Migrasi Cassandra menyang Kubernetes: fitur lan solusi

Kita ajeg nemokke database Apache Cassandra lan perlu kanggo operate ing infrastruktur basis Kubernetes. Ing materi iki, kita bakal nuduhake sesanti saka langkah perlu, kritéria lan solusi ana (kalebu ringkesan operator) kanggo migrasi Cassandra kanggo K8s.

"Sapa sing bisa mrentah wanita uga bisa mrentah negara"

Sapa sing Cassandra? Iku sistem panyimpenan mbagekke dirancang kanggo ngatur volume gedhe saka data nalika mesthekake kasedhiyan dhuwur tanpa titik siji saka Gagal. Proyek kasebut meh ora mbutuhake introduksi sing dawa, mula aku bakal menehi mung fitur utama Cassandra sing bakal relevan ing konteks artikel tartamtu:

• Cassandra ditulis nganggo basa Jawa.
• Topologi Cassandra kalebu sawetara tingkat:
  • Node - siji disebarake Cassandra Kayata;
  • Rak minangka klompok kasus Cassandra, digabungake karo sawetara karakteristik, dumunung ing pusat data sing padha;
  • Datacenter - kumpulan kabeh klompok kasus Cassandra sing ana ing siji pusat data;
  • Cluster minangka kumpulan kabeh pusat data.
• Cassandra nggunakake alamat IP kanggo ngenali simpul.
• Kanggo nyepetake operasi nulis lan maca, Cassandra nyimpen sawetara data ing RAM.

Saiki - kanggo pamindhahan potensial nyata kanggo Kubernetes.

Priksa-dhaftar kanggo transfer

Ngomong babagan migrasi Cassandra menyang Kubernetes, muga-muga kanthi pamindhahan bakal luwih trep kanggo ngatur. Apa sing dibutuhake kanggo iki, apa sing bakal mbantu?

1. Panyimpenan data

Kaya sing wis dijlentrehake, Cassanda nyimpen bagean data ing RAM - ing Mebel. Nanging ana bagean liya saka data sing disimpen ing disk - ing wangun SSTable. Entitas ditambahake menyang data iki Log Komit - cathetan kabeh transaksi, sing uga disimpen ing disk.

Tulis diagram transaksi ing Cassandra

Ing Kubernetes, kita bisa nggunakake PersistentVolume kanggo nyimpen data. Thanks kanggo mekanisme sing wis kabukten, nggarap data ing Kubernetes dadi luwih gampang saben taun.

Kita bakal nyedhiyakake PersistentVolume dhewe kanggo saben pod Cassandra

Wigati dicathet yen Cassandra dhewe nuduhake replikasi data, nawakake mekanisme sing dibangun kanggo iki. Mulane, yen sampeyan mbangun kluster Cassandra saka akeh kelenjar, mula ora perlu nggunakake sistem sing disebarake kaya Ceph utawa GlusterFS kanggo panyimpenan data. Ing kasus iki, iku bakal logis kanggo nyimpen data ing disk host nggunakake disk tetep lokal utawa soyo tambah hostPath.

Pitakonan liyane yaiku yen sampeyan pengin nggawe lingkungan sing kapisah kanggo pangembang kanggo saben cabang fitur. Ing kasus iki, pendekatan sing bener bakal mundhakaken siji simpul Cassandra lan nyimpen data ing panyimpenan mbagekke, i.e. Ceph lan GlusterFS kasebut bakal dadi pilihan sampeyan. Banjur pangembang bakal yakin manawa dheweke ora bakal kelangan data tes sanajan salah sawijining simpul kluster Kuberntes ilang.

2. Ngawasi

Pilihan sing meh ora bisa dibantah kanggo ngetrapake pemantauan ing Kubernetes yaiku Prometheus (kita ngomong babagan iki kanthi rinci ing laporan sing gegandhengan). Kepiye Cassandra karo eksportir metrik kanggo Prometheus? Lan, apa sing luwih penting, kanthi dashboard sing cocog kanggo Grafana?

Conto tampilan grafik ing Grafana kanggo Cassandra

Mung ana rong eksportir: jmx_exporter и cassandra_exporter.

Kita milih sing pisanan kanggo awake dhewe amarga:

1. JMX Exporter berkembang lan berkembang, nalika Cassandra Exporter durung entuk dhukungan komunitas sing cukup. Cassandra Exporter isih ora ndhukung paling versi Cassandra.
2. Sampeyan bisa mbukak minangka javaagent kanthi nambahake gendera -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. Ana siji kanggo dheweke dashboad cekap, sing ora kompatibel karo Cassandra Exporter.

3. Milih Kubernetes primitif

Miturut struktur kluster Cassandra ing ndhuwur, ayo nyoba nerjemahake kabeh sing diterangake ing terminologi Kubernetes:

• Cassandra Node → Pod
• Cassandra Rack → StatefulSet
• Cassandra Datacenter → pool saka StatefulSets
• Cluster Cassandra → ???

Pranyata sawetara entitas tambahan ilang kanggo ngatur kabeh klompok Cassandra bebarengan. Nanging yen ana sing ora ana, kita bisa nggawe! Kubernetes duwe mekanisme kanggo nemtokake sumber daya dhewe kanggo tujuan iki - Definisi Sumber Daya Kustom.

Nyatakake sumber daya tambahan kanggo log lan tandha

Nanging Custom Resource dhewe ora ateges apa-apa: sawise kabeh, iku mbutuhake pengontrol. Sampeyan bisa uga kudu njaluk bantuan operator Kubernetes...

4. Identifikasi polong

Ing paragraf ing ndhuwur, kita sarujuk yen siji simpul Cassandra bakal padha karo siji pod ing Kubernetes. Nanging alamat IP saka pods bakal beda saben wektu. Lan identifikasi simpul ing Cassandra adhedhasar alamat IP ... Pranyata sawise saben mbusak pod, kluster Cassandra bakal nambah simpul anyar.

Ana cara metu, lan ora mung siji:

1. Kita bisa nyimpen cathetan kanthi pengenal host (UUID sing ngenali kasus Cassandra kanthi unik) utawa kanthi alamat IP lan nyimpen kabeh ing sawetara struktur/tabel. Cara kasebut duwe rong kerugian utama:
   • Risiko kondisi balapan sing kedadeyan yen rong kelenjar tiba bebarengan. Sawise munggah, simpul Cassandra bakal bebarengan njaluk alamat IP saka meja lan saingan kanggo sumber daya sing padha.
   • Yen simpul Cassandra ilang data, kita ora bakal bisa ngenali maneh.
2. Solusi kapindho katon kaya hack cilik, nanging: kita bisa nggawe Layanan karo ClusterIP kanggo saben simpul Cassandra. Masalah karo implementasine iki:
   • Yen ana akeh kelenjar ing kluster Cassandra, kita kudu nggawe akeh Layanan.
   • Fitur ClusterIP dileksanakake liwat iptables. Iki bisa dadi masalah yen kluster Cassandra duwe akeh (1000 ... utawa malah 100?) simpul. sanadyan imbangan adhedhasar IPVS bisa ngatasi masalah iki.
3. Solusi katelu yaiku nggunakake jaringan simpul kanggo simpul Cassandra tinimbang jaringan pod khusus kanthi ngaktifake setelan kasebut. hostNetwork: true. Cara iki ngetrapake watesan tartamtu:
   • Kanggo ngganti unit. Perlu yen simpul anyar kudu duwe alamat IP sing padha karo sing sadurunge (ing awan kaya AWS, GCP iki meh ora bisa ditindakake);
   • Nggunakake jaringan kelenjar kluster, kita wiwiti saingan kanggo sumber daya jaringan. Mulane, nempatake luwih saka siji pod karo Cassandra ing siji simpul kluster bakal dadi masalah.

5. Serep

Kita pengin nyimpen versi lengkap data siji simpul Cassandra ing jadwal. Kubernetes menehi fitur trep nggunakake CronJob, nanging kene Cassandra dhéwé sijine ngandika ing gembong kita.

Ayo kula ngelingake yen Cassandra nyimpen sawetara data ing memori. Kanggo nggawe serep lengkap, sampeyan butuh data saka memori (Memtables) pindhah menyang disk (SSTables). Ing titik iki, simpul Cassandra mandheg nampa sambungan, rampung mati saka kluster.

Sawise iki, serep dibusak (gambar asli seko) lan skema kasebut disimpen (papan tombol). Banjur ternyata mung serep ora menehi apa-apa: kita kudu nyimpen pengenal data sing tanggung jawab simpul Cassandra - iki minangka token khusus.

Distribusi token kanggo ngenali data apa sing tanggung jawab node Cassandra

Tuladha skrip kanggo njupuk cadangan Cassandra saka Google ing Kubernetes bisa ditemokake ing link iki. Siji-sijine titik sing ora digatekake skrip yaiku ngreset data menyang simpul sadurunge njupuk gambar. Sing, serep dileksanakake ora kanggo negara saiki, nanging kanggo negara sethitik sadurungé. Nanging iki mbantu ora njupuk simpul metu saka operasi, kang misale jek banget logis.

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}"

Conto script bash kanggo njupuk serep saka siji simpul Cassandra

Solusi siap kanggo Cassandra ing Kubernetes

Apa sing saiki digunakake kanggo nyebarake Cassandra ing Kubernetes lan endi sing paling cocog karo syarat sing diwenehake?

1. Solusi adhedhasar denah StatefulSet utawa Helm

Nggunakake fungsi StatefulSets dhasar kanggo mbukak kluster Cassandra iku pilihan apik. Nggunakake grafik Helm lan Go cithakan, sampeyan bisa nyedhiyani pangguna karo antarmuka fleksibel kanggo deploying Cassandra.

Iki biasane dianggo kanthi apik ... nganti kedadeyan sing ora dikarepake, kayata kegagalan simpul. Piranti standar Kubernetes ora bisa nggatekake kabeh fitur sing diterangake ing ndhuwur. Kajaba iku, pendekatan iki diwatesi banget babagan jumlah sing bisa ditambahake kanggo panggunaan sing luwih rumit: panggantos simpul, serep, pemulihan, pemantauan, lsp.

Perwakilan:

• Bagan saka gudang Helm utama;
• Bagan saka bitnami.

Loro-lorone denah padha apik, nanging tundhuk masalah sing diterangake ing ndhuwur.

2. Solusi adhedhasar Kubernetes Operator

Opsi kasebut luwih menarik amarga menehi kesempatan akeh kanggo ngatur kluster. Kanggo ngrancang operator Cassandra, kaya database liyane, pola apik katon kaya Sidecar <-> Controller <-> CRD:

Skema manajemen simpul ing operator Cassandra sing dirancang kanthi apik

Ayo goleki operator sing ana.

1. Cassandra-operator saka instaclustr

• GitHub
• Kesiapan: Alpha
• Lisensi: Apache 2.0
• Dilaksanakake ing: Jawa

Iki pancen proyek banget lan aktif ngembangake saka perusahaan sing nawakake penyebaran Cassandra sing dikelola. Iki, kaya sing kasebut ing ndhuwur, nggunakake wadhah sidecar sing nampa perintah liwat HTTP. Ditulis ing Jawa, kadhangkala ora nduweni fungsi sing luwih maju saka perpustakaan klien-go. Uga, operator ora ndhukung Rak beda kanggo siji Datacenter.

Nanging operator duwe kaluwihan kayata dhukungan kanggo ngawasi, manajemen kluster tingkat dhuwur nggunakake CRD, lan uga dokumentasi kanggo nggawe serep.

2. Navigator saka Jetstack

• GitHub
• Kesiapan: Alpha
• Lisensi: Apache 2.0
• Dilaksanakake ing: Golang

Pernyataan sing dirancang kanggo nyebarake DB-as-a-Service. Saiki ndhukung rong database: Elasticsearch lan Cassandra. Wis solusi menarik kayata kontrol akses database liwat RBAC (kanggo iki wis navigator-apiserver dhewe kapisah). Proyèk sing menarik sing kudu ditliti kanthi tliti, nanging komitmen pungkasan digawe setaun setengah kepungkur, sing jelas nyuda potensiale.

3. Cassandra-operator dening vgkowski

• GitHub
• Kesiapan: Alpha
• Lisensi: Apache 2.0
• Dilaksanakake ing: Golang

Dheweke ora nganggep "serius", amarga komitmen pungkasan menyang repositori luwih saka setahun kepungkur. Pangembangan operator ditinggalake: versi paling anyar saka Kubernetes sing dilapurake minangka didhukung yaiku 1.9.

4. Cassandra-operator dening Rook

• GitHub
• Kesiapan: Alpha
• Lisensi: Apache 2.0
• Dilaksanakake ing: Golang

Operator sing pangembangane ora maju kanthi cepet kaya sing dikarepake. Nduwe struktur CRD sing dipikirake kanthi apik kanggo manajemen kluster, ngrampungake masalah ngenali kelenjar nggunakake Layanan karo ClusterIP ("hack" sing padha) ... nanging mung saiki. Saiki ora ana pemantauan utawa serep metu saka kothak (kanthi cara, kita kanggo ngawasi njupuk dhewe). Titik sing menarik yaiku sampeyan uga bisa masang ScyllaDB nggunakake operator iki.

NB: Kita nggunakake operator iki kanthi modifikasi cilik ing salah sawijining proyek. Ora ana masalah sing ditemokake ing karya operator sajrone kabeh operasi (~ 4 sasi operasi).

5. CassKop saka Orange

• GitHub
• Kesiapan: Alpha
• Lisensi: Apache 2.0
• Dilaksanakake ing: Golang

Operator paling enom ing dhaptar: komitmen pisanan digawe tanggal 23 Mei 2019. Saiki wis ana ing arsenal akeh fitur saka dhaptar kita, rincian liyane sing bisa ditemokake ing repositori proyek. Operator dibangun ing basis saka populer operator-sdk. Ndhukung ngawasi metu saka kothak. Bentenane utama saka operator liyane yaiku panggunaan Plugin CassKop, dipun ginakaken ing Python lan digunakake kanggo komunikasi antarane kelenjar Cassandra.

temonan

Jumlah pendekatan lan opsi sing bisa kanggo porting Cassandra menyang Kubernetes ngomong dhewe: topik kasebut dikarepake.

Ing tahap iki, sampeyan bisa nyoba samubarang ing ndhuwur kanthi resiko lan resiko dhewe: ora ana pangembang sing njamin 100% operasi solusi kasebut ing lingkungan produksi. Nanging saiki, akeh produk katon janji bakal nyoba digunakake ing bangku pangembangan.

Aku ing mangsa iki wong wadon ing kapal bakal teka ing Handy!

PS

Waca uga ing blog kita:

• «Migrasi lancar MongoDB menyang Kubernetes";
• «Migrasi lancar saka RabbitMQ menyang Kubernetes";
• «Database lan Kubernetes (ringkesan lan laporan video)";
• «Tip & trik K8s: Nyepetake bootstrap kanggo database gedhe".

Source: www.habr.com