Odolnost a zotavení po havárii ve službě Azure SignalR

Odolnost a zotavení po havárii jsou běžnou potřebou online systémů. Služba Azure SignalR už poskytuje 99,9% dostupnost, ale stále se jedná o regionální službu. Pokud dojde k výpadku celé oblasti, instance služby nepřejde do jiné oblasti, protože je vždy spuštěná v jedné oblasti.

Pro regionální zotavení po havárii doporučujeme následující dva přístupy:

• Povolte geografickou replikaci (snadný způsob). Tato funkce automaticky zpracovává místní převzetí služeb při selhání. Pokud je tato možnost povolená, existuje pouze jedna instance Azure SignalR a nejsou zavedeny žádné změny kódu. Podrobnosti najdete v geografické replikaci .
• Využití více koncových bodů v sadě SDK služby Naše sada SDK služby podporuje více instancí služby SignalR a automaticky se přepne na jiné instance, pokud některé z nich nejsou k dispozici. Díky této funkci se můžete zotavit, když dojde k havárii, ale musíte nastavit správnou topologii systému sami. V tomto dokumentu se dozvíte, jak to udělat.

Architektura s vysokou dostupností pro službu SignalR

Pokud chcete zajistit odolnost mezi oblastmi pro službu SignalR, musíte nastavit více instancí služby v různých oblastech. Takže když je jedna oblast mimo provoz, ostatní je možné použít jako zálohu. Když se aplikační servery připojují k více instancím služby, existují dvě role, primární a sekundární. Primární je instance zodpovědná za příjem online provozu, zatímco sekundární slouží jako záložní instance, která je plně funkční. V naší implementaci sady SDK vyjednávejte pouze primární koncové body, takže se klienti připojují pouze k primárním koncovým bodům v normálních případech. Když je ale primární instance v výpadku, vyjednávejte sekundární koncové body, aby klient stále mohl vytvářet připojení. Primární instance a aplikační server jsou připojené přes normální připojení k serveru, ale sekundární instance a aplikační server jsou připojené prostřednictvím speciálního typu připojení nazývaného slabé připojení. Jednou z charakteristických vlastností slabého připojení je to, že nemůže přijmout směrování připojení klienta kvůli umístění sekundární instance v jiné oblasti. Směrování klienta do jiné oblasti není optimální volbou (zvyšuje latenci).

Jedna instance služby může mít při připojování k více aplikačním serverům různé role. Jedním z typických nastavení scénáře napříč oblastmi je mít dva nebo více dvojic instancí služby SignalR a aplikačních serverů. Uvnitř každého párového aplikačního serveru a služby SignalR se nacházejí ve stejné oblasti a služba SignalR je připojená k aplikačnímu serveru jako primární role. Mezi jednotlivými dvojicemi aplikačního serveru a službou SignalR jsou také připojeny, ale SignalR se stane sekundární při připojování k serveru v jiné oblasti.

Díky této topologii se zprávy z jednoho serveru stále dají doručit všem klientům, protože všechny aplikační servery a instance služby SignalR jsou vzájemně propojené. Když je ale klient připojený, směruje se na aplikační server ve stejné oblasti, aby dosáhl optimální latence sítě.

Následující diagram znázorňuje takovou topologii:

Konfigurace několika instancí služby SignalR

Na aplikačních serverech i ve službě Azure Functions se podporuje několik instancí služby SignalR.

Jakmile budete mít službu SignalR a aplikační servery / Azure Functions vytvořené v každé oblasti, můžete nakonfigurovat aplikační servery nebo Azure Functions tak, aby se připojily ke všem instancím služby SignalR.

Azure:SignalR:ConnectionString:<name>:<role>

services.AddSignalR()
        .AddAzureSignalR(options => options.Endpoints = new ServiceEndpoint[]
        {
            new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
            new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
        });

app.MapAzureSignalR(GetType().FullName, hub,  options => options.Endpoints = new ServiceEndpoint[]
    {
        new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
        new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
    };

dotnet user-secrets set Azure:SignalR:Endpoints:east-region-a <ConnectionString1>
dotnet user-secrets set Azure:SignalR:Endpoints:east-region-b:primary <ConnectionString2>
dotnet user-secrets set Azure:SignalR:Endpoints:backup:secondary <ConnectionString3>

var serviceManager = new ServiceManagerBuilder()
                    .WithOptions(option =>
                    {
                        options.Endpoints = new ServiceEndpoint[]
                        {
                            // Note: this is just a demonstration of how to set options.Endpoints
                            // Having ConnectionStrings explicitly set inside the code is not encouraged
                            // You can fetch it from a safe place such as Azure KeyVault
                            new ServiceEndpoint("<ConnectionString0>"),
                            new ServiceEndpoint("<ConnectionString1>", type: EndpointType.Primary, name: "east-region-a"),
                            new ServiceEndpoint("<ConnectionString2>", type: EndpointType.Primary, name: "east-region-b"),
                            new ServiceEndpoint("<ConnectionString3>", type: EndpointType.Secondary, name: "backup"),
                        };
                    })
                    .BuildServiceManager();

Posloupnost převzetí služeb při selhání a osvědčený postup

Teď máte správnou systémovou topologii. Kdykoli je jedna instance služby SignalR mimo provoz, online provoz se směruje do jiných instancí. Tady je postup, co se stane, když je primární instance mimo provoz (a po nějaké době se obnoví):

1. Primární instance služby je v provozu, všechna připojení k serveru v tomto výpadku.
2. Všechny servery připojené k této instanci ho označí jako offline a vyjednávají, že tento koncový bod nevrátí a začnou vracet sekundární koncový bod.
3. Všechna připojení klientů v této instanci jsou také uzavřena, klienti se pak znovu připojují. Vzhledem k tomu, že aplikační servery teď vrací sekundární koncový bod, klienti se připojují k sekundární instanci.
4. Teď sekundární instance přebírá veškerý online provoz. Všechny zprávy ze serveru do klientů se stále dají doručovat, protože sekundární jsou připojené ke všem aplikačním serverům. Zprávy klienta na server se ale směrují jenom na aplikační server ve stejné oblasti.
5. Jakmile se primární instance obnoví a znovu online, aplikační server k ní znovu publikuje připojení a označí ho jako online. Funkce Negotiate teď vrátí znovu primární koncový bod, aby se noví klienti připojili zpět k primárnímu. Stávající klienti se ale neodpojí a stále se směrují do sekundární oblasti, dokud se neodpojí.

Následující diagramy znázorňují, jak se provádí převzetí služeb při selhání ve službě SignalR:

Obr.1 Před převzetím služeb při selhání

Obr.2 Po převzetí služeb při selhání

Obr.3 Krátký čas po obnovení primárního

V normálním případě se můžete podívat jenom na primární aplikační server a službu SignalR mají online provoz (modře). Po převzetí služeb při selhání se aktivuje také sekundární aplikační server a služba SignalR. Jakmile bude primární služba SignalR opět online, budou se noví klienti připojovat k primární službě SignalR. Stávající klienti se ale stále připojují k sekundárnímu, takže obě instance mají provoz. Po odpojení všech stávajících klientů se váš systém vrátí do normálního stavu (obr. 1).

Implementace architektury s vysokou dostupností napříč oblastmi má dva hlavní vzory:

1. První z nich je mít dvojici aplikačního serveru a instance služby SignalR, která přebírá veškerý online provoz, a má další dvojici jako zálohu (označovanou jako aktivní/pasivní, znázorněná na obr. 1).
2. Druhým je mít dva (nebo více) dvojic aplikačních serverů a instancí služby SignalR, z nichž každá je součástí online provozu a slouží jako záloha pro jiné páry (označované jako aktivní/aktivní, podobně jako obr. 3).

Služba SignalR může podporovat oba vzory, hlavním rozdílem je způsob implementace aplikačních serverů. Pokud jsou aplikační servery aktivní/pasivní, služba SignalR je také aktivní/pasivní (protože primární aplikační server vrací pouze primární instanci služby SignalR). Pokud jsou aplikační servery aktivní/aktivní, služba SignalR je také aktivní/aktivní (protože všechny aplikační servery vrací své vlastní primární instance SignalR, takže všechny z nich můžou získat provoz).

Je třeba poznamenat, bez ohledu na to, jaké vzory se rozhodnete použít, musíte připojit každou instanci služby SignalR k aplikačnímu serveru jako primární.

Vzhledem k povaze připojení SignalR (je to dlouhé připojení) dochází také k poklesu připojení klientů, když dojde k havárii a převzetí služeb při selhání. Tyto případy musíte zpracovat na straně klienta, aby byly pro koncové zákazníky transparentní. Po zavření připojení se například znovu připojte.

Jak otestovat převzetí služeb při selhání

Postupujte podle kroků pro aktivaci převzetí služeb při selhání:

1. Na kartě Sítě pro primární prostředek na portálu zakažte přístup k veřejné síti. Pokud má prostředek povolenou privátní síť, zamítejte veškerý provoz pomocí pravidel řízení přístupu.
2. Restartujte primární prostředek.

Další kroky

V tomto článku jste zjistili, jak nakonfigurovat aplikaci tak, aby zajistila odolnost služby SignalR. Další podrobnosti o připojení k serveru nebo klientovi a směrování připojení ve službě SignalR najdete v tomto článku pro interní informace o službě SignalR.

Pro scénáře škálování, jako je horizontální dělení, které používá více instancí dohromady ke zpracování velkého počtu připojení, se dozvíte , jak škálovat více instancí.

Podrobnosti o tom, jak nakonfigurovat Službu Azure Functions s několika instancemi služby SignalR, najdete v tématu podpora několika instancí služby Azure SignalR ve službě Azure Functions.