Sdílet prostřednictvím

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

  • Č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 Managed Redis (Preview). 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 Managed 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 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) spouští paralelně několik procesů serveru Redis (označovaných jako horizontální oddíly). Více horizontálních oddílů umožňuje efektivnější využití virtuálních procesorů na každém virtuálním počítači a vyšší výkon. Ne všechny primární horizontální oddíly Redis jsou na stejném virtuálním počítači nebo uzlu. Místo toho se horizontální oddíly primárních i replik distribuují napříč 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ý proces proxy pro správu horizontálních oddílů, zpracování správy připojení a aktivaci samoopravení. Jeden horizontální oddíl může být mimo provoz, zatímco ostatní zůstanou dostupné.

Podrobné informace o architektuře Azure Managed Redis najdete tady.

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

Převzetí služeb při selhání nastane, když se jeden nebo více horizontálních oddílů repliky upřednostní, aby se staly primárními horizontálními oddíly, a staré primární horizontální oddíly 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 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 jednoho nebo více uzlů v clusteru. Horizontální oddíly repliky na zbývajících uzlech se zvýší na primární, aby zachovaly dostupnost, ale proces trvá déle. Horizontální oddíl repliky musí nejprve zjistit, že jeho primární horizontální oddíl není k dispozici, aby mohl zahájit proces převzetí služeb při selhání. Horizontální oddíl repliky také musí ověřit, že toto neplánované selhání není přechodné nebo místní, aby nedošlo k 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 Managed 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 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 horizontální oddíly na těchto virtuálních počítačích budou degradovány a migrovány na jeden 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.

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ě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ší načtení mezipaměti

Kdykoli dojde k převzetí služeb při selhání, musí mezipaměti 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.

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

Klientské aplikace můžou ze své instance Azure Managed Redis obdržet nějaké 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.

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 ve stavu služby na portálu ani na jiném místě.

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 Managed 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í:

Související obsah