Osvědčené postupy pro vysokou dostupnost a zotavení po havárii

Azure Managed Instance for Apache Cassandra je plně spravovaná služba pro čistě opensourcové clustery Apache Cassandra. Služba umožňuje přepsání konfigurací v závislosti na potřebách jednotlivých úloh, což umožňuje maximální flexibilitu a kontrolu v případě potřeby.

Apache Cassandra je skvělou volbou pro vytváření vysoce odolných aplikací kvůli své distribuované povaze a architektuře peer-to-peer. Jakýkoli uzel v databázi může poskytovat stejné funkce jako jakýkoli jiný uzel. Tento návrh přispívá k robustnosti a odolnosti Cassandry. Tento článek obsahuje tipy, jak optimalizovat vysokou dostupnost a jak přistupovat k zotavení po havárii.

Cíl bodu obnovení a cíl doby obnovení

Pokud máte následující prvky, cíl bodu obnovení (RPO) a cíl doby obnovení (RTO) jsou obvykle nízké, blízko nuly:

• Nasazení více oblastí s replikací mezi oblastmi a faktorem replikace 3.
• Povolené zóny dostupnosti Tuto možnost nakonfigurujte při vytváření clusteru na webu Azure Portal nebo pomocí Azure CLI.
• Nakonfigurované přepnutí při selhání na úrovni aplikace pomocí zásad vyrovnávání zatížení v klientském ovladači, nebo přepnutí při selhání na úrovni vyrovnávání zatížení pomocí Azure Traffic Manageru nebo Azure Front Door.

RTO je délka, po kterou jste ve výpadku. Je nízká, protože cluster je odolný vůči zónám i oblastem. Apache Cassandra je také vysoce odolný systém peer-to-peer, ve kterém můžou všechny uzly zapisovat ve výchozím nastavení.

RPO je , kolik dat můžete při výpadku ztratit. Je nízká, protože data se synchronizují mezi všemi uzly a datovými centry. Ztráta dat v výpadku by byla minimální.

Poznámka:

Není možné dosáhnout RTO=0 i RPO=0 podle CAP teorém. Vyhodnoťte kompromis mezi konzistencí a dostupností nebo optimálním výkonem.

Tento zůstatek pro každou aplikaci vypadá jinak. Pokud je například vaše aplikace orientovaná na čtení, může být lepší se vypořádat se zvýšenou latencí mezi regiony při zápisu, aby se zabránilo ztrátě dat, což podporuje konzistenci. Pokud je aplikace zaměřená na zápis a má přísné požadavky na nízkou latenci, může být riziko ztráty některých nejnovějších zápisů během rozsáhlého regionálního výpadku přijatelné, což dává přednost dostupnosti.

Zóny dostupnosti

Architektura typu peer-to-peer Cassandra přináší odolnost proti chybám přímo od základů. Azure Managed Instance for Apache Cassandra poskytuje podporu zón dostupnosti ve vybraných oblastech. Tato podpora zvyšuje odolnost na úrovni infrastruktury. Pro faktor replikace 3 zajišťuje podpora zóny dostupnosti, že každá replika je v jiné zóně dostupnosti. Tento přístup zabrání tomu, aby výpadek zóny ovlivnil vaši databázi nebo aplikaci. Pokud je to možné, doporučujeme povolit zóny dostupnosti.

Redundance ve více oblastech

Architektura Cassandra, která je spojená s podporou zón dostupnosti Azure, poskytuje úroveň odolnosti proti chybám a odolnosti. Zvažte také dopad regionálních výpadků pro vaše aplikace. Pokud chcete zajistit ochranu před výpadky na úrovni oblastí, důrazně doporučujeme nasadit clustery s více oblastmi. I když jsou vzácné, potenciální dopad je závažný.

Pro provozní kontinuitu nestačí použít databázi více oblastí. Další části vaší aplikace musí být také distribuovány, nebo vybaveny odpovídajícími mechanismy pro zajištění kontinuity. Pokud jsou vaši uživatelé rozloženi do mnoha geografických umístění, má nasazení datového centra více oblastí pro vaši databázi přidanou výhodu snížení latence. Všechny uzly ve všech datových centrech v clusteru můžou obsluhovat čtení i zápisy z oblasti, která je k nim nejblíže.

Pokud je aplikace nakonfigurovaná jako aktivní-aktivní, zvažte, jak se CAP teorém vztahuje na konzistenci vašich dat mezi replikami (uzly) a kompromisy potřebné k dosažení vysoké dostupnosti.

Podle teorému CAP je Cassandra v základním nastavení databázový systém dostupný a odolný proti oddílům (AP) s vysoce vyladitelnou konzistencí. Ve většině případů použití doporučujeme pro čtení používat LOCAL_QUORUM.

• V metodě aktivní-pasivní pro zápisy existuje kompromis mezi spolehlivostí a výkonem. Pro spolehlivost doporučujeme QUORUM_EACH, ale pro většinu uživatelů LOCAL_QUORUM nebo KVORA je dobrým kompromisem. Pokud dojde k výpadku oblasti, může dojít ke ztrátě některých zápisů v LOCAL_QUORUM.

• Pokud aplikace běží paralelně, doporučuje se ve většině případů upřednostnit zápisy QUORUM_EACH, aby byla zajištěna konzistence mezi dvěma datovými centry.

• Pokud je vaším cílem upřednostnit konzistenci nebo nižší RPO před latencí nebo dostupností, či nižším RTO, měly by vaše nastavení konzistence a faktor replikace tento cíl odrážet.

  Obecně platí, že počet uzlů kvora vyžadovaných pro čtení a počet uzlů kvora požadovaných pro zápis by měl být větší než faktor replikace. Pokud máte například faktor replikace 3 a quorum_one při čtení (jeden uzel), měli byste provést quorum_all u zápisů (tři uzly), aby celkový počet 4 byl větší než faktor replikace 3.

Poznámka:

Operátor řídicí roviny pro Azure Managed Instance for Apache Cassandra je nasazen pouze v jedné oblasti. Oblast je ta, která je vybraná, když nasadíte první datové centrum. V nepravděpodobném případě výpadku celkové oblasti potvrdíme 3hodinovou dobu obnovení pro převzetí služeb při selhání řídicí roviny do jiné oblasti.

Vzhledem k tomu, že datacentra by stále měla fungovat, nemá tento problém vliv na smlouvu SLA o dostupnosti pro službu. Během tohoto období nemusí být možné provádět změny konfigurace databáze z webu Azure Portal nebo nástrojů poskytovatele prostředků.

Replikace

Doporučujeme pravidelně auditovat keyspaces a jejich nastavení replikace, abyste měli jistotu, že požadovaná replikace mezi datovými centry je nakonfigurovaná. V počátečních fázích vývoje doporučujeme provádět jednoduché testy pomocí cqlsh. Například vložte hodnotu, která je připojená k jednomu datovému centru, a načtěte ji z druhého.

Konkrétně když nastavíte druhé datové centrum, kde již existující datové centrum obsahuje data, určete, že jste replikovali všechna data a že je systém připravený. Doporučujeme monitorovat průběh replikace pomocí příkazů DBA s nodetool netstats. Alternativním přístupem by bylo spočítat řádky v každé tabulce. Mějte na paměti, že u velkých objemů dat, vzhledem k distribuované povaze Cassandry, může tento přístup poskytnout pouze hrubý odhad.

Vyrovnávání nákladů na zotavení po havárii

Pokud je vaše aplikace aktivní-pasivní, obecně doporučujeme nasadit stejnou kapacitu v každé oblasti. Tento přístup pomáhá vaší aplikaci převzít služby při selhání okamžitě do aktivního záložního datového centra v sekundárním regionu. Pokud dojde k regionálnímu výpadku, tento přístup zajistí žádné snížení výkonu. Většina klientských ovladačů Cassandra poskytuje možnosti pro zahájení převzetí služeb při selhání na úrovni aplikace. Ve výchozím nastavení předpokládají, že regionální výpadek znamená, že aplikace je také mimo provoz, takže převzetí služeb při selhání by mělo proběhnout na úrovni vyrovnávače zatížení.

Pokud chcete snížit náklady na zřízení druhého datového centra, možná budete chtít nasadit menší skladovou položku a méně uzlů v sekundární oblasti. Když dojde k výpadku, vertikální a horizontální škálování na klíč usnadňuje škálování ve službě Azure Managed Instance for Apache Cassandra. Zatímco vaše aplikace přepínají v případě selhání do sekundární oblasti, můžete ručně škálovat horizontálně a škálovat vertikálně uzly v sekundárním datacentru. Sekundární datové centrum funguje jako cenově výhodná varianta pohotovostního režimu. Tento přístup je potřeba vyvážit s dobou potřebnou k obnovení systému do plné kapacity, pokud dojde k výpadku. Je důležité otestovat a vyzkoušet, co se stane, když dojde ke ztrátě oblasti.

Poznámka:

Škálování uzlů je mnohem rychlejší než škálování do šířky. Mějte toto na paměti při zvažování rovnováhy mezi vertikálním a horizontálním škálováním, stejně jako při zvažování počtu uzlů, které chcete nasadit v clustru.

Plány zálohování

Zálohy jsou ve službě Azure Managed Instance for Apache Cassandra automatické. Můžete si vybrat vlastní plán denních záloh. Doporučujeme zvolit časy s menším zatížením. I když jsou zálohy nakonfigurované tak, aby spotřebovávaly jen nečinné procesory, můžou za určitých okolností aktivovat komprimace v Cassandře, což může vést ke zvýšení využití procesoru. Komprimace se můžou s Cassandrou vyskytnout kdykoli. Závisí na úloze a zvolené strategii komprimace.

Důležité

Záměrem zálohování je čistě zmírnit náhodné ztráty dat nebo poškození dat. Jako strategii zotavení po havárii nedoporučujeme zálohování.

Zálohy nejsou geograficky redundantní. I když byly, obnovení databáze ze záloh může trvat dlouhou dobu. Proto důrazně doporučujeme nasazování do více regionů, ve spojení s povolením zónami dostupnosti, kde je to možné, abychom zmírnili důsledky scénářů katastrof a byli schopni se z nich efektivně zotavit. Tento přístup je zvlášť důležitý ve výjimečných scénářích, kdy se nepodařilo obnovit oblast, která selhala. Bez replikace ve více oblastech může dojít ke ztrátě všech dat.

Další krok

Vytvoření clusteru pomocí webu Azure Portal