Server-Virtualisierung mit VMware ESXi, Microsoft Hyper-V, Proxmox und Linux KVM

Viele Anwendungen lasten die neusten Server-Generationen nicht mehr aus. Gerade moderne Prozessoren arbeiten in vielen Servern nur mit wenigen Prozent Auslastung. Bei physikalischen Servern werden aber meist eigene Server für jede Anwendung benötigt. Die einzelnen Anwendungen beeinflussen sich bzw. die Hersteller geben keinen Support, wenn zusätzliche andere Programme auf dem gleichen Betriebssystem (in diesem Fall die Hardware) laufen. Ein einfacher und damit kostengünstiger Server ist häufig trotzdem nicht ausreichend, die Verfügbarkeit der Hardware darf ja auch bei kleinen aber wichtigen Anwendungen nicht leiden. Also wurde für jede Anwendung ein teurer und überdimensionierter Server angeschafft, geschützt mit einem zusätzlichen Wartungsvertrag für die Hardware. Dieser Server muss natürlich genauso administriert werden, als wäre er gut ausgelastet. Auch die Überwachung der Hardware nimmt zusätzliche Zeit und Geld in Anspruch.

Es geht also nicht, einfach verschiedene Anwendungen auf ein Betriebssystem zusammenzufassen. Wenn eine Trennung zwischen Anwendungen geschaffen werden soll, jede Applikation also ihr eigenes Betriebssystem braucht, aber nicht unbedingt eine eigene Hardware, dann ist die Lösung die Server-Virtualisierung.

Man nimmt eine gemeinsame Hardware, lässt darauf aber mehrere unabhängige Betriebssysteme laufen. Hierfür stellt die Virtualisierungssoftware quasi mehrere virtuelle Rechner (virtuelle Hardware) innerhalb der gleichen phsikalischen Hardware zur Verfügung. Ein Betriebssystem innerhalb dieser Virtualisierungssoftware verhält sich genauso, als wäre es direkt auf einem Server installiert. Es "sieht" Festplatten, Hauptspeicher, CPU(s), Netzwerkkarten und weitere I/O-Bausteine.

Aber die Virtualisierungsschicht stellt nicht nur virtuelle Hardware zur Verfügung. Sie schützt auch die virtuellen Maschinen gegenseitig. Eine virtuelle Maschine kann nicht auf den RAM oder die Festplatten einer anderen VM zugreifen. Auch kann die VM in RAM und CPU begrenzt werden. Sollte die virtuelle Maschine durch eine Störung mehr RAM oder CPU als definiert verbrauchen, so unterbindet die Virtualisierung die weitere Nutzung. Neben diesem Schutzmechanismus kann aber auch der Verbrauch der Ressourcen außerhalb der virtuellen Maschine gemessen und protokolliert werden und das völlig unabhängig vom Betriebssystem der VM.

Vorteile der Server-Virtualisierung

Hardware-Unabhängigkeit der virtuellen Maschinen

Die Virtualisierungsschicht stellt die virtuelle Hardware den virtuellen Maschinen (VM) zur Verfügung. Damit ist diese virtuelle Hardware unabhängig von der physikalischen Hardware. Wird zum Beispiel der Server gegen eine neuere Version oder den Typ eines anderen Herstellers ausgetauscht, dann ändert sich für die VMs nichts. Immer noch die gleiche Netzwerkkarte und der gleiche SAS Controller für die Platten. Ein Umzug ist also ohne Neuinstallation oder Installation von neuen Treibern direkt möglich. Ein großer Vorteil bei geplanten Änderungen in der Hardware, aber ein noch größerer Vorteil bei ungeplanten Änderungen. Fällt zum Beispiel der Server aus, dann muss es nicht unbedingt exakt die gleiche Hardware sein. Ein gerade aktueller Server mit passender CPU und genügend Speicher kann den defekten ersetzen. Und die VMs laufen sofort wieder, dank der virtuellen Hardware.

Hohe Verfügbarkeit

Dies muss von Anfang an genau betrachtet werden. Werden zum Beispiel 3 physikalische Server in ein virtualisiertes System übertragen, dann ist die Verfügbarkeit nicht gerade besser geworden. Wenn vor der Virtualisierung ein Server ausgefallen ist, dann war eine Anwendung (bzw. ein Betriebssystem) gestört. Fällt jetzt der eine Server aus, so sind alle 3 Anwendungen (= alle drei Betriebssystem) gestört. Die Verfügbarkeit ist nicht besser geworden, sondern schlechter. Das liegt jetzt aber nicht direkt an der Virtualisierung, sondern am Design der Umgebung. Würde man statt dem einen Virtualisierungsserver lieber 2 Stück nehmen, dann sieht das Ganze schon viel besser aus. Gleiches Beispiel: Vorher 3 Server, hinterher dann zwei physikalische Server. Fällt jetzt eine Hardware aus, so können alle virtuelle Maschinen auf der anderen Hardware laufen. Damit hat sich die Verfügbarkeit deutlich erhöht.

Das Bild oben zeigt den Standard-Aufbau einer Virtualisierung für den Mittelstand. Es sind mindestens zwei Server vorhanden und ein Storage. Sollte also ein Server ausfallen, dann können alle virtuellen Maschinen auf den anderen Server umziehen. Bei VMware vSphere gibt es dafür die Funktion HA (High Availability). Diese Funktion prüft die Funktionsfähigkeit des jeweils anderen Servers. Sollte ein Server ausfallen, dann startet die HA-Funktion die virtuellen Maschinen auf dem anderen Server neu. Ein kurzer Ausfall der Anwendung wird es also geben. Wenn auch das nicht tolerierbar ist, dann gibt es noch die Funktion "Fault Tolerance" (FT). Ist eine VM im FT-Modus, so wird sie doppelt auf zwei getrennten Servern ausgeführt. Alle Schreiboperationen auf Platte und im Hauptspeicher werden doppelt ausgeführt, ebenso jede Rechenoperation. Die beiden "Ergebnisse" werden miteinander verglichen (die sind ja immer gleich) und in der Ausführung synchron gehalten. Fällt jetzt ein Server aus, so kann die VM auf dem anderen Server sofort weiter arbeiten.

Aber einen "Mangel" hat dieser Aufbau ja doch, oder? Die Server sind zwar doppelt vorhanden, nicht aber der Storage. Sollte der Storage ausfallen, dann sind ja alle virtuellen Maschinen gestört, nichts geht mehr. Das ist richtig, jedoch ist ein Storage-System meist wesentlich redundanter ausgelegt als ein normaler Server. Ein Storage-System hat zwei getrennte Controller, getrennte Pfade zum Server, redundante Netzteile und Lüfter, eine angepasste RAID-Konfiguration, ausreichende Hot Spare Platten, usw.
Aber der Storage könnte natürlich ausfallen, keine Frage. Auch hier gibt es eine Lösung: Es wird ein zweites Storage eingesetzt und die Daten werden vom ersten auf das zweite Storage synchron repliziert. Sollte jetzt ein Storage ausfallen, dann sind die Daten immer noch auf dem zweiten vorhanden. Je nach Storage ist auch eine automatische Umschaltung möglich.
Aber eines ist auch in diesem Fall wichtig: Wenn alle Systeme in einem Raum stehen, dann fallen bei Brand oder Wasserschaden auch alle Systeme auf einmal aus. Also muss nicht nur bei der Hardware etwas getan werden, sondern auch bei den Räumlichkeiten. Eine solche hoch-redundante Lösung sollte auch an zwei getrennten Brandabschnitten aufgebaut werden. Im Übrigen sind die häufigsten Ausfälle von Storage-Systemen durch externe Einflüsse zu verzeichnen. Und das muss nicht unbedingt immer das Großfeuer sein. Wassereinbruch, Ausfall der Klimaanlage, Diebstahl und ein kleiner Schwelbrand sind wesentlich häufiger als man denkt.

Server-Virtualisierung und Green-IT

Der Ansatz der Green-IT ist den Stromverbrauch im Rechenzentrum zu verringern. Wenn also viele physikalische Rechner auf einem virtuellen Server laufen, dann kann eine Menge Energie eingespart werden. Einmal die reine Versorgung der Systeme mit Strom. Das eine große System wird natürlich stärker belastet und verbraucht auch Energie, die vielen "kleinen" Server brauchen aber auch bei geringer CPU-Last viel mehr Energie. Können zehn kleine Server auf einen großen virtualisiert werden, so kann durchaus 80% der Energie eingespart werden.
Und ein weiteres Einsparpotential kommt hinzu. Wenn weniger Energie zur Versorgung benötigt wird, so wird auch die Abwärme geringer. Damit reduziert sich zusätzlich auch der Aufwand für die Klimatechnik, auch dort kann Energie und damit auch Kosten gespart werden.
Damit wird die Server-Virtualisierung zu einem wichtigen Baustein in der Green-IT.

Administration und Überwachung

Dass die Administration einfacher wird, das kann man recht einfach einsehen. Es sind ja weniger Server vorhanden, weniger Hardware die überwacht werden muss. Zusätzlich sind alle Funktionen der virtuellen Maschinen auch remote zu erreichen. Die Consolen der Systeme sind über den Virtualisierungsclient (bei VMware der vSphere Client) zu erreichen. Ein Reboot ist kein Problem, selbst aus harte Ausschalten einer VM ist möglich (klar ist ja nur Software). In der VM ist kein RAID-Controller, keine Festplatte die per Smart zu überwachen wäre. Die gesamte Überwachung der Hardware liegt in der Virtualisierung. Auch kein Problem, alles ist im Client zu sehen. Selbst eine ausgefallene Platte in einem eventuell vorhandenen RAID-Controller wird per Client gemeldet.
Aber einen großen weiteren Vorteil hat die Virtualisierung für den Administrator: Vor der Virtualisierung musste für eine Hardware-Wartung oder eine Hardware-Aufrüstung das Wochenende abgewartet werden, die Anwendung herunterfahren, dann die Hardware erweitert und die Anwendung wieder hochfahren. Der Samstag oder gar der Sonntag waren verloren. Mit der Virtualisierung werden alle virtuellen Maschinen per vMotion oder Live-Migration von einer Hardware auf andere Server verschoben, das geht alles im laufenden Betrieb. Ist die Hardware frei, dann kann die Hardware erweitert oder geändert werden. Dann die Virtualisierung wieder hochfahren, alles noch mal kontrollieren und die VMs im laufenden Betrieb wieder zurückschieben. Das Wochenende ist gerettet.

Funktionsweise der Virtualisierungssoftware

Die Virtualisierungssoftware stellt jedem virtuellen Server eine komplette Hardware-Umgebung zur Verfügung. Es gibt eine Festplatte an einem virtuellen SCSI-oder SAS-Controller, ein virtuelles CD oder DVD Laufwerk und eine virtuelle Netzwerkkarte. Über die CD oder DVD kann wie gewohnt das Betriebssystem auf der virtuellen Festplatte installiert werden, ein Image kann direkt verbunden werden, es muss nicht erst ein CD gebrannt werden. Der Bildschirm wird über eine Anwendung dem Administrator zur Verfügung gestellt. Es wird also auch kein zusätzlicher Bildschirm oder KVM-Switch pro virtuellen Server benötigt, zusätzliche Kostenersparnis. Meist gibt es auch die Möglichkeit, physikalische Hardware direkt einem virtuellen System zur Verfügung zu stellen. Somit kann eine eigene exklusive Netzwerkkarte genutzt werden oder ein direkter Zugriff auf Festplatten, Bandlaufwerke und RAID-Systeme ermöglicht werden.
Ein großer Vorteil dieser Technologie ist die Unabhängigkeit der virtuellen Rechner von der tatsächlich vorhandenen Hardware. Es ist ja für das Betriebssystem des virtuellen Servers alles nur virtuell vorhanden, wird also von der Virtualisierungssoftware vorgegeben. Damit kann ein virtueller Server ohne Änderung seiner Konfiguration (Treiber) von einem physikalischen Rechner auf den anderen umziehen.
Sollte ein Hardware-Server an seine Leistungsgrenzen kommen, so wird ein zweiter installiert und ein virtueller Server zieht auf die neue Hardware um und entlastet die erste Hardware. Genauso beim Ausfall des physikalischen Servers. Es muss nur die Virtualisierungssoftware auf der neuen Hardware installiert werden, für die virtuellen Systeme beliebt alles gleich. Ein einfacher und sicherer Restore für das virtuelle Betriebssystem ist möglich.

VMware ESXi (VSphere 8.x) / Microsoft Hyper-V 2022 / Proxmox / Linux KVM

Diese vier Hersteller (wir nehmen Linux mal als Hersteller) sind zurzeit die häufigsten Vertreter der Virtualisierungssoftware. Alle beherrschen natürlich die Virtualisierung von Betriebssystemen, bringen jedoch unterschiedliche Features und Ausstattungen mit. Und sie unterscheiden sich ganz erheblich im Preis.

VMware ESXi / VSphere 8.x

Bei VMware handelt es sich um den Hersteller, der verschiedene Produkte im Bereich der Virtualisierung anbietet. Dies gliedert sich in Desktop-Virtualisierung, Server-Virtualisierung als Addon auf bestehende Betriebssysteme und die Enterprise Lösung auf Basis der ESXi Server, sowie viele Basis-Technologien für Cloud Anwendungen und Hyper-Converged Systems (vSAN). Für professionelle Anwendungen wird die vSphere ESXi Familie benötigt. Hierbei gibt es den ESXi-Server, die kostenpflichtige Vollversion (in verschiedenen Lizenzen, zur zeit nur als Subscription). Die ESXi Software bringt Betriebssystem, Hypervisor und Administration mit. VSphere vCenter ist die zentrale Management Software von VMware. Sie wird als Basis für viele weitere Features benötigt, wie zum Beispiel VMotion, HA und die Storage-APIs (zum Beispiel die zentrale VMware ESXi Backup-Schnittstellen).

Microsoft Hyper-V 2022 (Hyper-V 2019 / 2016)

Bei Microsoft ist das Hyper-V eine Rolle im Windows 2022, 2019 und 2016 Server. Es gehört also zur Grundausstattung eines Windows Servers der neuen Generation. Der Hyper-V Rolle kann auf einem Server neben weiteren Anwendungen laufen und zusätzlich auch noch Servervirtualisierung anbieten. Es kann aber auch als "einzige" Rolle auf einem Windows Core Server (ohne grafische Oberfläche) installiert werden. Die Administration muss in diesem Falle über einen anderen Windows 2019 oder 2022 Server (mit grafischer Oberfläche) oder einen Windows 11 / Windows 10 Client durchgeführt werden. Ideal ist Hyper-V für reine Windows-Umgebungen, aber auch im Bereich Linux zeigt sich Microsoft offen. Es wurde Open-Source-Code veröffentlicht, der die Einbindung von Linux Gast-Systemen erleichtert.
Die Hyper-V Rolle im Windows 2019 oder 2022 benötigt die Virtualisierungsfunktionen im Prozessor.

Linux KVM

Das KVM Open-Source Projekt war vom Anfang an immer drauf bedacht, eine Integration in den Linux Kernel zu bekommen, was auch 2007 gelang. Damit entwickelt sich KVM zum bevorzugten Hypervisor unter Linux und damit auch im OpenStack Projekt.
Ob KVM jetzt ein Typ2-Hypervisor oder Typ1-Hypervisor ist, ein Bare-Metal-Hypervirsor oder doch nicht, sind eigentlich nur historische Diskussionen. Zu KVM haben wir eine eigene Dokumentation entwickelt, mit einer kurzen Einführung und einer Beispiel-Installation unter Debian.

Proxmox

Proxmox nutzt das Open Source-Projekt KVM für die Virtualisierung. Aber nicht nur KVM ist in der Proxmox Software enthalten. ZFS ist als Speicherverwaltung und Filesystem dabei, ein Cluster mit HA Funktion und Cluster Filesystem und Ceph als Storage. Vom Single Node bis zu einem komplexen HA Cluster ist alles möglich. Und das Backup ist quasi schon mit eingebaut, der externe Proxmox Backup-Server kann nahtlos integriert werden.
Neben der Virtualisierung mit KVM ist auch Linux Containers (LXC) integriert, alles über die gleiche Weboberfläche mit vielen Funktionen.
Proxmox ist mit kostenpflichtiger Subscription und damit auch mit Support vom Hersteller erhältlich. Aber auch in einer kostengünstigen Community-Version und sogar komplett kostenfrei.

Beispiel: Betrieb eines ESXi Servers

Sollen nur wenige Server virtualisiert werden, die keine Hochverfügbarkeit benötigen, so bietet sich unter anderem VMware ESXi an. Wichtig ist bei dieser Überlegung jedoch, sollte der einzige Server ausfallen, so sind alle Anwendungen offline. Sicherlich selbst für viele kleine Unternehmen nicht mehr akzeptabel.
Empfehlung für keine Unternehmen: Mindestens die Essentials Version nutzen und mindestens zwei Server.

Vorplanung / Dimensionierung

Bei der Dimensionierung müssen die Grundwerte der physikalischen Maschinen erfasst werden und auf die Virtualisierungshardware umgerechnet werden. Das ist zum einen der Hauptspeicher. Eine Auslegung ist eigentlich nicht schwer: Den Hauptspeicher der zu virtualisierenden Server addieren und noch etwas RAM für den ESXi hinzurechnen. Wichtig sind hierbei ein gutes Augenmaß und noch Reserve für den späteren Ausbau einzuplanen. Ebenso beim Plattenplatz, auch dort müssen nur die physikalischen Mengen addiert werden, die ESXi Software braucht nur wenige Gigabyte zusätzlich. Schwieriger wird es bei der CPU. Hierbei kann die Auslastung der zu virtualisierenden Maschinen als Grundlage dienen. Es sollten dann genügend Reserven eingeplant werden, da sich ein Prozessor meist später nicht so einfach tauschen lässt.
Für den Plattenplatz sollte ein guter und zuverlässiger Hardware-RAID-Controller eingeplant werden, sowie gute und schnelle Server-Platten in der passenden Kapazität. Wichtig ist bei dem Server möglichst viele Hot-Plug fähig Hardware zu verbauen. Denn wer will schon alle virtuellen Systeme runterfahren, weil eine Platte getauscht werden muss.
Um die Verfügbarkeit zu erhöhen kann später ein zweiter ESXi Server aufgebaut werden und dann ein zentrales Speichersystem (Fibre Channel, iSCSI oder NFS) angeschafft werden. Damit können die virtuellen Maschinen entweder auf dem einen oder den anderen Server gestartet werden. Aber auch ohne zentralen Speicher ist ein guter Wartungsvertrag für den Server notwendig. Immerhin fallen jetzt mehrere Anwendungen aus, wenn die Hardware Probleme hat.

Installation der virtuellen Maschinen

Als erstes muss die VMware ESXi Software installiert werden. Diese benötigt wenige Gigabyte auf der Festplatte, der Rest wird für die virtuellen Maschinen formatiert. Über die Console muss die Grundkonfiguration vorgenommen werden, wie z.B. IP-Adresse und Passwort. Danach wird über einen Webbrowser der Administrationsclient (vSphere Client) heruntergeladen. Über diesen können dann weitere Konfigurationen vorgenommen und die ersten virtuellen Maschinen installiert werden.
Die Installation läuft wie bei einer physikalischen Maschine ab. Es wird von einer CD oder DVD gebootet, bei ESX kann es auch ein Image einer CD sein. Dann wird das Betriebssystem auf die definierte Festplatte installiert. Der Monitor wird über einen Software-KVM auf dem Administrationsclient angezeigt.
Sind schon physikalische Server vorhanden und sollen die Anwendungen weiter verwendet werden, dann bietet sind der VMware-Importer an. Es wird entweder von einer CD die vorhandene physikalische Maschine gebootet und der Platteninhalt auf den ESXi transportiert oder über eine kleine Software ein "Online-Import" des Systems durchgeführt. Das alte System ist dann 1 zu 1 auf dem ESXi vorhanden. Die benötigten Treiber fügt der Importer automatisch ein.

Datensicherung der virtuellen Maschinen

Die Datensicherung der virtuellen Betriebssysteme und Daten kann wie bei physikalischen Maschinen auch über einen Client der Backup-Software und dann über das Netzwerk erfolgen. Es können Agenten für Datenbanken und Anwendungen genutzt werden, die Backup-Strategie kann praktisch eins zu eins übernommen werden. Einen weiteren Vorteil hat die Virtualisierung für die Datensicherung noch. Das Betriebssystem liegt jetzt als Datei auf dem Filesystem des ESXi Servers. Kann dies nicht geschickt genutzt werden? Der ESXi Server bietet SnapShots der VMs an, jedoch gehen diese auch wieder auf die Festplatten des ESXi. Wie es aussieht ein geschlossenes System. Na ja, nicht so ganz. Auch die ESXi Version bietet eine Shell an mit einem SSH Zugang. Aber nicht so ohne weiteres und die Bedienung ist sehr kryptisch und von Version zu Version leicht unterschiedlich.
Ist der SSH Zugang freigeschaltet, so können Skripte auf dem ESXi installiert werden. Und dann kommt der Trick: VMware ESXi kann ja auch NFS Filesysteme einbinden und nutzen. Also müssen nur die Dateien der virtuellen Maschinen auf das NFS Filesystem kopiert werden und die Sicherung ist in einem zweiten Gerät vorhanden und kann zum Beispiel auf ein Band gesichert und ausgelagert werden.
Daraus kann ein einfaches aber sicheres Backupkonzept entwickelt werden. Die Sicherung der Daten und Anwendungen wird über eine zentrale Backup-Software realisiert. Es wird zum Beispiel am Freitag eine Vollsicherung und an den anderen Wochentagen eine inkrementelle Sicherung durchgeführt. Am Samstag werden die virtuellen Maschinen kurz heruntergefahren, ein SnapShot erstellt und dann dieser SnapShot auf das NFS-Filesystem geclont (kopiert). Jetzt sind also zwei Sicherungen vorhanden: Einmal die täglichen Daten und das wöchentliche System-Backup.
Sollte jetzt der K-Fall eintreten und der VMware Server zerstört sein (inklusive der Festplatten), dann kann mit einem zweiten Server (genügend RAM und CPU-Ressourcen) die Clone der Betriebssysteme sogar direkt auf dem NFS-Speicher gestartet werden. Die Performance ist wahrscheinlich nicht so gut, aber die Maschinen laufen erst mal wieder. Allerdings mit dem Stand des letzten Wochenendes. Also noch die täglichen Sicherungen restoren und die Maschinen laufen wieder. Eine K-Fall Vorsorge, die sehr kostengünstig ist und sehr flexibel gestaltet werden kann und sich auch noch vollständig automatisieren lässt.
Eine genauere Beschreibung der Sicherung finden Sie hier.

Weiterführende Informationen zum Thema Datensicherung bei der Server-Virtualisierung und Performance-Tuning in virtuellen Umgebungen.

Für Virtualisierungsprojekte bieten wir die passenden Storage-Lösungen an, setzen Sie sich mit uns in Verbindung. Natürlich können Sie auch komplette Lösungen von uns bekommen. Egal zu welcher Virtualisierungssoftware, wir finden ein für Sie passendes Storagesystem.