Wy tsjinkomme geregeld de Apache Cassandra-database en de needsaak om it te betsjinjen binnen in Kubernetes-basearre ynfrastruktuer. Yn dit materiaal sille wy ús fyzje diele oer de nedige stappen, kritearia en besteande oplossingen (ynklusyf in oersjoch fan operators) foar it migrearjen fan Cassandra nei K8s.
"Wa't in frou regearje kin kin ek de steat regearje"
Wa is Cassandra? It is in ferspraat opslachsysteem ûntworpen om grutte folumes gegevens te behearjen, wylst it garandearjen fan hege beskikberens sûnder ien inkeld punt fan mislearring. It projekt hat amper in lange ynlieding nedich, dus ik sil allinich de haadfunksjes fan Cassandra jaan dy't relevant sille wêze yn 'e kontekst fan in spesifyk artikel:
- Cassandra is skreaun yn Java.
- De Cassandra-topology omfettet ferskate nivo's:
- Node - ien ynset Cassandra eksimplaar;
- Rack is in groep Cassandra eksimplaren, ferienige troch guon karakteristyk, leit yn deselde data sintrum;
- Datacenter - in kolleksje fan alle groepen Cassandra-eksimplaren yn ien datasintrum;
- Cluster is in samling fan alle datasintra.
- Cassandra brûkt in IP-adres om in knooppunt te identifisearjen.
- Om skriuw- en lêsoperaasjes te rapperjen, bewarret Cassandra guon fan 'e gegevens yn RAM.
No - nei de eigentlike potinsjele ferhuzing nei Kubernetes.
Kontrolearjelist foar oerdracht
Sprekend oer de migraasje fan Cassandra nei Kubernetes, hoopje wy dat it mei de ferhuzing handiger wurdt om te behearjen. Wat sil hjirfoar nedich wêze, wat sil hjirmei helpe?
1. Data opslach
Lykas al dúdlik is, bewarret Cassanda in diel fan 'e gegevens yn RAM - yn Memtable. Mar d'r is in oar diel fan 'e gegevens dy't op skiif bewarre wurdt - yn' e foarm SSTable. In entiteit wurdt tafoege oan dizze gegevens Commit Log - records fan alle transaksjes, dy't ek wurde opslein op skiif.
Skriuw transaksjediagram yn Cassandra
Yn Kubernetes kinne wy PersistentVolume brûke om gegevens op te slaan. Mei tank oan bewiisde meganismen wurdt it wurkjen mei gegevens yn Kubernetes alle jierren makliker.
Wy sille ús eigen PersistentVolume tawize oan elke Cassandra-pod
It is wichtich om te notearjen dat Cassandra sels gegevensreplikaasje ymplisearret, en biedt hjirfoar ynboude meganismen. Dêrom, as jo in Cassandra-kluster bouwe fan in grut oantal knooppunten, dan is d'r gjin ferlet om ferdielde systemen lykas Ceph of GlusterFS te brûken foar gegevensopslach. Yn dit gefal soe it logysk wêze om gegevens op te slaan op 'e hostskiif mei help fan of mounting hostPath.
In oare fraach is as jo in aparte omjouwing wolle meitsje foar ûntwikkelders foar elke funksje-tûke. Yn dit gefal soe de juste oanpak wêze om ien Cassandra-knooppunt te ferheegjen en de gegevens op te slaan yn in ferspraat opslach, d.w.s. de neamde Ceph en GlusterFS sille jo opsjes wêze. Dan sil de ûntwikkelder der wis fan wêze dat hy gjin testgegevens ferliest, sels as ien fan 'e Kuberntes-klusterknooppunten ferlern is.
2. Monitoring
De frijwol ûnbestriden kar foar it ymplementearjen fan tafersjoch yn Kubernetes is Prometheus (wy hawwe hjir yn detail oer praat yn ). Hoe docht Cassandra mei metrike eksporteurs foar Prometheus? En, wat is noch wichtiger, mei oerienkommende dashboards foar Grafana?
In foarbyld fan it ferskinen fan grafiken yn Grafana foar Cassandra
D'r binne mar twa eksporteurs: и .
Wy hawwe de earste foar ússels keazen omdat:
- JMX Exporter groeit en ûntwikkelet, wylst Cassandra Exporter net genôch mienskipsstipe koe krije. Cassandra Exporter stipet de measte ferzjes fan Cassandra noch net.
- Jo kinne it útfiere as in javaagent troch in flagge ta te foegjen
-javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180. - Der is ien foar him , dat is ynkompatibel mei Cassandra Exporter.
3. Selektearje Kubernetes primitives
Neffens de boppesteande struktuer fan 'e Cassandra-kluster, litte wy besykje alles dat dêr beskreaun wurdt oer te setten yn Kubernetes-terminology:
- Cassandra Node → Pod
- Cassandra Rack → StatefulSet
- Cassandra Datacenter → pool fan StatefulSets
- Cassandra Cluster → ???
It docht bliken dat wat ekstra entiteit ûntbrekt om it heule Cassandra-kluster tagelyk te behearjen. Mar as der wat net bestiet, kinne wy it meitsje! Kubernetes hat in meganisme foar it definiearjen fan har eigen boarnen foar dit doel - .
Oanfoljende boarnen ferklearje foar logs en warskôgings
Mar Custom Resource sels betsjut neat: it fereasket ommers kontrôler. Jo moatte miskien help sykje ...
4. Pod identifikaasje
Yn 'e alinea hjirboppe binne wy it iens dat ien Cassandra-knooppunt gelyk is oan ien pod yn Kubernetes. Mar de IP-adressen fan 'e pods sille elke kear oars wêze. En de identifikaasje fan in knooppunt yn Cassandra is basearre op it IP-adres ... It docht bliken dat nei elke fuortheljen fan in pod, it Cassandra-kluster in nije knooppunt tafoegje sil.
D'r is in útwei, en net ien:
- Wy kinne records hâlde troch host-identifikaasjes (UUID's dy't Cassandra-eksimplaren unyk identifisearje) of troch IP-adressen en alles opslaan yn guon struktueren / tabellen. De metoade hat twa wichtichste neidielen:
- It risiko fan in race tastân optreedt as twa knopen falle tagelyk. Nei de opkomst sille Cassandra-knooppunten tagelyk in IP-adres fan 'e tafel freegje en konkurrearje foar deselde boarne.
- As in Cassandra-knooppunt syn gegevens ferlern hat, kinne wy it net langer identifisearje.
- De twadde oplossing liket in lyts hack, mar dochs: wy kinne in tsjinst meitsje mei ClusterIP foar elke Cassandra-knooppunt. Problemen mei dizze ymplemintaasje:
- As d'r in protte knopen binne yn in Cassandra-kluster, sille wy in protte tsjinsten moatte oanmeitsje.
- De ClusterIP-funksje wurdt ymplementearre fia iptables. Dit kin in probleem wurde as it Cassandra-kluster in protte (1000 ... of sels 100?) Knooppunten hat. Alhoewol kin oplosse dit probleem.
- De tredde oplossing is om in netwurk fan knopen te brûken foar Cassandra-knooppunten ynstee fan in tawijd netwurk fan pods troch de ynstelling yn te skeakeljen
hostNetwork: true. Dizze metoade stelt bepaalde beheiningen op:- Om ienheden te ferfangen. It is needsaaklik dat it nije knooppunt itselde IP-adres hawwe moat as it foarige (yn wolken lykas AWS, GCP is dit hast ûnmooglik om te dwaan);
- Mei in netwurk fan klusterknooppunten begjinne wy te konkurrearjen foar netwurkboarnen. Dêrom sil it pleatsen fan mear dan ien pod mei Cassandra op ien klusterknoop problematysk wêze.
5. Reservekopy
Wy wolle in folsleine ferzje fan de gegevens fan ien Cassandra-knooppunt opslaan op in skema. Kubernetes biedt in handige funksje mei help , mar hjir set Cassandra sels in spek yn ús tsjillen.
Lit my jo herinnerje dat Cassandra guon fan 'e gegevens yn it ûnthâld bewarret. Om in folsleine reservekopy te meitsjen, hawwe jo gegevens nedich út it ûnthâld (Memtables) ferpleatse nei skiif (SSTables). Op dit punt stopet de Cassandra-knooppunt mei it akseptearjen fan ferbiningen, folslein ôfsletten fan it kluster.
Hjirnei wurdt de reservekopy fuortsmiten (snapshot) en it skema wurdt bewarre (keyspace). En dan docht bliken dat gewoan in reservekopy ús neat jout: wy moatte de gegevensidentifiers bewarje wêrfoar de Cassandra-knooppunt wie ferantwurdlik - dit binne spesjale tokens.
Ferdieling fan tokens om te identifisearjen hokker gegevens Cassandra-knooppunten binne ferantwurdlik foar
In foarbyldskript foar it nimmen fan in Cassandra-backup fan Google yn Kubernetes is te finen op . It ienige punt dat it skript net yn 'e rekken hâldt, is it resetten fan gegevens nei it knooppunt foardat jo de momintopname nimme. Dat is, de reservekopy wurdt útfierd net foar de hjoeddeiske steat, mar foar in steat in bytsje earder. Mar dit helpt net te nimmen it knooppunt út wurking, dat liket hiel logysk.
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}"In foarbyld fan in bash-skript foar it nimmen fan in reservekopy fan ien Cassandra-knooppunt
Klear oplossings foar Cassandra yn Kubernetes
Wat wurdt op it stuit brûkt om Cassandra yn Kubernetes yn te setten en hokker fan dizze past it bêste by de opjûne easken?
1. Oplossings basearre op StatefulSet of Helm charts
It brûken fan de basisfunksjes fan StatefulSets om in Cassandra-kluster út te fieren is in goede opsje. Mei help fan de Helm-kaart en Go-sjabloanen kinne jo de brûker in fleksibele interface leverje foar it ynsetten fan Cassandra.
Dit wurket normaal goed ... oant der wat ûnferwachts bart, lykas in knooppuntfal. Standert Kubernetes-ark kinne gewoan net rekken hâlde mei alle hjirboppe beskreaune funksjes. Derneist is dizze oanpak heul beheind yn hoefolle it kin wurde útwreide foar mear komplekse gebrûk: knooppuntferfanging, reservekopy, herstel, tafersjoch, ensfh.
Fertsjintwurdigers:
- ;
- .
Beide charts binne like goed, mar binne ûnder foarbehâld fan de problemen beskreaun hjirboppe.
2. Oplossings basearre op Kubernetes Operator
Sokke opsjes binne nijsgjirriger om't se genôch kânsen jouwe foar it behearen fan it kluster. Foar it ûntwerpen fan in Cassandra-operator, lykas elke oare database, liket in goed patroan Sidecar <-> Controller <-> CRD:
Node behear skema yn in goed ûntwurpen Cassandra operator
Litte wy nei besteande operators sjen.
1. Cassandra-operator út instaclustr
- Reewilligens: Alpha
- Lisinsje: Apache 2.0
- Implementearre yn: Java
Dit is yndie in heul belofte en aktyf ûntwikkeljend projekt fan in bedriuw dat behearde Cassandra-ynset biedt. It, lykas hjirboppe beskreaun, brûkt in sidecar-container dy't kommando's akseptearret fia HTTP. Skreaun yn Java mist it soms de mear avansearre funksjonaliteit fan 'e client-go-biblioteek. Ek stipet de operator gjin ferskate Racks foar ien Datacenter.
Mar de operator hat sokke foardielen as stipe foar tafersjoch, klusterbehear op hege nivo mei CRD, en sels dokumintaasje foar it meitsjen fan backups.
2. Navigator út Jetstack
- Reewilligens: Alpha
- Lisinsje: Apache 2.0
- Implementearre yn: Golang
In ferklearring ûntworpen om DB-as-a-Service yn te setten. Op it stuit stipet twa databases: Elasticsearch en Cassandra. It hat sokke nijsgjirrige oplossingen as databank tagongskontrôle fia RBAC (dêrfoar hat it in eigen aparte navigator-apiserver). In nijsgjirrich projekt dat it wurdich is om in tichterby te besjen, mar de lêste commit waard oardel jier lyn makke, wat har potensjeel dúdlik ferminderet.
3. Cassandra-operator troch vgkowski
- Reewilligens: Alpha
- Lisinsje: Apache 2.0
- Implementearre yn: Golang
Se beskôgen it net "serieus", om't de lêste ynset foar de repository mear as in jier lyn wie. Operatorûntwikkeling wurdt ferlitten: de lêste ferzje fan Kubernetes rapporteare as stipe is 1.9.
4. Cassandra-operator troch Rook
- Reewilligens: Alpha
- Lisinsje: Apache 2.0
- Implementearre yn: Golang
In operator waans ûntwikkeling net sa fluch foarút giet as wy wolle. It hat in goed trochtocht CRD-struktuer foar klusterbehear, lost it probleem op fan it identifisearjen fan knooppunten mei Service mei ClusterIP (deselde "hack") ... mar dat is alles foar no. D'r is op it stuit gjin tafersjoch of backups út 'e doaze (troch de manier, wy binne foar tafersjoch ). In nijsgjirrich punt is dat jo ek ScyllaDB kinne ynsette mei dizze operator.
NB: Wy brûkten dizze operator mei lytse oanpassings yn ien fan ús projekten. Gjin problemen waarden opmurken yn it wurk fan de operator yn de hiele perioade fan operaasje (~ 4 moannen fan operaasje).
5. CassKop út Oranje
- Reewilligens: Alpha
- Lisinsje: Apache 2.0
- Implementearre yn: Golang
De jongste operator op 'e list: de earste commit waard makke op 23 maaie 2019. No al hat it yn har arsenal in grut oantal funksjes út ús list, wêrfan mear details kinne fûn wurde yn it projektbewarplak. De operator is boud op basis fan de populêre operator-sdk. Unterstützt tafersjoch út 'e doaze. It wichtichste ferskil fan oare operators is it gebrûk , ymplementearre yn Python en brûkt foar kommunikaasje tusken Cassandra-knooppunten.
befinings
It oantal oanpakken en mooglike opsjes foar it portearjen fan Cassandra nei Kubernetes sprekt foar himsels: it ûnderwerp is yn fraach.
Op dit stadium kinne jo ien fan 'e boppesteande besykje op jo eigen risiko en risiko: gjinien fan' e ûntwikkelders garandearret 100% wurking fan har oplossing yn in produksjeomjouwing. Mar al sjogge in protte produkten belofte om te besykjen te brûken yn ûntwikkelingsbanken.
Ik tink dat dizze frou op it skip yn 'e takomst fan pas komt!
PS
Lês ek op ús blog:
- «";
- «";
- «";
- «".
Boarne: www.habr.com