Az Azure NetApp Files rendszeres mennyiségi teljesítménymutatói Linuxhoz

Ez a cikk az Azure NetApp Files linuxos, normál kötettel nyújtott teljesítménymutatóit ismerteti.

Teljes fájlstreamelési számítási feladatok (vertikális felskálázási teljesítménytesztek)

A horizontális felskálázási teszt célja egy Azure NetApp-fájlkötet teljesítményének megjelenítése az egyidejű számítási feladatot ugyanazon kötetre létrehozó ügyfelek számának horizontális felskálázása (vagy növelése) során. Ezek a tesztek általában képesek egy kötetet a teljesítménykorlátok peremére küldeni, és olyan számítási feladatokra utalnak, mint a médiamegjelenítés, az AI/ML és más számítási feladatok, amelyek nagy számítási farmokat használnak a munka elvégzéséhez.

Magas I/OP-skálázási teljesítményteszt konfigurálása

Ezek a teljesítménymutatók a következőket használták:

• Egyetlen Azure NetApp Files 100-TiB normál kötet 1 TiB-adatkészlettel az Ultra teljesítményszint használatával
• FIO (a randrepeat=0 beállítással és anélkül)
• 4-KiB és 8 KiB blokkméretek
• 6 D32s_v5 RHEL 9.3-at futtató virtuális gépek
• NFSv3
• Manuális QoS
• Csatlakoztatási lehetőségek: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Nagy átviteli sebességű vertikális felskálázási teljesítményteszt konfigurációja

Ezek a teljesítménymutatók a következőket használták:

• Egyetlen Normál Azure NetApp Files-kötet 1 TiB-adatkészlettel az Ultra teljesítményszint fiO használatával (a randrepeat=0 beállítással és anélkül)
• FIO (a randrepeat=0 beállítással és anélkül)
• 64 KiB és 256 KiB blokkméret
• 6 D32s_v5 RHEL 9.3-at futtató virtuális gépek
• NFSv3
• Manuális QoS
• Csatlakoztatási lehetőségek: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Párhuzamos hálózati kapcsolat (nconnect) benchmark konfigurációja

Ezek a teljesítménymutatók a következőket használták:

• Egyetlen Normál Azure NetApp Files-kötet 1 TiB-adatkészlettel az Ultra teljesítményszint használatával
• FIO (a randrepeat=0 beállítással és anélkül)
• 4-KiB és 64-KiB wsize/rsize
• Egyetlen D32s_v4 RHEL 9.3-at futtató virtuális gép
• NFSv3 with and without nconnect
• Csatlakoztatási lehetőségek: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Vertikális felskálázási teljesítménytesztek

A vertikális felskálázási teszt célja egy Azure NetApp-fájlkötet teljesítményének megjelenítése, amikor felskálázza (vagy növeli) azon feladatok számát, amelyek egyszerre több TCP-kapcsolaton keresztül hoznak létre egyszerre több TCP-kapcsolatot ugyanazon a köteten (például a ).nconnect

Nélkülük nconnectezek a számítási feladatok nem tudják leküldeni a kötet maximális teljesítményének korlátait, mivel az ügyfél nem tud elegendő IO- vagy hálózati átviteli sebességet generálni. Ezek a tesztek általában azt jelzik, hogy egy felhasználó milyen felhasználói élményt érhet el olyan számítási feladatokban, mint a médialeképezés, az adatbázisok, az AI/ML és az általános fájlmegosztások.

Magas I/OP-skálázási teljesítménymutatók

Az alábbi teljesítménymutatók a magas I/OP-számítási feladatokkal rendelkező Azure NetApp Files esetében elért teljesítményt mutatják be:

• 32 ügyfél
• 4-KiB és 8-KiB véletlenszerű olvasások és írások
• 1 TiB adatkészlet
• Olvasási/írási arányok az alábbiak szerint: 100%:0%, 90%:10%, 80%:20% stb.
• Fájlrendszer-gyorsítótárazással és anélkül (a FIO használatával randrepeat=0 )

További információ: Tesztelési módszertan.

Eredmények: 4 KiB, véletlenszerű, ügyfél gyorsítótárazása is

Ebben a teljesítménytesztben a FIO anélkül futott, hogy lehetőség volt az randrepeat adatok véletlenszerűsítésére. Így meghatározhatatlan mennyiségű gyorsítótárazás került a játékba. Ez a konfiguráció valamivel jobb általános teljesítményszámokat eredményez, mint a tesztek, amelyek gyorsítótárazás nélkül futnak a teljes IO-verem használatával.

A következő grafikonon a tesztelés azt mutatja, hogy az Azure NetApp Files normál kötete körülbelül 130 000 tiszta véletlenszerű 4 KiB-írás és körülbelül 460 000 tiszta véletlenszerű 4 KiB-olvasás között képes kezelni a teljesítményteszt során. Olvasási-írási mix a számítási feladathoz 10%-kal módosítva minden futtatáshoz.

Ahogy az írási-írási I/OP-mix az írási terhelés felé nő, a teljes I/OPS csökken.

Eredmények: 4 KiB, véletlenszerű, ügyfél gyorsítótárazása kizárt

Ebben a teljesítménytesztben a FIO az adatok véletlenszerűsítésére szolgáló beállítással randrepeat=0 lett futtatva, csökkentve a teljesítményre gyakorolt gyorsítótárazási hatást. Ez körülbelül 8%-os csökkenést eredményezett az írási I/OPS-ben, és körülbelül 17%-kal csökkentette az olvasási I/OPS-t, de a teljesítményszámokat jobban reprezentatívan jeleníti meg, hogy a tároló valójában mire képes.

A következő grafikonon a tesztelés azt mutatja, hogy az Azure NetApp Files normál kötete körülbelül 120 000 tiszta véletlenszerű 4 KiB-írás és körülbelül 388 000 tiszta véletlenszerű 4 KiB-olvasás között képes kezelni. Olvasási-írási mix a számítási feladathoz 25%-kal módosítva minden futtatáshoz.

Ahogy az írási-írási I/OP-mix az írási terhelés felé nő, a teljes I/OPS csökken.

Eredmények: 8 KiB, véletlenszerű, ügyfél gyorsítótárazása kizárt

A nagyobb olvasási és írási méretek kevesebb I/OPS-t eredményeznek, mivel minden művelettel több adat küldhető el. A 8 KiB-s olvasási és írási méret pontosabban szimulálta a legtöbb modern alkalmazást. Sok EDA-alkalmazás például 8 KiB olvasást és írást használ.

Ebben a teljesítménytesztben a FIO az adatok véletlenszerűsítésére randrepeat=0 futott, így az ügyfél gyorsítótárazási hatása csökkent. A következő grafikonon a tesztelés azt mutatja, hogy az Azure NetApp Files normál kötete körülbelül 111 000 tiszta véletlenszerű 8 KiB-írás és körülbelül 293 000 tiszta véletlenszerű 8 KiB-olvasás között képes kezelni. Olvasási-írási mix a számítási feladathoz 25%-kal módosítva minden futtatáshoz.

Ahogy az írási-írási I/OP-mix az írási terhelés felé nő, a teljes I/OPS csökken.

Egymás melletti összehasonlítások

Annak szemléltetésére, hogy a gyorsítótárazás hogyan befolyásolhatja a teljesítménymutató-teszteket, az alábbi grafikon a 4 kiB-tesztek teljes I/OPS-ét mutatja be gyorsítótárazási mechanizmusokkal és anélkül. Ahogy látható, a gyorsítótárazás enyhe teljesítménynövelést biztosít az I/OPS viszonylag konzisztens trendjeihez.

Specifikus eltolás, véletlenszerű olvasási/írási számítási feladatok streamelése: párhuzamos hálózati kapcsolatok használatával végzett vertikális felskálázási tesztek (nconnect)

Az alábbi tesztek egy magas I/OP-teljesítményt mutatnak egy 4 KiB véletlenszerű számítási feladatokkal és egy 1 TiB-adatkészlettel rendelkező ügyfél használatával. A létrehozott számítási feladatok keveréke minden alkalommal eltérő I/O-mélységet használ. Az egyetlen ügyfél-számítási feladat teljesítményének növelése érdekében a csatlakoztatási nconnect lehetőség a csatlakoztatási lehetőség nélküli nconnect ügyfélcsatlakozásokhoz képest a párhuzamosság javítására szolgál.

Ha olyan szabványos TCP-kapcsolatot használ, amely csak egyetlen elérési utat biztosít a tárolóhoz, a rendszer másodpercenként kevesebb teljes műveletet küld el, mint amikor a csatlakoztatás több TCP-kapcsolatot képes kihasználni (például nconnect) csatlakoztatási pontonként. Használat nconnectesetén a műveletek teljes késése általában alacsonyabb. Ezek a tesztek a gyorsítótárazás szándékos elkerülése érdekében is futnak randrepeat=0 . Erről a lehetőségről további információt a Tesztelési módszertan című témakörben talál.

Eredmények: 4 KiB, véletlenszerű, és anélkül nconnect, gyorsítótárazás kizárt

Az alábbi grafikonok a 4 KiB-olvasások és -írások egymás melletti összehasonlítását mutatják be, és nem nconnect emelik ki a használat nconnectsorán tapasztalt teljesítménybeli javulást: magasabb általános I/OPS, alacsonyabb késés.

Magas átviteli sebességű teljesítménytesztek

Az alábbi teljesítménymutatók a nagy átviteli sebességű számítási feladatokkal rendelkező Azure NetApp Files esetében elért teljesítményt mutatják be.

A nagy átviteli sebességű számítási feladatok szekvenciálisabbak a természetben, és gyakran alacsony metaadatokat tartalmazó olvasási/írási nehézkesek. Az átviteli sebesség általában fontosabb, mint az I/OPS. Ezek a számítási feladatok általában nagyobb olvasási/írási méreteket használnak (64K–256K), ami nagyobb késéseket eredményez, mint a kisebb olvasási/írási méretek, mivel a nagyobb hasznos adatok feldolgozása természetesen tovább tart.

A nagy átviteli sebességű számítási feladatok például a következők:

• Médiatárak
• Nagy teljesítményű számítás
• AI/ML/LLP

Az alábbi tesztek egy magas átviteli teljesítménytesztet mutatnak, amely 64 KiB és 256 KiB szekvenciális számítási feladatokat és egy 1 TiB-adatkészletet használ. A létrehozott számítási feladatok keveréke egyszerre csökkenti a megadott százalékos értéket, és bemutatja, hogy mire számíthat a változó olvasási/írási arányok használatakor (például 100%:0%, 90%:10%, 80%:20%stb.).

Eredmények: 64 KiB szekvenciális I/O, gyorsítótárazás belefoglalva

Ebben a teljesítménytesztben a FIO olyan cikluslogikával futott, amely agresszívabban feltöltötte a gyorsítótárat, így a gyorsítótárazás meghatározatlan mennyisége befolyásolta az eredményeket. Ez valamivel jobb általános teljesítményt eredményez, mint a gyorsítótárazás nélkül futtatott tesztek.

Az alábbi ábrán a tesztelés azt mutatja, hogy az Azure NetApp Files normál kötete körülbelül 4500MiB/s tiszta szekvenciális 64 KiB-olvasás és körülbelül 1600MiB/s tiszta szekvenciális 64 KiB-írás között képes kezelni. A számítási feladat írási és olvasási mixe minden futtatás esetében 10%-kal lett módosítva.

Eredmények: 64 KiB szekvenciális I/O, gyorsítótárazás kizárt

Ebben a teljesítménytesztben a FIO olyan cikluslogikával futott, amely kevésbé agresszíven tölti fel a gyorsítótárat. Az ügyfél gyorsítótárazása nem befolyásolta az eredményeket. Ez a konfiguráció valamivel jobb írási teljesítményt eredményez, de alacsonyabb olvasási számokat eredményez, mint a gyorsítótárazás nélküli tesztek.

A következő grafikonon a tesztelés azt mutatja be, hogy az Azure NetApp Files normál kötete körülbelül 3600MiB/s tiszta szekvenciális 64 KiB-olvasás és körülbelül 2400MiB/s tiszta szekvenciális 64 KiB-írás között képes kezelni. A tesztek során az 50/50-es mix teljes átviteli sebességet mutatott egy tiszta szekvenciális olvasási számítási feladattal.

A számítási feladat írási és olvasási mixe minden futtatás esetében 25%-kal lett módosítva.

Eredmények: 256 KiB szekvenciális I/O, gyorsítótárazás kizárt

Ebben a teljesítménytesztben a FIO olyan cikluslogikával futott, amely kevésbé agresszíven tölti fel a gyorsítótárat, így a gyorsítótárazás nem befolyásolta az eredményeket. Ez a konfiguráció valamivel kevesebb írási teljesítményt eredményez, mint a 64 KiB-tesztek, de az azonos 64 KiB-teszteknél magasabb olvasási számok gyorsítótárazás nélkül futnak.

Az alábbi grafikonon a tesztelés azt mutatja, hogy az Azure NetApp Files normál kötete körülbelül 3500MiB/s tiszta szekvenciális 256 KiB-olvasás és körülbelül 2500MiB/s tiszta szekvenciális 256-KiB-írás között képes kezelni. A tesztek során egy 50/50-es mix azt mutatta, hogy a teljes átviteli sebesség magasabb volt, mint egy tiszta szekvenciális olvasási számítási feladat.

A számítási feladat írási-olvasási mixe minden futtatáshoz 25%-os növekményben lett módosítva.

Egymás melletti összehasonlítás

Annak jobb szemléltetéséhez, hogy a gyorsítótárazás hogyan befolyásolhatja a teljesítményteszt-teszteket, az alábbi grafikon a 64 KiB-tesztek teljes MiB/s-jét mutatja gyorsítótárazási mechanizmusokkal és anélkül. A gyorsítótárazás kezdeti kis teljesítménynövelést biztosít az összes miB/s esetében, mivel a gyorsítótárazás általában jobban javítja az olvasást, mint az írást. Ahogy változik az olvasási/írási mix, a gyorsítótárazás nélküli teljes átviteli sebesség meghaladja az ügyfél gyorsítótárazását használó eredményeket.

Párhuzamos hálózati kapcsolatok (nconnect)

Az alábbi tesztek egy magas I/OP-teljesítményt mutatnak egyetlen ügyfél használatával, 64 KiB véletlenszerű számítási feladatokkal és egy 1 TiB-adatkészlettel. A létrehozott számítási feladatok keveréke minden alkalommal eltérő I/O-mélységet használ. Az egyetlen ügyfél-számítási feladat teljesítményének növelése érdekében a csatlakoztatási lehetőséget a nconnect jobb párhuzamosság érdekében használták a csatlakoztatási lehetőséget nem használó nconnect ügyfélcsatlakozásokhoz képest. Ezeket a teszteket csak a gyorsítótárazás kizárásával futtatták.

Eredmények: 64 KiB, szekvenciális, gyorsítótárazás kizárt, és nem nconnect

Az alábbi eredmények egy vertikális felskálázási teszt eredményeit mutatják, amikor egy NFSv3-csatlakoztatáson 4 KiB-adattömbökben olvasnak és írnak egyetlen ügyfélen a műveletek párhuzamosításával és nélkül (nconnect). A grafikonok azt mutatják, hogy az I/O mélységének növekedésével az I/OPS is növekszik. Ha azonban olyan szabványos TCP-kapcsolatot használ, amely csak egyetlen elérési utat biztosít a tárolóhoz, a rendszer másodpercenként kevesebb teljes műveletet küld el, mint amikor a csatlakoztatás több TCP-kapcsolatot képes kihasználni csatlakoztatási pontonként. Emellett a műveletek teljes késése általában alacsonyabb a használat során nconnect.

Egymás melletti összehasonlítás (a következővel és anélkül nconnect)

Az alábbi grafikonok a 64 KiB szekvenciális olvasások és írások egymás melletti összehasonlítását mutatják be, és nem nconnect emelik ki a használat nconnectsorán tapasztalt teljesítménybeli javulást: nagyobb általános átviteli sebesség, alacsonyabb késés.

További információ

• Tesztelési módszertan