Was ist die Notfallwiederherstellung?
Ein Notfall ist ein einzelnes, schwerwiegendes Ereignis mit größeren und länger anhaltenden Auswirkungen, als eine Anwendung durch die Hochverfügbarkeitsfunktion ihres Designs entschärfen kann. Bei der Notfallwiederherstellung (DR) geht es um die Wiederherstellung nach Ereignissen mit umfangreichen Auswirkungen, z. B. Naturkatastrophen oder fehlgeschlagenen Bereitstellungen, die zu Ausfallzeiten und Datenverlust führen. Unabhängig von der Ursache ist das beste Mittel gegen einen Notfall ein gut definierter und getesteter Notfallplan und ein Anwendungsdesign, die Notfallwiederherstellung aktiv unterstützt.
Ziele der Wiederherstellung
Ein vollständiger Notfallwiederherstellungsplan muss die folgenden kritischen Geschäftsanforderungen für jeden von der Anwendung implementierten Prozess angeben:
Recovery Point Objective (RPO): die maximale Dauer des akzeptablen Datenverlusts. RPO wird in Zeiteinheiten gemessen, nicht in Mengen, wie „30 Minuten an Daten“ oder „vier Stunden an Daten“. Bei RPO geht es um die Begrenzung und Wiederherstellung von Datenverlusten, nicht um Datendiebstahl.
Recovery Time Objective (RTO): die maximale Dauer der zulässigen Ausfallzeit, wobei „Ausfallzeit“ gemäß Ihrer Spezifikation definiert ist. Wenn die akzeptable Ausfallzeit bei einem Notfall z. B. acht Stunden beträgt, beträgt der RTO-Wert acht Stunden.
Jeder wichtige Prozess oder jede Arbeitsauslastung, die von einer Anwendung implementiert wird, sollte separate RPO- und RTO-Werte aufweisen, indem Risiken für Notfallszenarien und potenzielle Wiederherstellungsstrategien untersucht werden. Der Prozess der Festlegung eines RPO und RTO erstellt effektiv DR-Anforderungen für Ihre Anwendung als Ergebnis Ihrer einzigartigen Geschäftlichen Bedenken (Kosten, Auswirkungen, Datenverlust usw.).
Entwurf für die Notfallwiederherstellung
Die Notfallwiederherstellung ist kein automatisches Feature, sondern muss entworfen, erstellt und getestet werden. Um eine solide Notfallwiederherstellungsstrategie zu unterstützen, müssen Sie eine Anwendung von Anfang an mit Notfallwiederherstellung im Hinterkopf entwickeln. Azure bietet Dienste, Features und Anleitungen zur Unterstützung von DR beim Erstellen von Apps.
Datenwiederherstellung
Während eines Notfalls gibt es zwei Standard Methoden zum Wiederherstellen von Daten: Sicherungen und Replikation.
Die Sicherung stellt Daten zu einem bestimmten Zeitpunkt wieder her. Mithilfe der Sicherung können Sie einfache, sichere und kostengünstige Lösungen bereitstellen, um Ihre Daten in der Microsoft Azure-Cloud zu sichern und wiederherzustellen. Verwenden Sie Azure Backup, um langlebige, schreibgeschützte Daten Momentaufnahme für die Verwendung in der Wiederherstellung zu erstellen.
Die Datenreplikation erstellt Echtzeit- oder Nahezu-Echtzeit-Kopien von Livedaten in mehreren Datenspeicherreplikaten mit minimalem Datenverlust. Das Ziel der Replikation besteht darin, Replikate mit möglichst geringer Latenz synchron zu halten, während gleichzeitig die Reaktionsfähigkeit der Anwendung aufrechterhalten wird. Die meisten Datenbanksysteme mit vollem Funktionsumfang und andere Datenspeicherprodukte und -dienste enthalten im Rahmen der Funktions- und Leistungsanforderungen eine Art der Replikation als fest integrierte Funktion. Ein Beispiel hierfür ist georedundanter Speicher (GRS).
Bei verschiedenen Replikationsdesigns weisen die Datenkonsistenz, Leistung und Kosten unterschiedliche Prioritäten auf.
Für aktive Replikationen müssen Updates gleichzeitig auf mehreren Replikaten durchgeführt werden, um die Konsistenz auf Kosten des Durchsatzes zu gewährleisten.
Bei der passiven Replikation wird die Synchronisierung im Hintergrund durchgeführt, sodass die Replikation als Einschränkung der Anwendungsleistung wegfällt. Es ergibt sich aber ein höherer RPO-Wert.
Die Aktiv/Aktiv- oder Multimasterreplikation ermöglicht die gleichzeitige Verwendung mehrerer Replikate, was den Lastenausgleich auf Kosten einer erschwerten Datenkonsistenz ermöglicht.
Die Aktiv/Passiv-Replikation reserviert Replikate nur während des Failover für die Livenutzung.
Hinweis
Die meisten voll funktionsfähigen Datenbanksysteme und andere Datenspeicherprodukte und -dienste umfassen eine Art Replikation, z. B. georedundanter Speicher (GRS), aufgrund ihrer funktionalen und Leistungsanforderungen.
Erstellen resilienter Anwendungen
Häufig führen Notfallszenarien auch zu Ausfallzeiten, z. B. aufgrund von Problemen mit der Netzwerkverbindung, Rechenzentrumsausfällen sowie beschädigten VMs oder Softwarebereitstellungen. In den meisten Fällen umfasst die Anwendungswiederherstellung ein Failover auf eine separate, funktionierende Bereitstellung. Daher kann es erforderlich sein, Prozesse in einer anderen Azure-Region im Falle eines groß angelegten Notfalls wiederherzustellen. Weitere Überlegungen können sein: Wiederherstellungsspeicherorte, Anzahl der replizierten Umgebungen und wie sie diese Umgebungen Standard.
Je nach Anwendungsdesign können Sie verschiedene Strategien und Azure-Features wie Azure Site Recovery verwenden, um die Unterstützung Ihrer Anwendung für die Prozesswiederherstellung nach einem Notfall zu verbessern.
Dienstspezifische Notfallwiederherstellungsfeatures
Die meisten Dienste, die auf der Azure-Plattform als Dienst (PaaS) ausgeführt werden, wie z. B. Azure-App Service, bieten Features und Anleitungen zur Unterstützung von DR. Für einige Szenarien können Sie dienstspezifische Funktionen nutzen, um eine schnelle Wiederherstellung zu unterstützen. Beispielsweise wird für Azure SQL Server die Georeplikation unterstützt, um einen Dienst schnell in einer anderen Region wiederherstellen zu können. Azure App Service verfügt über ein Feature für die Sicherung und Wiederherstellung, und die Dokumentation enthält eine Anleitung zur Verwendung des Azure Traffic Manager, um die Weiterleitung von Datenverkehr an eine sekundäre Region zu unterstützen.