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:
| Alternativ | Description | Tillgänglighet | Standard | Premium | Stora företag |
|---|---|---|---|---|---|
| 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,9 % i Premium; 99,99 % i Enterprise (se information) | - | ✔ | ✔ |
| Geo-replikering | Länkade cacheinstanser i två regioner, med användarkontrollerad redundans | Premium; Företag (se information) | - | Passiv | Aktiv |
| Import/Export | Ögonblicksbild från tidpunkt av data i cacheminnet. | 99,9 % (se information) | - | ✔ | ✔ |
| Uthållighet | Periodisk databesparing till lagringskonto. | 99,9 % (se information) | - | ✔ | Förhandsgranska |
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 checkar den in en ny nyckel och en nyckeluppdatering till det interna minnet och svarar omedelbart på klienten. Åtgärden vidarebefordras till repliken asynkront.
Kommentar
Normalt kommunicerar ett Azure Cache for Redis-klientprogram med den primära noden i en cache för alla läs- och skrivbegäranden. Vissa klienter kan konfigureras att läsa från repliknoden.
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 Cache for Redis ger en detaljerad förklaring av typer av redundansväxlingar. En Azure Cache for 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.
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 återhämtning eftersom du har noder som säkerhetskopierar den primära. Även med fler repliker kan en Azure Cache for Redis-instans fortfarande påverkas allvarligt av ett datacenter eller avbrott i tillgänglighetszonen. Du kan öka cachetillgängligheten genom att använda flera repliker med zonredundans.
Zonredundans
Tillämpliga nivåer: Premium, Enterprise, Enterprise Flash
Rekommenderas för: Hög tillgänglighet, haveriberedskap – intra region
Azure Cache for Redis stöder zonredundanta konfigurationer på Premium- och Enterprise-nivåerna. En zonredundant cache kan placera sina noder i olika Azure-Tillgänglighetszoner i samma region. Det eliminerar datacenter- eller AZ-avbrott som en enskild felpunkt och ökar den övergripande tillgängligheten för din cache. Mer information om hur du konfigurerar den finns i den här artikeln.
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 går ned är cachenoder i andra zoner tillgängliga för att cachen ska fungera som vanligt.
Azure Cache for Redis stöder zonredundanta konfigurationer på Premium- och Enterprise-nivåerna. 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 felpunkt och ökar den övergripande tillgängligheten för cacheminnet.
Premiumnivå
Följande diagram illustrerar zonredundant konfiguration för Premium-nivån:
Azure Cache for Redis distribuerar noder i en zonredundant cache på ett resursallokeringssätt över de valda Tillgänglighetszoner. 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 redundans. 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 svarstider för tur och retur-nätverk 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 ser till att de primära replikerna och replikerna för en partition aldrig är sorterade på samma datanod. Partitioner replikerar data asynkront från primärval till motsvarande repliker.
Zone Down Experience for Enterprise-nivå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. Den befordrar även replikpartitioner inom dessa noder till primärvärden efter behov.
Regional tillgänglighet
Zonredundanta Premium-nivåcacheminnen är tillgängliga i följande regioner:
| Nord- och Sydamerika | Europa | Mellanöstern | Afrika | Asien och stillahavsområdet |
|---|---|---|---|---|
| Brasilien, södra | Frankrike, centrala | Qatar, centrala | Sydafrika, norra | Australien, östra |
| Kanada, centrala | Tyskland, västra centrala | Indien, centrala | ||
| Central US | Europa, norra | Japan, östra | ||
| USA, östra | Norge, östra | Sydkorea, centrala | ||
| USA, östra 2 | Södra Storbritannien | Sydostasien | ||
| USA, södra centrala | Västeuropa | Asien, östra | ||
| US Gov, Virginia | Sverige, centrala | Norra Kina 3 | ||
| Västra USA 2 | Schweiz, norra | |||
| Västra USA 3 |
Zonredundanta Cacheminnen på Enterprise- och Enterprise Flash-nivå ä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 |
* Enterprise Flash-nivån är inte tillgänglig i den här regionen.
Omdistribution och migrering av tillgänglighetszon
För närvarande är det enda sättet att konvertera cacheminnet från en icke-AZ-konfiguration till en AZ-konfiguration att distribuera om cachen. Information om hur du distribuerar om din aktuella cache finns i Migrera en Azure Cache for Redis-instans till stöd för tillgänglighetszoner.
Bevarande
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.
Import/Export
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å eller flera Azure Cache for Redis-instanser, som vanligtvis omfattar två Azure-regioner. Geo-replikering är främst utformat för haveriberedskap mellan 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.
Mer information om hur du konfigurerar det finns i Konfigurera geo-replikering för Premium Azure Cache for 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 som erbjuder både högre tillgänglighet och haveriberedskap mellan regioner i 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. Mer information finns i 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 force-unlinking finns i Force-Unlink om det uppstår regionstopp.
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.