Der Trend zur Standardisierung von Hard- und Software in den Rechenzentren ist deutlich und wird weiter zunehmen. Nur für Spezialaufgaben kommen noch proprietäre und teure Server-Systeme zum Einsatz. An dieser Tendenz wird sich nichts mehr ändern, denn die Rechenleistung der Standard-Server ist, verglichen mit den Mainframes aus den 60er und 70er Jahren oder auch den aktuellen Unix-Systemen, wesentlich preisgünstiger zu haben.

Wo die Leistungsanforderungen steigen, kaufen Unternehmen heute zusätzliche Intel-basierende Rack-Server hinzu und bauen sie in bestehende Rack-Systeme ein. Unter dem Stichwort "Scale out" wird dabei häufig für jede Applikation ein eigener Server eingesetzt. Je mehr Systeme, desto eher erweist sich das System-Management hier allerdings als Herausforderung. Da müssen Patches und Updates von unterschiedlichen Betriebssystem-Versionen eingespielt, alte Server ersetzt oder zusätzliche Rechner für bestimmte Einsatzgebiete beschafft werden. Die Administrierbarkeit einer Vielzahl einzelner Server ist in dem Umfeld - trotz aller Fortschritte beim System-Management - immer noch eine zeitraubende Aufgabe.

An einigen Stellen vollzog man daher wieder eine Abkehr vom Scale out und konsolidierte mehrere Applikationen auf dedizierten Multiprozessor-Systemen. "Scale up" lautet dann die Devise. Im Idealfall wird bei einem Multiprozessor-Server unterstellt, dass dessen Leistungsfähigkeit linear mit den zusätzlichen Server-Ressourcen wie Prozessoren, Hauptspeicher und der Datenbreite des System-Busses steigt. Der Vorteil dabei liegt in der gemeinsamen Nutzung aller Ressourcen. Aber auch diese Strategie führt schnell zum bekannten Grundproblem, denn die Management-Anforderungen bleiben die gleichen: Software-Patches, die Umwidmung von Hardware, Ausfallzeiten wegen Wartung und die Allokation von Rechenleistung. Letztlich ist die enge Verknüpfung von Software und Hardware für die Inflexibilität verantwortlich.

Entkopplung von Hardware und Software

Sind umgekehrt Hardware und Software entkoppelt, so ist es möglich, Server mit einem zuvor archivierten Software-Stack zu klonen und damit identische Server zu reproduzieren. Administratoren können so Workloads viel einfacher auf einheitlich konfigurierte Server verteilen. Das wiederum setzt standardisierte Hardware voraus, bei der die Schnittstellen vereinheitlicht sind. Hier kommt eine Virtualisierungstechnik ins Spiel, die eine Schnittstelle zwischen Hard- und Software bereitstellt: die "Virtual Machine".

Mit Virtualisierung ist in diesem Zusammenhang ein Verfahren zur Ressourcenverteilung gemeint, das Wechselwirkungen zwischen Hard- und Software durch Isolierung und Partitionierung möglichst ausschließt. Eine Virtual Machine (VM) ist demnach ein Softwarekonstrukt, das aus Sicht einer Applikation das funktionale Äquivalent einer physischen Hardware bietet. Die VM verfügt über dieselben Features wie ein Server: Prozessor, Steckplätze, Netzwerkkarten, Festplatten und dergleichen - aber eben alles "virtuell" als Software emuliert. Ähnlich wie ein physikalisches System lässt sich auch eine VM ein- und ausschalten. Wird eine VM aktiviert, arbeitet das Betriebssystem auf der virtuellen Harddisk - auch als Image, Stack oder Container bezeichnet. Dieses Image können Administratoren von einem Server zum anderen kopieren.

Die Virtualisierung von Hardware ist für die IT kein völlig neues Thema. Auf Mainframes ist die Methode seit langem bekannt und wird dort auch eifrig praktiziert. Virtualisierung erlaubt es einem bestimmten Betriebssystem, als Host (Gastgeber) weiterer Operating Systems zu agieren. Insbesondere im Segment der x86-Architekturen erweist sich die Virtualisierung als Technik mit viel Potenzial, verspricht sie doch die mit Scale-out-Architekturen verbundenen Management-Probleme zu lindern.

Zwei Wege zur Implementierung von Virtual Machines

Bei der Implementierung von Virtual Machines lassen sich zwei Optionen unterscheiden, die beispielsweise Dell in seinen Rack-optimierten Servern unterstützt. Beiden VM-Varianten gemeinsam ist eine Untergliederung des Hardware-Software-Stacks in drei Schichten: Applikationssoftware-Layer, Virtualisierungs-Layer und Hardware-Layer. Der Unterschied zwischen den zwei Modellen besteht lediglich darin, wie die mittlere Virtualisierungsschicht realisiert wird: als eigenes Betriebssystem oder als Applikation eines Host-Betriebssystems.

Ist die Virtualisierungsschicht als eigenes, spezialisiertes Betriebssystem installiert, übernimmt sie - direkt auf der Hardware aufgespielt - die Aufgaben eines herkömmlichen universellen Betriebssystems. Ein derartiges "Special Purpose" Operating System verfügt jedoch über kein eigenes Dateisystem. In diese Produktkategorie gehört beispielsweise der "ESX Server" von VMware. Da hier die Zugriffe von den Virtual Machines auf die Hardware nur mehr oder minder durchgereicht werden, bietet dieser Ansatz eine bessere Performance als die zweite Variante. Wird die Virtualisierungsschicht als Applikation eines Host-Betriebssystems betrieben, besteht sie aus der Kombination eines generischen Betriebssystems wie Windows oder Linux und einer Virtualisierungsapplikation. Da hier die Virtualisierungsschicht alle Services des Gastgebers nutzen kann, gewährleistet diese Variante eine recht gute Kompatibilität mit bereits vorhandener Hardware. In diese Produktkategorie gehören etwa der "GSX Server" von VMware sowie Microsofts "Virtual Server 2005".

Die Hardwareverwaltung gestaltet sich einfacher

Die Virtualisierungstechnik kommt heute vor allem dort zum Einsatz, wo es um Konsolidierung, Standardisierung und Replikation geht. Konsolidierung bedeutet, dass mehrere physische Server als logische Virtual Machines auf einem System zusammengeführt werden. Der wesentliche Effekt: Es wird Platz gespart, und es ist dann nur noch eine Server-Hardware statt zuvor mehrere zu administrieren. Der Vorteil der Standardisierung lässt sich recht gut am Beispiel eines Treiber-Updates in einer heterogenen Betriebssystem-Landschaft mit Windows, Linux und Netware verdeutlichen. In der alten Welt mussten drei Versionen des neuen Treibers installiert werden. Dagegen genügt es nach der Umstellung, einen Treiber auf dem Virtualisierungs-Layer zu aktualisieren. Die Gast-Betriebssysteme und ihre Applikationen nutzen weiterhin die ihnen virtuell bereitgestellten generischen Treiber. Damit können Anwender auch alte Applikationen weiterverwenden, die etwa Windows NT benötigen.

Durch die Trennung von Hard- und Software replizieren Administratoren Software-Images nahezu beliebig auf zusätzliche Server - sei es, weil deren Kapazität brachliegt oder sie zu anderen Zwecken eingesetzt wurden. Im Rechenzentrumsbetrieb oder in Server-Farmen, wo eine schnelle Reaktion auf geänderte Anforderungen zählt, ist das unter dem Stichwort "Wartung ohne Ausfallzeiten" eine höchst willkommene Funktion. Mit "VMotion" von VMware können Server im laufenden Betrieb von einem Host zu einem anderen verschoben werden. Betreibern von Server-Farmen ermöglicht dies eine ausfallfreie Wartung sowie eine kontinuierliche Konsolidierung der Arbeitslast. (kk)