Az NFS Azure-fájlmegosztások teljesítményének javítása

Ez a cikk azt ismerteti, hogyan javíthatja a hálózati fájlrendszer (NFS) Azure-fájlmegosztások teljesítményét.

A következőkre vonatkozik:

Irányítási modell	Számlázási modell	Médiaréteg	Redundancia	SMB	NFS
Microsoft.Storage	Előre beállított v2	SSD (prémium)	Lokális (LRS)
Microsoft.Storage	Előre beállított v2	SSD (prémium)	Zóna (ZRS)
Microsoft.Storage	Előre beállított v2	HDD (standard)	Lokális (LRS)
Microsoft.Storage	Előre beállított v2	HDD (standard)	Zóna (ZRS)
Microsoft.Storage	Előre beállított v2	HDD (standard)	Geo (GRS)
Microsoft.Storage	Előre beállított v2	HDD (standard)	Geozone (GZRS)
Microsoft.Storage	Előkészített v1	SSD (prémium)	Lokális (LRS)
Microsoft.Storage	Előkészített v1	SSD (prémium)	Zóna (ZRS)
Microsoft.Storage	Fizetés a használat szerint	HDD (standard)	Lokális (LRS)
Microsoft.Storage	Fizetés a használat szerint	HDD (standard)	Zóna (ZRS)
Microsoft.Storage	Fizetés a használat szerint	HDD (standard)	Geo (GRS)
Microsoft.Storage	Fizetés a használat szerint	HDD (standard)	Geozone (GZRS)

Az előre olvasási méret növelése az olvasási átviteli sebesség javítása érdekében

A read_ahead_kb Linux kernelparamétere azt az adatmennyiséget jelöli, amelyet a szekvenciális olvasási művelet során "előre beolvasni" vagy előre be kell olvasni. Az 5.4 előtti Linux kernelverziók az olvasási előre értéket a csatlakoztatott fájlrendszer rsize15-szörösének megfelelő értékre állítják be, amely az olvasási puffer méretének ügyféloldali csatlakoztatási lehetőségét jelöli. Ez elég magasra állítja az előreolvasási értéket az ügyfél szekvenciális olvasási sebességének javításához a legtöbb esetben.

A Linux kernel 5.4-es verziójától kezdve azonban a Linux NFS-ügyfél alapértelmezett read_ahead_kb értéke 128 KiB. Ez a kis érték csökkentheti a nagy fájlok olvasási sebességét. A Nagyobb olvasási értékkel rendelkező Linux-kiadásokról a 128 KiB alapértelmezett kiadásra frissítő ügyfelek a szekvenciális olvasási teljesítmény csökkenését tapasztalhatják.

Az 5.4-s vagy újabb Linux-kernelek esetében javasoljuk, hogy a jobb teljesítmény érdekében folyamatosan állítsa a read_ahead_kb 15 MiB-re.

Az érték módosításához állítsa be a read-ahead méretet egy szabály hozzáadásával az udevben, a Linux kernel eszközkezelőjében. Kövesse az alábbi lépéseket:

1. Szövegszerkesztőben hozza létre az /etc/udev/rules.d/99-nfs.rules fájlt a következő szöveg beírásával és mentésével:

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. A konzolon alkalmazza az udev szabályt az udevadm parancs szuperfelhasználóként való futtatásával és a szabályfájlok és más adatbázisok újratöltésével. Ezt a parancsot csak egyszer kell futtatnia, hogy az udev értesüljön az új fájlról.

   sudo udevadm control --reload
   

NFS nconnect

Az NFS nconnect az NFS-fájlmegosztások ügyféloldali csatlakoztatási lehetősége, amely lehetővé teszi több TCP-kapcsolat használatát az ügyfél és az NFS-fájlmegosztás között.

Előnyök

Az nconnect használatával kisebb ügyfélszámítógépek használatával növelheti a teljesítményt a teljes tulajdonlási költség (TCO) csökkentése érdekében. Az nconnect funkció úgy növeli a teljesítményt, hogy több TCP-csatornát használ egy vagy több hálózati adapteren egy vagy több ügyfél használatával. Nconnect nélkül nagyjából 20 ügyfélgépre lenne szükség a legnagyobb SSD-fájlmegosztás kiépítési mérete által kínált sávszélesség-méretezési korlátok (10 GiB/s) eléréséhez. Az nconnect használatával ezeket a korlátokat csak 6-7 ügyfél használatával érheti el, közel 70% csökkentve a számítási költségeket, miközben jelentős fejlesztéseket tesz lehetővé az I/O-műveletek másodpercenkénti (IOPS) és a nagy léptékű átviteli sebesség terén. Lásd a következő táblázatot.

Mérték (művelet)	I/O-méret	Teljesítménybeli javulás
IOPS (írás)	64 KiB, 1024 KiB	3x
IOPS (olvasási műveletek)	Minden I/O-méret	2-4-szer
Átviteli sebesség (írás)	64 KiB, 1024 KiB	3x
Átviteli sebesség (olvasás)	Minden I/O-méret	2-4-szer

Előfeltételek

• A legújabb Linux-disztribúciók teljes mértékben támogatják az nconnect-et. Régebbi Linux-disztribúciók esetén győződjön meg arról, hogy a Linux kernelverziója 5.3 vagy újabb.
• Csatolásonkénti beállítás csak akkor támogatott, ha egy tárfiókhoz egyetlen fájlmegosztás járul egy privát végponton keresztül.

A teljesítményre gyakorolt hatás

A következő teljesítményeredményeket értünk el, amikor az nconnect csatlakoztatási lehetőséget NFS Azure-fájlmegosztásokkal használjuk Linux-ügyfeleken nagy méretekben. Az eredmények eléréséről további információt a teljesítményteszt konfigurációját ismertető cikkben talál.

Ajánlások

Ahhoz, hogy a legjobb eredményeket érje el a nconnect segítségével, kövesse ezeket az ajánlásokat.

nconnect=4 beállítása

Bár az Azure Files támogatja az nconnect beállítását a 16-os maximális értékre, javasoljuk, hogy konfigurálja a csatlakoztatási beállításokat az nconnect=4 optimális beállításával. Jelenleg az nconnect Azure Files-implementációjának négy csatornán kívül nincs nyeresége. Valójában az egyetlen ügyféltől származó egyetlen Azure-fájlmegosztás négy csatornája túllépése hátrányosan befolyásolhatja a TELJESÍTMÉNYT a TCP-hálózat telítettsége miatt.

Virtuális gépek gondos méretezése

A terhelési követelményektől függően fontos, hogy megfelelően méretezzék az ügyfél virtuális gépeket, hogy elkerüljék a várt hálózati sávszélesség okozta korlátozásokat. A várt hálózati teljesítmény eléréséhez nincs szükség több hálózati adapter-vezérlőre (NIC-re). Bár általános célú virtuális gépek használata az Azure Files használatával gyakori, a számítási feladatok igényeitől és a régió rendelkezésre állásától függően különböző virtuálisgép-típusok érhetők el. További információ: Azure-beli virtuálisgép-választó.

Tartsd a sor mélységet 64-nél kisebb vagy egyenlőért

A várólista mélysége a tárolóerőforrás által kiszolgálható függőben lévő I/O-kérések száma. Nem javasoljuk, hogy az üzenetsor optimális mélységét, a 64-et túllépje, mert nem fog több teljesítményjavulást tapasztalni. További információ: Üzenetsor mélysége.

Csatlakoztatási konfigurációnként

Ha egy számítási feladathoz több megosztást kell csatlakoztatni egy vagy több olyan tárfiókhoz, amelyek eltérő nconnect-beállításokat használnak egyetlen ügyféltől, nem garantálhatjuk, hogy ezek a beállítások megmaradnak a nyilvános végponton való csatlakoztatáskor. Csatlakoztatásonkénti konfiguráció csak akkor támogatott, ha tárfiókonként egyetlen Azure-fájlmegosztást használnak a privát végponton az 1. forgatókönyvben leírtak szerint.

1. Forgatókönyv: Privát végponton keresztüli csatlakoztatási konfigurációnként több tárfiók (támogatott)

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

2. forgatókönyv: csatlakoztatásonkénti konfiguráció nyilvános végponton keresztül (nem támogatott)

• StorageAccount.file.core.windows.net = 52.239.238.8
• StorageAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Megjegyzés:

Még ha a tárfiók egy másik IP-címre is feloldható, nem tudjuk garantálni, hogy a cím megmaradjon, mert a nyilvános végpontok nem statikus címek.

3. forgatókönyv: csatlakoztatásonkénti konfiguráció privát végponton több megosztással egyetlen tárfiókon (nem támogatott)

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Teljesítményteszt konfigurációja

A cikkben ismertetett eredmények eléréséhez és méréséhez az alábbi erőforrásokat és teljesítményértékelési eszközöket használtuk.

• Egyetlen ügyfél: Azure-beli virtuális gép (DSv4-Series) egyetlen hálózati adapterrel
• OPERÁCIÓS RENDSZER: Linux (Ubuntu 20.40)
• NFS-tároló: SSD-fájlmegosztás (kiépített 30 TiB, set nconnect=4)

Méret	vCPU	Emlékezet	Ideiglenes tároló (SSD)	Adatlemezek maximális kihasználása	Maximális hálózati adapterek	Várható hálózati sávszélesség
Standard_D16_v4	16	64 GiB	Csak távoli tárolás	32	8	12 500 Mb/s

Teljesítményértékelési eszközök és tesztek

Rugalmas I/O-tesztelőt (FIO) használtunk, amely egy ingyenes, nyílt forráskódú lemez I/O-eszköz, amelyet a teljesítményteszthez és a stressz/hardver ellenőrzéséhez is használtunk. A FIO telepítéséhez kövesse a FIO README fájl Bináris csomagok szakaszát, és telepítse a kívánt platformra.

Bár ezek a tesztek véletlenszerű I/O-hozzáférési mintákra összpontosítanak, hasonló eredményeket kap a szekvenciális I/O használatakor.

Magas IOPS: 100% olvasási teljesítmény

4k I/O méret – véletlenszerű olvasás – 64 sor mélység

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

8k I/O méret – véletlenszerű olvasás – 64 üzenetsor mélysége

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Magas átviteli sebesség: 100% olvasás

64 KiB I/O-méret – véletlenszerű olvasás – 64 üzenetsor mélysége

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

1 024 KiB I/O-méret – 100% véletlenszerű olvasás – 64 sor mélység

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Magas IOPS: 100% írás

4 KiB I/O méret – 100% véletlenszerű írás – 64 üzenetsor mélysége

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

8 KiB I/O-méret – 100% véletlenszerű írás – 64 üzenetsor mélysége

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Nagy áteresztőképesség: 100% írás

64 KiB I/O-méret – 100% véletlenszerű írás – 64 sor mélység

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

1024 KiB I/O méret – 100% véletlenszerű írás – 64 sor mélysége

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Teljesítménnyel kapcsolatos szempontok a következőhöz: nconnect

A csatlakoztatási nconnect beállítás használatakor alaposan ki kell értékelnie azokat a számítási feladatokat, amelyek a következő jellemzőkkel rendelkeznek:

• Késésre érzékeny írási számítási feladatok, amelyek egyszálasak és/vagy alacsony várólista-mélységet használnak (kevesebb, mint 16)
• Késésre érzékeny olvasási számítási feladatok, amelyek egyszálasak, és/vagy alacsony üzenetsor-mélységet használnak kisebb I/O-méretekkel kombinálva

Nem minden számítási feladat igényel nagy léptékű IOPS-t vagy teljes teljesítményt. A kisebb méretű számítási feladatok esetében lehet, nconnect hogy nincs értelme. Az alábbi táblázat segítségével döntse el, hogy előnyös-e nconnect a számítási feladat számára. A zöld színnel kiemelt forgatókönyvek használata ajánlott, míg a piros színnel kiemelt forgatókönyvek nem. A sárga színnel kiemelt forgatókönyvek semlegesek.

Lásd még

• NFS-fájlmegosztás csatlakoztatása Linuxhoz
• Csatlakoztatási beállítások listája
• Az Azure Files teljesítményének ismertetése