Zuverlässigkeit in Azure Event Hubs

Azure Event Hubs ist ein nativer Clouddienst, der Millionen von Ereignissen pro Sekunde mit geringer Latenz von jeder Quelle bis zu jedem Beliebigen Ziel streamen kann. Verwenden Sie Event Hubs, um Streamingdaten aufzunehmen und zu speichern und in Clientanwendungen zu integrieren, die für Apache Kafka oder Anwendungen erstellt wurden, die die Event Hubs-Client-SDKs verwenden.

Wenn Sie Azure verwenden, ist Zuverlässigkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird beschrieben, wie Event Hubs für eine Vielzahl potenzieller Ausfälle und Probleme widerstandsfähig ist und wie Sie diese so konfigurieren können, dass sie für andere widerstandsfähig ist, einschließlich vorübergehender Fehler, Ausfall von Verfügbarkeitszonen und Regionsausfällen. Darüber hinaus werden Sicherungs- und Wiederherstellungsoptionen beschrieben, und es werden einige wichtige Informationen zum Servicelevelvertrag von Azure Event Hubs (SLA) erläutert.

Bereitstellungsempfehlungen für die Produktion

Informationen zum Bereitstellen von Event Hubs zur Unterstützung der Zuverlässigkeitsanforderungen Ihrer Lösung und zum Verständnis, wie sich die Zuverlässigkeit auf andere Aspekte Ihrer Architektur auswirkt, finden Sie unter Architektur bewährte Methoden für Event Hubs im Azure Well-Architected Framework.

Übersicht über die Zuverlässigkeitsarchitektur

In diesem Abschnitt werden wichtige Aspekte zur Funktionsweise von Event Hubs aus Zuverlässigkeitsperspektive beschrieben. Es führt die logische Architektur ein, die Ressourcen und Features enthält, die Sie bereitstellen und verwenden. Außerdem wird die physische Architektur erläutert, die Details dazu bereitstellt, wie der Dienst Vorgänge intern verwaltet.

Logische Architektur

Ein Event Hubs-Namespace dient als Verwaltungscontainer für einen oder mehrere Event Hubs. Sie konfigurieren den Dienst, z. B. das Zuordnen der Streamingkapazität, das Konfigurieren der Netzwerksicherheit und die Aktivierung der Georesilienz und der Geo-Notfallwiederherstellung auf Namespaceebene.

Innerhalb eines Namespaces können Sie Ereignisse in einem Event Hub organisieren. Das Apache® Kafka-Ökosystem bezieht sich auf diese Art von Entität als Thema. Der Event Hub oder das Thema ist ein verteiltes Protokoll Ihrer Ereignisse, das nur Anfügevorgänge unterstützt.

Jeder Event Hub enthält eine oder mehrere Partitionen, die Protokolle sequenzieller Ereignisse sind. Ein Event Hub kann mehrere Partitionen verwenden, um parallele Verarbeitung und horizontale Skalierung durchzuführen. Event Hubs garantiert nur die Reihenfolge innerhalb einer einzelnen Partition. Die Partitionierung spielt eine wichtige Rolle im Zuverlässigkeitsentwurf Ihrer Anwendung. Wenn Sie Ihre Anwendung entwerfen, machen Sie einen Kompromiss zwischen Maximierung der Verfügbarkeit und Konsistenz. Um die Betriebszeit für die meisten Anwendungen zu maximieren, vermeiden Sie die Direkte Adressierung von Partitionen aus Ihren Clientanwendungen. Weitere Informationen finden Sie unter Verfügbarkeit und Konsistenz in Event Hubs.

Verbraucher, die vom Event Hub lesen, können ihre Ereignisse sequenziell lesen, indem sie ihren eigenen Checkpoint beibehalten, der das letzte empfangene Ereignis identifiziert.

Weitere Informationen zu Partitionen und anderen grundlegenden Konzepten in Event Hubs finden Sie unter Features und Terminologie in Event Hubs.

Physische Architektur

In der physischen Architektur wird ein Event Hubs-Namespace innerhalb eines Clusters ausgeführt. Ein Cluster stellt die zugrunde liegenden Compute- und Speicherressourcen bereit. Die meisten Namespaces werden auf Clustern ausgeführt, die andere Azure-Kunden teilen. Wenn Sie das Premium-Tier nutzen, werden dem Namespace dedizierte Ressourcen innerhalb eines gemeinsamen Clusters zugewiesen. Wenn Sie die Dedizierte Ebene verwenden, ist ein Cluster ihren Namespaces zugeordnet. Weitere Informationen zu dedizierten Clustern finden Sie unter "Event Hubs Dedicated tier overview". Unabhängig vom Ebenen- und Clustertyp verwaltet Microsoft die Cluster und deren zugrunde liegende virtuelle Computer und Speicher.

Um Redundanz zu erzielen, verfügt jeder Cluster über mehrere Replikate, die Lese- und Schreibanforderungen verarbeiten. Für hohe Verfügbarkeit und Leistungsoptimierung werden alle Daten auf drei Speicherreplikaten gespeichert. Um die Computeressourcen Ihres Namespace zu skalieren, stellen Sie je nach Ebene Durchsatzeinheiten (TUs), Verarbeitungseinheiten (PUs) oder Kapazitätseinheiten (CUs) bereit. Weitere Informationen finden Sie unter Skalieren mit Event Hubs.

Cluster umfassen mehrere physische Maschinen und Racks, wodurch das Risiko von katastrophalen Fehlern verringert wird, die Ihren Namespace beeinträchtigen. In Regionen mit Verfügbarkeitszonen erstrecken sich Cluster über separate physische Rechenzentren. Weitere Informationen finden Sie unter Resilienz bei Ausfällen von Verfügbarkeitszonen.

Resilienz für vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zum Umgang mit vorübergehenden Fehlern.

Event Hubs implementiert transparente Fehlererkennungs- und Failovermechanismen, sodass der Dienst weiterhin innerhalb der gesicherten Dienstebenen arbeitet, in der Regel ohne erkennbare Unterbrechungen, wenn Fehler auftreten.

Wenn Sie Clientanwendungen für die Arbeit mit Event Hubs entwerfen, befolgen Sie diese Anleitung:

• Verwenden Sie integrierte Wiederholungsrichtlinien. Die Event Hubs und Apache Kafka SDKs wiederholen automatisch Wiederholungsvorgänge für wiederholungsfähige Fehler wie Netzwerktimeouts, Drosselungsantworten oder wenn der Server ausgelastet ist. Um unnötige Überlastung des Diensts zu vermeiden, implementieren sie standardmäßig exponentielle Backoffs.

• Konfigurieren Sie geeignete Timeoutwerte basierend auf Ihren Anwendungsanforderungen. Das Standardtimeout beträgt in der Regel 60 Sekunden, Sie können es jedoch basierend auf Ihrem Szenario anpassen.

• Implementieren Sie Prüfpunkte in Ihrem Ereignisprozessor, um den Fortschritt nachzuverfolgen und die Wiederherstellung von der letzten verarbeiteten Position nach vorübergehenden Fehlern zu aktivieren.

• Verwenden Sie Batchverarbeitung für Sendevorgänge , um den Durchsatz zu verbessern und die Auswirkungen vorübergehender Netzwerkprobleme auf einzelne Nachrichten zu verringern.

• Verwenden Sie Apache Kafka SDKs , wenn Sie mit dem Kafka-Protokoll arbeiten. Die Kafka-SDKs implementieren auch Wiederholungsrichtlinien und andere bewährte Methoden, die bei der Behandlung vorübergehender Fehler helfen.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb einer Azure-Region. Wenn eine Zone ausfällt, kann für die Dienste ein Failover zu einer der verbleibenden Zonen erfolgen.

Event Hubs unterstützt zonenredundante Bereitstellungen in allen Dienstebenen. Wenn Sie einen Event Hubs-Namespace in einer unterstützten Region erstellen, wird Zonenredundanz automatisch ohne zusätzliche Kosten aktiviert. Aber mit der dedizierten Ebene werden Verfügbarkeitszonen nur mit mindestens drei CUs unterstützt. Das zonenredundante Bereitstellungsmodell gilt für alle Event Hubs-Features, einschließlich Capture, Schema Registry und Kafka-Protokollunterstützung.

Event Hubs repliziert Ihre Konfigurations-, Metadaten- und Ereignisdaten transparent in drei Verfügbarkeitszonen in der Region. Zonenredundanz bietet automatisches Failover, ohne dass ein Eingriff Ihrerseits erforderlich ist. Alle Event Hubs-Komponenten, einschließlich Compute, Netzwerk und Speicher, werden über Zonen repliziert. Event Hubs verfügt über genügend Kapazitätsreserven, um den vollständigen Verlust einer Zone sofort zu bewältigen. Auch wenn eine gesamte Verfügbarkeitszone nicht verfügbar ist, funktioniert Event Hubs weiterhin ohne Datenverlust oder Unterbrechung von Streaminganwendungen.

Regionsunterstützung

Zonenredundante Event Hubs-Namespaces können in einer beliebigen Azure-Region bereitgestellt werden, die Verfügbarkeitszonen unterstützt.

Anforderungen

• Standard- und Premium-Stufen unterstützen Verfügbarkeitszonen ohne zusätzliche Konfiguration.

• Für die dedizierte Ebene erfordern Verfügbarkeitszonen mindestens drei CUs.

Kosten

Die Zonenredundanz in Event Hubs bietet keine zusätzlichen Kosten.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

Event Hubs-Namespaces unterstützen zonenredundanz automatisch, wenn sie in unterstützten Regionen bereitgestellt werden. Es ist keine weitere Konfiguration erforderlich.

Verhalten, wenn alle Zonen fehlerfrei sind

Wenn Event Hubs-Namespaces Zonenredundanz verwenden und alle Verfügbarkeitszonen normal funktionieren, erwarten Sie folgendes Verhalten:

• Datenverkehrsrouting zwischen Zonen: Event Hubs arbeitet in einem aktiven Modell, in dem die Infrastruktur in drei Verfügbarkeitszonen gleichzeitig eingehende Ereignisse verarbeitet.

• Datenreplikation zwischen Zonen: Event Hubs verwenden synchrone Replikation über Verfügbarkeitszonen hinweg. Wenn ein Ereignisproduzent ein Ereignis sendet, schreibt Event Hubs es zuerst in Replikate in mehreren Zonen und sendet erst dann eine Bestätigung des abgeschlossenen Schreibvorgangs an den Client. Durch diesen Ansatz wird kein Datenverlust sichergestellt, auch wenn eine gesamte Zone nicht verfügbar ist. Der synchrone Replikationsansatz bietet starke Konsistenzgarantien bei gleichzeitiger Beibehaltung geringer Latenz durch optimierte Replikationsprotokolle.

Verhalten bei einem Zoneausfall

Wenn Event Hubs-Namespaces Zonenredundanz verwenden und ein Ausfall der Verfügbarkeitszone auftritt, erwarten Sie folgendes Verhalten:

• Erkennung und Reaktion: Event Hubs ist für die automatische Erkennung eines Fehlers in einer Verfügbarkeitszone verantwortlich. Sie müssen kein Zonenfailover initiieren.

• Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone deaktiviert ist. Sie können jedoch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich aller Zonenfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

• Aktive Anforderungen: Beim Ausfall einer Zone können Ereignishubs aktive Anforderungen verwerfen. Wenn Ihre Clients vorübergehende Fehler angemessen behandeln, indem sie nach kurzer Zeit erneut versuchen, vermeiden sie in der Regel erhebliche Auswirkungen.

• Erwarteter Datenverlust: Während eines Zonenfehlers tritt kein Datenverlust auf, da Event Hubs Ereignisse vor der Bestätigung synchron über Zonen repliziert.

• Erwartete Ausfallzeiten: Ein Zonenfehler kann zu einigen Sekunden Ausfallzeiten führen. Wenn Ihre Clients vorübergehende Fehler angemessen behandeln, indem sie nach kurzer Zeit erneut versuchen, vermeiden sie in der Regel erhebliche Auswirkungen.

• Datenverkehrsumleitung: Event Hubs erkennt den Verlust der Zone und leitet neue Anforderungen automatisch an ein anderes Replikat in einer der fehlerfreien Verfügbarkeitszonen weiter.

  Event Hubs-Client-SDKs behandeln in der Regel Verbindungsverwaltung und Wiederholungslogik transparent.

Zonenwiederherstellung

Wenn eine Verfügbarkeitszone wiederhergestellt wird, integriert Event Hubs die Zone automatisch in die aktive Diensttopologie. Die wiederhergestellte Zone beginnt, neue Verbindungen und Verarbeitungsereignisse zusammen mit den anderen Zonen zu akzeptieren. Daten, die während des Ausfalls in überlebende Zonen repliziert wurden, bleiben intakt, und die normale synchrone Replikation wird in allen Zonen fortgesetzt. Sie müssen keine Maßnahmen für die Zonenwiederherstellung und -wiedereingliederung ergreifen.

Test auf Zonenfehler

Da Event Hubs Datenverkehrsrouting, Failover und Zonenwiederherstellung für Zonenfehler verwaltet, müssen Sie keine Prozesse für Verfügbarkeitszonenfehler überprüfen oder weitere Eingaben bereitstellen.

Widerstandsfähigkeit bei regionalen Ausfällen

Event Hubs bieten zwei Arten von Unterstützung für mehrere Regionen:

• Die Georeplikation (Premium- und dedizierte Ebenen) bietet eine aktive Replikation von Metadaten- und Ereignisdaten zwischen einer primären Region und einer oder mehreren sekundären Regionen. Verwenden Sie die Georeplikation für die meisten Anwendungen, die ausfallsicher für Regionen bleiben müssen und eine geringe Toleranz für Ereignisdatenverlust aufweisen.

• Metadaten-Geo-Notfallwiederherstellung (Standardebene und höher) bietet eine aktive passive Replikation von Konfiguration und Metadaten zwischen einer primären und sekundären Region, repliziert jedoch keine Ereignisdaten. Verwenden Sie die Geo-Notfallwiederherstellung für Anwendungen, die während eines Notfallszenarios ereignisbedingte Datenverluste tolerieren können und die Vorgänge in einer anderen Region schnell fortsetzen müssen.

Sowohl georeplikation als auch Metadaten-Geo-Notfallwiederherstellung erfordern, dass Sie ein Failover oder eine Heraufstufung einer sekundären Region manuell initiieren, um zur neuen primären Region zu werden. Microsoft führt nicht automatisch ein Failover oder eine Höherstufung durch, auch wenn Ihre primäre Region ausgefallen ist.

Georeplikation

Die Premium- und dedizierten Ebenen unterstützen die Georeplikation. Dieses Feature repliziert sowohl Metadaten (z. B. Entitäten, Konfiguration und Eigenschaften) als auch Daten (z. B. Ereignisnutzlasten) für den Namespace. Sie konfigurieren den Replikationsansatz für die Konfigurations- und Ereignisdaten Ihres Namespaces. Mit diesem Feature wird sichergestellt, dass Ihre Ereignisse in einer anderen Region verfügbar bleiben und sie bei Bedarf zur sekundären Region wechseln können. Außerdem werden Schemaregistrierungsmetadaten und -daten repliziert.

Verwenden Sie die Georeplikation für Szenarien, die Ausfallsicherheit für Regionen erfordern und eine geringe Toleranz für Ereignisdatenverlust aufweisen.

Der Namespace erstreckt sich im Wesentlichen über Regionen. Eine Region dient als primäre Region, und die anderen Regionen dienen als Secondaries. Ihr Azure-Abonnement zeigt einen einzelnen Namespace an, unabhängig davon, wie viele sekundäre Regionen Sie für die Georeplikation konfigurieren.

Sie können jederzeit eine sekundäre Region zu einer primären Region heraufstufen . Wenn Sie eine sekundäre Region heraufstufen, weist Event Hubs den vollqualifizierten Domänennamen (FQDN) des Namespaces der ausgewählten sekundären Region neu zu und stuft die vorherige primäre Region zu einer sekundären Region herab. Sie entscheiden, ob eine geplante Heraufstufung durchgeführt werden soll, was bedeutet, dass Sie warten, bis die Datenreplikation abgeschlossen ist, oder eine erzwungene Heraufstufung, was zu Datenverlust führen kann.

In diesem Abschnitt werden wichtige Aspekte der Georeplikation zusammengefasst. Lesen Sie die vollständige Dokumentation, um genau zu verstehen, wie es funktioniert. Weitere Informationen finden Sie unter Georeplikation von Event Hubs.

Regionsunterstützung

Sie können eine beliebige Azure-Region auswählen, die Event Hubs als primäre Region oder sekundäre Regionen unterstützt. Sie müssen keine gekoppelten Azure-Regionen verwenden, sodass Sie sekundäre Regionen basierend auf Ihren Latenz-, Compliance- oder Datenresidency-Anforderungen auswählen können.

Anforderungen

Um die Georeplikation zu aktivieren, muss Ihr Namespace die Premium- oder dedizierte Ebene verwenden.

Überlegungen

Berücksichtigen Sie beim Aktivieren der Georeplikation die folgenden Faktoren:

• Prüfpunktformat: Das Format der Prüfpunkte ändert sich. Weitere Informationen finden Sie unter Georeplikation: Verwenden von Daten.

• Private Endpunkte: Wenn Sie private Endpunkte verwenden, um eine Verbindung mit Ihrem Namespace herzustellen, müssen Sie auch das Netzwerk in Ihren primären und sekundären Regionen konfigurieren. Weitere Informationen finden Sie unter Private Endpunkte.

Kosten

Informationen dazu, wie die Preise für die Georeplikation funktionieren, finden Sie unter "Preise".

Konfigurieren der Unterstützung für mehrere Regionen

• Aktivieren sie die Georeplikation für einen neuen oder vorhandenen Namespace. Informationen zum Einrichten der aktiven Replikation für einen neu erstellten Namespace finden Sie unter Aktivieren der Georeplikation für einen neuen Namespace. Informationen zum Einrichten der aktiven Replikation für einen vorhandenen Namespace finden Sie unter Aktivieren der Georeplikation für einen vorhandenen Namespace.

• Ändern Sie den Replikationsansatz. Informationen zum Wechseln zwischen synchronen und asynchronen Replikationsmodi finden Sie unter Switch-Replikationsmodus.

• Deaktivieren Sie die Georeplikation. Informationen zum Deaktivieren der Georeplikation in eine sekundäre Region finden Sie unter Entfernen einer sekundären Region.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Event Hubs-Namespace für die Georeplikation konfiguriert ist und die primäre Region betriebsbereit ist.

• Datenverkehrsrouting zwischen Regionen: Clientanwendungen verbinden sich über den FQDN Ihres Namespace, und ihr Datenverkehr wird zur primären Region weitergeleitet.

  Nur die primäre Region verarbeitet Ereignisse von Clients während normaler Vorgänge aktiv. Die sekundäre Region empfängt replizierte Ereignisse, bleibt aber andernfalls im Standbymodus passiv.

• Datenreplikation zwischen Regionen: Das Verhalten der Datenreplikation zwischen den primären und sekundären Regionen hängt davon ab, ob Sie die Replikationspaarung so konfigurieren, dass synchrone oder asynchrone Replikation verwendet wird.

  • Synchron: Ereignisse werden in den sekundären Bereich repliziert, bevor der Schreibvorgang abgeschlossen ist.

    Dieser Modus bietet die größte Sicherheit, dass Ihre Ereignisdaten sicher sind, da sie in der primären und sekundären Region gespeichert werden müssen. Die synchrone Replikation erhöht jedoch die Schreiblatenz für eingehende Ereignisse erheblich. Außerdem muss der sekundäre Bereich verfügbar sein, um den Schreibvorgang zu akzeptieren, sodass ein Ausfall in jedem sekundären Bereich dazu führt, dass der Schreibvorgang fehlschlägt.

    • Asynchron: Ereignisse werden in die primäre Region geschrieben und dann wird der Schreibvorgang abgeschlossen. Kurze Zeit später repliziert sie die Ereignisse in die sekundäre Region.

    Dieser Modus bietet einen höheren Schreibdurchsatz als die synchrone Replikation, da während Schreibvorgängen keine Latenz für die Replikation zwischen Regionen besteht. Außerdem kann der asynchrone Replikationsmodus den Verlust einer sekundären Region tolerieren und gleichzeitig Schreibvorgänge in der primären Region zulassen. Wenn der primäre Bereich jedoch einen Ausfall aufweist, sind daten, die noch nicht in die sekundäre Region repliziert wurden, möglicherweise nicht verfügbar oder verloren gegangen.

    Wenn Sie die asynchrone Replikation konfigurieren, konfigurieren Sie die maximale zulässige Verzögerungszeit für die Replikation. Sie können die aktuelle Replikationsverzögerung jederzeit mithilfe von Azure Monitor-Metriken überprüfen.

    Wenn die Verzögerung der asynchronen Replikation über das von Ihnen angegebene Maximum hinaus steigt, beginnt die primäre Region, eingehende Anforderungen zu drosseln, damit die Replikation aufholen kann. Um diese Situation zu vermeiden, ist es wichtig, sekundäre Regionen auszuwählen, die nicht zu geografisch entfernt sind, und um sicherzustellen, dass Ihre Kapazität für den Durchsatz ausreicht.

    Weitere Informationen finden Sie unter Replikationsmodi.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Event Hubs-Namespace für die Georeplikation konfiguriert ist und ein Ausfall in der primären oder sekundären Region vorhanden ist.

• Erkennung und Reaktion: Sie sind dafür verantwortlich, zu entscheiden, wann die sekundäre Region Ihres Namespace zur neuen primären Region wird. Microsoft macht diese Entscheidung nicht oder initiiert den Prozess für Sie, auch wenn es einen Regionsausfall gibt. Informationen zum Höherstufen einer sekundären Region als neue primäre Region finden Sie unter Höherstufen der sekundären Region.

  Wenn Sie eine sekundäre Region bewerben, wählen Sie aus, ob eine geplante Werbeaktion oder eine erzwungene Aktion ausgeführt werden soll. Eine geplante Promotion wartet darauf, dass die sekundäre Region aufgeholt hat, bevor neuer Traffic akzeptiert wird. Dieser Ansatz beseitigt Datenverlust, führt aber zu Ausfallzeiten.

  Während eines Ausfalls in der primären Region müssen Sie in der Regel eine erzwungene Heraufstufung durchführen. Wenn die primäre Region verfügbar ist und Sie eine Aktion aus einem anderen Grund auslösen, können Sie eine geplante Werbeaktion auswählen.

• Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Sie können jedoch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich aller Regionsfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

  Verwenden Sie diese Informationen und andere Metriken, um zu entscheiden, wann eine sekundäre Region in eine primäre Region heraufstufen soll.

• Aktive Anforderungen: Das Verhalten hängt davon ab, ob der Regionsausfall in der primären oder in einer sekundären Region auftritt:

  • Ausfall des primären Bereichs: Wenn der primäre Bereich nicht verfügbar ist, werden alle aktiven Anforderungen beendet. Clientanwendungen sollten Vorgänge wiederholen, nachdem die Heraufstufung abgeschlossen wurde.

  • Ausfall des sekundären Bereichs: Ein Ausfall in der sekundären Region kann probleme mit aktiven Anforderungen in den folgenden Situationen verursachen:

    • Wenn Sie den synchronen Replikationsmodus verwenden, kann der primäre Bereich Schreibvorgänge nicht abschließen, wenn eine sekundäre Region nicht verfügbar ist.

    • Wenn Sie den asynchronen Replikationsmodus verwenden, drosselt Der Namespace und akzeptiert keine neuen Ereignisse, nachdem die Replikationsverzögerung das von Ihnen konfigurierte Maximum erreicht hat.

    Um den Namespace in der primären Region weiterhin zu verwenden, entfernen Sie den sekundären Namespace aus Ihrer Georeplikationskonfiguration.

• Erwarteter Datenverlust: Die Menge des Datenverlusts hängt von der Art der Heraufstufung ab, die Sie ausführen (geplant oder erzwungen) und den Replikationsmodus (synchron oder asynchron):

  • Geplante Promotion: Es wird kein Datenverlust erwartet. Während eines Ausfalls einer Region ist eine geplante Förderung jedoch möglicherweise nicht möglich, da alle primären und sekundären Regionen verfügbar sein müssen.

  • Erzwungene Heraufufung, synchrone Replikation: Es wird kein Datenverlust erwartet.

  • Erzwungene Hochstufung, asynchrone Replikation: Möglicherweise treten Datenverluste bei aktuellen Ereignissen auf, die nicht in die sekundäre Region repliziert sind. Der Betrag hängt von der Replikationsverzögerung ab. Verwenden Sie Azure Monitor-Metriken, um die aktuelle Replikationsverzögerung zu überprüfen.

  Wenn Sie eine erzwungene Heraufstufung durchführen, können Sie verlorene Daten nicht wiederherstellen, auch nachdem die primäre Region verfügbar ist.

• Erwartete Ausfallzeiten: Das Ausmaß der erwarteten Ausfallzeiten hängt davon ab, ob Sie eine geplante oder erzwungene Beförderung vornehmen:

  • Geplante Promotion: Der erste Schritt in einer geplanten Heraufstufung repliziert Daten in die Sekundärregion. Dieser Prozess wird in der Regel schnell abgeschlossen, aber in einigen Situationen kann es bis zur Länge der Replikationsverzögerung dauern. Nach Abschluss der Replikation dauert der Beförderungsprozess normalerweise 5 bis 10 Minuten. Es kann manchmal länger dauern, bis DNS-Server (Domain Name System) Einträge aktualisieren und ihre Einträge vollständig auf Clients replizieren.

    Die primäre Region akzeptiert während des gesamten Heraufstufungsprozesses keine Schreibvorgänge.

    Diese Option ist möglicherweise während eines Regionsausfalls nicht möglich, da alle primären und sekundären Regionen verfügbar sein müssen.

  • Erzwungene Beförderung: Während einer erzwungenen Beförderung wartet Event Hubs nicht, bis die Datenreplikation abgeschlossen ist, sondern initiiert die Beförderung sofort. In der Regel dauert der Beförderungsprozess etwa 5 bis 10 Minuten. Es kann manchmal länger dauern, bis DNS-Einträge vollständig repliziert und bei allen Clients aktualisiert werden.

    Die primäre Region akzeptiert während des gesamten Heraufstufungsprozesses keine Schreibvorgänge.

• Datenverkehrsumleitung: Nach Abschluss der Höherstufung verweist der Namespace-FQDN auf die neue primäre Region. Diese Umleitung hängt jedoch davon ab, wie schnell die DNS-Einträge der Clients aktualisiert werden, wobei auch berücksichtigt wird, dass ihre DNS-Server die Time-to-Live (TTL) der Namespace-DNS-Einträge respektieren.

  In einigen Fällen müssen Sie Consumeranwendungen so konfigurieren, dass sie sich konsistent verhalten, nachdem die Regionsheraufstufung erfolgt. Weitere Informationen finden Sie unter Georeplikation: Verwenden von Daten.

Regionswiederherstellung

Nachdem die ursprüngliche primäre Region wiederhergestellt wurde, folgen Sie demselben Regionsheraufstufungsprozess, wenn Sie den Namespace an seine ursprüngliche primäre Region zurückgeben möchten.

Wenn Sie während des Regionsausfalls eine erzwungene Heraufstufung durchgeführt haben, können Sie verlorene Daten nicht wiederherstellen, auch nachdem die primäre Region verfügbar ist.

Test auf Regionsfehler

Um die Georeplikation zu testen, stufen Sie die sekundäre Region vorübergehend in die primäre Region hoch, und überprüfen Sie, ob Ihre Clientanwendungen zwischen Regionen mit minimalen Unterbrechungen wechseln können.

Überwachen Sie die Dauer der Kampagne und stellen Sie sicher, dass Ihre Runbooks und Automatisierung einwandfrei funktionieren. Nach dem Testen können Sie zur ursprünglichen Konfiguration zurückkehren.

Verstehen Sie die potenziellen Ausfallzeiten und Datenverluste, die Während und nach dem Heraufstufungsprozess auftreten können. Testen Sie die Georeplikation in einer Nichtproduktionsumgebung, die die Konfiguration Ihres Produktionsnamespaces widerspiegelt.

Geometadaten-Katastrophenwiederherstellung

Die Standardebene und höher unterstützen die Geo-Notfallwiederherstellung für Metadaten. Dieses Feature verbessert die Wiederherstellung von Notfallszenarien, einschließlich des katastrophalen Verlusts einer Region. Geo-Notfallwiederherstellung repliziert nur die Konfiguration und Metadaten Ihres Namespaces. Ereignisdaten werden jedoch nicht repliziert. Um die Notfallwiederherstellung zu unterstützen, stellt dieses Feature sicher, dass ein Namespace in einer anderen Region vorkonfiguriert ist und sofort Ereignisse von Clients akzeptiert. Die georedundante Notfallwiederherstellung fungiert als unidirektionale Wiederherstellungslösung und unterstützt kein Failback auf die vorherige primäre Region.

Die Geo-Notfallwiederherstellung von Metadaten funktioniert am besten für Anwendungen, die nicht unbedingt jedes Ereignis verwalten müssen und während eines Notfallszenarios Datenverluste tolerieren können. Wenn Ihre Ereignisse beispielsweise Sensorwerte darstellen, die Sie später aggregieren, können Sie sich entscheiden, dass Sie einige Ereignisse aus einer fehlerhaften Region verlieren können, wenn Sie die Verarbeitung neuer Ereignisse in einer anderen Region schnell fortsetzen können.

Wenn Sie die Geo-Notfallwiederherstellung für Metadaten konfigurieren, erstellen Sie einen Alias , mit dem Clientanwendungen eine Verbindung herstellen. Der Alias ist ein FQDN, der standardmäßig den gesamten Datenverkehr an den primären Namespace weitergibt.

Wenn die primäre Region fehlschlägt oder eine andere Art von Notfall auftritt, können Sie jederzeit manuell ein einmaliges Failover von der primären Region zur sekundären Region initiieren. Das Failover erfolgt fast sofort. Während des Failoverprozesses wird der Alias für die georedundante Notfallwiederherstellung auf den sekundären Namespace verwiesen, und die Kopplung wird entfernt.

In diesem Abschnitt werden wichtige Aspekte der Geo-Notfallwiederherstellung zusammengefasst. Lesen Sie die vollständige Dokumentation, um genau zu verstehen, wie es funktioniert. Weitere Informationen finden Sie unter Event Hubs Geo-Disaster Recovery.

Regionsunterstützung

Sie können eine beliebige Azure-Region auswählen, die Event Hubs als primären oder sekundären Namespace unterstützt. Sie müssen keine gekoppelten Azure-Regionen verwenden, sodass Sie sekundäre Regionen basierend auf Ihren Latenz-, Compliance- oder Datenresidency-Anforderungen auswählen können.

Anforderungen

• Primäre Namespaceebene: Der primäre Namespace muss sich auf der Standardebene oder höher befinden, um die Geo-Notfallwiederherstellung für Metadaten zu verwenden.

• Sekundäre Namespaceebene: Metadaten-Geo-Notfallwiederherstellung unterstützt bestimmte Kombinationen von Ebenen für die primären und sekundären Namespaces. Weitere Informationen finden Sie unter "Unterstützte Namespacepaare".

Überlegungen

• Rollenzuweisung: Zuweisungen der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Microsoft Entra für Entitäten im primären Namespace werden nicht in den sekundären Namespace repliziert. Erstellen Sie Rollenzuweisungen manuell im sekundären Namespace, um den Zugriff auf sie zu schützen.

• Schemaregistrierung: Schemaregistrierungsmetadaten werden repliziert, wenn Sie die georedundante Notfallwiederherstellung von Metadaten verwenden, aber Schemas, die bei der Schemaregistrierung registriert sind, werden nicht repliziert.

• Anwendungsdesign: Für die Geo-Notfallwiederherstellung sind bestimmte Überlegungen erforderlich, wenn Sie Ihre Clientanwendungen entwerfen. Weitere Informationen finden Sie unter Überlegungen.

• Private Endpunkte: Wenn Sie private Endpunkte verwenden, um eine Verbindung mit Ihrem Namespace herzustellen, konfigurieren Sie das Netzwerk sowohl in Ihrer primären als auch in der sekundären Region. Weitere Informationen finden Sie unter Private Endpunkte.

Kosten

Wenn Sie die Geo-Notfallwiederherstellung für Metadaten aktivieren, bezahlen Sie sowohl für die primären als auch für sekundäre Namespaces.

Konfigurieren der Unterstützung für mehrere Regionen

• Erstellen Sie die Kopplung für die georedundante Notfallwiederherstellung für Metadaten. Informationen zum Konfigurieren der Notfallwiederherstellung zwischen primären und sekundären Namespaces finden Sie unter Einrichtung und Failover-Prozess.

• Deaktivieren Sie die Geo-Notfallwiederherstellung für Metadaten. Informationen zum Aufheben der Kopplung zwischen Namespaces finden Sie unter Setup und Failoverablauf.

Kapazitätsplanung und -verwaltung

Stellen Sie beim Planen von Bereitstellungen mit mehreren Regionen sicher, dass beide Regionen über ausreichende Kapazität verfügen, um die vollständige Auslastung zu bewältigen, wenn eine Region fehlschlägt. Die sekundäre Region bleibt während des normalen Betriebs passiv, muss aber unmittelbar nach dem Failover Datenverkehr verarbeiten. Planen Sie, wie die sekundäre Namespacekapazität skaliert wird, damit sie den Produktionsverkehr ohne Verzögerung aufnehmen kann. Wenn Sie während des Failoverprozesses zusätzliche Ausfallzeiten tolerieren können, können Sie die sekundäre Namespacekapazität während oder nach dem Failover skalieren. Um Ausfallzeiten zu reduzieren, stellen Sie die Kapazität im sekundären Namespace im Voraus bereit, damit weiterhin Produktionslast erhalten kann.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Event Hubs-Namespace für die Geo-Notfallwiederherstellung konfiguriert ist und die primäre Region betriebsbereit ist.

• Datenverkehrsrouting zwischen Regionen Clientanwendungen stellen eine Verbindung über den Alias für die georedundante Notfallwiederherstellung für den Namespace her. Ihr Datenverkehr wird dann an den primären Namespace in der primären Region weitergeleitet.

  Nur der primäre Namespace verarbeitet Ereignisse von Clients während normaler Vorgänge aktiv. Der sekundäre Namespace bleibt im Standbymodus passiv, und alle Anforderungen für den Zugriff auf Daten schlagen fehl.

• Datenreplikation zwischen Regionen: Nur Konfigurationsmetadaten werden zwischen den Namespaces repliziert. Die Replikation der Konfiguration erfolgt kontinuierlich und asynchron.

  Alle Ereignisdaten verbleiben nur im primären Namespace und werden nicht in den sekundären Namespace repliziert.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Event Hubs-Namespace für die Geo-Notfallwiederherstellung konfiguriert ist und es einen Ausfall in der primären Region gibt.

• Erkennung und Reaktion: Sie sind für die Überwachung des Zustands der Region und das manuelle Initiieren des Failovers verantwortlich. Microsoft führt kein Failover durch oder stuft eine sekundäre Region nicht automatisch höher, selbst wenn Ihre primäre Region ausgefallen ist.

  Weitere Informationen zum Initiieren des Failovers finden Sie unter Manuelles Failover.

  Ein Failover ist ein unidirektionales Verfahren, daher müssen Sie die Geo-Notfallwiederherstellungspaarung später neu erstellen. Weitere Informationen finden Sie unter Regionswiederherstellung.

• Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Sie können jedoch Azure Service Health verwenden, um die allgemeine Integrität des Diensts zu verstehen, einschließlich aller Regionsfehler, und Sie können Dienststatuswarnungen einrichten, um Sie über Probleme zu informieren.

  Verwenden Sie diese Informationen und andere Metriken, um zu entscheiden, wann auf die sekundäre Region umgeschaltet werden soll.

• Aktive Anforderungen: Aktive Anforderungen werden beim Starten des Failovers beendet. Clientanwendungen sollten Vorgänge wiederholen, nachdem das Failover abgeschlossen wurde.

• Erwarteter Datenverlust:

  • Metadaten: Konfiguration und Metadaten werden in der Regel in den sekundären Namespace repliziert. Die Metadatenreplikation erfolgt jedoch asynchron, sodass aktuelle Änderungen möglicherweise nicht repliziert werden, insbesondere komplexe Änderungen. Überprüfen Sie die Konfiguration Ihres sekundären Namespaces, bevor Clients darauf zugreifen.

  • Ereignisdaten: Ereignisdaten werden nicht zwischen Regionen repliziert. Wenn die primäre Region ausfällt, sind Ereignisse in Ihrem primären Namespace nicht mehr verfügbar.

    Die Ereignisse gehen nicht dauerhaft verloren, es sei denn, eine katastrophale Katastrophe verursacht totalen Verlust der primären Region. Wenn die Region wiederhergestellt wird, können Sie Ereignisse später aus dem primären Namespace abrufen.

• Erwartete Ausfallzeiten: Failover tritt in der Regel innerhalb von 5 bis 10 Minuten auf. Es kann länger dauern, bis Clients DNS-Einträge vollständig replizieren und aktualisieren.

• Datenverkehrsumleitung: Clients, die den Alias für die Geo-Notfallwiederherstellung verwenden, um eine Verbindung mit dem Namespace herzustellen, werden nach dem Failover automatisch an den sekundären Namespace umgeleitet. Diese Umleitung hängt jedoch von DNS-Servern ab, die die TTL der Namespace-DNS-Einträge und -Clients berücksichtigen, die diese aktualisierten DNS-Einträge erhalten.

Regionswiederherstellung

Nachdem die ursprüngliche primäre Region wiederhergestellt wurde, müssen Sie die Kopplung manuell erneut einrichten und optional ein Failback ausführen. Erstellen Sie eine neue Geo-Notfallwiederherstellungspaarung mit der wiederhergestellten Region als sekundär, und führen Sie dann ein weiteres Failover aus, wenn Sie zur ursprünglichen Region zurückkehren möchten. Dieser Vorgang kann potenzielle Datenverluste von Ereignissen beinhalten, die an das temporäre primäre System gesendet werden.

Wenn die Katastrophe den Verlust aller Zonen in der primären Region verursacht, können Ihre Daten möglicherweise nicht wiederhergestellt werden. In anderen Szenarien verbleiben Ihre Ereignisdaten im primären Namespace, bevor das Failover wiederhergestellt werden kann. Sie können historische Ereignisse aus dem alten primären Namespace abrufen, nachdem Sie den Zugriff wiederhergestellt haben. Sie sind dafür verantwortlich, Ihre Anwendungen so zu konfigurieren, dass diese Ereignisse empfangen und verarbeitet werden. Microsoft stellt sie nicht automatisch wieder in Ihrer sekundären Region her.

Test auf Regionsfehler

Um Ihre Reaktions- und Notfallwiederherstellungsprozesse zu testen, führen Sie während eines Wartungsfensters ein geplantes Failover aus. Initiieren Sie failover von Ihrem primären Namespace zu Ihrem sekundären Namespace, und stellen Sie sicher, dass Ihre Anwendungen Ereignisse aus der neuen primären Domäne verbinden und verarbeiten können.

Überwachen Sie die Failover-Dauer und vergewissern Sie sich, dass Ihre Runbooks und Automatisierungsprozesse ordnungsgemäß funktionieren. Nach dem Testen können Sie zur ursprünglichen Konfiguration zurückkehren.

Verstehen Sie die potenziellen Ausfallzeiten und Datenverluste, die während und nach dem Failoverprozess auftreten können. Testen Sie die Georeplikation in einer Nichtproduktionsumgebung, die die Konfiguration Ihres Produktionsnamespaces widerspiegelt.

Benutzerdefinierte Lösungen mit mehreren Regionen für Resilienz

Georeplikation und Metadaten-Geo-Notfallwiederherstellung bieten Resilienz für Regionenausfälle und andere Probleme, und sie unterstützen die meisten Workloads. Einige Event Hubs-Ebenen unterstützen diese Features nicht, oder Sie benötigen möglicherweise eine benutzerdefinierte Replikation oder müssen mehrere aktive Regionen gleichzeitig verwalten.

Verschiedene Entwurfsmuster können verschiedene Arten von Unterstützung für mehrere Regionen in Event Hubs erreichen. Viele der Muster erfordern die Bereitstellung mehrerer Namespaces und die Verwendung von Diensten wie Azure Functions, um Ereignisse zwischen ihnen zu replizieren. Weitere Informationen finden Sie unter "Verbund mit mehreren Standorten und mehreren Regionen".

Sichern und Wiederherstellen

Event Hubs ist nicht als langfristiger Speicherort für Ihre Daten konzipiert. In der Regel speichern Sie Daten in einem Event Hub für einen kurzen Zeitraum und verarbeiten sie dann entweder oder speichern sie in einem anderen Datenspeichersystem. Sie können den Datenaufbewahrungszeitraum für Ihren Event Hub basierend auf Ihren Anforderungen und der Von Ihrem Namespace verwendeten Ebene konfigurieren. Weitere Informationen finden Sie unter Ereignisaufbewahrung.

Wenn Sie eine Kopie Ihrer Ereignisse aufbewahren müssen, sollten Sie die Ereignishuberfassung verwenden, die Kopien von Ereignissen in einem Azure Blob Storage-Konto speichert.

Service-Level-Vereinbarung

Der Service level agreement (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit jedes Diensts und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter SLAs für Onlinedienste.

Die Verfügbarkeits-SLA Ihres Namespace ist höher, wenn er die Premium- oder Dedizierten Ebenen verwendet.

Verwandte Inhalte

• Event Hubs-Dokumentation
• Übersicht über die Zuverlässigkeit von Azure