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

A Service Bus Geo-Disaster Recovery funkciója az egyik lehetőség az Azure Service Bus-alkalmazások kimaradások és katasztrófák elleni szigetelésére, és elsősorban az összetett alkalmazáskonfiguráció integritásának megőrzését célozza.

Feljegyzés

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

A Geo-Vészhelyreállítás funkció biztosítja, hogy egy névtér teljes konfigurációja (entitások, konfiguráció, tulajdonságok) folyamatosan replikálva legyen egy elsődleges névtérből egy másodlagos névtérbe, amelyhez párosítva van, és lehetővé teszi, hogy bármikor egyszeri feladatátvételt kezdeményezze az elsődlegesről a másodlagosra. A feladatátvétel áthelyezi a névtér kiválasztott aliasnevét a másodlagos névtérre, 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, amelyet a georeplikációs funkció (nyilvános előzetes verzió) kínál.
• 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
  • Azure Event Grid-előfizetések
• 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éséhez ne támaszkodjon erre a Geo-Vészhelyreállítás funkciókészletre, hanem használja a georeplikációs funkciót , vagy kövesse a replikációs útmutatót.

Alapfogalmak és kifejezések

A Geo-Vészhelyreállítás 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 szintű szinten é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 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 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. Alias esetén adjon meg egy aliast a Geo-Disaster Recovery 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-Recovery 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 Biztonságos 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-vészhelyreállítási replikációk befejeződjenek, mielőtt átváltanak a másodlagosra. Másik lehetőségként 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-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 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 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.

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.

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-azonosítóban szükséges beállítások az Azure Resource Manager Service Bus használatával való használatához, a Geo-Vészhelyreá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.

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. 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 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
• A Service Bus-üzenettémakörök és -előfizetések használata
• REST API