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

  • Cikk

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és a legmegmunkálóbbnak bizonyult nconnect=8 .

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

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)
    Redhat 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 használja. 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: nconnect az első csatlakoztatás nem használja. Ezért ugyanahhoz a végponthoz nem lehet csatlakoztatást használni nconnect , annak ellenére nconnect , hogy ott meg lehet adni.

    • 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 használja a csatlakoztatás érkező 10.10.10.10 , de nem a mount érkező 10.12.12.12.

    • 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 a beállítások együttes használata nconnect és sec=krb5* csatlakoztatása. A teljesítménycsökkenést a két lehetőség együttes használata esetén figyelték meg.

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 beállításban lévő nconnect csomagok nagyobb száma gyakori, ablakon kívüli csomagokat okoz, ami aktiválja 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ényeinek megfelelően módosítania kell a módosításokat.

A rsize és wsize a jelzők egy NFS-művelet maximális átviteli méretét állítják be. wsize Ha rsize nincs megadva a csatlakoztatáskor, 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 wsize nem nagyobb beállítást rsize javasol. Megfigyelheti, hogy mind a nagyobb késés, mind a csökkent átviteli sebesség 256 KiB-nél nagyobb használat rsize wsize esetén.

Ha például üzembe helyez egy SAP HANA kibővített rendszert készenléti csomóponttal az Azure-beli virtuális gépeken az Azure NetApp Files SUSE Linux Enterprise Serveren való használatával, a 256 KiB-t rsize és wsize a maximumot mutatja az alábbiak szerint:

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, a SAS GRID pedig 64 KiB-re korlátozza a r/wsize méretet, miközben növeli az olvasási teljesítményt az NFS-csatlakoztatások esetében. 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 csatlakoztatási és wsize csatlakoztatási rsize beállítások. Ezért ezek nem kényszerek.
  • A fájlrendszer-gyorsítótár használatakor a szekvenciális I/O az és wsize a rsize 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 és wsize.
  • A fájlrendszer-gyorsítótárat megkerülő műveletek, bár továbbra is korlátozzák a rsize csatlakoztatási wsize lehetőségeket, nem olyan nagyok, mint a megadott rsize vagy wsizea . 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, hogy a lehető legjobb teljesítményt és késést nyújtsa, és rsize wsize ne legyen nagyobb, mint 262 144 bájt.

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 minden alkalommal le kell ké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 actimeo pedig további 20-25%-getattrkal 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ályozza a gyorsítótár áhítottságá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. maxA rendszer min egy algoritmussal határozza meg, hogy mennyi idő alatt legyen megbízható a gyorsítótárazott bejegyzés.

Vegyük például az alapértelmezett acregmin és acregmax a 30 másodperces értékeket. 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ág 30 másodperc a megadott acregmaxérték.

Vannak más esetek is, amelyek hasonló csatlakoztatási lehetőségeket használhatnak, még akkor is, ha az ügyfelek nem teljes tulajdonjogot élveznek, például ha az ügyfelek írásvédettként 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, és actimeo használható annak az időszaknak a szabályozására, nocto ahol az adaton kívüli dátum kezelhető. 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 csatlakoztatási lehetőségeknek a használata jelentősen csökkenti a számítási feladatot a tárolásra 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ő nanoszekundumok és több száz mikroszekundum a gyors hálózaton való hozzáféréshez getattr.)

Nyitott konzisztencia közelről

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 versenyfeltétel, amely miatt a tartalom nem fejeződött be az 1. gépről a 2. gépen megnyitott fájl megnyitásakor, a 2. gép csak a megnyitás időpontjában fogadja a kiszolgálón található adatokat. 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 a 2. gép ismét ellenőrzi a gyorsítótár-mosóképességét a kiszolgálóról. 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 nyitott 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