Storage für Server-Virtualisierung: Shared Storage, HCI und Software-defined Storage

Storage für die Server-Virtualisierung – Einführung

Bei einer Server-Virtualisierung sind neben den Hypervisor-Hosts vor allem Storage, Netzwerk und deren Redundanz für Performance und Verfügbarkeit entscheidend. Virtuelle Maschinen benötigen dauerhaft verfügbare Speicherkapazität, auch wenn ein einzelner Virtualisierungs-Host ausfällt oder gewartet wird.

Bei klassischen Virtualisierungsumgebungen wird dafür häufig ein zentraler Shared Storage eingesetzt. Mehrere Hosts greifen gemeinsam auf das Storage-System zu, beispielsweise über Fibre Channel, iSCSI, NFS oder moderne NVMe-over-Fabrics-Protokolle wie NVMe/FC und NVMe/TCP. Multipathing und redundante Storage-Controller sorgen dafür, dass einzelne Verbindungen oder Komponenten ausfallen können, ohne den Zugriff auf die virtuellen Maschinen zu unterbrechen.

Neben zentralen SAN- und NAS-Systemen haben sich Software-defined Storage und Hyperconverged Infrastructure (HCI) etabliert. Dabei werden lokale SSDs oder NVMe-Laufwerke mehrerer Virtualisierungs-Hosts zu einem verteilten Storage zusammengefasst. Bekannte Beispiele sind VMware vSAN und Ceph in Verbindung mit Proxmox VE.

Welche Architektur geeignet ist, hängt unter anderem von Kapazität, IOPS, Latenz, Verfügbarkeitsanforderungen, Skalierbarkeit, Wiederanlaufzeit und Budget ab. Besonders wichtig ist dabei die Frage, wie Daten gegen den Ausfall einzelner Laufwerke, Hosts, Storage-Systeme oder kompletter Standorte geschützt werden.

Software-defined Storage (SDS)

Software-defined Storage (SDS) trennt Storage-Funktionen weitgehend von einer proprietären Storage-Appliance. Funktionen wie Datenverteilung, Redundanz, Replikation, Caching und Storage-Management werden durch Software realisiert und können auf standardisierten Serverplattformen betrieben werden.

In virtualisierten Umgebungen lässt sich der lokale Speicher mehrerer Hosts zu einem gemeinsamen verteilten Storage zusammenfassen. Die virtuellen Maschinen greifen anschließend auf einen logischen Storage-Pool zu, obwohl die Daten physisch über mehrere Server und Laufwerke verteilt sind.

Ein bekanntes Beispiel ist VMware vSAN. vSAN ist in die VMware-vSphere-Umgebung integriert und nutzt lokale Laufwerke der ESXi-Hosts für einen gemeinsam verfügbaren Datastore. Moderne vSAN-Architekturen können NVMe- und SSD-basierte Storage-Pools verwenden. Die gewünschte Verfügbarkeit und Datenredundanz wird über Storage Policies festgelegt. Abhängig von Architektur und Clustergröße stehen beispielsweise Spiegelung (RAID 1) oder Erasure Coding in Form von RAID 5 beziehungsweise RAID 6 zur Verfügung.

Ein weiteres Beispiel ist Ceph. Ceph ist ein verteilter Open-Source-Storage und kann unter anderem Block Storage über RBD, Dateispeicher über CephFS und Object Storage über den RADOS Gateway bereitstellen. In Verbindung mit Proxmox VE lässt sich Ceph direkt auf den Virtualisierungs-Hosts betreiben und damit eine hyperkonvergente Infrastruktur aufbauen.

Für die Performance eines Software-defined Storage sind insbesondere Netzwerkbandbreite, Latenz, Storage-Medien und die gewählte Redundanz entscheidend. Schreibvorgänge müssen je nach Schutzverfahren auf mehrere Laufwerke oder Hosts verteilt werden. Deshalb sollte das Storage-Netzwerk ausreichend dimensioniert und möglichst redundant aufgebaut werden.

Bewertung der Verfügbarkeit des Storage-Systems

Ein Storage-System ist in der Regel bereits redundant aufgebaut. Redundante Netzteile und Lüfter gehören bei Enterprise-Storage-Systemen zum Standard. Auch die Laufwerke werden durch ein geeignetes RAID-Verfahren oder ein vergleichbares Schutzverfahren gegen Ausfälle abgesichert. Je nach eingesetztem RAID-Level können ein oder mehrere Laufwerke ausfallen, ohne dass die gespeicherten Daten unmittelbar verloren gehen. Ein Hot-Spare-Laufwerk kann automatisch in den Rebuild einbezogen werden und ein ausgefallenes Laufwerk ersetzen.

Storage-Systeme für die Server-Virtualisierung gehen meist noch einen Schritt weiter. Häufig sind zwei weitgehend unabhängige Storage-Controller vorhanden. Beide Controller verfügen über eigene Prozessoren, Arbeitsspeicher und weitere Hardware-Komponenten und überwachen gegenseitig ihren Betriebszustand. Fällt ein Controller aus, kann der verbleibende Controller dessen Aufgaben übernehmen. Bei einer korrekt konfigurierten redundanten Host-Anbindung und funktionierendem Multipathing erfolgt diese Umschaltung für die angeschlossenen Server in der Regel transparent.

Damit kann ein einzelnes Storage-System bereits eine sehr hohe Verfügbarkeit erreichen. Gegen standortbezogene Störungen wie Brand, Wasser, einen längerfristigen Stromausfall oder andere größere Schäden schützt diese interne Redundanz jedoch nicht. Für solche Szenarien kann eine Replikation der Daten auf ein zweites Storage-System in einem getrennten Brandabschnitt oder an einem zweiten Standort erforderlich sein.

Warum kann eine solche Replikation wichtig sein? Fällt ein komplettes Storage-System oder sogar ein gesamter Standort aus, müssen die Daten ohne Replikation zunächst aus einer Datensicherung wiederhergestellt werden. Abhängig von der Datenmenge, der Performance der Backup-Infrastruktur und der Anzahl der wiederherzustellenden Systeme kann dieser Vorgang viele Stunden oder sogar mehrere Tage dauern.

Bei einer Storage-Replikation steht dagegen bereits eine zusätzliche Kopie der produktiven Daten auf einem zweiten System zur Verfügung. Im Katastrophenfall (K-Fall) kann auf dieses System umgeschaltet werden. Befinden sich auch geeignete Virtualisierungs-Hosts beziehungsweise Ersatzserver am zweiten Standort, können die betroffenen virtuellen Maschinen dort wieder gestartet werden. Abhängig von Architektur, Automatisierungsgrad und getesteten Notfallverfahren lassen sich dadurch deutlich kürzere Wiederanlaufzeiten erreichen.

Ob eine synchrone oder asynchrone Replikation erforderlich ist, hängt von den Anforderungen des Unternehmens an Datenverlust und Wiederanlaufzeit ab. Bei einer synchronen Replikation werden Schreibvorgänge entsprechend der eingesetzten Technologie auf beide Storage-Systeme übertragen, bevor sie bestätigt werden. Dadurch kann auf Storage-Ebene grundsätzlich ein sehr niedriger beziehungsweise ein RPO von 0 erreicht werden. Eine asynchrone Replikation überträgt Änderungen dagegen zeitversetzt und eignet sich deshalb auch für größere Entfernungen und höhere Netzwerklatenzen.

Eine Replikation muss nicht zwingend durch die Storage-Systeme selbst erfolgen. Auch softwarebasierte Lösungen können virtuelle Maschinen oder deren Daten auf ein zweites System replizieren. E in Beispiel ist Veeam Backup & Replication. Damit lassen sich virtuelle Maschinen abhängig von der eingesetzten Plattform und Konfiguration auf einen zweiten Virtualisierungs-Host beziehungsweise Storage replizieren. Eine solche Lösung kann insbesondere dann interessant sein, wenn die Replikation unabhängig vom eingesetzten Storage-System erfolgen soll.

Klassischer Aufbau einer Virtualisierungslösung mit Shared Storage

Wie schon beschrieben gibt es verschiedene Möglichkeiten, eine Virtualisierungslösung aufzubauen. Die einfachste Variante sind zwei Server und ein Storage-System. In diesem Beispiel besitzt das Storage-System (Dell EMC Unity) zwei RAID Controller, daher muss jeder Server auch mit zwei Kanälen an das Storage angeschlossen werden (jeweils ein Kanal pro Controller bzw. Service Prozessor der Unity). Sollte jetzt ein Kanal im Server, ein LWL Kabel oder ein Controller im Storage-System ausfallen, so kann die Multipathing-Software (die bei VMware ESXi, Hyper-V, Proxmox und KVM enthalten ist) automatisch auf den verbleibenden Kanal umschalten. Die Daten bleiben weiter für die virtuellen Maschinen verfügbar.

In diesem Beispiel sind die Server mit Fibre Channel angebunden und zwar direkt an das Storage ohne Switch. Dies geht in dem Beispiel, weil das Storage-System über 2 Kanäle verfügt und damit 2 Server direkt angeschlossen werden können. Werden mehr als 2 Server benötigt, dann wird bei diesem Storage ein Fibre-Channel-Switch oder zusätzliche Host-Karten pro Service Prozessor benötigt. Um genauer zu sein, man benötigt dann 2 Fibre-Channel-Switche, ebenfalls wegen der Redundanz. Sollte ansonsten der einzige vorhandene Switch ausfallen, dann verlieren alle Server die Verbindung zum Storage, alle virtuellen Maschinen fallen aus.

Für den Zugriff auf Shared Storage stehen unterschiedliche Protokolle zur Verfügung. Im Block-Storage-Bereich werden unter anderem Fibre Channel, iSCSI, NVMe/FC und NVMe/TCP eingesetzt. Dateibasierter Shared Storage kann beispielsweise über NFS bereitgestellt werden. Welches Protokoll sinnvoll ist, hängt von Hypervisor, Storage-System, vorhandener Netzwerkinfrastruktur, Performance-Anforderungen und Entfernung ab.

Virtualisierung mit Storage-Replikation

Der Aufbau mit den Servern bleibt auch in diesem Fall gleich, es werden nur aus den 2 jetzt 4 Server. Dies ist aber unerheblich für die Replikation. Nur sollten die Server auch an beide Brandabschnitte verteilt werden. Wichtig sind jetzt aber die beiden Storage-Systeme. Sie replizieren die Daten entweder synchron oder asynchron zwischen den Systemen. In den meisten Fällen können beide Storage-Systeme aktiv Daten anbieten, allerdings nicht die gleichen LUNs.

Also das eine Storage ist aktiv für die LUN 1 und das andere dann für die LUN 2. Sollte jetzt das eine System ausfallen, so muss die bisher nicht aktive LUN dann für die Server aktiv geschaltet werden. Damit können die Server auf diese LUN zugreifen. War es eine synchrone Spiegelung, dann kann ohne Datenverlust direkt weitergearbeitet werden, meist nach einem manuellen Eingriff. Damit kann der Ausfall eines kompletten Brandabschnitts abgefangen werden. Das ist immer dann sinnvoll, wenn ein längerer Ausfall der Systeme auch bei größeren Störungen nicht akzeptabel ist. Oder wenn so große Datenmengen vorhanden sind, das eine Recovery über Bänder oder Disksysteme nicht in einem akzeptablen Zeitrahmen möglich ist. Ein einfaches Beispiel: Wenn Sie maximal mit 200 MB/s Daten auf ein System bringen können, sie nutzen aber 40 TB, dann werden im Idealfalle über 55 Stunden benötigt. In der Praxis wird eine Recovery sicherlich deutlich über eine Woche dauern, da eine Sicherung bei dieser Menge nur noch inkrementell möglich ist. Mit einer Replikation sind die Daten innerhalb von wenigen Minuten wieder nutzbar.

Wer braucht eine Replikation? Eigentlich alle, die keinen auch nur so geringen Datenverlust selbst im K-Fall akzeptieren können und bei denen selbst kurze Ausfälle einen hohen Schaden verursachen. Was muss neben der Replikation sonst noch an Basisvorgaben erfüllt sein? Die Systeme sollten an zwei Brandabschnitten verteilt aufgebaut sein. Viele äußere Gefahren wie Brand oder Wasser lassen sich so vermeiden, das richtige Konzept einmal vorausgesetzt. Deutlich häufiger sind Stromausfälle, die sich nur mit redundanten Einspeisungen abfangen lassen. Die Ausstattung mit einer USV pro Brandabschnitt ist dabei trotzdem Standard.

Vom internen Storage zur Hyperconverged Infrastructure

Bereits frühe Software-defined-Storage-Lösungen versuchten, die lokalen Laufwerke von Virtualisierungs-Hosts als gemeinsamen Storage bereitzustellen. Ein historisches Beispiel war die VMware vSphere Storage Appliance (VSA). Die Lösung wurde jedoch bereits 2014 aus dem Vertrieb genommen und spielt in aktuellen Virtualisierungsumgebungen keine praktische Rolle mehr.

Das grundlegende Konzept, lokalen Storage mehrerer Hosts zu einem hochverfügbaren verteilten Storage zusammenzufassen, wurde anschließend durch moderne HCI- und SDS-Plattformen weiterentwickelt. Heute gehören insbesondere VMware vSAN und Ceph zu den bekannten Lösungen in diesem Bereich.

Hyperconverged Infrastructure (HCI)

Bei einer Hyperconverged Infrastructure (HCI) werden Rechenleistung, Storage und Virtualisierung auf denselben Cluster-Knoten betrieben. Anstelle eines separaten zentralen Storage-Systems stellen die lokalen Laufwerke mehrerer Server gemeinsam den Storage für die virtuellen Maschinen bereit.

Die Daten werden verteilt und entsprechend der gewählten Storage-Policy redundant auf mehreren Laufwerken beziehungsweise Hosts gespeichert. Dadurch kann der Cluster den Ausfall einzelner Datenträger oder, bei entsprechender Auslegung, kompletter Hosts verkraften.

Bekannte Beispiele sind VMware vSAN und Ceph in Verbindung mit Proxmox VE. Beide Ansätze stellen verteilten Storage bereit, unterscheiden sich jedoch deutlich bei Architektur, Lizenzmodell, unterstützten Zugriffsmethoden und Einsatzmöglichkeiten.

Der Aufbau ist fast identisch und hat auch recht ähnliche Voraussetzungen.

Warum ist das Netzwerk bei HCI so wichtig?

Bei hyperkonvergenten Storage-Systemen ist das Netzwerk Bestandteil des Storage-I/O-Pfads. Schreibdaten müssen abhängig von der gewählten Redundanz auf weitere Hosts beziehungsweise OSDs übertragen werden. Bandbreite und insbesondere Latenz beeinflussen deshalb unmittelbar die Storage-Performance.

Zusätzlich benötigt ein verteilter Storage Bandbreite für Rebuilds, Rebalancing und Recovery-Vorgänge. Fällt ein Laufwerk oder ein kompletter Host aus, müssen fehlende Daten oder Redundanzen im Cluster neu aufgebaut werden. Das Storage-Netzwerk sollte deshalb nicht nur für die normale Nutzlast, sondern auch für solche Recovery-Situationen dimensioniert werden.

Ersetzt HCI eine Storage-Replikation zwischen zwei Standorten?

Nicht automatisch. Die Datenredundanz eines HCI-Clusters schützt zunächst gegen definierte Fehler innerhalb des Clusters, beispielsweise den Ausfall eines Laufwerks oder Hosts. Soll zusätzlich ein kompletter Standortausfall abgesichert werden, müssen Failure Domains, Stretched-Cluster-Konzepte oder eine separate Replikation berücksichtigt werden.

VMware vSAN und Ceph im Vergleich

Welche Storage-Lösung eignet sich für welche Virtualisierungsumgebung?

Für kleinere Virtualisierungsumgebungen kann ein direkt angebundenes oder kompaktes Shared-Storage-System eine wirtschaftliche Lösung sein. Bei mehreren Hosts und hohen Anforderungen an Verfügbarkeit und Performance kommen häufig redundante SAN-Systeme mit Fibre Channel, iSCSI oder NVMe over Fabrics zum Einsatz.

Hyperconverged Systeme eignen sich besonders, wenn Compute und Storage gemeinsam skaliert und zentral administriert werden sollen. VMware-Umgebungen können hierfür vSAN einsetzen, während sich bei Proxmox VE Ceph als integrierter verteilter Storage anbietet.

Bei sehr hohen Verfügbarkeitsanforderungen sollte zusätzlich zur lokalen Redundanz geprüft werden, ob eine Storage-Replikation, ein Stretched Cluster oder eine Disaster-Recovery-Lösung zwischen getrennten Standorten erforderlich ist. Die Entscheidung sollte sich an den geforderten RPO- und RTO-Werten sowie an Kapazität, Performance und Wiederherstellungszeit orientieren.

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 eine für Sie passende Storagelösung, ob Direct Attached, klassisch als SAN oder Hyper-Converged.