कुबेरनेटमा क्यासान्ड्राको माइग्रेसन: सुविधाहरू र समाधानहरू

हामी नियमित रूपमा Apache Cassandra डाटाबेस र यसलाई Kubernetes-आधारित पूर्वाधार भित्र सञ्चालन गर्ने आवश्यकताको सामना गर्छौं। यस सामग्रीमा, हामी क्यासान्ड्रालाई K8s मा स्थानान्तरण गर्नका लागि आवश्यक कदमहरू, मापदण्डहरू र अवस्थित समाधानहरू (अपरेटरहरूको सिंहावलोकन सहित) को हाम्रो दृष्टिकोण साझा गर्नेछौं।

"जसले महिलालाई शासन गर्न सक्छ उसले राज्य पनि शासन गर्न सक्छ"

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

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

अब - Kubernetes को वास्तविक सम्भावित सार्न को लागी।

स्थानान्तरणको लागि चेक-लिस्ट

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

1. डाटा भण्डारण

पहिले नै स्पष्ट गरिएझैं, क्यासान्डाले डाटाको अंश RAM - in मा भण्डार गर्दछ Memtable। तर त्यहाँ डाटाको अर्को भाग हो जुन डिस्कमा बचत गरिएको छ - फारममा SSTable। यस डेटामा एक निकाय थपिएको छ प्रतिबद्ध लग - सबै लेनदेनहरूको रेकर्ड, जुन डिस्कमा पनि बचत गरिन्छ।

क्यासान्ड्रामा लेनदेन रेखाचित्र लेख्नुहोस्

Kubernetes मा, हामी डेटा भण्डारण गर्न PersistentVolume प्रयोग गर्न सक्छौं। सिद्ध संयन्त्रको लागि धन्यवाद, Kubernetes मा डेटा संग काम हरेक वर्ष सजिलो हुँदैछ।

हामी प्रत्येक क्यासान्ड्रा पोडमा हाम्रो आफ्नै Persistent Volume आवंटित गर्नेछौं

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

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

2. अनुगमन

Kubernetes मा अनुगमन लागू गर्न को लागी लगभग निर्विरोध छनोट प्रोमेथियस हो (हामीले यसको बारेमा विस्तृत रूपमा कुरा गर्यौं सम्बन्धित रिपोर्ट)। क्यासान्ड्रा प्रोमेथियसका लागि मेट्रिक्स निर्यातकहरूसँग कसरी भइरहेको छ? र, Grafana का लागि मिल्दो ड्यासबोर्डहरूसँग अझ महत्त्वपूर्ण के छ?

Cassandra को लागि Grafana मा ग्राफ को उपस्थिति को एक उदाहरण

त्यहाँ केवल दुई निर्यातकहरू छन्: jmx_exporter и cassandra_exporter.

हामीले आफ्नो लागि पहिलो रोज्यौं किनभने:

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

3. Kubernetes primitives चयन गर्दै

क्यासान्ड्रा क्लस्टरको माथिको संरचना अनुसार, कुबेरनेट शब्दावलीमा वर्णन गरिएको सबै कुरा अनुवाद गर्ने प्रयास गरौं:

• क्यासान्ड्रा नोड → पोड
• क्यासान्ड्रा र्याक → स्टेटफुलसेट
• क्यासान्ड्रा डाटासेन्टर → StatefulSets बाट पूल
• क्यासान्ड्रा क्लस्टर → ???

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

लग र अलर्टहरूको लागि थप स्रोतहरू घोषणा गर्दै

तर अनुकूलन संसाधन आफैंमा केहि मतलब छैन: सबै पछि, यो आवश्यक छ नियन्त्रक। तपाईंले मद्दत खोज्नु पर्ने हुन सक्छ Kubernetes अपरेटर...

4. पोड को पहिचान

माथिको अनुच्छेदमा, हामीले सहमति गर्यौं कि एउटा क्यासान्ड्रा नोडले कुबर्नेट्समा एउटा पोड बराबर हुनेछ। तर पोडहरूको IP ठेगानाहरू प्रत्येक पटक फरक हुनेछन्। र Cassandra मा एक नोड को पहिचान IP ठेगाना मा आधारित छ... यो बाहिर जान्छ कि प्रत्येक पोड हटाउन पछि, Cassandra क्लस्टरले नयाँ नोड थप्नेछ।

त्यहाँ एक बाटो छ, र केवल एक छैन:

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

5. ब्याकअपहरू

हामी तालिकामा एकल क्यासान्ड्रा नोडको डेटाको पूर्ण संस्करण बचत गर्न चाहन्छौं। Kubernetes प्रयोग गरेर एक सुविधाजनक सुविधा प्रदान गर्दछ क्रोनजबतर यहाँ क्यासान्ड्रा आफैले हाम्रो पाङ्ग्रामा स्पोक राख्छिन्।

मलाई तपाईलाई सम्झाउन दिनुहोस् कि क्यासान्ड्राले मेमोरीमा केहि डाटा भण्डार गर्दछ। पूर्ण ब्याकअप बनाउनको लागि, तपाईंलाई मेमोरीबाट डाटा चाहिन्छ (मेमटेबलहरू) डिस्कमा सार्नुहोस् (SSTables)। यस बिन्दुमा, क्यासान्ड्रा नोडले जडानहरू स्वीकार गर्न रोक्छ, क्लस्टरबाट पूर्ण रूपमा बन्द हुन्छ।

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

केसान्ड्रा नोडहरू जिम्मेवार छन् भनेर पहिचान गर्न टोकनहरूको वितरण

Kubernetes मा 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}"

एउटा क्यासान्ड्रा नोडबाट ब्याकअप लिनको लागि ब्यास स्क्रिप्टको उदाहरण

Kubernetes मा Cassandra लागि तयार समाधान

कुबर्नेट्समा क्यासान्ड्रा डिप्लोय गर्नको लागि हाल के प्रयोग गरिन्छ र यी मध्ये कुनचाहिँ दिइएको आवश्यकताहरू उपयुक्त हुन्छ?

1. StatefulSet वा हेल्म चार्टहरूमा आधारित समाधानहरू

क्यासान्ड्रा क्लस्टर चलाउन आधारभूत स्टेटफुलसेट प्रकार्यहरू प्रयोग गर्नु राम्रो विकल्प हो। हेल्म चार्ट र गो टेम्प्लेटहरू प्रयोग गरेर, तपाइँ प्रयोगकर्तालाई क्यासान्ड्रा डिप्लोय गर्नको लागि लचिलो इन्टरफेस प्रदान गर्न सक्नुहुन्छ।

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

प्रतिनिधिहरू:

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

दुबै चार्टहरू समान रूपमा राम्रो छन्, तर माथि वर्णन गरिएका समस्याहरूको अधीनमा छन्।

2. Kubernetes अपरेटर मा आधारित समाधान

त्यस्ता विकल्पहरू थप चाखलाग्दो छन् किनभने तिनीहरूले क्लस्टर व्यवस्थापनको लागि पर्याप्त अवसरहरू प्रदान गर्छन्। Cassandra अपरेटर डिजाइन गर्न को लागी, कुनै अन्य डाटाबेस जस्तै, एक राम्रो ढाँचा Sidecar <-> नियन्त्रक <-> CRD जस्तो देखिन्छ:

राम्रोसँग डिजाइन गरिएको क्यासान्ड्रा अपरेटरमा नोड व्यवस्थापन योजना

अवस्थित अपरेटरहरू हेरौं।

1. instaclust बाट क्यासान्ड्रा-अपरेटर

• GitHub
• तयारी: अल्फा
• इजाजतपत्र: Apache 2.0
• लागू: Java

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

तर अपरेटरसँग अनुगमनका लागि समर्थन, CRD प्रयोग गरी उच्च-स्तरको क्लस्टर व्यवस्थापन, र ब्याकअपहरू बनाउनका लागि कागजातहरू जस्ता फाइदाहरू छन्।

2. Jetstack बाट नेभिगेटर

• GitHub
• तयारी: अल्फा
• इजाजतपत्र: Apache 2.0
• मा लागू: Golang

DB-as-a-Service लाई डिप्लोय गर्न डिजाइन गरिएको कथन। हाल दुई डाटाबेस समर्थन गर्दछ: Elasticsearch र Cassandra। यसमा RBAC मार्फत डाटाबेस पहुँच नियन्त्रण जस्ता रोचक समाधानहरू छन् (यसका लागि यसको आफ्नै छुट्टै नेभिगेटर-एपिसर्भर छ)। एक चाखलाग्दो परियोजना जुन नजिकबाट हेर्न लायक हुनेछ, तर अन्तिम प्रतिबद्धता डेढ वर्ष अघि गरिएको थियो, जसले स्पष्ट रूपमा यसको सम्भावना कम गर्दछ।

3. क्यासान्ड्रा-अपरेटर vgkowski द्वारा

• GitHub
• तयारी: अल्फा
• इजाजतपत्र: Apache 2.0
• मा लागू: Golang

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

4. रुक द्वारा क्यासान्ड्रा-अपरेटर

• GitHub
• तयारी: अल्फा
• इजाजतपत्र: Apache 2.0
• मा लागू: Golang

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

NB: हामीले यो अपरेटरलाई हाम्रो एउटा परियोजनामा ​​सानो परिमार्जनको साथ प्रयोग गर्यौं। सञ्चालनको सम्पूर्ण अवधि (~ 4 महिना सञ्चालन) मा अपरेटरको काममा कुनै समस्याहरू देखिएनन्।

5. सुन्तलाबाट CassKop

• GitHub
• तयारी: अल्फा
• इजाजतपत्र: Apache 2.0
• मा लागू: Golang

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

निष्कर्ष

क्यासान्ड्रालाई कुबेरनेटमा पोर्ट गर्नका लागि दृष्टिकोण र सम्भावित विकल्पहरूको संख्या आफैले बोल्छ: विषय मागमा छ।

यस चरणमा, तपाइँ तपाइँको आफ्नै जोखिम र जोखिममा माथिको कुनै पनि प्रयास गर्न सक्नुहुन्छ: विकासकर्ताहरू मध्ये कुनै पनि उत्पादन वातावरणमा उनीहरूको समाधानको 100% सञ्चालनको ग्यारेन्टी गर्दैन। तर पहिले नै, धेरै उत्पादनहरू विकास बेन्चहरूमा प्रयोग गर्ने प्रयास गर्न आशावादी देखिन्छन्।

मलाई लाग्छ भविष्यमा जहाजमा यो महिला काममा आउनेछ!

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «MongoDB को Kubernetes मा सिमलेस माइग्रेसन»;
• «RabbitMQ को Kubernetes मा सिमलेस माइग्रेसन»;
• «डाटाबेस र Kubernetes (समीक्षा र भिडियो रिपोर्ट)»;
• «K8s सुझावहरू र चालहरू: ठूला डाटाबेसहरूको लागि बुटस्ट्र्यापको गति बढाउँदै"।

स्रोत: www.habr.com