Azure Event Hubs – Georeduktúra-helyreá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 Event Hubs már eleve szétterjed az egyes gépek vagy akár teljes állványok katasztrofális hibáinak kockázatával olyan fürtökön, amelyek egy adatközponton belül több hibatartományra is kiterjednek. Transzparens hibaészlelési és feladatátvételi mechanizmusokat vezet be, hogy a szolgáltatás továbbra is a biztosított szolgáltatási szinteken belül, és általában észrevehető megszakítások nélkül működjön ilyen hibák esetén. Ha olyan Event Hubs-névteret hoz létre, amelyen engedélyezve van a rendelkezésre állási zónák használata, tovább csökkentheti a kimaradás kockázatát, és magas rendelkezésre állást engedélyezhet. A rendelkezésre állási zónákkal a kimaradás kockázata tovább terjed három fizikailag elkülönített létesítményre, és a szolgáltatás elegendő kapacitással rendelkezik ahhoz, hogy azonnal megbirkózzon a teljes létesítmény teljes, katasztrofális veszteségével.

A rendelkezésre állási zóna támogatásával rendelkező, minden aktív Azure Event Hubs-fürtmodell rugalmasságot biztosít a súlyos hardverhibák és akár a teljes adatközpont-létesítmények katasztrofális elvesztése ellen. Mégis előfordulhatnak olyan súlyos helyzetek, amelyek széles körű fizikai pusztítással járhatnak, amelyek ellen még ezek az intézkedések sem képesek megfelelően védekezni.

Az Event Hubs 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 Geo-Vészhelyreállítás funkció biztosítja, hogy egy névtér (Event Hubs, Fogyasztói csoportok és beállítások) 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ételi lépés újra a névtér kiválasztott aliasnevét a másodlagos névtérre irányítja, 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

  • A funkció lehetővé teszi az azonos konfigurációjú műveletek azonnali folytonosságát, de nem replikálja az eseményadatokat. Hacsak a katasztrófa nem okozta az összes zóna elvesztését, a feladatátvételt követően az elsődleges Eseményközpontban őrzött eseményadatok helyreállíthatók lesznek, és a korábbi események onnan szerezhetők be a hozzáférés visszaállítása után. Az eseményadatok 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-vészhelyreállítási funkciókészletre, hanem kövesse a replikációs útmutatást.
  • A Microsoft Entra szerepköralapú hozzáférés-vezérlési (RBAC) hozzárendelései az elsődleges névtérben lévő 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.

Ü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 Event Hubs ideiglenes elérhetetlensége, amely hatással lehet a szolgáltatás egyes összetevőire, például az üzenettárra vagy akár a teljes adatközpontra. A probléma kijavítása után azonban az Event Hubs 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 az Event Hubs-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 újra 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 Event Hubs 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 standard, prémium és dedikált termékváltozatokhoz é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.

  • 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 eseményközpontok és fogyasztói csoportok, 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 és események nem replikálódnak.

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

Támogatott névtérpárok

Az elsődleges és másodlagos névterek alábbi kombinációi támogatottak:

Elsődleges névtérszint Engedélyezett másodlagos névtérszint
Standard Standard, Dedikált
Prémium Prémium
Dedicated Dedicated

Megjegyzés:

Nem párosíthatja az ugyanabban a dedikált fürtben lévő névtereket. A különálló fürtökben lévő névterek párosíthatók.

Beállítási és feladatátvételi folyamat

Az alábbi szakasz áttekintést nyújt a feladatátvételi folyamatról, és ismerteti a kezdeti feladatátvétel beállítását.

Image showing the overview of failover process

Setup

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 névteret.

  2. Hozza létre a másodlagos 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.

    Initiate pairing from the primary namespace

  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 egy meglévő névtér van kijelölve.
    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.

    Select the secondary namespace

  6. Ekkor megjelenik a Geo-DR Alias lap. Az elsődleges névtérből is navigálhat erre a lapra a bal oldali menü Geo-helyreállítás elemének kiválasztásával.

    Geo-DR alias page

  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.

  8. Ezen az Áttekintés lapon 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. Válassza a Feladatátvétel lehetőséget az eszköztáron.

      Figyelmeztetés:

      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-vészhelyreállítási pár létrehozásához.

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.

Example

Ebben a forgatókönyvben fontolja meg az értékesítési pont (POS) megoldást, amely üzeneteket vagy eseményeket bocsát ki. Az Event Hubs ezeket az eseményeket egy leképezési vagy újraformázási megoldásnak továbbítja, amely ezután tovább továbbítja a leképezett adatokat egy másik rendszernek további feldolgozás céljából. Ezen a ponton előfordulhat, hogy ezek a rendszerek ugyanabban az Azure-régióban vannak üzemeltetve. A feladatátvétel időpontjának és milyen részének eldöntése az infrastruktúra adatáramlásától függ.

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.

Feladatátvételi folyamat

Ha elindítja a feladatátvételt, két lépésre van szükség:

  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.

Megjegyzé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.

Image showing the failover flow

Manuális feladatátvétel

Ez a szakasz bemutatja, hogyan lehet manuálisan feladatátvételt végrehajtani az Azure Portal, a parancssori felület, a PowerShell, a C# stb. használatával.

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

  2. Válassza a Bal oldali menü Georeduktúra elemét.

  3. Manuális feladatátvétel a másodlagos névtérbe. Válassza a Feladatátvétel lehetőséget az eszköztáron.

    Figyelmeztetés:

    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-vészhelyreállítási pár létrehozásához.

Kezelés

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

Considerations

Vegye figyelembe az alábbi szempontokat:

  1. Az Event Hubs geo-vészhelyreállítása tervezés szerint nem replikálja az adatokat, ezért nem használhatja újra az elsődleges eseményközpont régi eltolási értékét a másodlagos eseményközpontban. Javasoljuk, hogy indítsa újra az esemény fogadóját az alábbi módszerek egyikével:

    • EventPosition.FromStart() – Ha minden adatot be szeretne olvasni a másodlagos eseményközpontban.
    • EventPosition.FromEnd() – Ha a másodlagos eseményközponthoz való kapcsolódás időpontjától kezdve minden új adatot be szeretne olvasni.
    • EventPosition.FromEnqueuedTime(dateTime) – Ha a másodlagos eseményközpontban kapott összes adatot egy adott dátumtól és időponttól szeretné olvasni.
  2. 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.

  3. Az a tény, hogy egyetlen adat sem replikálódik, az azt jelenti, hogy az aktuális aktív munkamenetek nem replikálódnak. Emellett előfordulhat, hogy az ismétlődő észlelés és az ütemezett üzenetek nem működnek. Az új munkamenetek, az ütemezett üzenetek és az új ismétlődések működni fognak.

  4. Az összetett elosztott infrastruktúra feladatátvételét legalább egyszer el kell próbálni.

  5. Az entitások szinkronizálása eltarthat egy ideig, percenként körülbelül 50–100 entitásig.

  6. A másodlagos névtér felügyeleti síkjának néhány aspektusa írásvédetté válik, míg a georeduktív párosítás aktív.

  7. A másodlagos névtér adatsíkja írásvédett lesz, míg a georeduktív párosítás aktív. A másodlagos névtér adatsíkja get kéréseket fogad el az ügyfélkapcsolatok és a hozzáférés-vezérlők ellenőrzésének engedélyezéséhez.

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

Az Event Hubs támogatja a rendelkezésre állási zónákat, és az Azure-régión belüli, hibaelszigetelt helyeket biztosít. A rendelkezésre állási zónák támogatása csak a rendelkezésre állási zónákkal rendelkező Azure-régiókban érhető el. A metaadatok és az adatok (események) is replikálódnak a rendelkezésre állási zónában lévő adatközpontok között.

Névtér létrehozásakor a következő kiemelt üzenet jelenik meg, amikor kijelöl egy rendelkezésre állási zónákkal rendelkező régiót.

Image showing the Create Namespace page with region that has availability zones

Megjegyzés:

Az Azure Portal használatakor a zónaredundancia automatikusan engedélyezve lesz a rendelkezésre állási zónák támogatásán keresztül. A portálon nem tilthatja le. Az Azure CLI-parancsot az eventhubs namespace--zone-redundant=false használhatja a PowerShell-paranccsal New-AzEventHubNamespace , vagy használhatja egy -ZoneRedundant=false letiltott zónaredundanciával rendelkező névteret.

Private endpoints

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 event hubokkal való általános használatáról a privát végpontok konfigurálása 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 lesz 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.

Megjegyzés:

Amikor az elsődleges névteret magánvégponttal és másodlagos névtérrel próbálja párosítani, 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 felelőssége 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 azonosak-e az elsődleges és a másodlagos névtereken, küldjön egy olvasási kérést (például: Event Hub lekérése) 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, a privát végpont létrehozása az elsődleges névtéren sikertelen lesz. 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.

Megjegyzé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.

Ha vészhelyreállítási konfigurációt hoz létre az alkalmazáshoz és az Event Hubs-névterekhez, privát végpontokat kell létrehoznia mind az elsődleges, mind a másodlagos Event Hubs-névterekhez az alkalmazás elsődleges és másodlagos példányait futtató 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: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. A következő lépéseket kell elvégeznie:

  • Az EventHubs-Namespace1-Primary rendszeren hozzon létre két privát végpontot, amelyek a VNET-1 és a VNET-2 alhálózatait használják
  • Az EventHubs-Namespace2-Secondary rendszeren 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

Private endpoints and virtual networks

Ennek a megközelítésnek az az előnye, hogy a feladatátvétel az Event Hubs 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 fog létezni 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 csak működni fog.

Event Hubs csak feladatátvétel: Itt is, 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évterek esetében, az alkalmazás csak működni fog.

Megjegyzé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.

Role-based access control

A Microsoft Entra szerepköralapú hozzáférés-vezérlési (RBAC) hozzárendelései az elsődleges névtérben lévő 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

Tekintse át a következő mintákat vagy referenciadokumentációt.