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í. 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.
Výpadek se definuje jako dočasná nedostupnost služby Azure Service Bus. Výpadek může mít vliv na některé komponenty služby Service Bus, jako je úložiště zpráv nebo dokonce celé datové centrum. Po vyřešení problému bude služba Service Bus opět dostupná. 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í.
Havárie se definuje jako trvalá ztráta jednotky škálování služby Service Bus nebo datacentra. Datacentrum může nebo nemusí být znovu dostupné. Havárie obvykle způsobuje ztrátu některých nebo všech zpráv nebo jiných dat. Příkladem katastrof jsou požáry, záplavy nebo zemětřesení.
Ochrana před výpadky a haváriemi – úroveň Premium
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).
Geografické zotavení po havárii
Úroveň Service Bus Premium 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 zotavení po havárii, která je dostupná jenom pro skladovou položku 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ů.
Zóny dostupnosti
Úroveň Service Bus Úrovně Premium podporuje zóny dostupnosti, které 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 pro úroveň Premium je dostupná jenom v oblastech Azure, kde se nacházejí zóny dostupnosti.
Při vytváření oboru názvů úrovně Premium prostřednictvím portálu se pro obor názvů automaticky povolí podpora zón dostupnosti (pokud je dostupná ve vybrané oblasti). Když vytvoříte obor názvů úrovně Premium prostřednictvím jiných mechanismů, jako jsou šablony Azure Resource Manageru nebo šablony Bicep, rozhraní příkazového řádku nebo PowerShell, musí být vlastnost zoneRedundant explicitně nastavená tak, aby true povoluje zóny dostupnosti (pokud jsou ve vybrané oblasti k dispozici). 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.
Ochrana před výpadky a haváriemi – úroveň Standard
Pokud chcete dosáhnout odolnosti proti výpadkům datacentra s cenovou úrovní standardního zasílání zpráv, 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.
Ukázka [geografické replikace s úrovní Standard služby Service Bus][Geografická replikace s úrovní Standard služby Service Bus] demonstruje aktivní replikaci entit zasílání zpráv.
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: