Spolehlivost ve službě Azure Managed Redis

Azure Managed Redis poskytuje plně integrované a spravované úložiště Redis Enterprise v Azure, které nabízí vysoce výkonné úložiště dat v paměti pro aplikace. Tato služba je vytvořená pro podnikové úlohy vyžadující 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 spolehlivost ve službě Azure Managed Redis, včetně odolnosti vůči přechodným chybám, selháním zón dostupnosti a selháním v celé oblasti. Článek také popisuje 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:

• Povolte vysokou dostupnost, která nasadí více uzlů pro vaši mezipaměť.
• Povolte zónovou redundanci nasazením vysoce dostupné mezipaměti do oblasti s zónami dostupnosti.
• Zvažte implementaci aktivní geografické replikace pro kritické úlohy, které vyžadují failover mezi oblastmi.

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

Při plánování odolnosti pro Azure Managed Redis je potřeba porozumět dvěma klíčovým konceptům: uzly a horizontální oddíly.

• 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 spravuje vytváření instancí, monitorování stavu a nahrazování instancí, které nejsou v pořádku. Sada virtuálních počítačů, které jsou pohromadě, se označuje také jako cluster.

  Instanci můžete nakonfigurovat pro zajištění vysoké dostupnosti. Když to uděláte, Azure Managed Redis zajistí, že existují aspoň dva uzly a automaticky replikuje data mezi uzly. V oblastech se zónami dostupnosti jsou uzly umístěny 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ů používaných v každé konfiguraci, aby se zabránilo složitosti a zajistil optimální konfigurace.

• Střepy: Každý uzel spouští několik procesů serveru Redis nazývaných shardy, které spravují podmnožinu dat vaší mezipaměti. Když je vaše mezipaměť nakonfigurovaná pro vysokou dostupnost, fragmenty se automaticky distribuují a replikují mezi uzly. Zadáte zásady clusteru, které určují rozložení datových fragmentů 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í ke správě přechodných chyb:

• Použijte konfigurace sady SDK, které se automaticky opakují, když dojde k přechodným chybám, a které používají vhodná období odstupu a časového limitu. Zvažte použití Retry vzoru a vzor přerušení obvodu ve vašich aplikacích.
• Návrh vzorů typu cache-aside , ve kterých může vaše aplikace dál fungovat se sníženým výkonem, když je Redis dočasně nedostupný, tím, že se vrátí k primárnímu úložišti 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 mezipaměti Azure Managed Redis je možné nastavit jako zónově redundantní, což automaticky distribuuje uzly mezipaměti mezi několik zón dostupnosti v rámci oblasti. Redundance zón snižuje riziko výpadků datových center nebo zón dostupnosti, které způsobují nedostupnost vaší mezipaměti.

Aby byla mezipaměť s redundantním zónovým pokrytím, musíte ji nasadit do podporovaného regionu a povolit konfiguraci vysoké dostupnosti. V oblastech bez zón dostupnosti konfigurace vysoké dostupnosti stále vytváří aspoň dva uzly, ale nejsou 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ěti Azure Managed Redis je možné nasadit do libovolné oblasti, která podporuje zóny dostupnosti a kde je služba dostupná. Nejnovější 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: V mezipaměti musíte povolit konfiguraci vysoké dostupnosti, aby byla zónově redundantní.

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

Náklady

Redundance zón vyžaduje, aby byla vaše mezipaměť nakonfigurovaná pro vysokou dostupnost, která nasadí minimálně dva uzly pro vaši mezipaměť. Konfigurace vysoké dostupnosti je účtována vyšší sazbou než standardní konfigurace. 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, povolte konfiguraci vysoké dostupnosti a nasaďte ji do oblasti s zónami dostupnosti. Pak automaticky zahrnuje redundanci zón ve výchozím nastavení. Nemusíte provádět žádnou další konfiguraci.

  Podrobný postup najdete v tématu Rychlý start: Vytvoření instance Azure Managed Redis.

• Povolení redundance zón u existující instance: Pokud chcete nakonfigurovat existující instanci Azure Managed Redis tak, aby byla zónově redundantní, ujistěte se, že je nasazená v oblasti, která podporuje zóny dostupnosti, a povolte vysokou dostupnost v mezipaměti.

• Zakázání redundance zóny: U existujících instancí není možné zakázat redundanci zón, protože po povolení instance mezipaměti nemůžete vysokou dostupnost zakázat.

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 je vaše instance často pod tlakem prostředků a potřebujete se připravit na selhání zóny dostupnosti, zvažte jeden z následujících přístupů:

• Overprovision your instance: Nadměrné přidělení prostředků zahrnuje výběr vyššího výkonového stupně, než byste mohli potřebovat. Umožňuje vaší instanci tolerovat určitou ztrátu kapacity a nadále fungovat bez snížení výkonu. Další informace o principu nadměrného zřízení najdete v tématu Správa kapacity prostřednictvím nadměrného zřízení. Informace o škálování instance najdete v tématu Škálování instance Azure Managed Redis.

• Použijte aktivní geografickou replikaci: Můžete nasadit více instancí v různých oblastech a nakonfigurovat 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 jsou funkční:

• Směrování provozu mezi zónami: Shardy se distribuují mezi uzly na základě zásad clusteru. Zásady clusteru také určují, jak se provoz směruje do jednotlivých uzlů. Redundance zón nemění způsob směrování provozu.

• Replikace dat mezi zónami: Shardy se automaticky replikují mezi uzly a používají asynchronní replikaci. Prodleva replikace mezi shardy se obvykle měří v sekundách, ale to se může lišit v závislosti na úloze mezipaměti. U scénářů náročných na zápis a zatížení sítě obvykle vykazují 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 není 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: Probíhající požadavky mohou být zrušeny a měly by být opakovány. 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 se množství ztráty dat měří v sekundách, ale závisí na prodlevě replikace.

• Očekávaný výpadek: Může dojít k malému výpadku, obvykle 10 až 15 sekund, když shardy přepnou na uzly ve zdravých zónách. 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í, postupujte podle postupů 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

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

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 více instancí Azure Managed Redis napříč různými oblastmi Azure do jedné replikační skupiny. Poté můžete nakonfigurovat vlastní přístup převzetí služeb při selhání mezi jednotlivými instancemi.

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 s klientskými aplikacemi, které se připojují k jednotlivým instancím mezipaměti:

Zodpovídáte za konfiguraci klientských aplikací, aby v případě selhání jakékoli místní instance mohly žádosti přesměrovat na instanci, která je v pořádku. Následující diagram znázorňuje, jak může aplikace přesměrovat své požadavky na zdravou instanci mezipaměti, když instance, kterou obvykle používají, selže.

Požadavky

• Podpora oblastí Aktivní geografickou replikaci Azure Managed Redis je možné nakonfigurovat mezi všemi oblastmi Azure, ve kterých je služba dostupná.

• Konfigurace instance: Aktivní geografická replikace vyžaduje instance Azure Managed Redis se stejnou úrovní a velikostí ve všech zúčastněných oblastech. Všechny instance mezipaměti ve skupině replikace musí být nakonfigurované se stejnými nastaveními, 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, a ovlivňuje způsob škálování instancí 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. Měli byste připravit a nakonfigurovat svou aplikaci tak, aby zvládla převzetí služeb při selhání. Převzetí služeb při selhání zahrnuje přípravu a může vyžadovat provedení několika kroků. Další informace najdete v tématu Vynucení zrušení propojení, pokud dojde k výpadku oblasti.

• Konečná konzistence: Aplikace by měly být navrženy tak, aby zpracovávaly scénáře 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 zeměpisné vzdálenosti. Během výpadků oblastí můžete zaznamenat více nekonzistence dat, dokud se připojení neobnoví a synchronizace se dokončí.

Náklady

Když povolíte aktivní geografickou replikaci, bude se vám účtovat každá instance Azure Managed Redis v každé oblasti v rámci replikační skupiny. Navíc můžete být účtovány poplatky za přenos dat při replikaci mezi oblastmi. Další informace o cenách 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: Nakonfigurujte aktivní geografickou replikaci během 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í.

• Povolení existující instance mezipaměti pro geografickou replikaci: Existující instanci mezipaměti můžete přidat do aktivní skupiny geografické replikace.

  Když se ale existující instance přidá do aktivní skupiny geografické replikace, musí se data v instanci vyprázdnit a dojde k malému výpadku. Pokud je to možné, naplánujte povolení aktivní geografické replikace při vytváření instancí mezipaměti.

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

• Zakažte geografickou replikaci instance mezipaměti: Odeberte instanci ze skupiny geografické replikace odstraněním instance mezipaměti. Zbývající instance se automaticky překonfigurují.

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

Během výpadku regionu mohou být ostatní instance pod vyšším tlakem. Pokud je instance často již pod tlakem prostředků a potřebujete se připravit na zvýšené požadavky na kapacitu během selhání regionu, zvažte předimenzování instance. Informace o škálování instance 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ž jsou instance nakonfigurované tak, aby používaly aktivní geografickou replikaci a všechny oblasti jsou funkční.

• Směrování provozu mezi oblastmi: Zodpovídáte za konfiguraci aplikací pro připojení ke konkrétní instanci mezipaměti. Aplikace se můžou připojit k libovolné instanci mezipaměti ve skupině replikace a provádět operace čtení i zápisu. Směrování provozu zpracovává aplikace, což umožňuje směrovat klienty do nejbližší oblasti s minimální latencí. Azure Managed Redis neposkytuje automatické směrování provozu mezi oblastmi.

• Replikace dat mezi oblastmi: Služba používá asynchronní replikaci mezi oblastmi, aby zachovala konečnou konzistenci. Operace zápisu jsou okamžitě zajištěny v místním regionu a poté na pozadí rozšířeny do dalších regionů. Replikované datové typy bez konfliktů (CRDT) zajišťují, aby se souběžné zápisy v různých oblastech automaticky sloučily.

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

Tato část popisuje, co očekávat, když jsou instance nakonfigurované tak, aby používaly aktivní geografickou replikaci, a v jedné oblasti došlo k výpadku:

• Detekce a reakce: Jste zodpovědní za detekci selhání instance mezipaměti a rozhodnutí, kdy přepnout na záložní řešení. Můžete monitorovat stav geograficky replikovaného clusteru, který vám může pomoct rozhodnout, kdy začít s převzetím služeb při selhání. Další informace najdete v tématu Metrika geografické replikace.

  Převzetí služeb při selhání vyžaduje provedení několika kroků. Další podrobnosti najdete v tématu Vynucení zrušení propojení, pokud dojde k 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, můžete použít metriku geografické replikace , která je v pořádku. Metrika má vždy hodnotu 1 (v pořádku) nebo 0 (není v pořádku). Na této metrice můžete nakonfigurovat upozornění služby Azure Monitor, abyste pochopili, kdy se instance nemusí synchronizovat.

• Aktivní požadavky: Požadavky na selhaný region jsou ukončeny a jejich zpracování musí zajistit logika převzetí služeb při selhání vaší aplikace. 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: Kvůli asynchronní replikaci mezi oblastmi můžou být některé nedávné zápisy do oblasti, které selhaly, ztraceny, pokud ještě nebyly replikovány 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 geo-distribuovaný Redis Active-Active a úvahy o konzistenci a ztrátě dat při regionálním selhání 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. To se obvykle pohybuje od několika sekund do několika minut v závislosti na tom, jak jste nakonfigurovali kontrolu stavu aplikace a konfiguraci převzetí služeb při selhání.

• 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. Toho lze dosáhnout prostřednictvím kontrol stavu, vzorů jističe nebo externích řešení vyrovnávání zatížení.

Obnovení oblasti

Když se nefunkční oblast zotaví, Azure Managed Redis automaticky opětovně zařadí instance v této oblasti do aktivní skupiny geografické replikace, aniž by vyžadovala váš zásah. Služba automaticky synchronizuje data z instancí, které jsou v pořádku. Během tohoto procesu obnovená instance postupně zachytí změny, ke kterým došlo během výpadku. Po dokončení synchronizace se obnovené instance stanou plně aktivní a mohou 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ů

Měli byste pravidelně testovat failover procedury vaší aplikace. Je důležité, aby vaše aplikace mohla přepnout mezi instancemi při výpadku a aby dodržovala vaše obchodní požadavky na dobu nefunkčnosti během tohoto procesu. Je také důležité otestovat celkové procesy odezvy, včetně jakékoli rekonfigurace bran firewall a jiné infrastruktury a procesu obnovení.

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

Azure Managed Redis provádí pravidelné upgrady služeb a další úlohy údržby.

Když probíhá údržba, Azure Managed Redis automaticky vytvoří nové uzly a automaticky provede převzetí služeb při selhání. Klientské aplikace můžou vidět přerušení připojení a další přechodné chyby. 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 pro 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 můžou poskytovat ochranu 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. Volitelně může zapisovat snímky dat na disk pomocí trvalosti dat. Pokud dojde k selhání hardwaru, které ovlivňuje uzel, Azure Managed Redis automaticky obnoví data. Existují různé typy trvalosti dat, ze kterých si můžete vybrat, které poskytují různé kompromisy mezi frekvencí snímků a efekty výkonu vaší mezipaměti.

  Datové soubory se ale nedají 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 pomocí funkce importu a exportu, která ukládá záložní soubory do služby Azure Blob Storage. Geograficky redundantní úložiště můžete nakonfigurovat 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 je možné obnovit do stejné instance mezipaměti nebo do jiné instance mezipaměti.

  Neexistuje žádný integrovaný plánovač importu nebo exportu, ale můžete vyvíjet vlastní procesy automatizace, které k zahájení 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. Smlouva SLA nezahrnuje ochranu před ztrátou dat.

Abyste splnili podmínky pro úrovně služeb (SLA) dostupnosti pro službu Azure Managed Redis:

• Musíte povolit konfiguraci vysoké dostupnosti.
• 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í, pokud jste nasadili zónově redundantní instance do alespoň tří oblastí pomocí aktivní geografické replikace.