Eine Virtualisierungsplattform für Serverdienste auswählen

Was du nach dieser Lektion kannst

Die Südwind Sozialberatung betreibt eine Termin- und Dokumentenanwendung. Bisher laufen Anwendung, Datenbank und Monitoring gemeinsam auf einem älteren physischen Server. Ein Hardwaredefekt würde alle drei Dienste gleichzeitig stoppen. Außerdem lassen sich Wartungsfenster nur schwer planen.

Du sollst keine bestimmte Marke einkaufen. Dein Auftrag beginnt eine Ebene früher: Welche Art von Virtualisierungsplattform trägt den Betrieb, und welche Bedingungen muss sie erfüllen?

Nach dieser Lektion kannst du:

• Anforderungen aus einem Serverdienst in technische Kriterien übersetzen,
• Type-1- und Type-2-Hypervisor sowie Container voneinander abgrenzen,
• Ressourcen für den Normalbetrieb und den Ausfall eines Hosts prüfen,
• Netzwerk, Speicher, Verfügbarkeit, Lizenzierung und Administration gemeinsam bewerten,
• eine Variante nachvollziehbar auswählen und ihre Grenzen benennen.

Du solltest bereits wissen, was CPU-Kerne, Arbeitsspeicher und ein Serverdienst sind. Konkrete Kenntnisse eines Virtualisierungsprodukts brauchst du nicht.

Erst der Dienst, dann die Plattform

Virtualisierung ist kein Selbstzweck. Eine Plattform passt nur, wenn sie den Dienst unter den tatsächlichen Betriebsbedingungen tragen kann. Für die Sozialberatung gelten diese Anforderungen:

• Die Anwendung wird werktags von 7 bis 19 Uhr benötigt.
• Geplante Wartung eines Hosts soll den Anwendungsdienst nicht für das gesamte Wartungsfenster unterbrechen.
• Anwendung und Datenbank brauchen jeweils ein vollständiges Gastbetriebssystem, weil der Softwareanbieter genau diese Betriebsform unterstützt.
• Die Datenbank erzeugt zeitweise hohe Schreiblast.
• Die drei produktiven Systeme müssen in getrennten Netzwerksegmenten betrieben werden können.
• Sicherungen werden in ein getrenntes Sicherungsziel übertragen.
• Die Administration erfolgt durch zwei Personen. Änderungen müssen dokumentiert werden.
• Betriebssysteme, Verwaltungskomponenten und Zugriffe müssen lizenzrechtlich abgedeckt sein.

Die Anforderungen beschreiben noch keine Lösung. Sie geben aber Prüffragen vor: Muss ein einzelner Host ausfallen dürfen? Reicht lokaler Speicher? Gibt es getrennte Netzwerkpfade? Darf die CPU überbucht werden? Welche Lizenzen entstehen pro Host, Prozessorkern, virtueller Maschine oder Zugriff?

Hypervisor und Container trennen unterschiedliche Ebenen

Eine virtuelle Maschine, kurz VM, enthält ein eigenes Gastbetriebssystem. Der Hypervisor teilt CPU, Arbeitsspeicher, Netzwerk und Speicher des physischen Hosts auf die VMs auf. Das NIST beschreibt eine serverbasierte Hypervisor-Plattform entsprechend als Softwareschicht, die Hardware-Ressourcen virtualisiert und mehrere vollständige Betriebssystem- und Anwendungsstapel auf einem Host ermöglicht.

Bei einem Type-1-Hypervisor liegt die Virtualisierungsschicht direkt auf der Serverhardware. Diese Form ist für Serverplattformen üblich. Ein Type-2-Hypervisor läuft dagegen als Anwendung auf einem normalen Hostbetriebssystem. Er eignet sich etwa für lokale Tests, bringt für einen produktiven Serverdienst aber eine zusätzliche Betriebs- und Fehlerdomäne mit: Fällt das Hostbetriebssystem aus oder wird es neu gestartet, betrifft das auch die VMs.

Container verpacken eine Anwendung mit ihren Laufzeitabhängigkeiten. Unter Linux verwenden Container auf einem Host jedoch denselben Kernel. Die Kubernetes-Dokumentation ordnet ihre Isolationsgrenze deshalb schwächer ein als die einer VM mit eigenem Kernel. Container können für passende Anwendungen sehr sinnvoll sein. Im vorliegenden Auftrag fordert der Softwareanbieter aber vollständige Gastbetriebssysteme. Damit sind Container keine gleichwertige Ersatzvariante für diese drei Dienste.

Eine Plattform ist mehr als der Hypervisor

Der Hypervisor allein stellt noch keinen verlässlichen Dienst bereit. Für die Auswahl betrachtest du mindestens sechs Bereiche zusammen.

1. Rechenressourcen: CPU-Kerne und Arbeitsspeicher müssen die gleichzeitige Last tragen. Zusätzlich braucht der Host selbst eine Reserve.
2. Verfügbarkeit: Mehrere Hosts helfen nur, wenn die VM auf einem anderen Host gestartet werden kann und die dafür nötigen Daten erreichbar sind.
3. Netzwerk: Verwaltungs-, VM-, Speicher-, Sicherungs- und gegebenenfalls Migrationsverkehr brauchen genug Bandbreite, passende Trennung und sinnvolle Redundanz.
4. Speicher: Kapazität allein reicht nicht. IOPS, Latenz, Redundanz, gemeinsame Erreichbarkeit und Sicherbarkeit beeinflussen den Betrieb.
5. Lizenz und Support: Host, Gastbetriebssystem, Verwaltung, Sicherung und Zugriffe können unterschiedliche Lizenzmetriken und Supportgrenzen haben.
6. Betrieb: Updates, Monitoring, Rollen, Protokollierung, Wiederherstellungstests und vorhandene Kenntnisse verursachen dauerhafte Arbeit.

Ressourcen auch für den Ausfallfall rechnen

Die Sozialberatung plant zwei gleich ausgestattete Hosts. Jeder Host besitzt 16 physische CPU-Kerne und 128 GiB Arbeitsspeicher. Für Hypervisor, Verwaltung und Sicherheitspuffer werden pro Host 16 GiB reserviert.

Im Regelbetrieb sollen die VMs verteilt laufen. Bei Wartung oder Ausfall eines Hosts muss der verbleibende Host vorübergehend alle produktiven VMs aufnehmen können.

Die produktiven VMs benötigen zusammen 80 GiB Arbeitsspeicher und 12 vCPU. Mit den Test-VMs sind es 104 GiB und 18 vCPU. Nach der Hostreserve stehen 112 GiB Arbeitsspeicher bereit. Damit passt die geplante Arbeitsspeicherzuweisung rechnerisch auf einen Host.

Bei der CPU ist die Zuordnung mit allen Test-VMs überbucht: 18 vCPU treffen auf 16 physische Kerne. Dieses Verhältnis heißt CPU-Overcommit.

CPU-Overcommit = zugewiesene vCPU / physische CPU-Kerne
CPU-Overcommit = 18 / 16 = 1,125

Ein Verhältnis von 1,125 bedeutet nicht, dass dauerhaft 12,5 Prozent Rechenleistung fehlen. vCPU sind planbare Rechenzeit auf den physischen Kernen. Kritisch wird die Überbuchung, wenn viele VMs gleichzeitig ihre volle CPU-Zeit verlangen. Red Hat weist deshalb darauf hin, dass ein tragfähiges Verhältnis von der Arbeitslast abhängt und in Produktion gemessen sowie getestet werden muss.

Verfügbarkeit braucht mehrere unabhängige Pfade

Zwei Hosts beseitigen noch keinen Single Point of Failure. Liegen alle virtuellen Festplatten auf einem einzelnen Speichergerät, bleibt dieses Gerät eine gemeinsame Ausfallstelle. Führt nur ein Switch den Speicher- und VM-Verkehr, gilt dasselbe für das Netzwerk.

Für eine hoch verfügbare VM müssen die beteiligten Hosts auf ihren Zustand und ihre virtuellen Datenträger zugreifen können. Microsoft nennt für einen Hyper-V-Cluster getrennt zu planende Verkehrsarten wie Verwaltung, Clusterkommunikation, Migration, Speicherzugriff, Replikation und VM-Zugriff. Die konkrete Technik ist produktabhängig. Die Planungsfrage bleibt allgemein: Welche Daten müssen von welchem Host über welchen Pfad erreichbar sein?

Für den Auftrag werden deshalb vorgesehen:

• zwei Hosts, die beide die produktiven VMs ausführen können,
• redundant angebundener, von beiden Hosts erreichbarer Speicher,
• getrennte logische Netze für Verwaltung, VM-Zugriff, Speicher und Sicherung,
• redundante physische Netzwerkpfade für die kritischen Verbindungen,
• ein externes Sicherungsziel, das nicht dieselbe Fehlerdomäne wie der VM-Speicher teilt,
• ein dokumentierter Test für Hostausfall und Wiederanlauf.

Ein Cluster ersetzt keine Datensicherung. Der Cluster hilft beim Weiterbetrieb nach dem Ausfall eines Knotens. Eine Sicherung stellt frühere Datenstände wieder her, etwa nach versehentlichem Löschen oder einer beschädigten Datenbank.

Drei Varianten vergleichen

Die Vorauswahl enthält drei produktneutrale Varianten.

Variante B ist hier die belastbarste Ausgangswahl. Sie erfüllt die Wartungsanforderung nicht automatisch, kann sie aber mit geeigneter Clusterfunktion, gemeinsam erreichbarem Speicher und redundanten Netzwerkpfaden tragen. Variante A bleibt für weniger kritische Dienste denkbar. Variante C passt eher in eine Testumgebung.

Betrieb und Lizenzierung gehören in dieselbe Entscheidung

Eine kostenlose Hypervisor-Lizenz bedeutet nicht automatisch einen kostenlosen Betrieb. Patchen, Monitoring, Sicherung, Dokumentation, Bereitschaft, Schulung und Wiederherstellungstests benötigen Zeit. Umgekehrt belegt ein hoher Lizenzpreis nicht, dass eine Plattform für den Auftrag geeignet ist.

Für jede Variante hältst du deshalb getrennt fest:

• Nutzungsrecht: Welche Hosts, Prozessorkerne, Gastbetriebssysteme, Verwaltungsfunktionen und Zugriffe sind abgedeckt?
• Support: Welche Kombination aus Hardware, Hypervisor und Gastbetriebssystem unterstützt der jeweilige Anbieter?
• Betriebsaufwand: Wer installiert Updates, überwacht die Plattform und reagiert auf Störungen?
• Nachweis: Welche Inventar-, Lizenz- und Änderungsdaten müssen dokumentiert werden?
• Ausstieg: Wie lassen sich VMs, Daten und Konfigurationen sichern oder auf eine andere Plattform übertragen?

Die konkreten Bedingungen stehen im jeweiligen Vertrag und in den zum Entscheidungszeitpunkt gültigen Produktbestimmungen. Diese Lektion liefert deshalb keine pauschale Lizenzrechnung. Sie zeigt, welche Fragen vor einer Entscheidung beantwortet werden müssen.

Übertrage die Auswahl auf einen neuen Auftrag

Das nimmst du mit

Eine belastbare Plattformentscheidung beginnt beim Serverdienst. Type-1-Hypervisor, Type-2-Hypervisor, Container und Bare Metal lösen unterschiedliche Betriebsprobleme. Erst Anforderungen an Isolation, Support, Ressourcen und Ausfallzeit zeigen, welche Form passt.

Ressourcen planst du nicht nur für den ruhigen Regelbetrieb. Du rechnest Reserve und Ausfallfall, misst Spitzenlast und behandelst Overcommit als überprüfbare Annahme. Für Verfügbarkeit betrachtest du Hosts, Speicher und Netzwerk als zusammenhängende Fehlerdomänen. Lizenzierung und Betriebsaufwand gehören ebenfalls in den Variantenvergleich.

Damit steht die Auswahl, aber noch nicht die vollständige Systemlösung. Die konkrete Speicherarchitektur, das Sicherungsverfahren, VLANs, Firewallregeln und die Installation der Serverdienste brauchen jeweils eine eigene Planung und Prüfung.

Quellenbasis und Abgrenzung

Der Rahmenlehrplan ordnet das Bereitstellen von Serverdiensten dem Lernfeld 10b zu. Die Ausbildungsordnung verbindet die Lektion mit dem Konzipieren, Realisieren und Administrieren von IT-Systemen. Der Prüfungskatalog stützt die Themenbreite aus Anforderungen, Virtualisierung, Bare Metal, Auslastung und Lizenzmanagement. Er sagt nicht voraus, welche Aufgabe in einem konkreten Prüfungstermin vorkommt.

Die technischen Details sind produktneutral erklärt. NIST trägt das Grundmodell der Hypervisor-Plattform. Die aktuelle RHEL-9-Dokumentation trägt die Einordnung von vCPU- und Arbeitsspeicher-Overcommit. Microsoft Learn dient als konkrete Primärquelle für Verkehrsarten und Speicheranforderungen eines Failover-Clusters. Die Kubernetes-Dokumentation grenzt die gemeinsame Kernel-Nutzung von Containern gegenüber VMs ab.

Nicht Teil dieser Lektion sind die Auswahl eines konkreten Herstellers, eine vollständige Clusterinstallation, die Dimensionierung einer Speicherlösung und die Konfiguration von VLANs oder Sicherungsverfahren. Diese Themen schließen fachlich an, würden die Handlung in einer 40-Minuten-Lektion aber zu breit machen.

Belegmatrix