ProHoster > Blog > Administrimi > Migrimi i Cassandra në Kubernetes: veçoritë dhe zgjidhjet

Migrimi i Cassandra në Kubernetes: veçoritë dhe zgjidhjet

Migrimi i Cassandra në Kubernetes: veçoritë dhe zgjidhjet

Me mendojme se shpesh hasim në përdorimin e bazës së të dhënave Apache Cassandra në infrastrukturën e bazuar në Kubernetes. Në këtë material do të ndajmë vizionin tonë mbi hapat e nevojshëm, kriteret dhe zgjidhjet ekzistuese (përfshirë një përmbledhje të operatorëve) për migrimin e Cassandra në K8s.

«Kush mund të menaxhojë një grua, do të përballojë edhe me një shtet»

Kush është Cassandra? Ajo është një sistem të dhënash të shpërndara, e krijuar për menaxhimin e volumieve të mëdha të të dhënave, duke ofruar disponibilitet të lartë pa një pikë të vetme dështimi. Projekti, ndoshta, nuk ka nevojë për një prezantim të gjatë, prandaj do të përmend vetëm karakteristikat kryesore të Cassandra, që do të jenë të rëndësishme në kontekstin e këtij artikulli:

  • Cassandra Ă«shtĂ« shkruar nĂ« Java.
  • Topologjia e Cassandra pĂ«rfshin disa nivele:
    • Node — njĂ« instancĂ« e deployuar e Cassandra;
    • Rack — njĂ« grup instancash tĂ« Cassandra, tĂ« grupuara sipas njĂ« kritereje, duke u gjetur nĂ« tĂ« njĂ«jtin qendĂ«r tĂ« tĂ« dhĂ«nave;
    • Datacenter — njĂ« pĂ«rbĂ«rje e tĂ« gjitha grupeve tĂ« instancave tĂ« Cassandra, qĂ« ndodhen nĂ« njĂ« qendĂ«r tĂ« dhĂ«nash;
    • Cluster — njĂ« pĂ«rbĂ«rje e tĂ« gjitha qendrave tĂ« tĂ« dhĂ«nave.
  • PĂ«r identifikimin e nyjĂ«s, Cassandra pĂ«rdor adresĂ«n IP.
  • PĂ«r tĂ« saktĂ«suar operacionet e regjistrimit dhe leximit, njĂ« pjesĂ« e tĂ« dhĂ«nave Cassandra ruhet nĂ« memorien operative.

Tani – pĂ«r migrimin e mundshĂ«m nĂ« Kubernetes.

Liste kontrolli për transferimin

Duke folur pĂ«r migrimin e Cassandra nĂ« Kubernetes, shpresojmĂ« qĂ« me kĂ«tĂ« transferim tĂ« menaxhohet mĂ« lehtĂ«. ÇfarĂ« do tĂ« nevojitet pĂ«r kĂ«tĂ«, çfarĂ« do tĂ« ndihmojĂ«?

1. Ruajtja e të dhënave

Siç Ă«shtĂ« saktĂ«suar mĂ« parĂ«, njĂ« pjesĂ« e tĂ« dhĂ«nave tĂ« Cassandra ruhet nĂ« memorien operative – nĂ« Memtable. Por ka edhe njĂ« pjesĂ« tjetĂ«r tĂ« dhĂ«nash, e cila ruhet nĂ« disk, – nĂ« formĂ«n e SSTable. NĂ« kĂ«to tĂ« dhĂ«na shtohet entiteti Commit Log – regjistrimet e tĂ« gjitha transaksioneve, tĂ« cilat gjithashtu ruhen nĂ« disk.

Migrimi i Cassandra në Kubernetes: veçoritë dhe zgjidhjet
Schema e transaksioneve të regjistrimit në Cassandra

Në Kubernetes, ne mund të përdorim për ruajtjen e të dhënave PersistentVolume. Falë mekanizmave të zhvilluara, puna me të dhënat në Kubernetes bëhet gjithnjë e më e lehtë me kalimin e viteve.

Migrimi i Cassandra në Kubernetes: veçoritë dhe zgjidhjet
Çdo pod me Cassandra do t'i alokohet njĂ« PersistentVolume i tij

ËshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se Cassandra, vetvetiu, nĂ«nkupton replikimin e tĂ« dhĂ«nave, duke ofruar mekanizma tĂ« integruar pĂ«r kĂ«tĂ«. Prandaj, nĂ«se po ngrini njĂ« grumbull Cassandra nga njĂ« numĂ«r i madh nodash, nuk ka nevojĂ« tĂ« pĂ«rdorni sisteme tĂ« shpĂ«rndara pĂ«r ruajtjen e tĂ« dhĂ«nave si Ceph ose GlusterFS. NĂ« kĂ«tĂ« rast, do tĂ« ishte logjike tĂ« ruani tĂ« dhĂ«nat nĂ« diskun e nodit nĂ«pĂ«rmjet disqeve lokalĂ« tĂ« qĂ«ndrueshĂ«m ose montimit hostPath.

Një çështje tjetër është nëse dëshironi të krijoni një ambient të veçantë për zhvilluesit për çdo degë funksionaliteti. Në këtë rast, qasja e duhur do të ishte të ngrihet një nod Cassandra dhe të ruhen të dhënat në një ruajtje të shpërndarë, dmth, Ceph dhe GlusterFS të përmendura do të bëhen opsioni juaj. Kështu, zhvilluesi do të jetë i sigurt se nuk do të humbasë të dhënat testuese edhe në rastin e humbjes së një prej nodave të grumbullit Kubernetes.

2. Monitorimi

Zgjedhja pothuajse e paalternuar për realizimin e monitorimit në Kubernetes është Prometheus (ne e kemi përshkruar këtë në referatin përkatëse). Si qëndron Cassandra me eksportuesit e metrikave për Prometheus? Dhe, çka është ndoshta më e rëndësishme, me dashboard-et e përshtatshme për to për Grafana?

Migrimi i Cassandra në Kubernetes: veçoritë dhe zgjidhjet
shembuj i pamjes së grafikëve në Grafana për Cassandra

Ka vetëm dy eksportues: jmx_exporter dhe cassandra_exporter.

Ne zgjodhëm të parin, sepse:

  1. JMX Exporter po rritet dhe zhvillohet, ndërsa Cassandra Exporter nuk ka arritur të marrë mbështetje të duhur nga komuniteti. Cassandra Exporter ende nuk mbështet shumicën e versioneve të Cassandra.
  2. Mund ta nisni si javaagent duke shtuar këtë flamur -javaagent:/cassandra-exporter.jar=--listen=:9180.
  3. Për të ka një dashboard adekuat, i cili nuk është i përputhshëm me Cassandra Exporter.

3. Zgjedhja e primitiveve të Kubernetes

Sipas strukturës së mësipërme të klasterit Cassandra, do të mundohemi të përkthejmë gjithçka që është përshkruar aty në terminologjinë e Kubernetes:

  • Cassandra Node → Pod
  • Cassandra Rack → StatefulSet
  • Cassandra Datacenter → njĂ« grup StatefulSets
  • Cassandra Cluster → ???

Kjo nĂ«nkupton se mungon njĂ« entitet shtesĂ« pĂ«r tĂ« menaxhuar tĂ« gjithĂ« klasterin Cassandra njĂ«herĂ«sh. Por nĂ«se diçka mungon, mund ta krijojmĂ« atĂ«! NĂ« Kubernetes, pĂ«r kĂ«tĂ« qĂ«llim ekziston mekanizmi i pĂ«rcaktimit tĂ« burimeve tĂ« personalizuara — Definitat e Burimeve tĂ« Personalizuara.

Migrimi i Cassandra në Kubernetes: veçoritë dhe zgjidhjet
Deklarimi i burimeve të tjera për logje dhe njoftime

Por vetë Burimi i Personalizuar nuk ka kuptim: pasi për të nevojitet kontrolleri. Ndoshta do të duhet të kërkojmë ndihmën e Kubernetes-operatorit


4. Identifikimi i pod'ave

Në pikën e mësipërme u pajtuam se një nyje Cassandra do të barazohet me një pod në Kubernetes. Por adresat IP të pod'ave do të jenë gjithmonë të ndryshme. Identifikimi i nyjes në Cassandra bëhet pikërisht mbi bazën e adresës IP... Kjo do të thotë se, pas çdo fshirjeje të pod'it, klasteri Cassandra do të shtojë një nyje të re.

Ka zgjidhje, madje jo vetëm një:

  1. Mund të mbajmë shënim në bazë të identifikatorëve të hosteve (UUID, që identifikojnë në mënyrë unike instancat e Cassandra) ose sipas adresave IP dhe ta ruajmë këtë informacion në struktura/tabela të caktuara. Ky metodë ka dy disavantazhe kryesore:
    • Rreziku i krijimit tĂ« njĂ« kushti garues nĂ« rastin e rĂ«nies sĂ« dy nyjeve menjĂ«herĂ«. Pas rikthimit, nyjet Cassandra do tĂ« kĂ«rkojnĂ« njĂ« adresĂ« IP nga tabela dhe do tĂ« konkurrojnĂ« pĂ«r tĂ« njĂ«jtĂ«n burim.
    • NĂ«se nyja Cassandra ka humbur tĂ« dhĂ«nat e saj, ne nuk do tĂ« mund ta identifikojmĂ« mĂ«.
  2. Zgjidhja e dytë duket si një hack i vogël, por megjithatë: mund të krijojmë një Shërbim me ClusterIP për çdo nyje Cassandra. Problemet e kësaj zbatimi:
    • NĂ«se klasteri Cassandra ka shumĂ« nyje, do tĂ« na duhet tĂ« krijojmĂ« shumĂ« ShĂ«rbime.
    • MundĂ«sia e ClusterIP realizohet pĂ«rmes iptables. Kjo mund tĂ« bĂ«het njĂ« problem nĂ«se nĂ« klasterin Cassandra ka shumĂ« (1000
 apo madje 100?) node. Balancimi nĂ« bazĂ« tĂ« IPVS Ă«shtĂ« nĂ« gjendje ta zgjidhĂ« kĂ«tĂ« problem.
  3. Zgjidhja e tretĂ« Ă«shtĂ« tĂ« pĂ«rdorim pĂ«r node Cassandra rrjetin e nodeve nĂ« vend tĂ« njĂ« rrjeti tĂ« dedikuar pod’esh duke aktivizuar cilĂ«simin hostNetwork: true. Ky metod ka disa kufizime:
    • PĂ«r zĂ«vendĂ«simin e nodeve. Duhet qĂ« nodi i ri tĂ« ketĂ« domosdoshmĂ«risht tĂ« njĂ«jtin adresĂ« IP si ai paraardhĂ«s (nĂ« nube si AWS, GCP, kjo Ă«shtĂ« praktikisht e pamundur);
    • Duke pĂ«rdorur rrjetin e nodeve tĂ« klasterit, fillojmĂ« tĂ« garojmĂ« pĂ«r burimet rrjetĂ«. Prandaj, tĂ« vendosim mĂ« shumĂ« se njĂ« pod nĂ« njĂ« node tĂ« klasterit me Cassandra do tĂ« jetĂ« problematik.

5. Backup-et

Dëshirojmë të ruajmë një version të plotë të të dhënave nga një node Cassandra në një orar të rregullt. Kubernetes ofron një mundësi të përshtatshme duke përdorur CronJob, por këtu na pengon vetë Cassandra.

Më kujtohet se një pjesë e të dhënave Cassandra ruhet në memorie. Për të bërë një backup të plotë, duhet të transferojmë të dhënat nga memoria (Memtables) në disk (SSTables). Në këtë moment, nodi Cassandra ndalon pranimin e lidhjeve, duke u çaktivizuar plotësisht nga puna e klasterit.

Pas kësaj, merret një backup (snapshot) dhe ruhet një skemë (keyspace). Dhe këtu del në pah se thjesht backup-i nuk na jep asgjë: duhet të ruajmë identifikatorët e të dhënave për të cilat ishte përgjegjës nodi Cassandra - këta janë tokene speciale.

Migrimi i Cassandra në Kubernetes: veçoritë dhe zgjidhjet
Distribuimi i tokeneve për identifikimin e të dhënave për të cilat janë përgjegjës nodet Cassandra

Shembulli i skriptit për marrjen e backup-it të Cassandra nga Google në Kubernetes mund të gjendet në kjo lidhje. Momenti i vetëm që skripti nuk e merr parasysh është shlyerja e të dhënave në nod para se të merret snapshot-i. Kjo do të thotë se backup-i kryhet jo për gjendjen aktuale, por për një gjendje pak më parë. Por kjo ndihmon që nodi të mos dalë nga puna, gjë që duket shumë logjike.

set -eu

if [[ -z "$1" ]]; then
  info "Ju lutem jepni një keyspace"
  exit 1
fi

KEYSPACE="$1"

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

if [[ $? -ne 0 ]]; then
  echo "Gabim gjatë krijimit të snapshot-it"
  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}"

Shembulli i skriptit bash për marrjen e backup-it nga një nod Cassandra

Zgjidhje të gatshme për Cassandra në Kubernetes

ÇfarĂ« pĂ«rdoret aktualisht pĂ«r tĂ« shpĂ«rndarĂ« Cassandra nĂ« Kubernetes dhe cila prej tyre pĂ«rmbush mĂ« sĂ« miri kĂ«rkesat e caktuara?

1. Zgjidhje të bazuara në StatefulSet ose Helm-charts

Përdorimi i funksioneve bazë të StatefulSets për të nisur një klaster Cassandra është një opsion i mirë. Me ndihmën e Helm-chart dhe template-ve Go, mund t'i ofrohet përdoruesit një ndërfaqe e përshtatshme për shpërndarjen e Cassandra.

Zakonisht kjo funksionon mirë... deri sa ndodh diçka e papritur - për shembull, dështimi i një nodi. Mjetet standarde të Kubernetes vetëm kafe nuk mund të bëjnë llogaritë për të gjitha veçoritë e përshkruara më sipër. Për më tepër, ky qasje është shumë e kufizuar në mënyrën se si mund të zgjerohet për përdorim më të ndërlikuar: zëvendësimi i node-ve, kopjimi, rikuperimi, monitorimi, etj.

Përfaqësuesit:

Të dy chart-et janë njëlloj të mira, por janë të ndjeshëm ndaj problemeve të përshkruara më sipër.

2. Zgjidhje të bazuara në Kubernetes Operator

Këto opsione janë më tërheqëse, sepse ofrojnë mundësi të gjera për menaxhimin e klasterit. Për projektimin e operatorit Cassandra, siç është çdo bazë të dhënash tjetër, një model i mirë duket si Sidecar Controller CRD:

Migrimi i Cassandra në Kubernetes: veçoritë dhe zgjidhjet
Skema e menaxhimit të nyjeve në një operator Cassandra të dizajnuar mirë

Le ta shqyrtojmë operatorët ekzistues.

1. Cassandra-operator nga instaclustr

  • GitHub
  • GatishmĂ«ria: Alpha
  • Licenca: Apache 2.0
  • Implementuar nĂ«: Java

Ky Ă«shtĂ« vĂ«rtet njĂ« projekt shumĂ« premtues dhe nĂ« zhvillim e sipĂ«r nga njĂ« kompani qĂ« ofron shpĂ«rndarje tĂ« menaxhuara tĂ« Cassandra. Ai, ashtu siç pĂ«rshkruhet mĂ« lart, pĂ«rdor njĂ« kontejner sidecar qĂ« pranon komanda pĂ«rmes HTTP. ËshtĂ« shkruar nĂ« Java, prandaj ndonjĂ«herĂ« i mungon funksionaliteti mĂ« i avancuar i bibliotekĂ«s client-go. Po ashtu, operatori nuk mbĂ«shtet Racks tĂ« ndryshme pĂ«r njĂ« Datacenter.

Megjithatë, operatori ka disa përparësi, si mbështetje për monitorimin, menaxhimin e nivelit të lartë të klasterit përmes CRD-së dhe madje dokumentacion për krijimin e kopjeve rezervë.

2. Navigator nga Jetstack

  • GitHub
  • GatishmĂ«ria: Alpha
  • Licenca: Apache 2.0
  • Implementuar nĂ«: Golang

Operator i destinuar për shpërndarjen e DB-as-a-Service. Aktualisht mbështet dy baza të dhënash: Elasticsearch dhe Cassandra. Ka disa zgjidhje interesante, si kontrolli i aksesit në bazën e të dhënave përmes RBAC (për këtë ngrihet një navigator-apiserver i veçantë). Një projekt interesant që meriton vëmendje, megjithatë komiti i fundit u bë një ndihmë një vit e gjysmë më parë, gjë që e ul potencialin e tij.

3. Cassandra-operator nga vgkowski

  • GitHub
  • GatishmĂ«ria: Alpha
  • Licenca: Apache 2.0
  • Implementuar nĂ«: Golang

Nuk e morëm seriozisht, pasi komiti i fundit në depo ishte më shumë se një vit më parë. Zhvillimi i operatorit është braktisur: versioni më i fundit i Kubernetes, i shpallur si i mbështetur, është 1.9.

4. Cassandra-operator nga Rook

  • GitHub
  • GatishmĂ«ria: Alpha
  • Licenca: Apache 2.0
  • Implementuar nĂ«: Golang

Operatori, zhvillimi i të cilit po ecën më ngadalë se sa do të dëshironim. Ka një strukturë të menduar mirë për CRD për menaxhimin e klasterit, zgjidh problemin e identifikimit të nyjeve me anë të Shërbimit me ClusterIP (ai 'hack' që përmendëm)... por deri tani, kjo është gjithçka. Nuk ka monitorim dhe backup nga kutia (për shembull, ne marrim vetë këtë detyrë). Një detaj interesant është se me anë të këtij operatori mund të ngrihet gjithashtu ScyllaDB.

NB: Ky ky operator me disa përmirësime e kemi përdorur në një prej projekteve tona. Nuk ka pasur probleme në funksionimin e operatorit gjatë gjithë kohës së përdorimit (~4 muaj punë).

5. CassKop nga Orange

  • GitHub
  • GatishmĂ«ria: Alpha
  • Licenca: Apache 2.0
  • Implementuar nĂ«: Golang

Operatori më i ri në listë: komenti i parë u bë më 23 maj 2019. Tani për tani, ai ka në arsenalin e tij një numër të madh karakteristikash nga lista jonë, të cilat mund të shqyrtohen më në detaje në repo-n e projektit. Operatorët janë ndërtuar mbi bazën e operator-sdk të njohur. Mbështet monitorimin "nga kutia". Diferenca kryesore nga operatorët e tjerë është përdorimi i pluginit CassKop, i zbatuar në Python dhe përdorur për komunikimin midis nyjeve Cassandra.

PĂ«rfundimet

Numri i qasjeve dhe mundësive të mundshme për migrimin e Cassandra në Kubernetes flet vetë: tema është e kërkuar.

Në këtë fazë, provoni ndonjë gjë nga ato të përshkruara më lart në rrezikun tuaj: asnjë nga zhvilluesit nuk garanton funksionimin 100% të zgjidhjes së tij në ambientin e prodhimit. Por tashmë shumë produkte duken premtuese për t'u përdorur në stendat për zhvillim.

Mendoj se në të ardhmen kjo grua në anije do të vijë në vend!

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster