Ein MacBook (Laptop von Apple) ist – wenn man die emotionale Komponente erst einmal unberücksichtigt lässt – letztendlich auch nur ein Laptop. Dennoch ist ein oft primär dem Apfel-Logo und dem Design geschuldetes Interesse nachvollziehbar, und so ertappen Sie sich plötzlich schon bei der Abwägung der Vor- und Nachteile einer Kaufentscheidung. Folgende Punkte könnten dazu beitragen, dass Ihnen die Kaufentscheidung berechtigterweise nicht leichtfällt:

Letztendlich wird Ihnen klar, dass der Umstieg mit gewissen Herausforderungen verbunden sein kann und womöglich schnell auch zu einem persönlichen Waterloo wird. Somit grenzen sich Ihre Optionen wie folgt ein:

Die aufgeführten Optionen sind – wenn Sie sich wirklich ein MacBook gewünscht haben – durchaus als unbefriedigend zu bezeichnen: Entweder ist die Option aus ökonomischer und ökologischer Sicht unsinnig (a), umständlich (b), emotional nicht vertretbar (c), oder sie ist das Gegenteil des eigentlichen Wunsches (d).

Wie eine Anwendung starten
Was wäre aber, wenn Sie mit Ihrem neuen MacBook einfach einen Windows-Rechner wie eine Anwendung starten könnten? Also einen Rechner im Rechner? Abbildung 1 unterstützt diesen Gedankengang und zeigt ein MacOS-Betriebssystem (Hintergrund) sowie ein Windows-Betriebssystem (Vordergrund), das wie eine Anwendung in einem Fenster ausgeführt wird.

Der Rechner im Rechner ermöglicht es Ihnen, sich langsam an das neue Betriebssystem und die neuen Anwendungen heranzutasten, während Sie aber zu jeder Zeit noch direkten Zugriff auf die gewohnte Windows-Umgebung haben.

Bevor Sie nun aber Heureka! rufen und der Autor aufgrund des gewählten Beispiels subtil Einfluss auf eine eventuell ausstehende Kaufentscheidung genommen hat, sollten Sie das Beispiel nutzen, um mit den darüber implizit transportierten Informationen zu arbeiten. Wenn der Rechner im Rechner keine Vision ist, dann lassen sich daraus die folgenden Erkenntnisse ableiten:

Diese Ressourcen müssen sich nun zwei Betriebssysteme teilen: MacOS, das direkt auf der Hardware installiert ist, und Windows, das wie eine Anwendung ausgeführt wird und sich der Illusion hingibt, dass es ebenfalls direkt auf der Hardware installiert wurde.

Physische Ressourcen
Damit das funktioniert, muss es ein Programm geben, das dafür sorgt, dass die virtuelle Maschine die physischen Ressourcen mitnutzen kann, es für sie aber so aussieht, als wären diese Ressourcen exklusiv vorhanden. Abbildung 3 zeigt, wie eine virtuelle Maschine ihre Umgebung sieht.

Sollten Sie beim Lesen an dieser Stelle einen Windows-Rechner zur Hand haben, geben Sie bitte über den Menüpunkt Ausführen im Startmenü (der Menüpunkt muss eventuell über die Eigenschaften des Startmenüs zur Anzeige aktiviert werden, Abb. 4) den Befehl mmc devmgmt.msc ein und vergleichen Sie die Ausgabe mit der Abbildung 3.

Kein Unterschied
Sie können – abgesehen von den genauen Ausstattungsmerkmalen (einen Golf gibt es ja auch mit unterschiedlichen Ausstattungsmerkmalen und Motorisierungen) – hier keinen Unterschied erkennen? Genau das ist der Trick der Virtualisierung: Eine virtuelle Maschine weiß nicht, dass sie nicht exklusiv auf einer Hardware installiert ist, die ihr diese Ausstattung zur Verfügung stellt.

Parallels und VMware Fusion
Die virtuelle Windows-Maschine hat alles, was auch eine physische Windows-Maschine benötigt und verwaltet (z. B. Prozessoren, COM-Ports, DVD/CD-Laufwerk etc.). Da es aber nur eine physische Maschine gibt – nämlich den Wirt (Host), also Ihr MacBook –, muss das oben erwähnte Programm dem Windows-Betriebssystem vortäuschen, dass es direkt auf der entsprechenden Hardware installiert ist. Die in der MacOS-Welt für diesen Zweck häufig verwendeten Programme heißen z. B. Parallels und VMware Fusion.

Gleiche Ressourcen
Es gibt allerdings auch physische Komponenten, bei denen sich eine gleichzeitige Nutzung durch alle virtuellen Gäste nicht ausschließt, da sonst der Rechner im Rechner nicht arbeiten kann. Dazu zählen z. B. Prozessoren, RAM oder Netzwerkkarten. Wie ist z. B. eine virtuelle Maschine erreichbar, bzw. kann sie auf ein Netzwerk zugreifen, wenn sie dafür nicht eine physische Netzwerkkarte des Wirtsystems nutzen kann? Je mehr virtuelle Maschinen auf einem Wirtsystem betrieben werden, umso mehr Maschinen konkurrieren um die gleichen Ressourcen. Das kann dazu führen, dass diese Ressourcen nicht mehr ausreichen und die virtuellen Maschinen langsam werden bzw. nicht mehr arbeitsfähig sind.

VMware Workstation
Abbildung 5 zeigt z. B. einen Windows Server 2008 R2, der als virtuelle Maschine auf einem Windows-7-Rechner als Wirt gestartet wird. Insofern ist die oben gestellte Frage auch schon beantwortet. Ein Beispiel für ein solches Programm ist VMware Workstation.

Eine wichtige Erkenntnis, die sich aber nicht unmittelbar aus unserem Beispiel erschließt, ist die Option, eine physische Maschine in eine virtuelle Maschine zu überführen. So existieren z. B. Tools, die Ihren lokalen Rechner oder einen über ein Netzwerk erreichbaren Rechner in eine virtuelle Maschine konvertieren können, sodass die ursprünglich physische Maschine nun als Rechner im Rechner arbeiten kann (Abb. 6).

In die Jahre gekommen
Wenn nach der Abkündigung durch Microsoft nicht nur das XP-Betriebssystem, sondern auch die entsprechende Hardware Ihres Rechners in die Jahre gekommen ist, können Sie diesen Rechner zu einer virtuellen Maschine konvertieren und auf Ihrem neuen Rechner Windows 8 laufen lassen. Das kann durchaus unterschiedlich motiviert sein: Vielleicht hat es ja nur etwas mit Nostalgie zu tun, oder es ist Ihr persönliches kleines Legacy-Migration-Projekt und rettet lieb gewonnene Programme, die von Windows 8 nicht mehr unterstützt werden. Mit solchen Überlegungen lösen wir uns aber zum ersten Mal von der Motivierung des Themas auf der Basis der Faszination der Technik, denn das Thema Legacy Migration ist längst schon in vielen Unternehmen angekommen und zur Herausforderung geworden.

Lizenz benötigt
Abschließend ist es wichtig zu verstehen, dass eine virtuelle Maschine formal deshalb als virtuell zu bezeichnen ist, weil sie nicht als physische Maschine existiert. Das heißt aber nicht, dass Sie für eine virtuelle Maschine das gewünschte Betriebssystem und gegebenenfalls auch die dafür erforderliche Lizenz nicht benötigen: Das Programm, das den Betrieb von virtuellen Maschinen auf einem Wirt ermöglicht, bringt das Betriebssystem seiner Gäste nicht mit. Die Windows-Server-2008-DVD müssen Sie folglich erworben haben, um auch mal ein Serverbetriebssystem als Gast auf Ihrem Rechner begrüßen zu dürfen.

Das zur Veranschaulichung des Themas Virtualisierung gewählte Beispiel entstammt zugegebenermaßen dem Consumer-Umfeld, wobei die darüber gewonnenen Erkenntnisse aber durchaus hilfreich sind, um zu verstehen, warum dieses Thema eine enorme Bedeutung bekommen hat und viele innovative Entwicklungen, wie z. B. Cloud Services, daran gekoppelt sind. Allerdings sollte es an dieser Stelle nicht unerwähnt bleiben, dass die Virtualisierung von Rechnern (Insider sprechen hier von Blech) heute schon als Commodity zu bezeichnen ist. Das heißt, die Technologie ist etabliert, eine mögliche Business Transformation ist erfolgt und das Differenzierungspotenzial ist ausgeschöpft.

Die IT hat die in den letzten Jahren an sie herangetragenen Anforderungen oft mit einem Aufbau von dedizierten und isolierten Lösungen (Silos) beantwortet. Das heißt, zwischen z. B. Anwendung und Server existiert eine 1:1-Zuordnung. Diese Silo-Lösungen (Anwendung, Server, Speicher, Netzwerk etc.) können mit Blick auf die erforderlichen Ressourcen natürlich sehr gut auf eine dedizierte Anforderung abgestimmt werden, aber sie haben auch entscheidende Nachteile:

Konsolidierung und Zentralisierung
Insofern kann man in so einem Umfeld auch von tickenden Zeitbomben sprechen. Die Virtualisierung bietet für die genannten Probleme passende Lösungen: Sie ermöglicht eine Konsolidierung und Zentralisierung der ursprünglich verteilten Systeme, sie führt zu einer besseren Auslastung der Ressourcen, vereinfacht die Administration und öffnet die Tür in Richtung Standardisierung und Automatisierung.

Viele Anwendungen sind heute sehr komplex aufgebaut. Man spricht in diesem Zusammenhang oft auch von einer 3-Tier- bzw. 3-Schichten-Architektur (Abb. 7).

Höherer Bedarf an physischen Servern
Ein Anwender greift über einen Browser auf einen Webserver zu, der ihm letztendlich nur die Bedienoberfläche der Anwendung zur Verfügung stellt (z. B. seine SAP-Oberfläche), wobei diese wiederum ihre Daten in einer Datenbank verwaltet. Diese Architektur hat ihre Vorteile (z. B. muss der Client mit Blick auf die Anwendung keine dedizierten Softwaremodule besitzen) und damit aus konzeptioneller Sicht ihre Daseinsberechtigung. Sie führt aber letztendlich auch zu einem höheren Bedarf an physischen Servern. Auch hier gibt die Virtualisierung die passenden Antworten.

Halten wir kurz die grundlegenden Erkenntnisse dieser ersten Etappe fest:

Die beiden vorangegangenen Beispiele haben schon implizit gezeigt, dass ein spezielles Programm erforderlich ist, um virtuelle Maschinen „betreiben” zu können. Im ersten Beispiel wurde z. B. eine Management-Konsole (VMware vSphere) zur Verwaltung von virtuellen Maschinen gezeigt, während im zweiten Beispiel eine auf einem MacBook installierte Software (VMware Fusion) verwendet wurde, um eine virtuelle Windows-7-Maschine starten zu können. Letztgenannte Lösung bleibt im weiteren Verlauf allerdings unberücksichtigt, da es sich dabei um eine dedizierte Lösung im Consumer-Umfeld handelt.

Zwei Lösungsvarianten
Wenn man virtuelle Maschinen auf einem Desktop-Rechner oder auf physischen Servern betreiben möchte, benötigt man einen sogenannten Hypervisor (z. B. VMware vSphere, Citrix Xen, Red Hat KVM oder Microsoft Hyper-V). Der Hypervisor (Abb. 15) ist dafür zuständig, den virtuellen Maschinen und deren jeweiligem Betriebssystem den Eindruck zu vermitteln, dass sie wie sonst üblich direkt und exklusiv auf einem physischen System installiert wurden. Dabei sind grundsätzlich zwei Lösungsvarianten zu unterscheiden:

Die in den Beispielen für MacOS und Windows aufgezeigten Programme zur Virtualisierung sind somit als Hypervisor vom Typ 2 zu bezeichnen. Hier wird für die Installation des Hypervisors ein vollwertiges Betriebssystem (z. B. MacOS oder Windows) benötigt. Ein Hypervisor vom Typ 1 wird dagegen direkt auf der Hardware installiert. Sollten Sie schon einmal selbst über eine CD/DVD ein Betriebssystem auf Ihrem Rechner installiert haben, dann ist das durchaus vergleichbar: Die CD/DVD in das entsprechende Laufwerk legen, den Rechner booten und damit die Installationsroutine einleiten.

Host
Der Hypervisor verwaltet die Ressourcen des physischen Rechners (Host) und stellt sie den virtuellen Maschinen (Gast) zur Verfügung. Ein Gast (d. h. eine virtuelle Maschine) hat in der Regel keinen direkten Zugriff auf die Hardware des Host-Systems. Vielmehr emuliert das Host-System Komponenten wie z. B. CPU, BIOS, Festplattenspeicher, RAM, CD-/DVD-Laufwerk, USB-Anschlüsse, Netzwerkkarten etc., ohne dass ein Gastsystem diese Täuschung bemerkt. Dies ist in Abbildung 15 stark vereinfacht dargestellt.

Virtualisierungsschicht
An dieser Stelle reicht es aus, wenn Sie den Hypervisor als Virtualisierungsschicht verstehen, die über die Hardware gelegt wird und somit letztendlich auch eine Entkopplung selbiger von den Gästen und damit von deren Betriebssystemen, Anwendungen und Diensten ermöglicht. Virtualisierung bedeutet in diesem Fall, dass der Hypervisor die Ressourcen des physischen Rechners (Host) den Gästen (virtuellen Maschinen) anteilig zur Verfügung stellt.

Wenn eine virtuelle Maschine eingeschaltet wird, setzt der beschriebene Bootvorgang ein. Dabei gaukelt der Hypervisor der virtuellen Maschine aber nur eine (oder mehrere) CPUs eines bestimmten Typs und einer bestimmten Generation vor, wobei die eigentlichen von der Maschine benötigten CPU-Zyklen von den CPU-Ressourcen der physischen Maschine abgearbeitet werden. Da mehrere virtuelle Maschinen letztendlich die Ressourcen des Host-Systems konsumieren, kann man hier durchaus von einer Konsolidierung sprechen.

Kunst der Täuschung
Der Hypervisor beherrscht die Kunst der Täuschung extrem gut und kann bei seinen Gästen somit auch z. B. die Illusion des Besitzes von mehreren CPUs, mehreren Netzwerkkarten, oder mehreren CD-/DVD-Laufwerken erzeugen (kurze Randbemerkung: In seiner Trickkiste sind aber ohne Umwege über z. B. die USB-Schnittstelle keine ISDN-Karten oder analoge Modems zu finden).

In Abbildung 16 wird der Typ der Festplatte 1 mit Thin Provision angegeben. Dabei handelt es sich um eine Täuschung mit betrügerischen Absichten. Die virtuelle Maschine bekommt eine Festplatte mit z. B. einer Gesamtkapazität von 100 GB vorgegaukelt. Tatsächlich ist das zugehörige File auf dem Wirtsystem aber nur so groß, wie es der Datenbestand der virtuellen Maschine aktuell erfordert. Somit schont das Wirtsystem die Ressourcen der von ihm verwalteten Festplatten. Schreibt der Gast weitere Daten auf seine Festplatte, dann passt der Hypervisor die Kapazität bis zur zugesagten Kapazität schrittweise an.

Ausfall eines Wirtsystems
Einer virtuellen Maschine wird ihr Betriebssystem über eine virtuelle Festplatte zur Verfügung gestellt. Wir wissen natürlich schon, dass es sich dabei um ein File (oder eine Ansammlung von Files) handelt, dessen Inhalt der virtuellen Maschine als Inhalt einer Festplatte verkauft wird. Die zu einer Virtuellen Maschine gehörenden Files liegen – zumindest so lange, wie wir noch keine bessere Idee haben – auf den physischen Platten des Host-Systems. Dem aufmerksamen Leser wird nicht entgangen sein, dass wir nun zwar eine Konsolidierung einer zuvor erforderlichen Anzahl von physischen Servern auf einem entsprechend dimensionierten Gastsystem erreicht haben (was für viele Firmen schon von unschätzbarem Wert ist), aber die zuvor zitierte Entkopplung von Hard- und Software ist so natürlich nur schwer zu motivieren: Fällt das Wirtsystem aus, fallen auch alle Gäste aus. Zwischen Blech (= Hardware) und Anwendung besteht heute nicht mehr ein 1:1-, sondern ein 1:N-Verhältnis. Infolgedessen kann der Ausfall eines Wirtsystems katastrophale Auswirkungen haben. Ist die Konsolidierung somit zwar ganz im Sinne einer Green IT, aber aus z. B. dem Blickwinkel des Disaster Recovery (DR) ein unbrauchbares Instrument? Bevor wir diese Frage beantworten können, brauchen wir noch weitere Informationen.

Eine virtuelle Maschine benötigt natürlich auch einen Zugang zum Netzwerk und damit zur „realen” Welt. Die Virtualisierungsschicht stellt ihr dafür eine virtuelle Netzwerkkarte zur Verfügung, die mit einem Switch (eine Netzwerk-Infrastrukturkomponente) verbunden wird, der wiederum ebenfalls Bestandteil der Virtualisierungsschicht ist. Dieser Switch hat direkten Zugriff auf die physischen Netzwerkkarten des Wirtsystems.

Virtuelles Patchen
In Abbildung 17 ist der Steckbrief unseres Server001 zu sehen, über den die dem virtuellen Server zugeordneten Ressourcen administriert werden können. Hier ist auch die Zuordnung der virtuellen Maschine zu einem Port des Switch der Virtualisierungsschicht möglich. Diese Zuordnung kann durchaus als virtuelles Patchen bezeichnet werden. Physische Kabel sind dafür natürlich nicht erforderlich.

Da letztendlich alle Datenströme von und zu den virtuellen Gästen des Wirtsystems über die physischen Karten des Wirtsystems geführt werden, ist sicherlich zu verstehen, warum hier 10-Gigabit-Ethernet-Karten mittlerweile eine strategische Entscheidung sind.

Die Bereitstellung einer virtuellen Maschine ist im Vergleich zur Bereitstellung einer physischen Maschine einfacher und kann durchaus auch automatisiert werden. In Abbildung 18 werden die zur Bereitstellung einer virtuellen Maschine notwendigen Schritte gezeigt.

Der Schritt 4 zeigt noch einmal, dass die Virtualisierungsschicht nicht das Betriebssystem seiner Gäste zur Verfügung stellt.

Dedizierte Verwaltungstools
Die vorangegangenen Beispiele haben schon implizit gezeigt, dass die Hersteller für Ihre Lösungen auch dedizierte Verwaltungstools zur Verfügung stellen. Bei VMware beispielsweise nennt sich dieses Tool vCenter. Zum Aufbau einer virtuellen Umgebung sind aus Gründen der Redundanz mindestens zwei physische Server erforderlich. Die Virtualisierungsschicht sorgt dabei nun in Verbindung mit dem Verwaltungstool dafür, dass die virtuellen Maschinen „schwimmend verlegt” werden können. Das heißt, es ist – solange das Wirtsystem die entsprechenden Ressourcen hat – egal, auf welchem Wirtsystem eine neu erzeugte virtuelle Maschine ausgeführt wird: Das Verwaltungssystem verwaltet die Ressourcen aller verfügbaren Wirtsysteme als eine Art Ressourcenpool und weiß somit, welcher Wirt aktuell noch welche Ressourcen zur Verfügung stellen kann.

Die folgenden Aufgaben werden in der Regel von einem Verwaltungstool für virtuelle Maschinen übernommen:

Halten wir wiederum kurz die neu gewonnenen Erkenntnisse aus dieser Etappe fest:

Runtime
Einer virtuellen Maschine kann es letztendlich egal sein, auf welchem Gastsystem die für ihren Betrieb erforderlichen Prozesse (Runtime) ausgeführt werden, zumal ihr jedes Gastsystem die gleiche Hardware zur Verfügung stellt. In Abbildung 19 wird ein Exchange Server (Mailserver) als virtueller Gast auf dem Wirtsystem Host A ausgeführt. Soll die Runtime des Exchange Server auf Host B umgezogen werden, dann ist das – wenn Host B die benötigten Ressourcen bieten kann – erst einmal durchaus vorstellbar.

Migration
Den Umzug einer virtuellen Maschine auf ein neues Wirtsystem (auf einen neuen Host) bezeichnet man oft auch als Migration, wie in Abbildung 19 und 20 dargestellt. Die technische Möglichkeit an sich sagt noch nichts darüber aus, warum diese Option ein echter Mehrwert ist. Der Grund für den Umzug einer virtuellen Maschine könnte z. B. darin bestehen, dass das neue Wirtsystem der virtuellen Maschine mehr CPU- und RAM-Ressourcen zur Verfügung stellen kann. Es kann aber auch sein, dass der Host A im Rahmen des Hardware-Lifecycles getauscht werden muss (auch bei der Virtualisierung gibt es eine Abhängigkeit von der Generation der Hardware des Wirtsystems). Dazu müssen zunächst alle von ihm beherbergten Gäste migriert werden. Da die migrierten Maschinen auch weiterhin laufen und ihre Dienste zur Verfügung stellen können, kann der Tausch der Hardware unterbrechungsfrei erfolgen. Sobald die neue Hardware eingebunden ist, können die Gäste zurückkehren.

Bei der Migration einer virtuellen Maschine muss diese nicht ausgeschaltet werden. Das heißt, die Dienste der Maschine sind auch während der Migration verfügbar.

Sie haben sicherlich schon erkannt, dass wir auf der Basis der aktuellen Informationen beim Thema Migration sehr schnell in eine Sackgasse laufen: In Abbildung 21 ist zu sehen, dass zunächst Host A für die Runtime des virtuellen Exchange Servers verantwortlich ist. Sein lokaler Speicher (lokale Festplatte) beherbergt die Festplatte des virtuellen Servers, von der wir natürlich wissen, dass sie aus einem File oder einer Ansammlung von Files besteht. Soll nach der Migration Host B für die Runtime des virtuellen Exchange Servers zuständig sein, dann benötigt seine Virtualisierungsschicht natürlich auch den Zugriff auf die Festplatte des virtuellen Exchange Servers. Diese befindet sich aber auf dem lokalen Speicher von Host A, weshalb ein direkter Zugriff von Host B nicht möglich ist.

Shared-Storage-Lösung
Dieses Problem lässt sich lösen, indem man den Speicher zur Beherbergung der Festplatten der virtuellen Maschinen allen Wirtsystemen zentral zur Verfügung stellt. In diesem Fall spricht man von einer Shared-Storage-Lösung. Diese ist eine wesentliche Komponente der Virtualisierung, da diese sonst nicht alle ihre Vorteile ausspielen kann. Abbildung 21 zeigt vereinfacht den Aufbau einer solchen Lösung.

Wenn in diesem Setup der virtuelle Exchange Server erneut migriert werden soll, kann nun auch die Virtualisierungsschicht von Host B die Steuerung des Zugriffs auf die Festplatte des virtuellen Servers übernehmen, denn das entsprechende File wird hier über ein zentrales Storage-System zur Verfügung gestellt. Die Wirtsysteme Host A und Host B können dieses Storage-System über ein Netzwerk erreichen, das an dieser Stelle noch nicht genauer spezifiziert werden soll.

Damit auch in diesem Kontext die Mehrwerte der Virtualisierung transparent werden, ist in Abbildung 22 die Möglichkeit der Migration von virtuellen Maschinen stark vereinfacht dargestellt.

Verfügbarkeit erhöhen
Es lässt sich sicherlich erkennen, dass hier die Basis geschaffen wurde, um die Verfügbarkeit von virtuellen Maschinen und damit – was letztendlich auch für den Betrieb und die Reputation der IT maßgebend sein kann – die Verfügbarkeit von Anwendungen und Diensten zu erhöhen. Die Migration einer virtuellen Maschine kann manuell ausgelöst werden oder auch automatisiert gesteuert sein. Wenn z. B. ein Wirtsystem einer Anwendung nicht mehr die benötigten Ressourcen zur Verfügung stellen kann oder eine Störung meldet, kann dies automatisiert einen Umzug der virtuellen Maschine auf einen anderen Host auslösen.

In Verbindung mit einer solchen Automatisierung sind auch Regelungen möglich, die z. B. ausschließen, dass zwei virtuelle Maschinen A und B auf dem gleichen Wirtsystem ausgeführt werden. Das ist beispielsweise dann wichtig, wenn die virtuelle Maschine B das Backup für die virtuelle Maschine A ist.

Public Cloud
Wenn man einen sehr einfachen Vergleich bemühen möchte, dann sind virtuelle Maschinen schwimmend verlegt. Das heißt, sie können mithilfe des Hypervisors über mehrere Host-Systeme hinweg verschoben werden. Diese Bewegung kann zwischen den eigenen Host-Systemen erfolgen, oder die Maschinen können – was mit Blick auf die genaue technische Umsetzung wiederum eine sehr vereinfachte Betrachtungsweise ist – auch in die Public Cloud verschoben werden.

Das stark vereinfachte Bild zur Veranschaulichung der Migration zeigt aber auch, dass eine virtuelle Maschine auf jedem Wirtsystem, auf dem sie ausgeführt wird, den gleichen Netzwerkzugang bekommen muss. War die Maschine auf dem Wirtsystem A im Netzbereich X (für den technisch versierten Leser: VLAN X, IP-Netz X), muss ihr auch das Wirtsystem B den Zugang in den Netzbereich X ermöglichen. Insofern muss es eine enge Abstimmung zwischen den für die Virtualisierung zuständigen Administratoren und den Netzwerkadministrationen geben. Kommt es hier zu Unstimmigkeiten, kann es passieren, dass eine virtuelle Maschine bei der Migration ins Abseits (in ein falsches Netz) bewegt wird und deshalb ihre Anwendungen und Dienste nicht mehr erreichbar sind.

Große Bedeutung
Im Rahmen der Virtualisierung wird dem Thema Storage eine große Bedeutung zugesprochen. Wir können es bei der einfachen Vorstellung belassen, dass auf diesem System die Festplatten unserer virtuellen Systeme lagern. Fällt das Storage-System aus oder ist es für die Wirtsysteme nicht mehr erreichbar, dann ist das – wenn man nicht mit Netz und doppeltem Boden arbeitet – natürlich ein GAU und dürfte in einigen Umgebungen auch deren Existenz gefährden.

Zugriffsvarianten
Abbildung 23 zeigt, dass moderne Storage-Systeme auch unterschiedliche Zugriffsvarianten unterstützen sollten. Dabei wird hier aber der Zugriff auf CIFS und NFS beschränkt. CIFS kommt zum Einsatz, wenn Sie etwas von oder zu einem Netzwerklaufwerk kopieren. In Abbildung 23 ist das über den Aufruf eines Netzwerk-Shares über den Explorer (\\Fileserver01\daten\Backup) dargestellt. Der virtuelle Server nutzt in unserem Beispiel also diese Zugriffsvariante für seine Datensicherung. Das Wirtsystem nutzt NFS, um auf die Festplatte des virtuellen Servers zugreifen zu können. Backups und Festplatte des virtuellen Rechners lagern im Shared Storage.

Um an dieser Stelle technisch nicht zu unscharf zu werden, sei noch erwähnt, dass der Zugriff einer virtuellen Maschine auf ihre im Storage-System gelagerte Festplatte auch z. B. via iSCSC, FiberChannel, FCoE oder FCoIP erfolgen kann.

Hohe Erwartungshaltung
Die Virtualisierung weckt auch mit Blick auf das Netzwerk eine hohe Erwartungshaltung. Um das nachvollziehen zu können, stellen Sie sich bitte kurz vor, was Sie – mal abgesehen vom eventuellen Verlust der Garantieleistung – erwartet, wenn Sie Ihren Rechner öffnen. Erkennbar sollten zumindest Festplatte und ein daran angeschlossenes breites, flaches Kabel sein. Über dieses Kabel werden (gesteuert durch einen Controller) die Daten von und zu der Festplatte Ihres Rechners transportiert (Input/Output: I/O). Die Kommunikation zwischen Controller und Festplatte erfolgt über sogenannte SCSI-Befehle.

Das flache, breite Kabel wird als SCSI-Kabel bezeichnet. Es ist in Ihrem Rechner wohlbehütet, aber Sie können sich sicher vorstellen, was passiert, wenn Sie dieses Kabel durchschneiden, zumal die Festplatte auch das Betriebssystem Ihres Rechners beherbergt. Eine unwichtige Erkenntnis? Nein, eine Erkenntnis, die uns motivieren kann, warum auch dem Thema Netzwerk eine große Bedeutung zugesprochen werden muss.

Netzwerk zwischen Wirt- und Speichersystem
Wir haben gesehen, dass zum Erreichen der maximalen Wertschöpfung der Virtualisierung die Wirtsysteme u. a. auf ein zentrales Speichersystem zugreifen müssen. Dafür bietet sich ein Netzwerk zwischen Wirt- und Speichersystem an. Das SCSI-Kabel wird also durch ein Netzwerk ersetzt (s. Abb. 24). Vermutlich werden Sie nach kurzer Bedenkzeit nicht mehr von „wohlbehütet” sprechen wollen, wenn die Kommunikation zwischen dem Controller der virtuellen Maschine und ihrer Festplatte nun nicht mehr über ein SCSI-Kabel, sondern über ein Netzwerk geführt wird. Diese Kommunikation muss nämlich schnell und verlustfrei erfolgen – eine Anforderung, der nicht alle Netzwerke gerecht werden.

Durch die Virtualisierung werden an die Themen Storage, Virtualisierung und Netzwerk nicht nur hohe Anforderungen gestellt, vielmehr können diese Themen auch nicht mehr völlig unabhängig voneinander betrachtet und geplant werden.

Holistisches Architekturmodell
Man kann an dieser Stelle durchaus von einem holistischen Architekturmodell (s. Abb. 25) sprechen, wobei diese Erkenntnis für viele Unternehmen heute durchaus als strategisch zu bezeichnen ist. Sind die einzelnen Themen nicht optimal aufeinander abgestimmt, kann die Virtualisierung ihre Vorteile nicht ausspielen. So kann es z. B. sein, dass die über eine virtuelle Maschine bereitgestellten Anwendungen und Dienste vom Endanwender als langsam bewertet werden. Dies kann z. B. auf unzureichende Ressourcen des Host-Systems, hohe Latenzzeiten des Netzwerks beim Zugriff auf die virtuelle Festplatte, auf unzureichende Storage Performance (IOPS: Input/Output Operations per Second) oder auf einen falschen Treiber in der Virtualisierung zurückzuführen sein. So vielfältig die Gründe für dieses Problem auch sein können, dem Anwender ist das egal, und die Vorteile der Virtualisierung werden dann oft schnell infrage gestellt.

Dimension des Rechenzentrums
Heute vereinen moderne Rechenzentren die bereits genannten Themen Server (Hosts), Virtualisierung, Storage und Netzwerk. Das heißt, die Virtualisierung ist ein strategischer Aspekt der zu beobachtenden Entwicklung in Richtung zentraler, schneller Bereitstellung von Anwendungen und Diensten. Dabei spielt die Dimension des Rechenzentrums keine Rolle: Ein halb gefülltes 19-Zoll-Rack kann heute durchaus das IT-Rückgrat eines Unternehmens bilden.

Mehrwerte der Virtualisierung
Prinzipiell differenzieren sich IT-Unternehmen über ihre IT, was aber auf andere Unternehmen so nicht zutrifft. Das heißt, die meisten Unternehmen differenzieren sich über ihre Dienste und ihre Dienstleistungen (s. Abb. 26), die heute in der Regel IT-gestützt sind. Insofern ist die Virtualisierung durchaus als ein wichtiger Bestandteil einer IT-Strategie zu sehen. Ungeachtet dieser pauschalen Aussage ist es dennoch wichtig zu bewerten, welche Mehrwerte die Virtualisierung fallbezogen bieten kann und welche Key Performance Indicators (KPIs) diese Mehrwerte messbar machen. Zeitgleich muss den Entscheidern aber auch klar sein, dass der Schritt in Richtung Virtualisierung auch Investitionen in die Themen Storage und Netzwerk erforderlich machen kann.

Komplex
Da mit Blick auf das Gesamtbild die Thematik durchaus als komplex bezeichnet werden darf, tritt bei vielen Unternehmen neben der Frage nach den Mehrwerten der Virtualisierung noch eine weitere Frage in den Vordergrund: Ist die für den Betrieb erforderliche technische Expertise im Server-, Storage-, Virtualisierungs- und Netzwerkumfeld verfügbar? Während die Antwort auf die erste Frage in den meisten Fällen positiv ausfällt, ist die zweite Frage oft mit einem Nein zu beantworten. Insofern ist es sicherlich verständlich, dass in diesem Umfeld Lösungen gefordert sind, die die Komplexität verbergen und dem Administrator den Betrieb der Lösung über den kompletten Lifecycle (d. h. Feststellung der Anforderungen, Planung, Design, Konfiguration, Betrieb und Optimierung) ermöglichen.

Wiederherstellung der Daten
Das Thema Backup ist nicht erst mit der Virtualisierung aufgekommen. Daten sind ein wertvolles Gut und somit ist die Notwendigkeit einer Datensicherung formal erst einmal nicht dediziert mit der Umgebung – d. h. physisch oder virtuell – verknüpft. Gleiches gilt auch für den nicht minder wichtigen Prozess zur Wiederherstellung der Daten (Restore/Recovery) und die damit verknüpften Anforderungen. Das heißt, wie lange darf es maximal dauern, bis die Daten wieder zur Verfügung stehen (RTO: Recovery Time Objective) und welcher Datenverlust in Minuten, Stunden etc. ist tolerierbar (Recovery Point Objective)? Natürlich sind die individuellen Anforderungen hier unterschiedlich ausgeprägt.

Abbildung 27 verdeutlicht noch einmal den Unterschied zwischen physischer und virtueller Welt, woraus sich für die virtuelle Welt letztendlich auch dezidierte Anforderungen an die Themen Backup und Recovery ableiten lassen.

Unterschied
Ein offensichtlicher Unterschied zu einer Backup-Lösung für physische Server ist die Tatsache, dass man eine Integration der Backup-Lösung in die virtuelle Umgebung erwartet. Dazu zählt z. B. die Kommunikation mit dem Hypervisor und/oder der Management-Konsole für die Virtualisierung, mit dem Storage-System und mit einem entsprechenden Smart Agent in der virtuellen Maschine. Die Steuerung erfolgt über entsprechende Schnittstellen (API: Application Programming Interface), die von den Herstellern zur Verfügung gestellt werden. So ist es z. B. sinnvoll, dass beim Recovery einer virtuellen Maschine die Anweisung zur Wiederherstellung vom Backup-Tool an die Management-Konsole der Virtualisierung übergeben wird, da diese letztendlich auf die Bereitstellung einer (neuen) virtuellen Maschine spezialisiert ist (s. Abb. 28).

Agenten in den VMs
Klassische Backup-Tools verwenden sogenannte Agenten, die für das entsprechende Betriebssystem einer physischen Maschine installiert werden und unter Aufsicht durch die Management-Konsole der Backup-Lösung für die Steuerung von Backup & Recovery zuständig sind. Diese Agenten können aus technischer Sicht auch auf einer virtuellen Maschine (VM) installiert sein. Da auf einem Host aber viele VMs konsolidiert sind, kann diese Lösung z. B. zu einer hohen Auslastung der Ressourcen des Host-Systems und des Storage-Systems führen, was letztendlich eine negative Auswirkung auf alle Gäste hat. Das spricht aber nicht prinzipiell gegen einen Einsatz von Agenten in den VMs. Vielmehr bieten einige Hersteller von Backup-Lösungen sogenannte Smart Agents an, die an die Virtualisierung und ihre Anforderungen angepasst sind.

Crash-Consistent Images
Vielleicht erinnern Sie sich noch an den Vorschlag, Ihre virtuelle Maschine, deren Datenbestand, Dienste und Anwendungen einfach durch eine Kopie des Verzeichnisses der virtuellen Maschine zu sichern. Wenn dabei die Maschine ausgeschaltet ist, haben Sie einen definierten Zustand der Maschine. Erfolgt die Sicherung bei eingeschalteter Maschine, können Daten verloren gehen, da z. B. zum Zeitpunkt des Kopiervorgangs noch nicht alle Daten gespeichert wurden. Unabhängig davon kann man hier von der Erstellung eines sogenannten Image (Abbild) sprechen, denn wie bei einem konventionellen Image einer Partition oder Festplatte ermöglicht Ihnen das Image Ihrer VM (also der gesicherten Files), die Maschine wieder mit allen Daten, Diensten und Anwendungen bereitzustellen. Auch in größeren Umgebungen ist diese Variante eines Backups durchaus ein valides Konzept, das – ohne weitere Maßnahmen – aber zu sogenannten Crash-Consistent Images führt. Das heißt, diese Images sind mit dem Zustand einer Maschine z. B. nach einem plötzlichen Stromausfall (Hard Reset) zu vergleichen. Während viele Betriebssysteme mit einem Hard Reset umgehen können, ist das bei Anwendungen wie z. B. einer Datenbank nicht der Fall. Hier kann es sein, dass die Daten nicht mehr konsistent sind und eine Anwendung nicht mehr mit ihnen arbeiten kann. Insofern wäre es wichtig, dass das Backup-Tool diese Anwendungen kennt und dafür sorgen kann, dass die Daten konsistent sind, d. h. ein sogenanntes Application-Consistent Image bereitgestellt wird.

Anforderungen
An dieser Stelle soll das Thema Backup & Recovery technisch nicht weiter vertieft werden. Es ist nur wichtig zu verstehen, dass dieses Thema im Kontext der heutigen Anforderungen der Unternehmen an die Verfügbarkeit ihrer Daten, Dienste und Anwendungen sehr wichtig ist und eine entsprechende Lösung die Anforderungen – wie z. B. die Einhaltung einer RPO-Vorgabe – erfüllen muss. Dabei sollten bei der Auswahl einer passenden Lösung u. a. die folgenden Anforderungen berücksichtigt werden:

Virenscanner
Auch die Bedeutung des Themas Sicherheit ist zunächst unabhängig von der Umgebung (physisch oder virtuell). Wie auch beim Thema Backup existieren hier Sicherheitsanforderungen, die sich aus der Virtualisierung ableiten, und Sicherheitsanforderungen, die allgemeingültig sind. So kann es durchaus sinnvoll sein, dass virtuelle Maschinen über einen Virenscanner verfügen. Wie auch schon der Backup-Agent, so sollte auch eine Virenscanner-Lösung an die Gegebenheiten einer virtuellen Umgebung angepasst sein. Wenn z. B. die Virenscanner der von einem Host-System beherbergten virtuellen Maschinen zeitgleich einen Scan starten oder Signaturen nachladen, kann es auch hier auf dem Host-System und beim Zugriff auf die virtuellen Festplatten (also beim Zugriff auf das Storage-System) zu Ressourcenengpässen kommen. Sie kennen das sicherlich: Wenn Sie mit ihrem Rechner arbeiten und der Virenscanner plötzlich einen vollen Scan des Rechners startet, kann das Arbeiten durchaus sehr zähflüssig werden.

Trennung logischer Einheiten
Das Thema Sicherheit gab anfangs durchaus Anlass zu Konflikten zwischen den Administratoren von virtuellen Umgebungen und den für das Netzwerk bzw. die Sicherheit zuständigen Administratoren. Keiner kannte die Welt des anderen, was zwangsläufig an den Stellen zu Diskussionen führte, wo eine Brücke zwischen Virtualisierung und Netzwerk zu schlagen ist. So werden z. B. Server, die über das Internet erreichbar sein müssen, in einer durch eine Firewall abgekoppelten Demilitarized Zone (DMZ) betrieben. Soll ein solcher Server nun aber als virtuelle Maschine zur Verfügung gestellt werden, benötigt diese VM eine Verbindung zur physischen DMZ. Da virtuelle Maschinen aber im Rechenzentrum vorgehalten werden, muss es eine Verbindung zwischen dem Rechenzentrum und der DMZ – also einem prinzipiell als unsicher eingestuften Netz – geben. Hier ist es deshalb wichtig zu wissen, dass es Technologien gibt, die auf den unterschiedlichen Ebenen eine strikte Trennung von logischen Einheiten ermöglichen. Somit führt unser Beispiel nicht zwangsläufig dazu, dass die Systeme in der physischen DMZ aufgrund ihrer Kopplung mit einer virtuellen DMZ einen direkten Zugriff auf andere virtuelle Maschinen haben. Abbildung 29 zeigt, welche Technologien die gewünschte Trennung auf der Ebene der virtuellen Maschinen, des Netzwerks und des Storage-Systems ermöglichen können. Diese Thematik soll an dieser Stelle aber nicht weiter ausgeführt werden.

Gleiche Instrumente
Stellt ein virtueller Server bestimmte Dienste und Anwendungen zur Verfügung, sind diese den gleichen Risiken ausgesetzt, die auch existieren, wenn diese Dienste und Anwendungen auf einem physischen Server vorgehalten werden. Insofern müssen die Betriebssysteme, die Dienste und Anwendungen der virtuellen Server mithilfe der gleichen Instrumente geschützt werden, wie sie auch für physische Server existieren und eingesetzt werden. Als Beispiel sind hier Firewall-Systeme, Proxy-Lösungen oder auch Intrusion-Prevention-Systeme (IPS) zu nennen. Natürlich müssen diese Lösungen auch im Kontext einer virtuellen Umgebung geplant werden. So führt z. B. die zentrale Bereitstellung der virtuellen Maschinen im Rechenzentrum letztendlich auch zu einer Bündelung von Datenströmen, sodass z. B. eine den virtuellen Maschinen vorgeschaltete Firewall diese Datenströme bewältigen können muss und letztendlich nicht zur Bremse werden darf.

Auch am Ende dieses Kapitels wollen wir ein weiteres Fazit ziehen:

Display-Protokoll
Wenn Sie mit einem virtuellen Desktop arbeiten, existiert Ihr Rechner als virtuelle Maschine in einem Rechenzentrum und teilt sich dort mit vielen anderen virtuellen Desktops die über die physischen Server (Host-Systeme) bereitgestellten Ressourcen. Primär werden Ihnen die Tastatur, die Maus und der Bildschirminhalt Ihres virtuellen Rechners über das Netzwerk (d. h. quasi abgesetzt) an einem VDI-Client zur Verfügung gestellt. Wenn Sie z. B. ein Textdokument bearbeiten und über die Tastatur ein Zeichen eingeben, dann wird dieses vom VDI-Client über das Netzwerk zum virtuellen Rechner geschickt. Dort wird die Eingabe verarbeitet und das Zeichen auf dem Bildschirm dargestellt. Da der Bildschirm in diesem Fall aber über das Netzwerk abgesetzt ist, muss die Ausgabe erst noch über das Netzwerk an den Bildschirm Ihres VDI-Clients geschickt werden. Deshalb spricht man bei der Kommunikation zwischen virtuellem Desktop und VDI-Client auch von einem Display-Protokoll.

Abbild der Anwendung
Bei der Virtualisierung von Anwendungen wird dem Anwender ausgehend vom Rechenzentrum und über das Netzwerk nicht ein kompletter Desktop zur Verfügung gestellt. Vielmehr wird ihm auf seinem Monitor quasi ein Abbild der Anwendung zur Verfügung gestellt. Damit ist die Verwendung einer Anwendung vom lokalen Rechner- und Betriebssystem des Anwenders entkoppelt, d. h., sie kann prinzipiell über jedes Client-System bedient werden. Dabei können dem Anwender die ihm zur Verfügung stehenden Anwendungen bei einem Rechner mit z. B. Windows-Betriebssystem im Startmenü angezeigt werden. Der Anwender weiß also nicht, dass er beim Starten einer Anwendung nur das Abbild der Anwendung erhält, die letztendlich an zentraler Stelle im Rechenzentrum installiert ist und gepflegt wird.

Etablierte Technologie
Der Einstieg in die Welt der Virtualisierung führte uns aus Gründen der Didaktik über das Consumer-Umfeld hin zur Virtualisierung von Servern, die heute als etablierte Technologie gilt. Das Thema hat sich weiterentwickelt, sodass man den Anwendern heute einen kompletten Desktop oder auch dediziert nur die benötigten Anwendungen virtuell zur Verfügung stellen kann. Damit reduzieren sich z. B. die Anforderungen an die Hardware, über die anwenderseitig Desktop und Anwendungen bereitgestellt werden. Benötigte man früher im Desktop-Umfeld einen voll ausgestatteten Client (Fat Client), so stehen heute abgespeckte Varianten (sogenannte Thin und Zero Clients) zur Verfügung, da die für das Betriebssystem und die Anwendungen bereitgestellten Ressourcen nicht mehr dezentral und lokal vorgehalten werden müssen.