Delen via

Beste praktijken voor Linux NFS mountopties bij gebruik van Azure NetApp Files

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. Uit tests bleek nconnect=8 de best presterende te zijn.

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 series tests maakten gebruik van dezelfde E32-8_v4 virtuele machine en RHEL8.3. Hierbij werd vooruitladen 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 versie) NFSv4.1 (minimale versie)
    Red Hat 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 montage. Daarom gebruiken alle koppelingen hetzelfde eindpunt nconnect=8.

    • 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: De eerste koppeling maakt geen gebruik van nconnect. Daarom worden er geen koppelingen gemaakt tegen hetzelfde eindpunt nconnect, zelfs als nconnect daar kan worden gespecificeerd.

    • 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.

Voor meer informatie, zie best practices voor gelijktijdigheid van Linux voor Azure NetApp Files.

Nconnect Overwegingen

Het is niet raadzaam om de montage-opties nconnect en sec=krb5* samen te gebruiken. Als u deze opties samen gebruikt, kan dit leiden tot prestatievermindering.

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 zou kunnen opmerken dat zowel de verhoogde latentie als de verlaagde doorvoer optreden bij gebruik van rsize en wsize groter dan 256 KiB.

Implementeer bijvoorbeeld een SAP HANA-scale-outsysteem met standbyknooppunt op Azure-VM's door gebruik te maken van Azure NetApp Files op SUSE Linux Enterprise Server waarbij het 256-KiB rsize en wsize maximum als volgt wordt getoond:

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 lees- en schrijfgrootte van 256 KiB aan, terwijl SAS GRID de r/wsize beperkt tot 64 KiB en tegelijkertijd de leesprestaties verbetert door voorspellend lezen op de NFS-koppels te verhogen. 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- en wsize-koppelopties. Daarom zijn ze geen beperkingen.
  • Wanneer u de bestandssysteemcache gebruikt, zal sequentiële I/O plaatsvinden op de grootte die wordt voorspeld door de rsize mount opties wsize, tenzij de bestandsgrootte kleiner is dan rsize en wsize.
  • Bewerkingen die de bestandssysteemcache omzeilen, hoewel ze nog steeds worden beperkt door de rsize- en wsize-opties voor 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 een best practice met Azure NetApp Files, stel voor de beste algemene doorvoer en latentie rsize en wsize in op 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 consistentiecto van close-to-open (noctoals 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 eerste twee kenmerken bepalen hoe lang de eigenschappen 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 gelden de kenmerken in de cache als verouderd zodra dit blijkt, waarna de cyclus opnieuw begint. Vanaf dat moment wordt de betrouwbaarheid gedefinieerd als een periode van 30 seconden zoals opgegeven door acregmax.

Er zijn andere gevallen die kunnen profiteren van een vergelijkbare set koppelopties, zelfs als de clients niet volledig eigenaar zijn, bijvoorbeeld wanneer ze alleen-lezen toegang tot de gegevens hebben en de gegevensupdates via een ander kanaal worden beheerd. Voor toepassingen die gebruikmaken van netwerken van clientcomputers zoals die worden gebruikt bij EDA, webhosting en filmweergave, en gegevenssets die relatief statisch zijn (zoals EDA-hulpprogramma's of bibliotheken, webinhoud, patroongegevens), is het typische gedrag dat de gegevensset grotendeels in de cache van de clientcomputers 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 kunnen nocto en actimeo worden gebruikt om de periode te bepalen waarin verouderde datum kan 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.

Door deze koppelopties te gebruiken, wordt de werkbelasting in deze gevallen aanzienlijk verminderd voor 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.)

Consistentie van dichtbij-naar-open

Bij close-to-open consistentie (de cto koppelingsoptie) wordt ervoor gezorgd dat de meest recente gegevens van een bestand altijd aan de toepassing worden gepresenteerd wanneer het wordt geopend, 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 wordt gebruikt door alle NFS-clients die toegang hebben tot een bepaalde NFS-export, zullen alle clients dezelfde lijst met bestanden en mappen daarin zien. De actualiteit van de kenmerken van de bestanden in de directory wordt bepaald door de kenmerkcache-timers. Met andere woorden, zolang cto wordt gebruikt, lijken bestanden voor externe gebruikers zichtbaar zodra het bestand is gemaakt en 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 tail-commando -f van machine 2 wanneer het bestand nog steeds naar machine 1 wordt geschreven.

Geen consistentie van sluit naar open

Wanneer er geen close-to-open consistentie (nocto) is gebruikt, vertrouwt de client de versheid van zijn huidige weergave van het bestand en de map totdat de timer van de cache-attributen zijn overschreden.

  • 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

  • Last updated on