Microsoft TechNet Forum: 2008 R2 Failover Cluster – Überprüfung ok, aber erstellen schlägt fehl

Die Lösung war (sowohl bei dem Autor als auch bei mir) die Deinstallation des Features per Kommandozeile, ein Neustart, die erneute Installation per Kommandozeile und ein erneuter Neustart. Danach lies sich das Cluster problemlos erstellen. Die betreffenden Befehle zur Deinstallation und zur Installation sind:

dism /online /disable-feature /featurename:FailoverCluster-FullServer

zur Deinstallation und

dism /online /enable-feature /featurename:FailoverCluster-FullServer

zur erneuten Installation. Bitte auf die Groß-/Kleinschreibung achten, sonst kommt es zu einer Fehlermeldung. Die Hilfe zeigt dies auch noch einmal auf

Der Aufbau

Der Aufbau der Umgebung sieht grafisch wie folgt aus

In das Management-Netz wird nun ein weiterer Server mit dem DPM gestellt. Auf jeden der vier Hosts wird der DPM-Agent installiert, wenn man danach einen der Server in der DPM-Konsole hinzufügt werden automatisch alle weiteren Cluster-Knoten hinzugefügt (wenn man dies möchte). Nach dem Hinzufügen tauchen die vier Hosts nicht mehr einzeln, sondern als Cluster auf. Der DPM erkennt, dass es sich um ein Failover-Cluster handelt und behandelt dieses auch so.

Ohne die Installation weiterer Software sind wir nun in der Lage, Backups der VMs zu erstellen. Diese Backups werden allerdings vom DPM mit einer oder mehreren Fehlermeldungen begleitet

Warum ist dies so? Die von mir erstellte Schutzgruppe ist so konfiguriert, das täglich um 07.00 Uhr ein Backup der Gruppen-Mitglieder erstellt wird. Bei einem Backup-Vorgang müssen in meinem Fall 21 VMs gesichert werden.

Software vs. Hardware VSS Provider

Die Möglichkeit einer Live-Sicherung der VMs wird uns ermöglicht durch einen VSS-Snapshot (Volume Shadow Copy Service) der VM im Betrieb. Es gibt zwei Arten von Snapshot Providern:

Software VSS Provider

Dieser Provider ist im Windows enthalten. Bei Beginn eines Backups wird die Anbindung an das Storage-System umgeleitet, wir befinden uns im “Redirected Mode”. Dieser Modus wird genutzt, wenn ein Knoten keinen direkten Zugriff auf das CSV erhält. In diesem Fall wird der Zugriff auf das CSV ermöglicht, indem über einen anderen Knoten auf das CSV zugegriffen wird. Dies beugt einem Ausfall vor, allerdings verschlechtert sich hierdurch die Performance. Bei einem Backup wird die Anbindung an das CSV in den Redirected Mode geschaltet, wenn das Backup mit Hilfe des Software Providers erfolgt bleibt der Zugriff während des gesamten Backupzeitraums umgeleitet.

Der Zugriff der Hosts auf den Storage erfolgt im Normalzustand wie folgt:

Jeder Host ist (bestenfalls) redundant an den Storage angebunden. Diese Ansicht ändert sich, wenn wir uns im Redirected Mode befinden:

Man kann erkennen, dass der gesamte Traffic über den Coordinator Node läuft. Vorher hatten wir zwei x 1 GBit/s pro Knoten zur Verfügung, diese 8 GBit/s werden nun auf ein Viertel gedrosselt. Wenn sich in dem Cluster 16 Knoten befinden, die alle über einen einzigen Knoten kommunizieren, kann sich dies enorm (negativ) auf die Performance auswirken.

Hardware VSS Provider

Diese Art von Provider wird in der Regel von dem Storage-Hersteller zur Verfügung gestellt, man kann ihn wie einen Treiber für den Storage sehen. Bei der Erstellung eines Backups einer VM wird über den Hardware VSS Provider ein Snapshot auf dem Storage angestoßen, nach Erstellung des Snapshots werden die Daten vom DPM-Server abgeholt. Der Vorteil dieser Art von Provider ist der, dass der Zugriff auf das CSV nur während der Snapshot-Phase im umgeleiteten Modus ist. Nach diesem in der Regel recht kurzen Zeitraum wird der Zugriff wieder online geschaltet, in der Zeit wo die Daten vom Storage über den Host zum DPM-Server gesendet werden ist die Performance nicht durch eine Umleitung beeinträchtigt.

Ein interessanter Artikel mit weiteren Infos und mehr Hintergrund zum Thema “Redirected Mode” finden Sie hier: Ask the Core Team: Troubleshooting ‘Redirected Access’ on a Cluster Shared Volume (CSV)

Der Backup-Vorgang in Zeitlupe

Zur besseren Verständlichkeit hier beide Arten von Backup im Detail. Grundsätzlich gleich sind die vier Clusterknoten Hyperv4, Hyperv5, Hyperv6 und Hyperv7.

Software VSS Provider

Auf dem Data Protection Manager beginnt laut Zeitplan die Sicherung von vWinXPTest. Diese VM befindet sich aktuell auf Hyperv4. Besitzer des CSV ist Hyperv6.

Im DPM startet nun die Sicherung. Als erstes wechselt der Besitzer des Clustervolumes zu dem Besitzer der VM, danach beginnt die Erstellung des VSS-Snapshots. Man erkennt den Backup-Vorgang am Status des CSV.

Dieser Status bleibt nun so lange bestehen, bis das Backup beendet ist. Im Taskmanager auf Hyperv4 erkennt man, dass über das Management-Netzwerk die Daten in Richtung DPM geschickt werden und über die beiden iSCSI-Netzwerke vom SAN geholt werden.

Hardware VSS Provider

Auf dem Data Protection Manager beginnt laut Zeitplan die Sicherung von vWinXPTest. Diese VM befindet sich aktuell auf Hyperv4. Besitzer des CSV ist Hyperv6.

Im DPM startet nun die Sicherung. Als erstes wechselt der Besitzer des Clustervolumes zu dem Besitzer der VM, danach beginnt die Erstellung des VSS-Snapshots. Man erkennt den Backup-Vorgang am Status des CSV. Bis zu diesem Punkt ist die Sicherung gleich, zumindest sieht es für uns so aus. Im Hintergrund wird nun auf dem SAN ein Snapshot angestoßen. Während der Zeit des Snapshots befindet sich das CSV im Umgeleiteten Modus, im Failovercluster-Manager wird der Status angezeigt.

Nachdem der Snapshot auf der NetApp gemacht wurde, wechselt der Status des CSV in den folgenden Modus

Dies bleibt noch eine kurze Zeit so, danach wechselt der Status auf grün (online) und der Zugriff ist ohne eine Umleitung über den Coordinator Node möglich. Die Sicherung ist in diesem Fall allerdings noch nicht fertig, im Hintergrund werden noch fleißig Daten übertragen bzw. geprüft, welche Daten sich geändert haben. Dies ist im Taskmanager erkennbar.

Fazit

Beim Einsatz eines Failover-Cluster sollte man sehr genau darauf achten, dass das genutzte SAN einen Hardware VSS Provider mitbringt. Man verkürzt die Zeit, in der sich das Cluster im Redirected Mode befindet erheblich. Weiterhin wird die Dauer der Gesamtsicherung verkürzt. Ein Failover-Cluster sollte so wenig wie möglich im Redirected Mode betrieben werden, unterstützende Software seitens des SAN-Herstellers helfen hierbei.

Laut Datenblatt hat die GreenBytes eine Quad Core CPU, 12 GB RAM, eine 32 GB große SSD für das Betriebssystem, zwei 25 GB große SSDs für den Cache und acht 500 GB große Festplatten, allesamt 2,5” groß. Zur Anbindung an das Netzwerk sind zwei 1 GbE-Adapter vorhanden sowie einen weiteren 1 GbE-Adapter für das Management. Weitere Daten stellt das Datenblatt bereit.

Nach dem Start des Geräts wird man von einem OpenSolaris begrüßt. Man kann sich zwar an der Konsole anmelden, kann dort aber nichts GreenBytes-relevantes einstellen. Administriert wird das Gerät über den “GreenBytes Storage Manager”, ein MMC-SnapIn. Das sieht dann wie folgt aus:

Die Benchmark-Tests:

Der erste Test, den ich durchgeführt habe”, war das Messen der Geschwindigkeit mit dem Programm “CrystalDiskMark”.

Hier ein Test der Geschwindigkeit auf ein 500 GB großes Volume, inkl. aktivierter Kompression und De-Duplizierung (hierzu später mehr):

Hier der gleiche Test, allerdings mit deaktivierter Kompression und De-Duplizierung:

Hier zum Vergleich die beiden lokalen 300 GB SAS 15k-Festplatten:

Was sich extrem bemerkbar macht sind die hohen Werte bei den Tests “4K” und “4k QD32”. Vergleichen kann man die Werte mit den folgenden: Hyper-V-Server.de: Ein guter Server zum Virtualisieren

Als nächstes habe ich neun virtuelle Server auf einem unserer Hyper-V-Hosts hinzugefügt und die Festplatten auf dem verbundenem iSCSI-Volume gespeichert. Da das größte Problem bei solchen externen Speicher-Systemen die Performance und die Latenz ist, wollte ich mir einen Eindruck darüber verschaffen, wie sich diese Server verhalten im Betrieb. Genaue, messbare Werte konnte ich nicht ermitteln, allerdings hat man ja ein Gefühl dafür, ob ein System nun träge ist oder ob sich das Verhalten mit einem System auf direkt angeschlossenen Festplatten vergleichen lässt.

Mit aktivierter Kompression und De-Duplizierung war das Verhalten dieser neun Maschinen schon beachtenswert, Operationen mit einer gewissen Anzahl von I/O-Vorgängen (Starten der Maschine, Herunterfahren, Suchen nach allen Dateien auf Laufwerk C…) waren zufriedenstellend, selbst bei dieser Art des Betriebs.

Einen weiteren Performance-Schub habe ich bekommen, nachdem ich die Maschinen auf einem Volume gespeichert habe, auf dem sowohl die Kompression als auch die De-Duplizierung deaktiviert war. Wie schon an den Benchmark-Werten oben sichtbar steigen die Werte je nach Art des Benchmark-Tests um fast das fünffache im Schreib-Modus.

Eine noch weiter verbesserte Performance bekommt man, wenn man pro virtuellem System ein (oder mehrere) Volume(s) erstellt und diese direkt mit der virtuellen Maschine verbindet. Hierdurch verliert man allerdings einige Vorteile, z.B. die Möglichkeit eines Exports, der Verlust wird aber weitestgehend durch die Snapshot-Möglichkeit der GB-1000 wett gemacht.

Das Hyper-V Failover-Cluster:

Als nächstes stand das Einrichten eines Failover-Clusters auf dem Plan. Aus Zeitgründen konnten wir bis zum aktuellen Zeitpunkt nur zwei Maschinen hochverfügbar machen, allerdings ergibt sich hierbei schon ein interessantes Detail:

Aktuell sind 13,7 GB genutzt, und zwar durch zwei Windows Server 2008 R2. Nur durch die Kompression und die De-Duplizierung schafft die GB-1000 eine Reduzierung des Speicherplatzes von 22,36 GB auf 13,7 GB. Wie man in dem Screenshot erkennt sind das 38,73 %. Wenn das Verhältnis so bleibt könnten auf den eigentlich nur 3,16 TB großen Festplatten insgesamt 5,16 TB an Daten gespeichert werden. Für die Virtualisierung aus Performance-Gründen nicht ganz sinnvoll, für ein NAS-System allerdings schon ein geiles Feature :)

Die Maschinen liefen sehr performant und ohne kleine Hänger/Aussetzer im Betrieb, wie es manchmal bei langsamen iSCSI-Volumes der Fall ist. Hier einige Screenshots des Clusters und eines Umzugs einer virtuellen Maschine:

Das hier vorgestellte Modell GB-1000 mit 8 x 500 GB plus SSD kostet Liste 13200 €. Vergleichbare Systeme anderer Hersteller bewegen sich teilweise in weitaus höheren Regionen, von daher ist dieses Gerät an sich schon ziemlich günstig. Trotz des geringen Preises schlägt sich die GreenBytes sehr gut und liefert sehr souveräne Werte ab. Wir hatten während der Teststellung einen durchweg positiven Eindruck von dem Gerät und können das Gerät als NAS oder SAN empfehlen.

Die meisten Arbeiten können wir mit dem grafischen Tool „Failovercluster-Manager“ erledigen, dieses gilt auch nachher für die Betriebsphase.

Eine Neuerung bei dem Cluster unter Windows Server 2008 sind die Prüfungsvorgänge, somit lässt sich die Grundkonfiguration im Vorfeld prüfen.

Wir rufen also zunächst den Punkt „Konfiguration überprüfen auf“.

Hier werden die Namen der Hyper-V Servers eingegeben, in unserem Beispiel HyperV1 und HyperV2

Die Testoptionen auswählen.

Nach Abschluss des Testlaufes wird ein html Bericht generiert, in welchem sehr detailliert die Ergebnisse aufgelistet werden. Falls Probleme erkannt worden sind werden recht konkrete Handlungsschritte bereitgestellt.

Man sollte dringend die Tests solange durchführen bis keinerlei Probleme oder Warnungen mehr auftauchen. Zwar ist eine Clusterinstallation auch früher möglich, allerdings werden Installationen die kein grünes Zeichen bekommen von Microsoft nicht Supportet. Des weiteren können die Warnungen und Probleme nachher zu weiteren Schwierigkeiten führen, die sich im Nachhinein nur schwer diagnostizieren lassen.

Cluster erstellen.

Nachdem keine Warnungen und Probleme mehr auftauchen kommen wir zur eigentlichen Installation des Clusters. Wir wählen den Punkt „Cluster erstellen“.

Zunächst werden die Server ausgewählt, welche im Cluster initial aufgebaut werden sollen.

Folgende Dialog Seite ist ziemlich wichtig. Falls bei dem letzten Validierungstest Warnungen aufgetreten sind, wird darauf hingewiesen, dass die Cluster Konfiguration von Microsoft nicht Supportet wird. Es besteht die Möglichkeit den Test zu wiederholen. (Eventuell sind die Fehler und die gemeldeten Probleme ja behoben worden)

Falls keine Probleme erkannt werden kann im nächsten Schritt der Clustername und die dazu gehörige IP Adresse hinterlegt werden. Diese Adresse dient zur Verwaltung über den Cluster.
Es wird eine neue Adresse benötigt, keine Adresse aus einem Clusterknoten!

Im Anschluss ist der Assistent durchgearbeitet und das Cluster wurde erstellt.

Ausblick Teil 6:Konfiguration des Clusters

Als iSCSI Target dient der von Microsoft bereit gestellte iSCSI, welcher über MSDN Abo bezogen werden kann. Nähere Information wie man ein solches MSDN Abo bekommt gibt es hier.

Nach erfolgreicher Installation wird unter Server Manager -> Storage die Microsoft iSCSI Software Target aufgelistet.

Mit „rechtsklick“ auf ISCSI Target kann ein neuer Target angelegt werden.

Hier muss der Name des iSCSI Targets vergeben werden. Optional kann noch eine Beschreibung hinzugefügt werden.

Im nächsten Schritt müssen die iSCSI Initiator ausgewählt werden welche Zugriff auf den Target bekommen sollen:

Anschließend ist der Wizard durchlaufen und die Virtual Disk für den iSCSI Target können erstellt werden.

Dazu machen wir wieder einen „rechtsklick“ auf unseren gerade erstellten iSCSI Target (in meinem Beispiel „Storage1“) und wählen den Punkt „Create Virtual Disk for iSCSI Target“.

Wieder öffnet sich ein Wizard der bei der Erstellung der Virtuellen Festplatte hilft.

Dies ist der Pfad wo die Virtuellen Disk gespeichert werden.

Größe der Virtuellen Festplatte.

Anschließend kann noch eine Beschreibung angegeben werden und der Wizard ist durchlaufen.

Für die Live Migration werden Mindestens zwei iSCSI Bereiche benötigt.

Ein Teil muss nicht größer als ca. 100MB sein, dieser wird als Quorum verwendet. Darauf werden die „Cluster internen“ Daten abgelegt,

Der zweite(und dritte, vierte, fünfte etc. ) Bereich wird für die Daten verwendet.

Konfiguration des iSCSI Initialtor

 
Auf dem Hyper-V Server muss nun der iSCSI-Initiator konfiguriert werden, eine grafische Oberfläche bekommt man mit der Eingabe von “iscsicpl”, hier von Carsten Rachfahl erklärt.

Im Feld Ziel wird die IP Adresse, DNS Name oder IQN Name des iSCSI Target eingetragen.

Konfiguration der Datenträger

Bei der Datenträger Konfiguration kommt unser Windows 7 mit RemoteTools ins Spiel.
Per WMI greifen wir auf die Datenträgerverwaltung des Hyper-V-Servers zu, wo nun die zwei neuen Datenträger erscheinen sollten. Die iSCSI Ressourcen sind von „normalen“ Festplatten nicht zu unterscheiden, deshalb sollte hier mit Vorsicht gehandelt werden!
Die neuen Datenträger müssen nun noch Online geschaltet werden damit diese Formatiert werden können. Es ist nicht nötig einen Laufwerksbuchstaben zu vergeben, da dieses ohnehin bei der Clusterinstallation modifiziert wird.

Ausblick Teil 5: Installation des Clusters

Im Rahmen meiner Projektarbeit zur Abschlussprüfung zum Fachinformatiker für Systemintegration war es meine Aufgabe eine kostengünstige Hochverfügbarkeitslösung zu finden. Die Wahl viel wie nicht anders zu vermuten als Microsoft Gold Partner auf Hyper-V. Aus Kostengründen haben wir uns für den Hyper-V Server und den Windows Storage Server entschieden.

In dieser Reihe möchte ich die Live Migration mit Hyper-V vorstellen und demonstrieren wie ein Failovercluster installiert wird. Die Live-Migration beinhaltet das transparente verschieben einer virtuellen Maschine von einem physikalischen Host auf einen anderen. Der Vorteil an der Live-Migration ist, wenn ein Administrator eine Wartung oder ein Problem an einem physikalischen Host feststellt, kann die darauf laufende Instanz einfach auf ein anderes System migriert werden ohne das angebundene Clients die Verbindung zu der Maschine verlieren oder die virtuelle Maschine etwas davon bemerkt. Dadurch werden Ausfälle von Instanzen gering gehalten und Arbeitsausfälle vermieden.

Ich werde von der Installation der Server bis hin zur Live-Migration meine Schritte erklären.
In den ersten Teil möchte ich zeigen wie wir das Projekt Realisiert haben (siehe Grafik).

Auf die Einzelheiten der verwenden Hard und Software und der Grund warum wir sie so gewählt haben komme ich im Verlauf dieser Reihe noch zu sprechen wenn die einzelnen Punkte konfiguriert werden.

Ausblick:

Im zweiten Teil der Reihe gehe ich auf die Installation und Konfiguration der Hyper-V Server ein.