Kötetek tervezése az Azure Stack HCI-n és Windows Server-fürtökön

A következőkre vonatkozik: Azure Stack HCI, 22H2 és 21H2 verzió; Windows Server 2022, Windows Server 2019

Ez a cikk útmutatást nyújt a fürtkötetek számítási feladatok teljesítményének és kapacitásigényének megfelelő megtervezéséhez, beleértve a fájlrendszer, a rugalmasság típusa és a méret kiválasztását.

Megjegyzés

Közvetlen tárolóhelyek általános használatra nem támogatja a fájlkiszolgálót. Ha a fájlkiszolgálót vagy más általános szolgáltatásokat a Közvetlen tárolóhelyen kell futtatnia, konfigurálja azt a virtuális gépeken.

Áttekintés: Mik azok a kötetek?

A köteteken elhelyezheti a számítási feladatokhoz szükséges fájlokat, például VHD- vagy VHDX-fájlokat a Hyper-V virtuális gépekhez. A kötetek egyesítik a tárolókészlet meghajtóit, hogy bemutassa a Közvetlen tárolóhelyek, az Azure Stack HCI és a Windows Server mögötti szoftveralapú tárolási technológia hibatűrését, méretezhetőségét és teljesítménybeli előnyeit.

Megjegyzés

A "kötet" kifejezéssel együttesen hivatkozunk a kötetre és az alatta lévő virtuális lemezre, beleértve az egyéb beépített Windows-funkciók, például a fürt megosztott kötetei (CSV) és a ReFS által biztosított funkciókat is. Ezeknek a megvalósítási szintű megkülönböztetéseknek a megértése nem szükséges a Közvetlen tárolóhelyek sikeres megtervezéséhez és üzembe helyezéséhez.

Az összes kötetet a fürt összes kiszolgálója egyszerre érheti el. A létrehozás után az összes kiszolgálón megjelennek a C:\ClusterStorage\ helyen.

A létrehozni kívánt kötetek mennyiségének kiválasztása

Javasoljuk, hogy a kötetek számát a fürtön lévő kiszolgálók számának többszörösére tegye. Ha például 4 kiszolgálóval rendelkezik, konzisztensebb teljesítményt fog tapasztalni 4 teljes kötettel, mint 3 vagy 5 esetén. Ez lehetővé teszi, hogy a fürt egyenletesen ossza el a kötet "tulajdonjogát" (egy kiszolgáló kezeli az egyes kötetek metaadatainak vezénylését) a kiszolgálók között.

Javasoljuk, hogy a kötetek teljes számát fürtönként 64 kötetre korlátozza.

A fájlrendszer kiválasztása

Javasoljuk, hogy használja az új Rugalmas fájlrendszert (ReFS) a Közvetlen tárolóhelyek. A ReFS a virtualizálásra tervezett elsődleges fájlrendszer, amely számos előnnyel rendelkezik, beleértve a drámai teljesítménygyorsításokat és az adatsérülések elleni beépített védelmet. Szinte minden fontos NTFS-funkciót támogat, beleértve az adatdeduplikációt a Windows Server 1709-es és újabb verzióiban. A részletekért tekintse meg a ReFS szolgáltatás-összehasonlító táblázatát .

Ha a számítási feladathoz olyan funkcióra van szükség, amelyet a ReFS még nem támogat, használhatja az NTFS-t.

Tipp

A különböző fájlrendszerrel rendelkező kötetek együtt lehetnek ugyanazon a fürtön.

A rugalmasság típusának kiválasztása

A Közvetlen tárolóhelyek kötetei rugalmasságot biztosítanak a hardverproblémák, például a meghajtó- vagy kiszolgálóhibák elleni védelemhez, valamint a folyamatos rendelkezésre állás biztosításához a kiszolgáló karbantartása során, például szoftverfrissítések esetén.

Megjegyzés

A választható rugalmassági típusok függetlenek a meghajtók típusától.

Két kiszolgálóval

Ha a fürtben két kiszolgáló található, használhat kétirányú tükrözést, vagy használhat beágyazott rugalmasságot.

A kétirányú tükrözés az összes adat két példányát tárolja, az egyes kiszolgálók meghajtóinak egy-egy példányát. Tárolási hatékonysága 50 százalék; 1 TB adat írásához legalább 2 TB fizikai tárolási kapacitásra van szükség a tárolókészletben. A kétirányú tükrözés biztonságosan képes elviselni egyszerre egy hardverhibát (egy kiszolgálót vagy meghajtót).

A beágyazott rugalmasság kétirányú tükrözéssel biztosítja a kiszolgálók közötti adatrugalmasságot, majd kétirányú tükrözéssel vagy tükrözéssel gyorsított paritású rugalmasságot biztosít a kiszolgálókon belül. A beágyazás akkor is biztosít adatrugalmasságokat, ha egy kiszolgáló újraindul vagy nem érhető el. Tárolási hatékonysága 25 százalék a beágyazott kétirányú tükrözéssel, és körülbelül 35-40 százalék a beágyazott tükrözött tükrözött paritás esetében. A beágyazott rugalmasság egyszerre két hardverhibát (két meghajtót vagy egy kiszolgálót és egy meghajtót) képes elviselni. A hozzáadott adatrugalmasság miatt javasoljuk, hogy beágyazott rugalmasságot használjunk a kétkiszolgálós fürtök éles üzemelő példányaihoz. További információ: Beágyazott rugalmasság.

Három kiszolgálóval

Három kiszolgáló esetén háromirányú tükrözést kell használnia a jobb hibatűrés és teljesítmény érdekében. A háromutas tükrözés az összes adat három példányát tárolja, az egyes kiszolgálók meghajtóinak egy-egy példányát. Tárolási hatékonysága 33,3 százalék – 1 TB adat írásához legalább 3 TB fizikai tárolókapacitásra van szükség a tárolókészletben. A háromutas tükrözés egyszerre legalább két hardverhibát (meghajtót vagy kiszolgálót) képes biztonságosan elviselni. Ha két csomópont elérhetetlenné válik, a tárolókészlet elveszíti a kvórumot, mivel a lemezek 2/3-a nem érhető el, és a virtuális lemezek elérhetetlenek lesznek. A csomópontok azonban leállhatnak, és egy vagy több másik csomópont lemeze meghibásodhat, és a virtuális lemezek online állapotban maradnak. Ha például újraindít egy kiszolgálót, amikor hirtelen egy másik meghajtó vagy kiszolgáló meghibásodik, minden adat biztonságos és folyamatosan elérhető marad.

Négy vagy több kiszolgálóval

Négy vagy több kiszolgálóval minden kötethez kiválaszthatja, hogy háromirányú tükrözést, kettős paritást (gyakran "erasure coding" néven) használjon, vagy keverje össze a kettőt a tükrözéssel gyorsított paritással.

A kettős paritás ugyanazt a hibatűrést biztosítja, mint a háromutas tükrözés, de jobb tárolási hatékonysággal. Négy kiszolgáló esetében a tárolási hatékonyság 50,0 százalék; 2 TB adat tárolásához 4 TB fizikai tárolókapacitásra van szükség a tárolókészletben. Ez hét kiszolgáló esetében 66,7%-ra növeli a tárolási hatékonyságot, és továbbra is 80,0 százalékos tárolási hatékonyságot biztosít. A kompromisszum az, hogy a paritásos kódolás nagyobb számítási igényű, ami korlátozhatja a teljesítményét.

A használni kívánt rugalmassági típus a számítási feladat igényeitől függ. Az alábbi táblázat összefoglalja, hogy mely számítási feladatok felelnek meg az egyes rugalmassági típusoknak, valamint az egyes rugalmasságtípusok teljesítmény- és tárolási hatékonyságát.

Rugalmasság típusa	Kapacitáshatékonyság	Sebesség	Számítási feladatok
Tükrözött	Háromutas tükör: 33% Kétirányú tükör: 50%	Legnagyobb teljesítmény	Virtualizált számítási feladatok Adatbázisok Egyéb nagy teljesítményű számítási feladatok
Tükrözött gyorsított paritás	A tükrözés és a paritás arányától függ	Sokkal lassabb, mint a tükör, de akár kétszer olyan gyors, mint a kettős paritás A legjobb a nagy szekvenciális írásokhoz és olvasásokhoz	Archiválás és biztonsági mentés Virtualizált asztali infrastruktúra
Kettős paritás	4 kiszolgáló: 50% 16 kiszolgáló: akár 80%	A legnagyobb I/O-késés & processzorhasználat íráskor A legjobb a nagy szekvenciális írásokhoz és olvasásokhoz	Archiválás és biztonsági mentés Virtualizált asztali infrastruktúra

Amikor a teljesítmény számít a legjobban

A szigorú késési követelményekkel rendelkező vagy sok vegyes véletlenszerű IOPS-t igénylő számítási feladatoknak, például SQL Server adatbázisoknak vagy teljesítményérzékeny Hyper-V virtuális gépeknek olyan köteteken kell futniuk, amelyek tükrözést használnak a teljesítmény maximalizálása érdekében.

Tipp

A tükrözés gyorsabb, mint bármely más rugalmassági típus. Szinte az összes teljesítménybeli példánkhoz használunk tükrözést.

Amikor a kapacitás a legfontosabb

A ritkán írt számítási feladatoknak, például az adattárházaknak vagy a "ritka" tárolásnak kettős paritást használó köteteken kell futniuk a tárolási hatékonyság maximalizálása érdekében. Bizonyos egyéb számítási feladatok, például a Scale-Out Fájlkiszolgáló (SoFS), a virtuális asztali infrastruktúra (VDI) vagy más olyan számítási feladatok, amelyek nem hoznak létre nagy mennyiségű gyors sodródású véletlenszerű I/O-forgalmat, és/vagy amelyek nem igénylik a legjobb teljesítményt, szintén kettős paritást használhatnak saját belátása szerint. A paritás elkerülhetetlenül növeli a processzorkihasználtságot és az I/O-késést, különösen az írások esetében, a tükrözéshez képest.

Ha az adatok tömegesen íródnak

A nagy, szekvenciális áthaladásokat , például archiválási vagy biztonsági mentési célokat tartalmazó számítási feladatoknak van egy másik lehetőségük: az egyik kötet keverheti a tükrözést és a kettős paritást. Az írások először a tükrözött részbe kerülnek, és később fokozatosan kerülnek a paritásos részbe. Ez felgyorsítja a betöltést, és csökkenti az erőforrás-kihasználtságot nagy írások érkezésekor azáltal, hogy lehetővé teszi a nagy számítási igényű paritásos kódolás hosszabb ideig történő használatát. A részek méretezésekor vegye figyelembe, hogy az egyszerre előforduló írások mennyisége (például egy napi biztonsági mentés) kényelmesen elfér a tükrözött részben. Ha például naponta egyszer 100 GB-ot használ, érdemes lehet tükrözést használni 150 GB és 200 GB között, a többihez pedig kettős paritást.

Az eredményként kapott tárolási hatékonyság a választott arányoktól függ. Példákért tekintse meg ezt a bemutatót .

Tipp

Ha az adatbetöltés során hirtelen csökkenést tapasztal az írási teljesítményben, az azt jelezheti, hogy a tükrözött rész nem elég nagy, vagy hogy a tükrözéssel gyorsított paritás nem megfelelő a használati esethez. Ha például az írási teljesítmény 400 MB/s-ról 40 MB/s-ra csökken, fontolja meg a tükrözött rész kibontását vagy a háromutas tükrözésre való váltást.

Tudnivalók az NVMe-vel, SSD-vel és HDD-vel történő üzembe helyezésről

A két típusú meghajtóval rendelkező üzemelő példányokban a gyorsabb meghajtók gyorsítótárazást biztosítanak, míg a lassabb meghajtók biztosítják a kapacitást. Ez automatikusan történik – további információ: A gyorsítótár ismertetése Közvetlen tárolóhelyek. Az ilyen üzemelő példányokban az összes kötet végső soron azonos típusú meghajtókon – a kapacitásmeghajtókon – található.

A háromféle meghajtót tartalmazó üzemelő példányokban csak a leggyorsabb meghajtók (NVMe) biztosítják a gyorsítótárazást, így két meghajtótípus (SSD és HDD) biztosítja a kapacitást. Minden kötet esetében megadhatja, hogy teljes egészében az SSD-szinten, teljes egészében a HDD-szinten található-e, vagy a kettőre terjed-e ki.

Fontos

Azt javasoljuk, hogy az SSD-szint használatával helyezze a legmegfelelőbb számítási feladatokat minden villámra.

A kötetek méretének kiválasztása

Javasoljuk, hogy az egyes kötetek méretét 64 TB-ra korlátozza az Azure Stack HCI-ben.

Tipp

Ha olyan biztonsági mentési megoldást használ, amely a Kötet árnyékmásolata szolgáltatásra (VSS) és a Volsnap szoftverszolgáltatóra támaszkodik – ahogy az a fájlkiszolgáló számítási feladatainál is gyakori – a kötetméret 10 TB-ra való korlátozása javítja a teljesítményt és a megbízhatóságot. Az újabb Hyper-V RCT API-t és/vagy ReFS-blokk klónozást és/vagy a natív SQL backup API-kat használó biztonsági mentési megoldások akár 32 TB-nál is jobb teljesítményt biztosítanak.

Lábnyom

A kötet mérete a használható kapacitására, a tárolható adatok mennyiségére utal. Ezt a New-Volume parancsmag -Size paramétere biztosítja, majd a Get-Volume parancsmag futtatásakor megjelenik a Méret tulajdonságban.

A méret különbözik a kötet lábnyomától, a tárolókészleten elfoglalt teljes fizikai tárolókapacitástól. A lábnyom a rugalmasság típusától függ. A háromutas tükrözést használó kötetek például a méretük háromszorosával rendelkeznek.

A kötetek lábnyomának el kell férnie a tárolókészletben.

Kapacitás lefoglalása

Ha a tárolókészlet bizonyos kapacitását nem helyezi el, a kötetek számára helyet biztosít a meghajtók meghibásodása utáni "helyben" történő javításhoz, ami növeli az adatbiztonságot és a teljesítményt. Ha elegendő kapacitás áll rendelkezésre, az azonnali, helyszíni, párhuzamos javítás a meghibásodott meghajtók cseréje előtt is teljes rugalmasságra állíthatja vissza a köteteket. Ez automatikusan megtörténik.

Azt javasoljuk, hogy kiszolgálónként egy kapacitásmeghajtót, legfeljebb 4 meghajtót foglaljon le. Előfordulhat, hogy a saját belátása szerint többre van szüksége, de ez a minimális javaslat garantálja, hogy bármely meghajtó meghibásodása után azonnal, helyben, párhuzamos javítást végezhet.

Ha például 2 kiszolgálóval rendelkezik, és 1 TB kapacitásmeghajtót használ, tartalékként helyezzen el 2 x 1 = 2 TB készletet. Ha 3 kiszolgálóval és 1 TB kapacitásmeghajtóval rendelkezik, tartalékként 3 x 1 = 3 TB-t helyezzen el. Ha 4 vagy több kiszolgálóval és 1 TB kapacitásmeghajtóval rendelkezik, tartalékként 4 x 1 = 4 TB-os tartalékot helyezzen el.

Megjegyzés

A három típusú (NVMe + SSD + HDD) meghajtókat tartalmazó fürtökben javasoljuk, hogy kiszolgálónként egy SSD-t és egy HDD-t foglaljon le, legfeljebb 4 meghajtót.

Példa: Kapacitástervezés

Vegyünk egy négykiszolgálós fürtöt. Minden kiszolgáló rendelkezik néhány gyorsítótár-meghajtóval, valamint 16 2 TB-os meghajtóval a kapacitáshoz.

4 servers x 16 drives each x 2 TB each = 128 TB

A tárolókészletben lévő 128 TB-ból négy meghajtót vagy 8 TB-ot különítünk el, hogy a helyszíni javítások a meghibásodásuk után a meghajtók cseréjének siettetése nélkül történjenek. Ez 120 TB fizikai tárolókapacitást hagy a készletben, amellyel köteteket hozhatunk létre.

128 TB – (4 x 2 TB) = 120 TB

Tegyük fel, hogy az üzemelő példányra szükség van néhány nagyon aktív Hyper-V virtuális gép üzemeltetéséhez, de rengeteg ritka elérésű tárolónk is van – régi fájlok és biztonsági másolatok, amelyeket meg kell őriznünk. Mivel négy kiszolgálónk van, hozzunk létre négy kötetet.

Tegyük fel a virtuális gépeket az első két kötetre( Volume1 és Volume2). A reFS fájlrendszert választjuk (a gyorsabb létrehozás és ellenőrzőpontok érdekében), valamint háromirányú tükrözést a teljesítmény maximalizálása érdekében. Tegyük a hideg tárolást a másik két kötetre, a 3 . kötetre és a 4. kötetre. Fájlrendszerként az NTFS fájlrendszert (adatdeduplikációhoz) és kettős paritást választunk a kapacitás maximalizálása érdekében.

Nem kell minden kötetet azonos méretűre tenni, de az egyszerűség kedvéért tegyük fel, hogy mind a 12 TB-ot el tudjuk készíteni.

A Volume1 és a Volume2 mindegyike 12 TB x 33,3 százalékos hatékonyságot foglal el = 36 TB fizikai tárolási kapacitást.

A Volume3 és a Volume4 mindegyike 12 TB x 50,0 százalékos hatékonyságot foglal el = 24 TB fizikai tárolókapacitást.

36 TB + 36 TB + 24 TB + 24 TB = 120 TB

A négy kötet pontosan illeszkedik a készletben elérhető fizikai tárolókapacitáshoz. Tökéletes!

Tipp

Nem kell azonnal létrehoznia az összes kötetet. Később bármikor bővítheti a köteteket, vagy létrehozhat új köteteket.

Az egyszerűség kedvéért ez a példa decimális (alap-10) egységeket használ, ami 1 TB = 1 000 000 000 000 bájtot jelent. A Windowsban azonban a tárolási mennyiségek bináris (base-2) egységekben jelennek meg. Például minden 2 TB-os meghajtó 1,82 TiB-ként jelenik meg a Windowsban. Hasonlóképpen, a 128 TB-os tárolókészlet 116,41 TiB-ként jelenik meg. Ez a várható eredmény.

Használat

Lásd: Kötetek létrehozása az Azure Stack HCI-ben.

Következő lépések

További információ:

• Meghajtók kiválasztása Közvetlen tárolóhelyek
• Hibatűrés és tárolási hatékonyság