Förstå och övervaka omsynkronisering av lagring

Gäller för: Azure Stack HCI, versionerna 22H2 och 21H2; Windows Server 2022, Windows Server 2019

Omsynkronisering för lagring är en funktion för Lagringsdirigering i Azure Stack HCI och Windows Server. Det gör att hälsotjänsten kan utlösa ett fel och meddela dig om omsynkronisering. Detta förhindrar att du oavsiktligt tar bort fler servrar, vilket kan påverka flera feldomäner som resulterar i att klustret går ned.

Den här artikeln innehåller en översikt över omsynkronisering av lagring och hur du kan övervaka den i ett redundanskluster med Lagringsdirigering.

Om omsynkronisering av lagring

Vi börjar med ett enkelt exempel för att förstå hur lagringen kan bli osynkroniserad. Tänk på att den distribuerade lagringslösningen shared-nothing (endast lokala enheter) uppvisar det här beteendet. Följande avsnitt visar hur lagringen blir osynkroniserad när en servernod slutar fungera. Dess enheter uppdateras inte förrän de är online igen – det här beteendet gäller för alla hyperkonvergerade arkitekturer.

Anta att du vill lagra strängen "HELLO".

Förutsatt att du har trevägs speglingsåterhämtning har du tre kopior av den här strängen. Om du tar ned server 1 tillfälligt (för underhåll) kan du inte komma åt kopiering nr 1.

Anta att du uppdaterar strängen från "HELLO" till "HELP!" just nu.

När du har uppdaterat strängen uppdateras kopiera nr 2 och 3. Det går dock inte att komma åt copy #1 eftersom server 1 är tillfälligt nere (för underhåll).

Nu har du kopiera #1 med data som inte är synkroniserade. Operativsystemet använder detaljerad spårning av smutsiga regioner för att hålla reda på vilka bitar som inte är synkroniserade. På så sätt kan du synkronisera ändringarna när server 1 är online igen genom att läsa data från kopia nr 2 eller 3 och skriva över data i kopia nr 1. Med den här metoden behöver du bara kopiera över dessa data som är inaktuella, i stället för att synkronisera om alla data från server nr 2 eller server 3.

I föregående avsnitt beskrivs hur data kan bli osynkroniserade. Men hur ser det ut på en hög nivå? Anta att du har ett hyperkonvergerat kluster med tre servrar. När server 1 är under underhåll ser du att den är nere. När du säkerhetskopierar server 1 börjar den synkronisera om all lagring med hjälp av detaljerad spårning av smutsiga regioner (förklaras i föregående avsnitt). När alla data är synkroniserade igen visas alla servrar som upp.

Följande GIF visar hur lagringssynkronisering fungerar i ett hyperkonvergerat kluster:

Så här övervakar du lagringssynkronisering

Från och med Windows Server 2019 lade vi till ett nytt fel i hälsotjänsten som visas när lagringen synkroniseras om.

Om du vill visa det här felet i PowerShell kör du följande cmdlet:

Get-HealthFault

Det här nya felet visas i PowerShell, i klusterverifieringsrapporten och någon annanstans som bygger på hälsofel.

För att få en djupare vy kan du köra frågor mot tidsseriedatabasen i PowerShell på följande sätt:

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

Här är ett exempel på utdata:

Object Description: ClusterNode Server1

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

Windows Admin Center använder hälsofel för att ange status och färg för klusternoderna. På HCI-instrumentpanelen gör det här nya felet att klusternoderna kan övergå från rött (nedåt) till gult (omsynkroniseras) till grönt (uppåt) i stället för att gå direkt från rött till grönt.

I följande bild jämförs hur omsynkronisering av lagring fortskrider i Windows Server 2016 jämfört med Windows Server 2019.

Genom att visa den övergripande förloppet för omsynkronisering av lagring kan du korrekt veta hur mycket data som är osynkroniserade och om systemet går framåt. I Windows Admin Center går du till instrumentpanelen för att se den nya aviseringen, som du ser på följande skärmbild:

Aviseringen är användbar för att meddela dig när omsynkronisering sker, så att du inte oavsiktligt tar bort fler servrar (vilket kan orsaka att flera feldomäner påverkas, vilket resulterar i att klustret går ned).

Om du vill få en detaljerad vy över hur lagringssynkronisering visas per server i Windows Admin Center går du till sidan Servrar, klickar på Inventering och väljer sedan en specifik server. Gå till servern och titta på diagrammet Lagring för att se mängden data som behöver repareras i en lila linje med ett exakt tal precis ovanför. Den här mängden ökar när servern är nere (mer data måste synkroniseras om) och minskar gradvis när servern är online igen (data synkroniseras). När mängden data som behöver repareras är 0 görs omsynkronisering av lagringen– du kan nu ta ned en server om du behöver.

Följande skärmbild visar servervyn i Windows Admin Center:

Övervaka omsynkronisering av lagring i Windows Server 2016

Aviseringen som är tillgänglig i Windows Server 2019 och senare är användbar för att få en holistisk bild av vad som händer på lagringsskiktet. Den sammanfattar den information som du kan få från cmdleten Get-StorageJob . Den här cmdleten returnerar information om långvariga lagringsmoduljobb, till exempel en reparationsåtgärd på ett lagringsutrymme, enligt följande exempelutdata.

Get-StorageJob

Här är ett exempel på utdata:

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

Den här vyn är mer detaljerad eftersom lagringsjobben visas per volym. Du kan se listan över jobb som körs och du kan spåra deras enskilda förlopp. Denna cmdlet fungerar på både Windows Server 2016 och 2019.

Ytterligare referenser

• Koppla från en server för underhåll
• Översikt över Lagringsdirigering