Über Speichervirtualisierung

Virtualisierung ist in aller Munde. Alles und jeder wird virtualisiert – nur das mit der Cloud ist noch schlimmer (Cloud-Salat). So ist der Begriff der Virtualisierung im Storage-Bereich auch schon länger angekommen, lässt aber ebenfalls schon länger keine Rückschlüsse darauf zu, was eigentlich gemeint ist.

Eine Variante von Speicher-„Virtualisierung“ hat HP schon lange im Programm (schon bevor es zum Buzzword wurde, behaupte ich mal): EVA. Enterprise Virtual Array. Da wird innerhalb der Speichermaschine virtualisiert. Bei den klassischen Arrays, seien es EMC² AX, CX oder HP MSA oder NetApp FAS oder oder… sieht der Admin Controller und Platten, baut RAID-Sets (Aggregates bei NetApp) mit einem RAID-Level aus von ihm bestimmten Platten zusammen, legt Volumes an und stellt sie als LUNs zur Verfügung. Dazu muss er wissen, was auf den Volumes laufen wird, um die RAID-Level richtig zu wählen und die Anzahl der Platten passend zu bestimmten für die geforderte Performance und Verfügbarkeit – was dann für die Zukunft auch statisch so ist und bleibt. Bei einer EVA sieht der Admin die einzelnen Platten nur zur Information über den Hardware Status und um Speicher Pools zu definieren. Innerhalb eines Pools gibt der Admin Eigenschaften bzw. Anforderungen wie das Redundanz-Niveau vor. Dann legt er Volumes innerhalb der Speicher Pools an, für die er wiederum das Redundanz-Niveau und die gewünschte Größe definiert. Wie die EVA dann intern tatsächlich die Daten über die Platten verteilt, weiß der Admin nicht. Das ist dynamisch und abhängig davon, wie viele Volumes mit welchen Anforderungen es gibt. So ändert sich auch mit der Zeit die Menge des verfügbaren Speichers in einem Pool, denn die EVA balanciert und striped die Volumes dynamisch über den gesamten Pool. Das ermöglicht prinzipiell, dass sie die Verteilung auf Spindeln aus Performance- oder Platz-Sicht optimiert. Angeblich tut sie das auch – unmittelbar nachvollziehbar ist das im Detail aber nicht, ist halt virtualisiert.

SAN-Virtualisierung im Sinne von DataCore und anderen sieht hingegen so aus, dass man einen Windows Server braucht, auf dem die DataCore Software installiert wird. Was immer an Storage dem Server zur Verfügung steht – sei es Direct Attached (DAS) oder unterschiedliche SAN-Arrays im Backend, erst mal muss es der Windows Server erreichen können – kann dann als Basis für die Funktionalität verwendet werden. D.h. es wird das tatsächliche Backend virtualisiert/abstrahiert und nach vorne einheitlich per iSCSI präsentiert (das kann mit kleinerem Feature-Set auch mit einem Windows Storage Server erreicht werden).

SANmelody ist dabei auf ein HA-Pärchen limitiert, SANsymphony unterstützt N+1 Redundanz. Loadbalancing findet nur zu den Backends statt (wobei auch erst SANsymphony Multipathing-Arrays unterstützt), d.h. die Anwendungsserver (iSCSI Initiators) sprechen immer mit einem Target (DataCore Server). Andere Vertreter dieser Gattung sind OpenFiler, aber auch – in anderem Maßstab – HP SVSP.

Dann taucht in dem Zusammenhang auch noch ein HP Produkt auf, das allerdings weniger selbst virtualisiert als dass es wirklich optimal als Storage für Virtualisierungsumgebungen geeignet ist: HP P4000 (the artist formerly known as „Lefthand“). Was dort virtualisiert wird, ist eigentlich nur die Anzahl der Knoten; es wird ein Cluster gebildet aus N Knoten, der von allen iSCSI Initiators über eine Cluster-IP angesprochen wird und die tatsächlichen Verbindungen dann auf die beteiligten Knoten verteilt. Es entsteht ein „hyperredundanter“ Speicher-Cluster, der immer gleichzeitig Platz und Performance skaliert, sehr performant und praktisch immer Feature-complete ist (einmal kaufen, nichts nachlizensieren). Die Redundanz bis hoch zur Knoten-Ebene (Ausfall eines kompletten Speicherknotens) ist transparent für die iSCSI Clients, ein aufwändiges, fehleranfälliges und möglicherweise sogar manuelles Failover zwischen Sites ist nicht nötig.

Allerdings können P4000 Speicherknoten auch virtuell sein – als Virtual SAN Appliance (VSA) für VMware ESX(i), die wiederum das komplette Feature-Set zur Verfügung stellt. Betrachtet man nun also den ESX-Host als Vergleich zum o.g. Windows Server, der als Basis für z.B. DataCore SANsymphony dient, dann kann man mit einer P4000 VSA alle dem Host zur Verfügung stehenden Storage Backends nutzen und einheitlich, mit dem gesamten P4000 Funktionsumfang, präsentieren, mithin also virtualisieren. In diesem Konstrukt sind allerdings schon so viele Ebenen beteiligt, durch die ein Datenblock zum Lesen oder Schreiben wandern muss, dass das Szenario seine Grenzen haben sollte.

Bevor ich jetzt noch in Diskussionen oder Vergleiche einsteige (das hebe ich mir für einen anderen Beitrag auf), sage ich nur noch: Welches Schweinderl hätten’s denn gern? Nur weil ein Produkt oder Angebot das Label „Virtualisierung“ trägt, sagt das alleine noch nichts über seine tatsächliche Beschaffenheit oder Funktionsweise aus. Nicht von den Verkäufern einlullen lassen, immer hinterfragen und auf kompetente Beratung bestehen (und darin investieren), um herauszufinden, was für meine konkreten Anforderungen die passende Lösung ist!

Datensicherung ist kein Notfallplan

In den meisten größeren Unternehmen ist man sich des Unterschieds zwischen Datensicherung und Disaster Recovery bewusst, doch im Mittelstand fehlt diese Einsicht oft.

Die Datensicherung ist dazu da, Daten zu sichern und im Bedarfsfall wiederherstellen zu können. Daten, nicht ganze Systeme, sondern Nutzdaten. Also Dateien, Datenbanken etc., die versehentlich oder aus welchen Gründen auch immer gelöscht, überschrieben oder beschädigt wurden.

Ein Notfallkonzept betrachtet Großschadensfälle vom Hardware-Ausfall (System-Platten statt oder zusätzlich zu den Nutzdaten-Platten, zentrale Komponenten, die zum Ausführen von Betriebssystem und/oder Anwendungen/Diensten erforderlich sind, …) bis zur Nicht-Verfügbarkeit von Infrastruktur-Elementen wie Stromversorgung, Netzwerk, Anbindung reichen.

Das Notfallkonzept ist sehr individuell und vielfältig, denn es muss nicht nur verschiedene Szenarien betrachten, sondern auch unterschiedlichen Anforderungen an die Verfügbarkeit gerecht werden. So ergeben sich für die Auslegung einer zentralen Infrastruktur Verfügbarkeitsklassen, die Systemen/Diensten zugeordnet werden, und darauf basierend unterschiedliche Auslegungen der Infrastrukturelemente, die diese Systeme bereitstellen, sowie verschiedene Maßnahmenkataloge für den je nach Szenario notwendigen Wiederanlauf.

Abhängig von den umgesetzten Redundanz-Niveaus (Rahmen-Infrastruktur wie Strom, Kühlung etc., Netzwerk passiv und aktiv, Storage, Virtualisierung, Verfügbarkeitscluster) gibt es nur noch bestimmte Szenarien, die überhaupt dazu führen, dass eine Unterbrechung (Disaster) eintritt und ein Disaster Recovery erforderlich wird. Fällt beispielsweise ein ganzer Standort aus, aber sämtliche Daten und Systeme sind dank Speicher- und Server-Virtualisierung auch in einem weiteren Standort vorhanden und ausführbar, so liegt aus Infrastruktur-Sicht kein Disaster vor (Definitionssache, aber zumindest kann, entsprechende Kapazitäten vorausgesetzt, alles weiter ausgeführt und bereitgestellt werden). Dieses Niveau lässt sich etwa mit einem Storage Cluster aus HP MSA P4000 (ehemals „Lefthand“) und entsprechend aufgebauter Virtualisierungsinfrastruktur (Citrix, VMware, Microsoft) erreichen.

Man reduziert so die Wahrscheinlichkeit, aber irgendwie kann es doch immer noch passieren, dass mal ein System komplett wiederhergestellt werden muss. Sei es aufgrund von Kompromittierung durch einen Angreifer (neu installieren oder auf einen definitiv sauberen Stand zurück gehen) oder durch beschädigte Daten im Systembereich. Dafür muss es entsprechende Mechanismen geben, die etwa auf Imaging-Verfahren oder einer Software-Verteilung inkl. Betriebssystem-Installation basieren könnten. Die Möglichkeiten klassischer Backup Software sind hier meist eingeschränkt, erlauben bei entsprechend sauberer Umsetzung aber zumindest die Wiederherstellung auf absolut identischer Hardware. Oft ist das aber gar nicht mehr das Problem, da die „Hardware“ sowieso eine Virtuelle Maschine ist. Aber es reicht nicht aus, einfach „alles“ mit der Datensicherung zu sichern.

Datensicherung ist kein Notfallplan. Wer eine Datensicherung einkauft und umsetzt, hat davon kein Notfallkonzept für Komplettausfälle von Systemen.