Neuheiten Hyper-V & Windows Server 8, Teil 2

Wir haben bereits in einem ersten Artikel zum Thema Windows Server 8 und Hyper V einige Neuerung vorgestellt, die der kommende Windows-Server mit sich bringen wird. Wir setzen diese Beschreibung in diesem Bericht fort: Dabei werden wir uns auch weiterhin auf den Codenamen Windows Server 8 beziehen, denn nur diese Beta-Version liegt uns bisher vor, obwohl schon klar ist, dass dieser Server unter dem Namen Windows Server 2012 auf den Markt kommen wird. John Savill beschäftigt sich hier mit den unterschiedlichen Methoden der Live-Migration und dem neuen Feature Hyper-V Replica.

Zu den großen Fortschritten, die Microsoft seinen Kunden bei der Einführung der R2-Version des Windows Servers 2008 präsentierte, gehörte ohne Zweifel die Live-Migration beim Hyper-V: Keine Downtime mehr und keine Client-Systeme, deren Verbindungen abreißen – das kannten bis dahin nur die Anwender der VMware-Lösungen. Durch diese Technik sind viele Szenarien in der Unternehmens-IT möglich geworden, die zuvor so nicht denkbar waren. So können Administratoren beispielsweise alle virtuellen Maschinen von einem Host auf einen anderen Knoten in einem Cluster „evakuieren“, um beispielsweise zu Patchen, Systeme neu zu starten oder Hardware zu warten, während alle Dienste ohne Unterbrechung zur Verfügung stehen.

Viele Vorteile schon unter Windows Server 2008 R2

Mit Hilfe der Live Migration werden auch die sogenannte Performance and Resource Optimatization (PRO – Leistungs und Ressourcenoptimierung) und die Dynamic Optimization im System Center Virtual Machine Manager (SCVMM) möglich gemacht. Diese beiden Features führen eine automatisches Ausbalancieren und Verschieben von VMs aus, das auf eine entsprechende Auslastung der Ressourcen beruht. Sie stellen so eine möglichst optimale Performance der virtuellen Maschinen sicher. indem sie über die Host-Systeme verteilen, wenn die Ressourcen nach Änderungen verlangen. Das Power-Optimization-Feature kann die Live Migration zudem dazu einsetzen, die VMs auf insgesamt weniger Host-Systeme zu konsolidieren, wenn die allgemeine Systemlast gerade nicht so hoch ist. Zudem können dann während dieser Zeit nicht benötigte Host-Systeme herunter- und dann auch wieder hochgefahren werden, wenn sie wieder gebraucht werden.

Unter Windows Server 8 haben die Microsoft-Ingenieure diese Live Migration Features weiterentwickelt, ihre Anwendungsgebiete und Skalierbarkeit deutlich erweitert, damit auch neue Szenarios und Veränderungen in der IT-Infrastruktur mit ihrer Hilfe abgedeckt werden können. So sind jetzt gleichzeitige Live-Migrationen (concurrent live migrations), eine SMB Live-Migration, Live-Storage-Migrationen und auch Migrationen möglich, bei denen die virtuellen Maschinen nur eine Gemeinsamkeit besitzen – die geteilte Ethernet-Verbindung.

Neue Möglichkeiten bei der Live-Migration unter Hyper-V

Concurrent Live Migrations: Unter Windows Server 2008 R2 konnte innerhalb eines Clusters zwischen den zwei beteiligten Knoten nur eine Live-Migration gleichzeitig durchgeführt werden: vom aktuellen Besitzer der VM hin zum Zielsystem. Der Grund für diese Art der Einschränkung war ziemlich einfach: Die meisten Rechenzentren setzen aktuell ein Netzwerk-Infrastruktur mit einer Geschwindigkeit von 1 Gbit/s ein. Eine Live-Migration ist grundsätzlich sehr Netzwerk-intensiv: Der gesamte Speicherinhalt wird zwischen den Hosts über das Netzwerk kopiert. Da die VM während dieses Kopiervorgangs weiterläuft, sind mehrere Kopierdurchgänge notwendig, um auch Speicherbereiche richtig zu transferieren, die während der vorherigen Kopieraktion geändert haben. Diese speziellen Kopieraktionen laufen mit jedem Durchgang immer schneller ab, denn die Menge der davon betroffenen Daten wird auch mit jedem Durchgang abnehmen.

Hyper-V war schon immer effizient, wenn es um die Auslastung des Netzwerks ging, und so lastet das System dann auch einen 1 Gbit/s-Link voll aus. Wenn ein Administrator in dieser Konfiguration mehrere, gleichzeitige Live-Migrationen zwischen zwei Host-Systemen ausgeführt hat, wurde die Netzwerkgeschwindigkeit zwischen den einzelnen Bewegungen aufteilt. Durch diese Aufteilung der Bandbreite, dauert die Kopie natürlich für jede VM länger. Zudem hat sich dabei während der Dauer des Kopiervorganges auch immer mehr Speicherinhalt verändert, was wiederum die Gesamtzeit erhöhte, die zum Bewegen der virtuellen Maschine benötigt wurde.

Das Dilemma beim Verschieben der VMs: ein Beispiel

Wer sich dieses Dilemma vor Augen führen möchte, sollte sich vorstellen, dass er zunächst eine Flasche mit einem kohlesäurehaltige Getränk durch einen Trichter schüttet. Sollen dann der Inhalt von vier solcher Flaschen durch den gleichzeitig durch den gleichen Trichter geschüttet werden, so wird dies auch viermal so viel Zeit benötigen: Der Trichter ist der begrenzte Faktor der gesamten Aktion. Nun muss man sich vorstellen, dass irgendjemand immer wieder Brause in die Flasche zurück tröpfeln lässt, während sie geleert wird. Je länger es dann dauert, eine Flasche zu leeren, umso mehr  Getränks wird man dadurch ausschütten müssen, was wiederum die Gesamtzeit der „Ausgießvorgangs“ erhöhen wird. In einem derartigen Szenario wird man die vier Flaschen am schnellsten leeren können, indem man sie eine nach der anderen durch den Trichter gießt.

Wird dieses Beispiel auf die Hyper-V-Virtualisierung übertragen, so ist der Trichter das Netzwerk, die Flasche mit dem kohlensäurehaltigen Getränk steht für die Live-Migration und die zusätzlichen Mengen des Getränks, die wieder „hinein tröpfeln“, die repräsentieren dabei dann die Veränderungen am Speicherinhalt, die während der Live-Migration auftreten. Der Virtual-Machine-Manager hilft dabei, solche multiplen Live-Migrationen zu verarbeiten, indem er sich in einer Warteschlange aufreiht und sie dann nach und nach abarbeitet. Dadurch bekommen die Administratoren die Möglichkeit, „Massen-Migrationen“ mittels der Managementschnittstelle in eine Warteschlange zu stellen und diese dann durch die Software abarbeiten zu lassen.

Mit 10 Gbit/s geht es schneller…

In der Zwischenzeit sind aber in vielen Rechenzentren bereits Netzwerk mit einer Geschwindigkeit von 10 Gbit/s zum Standard geworden und eine einzelne Live-Migration wird diese Bandbreite nicht ausnutzen (dies ist dann ein richtig „großer Trichter“). Um diesem Fortschritt Genüge zu tun, erlaubt der Windows Server 8 mehrere, gleichzeitige Live-Migrationen zwischen Host-Systemen. Es existiert keine festgelegte maximale Anzahl an gleichzeitigen Migrationen, aber ein Administrator kann einen solchen Wert als Teil der Hyper-V Host-Konfiguration festlegen. Hyper-V untersucht die Kapazitäten des Netzwerks und die zur Verfügung stehende Menge an Bandbreite. Dann stellt der Server die Anzahl der gleichzeitigen Live-Migrationen basierend auf den aktuellen Gegebenheiten so ein, dass die beste Performance sichergestellt ist.

SMB- und Storage-Live-Migration: Zwei neue Wege

SMB live migration: Die Erweiterungen, die Microsoft bei der Live-Migration im Hochverfügbarkeitsumfeld mit dem Windows Server 8 bereitstellt, sind ein großer Schritt vorwärts. Aber bei der Fähigkeit zur Live-Migration wurde eine weitere Veränderung vorgenommen, die noch weitreichendere Konsequenzen hat: Die Fähigkeit eine Live-Migration auf eine virtuelle Maschine auszuführen, die sich außerhalb der Cluster-Konfiguration befindet. Diese Feature erlaubt es einem Administrator, eine VM zwischen zwei Hosts zu migrieren, die nicht Teil eines Failover-Cluster sind! Zwei Typen dieser Art der Live-Migration außerhalb einer Cluster-Umgebung stehen dann mit dem neuen Server zur Verfügung: „SMB live migration“ und die „shared-nothing live migration“.

Bei einer SMB live migration sind zwei Hyper-V Host mit dem gleichen SMB-File-Share verbunden. Auf diesem befinden sich die virtuellen Datenträger (VHDs) und die Konfigurationsdateien der virtuellen Maschine, die migriert werden soll. Die einzige Bedingung, die einem derartigen Szenario existiert, besteht darin, dass beide Computerkonten der Hyper-V Hosts vollen Zugriff und Kontrolle auf das Verzeichnis und die Dateifreigabe besitzen. Die grundlegende Prinzipien für eine Live-Migration sind auch in diesem Fall die gleichen, wie bei eine Verschiebung in einem Failover-Cluster. Allerdings ist die virtuelle Maschine in diesem Szenario keine geteilte (shared) Ressource, weshalb hier einige zusätzliche Schritte notwendig werden:

• Es wird eine TCP-Verbindung zwischen dem Host, auf dem die virtuelle Maschine läuft (dem Source-Host) und dem Zielsystem aufgebaut. Die Konfigurationsdaten der VM werden an das Zielsystem geschickt. Das erlaubt es auf dem Zielsystem, eine Art „Skelett-VM“ zu erstellen und die benötigte Menge an Speicherplatz zu reservieren.
• Der Inhalt des Hauptspeichers wird vom Source- auf das Zielsystem kopiert. Wie bei allen Live-Migrationen besteht auch dieser Vorgang zunächst aus einer initialen Übertragung des kompletten Speicherinhalts, gefolgt von mehreren Iterationen, um die Bereich des Speichers zu kopieren, die sich in der Zwischenzeit verändert haben.
• Wenn die Menge des Hauptspeicherinhalts, die noch transferiert werden muss, kopiert werden kann, ohne dass sie die „Einfrierzeit“ der VM signifikant beeinflusst, wird die virtuelle Maschine temporär stillgelegt. Dann wird der restliche Speicherinhalt plus dem Status der CPU und der Geräte zum Zielsystem kopiert.
• Die Handles der Dateien auf dem SMB-File-Share werden vom Quell- zum Zielsystem transferiert. Dies geschieht zusammen mit etwaigen weiteren Storage, der über den ebenfalls unter Windows Server 8 neuem virtuellen Fibre-Channel-Adapter angebunden ist.
• Dann wird die Ziel-VM aktiviert und die Quell-VM wird gelöscht.
• Es wird ein reverses ARP-Paket (Address Resolution Protocol) ausgesendet, das die Netzwerk-Switches dazu veranlasst, ihr Mapping der IP-Adresse der virtuellen Maschine auf die MAC-Adresse des neuen Host-Systems umzustellen.

Bei diesem gesamten Vorgang wird die VM typischerweise für Millisekunden nicht auf Anfragen reagieren. Das ist ein Wert, der weit unter dem typischer TCP-Timeouts liegt, so dass die Anwender, die diese VM verwenden, nichts bemerken werden.

Wenn ein Administrator diesen Vorgang mittels eines Ping-Befehls zur virtuellen Maschine, die in diesem Fall migriert wurde, beobachten würde, so würde er für ein Ping-Packet eine Antwortszeit sehen, die länger als üblich ist. Es ist auch möglich, dass er in diesem Fall ein verworfenes Packet zu sehen bekäme. Aber das sind keine Werte, die ein Anwender bemerken würde, oder die einen Abbruch der Verbindung verursachen würden.

Auch der Festplattenspeicher "bewegt" sich

Live storage migration: Bevor wir uns hier mit der shared-nothing-Variante der Migration befassen, wollen wir zunächst einen Blick auf einen weiteren Weg der Live-Migration werfen, der ebenfalls neu ist in der Hyper-V-Umgebung: Nun ist es also auch bei Microsofts Virtualisierungslösung möglich, die Storage-Daten (wie etwas VHDs) und die Konfigurationsdateien zu verschieben, während die virtuelle Maschine aktiv ist. Eine Verschiebung des Storage-Bereichs einer VM kann in verschiedenen Szenarien zum Einsatz kommen:

• ·Das Verschieben einen VM von einem lokalen Speicher auf ein SAN. 
•   Das Verschieben von VMs zwischen SANs, um beispielsweise die I/O-Operationen besser auszubalancieren oder wenn ein SAN gewartet werden muss.·
• Das Verschieben einer VM hin zu einem SMB-Share.
• Ein NFTS-Volumen von virtuellen Maschinen „befreien“, damit beispielsweise eine chkdsk-Operation darauf ausgeführt werden kann.

Aber ganz gleich, aus welchen Grund eine derartige Verschiebung stattfinden soll: Mit Hilfe der Storage Life-Migration können virtuelle Maschinen zwischen allen unterstützten Storage-Medien wie DAS, SAN und Datei-basierten Medien wie SMB-Share ohne Downtime für die VM verschoben werden.

Allerdings arbeitet die Storage-Migration anders als die „normale“ Life-Migration: Eine Life-Migration arbeitet normalerweise mit Daten, die sich im Hauptspeicher befinden. Von diesem Speicher kann extrem schnell gelesen werden und ebenso schnell kann die Software dort wieder hineinschreiben. Deshalb ist auch möglich, mit Iterationen der Änderungen im Hauptspeicher zu arbeiten, bis die letzte Kopie dann arbeitet. Aber im Umfeld der Storage-Systeme würden diese vielen Iterationen mit einer geschäftigen Disk auf keinen Fall mithalten können.

Wie die Skizze in Bild 1 zeigt, beinhaltet der Prozess einer live storage migration verschiedene Schritte, deren Aufgabe darin besteht, die Probleme zu lösen, die durch die vergleichsweise langsame Gangart der Festplatten entstehen. Dabei wird im ersten Schritt eine initiale Kopie des Inhalts auf der Festplatte angelegt: Dazu gehören dann die VHD- und Konfigurationsdateien, die Schnappschüsse und alles andere, was zur virtuellen Maschine dazu gehört. Während dieser Zeit liest und schreibt die VM noch vom und zum Quell-Medium. Im zweiten Schritt, nach dem die erste Kopie komplett ist, spiegelt der VHD-Stack alle Schreibzugriffe auf beiden Medien – Quell- und Ziel-Storage. Dabei wird ein einzelner Durchlauf ausgeführt, der die Blöcke kopiert, die sich während des Anlegens der Initial-Kopie geändert haben.

Im dritten Schritt sind dann schließlich Quelle und Ziel miteinander synchronisiert. Der VHD-Stack schaltet dann die VM um, so dass sie ihre Schreib- und Lesezugriffe nur noch auf dem Ziel-Storage ausführt. Dann löscht er die Daten auf dem Quell-Storage. Als Resultat dieser Vorgänge wurde eine komplette Verschiebung des mit der virtuellen Maschine verbundenen Speichers durchgeführt, ohne dass dabei eine Unterbrechung aufgetreten ist.

Nichts gemeinsam und trotzdem migrieren

Shared-nothing live migration: Wenn es ein neues Hyper-V-Feature gibt, das große Beachtung verdient und einen echten „Wow-Effekt“ bei allen Fachleuten hervorgerufen hat, dann ist es die Fähigkeit, eine VM von einen Hyper-V-Server zu einem anderen zu migrieren, deren Gemeinsamkeit darin besteht, dass zwischen ihnen eine Gigabit-Ethernet-Verbindung besteht. So ist dann eine Verschiebung ohne Unterbrechung zwischen zwei Host-Systemen möglich, ohne dass diese Teil des gleichen Clusters sind oder einen gemeinsamen Festplatten-Speicher besitzen.

Grundsätzlich sieht die shared-nothing live migration ebenso aus wie die zuvor beschriebene SMB live migration: Aber bei diesem Vorgang ist dann zusätzlich auch noch notwendig, den Speicher ebenfalls mit zu verschieben, wobei dann die zuvor geschilderte Technik der Storage-Migration zum Einsatz kommt. Es wird also all das ausgeführt, was zuvor bei der SMB-Migration geschildert wurde plus der ebenfalls geschilderten Vorgänge bei einer Storage-Migration. Zudem wird dabei eine Spiegelung der Schreibzugriffe sowohl zum Quell- als auch zum Ziel-Storage während der Live-Migration des Hauptspeicherinhalts und des Status aufrechterhalten. Erst danach werden dann die Host-Systeme „umgeschaltet“.

Mit dieser Technik wird es Administratoren möglich, virtuelle Maschinen zwischen beliebigen Hyper-V-Hosts auf Windows-8-Server-Systemen zu verschieben, selbst wenn sich nicht mehr gemeinsam haben, als ein „geteiltes“ Ethernet-Kabel. Der Autor konnte einer Demonstration beiwohnen, bei der eine derartige Live-Migration zwischen zwei Laptop-Systemen nur mit lokalem Storage durchgeführt wurde. Die virtuelle Maschine nutze diesen lokalen Speicher und konnte ohne Unterbrechung von einem System auf das andere geschoben werden. Wenn man sich diese Fähigkeit des Servers im Einsatz vorstellt, um beispielsweise VMs zwischen Clustern, Host-Systemen oder sogar zwischen Private- und Public-Cloud-Infrastrukturen vorstellt, so werden unter anderem die vielfältigen Möglichkeiten dieser Technik für Provider von IaaS-Lösungen (Infrastructure as a Service) deutlich.

Ein weiterer großer Schritt: Hyper-V Replica

Alle Techniken zur Live-Migration – dazu gehört auch die Live-Migration von Storage – kommen in geplanten Migrationen zum Einsatz, wie sie in der typischen täglichen Arbeit der Administratoren die Regel sein dürften. Wenn aber um Bereiche wie das Disaster-Recovery geht, dann sehen sich Unternehmen und ihre IT-Abteilungen ganz anderen Herausforderungen gegenüber.

So stellen dann auch einige Firmen spezielle Lösungen bereit, die eine Hyper-V-Umgebung mit den Möglichkeiten eines Disaster Recoveries ergänzen. Allerdings setzen viele dieser Lösungen auf entsprechende Speicherlösungen auf, was für kleinere und mittlere Unternehmen häufig keine gute Lösung ist: Entweder stehen solche Lösungen dort nicht zur Verfügung stehen oder sie überschreiten schon in der Anschaffung das Budget. Wohl auch um diese Problematik zu entschärfen, wurde der Hyper-V im Windows um ein Feature erweitert, das als Hyper-V Replica bezeichnet wird.

Es stellt eine asynchrone Technik zur Replikation des Storage von virtuellen Maschinen von einem Hyper-V-Host zu einem anderen bereit. Dabei kann dann der Storage-Bereich einer VM von einem Hyper-V-Host auf einen anderen geschoben werden. Das funktioniert auch dann, wenn diese Rechner unterschiedliche Typen von Speicher verwenden. Die inititale Replikation des Storage einer Quell-VM über das Netzwerk kann dabei auf zwei Wegen durchgeführt werden:

• mit Hilfe einer direkten Verbindung zwischen dem Quell-System und dem Replikations-Server oder
• indem der Storage-Bereich der virtuellen Maschine an einem Ort im Netzwerk abgespeichert wird, von dem der Replikations-Server einlesen kann. Diese Vorgehensweise wird auch als „off-the-network“ seeding bezeichnet.

Für den Fall, dass nicht genügend Bandbreite für die erste Replikation zur Verfügung steht, können Administratoren ein Backup der VMs auf dem primären Server ziehen und dieses dann auf dem Replika-Server wieder einspielen. Dies kann gerade dann sinnvoll sein, wenn ein solcher Replika-Server in einer Außenstelle des Unternehmens betrieben werden soll oder wenn es sich um virtuelle Maschinen handelt, zu denen große Mengen an Speicher gehören.

Nach der ersten Übertragung: Nun kommen Deltas zum Einsatz

Nach der ersten kompletten Übertragung wird standardmäßig alle fünf Minuten eine Delta-Replikation zwischen den beiden Systemen durchgeführt, bei der nur noch die Updates über das Netz übertragen werden müssen. Dabei verläuft die Übertragung asynchron in periodischen Abständen. Dadurch ist dies selbstverständlich keine Lösung, für eine Replikation in Echtzeit. Wenn also wirklich ein ungeplanter Ausfall ohne Vorwarnungen auftritt, so ein gewisser Teil der Speicherinhalten verloren gehen. Dabei wird es sich dann maximal um den Inhalt der letzten fünf Minuten, die seit dem letzten Delta-Abgleich vergangen sind, handeln. Der asynchrone Ansatz bietet der IT-Mannschaft aber auch Vorteile:

• kaum Einschränkungen, was die Größe der zu replizierenden virtuellen Maschinen angeht und·
• die Ansprüche an das Netzwerk zwischen primären und Replika-Server sind eher moderat.

Die exakte benötigte Bandbreite, die für den Einsatz dieses Features zwischen den Servern benötigt wird, beruht darauf, wie groß die Veränderungen beim Storage sind. Aber es existieren durchaus auch geplante Szenarios für Hyper-V Replica, die eine Replikation auf eine zweite Site vorsehen, die über eine WAN-Strecke angebunden ist.

Wichtiger Hinweis: Es handelt sich hierbei nicht um eine Lösung handelt, die ein automatisches Failover anbietet. Tritt also ein solches „Disaster“ auf, so müssen die Administratoren das Feature manuell aktivieren. Es stehen jedoch entsprechende Optionen bereit, die es erlauben, einen zuvor angelegten Failover-Prozess zu testen. Dabei kann dann das Replika-System gegen ein Testsystem überprüft werden, so dass der laufende Betrieb durch diese Überprüfung nicht gestört wird. Bei einem geplanten Übergang würde der Administrator dann die primäre Maschine manuell herunterfahren, wobei ein letztes abgleichendes Delta über das Netz an die Replika-Maschine gesendet wird. Diese wird dann dieses Delta noch hinzufügen und dann mit dem Wiederaufsetzen des replizierten Primär-Systems beginnen.

Es wird Administratoren sicher gefallen, dass die Konfiguration von Hyper-V Replica ein sehr einfacher Vorgang ist. So ist die Replikationskonfiguration nun eine Einstellung, die an allen Hyper-V-Servern zu finden ist (Bild 2). Diese Einstellung kann mit Option verwendet werden, die integrierte Windows-Authentifizierung einzusetzen, bei der die Änderungen über den Port 80 (HTTP) versendet werden, oder die die Zertifikatsbasierte Authentifizierung einzusetzen, bei der die Änderungen über den Port 443 (HTTPS) wandern. Dieser zweite Weg beinhaltet auch die Möglichkeit, die Update-Daten der virtuellen Maschine zu verschlüsseln, wenn sie über das Netzwerk gesendet werden.

Replikationseinstellung: Wahl der Ports ist möglich

Für die Konfiguration der Replikation können Administratoren die verwendeten Ports auch verändern. Zudem kann ein Server so eingestellt werden, dass er eine Replikation von jedem Hyper-V Server oder nur von bestimmten Hyper-V Maschinen akzeptiert. Der einzige zusätzliche Schritt, den die Administratoren auf dem Zielsystem vornehmen müssen, ist das Einschalten der entsprechenden Firewall-Regeln, um die reibungslose Kommunikation über den gewählten Port zu ermöglichen.

Steht ein Hyper-V Server zur Verfügung, bei dem die Replikation eingeschaltet ist, so kann eine virtuelle Maschine durch die Aktion „Enable Replication“ entsprechend konfiguriert werden. Hat der Administrator diese Fähigkeit über das Kontextmenü eingeschaltet, so wird er in einem nächsten Schritt aufgefordert, den Ziel Replica-Server anzugeben. Er muss zudem angeben, wie die initiale Replikation durchgeführt werden soll. Die Replikation erlaubt es ihm außerdem auch noch, eine gewisse Anzahl zusätzlicher Recovery-Punkte aufzusetzen, bei denen es sich um stündliche VSS-Schnappschüsse (VSS – Volume Shadow Copy- Volumenschattenkopie) handelt. Sie stellen die Integrität spezifischer Replika Recovery-Punkte sicher. Die Replikationen einer VM sowie und „Health“ der Replikation können jederzeit mit Hilfe des sogenannten „Health Report“ überprüft werden.

Diese Anzeige ist in Bild 3 auf einer englischsprachigen Version des Servers zu sehen. Hier wird dann die Anzahl der Replikations-Zyklen ebenso angezeigt wie die durchschnittliche Größe der Replikation und der Zeitpunkt, an dem diese ausgeführt wurde. Der Administrator kann der Aktivierung einer Replika-VM auch eine alternative TCP/IP-Konfiguration für diese festlegen. Diese alternative Konfiguration muss direkt in der virtuellen Maschine verankert werden, wenn die Replikation in einem anderen Netzwerk beheimatet ist und die Netzwerk-Virtualisierung (ein weiteres neues Feature des Windows Server 8) nicht zum Einsatz kommt.

Für kleine Installationen gut geeignet aber keine Echtzeitlösung

Administratoren sollten sich mit dieser Technik vertraut machen und dabei unbedingt abwägen, ob eine solche Lösung die Bedürfnisse ihrer Firma und ihrer IT-Infrastruktur abdecken kann: Microsoft betont ausdrücklich, dass dieses Feature für kleine und mittelständische Unternehmen entwickelt wurde, die eine Möglichkeit für eine Disaster-Recovery-Fähigkeit mit Hilfe einer zweiten Site suchen. Es ist gut, dass diese Möglichkeit beim neuen Server „out-of-the-Box“ zur Verfügung steht, einen guten Grad an Disaster-Recovery anzubieten hat, dabei ohne ein Hochgeschwindigkeitsnetzwerk auskommt und mit jeder Art von Storage zusammenarbeiten kann. Damit dürften die Ansprüche vieler Unternehmen bereits erfüllt sein. Aber IT-Verantwortliche und Administratoren sollten immer bedenken, dass diese Funktionalität weder in Echtzeit arbeitet noch automatisiert arbeitet – wer diese Ansprüche hat, muss sich nach wie vor nach der Lösung eines Drittanbieters umschauen, die auf Hyper-V aufsetzt.

John Savill/ fms