Osvědčené postupy pro ochranu aplikací před haváriemi a výpadky služby Service Bus
Nepostradatelné aplikace musí fungovat nepřetržitě, a to i v případě neplánovaných výpadků nebo havárií. Odolnost proti katastrofálním výpadkům prostředků zpracování dat je požadavkem pro mnoho podniků a v některých případech dokonce vyžaduje oborová nařízení. Tento článek popisuje techniky, které můžete použít k ochraně aplikací Service Bus před potenciálním výpadkem nebo havárií služby.
Azure Service Bus už rozšiřuje riziko katastrofických selhání jednotlivých počítačů nebo dokonce dokončuje racky napříč clustery, které zahrnují více domén selhání v rámci datacentra, a implementuje mechanismy transparentní detekce selhání a převzetí služeb při selhání tak, aby služba dál fungovala v rámci zaručených úrovní služeb a obvykle bez znatelných přerušení, pokud k takovým selháním dojde.
Kromě toho se riziko výpadku dále rozprostírá mezi tři fyzicky oddělená zařízení (zóny dostupnosti) a služba má dostatek rezerv kapacity, aby se okamžitě dokázala vypořádat s kompletní katastrofickou ztrátou datacentra. Plně aktivní model clusteru Azure Service Bus v rámci domény selhání spolu s podporou zóny dostupnosti je nadřazený všem místním produktům zprostředkovatele zpráv z hlediska odolnosti proti vážným selháním hardwaru a dokonce i katastrofické ztrátě celých zařízení datacentra. Přesto může dojít k vážným situacím s rozsáhlou fyzickou zničením, proti kterým ani tato opatření nemohou dostatečně bránit.
Funkce geografického zotavení po havárii a geografické replikace služby Service Bus jsou navržené tak, aby se snadněji zotavily z havárie této velikosti a opustily neúspěšnou oblast Azure, a to bez nutnosti měnit konfigurace aplikací.
Výpadky a havárie
Je důležité si uvědomit rozdíl mezi "výpadky" a "haváriemi".
Výpadek je dočasná nedostupnost služby Azure Service Bus a může mít vliv na některé komponenty služby, jako je úložiště zpráv nebo dokonce celé datové centrum. Po vyřešení problému se ale service Bus znovu zpřístupní. Výpadek obvykle nezpůsobí ztrátu zpráv nebo jiných dat. Příkladem selhání komponenty je nedostupnost konkrétního úložiště zpráv. Příkladem výpadku celého datacentra je selhání napájení datacentra nebo vadný síťový přepínač datacentra. Výpadek může trvat několik minut až několik dní. Některé výpadky jsou pouze krátké ztráty připojení kvůli přechodným problémům nebo problémům se sítí.
Havárie se definuje jako trvalá nebo dlouhodobější ztráta clusteru Service Bus, oblasti Azure nebo datacentra. Oblast nebo datacentrum může nebo nemusí být znovu k dispozici nebo může být po dobu hodin nebo dnů nedostupná. Příkladem takových katastrof jsou požáry, záplavy nebo zemětřesení. Havárie, která se stane trvalou, může způsobit ztrátu některých zpráv, událostí nebo jiných dat. Ve většině případů by ale nemělo dojít ke ztrátě dat a po zálohování datového centra je možné obnovit zprávy.
Ochrana před výpadky a haváriemi
Existují dvě funkce, které poskytují geografické zotavení po havárii ve službě Azure Service Bus pro úroveň Premium. Nejprve existuje geografická zotavení po havárii (zotavení po havárii metadat) poskytující replikaci metadat (entity, konfigurace, vlastnosti). Za druhé je k dispozici geografická replikace, která je aktuálně ve verzi Public Preview a poskytuje replikaci metadat i dat (změny vlastností zpráv a vlastností zpráv / stavu). Funkce geografického zotavení po havárii by neměla být zaměňována s Zóny dostupnosti. Bez ohledu na to, jestli se jedná o zotavení po havárii metadat nebo geografickou replikaci, zajišťují funkce obnovení geografické grafiky odolnost mezi oblastmi Azure, jako jsou USA – východ a USA – západ.
Zóny dostupnosti jsou k dispozici na všech úrovních služby Service Bus a podpora zajišťuje odolnost v rámci konkrétní geografické oblasti, jako je USA – východ. Podrobné informace o zotavení po havárii v Microsoft Azure najdete v tomto článku.
Koncepty vysoké dostupnosti a zotavení po havárii jsou integrované přímo do úrovně Premium služby Azure Service Bus, a to jak ve stejné oblasti (prostřednictvím zón dostupnosti), tak napříč různými oblastmi (prostřednictvím geografického zotavení po havárii a geografické replikace).
Možnosti geografického zotavení po havárii
Geografické zotavení po havárii
Úroveň Premium služby Service Bus podporuje geografické zotavení po havárii na úrovni oboru názvů. Další informace najdete v tématu Geografické zotavení po havárii služby Azure Service Bus. Funkce Geografické zotavení po havárii, která je dostupná jenom pro úroveň Premium, implementuje zotavení po havárii metadat a spoléhá na primární a sekundární obory názvů. Při geografickém zotavení po havárii se replikují pouze metadata entit mezi primárními a sekundárními obory názvů.
Geografická replikace
Úroveň Premium služby Service Bus podporuje také geografickou replikaci na úrovni oboru názvů. Další informace najdete v tématu Geografická replikace služby Azure Service Bus (Public Preview). Funkce geografické replikace, která je dostupná jenom pro úroveň Premium a aktuálně ve verzi Public Preview, implementuje metadata a zotavení po havárii dat a spoléhá na primární a sekundární oblasti. Při geografické replikaci se metadata i data entit replikují mezi primárními a sekundárními oblastmi.
Rozdíly ve funkcích vysoké úrovně
Funkce Geografické zotavení po havárii (Metadata DR) replikuje metadata oboru názvů z primárního oboru názvů do sekundárního oboru názvů. Podporuje pouze jednorázové převzetí služeb při selhání do sekundární oblasti. Během převzetí služeb při selhání iniciovaného zákazníkem se název aliasu oboru názvů znovu nastaví na sekundární obor názvů a pak se párování přeruší. Žádná data se nereplikují jinak než metadata ani nejsou replikovaná přiřazení RBAC.
Funkce geografické replikace replikuje metadata a všechna data z primární oblasti do jedné nebo více sekundárních oblastí. Když zákazník provede převzetí služeb při selhání, stane se vybraná sekundární primární a předchozí primární server se stane sekundární. Uživatelé můžou v případě potřeby provést převzetí služeb při selhání zpět na původní primární server.
Zóny dostupnosti
Všechny úrovně služby Service Bus podporují zóny dostupnosti a poskytují izolovaná umístění v izolovaném stavu v rámci stejné oblasti Azure. Service Bus spravuje tři kopie úložiště zpráv (1 primární a 2 sekundární). Service Bus uchovává všechny tři kopie synchronizované pro operace správy a dat. Pokud primární kopie selže, jedna ze sekundárních kopií se zvýší na primární bez vnímaných výpadků. Pokud aplikace vidí přechodné odpojení od služby Service Bus, logika opakování v sadě SDK se automaticky znovu připojí ke službě Service Bus.
Když používáte zóny dostupnosti, metadata i data (zprávy) se replikují napříč datovými centry v zóně dostupnosti.
Poznámka:
Podpora zón dostupnosti je dostupná jenom v oblastech Azure, kde se nacházejí zóny dostupnosti.
Při vytváření oboru názvů se pro obor názvů automaticky povolí podpora zón dostupnosti (pokud je dostupná ve vybrané oblasti). Za použití této funkce nejsou žádné další poplatky a po vytvoření oboru názvů tuto funkci nemůžete zakázat ani povolit.
Poznámka:
Dříve bylo nutné nastavit vlastnost zoneRedundant tak, aby true povolovala zóny dostupnosti, ale toto chování se ve výchozím nastavení změnilo tak, aby povolovalo zóny dostupnosti. Existující obory názvů se migrují do zón dostupnosti, kde je to možné, a tato vlastnost zoneRedundant je zastaralá. Vlastnost zoneRedundant se může stále zobrazovat jako false, i když jsou povolené zóny dostupnosti.
Existující obory názvů, které se migrují:
- Aktuálně nemá povolené zóny dostupnosti.
- Oblast podporuje zóny dostupnosti.
- Oblast má dostatečnou kapacitu zóny dostupnosti.
Ochrana před haváriemi – úroveň Standard
Pokud chcete dosáhnout odolnosti proti haváriím s úrovní Standard služby Service Bus, můžete použít aktivní nebo pasivní replikaci. Pro každý přístup, pokud daná fronta nebo téma musí zůstat přístupné v případě výpadku datacentra, můžete ho vytvořit v obou oborech názvů. Obě entity můžou mít stejný název. Primární fronta je například dostupná v contosoPrimary.servicebus.windows.net/myQueue, zatímco její sekundární protějšek je možné dosáhnout v contosoSecondary.servicebus.windows.net/myQueue.
Poznámka:
Aktivní replikace a nastavení pasivní replikace jsou řešení pro obecné účely, nikoli specifické funkce služby Service Bus. Logika replikace (odesílání do 2 různých oborů názvů) je v aplikacích odesílatele a příjemce musí mít vlastní logiku pro detekci duplicit.
Pokud aplikace nevyžaduje trvalou komunikaci mezi odesílatelem a příjemcem, může aplikace implementovat odolnou frontu na straně klienta, aby se zabránilo ztrátě zpráv a stínění odesílatele před přechodnými chybami služby Service Bus.
Aktivní replikace
Aktivní replikace používá entity v obou oborech názvů pro každou operaci. Každý klient, který odešle zprávu, odešle dvě kopie stejné zprávy. První kopie se odešle do primární entity (například contosoPrimary.servicebus.windows.net/sales) a druhá kopie zprávy se odešle sekundární entitě (například contosoSecondary.servicebus.windows.net/sales).
Klient přijímá zprávy z obou front. Příjemce zpracuje první kopii zprávy a druhá kopie se potlačí. Pokud chcete potlačit duplicitní zprávy, musí odesílatel označit každou zprávu jedinečným identifikátorem. Obě kopie zprávy musí být označené stejným identifikátorem. K označení zprávy můžete použít vlastnosti ServiceBusMessage.MessageId nebo ServiceBusMessage.Subject nebo vlastní vlastnost. Příjemce musí udržovat seznam zpráv, které už přijal.
Poznámka:
Přístup aktivní replikace zdvojnásobí počet operací, takže tento přístup může vést k vyšším nákladům.
Pasivní replikace
V případě bez selhání používá pasivní replikace pouze jednu ze dvou entit zasílání zpráv. Klient odešle zprávu aktivní entitě. Pokud operace s aktivní entitou selže s kódem chyby, který indikuje, že datacentrum, které je hostitelem aktivní entity, nemusí být k dispozici, klient odešle kopii zprávy do zálohované entity. V tomto okamžiku aktivní entity a entity zálohování přepínají role. Odesílající klient považuje starou aktivní entitu za novou zálohovanou entitu a stará zálohovací entita je nová aktivní entita. Pokud oba operace odesílání selžou, role obou entit zůstanou beze změny a vrátí se chyba.
Klient přijímá zprávy z obou front. Vzhledem k tomu, že příjemce obdrží dvě kopie stejné zprávy, musí příjemce potlačit duplicitní zprávy. Duplikáty můžete potlačit stejným způsobem, jak je popsáno pro aktivní replikaci.
Obecně platí, že pasivní replikace je úspornější než aktivní replikace, protože ve většině případů se provádí pouze jedna operace. Latence, propustnost a peněžní náklady jsou identické s nereplikovaným scénářem.
Při použití pasivní replikace se v následujících scénářích můžou zprávy ztratit nebo přijímat dvakrát:
- Zpoždění nebo ztráta zprávy: Předpokládejme, že odesílatel úspěšně odeslal zprávu m1 do primární fronty a pak fronta přestane být k dispozici, než příjemce obdrží m1. Odesílatel odešle následující zprávu m2 do sekundární fronty. Pokud je primární fronta dočasně nedostupná, příjemce obdrží m1 po opětovném zpřístupnění fronty. Když dojde k havárii, příjemce nemusí nikdy obdržet m1.
- Duplicitní příjem: Předpokládejme, že odesílatel odešle zprávu m do primární fronty. Service Bus úspěšně zpracuje m, ale neodešle odpověď. Po vypršení časového limitu operace odeslání odešle odesílatel identickou kopii m do sekundární fronty. Pokud příjemce dokáže přijmout první kopii m před tím, než se primární fronta stane nedostupnou, příjemce obdrží obě kopie m přibližně ve stejnou dobu. Pokud příjemce nemůže přijmout první kopii m před tím, než se primární fronta stane nedostupnou, příjemce nejprve obdrží pouze druhou kopii m, ale pak obdrží druhou kopii m, jakmile bude primární fronta k dispozici.
Úlohy replikace zasílání zpráv Azure s ukázkou .NET Core demonstrují replikaci zpráv mezi obory názvů.
Další kroky
Další informace o zotavení po havárii najdete v těchto článcích: