Zuverlässigkeit im Azure-Ereignisraster

Azure Event Grid ist ein vollständig verwalteter Messagingdienst, der die ereignisbasierte Kommunikation zwischen Diensten und Anwendungen ermöglicht. Es wird häufig zum Erstellen ereignisgesteuerter Architekturen und zum Integrieren von Azure-Diensten in benutzerdefinierte Anwendungen verwendet.

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 Azure Event Grid für verschiedene potenzielle Ausfälle und Probleme widerstandsfähig machen, einschließlich vorübergehender Fehler, Verfügbarkeitszonenfehler und regionsweite Fehler. Außerdem werden wichtige Informationen zum Azure Event Grid Service Level Agreement (SLA) hervorgehoben.

Bereitstellungsempfehlungen für die Produktion

Das Azure Well-Architected Framework bietet Empfehlungen für Zuverlässigkeit, Sicherheit, Kosten, Vorgänge und Leistung. Informationen dazu, wie sich diese Bereiche gegenseitig beeinflussen und zu einer zuverlässigen Azure Event Grid-Lösung beitragen, finden Sie unter Azure Well-Architected Framework-Leitfaden für Azure Event Grid.

Ü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

Azure Event Grid leitet Ereignisse von Ereignisquellen an Ereignisverbraucher weiter. Es wird sowohl von Kundenanwendungen als auch von Azure-Diensten verwendet, um Ereignisse auszugeben und zu nutzen, z. B. Benachrichtigungen, wenn Ressourcen erstellt, aktualisiert oder gelöscht werden.

Event Grid unterstützt mehrere Ressourcentypen und Bereitstellungsmodelle:

• Themen sind die primären Entitäten, die Ereignisse empfangen und speichern.

  Systemthemen werden automatisch von Azure-Diensten erstellt, um Ereignisse für bestimmte Azure-Ressourcentypen auszustrahlen. Benutzerdefinierte Themen werden von Ihnen erstellt und verwaltet.

  Themen können die Push- und Pull-Übermittlung unterstützen.

• Ereignisdomänen gruppieren mehrere benutzerdefinierte Themen unter einem einzelnen Endpunkt und vereinfachen die Veröffentlichung von Ereignissen. Weitere Informationen finden Sie unter Grundlegendes zu Ereignisdomänen für die Verwaltung von Event Grid-Themen.

• Namespaces werden mit der Standardebene verwendet und stellen einen Container für mehrere Event Grid-Ressourcen bereit. Weitere Informationen finden Sie unter Azure Event Grid-Namespacekonzepte.

Das Ereignisraster unterstützt mehrere Ebenen, einschließlich der grundlegenden Ebene und der Standardebene. Diese Ebenen bieten unterschiedliche Funktionen und unterscheiden sich darin, wie Ressourcen bereitgestellt und verwaltet werden. Weitere Informationen finden Sie unter Auswählen der richtigen Ereignisrasterebene für Ihre Lösung.

Physische Architektur

Azure Event Grid ist ein vollständig verwalteter Dienst. Microsoft verwaltet die zugrunde liegende Infrastruktur, einschließlich Compute- und Speicherressourcen. In unterstützten Regionen verteilt Event Grid automatisch Ressourcen über Verfügbarkeitszonen , um integrierte Zonenredundanz bereitzustellen.

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.

Berücksichtigen Sie beim Verwenden des Ereignisrasters die folgenden Methoden, um sicherzustellen, dass Ihre Lösung für vorübergehende Fehler widerstandsfähig ist:

• Ereignisverleger: Wenn eine Clientanwendung Ereignisse im Event Grid veröffentlicht, ist sie für die Behandlung vorübergehender Fehler verantwortlich. Anwendungen sollten Wiederholungslogik implementieren, beim Veröffentlichen von Ereignissen. Weitere Informationen finden Sie unter Problembehandlung bei vorübergehenden Verbindungsproblemen.

  Es wird empfohlen, die Event Grid-Datenebenen-SDKs zu verwenden, die automatisch vorübergehende Fehlerbehandlung bieten.

• Ereigniskonsumenten: Event Grid liefert Ereignisse an konfigurierte Ziele. Für diese ausgehenden Verbindungen konfigurieren Sie Wiederholungsrichtlinien für Ereignisabonnements. Diese Richtlinien definieren, wie oft und wie lange Event Grid die Zustellung bei Fehlern, einschließlich vorübergehender Ausfälle, erneut versucht. Weitere Informationen finden Sie unter Nachrichten-Push-Zustellung und Wiederholungsversuche mit Namespace-Themen

• Idempotenz: Es empfiehlt sich, Ihre Ereignisarchitektur für idempotenz zu entwerfen, was bedeutet, dass Ereignisse mehrmals empfangen und verarbeitet werden können. Wenn beispielsweise ein vorübergehender Fehler oder ein anderes Problem auftritt, wenn Ihre Anwendung ein Ereignis verarbeitet, bedeutet eine idempotente Methode, dass Ihre Anwendung die Nachricht erneut verarbeiten und wiederherstellen kann.

  Sie sind dafür verantwortlich, Ihre Ereignisarchitektur und Ihre Anwendung so zu entwerfen, dass sie Idempotenz unterstützt. Allgemeine Informationen finden Sie unter "Idempotency".

• Dead-Letter-Verfahren: Event Grid unterstützt Dead-Lettering für nicht zustellbare Ereignisse, was dabei hilft, Daten bei länger andauernden Fehlern in den Ereignisverbrauchern zu speichern. Weitere Informationen finden Sie unter "Dead lettering" für Ereignisabonnements für Namespaces-Themen in Azure Event Grid.

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.

Azure Event Grid-Ressourcen sind zonenredundant in Regionen, die Verfügbarkeitszonen unterstützen. Zonenredundanz bedeutet, dass Ihre Event Grid-Ressourcen auch dann weiterhin funktionieren, wenn eine Verfügbarkeitszone ein Problem hat, indem Sie die Infrastruktur in anderen Zonen verwenden. Ereignisdaten werden automatisch über drei Verfügbarkeitszonen hinweg für regionale Resilienz repliziert, und das Event Grid verfügt über Selbstheilungsmechanismen im Falle eines zonenweiten Ausfalls. Sie müssen diese Funktion nicht aktivieren oder konfigurieren.

Anforderungen

Regionsunterstützung: Zonenredundanz ist in allen Azure-Regionen verfügbar, die Verfügbarkeitszonen unterstützen.

Cost

Es gibt keine zusätzlichen Kosten für Zonenredundanz. Sie können dieses Feature nicht aktivieren oder deaktivieren. sie ist standardmäßig in unterstützten Regionen enthalten.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

Es ist keine Konfiguration erforderlich. Alle Ereignisrasterressourcen in unterstützten Regionen sind automatisch zonenredundant.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn eine Ereignisrasterressource zonenredundant ist und alle Zonen betriebsbereit sind.

• Zonenübergreifender Vorgang: Das Ereignisraster arbeitet in einem aktiven Modell über Verfügbarkeitszonen hinweg. 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.

• Zonenübergreifende Datenreplikation: Das Ereignisraster repliziert Metadaten und Ereignisdaten automatisch über Verfügbarkeitszonen hinweg, um Resilienz aufrechtzuerhalten.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn eine Ereignisrasterressource zonenredundant ist, und es gibt einen Ausfall in einer der Zonen.

• Erkennung und Reaktion: Das Ereignisraster erkennt Automatisch Zonenfehler und initiiert Failover zu fehlerfreien Zonen. Sie müssen keine Maßnahmen ergreifen, um ein Zonenfailover zu initiieren.

• Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone deaktiviert ist. 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: Während eines Zonenfehlers kann Event Grid aktive Anforderungen ablegen. Wenn Ihre Clients vorübergehende Fehler angemessen behandeln, z. B. durch erneutes Wiederholen nach kurzer Zeit, vermeiden sie in der Regel erhebliche Auswirkungen.

• Erwarteter Datenverlust: Das Redundanzmodell des Event Grid ist darauf ausgelegt, bei Zonenfehlern mit minimalen Auswirkungen Ausfallsicherheit zu gewährleisten. Während eines Zonenausfalls besteht jedoch die Möglichkeit eines Datenverlusts.

  Wenn Sie sicherstellen müssen, dass Ihre Anwendung auch während eines Zonenfehlers keine Daten verliert, sollten Sie:

  • Entwerfen Sie Ihre Ereignishersteller und Verbraucher so, dass sie die Empfehlungen zur Behandlung transiente Fehler befolgen, einschließlich Wiederholungen und Idempotenz.
  • Planen Sie die Haltbarkeit von Ereignissen an der Quelle oder in einem dauerhaften Ereignisspeicher.

• Erwartete Ausfallzeiten: Ein Zonenfehler kann zu einigen Sekunden Ausfallzeiten führen. Wenn Ihre Clients vorübergehende Fehler angemessen behandeln, z. B. durch erneutes Wiederholen nach kurzer Zeit, vermeiden sie in der Regel erhebliche Auswirkungen.

• Datenverkehrsumleitung: Das Ereignisraster erkennt den Verlust der Zone und leitet neue Anforderungen automatisch an die Infrastruktur in einer der fehlerfreien Verfügbarkeitszonen weiter.

Zonenwiederherstellung

Wenn die betroffene Zone wiederhergestellt wird, wird das Ereignisraster automatisch wieder in den Dienst integriert, ohne dass eine Kundenaktion erforderlich ist. Die wiederhergestellte Zone akzeptiert dann neue Verbindungen und verarbeitet Nachrichten zusammen mit den anderen Zonen. Daten, die während des Ausfalls in überlebende Zonen repliziert wurden, bleiben intakt und die normale Replikation wird in allen Zonen fortgesetzt. Sie müssen keine Maßnahmen für die Zonenwiederherstellung oder die Neuintegration ergreifen.

Test auf Zonenfehler

Event Grid verwaltet das Routing des Datenverkehrs, Failover und die Wiederherstellung bei Zonenausfällen, sodass Sie keine Prozesse bei Ausfällen von Verfügbarkeitszonen überprüfen oder weitere Eingaben geben müssen.

Widerstandsfähigkeit bei regionalen Ausfällen

Ereignisrasterressourcen werden in einer einzelnen Region bereitgestellt. Wenn ein regionsweiter Fehler auftritt, sind Ihre Event Grid-Ressourcen nicht verfügbar.

In gekoppelten Azure-Regionen bietet Event Grid eine eingeschränkte Geo-Notfallwiederherstellung für die Metadaten Ihrer Event Grid-Ressourcen. Sie können auch Ihre eigene Multi-Region-Lösung entwerfen und erstellen, die Ihre Notfallwiederherstellungsplanung unterstützen kann. In der folgenden Tabelle wird gezeigt, wie verschiedene Ereignisrasterressourcentypen jedes Modell unterstützen:

Geokatastrophenwiederherstellung

Die Geo-Disaster-Recovery repliziert die Event Grid-Metadaten für die unterstützten Ressourcen in das gekoppelte Gebiet Ihrer primären Region. Ereignisdaten werden nicht repliziert.

Geo-Notfallwiederherstellung ist als best-effort, von Microsoft verwalteter Fallback für schwere regionale Ausfälle konzipiert und ist nicht für schnelle oder vorhersehbare Wiederherstellungszeiten vorgesehen. In seltenen Fällen wird ein von Microsoft initiiertes Failover durchgeführt, um Event Grid-Ressourcen aus einer betroffenen Region in die entsprechende geografisch gekoppelte Region zu übertragen. Microsoft behält sich das Recht vor, zu entscheiden, wann diese Option angewendet wird. Dieser Mechanismus schließt keine Kundenzustimmung ein, bevor der Datenverkehr umgeleitet wird.

Sie können optional die Geo-Notfallwiederherstellung deaktivieren und Ihre eigene benutzerdefinierte Multi-Region-Lösung verwenden, die Ihre Anforderungen für die Regionsauswahl, Failoverzeit und vieles mehr erfüllt. Wenn Sie die Geo-Notfallwiederherstellung deaktivieren, werden keine Ereignisdaten von Microsoft in eine andere Region repliziert.

Dieses Feature ist in Regionen ohne gekoppelte Region nicht verfügbar.

Anforderungen

• Regionsunterstützung: Die Geo-Notfallwiederherstellung ist nur in Azure-Regionen verfügbar, die über eine gekoppelte Region verfügen.

• Ressourcentypen: Benutzerdefinierte Themen und Domänen unterstützen die Geo-Notfallwiederherstellung. Systemtopics werden automatisch für die Geo-Disaster-Wiederherstellung aktiviert. Andere Ressourcentypen, z. B. Namespaces und Partnernamespaces, werden nicht unterstützt.

Cost

Es gibt keine zusätzlichen Kosten für die Geo-Notfallwiederherstellung.

Konfigurieren der Unterstützung für mehrere Regionen

In unterstützten Regionen werden Systemthemen automatisch für die Geo-Notfallwiederherstellung konfiguriert. Für andere Ereignisrasterressourcentypen:

• So aktivieren Sie die Geo-Notfallwiederherstellung: Aktualisieren Sie die Konfiguration für Ihr Thema oder Ihre Domäne, und wählen Sie Cross-Geo (Standard) aus.

• So deaktivieren Sie die Geodiasterwiederherstellung: Aktualisieren Sie die Konfiguration für Ihr Thema oder Ihre Domäne, und wählen Sie "Regional" aus.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn eine Event Grid-Ressource für die Geo-Notfallwiederherstellung konfiguriert ist und alle Regionen betriebsbereit sind.

• Standortübergreifender Betrieb: Der gesamte Datenverkehr wird an die primäre Region weitergeleitet.

• Regionsübergreifende Datenreplikation: Metadaten werden synchron in den gekoppelten Bereich repliziert. Ereignisdaten werden nicht repliziert.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn eine Event Grid-Ressource für die Geo-Notfallwiederherstellung konfiguriert ist, und es gibt einen Ausfall in der primären Region.

• Erkennung und Reaktion: Microsoft erkennt Regionsfehler und bestimmt, ob und wann Failover initiiert werden soll.

• 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 an den primären Bereich werden beendet. Clientanwendungen müssen diese Anfragen wiederholen, nachdem das Failover abgeschlossen wurde.

• Erwarteter Datenverlust:

  • Metadaten: Das Ereignisraster behält Metadaten während des Failovers bei. Da alle Metadatenänderungen synchron repliziert werden, wird kein Verlust von Metadaten erwartet.

  • Ereignisdaten: Ereignisdaten in der primären Region sind nicht verfügbar und gehen möglicherweise verloren, wenn die Region nicht wiederhergestellt werden kann.

    Nachdem ein Failover erfolgt, werden neue Daten aus dem gekoppelten Bereich verarbeitet. Die unverarbeiteten Ereignisse werden aus der primären Region versendet, sobald der Ausfall behoben ist. Wenn die Wiederherstellung der primären Region eine längere Zeit erfordert als der für Ereignisse festgelegte Zeit-zu-Live-Wert, werden die Daten in der primären Region möglicherweise gelöscht. Um diesen Datenverlust zu mindern, empfehlen wir, ein Dead-Letter-Ziel für ein Event-Abonnement zu konfigurieren.

    Wenn die betroffene Region verloren geht und nicht wiederhergestellt werden kann, treten Datenverluste auf. Im besten Fall hält der Verbraucher die Veröffentlichungsrate bei, und nur wenige Sekunden Daten gehen verloren. Im schlimmsten Fall wäre es, wenn der Konsument Ereignisse nicht aktiv verarbeitet und bei einer maximalen Lebensdauer von 24 Stunden, kann der Datenverlust bis zu 24 Stunden betragen.

    Hinweis

    Ereignisraster kann die Datenaufbewahrung während eines Regionsausfalls nicht garantieren. Wenn Sie eine garantierte Aufbewahrung benötigen, müssen Sie Ihre Anwendung so entwerfen, dass Ereignisse in einem anderen Datenspeicher dauerhaft gespeichert werden.

• Erwartete Ausfallzeiten: Die Anzahl der Ausfallzeiten hängt vom Schweregrad des Ausfalls und der Zeit ab, die Microsoft zum Bewerten und Initiieren des Failovers benötigt. Sie sollten erwarten, dass ausfallzeiten mindestens eine Stunde und vielleicht länger sind.

  Nach dem Initiieren des Failovers nimmt Event Grid nach fünf Minuten den Verkehr für Themen und Abonnements an, einschließlich der Vorgänge zur Erstellung, Aktualisierung und Löschung.

• Umverteilung: Nach Abschluss des Failovers wird der Datenverkehr automatisch an die sekundäre Region weitergeleitet.

Region-Wiederherstellung

Microsoft verwaltet die Regionswiederherstellung und der Wiederherstellungsvorgang hängt vom jeweiligen Ausfallszenario ab. Im Allgemeinen wird Failover in der Regel als einseitiger Vorgang behandelt.

Test auf Regionsfehler

Azure Event Grid verwaltet Datenverkehrsrouting, Failover und Wiederherstellung für die Geo-Notfallwiederherstellung. Sie brauchen nichts zu initiieren. Da dieses Feature vollständig verwaltet wird, müssen Sie keine Regionsfehlerprozesse überprüfen.

Benutzerdefinierte Lösungen mit mehreren Regionen für Resilienz

Möglicherweise möchten Sie das von Microsoft initiierte Failover aus einem der folgenden Gründe deaktivieren oder nicht darauf vertrauen:

• Sie benötigen, dass Ereignisdaten über Regionen hinweg repliziert werden und nicht nur ausschließlich Metadaten.
• Sie müssen eine bestimmte Failoverzeit oder einen bestimmten Ansatz garantieren. Das von Microsoft initiierte Failover wird nach bestem Bemühen ausgeführt.
• Ihre Region ist nicht mit einer anderen Azure-Region gekoppelt.
• Das Datenpaar Ihrer Region erfüllt nicht die Anforderungen Ihrer Organisation an die Datenresidenz.

Für höhere Steuerungs- und Vorhersagbarkeitsebenen können Sie benutzerdefinierte Multi-Region-Architekturen implementieren. Dieser Ansatz umfasst die Bereitstellung separater Event Grid-Ressourcen in mehreren Regionen und das Verwalten von Failover auf Anwendungsebene. Wenn Sie dieses Modell verwenden, sind Sie für die Bereitstellung, Konfiguration und Synchronisierung von Ressourcen in allen Regionen verantwortlich.

Berücksichtigen Sie beim Entwerfen einer Lösung mit mehreren Regionen die folgenden Faktoren:

• Replikation: Sie sollten einen benutzerdefinierten Prozess implementieren, um Ihre Event Grid-Ressourcen und deren Konfiguration zwischen primären und sekundären Regionen zu replizieren. Denken Sie daran, Clientidentitäten, Zertifizierungsstellenzertifikate, Clientgruppen, Themenräume und Berechtigungsbindungen ggf. zu replizieren. Sie können entscheiden, ob die manuelle oder automatisierte Replikation implementiert werden soll.

• Failoveransätze: Sie können auswählen, ob eine aktive-aktive oder aktive-passive Lösung erstellt werden soll.

  • Aktiv-aktive Lösungen können erreicht werden, indem die Metadaten repliziert und die Last über die Namespaces hinweg verteilt wird.
  • Aktiv-passive Lösungen können erreicht werden, indem die Metadaten repliziert werden, um den sekundären Namespace bereit zu halten, damit der Datenverkehr an sekundären Namespace weitergeleitet werden kann, wenn der primäre Namespace nicht verfügbar ist.

• Integritätsüberwachung: Sie können integrierte Integritäts-APIs verwenden, die vom Ereignisraster bereitgestellt werden, um die Integrität von Themen zu überwachen.

  Ihre Clientanwendungen müssen Fehler einer Region erkennen und Ereignisse an eine andere geeignete Region weiterleiten.

  Alternativ können Sie einen Concierge-Dienst implementieren, der Clients an die primären oder sekundären Endpunkte für ihre Themen oder Namespaces leitet, durch Ausführen von Integritätsprüfungen dieser Endpunkte. Der Portierdienst kann eine Webanwendung sein, die geo-repliziert und mithilfe von DNS-Umleitungstechniken oder Diensten wie Azure Traffic Manager erreichbar gehalten wird.

Weitere Informationen zu einem Ansatz, einschließlich Beispielcode, finden Sie unter clientseitige Failoverimplementierung in Azure Event Grid.

Sichern und Wiederherstellen

Das Ereignisraster ist in erster Linie ein Ereignisroutingdienst und verfügt nicht über systemeigene Sicherungs- oder Wiederherstellungsfunktionen.

Wenn Sie Sicherungsfunktionen implementieren oder langfristige Aufbewahrungsanforderungen haben, empfehlen wir Ihnen, die Archivierung in Ihrer Anwendung durchzuführen. Dazu sollten Sie Logik erstellen, um Ihre Ereignisse parallel zum primären Übermittlungspfad an einen dauerhaften Speicher wie Azure Blob Storage weiterzuleiten oder zu kopieren. Wenn nachgeschaltete Systeme nicht verfügbar sind, kann Ihre Anwendung das Archiv verwenden, um die Ereignisse abzuspielen.

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. Während Wartungsereignissen wird keine Ausfallzeit erwartet, es sei denn, Sie wurden über die geplante Wartung des Azure Service Health beraten.

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.

Die SLA zur Verfügbarkeit des Ereignisrasters umfasst die Veröffentlichung von Ereignissen.

Verwandte Inhalte

• Zuverlässigkeit in Azure
• Azure Well-Architected Framework-Leitfaden für Azure Event Grid
• Dokumentation zu Azure Event Grid