Es wurde versucht, ein Laufwerk, welches per FC von einem All Flash-System präsentiert wurde, innerhalb von Windows zu formatieren. Dieser Vorgang dauerte horrend lange, wir stießen die Formatierung nachmittags an und konnten das Laufwerk erst am nächsten Vormittag weiterverwenden und in unseren Cluster importieren.
Eigentlich ein sehr unerwartetes Verhalten, erwartet man doch durch die Implementierung solcher Systeme vor allem einen Geschwindigkeitszuwachs.
Erklärung
Seit Windows Server 2012 ist die TRIM-Funktion in Windows standardmäßig aktiviert. Diese Funktion markiert gelöschte Sektoren auf einem Flashspeicher. Bei einer Formatierung eines logischen Volumes sorgt dies wohl für eine regelrechte Flutung des Mediums durch diese Unmap- und Trim-Kommandos.
Diese Funktion sollte also in dem Moment, wo Volumes von All Flash-Systemen dem Windows Server präsentiert werden, abgeschaltet werden.
Behebung
Man schaltet die Funktion ab, in dem über das Konsolenfenster (Win + R -> cmd) folgenden Befehl absetzt:
Im Rahmen einer Fehlersuche entfernten wir ein CSV aus dem Cluster, da dieses von einer der Clusternodes nicht mehr “in Besitz” genommen werden konnte. Später an diesem Tag wollten wir das CSV wieder dem Cluster hinzufügen, da das Problem an anderer Stelle festgemacht werden konnte. Da wir das CSV nicht nur als solches, sondern auch als verfügbaren Speicher enfernt hatten, wollten wir über den Knopf “+ Add Disk” die präsentierte Disk wieder hinzufügen. Statt uns die Disk anzubieten, überraschte uns Microsoft mit der Fehlermeldung:
Für Clusterdatenträger wurden keine geeigneten Datenträger gefunden.
In der Datenträgerverwaltung wurde die Disk in einem der Cluster als RAW-Datenträger erkannt, auf den anderen Nodes war gar keine Formatierung zu erkennen. Egal welche Node wir zu diesem Zeitpunkt als Master verwendeten, die Fehlermeldung blieb die selbe.
Wir versuchten sogar, die Disk auf einer Node online zu schalten und ihr einen Laufwerksbuchstaben zu verpassen. Auch dieser Zugriff war nicht möglich, hier bekamen wir nur folgenden Fehler:
Die angeforderte Ressource wird bereits verwendet.
Ursache:
Scheinbar hat sich bei dem übergeordneten Problem, welches wir hatten und weswegen auch dieser Schritt erst notwendig wurde, der Cluster bei der Ownership-Vergabe verhaspelt. Fakt ist, dass dieses scheinbar nicht lesbare Laufwerk zum Zeitpunkt des Enfernens aus den CSVs noch einer Node zugeordnet war und diese Zuordnung auch nicht verloren hat. Diese Zuordnung verhindert ein erneutes Auffinden der Disk über den Knopf “+ Add Disk”.
Behebung:
Ein einfacher PowerShell-Befehl hat uns im Endeffekt geholfen. Über die Datenträgerverwaltung konnten wir die Disknummer ausmachen (Disk 6). Mit diesem Wissen konnte folgender Befehl über die PowerShell-Konsole abgesetzt werden:
Clear-ClusterDiskReservation -Disk 6
Das ganze musste kurz bestätigt werden und direkt im Anschluss war die Disk wieder zu finden.
Migrationen über den VMM (vorallem zwischen Clustern) können oft zu merkwürdigen Fehlern führen, die sich nicht immer logisch erklären lassen. Aus diesem Grund habe ich hier mal die mir widerfahrenen Probleme aufgelistet, gemeinsam mit Lösungsansätzen.
Es konnte keine verfügbare Verbindung mit dem ausgewählten VM-Netzwerk gefunden werden.
Es wurde keine Verbindung zu “[VM-Netzwerkname]” mit ausreichenden Ressourcen gefunden.
Das ist ein seltsamer Bug. Wenn wir jedoch im VMM aus dem Menüband die PowerShell-Konsole öffnen, und darüber die Migration durchführen, so funktioniert es ohne Probleme – Vorausgesetzt natürlich, dass das Netzwerk tatsächlich an dem Zielhost anliegt. Hierzu gehen wir folgendermaßen vor:
Move-VM : Die VM “XXXXX” kann aufgrund von Inkompatibilitätsproblemen nicht zu Host “XXXXXXX” migriert werden. The virtual machine ‘XXXXX’ is using processor-specific features not supported on physical computer ‘XXXX’. To allow for migration of this virtual machine to physical computers with different processors, modify the virtual machine settings to limit the processor features used by the virtual machine. (Virtual machine ID xxxxxxxx-xxxxxx-xxxxxxx-xxxxxxxx) (Fehler-ID: 23008, Detaillierter Fehler: )
Beheben Sie das Inkompatibilitätsproblem, und wiederholen Sie den Migrationsvorgang.
Hier ist die VM auf einem Host erstellt worden, dessen Prozessorgeneration neuer ist, als der Zielhost der Migration. Behoben werden kann das Ganze, in dem man die VM herunterfährt, den Haken unter “Hardware” -> “Prozessor” -> “Migration zu einem virtuellen Maschinenhost mit abweichender Prozessorversion zulassen” setzt und dann die Migration erneut durchführt. Nach der Migration sollte die Maschine erneut heruntergefahren werden, um diesen Haken wieder zu entfernen.
Move-VM : Der Hostvorgang auf dem Server “XXXXXXXXX” kann von VMM aufgrund des folgenden Fehlers nicht abgeschlossen werden: Virtual machine migration operation for ‘XXXXXXXX’ failed at migration source ‘XXXXXXX’. (Virtual machine ID xxxxxxxx-xxxxxx-xxxxxx-xxxxxxxxx) Virtual machine migration for ‘XXXXXXX’ failed because configuration data root cannot be changed for a clustered virtual machine. (Virtual machine ID xxxxx-xxxxxxxxx-xxxxxxxx-xxxxxx) (Fehler-ID: 12700, Detaillierter Fehler: Unknown error (0x8005))
Beheben Sie das Problem auf dem Host, und wiederholen Sie dann den Vorgang.
Dieser Fehler kann behoben werden, indem man im Anschluss an den Fehler auf “Reparieren” -> “Ignorieren” klickt, und anschließend die Migration erneut triggert. Notfalls über PowerShell.
In unserer Infrastruktur haben wir uns dazu entschieden, jeden HyperV-Cluster in eine eigene Domain zu packen. Zusätzlich gibt es noch einen Management-Cluster, in dem unter anderem die Virtual Machine Manager-Server stehen. Die Domains sind untereinander über Forest-Trusts verbunden. Dieser Aufbau lässt zwar extrem hohe Sicherheitsstandards zu, bringt aber auch Probleme mit sich – Unter anderem beim Hinzufügen neuer HyperV-Cluster.
Vorgang:
Wie gewohnt öffnet man per Rechtsklick auf “All Hosts” oder einer Untergruppe den Assistent zum Hinzufügen von Ressourcen. Da wir wie erwähnt einen Cluster bzw. Host aus einer vertrauenswürdigen Domain hinzufügen wollen, wählen wir den obersten Punkt (“Windows-Server in einer vertrauenswürdigen Active Directory-Domäne”) aus. Anschließend wählen wir die zu verwendenden Anmeldeinformationen aus. Im darauffolgenden Fenster geben wir nun die Hostnamen der Server an, welche wir hinzufügen wollen. Da sich diese nicht in der selben Domain wie der VMM bewegen, geben wir die FQDNs an (hyperv-server01.cluster-domain01.dom). Klicken wir nun auf weiter, schlägt die Überprüfung nach einiger Wartezeit fehl, da er die Hostnamen (hyperv-server01) nicht auflösen kann.
Problem:
VMM ist hier ziemlich doof. Wir geben ihm die FQDNs, doch er will während dem Überprüfungsvorgang plötzlich die Hostnamen auch ohne Domain-Endung ansprechen. Nichts anderes sagt uns auch die Fehlermeldung.
Behebung:
Um das Problem zu umgehen, gibt es zwei Möglichkeiten. Bei einer von beiden von schön zu reden, wäre etwas vermessen:
Hinzufügen der Hostnames aller Hosts in die DNS-Zone der Managementdomain: Die weniger unsaubere Lösung – Einfach in die DNS-Verwaltung der Management-Domain gehen um dort alle Hosts (und Cluster) als A-Records mit deren entsprechender IP einzutragen.
Modifizieren der Hosts-Datei: Nicht schön aber selten – Wir öffnen das Notepad als Admin und öffnen die Hosts-Datei unter C:\Windows\System32\drivers\etc. Dort tragen wir gemäß dem auskommentierten Beispiel alle Host- (und Cluster-) Namen ein sowie deren IP (vorangestellt)
Anschließend kann im VMM auf “Retry” gedrückt werden. Sollte noch immer was fehlen, zeigt er dies zum Glück in der Fehlermeldung an.
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:
Beispiel-GPO
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ß!
Als erstes erstellen wir den Switch, welcher einem Netzwerkinterface zugewiesen werden muss. Man kann hier auch ein Teaming verwenden, wie in diesem Beitrag beschrieben. Wichtig ist der Name des Interfaces, der nun verwendet wird:
#vSwitch-Name
$VSName = "abc"
#Interface auf das der vSwitch gelegt wird
$ethernet = Get-NetAdapter "Name des Interfaces"
New-VMSwitch -Name $VSName -NetAdapterName $ethernet.Name -AllowManagementOS $true
.
Dieser vSwitch hat nun weder IP noch VLAN zugewiesen. Um dies zu erledigen, müssen noch folgende Befehle ausgeführt werden:
Wenn an sich mehr Netzwerkbuchsen im Server verbaut sind als für das Teaming benötigt, so müssen als erstes die richtigen Anschlüsse fürs Teaming deklariert werden. Dies ist notwendig da die Benennung in Windows absolut gar nichts mit der physikalischen Anordnung am Server selbst zu tun hat.
Ich habe es mir da sehr einfach gemacht: Alle Netzwerkkabel abgesteckt und dann ein Kabel (möglichst mit DHCP-Server dahinter) nacheinander in jede Teaming-Buchse eingesteckt, immer gefolgt von folgendem PowerShell-Befehl:
Get-NetAdapter -Physical | where {$_.Status -eq "Up"} | Get-NetIPConfiguration
.
Dabei sollte man sich immer die Property “Interface Alias” notieren.
Mit Hilfe dieser Aliase geht es nun zum zweiten PowerShell-Befehl:
