Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
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 att konfigurationer åsidosätts, beroende på 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 peer-to-peer-arkitektur. Alla noder i databasen kan ge samma funktioner som andra noder. Den här designen 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.
Mål för återställningspunkt och mål för återställningstid
Så länge du har följande element är mål för återställningspunkt (RPO) och mål för återställningstid (RTO) vanligtvis låga, nära noll:
- En distribution i flera regioner med replikering mellan regioner och en replikeringsfaktor på 3.
- Aktiverade tillgänglighetszoner. Konfigurera det här alternativet när du skapar ett kluster i Azure-portalen eller med hjälp av Azure CLI.
- Konfigurerad redundans på programnivå med hjälp av en belastningsutjämningsprincip i klientdrivrutinen eller redundans på belastningsutjämningsnivå med hjälp av Azure Traffic Manager eller Azure Front Door.
RTO är hur länge du är nere under ett avbrott. Det är lågt eftersom klustret är motståndskraftigt i både zoner och regioner. Apache Cassandra är också ett mycket feltolerant peer-to-peer-system där alla noder kan skriva som standard.
RPO är hur mycket data du kan förlora i ett avbrott. Den är låg eftersom data synkroniseras mellan alla noder och datacenter. Dataförlust i ett avbrott skulle vara minimalt.
Kommentar
Det går inte att uppnå både RTO=0 och RPO=0 per CAP-sats. Utvärdera kompromissen mellan konsekvens och tillgänglighet eller optimala prestanda.
Det här saldot 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 programmet skrivs hårt med snäva svarstider kan risken för att förlora några av de senaste skrivningarna i ett större regionalt avbrott vara acceptabel, vilket gynnar tillgängligheten.
Tillgänglighetszoner
Cassandras peer-to-peer-arkitektur ger feltolerans från grunden. Azure Managed Instance för Apache Cassandra ger stöd för tillgänglighetszoner i valda regioner. Det här stödet förbättrar återhämtning på infrastrukturnivå. För replikeringsfaktorn 3 säkerställer tillgänglighetszonens stöd att varje replik finns i en annan tillgänglighetszon. Den här metoden förhindrar att ett zonindelad avbrott påverkar din databas eller 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 en nivå av feltolerans och återhämtning. Tänk också på effekten av regionala avbrott för dina program. För att skydda mot avbrott på regionnivå rekommenderar vi starkt att du distribuerar flera regionkluster. Även om de är sällsynta är den potentiella effekten allvarlig.
För affärskontinuitet räcker det inte att använda en databas med flera regioner. Andra delar av applikationen måste också distribueras med lämpliga mekanismer för failover. Om användarna är spridda över många geo-platser har en distribution av datacenter i flera regioner för databasen den extra fördelen att svarstiden minskar. Alla noder i alla datacenter i klustret kan hantera både läsningar och skrivningar från den region som ligger närmast dem.
Om programmet är konfigurerat att vara active-active bör du överväga hur CAP-teorem ska tillämpas på datakonsekvensen mellan repliker (noder) och de kompromisser som krävs för att leverera hög tillgänglighet.
I CAP-teoremtermer är Cassandra som standard ett Tillgänglig partitions-tolerant (AP) databassystem, med mycket justerbar konsistens. För de flesta användningsområden rekommenderar vi att du använder LOCAL_QUORUM för läsningar.
I ett aktiv-passivt system för dataskrivningar finns det en kompromiss mellan tillförlitlighet och prestanda. För tillförlitlighet rekommenderar vi QUORUM_EACH men för de flesta användare är LOCAL_QUORUM eller KVORUM en bra kompromiss. Om det uppstår ett regionalt avbrott kan vissa skrivningar gå förlorade i LOCAL_QUORUM.
Om ett program körs parallellt, bör du föredra att använda QUORUM_EACH-skrivningar i de flesta fall för att säkerställa konsekvens mellan de två datacentren.
Om ditt mål är att gynna konsekvens, eller lägre RPO i stället för svarstid eller tillgänglighet, eller lägre RTO, bör konsekvensinställningarna och replikeringsfaktorn återspegla det här målet.
I allmänhet bör 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. Regionen är den som valts när du distribuerar det första datacentret. 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.
Eftersom datacenter fortfarande bör fortsätta att fungera påverkar det här problemet inte tjänstens tillgänglighets-SLA . Under den här perioden kanske det inte går att göra ändringar i databaskonfigurationen från Azure-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 gör enkla tester med hjälp av cqlsh. Du kan till exempel infoga ett värde när du är ansluten till ett datacenter och läsa det från det andra.
Särskilt när du konfigurerar ett andra datacenter där ett befintligt datacenter redan har data ska du fastställa att du replikerade alla data och att systemet är klart. Vi rekommenderar att du övervakar replikeringsstatusen via våra DBA-kommandon med nodetool netstats. En alternativ metod är att räkna raderna i varje tabell. Tänk på att med stordatastorlekar kan den här metoden bara ge en ungefärlig uppskattning på grund av Cassandras distribuerade karaktär.
Balansera kostnaden för haveriberedskap
Om ditt program är aktivt-passivt rekommenderar vi fortfarande att du distribuerar samma kapacitet i varje region. Den här metoden hjälper ditt program att redundansväxla direkt till ett datacenter med frekvent vänteläge i en sekundär region. Om ett regionalt avbrott inträffar säkerställer den här metoden ingen prestandaförsämring. 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, så redundans bör ske på lastbalanserarens nivå.
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 gör nyckelfärdig vertikal och horisontell skalning det enklare att skala upp i Azure Managed Instance för Apache Cassandra. Medan dina program redundansväxlar till den sekundära regionen kan du skala ut och skala upp noderna i det sekundära datacentret manuellt. Ditt sekundära datacenter fungerar som ett lågkostnadsvarmt vänteläge. Den här metoden måste balanseras mot den tid som krävs för att återställa systemet till full kapacitet om ett avbrott inträffar. 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 tänker på 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. Du kan välja ett 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. De är beroende av arbetsbelastning och vald komprimeringsstrategi.
Viktigt!
Avsikten med säkerhetskopieringar ä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. Även om de var det kan det ta 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. Den här metoden är särskilt viktig i de sällsynta scenarier där den misslyckade regionen inte kan återställas. Utan replikering i flera regioner kan alla data gå förlorade.
