Georedundante Notfallwiederherstellung in Azure Service Bus

Die Resilienz gegen katastrophale Ausfälle von Datenverarbeitungsressourcen ist für viele Unternehmen erforderlich und in einigen Fällen sogar Branchenvorschrift.

Mit Azure Service Bus wird das Risiko von schwerwiegenden Ausfällen einzelner Computer oder sogar der kompletten Racks in Clustern, die mehrere Fehlerdomänen in einem Rechenzentrum umfassen, bereits verteilt. Außerdem werden mit Azure Service Bus transparente Fehlererkennungs- und Failovermechanismen implementiert. Somit wird der Dienst weiterhin innerhalb der garantierten Servicelevel und in der Regel ohne spürbare Unterbrechungen im Falle solcher Fehler ausgeführt. Ein Premium-Namespace kann über zwei oder mehr Messagingeinheiten verfügen, und diese Messagingeinheiten werden auf mehrere Fehlerdomänen innerhalb eines Rechenzentrums verteilt und unterstützen ein umfassend aktives Service Bus-Clustermodell.

Bei einem Namespace der Premium-Dienstebene ist das Ausfallrisiko auf drei physisch getrennte Anlagen (Verfügbarkeitszonen) verteilt, und der Dienst verfügt über genügend Kapazitätsreserven, um den vollständigen, katastrophalen Ausfall eines Rechenzentrums sofort zu bewältigen. Das umfassend aktive Azure Service Bus-Clustermodell in einer Fehlerdomäne mit Unterstützung von Verfügbarkeitszonen ist jedem lokalen Nachrichtenbroker im Hinblick auf Resilienz gegen schwerwiegende Hardwareausfälle und sogar gegen den katastrophalen Verlust gesamter Rechenzentrumseinrichtungen überlegen. Es kann jedoch bedrohliche Situationen mit großflächigen physischen Zerstörungen geben, vor denen selbst diese Maßnahmen keinen ausreichenden Schutz bieten können.

Die georedundante Notfallwiederherstellung von Service Bus erleichtert die Wiederherstellung nach einem Notfall dieser Größenordnung und das endgültige Verwerfen einer Azure-Region, ohne die Anwendungskonfigurationen ändern zu müssen. Wenn Sie eine Azure-Region aufgeben, sind in der Regel mehrere Dienste betroffen. Dieses Feature soll vor allem dabei helfen, die Integrität der gesamten Anwendungskonfiguration zu bewahren. Das Feature ist für die Service Bus Premium-SKU global verfügbar.

Die georedundante Notfallwiederherstellung stellt sicher, dass die gesamte Konfiguration eines Namespaces (Warteschlangen, Themen, Abonnements, Filter) ständig von einem primären Namespace in einen sekundären Namespace repliziert wird, wenn diese gekoppelt sind. Außerdem können Sie mit ihr 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. Bei den meisten Service Bus-Namespaces würde der erforderliche Replikationsdatenverkehr den Anwendungsdatenverkehr weit überschreiten. Zudem würden bei Warteschlangen mit hohem Durchsatz die meisten Nachrichten immer in den sekundären Namespace repliziert, während sie bereits vom primären Replikat gelöscht werden. Dies hätte übermäßigen unwirtschaftlichen Datenverkehr zur Folge. Bei Replikationsrouten mit hoher Latenz, wie dies auf viele Kopplungen zutrifft, die Sie für die georedundante Notfallwiederherstellung wählen würden, kann zudem der Replikationsdatenverkehr aufgrund der latenzbedingten Drosselungseffekte möglicherweise nicht nachhaltig mit dem Anwendungsdatenverkehr Schritt halten.
• 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
• 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 Einheit zur primären wird, ist der letzte Zugriffsstatus, der nicht Teil der Metadaten ist, für die neue primäre Einheit nicht mehr verfügbar, und die Einheit 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. Befolgen Sie stattdessen die Replikationsanleitung.

Ausfälle und Notfälle

Es ist wichtig, dass Sie den Unterschied zwischen „Ausfällen“ und „Notfällen“ kennen.

Ein Ausfall ist die vorübergehende Nichtverfügbarkeit von Azure Service Bus und kann einige Komponenten des Diensts, z.B. einen Nachrichtenspeicher, oder selbst das gesamte Rechenzentrum betreffen. Nachdem das Problem behoben wurde, ist Service Bus aber wieder verfügbar. In der Regel führt ein Ausfall nicht zum Verlust von Nachrichten oder anderen Daten. Ein Beispiel für einen Ausfall ist ein Stromausfall im Rechenzentrum. Bei einigen Ausfällen handelt es sich nur um kurze Verbindungsunterbrechungen aufgrund von vorübergehenden Problemen bzw. Netzwerkproblemen.

Ein Notfall ist als dauerhafter oder längerer Ausfall eines Service Bus-Clusters, einer Azure-Region oder eines Datencenters definiert. Es kann sein, dass die Region oder das Rechenzentrum noch nicht wieder verfügbar ist oder für Stunden oder Tage ausfällt. Beispiele für Notfälle sind Feuer, Überflutung und Erdbeben. Ein Notfall, der dauerhaft wird, kann zum Verlust von Nachrichten, Ereignissen oder anderen Daten führen. In den meisten Fällen sollte es jedoch zu keinem Datenverlust kommen und die Nachrichten können wiederhergestellt werden, sobald das Rechenzentrum wieder in Betrieb ist.

Die Funktion der georedundanten Notfallwiederherstellung von Azure Service Bus ist eine Lösung zur Notfallwiederherstellung. Die Konzepte und der Workflow, die in diesem Artikel beschrieben werden, gelten für Notfallszenarien und nicht für vorübergehende Ausfälle. Eine ausführliche Erläuterung der Notfallwiederherstellung in Microsoft Azure finden Sie in diesem Artikel.

Allgemeine Konzepte und Begriffe

Bei der Funktion zur Notfallwiederherstellung wird die Notfallwiederherstellung von Metadaten implementiert, und sie basiert auf speziellen primären und sekundären Namespaces. Die Funktion zur georedundanten Notfallwiederherstellung ist nur für die Premium-SKU 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 georedundanten Kopplung 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 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 georedundante Notfallwiederherstellungsreplikationen vor dem Wechsel zum sekundären Namespace abgeschlossen werden. Im Gegensatz dazu 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 passiven 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 Ihrer eingerichteten geografischen Wiederherstellung, 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.

Verfügbarkeitszonen

Die Service Bus Premium-SKU unterstützt Verfügbarkeitszonen, die fehlerisolierte Standorte innerhalb einer Azure-Region bieten. Service Bus verwaltet drei Kopien des Nachrichtenspeichers (ein primäres und zwei sekundäre Replikate). Service Bus hält alle drei Kopien für Daten- und Verwaltungsvorgänge synchron. Wenn bei der primären Kopie ein Fehler auftritt, wird eine der sekundären Kopien ohne wahrnehmbare Ausfallzeit zum primären Replikat heraufgestuft. Wenn bei den Anwendungen vorübergehende Trennungen von Azure Service Bus auftreten, stellt die Wiederholungslogik im SDK automatisch erneut eine Verbindung mit Azure Service Bus her.

Wenn Sie Verfügbarkeitszonen verwenden, werden sowohl Metadaten als auch Daten (Nachrichten) zwischen Rechenzentren in der Verfügbarkeitszone repliziert.

Hinweis

Die Unterstützung für Verfügbarkeitszonen für Azure Service Bus Premium ist nur in Azure-Regionen verfügbar, in denen Verfügbarkeitszonen vorhanden sind.

Wenn Sie einen Namespace der Premium-Dienstebene über das Portal erstellen, wird die Unterstützung für Verfügbarkeitszonen (sofern in der ausgewählten Region verfügbar) automatisch für den Namespace aktiviert. Beim Erstellen eines Premium-Namespace über andere Mechanismen, z. B. ARM/Bicep-Vorlagen, CLI oder PowerShell, muss die zoneRedundant-Eigenschaft explizit auf true festgelegt werden, um Verfügbarkeitszonen (sofern in der ausgewählten Region verfügbar) zu aktivieren. Es fallen keine zusätzlichen Kosten für die Verwendung dieses Features an, und Sie können dieses Feature nach der Namespaceerstellung nicht deaktivieren oder aktivieren.

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 Informationen zur 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, mit dem Nachrichten an einen Alias gesendet werden an.

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