Flutningur Cassandra til Kubernetes: eiginleikar og lausnir

Við rekumst reglulega á Apache Cassandra gagnagrunninn og þörfina á að reka hann innan Kubernetes innviða. Í þessu efni munum við deila sýn okkar á nauðsynlegum skrefum, viðmiðunum og núverandi lausnum (þar á meðal yfirlit yfir rekstraraðila) til að flytja Cassandra til K8s.

„Hver ​​sem getur stjórnað konu getur líka stjórnað ríkinu“

Hver er Cassandra? Það er dreifð geymslukerfi sem er hannað til að stjórna miklu magni af gögnum á sama tíma og það tryggir mikið aðgengi án nokkurs bilunarpunkts. Verkefnið þarf varla langa kynningu, svo ég mun aðeins gefa helstu eiginleika Cassöndru sem eiga við í samhengi við tiltekna grein:

• Cassandra er skrifuð á Java.
• Cassandra svæðisfræðin inniheldur nokkur stig:
  • Hnútur - eitt útsett Cassandra dæmi;
  • Rack er hópur Cassandra tilvika, sameinuð af einhverjum eiginleikum, staðsett í sama gagnaveri;
  • Datacenter - safn af öllum hópum Cassandra tilvika staðsett í einni gagnaveri;
  • Cluster er safn allra gagnavera.
• Cassandra notar IP tölu til að bera kennsl á hnút.
• Til að flýta fyrir ritun og lestri geymir Cassandra sum gagna í vinnsluminni.

Nú - að raunverulegum hugsanlegum flutningi til Kubernetes.

Gátlisti fyrir flutning

Talandi um flutning Cassandra til Kubernetes, vonum við að með flutningnum verði það þægilegra að stjórna henni. Hvað þarf til þess, hvað mun hjálpa við þetta?

1. Gagnageymsla

Eins og þegar hefur verið skýrt, geymir Cassanda hluta af gögnunum í vinnsluminni - í Minnilegt. En það er annar hluti gagna sem er vistaður á disk - í formi SSTable. Eining er bætt við þessi gögn Skuldbindingarskrá — skrár yfir allar færslur, sem einnig eru vistaðar á disk.

Skrifaðu viðskiptamynd í Cassandra

Í Kubernetes getum við notað PersistentVolume til að geyma gögn. Þökk sé sannreyndum aðferðum er að vinna með gögn í Kubernetes að verða auðveldara á hverju ári.

Við munum úthluta hverjum fræbelgi með Cassöndru sínu eigin PersistentVolume

Það er mikilvægt að hafa í huga að Cassandra sjálf gefur til kynna afritun gagna og býður upp á innbyggða aðferð fyrir þetta. Þess vegna, ef þú ert að byggja upp Cassandra þyrping úr miklum fjölda hnúta, þá er engin þörf á að nota dreifð kerfi eins og Ceph eða GlusterFS fyrir gagnageymslu. Í þessu tilviki væri rökrétt að geyma gögn á hýsildisknum með því að nota staðbundnir viðvarandi diskar eða uppsetningu hostPath.

Önnur spurning er hvort þú vilt búa til sérstakt umhverfi fyrir forritara fyrir hverja eiginleikagrein. Í þessu tilviki væri rétta aðferðin að hækka einn Cassandra hnút og geyma gögnin í dreifðri geymslu, þ.e. nefndir Ceph og GlusterFS verða valmöguleikar þínir. Þá mun verktaki vera viss um að hann tapi ekki prófunargögnum þótt einn af Kuberntes klasahnútunum glatist.

2. Eftirlit

Nánast óumdeilt val til að innleiða vöktun í Kubernetes er Prometheus (við ræddum þetta ítarlega í tengd skýrslu). Hvernig gengur Cassandra með útflytjendur mæligilda fyrir Prometheus? Og hvað er enn mikilvægara, með samsvarandi mælaborð fyrir Grafana?

Dæmi um útlit grafa í Grafana fyrir Cassöndru

Það eru aðeins tveir útflytjendur: jmx_útflytjandi и cassandra_exporter.

Við völdum þann fyrsta fyrir okkur vegna þess að:

1. JMX Exporter er að vaxa og þróast á meðan Cassandra Exporter hefur ekki getað fengið nægan stuðning samfélagsins. Cassandra Exporter styður samt ekki flestar útgáfur af Cassandra.
2. Þú getur keyrt það sem javaagent með því að bæta við fána -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. Það er einn fyrir hann fullnægjandi mælaborð, sem er ósamrýmanlegt Cassandra Exporter.

3. Velja Kubernetes frumefni

Samkvæmt ofangreindri uppbyggingu Cassandra þyrpingarinnar, skulum við reyna að þýða allt sem þar er lýst yfir í Kubernetes hugtök:

• Cassandra Node → Pod
• Cassandra Rack → StatefulSet
• Cassandra Datacenter → sundlaug frá StatefulSets
• Cassandra Cluster → ???

Það kemur í ljós að einhverja viðbótareiningu vantar til að stjórna öllum Cassandra þyrpingunni í einu. En ef eitthvað er ekki til getum við búið það til! Kubernetes hefur kerfi til að skilgreina eigin auðlindir í þessum tilgangi - Sérsniðnar auðlindaskilgreiningar.

Lýsa yfir viðbótarauðlindum fyrir annála og viðvaranir

En Custom Resource sjálft þýðir ekki neitt: eftir allt saman, það krefst þess stjórnandi. Þú gætir þurft að leita þér hjálpar Kubernetes rekstraraðili...

4. Auðkenning belg

Í málsgreininni hér að ofan samþykktum við að einn Cassandra hnútur jafngildir einum belg í Kubernetes. En IP tölur belganna verða mismunandi í hvert skipti. Og auðkenning á hnút í Cassandra byggist á IP tölu... Það kemur í ljós að eftir hverja fjarlægingu á fræbelgi mun Cassandra þyrpingin bæta við nýjum hnút.

Það er leið út en ekki bara ein:

1. Við getum haldið skrár með hýsilauðkennum (UUID sem auðkenna Cassandra tilvik einstaklega) eða eftir IP tölum og geymt það allt í sumum mannvirkjum/töflum. Aðferðin hefur tvo megin ókosti:
   • Hættan á að keppnisástand komi upp ef tveir hnútar falla í einu. Eftir hækkunina munu Cassandra hnúðar samtímis biðja um IP tölu frá borðinu og keppa um sömu auðlindina.
   • Ef Cassandra hnútur hefur tapað gögnum sínum munum við ekki lengur geta borið kennsl á þau.
2. Önnur lausnin virðist vera lítið hakk, en engu að síður: við getum búið til þjónustu með ClusterIP fyrir hvern Cassandra hnút. Vandamál við þessa framkvæmd:
   • Ef það eru margir hnútar í Cassandra þyrpingunni verðum við að búa til fullt af þjónustu.
   • ClusterIP eiginleikinn er útfærður í gegnum iptables. Þetta getur orðið vandamál ef Cassandra þyrpingin hefur marga (1000... eða jafnvel 100?) hnúta. Samt jöfnun byggt á IPVS getur leyst þetta vandamál.
3. Þriðja lausnin er að nota net hnúta fyrir Cassandra hnúta í stað sérstakt net af fræbelg með því að virkja stillinguna hostNetwork: true. Þessi aðferð setur ákveðnar takmarkanir:
   • Til að skipta um einingar. Það er nauðsynlegt að nýi hnúturinn verði að hafa sömu IP tölu og sá fyrri (í skýjum eins og AWS, GCP er þetta næstum ómögulegt að gera);
   • Með því að nota net klasahnúta byrjum við að keppa um netauðlindir. Þess vegna verður erfitt að setja fleiri en einn fræbelg með Cassandra á einn klasahnút.

5. Afrit

Við viljum vista fulla útgáfu af gögnum eins Cassandra hnúts á áætlun. Kubernetes býður upp á þægilegan eiginleika með því að nota CronJob, en hér setur Cassandra sjálf sprotinn í hjólin okkar.

Leyfðu mér að minna þig á að Cassandra geymir hluta af gögnunum í minni. Til að taka fullt öryggisafrit þarftu gögn úr minni (Minningartöflur) færa á disk (SSTables). Á þessum tímapunkti hættir Cassandra hnúturinn að samþykkja tengingar og slokknar alveg á þyrpingunni.

Eftir þetta er öryggisafritið fjarlægt (skyndimynd) og kerfið er vistað (lyklarými). Og svo kemur í ljós að bara öryggisafrit gefur okkur ekki neitt: við þurfum að vista gagnaauðkennin sem Cassandra hnúturinn var ábyrgur fyrir - þetta eru sérstök tákn.

Dreifing tákna til að bera kennsl á hvaða gögn Cassandra hnútar bera ábyrgð á

Dæmi um handrit til að taka Cassandra öryggisafrit frá Google í Kubernetes er að finna á þessi tengill. Eini punkturinn sem handritið tekur ekki með í reikninginn er að endurstilla gögn á hnútinn áður en skyndimyndin er tekin. Það er, afritið er ekki framkvæmt fyrir núverandi ástand, heldur fyrir ástand aðeins fyrr. En þetta hjálpar til við að taka hnútinn ekki úr rekstri, sem virðist mjög rökrétt.

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

Dæmi um bash forskrift til að taka öryggisafrit frá einum Cassandra hnút

Tilbúnar lausnir fyrir Cassandra í Kubernetes

Hvað er nú notað til að dreifa Cassandra í Kubernetes og hver af þessum hentar best tilteknum kröfum?

1. Lausnir byggðar á StatefulSet eða Helm töflum

Að nota grunn StatefulSets aðgerðir til að keyra Cassandra þyrping er góður kostur. Með því að nota Helm töfluna og Go sniðmát geturðu veitt notandanum sveigjanlegt viðmót til að nota Cassandra.

Þetta virkar venjulega vel... þangað til eitthvað óvænt gerist, eins og hnútabilun. Hefðbundin Kubernetes verkfæri geta einfaldlega ekki tekið tillit til allra eiginleika sem lýst er hér að ofan. Að auki er þessi nálgun mjög takmörkuð hvað varðar hversu mikið er hægt að framlengja hana fyrir flóknari notkun: hnútaskipti, öryggisafrit, endurheimt, eftirlit osfrv.

Fulltrúar:

• Mynd frá aðal Helm geymslunni;
• Mynd frá bitnami.

Bæði töflurnar eru jafn góðar, en eru háðar vandamálunum sem lýst er hér að ofan.

2. Lausnir byggðar á Kubernetes Operator

Slíkir valkostir eru áhugaverðari vegna þess að þeir veita næg tækifæri til að stjórna klasanum. Til að hanna Cassandra rekstraraðila, eins og hvern annan gagnagrunn, lítur gott mynstur út eins og Sidecar <-> Controller <-> CRD:

Hnútastjórnunarkerfi í vel hönnuðum Cassandra rekstraraðila

Við skulum skoða núverandi rekstraraðila.

1. Cassandra-operator frá instaclustr

• GitHub
• Viðbúnaður: Alfa
• Leyfi: Apache 2.0
• Útfært í: Java

Þetta er sannarlega mjög efnilegt og virkt þróunarverkefni frá fyrirtæki sem býður upp á stýrða Cassandra dreifingu. Það, eins og lýst er hér að ofan, notar hliðarvagnaílát sem tekur við skipunum í gegnum HTTP. Skrifað í Java skortir það stundum fullkomnari virkni viðskiptavinar-fara bókasafnsins. Einnig styður rekstraraðilinn ekki mismunandi rekki fyrir eina gagnaver.

En rekstraraðilinn hefur kosti eins og stuðning við eftirlit, háþróaða klasastjórnun með CRD og jafnvel skjöl til að taka afrit.

2. Navigator frá Jetstack

• GitHub
• Viðbúnaður: Alfa
• Leyfi: Apache 2.0
• Útfært í: Golang

Yfirlýsing sem er hönnuð til að dreifa DB-as-a-Service. Styður sem stendur tvo gagnagrunna: Elasticsearch og Cassandra. Það hefur svo áhugaverðar lausnir eins og aðgangsstýringu gagnagrunns í gegnum RBAC (fyrir þetta hefur það sinn eigin navigator-apiserver). Áhugavert verkefni sem vert væri að skoða nánar, en síðasta skuldbindingin var gerð fyrir einu og hálfu ári, sem klárlega dregur úr möguleikum þess.

3. Cassandra-operator eftir vgkowski

• GitHub
• Viðbúnaður: Alfa
• Leyfi: Apache 2.0
• Útfært í: Golang

Þeir íhuguðu það ekki „alvarlega“ þar sem síðasta skuldbindingin til geymslunnar var fyrir meira en ári síðan. Þróun rekstraraðila er yfirgefin: nýjasta útgáfan af Kubernetes sem tilkynnt er að sé studd er 1.9.

4. Cassandra-stjórnandi eftir Rook

• GitHub
• Viðbúnaður: Alfa
• Leyfi: Apache 2.0
• Útfært í: Golang

Rekstraraðili þar sem þróunin gengur ekki eins hratt og við viljum. Það hefur úthugsaða CRD uppbyggingu fyrir klasastjórnun, leysir vandamálið við að bera kennsl á hnúta með því að nota þjónustu með ClusterIP (sama „hakk“) ... en það er allt í bili. Sem stendur er ekkert eftirlit eða afrit úr kassanum (við the vegur, við erum til að fylgjast með tók það sjálf). Áhugaverður punktur er að þú getur líka notað ScyllaDB með því að nota þennan rekstraraðila.

ATH: Við notuðum þennan rekstraraðila með smávægilegum breytingum í einu af verkefnum okkar. Ekki varð vart við nein vandamál í starfi rekstraraðila á öllu rekstrartímabilinu (~4 mánuðir í rekstri).

5. CassKop frá Orange

• GitHub
• Viðbúnaður: Alfa
• Leyfi: Apache 2.0
• Útfært í: Golang

Yngsti rekstraraðilinn á listanum: Fyrsta skuldbindingin var gerð 23. maí 2019. Nú þegar hefur það í vopnabúrinu mikinn fjölda eiginleika af listanum okkar, nánari upplýsingar um þá er að finna í verkefnageymslunni. Símafyrirtækið er byggt á grunni hins vinsæla rekstraraðila-sdk. Styður eftirlit úr kassanum. Helsti munurinn frá öðrum rekstraraðilum er notkunin CassKop viðbót, útfært í Python og notað fyrir samskipti milli Cassandra hnúta.

Niðurstöður

Fjöldi aðferða og mögulegra valkosta til að flytja Cassandra til Kubernetes talar sínu máli: efnið er eftirsótt.

Á þessu stigi geturðu prófað eitthvað af ofangreindu á eigin hættu og áhættu: enginn af hönnuðum ábyrgist 100% rekstur lausnar sinnar í framleiðsluumhverfi. En nú þegar virðast margar vörur vænlegar til að prófa að nota í þróunarbekkjum.

Ég held að í framtíðinni muni þessi kona á skipinu koma sér vel!

PS

Lestu líka á blogginu okkar:

• «Óaðfinnanlegur flutningur á MongoDB til Kubernetes»;
• «Óaðfinnanlegur flutningur RabbitMQ til Kubernetes»;
• «Gagnagrunnar og Kubernetes (endurskoðun og myndbandsskýrsla)»;
• «K8s ráð og brellur: Hraða upp ræsibúnaði fyrir stóra gagnagrunna'.

Heimild: www.habr.com