कैसेंड्रा का कुबेरनेट्स में प्रवासन: विशेषताएं और समाधान

हम नियमित रूप से अपाचे कैसेंड्रा डेटाबेस और कुबेरनेट्स-आधारित बुनियादी ढांचे के भीतर इसे संचालित करने की आवश्यकता का सामना करते हैं। इस सामग्री में, हम कैसेंड्रा को K8s में स्थानांतरित करने के लिए आवश्यक कदमों, मानदंडों और मौजूदा समाधानों (ऑपरेटरों के अवलोकन सहित) के बारे में अपना दृष्टिकोण साझा करेंगे।

"जो एक महिला पर शासन कर सकता है वह राज्य पर भी शासन कर सकता है"

कैसेंड्रा कौन है? यह एक वितरित भंडारण प्रणाली है जिसे विफलता के एक भी बिंदु के बिना उच्च उपलब्धता सुनिश्चित करते हुए बड़ी मात्रा में डेटा का प्रबंधन करने के लिए डिज़ाइन किया गया है। परियोजना को शायद ही लंबे परिचय की आवश्यकता है, इसलिए मैं कैसेंड्रा की केवल मुख्य विशेषताएं दूंगा जो एक विशिष्ट लेख के संदर्भ में प्रासंगिक होंगी:

• कैसंड्रा जावा में लिखा गया है।
• कैसेंड्रा टोपोलॉजी में कई स्तर शामिल हैं:
  • नोड - एक तैनात कैसेंड्रा उदाहरण;
  • रैक कैसेंड्रा उदाहरणों का एक समूह है, जो कुछ विशेषताओं से एकजुट होता है, जो एक ही डेटा सेंटर में स्थित होता है;
  • डेटासेंटर - एक डेटा सेंटर में स्थित कैसेंड्रा उदाहरणों के सभी समूहों का संग्रह;
  • क्लस्टर सभी डेटा केंद्रों का एक संग्रह है।
• कैसेंड्रा एक नोड की पहचान करने के लिए एक आईपी पते का उपयोग करता है।
• लिखने और पढ़ने के कार्यों को तेज़ करने के लिए, कैसेंड्रा कुछ डेटा को रैम में संग्रहीत करता है।

अब - कुबेरनेट्स की वास्तविक संभावित चाल के बारे में।

स्थानांतरण के लिए जाँच सूची

कैसेंड्रा के कुबेरनेट्स में प्रवास के बारे में बोलते हुए, हमें उम्मीद है कि इस कदम से इसे प्रबंधित करना अधिक सुविधाजनक हो जाएगा। इसके लिए क्या आवश्यक होगा, इससे क्या मदद मिलेगी?

1. डेटा भंडारण

जैसा कि पहले ही स्पष्ट किया जा चुका है, कैसांडा डेटा का कुछ हिस्सा रैम में संग्रहीत करता है स्मरणीय. लेकिन डेटा का एक और हिस्सा है जो डिस्क पर सहेजा जाता है - फॉर्म में एसएसटेबल. इस डेटा में एक इकाई जोड़ी जाती है प्रतिबद्ध लॉग - सभी लेन-देन के रिकॉर्ड, जो डिस्क में भी सहेजे जाते हैं।

कैसेंड्रा में लेनदेन आरेख लिखें

Kubernetes में, हम डेटा संग्रहीत करने के लिए PersistentVolume का उपयोग कर सकते हैं। सिद्ध तंत्रों की बदौलत, कुबेरनेट्स में डेटा के साथ काम करना हर साल आसान होता जा रहा है।

हम कैसंड्रा के साथ प्रत्येक पॉड को उसका अपना पर्सिस्टेंट वॉल्यूम आवंटित करेंगे

यह ध्यान रखना महत्वपूर्ण है कि कैसेंड्रा स्वयं डेटा प्रतिकृति का तात्पर्य करता है, इसके लिए अंतर्निहित तंत्र की पेशकश करता है। इसलिए, यदि आप बड़ी संख्या में नोड्स से कैसेंड्रा क्लस्टर बना रहे हैं, तो डेटा भंडारण के लिए सेफ या ग्लस्टरएफएस जैसे वितरित सिस्टम का उपयोग करने की कोई आवश्यकता नहीं है। इस मामले में, होस्ट डिस्क पर डेटा संग्रहीत करना तर्कसंगत होगा स्थानीय लगातार डिस्क या माउंटिंग hostPath.

एक अन्य प्रश्न यह है कि क्या आप प्रत्येक फीचर शाखा के लिए डेवलपर्स के लिए एक अलग वातावरण बनाना चाहते हैं। इस मामले में, सही दृष्टिकोण एक कैसेंड्रा नोड को बढ़ाना और डेटा को एक वितरित भंडारण में संग्रहीत करना होगा, यानी। उल्लिखित सेफ और ग्लस्टरएफएस आपके विकल्प होंगे। तब डेवलपर यह सुनिश्चित कर लेगा कि कुबेरनेट्स क्लस्टर नोड्स में से एक खो जाने पर भी वह परीक्षण डेटा नहीं खोएगा।

2. निगरानी

कुबेरनेट्स में निगरानी लागू करने के लिए वस्तुतः निर्विरोध विकल्प प्रोमेथियस है (हमने इस बारे में विस्तार से बात की संबंधित रिपोर्ट). कैसेंड्रा प्रोमेथियस के लिए मेट्रिक्स निर्यातकों के साथ कैसा काम कर रही है? और, ग्राफाना के लिए मिलान वाले डैशबोर्ड से भी अधिक महत्वपूर्ण क्या है?

कैसेंड्रा के लिए ग्राफाना में ग्राफ़ की उपस्थिति का एक उदाहरण

केवल दो निर्यातक हैं: jmx_निर्यातक и कैसेंड्रा_निर्यातक.

हमने अपने लिए पहला चुना क्योंकि:

1. जेएमएक्स एक्सपोर्टर बढ़ रहा है और विकास कर रहा है, जबकि कैसेंड्रा एक्सपोर्टर को पर्याप्त सामुदायिक समर्थन नहीं मिल पाया है। कैसेंड्रा एक्सपोर्टर अभी भी कैसेंड्रा के अधिकांश संस्करणों का समर्थन नहीं करता है।
2. आप इसे फ़्लैग जोड़कर javaagent के रूप में चला सकते हैं -javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180.
3. उसके लिए एक है पर्याप्त डैशबोर्ड, जो कैसेंड्रा एक्सपोर्टर के साथ असंगत है।

3. कुबेरनेट्स आदिमों का चयन करना

कैसेंड्रा क्लस्टर की उपरोक्त संरचना के अनुसार, आइए वहां वर्णित हर चीज का कुबेरनेट्स शब्दावली में अनुवाद करने का प्रयास करें:

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

यह पता चला है कि पूरे कैसेंड्रा क्लस्टर को एक साथ प्रबंधित करने के लिए कुछ अतिरिक्त इकाई गायब है। लेकिन अगर कोई चीज़ अस्तित्व में नहीं है, तो हम उसे बना सकते हैं! कुबेरनेट्स के पास इस उद्देश्य के लिए अपने स्वयं के संसाधनों को परिभाषित करने के लिए एक तंत्र है - कस्टम संसाधन परिभाषाएँ.

लॉग और अलर्ट के लिए अतिरिक्त संसाधनों की घोषणा करना

लेकिन कस्टम संसाधन का अपने आप में कोई मतलब नहीं है: आखिरकार, इसकी आवश्यकता है नियंत्रक. आपको मदद लेने की आवश्यकता हो सकती है कुबेरनेट्स ऑपरेटर...

4. फलियों की पहचान

उपरोक्त पैराग्राफ में, हम इस बात पर सहमत हुए कि एक कैसेंड्रा नोड कुबेरनेट्स में एक पॉड के बराबर होगा। लेकिन पॉड्स का आईपी एड्रेस हर बार अलग होगा। और कैसेंड्रा में एक नोड की पहचान आईपी पते पर आधारित है... यह पता चला है कि प्रत्येक पॉड को हटाने के बाद, कैसेंड्रा क्लस्टर एक नया नोड जोड़ देगा।

वहाँ एक रास्ता है, और सिर्फ एक ही नहीं:

1. हम होस्ट पहचानकर्ताओं (यूयूआईडी जो विशिष्ट रूप से कैसेंड्रा उदाहरणों की पहचान करते हैं) या आईपी पते द्वारा रिकॉर्ड रख सकते हैं और इसे कुछ संरचनाओं/तालिकाओं में संग्रहीत कर सकते हैं। इस विधि के दो मुख्य नुकसान हैं:
   • यदि दो नोड एक साथ गिरते हैं तो दौड़ की स्थिति उत्पन्न होने का जोखिम होता है। वृद्धि के बाद, कैसेंड्रा नोड्स एक साथ तालिका से एक आईपी पते का अनुरोध करेंगे और उसी संसाधन के लिए प्रतिस्पर्धा करेंगे।
   • यदि कैसेंड्रा नोड ने अपना डेटा खो दिया है, तो हम अब इसकी पहचान नहीं कर पाएंगे।
2. दूसरा समाधान एक छोटी सी हैक की तरह लगता है, लेकिन फिर भी: हम प्रत्येक कैसेंड्रा नोड के लिए क्लस्टरआईपी के साथ एक सेवा बना सकते हैं। इस कार्यान्वयन में समस्याएँ:
   • यदि कैसेंड्रा क्लस्टर में बहुत सारे नोड हैं, तो हमें बहुत सारी सेवाएँ बनानी होंगी।
   • क्लस्टरआईपी सुविधा iptables के माध्यम से कार्यान्वित की जाती है। यदि कैसेंड्रा क्लस्टर में कई (1000... या 100?) नोड हों तो यह एक समस्या बन सकती है। हालांकि आईपीवीएस पर आधारित संतुलन इस समस्या का समाधान कर सकते हैं.
3. तीसरा समाधान सेटिंग को सक्षम करके पॉड्स के समर्पित नेटवर्क के बजाय कैसेंड्रा नोड्स के लिए नोड्स के नेटवर्क का उपयोग करना है hostNetwork: true. यह विधि कुछ सीमाएँ लगाती है:
   • इकाइयों को बदलने के लिए. यह आवश्यक है कि नए नोड का IP पता पिछले नोड के समान होना चाहिए (AWS, GCP जैसे क्लाउड में ऐसा करना लगभग असंभव है);
   • क्लस्टर नोड्स के नेटवर्क का उपयोग करके, हम नेटवर्क संसाधनों के लिए प्रतिस्पर्धा करना शुरू करते हैं। इसलिए, एक क्लस्टर नोड पर कैसेंड्रा के साथ एक से अधिक पॉड रखना समस्याग्रस्त होगा।

5. बैकअप

हम एक शेड्यूल पर एकल कैसेंड्रा नोड के डेटा का पूर्ण संस्करण सहेजना चाहते हैं। Kubernetes का उपयोग करके एक सुविधाजनक सुविधा प्रदान करता है क्रॉन नौकरी, लेकिन यहां कैसेंड्रा खुद हमारे पहियों में एक स्पोक लगाती है।

मैं आपको याद दिला दूं कि कैसंड्रा कुछ डेटा को मेमोरी में संग्रहीत करता है। पूर्ण बैकअप बनाने के लिए, आपको मेमोरी से डेटा की आवश्यकता होगी (स्मरणीय वस्तुएँ) डिस्क पर ले जाएँ (एसएसटेबल्स). इस बिंदु पर, कैसेंड्रा नोड कनेक्शन स्वीकार करना बंद कर देता है, क्लस्टर से पूरी तरह से बंद हो जाता है।

इसके बाद, बैकअप हटा दिया जाता है (स्नैपशॉट) और योजना सहेजी गई है (keyspace). और फिर यह पता चला कि केवल बैकअप से हमें कुछ नहीं मिलता: हमें डेटा पहचानकर्ताओं को सहेजने की ज़रूरत है जिसके लिए कैसेंड्रा नोड ज़िम्मेदार था - ये विशेष टोकन हैं।

कैसेंड्रा नोड्स किस डेटा के लिए जिम्मेदार हैं, इसकी पहचान करने के लिए टोकन का वितरण

कुबेरनेट्स में 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. स्टेटफुलसेट या हेल्म चार्ट पर आधारित समाधान

कैसेंड्रा क्लस्टर चलाने के लिए बुनियादी स्टेटफुलसेट्स फ़ंक्शंस का उपयोग करना एक अच्छा विकल्प है। हेल्म चार्ट और गो टेम्प्लेट का उपयोग करके, आप उपयोगकर्ता को कैसेंड्रा को तैनात करने के लिए एक लचीला इंटरफ़ेस प्रदान कर सकते हैं।

यह आमतौर पर ठीक काम करता है... जब तक कुछ अप्रत्याशित नहीं होता, जैसे नोड विफलता। मानक कुबेरनेट्स उपकरण ऊपर वर्णित सभी सुविधाओं को ध्यान में नहीं रख सकते हैं। इसके अतिरिक्त, यह दृष्टिकोण बहुत सीमित है कि इसे अधिक जटिल उपयोगों के लिए कितना बढ़ाया जा सकता है: नोड प्रतिस्थापन, बैकअप, पुनर्प्राप्ति, निगरानी, ​​​​आदि।

प्रतिनिधि:

• मुख्य हेल्म भंडार से चार्ट;
• बिटनामी से चार्ट.

दोनों चार्ट समान रूप से अच्छे हैं, लेकिन ऊपर वर्णित समस्याओं के अधीन हैं।

2. कुबेरनेट्स ऑपरेटर पर आधारित समाधान

ऐसे विकल्प अधिक दिलचस्प हैं क्योंकि वे क्लस्टर के प्रबंधन के लिए पर्याप्त अवसर प्रदान करते हैं। कैसेंड्रा ऑपरेटर को डिजाइन करने के लिए, किसी भी अन्य डेटाबेस की तरह, एक अच्छा पैटर्न साइडकार <-> नियंत्रक <-> सीआरडी जैसा दिखता है:

एक अच्छी तरह से डिज़ाइन किए गए कैसेंड्रा ऑपरेटर में नोड प्रबंधन योजना

आइए मौजूदा ऑपरेटरों पर नजर डालें।

1. इंस्टाक्लस्टर से कैसेंड्रा-ऑपरेटर

• GitHub
• तत्परता: अल्फ़ा
• लाइसेंस: अपाचे 2.0
• में कार्यान्वित: जावा

यह वास्तव में एक कंपनी की ओर से एक बहुत ही आशाजनक और सक्रिय रूप से विकसित होने वाली परियोजना है जो प्रबंधित कैसेंड्रा तैनाती की पेशकश करती है। जैसा कि ऊपर वर्णित है, यह एक साइडकार कंटेनर का उपयोग करता है जो HTTP के माध्यम से कमांड स्वीकार करता है। जावा में लिखा गया, इसमें कभी-कभी क्लाइंट-गो लाइब्रेरी की अधिक उन्नत कार्यक्षमता का अभाव होता है। साथ ही, ऑपरेटर एक डेटासेंटर के लिए अलग-अलग रैक का समर्थन नहीं करता है।

लेकिन ऑपरेटर के पास निगरानी के लिए समर्थन, सीआरडी का उपयोग करके उच्च-स्तरीय क्लस्टर प्रबंधन और यहां तक ​​कि बैकअप बनाने के लिए दस्तावेज़ीकरण जैसे फायदे हैं।

2. जेटस्टैक से नेविगेटर

• GitHub
• तत्परता: अल्फ़ा
• लाइसेंस: अपाचे 2.0
• में कार्यान्वित: गोलांग

डीबी-ए-ए-सर्विस को तैनात करने के लिए डिज़ाइन किया गया एक बयान। वर्तमान में दो डेटाबेस का समर्थन करता है: इलास्टिक्स खोज और कैसेंड्रा। इसमें आरबीएसी के माध्यम से डेटाबेस एक्सेस कंट्रोल जैसे दिलचस्प समाधान हैं (इसके लिए इसका अपना अलग नेविगेटर-एपिसर्वर है)। एक दिलचस्प परियोजना जिस पर करीब से नज़र डालने लायक होगा, लेकिन आखिरी प्रतिबद्धता डेढ़ साल पहले की गई थी, जो स्पष्ट रूप से इसकी क्षमता को कम कर देती है।

3. कैसेंड्रा-ऑपरेटर वीजीकोव्स्की द्वारा

• GitHub
• तत्परता: अल्फ़ा
• लाइसेंस: अपाचे 2.0
• में कार्यान्वित: गोलांग

उन्होंने इस पर "गंभीरता से" विचार नहीं किया, क्योंकि भंडार के लिए अंतिम प्रतिबद्धता एक वर्ष से अधिक समय पहले की गई थी। ऑपरेटर विकास को छोड़ दिया गया है: समर्थित के रूप में रिपोर्ट किया गया कुबेरनेट्स का नवीनतम संस्करण 1.9 है।

4. कैसेंड्रा-ऑपरेटर रूक द्वारा

• GitHub
• तत्परता: अल्फ़ा
• लाइसेंस: अपाचे 2.0
• में कार्यान्वित: गोलांग

एक ऑपरेटर जिसका विकास उतनी तेजी से नहीं हो रहा है जितना हम चाहेंगे। इसमें क्लस्टर प्रबंधन के लिए एक सुविचारित सीआरडी संरचना है, जो क्लस्टरआईपी (वही "हैक") के साथ सेवा का उपयोग करके नोड्स की पहचान करने की समस्या को हल करती है... लेकिन अभी के लिए बस इतना ही। वर्तमान में बॉक्स से बाहर कोई निगरानी या बैकअप नहीं है (वैसे, हम निगरानी के लिए हैं इसे हमने स्वयं लिया). एक दिलचस्प बात यह है कि आप इस ऑपरेटर का उपयोग करके ScyllaDB को भी तैनात कर सकते हैं।

ध्यान दें: हमने अपनी एक परियोजना में मामूली संशोधन के साथ इस ऑपरेटर का उपयोग किया। ऑपरेशन की पूरी अवधि (ऑपरेशन के ~4 महीने) के दौरान ऑपरेटर के काम में कोई समस्या नहीं देखी गई।

5. ऑरेंज से कैसकोप

• GitHub
• तत्परता: अल्फ़ा
• लाइसेंस: अपाचे 2.0
• में कार्यान्वित: गोलांग

सूची में सबसे कम उम्र का ऑपरेटर: पहली प्रतिबद्धता 23 मई, 2019 को की गई थी। पहले से ही इसके शस्त्रागार में हमारी सूची से बड़ी संख्या में विशेषताएं हैं, जिनके बारे में अधिक विवरण परियोजना भंडार में पाया जा सकता है। ऑपरेटर लोकप्रिय ऑपरेटर-एसडीके के आधार पर बनाया गया है। बॉक्स से बाहर निगरानी का समर्थन करता है। अन्य ऑपरेटरों से मुख्य अंतर उपयोग का है कैसकोप प्लगइन, पायथन में कार्यान्वित किया गया और कैसेंड्रा नोड्स के बीच संचार के लिए उपयोग किया गया।

निष्कर्ष

कैसंड्रा को कुबेरनेट्स में पोर्ट करने के लिए दृष्टिकोण और संभावित विकल्पों की संख्या स्वयं ही बोलती है: विषय मांग में है।

इस स्तर पर, आप अपने जोखिम और जोखिम पर उपरोक्त में से कोई भी प्रयास कर सकते हैं: कोई भी डेवलपर उत्पादन वातावरण में अपने समाधान के 100% संचालन की गारंटी नहीं देता है। लेकिन पहले से ही कई उत्पाद विकास बेंचों में उनका उपयोग करने का प्रयास करने के लिए आशाजनक दिख रहे हैं।

मुझे लगता है भविष्य में जहाज़ पर यह महिला काम आएगी!

पुनश्च

हमारे ब्लॉग पर भी पढ़ें:

• «MongoDB का कुबेरनेट्स में निर्बाध प्रवासन";
• «RabbitMQ का कुबेरनेट्स में निर्बाध प्रवासन";
• «डेटाबेस और कुबेरनेट्स (समीक्षा और वीडियो रिपोर्ट)";
• «K8s टिप्स और ट्रिक्स: बड़े डेटाबेस के लिए बूटस्ट्रैप को तेज़ करना'.

स्रोत: www.habr.com