Ajánlott linuxos párhuzamossági eljárások az Azure NetApp Fileshoz – Munkamenet-pontok és ponttáblázat-bejegyzések
Ez a cikk segít megérteni az Azure NetApp Files NFS protokoll munkamenet-pontokra és ponttáblázat-bejegyzésekre vonatkozó ajánlott eljárásait.
NFSv3
Az NFSv3 nem rendelkezik az ügyfél és a kiszolgáló közötti egyidejűség egyeztetésére szolgáló mechanizmussal. Az ügyfél és a kiszolgáló a másik megkérdezése nélkül határozza meg a korlátot. A legjobb teljesítmény érdekében fel kell sorakoznia az ügyféloldali sunrpc ponttáblázatok maximális számának a kiszolgálóra való visszaküldés nélkül támogatott bejegyzéseinek számával. Ha egy ügyfél túlterheli a kiszolgáló hálózati vermének a számítási feladatok feldolgozását, a kiszolgáló úgy válaszol, hogy csökkenti a kapcsolat ablakméretét, ami nem ideális teljesítményforgatókönyv.
A modern Linux-kernelek alapértelmezés szerint 65 536 kiemelkedő művelet támogatásaként határozzák meg a kapcsolati sunrpc pontonkénti táblabejegyzés méretét sunrpc.tcp_max_slot_table_entries , ahogyan az az alábbi táblázatban látható.
| Azure NetApp Files NFSv3-kiszolgáló Kapcsolatonkénti végrehajtási környezetek maximális száma |
Linux-ügyfél Alapértelmezett maximális sunrpc ponttáblázat-bejegyzések kapcsolatonként |
|---|---|
| 128 | 65,536 |
Ezek a ponttáblázat-bejegyzések határozzák meg az egyidejűség korlátait. Az ilyen magas értékek szükségtelenek. Például a Littles Law nevű üzenetsor-kezelési elmélettel azt fogja tapasztalni, hogy az I/O-arányt az egyidejűség (azaz a kiemelkedő I/O) és a késés határozza meg. Az algoritmus így azt bizonyítja, hogy 65 536 tárolóhely nagyságrendekkel nagyobb, mint ami a rendkívül nagy terhelésű számítási feladatok futtatásához szükséges.
Littles Law: (concurrency = operation rate × latency in seconds)
A 155-ösnél alacsonyabb egyidejűségi szint elegendő másodpercenként 155 000 Oracle DB NFS-művelet eléréséhez az Oracle Direct NFS használatával, amely a csatlakoztatási lehetőséghez nconnect hasonló technológia:
- A 0,5 ms-os késést figyelembe véve 110 000 IOPS eléréséhez 55 egyidejűség szükséges.
- Az 1 ms-os késést figyelembe véve 155 egyidejűség szükséges a 155 000 IOPS eléréséhez.
Részletekért tekintse meg az Oracle-adatbázis teljesítményét az Azure NetApp Files önálló köteteinél .
A sunrpc.tcp_max_slot_table_entries hangolható egy kapcsolatszintű hangolási paraméter. Ajánlott eljárásként állítsa ezt az értéket kapcsolatonként 128-ra vagy annál kevesebbre, és ne haladja meg a 10 000 tárolóhelyet a környezet egészében.
Példák a pontszámra az egyidejűségi javaslat alapján
Az ebben a szakaszban szereplő példák az egyidejűségi javaslat alapján szemléltetik a pontok számát.
1. példa – Egy NFS-ügyfél, 65 536 sunrpc.tcp_max_slot_table_entriesés nem nconnect a kiszolgálóoldali 128-ra vonatkozó maximális egyidejűséghez
Az 1. példa egyetlen ügyfélfeladaton alapul, amelynek alapértelmezett sunrpc.tcp_max_slot_table_entry értéke 65 536, és egyetlen hálózati kapcsolat, azaz nem nconnect. Ebben az esetben 128 egyidejűség érhető el.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)- Az ügyfél elméletileg legfeljebb 65 536 kérést tud kiadni a kiszolgálóra való repülés során kapcsolatonként.
- A kiszolgáló legfeljebb 128 kérést fogad el az egyetlen kapcsolatról való repülés során.
2. példa – Egy NFS-ügyfél, 128 sunrpc.tcp_max_slot_table_entriesés nem nconnect egy 128-ás maximális egyidejűség esetén
A 2. példa egyetlen, 128 értékű ügyfél-számítási feladaton sunrpc.tcp_max_slot_table_entry alapul, de a csatlakoztatási nconnect lehetőség nélkül. Ezzel a beállítással egyetlen hálózati kapcsolatból 128-at lehet egyidejűleg elérni.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)- Az ügyfél kapcsolatonként legfeljebb 128 kérést ad ki a kiszolgálóra való repülés során.
- A kiszolgáló legfeljebb 128 kérést fogad el az egyetlen kapcsolatról való repülés során.
3. példa – Egy NFS-ügyfél, 100 sunrpc.tcp_max_slot_table_entries, és nconnect=8 legfeljebb 800 egyidejűség esetén
A 3. példa egyetlen ügyfél-számítási feladaton alapul, de 100-zal alacsonyabb sunrpc.tcp_max_slot_table_entry értékkel. Ezúttal a csatlakoztatási nconnect=8 lehetőség a számítási feladat 8 kapcsolaton keresztüli elosztását használta. Ezzel a beállítással 800 egyidejűség érhető el a 8 kapcsolat között. Ez az összeg a 400 000 IOPS eléréséhez szükséges egyidejűség.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP), Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)… Connection 8 (10.10.10.10:2049, 10.10.10.11:7321,TCP)- Csatlakozás ion 1
- Az ügyfél legfeljebb 100 kérést ad ki a kiszolgálóra való repülés során ebből a kapcsolatból.
- A kiszolgáló várhatóan legfeljebb 128 kérést fogad el az ügyféltől a kapcsolathoz.
- Csatlakozás ion 2
- Az ügyfél legfeljebb 100 kérést ad ki a kiszolgálóra való repülés során ebből a kapcsolatból.
- A kiszolgáló várhatóan legfeljebb 128 kérést fogad el az ügyféltől a kapcsolathoz.
……- Csatlakozás ion 8
- Az ügyfél legfeljebb 100 kérést ad ki a kiszolgálóra való repülés során ebből a kapcsolatból.
- A kiszolgáló várhatóan legfeljebb 128 kérést fogad el az ügyféltől a kapcsolathoz.
4– 250 NFS-ügyfél, 8 sunrpc.tcp_max_slot_table_entriesés nem nconnect , legfeljebb 2000 egyidejűség esetén
A 4. példa egy 250 gépszámú EDA-környezetben a 8-ra csökkentett ügyfélértéket sunrpc.tcp_max_slot_table_entry használja. Ebben a forgatókönyvben a 2000-re vonatkozó egyidejűség környezeti szintű lesz, ami több mint elegendő ahhoz, hogy egy háttérbeli EDA-számítási feladat 4000 MiB/s-jét vezesse.
NFS_Server=10.10.10.10, NFS_Client1=10.10.10.11Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)- Az ügyfél kapcsolatonként legfeljebb 8 kérést ad ki a kiszolgálóra való repülés során.
- A kiszolgáló legfeljebb 128 kérést fogad el az egyetlen kapcsolatról való repülés során.
NFS_Server=10.10.10.10, NFS_Client2=10.10.10.12Connection (10.10.10.10:2049, 10.10.10.12:7820,TCP)- Az ügyfél kapcsolatonként legfeljebb 8 kérést ad ki a kiszolgálóra való repülés során.
- A kiszolgáló legfeljebb 128 kérést fogad el az egyetlen kapcsolatról való repülés során.
……NFS_Server=10.10.10.10, NFS_Client250=10.10.11.13Connection (10.10.10.10:2049, 10.10.11.13:4320,TCP)- Az ügyfél kapcsolatonként legfeljebb 8 kérést ad ki a kiszolgálóra való repülés során.
- A kiszolgáló legfeljebb 128 kérést fogad el az egyetlen kapcsolatról való repülés során.
Az NFSv3 használatakor a tárvégpontok számát együttesen 10 000 vagy annál kevesebbre kell tartania. A legjobb, ha a kapcsolatonkénti értéket 128-nál kisebb értékre sunrpc.tcp_max_slot_table_entries állítja be, ha egy alkalmazás több hálózati kapcsolaton (nconnect és általában a HPC-n, és különösen az EDA-n) skálázódik.
A legjobb számítás sunrpc.tcp_max_slot_table_entries
A Littles Law használatával kiszámíthatja a szükséges ponttáblázatok teljes bejegyzésszámát. Általában vegye figyelembe a következő tényezőket:
- A vertikálisan felskálázott számítási feladatok gyakran dominánsan nagy szekvenciális jellegűek.
- Az adatbázis-számítási feladatok, különösen az OLTP, gyakran véletlenszerű jellegűek.
Az alábbi táblázat egy mintatanulmányt mutat be az egyidejűségről tetszőleges késésekkel:
| I/O-méret | Késés | I/O vagy átviteli sebesség | Egyidejűség |
|---|---|---|---|
| 8 KiB | 0,5 ms | 110 000 IOPS | 859 MiB/s | 55 |
| 8 KiB | 2 ms | 400 000 IOPS | 3,125 MiB/s | 800 |
| 256 KiB | 2 ms | 16 000 IOPS | 4000 MiB/s | 32 |
| 256 KiB | 4 ms | 32 000 IOPS | 8000 MiB/s | 128 |
Egyidejűségi beállítások kiszámítása kapcsolatszám alapján
Ha például a számítási feladat egy EDA-farm, és 1250 ügyfél mindegyike ugyanarra a tárolási végpontra hajtja a számítási feladatot (a tárolási végpont egy tárolási IP-cím), akkor kiszámítja a szükséges I/O-sebességet, és elosztja az egyidejűséget a farmon.
Tegyük fel, hogy a számítási feladat 4000 MiB/s, amely 256 KiB átlagos műveletméretet és 10 ms átlagos késést használ. Az egyidejűség kiszámításához használja a következő képletet:
(concurrency = operation rate × latency in seconds)
A számítás a 160-ból álló egyidejűséget jelenti:
(160 = 16,000 × 0.010)
Mivel 1250 ügyfélre van szükség, biztonságosan beállíthatja sunrpc.tcp_max_slot_table_entries , hogy ügyfelenként 2 legyen, hogy elérje a 4000 MiB/s-t. Azonban úgy is dönthet, hogy extra fejtérbe épít, ha az ügyfélenkénti számot 4-es vagy akár 8-ra állítja, és jól tartja magát a 10 000 javasolt ponthatár alatt.
Beállítás sunrpc.tcp_max_slot_table_entries az ügyfélen
- Adja hozzá
sunrpc.tcp_max_slot_table_entries=<n>a/etc/sysctl.confkonfigurációs fájlhoz.
A hangolás során, ha a 128-nál kisebb érték található optimálisnak, cserélje le a 128-at a megfelelő számra. - Futtassa az alábbi parancsot:
$ sysctl -p - Csatlakoztassa (vagy szerelje újra) az összes NFS fájlrendszert, mivel a hangjelzés csak a hangjelzés beállítása után készített csatlakoztatásokra vonatkozik.
NFSv4.1
Az NFSv4.1-ben a munkamenetek határozzák meg az ügyfél és a kiszolgáló közötti kapcsolatot. Függetlenül attól, hogy a csatlakoztatott NFS-fájlrendszerek egy kapcsolaton vagy többen ülnek-e (ahogy a példában nconnectis), a munkamenetre vonatkozó szabályok érvényesek. A munkamenet beállításakor az ügyfél és a kiszolgáló egyezteti a munkamenetre vonatkozó maximális kéréseket, és a két támogatott érték közül az alacsonyabbra települ. Az Azure NetApp Files 180 függőben lévő kérést támogat, a Linux-ügyfelek pedig alapértelmezés szerint 64-et. Az alábbi táblázat a munkamenet korlátait mutatja be:
| Azure NetApp Files NFSv4.1 kiszolgáló Munkamenetenkénti parancsok maximális száma |
Linux-ügyfél Alapértelmezett maximális parancsok munkamenetenként |
Egyeztetett maximális parancsok a munkamenethez |
|---|---|---|
| 180 | 64 | 64 |
Bár a Linux-ügyfelek alapértelmezés szerint munkamenetenként legfeljebb 64 kérést kérnek, az érték max_session_slots nem érhető el. A módosítások érvénybe lépéséhez újraindításra van szükség. systool -v -m nfs A parancs használatával megtekintheti az ügyfél által használt aktuális maximális értékeket. A parancs működéséhez legalább egy NFSv4.1-csatlakoztatásnak a helyén kell lennie:
$ systool -v -m nfs
{
Module = "nfs"
...
Parameters:
...
max_session_slots = "64"
...
}
A hangoláshoz max_session_slotshozzon létre egy konfigurációs fájlt /etc/modprobe.d a következőképpen. Győződjön meg arról, hogy nincsenek "idézőjelek" a fájl sorához. Ellenkező esetben a beállítás nem lép érvénybe.
$ sudo echo “options nfs max_session_slots=180” > /etc/modprobe.d/nfsclient.conf
$ sudo reboot
Az Azure NetApp Files az egyes munkameneteket legfeljebb 180 parancsra korlátozza. Ezért fontolja meg a jelenleg konfigurálható maximális érték 180-at. Az ügyfél nem fog tudni 128-nál nagyobb egyidejűséget elérni, kivéve, ha a munkamenet több kapcsolatra van osztva, mivel az Azure NetApp Files az egyes kapcsolatokat legfeljebb 128 NFS-parancsra korlátozza. Egynél több kapcsolat beszerzéséhez ajánlott a nconnect csatlakoztatási lehetőség, és két vagy több értékre van szükség.
Példák a várt egyidejűségi maximumokra
Az ebben a szakaszban szereplő példák az egyidejűség várható maximumait mutatják be.
1– 64 max_session_slots . példa és nem nconnect
Az 1. példa a 64 max_session_slots - és a nem nconnectérték alapértelmezett beállításán alapul. Ezzel a beállítással a 64-et egyidejűleg lehet elérni, mindezt egyetlen hálózati kapcsolatból.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)- Az ügyfél legfeljebb 64 kérést ad ki a kiszolgálóra való repülés során a munkamenethez.
- A kiszolgáló legfeljebb 64 kérést fogad el az ügyféltől a munkamenetre vonatkozóan. (A 64 a tárgyalásos érték.)
2– 64 max_session_slots . példa és nconnect=2
A 2. példa a max session_slots . 64-en alapul, de a hozzá tartozó csatlakoztatási nconnect=2lehetőséggel. A 64-es egyidejűség elérhető, de két kapcsolatra van osztva. Bár ebben a forgatókönyvben több kapcsolat sem jár nagyobb egyidejűséggel, a kapcsolatonkénti várólista-mélység csökkenése pozitív hatással van a késésre.
max_session_slots A továbbra is 64-es, de nconnect=2figyelje meg, hogy a kérelmek maximális száma a kapcsolatok között oszlik el.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)- Csatlakozás ion 1
- Az ügyfél legfeljebb 32 kérést ad ki a kiszolgálóra való repülés során ebből a kapcsolatból.
- A kiszolgáló várhatóan legfeljebb 32 kérést fogad el az ügyféltől a kapcsolatra vonatkozóan.
- Csatlakozás ion 2
- Az ügyfél legfeljebb 32 kérést ad ki a kiszolgálóra való repülés során ebből a kapcsolatból.
- A kiszolgáló várhatóan legfeljebb 32 kérést fogad el az ügyféltől a kapcsolatra vonatkozóan.
3– 180 max_session_slots . példa és nem nconnect
A 3. példa elveti a nconnect csatlakoztatási beállítást, és a max_session_slots kiszolgáló maximális NFSv4.1 munkamenet-egyidejűségének megfelelő értékre állítja az értéket 180-ra. Ebben a forgatókönyvben, ha csak egy kapcsolat van, és az Azure NetApp Files 128 maximális, NFS-kapcsolatonkénti kiemelkedő művelettel rendelkezik, a munkamenet legfeljebb 128 műveletre korlátozódik a repülés során.
Bár max_session_slots 180-ra van beállítva, az egyetlen hálózati kapcsolat legfeljebb 128 kérésre korlátozódik:
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)- Az ügyfél legfeljebb 180 kérést ad ki a kiszolgálóra való repülés során a munkamenethez.
- A kiszolgáló legfeljebb 180 kérést fogad el az ügyféltől a munkamenetre vonatkozóan.
- A kiszolgáló legfeljebb 128 kérést fogad el repülés közben az egyetlen kapcsolatra vonatkozóan.
4– 180 max_session_slots . példa és nconnect=2
A 4. példa hozzáadja a nconnect=2 csatlakoztatási lehetőséget, és újra felhasználja a 180-at max_session_slots . Mivel a teljes számítási feladat két kapcsolatra van osztva, 180 kiemelkedő művelet érhető el.
Ha két kapcsolat van folyamatban, a munkamenet 180 folyamatban lévő kérés teljes kiosztását támogatja.
NFS_Server=10.10.10.10, NFS_Client=10.10.10.11Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)- Csatlakozás ion 1
- Az ügyfélnek várhatóan legfeljebb 90 kérést kell fenntartania a kiszolgálóra való repülés során az első kapcsolatról.
- A kiszolgáló várhatóan legfeljebb 90 kérést tart fenn az ügyféltől a kapcsolathoz a munkameneten belül.
- Csatlakozás ion 2
- Az ügyfélnek várhatóan legfeljebb 90 kérést kell fenntartania a kiszolgálóra való repülés során az első kapcsolatról.
- A kiszolgáló várhatóan legfeljebb 90 kérést tart fenn az ügyféltől a kapcsolathoz a munkameneten belül.
Feljegyzés
A maximális egyidejűséghez állítsa be max_session_slots a 180-at, amely az Azure NetApp Files által jelenleg támogatott maximális munkamenetszintű egyidejűség.
A munkamenetre vonatkozó maximális függőben lévő kérések ellenőrzése
Az ügyfél és a session_slot kiszolgáló által támogatott méretek megtekintéséhez rögzítse a csatlakoztatási parancsot egy csomagkövetésben. Keresse meg a hívást és CREATE_SESSION a CREATE_SESSION választ az alábbi példában látható módon. A hívás az ügyféltől származik, a válasz pedig a kiszolgálótól származik.
A csatlakoztatási parancs rögzítéséhez használja a következő tcpdump parancsot:
$ tcpdump -i eth0 -s 900 -w /tmp/write.trc port 2049
A Wireshark használatával az érdeklődési körök a következők:
Ebben a két csomagban tekintse meg a max_reqs nyomkövetési fájl középső szakaszában lévő mezőt.
- Hálózati fájlrendszer
- Műveletek
Opcodecsa_fore_channel_attrsmax reqs
- Műveletek
A 12. csomag (az ügyfél maximális kérései) azt mutatja, hogy az ügyfél értéke 64 volt max_session_slots . A következő szakaszban figyelje meg, hogy a kiszolgáló 180-at támogat a munkamenethez. A munkamenet végül a két megadott érték közül az alsóbbrendűt tárgyalja.
Az alábbi példában a 14. csomag látható (a kiszolgáló maximális kérései):
Következő lépések
- Ajánlott eljárások a Linux közvetlen I/O-hoz az Azure NetApp Fileshoz
- Ajánlott eljárások linuxos fájlrendszer-gyorsítótárazáshoz az Azure NetApp Fileshoz
- A Linux NFS csatlakoztatási beállításainak ajánlott eljárásai az Azure NetApp Fileshoz
- Ajánlott eljárások a Linux NFS írásvédett használatához
- Azure-beli virtuálisgép-termékváltozatok – ajánlott eljárások
- Teljesítménytesztek Linuxhoz
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: