Felövergång och patchning för Azure Cache for Redis

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 cache-failover sker när hanteringstjänsten uppdaterar binärfilerna för Azure Cache for Redis.

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

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

Vad är en felväxling?

Vi börjar med en översikt över failover 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.

Förklaring av ett failover-system

En felvä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 återställts upptäcker den förändringen i roller och nedgraderas till en replik. Den ansluter sedan till den nya primära och synkroniserar data. En redundansväxling kan vara planerad eller oplanerad.

En planerad övergång sker vid två olika tidpunkter.

• 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 failover vanligtvis är genomfört på 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 själv i samförstånd 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 patchning är en planerad omställning uppgraderas repliknoden snabbt för att bli primär. Sedan börjar noden behandla begäranden och nya anslutningar. Grundläggande cacheminnen har ingen repliknod och är inte tillgängliga förrän uppdateringen är klar. Varje skärva i ett klustrat cache patchas separat och stänger inte anslutningar till en annan skärva.

Flera cacheminnen i samma resursgrupp och region korrigeras också en i taget. Cacheminnen som finns i olika resursgrupper eller olika regioner kan patchas 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å tidsgräns-undantag. För att minska effekten av mer belastning konfigurerar du inställningen för cacheminnet maxmemory-reserved .

Hur påverkar en failover mitt klientprogram?

Klientprogrammen kan få en del fel från sina Azure Cache for Redis. Antalet fel som visas av en klientapplikation beror på hur många operationer som väntade på anslutningen vid tidpunkten för felövergången. Alla anslutningar som dirigeras via noden som stängde sina anslutningar möter fel.

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

• Timeout-undantag
• Anslutningsfel
• Socket-undantag

Antalet och typen av undantag beror på var begäran finns i kodsökvägen när cachen stänger sina anslutningar. Till exempel kan en operation som skickar en begäran men inte har fått något svar när felövergången inträffar få ett timeout-undantag. Nya begäranden om det stängda anslutningsobjektet tar emot anslutningsundantag 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.

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 inkluderar att uppdatera programvarukomponenter i värdmiljön, uppgradera nätverkskomponenter eller avveckla dem.

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 Ingen anslutning tillgänglig-fel. 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.

Inbygg motståndskraft

Du kan inte undvika systembyte 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 mitt program motståndskraftigt?

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

• Tillförlitlighetsmönster – Mönster för molndesign
• Återförsöksvägledning för Azure-tjänster – Metodtips för molnprogram
• Implementera återförsök med exponentiell backoff

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 Anslutningsresiliens.

Relaterat innehåll

• Uppdatera kanal- och schemauppdateringar
• Testa programmets återhämtning med hjälp av en omstart
• Konfigurera minnesreservationer och principer