Kassandraning Kubernetesga ko'chishi: xususiyatlar va echimlar

Biz muntazam ravishda Apache Cassandra ma'lumotlar bazasiga va uni Kubernetesga asoslangan infratuzilmada ishlatish zarurligiga duch kelamiz. Ushbu materialda biz Kassandrani K8-ga o'tkazish uchun zarur qadamlar, mezonlar va mavjud echimlar (shu jumladan operatorlar haqida umumiy ma'lumot) haqidagi tasavvurimizni baham ko'ramiz.

“Kim ayolni boshqara olsa, davlatni ham boshqara oladi”

Kassandra kim? Bu katta hajmdagi ma'lumotlarni boshqarish uchun mo'ljallangan taqsimlangan saqlash tizimi bo'lib, ayni paytda bitta nosozliksiz yuqori mavjudlikni ta'minlaydi. Loyiha uzoq kirishni talab qilmaydi, shuning uchun men faqat ma'lum bir maqola kontekstida tegishli bo'lgan Kassandraning asosiy xususiyatlarini beraman:

• Kassandra Java tilida yozilgan.
• Kassandra topologiyasi bir necha darajalarni o'z ichiga oladi:
  • Tugun - bitta joylashtirilgan Cassandra nusxasi;
  • Rack - bu bir xil ma'lumotlar markazida joylashgan ba'zi xususiyatlar bilan birlashtirilgan Cassandra nusxalari guruhi;
  • Datacenter - bitta ma'lumot markazida joylashgan Cassandra misollarining barcha guruhlari to'plami;
  • Klaster barcha ma'lumotlar markazlarining to'plamidir.
• Kassandra tugunni aniqlash uchun IP-manzildan foydalanadi.
• Yozish va o'qish operatsiyalarini tezlashtirish uchun Kassandra ma'lumotlarning bir qismini operativ xotirada saqlaydi.

Endi - Kubernetesga haqiqiy potentsial o'tish.

O'tkazish uchun tekshirish ro'yxati

Kassandraning Kubernetesga ko'chishi haqida gapirganda, biz ko'chib o'tish bilan uni boshqarish qulayroq bo'ladi deb umid qilamiz. Buning uchun nima talab qilinadi, bunga nima yordam beradi?

1. Ma'lumotlarni saqlash

Yuqorida aytib o'tilganidek, Cassanda ma'lumotlarning bir qismini RAM-da saqlaydi Memtable. Ammo diskda saqlanadigan ma'lumotlarning yana bir qismi bor - shaklda SSTable. Ushbu ma'lumotlarga ob'ekt qo'shiladi Jurnalni topshirish — barcha tranzaksiyalarning yozuvlari, ular ham diskda saqlanadi.

Kassandrada tranzaksiya diagrammasini yozing

Kubernetes-da biz ma'lumotlarni saqlash uchun PersistentVolume-dan foydalanishimiz mumkin. Tasdiqlangan mexanizmlar tufayli Kubernetes-da ma'lumotlar bilan ishlash har yili osonlashmoqda.

Biz har bir Cassandra podasiga o'zimizning Persistent Volume-ni ajratamiz

Shuni ta'kidlash kerakki, Kassandraning o'zi buning uchun o'rnatilgan mexanizmlarni taklif qilib, ma'lumotlarni takrorlashni nazarda tutadi. Shuning uchun, agar siz ko'p sonli tugunlardan Cassandra klasterini qurayotgan bo'lsangiz, ma'lumotlarni saqlash uchun Ceph yoki GlusterFS kabi taqsimlangan tizimlardan foydalanishga hojat yo'q. Bunday holda, ma'lumotlarni asosiy diskda saqlash mantiqiy bo'ladi mahalliy doimiy disklar yoki o'rnatish hostPath.

Yana bir savol shundaki, siz har bir xususiyat bo'limi uchun ishlab chiquvchilar uchun alohida muhit yaratmoqchimisiz. Bunday holda, to'g'ri yondashuv bitta Cassandra tugunini ko'tarish va ma'lumotlarni taqsimlangan saqlashda saqlash bo'ladi, ya'ni. qayd etilgan Ceph va GlusterFS sizning tanlovingiz bo'ladi. Keyin ishlab chiquvchi Kuberntes klaster tugunlaridan biri yo'qolgan taqdirda ham test ma'lumotlarini yo'qotmasligiga ishonch hosil qiladi.

2. Monitoring

Kubernetesda monitoringni amalga oshirish uchun deyarli shubhasiz tanlov bu Prometeydir (bu haqda biz maqolada batafsil gaplashdik tegishli hisobot). Kassandra Prometey uchun o'lchovlarni eksport qiluvchilar bilan qanday ishlaydi? Va Grafana uchun mos asboblar paneli bilan nima muhimroq?

Kassandra uchun Grafanadagi grafiklarning paydo bo'lishiga misol

Faqat ikkita eksportchi mavjud: jmx_exporter и cassandra_exporter.

Biz o'zimiz uchun birinchisini tanladik, chunki:

1. JMX Exporter o'sib bormoqda va rivojlanmoqda, Cassandra Exporter esa etarli darajada jamoatchilik yordamini ololmadi. Cassandra Exporter hali ham Cassandra-ning aksariyat versiyalarini qo'llab-quvvatlamaydi.
2. Siz bayroqni qo'shish orqali uni javaagent sifatida ishga tushirishingiz mumkin -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. Uning uchun bittasi bor etarli boshqaruv paneli, bu Cassandra Exporter bilan mos kelmaydi.

3. Kubernetes primitivlarini tanlash

Kassandra klasterining yuqoridagi tuzilishiga ko'ra, keling, u erda tasvirlangan hamma narsani Kubernetes terminologiyasiga tarjima qilishga harakat qilaylik:

• Kassandra tugun → Pod
• Cassandra Rack → StatefulSet
• Cassandra Datacenter → StatefulSets-dan hovuz
• Kassandra klasteri → ???

Ma'lum bo'lishicha, bir vaqtning o'zida butun Cassandra klasterini boshqarish uchun qo'shimcha ob'ekt etishmayapti. Ammo agar biror narsa mavjud bo'lmasa, biz uni yaratishimiz mumkin! Kubernetes bu maqsadda o'z resurslarini aniqlash mexanizmiga ega - Maxsus manba ta'riflari.

Jurnallar va ogohlantirishlar uchun qo'shimcha resurslarni e'lon qilish

Lekin Custom Resursning o'zi hech narsani anglatmaydi: axir, bu talab qiladi boshqaruvchi. Sizga yordam so'rash kerak bo'lishi mumkin Kubernetes operatori...

4. Po‘choqlarni aniqlash

Yuqoridagi paragrafda biz bitta Kassandra tugunining Kubernetesda bitta podkastga teng kelishiga kelishib oldik. Ammo podkastlarning IP manzillari har safar boshqacha bo'ladi. Kassandradagi tugunni aniqlash esa IP-manzilga asoslanadi... Ma’lum bo‘lishicha, har bir podani olib tashlangandan so‘ng Cassandra klasteriga yangi tugun qo‘shiladi.

Bitta emas, chiqish yo'li bor:

1. Biz qaydlarni xost identifikatorlari (Cassandra misollarini noyob identifikatsiya qiluvchi UUIDlar) yoki IP manzillar bo'yicha saqlashimiz va barchasini ba'zi tuzilmalar/jadvallarda saqlashimiz mumkin. Usul ikkita asosiy kamchilikka ega:
   • Ikki tugun bir vaqtning o'zida tushib qolsa, poyga holatining paydo bo'lish xavfi. Ko'tarilgandan so'ng, Cassandra tugunlari bir vaqtning o'zida jadvaldan IP-manzilni so'raydi va bir xil resurs uchun raqobatlashadi.
   • Agar Cassandra tugunlari o'z ma'lumotlarini yo'qotgan bo'lsa, biz endi uni aniqlay olmaymiz.
2. Ikkinchi yechim kichik buzish kabi ko'rinadi, ammo shunga qaramay: biz har bir Cassandra tuguniga ClusterIP bilan xizmat yaratishimiz mumkin. Ushbu amaliyot bilan bog'liq muammolar:
   • Agar Cassandra klasterida tugunlar ko'p bo'lsa, biz ko'plab xizmatlarni yaratishimiz kerak bo'ladi.
   • ClusterIP xususiyati iptables orqali amalga oshiriladi. Agar Cassandra klasterida ko'p (1000... yoki hatto 100?) tugun bo'lsa, bu muammoga aylanishi mumkin. Garchi IPVS asosida muvozanatlash bu muammoni hal qila oladi.
3. Uchinchi yechim - sozlashni yoqish orqali maxsus pods tarmog'i o'rniga Cassandra tugunlari uchun tugunlar tarmog'idan foydalanish. hostNetwork: true. Ushbu usul ma'lum cheklovlarni qo'yadi:
   • Birliklarni almashtirish uchun. Yangi tugun avvalgisi bilan bir xil IP-manzilga ega bo'lishi kerak (AWS, GCP kabi bulutlarda buni qilish deyarli mumkin emas);
   • Klaster tugunlari tarmog'idan foydalanib, biz tarmoq resurslari uchun raqobatlasha boshlaymiz. Shuning uchun, bitta klaster tuguniga Kassandra bilan bir nechta podkastlarni joylashtirish muammoli bo'ladi.

5. Zaxira nusxalari

Biz bitta Cassandra tugunining ma'lumotlarining to'liq versiyasini jadvalda saqlamoqchimiz. Kubernetes foydalanish uchun qulay xususiyatni taqdim etadi CronJob, lekin bu erda Kassandraning o'zi bizning g'ildiraklarimizga spiker qo'yadi.

Eslatib o'taman, Kassandra ma'lumotlarning bir qismini xotirada saqlaydi. To'liq zaxira nusxasini yaratish uchun sizga xotiradan ma'lumot kerak (Memtables) diskka o'tish (SSTables). Ushbu nuqtada, Kassandra tuguni ulanishlarni qabul qilishni to'xtatadi, klasterdan butunlay o'chadi.

Shundan so'ng, zaxira o'chiriladi (surat) va sxema saqlanadi (kalit maydoni). Va keyin ma'lum bo'ldiki, shunchaki zaxira nusxasi bizga hech narsa bermaydi: biz Cassandra tuguni javobgar bo'lgan ma'lumotlar identifikatorlarini saqlashimiz kerak - bular maxsus belgilar.

Cassandra tugunlari qanday ma'lumotlar uchun javobgar ekanligini aniqlash uchun tokenlarni taqsimlash

Kubernetes-da Google-dan Cassandra zaxira nusxasini olish uchun misol skriptini quyidagi manzilda topishingiz mumkin Ushbu havola. Skript e'tiborga olinmaydigan yagona nuqta - suratga olishdan oldin tugunga ma'lumotlarni qayta o'rnatish. Ya'ni, zaxira joriy holat uchun emas, balki biroz oldingi holat uchun amalga oshiriladi. Ammo bu tugunni ishdan chiqarmaslikka yordam beradi, bu juda mantiqiy ko'rinadi.

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

Bitta Cassandra tugunidan zaxira nusxasini olish uchun bash skriptiga misol

Kubernetesdagi Kassandra uchun tayyor echimlar

Hozirda Kassandrani Kubernetesda joylashtirish uchun nima ishlatiladi va ulardan qaysi biri berilgan talablarga eng mos keladi?

1. StatefulSet yoki Helm diagrammalariga asoslangan yechimlar

Cassandra klasterini ishga tushirish uchun asosiy StatefulSets funksiyalaridan foydalanish yaxshi variantdir. Helm chart va Go shablonlaridan foydalanib, foydalanuvchiga Cassandra-ni joylashtirish uchun moslashuvchan interfeysni taqdim etishingiz mumkin.

Bu odatda yaxshi ishlaydi... tugun ishdan chiqishi kabi kutilmagan narsa sodir bo'lguncha. Standart Kubernetes vositalari yuqorida tavsiflangan barcha xususiyatlarni hisobga olmaydi. Bundan tashqari, ushbu yondashuv yanada murakkab foydalanish uchun qanchalik kengaytirilishi mumkinligi bilan cheklangan: tugunni almashtirish, zaxiralash, tiklash, monitoring va hk.

Vakillar:

• Asosiy Helm omboridan diagramma;
• Bitnami dan diagramma.

Ikkala diagramma ham bir xil darajada yaxshi, lekin yuqorida tavsiflangan muammolarga bog'liq.

2. Kubernetes Operatoriga asoslangan yechimlar

Bunday variantlar qiziqroq, chunki ular klasterni boshqarish uchun keng imkoniyatlar yaratadi. Cassandra operatorini loyihalash uchun, boshqa ma'lumotlar bazasi kabi, yaxshi namuna Sidecar <-> Controller <-> CRD ga o'xshaydi:

Yaxshi ishlab chiqilgan Cassandra operatorida tugunlarni boshqarish sxemasi

Keling, mavjud operatorlarni ko'rib chiqaylik.

1. Cassandra-operator instaclustr

• GitHub
• Tayyorlik: Alfa
• Litsenziya: Apache 2.0
• Amalga oshirilgan: Java

Bu haqiqatan ham Cassandra-ni boshqariladigan joylashtirishni taklif qiladigan kompaniyaning juda istiqbolli va faol rivojlanayotgan loyihasidir. Yuqorida aytib o'tilganidek, u HTTP orqali buyruqlarni qabul qiladigan yonbosh konteyneridan foydalanadi. Java-da yozilgan bo'lib, u ba'zan mijoz-go kutubxonasining yanada ilg'or funksiyalariga ega emas. Bundan tashqari, operator bitta Datacenter uchun turli Raklarni qo'llab-quvvatlamaydi.

Ammo operator monitoringni qo'llab-quvvatlash, CRD yordamida yuqori darajadagi klasterlarni boshqarish va hatto zaxira nusxalarini yaratish uchun hujjatlar kabi afzalliklarga ega.

2. Jetstack-dan navigator

• GitHub
• Tayyorlik: Alfa
• Litsenziya: Apache 2.0
• Amalga oshirilgan: Golang

DB-as-a-Service-ni joylashtirish uchun mo'ljallangan bayonot. Hozirda ikkita ma'lumotlar bazasini qo'llab-quvvatlaydi: Elasticsearch va Cassandra. U RBAC orqali ma'lumotlar bazasiga kirishni boshqarish kabi qiziqarli echimlarga ega (buning uchun u o'zining alohida navigator-apiserveriga ega). Qiziqarli loyiha, uni diqqat bilan ko'rib chiqishga arziydi, lekin oxirgi majburiyat bir yarim yil oldin qilingan, bu uning salohiyatini aniq pasaytiradi.

3. Kassandra-operator vgkowski tomonidan

• GitHub
• Tayyorlik: Alfa
• Litsenziya: Apache 2.0
• Amalga oshirilgan: Golang

Ular buni "jiddiy" deb hisoblamadilar, chunki omborga so'nggi majburiyat bir yildan ko'proq vaqt oldin bo'lgan. Operatorni ishlab chiqish to'xtatildi: Kubernetesning eng so'nggi versiyasi qo'llab-quvvatlangani xabar qilingan 1.9.

4. Rukning Kassandra-operatori

• GitHub
• Tayyorlik: Alfa
• Litsenziya: Apache 2.0
• Amalga oshirilgan: Golang

Rivojlanishi biz xohlaganchalik tez rivojlanmayotgan operator. U klasterni boshqarish uchun puxta o'ylangan CRD tuzilmasiga ega, ClusterIP bilan Service (xuddi shu "hack") yordamida tugunlarni aniqlash muammosini hal qiladi... lekin hozircha hammasi. Hozirda hech qanday monitoring yoki zaxira nusxalari mavjud emas (Aytgancha, biz monitoring uchunmiz o'zimiz oldik). Qizig'i shundaki, siz ushbu operator yordamida ScyllaDB ni ham o'rnatishingiz mumkin.

Eslatma: Biz ushbu operatorni loyihalarimizdan birida kichik o'zgartirishlar bilan ishlatganmiz. Operator ishining butun muddati davomida (~4 oylik ish) hech qanday muammo sezilmadi.

5. Orangedan CassKop

• GitHub
• Tayyorlik: Alfa
• Litsenziya: Apache 2.0
• Amalga oshirilgan: Golang

Ro‘yxatdagi eng yosh operator: birinchi majburiyat 23-yil 2019-mayda amalga oshirilgan. Hozirda u o'z arsenalida bizning ro'yxatimizdan ko'plab funktsiyalarga ega, ularning batafsil ma'lumotlarini loyiha omborida topish mumkin. Operator mashhur operator-sdk asosida qurilgan. Qutidan tashqari monitoringni qo'llab-quvvatlaydi. Boshqa operatorlardan asosiy farqi foydalanishda CassKop plagini, Python-da amalga oshirilgan va Cassandra tugunlari o'rtasidagi aloqa uchun ishlatiladi.

topilmalar

Kassandrani Kubernetesga o'tkazishning yondashuvlari va mumkin bo'lgan variantlari o'zi uchun gapiradi: mavzu talabga ega.

Ushbu bosqichda siz yuqoridagilardan birini o'zingizning xavf-xataringiz va xavf-xataringiz bilan sinab ko'rishingiz mumkin: ishlab chiquvchilarning hech biri ishlab chiqarish muhitida o'z yechimining 100% ishlashiga kafolat bermaydi. Ammo allaqachon ko'plab mahsulotlar ishlab chiqarish dastgohlarida foydalanishga umidvor ko'rinadi.

Menimcha, kelajakda kemadagi bu ayol yordamga keladi!

PS

Shuningdek, bizning blogimizda o'qing:

• «MongoDB-ning Kubernetes-ga uzluksiz ko'chishi";
• «RabbitMQ-ning Kubernetes-ga uzluksiz ko'chishi";
• «Ma'lumotlar bazalari va Kubernetes (ko'rib chiqish va video hisobot)";
• «K8s maslahatlari va fokuslari: Katta ma'lumotlar bazalari uchun yuklashni tezlashtirish".

Manba: www.habr.com