Geografická replikace v Azure SignalR

Společnosti, které hledají místní přítomnost nebo vyžadují robustní systém převzetí služeb při selhání, se často rozhodnou nasazovat služby napříč několika oblastmi Azure. Díky integraci geografické replikace ve službě Azure SignalR se výrazně zjednodušila správa scénářů ve více oblastech.

Výhody použití geografické replikace

• Odolnější vůči oblastnímu výpadku: Pokud dojde k regionálnímu výpadku, dns služby Azure SignalR se přeloží na repliky v pořádku v jiných oblastech.
• Komunikace mezi oblastmi Různé repliky můžou vzájemně komunikovat, jako by byly stejné instance.
• Zvýšená rychlost sítě: Geograficky rozptýlení klienti se budou připojovat k nejbližší replice. Tyto repliky komunikují prostřednictvím páteřní sítě Azure a zajišťují rychlou a stabilní síť.
• Sdílené konfigurace. Všechny repliky uchovávají primární konfiguraci prostředku služby Azure SignalR Service.

Požadavky

• Služba Azure SignalR na úrovni Premium.

Příklad případu použití

Contoso je společnost sociálních médií se svou zákaznickou základnou rozloženou do USA a Kanady. Aby společnost Contoso těmto zákazníkům sloužila a nechala je vzájemně komunikovat, provozuje své služby v oblasti USA – střed. Služba Azure SignalR se používá ke zpracování uživatelských připojení a usnadnění komunikace mezi uživateli. Koncoví uživatelé společnosti Contoso jsou většinou telefonními uživateli. Vzhledem k dlouhým zeměpisným vzdálenostem můžou koncoví uživatelé v Kanadě zaznamenat vysokou latenci a nízkou kvalitu sítě.

Před nástupem funkce geografické replikace může společnost Contoso nastavit jinou službu Azure SignalR v Kanadě Central tak, aby sloužila svým kanadským uživatelům. Když nastavíte geograficky blíže službu Azure SignalR, koncoví uživatelé teď mají lepší kvalitu sítě a nižší latenci.

Správa více služeb Azure SignalR ale přináší několik výzev:

1. Aby bylo možné komunikovat mezi Kanadou a uživateli USA, je potřeba mechanismus komunikace mezi oblastmi.
2. Vývojový tým by potřeboval spravovat dvě samostatné služby Azure SignalR, z nichž každý má odlišnou doménu a připojovací řetězec.
3. Pokud dojde k výpadku oblasti, provoz se musí přepnout do jiné oblasti.

Využití geografické replikace

Díky nové funkci geografické replikace teď společnost Contoso může vytvořit repliku v Kanadě – střed a efektivně tak překonat výše uvedené překážky.

Vytvoření repliky SignalR

Azure Portal

Pokud chcete vytvořit repliku, přejděte do okna Repliky služby SignalR na webu Azure Portal a kliknutím na Přidat vytvořte repliku. Při vytváření se automaticky povolí.

Po vytvoření byste mohli repliku zobrazit nebo upravit na portálu kliknutím na název repliky.

Bicep

Pomocí editoru Visual Studio Code nebo oblíbeného editoru vytvořte soubor s následujícím obsahem a pojmenujte ho 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
  }
}

Nasazení souboru Bicep pomocí Azure CLI

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

Poznámka:

• Počet replik je aktuálně omezen na maximálně 8 na primární prostředek.

Ceny a jednotka prostředků

Každá replika má vlastní unit a autoscale settings.

Replika je funkce úrovně Premium služby Azure SignalR. Každá replika se účtuje samostatně podle vlastní jednotky a odchozího provozu. Kvóta bezplatných zpráv se také počítá samostatně.

V předchozím příkladu společnost Contoso přidala jednu repliku v Kanadě – střed. Společnost Contoso bude platit za repliku v Kanadě Central podle své jednotky a zprávy v ceně Premium.

U odchozích přenosů mezi oblastmi se budou účtovat poplatky za odchozí přenosy dat. Pokud je zpráva přenesena mezi replikami a úspěšně odeslána klientovi nebo serveru po přenosu, bude se fakturovat jako odchozí zpráva.

Odstranění repliky

Jakmile vytvoříte repliku pro službu Azure SignalR, můžete ji kdykoli odstranit, pokud už ji nepotřebujete.

Odstranění repliky na webu Azure Portal:

1. Přejděte do služby Azure SignalR a vyberte okno Repliky . Klikněte na repliku, kterou chcete odstranit.
2. V okně přehledu repliky klikněte na tlačítko Odstranit.

Vysvětlení fungování repliky SignalR

Následující diagram obsahuje stručný obrázek funkčnosti replik služby SignalR:

1. Klient vyjedná s aplikačním serverem a obdrží přesměrování do služby Azure SignalR. Pak přeloží plně kvalifikovaný název domény (FQDN) služby SignalR – contoso.service.signalr.net. Tento plně kvalifikovaný název domény odkazuje na Traffic Manager, který vrátí Canonical Name (CNAME) nejbližší místní instance SignalR.
2. Pomocí tohoto CNAME klient vytvoří připojení k místní instanci (replika).
3. Obě repliky vzájemně synchronizují data. Zprávy odeslané do jedné repliky se v případě potřeby přenesou do jiných replik.
4. V případě, že replika selže při kontrole stavu provedené traffic managerem (TM), TM vyloučí koncový bod neúspěšné instance z procesu překladu domény. Podrobnosti najdete v následujících článcích o odolnosti a zotavení po havárii.

Poznámka:

• V rovině dat funguje primární prostředek Azure SignalR stejně jako jeho repliky.

Odolnost a zotavení po havárii

Služba Azure SignalR využívá traffic manager ke kontrole stavu a překladu DNS ve svých replikách. Za normálních okolností budou klienti přesměrováni na nejbližší repliku, pokud všechny repliky fungují správně. Například:

• Klienti blízko eastus budou přesměrováni na repliku umístěnou v eastusumístění .
• Podobně se klienti blízko westus budou směrovat na repliku v .westus

V případě regionálního výpadku v oblasti eastus (viz níže) traffic manager zjistí selhání kontroly stavu pro danou oblast. Poté bude dns této vadné repliky vyloučeno z výsledků překladu DNS traffic manageru. Po době trvání TTL (Time to Live) DNS, která je nastavena na 90 sekund, budou klienti přesměrováni eastus na připojení s replikou v westus.

Jakmile se problém eastus vyřeší a oblast je zase online, kontrola stavu proběhne úspěšně. Klienti pak eastus budou znovu přesměrováni na repliku ve své oblasti. Tento přechod je hladký, protože připojení klienti nebudou ovlivněni, dokud nebudou tato stávající připojení uzavřena.

Tento proces převzetí služeb při selhání a obnovení je automatický a nevyžaduje žádný ruční zásah.

U připojení k serveru funguje převzetí služeb při selhání a obnovení stejným způsobem jako u připojení klientů.

Poznámka:

• Tento mechanismus převzetí služeb při selhání je určený pro službu Azure SignalR. Regionální výpadky aplikačního serveru jsou nad rámec tohoto dokumentu.

Zakázání nebo povolení koncového bodu repliky

Při nastavování repliky máte možnost povolit nebo zakázat jeho koncový bod. Pokud je zakázaný, překlad DNS primárního plně kvalifikovaného názvu domény nebude obsahovat repliku, a proto se na ni nebude směrovat provoz.

Koncový bod můžete také povolit po jeho vytvoření. V okně replik primárního prostředku klikněte na tlačítko se třemi tečkami na pravé straně repliky a zvolte Povolit koncový bod nebo Zakázat koncový bod:

Před odstraněním replikace nejprve zvažte zakázání jeho koncového bodu. V průběhu času se stávající připojení odpojí. Vzhledem k tomu, že nepřicházejí žádná nová připojení, replikace se nakonec stane nečinnou. Tím se zajistí bezproblémový proces odstranění.

Tato funkce je užitečná také pro řešení potíží v jednotlivých oblastech.

Poznámka:

• Vzhledem k mezipaměti DNS může trvat několik minut, než se aktualizace DNS projeví.
• Stávající připojení zůstávají nedotčená, dokud se neodpojí.

Dopad na výkon po přidání replik

Po povolení replik se klienti přirozeně distribuují na základě jejich geografických umístění. I když služba SignalR přebírá odpovědnost za synchronizaci dat napříč těmito replikami, budete rádi, že související režie při načítání serveru je minimální pro nejběžnější případy použití.

Konkrétně pokud vaše aplikace obvykle vysílá větší skupiny (velikost >10) nebo jediné připojení, dopad synchronizace na výkon je sotva patrný. Pokud posíláte zprávy malým skupinám (velikost < 10) nebo jednotlivým uživatelům, můžete si všimnout trochu větší režie synchronizace.

Pokud chcete zajistit efektivní správu převzetí služeb při selhání, doporučujeme nastavit velikost jednotky každé repliky pro zpracování veškerého provozu. Případně můžete povolit automatické škálování pro správu.

Další vyhodnocení výkonu najdete v tématu Výkon.

Neděděné a zděděné konfigurace

Repliky dědí většinu konfigurací z primárního prostředku; Některá nastavení však musí být nakonfigurovaná přímo na replikách. Níže je seznam těchto konfigurací:

1. Skladová položka: Každá replika má vlastní název skladové položky a velikost jednotky. Pravidla automatického škálování pro repliky musí být nakonfigurovaná samostatně na základě jejich jednotlivých metrik.
2. Sdílené privátní koncové body: Sdílené privátní koncové body se automaticky replikují do replik, u cílových prostředků privátního propojení se vyžadují samostatná schválení. Pokud chcete přidat nebo odebrat sdílené privátní koncové body, spravujte je v primárním prostředku. Nepovolujte repliku, dokud nebude schválen její sdílený privátní koncový bod.
3. Nastavení cíle protokolu. Pokud nejsou nakonfigurované na replikách, budou přeneseny pouze protokoly z primárního prostředku.
4. Výstrahy.

Všechny ostatní konfigurace se dědí z primárního prostředku. Například přístupové klíče, identita, firewall aplikací, vlastní domény, privátní koncové body a řízení přístupu.