Cassandra migratsioon Kubernetesesse: funktsioonid ja lahendused

Me puutume regulaarselt kokku Apache Cassandra andmebaasiga ja vajadusega kasutada seda Kubernetese-põhises infrastruktuuris. Selles materjalis jagame oma nägemust vajalikest sammudest, kriteeriumidest ja olemasolevatest lahendustest (sh ülevaade operaatoritest) Cassandra K8-dele migreerimiseks.

"Kes suudab valitseda naist, võib valitseda ka riiki"

Kes on Cassandra? See on hajutatud salvestussüsteem, mis on loodud suurte andmemahtude haldamiseks, tagades samal ajal kõrge kättesaadavuse ilma ühegi tõrkepunktita. Projekt ei vaja vaevalt pikka tutvustamist, seega annan ainult Cassandra peamised omadused, mis on konkreetse artikli kontekstis asjakohased:

• Cassandra on kirjutatud Java keeles.
• Cassandra topoloogia sisaldab mitut taset:
  • Sõlm – üks juurutatud Cassandra eksemplar;
  • Rack on Cassandra eksemplaride rühm, mida ühendavad mõned omadused ja mis asuvad samas andmekeskuses;
  • Andmekeskus – Cassandra eksemplaride kõigi rühmade kogum, mis asuvad ühes andmekeskuses;
  • Klaster on kõigi andmekeskuste kogum.
• Cassandra kasutab sõlme tuvastamiseks IP-aadressi.
• Kirjutamis- ja lugemistoimingute kiirendamiseks salvestab Cassandra osa andmetest RAM-i.

Nüüd – tegeliku potentsiaalse kolimise juurde Kubernetesesse.

Ülekandmise kontrollnimekiri

Rääkides Cassandra rändest Kubernetesesse, loodame, et kolimisega muutub selle haldamine mugavamaks. Mida selleks vaja on, mis selle vastu aitab?

1. Andmete salvestamine

Nagu juba selgitatud, salvestab Cassanda osa andmetest RAM-i - sisse Meeldejääv. Kuid on veel üks osa andmetest, mis salvestatakse kettale - kujul SSTable. Nendele andmetele lisatakse olem Kinnituslogi — kõigi tehingute kirjed, mis salvestatakse ka kettale.

Kirjutage Cassandras tehinguskeem

Kubernetesis saame andmete salvestamiseks kasutada PersistentVolume'i. Tänu tõestatud mehhanismidele muutub Kubernetes andmetega töötamine iga aastaga lihtsamaks.

Eraldame Cassandraga igale kaunale oma püsiva helitugevuse

Oluline on märkida, et Cassandra ise tähendab andmete replikatsiooni, pakkudes selleks sisseehitatud mehhanisme. Seega, kui ehitate Cassandra klastri suurest arvust sõlmedest, pole andmete salvestamiseks vaja kasutada hajutatud süsteeme, nagu Ceph või GlusterFS. Sel juhul oleks loogiline salvestada andmeid hostikettale kasutades kohalikud püsivad kettad või paigaldus hostPath.

Teine küsimus on, kas soovite luua iga funktsiooniharu jaoks eraldi keskkonna arendajatele. Sel juhul oleks õige lähenemine tõsta üks Cassandra sõlm ja salvestada andmed hajutatud salvestusruumi, s.t. mainitud Ceph ja GlusterFS on teie valikud. Siis on arendaja kindel, et ta ei kaota testiandmeid isegi siis, kui üks Kuberntese klastri sõlmedest kaob.

2. Järelevalve

Peaaegu vaieldamatu valik Kubernetes seire rakendamiseks on Prometheus (me rääkisime sellest üksikasjalikult seotud aruanne). Kuidas Cassanral Prometheuse mõõdikute eksportijatega läheb? Ja mis on Grafana jaoks sobivate armatuurlaudade puhul veelgi olulisem?

Näide Grafana graafikute ilmumisest Cassandra jaoks

Eksportijaid on ainult kaks: jmx_exporter и cassandra_eksportija.

Valisime endale esimese, sest:

1. JMX Exporter kasvab ja areneb, samas kui Cassandra Exporter ei ole saanud kogukonnalt piisavalt tuge. Cassandra Exporter ei toeta endiselt enamikku Cassandra versioone.
2. Saate seda käivitada javaagendina, lisades lipu -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. Tema jaoks on üks piisav armatuurlaud, mis ei ühildu rakendusega Cassandra Exporter.

3. Kubernetese primitiivide valimine

Vastavalt ülaltoodud Cassandra klastri struktuurile proovime tõlkida kõik seal kirjeldatu Kubernetese terminoloogiasse:

• Cassandra Node → Pod
• Cassandra Rack → StatefulSet
• Cassandra Datacenter → bassein firmalt StatefulSets
• Cassandra Cluster → ???

Selgub, et kogu Cassandra klastri korraga haldamiseks puudub mõni lisaüksus. Aga kui midagi pole olemas, saame selle luua! Kubernetesil on selleks otstarbeks oma ressursside määratlemise mehhanism - Kohandatud ressursi määratlused.

Logide ja hoiatuste jaoks täiendavate ressursside deklareerimine

Kuid kohandatud ressurss ise ei tähenda midagi: see ju nõuab kontroller. Võimalik, et peate abi otsima Kubernetese operaator...

4. Kaunade identifitseerimine

Ülaltoodud lõigus leppisime kokku, et üks Cassandra sõlm võrdub Kubernetes ühe kaustaga. Kuid kaunade IP-aadressid on iga kord erinevad. Ja sõlme tuvastamine Cassandras põhineb IP-aadressil... Selgub, et pärast iga kauna eemaldamist lisab Cassandra klaster uue sõlme.

Väljapääs on ja mitte ainult üks:

1. Me saame pidada arvestust hostiidentifikaatorite (UUID-d, mis tuvastavad Cassandra eksemplarid unikaalselt) või IP-aadresside järgi ja salvestada need kõik mõnesse struktuuri/tabelisse. Sellel meetodil on kaks peamist puudust:
   • Kahe sõlme korraga langemise korral esineb võistlusseisundi oht. Pärast tõusu küsivad Cassandra sõlmed samaaegselt tabelist IP-aadressi ja võistlevad sama ressursi pärast.
   • Kui Cassandra sõlm on oma andmed kaotanud, ei saa me seda enam tuvastada.
2. Teine lahendus tundub väikese häkkimisena, kuid sellegipoolest: saame luua ClusterIP-ga teenuse iga Cassandra sõlme jaoks. Probleemid selle rakendamisega:
   • Kui Cassandra klastris on palju sõlme, peame looma palju teenuseid.
   • ClusterIP-funktsiooni rakendatakse iptablesi kaudu. See võib muutuda probleemiks, kui Cassandra klastris on palju (1000... või isegi 100?) sõlme. Kuigi tasakaalustamine IPVS-i alusel saab selle probleemi lahendada.
3. Kolmas lahendus on kasutada Cassandra sõlmede jaoks sõlmede võrku spetsiaalse poodide võrgu asemel, lubades seade hostNetwork: true. See meetod seab teatud piirangud:
   • Üksuste asendamiseks. Uuel sõlmel peab olema sama IP-aadress, mis eelmisel (pilvedes nagu AWS, GCP on seda peaaegu võimatu teha);
   • Kasutades klastri sõlmede võrku, hakkame konkureerima võrguressursside pärast. Seetõttu on rohkem kui ühe Cassandraga kausta paigutamine ühele klastrisõlmele problemaatiline.

5. Varukoopiad

Soovime salvestada ajakavasse ühe Cassandra sõlme andmete täisversiooni. Kubernetes pakub mugavat funktsiooni CronJob, aga siin paneb Cassandra ise kodara meie ratastesse.

Tuletan meelde, et Cassandra salvestab osa andmetest mällu. Täieliku varukoopia tegemiseks vajate andmeid mälust (Memtables) liigu kettale (SST-tabelid). Sel hetkel lõpetab Cassandra sõlm ühenduste vastuvõtmise, lülitub klastrist täielikult välja.

Pärast seda eemaldatakse varukoopia (snapshot) ja skeem salvestatakse (klahviruum). Ja siis selgub, et lihtsalt varukoopia ei anna meile midagi: peame salvestama andmeidentifikaatorid, mille eest Cassandra sõlm vastutas - need on spetsiaalsed märgid.

Märkide levitamine, et teha kindlaks, milliste andmete eest Cassandra sõlmed vastutavad

Näidisskripti Cassandra varukoopia võtmiseks Google'ist Kubernetesis leiate aadressilt see link. Ainus punkt, mida skript arvesse ei võta, on andmete lähtestamine sõlmele enne hetktõmmise tegemist. See tähendab, et varukoopiat ei tehta praeguse oleku, vaid veidi varasema oleku jaoks. Kuid see aitab mitte sõlme tööst välja võtta, mis tundub väga loogiline.

set -eu

if [[ -z "$1" ]]; then
  info "Please provide a keyspace"
  exit 1
fi

KEYSPACE="$1"

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

if [[ $? -ne 0 ]]; then
  echo "Error while making snapshot"
  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äide bash-skriptist ühest Cassandra sõlmest varukoopia tegemiseks

Cassandra jaoks valmis lahendused Kubernetesis

Mida kasutatakse praegu Cassandra juurutamiseks Kubernetesis ja milline neist vastab antud nõuetele kõige paremini?

1. StatefulSeti või Helmi diagrammidel põhinevad lahendused

Peamiste StatefulSetsi funktsioonide kasutamine Cassandra klastri käitamiseks on hea valik. Helm diagrammi ja Go mallide abil saate pakkuda kasutajale Cassandra juurutamiseks paindlikku liidest.

Tavaliselt töötab see hästi... kuni juhtub midagi ootamatut, näiteks sõlme rike. Standardsed Kubernetese tööriistad ei saa lihtsalt kõiki ülalkirjeldatud funktsioone arvesse võtta. Lisaks on see lähenemisviis väga piiratud, kui palju seda saab laiendada keerukamate kasutuste jaoks: sõlmede asendamine, varundamine, taastamine, jälgimine jne.

Esindajad:

• Helmi peamise hoidla diagramm;
• Diagramm bitnamilt.

Mõlemad diagrammid on võrdselt head, kuid nende puhul esinevad ülalkirjeldatud probleemid.

2. Kubernetes Operatoril põhinevad lahendused

Sellised valikud on huvitavamad, kuna need pakuvad klastri haldamiseks palju võimalusi. Cassandra operaatori, nagu iga teise andmebaasi, kujundamiseks näeb hea muster välja järgmiselt: Sidecar <-> Controller <-> CRD:

Sõlmehaldusskeem hästi läbimõeldud Cassandra operaatoris

Vaatame olemasolevaid operaatoreid.

1. Cassandra-operaator instaclustrist

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

See on tõepoolest väga paljutõotav ja aktiivselt arenev projekt ettevõttelt, mis pakub hallatud Cassandra juurutusi. Nagu ülalpool kirjeldatud, kasutab see külgkorvi konteinerit, mis aktsepteerib HTTP kaudu käske. Java-keeles kirjutatud sellel puudub mõnikord klient-go teegi täiustatud funktsionaalsus. Samuti ei toeta operaator ühe andmekeskuse jaoks erinevaid racke.

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

2. Navigaator firmalt Jetstack

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

Avaldus, mis on loodud DB-as-a-Service juurutamiseks. Praegu toetab kahte andmebaasi: Elasticsearch ja Cassandra. Sellel on sellised huvitavad lahendused nagu andmebaasi juurdepääsu kontroll RBAC kaudu (selleks on tal oma eraldi navigaator-apiserver). Huvitav projekt, mida tasuks lähemalt vaadata, aga viimane commit sai tehtud poolteist aastat tagasi, mis vähendab selgelt selle potentsiaali.

3. Cassandra-operaator vgkowski poolt

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

Nad ei pidanud seda "tõsiselt", kuna viimane andmehoidlale pühendumine oli rohkem kui aasta tagasi. Operaatorarendusest loobutakse: Kubernetese uusim versioon, millest teatati, on 1.9.

4. Cassandra-operaator Rooki poolt

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

Operaator, kelle areng ei edene nii kiiresti, kui tahaksime. Sellel on hästi läbimõeldud CRD-struktuur klastri haldamiseks, see lahendab sõlmede tuvastamise probleemi teenusega Service with ClusterIP (sama "häkkimine") ... kuid see on praegu kõik. Praegu pole järelevalvet ega karbist varukoopiaid (muide, oleme jälgimise jaoks võtsime ise). Huvitav on see, et saate selle operaatori abil juurutada ka ScyllaDB.

NB: Kasutasime seda operaatorit ühes oma projektis väikeste muudatustega. Kogu tööperioodi jooksul (~4 kuud) operaatori töös probleeme ei täheldatud.

5. CassKop firmalt Orange

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

Nimekirja noorim operaator: esimene kohustus tehti 23. mail 2019. Juba praegu on selle arsenalis suur hulk funktsioone meie loendist, mille üksikasjad leiate projektihoidlast. Operaator on üles ehitatud populaarse operaatori-sdk alusel. Toetab jälgimist karbist väljas. Peamine erinevus teistest operaatoritest on kasutus CassKopi pistikprogramm, mis on rakendatud Pythonis ja mida kasutatakse Cassandra sõlmede vaheliseks suhtluseks.

Järeldused

Lähenemisviiside ja võimalike võimaluste arv Cassandra teisaldamiseks Kubernetesesse räägib enda eest: teema on nõutud.

Selles etapis saate omal vastutusel ja riskil proovida mõnda ülalnimetatust: ükski arendajatest ei garanteeri oma lahenduse 100% toimimist tootmiskeskkonnas. Kuid juba praegu tunduvad paljud tooted paljulubavad, et proovida neid arenduspinkidel kasutada.

Ma arvan, et tulevikus tuleb see naine laevas kasuks!

PS

Loe ka meie blogist:

• «MongoDB sujuv migreerimine Kubernetesesse";
• «RabbitMQ sujuv migreerimine Kubernetesesse";
• «Andmebaasid ja Kubernetes (ülevaade ja videoaruanne)";
• «K8s näpunäited ja nipid: suurte andmebaaside alglaadimise kiirendamine'.

Allikas: www.habr.com