Közvetlen tárolóhelyek beágyazott rugalmassága

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

A beágyazott rugalmasság a Közvetlen tárolóhelyek képessége az Azure Stack HCI-ben és a Windows Serverben. Lehetővé teszi, hogy egy kétkiszolgálós fürt egyszerre több hardverhibát is kibírjon a tároló rendelkezésre állásának elvesztése nélkül, így a felhasználók, alkalmazások és virtuális gépek zavartalanul futnak. Ez a cikk bemutatja a beágyazott rugalmasság működését, részletes útmutatást nyújt az első lépésekhez, és megválaszolja a leggyakrabban feltett kérdéseket.

Mielőtt hozzákezdene

Fontolja meg a beágyazott rugalmasságot, ha:

• A klaszter a következő operációs rendszerek egyikét futtatja: Azure Stack HCI 22H2-es vagy újabb verzió, Windows Server 2019 vagy újabb; illetve
• A fürtnek pontosan két szervercsomópontja van.

Beágyazott rugalmasság nem használható, ha:

• A klaszter a Windows Server 2016-ot futtatja; vagy
• A fürtnek csak egyetlen kiszolgálócsomópontja van, vagy három vagy több kiszolgálócsomópontja van.

Miért érdemes beágyazott rugalmasságot

A beágyazott rugalmasságot használó kötetek akkor is online maradhatnak és elérhetők, ha egyszerre több hardverhiba történik, ellentétben a klasszikus kétirányú tükrözési rugalmasságkal. Ha például két meghajtó meghibásodik egyszerre, vagy ha egy kiszolgáló leáll, és egy meghajtó meghibásodik, a beágyazott rugalmasságot használó kötetek online állapotban maradnak és elérhetők maradnak. A hiperkonvergens infrastruktúra esetében ez növeli az alkalmazások és a virtuális gépek üzemidejét; fájlkiszolgálói számítási feladatok esetén ez azt jelenti, hogy a felhasználók folyamatos hozzáféréssel rendelkeznek a fájljaikhoz.

A kompromisszum az, hogy a beágyazott rugalmasság alacsonyabb kapacitáshatékonysággal rendelkezik, mint a klasszikus kétirányú tükrözés, ami azt jelenti, hogy valamivel kevesebb hasznos helyet kap. További részletekért tekintse meg a kapacitáshatékonyságot ismertető szakaszt.

Hogyan működik?

Ez a szakasz a Közvetlen tárolóhelyek beágyazott rugalmasságának hátterét mutatja be, és ismerteti a két új rugalmassági lehetőséget és azok kapacitáshatékonyságát.

Inspiráció: RAID 5+1

A RAID 5+1 az elosztott tárolási rugalmasság egy bevált formája, amely hasznos hátteret nyújt a beágyazott rugalmasság megértéséhez. A RAID 5+1-ben az egyes kiszolgálókon belül a helyi rugalmasságot a RAID-5 vagy az egyetlen paritás biztosítja, hogy védelmet nyújtson az egyetlen meghajtók elvesztése ellen. Ezután a raid-1 vagy kétirányú tükrözés további rugalmasságot biztosít a két kiszolgáló között, hogy védelmet nyújtsunk mindkét kiszolgáló elvesztése ellen.

Rugalmassági beállítások

A Közvetlen tárolóhelyek az Azure Stack HCI-ben és a Windows Serverben két rugalmassági lehetőséget kínál a szoftverben, anélkül, hogy speciális RAID-hardverre van szükség:

• Beágyazott kétirányú tükör. Az egyes kiszolgálókon belül a helyi rugalmasságot kétirányú tükrözés biztosítja, majd a két kiszolgáló közötti kétirányú tükrözés további rugalmasságot biztosít. Ez lényegében egy négyes tükör, ahol minden kiszolgálón két példány van, amelyek különböző fizikai lemezeken találhatók. A beágyazott kétirányú tükrözés kompromisszumok nélküli teljesítményt nyújt: az írások az összes példányba kerülnek, és az olvasások bármelyik másolatból történnek.

  

• Beágyazott gyorsított tükrözésű paritás. Az előző képen szereplő beágyazott kétirányú tükrözés kombinálása beágyazott paritásossággal. Az egyes kiszolgálókon belül a legtöbb adat helyi rugalmasságát egy bitenkénti paritásos aritmetika biztosítja, kivéve a kétirányú tükrözést használó új írásokat. Ezután a kiszolgálók közötti kétirányú tükrözés további rugalmasságot biztosít az összes adat számára. A kötetre írt új írások a tükrözött részre kerülnek, és mindegyik kiszolgálón két példány található külön fizikai lemezen. Ahogy a kötet tükrözött része megtelik minden kiszolgálón, a legrégebbi adatok konvertálásra kerülnek és mentésre kerülnek a háttérben található paritásos részre. Ennek eredményeképpen minden kiszolgáló kétirányú tükrözésben vagy egyetlen paritásos struktúrában rendelkezik a kötet adataival. Ez hasonló a tükrözött paritás működéséhez– a különbség az, hogy a tükrözéssel gyorsított paritás négy kiszolgálót igényel a fürtben és a tárolókészletben, és egy másik paritásos algoritmust használ.

  

Kapacitáshatékonyság

A kapacitáshatékonyság a használható hely és a térfogati kitöltés aránya. Leírja a rugalmasságnak tulajdonítható kapacitásterhelést, és a választott rugalmassági beállítástól függ. Egyszerű példaként az adatok rugalmasság nélküli tárolása 100% kapacitás hatékony (1 TB adat 1 TB fizikai tárolási kapacitást foglal el), míg a kétirányú tükrözés 50% hatékony (1 TB adat 2 TB fizikai tárolási kapacitást foglal el).

• A beágyazott kétutas tükör mindenből négy példányt ír. Ez azt jelenti, hogy 1 TB adat tárolásához 4 TB fizikai tárolási kapacitásra van szükség. Bár az egyszerűsége vonzó, a beágyazott kétirányú tükör 25% kapacitás-hatékonysága a legalacsonyabb a Storage Spaces Direct összes rugalmassági opciója közül.

• A beágyazott tükrözött gyorsított paritás körülbelül 35%-40%kapacitáshatékonyságot ér el, amely két tényezőtől függ: az egyes kiszolgálók meghajtóinak számától, valamint a kötethez megadott tükrözés és paritás kombinációjától. Ez a táblázat a gyakori konfigurációk keresését tartalmazza:

  Kapacitásmeghajtók kiszolgálónként	10% tükör	20% tükör	30% tükör
  4	35,7%	34.1%	32,6%
  5	37,7%	35,7%	33,9%
  6	39.1%	36,8%	34,7%
  7+	40,0%	37,5%	35,3%

  Az alábbiakban egy példa látható a teljes matematikára. Tegyük fel, hogy mindkét kiszolgálón hat kapacitásmeghajtó található, és egy 100 GB-os kötetet szeretnénk létrehozni, amely 10 GB tükörből és 90 GB paritásból áll. A szerver lokális kétirányú tükrözése 50,0% hatékonyságú, ami azt jelenti, hogy a 10 GB-os tükrözött adatok tárolása megköveteli 20 GB helyet az egyes szervereken. Mindkét kiszolgálóra tükrözve, összesen 40 GB. A kiszolgáló-helyi egy paritás ebben az esetben 5/6 = 83,3% hatékony, ami azt jelenti, hogy a 90 GB paritásos adatok tárolása 108 GB-ot vesz igénybe az egyes kiszolgálókon. Tükrözve mindkét szerverre, a teljes mérete 216 GB. A teljes terület így [(10 GB / 50,0%) + (90 GB / 83,3%)] × 2 = 256 GB, 39,1% teljes kapacitási hatékonysággal.

  Figyelje meg, hogy a klasszikus kétirányú tükrözés kapacitáshatékonysága (körülbelül 50%) és a beágyazott tükörrel gyorsított paritás (akár 40%) kapacitáshatékonysága nem sokban különbözik. A követelményektől függően a kapacitás kissé alacsonyabb hatékonysága érdemes lehet a tárterület rendelkezésre állásának jelentős növelésével. A kötetenkénti rugalmasságot választva kombinálhatja a beágyazott rugalmassági köteteket és a klasszikus kétirányú tükrözött köteteket ugyanazon a fürtön belül.

  

Beágyazott rugalmassági kötetek létrehozása

A PowerShell ismert tárolási parancsmagjaival beágyazott rugalmasságú köteteket hozhat létre, az alábbi szakaszban leírtak szerint.

1. lépés: Tárolási rétegsablonok létrehozása (csak Windows Server 2019 esetén)

A Windows Server 2019 megköveteli, hogy kötetek létrehozása előtt hozzon létre új tárolási rétegsablonokat a New-StorageTier parancsmag használatával. Ezt csak egyszer kell elvégeznie, és minden újonnan létrehozott kötet hivatkozhat ezekre a sablonokra.

Megjegyzés:

Ha Windows Server 2022, Azure Stack HCI, 21H2 vagy Azure Stack HCI 20H2-es verziót futtat, kihagyhatja ezt a lépést.

Határozza meg a -MediaType meghajtók kapacitását, és választhatóan a -FriendlyName választását. Ne módosítsa a többi paramétert.

Ha például a kapacitásmeghajtók merevlemezek (HDD), indítsa el a PowerShellt rendszergazdaként, és futtassa a következő parancsmagokat.

NestedMirror-szint létrehozása:

New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedMirrorOnHDD -ResiliencySettingName Mirror -MediaType HDD -NumberOfDataCopies 4

Beágyazottparitási szint létrehozása:

New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedParityOnHDD -ResiliencySettingName Parity -MediaType HDD -NumberOfDataCopies 2 -PhysicalDiskRedundancy 1 -NumberOfGroups 1 -FaultDomainAwareness StorageScaleUnit -ColumnIsolation PhysicalDisk

Ha a kapacitásmeghajtók szilárdtest-meghajtók (SSD), állítsa be a -MediaType-t SSD-re, és változtassa meg a -FriendlyName-t *OnSSD-ra. Ne módosítsa a többi paramétert.

Jótanács

Ellenőrizze, hogy sikeresen létrehozta-e Get-StorageTier a szinteket.

2. lépés: Beágyazott kötetek létrehozása

Hozzon létre új köteteket a New-Volume parancsmaggal.

• Beágyazott kétirányú tükör

  Beágyazott kétirányú tükrözés használatához hivatkozzon a NestedMirror rétegsablonra, és adja meg a méretet. Például:

  New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume01 -StorageTierFriendlyNames NestedMirrorOnHDD -StorageTierSizes 500GB
  

  Ha a meghajtók szilárdtestalapúak (SSD), cserélje a -StorageTierFriendlyNames a *OnSSD értékre.

• Beágyazott tükörgyorsított paritás

  A beágyazott tükrözött paritás használatához hivatkozzon mind a rétegsablonokra, mind a NestedMirrorNestedParity rétegsablonokra, és adjon meg két méretet, egyet a kötet minden részéhez (első tükrözés, második paritás). Ha például egy 500 GB-os kötetet szeretne létrehozni, amely 20% beágyazott kétutas tükör és 80% beágyazott paritás, futtassa a következőt:

  New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirrorOnHDD, NestedParityOnHDD -StorageTierSizes 100GB, 400GB
  

  Ha a meghajtók szilárdtestalapúak (SSD), cserélje a -StorageTierFriendlyNames a *OnSSD értékre.

3. lépés: Folytatás a Windows Felügyeleti központban

A beágyazott rugalmasságot használó kötetek egyértelmű címkézéssel jelennek meg a Windows Felügyeleti központban , ahogyan az alábbi képernyőképen is látható. A létrehozásuk után ugyanúgy kezelheti és figyelheti őket a Windows Felügyeleti központban, mint bármely más kötet a Közvetlen tárolóhelyekben.

Nem kötelező: Kiterjesztése a gyorsítótár-meghajtókra

Az alapértelmezett beállításokkal a beágyazott rugalmasság védelmet nyújt egyszerre több kapacitásmeghajtó, illetve egy kiszolgáló és egy kapacitásmeghajtó elvesztésével szemben. Ennek a védelemnek a gyorsítótár-meghajtókra való kiterjesztése érdekében van egy másik szempont: mivel a gyorsítótár-meghajtók gyakran biztosítanak olvasási és írási gyorsítótárazást több kapacitásmeghajtóhoz, az egyetlen módja annak, hogy a gyorsítótár-meghajtók elvesztését elviselje, ha a másik kiszolgáló leáll, ha nem gyorsítótáraz írásokat, de ez hatással van a teljesítményre.

Ennek a forgatókönyvnek a megoldásához a Közvetlen tárolóhelyek lehetőséget kínál az írási gyorsítótárazás automatikus letiltására, ha egy kétkiszolgálós fürt egyik kiszolgálója leállt, majd a kiszolgáló biztonsági mentése után újra engedélyezheti az írási gyorsítótárazást. Ha teljesítményhatással nem szeretné engedélyezni a rutinszerű újraindításokat, az írási gyorsítótárazás csak akkor tiltható le, ha a kiszolgáló 30 percig nem működik. Miután az írási gyorsítótárazás le van tiltva, az írási gyorsítótár tartalma a kapacitáseszközökre lesz írva. Ezt követően a kiszolgáló el tudja viselni a sikertelen gyorsítótáreszközt az online kiszolgálón, bár a gyorsítótárból történő olvasás késleltetett vagy sikertelen lehet, ha egy gyorsítótáreszköz meghibásodik.

Megjegyzés:

Az összes gyorsítótár (egy adathordozótípusú) fizikai rendszer esetében nem kell fontolóra vennie az írási gyorsítótár automatikus letiltását, ha egy kétkiszolgálós fürt egyik kiszolgálója leáll. Ezt csak a storage bus layer (SBL) gyorsítótárral kell figyelembe vennie, amely csak HDD-k használata esetén szükséges.

(Nem kötelező) Ha automatikusan le szeretné tiltani az írási gyorsítótárazást, ha egy kétkiszolgálós fürt egyik kiszolgálója leállt, indítsa el a PowerShellt rendszergazdaként, és futtassa a következőt:

Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name "System.Storage.NestedResiliency.DisableWriteCacheOnNodeDown.Enabled" -Value "True"

Ha igaz értékre van állítva, a gyorsítótár működése a következő:

Helyzet	A gyorsítótár viselkedése	Képes elviselni a gyorsítótár-meghajtó elvesztését?
Mindkét kiszolgáló felfelé	Gyorsítótári olvasás és írás, maximális teljesítmény	Igen
Kiszolgáló leállt, első 30 perc	Gyorsítótári olvasás és írás, maximális teljesítmény	Nem (ideiglenesen)
Az első 30 perc után	Csak a gyorsítótár olvasása, a teljesítmény befolyásolva	Igen (miután a gyorsítótárat kapacitásmeghajtókra írták)

Gyakori kérdések

Válaszokat találhat a beágyazott rugalmasságra vonatkozó gyakori kérdésekre.

Átalakíthatok egy meglévő kötetet kétirányú tükrözés és beágyazott rugalmasság között?

Nem, a kötetek nem konvertálhatók különböző rugalmassági típusok között. Az Azure Stack HCI, a Windows Server 2022 vagy a Windows Server 2019 új üzembe helyezéséhez előre döntse el, hogy melyik rugalmassági típus felel meg a legjobban az igényeinek. Ha Windows Server 2016-ról frissít, létrehozhat új köteteket beágyazott rugalmassággal, migrálhatja az adatokat, majd törölheti a régebbi köteteket.

Használhatok beágyazott rugalmasságot több típusú kapacitásmeghajtóval?

Igen, csak adja meg az egyes szintek -MediaType-ját a fent említett 1. lépésben. Ha például az NVMe, az SSD és a HDD ugyanabban a fürtben található, az NVMe gyorsítótárat biztosít, míg az utóbbi kettő kapacitást: állítsa a NestedMirror szintet -MediaType SSD-re, a NestedParity szintet pedig -MediaType HDD-ra. Ebben az esetben a paritásos kapacitás hatékonysága csak a HDD-meghajtók számától függ, és kiszolgálónként legalább 4 meghajtóra van szükség.

Használhatok beágyazott rugalmasságot három vagy több kiszolgálóval?

Nem, csak akkor használjon hierarchikus rugalmasságot, ha a klaszter pontosan két kiszolgálóval rendelkezik.

Hány meghajtót kell használnom a beágyazott rugalmassághoz?

A Közvetlen tárolóhelyekhez szükséges meghajtók minimális száma kiszolgálócsomópontonként négy kapacitásmeghajtó, valamint kiszolgálócsomópontonként két gyorsítótár-meghajtó (ha van ilyen). Ez nem változik a Windows Server 2016-ról. Nincs más követelmény a beágyazott rugalmassághoz, és a tartalékkapacitásra vonatkozó javaslat is változatlan.

A beágyazott rugalmasság megváltoztatja a meghajtó cseréjének működését?

Nem.

A beágyazott rugalmasság megváltoztatja a kiszolgálócsomópontok cseréjének működését?

Nem. A kiszolgálócsomópont és a meghajtók cseréjéhez kövesse az alábbi sorrendet:

1. A kimenő kiszolgálón lévő meghajtók kivonása
2. Adja hozzá az új kiszolgálót a meghajtókkal együtt a fürthöz
3. A tárolókészlet újraegyensúlyozódni fog
4. A kimenő kiszolgáló és meghajtóinak eltávolítása

További részletekért lásd a Kiszolgálók eltávolítása című cikket.

Következő lépések

• Storage Spaces Direct áttekintése
• A közvetlen tárolóhelyek hibatűrésének ismertetése
• Volume tervezés a Storage Spaces Direct rendszerben
• Kötetek létrehozása a Storage Spaces Direct szolgáltatásban