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

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

  • Cikk

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őre érvényes:

Fájlmegosztás típusa SMB NFS
Standard szintű fájlmegosztások (GPv2), LRS/ZRS Nem, ez a cikk nem vonatkozik az LRS/ZRS standard SMB Azure-fájlmegosztásokra. Az NFS-megosztások csak prémium Szintű Azure-fájlmegosztásokban érhetők el.
Standard szintű fájlmegosztások (GPv2), GRS/GZRS Nem, ez a cikk nem vonatkozik a standard SMB Azure-fájlmegosztásokra GRS/GZRS. Az NFS csak prémium Szintű Azure-fájlmegosztásokban érhető el.
Prémium fájlmegosztások (FileStorage), LRS/ZRS Nem, ez a cikk nem vonatkozik a prémium szintű SMB Azure-fájlmegosztásokra. Igen, ez a cikk a prémium szintű NFS Azure-fájlmegosztásokra vonatkozik.

Olvasási sebesség növelése az olvasási 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ítson be egy szabályt az udev linuxos kerneleszköz-kezelőben. Tegye a következők egyikét:

  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

Nconnect

Nconnect egy ügyféloldali Linux-csatlakoztatási lehetőség, amely nagy léptékben növeli a teljesítményt azáltal, hogy lehetővé teszi az ügyfél és az NFSv4.1-hez készült Azure Premium Files szolgáltatás közötti több Átviteli vezérlési protokoll (TCP) kapcsolat használatát.

A nconnect

Ezzel nconnectskálázhatóan növelheti a teljesítményt kevesebb ügyfélszámítógép használatával a teljes tulajdonosi költség (TCO) csökkentése érdekében. Nconnect több TCP-csatorna használatával növeli a teljesítményt egy vagy több hálózati adapteren, egy vagy több ügyfél használatával. E nélkül nconnectkörülbelül 20 ügyfélgépre lenne szüksége a legnagyobb prémium szintű Azure-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. Ezzel nconnectcsak 6–7 ügyféllel érheti el ezeket a korlátokat, közel 70%-kal csökkentve a számítási költségeket, miközben jelentős fejlesztéseket tesz lehetővé a másodpercenkénti I/O-műveletekben (IOPS) és a nagy léptékű átviteli sebességben. Lásd az alábbi táblázatot.

Metrika (művelet) I/O-méret Teljesítménybeli javulás
IOPS (írás) 64K, 1024K 3x
IOPS (olvasás) Minden I/O-méret 2-4x
Átviteli sebesség (írás) 64K, 1024K 3x
Átviteli sebesség (olvasás) Minden I/O-méret 2-4x

Előfeltételek

  • A legújabb Linux-disztribúciók teljes mértékben támogatják nconnect. Régebbi Linux-disztribúciók esetén győződjön meg arról, hogy a Linux kernelverziója 5.3 vagy újabb.
  • Csatlakoztatásonkénti konfiguráció csak akkor támogatott, ha tárfiókonként egyetlen fájlmegosztást használ egy privát végponton keresztül.

A teljesítményre gyakorolt hatás nconnect

A következő teljesítményeredményeket értünk el, amikor a csatlakoztatási nconnect 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.

Az NFS Azure-fájlmegosztásokkal való nconnect használatakor az IOPS átlagos javulását bemutató képernyőkép.

Az NFS Azure-fájlmegosztásokkal való nconnect használatakor az átviteli sebesség átlagos javulását bemutató képernyőkép.

Javaslatok a következőhöz: nconnect

Kövesse ezeket a javaslatokat a legjobb eredmények nconnecteléréséhez.

Beállít nconnect=4

Bár az Azure Files támogatja nconnect a legfeljebb 16 beállítás beállítását, javasoljuk, hogy a csatlakoztatási beállításokat az optimális beállítással konfigurálja nconnect=4. Az Azure Files implementációjának jelenleg négy csatornán túl nincs nyeresége nconnect. 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 számítási feladatokra vonatkozó követelményektől függően fontos, hogy megfelelően méretezzék az ügyfél virtuális gépeket (virtuális gépeket), hogy ne korlátozzák a várt hálózati sávszélességet. 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ó.

Az üzenetsor mélységének megtartva 64-nél kisebb vagy egyenlő

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 túllépje a 64-et az optimális üzenetsormélységen, mert nem fog több teljesítménynövekedést látni. További információ: Üzenetsor mélysége.

Nconnect csatlakoztatásonkénti konfiguráció

Ha egy számítási feladathoz több megosztást kell csatlakoztatni egy vagy több, egyetlen ügyféltől eltérő nconnect beállításokkal rendelkező tárfiókkal, nem tudjuk garantálni, 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: nconnect Csatlakoztatásonkénti konfiguráció több tárfiókkal rendelkező privát végponton (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: nconnect 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

Feljegyzés

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

3. forgatókönyv: nconnect 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ó: Prémium szintű Azure Files-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%-os olvasás

4k 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=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%-os olvasás

64k 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

1024k I/O méret – 100%-os véletlenszerű olvasás – 64 üzenetsor mélysége

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%-os írás

4k I/O méret – 100%-os 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

8k I/O méret – 100%-os 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

Magas átviteli sebesség: 100%-os írási sebesség

64k I/O méret – 100%-os véletlenszerű írá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=randwrite --group_reporting --ramp_time=300

1024k I/O méret – 100%-os véletlenszerű írás – 64 üzenetsor 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.

Képernyőkép a különböző olvasási és írási I O-forgatókönyvekről, amelyek megfelelő késéssel jelzik, hogy mikor javasolt az nconnect használata.

Lásd még