Hög tillgänglighet och haveriberedskap

Precis som för alla molnsystem kan det uppstå oplanerade avbrott som gör att en virtuell datorinstans (VM), en tillgänglighetszon eller en fullständig Azure-region slutar fungera. Vi rekommenderar att kunderna har en plan för att hantera zon- eller regionala avbrott.

Den här artikeln visar information för kunder om hur de skapar en plan för affärskontinuitet och haveriberedskap för azure cache for Redis eller Azure Cache for Redis Enterprise-implementering.

Det finns olika alternativ för hög tillgänglighet på nivåerna Standard, Premium och Enterprise:

Standardreplikering för hög tillgänglighet

Tillämpliga nivåer: Standard, Premium, Enterprise, Enterprise Flash

Rekommenderas för: Hög tillgänglighet

Azure Cache for Redis har en arkitektur med hög tillgänglighet som säkerställer att din hanterade instans fungerar, även när avbrott påverkar de underliggande virtuella datorerna (VM). Oavsett om avbrotten är planerade eller oplanerade avbrott ger Azure Cache for Redis högre tillgänglighet i procent än vad som kan uppnås genom att vara värd för Redis på en enda virtuell dator.

En Azure Cache for Redis på tillämpliga nivåer körs som standard på ett par Redis-servrar. De två servrarna finns på dedikerade virtuella datorer. Redis med öppen källkod tillåter endast en server att hantera begäranden om dataskrivning.

Med Azure Cache for Redis är en server den primära noden, medan den andra är repliken. När den har etablerat servernoderna tilldelar Azure Cache for Redis primära roller och replikroller till dem. Den primära noden ansvarar vanligtvis för att underhålla skriv- och läsbegäranden från klienter. Vid en skrivåtgärd skriver den en ny nyckel och en uppdatering av nyckeln i det interna minnet och svarar omedelbart till klienten. Operationen vidarebefordras till repliken asynkront.

Om den primära noden i en cache inte är tillgänglig befordras repliken automatiskt till den nya primära noden. Den här processen kallas för felövergång. En redundansväxling innebär att två noder, primär/replika, byter roller, replika/primär, där en av noderna kan gå offline i några minuter. Vid de flesta failover-processer samordnar de primära och repliknoderna överlämningen så att du har nära nog ingen tid utan en primär nod.

Den tidigare primärservern kopplar bort en kort stund för att mottaga uppdateringar från den nya primärservern. Repliken kommer då online igen och ansluter till cachen helt synkroniserad. Nyckeln är att när en nod inte är tillgänglig är det ett tillfälligt villkor och det är online igen.

En typisk redundanssekvens ser ut så här när en primär behöver gå ner för underhåll:

1. Huvudnoder och repliknoder förhandlar om en samordnad övergång och byter roller.
2. Replikservern (tidigare primär) går offline för omstart.
3. Några sekunder eller minuter senare är repliken online igen.
4. Repliken synkroniserar data från den primära.

En primär nod kan gå ur drift som en del av en planerad underhållsaktivitet, till exempel en uppdatering av Redis-programvaran eller operativsystemet. Det kan också sluta fungera på grund av oplanerade händelser, till exempel fel i underliggande maskinvara, programvara eller nätverk. Failover och patchning för Azure Cache for Redis ger en detaljerad förklaring av typer av failovers. En Azure Cache for Redis genomgår många failover under sin livslängd. Utformningen av arkitekturen för hög tillgänglighet gör dessa ändringar i en cache så transparent för sina klienter som möjligt.

Dessutom tillhandahåller Azure Cache for Redis fler repliknoder på Premium-nivån. En cache med flera repliker kan konfigureras med upp till tre repliknoder. Att ha fler repliker förbättrar vanligtvis motståndskraft eftersom du har noder som stödjer den primära. Även med fler repliker kan en Azure Cache for Redis-instans fortfarande påverkas allvarligt av ett avbrott i ett datacenter eller en tillgänglighetszon. Du kan öka cachetillgängligheten genom att använda flera repliker med zonredundans.

Zon-redundans

Tillämpliga nivåer: Standard, Premium, Enterprise, Enterprise Flash

Rekommenderas för: Hög tillgänglighet, haveriberedskap – intra region

Azure Cache for Redis stöder zonredundanta konfigurationer på nivåerna Standard, Premium och Enterprise. En zonredundant cache kan placera sina noder i olika Azure-Tillgänglighetszoner i samma region. Det eliminerar avbrott i datacenter eller tillgänglighetszoner som en felkälla och ökar den övergripande tillgängligheten för cacheminnet.

Om en cache är konfigurerad för att använda två eller flera zoner enligt beskrivningen tidigare i artikeln skapas cachenoderna i olika zoner. När en zon är ur funktion, förblir cachenoder i andra zoner tillgängliga för att säkerställa att cacheminnet fortsätter att fungera som vanligt.

Premiumnivå

Följande diagram illustrerar zonredundant konfiguration för Premium-nivån:

Azure Cache for Redis distribuerar noder i en zonredundant cache i ett rundgångssätt över de valda tillgänglighetszonerna. Den avgör också vilken nod som fungerar som primär från början.

Zon ned-upplevelse för Premium-nivå

En zonredundant cache ger automatisk överlåsning. När den aktuella primära noden inte är tillgänglig tar en av replikerna över. Ditt program kan få högre svarstid för cacheminnet om den nya primära noden finns i en annan AZ. Tillgänglighetszoner avgränsas geografiskt. Om du byter från en AZ till en annan ändras det fysiska avståndet mellan där programmet och cachen finns. Den här ändringen påverkar tur-och-retur-fördröjningen i nätverket från ditt program till cacheminnet. Den extra svarstiden förväntas ligga inom ett acceptabelt intervall för de flesta program. Vi rekommenderar att du testar ditt program för att säkerställa att det fungerar bra med en zonredundant cache.

Enterprise- och Enterprise Flash-nivåer

En cache på antingen Enterprise-nivå körs på ett Redis Enterprise-kluster. Det krävs alltid ett udda antal servernoder för att bilda ett kvorum. Som standard har den tre noder som var och en finns på en dedikerad virtuell dator.

• En Enterprise-cache har två datanoder i samma storlek och en mindre kvorumnod.
• Ett Enterprise Flash-cacheminne har tre datanoder i samma storlek.

Enterprise-klustret delar in Azure Cache for Redis-data i partitioner internt. Varje partition har en primär och minst en replik. Varje datanod innehåller en eller flera partitioner. Enterprise-klustret säkerställer att den primära och replika/replikorna av en partition aldrig placeras på samma datanod. Partitioner replikerar data asynkront från primärer till deras motsvarande kopior.

Reducerad upplevelse för företagsnivåer

När en datanod blir otillgänglig eller en nätverksdelning sker sker en redundansväxling som liknar den som beskrivs i Standard-replikering . Enterprise-klustret använder en kvorumbaserad modell för att avgöra vilka kvarvarande noder som deltar i ett nytt kvorum. Det befordrar också replikpartitioner inom dessa noder till primära databaser vid behov.

Regional tillgänglighet

Zon-redundanta Premium- och standardcacheminnen är tillgängliga i följande regioner:

De zonredundanta cacharna på Enterprise- och Enterprise Flash-nivåerna finns tillgängliga i följande regioner:

* Enterprise Flash-nivån är inte tillgänglig i den här regionen.

Omdistribution och migrering av tillgänglighetszon

På nivåerna Standard och Premium kan du uppgradera en befintlig resurs för att använda zonredundans. Information om hur du uppgraderar din aktuella cache finns i Migrera en Azure Cache for Redis-instans till stöd för tillgänglighetszoner.

Uthållighet

Tillämpliga nivåer: Premium, Enterprise (förhandsversion), Enterprise Flash (förhandsversion)

Rekommenderas för: Datahållbarhet

Eftersom cachedata lagras i minnet kan ett sällsynt och oplanerat fel på flera noder göra att alla data tas bort. För att undvika att förlora data helt kan du med Redis persistence ta regelbundna ögonblicksbilder av minnesinterna data och lagra dem på ditt lagringskonto. Om det uppstår ett fel mellan flera noder som orsakar dataförlust läser cachen in ögonblicksbilden från lagringskontot. Mer information finns i Konfigurera datapersistence för en Premium Azure Cache for Redis-instans.

Lagringskonto för beständighet

Överväg att välja ett geo-redundant lagringskonto för att säkerställa hög tillgänglighet för beständiga data. Läs mer i Redundansalternativ för Azure Storage.

Importera/Exportera

Tillämpliga nivåer: Premium, Enterprise, Enterprise Flash

Rekommenderas för: Haveriberedskap

Azure Cache for Redis har stöd för alternativet att importera och exportera Redis Database-filer (RDB) för att tillhandahålla dataportabilitet. Med den kan du importera data till Azure Cache for Redis eller exportera data från Azure Cache for Redis med hjälp av en RDB-ögonblicksbild. RDB-ögonblicksbilden från en Premium-cache exporteras till en blob i ett Azure Storage-konto. Du kan skapa ett skript som utlöser export med jämna mellanrum till ditt lagringskonto. Mer information finns i Importera och exportera data i Azure Cache for Redis.

Lagringskonto för export

Överväg att välja ett geo-redundant lagringskonto för att säkerställa hög tillgänglighet för dina exporterade data. Läs mer i Redundansalternativ för Azure Storage.

Passiv geo-replikering

Tillämpliga nivåer: Premium

Rekommenderas för: Haveriberedskap – enskild region

Geo-replikering är en mekanism för att länka två Azure Cache for Redis-instanser, som vanligtvis omfattar två Azure-regioner. Geo-replikation är främst utformad för katastrofåterställning över regioner. Två cacheinstanser på Premium-nivån är anslutna via geo-replikering på ett sätt som ger läsningar och skrivningar till din primära cache och att data replikeras till den sekundära cachen.

För mer information om hur du konfigurerar det, se Konfigurera geo-replikering för Premium Azure Cache för Redis-instanser.

Om den region som är värd för den primära cachen slutar fungera måste du starta redundansväxlingen genom att först ta bort länken till den sekundära cachen och sedan uppdatera programmet så att det pekar på den sekundära cachen för läsningar och skrivningar.

Aktiv geo-replikering

Tillämpliga nivåer: Enterprise, Enterprise Flash

Rekommenderas för: Hög tillgänglighet, haveriberedskap – flera regioner

Enterprise-nivåerna stöder en mer avancerad form av geo-replikering som kallas aktiv geo-replikering och som erbjuder både högre tillgänglighet och haveriberedskap över flera regioner. Azure Cache for Redis Enterprise-programvaran använder konfliktfria replikerade datatyper för att stödja skrivningar till flera cacheinstanser, sammanfogar ändringar och löser konflikter. Du kan ansluta upp till fem cacheinstanser på Enterprise-nivå i olika Azure-regioner för att bilda en geo-replikeringsgrupp.

Ett program som använder en sådan cache kan läsa och skriva till någon av de geo-distribuerade cacheinstanserna via motsvarande slutpunkter. Programmet bör använda det som är närmast varje programinstans, vilket ger dig den lägsta svarstiden. För mer information, se Konfigurera aktiv geo-replikering för Enterprise Azure Cache for Redis-instanser.

Om en region i en av cacheminnena i replikeringsgruppen slutar fungera måste programmet växla till en annan region som är tillgänglig.

När en cache i replikeringsgruppen inte är tillgänglig rekommenderar vi att du övervakar minnesanvändningen för andra cacheminnen i samma replikeringsgrupp. Medan en av cacheminnena är nere börjar alla andra cacheminnen i replikeringsgruppen spara metadata som de inte kunde dela med cacheminnet som ligger nere. Om minnesanvändningen för de tillgängliga cacheminnena börjar växa med hög hastighet efter att en av cacheminnena har gått ned bör du ta bort länken till den cache som inte är tillgänglig från replikeringsgruppen.

Mer information om att upphäva länkning finns i Upphäva länkning vid regionalt avbrott.

Ta bort och återskapa cache

Tillämpliga nivåer: Standard, Premium, Enterprise, Enterprise Flash

Om det uppstår ett regionalt avbrott kan du överväga att återskapa cacheminnet i en annan region och uppdatera programmet för att ansluta till den nya cachen i stället. Det är viktigt att förstå att data går förlorade under ett regionalt avbrott. Programkoden ska vara motståndskraftig mot dataförlust.

När den berörda regionen har återställts återställs din otillgängliga Azure Cache for Redis automatiskt och är tillgänglig för användning igen. Fler strategier för att flytta din cache till en annan region finns i Flytta Azure Cache for Redis-instanser till olika regioner.

Nästa steg

Läs mer om hur du konfigurerar alternativ för hög tillgänglighet i Azure Cache for Redis.

• Azure Cache for Redis Premium-tjänstnivåer
• Lägga till repliker i Azure Cache for Redis
• Aktivera zonredundans för Azure Cache for Redis
• Konfigurera geo-replikering för Azure Cache for Redis