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

Az Azure-fájlmegosztás teljesítményének megismerése és optimalizálása

  • Cikk

Az Azure Files képes megfelelni a legtöbb alkalmazás és használati eset teljesítménykövetelményeinek. Ez a cikk ismerteti azokat a különböző tényezőket, amelyek befolyásolhatják a fájlmegosztások teljesítményét, és hogyan optimalizálhatók az Azure-fájlmegosztások teljesítménye a számítási feladathoz.

A következőre érvényes:

Fájlmegosztás típusa SMB NFS
Standard szintű fájlmegosztások (GPv2), LRS/ZRS Igen Nem
Standard szintű fájlmegosztások (GPv2), GRS/GZRS Igen Nem
Prémium fájlmegosztások (FileStorage), LRS/ZRS Igen Igen

Szószedet

A cikk elolvasása előtt hasznos megérteni a tárolási teljesítményre vonatkozó néhány fontos kifejezést:

  • IO-műveletek másodpercenként (IOPS)

    Az IOPS vagy a másodpercenkénti bemeneti/kimeneti műveletek a fájlrendszerműveletek másodpercenkénti számát mérik. Az "IO" kifejezés az Azure Files dokumentációjában található "művelet" és "tranzakció" kifejezésekkel van összefüggésben.

  • I/O-méret

    Az I/O-méret (más néven blokkméret) annak a kérésnek a mérete, amelyet egy alkalmazás egyetlen bemeneti/kimeneti (I/O) művelet végrehajtására használ a tárterületen. Az alkalmazástól függően az I/O mérete a nagyon kis méretektől, például a 4 KiB-től a sokkal nagyobb méretekig terjedhet. Az I/O-méret jelentős szerepet játszik az elérhető átviteli sebességben.

  • Átviteli sebesség

    Az átviteli sebesség a tárolóból beolvasott vagy a tárolóba írt bitek másodpercenkénti számát méri, és másodpercenkénti mebibyte-ben (MiB/s) méri. Az átviteli sebesség kiszámításához szorozza meg az IOPS-t az I/O méretével. Például 10 000 IOPS * 1 MiB I/O méret = 10 GiB/s, míg 10 000 IOPS * 4 KiB I/O méret = 38 MiB/s.

  • Késés

    A késés a késés szinonimája, és általában ezredmásodpercben (ms) mérik. A késésnek két típusa van: a végpontok közötti késés és a szolgáltatás késése. További információ: Késés.

  • Üzenetsor mélysége

    A várólista mélysége azoknak a függőben lévő I/O-kérelmeknek a száma, amelyeket egy tárerőforrás egyszerre képes kezelni. További információ: Üzenetsor mélysége.

Teljesítményszint kiválasztása használati minták alapján

Az Azure Files számos tárolási szintet biztosít, amelyek segítenek csökkenteni a költségeket azáltal, hogy lehetővé teszik az adatok tárolását a megfelelő teljesítmény- és árszinten. A legmagasabb szinten az Azure Files két teljesítményszintet kínál: standard és prémium szintet. A standard fájlmegosztások merevlemez-meghajtók (HDD) által támogatott tárolórendszeren vannak tárolva, míg a prémium szintű fájlmegosztásokat szilárdtest-meghajtók (SSD) biztosítják a jobb teljesítmény érdekében. A standard fájlmegosztások több tárolási szinttel (tranzakcióoptimalizált, gyakori és ritka elérésű) rendelkeznek, amelyek között zökkenőmentesen mozoghat, hogy maximalizálja az inaktív tárterület adatait és a tranzakciós árakat. A standard és a prémium szintű szintek közötti váltás azonban nem lehetséges anélkül, hogy fizikailag migrálhatja az adatokat a különböző tárfiókok között.

A standard és a prémium szintű fájlmegosztások közötti választáskor fontos megérteni az Azure Fileson futtatni kívánt várható használati minta követelményeit. Ha nagy mennyiségű IOPS-t, rendkívül gyors adatátviteli sebességet vagy nagyon alacsony késést igényel, akkor prémium Szintű Azure-fájlmegosztásokat kell választania.

Az alábbi táblázat a standard és a prémium szintű teljesítménycélokat foglalja össze. További részletekért tekintse meg az Azure Files méretezhetőségét és teljesítménycéljait.

Használati minta követelményei Standard Prémium
Írási késés (egyjegyű ezredmásodperc) Igen Igen
Olvasási késés (egyjegyű ezredmásodperc) Nem Igen

A prémium szintű fájlmegosztások olyan kiépítési modellt kínálnak, amely a megosztás mérete alapján garantálja a következő teljesítményprofilt. További információ: Kiépített modell. A kipukkasztott kreditek akkor halmozódnak fel egy burst gyűjtőben, ha a fájlmegosztás forgalma az alapkonfiguráció IOPS-érték alatt van. A megtermelt krediteket később a rendszer a kipukkadás engedélyezéséhez használja fel, ha a műveletek túllépnék az alapszintű IOPS-t.

Kapacitás (GiB) Alapterv IOPS Burst IOPS Kipukkanó kreditek Átviteli sebesség (bejövő forgalom + kimenő forgalom)
100 3,100 Legfeljebb 10 000 24,840,000 110 MiB/s
500 3 500 Legfeljebb 10 000 23,400,000 150 MiB/s
1,024 4,024 Legfeljebb 10 000 21,513,600 203 MiB/s
5,120 8120 Legfeljebb 15 360 26,064,000 613 MiB/s
10,240 13,240 Legfeljebb 30 720 62,928,000 1,125 MiB/s
33,792 36,792 Legfeljebb 100 000 227,548,800 3480 MiB/s
51,200 54,200 Legfeljebb 100 000 164,880,000 5220 MiB/s
102,400 100 000 Legfeljebb 100 000 0 10 340 MiB/s

Teljesítmény-ellenőrzőlista

Akár új, akár meglévő számítási feladat teljesítménykövetelményeit értékeli, a használati minták megértése segít a kiszámítható teljesítmény elérésében. A következő használati minták meghatározásához forduljon a tár rendszergazdájához vagy az alkalmazás fejlesztőjéhez.

  • Késési érzékenység: A felhasználók fájlokat nyitnak meg, vagy az Azure Fileson futó virtuális asztalokkal dolgoznak? Ezek olyan számítási feladatok, amelyek érzékenyek az olvasási késésre, és magas láthatóságot biztosítanak a végfelhasználók számára. Az ilyen típusú számítási feladatok jobban megfelelnek a prémium Szintű Azure-fájlmegosztásoknak, ami egy ezredmásodpercnyi késést biztosít az olvasási és írási műveletekhez (< 2 ms kis I/O-méret esetén).

  • IOPS- és átviteli sebességre vonatkozó követelmények: A prémium szintű fájlmegosztások nagyobb IOPS- és átviteli sebességkorlátokat támogatnak, mint a normál fájlmegosztások. További információkért tekintse meg a fájlmegosztási skálázási célokat .

  • Számítási feladatok időtartama és gyakorisága: A rövid (perc) és a ritkán (óránkénti) számítási feladatok kisebb valószínűséggel érik el a standard fájlmegosztások felső teljesítménykorlátját a hosszú ideig futó, gyakran előforduló számítási feladatokhoz képest. Prémium szintű fájlmegosztások esetén a számítási feladatok időtartama hasznos a megfelelő teljesítményprofil meghatározásakor a kiépítési méret alapján. Attól függően, hogy mennyi ideig kell kipukkannia a számítási feladatnak, és mennyi ideig kell az alapszintű IOPS alatt töltenie, meghatározhatja, hogy elegendő kiugró kreditet halmoz-e fel ahhoz, hogy folyamatosan kielégítse a számítási feladatot csúcsidőben. A megfelelő egyenleg megtalálása csökkenti a költségeket a fájlmegosztás túlkiépítéséhez képest. Gyakori hiba a teljesítménytesztek futtatása néhány percig, ami gyakran félrevezető. Ahhoz, hogy reális képet kapjon a teljesítményről, győződjön meg arról, hogy elég nagy gyakorisággal és időtartamon tesztel.

  • Számítási feladatok párhuzamosítása: Az olyan számítási feladatok esetében, amelyek párhuzamosan, például több szálon, folyamaton vagy alkalmazáspéldányon keresztül hajtanak végre műveleteket ugyanazon ügyfélen, a prémium szintű fájlmegosztások egyértelmű előnyt biztosítanak a standard fájlmegosztásokkal szemben: SMB Multichannel. További információt az SMB Azure-fájlmegosztás teljesítményének javítása című témakörben talál.

  • API-műveletek eloszlása: A számítási feladatok metaadatai nagyok a fájlmegnyitási/-bezárási műveletekkel? Ez gyakran előfordul olyan számítási feladatok esetében, amelyek olvasási műveleteket végeznek nagy számú fájlon. Lásd a metaadatokat vagy a névtér nagy számítási feladatait.

Késés

Ha a késésre gondol, először is fontos tisztában lenni azzal, hogy az Azure Files hogyan határozza meg a késést. A leggyakoribb mérések a végpontok közötti késéssel és a szolgáltatás késésével kapcsolatos metrikák. Ezeknek a tranzakciómetrikáknak a használatával azonosíthatja az ügyféloldali késéssel és/vagy hálózatkezeléssel kapcsolatos problémákat azáltal, hogy meghatározza, hogy az alkalmazás forgalma mennyi időt tölt az ügyfél felé és az ügyfélről való átvitel során.

  • A végpontok közötti késés (SuccessE2ELatency) az a teljes idő, amíg egy tranzakció teljes körű utazást végez az ügyféltől a hálózaton keresztül az Azure Files szolgáltatásig, majd vissza az ügyfélhez.

  • A szolgáltatás késése (SuccessServerLatency) az az idő, amelyet egy tranzakció csak az Azure Files szolgáltatáson belül bonyolíthat le. Ez nem tartalmaz ügyfél- vagy hálózati késést.

    Az Azure Files ügyfél-késését és szolgáltatáskésését összehasonlító ábra.

A SuccessE2ELatency és a SuccessServerLatency értékek közötti különbség a hálózat és/vagy az ügyfél által valószínűleg okozott késés.

Gyakran összekeverjük az ügyfél késését a szolgáltatás késésével (ebben az esetben az Azure Files teljesítményével). Ha például a szolgáltatás késése alacsony késést jelez, és a végpontok közötti adatforgalom nagyon nagy késést jelent a kérések esetében, az azt jelzi, hogy az ügyfél felé és az ügyfélről való átvitel során minden időt az Azure Files szolgáltatásban kell tölteni, nem pedig az Azure Files szolgáltatásban.

Továbbá, ahogy az ábrán látható, minél messzebb van a szolgáltatástól, annál lassabb lesz a késési élmény, és annál nehezebb lesz teljesítményskálázási korlátokat elérni bármely felhőszolgáltatással. Ez különösen igaz az Azure Files helyszíni elérésére. Bár az ExpressRoute-hoz hasonló lehetőségek ideálisak a helyszíni környezetekhez, még mindig nem egyeznek a kizárólag ugyanabban az Azure-régióban futó alkalmazások (számítási és tárolási) teljesítményével.

Tipp.

Az Azure-beli virtuális gépek használata a helyszíni és az Azure közötti teljesítmény teszteléséhez hatékony és gyakorlati módszer az Azure-beli kapcsolat hálózati képességeinek alapkonfigurációjára. A számítási feladatokat gyakran lelassíthatja egy alulméretezett vagy helytelenül irányított ExpressRoute-kapcsolatcsoport vagy VPN-átjáró.

Üzenetsor mélysége

Az üzenetsor mélysége a tárerőforrás által kiszolgálható, nem teljesíthető I/O-kérések száma. Mivel a tárolórendszerek által használt lemezek a HDD-orsóktól (IDE, SATA, SAS) a szilárd állapotú eszközökig (SSD, NVMe) fejlődtek, a nagyobb üzenetsormélység támogatása érdekében is fejlődtek. Egy olyan számítási feladat, amely egyetlen ügyfélből áll, amely egy nagy adatkészleten belül egyetlen fájllal kommunikál, az alacsony üzenetsor-mélység példája. Ezzel szemben a több szálat és több fájlt tartalmazó párhuzamosságot támogató számítási feladatok könnyen elérhetik a magas üzenetsor-mélységet. Mivel az Azure Files egy elosztott fájlszolgáltatás, amely több ezer Azure-fürtcsomópontra terjed ki, és úgy van kialakítva, hogy nagy léptékű számítási feladatokat futtasson, javasoljuk, hogy magas üzenetsor-mélységű számítási feladatokat építsen ki és teszteljen.

A magas várólista-mélység számos különböző módon érhető el az ügyfelekkel, fájlokkal és szálakkal kombinálva. A számítási feladat várólista-mélységének meghatározásához szorozza meg az ügyfelek számát a fájlok számával a szálak számával (ügyfelek * fájlok * szálak = üzenetsormélység).

Az alábbi táblázat azokat a kombinációkat mutatja be, amelyekkel magasabb üzenetsormélység érhető el. Bár túllépheti a 64-et az optimális üzenetsormélységen, nem javasoljuk. Ha mégis, akkor nem fog több teljesítménynövekedést látni, és a TCP telítettsége miatt megnövekedett késést kockáztat.

Ügyfelek Fájlok Szálak Üzenetsor mélysége
0 0 0 0
0 0 2 2
0 2 2 4
2 2 2 8
2 2 4 16
2 4 4 32
0 8 8 64
4 4 2 64

Tipp.

A felső teljesítménykorlátok eléréséhez győződjön meg arról, hogy a számítási feladat vagy a teljesítményértékelési teszt többszálú, több fájlból áll.

Egyszálas és többszálas alkalmazások

Az Azure Files leginkább többszálas alkalmazásokhoz használható. A többszálas feldolgozás számítási feladatra gyakorolt teljesítményre gyakorolt hatásának megértésének legegyszerűbb módja az, ha végigvezeti a forgatókönyvet az I/O-n keresztül. Az alábbi példában van egy számítási feladatunk, amely 10 000 kis fájlt kell a lehető leggyorsabban átmásolnia egy Azure-fájlmegosztásba vagy onnan.

Ez a táblázat lebontja a szükséges időt (ezredmásodpercben), hogy egyetlen 16 KiB-fájlt hozzon létre egy Azure-fájlmegosztáson egy egyszálas alkalmazás alapján, amely 4 KiB-blokkméretben ír.

I/O-művelet Létrehozás 4 KiB írás 4 KiB írás 4 KiB írás 4 KiB írás Bezár Teljes
Szál 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Ebben a példában körülbelül 14 ms-ot vesz igénybe egyetlen 16 KiB-fájl létrehozása a hat műveletből. Ha egy egyszálas alkalmazás 10 000 fájlt szeretne áthelyezni egy Azure-fájlmegosztásba, az 140 000 ms -ra (14 ms * 10 000) vagy 140 másodpercre fordítódik, mivel az egyes fájlokat egymás után helyezi át egymás után. Ne feledje, hogy az egyes kérések kiszolgálásának idejét elsősorban az határozza meg, hogy a számítás és a tárterület milyen közel van egymáshoz, ahogyan azt az előző szakaszban tárgyaltuk.

Ha egy helyett nyolc szálat használ, a fenti számítási feladat 140 000 ms-ról (140 másodpercről) 17 500 ms-ra (17,5 másodpercre) csökkenthető. Ahogy az alábbi táblázat is mutatja, ha egyszerre nyolc fájlt helyez át párhuzamosan egy fájl helyett, ugyanazt az adatmennyiséget 87,5%-kal kevesebb idő alatt helyezheti át.

I/O-művelet Létrehozás 4 KiB írás 4 KiB írás 4 KiB írás 4 KiB írás Bezár Teljes
Szál 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Szál 2 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Szál 3 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Szál 4 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Szál 5 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Szál 6 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Szál 7 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Szál 8 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Lásd még