Drücke "Enter", um den Text zu überspringen.

Schlagwort: Cluster

CPU-Kompatibilität in Hyper-V-Cluster mittels PowerShell steuern

Zu einem bestehenden 2-Knoten S2D-Hyper-V-Failover-Cluster aus 2 exakt gleichen Hosts hatte ich vor kurzem einen dritten Knoten hinzugefügt. Es handelte sich hierbei um das selbe HP-Server-Modell. Bei den ersten Live-Migrationen traten jedoch Fehler auf und eine Analyse brachte zu Tage, dass die CPUs am dritten Knoten geringfügig andere sind.

Für dieses Problem gibt es im Allgemeinen das Feature „Processor compatibility“ in Hyper-V (Im Deutschen als „Prozessorkompatibilitätsmodus“ bezeichnet, in der GUI heisst es dann „Zu einem physischen Computer mit einer anderen Prozessorversion migrieren“ bzw. „Migrate to physical computer with a different processor version“). Dieses Feature kann man natürlich problemlos über die GUI ein- und ausschalten:

Allerdings ergeben sich hier schnell 2 Herausforderungen:

  • Das Feature lässt sich nur ändern, während die VM ausgeschaltet ist
  • In einem Cluster laufen schnell mal eine 2-stellige Anzahl VMs

Das kann man natürlich wie so vieles sehr elegant per PowerShell lösen, also habe ich dafür ein passendes Skript geschrieben. Dieses kann entweder zum ein- oder ausschalten des Features benutzt werden und iteriert dabei über einen Cluster und behandelt dabei dann alle VMs im Cluster, bei denen das Feature noch nicht korrekt eingestellt ist, in dem die VMs bei Bedarf zuerst gestoppt, das Feature gesetzt und dann falls vorher laufend die VM wieder startet. Am Ende wird dann noch der Gesamtzustand ausgegeben.

Das Skript findet ihr auf meinem GitHub Repo, siehe hier:

scripts/HyperV/EnableOrDisableCPUCompatibilityOnHyperVCluster.ps1 at master · HaikoHertes/scripts (github.com)

Damit kann man nun also entweder bei unterschiedlicher Hardware die CPU-Kompatibilität für alle VMs erhöhen oder, nachdem man z.B. die CPUs überall auf den selben Stand gebracht hat, das Feature wieder deaktivieren.

Schreibe einen Kommentar...

Windows Server 2012 R2: Einrichten eines Failover-Clusters am Beispiel Hyper-V

Ein Failover-Cluster ist eine gute Sache: Er sorgt für Hochverfügbarkeit! Damit lassen sich diverse Dienste geclustert betreiben. Mehrere Server teilen sich eine Aufgabe und die dazugehörige Last. Fällt nun einer der beteiligten sogenannten “Knoten” aus, so übernehmen die verbliebenen die Aufgabe sofort automatisch. Damit lässt sich beispielsweise auch Hyper-V bzw. die darauf laufenden virtuellen Maschinen gegen einen Ausfall absichern.

Für eine Minimal-Konfiguration werden benötigt:

  • Ein Domänencontroller
  • Zwei weitere Server als Mitglied der Domäne
  • Zentraler Speicher

Für den zentralen Speicher kämen die beiden SAN-Technologien iSCSI und FiberChannel in Frage. Optional geht seit Server 2012 auch SMB3.0 (“Scale Out File Server”). Für eine Testumgebung ist iSCSI sehr gut geeignet. Wie man ein iSCSI-Target einrichtet und den dazugehörigen Initiator nutzt habe ich in einem meiner letzten Blogartikel beschrieben (Windows Server 2012 R2: iSCSI Target und Initiator einrichten).

Der Domänencontroller sowie die beiden Member-Server laufen unter Windows Server 2012 R2.

Es werden 2 iSCSI-Targets benötigt, eines mit min. 512MB Speicher, das zweite mit ausreichend Speicher für die vorgesehenen VMs und deren VHD(X)-Dateien, in meinem Fall 40GB. Die beiden Targets müssen bereits auf beiden Knoten eingebunden sein, die beiden Datenträger online geschaltet worden sein, initialisiert und formatiert (ohne Laufwerksbuchstaben).

Weiterhin muss das Netzwerk sauber konfiguriert sein. Für eine Testumgebung reicht es, wenn die beiden Hosts über genau eine Netzwerkverbindung verfügen. Dort muss das selbe Subnetz eingerichtet sein, ebenso ein passender DNS-Server und ein Gateway. Für Produktivzwecke empfehlen sich deutlich mehr Netzwerkverbindungen, z.B. eine dedizierte für den Heartbeat (Link zwischen den Knoten), eine für die Anbindung an das Storage, eine für die Verwaltung, eine für die Anbindung an das reguläre Netzwerk und so weiter und so fort.

Als nächstes muss auf allen künftigen Knoten das Feature “Failoverclustering” installiert werden. Dazu werden auch die Verwaltungstools angeboten, die zumindest auf einem System installiert sein müssen, um den Cluster einrichten zu können:

failover1

failover2

failover3

Wenn die Installation auf beiden/allen künftigen Knoten abgeschlossen ist kann der “Failovercluster-Manager” gestartet werden, z.B. über “Tools” im Servermanager:

failover4

Dort wird durch einen Rechtsklick auf das Wort “Failovercluster-Manager” im Baum links mittels “Cluster erstellen…” der Prozess begonnen:

failover5

In den ersten Schritten sind die künftigen Knoten auszuwählen:

failover6 failover7
failover8 failover9
failover10  

Danach folgt eine Abfrage bezüglich des “Konfigurationsvalidierungstests”. Dabei werden die beteiligten Server “auf Herz und Nieren geprüft”. Dieser Test dauert ca. 10 Minuten. Man könnte ihn abschalten – verzichtet dann auber auf den Support durch Microsoft und wertvoll Hinweise zur Konfiguration. Nicht zuletzt kann der Test einem auch Fehler aufzeigen, die man bei der Vorbereitung übersehen hat. Ich würde ihn also immer laufen lassen…

failover11 failover16
failover13 failover14
failover15 failover16

Am Ende des Tests wird einem das Ergebnis angeboten (“Bericht anzeigen”):

failover17

In diesem Fall liegt nur eine Warnung vor: Es gibt nur eine Netzwerkverbindung!

Nun muss noch ein Name für den Cluster sowie eine entsprechende IP-Adresse bestimmt werden. Außerdem kann man auswählen, dass der gesamte verfügbare Speicher dem Cluster hinzugefügt werden soll:

failover18 failover19
failover20 failover21

Danach beginnt die eigentliche Bildung des Clusters. Ist diese abgeschlossen, kann die Clusterkonfiguration verändert werden bzw. der Cluster mit Rollen ausgestattet werden. Dabei ist zum einen die Netzwerkkonfiguration zu prüfen: Wenn es einen dedizierten Link zwischen den Hosts geben soll, so ist bei dieser Netzwerkkonfiguration der Haken “Clients das Herstellen einer Verbindung…” zu entfernen. Weiterhin muss das zweite iSCSI-Target noch als “Cluster Shared Volume” (CSV) bzw. al “freigegebenes Clutservolume” hinzugefügt werden. Das sorgt dafür, dass dieses “Laufwerk” auf allen Clutserknoten unter C:\ClusterStorage eingebunden wird und dort genutzt werden kann (z.B. für die VMs und VHDs)

failover22

failover23

Abschließend können nun VMs im Cluster erzeugt werden. Dabei ist darauf zu achten, das alle relevanten Daten unter C:\ClusterStorage liegen!

failover24

failover25

failover26

failover27

Wenn die VM fertig konfiguriert ist und läuft, dann kann man ganz einfach die Funktionsfähigkeit des Clusters testen und einen einfachen Ausfall simulieren: Man zieht einfach das Netzwerkkabel aus dem Host heraus, auf dem die VM aktuell ausgeführt wird. Dann sollte sie in kurzer Zeit auf dem verbliebenen Host neu gestartet werden und dann kurz darauf wieder regulär zur Verfügung stehen!

Schreibe einen Kommentar...

SCVMM2012: Keine IP-Einstellungen beim Erstellen eines Clusters

Beim Erstellen eines Clusters mit Hilfe vom System Center Virtual Machine Manager 2012 unter Server 2008 R2 auf Hyper-V-Hosts unter Server 2008 R2 hatte ich das „Phänomen“, dass der „Create Cluster Wizard“ die Option für die Cluster-IP nicht anzeigte:

 

Es fehlte einfach der Bereich „IP Adress“, dadurch lässt sich der Wizard auch nicht abschließen. Beim Überprüfen aller in Frage kommenden Faktoren, viel mir auf, dass die Netzwerkkarten der beiden Hyper-V-Hosts kein Gateway eingetragen hatten (IP + Subnetzmaske + DNS passten). Nachdem ich ein Gateway (welches die Hosts gar nicht erreichen können) auf beiden NICs eingetragen habe, zeigte der Wizard auch die entsprechende Einstellung an und erstellt den Cluster erfolgreich.

Im Nachgang habe ich das Ganze dann nochmal nachgestellt und den „klassischen“ Cluster-Assistenten verwendet, der vom Windows Server mitgeliefert wird. Dieser zeigt eine Warnung bezüglich des Gateways, stört sich aber sonst nicht weitere daran und erstellt den Cluster problemlos.

Schreibe einen Kommentar...