Verhalten eines Scale-Out File Servers beim Ausfall eines Datenträgers
In diesem Beitrag möchte ich einmal darauf eingehen, wie sich ein Scale-Out File Server verhält, wenn Ressourcen ausfallen. Festplatten sind ja in einem Storage häufig die Ursache für Warnmeldungen und der Grund für den Anruf beim Hersteller. Da wir für unseren Hyper-V Powerkurs eine eigene SOFS-Hardware zur Verfügung haben, zeige ich hier einmal, was bei einem Ausfall von einem Datenträger gemacht werden muss und wie sich das System in solch einem Fall verhält.
Wir beginnen mit einer kurzen Erklärung der Umgebung und der Konfiguration, die vorgenommen wurde:
Zwei Server sind zu dem Failover Cluster-Verbund zusammengeschlossen. Jeder Server besitzt eine lokale SSD für das Betriebssystem, 16 GB RAM, zwei 1 Gb/s Ports und zwei 10 Gb/s RDMA Netzwerkkarten. Zusätzlich ist in jedem Server ein LSI Quad-Port SAS HBA verbaut, der eine redundante Anbindung an ein Intel JBOD besitzt.
In diesem Intel JBOD stecken insgesamt vier 200 GB große SSDs und 15 mal 1 TB große Festplatten. Jeder der beiden Server ist an jeweils einen der SAS Controller angebunden.
Nach der Installation von Windows Server 2012 R2 in der Standard-Edition werden erst einmal beide Systeme auf den aktuellen Patchlevel von Mai 2016 gebracht. Nun beginnt die Einrichtung mit der Installation der benötigten Rollen und Features, gefolgt von einer Aktivierung von MPIO für SAS und einem Neustart der Systeme. Nach diesem Neustart lasse ich mir die Datenträger per PowerShell anzeigen:
Nun beginnt die Überprüfung der beiden Server gegeneinander, um die Nutzung als Failover Cluster zu verifizieren:
Das Ergebnis meldet eine Warnung, die wie folgt aussieht:
Das fehlende Standardgateway ist kein Problem, es bedeutet lediglich, dass ich später das Management-Netzwerk manuell definieren muss. Wir beginnen nun mit der Installation des Failover Cluster.
Das Cluster wurde erfolgreich gebildet, nun erfolgt die weitere Einrichtung und die Konfiguration des Quorum.
Wir beginnen mit der Erstellung des Pools und dem Hinzufügen aller Festplatten in diesen Pool:
Nun können wir unseren Quorum-Datenträger anlegen:
Nun legen wir einen Dummy-Datenträger an, der nach der Erstellung der Produktiv-Datenträger wieder gelöscht wird. Dies garantiert, dass ausreichend Speicherplatz im Pool vorhanden ist, so das ein automatischer Rebuild passiert, sobald ein Datenträger ausfällt.
Im nächsten Schritt legen wir Datenträger an, die unsere Produktiv-Laufwerke darstellen. Ein Datenträger ist geschützt durch einen 3-Wege-Spiegel, der andere durch eine Duale Parität.
Nun werden die Datenträger formatiert und mit einem NTFS-Dateisystem ausgestattet. Der Dummy-Datenträger wird wieder gelöscht (Da er den gleichen Namen hat wie das Quorum, hier eine Identifizierung per ID. Copy/Paste-Fehler ;) ).
Nun kann der eigentliche Dateiserver installiert und eingerichtet werden.
Nun werden die entsprechenden Shares angelegt und konfiguriert.
Aktuell sehen die Eigenschaften des Pools wie folgt aus:
Primär geht es hier um die Einstellung “RetireMissingPhysicalDisks”. Diese steht aktuell auf “Auto”, diesen Wert stellen wir um auf “Always” laut der Empfehlung von Microsoft: Replace Failed Disks and Repair JBODs for Storage Spaces in Windows Server
Nach der Anpassung:
Das Entfernen einer Festplatte
Nachdem das System nun konfiguriert und eingerichtet ist, ziehe ich per Hand eine der Festplatten heraus. Die Festplatte erscheint erst wie folgt:
Nun dauert es eine kurze Zeit, bis die Festplatte vom HealthStatus “Warning” in den Status “Retired” wechelt. An dieser Stelle sollte nun eigentlich eine automatische Reparatur meiner Datenträger stattfinden. Dies ist in genau diesem Fall allerdings nicht so, die virtuellen Datenträger bleiben im Modus “Degraded”. Dies liegt daran, dass ich mit der maximalen Anzahl an Columns gearbeitet habe. Ein 3-Wege-Spiegel mit einer Column-Anzahl von fünf benötigt mindestens 15 Datenträger, damit er vollständig ist. Verringert sich durch einen Ausfall von einem oder mehreren Datenträgern diese Anzahl, ist die vDisk nicht vollständig und kann sich nicht wiederherstellen. Wie sich der Aufbau bei einer kleineren Column-Anzahl verhält zeige ich später, an diesem Punkt stecke ich die gezogene Festplatte erst einmal wieder in das Enclosure.
Nachdem ich die Festplatte nun wieder eingesteckt habe, muss ich den Status der Festplatte wieder umsetzen auf “Auto-Select”. Danach kann ich die Reparatur der vDisks anstoßen:
Die Reparatur-Dauer ist natürlich abhängig von der Größe und der Menge der Platten, ist dann aber erfolgreich:
Den gleichen Vorgang kann ich dann bei der zweiten vDisk ebenfalls wiederholen:
Der optimale Aufbau von virtuellen Datenträgern (Virtual Disks)
Damit auch bei dem Ausfall von einer Festplatte die vDisks wiederhergestellt werden können, muss die genutzte Column-Zahl optimal eingestellt sein. Nachdem ich alle virtuellen Datenträger wieder gelöscht habe, erstelle ich insgesamt fünf neue Datenträger. Einer dieser vDisks wird als Quorum genutzt, die anderen vier Datenträger als Cluster Shared Volumes.
Nun ziehe ich eine Festplatte aus dem Enclosure heraus und beobachte das Verhalten. Den gesamten Vorgang habe ich in einem Video aufgenommen, welches hier betrachtet werden kann:
IT-Cast.de: Ausfall einer Festplatte in einem Microsoft Storage Space Pool
In dem Video kann man sehr gut erkennen, dass es trotz einer gezogenen Festplatte zu einer Wiederherstellung der virtuellen Datenträger kommt. Nach Abschluss der Reparatur werden alle Datenträger wieder als “Healthy” aufgeführt. Man kann in dem oberen Screenshot sehr gut erkennen, dass die “NumberOfColumns” bei den Datenträgern bei drei (FSQuorum), vier (die beiden 3-Wege-Mirror Datenträger) bzw. sieben (die beiden Dual-Parity Datenträger) liegt.
Resultat
Die hier aufgeführten Ergebnisse zeigen, dass die Anzahl der Columns eine sehr wichtige Rolle bei der Verfügbarkeit der Datenträger spielen. Wird die Anzahl falsch konfiguriert, ist unter Umständen keine Reparatur der vDisks möglich und man kann die Reparatur erst starten, wenn der Austausch-Datenträger eingetroffen ist. Obwohl die Reduzierung der Anzahl um eins vielleicht im ersten Moment sinnlos und verschwenderisch klingt, so macht sich diese Entscheidung bei dem Ausfall der ersten Festplatte sofort positiv bemerkbar.
