Georedundante Notfallwiederherstellung von Azure Service Bus

Das Feature für georedundante Notfallwiederherstellung in Service Bus ist eine der Optionen zum Isolieren von Azure Service Bus-Anwendungen gegen Ausfälle und Notfälle und zielt in erster Linie darauf ab, die Integrität der gesamten Anwendungskonfiguration zu bewahren.

Hinweis

Dieses Feature ist für die Premium-Ebene von Azure Service Bus verfügbar.

Das Feature für die georedundante Notfallwiederherstellung stellt sicher, dass die gesamte Konfiguration eines Namespace (Entitäten, Konfiguration, Eigenschaften) ständig von einem primären Namespace in einem sekundären Namespace repliziert wird, mit dem er gekoppelt ist. Außerdem können Sie jederzeit ein einmaliges Failover vom primären zum sekundären Namespace auslösen. Beim Failover wird der ausgewählte Aliasname für den Namespace dem sekundären Namespace zugeordnet, dann wird die Kopplung aufgehoben. Das Failover erfolgt nach der Initiierung fast unmittelbar.

Wichtige zu berücksichtigende Punkte

• Das Feature ermöglicht die sofortige Fortsetzung von Vorgängen mit der gleichen Konfiguration, jedoch werden die Nachrichten in Warteschlangen, Themenabonnements oder in Warteschlangen für unzustellbare Nachrichten nicht repliziert. Damit die Warteschlangensemantik beibehalten wird, müssen bei einer solchen Replikation nicht nur die Nachrichtendaten, sondern auch jede Zustandsänderung im Broker repliziert werden. Dies wird über das Feature für die Georeplikation (Public Preview) ermöglicht.
• Zuweisungen der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Microsoft Entra für Service Bus-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.
• Die folgenden Konfigurationen werden nicht repliziert.
  • Konfigurationen für das virtuelle Netzwerk
  • Private Endpunktverbindungen
  • Aktivierung des Zugriffs auf alle Netzwerke
  • Aktivierung des Zugriffs auf vertrauenswürdige Dienste
  • Zugriff aus öffentlichen Netzwerken
  • Standardnetzwerkaktion
  • Identitäten und Verschlüsselungseinstellungen (Verschlüsselung mit kundenseitig verwalteten Schlüsseln oder BYOK-Verschlüsselung (Bring Your Own Key))
  • Aktivieren der automatischen Skalierung
  • Deaktivieren der lokalen Authentifizierung
  • Azure Event Grid-Abonnements
• Das Koppeln eines partitionierten Namespace mit einem nicht partitionierten Namespace wird nicht unterstützt.
• Wenn AutoDeleteOnIdle für eine Entität aktiviert ist, ist die Entität möglicherweise nicht im sekundären Namespace vorhanden, wenn der Failover auftritt. Wenn die sekundäre Entität zur primären wird, ist der letzte Zugriffsstatus, der nicht Teil der Metadaten ist, für die neue primäre Entität nicht mehr verfügbar, und die Entität wird möglicherweise im Rahmen der AutoDeleteOnIdle-Bereinigung gelöscht.

Tipp

Verwenden Sie zum Replizieren der Inhalte von Warteschlangen und Themenabonnements sowie für den Betrieb der entsprechenden Namespaces in Aktiv/Aktiv-Konfigurationen zur Bewältigung von Ausfällen und Notfällen nicht den Featuresatz der georedundanten Notfallwiederherstellung. Verwenden Sie stattdessen das Feature für die Georeplikation, oder befolgen Sie die Anleitung zur Replikation.

Allgemeine Konzepte und Begriffe

Bei der Funktion zur georedundanten Notfallwiederherstellung wird die Notfallwiederherstellung von Metadaten implementiert, und sie basiert auf speziellen primären und sekundären Notfallwiederherstellungsnamespaces. Die Funktion zur georedundanten Notfallwiederherstellung ist nur für die Premium-Ebene verfügbar. Sie müssen keine Änderungen an den Verbindungszeichenfolgen vornehmen, da die Verbindung über einen Alias hergestellt wird.

In diesem Artikel werden die folgenden Begriffe verwendet:

• Alias: Der Name für die Konfiguration einer von Ihnen eingerichteten Notfallwiederherstellung. Der Alias stellt einen einzelnen, stabilen, vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) als Verbindungszeichenfolge bereit. Anwendungen verwenden diese Alias-Verbindungszeichenfolge, um eine Verbindung mit einem Namespace herzustellen. Mit einem Alias wird sichergestellt, dass die Verbindungszeichenfolge unverändert bleibt, wenn das Failover ausgelöst wird.

• Primärer/sekundärer Namespace: Die Namespaces, die dem Alias entsprechen. Der primäre Namespace ist „aktiv“ und empfängt Nachrichten. (Dies kann ein bereits vorhandener oder ein neuer Namespace sein.) Der sekundäre Namespace ist passiv und empfängt keine Nachrichten. Die Metadaten zwischen beiden Namespaces werden synchronisiert, sodass beide nahtlos und ohne Änderung des Anwendungscodes oder der Verbindungszeichenfolge Nachrichten entgegennehmen können. Um sicherzustellen, dass nur der aktive Namespace Nachrichten empfängt, müssen Sie den Alias verwenden.

• Metadaten: Entitäten, z.B. Warteschlangen, Themen und Abonnements und die dazugehörigen Eigenschaften des Diensts, die dem Namespace zugeordnet sind. Nur Entitäten und ihre Einstellungen werden automatisch repliziert. Nachrichten werden nicht repliziert.

• Failover: Der Vorgang zum Aktivieren des sekundären Namespace.

Einrichten

Der folgende Abschnitt enthält eine Übersicht über die Einrichtung der Kopplung zwischen den Namespaces.

Zuerst erstellen bzw. verwenden Sie einen vorhandenen primären Namespace und einen neuen sekundären Namespace und koppeln diese anschließend. Über diese Kopplung erhalten Sie einen Alias, mit dem Sie eine Verbindung herstellen können. Da Sie einen Alias verwenden, müssen Sie keine Verbindungszeichenfolgen ändern. Nur neue Namespaces können der Failoverkopplung hinzugefügt werden.

1. Erstellen Sie den primären Namespace der Premium-Dienstebene.

2. Erstellen Sie den sekundären Namespace der Premium-Dienstebene in einer anderen Region. Dieser Schritt ist optional. Sie können den sekundären Namespace während der Erstellung der Kopplung im nächsten Schritt erstellen.

3. Navigieren Sie im Azure-Portal zu Ihrem primären Namespace.

4. Wählen Sie im linken Menü Georedundante Wiederherstellung und auf der Symbolleiste Kopplung initiieren aus.

   

5. Führen Sie auf der Seite Kopplung initiieren die folgenden Schritte aus:

   1. Wählen Sie einen vorhandenen sekundären Namespace aus, oder erstellen Sie einen in einer anderen Region. In diesem Beispiel wird ein vorhandener Namespace als sekundärer Namespace verwendet.

   2. Geben Sie als Alias einen Alias für die Kopplung der georedundanten Notfallwiederherstellung ein.

   3. Wählen Sie anschließend Erstellen.

      

6. Die Seite Service Bus-Alias für georedundante Notfallwiederherstellung sollte wie in der folgenden Abbildung dargestellt angezeigt werden. Sie können auch von der Seite des primären Namespace zur Seite Alias für georedundante Notfallwiederherstellung navigieren, indem Sie im linken Menü die Option Georedundante Wiederherstellung auswählen.

   

7. Wählen Sie auf der Seite Alias für georedundante Notfallwiederherstellung im linken Menü die Option Richtlinien für gemeinsamen Zugriff aus, um auf die primäre Verbindungszeichenfolge für den Alias zuzugreifen. Verwenden Sie diese Verbindungszeichenfolge anstelle der direkten Verbindungszeichenfolge zum primären bzw. sekundären Namespace. Der Alias verweist zunächst auf den primären Namespace.

8. Wechseln Sie zur Seite Übersicht. Sie können die folgenden Aktionen ausführen:

   1. Aufheben der Kopplung zwischen dem primären und sekundären Namespace. Wählen Sie auf der Symbolleiste die Option Kopplung aufheben aus.
   2. Manuelles Failover zum sekundären Namespace.

      1. Wählen Sie auf der Symbolleiste die Option Failover aus.

      2. Vergewissern Sie sich, dass Sie ein Failover zum sekundären Namespace durchführen möchten, indem Sie Ihren Alias eingeben.

      3. Aktivieren Sie die Option Sicheres Failover, um ein sicheres Failover auf den sekundären Namespace durchzuführen.

         Hinweis

         • Durch sicheres Failover wird gewährleistet, dass ausstehende Replikationen der georedundanten Notfallwiederherstellung vor dem Wechsel zum sekundären Namespace abgeschlossen werden. Alternativ wartet erzwungenes oder manuelles Failover nicht auf den Abschluss ausstehender Replikationen, bevor auf den sekundären Namespace umgeschaltet wird.
         • Derzeit schlägt das sichere Failover fehl, wenn sich der primäre und der sekundäre Namespace nicht im gleichen Azure-Abonnement befinden.

      4. Wählen Sie dann Failover aus.

         

         Wichtig

         Ein Failover aktiviert den sekundären Namespace und entfernt den primären Namespace aus der Kopplung für die georedundante Notfallwiederherstellung. Erstellen Sie einen weiteren Namespace, um eine neue Kopplung für die georedundante Notfallwiederherstellung zu erhalten.

9. Abschließend sollten Sie einige Überwachungsfunktionen hinzufügen, um zu ermitteln, ob ein Failover erforderlich ist. In den meisten Fällen ist der Dienst Teil eines großen Ökosystems, sodass automatische Failover selten möglich sind, da Failover häufig synchron mit dem restlichen Subsystem oder der Infrastruktur durchgeführt werden müssen.

Service Bus Standard auf Premium

Wenn Sie Ihren Azure Service Bus Standard-Namespace zu Azure Service Bus Premium migriert haben, müssen Sie den bereits vorhandenen Alias (d. h. Ihre Service Bus-Standard-Namespaceverbindungszeichenfolge) verwenden, um die Notfallwiederherstellungskonfiguration über die PS/CLI oder REST-API zu erstellen.

Dies liegt daran, dass während der Migration Ihre Azure Service Bus Standard-Namespaceverbindungszeichenfolge bzw. der DNS-Name selbst zu einem Alias für Ihren Azure Service Bus Premium-Namespace geworden ist.

Ihre Clientanwendungen müssen mit diesem Alias (d. h. der Azure Service Bus Standard-Namespaceverbindungszeichenfolge) die Verbindung mit dem Premium-Namespace herstellen, in dem die Kopplung für die Notfallwiederherstellung eingerichtet wurde.

Wenn Sie das Azure-Portal verwenden, um die Konfiguration für die Notfallwiederherstellung einzurichten, wird das Portal diesen Nachteil vor Ihnen verbergen.

Failoverablauf

Ein Failover wird manuell vom Kunden (explizit durch einen Befehl oder über Geschäftslogik des Clients, mit der der Befehl ausgelöst wird) und nie von Azure ausgelöst. Dadurch erhält der Kunde vollständigen Besitz und vollständige Transparenz für die Auflösung von Ausfällen im Backbone von Azure.

Nach dem Auslösen des Failovers:

1. Die Verbindungszeichenfolge des Alias wird so aktualisiert, dass sie auf den sekundären Premium-Namespace verweist.

2. Clients (Sender und Empfänger) stellen automatisch eine Verbindung mit dem sekundären Namespace her.

3. Die vorhandene Kopplung zwischen dem primären und sekundären Premium-Namespace wird getrennt.

Nach dem Initiieren des Failovers:

1. Bei einem weiteren Ausfall muss ein erneutes Failover möglich sein. Richten Sie daher einen weiteren sekundären Namespace ein, und aktualisieren Sie die Kopplung.

2. Übertragen Sie Nachrichten mithilfe von Pull aus dem ehemals primären Namespace, nachdem er wieder verfügbar ist. Verwenden Sie diesen Namespace danach für das reguläre Messaging außerhalb Ihres Setup für die georedundante Notfallwiederherstellung, oder löschen Sie den alten primären Namespace.

Hinweis

Es wird nur die Semantik für „Fail Forward“ unterstützt. In diesem Szenario führen Sie das Failover und anschließend die Reparatur mit einem neuen Namespace durch. Ein Failback wird nicht unterstützt, z. B. in einem SQL-Cluster.

Sie können das Failover entweder mit Überwachungssystemen oder mit benutzerdefinierten Überwachungslösungen automatisieren. Für diese Art der Automatisierung sind aber zusätzliche Planungs- und Arbeitsschritte erforderlich, was den Rahmen dieses Artikels sprengen würde.

Verwaltung

Falls Sie einen Fehler gemacht haben (z. B. eine Kopplung der falschen Regionen während des anfänglichen Setups), können Sie die Kopplung der beiden Namespaces jederzeit aufheben. Wenn Sie die gekoppelten Namespaces als reguläre Namespaces verwenden möchten, löschen Sie den Alias.

Verwenden des vorhandenen Namespace als Alias

Bei einem Szenario, für das Sie die Verbindungen von Producern und Consumern nicht ändern können, können Sie Ihren Namespacenamen als Aliasnamen verwenden. Den Beispielcode finden Sie auf GitHub.

Beispiele

In den Beispielen auf GitHub wird veranschaulicht, wie Sie ein Failover einrichten und initiieren. In diesen Beispielen werden die folgenden Konzepte veranschaulicht:

• Ein .NET-Beispiel und Einstellungen, die in Microsoft Entra ID erforderlich sind, um unter Verwendung von Azure Resource Manager und Service Bus georedundante Notfallwiederherstellung einzurichten und zu aktivieren.
• Schritte, die zum Ausführen des Beispielcodes erforderlich sind
• Verwenden eines vorhandenen Namespace als Alias
• Schritte zur alternativen Aktivierung der georedundanten Notfallwiederherstellung über PowerShell oder die Befehlszeilenschnittstelle
• Senden und Empfangen aus dem aktuellen primären oder sekundären Namespace unter Verwendung des Alias

Überlegungen

Beachten Sie für diesen Release Folgendes:

• Berücksichtigen Sie bei der Failoverplanung auch den Zeitfaktor. Falls beispielsweise länger als 15 bis 20 Minuten keine Konnektivität vorhanden ist, empfiehlt es sich unter Umständen, das Failover zu initiieren.
• Die Tatsache, dass keine Daten repliziert werden, bedeutet, dass derzeit keine aktiven Sitzungen repliziert werden. Außerdem kann es sein, dass die Duplikaterkennung und geplante Nachrichten nicht funktionieren. Neue Sitzungen, neue geplante Nachrichten und neue Duplikate funktionieren.
• Die Durchführung eines Failovers für eine komplexe verteilte Infrastruktur sollte mindestens einmal durchgespielt werden.
• Das Synchronisieren von Entitäten kann einige Zeit dauern (etwa eine Minute pro 50 bis 100 Entitäten). Abonnements und Regeln zählen ebenfalls zu den Entitäten.

Private Endpunkte

In diesem Abschnitt finden Sie weitere Überlegungen zur Verwendung der georedundanten Notfallwiederherstellung mit Namespaces, die private Endpunkte verwenden. Allgemeine Informationen zur Verwendung von privaten Endpunkten mit Service Bus finden Sie unter Integrieren von Azure Service Bus in den Azure Private Link-Dienst.

Neue Kopplungen

Wenn Sie versuchen, eine Kopplung zwischen einem primären Namespace mit einem privaten Endpunkt und einem sekundären Namespace ohne einen privaten Endpunkt zu erstellen, wird die Kopplung nicht durchgeführt. Die Kopplung erfolgt nur, wenn sowohl der primäre als auch der sekundäre Namespace einen privaten Endpunkt aufweist. Wir empfehlen Ihnen, für den primären und den sekundären Namespace sowie für virtuelle Netzwerke, in denen private Endpunkte erstellt werden, die gleichen Konfigurationen zu verwenden.

Hinweis

Wenn Sie versuchen, den primären Namespace mit einem privaten Endpunkt und dem sekundären Namespace zu koppeln, prüft der Überprüfungsprozess lediglich, ob ein privater Endpunkt im sekundären Namespace vorhanden ist. Es wird nicht überprüft, ob der Endpunkt funktioniert oder nach dem Failover funktioniert. Sie selbst müssen sicherstellen, dass der sekundäre Namespace mit dem privaten Endpunkt nach dem Failover erwartungsgemäß funktioniert.

Gehen Sie wie folgt vor, um die Konfigurationen des privaten Endpunkts zu testen: Senden Sie von einem Ort außerhalb des virtuellen Netzwerks eine Get queues-Anforderung an den sekundären Namespace, und überprüfen Sie, ob Sie eine Fehlermeldung vom Dienst erhalten.

Vorhandene Kopplungen

Wenn bereits eine Kopplung zwischen primärem und sekundärem Namespace besteht, schlägt die Erstellung eines privaten Endpunkts im primären Namespace fehl. Erstellen Sie zunächst einen privaten Endpunkt für den sekundären Namespace und dann einen privaten Endpunkt für den primären Endpunkt, um das Problem zu beheben.

Hinweis

Für den sekundären Namespace ist nur Lesezugriff möglich, Konfigurationen des privaten Endpunkts können dagegen aktualisiert werden.

Empfohlene Konfiguration

Beim Erstellen einer Konfiguration für die Notfallwiederherstellung Ihrer Anwendung und Service Bus müssen Sie private Endpunkte für primäre und sekundäre Service Bus-Namespaces für die virtuellen Netzwerke erstellen, die primäre und sekundäre Instanzen der Anwendung enthalten.

Nehmen wir an, Sie haben zwei virtuelle Netzwerke: VNET-1, VNET-2 und diese primären und sekundären Namespaces: ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. Sie müssen dann die folgenden Schritte ausführen:

• Erstellen Sie auf ServiceBus-Namespace1-Primary zwei private Endpunkte, die Subnetze von VNET-1 und VNET-2 verwenden.
• Erstellen Sie auf ServiceBus-Namespace2-Secondary zwei private Endpunkte, die die gleichen Subnetze von VNET-1 und VNET-2 verwenden.

Der Vorteil dieses Ansatzes besteht darin, dass ein Failover auf Anwendungsebene unabhängig vom Service Bus-Namespace erfolgen kann. Betrachten Sie die folgenden Szenarien:

Auf Anwendung beschränktes Failover: In diesem Fall ist die Anwendung nicht in VNET-1 vorhanden, wird aber in VNET-2 verschoben. Da beide privaten Endpunkte sowohl in VNET-1 als auch in VNET-2 für primäre und sekundäre Namespaces konfiguriert sind, wird die Anwendung ausgeführt.

Auf Azure Service Bus-Namespaces beschränktes Failover: Da auch in diesem Fall beide privaten Endpunkte in beiden virtuellen Netzwerken für primäre und sekundäre Namespaces konfiguriert sind, wird die Anwendung ausgeführt.

Hinweis

Eine Anleitung zur georedundanten Notfallwiederherstellung eines virtuellen Netzwerks finden Sie unter Virtuelles Netzwerk: Geschäftskontinuität.

Rollenbasierte Zugriffssteuerung

Zuweisungen der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) von Microsoft Entra für Service Bus-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.

Nächste Schritte

• Hier finden Sie eine REST-API-Referenz für die georedundante Notfallwiederherstellung.
• Führen Sie das Beispiel auf GitHub zur georedundanten Notfallwiederherstellung aus.
• Sehen Sie sich das Beispiel zur georedundanten Notfallwiederherstellung an, mit dem Nachrichten an einen Alias gesendet werden.

Weitere Informationen zum Service Bus-Messaging finden Sie in folgenden Artikeln:

• Service Bus-Warteschlangen, -Themen und -Abonnements
• Erste Schritte mit Service Bus-Warteschlangen
• Verwenden von Service Bus-Themen und -Abonnements
• REST-API