Disaster Recovery im SDDC: Software-defined bedeutet agil, nicht unzerstörbar

Software-defined bedeutet agil, aber nicht unzerstörbar. Daher muss es auch im Software-defined Data Center Disaster-Recovery-Vorkehrungen geben.

Dieser Artikel behandelt

Data-Center-Design

ÄHNLICHE THEMEN

Es gibt viele Debatten darüber, wie genau sich ein Software-defined Data Center (SDDC) definiert. Dabei ist aber egal, welcher Meinung man hierzu ist – das Thema Disaster Recovery muss so oder so auf die Agenda.

Vor einiger Zeit habe ich Materialien für eine dreistündige Präsentation über die Voraussetzungen für Disaster Recovery im Softare-definierten Data Center (Software-defined Data Center, SDDC) zusammengestellt. Das ist eine Themen-Kombination, die sich so eher selten finden lassen dürfte. 

Verfechter des Software-definierten Data Centers bemerken gerne, dass die Planung für Disaster-Recovery- und Business-Continuity-Szenarien obsolet sei, sobald eine SDDC-Infrastruktur ins Spiel komme. In einem SDDC sei ja alles virtualisiert und schon vom Design her an sich hochverfügbar. Deswegen bin ich recht gespannt, wie die Themen-Kombination SDDC und Disaster Recovery bei den Besuchern meines Vortrags ankommt.

Als Teil der Vorbereitungen habe ich alle möglichen Quellen studiert und auch mit vielen Startup-Unternehmen gesprochen, die in SDDC das absolute Nonplusultra sehen. Dabei habe ich herausgefunden, dass alleine das Verständnis des Begriffs Software-defined schon eine Herausforderung ist. 

Neben der ungünstigen Nomenklatur-Schwierigkeiten, über die ich hier und da in der Vergangenheit schon berichtet habe, gibt es weitere schwerwiegende Probleme. Diese hängen mit den Komponenten der Architektur selbst zusammen. Oder zumindest hat es etwas mit den verschiedenen Ansichten der unterschiedlichen SDDC-Verfechter zu tun, was diese Komponenten sind und was sie tun sollten.

Was aggregiert Software-defined Storage: Kapazitäten oder Services?

Nehmen wir als Beispiel das Storage. SDDC-Befürworter positionieren das Storage in einem Software-defined Data Center als Software-defined Storage (SDS). Es handelt sich dabei also um eine virtualisierte Ressource, die sich genau wie das Software-defined Network und Software-definierte Prozessoren schnell und unkompliziert zuweisen lässt, um damit Hosting-Plattformen für Applikationen in Echtzeit zu erstellen.

Storage-Virtualisierung zahlt sich aus, da die „Goldenen Käfige“ der Hardware-anbieter nicht mehr existieren.

Für mich klingt das hervorragend. Ich bin schließlich auch ein großer Fan von Storage-Virtualisierung. Damit können Sie die Kapazitäten von vielen Storage-Arrays aggregieren, während der Hersteller keine Rolle mehr spielt. Die komplette Kapazität lässt sich dann in Form virtualisierter Datenträger flink zur Verfügung stellen. 

Damit stellt die Storage-Virtualisierungs-Engine eine Sammelstelle zur Verfügung, wo sich zusätzliche und nützliche Storage-Services hosten lassen. Diese wiederum lassen sich für virtuelle Datenträger verwerten. Das Ganze ist sehr agil und natürlich kosteneffizient. Storage-Virtualisierung zahlt sich aus, da die „Goldenen Käfige“ der Hardwareanbieter nicht mehr existieren. Der Trend hin zu überteuerten Storage-Arrays und isolierter Zusatz-Software auf proprietären Controllern wird dabei gehörig auf den Kopf gestellt.

Allerdings wird diese Sicht auf Software-defined Storage in Wirklichkeit gar nicht von vielen SDDC-Anhängern geteilt. Es gibt eine hitzige Diskussion über die Bedeutung von Software-defined Storage und viele führende Stimmen (vor allem aus dem Bereich Server-Virtualisierung und Hypervisor) behaupten, dass SDS mit der Aggregierung von Storage-Kapazitäten gar nichts zu tun hätte. 

Es gehe lediglich um das zentralisierte Management und um die Administration der zusätzlichen Storage-Services. Dann gilt also für IBM mit SAN Volume Controller, für DataCores erstklassige Storage-Virtualisierungs-Software und für alle anderen im Bereich Storage-Virtualisierung, dass man gar kein Software-defined Storage anbietet. Für die Neuen im SDS-Club gehören die eben genannten Unternehmen eben bereits zum alten Schlag und können nicht dieselbe Kragenweite vorweisen.

Storage-Probleme führen zu VMware vSAN

Warum virtualisiert man aber nicht auch einfach die Kapazitäten als Teil von Software-defined Storage? Keiner scheint dafür einen plausiblen Grund zu kennen, deswegen schlage ich einfach einmal einen vor. Während man Hypervisoren immer nachgesagt hat, Computing zu revolutionieren, sind sie gleichzeitig immer stärker mit dem Storage in Konflikt geraten. 

Der Trend hin zu überteuerten Storage-Arrays und isolierter Zusatz-Software auf proprietären Controllern wird gehörig auf den Kopf gestellt.

VMwares Storage-Probleme sind legendär und haben das Unternehmen gezwungen, proprietäre SCSI-Befehle einzuführen. Damit lagern Sie diverse Storage-Funktionen an die Array-Controller aus. Nur so mindern sie den gravierenden Flaschenhals im eigenen Hypervisor-Microkernel-Stack.

Daraus entstand schließlich die Diskussion über einen VMware-eigenen Storage-Hypervisor, durch den Unternehmen, die gerade erst ein Jahrzehnt für den Aufbau einer Fibre-Channel-Umgebung gebraucht hatten, all diese Storage-Ressourcen wieder auseinandernehmen müssten. 

In ähnlicher Weise würde dies wohl auch für Hyper-V, Citrix, Oracle und so weiter zutreffen, am Ende würde man so die Probleme im Storage-Management nur verschlimmern. Als diese Idee nicht so richtig funktionierte, hat VMware die interessante Storage-Variante Virtual SAN vorgestellt: eine Art Direct-Attached- und trotzdem Cluster-Shared-Storage. Man sollte dieses vSAN nicht mit Ciscos VSAN verwechseln.

Diese Unterscheidung zwischen Kapazitäten- und Service-Aggregierung hinterlässt bei mir den Eindruck, dass die SDDC-Gemeinde so viel über Storage weiß wie ein Server-Administrator, der zur Arbeit kommt und herausfindet, dass alle Storage-Administratoren gefeuert wurden. Der Server-Administrator wurde also ins kalte Wasser geworfen und muss jetzt so schnell wie möglich das ganze Fachwissen erlernen.

Schlussendlich wird er sich dann auf einen Anbieter einlassen, der ihm hoch und heilig verspricht, ein komplett vollautomatisiertes Storage-Kit zu liefern. Dazu gehört dann auch eine Storage-Cloud und irgendeine Art vSAN, mit der die Kontroll-Ebene (Services) von der Daten-Ebene (Hardware) abstrahiert wird.

Disaster Recovery gehört auch ins Software-defined Data Center

Gerade weil sich die Anhänger des Software-definierten Data Center überhaupt nicht einig sind, was nun mit Software-defined Storage gemeint ist, sollte man auch weiterhin in Disaster Recovery investieren. Vor allen Dingen auch Unternehmen, die bereits sehr früh auf Software-definierte Technologie setzen wollen. Bisher haben wir einfach noch nicht besonders viel Erfahrung über Storage auf der LUN-, Datenträger-, System- oder Infrastrukturebene.

Es gibt leider den großen Trend hin zu Uneindeutigkeiten, Ausflüchten und zu starker Vereinfachung, wenn es um die Herausforderungen und Risiken geht, die der Umbau physischer Infrastrukturen in eine Art münzbetriebenen Getränkeautomat mit sich bringt – die „Starbuck-ifizierung“ der gesamten IT, einschließlich des Storage.

Ich arbeite seit 30 Jahren im IT-Bereich und hatte bisher selten ein so großes Bedürfnis, meinen DR-Plan so schnell wie möglich ausführlich zu testen.

Über den Autor:
Jon William Toigo blickt auf 30 Jahre Erfahrung im IT-Bereich zurück. Er ist CEO und Managing Principal von Toigo Partners International sowie Vorsitzender des Data Management Institute.

Folgen Sie SearchDataCenter.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im November 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Data-Center-Design

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close