Betrachtet man den Trend der vergangenen Jahre im Bereich der Server, so erkennt man eine sich abwechselnde Schwerpunktverlagerung von der Konsolidierung von Einzelsystemen auf ein performantes Enterprise-System hin zu einzelnen Blade-Systemen.
Virtualisierung als Form der Konsolidierung von Servern in virtuelle Maschinen (VM) oder virtuelle Umgebungen (Virtual Environment VE) ermöglicht eine Energie- und Raumeinsparung durch Reduktion der physikalischen Systeme. Außerdem erlaubt die Virtualisierung eine schnellere Inbetriebnahme von Systemen.
Werfen wir einen Blick zurück, so gab es leistungsstarke und teure Enterprise-Systeme mit vielen Einzelprozessoren, deren Hardwarekomponenten zu sogenannten unabhängigen, voneinander abgeschirmten Domains unterteilt werden konnten. Die Zuordnung der Ressourcen zu den einzelnen Domains war mehr oder weniger fest definiert. Später konnten Ressourcen aus der einen Domain abgezogen und diese einer anderen Domain zugewiesen werden –und das ohne merklichen Systemunterbruch, also dynamisch. Klassiker für Domaining und Partitioning auf der Hardware-Ebene waren und sind hier SUN Starfire (E10K), Starcat (F15K) und die ganze Fire-Serie.
Mittels logischer Partitionierung, wie man sie bei IBM seit dem Power4 bei der p-Series als LPAR findet, kann man physikalische Komponenten mehreren Partitionen parallel logisch zuteilen – also ebenfalls auf der Hardwareebene. Seit dem Power5 und AIX5.3 gibt es die Mikropartitionierung. Diese erlaubt die dynamische Zuteilung von 1/10 CPU-Leistung zu den Betriebssystemen innerhalb der Partitionen je nach Leistungsbedarf oder nach einem definierten Schema, beispielsweise minimale oder maximale CPU-Leistung. Pro CPU sind damit nochmals je zehn LPAR möglich. Innerhalb der LPAR kann das gleiche Betriebssystem oder beispielsweise Linux betrieben werden. Seit dem Power6 und AIX 6.1 können die LPAR auch zwischen den Maschinen verschoben werden (Partition Mobility).
|
System/ Hersteller |
Art der Nutzung |
Typisierung |
Level |
|
SUN |
Aufteilung der Hardware (HW) |
Domaining, Partitioning |
HW |
|
IBM i-p-Series AIX 5.3/ Linux AIX 6.1 |
Versch. Betriebsmodi, Ressourcenteilung, virt. HW-Ressourcen |
Log. Partitionierung (LPAR), Mikro-LPAR/shared Prozessor LPAR |
HW Steuerung durch Hypervisor/ Workload-Manager |
|
IBM z-Series OS : z/VM |
Ressourcenteilung |
LPAR Paravirtualisierung |
HW |
|
XEN |
OS-Ressourcen-Sharing |
Virtualisierung Hypervisor-Layer |
OS |
|
VMware |
App-Ressourcen-Sharing |
HW-Virtualisierung |
OS/ Applikation |
|
SUN Solaris ab 10 |
OS-Ressourcen-Sharing |
Container, OS-Virtualisierung |
OS |
|
openVZ/ Virtuozzo |
App-Ressourcen-Sharing |
OS-Virtualisierung |
OS |
|
Microsoft Virtual PC |
Ressourcen-Sharing |
HW-Emulation |
OS/ Applikation |
|
Qemu + Bochs |
Ressourcen-Sharing |
HW-Emulation |
SW |
|
MS Hyper-V |
Ressourcen-Sharing |
Virtualisierung |
HW |
Das Ziel damit war klar: die anspruchslosen Services auf den vielen physikalischen Klein-Servern auf wenige leistungsstarke Enterprise-Systeme zu konsolidieren. Damit werden die Ressourcen so effektiv wie möglich genutzt und verteilt, ohne dass die Applikationen innerhalb der Betriebssysteminstanzen beeinflusst werden.
Autonomität
Man könnte auch viele Services auf dem gleichen Server einrichten, nur damit wären die Services nicht mehr voneinander unabhängig zu warten. Beispielsweise käme es zu einem Unterbruch in dem Fall, dass man das Betriebssystem oder gemeinsam benutzte Bibliotheken aktualisiert.
Um daher eine größtmögliche Unabhängigkeit zwischen den Applikationen und damit Services zu erhalten, braucht es eigenständige Betriebssysteme und damit die nötigen Ressourcen.
Es liegt also nahe, die divergierenden Anforderungen so zu erfüllen, dass zwar die Betriebssysteme autonom sind, aber die Hardwareressourcen zusammen so effektiv wie möglich genutzt werden. Während eine Betriebssysteminstanz gerade mal 20 Prozent der Prozessorleistung beansprucht, kann der restliche Teil auf die anderen verteilt werden.
Virtualisierung
Die unterschiedlichen Arten der Virtualisierung (Applikation, Betriebssystem) fordern verschiedene Ansätze.
-
Bei einer Applikation bildet man die Dateisysteme nach und fängt die Aufrufe zum Betriebssystem (System-API) im einfachsten Fall ab. Die HW-Ressourcen werden durch die System-API abgeschirmt.
-
Soll ein Betriebssystem unverändert in einer VM starten, so muss man die HW-Ressourcen zur Verfügung stellen entweder nativ oder emuliert. Man legt also zwischen physikalischer HW und VM einen Layer, merkt sich alle Veränderungen, wie Einstellungen im BIOS oder I/O-Operationen und reagiert darauf, ohne diese Änderung an die reale HW weiterzuleiten. Ausnahmen bilden hier Zugriffe auf die CPU und den Speicher, die direkt an die HW weitergereicht werden. Das Betriebssystem ist damit ohne Anpassungen in der VM lauffähig.
Die Steuerung der Ressourcenzuteilung zu den VM übernimmt der sogenannte Hypervisor, auch Virtual Maschine Monitor (VMM) genannt. Dieser ist der Kern der meisten Produkte für die Server-Virtualisierung und setzt entweder auf ein laufendes Betriebssystem (Typ-2 VMM) oder direkt auf die Hardware (Typ-1 VMM) auf. Einige VMM sind dabei auf spezielle Virtualisierungsfunktionen innerhalb der Prozessoren (AMD-V, Intel-VTx, IBM LPAR) angewiesen, um virtuelle Maschinen auszuführen.
|
Architektur |
Hypervisor Typ-1 |
Hypervisor Typ-2 |
|
Virtualisierungslösung |
|
|
|
Vorteile: |
Schlank Robust Performant |
Keine OS Anpassung nötig |
|
Nachteile: |
OS Modifikation |
Bei der Paravirtualisierung nutzt man eine von der Hardware abweichende Softwareschnittstelle, bei der das Betriebssystem jedoch an diese Schnittstelle angepasst werden muss, um lauffähig zu sein. Diese Technik betet mehr Performance als die Emulation der Hardware.
Indem man nun jedem Betriebssystem die nötigen Ressourcen vorspiegelt, die es zum Booten und zum Betrieb benötigt, kann man die vorhandenen physikalischen Ressourcen effektiv nutzen. Das komplette System, bestehend aus – unverändertem - OS, Applikationen und Ressourcen, nennt man virtuelle Maschine (VM).
Vor- und Nachteile der Virtualisierung
Vor der Virtualisierung von Servern sollten die Auswirkungen und eventuellen Einschränkungen bedacht werden. Zu den Vorteilen zählen:
-
Weniger physikalische Systeme: Kosten- und Energieeinsparung
-
Die VM/LPAR kann on-the-fly verschoben werden (Live-Migration, Checkpointing, Partition Mobility)
-
Der aktuelle Status der VM kann „eingefroren“ werden
-
Erstellen von gleichen/identischen VM (Cloning)
-
Rückgängig-Machen von Änderungen innerhalb der VM durch Snapshots
-
Statische VM für Kiosk-Mode
Nachteile der Virtualisierung:
-
Ausfall aller VM bei Ausfall des Wirtssystems ergibt ein erhöhtes Risiko
-
Ungenaue Zeitscheiben
-
Höhere Latenzzeiten mit mehr VM pro System
Probleme
Sollen physische Server und darauf laufende Applikationen in virtuelle Server migriert werden, sind auch folgende Probleme zu beachten:
Timing
Mögliche Probleme beim Betrieb innerhalb einer virtualisierten Umgebung sind Applikationen, die auf ein exaktes Timing angewiesen sind, beispielsweise Job-Steuerungen. Die Zeitsynchronisierung bei modernen Betriebssystemen erfolgt über den Timer-Interrupt in Hardware, der je nach Programmierung von 50 bis zu 1000 Interrupts pro Sekunde auslösen kann. Die Periodizität ist dabei nahezu konstant, jedoch muss dieser eine Interrupt einigen virtuellen Umgebungen übermittelt werden, bevor erneut ein Interrupt ausgelöst wird. Alleine mit diesem Scheduling wäre ein Prozessor einige Zeit beschäftigt, und die VM müsste dafür immer wieder aktiviert werden. Damit aber die Prozessorleistung den virtuellen Maschinen zugute kommt, werden einige Timer-Interrupts ignoriert, während die VM gerade nicht aktiv ist. Sobald die VM dann wieder aktiviert wird, werden die fehlenden Interrupts auf einmal nachgeliefert. So kommt es vor, das unter Linux die Uhrzeit damit der aktuellen Zeit vorauslaufen würde – erfolgen keine Gegenmaßnahmen.
Verantwortung
Bei Störungen an einem Einzelsystem waren nur dessen Services betroffen, und damit war der Überblick gegeben. Wenn aber 20 und mehr VM auf einem System laufen, dann ist es wichtig, auch hier den Überblick zu behalten. Das physikalische Wirtssystem ist damit unternehmenskritischer als ein einzelner Server mit wenigen Services.
Support
Wenn man Applikationen ohne Fehler in einer VM betreibt, und es kommt zu einem Störfall, bei dem man auf den Support des Herstellers angewiesen ist, so sollte man sich vor Augen halten, dass einige Applikationen in einem virtuellen Umfeld keinen Support genießen. Erst wenn man den Fehler auch außerhalb der VM reproduzieren kann, akzeptieren einige Hersteller diesen Support-Fall.
SW-Aktivierung
Für SW, die einer Aktivierung unterworfen ist, beispielsweise Windows XP, ist bei der Life-Migration auf einen anderen Prozessor zu beachten, dass dadurch gegebenenfalls eine neue Aktivierung notwendig sein kann, da der native Prozessor mit seinen Kenndaten in die VM durchgereicht wird.
Vorbereitungen
Aus Unternehmenssicht heißt die Vorgabe schlicht: „Die zu migrierende Applikation inklusive Betriebssystem soll sich in der virtuellen Umgebung unverändert verhalten.“
Die Erfahrung hat gezeigt, dass es nur wenige Probleme beim Betrieb innerhalb einer VM gibt. Die Hardwarearchitektur des Betriebssystems muss die gleiche auf dem Wirt und innerhalb der VM sein. Unterschiedliche HW-Architekturen sind nur mittels Emulation (QEmu) möglich. Je nach Produkt gilt es Einschränkungen zu berücksichtigen. OpenVZ nutzt den gleichen Kernel, somit können pro VE keine unterschiedlichen Kernelmodule genutzt werden.
Bei der Konfiguration einer virtuellen Maschine definiert man grundlegende Größen für Ressourcen wie:
-
Prozessorleistung beziehungsweise -zuteilung zur VM
-
Hauptspeichernutzung (RAM)
-
Art und Größe der Festplatten (SCSI/ IDE / SATA)
-
Optische Laufwerke
-
I/O-Schnittstellen
-
Netzwerk
Ist eine VM inklusive Betriebssystem und Applikationen einmal eingerichtet, so liegen diese Daten auf dem Wirtssystem, beispielsweise dem ESX-Host. Der Vorteil dabei ist nun, dass man diese VM jederzeit kopieren beziehungsweise klonen kann und so innerhalb kurzer Zeit ein identisches Umfeld zur Verfügung hat. Damit lassen sich beispielsweise Tests für Applikations-Updates durchführen.
Hat man die Festplatte so eingerichtet, dass die Änderungen darauf nicht persistent sind, startet die VM immer mit den identischen Daten darauf – ideal also für einen Kiosk-Modus oder im Internet-Café.
Im anderen Fall behält die Disk ihre Daten, und es besteht die Möglichkeit, einen konsistenten Datenbestand (Snapshot) davon zu erstellen und jederzeit zu rekonstruieren. Dies ist ein hilfreiches Verfahren, falls zum Beispiel ein SW-Update fehlschlägt.
Da alle VM auf dem Wirtssystem ebenfalls von dessen Ausfall betroffen wären, sollte man ein zweites System aufbauen und die Daten der VM allen Wirtssystemen zur Verfügung stellen, das heißt als Kopie oder über ein SAN. Ein weiterer Vorteil dabei ist, dass die VM zwischen den Wirtssystemen verschoben werden können.
Dabei wird die VM kurz „eingefroren“, und alle notwendigen Daten werden auf das andere System transferiert. Anschließend wird die VM wieder aktiviert, und eventuelle Anpassungen werden durchgeführt – in Analogie, wie es im Modus „Hibernate“ beziehungsweise Suspend-to-Disk erfolgt.
Kommunikation VM und Wirt
In der Regel bedarf es keiner Anpassung des Betriebssystems, wenn es als Gast in einer VM funktionieren soll. Linux und Windows – ob 32- oder 64-Bit-Version – laufen ohne Probleme. Im Hinblick auf die bereits angesprochene Problematik der Zeitsynchronisation, optimaler Nutzung Netzwerk und I/O-Geräten ist eine Kommunikation zwischen Gast- und Wirtssystem erforderlich. Bei VMware Workstation und Server werden die dazu notwendigen Treiber in Form der „vmware-tools“ nachträglich in der VM ins OS installiert. Sehr elegant bindet dazu die VMware-Software auf dem Wirt ein virtuelles optisches Laufwerk in das System ein, das die notwendige Software je nach Gastsystem in der entsprechenden Installationsform vorhält.
Nach der Installation der Tool-Suite als Treiber für Windows oder als Kernel-Modul für Linux kann beispielsweise die Grafikauflösung dynamisch angepasst oder der Gast mit der Zeit des Wirtes synchronisiert werden. Diese Steuerung auf dem Wirt für die VM erfolgt über eine lokale Konsole, ein GUI oder über ein Webinterface.
Migration
Plant man also, einen physischen Server in eine VM zu migrieren, so sollte man die bisherigen Ressourcen für CPU, lokale Laufwerke, Hauptspeicher oder Netzwerk beibehalten und für die VM mindestens so konfigurieren. Dann kann man je nach Produkt mittels verschiedener Methoden entweder aus dem Life-System oder auch aus einem Disk-Image diverser Hersteller die neue VM aufbauen. Die lokalen Disks innerhalb der VM werden auf dem Wirtssystem normalerweise als Dateien nachgebildetm und auf diese kann man je nach Produkt ebenfalls zugreifen, auch wenn die virtuelle Maschine gerade nicht aktiv ist.
|
Kommerzielle Produkte |
Freie-/ Open-Source-Produkte |
|
|
Für die Auswahl des passenden Produktes sollte man folgende Kriterien bewerten:
-
Management/Administration
-
Skalierbarkeit
-
Stabilität
-
Dynamische Ressourcenverteilung
-
Disaster Recovery
Gerade im Bereich der quelloffenen Software wie Linux sind diverse Produkte im Bereich der Paravirtualisierung vorhanden, die damit die Vorteile mit niedrigen Kosten verknüpfen.
Für Upgrades/Updates ist es sinnvoll, wenn der Administrator auf alle virtuellen Umgebungen zugreifen kann. Tauschen VM untereinander viele Daten über das Netzwerk aus, empfiehlt es sich, diese VM auf einem gemeinsamen physikalischen Server zu platzieren.
Eigentlich eine Selbstverständlichkeit, dennoch der Hinweis: Sowohl das Wirtsystem als auch die VM sollte man testen, das heißt kritische Situationen vor der Produktivschaltung erzwingen, und zwar wie folgt: Wie verhält sich das Gesamtsystem, wenn eine VM permanent Dauerlast beim Prozessor wie im I/O- und Speicherbereich einfordert.
Ausblick
Die Multi-Core-Prozessoren sind bei aktuellen Systemen kaum ausgelastet, und so bietet es sich geradezu an, die brachliegende Leistung in Form von virtuellen Systemen sinnvoll einzusetzen.
Server-Virtualisierung liegt im Trend, und die Vorteile überwiegen die Nachteile. Jeder Hersteller kocht zwar wieder sein eigenes Süppchen, doch im Grunde sind die Unterschiede nur minimal. Die Konsolidierung vieler physischer Server auf eine einzige Maschine versetzt die Unternehmen in die Lage. viel Geld beim Betrieb des Rechenzentrums zu sparen. Die Stromkosten sinken, Wartung und Management vereinfachen sich, und die Ressourcen werden besser genutzt.
Hersteller wie Intel und AMD unterstützen mit der Realisierung spezieller Virtualisierungs-Features innerhalb der Prozessoren und Plattformen virtuelle Umgebungen immer besser. Damit wird der sichere Betrieb von virtuellen Servern ohne Performance-Einbußen möglich. (cvi)