Delen via

Aanbevolen procedures voor koppelen in Linux NFS voor Azure NetApp Files

  • Artikel

Dit artikel helpt u inzicht te hebben in koppelingsopties en de aanbevolen procedures voor het gebruik ervan met Azure NetApp Files.

Nconnect

Met de nconnect koppelingsoptie kunt u het aantal verbindingen (netwerkstromen) opgeven dat tot stand moet worden gebracht tussen de NFS-client en het NFS-eindpunt tot een limiet van 16. Normaal gesproken maakt een NFS-client gebruik van één verbinding tussen zichzelf en het eindpunt. Door het aantal netwerkstromen te verhogen, worden de bovengrenzen van I/O en doorvoer aanzienlijk verhoogd. Testen is nconnect=8 de meest presterende.

Wanneer u een SAS GRID-omgeving met meerdere knooppunten voorbereidt voor productie, ziet u mogelijk een herhaalbare vermindering van 30% in runtime van 8 uur tot 5,5 uur:

Koppelingsoptie Uitvoeringstijden van taken
Nee nconnect 8 uur
nconnect=8 5,5 uur

Beide tests hebben dezelfde E32-8_v4 virtuele machine en RHEL8.3 gebruikt, waarbij de leesbewerking is ingesteld op 15 MiB.

Houd bij gebruik nconnectrekening met de volgende regels:

  • nconnect wordt ondersteund door Azure NetApp Files op alle belangrijke Linux-distributies, maar alleen op nieuwere releases:

    Linux-release NFSv3 (minimale release) NFSv4.1 (minimale release)
    Redhat Enterprise Linux RHEL8.3 RHEL8.3
    SUSE SLES12SP4 of SLES15SP1 SLES15SP2
    Ubuntu Ubuntu18.04

    Notitie

    SLES15SP2 is de minimale SUSE-release waarin nconnect Azure NetApp Files voor NFSv4.1 wordt ondersteund. Alle andere releases zoals opgegeven zijn de eerste releases die de nconnect functie hebben geïntroduceerd.

  • Alle koppelingen van één eindpunt nemen de nconnect instelling van de eerste gekoppelde export over, zoals wordt weergegeven in de volgende scenario's:

    Scenario 1: nconnect wordt gebruikt door de eerste koppeling. Daarom worden alle koppelingen tegen hetzelfde eindpuntgebruik nconnect=8gebruikt.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.10.10.10:/volume2 /mnt/volume2
    • mount 10.10.10.10:/volume3 /mnt/volume3

    Scenario 2: nconnect wordt niet gebruikt door de eerste koppeling. Daarom kunnen er geen koppelingen worden gebruikt voor hetzelfde eindpunt nconnect , ook al nconnect kan daar wel worden opgegeven.

    • mount 10.10.10.10:/volume1 /mnt/volume1
    • mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8
    • mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8

    Scenario 3: nconnect instellingen worden niet doorgegeven aan afzonderlijke opslageindpunten. nconnect wordt gebruikt door de koppeling die afkomstig is van 10.10.10.10 maar niet door de koppeling die afkomstig is van 10.12.12.12.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.12.12.12:/volume2 /mnt/volume2

  • nconnect kan worden gebruikt om de gelijktijdigheid van opslag van een bepaalde client te verhogen.

Zie best practices voor gelijktijdigheid van Linux voor Azure NetApp Files voor meer informatie.

Nconnect Overwegingen

Het wordt niet aanbevolen om opties samen te gebruiken nconnect en sec=krb5* te koppelen. Prestatievermindering is waargenomen bij het gebruik van de twee opties in combinatie.

De Generic Security Standard Application Programming Interface (GSS-API) biedt een manier voor toepassingen om gegevens te beveiligen die naar peertoepassingen worden verzonden. Deze gegevens kunnen vanaf een client op de ene computer naar een server op een andere computer worden verzonden. 

Wanneer nconnect wordt gebruikt in Linux, wordt de GSS-beveiligingscontext gedeeld tussen alle nconnect verbindingen met een bepaalde server. TCP is een betrouwbaar transport dat ondersteuning biedt voor pakketlevering buiten bestelling om te gaan met out-of-order pakketten in een GSS-stroom, met behulp van een schuifvenster met reeksnummers. Wanneer pakketten niet in het reeksvenster worden ontvangen, wordt de beveiligingscontext verwijderd en wordt er onderhandeld over een nieuwe beveiligingscontext. Alle berichten die in de nu genegeerde context worden verzonden, zijn niet meer geldig, waardoor de berichten opnieuw moeten worden verzonden. Een groter aantal pakketten in een nconnect installatie veroorzaakt frequente out-of-window pakketten, waardoor het beschreven gedrag wordt geactiveerd. Er kunnen geen specifieke degradatiepercentages worden vermeld met dit gedrag.

Rsize en Wsize

Voorbeelden in deze sectie bevatten informatie over het afstemmen van prestaties. Mogelijk moet u aanpassingen aanbrengen aan uw specifieke toepassingsbehoeften.

Met de rsize markeringen wsize wordt de maximale overdrachtsgrootte van een NFS-bewerking ingesteld. Als rsize of wsize niet is opgegeven bij koppelen, onderhandelen de client en server over de grootste grootte die door de twee wordt ondersteund. Momenteel ondersteunen zowel Azure NetApp Files als moderne Linux-distributies lees- en schrijfgrootten zo groot als 1.048.576 bytes (1 MiB). Voor de beste totale doorvoer en latentie raadt Azure NetApp Files echter aan beide rsize en wsize niet groter dan 262.144 bytes (256 K) in te stellen. U ziet mogelijk dat zowel de latentie als de lagere doorvoer bij gebruik rsize en wsize groter dan 256 KiB zijn.

Implementeer bijvoorbeeld een SAP HANA-scale-outsysteem met stand-byknooppunt op Azure-VM's met behulp van Azure NetApp Files op SUSE Linux Enterprise Server met de 256-KiB rsize en wsize het maximum als volgt:

sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001  nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-shared/shared /hana/shared  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0

SAS Viya raadt bijvoorbeeld een 256-KiB-lees- en schrijfgrootte aan, en SAS GRID beperkt de r/wsize tot 64 KiB terwijl de leesprestaties worden verbeterd met een verhoogde leesdoorloop voor de NFS-koppels. Zie de aanbevolen procedures voor het lezen van NFS voor Azure NetApp Files voor meer informatie.

De volgende overwegingen zijn van toepassing op het gebruik van rsize en wsize:

  • Grootten van willekeurige I/O-bewerkingen zijn vaak kleiner dan de rsize opties voor koppelen en wsize koppelen. Daarom zijn ze geen beperkingen.
  • Wanneer u de bestandssysteemcache gebruikt, vindt sequentiële I/O plaats op basis van de grootte die wordt geprediceerd door de rsize opties voor koppelen wsize , tenzij de bestandsgrootte kleiner is dan rsize en wsize.
  • Bewerkingen die de bestandssysteemcache omzeilen, hoewel ze nog steeds worden beperkt door de rsize opties voor koppelen en wsize koppelen, zijn niet zo groot als het maximum dat is opgegeven door rsize of wsize. Deze overweging is belangrijk wanneer u workloadgeneratoren gebruikt die de directio optie hebben.

Als best practice met Azure NetApp Files, voor de beste totale doorvoer en latentie, ingesteld rsize en wsize niet groter dan 262.144 bytes.

Close-to-open consistentie en timers voor cachekenmerken

NFS maakt gebruik van een los consistentiemodel. De consistentie is los, omdat de toepassing niet elke keer naar gedeelde opslag hoeft te gaan en gegevens hoeft op te halen om deze te gebruiken, een scenario dat een enorme impact zou hebben op de prestaties van de toepassing. Er zijn twee mechanismen voor het beheren van dit proces: timers voor cachekenmerken en close-to-open consistentie.

Als de client volledig eigenaar is van gegevens, dat wil gezegd, wordt deze niet gedeeld tussen meerdere knooppunten of systemen, dan is er gegarandeerde consistentie. In dat geval kunt u de getattr toegangsbewerkingen voor opslag verminderen en de toepassing versnellen door de consistentienocto van close-to-open (ctoals koppeloptie) uit te schakelen en door de time-outs voor het cachebeheer van kenmerken in te schakelen (actimeo=600als een koppelingsoptie de timer wijzigt in 10 m versus de standaardwaardenacregmin=3,acregmax=30,acdirmin=30,acdirmax=60). Bij sommige tests nocto vermindert ongeveer 65-70% van de getattr toegangsgesprekken en vermindert het actimeo aanpassen van deze aanroepen nog eens 20-25%.

Hoe timers voor kenmerkcache werken

De kenmerkenacregmin, acregmaxen acdirminacdirmax bepalen de coherentie van de cache. De voormalige twee kenmerken bepalen hoe lang de kenmerken van bestanden worden vertrouwd. De laatste twee kenmerken bepalen hoe lang de kenmerken van het mapbestand zelf worden vertrouwd (mapgrootte, mapeigendom, mapmachtigingen). De min en max kenmerken definiëren de minimale en maximale duur gedurende welke kenmerken van een map, kenmerken van een bestand en cache-inhoud van een bestand respectievelijk betrouwbaar worden geacht. Tussen min en max, wordt een algoritme gebruikt om de hoeveelheid tijd te definiëren waarin een vermelding in de cache wordt vertrouwd.

Denk bijvoorbeeld aan de standaardwaarden acregmin en acregmax waarden, respectievelijk 3 en 30 seconden. De kenmerken worden bijvoorbeeld herhaaldelijk geëvalueerd voor de bestanden in een map. Na 3 seconden wordt de NFS-service op nieuwheid opgevraagd. Als de kenmerken geldig worden geacht, verdubbelt de client de vertrouwde tijd naar 6 seconden, 12 seconden, 24 seconden, en als het maximum is ingesteld op 30, 30 seconden. Vanaf dat punt worden de kenmerken in de cache beschouwd als verouderd (op welk moment de cyclus opnieuw begint), wordt betrouwbaarheid gedefinieerd als 30 seconden als de waarde die is opgegeven door acregmax.

Er zijn andere gevallen die kunnen profiteren van een vergelijkbare set koppelopties, zelfs als er geen volledig eigendom van de clients is, bijvoorbeeld als de clients de gegevens gebruiken als alleen-lezen en gegevensupdate wordt beheerd via een ander pad. Voor toepassingen die gebruikmaken van rasters van clients zoals EDA, webhosting en filmweergave en relatief statische gegevenssets (EDA-hulpprogramma's of bibliotheken, webinhoud, patroongegevens), is het typische gedrag dat de gegevensset grotendeels in de cache van de clients wordt opgeslagen. Er zijn weinig leesbewerkingen en geen schrijfbewerkingen. Er komen veel getattr/access-aanroepen terug naar de opslag. Deze gegevenssets worden doorgaans bijgewerkt via een andere client die de bestandssystemen koppelen en regelmatig inhoudsupdates pushen.

In deze gevallen is er sprake van een bekende vertraging bij het ophalen van nieuwe inhoud en werkt de toepassing nog steeds met mogelijk verouderde gegevens. In deze gevallen nocto actimeo en kan worden gebruikt om de periode te bepalen waarin verouderde gegevens kunnen worden beheerd. In EDA-hulpprogramma's en -bibliotheken actimeo=600 werkt dit bijvoorbeeld goed omdat deze gegevens meestal onregelmatig worden bijgewerkt. Voor kleine webhosting waar clients hun gegevensupdates tijdig moeten zien wanneer ze hun sites bewerken, actimeo=10 zijn mogelijk acceptabel. Voor grootschalige websites waar inhoud naar meerdere bestandssystemen wordt gepusht, actimeo=60 is dit mogelijk acceptabel.

Als u deze koppelingsopties gebruikt, wordt de werkbelasting in deze gevallen aanzienlijk beperkt tot de opslag. (Een recente EDA-ervaring verminderde IOPS bijvoorbeeld tot het werktuigvolume van >150 K tot ~6 K.) Toepassingen kunnen aanzienlijk sneller worden uitgevoerd omdat ze de gegevens in het geheugen kunnen vertrouwen. (Geheugentoegangstijd is nanoseconden versus honderden microseconden voor getattr/access op een snel netwerk.)

Close-to-open consistentie

Close-to-open consistentie (de cto koppelingsoptie) zorgt ervoor dat bij het openen van de meest recente gegevens voor een bestand altijd aan de toepassing wordt gepresenteerd, ongeacht de status van de cache.

  • Wanneer een map wordt verkend (lsls -lbijvoorbeeld) wordt een bepaalde set RPC's (externe procedure-aanroepen) uitgegeven. De NFS-server deelt de weergave van het bestandssysteem. Zolang cto alle NFS-clients die toegang hebben tot een bepaalde NFS-export, zien alle clients dezelfde lijst met bestanden en mappen daarin. De nieuwheid van de kenmerken van de bestanden in de map wordt bepaald door de timers van de kenmerkcache. Met andere woorden, zolang cto dit wordt gebruikt, lijken bestanden externe clients te zien zodra het bestand is gemaakt en het bestand in de opslag terechtkomt.
  • Wanneer een bestand wordt geopend, is de inhoud van het bestand gegarandeerd nieuw vanuit het perspectief van de NFS-server. Als er een racevoorwaarde is waarbij de inhoud niet is leeggemaakt vanaf machine 1 wanneer een bestand wordt geopend op machine 2, ontvangt Machine 2 alleen de gegevens die aanwezig zijn op de server op het moment van openen. In dit geval haalt Machine 2 niet meer gegevens op uit het bestand totdat de acreg timer is bereikt en controleert Machine 2 de cacheherentie van de server opnieuw. Dit scenario kan worden waargenomen met behulp van een staart -f van machine 2 wanneer het bestand nog steeds naar machine 1 wordt geschreven.

Geen close-to-open consistentie

Wanneer er geen close-to-open consistentie (nocto) wordt gebruikt, vertrouwt de client de nieuwste weergave van het bestand en de map totdat de timers van het cachekenmerk zijn geschonden.

  • Wanneer een map wordt verkend (lsls -lbijvoorbeeld) wordt een bepaalde set RPC's (externe procedure-aanroepen) uitgegeven. De client geeft alleen een aanroep naar de server uit voor een huidige lijst met bestanden wanneer de acdir cachetimerwaarde is geschonden. In dit geval worden onlangs gemaakte bestanden en mappen niet weergegeven. Onlangs verwijderde bestanden en mappen worden weergegeven.

  • Wanneer een bestand wordt geopend, zolang het bestand zich nog in de cache bevindt, wordt de inhoud in de cache (indien aanwezig) geretourneerd zonder consistentie met de NFS-server te valideren.

Volgende stappen