Az Azure Files méretezhetőségi és teljesítménycéljai
Az Azure Files teljes mértékben felügyelt fájlmegosztásokat kínál a felhőben, amelyek az SMB és az NFS fájlrendszer protokolljaival érhetők el. Ez a cikk az Azure Files és az Azure File Sync skálázhatósági és teljesítménycéljait ismerteti.
Az itt felsorolt célokat az üzembe helyezés más változói is befolyásolhatják. Egy fájl I/O-jának teljesítményét például befolyásolhatja az SMB-ügyfél viselkedése és a rendelkezésre álló hálózati sávszélesség. Tesztelje a használati mintát annak megállapításához, hogy az Azure Files méretezhetősége és teljesítménye megfelel-e a követelményeknek.
A következőre érvényes:
Fájlmegosztás típusa | SMB | NFS |
---|---|---|
Standard szintű fájlmegosztások (GPv2), LRS/ZRS | ||
Standard szintű fájlmegosztások (GPv2), GRS/GZRS | ||
Prémium fájlmegosztások (FileStorage), LRS/ZRS |
Azure Files – skálázási célok
Az Azure-fájlmegosztások a tárfiókokban vannak üzembe helyezve, amelyek olyan legfelső szintű objektumok, amelyek megosztott tárkészletet képviselnek. Ez a tárkészlet több fájlmegosztás üzembe helyezésére is használható. Ezért három kategóriát kell figyelembe venni: tárfiókok, Azure-fájlmegosztások és egyedi fájlok.
Tárfiókok méretezési céljai
A tárfiókok méretezési céljai a tárfiók szintjén érvényesek. Az Azure Files két fő típusú tárfiókot tartalmaz:
Általános célú 2. verzió (GPv2) tárfiókok: A GPv2-tárfiókok lehetővé teszik az Azure-fájlmegosztások központi telepítését standard/merevlemez-alapú (HDD-alapú) hardvereken. Az Azure-fájlmegosztások tárolása mellett a GPv2-tárfiókok más tárolási erőforrásokat is tárolhatnak, például blobtárolókat, üzenetsorokat vagy táblákat. A fájlmegosztások üzembe helyezhetők a tranzakcióoptimalizált (alapértelmezett), gyakori vagy ritka elérésű szinteken.
FileStorage storage-fiókok: A FileStorage storage-fiókok lehetővé teszik az Azure-fájlmegosztások telepítését prémium/SSD-alapú (SSD-alapú) hardvereken. A FileStorage-fiókok csak Azure-fájlmegosztások tárolására használhatók; Más tárolási erőforrások (blobtárolók, üzenetsorok, táblák stb.) nem helyezhetők üzembe a FileStorage-fiókban.
Attribútum | GPv2-tárfiókok (standard) | FileStorage storage-fiókok (prémium) |
---|---|---|
Tárfiókok száma régiónként előfizetésenként | 2501 | 2501 |
Tárfiók maximális kapacitása | 5 PiB2 | 100 TiB (kiépített) |
Fájlmegosztások maximális száma | Korlátlan | Korlátlan, az összes megosztás teljes kiosztott méretének kisebbnek kell lennie, mint a tárfiók maximális kapacitása |
Egyidejű kérelmek maximális sebessége | 20 000 IOPS2 | 102 400 IOPS |
Átviteli sebesség (bejövő forgalom + kimenő forgalom) LRS/GRS esetén
|
|
10 340 MiB/s |
Átviteli sebesség (bejövő forgalom + kimenő forgalom) a ZRS-hez
|
|
10 340 MiB/s |
Az előző sorban nem szereplő redundancia-/régiókombinációk átviteli sebessége (bejövő és kimenő) |
|
10 340 MiB/s |
Virtuális hálózati szabályok maximális száma | 200 | 200 |
IP-címszabályok maximális száma | 200 | 200 |
Felügyeleti olvasási műveletek | 5 percenként 800 | 5 percenként 800 |
Felügyeleti írási műveletek | Másodpercenként 10/1200 óránként | Másodpercenként 10/1200 óránként |
Felügyeleti listaműveletek | 5 percenként 100 | 5 percenként 100 |
1 Kvótanöveléssel régiónként legfeljebb 500 tárfiók hozható létre standard végpontokkal. További információ: Azure Storage-fiókkvóták növelése. 2 Általános célú 2. verziójú tárfiókok támogatják a nagyobb kapacitáskorlátokat és a kérések szerinti bejövő forgalomra vonatkozó magasabb korlátokat. Ha kérni szeretné a fiókjára vonatkozó korlátok növelését, lépjen kapcsolatba az Azure ügyfélszolgálatával.
Azure-fájlmegosztási skálázási célok
Az Azure-fájlmegosztási skálázási célok a fájlmegosztás szintjén érvényesek.
Attribútum | Standard fájlmegosztások1 | Prémium szintű fájlmegosztások |
---|---|---|
Fájlmegosztás minimális mérete | Nincs minimum | 100 GiB (kiépített) |
Kiosztott méret növelése/csökkentése egység | n/a | 1 GB |
Fájlmegosztás maximális mérete |
|
100 TiB |
Fájlmegosztásban lévő fájlok maximális száma | Korlátlan | Korlátlan |
Maximális kérelemarány (maximális IOPS) |
|
|
Átviteli sebesség (bejövő forgalom + kimenő forgalom) egyetlen fájlmegosztáshoz (MiB/s) |
|
100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB) |
Megosztási pillanatképek maximális száma | 200 pillanatkép | 200 pillanatkép |
Objektumnév maximális hossza3 (teljes elérési út, beleértve az összes könyvtárat, fájlnevet és fordított perjel karaktert) | 2048 karakter | 2048 karakter |
A 3. egyedi elérési útnév összetevőmaximális hossza (az \A\B\C\D elérési útban minden betű egy önálló összetevőnek számító könyvtárat vagy fájlt jelöl) | 255 karakter | 255 karakter |
Kemény kapcsolat korlátja (csak NFS esetén) | n/a | 178 |
Többcsatornás SMB-csatornák maximális száma | n/a | 4 |
Tárolt hozzáférési szabályzatok maximális száma fájlmegosztásonként | 5 | 5 |
1 A standard fájlmegosztásokra vonatkozó korlátozások a standard fájlmegosztásokhoz elérhető mindhárom szintre vonatkoznak: tranzakcióoptimalizált, gyakori és ritka elérésű.
2 A standard fájlmegosztások alapértelmezett értéke 5 TiB. A 100 TiB méretű fájlmegosztások létrehozásáról és a meglévő standard fájlmegosztások 100 TiB-os méretre történő növeléséről az Azure-fájlmegosztás létrehozása című témakörben olvashat. A nagyobb léptékű célok kihasználásához módosítania kell a kvótát, hogy az 5 TiB-nál nagyobb legyen.
3 Az Azure Files bizonyos elnevezési szabályokat kényszerít ki a címtárakra és a fájlnevekre.
Fájlskálázási célok
A fájlok skálázási céljai az Azure-fájlmegosztásokban tárolt egyéni fájlokra érvényesek.
Attribútum | Standard szintű fájlmegosztásban lévő fájlok | Prémium szintű fájlmegosztásban lévő fájlok |
---|---|---|
Maximális fájlméret | 4 TiB | 4 TiB |
Egyidejű kérelmek maximális sebessége | 1000 IOPS | Legfeljebb 80001 |
Fájl maximális bejövő forgalma | 60 MiB/s | 200 MiB/s (legfeljebb 1 GiB/s SMB multichannellel)2 |
Fájl maximális kimenő forgalma | 60 MiB/s | 300 MiB/s (legfeljebb 1 GiB/s SMB multichannellel)2 |
A 3. gyökérkönyvtáregyidejű leíróinak maximális száma | 10 000 fogópont | 10 000 fogópont |
Egyidejű leírók maximális száma fájlonként és könyvtáronként3 | 2000 kezelő | 2000 kezelő |
1 Az olvasási és írási I/O-kra vonatkozik (általában kisebb I/O-méretek 64 KiB-nél kisebbek vagy egyenlők). Az olvasási és írási műveletek kivételével a metaadat-műveletek alacsonyabbak lehetnek. Ezek laza korlátok, és leszabályozás ezeken a korlátokon kívül is előfordulhat.
2 A gép hálózati korlátaira, a rendelkezésre álló sávszélességre, az I/O-méretekre, az üzenetsor mélységére és egyéb tényezőkre is figyelemmel. További részletekért lásd az SMB többcsatornás teljesítményét.
3 Az Azure Files 10 000 nyitott fogópontot támogat a gyökérkönyvtárban, és 2000 nyitott fogópontot fájlonként és könyvtáronként a megosztáson belül. A megosztásonként támogatott aktív felhasználók száma a megosztáshoz hozzáférő alkalmazásoktól függ. Ha az alkalmazások nem nyitnak meg leírót a gyökérkönyvtárban, az Azure Files megosztásonként több mint 10 000 aktív felhasználót támogat. Ha azonban az Azure Files használatával lemezképeket tárol nagy méretű virtuális asztali számítási feladatokhoz, előfordulhat, hogy elfogynak a gyökérkönyvtár vagy fájl/könyvtár leírói. Ebben az esetben előfordulhat, hogy több Azure-fájlmegosztást kell használnia. További információ: Azure Files méretezési útmutató az Azure Virtual Desktophoz.
Azure Files méretezési útmutató az Azure Virtual Desktophoz
Az Azure Files népszerű használati esete a felhasználói profiltárolók és lemezképek tárolása az Azure Virtual Desktophoz FSLogix vagy App Attach használatával. Nagy méretű Azure Virtual Desktop-környezetekben előfordulhat, hogy elfogynak a gyökérkönyvtár leírói, vagy fájlonként/könyvtáronként, ha egyetlen Azure-fájlmegosztást használ. Ez a szakasz azt ismerteti, hogyan használják a leírókat a lemezképek különböző típusai, és a használt technológiától függően méretezési útmutatást nyújt.
FSLogix
Ha az FSLogixot az Azure Virtual Desktoppal használja, a felhasználói profiltárolók virtuális merevlemezek (VHD) vagy Hyper-V virtuális merevlemezek (VHDX) fájlok, és felhasználói környezetben vannak csatlakoztatva, nem rendszerkörnyezetben. Minden felhasználó megnyit egy gyökérkönyvtár-leírót, amelynek a fájlmegosztásnak kell lennie. Az Azure Files legfeljebb 10 000 felhasználót támogathat, feltéve, hogy rendelkezik a fájlmegosztással (\\storageaccount.file.core.windows.net\sharename
) + a profilkönyvtárral (%sid%_%username%
) és a profiltárolóval (profile_%username.vhd(x)
).
Ha eléri a gyökérkönyvtár 10 000 egyidejű leírójának korlátját, vagy a felhasználók gyenge teljesítményt tapasztalnak, próbálkozzon egy további Azure-fájlmegosztás használatával, és ossza el a tárolókat a megosztások között.
Figyelmeztetés
Bár az Azure Files akár 10 000 egyidejű felhasználót is támogathat egyetlen fájlmegosztásból, fontos, hogy megfelelően tesztelje a számítási feladatokat a létrehozott fájlmegosztás méretével és típusával. A követelmények a felhasználóktól, a profilmérettől és a számítási feladatoktól függően változhatnak.
Ha például 2400 egyidejű felhasználóval rendelkezik, a gyökérkönyvtárban 2400 fogópont szükséges (minden felhasználóhoz egyet), ami a 10 000 nyitott fogópont korlátja alatt van. Az FSLogix-felhasználók számára a 2000 nyitott fájl- és könyvtárfogópont-korlát elérése rendkívül valószínűtlen. Ha felhasználónként egyetlen FSLogix-profiltárolóval rendelkezik, csak két fájl-/könyvtárleírót használ: egyet a profilkönyvtárhoz, egyet pedig a profiltároló-fájlhoz. Ha a felhasználók mindegyike két tárolóval rendelkezik (profil és ODFC), az ODFC-fájlhoz további leíróra van szükség.
Alkalmazás csatolása a CimFS-sel
Ha MSIX-alkalmazás csatolását vagy alkalmazás csatolását használja az alkalmazások dinamikus csatolásához, lemezképekhez használhat összetett képfájlrendszert (CimFS) vagy VHD/VHDX-fájlokat. Akárhogy is, a méretezési korlátok a rendszerképet csatlakoztató virtuális gépekre vonatkoznak, nem felhasználónként. A felhasználók száma a méretezési korlátok kiszámításakor irreleváns. A virtuális gép indításakor csatlakoztatja a lemezképet, még akkor is, ha nincsenek felhasználók.
Ha alkalmazás csatolását használja a CimFS-sel, a lemezképek csak a lemezképfájlok leíróit használják. Nem használnak leírókat a gyökérkönyvtárban vagy a lemezképet tartalmazó könyvtárban. Mivel azonban a CimFS-rendszerkép a .cim fájl és legalább két másik fájl kombinációja, a lemezképet csatlakoztató virtuális gépek mindegyikéhez egy-egy fogópontra lesz szüksége a könyvtárban található három fájlhoz. Ha tehát 100 virtuális gépe van, 300 fájlfogópontra lesz szüksége.
Előfordulhat, hogy elfogynak a fájlleírók, ha az alkalmazásonkénti virtuális gépek száma meghaladja a 2000-et. Ebben az esetben használjon egy további Azure-fájlmegosztást.
Alkalmazás csatolása VHD/VHDX használatával
Ha VHD/VHDX-fájlokkal használja az Alkalmazás csatolása szolgáltatást, a fájlok rendszerkörnyezetbe vannak csatlakoztatva, nem felhasználói környezetbe, és megosztottak és írásvédettek. A VHDX-fájl több leírója is használható egy csatlakozó rendszer számára. Ahhoz, hogy az Azure Files méretezési korlátain belül maradjon, a virtuális gépek és az alkalmazások számának szorzatának 10 000-nél kevesebbnek kell lennie, és az alkalmazásonkénti virtuális gépek száma nem haladhatja meg a 2000-et. Tehát a kényszer az, amelyiket először eléri.
Ebben a forgatókönyvben egyetlen VHD/VHDX-hez 2000 csatlakoztatással érheti el a fájlonkénti/könyvtárenkénti korlátot. Vagy ha a megosztás több VHD/VHDX-fájlt tartalmaz, először a gyökérkönyvtár korlátját érheti el. Például 100 virtuális gép, amely 100 megosztott VHDX-fájlt csatlakoztat, eléri a 10 000 kezelő gyökérkönyvtár-korlátját.
Egy másik példában 20 alkalmazáshoz hozzáférő 100 virtuális géphez 2000 gyökérkönyvtár-leíró szükséges (100 x 20 = 2000), ami jóval a gyökérkönyvtár-leírók 10 000 korlátja alatt van. A VHD(X) rendszerképet csatlakoztató összes virtuális géphez szükség lesz egy fájlfogópontra és egy könyvtár/mappa fogópontra is, így ebben az esetben 200 fogópont (100 fájlfogópont + 100 könyvtárfogópont) szükséges, ami fájlonként és könyvtáronként kényelmesen a 2000 fogópont korlátja alatt van.
Ha eléri a gyökérkönyvtár vagy fájl/könyvtár maximális egyidejű leíróira vonatkozó korlátokat, használjon további Azure-fájlmegosztást.
Az Azure File Sync skálázási céljai
Az alábbi táblázat a Microsoft által tesztelt határt és a kemény határt jelképező puha célokat jelzi, amely a kikényszerített maximális értékre utal:
Erőforrás | Cél | Merev korlát |
---|---|---|
Társzinkronizálási szolgáltatások régiónként | 100 társzinkronizálási szolgáltatás | Igen |
Storage Sync Services előfizetésenként | 15 Storage Sync Services | Igen |
Szinkronizálási csoportok társzinkronizálási szolgáltatásonként | 200 szinkronizálási csoport | Igen |
Regisztrált kiszolgálók társzinkronizálási szolgáltatásonként | 99 kiszolgáló | Igen |
Privát végpontok társzinkronizálási szolgáltatásonként | 100 privát végpont | Igen |
Felhőbeli végpontok szinkronizálási csoportonként | 1 felhőbeli végpont | Igen |
Kiszolgálóvégpontok szinkronizálási csoportonként | 100 kiszolgálóvégpont | Igen |
Kiszolgálóvégpontok kiszolgálónként | 30 kiszolgálóvégpont | Igen |
Fájlrendszer-objektumok (mappák és fájlok) szinkronizálási csoportonként | 100 millió objektum | Nem |
A könyvtárban található fájlrendszerobjektumok (könyvtárak és fájlok) maximális száma (nem rekurzív) | 5 millió objektum | Igen |
Objektumok (mappák és fájlok) biztonsági leírójának maximális mérete | 64 KiB | Igen |
Fájlméret | 100 GiB | Nem |
Fájl rétegezéséhez szükséges minimális fájlméret | A fájlrendszer klasztermérete alapján (a fájlrendszer klaszterméretének kétszerese). Ha a fájlrendszer klasztermérete például 4 KiB, akkor a minimális fájlméret 8 KiB. | Igen |
Feljegyzés
Az Azure File Sync-végpontok felskálázhatók egy Azure-fájlmegosztás méretére. Ha eléri az Azure-fájlmegosztás méretkorlátját, a szinkronizálás nem fog tudni működni.
Az Azure File Sync teljesítménymetrikái
Mivel az Azure File Sync-ügynök egy Olyan Windows Server-gépen fut, amely csatlakozik az Azure-fájlmegosztásokhoz, a tényleges szinkronizálási teljesítmény az infrastruktúra számos tényezőjétől függ: a Windows Servertől és a mögöttes lemezkonfigurációtól, a kiszolgáló és az Azure Storage közötti hálózati sávszélességtől, a fájlmérettől, az adathalmaz teljes méretétől és az adathalmazon végzett tevékenységtől. Mivel az Azure File Sync a fájlok szintjén működik, egy Azure File Sync-alapú megoldás teljesítményjellemzőit a másodpercenként feldolgozott objektumok (fájlok és mappák) számával érdemes mérni.
Az Azure File Sync teljesítménye két fázisban kritikus:
- Kezdeti egyszeri üzembe helyezés: A kezdeti üzembe helyezés optimális teljesítménye érdekében lásd az Előkészítés az Azure File Synckel című témakörben ismertetett optimális üzembehelyezési eljárást.
- Folyamatos szinkronizálás: Miután az adatok kezdeti feltöltése megtörtént az Azure-fájlmegosztásokon, az Azure File Sync több végpont között tartja fenn a szinkront.
Feljegyzés
Ha az ugyanabban a szinkronizálási csoportban lévő számos kiszolgálóvégpont egyidejűleg szinkronizálódik, a felhőszolgáltatás-erőforrásokért versengenek. Ennek eredményeképpen a feltöltési teljesítmény hatással van. Szélsőséges esetekben egyes szinkronizálási munkamenetek nem férnek hozzá az erőforrásokhoz, és sikertelenek lesznek. Ezek a szinkronizálási munkamenetek azonban rövidesen folytatódnak, és végül sikeresek lesznek a torlódás csökkentése után.
Belső teszteredmények
Annak érdekében, hogy megtervezhesse az üzembe helyezést az egyes szakaszokhoz (kezdeti egyszeri üzembe helyezés és folyamatos szinkronizálás), az alábbi eredményeket figyeltük meg egy rendszeren végzett belső tesztelés során az alábbi konfigurációval:
Rendszerkonfiguráció | Részletek |
---|---|
CPU | 64 virtuális mag 64 MiB-os L3-gyorsítótárral |
Memory (Memória) | 128 GiB |
Lemez | SAS-lemezek RAID 10-zel, akkumulátoros gyorsítótárral |
Network (Hálózat) | 1 Gb/s hálózat |
Számítási feladat | Általános célú fájlkiszolgáló |
Kezdeti egyszeri üzembe helyezés
Kezdeti egyszeri üzembe helyezés | Részletek |
---|---|
Objektumok száma | 25 millió objektum |
Adathalmaz mérete | ~4,7 TiB |
Átlagos fájlméret | ~200 KiB (a legnagyobb fájl: 100 GiB) |
Kezdeti felhőmódosítások száma | 80 objektum másodpercenként |
Feltöltési sebesség | Szinkronizálási csoportonként másodpercenként 20 objektum |
Névtér letöltési sebessége | 400 objektum másodpercenként |
Kezdeti felhőváltozások számbavétele: Új szinkronizálási csoport létrehozásakor a kezdeti felhőváltozások számbavétele az első lépés, amely végrehajtja a műveletet. Ebben a folyamatban a rendszer számba veszi az Azure-fájlmegosztás összes elemét. A folyamat során nem lesz szinkronizálási tevékenység. A rendszer nem tölt le elemeket a felhővégpontról a kiszolgálóvégpontra, és nem tölt fel elemeket a kiszolgálóvégpontról a felhővégpontra. A szinkronizálási tevékenység a felhőbeli változások enumerálásának befejezése után folytatódik.
A teljesítmény másodpercenként 80 objektum. A felhőbeli változások kezdeti számbavételének befejezéséhez szükséges időt úgy becsülheti meg, hogy meghatározza a felhőmegosztásban lévő elemek számát, és az alábbi képletek használatával napok alatt lekérheti az időt.
A kezdeti felhőbeli enumerálás időtartama (napokban) = (A felhőbeli végponton lévő objektumok száma) / (80 × 60 × 60 × 24)
Kezdeti adatszinkronizálás Windows Serverről Azure-fájlmegosztásra: Sok üzemelő Azure File Sync-példány üres Azure-fájlmegosztással indul, mert minden adat a Windows Serveren van. Ezekben az esetekben a kezdeti felhőbeli változások számbavétele gyors, és az idő nagy része a Windows Server változásainak az Azure-fájlmegosztás(ok)ba való szinkronizálásával történik.
Bár a szinkronizálás adatokat tölt fel az Azure-fájlmegosztásba, a helyi fájlkiszolgálón nincs állásidő, a rendszergazdák pedig hálózati korlátokat állíthatnak be a háttéradatok feltöltéséhez használt sávszélesség korlátozásához.
A kezdeti szinkronizálás korlátja általában a percenként és szinkronizálási csoportonként 20 fájlos kezdeti feltöltési sebesség. Az ügyfelek becslést kaphatnak az összes adat Azure-ba való feltöltésének napokban meghatározott időtartamára az alábbi képlettel:
A fájlok szinkronizálási csoportba való feltöltésének időtartama (napokban) = (A kiszolgálóvégponton lévő objektumok száma) / (20 × 60 × 60 × 24)
Az adatok több kiszolgálóvégponton és szinkronizálási csoportban történő elosztása felgyorsíthatja ezt a kezdeti adatfeltöltést, ugyanis a feltöltés több szinkronizálási csoporttal párhuzamosan végezhető, és ezek mindegyike 20 elemet tölt fel másodpercenként. Két szinkronizálási csoport együttes sebessége tehát másodpercenként 40 elem lesz. A befejezéshez szükséges teljes idő a legtöbb szinkronizálandó fájlt tartalmazó szinkronizálási csoporthoz kiszámított becslés lesz.
Névtér letöltési átviteli sebessége: Ha új kiszolgálóvégpontot ad hozzá egy meglévő szinkronizálási csoporthoz, az Azure File Sync-ügynök nem tölti le a fájl tartalmát a felhővégpontról. Először a teljes névteret szinkronizálja, majd háttérbeli visszahívást kezdeményez a fájlok letöltéséhez azok teljességében, vagy a felhőbeli rétegezés engedélyezése esetén a kiszolgálóvégponton beállított felhőbeli rétegezési szabályzatnak megfelelően.
Folyamatban lévő szinkronizálás
Folyamatban lévő szinkronizálás | Részletek |
---|---|
Szinkronizált objektumok száma | 125 000 objektum (~1%-os forgalom) |
Adathalmaz mérete | 50 GiB |
Átlagos fájlméret | ~500 KiB |
Feltöltési sebesség | Szinkronizálási csoportonként másodpercenként 20 objektum |
Teljes letöltési sebesség* | 60 objektum másodpercenként |
*Ha a felhőbeli rétegzés engedélyezve van, akkor valószínűleg jobb teljesítményt fog megfigyelni, mivel csak néhány fájladat töltődik le. Az Azure File Sync csak akkor tölti le a gyorsítótárazott fájlok adatait, ha bármelyik végponton módosítják őket. Rétegzett vagy újonnan létrehozott fájlok esetén az ügynök nem tölti le a fájladatokat, hanem csak az összes kiszolgálóvégpontra szinkronizálja a névteret. Az ügynök támogatja a rétegzett fájlok részleges letöltését is, mivel a felhasználó hozzáfér.
Feljegyzés
Ezek a számok nem jelzik a tapasztalt teljesítményt. A tényleges teljesítmény több tényezőtől függ, ahogyan azt a szakasz elején felvázoltuk.
Az üzembe helyezés általános útmutatójaként tartsa szem előtt néhány dolgot:
- Az objektumátvitel sebessége közelítőleg a kiszolgálón lévő szinkronizálási csoportok számával arányosan skálázódik. Az adatok több szinkronizálási csoportra való felosztása egy kiszolgálón jobb átviteli sebességet eredményez, amelyet a kiszolgáló és a hálózat is korlátoz.
- Az objektumátviteli sebesség fordítottan arányos a MiB/s átviteli sebességgel. Kisebb fájlok esetén nagyobb átviteli sebességet fog tapasztalni a másodpercenként feldolgozott objektumok száma, de alacsonyabb MiB másodpercenkénti átviteli sebesség. Ezzel szemben a nagyobb fájlok esetében másodpercenként kevesebb objektumot fog feldolgozni, de másodpercenként nagyobb MiB-teljesítményt. Az MiB/s-ben mért átviteli sebességet az Azure Files skálázási céljai korlátozzák.