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 také umožňuje přepsání konfigurací v závislosti na konkrétních potřebách jednotlivých úloh, což umožňuje maximální flexibilitu a kontrolu tam, kde je to potřeba.
Apache Cassandra je skvělou volbou pro vytváření vysoce odolných aplikací kvůli distribuované povaze a bezserverové architektuře – jakýkoli uzel v databázi může poskytovat přesně stejné funkce jako jakýkoli jiný uzel – přispívá k odolnosti a odolnosti Cassandry. Tento článek obsahuje tipy, jak optimalizovat vysokou dostupnost a jak přistupovat k zotavení po havárii.
RPO a RTO
Cíl bodu obnovení (cíl bodu obnovení) a RTO (cíl doby obnovení) budou obvykle nízké (téměř nula) pro Apache Cassandra, pokud máte:
- Nasazení ve více oblastech s replikací mezi oblastmi a faktorem replikace 3.
- Povolené zóny dostupnosti (výběr možnosti při vytváření clusteru na portálu nebo prostřednictvím Azure CLI)
- Nakonfigurované převzetí služeb při selhání na úrovni aplikace pomocí zásad vyrovnávání zatížení v klientském ovladači nebo převzetí služeb při selhání na úrovni vyrovnávání zatížení pomocí traffic manageru nebo služby Azure front door.
RTO ("jak dlouho dochází k výpadku") bude nízké, protože cluster bude odolný vůči zónám i oblastem a protože samotný Apache Cassandra je vysoce odolný proti chybám, ve výchozím nastavení může zapisovat bezserverový systém (všechny uzly můžou zapisovat). Cíl bodu obnovení ("kolik dat můžete ztratit v výpadku") bude nízký, protože data se budou synchronizovat mezi všemi uzly a datovými centry, takže ztráta dat v výpadku by byla minimální.
Poznámka:
Teoreticky není možné dosáhnout rto=0 i RPO=0 na cap theorem. Budete muset vyhodnotit kompromis mezi konzistencí a dostupností / optimálním výkonem – to bude vypadat jinak pro každou aplikaci. Pokud je například vaše aplikace silná pro čtení, může být lepší se vypořádat se zvýšenou latencí zápisů mezi oblastmi, aby nedošlo ke ztrátě dat (upřednostnění konzistence). Pokud je aplikace náročný na zápis a u rozpočtu na úzkou latenci, může být riziko ztráty některých nejnovějších zápisů v závažném regionálním výpadku přijatelné (upřednostnění dostupnosti).
Zóny dostupnosti
Architektura Cassandra bez masterless přináší odolnost proti chybám od základů a azure Managed Instance for Apache Cassandra poskytuje podporu zón dostupnosti ve vybraných oblastech, aby se zvýšila odolnost na úrovni infrastruktury. Vzhledem k faktoru replikace 3 zajišťuje podpora zóny dostupnosti, že každá replika je v jiné zóně dostupnosti, čímž brání výpadku zónového výpadku, aby ovlivnila 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 určitou úroveň odolnosti proti chybám a odolnosti. Je ale důležité zvážit dopad regionálních výpadků pro vaše aplikace. Důrazně doporučujeme nasadit clustery s více oblastmi , které chrání před výpadky na úrovni oblastí. I když jsou vzácné, potenciální dopad je závažný.
V případě provozní kontinuity nestačí, aby databáze byla pouze ve více oblastech. Další části aplikace musí být také nasazeny stejným způsobem, a to buď tím, že se distribuují, nebo s odpovídajícími mechanismy pro převzetí služeb při selhání. Pokud jsou vaši uživatelé rozloženi do mnoha geografických umístění, nasazení datového centra pro více oblastí pro vaši databázi má přidanou výhodu snížení latence, protože všechny uzly ve všech datových centrech v clusteru pak můžou obsluhovat čtení i zápisy z oblasti, která je k nim nejblíže. Pokud je ale aplikace nakonfigurovaná tak, aby byla aktivní–aktivní, je důležité zvážit, jak se věta CAP vztahuje na konzistenci vašich dat mezi replikami (uzly) a kompromisy vyžadované k zajištění vysoké dostupnosti.
V teorémech CAP je Cassandra ve výchozím nastavení databázový systém AP (dostupný odolný proti oddílům) s vysoce vyladěnou konzistencí. Ve většině případů použití doporučujeme pro čtení používat local_quorum.
- V aktivním-pasivním zápisu 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. Všimněte si však, že v případě regionálního výpadku může dojít ke ztrátě některých zápisů v LOCAL_QUORUM.
- V případě paralelního spouštění aplikace QUORUM_EACH zápisy se ve většině případů preferují, aby byla zajištěna konzistence mezi dvěma datovými centry.
- Pokud vaším cílem je upřednostňovat konzistenci (nižší cíl bodu obnovení) místo latence nebo dostupnosti (nižší RTO), mělo by se to projevit v nastavení konzistence a faktoru replikace. 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 se nasadí jenom v jedné oblasti (oblast vybraná při počátečním nasazení prvního datového centra). 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. To nemá vliv na smlouvu SLA o dostupnosti pro službu, protože datacentra by stále měla fungovat. Během této doby však nemusí být možné provádět změny konfigurace databáze z portálu nebo nástrojů poskytovatele prostředků.
Replikace
Doporučujeme auditovat keyspaces a jejich nastavení replikace od času, abyste měli jistotu, že je požadovaná replikace mezi datovými centry nakonfigurovaná. V počátečních fázích vývoje doporučujeme otestovat, aby vše fungovalo podle očekávání pomocí jednoduchých testů pomocí cqlsh. Například vložení hodnoty při připojení k jednomu datovému centru a jeho čtení z druhého.
Zejména při nastavování druhého datového centra, kde už má existující datové centrum data, je důležité určit, že se všechna data replikovala a systém je připravený. Doporučujeme monitorovat průběh replikace pomocí příkazů DBA pomocí nodetool netstatspříkazu . Alternativním přístupem by bylo spočítat řádky v každé tabulce, ale mějte na paměti, že vzhledem k distribuované povaze Cassandry to může 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, aby vaše aplikace při selhání okamžitě převzala datové centrum "aktivní pohotovostní" v sekundární oblasti. Tím se zajistí žádné snížení výkonu v případě regionálního výpadku. 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í regionální výpadek znamená, že aplikace je také mimo provoz, v takovém případě by mělo dojít k převzetí služeb při selhání na úrovni nástroje pro vyrovnávání zatížení.
Pokud ale chcete snížit náklady na zřízení druhého datového centra, můžete v sekundární oblasti raději nasadit menší skladovou položku a méně uzlů. Když dojde k výpadku, vertikálním a horizontálním škálováním se ve službě Azure Managed Instance pro Apache Cassandra zjednoduší vertikální a horizontální škálování. Zatímco vaše aplikace při selhání do sekundární oblasti, můžete ručně škálovat a vertikálně navýšit kapacitu uzlů v sekundárním datovém centru. V takovém případě vaše sekundární datové centrum funguje jako úsporný pohotovostní režim s nižšími náklady. Tento přístup je potřeba vyvážit s časem potřebným k obnovení systému do plné kapacity v případě výpadku. Je důležité otestovat a vyzkoušet, co se stane, když dojde ke ztrátě oblasti.
Poznámka:
Vertikální navýšení kapacity uzlů je mnohem rychlejší než horizontální navýšení kapacity. Při zvažování rovnováhy mezi vertikálním a horizontálním škálováním a počtem uzlů, které se mají nasadit v clusteru, mějte na paměti.
Plány zálohování
Zálohy jsou ve službě Azure Managed Instance for Apache Cassandra automatické, ale 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 Cassandra provádět kdykoli a 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í a i když tomu tak bylo, obnovení databáze ze záloh může trvat velmi dlouhou dobu. Proto důrazně doporučujeme nasazení ve více oblastech ve spojení s povolením zón dostupnosti, pokud je to možné, zmírnit scénáře havárie a efektivně se z nich zotavit. To je zvlášť důležité ve výjimečných scénářích, kdy se neúspěšná oblast nedá pokrýt, kde bez replikace ve více oblastech může dojít ke ztrátě všech dat.
Další kroky
V tomto článku jsme si ukázali některé osvědčené postupy pro vytváření odolných aplikací pomocí Cassandry.