A tárterület újraszinkronizálásának ismertetése és monitorozása

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

A tárterület-újraszinkronizálási riasztás az Azure Stack HCI és a Windows Server Közvetlen tárolóhelyek képessége. Lehetővé teszi, hogy az állapotfigyelő szolgáltatás hibát jelezze, és értesítést küld az újraszinkronizálásról. Ez segít megakadályozni, hogy véletlenül több kiszolgálót állítsunk le, ami több tartalék tartományt is érinthet, ami a fürt leállását eredményezheti.

Ez a cikk áttekintést nyújt a tárterület újraszinkronizálásáról, valamint arról, hogy hogyan monitorozhatja azt egy feladatátvevő fürtben Közvetlen tárolóhelyek.

Tudnivalók a tárterület újraszinkronizálásáról

Kezdjük egy egyszerű példával, amelyből megtudhatja, hogyan kerülhet ki a tárterület a szinkronizálásból. Ne feledje, hogy minden megosztott semmit nem tartalmazó (csak helyi meghajtókon) elosztott tárolási megoldás ezt a viselkedést mutatja. A következő szakasz azt mutatja be, hogyan lép ki a tárterület a szinkronizálásból, ha egy kiszolgálócsomópont leáll. A meghajtói csak akkor frissülnek, ha újra online állapotba kerülnek – ez a viselkedés bármely hiperkonvergens architektúrára alkalmazható.

Tegyük fel, hogy a "HELLO" sztringet szeretné tárolni.

Egy hello sztring s c i i képe.

Feltételezve, hogy háromutas tükrözési rugalmassága van, a sztringnek három példánya van. Ha ideiglenesen (karbantartás céljából) leállt az 1. kiszolgáló, akkor nem férhet hozzá az 1. példányhoz.

Az 1- es számú másolási szám elérésének a képe, ha az 1-es kiszolgálószámot veszi le.

Tegyük fel, hogy jelenleg a "HELLO" sztringet "HELP!" értékre frissíti.

A súgó s c i i képe! Karakterlánc.

A sztring frissítése után a 2. és a 3. másolás sikeresen frissül. Az 1. másolás azonban nem érhető el, mert az 1. kiszolgáló átmenetileg leállt (karbantartás céljából).

GIF a 2. és a 3. szám másolásához.

Most már rendelkezik az 1. másolással a nem szinkronizált adatokkal. Az operációs rendszer részletes, piszkos régiókövetést használ a nem szinkronizált bitek nyomon követéséhez. Így, amikor az 1. kiszolgáló újra online állapotba kerül, szinkronizálhatja a módosításokat a 2. vagy a 3. másolatból származó adatok beolvasásával és az 1. másolatban lévő adatok felülírásával. Ezzel a módszerrel csak az elavult adatokat kell átmásolnia ahelyett, hogy az összes adatot újraszinkronizálást kellene elvégeznie a 2. kiszolgálóról vagy a 3. kiszolgálóról.

GIF a felülírásról az 1. szám másolásához.

Az előző szakasz azt ismertette, hogyan kerülhetnek ki az adatok a szinkronizálásból. De hogyan néz ki ez magas szinten? Tegyük fel, hogy van egy háromkiszolgálós, hiperkonvergens fürtje. Ha az 1. kiszolgáló karbantartás alatt áll, a kiszolgáló leállt állapotúként jelenik meg. Amikor biztonsági másolatot készít az 1. kiszolgálóról, az elkezdi újraszinkronizálását az összes tárolójában a részletes piszkos régiókövetés használatával (ezt az előző szakaszban ismertetjük). Miután az adatok újra szinkronizálva lettek, az összes kiszolgáló megjelenik.

A következő GIF bemutatja, hogyan működik a tároló újraszinkronizálása egy hiperkonvergens fürtön:

GIF az újraszinkronizálás rendszergazdai nézetéről.

A tárterület újraszinkronizálásának monitorozása

A Windows Server 2019-től kezdve egy új hibát adtunk hozzá az állapotfigyelő szolgáltatáshoz , amely a tároló újraszinkronizálásakor jelenik meg.

A hiba PowerShellben való megtekintéséhez futtassa a következő parancsmagot:

Get-HealthFault

Ez az új hiba megjelenik a PowerShellben, a fürtérvényesítési jelentésben és bárhol máshol, amely az állapothibákra épül.

Ha részletesebb képet szeretne kapni, lekérdezheti az idősor-adatbázist a PowerShellben az alábbiak szerint:

Get-ClusterNode | Get-ClusterPerf -ClusterNodeSeriesName ClusterNode.Storage.Degraded

A kimenet például a következő lehet:

Object Description: ClusterNode Server1

Series                       Time                Value Unit
------                       ----                ----- ----
ClusterNode.Storage.Degraded 01/11/2019 16:26:48     214 GB

Windows Admin Center állapothibákkal állítja be a fürtcsomópontok állapotát és színét. A HCI-irányítópulton ez az új hiba lehetővé teszi, hogy a fürtcsomópontok pirosról (lefelé) sárga (újraszinkronizálás) zöldre (fel) váltson ahelyett, hogy egyenesen a pirosról a zöldre váltanának.

Az alábbi kép összehasonlítja a tárterület újraszinkronizálásának előrehaladását Windows Server 2016 és a Windows Server 2019 rendszerben.

Az újraszinkronizálás Windows Server 2016 és a Windows Server 2019 nézetének képe.

A tárterület teljes újraszinkronizálási folyamatának bemutatásával pontosan megállapíthatja, hogy mennyi adat nincs szinkronizálva, és hogy a rendszer halad-e előre. Az Windows Admin Center lépjen az Irányítópultra az új riasztás megtekintéséhez, ahogyan az alábbi képernyőképen látható:

A riasztás képernyőfelvétele Windows Admin Center.

A riasztás akkor hasznos, ha értesítést küld az újraszinkronizálásról, így nem vesz le véletlenül több kiszolgálót (ami több tartalék tartományt is érinthet, ami a fürt leállását eredményezheti).

Ha részletes képet szeretne kapni arról, hogyan jelenik meg a tárterület-újraszinkronizálás kiszolgálónként a Windows Admin Center, lépjen a Kiszolgálók lapra, kattintson a Leltár elemre, és válasszon ki egy adott kiszolgálót. Keresse meg a kiszolgálót, és tekintse meg a Tárterület diagramot, és nézze meg, hogy mennyi adatot kell javítani egy lila vonalban, pontosan a fölötte lévő számmal. Ez az összeg akkor nő, ha a kiszolgáló leáll (több adatot kell újraszinkronizálással szinkronizálni), és fokozatosan csökken, amikor a kiszolgáló újra online állapotba kerül (az adatok szinkronizálása folyamatban van). Ha a javítandó adatok mennyisége 0, a tárterület újraszinkronizálása befejeződött – szükség esetén most már szabadon leveheti a kiszolgálót.

Az alábbi képernyőképen a kiszolgáló nézete látható Windows Admin Center:

A kiszolgálónézet képernyőképe Windows Admin Center.

Tárterület-újraszinkronizálás monitorozása Windows Server 2016

A Windows Server 2019-es és újabb verzióiban elérhető riasztások segítenek átfogó képet kapni arról, hogy mi történik a tárolási rétegben. Összefoglalja a parancsmagból Get-StorageJob lekérhető információkat. Ez a parancsmag információkat ad vissza a tárolómodul hosszú ideig futó feladatairól, például egy tárterület javítási műveletéről, ahogyan az alábbi példakimenetben látható.

Get-StorageJob

Íme egy példa a kimenetre:

Name                  ElapsedTime           JobState              PercentComplete       IsBackgroundTask
----                  -----------           --------              ---------------       ----------------
Regeneration          00:01:19              Running               50                    True

Ez a nézet részletesebb, mert a tárolási feladatok kötetenként vannak felsorolva. Láthatja a futó feladatok listáját, és nyomon követheti azok egyéni előrehaladását. Ez a parancsmag Windows Server 2016 és 2019-ben is működik.

További hivatkozások