Windows Server Failover Cluster unter VMware

Dieses Thema ist noch nicht vollständig! Es wird noch daran gearbeitet!

Das wird hier eine Sammlung zu einem Windows File Failover Cluster unter VMware 7.0 - ist noch in Arbeit!

---

Changelog:

• 04.08.2021 erste Version
• 31.08.2023 Anpassungen an Server 2022

---

Vorbereitung

ESX Hosts

Es werden mindestens 2 ESXi Hosts mit VMware vSphere 7.x benötigt welche über FC (FibreChannel) mit einem Storage verbunden sind. Das Storage muss den beiden ESXi-Servern mindestens 2 LUNs präsentieren, eine für die VMs selbst und ein Datenspeicher auf dem nur die Cluster-VMDKs liegen.
Die beiden Clusterknoten können NICHT auf dem gleichen ESXi-Host laufen. Das Teilen des SCSI-Busses der VMs erfolgt in der Einstellung "Physisch", und das klappt nur wenn die VMs nicht auf dem gleichen Host laufen.

---

Datenspeicher

Wir brauchen einen "normalen" VMFS Datenspeicher, ganz normal wie immer. Auf diesem liegen die VMs der Cluster-Knoten.
Also die VM mit Ihren Konfigurationsdateien und Festplatte **C:**

Für die Cluster-Festplatte, also die VMDK-Datei auf welche die einzelnen Windows-Cluster-Knoten einen gemeinsamen Zugriff haben sollen, benötigen wir einen VMFS-Datenspeicher mit aktivierter Cluster-VMDK Unterstützung:

Die Option dafür hat man unter folgenden Bedingungen:

• vCenter-Server 7.0.0 oder höher
• Alle ESXi-Server die auf den Datenspeicher zugreifen müssen ESXi 7.0.0 oder höher sein
• Der Datenspeicher wurde mit VMFS 6 formatiert und den Hosts hinzugefügt
• Im Anschluss wurde die Cluster-VMDK Option aktiviert. Geduld, dauert eine Weile bis das umspringt.

Auf diesen Datenspeicher werden nun nur die Shared-VMDKs eines Cluster abgelegt, in diesem Fall hier also von einem Server-Paar.
Hier werden NICHT die Konfigurationsdateien sowie die Dateien der ersten Festplatte (Laufwerk C:) der Cluster-VMs abgelegt!!!!

---

IP-Adressen + Name

Die beiden Clusterknoten benötigen jeweils eine IP-Adresse.
Zusätzlich wird eine weitere IP-Adresse für die gemeinsame Cluster-Adresse benötigt:

192.168.0.60    filecluster.test.local
                fileserver.test.local
192.168.0.61    file01.test.local
192.168.0.62    file02.test.local

Die beiden Knoten legen sich selbst im DNS an wenn die Server der Domäne hinzugefügt werden, den DNS-Eintrag für die Cluster-IP habe ich händisch im DNS angelegt.
Die .60 hat 2 Namen. filecluster wir der Name des Clusters, fileserver der Name unter dem die Freigaben zu erreichen sind.

---

Windows VMs

Ich habe hier 2x Windows Server 2019 Standard Version 1809.14 installiert. Update: Unter Server 2022 habe ich die gleichen Einstellungen genutzt.

Die Einstellungen der VM habe wie folgt angepasst:

• Festplatte 1: 100 GB
• SCSI-Controller 0: LSI Logic SAS (entspricht der Vorgabe für Server 2019)
• Netzwerkadapter: VMXNET 3 (Anforderung von VMware und 10G Netzwerkgeschwindigkeit)
• Grafikkarte: 64 MB (Keine Probleme mit der Auflösung des Konsolenfensters)

Dann Windows installieren und durchpatchen. Ob es Standard oder Datacenter ist, ist egal.
Das Timeout für die Datenträger erhöhen bzw. kontrollieren:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue     DWORD 60

per Einzeiler:

reg add HKLM\System\CurrentControlSet\Services\Disk /v TimeOutValue  /t REG_DWORD /d 60 /f

Bei mir war der Wert nach dem Einrichten des Clusters unter 2019 automatisch so gesetzt.
Update: Unter Server 2022 ist der Wert auch schon richtig eingestellt.

Für das Beispiel hier verwende ich 2 VMs, FILE01 und FILE02
Beide nehme ich in die vorhandene Domäne auf.
Ich empfehle eine eigene OU im Active Directory für das Cluster zu stellen und die Computerkonten der beiden VMs dorthin zu schieben.
Alle Virtuellen Netzwerknamen / Failover cluster virtual network name die während der Konfiguration erzeugt werden landen dann automatisch ebenfalls unterhalb dieser OU.
Die OU sollte gegen versehentliches Löschen geschützt sein - dann gibt es später auch keine Fehlermeldungen dazu im Ereignisprotokoll.
Automatische Windows-Updates habe ich per sconfig deaktiviert.

---

Rollen und Features Installieren

Auf beiden Windows-Server installieren wir folgendes nach:

Dann den Server neu starten.
Update: Server 2022 verlangte keinen Neustart
Im Anschluss das Ganze auf dem 2. Server wiederholen.

---

Cluster VMDK hinzufügen

Man kann im Cluster mit oder ohne eine Quorum-Festplatte bzw. einem Whitness-Server arbeiten. Hier befinden sich beide Clusterknoten in einem VMware HA Cluster an einem Standort, deshalb verzichte ich darauf.

---

Erster Cluster-Knoten

Hinweis:Wenn man nach der offiziellen Anleitung von VMware vorgeht: Bei dem Erstellung und Hinzufügen der ersten Festplatte muss der Clusterknoten ausgeschaltet sein. Grund ist das man sonst nicht die notwendigen Einstellungen am neuen SCSI-Controller vornehmen kann. Weiter Festplatten lassen sich dann später im laufenden Betrieb hinzufügen

Wir bearbeiten die Hardware-Einstellungen der VM wie folgt:
Zuerst fügen wir einen neuen SCSI-Controller hinzu:

Diesen suchen wir danach in der Liste und ändern den Typ auf VMware Paravirtuell:

Dann fügen wir eine neue Festplatte hinzu:

Als Speicherort wählen wir den VMFS Datenspeicher auf dem wir zuvor die Datenspeicherfunktion Cluster-VMDK aktiviert haben.
Bei Festplattenbereitstellung wählen wir als Typ Thick-Provision Eager-Zeroed. Bei der Erstellung wird er den Datenträger komplett ausnullen (also mit 0 vollschreiben).
Bei Knoten des virtuellen Geräts wählen wir Neuer SCSI-Controller, die SCSI-ID sollte dann von allein auf SCSI (1:0) springen. Er wird hier nun den zuvor hinzugefügten neuen VMware Paravirtuell Controller verwenden.

Dann auf OK klicken - und warten. Er wird einen Moment brauchen die VMDK bereit zu stellen und mit 0en zu beschreiben.
Wenn er fertig damit ist die VM nochmals bearbeiten:

Und für den SCSI-Coontroller 1 die Gemeinsame Verwendung des SCSI-Busses auf Physisch umstellen.

Die VM kann jetzt wieder eingeschaltet werden.
Wir melden uns an und rufen die Datenträgerverwaltung auf:

Den neuen Datenträger nehmen wir Online, Initialisieren den Datenträger mit GPT und erstellen eine neue NTFS Partition mit einem beliebigen Laufwerksbuchstaben:

Jetzt fügen wir die Festplatte am 2. Clusterknoten hinzu.

---

Zweiter Cluster-Knoten

Auch diese VM muss dazu ausgeschaltet sein - das gleichzeitige Hinzufügen des neuen SCSI-Controllers und der vorhandenen Festplatte funktioniert sonst nicht!

Wir bearbeiten die Hardware-Einstellungen der VM wie folgt:

Also SCSI-Controller hinzufügen und diesen auf VMware Paravirtuell und Physisch ändern.
Dann fügen wir eine vorhandene Festplatte hinzu:

Im Dialog wählen wir die bereits vorhandene Festplatte des ersten Knotens auf dem Datenspeicher mit der aktivierten Cluster-VMDK Option.
Die Einstellung der neuen Festplatte müssen wir noch bearbeiten das auch diese den neuen Controller mit der gleichen SCSI-ID verwendet:

Dann auf OK klicken und die VM wieder starten.
In der VM überprüfen ob der Datenträger in der Datenträgerverwaltung zu sehen ist:

---

Cluster Grundkonfiguration

Nach dem wir zuvor die notwendigen Rollen und Features nachinstalliert und beide Knoten neu gestartet haben, starten wir auf dem ersten der beiden Knoten den Failovercluster-Manager:

Oben rechts wählen wir Konfiguration überprüfen ...:

Wenn wir nun auf Bericht anzeigen ... klicken können wir uns die Warnungen ansehen:
Bei mir wird folgendes beanstandet:

Das ist ok, es ist nur jeweils eine Netzwerkkarte in die beiden VMs eingebaut. Das Netzwerk ist durch den redundanten Anschluss der ESXi-Server an die Netzwerkswitche hochverfügbar.

Das ist ... auch ok. Er teste das mit dem Datenträger 0 - und das ist die Boot-Festplatte, Laufwerk C:. Ein Möglichkeit ihn dazu zu bringen gleich das geteilte Laufwerk zu nehmen habe ich nicht gefunden.

Ok, hier fehlt ein Update auf dem FILE02. Da es nur die Virendefinitionen von Windows Defender sind ignoriere ich das für den Test.


Wir setzen den Haken bei Cluster jetzt unter Verwendung der überprüften Knoten erstellen:

und klicken auf Fertig stellen

Als NetBIOS Name nehme ich den geplanten Namen FILECLUSTER, als IP die geplante Cluster IP-Adresse (siehe am Anfang des Artikels, .61 und .62 sind die beiden Knoten, .60 die gemeinsame Cluster-IP).

Den Haken bei Der gesamte geeignete Speicher soll dem Cluster hinzugefügt werden habe ich entfernt da ich in einem Schritt selbst das Fileserver-Clustering einrichten will. Ansonsten würde er sich die gemeinsame Festplatte gleich als Quorum schnappen.

Damit ist der Cluster erstellt.

---

Unterschiede Filecluster Typen

Ist hier beschrieben: https://docs.microsoft.com/de-de/windows-server/failover-clustering/sofs-overview
Anmerkungen dazu findet Ihr auch nachfolgende in den Hinweis-Boxen.

---

Fehler beim Erstellen

Egal welche der beiden Wege Ihr wählt, eventuell gibt es beim Erstellen der der Rolle einen Fehler, diese schaltet sich nicht online.
Es kommen zum Beispiel die Event Ids 1205, 1069 und 1254,
In diesem Fall befolgt diesen Artikel:

• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn466519%28v=ws.11%29

Die Kurzfassung (mit dem großen Hammer da einfach Vollzugriff gewährt wird)

• Auf einen Domänencontroller wechseln
• Active Directory Benutzer und Computer öffnen
• Unter Ansicht die Erweiterten Features aktivieren
• Die Eigenschaften der OU aufrufen in welcher die Clusterknoten sind
  • Unter Sicherheit die Computerkonten der beiden Knoten und des Clusters selbst mit Vollzugriff hinzufügen
• Die Eigenschaften des Computerkontos des Failoverclusters aufrufen
  • Unter Sicherheit die Computerkonten der beiden Knoten mit Vollzugriff hinzufügen

Dann im Cluster selbst im Failover-Manager die Rolle einmal beenden und wieder starten. Es sollte nun funktionieren.

---

Cluster-Rolle Fileserver hinzufügen - Horizontale Skalierung

Nachfolgend erstelle ich einen Fileserver-Cluster mit horizontaler Skalierung.

Hinweis:

Nach meinem bisherigen Verständnis - Stand 05.08.2021 - arbeitet die horizontale Skalierung wie folgt:

• Die Freigaben sind unter dem erstellten Namen zu erreichen - und zwar nur über diesen Namen
• Es ist eine Aktiv/Aktiv Konfiguration, über beide Knoten kann zugegriffen werden
• Im DNS wird dazu der gewählte Name 2 mal hinterlegt, mit den jeweiligen IP-Adressen der beiden Clusterknoten
• Das riecht - in Friedenszeiten wenn beide Knoten aktiv sind - nach Round-Robin. Und nach meinen Tests scheint das auch so zu sein da die Clients bei meinen Test beide Adressen nutzen.
• Der gemeinsame Datenspeicher wird dazu gleichzeitig auf beiden Knoten unter C:\ClusterStorage\VolumeX gemountet. Freigaben landen dort in einem Unterordner Shares
• Wenn man einen Failover macht, also einen Knoten entweder über die MMC schwenkt und/oder stoppt (oder hart einfach neu startet) läuft ein Kopiervorgang einfach weiter. Es gibt einen wirklich sehr kurzen Einbruch in der Datenrate, aber es läuft weiter. Daraus schließe ich das der Client die notwenigen Informationen dank SMB3 Protokoll hat und dann schwenkt.
• Clients die nicht SMB3 beherrschen sondern nur SMB2 können zwar trotzdem auf die Freigaben zugreifen, fallen dann aber bei einem Failover auf die Schnauze
• Ein Backup mit Veeam (Version 11) ist nicht möglich, die CSV - Cluster Shared Volumes - werden übersprungen. Ein Sicherung der Dateien über die Freigabe wäre möglich.

In der Failovercluster-Manager Konsole navigieren wir zu Rollen und wählen rechts (oder per Rechtsklick) Rolle konfigurieren:

Ich will einen Cluster bauen bei dem die Clients unterbrechungsfrei auf die Freigaben zugreifen können, deshalb wähle ich die horizontale Skalierung.

Hier tragen wir nun den Namen ein unter dem die Freigaben erreicht werden sollen, ich verwende hier FILEDISK1

Der Name FILEDISK1 steht nun 2x im DNS:

Er macht also per Round Robin eine zufällige Verteilung der Clients.
Im nächsten Schritt schaffen wir eine gemeinsame IP für den Zugriff.

---

Freigaben unter gemeinsamen Namen/IP veröffentlichen

Ab jetzt könnte auf Freigaben auch über den Namen FILESERVER zugegriffen werden

---

Speicher hinzufügen

Der File hat nun gerade noch nichts an Speicherplatz darunter, das ändern wir:

Damit beide Knoten gleichzeitig darauf zugreifen können müssen wir den Datenträger noch wie folgt hinzufügen:

Der Speicher steht nun auf beiden Knoten lokale unter

C:\ClusterStorage\Volume1

zur Verfügung.

---

Freigabe hinzufügen

Wir gehen zu

Rollen ==> FILEDISK1 ==> Dateifreigabe hinzufügen

Dort können wir nun wählen unter welchen Namen wir diese veröffentlichen wollen:

---

---

Cluster-Rolle Fileserver hinzufügen - Allgemeine Verwendung

Hinweis:

Nach meinem bisherigen Verständnis - Stand 05.08.2021 - arbeitet die allgemeine Verwendung wie folgt:

• Die Freigaben sind unter dem erstellten Namen zu erreichen - und zwar nur über diesen Namen
• Es ist eine Aktiv/Passiv Konfiguration, über den jeweils aktiven Knoten der dann auch die virtuelle IP hält wird zugegriffen
• Im DNS wird dazu der gewählte Name 1 mal hinterlegt, mit der virtuellen IP-Adressen des gewählten Knotennamens
• Der gemeinsame Datenspeicher ist unter seinem Laufwerksbuchstaben auf dem jeweils aktiven Knoten sichtbar. Wird geschwenkt so verschwindet das Laufwerk auf dem einen und erscheint auf dem anderen Knoten
• Wenn man einen Failover macht, also den aktiven Knoten wechselt, läuft ein Kopiervorgang ebenfalls einfach weiter. Es gibt aber einen spürbar längeren Einbruch in der Datenrate, der Kopiervorgang stockt für mehrere Sekunden, aber er läuft weiter.
• Ein Backup per Veeam Agent ist möglich, es kann der Veeam CBT (Change Block Tracking) Treiber eingesetzt werden, Veeam sichert auch die Shared-Festplatten

Zuerst brauchen wir einen Speicher für diesen Clustertyp. Dazu muss eine wieder eine gemeinsame Festplatte für beide Knoten geben die auf einem der beiden Knoten mit NTFS formatiert wurde.

Wenn da Verfügbarer Speicher steht ist das genau das wir brauchen.
In der Failovercluster-Manager Konsole navigieren wir zu Rollen und wählen rechts (oder per Rechtsklick) Rolle konfigurieren:

Wir wählen den eben hinzugefügten Speicher aus:

---

Festplatten vergrößern

• https://kb.vmware.com/s/article/67098

VMware supportet es explizit nicht im laufenden Betrieb da die jeweils andere VM welche die Festplatte eingebaut hat es nicht mitbekommt.
Im obigen Artikel werden alle Knoten ausgeschaltet, die .vmdk über SSH vergrößert und die Konfiguration der VMs neu eingelesen (was durch das verschieben der VMs zwischen Hosts erreicht wird). Von Microsoft / Windows Server 2019 her ginge es: https://www.tech-faq.net/csv-vergroessern-im-hyper-v-failovercluster/

---

---

Veeam Backup des Clusters

Da man keine Snapshots auf die VMs machen kann, kann man den Cluster auch nicht auf herkömmliche Weise sichern.
Veeam empfiehlt das das Backup per Agent.
Agentensicherungen benötigen Instanz-Lizenzen. Falls Ihr eine Lizensierung pro CPU (Socket) habt so schaut einmal in den Lizenzdialog:

In diesem Lizenztyp sind bis zu 6 Instanzen kostenlos enthalten.

---

Protection Group anlegen

Als Namen nehme ich den gleichen den ich auch dem Cluster gegeben habe - jeder andere wäre auch ok.

Es muss das Cluster-Konto ausgewählt werden, nicht die einzelnen Knoten oder virtuelle Namen. Es ist auch an seinem anderen Symbol erkennbar.

Bei den Exclusions muss der Haken bei All virtual machines entfernt werden - unsere Knoten sind schließlich virtuell.

Das Zugriffskonto muss die notwendigen Rechte habe. Unten rechts lassen sich die Zugangsdaten testen.

Der Zeitplan ist nur für den Rescan - da überprüft er den Clusterstatus und seine Mitglieder.
Die Option Install changed block tracking driver on Windows Server OS ist gefahrlos möglich und wird von Veeam bei größeren Datenmengen empfohlen. Aber es ist ein Neustart der Knoten nach der Installation des CBT Treibers notwendig.

Die Zusammenfassung zeigt uns Informationen zum Distribution-Server -also dem Server der für den Zugriff auf den Cluster verwendet wird und der im Dialog zuvor ausgewählt werden kann.

Da schon alles vorhanden ist geht es unter Apply entsprechend schnell weiter.

Den Agenten installiert er erst bei einem Rescan, den bietet er uns unten im Abschlussdialog gleich mit an. Falls der angehakt ist öffnet sich gleich der nächste Dialog:

Das sieht jetzt dramatisch aus - aber letztendlich fehlt nur der Reboot der Clusterknoten
Das könnten wir nun einfach aus der Veeam Console machen:

Ich habe das manuell an den Knoten inklusive vorherigem Failover gemacht.
Im Anschluß habe ich unter Veeam noch einmal einen Rescan durchgeführt:

Und schon ist alles grün!

---

BackupJob für Cluster anlegen

Wir wechseln zu Home und erstellen einen neuen Job für Windows computer...

Wir fügen per Add... den Cluster aus der Protection Group hinzu.
Ich habe im Internet und auch bei Veeam es unterschiedlich gesehen ob hier die Protection-Group oder das Cluster-Objekt hinzugefügt wird.
Da beides identisch ist - Pro Cluster wird eine Protection-Group erstellt - ist es wahrscheinlich Jacke wie Hose.

Diese Einstellungen gemäß eurer Anforderung (auch unter Advanced), da gibt es kein richtig oder falsch.

Den Zeitplan ebenfalls nach euren Wünschen, ich habe ihn hier an einen anderen Jon angehängt.

Restore

Dateiserver zur allgemeinen Verwendung:
Bei einem Restore von einzelnen Dateien ist es egal über welchen der beiden Clusterknoten ihr die Wiederherstellung startet, bei beiden seht ihr die Cluster-Laufwerke:

---

Quellen

• https://www.veeam.com/kb2463
• https://www.veeam.com/blog/windows-2019-file-server-cluster-backup-agent.html
• https://docs.vmware.com/en/VMware-vSphere/7.0/vsphere-esxi-vcenter-server-70-setup-wsfc.pdf

---

Kommentare

Loading comments...