Zuverlässigkeit in Azure Notification Hubs

Azure Notification Hubs hilft Ihnen, Pushbenachrichtigungen über mehrere Plattformbenachrichtigungssysteme (PNS) hinweg zu verwalten, z. B. Apple Push Notification Service (APNs), Firebase Cloud Messaging (FCM) und Windows PushBenachrichtigungsdienst (WNS).

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 Notification Hubs gegenüber verschiedenen potenziellen Ausfällen und Problemen resilient machen, darunter vorübergehende Fehler, Ausfälle von Verfügbarkeitszonen, regionsweite Ausfälle und Wartungsarbeiten am Dienst. Darüber hinaus werden Sicherungs- und Wiederherstellungsoptionen und wichtige Informationen zum Servicelevelvertrag (Notification Hubs Service Level Agreement, SLA) beschrieben.

Bereitstellungsempfehlungen für die Produktion

Befolgen Sie für Produktionsworkloads die folgenden Empfehlungen:

Übersicht über die Zuverlässigkeitsarchitektur

Azure Notification Hubs sind um Namespaces und Benachrichtigungshubs organisiert. Ein Namespace ist eine Verwaltungsgrenze, die einen oder mehrere Hubs enthält. Hubs stellen Endpunkte für eine Anwendung dar. Geräte registrieren sich bei diesen Endpunkten mithilfe von Registrierungen oder Installationen, die es dem Dienst ermöglichen, Pushbenachrichtigungen an die Geräte zu senden. Weitere Informationen finden Sie unter Registrierungsverwaltung.

Notification Hubs sendet Pushbenachrichtigungen an Plattformbenachrichtigungssysteme (PNS), z. B. Apple Push Notification Service (APNs) und Firebase Cloud Messaging (FCM). Die End-to-End-Benachrichtigungsübermittlung hängt von der Verfügbarkeit von Benachrichtigungshubs und dem Verhalten von nachgeschalteten PNS-Anbietern ab.

Für die Zuverlässigkeitsplanung ist es wichtig, zwischen den folgenden Datentypen zu unterscheiden, die Notification Hubs verwaltet:

• Metadaten: Namespace- und Hubkonfiguration, einschließlich Verbindungsinformationen und Notfallwiederherstellungskonfiguration.
• Registrierungsdaten: Geräteregistrierungen und -installationen, die Benutzern und Geräten Tags und Vorlagen zuordnen.

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 zum Umgang mit vorübergehenden Fehlern.

Notification Hubs behandelt automatisch vorübergehende Fehler, die bei der Verbindung mit einem PNS auftreten. Sie sind jedoch für die Behandlung vorübergehender Fehler verantwortlich, wenn Ihre Dienste oder Benutzergeräte mit Benachrichtigungshubs interagieren. Vorübergehende Fehler können während Registrierungsvorgängen, Benachrichtigungs-Sendevorgängen und Verwaltungsvorgängen auftreten. Befolgen Sie diese Anleitung:

• Registrierungen und Installationen: Ihre Anwendungen auf Geräten sollten Registrierungs- und Installationsvorgänge wiederholen, die aufgrund vorübergehender Fehler fehlschlagen. Microsoft bereitgestellten SDKs behandeln Wiederholungen automatisch. Wenn Sie die bereitgestellten SDKs nicht verwenden können, implementieren Sie Wiederholungslogik mit exponentiellem Backoff und Jitter, und machen Sie Registrierungsvorgänge nach Möglichkeit idempotent.

  Das Erstellen oder Aktualisieren einer Installation ist idempotent, sodass Sie den Vorgang sicher wiederholen können. Verwenden Sie nach Möglichkeit Installationen anstelle von Registrierungen.

• Benachrichtigungsvorgänge und Verwaltungsvorgänge: Verwenden Sie ein Microsoft bereitgestelltes SDK, um Pushbenachrichtigungen zu senden und Verwaltungsvorgänge auszuführen. Diese SDKs wiederholen automatisch den Vorgang, wenn vorübergehende Fehler auftreten.

  Wenn Sie die bereitgestellten SDKs nicht verwenden können, implementieren Sie eine Logik für Wiederholungsversuche mit exponentiellem Backoff und Jitter und gestalten Sie das Senden von Benachrichtigungen nach Möglichkeit idempotent.

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.

In Regionen, die Verfügbarkeitszonen unterstützen, unterstützen Notification Hubs-Namespaces eine zonenredundante Konfiguration. Benachrichtigungshubs ermöglichen automatisch Zonenredundanz für alle Namespaces in einigen Regionen. Wenn Zonenredundanz aktiviert ist, repliziert Microsoft Metadaten- und Registrierungsdaten in allen Verfügbarkeitszonen in der Region.

Requirements

• Regionsunterstützung:

  Notification Hubs aktiviert automatisch Zonenredundanz für alle Namespaces in den folgenden Regionen. Zonenredundanz kann in diesen Regionen nicht deaktiviert werden:

  Europa	Naher Osten	Africa	Asien-Pazifik
  Frankreich, Mitte	Qatar Central	Südafrika Nord	China, Norden 3
  Italy North			Korea Central
  Norwegen, Osten
  Poland Central
  Schweden, Mitte
  Switzerland North

  In anderen Regionen, die Benachrichtigungshubs unterstützen und Über Verfügbarkeitszonen verfügen, ist Zonenredundanz optional. Sie können sie nur aktivieren, wenn Sie einen Namespace erstellen.

• Unterstützte Tarife: Sie können Verfügbarkeitszonen mit allen Tarifen von Notification Hubs verwenden.

Cost

Zonenredundanz verursacht eine zusätzliche Gebühr, die über den Tarifpreis hinausgeht. Weitere Informationen finden Sie unter Preise für Benachrichtigungshubs.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

• Erstellen eines neuen zonenredundanten Namespaces: Der Prozess zum Erstellen eines neuen zonenredundanten Namespaces hängt von der Region ab, die Sie verwenden:

  • In Regionen, in denen Benachrichtigungshubs automatisch Zonenredundanzen aktivieren, müssen Sie sie nicht konfigurieren.

    Important

    In diesen Regionen erstellt Notification Hubs immer Namespaces mit aktivierter Zonenredundanz, auch wenn eine codebasierte Bereitstellung, z. B. eine Bicep Datei oder Azure Resource Manager Vorlage, angibt, dass Zonenredundanz deaktiviert ist.

    Wenn Sie keinen zonenredundanten Namespace wünschen, erstellen Sie ihn in einem Bereich, der optionale Zonenredundanz unterstützt.

  • In Regionen, in denen Zonenredundanz optional ist, können Sie sie nur aktivieren, wenn Sie einen Namespace erstellen. Informationen zum Einrichten eines neuen Namespace mit Zonenredundanz finden Sie unter Erstellen eines Azure Benachrichtigungshubs im Azure-Portal.

• Machen Sie eine vorhandene Namespace-Zone redundant: Notification Hubs unterstützt keine In-Place-Migration eines vorhandenen Namespace zur Unterstützung von Verfügbarkeitszonen. Sie müssen einen neuen Namespace bereitstellen und Ihre Registrierungen in diesen Namespace verschieben. Befolgen Sie die Anleitungen zum Verschieben von Ressourcen zwischen Azure Regionen, was auch gilt, wenn Sie den neuen Namespace in derselben Region bereitstellen.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie einen Notification Hubs-Namespace für Zonenredundanz konfigurieren, und alle Zonen sind betriebsbereit.

• Zonenübergreifender Betrieb: Notification Hubs verteilt und bedient Anfragen automatisch mithilfe der Infrastruktur in jeder Zone der Region.

• Zonenübergreifende Datenreplikation: Registrierungsdaten und Metadaten werden synchron in allen Zonen in der angegebenen Region repliziert.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie einen Notification Hubs-Namespace für Zonenredundanz konfigurieren, und es gibt einen Ausfall in einer der Zonen.

• Erkennung und Reaktion: Microsoft erkennt Zonenfehler und verwaltet Failover innerhalb der Region. Sie müssen kein Failover initiieren.

• Notification: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone abfällt. Sie können jedoch Azure Service Health verwenden, um den Gesamtstatus des Diensts zu verstehen, einschließlich aller Zonenfehler, und Sie können Service Health Alerts einrichten, um Sie über Probleme zu informieren.

• Aktive Anforderungen: In-Flight-Verwaltungsvorgänge, Geräteregistrierungen und neue Anforderungen zum Senden von Benachrichtigungen können während des Failovers fehlschlagen. Ihre Anwendungen sollten fehlgeschlagene Vorgänge wiederholen, indem Sie den Richtlinien zur vorübergehenden Fehlerbehandlung folgen.

• Erwarteter Datenverlust: Datenverluste werden während eines Ausfalls einer einzelnen Zone nicht erwartet, da Notification Hubs Namespace- und Hubkonfigurations- und Registrierungsdaten synchron über Verfügbarkeitszonen hinweg repliziert.

  Diese Replikation ist keine Sicherung. Im Rahmen des Modells der gemeinsamen Verantwortung sind Sie für die Sicherung von Registrierungs- und Installationsdaten verantwortlich. Weitere Informationen finden Sie unter Sicherung und Wiederherstellung.

• Voraussichtliche Ausfallzeit: Eine kurze Dienstunterbrechung ist möglich, während Microsoft den Datenverkehr umleitet. Befolgen Sie die Anleitung zur vorübergehenden Fehlerbehandlung , um Ihre Anwendungen auf diese Unterbrechungen vorzubereiten.

• Umverteilung: Der Dienst leitet Anforderungen automatisch an fehlerfreie Zonen weiter.

Zonenwiederherstellung

Wenn die betroffene Zone wiederhergestellt wird, müssen Sie keine Maßnahmen ergreifen. Microsoft stellt die Infrastruktur von Notification Hubs wieder her und balanciert sie neu aus, um die wiederhergestellte Zone zu verwenden.

Test auf Zonenfehler

Sie können ein Notification Hubs-Zonenfailover nicht direkt auslösen. Führen Sie Resilienztests für Wiederholungen, Idempotenz- und Abhängigkeitsfehler in Nichtproduktionsumgebungen aus, um das Arbeitsauslastungsverhalten zu testen. Sie können auch Azure Chaos Studio verwenden, um umgebende Anwendungskomponenten zu testen.

Widerstandsfähigkeit bei regionalen Ausfällen

Notification Hubs bietet Metadaten-Notfallwiederherstellung durch Replizieren von Namespacemetadaten in allen Regionen, repliziert jedoch keine Geräteregistrierungsdaten. Diese Funktion erfordert einen manuellen Eingriff während eines Regionsausfalls und umfasst einige Ausfallzeiten für Ihren Benachrichtigungshub.

Wenn Sie Ausfallzeiten und manuelle Eingriffe während des Failovers reduzieren müssen, sollten Sie eine benutzerdefinierte Multiregion-Lösung verwenden.

Microsoft-verwaltete Metadaten-Geo-Notfallwiederherstellung

Notification Hubs unterstützt die Notfallwiederherstellung von Microsoft-verwalteten Metadaten für eine sekundäre Azure-Region. Wenn Ihre primäre Region über einen gekoppelten Bereich verfügt, können Sie diesen gekoppelten Bereich auswählen. Unabhängig vom Kopplungsstatus Ihrer primären Region können Sie auch eine sekundäre Region aus einer Liste der flexiblen Wiederherstellungsregionen auswählen. Benachrichtigungshubs repliziert dann Namespacemetadaten, z. B. Namespacename, Verbindungszeichenfolgen und andere wichtige Informationen.

Microsoft ist für das Deklarieren eines Notfalls und das Initiieren eines Failovers verantwortlich. In diesem Fall erstellt Microsoft einen neuen Namespace in der sekundären Region. Da sie die Metadaten aus der primären Region verwendet, können Anwendungen mithilfe des vorhandenen Namespacenamens, Verbindungszeichenfolge und Hubnamen eine Verbindung mit diesem Namespace herstellen.

Requirements

• Regionsunterstützung: In gekoppelten Azure Regionen kann Ihr Namespace den Azure gekoppelten Bereich als sekundäre Region verwenden.

  Wenn sich Ihr Namespace in einer nicht verairten Region befindet oder Sie Daten in eine andere Region replizieren möchten, können Sie eine der folgenden flexiblen Wiederherstellungsregionen als sekundäre Region auswählen:

  Americas	Europa	Africa	Asien-Pazifik
  Brasilien Süd	Nordeuropa	Südafrika Nord	Australia East
  Westliches USA 2			Südostasien

• Unterstützung auf Tarifebene: Optionen für die Notfallwiederherstellung von Metadaten sind in allen Tarifen von Notification Hubs verfügbar.

Cost

Für die Konfiguration oder Nutzung der Metadaten-Geo-Notfallwiederherstellung mit Notification Hubs fallen keine zusätzlichen Gebühren an. Sie zahlen jedoch für die regionsübergreifende Bandbreite, die zum Replizieren von Metadaten verwendet wird. Details zu den Preisen finden Sie unter Bandbreitenpreise und Benachrichtigungshub-Preise.

Konfigurieren der Multiregion-Unterstützung

• Aktivieren der Geo-Notfallwiederherstellung für Metadaten für einen neuen Namespace: Befolgen Sie das Verfahren unter Erstellen eines Azure Benachrichtigungshubs im Azure-Portal. Wählen Sie die Notfallwiederherstellungskonfiguration aus, wenn Sie den Namespace erstellen.

• Aktivieren oder Deaktivieren der Geo-Notfallwiederherstellung für Metadaten für einen vorhandenen Namespace: Befolgen Sie das Verfahren unter "Notfallwiederherstellung aktivieren" für einen vorhandenen Azure Notification Hubs-Namespace.

• Sichern Sie Ihre Geräteregistrierungsdaten: Weitere Informationen finden Sie unter "Exportieren und Importieren Azure Notification Hubs Registrierungen in Massen".

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie einen Notification Hubs-Namespace für die Geo-Notfallwiederherstellung für Metadaten konfigurieren, und ihre primären und sekundären Regionen sind betriebsbereit.

• Standortübergreifender Betrieb: Die primäre Region dient allen Anforderungen. Die sekundäre Region bearbeitet keine Anfragen, es sei denn, es kommt zu einem Failover.

• Regionsübergreifende Datenreplikation: Metadaten, z. B. Namespacename, Hubkonfiguration, Verbindungszeichenfolgen und andere wichtige Informationen, werden asynchron in allen Regionen repliziert. Registrierungsdaten werden nicht repliziert. Sie sind dafür verantwortlich, sie regelmäßig zu exportieren, um eine Sicherungskopie zu behalten.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie einen Notification Hubs-Namespace für die Geo-Notfallwiederherstellung für Metadaten konfigurieren, und es gibt einen Ausfall in der primären Region.

• Erkennung und Reaktion: Microsoft ist dafür verantwortlich, den Regionsfehler zu erkennen und zu entscheiden, ob Failover in die konfigurierte sekundäre Region ausgelöst werden soll.

• Notification: 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: In-Flight-Anforderungen an den Namespace in der primären Region können fehlschlagen, wenn die Region offline ist. Clients sollten Vorgänge nach Abschluss des Failovers wiederholen.

• Erwarteter Datenverlust: Metadaten bleiben erhalten. Registrierungsdaten werden nicht automatisch gesichert, aber Sie können sie selbst sichern. Weitere Informationen finden Sie unter Exportieren und Importieren von Azure Notification Hubs-Registrierungen in großen Mengen. Wenn Sie das nicht tun, sind die Registrierungsdaten nicht verfügbar, bis sich die primäre Region erholt hat.

• Erwartete Ausfallzeit: Es dauert einige Zeit, bis Microsoft das Failover der Metadaten auslöst und das Failover anschließend abgeschlossen ist. Während die Zeit variieren kann, dauert es in der Regel mehrere Stunden.

  Nach Abschluss des Failovers sind Sie für die Wiederherstellung von Sicherungen von Registrierungsdaten verantwortlich.

• Umverteilung: Nach dem Failover werden Anforderungen an einen Namespace in der sekundären Region weitergeleitet, in dem die replizierten Daten aus der primären Region verwendet werden. Nach Abschluss des Failovers stellen Clients automatisch eine Verbindung mit dem Namespace in der sekundären Region her.

Region-Wiederherstellung

Wenn die primäre Region sich erholt, könnte es möglich sein, zurück zum primären Namespace in der primären Region zu wechseln. Der primäre Namespace würde die Registrierungsdaten vor dem Ausfall aufbewahren. Dies wäre ein manueller Prozess und Microsoft würden mit Ihnen kommunizieren, um zu erklären, wie dies funktioniert.

Nachdem die primäre Region wiederhergestellt wurde, müssen Sie:

• Überprüfen Sie den Zustand Ihres Namespace und seiner Daten.
• Ermitteln Sie, ob änderungen der letzten Registrierungsdaten aus der sekundären Region wieder mit der primären Region synchronisiert werden sollen.

Test auf Regionsfehler

Sie können kein Geo-Failover starten. Sie sollten jedoch ihre eigenen Notfallwiederherstellungsverfahren testen. Stellen Sie sicher, dass Registrierungen gesichert sind und dass Sie sie in einem neuen Namespace wiederherstellen können.

Benutzerdefinierte Multiregion-Lösungen für Resilienz

Die von Microsoft verwaltete Geonotfallwiederherstellung von Metadaten repliziert nur Metadaten. Das Feature kann diese Metadaten in einen sekundären Namespace wiederherstellen, aber Sie sind dafür verantwortlich, Geräteregistrierungen in diesen Namespace zu importieren, damit Ihre Anwendung weiterhin ausgeführt werden kann. Dieser Ansatz erfordert einen manuellen Eingriff während einer Katastrophe und erfordert Ausfallzeiten.

Wenn Ihre Wiederherstellungsziele geringere Ausfallzeiten oder weniger manuelle Eingriffe erfordern, können Sie eine benutzerdefinierte Active-Active-Multiregion-Lösung implementieren. Stellen Sie einen zweiten Notification Hubs-Namespace vorab in einer anderen Azure Region bereit.

• Failover: Da der zweite Namespace eine Arbeitsressource ist, können Sie Logik implementieren, um einen Regionsfehler zu erkennen und zu diesem Namespace zu wechseln.

• Synchronisierung: Um einen zweiten Benachrichtigungshub mit dem primären Benachrichtigungshub synchron zu halten, verwenden Sie eine der folgenden Optionen:

  • Für Installationen: Verwenden Sie ein App-Back-End, das gleichzeitig Installationen in beiden Benachrichtigungshubs erstellt und aktualisiert. Mit Installationen können Sie Ihren eigenen eindeutigen Gerätebezeichner angeben, der dieses Replikationsszenario unterstützt. Weitere Informationen finden Sie im RedundantHub-Beispiel.

  • Für Registrierungen: Verwenden Sie ein App-Back-End, das regelmäßig Registrierungen aus dem primären Benachrichtigungshub als Sicherung exportiert und sie in den sekundären Benachrichtigungshub importiert. Weitere Informationen finden Sie unter Massenexport und -import von Azure Notification Hubs-Registrierungen.

  Wenn Sie kein Back-End haben, konfigurieren Sie Ihre App auch so, dass Installationen in beiden Hubs erstellt werden, wenn die App auf Zielgeräten gestartet wird. Die Geräte erstellen neue Registrierungen in beiden Benachrichtigungshubs. Schließlich hat der sekundäre Benachrichtigungshub alle aktiven Geräte registriert.

• Abgelaufene Registrierungen und Installationen: Der sekundäre Benachrichtigungshub verfügt möglicherweise über abgelaufene Registrierungen und Installationen. Wenn ein Push an ein abgelaufenes Handle erfolgt, bereinigt Notification Hubs automatisch den zugehörigen Registrierungs- oder Installationsdatensatz auf dem Benachrichtigungshub basierend auf der vom PNS-Server empfangenen Antwort. Sie können abgelaufene Datensätze aus der Sicherungslösung Ihrer Wahl bereinigen, indem Sie benutzerdefinierte Logik hinzufügen, die Feedback von jedem Senden verarbeitet und abgelaufene Registrierungen und Installationen entfernt.

• Nicht geöffnete Apps: Es gibt einen Zeitraum, in dem Geräte mit ungeöffneten Apps keine Benachrichtigungen empfangen.

• Kosten: Wenn Sie Ihren eigenen sekundären Hub verwenden, um Registrierungsdaten zu schützen, verursacht dieser Hub normale Servicegebühren. Wenn Sie auch andere Azure Ressourcen in Ihrer sekundären Region bereitstellen, um Ihre Wiederherstellung zu unterstützen, bezahlen Sie diese zu normalen Servicetarifen.

Sichern und Wiederherstellen

Notification Hubs bietet keine einzelne integrierte Sicherungs- und Wiederherstellungsfunktion für alle in Ihrem Namespace gespeicherten Daten. Sie sind dafür verantwortlich, die folgenden Ansätze zu kombinieren:

• Verwenden Sie die Infrastruktur als Code (IaC), z. B. Bicep, um Ihren Namespace, Ihren Hub und die Richtlinienkonfiguration zu definieren. Speichern Sie diese Definitionen in der Quellcodeverwaltung, damit Sie die Ressourcen bei Bedarf erneut bereitstellen können.
• Sichern Sie Ihre Geräteregistrierungsdaten, indem Sie Azure Notification Hubs Registrierungen massenweise exportieren.

Resilienz gegenüber Wartungsarbeiten an Diensten

Microsoft wendet regelmäßig Dienstupdates an und führt andere Wartungen durch. Die Azure Plattform übernimmt diese Aktivitäten automatisch, um sicherzustellen, dass die Wartung nahtlos und transparent für Sie ist. Bei Wartungsereignissen wird keine Ausfallzeit erwartet, es sei denn, Sie wurden über die geplante Wartung in Azure Service Health informiert.

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 Dienstleistungsvereinbarungen für Onlinedienste.

Für Notification Hubs gilt die SLA für die Verfügbarkeit für Namespaces, die die Tarife "Basic" und "Standard" verwenden.

Verwandte Inhalte

• Zuverlässigkeit in Azure