Sdílet prostřednictvím

Přepnutí při selhání a aktualizace pro Azure Cache for Redis

  • Platí pro: ✅ Azure Cache for Redis

Důležité

Služba Azure Cache for Redis oznámila časovou osu vyřazení všech skladových položek. Doporučujeme přesunout stávající instance Azure Cache for Redis do Azure Managed Redis , jakmile budete moct.

Další podrobnosti o ukončení podpory:

Pokud chcete vytvářet odolné a úspěšné klientské aplikace, je důležité pochopit přenos 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í funkce převzetí mezipaměti při selhání nastane, když služba správy aktualizuje 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řepnutí na záložní systém během instalace 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 shardů, z nichž každý má odlišné primární a replikované uzly. Jeden shard 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í failoveru

Převzetí služeb při selhání nastane, když se uzel repliky povýší, 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řepnutí probíhá během dvou různých případů:

  • 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, prohodit role a rychle aktualizovat nástroj pro vyrovnávání zatížení, aby reflektoval změnu. Plánované převzetí služeb při selhání se obvykle dokončí za méně než 1 sekundu.

Neplánovaný failover 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 povýší na primární, ale tento proces trvá déle. Uzel repliky musí nejprve zjistit, že jeho primární uzel není k dispozici, aby mohl spustit proces převzetí při selhání. Uzel repliky musí také ověřit, že toto neplánované selhání není přechodné nebo lokální, 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 spolupracovně povýší 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ým procesem převzetí funkcí, uzel repliky se rychle povýší na hlavní. Uzel pak začne obsluhovat žádosti 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 jednotlivých fragmentech.

Několik cache ve stejné skupině a oblasti prostředků se také opraví jeden po druhém. Mezipaměti, které jsou v různých skupinách prostředků nebo v různých regionech, 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ší zatížení 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 ovlivní přepnutí při selhání moji klientskou aplikaci?

Klientské aplikace můžou ze služby Azure Cache for Redis obdržet určité chyby. Počet zjištěných chyb klientskou aplikací závisí na počtu operací čekajících na síťové připojení v době provozu při selhání. Jakékoli připojení, které je směrováno přes uzel, jenž uzavřel své připojení, zažívá 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ž nastane převzetí služeb při selhání, může vyvolat výjimku časového limitu. Nové požadavky na objekt uzavřeného připojení se setkávají s výjimkami připojení, dokud se nepodaří úspěšně znovu připojit.

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 na kanálu typu publish/subscribe (pub/sub) zvaném AzureRedisEvents. 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 mohou způsobit chybu Žádné připojení k dispozici. Tyto změny můžou zahrnovat:

  • Přepínání virtuální IP adresy klientské aplikace mezi zkušební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.

Zabudovat odolnost

Nelze se zcela vyhnout přepnutí 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.

Jak můžu aplikaci nastavit jako odolnou?

Podívejte se na tyto návrhové vzory pro vytváření odolných klientů, zejména vzor jističe a vzor opakovaného pokusu.

Použijte reboot jako ruční spouštěč pro přerušení připojení, abyste otestovali odolnost klientské aplikace.

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 Odolnost připojení.

Související obsah

  • Last updated on