Replikacja geograficzna w usłudze Azure SignalR

Firmy, które szukają lokalnej obecności lub wymagają niezawodnego systemu trybu failover, często decydują się na wdrażanie usług w wielu regionach świadczenia usługi Azure. Dzięki integracji replikacji geograficznej w usłudze Azure SignalR zarządzanie scenariuszami obejmującymi wiele regionów stało się znacznie łatwiejsze.

Zalety korzystania z replikacji geograficznej

• Większa odporność na awarię regionalną: jeśli wystąpi awaria regionalna, system DNS usługi Azure SignalR zostanie rozpoznany jako repliki w dobrej kondycji w innych regionach.
• Komunikacja między regionami. Różne repliki mogą komunikować się ze sobą tak, jakby były one tym samym wystąpieniem.
• Zwiększona szybkość sieci: geograficznie rozproszeni klienci będą łączyć się z najbliższą repliką. Te repliki komunikują się za pośrednictwem globalnej sieci szkieletowej platformy Azure, zapewniając szybką i stabilną sieć.
• Konfiguracje udostępnione. Wszystkie repliki zachowują konfigurację podstawowego zasobu usługi Azure SignalR Service.

Wymagania wstępne

• Usługa Azure SignalR Service w warstwie Premium.

Przykładowy przypadek użycia

Contoso to firma zajmująca się mediami społecznościowymi, która ma swoją bazę klientów w Stanach Zjednoczonych i Kanadzie. Aby obsłużyć tych klientów i umożliwić im komunikowanie się ze sobą, firma Contoso uruchamia swoje usługi w regionie Środkowe stany USA. Usługa Azure SignalR Service służy do obsługi połączeń użytkowników i ułatwiania komunikacji między użytkownikami. Użytkownicy końcowi firmy Contoso są głównie użytkownikami telefonów. Ze względu na duże odległości geograficzne użytkownicy końcowi w Kanadzie mogą doświadczać dużych opóźnień i niskiej jakości sieci.

Przed pojawieniem się funkcji replikacji geograficznej firma Contoso może skonfigurować inną usługę Azure SignalR Service w Kanadzie Central, aby obsługiwać swoich kanadyjskich użytkowników. Konfigurując geograficznie bliżej usługi Azure SignalR Service, użytkownicy końcowi mają teraz lepszą jakość sieci i mniejsze opóźnienia.

Jednak zarządzanie wieloma usługami Azure SignalR Services wiąże się z pewnymi wyzwaniami:

1. Aby umożliwić konwersację między użytkownikami Kanady i USA, wymagany byłby mechanizm komunikacji między regionami.
2. Zespół deweloperów musi zarządzać dwoma oddzielnymi usługami Azure SignalR Services, z których każda ma odrębną domenę i parametry połączenia.
3. Jeśli wystąpi awaria regionalna, ruch musi zostać przełączony do innego regionu.

Korzystanie z replikacji geograficznej

Dzięki nowej funkcji replikacji geograficznej firma Contoso może teraz ustanowić replikę w Kanadzie Środkowej, skutecznie przekonując powyższe przeszkody.

Tworzenie repliki usługi SignalR

Portal

Aby utworzyć replikę, przejdź do bloku Repliki usługi SignalR w witrynie Azure Portal i kliknij przycisk Dodaj, aby utworzyć replikę. Zostanie ona automatycznie włączona po utworzeniu.

Po utworzeniu można wyświetlić/edytować replikę w portalu, klikając nazwę repliki.

Bicep

Użyj programu Visual Studio Code lub ulubionego edytora, aby utworzyć plik z następującą zawartością i nadaj mu nazwę main.bicep:

@description('The name for your SignalR service')
param primaryName string = 'contoso'

@description('The region in which to create your SignalR service')
param primaryLocation string = 'eastus'

@description('Unit count of your SignalR service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/signalr@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your SignalR replica')
param replicaName string = 'contoso-westus'

@description('The region in which to create the SignalR replica')
param replicaLocation string = 'westus'

@description('Unit count of the SignalR replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/signalr/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

Wdrażanie pliku Bicep przy użyciu interfejsu wiersza polecenia platformy Azure

az group create --name MyResourceGroup --location eastus
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

Uwaga

• Liczba replik jest obecnie ograniczona do maksymalnie 8 na zasób podstawowy.

Cennik i jednostka zasobów

Każda replika ma własną i unit autoscale settings.

Replica to funkcja warstwy Premium usługi Azure SignalR Service. Każda replika jest rozliczana oddzielnie zgodnie z własną jednostką i ruchem wychodzącym. Bezpłatny limit przydziału komunikatów jest również obliczany oddzielnie.

W poprzednim przykładzie firma Contoso dodała jedną replikę w Kanadzie Środkowej. Firma Contoso zapłaci za replikę w Kanadzie Środkowej zgodnie z jednostką i komunikatem w cenie Premium.

Opłaty za ruch wychodzący między regionami będą naliczane. Jeśli komunikat zostanie przeniesiony między replikami i pomyślnie wysłany do klienta lub serwera po przeniesieniu, zostanie on rozliczone jako komunikat wychodzący.

Usuwanie repliki

Po utworzeniu repliki dla usługi Azure SignalR Service możesz usunąć ją w dowolnym momencie, jeśli nie jest już potrzebna.

Aby usunąć replikę w witrynie Azure Portal:

1. Przejdź do usługi Azure SignalR Service i wybierz blok Repliki . Kliknij replikę, którą chcesz usunąć.
2. Kliknij przycisk Usuń w bloku przeglądu repliki.

Dowiedz się, jak działa replika SignalR

Na poniższym diagramie przedstawiono krótką ilustrację funkcji replik usługi SignalR:

1. Klient negocjuje z serwerem aplikacji i otrzymuje przekierowanie do usługi Azure SignalR. Następnie rozpoznaje w pełni kwalifikowaną nazwę domeny (FQDN) usługi SignalR — contoso.service.signalr.net. Ta nazwa FQDN wskazuje usługę Traffic Manager, która zwraca nazwę kanoniczną (CNAME) najbliższego regionalnego wystąpienia usługi SignalR.
2. W przypadku tego rekordu CNAME klient nawiązuje połączenie z wystąpieniem regionalnym (Replica).
3. Dwie repliki będą synchronizować dane ze sobą. W razie potrzeby komunikaty wysyłane do jednej repliki zostaną przeniesione do innych replik.
4. W przypadku niepowodzenia repliki kontroli kondycji przeprowadzonej przez usługę Traffic Manager (TM), TM wykluczy punkt końcowy wystąpienia, który zakończył się niepowodzeniem z procesu rozpoznawania domeny. Aby uzyskać szczegółowe informacje, zapoznaj się z poniższymi informacjami na temat odporności i odzyskiwania po awarii

Uwaga

• W płaszczyźnie danych podstawowy zasób usługi Azure SignalR działa identycznie z replikami

Odporność i odzyskiwanie po awarii

Usługa Azure SignalR Service korzysta z usługi Traffic Manager na potrzeby kontroli kondycji i rozpoznawania nazw DNS w odniesieniu do replik. W normalnych okolicznościach, gdy wszystkie repliki działają prawidłowo, klienci będą kierowani do najbliższej repliki. Przykład:

• Klienci blisko zostaną przekierowani eastus do repliki znajdującej się w eastuslokalizacji .
• Podobnie klienci blisko westus zostaną przekierowani do repliki w programie westus.

W przypadku awarii regionalnej w regionie eastus (zilustrowanym poniżej) menedżer ruchu wykryje błąd kontroli kondycji dla tego regionu. Następnie system DNS tej wadliwej repliki zostanie wykluczony z wyników rozpoznawania nazw DNS usługi Traffic Manager. Po upływie czasu wygaśnięcia systemu DNS (TTL), który jest ustawiony na 90 sekund, klienci w programie eastus zostaną przekierowani w celu nawiązania połączenia z repliką w programie westus.

Po rozwiązaniu problemu eastus i powrocie regionu do trybu online kontrola kondycji zakończy się pomyślnie. Klienci w programie eastus będą następnie po raz kolejny kierowani do repliki w ich regionie. To przejście jest bezproblemowe, ponieważ połączone klienci nie będą mieć wpływu na te istniejące połączenia, dopóki te istniejące połączenia nie zostaną zamknięte.

Ten proces przechodzenia w tryb failover i odzyskiwania jest automatyczny i nie wymaga ręcznej interwencji.

W przypadku połączeń serwera tryb failover i odzyskiwanie działają tak samo jak w przypadku połączeń klienckich.

Uwaga

• Ten mechanizm trybu failover jest przeznaczony dla usługi Azure SignalR. Regionalne awarie serwera aplikacji wykraczają poza zakres tego dokumentu.

Wyłączanie lub włączanie punktu końcowego repliki

Podczas konfigurowania repliki możesz włączyć lub wyłączyć jego punkt końcowy. Jeśli jest ona wyłączona, rozpoznawanie nazw DNS podstawowej nazwy FQDN nie będzie zawierać repliki, a zatem ruch nie będzie kierowany do niej.

Możesz również włączyć wyłączenie punktu końcowego po jego utworzeniu. W bloku replik zasobów podstawowych kliknij przycisk wielokropka po prawej stronie repliki i wybierz pozycję Włącz punkt końcowy lub Wyłącz punkt końcowy:

Przed usunięciem replikacji rozważ najpierw wyłączenie punktu końcowego. W czasie istniejące połączenia zostaną rozłączone. W miarę zbliżania się nowych połączeń replikacja stanie się w końcu bezczynna. Zapewnia to bezproblemowy proces usuwania.

Ta funkcja jest również przydatna do rozwiązywania problemów regionalnych.

Uwaga

• Ze względu na pamięć podręczną DNS może upłynąć kilka minut, aby aktualizacja DNS weszła w życie.
• Istniejące połączenia pozostają bez wpływu, dopóki nie zostaną rozłączone.

Wpływ na wydajność po dodaniu replik

Po włączeniu replik klienci będą naturalnie dystrybuować na podstawie ich lokalizacji geograficznych. Usługa SignalR przejmuje odpowiedzialność za synchronizowanie danych między tymi replikami, ale wiesz, że związane z nim obciążenie związane z obciążeniem serwera jest minimalne w przypadku najczęstszych przypadków użycia.

W szczególności, jeśli aplikacja zazwyczaj emituje do większych grup (rozmiar >10) lub pojedynczego połączenia, wpływ synchronizacji na wydajność jest ledwo zauważalny. Jeśli wiadomości są małymi grupami (rozmiar < 10) lub poszczególnymi użytkownikami, możesz zauważyć nieco większe obciążenie związane z synchronizacją.

Aby zapewnić efektywne zarządzanie trybem failover, zaleca się ustawienie rozmiaru jednostki każdej repliki w celu obsługi całego ruchu. Alternatywnie można włączyć skalowanie automatyczne, aby zarządzać tym rozwiązaniem.

Aby uzyskać więcej oceny wydajności, zobacz Wydajność.

Konfiguracje nie dziedziczone i dziedziczone

Repliki dziedziczą większość konfiguracji z zasobu podstawowego; jednak niektóre ustawienia muszą być konfigurowane bezpośrednio w replikach. Poniżej znajduje się lista tych konfiguracji:

1. Jednostka SKU: Każda replika ma własną nazwę jednostki SKU i rozmiar jednostki. Reguły skalowania automatycznego dla replik muszą być konfigurowane oddzielnie na podstawie poszczególnych metryk.
2. Współużytkowane prywatne punkty końcowe: chociaż współużytkowane prywatne punkty końcowe są automatycznie replikowane do replik, oddzielne zatwierdzenia są wymagane w docelowych zasobach łącza prywatnego. Aby dodać lub usunąć udostępnione prywatne punkty końcowe, zarządzaj nimi w zasobie podstawowym. Nie włączaj repliki do momentu zatwierdzenia udostępnionego prywatnego punktu końcowego.
3. Ustawienia lokalizacji docelowej dziennika. Jeśli repliki nie zostaną skonfigurowane, zostaną przeniesione tylko dzienniki z zasobu podstawowego.
4. Alerty.

Wszystkie inne konfiguracje są dziedziczone z zasobu podstawowego. Na przykład klucze dostępu, tożsamość, zapora aplikacji, domeny niestandardowe, prywatne punkty końcowe i kontrola dostępu.