कॅसॅन्ड्राचे कुबर्नेट्समध्ये स्थलांतर: वैशिष्ट्ये आणि उपाय

आम्ही नियमितपणे Apache Cassandra डेटाबेसचा सामना करतो आणि तो Kubernetes-आधारित पायाभूत सुविधांमध्ये ऑपरेट करण्याची गरज आहे. या सामग्रीमध्ये, आम्ही कॅसॅन्ड्राचे K8s कडे स्थलांतर करण्यासाठी आवश्यक पावले, निकष आणि विद्यमान उपाय (ऑपरेटरच्या विहंगावलोकनासह) आमच्या दृष्टीकोन सामायिक करू.

"जो स्त्रीवर राज्य करू शकतो तो राज्यावरही राज्य करू शकतो"

कॅसांड्रा कोण आहे? ही एक वितरीत स्टोरेज प्रणाली आहे जी एकाही बिंदूच्या अपयशाशिवाय उच्च उपलब्धता सुनिश्चित करताना मोठ्या प्रमाणात डेटा व्यवस्थापित करण्यासाठी डिझाइन केलेली आहे. प्रकल्पाला क्वचितच दीर्घ परिचयाची आवश्यकता आहे, म्हणून मी कॅसॅन्ड्राची फक्त मुख्य वैशिष्ट्ये देईन जी विशिष्ट लेखाच्या संदर्भात संबंधित असतील:

• कॅसांड्रा हे जावामध्ये लिहिलेले आहे.
• कॅसॅन्ड्रा टोपोलॉजीमध्ये अनेक स्तरांचा समावेश आहे:
  • नोड - एक तैनात कॅसॅन्ड्रा उदाहरण;
  • रॅक हा कॅसॅंड्रा उदाहरणांचा एक समूह आहे, जो काही वैशिष्ट्यांद्वारे एकत्रित आहे, त्याच डेटा सेंटरमध्ये स्थित आहे;
  • डेटासेंटर - एका डेटा सेंटरमध्ये स्थित कॅसॅंड्रा उदाहरणांच्या सर्व गटांचा संग्रह;
  • क्लस्टर हा सर्व डेटा केंद्रांचा संग्रह आहे.
• Cassandra नोड ओळखण्यासाठी IP पत्ता वापरते.
• लेखन आणि वाचन क्रियांना गती देण्यासाठी, कॅसॅंड्रा काही डेटा RAM मध्ये संग्रहित करते.

आता - कुबर्नेट्सच्या वास्तविक संभाव्य हलवाकडे.

हस्तांतरणासाठी चेक-लिस्ट

कॅसॅन्ड्राच्या कुबरनेटेसच्या स्थलांतराबद्दल बोलताना, आम्हाला आशा आहे की या हालचालीमुळे ते व्यवस्थापित करणे अधिक सोयीस्कर होईल. यासाठी काय आवश्यक असेल, यासाठी काय मदत होईल?

1. डेटा स्टोरेज

आधीच स्पष्ट केल्याप्रमाणे, कॅसांडा डेटाचा काही भाग RAM - in मध्ये संग्रहित करते मेमटेबल. परंतु डेटाचा आणखी एक भाग आहे जो डिस्कवर जतन केला जातो - फॉर्ममध्ये SSTable. या डेटामध्ये एक घटक जोडला जातो कमिट लॉग — सर्व व्यवहारांचे रेकॉर्ड, जे डिस्कवर देखील जतन केले जातात.

कॅसँड्रामध्ये व्यवहार आकृती लिहा

Kubernetes मध्ये, डेटा संग्रहित करण्यासाठी आम्ही PersistentVolume वापरू शकतो. सिद्ध यंत्रणांबद्दल धन्यवाद, Kubernetes मधील डेटासह कार्य करणे दरवर्षी सोपे होत आहे.

आम्ही प्रत्येक कॅसॅन्ड्रा पॉडला आमचे स्वतःचे पर्सिस्टंट व्हॉल्यूम वाटप करू

हे लक्षात घेणे महत्त्वाचे आहे की कॅसॅन्ड्रा स्वतः डेटा प्रतिकृती सूचित करते, यासाठी अंगभूत यंत्रणा ऑफर करते. म्हणून, जर तुम्ही मोठ्या संख्येने नोड्समधून Cassandra क्लस्टर तयार करत असाल, तर डेटा स्टोरेजसाठी Ceph किंवा GlusterFS सारख्या वितरित प्रणाली वापरण्याची गरज नाही. या प्रकरणात, वापरून होस्ट डिस्कवर डेटा संग्रहित करणे तर्कसंगत असेल स्थानिक पर्सिस्टंट डिस्क किंवा माउंटिंग hostPath.

दुसरा प्रश्न असा आहे की तुम्हाला प्रत्येक वैशिष्ट्य शाखेसाठी विकसकांसाठी स्वतंत्र वातावरण तयार करायचे आहे का. या प्रकरणात, योग्य दृष्टीकोन म्हणजे एक कॅसॅन्ड्रा नोड वाढवणे आणि डेटा वितरित स्टोरेजमध्ये संग्रहित करणे, म्हणजे. नमूद केलेले Ceph आणि GlusterFS हे तुमचे पर्याय असतील. मग डेव्हलपरला खात्री असेल की कुबर्नटेस क्लस्टर नोड्सपैकी एक जरी हरवला तरीही तो चाचणी डेटा गमावणार नाही.

2. देखरेख

कुबर्नेट्समध्ये मॉनिटरिंग लागू करण्यासाठी अक्षरशः बिनविरोध निवड म्हणजे प्रोमिथियस (आम्ही याबद्दल तपशीलवार बोललो संबंधित अहवाल). कॅसॅन्ड्रा प्रोमिथियससाठी मेट्रिक्स निर्यातदारांसह कसे करत आहे? आणि, ग्राफानासाठी जुळणार्‍या डॅशबोर्डसह आणखी महत्त्वाचे काय आहे?

कॅसॅन्ड्रासाठी ग्राफनामध्ये आलेख दिसण्याचे उदाहरण

फक्त दोन निर्यातदार आहेत: जेएमएक्स_एक्सपोर्टर и cassandra_exporter.

आम्ही स्वतःसाठी पहिला निवडला कारण:

1. जेएमएक्स निर्यातक वाढत आणि विकसित होत आहेत, तर कॅसॅंड्रा निर्यातकांना पुरेसे समुदाय समर्थन मिळू शकलेले नाही. Cassandra Exporter अजूनही Cassandra च्या बर्‍याच आवृत्त्यांना समर्थन देत नाही.
2. ध्वज जोडून तुम्ही ते जावाजेंट म्हणून चालवू शकता -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. त्याच्यासाठी एक आहे पुरेसा डॅशबोर्ड, जे Cassandra Exporter शी विसंगत आहे.

3. Kubernetes primitives निवडणे

कॅसॅन्ड्रा क्लस्टरच्या वरील संरचनेनुसार, तेथे वर्णन केलेल्या प्रत्येक गोष्टीचे कुबर्नेट्स शब्दावलीमध्ये भाषांतर करण्याचा प्रयत्न करूया:

• कॅसॅन्ड्रा नोड → पॉड
• कॅसॅन्ड्रा रॅक → स्टेटफुलसेट
• स्टेटफुलसेट्स वरून कॅसॅन्ड्रा डेटासेंटर → पूल
• Cassandra क्लस्टर → ???

संपूर्ण Cassandra क्लस्टर एकाच वेळी व्यवस्थापित करण्यासाठी काही अतिरिक्त घटक गहाळ असल्याचे दिसून आले. पण जर काही अस्तित्वात नसेल तर आपण ते तयार करू शकतो! कुबर्नेट्सकडे या उद्देशासाठी स्वतःची संसाधने परिभाषित करण्याची यंत्रणा आहे - सानुकूल संसाधन व्याख्या.

नोंदी आणि सूचनांसाठी अतिरिक्त संसाधने घोषित करणे

परंतु सानुकूल संसाधनाचा स्वतःच काही अर्थ नाही: शेवटी, त्यासाठी आवश्यक आहे नियंत्रक. तुम्हाला मदत घ्यावी लागेल कुबर्नेट्स ऑपरेटर...

4. शेंगा ओळखणे

वरील परिच्छेदामध्ये, आम्ही सहमत झालो की एक कॅसॅन्ड्रा नोड कुबर्नेट्समधील एका पॉडच्या बरोबरीचा असेल. पण पॉड्सचे IP पत्ते प्रत्येक वेळी वेगळे असतील. आणि Cassandra मधील नोडची ओळख IP पत्त्यावर आधारित आहे... असे दिसून आले की प्रत्येक पॉड काढून टाकल्यानंतर, Cassandra क्लस्टर एक नवीन नोड जोडेल.

एक मार्ग आहे, आणि फक्त एक नाही:

1. आम्ही होस्ट आयडेंटिफायर्स (UUID जे कॅसॅन्ड्रा उदाहरणे अनन्यपणे ओळखतात) किंवा IP पत्त्यांद्वारे रेकॉर्ड ठेवू शकतो आणि ते सर्व काही संरचना/टेबलमध्ये संग्रहित करू शकतो. पद्धतीचे दोन मुख्य तोटे आहेत:
   • एकाच वेळी दोन नोड्स पडल्यास शर्यतीची स्थिती निर्माण होण्याचा धोका. वाढ झाल्यानंतर, कॅसॅंड्रा नोड्स एकाच वेळी टेबलवरून आयपी पत्त्याची विनंती करतील आणि त्याच संसाधनासाठी स्पर्धा करतील.
   • Cassandra नोडने त्याचा डेटा गमावला असल्यास, आम्ही यापुढे तो ओळखण्यास सक्षम राहणार नाही.
2. दुसरा उपाय लहान हॅकसारखा दिसतो, परंतु तरीही: आम्ही प्रत्येक कॅसॅंड्रा नोडसाठी क्लस्टरआयपीसह सेवा तयार करू शकतो. या अंमलबजावणीमध्ये समस्या:
   • Cassandra क्लस्टरमध्ये भरपूर नोड्स असल्यास, आम्हाला बर्‍याच सेवा तयार कराव्या लागतील.
   • क्लस्टरआयपी वैशिष्ट्य iptables द्वारे लागू केले आहे. Cassandra क्लस्टरमध्ये अनेक (1000... किंवा 100?) नोड्स असल्यास ही समस्या होऊ शकते. तरी IPVS वर आधारित संतुलन या समस्येचे निराकरण करू शकता.
3. तिसरा उपाय म्हणजे सेटिंग सक्षम करून पॉड्सच्या समर्पित नेटवर्कऐवजी कॅसॅंड्रा नोड्ससाठी नोड्सचे नेटवर्क वापरणे. hostNetwork: true. ही पद्धत काही मर्यादा लादते:
   • युनिट्स बदलण्यासाठी. हे आवश्यक आहे की नवीन नोडमध्ये मागील प्रमाणेच IP पत्ता असणे आवश्यक आहे (एडब्ल्यूएस, जीसीपी सारख्या क्लाउडमध्ये हे करणे जवळजवळ अशक्य आहे);
   • क्लस्टर नोड्सचे नेटवर्क वापरून, आम्ही नेटवर्क संसाधनांसाठी स्पर्धा करू लागतो. म्हणून, एका क्लस्टर नोडवर कॅसॅन्ड्रासह एकापेक्षा जास्त पॉड ठेवणे समस्याप्रधान असेल.

5. बॅकअप

आम्हाला शेड्यूलवर एकाच कॅसॅन्ड्रा नोडच्या डेटाची संपूर्ण आवृत्ती जतन करायची आहे. Kubernetes वापरून एक सोयीस्कर वैशिष्ट्य प्रदान करते क्रोनजॉब, पण इथे कॅसॅन्ड्रा स्वतः आमच्या चाकांमध्ये स्पोक ठेवते.

मी तुम्हाला आठवण करून देतो की कॅसॅंड्रा मेमरीमध्ये काही डेटा संग्रहित करते. पूर्ण बॅकअप घेण्यासाठी, तुम्हाला मेमरीमधील डेटा आवश्यक आहे (मेमटेबल्स) डिस्कवर हलवा (SSTables). या टप्प्यावर, कॅसॅंड्रा नोड कनेक्शन स्वीकारणे थांबवते, क्लस्टरमधून पूर्णपणे बंद होते.

यानंतर, बॅकअप काढला जातो (स्नॅपशॉट) आणि योजना जतन केली जाते (कीस्पेस). आणि मग असे दिसून आले की फक्त बॅकअप आम्हाला काहीही देत ​​नाही: आम्हाला डेटा आयडेंटिफायर जतन करणे आवश्यक आहे ज्यासाठी कॅसॅंड्रा नोड जबाबदार होता - हे विशेष टोकन आहेत.

कॅसॅंड्रा नोड्स कोणत्या डेटासाठी जबाबदार आहेत हे ओळखण्यासाठी टोकनचे वितरण

कुबर्नेट्समध्ये Google वरून कॅसॅंड्रा बॅकअप घेण्यासाठी उदाहरण स्क्रिप्ट येथे आढळू शकते हा दुवा. स्नॅपशॉट घेण्यापूर्वी नोडवर डेटा रीसेट करणे हा एकच मुद्दा स्क्रिप्ट विचारात घेत नाही. म्हणजेच, बॅकअप सध्याच्या स्थितीसाठी नाही, परंतु थोड्या पूर्वीच्या स्थितीसाठी केला जातो. परंतु हे नोडला ऑपरेशनमधून बाहेर न घेण्यास मदत करते, जे खूप तार्किक वाटते.

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

एका कॅसॅंड्रा नोडमधून बॅकअप घेण्यासाठी बॅश स्क्रिप्टचे उदाहरण

कुबर्नेट्समधील कॅसॅन्ड्रासाठी तयार उपाय

कुबर्नेट्समध्ये कॅसॅन्ड्रा तैनात करण्यासाठी सध्या काय वापरले जाते आणि यापैकी कोणते सर्वोत्कृष्ट आवश्यकतांनुसार आहेत?

1. स्टेटफुलसेट किंवा हेल्म चार्टवर आधारित उपाय

कॅसॅन्ड्रा क्लस्टर चालवण्यासाठी मूलभूत स्टेटफुलसेट्स फंक्शन्स वापरणे हा एक चांगला पर्याय आहे. हेल्म चार्ट आणि गो टेम्प्लेट्स वापरून, तुम्ही कॅसॅंड्रा तैनात करण्यासाठी वापरकर्त्याला लवचिक इंटरफेस प्रदान करू शकता.

हे सहसा चांगले कार्य करते... जोपर्यंत काहीतरी अनपेक्षित घडत नाही, जसे की नोड अपयश. मानक Kubernetes साधने फक्त वर वर्णन केलेली सर्व वैशिष्ट्ये विचारात घेऊ शकत नाहीत. याव्यतिरिक्त, हा दृष्टीकोन अधिक जटिल वापरांसाठी किती विस्तारित केला जाऊ शकतो याबद्दल खूप मर्यादित आहे: नोड बदलणे, बॅकअप, पुनर्प्राप्ती, निरीक्षण इ.

प्रतिनिधी:

• मुख्य हेल्म रेपॉजिटरीमधील चार्ट;
• बिटनामी वरून चार्ट.

दोन्ही चार्ट तितकेच चांगले आहेत, परंतु वर वर्णन केलेल्या समस्यांच्या अधीन आहेत.

2. Kubernetes ऑपरेटरवर आधारित उपाय

असे पर्याय अधिक मनोरंजक आहेत कारण ते क्लस्टर व्यवस्थापित करण्यासाठी भरपूर संधी प्रदान करतात. Cassandra ऑपरेटर डिझाइन करण्यासाठी, इतर डेटाबेसप्रमाणे, एक चांगला नमुना साइडकार <-> कंट्रोलर <-> CRD सारखा दिसतो:

चांगल्या प्रकारे डिझाइन केलेल्या कॅसॅंड्रा ऑपरेटरमध्ये नोड व्यवस्थापन योजना

चला विद्यमान ऑपरेटर पाहू.

1. instaclust वरून Cassandra-operator

• GitHub
• तयारी: अल्फा
• परवाना: Apache 2.0
• मध्ये लागू: Java

व्यवस्थापित कॅसॅंड्रा तैनाती ऑफर करणार्‍या कंपनीकडून हा खरोखरच एक अतिशय आशादायक आणि सक्रियपणे विकसित होणारा प्रकल्प आहे. हे, वर वर्णन केल्याप्रमाणे, साइडकार कंटेनर वापरते जे HTTP द्वारे आदेश स्वीकारते. Java मध्ये लिहिलेले, त्यात कधीकधी क्लायंट-गो लायब्ररीची अधिक प्रगत कार्यक्षमता नसते. तसेच, ऑपरेटर एका डेटासेंटरसाठी वेगवेगळ्या रॅकचे समर्थन करत नाही.

परंतु ऑपरेटरकडे मॉनिटरिंगसाठी समर्थन, CRD वापरून उच्च-स्तरीय क्लस्टर व्यवस्थापन आणि बॅकअप तयार करण्यासाठी दस्तऐवजीकरण असे फायदे आहेत.

2. जेटस्टॅक वरून नेव्हिगेटर

• GitHub
• तयारी: अल्फा
• परवाना: Apache 2.0
• मध्ये लागू: गोलंग

डीबी-ए-ए-सर्व्हिस तैनात करण्यासाठी डिझाइन केलेले विधान. सध्या दोन डेटाबेसेसचे समर्थन करते: Elasticsearch आणि Cassandra. यात RBAC द्वारे डेटाबेस ऍक्सेस कंट्रोल सारखे मनोरंजक उपाय आहेत (यासाठी त्याचे स्वतःचे स्वतंत्र नेव्हिगेटर-एपिसर्व्हर आहे). एक मनोरंजक प्रकल्प ज्याकडे जवळून पाहण्यासारखे आहे, परंतु शेवटचे वचन दीड वर्षापूर्वी केले गेले होते, जे स्पष्टपणे त्याची क्षमता कमी करते.

3. vgkowski द्वारे Cassandra-ऑपरेटर

• GitHub
• तयारी: अल्फा
• परवाना: Apache 2.0
• मध्ये लागू: गोलंग

त्यांनी याचा "गंभीरपणे" विचार केला नाही, कारण रेपॉजिटरीशी शेवटची वचनबद्धता एक वर्षापूर्वी होती. ऑपरेटर डेव्हलपमेंट सोडले आहे: कुबर्नेट्सची नवीनतम आवृत्ती 1.9 आहे.

4. रुक द्वारे Cassandra-ऑपरेटर

• GitHub
• तयारी: अल्फा
• परवाना: Apache 2.0
• मध्ये लागू: गोलंग

एक ऑपरेटर ज्याचा विकास आम्हाला पाहिजे तितक्या वेगाने होत नाही. क्लस्टर मॅनेजमेंटसाठी यात एक सुविचारित CRD रचना आहे, क्लस्टरआयपी (समान "हॅक") वापरून नोड्स ओळखण्याची समस्या सोडवते... पण आत्तासाठी एवढेच आहे. सध्या कोणतेही निरीक्षण किंवा बॅकअप बॉक्सच्या बाहेर नाही (तसे, आम्ही देखरेखीसाठी आहोत ते आम्ही स्वतः घेतले). एक मनोरंजक मुद्दा असा आहे की तुम्ही हा ऑपरेटर वापरून ScyllaDB देखील तैनात करू शकता.

NB: आम्ही आमच्या एका प्रकल्पात किरकोळ बदलांसह हा ऑपरेटर वापरला. ऑपरेशनच्या संपूर्ण कालावधीत (~4 महिने ऑपरेशन) ऑपरेटरच्या कामात कोणतीही समस्या लक्षात आली नाही.

5. नारिंगी पासून CassKop

• GitHub
• तयारी: अल्फा
• परवाना: Apache 2.0
• मध्ये लागू: गोलंग

यादीतील सर्वात तरुण ऑपरेटर: पहिली कमिट 23 मे 2019 रोजी करण्यात आली. आधीच आता त्याच्या शस्त्रागारात आमच्या सूचीमधून मोठ्या प्रमाणात वैशिष्ट्ये आहेत, ज्याचे अधिक तपशील प्रकल्प भांडारात आढळू शकतात. ऑपरेटर लोकप्रिय ऑपरेटर-sdk च्या आधारावर तयार केला आहे. बॉक्सच्या बाहेर निरीक्षणास समर्थन देते. इतर ऑपरेटरमधील मुख्य फरक म्हणजे वापर CassKop प्लगइन, Python मध्ये लागू केले आणि Cassandra नोड्समधील संवादासाठी वापरले.

निष्कर्ष

कॅसॅन्ड्राला कुबर्नेट्समध्ये पोर्ट करण्यासाठी दृष्टिकोन आणि संभाव्य पर्यायांची संख्या स्वतःच बोलते: विषय मागणीत आहे.

या टप्प्यावर, तुम्ही तुमच्या स्वत:च्या जोखमीवर आणि जोखमीवर वरीलपैकी कोणताही प्रयत्न करू शकता: कोणताही विकासक उत्पादन वातावरणात त्यांच्या सोल्यूशनच्या 100% ऑपरेशनची हमी देत ​​नाही. परंतु आधीच, अनेक उत्पादने विकास बेंचमध्ये वापरण्याचा प्रयत्न करण्यासाठी आशादायक दिसतात.

मला वाटतं भविष्यात जहाजावरील ही बाई कामी येईल!

PS

आमच्या ब्लॉगवर देखील वाचा:

• «मोंगोडीबीचे कुबर्नेट्समध्ये अखंड स्थलांतर";
• «RabbitMQ चे Kubernetes मध्ये अखंड स्थलांतर";
• «डेटाबेस आणि कुबर्नेट्स (पुनरावलोकन आणि व्हिडिओ अहवाल)";
• «K8s टिपा आणि युक्त्या: मोठ्या डेटाबेससाठी बूटस्ट्रॅपचा वेग वाढवणे».

स्त्रोत: www.habr.com