08V01 Virtualisierung – mehr als nur eine Technologie
In diesem Beitrag lernen Sie die Technologien und Mechanismen der (Server-)Virtualisierung kennen. Der Weg ist so gewählt, dass ein nicht technikaffiner Leser das Thema auf einer einfachen technischen Ebene grundlegend verstehen kann. Dieses technische Fundament ist hilfreich, um in einem zweiten Schritt die aus der Virtualisierung abzuleitenden Anforderungen, Mehrwerte und Herausforderungen einfacher verstehen und bewerten zu können. von: |
1 Einführung
Grundlegendes Verständnis
Dieser Beitrag möchte dem interessierten Leser ein grundlegendes Verständnis zum Thema Virtualisierung vermitteln. Dabei stehen weniger die technischen Details als die mit dieser Technologie verknüpften Möglichkeiten, Mehrwerte und Visionen im Vordergrund. Gleichwohl sind grundlegende technische Informationen zu diesem Thema hilfreich. Sie werden vereinfacht aufbereitet, ohne dabei aber aus Sicht eines Experten die technische Ebene völlig zu entfremden. Ungeachtet dieser Motivation wird ein technischer Experte natürlich einige Facetten der Virtualisierung vermissen und auch einige Punkte verfeinern und durch weitere Möglichkeiten ergänzen wollen. Aus Sicht des Autors wäre dies aber der eigentlichen Zielsetzung nicht dienlich.
Dieser Beitrag möchte dem interessierten Leser ein grundlegendes Verständnis zum Thema Virtualisierung vermitteln. Dabei stehen weniger die technischen Details als die mit dieser Technologie verknüpften Möglichkeiten, Mehrwerte und Visionen im Vordergrund. Gleichwohl sind grundlegende technische Informationen zu diesem Thema hilfreich. Sie werden vereinfacht aufbereitet, ohne dabei aber aus Sicht eines Experten die technische Ebene völlig zu entfremden. Ungeachtet dieser Motivation wird ein technischer Experte natürlich einige Facetten der Virtualisierung vermissen und auch einige Punkte verfeinern und durch weitere Möglichkeiten ergänzen wollen. Aus Sicht des Autors wäre dies aber der eigentlichen Zielsetzung nicht dienlich.
Es sei an dieser Stelle auch erwähnt, dass in diesem Beitrag Produktnamen und Screenshots von konkreten Lösungen zu finden sind. Dies ist eine bewusste Entscheidung, da sich dadurch gemäß dem Sprichwort „Ein Bild sagt mehr als tausend Worte” komplexe Zusammenhänge oftmals einfacher und verständlicher transportieren lassen. Dabei sind die mit Quellenangaben wiedergegebenen Lösungen nur als Beispiele ohne Empfehlungscharakter zu verstehen.
1.1 Virtualisierung: Einführung
Wünsche und Herausforderungen
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:
• | MacOS anstelle von Windows als Betriebssystem (OS: Operating System). |
• | Die Mac-Tastatur entspricht nicht ganz der gewohnten Tastatur. |
• | Werden alle von Ihnen benötigten Anwendungen unterstützt? |
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:
a) | Sie kaufen zwei Laptops: ein Laptop mit MacOS und ein Laptop mit Windows-Betriebssystem. |
b) | Sie kaufen ein MacBook, verwenden einen sogenannten Bootmanager (bringt MacOS mit: Boot Camp) und entscheiden beim Booten des Rechners über ein Auswahl-Menü, ob Sie MacOS oder Windows booten möchten. |
c) | Sie kaufen ein MacBook, löschen das MacOS und installieren Windows. |
d) | Sie entscheiden sich gegen ein MacBook. |
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.
Abb. 1: Der Rechner im Rechner (Variante 1)
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.
Die ersten Erkenntnisse
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:
• | Es gibt einen Rechner, den Sie anfassen können (das neue MacBook), und einen, der wie eine Anwendung zu sehen ist und sich nicht anfassen lässt. Letztgenannten bezeichnen wir deshalb als virtuelle Maschine (VM: Virtual Machine). |
• | Ein Rechner benötigt grundlegende Ressourcen (Abb. 2): Prozessoren (CPU: Central Processing Unit), einen dynamischen Speicher (RAM) und Festplattenspeicher. Ihr neues MacBook bringt diese Ressourcen mit. |
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.
Abb. 3: Der Windows-Gerätemanager
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.
Abb. 4: Aufruf des Gerätemanagers
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.
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.
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.
• | Die Idee des Rechners im Rechner verleitet Sie zu neuen Ideen: Warum sich nicht auch mal mit Linux auseinandersetzen? Es ist aber sicherlich einsichtig, dass Ihrer Euphorie Grenzen gesetzt sind, die sich u. a. dadurch begründen, dass alle virtuellen Gäste um die physischen Ressourcen konkurrieren müssen. Ganz banal lautet dann beispielsweise die Frage: Welcher virtuelle Gast darf das DVD/CD-Laufwerk sein Eigen nennen, wenn physisch nur ein Laufwerk eingebaut ist? |
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.
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.
• | Wenn für das MacOS-Betriebssystem ein Programm existiert, das dafür sorgt, dass ein Rechner im Rechner arbeiten kann, dann sollte das doch auch für andere Betriebssysteme als Wirt möglich sein? |
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.
Abb. 5: Der Rechner im Rechner (Variante 2)
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 virtuelle Maschine ist völlig entkoppelt von der Hardware und wird damit mobil. Das heißt, das Wirtsystem stellt die physischen Ressourcen zur Verfügung, die virtuelle Maschine selbst erkennt allerdings nicht, dass sie diese Ressourcen nicht dediziert besitzt. Letztendlich sind diese Ressourcen damit aber an das Wirtsystem und nicht an seine Gäste (die virtuellen Maschinen) gebunden. Dadurch kann eine virtuelle Maschine formal gesehen auf jedem beliebigen Gastsystem laufen. Wichtig ist dabei zunächst nur, dass das Wirtsystem auch ausreichende Ressourcen zur Verfügung stellen kann. |
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).
Abb. 6: Konvertierung einer physischen Maschine in eine virtuelle Maschine
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.
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.
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.
1.2 Virtualisierung: Ziele
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.
Rückblick
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:
• | Hoher administrativer Aufwand. |
• | Die 1:1-Zuordnung zwischen Server und Anwendung führt oft zu einer veralteten Hardware. Diese kann aber nicht so ohne Weiteres abgelöst werden, weil die auf der Hardware installierte Anwendung nicht problemlos auf eine neue Hardware portiert werden kann. |
• | Unterschiedliche Hardware-Generationen erhöhen den administrativen Aufwand. |
• | Eine Standardisierung gestaltet sich in der Regel sehr schwierig, sodass letztendlich eine Automatisierung (z. B. bei der Einrichtung der Systeme) kaum möglich ist. |
• | Hoher Platzbedarf. |
• | Hoher Bedarf an Netzwerkverbindungen. |
• | Ineffiziente Auslastung der Server-Ressourcen. |
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.
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.
Anwendungen
Viele Anwendungen sind heute sehr komplex aufgebaut. Man spricht in diesem Zusammenhang oft auch von einer 3-Tier- bzw. 3-Schichten-Architektur (Abb. 7).
Abb. 7: 3-Tier- bzw. 3-Schichten-Architektur
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.
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.
2 Was ist eine virtuelle Maschine?
Virtualisierung ist zugegebenermaßen kein triviales Thema und selbst IT-affine Menschen finden oft keinen einfachen Zugang dazu. Insofern mag es irritierend sein, wenn man direkt zum Einstieg mit der Frage konfrontiert wird, was denn eigentlich eine virtuelle Maschine ist? Die Erfahrung zeigt allerdings, dass eine punktgenaue Beantwortung dieser Frage den Einstieg in die Thematik erleichtert und sich dadurch die Mehrwerte dieser Technologie schneller erschließen.
Beispiel A
Abbildung 8 zeigt eine Management-Konsole (hier: VMware vSphere), über die mehrere virtuelle Maschinen verwaltet werden können. Es ist eine virtuelle Maschine mit dem Namen Server001 aufgelistet.
Abb. 8: Verwaltung einer virtuellen Maschine
Feste Routinen
Über die Management-Konsole lässt sich Server001 ein- und auch ausschalten, d. h., der Server kann heruntergefahren und auch gebootet werden. Mit Blick auf einen physischen Server ist die Möglichkeit einer solchen Steuerung nichts, was faszinieren könnte, wenngleich sich auch nicht jeder mit den Einzelheiten eines Bootvorgangs genauer auseinandersetzen muss. Mit Blick auf selbigen ist nur die Information wichtig, dass beim Einschalten eines Rechners feste Routinen abgearbeitet werden:
Über die Management-Konsole lässt sich Server001 ein- und auch ausschalten, d. h., der Server kann heruntergefahren und auch gebootet werden. Mit Blick auf einen physischen Server ist die Möglichkeit einer solchen Steuerung nichts, was faszinieren könnte, wenngleich sich auch nicht jeder mit den Einzelheiten eines Bootvorgangs genauer auseinandersetzen muss. Mit Blick auf selbigen ist nur die Information wichtig, dass beim Einschalten eines Rechners feste Routinen abgearbeitet werden:
• | Die CPU liest den Inhalt des BIOS (in einem nicht flüchtigen Speicher abgelegt) und führt die entsprechende Routine aus. |
• | Über die BIOS-Routine werden die Hardwarekomponenten identifiziert und geprüft. |
• | Die BIOS-Routine sucht über eine festlegbare Folge auf den verfügbaren Speichereinheiten (z. B. Festplatte, DVD-Laufwerk) einen Boot Sector, lädt dessen Inhalt (Master Boot Record) und übergibt dann die weitere Kontrolle an die darin enthaltene Startroutine. |
• | Die Startroutine sucht und lädt bei z. B. einem Windows-Betriebssystem im ersten Schritt das Programm bootmgr (Windows Bootmanager), über das eine Auswahl des zu startenden Betriebssystems erfolgen kann. Danach werden die zentralen Komponenten des Betriebssystems geladen (der sogenannte Kernel). |
Somit ist ein erfolgreicher Bootprozess primär von drei Dingen abhängig:
• | Hardware |
• | BIOS |
• | Betriebssystem |
Wenn eine virtuelle Maschine bootet, hat der oben beschriebene Vorgang auch in der virtuellen Welt Gültigkeit. Die virtuelle Maschine existiert dabei aber nicht in dem gewohnten Formfaktor und in der gewohnten Konsistenz: Eine virtuelle Maschine ist eine Datei (bzw. kann auch aus mehreren Dateien bestehen).
Boot Image
In Abbildung 9 ist zu sehen, dass sich Server001 in der Management-Konsole als eine Ansammlung von Files (im Bild links) darstellt. Ein wichtiges File ist die virtuelle Festplatte des Rechners. In unserem Beispiel das File mit dem Namen Server001.vmdk. Die Größe dieses Files signalisiert schon, dass wir den Inhalt dieses Files durchaus mit dem Inhalt einer Festplatte in unserem Rechner vergleichen dürfen, was einen Rückschluss auf den Inhalt – nämlich das bei der Installation des Betriebssystems erstellte Boot Image – zulässt.
Abb. 9: Was ist eine virtuelle Maschine?
In Abbildung 9 ist zu sehen, dass sich Server001 in der Management-Konsole als eine Ansammlung von Files (im Bild links) darstellt. Ein wichtiges File ist die virtuelle Festplatte des Rechners. In unserem Beispiel das File mit dem Namen Server001.vmdk. Die Größe dieses Files signalisiert schon, dass wir den Inhalt dieses Files durchaus mit dem Inhalt einer Festplatte in unserem Rechner vergleichen dürfen, was einen Rückschluss auf den Inhalt – nämlich das bei der Installation des Betriebssystems erstellte Boot Image – zulässt.
„Steckbrief”
Die Management-Konsole führt zu jeder virtuellen Maschine einen „Steckbrief” (im Bild rechts), über den die Maschine beschrieben wird. Dieser Steckbrief enthält Informationen zur Hardware des Systems (CPU, RAM, Netzwerkkarte, Laufwerke, Festplatte etc.). Diese Ressourcen hält das Wirtsystem (der Host) für den virtuellen Server Server001 vor. Nicht direkt physisch, sondern nur als verwalteter Zugriff auf die physischen Ressourcen, aber davon weiß und bemerkt Server001 nichts.
Die Management-Konsole führt zu jeder virtuellen Maschine einen „Steckbrief” (im Bild rechts), über den die Maschine beschrieben wird. Dieser Steckbrief enthält Informationen zur Hardware des Systems (CPU, RAM, Netzwerkkarte, Laufwerke, Festplatte etc.). Diese Ressourcen hält das Wirtsystem (der Host) für den virtuellen Server Server001 vor. Nicht direkt physisch, sondern nur als verwalteter Zugriff auf die physischen Ressourcen, aber davon weiß und bemerkt Server001 nichts.
Neue Kenntnisse
Mit Blick auf die bisherigen Ausführungen haben wir – wenn wir es erst einmal losgelöst von der Technik der Virtualisierung betrachten – sicherlich keine weiteren neuen Kenntnisse gewonnen:
Mit Blick auf die bisherigen Ausführungen haben wir – wenn wir es erst einmal losgelöst von der Technik der Virtualisierung betrachten – sicherlich keine weiteren neuen Kenntnisse gewonnen:
• | Unser physischer Rechner bootet, gesteuert durch einen Bootvorgang. |
• | Unser physischer Rechner hat eine Festplatte, auf der das Betriebssystem zu finden ist (und die irgendwann auch mal ihren maximalen Füllstand erreicht). |
• | Unser physischer Rechner hat ein Hardwareprofil, das z. B. etwas über seine Geschwindigkeit (CPU und RAM), oder seine Netzwerkschnittstellen (LAN, WLAN) aussagt. |
Virtuelle Maschine
Allerdings ist bei unserem physischen Rechner unsere Vorstellungsgabe sicherlich nicht so gefordert wie bei einer virtuellen Maschine, denn letztendlich steht das gute Stück vor uns, und wir können es in weiten Bereichen auch einfach haptisch begreifen. Eine virtuelle Maschine besteht dagegen aus Dateien. Wo ist z. B. ihre CPU, ihre Netzwerkkarte oder ihr RAM? Es gibt nichts zum Anfassen. Ein File kann man höchstens kopieren oder auch einfach löschen. Letztgenanntes eliminiert die Maschine, erfordert dabei aber keinen Ausflug zum Wertstoffhof.
Allerdings ist bei unserem physischen Rechner unsere Vorstellungsgabe sicherlich nicht so gefordert wie bei einer virtuellen Maschine, denn letztendlich steht das gute Stück vor uns, und wir können es in weiten Bereichen auch einfach haptisch begreifen. Eine virtuelle Maschine besteht dagegen aus Dateien. Wo ist z. B. ihre CPU, ihre Netzwerkkarte oder ihr RAM? Es gibt nichts zum Anfassen. Ein File kann man höchstens kopieren oder auch einfach löschen. Letztgenanntes eliminiert die Maschine, erfordert dabei aber keinen Ausflug zum Wertstoffhof.
Spannend ist, dass man eine virtuelle Maschine (Abb. 10) recht einfach verändern und erweitern kann. Die Management-Konsole zur Verwaltung von virtuellen Maschinen erlaubt es uns, der Maschine Server001 z. B. eine weitere CPU oder auch mehr Arbeitsspeicher zu spendieren.
Abb. 10: Erweiterung einer virtuellen Maschine
Lifecycle- Management
Mehr RAM und CPU via Mausklick? Mit Blick auf das Thema Lifecycle-Management eine faszinierende Vorstellung. Vor diesem Hintergrund ist sicherlich auch zu verstehen, warum z. B. Netzwerkausrüster zunehmend ihre Komponenten wie z. B. Firewalls als virtuelle Appliances (ein anderer Ausdruck für zweckgebundene virtuelle Maschinen) anbieten. Sollte die Firewall mehr Ressourcen benötigen, dann ist das (in Grenzen) mit ein paar Mausklicks schnell getan, und niemand muss in diesem Moment altes Blech gegen neues Blech austauschen.
Mehr RAM und CPU via Mausklick? Mit Blick auf das Thema Lifecycle-Management eine faszinierende Vorstellung. Vor diesem Hintergrund ist sicherlich auch zu verstehen, warum z. B. Netzwerkausrüster zunehmend ihre Komponenten wie z. B. Firewalls als virtuelle Appliances (ein anderer Ausdruck für zweckgebundene virtuelle Maschinen) anbieten. Sollte die Firewall mehr Ressourcen benötigen, dann ist das (in Grenzen) mit ein paar Mausklicks schnell getan, und niemand muss in diesem Moment altes Blech gegen neues Blech austauschen.
Beispiel B
Unser zweites Beispiel wird zwar wieder nur zu der Erkenntnis führen, dass eine virtuelle Maschine ein File ist, aber die mit diesem Beispiel verknüpfte Visualisierung soll das Thema noch greifbarer machen und bedient sich dazu unseres Beispiels aus dem Consumer-Umfeld.
Abbildung 11 zeigt den Desktop eines MacBooks. Im sogenannten Dock befindet sich ein Icon, über das ein Programm (hier: VMware Fusion) aufgerufen werden kann.
Abb. 11: Virtualisierung auf dem Desktop-Rechner
Über dieses Programm wird die hier angebotene Option Windows 7 gewählt. Abbildung 12 zeigt, dass es sich dabei wohl um einen virtuellen Rechner mit dem Namen Windows 7 handelt.
Abb. 12: Windows auf einem MacBook
Überbuchung
Damit läuft ein Windows-7-Rechner auf einem MacBook. Allerdings wurde die Entscheidung, die Windows-Maschine zu starten, nicht über den Dialog eines Bootmanagers beantwortet. Vielmehr läuft der Windows-Rechner zeitgleich mit dem MacOS-Betriebssystem auf der gleichen Hardware. Damit liegt die Vermutung nahe, dass sich MacOS- und Windows die verfügbaren Ressourcen teilen müssen. Der Rechner muss über die entsprechenden Ressourcen verfügen, da sonst die Performance beider Maschinen leidet. Allerdings ergeben sich die erforderlichen Ressourcen nicht einfach dadurch, dass man stupide die Ressourcen von zwei autarken Rechnern addiert, denn letztendlich benötigen nicht beide Maschinen immer zeitgleich alle Ressourcen, sodass man hier durchaus mit dem statistischen Aspekt einer Überbuchung planen kann.
Damit läuft ein Windows-7-Rechner auf einem MacBook. Allerdings wurde die Entscheidung, die Windows-Maschine zu starten, nicht über den Dialog eines Bootmanagers beantwortet. Vielmehr läuft der Windows-Rechner zeitgleich mit dem MacOS-Betriebssystem auf der gleichen Hardware. Damit liegt die Vermutung nahe, dass sich MacOS- und Windows die verfügbaren Ressourcen teilen müssen. Der Rechner muss über die entsprechenden Ressourcen verfügen, da sonst die Performance beider Maschinen leidet. Allerdings ergeben sich die erforderlichen Ressourcen nicht einfach dadurch, dass man stupide die Ressourcen von zwei autarken Rechnern addiert, denn letztendlich benötigen nicht beide Maschinen immer zeitgleich alle Ressourcen, sodass man hier durchaus mit dem statistischen Aspekt einer Überbuchung planen kann.
Über den Finder (in MacOS integrierte Suchfunktion) ist der Gast (die Windows-Maschine) schnell gefunden. Ein Schwergewicht von 68,7 GB und wieder nur ein File.
Abb. 13: Und wieder nur ein File ...
Das File mit dem Namen Windows 7 ist für MacOS nur ein File (Abb. 13) und könnte – beabsichtigt oder nicht – natürlich auch im Papierkorb (Abb. 14) landen. Sollten Sie das File präventiv vor einer Woche zusätzlich auf einen USB-Stick kopiert haben, hätten Sie Glück im Unglück: Sie könnten das verlorene File einfach wieder zurückkopieren.
Abb. 14: Möglicher Tod einer virtuellen Maschine ...
Sicherungszyklus
Wenn Sie die Maschine nun wieder starten würden, hätte sie allerdings einen Zustand, der eine Woche zurückliegt. Eventuell hätten Sie dadurch Daten verloren, oder sie müssten Anwendungen noch einmal installieren. Dennoch dürften sich Ihnen auf der Basis solcher unscheinbar wirkenden Beispiele so langsam weitere spannende Vorteile der Virtualisierung erschließen, zumal das Thema Virtualisierung das Thema Datensicherung nicht eliminiert und Sie hier mit Blick auf den Sicherungszyklus von einer Woche durchaus noch Optimierungspotenzial haben. Stellen Sie sich z. B. vor, Ihnen wäre Ihr Laptop auf den Boden gefallen: Das Display ist gesplittert, das Gehäuse gebrochen und der Rechner bootet nicht mehr. Wenn Sie mit einer virtuellen Maschine arbeiten, dann kopieren Sie das Windows-7-Backup-File einfach auf eine neue Hardware und booten Sie die virtuelle Maschine mithilfe des Programms, das den Rechner im Rechner ermöglicht.
Wenn Sie die Maschine nun wieder starten würden, hätte sie allerdings einen Zustand, der eine Woche zurückliegt. Eventuell hätten Sie dadurch Daten verloren, oder sie müssten Anwendungen noch einmal installieren. Dennoch dürften sich Ihnen auf der Basis solcher unscheinbar wirkenden Beispiele so langsam weitere spannende Vorteile der Virtualisierung erschließen, zumal das Thema Virtualisierung das Thema Datensicherung nicht eliminiert und Sie hier mit Blick auf den Sicherungszyklus von einer Woche durchaus noch Optimierungspotenzial haben. Stellen Sie sich z. B. vor, Ihnen wäre Ihr Laptop auf den Boden gefallen: Das Display ist gesplittert, das Gehäuse gebrochen und der Rechner bootet nicht mehr. Wenn Sie mit einer virtuellen Maschine arbeiten, dann kopieren Sie das Windows-7-Backup-File einfach auf eine neue Hardware und booten Sie die virtuelle Maschine mithilfe des Programms, das den Rechner im Rechner ermöglicht.
2.1 Fazit
Halten wir kurz die grundlegenden Erkenntnisse dieser ersten Etappe fest:
• | Virtuelle Maschinen „verhalten” sich wie ihre physischen Kollegen und benötigen die gleichen Komponenten (RAM, CPU, Speicher, Netzwerkkarten etc.). | ||||||||||
• | Eine virtuelle Maschine definiert sich über ein File (oder eine Ansammlung von Files) und, wenn sie eingeschaltet ist, noch über eine Anzahl von Prozessen (Laufzeit, engl. Runtime). | ||||||||||
• | Um eine virtuelle Maschine betreiben zu können, ist eine spezielle Software erforderlich. | ||||||||||
• | Ein File kann man ...
| ||||||||||
• | Ein Programm verwaltet die zu Verfügung stehenden physischen Ressourcen (z. B. Prozessoren oder RAM). Die virtuellen Gäste wissen nichts von diesem Ressourcenmanagement und haben die Illusion, dass ihnen die benötigten Ressourcen exklusiv zur Verfügung stehen. Sie wissen nichts von anderen Gästen, die über die gleichen Ressourcen bedient werden. Damit werden Betriebssysteme, Anwendungen und Dienste von der Hardware entkoppelt. | ||||||||||
• | Beherbergt ein Wirtsystem mehrere virtuelle Gäste, können – eine entsprechende Planung und Steuerung vorausgesetzt – die Ressourcen des Wirtsystems natürlich besser ausgelastet werden als bei einem Server, der angeschafft wurde, um genau eine Anwendung zu beherbergen. | ||||||||||
• | Wenn das Wirtsystem nicht die benötigten Ressourcen vorhalten kann, hat das Einfluss auf die virtuellen Gäste. So bekommt ein Gast z. B. eventuell nicht mehr die CPU-Zeitscheiben, die er benötigt, um seine Anwendungen adäquat bedienen zu können. In einfachen Worten heißt das: Die virtuelle Maschine wird langsam. |
3 Einfache technische Grundlagen
Professionelles Umfeld
Wie bereits erwähnt, führte die Einführung ins Thema Virtualisierung aus didaktischen Gründen über den Consumer-Bereich. Dort lassen sich einfacher Beispiele aufzeigen und Bilder verwenden, die man als Anwender und nicht als Rechenzentrumsexperte kennt. Allerdings gibt es in einem professionellen Umfeld Anforderungen, die sich über das eingangs gewählte Umfeld nicht mehr motivieren lassen. Damit dennoch weitere Vorteile der Virtualisierung sichtbar werden, müssen wir leichte technische Kost zu uns nehmen. Aber keine Sorge, die Flughöhe sollte so gewählt sein, dass Sie in Ruhe die Aussicht genießen können und niemand Ihnen in Brechtscher Manier am Ende noch den Boden unter den Füßen wegziehen möchte, auf dem Sie eben noch glaubten sicher zu stehen.
Wie bereits erwähnt, führte die Einführung ins Thema Virtualisierung aus didaktischen Gründen über den Consumer-Bereich. Dort lassen sich einfacher Beispiele aufzeigen und Bilder verwenden, die man als Anwender und nicht als Rechenzentrumsexperte kennt. Allerdings gibt es in einem professionellen Umfeld Anforderungen, die sich über das eingangs gewählte Umfeld nicht mehr motivieren lassen. Damit dennoch weitere Vorteile der Virtualisierung sichtbar werden, müssen wir leichte technische Kost zu uns nehmen. Aber keine Sorge, die Flughöhe sollte so gewählt sein, dass Sie in Ruhe die Aussicht genießen können und niemand Ihnen in Brechtscher Manier am Ende noch den Boden unter den Füßen wegziehen möchte, auf dem Sie eben noch glaubten sicher zu stehen.
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.
Abb. 15: Der Hypervisor (Konzept)
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.
Abb. 16: Zwei wichtige zu emulierende Komponenten: Festplatte und CPU
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.
3.2 Der Übergang in die „reale” Welt
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.
Abb. 17: 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.
3.3 Bereitstellen einer virtuellen Maschine
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.
Abb. 18: Bereitstellung einer virtuellen Maschine (Beispiel: vSphere 5.5)
0. | Menüpunkt: Neue virtuelle Maschine |
1. | Auf welchem Wirtsystem soll die neue virtuelle Maschine ausgeführt werden? |
2. | In welchen Speicher soll die Festplatte (ein File) der virtuellen Maschine abgelegt werden? |
3. | Welches Betriebssystem wird die virtuelle Maschine haben (damit sich die Virtualisierungsschicht darauf einstellen kann)? |
4. | Zuordnung des Laufwerks, in dem die DVD/CD mit dem Betriebssystem zu finden ist, das beim Booten installiert werden soll. |
Der Schritt 4 zeigt noch einmal, dass die Virtualisierungsschicht nicht das Betriebssystem seiner Gäste zur Verfügung stellt.
3.4 Verwaltung
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 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:
• | Abbildung des Lifecycle-Managements von virtuellen Maschinen, |
• | Anlegen von virtuellen Maschinen, |
• | Verwaltung der Ressourcen, |
• | Migration von virtuellen Maschinen, |
• | Verwaltung des Netzwerkzugangs von virtuellen Maschinen, |
• | Monitoring der Ressourcennutzung durch die einzelnen virtuellen Maschinen, |
• | Backup- und Restore-Steuerung der virtuellen Maschinen. |
3.5 Fazit
Halten wir wiederum kurz die neu gewonnenen Erkenntnisse aus dieser Etappe fest:
• | Über einen Hypervisor können die Ressourcen eines physischen Servers (Host) mehreren virtuellen Maschinen (Gästen) zur Verfügung gestellt werden. |
• | Die virtuellen Maschinen können mit unterschiedlichen Betriebssystemen und unterschiedlichen Generationen von Betriebssystemen arbeiten. |
• | Es ist eine Konsolidierung möglich: Auf wenigen, hochgerüsteten physischen Servern können viele virtuelle Maschinen betrieben werden. |
• | Es ist eine effizientere Nutzung der Ressourcen möglich: Eine starre Bindung zwischen Anwendung und physischem Server führt oft zu nur mäßig ausgelasteten Ressourcen. Durch den Umzug dieser Anwendungen in die virtuelle Welt bzw. auch durch die Konvertierung von physischen Servern zu virtuellen Servern kann diese Situation entschärft werden. |
4.1 Migration von virtuellen Maschinen
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.
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.
Abb. 19: Migration einer virtuellen Maschine (1)
Abb. 20: Migration einer virtuellen Maschine (2)
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.
Abb. 21: Migration einer virtuellen Maschine (3)
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.
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.
Abb. 22: Migration: vereinfachte Darstellung
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.
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.
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.
4.2 Anforderungen an das Thema Storage
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.
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.
Abb. 23: Shared Storage
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.
4.3 Anforderungen an das Thema Netzwerk
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.
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.
Abb. 24: Controller, SCSI-Kabel und Festplatte
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.
4.4 Das Gesamtbild
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.
Abb. 25: Primäre Komponenten eines Rechenzentrums
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.
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.
Abb. 26: Bereitstellung von Diensten
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.
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.
4.5 Backup & Recovery
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.
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.
Abb. 27: Backup & Recovery
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).
Abb. 28: Beispiel: Veeam Backup and Replication Management-Konsole
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.
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.
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:
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:
• | ein Backup-Tool für klassische und virtuelle Umgebungen; |
• | einfache Bedienbarkeit; |
• | Nutzen der Kommunikationsschnittstellen (APIs) von Hypervisor/Management-Tool der Virtualisierung und Storage-System; |
• | eine Auslagerung der Backup-Daten muss möglich sein (z. B. Tape oder Replikation zu einem anderen Storage-System); |
• | schnelle Recovery-Mechanismen; |
• | Recovery von kompletten virtuellen Maschinen, individuellen Files oder Anwendungsdaten (z. B. Exchange-Kontakte, Exchange-Postfach); |
• | Erstellung von Application-Consistent Images; |
• | automatisiertes und zeitgesteuertes Backup; automatisiertes Recovery; |
• | unterschiedliche Recovery-Ziele (z. B. Restore auf eine physische Maschine, Restore auf die gleiche oder eine unterschiedliche Virtualisierungsplattform); |
• | automatisiertes Überprüfen der Backups (Integrität der Daten und Anwendungen, kann VM gebootet werden etc.); |
• | Deduplizierung und Komprimierung der Backup-Daten (das bietet sich an, da z. B. viele VMs das gleiche Betriebssystem haben); |
• | Schnittstellen in Richtung Public Cloud. |
4.6 Sicherheit
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.
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.
Abb. 29: Strikte Trennung auf Netzwerk-, Storage- und Virtualisierungsebene
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.
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.
4.7 Fazit
Auch am Ende dieses Kapitels wollen wir ein weiteres Fazit ziehen:
• | Zur Verwaltung von virtuellen Maschinen sollte die für die Virtualisierung gewählte Lösung ein Administrationstool bieten. In der Praxis sind Mehrwerte und Funktionen der Virtualisierung maßgeblich von diesem Tool abhängig. |
• | Durch die Virtualisierung können auch bestehende Speicher- und Netzwerklösungen infrage gestellt werden, sodass ein Projekt in diesem Umfeld durchaus auch mit einer Modernisierung dieser Lösungen verknüpft sein kann. Das heißt, die anfänglichen Investitionskosten können sehr hoch sein, da es hier nicht nur um das Blech – also um wenige hochgerüstete Host-Systeme –, sondern auch um Speichersysteme und um Netzwerklösungen geht. |
• | Virtuelle Maschinen verhalten sich wie physische Maschinen. Insofern spielen auch in der virtuellen Welt Themen wie Backup und Sicherheit eine Rolle. Das heißt, die Fragestellungen bleiben an vielen Stellen gleich, lediglich die Antworten müssen Anforderungen und Möglichkeiten der Virtualisierung berücksichtigen. |
• | Es ist eine effizientere Nutzung der Ressourcen möglich: Eine starre Bindung zwischen Anwendung und physischem Server führt oft zu nur mäßig ausgelasteten Ressourcen. Durch den Umzug dieser Anwendungen in die virtuelle Welt bzw. auch durch die Konvertierung von physischen Servern zu virtuellen Servern kann diese Situation entschärft werden. |
5 Ausblick: Weitere Varianten der Virtualisierung
Ausgereift
Bisher beschränkte sich dieser Beitrag primär auf eine Variante der Virtualisierung, die als Server-Virtualisierung bezeichnet wird. Die Server-Virtualisierung kann heute durchaus als Commodity klassifiziert werden, d. h., sie gilt als ausgereift und wird in vielen Firmen bereits eingesetzt. Neben dieser Variante der Virtualisierung existieren heute aber noch weitere. Ein Beispiel ist die Virtualisierung der Desktop-Rechner, was allgemein als Virtual Desktop Infrastructure (VDI, Abb. 30) bezeichnet wird. Die virtuellen Desktops werden wie ein virtueller Server auf einem Host-System zur Verfügung gestellt. Bindeglied zwischen virtuellem Desktop und Host-System ist, wie auch schon zuvor, die Virtualisierungsschicht.
Abb. 30: Virtual Desktop Infrastructure (vereinfachte Darstellung)
Bisher beschränkte sich dieser Beitrag primär auf eine Variante der Virtualisierung, die als Server-Virtualisierung bezeichnet wird. Die Server-Virtualisierung kann heute durchaus als Commodity klassifiziert werden, d. h., sie gilt als ausgereift und wird in vielen Firmen bereits eingesetzt. Neben dieser Variante der Virtualisierung existieren heute aber noch weitere. Ein Beispiel ist die Virtualisierung der Desktop-Rechner, was allgemein als Virtual Desktop Infrastructure (VDI, Abb. 30) bezeichnet wird. Die virtuellen Desktops werden wie ein virtueller Server auf einem Host-System zur Verfügung gestellt. Bindeglied zwischen virtuellem Desktop und Host-System ist, wie auch schon zuvor, die Virtualisierungsschicht.
5.1 Desktop-Virtualisierung
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.
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.
5.2 Virtualisierung der Anwendung
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.
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.
5.3 Fazit
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.
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.