Cassandra-nın Kubernetes-ə köçürülməsi: xüsusiyyətlər və həllər

Apache Cassandra verilmiş bir verilənlər bazasıdır və Kubernetlərdə infrastruktur çərçivəsində bunun istismarı ilə müntəzəm olaraq qarşılaşırıq. Bu materialda Cassandra'nın K8s-ə köçürülməsi üçün lazım olan addımlar, meyarlar və mövcud həllərin (operatorların icmalı da daxil olmaqla) ilə bağlı öz fikrimizi paylaşacağıq.

«Bir qadını idarə edə bilən, dövlətlə də başa çıxa bilər»

Bəs Cassandra kimdir? Bu, böyük verilənlər volümlərini idarə etmək üçün nəzərdə tutulmuş dağıdılmış bir saxlama sistemidir və bu vəziyyətdə yüksək əlçatarlığı təmin edir, tək bir təslim nöqtəsi olmadan. Layihənin uzun təqdimata ehtiyacı yoxdur, buna görə də yalnız bu məqalənin kontekstində aktual olan Cassandra'nın əsas xüsusiyyətlərini təqdim edəcəyəm:

• Cassandra Java-da yazılıb.
• Cassandra topology bir neçə səviyyədən ibarətdir:
  • Noqta — Cassandra'nın bir instance-dir;
  • Rak — hər hansı bir xüsusiyyətə görə birləşmiş Cassandra instance-larının qrupu, bir məlumat mərkəzində yerləşir;
  • Məlumat Mərkəzi — bir məlumat mərkəzində yerləşən bütün Cassandra instance-larının toplamıdır;
  • Klaster — bütün məlumat mərkəzlərinin toplamıdır.
• Cassandra, node-u identifikasiya etmək üçün IP ünvanından istifadə edir.
• Yazma və oxuma əməliyyatlarının sürətlənməsi üçün Cassandra'nın bir hissəsi verilənləri yadaşda saxlayır.

İndi, Kubernetes-də köçürməyə keçək.

Köçürmə üçün yoxlama siyahısı

Cassandra-nın Kubernetes-ə köçürülməsi ilə deyirik ki, köçürmə ilə idarə etməsi daha rahat olacaq. Bunun üçün nə tələb olunur, nələr kömək edəcək?

1. Verilənlər üçün mühafizə

Zatən izah edildiyi kimi, Cassandra'nın verilənlərin bir hissəsi yadaşda saxlanılır — Memtable. Lakin başqa bir hissə də var ki, bu, diski saxlayır — SSTable. Bu verilənlərə əlavə olaraq bir varlıq - Commit Log — diski saxlanılan bütün tranzaksiyaların qeydləri də daxildir.

Cassandra'da yazma tranzaksiyalarının sxemi

Kubernetes-də verilənləri saxlamaq üçün PersistentVolume istifadə edə bilərik. İllər ötdükcə, Kubernetes-də verilənlərlə işləmək daha da asanlaşır.

Hər Cassandra poduna öz PersistentVolume ayıracağıq

Qeyd etmək vacibdir ki, Cassandra özündə verilənlərin replikasiyasını nəzərdə tutur, bunun üçün daxili mexanizmlər təqdim edir. Belə ki, əgər siz böyük sayda node-udan ibarət Cassandra klasteri yaradırsınızsa, verilənləri saxlamaq üçün Ceph və ya GlusterFS kimi dağıdılmış sistemləri istifadə etməyə ehtiyac yoxdur. Bu halda, verilənləri node-un diski üzərində saxlamak məqbul olacaq yerli mühafizə diskleri və ya hostPath.

Başka bir soru, her bir feature dalı için geliştiriciler için ayrı bir ortam oluşturmak istiyorsanız ne olur? Bu durumda doğru yaklaşım, bir Cassandra düğümü kurmak ve verileri dağıtılmış depolama alanında saklamak olacaktır; yani bahsedilen Ceph ve GlusterFS sizin seçeneğiniz olacaktır. Böylece geliştirici, Kubernetes kümesindeki bir düğümü kaybetse bile test verilerini kaybetmeyeceğinden emin olacaktır.

2. İzleme

Kubernetes'te izleme gerçekleştirmek için neredeyse alternatifsiz bir seçim Prometheus'tur. (bunu ayrıntılı olarak , ilgili sunumda). Prometheus için metric exporter'leri ile Cassandra'nın durumu nedir? Ve daha da önemlisi, Grafana için uygun dashboard'lara sahip mi?

Cassandra için Grafana'daki grafiklerin dış görünümüne bir örnek

Exporterin sadece iki örneği vardır: jmx_exporter və cassandra_exporter.

Biz ilkini seçtik çünkü:

1. JMX Exporter büyüyor ve gelişiyor, oysa Cassandra Exporter yeterli topluluk desteği alamadı. Cassandra Exporter hâlâ Cassandra'nın çoğu sürümünü desteklemiyor.
2. Bunu bir javaagent olarak başlatmak mümkündür, -javaagent:<plugin-dir-name>\/cassandra-exporter.jar=--listen=:9180 ekleyerek..
3. Bunun için bir uygun dashboard, Cassandra Exporter ile uyumsuzdur.

3. Kubernetes Primitiflerinin Seçimi

Yukarıda bahsedilen Cassandra kümesi yapısına göre, orada yazılan her şeyi Kubernetes terminolojisine çevirmeye çalışalım:

• Cassandra Düğümü → Pod
• Cassandra Rafka → StatefulSet
• Cassandra Veri Merkezi → StatefulSets havuzu
• Cassandra Kümesi → ???

Sonuç olarak, Cassandra kümesini bir anda yönetmek için eksik olan bir ek varlık var. Ama eğer bir şey yoksa, onu yaratabiliriz! Kubernetes'te bunun için özel kaynakların tanım mekanizması vardır - Özel Kaynak Tanımları.

Günlükler ve bildirimler için ek kaynakların ilanı

Ama özel kaynak başlı başına bir anlam ifade etmez: çünkü onun için bir denetleyici gerekir.Belki de bir Kubernetes operatörünün yardımına başvurmak gerekebilir.…

4. Pod'ların Tanımlanması

Yukarıdaki maddede bir Cassandra düğümünün Kubernetes'teki bir pod ile eşdeğer olacağını kabul ettik. Ama pod'ların IP adresleri her seferinde farklı olacak. Cassandra'daki düğüm tanımlaması tam olarak IP adresine dayanıyor… Sonuç olarak, her pod silindiğinde Cassandra kümesi kendine yeni bir düğüm ekleyecektir.

Çözüm var ve hatta birden fazla:

1. Biz ev sahibi kimlikleri (Cassandra örneklerini kesinlikle tanımlayan UUID’ler) veya IP adresleriyle takip edebiliriz ve bunları bazı yapılar/tablolarda saklayabiliriz. Bu yöntemin iki temel dezavantajı var:
   • İki düğümün aniden çökmesi durumunda yarış koşusu riski. Düğüm yeniden başlatıldığında, Cassandra düğümleri IP adresini tabloya talep etmek için aynı anda gidecek ve aynı kaynağa rekabet edecekler.
   • Eğer Cassandra düğümü verilerini kaybederse, artık onu tanımlayamayacağız.
2. İkinci çözüm küçük bir hile gibi görünüyor ama yine de: her Cassandra düğümü için ClusterIP ile Service oluşturabiliriz. Bu uygulamanın sorunları:
   • Eğer Cassandra kümesinde çok sayıda düğüm varsa, çok fazla Service oluşturmak zorunda kalacağız.
   • ClusterIP özelliği iptables aracılığıyla uygulanmıştır. Bu, Cassandra kümesinde çok sayıda (1000... veya hatta 100?) düğüm olduğunda sorun olabilir. Ancak IPVS tabanlı yük dengelemenin bu sorunu çözme kapasitesi vardır.
3. Üçüncü çözüm — düğümler için bir pod ağı yerine düğüm ağını kullanmak ve ayarı etkinleştirmek. hostNetwork: true. Bu yöntemin belirli kısıtlamaları vardır:
   • Düğüm yedekleme için. Yeni düğümün öncekilerle aynı IP adresine sahip olması gerekir (AWS, GCP gibi bulutlarda bunu başarmak neredeyse imkansız);
   • Küme düğüm ağını kullanarak, ağ kaynakları için rekabete başlıyoruz. Bu nedenle, bir Cassandra pod'unu bir küme düğümü üzerinde çalıştırmak zorlu olacaktır.

5. Yedekler

Bir Cassandra düğümünün tam veri versiyonunu belirli bir programla saklamak istiyoruz. Kubernetes, bunu kullanarak kolay bir olanak sunar CronJob, ancak burada Cassandra kendi ayaklarına kurşun sıksın.

Cassandra'nın bazı verileri bellek içinde sakladığını hatırlatmak isterim. Tam bir yedek almak için, bellek verilerini (Memtables) diske (SSTables) taşımak gerekir. Bu anda, Cassandra düğümü bağlantıları almaktan vazgeçer ve kümeden tamamen çıkar.

Bundan sonra yedek alınır (snapshot) ve şema kaydedilir (keyspace). Ve burada yalnızca bir yedek almanın hiçbir anlamı olmadığını öğreniyoruz: Cassandra düğümünün sorumlu olduğu veri kimliklerini saklamak gerekir - bunlar özel tokenlerdir.

Cassandra düğümlerinin hangi verilerden sorumlu olduğunu belirlemek için token dağılımı

Google'dan Kubernetes'de Cassandra yedeği almak için bir örnek script bulabilirsiniz bağlantıya. Script'in göz önünde bulundurmadığı tek nokta, snapshot alınmadan önce düğümdeki verilerin sıfırlanmasıdır. Yani yedek, mevcut duruma göre değil, biraz önceki duruma yapılır. Ancak bu, düğümü devre dışı bırakmamayı sağlar ki bu da oldukça mantıklıdır.

set -eu

if [[ -z "$1" ]]; then
  info "Lütfen bir keyspace sağlayın"
  exit 1
fi

KEYSPACE="$1"

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

if [[ $? -ne 0 ]]; then
  echo "Snapshot alırken hata oluştu"
  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}"

Bir Cassandra düğümünden yedek almak için bir örnek bash scripti

Kubernetes'de Cassandra için hazır çözümler

Şu anda Cassandra'yı Kubernetes üzerinde dağıtmak için ne kullanılıyor ve bunlardan hangisi belirlenen gereksinimlere en uygun?

1. StatefulSet veya Helm şeması tabanlı çözümler

StatefulSets-in əsas funksiyalarını Cassandra klasterini işə salmaq üçün istifadə etmək yaxşı bir seçimdir. Helm chartı və Go şablonları istifadə edərək istifadəçiyə Cassandra-nı yerləşdirmək üçün çevik bir interfeys təqdim edə bilərsiniz.

Adətən bu, yaxşı işləyir... ta ki, gözlənilməz bir şey baş verməsin - məsələn, bir node-un çökməsi. Kubernetes-in standart alətləri yuxarıda təsvir olunan bütün xüsusiyyətləri nəzərə ala bilmir. Bundan əlavə, bu yanaşma daha mürəkkəb istifadəyə genişləndirilə biləcəyinə görə çox məhduddur: node dəyişdirmə, ehtiyat nüsxə, bərpa, monitorinq və s.

Nümayəndələr:

• Helm əsas repositoyarından chart;
• bitnami-dən chart.

Hər iki chart eyni dərəcədə yaxşıdır, lakin yuxarıda təsvir olunan problemlərə məruz qalır.

2. Kubernetes Operator-a əsaslanan həllər

Bu variantlar daha maraqlıdır, çünki klasteri idarə etmək üçün geniş imkanlar təqdim edir. Cassandra operatorunu dizayn etmək, digər hər hansı bir verilənlər bazası ilə yanaşı, yaxşı bir naxışdır: Sidecar Controller CRD:

Düzgün dizayn edilmiş Cassandra operatorundakı node-ların idarəetmə sxemi

Mövcud operatorları nəzərdən keçirək.

1. instaclustr-dan Cassandra-operator

• GitHub
• Hazırlıq: Alpha
• Lisenziya: Apache 2.0
• Java-da həyata keçirilmişdir

Bu, Cassandra-nı idarə olunan yerləşdirmələr təklif edən şirkətdən çox ümid verici və aktiv inkişaf edən bir layihədir. Yuxarıda təsvir edildiyi kimi, HTTP vasitəsilə komandaları qəbul edən sidecar konteynerini istifadə edir. Java-da yazıldığından, bəzən client-go kitabxanasının daha irəliləmiş funksiyalarından məhrum olur. Həmçinin, operator bir Datacenter üçün müxtəlif Racks-i dəstəkləmir.

Amma operatorun monitorinq dəstəyi, CRD vasitəsilə klasterin yüksək səviyyəli idarə olunması və hətta ehtiyat nüsxə götürməyə dair sənədli sənədləri kimi üstünlükləri var.

2. Jetstack-dan Navigator

• GitHub
• Hazırlıq: Alpha
• Lisenziya: Apache 2.0
• Golang-da həyata keçirilmişdir

DB-as-a-Service yerləşdirmək üçün nəzərdə tutulmuş operator. Hal-hazırda iki verilənlər bazasını dəstəkləyir: Elasticsearch və Cassandra. Məlumat bazasına giriş nəzarətini təmin etmək üçün RBAC vasitəsilə öz müstəqil navigator-apiserverini qaldırır. Gözlənilməli olan maraqlı bir layihədir; lakin, son komit 1.5 il əvvəl edilib, bu da onun potensialını açıqca azaldır.

3. vgkowski-dan Cassandra-operator

• GitHub
• Hazırlıq: Alpha
• Lisenziya: Apache 2.0
• Golang-da həyata keçirilmişdir

Onu "ciddi" qəbul etməmişik, çünki depozitorda son komit bir ildən çoxdur. Operatorun inkişafı dayandırılıb: dəstəklənən son versiya Kubernetes 1.9-dur.

4. Rook-dan Cassandra-operator

• GitHub
• Hazırlıq: Alpha
• Lisenziya: Apache 2.0
• Golang-da həyata keçirilmişdir

Operator, istədiyimiz qədər sürətlə inkişaf etmir. Klasteri idarə etmək üçün düşünülmüş CRD strukturu var, node-ların identifikasiyası məsələsini ClusterIP (elə həmin "hack") ilə həll edir... amma indiyədək bu qədərdir. Hazırda monitorinq və ehtiyat nüsxələr yoxdur (qeydlə, monitorinq üçün biz... özləri üstləniblər). Maraqlı bir məqam odur ki, bu operatorun köməyi ilə ScyllaDB də genişləndirilə bilər.

Qeyd: Bu operatoru kiçik düzəlişlərlə bir layihəmizdə istifadə etdik. İşləmə müddəti ərzində (~4 ay) operatorun işində heç bir problem aşkar edilməyib.

5. Orange tərəfindən CassKop

• GitHub
• Hazırlıq: Alpha
• Lisenziya: Apache 2.0
• Golang-da həyata keçirilmişdir

Hesabın siyahısındakı ən gənc operator: ilk komit 23 may 2019-da edildi. İndidən layihə repertuarında bizim siyahımızda olan bir çox xüsusiyyət mövcuddur, onlarla daha ətraflı tanış olmaq üçün layihə repertuarına baxmaq olar. Operator populyar operator-sdk əsasında qurulub. "Karton" dəstəyi ilə monitorinq həyata keçirir. Digər operatorlardan əsas fərqi CassKop plaqinidir, Python-da həyata keçirilmiş və Cassandra düyünləri arasında əlaqə üçün istifadə olunur.

Sonuçlar

Cassandra-nın Kubernetes-ə köçürülməsi üçün əlverişli üsul və mümkün variantların sayı özlüyündə danışır: bu mövzu tələb olunur.

Hal-hazırda yuxarıda təsvir olunanlardan birini sınamaq öz riskinizdedir: heç bir hazırlayıcı həlletmənin istehsal mühitində 100%-lik işləyəcəyini təmin etmir. Ancaq artıq bir çox məhsullar, inkişaf üçün provayderlərdə istifadə edilməyə dəyər görsənir.

Düşünürəm ki, gələcəkdə bu qadın gəmidə faydalı olacaq!

P.S.

Blogumuzda oxuyun:

• «MongoDB-nin Kubernetes-də çətinliklə miqrasiyası»;
• «RabbitMQ-nin Kubernetes-ə çətin miqrasiya»;
• «Veri bazaları və Kubernetes (icmal və təqdimat videosu)»;
• «K8s ipuçları & fəndləri: Böyük verilənlər bazalarının bootstrapsını sürətləndiririk».

Mənbə: habr.com