Převzetí služeb při selhání a opravy služby Azure Cache for Redis

  • Článek

Pokud chcete vytvářet odolné a úspěšné klientské aplikace, je důležité pochopit převzetí služeb při selhání ve službě Azure Cache for Redis. Převzetí služeb při selhání může být součástí plánovaných operací správy nebo může být způsobeno neplánovanými chybami hardwaru nebo sítě. Běžné použití převzetí služeb při selhání mezipaměti nastane, když služba pro správu opraví binární soubory Azure Cache for Redis.

V tomto článku najdete tyto informace:

  • Co je převzetí služeb při selhání?
  • Jak dojde k převzetí služeb při selhání během oprav.
  • Jak vytvořit odolnou klientskou aplikaci

Co je převzetí služeb při selhání?

Začněme přehledem převzetí služeb při selhání pro Azure Cache for Redis.

Rychlý přehled architektury mezipaměti

Mezipaměť je vytvořena z několika virtuálních počítačů s samostatnými a privátními IP adresami. Každý virtuální počítač, označovaný také jako uzel, je připojený ke sdílenému nástroji pro vyrovnávání zatížení s jednou virtuální IP adresou. Každý uzel spouští proces serveru Redis a je přístupný pomocí názvu hostitele a portů Redis. Každý uzel se považuje za primární uzel nebo uzel repliky. Když se klientská aplikace připojí k mezipaměti, její provoz prochází tímto nástrojem pro vyrovnávání zatížení a automaticky se směruje do primárního uzlu.

V mezipaměti Basic je jeden uzel vždy primární. V mezipaměti Standard nebo Premium jsou dva uzly: jeden je zvolen jako primární a druhý je replika. Vzhledem k tomu, že mezipaměti Standard a Premium mají více uzlů, může být jeden uzel nedostupný, zatímco druhý stále zpracovává požadavky. Clusterované mezipaměti se skládají z mnoha horizontálních oddílů, z nichž každý má odlišné primární uzly a uzly repliky. Jeden horizontální oddíl může být mimo provoz, zatímco ostatní zůstanou dostupné.

Poznámka:

Mezipaměť Basic nemá více uzlů a nenabízí smlouvu o úrovni služeb (SLA) pro její dostupnost. Základní mezipaměti se doporučují jenom pro účely vývoje a testování. Pokud chcete zvýšit dostupnost, použijte mezipaměť Standard nebo Premium pro nasazení s více uzly.

Vysvětlení převzetí služeb při selhání

Převzetí služeb při selhání nastane, když se uzel repliky propaguje, aby se stal primárním uzlem, a starý primární uzel ukončí existující připojení. Jakmile se primární uzel vrátí zpět, všimne si změny rolí a degraduje sám sebe, aby se stal replikou. Potom se připojí k novému primárnímu serveru a synchronizuje data. Převzetí služeb při selhání může být plánované nebo neplánované.

Plánované převzetí služeb při selhání probíhá ve dvou různých časech:

  • Aktualizace systému, jako jsou opravy Redis nebo upgrady operačního systému.
  • Operace správy, jako je škálování a restartování

Vzhledem k tomu, že uzly obdrží předběžné oznámení o aktualizaci, mohou spolupracovat prohození rolí a rychle aktualizovat nástroj pro vyrovnávání zatížení změny. Plánované převzetí služeb při selhání se obvykle dokončí za méně než 1 sekundu.

Neplánované převzetí služeb při selhání může nastat kvůli selhání hardwaru, selhání sítě nebo jiným neočekávaným výpadkům primárního uzlu. Uzel repliky se propaguje na primární, ale proces trvá déle. Uzel repliky musí nejprve zjistit, že jeho primární uzel není k dispozici, aby mohl spustit proces převzetí služeb při selhání. Uzel repliky také musí ověřit, že toto neplánované selhání není přechodné nebo místní, aby se zabránilo zbytečnému převzetí služeb při selhání. Toto zpoždění detekce znamená, že neplánované převzetí služeb při selhání se obvykle dokončí do 10 až 15 sekund.

Jak dochází k opravám?

Služba Azure Cache for Redis pravidelně aktualizuje vaši mezipaměť nejnovějšími funkcemi a opravami platformy. Pokud chcete opravit mezipaměť, služba se řídí těmito kroky:

  1. Služba nejprve opraví uzel repliky.
  2. Opravená replika se spolupracivně podporuje na primární. Toto povýšení se považuje za plánované převzetí služeb při selhání.
  3. Bývalý primární uzel se restartuje, aby převzal nové změny a vrátil se jako uzel repliky.
  4. Uzel repliky se připojí k primárnímu uzlu a synchronizuje data.
  5. Po dokončení synchronizace dat se proces opravy opakuje pro zbývající uzly.

Vzhledem k tomu, že opravy jsou plánované převzetí služeb při selhání, uzel repliky se rychle prosadí, aby se stal primárním. Uzel pak zahájí žádosti o údržbu a nová připojení. Základní mezipaměti nemají uzel repliky a nejsou k dispozici, dokud se aktualizace nedokončí. Každý horizontální oddíl clusterované mezipaměti se opravuje samostatně a nezavírá připojení k jinému horizontálnímu oddílu.

Důležité

Uzly se opravují po jednom, aby se zabránilo ztrátě dat. Základní mezipaměti budou mít ztrátu dat. Clusterované mezipaměti se opravují po jednom horizontálním oddílu.

Několik mezipamětí ve stejné skupině prostředků a oblasti se také opraví po jednom. Mezipaměti, které jsou v různých skupinách prostředků nebo v různých oblastech, se můžou opravovat současně.

Vzhledem k tomu, že úplná synchronizace dat probíhá před opakováním procesu, je nepravděpodobné, že při použití mezipaměti Standard nebo Premium dojde ke ztrátě dat. Před ztrátou dat můžete dále chránit exportem dat a povolením trvalosti.

Další načtení mezipaměti

Kdykoli dojde k převzetí služeb při selhání, musí mezipaměti Standard a Premium replikovat data z jednoho uzlu do druhého. Tato replikace způsobuje zvýšení zatížení paměti serveru i procesoru. Pokud je instance mezipaměti již silně načtená, můžou klientské aplikace zaznamenat zvýšenou latenci. V extrémních případech můžou klientské aplikace dostávat výjimky vypršení časového limitu. Pokud chcete zmírnit dopad většího zatížení, nakonfigurujte nastavení mezipaměti maxmemory-reserved .

Jaký má převzetí služeb při selhání vliv na klientskou aplikaci?

Klientské aplikace můžou ze služby Azure Cache for Redis obdržet určité chyby. Počet chyb, které klientská aplikace viděla, závisí na počtu operací čekajících na připojení v době převzetí služeb při selhání. Jakékoli připojení směrované přes uzel, který ukončil připojení, se zobrazí chyby.

Mnoho klientských knihoven může při přerušení připojení vyvolat různé typy chyb, mezi které patří:

  • Výjimky časového limitu
  • výjimky Připojení
  • Výjimky soketů

Počet a typ výjimek závisí na tom, kde je požadavek v cestě ke kódu, když mezipaměť ukončí svá připojení. Například operace, která odešle požadavek, ale neobdržela odpověď, když dojde k převzetí služeb při selhání, může dojít k výjimce časového limitu. Nové požadavky na objekt uzavřeného připojení přijímají výjimky připojení, dokud se opětovné připojení úspěšně neskončí.

Většina klientských knihoven se pokusí znovu připojit k mezipaměti, pokud jsou nakonfigurované tak. Nepředvídatelné chyby však mohou občas umístit objekty knihovny do nerepravovatelného stavu. Pokud chyby potrvají déle, než je předkonfigurovaná doba, měl by se objekt připojení znovu vytvořit. V Microsoft.NET a jiných objektově orientovaných jazycích je možné znovu vytvořit připojení bez restartování aplikace pomocí vzoru ForceReconnect.

Můžu být předem upozorněn(a) na údržbu?

Azure Cache for Redis publikuje oznámení o údržbě modulu runtime v kanálu AzureRedisEventspublish/subscribe (pub/sub). Mnoho oblíbených klientských knihoven Redis podporuje přihlášení k odběru pub/sub kanálů. Příjem oznámení z AzureRedisEvents kanálu je obvykle jednoduchým doplňkem klientské aplikace. Další informace o událostech údržby najdete v tématu AzureRedisEvents.

Poznámka:

Kanál AzureRedisEvents není mechanismus, který vás může informovat o dnech nebo hodinách předem. Kanál může klientům oznámit všechny nadcházející události údržby serveru, které můžou ovlivnit dostupnost serveru. AzureRedisEvents je k dispozici pouze pro úrovně Basic, Standard a Premium.

Jaké jsou aktualizace zahrnuté v rámci údržby?

Údržba zahrnuje tyto aktualizace:

  • Aktualizace Serveru Redis: Všechny aktualizace nebo opravy binárních souborů serveru Redis.
  • Aktualizace virtuálního počítače: Všechny aktualizace virtuálního počítače hostujícího službu Redis Aktualizace virtuálních počítačů zahrnují opravy softwarových komponent v hostitelském prostředí pro upgrade síťových komponent nebo vyřazení z provozu.

Zobrazuje se údržba ve stavu služby na webu Azure Portal před opravou?

Ne, údržba se nezobrazuje nikde pod stavem služby na portálu ani na jiném místě.

Kolik času můžu oznámení získat před plánovanou údržbou?

Při používání AzureRedisEvents kanálu budete upozorněni 15 minut před údržbou.

Změny konfigurace sítě klienta

Některé změny konfigurace sítě na straně klienta můžou aktivovat žádné chyby připojení k dispozici . Tyto změny můžou zahrnovat:

  • Prohození virtuální IP adresy klientské aplikace mezi přípravovými a produkčními sloty
  • Škálování velikosti nebo počtu instancí aplikace

Tyto změny můžou způsobit problém s připojením, který obvykle trvá méně než jednu minutu. Vaše klientská aplikace pravděpodobně ztratí připojení k jiným externím síťovým prostředkům, ale také ke službě Azure Cache for Redis.

Sestavení v odolnosti

Nemůžete se úplně vyhnout převzetí služeb při selhání. Místo toho napište klientské aplikace tak, aby byly odolné vůči přerušení připojení a neúspěšné žádosti. Většina klientských knihoven se automaticky znovu připojí ke koncovému bodu mezipaměti, ale několik z nich se pokusí opakovat neúspěšné požadavky. V závislosti na scénáři aplikace může být vhodné použít logiku opakování s backoffem.

Návody, aby byla moje aplikace odolná?

Projděte si tyto vzory návrhu pro vytváření odolných klientů, zejména jističe a vzory opakování:

Pokud chcete otestovat odolnost klientské aplikace, použijte restartování jako ruční aktivační událost pro přerušení připojení.

Kromě toho doporučujeme, abyste pomocí plánovaných aktualizací zvolili aktualizační kanál a časové období údržby pro mezipaměť, abyste mohli použít opravy modulu runtime Redis během konkrétních týdenních oken. Tato okna jsou obvykle období, kdy je provoz klientských aplikací nízký, aby se zabránilo potenciálním incidentům. Další informace najdete v tématu Aktualizace kanálu a plánování aktualizací.

Další informace najdete v tématu o odolnosti Připojení.

Související obsah