Die Nutzung von Differenzierenden VHDs mit Hyper-V

Da ich zur Vorbereitung eines weiteren Blogartikels mehrere VMs benötige, die alle eine gleichartige Grundinstallation haben, verbinde ich diese Installation mit der Nutzung von differenzierenden VHDs, um dieses Verfahren in diesem Artikel zu beschreiben. Differenzierende VHDs sind virtuelle Festplatten, in denen ausschließlich die Änderungen geschrieben werden, der Grundbestand liegt in einer eigenen VHD. Diese VHD ist einmalig und immer gleich, diese Art von Verfahren funktioniert, weil auf die Basis-VHD nur lesend zugegriffen wird. Mit Hilfe dieses Verfahrens ist man in der Lage, mehrere Dutzend VMs bereitzustellen, die dann aber nicht pro VM jeweils die volle Größe nutzen, sondern immer nur die Änderungen speichern. Ausgehend von dem Ziel, 50 VMs mit Windows 7 bereitzustellen, hätten wir auf unserem Hyper-V Host einmal die ~10 GB an Daten liegen, nach dem Hinzufügen aller 50 VMs zur Domäne sind auf dem Server pro VM weitere 600 MB in Nutzung. Mit einer dynamisch erweiterbaren VHD pro VM und ohne Nutzung von differenzierenden VHDs würde diese Installation 50 x 10 GB = 500 GB benötigen. Wenn die VMs jeweils mit differenzierenden VHDs eingerichtet sind, wird 1 x 10 GB + 50 x 100 MB = 15 GB benötigt. Wir sparen uns auf unserem Host somit über 95% an Speicherplatz. Wie die Einrichtung und Nutzung funktioniert, möchte ich nun in dem folgenden Artikel beschreiben.

Meine Demo Hyper-V Infrastruktur vom TechDay Private Cloud

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

Installation des System Center Data Protection Manager 2012 Beta

Da vor kurzem der System Center Data Protection Manager 2012 in der Beta-Version erschienen ist und das Produkt sehr interessant ist, habe ich die Installation und die Einrichtung einer Schutzgruppe inkl. der Installation eines DPM-Agenten einmal in einer Screenshot-Serie zusammengefasst. Wir setzen den Data Protection Manager in der Version 2010 für unsere interne Umgebung ein und sichern damit einen Großteil unserer Hyper-V VMs. Für alle die den Data Protection Manager noch nicht kennen, hier eine Beschreibung des Produktes. Nun aber zur Installation des Data Protection Manager 2012 Beta.

SystemCenter 2012 Testdrives und Microsoft Virtual Academy

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

NetApp Migration von einem Filer auf einen anderen

Vor ein paar Tagen haben wir einen neuen NetApp Storage bekommen (super Teil aber davon später mal mehr). Jetzt standen wir vor der Aufgabe, die Daten unseres bestehenden Hyper-V Clustes von unserer alten NetApp FAS2050 (Quelle NetApp) auf die neu NetApp FAS6040 (Ziel NetApp) zu übertragen. Weiterhin war das Ziel, dass die virtuellen Maschinen, die auf einem Cluster Shared Volume liegen und per iSCSI angebunden sind, nach der Migration einwandfrei funktionieren. Und alles natürlich mit möglichst wenig Downtime.

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

Netzwerkkonfiguration im Hyper-V Cluster

Ein Hyper-V Cluster soll möglichst viele Netzwerkkarten besitzen. Das ist vielen bekannt. Wie konfiguriert man aber jetzt die Netze, wenn man, wie in unserem Beispiel, sechs davon hat? Nachdem ich bereits in unserem Artikel “Hyper-V Cluster und Netzwerkkarten Bindungen” auf die einzelnen Protokolle und Bindungen der Netzwerkkarten eingegangen bin, beschreibe ich in diesem Artikel unsere momentane “Best Practice” zur Hyper-V Cluster Netzkonfiguration. Diese basieren neben unseren Erfahrungen auch auf Empfehlungen und Support Richtlinien von Microsoft.

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:

Videocast über das Importieren von VMs auf einem Hyper-V Cluster

Oft wir ein Hyper-V Cluster eingeführt und es sind schon vorher VMs (virtuelle Maschinen) da. Diese möchte man normalerweise in den Failover-Cluster importieren. Der Failover-Manager bietet dafür aber leider keine Option an. Wie es trotzdem geht, zeigen wir in diesem Videocast. Viel Spaß beim Zuschauen.

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

Die HP LeftHand P4000 Virtual SAN Appliance Software im Test

Überblick

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.