Übersicht über Business Continuity & Disaster Recovery

Geschäftskontinuität und Notfallwiederherstellung in Azure Data Explorer ermöglicht Es Ihrem Unternehmen, angesichts einer Unterbrechung weiter zu arbeiten. In diesem Artikel werden mehrere Konfigurationen für die Notfallwiederherstellung je nach Wiederherstellungsanforderungen (RPO und RTO), erforderlichen Aufwand und Kosten beschrieben.

Weitere Informationen zu den verfügbaren Zuverlässigkeitsoptionen für Azure Data Explorer, einschließlich Verfügbarkeitszonenunterstützung, Sicherung und Schutz vor einigen Arten von menschlichem Fehler, finden Sie unter Reliability in Azure Data Explorer.

Notfallwiederherstellungskonfigurationen

Recovery Time Objective (RTO) bezieht sich auf die Zeit bis zur Wiederherstellung nach einer Störung. So bedeutet beispielsweise ein RTO-Wert von zwei Stunden, dass die Anwendung nach einer Störung innerhalb von zwei Stunden wieder verfügbar sein muss. Recovery Point Objective (RPO) bezieht sich auf die Zeit, die bei einer Störung vergehen kann, bis der Datenverlust den zulässigen Schwellenwert übersteigt. Wenn der RPO-Wert also beispielsweise 24 Stunden beträgt und eine Anwendung Daten aus den letzten 15 Jahren enthält, sind die Parameter des vereinbarten RPO-Werts weiterhin erfüllt.

Erfassungs-, Verarbeitungs- und Zusammenstellungsprozesse müssen bereits im Vorfeld der Notfallwiederherstellungsplanung sorgfältig entworfen werden. Die Datenaufnahme bezieht sich auf Daten, die aus verschiedenen Quellen in Azure Data Explorer integriert sind; die Verarbeitung bezieht sich auf Transformationen und ähnliche Aktivitäten; die Kurierung bezieht sich auf materialisierte Ansichten, Exporte in den Datensee usw.

Es folgen häufig verwendete Notfallwiederherstellungskonfigurationen:

• Aktiv/Aktiv/Aktiv-Konfiguration (immer eingeschaltet)
• Aktiv/Aktiv-Konfiguration
• Aktive-Hot-Standby-Konfiguration
• Konfiguration mit bedarfsgesteuertem Datenwiederherstellungscluster

Aktiv/Aktiv/Aktiv-Konfiguration

Diese Konfiguration wird auch als Always-On bezeichnet. Bei kritischen Anwendungsbereitstellungen ohne Toleranz für Ausfälle sollten Sie mehrere Azure Data Explorer Cluster in Azure gekoppelten Regionen verwenden. Richten Sie die Erfassung, Verarbeitung und Zusammenstellung parallel zu allen Clustern ein. Die Cluster-SKU muss regionsübergreifend gleich sein. Azure stellt sicher, dass Updates in Azure gekoppelten Regionen bereitgestellt und gestaffelt werden. Ein Azure Bereichsausfall verursacht keinen Anwendungsausfall. Möglicherweise treten latenz- oder Leistungsbeeinträchtigungen auf.

Aktiv/Aktiv-Konfiguration

Diese Konfiguration ist identisch mit der Konfiguration active-active-active, umfasst jedoch nur zwei Azure-gekoppelte Regionen. Konfigurieren Sie eine duale Erfassung, Verarbeitung und Zusammenstellung. Benutzer werden an die nächstgelegene Region weitergeleitet. Die Cluster-SKU muss regionsübergreifend gleich sein.

Aktiv-Hot-Standby-Konfiguration

Die Aktiv-Heiß-Konfiguration ähnelt der Aktiv/Aktiv-Konfiguration in Bezug auf die duale Eingabe, Verarbeitung und Kuratierung. Während der Standby-Cluster für Aufnahme, Verarbeitung und Kurierung online ist, steht er nicht zur Abfrage zur Verfügung. Der Standbycluster muss sich nicht in derselben SKU wie der primäre Cluster befinden. Es kann sich um eine kleinere SKU und Skalierung handeln, was dazu führen könnte, dass es weniger leistungsstark ist. In einem Notfallszenario werden Benutzer an den Standbycluster umgeleitet, der optional skaliert werden kann, um die Leistung zu erhöhen.

Konfiguration mit bedarfsgesteuerter Datenwiederherstellung

Diese Lösung bietet die geringste Wiederherstellbarkeit (höchstes RPO und RTO), ist am niedrigsten in den Kosten und am höchsten im Aufwand. In dieser Konfiguration gibt es keinen Datenwiederherstellungscluster. Konfigurieren Sie den fortlaufenden Export zusammengestellter Daten (es sei denn, es werden auch Roh- und Zwischendaten benötigt) für ein Speicherkonto mit GRS-Konfiguration (georedundanter Speicher). Ein Datenwiederherstellungscluster wird ausgelöst, wenn ein Notfallwiederherstellungsszenario vorhanden ist. Zu diesem Zeitpunkt werden DDLs, die Konfiguration, Richtlinien und Prozesse angewendet. Daten werden aus dem Speicher mit der Erfassungseigenschaft kustoCreationTime aufgenommen, um die Aufnahmezeit außer Kraft zu setzen, die standardmäßig auf Systemzeit festgelegt ist.

Zusammenfassung der Optionen für die Notfallwiederherstellungskonfiguration

Bewährte Methoden

Die folgenden bewährten Methoden sollten unabhängig von der gewählten Notfallwiederherstellungskonfiguration angewendet werden:

• Alle Datenbankobjekte, -richtlinien und -konfigurationen sollten in der Quellcodeverwaltung gespeichert werden, um sie per Releaseautomatisierungstool für den Cluster veröffentlichen zu können. Weitere Informationen finden Sie unter Azure DevOps Support für Azure Data Explorer.
• Entwerfen, entwickeln und implementieren Sie Validierungsroutinen, um sicherzustellen, dass die Daten aller Cluster synchronisiert sind. Azure Data Explorer unterstützt Cluster-übergreifende Joins. Eine einfache tabellenübergreifende Zeilenzählung kann zur Validierung beitragen.
• Die Freigabeverfahren sollten Governance-Kontrollen und -Ausgleiche beinhalten, die die Spiegelung der Cluster sicherstellen.
• Machen Sie sich umfassend mit den Anforderungen für die Neuerstellung eines Clusters vertraut.
• Erstellen Sie eine Prüfliste mit Bereitstellungseinheiten. Ihre Liste ist für Ihre Anforderungen einzigartig, sollte jedoch folgendes umfassen: Bereitstellungsskripts, Aufnahmeverbindungen, BI-Tools und andere wichtige Konfigurationen.

Nächster Schritt