Spolehlivost ve službě Azure Managed Redis

Azure Managed Redis je plně spravovaná služba Azure založená na Redis Enterprise. Poskytuje vysoce výkonné úložiště dat v paměti pro aplikace a je navržené pro podnikové úlohy, které vyžadují ultra-nízkou latenci, vysokou propustnost a pokročilé datové struktury.

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 Azure Managed Redis vůči nejrůznějším potenciálním výpadkům a problémům, včetně přechodných chyb, výpadků zón dostupnosti a výpadků oblastí. Popisuje také strategie zálohování a smlouvu o úrovni služeb (SLA).

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

Pokud chcete zajistit vysokou spolehlivost pro produkční instance Azure Managed Redis, doporučujeme:

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

Azure Managed Redis je založený na Redis Enterprise a poskytuje spolehlivost prostřednictvím konfigurací vysoké dostupnosti a možností replikace.

Nasadíte instanci Azure Managed Redis, která se také označuje jako instance mezipaměti nebo mezipaměť. Klientské aplikace ukládají data v mezipaměti a pracují s nimi pomocí rozhraní API Redis.

Fyzická architektura

Pokud plánujete-li zajištění odolnosti ve službě Azure Managed Redis, musíte porozumět klíčovým konceptům uzlů a shardů.

• Uzly: Každá instance mezipaměti se skládá z uzlů, což jsou virtuální počítače. Každý virtuální počítač slouží jako nezávislá výpočetní jednotka v clusteru. Virtuální počítače nevidíte ani nespravujete přímo. Platforma automaticky vytváří instance, monitoruje stav instance a nahrazuje všechny instance, které nejsou v pořádku. Tato sada virtuálních počítačů tvoří cluster.

  Instanci můžete nastavit na vysokou dostupnost. Pokud používáte vysokou dostupnost, Azure Managed Redis zajišťuje, že instance má aspoň dva uzly a automaticky replikuje data mezi nimi. V oblastech, které mají zóny dostupnosti, služba umístí uzly do různých zón dostupnosti. Další informace najdete v tématu Odolnost proti chybám zóny dostupnosti.

  Služba abstrahuje konkrétní počet uzlů v každé konfiguraci, aby se zabránilo složitosti a zajištění optimálních konfigurací.

• Střepy: Každý uzel spouští několik procesů serveru Redis nazývaných shardy. Každý shard spravuje podmnožinu dat z vaší cache. Když nastavíte mezipaměť s vysokou dostupností, shardy se automaticky distribuují a replikují mezi uzly. Zadáte zásady clusteru, které určují, jak se shardy distribuují mezi uzly.

Další informace najdete v tématu Architektura Azure Managed Redis a Přepínání při selhání a opravy pro Azure Managed Redis.

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 při komunikaci se všemi cloudovými rozhraními API, databázemi a dalšími komponentami postupovat podle pokynů pro zpracování přechodných chyb Azure. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

Při použití Azure Managed Redis postupujte podle těchto doporučení pro správu přechodných chyb:

• Použijte konfigurace sady SDK , které se automaticky opakují, když dojde k přechodným chybám, a použijte příslušná období výpadku a časového limitu. Zvažte použití Retry vzoru a vzor přerušení obvodu ve vašich aplikacích.

• Návrh pro vzor cache-aside, kdy vaše aplikace může nadále fungovat se sníženým výkonem tím, že se v případě dočasné nedostupnosti Redis přepne na primární úložiště dat.

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.

Instance azure Managed Redis Cache můžete nastavit jako zónově redundantní, což automaticky distribuuje uzly mezipaměti napříč několika zónami dostupnosti v rámci oblasti. Redundance zón snižuje riziko, že výpadky datového centra nebo zóny dostupnosti znepřístupní vaši mezipaměť.

Pokud chcete zónu mezipaměti nastavit jako redundantní, musíte ji nasadit v podporované oblasti a nastavit ji tak, aby používala konfiguraci vysoké dostupnosti. V oblastech bez zón dostupnosti konfigurace vysoké dostupnosti stále vytváří aspoň dva uzly, ale nejsou umístěné v samostatných zónách.

Následující diagram znázorňuje zónově redundantní mezipaměť se dvěma uzly, z nichž každý je v samostatné zóně.

Požadavky

• Podpora oblastí: Zónově redundantní mezipaměť Azure Managed Redis můžete nasadit do libovolné oblasti, která podporuje zóny dostupnosti a kde je služba dostupná. Seznam oblastí, které podporují zóny dostupnosti, najdete v oblastech Azure se zónami dostupnosti. Seznam oblastí, které podporují Azure Managed Redis, najdete v tématu Dostupnost produktů v jednotlivých oblastech.

• Konfigurace vysoké dostupnosti: Aby byla zónově redundantní, musíte v mezipaměti použít konfiguraci vysoké dostupnosti.

• Úrovně: Všechny úrovně Azure Managed Redis podporují zóny dostupnosti.

Náklady

Redundance zón vyžaduje, abyste si nastavili mezipaměť pro vysokou dostupnost, která nasadí minimálně dva uzly pro vaši mezipaměť. Konfigurace vysoké dostupnosti stojí více než konfigurace bez vysoké dostupnosti. Další informace najdete v tématu o cenách Azure Managed Redis.

Konfigurujte podporu zón dostupnosti

• Vytvořte novou zónově redundantní instanci. Když vytvoříte novou instanci Azure Managed Redis, použijte konfiguraci vysoké dostupnosti a nasaďte ji do oblasti, která podporuje zóny dostupnosti. Instance ve výchozím nastavení zahrnuje redundanci zón bez nutnosti další konfigurace.

  Další informace najdete v tématu Vytvoření instance Azure Managed Redis.

• Nastavení existující zóny instance jako redundantní. Pokud chcete stávající zónu instance Azure Managed Redis redundantní, nasaďte ji v oblasti, která podporuje zóny dostupnosti a nastaví vysokou dostupnost v mezipaměti.

• Vypněte redundanci zón. U existujících instancí nemůžete vypnout zónovou redundanci, protože po aplikaci na mezipaměť nelze vysokou dostupnost vrátit zpět.

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

Během události výpadku zóny může mít vaše instance k dispozici méně prostředků pro obsluhu vaší úlohy. Pokud u vaší instance často dochází k tlaku na prostředky a potřebujete se připravit na selhání zóny dostupnosti, zvažte jeden z následujících přístupů:

• Nadsadit kapacitu vaší instance. Vyberte vyšší úroveň výkonu, než potřebujete, aby instance snášela určitou ztrátu kapacity a nadále fungovala bez snížení výkonu. Další informace najdete v tématu Správa kapacity prostřednictvím nadměrného zřízení a škálování instance Azure Managed Redis.

• Použijte aktivní geografickou replikaci. Můžete nasadit více instancí v různých oblastech a nastavit aktivní geografickou replikaci , která rozdělí zatížení mezi tyto samostatné instance.

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

Tato část popisuje, co očekávat, když je spravovaná mezipaměť Redis zónově redundantní a všechny zóny dostupnosti fungují normálně:

• Směrování provozu mezi zónami: Azure Managed Redis distribuuje shardy mezi uzly na základě politiky clusteru. Zásady clusteru také určují, jak se provoz směruje do jednotlivých uzlů. Redundance zón nemění způsob, jakým služba směruje provoz.

• Replikace dat mezi zónami: Azure Managed Redis automaticky replikuje horizontální oddíly napříč uzly pomocí asynchronní replikace. Typicky měříte zpoždění replikace mezi shardami v sekundách, ale přesná doba trvání závisí na zatížení vaší cache. Scénáře náročné na zápis a sítě obvykle mají vyšší prodlevu replikace.

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

Tato část popisuje, co očekávat, když je spravovaná mezipaměť Redis zónově redundantní a jedna nebo více zón dostupnosti přestane být k dispozici:

• Detekce a odpověď: Azure Managed Redis 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 při výpadku zóny automaticky neoznámí. Azure Service Health ale můžete použít k pochopení celkového 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.

• Aktivní požadavky: Služba může vyřadit požadavky na testovací verze a aplikace by je měly opakovat. Aplikace by měly implementovat logiku opakování pro zpracování těchto dočasných přerušení.

• Očekávaná ztráta dat: Všechna data, která nebyla replikována do shardů v jiné zóně, mohou být ztracena během selhání zóny. Obvykle měříte množství ztráty dat v sekundách, ale závisí na prodlevě replikace.

• Očekávaný výpadek: K malému výpadku, obvykle 10 až 15 sekund, může dojít při převzetí shardů uzly v zónách, které jsou v pořádku. Další informace o neplánovaném procesu převzetí služeb při selhání najdete v tématu Vysvětlení převzetí služeb při selhání. Při návrhu aplikací dodržujte postupy pro zpracování přechodných chyb.

• Přesměrování provozu: Azure Managed Redis automaticky přesměruje provoz na uzly v zónách, které jsou v pořádku.

Obnovení zóny

Když se ovlivněná zóna dostupnosti obnoví, Azure Managed Redis automaticky obnoví operace do této zóny. Platforma Azure tento proces plně spravuje a nevyžaduje žádný zásah zákazníka.

Testování poruch zón

Azure Managed Redis plně spravuje směrování provozu, převzetí a obnovení služeb při selhání zóny, takže nemusíte ověřovat procesy selhání zón dostupnosti ani poskytovat další součinnost.

Odolnost proti selháním v celé oblasti

Azure Managed Redis poskytuje nativní podporu více oblastí prostřednictvím aktivní geografické replikace, která umožňuje propojit několik instancí Azure Managed Redis mezi různými oblastmi Azure do jedné replikační skupiny. Pak můžete mezi instancemi nastavit vlastní způsob převzetí služeb při selhání.

Aktivní geografická replikace

Když používáte aktivní geografickou replikaci, můžou aplikace číst a zapisovat do jakékoli instance mezipaměti ve skupině, přičemž změny se automaticky synchronizují napříč všemi oblastmi. Služba podporuje vzorce replikace aktivní-aktivní, kde každá oblast dokáže zpracovávat operace čtení i zápisu současně. Pokud dojde ke konfliktům kvůli souběžným zápisům v různých oblastech, služba je automaticky vyřeší pomocí předem určených algoritmů řešení konfliktů bez nutnosti ručního zásahu. Tento přístup zajišťuje odolnost vůči selháním oblastí při zachování přístupu s nízkou latencí pro globálně distribuované aplikace.

Následující diagram znázorňuje dvě instance mezipaměti v různých oblastech ve stejné aktivní skupině geografické replikace spolu s klientskými aplikacemi, které se připojují k jednotlivým instancím mezipaměti.

Zodpovídáte za nastavení klientských aplikací pro přesměrování požadavků na instanci, která je v pořádku, pokud selže nějaká místní instance. Následující diagram ukazuje, jak může aplikace přesměrovat své požadavky na instanci mezipaměti, která je v pořádku, když instance, kterou obvykle používají, selže.

Požadavky

• Podpora oblastí: Aktivní geografickou replikaci Azure Managed Redis můžete nastavit mezi všemi oblastmi Azure, ve kterých je služba dostupná.

• Konfigurace instance: Aktivní geografická replikace vyžaduje instance Azure Managed Redis, které ve všech zúčastněných oblastech používají stejnou úroveň a velikost. Všechny instance mezipaměti ve skupině replikace musí používat stejná nastavení, včetně možností trvalosti, modulů a zásad clusteringu.

• Další požadavky: Instance mezipaměti musí splňovat další požadavky, včetně modulů, které používáte. Tyto požadavky ovlivňují, jak můžete škálovat instance mezipaměti. Další informace najdete v tématu Požadavky aktivní geografické replikace.

Úvahy

• Odpovědnost za převzetí služeb při selhání: Když používáte aktivní geografickou replikaci, zodpovídáte za převzetí služeb při selhání mezi instancemi mezipaměti. Připravte svou aplikaci na zpracování failoveru. Převzetí služeb při selhání zahrnuje přípravu a může vyžadovat, abyste provedli několik kroků. Další informace najdete v tématu Vynucení zrušení propojení během výpadku oblasti.

• Konečná konzistence: Návrh aplikací pro zpracování scénářů konečné konzistence, protože šíření změn napříč všemi oblastmi může nějakou dobu trvat v závislosti na podmínkách sítě a geografické vzdálenosti. Během výpadků oblastí můžete zaznamenat více nekonzistence dat, dokud se připojení neobnoví a synchronizace se nedokončí.

Náklady

Když nastavíte aktivní geografickou replikaci, platíte za každou instanci Azure Managed Redis v každé oblasti v rámci replikační skupiny. Můžete také vzniknout poplatky za přenos dat za provoz replikace mezi oblastmi. Další informace najdete v podrobnostech o cenách Azure Managed Redis a cenách šířky pásma.

Konfigurace podpory více oblastí

• Vytvořte novou geograficky replikovanou instanci mezipaměti. Nastavení aktivní geografické replikace při zřizování mezipaměti zadáním replikační skupiny a propojením více instancí. Další informace najdete v tématu Vytvoření aktivní skupiny geografické replikace nebo připojení k ní.

• Přidejte existující instanci mezipaměti do skupiny geografické replikace. Existující instanci mezipaměti můžete přidat do aktivní skupiny geografické replikace.

  Když přidáte existující instanci do aktivní skupiny geografické replikace, platforma musí vymazat data v instanci a dojde k malému výpadku. Pokud je to možné, naplánujte při vytváření instancí mezipaměti aktivní geografickou replikaci.

  Další informace najdete v tématu Přidání existující instance do aktivní skupiny geografické replikace.

• Vypněte geografickou replikaci instance mezipaměti. Odeberte instanci ze skupiny geografické replikace odstraněním instance mezipaměti. Zbývající instance automaticky upraví jejich nastavení.

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

Během události výpadku oblasti můžou ostatní instance zaznamenat vyšší zatížení. Pokud instance často běží v blízkosti limitů prostředků a musíte se připravit na zvýšené požadavky na kapacitu v případě selhání oblasti, zvažte předimenzování instance. Další informace najdete v tématu Škálování instance Azure Managed Redis.

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

Tato část popisuje, co očekávat, když nastavíte instance tak, aby používaly aktivní geografickou replikaci a všechny oblasti fungují normálně.

• Směrování provozu mezi oblastmi: Zodpovídáte za nastavení aplikací pro připojení ke konkrétní instanci mezipaměti. Aplikace se můžou připojit k jakékoli instanci mezipaměti ve skupině replikace a provádět operace čtení i zápisu. Aplikace zpracovává směrování provozu, což umožňuje směrovat klienty do nejbližší oblasti kvůli minimální latenci. Azure Managed Redis automaticky nesměruje provoz mezi oblastmi.

• Replikace dat mezi oblastmi: Služba používá asynchronní replikaci mezi oblastmi k zachování konečné konzistence. Okamžitě potvrdí operace zápisu v místní oblasti a pak je rozšíří do jiných oblastí na pozadí. Replikované datové typy bez konfliktů (CRDT) zajišťují, že služba automaticky slučuje souběžné zápisy v různých oblastech.

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

Tato část popisuje, co očekávat, když nastavíte instance tak, aby používaly aktivní geografickou replikaci a dojde k výpadku v jedné oblasti.

• Detekce a odpověď: Zodpovídáte za zjištění selhání instance mezipaměti a rozhodnutí o tom, kdy provést převzetí služeb při selhání. Můžete sledovat zdraví geograficky replikovaného clusteru, což vám může pomoci rozhodnout, kdy začít s převzetím služeb. Další informace najdete v tématu Metrika geografické replikace.

  Převzetí služeb při selhání vyžaduje, abyste vykonali několik kroků. Další informace najdete v tématu Vynucení zrušení propojení během výpadku oblasti.

• Oznámení: Microsoft vás při výpadku oblasti automaticky neoznámí. Můžete ale použít Azure Service Health k pochopení celkového stavu služby, včetně všech selhání oblastí, a můžete nastavit upozornění služby Health, která vás upozorní na problémy.

  Můžete také sledovat zdraví jednotlivých instancí.

  Pokud chcete monitorovat stav vztahu geografické replikace, použijte metriku geografické replikace , která je v pořádku. Metrika má vždy hodnotu 1 (v pořádku) nebo 0 (není v pořádku). Nastavte upozornění služby Azure Monitor na tuto metriku, abyste zjistili, kdy se instance nemusí synchronizovat.

• Aktivní požadavky: Služba ukončí požadavky do oblasti, která selhala, a logika převzetí služeb při selhání vaší aplikace je musí zpracovat. Aplikace by měly implementovat zásady opakování, které můžou přesměrovat provoz do zdravých vyrovnávacích pamětí.

• Očekávaná ztráta dat: Asynchronní replikace mezi oblastmi může vést ke ztrátě nedávných zápisů do oblasti, která selhala, pokud se tyto zápisy nereplikovaly do jiných oblastí. Velikost potenciální ztráty dat závisí na prodlevě replikace v době selhání. Další informace najdete v tématu aktivně-aktivní geograficky distribuovaný Redis a úvaha o konzistenci a ztrátě dat při regionálním selhání bezkonfliktní replikované databáze (CRDB).

• Očekávaný výpadek: Aplikace mají výpadek jenom po dobu potřebnou ke zjištění selhání a přesměrování provozu do oblastí, které jsou v pořádku. Tento výpadek se obvykle pohybuje od několika sekund do několika minut a závisí na tom, jak jste nastavili kontrolu stavu a konfiguraci převzetí služeb při selhání vaší aplikace.

• Přesměrování provozu: Zodpovídáte za implementaci logiky ve vašich aplikacích za účelem zjištění selhání oblastí a směrování provozu do oblastí, které jsou v pořádku. Tuto logiku můžete implementovat prostřednictvím kontrol stavu, vzorů jističe nebo externích řešení vyrovnávání zatížení.

Obnovení oblasti

Po obnovení oblasti, která selhala, Azure Managed Redis automaticky znovu integruje instance v této oblasti do aktivní skupiny geografické replikace bez vašeho zásahu. Služba automaticky synchronizuje data z instancí, které jsou v pořádku. Během tohoto procesu obnovené instance postupně synchronizují změny, ke kterým došlo během výpadku. Po dokončení synchronizace se obnovené instance plně aktivují a můžou zpracovávat operace čtení i zápisu.

Zodpovídáte za překonfigurování aplikace tak, aby směrovala provoz zpět do instance obnovené oblasti.

Testování selhání regionů

Pravidelně testujte postupy pro převzetí služeb při selhání vaší aplikace. Vaše aplikace musí být schopná přepnout služby mezi instancemi a splnit vaše obchodní požadavky na dobu výpadku během přechodu. Otestujte také celkové procesy odezvy, včetně jakékoli rekonfigurace bran firewall a další infrastruktury a procesu obnovení.

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

Azure Managed Redis zpracovává běžné upgrady služeb a další úlohy údržby.

Během údržby Azure Managed Redis automaticky vytvoří nové uzly a provedou přepnutí. U klientských aplikací může docházet k přerušení připojení a dalším přechodným chybám. Aplikace by měly implementovat logiku opakování pro zpracování těchto dočasných přerušení.

Další informace o procesech údržby Azure Managed Redis najdete v tématu Převzetí služeb při selhání a opravy pro Azure Managed Redis.

Zálohování a obnovení

Azure Managed Redis poskytuje možnosti trvalosti dat i zálohování, které chrání před scénáři ztráty dat, které nemusí řešit jiné funkce spolehlivosti. Zálohy chrání před scénáři, jako jsou poškození dat, náhodné odstranění nebo chyby konfigurace.

• Trvalost dat: Azure Managed Redis ve výchozím nastavení ukládá všechna data mezipaměti do paměti. Služba může volitelně zapisovat snímky dat na disk pomocí trvalosti dat. Pokud selhání hardwaru ovlivní uzel, Azure Managed Redis automaticky obnoví data. Můžete si vybrat z různých typů trvalosti dat, které poskytují různé kompromisy mezi frekvencí snímků a efekty výkonu v mezipaměti.

  Datové soubory nemůžete obnovit do jiné instance a nemáte k souborům přístup. Trvalost dat vás nechrání před poškozením nebo náhodným odstraněním dat.

• Import a export: Azure Managed Redis podporuje zálohování dat při použití funkce importu a exportu, která ukládá záložní soubory do služby Azure Blob Storage. V podporovaných oblastech můžete nastavit geograficky redundantní úložiště (GRS) ve svém účtu Azure Storage nebo můžete zkopírovat nebo přesunout záložní objekty blob do jiných umístění pro další ochranu.

  Exportované soubory můžete obnovit do stejné instance mezipaměti nebo do jiné instance mezipaměti.

  Služba nezahrnuje integrovaný plánovač importu nebo exportu, ale můžete vyvíjet vlastní procesy automatizace, které ke spuštění operací exportu používají Azure CLI nebo Azure PowerShell.

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.

Smlouva SLA pro Azure Managed Redis pokrývá připojení ke koncovým bodům mezipaměti. Nevztahuje se na ochranu před ztrátou dat.

Pokud chcete mít nárok na smlouvy SLA dostupnosti pro Azure Managed Redis, musíte splnit následující požadavky:

• Musíte použít konfiguraci s vysokou dostupností.

• Nesmíte spouštět jakékoli funkce produktu ani akce správy, které jsou zdokumentované, že vedou k dočasné nedostupnosti.

Smlouvy SLA s vyšší dostupností platí, když je vaše instance zónově redundantní. V některých úrovních můžete mít nárok na smlouvu SLA s vyšší dostupností, když nasadíte zónově redundantní instance do alespoň tří oblastí pomocí aktivní geografické replikace.

Související obsah

• Spolehlivost v Azure