Partilhar via


Compreender grupos auxiliares/suplementares com NFS nos Arquivos NetApp do Azure

O NFS tem uma limitação específica para o número máximo de GIDs auxiliares (grupos secundários) que podem ser honrados em uma única solicitação NFS. O máximo para AUTH_SYS/AUTH_UNIX é 16. Para AUTH_GSS (Kerberos), o máximo é 32. Esta é uma limitação de protocolo conhecida do NFS.

Os Arquivos NetApp do Azure fornecem a capacidade de aumentar o número máximo de grupos auxiliares para 1.024. Isso é feito evitando o truncamento da lista de grupos no pacote NFS pré-buscando o grupo do usuário solicitante de um serviço de nomes, como LDAP.

Como funciona

As opções para estender a limitação de grupo funcionam da mesma forma que a -manage-gids opção para outros servidores NFS. Em vez de despejar toda a lista de GIDs auxiliares aos quais um usuário pertence, a opção procura o GID no arquivo ou pasta e retorna esse valor.

A referência de comando para mountd 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.

Quando uma solicitação de acesso é feita, apenas 16 GIDs são passados na parte RPC do pacote.

Output of RPC packet with 16 GIDs.

Qualquer GID além do limite de 16 é descartado pelo protocolo. Os GIDs estendidos nos Arquivos NetApp do Azure só podem ser usados com serviços de nomes externos, como LDAP.

Potenciais impactos no desempenho

Os grupos estendidos têm uma penalidade mínima de desempenho, geralmente em percentuais baixos de um dígito. Cargas de trabalho NFS de metadados mais altas provavelmente teriam mais efeito, particularmente nos caches do sistema. O desempenho também pode ser afetado pela velocidade e carga de trabalho dos servidores de serviço de nomes. Servidores de serviço de nome sobrecarregados são mais lentos para responder, causando atrasos na pré-busca do GID. Para obter melhores resultados, use vários servidores de serviço de nomes para lidar com um grande número de solicitações.

Opção "Permitir usuários locais com LDAP"

Quando um usuário tenta acessar um volume de Arquivos NetApp do Azure via NFS, a solicitação vem em uma ID numérica. Por padrão, o Azure NetApp Files oferece suporte a associações de grupo estendidas para usuários NFS (para ir além do limite padrão de 16 grupos para 1.024). Como resultado, os arquivos NetApp do Azure tentam procurar a ID numérica no LDAP em uma tentativa de resolver as associações de grupo para o usuário em vez de passar as associações de grupo em um pacote RPC.

Devido a esse comportamento, se essa ID numérica não puder ser resolvida para um usuário no LDAP, a pesquisa falhará e o acesso será negado, mesmo que o usuário solicitante tenha permissão para acessar o volume ou a estrutura de dados.

A opção Permitir usuários NFS locais com LDAP em conexões do Ative Directory destina-se a desabilitar essas pesquisas LDAP para solicitações NFS desativando a funcionalidade de grupo estendido. Ele não fornece "criação/gerenciamento de usuário local" nos Arquivos NetApp do Azure.

Para obter mais informações sobre a opção, incluindo como ela se comporta com diferentes estilos de segurança de volume em arquivos NetApp do Azure, consulte Compreender o uso de LDAP com arquivos NetApp do Azure.

Próximos passos