Hög tillgänglighet och haveriberedskap med Azure Managed Redis (förhandsversion)
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 beskriver informationen för kunder att skapa en plan för affärskontinuitet och haveriberedskap för implementeringen av Azure Managed Redis (förhandsversion).
Alternativ för hög tillgänglighet:
| Alternativ | Description | Tillgänglighet |
|---|---|---|
| Standardreplikering | Replikerad konfiguration med dubbla noder i ett enda datacenter med automatisk redundans | 99,9 % (se information) |
| Zonredundans | Replikerad konfiguration med flera noder över Tillgänglighetszoner, med automatisk redundans | 99,99 % (se information) |
| Geo-replikering | Länkade cacheinstanser i två regioner, med användarkontrollerad redundans | Aktiv (se information) |
| Import/Export | Ögonblicksbild från tidpunkt av data i cacheminnet. | 99,9 % (se information) |
| Ståndaktighet | Periodisk databesparing till lagringskonto. | 99,9 % (se information) |
Standardreplikering för hög tillgänglighet
Rekommenderas för: Hög tillgänglighet
Azure Managed 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 Managed 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 Managed Redis-konfiguration körs som standard på ett par Redis-servrar. De två servrarna finns på dedikerade virtuella datorer.
Med Azure Managed Redis är en server den primära noden, medan den andra är repliken. När den har etablerat servernoderna tilldelar Azure Managed 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 checkar den in en ny nyckel och en nyckeluppdatering till det interna minnet och svarar omedelbart på klienten. Åtgärden 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 redundansväxling. En redundansväxling är bara två noder, primär/replik, handelsroller, replik/primär, där en av noderna eventuellt går offline i några minuter. I de flesta redundansväxlingar samordnar de primära noderna och repliknoderna överlämningen så att du har nästan noll tid utan primär.
Den tidigare primära går offline en kort stund för att ta emot uppdateringar från den nya primära. Sedan kommer repliken nu tillbaka online och återansluter 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:
- Primära noder och repliknoder förhandlar om en samordnad redundans och handelsroller.
- Repliken (tidigare primär) går offline för en omstart.
- Några sekunder eller minuter senare är repliken online igen.
- 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. Redundans och korrigering för Azure Managed Redis ger en detaljerad förklaring av typer av redundans. En Azure Managed Redis genomgår många redundansväxlingar 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.
Zonredundans
Rekommenderas för: Hög tillgänglighet, haveriberedskap – intra region
Azure Managed Redis stöder zonredundant konfiguration som standard. En zonredundant cache placerar automatiskt sina noder över olika Azure-Tillgänglighetszoner i samma region. När en zon går ned är cachenoder i andra zoner tillgängliga för att cachen ska fungera som vanligt. Det eliminerar avbrott i datacenter eller tillgänglighetszoner som en felpunkt och ökar den övergripande tillgängligheten för cacheminnet.
Zon ned-upplevelse
När en datanod blir otillgänglig eller en nätverksdelning sker sker en redundansväxling som liknar den som beskrivs i Standard-replikering . Klustret använder en kvorumbaserad modell för att avgöra vilka kvarvarande noder som deltar i ett nytt kvorum. Den befordrar även replikpartitioner inom dessa noder till primärvärden efter behov.
Regional tillgänglighet
Zonredundanta cacheminnen är tillgängliga i följande regioner:
| Nord- och Sydamerika | Europa | Mellanöstern | Afrika | Asien och stillahavsområdet |
|---|---|---|---|---|
| Kanada, centrala* | Europa, norra | Australien, östra | ||
| USA, centrala* | Södra Storbritannien | Indien, centrala | ||
| East US | Europa, västra | Sydostasien | ||
| USA, östra 2 | Japan, östra* | |||
| USA, södra centrala | Asien, östra* | |||
| USA, västra 2 | ||||
| USA, västra 3 | ||||
| Brasilien, södra |
Bevarande
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å en hanterad disk som är ansluten direkt till cacheinstansen. Vid dataförlust återställs cachedata automatiskt med hjälp av ögonblicksbilden på den hanterade disken. Mer information finns i Konfigurera datapersistence för en Azure Managed Redis-instans.
Import/Export
Rekommenderas för: Haveriberedskap
Azure Managed Redis stöder alternativet att importera och exportera Redis Database-filer (RDB) för att tillhandahålla dataportabilitet. Det gör att du kan importera data till Azure Managed Redis eller exportera data från Azure Managed Redis med hjälp av en RDB-ögonblicksbild. RDB-ögonblicksbilden från en 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 Managed 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.
Aktiv geo-replikering
Rekommenderas för: Hög tillgänglighet, haveriberedskap – flera regioner
Geo-replikering är en mekanism för att länka Azure Managed Redis-instanser mellan flera Azure-regioner. Azure Managed Redis stöder en avancerad form av geo-replikering som kallas aktiv geo-replikering som erbjuder både högre tillgänglighet och haveriberedskap mellan regioner i flera regioner. Azure Managed Redis-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 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. Mer information finns i Konfigurera aktiv geo-replikering för Azure Managed 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 force-unlinking finns i Force-Unlink om det uppstår regionstopp.
Ta bort och återskapa cache
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, såvida du inte använder aktiv geo-replikering. Programkoden ska vara motståndskraftig mot dataförlust.
När den berörda regionen har återställts återställs din otillgängliga Azure Managed 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 Managed Redis-instanser till olika regioner.