Azure Service Bus Geo-Katasztrófa Helyreállítás

A Service Bus Geo-Disaster Recovery funkcióval szigetelheti az Azure Service Bus-alkalmazásokat a kimaradások és katasztrófák ellen. Segít megőrizni az összetett alkalmazáskonfiguráció integritását.

Megjegyzés

Ez a funkció az Azure Service Bus prémium szintű verziójához érhető el.

A Geo-Disaster Recovery szolgáltatás folyamatosan replikálja egy névtér teljes konfigurációját (entitások, konfigurációk, tulajdonságok) egy elsődleges névtérből egy másodlagos párosított névtérbe. Bármikor kezdeményezhet egyszeri átváltást az elsődlegesről a másodlagosra. A feladatátvételi lépés újrapontozza a névtér kiválasztott aliasnevét a másodlagos névtérbe, majd megszakítja a párosítást. A feladatátvétel a kezdeményezést követően szinte azonnal megtörténik.

Az összehasonlítás a Geo-Replikációval

Az Azure Service Bus két funkciót kínál a földrajzi rugalmasság érdekében: Geo-Replication és Geo-Disaster Recovery. A fő különbség az, hogy Geo-Replication metaadatokat és adatokat (üzeneteket, üzenetállapotokat, tulajdonságváltozásokat) replikál, míg Geo-Disaster Recovery csak metaadatokat replikál. A legtöbb vészhelyreállítási forgatókönyv esetében a Geo-Replication a javasolt választás. Részletes összehasonlításért lásd: Megbízhatóság az Azure Service Busban – Rugalmasság a régiószintű hibákhoz.

Fontos tudnivalók

• Ez a funkció lehetővé teszi a műveletek azonnali folytonosságát ugyanazzal a konfigurációval, 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ása, hanem a közvetítő minden állapotváltozása is szükséges. Ez a replikáció a Geo-Replication szolgáltatásban érhető el.
• 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 rendszer nem replikálja a következő konfigurációkat:
  • 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
  • Azure Event Grid-előfizetések
• A particionált névtér és a nem particionált névtér párosítása nem támogatott.
• Ha engedélyezi a(z) AutoDeleteOnIdle egy entitás számára, előfordulhat, hogy az entitás nem lesz jelen a másodlagos névtérben a feladatátvétel során. Amikor a másodlagos elsődlegessé válik, az utolsó hozzáférési állapot, amely nem része a metaadatoknak, nem érhető el 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 a témakör-előfizetések tartalmának replikálásához és 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éséhez ne támaszkodjon erre a Geo-Disaster Helyreállítási funkciókészletre. Ehelyett használja a Geo-Replication funkciót , vagy kövesse a replikációs útmutatót.

Alapfogalmak és kifejezések

A Geo-Disaster Helyreállítási funkció metaadatok vészhelyreállítását valósítja meg, és 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 szintű szinten érhető el. Nem kell módosítania a kapcsolati sztringet, 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) biztosító kapcsolati karakterláncot nyújt. Az alkalmazások ezt a kapcsolati aliast használják egy névtérhez való csatlakozáshoz. Alias használatával a kapcsolati karakterlánc ugyanaz marad, amikor az átállás elindul.

• 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áról.

Először hozzon létre vagy használjon egy meglévő elsődleges névteret, és hozzon létre egy új másodlagos névteret. Ezután párosítsa a két névteret. Ez a párosítás egy aliast biztosít, amellyel csatlakozhat. Mivel aliast használ, nem kell módosítania a kapcsolati karakterláncot. A feladatátvételi párosításhoz csak új névtereket adhat hozzá.

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 lépjen az elsődleges névtérre.

4. A bal oldali menüben válassza a Geo-Recovery 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 indításakor 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. Alias esetén adjon meg egy aliast a Geo-Disaster Recovery párosításhoz.

   3. Válassza a Create gombot.

      

6. A(z) Service Bus Geo-DR Alias oldalnak úgy kell megjelennie, ahogy az az alábbi képen látható. Az Geo-DR Alias lapra az elsődleges névtérlapról is navigálhat a bal oldali menü Geo-Recovery elemének kiválasztásával.

   

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

8. Váltson az Áttekintés lapra. Az alábbi tevékenységeket 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 Párosítás megszakítása lehetőséget az eszköztáron.
   2. A másodlagos névtérre történő manuális átkapcsolás.

      1. Válassza az Átkapcsolás lehetőséget az eszköztáron.

      2. Erősítse meg, hogy áttérni szeretne a másodlagos névtérbe az aliasának beírásával.

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

         Megjegyzés

         • A biztonságos feladatátvétel gondoskodik arról, hogy a függőben lévő geo-vészhelyreállítási replikációk befejeződjenek, mielőtt átváltanak a másodlagos kiszolgálóra. Alternatívaként a kényszerített vagy manuális átállás nem várja meg a függőben lévő replikációk befejezését, mielőtt áttér a másodlagos szerverre.
         • 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. Válassza Átálláslehető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-Vészhelyreállítás párosításból. Hozzon létre egy másik névteret egy új Geo-Disaster Recovery-pár létrehozásához.

9. Végül adjon hozzá monitorozási funkciót annak észleléséhez, hogy 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, 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 (a Service Bus Standard névtér kapcsolati sztringet) kell használnia.

A migrálás során az Azure Service Bus standard névtérkapcsolati sztringje és DNS-neve az Azure Service Bus prémium szintű névterének aliasává válik.

Az ügyfélalkalmazásainak ezt az aliast (az Azure Service Bus standard névtérkapcsolati sztringet) kell használniuk ahhoz a prémium névtérhez való csatlakozáshoz, ahol beállította a vészhelyreállítási párosítást.

Ha az Azure Portal használatával állítja be a vészhelyreállítási konfigurációt, a portál kezeli ezt a részletet.

Átállási folyamat

Az ügyfél manuálisan aktivál egy feladatátvételt (explicit módon egy parancson keresztül vagy a parancsot aktiváló ügyfél tulajdonában lévő üzleti logikán keresztül). Az Azure soha nem indít el feladatátvételt. Ez a megközelítés teljes körű tulajdonjogot és láthatóságot biztosít az ügyfél számára a kimaradás megoldásához az Azure gerinchálózatán.

Az átváltási eseményindítók után –

1. Az alias kapcsolati sztringet a másodlagos prémium névtérre történő irányításhoz frissítették.

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 újabb leállás történik, biztosítani kell a feladatátvétel lehetőségét. Ezért állítson be egy másik másodlagos 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 Geo-Vészhelyreállítás beállításán kívüli rendszeres üzenetküldéshez, vagy törölje a régi elsődleges névteret.

Megjegyzés

Csak a fail-forward szemantika támogatott. Amikor földrajzilag elosztott katasztrófa utáni helyreállítással kezdeményezi az átállást, az átállás befejezése után új névteret párosíthat hozzá. Nem lehet visszatérni az előző elsődleges replikához. Ezek a szemantikák különbözhetnek a többi adattártól, amelyeket megszokott, például a Microsoft SQL Server fürtökben.

A feladatátvételt monitorozási rendszerekkel vagy egyéni fejlesztésű monitorozási megoldásokkal automatizálhatja. 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 hibát követ el, például rossz régiókat párosít 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.

Példá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:

• .NET minta és a Microsoft Entra ID-ban szükséges beállítások az Azure Resource Manager és a Service Bus használatához, a geo-vészhelyzeti 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 földrajzi katasztrófa utáni helyreállítás alternatív engedélyezésének lépései PowerShell-lel vagy parancssori felülettel.
• 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

Tartsa szem előtt a következő szempontokat ezzel a kiadással:

• A feladatátvételi tervezés során vegye figyelembe az időtényezőt. Ha például 15–20 percnél hosszabb ideig elveszíti a kapcsolatot, dönthet úgy, hogy elindítja a feladatátvételt.
• Mivel nincs replikálva adat, 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.
• Legalább egyszer gyakorolnia kell egy összetett elosztott infrastruktúra feladatátvételét.
• 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.

Privát végpontok

Ez a szakasz további szempontokat tartalmaz a Geo-Disaster Recovery privát végpontokat használó névterekkel 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. Használja ugyanazokat a konfigurációkat az elsődleges és másodlagos névtereken, valamint az olyan virtuális hálózatokon, ahol privát végpontokat hoz létre.

Megjegyzé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 a feladatátvétel után működésbe lép-e. 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 hiba megoldásához 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.

Megjegyzés

Bár a másodlagos névteret írásvédettként érheti el, frissítheti a privát végpont konfigurációit.

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, a VNET-1 és a VNET-2, valamint ezek az elsődleges és másodlagos névterek: ServiceBus-Namespace1-Primary és ServiceBus-Namespace2-Secondary. Hajtsa végre a következő lépéseket:

• 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.

Megjegyzés

A virtuális hálózatok geo-vészhelyreállításával kapcsolatos útmutatásért lásd: Virtual Network – Üzletmenet-folytonosság.

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-Disaster Recovery REST API-referenciát itt találja.
• Futtassa a Geo-Disaster Recovery mintát a GitHubon.
• Tekintse meg a Geo-Disaster Recovery 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
• Service Bus témakörök és előfizetések használata
• REST API