Niezawodność w Azure SignalR Service

Azure SignalR Service to w pełni zarządzana usługa, która umożliwia dwukierunkową komunikację w czasie rzeczywistym w aplikacjach internetowych i mobilnych. Abstrahuje on od podstawowego mechanizmu transportu. Gdy WebSockety są dostępne, usługa ich używa. Kiedy tak nie jest, przełącza się na Server-Sent Events lub długi polling. Ta abstrakcja oznacza, że kod klienta i serwera może komunikować się w czasie rzeczywistym bez powiązania z określonym protokołem transportowym.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Microsoft oferuje szereg funkcjonalności wspierających odporność i odzyskiwanie. Odpowiadasz za zrozumienie, jak te możliwości działają w ramach wszystkich używanych usług oraz za wybór tych, które są potrzebne do osiągnięcia Twoich celów biznesowych i celów dotyczących niezawodności.

W tym artykule opisano, jak zapewnić odporność Azure SignalR Service na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie strefy dostępności, awarie regionów i konserwacja usługi. Wyróżnia również kluczowe informacje o umowie o poziomie usług (SLA) usługi Azure SignalR Service.

Zalecenia dotyczące wdrażania produkcyjnego pod kątem niezawodności

W przypadku obciążeń produkcyjnych zalecamy:

  • Użyj warstwy Premium. Warstwa Premium jest odporna na awarie strefy dostępności w obsługiwanych regionach i umożliwia konfigurowanie replikacji geograficznej.
  • Zaprojektuj aplikacje klienckie i serwery aplikacji, aby bezpiecznie ponownie łączyć się automatycznie po usunięciu połączeń. Awarie strefowe, awarie regionalne i błędy tymczasowe powodują utratę aktywnych połączeń.
  • Włącz replikację geograficzną, aby chronić przed awariami obejmującymi cały region. Zaprojektuj każdą replikę z wystarczającą liczbą jednostek do obsługi całego oczekiwanego obciążenia ruchu podczas zdarzenia przełączenia awaryjnego.

Omówienie architektury niezawodności

W tej sekcji opisano niektóre ważne aspekty działania usługi, które są najbardziej istotne z perspektywy niezawodności. W sekcji przedstawiono architekturę logiczną, która zawiera niektóre z zasobów i funkcji wdrażanych i używanych. Omówiono również architekturę fizyczną, która zawiera szczegółowe informacje na temat działania usługi za kulisami.

Architektura logiczna

Tworzony zasób to zasób SignalR Service. Zasób należy skonfigurować z liczbą jednostek, która reprezentuje pojemność zasobu, w tym maksymalną liczbę połączeń współbieżnych. Aby uzyskać więcej informacji, zobacz przewodnik dotyczący wydajności usługi Azure SignalR.

Azure SignalR Service obsługuje dwa tryby usługi service. W trybie domyślnym serwery aplikacji łączą się z zasobem Azure SignalR Service i zawierają logikę hubów. W trybie bezserwerowym usługa integruje się z Azure Functions, a funkcje działają jako programy obsługi komunikatów sterowane zdarzeniami, dzięki czemu serwery aplikacji nie są zarządzane bezpośrednio. Aby uzyskać więcej informacji, zobacz Tryb usługi w usłudze Azure SignalR Service.

Zasób SignalR Service ma globalnie unikatowy punkt końcowy podobny do contoso.service.signalr.net. Klienci nawiązują połączenia z tym punktem końcowym. Serwery aplikacji łączą się z tym samym punktem końcowym w celu wysyłania komunikatów i odbierania zdarzeń od klientów.

Architektura fizyczna

Azure SignalR Service zarządza stanem połączenia i routingiem komunikatów w zestawie zasobów obliczeniowych. Microsoft zarządza podstawową infrastrukturą. Nie widzisz ani nie wchodzisz bezpośrednio w interakcje z poszczególnymi maszynami wirtualnymi używanymi przez usługę ani z innymi składnikami infrastruktury.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

Azure SignalR Service używa długotrwałych połączeń między klientami, serwerami aplikacji i usługą. Te połączenia mogą zostać porzucone z powodu przejściowych błędów, takich jak niestabilność sieci, ponowna konfiguracja modułu równoważenia obciążenia lub zawieszenia kart przeglądarki. Zaprojektuj aplikacje klienckie i serwery aplikacji, aby obsługiwać przerywanie połączeń i automatycznie łączyć się ponownie.

Zestawy SDK Azure SignalR Service obejmują wbudowaną obsługę ponownego łączenia dla połączeń serwera z usługą. Ponowne nawiązywanie połączenia po stronie klienta zależy od używanej biblioteki klienta. Klienci SignalR usługi ASP.NET Core obsługują utrzymywanie stanu podczas ponownego nawiązywania połączenia, co umożliwia klientowi wznowienie poprzedniego połączenia bez utraty jego stanu, jeśli szybko nawiąże połączenie przy użyciu tego samego identyfikatora połączenia. Jeśli ponowne połączenie spowoduje wyświetlenie nowego identyfikatora połączenia, na przykład po dłuższej awarii, usługa traktuje klienta jako nowe połączenie. W takim przypadku klient musi ponownie połączyć wszystkie grupy, w których wcześniej znajdował się, i przywrócić dowolny stan sesji.

Aby uzyskać szczegółowe wskazówki dotyczące projektowania aplikacji do obsługi rozłączeń klientów i ponownego nawiązywania połączeń, zobacz Łączenie klientów i ponowne nawiązywanie połączenia w Azure SignalR Service.

Odporność na błędy strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Azure SignalR Service obsługuje wdrożenia strefowo nadmiarowe w warstwie Premium. Azure SignalR Service podczas tworzenia lub uaktualniania do zasobu warstwy Premium w regionie obsługującym strefy dostępności automatycznie dystrybuuje swoją moc obliczeniową we wszystkich strefach dostępności w regionie. Jeśli strefa dostępności przestanie działać, Azure SignalR Service kieruje nowe połączenia do wystąpień w pozostałych strefach w dobrej kondycji.

Diagram przedstawiający strefowo nadmiarową Azure usługę SignalR, rozłożoną na wiele stref dostępności.

Wymagania

  • Obsługa regionów: Nadmiarowość strefy jest obsługiwana w większości regionów, w których obowiązują oba te warunki:

    • Azure SignalR Service jest dostępny. Aby uzyskać listę regionów, w których usługa jest dostępna, zobacz Dostępność produktu według regionów.
    • Region obsługuje strefy dostępności. Aby uzyskać listę regionów ze strefami dostępności, zobacz listę regionów Azure.

    Jednak Japonia Zachodnia nie obsługuje obecnie redundancji strefowej dla usługi Azure SignalR.

  • Poziom: Redundancja strefowa jest dostępna w poziomie Premium.

Cost

Redundancja strefowa nie powoduje dodatkowych kosztów i płacisz standardową stawkę pakietu Premium. Aby uzyskać więcej informacji, zobacz cennik Azure SignalR Service.

Konfiguruj obsługę stref dostępności

Redundancja stref nie wymaga konfiguracji poza wybraniem poziomu Premium. Jest ona automatycznie włączona w obu tych przypadkach:

  • Utwórz nowy zasób usługi SignalR redundantny strefowo. Wybierz jednostkę SKU warstwy Premium podczas tworzenia zasobu. Aby uzyskać więcej informacji, zobacz szybkie starty, takie jak Quickstart: Tworzenie pokoju rozmów przy użyciu SignalR Service.

  • Uaktualnij istniejący zasób do warstwy Premium. Nadmiarowość strefowa jest automatycznie włączana podczas aktualizacji istniejącego zasobu do SKU warstwy Premium. Uaktualnienie z Standardowej do Premium nie powoduje przestoju usługi. Aby uzyskać więcej informacji, zobacz Zmień warstwę Azure SignalR Service.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania zasobu Azure SignalR Service dla redundancji strefy, gdy wszystkie strefy dostępności są operacyjne.

  • Cross-zone operation: Azure SignalR Service automatycznie zarządza sposobem dystrybucji połączeń i operacji między strefami dostępności. Infrastruktura w wielu strefach przetwarza ruch w modelu aktywny-aktywny. Nie musisz konfigurować żadnych elementów, aby korzystać z tego zachowania. Usługa automatycznie kieruje komunikaty między wystąpieniami w różnych strefach, więc komunikat wysyłany przez klienta w jednej strefie jest dostarczany do klientów połączonych w dowolnej innej strefie.

  • Replikacja danych między strefami: Azure SignalR Service nie utrwala danych klientów, więc nie ma danych do replikacji między strefami. Stan połączenia jest efemeryczny i jest skojarzony z każdym aktywnym połączeniem.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania zasobu Azure SignalR Service na potrzeby redundantności strefowej w przypadku awarii w jednej ze stref dostępności.

  • Detection i reakcja: platforma Azure SignalR Service jest odpowiedzialna za wykrywanie awarii w strefie dostępności. Nie musisz podejmować żadnych akcji w celu zainicjowania trybu failover strefy.

  • Aktywne żądania: Podczas awarii strefy aktywne połączenia z węzłami w strefie, której dotyczy problem, są porzucane. Jeśli klienci odpowiednio obsługują błędy przejściowe, na przykład przez ponowne połączenie po krótkim czasie, zwykle unikają znaczących konsekwencji.

  • Expected data loss: Azure SignalR Service nie utrwala komunikatów, więc nie oczekuje się, że awaria strefy spowoduje utratę danych w Azure SignalR service. Jednak wszystkie aktywne połączenia są zrywane podczas zdarzenia obniżenia strefy i dlatego wszelkie dane, które są aktywnie przesyłane, mogą zostać utracone.

  • Oczekiwany przestój: Ponowne łączenie porzuconych aktywnych połączeń zwykle trwa kilka sekund. Klienci, którzy implementują logikę ponownego łączenia, doświadczają minimalnych zakłóceń.

  • Redistribution: Azure SignalR Service wykrywa utratę strefy i automatycznie dystrybuuje ruch w strefach w dobrej kondycji. Nie musisz podejmować żadnych działań.

Odzyskiwanie strefy

Gdy strefa dostępności zostaje odzyskana, Azure SignalR Service automatycznie ponownie umieszcza ją w aktywnej topologii usługi. Nie trzeba wykonywać żadnych akcji na potrzeby odzyskiwania strefy.

Po odzyskaniu strefy nowe połączenia mogą być kierowane do infrastruktury w odzyskanej strefie. Żadne istniejące połączenia nie zostaną przeniesione ani ponownie zrównoważone do odzyskanej strefy, ale zostaną one stopniowo ponownie zrównoważone w miarę porzucania istniejących połączeń i ponownego nawiązywania połączenia w miarę upływu czasu. Brak równowagi połączeń między strefami nie ma żadnego wpływu na obciążenie.

Testowanie pod kątem niepowodzeń strefy

Azure SignalR Service automatycznie zarządza routingiem ruchu, trybem failover i odzyskiwaniem strefy dla zasobów warstwy Premium strefowo nadmiarowej. Nie musisz nic inicjować. Ponieważ nadmiarowość strefy dostępności jest w pełni zarządzana, nie trzeba weryfikować procesów na wypadek awarii strefy dostępności.

Odporność na awarie całego regionu

Azure SignalR Service jest usługą jednoregionową. Jeśli region stanie się niedostępny, zasób SignalR Service jest również niedostępny.

Aby chronić aplikację przed awarią całego regionu, możesz użyć replikacji geograficznej, która jest dostępna w warstwie Premium. Alternatywnie możesz utworzyć niestandardowe rozwiązanie wieloregionowe, wdrażając wiele zasobów SignalR Service w różnych regionach.

Geo-replication

Replikacja geograficzna umożliwia dodanie replik zasobu usługi SignalR w innych regionach Azure. Azure Traffic Manager używa routingu opartego na systemie DNS, aby skierować każdego klienta do najbliższej repliki regionalnej w dobrej kondycji. Jeśli region ulegnie awarii, usługa Traffic Manager wykryje błąd za pośrednictwem kontroli kondycji i przestanie kierować klientów do tej repliki. Nowe połączenia klienta są automatycznie kierowane do najbliższej zdrowej repliki.

Diagram przedstawiający Azure SignalR Service skonfigurowany do replikacji geograficznej w dwóch regionach.

Region, w którym utworzono zasób Azure SignalR Service, jest nazywany regionem primary a jego repliką jest replika primary. Płaszczyzna kontroli zasobu podstawowego zarządza konfiguracją zasobu Azure SignalR Service.

Wymagania

  • Region support: Repliki można dodawać w dowolnym regionie, w którym jest dostępna Azure SignalR Service.
  • Warstwy: Aby włączyć replikację geograficzną, należy użyć warstwy Premium.
  • Limit replik: Każdy podstawowy zasób usługi SignalR obsługuje maksymalnie osiem replik.

Zagadnienia do rozważenia

  • Dziedziczenie konfiguracji: Repliki dziedziczą większość ustawień konfiguracji z zasobu podstawowego. Niektóre ustawienia muszą być konfigurowane oddzielnie w każdej repliki. Aby uzyskać pełną listę ustawień, które nie są dziedziczone, zobacz Geo-replication w Azure SignalR Service.

  • Zmiany konfiguracji: Podstawowa płaszczyzna sterowania w regionie podstawowym przetwarza wszelkie zmiany konfiguracji zasobu SignalR Service. Jeśli podstawowa płaszczyzna sterowania jest niedostępna, nie będzie można zaktualizować konfiguracji zasobów, chociaż istniejące repliki będą nadal przetwarzać ruch danych bez przerwy.

Cost

Każda replika jest rozliczana oddzielnie na podstawie własnej liczby jednostek i woluminu komunikatów wychodzących. Opłaty za ruch między regionami mają zastosowanie, gdy wiadomości są przesyłane między replikami i dostarczane do klientów lub serwerów w innym regionie. Aby uzyskać więcej informacji, zobacz cennik Azure SignalR Service.

Konfigurowanie replikacji geograficznej

Aby dodać lub usunąć replikę do zasobu SignalR Service, zobacz Geo-replication w Azure SignalR Service.

Planowanie pojemności i zarządzanie nimi

Każda replika obsługuje ruch niezależnie. Podczas awarii regionalnej klienci z regionu, w którym wystąpił błąd, ponownie nawiązują połączenie z najbliższą działającą poprawnie repliką. Aby upewnić się, że pozostałe repliki mają wystarczającą pojemność dla przejęcia dodatkowego obciążenia, należy skonfigurować każdą replikę tak, aby jej jednostki mogły obsłużyć cały spodziewany ruch, a nie tylko tę część, którą normalnie obsługuje.

Alternatywnie, włącz skalowanie automatyczne dla każdej repliki, aby mogły one skalować się poziomo w odpowiedzi na zwiększone obciążenie. Skalowanie automatyczne nadal działa, gdy replika pomocnicza jest niedostępna, ale skalowanie automatyczne nie działa, jeśli podstawowa płaszczyzna sterowania jest niedostępna. Aby uzyskać więcej informacji na temat skalowania automatycznego, zobacz Autoscaling w Azure SignalR Service.

Aby uzyskać ogólne wskazówki dotyczące nadaprowizacji jako strategii, zobacz Zarządzanie pojemnością przez nadaprowizację.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania Azure SignalR Service na potrzeby replikacji geograficznej, a wszystkie repliki działają.

  • Operacja międzyregionowa: Azure Traffic Manager kieruje każdego klienta do najbliższej działającej repliki regionalnej. Użytkownicy w różnych obszarach geograficznych mogą łączyć się z różnymi replikami. SignalR Service synchronizuje komunikaty między replikami, aby klienci połączeni z dowolną repliką mogli komunikować się ze sobą.

  • Replikacja danych między regionami: Po wysłaniu komunikatu do repliki usługa synchronicznie przesyła ten komunikat do innych replik, aby klienci połączeni gdzie indziej mogli je odbierać. Obciążenie synchronizacji jest minimalne dla najbardziej typowych wzorców komunikacji, takich jak emisja do dużych grup lub komunikacja z pojedynczym połączeniem. Obsługa komunikatów w małych grupach (mniej niż 10 członków) może spowodować nieco wyższe obciążenie związane z synchronizacją.

    Azure SignalR Service nie utrwala komunikatów; tylko aktywne dostarczanie jest synchronizowane między replikami.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania Azure SignalR Service na potrzeby replikacji geograficznej i awarii w jednym z regionów repliki.

  • Wykrywanie i reagowanie: Usługa SignalR odpowiada za wykrywanie awarii w regionie i automatyczne przekierowanie przychodzącego ruchu do repliki w jednym z innych, skonfigurowanych przez Ciebie regionów.
  • Powiadomienie: Firma Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Można jednak użyć Azure Service Health, aby zrozumieć ogólną kondycję usługi, w tym awarie regionów, i skonfigurować alerty Service Health w celu powiadomienia o problemach.

  • Aktywne żądania: Aktywne połączenia z repliką w regionie, który zakończył się niepowodzeniem, są porzucane. Użytkownicy muszą ponownie nawiązać połączenie, gdy replika przechodzi w tryb awaryjny.

  • Spodziewana utrata danych: Usługa Azure SignalR nie zachowuje wiadomości. Komunikaty przesyłane do klientów w regionie, w którym wystąpił błąd, mogą zostać utracone. Nie oczekuje się trwałej utraty danych, ponieważ usługa nie przechowuje danych klientów.

  • Oczekiwany czas przestoju: Azure Traffic Manager wykonuje kontrolę stanu każdej repliki. Gdy awaria regionu powoduje, że replika nie zdaje testu kondycji, usługa Traffic Manager usuwa z wyników rozpoznawania nazw DNS punkt końcowy tej repliki. Po usunięciu punktu końcowego, musi upłynąć czas TTL DNS wynoszący 90 sekund, zanim klienci zobaczą zaktualizowane rekordy DNS. W sumie przejście zwykle trwa kilka minut. Dobrze zaprojektowani klienci, którzy implementują logikę ponownego łączenia, mogą wznowić normalne działanie po ponownym połączeniu ze zdrową repliką.

    Jeśli podstawowa płaszczyzna sterowania jest niedostępna, nie można wprowadzić żadnych zmian w konfiguracji zasobu SignalR Service ani jego replik. Jednak połączenia nadal działają w sprawnych replikach.

  • Redistribution: Azure Traffic Manager kieruje żądania przychodzące do replik w dobrej kondycji. Jeśli jednak klient próbuje ponownie połączyć się, zanim Azure Traffic Manager wykryje przełączenie awaryjne repliki i zanim zaktualizowane wpisy DNS zostaną rozpropagowane do klienta, próba ponownego połączenia się klienta może nadal dotyczyć niedostępnego obszaru i może zakończyć się niepowodzeniem.

    Po propagacji aktualizacji DNS ponownie łączący się klienci są automatycznie kierowani do najbliższej zdrowej repliki.

Odzyskiwanie regionów

Gdy nieudany region zostanie odzyskany, usługa Traffic Manager wykrywa przywróconą replikę i ponownie uwzględnia punkt końcowy w rozpoznawaniu DNS. Obecnie połączeni klienci z innymi replikami nie są dotknięci i pozostają połączeni do rozłączenia. Nowe połączenia są ponownie kierowane do repliki odzyskanego regionu, gdy jest to najbliższa zdrowa replika.

Testowanie pod kątem błędów regionów

Aby zasymulować awarię regionu i przetestować działanie aplikacji klienckiej podczas ponownego łączenia, możesz wyłączyć punkt końcowy repliki. Ta akcja powoduje zatrzymanie routingu ruchu do tej repliki przez usługę Traffic Manager, co pozwala obserwować zachowanie klientów, gdy replika, z którą nawiązują połączenie, staje się niedostępna. Aby uzyskać szczegółowe instrukcje, zobacz Wyłączanie lub włączanie punktu końcowego repliki.

Niestandardowe rozwiązania obejmujące wiele regionów w celu zapewnienia odporności

Jeśli potrzebujesz odporności między regionami, ale nie używasz replikacji geograficznej, możesz wdrożyć oddzielne zasoby SignalR Service w wielu regionach i wdrożyć własną logikę trybu failover na serwerze aplikacji i zarządzać nimi. Takie podejście jest bardziej złożone niż replikacja geograficzna i nie obsługuje przełączenia awaryjnego bez przestojów dla połączeń między klientami. Aby uzyskać szczegółowe omówienie architektury, wzorce trybu failover i wskazówki dotyczące testowania, zobacz Odporność i odzyskiwanie po awarii w Azure SignalR Service.

Tworzenie kopii zapasowej i przywracanie

Azure SignalR Service to bezstanowa usługa obsługi komunikatów. Nie utrwala komunikatów klientów i nie ma możliwości tworzenia kopii zapasowej ani przywracania.

Aby chronić konfigurację zasobu, zdefiniuj zasoby SignalR Service przy użyciu infrastruktury jako kod (takiej jak Bicep lub szablony ARM) i zapisz te definicje w systemie kontroli wersji. Jeśli musisz ponownie utworzyć zasób, ponownie wdróż go z przechowywanej konfiguracji.

Odporność usługi na prace konserwacyjne

Firma Microsoft regularnie stosuje aktualizacje usług i wykonuje inną konserwację. Platforma Azure automatycznie obsługuje te działania, zapewniając bezproblemową i przejrzystą konserwację. Podczas zdarzeń konserwacji nie przewiduje się przestoju, chyba że poinformowano Cię o zaplanowanej konserwacji Azure Service Health.

Podczas planowanej konserwacji Azure SignalR Service używa strategii bezpiecznego zamykania, aby zmniejszyć wpływ na połączonych klientów. Połączenia są stopniowo rozłączane w określonym przedziale czasu, dzięki czemu klienci mogą ponownie łączyć się stopniowo, a nie jednocześnie. Aby uzyskać więcej informacji, zobacz Rozłączenia podczas konserwacji usługi.

Zdarzenia konserwacji są udostępniane klientom w miarę przerywania połączenia. Upewnij się, że aplikacje klienckie implementują logikę ponownego łączenia, aby umożliwić odzyskiwanie po rozłączeniach związanych z konserwacją bez widocznych dla użytkownika przerw.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

Treści powiązane

  • Last updated on