Georeplikációs (nyilvános előzetes verzió)

Az Azure Event Hubsban két funkció biztosítja a geo-vészhelyreállítást.

• Geo-vészhelyreállítás (Metadata DR), amely csak metaadatok replikálását biztosítja.
• Georeplikáció (nyilvános előzetes verzió), amely a metaadatok és az adatok replikálását biztosítja.

Ezeket a funkciókat nem szabad összekeverni a rendelkezésre állási zónákkal. Mindkét földrajzi helyreállítási funkció rugalmasságot biztosít az Olyan Azure-régiók között, mint az USA keleti régiója és az USA nyugati régiója. A rendelkezésre állási zóna támogatása rugalmasságot biztosít egy adott földrajzi régión belül, például az USA keleti régiójában. További információ a rendelkezésre állási zónákról: Event Hubs Rendelkezésre állási zóna támogatása.

Fontos

• Ez a funkció jelenleg nyilvános előzetes verzióban érhető el, ezért éles környezetben nem használható.
• A nyilvános előzetes verzióban jelenleg az alábbi régiók támogatottak.

US	Európa
USA középső régiója – EUAP	Észak-Olaszország
	Közép-Spanyolország
	Kelet-Norvégia

Metaadatok vészhelyreállítása és a metaadatok és adatok georeplikációja

A Metadata DR szolgáltatás egy névtér konfigurációs adatait replikálja egy elsődleges névtérből egy másodlagos névtérbe. Egyszeri feladatátvételt támogat a másodlagos régióba. Az ügyfél által kezdeményezett feladatátvétel során a névtér aliasnevét a rendszer a másodlagos névtérre irányítja át, majd a párosítás megszakad. A konfigurációs adatokon kívül egyetlen adat sem replikálódik, és az engedély-hozzárendelések sem replikálódnak.

Az újabb georeplikációs funkció replikálja a konfigurációs adatokat és az összes adatot egy elsődleges névtérből egy vagy több másodlagos névtérbe. Feladatátvétel esetén a kiválasztott másodlagos lesz az elsődleges, az előző elsődleges pedig másodlagos lesz. A felhasználók igény szerint visszaállíthatják a feladatátvételt az eredeti elsődleges helyre.

Ez a cikk a georeplikációs funkcióval foglalkozik. A metaadatok dr. funkciójával kapcsolatos részletekért tekintse meg az Event Hubs Geo-disater recovery for metadata (A metaadatok geodéziai helyreállítása) című témakört.

Georeplikáció

A georeplikációs funkció nyilvános előzetes verziója támogatott az Event Hubs önkiszolgáló, dedikált fürtök skálázási névtereihez. A funkciót új vagy meglévő névtérekkel használhatja dedikált önkiszolgáló fürtökben. A georeplikációs szolgáltatás nem támogatja a következő funkciókat:

• Ügyfél által felügyelt kulcsok (CMK)
• Felügyelt identitás rögzítéshez
• Virtuális hálózati szolgáltatások (szolgáltatásvégpontok vagy privát végpontok)
• Nagy méretű üzenetek támogatása (most nyilvános előzetes verzióban)
• Kafka-tranzakciók (most nyilvános előzetes verzióban)

A geoadat-replikáció nyilvános előzetes verziójának néhány fő aspektusa a következő:

• Elsődleges-másodlagos replikációs modell – A georeplikációs modell elsődleges-másodlagos replikációs modellre épül, ahol egy adott időpontban csak egy elsődleges névtér szolgál ki eseménygyártókat és eseményfelhasználókat.
• Az Event Hubs teljes mértékben felügyelt bájtról bájtra replikálja a metaadatokat, az eseményadatokat és a felhasználók eltolását a másodlagos fájlok között a konfigurált konzisztenciaszintekkel.
• Stabil névtér teljes tartománynév (FQDN) – A teljes tartománynévnek nem kell megváltoznia az előléptetés végrehajtásakor.
• Replikációs konzisztencia – Két replikációs konzisztenciabeállítás létezik, szinkron és aszinkron.
• Egy másodlagos felhasználó által felügyelt előléptetése az új elsődlegeshez.

A másodlagos elem új elsődlegessé alakítása kétféleképpen történik:

• Tervezett: a másodlagos elsődlegesre való előléptetés, ahol a forgalom nem lesz feldolgozva, amíg az új elsődleges nem kapja meg a korábbi elsődleges példány által tárolt összes adatot.
• Kényszerített: feladatátvételként, ahol a másodlagos a lehető leggyorsabban elsődlegessé válik. A georeplikációs funkció az összes adatot és metaadatot replikálja az elsődleges régióból a kiválasztott másodlagos régiókba. A névtér teljes tartományneve mindig az elsődleges régióra mutat.

Amikor elindít egy másodlagos előléptetést, a teljes tartománynév az új elsődlegesként kiválasztott régióra mutat. A régi elsődleges ezután másodlagossá válik. Feladatátvételen kívül más okból is előléptetheti a másodlagost az új elsődlegesként. Ilyen okok lehetnek például az alkalmazásfrissítések, a feladatátvételi tesztelés vagy bármilyen más dolog. Ezekben a helyzetekben gyakran előfordul, hogy vissza kell váltani, amikor ezek a tevékenységek befejeződnek.

A másodlagos régiók hozzáadása vagy eltávolítása az ügyfél belátása szerint történik. Néhány jelenlegi korlátozást érdemes megjegyezni:

• A másodlagos régiók írásvédett nézetei nem támogatottak.
• Nincs automatikus előléptetési/feladatátvételi képesség. Minden promóciót az ügyfél kezdeményez.
• A másodlagos régióknak különbözniük kell az elsődleges régiótól. Nem jelölhet ki másik dedikált fürtöt ugyanabban a régióban.
• A nyilvános előzetes verzió csak egy másodlagos verziót támogat.

Replikációs konzisztencia

Két replikációs konzisztenciakonfiguráció létezik, szinkron és aszinkron. Fontos tudni a két konfiguráció közötti különbségeket, mivel hatással vannak az alkalmazásokra és az adatok konzisztenciájára.

Aszinkron replikáció

Ha engedélyezve van az aszinkron replikáció, a rendszer minden üzenetet véglegesített az elsődleges helyen, majd elküldi a másodlagosnak. A felhasználók elfogadható mennyiségű késési időt konfigurálhatnak, amelyet a másodlagosnak fel kell zárnia. Ha egy aktív másodlagos késés nagyobb, mint a felhasználó késési konfigurációja, az elsődleges régió szabályozza a bejövő közzétételi kérelmeket.

Szinkron replikáció

Ha engedélyezve van a szinkron replikáció, a rendszer replikálja a közzétett eseményeket a másodlagosra, amelynek meg kell erősítenie az üzenetet, mielőtt az elsődlegesen véglegesítése megtörtént volna. A szinkron replikációval az alkalmazás a közzétételhez, replikáláshoz, nyugtázáshoz és véglegesítéshez szükséges sebességgel tesz közzé. Azt is jelenti, hogy az alkalmazás mindkét régió rendelkezésre állásához van kötve. Ha a másodlagos régió leáll, az üzeneteket nem lehet nyugtázni vagy véglegesíteni.

Replikációs konzisztencia összehasonlítása

Szinkron replikációval:

• A késés hosszabb az elosztott véglegesítés miatt.
• A rendelkezésre állás két régió elérhetőségéhez van kötve. Ha egy régió leáll, a névtér nem érhető el.
• A fogadott adatok mindig legalább két régióban találhatók (a kezdeti nyilvános előzetes verzióban csak két régió támogatott).

A szinkron replikáció biztosítja a legnagyobb biztosítékot az adatok biztonságára. Ha szinkron replikációval rendelkezik, akkor a véglegesítés után a georeplikáláshoz konfigurált összes régióban le van állítva. Ha azonban engedélyezve van a szinkron replikáció, az alkalmazás rendelkezésre állása a két régió rendelkezésre állásától függően csökkenthető.

Az aszinkron replikáció engedélyezése nem befolyásolja nagyon a késést, és a szolgáltatás rendelkezésre állását nem befolyásolja egy másodlagos régió elvesztése. Az aszinkron replikáció nem garantálja, hogy minden régió rendelkezik az adatokkal a véglegesítése előtt, ahogyan a szinkron replikáció teszi. Beállíthatja azt az időtartamot is, amíg a másodlagos nem szinkronizálható a bejövő forgalom szabályozása előtt. A beállítás 5 perctől 1440 percig is lehet, ami egy nap. Ha nagy távolságra lévő régiókat szeretne használni, akkor valószínűleg az aszinkron replikáció a legjobb választás.

A replikáció konzisztencia-konfigurációja a georeplikációs konfiguráció után változhat. A szinkronról az aszinkronra, vagy az aszinkronról a szinkronra léphet. Ha szinkronról aszinkronra lép, a késés és az alkalmazás rendelkezésre állása javul. Ha az aszinkronról szinkronra vált, a másodlagos a nullát elérő késés után szinkronként lesz konfigurálva. Ha valamilyen okból folyamatos késéssel fut, előfordulhat, hogy szüneteltetnie kell a közzétevőket ahhoz, hogy a késés elérje a nullát, és a mód szinkronra válthasson.

A szinkron replikáció engedélyezésének általános okai az adatok fontosságához, a konkrét üzleti igényekhez vagy a megfelelőségi okokhoz kapcsolódnak. Ha az elsődleges cél az alkalmazások rendelkezésre állása az adatbiztosítás helyett, akkor az aszinkron konzisztencia valószínűleg a jobb választás.

Másodlagos régió kiválasztása

A georeplikációs funkció engedélyezéséhez egy elsődleges és másodlagos régiót kell használnia, ahol engedélyezve van a georeplikációs funkció. Azt is meg kell adnia, hogy az Event Hubs-fürt már meglévő legyen az elsődleges és a másodlagos régióban is.

A georeplikációs funkció attól függ, hogy képes-e replikálni a közzétett eseményeket az elsődlegesről a másodlagos régióba. Ha a másodlagos régió egy másik kontinensen található, az jelentős hatással van az elsődleges és a másodlagos régió közötti replikációs késésre. Ha a georeplikálást rendelkezésre állási és megbízhatósági okokból használja, akkor a legjobb, ha a másodlagos régiók legalább ugyanazon a kontinensen vannak, ahol lehetséges. A földrajzi távolság által kiváltott késés jobb megértéséhez többet tudhat meg az Azure-beli hálózat oda-vissza késési statisztikáiból | Microsoft Learn.

Georeplikációs felügyelet

A georeplikációs funkció lehetővé teszi egy másodlagos régió konfigurálását a konfiguráció és az adatok replikálásához. A következőket teheti:

• Georeplikálás konfigurálása – A másodlagos régiók konfigurálhatók egy önkiszolgáló dedikált fürt bármely meglévő névterén egy olyan régióban, ahol engedélyezve van a georeplikációs funkciókészlet. A névtér létrehozásakor is konfigurálható ugyanazon a dedikált fürtön. Másodlagos régió kiválasztásához rendelkeznie kell egy dedikált fürttel, amely elérhető a másodlagos régióban, és a másodlagos régiónak engedélyeznie kell az adott régió georeplikációs funkciókészletét is.
• A replikáció konzisztenciájának konfigurálása – A georeplikálás konfigurálásakor a szinkron és az aszinkron replikáció be van állítva, de később is átváltható. Az aszinkron konzisztenciával konfigurálhatja, hogy egy másodlagos régió mennyi ideig késhet.
• Előléptetés/feladatátvétel aktiválása – Minden előléptetést vagy feladatátvételt az ügyfél kezdeményez. Az előléptetés során dönthet úgy, hogy az elejétől fogva kényszerítetté teszi, vagy akár meggondolja magát az előléptetés elindítása és kényszerítése után.
• Másodlagos eltávolítása – Ha bármikor el szeretné távolítani az elsődleges és a másodlagos régiók közötti geopárosítást, ezt megteheti, és a másodlagos régióban lévő adatok törlődnek.

Adatreplikálás monitorozása

A felhasználók a replikációs feladat előrehaladását az alkalmazásmetrikanaplók replikációs késési metrikáinak monitorozásával figyelhetik.

• Application Metrics-naplók engedélyezése az Event Hubs-névtérben az Azure Event Hubs – Azure Event Hubs monitorozása után | Microsoft Learn.

• Az alkalmazásmetrikák naplóinak engedélyezése után néhány percig elő kell állítania és felhasználnia a névtérből származó adatokat, mielőtt megkezdené a naplók megtekintését.

• Az alkalmazásmetrikák naplóinak megtekintéséhez lépjen az Event Hubs lap Figyelés szakaszára, és válassza a Bal oldali menü Naplók elemét. Az alábbi lekérdezéssel megkeresheti a replikáció késését (másodpercben) az elsődleges és a másodlagos névterek között.

  AzureDiagnostics
    | where TimeGenerated > ago(1h)
    | where Category == "ApplicationMetricsLogs"
    | where ActivityName_s == "ReplicationLag
  

• Az oszlop count_d az elsődleges és a másodlagos régió közötti replikációs késést jelzi másodpercekben.

Adatok közzététele

Az esemény-közzétételi alkalmazások a georeplikált névterekben a georeplikált névtér teljes tartománynevén keresztül tehetnek közzé adatokat. Az esemény közzétételi megközelítése megegyezik a nem Geo DR-esetével, és nincs szükség az ügyfélalkalmazások módosítására.

Előfordulhat, hogy az esemény közzététele nem érhető el a következő körülmények között:

• A feladatátvételi türelmi időszak alatt a meglévő elsődleges régió elutasítja az eseményközpontban közzétett új eseményeket.
• Ha az elsődleges és a másodlagos régiók közötti replikációs késés eléri a replikációs késés maximális időtartamát, a közzétevő bejövő számítási feladatai szabályozva lehetnek. A Közzétevő-alkalmazások nem férnek hozzá közvetlenül a másodlagos régiók névtereihez.

Adatok felhasználása

Az eseményfelhasználó alkalmazások egy georeplikált névtér stabil névtér teljes tartománynevével használhatják fel az adatokat. A felhasználói műveletek nem támogatottak, attól kezdve, hogy a feladatátvételt kezdeményezik, amíg be nem fejeződik.

Ellenőrzőpont-kezelés/Eltoláskezelés

Az eseményfelhasználó alkalmazások továbbra is fenntarthatják az eltoláskezelést, ahogy egyetlen névtérrel tennék.

Kafka

Az eltolások közvetlenül az Event Hubshoz kerülnek, az eltolások pedig régiók között replikálódnak. Ezért a fogyasztók onnan kezdhetik meg a fogyasztást, ahol az elsődleges régióban abbahagyták.

Event Hubs SDK/AMQP

Az Event Hubs SDK-t használó ügyfeleknek frissíteni kell az SDK 2024. áprilisi verziójára. Az Event Hubs SDK legújabb verziója támogatja a feladatátvételt az ellenőrzőpont frissítésével. Az ellenőrzőpontot olyan ellenőrzőpont-tárolóval rendelkező felhasználók kezelik, mint az Azure Blob Storage vagy egy egyéni tárolási megoldás. Feladatátvétel esetén az ellenőrzőpont-tárolónak elérhetőnek kell lennie a másodlagos régióból, hogy az ügyfelek le tudják kérni az ellenőrzőpont adatait, és elkerüljék az üzenetek elvesztését.

Díjszabás

A dedikált Event Hubs-fürtök ára a georeplikálástól függetlenül van megosztva. A dedikált Event Hubs-alapú georeplikálás használatához legalább két dedikált fürtnek kell külön régiókban rendelkeznie. A georeplikálás másodlagos példányaként használt dedikált fürtök más számítási feladatokhoz is használhatók. A georeplikációs díj a közzétett sávszélesség * a másodlagos régiók száma alapján van felszámítva. A georeplikációs díjról a korai nyilvános előzetes verzióban lemondunk.

Kapcsolódó tartalom

A georeplikációs funkció használatáról a Georeplikációs szolgáltatás használata című témakörben olvashat.