Share via

Business Continuity & Disaster Recovery für Analysen auf Cloudebene

  • Artikel

Wenn Sie die Architektur für einen Clouddienst entwerfen, sollten Sie Ihre Verfügbarkeitsanforderungen berücksichtigen und überlegen, wie Sie auf mögliche Unterbrechungen des Diensts reagieren können. Ein Problem kann sich auf eine bestimmten Instanz oder auf die gesamte Region beziehen. Es ist wichtig, dass Sie für beide Fälle Pläne haben. Abhängig von Ihrem Recovery Time Objective und Recovery Point Objective können Sie für die Hochverfügbarkeit und Notfallwiederherstellung eine aggressive Strategie wählen.

Die Hochverfügbarkeit und die Notfallwiederherstellung können manchmal kombiniert werden. Die beiden Bereiche verfolgen leicht unterschiedliche Strategien, insbesondere im Bereich der Daten. Weitere Informationen finden Sie im Microsoft Azure Well-Architected Framework und seinen Zuverlässigkeitsprinzipien.

Anstatt zu versuchen, Fehler zu verhindern, sollten Sie von vornherein akzeptieren, dass Fehler auftreten können und auch werden. Minimieren Sie die Auswirkungen einer einzelnen fehlerhaften Komponente im Lebenszyklus. Ihre Toleranz für Kosten, Recovery Point Objective und Recovery Time Objective bestimmt den Typ der zu implementierenden Lösung.

Sicherungsstrategien

Zum Implementieren verteilter Computeressourcen über mehrere Regionen hinweg stehen viele alternative Strategien zur Verfügung. Diese Strategien müssen auf die jeweiligen Geschäftsanforderungen und die besonderen Bedingungen der Anwendung angepasst werden. Im Wesentlichen lassen sich die Ansätze in die folgenden Kategorien einteilen:

  • Sichern und Wiederherstellen: Stellen Sie die Datenbankanwendung aus der letzten Sicherungskopie vor dem Notfall wieder her. Dieser Ansatz wird häufig nach einer Datenbeschädigung oder einem versehentlichem Löschen verwendet.

  • Erneute Bereitstellung bei einem Notfall: Stellen Sie die Anwendung zum Zeitpunkt des Notfalls von Grund auf neu bereit. Dieser Ansatz eignet sich für nicht-kritischen Anwendungen, die keine garantierte Wiederherstellungszeit erfordern.

  • Warmspare (aktiv/passiv): Erstellen Sie einen sekundären gehosteten Dienst in einer alternativen Region. Stellen Sie die Rollen bereit, um eine minimale Kapazität zu gewährleisten. Die Rollen empfangen keinen Produktionsdatenverkehr. Diese Vorgehensweise eignet sich für Anwendungen, die nicht dafür entworfen wurden, Datenverkehr über Regionen hinweg zu verteilen.

  • Hotspare (aktiv/aktiv): Entwerfen Sie die Anwendung so, dass sie die Produktionslasten in mehreren Regionen empfängt. Sie können die Clouddienste in jeder Region für eine höhere Kapazität, als zur Notfallwiederherstellung erforderlich ist, konfigurieren. Stattdessen können Sie die Clouddienste auch skalieren, wenn es zum Zeitpunkt eines Notfalls und für ein Failover erforderlich ist.

    Dieser Ansatz erfordert Investitionen in den Anwendungsentwurf, hat jedoch auch Vorteile. Er bietet eine niedrige und garantierte Wiederherstellungszeit. Es gibt kontinuierliche Tests aller Wiederherstellungsstandorte und eine effiziente Nutzung der Kapazität. Bei den Datenbankanwendungen umfasst dieser Ansatz einen Lastenausgleich für zwei Datenbanken, die mit einem einzelnen Verbindungspunkt synchronisiert werden.

Die Notfallwiederherstellung und die Hochverfügbarkeit für Azure-Dienste

In den folgenden Abschnitten werden verschiedene Azure-Dienste erläutert.

Azure Cosmos DB

Eine Übersicht über Hochverfügbarkeit mit Azure Cosmos DB finden Sie unter Wie stellt Azure Cosmos DB Hochverfügbarkeit.

Azure Data Factory

Die Datenintegrationen und das Datenprodukt verfügen wahrscheinlich über Azure DevOps Repositorys, die mit Azure Data Factory verknüpft sind. Sie können Pipelines in einer anderen Data Factory mit minimaler Ausfallzeit bereitstellen. Verwenden Sie das Azure Data Factory SDK zum Erstellen von Pipelines und anderen Azure Data Factory-Objekten, um neben GitHub- und Azure DevOps-Repository auch Software zur Codeversionssteuerung zu verwenden.

Azure Data Lake

Azur Data Lake Storage Gen2 unterstützt bereits die Dreifachreplikation als Schutz vor lokalisierten Hardwarefehlern. Andere Replikationsoptionen, wie zonenredundanter Speicher (ZRS) oder geozonenredundanter Speicher (GZRS), verbessern die Hochverfügbarkeit. Georedundanter Speicher (GRS) und georedundanter Speicher mit Lesezugriff (RA-GRS) verbessern die Notfallwiederherstellung. Für die Hochverfügbarkeit benötigt die Workload bei einer Dienstunterbrechung so schnell wie möglich Zugriff auf die neuesten Daten. Die Workload kann lokal zu einer replizierten Instanz oder zu einer neuen Region wechseln.

Ein als RA-GRS oder GRS konfiguriertes Speicherkonto kann Teil eines Plans für die Notfallwiederherstellung sein, erfordert jedoch eine sorgfältiger Analyse von Recovery Point Objective (RPO) und Recovery Time Objective (RTO) sowie die Überprüfung anderer Optionen, z. B. eines Doppellastszenarios, in dem Daten in zwei verschiedene Azure-Regionen kopiert werden.

Jede Datenzielzone muss über ein Recovery Point Objective für ihre Datenprodukte verfügen. Jede Datenzielzone muss über eine definierte Replikationsstrategie für ihre Anwendungsfälle verfügen.

Hinweis

Kundenverwaltetes Kontofailover wird in Konten mit einem hierarchischen Namespace (Azure Data Lake Storage Gen2) noch nicht unterstützt.

Im Falle eines Notfalls, der sich auf die primäre Region auswirkt, verwaltet Microsoft das Failover für Konten mit einem hierarchischen Namespace.

Weitere Informationen finden Sie unter Notfallwiederherstellung und Speicherkontofailover.

Azure Databricks

Eine Übersicht über eine Notfallwiederherstellungsarchitektur für Azure Databricks-Cluster finden Sie unter Regionale Notfallwiederherstellung für Azure Databricks-Cluster.

Azure Machine Learning

Eine Übersicht über die Hochverfügbarkeit mit Azure Machine Learning finden Sie unter Failover für Geschäftskontinuität und Notfallwiederherstellung.

Azure-Schlüsseltresor

Azure Key Vault stellt Funktionen zur Aufrechterhaltung der Verfügbarkeit und zur Vermeidung von Datenverlusten zur Verfügung. Sichern Sie Geheimnisse nur dann, wenn eine wichtige geschäftliche Begründung vorliegt. Das Sichern von Geheimnissen in Ihrem Schlüsseltresor kann betriebliche Herausforderungen mit sich bringen, etwa im Zusammenhang mit der Verwaltung von mehreren Protokoll-, Berechtigungs- und Sicherungssätzen beim Ablauf oder bei der Rotation von Geheimnissen. Weitere Informationen finden Sie unterAzure Key Vault-Sicherung.

Key Vault verwaltet die Verfügbarkeit in Notfallszenarien. Es leitet Anforderungen an eine gepaarte Region ohne Eingriff eines Benutzers um. Weitere Informationen finden Sie unter Azure Key Vault: Verfügbarkeit und Redundanz. Alternativ können Sie das Speichern von Geheimnissen und anderen Key Vault-Artefakten in einem sekundären Tresor mit entsprechenden Berechtigungen in Betracht ziehen. Dieses Muster eignet sich möglicherweise für Anwendungen, für die sich der Tresor in derselben Region wie die Anwendung befinden muss.

Azure SQL-Datenbank

Eine Übersicht über die Geschäftskontinuität mit einer Azure SQL-Datenbank finden Sie unter Übersicht über die Geschäftskontinuität mit einer Azure SQL-Datenbank.

Azure Synapse Analytics

Eine Übersicht über die Geschäftskontinuität mit Azure Synapse Analytics finden Sie unter Hochverfügbarkeit für Azure Synapse Analytics.

Nächste Schritte