Business Continuity & Disaster Recovery

Notfälle können Hardwareausfälle, Naturkatastrophen oder Softwarefehler sein. Der Prozess der Vorbereitung auf und Wiederherstellung nach einem Notfall wird als Notfallwiederherstellung (Disaster Recovery, DR) bezeichnet. In diesem Artikel werden empfohlene Methoden zum Erreichen von Geschäftskontinuität und Notfallwiederherstellung (BCDR) für Azure Operator Insights erläutert.

BCDR-Strategien umfassen Verfügbarkeitszonenredundanz und vom Benutzer verwaltete Wiederherstellung.

Steuerungsebene

Die Azure Operator Insights-Steuerungsebene ist sowohl gegenüber Softwarefehlern als auch gegenüber Fehler einer Verfügbarkeitszone widerstandsfähig. Die Möglichkeit zum Erstellen und Verwalten von Datenprodukten ist von diesen Fehlermodi nicht betroffen.

Die Steuerungsebene ist nicht regional redundant. Während eines Ausfalls in einer Azure-Region können Sie keine neuen Datenprodukte in dieser Region erstellen oder vorhandene Produkte zugreifen/verwalten. Sobald sich die Region aus dem Ausfall wiederherstellen lässt, können Sie erneut auf vorhandene Datenprodukte zugreifen und diese verwalten.

Datenebene

Datenprodukte sind widerstandsfähig gegen Software- oder Hardwarefehler. Wenn beispielsweise ein Softwarefehler dazu führt, dass der Dienst abstürzt, oder ein Hardwarefehler bewirkt, dass die Computeressourcen für Anreicherungsabfragen verloren gehen, wird der Dienst automatisch wiederhergestellt. Die einzige Auswirkung ist eine leichte Verzögerung bei neu aufgenommenen Daten, die im Speicherendpunkt des Datenprodukts und in der KQL-Verbrauchs-URL verfügbar werden.

Zonenredundanz

Datenprodukte unterstützen keine Zonenredundanz. Wenn eine Verfügbarkeitszone fehlschlägt, sind die Aufnahme, blob/DFS und KQL/SQL-APIs des Datenprodukts nicht verfügbar, und Dashboards funktionieren nicht. Die Transformation bereits aufgenommener Daten wird angehalten. Es gehen keine zuvor aufgenommenen Daten verloren. Die Verarbeitung wird fortgesetzt, wenn die Verfügbarkeitszone wiederhergestellt wird.

Was mit Daten passiert, die während des Ausfalls der Verfügbarkeitszone generiert wurden, hängt vom Verhalten des Aufnahme-Agents ab:

• Wenn der Aufnahme-Agent Daten puffert und erneut sendet, wenn die Verfügbarkeitszone wiederhergestellt wird, gehen die Daten nicht verloren. Azure Operator Insights kann einige Zeit in Anspruch nehmen, um den Transformations-Backlog zu durchlaufen.
• Andernfalls gehen Daten verloren.

Notfallwiederherstellung

Azure Operator Insights hat keine angeborene Regionsredundanz. Regionale Ausfälle wirken sich auf Datenprodukte auf die gleiche Weise wie Verfügbarkeitszonenfehler aus. Wir haben Empfehlungen und Features, um Kunden zu unterstützen, die in der Lage sein möchten, den Ausfall einer gesamten Azure-Region zu bewältigen.

Vom Benutzer verwaltete Redundanz

Für maximale Redundanz können Sie Datenprodukte im aktiven Modus bereitstellen. Stellen Sie ein zweites Datenprodukt in einer Azure-Sicherungsregion Ihrer Wahl bereit, und konfigurieren Sie Ihre Aufnahme-Agents so, dass Daten gleichzeitig auf beide Datenprodukte gezweigt werden. Das Sicherungsdatenprodukt ist von dem Fehler der primären Region nicht betroffen. Sehen Sie sich während eines regionalen Ausfalls Dashboards an, die das Sicherungsdatenprodukt als Datenquelle verwenden. Diese Architektur verdoppelt die Kosten der Lösung.

Alternativ können Sie einen aktiven passiven Modus verwenden. Stellen Sie ein zweites Datenprodukt in einer Azure-Sicherungsregion bereit, und konfigurieren Sie Ihre Aufnahme-Agents so, dass sie an das primäre Datenprodukt gesendet werden. Konfigurieren Sie während eines regionalen Ausfalls Ihre Aufnahme-Agents neu, um Daten während eines Regionsausfalls an das Sicherungsdatenprodukt zu senden. Diese Architektur ermöglicht den vollständigen Zugriff auf Daten, die während des Ausfalls erstellt wurden (beginnend mit dem Zeitpunkt, zu dem Sie die Aufnahme-Agents neu konfigurieren), aber während des Ausfalls haben Sie keinen Zugriff auf Daten, die vor diesem Zeitpunkt aufgenommen wurden. Diese Architektur erfordert eine geringe Infrastrukturgebühr für das zweite Datenprodukt, aber keine zusätzlichen Datenverarbeitungsgebühren.