Spolehlivost v Azure Cosmos DB

Azure Cosmos DB pro NoSQL je globálně distribuovaná databázová služba s více modely, která podporuje datové modely dokumentů s flexibilními schématy. Azure Cosmos DB nabízí komplexní funkce spolehlivosti, včetně několika úrovní konzistence, které umožňují vyvážit výkon a dostupnost, zónově redundantní nasazení, která chrání před selháními zón dostupnosti, replikací ve více oblastech pomocí převzetí služeb spravovaného službou nebo převzetím služeb při selhání spravovaném zákazníkem a možnostmi průběžného a pravidelného zálohování pro ochranu dat.

Při používání Azure je spolehlivost sdílenou odpovědností. Microsoft nabízí celou řadu možností, které podporují odolnost a obnovení. Zodpovídáte za pochopení toho, jak tyto možnosti fungují ve všech službách, které používáte, a výběrem možností, které potřebujete ke splnění vašich obchodních cílů a cílů dostupnosti.

Tento článek popisuje, jak zajistit odolnost služby Azure Cosmos DB vůči různým potenciálním výpadkům a problémům, včetně přechodných chyb, výpadků zón dostupnosti, výpadků oblastí a údržby služby. Popisuje také, jak se zálohy používají k zotavení z jiných typů problémů a zvýrazňují klíčové informace o smlouvě o úrovni služeb (SLA) Azure Cosmos DB.

Doporučení pro nasazení do produkčního prostředí

Azure Well-Architected Framework poskytuje doporučení týkající se spolehlivosti, zabezpečení, nákladů, provozu a výkonu. Informace o tom, jak se tyto oblasti navzájem ovlivňují a jak přispívají ke spolehlivému řešení Azure Cosmos DB, naleznete v článku Osvědčené postupy architektury pro Azure Cosmos DB.

Přehled architektury spolehlivosti

Tato část popisuje některé důležité aspekty fungování služby, které jsou z hlediska spolehlivosti nejrelevantní. Tato část představuje logickou architekturu, která obsahuje některé prostředky a funkce, které nasazujete a používáte. Popisuje také fyzickou architekturu, která poskytuje podrobnosti o tom, jak služba funguje v zákulisí.

Logická architektura

Primárním prostředkem, který nasadíte, je Azure Cosmos DB account. Každý účet může mít více databází s více kontejnery. Kontejnery slouží jako logické jednotky distribuce a škálovatelnosti. Kontejnery, jako jsou kolekce, tabulky a grafy, můžete vytvářet v závislosti na rozhraní API, které používáte k interakci s Azure Cosmos DB. Další informace o modelu prostředků najdete v tématu Databases, kontejnery a položky v Azure Cosmos DB. Každý kontejner používá dělení, které podporuje vysoké škálování a vysoký výkon.

Nakonfigurujete propustnost, která představuje množství systémových prostředků, které můžete použít k dotazování a práci s daty. Propustnost můžete zřídit ručně, pomocí automatického škálování dynamicky upravit kapacitu na základě požadavků vaší úlohy nebo použít typ bezserverového účtu , který se bude účtovat za skutečné využití.

Jeden účet může zahrnovat více oblastí Azure, což zvyšuje odolnost vůči výpadkům oblastí. Pro čtení můžete nakonfigurovat více oblastí a pokud používáte úroveň Pro důležité obchodní informace, můžete pro psaní použít více oblastí. Azure Cosmos DB automaticky geograficky replikuje vaše data. Chování geografické replikace je ovlivněno konfigurací, kterou používáte, například úrovní konzistence, která označuje, jak chcete zajistit kompromis mezi konzistencí dat, dostupností, latencí a propustností. Různé úrovně konzistence jsou optimalizované pro různé aspekty, podporují různé záruky a poskytují různé typy replikace mezi oblastmi.

Fyzická architektura

Azure Cosmos DB ukládá několik replik vašich dat pro zajištění redundance. Služba automaticky zmírní výpadky replik tím, že udržuje kvorum napříč replikami v každé oblasti. Tento přístup zaručuje vysokou dostupnost a chrání před ztrátou dat během selhání jednotlivých uzlů bez nutnosti změn nebo konfigurace aplikace.

Azure Cosmos DB interně spravuje vaše data pomocí různých konstrukcí, včetně fyzických oddílů, sad oddílů a sad replik. Podrobnější informace o tom, jak Azure Cosmos DB funguje, najdete v článku Globální distribuce dat s Azure Cosmos DB – pod kapotou.

Odolnost proti přechodným chybám

Přechodné chyby jsou krátká, přerušovaná selhání ve složkách. V distribuovaném prostředí, jako je cloud, se vyskytují často a jsou normální součástí provozu. Přechodné chyby se opravují po krátké době. Je důležité, aby vaše aplikace mohly zpracovávat přechodné chyby, obvykle opakováním ovlivněných požadavků.

Všechny aplikace hostované v cloudu by měly postupovat podle Azure pokynů pro zpracování přechodných chyb, když komunikují s libovolnými rozhraními API, databázemi a dalšími komponentami hostovanými v cloudu. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

Použijte sady SDK Azure Cosmos DB. Sady SDK automaticky implementují podporu pro řadu aspektů odolnosti, včetně přechodného zpracování chyb prostřednictvím automatických opakovaných pokusů a plnění odpovědí na omezení rychlosti odesílaných službou. Další informace najdete v tématu Design odolných aplikací pomocí sad SDK Azure Cosmos DB.

Při práci s účtem s více oblastmi podporuje sada SDK také strategii dostupnosti založenou na prahové hodnotě, označovanou také jako hedging, kde odesílá paralelní žádosti o čtení do více oblastí a přijímá nejrychlejší odpověď. Tento přístup může zlepšit výkon aplikace, když oblast dočasně zaznamená vyšší latenci než obvykle.

Odolnost proti chybám zóny dostupnosti

Zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci oblasti Azure. Když jedna zóna selže, mohou služby přejít na jednu ze zbývajících zón.

Azure Cosmos DB podporuje redundanci zón. Když povolíte redundanci zón, Azure distribuuje repliky dat do několika zón dostupnosti a zajišťuje odolnost problémů a výpadků datacentra. Microsoft vybere zóny dostupnosti, které se mají použít.

Diagram zobrazující účet Azure Cosmos DB se sadou replik, která obsahuje tři repliky, které se distribuují mezi tři samostatné zóny dostupnosti.

Účet Azure Cosmos DB může používat více oblastí (umístění) pro globální distribuci, škálování a převzetí služeb při selhání. Redundanci zón nakonfigurujete zvlášť pro každou oblast ve vašem účtu.

Použití redundance zón v Azure Cosmos DB nemá žádný rozpoznatelný vliv na výkon nebo latenci. Nevyžaduje žádné úpravy vybraného režimu konzistence a nevyžaduje žádné úpravy kódu aplikace.

Používejte redundanci zón v oblastech, kde je podporovaná, zejména pro účty s jednou oblastí. Vzhledem k tomu, že zóny dostupnosti jsou fyzicky oddělené a poskytují různé zdroje napájení, sítě a chlazení, jsou smlouvy SLA dostupnosti pro Azure Cosmos DB vyšší pro zónově redundantní účty než účty, které nepoužívají zóny dostupnosti.

Tip

Povolení redundance zón je skvělý způsob, jak zvýšit odolnost databáze Azure Cosmos DB bez zavedení dalších složitostí aplikací nebo ovlivnění výkonu. V závislosti na konfiguraci vašeho účtu nemusí ani vzniknout další náklady.

Pokud nepovolíte redundanci zóny, účet je v této oblasti nezonální . Nezonální účty mohou mít repliky umístěné v jediné zóně dostupnosti, což může vést k výpadku, pokud v této konkrétní zóně dojde k problému.

Requirements

  • Region support: V oblastech Azure podporujících zóny dostupnosti můžete povolit redundanci zón. Pokud chcete zjistit, jestli vaše oblast podporuje zóny dostupnosti, podívejte se na seznam podporovaných oblastí.

    Redundance zón není nastavení pro celý účet. Azure Cosmos DB účty můžou zahrnovat více oblastí a každou oblast je možné nakonfigurovat nezávisle na používání zón dostupnosti. Oblasti, které nepodporují zóny dostupnosti, nezabrání v povolení redundance zón v jiných oblastech ve stejném účtu.

  • Bezserverové účty: Zónově redundantní účty bez serveru můžete nakonfigurovat jenom při jejich vytváření. Existující účty bez serveru bez zón dostupnosti nemůžete převést na konfiguraci zóny dostupnosti. Pro klíčové úlohy použijte zřízenou propustnost.

Úvahy

  • Několik souběžných výpadků zón: Účet jedné oblasti s redundancí zóny může udržovat dostupnost pro čtení i zápis, když výpadek ovlivní jednu zónu dostupnosti. Pokud však výpadek ovlivní více zón dostupnosti nebo celou oblast, účty v jedné oblasti ztratí přístup pro čtení a zápis, dokud se služba neobnoví. Pokud potřebujete být odolní proti selhání několika zón najednou, zvažte nasazení účtu ve více oblastech.

  • Účty ve více oblastech: Pokud máte účet ve více oblastech, můžete volitelně povolit redundanci zón v libovolné nebo všech oblastech účtů, které podporují zóny dostupnosti. Důrazně doporučujeme povolit redundanci zón, když je váš účet nakonfigurovaný tak, aby používal jednu oblast, nebo pokud je nakonfigurovaná tak, aby používala jednu oblast zápisu s více oblastmi čtení.

Náklady

Regiony, kde je povolená zónová redundance, jsou zpoplatněny vyšší sazbou. U účtů nakonfigurovaných s více oblastmi se však pro účty nakonfigurované s více oblastmi a pro kolekce nakonfigurované tak, aby používaly režim propustnosti automatického škálování, se však vzdává cen úrovně Premium pro zóny dostupnosti. Další informace najdete v tématu o cenách služby Azure Cosmos DB.

Konfigurujte podporu zón dostupnosti

U většiny účtů povolíte redundanci zón jenom v případě, že do účtu Azure Cosmos DB přidáte novou oblast. Pokud chcete povolit podporu zóny dostupnosti u existujícího účtu, přidejte do ní oblast a povolte redundanci zóny. Můžete postupovat podle procesu a přidat dočasnou oblast, abyste mohli nakonfigurovat redundanci zón v původní oblasti. Podrobný postup najdete v tématu Povolení redundance zóny pro účet Azure Cosmos DB.

U bezserverových účtů musíte při vytváření účtu povolit redundanci zóny.

Chování, když jsou všechny zóny v pořádku

Tato část popisuje, co očekávat, když nakonfigurujete účet Azure Cosmos DB pro redundanci zón a všechny zóny jsou funkční.

  • Provoz napříč zónami: Azure Cosmos DB automaticky směruje požadavky na repliky napříč zónami dostupnosti, takže každý požadavek může obsloužit jakákoli replika.

  • Replikace dat mezi zónami: Když klient provede změnu dat, použije se tato změna na více replik v různých zónách, aby se dosáhlo kvora. Tento přístup se označuje jako synchronní replikace. Synchronní replikace zajišťuje vysokou úroveň konzistence dat, což snižuje pravděpodobnost ztráty dat během selhání zóny. Zóny dostupnosti se nacházejí relativně blízko sebe, což znamená, že latence nebo propustnost je minimální.

Chování při selhání zóny

Tato část popisuje, co očekávat, když nakonfigurujete účet Azure Cosmos DB pro redundanci zón a v jedné ze zón dojde k výpadku.

  • Detekce a reakce: Platforma Azure Cosmos DB zodpovídá za detekci selhání v zóně dostupnosti. Nemusíte dělat nic, abyste zahájili převzetí zóny.
  • Oznámení: Microsoft vás automaticky neoznámí, když je zóna mimo provoz. Pomocí Azure Resource Health ale můžete monitorovat stav jednotlivých prostředků a můžete nastavit výstrahy Resource Health, které vás upozorní na problémy. Pomocí služby Azure Service Health můžete také porozumět celkovému stavu služby, včetně jakýchkoli selhání zón, a můžete nastavit upozornění služby Service Health , která vás upozorní na problémy.

  • Active requests: Když zóna dostupnosti přestane být dostupná, Azure Cosmos DB ukončí všechny probíhající požadavky připojené k replikám v ovlivněné zóně a aplikace musí tyto požadavky opakovat. Podle pokynů pro zpracování přechodných chyb se ujistěte, že je vaše aplikace připravená.

  • Očekávaná ztráta dat: Při selhání zóny nedošlo k žádné očekávané ztrátě dat.

  • Očekávaný výpadek: Během výpadků zóny mohou připojení zaznamenat krátká přerušení, která obvykle trvají několik sekund během redistribuce provozu. Podle pokynů pro zpracování přechodných chyb se ujistěte, že jsou vaše aplikace připravené.

  • Redistribution: Azure Cosmos DB automaticky přesměrovává příchozí požadavky na funkční repliky v jiných zónách dostupnosti. Pokud dojde k výpadku zóny dostupnosti, platforma automaticky přerozdělí vyhrazenou propustnost na ostatní repliky.

Obnovení zóny

Když se zóna dostupnosti obnoví, Azure Cosmos DB automaticky obnoví repliky v zóně dostupnosti a směruje provoz mezi replikami jako obvykle.

Testování poruch zón

Převzetí služeb při selhání a obnovení zóny dostupnosti pro Azure Cosmos DB jsou plně spravované Microsoft. Nemusíte spouštět ani ověřovat postupy při selhání zóny dostupnosti.

Odolnost proti selháním v celé oblasti

Když nasadíte účet Azure Cosmos DB v jedné oblasti, výpadek v celé oblasti, který ovlivní všechny uzly Azure Cosmos DB, obvykle nezpůsobí ztrátu dat, ale zabrání aplikaci v přístupu k datům. Azure Cosmos DB obnoví přístup k datům po obnovení služby v ovlivněné oblasti. Ke ztrátě dat dochází pouze v případě, že oblast dojde k neopravitelné havárii.

Pokud se chcete připravit na vzácné případy výpadků oblastí, můžete nakonfigurovat Azure Cosmos DB tak, aby podporovaly různé úrovně stálosti a dostupnosti pomocí jednoho z těchto přístupů:

Následující tabulka shrnuje dostupné možnosti obnovení na základě konfigurace účtu a typu výpadku. Další části tohoto článku obsahují podrobné informace o těchto možnostech a přidruženém chování.

Konfigurace Typ výpadku Dopad na dostupnost Dopad na odolnost Co dělat
Účet jedné oblasti Výpadek v oblasti Přístup pro čtení a zápis se ztratí, dokud se služba neobnoví. Žádná ztráta dat, pokud oblast nepostihne katastrofa, ze které se nelze zotavit. Počkejte na obnovení služby nebo požádejte o obnovení účtu ze zálohy do jiné oblasti.
Oblast s jedním zápisem, účet s více oblastmi Výpadek oblasti čtení Sada SDK směruje do dostupných oblastí na základě konfigurace upřednostňovaných oblastí.

U účtů, které používají silnou konzistenci jen ve dvou oblastech nebo omezenou zastaralost překračující interval zastaralosti, se také ztratí dostupnost zápisu, pokud neodstavíte postiženou oblast.		 Žádná ztráta dat. Zajistěte dostatečnou propustnost ve zbývajících oblastech. Pokud chcete konzistenci silné nebo omezené nestarosti, zvažte přechádět ovlivněnou oblast do offline režimu.
Oblast s jedním zápisem, účet s více oblastmi Výpadek oblasti zápisu (s povoleným PPAF) Automatické převzetí služeb při selhání na úrovni partic; bez nutnosti ručního zásahu. Pokud účet používá silnou konzistenci, žádná ztráta dat. Pokud účet nepoužívá silnou konzistenci, mohou být nereplikovaná data ztracena v nepravděpodobném případě, že v oblasti dojde k trvalé ztrátě dat. Nevyžaduje se žádná akce. PPAF automaticky zajišťuje převzetí služeb při selhání.
Oblast s jedním zápisem, účet s více oblastmi Výpadek oblasti zápisu (bez PPAF) Možnost zápisu nebude k dispozici, dokud nebude dokončena offline operace oblasti nebo službou spravované převzetí služeb při selhání. Čtení pokračuje z bezchybných oblastí. Pokud účet používá silnou konzistenci, žádná ztráta dat. Pokud účet nepoužívá silnou konzistenci, mohou být nereplikovaná data ztracena v nepravděpodobném případě, že v oblasti dojde k trvalé ztrátě dat. Proveďte operaci oblasti v režimu offline. Pokud je povolené převzetí služeb při selhání spravované službou, Azure Cosmos DB zahájí převzetí služeb při selhání automaticky, ale může to trvat jednu nebo více hodin. Během výpadku neměňte oblast zápisu.
Účet oblasti s více možnostmi zápisu Výpadek libovolné oblasti Automatické směrování do funkčních oblastí pomocí konfigurace sady SDK; bez nutnosti ručního zásahu. Nedávno aktualizovaná data v oblasti, která selhala, můžou být ve zbývajících oblastech nedostupná. V nepravděpodobném případě, že oblast trpí trvalou ztrátou dat, může dojít ke ztrátě nereplicitovaných dat. Zajistěte dostatečnou propustnost ve zbývajících oblastech. Po obnovení Azure Cosmos DB automaticky obnoví nereplicitovaná data pomocí nakonfigurované metody řešení konfliktů.
Libovolná konfigurace účtu Poškození nebo náhodné odstranění dat Žádný dopad na dostupnost. Potenciální ztráta dat v závislosti na tom, kdy se zjistí poškození nebo odstranění. Obnovení dat k určitému bodu v čase (průběžná záloha) nebo obnovení dat z periodické zálohy.

Note

Tento článek se zaměřuje na aspekty spolehlivosti funkcí Azure Cosmos DB ve více oblastech. Existují další výhody pro více oblastí čtení a zápisu, jako je vyšší výkon a škálování pro globálně distribuované aplikace. Měli byste vyhodnotit celou architekturu řešení a zvážit všechny výhody používání těchto funkcí.

Sady SDK a odolnost proti chybám

Sady SDK Azure Cosmos DB jsou důležitou součástí strategie odolnosti vaší aplikace. Pokud máte účet s více oblastmi, má konfigurace sady SDK vliv na směrování požadavků mezi oblastmi, včetně upřednostňovaných oblastí pro připojení a oblastí, které by se měly vyloučit. Sady SDK monitorují dostupnost oblastí a oddílů a můžou se dynamicky překonfigurovat tak, aby používaly oblasti a oddíly v pořádku, například prostřednictvím jističe na úrovni oddílů.

Další informace o tom, jak sada SDK podporuje vysokou dostupnost, najdete v dokumentaci k vysoké dostupnosti pro sadu SDK, kterou používáte:

Potenciální ztráta dat během výpadků oblastí

Když nasadíte účet Azure Cosmos DB ve více oblastech, stálost dat závisí na úrovni konzistence, kterou pro účet nakonfigurujete. Následující tabulka uvádí pro všechny úrovně konzistence hodnotu cílového bodu obnovení (RPO) účtu Azure Cosmos DB nasazeného alespoň ve dvou oblastech. RPO představuje potenciální ztrátu dat během výpadku oblasti.

Úroveň konzistence RPO pro výpadek regionu
Relace, konzistentní předpona, konečný Méně než 15 minut
Omezená zastaralost K a T
Silný 0

K = počet verzí (tj. aktualizací) položky.

T = časový interval od poslední aktualizace.

U účtů s více oblastmi je minimální hodnota K a T 100 000 operací zápisu nebo 300 sekund. Tato hodnota určuje minimální hodnotu RPO pro data při použití omezené zastaralosti.

Další informace o rozdílech mezi úrovněmi konzistence najdete v tématu Úrovně konzistence ve službě Azure Cosmos DB.

Více oblastí čtení s jednou oblastí zápisu

Pokud vaše řešení vyžaduje nepřetržitou dobu provozu během výpadků oblastí, můžete nakonfigurovat Azure Cosmos DB pro replikaci dat do více oblastí s zápisy zpracovávanými vaší primární oblastí. Volitelně můžete nakonfigurovat aplikace tak, aby se připojovaly ke konkrétním oblastem čtení, což může pomoct zlepšit jejich výkon. Pokud má oblast výpadek, může účet dál fungovat z oblastí, které jsou v pořádku.

Diagram zobrazující účet Azure Cosmos DB. Oblast A je oblast zápisu a čtení a oblast B je oblast čtení. Aplikace v oblasti A provádí čtení a zápisy proti účtu Azure Cosmos DB v oblasti A. Aplikace v oblasti B provádí čtení s účtem v oblasti B, ale zapisuje do oblasti A. Interně Azure Cosmos DB replikuje změny mezi oblastmi.

Přepnutí při selhání mezi oblastmi

Sadu AZURE COSMOS DB SDK můžete nakonfigurovat se seznamem oblastí čtení s prioritou. Sada SDK připojí vaši aplikaci k první dostupné oblasti v seznamu. Během výpadku oblasti čtení sada SDK zjistí výpadek oblasti prostřednictvím kódů odpovědí back-endu, označí ji jako nedostupnou a směruje budoucí operace do další dostupné oblasti v seznamu předvoleb. Ujistěte se, že je seznam upřednostňovaných oblastí správně nastavený a aby odpovídal požadavkům vaší firmy a latence. Podrobné pokyny najdete v tématu Řešení potíží s dostupností sady SDK služby Azure Cosmos DB.

Převzetí služeb při selhání je proces, při kterém se jedna z oblastí vašeho účtu stane nedostupnou, a to buď zcela, nebo částečně. Dopad převzetí služeb při selhání závisí na tom, zda je oblast oblastí pro zápis, nebo oblastí pro čtení:

  • Pokud oblast zápisu přestane být dostupná, stane se oblastí zápisu jiná oblast.
  • Pokud oblast čtení přestane být dostupná, nemůže tato oblast obsluhovat žádosti o čtení a jiné oblasti se místo toho používají pro operace čtení.

Azure Cosmos DB poskytuje více typů převzetí služeb při selhání:

  • Automatické převzetí služeb při selhání pro každý oddíl (PPAF): Azure Cosmos DB interně distribuuje vaše data mezi několik fyzických oddílů. Pokud dojde k problému s infrastrukturou podporující oddíl, nemusí to mít vliv na další oddíly. PPAF umožňuje účtům s jednou zapisovatelnou oblastí automaticky při selhání přepnout jednotlivé oddíly do sekundární oblasti, zatímco funkční oddíly zůstávají v primární oblasti. PPAF může pomoct minimalizovat výpadky a umožnit rychlejší obnovení během částečného selhání oblasti. Další informace najdete v tématu Jak zavést a používat Per-Partition Automatic Failover (PPAF) pro Azure Cosmos DB.

  • Vynucený failover: Jeden z regionů svého účtu můžete odstavit. Také se tomu říká zákazníkem spravované převzetí služeb při selhání nebo provoz v offline oblasti. Tento postup se doporučuje pro rychlé obnovení dostupnosti během výpadku. Odpovídáte za detekci výpadku a spuštění přepnutí při selhání. Vynucená převzetí služeb při selhání můžete použít také k simulaci scénářů nedostupnosti oblasti pro účely testování, například během cvičení zotavení po havárii.

    Pokud přeberete oblast zápisu do offline režimu, oblast čtení s další nejvyšší prioritou se stane novou oblastí zápisu. Pokud oblast pro čtení odstavíte, vaše aplikace se mohou připojit k jakékoli jiné oblasti pro čtení v rámci účtu.

    Vynucené převzetí služeb při selhání vaší oblasti zápisu nese riziko ztráty dat u všech nereplikovaných zápisů.

    Po vynuceném převzetí služeb při selhání musí Microsoft oblast znovu uvést do provozu. U oblastí, které jsou v pořádku, je tento proces automatizovaný, ale může to trvat až několik dní. Pokud se oblast během dne nebo dvou nevrátí do online režimu, otevřete případ podpory a požádejte o pomoc.

  • Změnit oblast zápisu: Pokud jsou oblasti v pořádku, můžete změnit oblast zápisu vašeho účtu. Tato změna je fakticky plánované přepnutí při selhání oblasti pro zápis pro váš účet.

    Při změně oblasti zápisu nedojde ke ztrátě dat, protože replikace dat se zachytí před zvýšením úrovně nové oblasti zápisu. Může dojít k krátkému přerušení, ale klienti, kteří používají logiku opakování a jiné techniky zpracování přechodných chyb, obvykle nemají významný dopad.

    Tato operace vyžaduje, aby oblasti byly v bezchybném stavu, takže ji nelze použít během výpadku oblasti.

  • Převzetí službou při selhání: Když váš účet používá převzetí službou při selhání, Microsoft odpovídá za to, kdy dojde k převzetí při selhání mezi oblastmi. Chcete-li povolit službou spravované převzetí služeb při selhání, zadejte priority pro každý region. Proces deklarování výpadku a aktivace převzetí služeb při selhání spravované službou ale může trvat významnou dobu – potenciálně jednu nebo více hodin. Pro rychlejší obnovu proveďte vynucené převzetí při selhání místo čekání, až se spustí automatické převzetí při selhání spravované službou.

    Pokud Microsoft iniciuje službou spravované převzetí služeb při selhání pro oblast zápisu účtu, mohlo by dojít ke ztrátě nereplikovaných zápisů.

    Po převzetí služeb při selhání spravované službou musí Microsoft vrátit oblast zpět do režimu online. Microsoft automaticky přenese oblast do online režimu, ale tento proces může trvat několik dní.

Requirements

Region support: Pro svůj účet Azure Cosmos DB můžete nakonfigurovat libovolnou oblast Azure jako oblast čtení.

Náklady

Přidání další oblasti čtení do účtu Azure Cosmos DB zvyšuje vaše stávající náklady na každou oblast. Další informace najdete v tématu o cenách služby Azure Cosmos DB.

Konfigurace několika oblastí čtení

Plánování a řízení kapacit

Pokud vaše aplikace rozloží požadavky napříč oblastmi a jedna oblast přejde do režimu offline, zbývající oblasti mají větší objem požadavků. Propustnost automatického škálování můžete použít k dynamické úpravě kapacity na základě poptávky. Pokud používáte předem zajištěnou propustnost, naplánujte dostatečnou kapacitu tak, aby bylo možné zvládnout výpadek regionu bez zhoršení služby, a zvažte naddimenzování kapacity. Pro více informací viz Správa kapacity s nadměrným přidělováním.

Chování, když jsou všechny oblasti v pořádku

Tato část popisuje, co očekávat, když nakonfigurujete účet Azure Cosmos DB s více oblastmi čtení a všechny oblasti jsou funkční.

Chování při selhání oblasti čtení

Tato část popisuje, co očekávat, když nakonfigurujete účet Azure Cosmos DB s více oblastmi čtení a dojde k výpadku v jedné z oblastí čtení účtu.

Important

V ideálním případě by se výpadky oblastí čtení měly zpracovávat na úrovni klienta správnou konfigurací seznamu upřednostňovaných oblastí v konfiguraci sady SDK. Je-li sada SDK správně nakonfigurována, automaticky zjistí výpadek a přesměruje operace čtení do další dostupné oblasti bez nutnosti přepnutí při selhání na straně služby.

  • Detekce a reakce: Odpovědnost za detekci výpadku a reakci na něj závisí na typu mechanismu převzetí služeb při selhání, který váš účet používá.

    • PPAF: PPAF se obvykle nevztahuje na výpadky oblasti čtení. U účtů se silnou konzistencí a pouze dvěma oblastmi ale ztráta oblasti čtení snižuje účet na jednu oblast, která nemůže udržovat dynamické kvorum. V tomto scénáři se může PPAF aktivovat, aby zachoval dostupnost přesunutím dotčených oddílů do zdravého regionu.

    • Vynucené převzetí služeb při selhání: Jste odpovědní za provedení vynuceného převzetí služeb při selhání. Podrobné kroky najdete v tématu Provedení vynuceného převzetí při selhání pro svůj účet Azure Cosmos DB.

      Pokud neprovedete převzetí služeb při selhání, chování účtu závisí na úrovni konzistence:

      • Silná konzistence: Silná konzistence vyžaduje pro zachování dynamického kvora dvě nebo více oblastí. Pokud jsou k dispozici méně než dvě oblasti a neprovedete převzetí služeb při selhání (failover), účet ztratí možnost zápisu až do obnovení služby.

      • Konzistence s omezenou zastaralostí: Konzistence s omezenou zastaralostí je založena na udržování konkrétního prahu zastaralosti mezi regiony. Pokud délka výpadku oblasti překročí prahovou hodnotu, systém nemůže udržovat konzistenci mezi zápisy. Pokud neprovedete převzetí služeb při selhání, účet ztratí dostupnost zápisu až do obnovení služby.

    • Převzetí služeb při selhání řízené službou: Pokud je povoleno převzetí služeb při selhání řízené službou, Microsoft časem rozpozná výpadek a zahájí proces převzetí služeb při selhání pro váš účet. Tento proces ale může trvat významnou dobu, potenciálně jednu nebo více hodin. Pro rychlejší obnovu proveďte vynucené převzetí při selhání místo čekání, až se spustí automatické převzetí při selhání spravované službou.

  • Oznámení: Microsoft vás automaticky neoznámí, když je oblast mimo provoz. Mějte však na paměti následující:

  • Aktivní požadavky: Veškeré aktivní požadavky mohou být ukončeny a klient je po dokončení převzetí služeb při selhání musí zopakovat. Pokud vaši klienti zpracovávají přechodné chyby odpovídajícím způsobem opakovaným pokusem po krátké době, obvykle se vyhýbají významnému dopadu.

  • Očekávaná ztráta dat: Výpadek v oblasti čtení nezpůsobí ztrátu dat. Azure Cosmos DB nadále dodržuje záruky konzistence při čtení.

  • Očekávaný výpadek: Délka výpadku účtu závisí na typu mechanismu převzetí služeb při selhání, který je pro váš účet použit.

    • PPAF: Pokud je povolená služba PPAF, systém automaticky zjistí a obnoví se při selhání, obvykle během 3 minut bez ručního zásahu.

    • Vynucený failover: Výpadek závisí na:

      • Jak dlouho vám trvá zjistit výpadek a zahájit přepnutí při selhání.

      • Jak dlouho trvá přepnutí při selhání, obvykle několik sekund.

        Výstraha

        Během výpadku neprovádějte v zasaženém regionu žádné konfigurační operace (v rovině řízení), protože vedou k nekonzistenci účtu a zpoždění obnovy. Mezi příklady operací řídicí roviny, kterým se třeba vyhnout, patří:

        • Změnit oblast zápisu nebo upravit prioritu převzetí služeb při selhání
        • Aktualizujte účet na vícezápisovou konfiguraci
        • Aktualizace úrovní konzistence nebo jiných nastavení účtu
        • Aktualizace konfigurací privátních koncových bodů nebo nastavení sítě
        • Aktualizace propustnosti nebo operací škálování účtu
        • Jakákoli jiná operace, která upravuje nastavení konfigurace účtu nebo oblasti

    • Převzetí služeb při selhání řízené službou: Microsoft odpovídá za zahájení převzetí služeb při selhání řízeného službou a doba nedostupnosti vašeho účtu závisí na tom, jak dlouho Microsoftu trvá vyhlásit výpadek a zahájit převzetí služeb při selhání. V některých situacích může trvat jednu nebo více hodin. Pokud u vašeho účtu dojde k narušení operací zápisu a potřebujete rychle obnovit možnost zápisu, proveďte vynucené převzetí služeb při selhání.

  • Přesměrování: Při vynuceném převzetí služeb při selhání nebo převzetí služeb při selhání spravovaném službou se dotčená oblast odpojí a označí jako offline.

    Pro zpracování výpadků oblasti čtení se v kódu aplikace nevyžadují žádné změny. Sady SDK Azure Cosmos DB přesměrovávají operace čtení do další dostupné oblasti v seznamu upřednostňovaných oblastí. Pokud není k dispozici žádná z oblastí v seznamu upřednostňovaných oblastí, operace čtení se automaticky vrátí do aktuální oblasti zápisu účtu nakonfigurované ve službě.

    Note

    Pokud používáte privátní koncové body s účtem Azure Cosmos DB, ujistěte se, že se privátní DNS správně směruje po operaci offline oblasti. Podrobné pokyny najdete v tématu Aspekty převzetí služeb při selhání pro privátní koncové body.

Chování při selhání regionu zápisu

Tato část popisuje, co očekávat, když nakonfigurujete účet Azure Cosmos DB s více oblastmi čtení a dojde k výpadku v oblasti zápisu účtu.

  • Detekce a reakce: Odpovědnost za detekci výpadku a reakci na něj závisí na typu mechanismu převzetí služeb při selhání, který váš účet používá.

    • PPAF: Microsoft automaticky zjistí výpadek a v případě potřeby zahájí převzetí služeb při selhání některých oddílů. Vaše aplikace nemusí provádět žádnou akci.

    • Vynucené převzetí služeb při selhání: Jste odpovědní za provedení vynuceného převzetí služeb při selhání. Podrobné kroky najdete v tématu Provedení vynuceného převzetí při selhání pro svůj účet Azure Cosmos DB.

      Pokud neprovedete převzetí služeb při selhání, účet ztratí dostupnost zápisu až do obnovení služby.

      Pokud dojde k výpadku oblasti pro zápis u vašeho účtu, neprovádějte operaci změnit oblast zápisu. Pokud dojde k výpadku zdrojové nebo cílové oblasti, změny oblastí zápisu nebudou úspěšné. Důvodem je, že postup změny oblasti zahrnuje kontrolu konzistence, která vyžaduje připojení mezi oblastmi.

    • Spravované převzetí služeb při selhání: Microsoft automaticky zjistí výpadek a zahájí převzetí služeb při selhání vašeho účtu. Vaše aplikace nemusí provádět žádnou akci.

  • Oznámení: Microsoft vás automaticky neoznámí, když je oblast mimo provoz. Mějte však na paměti následující:

  • Aktivní požadavky: Veškeré aktivní požadavky mohou být ukončeny a klient je po dokončení převzetí služeb při selhání musí zopakovat. Pokud vaši klienti zpracovávají přechodné chyby odpovídajícím způsobem opakovaným pokusem po krátké době, obvykle se vyhýbají významnému dopadu.

  • Očekávaná ztráta dat: Pokud konfigurujete účet se silnou konzistencí, nedojde ke ztrátě dat. Jinak může po dokončení převzetí služeb při selhání dojít ke ztrátě všech nereplikovaných zápisů. Informace o maximální ztrátě dat očekávané během výpadku oblasti najdete v tématu Potenciální ztráta dat během výpadků oblastí.

  • Očekávaný výpadek: Délka výpadku účtu závisí na typu mechanismu převzetí služeb při selhání, který je pro váš účet použit.

    • PPAF: Pokud je povolená služba PPAF, očekávejte krátké přerušení, což je obvykle přibližně 3 minuty.

    • Vynucený failover: Výpadek závisí na:

      • Jak dlouho vám trvá zjistit výpadek a zahájit přepnutí při selhání.
      • Jak dlouho trvá přepnutí při selhání, obvykle několik sekund.

    Výstraha

    Během scénářů výpadku neprovádějte žádné operace na kontrolní rovině v postižené oblasti, protože to vede ke nekonzistenci účtu a zpoždění obnovy. Mezi příklady operací řídicí roviny, kterým se třeba vyhnout, patří:

    • Změnit oblast zápisu nebo upravit prioritu převzetí služeb při selhání
    • Aktualizujte účet na vícezápisovou konfiguraci
    • Aktualizace úrovní konzistence nebo jiných nastavení účtu
    • Aktualizace konfigurací privátních koncových bodů nebo nastavení sítě
    • Aktualizace propustnosti nebo operací škálování účtu
    • Jakákoli jiná operace, která upravuje nastavení konfigurace účtu nebo oblasti
    • Převzetí služeb při selhání řízené službou: Microsoft odpovídá za zahájení převzetí služeb při selhání řízeného službou a doba nedostupnosti vašeho účtu závisí na tom, jak dlouho Microsoftu trvá vyhlásit výpadek a zahájit převzetí služeb při selhání. V některých situacích může trvat jednu nebo více hodin. Chcete-li rychle obnovit možnost zápisu, proveďte nucený failover.

  • Přerozdělování: Redistribuce provozu zápisu závisí na typu převzetí služeb při selhání, které váš účet používá.

    • PPAF: Azure Cosmos DB automaticky přepne nefunkční oddíl do zdravé oblasti.

    • Vynucené převzetí služeb při selhání: Při vynuceném převzetí služeb při selhání se oblast zápisu vašeho účtu změní na zadaná oblast.

    Note

    Pokud používáte privátní koncové body s účtem Azure Cosmos DB, ujistěte se, že se privátní DNS správně směruje po operaci offline oblasti. Podrobné pokyny najdete v tématu Aspekty převzetí služeb při selhání pro privátní koncové body.

    • Převzetí službou při selhání: Azure Cosmos DB automaticky povýší jednu ze sekundárních oblastí účtu na novou primární oblast pro zápis. Převzetí služeb při selhání nastane v jiné oblasti v pořadí podle priority oblasti, kterou zadáte.

Obnovení oblasti

Microsoft musí vrátit oblast zpátky do režimu online. Když se oblast obnoví po výpadku, Microsoft automaticky přenese oblast do režimu online. Tento proces ale může trvat několik dní.

Important

Po vynuceném převzetí služeb při selhání Microsoft automaticky přenese oblast zpět do režimu online pro oblasti, které jsou v pořádku. Pokud se oblast během dne nebo dvou nevrátí do online režimu, otevřete případ podpory a požádejte o pomoc.

Jakmile je oblast online, akce, které provedete, se liší v závislosti na tom, jestli došlo k výpadku v oblasti čtení nebo oblasti zápisu.

  • Po výpadku oblasti čtení: Když je ovlivněná oblast opět online, synchronizuje se s aktuální oblastí zápisu a je opět k dispozici pro obsluhu žádostí o čtení, jakmile ji plně zachytí. Následná čtení se přesměrují na zotavenou oblast bez toho, aby se musel nějak změnit kód aplikace. Během převzetí služeb při selhání i při opětovném připojení k dříve neúspěšné oblasti služba Azure Cosmos DB nadále dodržuje záruky konzistence čtení.

  • Pokud dojde k výpadku oblasti zápisu: Pokud je ovlivněná oblast zase online, zobrazí se oblast na portálu Azure jako online a bude dostupná jako oblast pro čtení. V tomto okamžiku je bezpečné změnit oblast zápisu zpět na obnovenou oblast.

    Important

    Obnovená oblast nebude po obnovení automaticky znovu nastavena jako oblast pro zápis. Je vaší zodpovědností změnit zpět na obnovenou oblast jako oblast zápisu, jakmile je to bezpečné.

    Před změnou oblasti zápisu nebo po změně oblasti zápisu nedošlo k žádné ztrátě dat ani dostupnosti . Vaše aplikace bude i nadále vysoce dostupná.

    Pokud některé zápisy nebyly replikovány předtím, než oblast přešla do režimu offline, můžete nereplikované zápisy přečíst z kanálu konfliktů. Vaše aplikace může číst informační kanál konfliktů, vyřešit případné konflikty na základě logiky specifické pro aplikaci a podle potřeby zapsat aktualizovaná data zpět do kontejneru.

Testování selhání regionů

Vaše aplikace nemusí správně zpracovávat převzetí služeb při selhání oblastí, i když je váš účet Azure Cosmos DB vysoce dostupný. Chcete-li v rámci testování aplikace nebo cvičení zotavení po havárii (DR) otestovat end-to-end vysokou dostupnost své aplikace, dočasně zakažte službou spravovaný failover u daného účtu. Vyvolejte vynucené převzetí služeb při selhání pomocí PowerShellu, Azure CLI nebo webu Azure Portal a pak monitorujte aplikaci. Po dokončení testu můžete po automatickém obnovení primární oblasti do online režimu přepnout zpět do primární oblasti a poté pro účet obnovit převzetí služeb při selhání spravované službou. Pokud se oblast během dne nebo dvou nevrátí do online režimu, otevřete případ podpory a požádejte o pomoc.

Pokud váš účet používá PPAF, můžete simulovat převzetí služeb při selhání oddílu. Další informace najdete v tématu Otestování nastavení PPAF (simulace chyby).

Více oblastí zápisu

Službu Azure Cosmos DB můžete nakonfigurovat tak, aby přijímala zápisy v několika oblastech. Tato konfigurace může poskytovat velmi vysokou odolnost vůči výpadkům oblastí. Je také užitečné snížit latenci zápisu v geograficky distribuovaných aplikacích.

Diagram zobrazující účet Azure Cosmos DB. Oblast A a oblast B jsou oblasti zápisu i čtení. Aplikace v oblasti A provádí čtení a zápisy proti účtu Azure Cosmos DB v oblasti A. Aplikace v oblasti B provádí čtení a zápisy proti účtu Azure Cosmos DB v oblasti B. Interně Azure Cosmos DB asynchronně replikuje změny mezi oblastmi.

Při konfiguraci účtu služby Azure Cosmos DB pro více oblastí zápisu se nepodporuje silná konzistence a můžou nastat konflikty zápisu. Oblast centra funguje jako arbiter v konfliktech zápisu. Další informace o řešení těchto konfliktů najdete v tématu Typy konfliktů a zásady řešení při použití více oblastí zápisu.

Je důležité zvážit návrh vaší aplikace a jeho fungování s několika oblastmi zápisu. Projděte si osvědčené postupy pro zápisy do více oblastí.

Requirements

Region support: Pro svůj účet Azure Cosmos DB můžete nakonfigurovat libovolnou oblast Azure jako oblast čtení nebo zápisu.

Náklady

Přidání další oblasti zápisu do účtu Azure Cosmos DB zvyšuje vaše stávající náklady na každou oblast. Další informace najdete v tématu o cenách služby Azure Cosmos DB.

Konfigurace několika oblastí zápisu

Při vytváření účtu nebo po vytvoření účtu můžete nakonfigurovat více oblastí zápisu. Další informace najdete v tématu Konfigurace více oblastí zápisu.

Aby bylo možné efektivně používat více oblastí zápisu, musí být vaše aplikace také správně nakonfigurovaná. Viz Konfigurace zápisů ve více oblastech v aplikacích, které používají Azure Cosmos DB.

Plánování a řízení kapacit

Pokud vaše aplikace rozloží požadavky napříč oblastmi a jedna oblast přejde do režimu offline, zbývající oblasti mají větší objem požadavků. Propustnost automatického škálování můžete použít k dynamické úpravě kapacity na základě poptávky. Pokud používáte předem zajištěnou propustnost, naplánujte dostatečnou kapacitu tak, aby bylo možné zvládnout výpadek regionu bez zhoršení služby, a zvažte naddimenzování kapacity. Pro více informací viz Správa kapacity s nadměrným přidělováním.

Chování, když jsou všechny oblasti v pořádku

Tato část popisuje, co očekávat, když nakonfigurujete účet Azure Cosmos DB s více oblastmi zápisu a všechny oblasti jsou funkční.

Chování při selhání oblasti

Tato část popisuje, co očekávat, když nakonfigurujete účet Azure Cosmos DB s více oblastmi zápisu a dojde k výpadku v jedné z oblastí čtení nebo zápisu účtu.

  • Detekce a odpověď: Vaše aplikace zjistí ztrátu oblasti. Azure Cosmos DB sady SDK poskytují možnosti automatického výběru oblastí, které směrují operace čtení a zápisu do oblastí, které jsou v pořádku.

  • Oznámení: Microsoft vás automaticky neoznámí, když je oblast mimo provoz. Mějte však na paměti následující:

  • Aktivní požadavky: Veškeré aktivní požadavky mohou být ukončeny a klient je po dokončení převzetí služeb při selhání musí zopakovat. Pokud vaši klienti zpracovávají přechodné chyby odpovídajícím způsobem opakovaným pokusem po krátké době, obvykle se vyhýbají významnému dopadu.

  • Očekávaná ztráta dat: Nedávno aktualizovaná data můžou být v jiných oblastech nedostupná. Informace o maximální ztrátě dat očekávané během výpadku oblasti najdete v tématu Potenciální ztráta dat během výpadků oblastí. V nepravděpodobném případě, že ovlivněná oblast trpí trvalou ztrátou dat, můžete ztratit nereplicitovaná data.

  • Očekávaný výpadek: V konfiguracích s vícenásobným zápisem se neočekává žádný výpadek, pokud jsou sady SDK správně nakonfigurovány pomocí ApplicationRegions nebo PreferredRegions.

    Tip

    Pro zajištění nejlepších výsledků by globální služba vyrovnávání zatížení měla předcházet globálně distribuovaným aplikacím, jako jsou Azure Front Door nebo Azure Traffic Manager. Tyto služby můžou detekovat regionální snížení výkonu a automaticky směrovat provoz do instancí aplikace v oblasti, která je v pořádku.

  • Redistribution: Sady SDK Azure Cosmos DB automaticky zjistí, že oblast není v pořádku, a přesměruje operace čtení a zápisu do další dostupné oblasti v seznamu upřednostňovaných oblastí. V kódu aplikace nejsou vyžadovány žádné změny.

    Tip

    Pokud je vaše aplikace nasazená za službami Azure Front Door nebo Traffic Manager, tyto služby také zjistí zhoršení stavu v dané oblasti a přesměrují provoz do zdravé oblasti.

Obnovení oblasti

Když je ovlivněná oblast zpět online, oblast se na portálu Azure zobrazí jako online a bude znovu dostupná.

Veškerá zapisovaná data, která nebyla replikována v době selhání oblasti, jsou k dispozici prostřednictvím kanálu kolizí. Aplikace můžou číst informační kanál konfliktů, vyřešit konflikty na základě logiky specifické pro aplikaci a podle potřeby zapsat aktualizovaná data zpět do kontejneru Azure Cosmos DB.

Testování selhání regionů

Pokud chcete otestovat scénáře převzetí služeb při selhání zápisu do více oblastí, můžete pomocí vynuceného převzetí služeb při selhání převést oblast zápisu do offline režimu. Tento proces simuluje výpadek oblasti a můžete sledovat, jak vaše aplikace reaguje.

Zálohování a obnovení

U většiny řešení byste se neměli spoléhat výhradně na zálohy. Místo toho využijte další funkce popsané v tomto průvodci k podpoře vašich požadavků na odolnost. Zálohy ale chrání před některými riziky, která jiné přístupy nechrání. Další informace najdete v tématu Co jsou redundance, replikace a zálohování?.

Ke ztrátě dat může dojít kvůli náhodnému odstranění nebo jiným problémům v aplikaci, které způsobují poškození dat. Pokud používáte účet v jedné oblasti, může dojít ke ztrátě dat také kvůli neopravitelné havárii v Azure Cosmos DB oblasti. Pro zajištění ochrany před ztrátou dat poskytuje Azure Cosmos DB sadu možností zálohování a obnovení. Zálohy a uchovávání můžete nakonfigurovat na základě požadavků na obnovitelnost a požadavků na náklady. Další informace najdete v tématu Online zálohování a obnovení dat na vyžádání ve službě Azure Cosmos DB.

Odolnost vůči údržbě služeb

Azure Cosmos DB transparentně spravuje všechny podrobnosti jednotlivých výpočetních uzlů a automaticky provádí opravy a další typy plánované údržby. Smlouvy SLA Azure Cosmos DB pro dostupnost a latenci platí prostřednictvím všech operací automatické údržby, které systém provádí.

Smlouva o úrovni služeb

Smlouva o úrovni služeb (SLA) pro služby Azure popisuje očekávanou dostupnost každé služby a podmínky, které musí vaše řešení splnit, aby bylo dosaženo očekávané dostupnosti. Další informace najdete v tématu Smlouvy SLA pro online služby.

Azure Cosmos DB poskytuje smlouvy SLA pro řadu konfigurací a charakteristik služeb, včetně dostupnosti, latence, propustnosti a konzistence.

Smlouvy SLA dostupnosti se liší v závislosti na tom, jestli používáte některou z následujících možností produktu:

  • Zřízená propustnost
  • Účet v jedné oblasti s podporou zón dostupnosti (redundance zón)
  • Účty, které používají více oblastí čtení
  • Účty, které používají více oblastí pro zápis (úroveň Business Critical)

Související obsah

  • Last updated on