Rugalmasság és vészhelyreállítás az Azure SignalR Szolgáltatásban

Az online rendszerek általános szükséglete a rugalmasság és a vészhelyreállítás. Az Azure SignalR szolgáltatás már 99,9%-os rendelkezésre állást biztosít, de továbbra is regionális szolgáltatás. Régiószintű kimaradás esetén a szolgáltatáspéldány nem felel meg a feladatátvételnek egy másik régióban, mert mindig az egy régióban fut.

A regionális vészhelyreállításhoz a következő két módszert javasoljuk:

• Georeplikációs funkció engedélyezése (egyszerű módszer). Ez a funkció automatikusan kezeli a regionális feladatátvételt. Ha engedélyezve van, csak egy Azure SignalR-példány van, és nincs kódmódosítás. Részletekért tekintse meg a georeplikációs adatokat.
• Több végpont használata a Service SDK-ban. A szolgáltatási SDK több SignalR-szolgáltatáspéldányt is támogat, és automatikusan átvált más példányokra, ha egyes példányok nem érhetők el. Ezzel a funkcióval vészhelyreállítást hozhat létre, de saját maga kell beállítania a megfelelő rendszertopológiát. Ebből a dokumentumból megtudhatja, hogyan teheti meg.

Magas rendelkezésre állású architektúra a SignalR szolgáltatáshoz

A SignalR szolgáltatás régióközi rugalmasságának biztosításához több szolgáltatáspéldányt kell beállítania különböző régiókban. Így ha az egyik régió le van állítva, a többi biztonsági mentésként is használható. Ha az alkalmazáskiszolgálók több szolgáltatáspéldányhoz csatlakoznak, két szerepkör van: elsődleges és másodlagos. Az elsődleges egy olyan példány, amely az online forgalom fogadásáért felelős, a másodlagos pedig tartalék példányként szolgál, amely teljes mértékben működőképes. Az SDK-implementációban az egyeztetés csak az elsődleges végpontokat adja vissza, így az ügyfelek csak normál esetekben csatlakoznak az elsődleges végpontokhoz. Ha azonban az elsődleges példány le van állítva, az egyeztetés másodlagos végpontokat ad vissza, így az ügyfél továbbra is létesíthet kapcsolatokat. Az elsődleges példány és az alkalmazáskiszolgáló normál kiszolgálói kapcsolatokon keresztül csatlakozik, de a másodlagos példány és az alkalmazáskiszolgáló egy speciális, gyenge kapcsolatnak nevezett kapcsolaton keresztül csatlakozik. A gyenge kapcsolat egyik megkülönböztető jellemzője, hogy nem tudja elfogadni az ügyfélkapcsolat útválasztását a másodlagos példány helye miatt egy másik régióban. Az ügyfél másik régióba történő átirányítása nem optimális választás (növeli a késést).

Egy szolgáltatáspéldánynak különböző szerepkörei lehetnek több alkalmazáskiszolgálóhoz való csatlakozáskor. A régiók közötti forgatókönyvek egyik tipikus beállítása, ha két vagy több pár SignalR-szolgáltatáspéldányt és alkalmazáskiszolgálót használ. Minden pár alkalmazáskiszolgálón és SignalR-szolgáltatáson belül ugyanabban a régióban található, és a SignalR szolgáltatás elsődleges szerepkörként csatlakozik az alkalmazáskiszolgálóhoz. Az egyes párok között az alkalmazáskiszolgáló és a SignalR szolgáltatás is csatlakozik, de a SignalR másodlagossá válik, amikor egy másik régióban lévő kiszolgálóhoz csatlakozik.

Ezzel a topológiával az egy kiszolgálóról érkező üzenetek továbbra is kézbesíthetők az összes ügyfélnek, mivel az összes alkalmazáskiszolgáló és SignalR-szolgáltatáspéldány összekapcsolva van. Ha azonban egy ügyfél csatlakozik, az ugyanabban a régióban található alkalmazáskiszolgálóra irányítja az optimális hálózati késés elérése érdekében.

Az alábbi ábra az ilyen topológiát szemlélteti:

Több SignalR-szolgáltatáspéldány konfigurálása

Több SignalR-szolgáltatáspéldány is támogatott az alkalmazáskiszolgálókon és az Azure Functionsben.

Miután létrehozta a SignalR szolgáltatást és az alkalmazáskiszolgálókat/Az Azure Functionst minden régióban, konfigurálhatja az alkalmazáskiszolgálókat/az Azure Functionst az összes SignalR-szolgáltatáspéldányhoz való csatlakozáshoz.

Konfigurálás alkalmazáskiszolgálókon

Kétféleképpen teheti meg:

Konfigurálás útján

Már tudnia kell, hogyan állíthatja be a SignalR szolgáltatás kapcsolati sztring környezeti változókon/alkalmazásbeállításokon/web.cofig-on keresztül egy konfigurációs bejegyzésbenAzure:SignalR:ConnectionString. Ha több végpontja van, több konfigurációs bejegyzésben is beállíthatja őket, mindegyik a következő formátumban:

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

A Csatlakozás ionStringben <name> a végpont neve és <role> szerepe (elsődleges vagy másodlagos). A név megadása nem kötelező, de akkor hasznos, ha több végpont között szeretné tovább testre szabni az útválasztási viselkedést.

Kódon keresztül

Ha inkább valahol máshol szeretné tárolni a kapcsolati sztring, akkor a kódban is elolvashatja őket, és paraméterekként használhatja őket híváskor AddAzureSignalR() (ASP.NET Core-ban) vagy MapAzureSignalR() (ASP.NET).

Íme a mintakód:

ASP.NET Core:

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

ASP.NET:

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

Több elsődleges vagy másodlagos példányt is konfigurálhat. Ha több elsődleges és/vagy másodlagos példány van, az egyeztetés egy végpontot ad vissza a következő sorrendben:

1. Ha legalább egy elsődleges példány van online, egy véletlenszerű elsődleges online példányt ad vissza.
2. Ha az összes elsődleges példány leállt, egy véletlenszerű másodlagos online példányt ad vissza.

Konfigurálás az Azure Functionsben

Lásd ezt a cikket.

Feladatátvételi sorrend és ajánlott eljárás

Most már rendelkezik a megfelelő rendszertopológia beállításával. Amikor egy SignalR szolgáltatáspéldány leáll, az online forgalom más példányokra lesz irányítva. A következők történnek, ha egy elsődleges példány leáll (és egy idő után helyreáll):

1. Az elsődleges szolgáltatáspéldány leállt, a példány összes kiszolgálókapcsolata megszakad.
2. A példányhoz csatlakoztatott összes kiszolgáló offlineként jelöli meg, és az egyeztetés leállítja a végpont visszaadását és a másodlagos végpont visszatérését.
3. Ezen a példányon az összes ügyfélkapcsolat is bezárul, az ügyfelek ezután újracsatlakoznak. Mivel az alkalmazáskiszolgálók most másodlagos végpontot adnak vissza, az ügyfelek a másodlagos példányhoz csatlakoznak.
4. Most a másodlagos példány minden online forgalmat átvesz. A kiszolgálóról az ügyfelekre érkező összes üzenet továbbra is kézbesíthető, mivel a másodlagos az összes alkalmazáskiszolgálóhoz csatlakozik. Az ügyfél és a kiszolgáló közötti üzenetek azonban csak ugyanabban a régióban lévő alkalmazáskiszolgálóra lesznek irányítva.
5. Az elsődleges példány helyreállítása és online állapotba helyezése után az alkalmazáskiszolgáló újra létrehozza a kapcsolatot vele, és onlineként jelöli meg. Az egyeztetés most ismét az elsődleges végpontot adja vissza, így az új ügyfelek újra csatlakoznak az elsődlegeshez. A meglévő ügyfelek azonban nem esnek le, és továbbra is másodlagosra vannak irányítva, amíg le nem választják magukat.

Az alábbi ábrák bemutatják, hogyan történik a feladatátvétel a SignalR szolgáltatásban:

1. ábra feladatátvétel előtt

2. ábra feladatátvétel után

3. ábra: Rövid idő az elsődleges helyreállítás után

Normál esetben csak az elsődleges alkalmazáskiszolgáló és a SignalR szolgáltatás rendelkezik online forgalommal (kék színnel). A feladatátvétel után a másodlagos alkalmazáskiszolgáló és a SignalR szolgáltatás is aktívvá válik. Miután az elsődleges SignalR szolgáltatás újra online állapotba kerül, az új ügyfelek csatlakoznak az elsődleges SignalR-hez. A meglévő ügyfelek azonban továbbra is a másodlagoshoz csatlakoznak, így mindkét példány forgalommal rendelkezik. Miután az összes meglévő ügyfél megszakadt, a rendszer visszaáll a normál állapotra (1. ábra).

A régiók közötti magas rendelkezésre állású architektúra megvalósításának két fő mintája van:

1. Az első az, hogy egy pár app server és SignalR szolgáltatáspéldány veszi az összes online forgalmat, és egy másik pár biztonsági mentés (az úgynevezett aktív/passzív, illusztrált ábra 1).
2. A másik az, hogy két (vagy több) pár alkalmazáskiszolgálóval és SignalR-szolgáltatáspéldánysal kell rendelkeznie, amelyek mindegyike részt vesz az online forgalomban, és biztonsági mentésként szolgál más párokhoz (az úgynevezett aktív/aktív, a 3. ábrához hasonlóan).

A SignalR szolgáltatás mindkét mintát támogatja, a fő különbség az alkalmazáskiszolgálók implementálása. Ha az alkalmazáskiszolgálók aktívak/passzívak, a SignalR szolgáltatás is aktív/passzív (mivel az elsődleges alkalmazáskiszolgáló csak az elsődleges SignalR szolgáltatáspéldányát adja vissza). Ha az alkalmazáskiszolgálók aktívak/aktívak, a SignalR szolgáltatás is aktív/aktív (mivel minden alkalmazáskiszolgáló saját elsődleges SignalR-példányokat ad vissza, így mindegyik képes a forgalom lekérésére).

Ne feledje, hogy a használni kívánt mintáktól függetlenül minden SignalR-szolgáltatáspéldányt elsődlegesként egy alkalmazáskiszolgálóhoz kell csatlakoztatnia.

A SignalR-kapcsolat jellege miatt (ez egy hosszú kapcsolat) az ügyfelek azt tapasztalják, hogy a kapcsolat megszakad, amikor katasztrófa történik, és feladatátvétel történik. Az ilyen eseteket ügyféloldalon kell kezelnie, hogy átlátható legyen a végfelhasználók számára. Például egy kapcsolat bezárása után újracsatlakozik.

Feladatátvétel tesztelése

A feladatátvétel aktiválásához kövesse az alábbi lépéseket:

1. A portál elsődleges erőforrásának Hálózatkezelés lapján tiltsa le a nyilvános hálózati hozzáférést. Ha az erőforrás rendelkezik engedélyezett privát hálózatokkal, hozzáférés-vezérlési szabályokkal tiltsa le az összes forgalmat.
2. Indítsa újra az elsődleges erőforrást.

Következő lépések

Ebben a cikkben megtanulta, hogyan konfigurálhatja az alkalmazást a SignalR szolgáltatás rugalmasságának eléréséhez. A SignalR szolgáltatásban a kiszolgáló-/ügyfélkapcsolattal és a kapcsolat-útválasztással kapcsolatos további részletekért olvassa el ezt a cikket a SignalR szolgáltatás belső hálózatairól.

Olyan méretezési forgatókönyvek esetében, mint a több példányt együtt használó horizontális horizontális skálázás, amely nagy számú kapcsolat kezelésére szolgál, olvassa el , hogyan skálázhat több példányt.

Az Azure Functions több SignalR-szolgáltatáspéldánysal való konfigurálásáról további információt az Azure Functions több Azure SignalR-szolgáltatáspéldányának támogatásában talál.