Förstå extra/kompletterande grupper med NFS i Azure NetApp Files
NFS har en specifik begränsning för det maximala antalet extra GID:er (sekundära grupper) som kan uppfyllas i en enda NFS-begäran. Maxvärdet för AUTH_SYS/AUTH_UNIX är 16. För AUTH_GSS (Kerberos) är maxvärdet 32. Detta är en känd protokollbegränsning för NFS.
Med Azure NetApp Files kan du öka det maximala antalet extragrupper till 1 024. Detta utförs genom att undvika trunkering av grupplistan i NFS-paketet genom att förinstallera den begärande användarens grupp från en namntjänst, till exempel LDAP.
Så här fungerar det
Alternativen för att utöka gruppbegränsningen fungerar på samma sätt som -manage-gids för andra NFS-servrar. I stället för att dumpa hela listan över extra GID:er som en användare tillhör letar alternativet upp GID:t i filen eller mappen och returnerar det värdet i stället.
Kommandoreferensen för mountd anteckningar:
-g or --manage-gids
Accept requests from the kernel to map user id numbers into lists of group id numbers for use in access control. An NFS request will normally except when using Kerberos or other cryptographic authentication) contains a user-id and a list of group-ids. Due to a limitation in the NFS protocol, at most 16 groups ids can be listed. If you use the -g flag, then the list of group ids received from the client will be replaced by a list of group ids determined by an appropriate lookup on the server.
När en åtkomstbegäran görs skickas endast 16 GID:er i RPC-delen av paketet.
Alla GID som överskrider gränsen på 16 tas bort av protokollet. Utökade GID:er i Azure NetApp Files kan bara användas med externa namntjänster som LDAP.
Potentiella prestandaeffekter
Utökade grupper har en minimal prestandastraff, vanligtvis i de låga ensiffriga procentsatserna. Högre NFS-arbetsbelastningar med metadata skulle sannolikt ha större effekt, särskilt på systemets cacheminnen. Prestanda kan också påverkas av hastigheten och arbetsbelastningen för namntjänstservrarna. Överlagrade namntjänstservrar svarar långsammare, vilket orsakar fördröjningar i förinläsningen av GID:en. För bästa resultat använder du flera namntjänstservrar för att hantera ett stort antal begäranden.
Alternativet "Tillåt lokala användare med LDAP"
När en användare försöker komma åt en Azure NetApp Files-volym via NFS kommer begäran i ett numeriskt ID. Som standard stöder Azure NetApp Files utökade gruppmedlemskap för NFS-användare (för att gå utöver standardgränsen på 16 grupper till 1 024). Därför försöker Azure NetApp-filer leta upp det numeriska ID:t i LDAP i ett försök att lösa gruppmedlemskapen för användaren i stället för att skicka gruppmedlemskapen i ett RPC-paket.
På grund av det beteendet misslyckas sökningen och åtkomst nekas om det numeriska ID:t inte kan matchas mot en användare i LDAP, även om den begärande användaren har behörighet att komma åt volymen eller datastrukturen.
Alternativet Tillåt lokala NFS-användare med LDAP i Active Directory-anslutningar är avsett att inaktivera dessa LDAP-sökningar för NFS-begäranden genom att inaktivera den utökade gruppfunktionen. Den tillhandahåller inte "skapande/hantering av lokala användare" i Azure NetApp Files.
Mer information om alternativet, inklusive hur det fungerar med olika volymsäkerhetsformat i Azure NetApp-filer, finns i Förstå användningen av LDAP med Azure NetApp Files.