Informationen zur Disaster-Recovery

Disaster RecoveryDie Fähigkeit eines Dienstes oder einer Arbeitslast, sich von seltenen, schwerwiegenden Vorfällen und großflächigen Ausfällen, wie z. B. Dienstunterbrechungen, zu erholen. Dies umfasst eine Naturkatastrophe, die eine ganze Region betrifft, die Beschädigung einer Datenbank oder den Verlust eines Dienstes, der zu einer Arbeitsbelastung beiträgt. Die Auswirkungen übersteigen die Fähigkeit des Hochverfügbarkeitsdesigns, sie zu bewältigen. (DR) ist der Prozess, bei dem eine oder mehrere Workloads nach einem ungeplanten Ausfall in einer zweiten Region von IBM Cloud wieder in einen funktionsfähigen Zustand versetzt werden. Hohe Verfügbarkeit ist nicht dasselbe wie Disaster Recovery.

Bei der Entwicklung und Erstellung von IT-Workloads liegt der Schwerpunkt häufig auf der Aufrechterhaltung der HochverfügbarkeitDie Fähigkeit eines Dienstes oder einer Arbeitslast, Ausfällen standzuhalten und die Verarbeitungsfähigkeit gemäß einem vordefinierten Servicelevel weiterhin bereitzustellen. (HA). HA ist ein Prozess, bei dem einzelne Fehlerpunkte ausgeschlossen werden, so dass Arbeitslasten überleben und Ausfälle vermieden werden können, die andernfalls durch eine fehlerhafte Infrastruktur verursacht werden.

Katastrophen sind anders. Katastrophen führen dazu, dass ein Workload ausfällt, obwohl versucht wurde, ihn hochverfügbar zu machen. Wenn Sie eine Cloud-Workload entwerfen und bereitstellen, müssen Sie berücksichtigen, wie diese Workload von einer Katastrophe betroffen sein könnte und wie sie wiederhergestellt werden kann. Im Katastrophenfall muss IBM Cloud im Rahmen des Wiederherstellungsprozesses möglicherweise bestimmte Maßnahmen ergreifen, wie beispielsweise die Wiederherstellung der Infrastruktur. Möglicherweise müssen auch Sie bestimmte Maßnahmen ergreifen, beispielsweise die Wiederherstellung von Daten. Sie müssen sicherstellen, dass Ihre Daten, zu denen häufig auch Konfigurationsdaten gehören, gesichert werden und für eine Wiederherstellung zur Verfügung stehen.

Die schlimmsten Katastrophen haben weitreichende Folgen, was bedeutet, dass die betroffenen Workloads möglicherweise in einer ganz anderen Region wiederhergestellt werden müssen.

Was bedeutet Disaster Recovery?

Zur Veranschaulichung der Erholung in einer zweiten Region betrachten wir ein Szenario. Unter normalen Umständen führt ein Kunde seine Workloads in der IBM Cloud us-south Multizonenregion aus. Dann ereignet sich eine große Katastrophe, die die gesamte Region us-south in Mitleidenschaft zieht und einen längeren Stromausfall verursacht. In solchen Fällen kann die Rückkehr zum Normalbetrieb auf us-south je nach Ausmaß des Ausfalls Stunden, Tage oder sogar Monate dauern. Wenn die betroffenen Cloud-Workloads kritisch für den Geschäftsbetrieb sind, haben Sie bei längeren Ausfallzeiten kaum eine andere Wahl, als Ihre Workloads wiederherzustellen und in einer zweiten IBM Cloud Region auszuführen.

Solche Umstände sind in der Regel auf ein weit verbreitetes Problem zurückzuführen, das ein bestimmtes geografisches Gebiet betrifft, einschließlich Naturkatastrophen und regionaler oder nationaler Notfälle. Es ist unwahrscheinlich, dass solche Katastrophen eintreten. In der Regel bietet die MZR-Architektur von IBM Cloud einen ausreichenden Schutz vor Ausfällen auf Zonenebene, und der Ausfall einer gesamten Multi-Zone-Region ist unwahrscheinlich. Die Service Level Agreements (SLA) von IBM Cloud für Dienste, die über eine MZR bereitgestellt werden, liegen in der Regel bei 99.99 %, was etwas mehr als 52.5 Minuten ungeplanter Ausfallzeit pro Jahr entspricht. Für weitere Informationen siehe IBM Cloud Service Level Agreements.

Es besteht jedoch die Möglichkeit, dass eine Katastrophe die Region, in der Ihre kritischen Arbeitslasten ausgeführt werden, auslöschen kann. Bereiten Sie sich mit einem Notfallwiederherstellungsplan vor, wenn Sie längere Ausfallzeiten aufgrund von Katastrophen vermeiden wollen.

RTO und RPO

Recovery Time ObjectiveIn der Notfallwiederherstellungsplanung die Zeitspanne, die ein Geschäftsprozess nach einem Notfall benötigt, um wiederhergestellt zu werden. (RTO) und Recovery Point ObjectiveBei der Planung der Notfallwiederherstellung wird die Zeit, in der Daten wiederhergestellt werden, in Zeit gemessen (Sekunden, Minuten, Stunden), beginnend mit der wiederhergestellten Instanz und endend am Punkt des Notfalls. (RPO) sind häufig die beiden Ausgangspunkte für einen Notfallwiederherstellungsplan. Das folgende Diagramm beschreibt, wie sich RTO und RPO in einen vereinfachten Zeitplan für Ausfälle einfügen.

Diagramm, das zeigt, wie RTO/RPO in einen Ausfallzeitplan passt

Wenn es zu einem Ausfall kommt, muss das Unternehmen entscheiden, ob und wann es den Katastrophenfall ausruft und den Wiederherstellungsplan in die Tat umsetzt. Nachdem Sie den Katastrophenfall ausgerufen haben, beginnt die Uhr der RTO. RTO bezieht sich auf die Zeit, die benötigt wird, um die Dienste wieder in einen nutzbaren Zustand zu versetzen. Ein Plan kann ein übergreifendes RTO haben, das viele Arbeitslasten abdeckt, und individuelle RTOs für jede von ihm abgedeckte Arbeitslast. RTO wird in Zeiteinheiten ausgedrückt, z. B. Minuten, Stunden oder Tage.

RPO bezieht sich auf den Zeitpunkt, zu dem die Dienste wiederhergestellt werden, was in der Regel der Zeitpunkt der letzten Sicherung ist. Bei der Wiederherstellung nach einer Datenbeschädigung ist ein früherer RPO auf einen Zeitpunkt vor der Beschädigung wünschenswert. Wenn mehrere Arbeitslasten miteinander verbunden sind, ist es wichtig, dass jedes System zum gleichen Zeitpunkt zurückgekauft wird. RPO wird ausgedrückt als bis zum Zeitpunkt des Ausfalls oder Null-Datenverlusts, bis zum Zeitpunkt der letzten Sicherung oder irgendwo dazwischen. Zu den Hemmnissen für RPO gehören die technische Machbarkeit und die Kosten der Umsetzung. Der Ausfall dauert so lange, bis der Dienst für den Endnutzer wiederhergestellt ist.

In vielen Umgebungen gibt es eine Mischung aus verschiedenen Workload-Typen, von denen einige grundlegend kritisch und andere weniger kritisch sind. Einige komplexe Umgebungen können auch viele Abhängigkeiten von anderen Workloads aufweisen, bei denen eine Workload eine andere benötigt, um zu funktionieren. Diese Aspekte tragen dazu bei, RTO- und RPO-Ziele für einzelne Workloads festzulegen. Erstellen Sie einen Zeitplan für den Wiederherstellungsplan, der die Reihenfolge berücksichtigt, in der die Workloads wiederhergestellt werden müssen. Der Zeitplan muss die Bedeutung eines Workloads für das Unternehmen, seine Ressourcenanforderungen, seine Komplexität und seine Abhängigkeiten berücksichtigen.

Die folgende Tabelle enthält ein RPO/RTO-Beispiel für die Klassifizierung von Beispielanwendungen als Referenz. Die tatsächliche RPO/RTO und die geschäftliche Einstufung hängen von der jeweiligen Organisation ab.

Beispiel für RTO/RPO-Werte auf der Grundlage der Klasse der Geschäftsanwendung
Klasse für Geschäftsanwendungen	RPO	RTO
Platin (immer eingeschaltet)	Null	Nahe Null
Gold (fast immer eingeschaltet)	<= 15 Min	<= 1 Stunde
Silber (Hohe Verfügbarkeit)	<= 1 Stunde	4 - 8 Stunden
Bronze (mäßige Verfügbarkeit)	<= 8 Stunden	<= 24 Stunden

Die Aufrechterhaltung einer DR-Rückstellung ist mit Kosten verbunden. Das folgende Diagramm zeigt eine typische DR-Kostenkurve. Je näher das RTO- und RPO-Ziel bei Null liegt, desto höher sind die Kosten der benötigten Lösung. Wenn sich RTO und RPO in Richtung Stunden und sogar Tage bewegen, sinken die damit verbundenen Kosten. Workloads, die die strengsten RTO- und RPO-Ziele haben, sind am teuersten zu schützen und am geschäftskritischsten.

Diagramm zur Darstellung des Verhältnisses von RTO/RPO zu den Kosten

Planung für den Katastrophenfall

Der Ansatz zur Definition Ihrer DR-Strategie muss systematisch sein und mit der Anwendung oder Arbeitslast und den von ihr genutzten Cloud-Service-Typen beginnen. Es ist verlockend, ein einziges RTO/RPO-Ziel für alle Workloads festzulegen, aber die Realität ist, dass jeder Geschäftsworkload unabhängig ist und seine eigenen RTO- und RPO-Anforderungen hat. Viele Kunden verwenden eine Reihe von Workload-Klassen, wobei jede Klasse ein bestimmtes RPO/RTO hat.

Jede geschäftliche Arbeitslast nutzt eine Reihe von Cloud-Ressourcen. Die Anforderungen für DR müssen verstanden, dokumentiert und implementiert werden, bevor sie für die Produktion freigegeben werden. Es ist schwieriger, eine DR-Lösung "nachzurüsten", als die Arbeitslast von vornherein mit Blick auf eine DR-Lösung zu gestalten.

Strategien für die Notfallwiederherstellung

Es gibt viele Möglichkeiten zur Implementierung von DR-Lösungen. Die verschiedenen Optionen werden in die folgenden vier Hauptkategorien eingeteilt:

Null Fußabdruck: Bei Zero Footprint ist der gesamte Anwendungsstack an einem Standort aktiv, wobei die Möglichkeit besteht, den Anwendungsstack an einem anderen Standort wiederherzustellen, an dem jedoch überhaupt nichts aufgebaut ist. Vergewissern Sie sich in der Praxis, dass alle Sicherungen am zweiten Speicherort für die Wiederherstellung verfügbar sind. Im Katastrophenfall werden alle Dienste von Grund auf neu eingerichtet, vorzugsweise anhand von Terraform-Vorlagen oder ähnlichem, bevor Backups erstellt werden. Ein Null-Fußabdruck ist die kostengünstigste Strategie. Da die Dienste von Grund auf neu bereitgestellt werden, ist diese Lösung nur geeignet, wenn die RTO- und RPO-Ziele mindestens mehrere Stunden betragen.
Basis-Standby: Bei den grundlegenden Standby-Optionen bleibt der gesamte Anwendungsstapel an einem Standort aktiv, während ein anderer Anwendungsstapel an einem anderen Standort bereitgestellt, aber heruntergefahren wird. Bei einem längeren Ausfall des primären Standorts wird der Anwendungsstapel am zweiten Standort aktiviert und die Backups werden wiederhergestellt. Rechnen Sie mit einer Wiederherstellungszeit von mehreren Stunden für die Instanziierung und Wiederherstellung von Workloads, die dieses Modell verwenden. Wenn die Verfügbarkeit des Workloads kritisch ist und das RTO-Ziel weniger als ein paar Stunden beträgt, ist dieser Ansatz nicht optimal.
Minimale Bedienung: Minimaler Betrieb bedeutet, dass der gesamte Anwendungsstapel sowohl am primären als auch am Backup-Standort aktiv ist, die Benutzertransaktionen jedoch nur am primären Standort verarbeitet werden. Die Datenreplikation, wie z. B. die Datenbankreplikation oder die Festplattenreplikation, sorgt für die Synchronisierung der Sicherungsorte. Wenn der Hauptstandort über einen längeren Zeitraum nicht verfügbar ist, werden alle Kundentransaktionen an den Backup-Standort weitergeleitet. Dieser Ansatz bietet ein RPO und RTO, das in Minuten gemessen werden kann. Der Minimalbetrieb ist wegen des doppelten Einsatzes teurer als die Optionen Aktiv/Passiv. Ressourcen werden beispielsweise verschwendet, weil die Standby-Assets nicht verwendet werden können, um die Skalierbarkeit und den Durchsatz zu verbessern.
Aktiv/Aktiv: Aktiv/Aktiv bedeutet, dass beide Standorte aktiv sind und die Kundentransaktionen nach vordefinierten Richtlinien, wie z. B. "round-robin" oder "geographisch am nächsten", auf beide Regionen verteilt werden. Fällt ein Standort aus, muss der andere Standort in der Lage sein, alle Kunden zu bedienen. Mit dieser Konfiguration ist es möglich, sowohl eine RPO als auch eine RTO nahe null zu erreichen. Der Einsatz von Autoscaling ist wichtig, um sicherzustellen, dass je nach aktueller Auslastung genügend Ressourcen zur Verfügung stehen. Fällt eine Region aus, muss die verbleibende Region schnell skalieren, um die volle Last zu bewältigen. Die Daten zwischen den beiden Standorten werden kontinuierlich mit einem Replikationsmechanismus synchronisiert. Sich ausschließlich auf diesen Ansatz zu verlassen, ist in Fällen problematisch, in denen Datenbeschädigungen oder -verluste aufgrund der Replikation die eigentliche Ursache für die Katastrophe sind. Die Behebung solcher Katastrophen hängt immer noch von der Wiederherstellung von Backups ab, die die nicht beschädigten oder verlorenen Daten enthalten.

Entwürfe für verschiedene Szenarien

Katastrophen haben viele Formen und erfordern unterschiedliche Techniken, um ihnen zu begegnen. Die Wiederherstellung nach einem vollständigen Ausfall einer Region ist anders als die Wiederherstellung nach einer Datenbeschädigung. Ein guter Entwurf berücksichtigt nicht nur ein einziges Szenario, sondern zieht verschiedene Szenarien in Betracht, die eine Wiederherstellung bei mehreren potenziellen Fehlern ermöglichen.

Überlegen Sie sich genau, was Sie im Falle einer Katastrophe brauchen, um sich zu erholen. Benötigen Sie alle Arbeitslasten oder nur eine Teilmenge der Kernanwendungen? Gibt es eine Reihenfolge, in der sie wiederhergestellt werden müssen? Ist die Datenkonsistenz über verschiedene Arbeitslasten hinweg wichtig? Ist es möglich, in einem degradierten Zustand zu arbeiten, und wenn ja, wie lange?

Diese Fragen sind sowohl geschäftliche als auch technische Erwägungen, da die Kosten in manchen Situationen unerschwinglich sein können. Sie müssen eine klare Vorstellung davon haben, was die minimal akzeptable Wiederherstellung ist, die es dem Unternehmen ermöglicht, zu funktionieren, wobei Sie Restrisiken in Kauf nehmen, wenn Sie deren Konsequenzen kennen. Die Planung der technischen Lösung muss Hand in Hand mit den geschäftlichen Anforderungen gehen, und beide müssen im Notfallwiederherstellungsplan festgehalten werden. Weitere Informationen finden Sie unter Planung der Notfallwiederherstellung.

Lesen Sie die dienstspezifische Dokumentation

Jeder IBM Cloud Dienst wird separat dokumentiert und enthält einen Abschnitt über die BCDR-Anforderungen, die speziell für dieses Produkt gelten. Vergewissern Sie sich, dass Sie die Anleitungen für jeden Dienst, den Sie nutzen, lesen und befolgen. Hilfe bei der Suche nach spezifischen Links zu Themen finden Sie unter Service-Dokumentation für Hochverfügbarkeit und Disaster Recovery.