Кассандрагийн Кубернетес рүү шилжих хөдөлгөөн: онцлог, шийдэл

Бид Apache Cassandra мэдээллийн сантай байнга тулгардаг бөгөөд үүнийг Кубернетес дээр суурилсан дэд бүтцийн хүрээнд ажиллуулах шаардлагатай байдаг. Энэ материалд бид Кассандра-г K8-д шилжүүлэхэд шаардлагатай алхмууд, шалгуурууд болон одоо байгаа шийдлүүдийн талаарх (операторуудын тоймыг оруулаад) үзэл бодлоо хуваалцах болно.

"Эмэгтэй хүнийг захирч чадах хүн төрийг ч удирдаж чадна"

Кассандра гэж хэн бэ? Энэ нь их хэмжээний өгөгдлийг удирдахад зориулагдсан хуваарилагдсан хадгалах систем бөгөөд нэг цэгийн доголдолгүйгээр өндөр хүртээмжтэй байх боломжийг олгодог. Төсөл нь урт хугацааны танилцуулга шаарддаггүй тул би зөвхөн Кассандрагийн тодорхой өгүүллийн хүрээнд хамаарах гол шинж чанаруудыг өгөх болно.

• Кассандра нь Java хэл дээр бичигдсэн байдаг.
• Кассандра топологи нь хэд хэдэн түвшинг агуулдаг.
  • Зангилаа - нэг байрлуулсан Кассандра жишээ;
  • Rack нь нэг дата төвд байрладаг, зарим шинж чанараараа нэгдсэн Кассандрагийн бүлэг юм;
  • Дата төв - нэг дата төвд байрлах Кассандрагийн бүх бүлгүүдийн цуглуулга;
  • Кластер бол бүх мэдээллийн төвүүдийн цуглуулга юм.
• Кассандра зангилааг тодорхойлохын тулд IP хаягийг ашигладаг.
• Бичих, унших ажиллагааг хурдасгахын тулд Кассандра зарим өгөгдлийг RAM-д хадгалдаг.

Одоо - Кубернетес рүү шилжих бодит боломж.

Шилжүүлгийг шалгах хуудас

Кассандра Кубернетес рүү нүүсэн тухай ярихдаа, нүүснээр үүнийг удирдахад илүү тохиромжтой болно гэж найдаж байна. Үүнд юу шаардагдах вэ, үүнд юу туслах вэ?

1. Мэдээлэл хадгалах

Өмнө дурьдсанчлан Кассанда өгөгдлийн нэг хэсгийг RAM-д хадгалдаг Memtable. Гэхдээ өгөгдлийн өөр нэг хэсэг нь дискэнд хадгалагддаг - хэлбэрээр SST боломжтой. Энэ өгөгдөлд байгууллага нэмэгдсэн Бүртгэлийн бүртгэл - бүх гүйлгээний бүртгэлийг дискэнд хадгалдаг.

Кассандра хэлээр гүйлгээний диаграм бич

Kubernetes-д бид өгөгдөл хадгалахын тулд PersistentVolume ашиглаж болно. Батлагдсан механизмын ачаар Кубернетес дэх өгөгдөлтэй ажиллах нь жил бүр хялбар болж байна.

Бид Cassandra pod тус бүрт өөрийн PersistentVolume-г хуваарилах болно

Кассандра өөрөө өгөгдлийн хуулбарыг хэлдэг бөгөөд үүнд зориулж суурилуулсан механизмуудыг санал болгодог гэдгийг анхаарах нь чухал юм. Тиймээс, хэрэв та олон тооны зангилаанаас Кассандра кластер барьж байгаа бол өгөгдөл хадгалахад Ceph эсвэл GlusterFS гэх мэт тархсан системийг ашиглах шаардлагагүй болно. Энэ тохиолдолд өгөгдлийг хост диск дээр хадгалах нь логик юм локал байнгын дискүүд эсвэл угсрах hostPath.

Өөр нэг асуулт бол та онцлог салбар бүрт хөгжүүлэгчдэд зориулж тусдаа орчин бий болгохыг хүсч байна уу. Энэ тохиолдолд зөв хандлага нь нэг Кассандра зангилаа босгож, өгөгдлийг хуваарилагдсан хадгалах санд хадгалах явдал юм. дурдсан Ceph болон GlusterFS нь таны сонголт байх болно. Дараа нь хөгжүүлэгч Kuberntes кластерийн зангилаа алдагдсан ч туршилтын өгөгдлийг алдахгүй гэдэгт итгэлтэй байх болно.

2. Хяналт

Кубернетес дэх мониторингийг хэрэгжүүлэх бараг маргаангүй сонголт бол Прометей юм (бид энэ талаар дэлгэрэнгүй ярьсан холбогдох тайлан). Кассандра Prometheus-ийн хэмжигдэхүүн экспортлогчидтой хэрхэн ажиллаж байна вэ? Grafana-д тохирох хяналтын самбартай бол юу нь илүү чухал вэ?

Кассандрагийн хувьд Графана дахь график гарч ирсэн жишээ

Зөвхөн хоёр экспортлогч байдаг: jmx_exporter и кассандра_экспортлогч.

Бид эхнийхийг нь сонгосон учир нь:

1. JMX Exporter нь өсч, хөгжиж байгаа бол Кассандра Экспорттер олон нийтийн дэмжлэгийг хангалттай авч чадаагүй байна. Cassandra Exporter нь Кассандрагийн ихэнх хувилбаруудыг дэмждэггүй хэвээр байна.
2. Та туг нэмж javaagent болгон ажиллуулж болно -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. Түүний хувьд нэг байна хангалттай хяналтын самбар, энэ нь Кассандра Экспортлогчтой нийцэхгүй байна.

3. Kubernetes командуудыг сонгох

Кассандра кластерын дээрх бүтцийн дагуу тэнд тайлбарласан бүх зүйлийг Кубернетес нэр томъёонд орчуулахыг хичээцгээе.

• Кассандра зангилаа → Pod
• Кассандра өлгүүр → StatefulSet
• Cassandra Datacenter → StatefulSets-ийн сан
• Кассандра кластер → ???

Кассандра кластерийг бүхэлд нь нэг дор удирдах нэмэлт байгууллага дутуу байна. Гэхдээ хэрэв ямар нэг зүйл байхгүй бол бид үүнийг бүтээж чадна! Кубернетес энэ зорилгоор өөрийн нөөцийг тодорхойлох механизмтай байдаг. Тусгай нөөцийн тодорхойлолтууд.

Бүртгэл болон сэрэмжлүүлгийн нэмэлт нөөцийг зарлах

Гэхдээ Custom Resource нь өөрөө юу ч гэсэн үг биш: эцэст нь энэ нь шаарддаг хянагч. Та тусламж хүсэх хэрэгтэй байж магадгүй Kubernetes оператор...

4. Хонхорхойг тодорхойлох

Дээрх догол мөрөнд бид нэг Кассандра зангилаа нь Кубернетес дэх нэг подтой тэнцэнэ гэж тохиролцсон. Гэхдээ pods-ийн IP хаягууд бүр өөр өөр байх болно. Мөн Кассандра дахь зангилааг тодорхойлох нь IP хаяг дээр суурилдаг ... Подыг арилгах болгонд Кассандра кластерт шинэ зангилаа нэмэгдэх нь харагдаж байна.

Ганц нэг биш харин гарах гарц бий.

1. Бид бүртгэлийг хост танигч (Кассандрагийн тохиолдлуудыг өвөрмөц байдлаар тодорхойлдог UUID) эсвэл IP хаягаар хөтөлж, бүгдийг нь зарим бүтэц/хүснэгтэд хадгалах боломжтой. Энэ арга нь хоёр үндсэн сул талтай:
   • Хоёр зангилаа нэг дор унавал уралдааны нөхцөл үүсэх эрсдэл. Өсөлтийн дараа Кассандра зангилаанууд хүснэгтээс IP хаягийг нэгэн зэрэг хүсч, ижил нөөцийн төлөө өрсөлдөх болно.
   • Хэрэв Кассандра зангилаа өгөгдлөө алдсан бол бид үүнийг таних боломжгүй болно.
2. Хоёрдахь шийдэл нь жижиг хакердсан мэт санагдаж байгаа ч бид Кассандра зангилаа бүрт ClusterIP-тэй үйлчилгээ үүсгэж болно. Үүнийг хэрэгжүүлэхтэй холбоотой асуудлууд:
   • Хэрэв Кассандра кластерт олон зангилаа байгаа бол бид маш олон үйлчилгээ үүсгэх шаардлагатай болно.
   • ClusterIP функцийг iptables ашиглан хэрэгжүүлдэг. Кассандра кластер олон (1000... эсвэл бүр 100?) зангилаатай бол энэ нь асуудал болж хувирдаг. Хэдийгээр IPVS дээр суурилсан тэнцвэржүүлэх энэ асуудлыг шийдэж чадна.
3. Гурав дахь шийдэл нь тохиргоог идэвхжүүлж, тусгайлсан үүрний сүлжээний оронд Кассандра зангилааны зангилааны сүлжээг ашиглах явдал юм. hostNetwork: true. Энэ арга нь тодорхой хязгаарлалтуудыг тавьдаг:
   • Нэгжийг солихын тулд. Шинэ зангилаа нь өмнөхтэй ижил IP хаягтай байх шаардлагатай (AWS, GCP гэх мэт үүлэн дээр үүнийг хийх бараг боломжгүй);
   • Кластер зангилааны сүлжээг ашигласнаар бид сүлжээний нөөцийн төлөө өрсөлдөж эхэлдэг. Тиймээс нэг кластер зангилаа дээр Кассандратай нэгээс олон pod байрлуулах нь асуудалтай байх болно.

5. Нөөцлөлт

Бид нэг Кассандра зангилааны өгөгдлийн бүрэн хувилбарыг хуваарийн дагуу хадгалахыг хүсч байна. Kubernetes нь ашиглахад тохиромжтой функцээр хангадаг CronJob, гэхдээ энд Кассандра өөрөө бидний дугуйнд хигээс тавьдаг.

Кассандра зарим өгөгдлийг санах ойд хадгалдаг гэдгийг сануулъя. Бүрэн нөөцлөхийн тулд танд санах ойн өгөгдөл хэрэгтэй болно (Memtables) диск рүү шилжих (SSTables). Энэ үед Кассандра зангилаа холболтыг хүлээн авахаа больж, кластераас бүрэн унтарна.

Үүний дараа нөөцлөлтийг устгана (Хормын хувилбар) ба схем хадгалагдсан (товчлуурын зай). Тэгээд зүгээр л нөөцлөлт нь бидэнд юу ч өгдөггүй нь харагдаж байна: бид Кассандра зангилаа хариуцаж байсан өгөгдөл танигчийг хадгалах хэрэгтэй - эдгээр нь тусгай тэмдэг юм.

Кассандра зангилаа ямар өгөгдлийг хариуцаж байгааг тодорхойлох токенуудын хуваарилалт

Kubernetes дахь Google-ээс Кассандрагийн нөөц хуулбарыг авах жишээ скриптийг эндээс олж болно энэ холбоос. Скриптийг анхаарч үздэггүй цорын ганц зүйл бол агшин зуурын зургийг авахын өмнө зангилаа руу өгөгдлийг дахин тохируулах явдал юм. Өөрөөр хэлбэл, нөөцлөлтийг одоогийн төлөвт бус, харин арай өмнөх төлөвт зориулж хийдэг. Гэхдээ энэ нь зангилааг ажиллагаанаас гаргахгүй байхад тусалдаг бөгөөд энэ нь маш логик юм шиг санагддаг.

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

Нэг Кассандра зангилаанаас нөөцлөлт авах bash скриптийн жишээ

Кубернетес дэх Кассандрагийн бэлэн шийдлүүд

Одоогоор Кассандра-г Кубернетес-д байрлуулахад юу ашиглаж байгаа бөгөөд эдгээрийн аль нь өгөгдсөн шаардлагад хамгийн сайн тохирох вэ?

1. StatefulSet эсвэл Helm диаграм дээр суурилсан шийдлүүд

Кассандра кластерыг ажиллуулахын тулд StatefulSets үндсэн функцуудыг ашиглах нь сайн сонголт юм. Helm chart болон Go загваруудыг ашигласнаар та хэрэглэгчийг Кассандра-г байрлуулах уян хатан интерфейсээр хангах боломжтой.

Энэ нь ихэвчлэн хэвийн ажилладаг... зангилааны эвдрэл гэх мэт гэнэтийн зүйл тохиолдох хүртэл. Стандарт Kubernetes хэрэгслүүд нь дээр дурдсан бүх шинж чанарыг харгалзан үзэх боломжгүй юм. Нэмж дурдахад, зангилаа солих, нөөцлөх, сэргээх, хянах гэх мэт нарийн төвөгтэй хэрэглээнд энэ арга нь маш хязгаарлагдмал байдаг.

Төлөөлөгчид:

• Helm-ийн үндсэн агуулахын график;
• Битнамигийн график.

Хоёр график хоёулаа адилхан сайн боловч дээр дурдсан асуудлуудтай холбоотой.

2. Kubernetes Operator дээр суурилсан шийдлүүд

Ийм сонголтууд нь кластерийг удирдах өргөн боломжийг олгодог тул илүү сонирхолтой байдаг. Бусад өгөгдлийн сангийн нэгэн адил Кассандра операторыг зохион бүтээхэд сайн загвар нь Sidecar <-> Controller <-> CRD шиг харагдаж байна:

Сайн зохион бүтээсэн Кассандра оператор дахь зангилааны удирдлагын схем

Одоо байгаа операторуудыг харцгаая.

1. Cassandra-operator instaclustr

• GitHub
• Бэлэн байдал: Альфа
• Лиценз: Apache 2.0
• Хэрэгжүүлсэн: Java

Энэ бол үнэхээр Кассандрагийн удирдлагатай байршуулалтыг санал болгодог компанийн маш ирээдүйтэй, идэвхтэй хөгжиж буй төсөл юм. Энэ нь дээр дурдсанчлан HTTP-ээр дамжуулан тушаалуудыг хүлээн авдаг хажуугийн савыг ашигладаг. Java хэл дээр бичигдсэн энэ нь заримдаа client-go номын сангийн илүү дэвшилтэт функцээр дутмаг байдаг. Түүнчлэн, оператор нь нэг Дата төвийн өөр өөр тавиуруудыг дэмждэггүй.

Гэхдээ оператор нь хяналт-шинжилгээг дэмжих, CRD ашиглан өндөр түвшний кластерын удирдлага, нөөцлөх баримт бичиг зэрэг давуу талуудтай.

2. Jetstack-ийн навигатор

• GitHub
• Бэлэн байдал: Альфа
• Лиценз: Apache 2.0
• Хэрэгжүүлсэн: Голанг

Үйлчилгээ болгон DB-г ашиглахад зориулагдсан мэдэгдэл. Одоогоор Elasticsearch болон Cassandra гэсэн хоёр мэдээллийн санг дэмждэг. Энэ нь RBAC-ээр дамжуулан мэдээллийн санд хандах хяналт гэх мэт сонирхолтой шийдлүүдтэй байдаг (үүнд зориулж тусдаа навигатор-аписервер байдаг). Сонирхолтой төсөл бөгөөд үүнийг нарийвчлан авч үзэх нь зүйтэй боловч хамгийн сүүлийн амлалт нь жил хагасын өмнө хийгдсэн бөгөөд энэ нь түүний боломжийг тодорхой хэмжээгээр бууруулдаг.

3. Кассандра-оператор vgkowski

• GitHub
• Бэлэн байдал: Альфа
• Лиценз: Apache 2.0
• Хэрэгжүүлсэн: Голанг

Хамгийн сүүлд нэг жил гаруйн өмнө хадгалагдаж байсан тул тэд үүнийг "ноцтой" гэж үзээгүй. Операторын хөгжүүлэлтийг орхисон: дэмжигдсэн гэж мэдэгдсэн Kubernetes-ийн хамгийн сүүлийн хувилбар нь 1.9.

4. Кассандра-оператор Рүүк

• GitHub
• Бэлэн байдал: Альфа
• Лиценз: Apache 2.0
• Хэрэгжүүлсэн: Голанг

Хөгжил нь бидний хүссэн шиг хурдан урагшлахгүй байгаа оператор. Энэ нь кластерын менежментэд зориулсан сайтар бодож боловсруулсан CRD бүтэцтэй бөгөөд ClusterIP-тэй Service-ийг ашиглан зангилааг тодорхойлох асуудлыг шийддэг (ижил "хакер") ... гэхдээ одоохондоо энэ. Одоогоор ямар ч хяналт, нөөцлөлт байхгүй байна (Дашрамд хэлэхэд бид хяналт тавих зорилготой өөрсдөө авсан). Сонирхолтой зүйл бол та энэ операторыг ашиглан ScyllaDB-г ашиглаж болно.

Анхааруулга: Бид энэ операторыг нэг төсөлдөө бага зэрэг өөрчлөлт оруулан ашигласан. Ашиглалтын бүх хугацаанд (~4 сар) операторын ажилд ямар ч асуудал гараагүй.

5. Улбар шар өнгийн CassKop

• GitHub
• Бэлэн байдал: Альфа
• Лиценз: Apache 2.0
• Хэрэгжүүлсэн: Голанг

Жагсаалтын хамгийн залуу оператор: 23 оны 2019-р сарын XNUMX-нд анхны амлалтаа хийсэн. Одоо түүний арсенал дээр манай жагсаалтаас олон тооны функцууд байгаа бөгөөд тэдгээрийн дэлгэрэнгүй мэдээллийг төслийн репозитороос олж болно. Оператор нь алдартай оператор-sdk дээр суурилагдсан. Хайрцагнаас гадуур хяналтыг дэмждэг. Бусад операторуудаас гол ялгаа нь хэрэглээ юм CassKop залгаас, Python-д хэрэгжсэн бөгөөд Кассандра зангилааны хооронд харилцахад ашигладаг.

үр дүн нь

Кассандраг Кубернетес рүү шилжүүлэх хэд хэдэн арга, боломжит хувилбарууд нь өөрөө ярьдаг: сэдэв эрэлт хэрэгцээтэй байна.

Энэ үе шатанд та дээрх аргуудын аль нэгийг өөрийн эрсдэл, эрсдэлд оруулан туршиж үзэж болно: хөгжүүлэгчдийн аль нь ч үйлдвэрлэлийн орчинд өөрсдийн шийдлийг 100% ажиллуулах баталгаа өгдөггүй. Гэхдээ аль хэдийн олон бүтээгдэхүүн хөгжүүлэлтийн вандан сандал дээр ашиглахыг хичээх ирээдүйтэй харагдаж байна.

Ирээдүйд хөлөг онгоцон дээрх энэ эмэгтэй хэрэг болно гэж би бодож байна!

PS

Мөн манай блог дээрээс уншина уу:

• «MongoDB-г Kubernetes руу саадгүй шилжүүлэх";
• «RabbitMQ-г Kubernetes руу саадгүй шилжүүлэх";
• «Өгөгдлийн сан ба Кубернетес (хяналт, видео тайлан)";
• «K8s зөвлөмж ба заль мэх: Том өгөгдлийн сангийн ачааллыг хурдасгах".

Эх сурвалж: www.habr.com