Shared Nothing Live Migration ist nun bereits seit der Servergeneration 2012 fest integriert und wurde nun auch bei uns im Rahmen von diversen Clusteraktualisierungen zu einem echten Thema. Wie das Ganze funktioniert, werden wir hier im Detail nicht mehr erläutern. Nur soviel sei dazu gesagt: Während die ursprüngliche Live-Migration einen gemeinsam genutzten Storagepool voraussetzt, wird bei der Shared Nothing Live Migration (kurz: VSM) der tatsächliche Speicherort der VM so lange für den Zielhost freigegeben, bis dieser alle benötigten Dateien in den für ihn vorgesehenen Storagepool verschoben hat. Anschließend wird die Freigabe geschlossen, die VM läuft mit max. 2 verlorenen Pings weiter und die Migration ist erfolgreich beendet.
Wie Sie sich vielleicht vorstellen können, bedeutet dieser veränderte Zugriff der Hosts aufeinander logischerweise mehr Konfigurationsaufwand. Vorallem dann, wenn man nicht wie von Microsoft vorgesehen jeden Cluster in die selbe Domain schiebt, sondern für jeden Cluster eine eigene Domain hat. Wir werden Ihnen hier schrittweise aufzeigen, wie wir vorgegangen sind, um dennoch die VSM-Migration zu ermöglichen. Dabei wird auch Bezug auf die Migration über den System Center Virtual Machine Manager genommen, da wir diesen zur Verwaltung unserer Cluster verwenden.
Schritt 1 – Trusts soweit das Auge reicht
Als erstes sorgten wir dafür, dass sich sämtliche Clusterdomains in einer Vertrauensstellung zueinander befanden. Hierzu wurde immer ein Two-Way-Forest-Trust verwendet. Mehr gibt es an dieser Stelle eigentlich nicht zu sagen.
Schritt 2 – Pro Domain eine Gruppenrichtlinie
Nun machen wir pro Clusterdomäne eine Gruppenrichtlinie, die dafür sorgt, dass die Administratoren und Hosts aus den anderen Clusterdomänen Vollzugriff auf die Hosts der Clusterdomain haben:
Schritt 3 – Portfreigabe
Damit die Migration durchgeführt werden kann, müssen diverse Portfreigaben gesetzt werden. Zusätzlich zu den gewöhnlichen LDAP-Ports usw. gesellt sich hier der Port TCP 6600. Ohne den geht gar nichts. Hier wäre es am Besten, einfach das Firewall-Monitoring zu öffnen um zu schauen, was noch zwischen den Clustern geblockt wird.
Schritt 4 – Kerberos
Nun wird es spannend, denn hier müssen wir von jeder Empfehlung abweichen auf Grund unserer Multi-Domain-Struktur. Wir klicken also im ersten Cluster im Domain Controller auf „Active Directory User and Computers“ und suchen die Maschinen-Accounts unserer Hosts. Wir picken uns den ersten Host heraus, öffnen dessen Properties und klicken auf den Tab „Delegation“. Hier müssten wir eigentlich alle Hosts einzeln für die benötigten Services auf dem Host berechtigen. Unser einziges Problem: Wir können hier keine Hosts aus Vertrauensstellungen auswählen. Stattdessen setzen wir also unseren Haken bei „Trust this Computer for Delegation to any service (Kerberos only)“. Da dies ein Stück weit auch die Tore öffnet, ist es umso wichtiger, die Firewall in Schritt 3 sorgfältig zu konfigurieren. Diese Aktion ist für jeden Host in jedem Cluster zu wiederholen.
Schritt 5 – Hyper-V Einstellungen setzen
Nun muss man noch auf jedem einzelnen Hyper-V-Host die generellen Einstellungen anpassen. Dazu öffnen wir den Hyper-V Manager, klicken auf Hyper-V Settings und wählen dann links die Option „Live Migrations“. Folgende Einstellungen müssen gesetzt werden:
[x] Enable incoming and outgoing live migrations
[x] Use any available network for live migration (kann auch geändert werden)
-> Links die Option Live Migrations über das + erweitern und auch noch folgende Einstellungen setzen:
[x] Use Kerberos
[x] TCP/IP oder Compression (das eine belastet das Netzwerk länger, das andere dafür die CPU mehr)
Schritt 6 – Netzwerke publizieren (Nur beim VMM)
Idealerweise haben Sie die Netze schon immer über den VMM gepflegt, ansonsten wird es hier nochmal sehr trocken. Sobald Sie alle Cluster im VMM integriert haben, sollten Sie die Netzwerke anlegen. Ich kann hier nur jedem ans Herz legen, es vernünftig zu machen, sprich ein Netz pro VLAN. Dies hängt ganz einfach mit den Erweiterungsmöglichkeiten des VMM zusammen, wie z.B. dem App Controller, bei welchem Sie den Usern Clouds zuordnen können (Ja, geht auch ohne, aber hier machts auch Sinn). Den Clouds können Sie verfügbare Netze zuweisen, nicht jedoch nur einzelne VLANs aus einem Netz. Nachdem Sie jedes Netz angelegt und die Haken gesetzt haben, für welche Hosts diese Netze verfügbar sein sollen, müssen Sie nun nochmal bei jedem Host im VMM in die Eigenschaften reingehen. Unter dem Punkt Hardware weisen Sie nun den entsprechenden Netzwerkkarten die verfügbaren VLANs zu. Dies ist leider unumgänglich um VMs mit Netzwerkkarten von A nach B umziehen zu können. Man kann es sich leichter machen mit sogenannten Port-Profiles, danach am Besten einfach mal googlen.
Nach diesen Schritten sollte der Live-Migration nichts mehr im Wege stehen. Viel Spaß!