Der erste Schritt ist die Aktivierung des Features “Windows Server-Sicherung”

Nach der Installation können wir unter “Tools” im “Server-Manager” die “Windows Server-Sicherung” aufrufen. Nach einem Klick auf “Sicherungszeitplan” öffnet sich ein Assistent, der uns bei der Erstellung einer Sicherung hilft. Als Konfiguration wählen wir “Benutzerdefiniert”

Im nächsten Feld wählen wir “Elemente hinzufügen” und wählen unsere Hyper-V VMs aus. Man kann erkennen, dass der Aufbau der Sicherung bzw. die Wortwahl an den "DPM erinnert. Auf dem System sind bis auf eine VM ausschließlich Windows-Systeme. Diese können per “Backup using Child Partition Snapshot” gesichert werden, die Linux-VM (Eintrag 4) kann nur per “Backup Using Saved State” gesichert werden.

Das Ergebnis sieht wie folgt aus. Unter “Erweiterte Einstellungen” kann man Ausschlüsse und die Art der VSS-Sicherung einstellen, wir übernehmen in unserem Fall die Standard-Werte

Im nächsten Schritt definieren wir den Sicherungszeitraum bzw. die Häufigkeit der Sicherung

Als Ziel können wir mehrere Arten von Backup-Zielen angeben. Die empfohlene Art ist die Verwendung einer speziellen Backupfestplatte. In diesem Fall wird die ausgewählte Festplatte komplett formatiert und ausschließlich für die Windows-Sicherung genutzt. Das Ergebnis sieht wie folgt aus

Die weiteren Möglichkeiten wäre die Sicherung auf einer Festplatte ohne die Formatierung und exklusive Nutzung und die Sicherung in einen Netzwerkordner. Ich habe mich in diesem Fall für die empfohlene Variante entschieden. Im nächsten Schritt werden die verfügbaren Datenträger aufgelistet, wie man erkennen kann können hier auch USB-Festplatte genutzt werden.

Bei der von mir verwendeten Variante erscheint eine Warnung, das alle Daten gelöscht werden

Nach der Bestätigung bekommt man eine Zusammenfassung der Einstellungen, danach wird die Sicherung eingerichtet

Man bekommt eine kleine Zusammenfassung der Einrichtung, danach ist die Sicherung konfiguriert

Unser Vorgehen bei einem solchen Problem ist die Aufnahme von Leistungsdaten auf dem oder den Systemen und eine anschließende Auswertung mit dem Performance Analysis of Logs, kurz PAL. Dieses kleine, aber sehr mächtige Tool ist in der Lage, vorhandene Messwerte zu analysieren, sie zu bewerten und grafisch in einem Report auszugeben. Diese Vorgehensweise möchte ich hier einmal näher erklären.

Die Vorgehensweise bei einer Analyse

Mit Hilfe der Leistungsüberwachung auf einem Host (unter Verwaltung zu finden) wird eine Leistungsüberwachung gestartet, die für einen definierten Zeitraum ein Logfile erstellt und vorher definierte Indikatoren abfragt und protokolliert. Dieses Logfile wird später mit dem PAL analysiert und ausgewertet.

Der Download von PAL und die Voraussetzungen

PAL kann frei über Codeplex bezogen werden:

Microsoft Codeplex: Performance Analysis of Logs (PAL) Tool

Voraussetzungen für die Nutzung des Programms sind

• PowerShell 2.0 oder höher
• .Net Framework 3.5 SP1
• Microsoft Chart Controls für .NET Framework 3.5

Es ist nur dann möglich das Programm zu nutzen, wenn man die System-Lokalität auf English-US stellt, da scheinbar gewisse Parameter oder Namen genutzt werden, die nur in dieser Sprache zur Verfügung stehen. Ich habe es mit einem deutschen System probiert, die Analyse startet erst gar nicht, sondern es erscheint direkt eine Fehlermeldung. Eine Umstellung der System-Lokalität habe ich nicht gemacht, ich habe mir für die Auswertung ein Server 2008 R2 SP1 in Englisch installiert, damit hat die Analyse problemlos funktioniert.

Wichtige Information: Nur die Maschine, die die Analyse der Messwerte mit PAL übernimmt muss eine English-US-Lokalität haben, die Erstellung der Performance-Messwerte kann auf einem deutschsprachigem System passieren.

Die Erstellung einer Messung

Das erste Fenster, was man nach dem Aufruf der Leistungsüberwachung sieht, zeigt den Verlauf der CPU-Auslastung im Host:

Wir wechseln zu “Sammlungssätze”, und erstellen mit einem Rechtsklick unter “Benutzerdefiniert” einen neuen Sammlungssatz:

Wir wählen die folgenden Einstellungen:

Im nächsten Fenster wählen wir “Hinzufügen” und können nun aus allen zur Verfügung stehenden Indikatoren wählen.

Die Frage, dies sich vielen nun stellt, ist die, welche Indikatoren sinnvoll sind und was wofür genutzt wird. Hier kommt PAL das erste Mal mit einer Empfehlung. Wenn man PAL aufruft, erscheint das folgende Fenster mit einer Begrüßung.

Im Reiter “Threshold File” gibt es einige Vorlagen, unter anderem die Vorlage “Microsoft Hyper-V R2 SP1”.

Wenn wir diesen Eintrag auswählen und auf “Edit” klicken, bekommen wir eine Übersicht über die Indikatoren, die mit dieser Vorlage ausgewertet werden. Wenn man sich die Gruppen aufklappt und einen Indikator markiert, wird rechts eine Beschreibung angezeigt, weiterhin werden teilweise Empfehlungen aufgeführt. Bei “Cluster Shared Volumes” => “Cluster Shared Volumes IO Read Bytes” sieht das wie folgt aus:

Eine komplette Liste der Indikatoren sieht wie folgt aus:

Auf einem englischen System fangen die einzelnen Gruppen fast alle mit “Hyper-V …” an, auf einem deutschen System wurde dies leider nicht so übernommen, dort sind die Gruppen teilweise recht schwer zu finden. Aus diesem Grund hier eine Liste mit den deutschen Namen, damit diese einfacher zu finden sind:

• Cache
• Freigegebene Clustervolumes
• Hyper-V-Ausgleichsmodul für dynamischen Arbeitsspeicher
• Dynamischer Hyper-V-Arbeitsspeicher – virtueller Computer
• Logischer Prozessor für Hyper-V-Hypervisor
• Hyper-V-Hypervisor-Partition
• Hyper-V-Hypervisorstammpartition
• Virtueller Prozessor des Hyper-V-Hypervisorstamms
• Virtueller Prozessor von Hyper-V-Hypervisor
• Hyper-V-Hypervisor
• Hyper-V – Integritätszusammenfassung
• Virtueller Hyper-V-Netzwerkadapter
• Virtuelles Hyper-V-Speichergerät
• Virtueller Hyper-V-Switch
• Hyper-V VM-VID-NUMA-Knoten
• Hyper-V VM-VID-Partition
• Logischer Datenträger
• Arbeitsspeicher
• Network Inspection System
• Netzwerkschnittstelle
• Auslagerungsdatei
• Physikalischer Datenträger
• Prozess
• Prozessorinformationen
• Prozessor
• RemoteFX Root GPU Management
• Server
• System

Export und Import von einer Vorlagen-Datei

Man muss sich die oben aufgelisteten Indikatoren nicht einzeln heraussuchen, die im PAL hinterlegten Einträge können exportiert und auf Host wieder importiert werden, das spart Zeit und Sucherei. Im PAL unter “Threshold File” wählen wir die Vorlage “Microsoft Hyper-V R2 SP1” aus und klicken auf “Export to Perfmon template file…”.

Die exportierte XML-Datei kopieren wir nun auf unseren Hyper-V Host und öffnen dort die Leistungsüberwachung. Unter “Sammlungssätze” => “Benutzerdefiniert” wählen wir “Neu” => “Sammlungssatz”.

Wir geben dem Sammlungssatz einen Namen und wählen die Option “Aus einer Vorlage erstellen”.

Im nächsten Fenster klicken wir auf “Durchsuchen…” und wählen die zuvor erstellte XML-Datei aus

Ein Klick auf “Fertig stellen” erstellt unsere “Hyper-V Messung”. In den Eigenschaften können wir bestimmte Optionen anpassen

Was ich persönlich immer direkt einstelle ist eine Stoppbedingung. Dies verhindert, das eine Auswertung (falls sie mal vergessen wird) ewig läuft und die Festplatte vollschreibt.

Weiterhin sehr hilfreich ist die Erstell-Möglichkeit eines Zeitplans, so könnten z.B. über eine Woche hinweg jeden Tag zwischen 06 und 18 Uhr die Werte mitprotokolliert werden, in der Nacht wenn niemand arbeitet nicht.

Wenn man links in der Spalte auf die benutzerdefinierte Messung klickt, sieht man rechts eine Auflistung der definierten Indikatoren-Sammlungs-Sätzen. Ein Doppelklick hierauf öffnet die oben aufgeführte Liste mit den Indikatoren und eine Einstellmöglichkeit für die Intervalle. Standardmäßig werden die Werte alle 15 Sekunden abgefragt, evtl. sollen bestimmte Indikatoren aber häufiger protokolliert werden. Dies ist hier einstellbar.

Die Auswertung des Logfiles mit PAL

Nachdem die Messung gelaufen ist, können wir mit der Auswertung und Analyse der Werte beginnen. Hierzu rufen wir das PAL-Programm auf und klicken und durch die Einstellungen. Im zweiten Reiter wählen wir die von uns erzeugte BLG-Datei

Unter “Threshold File” wählen wir “Microsoft Hyper-V R2 SP1” aus

Im nächsten Fenster werden uns einige Fragen gestellt, diese sind

• NumberOfProcessors – Hier wird die Anzahl an Kernen eingetragen, die auch im Taskmanager unter Performance/Leistung angezeigt wird
• ThreeGBSwitch – Wird der RAM des Servers künstlich auf 3 GB begrenzt? Ich vermute mal nein ;)
• SixtyFourBit – Ist das System ein 64-Bit-System?
• TotalMemory – Die Anzahl an Arbeitsspeicher im Server
• RAID5Drives – Sind in dem Server Festplatten zu einem RAID5-Verbund zusammengeschlossen? Hier müssen, falls ja, die Laufwerksbuchstaben angegeben werden
• RAID1Drives – Sind Festplatten im RAID1 oder RAID10-Verbund vorhanden? Wenn ja, müssen hier die Laufwerksbuchstaben angegeben werden

Unter “Output Options” können die Analyse-Intervalle im Logfile angegeben werden, alternativ werden automatisch Intervalle gesetzt. Die untere Option zwingt das Programm, alle Counter auszuwerten, falls diese vorhanden sind.

Unter “File Output” kann der Ausgabe-Pfad sowie das Ausgabe-Format gewählt werden. Standardmäßig wird ein HTML-Report erzeugt, auf Wunsch kann allerdings auch eine XML-Datei erzeugt werden.

Der Reiter “Queue” zeigt uns eine Zusammenfassung der Einstellungen an.

Unter “Execute” können wir wählen ob die Auswertung sofort gestartet wird oder in eine Warteschlange aufgenommen wird, um später konvertiert zu werden. Zusätzlich kann hier die Priorität der Konvertierung heruntergesetzt werden.

Als letzten Schritt klicken wir auf “Finish” und die Konvertierung startet. Wenn diese fertig ist, öffnet sich ein Browser mit dem erzeugten HTML-Report.

Die Übersetzung des Logfiles

Wenn die Erstellung des Logfiles nicht auf einem englischen System vorgenommen wurde, kann es passieren das nach dem Start der Auswertung der folgende Fehler auftaucht.

Dies bedeutet, dass das Programm die BLG-Datei nicht lesen kann. In diesem Fall muss man sich das kleine Programm “Perfmon Log Translator” herunterladen und die Datei konvertieren. Das Programm ist hier zu finden:

Download: Perfmon Log Translator (PLT)

Das Programm ist sehr einfach aufgebaut, man wählt als erstes seine Datei aus, wählt die Quell-Sprache und kann dann eigentlich schon mit “Execute!” die Konvertierung starten.

Das Ergebnis sieht wie folgt aus:

Wenn wir nun das PAL-Tool mit dem neuen Logfile füttern, sieht das Ergebnis besser aus:

Der Report

Wenn die Auswertung komplett durchgelaufen ist, bekommen wir als Ausgabe einen Report, der als erstes alle Fehler bzw. Warnungen in chronologischer Reihenfolge auflistet, danach werden alle Auswertungen, gruppiert nach Parameter, aufgelistet. Der Report an sich ist sehr aufwendig und groß, zusätzlich zu den Werten werden noch weitere Informationen und Tipps aufgelistet. Dies sieht z.B. für die Anzahl an Disk-Transfers pro Sekunde wie folgt aus:

Wenn Sie Unterstützung bei der Messung Ihrer Host-Performance, Hilfe bei der Interpretierung Ihrer Ergebnisse oder Referenz-Werte von z.B. unseren Systemen benötigen stehen wir Ihnen natürlich gerne zur Verfügung.

Ich wünsche wie immer viel Spaß beim Zuschauen.

P.S.: Das im Videocast benutzte Tool heißt HyperV_Mon und wurde von Tim Mangan entwickelt. Nähere Informationen gibt es auf seiner Website

Was zeige ich in dem Videocast? Ich demonstriere an Hand eines unserer Hyper-V PowerKurs System, das wenn wir in einer VM mit zwei vCPUs einen Primzahlen Generator starten wir auf dem QuadCore Core i5 System nicht die erwarten 50 Prozent Auslastung im Taskmanager auf dem Hyper-V Host sehen, sondern nur ca. 6 Prozent. Danach erkläre Ich, warum wir in der Parent Partition nur 6% sehen und nicht 50% und demonstrieren dann mit der Windows  Leitungsüberwachung und dem Tool HyperV_Mon wie man die tatsächliche Belastung heraus bekommt.

Microsoft TechNet Forum: 2008 R2 Failover Cluster – Überprüfung ok, aber erstellen schlägt fehl

Die Lösung war (sowohl bei dem Autor als auch bei mir) die Deinstallation des Features per Kommandozeile, ein Neustart, die erneute Installation per Kommandozeile und ein erneuter Neustart. Danach lies sich das Cluster problemlos erstellen. Die betreffenden Befehle zur Deinstallation und zur Installation sind:

dism /online /disable-feature /featurename:FailoverCluster-FullServer

zur Deinstallation und

dism /online /enable-feature /featurename:FailoverCluster-FullServer

zur erneuten Installation. Bitte auf die Groß-/Kleinschreibung achten, sonst kommt es zu einer Fehlermeldung. Die Hilfe zeigt dies auch noch einmal auf

Der Aufbau

Der Aufbau der Umgebung sieht grafisch wie folgt aus

In das Management-Netz wird nun ein weiterer Server mit dem DPM gestellt. Auf jeden der vier Hosts wird der DPM-Agent installiert, wenn man danach einen der Server in der DPM-Konsole hinzufügt werden automatisch alle weiteren Cluster-Knoten hinzugefügt (wenn man dies möchte). Nach dem Hinzufügen tauchen die vier Hosts nicht mehr einzeln, sondern als Cluster auf. Der DPM erkennt, dass es sich um ein Failover-Cluster handelt und behandelt dieses auch so.

Ohne die Installation weiterer Software sind wir nun in der Lage, Backups der VMs zu erstellen. Diese Backups werden allerdings vom DPM mit einer oder mehreren Fehlermeldungen begleitet

Warum ist dies so? Die von mir erstellte Schutzgruppe ist so konfiguriert, das täglich um 07.00 Uhr ein Backup der Gruppen-Mitglieder erstellt wird. Bei einem Backup-Vorgang müssen in meinem Fall 21 VMs gesichert werden.

Software vs. Hardware VSS Provider

Die Möglichkeit einer Live-Sicherung der VMs wird uns ermöglicht durch einen VSS-Snapshot (Volume Shadow Copy Service) der VM im Betrieb. Es gibt zwei Arten von Snapshot Providern:

Software VSS Provider

Dieser Provider ist im Windows enthalten. Bei Beginn eines Backups wird die Anbindung an das Storage-System umgeleitet, wir befinden uns im “Redirected Mode”. Dieser Modus wird genutzt, wenn ein Knoten keinen direkten Zugriff auf das CSV erhält. In diesem Fall wird der Zugriff auf das CSV ermöglicht, indem über einen anderen Knoten auf das CSV zugegriffen wird. Dies beugt einem Ausfall vor, allerdings verschlechtert sich hierdurch die Performance. Bei einem Backup wird die Anbindung an das CSV in den Redirected Mode geschaltet, wenn das Backup mit Hilfe des Software Providers erfolgt bleibt der Zugriff während des gesamten Backupzeitraums umgeleitet.

Der Zugriff der Hosts auf den Storage erfolgt im Normalzustand wie folgt:

Jeder Host ist (bestenfalls) redundant an den Storage angebunden. Diese Ansicht ändert sich, wenn wir uns im Redirected Mode befinden:

Man kann erkennen, dass der gesamte Traffic über den Coordinator Node läuft. Vorher hatten wir zwei x 1 GBit/s pro Knoten zur Verfügung, diese 8 GBit/s werden nun auf ein Viertel gedrosselt. Wenn sich in dem Cluster 16 Knoten befinden, die alle über einen einzigen Knoten kommunizieren, kann sich dies enorm (negativ) auf die Performance auswirken.

Hardware VSS Provider

Diese Art von Provider wird in der Regel von dem Storage-Hersteller zur Verfügung gestellt, man kann ihn wie einen Treiber für den Storage sehen. Bei der Erstellung eines Backups einer VM wird über den Hardware VSS Provider ein Snapshot auf dem Storage angestoßen, nach Erstellung des Snapshots werden die Daten vom DPM-Server abgeholt. Der Vorteil dieser Art von Provider ist der, dass der Zugriff auf das CSV nur während der Snapshot-Phase im umgeleiteten Modus ist. Nach diesem in der Regel recht kurzen Zeitraum wird der Zugriff wieder online geschaltet, in der Zeit wo die Daten vom Storage über den Host zum DPM-Server gesendet werden ist die Performance nicht durch eine Umleitung beeinträchtigt.

Ein interessanter Artikel mit weiteren Infos und mehr Hintergrund zum Thema “Redirected Mode” finden Sie hier: Ask the Core Team: Troubleshooting ‘Redirected Access’ on a Cluster Shared Volume (CSV)

Der Backup-Vorgang in Zeitlupe

Zur besseren Verständlichkeit hier beide Arten von Backup im Detail. Grundsätzlich gleich sind die vier Clusterknoten Hyperv4, Hyperv5, Hyperv6 und Hyperv7.

Software VSS Provider

Auf dem Data Protection Manager beginnt laut Zeitplan die Sicherung von vWinXPTest. Diese VM befindet sich aktuell auf Hyperv4. Besitzer des CSV ist Hyperv6.

Im DPM startet nun die Sicherung. Als erstes wechselt der Besitzer des Clustervolumes zu dem Besitzer der VM, danach beginnt die Erstellung des VSS-Snapshots. Man erkennt den Backup-Vorgang am Status des CSV.

Dieser Status bleibt nun so lange bestehen, bis das Backup beendet ist. Im Taskmanager auf Hyperv4 erkennt man, dass über das Management-Netzwerk die Daten in Richtung DPM geschickt werden und über die beiden iSCSI-Netzwerke vom SAN geholt werden.

Hardware VSS Provider

Auf dem Data Protection Manager beginnt laut Zeitplan die Sicherung von vWinXPTest. Diese VM befindet sich aktuell auf Hyperv4. Besitzer des CSV ist Hyperv6.

Im DPM startet nun die Sicherung. Als erstes wechselt der Besitzer des Clustervolumes zu dem Besitzer der VM, danach beginnt die Erstellung des VSS-Snapshots. Man erkennt den Backup-Vorgang am Status des CSV. Bis zu diesem Punkt ist die Sicherung gleich, zumindest sieht es für uns so aus. Im Hintergrund wird nun auf dem SAN ein Snapshot angestoßen. Während der Zeit des Snapshots befindet sich das CSV im Umgeleiteten Modus, im Failovercluster-Manager wird der Status angezeigt.

Nachdem der Snapshot auf der NetApp gemacht wurde, wechselt der Status des CSV in den folgenden Modus

Dies bleibt noch eine kurze Zeit so, danach wechselt der Status auf grün (online) und der Zugriff ist ohne eine Umleitung über den Coordinator Node möglich. Die Sicherung ist in diesem Fall allerdings noch nicht fertig, im Hintergrund werden noch fleißig Daten übertragen bzw. geprüft, welche Daten sich geändert haben. Dies ist im Taskmanager erkennbar.

Fazit

Beim Einsatz eines Failover-Cluster sollte man sehr genau darauf achten, dass das genutzte SAN einen Hardware VSS Provider mitbringt. Man verkürzt die Zeit, in der sich das Cluster im Redirected Mode befindet erheblich. Weiterhin wird die Dauer der Gesamtsicherung verkürzt. Ein Failover-Cluster sollte so wenig wie möglich im Redirected Mode betrieben werden, unterstützende Software seitens des SAN-Herstellers helfen hierbei.

Aktuell sieht der Bereich “Aggregate” wie folgt aus:

Der Punkt “Volumes” zeigt die folgenden Volumes:

Jedes der Volumes enthält eine LUN, diese sehen wie folgt aus:

Wie man erkennen kann, ist csv1 und quorum1 online, die beiden mittleren LUNs sind offline und aktuell nicht verbunden.

Nachdem man sich per ssh auf die Managementkonsole der FAS6040 geschaltet hat, kann man die Migration eines Volume mit dem folgenden Befehl starten:

vol move start Quell-Volume Ziel-Aggregat

In meinem Fall beginne ich mit Vol1, einem offline geschalteten Volume.

Mit dem Befehl

vol move status –v

kann man sich den Verlauf der Migration anschauen. An dieser Stelle wird lange Zeit nichts angezeigt, die Größe der verschobenen Daten bleibt hier scheinbar die ganze Zeit bei 0 KB, obwohl im Hintergrund die Daten migriert und verschoben werden.

Nachdem die Migration erfolgreich beendet wurde, erscheinen die folgenden Meldungen:

Der Manager zeigt das folgende Bild:

Das ganze funktioniert auch mit online-Volumes:

Da es sich nur um 1GB handelt, wir dies natürlich sehr schnell übernommen. Nach der Übernahme sieht der Manager wie folgt aus:

Das Cluster und die Cluster-Knoten bekommen von der ganzen Sache nichts mit, das ganze passiert alles im Hintergrund. Cooles Feature :)

Um die im oberen Teil in Worten versuchte Erklärung weiter zu vereinfachen, hier ein Screenshot mit der Funktionsweise:

Die Erstellung einer Vorlage

Um eine Vorlage zu erstellen, erstellen wir wie gewohnt eine VM. Bei der Auswahl der Festplatte ist zu beachten, dass die Größe der Vorlagen-VHD später die Größe sein wird, die in dem System zur Verfügung stehen wird. Wenn wir hier nur z.B. 15 GB angeben, können wir später auch nur 15 GB nutzen. Nach der Erstellung der VM inkl. einer VHD benennen wir das System so, wie unser erstes System später heißen soll. Die Einstellungen der VM passen wir nach unseren Einstellungen an und starten die VM. Wir installieren das von uns benötigte System und passen das System so an, wie es nach dem Start einer weiteren “Kopie” aussehen soll. Zu diesen Anpassungen zählt z.B. die Installation aller bisher erschienenen Updates, die Installation oder Ablage von Programmen auf der lokalen Festplatte usw.

Hier die Installation in Screenshots. Zuerst legen wir eine neue VM an

Bei der Wahl der Festplatte denken wir daran, dass diese Größe später wichtig und unsere Maximalgröße ist. Falls eine VHD mit fester Größe erstellt werden soll kann dies nicht an dieser Stelle passieren, sondern muss nach der Erstellung der VM separat erfolgen

Wir passen die Einstellungen der VM an unsere Bedürfnisse an

Als nächstes starten wir die VM und installieren das Betriebssystem

Nach der Installation führen wir die Schritte durch, die jede VM benötigt, wir aber nur einmalig machen möchten. Weiterhin ist zu bedenken, dass alles was nun installiert und kopiert wird einmalig in der Basis-VHD liegt und nicht in jeder der differenzierenden VHDs. Da es sich in meinem Fall um ein Windows XP handelt installiere ich die Integrationskomponenten

Weiterhin kopiere ich NewSid (Bitte keine Diskussion über NewSid starten, ich weiß dass das Tool nicht mehr “state of the art” ist ;)) auf die lokale Festplatte unter C:\system

Als nächstes schalten wir den Client aus

In den Eigenschaften entfernen wir die VHD

Das Ergebnis sieht wie folgt aus

Im Explorer verschieben wir nun die .vhd-Datei aus dem Ordner der VM heraus in einen eigenen Ordner, ein aussagekräftiger Name ist hier sinnvoll

Als nächstes setzen wir in den Eigenschaften der VHD die Einstellung “Schreibgeschützt”

Zurück im Hyper-V-Manager erstellen wir über Neu => Virtuelle Festplatte eine neue VHD, dieses Mal wählen wir die Option “Differenzierend”

In der nächsten Option konfigurieren wir den Pfad und den Namen der VHD-Datei. Wie man erkennen kann, ist hier keine Eingabe der Größe möglich

Im nächsten Schritt geben wir den Pfad und Namen der Basis-VHD an, dies ist die VHD, die wir im vorherigen Schritt kopiert und mit einem Schreibschutz versehen haben

Nach einem Klick auf “Fertig stellen” weisen wir unserer VM diese soeben erstellte VHD zu

Wir können die VM nun starten, nach dem Start führe ich NewSid aus, um die SID des Systems zu ändern

Weiter geht es mit der Erstellung der zweiten VM. Hierzu erstellen wir im Hyper-V-Manager im Wizard eine neue VM

Die Einstellungen können nach Belieben angepasst werden, bei der Wahl der virtuellen Festplatte wählen wir die folgende Option

Nachdem wir die VM erstellt haben öffnen wir die Eigenschaften. Hier passen wir uns die Einstellungen nach unseren Wünschen an, weiterhin fügen wir unter “IDE Controller 0” eine Festplatte hinzu

Wir wählen im folgenden Fenster “Neu” und erstellen eine differenzierende Festplatte

Falls diese VHD-Datei im Ordner “Virtual Hard Disks” gespeichert werden soll, muss dieser Ordner noch angelegt werden im Explorer

Wir konfigurieren erneut die VHD sowie den Pfad zu der Basis-VHD

Nach der Bestätigung und dem Start der VM habe ich mit NewSid die SID des Systems geändert, zusätzlich kann ich mit dem Programm auch den Namen des Systems anpassen.

Mit dieser Vorgehensweise kann ich mir eine große Anzahl an VMs erstellen, die jeweils immer auf eine VHD zurückgreifen. Ich habe die beiden Server in der Testumgebung ebenfalls mit dieser Variante eingerichtet, man kann im Explorer gut erkennen, wie groß die differenzierende VHD der beiden Windows Server 2008 R2 während der Sysprep-Phase ist

Im Ressourcenmonitor kann man gut erkennen, dass die Basis-VHD nur lesend in Nutzung ist, die beiden differenzierenden VHDs jeweils lesend und schreibend bearbeitet werden

Die oben beschriebene Art von Einsparung funktioniert natürlich nur dann, wenn sich die Systeme im späteren Betrieb nicht mehr viel voneinander unterscheiden. Ein gutes Beispiel für die Nutzung dieser Art von Festplatte ist z.B. VDI. Wenn Sie Unterstützung bei der Auswahl Ihrer Strategie benötigen oder generelle Hilfe beim Betrieb oder Aufbau Ihrer Hyper-V Umgebung benötigen, stehen wir Ihnen gerne zur Verfügung. Unsere Kontaktdaten sowie unsere Preise finden Sie rechts in der Navigationsleiste.

Momentan “tingle” ich mit Microsoft auf den TechDays Private Cloud durch Deutschland. Mich begleiten für meine Livedemo drei von unseren “Hyper-V Powerkurs” Systemen. Da ich in meinen Vorträgen schon mehrfach nach der Konfiguration der Demo gefragt wurde, habe ich diese hier beschreiben. Übrigens: wer die super performanten Schulungssystem nachbauen möchte, der findet die Konfiguration in dem Artikel “Empfehlung: Unser Hyper-V Schulungs-System” beschrieben.

Der schematische Aufbau des Demo Infrastruktur zeigt die Grafik. Das System unterhalb des stilisierten Netzwerks ist dabei die Storage- und Management Maschine. Die beiden Systeme oberhalb des Netzwerks sind die beiden Hyper-V Cluster Hosts.

Storage- und Management System

Auf dem Management System ist Windows Server 2008 R2 Edition (mit SP1) und das Microsoft iSCSI Software Taget 3.3 installiert. Mit dem iSCSI Target ist es möglich auf den lokalen SSD-Platten des Systems zwei VHDs als Storage für den Hyper-V Cluster bereitzustellen. Eine VHD ist dabei ein ca. 150GB großes Cluster Shared Volume und die andere VHD eine 1 GB große Quorum Disk. Weiterhin ist auf dem System die Hyper-V Role aktiviert und zwei VMs installiert. Die eine VM ist ein ADS-Controller mit DNS- und DHCP-Server, damit alle notwendigen Infrastruktur Dienste für die autarke Umgebung bereitstehen. Die andere VM enthält den Virtual Machine Manager 2012 RC mit dem ich den Hyper-V Cluster verwalte.

Anmerkung: Wenn man in das Storage-System noch 2 große SATA Platten bauen würde, könnte das System mit einem in der Parentpartition installiertem DPM den Cluster sichern und noch weitere VMs beheimaten.

Hyper-V Cluster Node

Auf den beiden Hyper-V Cluster Nodes ist jeweils die Microsoft Server 2008 R2 Enterprise Edition (SP1) installiert. Es wäre hier auch möglich den freien Hyper-V Server 2008 R2 SP1 zu benutzen, da beide die benötigten Failover-Cluster Funktionen bereitstellen. Auf das iSCSI Target des Storage- System wird mittels iSCSI Initiator über MPIO redundant zugegriffen.

Netzwerk

Alle Hosts sind mit mehreren Netzwerkschnittstellen mit einer Switch (in der Produktion sollten es mindestens zwei sein) verbunden. Das Management System nutzt hierbei vier Interface (Management, VM, iSCSI und iSCSI2) und die Cluster Nodes jeweils sechs Interface (Management, iSCSI, VM, Livemigration, CSV und iSCSi2). Das Netzwerk ist dabei wie in unserem Artikel Netzwerkkonfiguration im Hyper-V Cluster konfiguriert.

Kosten

Die ganze genutzte Konfiguration ist nicht ganz billig. Vorausgesetzt man hat die Softwarelizenzen oder benutzt Eval Versionen kostet das Equipment unter netto € 4.000. Man bekommt dafür:

1. drei sehr leise Powerworkstations mit je 16GB RAM, Core i5, 2x schnellen 120GB SSDs, 6 Intel GBit Ports

2. eine sehr leise HP Procurve 1810-24G 24 Port GBit Switch mit Kabeln

Fazit

Die Hardware bietet die Möglichkeit, sich mit dem Microsoft Hyper-V Cluster und den Produkten aus der neuen System Center 2012 Familie auseinander zu setzen. Das ist, betrachtet man die ganzen Neuerungen in den System Center 2012 Produkten, auch dringend notwendig. Starten Sie jetzt, damit Sie, wenn die nächste Version vom Windows Server herauskommt, gewappnet sind. Denn System Center 2012 und Windows 8 “neu lernen” ist so viel, da könnte man schon mal den Mut verlernen.

Hier sind noch einige Links damit man mit den Pre-Release und freien Eval Versionen starten kann:

Microsoft System Center 2012 Pre-Release Products

Windows Server 2008 R2 SP1 180 Testversion

Microsoft SQL Server 2008 R2 Testversion

Windows Automated Installation Kit (AIK) für Windows 7

Die Installation beginnt mit dem Aufruf der Setup.exe im Installations-Verzeichnis. Dort sollte man sich den Installation Guide anschauen, ein Klick auf diesen Punkt öffnet einen Internet Explorer und eine Microsoft-Seite. Die eigentliche Installation des Servers beginnt mit dem Aufruf von “Data Protection Manager” im Menü “Install”.

In unserem Fall installiere ich den DPM mit einer lokalen Datenbank, hierfür muss ein SQL 2008 R2 Express installiert werden.

Der DPM ist nun installiert. Hier ein paar Eindrücke von der Administrator-Konsole.

Als nächstes installieren wir auf einem anderen Server im Netzwerk einen DPM-Agenten und wollen einen ganz bestimmten Ordner in die Sicherung aufnehmen. Wie schon bei dem DPM 2010 lässt sich der Agent nicht installieren, wenn die Firewall des Servers, auf dem der Agent installiert werden soll, aktiv ist. Es erscheint der Fehler 347, für eine erfolgreiche Installation müssen diverse Ports freigegeben bzw. Regeln aktiviert werden. Dies kann entweder manuell erfolgen, oder man macht es sich etwas leichter und deaktiviert für die Dauer der Installation die Windows Firewall für den Bereich, in dem der Server mit seiner Netzwerkkarte steht, in der Regel ist dies “Domänennetzwerk”. Nach der Installation kann und sollte die Firewall wieder aktiviert werden, alle benötigten Regeln sind automatisch eingetragen worden. Diese automatische Eintragung funktioniert aber vermutlich nur, wenn nur die Regeln für einen Bereich der Firewall abgeschaltet werden (in unserem Fall ist “Heimnetzwerk” und “Öffentliches Netzwerk” noch aktiv) und nicht wenn die Firewall komplett deaktiviert wird.

Der Agent ist nun installiert, es kann nun im Bereich “Protection” eine Schutzgruppe definiert werden. Wie man erkennt ist dies allerdings nur möglich, wenn mindestens eine weitere komplett leere und unformatierte Festplatte zur Verfügung steht. Eine weitere Partition oder der Rest einer Festplatte mit freiem Speicherplatz ist NICHT nutzbar und kann nicht verwendet werden. Eine gute nutzbare Alternative zu lokalen Festplatten sind übrigens per iSCSI angebundene Geräte. Wie man in den Screenshots erkennen kann, ist die “long-term protection”, also die Langzeit-Sicherung auf ein Band nicht anwählbar. Dies hat den Hintergrund, das es sich bei dem DPM-Server um eine VM handelt und an diese VM kein Bandlaufwerk angeschlossen ist. Somit ist nur die Variante der Festplatten-Sicherung möglich.

Gestern ist die öffentliche Beta von System Center Data Protection Manager 2012 erschienen. Jetzt stehen die meisten Produkte der kommenden System Center 2012 Familie für jedermann zum Testen zur Verfügung. Da wird es Zeit, mal die Links auf die verschrienen Private Cloud Downloads zusammenzufassen. Im Folgende findet man die Testversionen der aktuellen Produkte und für experimentierfreudige Zeitgenossen die Betas der neuen Produkte.

Windows Server 2008 R2 SP1 Testversion:
http://technet.microsoft.com/evalcenter/dd459137.aspx?ocid=otc-n-de-jtc–EVAL_WS2008R2SP1

Hyper-V Server 2008 R2 SP1:
http://technet.microsoft.com/evalcenter/dd776191.aspx?ocid=otc-n-de-jtc–EVAL_HVS2008R2SP1

System Center Virtual Maschine Manager 2008 R2 SP1 Testversion:
http://technet.microsoft.com/evalcenter/cc793138.aspx?ocid=otc-n-de-jtc–EVAL_SCVMM2008R2SP1

System Center Virtual Maschine Manager 2012 Beta:
http://technet.microsoft.com/evalcenter/gg678609.aspx?ocid=otc-n-de-jtc–EVAL_SCVMM2012BETA

System Center Operation Manager 2007 R2 Testversion:
http://technet.microsoft.com/evalcenter/bb738014.aspx?ocid=otc-n-de-jtc–EVAL_SCOM2007R2

System Center Operation Manager 2012 Beta:
http://www.microsoft.com/download/en/details.aspx?id=26804

System Center Configuration Manager 2007 R3 Testversion:
http://technet.microsoft.com/evalcenter/bb736730.aspx?ocid=otc-n-de-jtc–EVAL_SCCM2007R3

System Center Configuration Manager 2012 Beta:
http://technet.microsoft.com/evalcenter/ff657840.aspx?ocid=otc-n-de-jtc–EVAL_SCCM2012BETA2

System Center Data Protection Manager 2010 Testversion:
http://technet.microsoft.com/evalcenter/bb727240.aspx

System Center Data Protection Manager 2012 Beta:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=27216

Und zum Schluß noch ein Schmankerl. Microsoft bietet mit der Microsoft Virtual Academy eine kostenfreie Lernplatform auf der man sich mit allem möglichen Rund um die Virtualisierung beschäftigen kann.

Wie das geht findet man im Folgenden stichpunktartig (dient nur als Grobanleitung).

1. NetApp FSA6040 als SCSI Targets an jedem Host des Hyper-V Cluster bekannt machen
2. Hyper-V Hosts auf der FSA6040 als iSCSI Targets bekannt machen
3. Auf Quell NetApp meldet man sich per Telnet oder SSH an der CLI an
4. Mittels des Befehls “lun show –v” alle LUNs anzeigen und “Serial#” und “Maps” unbedingt merken
5. Auf der Ziel NetApp werden Volumes mit gleicher oder größerer Größe anlegt
6. Zielvolume mit Befehl “vol restrict <volname>” in Restrictet Modus schalten
7. Auf Quell NetApp prüfen, ob SnapMirror aktiv ist “options snapmirror” und wenn nicht mit dem Befehl “snapmirror on” einschalten
8. Zugriff von der Ziel NetApp auf die Quell NetApp mit dem Befehl “options snapmirror.access host"=<Ziel NetApp>” konfigurieren
9. Übertragung auf Ziel NetApp mit dem Befehl “snapmirror initialize –S <Quell NetApp>:<Quellvolume> <Zielvomume>” für alle zu migrierenden Volumes starten
10. Wenn die erste Synchronisation fertig ist, können wir alle VMs die auf dem CSV Volume liegen herunter fahren und dann auch die Hyper-V Hosts, die auf die Quell NetApp zugreifen, herunterfahren
11. Auf der Quell NetApp die iSCSI-LUNs mit dem Befehl “lun offline <kompletter LUN Pfad>” offline schalten
12. Auf Ziel NetApp den Befehl “snapmirror update –S <Quell NetApp:<Quellvolume> <Zielvolume>” für alle zu übertragenden Volumes ausführen, um die Änderungen zu synchronisieren
13. Auf Ziel NetApp Befehl “snapmirror quiesce <Ziel Volume>” für alle betroffenen Volumes ausführen, um aktuellen Transfer zu vollenden und neue zu unterbinden
14. Auf Ziel NetApp Befehl “snapmirror break <Ziel Volume>” für alle betroffenen Volumes ausführen, um SnapMirror aufzubrechen und die Ziele benutzbar zu machen
15. Auf der Ziel NetApp werden Seriennummer der alten LUNs auf neue LUNs mit dem Befehl “lun serial <Lun-Pfad> <Serial>” gesetzt
16. jede dieser LUNs mit dem Befehl “lun online <Lun-Pfad>” online schalten
17. alle LUN-IDs mit dem Befehl “lun map <LUN-Pfad> <Initiator-Group> <Lun-ID>” setzen
18. alle Hyper-V Cluster Host starten und prüfen, ob die LUNs in der Datenträgerverwaltung zur Verfügung stehen
19. Alle Clusterdienst starten und alle VMs ebenfalls hochfahren
20. Quell NetApp auf allen Hyper-V Hosts aus der iSCSI Konfiguraton entfernen

Nach diesem 20 Schritteplan war bei uns das gewünschte Ergebnis erreicht: alle Hyper-V Cluster Hosts sind mit der FSA6040 verbunden und die FAS2050 kann abgebaut werden. Viel Erfolg beim Nachbauen.

P.S.: Meinen Dank möchte ich Udo Lorenz von der Firma NetApp @udolorenz aussprechen, da er mich bei der Migration stark unterstützt hat. Für mich hätte es wesentlich mehr Aufwand bedeutet diese ganzen Befehle in der Doku zu finden.

Bevor wir aber mit den “Best Practice” loslegen, möchte ich erst mal, anhand der Grafik rechts, unseren Testaufbau verdeutlichen. In der Mitte sieht man unsere zwei HP Proliant DL160 G6 Server Systeme, aus denen später der Hyper-V Cluster gebaut wird. Ganz unten haben wir einen SAN Storage, eine NetApp FSA2050, die wir per iSCSI redundant anbinden. Jeder der blauen Balken stellt dabei ein Netzwerk dar. Diesen sind von oben nach unten:

• Management – Über dieses Netz wird der Cluster verwaltet (Remote Administration, Updates, SystemCenter Agenten, Host und VM Backup)
• VM – Netzwerk über das die virtuellen Maschinen mit der “Außenwelt” kommunizieren
• CSV – Heartbeat und (Privates) Cluster Netzwerk über das der Cluster Informationen austauscht und auch der „Redirect Access“ der Cluster Shared Volumes abgewickelt wird
• Livemigration – Netz über das der Speicher einer VM, die auf einem anderen Host migriert, übermittelt wird
• iSCSI – SAN Netzwerk für die Kommunikation der Hyper-V Hosts mit dem Storage (Redundant per MPIO)
• iSCSI2 – SAN Netzwerk für die Kommunikation der Hyper-V Server mit dem Storage (Redundant per MPIO)

In der Grafik sieht man auch die Beispiel IPv4 Konfiguration. Es sind insgesamt fünf private Netze involviert. Das Management und VM Netzwerk sind in dem allgemeinen Kommunikationsnetz, in dem sich auch andere Server und Clients befinden (hier 192.168.210.0/23). Es kann geroutet werden und mit dem Internet über einen Firewall kommunizieren. Allen anderen vier Netze zwischen den Hosts und dem Storage ist gemeinsam, dass sie nicht geroutet werden. Die Aufgabe dieser Netze habe ich oben schon angerissen. Im Verlauf des Artikels werden wir nochmal bei der Bindung und Priorisierung der Adapter etwas genauer darauf eingehen.

Anmerkung: Auch wenn einem sechs Netzwerkadapter viel vorkommen, so ist diese Konfiguration, zumindest wenn man iSCSI einsetzt, noch nicht optimal. Im Idealfall benötigt man noch ein bis zwei Adapter mehr. Wieso? Zum einen sollte das Private Cluster Netzwerk, bei uns kurz CSV genannt, in zwei Netze aufgeteilt werden: das Heartbeat Netz und das eigentliche Cluster Shared Volume Netzwerk. Dann kann man die Cluster Kommunikation (der Cluster Heardbeat) und den Redirected Access von einander trennen (Empfehlung Microsoft). Genauso wird man auch das VM Netz oft mit mehr als einem Adapter betreiben und dazu auf Teaming zurückgreifen (Einen guten Artikel hierzu findet man bei Michel Lüscher auf dem Blog: How-To: Netzwerkkarten Teaming mit Hyper-V). Unsere gezeigte Konfiguration ist allerdings ein guter Kompromiss und ist auch so in unserem Lab aufgebaut.

Netz Überlegungen

Nun aber zur eigentlichen Konfiguration. Nach der Installation des Betriebssystems Windows Server 2008 R2 SP1, wurden alle sechs Netzwerkkarten erkannt. Wichtig ist, dass man nun die neusten Netzwerkkartentreiber installiert.

Wenn man jetzt die Netzwerkkonfiguration öffnet, geht man aus Gründen der Übersicht zuerst hin und deaktiviert alle Netzwerkkarten, bis auf das Management Interface. Als Nächstes macht man sich Gedanken, wie die Netzwerk Adapter am besten verteilt werden, damit auch die Redundanz richtig gewährleistet ist. Dabei soll verhindert werden, dass z.B. iSCSI und iSCSI2 auf dem gleichen Netzwerk Adapter konfiguriert sind. Wenn man unterschiedliche Netzwerkkarten in dem Hyper-V Host verbaut hat, dann spielen bei der Verteilung auch die Fähigkeiten der Adapter eine Rolle. Was heißt das in unserem Fall? Die beiden HP Proliant DL160 G6 haben jeweils eine onboard Intel Dualport und eine zusätzliche Intel Quadport Netzwerkkarte I340-T4 verbaut. Die I340-T4 besitzt verschiedene Optimierungen für iSCSI und Virtualisierung (z.B. TCP Segmentation and Checksum Offload, RSS und VMDq hier sind die Specs). Nach Abwägen der Optionen haben wir die Funktionen der Netzwerke wie folgt verteilt:

onboard Dualport Adapter: Management und iSCSI

Quadport Adapter: VM, Livemigration, CSV und iSCSI2

Danach sieht das Ganze wie im Screenshot rechts aus.

Jetzt vergeben wir für alle Netzwerk Ports, bis auf das VM Netz, eine feste IP Adresse aus den jeweiligen Netzen. Wir haben uns dabei angewöhnt, dass das letzte Oktett der IP-Adressen der Hyper-V Hosts in allen Netzen gleich ist. Ein Beispiel: Wenn, wie in unserer Konfiguration, HyperV6 in unserem Management-Netz die IP-Adresse 192.168.210.26 hat, dann bekommt er auch in allen anderen Netzen die Endadresse “x.x.x.26”. Unten sehen Sie exemplarisch die IP-Konfiguration des Livemigration Netzes.

Bei der IP-Konfiguration wird, außer beim Management Netzerk, nirgendswo ein Gateway oder ein DNS Server eingetragen. Zusätzlich wird bei diesen privaten Netzwerken unter DNS die Checkbox “Adresse dieser Verbindung im DNS registrieren” entfernt. Das ist wichtig, damit sich der Hyper-V Host nicht unter den IP-Adressen der Netze Livemigraton, CSV, iSCSI und iSCSI2 beim DNS registriert. Weiterhin sollte man unter dem Reiter WINS die Option “NetBIOS über TCP/IP deaktivieren” aktivieren (siehe Screenshot oben).

Anmerkung: Weitere Optimierungen, welche früher für einen Cluster vorgenommen wurden, sollten bei einem Hyper-V Cluster nicht durchgeführt werden (Siehe Michels Artikel: Error “Cluster Shared Volume is no longer available” mit Hyper-V Failover Cluster)

Nochmals, all das geschriebenen gilt nicht für das Management Netzwerk. Dieses wird wie gehabt mit Gateway und DNS Server konfiguriert. Auch wird die DNS und NetBIOS Konfiguration mit den Standardwerten belassen.

Hyper-V Rolle installieren

Bevor wird die Hyper-V Rolle installieren, achten wir darauf, dass auf dem VM Netzwerkinterface DHCP eingeschaltet ist. Dann starten wir die Hyper-V Rolleninstallation und wählen im Dialog “Virtuelle Netzwerke erstellen”, das VM Netz aus (siehe Screenshot).

Nach der Installation des Hypervisors gehen wir in die Konfiguration der Hyper-V Manager und wählen auf der rechten Seite den Punkt “Manager für virtuelle Netzwerke” aus. In dem daraufhin erscheinenden Dialog wählen wir das virtuelle Netzwerk “VM – virtuelles Netzwerk” aus. Jetzt entfernen wir die Checkbox “Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen” (siehe Screenshot).

Hyper-V Cluster konfigurieren

Um die Netzwerkkonfiguration für den Cluster fortzusetzen, müssen wir nun einen Cluster einrichten. Nachdem das erfolgt ist, finden wir im Failovercluster-Manager, unter dem Punkt “Netzwerke”, die Netze “Clusternetzwerk 1” bis “Clusternetzwerk 5” (Screenshot unten links). Diese werden automatisch anhand der Subnetze angelegt. In deren Detail Ansicht findet man dann auch die Netzwerk Adapter der jeweiligen Cluster Nodes / Hyper-V Hosts. Da die Bezeichnung “Clusternetzwerk x” nicht wirklich sprechend ist, ändern wir die Netze in unsere Netzbezeichnungen um (Screenshot unten rechts).

Bis jetzt haben wir erreicht, dass unsere Netzwerke für uns einen logischen Sinn ergeben. Jetzt müssen wir auch dem Cluster beibringen, welcher Adapter er für welche Funktion benutzen soll. Das geschieht an mehreren Stellen in der Konfiguration, auf die wir jetzt für jedes der Netze eingehen.

CSV Netz

Über diesen Adapter laufen zwei Funktionen: die Clusterkommunikation (oder Cluster Heartbeat) und die Cluster Shared Volumes. Wie oben schön erwähnt, würden wir diese Funktionen auf getrennte Netzwerkkarten legen, wenn weitere zur Verfügung ständen.

Welche Netze der Cluster Heartbeat benutzen darf, wird im Failovercluster-Manager eingestellt. Hier wählt man unter dem Punkt Netzwerke das Netz aus, welches für die Clusterkommunikation benutzt werden soll. Als nächstes rechtsklickt man und wählt Eigenschaften aus (Screenshot rechts). Im erscheinenden Dialog clickt man den Punkt “Netzwerkkommunikation für Cluster in diesem Netzwerk zulassen” an. Im Screenshot sieht man links die Bindungen der Netzwerkkarte und rechts die Einstellungen des Clusters für diese Netzwerkschnittstelle.

Wie zuvor bereits erwähnt und bei Michel gebloggt, dürfen hier die Protokolle „Client für Microsoft Netzwerke“ und „Datei für Druckerfreigabe“ nicht deaktiviert werden. Dies wird für den Redirected Access vom CSV benötigt.

Die Einstellung der Funktion Cluster Shared Volumes und damit des Redirected Access, definiert man in der PowerShell. Jede Netzwerkschnittstelle im Cluster hat eine Metrik zugeordnet. Diese Metrik bestimmt der Cluster anhand der Netzwerkeigenschaften, wie z.B. die Geschwindigkeit des Interfaces, das Vorhandensein eines Gateways und die DNS Einträge. Der Cluster nutzt nun für die CSV Kommunikation die Karte mit der tiefsten Metrik. Wenn Sie selber bestimmen wollen, welche Karte da ist, so müssen sie die automatisch vergebenen Metriken modifizieren. Und eben hierzu benötigt man die PowerShell.

Zuerst laden wir in der PowerShell die FailoverCluster CmdLets:

Import-Module FailoverClusters

Dann lassen wir uns die Metrik der einzelnen Schnittstellen mit dem Befehl:

Get-ClusterNetwork | ft Name, Metric, AutoMetric

anzeigen. Das Ergebnis sieht so aus:

Momentan wird der CSV Adapter automatisch für die Clusterkommunikation benutzt. Wir möchten aber, dass die Auswahl nicht zufällig passiert, weswegen wir diese fest mit dem Wert 900 zuordnen. Weiterhin möchten wir, dass die Livemigration auf 1100 gesetzt wird. Dazu benutzen wir folgende PowerShell Befehle:

(Get-ClusterNetwork “CSV”).Metric=900
(Get-ClusterNetwork “Livemigration”).Metric=1100

Danach lassen wir uns wieder die Metriken der einzelnen Netzwerke anzeigen:

Damit haben wir die Interfaces nach unseren Vorstellungen “geordnet”.

Management Netz

Das Management Netzwerk ist Mitglied im normalen Clientnetzwerk und für die Kommunikation des Clusters mit der “Außenwelt” zuständig. Über dieses kann z.B. per Remote Desktop auf die Konsole zugegriffen werden und die System Center Agenten kommunizieren mit ihren Management Servern. Wie bereits weiter oben beschrieben, hat dieses Netz in der Regel ein Gateway und DNS konfiguriert. Die Konfiguration der Netzwerkkarte sieht man im Screenshot unten links und die der Clusternetzwerks im Screenshot unten rechts.

Im rechten Screenshot sehen wir, dass der Cluster auch eine IPv6 Netz für die Kommunikation benutzt. Das ist vollkommen in Ordnung und bei unserer Umgebung sogar gewünscht! (siehe Kapitel IPv6). Zusätzlich wird dieses Netz als Backup für die Cluster Heartbeat Kommunikation genutzt. Deshalb ist hier, wie beim CSV und Livemigration Netz, der Radiobutton ”Netzwerkkommunikation für Cluster in diesem Netzwerk zulassen” ausgewählt.

iSCSI und iSCSI2 Netze

Die Konfiguration ist für beide Adapter im Wesentlichen gleich, weswegen wir nur eine besprechen. Über dieses Netzwerk wird das SAN System, auf dem unsere VMs liegen, angesprochen. Wenn, wie in unserem Fall, für die Kommunikation mehrere Netzwerke (iSCSI und iSCSI2) benutzt werden, dann sollte das Feature MPIO korrekt konfiguriert sein. Die eigentliche Netzwerkkonfiguration der iSCSI Interface ist relativ simpel. Auf der Netzwerkschnittstelle wird nur IP gebunden (Screenshot unten links) und in der Clusternetzwerkkonfiguration wird die Netzwerkkonfiguration für den Cluster unterbunden (Screenshot unten rechts).

Livemigration Netz

Das Livemigration Netzwerk hat die Aufgabe, bei dem Vorgang einer Livemigration, den Hauptspeicher einer VM von Host A (auf dem die VM noch läuft) auf Host B (auf den die VM migriert wird) zu übertragen. Damit das funktioniert, ist ein möglichst schnelles Netz notwendig (mindestens 1Gbit). In unserer Konfiguration dient der Livemigration Adapter auch noch als Backup für die Clusterkommunikation (Cluster Heartbeat). Deswegen schalten wir in der Cluster Netzwerkkonfiguration auch die Clusterkommunikation ein (siehe Screenshot rechts).

Das eigentliche Konfigurieren, welches Netzwerk für die Livemigration benutzt wird, geschieht aber auf der VM. Dazu rechtsklickt man auf eine VM und wählt “Eigenschaften” aus (Screenshot unten links). Dann wechselt man in den Reiter “Netzwerk für Livemigration” und wählt die Netze “Livemigration” und “Management” aus (Screenshot rechts). Das Netz Management soll dabei als Backup dienen, wenn das Netz Livemigration nicht zur Verfügung steht. Wenn Livemigration unterhalb von Management steht, dann müssen wir die Reihenfolge der Netze noch durch “Drücken” des Buttons “Nach Oben” verändern, da sonst die Livemigration über das Management Netz erfolgen würde.

Wie bereits beim Heartbeat beschrieben, dürfen auch hier die Protokolle „Client für Microsoft Netzwerke“ und „Datei für Druckerfreigabe“ nicht deaktiviert werden.

Wichtig: Die Konfiguration auf der VM lässt den Anschein erwecken, dass man bei jeder VM das Netz für die Livemigration auswählen kann/muss. Das ist nicht so. Was man auf einer VM konfiguriert gilt auch für alle anderen.

Reihenfolge der Netzwerkkarten

Zuletzt wollen wir noch sicherstellen, dass das System zuerst über das Management Netzwerk versucht, mit anderen Systemen zu kommunizieren (z.B: Active Directory oder DNS Auflösung). Deswegen müssen wir gegebenenfalls die Reihenfolge der Netzwerkschnittstellen umsetzen. Dazu öffnen wir das “Netzwerk- und Freigabecenter” und klicken auf “Adaptereinstellungen ändern”. Im Fenster “Netzwerkverbindungen” drücken wir die die ALT-Taste und können in dem erscheinenden Menü (Screenshot unten links) über “Erweitert” den Dialog ”Erweiterte Einstellungen” aufrufen. Hier sorgen wir durch umordnen der Netzwerkschnittstellen dafür, dass das Management als Erstes in der Auflistung erscheint (Screenshot unten rechts).

IPv6

Noch ein paar Wort zu IPv6. Microsoft empfielt mittlerweile IPv6 auf den Schnittstellen eingeschaltet zu lassen. Es ist sogar wichtig zu wissen, dass Microsoft inzwischen nur noch mit aktiviertem IPv6 testet. Warum haben wir es dann in dieser Beispielkonfiguration mit einer Ausnahme ausgeschaltet? Ein einfacher Grund: Wir wollten die Konfiguration nicht weiter verkomplizieren. In unserer Umgebung haben wir wegen DirectAccess einen IPv6 DHCP Server laufen (siehe auch How to: Einrichtung von DirectAccess). Dieser versorgt alle Adapter, wenn IPv6 eingeschaltet ist, mit IPv6 Adressen. Damit wären alle Adapter über IPv6 in einem Netz und könnten miteinander kommunizieren. Um das zu verhindern, müssten wir VLANs einfügen, was dann die Komplexität dieses Artikels stark erhöhen würde. Aber bitte nicht falsch verstehen, VLANs machen im Hyper-V Cluster durchaus Sinn und wir empfehlen Sie auch (zumindest bei etwas größeren Umgebungen).

Schlussbemerkung

Damit ist unser Netzwerk für das Hyper-V Cluster korrekt konfiguriert. Da diese Konfiguration den Anspruch erhebt sich innerhalb der Microsoft Empfehlungen und Supportrichtlinien zu bewegen, habe ich gerne Michel Lüschers Angebot den Artikel zu prüfen wahrgenommen. Danke Michel für die Zeit und deine sehr hilfereichen Kommentare. Wer Michel nicht kennt, er ist für Microsoft in der Schweiz tätig und betreibt den sehr guten Blog Server-Talk.eu (findet ihr übrigens auch in unserer Blogroll).

Links

Wer noch mehr zu dem Thema erfahren möchte, dem habe ich noch ein paar Links zusammengetragen:

TechNet Modify Network Settings for a Failover Cluster

Alessandro Cardoso : Hyper-V : Network Design, Configuration and Prioritization : Guidance

TechNet Configuring Network Prioritization on a Failover Cluster

Michel Lüscher: How-To: Verwaltung eines Cluster Shared Volume (CSV)

Hier eine kleine Aufzählung, was man in dem Videocast sieht:

1. Netzwerkkonfig wird bei der zu exportierenden VM auf “nicht konfiguriert” gestellt
2. Export der VM und anschliessendes kopieren dieser auf den Cluster
3. Import der VM mit dem Hyper-V Manager und Konfigurieren des Netzwerks
4. Hochverfügbar machen der VM mit dem Failovercluster-Manager
5. Test der Hochverfügbarkeit mittels einer Livemigration

Mit der HP LeftHand P4000 Virtual SAN Appliance Software hat man die Möglichkeit, sich ohne den Kauf einer speziellen SAN-Hardware ein Cluster-fähiges SAN aufzubauen und z.B. für ein Hyper-V-Cluster zu nutzen. Das Prinzip ist recht simpel: Man installiert auf mindestens einem Hyper-V oder ESX-zertifiziertem HP-Server (ProLiant oder c-Class-Blade) die SAN-Software. Die Software richtet eine virtuelle Maschine ein, in der die Software läuft. Dieser virtuellen Maschine wird Festplatten-Speicher zugeordnet, entweder über mehrere VHD-Dateien oder mit einer Pass-Through-Disk. Dieser Festplattenplatz kann dann im Netzwerk freigegeben werden und andere Server können auf den Speicherplatz per iSCSI zugreifen. Um eine zusätzliche Redundanz zu schaffen, kann man mehrere VSA-Server auf verschiedenen Hosts installieren und diese in einer Management-Gruppe zusammenfassen. Je nach Konfiguration kann man den Speicher im Netzwerk als Netzwerk-RAID10 definieren, d.h. bei einem Ausfall oder bei einem Neustart eines Hosts sind die Daten trotzdem erreichbar. Zusätzlich zu dem Ausfall-Schutz kommt noch ein Geschwindigkeitsvorteil hinzu, wenn beide (bzw. alle Server) im Netz erreichbar sind, ähnlich dem Verhalten eines Festplatten-RAID1/RAID10.

Die Installation

Die Installation der Software gestaltet sich als recht einfach. Auf dem Hyper-V Host wird das Setup aufgerufen, welches mit einem Wizard durch die Installation führt. Hier eine Reihe von Screenshots, die die Installation der einer VSA-Maschine zeigen:

Nach den Lizenzbedingungen und dem Entpacken der Setup-Dateien startet die eigentliche Installation

An der folgenden Stelle sollte man darauf achten, dass für die Maschine kein zusätzlicher Ordner angelegt wird

Man kann nun wählen, ob man VHD-Dateien als Speicherplatz nimmt oder Pass-Through-Disks. Letztere bieten eine höhere Performance. Zu Testzwecken nehme ich eine VHD-Datei mit 5 GB Größe.

Nach dem Bestätigen von Next wird die Maschine angelegt

Man kann sich den Erstellungs-Prozess auch im Hyper-V-Manager anschauen

Nach wenigen Minuten ist die Installation beendet

Im Hyper-V-Manager erkannt man nun, dass die virtuelle Maschine korrekt benannt wurde und wie gewünscht nicht eingeschaltet wurde

Der Start der Maschine sieht wie folgt aus

Die Eigenschaften der virtuellen Maschine sehen wie folgt aus

Die einzige Änderung hier sollte bei “Automatische Startaktion” gemacht werden und auf “Virtuelle Maschine immer automatisch einschalten” gestellt werden, damit die virtuelle Maschine auch wirklich immer eingeschaltet wird. Später bei der Konfiguration kann noch eine oder mehrere Netzwerkkarten hinzugefügt werden, je nach Bedarf und Netzwerkaufbau. Wir man erkennt, wird bei der (Linux-)Maschine ein “richtiger” Netzwerk-Adapter genutzt. Dies ist möglich durch die installierten und aktivierten Integrationskomponenten, ebenso ist ein Herunterfahren “von außen” möglich.

Die Verwaltung mit der Centralized Management Console

Nachdem die Maschine installiert ist, kann man an der Konsole nur noch wenig einstellen. Den Großteil der Konfiguration stellt man in der Management-Konsole ein.

Als erstes wird das System über den Menüpunkt “Find” hinzugefügt

Die verfügbaren Systeme können (und müssen) in Management-Gruppen sortiert werden. Als erstes muss solch eine Gruppe erstellt werden

Hier eine kurze Zusammenfassung der Screenshot-Reihe:

Es wird eine neue Management-Gruppe erstellt. In diese Gruppe wird das System “VSA1” automatisch aufgenommen. Die Gruppe wird mit einem Benutzernamen und einem Kennwort versehen, weiterhin wird ein Zeitserver sowie die DNS-Namen und –Server definiert. Als nächstes wird ein Mailserver und ein ein/mehrere Empfänger definiert, die wahlweise Fehlermeldungen, Warnungen und/oder Informationen zu dem System bekommen. Es wird gefragt ob es ein Standard- oder ein Multi-Site-Cluster werden soll, weiterhin wird der Name und die gemeinsame IP des Clusters abgefragt. Man kann im Zuge der Erstellung auch direkt ein Volume erstellen, diesen Schritt überspringen wir allerdings durch das Setzen der Option “Skip Volume Creation”. Am Ende bekommt man eine Zusammenfassung der Einstellungen und die Management-Gruppe mitsamt Cluster ist eingerichtet.

Hinzufügen eines weiteren Systems

Als nächsten Schritt habe ich eine weitere Maschine mit der VSA-Software installiert und in der Management Konsole hinzugefügt. Sobald die Software das System findet kann man den Server einer bestehenden Management-Gruppe hinzufügen.

Nun kann das System einem Cluster hinzugefügt werden, alternativ könnte ein weiteres Cluster erzeugt werden

Erstellung eines Volumes zur Nutzung auf einem anderen Server

Als nächstes legen wir unter “Servers” das System an, was auf das Volume zugreifen darf.

In dem folgenden Fenster wird der Name und der Initiator Node Name des Systems benötigt, alternativ kann die Verbindung auch per CHAP abgesichert werden.

Danach beginnen wir mit der Erstellung des Volume

Im nachfolgenden Screenshot sieht man, das man die Wahl zwischen einem Network RAID-1 oder einem Network RAID-10 hat. Ich wähle Network RAID-10.

Man erkennt nach der Erstellung des Volumes, dass die angegebene Größe des Volumes doppelt gerechnet wird.

Die Anbindung an den Server ist recht einfach, im iSCSI-Initiator wird die während des Setup angegebene Cluster-IP angegeben und das Volume wird verbunden

Wenn man nun eine der beiden VSA-Server herunterfährt, ist der Server mit dem Laufwerk S: trotzdem in der Lage, auf die Daten zuzugreifen. Hier zwei Screenshots der beiden Server, dem iSCSI-Initiator, dem offenen Laufwerk und der Management-Konsole:

Fazit

Die Software eignet sich super für die Erstellung eines SAN, vor allem wenn man die Hardware schon zur Verfügung hat und auf Grund von Infrastruktur-Änderungen diese zum Einsatz kommen kann. Bei dem Aufbau des SANs zählt natürlich die Geschwindigkeit und die Ausstattung der Hosts, auf denen die Daten liegen sollen, man kann hier nicht erwarten das die Software zaubert. Die Installation und Einrichtung der einzelnen Server funktioniert einfach und schnell, für einen sauberen und fehlerfreien Betrieb später sollte man sich allerdings die Software einige Zeit anschauen und in die Thematik einlesen, da man sonst Gefahr läuft unbewusst Fehler zu machen und mit bestimmten Konfigurationen in Fehler hineinläuft. Aber wo ist das nicht so… :)

-TurnOff Mit diesem Parameter startet das Script die VM nach dem Export nicht wieder.

-StartDelay <Sekunden>

Der Start der VM wird um <Sekunden> verzögert.

Der StartDelay Befehl ist sehr hilfreich, wenn man große VMs auf externe USB-Festplatten exportiert oder nach

dem Export kopiert. Hierbei scheint die Parent Partition den Host Hauptspeicher zu nutzen, um den Zugriff auf die meist langsame USB-Festplatte zu cachen. Je nachdem wie groß die VM und wie langsam die externe USB-Platte ist, kann das schon einige GB des Hauptspeichers in der Parent Partition “fressen”. Es scheint nun, dass für Windows das Kopieren abgeschlossen ist, wenn alle Daten im Speicher liegen. Das Betriebsystem meldet “Kopiervorgang fertig” , das Script startet die VM, das System möchte den RAM für die VM reservieren und erhält ihn nicht, da nicht genügend Speicher frei ist.

Ihr findet das upgedatete Script und den aktualisierten Post mit einigen Beispielen und einer Anleitung, wie man das Backup automatisierten kann hier: Hyper-V Sicherung mittels Powershell Script.

P.S.: Wenn Ihr unser Script schätzt, dann belohnt uns doch indem ihr 5 Minuten für eine Pinpoint Bewertung von unserem Blog investiert: https://pinpoint.microsoft.com/de-DE/Review.aspx?gId=1&Id=4294998082

Die Installation gestaltet sich als sehr einfach. Nach dem Download des ca. 230 MB großen Pakets starten wir die Installation und warten, bis diese fertiggestellt wurde. Die Installation bedingt keinen Neustart, direkt nach der Installation kann mit dem Hinzufügen der einzelnen Tools in der “Systemsteuerung” unter “Programme und Funktionen” => “Windows-Funktionen aktivieren oder deaktivieren” begonnen werden. In meinem Fall wähle ich nur die “Hyper-V-Tools” aus, wenn man noch weitere Tools benötigt kann man diese natürlich auch anwählen. Nach der Bestätigung mit “OK” werden die Tools aktiviert und stehen nach kurzer Zeit in der “Systemsteuerung” und “Verwaltung” zur Verfügung. Hier noch eine kleine Screenshot-Strecke der Installation zur besseren Darstellung :)

Nach der Installation hat man das Problem, dass man nicht “mal eben” eine Verbindung zu dem Hyper-V Server aufbauen kann. Es erscheint die folgende Fehlermeldung:

Das Problem lässt sich lösen, indem man auf den Systemen bestimmte Einstellungen vornimmt. Die Einstellungen könnten alle per Hand gemacht werden, einfacher ist allerdings die Benutzung des “Hyper-V Remote Management Configuration Utility” von John Howard. Mit Hilfe dieses Scripts ist man in der Lage, innerhalb weniger Minuten erfolgreich eine Verbindung aufbauen zu können. Das Script muss sowohl auf den Server als auch auf den Client gedownloaded werden, da auf beiden Systemen entsprechende Befehle ausgeführt werden müssen. Hier meine Vorgehensweise, die zum Erfolg geführt hat:

Auf dem Server und auf dem Client wird ein neuer Benutzer mit dem gleichen Kennwort angelegt. In meinem Fall habe ich auf beiden Systemen einen Benutzer JK angelegt. Auf dem Hyper-V Server funktioniert dies mit dem Serverkonfigurations-Fenster, auf dem Client kann man den Benutzer wie gewohnt über die “Computerverwaltung” anlegen. Die Vorgehensweise in Bildern:

Nach der Benutzer-Erstellung habe in den Benutzer “JK” auf dem Client in die Gruppe der lokalen Administratoren aufgenommen. Als nächstes habe ich die Remoteverwaltung auf dem Hyper-V Server konfiguriert:

Als nächstes gibt man dem erstellten Benutzer Zugriff. Dazu gibt man auf dem Server in einer administrativen Konsole den folgenden Befehl ein

cscript hvremote.wsf /add:jk

Nun sollte der Server neugestartet werden! In der Zeit des Reboots geben wir auf dem Client den folgenden Befehl ein

cscript hvremote.wsf /anondcom:grant

Nach der Eingabe melden wir uns von dem Windows 7 ab (davon ausgehend, das man noch als “Administrator” oder jemand anders, aber nicht als “jk” angemeldet ist). Wir melden uns nun als “jk” (bzw. mit dem Konto das vorher angelegt wurde) an. Dies ist wichtig, da die Verbindung sonst NICHT funktioniert, wie ich feststellen musste!

Nach der Anmeldung geben wir am Client in einer administrativen Konsole den folgenden Befehl ein

cmdkey /add:hyper-v-servername /user:hyper-v-servername\accountname /pass

Nun wird das Kennwort abgefragt (nicht sichtbar) und gespeichert. “hyper-v-servername” ist der Name des Servers, accountname ist in meinem Fall “jk”. Als letzten Schritt auf dem Client legen wir noch die Firewall-Ausnahmen fest

cscript hvremote.wsf /mmc:enable

Hier das ganze wieder in Screenshots:

Nachdem man diese Eingaben gemacht hat, kann man auf beiden Systemen die Verbindung testen. Dazu ruft man den folgenden Befehl auf

cscript hvremote.wsf /show /target:NameDesAnderenComputers

Auf dem Client trägt man hinten den Namen des Hyper-V Servers ein, auf dem Server den Namen des Windows 7. Die Ausgaben sehen auf dem Server wie folgt aus:

Auf dem Client sieht ein erfolgreicher Aufruf wie folgt aus:

Anmerkung zu dem Ping-Test: Auf dem Windows 7 habe ich in der Firewall ICMP-Traffic erlaubt, dadurch ist es dem Hyper-V Server möglich, den Client anzupingen. Auf dem Hyper-V Server läuft die Windows-Firewall, deswegen ist hier ein Ping nicht möglich. Ein weiterer, sehr wichtiger Punkt: Die Namensauflösung muss funktionieren. Wenn man keine Möglichkeit hat diese Einträge auf dem DNS-Server zu setzen (z.B. weil es ein 0815-DLS-Router ist) kann man den Weg mit der “Hosts”-Datei wählen, dies muss dann aber unbedingt dokumentiert werden, denn wenn sich die IP des Server oder des Clients ändert funktioniert das Management nicht mehr!!!

Die Einrichtung ist an dieser Stelle beendet, ich bin nun in der Lage mit meinem Windows 7-Client den Hyper-V Server zu administrieren. Hier ein paar Screenshots des Managers:

Aber seht selbst: Ich gebe in dem Videocast einen kleinen Überblick über die Funktion. Viel Spaß beim Anschauen.

Mich hat diese Frage auch sehr beschäftigt und deswegen findet Ihr hier meine Empfehlungen.

Das folgende Bild zeigt eine Bilderbuch Netzwerkkonfiguration einer Hyper-V Cluster Konfiguration. In der Mitte findet man, stellvertretend für alle Cluster Knoten, zwei Hyper-V

Server. Diese sind in der unteren Bildhälfte durch ein Livemigrations Netz, ein CSV-Netz und ein iSCSI-Netz verbunden. Alle diese Netze haben gemeinsam, dass sie nicht geroutet werden und in Ihnen nur die Clusterknoten vertreten sind. Eine Ausnahme bildet gegebenenfalls  das iSCSI Netzwerk. In diesem können weitere Systeme, die direkt auf den Storage zugreifen (im Bild stellvertretend durch den SCVMM dargestellt, welcher seine Library auf dem Storage liegen hat), vorhanden sein. Oberhalb der Cluster Knoten sind das Management-Netz und das VM-Netz eingezeichnet. Diese Netze werden gegebenenfalls geroutet. Was bedeuten diese Netze nun im Einzelnen?

Management-Netzwerk

Über das Management-Netzwerk wird mit den Hyper-V Hosts kommuniziert. Hierzu gehört unteranderem Dateizugriff, WMI-Zugriffe, das Backup und Kommunikation der Systemcenter Agenten. Dieses Netz hat deshalb sowohl IP wie auch den “Client für Microsoft Netzwerk” und auch die “Datei und Druckfreigabe” gebunden.

CSV- oder Heartbeat-Netzwerk

Über dieses Netz stellt der Cluster einerseits fest, ob es den anderen Cluster Knoten gut geht (Heartbeat) und andererseits wird hierrüber bei Ausfall einer Storageanbindung eines Host der Traffic zum Storage über einen anderen Host umgeleitet. Ebenso wird dieses Netz benutzt, wenn z.B. beim Backup eines CSV Volumes über den Koordinator-Node exclusive auf den Storage zugegriffen wird. Dieses Netz muss deshalb sowohl  IP, wie auch den “Client für Microsoft Netzwerk” und auch die “Datei und Druckfreigabe”  gebunden haben.

VM-Netzwerk

Über das VM-Netzwerk kommunizieren die virtuellen Maschinen mit ihrem “normalen” Netzwerk. Im Hyper-V sollten diese Karten nichts gebunden haben, außer das ”Protokoll für Microsoft virtuelle Netzwerk-Switch”.

Livemigrations-Netzwerk

Über dieses Netz wird bei der Livemigration der Speicher der VM von einem Cluster Knoten auf den anderen übertragen. Da die VM weiterläuft und dadurch noch während der ersten Übertragung des Speichers schon wieder Veränderungen an dem Speicher vorkommen, sollte dieses Netz sehr performant angebunden sein. In der Beispielkonfiguration ist sowohl IP wie auch die “Client für Microsoft Netzwerk” und auch die “Datei und Druckfreigabe” gebunden. Die letzten beiden sind aus gründen der Redundanz für das CSV Netz vorhanden und können auch wegfallen.

iSCSI-Netzwerk

Das letzte Netzwerk ist die iSCSI Anbindung. Sie dient als Anbindung der Cluster Knoten an ein vorhandenes iSCSI Storage System. Hier ist nur die IP Bindung notwendig.

In der folgenden Übersicht sehen Sie nochmal alle Einstellungen zusammengefasst.

Als Quelle für meine Erkenntnisse möchte ich einmal auf das Buch Mastering Hyper-V Deployments von Aidan Finn und den Microsoft Artikel Virtualization: Network card settings for Hyper V Cluster von Wilfried Schandenboeck hinweisen. Dann hat mich Alexander Ortha noch auf diesen Technet Artikel hingewiesen. Danke Alexander und viel Spaß beim Networken.

Ergänzung vom 14. Juni.2011: In den Kommentaren hat Michel Lüscher (Microsoft Virtualisierungsspezialist und Betreiber vom Server-Talk.eu Blog) darauf hingewiesen, dass Microsoft mittlerweile empfiehlt IPv6 eingeschaltet zu lassen. Danke Michel für den Hinweis.

Also gesagt getan. Im Folgenden beschreibe ich die Installation. Wer es lieber visuell mag, der kann sich aber auch einen Videocast anschauen, der im Wesentlichen das Gleiche darstellt. Hierzu klickt man einfach auf das Bild oben links oder hier.

Zuerst der Download: Hier stehen zwei Varianten zur Auswahl. Die Installation oder eine vorkonfigurierte VHD. Ich habe mich für die VHD entschieden (die es hier downzuloaden gibt).

Um diese zu bekommen, werden alle sechs Dateien in ein Verzeichnis herunter geladen. Dann führt man die EXE (durch doppleclick auf die Datei “SCVMM2012.EVALVHD.BETA.part01.exe”) aus, woraufhin im gleichen Verzeichnis die ca. 12GB große Datei “SCVMM2012.EVALVHD.BETA.vhd” entpackt wird.

Im nächsten Schritt erstellt man die VM für den VMM 2012. Dazu leget man ein Verzeichnis an, in dem die virtuelle Maschine liegen soll. Laut unseren Konventionen machen wir das auf Laufwerk D: im Pfad “D:\Virtuelle Maschinen”. Dort erzeuge ich ein Verzeichnis mit dem späteren Namen der VM (in meinem Fall “vscvmm2012beta") und kopiere die VHD dort hinein. Dann erstelle ich im Hyper-V Manager über den Punkt “Neu->virtuellen Computer” eine neue VM. Sie erhält den Namen “vscvmm2012beta” und wird im Pfad “D:\Virtuelle Maschinen” angelegt. Nach Zuweisung von 2048MB Arbeitsspeicher ordne ich ihr die Netzwerkkarte einer Virtuellen Switch zu. Im nächsten Schritt wird dann schließlich die vorhandene VHD über den Punkt “vorhandene virtuelle Festplatte verwenden” angefügt. Nachfolgend sieht man die Zusammenfassung des Wizards:

Jetzt kann man die VM starten und es werden das Land und Lokalität abgefragt:

Lizenzbedingungen akzeptieren:

Passwort setzen:

Nach dem Anmelden ist es wichtig, die VM in die Domaine aufzunehmen. Dies macht man im Server Manager über den Punkt “Change System Properties”:

Nach dem Reboot können wir mit der mit der eigentlichen VMM2012 Beta Installation fortsetzen. Dazu führt man das Programm “Config VMM2012” aus:

Es erscheint die obligatorische “User Account Control” Abfrage:

Es startet der “Setup Wizzard” im dem man die EULA bestätigen muss:

Eintragen von Benutzernamen und Organisationnamen:

Abfrage ob Fehler an Microsoft gemeldet werden. Wir bejahen das, da wir so Microsoft helfen können, Fehler aus dem Produkt zu nehmen:

Jetzt werden die Informationen zur Datenbank abgefragt. Wenn man die Datenbank in der gleichen VM betreiben möchte, die wir gerade konfigurieren, dann trägt man nur den Namen des System ein. Wenn man eine andere schon vorhandene SQL Server Installation nutzen möchte, dann kann man hier alle Angaben dazu vornehmen:

Der Service Account wird eingegeben. Da es sich nur um eine Beta Installation zum Testen handelt, verwende ich einen Domainen Account mit Administrator rechten:

Damit die Installation funktioniert, muss dieser Account in die Gruppe der lokalen Administratoren eingetragen werden (obwohl er das über die Domainen-Admins Gruppe bereits ist):

Jetzt wird der Pfad der Library abgefragt. Wir belassen es bei dem Standard Pfad:

Bevor die eigentliche Installationsroutine anläuft, bekommen wir eine Übersicht der Einstellung:

Nach Bestätigen läuft die Installation an:

Nach der erfolgreichen Installation wir das mit dem folgenden Bildschirm quittiert:

Wenn man jetzt zum ersten Mal die “Virtual Maschine Manager Console” startet, dann wird der Name und Port zur Kommunikation mit dem “Virtual Maschine Management Server” abgefragt. Da wir in dieser Installation den VMM Management Server in der gleichen VM betreiben wie die VMM Console ist des “localhost” und Port 8100:

Jetzt möchte die Console wissen, in welcher Rolle wir uns verbinden. Einzige momentane Auswahlmöglichkeit ist der Administrator:

Noch der Startscreen:

Und so sieht das noch leere neue Interface des VMM2012 Beta aus:

Damit ist der VMM2012 Beta installiert und es kann jetzt mit der Konfiguration begonnen werden.

Ein DPM-Server hat eine Datenbank, in die er seine Informationen speichert. Dort steht z.B., welche Partition welche Daten enthalten bzw. welche Schutzgruppe besitzt welche Partitionen. Was aber passiert, wenn der Server, auf dem das DPM installiert ist, einen Ausfall der Festplatten hat, auf dem die Datenbank liegt oder wenn aus irgendeinem Grund die Partition kaputt geht oder die Datenbank korrupt wird? Kann der DPM-Server, nachdem er wieder funktionstüchtig gemacht wurde, die vom ihm angelegten Partitionen (ähnlich wie bei einem Band) wieder einlesen und die Daten wiederherstellen? Da ich zu diesem Thema keinerlei Aussagen gefunden habe, habe ich das ganze mal bei uns in der Theorie nachgestellt. Ich habe einen DPM installiert, eine Schutzgruppe erstellt mit mehreren virtuellen Maschinen und eine Sicherung erstellt. Dann habe ich die Maschine heruntergefahren, eine der beiden RAID1-Festplatten die das Betriebssystem-Laufwerk darstellen herausgezogen und den Server wieder gestartet. Das System lief so einige Zeit, ich habe diverse Änderungen innerhalb der virtuellen Maschinen gemacht und der DPM hat noch ein paar weitere Sicherungen erstellt. Nach knapp einem Tag habe ich dann den Server wieder heruntergefahren, die bisher aktive Festplatte herausgezogen, die bis dahin inaktive Festplatte mit dem Stand von “gestern” wieder eingesteckt und den Server wieder in Betrieb genommen. Sinn dieser Aktion war, dass ich nun einen Datenbank-Stand von Montag (als Beispiel) habe, die Sicherungs-Daten auf meinem DPM-Speicher-Laufwerk allerdings von Dienstag sind.

Nach dem Start der DPM-Konsole zeigte mir die Anzeige diverse inkonsistent Replikationen an. Ich habe die Prüfung dann manuell gestartet, und nach der Prüfung wurden mir alle Replikationen wieder als “OK” angezeigt. Ich habe nun die Wiederherstellung eines virtuellen Servers gestartet, leider hat mir der Wizard nur Wiederherstellungsdaten angezeigt von vor dem Ziehen der Festplatte (sprich: Montag). Auch eine Wiederherstellung des virtuellen Servers hatte nicht zur Folge das Daten von Dienstag wieder da waren, der Server war auf dem Stand der letzten (bekannten) Sicherung => Letzte Sicherung (Montag) vor dem Ziehen der Festplatte.

Nun stellt sich die Frage, wie ich einen DPM-Server bzw. die Datenbank absichere. Microsoft empfiehlt die folgende Vorgehensweise (das Dokument ist für den DPM 2007, die Parameter und die Programme haben sich bei dem DPM 2010 nicht geändert, außer des es “replicas” heißen muss anstatt “replica”:

Backup of DPM Servers

Variante 1 (Backing Up DPM by Using a Secondary DPM Server) fällt raus, da wir nur einen DPM-Server haben. Variante 2 (Backing Up DPM Databases to Tape) fällt ebenfalls heraus, da wir kein Laufwerk in dem Server verbaut haben, sondern “nur” eine Backup2Disk-Sicherung fahren. Bleibt also nur Variante 3 (Backing Up DPM by Using Third-Party Software).

Die Lösung bringt das kleine, aber feine Programm “DPMBackup.exe” im DPM-Verzeichnis. Mit Hilfe dieses Programms ist man in der Lage, einen Export der Datenbank zu erstellen. Der Parameter ist “-db”, dann wird ein Export unter “\Program Files\Microsoft DPM\DPM\Volumes\ShadowCopy\” gespeichert. Weitere Parameter (z.B. das Umlenken des Exports in einen anderen Pfad) bekommt man angezeigt, wenn man “DPMBackup.exe /?” eingibt. Mit Hilfe der Aufgabenplanung kann man so in recht kurzen Abständen eine Sicherung der Datenbank erstellen.

Zum Thema “Wiederherstellung” gibt es ebenfalls einen eigenen Bereich im Technet, und zwar unter der folgenden Adresse:

http://technet.microsoft.com/en-us/library/bb795745.aspx

Ich habe die Wiederherstellung der Datenbank natürlich auch getestet und musste feststellen, das man den DPM komplett neu installieren muss. Selbst bei einem Restore einer Acronis oder DriveSnapshot-Sicherung kann man nicht einfach die Datenbank wiederherstellen, sondern muss das komplette Programm deinstallieren und neu installieren. Erst dann kann man die Datenbank wieder einziehen und ist in der Lage, seine anderen mit dem DPM erstellten Sicherungen wiederherzustellen.

Wie man sieht ist eine Ein-Server-Lösung nicht so sexy wie eine Zwei-Server-Lösung inkl. Replikation bzw. gegenseitiger Sicherung der Datenbanken. Da allerdings oft das Geld oder die Mittel für solch eine Lösung fehlen habe ich mit diesem Artikel hoffentlich einen kurzen Überblick gegeben, wie eine konsistente Sicherung und eine erfolgreiche Wiederherstellung der Datenbank möglich ist. Weiterhin steigt mit Anzahl der Server bzw. der Daten in einem Unternehmen in der Regel auch die Wichtigkeit, sodass man ab einem gewissen Punkt eigentlich keinerlei (weitere) Argumentation mehr für einen zweiten DPM-Server benötigt.

Laut Datenblatt hat die GreenBytes eine Quad Core CPU, 12 GB RAM, eine 32 GB große SSD für das Betriebssystem, zwei 25 GB große SSDs für den Cache und acht 500 GB große Festplatten, allesamt 2,5” groß. Zur Anbindung an das Netzwerk sind zwei 1 GbE-Adapter vorhanden sowie einen weiteren 1 GbE-Adapter für das Management. Weitere Daten stellt das Datenblatt bereit.

Nach dem Start des Geräts wird man von einem OpenSolaris begrüßt. Man kann sich zwar an der Konsole anmelden, kann dort aber nichts GreenBytes-relevantes einstellen. Administriert wird das Gerät über den “GreenBytes Storage Manager”, ein MMC-SnapIn. Das sieht dann wie folgt aus:

Die Benchmark-Tests:

Der erste Test, den ich durchgeführt habe”, war das Messen der Geschwindigkeit mit dem Programm “CrystalDiskMark”.

Hier ein Test der Geschwindigkeit auf ein 500 GB großes Volume, inkl. aktivierter Kompression und De-Duplizierung (hierzu später mehr):

Hier der gleiche Test, allerdings mit deaktivierter Kompression und De-Duplizierung:

Hier zum Vergleich die beiden lokalen 300 GB SAS 15k-Festplatten:

Was sich extrem bemerkbar macht sind die hohen Werte bei den Tests “4K” und “4k QD32”. Vergleichen kann man die Werte mit den folgenden: Hyper-V-Server.de: Ein guter Server zum Virtualisieren

Als nächstes habe ich neun virtuelle Server auf einem unserer Hyper-V-Hosts hinzugefügt und die Festplatten auf dem verbundenem iSCSI-Volume gespeichert. Da das größte Problem bei solchen externen Speicher-Systemen die Performance und die Latenz ist, wollte ich mir einen Eindruck darüber verschaffen, wie sich diese Server verhalten im Betrieb. Genaue, messbare Werte konnte ich nicht ermitteln, allerdings hat man ja ein Gefühl dafür, ob ein System nun träge ist oder ob sich das Verhalten mit einem System auf direkt angeschlossenen Festplatten vergleichen lässt.

Mit aktivierter Kompression und De-Duplizierung war das Verhalten dieser neun Maschinen schon beachtenswert, Operationen mit einer gewissen Anzahl von I/O-Vorgängen (Starten der Maschine, Herunterfahren, Suchen nach allen Dateien auf Laufwerk C…) waren zufriedenstellend, selbst bei dieser Art des Betriebs.

Einen weiteren Performance-Schub habe ich bekommen, nachdem ich die Maschinen auf einem Volume gespeichert habe, auf dem sowohl die Kompression als auch die De-Duplizierung deaktiviert war. Wie schon an den Benchmark-Werten oben sichtbar steigen die Werte je nach Art des Benchmark-Tests um fast das fünffache im Schreib-Modus.

Eine noch weiter verbesserte Performance bekommt man, wenn man pro virtuellem System ein (oder mehrere) Volume(s) erstellt und diese direkt mit der virtuellen Maschine verbindet. Hierdurch verliert man allerdings einige Vorteile, z.B. die Möglichkeit eines Exports, der Verlust wird aber weitestgehend durch die Snapshot-Möglichkeit der GB-1000 wett gemacht.

Das Hyper-V Failover-Cluster:

Als nächstes stand das Einrichten eines Failover-Clusters auf dem Plan. Aus Zeitgründen konnten wir bis zum aktuellen Zeitpunkt nur zwei Maschinen hochverfügbar machen, allerdings ergibt sich hierbei schon ein interessantes Detail:

Aktuell sind 13,7 GB genutzt, und zwar durch zwei Windows Server 2008 R2. Nur durch die Kompression und die De-Duplizierung schafft die GB-1000 eine Reduzierung des Speicherplatzes von 22,36 GB auf 13,7 GB. Wie man in dem Screenshot erkennt sind das 38,73 %. Wenn das Verhältnis so bleibt könnten auf den eigentlich nur 3,16 TB großen Festplatten insgesamt 5,16 TB an Daten gespeichert werden. Für die Virtualisierung aus Performance-Gründen nicht ganz sinnvoll, für ein NAS-System allerdings schon ein geiles Feature :)

Die Maschinen liefen sehr performant und ohne kleine Hänger/Aussetzer im Betrieb, wie es manchmal bei langsamen iSCSI-Volumes der Fall ist. Hier einige Screenshots des Clusters und eines Umzugs einer virtuellen Maschine:

Das hier vorgestellte Modell GB-1000 mit 8 x 500 GB plus SSD kostet Liste 13200 €. Vergleichbare Systeme anderer Hersteller bewegen sich teilweise in weitaus höheren Regionen, von daher ist dieses Gerät an sich schon ziemlich günstig. Trotz des geringen Preises schlägt sich die GreenBytes sehr gut und liefert sehr souveräne Werte ab. Wir hatten während der Teststellung einen durchweg positiven Eindruck von dem Gerät und können das Gerät als NAS oder SAN empfehlen.

HP DL380 G7:

• Zwei Intel Xeon E5640 CPUs (QuadCore, 2.66 GHz, 12MB L3 Cache, 80 Watt Verbrauch)
• 12 GB DDR3 RAM, pro CPU sind 3 x 2 GB-Module verbaut, um eine optimale Speicher-Konfiguration zu erreichen
• HP Smart Array P410i Controller, erweitert um ein 1GB Flash Backed Write Cache-Modul
• Erweiterung um ein Drive Cage zur Erweiterung der Festplatten-Kapazität von 8 auf 16
• 16 x 300 GB 2,5” 10k SAS-Festplatten
• Zwei 750 Watt Netzteile
• Eine 10 Gigabit Dual-Port Netzwerkkarte

Nach den Eckdaten und den Fotos des Servers, hier nun die Benchmark-Ergebnisse. Gemessen wurde die Performance mit CrystalDiskMark 3.0. Zwei der 16 Festplatten wurden zu einem RAID1 zusammengefügt und auf diesem Volume wurde die Windows-Installation gemacht.

Screenshot des Array Configuration Utility mit den 14 nicht zugeordneten Festplatten:

Erstellung eines RAID 10:

Benchmark auf dem RAID10, 5 Durchläufe, 1000MB große Datei:

Benchmark auf dem RAID10, 9 Durchläufe, 4000MB große Datei:

Erstellung des RAID50 im Array Configuration Utility:

Benchmark auf dem RAID50, 5 Durchläufe, 1000MB große Datei:

Benchmark auf dem RAID50, 9 Durchläufe, 4000MB große Datei:

Nach diesen Tests habe ich die 14 Festplatten nochmal zu einem RAID5 zusammengefasst und CrystalDiskMark nochmal laufen lassen, hier noch diese Werte:

Fazit: Bei diesem Benchmark-Test bestätigt sich wieder einmal, das ein RAID10 eine bessere Performance bietet als ein RAID50 bzw. RAID5. Gerade bei den Tests mit 4K-Blöcken macht die der Unterschied am stärksten bemerkbar, bei 512K bzw. Sequentiell sind die Unterschiede nicht so gravierend. Bei dem Einsatz dieser Maschine als Hyper-V Host werden allerdings immer wieder viele kleine Änderungen an den Blöcken auf der Festplatte gemacht, eine Sicherung bzw. ein Export ist da schon seltener. Unsere Empfehlung ist ganz klar das RAID10, welche auch von diesen Werten bestätigt wird.

Als iSCSI Target dient der von Microsoft bereit gestellte iSCSI, welcher über MSDN Abo bezogen werden kann. Nähere Information wie man ein solches MSDN Abo bekommt gibt es hier.

Nach erfolgreicher Installation wird unter Server Manager -> Storage die Microsoft iSCSI Software Target aufgelistet.

Mit „rechtsklick“ auf ISCSI Target kann ein neuer Target angelegt werden.

Hier muss der Name des iSCSI Targets vergeben werden. Optional kann noch eine Beschreibung hinzugefügt werden.

Im nächsten Schritt müssen die iSCSI Initiator ausgewählt werden welche Zugriff auf den Target bekommen sollen:

Anschließend ist der Wizard durchlaufen und die Virtual Disk für den iSCSI Target können erstellt werden.

Dazu machen wir wieder einen „rechtsklick“ auf unseren gerade erstellten iSCSI Target (in meinem Beispiel „Storage1“) und wählen den Punkt „Create Virtual Disk for iSCSI Target“.

Wieder öffnet sich ein Wizard der bei der Erstellung der Virtuellen Festplatte hilft.

Dies ist der Pfad wo die Virtuellen Disk gespeichert werden.

Größe der Virtuellen Festplatte.

Anschließend kann noch eine Beschreibung angegeben werden und der Wizard ist durchlaufen.

Für die Live Migration werden Mindestens zwei iSCSI Bereiche benötigt.

Ein Teil muss nicht größer als ca. 100MB sein, dieser wird als Quorum verwendet. Darauf werden die „Cluster internen“ Daten abgelegt,

Der zweite(und dritte, vierte, fünfte etc. ) Bereich wird für die Daten verwendet.

Konfiguration des iSCSI Initialtor

 
Auf dem Hyper-V Server muss nun der iSCSI-Initiator konfiguriert werden, eine grafische Oberfläche bekommt man mit der Eingabe von “iscsicpl”, hier von Carsten Rachfahl erklärt.

Im Feld Ziel wird die IP Adresse, DNS Name oder IQN Name des iSCSI Target eingetragen.

Konfiguration der Datenträger

Bei der Datenträger Konfiguration kommt unser Windows 7 mit RemoteTools ins Spiel.
Per WMI greifen wir auf die Datenträgerverwaltung des Hyper-V-Servers zu, wo nun die zwei neuen Datenträger erscheinen sollten. Die iSCSI Ressourcen sind von „normalen“ Festplatten nicht zu unterscheiden, deshalb sollte hier mit Vorsicht gehandelt werden!
Die neuen Datenträger müssen nun noch Online geschaltet werden damit diese Formatiert werden können. Es ist nicht nötig einen Laufwerksbuchstaben zu vergeben, da dieses ohnehin bei der Clusterinstallation modifiziert wird.

Ausblick Teil 5: Installation des Clusters

Zur Konfiguration dient ein Windows 7 64-bit mit Remoteverwaltung Tools, wie diese installiert werden hat Jan Kappen in diesem Blogartikel bereits erklärt, weshalb ich an dieser Stelle nicht weiter darauf ein gehe. Bevor die Server per Windows 7 konfiguriert werden können, müssen einige Anpassungen vorgenommen werden.

Nachdem Windows 7 zur Remoteverwaltung angepasst wurde, müssen die Hyper-V Server angeglichen werden.
Unter dem Punkt „Remoteverwaltung konfigurieren“ muss der Zugriff per MMC aktiviert werden.

Desweiteren muss die Firewall angepasst werden, dieses ist über die Kommandozentrale Möglich: 

netsh advfirewall firewall set rule group="Windows-Verwaltungsinstrumentation (WMI)" new enable=yes

Wer das Konfigurieren per Konsole nicht mag kann auf den Core Configurator 2.0 zurückgreifen, welcher von Carsten Rachfahl in einem Blogartikel hier bereits vorgestellt wurde.

Nach einem Neustart des Betriebssystems kann die Netzwerkkonfiguration vorgenommen werden.

Die Hyper-V Server sind mit jeweils drei Netzwerkkarten ausgestattet:

• Das Heartbeat-Netz, welches die Verbindung der Hyper-V Server untereinander bereitstellt
• Das Client-Netz, welches das Netz in unserer Domäne ist
• Das iSCSI-Netz, welches die Anbindung zum iSCSI Target bereitstellt, welches auf dem Windows Storage Server läuft.

Beispiel für eine Netzwerkkonfiguration:

Anschließend wird auf beiden Server das Failovercluster Feature (Option 11) aktiviert, welches mit dem Failoverclustermanager in späteren Schritten konfiguriert wird.

Ausblick Teil 4: Installation und Konfiguration des iSCSI Target

Mit dem kleinen Tool kann man die Konfiguration seines Hyper-V Hosts überprüfen lassen, und man bekommt ein Ergebnis mit dem “Gesundheitszustand” des Systems inkl. Empfehlungen, die Microsoft ausspricht für den Betrieb von einem Hyper-V Host.

Ich habe den Analyzer mal bei uns auf einem System ausgeführt, es wurden insgesamt 29 Überprüfungen gemacht.

Hier sieht man, wie der BPA per Windows Update auf das System kommt:

Nachdem man im Server-Manager unterhalb der Hyper-V Rolle rechts auf “Diese Rolle überprüfen” geklickt hat, führt der BPA seine Tests durch und präsentiert das Ergebnis, welches man sich entweder nach “Nicht kompatibel”, “Ausgeschlossen”, “Kompatibel” oder “Alle” filtern lassen kann. In diesem Screenshot sieht man die Warnungen, die bei unserem Server erscheinen:

Wenn man einen Doppelklick auf die Fehlermeldung macht, bekommt man ein weiteres Fenster angezeigt, welches das genaue Problem beschreibt, die Auswirkung und die Lösung. Dies kann wie folgt aussehen:

Info: Da es sich bei diesem Server um einen virtuellen Domänen-Controller handelt, haben wir die Zeit-Synchronisation mit dem Host deaktiviert.

In diesem Fenster sieht man ebenfalls, das es sich nicht um ein Problem handeln muss, sondern lediglich um eine Abweichung von den vorgeschriebenen Konfigurationen, die aber bei Beabsichtigung ignoriert werden kann.

Man kann nun hingehen und all die benötigten Programme installieren, oder man geht hin und erledigt all diese Aufgaben mit seinem Notebook, was in der Regel neben einem steht. Beides keine wirklichen guten Lösungen, Möglichkeit 1 “müllt” den Server zu, Variante 2 dauert i.d.R. länger.

Meine Lösung in dieser Situation ist die, das ich mir mit "portablen Apps” helfe, d.h. Programme die ohne Installation lauffähig sind. Eine kleine Liste der hilfreichsten Programme und deren Nutzen führe ich hier aufführen möchte.

Imgburn portable

Imgburn ist ein Brennprogramm, mit dem sich aber unter anderem auch .iso-Dateien erzeugen lassen. Super, um mal eben Dateien in ein Image zu schreiben, um es in einer virtuellen Maschine einzubinden.

Winrar unplugged

Eine portable Version von Winrar. Sinnvoll um Dateien zu packen (geht natürlich in das .zip-Format auch mit Bordmitteln) oder zu entpacken, da Windows von Hause aus kein .rar-Archiv entpacken kann.

PDF-XChange Viewer portable

Man muss nicht zwangsläufig einen PDF-Viewer installieren, um den Inhalt einer PDF-Datei zu sehen. Der PDF-XChange Viewer ermöglicht das Betrachten von PDF-Dateien ganz ohne Installation.

Firefox portable

Ich denke zum Firefox brauche ich nichts mehr sagen. Wer nicht auf seinen Fuchs verzichten kann, der ist mit der portablen Version des Browsers bestens aufgehoben. Die meisten Add-Ons funktionieren, allerdings funktioniert z.B. Java nur, wenn es auch auf dem Host-System installiert ist.

WinSCP portable

Mit WinSCP ist man in der Lage, Dateien über eine gesicherte Verbindung mit einem Linux-Host auszutauschen.

WinWGet portable

WinWGet ist ein Download-Manager, mit dem man seine Downloads managen kann und der in der Lage ist, abgebrochene Downloads (je nach Server-Einstellung) wieder aufzunehmen. Um große und/oder mehrere Dateien herunterzuladen sehr zu empfehlen

Da die Tools eine Sammlung von Powershell Skripten sind müssen wir zu allererst “.Net Framework 2.0” und die “Powershell” mit dem Befehl:

start /w ocsetup NetFx2-ServerCore

start /w ocsetup MicrosoftWindowsPowerShell 

nachinstallieren. Danach kann das Core Configurator 2.0 Paket unter der URL http://coreconfig.codeplex.com/ heruntergeladen werden. Nach dem Download befindet sich das ISO-Image CoreConfig.iso auf ihrer Platte. Diese entpacken Sie mit einem Tool (z.B. WinRAR) und kopieren den Inhalt in ein Verzeichnis auf den Hyper-V Server 2008 R2 (wir benutzten hierzu standardmäßig das Verzeichnis  “C:\Tools”). Danach wechseln Sie auf den Hyper-V Server und starten das Core Configurator Startscript indem sie in das Verzeichnis C:\Tools gehen und dort den Befehl:

Start_Coreconfig.wsf

eingeben. Daraufhin öffnet sich eine Lizenzabfrage die Sie bitte mit klicken auf den “Accept” Button bestätigen.

Jetzt erscheint das Hauptfenster indem man verschiedenen Bereiche anwählen kann. Im folgenden finden Sie einige Screenshots dieser Bereiche in denen dann diverse sinnvolle Einstellungen (gelb markiert) vorgenommen werden können.

Bereich “Computer Settings…”:

Hier lassen sich sinnvolle Einstellungen in folgenden Bereichen vornehmen:

“Computer and Domain…”

“Remote Desktop…”

“WinRM”

“Services…”

Bereich “Control panel…”:

Ich denke, dass Einstellungen im den Bereichen:

“Windows Update…”

“FireWall…”

“Add Drivers…”

“Keyboard…”

“Date and Time…”

sinnvoll sind.

Bereich “Network Settings…”:

Modifizierungen kann man hier in den Bereichen:

“Network Interface Cards…”

“Proxy configurations…”

“Group Memberthip…”

“Share membership…”

“iSCSI configuration…”

vornehmen.

Bereich “Hyper-V settings…”:

Hier kann man schließlich sehen welchen VMs laufen (incl. der Ansicht der Konsole)  und kann die VMs auch Starten und Stoppen.

Fazit:

Der Core Configurator 2.0 lässt sich nicht nur in der Core Installation sondern auch beim Hyper-V Server R2 hervorragend einsetzen. Mit Ihm ist es möglich auch Einstellungen vorzunehmen die man mit der Shell nur sehr schwer durchführen kann und nach denen man bei Goolge auch sehr lange suchen muss. Ich kann diese Tool allen Hyper-V Server Anhängern uneingeschränkt empfehlen.

Fehler (2912)
Interner Fehler beim Kontaktieren eines Agents auf dem Server “hyperv1.it-solutions.de”.
(Unknown error (0×80041001))

Empfohlene Aktion
Stellen Sie sicher, dass der Agent installiert ist und ausgeführt wird. Stellen Sie sicher, dass der WS-Verwaltungsdienst installiert ist und ausgeführt wird, und starten Sie dann den Agent neu.

Nach Überprüfung der Dienste und kurzem Überlegen sind wir dann auf die Firewall als mögliche Fehlerquelle gekommen, was sich letztendlich auch als richtig erwiesen hat. Wie in den Screenshots erkennbar, gibt es auch spezielle Ausnahmen, die aktiviert werden müssen.

Dazu klickt man in der Managementkonsole auf “Host Hinzufügen” und durchläuft den Wizard.

Ich habe in diesem Beispiel nur einen Server hinzugefügt, danach aber auch alle weiteren in unserem Netzwerk. Das Ergebnis sieht dann wie folgt aus:

Die zu verwaltenen virtuellen Server sind nun alle aufgelistet unter “Virtuelle Maschinen” und können nun administriert werden. Dazu aber in den nächsten Beiträgen mehr.

Jan