Startseite > Datacenter & Verkabelung > Mit Disaster-Recovery die IT wetterfest machen

Datensicherheit

Mit Disaster-Recovery die IT wetterfest machen

26. Januar 2015, 15:16 Uhr | Diethelm Siebuhr, CEO der Nexinto Holding und Peter Wurbs, Senior Solutions Consultant

Fortsetzung des Artikels von Teil 1

Die Wege zum Disaster-Recovery

Um die Komplexität an verschiedenen Konzepten zu vereinfachen, können vier Wege für die Realisierung eines Disaster-Recovery-Konzepts unterschieden werden:

Backup:
Die einfachste und die am häufigsten angewandte Methode stellt das klassische Backup dar. Dabei handelt es sich jedoch um kein vollständiges Disaster-Recovery-Konzept, denn Backup bildet nur einen Teil-aspekt ab, es beantwortet nur die Frage der Replikation. Die Frage wie die Umschaltung erfolgt, wird demnach aus einem Backup-Konzept heraus nicht beantwortet. Allerdings sichert ein Backup Dinge ab, die andere Konzepte nicht berücksichtigen, wie zum Beispiel die Auswirkungen von Bedienungsfehlern wie irrtümlich gelöschte Dateien. Ein Backup sichert zusätzlich aufgrund des „Medienbruchs“ zudem gegen Produktfehler ab. Backup gehört daher zu jedem Disaster-Recovery-Konzept dazu; es ist unerlässlich, aber nicht ausreichend.
Infrastruktur:
Disaster-Recovery auf der Ebene der Infrastruktur, also unterhalb des Betriebssystems, ist eine mehr oder weniger technische Angelegenheit. Hier stehen unterschiedliche Verfahren zur Verfügung, zum Beispiel klassische Storage-Replikationen, als Feature einer Storage-Hardware, Stretched-Cluster – Cluster, die sich über mehrere Standorte erstrecken –, oder die Hypervisor-Replikation als Bestandteil von Virtualisierungs-Umgebungen.

Mit diesen technischen Lösungen lassen sich prinzipiell sehr niedrige Ausfall- und Datenverlustraten erreichen; es sind sehr schnelle Schwenks zum sekundären Rechenzentrum möglich und damit auch niedrige RTO und RPO realisierbar. Der Nachteil besteht in einer hohen Hersteller- und Produktabhängigkeit. Beide Rechenzentren müssen identische Produkte einsetzen, denn eine Replikation zwischen Storage-Systemen verschiedener Hersteller funktioniert meist nicht. Die gesamte Infrastruktur in beiden Rechenzentren muss eng verzahnt sein. Ein ganzheitlicher Ansatz ist zudem nur selten möglich, denn ein Storage-Hersteller sorgt beispielsweise für die Spiegelung der Systeme, aber selten auch für die Failover-Prozesse. Und ob im Notfall im sekundären Rechenzentrum überhaupt geeignete Server bereit stehen, muss zusätzlich zu einem Storage-Konzept geplant werden.

Außerdem ist es im Rahmen einer Infrastruktur-Lösung kaum möglich, ein sekundäres Rechenzentrum über Cloud-Services zu betreiben; dazu sind die Anforderungen an die jeweilige Infrastruktur viel zu konkret, und gerade die technische Infrastruktur lässt sich vom Anwender in einer Cloud-Lösung nur sehr bedingt beeinflussen.

Application-Stack:
Eine Alternative ist die Abbildung von Datenreplikation und Failover-Prozessen auf der Ebene von Betriebssystem und Applikationen. Damit werden die Konzepte von Storage- oder Virtualisierungs-Technologien abstrahiert. Die Replikation erfolgt beispielsweise mit den Bordmitteln von Linux oder mit einer Datenbank etwa durch „Oracle DataGuard“. Anwender können aber die Replikation-Funktionalität auch direkt in ihre eigenen Anwendungen hineinschreiben. Tendenziell werden Umschaltzeiten und Datenverlust bei dieser Variante höher sein als bei einer Infrastruktur-Lösung und auch der Aufwand für die Implementierung ist höher. Allerdings hat man nun eine ganzheitliche Lösung, denn die Vorbereitung einer sekundären Plattform muss immer berücksichtigt werden. Zugleich erreichen Unternehmen auf diese Weise mehr Unabhängigkeit von Providern und Herstellern. Sie können in diesem Konzept aufgrund der Commodity-Anforderung an die IT-Infrastruktur (Server- oder Storage-Systeme von der Stange) Cloud-Provider für die Bereitstellung des sekundären Rechenzentrums ins Auge fassen.

Generell ist derzeit in der Unternehmens-IT ein Trend zur Abkehr von komplexer Hardware mit ausgeklügelten Features hin zu Commodity-Anforderungen zu beobachten; auf dieser Basis lassen sich dann auch Cloud-basierte Lösungen leichter realisieren und die Abhängigkeit von Providern, Herstellern und Produkten verringern.

Mobiles Deployment:
Das derzeit hochaktuelle Konzept des kontinuierlichen Deployments lässt sich auch für das Disaster-Recovery nutzen. Zumindest für bestimmte Datentypen, für statische Daten geringer Menge, zum Beispiel für Software, Code oder Konfigurationen. Hierfür muss eine klassische Replikation nicht mehr durchgeführt werden. Vielmehr erfolgt im Disaster-Fall das Deployment direkt in das sekundäre Rechenzentrum, repliziert werden nur sich häufig verändernde und hochkapazitive Datentypen wie Datenbank- oder Content-Daten. Mit diesem Ansatz können Unternehmen erreichen, dass der Aufwand in die Entwicklung flexibler und schneller Deployment-Prozesse fließt und die Vorbereitung auf Disaster-Szenarien quasi als Nebenprodukt entsteht. Die Integration von Disaster-Maßnahmen in die Applikationsentwicklung wäre praktisch gelebte Umsetzung des Dev-Ops-Paradigmas.

In der Praxis des Disaster-Recoverys kommt fast immer eine Mischung mehrerer Ansätze zum Einsatz: Man wird immer Backups erstellen, dazu bestimmte Services hardwaremäßig absichern, andere auf Betriebssystemebene, und, wo entsprechendes Know-how schon vorhanden ist, auch die Möglichkeiten des mobilen Deployments nutzen. Die Zusammenstellung eines solchen Disaster-Recovery-Mix setzt entsprechende Expertise voraus, und ist daher meist auch ein Thema für das Consulting durch Disaster-Recovery-Experten.