Ni regule renkontas la datumbazon Apache Cassandra kaj la bezonon funkciigi ĝin ene de Kubernetes-bazita infrastrukturo. En ĉi tiu materialo, ni dividos nian vizion pri la necesaj paŝoj, kriterioj kaj ekzistantaj solvoj (inkluzive de superrigardo de funkciigistoj) por migri Cassandra al K8s.
"Kiu povas regi virinon, povas ankaŭ regi la ŝtaton"
Kiu estas Kasandra? Ĝi estas distribuita stokada sistemo desegnita por administri grandajn volumojn da datumoj dum ĝi certigas altan haveblecon sen unu punkto de fiasko. La projekto apenaŭ bezonas longan enkondukon, do mi donos nur la ĉefajn trajtojn de Kasandra, kiuj estos trafaj en la kunteksto de specifa artikolo:
- Kasandra estas skribita en Java.
- La Kasandra topologio inkludas plurajn nivelojn:
- Nodo - unu deplojita Cassandra kazo;
- Rack estas grupo de Kasandraj petskriboj, kunigitaj de iu trajto, situantaj en la sama datumcentro;
- Datacenter - kolekto de ĉiuj grupoj de Kasandra petskriboj situantaj en unu datumcentro;
- Areto estas kolekto de ĉiuj datumcentroj.
- Cassandra uzas IP-adreson por identigi nodon.
- Por akceli skribajn kaj legajn operaciojn, Cassandra stokas iujn datumojn en RAM.
Nun - al la reala potenciala movo al Kubernetes.
Kontrollisto por translokigo
Parolante pri la migrado de Cassandra al Kubernetes, ni esperas, ke kun la movo ĝi fariĝos pli oportuna administri. Kio estos postulata por ĉi tio, kio helpos pri tio?
1. Stokado de datumoj
Kiel jam estis klarigite, Cassanda stokas parton de la datumoj en RAM - en Memtable. Sed estas alia parto de la datumoj, kiu estas konservita en disko - en la formo SSTable. Ento estas aldonita al ĉi tiu datumo Commit Log — registroj de ĉiuj transakcioj, kiuj ankaŭ estas konservitaj en disko.
Skribu transakcian diagramon en Kasandra
En Kubernetes, ni povas uzi PersistentVolume por stoki datumojn. Danke al provitaj mekanismoj, labori kun datumoj en Kubernetes pliiĝas ĉiujare.
Ni asignos nian propran Persistentan Volumon al ĉiu Kasandra pod
Gravas noti, ke Cassandra mem implicas reproduktadon de datumoj, proponante enkonstruitajn mekanismojn por tio. Sekve, se vi konstruas Cassandra areton el granda nombro da nodoj, tiam ne necesas uzi distribuitajn sistemojn kiel Ceph aŭ GlusterFS por datumstokado. En ĉi tiu kazo, estus logike stoki datumojn sur la gastiga disko uzante aŭ muntado hostPath.
Alia demando estas ĉu vi volas krei apartan medion por programistoj por ĉiu funkciobranĉo. En ĉi tiu kazo, la ĝusta aliro estus levi unu Kasandran nodon kaj stoki la datumojn en distribuita stokado, t.e. la menciitaj Ceph kaj GlusterFS estos viaj elektoj. Tiam la programisto estos certa, ke li ne perdos testajn datumojn eĉ se unu el la kuberntesaj nodoj estas perdita.
2. Monitorado
La preskaŭ nekontestita elekto por efektivigi monitoradon en Kubernetes estas Prometheus (Ni parolis pri tio detale en ). Kiel Cassandra fartas kun metrikaj eksportantoj por Prometeo? Kaj, kio estas eĉ pli grava, kun kongruaj paneloj por Grafana?
Ekzemplo de la apero de grafeoj en Grafana por Kasandra
Estas nur du eksportistoj: и .
Ni elektis la unuan por ni mem ĉar:
- JMX Exporter kreskas kaj disvolvas, dum Cassandra Exporter ne povis akiri sufiĉe da komunuma subteno. Cassandra Exporter ankoraŭ ne subtenas plej multajn versiojn de Cassandra.
- Vi povas ruli ĝin kiel javaagent aldonante flagon
-javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180. - Estas unu por li , kiu estas malkongrua kun Cassandra Exporter.
3. Elekto de Kubernetes primitivuloj
Laŭ la ĉi-supra strukturo de la kasandra areto, ni provu traduki ĉion, kio estas priskribita tie, en la terminologion de Kubernetes:
- Kasandra Nodo → Pod
- Cassandra Rack → StatefulSet
- Cassandra Datacenter → naĝejo de StatefulSets
- Kasandra Areto → ???
Rezultas, ke mankas iu plia ento por administri la tutan Kasandran areton samtempe. Sed se io ne ekzistas, ni povas ĝin krei! Kubernetes havas mekanismon por difini siajn proprajn rimedojn por ĉi tiu celo - .
Deklari pliajn rimedojn por protokoloj kaj atentigoj
Sed Propra Rimedo mem nenion signifas: ja ĝi postulas regilo. Vi eble bezonos serĉi helpon ...
4. Identigo de balgoj
En la supra alineo, ni konsentis, ke unu Kasandra nodo egalos unu pod en Kubernetes. Sed la IP-adresoj de la podoj estos malsamaj ĉiufoje. Kaj la identigo de nodo en Cassandra baziĝas sur la IP-adreso... Rezultas, ke post ĉiu forigo de pod, la Kasandra areto aldonos novan nodon.
Estas elirejo, kaj ne nur unu:
- Ni povas konservi rekordojn per mastro-identigiloj (UUID-oj, kiuj unike identigas Cassandra-instancojn) aŭ per IP-adresoj kaj stoki ĉion en iuj strukturoj/tabloj. La metodo havas du ĉefajn malavantaĝojn:
- La risko de raskondiĉo okazanta se du nodoj falas samtempe. Post la pliiĝo, Cassandra-nodoj samtempe petos IP-adreson de la tablo kaj konkuros por la sama rimedo.
- Se Kasandra nodo perdis siajn datumojn, ni ne plu povos identigi ĝin.
- La dua solvo ŝajnas malgranda hako, sed tamen: ni povas krei Servon kun ClusterIP por ĉiu Cassandra nodo. Problemoj kun ĉi tiu efektivigo:
- Se estas multaj nodoj en Cassandra areto, ni devos krei multajn Servojn.
- La funkcio ClusterIP estas efektivigita per iptables. Ĉi tio povas fariĝi problemo se la Kasandra areto havas multajn (1000... aŭ eĉ 100?) nodojn. Kvankam povas solvi ĉi tiun problemon.
- La tria solvo estas uzi reton de nodoj por Cassandra nodoj anstataŭ dediĉita reto de balgoj ebligante la agordon.
hostNetwork: true. Ĉi tiu metodo postulas iujn limigojn:- Anstataŭigi unuojn. Necesas, ke la nova nodo devas havi la saman IP-adreson kiel la antaŭa (en nuboj kiel AWS, GCP ĉi tio estas preskaŭ neeble fari);
- Uzante reton de grapolnodoj, ni komencas konkuri por retaj rimedoj. Sekve, meti pli ol unu pod kun Kasandra sur unu grapolnodo estos problema.
5. Rezervoj
Ni volas konservi plenan version de la datumoj de ununura Kasandra nodo laŭ horaro. Kubernetes provizas oportunan funkcion uzante , sed ĉi tie Kasandra mem metas spokon en niajn radojn.
Mi memorigu vin, ke Cassandra konservas iujn datumojn en memoro. Por fari plenan sekurkopion, vi bezonas datumojn el memoro (Memtables) movi al disko (SSTables). Je ĉi tiu punkto, la nodo Cassandra ĉesas akcepti ligojn, tute fermante de la areto.
Post tio, la sekurkopio estas forigita (ekrano) kaj la skemo estas konservita (klavspaco). Kaj tiam montriĝas, ke nur sekurkopio nenion donas al ni: ni devas konservi la datumajn identigilojn, pri kiuj respondecis la nodo Cassandra - ĉi tiuj estas specialaj ĵetonoj.
Distribuado de ĵetonoj por identigi pri kiaj datumoj respondecas Kasandraj nodoj
Ekzempla skripto por preni Kasandran sekurkopion de Guglo en Kubernetes troveblas ĉe . La sola punkto, kiun la skripto ne konsideras, estas restarigi datumojn al la nodo antaŭ preni la momentfoton. Tio estas, la sekurkopio estas farita ne por la nuna stato, sed por stato iom pli frue. Sed ĉi tio helpas ne elfunkciigi la nodon, kio ŝajnas tre logika.
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}"Ekzemplo de bash-skripto por preni sekurkopion de unu Cassandra nodo
Pretaj solvoj por Cassandra en Kubernetes
Kio estas nuntempe uzata por disfaldi Cassandra en Kubernetes kaj kiu el ĉi tiuj plej taŭgas al la donitaj postuloj?
1. Solvoj bazitaj sur StatefulSet aŭ Helm-diagramoj
Uzi la bazajn funkciojn de StatefulSets por ruli Cassandra areton estas bona elekto. Uzante la ŝablonojn Helm-diagramo kaj Go, vi povas provizi la uzanton per fleksebla interfaco por deploji Cassandra.
Ĉi tio kutime funkcias bone... ĝis io neatendita okazas, kiel noda fiasko. Normaj Kubernetes-iloj simple ne povas konsideri ĉiujn funkciojn priskribitajn supre. Aldone, ĉi tiu aliro estas tre limigita en kiom ĝi povas esti etendita por pli kompleksaj uzoj: nodo anstataŭigo, sekurkopio, reakiro, monitorado, ktp.
Reprezentantoj:
- ;
- .
Ambaŭ leteroj estas same bonaj, sed estas submetitaj al la problemoj priskribitaj supre.
2. Solvoj bazitaj sur Kubernetes Operatoro
Tiaj opcioj estas pli interesaj ĉar ili provizas ampleksajn ŝancojn por administri la areton. Por desegnado de Cassandra funkciigisto, kiel ajna alia datumbazo, bona ŝablono aspektas kiel Sidecar <-> Controller <-> CRD:
Noda administradskemo en bone dizajnita Cassandra funkciigisto
Ni rigardu ekzistantajn funkciigistojn.
1. Cassandra-operatoro de instaclustr
- Preteco: Alfa
- Licenco: Apache 2.0
- Realigita en: Java
Ĉi tio ja estas tre promesplena kaj aktive evoluanta projekto de firmao kiu ofertas administritajn deplojojn de Cassandra. Ĝi, kiel priskribite supre, uzas kroman ujon, kiu akceptas komandojn per HTTP. Skribita en Java, al ĝi foje mankas la pli altnivela funkcieco de la klient-go biblioteko. Ankaŭ, la funkciigisto ne subtenas malsamajn Rakojn por unu Datumcentro.
Sed la funkciigisto havas tiajn avantaĝojn kiel subteno por monitorado, altnivela cluster-administrado per CRD, kaj eĉ dokumentado por fari sekurkopiojn.
2. Navigilo de Jetstack
- Preteco: Alfa
- Licenco: Apache 2.0
- Realigita en: Golang
Deklaro dizajnita por deploji DB-as-a-Service. Nuntempe subtenas du datumbazojn: Elasticsearch kaj Cassandra. Ĝi havas tiajn interesajn solvojn kiel datumbazan alirkontrolon per RBAC (por tio ĝi havas propran apartan navigilon-apiserver). Interesa projekto, kiun valorus pli detale rigardi, sed la lasta kompromiso estis farita antaŭ jaro kaj duono, kio klare malpliigas ĝian potencialon.
3. Kasandra-funkciigisto de vgkowski
- Preteco: Alfa
- Licenco: Apache 2.0
- Realigita en: Golang
Ili ne konsideris ĝin "serioze", ĉar la lasta kompromiso al la deponejo estis antaŭ pli ol unu jaro. Funkciisto-disvolviĝo estas forlasita: la plej nova versio de Kubernetes raportita kiel subtenata estas 1.9.
4. Kasandra-funkciigisto de Rook
- Preteco: Alfa
- Licenco: Apache 2.0
- Realigita en: Golang
Telefonisto, kies evoluo ne progresas tiel rapide kiel ni ŝatus. Ĝi havas bone pripensitan CRD-strukturon por cluster-administrado, solvas la problemon de identigado de nodoj uzante Servon kun ClusterIP (la sama "hako")... sed tio estas ĉio por nun. Nuntempe ne ekzistas monitorado aŭ sekurkopioj el la skatolo (cetere, ni estas por monitorado ). Interesa punkto estas, ke vi ankaŭ povas disfaldi ScyllaDB uzante ĉi tiun funkciigiston.
NB: Ni uzis ĉi tiun funkciigiston kun etaj modifoj en unu el niaj projektoj. Neniuj problemoj estis rimarkitaj en la laboro de la funkciigisto dum la tuta periodo de operacio (~4 monatoj da operacio).
5. CassKop el Orange
- Preteco: Alfa
- Licenco: Apache 2.0
- Realigita en: Golang
La plej juna funkciigisto en la listo: la unua kompromiso estis farita la 23-an de majo 2019. Jam nun ĝi havas en sia arsenalo grandan nombron da funkcioj el nia listo, pli da detaloj pri kiuj troveblas en la projekta deponejo. La funkciigisto estas konstruita surbaze de la populara operatoro-sdk. Subtenas monitoradon el la skatolo. La ĉefa diferenco de aliaj funkciigistoj estas la uzo , efektivigita en Python kaj uzita por komunikado inter Kasandraj nodoj.
trovoj
La nombro da aliroj kaj eblaj ebloj por porti Cassandra al Kubernetes parolas por si mem: la temo estas postulata.
En ĉi tiu etapo, vi povas provi iun ajn el ĉi-supraj je via propra danĝero kaj risko: neniu el la programistoj garantias 100% funkciadon de sia solvo en produktadmedio. Sed jam multaj produktoj aspektas promesplenaj por provi uzi en evolubenkoj.
Mi pensas, ke estonte ĉi tiu virino sur la ŝipo utilos!
PS
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com