Kommen wir nun zum nächsten Schritt:
HOWTO 5: HYPER-V FAILOVER CLUSTER (OHNE GEMEINSAME DOMÄNE)
TEIL 1: EINE EINFÜHRUNG
Damit die ganze Sache überhaupt in der Praxis Sinn macht, brauchen wir mindestens zwei physische Maschinen, auf denen jeweils (zumindest auch) ein Hyper-V Host läuft. Mehr Hosts ist natürlich immer nett, aber nicht nötig und @home sowieso schwierig. Daher wird in der Folge hier immer unterstellt, dass (nur) zwei Hyper-V Hosts existieren.
Im Gegensatz zu unseren bisherigen Gehversuchen mit Hyper-V - "Stand-alone" per HowTo 1 oder "Remote Managed" per HowTo 2 - müssen wir uns jetzt bei einem Failover Cluster aber um eine weitere Komponente einmal nähere Gedanken machen, die wir bisher grundsätzlich ausklammern konnten:
STORAGE. Konkret: wo sollen die VMs und ihre (virtuellen) Festplatten jetzt eigentlich hin?
Warum?
Unser Failover-Cluster hat ja den Sinn, dass eine darin laufende HAVM (high availability virtual machine - also hochverfügbare virtuelle Maschine) grundsätzlich auch dann weiter laufen soll, wenn der physische Host - auf dem sie bis gerade munter lief - plötzlich oder geplant ausfällt, aus welchen Gründen auch immer. Das funktioniert allerdings nur, wenn die Festplatte
bzw. VHD(x)s der HAVM auch für alle (anderen) physischen am Cluster teilnehmenden Rechner (sogenannte "Nodes") zur Verfügung steht.
Ist das nicht der Fall und sollte nun eine der Nodes Schluckauf haben und ausfallen, und liegt ausgerechnet auf einer lokalen Platte dieses Nodes die HAVM, hätten wir leider Pech gehabt. In einem Zwei-Node-Cluster dürfte also nur "die andere Node" ausfallen - das bringt uns nicht so richtig weiter.
Ich kann hier leider auch (noch)
keine perfekte Lösung aufzeigen. Eine solche ginge wahrscheinlich in die Richtung zwei weiterer (virtueller) Windows File-Server, die ihrerseits einen separaten Storage-Cluster neben dem Hyper-V Cluster aus lokalen Platten/VMs bilden. Theoretisch könnte man diese Fileserver wahrscheinlich auch virtualisieren. Alternativ habe ich auch mal an einen Fileserver als HAVM gedacht, der einen Raid1-Verbund aus (mindestens) 2 Festplatten in Form von iSCSI-Freigaben von eben (mindestens) zwei physischen Hosts als Storage bekommt und dann zurück als VM-Speicherplatz bereitstellt. Dann könnte theoretisch auch eine Seite komplett ausfallen und die HAVM stünde noch auf einem Raid1-Bein zur Verfügung. Damit habe ich mich allerdings noch gar nicht beschäftigt und hat bei mir gerade weder Priorität noch "haben-wollen-Faktor". Das darf gerne ein anderer mal ausprobieren/niederschreiben.
Außerdem ist dann da noch das Lizenzthema für die Fileserver (keine Ahnung ob das zukünftig ein Essentials- oder Core-Edition kostenlos mitbringt).
Als praktischer und praktikabler
Kompromiss bieten sich meiner Meinung nach zwei Möglichkeiten an:
1. Ein drittes Maschinchen, das seinerseits mindestens "iSCSI-Freigaben" bereitstellen kann (vielleicht geht's auch mit SMB3, habe ich aber nicht selbst ausprobiert). Das kann z.B. ein ohnehin bereits vorhandenes (Fertig-)NAS sein. Jedenfalls sollte diese Box möglichst zuverlässig laufen, iSCSI darauf leicht zu konfigurieren sein und das Ding auch weitgehend wartungsfrei sein (wenn man daran was machen will, muss man ja im Zweifel den ganzen Cluster, also alle VMs und besser auch beide physischen Hosts runterfahren).
- Vorteil: einer von beiden Hyper-V Hosts kann jeweils vollständig abrauchen, der andere kann einspringen.
- Nachteil 1: Will das dritte Maschinchen nicht mehr, bringen auch zwei an sich laufende Hyper-Vs nichts mehr.
- Nachteil 2: Raucht (nur) die Storage-Maschine ab, geht auch nichts mehr. (Wenn einem die Konfiguration des Clusters, die VMs oder Zeit auch nur irgend etwas bedeutet, ist also RAID/Backup bei dieser Kiste Pflicht).
2. Eine Storage-VM auf einem der beiden Hosts, die "neben" (also nicht IN) dem jeweiligen Hyper-V läuft. Daher war/ist es für mich so faszinierend, dass man einen Hyper-V Host als VM in einem ESXi-Host (sogenannt "nested") laufen lassen kann (s.o. HowTo 4)!
- Vorteil 1: ich brauche keine 3. physische Maschine (spart vielleicht sogar Strom) und kann trotzdem jeweils zur Not auf einen Hyper-V Host verzichten (Wartung/Reboot/Spielerei).
- Vorteil 2: Ich bin mit ESXi fast gar nicht bei der Auswahl eingeschränkt, welche (Software)Basis ich für mein Storage haben will (alles ist denkbar, wie Solaris/ZFS, OMV, XPEnology und und und...).
- Vorteil 3: Über einen internen virtuellen ESXi-vSwitch laufen Datentransfers innerhalb des ESXi-Hosts zwischen der Hyper-V-VM und der Storage-VM näher am physischen Storage-Limit - und eben nicht am Netzwerklimit (SSD anyone?).
- Vorteil 4: Raucht die ESXi-Hyper-V-Host-VM ab, steht die Storage-VM grundsätzlich noch für die 2. Node auf der anderen Box zur Verfügung (wenn das Problem nicht auf den ESXi-Host durchschlägt und der sich mit verabschiedet).
- Vorteil 5: Ausreichende Hardware-Ressourcen voraussgesetzt, sind alle Napp-it All In One Nutzer bereits bestens aufgestellt.
- Nachteil 1: Die Performance von einem "virtualisierten" Hyper-V Host ist schlechter als "bare metal".
- Nachteil 2: Höhere Komplexität birgt höheres Fehlerpotenzial (auf allen Ebenen, u.a. bei Hyper-V oder auch bei der Storage-VM). Nachteil 3: Stirbt die Storage-VM, sterben alle HAVMs (und ggf. je nach Konfiguration / Pech die Hyper-V Hosts gleich mit). Nachteil 4: Ggf. höhere Hardwareanforderungen / Anschaffungskosten für die "All-in-one" Box.
Ich habe mich für eine Kombination aus Variante 1 und Variante 2 entschieden: Mein Hauptfiler mit den iSCSI-Freigaben läuft als ESXi-VM (Variante 2) und ich benutze eine 3. Box (Variante 1) als Backup der Storage VM.
Für das Failover-Cluster HowTo selbst werde ich zunächst unterstellen, dass irgendwo im Netz mindestens ein iSCSI-Share zur Verfügung steht.
Exkurs "nested Hyper-V": Hyper-V 2016 soll breits/zukünftig auch "nested" Hyper-V (und vielleicht auch andere Hypervisoren?) ermöglichen. Theoretisch können das vielleicht jetzt auch schon noch andere Hypervisoren wie Proxmox, Oracle & Co. Ich habe bisher nur ESXi6 ausprobiert und für mich als absolut stabil (genug) kennen gelernt.
TEIL 2: VORBEREITUNGEN (NUTZER UND CO...)
0. OPTIONAL: Management VM/Maschine
Um die Verwirrung und die Komplexität des HowTos in Grenzen zu halten, trenne ich mal den Cluster-Aufbau von der Verwaltung des Ganzen. Der Einfachheit halber nehme ich eine GUI-Serverversion und eine Core (mit dem GUI-Server verwalten wir in diesem Beispiel den non-GUI Hyper-V). Im Prinzip solltet Ihr damit aber auch in der Lage sein, einen Cluster nur aus non-GUI Servern zu bauen (alle PS-Befehle sind ja angegeben).
1. Feste IPs
Ihr solltet für alles weitere am besten Euren Servern feste IP-Adressen geben. Ich habe für dieses HowTo meinen beiden oben über die HowTos eingerichteten Servern die folgenden festen Adressen gegeben:
192.168.178.240=HYPVCORE
192.168.178.241=HYPVGUI
HYPVCORE ist der Hyper-V Host, den wir in HowTo 1 erstellt haben.
HYPVGUI ist der Hyper-V Host, den wir in HowTo 2 erstellt haben.
2. Primäres DNS Suffix
Ich kenne mich mit DNS nicht wirklich gut aus. Nach meinem Verständnis geht es hier darum, eben eine "Domäne" vorzugaukeln und ich habe mich an der klassischen Internet-Domain-Nomenklatur orientiert. Soll heißen: Schema NAME.TOPLEVEL - in meinem Beispiel "howtofailo.priv".
Laut meiner Quelle müssen alle Cluster-Mitglieder
ein solches DNS-Suffix haben. Keine Ahnung ob das immer der gleiche sein muss, hab bei beiden Hyper-V-Hosts vorsichtshalber den gleichen genommen (howtofailo.priv). Ich hab's nicht getestet, ob/wie es auch ohne geht. Also machen wir's halt (auf allen Hyper-V Hosts für's Cluster! Connecten dafür bitte per RDP zu unseren remote-Server
):
In der
GUI-Version ist's recht einfach: Links auf Local Server", auf den Computer-Namen clicken, "Change" clicken, "More" clicken, bei "Primary DNS suffix of this computer" den Namen eingeben:
In der
CORE-Version müssen wir die Registry direkt manipulieren und wechseln wieder in die Powershell für:
Code:
PS C:\User\Administrator> Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\" -Name Domain -Value "howtofailo.priv"
(Funktioniert natürlich auch in der GUI-Version - geht vielleicht schneller)
Machen wir's über die Powershell, vorsichtshalber rebooten!
3. "hosts" Datei anpassen
Im GUI-Server, da wir mit diesem den Cluster bauen werden, editieren wir die "hosts" Datei und weisen der IP-Adresse des non-GUI Server den entsprechenden Hostnamen (HYPVCORE) zu.
Also Editor (Notepad) als Administrator ausführen, auf Datei-->Öffnen clicken, alle Dateien auswählen und navigieren zu c:\Windows\System32\drivers\etc-->Datei "hosts" öffnen:
(Alternativ, schneller und eleganter in Administrator-command- oder powershell eingeben: "notepad c:\Windows\System32\drivers\etc\hosts").
In meinem Beispiel mit den 2 Hyper-V-Hosts sieht die Hosts-Datei des GUI-Servers (HYPVGUI) dann also wie folgt aus:
Code:
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
[B]192.168.178.240 HYPVCORE.howtofailo.priv[/B]
WICHTIG: ihr müsst unbedingt den primären DNS-Suffix (hier im Beispiel : howtofailo.priv) mit eintragen, sonst funktioniert die Erstellung des Clusters nicht! (Die Fehlersuche hat mich STUNDEN gekostet...)
4. Einheitliche Benutzer
Für die Einrichtung eines "Arbeitsgruppen"-Clusters (also ohne einheitliche Domäne) brauchen wir auf allen Maschinen -
die Teil des Clusters werden sollen! - einen
einheitlichen Benutzer-Account mit Administrator-Rechten. Einheitlich heißt: gleicher Name, gleiches Passwort. Falls Ihr nur mit den Hyper-V Servern arbeitet, könnt Ihr natürlich den eingebauten Administrator-Account benutzen und müsst nur das gleiche Passwort setzen (admin-cmd: "net user Administrator *"). Das habe ich hier gemacht.
TEIL 3: REMOTE-STEUERUNG ÜBER SERVER-MANAGER
Ganz so einfach wie die Einrichtung des Hyper-V Managers für die Remotesteuerung (HowTo 2 oben) geht es leider hier nicht. Wir müssen nun zunächst unserem Management-PC (VM, Client oder eben ein GUI-Hyper-V Server) beibringen, dass er den zu verwaltenden Servern vertrauen kann.
1. Vertrauen schaffen...
Als erstes bringen wir unserem Management-Client bei, dass er den Servern hinreichend vertraut (und ihnen u.a. seine Anmeldedaten übermittelt). Dazu öffnen wir eine Administrator-Powershell und geben Folgendes ein:
Code:
PS C:\windows\system32>set-item WSMan:\localhost\Client\TrustedHosts -value "HYPVGUI.howtofailo.priv,HYPVCORE.howtofailo.priv" -concatenate
Falls der WinRM-Dienst noch nicht läuft, werdet Ihr gebeten, den Start zu bestätigen ("JA"). Dann gibt es eine zweite Warnung, ob Ihr die TrustedHosts-Liste ändern wollt (ebenfalls "JA").
WICHTIG: Auch hier das primäre DNS-Suffix mit eintragen!
2. Remote-Server im Server Manager hinzufügen
Jetzt können wir als nächstes den Server im Server-Manager des Management-Client hinzufügen. Dazu machen wir links im Server Manager auf "Alle Server" einen rechtsclick und wählen "Server hinzufügen" (1.). In der sich öffnenden Maske wählen wir DNS (2.) und geben den/die Hostnamen unserer Hyper-V Host(s) in das Suchfeld ein und clicken auf die Lupe (3.). Dann wählen wir den Server in der Liste aus und clicken auf den kleinen Pfeil daneben (4.), worauf der Server dann in dem mit "ausgewählt" überschriebenen Feld erscheint. Am Ende bestätigen wir mit "OK" (5.).
3. Server mit anderen Anmeldedaten managen
Die Server tauchen immerhin jetzt in der Liste auf, aber leider begrüßt uns auch eine Fehlermeldung (pro hinzugefügtem Server, also hier 2):
DON'T PANIC!
Wir machen nun einen Rechtsclick auf den Server, wählen dann "Verwalten als" und geben in der sich öffnenden Maske die Admin-Accountdaten des jeweiligen Servers ein nachdem Muster "HOSTNAME\Account", in meinem Beispiel also "HYPVGUI\Administrator" mit dem entsprechenden Passwort. Am besten gleich den Haken bei "Anmeldedaten speichern" setzen.
Etwas Geduld und dann ändert sich der Stand bei der Verwaltbarkeit in "Online - Leistungsindikatoren wurden nicht gestartet". Oleole, die Leistungsindikatoren sind uns an dieser Stelle schnuppe (wer mag kann sie anwerfen über einen rechtsclick auf den Server-->"Leistungsindikatoren starten").
Damit sind die Server GRUNDSÄTZLICH verwaltbar, insbesondere lassen sich remote direkt aus dem Server Manager Rollen und Features hinzufügen...
TEIL 4: FAILOVER-CLUSTER EINRICHTEN
1. Failover-Features installieren
Und genau das machen wir jetzt (endlich). Dank unserer Vorarbeiten gibt es zwei Möglichkeiten:
- Über GUI: Wir gehen im Server Manager zum Dashboard und wählen "Rollen und Features hinzufügen". In dem sich öffnenden Wizard clicken wir munter auf weiter, bis wir zur Serverauswahl kommen. Dort wählen wir nun unseren remote zu steuernden Server.
Zur Erinnerung: in meinem Bespiel sind ja beide Server remote, so dass wir diesen Schritt für beide Server durchführen müssen. Dann clicken wieder wieder fröhlich weiter bis zum Feld "Features" und setzen den Haken bei Failover Clustering (einschließlich Management Tools) und clicken weiter bis einschließlich installieren.
- ODER (m.E. schneller) mit Powershell: RPD zu (je)dem remote-Server, in der cmd schnell zur powershell wechseln und dort eingeben:
Code:
Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools
- Reboot nicht zwingend erforderlich.
2. Hyper-V Switches überprüfen/vorbereiten
Damit unser Failover funktioniert, müssen wir auf
beiden Hyper-V Servern die richtigen Rahmenbedingungen schaffen. Konkret heisst das, die identischen virtuellen Switches auf beiden Hosts erstellen. Identisch heisst hier, gleicher Name (reicht).
3. Cluster bauen
Jetzt wird's ernst. Wir gehen also wieder an einen unserer Server (z.B. per RDP) und dort in eine Admin-Shell mit dem Admin-Account, der auf allen hyper-V Hosts mit identischem Name/Passwort vorhanden ist:
Code:
PS: C:\Users\Administrator>new-cluster -name HowToFailO -node HYPVCORE.howtofailo.priv,HYPVGUI.howtofailo.priv -AdministrativeAccessPoint DNS -staticaddress 192.168.178.245/24
Hinweis:: der Parameter -staticaddress gefolgt von der IP-Adresse/Subnetzmaske ist nicht erforderlich, wenn ihr DHCP verwendet. Da ich aber (beiden) Servern feste Adressen gegeben habe, erwartet der Cluster-Befehl auch für den Cluster eine feste IP, die Ihr eben mit diesem Parameter setzt.
Solltet ihre keine weiteren Festplatten zusätzlich zu den Systemplatten (C
in Euren Hyper-V Servern haben, werdet Ihr voraussichtlich mit einer Fehlermeldung beglückt:
Konkret geht es darum, dass dem Cluster noch ein (gemeinsamer) Speicherplatz fehlt, sowohl zum Ablegen der HAVMs, als auch betreffend die sogenannte "Witness Disk", wie sich aus dem automatisch generierten Report erkennen lässt:
Dazu kommen wir aber gleich noch.
4. Failover Cluster Manager
Nach dem
Microsoft Blog zum Thema ist es (angeblich) nicht möglich, ein non-domain/workgroup-Cluster über das GUI zu administrieren:
Management operations may only be performed using Microsoft PowerShell©. The Failover Cluster Manager snap-in tool is not supported in these configurations.
Das galt vielleicht noch für die TP3, bei der TP4 habe ich festgestellt, dass das (inzwischen) so nicht mehr ganz richtig ist. Insbesondere Rollen und Ressourcen lassen sich dem Cluster zuordnen, auch Nodes entfernen oder auch der Cluster zerstören. Nur bis zur bzw. einschließlich der erstmaligen Erstellung muss man die Powershell bemühen.
Wir öffnen also den Failover Cluster Manager, indem wir im Server Manager oben rechts auf "Tools" clicken und darin auf "Failover Cluster Manager". Dann clicken wir darin rechts auf "Connect to cluster..." und geben darin entweder die IP unseres Clusters ein oder wir lassen - wenn wir uns auf einem Server befinden, der Mitglied des Clusters ist - einfach "<Cluster on this server...>" stehen.
Hinweis: Unser Cluster erscheint über (mindestens) eine eigene IP im Netzwerk, die wir im Befehl oben mit "-staticaddress" angegeben haben.
Nach erfolgreicher Verbindung begrüßt uns dann der Failover Cluster Manager mit der Übersichtsseite zu den wichtigen Informationen. Im nachfolgenden Screenshot habe ich links die Reiter mal ausgeklappt:
TEIL 5: GEMEINSAMEN STORAGE EINRICHTEN
0. iSCSI Share
Wie oben in der Einführung bereits schon etwas detaillierter ausgeführt, brauchen wir für unsere HAVMs irgendwo einen gemeinsamen Speicherplatz , auf den sämtliche Cluster-Mitglieder zugreifen können. Wie gesagt setze ich hierzu ein irgendwo in Eurem Netzwerk bereits eingerichtetes "iSCSI-Share" voraus. Das sollten auch die verschiedenen Fertig-NAS-Lösungen hinbekommen, hier ein Beispiel mit QNAP:
1. iSCSI-Share für Server 1 (Beispiel mit GUI) verfügbar machen
Um unsere iSCSI-Share nutzbar zu machen, starten wir auf dem
ersten Hyper-V Server (mit GUI) den iscsi-Initiator (Start-->iscsi eintippen und obersten Eintrag in der Liste wählen; Alternativ über den Server Manager-->Tools-->iSCSI Initiator oder in der Powershell: iscsicpl.exe - brauchen wir spätestens für den non-GUI-Server). Darin bestätigen wir, dass der iSCSI-Dienst jetzt und standardmäßig gestartet werden soll und geben im Idealfall nur die IP-Adresse des Servers ein, auf dem Ihr die iSCSI-Freigabe eingerichtet habt.
Nun wechseln wir in die Datenträgerverwaltung (z.B. rechtsclick auf start-->"Disk Management"), stellen die dort auftauchende Disk "online" (rechtsclick), erstellen eine neue Partition und formatieren sie mit NTFS.
Laufwerksbuchstaben merken! In meinem Beispiel habe ich mein 200GB-iSCSI-Share als Laufwerk E: eingebunden und mit NTFS formatiert:
Wer hierzu konkretere Hilfestellung wünscht, findet zum Thema iSCSI in Windows zahlreiche Guides,
zum Beispiel hier (englisch).
Das Wichtige folgt nun: wir nehmen diese Disk nun im ersten Server wieder
offline und fügen sie auf die gleiche Weise im zweiten Node hinzu. Falls dort ein anderer Laufwerksbuchstabe vergeben wird, müsst Ihr diesen auf den gleichen Laufwerksbuchstaben wie im ersten Server ändern!
2. iSCSI-Share für Server 2 (Beispiel ohne GUI) verfügbar machen
Also wechseln wir zu unserem
zweiten Hyper-V Server (hier: der non-GUI-Server), geben dort in der cmd-/Powershell iscsicpl.exe ein und lassen auch dort den Service starten. Dummerweise haben wir für die Datenträgerverwaltung hier kein GUI. Da die Einrichtung der GUI-Remoteverwaltung ein eigenes Kapital füllen kann (und hoffentlich bald auch wird), bemühen wir für diese Zwecke das gute alte "
DISKPART":
a) in cmd "diskpart" eingeben
b) "list disk" eingeben und die richtige Ziffer für die Freigabe herausfinden (erkennbar z.B. an der Größe) und am Status "offline"
c) "select disk 1" (bzw. richtige Ziffer bei Euch -
WICHTIG, sonst macht ihr ggf. die Installation/Daten unbrauchbar)
d) "online disk"
e) "list volume" --> Laufwerksbuchstaben eurer iSCSI-Share prüfen!
Falls Schritt e) einen abweichenden Laufwerksbuchstaben zeigt:
e.1) "select volume 3"
e.2) "assign letter=e" (bzw. den Buchstaben von eurem ersten Server)
e.3) "list volume" (zur Kontrolle
)
f) "offline disk"
g) "exit"
Das sieht dann in der shell etwa so aus (eingaben
fett+unterstrichen):
Code:
C:\Users\Administrator>[B][U]diskpart[/U][/B]
Microsoft DiskPart version 10.0.10586
Copyright (C) 1999-2013 Microsoft Corporation.
On computer: HYPVCORE
DISKPART> [B][U]list disk[/U][/B]
Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 20 GB 0 B
Disk 1 Offline 200 GB 0 B *
DISKPART> [B][U]select disk 1[/U][/B]
Disk 1 is now the selected disk.
DISKPART> [B][U]online disk[/U][/B]
DiskPart successfully onlined the selected disk.
DISKPART> [B][U]list volume[/U][/B]
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 D DVD-ROM 0 B No Media
Volume 1 System Rese NTFS Partition 500 MB Healthy System
Volume 2 C NTFS Partition 19 GB Healthy Boot
Volume 3 F iSCSI NTFS Partition 199 GB Healthy
DISKPART> [B][U]select volume 3[/U][/B]
Volume 3 is the selected volume.
DISKPART> [B][U]assign letter=e[/U][/B]
DiskPart successfully assigned the drive letter or mount point.
DISKPART> [B][U]list volume[/U][/B]
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 D DVD-ROM 0 B No Media
Volume 1 System Rese NTFS Partition 500 MB Healthy System
Volume 2 C NTFS Partition 19 GB Healthy Boot
* Volume 3 E iSCSI NTFS Partition 199 GB Healthy
DISKPART> [B][U]offline disk[/U][/B]
DiskPart successfully offlined the selected disk.
DISKPART> [B][U]exit[/U][/B]
Leaving DiskPart...
C:\Users\Administrator>
(Eine englische Schritt-für-Schritt Anleitung, allerdings nur für GUI, findet sich
zum Beispiel hier.)
3. iSCSI-Share dem Cluster zur Verfügung stellen
Bis jetzt haben wir nur ein iSCSI-Share, das "zufällig" auf zwei Servern eingebunden ist. Eigentlich soll man sowas ja anscheinend eher nicht machen, aber im Cluster gelten diesbezüglich andere Regeln, denn ohne geht es nicht...
Damit wir nun also echte HAVMs erstellen können, die auch den "Tod" eines kompletten physischen Hyper-V Servers überleben, brauchen wir nun den gemeinsamen Speicherplatz, der allen Servern im Cluster zur Verfügung steht. Microsoft nennt das dann "Cluster Shared Volumes" und beschreibt das - wie ich finde recht eingängig - so:
Quelle 1:
CSV can enhance the availability and manageability of virtual machines by enabling multiple nodes to concurrently access a single shared storage volume. For example, on a failover cluster that uses CSV, multiple clustered virtual machines that are distributed across multiple cluster nodes can all access their virtual hard disk files at the same time, even if the files are on a single disk (LUN) in the storage. This means that the clustered virtual machines can fail over independently of one another, even if they use only a single LUN. CSV also support live migration of a Hyper-V virtual machine between nodes in a failover cluster.
Quelle 2:
Cluster Shared Volumes (CSV) enable multiple nodes in a failover cluster to simultaneously have read-write access to the same LUN (disk) that is provisioned as an NTFS volume. (In Windows Server 2012 R2, the disk can be provisioned as NTFS or Resilient File System (ReFS).) With CSV, clustered roles can fail over quickly from one node to another node without requiring a change in drive ownership, or dismounting and remounting a volume. CSV also help simplify the management of a potentially large number of LUNs in a failover cluster.
Immerhin können wir jetzt zurück in die GUI-Version und zwar wieder in den Failover Cluster Manager. Dort machen wir einen rechtsclick auf "Disk", wählen "add Disk" und bekommen netterweise direkt unsere neue "DISK" (in Form der iSCSI-Freigabe) präsentiert:
4. iSCSI-Share als Cluster Shared Volume definieren
Nun noch schnell auf der Disk ein
Cluster Shared Volume einrichten, also rechtsclick auf die neue Disk, darin "Add to Cluster Shared Volumes":
...und wir haben unseren "gemeinsamen Speicherplatz" erfolgreich eingerichtet.
Hinweis: Obwohl wir die "DISK" offline genommen haben, ist diese jetzt übrigens auf beiden Servern lokal verfügbar unter "c:\clusterstorage\volume1\":
Wenn wir nun auf Server 1 eine Datei dorthin kopieren, sieht auch sofort Server 2 - genau das was wir wollen, falls eben ein Server ausfällt.
TEIL 6: HAVM
Im Prinzip funktioniert das Anlegen einer
hoch verfügbaren virtuellen Maschine hier genauso wie im HowTo1 für den Hyper-V Manager beschrieben. Es gibt nur drei Besonderheiten am Beispiel einer "frischen" VM:
1. Wizard im Failover Cluster Manager starten
Wir starten das Ganze am besten über den Failover Cluster Manager (nicht im Hyper-V Manager) durch einen rechtsclick auf "Roles", wählen "Virtual Maschine" und "New Virtual Maschine" und wählen einen Server für die Erstellung aus (ist m.W. eigentlich egal welchen).
2. Cluster-Storage als Speicherplatz für die VM
Beim Speicherplatz für die VM dürfen wir nicht die Standardeinstellungen verwenden, sondern müssen die VM in unserem Cluster-Speicherplatz ablegen und den Platz manuell auswählen ("Browse"):
3. Cluster-Storage als Speicherplatz auch für die VHD
Das gleiche gilt natürlich auch für die dazugehörige VHD, allerdings ist der Wizard so schlau, hier jetzt gleich das richtige Plätzchen vorzuschlagen:
4. Success!
Am Ende werden wir dann begrüßt von der begehrten Meldung, dass wir erfolgreich eine "HIGH AVAILABILITY" VM erstellt haben:
5. HAVM managen
HAVMs verwaltet Ihr am besten über den Failover-Cluster Manager. Wenn Ihr unter "role" auf Eure VM clickt, seht Ihr rechts unten das aus dem Hyper-V Manager bekannte Menü, allerdings inbs. ergänzt um den spannenden Eintrag "Move":
Im Prinzip ist m.E. alles Weitere selbsterklärend, bis auf:
Hinweis: in einem "workgroup" cluster funktioniert Live Migration NICHT. Ihr könnt also die VM nur in Form der Quick Migration hin-und-her schubsen. Der wesentliche Unterscheid besteht darin, dass die VM vom Cluster während dieses Vorgangs automatisch quasi auf Node 1 in den Ruhezustand geschickt, und auf Node 2 dann wieder aufgeweckt wird.
Viel Spaß mit Eurem Cluster!
01_Language.jpg
02_DesktopExperience.jpg
03_1stStart.jpg
04_HyperVrole1.jpg
05_HypVRole2.jpg
06_VirtSwitch.jpg
08_InstallCompleted.jpg
07_Install.jpg
09_HypVMan.jpg
10_RDP.jpg
11_VirtSw.jpg
12_VirtSw2.jpg
13_NewVM1.jpg
15_VMname.jpg
16_VMGen.jpg
17_VMRAM.jpg
18_VMSwitch.jpg
19_VMVHD.jpg
20_VMOS.jpg
21_UbuntuVMSettings.jpg
