Notfallwiederherstellung für Azure-Datenplattform: Empfehlungen

Erkenntnisse

1. Stellen Sie sicher, dass alle Beteiligten den Unterschied zwischen Hochverfügbarkeit und Notfallwiederherstellung verstehen: Ein häufiger Fehler besteht darin, die beiden Konzepte zu verwechseln und die damit verbundenen Lösungen nicht aufeinander abzustimmen
2. Sprechen Sie mit den Projektbeteiligten über ihre Erwartungen hinsichtlich der folgenden Aspekte, um die Zielvorgaben für RPO (Recovery Point Objectives) und RTO (Recovery Time Objectives) zu definieren:
   1. Welche Ausfallzeiten können toleriert werden? Dabei ist zu beachten, dass die Kosten in der Regel umso höher sind, je schneller die Wiederherstellung erfolgt.
   2. Die Art der Vorfälle, vor denen Schutz benötigt wird, unter Angabe der Wahrscheinlichkeit eines solchen Ereignisses. Beispielsweise ist die Wahrscheinlichkeit eines Serverausfalls höher als das Auftreten eine Naturkatastrophe, die alle Rechenzentren in einer Region betrifft.
   3. Welche Auswirkungen hat die Nichtverfügbarkeit des Systems auf ihr Geschäft?
   4. Das Betriebsausgabenbudget für die künftige Lösung
3. Überlegen Sie, welche eingeschränkten Dienstoptionen Ihre Endbenutzer akzeptieren können. Dies kann Folgendes beinhalten:
   1. Benutzer haben weiterhin Zugriff auf Visualisierungsdashboards, auch wenn die Daten nicht auf dem neuesten Stand sind. Anders ausgedrückt: Wenn die Erfassungspipelines nicht funktionieren, können die Endbenutzer trotzdem auf ihre Daten zugreifen.
   2. Lesezugriff, aber kein Schreibzugriff
4. Ihre angestrebten RTO- und RPO-Kennzahlen können definieren, welche Notfallwiederherstellungsstrategie Sie implementieren möchten:
   1. Aktiv/aktiv
   2. Aktiv/passiv
   3. Aktiv/Neubereitstellung bei Notfall
   4. Vertrauen auf die SLA von Microsoft
5. Stellen Sie sicher, dass Sie alle Komponenten kennen, die sich auf die Verfügbarkeit Ihrer Systeme auswirken können, darunter beispielweise:
   1. Identitätsverwaltung
   2. Netzwerktopologie
   3. Verwaltung von Geheimnissen/Schlüsseln
   4. Datenquellen
   5. Automatisierung/Auftragsplaner
   6. Quellrepository und Bereitstellungspipelines (GitHub, Azure DevOps)
6. Die frühzeitige Erkennung von Ausfällen ist ebenfalls eine Möglichkeit, die RTO- und RPO-Werte deutlich zu senken. Im Folgenden werden einige Aspekte aufgeführt, die Sie beachten sollten:
   1. Definieren Sie, was ein Ausfall ist und inwieweit dies der Microsoft-Definition eines Ausfalls entspricht. Sie finden die Microsoft-Definition eines Ausfalls auf der Seite zum Azure-SLA auf Produkt- oder Dienstebene.
   2. Ein effizientes Überwachungs- und Warnsystem mit rechenschaftspflichtigen Teams, die diese Metriken und Warnungen zeitnah überprüfen, trägt dazu bei, das Ziel zu erreichen
7. Bei einer kombinierten SLA steigt die Wahrscheinlichkeit eines Ausfalls, je mehr Komponenten in Ihrer Architektur vorhanden sind. Sie könnten eine zusammengesetzte SLA verwenden, um die Wahrscheinlichkeit eines Komponentenausfalls zu definieren.
8. In Bezug auf den Abonnemententwurf kann die zusätzliche Infrastruktur für die Notfallwiederherstellung im ursprünglichen Abonnement enthalten sein. PaaS-Dienste wie ADLS Gen2 oder Azure Data Factory verfügen in der Regel über native Funktionen, die ein Failover auf sekundäre Instanzen in anderen Regionen ermöglichen, während sie im ursprünglichen Abonnement enthalten bleiben. Einige Kunden könnten aus Kostengründen eine dedizierte Ressourcengruppe für Ressourcen in Betracht ziehen, die nur in DR-Szenarien verwendet werden.
   1. Es sollte beachtet werden, dass Abonnementlimits eine Einschränkung für diesen Ansatz darstellen können
   2. Weitere Einschränkungen können die Komplexität des Entwurfs und Kontrollmechanismen der Verwaltung sein, mit denen sichergestellt wird, dass die DR-Ressourcengruppen nicht für Workflows des täglichen Geschäftsbetriebs genutzt werden.
9. Entwerfen Sie den DR-Workflow basierend auf der Wichtigkeit einer Lösung und deren Abhängigkeiten. Versuchen Sie zum Beispiel nicht, eine Azure Analysis Services-Instanz neu zu erstellen, bevor Ihr Data Warehouse in Betrieb ist, da dadurch ein Fehler ausgelöst wird. Kümmern Sie sich erst später um Lab-Umgebungen für die Entwicklung, und stellen Sie zuerst die zentralen Unternehmenslösungen wieder her.
10. Identifizieren Sie Wiederherstellungsaufgaben, die lösungsübergreifend parallelisiert werden können, um die Gesamt-RTO zu verringern.
11. Wenn Azure Data Factory in einer Lösung verwendet wird, vergessen Sie nicht, die selbstgehosteten IRs in den Geltungsbereich einzuschließen. Azure Site Recovery ist ideal für diese Computer.
12. Manuelle Vorgänge sollten so weit wie möglich automatisiert werden, um Bedienungsfehler zu vermeiden, insbesondere dann, wenn der Druck sehr hoch ist. Folgendes wird empfohlen:
    1. Durchführen der Ressourcenbereitstellung über Bicep, ARM-Vorlagen oder PowerShell-Skripts
    2. Einführen einer Quellcodeversionierung und Ressourcenkonfiguration
    3. Verwenden von CI/CD-Releasepipelines anstelle von ClickOps
13. Da Sie über einen Plan für ein Failover verfügen, sollten Sie Verfahren für das Failback auf die primären Instanzen einrichten
14. Definieren Sie klare Indikatoren/Metriken, um zu validieren, dass das Failover erfolgreich war und die Lösungen funktionieren bzw. dass sich die Situation wieder normalisiert hat (auch als Primärfunktionen bezeichnet)
15. Entscheiden Sie, ob nach einem Failover die gleichen SLAs gelten sollen oder ob Sie einen eingeschränkten Leistungsumfang akzeptieren können
    1. Diese Entscheidung hängt stark von dem zu unterstützenden Geschäftsprozess ab. Beispielsweise gelten für das Failover eines Raumbuchungssystems ganz andere Anforderungen als für das Failover eines operativen Kernsystems
16. Eine RTO/RPO-Definition sollte nicht auf der Infrastrukturebene, sondern auf spezifischen Benutzerszenarien/Lösungen basieren. So können Sie präziser bestimmen, welche Prozesse und Komponenten im Falle eines Ausfalls oder einer Katastrophe zuerst wiederhergestellt werden sollen.
17. Stellen Sie sicher, dass Sie Kapazitätsprüfungen in der Zielregion durchführen, bevor Sie ein Failover starten: Bei einem größeren Notfall werden viele Kunden gleichzeitig versuchen, ein Failover in dieselbe gekoppelte Region durchzuführen. Dies kann zu Verzögerungen oder Konflikten bei der Bereitstellung der Ressourcen führen
    1. Wenn diese Risiken nicht in Kauf genommen werden können, sollte entweder eine Aktiv/Aktiv- oder Aktiv/Passiv-DR-Strategie in Betracht gezogen werden.
18. Es sollte ein Notfallwiederherstellungsplan erstellt und verwaltet werden, um den Wiederherstellungsvorgang und die Aktionsbesitzer zu dokumentieren. Denken Sie außerdem daran, dass Personen womöglich abwesend sind. Stellen Sie deshalb sicher, dass Sie Zweitkontakte angeben
19. Führen Sie regelmäßig Notfallübungen durch. So validieren Sie den Ablauf des Notfallplans, stellen sicher, dass die geforderten RTO/RPO-Vorgaben erfüllt werden und schulen die zuständigen Teams.
    1. Daten- und Konfigurationssicherungen sollten ebenfalls regelmäßig getestet werden, um sicherzustellen, dass sie für die Unterstützung von Wiederherstellungsaktivitäten geeignet sind.
20. Eine frühzeitige Zusammenarbeit mit den Teams, die für Netzwerkbetrieb, Identität und Ressourcenbereitstellung zuständig sind, ermöglicht eine Einigung auf die optimale Lösung unter diesen Gesichtspunkten:
    1. Wie werden Benutzer und Datenverkehr von Ihrem primären an den sekundären Standort weitergeleitet? Es können Konzepte wie die DNS-Umleitung oder der Einsatz spezieller Tools wie Azure Traffic Manager ausgewertet werden
    2. Wie können Sie zeitnah und sicher Zugriff und Rechte für den sekundären Standort bereitstellen?
21. Bei einem Notfall ist eine reibungslose Kommunikation zwischen den verschiedenen Beteiligten der Schlüssel zu einer effizienten und schnellen Umsetzung des Plans:
    1. Entscheidungsträger
    2. Incident Response-Team
    3. Betroffene interne Zielgruppen
    4. Externe Teams
22. Eine Orchestrierung der verschiedenen Ressourcen zum richtigen Zeitpunkt gewährleistet eine effiziente Umsetzung des DR-Plans.

Überlegungen

Antimuster

• Kopieren/Einfügen dieser Artikelreihe: Diese Artikelreihe ist als Leitfaden für Kunden gedacht, die genauere Details für einen Azure-spezifischen DR-Prozess benötigen. Aus diesem Grund basiert das Verfahren auf den allgemeinen Microsoft IP- und Referenzarchitekturen und nicht auf einer einzelnen kundenspezifischen Azure-Implementierung.
  Auch wenn die bereitgestellten Details zu einem soliden Grundverständnis beitragen, müssen die Kunden den spezifischen Kontext, ihre eigene Implementierung und die für sie geltenden Anforderungen berücksichtigen, bevor sie eine zweckmäßige DR-Strategie und einen entsprechenden Prozess entwickeln können.

• Betrachtung der Notfallwiederherstellung als rein technischer Prozess: Die geschäftlichen Projektbeteiligten spielen eine entscheidende Rolle bei der Definition der Anforderungen für die Notfallwiederherstellung und bei den Schritten zur Geschäftsvalidierung, die zur Bestätigung einer Dienstwiederherstellung erforderlich sind. Durch die Einbeziehung der geschäftlichen Projektbeteiligten in alle Notfallwiederherstellungsaktivitäten erhalten Sie einen geeigneten Notfallwiederherstellungsvorgang, der einen Mehrwert für das Unternehmen darstellt und umsetzbar ist.

• DR-Pläne nach dem Set-and-Forget-Prinzip: Azure entwickelt sich ständig weiter, ebenso wie die Nutzung der verschiedenen Komponenten und Dienste durch einzelne Kunden. Ein zielführender DR-Prozess muss sich daher an diese Entwicklung anpassen. Kunden sollten ihren DR-Plan entweder im Rahmen des SDLC-Prozesses oder bei periodischen Überprüfungen regelmäßig überarbeiten. Ziel ist es, die Gültigkeit des Dienstwiederherstellungsplans sicherzustellen und alle Abweichungen zwischen Komponenten, Diensten oder Lösungen zu berücksichtigen.

• Papierbasierte Bewertungen: Auch wenn die End-to-End-Simulation eines DR-Ereignisses in einem modernen Datenökosystem schwierig ist, sollten alle Anstrengungen unternommen werden, um einer vollständigen Simulation der betroffenen Komponenten so nahe wie möglich zu kommen. Regelmäßig geplante Notfallübungen sorgen dafür, dass die zuständigen Personen in der Organisation sich den Notfallwiederherstellungsplan einprägen und so im Ernstfall sicher ausführen können.

• Vertrauen auf die Unterstützung durch Microsoft: Innerhalb der Microsoft Azure-Dienste gibt es eine klare Aufteilung der Verantwortung, die sich nach der genutzten Clouddienstebene richtet: Selbst wenn ein vollständiger SaaS-Stapel genutzt wird, bleibt der Kunde dafür verantwortlich, dass die Konten, Identitäten und Daten sowie die Geräte, die zur Interaktion mit den Azure-Diensten verwendet werden, korrekt bzw. auf dem neuesten Stand sind.

Ereignisumfang und Strategie

Umfang des Notfallereignisses

Je nach Ereignis sind die Auswirkungen unterschiedlich groß, deshalb müssen Sie auch unterschiedlich reagieren. Die folgende Abbildung veranschaulicht dies für ein Notfallereignis:

Optionen für eine Notfallstrategie

Es gibt vier allgemeine Optionen für eine Strategie zur Notfallwiederherstellung:

• Warten auf Microsoft: Wie der Name andeutet, bleibt die Lösung offline, bis Microsoft die Dienste in der betroffenen Region wiederhergestellt hat. Nach der Wiederherstellung wird die Lösung vom Kunden validiert und dann zur Dienstwiederherstellung auf den neuesten Stand gebracht.
• Neubereitstellung bei einem Notfall: Die Lösung wird nach einem Notfallereignis in einer verfügbaren Region manuell von Grund auf neu bereitgestellt.
• Warm-Spare-Strategie (Aktiv/Passiv): In einer alternativen Region wird eine sekundäre gehostete Lösung erstellt, und durch die Bereitstellung der Komponenten wird eine Mindestkapazität gewährleistet. Die Komponenten empfangen jedoch keinen Produktionsdatenverkehr. Die sekundären Dienste in der alternativen Region können abgeschaltet oder auf einem niedrigeren Leistungsniveau betrieben werden, bis ein DR-Ereignis eintritt.
• Hot-Spare-Strategie (Aktiv/Aktiv): Die Lösung wird regionsübergreifend in einer Aktiv/Aktiv-Konfiguration gehostet. Die sekundäre gehostete Lösung empfängt, verarbeitet und verteilt Daten als Teil des größeren Systems.

Auswirkungen der DR-Strategie

Während die Betriebskosten oftmals dem höheren Servicelevel geschuldet sind, werden die wichtigsten Entwurfsentscheidungen für eine DR-Strategie häufig von der Ausfallsicherheit bestimmt. Darüber müssen weitere wichtige Aspekte berücksichtigt werden.

Das DR-Szenario für dieses Praxisbeispiel ist ein vollständiger regionaler Azure-Ausfall, der sich direkt auf die primäre Region auswirkt, in der die Datenplattform von Contoso gehostet wird. Dieses Ausfallszenario hat die folgenden relativen Auswirkungen auf die vier allgemeinen DR-Strategien:

Klassifizierungsschlüssel

• Recovery Time Objective (RTO): Die erwartete Zeitspanne vom Eintritt des Notfallereignisses bis zur Wiederherstellung der Plattformdienste.
• Komplexität der Umsetzung: Die Komplexität der Wiederherstellungsaktivitäten für die Organisation.
• Komplexität der Implementierung: Der Komplexität der Implementierung der DR-Strategie für die Organisation.
• Auswirkung auf die Kunden: Die direkten Auswirkungen der DR-Strategie auf die Kunden des Datenplattformdiensts.
• Zusätzliche Betriebsausgaben: Die zu erwartenden Mehrkosten für die Implementierung dieser Strategie, z. B. höhere monatliche Azure-Rechnungen für zusätzliche Komponenten und Ressourcen, die zur Unterstützung der Strategie benötigt werden.

Nächste Schritte

Nachdem Sie jetzt die Empfehlungen für das Szenario kennen, können Sie sich darüber informieren, wie Sie dieses Szenario bereitstellen.

Zugehörige Ressourcen

• DR für Azure Data Platform – Übersicht
• DR für Azure Data Platform – Architektur
• Notfallwiederherstellung für eine Azure-Datenplattform: Szenariodetails
• Notfallwiederherstellung für eine Azure-Datenplattform: Zusammenfassung