Ein allgemeines Ärgernis für Systemadministratoren ist der immense Test- und Qualifizierungsaufwand, der anfällt, sobald die neue Version eines zugrundeliegenden Betriebssystems vorliegt. Und obwohl die Vorteile der neuen Software für den Großteil der Anwendungen minimal sind, wird das Upgrade für eine bestimmte Anwendung oder eine neue Hardwarekomponente benötigt.

Die Lösung dieses Dilemmas lautet Virtualisierung. Die vorhandene Masse der Anwendungen kann wie gehabt als Gast innerhalb einer virtuellen Maschine weiterlaufen, während der aktuelle Hypervisor problemlos die neue Hardware unterstützt sowie Vorteile in punkto Zuverlässigkeit und Leistung mitbringt. Die wenigen Anwendungen, die auf die neue Version des Betriebssystems angewiesen sind, können auf einer anderen virtuellen Maschine mit der aktuellen Version laufen.

Das heißt, dass Upgrades wirklich nur dann stattfinden, wenn die Systemadministratoren es möchten. Damit sind sie nie wieder zu ungeplanten und kostspieligen Software-Upgrades gezwungen.

• Video anschauen: Schluss mit hektischen Upgrades

Während ein System, das ausschließlich für eine Anwendung genutzt wird, hermetisch abgeriegelt werden kann, nutzen heute viele Systeme gemeinsame Zugriffe. Hier gilt es, den Datenschutz aufrechtzuerhalten.

Mit der Virtualisierung ist es möglich, jede Anwendung und jeden Datensatz auf eine separate virtuelle Maschine zu platzieren. Das sichert viele der Vorteile, die wir aus der Verriegelung einzelner physischer Systeme kennen - allerdings mit deutlich weniger Hardwareaufwand. Da die Virtualisierung jeden Gast isoliert, besteht auch eine geringere Gefahr unbefugten Datenzugriffs. Und jeder erfolgreiche Angriff ist jeweils nur auf den betroffenen Gast begrenzt. In Verbindung mit SELinux und dem Red Hat Identity Management lässt sich so ein hoher Grad an Nutzer- und Datenisolierung erreichen, ohne für jeden Nutzer einen separaten Server zu benötigen.

Softwareentwicklung erfordert einen langen Arbeitszyklus mit wiederholtem Codieren, Debuggen und Testen. Bisher wurden für das Debugging und die Tests viele separate Systeme benötigt. Und es war schwierig, die für die Tests erforderlichen größeren Netzwerke und Datensammlungen aufzubauen. Virtualisierung bietet hier gleich mehrere Lösungen.

Die Entwickler können einzelne virtuelle Maschinen nutzen, die sie starten und anhalten können, ohne sich gegenseitig zu behindern. Damit brauchen Entwickler keine separaten physischen Rechner mehr. Auf diese Weise lässt sich das Debugging von Code, auch von Kernelcode, deutlich optimieren.

Da sich virtuelle Maschinen schnell und einfach starten, anhalten und anpassen lassen, ist es problemlos möglich, große Regressionstestreihen zu automatisieren. Skripte können unterschiedliche Versionen von Anwendungen und Betriebssystemen bereitstellen, bekannte Datenbestände mit ihnen abgleichen und die Ergebnisse protokollieren. Und wenn sich ein System aufhängt, kann das Skript dies erkennen, da nur der Gast abstürzt und nicht das zugrundeliegende DOM 0.

Werden große Mengen an Systemen benötigt, können mehrere vernetzte Gäste eingerichtet werden, um mit wenigen physischen Servern ein großes physisches Netzwerk zu simulieren. Damit sind Skalierbarkeitstests möglich, die heute kaum durchgeführt werden. Während der inaktiven Zeiten können die zusätzlichen Zyklen in ungenutzten Arbeitsrechnern sogar auf sichere Art und Weise für Tests benutzt werden, da jeder Gast gesichert und mit einer Firewall geschützt ist.

Die sogenannte Live Migration erlaubt die Migration paravirtualisierter Gäste auf Red Hat Enterprise Linux Version 5 über das Netzwerk von einem physischen Server zum anderen. Erhält der Gast den "Umzugs"-Befehl (von einem Programm oder einem Systemadministrator mit Hilfe der Verwaltungstools von Red Hat Enterprise Linux) arbeitet der Hypervisor auf dem "Quell"-System mit dem auf dem "Ziel"-System zusammen, um ausreichend Speicher für den Gast bereitzustellen. Dann wird der Speicher über das Netzwerk kopiert, bis nur noch "heißer" Speicher übrig ist. Da der Gast auf der "Quell"-Maschine noch läuft und Gäste unterstützt, definieren wir "heißen" Speicher als den Speicher, der aktiv in Benutzung ist. Anschließend hält der "Quell"- Hypervisor den Gast an und kopiert den restlichen "heißen" Speicher. Danach startet der Hypervisor auf der "Ziel"-Maschine den Gast. Da sämtliche Netzwerke und E/A-Verbindungen im kopierten Speicher gehalten werden, bleiben sie vollständig bestehen. Damit werden die Aufgaben nach einer kurzen Pause (< 200 ms) unvermindert weiter ausgeführt. Beachten Sie, dass die Systeme auf demselben Subnetz liegen müssen, damit der Netzwerk-Socket erhalten wird, und eine gemeinsame Datenablage benötigen, um geöffnete Dateien zu erhalten. Ein Lock-Manager ist nicht erforderlich, und iSCSI, GNDB oder ein beliebiges SAN sind ebenfalls geeignet.

Die Gründe für eine solche Live Migration sind vielfältig.

1. Ein Gast ist dermaßen ausgelastet, dass er entweder auf einen neuen Rechner verlegt wird oder andere Gäste von diesem Rechner ausgelagert werden, um für den ausgelasteten Gast mehr Ressourcen freizugeben.
2. Ein System meldet Soft Errors im Speicher, Überhitzungsprobleme oder andere Anzeichen eines drohenden Ausfalls. Gäste können verlagert werden, bevor sie heruntergefahren werden, um den Server warten zu können.
3. Als Vorbereitung auf große Datenströme, wie sie bei Durchläufen in ERP- oder Finanzsystemen vorkommen, können Gäste von einem Server verlagert werden, um Kapazitäten freizusetzen. Genauso können Gäste auf weniger Rechner zusammengelegt werden, um überschüssige Kapazitäten auszuschalten und Strom zu sparen.

• Video anschauen: Server komfortabel reparieren

Ein gutes Argument für eine große Anzahl von Gästen, die jeweils wenige Funktionen übernehmen, ist die Minimierung eines Dominoeffekts bei einem Absturz. Häufig ist zu beobachten, dass durch einen abgestützten Auftrag auf einem großen SMP-System alle Knoten auf diesem System abstürzen oder sich aufhängen. Mit der Red Hat-Virtualisierung kann jede Funktion einem separaten Gast zugeordnet werden. Fällt eine Funktion aus oder hat sie ein Sicherheitsproblem, verbreitet sich der Fehler nicht, sondern wirkt sich nur auf den einen Gast aus. Durch eine geschickte Nutzung der Migration und der HA-Cluster-Software lassen sich problemlos Backupinstanzen einrichten, die bei Problemen mit einem Gast oder einem Workload auf andere Rechner verlagert werden können.