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

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

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:

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) Nem Igen
Microsoft.Storage Előre beállított v2 SSD (prémium) Zóna (ZRS) Nem Igen
Microsoft.Storage Előre beállított v2 HDD (standard) Lokális (LRS) Igen Nem
Microsoft.Storage Előre beállított v2 HDD (standard) Zóna (ZRS) Igen Nem
Microsoft.Storage Előre beállított v2 HDD (standard) Geo (GRS) Igen Nem
Microsoft.Storage Előre beállított v2 HDD (standard) Geozone (GZRS) Igen Nem
Microsoft.Storage Előkészített v1 SSD (prémium) Lokális (LRS) Igen Igen
Microsoft.Storage Előkészített v1 SSD (prémium) Zóna (ZRS) Igen Igen
Microsoft.Storage Fizetés a használat szerint HDD (standard) Lokális (LRS) Igen Nem
Microsoft.Storage Fizetés a használat szerint HDD (standard) Zóna (ZRS) Igen Nem
Microsoft.Storage Fizetés a használat szerint HDD (standard) Geo (GRS) Igen Nem
Microsoft.Storage Fizetés a használat szerint HDD (standard) Geozone (GZRS) Igen Nem

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 felcserélhető az Azure Files dokumentációjában szereplő "művelet" és "tranzakció" kifejezéssel.

  • 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 kis méretektől, például 4 KiB-től 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ésleltetés

    A késés a késés szinonimája, és ezredmásodpercben (ms) mérhető. 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.

Médiaréteg kiválasztása használati minták alapján

Az Azure Files két tárolási adathordozó-réteget biztosít, amelyek lehetővé teszik a teljesítmény és az ár egyensúlyát: az SSD-t és a HDD-t. A fájlmegosztás médiarétegét a tárfiók szintjén választhatja ki, és miután létrehozott egy tárfiókot egy adott médiaszinten, nem léphet át a másikra anélkül, hogy manuálisan áttelepítenél egy új fájlmegosztásra.

Az SSD- és HDD-fájlmegosztások közötti választáskor fontos tisztában lenni az Azure Fileson futtatni kívánt elvárt használati mintával. Ha nagy mennyiségű IOPS-t, gyors adatátviteli sebességet vagy alacsony késést igényel, akkor SSD-fájlmegosztásokat kell választania.

Az alábbi táblázat összefoglalja az SSD- és HDD-fájlmegosztások közötti várható teljesítménycélokat. 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 SSD HDD
Írási késés (egyjegyű ezredmásodperc) Igen Igen
Olvasási késés (egyjegyű ezredmásodperc) Igen Nem

Az SSD-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ókért tekintse meg a kiépített v1-modellt.

Teljesítmény-ellenőrzőlista

Akár egy új vagy 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.

  • Késés érzékenysége: Az olvasási késésre érzékeny és a végfelhasználók számára magas láthatóságú számítási feladatok jobban alkalmasak az SSD-fájlmegosztásokhoz, ami egy ezredmásodpercnyi késést biztosít az olvasási és írási műveletekhez is (< 2 ms kis I/O-méret esetén).

  • IOPS- és átviteli sebességre vonatkozó követelmények: Az SSD-fájlmegosztások nagyobb IOPS- és átviteli sebességkorlátokat támogatnak, mint a HDD-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 HDD-fájlmegosztások felső teljesítménykorlátját a hosszú ideig futó, gyakran előforduló számítási feladatokhoz képest. SSD-fájlmegosztások esetén a számítási feladatok időtartama akkor hasznos, ha a kiosztott tárterület, az IOPS és az átviteli sebesség alapján határozza meg a megfelelő teljesítményprofilt. 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 hajtanak végre műveleteket, például több szálon, folyamaton vagy alkalmazáspéldányon keresztül ugyanazon az ügyfélen, az SSD-fájlmegosztások egyértelmű előnyt biztosítanak a HDD-fájlmegosztásokkal szemben: az SMB Többcsatornás. 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: Az SSD-fájlmegosztásokhoz jobban illeszkednek a metaadatok, például az olvasási műveleteket nagy számú fájlon végző számítási feladatok. Lásd a metaadatokat vagy a névtér nagy számítási feladatait.

Késlelteté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 Fileson 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 SuccessServerLatency értékek közötti különbség a hálózat és/vagy az ügyfél által okozott késés valószínűsége.

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égponttól végpontig terjedő adatátvitel a kérések esetében nagyon nagy késést jelent, az azt jelzi, hogy az összes idő az átvitellel telik az ügyfél felé és vissza, 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 a késési élmény, és annál nehezebb elérni a teljesítményskálázási korlátokat 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. Az alulméretezett vagy helytelenül irányított ExpressRoute-kapcsolatcsoportok vagy VPN-átjárók jelentősen lelassíthatják az Azure Fileson futó számítási feladatokat.

Sor mélysége

A sorban állás mélysége a tárolási erőforrás által kiszolgálható, folyamatban lévő 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 számítási feladat, ahol egyetlen ügyfél sorserűen lép kapcsolatba egy nagy adatkészleten belül található egyetlen fájllal, az alacsony sorhosszúság példája. Ezzel szemben a több szálat és több fájlt használó, párhuzamosságot lehetővé tevő számítási feladatok könnyen elérhetik a magas sorozat mélységét. 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 meghaladhatja az optimális üzenetsormélységet, amely 64, ezt 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
1 1 1 1
1 1 2 2
1 2 2 4
2 2 2 8
2 2 4 16
2 4 4 32
1 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ásnak a terhelés teljesítményére gyakorolt hatásának megértéséhez a legkönnyebb út, ha végigvesszük az I/O-forgatókönyvet. 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 Hozz létre 4 KiB írása 4 KiB írása 4 KiB írása 4 KiB írása Bezár Összesen
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 Hozz létre 4 KiB írása 4 KiB írása 4 KiB írása 4 KiB írása Bezár Összesen
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

  • Last updated on