Informazioni sui gruppi ausiliari/supplementari con NFS in Azure NetApp Files
NFS presenta una limitazione specifica per il numero massimo di GID ausiliari (gruppi secondari) che possono essere rispettati in una singola richiesta NFS. Il valore massimo per AUTH_SYS/AUTH_UNIX è 16. Per AUTH_GSS (Kerberos), il valore massimo è 32. Si tratta di una limitazione nota del protocollo NFS.
Azure NetApp Files offre la possibilità di aumentare il numero massimo di gruppi ausiliari a 1.024. Questa operazione viene eseguita evitando il troncamento dell'elenco di gruppi nel pacchetto NFS prelettura del gruppo dell'utente richiedente da un servizio dei nomi, ad esempio LDAP.
Funzionamento
Le opzioni per estendere la limitazione del gruppo funzionano allo stesso modo in cui funziona l'opzione -manage-gids per altri server NFS. Anziché eseguire il dump dell'intero elenco di GID ausiliari a cui appartiene un utente, l'opzione cerca il GID nel file o nella cartella e restituisce invece tale valore.
Informazioni di riferimento sul comando per mountd le note:
-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 viene effettuata una richiesta di accesso, nella parte RPC del pacchetto vengono passati solo 16 GID.
Qualsiasi GID oltre il limite di 16 viene eliminato dal protocollo. I GID estesi in Azure NetApp Files possono essere usati solo con servizi dei nomi esterni, ad esempio LDAP.
Potenziali impatti sulle prestazioni
I gruppi estesi hanno una riduzione minima delle prestazioni, in genere nelle percentuali a singola cifra bassa. I carichi di lavoro NFS con metadati più elevati avranno probabilmente un effetto maggiore, in particolare nelle cache del sistema. Le prestazioni possono essere influenzate anche dalla velocità e dal carico di lavoro dei server del servizio dei nomi. I server del servizio dei nomi in overload sono più lenti a rispondere, causando ritardi nel prelettura del GID. Per ottenere risultati ottimali, usare più server del servizio dei nomi per gestire un numero elevato di richieste.
Opzione "Consenti utenti locali con LDAP"
Quando un utente tenta di accedere a un volume di Azure NetApp Files tramite NFS, la richiesta viene inserita in un ID numerico. Per impostazione predefinita, Azure NetApp Files supporta le appartenenze estese ai gruppi per gli utenti NFS (per superare il limite standard di 16 gruppi a 1.024). Di conseguenza, Azure NetApp files tenta di cercare l'ID numerico in LDAP nel tentativo di risolvere le appartenenze ai gruppi per l'utente anziché passare le appartenenze ai gruppi in un pacchetto RPC.
A causa di questo comportamento, se tale ID numerico non può essere risolto in un utente in LDAP, la ricerca non riesce e l'accesso viene negato, anche se l'utente richiedente dispone dell'autorizzazione per accedere al volume o alla struttura dei dati.
L'opzione Consenti utenti NFS locali con LDAP nelle connessioni Active Directory è destinata a disabilitare le ricerche LDAP per le richieste NFS disabilitando la funzionalità del gruppo esteso. Non fornisce "creazione/gestione utente locale" in Azure NetApp Files.
Per altre informazioni sull'opzione, incluso il comportamento con diversi stili di sicurezza dei volumi in Azure NetApp Files, vedere Informazioni sull'uso di LDAP con Azure NetApp Files.