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

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

"कौन नियंत्रित कर सकता है एक महिला राज्य का सामना करेगी"

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

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

अब कुबेरनेट्स के लिए वास्तविक संभावित कदम के लिए।

माइग्रेशन के लिए चेक-लिस्ट

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

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

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


कैसांद्रा लिखें लेन-देन योजना

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


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

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

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

2. निगरानी करना

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


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

केवल दो निर्यातक हैं: jmx_exporter और cassandra_exporter ।

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

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

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

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

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

यह पता चला है कि कुछ अतिरिक्त इकाई एक ही बार में संपूर्ण कैसंड्रा क्लस्टर का प्रबंधन करने के लिए गायब है। लेकिन अगर कुछ नहीं है, तो हम इसे बना सकते हैं! Kubernetes में कस्टम संसाधन परिभाषा नामक एक समर्पित संसाधन परिभाषा इंजन है।


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

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

4. फली की पहचान

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

एक रास्ता है, और एक भी नहीं:

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

5. बैकअप

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

आपको याद दिला दें कि डेटा कांड का वह हिस्सा मेमोरी में स्टोर होता है। एक पूर्ण बैकअप बनाने के लिए, आपको मेमोरी ( मेमटेबल्स ) से डेटा को डिस्क ( 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. स्टेटफुलसेट या हेलम चार्ट सॉल्यूशंस

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

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

प्रतिनिधि:

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

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

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

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


एक अच्छी तरह से डिजाइन Cassandra बयान में नोड प्रबंधन आरेख

मौजूदा ऑपरेटरों पर विचार करें।

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

• GitHub
• इच्छा: अल्फा
• लाइसेंस: अपाचे 2.0
• में लागू: जावा

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

लेकिन ऑपरेटर के पास समर्थन, निगरानी स्तर, सीआरडी का उपयोग करने वाले उच्च स्तरीय क्लस्टर प्रबंधन और बैकअप हटाने पर भी प्रलेखन जैसे लाभ हैं।

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

• GitHub
• इच्छा: अल्फा
• लाइसेंस: अपाचे 2.0
• में लागू: गोलंग

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

3. vgkowski से कैसेंड्रा-ऑपरेटर

• GitHub
• इच्छा: अल्फा
• लाइसेंस: अपाचे 2.0
• में लागू: गोलंग

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

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

• GitHub
• इच्छा: अल्फा
• लाइसेंस: अपाचे 2.0
• में लागू: गोलंग

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

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

5. ऑरेंज द्वारा CassKop

• GitHub
• इच्छा: अल्फा
• लाइसेंस: अपाचे 2.0
• में लागू: गोलंग

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

निष्कर्ष

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

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

मुझे लगता है कि भविष्य में इस महिला को जहाज पर जाना होगा!

पुनश्च

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

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