Storage. Backup. Virtualisierung.
Virtualisierung von Storage / Speicher · Version 1.16 · © Stor IT Back 2026
Kurz erklärt: Storage-Virtualisierung fasst physische Speicherressourcen zu einer zentral verwalteten logischen Ebene zusammen. Server und Anwendungen greifen auf virtuelle Volumes oder Datastores zu, ohne die zugrunde liegende Hardware direkt verwalten zu müssen. Dadurch lassen sich Kapazitäten flexibler bereitstellen, Systeme leichter migrieren und Funktionen wie Snapshots, Replikation, Tiering oder Thin Provisioning zentral umsetzen.
Ursprünglich bezeichnete der Begriff vor allem das flexible Mapping physischer Laufwerke auf logische Volumes – vergleichbar mit RAID-Technologie und flexibler Partitionierung. Heute umfasst Storage-Virtualisierung zusätzlich die zentrale Administration und Überwachung ganzer Storage-Landschaften. Neben blockbasierter Virtualisierung gewinnt auch die dateibasierte Virtualisierung an Bedeutung.
Eng damit verbunden ist Software-defined Storage. Dabei reichen die Ansätze von der zentralen Verwaltung klassischer Storage-Systeme bis zu softwarebasierten Lösungen, bei denen Standardserver mit lokalen Laufwerken Storage-Dienste bereitstellen. Welche Architektur geeignet ist, hängt insbesondere von Performance, Verfügbarkeit, Herstellerunterstützung und Betriebsmodell ab.
Storage-Virtualisierung kann an mehreren Stellen umgesetzt werden: direkt im Storage-System oder RAID-Controller, hostbasiert auf Applikationsservern, netzwerkbasiert als In-Band- oder Out-of-Band-Schicht sowie als Software-defined Storage auf Standardservern.
Bei einer dezentralen Umsetzung liefern die Hersteller eigene Werkzeuge für Administration und Überwachung. Gemeinsame Schnittstellen ermöglichen eine zentrale Steuerung über Fibre Channel oder LAN. In Cloud- und virtualisierten Umgebungen wird die Storage-Schicht zunehmend in durchgängige Bereitstellungsprozesse für Speicher, Netzwerk, Betriebssystem und Anwendungen eingebunden.
Die folgenden Abschnitte erläutern die Virtualisierung im Storage-System sowie die In-Band- und Out-of-Band-Virtualisierung im Detail.
Bei dieser Variante sind die Virtualisierungsfunktionen direkt im Storage-System integriert. Zusätzliche Server oder Appliances sind nicht erforderlich; RAID-Verwaltung und Virtualisierung werden in einer gemeinsamen Oberfläche administriert. Eine typische Einschränkung besteht darin, dass sich Storage-Systeme unterschiedlicher Hersteller nicht ohne Weiteres zu einem gemeinsamen Pool zusammenfassen lassen.
Je nach Hersteller kann die Lösung geclustert und auf zwei Standorte verteilt werden. Da keine separate Virtualisierungs-Appliance im Datenpfad liegt, ist eine hohe Performance möglich. Welche zusätzlichen Protokolle und Funktionen bereitstehen, hängt vom jeweiligen System ab.
Beispiele für umfangreiche Virtualisierungsfunktionen im Storage-System sind NetApp-FAS-Systeme und die Dell-EMC-Unity-Serie.
Bei der In-Band-Virtualisierung liegt die Hard- und Software direkt im Datenpfad zwischen Server und Storage-System. Die Schicht stellt virtuelle Volumes bereit und kann – abhängig von der Lösung – zusätzliche Protokolle und Funktionen integrieren.
Da sämtliche I/O-Daten die Virtualisierungsschicht durchlaufen, ist deren Ausfallsicherheit besonders wichtig. Eine Störung kann die gesamte SAN-Umgebung beeinträchtigen. Der Vorteil liegt in der direkten Kontrolle des Datenstroms; dadurch lassen sich beispielsweise Serverless-Backup-Funktionen oder zusätzliche Zugriffsmöglichkeiten realisieren.
Zur Leistungssteigerung können SSD- oder RAM-Ressourcen als Cache eingebunden werden. Die Lösung virtualisiert die angeschlossenen Storage-Systeme und stellt den Servern logische Volumes bereit. Diese Topologie wird auch als „symmetrische Storage-Virtualisierung“ bezeichnet. Beispiele sind IBM SVC, EMC VPLEX und DataCore SANsymphony.
Bei der Out-of-Band-Virtualisierung liegt die Steuerungs- und Metadatenebene außerhalb des eigentlichen Datenpfads.
Fällt die Steuerungsschicht aus, können grundlegende Datenpfade je nach Architektur zunächst weiter funktionieren. Zuordnungen, Konfigurationen oder Verwaltungsfunktionen können jedoch nicht mehr verfügbar sein. Auch diese Variante muss deshalb redundant und hochverfügbar geplant werden.
Out-of-Band-Lösungen arbeiten typischerweise mit Storage-Protokollen wie Fibre Channel, SAS und iSCSI. Die Ressourcen werden über spezielle Hardware im Host-Bus-Adapter oder über eine Softwareschnittstelle in die Applikationsserver eingebunden.
In Cloud-Umgebungen kann diese Technik die automatisierte Bereitstellung von Speicher unterstützen. Voraussetzung ist, dass Cloud-Software und Storage-System über kompatible Schnittstellen verfügen. Diese Topologie wird auch als „asymmetrische Storage-Virtualisierung“ bezeichnet.
Ob Storage-Virtualisierung sinnvoll ist, hängt von der vorhandenen Infrastruktur, den Betriebsanforderungen und dem gewünschten Automatisierungsgrad ab.
Für hochverfügbare Umgebungen sollten Virtualisierungs- und Storage-Komponenten auf getrennte Brandabschnitte oder Standorte verteilt werden. Redundante Hardware allein schützt nicht, wenn alle Komponenten von demselben Ausfall betroffen sind.
Die Grundlage einer hochverfügbaren Storage-Virtualisierung ist eine redundante Virtualisierungs-Appliance beziehungsweise ein Cluster. Bei einem Failover-Cluster stellt eine Appliance die Dienste bereit, während die zweite überwacht und im Fehlerfall übernimmt. In einem Lastausgleichs-Cluster teilen sich beide Systeme die Aufgaben und überwachen sich gegenseitig.
Cluster und Storage-Systeme sollten auf zwei getrennte Brandabschnitte oder Standorte verteilt werden. Die Virtualisierung kann Daten zwischen den Storage-Systemen spiegeln, sodass die Anwendungen beim Ausfall eines Systems ohne manuellen Eingriff weiterarbeiten können.
Sind auch Netzwerk und Server redundant ausgelegt, kann die Umgebung selbst den Ausfall eines vollständigen Standorts überstehen. In Kombination mit Server-Virtualisierung entsteht eine hochverfügbare Infrastruktur, die zentral administriert und überwacht werden kann.
Storage-Virtualisierung kann unterschiedliche Funktionen bereitstellen. Umfang, Bezeichnung und technische Umsetzung unterscheiden sich je nach Hersteller. Die folgende Übersicht dient daher als Leitfaden; die konkrete Realisierung muss für das jeweilige System geprüft werden.
Die erste Möglichkeit, den Plattenplatz bei einem RAID-System zu erhöhen, besteht darin, dem Grundgerät zusätzliche JBODs hinzuzufügen. Diese Methode beherrscht nahezu jedes System; sie wird als vertikale Skalierbarkeit bezeichnet.
Der Vorteil ist, dass die JBODs kostengünstiger sind als ein RAID-Grundsystem
und dass nur ein Grundsystem überwacht werden muss. Der Nachteil ist
jedoch, dass die Performance durch das Grundsystem begrenzt ist. Der RAID-Controller
hat nur einen gewissen Durchsatz und die Anbindung an das SAN ist meist auch
auf vier Ports begrenzt. Bei 8 Gbit/s Fibre Channel ergibt sich daraus rechnerisch ein maximaler Durchsatz von 32 Gbit/s.
Diese Nachteile hebt die horizontale Skalierbarkeit auf. Es wird ein neues Grundsystem
mit den vorhandenen kombiniert. Es können auch vorhandene Volumes über
mehrere Grundsysteme verteilt werden. Da jedes Grundsystem eigene RAID-Controller
und damit auch eigene Anschlüsse zum SAN mitbringen, steigert dies nicht nur die Kapazität, sondern auch die Performance. Vier eigenständige Grundsysteme mit jeweils 4 × 8 Gbit/s erreichen zusammen rechnerisch 128 Gbit/s
zum SAN.
Das nebenstehende Bild zeigt die horizontale Skalierbarkeit eines Storage-Systems.
Es wird ein gemeinsamer Storage-Pool aus verschiedenen Grundgeräten gebildet.
Die virtuelle Festplatte wird auf alle Grundsysteme verteilt. Fordert jetzt
ein Server Daten von seiner virtuellen Festplatte ab, so können beide Grundsysteme
zur gleichen Zeit die Daten liefern. Der Durchsatz verdoppelt sich nahezu. Das Gleiche gilt für Schreibvorgänge: Die Daten werden auf die
beiden Systeme verteilt, auch dort wird die doppelte Performance erreicht.
Die Verteilung der Daten übernimmt der Storage-Pool, also der Zusammenschluss
der vorhandenen Grundgeräte. Weder Server noch Betriebssystem wissen, dass
hinter dem Storage-Pool mehrere Grundsysteme stehen. Das ist völlig transparent
für alle weiteren Schichten. Wird jetzt ein zusätzliches Grundsystem
in einen vorhandenen Pool integriert, dann werden die Daten über alle Systeme
verteilt.
Thin Provisioning weist einem Betriebssystem logisch mehr Speicherplatz zu, als physisch sofort belegt wird. Tatsächlich wird zunächst nur die Kapazität verbraucht, die für geschriebene Daten und Dateisystemstrukturen benötigt wird. Dadurch lassen sich ungenutzte Reserven reduzieren und Kapazitäten flexibler planen.
Die physisch verfügbare Kapazität muss trotzdem kontinuierlich überwacht werden. Werden mehrere virtuelle Volumes überprovisioniert, können die realen Speicherressourcen später knapp werden. Frühzeitige Warnschwellen und ein definierter Erweiterungsprozess sind deshalb unverzichtbar.
Beispiel: Ein Betriebssystem sieht ein virtuelles Dateisystem mit 2 TB. Solange nur 500 MB Nutzdaten und 2 MB Dateisystemstrukturen geschrieben wurden, belegt das Volume physisch ungefähr 502 MB. Zusätzliche Kapazität wird erst bei weiterer Nutzung zugewiesen. Bei Erreichen definierter Grenzwerte müssen Festplatten ergänzt oder weitere Storage-Systeme in den Pool aufgenommen werden.
Replikation und Spiegelung verfolgen das Ziel, Daten auf zwei Systemen oder an zwei Standorten vorzuhalten. Dadurch lassen sich Ausfälle und Katastrophenszenarien besser absichern.
Bei der Replikation wird häufig mit einem Primär-/Sekundärverfahren gearbeitet. Bei synchroner Replikation erhält der Server die Schreibbestätigung erst, wenn die Daten auf beiden Systemen gespeichert sind. Das erhöht die Datenkonsistenz, kann aber die Schreiblatenz steigern. Bei asynchroner Replikation bestätigt das Primärsystem den Schreibvorgang früher und überträgt die Daten zeitversetzt. Die Anwendungskonsistenz muss je nach Lösung durch geeignete Mechanismen sichergestellt werden.
Bei der Spiegelung werden Daten gleichzeitig auf beide Storage-Systeme geschrieben. Die Umsetzung ist häufig aufwendiger und kann eine In-Band-Virtualisierung erfordern, die das RAID 1 über beide Systeme bereitstellt. Siehe dazu auch den Abschnitt „Virtualisierung und Hochverfügbarkeit“.
Tiering verteilt Daten abhängig von Performance-, Verfügbarkeits- und Kostenanforderungen auf unterschiedliche Medien oder Storage-Systeme. Innerhalb eines RAID-Systems können beispielsweise SSD-, SAS- und SATA-Medien kombiniert werden; Storage-Virtualisierung kann darüber hinaus mehrere RAID-Systeme in ein gemeinsames Tiering-Konzept einbeziehen.
So lassen sich besonders wichtige oder performancekritische Daten auf Dual-Controller-Systemen ablegen, während ältere oder weniger kritische Daten kostengünstigere Storage-Klassen nutzen. Anwendungen greifen weiterhin über eine einheitliche virtuelle Speicherschicht auf die jeweiligen Tiers zu. Weitere Informationen zum Thema Tiering.
Storage-Virtualisierung schafft eine flexible, zentral verwaltete Speicherschicht. Ihr Nutzen hängt jedoch von einer sorgfältigen Planung ab: Funktionen, Performance, Hochverfügbarkeit, Herstellerkompatibilität, Kapazitätsreserven und Betriebsprozesse müssen gemeinsam betrachtet werden.
Sie planen eine Storage-Virtualisierung oder möchten eine bestehende Umgebung bewerten? Kontaktieren Sie uns für eine herstellerunabhängige Beratung. Ergänzend bieten wir herstellerunabhängige Schulungen und Praxis-Workshops zu Storage Area Networks, DAS, NAS, iSCSI und Virtualisierung an.
Storage-Virtualisierung fasst physischen Speicher (verschiedene Arrays, Pools oder Disks) zu einer logischen Ebene zusammen, die einfacher zu verwalten ist. Anwendungen und Server sehen dann nicht mehr, welches Gerät dahintersteht, sondern z. B. nur noch logische Volumes oder Datastores. Das erleichtert Umzüge, Erweiterungen und Standardisierung, weil Speicher ausgetauscht werden kann, ohne jeden Host neu anzufassen. Für Entscheider ist wichtig: Ziel ist nicht technische Magie, sondern weniger Betriebsaufwand und mehr Flexibilität im Lebenszyklus.
Ein großer Vorteil ist die Entkopplung von Hardware und Bereitstellung: Kapazität kann ergänzt werden, und Systeme lassen sich häufig ohne geplante Downtime austauschen. Häufig verbessern sich Auslastung und Kosten, weil Speicherpools besser geteilt werden und weniger ungenutzte Reserven entstehen. Zudem lassen sich Funktionen wie Replikation, Snapshots (Zeitpunkt-Kopien) oder Tiering (automatisches Verschieben zwischen schnellen und günstigen Medien) konsistenter nutzen. Beispiel: Ein Unternehmen migriert von Array A zu Array B, während die Server weiterlaufen, weil die Virtualisierung die Daten im Hintergrund verschiebt.
Nicht ganz. Server-Virtualisierung teilt Rechenleistung auf virtuelle Maschinen auf, Storage-Virtualisierung abstrahiert Speicherressourcen.
Beide folgen jedoch demselben Prinzip: Hardware wird austauschbarer und Ressourcen werden flexibler zugewiesen.
In der Praxis wirken sie zusammen: Viele Storage-Virtualisierungsansätze sind besonders für VM-Umgebungen attraktiv, weil dort häufig
neue Datastores, Klone und Migrationen gebraucht werden.
Tipp: Trennen Sie in der Kommunikation sauber Server-/VM-Virtualisierung und Storage-Virtualisierung, damit Erwartungen realistisch bleiben.
Häufig unterscheidet man hostbasiert, storage- beziehungsweise arraybasiert und netzwerkbasiert (z. B. über eine Storage-Schicht zwischen Host und Arrays). Hostbasiert bedeutet: Die Logik läuft auf dem Server (z. B. Volume-Manager), arraybasiert: im Storage-System selbst, netzwerkbasiert: in einer separaten Virtualisierungs-Appliance oder -Software. Jede Variante hat Vor- und Nachteile bei Komplexität, Performance und Abhängigkeiten. Praxisregel: Je zentraler die Virtualisierung, desto wichtiger werden Verfügbarkeit und saubere Redundanzplanung.
Pooling bündelt Kapazität in logische Speicherpools, aus denen Volumes dynamisch bereitgestellt werden. Der Mehrwert entsteht durch Regeln: z. B. unterschiedliche Serviceklassen (schnell vs. günstig), Kontingente (Quotas), Replikationsrichtlinien oder automatische Platzierung. Ohne Regeln wird Pooling schnell unübersichtlich und endet in einem „Jeder nutzt alles“, was Performance- und Verantwortungsfragen erzeugt. Tipp: Definieren Sie mindestens 2–3 klare Storage-Klassen (z. B. „Tier 1 DB“, „VM Standard“, „Archive“) und ordnen Sie Workloads bewusst zu.
Ein zentraler Nutzen ist die unterbrechungsarme Migration: Daten können im Hintergrund von System A nach System B wandern, während Hosts weiter auf die gleichen logischen Volumes zugreifen. So lassen sich Wartungsfenster verkürzen und große Umzüge planbarer machen. Oft wird auch die Anwendungsseite einfacher, weil Mountpoints, Laufwerksbuchstaben oder Datastore-Namen gleich bleiben. Tipp: Planen Sie Migrationen trotzdem wie ein Projekt: Tests, Performance-Vergleich, Rollback-Plan und klare Cutover-Kriterien.
Nicht automatisch, aber sie kann neue Engpässe schaffen, wenn die Virtualisierungsschicht falsch dimensioniert ist oder zusätzliche Wege in den Datenpfad bringt. In vielen modernen Systemen ist der Overhead gering, solange CPU-, Cache- und Port-Ressourcen ausreichend dimensioniert sind und das Design zu den Workloads passt. Kritisch sind häufig nicht die Virtualisierung, sondern falsche Tiering-Regeln, überfüllte Pools oder ungünstige I/O-Mischungen (z. B. viele kleine Random-Writes auf HDD-Tier). Tipp: Messen Sie Latenz und Queue-Tiefe pro Workload und setzen Sie Baselines, bevor Sie Optimierungen vornehmen.
Beides ist möglich. Manche Lösungen entkoppeln von Herstellern, weil verschiedene Storage-Systeme unter einer einheitlichen Schicht betrieben und leichter ausgetauscht werden können. Andere binden stärker, weil zentrale Funktionen (Replikation, Management, Datenformate) sehr spezifisch sind und ein Wechsel komplizierter wird. Entscheidend ist, ob Standardschnittstellen genutzt werden und wie portabel Daten und Richtlinien sind. Tipp: Fragen Sie bei der Auswahl gezielt nach Exit-Strategie: Wie migrieren wir in 3–5 Jahren weg – realistisch, mit welchem Aufwand?
Neben Lizenz- und Hardwarekosten zählen vor allem Betriebsaufwand, Ausfallrisiken und Projektdauer bei Migrationen. Storage-Virtualisierung lohnt sich oft, wenn häufige Erweiterungen, mehrere Storage-Generationen oder im Unternehmen häufige Änderungen anstehen. In stabilen, kleinen Umgebungen kann sie hingegen unnötige Komplexität einführen. Praxisansatz: Rechnen Sie nicht nur €/TB, sondern auch Kosten pro Änderung, Wartungsfenster pro Jahr und Risikokosten (Ausfallstunden, Recovery-Zeit).
Ein häufiger Fehler ist, ohne klare Serviceklassen zu starten: Dann landet alles im gleichen Pool, und am Ende sind Performance-Diskussionen vorprogrammiert. Ein weiterer Fehler ist eine zu knapp bemessene Kapazitätsreserve (besonders bei Thin Provisioning und Snapshot-Wachstum), wodurch die Umgebung plötzlich voll läuft. Auch organisatorisch kritisch: Wenn Rollen unklar sind (wer ist zuständig für Policies, Quotas, Eskalation), wird die Plattform schwer steuerbar. Tipp: Starten Sie mit einem Pilot-Workload, definieren Sie Standards (Namenskonventionen, Klassen, Alarmgrenzen) und skalieren Sie erst dann breit.
