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 ook worden overschreven, afhankelijk van de specifieke behoeften van elke workload, waardoor de maximale flexibiliteit en controle waar nodig mogelijk zijn.
Apache Cassandra is een uitstekende keuze voor het bouwen van uiterst tolerante toepassingen vanwege de gedistribueerde aard en masterloze architectuur. Elk knooppunt in de database kan exact dezelfde functionaliteit bieden als elk ander knooppunt, wat bijdraagt aan de robuustheid en tolerantie van Cassandra. Dit artikel bevat tips voor het optimaliseren van hoge beschikbaarheid en het benaderen van herstel na noodgevallen.
RPO en RTO
RPO (herstelpuntdoelstelling) en RTO (beoogde hersteltijd) zijn doorgaans laag (dicht bij nul) voor Apache Cassandra zolang u het volgende hebt:
- Een implementatie met meerdere regio's met replicatie tussen regio's en een replicatiefactor van 3.
- Beschikbaarheidszones ingeschakeld (selecteer de optie bij het maken van een cluster in de portal of via Azure CLI).
- Failover op toepassingsniveau geconfigureerd met behulp van taakverdelingsbeleid in het clientstuurprogramma en/of failover op taakverdelingsniveau met traffic manager/Azure-front door.
RTO (hoe lang u niet in een storing zit) is laag omdat het cluster tolerant is voor zowel zones als regio's en omdat Apache Cassandra zelf standaard een zeer fouttolerant systeem is (alle knooppunten kunnen schrijven). RPO ('hoeveel gegevens kunnen er verloren gaan in een storing') is laag omdat gegevens worden gesynchroniseerd tussen alle knooppunten en datacenters, zodat gegevensverlies in een storing minimaal is.
Notitie
Het is niet theoretisch mogelijk om zowel RTO=0 als RPO=0 per Cap Theorrem te bereiken. U moet de afweging tussen consistentie en beschikbaarheid/optimale prestaties evalueren. Dit ziet er anders uit voor elke toepassing. Als uw toepassing bijvoorbeeld zwaar wordt gelezen, is het misschien beter om te kunnen omgaan met een verhoogde latentie van schrijfbewerkingen tussen regio's om gegevensverlies te voorkomen (voorkeur voor consistentie). Als de appplicatie zwaar schrijft en bij een krap latentiebudget, is het risico dat sommige van de meest recente schrijfbewerkingen in een grote regionale storing acceptabel zijn (gunstig voor beschikbaarheid).
Beschikbaarheidszones
De masterless architectuur van Cassandra brengt fouttolerantie vanaf de grond en Azure Managed Instance voor Apache Cassandra biedt ondersteuning voor beschikbaarheidszones in geselecteerde regio's om de tolerantie op infrastructuurniveau te verbeteren. Gezien een replicatiefactor van 3 zorgt ondersteuning voor beschikbaarheidszones ervoor dat elke replica zich in een andere beschikbaarheidszone bevindt, waardoor een zonegebonden storing geen invloed heeft op uw database/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 bepaald niveau van fouttolerantie en tolerantie. Het is echter belangrijk om rekening te houden met de impact van regionale storingen voor uw toepassingen. We raden u ten zeerste aan clusters met meerdere regio's te implementeren om te beschermen tegen storingen op regioniveau. Hoewel ze zeldzaam zijn, is de potentiële impact ernstig.
Voor bedrijfscontinuïteit is het niet voldoende om alleen de database in meerdere regio's te maken. Andere onderdelen van uw toepassing moeten ook op dezelfde manier worden geïmplementeerd door gedistribueerd te worden, of met adequate mechanismen om een failover uit te voeren. Als uw gebruikers verspreid zijn over veel geografische locaties, heeft een datacenterimplementatie voor meerdere regio's voor uw database het extra voordeel van het verminderen van latentie, omdat alle knooppunten in alle datacenters in het cluster vervolgens zowel lees- als schrijfbewerkingen kunnen leveren vanuit de regio die zich het dichtst bij hen bevindt. Als de toepassing echter is geconfigureerd als 'actief-actief', is het belangrijk om na te gaan hoe 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-theorremtermen is Cassandra standaard een AP-databasesysteem (Available Partition-tolerant) met zeer onopzettelijk consistentie. Voor de meeste gebruiksvoorbeelden raden we u aan om local_quorum te gebruiken voor leesbewerkingen.
- In actief-passief voor schrijfbewerkingen is er sprake van een compromis tussen betrouwbaarheid en prestaties: voor betrouwbaarheid raden we QUORUM_EACH aan, maar voor de meeste gebruikers LOCAL_QUORUM of QUORUM een goed compromis is. In het geval van een regionale storing kunnen sommige schrijfbewerkingen echter verloren gaan in LOCAL_QUORUM.
- In het geval van een toepassing die parallel wordt uitgevoerd QUORUM_EACH schrijfbewerkingen de voorkeur hebben voor de meeste gevallen om consistentie tussen de twee datacenters te garanderen.
- Als uw doel is om consistentie te bevorderen (lagere RPO) in plaats van latentie of beschikbaarheid (lagere RTO), moet dit worden weerspiegeld in uw consistentie-instellingen en replicatiefactor. Als vuistregel 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.
Notitie
De operator voor het besturingsvlak voor Azure Managed Instance voor Apache Cassandra wordt alleen geïmplementeerd in één regio (de regio die is geselecteerd bij de eerste implementatie van het eerste datacenter). In het onwaarschijnlijke geval van een storing in een totale regio wordt een hersteltijd van 3 uur doorgevoerd voor het uitvoeren van een failover van het besturingsvlak naar een andere regio. Dit heeft geen invloed op de SLA voor beschikbaarheid voor de service, omdat datacenters nog steeds blijven functioneren. Tijdens deze periode is het echter mogelijk om vanuit de portal- of resourceproviderhulpprogramma's geen wijzigingen aan te brengen in de databaseconfiguratie.
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 aan om te testen of alles werkt zoals verwacht door eenvoudige tests uit te voeren met behulp van cqlsh. U kunt bijvoorbeeld een waarde invoegen terwijl deze is verbonden met het ene datacenter en deze van het andere datacenter lezen.
Met name bij het instellen van een tweede datacenter waar een bestaand datacenter al gegevens bevat, is het belangrijk om te bepalen of alle gegevens zijn gerepliceerd en het systeem gereed is. We raden u aan de voortgang van de replicatie te controleren via onze DBA-opdrachten met nodetool netstats. Een alternatieve benadering is het tellen van de rijen in elke tabel, maar houd er rekening mee dat met big data-grootten, vanwege de gedistribueerde aard van Cassandra, dit alleen een ruwe schatting kan geven.
De kosten van herstel na noodgevallen in balans brengen
Als uw toepassing 'actief-passief' is, wordt u in het algemeen nog steeds aangeraden dezelfde capaciteit in elke regio te implementeren, zodat uw toepassing direct een failover kan uitvoeren naar een 'hot stand-by'-datacenter in een secundaire regio. Dit zorgt voor geen prestatievermindering in het geval van een regionale storing. 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, in welk geval failover moet plaatsvinden op het niveau van de load balancer.
Als u echter de kosten voor het inrichten van een tweede datacenter wilt verlagen, wilt u misschien liever een kleinere SKU en minder knooppunten implementeren in uw secundaire regio. Wanneer er een storing optreedt, wordt omhoog schalen in Azure Managed Instance voor Apache Cassandra eenvoudiger gemaakt door kant-en-klare verticale en horizontale schaalaanpassing. Terwijl uw toepassingen failover uitvoeren naar uw secundaire regio, kunt u de knooppunten in uw secundaire datacenter handmatig uitschalen en omhoog schalen. In dit geval fungeert uw secundaire datacenter als een goedkopere warme stand-by. Als u deze aanpak volgt, moet u rekening houden met de tijd die nodig is om uw systeem te herstellen naar volledige capaciteit in het geval van een storing. Het is belangrijk om te testen en te oefenen wat er gebeurt wanneer een regio verloren gaat.
Notitie
Het omhoog schalen van knooppunten is veel sneller dan uitschalen. Houd er rekening mee wanneer u rekening houdt met de balans tussen verticale en horizontale schaal en het aantal knooppunten dat in uw cluster moet worden geïmplementeerd.
Back-upschema's
Back-ups worden automatisch uitgevoerd in Azure Managed Instance voor Apache Cassandra, maar 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 en zijn afhankelijk van de workload en de gekozen compressiestrategie.
Belangrijk
Het doel van back-ups is uitsluitend om onbedoeld gegevensverlies of beschadiging van gegevens te beperken. Het wordt afgeraden om back-ups te maken als strategie voor herstel na noodgevallen. Back-ups zijn niet geografisch redundant en zelfs als dat zo is, kan het erg lang duren om een database te herstellen vanuit back-ups. Daarom raden we u ten zeerste aan om implementaties met meerdere regio's, in combinatie met het inschakelen van beschikbaarheidszones waar mogelijk, te beperken tegen noodscenario's en om effectief hiervan te kunnen herstellen. Dit is met name belangrijk in de zeldzame scenario's waarin de mislukte regio niet kan worden gedekt, waarbij zonder replicatie in meerdere regio's alle gegevens verloren kunnen gaan.
Volgende stappen
In dit artikel hebben we enkele aanbevolen procedures voor het bouwen van flexibele toepassingen met Cassandra beschreven.