Grundlegendes zu Hilfs-/Ergänzenden Gruppen mit NFS in Azure NetApp Files
NFS hat eine spezifische Einschränkung für die maximale Anzahl von Hilfs-GIDs (sekundäre Gruppen), die in einer einzigen NFS-Anforderung berücksichtigt werden können. Der Höchstwert für AUTH_SYS/AUTH_UNIX beträgt 16. Für AUTH_GSS (Kerberos) beträgt der Maximalwert 32. Dies ist eine bekannte Protokollbeschränkung von NFS.
Azure NetApp Files bietet die Möglichkeit, die maximale Anzahl von Hilfsgruppen auf 1.024 zu erhöhen. Dies wird durchgeführt, indem verhindert wird, dass die Gruppenliste im NFS-Paket abgeschnitten wird, indem die Gruppe des anfordernden Benutzers von einem Namensdienst, z. B. LDAP, vorab gelöscht wird.
Funktionsweise
Die Optionen zum Erweitern der Gruppeneinschränkung funktionieren auf die gleiche Weise wie die -manage-gids Option für andere NFS-Server. Anstatt die gesamte Liste der Hilfs-GIDs zu dumpingn, zu denen ein Benutzer gehört, sucht die Option die GID in der Datei oder dem Ordner und gibt stattdessen diesen Wert zurück.
Die Befehlsreferenz für mountd Hinweise:
-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.
Wenn eine Zugriffsanforderung gestellt wird, werden nur 16 GIDs im RPC-Teil des Pakets übergeben.
Alle GID, die über die Grenze von 16 hinausgehen, werden vom Protokoll verworfen. Erweiterte GIDs in Azure NetApp-Dateien können nur mit externen Namensdiensten wie LDAP verwendet werden.
Mögliche Auswirkungen auf die Leistung
Erweiterte Gruppen haben eine minimale Leistungseinbuße, im Allgemeinen in prozentual niedrigen Prozentsätzen. Höhere METADATEN-NFS-Workloads würden wahrscheinlich mehr Auswirkungen haben, insbesondere auf die Caches des Systems. Die Leistung kann auch durch die Geschwindigkeit und Arbeitsauslastung der Namendienstserver beeinträchtigt werden. Überlastete Namendienstserver reagieren langsamer und verursachen Verzögerungen beim Vorabstart der GID. Um optimale Ergebnisse zu erzielen, verwenden Sie mehrere Namendienstserver, um eine große Anzahl von Anforderungen zu verarbeiten.
Option "Lokale Benutzer mit LDAP zulassen"
Wenn ein Benutzer versucht, über NFS auf ein Azure NetApp Files-Volume zuzugreifen, wird die Anforderung in eine numerische ID gestellt. Standardmäßig unterstützt Azure NetApp Files erweiterte Gruppenmitgliedschaften für NFS-Benutzer (um den Standardgrenzwert von 16 Gruppen auf 1.024 zu überschreiten). Daher versucht Azure NetApp-Dateien, die numerische ID in LDAP nachzuschlagen, um die Gruppenmitgliedschaften für den Benutzer aufzulösen, anstatt die Gruppenmitgliedschaften in einem RPC-Paket zu übergeben.
Wenn diese numerische ID aufgrund dieses Verhaltens nicht für einen Benutzer in LDAP aufgelöst werden kann, schlägt die Suche fehl, und der Zugriff wird verweigert, auch wenn der anfordernde Benutzer über die Berechtigung für den Zugriff auf das Volume oder die Datenstruktur verfügt.
Die Option "Lokale NFS-Benutzer mit LDAP-Option in Active Directory-Verbindungen zulassen" soll diese LDAP-Nachschlagevorgänge für NFS-Anforderungen deaktivieren, indem die erweiterte Gruppenfunktionalität deaktiviert wird. Es stellt keine "lokale Benutzererstellung/-verwaltung" in Azure NetApp Files bereit.
Weitere Informationen zur Option, einschließlich des Verhaltens mit unterschiedlichen Volumensicherheitsstilen in Azure NetApp-Dateien, finden Sie unter Grundlegendes zur Verwendung von LDAP mit Azure NetApp Files.