Aus der Praxis: Austausch einer defekten NVMe in einem S2D Cluster
Bei einem Kunden von uns hat eine NVMe einen IO Error angezeigt und musste daraufhin ausgetauscht werden. Die NVMe war als Caching Device in einen 4 Knoten S2D Cluster verbaut. Ich möchte euch hier kurz schildern, wie wir auf den Fehler aufmerksam wurden und welche Schritte notwendig waren, um die NVMe zu ersetzen.
Kurz zur Hardware, es sind 4 Fujitsu Server mit je 4 x Intel P3700 800GB NVMe's und 20 Seagate 2TB HDDs für den Storage Spaces Direct Pool.
Fehlersuche:
Als ersten Indiz haben wir festgestellt, dass Repairjobs laufen, ohne dass einer der Server neu gestartet wurde. Daraufhin habe ich mit "Get-PhysicalDisk" die Festplatten überprüft und musste feststellen, dass ein Caching Device und wechselnde Festplatten IO Errors anzeigen. Unten ein kurzes Beispiel der Ausgabe.
Anhand der Seriennummern konnten alle fehlerhaften Festplatten einem Host zugeordnet werden. Die NVMe zeigte dauerhaft den IO Error an, bei den HDDs tauchte der Fehler sporadisch auf. Aber ich konnte die IO Errors auf den HDDs auf 5 Stück eingrenzen und damit war mir klar, dass diese Festplatten alle der defekten NVMe zugeordnet waren. Auf der Suche nach weiteren Infos zur Usache, bin ich auch noch auf folgende Eventlog Einträge gestoßen.
Austausch der NVMe:
Vor dem Austauch, wurden alle Rollen von dem betroffenen Host verschoben und der Host auf "Pause" gesetzt und heruntergefahren.
Der Fujitsu Support hat sich entschlossen, den Controller für die NVMe's und die fehlerhafte NVMe auszutauschen. Nachdem der Server wieder hochgefahren war, ergab ein weiterer "Get-PhysicalDisk" Befehl dass nun 2 NVMe und 10 HDDs auf "Lost Communication" standen. Die neue NVMe war nicht zu sehen. Alle Festplatten befinden sich in dem Server, bei dem gerade die Komponenten getauscht wurden.
Was war die Ursache für die fehlen der Festplatten? Es musste ja etwas mit dem Tausch der Komponenten zu tun haben. Letztlich hat sich herausgestellt, dass zwei der vier NVMe's nicht richtig gesteckt waren. Als dieser Mangel beseitigt war, wurden alle NVMe (die alte und auch die neue) korrekt angezeigt. Bei den HDDs waren nach wie vor 5 Festplatten auf "Lost Communication"
Wir sehen, die defekte NVMe wird mit "Lost Communication" angezeigt und die neue NVMe ist noch nicht im Storagepool. An dieser Stelle ein dickes Danke schön für den sehr hilfreichen Blogpost von Jan-Tore Pedersen der genau beschreibt, welche weiteren Schritte nun zu tun sind.
Als nächster Schritt muss die defekte NVMe auf "retired" gesetzt werden.
Jan-Tore Pedersen beschreibt in seinem Blogpost, dass die neue NVMe nun per PowerShell Befehl zum StoragePool hinzugefügt werden muss. Das habe ich versucht, doch ich bekam daraufhin folgenden Fehler angezeigt.
Die neue NVMe war bereits als Caching Device im Storagepool. Das erfolgte wohl automatisch nachdem ich die defekte NVMe auf "retired" gesetzt hatte.
Eine weitere Überprüfung der Festplatten mit "Get-PhysicalDisk" zeigt, dass die 5 HDDs, die der defekten NVMe zugeordnet waren, immer noch mit "Lost Communication anzeigten werden. Die HDDs müssen in einem weiteren Schritt der neuen NVMe zugeordnet werden.
Es dauerte ein paar Minuten, bis alle Festplatten wieder mit "OK" und "Healthy" angezeigt werden. Jetzt muss nur noch die defekte NVMe aus dem StoragePool entfernt werden.
Zum Abschluss überprüfen wir mit "Get-StorageJob" , ob die Repair Jobs angelaufen sind. Es kann einige Zeit dauern, bis alle Repair Jobs abgearbeitet wurden, aber das soll uns nicht daran hintern, den Knoten wieder aus dem Pause Modus zu nehmen und ihm seine Rollen zu übertragen.
So, ich hoffe, ich konnte euch mit dieses Blogpost zeigen, wie eine NVMe aus einem S2D Cluster getauscht werden kann und welche Probleme dabei auftreten können. Bedenkt immer, dass all diese Befehle mit Vorsicht und Bedacht ausgeführt werden müssen, da ja meist ein Produktivsystem davon betroffen ist.
Viel Erfolg bei eurer Arbeit und bis zum nächsten Mal
Petra
