Az Azure Files és az Azure File Sync méretezhetőségi és teljesítménycéljai
Az Azure Files teljes körűen felügyelt fájlmegosztásokat kínál a felhőben, amelyek a kiszolgálói üzenetblokk (SMB) és a hálózati fájlrendszer (NFS) fájlrendszerprotokolljaival é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.
Felügyeleti modell | Számlázási modell | Médiaszint | Redundancia | SMB | NFS |
---|---|---|---|---|---|
Microsoft.Storage | Kiépített v2 | HDD (standard) | Helyi (LRS) | ||
Microsoft.Storage | Kiépített v2 | HDD (standard) | Zóna (ZRS) | ||
Microsoft.Storage | Kiépített v2 | HDD (standard) | Geo (GRS) | ||
Microsoft.Storage | Kiépített v2 | HDD (standard) | Geozone (GZRS) | ||
Microsoft.Storage | Kiépített v1 | SSD (prémium) | Helyi (LRS) | ||
Microsoft.Storage | Kiépített v1 | SSD (prémium) | Zóna (ZRS) | ||
Microsoft.Storage | Használatalapú fizetés | HDD (standard) | Helyi (LRS) | ||
Microsoft.Storage | Használatalapú fizetés | HDD (standard) | Zóna (ZRS) | ||
Microsoft.Storage | Használatalapú fizetés | HDD (standard) | Geo (GRS) | ||
Microsoft.Storage | Használatalapú fizetés | HDD (standard) | Geozone (GZRS) |
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.
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:
FileStorage storage-fiókok: A FileStorage storage-fiókok lehetővé teszik az Azure-fájlmegosztások üzembe helyezését egy kiépített számlázási modellel. 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.
Általános célú 2. verzió (GPv2)-tárfiókok: A GPv2-tárfiókok lehetővé teszik használatalapú fizetéses fájlmegosztások üzembe helyezését a 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.
Attribútum | SSD kiosztott v1 | HDD kiosztott v2 | HDD használatalapú fizetés |
---|---|---|---|
Tárfiók altípusa | FileStorage | FileStorage | StorageV2 |
Termékváltozatok |
|
|
|
Tárfiókok száma régiónként előfizetésenként | 250 | 250 | 250 |
Maximális tárolási kapacitás | 100 TiB | 4 PiB | 5 PiB |
Fájlmegosztások maximális száma | 1024 (50 vagy kevesebb használata javasolt) | 50 | Korlátlan (50 vagy kevesebb használata ajánlott) |
Maximális IOPS | 102 400 IOPS | 50 000 IOPS | 20 000 IOPS |
Maximális átviteli sebesség | 10 340 MiB / mp | 5,120 MiB / mp |
|
Virtuális hálózati szabályok maximális száma | 200 | 200 | 200 |
IP-címszabályok maximális száma | 200 | 200 | 200 |
Felügyeleti olvasási műveletek | 5 percenként 800 | 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 | Másodpercenként 10/1200 óránként |
Felügyeleti listaműveletek | 5 percenként 100 | 5 percenként 100 | 5 percenként 100 |
Az alábbi régiók nagyobb maximális átviteli sebességgel rendelkeznek a használatalapú HDD-tárfiókok (StorageV2) esetében:
- Kelet-Ázsia
- Délkelet-Ázsia
- Kelet-Ausztrália
- Dél-Brazília
- Közép-Kanada
- Kelet-Kína 2. régiója
- Észak-Kína 3. régiója
- Észak-Európa
- Nyugat-Európa
- Közép-Franciaország
- Középnyugat-Németország
- Közép-India
- Kelet-Japán
- Jio Nyugat-India
- Dél-Korea középső régiója
- Kelet-Norvégia
- Dél-Afrika északi régiója
- Közép-Svédország
- Egyesült Arab Emírségek északi régiója
- Az Egyesült Királyság déli régiója
- USA középső régiója
- USA keleti régiója
- USA 2. keleti régiója
- USA-beli államigazgatás – Virginia
- USA-beli államigazgatás – Arizona
- USA északi középső régiója
- USA déli középső régiója
- USA nyugati régiója
- USA 2. nyugati régiója
- USA 3. nyugati régiója
Az Azure-fájlmegosztási skálázási célok a fájlmegosztás szintjén érvényesek.
Attribútum | SSD kiosztott v1 | HDD kiosztott v2 | HDD használatalapú fizetés |
---|---|---|---|
Tárolókiépítési egység | 1 GB | 1 GB | n/a |
IOPS-kiépítési egység | n/a | 1 I/s | n/a |
Átviteli sebesség kiépítési egység | n/a | 1 miB / mp | n/a |
Minimális tárterületméret | 100 GiB (kiépített) | 32 GiB (kiépített) | 0 bájt |
Maximális tárterületméret | 100 TiB | 256 TiB | 100 TiB |
Fájlok maximális száma | Korlátlan | Korlátlan | Korlátlan |
Maximális IOPS | 102 400 IOPS (kiépítéstől függő) | 50 000 IOPS (kiépítéstől függően) | 20 000 IOPS |
Maximális átviteli sebesség | 10 340 MiB /s (kiépítéstől függően) | 5 120 IOPS (kiépítéstől függően) | Legfeljebb tárfiókkorlátok |
Megosztási pillanatképek maximális száma | 200 pillanatkép | 200 pillanatkép | 200 pillanatkép |
Fájlné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 | 2048 karakter |
A 2. egyedi elérési útnév összetevőmaximális hossza (az \A\B\C\D elérési úton minden betű egy adott összetevőt tartalmazó könyvtárat vagy fájlt jelöl) | 255 karakter | 255 karakter | 255 karakter |
Kemény kapcsolat korlátja (csak NFS esetén) | 178 | N.A. | N.A. |
Többcsatornás SMB-csatornák maximális száma | 4 | N.A. | N.A. |
Tárolt hozzáférési szabályzatok maximális száma fájlmegosztásonként | 5 | 5 | 5 |
3 Az Azure Files bizonyos elnevezési szabályokat kényszerít ki a címtárakra és a fájlnevekre.
A fájlok skálázási céljai az Azure-fájlmegosztásokban tárolt egyéni fájlokra érvényesek.
Attribútum | SSD kiosztott v1 | HDD kiosztott v2 | HDD használatalapú fizetés |
---|---|---|---|
Maximális fájlméret | 4 TiB | 4 TiB | 4 TiB |
Az adatok maximális IOPS-száma fájlonként | 8000 IOPS | 1000 IOPS | 1000 IOPS |
Fájlonkénti átviteli sebesség maximális száma | 1,024 MiB / mp | 60 MiB / mp | 60 MiB / mp |
A gyökérkönyvtár egyidejű leíróinak maximális száma | 10 000 fogópont | 10 000 fogópont | 10 000 fogópont |
Egyidejű leírók maximális száma fájlonként és könyvtáronként | 2000 kezelő | 2000 kezelő | 2000 kezelő |
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.
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.
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.
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 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 | 100 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 |
Megjegyzé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.
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.
Megjegyzé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.
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 | 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 | 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.
Megjegyzé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.