Ajánlott eljárások a magas rendelkezésre álláshoz és a vészhelyreállításhoz
Az Apache Cassandra Azure Managed Instance egy teljesen felügyelt szolgáltatás tiszta nyílt forráskódú Apache Cassandra-fürtökhöz. A szolgáltatás lehetővé teszi a konfigurációk felül bírálását is az egyes számítási feladatok adott igényeitől függően, ami maximális rugalmasságot és szabályozást tesz lehetővé, ahol szükséges.
Az Apache Cassandra kiváló választás az elosztott természet és a mester nélküli architektúra miatt rendkívül rugalmas alkalmazások létrehozásához – az adatbázis bármely csomópontja pontosan ugyanazt a funkciót biztosítja, mint bármely más csomópont – hozzájárulva a Cassandra robusztusságához és rugalmasságához. Ez a cikk tippeket nyújt a magas rendelkezésre állás optimalizálásához és a vészhelyreállítás megközelítéséhez.
RPO és RTO
Az RPO (helyreállítási pont célkitűzése) és az RTO (helyreállítási idő célkitűzése) általában alacsony (közel nulla) lesz az Apache Cassandra esetében, amennyiben van:
- Többrégiós üzembe helyezés régiók közötti replikációval és 3 replikációs tényezővel .
- Engedélyezett rendelkezésre állási zónák (a fürt portálon vagy az Azure CLI-n keresztül történő létrehozásakor válassza a lehetőséget).
- Alkalmazásszintű feladatátvétel konfigurálva az ügyfélillesztőben lévő terheléselosztási szabályzattal és/vagy terheléselosztási szintű feladatátvétellel a Traffic Manager/Azure bejárati ajtó használatával.
Az RTO (mennyi ideig áll le egy üzemkimaradás esetén) alacsony lesz, mert a fürt rugalmas lesz mind a zónákban, mind a régiókban, és mivel maga az Apache Cassandra egy rendkívül hibatűrő, mester nélküli rendszer (minden csomópont képes írni) alapértelmezés szerint. Az RPO (mennyi adat veszhet el egy kimaradás során) alacsony lesz, mivel az adatok szinkronizálva lesznek az összes csomópont és adatközpont között, így a kimaradásban az adatvesztés minimális lenne.
Feljegyzés
Elméletileg nem érhető el az RTO=0 és az RPO=0 cap tételenként. Értékelnie kell a konzisztencia és a rendelkezésre állás/optimális teljesítmény közötti kompromisszumot – ez minden alkalmazás esetében más lesz. Ha például az alkalmazás nagy olvasottságú, jobb lehet kezelni a régiók közötti írások megnövekedett késését az adatvesztés elkerülése érdekében (a konzisztencia előnyben részesítése érdekében). Ha az appplication írási nehéz, és szűk késésű költségvetés, annak kockázata, hogy elveszíti néhány legutóbbi írás egy nagy regionális kimaradás elfogadható (előnyben részesítve a rendelkezésre állást).
Rendelkezésreállási zónák
A Cassandra mester nélküli architektúrája az alapoktól kezdve biztosítja a hibatűrést, az Apache Cassandra-hoz készült Azure Managed Instance pedig támogatja a rendelkezésre állási zónákat a kiválasztott régiókban, hogy az infrastruktúra szintjén növelje a rugalmasságot. A 3-ás replikációs tényező miatt a rendelkezésre állási zóna támogatása biztosítja, hogy minden replika egy másik rendelkezésre állási zónában legyen, így megakadályozza, hogy egy zónakimaradás hatással legyen az adatbázisra/alkalmazásra. Javasoljuk, hogy ahol csak lehetséges, engedélyezze a rendelkezésre állási zónákat.
Többrégiós redundancia
A Cassandra architektúrája az Azure rendelkezésre állási zónák támogatásával együtt bizonyos szintű hibatűrést és rugalmasságot biztosít. Fontos azonban figyelembe venni, hogy milyen hatással van a regionális kimaradás az alkalmazásokra. Javasoljuk többrégiós fürtök üzembe helyezését a régiószintű kimaradások elleni védelem érdekében. Bár ritkák, a lehetséges hatás súlyos.
Az üzletmenet folytonosságához nem elegendő az adatbázis többrégióssá tétele. Az alkalmazás más részeit is ugyanúgy kell üzembe helyezni az elosztott vagy a feladatátvételhez szükséges megfelelő mechanizmusokkal. Ha a felhasználók számos földrajzi helyen vannak elosztva, az adatbázis többrégiós adatközpontjának üzembe helyezése további előnyöket biztosít a késés csökkentéséhez, mivel a fürt összes adatközpontjának összes csomópontja képes a hozzájuk legközelebbi régióból származó olvasási és írási műveleteket is kiszolgálni. Ha azonban az alkalmazás "aktív-aktív" állapotra van konfigurálva, fontos figyelembe venni, hogy a CAP-tétel hogyan vonatkozik az adatok replikák (csomópontok) közötti konzisztenciájára, valamint a magas rendelkezésre állás biztosításához szükséges kompromisszumokra.
A CAP-tétel szempontjából a Cassandra alapértelmezés szerint egy AP -adatbázisrendszer (elérhető partíciótűrő) adatbázisrendszer, amely rendkívül rugalmas konzisztenciával rendelkezik. A legtöbb használati esetben javasoljuk, hogy local_quorum használjon olvasáshoz.
- Az aktív-passzív írások esetében a megbízhatóság és a teljesítmény között kompromisszum áll fenn: a megbízhatóság érdekében javasoljuk QUORUM_EACH, de a legtöbb felhasználó számára a LOCAL_QUORUM vagy a KVÓRUM jó kompromisszum. Vegye figyelembe azonban, hogy regionális leállás esetén előfordulhat, hogy egyes írások elvesznek LOCAL_QUORUM.
- Ha egy alkalmazás párhuzamosan fut, QUORUM_EACH írás a legtöbb esetben előnyben részesíti a két adatközpont közötti konzisztenciát.
- Ha a cél a késés vagy a rendelkezésre állás (alacsonyabb RTO) helyett a konzisztencia (alacsonyabb RPO) előnyben részesítése, ennek tükröződnie kell a konzisztencia beállításaiban és a replikációs tényezőben. Ökölszabályként az olvasáshoz szükséges kvórumcsomópontok számának és az íráshoz szükséges kvórumcsomópontok számának nagyobbnak kell lennie, mint a replikációs tényező. Ha például 3 replikációs tényezővel rendelkezik, és quorum_one olvasásokon (egy csomóponton), akkor quorum_all kell írnia (három csomóponton), hogy a 4-es szám nagyobb legyen, mint a 3 replikációs tényező.
Feljegyzés
Az Apache Cassandra azure-beli felügyelt példányának vezérlősík-operátora csak egyetlen régióban lesz üzembe helyezve (az első adatközpont üzembe helyezésekor kiválasztott régióban). A régió teljes leállásának valószínűtlensége esetén 3 órás helyreállítási időt kötelezettséget vállalunk arra, hogy a vezérlősíkot egy másik régióba megyünk át. Ez nem befolyásolja a szolgáltatás rendelkezésre állási SLA-ját , mivel az adatközpontoknak továbbra is működnie kell. Ebben az időszakban azonban előfordulhat, hogy nem lehet módosítani az adatbázis konfigurációját a portálon vagy az erőforrás-szolgáltató eszközein.
Replikáció
Javasoljuk a naplózást keyspaces és azok replikációs beállításait időről időre annak biztosítása érdekében, hogy az adatközpontok közötti szükséges replikáció konfigurálva legyen. A fejlesztés korai szakaszában azt javasoljuk, hogy tesztelje, hogy minden a várt módon működik-e egyszerű tesztek használatával cqlsh. Például beszúrhat egy értéket, miközben az egyik adatközponthoz csatlakozik, és beolvassa a másikból.
Különösen akkor, ha egy második adatközpontot állít be, ahol egy meglévő adatközpont már rendelkezik adatokkal, fontos megállapítani, hogy az összes adat replikálva van, és a rendszer készen áll. Javasoljuk, hogy a DBA-parancsokkal monitorozza a replikáció előrehaladását nodetool netstats. Alternatív módszer lenne az egyes táblák sorainak megszámlálása, de ne feledje, hogy big data-méretek esetén a Cassandra elosztott jellege miatt ez csak hozzávetőleges becslést adhat.
A vészhelyreállítás költségeinek kiegyenlítése
Ha az alkalmazás "aktív-passzív", akkor is általában azt javasoljuk, hogy minden régióban ugyanazt a kapacitást telepítse, hogy az alkalmazás azonnal feladatátvételt hajthass végre egy másodlagos régióban lévő "gyakori rendelkezésre állású" adatközpontban. Ez regionális kimaradás esetén nem biztosítja a teljesítménycsökkenést. A Cassandra-ügyfélillesztők többsége lehetőséget biztosít az alkalmazásszintű feladatátvétel indítására. Alapértelmezés szerint azt feltételezik, hogy a regionális kimaradás azt jelenti, hogy az alkalmazás is leállt, ebben az esetben a feladatátvételnek a terheléselosztó szintjén kell történnie.
A második adatközpont kiépítésének költségeinek csökkentése érdekében azonban érdemes lehet kisebb termékváltozatot és kevesebb csomópontot üzembe helyezni a másodlagos régióban. Ha leállás történik, a vertikális felskálázás az Apache Cassandra Azure Managed Instance-példányában egyszerűbbé válik a kulcsrakész függőleges és vízszintes skálázással. Míg az alkalmazások feladatátvételt végeznek a másodlagos régióba, manuálisan méretezheti fel és skálázhatja fel a másodlagos adatközpont csomópontjait. Ebben az esetben a másodlagos adatközpont alacsonyabb költségű meleg készenléti állapotként működik. Ennek a megközelítésnek a figyelembe vételével ki kell egyensúlyozni a rendszer teljes kapacitásra való visszaállításához szükséges idővel, kimaradás esetén. Fontos tesztelni és gyakorolni, hogy mi történik, ha egy régió elveszik.
Feljegyzés
A csomópontok vertikális felskálázása sokkal gyorsabb, mint a horizontális felskálázás. Ezt tartsa szem előtt, amikor figyelembe veszi a függőleges és a vízszintes skálázás, valamint a fürtben üzembe helyezendő csomópontok számát.
Biztonsági mentés ütemezése
A biztonsági mentések az Apache Cassandra Azure Managed Instance-példányában automatikusak, de a napi biztonsági mentések ütemezését is választhatja. Javasoljuk, hogy kevesebb terheléssel válassza ki az időpontokat. Bár a biztonsági másolatok úgy vannak konfigurálva, hogy csak tétlen processzort használjanak, bizonyos körülmények között tömörítéseket aktiválhatnak a Cassandra-ban, ami a processzorhasználat növekedéséhez vezethet. A tömörítés bármikor megtörténhet a Cassandra használatával, és a számítási feladattól és a választott tömörítési stratégiától függ.
Fontos
A biztonsági mentés célja kizárólag a véletlen adatvesztés vagy az adatsérülések csökkentése. Nem javasoljuk a biztonsági mentéseket vészhelyreállítási stratégiaként. A biztonsági mentések nem georedundánsak, és még ha igen, akkor is nagyon hosszú időt vehet igénybe az adatbázisok helyreállítása a biztonsági másolatokból. Ezért határozottan javasoljuk a többrégiós üzemelő példányok használatát, valamint a rendelkezésre állási zónák lehetőség szerinti engedélyezését, a vészforgatókönyvek elleni védekezést és a hatékony helyreállítást. Ez különösen fontos azokban a ritka esetekben, amikor a meghiúsult régió nem fedezhető, ahol többrégiós replikáció nélkül az összes adat elveszhet.
Következő lépések
Ebben a cikkben bemutattunk néhány ajánlott eljárást a rugalmas alkalmazások Cassandra használatával történő létrehozásához.