Descripción de los grupos auxiliares o complementarios con NFS en Azure NetApp Files
NFS tiene una limitación específica para el número máximo de GID auxiliares (grupos secundarios) que se pueden respetar en una sola solicitud NFS. El máximo de AUTH_SYS/AUTH_UNIX es 16. Para AUTH_GSS (Kerberos), el máximo es 32. Se trata de una limitación de protocolo conocida de NFS.
Azure NetApp Files proporciona la capacidad de aumentar el número máximo de grupos auxiliares a 1024. Esto se realiza evitando el truncamiento de la lista de grupos en el paquete NFS capturando previamente el grupo del usuario solicitante de un servicio de nombres, como LDAP.
Funcionamiento
Las opciones para ampliar la limitación de grupo funcionan de la misma manera que funciona la -manage-gids opción para otros servidores NFS. En lugar de volcar la lista completa de GID auxiliares a los que pertenece un usuario, la opción busca el GID en el archivo o carpeta y devuelve ese valor en su lugar.
Referencia del comando para mountd las notas:
-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.
Cuando se realiza una solicitud de acceso, solo se pasan 16 GID en la parte RPC del paquete.
El protocolo quita cualquier GID más allá del límite de 16. Los GID extendidos en Azure NetApp Files solo se pueden usar con servicios de nombres externos, como LDAP.
Posibles impactos en el rendimiento
Los grupos extendidos tienen una penalización de rendimiento mínima, generalmente en porcentajes de dígitos únicos bajos. Es probable que las cargas de trabajo NFS de metadatos más altas tengan más efecto, especialmente en las memorias caché del sistema. El rendimiento también puede verse afectado por la velocidad y la carga de trabajo de los servidores de servicio de nombres. Los servidores de servicio de nombres sobrecargados son más lentos para responder, lo que provoca retrasos en la captura previa del GID. Para obtener los mejores resultados, use varios servidores de servicio de nombres para controlar un gran número de solicitudes.
Opción "Permitir usuarios locales con LDAP"
Cuando un usuario intenta acceder a un volumen de Azure NetApp Files a través de NFS, la solicitud se incluye en un identificador numérico. De forma predeterminada, Azure NetApp Files admite pertenencias extendidas a grupos para usuarios NFS (para ir más allá del límite estándar de 16 grupos a 1024). Como resultado, Azure NetApp files intenta buscar el identificador numérico en LDAP en un intento de resolver las pertenencias a grupos para el usuario en lugar de pasar las pertenencias a grupos en un paquete RPC.
Debido a ese comportamiento, si ese identificador numérico no se puede resolver para un usuario en LDAP, se produce un error en la búsqueda y se deniega el acceso, incluso si el usuario solicitante tiene permiso para acceder al volumen o la estructura de datos.
La opción Permitir usuarios NFS locales con LDAP en conexiones de Active Directory está pensada para deshabilitar esas búsquedas LDAP para las solicitudes NFS deshabilitando la funcionalidad de grupo extendido. No proporciona "creación o administración de usuarios locales" en Azure NetApp Files.
Para más información sobre la opción, incluido cómo se comporta con diferentes estilos de seguridad de volumen en Azure NetApp files, consulte Descripción del uso de LDAP con Azure NetApp Files.