Cassandra migratsioon Kubernetesesse: eripärad ja lahendused

Apache Cassandra and the need to operate it within a Kubernetes-based infrastructure is something we encounter regularly. In this article, we will share our vision of the necessary steps, criteria, and existing solutions (including an overview of operators) for migrating Cassandra to K8s.

“Who can manage a woman can also manage a state”

So, who is Cassandra? It is a distributed storage system designed to manage large volumes of data while providing high availability without a single point of failure. The project hardly needs a lengthy introduction, so I will only highlight the main features of Cassandra that will be relevant for this article:

• Cassandra is written in Java.
• The topology of Cassandra includes several levels:
  • Node — a single deployed instance of Cassandra;
  • Rack — a group of Cassandra instances unified by a criterion, located in the same data center;
  • Datacenter — a collection of all groups of Cassandra instances within a single data center;
  • Cluster — a collection of all data centers.
• To identify a node, Cassandra uses the IP address.
• For the speed of write and read operations, Cassandra stores part of the data in memory.

Now — to the actual potential move to Kubernetes.

Check-list for migration

When it comes to migrating Cassandra to Kubernetes, we hope that managing it will become easier with the move. What will be required for this, and what will assist in it?

1. Storage for data

As previously mentioned, part of the Cassandra data is stored in memory — in the Memtable. But there is also another part of the data that is saved to disk — in the form of SSTable. To this data, we add an entity called Commit Log — records of all transactions, which are also saved to disk.

Transaction schema for writing in Cassandra

In Kubernetes, we can use PersistentVolume for data storage. Thanks to well-established mechanisms, working with data in Kubernetes is becoming easier each year.

We will allocate a separate PersistentVolume for each pod with Cassandra.

Oluline on märkida, et Cassandra hõlmab iseenesest andmete replikatsiooni, pakkudes selleks sisseehitatud mehhanisme. Seega, kui kogute Cassandra klastrit suurest arvust sõlmedest, ei ole andmete salvestamiseks vaja kasutada jaotatud süsteeme nagu Ceph või GlusterFS. Sel juhul oleks mõistlik salvestada andmed sõlme kettale, kasutades kohalikke püsikettaid või mountimist hostPath.

Teine küsimus on, kui soovite luua igale feature-haru jaoks eraldi arendajate keskkonna. Sel juhul oleks õige lähenemine tõsta üles üks Cassandra sõlm ja hoida andmed jaotatud salves, st mainitud Ceph ja GlusterFS saavad teie valikuks. Siis on arendaja kindel, et ei kaota testandmeid isegi siis, kui üks Kuberntese klastri sõlm kaob.

2. Jälgimine

Peaaegu alternatiivideta valik Kuberneteses jälgimise elluviimiseks on Prometheus (oleme sellest põhjalikult rääkinud vastavas ettekandes). Kuidas on Cassandra-l asjadega, mis puudutavad Prometheusele mõeldud meetrika eksportijaid? Ja, mis on isegi tähtsam, sobivate dashboard'idega Grafana jaoks?

Grafana Cassandra jaoks graafikute väljanägemise näide

Eksportijaid on kokku kaks: jmx_exporter ja cassandra_exporter.

Oleme valinud enda jaoks esimese, kuna:

1. JMX Exporter kasvab ja areneb, samas kui Cassandra Exporter ei ole suutnud saada vajalikku kogukonna toetust. Cassandra Exporter ei toeta siiani enamiku Cassandra versioone.
2. Seda saab käivitada kui javaagent, lisades lipu -javaagent:<plugin-dir-name>\/cassandra-exporter.jar=--listen=:9180.
3. Selle jaoks on olemas adequate dashboard, mis ei ühildu Cassandra Exporter'iga.

3. Kubernetes'e primitiivide valik

Arvestades eeltoodud Cassandra klastristruktuuri, proovime tõlkida kõik, mis seal on, Kubernetes'e terminoloogiasse:

• Cassandra Node → Pod
• Cassandra Rack → StatefulSet
• Cassandra Datacenter → StatefulSets kogum
• Cassandra Cluster → ???

Tundub, et Cassandra klastrit juhtimiseks vajalik täiendav üksus on puudu. Kuid kui midagi puudub, saame selle luua! Kubernetes'es on selleks ette nähtud oma ressursside määratlemise mehhanism - Kohandatud Ressursi Määratlused.

Lisareursside kuulutamine logide ja teavituste jaoks

Kuid iseenesest ei tähenda Custom Resource midagi: vajalik on kontroller. Võib-olla tuleb kaasata Kubernetes'i operaator…

4. pod'ide identifitseerimine

Ülaltoodud punktis leppisime kokku, et üks Cassandra sõlm vastab ühele pod'ile Kubernetesis. Kuid pod'ide IP-aadressid on iga kord erinevad. Ja Cassandra sõlme tuvastamine toimub just IP-aadressi põhjal... Seega, pärast iga pod'i kustutamist lisab Cassandra klaster endasse uue sõlme.

Väljapääs on olemas, ja isegi mitte üks:

1. Saame arvestada hosti identifikaatorite (UUID-de, mis tuvastavad Cassandra eksemplare) või IP-aadresside järgi ja salvestada kõik see mingitesse struktuuridesse/tabelitesse. Meetodil on kaks peamist puudust:
   • Oht, et kahe sõlme allakukkumisel tekib konkurentsitingimus. Pärast taastumist hakkavad Cassandra sõlmed samaaegselt enda jaoks tabelist IP-aadressi küsima ja konkureerima sama ressursi üle.
   • Kui Cassandra sõlm on oma andmed kaotanud, ei saa me seda enam tuvastada.
2. Teine lahendus tundub olevat väike nipp, kuid siiski: saame luua iga Cassandra sõlme jaoks Service, millel on ClusterIP. Selle rakenduse probleemid:
   • Kui Cassandra klastris on palju sõlmi, peame looma väga palju Service'e.
   • ClusterIP funktsionaalsus on rakendatud iptables'i kaudu. See võib probleemiks saada, kui Cassandra klastris on palju (1000... või isegi 100?) sõlme. Kuigi IPVS-põhine tasakaalustamine suudab selle probleemi lahendada.
3. Kolmas lahendus on kasutada Cassandra sõlmede jaoks sõlmede võrku, mitte eraldiseisvat pod'ide võrku, lubades seadistuse hostNetwork: true. See meetod seab mõned piirangud:
   • Sõlmide asendamiseks. Uus sõlm peab kindlasti omama sama IP-aadressi, mis eelmine (pilvedes nagu AWS, GCP on seda peaaegu võimatu teha);
   • Klastri sõlmede võrgu kasutamisel hakkame konkurentsi pidama võrguressursside üle. Seega on ühe Cassandra klastris oleva sõlme jaoks rohkem kui ühe pod'i paigutamine problemaatiline.

5. Varundused

Tahame aeg-ajalt salvestada ühe Cassandra sõlme täisandmete versiooni. Kubernetes pakub mugavat võimalust, kasutades CronJob, kuid siin takistab meid ise Cassandra.

Mäletan, et osa andmeid salvestab Cassandra mällu. Täieliku varukoopia tegemiseks tuleb andmed mälust (Memtables) viia kettale (SSTables). Sel hetkel lakab Cassandra sõlm ühenduste vastu võtmast, sulgedes end täielikult klastri tööst.

Pärast seda tehakse varukoopia (snapshot) ja salvestatakse skeem (keyspace). Ja selgub, et lihtsalt varukoopia meile midagi ei anna: tuleb salvestada andmete identifikaatorid, mille eest vastutas Cassandra sõlm – need on spetsiaalsed tokenid.

Tokenite jaotamine andmete identifitseerimiseks, mille eest vastutavad Cassandra sõlmed

Näidis skriptist, mis teeb Cassandra varukoopia Google'i poolt Kuberneteses, leiate siit sellel lingil. Ainus moment, mida skript ei arvesta, on andmete lähtestamine sõlmes enne snapshot'i tegemist. See tähendab, et varukoopia tehakse mitte praegusest seisundist, vaid veidi varasemast. Kuid see aitab mitte viia sõlme välja tegevusest, mis tundub väga loogiline.

set -eu

if [[ -z "$1" ]]; then
  info "Palun esitage keyspace"
  exit 1
fi

KEYSPACE="$1"

result=$(nodetool snapshot "${KEYSPACE}")

if [[ $? -ne 0 ]]; then
  echo "Viga snapshot'i tegemisel"
  exit 1
fi

timestamp=$(echo "$result" | awk '\/Snapshot directory: \/ { print $3 }')

mkdir -p \/tmp\/backup

for path in $(find "\/var\/lib\/cassandra\/data\/${KEYSPACE}" -name $timestamp); do
  table=$(echo "${path}" | awk -F "[\/-]" '{print $7}')
  mkdir \/tmp\/backup\/$table
  mv $path \/tmp\/backup\/$table
done


tar -zcf \/tmp\/backup.tar.gz -C \/tmp\/backup .

nodetool clearsnapshot "${KEYSPACE}"

Näidis bash-skript, mis teeb varukoopia ühe Cassandra sõlme kohta

Valmis lahendused Cassandra jaoks Kuberneteses

Mida praegu üldse kasutatakse Cassandra käivitamiseks Kuberneteses ja mis neist sobib kõige paremini antud nõuete täitmiseks?

1. Lahendused StatefulSetide või Helm-kartide alusel

Kasutada StatefulSetide põhifunktsioone Cassandra klastrite käivitamiseks – hea variant. Helm-kardi ja Go mallide abil saab pakkuda kasutajale paindlikku liidese Cassandra käivitamiseks.

Tavaliselt töötab see normaalselt… kuni juhtub midagi ootamatut – näiteks sõlme rike. Kubernetes'e standardvahendid ei suuda lihtsalt arvestada kõiki ülaltoodud omadusi. Lisaks on see lähenemine väga piiratud, kui tuleb arvestada keerulisemate kasutusjuhtumitega: sõlmede asendamine, varukoopiad, taastamine, jälgimine jne.

Esindajad:

• Helmi põhiraamatukogust pärit chart;
• Bitnami chart.

Mõlemad chart'id on sama head, kuid nad on siiski vastuvõtlikud ülaltoodud probleemidele.

2. Kubernetes Operator'i alusel põhinevad lahendused

Sellised valikud on huvitavamad, kuna nad pakuvad laia valikut võimalusi klastriga haldamiseks. Cassandra operaatori kujundamisel, nagu iga teise andmebaasi puhul, näeb hea mustrina välja Sidecar Controller CRD:

Cassandra õigesti kavandatud operaatori sõlmede haldamise skeem

Uurime olemasolevaid operaatorite lahendusi.

1. Cassandra-operator Instaclustr'i poolt

• GitHub
• Valmidus: Alfa
• Litsents: Apache 2.0
• Rakendatud: Java

See on tõeliselt paljutõotav ja aktiivselt arenev projekt ettevõttelt, mis pakub hallatavaid Cassandra juurutusi. Nagu eespool mainitud, kasutab see sidecar konteinerit, mis võtab käske vastu HTTP kaudu. Kirjutatud Java's, seega mõnikord jääb tal puudu klient-go teegi täiendavast funktsionaalsusest. Samuti ei toeta operaator erinevaid racks'e ühe datakeskuse jaoks.

Kuid operaatoril on sellised eelised nagu toetatud monitooring, kõrgetasemeline klastrihaldus CRD abil ja isegi dokumentatsioon varukoopiate tegemiseks.

2. Navigator Jetstack'i poolt

• GitHub
• Valmidus: Alfa
• Litsents: Apache 2.0
• Rakendatud: Golang

Operaatore, mis on mõeldud DB-as-a-Service'i juurutamiseks. Praegu toetab see kahte andmebaasi: Elasticsearch ja Cassandra. Sellel on sellised huvitavad lahendused nagu juurdepääsu kontroll andmebaasile RBAC kaudu (selleks tõuseb omaette navigator-apiserver). Huvitav projekt, millele tasuks tähelepanu pöörata, kuigi viimane commit tehti poolteist aastat tagasi, mis vähendab selgelt selle potentsiaali.

3. Cassandra-operator vgkowski poolt

• GitHub
• Valmidus: Alfa
• Litsents: Apache 2.0
• Rakendatud: Golang

Ei hakanud seda 'tõsiselt' võtma, kuna viimane commit reposse oli rohkem kui aasta tagasi. Operaatori arendamine on unarusse jäetud: viimane Kubernetes'i versioon, mida väidetakse toetavat, on 1.9.

4. Cassandra-operator Rook'i poolt

• GitHub
• Valmidus: Alfa
• Litsents: Apache 2.0
• Rakendatud: Golang

Operaator, mille areng ei edene nii kiiresti, kui sooviksime. Tal on läbi mõeldud CRD struktuur klastrihalduseks, lahendab sõlmede tuvastamise probleemi ClusterIP teenuse kaudu (see sama 'nipp')... kuid hetkel on see kõik. Monitooringut ja varukoopiaid pole lahti keeratud (ühe sõnaga, monitooringuga võtsime meie ise käsile). Huvitav punkt on see, et selle operaatori abil on võimalik üles seada ka ScyllaDB.

NB: Seda operaatorit oleme me väikeste muudatustega kasutanud ühes meie projektis. Operaatori kasutamise ajal (~4 kuud) ei ole probleeme täheldatud.

5. CassKop Orange'i poolt

• GitHub
• Valmidus: Alfa
• Litsents: Apache 2.0
• Rakendatud: Golang

Noorim operaator nimekirjas: esimene commit tehti 23. mai 2019. Praeguseks on tal juba suur hulk omadusi meie nimekirjast, millega saab lähemalt tutvuda projekti repozitooriumis. Operaator on loodud populaarse operator-sdk baasil. Toetab 'välja kastist' monitooringut. Peamine erinevus teiste operaatorite seas on selle kasutamine. CassKop plugina, mis on rakendatud Pythonis ja kasutatakse kommunikatsiooniks Cassandra sõlmede vahel.

Järeldused

Cassandra üleviimise lähenemisviiside ja võimalike variantide arv Kubernetesesse räägib enda eest: teema on väga nõutud.

Praegusel hetkel võib katsetada midagi ülaltoodust omal riskil: ükski arendaja ei garanteeri oma lahenduse 100%-list toimimist tootmiskeskkonnas. Siiski, paljud tooted näevad juba praegu lubavad välja, et neid saab proovida arendustegevuse keskkondades.

Ma arvan, et tulevikus see naine laeva peal osutub vajalikuks!

P.S.

Lugege ka meie blogist:

• «Aeganõudev MongoDB migreerimine Kubernetesesse»;
• «Kompleksne RabbitMQ migratsioon Kubernetesesse»;
• «Andmebaasid ja Kubernetes (ülevaade ja video ettekandest)»;
• «K8s näpunäited ja nipid: Suurendame suurte andmebaaside bootstrap'i kiirus.».

Allikas: habr.com