Verhalten eines Scale-Out File Servers beim Ausfall eines Datenträgers | Hyper-V Server Blog

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:

image

image

Nun beginnt die Überprüfung der beiden Server gegeneinander, um die Nutzung als Failover Cluster zu verifizieren:

image

image

image

image

Das Ergebnis meldet eine Warnung, die wie folgt aussieht:

image

image

image

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.

image

image

Das Cluster wurde erfolgreich gebildet, nun erfolgt die weitere Einrichtung und die Konfiguration des Quorum.

image

Wir beginnen mit der Erstellung des Pools und dem Hinzufügen aller Festplatten in diesen Pool:

image

image

Nun können wir unseren Quorum-Datenträger anlegen:

image

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.

image

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.

image

image

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 ;) ).

image

Nun kann der eigentliche Dateiserver installiert und eingerichtet werden.

image

image

image

image

Nun werden die entsprechenden Shares angelegt und konfiguriert.

image

image

Aktuell sehen die Eigenschaften des Pools wie folgt aus:

image

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

image

Nach der Anpassung:

image

 

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:

image

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:

image

image

image

Die Reparatur-Dauer ist natürlich abhängig von der Größe und der Menge der Platten, ist dann aber erfolgreich:

image

image

Den gleichen Vorgang kann ich dann bei der zweiten vDisk ebenfalls wiederholen:

image

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.

image

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.

Jan Kappen
 

Jan Kappen ist ausgebildeter Fachinformatiker in der Richtung Systemintegration. Er hat seine Ausbildung im Sommer 2008 abgeschlossen und arbeitete bis August 2018 bei der Rachfahl IT-Solutions GmbH & Co. KG. Seit September 2018 arbeitet er als Senior Netzwerk- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland. Jan Kappen ist unter anderen MCITP Server Administrator, Enterprise Administrator und Enterprise Messaging Administrator 2010 sowie MCTS für System Center Virtual Machine Manager 2008, Windows Server 2008 Active Directory, Windows Server Virtualization und Windows Server 2008 Network Infrastructure. Seit 2015 wird Jan Kappen im Bereich "File System Storage" bzw. "Cloud & Datacenter Management" für seine Expertise und seine Community-Arbeit mit dem MVP Award von Microsoft ausgezeichnet.

  • Jan sagt:

    Hallo Jan,
    wir haben einen bestehenden Storage Pool mit bestehenden Virtual Disks jetzt mit weiteren SSDs und HDDs erweitert. Besteht die Möglichkeit das man für die bestehenden Virtual Disks die NumberOfColumns im nachhinein erhöht? Als Betriebssystem ist Windows Server 2012 R2 im Einsatz und genügend weitere SSDs & HDDs sind vorhanden.
    Gruß und schönes Wochenende,
    Jan

  • Jan Kappen sagt:

    Hallo Jan,
    nein ist nicht möglich, nur durch auflösen und neu erstellen.
    Gruß, Jan

  • Jan sagt:

    Danke! Das habe ich schon geahnt… Da hat Microsoft ja richtig mitgedacht…

  • Jan Kappen sagt:

    Ist nicht schön, wurde aber von Anfang an so kommuniziert, dass es nicht nachträglich geht.
    Gruß, Jan

  • >