Apache Cassandra veritabanıyla ve onu Kubernetes tabanlı bir altyapı içerisinde çalıştırma ihtiyacıyla düzenli olarak karşılaşıyoruz. Bu materyalde Cassandra'nın K8'lere geçişi için gerekli adımlara, kriterlere ve mevcut çözümlere (operatörlerin genel görünümü dahil) ilişkin vizyonumuzu paylaşacağız.
“Kadını yöneten, devleti de yönetebilir”
Cassandra kimdir? Tek bir arıza noktası olmadan yüksek kullanılabilirlik sağlarken büyük hacimli verileri yönetmek için tasarlanmış dağıtılmış bir depolama sistemidir. Projenin uzun bir girişe pek ihtiyacı yok, bu yüzden Cassandra'nın yalnızca belirli bir makale bağlamında alakalı olacak temel özelliklerini vereceğim:
- Cassandra Java'da yazılmıştır.
- Cassandra topolojisi birkaç seviye içerir:
- Düğüm - konuşlandırılmış bir Cassandra örneği;
- Rack, aynı veri merkezinde bulunan, bazı özelliklerle birleştirilmiş bir Cassandra bulut sunucuları grubudur;
- Veri merkezi - tek bir veri merkezinde bulunan tüm Cassandra bulut sunucusu gruplarının koleksiyonu;
- Küme, tüm veri merkezlerinin bir koleksiyonudur.
- Cassandra bir düğümü tanımlamak için bir IP adresi kullanır.
- Yazma ve okuma işlemlerini hızlandırmak için Cassandra verilerin bir kısmını RAM'de saklar.
Şimdi Kubernetes'e gerçek potansiyel geçişe geçelim.
Transfer için kontrol listesi
Cassandra'nın Kubernetes'e geçişi hakkında konuşurken, bu geçişle birlikte yönetimin daha kolay hale geleceğini umuyoruz. Bunun için ne gerekli olacak, buna ne yardımcı olacak?
1. Veri depolama
Daha önce de açıklandığı gibi, Cassanda verilerin bir kısmını RAM'de saklar. Hatırlanabilir. Ancak verilerin diske kaydedilen başka bir kısmı da var - formda SSTable. Bu verilere bir varlık eklenir Kaydetme Günlüğü — diske de kaydedilen tüm işlemlerin kayıtları.
Cassandra'da işlem diyagramını yazın
Kubernetes'te veri depolamak için PersistentVolume'u kullanabiliriz. Kanıtlanmış mekanizmalar sayesinde Kubernetes'te verilerle çalışmak her geçen yıl daha kolay hale geliyor.
Her Cassandra bölmesine kendi PersistentVolume değerimizi tahsis edeceğiz
Cassandra'nın kendisinin veri çoğaltmayı ima ettiğini ve bunun için yerleşik mekanizmalar sunduğunu unutmamak önemlidir. Bu nedenle çok sayıda düğümden Cassandra kümesi oluşturuyorsanız veri depolama için Ceph veya GlusterFS gibi dağıtılmış sistemleri kullanmanıza gerek yoktur. Bu durumda verileri ana diskte depolamak mantıklı olacaktır. veya montaj hostPath.
Başka bir soru da, geliştiriciler için her özellik dalı için ayrı bir ortam oluşturmak isteyip istemediğinizdir. Bu durumda doğru yaklaşım, bir Cassandra düğümünü yükseltmek ve verileri dağıtılmış bir depolama alanında depolamak olacaktır. bahsedilen Ceph ve GlusterFS seçenekleriniz olacaktır. Böylece geliştirici, Kuberntes küme düğümlerinden biri kaybolsa bile test verilerini kaybetmeyeceğinden emin olacaktır.
2. İzleme
Kubernetes'te izlemeyi uygulamak için neredeyse tartışmasız tercih Prometheus'tur (bu konuyu ayrıntılı olarak konuştuk ). Cassandra'nın Prometheus için metrik aktarıcılarla durumu nasıl? Ve daha da önemlisi Grafana için uyumlu kontrol panelleri var mı?
Cassandra için Grafana'da grafiklerin görünümüne bir örnek
Sadece iki ihracatçı var: и .
İlkini kendimiz için seçtik çünkü:
- JMX Exporter büyüyor ve gelişiyor, Cassandra Exporter ise yeterli topluluk desteğini alamıyor. Cassandra Exporter hala Cassandra'nın çoğu sürümünü desteklemiyor.
- Bayrak ekleyerek javaagent olarak çalıştırabilirsiniz.
-javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180. - Onun için bir tane var Cassandra Exporter ile uyumsuz.
3. Kubernetes temel öğelerini seçme
Cassandra kümesinin yukarıdaki yapısına göre, burada anlatılan her şeyi Kubernetes terminolojisine çevirmeye çalışalım:
- Cassandra Düğümü → Bölme
- Cassandra Rafı → StatefulSet
- Cassandra Veri Merkezi → StatefulSets'ten havuz
- Cassandra Kümesi → ???
Cassandra kümesinin tamamını aynı anda yönetmek için bazı ek varlıkların eksik olduğu ortaya çıktı. Ama eğer bir şey yoksa onu yaratabiliriz! Kubernetes'in bu amaçla kendi kaynaklarını tanımlamaya yönelik bir mekanizması vardır: .
Günlükler ve uyarılar için ek kaynaklar bildirme
Ancak Özel Kaynağın kendisi hiçbir şey ifade etmez; sonuçta kontrolör. Yardım aramanız gerekebilir ...
4. Bölmelerin tanımlanması
Yukarıdaki paragrafta, Kubernetes'te bir Cassandra düğümünün bir pod'a eşit olacağı konusunda anlaşmıştık. Ancak bölmelerin IP adresleri her seferinde farklı olacaktır. Ve Cassandra'daki bir düğümün tanımlanması IP adresine dayanmaktadır... Her bir kapsülün çıkarılmasından sonra Cassandra kümesinin yeni bir düğüm ekleyeceği ortaya çıktı.
Bir çıkış yolu var, tek bir yol değil:
- Kayıtları ana bilgisayar tanımlayıcılarına (Cassandra örneklerini benzersiz şekilde tanımlayan UUID'ler) veya IP adreslerine göre tutabilir ve hepsini bazı yapılarda/tablolarda saklayabiliriz. Yöntemin iki ana dezavantajı vardır:
- İki düğümün aynı anda düşmesi durumunda yarış durumunun ortaya çıkma riski. Yükselişin ardından Cassandra düğümleri eş zamanlı olarak tablodan bir IP adresi isteyecek ve aynı kaynak için rekabet edecek.
- Bir Cassandra düğümü verilerini kaybetmişse artık onu tanımlayamayız.
- İkinci çözüm küçük bir hack gibi görünüyor ama yine de: her Cassandra düğümü için ClusterIP ile bir Hizmet oluşturabiliriz. Bu uygulamayla ilgili sorunlar:
- Cassandra kümesinde çok sayıda düğüm varsa çok sayıda Hizmet oluşturmamız gerekecektir.
- ClusterIP özelliği iptables aracılığıyla uygulanır. Cassandra kümesinin çok sayıda (1000... hatta 100?) düğümü varsa bu bir sorun haline gelebilir. Rağmen bu sorunu çözebilir.
- Üçüncü çözüm, ayarı etkinleştirerek Cassandra düğümleri için özel bir bölme ağı yerine bir düğüm ağı kullanmaktır.
hostNetwork: true. Bu yöntem belirli sınırlamalar getirir:- Birimleri değiştirmek için. Yeni düğümün öncekiyle aynı IP adresine sahip olması gerekir (AWS, GCP gibi bulutlarda bunu yapmak neredeyse imkansızdır);
- Küme düğümlerinden oluşan bir ağ kullanarak ağ kaynakları için rekabet etmeye başlarız. Bu nedenle, bir küme düğümüne Cassandra ile birden fazla kapsül yerleştirmek sorunlu olacaktır.
5. Yedeklemeler
Tek bir Cassandra düğümünün verilerinin tam sürümünü bir programa kaydetmek istiyoruz. Kubernetes, aşağıdakileri kullanarak kullanışlı bir özellik sağlar: , ama burada Cassandra'nın kendisi tekerleklerimize bir jant teli koyuyor.
Cassandra'nın bazı verileri hafızasında sakladığını hatırlatayım. Tam yedekleme yapmak için bellekteki verilere ihtiyacınız vardır (Memtable'lar) diske taşı (SSTable'lar). Bu noktada Cassandra düğümü bağlantıları kabul etmeyi bırakır ve kümeden tamamen kapanır.
Bundan sonra yedekleme kaldırılır (enstantane) ve şema kaydedilir (anahtar alanı). Ve sonra, yedeklemenin bize hiçbir şey sağlamadığı ortaya çıktı: Cassandra düğümünün sorumlu olduğu veri tanımlayıcılarını kaydetmemiz gerekiyor - bunlar özel belirteçlerdir.
Cassandra düğümlerinin hangi verilerden sorumlu olduğunu belirlemek için token dağıtımı
Kubernetes'te Google'dan Cassandra yedeğini almak için örnek bir komut dosyası şu adreste bulunabilir: . Komut dosyasının dikkate almadığı tek nokta, anlık görüntüyü almadan önce verileri düğüme sıfırlamaktır. Yani yedekleme mevcut durum için değil, biraz daha önceki bir durum için gerçekleştirilir. Ancak bu, düğümün devre dışı bırakılmasına yardımcı olmuyor ki bu da çok mantıklı görünüyor.
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}"Bir Cassandra düğümünden yedekleme almaya yönelik bash betiği örneği
Kubernetes'te Cassandra için hazır çözümler
Cassandra'yı Kubernetes'te dağıtmak için şu anda ne kullanılıyor ve bunlardan hangisi verilen gereksinimlere en uygun?
1. StatefulSet veya Helm çizelgelerine dayalı çözümler
Bir Cassandra kümesini çalıştırmak için temel StatefulSets işlevlerini kullanmak iyi bir seçenektir. Helm grafiğini ve Go şablonlarını kullanarak kullanıcıya Cassandra'yı dağıtmak için esnek bir arayüz sağlayabilirsiniz.
Bu genellikle iyi çalışır... ta ki düğüm hatası gibi beklenmeyen bir durum gerçekleşene kadar. Standart Kubernetes araçları yukarıda açıklanan tüm özellikleri hesaba katamaz. Ek olarak, bu yaklaşımın daha karmaşık kullanımlar için ne kadar genişletilebileceği oldukça sınırlıdır: düğüm değiştirme, yedekleme, kurtarma, izleme vb.
temsilcileri:
- ;
- .
Her iki grafik de eşit derecede iyidir ancak yukarıda açıklanan sorunlara tabidir.
2. Kubernetes Operatörünü temel alan çözümler
Bu tür seçenekler daha ilgi çekicidir çünkü kümenin yönetilmesi için geniş fırsatlar sunarlar. Diğer herhangi bir veritabanı gibi bir Cassandra operatörünü tasarlamak için iyi bir model Sidecar <-> Controller <-> CRD'ye benzer:
İyi tasarlanmış bir Cassandra operatöründe düğüm yönetimi şeması
Mevcut operatörlere bakalım.
1. instaclustr'dan Cassandra operatörü
- Hazırlık: Alfa
- Lisans: Apache 2.0
- Uygulandığı dil: Java
Bu gerçekten de yönetilen Cassandra dağıtımları sunan bir şirketin oldukça umut verici ve aktif olarak gelişen bir projesi. Yukarıda açıklandığı gibi, HTTP yoluyla komutları kabul eden bir sepet kabı kullanır. Java'da yazılan bu kitap bazen client-go kitaplığının daha gelişmiş işlevlerinden yoksundur. Ayrıca operatör, bir Veri Merkezi için farklı Rafları desteklemez.
Ancak operatörün izleme desteği, CRD kullanarak üst düzey küme yönetimi ve hatta yedekleme yapmak için belgeleme gibi avantajları vardır.
2. Jetstack'tan Navigatör
- Hazırlık: Alfa
- Lisans: Apache 2.0
- Uygulandığı yer: Golang
Hizmet Olarak Veritabanını dağıtmak için tasarlanmış bir bildirim. Şu anda iki veritabanını desteklemektedir: Elasticsearch ve Cassandra. RBAC aracılığıyla veritabanı erişim kontrolü gibi ilginç çözümlere sahiptir (bunun için kendi ayrı navigatör-apserver'ı vardır). Daha yakından bakmaya değer ilginç bir proje, ancak son taahhüt bir buçuk yıl önce yapıldı ve bu da potansiyelini açıkça azaltıyor.
3. Vgkowski'den Cassandra operatörü
- Hazırlık: Alfa
- Lisans: Apache 2.0
- Uygulandığı yer: Golang
Depoya yapılan son taahhüt bir yıldan fazla süre önce gerçekleştiği için bunu "ciddi olarak" değerlendirmediler. Operatör geliştirmeden vazgeçildi: Desteklendiği bildirilen Kubernetes'in en son sürümü 1.9.
4. Rook'tan Cassandra operatörü
- Hazırlık: Alfa
- Lisans: Apache 2.0
- Uygulandığı yer: Golang
Gelişimi istediğimiz kadar hızlı ilerlemeyen bir operatör. Küme yönetimi için iyi düşünülmüş bir CRD yapısına sahiptir, Service with ClusterIP (aynı "hack") kullanılarak düğümlerin tanımlanması sorununu çözer... ama şimdilik hepsi bu. Şu anda kutudan çıkan hiçbir izleme veya yedekleme yok (bu arada, izleme amaçlıyız ). İlginç bir nokta da bu operatörü kullanarak ScyllaDB'yi dağıtabilmenizdir.
Not: Bu operatörü projelerimizden birinde küçük değişikliklerle kullandık. Tüm çalışma süresi boyunca (~4 aylık çalışma) operatörün çalışmasında herhangi bir sorun fark edilmedi.
5. Orange'dan CassKop
- Hazırlık: Alfa
- Lisans: Apache 2.0
- Uygulandığı yer: Golang
Listedeki en genç operatör: İlk taahhüt 23 Mayıs 2019'da yapıldı. Şimdiden cephaneliğinde listemizden çok sayıda özellik var, daha fazla ayrıntıyı proje deposunda bulabilirsiniz. Operatör, popüler operatör SDK'sı temel alınarak oluşturulmuştur. Kutunun dışında izlemeyi destekler. Diğer operatörlerden temel farkı kullanımıdır. Python'da uygulandı ve Cassandra düğümleri arasındaki iletişim için kullanıldı.
Bulgular
Cassandra'yı Kubernetes'e taşımaya yönelik yaklaşımların ve olası seçeneklerin sayısı her şeyi açıklıyor: Konu talep görüyor.
Bu aşamada, risk ve risk size ait olmak üzere yukarıdakilerden herhangi birini deneyebilirsiniz: geliştiricilerin hiçbiri, çözümlerinin üretim ortamında %100 çalışmasını garanti etmez. Ancak şimdiden birçok ürün, geliştirme tezgahlarında kullanmayı denemek için umut verici görünüyor.
Gelecekte gemideki bu kadının işe yarayacağını düşünüyorum!
PS
Blogumuzda da okuyun:
- «";
- «";
- «";
- «'.
Kaynak: habr.com