Hulp-/aanvullende groepen begrijpen met NFS in Azure NetApp Files
NFS heeft een specifieke beperking voor het maximum aantal hulp-GID's (secundaire groepen) dat kan worden uitgevoerd in één NFS-aanvraag. Het maximum voor AUTH_SYS/AUTH_UNIX is 16. Voor AUTH_GSS (Kerberos) is het maximum 32. Dit is een bekende protocolbeperking van NFS.
Azure NetApp Files biedt de mogelijkheid om het maximum aantal hulpgroepen te verhogen naar 1024. Dit wordt uitgevoerd door afkapping van de groepslijst in het NFS-pakket te voorkomen door de groep van de aanvragende gebruiker vooraf te laten gaan uit een naamservice, zoals LDAP.
Hoe het werkt
De opties voor het uitbreiden van de groepsbeperking werken op dezelfde manier als de -manage-gids optie voor andere NFS-servers. In plaats van de volledige lijst met hulp-GID's waartoe een gebruiker behoort te dumpen, zoekt de optie de GID op in het bestand of de map en retourneert deze waarde in plaats daarvan.
De opdrachtreferentie voor mountd notities:
-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.
Wanneer er een toegangsaanvraag wordt gedaan, worden er slechts 16 GID's doorgegeven in het RPC-gedeelte van het pakket.
Elke GID buiten de limiet van 16 wordt verwijderd door het protocol. Uitgebreide GID's in Azure NetApp Files kunnen alleen worden gebruikt met externe naamservices zoals LDAP.
Mogelijke gevolgen voor prestaties
Uitgebreide groepen hebben een minimale prestatiestraf, meestal in de percentages met één cijfer met lage cijfers. Hogere NFS-workloads met metagegevens hebben waarschijnlijk meer effect, met name op de caches van het systeem. De prestaties kunnen ook worden beïnvloed door de snelheid en werkbelasting van de naamserviceservers. Overbelaste naamserviceservers reageren trager, wat vertragingen veroorzaakt bij het afmaken van de GID. Gebruik voor de beste resultaten meerdere naamserviceservers om grote aantallen aanvragen te verwerken.
Optie Lokale gebruikers met LDAP toestaan
Wanneer een gebruiker probeert toegang te krijgen tot een Azure NetApp Files-volume via NFS, wordt de aanvraag geleverd in een numerieke id. Standaard ondersteunt Azure NetApp Files uitgebreide groepslidmaatschappen voor NFS-gebruikers (om de standaardlimiet van 16 groepen te overschrijden tot 1024). Als gevolg hiervan probeert Azure NetApp-bestanden de numerieke id in LDAP op te zoeken in een poging om de groepslidmaatschappen voor de gebruiker op te lossen in plaats van de groepslidmaatschappen in een RPC-pakket door te geven.
Als deze numerieke id vanwege dat gedrag niet kan worden omgezet naar een gebruiker in LDAP, mislukt de zoekactie en wordt de toegang geweigerd, zelfs als de aanvragende gebruiker gemachtigd is om toegang te krijgen tot het volume of de gegevensstructuur.
De optie Lokale NFS-gebruikers met ldap toestaan in Active Directory-verbindingen is bedoeld om deze LDAP-zoekopdrachten voor NFS-aanvragen uit te schakelen door de uitgebreide groepsfunctionaliteit uit te schakelen. Het biedt geen 'lokale gebruiker maken/beheren' in Azure NetApp Files.
Zie Inzicht in het gebruik van LDAP met Azure NetApp Files voor meer informatie over de optie, inclusief hoe deze zich gedraagt met verschillende volumebeveiligingsstijlen in Azure NetApp Files.