Osvědčené postupy pro ochranu aplikací před haváriemi a výpadky služby Service Bus

Klíčové 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ě Service Bus aplikací před potenciálním výpadkem nebo havárií služby.

Výpadek je definován jako dočasná nedostupnost Azure Service Bus. Výpadek může mít vliv na některé součásti Service Bus, jako je úložiště zpráv nebo dokonce celé datové centrum. Po vyřešení problému se Service Bus znovu zpřístupní. Výpadek obvykle nezpůsobí ztrátu zpráv ani 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 chybný síťový přepínač datacentra. Výpadek může trvat několik minut až několik dní.

Havárie je definována jako trvalá ztráta jednotky škálování 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 proti výpadkům a katastrofám – Service Bus Premium

Koncepty vysoké dostupnosti a zotavení po havárii jsou integrované přímo do úrovně Azure Service Bus Premium, a to jak ve stejné oblasti (prostřednictvím Zóny dostupnosti), tak napříč různými oblastmi (prostřednictvím Geo-Disaster Recovery).

obnovení Geo-Disaster

Service Bus Premium podporuje geografické zotavení po havárii na úrovni oboru názvů. Další informace najdete v tématu Azure Service Bus geografické zotavení po havárii. Funkce zotavení po havárii dostupná pouze pro skladovou položku Premium, implementuje zotavení po havárii metadata a spoléhá na primární a sekundární obory názvů zotavení po havárii. Při Geo-Disaster Recovery se replikují pouze metadata pro entity mezi primárními a sekundárními obory názvů.

Zóny dostupnosti

Skladová položka Service Bus Premium podporuje Zóny dostupnosti a poskytuje izolovaná umístění selhání ve 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 upřednostní na primární bez vnímaných výpadků. Pokud aplikace uvidí přechodné odpojení od Service Bus, logika opakování v sadě SDK se automaticky znovu připojí k 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óny dostupnosti pro Azure Service Bus Premium je dostupná jenom v oblastech Azure, kde jsou k dispozici zóny dostupnosti.

Pomocí Azure Portal můžete povolit Zóny dostupnosti pouze u nových oborů názvů. Service Bus nepodporuje migraci existujících oborů názvů. Po povolení v oboru názvů není možné zakázat redundanci zóny.

1

Ochrana proti výpadkům a katastrofám – Service Bus Standard

Pokud chcete dosáhnout odolnosti proti výpadkům datacentra při použití cenové úrovně standardního zasílání zpráv, Service Bus podporuje dva přístupy: aktivní a pasivní replikace. 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. Například primární fronta je dostupná pod contosoPrimary.servicebus.windows.net/myQueue, zatímco sekundární protějšk je dostupný pod contosoSecondary.servicebus.windows.net/myQueue.

Poznámka

Nastavení aktivní replikace a pasivní replikace jsou řešení pro obecné účely, nikoli specifické funkce Service Bus. Logika replikace (odesílající do 2 různých oborů názvů) se nachází 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 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 primární entitě (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 každou zprávu označit 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 BrokeredMessage.MessageId nebo BrokeredMessage.Label nebo vlastní vlastnost. Příjemce musí udržovat seznam zpráv, které už obdržel.

Geografická replikace s ukázkou Service Bus úrovně Standard ukazuje 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ý označuje datacentrum, které hostuje aktivní entitu, může být nedostupné, klient odešle kopii zprávy do zálohovací entity. V tomto okamžiku aktivní a zálohovací entity přepínají role: odesílající klient považuje starou aktivní entitu za novou entitu zálohování a stará zálohovací entita je nová aktivní entita. Pokud obě operace odesílání selžou, role obou entit zůstanou nezměněné 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.

Pasivní replikace je obecně ú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 další 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. V případě havárie 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 může přijmout první kopii m před tím, než primární fronta přestane být k dispozici, 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ž primární fronta přestane být k dispozici, příjemce zpočátku obdrží pouze druhou kopii m, ale pak obdrží druhou kopii m, jakmile bude primární fronta k dispozici.

Geografická replikace s ukázkou Service Bus úrovně Standard ukazuje pasivní replikaci entit zasílání zpráv.

Ochrana koncových bodů přenosu před výpadky nebo haváriemi datacentra

Geografická replikace koncových bodů Azure Relay umožňuje službě, která zpřístupňuje koncový bod přenosu, aby byla dostupná v přítomnosti Service Bus výpadků. Aby služba dosáhla geografické replikace, musí vytvořit dva koncové body přenosu v různých oborech názvů. Obory názvů se musí nacházet v různých datacentrech a oba koncové body musí mít různé názvy. Například primární koncový bod je možné dosáhnout v rámci contosoPrimary.servicebus.windows.net/myPrimaryService, zatímco jeho sekundární protějšek je možné dosáhnout pod contosoSecondary.servicebus.windows.net/mySecondaryService.

Služba pak naslouchá na obou koncových bodech a klient může službu vyvolat prostřednictvím libovolného koncového bodu. Klientská aplikace náhodně vybere jednu z přenosů jako primární koncový bod a odešle svou žádost do aktivního koncového bodu. Pokud operace selže s kódem chyby, znamená to, že koncový bod přenosu není k dispozici. Aplikace otevře kanál pro koncový bod zálohování a žádost znovu odešle. V tomto okamžiku aktivní a koncové body zálohování přepínají role: klientská aplikace považuje starý aktivní koncový bod za nový koncový bod zálohování a starý koncový bod zálohování jako nový aktivní koncový bod. Pokud obě operace odesílání selžou, role obou entit zůstanou nezměněné a vrátí se chyba.

Další kroky

Další informace o zotavení po havárii najdete v těchto článcích: