Aanbevolen procedures voor hoge beschikbaarheid en herstel na noodgevallen

Azure Managed Instance voor Apache Cassandra is een volledig beheerde service voor pure opensource Apache Cassandra-clusters. Met de service kunnen configuraties worden overschreven, afhankelijk van de behoeften van elke workload, waardoor maximale flexibiliteit en controle waar nodig mogelijk zijn.

Apache Cassandra is een uitstekende keuze voor het bouwen van zeer tolerante toepassingen vanwege de gedistribueerde aard en peer-to-peer-architectuur. Elk knooppunt in de database kan dezelfde functionaliteit bieden als elk ander knooppunt. Dit ontwerp draagt bij aan de robuustheid en tolerantie van Cassandra. Dit artikel bevat tips voor het optimaliseren van hoge beschikbaarheid en het benaderen van herstel na noodgevallen.

Beoogde herstelpunt en beoogde hersteltijd

Zolang u de volgende elementen hebt, zijn RPO (Recovery Point Objective) en RTO (Recovery Time Objective) meestal laag, dicht bij nul:

• Een implementatie van meerdere regio's met replicatie tussen regio's en een replicatiefactor van 3.
• Beschikbaarheidszones ingeschakeld. Configureer deze optie wanneer u een cluster maakt in Azure Portal of met behulp van Azure CLI.
• Failover op toepassingsniveau geconfigureerd met behulp van taakverdelingsbeleid in het clientstuurprogramma of failover op taakverdelingsniveau met behulp van Azure Traffic Manager of Azure Front Door.

RTO is hoe lang u buitendienst bent tijdens een storing. Het is laag omdat het cluster tolerant is voor zowel zones als regio's. Apache Cassandra zelf is ook een zeer fouttolerant peer-to-peer-systeem, waarbij alle knooppunten standaard kunnen schrijven.

RPO is hoeveel gegevens u kwijtraakt in een storing. Het is laag omdat gegevens worden gesynchroniseerd tussen alle knooppunten en datacenters. Gegevensverlies in een storing is minimaal.

Beschikbaarheidszones

De peer-to-peer-architectuur van Cassandra brengt fouttolerantie vanaf de basis. Azure Managed Instance voor Apache Cassandra biedt ondersteuning voor beschikbaarheidszones in geselecteerde regio's. Deze ondersteuning verbetert de tolerantie op infrastructuurniveau. Voor een replicatiefactor van 3 zorgt ondersteuning voor beschikbaarheidszones ervoor dat elke replica zich in een andere beschikbaarheidszone bevindt. Deze aanpak voorkomt dat een zonegebonden storing van invloed is op uw database of toepassing. We raden u aan waar mogelijk beschikbaarheidszones in te schakelen.

Redundantie in meerdere regio's

De architectuur van Cassandra, in combinatie met ondersteuning voor Azure-beschikbaarheidszones, biedt u een niveau van fouttolerantie en tolerantie. Houd ook rekening met de impact van regionale storingen voor uw toepassingen. Ter bescherming tegen storingen op regioniveau raden we u ten zeerste aan om meerdere regioclusters te implementeren. Hoewel ze zeldzaam zijn, is de potentiële impact ernstig.

Voor bedrijfscontinuïteit is het niet voldoende om een database met meerdere regio's te gebruiken. Andere onderdelen van uw toepassing moeten ook worden gedistribueerd en beschikken over voldoende mechanismen voor failover. Als uw gebruikers zijn verspreid over veel geografische locaties, heeft een implementatie van een datacenter in meerdere regio's voor uw database het extra voordeel dat de latentie wordt verminderd. Alle knooppunten in alle datacenters in het cluster kunnen zowel lees- als schrijfbewerkingen verwerken vanuit de regio die zich het dichtst bij hen bevindt.

Als de toepassing is geconfigureerd om actief-actief te zijn, kunt u overwegen hoe het CAP-theorema van toepassing is op de consistentie van uw gegevens tussen replica's (knooppunten) en de afwegingen die nodig zijn om hoge beschikbaarheid te leveren.

In CAP-theorema termen is Cassandra standaard een beschikbaar en partitietolerant (AP) databasesysteem, met zeer afstembare consistentie. Voor de meeste gebruiksvoorbeelden raden we u aan om LOCAL_QUORUM te gebruiken voor leesbewerkingen.

• In actief-passief voor schrijfbewerkingen is er een afweging tussen betrouwbaarheid en prestaties. Voor betrouwbaarheid raden we QUORUM_EACH aan, maar voor de meeste gebruikers LOCAL_QUORUM of QUORUM een goed compromis is. Als er sprake is van een regionale storing, kunnen enkele schrijfbewerkingen verloren gaan in LOCAL_QUORUM.

• Als een toepassing parallel wordt uitgevoerd, geeft u bij voorkeur de voorkeur aan QUORUM_EACH schrijfbewerkingen in de meeste gevallen om consistentie tussen de twee datacenters te garanderen.

• Als uw doel is om consistentie te bevorderen, of een lagere RPO, in plaats van latentie of beschikbaarheid, of een lagere RTO, moet uw consistentie-instellingen en replicatiefactor dit doel weerspiegelen.

  Over het algemeen moet het aantal quorumknooppunten dat is vereist voor een leesbewerking plus het aantal quorumknooppunten dat is vereist voor een schrijfbewerking groter zijn dan de replicatiefactor. Als u bijvoorbeeld een replicatiefactor van 3 hebt en quorum_one op leesbewerkingen (één knooppunt), moet u quorum_all uitvoeren op schrijfbewerkingen (drie knooppunten), zodat het totaal van 4 groter is dan de replicatiefactor van 3.

Replicatie

We raden u aan om de replicatie-instellingen van tijd tot tijd te controleren keyspaces om ervoor te zorgen dat de vereiste replicatie tussen datacenters is geconfigureerd. In de vroege ontwikkelingsfasen raden we u aan eenvoudige tests uit te voeren met behulp van cqlsh. Voeg bijvoorbeeld een waarde in terwijl deze is verbonden met het ene datacenter en lees deze van het andere.

Wanneer u een tweede datacenter instelt waarin een bestaand datacenter al gegevens bevat, moet u bepalen of u alle gegevens hebt gerepliceerd en of het systeem gereed is. We raden u aan om de voortgang van de replicatie te bewaken via onze DBA-opdrachten met nodetool netstats. Een alternatieve benadering is het tellen van de rijen in elke tabel. Houd er rekening mee dat met big data-grootten, vanwege de gedistribueerde aard van Cassandra, deze benadering slechts een ruwe schatting kan geven.

De kosten van herstel na noodgevallen in balans brengen

Als uw toepassing actief-passief is, raden we u nog steeds aan dezelfde capaciteit in elke regio te implementeren. Deze aanpak helpt uw toepassing om direct een failover uit te geven naar een hot standby-datacenter in een secundaire regio. Als er een regionale storing optreedt, zorgt deze aanpak ervoor dat er geen prestatievermindering plaatsvindt. De meeste Cassandra-clientstuurprogramma's bieden opties voor het initiëren van failover op toepassingsniveau. Standaard gaan ze ervan uit dat regionale storingen betekenen dat de toepassing ook offline is, dus failover moet plaatsvinden op het niveau van de load balancer.

Als u de kosten voor het inrichten van een tweede datacenter wilt verlagen, wilt u misschien liever een kleinere SKU en minder knooppunten in uw secundaire regio implementeren. Wanneer er een storing optreedt, dan maakt kant-en-klare verticale en horizontale opschaling het opschalen eenvoudiger in de omgeving van Azure Managed Instance voor Apache Cassandra. Terwijl uw toepassingen een failover naar uw secundaire regio uitvoeren, kunt u de knooppunten in uw secundaire datacenter handmatig uitschalen en omhoog schalen . Uw secundaire datacentrum fungeert als een goedkopere warme back-up. Als u deze aanpak uitvoert, moet u rekening houden met de tijd die nodig is om uw systeem te herstellen naar volledige capaciteit als er een storing optreedt. Het is belangrijk om te testen en te oefenen wat er gebeurt wanneer een regio verloren gaat.

Back-upschema's

Back-ups worden automatisch uitgevoerd in Azure Managed Instance voor Apache Cassandra. U kunt uw eigen planning kiezen voor de dagelijkse back-ups. We raden u aan tijden te kiezen met minder belasting. Hoewel back-ups zijn geconfigureerd om alleen niet-actieve CPU te verbruiken, kunnen ze in sommige gevallen compressies activeren in Cassandra, wat kan leiden tot een toename van het CPU-gebruik. Compressies kunnen op elk gewenst moment plaatsvinden met Cassandra. Ze zijn afhankelijk van de workload en de gekozen compressiestrategie.

Volgende stap