Über Jahrzehnte galt in Serverräumen eine einfache Regel: eine Aufgabe, ein Server. Die Warenwirtschaft bekam ihre eigene Maschine, der Mailserver eine zweite, die Dateiablage eine dritte. Das war übersichtlich, aber teuer – die meisten dieser Maschinen waren über weite Strecken kaum ausgelastet, verbrauchten aber Strom, Platz und Wartungszeit wie unter voller Last. Virtualisierung hat dieses Modell abgelöst: Mehrere virtuelle Server teilen sich eine physische Maschine, sauber voneinander getrennt.
Was ein Hypervisor eigentlich tut
Grundlage ist eine dünne Softwareschicht, der Hypervisor. Er läuft direkt auf der Hardware und teilt Prozessorkerne, Arbeitsspeicher, Netzwerk und Datenspeicher unter den virtuellen Maschinen auf. Jede virtuelle Maschine sieht dabei ihre eigene, standardisierte Hardware und weiß nichts von ihren Nachbarn. Im Unternehmensumfeld verbreitet sind vor allem VMware vSphere mit ESXi, Microsoft Hyper-V und Lösungen auf Basis von KVM wie Proxmox VE.
Entscheidend für das Verständnis ist ein Detail: Die virtuelle Maschine ist vom konkreten Server entkoppelt. Sie besteht im Kern aus einer Konfigurationsbeschreibung und einer oder mehreren virtuellen Festplatten – also aus Dateien. Genau daraus ergeben sich die Vorteile, die im Alltag schwerer wiegen als die bessere Auslastung.
Der eigentliche Gewinn liegt im Betrieb
Weil virtuelle Maschinen Dateien sind, lassen sie sich kopieren, sichern, verschieben und in Minuten neu starten. Eine Sicherung erfasst das gesamte System samt Betriebssystem und Konfiguration, nicht nur die Nutzdaten. Das verkürzt die Wiederherstellung erheblich, weil niemand zuerst einen Server neu installieren und einrichten muss. Bei der Ausfallsicherheit lohnt eine genaue Unterscheidung, die in Gesprächen oft verwischt wird.
- Geplante Wartung: In einem Verbund mehrerer Wirte mit gemeinsamem Speicher lassen sich laufende virtuelle Maschinen im Betrieb auf einen anderen Wirt verschieben. Nutzer bemerken diese Live-Migration in der Regel nicht; Firmware-Updates und Hardwaretausch lassen sich so tagsüber erledigen.
- Ungeplanter Ausfall: Fällt ein Wirt unerwartet aus, starten die betroffenen Maschinen automatisch auf den verbliebenen Wirten neu. Das entspricht einem Neustart und dauert einige Minuten – ein kurzer Ausfall also, aber kein stundenlanger.
- Test und Rückweg: Kopien produktiver Systeme für Tests sowie Rücksetzpunkte vor Updates werden erst durch Virtualisierung praktikabel.
- Hardwaretausch: Beim Wechsel auf neue Server ziehen die virtuellen Maschinen um, statt neu installiert zu werden. Die Anwendung bemerkt vom Generationswechsel der Hardware kaum etwas.
Wo Virtualisierung an Grenzen stößt
- Anwendungen mit Spezialhardware, etwa Steuerungskarten für Maschinen, Kopierschutzstecker oder bestimmte Messtechnik. Manches lässt sich an die virtuelle Maschine durchreichen, nicht alles zuverlässig.
- Software, deren Hersteller den virtuellen Betrieb nicht unterstützt. Technisch läuft sie oft trotzdem – im Supportfall steht man dann aber allein da.
- Extreme Anforderungen an Antwortzeiten, bei denen jede Zwischenschicht stört.
- Lizenzmodelle, die bei Virtualisierung unerwartet teuer werden.
Der letzte Punkt verdient Aufmerksamkeit, weil er häufig erst nach der Umstellung auffällt. Manche Hersteller lizenzieren nach den physischen Prozessorkernen des Wirts oder sogar des gesamten Verbunds, auf dem ihre Software laufen könnte – nicht nach den Kernen der einen virtuellen Maschine. Bei Windows Server deckt die Standard Edition auf einem vollständig lizenzierten Wirt zwei virtuelle Instanzen ab, die Datacenter Edition beliebig viele; wer viele Windows-Maschinen auf wenigen Wirten betreibt, sollte beide Varianten durchrechnen. Auch der Hypervisor selbst ist ein Kostenfaktor: VMware wird seit der Übernahme durch Broadcom nur noch im Abonnement und nach Prozessorkernen lizenziert, was viele Unternehmen zu einer Neubewertung ihrer Plattform veranlasst hat.
Planung: Der Verbund muss einen Ausfall tragen
Der häufigste Planungsfehler ist nicht technischer Natur: Wer viele virtuelle Maschinen auf zu wenige Wirte legt, spart an der falschen Stelle. Ein Verbund sollte den Ausfall eines Knotens verkraften, ohne dass die verbleibenden Maschinen überlastet sind. Fachleute sprechen von N+1 – so viele Wirte, wie die Last erfordert, plus einen.
Zur Veranschaulichung, mit frei gewählten Beispielwerten: Drei Wirte mit je 512 GB Arbeitsspeicher bieten zusammen 1.536 GB. Fällt einer aus, bleiben 1.024 GB. Die virtuellen Maschinen dürfen im Normalbetrieb also zusammen höchstens rund zwei Drittel des Gesamtspeichers belegen, abzüglich einer Reserve für den Hypervisor selbst. Bei nur zwei Wirten liegt die Grenze bei der Hälfte. Wer diese Rechnung nicht aufstellt, stellt im Ernstfall fest, dass sich die Maschinen des ausgefallenen Wirts nirgends mehr starten lassen.
Beim Prozessor ist eine maßvolle Überbuchung üblich, weil selten alle virtuellen Maschinen gleichzeitig unter Volllast rechnen. Beim Arbeitsspeicher ist sie heikel: Reicht er nicht, lagert der Hypervisor aus, und die Leistung bricht spürbar ein. Ebenso wichtig ist der gemeinsame Speicher, auf dem die virtuellen Maschinen liegen – ist er nicht selbst redundant ausgelegt, wird er zum neuen einzelnen Schwachpunkt.
Fragen für die Geschäftsführung
- Wie viele Wirte haben wir, und laufen alle Systeme weiter, wenn einer davon ausfällt?
- Ist der gemeinsame Speicher redundant, oder hängt der gesamte Verbund an einem Gerät?
- Werden die virtuellen Maschinen als Ganzes gesichert, und wurde eine Wiederherstellung auf anderer Hardware schon einmal geprobt?
- Welche Anwendungen laufen bewusst noch physisch, und aus welchem Grund?
- Welche Lizenzen hängen an der Zahl der Prozessorkerne, und wer prüft sie bei jeder Erweiterung?
Virtualisierung ist heute der Normalfall, nicht mehr die Besonderheit. Die Frage lautet deshalb selten, ob virtualisiert wird, sondern wie sorgfältig. Ein gut geplanter Verbund macht aus Hardwaredefekten Wartungstermine; ein knapp bemessener verlagert das Risiko nur von vielen kleinen Servern auf wenige große.
Verwandte Themen: Wer hier weiterdenkt, liest bei VMware Alternativen, Snapshot und Hyper-V Cluster weiter.
Quellen
- SYS.1.5 Virtualisierung · BSIamtlich
- Hyper-V virtualization in Windows Server and Windows · Microsoft
