PowerFlex 3.X: Langzaam schrijven naar OS-schijf kan meerdere MDM-problemen veroorzaken.
Summary: Trage schrijfbewerkingen naar de besturingssysteemschijf kunnen meerdere MDM-problemen veroorzaken.
Symptoms
Er kunnen zich een aantal scenario's voordoen als gevolg van een trage schijf van het besturingssysteem op een MDM.
In ScaleIO 3.0 is het MDM-mechanisme robuuster gemaakt om problemen met zeer trage OS-schijven beter aan te pakken. (latentie van 10+ seconden)
Wanneer de MDM's worden uitgevoerd op besturingssysteemschijven die te lang duren om te schrijven, kunnen de volgende symptomen optreden:
-
Als u een SDS in onderhoud neemt, wordt de verbinding met de Master MDM verbroken.
-
Een rebuild event zorgt ervoor dat de Master MDM en mogelijk ook de Slave MDM's de verbinding verbreken.
-
MDM-switchover werkt niet; Slave MDM's kunnen de verantwoordelijkheden van Master MDM niet overnemen en dus is geen enkele MDM master.
-
Uitvoer van "scli --query_cluster" toont af en toe slave MDM's die niet gesynchroniseerd zijn.
-
SDC schrijft IO-fouten.
In alle scenario's wordt 'Harden duurde te lang' weergegeven in MDM trc-logboeken:
08/12 03:36:42.336327 0x7f64207f4eb0:replFile_WriteUnlocked:00667: WARNING: Harden took too long: 1360 ms 08/12 03:36:44.811987 0x7f6420668eb0:replFile_WriteUnlocked:00667: WARNING: Harden took too long: 1840 ms 08/12 03:36:46.463661 0x7f642072eeb0:replFile_WriteUnlocked:00667: WARNING: Harden took too long: 2210 ms
Impact
MDM-repo-schrijfbewerkingen die de harden-drempelwaarde overschrijden, betekent dat MDM niet wordt gesynchroniseerd.
Dit betekent dat het MDM-cluster niet wordt gesynchroniseerd en dat de MDM-processen opnieuw worden gestart.
Als MDM's snel/herhaaldelijk genoeg opnieuw worden opgestart, kunnen volledige data-niet-beschikbare scenario's (wanneer er geen Master MDM beschikbaar is), zoals in MDM-cluster, worden uitgeschakeld nadat er herhaaldelijk failovers kunnen optreden.
Cause
Wanneer de Master MDM wijzigingen moet aanbrengen in de status van datablokken, moet hij deze statuswijzigingen naar het MDM-repositorybestand schrijven en die wijzigingen vervolgens synchroniseren met de Slave-MDM's. Wanneer deze schrijfbewerkingen zijn voltooid, laat het MDM de SDS-exemplaren weten dat de wijzigingen zijn voltooid en kunnen ze schrijf-IO's alleen vanaf de primaire kopie naar de SDC's sturen (totdat het opnieuw opbouwen is voltooid). Als het langer dan 500 milliseconde (1/2 seconde) duurt voordat de Master MDM de wijzigingen naar de lokale repository heeft geschreven, worden de berichten "Harden took too long" weergegeven in de MDM trc-logboeken. Hierdoor kan de MDM niet snel genoeg reageren op de SDS-aanvragen en kunnen IO-fouten op de SDC's worden veroorzaakt. De MDM blijft in deze status totdat de IO in minder dan 500 milliseconden naar de repository kan schrijven of na 10 seconden wanneer eigendom van een MDM-switch plaatsvindt in het cluster.
Resolution
De oplossing bestaat erin het probleem met de latentie van de OS-schijf op te lossen.
Dit kan te wijten zijn aan:
-
RAID opnieuw opgebouwd (14G Ready Nodes hebben BOSS-kaarten met 2x M.2 SATA-schijven in RAID1)
-
Slijtage/veroudering van schijf
-
Onjuiste grootte/selectie van OS-schijven (HDD, trage/goedkope SSD, enz. Meestal alleen in softwareconfiguraties)
-
Bugs in OS-schijfcontroller/schijffirmware
-
Schijfstoring/voorspellende storingsstatus
-
Maar de meest voorkomende oorzaak is externe I/O-belasting van de OS-schijf.
In elk geval is het bewaken/profileren van de prestaties van de OS-schijf noodzakelijk.
Schijflatentie kan worden gecontroleerd door sar of iostat.
Het gemakkelijkste/meest universeel verkrijgbare hulpmiddel is jostat.
Voer
iostat -xtN 1
En observeer de wachttijden, gerapporteerd in milliseconden.
Dit geldt voor alle versies.