Tillförlitlighet i Azure Managed Redis

Azure Managed Redis tillhandahåller fullständigt integrerad och hanterad Redis Enterprise på Azure och erbjuder datalagring med höga prestanda i minnet för program. Den här tjänsten är byggd för företagsarbetsbelastningar som kräver extremt låg svarstid, högt dataflöde och avancerade datastrukturer.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver tillförlitligheten i Azure Managed Redis, inklusive motståndskraft mot tillfälliga fel, fel i tillgänglighetszonen och regionomfattande fel. Artikeln beskriver också säkerhetskopieringsstrategier och serviceavtal (SLA).

Rekommendationer för produktionsdistribution

För att säkerställa hög tillförlitlighet för dina Azure Managed Redis-produktionsinstanser rekommenderar vi att du:

• Aktivera hög tillgänglighet, som distribuerar flera noder för din cache.
• Aktivera zonredundans genom att distribuera en cache med hög tillgänglighet till en region med tillgänglighetszoner.
• Överväg att implementera aktiv geo-replikering för verksamhetskritiska arbetsbelastningar som kräver redundans mellan regioner.

Översikt över tillförlitlighetsarkitektur

I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.

Logisk arkitektur

Azure Managed Redis bygger på Redis Enterprise och ger tillförlitlighet genom konfigurationer och replikeringsfunktioner med hög tillgänglighet.

Du distribuerar en instans av Azure Managed Redis, som även kallas för en cacheinstans eller en cache. Dina klientprogram lagrar och interagerar med data i cachen med hjälp av Redis-API:er.

Fysisk arkitektur

Det finns två viktiga begrepp som du behöver förstå när du planerar återhämtning för Azure Managed Redis: noder och shards.

• Noder: Varje cacheinstans består av noder, som är virtuella datorer (VM). Varje virtuell dator fungerar som en oberoende beräkningsenhet i klustret. Du ser eller hanterar inte de virtuella datorerna direkt. Plattformen hanterar automatiskt skapande av instanser, hälsoövervakning och ersättning av instanser med feltillstånd. Den uppsättning virtuella datorer som tas tillsammans kallas även för ett kluster.

  Du kan konfigurera din instans för hög tillgänglighet. När du gör det ser Azure Managed Redis till att det finns minst två noder och replikerar data mellan noderna automatiskt. I regioner med tillgänglighetszoner placeras noderna i olika tillgänglighetszoner. Mer information finns i Motståndskraft mot fel i tillgänglighetszonen.

  Tjänsten abstraherar det specifika antalet noder som används i varje konfiguration för att undvika komplexitet och säkerställa optimala konfigurationer.

• Shards: Varje nod kör flera Redis-serverprocesser som kallas shards och som hanterar en delmängd av din caches data. När cacheminnet har konfigurerats för hög tillgänglighet distribueras och replikeras shards automatiskt mellan noder. Du anger en klusterprincip som avgör hur shards distribueras mellan noder.

Mer information finns i Azure Managed Redis-arkitektur och redundans och korrigering för Azure Managed Redis.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

Följ dessa rekommendationer för att hantera tillfälliga fel när du använder Azure Managed Redis:

• Använd SDK-konfigurationer som automatiskt försöker igen när tillfälliga fel inträffar och som använder lämpliga backoff- och timeout-perioder. Överväg att använda Återförsöksmönster och Kretsbrytarmönster i dina program.
• Designa för cache-aside-mönster där ditt program kan fortsätta att fungera med försämrad prestanda när Redis är tillfälligt otillgänglig genom att återgå till det primära datalagret.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Azure Managed Redis-cacheinstanser kan göras zonredundanta, vilket automatiskt distribuerar cachenoderna över flera tillgänglighetszoner i en region. Zonredundans minskar risken för avbrott i datacenter eller tillgänglighetszoner som gör att cacheminnet inte är tillgängligt.

Om du vill göra en cachezon redundant måste du distribuera den till en region som stöds och aktivera konfiguration med hög tillgänglighet. I regioner utan tillgänglighetszoner skapar konfigurationen med hög tillgänglighet fortfarande minst två noder, men de finns inte i separata zoner.

Följande diagram visar en zonredundant cache med två noder, var och en i en separat zon:

Kravspecifikation

• Regionstöd: Zonredundanta Azure Managed Redis-cacheminnen kan distribueras till alla regioner som stöder tillgänglighetszoner och där tjänsten är tillgänglig. Den senaste listan över regioner som stöder tillgänglighetszoner finns i Azure-regioner med tillgänglighetszoner. En lista över regioner som stöder Azure Managed Redis finns i Produkttillgänglighet per region.

• Konfiguration med hög tillgänglighet: Du måste aktivera konfiguration med hög tillgänglighet i cacheminnet för att den ska vara zonredundant.

• Nivåer: Alla Azure Managed Redis-nivåer har stöd för tillgänglighetszoner.

Kostnad

Zonredundans kräver att cacheminnet är konfigurerat för hög tillgänglighet, vilket distribuerar minst två noder för cacheminnet. Konfiguration med hög tillgänglighet debiteras till en högre taxa än konfiguration utan hög tillgänglighet. Mer information finns i Priser för Azure Managed Redis

Konfigurera stöd för tillgänglighetszoner

• Skapa en ny zonredundant instans: När du skapar en ny Azure Managed Redis-instans aktiverar du konfiguration med hög tillgänglighet och distribuerar den till en region med tillgänglighetszoner. Sedan innehåller den automatiskt zonredundans som standard. Du behöver inte utföra någon mer konfiguration.

  Detaljerade steg finns i Snabbstart: Skapa en Azure Managed Redis-instans.

• Aktivera zonredundans på en befintlig instans: Om du vill konfigurera en befintlig Azure Managed Redis-instans som zonredundant kontrollerar du att den distribueras i en region som stöder tillgänglighetszoner och aktiverar hög tillgänglighet i cacheminnet.

• Inaktivera zonredundans: Zonredundans kan inte inaktiveras på befintliga instanser, eftersom du inte kan inaktivera hög tillgänglighet när den är aktiverad på en cacheinstans.

Kapacitetsplanering och -hantering

Under en zon-neddragning kan det hända att din instans har färre resurser tillgängliga för att stödja arbetsbelastningen. Om din instans ofta är under resursbelastning och du behöver förbereda dig för fel i tillgänglighetszonen bör du överväga någon av följande metoder:

• Överetablera din instans: Överetablering innebär att du väljer en högre prestandanivå än du kanske behöver. Det gör att din instans kan tolerera viss kapacitetsförlust och fortsätta att fungera utan försämrad prestanda. Mer information om principen för överetablering finns i Hantera kapacitet genom överetablering. Information om hur du skalar instansen finns i Skala en Azure Managed Redis-instans.

• Använd aktiv geo-replikering: Du kan distribuera flera instanser i olika regioner och konfigurera aktiv geo-replikering för att sprida belastningen över dessa separata instanser.

Beteende när alla zoner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när en hanterad Redis-cache är zonredundant och alla tillgänglighetszoner är i drift:

• Trafikroutning mellan zoner: Shards distribueras mellan noder baserat på din klusterprincip. Klusterprincipen avgör också hur trafik dirigeras till varje nod. Zonredundans ändrar inte hur trafiken dirigeras.

• Datareplikering mellan zoner: Shards replikeras automatiskt mellan noder och använder asynkron replikering. Vanligtvis mäts replikeringsfördröjningen mellan shards i sekunder, men det kan variera beroende på cachens arbetsbelastning, med skrivintensiva och nätverksintensiva scenarier som vanligtvis ser högre replikeringsfördröjning.

Beteende vid ett zonfel

I det här avsnittet beskrivs vad du kan förvänta dig när en hanterad Redis-cache är zonredundant och en eller flera tillgänglighetszoner inte är tillgängliga:

• Identifiering och svar: Azure Managed Redis ansvarar för att identifiera ett fel i en tillgänglighetszon. Du behöver inte göra något för att påbörja en zone-failover.

• Meddelande: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

• Aktiva begäranden: Begäranden under flygning kan tas bort och bör göras om. Program bör implementera logik för återförsök för att hantera dessa tillfälliga avbrott.

• Förväntad dataförlust: Data som inte har replikerats till shards i en annan zon kan gå förlorade vid ett zonfel. Vanligtvis mäts mängden dataförlust i sekunder, men det beror på replikeringsfördröjningen.

• Förväntad stilleståndstid: En liten mängd stilleståndstid, vanligtvis 10–15 sekunder, kan inträffa medan shards redundansväxlar till noder i felfria zoner. Information om den oplanerade redundansprocessen finns i Förklaring av en redundans när du utformar program, följ metoderna för tillfällig felhantering.

• Omdistribution av trafik: Azure Managed Redis omdirigerar automatiskt trafik till noder i felfria zoner.

Zonåterställning

När den berörda tillgänglighetszonen återställs återställer Azure Managed Redis automatiskt åtgärder till den zonen. Azure-plattformen hanterar den här processen fullständigt och kräver inga kundinterventioner.

Test för zonfel

Eftersom Azure Managed Redis fullständigt hanterar trafikroutning, redundans och återställning efter fel i zonen behöver du inte verifiera felprocesser i tillgänglighetszonen eller ange ytterligare indata.

Motståndskraft mot regionomfattande fel

Azure Managed Redis tillhandahåller inbyggt stöd för flera regioner via aktiv geo-replikering, vilket gör att du kan länka flera Azure Managed Redis-instanser mellan olika Azure-regioner till en enda replikeringsgrupp. Du kan sedan konfigurera din egen redundansmetod mellan instanserna.

Aktiv geografisk replikering

När du använder aktiv geo-replikering kan program läsa från och skriva till alla cacheinstanser i gruppen, med ändringar som synkroniseras automatiskt i alla regioner. Tjänsten stöder aktivt aktiva replikeringsmönster där varje region kan hantera både läs- och skrivåtgärder samtidigt. När konflikter uppstår på grund av samtidiga skrivningar i olika regioner löser tjänsten dem automatiskt med hjälp av förutbestämda konfliktlösningsalgoritmer utan att kräva manuella åtgärder. Den här metoden ger återhämtning till regionfel samtidigt som åtkomst med låg latens bibehålls för globalt distribuerade program.

Följande diagram visar två cacheinstanser i olika regioner inom samma aktiva geo-replikeringsgrupp, med klientprogram som ansluter till varje cacheinstans:

Du ansvarar för att konfigurera dina klientprogram så att de, om någon regional instans misslyckas, kan omdirigera sina begäranden till en felfri instans. Följande diagram visar hur ett program kan omdirigera sina begäranden till en felfri cacheinstans när den instans som de vanligtvis använder misslyckas:

Kravspecifikation

• Regionstöd Azure Managed Redis aktiv geo-replikering kan konfigureras mellan alla Azure-regioner där tjänsten är tillgänglig.

• Instanskonfiguration: Aktiv geo-replikering kräver Azure Managed Redis-instanser på samma nivå och storlek i alla deltagande regioner. Alla cacheinstanser i en replikeringsgrupp måste konfigureras med identiska inställningar, inklusive beständighetsalternativ, moduler och klustringsprinciper.

• Andra krav: Dina cacheinstanser måste uppfylla andra krav, inklusive de moduler som du använder, och det påverkar hur dina cacheinstanser kan skalas. Mer information finns i Krav för aktiv geo-replikering.

Överväganden

• Ansvar för failover: När du använder aktiv geo-replikering ansvarar du för att utföra failover mellan cacheinstanser. Du bör förbereda och konfigurera programmet för att hantera redundans. Failover innefattar förberedelser och kan kräva att flera steg genomförs. Mer information finns i Avbryt tvångslänken vid regionsavbrott.

• Slutlig konsekvens: Program bör utformas för att hantera eventuella konsekvensscenarier, eftersom ändringar kan ta tid att sprida över alla regioner beroende på nätverksförhållanden och geografiskt avstånd. Under regionstopp kan det uppstå fler inkonsekvenser i data tills anslutningen har återställts och synkroniseringen har slutförts.

Kostnad

När du aktiverar aktiv geo-replikering debiteras du för varje Azure Managed Redis-instans i varje region i replikeringsgruppen. Dessutom kan du debiteras dataöverföringsavgifter för replikeringstrafik mellan regioner. Mer information om priser finns i Prissättning för Azure Managed Redis och prisinformation om bandbredd.

Konfigurera stöd för flera regioner

• Skapa en ny geo-replikerad cacheinstans: Konfigurera aktiv geo-replikering under cacheetablering genom att ange en replikeringsgrupp och länka flera instanser. Mer information finns i Skapa eller ansluta till en aktiv geo-replikeringsgrupp.

• Aktivera en befintlig cacheinstans för geo-replikering: Du kan lägga till en befintlig cacheinstans i en aktiv geo-replikeringsgrupp.

  Men när en befintlig instans läggs till i en aktiv geo-replikeringsgrupp måste data i instansen rensas och det finns en liten mängd stilleståndstid. Planera om möjligt att aktivera aktiv geo-replikering när du skapar cacheinstanser.

  Mer information finns i Lägga till en befintlig instans i en aktiv geo-replikeringsgrupp.

• Inaktivera geo-replikering på en cacheinstans: Ta bort en instans från en geo-replikeringsgrupp genom att ta bort cacheinstansen. De återstående instanserna konfigurerar automatiskt om sig själva.

Kapacitetsplanering och -hantering

Under ett regionavbrott kan de andra instanserna vara utsatta för högre belastning. Om en instans ofta redan är under resursbelastning och du behöver förbereda dig för de ökade kapacitetskraven vid ett regionfel bör du överväga att överetablera instansen. Information om hur du skalar en instans finns i Skala en Azure Managed Redis-instans.

Beteende när alla regioner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när instanser är konfigurerade att använda aktiv geo-replikering och alla regioner är i drift.

• Trafikroutning mellan regioner: Du ansvarar för att konfigurera dina program för att ansluta till en specifik cacheinstans. Program kan ansluta till valfri cacheinstans i replikeringsgruppen och utföra både läs- och skrivåtgärder. Trafikroutning hanteras av programmet, så att du kan dirigera klienter till närmaste region för minimal svarstid. Azure Managed Redis tillhandahåller inte automatisk trafikroutning mellan regioner.

• Datareplikering mellan regioner: Tjänsten använder asynkron replikering mellan regioner för att upprätthålla eventuell konsistens. Skrivåtgärder utförs omedelbart i den lokala regionen och sprids sedan till andra regioner i bakgrunden. Konfliktfria replikerade datatyper (CRDT) säkerställer att samtidiga skrivningar i olika regioner sammanfogas automatiskt.

Beteende under ett regionfel

Det här avsnittet beskriver vad du kan förvänta dig när instanser är konfigurerade att använda aktiv geo-replikering och det uppstår ett avbrott i en region:

• Identifiering och svar: Du ansvarar för att identifiera när en cacheinstans misslyckas, och att bestämma när failover ska genomföras. Du kan övervaka hälsotillståndet för ett geo-replikerat kluster, vilket kan hjälpa dig att bestämma när omkopplingen ska påbörjas. Mer information finns i Geo-replikeringsmått.

  Redundans kräver att du utför flera steg. Mer information finns i Force-unlink vid ett regionalt avbrott.

• Anmälan: Microsoft meddelar dig inte automatiskt när en region är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella regionfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

  Du kan också övervaka hälsotillståndet för varje instans.

  Om du vill övervaka hälsotillståndet för geo-replikeringsrelationen kan du använda metriken Geo-replikering hälsosam. Måttet har alltid värdet 1 (felfri) eller 0 (inte felfri). Du kan konfigurera Azure Monitor-aviseringar för det här måttet för att förstå när instanserna kan vara osynkroniserade.

• Aktiva begäranden: Begäranden till den misslyckade regionen avslutas och måste hanteras av programmets redundanslogik. Program bör implementera återförsöksprinciper som kan omdirigera trafik till felfria cacheminnen.

• Förväntad dataförlust: På grund av asynkron replikering mellan regioner kan vissa senaste skrivningar till den misslyckade regionen gå förlorade om de ännu inte har replikerats till andra regioner. Mängden potentiell dataförlust beror på replikeringsfördröjningen vid tidpunkten för felet. Mer information finns i Active-Active geo-distribuerade Redis och överväganden om konsekvens och dataförlust vid ett regionalt CRDB-fel.

• Förväntad stilleståndstid: Program upplever endast stilleståndstid under den tid som krävs för att identifiera felet och omdirigera trafik till felfria regioner. Detta sträcker sig vanligtvis från sekunder till några minuter, beroende på hur du har konfigurerat programmets hälsokontroll och redundanskonfiguration.

• Omdistribution av trafik: Du ansvarar för att implementera logik i dina program för att identifiera regionfel och dirigera trafik till felfria regioner. Detta kan åstadkommas genom hälsokontroller, kretsbrytarmönster eller externa belastningsutjämningslösningar.

Regionåterställning

När en misslyckad region återställs återintegrerar Azure Managed Redis automatiskt instanser i den regionen i den aktiva geo-replikeringsgruppen utan att du behöver göra något. Tjänsten synkroniserar automatiskt data från friska instanser. Under den här processen kommer den återställda instansen gradvis ikapp de ändringar som inträffade under driftstoppet. När synkroniseringen är klar blir de återställda instanserna helt aktiva och kan hantera både läs- och skrivåtgärder.

Du ansvarar för att konfigurera om programmet för att dirigera trafik tillbaka till den återställda regioninstansen.

Test för regionfel

Du bör regelbundet testa programmets redundansprocedurer. Det är viktigt att ditt program kan växla över mellan instanser och att det håller sig inom dina affärskrav för maximal stilleståndstid när det gör det. Det är också viktigt att du testar dina övergripande svarsprocesser, inklusive eventuell omkonfiguration av brandväggar och annan infrastruktur och återställningsprocessen.

Motståndskraft mot serviceunderhåll

Azure Managed Redis utför regelbundna serviceuppgraderingar och andra underhållsaktiviteter.

När underhåll pågår skapar Azure Managed Redis automatiskt nya noder och utför redundans automatiskt. Klientprogram kan se anslutningsavbrott och andra tillfälliga fel. Program bör implementera logik för återförsök för att hantera dessa tillfälliga avbrott.

Mer information om underhållsprocesserna för Azure Managed Redis finns i Redundans och korrigering för Azure Managed Redis.

Säkerhetskopiering och återställning

Azure Managed Redis tillhandahåller både funktioner för datapersistence och säkerhetskopiering för att skydda mot dataförlustscenarier som andra tillförlitlighetsfunktioner kanske inte hanterar. Säkerhetskopior kan skydda mot scenarier som skadade data, oavsiktlig borttagning eller konfigurationsfel.

• Datapersistence: Som standard lagrar Azure Managed Redis alla cachedata i minnet. Du kan också skriva ögonblicksbilder av dina data till disk med hjälp av datapersistence. Om det uppstår ett maskinvarufel som påverkar noden återställer Azure Managed Redis automatiskt data. Det finns olika typer av datapersistence som du kan välja mellan, vilket ger olika kompromisser mellan ögonblicksbildfrekvens och prestandaeffekter på cacheminnet.

  Datafiler kan dock inte återställas till en annan instans och du kan inte komma åt filerna. Datapersistence skyddar dig inte mot skadade data eller oavsiktlig borttagning.

• Importera och exportera: Azure Managed Redis stöder säkerhetskopiering av dina data med hjälp av import- och exportfunktionen, vilket sparar säkerhetskopieringsfiler till Azure Blob Storage. Du kan konfigurera geo-redundant lagring på ditt Azure Storage-konto, eller så kan du kopiera eller flytta säkerhetskopieringsblobbarna till andra platser för ytterligare skydd.

  Exporterade filer kan återställas till samma cacheinstans eller en annan cacheinstans.

  Det finns ingen inbyggd import- eller exportschemaläggare, men du kan utveckla dina egna automatiseringsprocesser som använder Azure CLI eller Azure PowerShell för att initiera exportåtgärder.

Serviceavtal

Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.

Serviceavtalet för Azure Managed Redis omfattar anslutning till cacheslutpunkterna. Serviceavtalet omfattar inte skydd mot dataförlust.

För att vara berättigad till tillgänglighets serviceavtal för Azure Managed Redis:

• Du måste aktivera konfiguration med hög tillgänglighet.
• Du får inte initiera några produktfunktioner eller hanteringsåtgärder som dokumenteras för att skapa tillfällig otillgänglighet.

Serviceavtal för högre tillgänglighet gäller när din instans är zonredundant. På vissa nivåer kan du vara berättigad till ett serviceavtal med högre tillgänglighet när du har distribuerat zonredundanta instanser till minst tre regioner med aktiv geo-replikering.