Tipps zur Planung erfolgreicher Disaster-Recovery-Strategien

Die steigenden Anforderungen an Backup und Disaster Recovery verlangen nach einer immer leistungsfähigeren Palette an spezialisierten Tools, die Backup und Disaster Recovery (DR) so einfach wie möglich machen. Ein ausgereifter DR-Plan erfordert jedoch den Miteinbezug von Menschen, Prozessen und Technologien, um wirklich erfolgreich zu sein.

Rubrik sieht deshalb in Technologien wie Live Mount, CloudOut und CloudOn wichtige Ansätze, um Unternehmen bei der schnellen Wiederherstellung nach einem Zwischenfall zu unterstützen und Ausfallzeiten zu minimieren. Dennoch ist nach Meinung von Rubrik die Technologie nur ein Teil der DR-Gleichung. 

Einige der wichtigsten Überlegungen bei der Entwicklung einer DR-Strategie:

1) Menschen

In erster Linie sind die richtigen Stakeholder erforderlich und die Führungsetage muss deren Strategie unterstützen bei der Zuteilung von personellen und technischen Ressourcen. Eine erfolgreiche DR-Planung erfordert Zeit und Input von vielen Menschen im Unternehmen. Je größer das Unternehmen, desto mehr Menschen sind beteiligt. Alle Schlüsselbereiche des Unternehmens müssen repräsentiert sein, während sich kleinere Gruppen bei Bedarf auf Logistik und Betrieb konzentrieren können.

Einige Beispiele, wie sich ein Team effektiv zusammenstellen lässt:

• Business Unit Stakeholder: Rubrik rät zur Identifikation kritischer Anwendungen, Erfolgskriterien und potenzielle Hindernisse.
• Anwendungseigner/Analytiker: Eigene Abhängigkeitsabbildung und Erfolgskriterien für Anwendungstests.
• IT-Infrastruktur-Ingenieure (Compute/Networking/Storage/Sprache/Datenbanken): Den Großteil der Arbeit während Tests und Events durchführen. Die Größe der DR-Standortressourcen, die Konnektivität und die Automatisierungstools angeben.

Jeder muss sich über seine Rollen und Verantwortlichkeiten im Klaren sein, und möglicherweise müssen diejenigen berücksichtigt werden, die „single points of failure“ im Team sind. Es kommt immer wieder vor, dass etwas nicht klappt, weil ein kritisches Teammitglied eine zugewiesene Aufgabe nicht erfüllt hat.

2) Prozesse

Unternehmen sollen mit dem Ausfüllen einer Verantwortungsmatrix oder RACI (Responsible, Accountable, Consulted and Informed) und eines Projektplans beginnen, damit jeder versteht, was von ihm erwartet wird und wann er es tun soll. Eine RACI-Matrix wird verwendet, um die Aufgaben zu bestimmen, die jeder Einzelne oder jede Gruppe hat. Typischerweise wird jeder Aufgabe in der Matrix eine verantwortliche Partei zugeordnet, und die anderen Werte werden nach Bedarf zugewiesen. Ein effektives Projektmanagement erleichtert die Durchführung dieses Prozesses erheblich.

Mit einm Team an Ort und Stelle und den zugewiesenen grundlegenden Verantwortlichkeiten ist es an der Zeit, in die Details einzutauchen. Zunächst muss man bestimmen, um welche Systeme es geht, zusammen mit der angestrebten Recovery Point Objective (RPO) und Recovery Time Objective (RTO).

• Eine RPO ist eine Entscheidung darüber, wie viele Daten im Falle einer Katastrophe verlorengehen, und ist typischerweise mit der Häufigkeit verbunden, mit der Backups ausgeführt werden.
• Eine RTO ist der Zielzeitraum für die Rückkehr zum normalen Betrieb nach einer Katastrophe, was in etwa der Zeit entspricht, die für die Ausführung eines DR-Plans benötigt wird.

Fast alle anderen Entscheidungen sind an die RPO und RTO gebunden. Die Entwicklung eines DR-Plans ist ein schwieriger Prozess, der Monate oder sogar Jahre dauert. Unternehmen sollten an jeden einzelnen Fehlerzustand, nicht nur an das Worst-Case-Szenario, denken. Ein Ausfall einer kritischen Anwendung kann die gleiche Wirkung haben wie ein Meteoriteneinschlag in im Rechenzentrum.

Regelmäßige Tests sind das wichtigste und zeitaufwändigste Element der DR-Strategie. Erfolgskriterien müssen klar definiert und messbar sein, aber es ist wichtig, sich daran zu erinnern, dass ein fehlgeschlagener Test nicht bedeutet, dass das Team versagt hat. Wird tatsächlich ein Fehler im Plan entdeckt, kann dieser gelöst werden, bevor eine echte Katastrophe passiert. Jeder strebt nach einem erfolgreichen Test beim ersten Versuch, aber das passiert selten. Man muss sicherstellen, dass das Team realistische Erwartungen hat, insbesondere für die ersten Tests.

Unternehmen dürfen ihren Fail-Back-Plan nicht vergessen. Sie können ihren DR-Prozess mehrmals testen, aber oft wird die DR-Umgebung nach Abschluss des Tests heruntergefahren. Im Falle einer echten Katastrophe müssen sie in der Lage sein, ihre Workloads wieder in Ihr Rechenzentrum zu übertragen. Sie sollten besonders darauf achten, wenn sie einen Cloud-Provider als DR-Standort nutzen. Es gibt einen Grund, warum die Leute die Cloud als „Hotel California“ bezeichnen: Oft ist es viel einfacher, Workloads in die Cloud zu bringen, als sie wieder herauszuholen.

3) Technologie

Der jeweils bestehende Technologie-Stack hat erhebliche Auswirkungen darauf, wie schwierig die Notfallwiederherstellung sein wird. Wenn eine zu 100 Prozent virtualisierte Umgebung vorliegt, ist die Sache einfacher als mit vielen Bare-Metal-Workloads. IT-Shops, die noch Mainframes oder Nicht-x86-Workloads betreiben, befinden sich in einer besonders schwierigen Situation, da sie sich auf DR-/Cloud-Anbieter beschränken müssen, die diese Systeme unterstützen. Hinzu kommt, dass Mainframes typischerweise ältere Systeme sind, und es wird deutlich, dass Unternehmen in dieser Situation eine gut durchdachte DR-Strategie haben müssen. Obwohl es normalerweise nicht Teil der DR-Diskussion ist, ist die Modernisierung des Technologie-Stacks hier ein wichtiger Aspekt.

Ein häufiger Stolperstein in jedem Unternehmen ist die Vernetzung. Die Unternehmen müssen sicherstellen, dass sie die Auswirkungen der Umgehung öffentlicher IP-Adressen verstehen, wenn das Unternehmen Ressourcen im Internet bereitstellt. Häufig erfordert dies die Einreichung eines Letter of Agency beim Internetserviceprovider an Ihrem DR-Standort, der sie berechtigt, ihren IP-Adressbereich zu bewerben. In einigen Fällen können öffentliche IPs nicht verschoben werden und erfordern, dass Unternehmen eine DNS-Änderung orchestrieren oder eine Variante von Global Server Load Balancing (GSLB) implementieren. Abhängig von der Komplexität des Netzwerks ist zu überlegen, wie Unternehmen das Netzwerk an ihrem DR-Standort auf dem neuesten Stand halten können, während sie VLANs oder Subnetze in der Produktion hinzufügen. Eine schnelle, redundante Konnektivität zu ihrem DR-Standort ist entscheidend, wenn sie sich auf die Speicherreplikation für einen Teil ihres DR verlassen. Speicher-Arrays könnten nicht in angemessener Weise mit einer Verschlechterung oder Unterbrechung der Konnektivität zwischen Standorten umgehen.

Die richtige Dimensionierung der DR-Umgebung kann mehr eine Kunst als eine Wissenschaft sein. Viele Unternehmen gehen davon aus, dass Rechen-, Netzwerk- und Speicherressourcen genau so groß sein müssen wie für die Produktion. Dies kann in manchen Fällen zu einem DR-Standort voller Ausrüstung im Dauerbetrieb führen, der nur einen Bruchteil der Zeit genutzt wird. Unternehmen müssen versuchen, ein Gleichgewicht zu finden, denn bei einer echten Katastrophe ist die Verfügbarkeit in der Regel wichtiger ist als vorübergehend verschmerzende Performanceeinbußen.

Disaster Recovery ist eine gewaltige Aufgabe, aber mit dem richtigen Team, den richtigen Verfahren und der richtigen Technologie ist sie lösbar.

www.rubrik.com