Georeplikation in Azure Event Hubs

Azure Event Hubs Georeplikation hält Kopien Ihrer Namensraum-Metadaten (Entitäten, Konfiguration, und Eigenschaften) sowie der Ereignisdaten in mehreren Azure-Regionen vor. Wenn Ihre primäre Region einen Ausfall erlebt, können Sie eine sekundäre Region bewerben, damit Ihre Streaminganwendungen mit minimalem Datenverlust ausgeführt werden.

In den folgenden Abschnitten wird erläutert, wie die Georeplikation funktioniert, synchrone und asynchrone Replikationsmodi verglichen und beschrieben, wie sekundäre Regionen verwaltet werden.

Die Georeplikation stellt sicher, dass Metadaten und Daten eines Namespace kontinuierlich aus einer primären Region in die sekundäre Region repliziert werden. Der Namespace kann als auf mehr als eine Region erweitert betrachtet werden, wobei eine Region die primäre und die andere die sekundäre ist.

Die sekundäre Region kann jederzeit zur primären Region heraufgestuft werden. Durch das Höherstufen einer sekundären Domäne zeigt der Namespace-FQDN (vollqualifizierter Domänenname) auf die ausgewählte sekundäre Region, und die vorherige primäre Region wird zu einer sekundären Region herabgestuft.

Szenarien

Die Georeplikation von Event Hubs kann in mehreren Szenarien verwendet werden.

Sicherstellen von Geschäftskontinuität und Notfallwiederherstellung

Georeplikation stellt die Notfallwiederherstellung und Geschäftskontinuität für alle Streamingdaten in Ihrem Namespace sicher. Durch replizierte Daten in allen Regionen können Organisationen vor Datenverlust schützen und sicherstellen, dass ihre Anwendungen auch bei einem regionalen Ausfall betriebsbereit bleiben. Dieses Feature ist für unternehmenskritische Anwendungen von entscheidender Bedeutung, die hohe Verfügbarkeit und minimale Ausfallzeiten erfordern.

Globale Datenverteilung

Georeplikation kann verwendet werden, um Daten global zu verteilen, sodass Anwendungen auf Daten aus der nächstgelegenen Region zugreifen können. Dadurch wird die Latenz reduziert und die Leistung für Workloads in verschiedenen Teilen der Welt verbessert.

Datenhoheit und Compliance

Organisationen, die in mehreren Ländern oder Regionen tätig sind, müssen häufig Datenhoheitsgesetze einhalten, die die Speicherung von Daten innerhalb bestimmter geografischer Grenzen erfordern. Die Georeplikation ermöglicht es diesen Organisationen, Daten in Regionen zu replizieren, die lokale Vorschriften einhalten, um sicherzustellen, dass sie gesetzliche Anforderungen erfüllen und gleichzeitig eine einheitliche Datenplattform beibehalten.

Migration und Upgrades

Georeplikation kann auch verwendet werden, um Datenmigration, Wartung und Systemupgrades zu vereinfachen. Organisationen können ihren Namespace proaktiv von einer primären zu einer sekundären Region migrieren, um Wartungs- und Upgrades in der primären Region zu ermöglichen.

Grundkonzepte

Das Georeplikationsfeature verwendet ein primäres sekundäres Replikationsmodell, um Metadaten und Daten zu replizieren. Zu einem bestimmten Zeitpunkt gibt es eine einzige Primäre Region, die sowohl Erzeugern als auch Verbrauchern dient. Die sekundäre Region fungiert als Hot-Standby-Region, sodass Sie nicht mit der sekundären Region interagieren können. Sie wird jedoch in derselben Ausführung wie die primäre Region ausgeführt, was bedeutet, dass sie nach der Hochstufung schnell eingreifen kann.

Einige der wichtigsten Aspekte des Georeplikationsfeatures sind:

• Primäres sekundäres Replikationsmodell – Georeplikation basiert auf einem primären sekundären Replikationsmodell, bei dem zu einem bestimmten Zeitpunkt nur ein primärer Namespace vorhanden ist, der Ereignisproduzenten und Ereigniskonsumenten dient.
• Event Hubs führt eine vollständig verwaltete Byte-zu-Byte-Replikation von Metadaten, Ereignisdaten und Consumeroffsets mit den konfigurierten Konsistenzebenen über sekundäre Namespaces hinweg aus.
• Einzelner Namespace-Hostname – Nachdem Sie einen georeplikationsfähigen Namespace erfolgreich konfiguriert haben, verwenden Sie den Namespace-Hostname in Ihrer Clientanwendung. Der Hostname verhält sich unabhängig von den konfigurierten primären und sekundären Regionen und verweist immer auf die primäre Region.
• Wenn Sie eine Heraufstufung initiieren, verweist der Hostname auf die Region, die als neue primäre Region ausgewählt ist. Die alte primäre Region wird zu einer sekundären Region.
• Sie können in den sekundären Regionen nicht lesen oder schreiben.
• Die kundenseitig verwaltete Höherstufung von der primären zur sekundären Region ermöglicht für den Fall von Ausfällen die vollständige Besitzübertragung und Sichtbarkeit. Es sind Metriken verfügbar, die dazu beitragen können, die Höherstufung kundenseitig zu automatisieren.
• Sie können sekundäre Regionen hinzufügen oder entfernen.
• Replikationskonsistenz : Zwei Replikationskonsistenzeinstellungen sind verfügbar: synchron und asynchron.

Staat	Diagramm
Vor dem Failover (Höherstufung der sekundären Region)
Nach Failover (Höherstufung der sekundären Region)

Replikationsmethoden

Es stehen zwei Konfigurationen zur Replikationskonsistenz zur Verfügung: synchron und asynchron. Verstehen Sie die Unterschiede zwischen diesen beiden Konfigurationen, da sie sich auf Ihre Anwendungen und ihre Datenkonsistenz auswirken.

Asynchrone Replikation

Wenn Sie eine asynchrone Replikation verwenden, verarbeitet der Primärserver alle Anforderungen und sendet anschließend eine Bestätigung an den Client. Die Replikation an die sekundären Regionen erfolgt asynchron. Sie können die maximal akzeptable Verzögerungszeit konfigurieren - den dienstseitigen Versatz zwischen der letzten Aktion auf der primären und der sekundären Region. Der Dienst repliziert kontinuierlich die Daten und Metadaten, um sicherzustellen, dass die Verzögerung so klein wie möglich bleibt. Wenn die Verzögerung für eine aktive sekundäre Instanz die vom Benutzer konfigurierte maximale Replikationsverzögerung übersteigt, beginnt die primäre Instanz mit der Drosselung eingehender Anforderungen.

Synchrone Replikation

Wenn Sie die synchrone Replikation verwenden, sendet das System alle Anforderungen an den sekundären Speicherort. Der sekundäre Speicherort führt den Commit durch und bestätigt den Vorgang, bevor der primäre Speicherort den Commit durchführt. Daher veröffentlicht Ihre Anwendung mit der Geschwindigkeit, die zum Veröffentlichen, Replizieren, Bestätigen und Commit erforderlich ist. Dieser Vorgang bedeutet, dass Ihre Anwendung von der Verfügbarkeit beider Regionen abhängt. Wenn die sekundäre Region verspätet oder nicht verfügbar ist, bestätigt die primäre Region keine Nachrichten und drosselt die eingehenden Anfragen.

Vergleich der Replikationskonsistenz

Bei Verwendung der synchronen Replikation:

• Die Latenz ist aufgrund der verteilten Commitvorgänge höher.
• Die Verfügbarkeit hängt von der Verfügbarkeit von zwei Regionen ab. Wenn eine Region ausfällt, ist Ihr Namespace nicht verfügbar.

Andererseits bietet die synchrone Replikation die größte Sicherheit, dass Ihre Daten geschützt sind. Bei der synchronen Replikation werden die Daten in allen Regionen, die Sie für die Geo-Replikation konfiguriert haben, gecommittet, was die beste Datensicherheit bietet.

Bei Verwendung der asynchronen Replikation:

• Die Latenz wird nur minimal beeinträchtigt.
• Der Verlust einer sekundären Region wirkt sich nicht sofort auf die Verfügbarkeit aus. Die Verfügbarkeit ist jedoch betroffen, sobald die konfigurierte maximale Replikationsverzögerung erreicht ist.

Daher ist nicht absolut garantiert, dass alle Regionen über die Daten verfügen, bevor der Commit erfolgt, wie es bei der synchronen Replikation der Fall ist, und es kann zu Datenverlust oder Duplizierung kommen. Da Sie jedoch nicht mehr sofort betroffen sind, wenn eine einzelne Region verzögert oder nicht verfügbar ist, verbessert sich die Anwendungsverfügbarkeit bei gleichzeitig niedrigerer Latenzzeit.

Sie können den Replikationsmodus nach der Konfiguration der Georeplikation ändern. Sie können von synchron zu asynchron oder von asynchron zu synchron wechseln. Wenn Sie von asynchron zu synchron wechseln, wird der sekundäre Bereich als synchron konfiguriert, nachdem die Verzögerung null erreicht hat. Wenn Sie aus irgendeinem Grund eine ständige Verzögerung haben, müssen Sie Ihre Publisher möglicherweise pausieren, damit die Verzögerung auf Null sinkt und Ihr Modus auf synchron umgestellt werden kann. Die Gründe für die Aktivierung der synchronen Replikation statt der asynchronen Replikation sind an die Bedeutung der Daten, spezifischen Geschäftsanforderungen oder Compliance-Gründe gebunden, anstatt auf die Verfügbarkeit Ihrer Anwendung.

Auswahl der sekundären Region

Um die Georeplikationsfunktion zu aktivieren, verwenden Sie primäre und sekundäre Regionen, in denen das Feature aktiviert ist. Die Georeplikationsfunktion hängt davon ab, dass veröffentlichte Nachrichten von der primären in die sekundären Regionen repliziert werden können. Wenn sich die sekundäre Region auf einem anderen Kontinent befindet, hat diese Auswahl eine erhebliche Auswirkung auf die Replikationsverzögerung von der primären bis zur sekundären Region. Wenn Sie die Georeplikation aus Verfügbarkeitsgründen verwenden, wählen Sie nach Möglichkeit sekundäre Regionen auf demselben Kontinent aus. Zum besseren Verständnis der durch geografische Entfernung verursachten Latenz, sehen Sie sich die Azure Rundreise-Latenzstatistiken an.

Verwaltung der Georeplikation

Mit dem Georeplikationsfeature können Sie eine sekundäre Region konfigurieren, in die Metadaten und Daten repliziert werden sollen. So können Sie die folgenden Verwaltungsaufgaben ausführen:

• Konfigurieren der Georeplikation – Sie können sekundäre Regionen für jeden neuen oder vorhandenen Namespace in einer Region konfigurieren, indem Sie die Georeplikationsfunktion aktivieren.
• Konfigurieren Sie die Replikationskonsistenz– Legen Sie beim Konfigurieren der Georeplikation synchrone und asynchrone Replikation fest. Sie können diese Einstellung auch später wechseln.
• Auslösen von Höherstufung/Failover – Alle Höherstufungen werden vom Kunden initiiert.
• Entfernen Sie eine sekundäre – Wenn Sie eine sekundäre Region entfernen möchten, können Sie dies tun. Die Daten im sekundären Bereich werden gelöscht.

Kriterien zum Auslösen von Werbung

Hier sind einige Fälle, in denen eine Hochstufung einer Sekundärinstanz zur Primärinstanz ausgelöst werden kann.

• Regionaler Ausfall: Wenn sich ein regionaler Ausfall auf die primäre Region auswirkt, fördern Sie die sekundäre Region, um die Geschäftskontinuität sicherzustellen und Ausfallzeiten zu minimieren.

• Wartungsaktivitäten: Während geplanter Wartungsaktivitäten in der primären Region kann die Förderung der sekundären Region dazu beitragen, eine hohe Verfügbarkeit für unternehmenskritische Anwendungen aufrechtzuerhalten.

• Notfallwiederherstellung: Im Falle einer Katastrophe, die sich auf die primäre Region auswirkt, stellt die Förderung der sekundären Region sicher, dass Ihre Daten weiterhin zugänglich bleiben und Ihre Anwendungen weiterhin funktionieren.

• Leistungsprobleme: Wenn in der primären Region Leistungsprobleme auftreten, die sich auf die Verfügbarkeit oder Zuverlässigkeit Ihrer Event Hubs auswirken, kann die Förderung der sekundären Region dazu beitragen, diese Probleme zu beheben.

Testen Sie gelegentlich Failovermechanismen, um sicherzustellen, dass der Geschäftskontinuitätsplan effektiv ist, und Ihre Anwendungen können bei Bedarf nahtlos zur sekundären Region wechseln.

Überwachen der Datenreplikation

Sie können den Fortschritt des Replikationsauftrags überwachen, indem Sie die Metrik der Replikationsverzögerung in den Anwendungsmetrikenprotokollen überprüfen.

• Aktivieren Sie Anwendungsmetrikenprotokolle in Ihrem Event Hubs-Namespace, indem Sie Monitoring Azure Event Hubs - Azure Event Hubs | Microsoft Learn folgen.

• Nachdem Sie Anwendungsmetrikenprotokolle aktiviert haben, erstellen und nutzen Sie Daten aus dem Namespace einige Minuten, bevor Sie beginnen, die Protokolle anzuzeigen.

• Um Anwendungsmetrikenprotokolle anzuzeigen, wechseln Sie zum Abschnitt "Überwachung " der Seite "Event Hubs", und wählen Sie " Protokolle " im linken Menü aus. Verwenden Sie die folgende Abfrage, um die Replikationsverzögerung (in Sekunden) zwischen den primären und sekundären Namespaces zu finden.

  AzureDiagnostics
    | where TimeGenerated > ago(1h)
    | where Category == "ApplicationMetricsLogs"
    | where ActivityName_s == "ReplicationLag
  

• In der Spalte count_d wird die Replikationsverzögerung in Sekunden zwischen der primären und sekundären Region angezeigt.

Veröffentlichen von Daten

Veröffentlichende Anwendungen können Daten über den Namespace-Hostnamen des für die Geo-Replikation aktivierten Namespaces an georeplizierte Namespaces senden. Der Veröffentlichungsansatz entspricht dem Nicht-Geo-Replikationsfall. Sie müssen keine Änderungen an Datenebenen-SDKs oder Clientanwendungen vornehmen.

Die Ereignisveröffentlichung ist unter den folgenden Umständen möglicherweise nicht verfügbar:

• Nach dem Anfordern einer Heraufgestufung einer sekundären Region lehnt die vorhandene primäre Region alle neuen Ereignisse ab, die im Event Hub veröffentlicht werden.
• Wenn die Replikationsverzögerung zwischen primären und sekundären Regionen die maximale Dauer der Replikationsverzögerung erreicht, wird die Eingangsworkload des Herausgebers möglicherweise gedrosselt.

Herausgeberanwendungen können nicht direkt auf Namespaces in den sekundären Regionen zugreifen.

Verwenden von Daten

Anwendungen können Daten konsumieren, indem sie den Namespace-Hostnamen eines Namespaces verwenden, bei dem die Geo-Replikationsfunktion aktiviert ist. Verbrauchervorgänge werden ab dem Zeitpunkt, an dem die Werbeaktion beginnt, nicht unterstützt, bis die Werbeaktion abgeschlossen ist.

Checkpointing und Offset-Verwaltung

Anwendungen, die Ereignisse verarbeiten, können die Offset-Verwaltung auf die gleiche Weise beibehalten wie bei einem nicht Geo-replizierten Namespace. Georeplikationsfähige Namespaces benötigen keine besondere Berücksichtigung für die Offsetverwaltung.

Kafka

Consumer committen Offsets direkt an Event Hubs, und das System repliziert die Offsets über Regionen hinweg. Aus diesem Grund können die Verbraucher dort weitermachen, wo sie in der primären Region aufgehört haben.

Hier ist eine Liste der unterstützten Apache Kafka-Clients:

Für andere Bibliotheken hängt die Unterstützung von der API-Version ab:

Event Hubs SDK und AMQP

Für AMQP verwalten Benutzer den Prüfpunkt mithilfe eines Prüfpunktspeichers wie Azure Blob-Speicher oder einer benutzerdefinierten Speicherlösung. Wenn ein Failover vorhanden ist, muss der sekundäre Bereich über den Prüfpunktspeicher verfügen, damit Clients Prüfpunktdaten abrufen und Den Verlust von Nachrichten vermeiden können.

Die neueste Version des Event Hubs SDK enthält Änderungen an der Prüfpunktdarstellung zur Unterstützung von Failovern. Verwenden Sie die neuesten Versionen der SDKs, aber auch frühere Versionen der folgenden SDKs werden unterstützt.

Überlegungen

Beachten Sie dabei die folgenden Aspekte:

• Berücksichtigen Sie in Ihrer Promotionplanung den Zeitfaktor. Falls beispielsweise die Verbindung länger als 15 bis 20 Minuten ausfällt, könnten Sie sich entscheiden, die Werbeaktion einzuleiten.
• Sie sollten mindestens einmal die Förderung einer komplexen verteilten Infrastruktur üben.

Preiskalkulation

Die Preise variieren je nach ausgewählter Stufe, haben jedoch im Allgemeinen zwei Parameter:

• Die Computegebühr für den Cluster oder Namespace.
• Die Bandbreitengebühr für die Daten, die zwischen den primären und sekundären Regionen repliziert werden.

Dedizierte Cluster

Wenn Sie georeplikation mit dedizierten Event Hubs-Clustern verwenden, benötigen Sie mindestens zwei dedizierte Cluster in separaten Regionen. Sie können diese Cluster verwenden, um andere Namespaces als den geo-replizierten zu hosten. Sie zahlen für diese dedizierten Cluster separat basierend auf der Anzahl der einzelnen Kapazitätseinheiten (CUs).

Wenn Sie die Georeplikation aktivieren, ist die einzige Zusätzliche Gebühr die Bandbreitengebühr für die daten, die von primär auf sekundär repliziert wurden. Diese Gebühr hängt vom Standort der primären Region ab.

Premium-Namespaces

Bei Premium-Namespaces erhalten Sie beim Aktivieren der Georeplikation die gleiche Anzahl von Verarbeitungseinheiten (PUs) in der sekundären Region. Sie zahlen für die Anzahl der verwendeten PUs und die Bandbreite für die zwischen der primären und sekundären Region übertragenen Daten.

Wenn Sie zum Beispiel die Geo-Replikation auf einem Premium Namespace aktivieren, den Sie mit 4 PUs bereitgestellt haben, zahlen Sie für

• 4 PUs in der primären Region,
• 4 PUs in der sekundären Region,
• Georeplikationsgebühr pro GB replizierter Daten.

Sie zahlen Bandbreitengebühren basierend auf den zwischen den primären und sekundären Regionen übertragenen Daten.

Preiseinheiten

Die Preisangaben für die Bandbreitengebühr bei der Geo-Replikationsdatenübertragung werden mit den folgenden Details angezeigt:

Private Endpunkte

Dieser Abschnitt enthält zusätzliche Überlegungen bei der Verwendung der Georeplikation mit Namespaces, die private Endpunkte verwenden. Allgemeine Informationen zur Verwendung privater Endpunkte mit Event Hubs finden Sie unter Integrate Azure Event Hubs mit Azure Private Link.

Wenn Sie die Georeplikation für einen Event Hubs-Namespace implementieren, der private Endpunkte verwendet, erstellen Sie private Endpunkte für die primären und sekundären Regionen. Konfigurieren Sie diese Endpunkte für virtuelle Netzwerke, die sowohl primäre als auch sekundäre Instanzen Ihrer Anwendung hosten. Wenn Sie beispielsweise über zwei virtuelle Netzwerke verfügen, VNET-1 und VNET-2, müssen Sie zwei private Endpunkte im Event Hubs-Namespace erstellen, wobei Subnetze von VNET-1 bzw. VNET-2 verwendet werden. Richten Sie die virtuellen Netzwerke mit regionsübergreifendem Peering ein, damit Clients mit einem der privaten Endpunkte kommunizieren können. Verwalten Sie schließlich das DNS , damit alle Clients die DNS-Informationen abrufen, die den Namespaceendpunkt (namespacename.servicebus.windows.net) auf die IP-Adresse des privaten Endpunkts in der aktuellen primären Region verweist.

Dieser Ansatz bietet den Vorteil, dass Failover unabhängig auf der Anwendungsschicht oder im Event Hubs-Namespace auftreten kann:

• Anwendungsverbindungsausfall: In diesem Szenario wechselt die Anwendung von VNET-1 zu VNET-2. Da private Endpunkte sowohl für VNET-1 als auch für VNET-2 für primäre und sekundäre Namespaces konfiguriert sind, funktioniert die Anwendung weiterhin nahtlos.
• Nur Event Hubs-Namespace-Failover: Wenn das Failover nur auf der Event Hubs-Namespaceebene auftritt, bleibt die Anwendung betriebsbereit, da private Endpunkte in beiden virtuellen Netzwerken konfiguriert sind.

Anhand dieser Richtlinien können Sie stabile und zuverlässige Failovermechanismen für Ihre Event Hubs-Namespaces sicherstellen, die private Endpunkte verwenden.

Zugehöriger Inhalt

Informationen zur Verwendung des Features „Georeplikation“ finden Sie unter Verwenden der Georeplikation.