Share via

Erstellen von BCDR-Lösungen (Business Continuity & Disaster Recovery) mit Azure Data Explorer

  • Artikel

In diesem Artikel erfahren Sie, wie Sie sich auf einen regionalen Azure-Ausfall vorbereiten können, indem Sie Ihre Azure Data Explorer-Ressourcen, Ihre Verwaltung und Ihre Erfassung in verschiedenen Azure-Regionen replizieren. Der Artikel enthält auch ein Beispiel für die Datenerfassung mit Azure Event Hubs. Außerdem wird auf die Kostenoptimierung bei verschiedenen Architekturkonfigurationen eingegangen. Eine ausführlichere Betrachtung von Architekturaspekten und Wiederherstellungslösungen finden Sie in der Übersicht über die Geschäftskontinuität.

Vorbereiten auf einen regionalen Azure-Ausfall zum Schutz Ihrer Daten

Azure Data Explorer bietet keinen automatischen Schutz vor dem Ausfall einer gesamten Azure-Region. Eine solche Störung kann durch eine Naturkatastrophe (beispielsweise ein Erdbeben) verursacht werden. Sollten Sie eine Notfallwiederherstellungslösung benötigen, führen Sie die folgenden Schritte aus, um die Geschäftskontinuität zu gewährleisten. In diesen Schritten werden Ihre Cluster, Ihre Verwaltung und Ihre Datenerfassung in zwei Azure-Regionspaaren repliziert.

  1. Erstellen Sie mindestens zwei unabhängige Cluster in zwei Azure-Regionspaaren.
  2. Replizieren Sie alle Verwaltungsaktivitäten wie etwa die Erstellung neuer Tabellen oder die Verwaltung von Benutzerrollen in jedem Cluster.
  3. Erfassen Sie Daten parallel in jedem Cluster.

Erstellen mehrerer unabhängiger Cluster

Erstellen Sie mehrere Azure Data Explorer-Cluster in mehreren Regionen. Mindestens zwei dieser Cluster müssen in Azure-Regionspaaren erstellt werden.

Die folgende Abbildung zeigt Replikate. Hierbei handelt es sich um drei Cluster in drei verschiedenen Regionen:

Erstellen unabhängiger Cluster

Replizieren von Verwaltungsaktivitäten

Replizieren Sie die Verwaltungsaktivitäten so, dass in jedem Replikat die gleiche Clusterkonfiguration vorhanden ist.

  1. Erstellen Sie in den einzelnen Replikaten jeweils die gleichen:

  2. Verwalten Sie die Authentifizierung und Autorisierung für jedes Replikat.

    Duplizieren von Verwaltungsaktivitäten

Notfallwiederherstellungslösung mit Event Hub-Erfassung

Nachdem Sie die Schritte unter Vorbereiten auf einen regionalen Azure-Ausfall zum Schutz Ihrer Daten ausgeführt haben, sind Ihre Daten und Ihre Verwaltung auf mehrere Regionen verteilt. Sollte eine Region ausfallen, kann Azure Data Explorer auf die anderen Replikate ausweichen.

Einrichten der Erfassung mit einem Event Hub

Zum Erfassen von Daten aus Azure Event Hubs in den Azure Data Explorer-Clustern der einzelnen Regionen replizieren Sie zunächst Ihr Azure Event Hubs-Setup in jeder Region. Konfigurieren Sie dann das Azure Data Explorer-Replikat jeder Region so, dass Daten aus den entsprechenden Event Hubs erfasst werden.

Hinweis

Die Erfassung über Azure Event Hubs/IoT Hub/Speicher ist robust. Sollte ein Cluster vorübergehend nicht verfügbar sein, wird er später auf den neuesten Stand gebracht, und ggf. ausstehenden Nachrichten oder Blobs werden eingefügt. Dieser Prozess basiert auf dem Setzen von Prüfpunkten.

Erfassung über Azure Event Hubs.

Wie im folgenden Diagramm zu sehen, werden von Ihren Datenquellen Ereignisse für Event Hubs in allen Regionen generiert und von den einzelnen Azure Data Explorer-Replikaten genutzt. Von Datenvisualisierungskomponenten wie Power BI, Grafana oder SDK-gestützten Web-Apps können Abfragen an eines der Replikate gesendet werden.

Datenquellen für die Datenvisualisierung

Optimieren der Kosten

Nun können Sie Ihre Replikate mithilfe einiger der folgenden Methoden optimieren:

Erstellen einer Konfiguration mit bedarfsgesteuerter Datenwiederherstellung

Durch die Replizierung und Aktualisierung des Azure Data Explorer-Setups nehmen die Kosten linear zur Replikatanzahl zu. Zur Kostenoptimierung können Sie eine Architekturvariante implementieren, um ein ausgewogenes Verhältnis zwischen Zeit, Failover und Kosten zu erreichen. In einer Konfiguration mit bedarfsgesteuerter Datenwiederherstellung wurde die Kostenoptimierung durch die Einführung passiver Azure Data Explorer-Replikate implementiert. Diese Replikate werden nur aktiviert, wenn in der primären Region (beispielsweise in der Region A) ein Notfall vorliegt. Die Replikate in den Regionen B und C müssen nicht rund um die Uhr aktiv sein, wodurch die Kosten erheblich sinken. In den meisten Fällen ist die Leistung dieser Replikate allerdings nicht so gut wie die des der primären Clusters. Weitere Informationen finden Sie unter Konfiguration mit bedarfsgesteuerter Datenwiederherstellung.

In der folgenden Abbildung erfasst nur ein einzelner Cluster Daten aus dem Event Hub. Vom primären Cluster in der Region A werden alle Daten mittels kontinuierlichem Datenexport in ein Speicherkonto exportiert. Von den sekundären Replikaten kann über externe Tabellen auf die Daten zugegriffen werden.

Architektur für eine Bedarfskonfiguration für die Datenwiederherstellung.

Starten und Beenden der Replikate

Die sekundären Replikate können mithilfe einer der folgenden Methoden gestartet und beendet werden:

az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>”

Implementieren eines hochverfügbaren Anwendungsdiensts

Erstellen des Azure App Service-BCDR-Clients

In diesem Abschnitt erfahren Sie, wie Sie eine Instanz von Azure App Service erstellen, die eine Verbindung mit einem einzelnen primären und mehreren sekundären Azure Data Explorer-Clustern unterstützt. In der folgenden Abbildung sehen Sie das Azure App Service-Setup:

Erstellen einer Azure App Service-Instanz

Tipp

Durch mehrere Verbindungen zwischen Replikaten im gleichen Dienst erhöht sich die Verfügbarkeit. Dieses Setup ist nicht nur bei regionalen Ausfällen hilfreich.

  1. Verwenden Sie diese Codebausteine für einen App-Dienst. Für die Implementierung eines Multiclusterclients wurde die Klasse AdxBcdrClient erstellt. Jede Abfrage, die mithilfe dieses Clients ausgeführt wird, wird zuerst an den primären Cluster gesendet. Im Falle eines Ausfalls wird die Abfrage an sekundäre Replikate gesendet.

  2. Verwenden Sie benutzerdefinierte Application Insights-Metriken, um die Leistung zu messen, und fordern Sie die Verteilung auf primäre und sekundäre Cluster an.

Testen des Azure App Service-BCDR-Clients

Wir haben einen Test mit mehreren Azure Data Explorer-Replikaten durchgeführt. Wie Sie sehen, verhält sich der App Service-BCDR-Client nach einem simulierten Ausfall primärer und sekundärer Cluster wie vorgesehen.

Überprüfen des App Service-BCDR-Clients

Die Azure Data Explorer-Cluster sind auf „Europa, Westen“ (2x D14v2, primär), „Asien, Südosten“ und „USA, Osten“ (2x D11v2) verteilt.

Antwortzeit für weltweite Abfragen

Hinweis

Langsamere Antwortzeiten sind auf unterschiedliche SKUs und weltweite Abfragen zurückzuführen.

Ausführen von dynamischem oder statischem Routing

Verwenden Sie Traffic Manager-Routingmethoden für dynamisches oder statisches Anforderungsrouting. Azure Traffic Manager ist ein DNS-basierter Lastenausgleichsdienst, mit dem Sie App Service-Datenverkehr verteilen können. Dieser Datenverkehr wird für Dienste in Azure-Regionen auf der ganzen Welt optimiert. Gleichzeitig profitieren Sie von Hochverfügbarkeit und hoher Reaktionsfähigkeit.

Sie können auch Azure Front Door-basiertes Routing verwenden. Eine Gegenüberstellung dieser beiden Methoden finden Sie unter Lastenausgleich mit der Azure-Suite für die Anwendungsbereitstellung.

Optimieren der Kosten in einer Aktiv/Aktiv-Konfiguration

Bei Verwendung einer Aktiv/Aktiv-Konfiguration für die Notfallwiederherstellung steigen die Kosten linear an. Darin enthalten sind die Kosten für Knoten, Speicher und Markup sowie höhere Netzwerkkosten für die Bandbreite.

Optimieren der Kosten durch optimierte Autoskalierung

Verwenden Sie das Feature Optimierte Autoskalierung, um die horizontale Skalierung für die sekundären Cluster zu konfigurieren. Diese sollten so dimensioniert sein, dass sie die Erfassungslast bewältigen können. Ist der primäre Cluster nicht erreichbar, erhöht sich der Datenverkehr für die sekundären Cluster, und die Cluster werden konfigurationsgemäß skaliert.

Durch die Verwendung der optimierten Autoskalierung konnten die Kosten in diesem Beispiel ungefähr halbiert werden (verglichen mit der Verwendung der gleichen horizontalen und vertikalen Skalierung für alle Replikate).

Verwandte Inhalte