Storage. Backup. Virtualisierung.
Server-Virtualisierung - Einführung, Grundlagen und Praxis · Version 1.16 · © Stor IT Back 2026
Moderne Serversysteme verfügen über leistungsfähige Mehrkern-Prozessoren und große Hauptspeicherkapazitäten. Viele einzelne Anwendungen benötigen jedoch nur einen Teil dieser Ressourcen. Werden Anwendungen jeweils auf eigener physischer Hardware betrieben, bleiben CPU, RAM und andere Ressourcen deshalb häufig ungenutzt.
Gleichzeitig sollen Anwendungen aus Gründen der Sicherheit, Kompatibilität und Herstellerunterstützung häufig voneinander getrennt betrieben werden. Mehrere Anwendungen einfach auf einem gemeinsamen Betriebssystem zu installieren, ist daher nicht immer sinnvoll oder vom Hersteller unterstützt.
Genau hier setzt die Server-Virtualisierung an. Ein physischer Server wird in mehrere voneinander getrennte virtuelle Maschinen (VMs) unterteilt. Jede virtuelle Maschine besitzt ein eigenes Betriebssystem und erhält virtuelle Prozessoren, Arbeitsspeicher, Storage und Netzwerkschnittstellen.
Die dafür zuständige Virtualisierungsschicht beziehungsweise der Hypervisor verwaltet die vorhandenen Hardware-Ressourcen und weist sie den einzelnen virtuellen Maschinen zu. Dadurch können mehrere unabhängige Serverbetriebssysteme gleichzeitig auf derselben physischen Hardware betrieben werden.
Zu den wichtigsten Virtualisierungsplattformen im Unternehmensumfeld gehören heute VMware ESX/ESXi, Microsoft Hyper-V, Proxmox VE und KVM/QEMU.
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.
Der Hypervisor sorgt außerdem für die Isolation der virtuellen Maschinen untereinander. Eine VM kann grundsätzlich nicht direkt auf den Arbeitsspeicher oder die virtuellen Festplatten einer anderen VM zugreifen. CPU-, RAM- und I/O-Ressourcen können über Limits, Reservierungen und Prioritäten gesteuert werden. Gleichzeitig lassen sich Auslastung und Ressourcenverbrauch unabhängig vom Betriebssystem innerhalb der VM zentral überwachen und protokollieren.
Die Virtualisierungsschicht stellt die virtuelle Hardware den virtuellen Maschinen (VMs) zur Verfügung. Damit ist diese virtuelle Hardware unabhängig von der physischen 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.
Dies muss von Anfang an genau betrachtet werden. Werden zum Beispiel drei physische 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 drei Anwendungen (= alle drei Betriebssysteme) 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 drei Server, hinterher dann zwei physische Server. Fällt jetzt eine Hardware aus, so können alle virtuellen 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-Laufwerke 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 hochredundante 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 oft angenommen.
Durch die Konsolidierung mehrerer physischer Server auf wenige leistungsfähige Virtualisierungshosts kann der Energiebedarf deutlich reduziert werden. Wie groß die Einsparung tatsächlich ausfällt, hängt unter anderem von der ursprünglichen Serverauslastung, der Anzahl der konsolidierten Systeme, der eingesetzten Hardware und dem Virtualisierungsgrad ab.
Zusätzlich sinkt der Kühlbedarf im Rechenzentrum, da weniger physische Server Abwärme erzeugen. Server-Virtualisierung kann damit einen wichtigen Beitrag zu Green-IT, Energieeffizienz und einer besseren Auslastung der vorhandenen Infrastruktur leisten.
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 Konsolen der Systeme sind über den Virtualisierungsclient
(bei VMware der vSphere Client) zu erreichen. Ein Reboot ist kein Problem, selbst
das harte Ausschalten einer VM ist möglich (klar ist ja nur Software).
In der VM ist kein RAID-Controller, keine Festplatte die mittels S.M.A.R.T. 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 einen anderen Host 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.
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 eine 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 virtuellem Server benötigt,
zusätzliche Kostenersparnis. Meist gibt es auch die Möglichkeit, physische
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 physischen
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 physischen Servers. Es muss
nur die Virtualisierungssoftware auf der neuen Hardware installiert werden,
für die virtuellen Systeme bleibt alles gleich. Ein einfacher und sicherer
Restore für das virtuelle Betriebssystem ist möglich.
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.
| Plattform | Technologie | Typischer Einsatz | HA / Cluster | Container |
|---|---|---|---|---|
| VMware ESX / ESXi | Proprietärer Hypervisor | Enterprise-Rechenzentren und größere Virtualisierungsumgebungen | vSphere HA | Nicht Schwerpunkt der Plattform |
| Microsoft Hyper-V | Typ-1-Hypervisor | Windows- und Microsoft-Umgebungen | Windows Server Failover Clustering | Windows-Container separat verfügbar |
| Proxmox VE | KVM / QEMU und LXC | KMU bis Enterprise, Open-Source-Virtualisierung | Proxmox VE HA-Cluster | LXC integriert |
| KVM / QEMU | Linux KVM und QEMU | Individuelle Linux-, Cloud- und Virtualisierungsplattformen | Abhängig vom eingesetzten Management- und Cluster-Stack | Über zusätzliche Linux-Technologien, z. B. LXC |
VMware gehört zu den etablierten Anbietern für Server-Virtualisierung im Rechenzentrum. Mit VMware vSphere beziehungsweise den aktuellen VMware-Cloud-Foundation- und VMware-vSphere-Foundation-Produkten stehen umfangreiche Funktionen für Virtualisierung, zentrale Administration, Hochverfügbarkeit, Live-Migration und Storage-Integration zur Verfügung.
Mit der Produktgeneration 9 verwendet VMware für den Hypervisor wieder die Bezeichnung VMware ESX. Die vorherige Generation wird weiterhin als VMware ESXi 8 bezeichnet. Für bestehende Installationen und bei der Suche nach technischen Informationen sind deshalb beide Begriffe relevant.
Die zentrale Administration mehrerer Hosts erfolgt über VMware vCenter Server. Darüber stehen unter anderem Funktionen wie vMotion für die Live-Migration virtueller Maschinen, High Availability (HA), zentrale Lifecycle-Verwaltung sowie Schnittstellen für Storage und Datensicherung zur Verfügung.
VMware bietet darüber hinaus Technologien wie vSAN für softwaredefinierten und hyperkonvergenten Storage. Lizenzierung und Funktionsumfang unterscheiden sich je nach eingesetztem VMware-Produkt und sollten insbesondere bei Neuplanungen geprüft werden.
Microsoft Hyper-V ist die in Windows Server integrierte Virtualisierungstechnologie von Microsoft und als Serverrolle unter anderem in Windows Server 2025 verfügbar. Hyper-V arbeitet als Typ-1-Hypervisor und ermöglicht den Betrieb von Windows- und Linux-Gastsystemen.
Für produktive Virtualisierungsumgebungen kann Windows Server als dedizierter Hyper-V-Host betrieben werden. Besonders Server Core eignet sich durch die reduzierte lokale Oberfläche und den geringeren Wartungsumfang für diesen Einsatz. Die Administration erfolgt beispielsweise über Windows Admin Center, PowerShell oder zentrale Microsoft-Managementwerkzeuge.
Für Hochverfügbarkeit können mehrere Hyper-V-Hosts zu einem Failover-Cluster verbunden werden. Live Migration ermöglicht dabei die Verschiebung laufender virtueller Maschinen zwischen Hosts. Hyper-V eignet sich insbesondere für Unternehmen, die bereits stark auf Windows Server, Active Directory und andere Microsoft-Technologien setzen.
KVM (Kernel-based Virtual Machine) ist seit 2007 Bestandteil des Linux-Kernels und stellt die grundlegenden Virtualisierungsfunktionen für Linux bereit. In der Praxis wird KVM häufig gemeinsam mit QEMU eingesetzt. KVM übernimmt dabei die hardwaregestützte Virtualisierung, während QEMU unter anderem virtuelle Hardware und Geräte für die virtuellen Maschinen bereitstellt.
KVM bildet die technische Grundlage zahlreicher Virtualisierungs- und Cloud-Plattformen, darunter auch Proxmox VE und verschiedene OpenStack-Umgebungen. Funktionen wie Live-Migration, virtuelle Netzwerke, unterschiedliche Storage-Systeme und Cluster-Lösungen können über zusätzliche Linux-Komponenten und Managementplattformen integriert werden.
Zu KVM haben wir eine eigene Dokumentation mit einer Einführung und einer Beispielinstallation unter Debian erstellt.
Proxmox VE ist eine Open-Source-Plattform für Server-Virtualisierung und kombiniert mehrere bewährte Linux-Technologien in einer zentral administrierbaren Lösung.
Für klassische virtuelle Maschinen verwendet Proxmox VE KVM/QEMU. Zusätzlich sind LXC-Container integriert. Virtuelle Maschinen und Container können gemeinsam über die Weboberfläche, die Kommandozeile oder die API verwaltet werden.
Für Storage unterstützt Proxmox VE unter anderem lokale Laufwerke, ZFS, NFS, iSCSI, Fibre Channel und verteilten Ceph-Storage. Mehrere Proxmox-Hosts lassen sich zu einem Cluster verbinden. Für hochverfügbare Umgebungen stehen HA-Funktionen zur Verfügung.
Der Proxmox Backup Server (PBS) lässt sich als speziell auf Proxmox VE abgestimmte Backup-Lösung integrieren und unterstützt unter anderem inkrementelle Sicherungen, Deduplizierung und zentrale Backup-Verwaltung.
Proxmox VE kann grundsätzlich ohne Lizenzkosten eingesetzt werden. Für produktive Unternehmensumgebungen bietet Proxmox kostenpflichtige Subscriptions mit Zugriff auf das Enterprise Repository und Herstellersupport in unterschiedlichen Supportstufen an.
Sollen nur wenige Server virtualisiert werden, die keine Hochverfügbarkeit
benötigen, so bietet sich unter anderem VMware ESX/ESXi an. Wichtig ist bei
dieser Überlegung jedoch, sollte der einzige Server ausfallen, sind
alle Anwendungen offline. Das ist selbst für viele kleine Unternehmen häufig nicht mehr akzeptabel.
Empfehlung für kleine Unternehmen: Mindestens zwei Server nutzen.
Bei der Dimensionierung einer Virtualisierungsumgebung sollten CPU-, RAM-, Storage- und Netzwerkbedarf der vorhandenen Systeme erfasst werden. Neben den aktuell belegten Ressourcen müssen Lastspitzen, Wachstum sowie Reserven für Wartung und den Ausfall eines Hosts berücksichtigt werden.
Besonders wichtig ist die Dimensionierung des Arbeitsspeichers, da RAM in vielen Virtualisierungsumgebungen die zuerst limitierende Ressource ist. Bei HA-Clustern muss außerdem sichergestellt werden, dass die verbleibenden Hosts beim Ausfall eines Systems genügend Ressourcen für die betroffenen virtuellen Maschinen bereitstellen können.
Beim Storage sind nicht nur Kapazität, sondern insbesondere IOPS, Durchsatz und Latenz zu betrachten. Abhängig vom Konzept können lokaler Storage, SAN, NAS oder verteilte Storage-Lösungen wie VMware vSAN oder Ceph eingesetzt werden.
br>Zuerst 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 Konsole muss die Grundkonfiguration vorgenommen werden,
wie zum Beispiel IP-Adresse und Passwort. Bei einem Standalone-ESXi erfolgt die Verwaltung über den browserbasierten VMware Host Client.
Bei vCenter ebenfalls browserbasiert über den vSphere Client. Über diese können
dann weitere Konfigurationen vorgenommen und die ersten virtuellen Maschinen
installiert werden.
Das Gastbetriebssystem wird in der Regel über ein eingebundenes
ISO-Image oder automatisierte Deployment-Verfahren installiert. Die Konsole der VM
wird über einen Software-KVM in dem Administrationsbrowser angezeigt.
Sind schon physische Server vorhanden und sollen die Anwendungen weiter
verwendet werden, dann bietet sich der VMware vCenter Converter Standalone an. Es wird entweder
von einer CD die vorhandene physische 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.
Für die Datensicherung virtueller Maschinen stehen grundsätzlich zwei Verfahren zur Verfügung: die Sicherung über einen Agenten innerhalb des Gastbetriebssystems und die imagebasierte Sicherung über die Schnittstellen der Virtualisierungsplattform.
Bei einer agentenbasierten Sicherung wird die Backup-Software innerhalb der virtuellen Maschine installiert. Dieses Verfahren funktioniert ähnlich wie bei einem physischen Server und eignet sich insbesondere für anwendungsbezogene Sicherungen von Datenbanken und anderen Applikationen.
Bei einer imagebasierten VM-Sicherung arbeitet die Backup-Software dagegen mit dem Hypervisor zusammen und sichert die virtuelle Maschine einschließlich ihrer virtuellen Festplatten und Konfiguration. VMware stellt hierfür entsprechende Schnittstellen für Datensicherungslösungen bereit. Moderne Backup-Produkte können damit virtuelle Maschinen zentral und weitgehend unabhängig vom Betriebssystem innerhalb der VM sichern.
Snapshots sind dabei kein eigenständiges Backup. Sie werden von Backup-Systemen häufig kurzfristig verwendet, um während der Sicherung einen konsistenten Zustand der virtuellen Festplatten bereitzustellen. Der eigentliche Sicherungsbestand muss anschließend auf einem unabhängigen Backup-System gespeichert werden.
Für ein belastbares Backup-Konzept sollten die Sicherungen außerhalb der produktiven Virtualisierungsumgebung gespeichert werden. Je nach Schutzbedarf können zusätzlich immutable oder offline gespeicherte Kopien eingesetzt werden. Für geschäftskritische Systeme sollten regelmäßig Wiederherstellungstests durchgeführt und definierte RPO- und RTO-Vorgaben berücksichtigt werden.
Bei VMware muss außerdem zwischen den Lizenzvarianten unterschieden werden. Kommerziell lizenzierte VMware-Umgebungen können von entsprechenden Backup-Produkten über die VMware-Schnittstellen gesichert werden. Bei kostenlosen ESXi-Versionen können diese Schnittstellen eingeschränkt sein, sodass vor der Auswahl der Backup-Lösung die jeweilige Lizenz und deren Funktionsumfang geprüft werden muss.
Weiterführende Informationen zum Thema Datensicherung bei der Server-Virtualisierung und Performance-Tuning in virtuellen Umgebungen.
Server-Virtualisierung bedeutet, dass mehrere virtuelle Server (virtuelle Maschinen, kurz VMs) auf einer einzigen physischen Hardware laufen können. Jede VM wirkt wie ein eigener Server mit eigenem Betriebssystem, Anwendungen und Einstellungen. Möglich wird das durch eine Virtualisierungssoftware, die die Hardware-Ressourcen (CPU, RAM, Speicher, Netzwerk) verteilt. Praktisch heißt das: Statt zehn physische Server zu betreiben, können Sie, je nach Last, zehn virtuelle Server auf wenigen Hosts bündeln und flexibel verschieben.
Ein Hypervisor ist die Software-Schicht, die virtuelle Maschinen erstellt, startet und voneinander trennt. Er sorgt dafür, dass eine VM nicht in eine andere hineinfunkt und dass Ressourcen fair zugewiesen werden. Man unterscheidet grob zwei Arten: Hypervisor direkt auf der Hardware (typisch im Rechenzentrum) und Hypervisor auf einem bestehenden Betriebssystem (häufig für Tests). Für Admins ist der Hypervisor der zentrale Dreh- und Angelpunkt, weil hier Performance, Sicherheit, Updates und Automatisierung zusammenlaufen.
Der größte Vorteil ist bessere Auslastung: Viele physische Server sind im Alltag nur zu einem kleinen Teil beschäftigt, während sie dennoch Strom, Platz und Wartung kosten. Virtualisierung erhöht die Effizienz und vereinfacht Prozesse wie Bereitstellung, Backup und Wiederherstellung. Außerdem werden Ausfälle leichter handhabbar, weil VMs zwischen Hosts verschoben oder auf anderer Hardware neu gestartet werden können. Ein konkretes Beispiel: Ein Testsystem lässt sich als VM-Vorlage in Minuten ausrollen statt Hardware zu bestellen und zu installieren.
Virtualisierung lohnt sich fast immer, sobald mehrere Server betrieben werden oder sich Workloads häufig ändern (z. B. Projekt- und Testumgebungen). Für Entscheider ist der Hebel oft: weniger Hardware, weniger Energie, weniger Einzelserver-Silos und schnellere Bereitstellung. Für Admins bringt es standardisierte Abläufe, bessere Übersicht und Automatisierungsmöglichkeiten. Ausnahmen können sehr spezielle Systeme mit extrem niedrigen Latenzanforderungen oder proprietärer Hardware sein, auch dort gibt es aber oft hybride Ansätze.
Kosten entstehen typischerweise durch leistungsfähigere Hosts (CPU, RAM), Shared Storage oder schnelle lokale Speicherlösungen,
Netzwerkinfrastruktur und Lizenzen/Support für Virtualisierung und Management. Einsparungen kommen häufig aus reduzierter Serveranzahl,
geringerem Strom- und Kühlbedarf sowie weniger Aufwand für Hardware-Tausch und Neuinstallationen.
Zusätzlich sparen Teams Zeit: Bereitstellung, Patching und Wiederherstellung werden standardisierter und schneller.
Tipp: Rechnen Sie nicht nur Hardware, sondern auch Betriebsaufwand (Stunden pro Monat) und Ausfallkosten mit ein.
Für die meisten Organisationen ist ein schrittweiser Start am risikoärmsten. Beginnen Sie mit unkritischen Systemen (z. B. interne Tools, Dev/Test, kleinere Web-Dienste) und sammeln Sie Betriebserfahrung. Danach folgen Standard-Workloads wie File-/Print-Services, Applikationsserver oder kleine Datenbanken, bevor geschäftskritische Systeme migriert werden. Ein Pilot-Cluster mit klar definierten Erfolgskriterien (Performance, Wiederherstellungszeit, Betriebsaufwand) ist oft die beste Grundlage für eine Entscheidung über die Skalierung.
Nicht automatisch, moderne Hosts sind sehr leistungsfähig und Ressourcen können dynamisch zugeteilt werden.
Probleme entstehen meist durch Überbelegung (also zu viele VMs teilen sich zu wenig CPU/RAM) oder durch Flaschenhälse bei Storage und Netzwerk.
Besonders Speicher-I/O (viele kleine Lese/Schreibvorgänge) entscheidet über gefühlte Geschwindigkeit.
Tipp: Planen Sie Kapazitätsreserven ein und beobachten Sie Metriken wie CPU-Ready/Wait, RAM-Druck, Storage-Latenz und Netzwerk-Durchsatz.
Hochverfügbarkeit heißt, dass ein Ausfall eines Hosts nicht automatisch einen längeren Systemausfall bedeutet. In vielen Virtualisierungs-Setups überwacht
das System die Hosts und startet betroffene VMs bei Problemen automatisch auf einem anderen Host neu.
Das ersetzt nicht jede Form von Null-Ausfallzeit, reduziert aber die Downtime deutlich.
Beispiel: Fällt ein Host nachts aus, laufen die wichtigsten VMs nach wenigen Minuten auf einem anderen Host weiter und alles ohne manuelles Eingreifen.
Meist gibt es mehrere physische Hosts, die gemeinsam einen Cluster bilden, damit Last verteilt und Ausfälle abgefangen werden können. Dazu kommt ein gemeinsamer Speicherbereich (z. B. über ein Storage-System oder verteilten Speicher), auf dem die VM-Daten liegen. Ein Management-Werkzeug bündelt Administration, Monitoring, Rechte und Automatisierung. Im Alltag arbeiten Sie dann eher mit VMs und Policies statt mit einzelner Serverhardware.
Beides ist möglich: Virtualisierung kann Sicherheit verbessern, weil Systeme klar getrennt sind und sich Rechte zentral steuern lassen.
Gleichzeitig wird der Hypervisor zur kritischen Schicht, wenn der kompromittiert wird, so betrifft es potenziell viele VMs.
Wichtig sind deshalb sauberes Patch-Management, strikte Admin-Rollen, getrennte Management-Netze und Protokollierung (Logging).
Tipp: Behandeln Sie die Management-Ebene (den Hypervisor) wie ein Tier-0-System: minimaler Zugriff, starke Authentifizierung, möglichst keine Alltagsarbeiten darüber.
VM-Sprawl beschreibt das unkontrollierte Wachstum von VMs: schnell erstellt, selten gelöscht, irgendwann unübersichtlich und teuer. Das passiert besonders in Organisationen ohne klare Prozesse für Anforderung, Freigabe, Laufzeit und Abschaltung. Gegenmaßnahmen sind einfache Regeln: Jede VM bekommt Owner, Zweck, Ablaufdatum/Review-Termin und ein standardisiertes Namensschema. Ein gutes Praxisbeispiel ist ein Self-Service-Portal mit Genehmigungsworkflow, das gleichzeitig automatisch dokumentiert.
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.
