Server-Virtualisierung - Einführung V1.14 (c) Stor IT Back 2025
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 physikalischen 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.
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.
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.
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.
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.
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.
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.
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).
Bei Microsoft ist das Hyper-V eine Rolle im Windows 2025, 2022 und 2019 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 2025 oder 2022 Server (mit grafischer Oberfläche)
oder einen Windows 11 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 2025 oder 2022 benötigt die Virtualisierungsfunktionen
im Prozessor.
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 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.
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.
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.
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.
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.
Was bedeutet Server-Virtualisierung überhaupt?
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 Virtualisierungs-Software, 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.
Was ist ein Hypervisor und warum ist er so wichtig?
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.
Welche Vorteile hat Virtualisierung gegenüber rein physischer Hardware?
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.
Für wen lohnt sich Server-Virtualisierung besonders?
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.
Welche Kosten entstehen und wo liegen die Einsparungen?
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 Recovery werden standardisierter und schneller.
Tipp: Rechnen Sie nicht nur Hardware, sondern auch Betriebsaufwand (Stunden pro Monat) und Ausfallkosten mit ein.
Wie starte ich sinnvoll: Big Bang oder schrittweise Migration?
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.
Wird alles langsamer, wenn mehrere Server, bzw. VMs auf einem Host laufen?
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.
Was bedeutet Hochverfügbarkeit (HA) und warum ist sie ein Kernargument?
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.
Wie sieht ein typisches Virtualisierungs-Setup einfach erklärt aus?
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.
Ist Virtualisierung sicher, oder vergrößert sie die Angriffsfläche?
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.
Was bedeutet VM-Sprawl und wie verhindere ich das?
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.
