Software-Defined Datacenter vereinfacht Ausfallsicherheit
Nächste Evolutionsstufe im Katastrophenschutz
Business Continuity, Ausfallschutz oder Disaster Recovery sind für nahezu alle Unternehmen keine Neuheit und lassen sich durch unterschiedliche Techniken in der Praxis umsetzen. Doch die Ansprüche steigen, und die Komplexität der Lösungen für Ausfallschutz wächst überproportional mit. Viele unterschiedliche Systeme sind dabei aufeinander abzustimmen und geben Raum für diverse Fehlerquellen - auch menschlicher Art. Einen eleganten Ansatz zum Thema Ausfallsicherheit liefert jetzt das "Software-Defined Datacenter".Der Markt bietet heute eine Vielzahl an Disaster-Recovery-Lösungen. Zahlreiche davon sind sehr leistungsfähig, jedoch auch sehr komplex bei der Installation und im laufenden Betrieb. So haben beispielsweise die Hersteller einzelner Rechenzentrums- und Netzwerkkomponenten sowie von Applikationen, Datenbanken, Betriebssystemen, Servern oder Speichersystemen jeweils ihre eigenen, isolierten Disaster-Recovery-Werkzeuge entwickelt. Diese Lösungen beziehen sich in der Regel jedoch lediglich auf eine bestimmte Komponente und oft auch nur auf die hauseigenen Systeme. Daher bieten sie keinen umfassenden Katastrophenschutz für das gesamte, zumeist heterogene Rechenzentrum. Um dieses Problem zu lösen, existieren bereits seit Jahren Standards und entsprechende Programmierschittstellen (APIs). Mit diesen technischen Hilfsmitteln lässt sich ein umfassendes Disaster Recovery für das komplette Rechenzentrum realisieren. Eine weitere wichtige Voraussetzung sind Lösungen, die den Failover-Prozess koordinieren können. Aber auch dort stellt die Komplexität das Kernproblem dar, weil die Abstimmung der unterschiedlichen Komponenten mit sehr großem Zeitaufwand verbunden ist. Komplexität anhand eines typischen Beispiels Ein typisches Szenario aus dem gehobenen Mittelstand: Ein Unternehmen betreibt zwei Rechenzentren innerhalb einer Stadt mit einer guten Verbindung von zweimal 10 GBit/s und einer Round-Trip-Zeit von 0,1 Millisekunden. Die Infrastruktur in den Rechenzentren sowie die Verbindung zwischen ihnen sind aus Sicherheitsgründen redundant ausgelegt. Damit ein Failover des Rechenzentrums möglich ist, sind die Daten an beiden Standorten gleichzeitig vorhanden. Die schnelle Verbindung und die geringe Latenzzeit lassen eine synchrone Spiegelung des Storage zu. Aus Sicht der Speicher-Hochverfügbarkeit ist damit einem Ausfallschutz Genüge getan. Doch wie sieht es mit der Server-Infrastruktur aus? Failover-Prozess bei Cluster-Lösungen Zwar sind in diesem Fall die Daten an beiden Standorten identisch, doch das Failover der Server in das Backup-Rechenzentrum ist keinesfalls eindeutig geregelt. Dafür sind zumeist Cluster-Lösungen im Einsatz, die diese Aufgabe gut bewältigen. Je nach Plattform kommen unterschiedliche Verfahren in Frage: Microsoft beispielsweise schaltet die Windows-Server um, VMware die Virtual Machines und IBM HACMP (High Availability Cluster Multi-Processing) die AIX-Server. Damit die Cluster-Lösung den Failover-Prozess fehlerfrei durchführt, ist es erforderlich, dass auch der Storage entweder ein transparentes Failover bietet, oder das Cluster-Werkzeug die Datenbereiche selbst im Speicher mittels Storage-API von Kopie auf Original umschaltet. Beide Verfahren haben ihre Vor- und Nachteile, was eine sehr genaue Analyse im Vorfeld nötig macht, um im Ernstfall nicht mit zusätzlichen Problemen kämpfen zu müssen. Transparentes Storage Failover und IP-Adressen Transparentes Storage Failover lässt sich einfach realisieren, zudem ist die Speicherspiegelung mit dem definierten Original und der Kopie sehr sicher. Produkte zur Storage-Virtualisierung wie zum Beispiel EMC Vplex, Falconstor, Datacore oder Netapp Metrocluster bieten dieses transparente Failover. Die klassischen Spiegelungslösungen mit definiertem Original und Kopie kommen etwa von EMC oder Hitachi. Nächstes Thema ist das Netzwerk an sich. Auch wenn die Entfernung zwischen den beiden Rechenzentren nicht groß ist, liegen sehr wahrscheinlich zwei unterschiedliche Netzwerke vor. Dies bedeutet, dass sich beim Failover eines Servers dessen IP-Adresse nicht einfach übernehmen lässt. Jeder Server benötigt eine neue, im Backup-Rechenzentrum gültige IP-Adresse, da sonst keine Kommunikation möglich ist. Dies erfordert eine zentrale Koordination, wobei gleichzeitig der Client-Zugriff anzupassen ist. Anwender beispielsweise müssen ebenfalls die neue Server-IP-Adresse aus dem Backup-RZ erhalten. Um letztere Aufgabe zu lösen, existieren geeignete Instrumente und Lösungen. Dennoch zeigt dieses Beispiel insgesamt recht deutlich, wie viele unterschiedliche Komponenten und Systeme aufeinander abzustimmen sind und wie hoch die Möglichkeit eines Fehlers ist. Failover auf Applikationsebene Um das gesamte Rechenzentrum ausfallsicher zu gestalten, muss auch ein Failover auf Applikationsebene stattfinden. Heutige Anwendungen greifen häufig auf mehrere Datenbanken zu und laufen auf einer Vielzahl an Servern. Für Failover oder Crash Recovery einer einzelnen Applikation existieren effiziente Lösungen. Sind jedoch mehrere Datenbestände logisch verknüpft und auf verschiedenen Servern in unterschiedlichen Bereichen im Storage gespeichert, greifen auch die besten Failover-Lösungen für eine Anwendung nicht. Eine Applikation, die auf mehr als einer Datenbank basiert, kann nur fehlerfrei arbeiten, wenn alle dazugehörigen Datenbanken nicht nur konsistent sind, sondern auch auf den gleichen RPO (Recovery Point Objective) verweisen. Vereinfacht ausgedrückt: Die Applikation ist nur dann konsistent, wenn alle Datenbanken konsistent sind und den gleichen Zeit-stempel haben. Anwendungen mit mehreren Datenbanken Dazu ein weiteres Beispiel: Eine Anwendung basiert auf drei Datenbanken. Beim Verlust des Produktionsrechenzentrums - beispielsweise durch einen Brand - werden Server zu unterschiedlichen Zeitpunkten beschädigt. Aus diesem Grund schreiben die drei Datenbanken unterschiedlich lange in das Log-File. Wenn keine speziellen Maßnahmen greifen, stellt der Recovery-Prozess die Datenbanken mit unterschiedlichen Zeitstempeln wieder her und die auf den drei Datenbanken basierenden Anwendungen sind dementsprechend inkonsistent. Die Datenbanken selbst jedoch sind alle konsistent. Um die Inkonsistenz der Applikationen zu verhindern, müssen die verschiedenen Restore-Prozesse koordiniert ablaufen und anhalten, sobald das erste Log wiederhergestellt ist. Auf diese Weise sind die Datenbanken auf einem zeitlich identischen Niveau, was die Konsistenz der darüber liegenden Applikation ermöglicht. Die übrigen, im Log verbliebenen Operationen sind anschließend erst zu löschen, bevor der Produktivbetrieb starten kann. Bei größeren Datenbanken und mehreren, im Unternehmen eingesetzten Applikationen ist das Failover somit eine große Herausforderung für IT-Verantwortliche. Lösung durch Software-Defined Datacenter Die Komplexität in einzelnen Bereichen eines Rechenzentrums, die Beziehungen der Komponenten und das möglichst durchgängige Failover stellen Unternehmen vor schwer zu bewältigende Aufgaben. Zudem kommen immer neue Anforderungen an zusätzliche Funktionen hinzu, die mit weiteren Produkten abzudecken sind. Genau aus diesem Grund steigt die Komplexität eines Rechenzentrums-Failovers mit der Zeit exponentiell an. Neue Lösungsstrategien und Konzepte sind daher gefordert. Einen möglichen Ansatz für zukünftige Disaster-Recovery-Lösungen stellt das Software-Defined Datacenter (SDDC) dar. Dort sind alle Teile der Infrastruktur virtualisiert und in einer Software zusammengefasst. SDDC ist mit bedeutend weniger Aufwand verbunden als die Entwicklung von Disaster-Recovery-Lösungen für einzelne Infrastrukturkomponenten und Applikationen, die Definition und Programmierung einzelner Schnittstellen sowie letztlich die Entwicklung der koordinierenden Lösungen. Virtualisierung vereinfacht das Aufsetzen und Verwalten der Rechenzentrumselemente. Sie bietet die Basis für eine moderne Disaster-Recovery-Lösung. Wenn alle Komponenten mit einem Produkt virtualisiert sind, entfällt die Koordination der Abläufe über die komplexen Schnittstellen. Es wird damit deutlich einfacher, ein zuverlässiges und kostengünstiges Disaster Recovery zu entwickeln. Das Software-Defined Datacenter ist keine abstrakte Strategie. Server, Netzwerke, Storage-Netzwerke, Storage und Security sind dafür zu virtualisieren. Für die Server-Virtualisierung steht heute eine breite Auswahl an Produkten zur Verfügung. Auch der Schritt in Richtung Netzwerkvirtualisierung ist bereits getan. Zuerst gilt dies nur für die Verbindungen zwischen virtuellen Maschinen, doch das Konzept erweitert sich aktuell auch auf physische Netzwerkkomponenten, damit letztendlich ein einziges, virtualisiertes Netzwerk zur Verfügung steht. Lässt sich ein Netzwerk zu 100 Prozent virtualisieren, vereinfacht dies das Management erheblich, vermeidet Fehler und steigert die Produktivität der IT-Abteilungen. Disaster-Recovery-Lösung in drei Schritten Ein Neuentwurf beziehungsweise Umbau eines Netzwerks im Sinne von SDDC lässt sich in drei Schritte einteilen: die Definition der Anforderungen und der Datenflüsse, das Design des Netzwerks und letztlich die Detailplanung und Umsetzung. Im ersten Schritt ist zu definieren, wie die Rechenzentrumskomponenten über das Netz miteinander kommunizieren sollen. Diese Aufgabe fällt relativ leicht und ist für Netzwerkspezialisten einfach nachzuvollziehen, da sich durch abstrakte Überlegungen ein klares Ziel definieren lässt. Im zweiten Schritt wählen die IT-Verantwortlichen die nötigen Komponenten wie Switches und Router sowie die Techniken wie VLANs, VPNs etc. aus, um das entworfene Konzept zu realisieren. Dabei entfernen sie sich vom rein Abstrakten und passen die technischen Möglichkeiten an die individuellen Anforderungen im Unternehmen an. Im dritten Schritt, folgt die "Übersetzung" des Konzeptes in die Setups der eingesetzten Netzwerkkomponenten. In den Switches sind zum Beispiel die VLANs zu definieren und es ist zu entscheiden, ob dies manuell oder mittels eines Protokolls erfolgen soll. Dieser Schritt führt direkt in die Welt von maschinellen CLIs (Command Line Interfaces), Routing-Tabellen, VLANs und vielem mehr. Genau aus diesem Grund ist er bislang am zeitaufwendigsten und stellt die größte Fehlerquelle dar. Ist das Netz jedoch virtualisiert, erfolgt die Definition des Netzwerkkonzepts bereits auf der virtuellen Ebene und die Software übernimmt das Setup der einzelnen Komponenten. Entsprechende Vorteile ergeben sich auch bei der Virtualisierung von Storage-Netzwerken oder Security-Infrastrukturen: Obwohl sich beispielsweise zwei Rechenzentren in unterschiedlichen Netzen befinden, besitzt das virtualisierte Netz nur eine einheitliche Netzadresse. Das Disaster Recovery Failover vereinfacht sich dadurch erheblich. Fazit Die Anforderungen an maximale Systemverfügbarkeit in Unternehmen steigen und die Notwendigkeit eines effizienten Katastrophenschutzes wird immer deutlicher. Die IT braucht dafür neue Lösungen. Software-Defined Datacenter bietet gute Lösungsansätze, um die heutigen und künftigen Anforderungen an den Ausfallschutz zu erfüllen.
Lesen Sie mehr zum Thema
