Redundans och korrigering – Azure Cache for Redis

  • Artikel

För att skapa motståndskraftiga och framgångsrika klientprogram är det viktigt att förstå redundans i Azure Cache for Redis-tjänsten. En redundansväxling kan vara en del av planerade hanteringsåtgärder eller orsakas av oplanerade maskinvaru- eller nätverksfel. En vanlig användning av cacheredundans kommer när hanteringstjänsten korrigerar Binärfilerna för Azure Cache for Redis.

I den här artikeln hittar du den här informationen:

  • Vad är en redundansväxling?
  • Hur redundansväxling sker under korrigeringen.
  • Så här skapar du ett motståndskraftigt klientprogram.

Vad är en redundansväxling?

Vi börjar med en översikt över redundans för Azure Cache for Redis.

En snabb sammanfattning av cachearkitekturen

En cache skapas av flera virtuella datorer med separata och privata IP-adresser. Varje virtuell dator, även kallad nod, är ansluten till en delad lastbalanserare med en enda virtuell IP-adress. Varje nod kör Redis-serverprocessen och är tillgänglig med hjälp av värdnamnet och Redis-portarna. Varje nod anses vara antingen en primär nod eller en repliknod. När ett klientprogram ansluter till en cache går trafiken via den här lastbalanseraren och dirigeras automatiskt till den primära noden.

I en Basic-cache är den enda noden alltid primär. I en Standard- eller Premium-cache finns det två noder: en väljs som primär och den andra är repliken. Eftersom Standard- och Premium-cacheminnen har flera noder kan en nod vara otillgänglig medan den andra fortsätter att bearbeta begäranden. Klustrade cacheminnen består av många shards, var och en med distinkta primära noder och repliknoder. En shard kan vara nere medan de andra förblir tillgängliga.

Kommentar

En Basic-cache har inte flera noder och erbjuder inte ett serviceavtal (SLA) för dess tillgänglighet. Grundläggande cacheminnen rekommenderas endast i utvecklings- och testsyfte. Använd en Standard- eller Premium-cache för en distribution med flera noder för att öka tillgängligheten.

Förklaring av en redundansväxling

En redundansväxling inträffar när en repliknod befordrar sig själv till en primär nod och den gamla primära noden stänger befintliga anslutningar. När den primära noden har säkerhetskopierats ser den ändringen i roller och degraderar sig själv till att bli en replik. Den ansluter sedan till den nya primära och synkroniserar data. En redundansväxling kan vara planerad eller oplanerad.

En planerad redundansväxling sker under två olika tider:

  • Systemuppdateringar, till exempel Redis-korrigeringar eller OS-uppgraderingar.
  • Hanteringsåtgärder, till exempel skalning och omstart.

Eftersom noderna får förhandsmeddelande om uppdateringen kan de kooperativt byta roller och snabbt uppdatera lastbalanseraren för ändringen. En planerad redundans slutar vanligtvis på mindre än 1 sekund.

En oplanerad redundansväxling kan inträffa på grund av maskinvarufel, nätverksfel eller andra oväntade avbrott i den primära noden. Repliknoden befordrar sig själv till primär, men processen tar längre tid. En repliknod måste först identifiera att den primära noden inte är tillgänglig innan den kan starta redundansväxlingen. Repliknoden måste också kontrollera att det här oplanerade felet inte är tillfälligt eller lokalt för att undvika onödig redundans. Den här fördröjningen i identifieringen innebär att en oplanerad redundans normalt avslutas inom 10 till 15 sekunder.

Hur sker korrigeringar?

Azure Cache for Redis-tjänsten uppdaterar regelbundet din cache med de senaste plattformsfunktionerna och korrigeringarna. För att korrigera en cache följer tjänsten dessa steg:

  1. Tjänsten korrigerar repliknoden först.
  2. Den korrigerade repliken befordrar sig tillsammans till primär. Den här befordran betraktas som en planerad redundansväxling.
  3. Den tidigare primära noden startas om för att ta de nya ändringarna och kommer tillbaka som en repliknod.
  4. Repliknoden ansluter till den primära noden och synkroniserar data.
  5. När datasynkroniseringen är klar upprepas korrigeringsprocessen för de återstående noderna.

Eftersom korrigering är en planerad redundansväxling befordras repliknoden snabbt till att bli primär. Sedan börjar noden underhålla begäranden och nya anslutningar. Grundläggande cacheminnen har ingen repliknod och är inte tillgängliga förrän uppdateringen är klar. Varje fragment i en klustrad cache korrigeras separat och stänger inte anslutningar till en annan shard.

Viktigt!

Noder korrigeras en i taget för att förhindra dataförlust. Grundläggande cacheminnen kommer att ha dataförlust. Klustrade cacheminnen korrigeras en shard i taget.

Flera cacheminnen i samma resursgrupp och region korrigeras också en i taget. Cacheminnen som finns i olika resursgrupper eller olika regioner kan korrigeras samtidigt.

Eftersom fullständig datasynkronisering sker innan processen upprepas är det osannolikt att dataförlust uppstår när du använder en Standard- eller Premium-cache. Du kan skydda dig ytterligare mot dataförlust genom att exportera data och aktivera beständighet.

Ytterligare cacheinläsning

När en redundansväxling sker måste Standard- och Premium-cacheminnen replikera data från en nod till en annan. Den här replikeringen orsakar en viss belastningsökning i både serverminnet och PROCESSORn. Om cacheinstansen redan är kraftigt inläst kan klientprogrammen få ökad svarstid. I extrema fall kan klientprogram få timeout-undantag. För att minska effekten av mer belastning konfigurerar du inställningen för cacheminnet maxmemory-reserved .

Hur påverkar redundansen mitt klientprogram?

Klientprogram kan få vissa fel från sina Azure Cache For Redis. Antalet fel som visas av ett klientprogram beror på hur många åtgärder som väntade på anslutningen vid tidpunkten för redundansväxlingen. Alla anslutningar som dirigeras via noden som stängde dess anslutningar ser fel.

Många klientbibliotek kan utlösa olika typer av fel när anslutningarna bryts, inklusive:

  • Timeout-undantag
  • undantag för Anslut ion
  • Socket-undantag

Antalet och typen av undantag beror på var begäran finns i kodsökvägen när cachen stänger sina anslutningar. En åtgärd som till exempel skickar en begäran men inte har fått något svar när redundansväxlingen inträffar kan få ett timeout-undantag. Nya begäranden om det stängda anslutningsobjektet tar emot anslutningsfel tills återanslutningen lyckas.

De flesta klientbibliotek försöker återansluta till cacheminnet om de är konfigurerade för att göra det. Oförutsedda buggar kan dock ibland placera biblioteksobjekten i ett oåterkalleligt tillstånd. Om felen kvarstår längre än en förkonfigurerad tid ska anslutningsobjektet återskapas. I Microsoft.NET och andra objektorienterade språk kan du återskapa anslutningen utan att starta om programmet med hjälp av ett ForceReconnect-mönster.

Kan jag meddelas i förväg om underhåll?

Azure Cache for Redis publicerar meddelanden om körningsunderhåll på en publicerings-/prenumerationskanal (pub/sub) med namnet AzureRedisEvents. Många populära Redis-klientbibliotek stöder prenumeration på pub-/underkanaler. Att ta emot meddelanden från AzureRedisEvents kanalen är vanligtvis ett enkelt tillägg till klientprogrammet. Mer information om underhållshändelser finns i AzureRedisEvents.

Kommentar

Kanalen AzureRedisEvents är inte en mekanism som kan meddela dig dagar eller timmar i förväg. Kanalen kan meddela klienter om kommande serverunderhållshändelser som kan påverka serverns tillgänglighet. AzureRedisEvents är endast tillgängligt för nivåerna Basic, Standard och Premium.

Vilka uppdateringar ingår under underhåll?

Underhållet omfattar följande uppdateringar:

  • Redis Server-uppdateringar: Alla uppdateringar eller korrigeringar av Redis-serverns binärfiler.
  • Uppdateringar av virtuell dator (VM): Alla uppdateringar av den virtuella datorn som är värd för Redis-tjänsten. Vm-uppdateringar omfattar korrigering av programvarukomponenter i värdmiljön för uppgradering av nätverkskomponenter eller inaktivering.

Visas underhåll i tjänstens hälsotillstånd i Azure-portalen före en korrigering?

Nej, underhåll visas inte någonstans under tjänstens hälsotillstånd i portalen eller någon annan plats.

Hur lång tid kan jag få meddelandet innan det planerade underhållet?

När du använder AzureRedisEvents kanalen meddelas du 15 minuter före underhållet.

Ändringar i klientnätverkskonfigurationen

Vissa ändringar i nätverkskonfigurationen på klientsidan kan utlösa Inga tillgängliga anslutningsfel. Sådana ändringar kan vara:

  • Växla ett klientprograms virtuella IP-adress mellan mellanlagrings- och produktionsplatser.
  • Skala storleken eller antalet instanser av ditt program.

Sådana ändringar kan orsaka ett anslutningsproblem som vanligtvis varar mindre än en minut. Klientprogrammet förlorar förmodligen sin anslutning till andra externa nätverksresurser, men även till Azure Cache for Redis-tjänsten.

Skapa återhämtning

Du kan inte undvika redundans helt. Skriv i stället dina klientprogram för att vara motståndskraftiga mot anslutningsavbrott och misslyckade begäranden. De flesta klientbibliotek återansluter automatiskt till cacheslutpunkten, men få av dem försöker försöka utföra misslyckade begäranden igen. Beroende på programscenariot kan det vara klokt att använda logik för återförsök med backoff.

Hur gör jag för att göra mitt program motståndskraftigt?

Se dessa designmönster för att skapa motståndskraftiga klienter, särskilt kretsbrytaren och återförsöksmönster:

Om du vill testa ett klientprograms återhämtning använder du en omstart som en manuell utlösare för anslutningsavbrott.

Dessutom rekommenderar vi att du använder schemalagda uppdateringar för att välja en uppdateringskanal och ett underhållsperiod för din cache för att tillämpa Redis-körningskorrigeringar under specifika veckofönster. Dessa fönster är vanligtvis perioder då klientprogramtrafiken är låg för att undvika potentiella incidenter. Mer information finns i Uppdatera kanal och Schemalägg uppdateringar.

Mer information finns i Anslut ionsresiliens.

Relaterat innehåll