Առցանց Apache Cassandra տվյալների բազայի և Kubernetes ենթակառուցվածքի շրջանակներում նրա շահագործման անհրաժեշտության համար մենք պարբերաբար բախվում ենք խնդիրների: Այս նյութում կկիսվենք մեր տեսլականով անհրաժեշտ քայլերի, չափանիշների և ներկայիս լուծումների (ներառյալ օպերատորների ակնարկը) շուրջ, որոնք անհրաժեշտ են Cassandra-ն K8s տեղափոխելու համար:
«Ով կարող է կառավարել կնոջը, նա կտանի նաև պետությունը»
Ո quién es Cassandra? Դա բաշխված տվյալների պահեստավորման համակարգ է, որը նախատեսված է մեծ տվյալների ծավալների կառավարելու համար, ապահովելով բարձր հասանելիություն առանց մեկ կետի չզրկվելու: Նախագիծը, ամենայն հավանականությամբ, երկար ներկայացման կարիք չունի, ուստի միայն նշեմ Cassandra-ի հիմնական հատկությունները, որոնք pertinent են նշված հոդվածի համատեքստում:
- Cassandra-ն գրված է Java վրա:
- Cassandra-ի ենթակառուցվածքը ներառում է մի քանի մակարդակներ:
- Node — մեկ ինքնուրույն Cassandra օրինակ:
- Rack — Cassandra օրինակների խումբ, որը կապված է որևէ հատկանիշով՝ գտնվելու մեկ տվյալ կենտրոնում:
- Datacenter — բոլոր Cassandra օրինակների խումբ, որոնք գտնվում են մեկ տվյալ կենտրոնում:
- Cluster — բոլոր տվյալ կենտրոնների խումբ:
- Cassandra-ն օգտագործում է IP հասցե՝ խելացանկի իրականացման համար:
- Գրանցման և ընթերցման գործողությունների արագացման համար Cassandra տվյալների մի մասը պահում է միջևեց հուշում:
Հիմա՝ ուղղակի կրքերը Kubernetes-ի մեջ տեղափոխելու մասին:
Check-list՝ տեղափոխման համար
Թեև խոսում ենք Cassandra-ի տեղափոխման մասին Kubernetes-ում, ակնկալում ենք, որ տեղափոխումից հետո կառավարման գործընթացը ավելի հեշտ կլինի: Ինչ անհրաժեշտ կլինի այս գործընթացում, ինչ կարող է օգնել դրան:
1. Տվյալների պահոց
Ինչպես արդեն նշվել է, Cassandra-ն տվյալների մի մասը պահում է միջազգային հիշողության մեջ՝ MemtableՄանավանդ, բայց նաև տվյալների մեկ այլ մասը, որը պահվում է սկավառակի վրա՝ SSTableԱյս տվյալներին գումարվում է մի հատկություն՝ Commit Log — բոլոր գործարքների գրառումներ, որոնք նույնպես պահվում են սկավառակի վրա:
Cassandra-ում գրանցման գործարքների սխեման
Kubernetes-ում մենք կարող ենք օգտագործել տվյալների պահոց համար PersistentVolume: Կայացրինելով կատարելագործված մեխանիզմները՝ տվյալների հետ աշխատելը Kubernetes-ում ամեն տարի ավելի հեշտանում է:
Ամեն Cassandra pod-ին մենք կհատկացնենք մեր PersistentVolume-ն:
Անշուշտ, կարևոր է նշել, որ Cassandra-ն ինքն իրեն подразумевает տվյալների կրկնօրինակումը, առաջարկում է դրա համար ներառյալ մեխանիզմները: Այնպես որ, եթե դուք կառուցում եք Cassandra վանում մեծ քանակությամբ узлы, ապա տվյալների պահելու համար տարածված համակարգեր, ինչպիսիք են Ceph կամ GlusterFS օգտագործելը անհրաժեշտ չէ: Այս դեպքում ճիշտ կլինի պահել տվյալները узлы-ի սկավառակի վրա՝ օգտագործելով կամ մոնտաժումը՝ hostPath.
Իրավիճակն այլ է, եթե ցանկանաք ստեղծել յուրաքանչյուր feature-կլասի համար առանձին միջավայր ծրագրավորողների համար: Այս դեպքում ճիշտ մոտեցումը կլինի մեկ Cassandra հանգույց բարձրացնելն ու տվյալները պահել բաշխված պահպանման մեջ, այսինքն՝ նշված Ceph և GlusterFS դրանք կդառնան ձեր տարբերակը: Այդ դեպքում ծրագրավորը վստահ կլինի, որ չի կորցնի փորձնական տվյալները նույնիսկ մեկ Kuberntes կլաստերից մեկի կորուստի դեպքում:
2. Մոնիտորինգ
pract nagu yeghavein Kamur dhakungin peck ajastnerum kyst (dapragonu 3b yukh da midgeb anhsb khar ). Ես Cassandra-ի համար տարբերակիչների զբաղեցման վերաբերյալ ստանալը ինչպե՞ս է ստացվում Prometheus-ի համար։ Եվ ինչ-որ առումով, ավելի կարևորագույն հարց. ի՞նչ ենք անում Grafana-ի հետ այս բոլորին:
Grafana-ում Cassandra-ի գրանքների արտաքին տեսքը
Կա ընդամենը երկու արգասիք: և .
Մենք ընտրեցինք առաջինը, որովհետև՝
- JMX Exporter-ն աճում և զարգանում է, մինչդեռ Cassandra Exporter-ը չհաջողի անհրաժեշտ աջակցություն ստանալ: Cassandra Exporter-ը դեռևս չի աջակցում Cassandra-ի մեծամասշտաբ տարբերակներին.
- Մեր համար հնարավոր է սկսել դա որպես javaagent, ավելացնելով դրոշի
-javaagent:<plugin-dir-name>\/cassandra-exporter.jar=--listen=:9180. - Սրա համար կա , որը անհամատեղելի է Cassandra Exporter-ի հետ.
3. Կուբերնետս-ի պրիմիտիվների ընտրություն
Գոյություն ունեցող Cassandra կլաստերի կառուցվածքի հիման վրա, փորձենք վերածել ներկայացվածը Kubernetes-ի տերմինոլոգիայի:
- Cassandra Node → Pod
- Cassandra Rack → StatefulSet
- Cassandra Datacenter → StatefulSets-ի խումբ
- Cassandra Cluster → ???
Դուք ստանում եք, որ անհրաժեշտ է հավելյալ միավոր, որպեսզի կառավարենք Cassandra-ի ամբողջ կլաստերը մեկ անգամ, սակայն եթե ինչ-որ բան իրոք չկա, մենք կարող ենք դա ստեղծել: Kubernetes-ում դրա համար նախատեսված է հարմարեցված ռեսուրսների սահմանման մեխանիզմը՝ .
Լոգերի և ծանոթացումների համար հավելյալ ռեսուրսների հայտարարում
Բայց ինքնըստինքյան Custom Resource-ը ոչինչ չի նշանակում: Քանի որ դրա համար անհրաժեշտ է կոնտրոլյոր. Դա հնարավորություն կունենա օգտվել …
4. pod-երի նույնականացում
Վերին կետում մենք համաձայնեցինք, որ մեկ Cassandra հանգույցը կներկայանա մեկ pod-ի Kubernetes-ում: Բայց pod-երի IP հասցեները միշտ տարբեր են լինելու: Իսկ Cassandra-ում հանգույցների նույնականացումը կատարվում է IP հասցեի հիման վրա... Այնպես է ստացվում, որ յուրաքանչյուր pod-ի ջնջումից հետո Cassandra կլաստերը նոր հանգույց կավելացնի իր մեջ:
Ունենք ելք, և նույնիսկ ոչ մեկը:
- Մենք կարող ենք հաշվել հոսթերի նույնականացման համար (UUID-ներով, որոնք միանշանակ նույնականացնում են Cassandra օրինակները) կամ IP հասցեներով և պահել դրանք որևէ կառուցվածքներում/թերթերում: Այս մեթոդի երկու հիմնական թերություն կա:
- Կանխվելու ռիսկի պայմաններ, երբ միանգամից երկու հանգույց է ընդհատվում: Հավանաբար, Cassandra հանգույցներն այս ենթակառուցվածքը հետագայում պետք է IP հասցե կապահովեն իր համար:
- Եթե Cassandra հանգույցը կորցնում է իր տվյալները, ապա մենք այլևս այն չենք կարող նույնականացնել.
- Երկրորդ լուծումը փոքր հաք թերևս է, բայց այնուամենայնիվ. Մենք կարող ենք ստեղծել Service՝ ClusterIP յուրաքանչուր Cassandra նոդի համար: Այդ իրագործման խնդիրները.
- Եթե Cassandra կլաստերում շատ նոդեր կան, ստիպված ենք լինելու շատ Service-ներ ստեղծել:
- ClusterIP-ի ֆունկցոնալությունը իրականացվում է iptables-ի միջոցով: Սա կարող է խնդիր լինել, եթե Cassandra կլաստերում շատ (1000… կամ նույնիսկ 100?) նոդեր կան: Հպարտանալով: կարող է լուծել այս խնդիրը.
- Երրորդ լուծումն է օգտագործել Cassandra նոդերի համար նոդերի ցանց փոխարեն հատուկ pod-ի ցանց օգտագործելով կարգավորման ակտիվացման միջոցով
hostNetwork: true. Այս մեթոդը որոշակի սահմանափակումներ է դնում:- Նոդերի փոխարինման վրա: Պետք է, որ նոր նոդը unbedingt ունենա նույն IP հասցեն, ինչ նախորդը (պատրաստված ամպերում, օրինակ AWS, GCP դա իրականում գրեթե անհնար է անել);
- Օգտագործելով կլաստերային նոդերի ցանցը, սկսում ենք մրցակցել ցանցային ռեսուրսների համար: Թեև, մեկ նոդի վրա Cassandra-ի ավելի քան մեկ pod տեղադրել կլինի խնդիր:
5. Բեկապներ
Մենք ցանկանում ենք պահպանել Cassandra մեկ նոդի տվյալների լիակատար տարբերակը ժամանակացույցով: Kubernetes-ը տրամադրում է հարմար հնարավորություն՝ օգտագործելով , բայց այստեղ խոչընդոտում է հենց Cassandra-ն:
Հիշեցնենք, որ Cassandra տվյալների մի մասը պահում է հիշողությունում: Լիակատար բեկապ կատարելու համար անհրաժեշտ է տվյալները դուրս բերել հիշողությունից (Memtables) փոխանցելով սկավառակի (SSTables). Այս պահին Cassandra նոդը դադարում է ընդունել կապեր, լիովին դուրս գալիս կլաստերից:
Այդուհետ, վերցվում է բեկապ (snapshot) և պահվում է սխեմա (keyspace). Եվ այստեղ պարզվում է, որ պարզապես բեկապը ոչինչ չի տալիս մեզ. անհրաժեշտ է պահպանել տվյալների նույնականացնողները, որոնց համար պատասխանատու էր Cassandra նոդը՝ հատուկ տոմսերը:
Տոմսերի բաշխումը տվյալների, որին պատասխանատու են Cassandra նոդերը, նույնականացնելու համար:
Cassandra-ի բեկապի ցուցանական սկрипտի օրինակ կարելի է գտնել Google-ում Kubernetes-ում . Միակ պահը, որն այդ սկрипտը չի հաշվի առնում, դա տվյալների ընկերություն կատարելու է առաջ նկարի (snapshot)-ի առաջ: Այսինքն, բեկապը կատարվում է ոչ ներկայիս վիճակի, այլ մի փոքր առաջվա վիճակի համար: Բայց դա օգնում է դուրս բերել նոդը աշխատանքից, ինչը շատ տրամաբանական է թվում:
set -eu
if [[ -z "$1" ]]; then
info "Խնդրում ենք տրամադրել keyspace"
exit 1
fi
KEYSPACE="$1"
result=$(nodetool snapshot "${KEYSPACE}")
if [[ $? -ne 0 ]]; then
echo "Սխալ նկարահանման ընթացքում"
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}"Cassandra-ի մեկ նոդից բեկապ արվելու bash-սկիբտի օրինակ
Մաքուր լուծումներ Cassandra-ի համար Kubernetes-ում
Ինչ בכלל ներկայումս օգտագործում են Cassandra-ն Kubernetes-ում տեղադրելու համար և որњето որից ամենա ակտիվորեն համապատասխանում է հաստատված պահանջներին:
1. StatefulSet-ի կամ Helm-մանրա հիման վրա լուծումներ
Cassandra կլաստեր գործարկելու համար StatefulSets-ի հիմնական ֆունկցիաների օգտագործումը լավ տարբերակ է։ Helm-ի քարտեզի և Go-ի թաղանթի միջոցով կարելի է օգտվողին տրամադրել Cassandra-ն տեղակայելու ճկուն ինտերֆեյս։
Սա սովորաբար աշխատում է նորմալ… մինչև տեղի ունենա unexpected-ի նման մի բան՝ օրինակ, узлы-ից մեկի դուրս գալը։ Kubernetes-ի ստանդարտ գործիքներն פשוט չեն կարող հաշվի առնել վերոնշյալ բոլոր առանձնահատկությունները։ Դրա ընթացքում այս մոտեցումը շատ սահմանափակ է, որքանով կարող է ընդլայնվել ավելի բարդ օգտագործման համար՝ узлы-ի փոխարինում, բախվում, վերականգնում, մոնիթորինգ և այլն։
Ներկայացուցիչներ․
- ;
- .
Երկու քարտեզները նույնպես լավն են, սակայն ենթարկվում են վերոնշյալ խնդիրներին։
2. Kubernetes Operator-ի հիման վրա լուծումներ
Այս տարբերակները ավելի հետաքրքիր են, քանի որ տրամադրում են լայն հնարավորություն կլաստերների կառավարման համար։ Cassandra օպերատորի համար, ինչպես ցանկացած այլ տվյալների բազայի, լավ տեսակը նման է Sidecar Controller CRD․
Cassandra օպերատորի թույլատրելի узлыների կառավարումը ճիշտ մշակված օպերատորի մեջ
Կքննարկենք առկա օպերատորները։
1. instaclustr-ի Cassandra-օպերատոր
- Պատրաստ է․ Alpha
- Լիցենզիա: Apache 2.0
- Գործողության մեջ է՝ Java
Այս նախագիծը իսկապես շատ խոստումնալից և ակտիվ զարգացող նախագծի է, որը առաջարկում է կառավարվող Cassandra տեղադրում։ Այն, ինչպես վերևում նկարագրված է, օգտագործում է sidecar-կոնտեյներ, որը ընդունում է հրահանգներ HTTP-ի միջոցով։ Այն գրված է Java-ի վրա, ուստի երբեմն պակասում է client-go գրադարանի ավելի առաջադեմ ֆունկցիոնալությունը։ Նաեւ օպերատորը չի աջակցում տարբեր Racks մեկ Datacenter-ում։
Բայց օպերատորը ունի այնպիսի առավելություններ, ինչպիսիք են մոնիթորինգի աջակցությունը, CRD-ի միջոցով բարձր մակարդակի կլաստերի կառավարման աջակցությունը և նույնիսկ բեքապների հետ կապված փաստաթղթավորումը։
2. Jetstack-ի Navigator
- Պատրաստ է․ Alpha
- Լիցենզիա: Apache 2.0
- Գործողության մեջ է՝ Golang
Օպերատոր, որը նախատեսված է DB-as-a-Service տեղադրումի համար։ Այս պահի դրությամբ աջակցում է երկու տվյալների բազաների՝ Elasticsearch և Cassandra։ Այն ունի հետաքրքիր լուծման, ինչպիսին է տվյալների բազայի մուտք գործելու վերահսկումը RBAC-ի միջոցով (այդ նպատակով բարձրացվում է իր առանձին navigator-apiserver)। Սա հետաքրքիր նախագիծ է, որի վրա պետք է ուշադրություն դարձվի, սակայն վերջին կոմիտը կատարվել է 1.5 տարի առաջ, ինչը պարտադրողն է ծույլ դարձնելու։
3. vgkowski-ի Cassandra-օպերատոր
- Պատրաստ է․ Alpha
- Լիցենզիա: Apache 2.0
- Գործողության մեջ է՝ Golang
Անզիրյան չենք թողել «լուրջ» դիտարկել, քանի որ վերջնական կոմիտը ռեպոզիտորում եղել է մեկ տարուց ավելի առաջ։ Օպերատորի զարգացումը լքվել է. վերջին հայտարարված Kubernetes տարբերակը, որը համարվում է աջակցվող, 1.9-ն է։
4. Rook-ի Cassandra-օպերատոր
- Պատրաստ է․ Alpha
- Լիցենզիա: Apache 2.0
- Գործողության մեջ է՝ Golang
Օպերատորը զարգանում է այնքան արագ, որքան ցանկալի է։ Այն ունի լավ կառուցված CRD կլաստերի կառավարման համար, լուծում է узлы-ների ճանաչման խնդիրը ClusterIP-ի Service-ի միջոցով (այդ նույն «hacker»)․․․ բայց մինչ այժմ այս ամենն է։ Մոնիթորինգ եւ բեքապներ առկա չեն (մասնավորապես, մոնիթորինգի համար մենք ). Հար interesting момент, որ այս օպերատորի օգնությամբ հնարավոր է նաև ScyllaDB-ը զարգացնել։
NB: Այս օպերատորը որոշակի փոփոխություններով մենք օգտագործել ենք մեր նախագծերից մեկում։ Մասնակցման ընթացքում (~4 ամիս) օպերատորի աշխատանքի հետ կապված խնդիրներ չեն հայտնվել։
5. CassKop Orange-ից
- Պատրաստ է․ Alpha
- Լիցենզիա: Apache 2.0
- Գործողության մեջ է՝ Golang
List-ում ամենաերիտասարդ օպերատորը՝ առաջին կոմիտը տեղի է ունեցել 2019-ի մայիսի 23-ին։ Այժմ այն ունի իր սպառազինությունում մեզ հայտնի շատ ֆունկցիաներ, որոնց հետ կարող եք ծանոթանալ նախագծի ռեպոզիտորիայում։ Օպերատորը կառուցված է հանրահայտ operator-sdk-ի հիման վրա։ Ունի «արկղից դուրս» մոնիտորինգի աջակցություն։ Մնացած օպերատորներից հիմնական տարբերությունն է , որը մշակվել է Python-ում և օգտագործվում է Cassandra հանգույցների միջև հաղորդակցման համար։
Արդուկները
Կասկած չունեմ, որ Cassandra-ի Kubernetes-ում տեղափոխման տարբերակների բազմությունը արդեն ինքն է խոսում իր պահանջարկի մասին։
Այս փուլում վերը նկարագրվածներից որևէ բան փորձել կարելի է ձեր սեփական ռիսկի տակ. ոչ մի ծրագրավորող չի երաշխավորում 100%-ային աշխատանք իր լուծման պրոդուկտիվ միջավայրում։ Բայց արդեն շատ արտադրանքներ թվանում են խոստումնալից, որպեսզի փորձեք օգտագործել դրանք զարգացման շարքերում։
Ես կարծում եմ, որ այս կնոջը նավում ապագայում պարտադիր կլինի!
P.S.
Նաեւ կարդացեք մեր բլոգում:
- «»;
- «»;
- «»;
- «».
Ընտանիք: habr.com
