Megosztás a következőn keresztül:

A Linux NFS csatlakoztatási beállításainak ajánlott eljárásai az Azure NetApp Fileshoz

Ez a cikk segít megérteni a csatlakoztatási lehetőségeket és az Azure NetApp Files használatával kapcsolatos ajánlott eljárásokat.

Nconnect

nconnect A csatlakoztatási beállítással 16-os korlátig megadhatja az NFS-ügyfél és az NFS-végpont között létesítendő kapcsolatok (hálózati folyamatok) számát. Az NFS-ügyfelek hagyományosan egyetlen kapcsolatot használnak maguk és a végpont között. A hálózati folyamatok számának növelése jelentősen növeli az I/O és az átviteli sebesség felső korlátját. A tesztelések során nconnect=8 bizonyult a legjobban teljesítőnek.

Többcsomópontos SAS GRID-környezet éles környezetben való előkészítésekor észreveheti, hogy a futási idő ismétlődően 30%-kal csökken, 8 óráról 5,5 órára:

Csatlakoztatási lehetőség Feladat futási ideje
Nem nconnect 8 óra
nconnect=8 5,5 óra

Mindkét tesztkészlet ugyanazt az E32-8_v4 virtuális gépet és az RHEL8.3-at használta, az előre olvashatóság pedig 15 MiB volt.

Ha használja nconnect, tartsa szem előtt az alábbi szabályokat:

  • nconnect az Azure NetApp Files minden nagyobb Linux-disztribúcióban támogatja, de csak az újabb kiadások esetében:

    Linux-kiadás NFSv3 (minimális kiadás) NFSv4.1 (minimális kiadás)
    Red Hat Enterprise Linux RHEL8.3 RHEL8.3
    SUSE SLES12SP4 vagy SLES15SP1 SLES15SP2
    Ubuntu Ubuntu18.04

    Feljegyzés

    SLES15SP2 a minimális SUSE-kiadás, amelyben nconnect az NFSv4.1-hez készült Azure NetApp Files támogatja. A megadott összes többi kiadás az első kiadás, amely bevezette a nconnect funkciót.

  • Az egyetlen végpont összes csatlakoztatása örökli az nconnect első csatlakoztatott exportálás beállítását, ahogyan az a következő forgatókönyvekben is látható:

    1. forgatókönyv: nconnect az első csatlakoztatás által van használva. Ezért az összes csatlakoztatás ugyanarra a végpontra vonatkozik 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

    2. forgatókönyv: az első szerelés nem használja a nconnect-t. Ezért ugyanahhoz a végponthoz nem történik csatlakoztatás nconnect, még akkor sem, ha nconnect ott meg van adva.

    • 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

    3. forgatókönyv: nconnect A beállítások nem propagálása külön tárolási végpontokon keresztül. nconnect a 10.10.10.10-ról érkező tartó által van használva, de nem a 10.12.12.12-ról érkező tartó által.

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

  • nconnect az adott ügyfél tárolási egyidejűségének növelésére használható.

További részletekért tekintse meg az Azure NetApp Files linuxos egyidejűségi ajánlott eljárásait.

Nconnect Megfontolások

Nem ajánlott együtt használni a nconnect és a sec=krb5* csatolási opciókat. A beállítások együttes használata teljesítménycsökkenést okozhat.

Az általános biztonsági standard alkalmazásprogramozási felület (GSS-API) lehetővé teszi az alkalmazások számára a társalkalmazásoknak küldött adatok védelmét. Ezek az adatok elküldhetők az egyik gépen lévő ügyfélről egy másik gépen lévő kiszolgálóra. 

Linux nconnect esetén a GSS biztonsági környezete meg van osztva az nconnect adott kiszolgálóval létesített összes kapcsolat között. A TCP egy megbízható átvitel, amely támogatja a rendelésen kívüli csomagkézbesítést a GSS-adatfolyamban lévő, rendelésen kívüli csomagok kezeléséhez a sorszámokat tartalmazó tolóablak használatával. Ha a rendszer nem a sorrendablakban lévő csomagokat fogadja, a rendszer elveti a biztonsági környezetet, és egy új biztonsági környezetet tárgyal. A most elvetett környezetben küldött összes üzenet már nem érvényes, ezért az üzeneteket ismét el kell küldeni. A nconnect beállításban lévő nagyobb számú csomag gyakori ablakon kívüli csomagokat eredményez, ezzel aktiválva a leírt viselkedést. Ezzel a viselkedéssel nem határozható meg konkrét csökkenési százalékérték.

Rsize és Wsize

Az ebben a szakaszban található példák a teljesítményhangolás megközelítésével kapcsolatos információkat tartalmaznak. Előfordulhat, hogy az adott alkalmazás igényeihez igazodva változtatásokat kell eszközölnie.

A rsize és wsize a jelzők egy NFS-művelet maximális átviteli méretét állítják be. Ha rsize vagy wsize egyike sincs megadva a csatlakoztatáskor, akkor az ügyfél és a kiszolgáló egyezteti a kettő által támogatott legnagyobb méretet. Az Azure NetApp Files és a modern Linux-disztribúciók jelenleg 1 048 576 bájt (1 MiB) méretű olvasási és írási méretet támogatnak. A legjobb általános átviteli sebesség és késés érdekében azonban az Azure NetApp Files 262 144 bájtnál (256 K) nagyobb és rsize nem nagyobb beállítást wsize javasol. Megfigyelheti, hogy esetleg mind a megnövekedett késleltetés, mind a csökkent átviteli sebesség előfordulhat, amikor 256 KiB-nél nagyobb rsize és wsize értékeket használ.

Ha például az Azure NetApp Files-t használja az SUSE Linux Enterprise Serveren egy SAP HANA scale-out rendszert készenléti csomóponttal az Azure VMs-en történő üzembe helyezéshez, az alábbi módon jeleníti meg a 256 KiB és a maximum értéket:

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

A SAS Viya például 256 KiB olvasási és írási méretet javasol, miközben a SAS GRID a r/wsize méretét 64 KiB-re korlátozza, és a teljesítményt az NFS-csatlakoztatások esetében a megnövelt előolvasással javítja. További részletekért tekintse meg az Azure NetApp Files NFS-sel kapcsolatos ajánlott eljárásait.

A következő szempontok vonatkoznak a következők használatárarsize:wsize

  • A véletlenszerű I/O-műveletek mérete gyakran kisebb, mint a rsize és wsize csatolási opciók. Ezért ezek nem kényszerek.
  • A fájlrendszer-gyorsítótár használatakor a szekvenciális I/O a rsize és wsize csatlakoztatási beállítások által meghatározott méretben történik, kivéve, ha a fájl mérete kisebb, mint rsize vagy wsize.
  • A fájlrendszer-gyorsítótárat megkerülő műveletek, bár továbbra is korlátozzák a rsize és wsize csatlakoztatási lehetőségek, nem olyan mértékűek, mint a rsize vagy wsize által megadott maximum. Ez a szempont akkor fontos, ha olyan számítási feladatgenerátorokat használ, amelyek rendelkeznek a directio lehetőséggel.

Az Azure NetApp Files ajánlott eljárása az, hogy a lehető legjobb általános teljesítmény és késési idő érdekében állítsa be rsize és wsize értékét legfeljebb 262 144 bájtra.

Nyitott konzisztencia- és gyorsítótárattribútum-időzítők

Az NFS laza konzisztenciamodellt használ. A konzisztencia laza, mert az alkalmazásnak nem kell minden alkalommal megosztott tárolóba mennie és lekérnie az adatokat, ami óriási hatással lenne az alkalmazás teljesítményére. A folyamatot két mechanizmus kezeli: a gyorsítótárattribútum-időzítők és a nyitotthoz közeli konzisztencia.

Ha az ügyfél teljes körűen birtokolja az adatokat, azaz nem osztják meg több csomópont vagy rendszer között, akkor garantált konzisztencia áll fenn. Ebben az esetben csökkentheti a getattr tárolási hozzáférési műveleteket, és felgyorsíthatja az alkalmazást a megnyitáshoz közeli () konzisztencia kikapcsolásával (ctonoctocsatlakoztatási lehetőségként), valamint az attribútumgyorsítótár-kezelés időtúllépéseinek bekapcsolásával (actimeo=600mivel a csatlakoztatási beállítás az időzítőt 10m-re módosítja az alapértelmezett értékekkel acregmin=3,acregmax=30,acdirmin=30,acdirmax=60szemben). Egyes tesztelések nocto során a hozzáférési hívások körülbelül 65-70%-át csökkenti, a módosítás getattr pedig további 20-25%-actimeokal csökkenti ezeket a hívásokat.

Az attribútumgyorsítótár időzítőinek működése

Az attribútumok acregmin, acregmax, acdirmin és acdirmax szabályozzák a gyorsítótár koherenciáját. Az előbbi két attribútum határozza meg, hogy a fájlok attribútumai mennyi ideig megbízhatók. Az utóbbi két attribútum határozza meg, hogy a címtárfájl attribútumai mennyi ideig megbízhatók (címtárméret, címtár tulajdonjoga, címtárengedélyek). Az min és max az attribútumok határozzák meg a minimális és maximális időtartamot, amely alatt a címtár attribútumai, a fájl attribútumai és a fájlok gyorsítótár-tartalma megbízhatónak minősülnek. Az min és max között egy algoritmus segítségével határozzuk meg, mennyi ideig tekinthető megbízhatónak a gyorsítótárazott bejegyzés.

Vegyük például az alapértelmezett acregmin és acregmax értékeket, 3 és 30 másodperc, illetve. Például az attribútumok ismételt kiértékelése a címtárban lévő fájlok esetében történik. 3 másodperc elteltével a program lekérdezi az NFS szolgáltatást a frissesség érdekében. Ha az attribútumok érvényesnek minősülnek, az ügyfél megduplázza a megbízható időt 6 másodpercre, 12 másodpercre és 24 másodpercre, majd a maximális érték 30, 30 másodpercre van állítva. Ettől a ponttól kezdve, amíg a gyorsítótárazott attribútumok elavultnak nem minősülnek (amikor a ciklus újraindul), a megbízhatóságot 30 másodperces időtartamként határozza meg a megadott acregmax érték.

Vannak más esetek is, amelyek hasonló csatlakoztatási lehetőségeket hasznosíthatnak, még akkor is, ha az ügyfelek nem élveznek teljes tulajdonjogot, például ha az ügyfelek csak olvasásra használják az adatokat, és az adatfrissítést egy másik útvonalon kezelik. Az olyan alkalmazások esetében, amelyek olyan ügyfélrácsokat használnak, mint az EDA, a web hosting és a film renderelése, és viszonylag statikus adatkészletekkel rendelkeznek (EDA-eszközök vagy tárak, webes tartalom, textúraadatok), a jellemző viselkedés az, hogy az adatkészlet nagyrészt gyorsítótárazva van az ügyfeleken. Kevés olvasási és írási lehetőség van. Sok getattr/access hívás érkezik vissza a tárolóba. Ezek az adatkészletek általában egy másik ügyfélen keresztül frissülnek, amely csatlakoztatja a fájlrendszereket, és rendszeresen leküldi a tartalomfrissítéseket.

Ezekben az esetekben ismert késés tapasztalható az új tartalom felvételében, és az alkalmazás továbbra is működik a potenciálisan elavult adatokkal. Ezekben az esetekben, a nocto és a actimeo használható annak az időszaknak a szabályozására, amikor az elavult adatok kezelhetők. Az EDA-eszközökben és kódtárakban például jól működik, actimeo=600 mert ezek az adatok általában ritkán frissülnek. Az olyan kis méretű webszolgáltatások esetében, ahol az ügyfeleknek időben kell látniuk az adataik frissítését, miközben szerkesztik a webhelyeiket, actimeo=10 elfogadhatóak lehetnek. Az olyan nagyméretű webhelyek esetében, ahol több fájlrendszerbe is leküldéses tartalom található, actimeo=60 elfogadható lehet.

Ezeknek a csatolási beállításoknak a használata jelentősen csökkenti a terhelést a tárolórendszerre ezekben az esetekben. (Például egy közelmúltbeli EDA-élmény csökkentette az IOP-k mennyiségét a szerszámkötetre 150 K-ról >~6 K-ra.) Az alkalmazások jelentősen gyorsabban futhatnak, mert megbízhatnak a memóriában lévő adatokban. (A memória-hozzáférési idő nanoszekundumokban mérhető, szemben a gyors hálózaton való hozzáférés több száz mikroszekundumával getattr.)

Közel-nyitott konzisztencia

A megnyitáshoz közeli konzisztencia (a cto csatlakoztatási beállítás) biztosítja, hogy a gyorsítótár állapotától függetlenül a megnyitáskor a fájl legfrissebb adatai mindig megjelennek az alkalmazás számára.

  • A címtár bejárásakor (lsls -lpéldául) a rendszer bizonyos RPC-ket (távoli eljáráshívásokat) bocsát ki. Az NFS-kiszolgáló megosztja a fájlrendszer nézetét. Mindaddig, amíg cto az adott NFS-exportáláshoz hozzáférő összes NFS-ügyfél használja, minden ügyfél ugyanazt a fájllistát és könyvtárat látja benne. A könyvtárban lévő fájlok attribútumainak frissességét az attribútumgyorsítótár időzítői vezérlik. Más szóval, amíg cto használatban van, a fájlok azonnal megjelennek a távoli ügyfelek számára, amint a fájl létrejön, és a fájl a tárolóba kerül.
  • A fájl megnyitásakor a fájl tartalma az NFS-kiszolgáló szempontjából garantáltan friss. Ha van egy versenyhelyzet, amikor a tartalom még nem fejeződött be az 1. gépről, mielőtt a fájl megnyílik a 2. gépen, akkor a 2. gép csak a szerveren a megnyitás időpontjában elérhető adatokat kapja meg. Ebben az esetben a 2. gép nem kér le több adatot a fájlból, amíg el nem éri az acreg időzítőt, és ismét ellenőrzi a gyorsítótár-koherenciáját a kiszolgálón. Ez a forgatókönyv a 2. gépből származó farok -f használatával figyelhető meg, amikor a fájl még mindig az 1. gépről van megírva.

Nincs lezárás utáni megnyitási konzisztencia

Ha nem használ megnyitáshoz közeli konzisztenciát (nocto), az ügyfél megbízik a fájl és a könyvtár aktuális nézetének frissességében, amíg a gyorsítótárattribútum időzítői nem sérülnek.

  • A címtár bejárásakor (lsls -lpéldául) a rendszer bizonyos RPC-ket (távoli eljáráshívásokat) bocsát ki. Az ügyfél csak akkor ad ki hívást a kiszolgálóhoz a fájlok aktuális listájához, ha a acdir gyorsítótár időzítőjének értéke megsértődött. Ebben az esetben a nemrég létrehozott fájlok és könyvtárak nem jelennek meg. A nemrég eltávolított fájlok és könyvtárak megjelennek.

  • Amikor megnyit egy fájlt, amíg a fájl továbbra is a gyorsítótárban van, a rendszer a gyorsítótárazott tartalmat (ha van ilyen) az NFS-kiszolgálóval való konzisztencia ellenőrzése nélkül adja vissza.

Következő lépések