Geografická replikace služby Azure Event Hubs

Funkce geografické replikace služby Event Hubs poskytuje replikaci metadat (entit, konfigurace a vlastností) i dat (datových částí událostí) pro obor názvů, což umožňuje provozní kontinuitu a zotavení po havárii.

Poznámka:

Funkce geografické replikace služby Event Hubs je dostupná jenom na úrovni Premium a Dedicated.

Tato funkce zajišťuje, aby se metadata a data oboru názvů průběžně replikovaly z primární oblasti do sekundární oblasti. Obor názvů lze považovat za rozšířený do více než jedné oblasti, přičemž jedna oblast je primární a druhá je sekundární.

Sekundární oblast může být kdykoli povýšena tak, aby se stala primární oblastí. Pozvednutí sekundární role mění plně kvalifikovaný název domény (FQDN) oboru názvů na vybranou sekundární oblast a předchozí primární oblast je snížena na sekundární oblast.

Scénáře

Geografickou replikaci služby Event Hubs je možné použít v několika různých scénářích, jak je popsáno zde.

Zajištění kontinuity podnikových procesů a zotavení po havárii

Geografická replikace zajišťuje zotavení po havárii a provozní kontinuitu pro všechna streamovaná data ve vašem oboru názvů. Replikací dat napříč oblastmi můžou organizace chránit před ztrátou dat a zajistit, aby jejich aplikace zůstaly v provozu i v případě regionálního výpadku. Tato funkce je zásadní pro klíčové aplikace, které vyžadují vysokou dostupnost a minimální prostoje.

Globální distribuce dat

Geografickou replikaci je možné použít k globální distribuci dat a umožnit aplikacím přístup k datům z nejbližší oblasti. Tím se snižuje latence a zvyšuje výkon úloh umístěných v různých částech světa.

Suverenita dat a dodržování předpisů

Organizace provozující ve více zemích nebo oblastech často potřebují dodržovat zákony o suverenitě dat, které vyžadují uložení dat v konkrétních geografických hranicích. Geografická replikace umožňuje těmto organizacím replikovat data do oblastí, které jsou v souladu s místními předpisy, a zajistit tak, aby splňovaly právní požadavky a zachovaly jednotnou datovou platformu.

Migrace a upgrady

Geografická replikace se dá použít také k usnadnění migrace, údržby dat a upgradů systému. Organizace můžou proaktivně migrovat jmenný prostor z primární do sekundární oblasti, aby umožnily provádění údržby a upgradů v primární oblasti.

Základní koncepty

Funkce geografické replikace implementuje metadata a replikaci dat v primárním sekundárním modelu replikace. V daném okamžiku existuje jedna primární oblast, která obsluhuje producenty i spotřebitele. Sekundární oblast funguje jako region v horké záloze, což znamená, že s těmito sekundárními oblastmi není možné interagovat. Spustí se ale ve stejné konfiguraci jako primární oblast, což umožňuje rychlé povýšení a připravenost k nasazení po dokončení povýšení.

Mezi klíčové aspekty funkce replikace geografických dat patří:

• Model replikace primární sekundární – geografická replikace je založená na modelu replikace primární sekundární, kde v daném okamžiku existuje pouze jeden primární obor názvů, který obsluhuje producenty událostí a příjemce událostí.
• Služba Event Hubs provádí plně spravovanou replikaci bajt po bajtu metadat, dat událostí a offsetu příjemců mezi sekundárními uzly s nakonfigurovanými úrovněmi konzistence.
• Jeden název hostitele oboru názvů – Po úspěšné konfiguraci oboru názvů s povoleným Geo-Replication můžou uživatelé ve své klientské aplikaci použít název hostitele oboru názvů. Název hostitele se chová jako nezávislý na nakonfigurovaných primárních a sekundárních oblastech a vždy odkazuje na primární oblast.
• Když zákazník zahájí akci, název hostitele odkazuje na oblast, která byla vybrána jako nová primární oblast. Původní primární oblast se stane sekundární oblastí.
• V sekundárních oblastech není možné číst ani zapisovat.
• Povýšení spravované zákazníkem z primární do sekundární oblasti, které zajišťuje plnou kontrolu a přehlednost pro řešení výpadků. K dispozici jsou metriky, které vám můžou pomoct automatizovat povýšení na straně zákazníka. Sekundární oblasti je možné přidat nebo odebrat podle vlastního uvážení zákazníka.
• Konzistence replikace – Existují dvě nastavení konzistence replikace, synchronní a asynchronní.

Stát	Schéma
Před přepnutím na záložní systém (povýšení záložního)
Po převzetí služeb při selhání (povýšení sekundárního)

Režimy replikace

Existují dvě konfigurace konzistence replikace, synchronní a asynchronní. Je důležité znát rozdíly mezi těmito dvěma konfiguracemi, protože mají vliv na vaše aplikace a konzistenci dat.

Asynchronní replikace

Pomocí asynchronní replikace se všechny požadavky potvrdí na primárním serveru, po kterém se klientovi odešle potvrzení. Replikace do sekundárních oblastí probíhá asynchronně. Uživatelé mohou nakonfigurovat maximální přijatelnou dobu prodlevy – posun služby mezi nejnovější akcí v primární a sekundární oblasti. Služba nepřetržitě replikuje data a metadata a zajišťuje, aby prodleva zůstala co nejmenší. Pokud prodleva aktivního sekundárního objektu překročí nakonfigurovanou maximální prodlevu replikace uživatele, primární zahájí omezování příchozích požadavků.

Synchronní replikace

Pomocí synchronní replikace se všechny požadavky replikují do sekundární, která musí operaci potvrdit a dokončit před potvrzením na primární. Vaše aplikace se proto publikuje rychlostí, jakou trvá zveřejnění, replikace, potvrzení a uzavření. Navíc to znamená, že vaše aplikace je svázaná s dostupností obou oblastí. Pokud sekundární oblast zaostává nebo je nedostupná, zprávy nebudou potvrzeny a zapsány a primární bude omezovat příchozí požadavky.

Porovnání konzistence replikace

Se synchronní replikací:

• Latence je delší kvůli operacím potvrzení v distribuovaném systému.
• Dostupnost je svázaná s dostupností dvou oblastí. Pokud dojde k výpadku jedné oblasti, váš obor názvů není dostupný.

Na druhou stranu synchronní replikace poskytuje největší jistotu, že jsou vaše data v bezpečí. Pokud máte synchronní replikaci, po potvrzení se potvrdí ve všech oblastech, které jste nakonfigurovali pro geografickou replikaci, a zajistí tak nejlepší záruku dat.

S asynchronní replikací:

• Latence je ovlivněna minimálně.
• Ztráta sekundární oblasti okamžitě neovlivní dostupnost. Dostupnost je ovlivněna, jakmile je dosaženo nakonfigurované maximální prodlevy replikace.

Proto nemá absolutní jistotu, že všechny oblasti obdrží data před jejich potvrzením, jako je tomu u synchronní replikace, a může dojít ke ztrátě nebo duplikaci dat. Protože už ale nemáte okamžitý dopad na prodlevu v jedné oblasti nebo je nedostupná, dostupnost aplikace se kromě nižší latence zlepší.

Schopnost	Synchronní replikace	Asynchronní replikace
Oneskorení přenosu	Kvůli distribuovaným potvrzovacím operacím delší	Minimálně ovlivněno
Dostupnost	Svázané s dostupností sekundárních oblastí	Ztráta sekundární oblasti nemá okamžitě vliv na dostupnost
Konzistence dat	Data jsou vždy zapsána v obou regionech před potvrzením.	Data zapsaná v primárním serveru pouze před potvrzením přijetí
cíl bodu obnovení (RPO)	RPO 0, žádná ztráta dat při povýšení	RPO > 0, možné ztráty dat při povýšení

Režim replikace lze po konfiguraci geografické replikace změnit. Můžete přejít ze synchronního na asynchronní nebo z asynchronního na synchronní. Pokud přejdete z asynchronního na synchronní, sekundární se nakonfiguruje jako synchronní, jakmile prodleva dosáhne nuly. Pokud běžíte s nepřetržitou prodlevou z jakéhokoli důvodu, možná budete muset pozastavit vydavatele, aby prodleva dosáhla nuly a váš režim mohl přepnout na synchronní. Důvody povolení synchronní replikace místo asynchronní replikace jsou svázané s důležitostí dat, specifickými obchodními potřebami nebo důvody dodržování předpisů místo dostupnosti vaší aplikace.

Poznámka:

V případě prodlevy sekundární oblasti nebo nedostupnosti už aplikace nebude moct replikovat do této oblasti a po dosažení prodlevy replikace se zahájí omezování. Chcete-li nadále používat obor názvů v hlavním umístění, lze odebrat zasaženou sekundární oblast. Pokud nejsou nakonfigurovány další sekundární oblasti, obor názvů pokračuje bez toho, aby bylo Geo-Replication povoleno. Další sekundární oblasti je možné kdykoli přidat. Entity nejvyšší úrovně, což jsou centra událostí, se replikují synchronně bez ohledu na nakonfigurovaný režim replikace.

Výběr sekundární oblasti

Pokud chcete povolit funkci geografické replikace, musíte použít primární a sekundární oblasti, kde je tato funkce povolená. Funkce geografické replikace závisí na možnosti replikovat publikované zprávy z primární do sekundárních oblastí. Pokud je sekundární oblast na jiném kontinentu, má to významný dopad na prodlevu replikace od primární do sekundární oblasti. Pokud z důvodů dostupnosti používáte geografickou replikaci, je nejlepší, když jsou sekundární oblasti alespoň na stejném kontinentu, kde je to možné. Pokud chcete lépe porozumět latenci vyvolané geografickou vzdáleností, můžete se dozvědět více ze statistik latence zpáteční cesty sítě Azure.

Poznámka:

Geografická replikace vyžaduje, aby primární a sekundární kopie služby Event Hubs byly na stejné úrovni. Konfiguraci nelze provést napříč úrovněmi.

Správa geografické replikace

Funkce geografické replikace umožňuje zákazníkům nakonfigurovat sekundární oblast, do které se mají replikovat metadata a data. Zákazníci proto můžou provádět následující úlohy správy:

• Konfigurace geografické replikace – Sekundární oblasti je možné nakonfigurovat v libovolném novém nebo existujícím oboru názvů v oblasti s povolenou funkcí Geo-Replication.
• Konfigurujte konzistenci replikace – Synchronní a asynchronní replikace se nastaví, když je nakonfigurovaná Geo-Replication, ale dá se také přepnout později.
• Vyvolání povýšení/převzetí služeb při selhání – Všechny povýšení jsou iniciované zákazníkem.
• Odebrat sekundární oblast – Pokud chcete odebrat sekundární oblast, můžete to udělat po odstranění dat v sekundární oblasti.

Kritéria pro aktivaci povýšení

Tady je několik případů, kdy se může aktivovat povýšení sekundární jednotky na primární jednotku.

• Regionální výpadek: Pokud dojde k regionálnímu výpadku, který má vliv na primární oblast, měli byste sekundární oblast propagovat, abyste zajistili provozní kontinuitu a minimalizovali výpadky.

• Aktivity údržby: Během aktivit plánované údržby v primární oblasti může podpora sekundární oblasti pomoct udržovat vysokou dostupnost pro důležité aplikace.

• Zotavení po havárii: V případě havárie ovlivňující primární oblast zajištění aktivace sekundární oblasti zajistí, že vaše data zůstanou přístupná a vaše aplikace budou dál fungovat.

• Problémy s výkonem: Pokud u primární oblasti dochází k problémům s výkonem, které mají vliv na dostupnost nebo spolehlivost služby Event Hubs, může zvýšení úrovně sekundární oblasti pomoct tyto problémy zmírnit.

Doporučuje se občas testovat mechanismy převzetí služeb při selhání, aby se zajistilo, že je plán kontinuity podnikových procesů efektivní a v případě potřeby se vaše aplikace můžou bezproblémově přepnout do sekundární oblasti.

Monitorování replikace dat

Uživatelé můžou sledovat průběh úlohy replikace monitorováním metriky prodlevy replikace v protokolech metrik aplikace.

• Povolení protokolů application Metrics v oboru názvů služby Event Hubs po monitorování služby Azure Event Hubs – Azure Event Hubs | Microsoft Learn.

• Jakmile jsou protokoly metrik aplikací povoleny, je třeba několik minut generovat a využívat data z namespace, než se začnou zobrazovat protokoly.

• Pokud chcete zobrazit protokoly metrik aplikace, přejděte na stránku Služby Event Hubs do části Monitorování a v nabídce vlevo vyberte Protokoly . Pomocí následujícího dotazu můžete najít prodlevu replikace (v sekundách) mezi primárním a sekundárním oborem názvů.

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

• Sloupec count_d označuje prodlevu replikace v sekundách mezi primární a sekundární oblastí.

Publikování dat

Publikační aplikace mohou posílat data do geograficky replikovaných oborů názvů prostřednictvím hostname oboru názvů s povolenou geografickou replikací. Přístup k publikování je stejný jako v případě bez geografické replikace a nevyžadují se žádné změny sad SDK roviny dat ani klientských aplikací.

Publikování událostí nemusí být dostupné za následujících okolností:

• Po vyžádání povýšení sekundární oblasti stávající primární oblast odmítne všechny nové události publikované v centru událostí.
• Když prodleva replikace mezi primárními a sekundárními oblastmi dosáhne maximální doby trvání prodlevy replikace, může dojít k omezení úlohy příchozího přenosu dat vydavatele.

Aplikace publisheru nemají přímý přístup k žádným oborům názvů v sekundárních oblastech.

Využívání dat

Aplikace mohou využívat data pomocí názvu hostitele oboru názvů s povolenou funkcí geografické replikace. Spotřebitelské operace nejsou podporovány od okamžiku, kdy je povýšení zahájeno, až do jeho dokončení.

Správa kontrolních bodů nebo posunu

Aplikace využívající události můžou dál udržovat správu posunu, protože by to dělaly s nereplikovaným oborem názvů, který není geograficky replikovaný. Pro správu posunu pro obory názvů s povolenou geografickou replikací není potřeba brát ohled na žádná zvláštní opatření.

Výstraha

V případě vynuceného neřízeného převzetí služeb při selhání může dojít ke ztrátě některých dat, která se ještě mají zkopírovat. To může způsobit, že ofsety těchto konkrétních dat budou rozdílné v primární a sekundární oblasti oboru názvů, avšak stále by to bylo v rámci maximální prodlevy replikace nakonfigurované pro obor názvů. V takových případech je vhodnější začít využívat od posledního potvrzeného offsetu. Některá data můžou mít duplicitní zpracování a musí být zpracována na straně klienta.

Kafka

Posuny jsou potvrzeny do služby Event Hubs přímo a posuny se replikují napříč oblastmi. Spotřebitelé mohou proto začít konzumovat od místa, kde skončili, v primární oblasti.

Tady je seznam podporovaných klientů Apache Kafka –

Název klienta	Version
Apache Kafka	2.1.0 nebo novější
Librdkafka a odvozené knihovny	2.1.0 nebo novější

V případě jiných knihoven se podporují ty, které používají následující verze rozhraní API –

Název rozhraní API	Podporovaná verze
Rozhraní API metadat	7 nebo novější
Rozhraní Fetch API	9 nebo novější
ListOffset API	4 nebo novější
Rozhraní API pro načtení offsetu	5 nebo novější
OffsetForLeaderEpoch API	0 nebo novější

Event Hubs SDK/AMQP

V případě AMQP spravuje kontrolní bod uživatelé s úložištěm kontrolních bodů, jako je Azure Blob Storage nebo vlastní řešení úložiště. Pokud dojde k přepnutí při selhání, úložiště kontrolních bodů musí být dostupné ze sekundárního regionu, aby klienti mohli načíst data kontrolního bodu a vyhnout se ztrátě zpráv.

Nejnovější verze sady Event Hubs SDK provedla určité změny v reprezentaci kontrolních bodů, aby podpořila převzetí služeb při selhání. Doporučujeme používat nejnovější verze sad SDK, ale podporují se i předchozí verze následujících sad SDK.

Jazyk	Název balíčku
jazyk C#	Azure.Messaging.EventHubs
jazyk C#	Microsoft.Azure.EventHubs

Výstraha

V rámci implementace se formát kontrolního bodu přizpůsobí, když je v oboru názvů povolená geografická replikace. Další kontrolní body budou zapsány v novém formátu po dokončení geografické replikace. Pokud vynutíte povýšení sekundární oblasti na primární hned po dokončení párování geografické replikace, ale před uložením nového kontrolního bodu (to se může stát v případě vynuceného povýšení nebo převzetí služeb při selhání), mohou být ztracena nová data publikovaná po povýšení.

V takových případech je vhodnější začít využívat od posledního potvrzeného offsetu. Některá data můžou mít duplicitní zpracování a musí být zpracována na straně klienta.

Doporučuje se také upgradovat na nejnovější verze sad SDK.

Úvahy

Mějte na paměti následující aspekty, které je potřeba vzít v úvahu s touto funkcí:

• Při plánování povýšení byste také měli zvážit časový faktor. Pokud například ztratíte připojení na dobu 15 až 20 minut, můžete se rozhodnout zahájit promo akci.
• Propagace komplexní distribuované infrastruktury by měla být alespoň jednou nacvičena.

Ceny

Ceny se liší podle úrovně, kterou vyberete, ale obecně má 2 parametry –

• Poplatek za využití výpočetních prostředků pro cluster nebo namespace.
• Poplatek za šířku pásma pro replikovaná data mezi primárními a sekundárními oblastmi.

Poznámka:

Podrobnosti o cenách najdete ve službě Azure Event Hubs, abyste zjistili poplatky. Poplatek za geografickou replikaci závisí na umístění primární oblasti.

Vyhrazené clustery

Použití geografické replikace s vyhrazenou službou Event Hubs vyžaduje, abyste měli alespoň dva vyhrazené clustery v samostatných oblastech, které je možné použít k hostování oborů názvů jiných než těch, které se geograficky replikují. Tyto vyhrazené clustery se účtují samostatně na základě počtu jednotek kapacity (CU) přidělených jednotlivým jednotkám.

Pokud je povolená geografická replikace, jediným dodatečným poplatkem je poplatek za šířku pásma pro data replikovaná z primární do sekundární. Tento poplatek závisí na umístění primární oblasti.

Prémiové jmenné prostory

U jmenných prostorů Premium povolení geografické replikace zřídí stejný počet jednotek zpracování (PU) v sekundární oblasti. Platíte tedy za počet jednotek PU, které používáte, a šířku pásma pro přenášená data mezi primární a sekundární oblastí.

Pokud například povolíte geografickou replikaci v oboru názvů Premium, který byl zřízen s 4 PU, bude vám účtováno

• 4 PU v primární oblasti,
• 4 PU v sekundární oblasti
• Poplatky za geografickou replikaci za GB replikovaných dat

Šířka pásma se účtuje na základě dat přenášených mezi primárními a sekundárními oblastmi.

Cenové měřiče

Cenové měřiče poplatku za šířku pásma přenosu dat geografické replikace se zobrazí s následujícími podrobnostmi.

Název produktu	Popis měřiče
Sběrnice	Service Bus – Přenos dat v geografické replikační zóně 1 GB – NÁZEV REGIONU
Sběrnice	Service Bus – Přenos dat 2 GB v zóně georeplikace – NÁZEV OBLASTI
Sběrnice	Service Bus – Přenos 3 GB dat v zóně geografické replikace – NÁZEV OBLASTI

Privátní koncové body

Tato část obsahuje další aspekty při použití Geo-Replication s obory názvů, které využívají privátní koncové body. Obecné informace o používání privátních koncových bodů se službou Event Hubs najdete v tématu Integrace služby Azure Event Hubs se službou Azure Private Link.

Při implementaci Geo-Replication pro obor názvů služby Event Hubs, který používá privátní koncové body, je důležité vytvořit privátní koncové body pro primární i sekundární oblasti. Tyto koncové body by měly být nakonfigurované pro virtuální sítě hostující primární i sekundární instance vaší aplikace. Pokud máte například dvě virtuální sítě, VNET-1 a VNET-2, musíte v oboru názvů služby Event Hubs vytvořit dva privátní koncové body pomocí podsítí z VNET-1 a VNET-2. Virtuální sítě by navíc měly být nastavené s partnerským vztahem mezi oblastmi, aby klienti mohli komunikovat s některým z privátních koncových bodů. Nakonec musí být DNS spravováno takovým způsobem, aby všichni klienti získali informace DNS, které by měly nasměrovat koncový bod oboru názvů (namespacename.servicebus.windows.net) na IP adresu privátního koncového bodu v aktuální primární oblasti.

Důležité

Při propagaci sekundárního regionu pro službu Event Hubs je potřeba také aktualizovat položku DNS, aby odkazovala na odpovídající koncový bod.

Výhodou tohoto přístupu je, že proces failoveru může probíhat nezávisle buď na aplikační vrstvě, nebo v oboru názvů Event Hubs.

• Selhání pouze aplikace: V tomto scénáři se aplikace přesune z VNET-1 na VNET-2. Jelikož jsou privátní koncové body nakonfigurované jak pro primární, tak sekundární obory názvů v rámci VNET-1 i VNET-2, aplikace funguje bez problémů.
• Převzetí služeb při selhání pouze na úrovni oboru názvů Event Hubs: Podobně platí, že pokud k převzetí služeb při selhání dojde pouze na úrovni oboru názvů Event Hubs, zůstane aplikace funkční, protože privátní koncové body jsou nakonfigurované v obou virtuálních sítích.

Podle těchto pokynů můžete zajistit robustní a spolehlivé mechanismy převzetí služeb při selhání pro obory názvů služby Event Hubs pomocí privátních koncových bodů.

Související obsah

Informace o použití funkce geografické replikace najdete v tématu Použití geografické replikace.