Migrasi Cassandra ka Kubernetes: fitur sareng solusi

Urang rutin sapatemon database Apache Cassandra jeung kabutuhan pikeun beroperasi dina infrastruktur basis Kubernetes. Dina bahan ieu, urang bakal babagi visi urang ngeunaan léngkah diperlukeun, kriteria jeung solusi aya (kaasup tinjauan operator) pikeun migrasi Cassandra ka K8s.

"Saha waé anu tiasa maréntah awéwé ogé tiasa maréntah nagara"

Saha éta Cassandra? Ieu mangrupakeun sistem gudang disebarkeun dirancang pikeun ngatur volume badag data bari mastikeun kasadiaan tinggi tanpa titik tunggal gagal. Proyék boro peryogi perkenalan anu panjang, janten kuring ngan ukur masihan fitur utama Cassandra anu bakal relevan dina kontéks tulisan khusus:

• Cassandra ditulis dina basa Jawa.
• Topologi Cassandra ngawengku sababaraha tingkatan:
  • Node - hiji conto Cassandra anu disebarkeun;
  • Rak mangrupakeun grup instansi Cassandra, dihijikeun ku sababaraha ciri, lokasina di puseur data sarua;
  • Datacenter - kumpulan sadaya grup instansi Cassandra lokasina di hiji puseur data;
  • Kluster mangrupikeun kumpulan sadaya pusat data.
• Cassandra ngagunakeun alamat IP pikeun ngaidentipikasi titik.
• Pikeun nyepetkeun operasi nulis sareng maca, Cassandra nyimpen sababaraha data dina RAM.

Ayeuna - kana potensi sabenerna move mun Kubernetes.

Daptar pariksa pikeun mindahkeun

Diomongkeun ngeunaan migrasi Cassandra ka Kubernetes, kami ngarepkeun yén kalayan mindahkeun éta bakal langkung merenah pikeun ngatur. Naon anu bakal diperyogikeun pikeun ieu, naon anu bakal ngabantosan ieu?

1. Panyimpenan data

Sakumaha anu parantos dijelaskeun, Cassanda nyimpen bagian tina data dina RAM - in Memtable. Tapi aya bagian sejen tina data nu disimpen ka disk - dina formulir SSTable. Hiji éntitas ditambahkeun kana data ieu Log komitmen - rékaman sadaya transaksi, anu ogé disimpen kana disk.

Tulis diagram transaksi dina Cassandra

Dina Kubernetes, urang tiasa nganggo PersistentVolume pikeun nyimpen data. Hatur nuhun kana mékanisme anu kabuktian, damel sareng data dina Kubernetes janten langkung gampang unggal taun.

Urang bakal allocate PersistentVolume urang sorangan ka unggal pod Cassandra

Penting pikeun dicatet yén Cassandra sorangan nunjukkeun réplikasi data, nawiskeun mékanisme anu diwangun pikeun ieu. Kukituna, upami anjeun ngawangun klaster Cassandra tina sajumlah ageung titik, maka teu kedah nganggo sistem anu disebarkeun sapertos Ceph atanapi GlusterFS pikeun neundeun data. Dina hal ieu, éta bakal logis pikeun nyimpen data dina disk host ngagunakeun disk pengkuh lokal atawa ningkatna hostPath.

Patarosan sanésna nyaéta upami anjeun badé nyiptakeun lingkungan anu misah pikeun pamekar pikeun tiap cabang fitur. Dina hal ieu, pendekatan bener bakal ngangkat hiji titik Cassandra tur nyimpen data dina gudang disebarkeun, i.e. Ceph sareng GlusterFS anu disebatkeun bakal janten pilihan anjeun. Lajeng pamekar bakal yakin yén anjeunna moal leungit data test sanajan salah sahiji titik klaster Kuberntes leungit.

2. Ngawaskeun

Pilihan anu ampir teu aya bantahan pikeun ngalaksanakeun monitoring di Kubernetes nyaéta Prometheus (urang ngobrol ngeunaan ieu sacara rinci dina laporan patali). Kumaha Cassandra lakukeun sareng eksportir métrik pikeun Prometheus? Sareng, naon anu langkung penting, kalayan dasbor anu cocog pikeun Grafana?

Conto penampilan grafik dina Grafana pikeun Cassandra

Aya ngan dua eksportir: jmx_exporter и cassandra_exporter.

Kami milih anu munggaran pikeun diri urang sorangan sabab:

1. JMX Exporter ngembang sareng berkembang, sedengkeun Cassandra Exporter teu acan tiasa nampi dukungan komunitas anu cukup. Cassandra Exporter masih henteu ngadukung seueur versi Cassandra.
2. Anjeun tiasa ngajalankeun salaku javaagent ku nambahkeun bandéra a -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. Aya hiji keur manehna dashboad nyukupan, anu henteu cocog sareng Cassandra Exporter.

3. Milih primitif Kubernetes

Numutkeun struktur klaster Cassandra di luhur, hayu urang coba narjamahkeun sadayana anu dijelaskeun di dinya kana terminologi Kubernetes:

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

Tétéla sababaraha éntitas tambahan leungit pikeun ngatur sakabéh klaster Cassandra sakaligus. Tapi upami aya anu teu aya, urang tiasa nyiptakeunana! Kubernetes boga mékanisme pikeun nangtukeun sumberdaya sorangan pikeun tujuan ieu - Harti Sumberdaya Adat.

Ngadéklarasikeun sumberdaya tambahan pikeun log sareng panggeuing

Tapi Custom Resource sorangan henteu hartosna nanaon: barina ogé, merlukeun anu ngaturna. Anjeun bisa jadi kudu neangan pitulung operator Kubernetes...

4. Idéntifikasi polong

Dina paragraf di luhur, urang sapuk yén hiji titik Cassandra bakal sarua jeung hiji pod di Kubernetes. Tapi alamat IP tina pods bakal béda unggal waktos. Jeung idéntifikasi titik di Cassandra dumasar kana alamat IP ... Tétéla yén sanggeus unggal ngaleupaskeun pod a, klaster Cassandra bakal nambahan titik anyar.

Aya jalan kaluar, teu ngan hiji:

1. Urang bisa nyimpen rékaman ku identifiers host (UUIDs nu uniquely ngaidentipikasi instansi Cassandra) atawa ku alamat IP tur nyimpen eta sadayana dina sababaraha struktur / tabel. Metoda ieu ngagaduhan dua kalemahan utama:
   • Résiko kaayaan balapan lumangsung lamun dua titik ragrag sakaligus. Saatos naékna, titik Cassandra sakaligus bakal menta alamat IP tina méja sareng bersaing pikeun sumber anu sami.
   • Lamun titik Cassandra leungit data na, urang moal deui bisa ngaidentipikasi eta.
2. Solusi kadua sigana kawas hack leutik, tapi kumaha oge: urang bisa nyieun Service kalawan ClusterIP pikeun tiap titik Cassandra. Masalah sareng palaksanaan ieu:
   • Upami aya seueur titik dina klaster Cassandra, urang kedah nyiptakeun seueur Jasa.
   • Fitur ClusterIP dilaksanakeun via iptables. Ieu bisa jadi masalah lamun klaster Cassandra boga loba (1000 ... atawa malah 100?) titik. Sanajan balancing dumasar kana IPVS bisa ngajawab masalah ieu.
3. Solusi katilu nyaéta ngagunakeun jaringan titik pikeun titik Cassandra tinimbang jaringan pods khusus ku cara ngaktipkeun setelan hostNetwork: true. Metoda ieu maksakeun sababaraha watesan:
   • Pikeun ngaganti unit. Perlu yén titik anyar kedah gaduh alamat IP anu sami sareng anu sateuacana (dina méga sapertos AWS, GCP ieu ampir teu mungkin dilakukeun);
   • Ngagunakeun jaringan titik klaster, urang ngawitan bersaing pikeun sumber jaringan. Ku alatan éta, nempatkeun leuwih ti hiji pod kalawan Cassandra dina hiji titik klaster bakal jadi masalah.

5. Nyadangkeun

Simkuring hoyong ngahemat versi pinuh ku data hiji titik Cassandra tunggal on jadwal a. Kubernetes nyadiakeun fitur merenah ngagunakeun CronJob, Tapi didieu Cassandra dirina nempatkeun spoke dina roda kami.

Hayu atuh ngingetan yén Cassandra nyimpen sababaraha data dina mémori. Pikeun nyieun cadangan lengkep, anjeun peryogi data tina mémori (Métables) pindah ka disk (SSTables). Dina titik ieu, titik Cassandra eureun narima sambungan, sagemblengna shutting turun tina klaster.

Sanggeus ieu, cadangan dihapus (snapshot) sareng skéma disimpen (spasi konci). Teras tétéla yén ngan ukur cadangan henteu masihan kami nanaon: urang kedah nyimpen pangidentifikasi data anu tanggung jawab titik Cassandra - ieu mangrupikeun token khusus.

Distribusi token pikeun ngaidentipikasi naon data titik Cassandra tanggung jawab

Conto naskah pikeun nyandak cadangan Cassandra ti Google di Kubernetes tiasa dipendakan di link ieu. Hiji-hijina titik anu naskah henteu dipertimbangkeun nyaéta ngareset data kana titik sateuacan nyandak snapshot. Nyaéta, cadangan dilakukeun sanés pikeun kaayaan ayeuna, tapi pikeun kaayaan anu langkung awal. Tapi ieu mantuan teu nyandak titik kaluar tina operasi, nu sigana pisan 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 skrip bash pikeun nyandak cadangan tina hiji titik Cassandra

Solusi siap pikeun Cassandra di Kubernetes

Naon anu ayeuna dianggo pikeun nyebarkeun Cassandra di Kubernetes sareng mana anu paling cocog sareng syarat anu dipasihkeun?

1. Solusi dumasar kana StatefulSet atanapi Helm grafik

Ngagunakeun fungsi StatefulSets dasar pikeun ngajalankeun hiji klaster Cassandra mangrupakeun pilihan alus. Nganggo témplat Helm chart sareng Go, anjeun tiasa nyayogikeun pangguna antarbeungeut anu fleksibel pikeun nyebarkeun Cassandra.

Ieu biasana tiasa dianggo saé ... dugi ka kajadian anu teu kaduga, sapertos gagalna titik. Alat Kubernetes standar ngan saukur teu tiasa merhatikeun sadaya fitur anu dijelaskeun di luhur. Salaku tambahan, pendekatan ieu terbatas pisan dina sabaraha éta tiasa diperpanjang pikeun kagunaan anu langkung kompleks: ngagantian node, cadangan, pamulihan, monitoring, jsb.

Perwakilan:

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

Duanana grafik anu sarua alus, tapi tunduk kana masalah ditétélakeun di luhur.

2. Solusi dumasar kana Kubernetes Operator

Pilihan sapertos kitu langkung narik sabab nyayogikeun kasempetan anu ageung pikeun ngatur klaster. Pikeun ngarancang operator Cassandra, sapertos pangkalan data anu sanés, pola anu saé sapertos Sidecar <-> Controller <-> CRD:

Skéma manajemén titik dina operator Cassandra dirancang ogé

Hayu urang tingali operator anu aya.

1. Cassandra-operator ti instaclustr

• GitHub
• Kesiapan: Alfa
• Lisensi: Apache 2.0
• Dilaksanakeun dina: Java

Ieu memang proyek pisan ngajangjikeun sarta aktip ngamekarkeun ti parusahaan nu nawarkeun junun deployments Cassandra. Éta, sakumaha anu dijelaskeun di luhur, nganggo wadah sidecar anu nampi paréntah via HTTP. Ditulis dina Java, éta kadang kakurangan fungsionalitas anu langkung maju tina perpustakaan klien-go. Ogé, operator teu ngarojong rak béda pikeun hiji Datacenter.

Tapi operator boga kaunggulan kayaning rojongan pikeun monitoring, tingkat luhur manajemén klaster maké CRD, komo dokuméntasi pikeun nyieun cadangan.

2. Navigator ti Jetstack

• GitHub
• Kesiapan: Alfa
• Lisensi: Apache 2.0
• Dilaksanakeun di: Golang

Pernyataan anu dirancang pikeun nyebarkeun DB-as-a-Service. Ayeuna ngadukung dua pangkalan data: Elasticsearch sareng Cassandra. Cai mibanda solusi metot kayaning kontrol aksés database via RBAC (pikeun ieu boga navigator-apiserver misah sorangan). Proyék anu pikaresepeun anu patut ditingali, tapi komitmen terakhir dilakukeun sataun satengah katukang, anu jelas ngirangan poténsina.

3. Cassandra-operator ku vgkowski

• GitHub
• Kesiapan: Alfa
• Lisensi: Apache 2.0
• Dilaksanakeun di: Golang

Aranjeunna henteu nganggap éta "serius", sabab komitmen terakhir pikeun gudang éta langkung ti sataun katukang. Pangembangan operator ditinggalkeun: versi panganyarna tina Kubernetes dilaporkeun salaku dirojong nyaéta 1.9.

4. Cassandra-operator ku Rook

• GitHub
• Kesiapan: Alfa
• Lisensi: Apache 2.0
• Dilaksanakeun di: Golang

Hiji operator anu ngembangkeun teu progressing gancang sakumaha urang hoyong. Cai mibanda struktur CRD well-dipikir-kaluar pikeun manajemén klaster, solves masalah identifying titik ngagunakeun Service kalawan ClusterIP (sarua "hack") ... tapi éta sakabéh pikeun ayeuna. Ayeuna teu aya monitoring atanapi cadangan out of the box (ku jalan kitu, kami pikeun ngawaskeun nyandak sorangan). Titik anu pikaresepeun nyaéta anjeun ogé tiasa nyebarkeun ScyllaDB nganggo operator ieu.

NB: Kami nganggo operator ieu kalayan modifikasi leutik dina salah sahiji proyék kami. Teu aya masalah anu ditingali dina padamelan operator salami periode operasi (~ 4 bulan operasi).

5. CassKop ti Oranyeu

• GitHub
• Kesiapan: Alfa
• Lisensi: Apache 2.0
• Dilaksanakeun di: Golang

Operator bungsu dina daptar: komitmen munggaran dilakukeun dina 23 Mei 2019. Ayeuna parantos aya di arsenal na sajumlah ageung fitur tina daptar kami, langkung rinci anu tiasa dipendakan dina gudang proyék. operator diwangun dina dasar populér operator-sdk. Ngarojong ngawaskeun out of the box. Beda utama ti operator séjén nyaéta pamakéan plugin CassKop, dilaksanakeun dina Python jeung dipaké pikeun komunikasi antara titik Cassandra.

papanggihan

Jumlah pendekatan sareng pilihan kamungkinan pikeun porting Cassandra ka Kubernetes nyarioskeun nyalira: topikna aya dina paménta.

Dina tahap ieu, anjeun tiasa nyobian salah sahiji anu di luhur dina bahaya sareng résiko anjeun nyalira: teu aya pamekar anu ngajamin 100% operasi solusina dina lingkungan produksi. Tapi geus, loba produk kasampak ngajangjikeun pikeun nyobaan ngagunakeun dina bangku pangwangunan.

Jigana dina mangsa nu bakal datang awéwé ieu dina kapal bakal datang dina gunana!

PS

Baca ogé dina blog urang:

• «Migrasi lancar MongoDB ka Kubernetes";
• «Seamless RabbitMQ ka migrasi Kubernetes";
• «Basis data sareng Kubernetes (review sareng laporan video)";
• «Tip & trik K8s: Ngagancangkeun bootstrap pikeun database ageung".

sumber: www.habr.com