Zuverlässigkeit in Azure SignalR Service

Azure SignalR Service ist ein vollständig verwalteter Dienst, der die bidirektionale Kommunikation in Echtzeit in Web- und mobilen Anwendungen ermöglicht. Er abstrahiert den zugrunde liegenden Transportmechanismus. Wenn WebSockets verfügbar sind, verwendet der Dienst sie. Wenn dies nicht der Fall ist, fällt es auf Server-Sent-Ereignisse oder Langzeit-Abfragen zurück. Diese Abstraktion bedeutet, dass Ihr Client- und Servercode in Echtzeit kommunizieren kann, ohne an ein bestimmtes Transportprotokoll gebunden zu sein.

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 SignalR Service widerstandsfähig für eine Vielzahl potenzieller Ausfälle und Probleme machen, einschließlich vorübergehender Fehler, Verfügbarkeitszonenausfälle, Regionsausfälle und Servicewartung. Außerdem werden wichtige Informationen zum Azure SignalR Service ServiceLevel Agreement (SLA) hervorgehoben.

Empfehlungen für die Produktionsimplementierung für Zuverlässigkeit

Für Produktionsarbeitslasten empfehlen wir Folgendes:

  • Verwenden Sie die Premium-Stufe. Die Premium-Stufe ist widerstandsfähig für Verfügbarkeitszonenfehler in unterstützten Regionen und ermöglicht es Ihnen, die Georeplikation zu konfigurieren.
  • Entwerfen Sie Clientanwendungen und App-Server so, dass sie sich bei einem Verbindungsabbruch automatisch wiederverbinden. Zonenfailover, Regionsfailover und vorübergehende Fehler führen dazu, dass alle aktiven Verbindungen abgebrochen werden.
  • Aktivieren Sie die Georeplikation, um vor regionsweiten Fehlern zu schützen. Stellen Sie sicher, dass jede Replik mit ausreichend Einheiten dimensioniert ist, um die vollständige erwartete Datenverkehrslast während eines Failovers zu bewältigen.

Ü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

Die ressource, die Sie erstellen, ist eine SignalR Service ressource. Sie konfigurieren eine Ressource mit einer Anzahl von Einheiten, die die Kapazität der Ressource darstellt, einschließlich der maximalen Anzahl gleichzeitiger Verbindungen. Weitere Informationen finden Sie im Leitfaden Performance für Azure SignalR Service.

Azure SignalR Service unterstützt zwei Servicemodi. Ihre App-Server stellen im Standardmodus eine Verbindung mit der Azure SignalR Service Resource her und enthalten die Hublogik. Im serverlosen Modus wird der Dienst in Azure Functions integriert, und Funktionen fungieren als ereignisgesteuerte Nachrichtenhandler, sodass Sie App-Server nicht direkt verwalten. Weitere Informationen finden Sie unter Dienstmodi in Azure SignalR Service.

Eine SignalR Service Ressource weist einen global eindeutigen Endpunkt auf, der contoso.service.signalr.net ähnelt. Clients richten Verbindungen zu diesem Endpunkt ein. Anwendungsserver stellen eine Verbindung mit demselben Endpunkt her, um Nachrichten zu senden und Ereignisse von Clients zu empfangen.

Physische Architektur

Azure SignalR Service verwaltet den Verbindungsstatus und das Nachrichtenrouting über eine Reihe von Computeressourcen hinweg. Microsoft verwaltet die zugrunde liegende Infrastruktur. Sie sehen oder interagieren nicht direkt mit einzelnen virtuellen Computern, die der Dienst verwendet, oder mit anderen Infrastrukturkomponenten.

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.

Azure SignalR Service verwendet langlebige Verbindungen zwischen Clients, App-Servern und dem Dienst. Diese Verbindungen können aufgrund vorübergehender Fehler wie Netzwerkinstabilität, Lastenausgleichs-Neukonfigurationen oder Aussetzen der Browserregisterkarten unterbrochen werden. Entwerfen Sie Ihre Clientanwendungen und App-Server so, dass Verbindungsabbrüche verarbeitet und automatisch erneut verbunden werden.

Die Azure SignalR Service SDKs umfassen die integrierte Behandlung der Wiederverbindungen für Serververbindungen mit dem Dienst. Die clientseitige Erneute Verbindung hängt von der verwendeten Clientbibliothek ab. ASP.NET Core SignalR-Clients unterstützen ein zustandsbehaftetes Wiederverbinden, wodurch ein Client seine vorherige Verbindung wiederaufnehmen kann, ohne den Zustand zu verlieren, wenn die Verbindung schnell mit der gleichen Verbindungs-ID wiederhergestellt wird. Wenn die erneute Verbindung zu einer neuen Verbindungs-ID führt, z. B. nach einem längeren Ausfall, behandelt der Dienst den Client als neue Verbindung. In diesem Fall muss der Client zu allen Gruppen erneut beitreten, in denen er zuvor war, und den Sitzungszustand wiederherstellen.

Ausführliche Anleitungen zum Entwerfen Ihrer Anwendung zur Behandlung von Verbindungsabbrüchen und Wiederverbindungen finden Sie unter Understanding client disconnections and reconnection in Azure SignalR Service.

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 SignalR Service unterstützt zonenredundante Bereitstellungen auf der Premium-Ebene. Wenn Sie eine Premium-Ressourcenebene in einer Region erstellen oder aktualisieren, die Verfügbarkeitszonen unterstützt, Azure SignalR Service ihre Computekapazität automatisch über alle Verfügbarkeitszonen in der Region verteilt. Wenn eine Verfügbarkeitszone fehlschlägt, leitet Azure SignalR Service neue Verbindungen zu Instanzen in den verbleibenden fehlerfreien Zonen weiter.

Diagramm, das einen zonenredundanten Azure SignalR-Dienst anzeigt, verteilt auf mehrere Verfügbarkeitszonen.

Anforderungen

  • Regionsunterstützung: Zonenredundanz wird in den meisten Regionen unterstützt, in denen beide Bedingungen gelten:

    • Azure SignalR Service ist verfügbar. Eine Liste der Regionen, in denen der Dienst verfügbar ist, finden Sie unter "Produktverfügbarkeit nach Region".
    • Die Region unterstützt Verfügbarkeitszonen. Eine Liste der Regionen mit Verfügbarkeitszonen finden Sie unter Azure Regionsliste.

    Japan West unterstützt derzeit jedoch keine Zonenredundanz für Azure SignalR Service.

  • Rang: Zonenredundanz ist auf der Premium-Stufe verfügbar.

Kosten

Zonenredundanz fügt keine Kosten hinzu, aber Sie zahlen den Standardtarif der Premium-Stufe. Weitere Informationen finden Sie unter Azure SignalR Service Pricing.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

Zonenredundanz erfordert keine Konfiguration, die über die Auswahl der Premium-Stufe hinausgeht. Sie ist in beiden Fällen automatisch aktiviert:

  • Erstellen einer neuen zonenredundanten SignalR-Dienst-Ressource. Wählen Sie beim Erstellen der Ressource eine Premium-SKU aus. Weitere Informationen finden Sie in den Schnellstarts wie Quickstart: Erstellen eines Chatrooms mithilfe von SignalR Service.

  • Aktualisieren Sie eine vorhandene Ressource auf die Premium-Stufe. Zonenredundanz wird automatisch aktiviert, wenn Sie eine vorhandene Ressource auf eine Premium-SKU aktualisieren. Das Upgrade von Standard auf Premium führt nicht zu Dienstausfallzeiten. Weitere Informationen finden Sie unter Change your Azure SignalR Service tier.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie eine Azure SignalR Service Ressource für Zonenredundanz konfigurieren und alle Verfügbarkeitszonen betriebsbereit sind.

  • Cross-zone operation: Azure SignalR Service verwaltet automatisch, wie Verbindungen und Vorgänge über Verfügbarkeitszonen verteilt werden. Infrastruktur in mehreren Zonen verarbeitet Datenverkehr in einem aktive-aktive Modell. Sie müssen nichts konfigurieren, um dieses Verhalten nutzen zu können. Der Dienst leitet Nachrichten zwischen Instanzen automatisch über Zonen weiter, sodass eine von einem Client in einer Zone gesendete Nachricht an Clients übermittelt wird, die in einer anderen Zone verbunden sind.

  • Cross-Zone-Datenreplikation: Azure SignalR Service speichert keine Kundendaten, sodass keine Daten zwischen Zonen repliziert werden können. Der Verbindungsstatus ist kurzlebig und wird jeder aktiven Verbindung zugeordnet.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie eine Azure SignalR Service Ressource für Zonenredundanz konfigurieren, und es gibt einen Ausfall in einer der Verfügbarkeitszonen.

  • Erkennung und Reaktion: Die Azure SignalR Service-Plattform ist dafür verantwortlich, einen Ausfall in einer Verfügbarkeitszone zu erkennen. Sie müssen keine Maßnahmen ergreifen, um ein Zonenfailover zu initiieren.
  • Notification: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone abfällt. Sie können jedoch Azure Resource Health verwenden, um den Status einer einzelnen Ressource zu überwachen, und Sie können Resource Health Alerts einrichten, um Sie über Probleme zu informieren. Sie können auch 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 werden aktive Verbindungen zu Knoten in der betroffenen Zone verworfen. Wenn Ihre Clients vorübergehende Fehler angemessen behandeln, z. B. durch erneutes Verbinden nach kurzer Zeit, vermeiden sie in der Regel erhebliche Auswirkungen.

  • Erwarteter Datenverlust: Der Azure SignalR Service speichert keine Nachrichten, sodass ein Zonenfehler nicht zu Datenverlusten innerhalb des Azure SignalR Service führen wird. Während eines Zone-Ausfallereignisses werden jedoch alle aktiven Verbindungen verworfen, sodass alle Daten, die aktiv übertragen werden, verloren gehen könnten.

  • Erwartete Ausfallzeiten: Die erneute Verbindung von verworfenen aktiven Verbindungen dauert in der Regel einige Sekunden. Clients, die eine Wiederherstellungslogik implementieren, erleben minimale Unterbrechungen.

  • Redistribution: Azure SignalR Service erkennt den Verlust der Zone und verteilt den Datenverkehr automatisch über die gesunden Zonen. Sie müssen keine Maßnahmen ergreifen.

Zonenwiederherstellung

Wenn eine Verfügbarkeitszone wiederhergestellt wird, integriert Azure SignalR Service sie automatisch wieder in die aktive Diensttopologie. Sie müssen keine Aktion für die Zonenwiederherstellung ergreifen.

Nachdem eine Zone wiederhergestellt wurde, können neue Verbindungen zur Infrastruktur in dieser wiederhergestellten Zone geleitet werden. Bestehende Verbindungen werden nicht zur wiederhergestellten Zone verschoben oder neu ausgeglichen, aber sie werden schrittweise neu ausgeglichen, wenn die bestehenden Verbindungen abfallen und sich im Laufe der Zeit wieder verbinden. Das Verbindungsungleichgewicht in allen Zonen hat keine Auswirkungen auf Ihre Arbeitsauslastung.

Test auf Zonenfehler

Azure SignalR Service verwaltet Datenverkehrsrouting, Failover und Zonenwiederherstellung automatisch für zonenredundante Premium-Ressourcen. Sie brauchen nichts zu initiieren. Da Zonenredundanz vollständig verwaltet wird, müssen Sie keine Fehlerprozesse der Verfügbarkeitszone überprüfen.

Widerstandsfähigkeit bei regionalen Ausfällen

Azure SignalR Service ist ein Einzelregionendienst. Wenn die Region nicht verfügbar ist, ist ihre SignalR Service Ressource ebenfalls nicht verfügbar.

Um Ihre Anwendung vor einem regionsweiten Fehler zu schützen, können Sie die Georeplikation verwenden, die auf der Premium-Stufe verfügbar ist. Alternativ können Sie eine benutzerdefinierte Multiregion-Lösung erstellen, indem Sie mehrere SignalR Service Ressourcen in verschiedenen Regionen bereitstellen.

Geo-replication

Mit der Georeplikation können Sie Replikate Ihrer SignalR-Dienstressource in anderen Azure-Regionen hinzufügen. Azure Traffic Manager verwendet DNS-basiertes Routing, um jeden Client auf das nächste fehlerfreie regionale Replikat zu leiten. Wenn eine Region fehlschlägt, erkennt der Traffic Manager den Fehler durch Durchführen von Integritätsprüfungen und beendet das Weiterleiten von Clients an diese Replik. Neue Clientverbindungen werden automatisch an das nächste fehlerfreie Replikat weitergeleitet.

Diagramm, das die Konfiguration des Azure SignalR Service für die Geo-Replikation über zwei Regionen zeigt.

Die Region, in der Sie die Azure SignalR Service Ressource erstellt haben, wird als primärregion bezeichnet, und das Replikat ist das primäre Replikat. Die Control-Ebene der primären Ressource verwaltet die Konfiguration Ihrer Azure SignalR Service Ressource.

Anforderungen

  • Region support: Sie können Replikate in jeder Region hinzufügen, in der Azure SignalR Service verfügbar ist.
  • Rang: Sie müssen die Premium-Stufe verwenden, um die Georeplikation zu aktivieren.
  • Replica limit: Jede primäre SignalR Service-Ressource unterstützt bis zu acht Replikate.

Überlegungen

  • Konfigurationsvererbung: Replikate erben die meisten Konfigurationseinstellungen von der primären Ressource. Bestimmte Einstellungen müssen für jedes Replikat separat konfiguriert werden. Die vollständige Liste der Einstellungen, die nicht geerbt werden, finden Sie unter Geo-replikation in Azure SignalR Service.

  • Konfigurationsänderungen: Die primäre Steuerebene in der primären Region verarbeitet alle Konfigurationsänderungen an den SignalR Service-Ressourcen. Wenn die primäre Kontrollebene nicht verfügbar ist, können Sie die Ressourcenkonfiguration nicht aktualisieren, obwohl vorhandene Replikate den Datenverkehr ohne Unterbrechung weiter verarbeiten.

Kosten

Jedes Replikat wird separat auf der Grundlage der eigenen Einheitenanzahl und des ausgehenden Nachrichtenvolumens abgerechnet. Grenzüberschreitende Ausgangsgebühren gelten, wenn Nachrichten zwischen Replikaten übertragen und an Clients oder Server in einer anderen Region übermittelt werden. Weitere Informationen finden Sie unter Azure SignalR Service Pricing.

Konfigurieren der Georeplikation

Informationen zum Hinzufügen oder Entfernen eines Replikats zu einer SignalR Service-Ressource finden Sie unter Geo-Replikation in Azure SignalR Service.

Kapazitätsplanung und -verwaltung

Jedes Replikat bearbeitet den Datenverkehr unabhängig. Während eines regionalen Failovers stellen Clients aus der fehlgeschlagenen Region die Verbindung mit dem nächstgelegenen fehlerfreien Replikat wieder her. Um sicherzustellen, dass die überlebenden Replikate über genügend Kapazität verfügen, um diese zusätzliche Last zu absorbieren, konfigurieren Sie jedes Replikat mit Einheiten, die den vollständigen erwarteten Datenverkehr der Workload verarbeiten können, nicht nur den teil, der normalerweise bereitgestellt wird.

Aktivieren Sie alternativ die automatische Skalierung für jede Replik, sodass Einheiten bei höherer Auslastung automatisch erweitert werden können. Die automatische Skalierung funktioniert weiterhin, wenn ein sekundäres Replikat nicht verfügbar ist, aber die automatische Skalierung funktioniert nicht, wenn die primäre Steuerungsebene nicht verfügbar ist. Weitere Informationen zur automatischen Skalierung finden Sie unter Autoscaling in Azure SignalR Service.

Allgemeine Anleitungen zur Überteilung als Strategie finden Sie unter Verwalten der Kapazität durch Überschreibung.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie Azure SignalR Service für die Georeplikation konfigurieren und alle Replikate betriebsbereit sind.

  • Cross-region operation: Azure Traffic Manager leitet jeden Client an das nächste fehlerfreie regionale Replikat weiter. Clients in unterschiedlichen geografischen Gebieten können eine Verbindung mit verschiedenen Replikaten herstellen. SignalR Service synchronisiert Nachrichten über Replikate hinweg, sodass Clients, die mit jedem Replikat verbunden sind, miteinander kommunizieren können.

  • Regionsübergreifende Datenreplikation: Wenn eine Nachricht an ein Replikat gesendet wird, überträgt der Dienst diese Nachricht synchron an andere Replikate, damit clients, die an anderer Stelle verbunden sind, sie empfangen können. Der Synchronisierungsaufwand ist für die meisten gängigen Messagingmuster minimal, z. B. das Übertragen an große Gruppen oder das Messaging einer einzigen Verbindung. Nachrichten an kleine Gruppen (weniger als 10 Mitglieder) können zu einem etwas höheren Synchronisierungsaufwand führen.

    Der Azure SignalR-Dienst speichert keine Nachrichten; nur die aktive Zustellung wird über Replikate hinweg synchronisiert.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie Azure SignalR Service für die Georeplikation konfigurieren, und es gibt einen Ausfall in einem der Replikatregionen.

  • Erkennung und Reaktion: Der SignalR-Dienst erkennt Fehler in einer Region und leitet den Datenverkehr automatisch an ein konfiguriertes Replikat in einer anderen Region um.
  • 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: Aktive Verbindungen mit dem Replikat im fehlgeschlagenen Bereich werden verworfen. Clients müssen erneut verbunden werden, nachdem das Replikat fehlschlägt.

  • Expected data loss: Azure SignalR Service speichert keine Nachrichten. Nachrichten, die sich zum Zeitpunkt des Fehlers im Transit zu Clients in der ausgefallenen Region befanden, könnten verloren gegangen sein. Es wird kein dauerhafter Datenverlust erwartet, da der Dienst keine Kundendaten speichert.

  • Erwartete Ausfallzeit: Azure Traffic Manager führt Gesundheitsprüfungen für jedes Replikat durch. Wenn ein Regionsausfall bewirkt, dass ein Replikat seine Integritätsprüfung fehlschlägt, entfernt der Datenverkehrs-Manager den Endpunkt dieses Replikats aus seinen DNS-Auflösungsergebnissen. Nach dem Entfernen des Endpunkts muss die DNS-TTL von 90 Sekunden verstrichen sein, bevor Clients aktualisierte DNS-Einträge sehen. Insgesamt dauert der Übergang in der Regel ein paar Minuten. Gut gestaltete Clients, die die Logik für die erneute Verbindung implementieren, können nach der erneuten Verbindung mit dem fehlerfreien Replikat den normalen Vorgang fortsetzen.

    Wenn die primäre Steuerungsebene nicht verfügbar ist, können Sie keine Änderungen an der Konfiguration Ihrer SignalR Service Ressource oder deren Replikate vornehmen. Verbindungen funktionieren jedoch weiterhin in funktionsfähigen Replikaten.

  • Redistribution: Azure Traffic Manager leitet eingehende Anforderungen an fehlerfreie Replikate weiter. Wenn ein Client jedoch versucht, eine Erneute Verbindung herzustellen, bevor Azure Traffic Manager das Replikatfailover erkannt hat und die aktualisierten DNS-Einträge an den Client weitergegeben wurden, kann der erneute Verbindungsversuch eines Clients weiterhin auf die nicht verfügbare Region ausgerichtet sein und fehlschlagen.

    Nachdem das DNS-Update verteilt wurde, werden erneut verbundene Clients automatisch an das nächste fehlerfreie Replikat weitergeleitet.

Region-Wiederherstellung

Wenn die fehlerhafte Region wiederhergestellt wird, erkennt die Integritätsprüfung des Datenverkehrs-Managers das wiederhergestellte Replikat und schließt den Endpunkt erneut in die DNS-Auflösung ein. Clients, die derzeit mit anderen Replikaten verbunden sind, sind nicht betroffen und bleiben verbunden, bis sie die Verbindung trennen. Neue Verbindungen werden erneut an das Replikat der wiederhergestellten Region geleitet, wenn dieses das nächstgelegene fehlerfreie Replikat ist.

Test auf Regionsfehler

Um ein Regionsfailover zu simulieren und das Verhalten ihrer Clientanwendung für die erneute Verbindung zu testen, können Sie den Endpunkt eines Replikats deaktivieren. Diese Aktion bewirkt, dass Traffic Manager das Routing des Datenverkehrs an dieses Replikat beendet, wodurch Sie beobachten können, wie sich Ihre Clients verhalten, wenn das Replikat, mit dem sie eine Verbindung herstellen, nicht mehr verfügbar ist. Ausführliche Schritte finden Sie unter Deaktivieren oder Aktivieren des Replikatendpunkts.

Benutzerdefinierte Lösungen mit mehreren Regionen für Resilienz

Wenn Sie regionsübergreifende Resilienz benötigen, aber keine Georeplikation verwenden, können Sie separate SignalR Service Ressourcen in mehreren Regionen bereitstellen und verwalten und Ihre eigene Failoverlogik in Ihrem Anwendungsserver implementieren. Dieser Ansatz ist komplexer als die Georeplikation und bietet kein Failover mit Null-Ausfallzeit für die Verbindung zwischen Clients. Eine detaillierte Architekturübersicht, Failovermuster und Testanleitungen finden Sie unter Resiliency und Disaster Recovery in Azure SignalR Service.

Sichern und Wiederherstellen

Azure SignalR Service ist ein statusloser Messagingdienst. Es werden keine Kundennachrichten beibehalten und es gibt keine Sicherungs- oder Wiederherstellungsfunktion.

Um Ihre Ressourcenkonfiguration zu schützen, definieren Sie Ihre SignalR Service Ressourcen mithilfe der Infrastruktur als Code (z. B. Bicep oder ARM-Vorlagen), und speichern Sie diese Definitionen in der Quellcodeverwaltung. Wenn Sie eine Ressource neu erstellen müssen, stellen Sie sie aus der gespeicherten Konfiguration erneut bereit.

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.

Während der geplanten Wartung verwendet Azure SignalR Service eine sanfte Herunterfahrstrategie, um die Auswirkungen auf verbundene Clients zu verringern. Verbindungen werden nach und nach über ein festgelegtes Zeitfenster getrennt, sodass Clients sich progressiv und nicht alle gleichzeitig wieder verbinden können. Weitere Informationen finden Sie unter "Trennungen während der Wartung des Diensts".

Wartungsereignisse werden ihren Kunden angezeigt, wenn die Verbindung sinkt. Stellen Sie sicher, dass Ihre Client-Anwendungen eine Wiederverbindungslogik implementieren, damit sie sich von wartungsbezogenen Trennungen ohne sichtbare Unterbrechungen für den Benutzer erholen können.

Vereinbarung zum Servicelevel

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.

Verwandte Inhalte

  • Last updated on