3.1 Der Hypervisor
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:
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:
| • | Typ 1: Der Hypervisor wird direkt auf der Server-Hardware installiert. |
| • | Typ 2: Der Hypervisor wird auf einem bestehenden Betriebssystem installiert. |
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.
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.
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).
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.
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.
