Azure Service Bus Geo-vészhelyreállítás

Az adatfeldolgozási erőforrások katasztrofális kimaradásokkal szembeni rugalmassága számos vállalat számára követelmény, és bizonyos esetekben még az iparági szabályozások is megkövetelik.

Az Azure Service Bus már magában hordozza az egyes gépek vagy akár teljes állványok katasztrofális hibáinak kockázatát az adatközponton belüli több hibatartományt felölelő fürtök között, és transzparens hibaészlelési és feladatátvételi mechanizmusokat implementál, hogy a szolgáltatás továbbra is a biztosított szolgáltatási szinteken belül működjön, és általában észrevehető megszakítások nélkül, amikor ilyen hibák történnek. A prémium szintű névtér két vagy több üzenetkezelési egységből áll, és ezek az üzenetkezelési egységek egy adatközpont több meghibásodási tartományában is el vannak osztva, támogatva egy teljes körű Service Bus-fürtmodellt.

A prémium szintű névtér esetében a kimaradás kockázata tovább oszlik három fizikailag elkülönített létesítményben (rendelkezésre állási zónákban), és a szolgáltatás elegendő kapacitással rendelkezik ahhoz, hogy azonnal megbirkózzon egy adatközpont teljes, katasztrofális veszteségével. A hibatartományon belüli, mindenre aktív Azure Service Bus-fürtmodell és a rendelkezésre állási zóna támogatása minden helyszíni üzenetközvetítő terméknél jobb a súlyos hardverhibákkal szembeni rugalmasság, sőt akár a teljes adatközpont-létesítmények katasztrofális elvesztése esetén is. Mégis lehetnek olyan súlyos helyzetek, amikor a fizikai pusztítás széles körben elterjedt, és még ezek a mértékek sem képesek megfelelően védekezni ellen.

A Service Bus georedundáns helyreállítási funkciója úgy lett kialakítva, hogy megkönnyítse az ilyen mértékű katasztrófák utáni helyreállítást, és hogy az alkalmazáskonfigurációk módosítása nélkül is elhagyjon egy meghibásodott Azure-régiót. Az Azure-régió elhagyása általában több szolgáltatást is magában foglal, és ez a funkció elsősorban az összetett alkalmazáskonfiguráció integritásának megőrzését célozza. A szolgáltatás globálisan elérhető a Service Bus Premium termékváltozathoz.

A Geo-Vészhelyreállítás funkció biztosítja, hogy egy névtér (üzenetsorok, témakörök, előfizetések, szűrők) teljes konfigurációja folyamatosan replikálva legyen az elsődleges névtérből egy másodlagos névtérbe párosítva, és lehetővé teszi, hogy bármikor egyszeri feladatátvételt kezdeményezze az elsődlegesről a másodlagosra. A feladatátvétel a névtér kiválasztott aliasnevét a másodlagos névtérre irányítja át, majd megszakítja a párosítást. A feladatátvétel a kezdeményezést követően szinte azonnal megtörténik.

Fontos tudnivalók

• A funkció lehetővé teszi az azonos konfigurációjú műveletek azonnali folytonosságát, de nem replikálja az üzenetsorokban, témakör-előfizetésekben vagy kézbesítetlen levelek üzenetsoraiban tárolt üzeneteket. Az üzenetsor szemantikájának megőrzése érdekében az ilyen replikációhoz nem csak az üzenetadatok replikálására van szükség, hanem a közvetítő minden állapotváltozására is. A legtöbb Service Bus-névtér esetében a szükséges replikációs forgalom messze meghaladná az alkalmazás forgalmát, és nagy átviteli sebességű üzenetsorok esetén a legtöbb üzenet továbbra is a másodlagosra replikálódik, miközben az elsődlegesről már törölve vannak, ami túlzottan pazarló forgalmat okoz. A georedukciós vészhelyreállításhoz választott számos párosításra érvényes nagy késésű replikációs útvonalak esetében a replikációs forgalom a késés által okozott szabályozási hatások miatt nem képes fenntarthatóan lépést tartani az alkalmazás forgalmával.
• A Microsoft Entra szerepköralapú hozzáférés-vezérlési (RBAC) hozzárendelései az elsődleges névtérBen lévő Service Bus-entitásokhoz nem replikálódnak a másodlagos névtérbe. A másodlagos névtérben manuálisan hozhat létre szerepkör-hozzárendeléseket a hozzájuk való hozzáférés biztonságossá tételéhez.
• A következő konfigurációk nem replikálódnak.
  • Virtuális hálózati konfigurációk
  • Privátvégpont-kapcsolatok
  • Minden hálózat hozzáférése engedélyezve van
  • A megbízható szolgáltatáshozzáférés engedélyezve van
  • Nyilvános hálózati hozzáférés
  • Alapértelmezett hálózati művelet
  • Identitások és titkosítási beállítások (ügyfél által felügyelt kulcstitkosítás vagy saját kulcs (BYOK) titkosítása)
  • Automatikus skálázás engedélyezése
  • Helyi hitelesítés letiltása
• A particionált névtér nem particionált névtérrel való párosítása nem támogatott.
• Ha AutoDeleteOnIdle egy entitás engedélyezve van, előfordulhat, hogy az entitás nem szerepel a másodlagos névtérben a feladatátvétel során. Amikor a másodlagos elsődleges lesz az utolsó hozzáférési állapot, amely nem része a metaadatoknak, nem lesz elérhető az új elsődleges számára, és az entitás törölhető a törlés részeként AutoDeleteOnIdle .

Tipp.

Az üzenetsorok és témakör-előfizetések tartalmának replikálásához, valamint a megfelelő névterek aktív/aktív konfigurációkban való működtetéséhez a kimaradások és a katasztrófák kezelése érdekében ne támaszkodjon erre a Geo-vészhelyreállítási funkciókészletre, hanem kövesse a replikációs útmutatót.

Üzemkimaradások és katasztrófák

Fontos megjegyezni a "kimaradások" és a "katasztrófák" közötti különbséget.

A kimaradás az Azure Service Bus ideiglenes elérhetetlensége, amely hatással lehet a szolgáltatás bizonyos összetevőire, például egy üzenetkezelő tárolóra vagy akár a teljes adatközpontra. A probléma kijavítása után azonban a Service Bus ismét elérhetővé válik. A kimaradás általában nem okozza az üzenetek vagy más adatok elvesztését. Ilyen kimaradás lehet például az adatközpont áramkimaradása. Egyes kimaradások csak rövid kapcsolatvesztések átmeneti vagy hálózati problémák miatt.

A katasztrófa a Service Bus-fürt, az Azure-régió vagy az adatközpont állandó vagy hosszabb távú vesztesége. Előfordulhat, hogy a régió vagy az adatközpont ismét elérhetővé válik, vagy órákig vagy napokig nem érhető el. Ilyen katasztrófák például a tűz, az áradás vagy a földrengés. Az állandóvá váló katasztrófa egyes üzenetek, események vagy egyéb adatok elvesztését okozhatja. A legtöbb esetben azonban nem lehet adatvesztés, és az adatközpont biztonsági mentése után az üzenetek helyreállíthatók.

Az Azure Service Bus georeduktúra-helyreállítási funkciója egy vészhelyreállítási megoldás. A cikkben ismertetett fogalmak és munkafolyamatok a vészforgatókönyvekre vonatkoznak, és nem az átmeneti vagy átmeneti kimaradásokra. A Microsoft Azure vészhelyreállításának részletes ismertetését ez a cikk ismerteti.

Alapfogalmak és kifejezések

A vészhelyreállítási funkció metaadatok vészhelyreállítását valósítja meg, és az elsődleges és másodlagos vészhelyreállítási névterekre támaszkodik. A Geo-vészhelyreállítás funkció csak a Prémium termékváltozathoz érhető el. Nem kell kapcsolati sztring módosításokat végeznie, mivel a kapcsolat aliason keresztül történik.

Ebben a cikkben a következő kifejezéseket használjuk:

• Alias: A beállított vészhelyreállítási konfiguráció neve. Az alias egyetlen stabil, teljes tartománynevet (FQDN) kapcsolati sztring biztosít. Az alkalmazások ezt az aliast kapcsolati sztring használják egy névtérhez való csatlakozáshoz. Az alias használata biztosítja, hogy a kapcsolati sztring a feladatátvétel aktiválásakor ne változik.

• Elsődleges/másodlagos névtér: Az aliasnak megfelelő névterek. Az elsődleges névtér "aktív", és üzeneteket fogad (lehet meglévő vagy új névtér). A másodlagos névtér "passzív", és nem fogad üzeneteket. A metaadatok mindkettő között szinkronban vannak, így mindkettő zökkenőmentesen fogadhatja az üzeneteket alkalmazáskód vagy kapcsolati sztring módosítások nélkül. Ahhoz, hogy csak az aktív névtér fogadjon üzeneteket, az aliast kell használnia.

• Metaadatok: Entitások, például üzenetsorok, témakörök és előfizetések, valamint a névtérhez társított szolgáltatás tulajdonságai. Csak az entitások és beállításaik replikálódnak automatikusan. Az üzenetek nem replikálódnak.

• Feladatátvétel: A másodlagos névtér aktiválásának folyamata.

Beállítás

Az alábbi szakasz áttekintést nyújt a névterek közötti párosítás beállításához.

Először létrehoz vagy használ egy meglévő elsődleges névteret és egy új másodlagos névteret, majd párosítja a kettőt. Ez a párosítás egy aliast biztosít, amellyel csatlakozhat. Mivel aliast használ, nem kell módosítania a kapcsolati sztring. A feladatátvételi párosításhoz csak új névterek vehetők fel.

1. Hozza létre az elsődleges prémium szintű névteret.

2. Hozza létre a másodlagos prémium szintű névteret egy másik régióban. Ez a lépés nem kötelező. A következő lépésben a párosítás létrehozása közben létrehozhatja a másodlagos névteret.

3. Az Azure Portalon keresse meg az elsődleges névteret.

4. A bal oldali menüben válassza a Georeduktúra lehetőséget, majd az eszköztáron válassza a Párosítás kezdeményezése lehetőséget.

   

5. A Párosítás kezdeményezése lapon kövesse az alábbi lépéseket:

   1. Válasszon ki egy meglévő másodlagos névteret, vagy hozzon létre egyet egy másik régióban. Ebben a példában a rendszer egy meglévő névteret használ másodlagos névtérként.

   2. Az Alias mezőben adjon meg egy aliast a geo-dr párosításhoz.

   3. Ezután kattintson a Létrehozás elemre.

      

6. A Service Bus Geo-DR Alias lapjának az alábbi képen látható módon kell megjelennie. Az elsődleges névtérlapról a Geo-DR Alias lapra is navigálhat a bal oldali menü Geo-helyreállítási elemének kiválasztásával.

   

7. A Geo-DR Alias lapon válassza a megosztott hozzáférési szabályzatokat a bal oldali menüben az alias elsődleges kapcsolati sztring eléréséhez. Használja ezt a kapcsolati sztring ahelyett, hogy közvetlenül az elsődleges/másodlagos névtérbe használná a kapcsolati sztring. Az alias kezdetben az elsődleges névtérre mutat.

8. Váltson az Áttekintés lapra. A következő műveleteket hajthatja végre:

   1. Megszakítja a párosítást az elsődleges és a másodlagos névterek között. Válassza a Töréspárosítás lehetőséget az eszköztáron.
   2. Manuális feladatátvétel a másodlagos névtérbe.

      1. Válassza a Feladatátvétel lehetőséget az eszköztáron.

      2. Győződjön meg arról, hogy át szeretne adni egy másodlagos névteret az alias beírásával.

      3. Kapcsolja be a Széf Feladatátvétel beállítást a másodlagos névtérbe való biztonságos feladatátvételhez.

         Feljegyzés

         • A biztonságos feladatátvétel gondoskodik arról, hogy a függőben lévő Geo-DR replikációk befejeződjenek, mielőtt áttér a másodlagosra. Míg a kényszerített vagy manuális feladatátvétel nem várja meg a függőben lévő replikációk befejezését, mielőtt áttér a másodlagosra.
         • Jelenleg a biztonságos feladatátvétel meghiúsul, ha az elsődleges és másodlagos névterek nem ugyanabban az Azure-előfizetésben találhatók.

      4. Ezután válassza a Feladatátvétel lehetőséget.

         

         Fontos

         A feladatátvétel aktiválja a másodlagos névteret, és eltávolítja az elsődleges névteret a Geo-Disaster Recovery párosításból. Hozzon létre egy másik névteret egy új geo-vészhelyreállítási pár létrehozásához.

9. Végül fel kell vennie néhány monitorozást, hogy észlelje, szükség van-e feladatátvételre. A szolgáltatás a legtöbb esetben egy nagy ökoszisztéma része, ezért az automatikus feladatátvételek ritkán lehetségesek, mivel a feladatátvételeket gyakran a fennmaradó alrendszerrel vagy infrastruktúrával szinkronban kell végrehajtani.

Service Bus standardtól prémiumig

Ha az Azure Service Bus Standard névterét az Azure Service Bus Premiumba migrálta, akkor a vészhelyreállítási konfiguráció ps/CLI vagy REST API használatával történő létrehozásához a meglévő aliast (azaz a Service Bus Standard névteret kapcsolati sztring) kell használnia.

Ennek az az oka, hogy a migrálás során az Azure Service Bus standard névtere kapcsolati sztring/DNS-neve maga lesz az Azure Service Bus prémium szintű névterének aliasa.

Az ügyfélalkalmazások ezt az aliast (azaz az Azure Service Bus standard névterét kapcsolati sztring) kell használniuk ahhoz a prémium névtérhez való csatlakozáshoz, ahol a vészhelyreállítási párosítást beállították.

Ha az Azure Portal használatával állítja be a vészhelyreállítási konfigurációt, a portál elvonja Öntől ezt a kikötést.

Feladatátvételi folyamat

A feladatátvételt manuálisan indítja el az ügyfél (vagy explicit módon egy parancson keresztül, vagy a parancsot aktiváló ügyfél tulajdonában lévő üzleti logikán keresztül), és soha nem az Azure által. Teljes tulajdonjogot és láthatóságot biztosít az ügyfélnek a kimaradás megoldásához az Azure gerincén.

A feladatátvétel aktiválása után –

1. Az alias kapcsolati sztring frissül, hogy a másodlagos prémium névtérre mutasson.

2. Az ügyfelek (feladók és fogadók) automatikusan csatlakoznak a másodlagos névtérhez.

3. Az elsődleges és a másodlagos prémium névtér közötti meglévő párosítás megszakadt.

A feladatátvétel kezdeményezése után –

1. Ha egy másik kimaradás történik, újra meg kell tudnia adni a feladatátvételt. Ezért állítson be egy másik passzív névteret, és frissítse a párosítást.

2. Üzenetek lekérése a korábbi elsődleges névtérből, amint ismét elérhetővé válik. Ezt követően használja ezt a névteret a georeduktúra beállításán kívüli rendszeres üzenetküldéshez, vagy törölje a régi elsődleges névteret.

Feljegyzés

Csak a feladatátvételi szemantikák támogatottak. Ebben a forgatókönyvben feladatátvételt kell végrehajtania, majd újra párosíthatja egy új névtérrel. A sikertelen visszalépés nem támogatott; például egy SQL-fürtben.

Automatizálhatja a feladatátvételt monitorozási rendszerekkel vagy egyéni kialakítású monitorozási megoldásokkal. Az ilyen automatizálás azonban további tervezést és munkát igényel, ami a jelen cikk hatókörén kívül esik.

Menedzsment

Ha például hibás régiókat párosított a kezdeti beállítás során, bármikor megszakíthatja a két névtér párosítását. Ha a párosított névtereket normál névtérként szeretné használni, törölje az aliast.

Meglévő névtér használata aliasként

Ha olyan forgatókönyve van, amelyben nem módosíthatja a gyártók és a fogyasztók kapcsolatait, a névtérnevet aliasnévként használhatja újra. A GitHubon található mintakódot itt találja.

Minták

A GitHubon található minták bemutatják, hogyan állíthat be és kezdeményezhet feladatátvételt. Ezek a minták a következő fogalmakat mutatják be:

• A Microsoft Entra ID-ban szükséges .NET-minta és beállítások az Azure Resource Manager Service Bus szolgáltatással való használatához, a georeduktúra-helyreállítás beállításához és engedélyezéséhez.
• A mintakód végrehajtásához szükséges lépések.
• Meglévő névtér használata aliasként.
• A Geo-vészhelyreállítás PowerShell-lel vagy parancssori felülettel történő engedélyezésének lépései.
• Küldés és fogadás az aktuális elsődleges vagy másodlagos névtérből az alias használatával.

Megfontolások

Vegye figyelembe a következő szempontokat, hogy tartsa szem előtt ezt a kiadást:

• A feladatátvételi tervezés során figyelembe kell vennie az időtényezőt is. Ha például 15–20 percnél hosszabb ideig elveszíti a kapcsolatot, dönthet úgy, hogy elindítja a feladatátvételt.
• Az a tény, hogy nincsenek replikálva adatok, azt jelenti, hogy az aktív munkamenetek jelenleg nem replikálódnak. Emellett előfordulhat, hogy az ismétlődő észlelés és az ütemezett üzenetek nem működnek. Új munkamenetek, új ütemezett üzenetek és új ismétlődések működnek.
• Az összetett elosztott infrastruktúra feladatátvételét legalább egyszer el kell próbálni.
• Az entitások szinkronizálása eltarthat egy ideig, percenként körülbelül 50–100 entitásig. Az előfizetések és a szabályok entitásoknak is számítanak.

Rendelkezésre állási zónák

A Service Bus Premium termékváltozata támogatja a rendelkezésre állási zónákat, és hibaelszigetelt helyeket biztosít ugyanabban az Azure-régióban. A Service Bus az üzenetkezelési tároló három példányát kezeli (1 elsődleges és 2 másodlagos). A Service Bus mind a három példányt szinkronizálja az adatok és a felügyeleti műveletek esetében. Ha az elsődleges másolat sikertelen, a másodlagos másolatok egyikét előlépteti az elsődlegesre, és nem észleli az állásidőt. Ha az alkalmazások átmeneti leválasztást látnak a Service Busról, az SDK újrapróbálkozási logikája automatikusan újracsatlakozik a Service Bushoz.

Rendelkezésre állási zónák használata esetén a rendszer a metaadatokat és az adatokat (üzeneteket) is replikálja a rendelkezésre állási zónában lévő adatközpontok között.

Feljegyzés

Az Azure Service Bus Premium rendelkezésre állási zónák támogatása csak azokban az Azure-régiókban érhető el, ahol rendelkezésre állási zónák találhatók.

Amikor prémium szintű névteret hoz létre a portálon keresztül, a rendelkezésre állási zónák támogatása (ha elérhető a kiválasztott régióban) automatikusan engedélyezve lesz a névtérhez. Ha prémium szintű névteret hoz létre más mechanizmusokkal, például ARM/Bicep-sablonokkal, parancssori felülettel vagy PowerShell-lel, a tulajdonságot zoneRedundant explicit módon be kell állítani a rendelkezésre állási zónák engedélyezéséhez true (ha a kiválasztott régióban elérhető). A szolgáltatás használata nem jár többletköltséggel, és a névtér létrehozása után nem tilthatja le vagy engedélyezheti ezt a funkciót.

Privát végpontok

Ez a szakasz további szempontokat tartalmaz a georedukciós helyreállítás privát végpontokat használó névtérekkel való használatakor. A privát végpontok Service Bus használatával való általános használatáról az Azure Service Bus integrálása az Azure Private Linkkel című témakörben olvashat.

Új párosítások

Ha egy privát végponttal rendelkező elsődleges névtér és egy privát végpont nélküli másodlagos névtér közötti párosítást próbál létrehozni, a párosítás sikertelen lesz. A párosítás csak akkor sikeres, ha az elsődleges és a másodlagos névtér is rendelkezik privát végpontokkal. Javasoljuk, hogy ugyanazokat a konfigurációkat használja az elsődleges és másodlagos névtereken, valamint azon virtuális hálózatokon, amelyekben privát végpontok jönnek létre.

Feljegyzés

Amikor megpróbálja párosítani az elsődleges névteret egy privát végponttal és a másodlagos névtérrel, az ellenőrzési folyamat csak azt ellenőrzi, hogy létezik-e privát végpont a másodlagos névtérben. Nem ellenőrzi, hogy a végpont működik-e vagy működik-e a feladatátvétel után. Az Ön feladata annak biztosítása, hogy a privát végponttal rendelkező másodlagos névtér a feladatátvétel után a várt módon működjön.

Annak ellenőrzéséhez, hogy a privát végpont konfigurációi megegyeznek-e, küldjön egy üzenetsor-lekéréses kérelmet a másodlagos névtérbe a virtuális hálózaton kívülről, és ellenőrizze, hogy hibaüzenetet kap-e a szolgáltatástól.

Meglévő párosítások

Ha már létezik párosítás az elsődleges és a másodlagos névtér között, az elsődleges névtér privát végpontjának létrehozása meghiúsul. A megoldáshoz először hozzon létre egy privát végpontot a másodlagos névtéren, majd hozzon létre egyet az elsődleges névtérhez.

Feljegyzés

Bár csak olvasási hozzáférést engedélyezünk a másodlagos névtérhez, a privát végpont konfigurációinak frissítése engedélyezett.

Ajánlott konfiguráció

Ha vészhelyreállítási konfigurációt hoz létre az alkalmazáshoz és a Service Bushoz, privát végpontokat kell létrehoznia mind az elsődleges, mind a másodlagos Service Bus-névterekhez az alkalmazás elsődleges és másodlagos példányait üzemeltető virtuális hálózatokon.

Tegyük fel, hogy két virtuális hálózata van: VNET-1, VNET-2 és ezek az elsődleges és másodlagos névterek: ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. A következő lépéseket kell elvégeznie:

• On ServiceBus-Namespace1-Primary, hozzon létre két privát végpontot, amelyek a VNET-1 és a VNET-2 alhálózatait használják
• On ServiceBus-Namespace2-Secondary, hozzon létre két privát végpontot, amelyek ugyanazt az alhálózatot használják a VNET-1 és a VNET-2 hálózatból

Ennek a megközelítésnek az az előnye, hogy a feladatátvétel a Service Bus névtérétől független alkalmazásrétegen történhet. Vegyük példaként a következő forgatókönyveket:

Csak alkalmazásbeli feladatátvétel: Itt az alkalmazás nem létezik a VNET-1-ben, hanem a VNET-2-be kerül. Mivel mindkét privát végpont a VNET-1 és a VNET-2 rendszeren is konfigurálva van az elsődleges és a másodlagos névterekhez, az alkalmazás egyszerűen működik.

Csak Service Bus-névtérbeli feladatátvétel: Itt is működik az alkalmazás, mivel mindkét privát végpont mindkét virtuális hálózaton konfigurálva van mind az elsődleges, mind a másodlagos névterekhez.

Feljegyzés

A virtuális hálózatok geo-vészhelyreállításával kapcsolatos útmutatásért tekintse meg a Virtual Network – Üzletmenet-folytonosság című témakört.

Szerepköralapú hozzáférés-vezérlés

A Microsoft Entra szerepköralapú hozzáférés-vezérlési (RBAC) hozzárendelései az elsődleges névtérBen lévő Service Bus-entitásokhoz nem replikálódnak a másodlagos névtérbe. A másodlagos névtérben manuálisan hozhat létre szerepkör-hozzárendeléseket a hozzájuk való hozzáférés biztonságossá tételéhez.

Következő lépések

• A Geo-vészhelyreállítás REST API-referenciája itt található.
• Futtassa a Geo-vészhelyreállítási mintát a GitHubon.
• Tekintse meg a Geo-vészhelyreállítási mintát, amely üzeneteket küld egy aliasnak.

A Service Bus üzenetkezelésével kapcsolatos további információkért tekintse meg az alábbi cikkeket:

• Service Bus-üzenetsorok, -témakörök és -előfizetések
• Bevezetés a Service Bus által kezelt üzenetsorok használatába
• A Service Bus-üzenettémakörök és -előfizetések használata
• REST API