ProHoster > Blog > Administrim > Migrimi i Cassandra në Kubernetes: veçori dhe zgjidhje

Migrimi i Cassandra në Kubernetes: veçori dhe zgjidhje

Migrimi i Cassandra në Kubernetes: veçori dhe zgjidhje

Me databazën Apache Cassandra dhe nevojën për ta përdorur atë në infrastrukturën e bazuar në Kubernetes, ne shpesh përballemi. Në këtë material, do të ndajmë vështrimin 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 shtetin»

Kush është Cassandra? Ajo është një sistem i shpërndarë për ruajtjen e të dhënave, i destinuar për menaxhimin e volumit të madh të të dhënave, duke siguruar një disponibilitet të lartë pa një pikë të vetme dështimi. Projekti pothuajse nuk ka nevojë për një prezantim të gjatë, prandaj do të përmend vetëm veçoritë kryesore të Cassandra-s që do të jenë relevante për këtë artikull:

  • Cassandra Ă«shtĂ« shkruar nĂ« Java.
  • Topologjia e Cassandra pĂ«rfshin disa nivele:
    • Nod — njĂ« instancĂ« e shpĂ«rndarĂ« e Cassandra-s;
    • Rack — njĂ« grup instancash Cassandra, tĂ« bashkuara sipas njĂ« kriteri, qĂ« ndodhen nĂ« njĂ« qendĂ«r tĂ« tĂ« dhĂ«nave;
    • Qendra e tĂ« DhĂ«nave — njĂ« pĂ«rmbledhje e tĂ« gjitha grupeve tĂ« instancave Cassandra qĂ« ndodhen nĂ« njĂ« qendĂ«r tĂ« tĂ« dhĂ«nave;
    • Klastri — njĂ« pĂ«rmbledhje e tĂ« gjitha qendrave tĂ« tĂ« dhĂ«nave.
  • PĂ«r identifikimin e nodit, Cassandra pĂ«rdor adresĂ«n IP.
  • PĂ«r shpejtĂ«sinĂ« e operacioneve tĂ« shkruarjes dhe leximit, njĂ« pjesĂ« e tĂ« dhĂ«nave Cassandra ruan nĂ« memorie.

Tani, le të flasim për migrimin në Kubernetes.

Listë kontrolli për transferimin

Kur flasim pĂ«r migrimin e Cassandra nĂ« Kubernetes, ne shpresojmĂ« qĂ« me migrimin menaxhimi i saj do tĂ« bĂ«het mĂ« i lehtĂ«. ÇfarĂ« Ă«shtĂ« e nevojshme pĂ«r kĂ«tĂ«, çfarĂ« do ta ndihmojĂ«?

1. Ruajtja për të dhënat

Siç Ă«shtĂ« theksuar, njĂ« pjesĂ« e tĂ« dhĂ«nave Cassandra ruhet nĂ« memorie — nĂ« Memtable. Por ka edhe njĂ« pjesĂ« tjetĂ«r tĂ« tĂ« dhĂ«nave, qĂ« ruhet nĂ« disk, — nĂ« formĂ«n e SSTable. KĂ«saj i shtohet entiteti Commit Log — regjistrime mbi tĂ« gjitha transaksionet, qĂ« gjithashtu ruhen nĂ« disk.

Migrimi i Cassandra në Kubernetes: veçori dhe zgjidhje
Schema e transaksioneve të shkruarjes në Cassandra

Në Kubernetes, ne mund të përdorim për ruajtjen e të dhënave PersistentVolume. Falë mekanizmave të provuar, të punuarit me të dhënat në Kubernetes bëhet gjithnjë e më e lehtë çdo vit.

Migrimi i Cassandra në Kubernetes: veçori dhe zgjidhje
Çdo pod me Cassandra do t'i rezervojmĂ« njĂ« PersistentVolume tĂ« vetin

ËshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se Cassandra nĂ« vetvete nĂ«nkupton replikimin e tĂ« dhĂ«nave, duke ofruar pĂ«r kĂ«tĂ« mekanizma tĂ« integruar. Prandaj, nĂ«se po krijoni njĂ« grup Cassandra nga njĂ« numĂ«r tĂ« madh nyjesh, nuk ka nevojĂ« tĂ« pĂ«rdorni pĂ«r ruajtjen e tĂ« dhĂ«nave sisteme tĂ« shpĂ«rndara si Ceph ose GlusterFS. NĂ« kĂ«tĂ« rast, do tĂ« ishte logjike tĂ« ruani tĂ« dhĂ«nat nĂ« diskun e nyjes duke pĂ«rdorur diskĂ«t lokalĂ« tĂ« qĂ«ndrueshĂ«m ose montimin hostPath.

Një çështje tjetër është, nëse dëshironi të krijoni një mjedis të veçantë për çdo degë funksionaliteti për zhvilluesit. Në këtë rast, qasja e duhur do të ishte ngritja e një nyjeje Cassandra dhe ruajtja e të dhënave në një depo të shpërndarë, dmth, Ceph dhe GlusterFS të përmendura do të bëhen opsionet tuaja. Kështu, zhvilluesi do të jetë i sigurt se nuk do të humbasë të dhënat testuese madje edhe në rast se humbet një nga nyjet e grupit Kubernetes.

2. Monitorimi

Zgjedhja praktike e bezdisur për realizimin e monitorimit në Kubernetes është Prometheus (në detaje kemi folur për këtë në referatin përkatës). Si shkon me Cassandra për eksportuesit e metrikeve për Prometheus? Dhe, që ndoshta është më e rëndësishme, me dashboard-et e përshtatshme për to në Grafana?

Migrimi i Cassandra në Kubernetes: veçori dhe zgjidhje
Shembujt e pamjes së grafikëve në Grafana për Cassandra

Ekspeditorët janë gjithsej dy: jmx_exporter dhe cassandra_exporter.

Ne zgjodhëm të parin për vete, sepse:

  1. JMX Exporter po rritet dhe po zhvillohet, ndërsa Cassandra Exporter nuk arriti të marrë mbështetje të mjaftueshme nga komuniteti. Cassandra Exporter ende nuk mbështet shumicën e versioneve të Cassandra.
  2. Mund ta nisim si javaagent duke shtuar flamurin -javaagent:emri-i-plugin-dir\/cassandra-exporter.jar=--listen=:9180.
  3. Për të ka një dashboard të përshtatshëm, i cili nuk është i përputhshëm me Cassandra Exporter.

3. Zgjedhja e primitiveve Kubernetes

Sipas strukturës së mësipërme të grupit Cassandra, le të përpiqemi të përkthim gjithçka që është përshkruar atje në terminologjinë Kubernetes:

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

KĂ«shtu, duket se na mungon ndonjĂ« entitet shtesĂ« pĂ«r tĂ« menaxhuar tĂ«rĂ« grupin Cassandra njĂ«kohĂ«sisht. Por nĂ«se mungon diçka, ne mund ta krijojmĂ« atĂ«! NĂ« Kubernetes, pĂ«r kĂ«tĂ« Ă«shtĂ« paraparĂ« mekanizmi i pĂ«rcaktimit tĂ« burimeve tĂ« personalizuara — Custom Resource Definitions.

Migrimi i Cassandra në Kubernetes: veçori dhe zgjidhje
Deklarata e burimeve shtesë për logët dhe alarmet

Por vetë Custom Resource nuk ka asnjë kuptim: sepse për të nevojitet një kontroller. Ndoshta do të duhet të kërkojmë ndihmën e Kubernetes-operatorit


4. Identifikimi i pod’ave

Si e rĂ«nĂ« nĂ« dakord mĂ« lart qĂ« njĂ« nyjĂ« Cassandra do tĂ« barazohet me njĂ« pod nĂ« Kubernetes. Por adresat IP tĂ« pod’ave do tĂ« jenĂ« çdo herĂ« tĂ« ndryshme. Identifikimi i nyjĂ«s nĂ« Cassandra ndodh pikĂ«risht mbi bazĂ«n e adresĂ«s IP... KĂ«shtu, pas çdo fshirjeje tĂ« njĂ« pod’i, klasteri i Cassandra do tĂ« shtojĂ« njĂ« nyjĂ« tĂ« re.

Ka një zgjidhje, dhe jo vetëm një:

  1. Mund tĂ« monitorojmĂ« identifikuesit e hostĂ«ve (UUID’ave, qĂ« identifikojnĂ« nĂ« mĂ«nyrĂ« unike instancat e Cassandra) ose adresat IP dhe ta ruajmĂ« kĂ«tĂ« nĂ« struktura/tabela. Ky metod ka dy disavantazhe kryesore:
    • Rreziku i shfaqjes sĂ« njĂ« kushti garues kur bien papritur dy nyje. Pasi tĂ« ngrihen, nyjet e Cassandra do tĂ« kĂ«rkojnĂ« menjĂ«herĂ« njĂ« adresĂ« IP nga tabela dhe do tĂ« konkurrojnĂ« pĂ«r tĂ« njĂ«jtin burim.
    • NĂ«se njĂ« nyjĂ« Cassandra ka humbur tĂ« dhĂ«nat e saj, nuk do tĂ« mund ta identifikojmĂ« mĂ«.
  2. Zgjidhja e dytë duket si një hile e vogël, por megjithatë: mund të krijojmë Shërbime me ClusterIP për secilën nyjë Cassandra. Problemet e kësaj zbatimi:
    • NĂ«se klasteri i Cassandra ka shumĂ« nyje, do 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?) nyje. MegjithatĂ«, balancimi mbi bazĂ«n e IPVS mund ta zgjidhĂ« kĂ«tĂ« problem.
  3. Zgjidhja e tretĂ« Ă«shtĂ« tĂ« pĂ«rdorim rrjetin e nyjeve pĂ«r nyjet Cassandra nĂ« vend tĂ« njĂ« rrjeti tĂ« veçantĂ« pod’ash duke aktivizuar parametrin hostNetwork: true. Ky metod imponon disa kufizime:
    • KĂ«to janĂ« nĂ« lidhje me zĂ«vendĂ«simin e nyjeve. Nevojitet qĂ« njĂ« nyjĂ« e re tĂ« ketĂ« patjetĂ«r tĂ« njĂ«jtĂ«n adresĂ« IP si ajo e mĂ«parshme (nĂ« shĂ«rbime si AWS, GCP, kjo Ă«shtĂ« praktikisht e pamundur);
    • Duke pĂ«rdorur rrjetin e nyjeve tĂ« klasterit, fillojmĂ« tĂ« konkurrojmĂ« pĂ«r burimet rrjetĂ«rore. Prandaj, Ă«shtĂ« problematike tĂ« vendosim mĂ« shumĂ« se njĂ« pod me Cassandra nĂ« njĂ« nyjĂ« tĂ« klasterit.

5. BĂ«kaps

Dëshirojmë të ruajmë një version të plotë të të dhënave të një nyjeje Cassandra sipas një programi. Kubernetes ofron një mundësi të përshtatshme duke përdorur CronJob, por këtu Cassandra na pengon.

Të kujtojmë se një pjesë e të dhënave të Cassandra ruhet në memorie. Për të bërë një bëkap të plotë, është e nevojshme që të dhënat nga memoria (Memtables) të transferohen në disk (SSTables). Në këtë moment, nyja Cassandra ndalon së pranoni lidhje, duke u çaktivizuar krejtësisht nga klasteri.

Pas kĂ«saj, bĂ«kapi merret (snapshot) dhe ruhet skema (keyspace). Dhe kĂ«tu del se sa thjeshtĂ« backup nuk na jep asgjĂ«: Ă«shtĂ« e nevojshme tĂ« ruajmĂ« identifikuesit e tĂ« dhĂ«nave pĂ«r tĂ« cilat pĂ«rgjigjet nyja Cassandra, — kĂ«to janĂ« toka speciale.

Migrimi i Cassandra në Kubernetes: veçori dhe zgjidhje
Shpërndarja e tokave për identifikimin e të dhënave për të cilat përgjigjen nyjet Cassandra

Një shembull skripti për marrjen e backup-it të Cassandra nga Google në Kubernetes mund të gjendet në këtë lidhje. Një moment i vetëm që skripti nuk e merr parasysh është se duhen zeruar të dhënat në nyjë para se të bëhet snapshot. Kështu, backup bëhet jo për gjendjen aktuale, por për një gjendje pak më parë. Por kjo ndihmon që të mos e nxjerrim nyjën nga puna, që duket shumë logjike.

set -eu

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

KEYSPACE="$1"

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

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

Një shembull bash-skripti për marrjen e backup-it nga një nyjë Cassandra

Zgjidhje të gatshme për Cassandra në Kubernetes

ÇfarĂ« pĂ«rdorin aktualisht pĂ«r implementimin e Cassandra nĂ« Kubernetes dhe çfarĂ« nga kĂ«to Ă«shtĂ« mĂ« e pĂ«rshtatshme pĂ«r kĂ«rkesat e vendosura?

1. Zgjidhjet e 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 anë të Helm-chart dhe shablloneve Go, mund të ofrohet një ndërfaqe fleksibël për përdoruesin për implementimin e Cassandra.

Shpesh kjo funksionon mirë  derisa tĂ« ndodhĂ« diçka e papritur — siç Ă«shtĂ« dĂ«shtimi i njĂ« nyje. Mjetet standarde tĂ« Kubernetes thjesht nuk mund tĂ« marrin parasysh tĂ« gjitha karakteristikat 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Ă«rdorime mĂ« kompleks: zĂ«vendĂ«simi i nyjeve, backup, rikuperim, monitorim etj.

Përfaqësuesit:

Të dy çartit janë po aq të mira, por janë të ndjeshme ndaj problemeve të përshkruara më sipër.

2. Zgjidhjet e bazuara në Kubernetes Operator

Këto opsione janë më interesante, sepse ofrojnë mundësi të shumta për menaxhimin e klasterit. Për projektuara operatorin Cassandra, si çdo bazë tjetër të dhënash, një model i mirë duket si Sidecar Controller CRD:

Migrimi i Cassandra në Kubernetes: veçori dhe zgjidhje
Schema e menaxhimit të nyjeve në një operator Cassandra të projektuara mirë

Le të shqyrtojmë operatorët ekzistues.

1. Cassandra-operator nga instaclustr

  • GitHub
  • GatishmĂ«ri: Alpha
  • Licenca: Apache 2.0
  • I realizuar nĂ«: Java

Ky është vërtet një projekt shumë premtues dhe aktivisht në zhvillim nga një kompani që ofron implementime të menaxhuara të Cassandra. Ai, ashtu siç përshkruhet më lart, përdor një konteiner sidecar që merr komanda përmes HTTP. I shkruar në Java, ndaj ndonjëherë i mungon funksionaliteti më i avancuar i bibliotekës client-go. Gjithashtu, operatori nuk mbështet Rack të ndryshme për një Datacenter.

Sidoqoftë, operatori ka avantazhe si mbështetje për monitorimin, menaxhimin e nivelit të lartë të klasterit përmes CRD dhe madje dokumentacion mbi krijimin e kopjeve rezervë.

2. Navigator nga Jetstack

  • GitHub
  • GatishmĂ«ri: Alpha
  • Licenca: Apache 2.0
  • I realizuar nĂ«: Golang

Operatori, 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 qasjes në bazën e të dhënave përmes RBAC (për këtë ngrihet një navigator-apiserver i veçantë). Një projekt interesant, të cilin do të ishte e këshillueshme ta shqyrtojmë, megjithatë komiti i fundit u bërë një vit e gjysmë më parë, gjë që e ul qartë potencialin e tij.

3. Cassandra-operator nga vgkowski

  • GitHub
  • GatishmĂ«ri: Alpha
  • Licenca: Apache 2.0
  • I realizuar nĂ«: Golang

Nuk e morëm atë «seriozisht», pasi komiti i fundit në repozitor u bë 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Ă«ri: Alpha
  • Licenca: Apache 2.0
  • I realizuar nĂ«: Golang

Operatori, zhvillimi i të cilit nuk po shkon aq shpejt sa do të dëshironim. Ka një strukturë të mirëmenduar CRD për menaxhimin e klasterit, zgjidh problemin me identifikimin e nyjeve përmes Shërbimit me ClusterIP (ai «hack»)... por deri tani kjo është gjithçka. Monitorimi dhe kopjet rezervë nga kutia aktualisht nuk janë aty (për të cilat, në fakt, ne u angazhua vetë). Një pikë interesante, është se me këtë operator është gjithashtu e mundur të implementohet ScyllaDB.

NB: Ky operator, me disa përmirësime të vogla, e kemi përdorur në një nga projektet tona. Nuk janë vërejtur probleme në funksionimin e operatorit gjatë gjithkohëzgjatjes (~4 muaj punë).

5. CassKop nga Orange

  • GitHub
  • GatishmĂ«ri: Alpha
  • Licenca: Apache 2.0
  • I realizuar nĂ«: Golang

Operatori më i ri në listë: komiti i parë u bë më 23 maj 2019. Tani ka tashmë një numër të madh funksionesh nga lista jonë, me të cilat mund të njihemi në repozitorin e projektit. Operatorishtë ndërtuar mbi bazën e operator-sdk të njohur. Mbështet monitorimin «nga kutia». Dallimi kryesor nga operatorët e tjerë është përdorimi plakës CassKop, implementuar në Python dhe i përdorur për komunikim midis nyjeve Cassandra.

PĂ«rfundimet

Numri i afrove dhe mundësive të transferimit të Cassandra në Kubernetes flet vetë: tema është e kërkuar.

Në këtë fazë, mund të provoni diçka nga ajo që përmendet më sipër me rrezikun tuaj: asnjë nga zhvilluesit nuk garanton një punë 100%-sh në ambientin e prodhimit. Por tashmë shumë produkte duken premtuese për t'u provuar në stallat për zhvillim.

Mendoj se në të ardhmen, kjo grua në anije do të jetë në vendin e duhur!

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

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