Zuverlässigkeit in Azure Service Bus

Azure Service Bus ist ein vollständig verwalteter Nachrichtenbrokerdienst für Unternehmen, der zuverlässige asynchrone Messagingfunktionen zum Decoupieren von Anwendungen und Diensten bietet. Service Bus unterstützt Warteschlangen für die Point-to-Point-Kommunikation und Themen mit Abonnements für Messagingmusters für Veröffentlichungen und Abonnements. Der Dienst bietet integrierte Zuverlässigkeitsfeatures, einschließlich dauerhafte Nachrichten, Garantien für mindestens eine einmalige Zustellung und Warteschlangen für unzustellbare Nachrichten zur Verarbeitung fehlgeschlagener Nachrichten.

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 Sie Service Bus für eine Vielzahl potenzieller Ausfälle und Probleme widerstandsfähig machen, einschließlich vorübergehender Fehler, Ausfall der Verfügbarkeitszone und Regionsausfälle. Außerdem werden einige wichtige Informationen zum Service Bus Service Level Agreement (SLA) hervorgehoben.

Bereitstellungsempfehlungen für die Produktion

Das Azure Well-Architected Framework bietet Empfehlungen für Zuverlässigkeit, Leistung, Sicherheit, Kosten und Vorgänge. Informationen dazu, wie sich diese Bereiche gegenseitig beeinflussen und zu einer zuverlässigen App Service-Lösung beitragen, finden Sie unter Architektur bewährte Methoden für Azure Service Bus im Azure Well-Architected Framework.

Übersicht über die Zuverlässigkeitsarchitektur

In diesem Abschnitt werden einige der wichtigen Aspekte der Funktionsweise des Diensts beschrieben, die aus Zuverlässigkeitsperspektive am relevantesten sind. Im Abschnitt wird die logische Architektur vorgestellt, die einige der Ressourcen und Features enthält, die Sie bereitstellen und verwenden. Außerdem wird die physische Architektur erläutert, die Details zur Funktionsweise des Diensts unter den Deckeln bereitstellt.

Logische Architektur

Ein Namespace dient als Verwaltungscontainer für Service Bus und kann für die Verwendung der Stufe "Basic", "Standard" oder "Premium" konfiguriert werden. Sie konfigurieren den Dienst auf Namespaceebene, indem Sie Kapazität zuordnen, Netzwerksicherheit konfigurieren und Geo-Replication und Geo-Disaster Wiederherstellung aktivieren.

Innerhalb eines Namespaces stellen Sie Warteschlangen und Themen bereit, bei denen es sich um Messagingentitäten mit unterschiedlicher Semantik handelt. Weitere Informationen finden Sie unter Service Bus-Warteschlangen, Themen und Abonnements.

Sie können optional Partitionen in Ihrem Namespace konfigurieren, die Warteschlangen und Themen über mehrere Nachrichtenbroker und Messagingspeicher verteilt. Ein Namespace kann mehrere Partitionen verwenden, um parallele Verarbeitung und horizontale Skalierung durchzuführen. Service Bus garantiert nur die Sortierung in 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. Für die Premium-Ebene aktivieren Sie die Partitionierung im Namespace. Für Namespaces der Ebene "Basic" und "Standard" konfigurieren Sie Partitionen für die Entität und optional, wenn Sie Nachrichten senden.

Sie können Service Bus und seine asynchronen Entwurfsansätze verwenden, um die Verfügbarkeit Ihrer Anwendungen zu erhöhen. Weitere Informationen finden Sie unter asynchrone Messagingmuster und hohe Verfügbarkeit.

Physische Architektur

Service Bus stellt die zugrunde liegenden Compute- und Speicherressourcen bereit. Für jeden Namespace verarbeiten mehrere Nachrichtenbroker die Nachrichten, und mehrere Nachrichtenspeicher speichern die Nachrichten. Es gibt drei Kopien des Nachrichtenspeichers: eine primäre und zwei sekundäre. 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.

Für Namespaces, die die Basis- oder Standardebene verwenden, bietet der Service Bus Redundanz über eine gemeinsam genutzte Infrastruktur für mehrere Mandanten, die Nachrichten automatisch in Verfügbarkeitszonen repliziert, falls verfügbar. Der Dienst verwaltet mehrere Nachrichtenspeicher und hält alle Kopien für Daten- und Verwaltungsvorgänge synchronisiert.

Für Premium-Namespaces stellt Service Bus dedizierte Messagingeinheiten bereit, die jeweils dedizierte CPU- und Arbeitsspeicherressourcen enthalten. Premium-Stufen-Namespaces können sich automatisch je nach Arbeitslastanforderungen skalieren. Weitere Informationen finden Sie unter "Automatisches Aktualisieren von Messagingeinheiten eines Azure Service Bus-Namespaces".

Die ServiceBus-Infrastruktur umfasst mehrere physische Maschinen und Racks, die über Fehlerdomänen verteilt sind, wodurch das Risiko katastrophaler Fehler verringert wird, die Ihren Namespace beeinträchtigen. In Regionen mit Verfügbarkeitszonen erstreckt sich die Infrastruktur über separate physische Rechenzentren. Der Dienst implementiert transparente Fehlererkennungs- und Failovermechanismen, sodass er weiterhin innerhalb der gesicherten Dienstebenen und in der Regel ohne erkennbare Unterbrechungen funktioniert, wenn solche Fehler auftreten.

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 zur Behandlung vorübergehender Fehler.

Das Azure Service Bus SDK enthält eine automatisierte Wiederholungslogik mit exponentiellem Backoff für Vorgänge, die aufgrund vorübergehender Bedingungen wie Netzwerk-Zeitüberschreitungen oder vorübergehender Dienstunverfügbarkeit fehlschlagen. Bei vorübergehenden Verbindungsabbrüchen von Service Bus versucht das SDK automatisch, die Verbindung mithilfe der konfigurierten Wiederholungsrichtlinie erneut herzustellen.

Um die vorübergehende Fehlerbehandlung in Ihren Anwendungen zu optimieren, verwenden Sie das neueste Service Bus SDK, das die aktuellsten Wiederholungslogik- und Verbindungsverwaltungsfunktionen enthält. Weitere Informationen finden Sie in der Azure Service Bus-Clientbibliothek für .NET.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

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

Service Bus unterstützt zonenredundante Bereitstellungen in allen Dienstebenen. Wenn Sie einen Service Bus-Namespace in einer unterstützten Region erstellen, wird Zonenredundanz automatisch ohne zusätzliche Kosten aktiviert. Das zonenredundante Bereitstellungsmodell gilt für alle ServiceBus-Features, einschließlich Partitionierung und Sitzungen.

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

Anforderungen

• Regionsunterstützung: Zonenredundante Servicebus-Namespaces können in Azure-Regionen mit Unterstützung von Verfügbarkeitszonen bereitgestellt werden. Service Bus ermöglicht die Unterstützung der Verfügbarkeitszone automatisch, wenn Sie einen Namespace in einer unterstützten Region erstellen, ohne dass zusätzliche Konfiguration erforderlich ist.

• Reihen: Alle ServiceBus-Stufen (Basic, Standard und Premium) unterstützen Verfügbarkeitszonen ohne zusätzliche Anforderungen.

Überlegungen

Service Bus-Namespaces enthalten eine zoneRedundant Eigenschaft. Zuvor war diese Eigenschaft erforderlich, um Verfügbarkeitszonen zu aktivieren, dieses Verhalten wurde jedoch geändert, und die zoneRedundant Eigenschaft ist veraltet. Diese Eigenschaft könnte weiterhin als false angezeigt werden, selbst wenn Zonenredundanz aktiviert ist. Alle Namespaces in Regionen mit Verfügbarkeitszonen sind zonenredundant.

Kosten

Die Zonenredundanz in Service Bus fügt keine zusätzlichen Kosten hinzu.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

Service Bus-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

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Service Bus-Namespaces für Zonenredundanz konfiguriert sind und alle Verfügbarkeitszonen betriebsbereit sind.

• Datenverkehrsrouting zwischen Zonen. Service Bus verwendet ein aktiv aktives Modell, bei dem Nachrichten über mehrere Verfügbarkeitszonen verteilt werden. Für Clientverbindungen wird automatisch über Zonen hinweg ein Lastenausgleich vorgenommen und der Dienst leitet Vorgänge unabhängig von der Zone an die verfügbare Messaginginfrastruktur weiter.

• Datenreplikation zwischen Zonen. Service Bus verwendet synchrone Replikation über Verfügbarkeitszonen hinweg, einschließlich metadaten- und Nachrichtendaten. Mehrere Kopien des Nachrichtenspeichers müssen Schreibvorgänge bestätigen, bevor sie als abgeschlossen betrachtet werden, wodurch die Datenkonsistenz in allen Zonen während normaler Vorgänge sichergestellt wird.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Service Bus-Namespaces für Zonenredundanz konfiguriert sind und ein Ausfall der Verfügbarkeitszone vorhanden ist.

• Erkennung und Reaktion: Microsoft erkennt Zonenfehler automatisch und initiiert Failover in fehlerfreie Zonen. Für Failover auf Zonenebene ist keine Kundenaktion erforderlich.

• 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: Während eines Zonenfehlers kann Service Bus aktive Anforderungen ablegen. 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 Service Bus Nachrichten vor der Bestätigung synchron repliziert.

• Erwartete Ausfallzeiten: Ein Zonenausfall kann einige Sekunden ausfallzeiten verursachen. Wenn Ihre Clients vorübergehende Fehler angemessen behandeln, indem sie nach kurzer Zeit erneut versuchen, vermeiden sie in der Regel erhebliche Auswirkungen.

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

  Das Service Bus SDK verarbeitet in der Regel die Verbindungsverwaltung und die Wiederholungslogik transparent.

Zonenwiederherstellung

Wenn eine Verfügbarkeitszone wiederhergestellt wird, integriert Service Bus die Zone automatisch in die aktive Diensttopologie. Die wiederhergestellte Zone beginnt, neue Verbindungen zu akzeptieren und Nachrichten zusammen mit den anderen Zonen zu verarbeiten. 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

Service Bus verwaltet das Routing von Datenverkehr, Failover und Zonenwiederherstellung bei Zonenfehlern, sodass Sie keine Fehlerprozesse für Verfügbarkeitszonen überprüfen oder weitere Eingaben bereitstellen müssen.

Widerstandsfähigkeit bei regionalen Ausfällen

Service Bus bietet zwei Arten von Unterstützung für mehrere Regionen, von denen beide Premium-Tier-Namespaces erfordern:

• Georeplikation bietet eine aktive passive Replikation von Metadaten- und Nachrichtendaten zwischen einer primären Region und einer sekundären Region. Verwenden Sie Geo-Replication für die meisten Anwendungen, die ausfallsicher bleiben müssen und eine geringe Toleranz für Nachrichtendatenverlust aufweisen.

• Bei der georedundanten Notfallwiederherstellung von Metadaten werden Konfigurationen und Metadaten zwischen einer primären und sekundären Region aktiv-passiv repliziert. Es werden jedoch keine Nachrichtendaten repliziert. Erwägen Sie die Verwendung von Geo-Disaster Recovery für Anwendungen, die ihre eigene Datenreplikation verarbeiten oder die keine Datenreplikation benötigen.

Sowohl Geo-Replication als auch Metadaten-Geo-Disaster-Recovery erfordern, dass Sie manuell ein Failover einleiten oder eine sekundäre Region promoten, damit diese zur neuen primären Region wird. Microsoft führt nicht automatisch ein Failover oder eine Höherstufung durch, auch wenn Ihre primäre Region ausgefallen ist.

Namespaces in den Ebenen "Basic" und "Standard" enthalten keine nativen Multi-Region-Features, sie können jedoch Replikationsmuster auf Anwendungsebene mithilfe mehrerer Namespaces in allen Regionen implementieren. Weitere Informationen finden Sie weiter unten im Abschnitt " Benutzerdefinierte Lösungen mit mehreren Regionen für Resilienz ".

Geo-Replication

Die Premium-Stufe unterstützt die Georeplikation. Dieses Feature repliziert sowohl Metadaten (z. B. Entitäten, Konfiguration und Eigenschaften) als auch Daten (z. B. Nachrichten in Ihren Warteschlangen und Themen sowie Nachrichteneigenschaften und -zustand) für den Namespace. Sie konfigurieren den Replikationsansatz für die Konfiguration und Daten Ihres Namespaces. Mit diesem Feature wird sichergestellt, dass Ihre Nachrichten in einer anderen Region verfügbar bleiben und sie bei Bedarf zur sekundären Region wechseln können.

Verwenden Sie Geo-Replication für Szenarien, die Resilienz für Regionenausfälle erfordern und eine geringe Toleranz für Den Verlust von Nachrichten aufweisen.

Der Namespace erstreckt sich im Wesentlichen über Regionen. Eine Region dient als Primärregion, und die anderen Regionen dienen als sekundär. Ihr Azure-Abonnement zeigt einen einzelnen Namespace an.

Sie können die sekundäre Region jederzeit zu einer primären Region heraufstufen . Wenn Sie die sekundäre Region heraufstufen, gibt Service Bus den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Namespace auf die ausgewählte sekundäre Region zurück und macht 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 Service Bus Geo-Replication.

Anforderungen

• Regionsunterstützung: Sie können eine beliebige Azure-Region auswählen, die Service Bus als primäre Region oder sekundäre Region 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.

• Rang: Um die Georeplikation zu aktivieren, muss Ihr Namespace die Premium-Ebene verwenden.

• Georedundante Notfallwiederherstellung von Metadaten: Sie können einen Namespace nur so konfigurieren, dass er entweder die Georeplikation oder die georedundante Notfallwiederherstellung verwendet.

Überlegungen

• Featurebeschränkungen: Wenn Sie georeplikation aktivieren, gibt es einige Einschränkungen. Weitere Informationen finden Sie unter Service Bus Geo-Replication.

• 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 in der Dokumentation zu Azure Event Hubs unter "Private Endpunkte ".

Kosten

Informationen zur Funktionsweise der Preise für Georeplikation finden Sie unter "Preise".

Konfigurieren der Unterstützung für mehrere Regionen

• Aktivieren Sie Geo-Replication für einen neuen Namespace. Informationen dazu, wie Sie die Georeplikation in einem Namespace während der Erstellung aktivieren, finden Sie unter Wechseln des Replikationsmodus.

• Migrieren von der georedundanten Notfallwiederherstellung von Metadaten zur Georeplikation.Sie können von der georedundanten Notfallwiederherstellung von Metadaten zur Georeplikation wechseln..

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

• Georeplikation deaktivieren. Informationen zum Deaktivieren von Geo-Replication in einer sekundären Region finden Sie unter Löschen des sekundären Bereichs.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein ServiceBus-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 Nachrichten von Clients aktiv während des normalen Betriebs. Die sekundäre Region empfängt replizierte Nachrichten, bleibt aber andernfalls im Standbymodus passiv.

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

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

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

    • Asynchron: Nachrichten werden in die primäre Region geschrieben und dann wird der Schreibvorgang abgeschlossen. Kurz später repliziert sie die Nachrichten 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 der 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.

    Einige Metadatentypen werden synchron repliziert, auch wenn Sie den asynchronen Replikationsmodus auswählen.

    Weitere Informationen finden Sie unter Replikationsmodi.

Verhalten während eines Regionsausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Service Bus-Namespace für Geo-Replication 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. Empfohlene Kriterien, die bei der Entscheidung, ob ein Failover durchgeführt werden soll, berücksichtigt werden sollten, finden Sie unter Empfohlene Szenarien zum Auslösen der Hochstufung.

  Weitere Informationen darüber, wie Sie eine sekundäre Region zur neuen primären Region hochstufen, finden Sie unter "Promotionsablauf".

  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.

• Aktive Anforderungen: Das Verhalten hängt davon ab, ob der Ausfall in der primären oder der 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 Ihr Namespace seinen Datenverkehr und akzeptiert keine neuen Nachrichten mehr, sobald die Replikationsverzögerung das von Ihnen konfigurierte Maximum erreicht.

    Um den Namespace im primären Bereich weiterhin zu verwenden, entfernen Sie den sekundären Namespace aus Ihrer Geo-Replication Konfiguration.

• 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 Förderung, asynchrone Replikation: Möglicherweise tritt ein Datenverlust bei Nachrichten auf, die kürzlich gesendet wurden und nicht in die sekundäre Region repliziert wurden, sowie bei Zustandsänderungen, die noch nicht repliziert wurden. 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 Höherstufung: Bei einer erzwungenen Höherstufung wartet Service Bus nicht, bis die Datenreplikation beendet ist, und initiiert die Heraufstufung 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.

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 Geo-Replication in einer Nichtproduktionsumgebung, die die Konfiguration Ihres Produktionsnamespaces widerspiegelt.

Metadaten Geo-Disaster-Recovery

Die Premium-Ebene unterstützt Metadaten bei der geografischen Katastrophenwiederherstellung. Dieses Feature verbessert die Wiederherstellung von Notfallszenarien, einschließlich des katastrophalen Verlusts einer Region. Geo-Disaster-Wiederherstellung repliziert nur die Konfiguration und die Metadaten Ihres Namespaces. Nachrichtendaten 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 Nachrichten von Clients akzeptiert. Geo-Disaster Recovery dient als unidirektionale Wiederherstellungslösung und unterstützt kein Failback in die vorherige primäre Region.

Metadaten Geo-Disaster Wiederherstellung eignet sich am besten für Anwendungen, die nicht unbedingt jede Nachricht verwalten müssen und während eines Notfallszenarios Datenverluste tolerieren können. Metadaten Geo-Disaster-Recovery ist möglicherweise auch für Anwendungen geeignet, die Daten selbst replizieren oder die überhaupt keine Datenreplikation benötigen. Wenn Ihre Nachrichten beispielsweise große Bilder darstellen, die Sie später in Miniaturansichten konvertieren, können Sie sich entscheiden, dass Sie einige Nachrichten aus einer fehlgeschlagenen Region verlieren können, wenn Sie in einer anderen Region schnell mit der Verarbeitung neuer Nachrichten fortfahren können, und Sie können die Nachrichten später rekonstruieren, um den Rückstand aufzuholen.

Wenn Sie die Geo-Disaster-Recovery für Metadaten konfigurieren, erstellen Sie einen Alias, mit dem sich Clientanwendungen verbinden. 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. Sie können ein sicheres Failover ausführen, das wartet, bis die Replikationen abgeschlossen sind, bevor Sie zur Sekundärseite wechseln, obwohl diese Option möglicherweise während eines Regionsausfalls nicht verfügbar ist. Sobald ein Failover gestartet wird, wird es fast sofort abgeschlossen. 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-Disaster Wiederherstellung zusammengefasst. Lesen Sie die vollständige Dokumentation, um genau zu verstehen, wie es funktioniert. Weitere Informationen finden Sie unter Service Bus Geo-Notfallwiederherstellung.

Anforderungen

• Regionsunterstützung: Sie können eine beliebige Azure-Region auswählen, die Service Bus 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.

• Tier: Um Metadaten Geo-Disaster-Wiederherstellung zu aktivieren, müssen beide Namespaces den Premium-Tier verwenden.

• Partitionierung: Es ist nicht möglich, einen partitionierten Namespace mit einem nicht partitionierten Namespace zu verbinden.

• Georedundante Notfallwiederherstellung von Metadaten: Sie können einen Namespace nur so konfigurieren, dass er entweder die Georeplikation oder die georedundante Notfallwiederherstellung verwendet.

Überlegungen

• Featurebeschränkungen: Wenn Sie Geo-Disaster Wiederherstellung aktivieren, gibt es einige Einschränkungen. Weitere Informationen finden Sie unter Wichtige Punkte zu beachten und Ü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.

• Anwendungsdesign: Geo-Desaster-Wiederherstellung erfordert spezifische Überlegungen bei der Gestaltung Ihrer Client-Anwendungen. 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.

• Namespaces, die von Standard zu Premium migriert wurden: Wenn sich Ihr Namespace zuvor auf der Standardebene befand und Sie ihn auf die Premium-Ebene migriert haben, müssen Sie den Alias anders behandeln. Weitere Informationen finden Sie unter Service Bus Standard to Premium.

Kosten

Wenn Sie die Metadaten-Geo-Disaster-Recovery aktivieren, bezahlen Sie sowohl für den primären als auch für den sekundären Namespace.

Konfigurieren der Unterstützung für mehrere Regionen

• Erstellen Sie eine Metadaten-Geo-Disaster-Recovery-Paarung. Informationen zum Konfigurieren der Notfallwiederherstellung zwischen primären und sekundären Namespaces finden Sie unter Einrichtung und Failover-Prozess.

• Geo-Disaster Recovery für Metadaten deaktivieren. 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 ServiceBus-Namespace für Geo-Disaster Wiederherstellung konfiguriert ist und die primäre Region betriebsbereit ist.

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

  Nur der primäre Namespace verarbeitet Nachrichten 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 Nachrichtendaten verbleiben nur im primären Namespace und werden nicht in den sekundären Namespace repliziert.

Verhalten während eines Regionsausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Service Bus-Namespace für Geo-Disaster Wiederherstellung konfiguriert ist und ein Ausfall in der primären Region vorhanden ist.

• 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 Failover-Ablauf.

  Wenn Sie ein Failover initiieren, wählen Sie aus, ob ein sicheres Failover oder ein Standard (erzwungenes oder manuelles Failover) ausgeführt werden soll. Ein sicheres Failover wartet, bis die Replikation in die sekundäre Region abgeschlossen ist, bevor es startet. Dieser Ansatz reduziert den Verlust von Metadaten, führt aber zu Ausfallzeiten. Für ein sicheres Failover müssen sich die Namespaces im selben Azure-Abonnement befinden.

  Während eines Ausfalls in der primären Region müssen Sie in der Regel ein erzwungenes Failover ausführen. Wenn die primäre Region verfügbar ist und Sie einen Failover aus einem anderen Grund auslösen, können Sie einen geplanten Failover auswählen.

  Ein Failover ist ein unidirektionales Verfahren, daher müssen Sie die georedundante Notfallwiederherstellung 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.

• 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.

  • Nachrichtendaten: Nachrichtendaten werden nicht zwischen Regionen repliziert. Wenn die primäre Region ausfällt, werden Nachrichten in Ihrem primären Namespace unverfügbar.

    Nachrichten gehen nicht dauerhaft verloren, es sei denn, eine katastrophale Katastrophe verursacht den völligen Verlust der primären Region. Wenn die Region wiederhergestellt wird, können Sie Nachrichten 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 die georedundante Notfallwiederherstellung verwenden, um eine Verbindung zum 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-Disaster Wiederherstellungspaarung mit dem wiederhergestellten Bereich als sekundär, und führen Sie dann ein weiteres Failover aus, wenn Sie zur ursprünglichen Region zurückkehren möchten. Dieser Vorgang umfasst den potenziellen Datenverlust von Nachrichten, die an den temporären primären Server 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 Nachrichtendaten im primären Namespace, bevor das Failover wiederhergestellt werden kann. Sie können historische Nachrichten 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 Nachrichten 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 ein Failover von Ihrem primären Namespace zu Ihrem sekundären Namespace, und stellen Sie sicher, dass Ihre Anwendungen Nachrichten von der neuen Primären 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 georedundante Notfallwiederherstellung von Metadaten in einer Nicht-Produktionsumgebung, die die Konfiguration Ihres Produktionsnamespace wiederspiegelt.

Benutzerdefinierte Lösungen mit mehreren Regionen für Resilienz

Die Georeplikation und die georedundante Notfallwiederherstellung von Metadaten bieten Ausfallsicherheit bei Regionalausfällen und anderen Problemen und eignen sich für die meisten Workloads. In den folgenden Situationen passen sie jedoch möglicherweise nicht zu Ihren Anforderungen:

• Sie verfügen über Anforderungen für die benutzerdefinierte Replikation oder für die gleichzeitige Aufrechterhaltung mehrerer aktiver Regionen.
• Sie verwenden eine Dienstbusebene, die diese Features nicht unterstützt.

Es gibt eine Reihe von Entwurfsmustern, um verschiedene Arten von Multi-Region-Unterstützung in Service Bus zu erreichen. Viele der Muster erfordern die Bereitstellung mehrerer Namespaces und das Konfigurieren Ihrer Anwendung für die geeignete Verwendung der Namespaces. Weitere Informationen finden Sie in den folgenden Artikeln:

• Verwendung mehrerer Namespaces zur Isolierung von Anwendungen vor Service Bus-Ausfällen und Katastrophen.
• Nachrichtenreplikation und regionsübergreifender Partnerverbund.

Resilienz gegenüber Wartungsarbeiten an Diensten

Service Bus führt regelmäßige Wartung durch. Während der geplanten Wartung werden Namespaces in einen redundanten Knoten verschoben, der die neuesten Updates enthält. Bei dieser Verschiebung trennt das Client-SDK die Verbindung und stellt sie automatisch für den Namenspace wieder her. In der Regel erfolgen die Upgrades innerhalb von 30 Sekunden. Es ist wichtig, dass Ihre Anwendungen auf vorübergehende Netzwerkverbindungsunterbrechungen vorbereitet sind, die während der Wartungszeiten auftreten.

Weitere Informationen finden Sie unter Anleitungen zu Azure-Wartungsereignissen für Azure Service Bus.

Sichern und Wiederherstellen

Service Bus ist nicht als langfristiger Speicherort für Ihre Daten konzipiert. In der Regel werden Daten für einen kurzen Zeitraum in einem Thementopic oder einer Warteschlange gespeichert und anschließend in einem anderen Datenspeichersystem verarbeitet oder gespeichert. Danach werden sie gelöscht. Aufgrund dieses Entwurfs verwaltet Service Bus automatisch Replikate von Nachrichtendaten, bietet jedoch keine Sicherungs- und Wiederherstellungsfunktionen für Nachrichtendaten.

Für Szenarien, die eine langfristige Nachrichtenaufbewahrung erfordern, sollten Sie die Archivierung auf Anwendungsebene in Azure Storage oder andere dauerhafte Speicherdienste implementieren.

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.

Service Bus stellt eine SLA für alle Namespaces bereit. Die Verfügbarkeits-SLA ist höher, wenn Ihr Namespace alle folgenden Kriterien erfüllt:

• Es verwendet die Premium-Stufe.
• Sie befindet sich in einer Region mit Verfügbarkeitszonen.
• Es verwendet Partitionierung.

Verwandte Inhalte

• Service Bus-Dokumentation
• Georedundante Notfallwiederherstellung von Azure Service Bus
• Georeplikation des Azure Service Bus