Převzetí služeb při selhání a opravy pro Azure Managed Redis

  • Platí pro: ✅ Azure Managed Redis

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ě Redis spravované Azurem. Přepnutí 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é využití přechodu na rezervní mezipaměť se objeví, když služba pro správu aktualizuje binární soubory Azure Managed Redis.

V tomto článku najdete tyto informace:

  • Co je převzetí služeb při selhání?
  • Jak dochází k přepnutí systému 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 Managed Redis.

Rychlý přehled architektury mezipaměti

Diagram znázorňující architekturu nabídky Azure Managed Redis.

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č (neboli uzel) paralelně spouští několik procesů serveru Redis (nazývaných shardy). Více shardů umožňuje efektivnější využití vCPU na každém virtuálním stroji a vyšší výkon. Ne všechny primární shardy Redis jsou na stejném virtuálním počítači nebo uzlu. Místo toho jsou primární a replikační shardy rozděleny mezi oběma uzly. Vzhledem k tomu, že primární horizontální oddíly používají více prostředků procesoru než horizontální oddíly replik, tento přístup umožňuje paralelní spouštění více primárních horizontálních oddílů. Každý uzel má vysoce výkonný proxy proces pro správu shardů, správu připojení a spuštění samoopravy. Jeden shard může být mimo provoz, zatímco ostatní zůstanou dostupné.

Podrobné informace o Azure spravované architektuře Redis najdete .

Vysvětlení přepnutí při selhání

Převzetí služeb při selhání nastane, když se jeden nebo více replik shardů prohlásí za primární shard a staré primární shardy ukončí stávající připojení. 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 je instalace oprav Redis nebo upgradů operačního systému.
  • Operace správy, například škálování a restartování

Vzhledem k tomu, že uzly obdrží předběžné oznámení o aktualizaci, mohou spolupracovat na výměně rolí a rychle aktualizovat nástroj pro vyrovnávání zatížení pro změnu. Plánované převzetí služeb při selhání se obvykle dokončí za méně než jednu 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 jednoho nebo více uzlů v clusteru. Replikované shardy ve zbývajících uzlech budou povýšeny na primární, aby zachovaly dostupnost, ačkoliv tento proces trvá déle. Replikovaný štěp musí nejprve zjistit, že jeho primární štěp není k dispozici, než může zahájit proces převzetí služeb při selhání. Replikovaný fragment musí také ověřit, že toto neplánované selhání není přechodné nebo místní, aby nedošlo k zbytečnému převzetí úloh. Toto zpoždění detekce znamená, že neplánované převzetí služeb se obvykle dokončí během 10 až 15 sekund.

Jak dochází k opravám?

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

  1. Služba vytvoří nové aktuální virtuální počítače, které nahradí všechny opravené virtuální počítače.
  2. Pak propaguje jeden z nových virtuálních počítačů jako vedoucího clusteru.
  3. Jeden po druhém, všechny uzly, které se opravují, se odeberou z clusteru. Všechny fragmenty na těchto virtuálních počítačích budou degradovány na nižší úroveň a migrovány na některé z nových virtuálních počítačů.
  4. Nakonec se odstraní všechny virtuální počítače, které byly nahrazeny.

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.

Poznámka:

Několik mezipamětí ve stejné oblasti může být opraveno současně. Pokud to ovlivní vaši aplikaci, nakonfigurujte plány údržby tak, aby každá mezipaměť byla opravena v jiném čase.

Vzhledem k tomu, že úplná synchronizace dat proběhne před opakováním procesu, je nepravděpodobné, že dojde ke ztrátě dat pro vaši mezipaměť. 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 failoveru, musí mezipaměti replikovat data z jednoho uzlu na druhý. Tato replikace způsobuje zvýšení zatížení paměti i procesoru serveru. Pokud je instance mezipaměti již silně zatížená, mohou klientské aplikace zaznamenat zvýšenou latenci. V extrémních případech může u klientské aplikace dojít k výjimce vypršení časového limitu.

Jak ovlivňuje převzetí služeb při selhání klientskou aplikaci?

Klientské aplikace můžou obdržet nějaké chyby ze své instance Azure Managed Redis. Počet chyb zobrazených klientskou aplikací závisí na tom, kolik operací na daném připojení čekalo na vyřízení při přepnutí. U všech připojení, která jsou směrována přes uzel, který ukončí své připojení, dojde k chybám.

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

  • Výjimky timeoutu
  • 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 u operace, která při převzetí služeb při selhání odešle požadavek, ale neobdrží odpověď, může dojít k výjimce časového limitu. Nové požadavky na objekt uzavřeného připojení vyvolávají výjimky, dokud nedojde k úspěšnému opětovnému připojení.

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

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 historie údržby na portálu Azure?

Informace o historii údržby na portálu Azure najdete v protokolu aktivit Azure instance vaší mezipaměti. Událost healthevent se vygeneruje při zahájení údržby.

Snímek obrazovky s událostí údržby v protokolu aktivit na portálu

Pokud chcete dostávat oznámení automaticky, nastavte upozornění v protokolu aktivit.

Změny konfigurace sítě na straně klienta

Některé změny v konfiguraci sítě na straně klienta mohou vyvolat chybu Není k dispozici žádné připojení. Tyto změny můžou zahrnovat následující prvky:

  • Výměna virtuální IP adresy klientské aplikace mezi připravovaný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 Managed Redis.

Zabudování odolnosti

Převzetí služeb při selhání nelze zcela vyhnout. Raději klientské aplikace napište tak, aby byly odolné vůči přerušení připojení a neúspěšným požadavkům. Většina klientských knihoven se automaticky znovu připojí ke koncovému bodu mezipaměti, ale jen málo z nich se pokusí znovu opakovat neúspěšné požadavky. V závislosti na scénáři aplikace může být přínosné použít logiku opakování se strategií exponenciálního zpomalování.

Jak mám zajistit, aby byla moje aplikace odolná?

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

Související obsah

  • Last updated on