Comprendre les groupes auxiliaires/supplémentaires avec NFS dans Azure NetApp Files
NFS a une limitation spécifique pour le nombre maximal de GID auxiliaires (groupes secondaires) qui peuvent être respectés dans une seule requête NFS. La valeur maximale de AUTH_SYS/AUTH_UNIX est de 16. Pour AUTH_GSS (Kerberos), la valeur maximale est 32. Il s’agit d’une limitation de protocole connue de NFS.
Azure NetApp Files permet d’augmenter le nombre maximal de groupes auxiliaires à 1 024. Cela est effectué en évitant la troncation de la liste de groupes dans le paquet NFS en prérécupération du groupe de l’utilisateur demandeur à partir d’un service de noms, tel que LDAP.
Fonctionnement
Les options permettant d’étendre la limitation de groupe fonctionnent de la même façon que pour -manage-gids les autres serveurs NFS. Au lieu de vider la liste complète des GID auxiliaires auxquels appartient un utilisateur, l’option recherche le GID sur le fichier ou le dossier et retourne cette valeur à la place.
Référence de commande pour les mountd notes :
-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.
Lorsqu’une demande d’accès est effectuée, seuls 16 GIO sont transmis dans la partie RPC du paquet.
Tout GID au-delà de la limite de 16 est supprimé par le protocole. Les GID étendus dans Azure NetApp Files peuvent uniquement être utilisés avec des services de noms externes tels que LDAP.
Impact potentiel sur les performances
Les groupes étendus ont une pénalité minimale en matière de performances, généralement dans les pourcentages à faible chiffre. Les charges de travail NFS de métadonnées plus élevées auraient probablement plus d’effet, en particulier sur les caches du système. Les performances peuvent également être affectées par la vitesse et la charge de travail des serveurs de service de noms. Les serveurs de service de noms surchargés sont plus lents à répondre, provoquant des retards dans la prérécupération du GID. Pour obtenir de meilleurs résultats, utilisez plusieurs serveurs de service de noms pour gérer un grand nombre de requêtes.
Option « Autoriser les utilisateurs locaux avec LDAP »
Lorsqu’un utilisateur tente d’accéder à un volume Azure NetApp Files via NFS, la requête est fournie dans un ID numérique. Par défaut, Azure NetApp Files prend en charge les appartenances de groupe étendues pour les utilisateurs NFS (pour dépasser la limite de 16 groupes standard à 1 024). Par conséquent, les fichiers Azure NetApp tentent de rechercher l’ID numérique dans LDAP dans une tentative de résolution des appartenances de groupe pour l’utilisateur plutôt que de passer les appartenances au groupe dans un paquet RPC.
En raison de ce comportement, si cet ID numérique ne peut pas être résolu en ldap, la recherche échoue et l’accès est refusé, même si l’utilisateur demandeur a l’autorisation d’accéder au volume ou à la structure de données.
L’option Autoriser les utilisateurs NFS locaux avec LDAP dans les connexions Active Directory est destinée à désactiver ces recherches LDAP pour les requêtes NFS en désactivant la fonctionnalité de groupe étendue. Il ne fournit pas de « création/gestion d’utilisateurs locaux » dans Azure NetApp Files.
Pour plus d’informations sur l’option, notamment son comportement avec différents styles de sécurité en volume dans Azure NetApp files, consultez Comprendre l’utilisation de LDAP avec Azure NetApp Files.