Rugalmasság és vészhelyreállítás az Azure Web PubSub Service-ben

Cikk
10/26/2023

Az online rendszerek általános szükséglete a rugalmasság és a vészhelyreállítás. Az Azure Web PubSub Service már 99,9%-os rendelkezésre állást garantál, de továbbra is regionális szolgáltatás. Régiószintű kimaradás esetén kritikus fontosságú, hogy a szolgáltatás továbbra is feldolgozhassa a valós idejű üzeneteket egy másik régióban.

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 marad, és nincs kódmódosítás. Részletekért tekintse meg a georeplikációs adatokat.
Több végpont használata. Ebből a dokumentumból megtudhatja, hogyan teheti ezt meg

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

A Web PubSub szolgáltatást két tipikus minta használja:

Az egyik az ügyfél-kiszolgáló minta, amely szerint az ügyfelek eseményeket küldenek a kiszolgálónak , a kiszolgáló pedig üzeneteket küld az ügyfeleknek.
Egy másik az ügyfél-ügyfél minta, amelyet az ügyfelek a Web PubSub szolgáltatáson keresztül más ügyfeleknek küldnek.

Az alábbi szakaszok a vészhelyreállítás e két mintájának különböző módjait ismertetik

Magas rendelkezésre állású architektúra az ügyfél-kiszolgáló mintához

Ahhoz, hogy a Web PubSub szolgáltatás régióközi rugalmasságot biztosíthasson, 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ó.

A régiók közötti forgatókönyvek egyik jellemző beállítása, hogy két (vagy több) pár Web PubSub szolgáltatáspéldányt és alkalmazáskiszolgálót használnak.

Az egyes párosított alkalmazáskiszolgálókon és a Web PubSub szolgáltatáson belül ugyanabban a régióban található, és a Web PubSub szolgáltatás az eseménykezelőt az adott régióban lévő alkalmazáskiszolgálóra állítja.

Az architektúra jobb szemléltetéséhez a Web PubSub szolgáltatást hívjuk elsődleges szolgáltatásnak az alkalmazáskiszolgálóhoz ugyanabban a párban. A Web PubSub-szolgáltatásokat pedig más párokban másodlagos szolgáltatásként hívjuk az alkalmazáskiszolgálónak.

Az alkalmazáskiszolgáló a Service Health Check API használatával észlelheti, hogy az elsődleges és másodlagos szolgáltatásai kifogástalan állapotban vannak-e. Egy Web PubSub nevű demoszolgáltatás esetében például a végpont https://demo.webpubsub.azure.com/api/health 200-t ad vissza, ha a szolgáltatás kifogástalan állapotú. Az alkalmazáskiszolgáló rendszeresen meghívhatja a végpontokat, vagy igény szerint meghívhatja a végpontokat annak ellenőrzéséhez, hogy a végpontok kifogástalan állapotban vannak-e. A WebSocket-ügyfelek általában először az alkalmazáskiszolgálóval egyeztetnek , hogy megkapják a Web PubSub szolgáltatáshoz csatlakozó URL-címet, és az alkalmazás ezt a egyeztetési lépést használja az ügyfelek más kifogástalan másodlagos szolgáltatásokra való feladatátvételéhez. Részletes lépések az alábbiak szerint:

Amikor egy ügyfél egyeztet az alkalmazáskiszolgálóval, az alkalmazáskiszolgálónak csak elsődleges Web PubSub szolgáltatásvégpontokat kell visszaadnia, így normál esetben az ügyfelek csak elsődleges végpontokhoz csatlakoznak.
Ha az elsődleges példány le van állítva, a negotiate SHOULD egy kifogástalan másodlagos végpontot ad vissza, hogy az ügyfél továbbra is kapcsolatokat létesítsen, és az ügyfél csatlakozik a másodlagos végponthoz.
Ha az elsődleges példány fel van állítva, az egyeztetésNEK az kifogástalan elsődleges végpontot kell visszaadnia, hogy az ügyfelek most már csatlakozni tudjanak az elsődleges végponthoz
Amikor az alkalmazáskiszolgáló közvetítiaz üzeneteket, az üzeneteket az összes kifogástalan végpontra kell küldenie, beleértve az elsődleges és a másodlagos végpontot is.
Az alkalmazáskiszolgáló bezárhatja a másodlagos végpontokhoz csatlakozó kapcsolatokat, hogy kényszerítse az ügyfeleket az kifogástalan elsődleges végponthoz való újracsatlakoztatásra.

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 a Web PubSub szolgáltatáspéldány összekapcsolva van.

Még nem integráltuk a stratégiát az SDK-ba, ezért az alkalmazásnak egyelőre önmagában kell implementálnia ezt a stratégiát.

Összefoglalva, az alkalmazásoldalnak a következőt kell implementálnia:

Állapot-ellenőrzés. Az alkalmazás rendszeresen ellenőrizheti, hogy a szolgáltatás kifogástalan állapotú-e a service health check API-val a háttérben, vagy igény szerint minden egyeztetési híváshoz.
Egyeztetési logika. Az alkalmazás alapértelmezés szerint kifogástalan elsődleges végpontot ad vissza. Ha az elsődleges végpont le van állítva, az alkalmazás kifogástalan másodlagos végpontot ad vissza.
Szórási logika. Ha az üzeneteket több ügyfélnek küldi el, az alkalmazásnak gondoskodnia kell arról, hogy az üzeneteket az összes kifogástalan állapotú végpontra közvetítse.

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

Diagram shows two regions each with an app server and a Web PubSub service, where each server is associated with the Web PubSub service in its region as primary and with the service in the other region as secondary.

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 Web PubSub 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):

Az elsődleges szolgáltatáspéldány leállt, az ehhez a példányhoz csatlakoztatott összes ügyfél elvetve lesz.
Új ügyfelek vagy az ügyfél újracsatlakoztatása egyeztetés az alkalmazáskiszolgálóval
Az alkalmazáskiszolgáló észleli, hogy az elsődleges szolgáltatáspéldány le van állítva, és az egyeztetés leállítja a végpont visszaadását és egy kifogástalan másodlagos végpont visszaadását.
Az ügyfelek másodlagos példányhoz csatlakoznak.
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–kiszolgáló eseményüzeneteket azonban csak az ugyanabban a régióban lévő felsőbb rétegbeli alkalmazáskiszolgálóra küldi a rendszer.
Az elsődleges példány helyreállítása és az online állapot visszaállítása után az alkalmazáskiszolgáló észleli, hogy az elsődleges példány újra kifogástalan állapotba kerül. Az egyeztetés most ismét visszaadja az elsődleges végpontot, így az új ügyfelek újra csatlakoznak az elsődlegeshez. A meglévő ügyfelek azonban nem lesznek elvetve, és továbbra is csatlakoznak a másodlagoshoz, amíg le nem választják magukat.

Az alábbi ábrák a feladatátvétel menetét szemléltetik:

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

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

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

Normál esetben csak az elsődleges alkalmazáskiszolgáló és a Web PubSub szolgáltatás rendelkezik online forgalommal (kék színnel).

A feladatátvétel után a másodlagos alkalmazáskiszolgáló és a Web PubSub szolgáltatás is aktívvá válik. Miután az elsődleges Web PubSub szolgáltatás újra online állapotba kerül, az új ügyfelek csatlakoznak az elsődleges Web PubSubhoz. 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:

Az első az, hogy egy pár app server és Web PubSub 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).
A másik az, hogy két (vagy több) pár alkalmazáskiszolgálóval és Web PubSub 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árok számára (az úgynevezett aktív/aktív, a 3. ábrához hasonlóan).

A Web PubSub 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 Web PubSub szolgáltatás is aktív/passzív lesz (mivel az elsődleges alkalmazáskiszolgáló csak az elsődleges Web PubSub szolgáltatáspéldányát adja vissza). Ha az alkalmazáskiszolgálók aktívak/aktívak, a Web PubSub szolgáltatás is aktív/aktív lesz (mivel minden alkalmazáskiszolgáló saját elsődleges Web PubSub-példányokat ad vissza, így mindegyik képes lesz a forgalom lekérésére).

Nem számít, hogy milyen mintákat használ, az egyes Web PubSub-szolgáltatáspéldányokat elsődleges szerepkörként egy alkalmazáskiszolgálóhoz kell csatlakoztatnia.

A WebSocket-kapcsolat jellege miatt (ez egy hosszú kapcsolat) az ügyfeleknél a kapcsolat megszakadását tapasztalják, 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.

Magas rendelkezésre állású architektúra ügyfél-ügyfél mintához

Ügyfél-ügyfél minta esetén jelenleg még nem lehet támogatni a nulla állásidős vészhelyreállítást több példány használatával. Ha magas rendelkezésre állási követelményekkel rendelkezik, fontolja meg a georeplikációs szolgáltatás használatát.

Feladatátvétel tesztelése

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

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.
Indítsa újra az elsődleges erőforrást.