Georeplikation (Public Preview)

Es gibt zwei Features, die die georedundante Notfallwiederherstellung (Disaster Recovery, DR) in Azure Event Hubs bereitstellen.

• Geo-Notfallwiederherstellung (Metadaten-DR), die nur die Replikation von nur Metadaten bereitstellt.
• Georeplikation (öffentliche Vorschau), die Replikation von sowohl Metadaten als auch Daten bereitstellt.

Diese Features sollten nicht mit Verfügbarkeitszonen verwechselt werden. Beide Features für die geografische Wiederherstellung bieten Resilienz zwischen Azure-Regionen wie „USA, Osten“ und „USA, Westen“. Die Unterstützung von Verfügbarkeitszonen bietet Resilienz innerhalb einer bestimmten geografischen Region, z. B. „USA, Osten“. Weitere Informationen zu Verfügbarkeitszonen finden Sie unter Unterstützung von Event Hubs Verfügbarkeitszonen.

Metadaten-Notfallwiederherstellung im Vergleich zu Georeplikation von Metadaten und Daten

Das Feature für die Notfallwiederherstellung von Metadaten repliziert Konfigurationsinformationen für einen Namespace von einem primären Namespace in einem sekundären Namespace. Sie unterstützt ein einmaliges Failover für die sekundäre Region. Während des vom Kunden initiierten Failovers wird der Aliasname für den Namespace auf den sekundären Namespace umgeleitet, und dann wird die Kopplung unterbrochen. Es werden nur Konfigurationsinformationen repliziert. Weder andere Daten noch Berechtigungszuweisungen werden repliziert.

Das neuere Feature „Georeplikation” repliziert Konfigurationsinformationen und alle Daten aus einem primären Namespace in einem oder mehreren sekundären Namespaces. Wenn ein Failover ausgeführt wird, wird der ausgewählte sekundäre Namespace zum primären Namespace und der vorherige primäre Namespace zu einem sekundären Namespace. Benutzer können bei Bedarf ein Failover zurück auf die ursprüngliche primäre Region ausführen.

In den verbleibenden Abschnitten dieses Artikels geht es um das Feature „Georeplikation“. Ausführliche Informationen zum Feature für die Notfallwiederherstellung von Metadaten finden Sie unter Georedundante Notfallwiederherstellung für Metadaten in Event Hubs.

Georeplikation

Die Public Preview des Features „Georeplikation“ wird für Namespaces in Event Hubs Dedicated-Clustern mit Self-Service-Skalierung unterstützt. Sie können das Feature mit neuen oder vorhandenen Namespaces in Dedicated-Clustern mit Self-Service verwenden. Die folgenden Features werden nicht mit der Georeplikation unterstützt:

• Kundenseitig verwaltete Schlüssel (CMK)
• Verwaltete Identität für die Erfassung
• VNet-Features (Dienstendpunkte oder private Endpunkte)
• Unterstützung für große Nachrichten (jetzt als Public Preview verfügbar)
• Kafka-Transaktionen (jetzt als Public Preview verfügbar)

Im Folgenden sind einige der wichtigsten Aspekte der Public Preview des Features „Georeplikation“ aufgeführt:

• Primär/Sekundär-Replikationsmodell: Die Georeplikation basiert auf dem Primär/Sekundär-Replikationsmodell, bei dem jeweils nur ein primärer Namespace zum Verarbeiten des Datenverkehrs von Ereignisproduzenten und Ereignisconsumern vorhanden ist.
• 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.
• Stabiler Namespace-FQDN (Fully Qualified Domain Name, vollqualifizierter Domänenname): Der FQDN muss bei einer Höherstufung nicht geändert werden.
• Replikationskonsistenz: Es gibt zwei Einstellungen für die Replikationskonsistenz – synchron und asynchron.
• Benutzerseitig verwaltete Höherstufung von einem sekundären zum neuen primären Namespace.

Das Ändern eines sekundären Namespaces in einen neuen primären Namespace erfolgt auf zwei Arten:

• Geplant: Eine Höherstufung des sekundären zum primären Namespace, bei der Datenverkehr erst verarbeitet wird, wenn der neue primäre Namespace bezüglich der Daten auf dem Stand des vorherigen primären Namespaces ist.
• Erzwungen: Ein Failover, bei dem der sekundäre Namespace so schnell wie möglich zum primären Namespace wird. Das Feature „Georeplikation“ repliziert alle Daten und Metadaten aus der primären Region in den ausgewählten sekundären Regionen. Der Namespace-FQDN verweist immer auf die primäre Region.

Wenn Sie eine Höherstufung eines sekundären Namespaces initiieren, verweist der FQDN auf die Region, die als neue primäre Region ausgewählt ist. Der alte primäre Namespace wird dann zu einem sekundären Namespace. Sie können Ihren sekundären Namespace auch aus anderen Gründen als einem Failover zum neuen primären Namespace höher stufen, z. B. zum Durchführen von Anwendungsupgrades oder Failovertests usw. In solchen Situationen ist es üblich, nach diesen Aktivitäten wieder zurück zu wechseln.

Sekundäre Regionen werden nach eigenem Ermessen vom Kunden hinzugefügt oder entfernt. Derzeit gelten folgende Einschränkungen, die zu beachten sind:

• Schreibgeschützte Ansichten für sekundäre Regionen werden nicht unterstützt.
• Es gibt keine Funktion für die automatische Höherstufung/Durchführung eines Failovers. Alle Höherstufungen werden vom Kunden initiiert.
• Sekundäre Regionen müssen sich von der primären Region unterscheiden. Sie können keinen anderen Dedicated-Cluster in derselben Region auswählen.
• Für die Public Preview wird nur eine sekundäre Region unterstützt.

Replikationskonsistenz

Für die Replikationskonsistenz gibt es zwei Konfigurationen: synchron und asynchron. Es ist wichtig, die Unterschiede zwischen den beiden Konfigurationen zu kennen, da sie Auswirkungen auf Ihre Anwendungen und Ihre Datenkonsistenz haben.

Asynchrone Replikation

Wenn die asynchrone Replikation aktiviert ist, werden alle Nachrichten in der primären Region committet und dann an die sekundäre Region gesendet. Benutzer können eine akzeptable Verzögerungszeit konfigurieren, damit die sekundäre Region auf den neuesten Stand gebracht werden kann. Wenn die Verzögerung für eine aktive sekundäre Region größer ist als die vom Benutzer konfigurierte Verzögerung, drosselt die primäre Region eingehende Veröffentlichungsanforderungen.

Synchrone Replikation

Wenn die synchrone Replikation aktiviert ist, werden veröffentlichte Ereignisse in der sekundären Region repliziert, die die Nachricht bestätigen muss, bevor sie in der primären Region committet wird. Bei der synchronen Replikation veröffentlicht Ihre Anwendung Ereignisse mit der Geschwindigkeit, die zum Veröffentlichen, Replizieren, Bestätigen und Committen benötigt wird. Dies bedeutet auch, dass Ihre Anwendung an die Verfügbarkeit beider Regionen gebunden ist. Wenn die sekundäre Region ausfällt, können Nachrichten nicht bestätigt oder committet werden.

Vergleich der Replikationskonsistenz

Bei Verwendung der synchronen Replikation:

• Die Wartezeit ist aufgrund des verteilten Commits länger.
• Die Verfügbarkeit ist an die Verfügbarkeit von zwei Regionen gebunden. Wenn eine Region ausfällt, ist Ihr Namespace nicht verfügbar.
• Empfangene Daten befinden sich immer in mindestens zwei Regionen (in der Public Preview werden nur zwei Regionen unterstützt).

Die synchrone Replikation bietet die größte Gewissheit, dass Ihre Daten sicher sind. Wenn Sie die synchrone Replikation verwenden, werden committete Daten in allen Regionen committet, die für die Georeplikation konfiguriert sind. Wenn die synchrone Replikation aktiviert ist, kann die Anwendungsverfügbarkeit jedoch je nach Verfügbarkeit der beiden Regionen reduziert werden.

Das Aktivieren der asynchronen Replikation hat keine erheblichen Auswirkungen auf die Latenz, und der Ausfall einer sekundären Region hat keinen Einfluss auf die Dienstverfügbarkeit. Im Gegensatz zur synchronen Replikation bietet die asynchrone Replikation keine absolute Garantie, dass alle Regionen über die Daten verfügen, bevor diese committet werden. Sie können auch festlegen, wie lange Ihre sekundäre Region nicht synchron sein kann, bevor eingehender Datenverkehr gedrosselt wird. Diese Zeitspanne kann auf einen Wert zwischen 5 und 1.440 Minuten festlegt werden. Wenn Sie weit auseinander liegende Regionen verwenden möchten, ist die asynchrone Replikation wahrscheinlich die beste Option für Sie.

Die Konfiguration der Replikationskonsistenz kann nach dem Konfigurieren der Georeplikation geändert werden. Sie können von „synchron“ zu „asynchron“ wechseln oder umgekehrt. Wenn Sie die Konfiguration von „synchron“ in „asynchron“ ändern, verbessern sich die Latenz und die Anwendungsverfügbarkeit. Bei einem Wechsel von „asynchron“ zu „synchron“ wird Ihre sekundäre Region als „synchron“ konfiguriert, sobald die Verzögerung 0 (null) ist. Wenn bei der Ausführung aus irgendeinem Grund eine kontinuierliche Verzögerung vorliegt, müssen Sie Ihre Herausgeberkomponenten möglicherweise anhalten, damit der Verzögerungswert 0 erreicht wird und der Modus in „synchron“ geändert werden kann.

Die Gründe für die Aktivierung der synchronen Replikation hängen im Allgemeinen mit der Bedeutung der Daten, den spezifischen geschäftlichen Anforderungen oder Compliancegründen zusammen. Wenn Ihr primäres Ziel die Anwendungsverfügbarkeit und nicht die Datensicherheit ist, ist die asynchrone Konsistenz wahrscheinlich die bessere Wahl.

Auswahl der sekundären Region

Zum Aktivieren des Features „Georeplikation“ benötigen Sie eine primäre und eine sekundäre Region, in denen das Feature aktiviert wird. Außerdem benötigen Sie sowohl in der primären als auch der sekundären Region einen bereits vorhandenen Event Hubs-Cluster.

Das Feature „Georeplikation“ muss in der Lage sein, veröffentlichte Ereignisse von der primären in die sekundäre Region zu replizieren. Wenn sich die sekundäre Region auf einem anderen Kontinent befindet, hat dies erhebliche Auswirkungen auf die Verzögerung der Replikation von der primären zur sekundären Region. Wenn Sie die Georeplikation aus Gründen der Verfügbarkeit und Zuverlässigkeit verwenden, sollten Sie nach Möglichkeit sekundäre Regionen auswählen, die sich zumindest auf demselben Kontinent befinden. Unter Roundtrip-Latenzstatistiken von Azure-Netzwerken | Microsoft Learn erfahren Sie mehr über die durch die geografische Entfernung verursachte Latenz.

Verwaltung der Georeplikation

Mit dem Feature „Georeplikation“ können Sie eine sekundäre Region konfigurieren, in der Konfigurationsinformationen und Daten repliziert werden. Sie können Folgendes ausführen:

• Konfigurieren der Georeplikation: Sekundäre Regionen können für jeden vorhandenen Namespace in einem Dedicated-Cluster mit Self-Service konfiguriert werden, der sich in einer Region mit aktiviertem Featuresatz für die Georeplikation befindet. Die Konfiguration kann auch während der Namespaceerstellung auf denselben Dedicated-Clustern vorgenommen werden. Um eine sekundäre Region auszuwählen, benötigen Sie einen Dedicated-Cluster in dieser sekundären Region, und zudem muss für die sekundäre Region der Featuresatz für die Georeplikation aktiviert sein.
• Konfigurieren der Replikationskonsistenz: Die synchrone oder asynchrone Replikation wird beim Konfigurieren der Georeplikation festgelegt, kann aber später geändert werden. Bei der asynchronen Konsistenz können Sie die zulässige Verzögerung für eine sekundäre Region konfigurieren.
• Auslösen einer Höherstufung/eines Failovers: Alle Höherstufungen oder Failover werden vom Kunden initiiert. Während einer Höherstufung haben Sie die Möglichkeit, diese von Anfang an zu erzwingen oder sie nach ihrem Start auf „erzwungen“ festzulegen, falls Sie Ihre Meinung noch ändern.
• Entfernen einer sekundären Region: Sie können die Geo-Kopplung zwischen primären und sekundären Regionen jederzeit entfernen. Die Daten in der sekundären Region werden dann gelöscht.

Überwachen der Datenreplikation

Benutzer können den Fortschritt des Replikationsauftrags mithilfe der Metrik „Replikationsverzögerung“ in den Anwendungsmetrikprotokollen überwachen.

• Aktivieren Sie die Anwendungsmetrikprotokolle in Ihrem Event Hubs-Namespace wie unter Überwachung von Azure Event Hubs: Azure Event Hubs | Microsoft Learn beschrieben.

• Nachdem die Anwendungsmetrikprotokolle aktiviert wurden, müssen Sie einige Minuten lang über den Namespace Daten erzeugen und nutzen, damit die Protokolle angezeigt werden.

• Um Anwendungsmetrikprotokolle anzuzeigen, navigieren Sie zum Abschnitt Überwachung der Seite „Event Hubs“, und wählen Sie im linken Menü Protokolle aus. Mit der folgenden Abfrage können Sie die Replikationsverzögerung (in Sekunden) zwischen den primären und sekundären Namespaces ermitteln.

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

• Die Spalte count_d gibt die Replikationsverzögerung zwischen der primären und der sekundären Region in Sekunden an.

Veröffentlichen von Daten

Anwendungen, die Ereignisse veröffentlichen, können Daten über den stabilen Namespace-FQDN des jeweiligen georeplizierten Namespaces in georeplizierten Namespaces veröffentlichen. Der Ansatz für die Ereignisveröffentlichung ist identisch mit dem Vorgang ohne georedundante Notfallwiederherstellung, und es sind keine Änderungen an Clientanwendungen erforderlich.

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

• Während der Toleranzperiode für das Failover lehnt die vorhandene primäre Region alle neuen Ereignisse ab, die in dem 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, die Ereignisse nutzen, können Daten mithilfe des stabilen Namespace-FQDN eines georeplizierten Namespaces nutzen. Zwischen der Initiierung und dem Abschluss des Failovers werden keine Consumervorgänge unterstützt.

Prüfpunkt-/Offsetverwaltung

Anwendungen, die Ereignisse nutzen, können die Offsetverwaltung weiterhin wie bei einem einzelnen Namespace vornehmen.

Kafka

Offsets werden direkt in Event Hubs committet und regionsübergreifend repliziert. Consumer können daher an der Stelle mit der Nutzung beginnen, an der die Unterbrechung in der primären Region erfolgt ist.

Event Hubs SDK/AMQP

Clients, die das Event Hubs SDK verwenden, müssen ein Upgrade auf die Version vom April 2024 des SDK durchführen. Die aktuelle Version des Event Hubs SDK unterstützt Failover mit einem Update des Prüfpunkts. Der Prüfpunkt wird von Benutzern mit einem Prüfpunktspeicher wie Azure Blob Storage oder einer benutzerdefinierten Speicherlösung verwaltet. Wenn ein Failover stattfindet, muss der Prüfpunktspeicher über die sekundäre Region verfügbar sein, damit Clients Prüfpunktdaten abrufen und den Verlust von Nachrichten vermeiden können.

Preiskalkulation

Die Preise für Event Hubs Dedicated-Cluster sind unabhängig von der Georeplikation. Die Verwendung der Georeplikation mit Event Hubs Dedicated setzt voraus, dass Sie mindestens zwei Dedicated-Cluster in separaten Regionen haben. Die Dedicated-Cluster, die als sekundäre Instanzen für die Georeplikation dienen, können für andere Workloads verwendet werden. Für die Georeplikation wird eine Gebühr in Rechnung gestellt, die auf der veröffentlichten Bandbreite * Anzahl der sekundären Regionen basiert. Zu Beginn der Public Preview-Phase wird die Gebühr für die Georeplikation nicht in Rechnung gestellt.

Zugehöriger Inhalt

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