Vom Blech zur VM: Hypervisor und Ressourcen

Worum es geht

Im Serverraum der Molkerei Emmental AG in Konolfingen stehen sechs Server. Jeder hat genau eine Aufgabe: Anmeldung und DNS, Dateiablage, ERP, Datenbank, Produktionssteuerung, Zeiterfassung. Alle sechs laufen bald aus der Garantie. Fällt das Netzteil des Datenbankservers aus, stehen Bestellwesen und Abfüllung still, bis das Ersatzteil geliefert ist. Gleichzeitig zeigt die Leistungsüberwachung etwas Erstaunliches: Die meiste Zeit langweilen sich diese Server. Von 38 Prozessorkernen arbeiten im Schnitt gerade 9.

Chiara, Lernende im 2. Lehrjahr als Informatikerin Plattformentwicklung, soll mit ihrem Berufsbildner die sechs Server durch eine Virtualisierungsplattform ersetzen: zwei leistungsfähige Hosts, auf denen alle Dienste als virtuelle Maschinen (VMs) laufen. Fällt ein Host aus, startet der andere die VMs neu. Ein Server wird so zu etwas, das man verschieben, sichern und kopieren kann.

Diese Lektion legt das Fundament: Du verstehst, was eine VM technisch ist, wie sich Typ-1- und Typ-2-Hypervisoren unterscheiden und welche vier Ressourcen du bei jeder Planung im Blick haben musst. Am Schluss übersetzt du die sechs Server der Molkerei Schritt für Schritt in VMs.

Was eine virtuelle Maschine eigentlich ist

Stell dir ein Mehrfamilienhaus vor. Das Gebäude mit Fundament, Stromanschluss und Wasserleitung ist die physische Hardware. Die Hausverwaltung teilt das Gebäude in Wohnungen auf, sorgt dafür, dass niemand in die Wohnung des Nachbarn kommt, und verteilt Strom und Wasser gerecht. Diese Hausverwaltung ist der Hypervisor. Jede Wohnung ist eine virtuelle Maschine: Wer darin wohnt, hat eigene Schlüssel und eigene Möbel und merkt im Alltag kaum, dass es Nachbarn gibt.

Technisch gesagt: Ein Hypervisor ist Software, die die Hardware eines Servers (CPU, Arbeitsspeicher, Speicher, Netzwerk) auf mehrere VMs aufteilt und diese voneinander isoliert. Jede VM hat ein eigenes Betriebssystem, das Gastsystem, und dieses glaubt, auf einem eigenen Rechner zu laufen. Der physische Server, auf dem der Hypervisor läuft, heisst Host.

Damit das ohne grossen Leistungsverlust funktioniert, braucht die CPU Hardware-Unterstützung: Intel VT-x bzw. AMD-V für die Prozessorvirtualisierung und eine schnelle Adressübersetzung für den Arbeitsspeicher (SLAT, bei Intel EPT genannt, bei AMD RVI oder NPT). Alle aktuellen Server-CPUs können das, aber die Funktionen müssen im BIOS/UEFI eingeschaltet sein. Genau daran scheitert Chiara bei ihrem zweiten Host, mehr dazu in Lektion 4.

Für den Host ist eine VM vor allem eine Sammlung von Dateien:

Das hat drei praktische Folgen:

• Eine VM lässt sich als Ganzes sichern, kopieren oder auf einen anderen Host verschieben.
• Die Hardware, die das Gastsystem sieht, ist virtuell und überall gleich. Darum läuft eine VM nach dem Umzug auf einen neuen Host ohne neue Treiber weiter, auch wenn der neue Host ein anderes Modell ist.
• Liegen die Dateien auf einem gemeinsamen Speicher, auf den mehrere Hosts zugreifen, kann ein anderer Host die VM übernehmen. Das ist die Grundlage für Hochverfügbarkeit.

Typ 1 und Typ 2: wo der Hypervisor sitzt

Es gibt zwei Bauarten von Hypervisoren, und der Unterschied liegt darin, was unter ihnen liegt.

Ein Typ-2-Hypervisor (hosted) läuft als normales Programm auf einem Betriebssystem, das du ohnehin verwendest, z.B. VirtualBox oder VMware Workstation auf deinem Windows-Laptop. Das ist ideal zum Lernen und Testen: installieren, VM starten, fertig. Aber jeder Zugriff der VM auf die Hardware geht über das Wirtsbetriebssystem. Startet Windows Update den Laptop neu, sind alle VMs weg.

Ein Typ-1-Hypervisor (bare metal) läuft direkt auf der Hardware, ohne vollwertiges Betriebssystem darunter. Beispiele sind VMware ESXi, Microsoft Hyper-V und Proxmox VE mit KVM. Er ist schlank, für den Dauerbetrieb gebaut und bietet Funktionen wie Live-Migration, Cluster und Hochverfügbarkeit.

Bei Hyper-V lohnt sich ein zweiter Blick. Nach der Installation der Rolle siehst du immer noch Windows, deshalb halten viele Hyper-V für Typ 2. Tatsächlich startet beim Booten zuerst der Hypervisor, und das Windows, an dem du arbeitest, wird selbst zu einer besonderen VM: der Root- oder Parent-Partition, die Treiber und Verwaltung übernimmt. Hyper-V ist also Typ 1. Ähnlich bei Proxmox VE: Es basiert auf Debian Linux, und das Kernelmodul KVM macht den Linux-Kernel selbst zum Hypervisor.

Die vier Ressourcen: CPU, RAM, Speicher, Netz

Jede VM verbraucht vier Ressourcen, und jede verhält sich anders. Wer das versteht, plant richtig.

CPU. Eine VM bekommt virtuelle Prozessoren (vCPU). Der Hypervisor verteilt deren Arbeit in sehr kurzen Zeitscheiben auf die physischen Kerne (pCPU). Weil die meisten Server ihre CPU nur selten auslasten, darfst du insgesamt mehr vCPU vergeben, als Kerne vorhanden sind. Das heisst Overcommitment. Denk an ein Fitnessstudio: 400 Abos, 60 Geräte. Das funktioniert, weil nie alle gleichzeitig trainieren. Am Montag um 18 Uhr wird es trotzdem eng, und genau so müssen VMs bei Überlast warten, bis ein Kern frei wird. Achtung bei Hyperthreading: Ein Kern mit zwei Threads erscheint als zwei logische Prozessoren, leistet aber nicht das Doppelte. Rechne deshalb mit physischen Kernen.

Arbeitsspeicher (RAM). Hier gibt es kein Fitnessstudio-Prinzip. Eine VM mit 16 GB nutzt diese meist auch, z.B. als Cache. Wird RAM überbucht, muss der Hypervisor auslagern, und die VMs werden massiv langsamer. Faustregel für die Produktion: RAM wird nicht überbucht.

Speicher. Hier zählen zwei Grössen. Die Kapazität in TB sagt, wie viel Platz du brauchst. Die Leistung sagt, wie schnell gelesen und geschrieben wird: IOPS (Input/Output Operations per Second, also Lese- und Schreibvorgänge pro Sekunde) und Latenz (Wartezeit pro Zugriff in Millisekunden). Eine Datenbank, die beim Monatsabschluss 4'200 IOPS verlangt, bringt eine einzelne Festplatte mit 7'200 Umdrehungen pro Minute (grob 80 bis 100 IOPS) sofort an die Grenze. Eine Enterprise-SSD schafft ein Vielfaches davon.

Netzwerk. VMs teilen sich die physischen Netzwerkkarten des Hosts. Wichtig sind Bandbreite, Redundanz und die saubere Trennung von Verkehrsarten. Das vertiefst du in Lektion 5.

Schritt für Schritt: Die Server der Molkerei als VMs denken

Chiara hat zwei Wochen lang mit der Leistungsüberwachung (perfmon) Daten gesammelt. So sieht ihre Tabelle aus:

"Genutzte Kerne" heisst: Ein Server mit 4 Kernen und 20 Prozent CPU-Last nutzt 0.8 Kerne.

1. Nutzung statt Hardware übernehmen. Die Server haben zusammen 38 Kerne, nutzen im Schnitt aber nur 9.0. Wer 38 vCPU vergibt, plant das Vierfache dessen, was gebraucht wird.
2. vCPU pro VM bestimmen. Chiaras Regel: Spitze mal 1.5 (Luft für Lastspitzen), auf eine ganze Zahl aufrunden, mindestens 2. DC01: 0.8 × 1.5 = 1.2, also 2. FS01: 1.8, also 2. ERP01: 3.9, also 4. SQL01: 7.5, also 8. PROD01: 3.3, also 4. APP01: 1.5, also 2.
3. vCPU summieren. 2 + 2 + 4 + 8 + 4 + 2 = 22 vCPU statt 38 Kerne.
4. RAM übernehmen, nicht überbuchen. 8 + 16 + 24 + 64 + 16 + 12 = 140 GB.
5. Speicher summieren. 0.1 + 1.4 + 0.2 + 0.9 + 0.3 + 0.3 = 3.2 TB Daten.
6. Leistungsspitze notieren. Beim Monatsabschluss erzeugt die Datenbank 4'200 IOPS. Diese Zahl bestimmt später die Wahl von SSDs und RAID.
7. Zwischenergebnis festhalten. 6 VMs, 22 vCPU, 140 GB RAM, 3.2 TB, 4'200 IOPS Spitze. Noch fehlen Wachstum, Reserve und die Frage, was passiert, wenn ein Host ausfällt. Das rechnest du in den Lektionen 2 und 3.

Typische Fehler

• Hardware 1:1 übernehmen. Aus einem 12-Kern-Server wird keine VM mit 12 vCPU. Zu viele vCPU schaden sogar, weil eine grosse VM warten muss, bis genügend Kerne gleichzeitig frei sind.
• Logische Prozessoren als Kerne zählen. 16 Kerne mit Hyperthreading zeigen 32 logische Prozessoren. Geplant wird mit 16.
• RAM wie CPU überbuchen. Beim RAM rächt sich Überbuchung mit Auslagerung. Plane ihn vollständig ein.
• Nur Kapazität betrachten. 3.2 TB passen auf zwei grosse Festplatten, aber diese liefern niemals 4'200 IOPS.
• Typ 2 als Server missbrauchen. Eine VirtualBox-VM auf einem Büro-PC fällt aus, sobald jemand den PC neu startet.

Zusammenfassung

• Ein Hypervisor teilt die Hardware eines Hosts auf mehrere isolierte VMs auf. Für den Host ist eine VM eine Sammlung von Dateien.
• Typ 1 läuft direkt auf der Hardware und gehört in die Produktion (ESXi, Hyper-V, Proxmox VE). Typ 2 läuft als Programm auf einem Betriebssystem.
• Die CPU braucht VT-x/AMD-V und SLAT, eingeschaltet im BIOS/UEFI.
• CPU darf mit Augenmass überbucht werden, RAM in der Produktion nicht.
• Beim Speicher zählen Kapazität und Leistung (IOPS, Latenz).
• Plane nach gemessener Nutzung, nicht nach der alten Hardware.