Metodtips för hög tillgänglighet och haveriberedskap
Azure Managed Instance för Apache Cassandra är en fullständigt hanterad tjänst för rena Apache Cassandra-kluster med öppen källkod. Tjänsten tillåter också att konfigurationer åsidosätts, beroende på de specifika behoven för varje arbetsbelastning, vilket ger maximal flexibilitet och kontroll där det behövs.
Apache Cassandra är ett bra val för att skapa mycket motståndskraftiga program på grund av dess distribuerade natur och huvudlösa arkitektur – alla noder i databasen kan ge exakt samma funktioner som andra noder – vilket bidrar till Cassandras robusthet och motståndskraft. Den här artikeln innehåller tips om hur du optimerar hög tillgänglighet och hur du kan hantera haveriberedskap.
RPO och RTO
RPO (mål för återställningspunkt) och RTO (mål för återställningstid) kommer båda vanligtvis att vara låga (nära noll) för Apache Cassandra så länge du har:
- En distribution i flera regioner med replikering mellan regioner och en replikeringsfaktor på 3.
- Aktiverade tillgänglighetszoner (välj alternativ när du skapar ett kluster i portalen eller via Azure CLI).
- Konfigurerad redundans på programnivå med hjälp av en belastningsutjämningsprincip i klientdrivrutinen och/eller redundans på belastningsutjämningsnivå med traffic manager/Azure front door.
RTO ("hur länge du är nere i ett avbrott") kommer att vara lågt eftersom klustret kommer att vara motståndskraftigt i både zoner och regioner, och eftersom Apache Cassandra självt är ett mycket feltolerant, huvudlöst system (alla noder kan skriva) som standard. RPO ("hur mycket data kan du förlora i ett avbrott") kommer att vara lågt eftersom data synkroniseras mellan alla noder och datacenter, så dataförlust i ett avbrott skulle vara minimal.
Kommentar
Det är inte teoretiskt möjligt att uppnå både RTO=0 och RPO=0 per Cap Theorem. Du måste utvärdera avvägningen mellan konsekvens och tillgänglighet/optimala prestanda – detta ser olika ut för varje program. Om ditt program till exempel är läsintensivt kan det vara bättre att hantera ökad svarstid för skrivningar mellan regioner för att undvika dataförlust (vilket gynnar konsekvens). Om appplikeringen är skrivintensiv, och med en budget med korta svarstider, kan risken för att förlora några av de senaste skrivningar i ett större regionalt avbrott vara acceptabel (vilket gynnar tillgängligheten).
Tillgänglighetszoner
Cassandras huvudlösa arkitektur ger feltolerans från grunden och Azure Managed Instance för Apache Cassandra ger stöd för tillgänglighetszoner i valda regioner för att förbättra återhämtning på infrastrukturnivå. Med en replikeringsfaktor på 3 säkerställer tillgänglighetszonens stöd att varje replik finns i en annan tillgänglighetszon, vilket förhindrar att ett zonindelat avbrott påverkar din databas/ditt program. Vi rekommenderar att du aktiverar tillgänglighetszoner där det är möjligt.
Redundans för flera regioner
Cassandras arkitektur, tillsammans med stöd för Azure-tillgänglighetszoner, ger dig viss nivå av feltolerans och återhämtning. Det är dock viktigt att överväga effekten av regionala avbrott för dina program. Vi rekommenderar starkt att du distribuerar kluster för flera regioner för att skydda mot avbrott på regionnivå. Även om de är sällsynta är den potentiella effekten allvarlig.
För affärskontinuitet räcker det inte att bara göra databasen till flera regioner. Andra delar av programmet måste också distribueras på samma sätt, antingen genom att distribueras eller med lämpliga mekanismer för redundansväxling. Om dina användare är spridda över många geo-platser har en distribution av datacenter i flera regioner för databasen den extra fördelen med att minska svarstiden, eftersom alla noder i alla datacenter i klustret sedan kan hantera både läsningar och skrivningar från den region som ligger närmast dem. Men om programmet har konfigurerats för att vara "aktiv-aktiv" är det viktigt att överväga hur CAP-satsen gäller för konsekvensen i dina data mellan repliker (noder) och de kompromisser som krävs för att leverera hög tillgänglighet.
I CAP-sats är Cassandra som standard ett AP-databassystem (tillgängligt partitionstolerant) med mycket justerbar konsekvens. För de flesta användningsfall rekommenderar vi att du använder local_quorum för läsningar.
- I aktiv-passiv för skrivningar finns det en kompromiss mellan tillförlitlighet och prestanda: för tillförlitlighet rekommenderar vi QUORUM_EACH men för de flesta användare LOCAL_QUORUM eller KVORUM är en bra kompromiss. Observera dock att vid ett regionalt avbrott kan vissa skrivningar gå förlorade i LOCAL_QUORUM.
- Om ett program körs parallellt QUORUM_EACH skrivningar föredras i de flesta fall för att säkerställa konsekvens mellan de två datacenter.
- Om målet är att gynna konsekvens (lägre RPO) i stället för svarstid eller tillgänglighet (lägre RTO) bör detta återspeglas i konsekvensinställningarna och replikeringsfaktorn. Som tumregel ska antalet kvorumnoder som krävs för en läsning plus antalet kvorumnoder som krävs för en skrivning vara större än replikeringsfaktorn. Om du till exempel har en replikeringsfaktor på 3 och quorum_one på läsningar (en nod) bör du göra quorum_all på skrivningar (tre noder), så att summan av 4 är större än replikeringsfaktorn 3.
Kommentar
Kontrollplansoperatorn för Azure Managed Instance för Apache Cassandra distribueras endast i en enda region (den region som valdes när det första datacentret distribuerades). I det osannolika fallet av ett totalt regionstopp förbinder vi oss till en återställningstid på 3 timmar för redundansväxling av kontrollplanet till en annan region. Detta påverkar inte serviceavtalet för tillgänglighet för tjänsten eftersom datacenter fortfarande bör fortsätta att fungera. Under den här perioden kanske det dock inte går att göra ändringar i databaskonfigurationen från portalen eller resursproviderverktygen.
Replikering
Vi rekommenderar granskning keyspaces och deras replikeringsinställningar då och då för att säkerställa att den nödvändiga replikeringen mellan datacenter har konfigurerats. I de tidiga utvecklingsstadierna rekommenderar vi att du testar att allt fungerar som förväntat genom att göra enkla tester med hjälp cqlshav . Du kan till exempel infoga ett värde när du är ansluten till ett datacenter och läsa det från det andra.
När du konfigurerar ett andra datacenter där ett befintligt datacenter redan har data är det särskilt viktigt att fastställa att alla data har replikerats och att systemet är klart. Vi rekommenderar att du övervakar replikeringsstatusen via våra DBA-kommandon med nodetool netstats. En alternativ metod skulle vara att räkna raderna i varje tabell, men tänk på att med stordatastorlekar, på grund av Cassandras distribuerade karaktär, kan detta bara ge en grov uppskattning.
Balansera kostnaden för haveriberedskap
Om ditt program är "aktiv-passivt" rekommenderar vi fortfarande vanligtvis att du distribuerar samma kapacitet i varje region så att programmet kan redundansväxla direkt till ett datacenter med "frekvent vänteläge" i en sekundär region. Detta säkerställer ingen prestandaförsämring vid ett regionalt avbrott. De flesta Cassandra-klientdrivrutiner ger alternativ för att initiera redundans på programnivå. Som standard förutsätter de att regionalt avbrott innebär att programmet också är nere, i vilket fall redundansväxlingen ska ske på lastbalanserarens nivå.
Men för att minska kostnaden för att etablera ett andra datacenter kanske du föredrar att distribuera en mindre SKU och färre noder i den sekundära regionen. När ett avbrott inträffar blir det enklare att skala upp i Azure Managed Instance för Apache Cassandra genom nyckelfärdig vertikal och vågrät skalning. När dina program redundansväxlar till den sekundära regionen kan du skala ut och skala upp noderna i det sekundära datacentret manuellt. I det här fallet fungerar ditt sekundära datacenter som ett lågkostnadsvarmt vänteläge. Om du använder den här metoden måste du balanseras mot den tid som krävs för att återställa systemet till full kapacitet i händelse av ett avbrott. Det är viktigt att testa och öva på vad som händer när en region går förlorad.
Kommentar
Det går mycket snabbare att skala upp noder än att skala ut. Tänk på detta när du överväger balansen mellan lodrät och vågrät skala och antalet noder som ska distribueras i klustret.
Scheman för säkerhetskopiering
Säkerhetskopieringar sker automatiskt i Azure Managed Instance för Apache Cassandra, men du kan välja ditt eget schema för de dagliga säkerhetskopieringarna. Vi rekommenderar att du väljer tider med mindre belastning. Även om säkerhetskopior är konfigurerade för att endast använda inaktiv CPU kan de i vissa fall utlösa komprimering i Cassandra, vilket kan leda till en ökning av CPU-användningen. Komprimering kan ske när som helst med Cassandra och beror på arbetsbelastning och vald komprimeringsstrategi.
Viktigt!
Avsikten med säkerhetskopior är enbart att minimera oavsiktlig dataförlust eller skadade data. Vi rekommenderar inte säkerhetskopieringar som en strategi för haveriberedskap. Säkerhetskopior är inte geo-redundanta, och även om de vore det kan det ta mycket lång tid att återställa en databas från säkerhetskopior. Därför rekommenderar vi starkt distributioner i flera regioner, tillsammans med aktivering av tillgänglighetszoner där det är möjligt, för att minimera katastrofscenarier och för att kunna återställa effektivt från dem. Detta är särskilt viktigt i de sällsynta scenarier där den misslyckade regionen inte kan omfattas, där alla data kan gå förlorade utan replikering i flera regioner.
Nästa steg
I den här artikeln har vi lagt fram några metodtips för att skapa motståndskraftiga program med Cassandra.