Kubernetes के लिए अविभाजित MongoDB प्रवासन

यह लेख हमारे हाल ही के RabbitMQ माइग्रेशन सामग्री को जारी रखता है और MongoDB को समर्पित है। चूँकि हम कई कुबेरनेट और मोंगोबीडी समूहों की सेवा करते हैं, इसलिए हम एक इंस्टालेशन से दूसरे में डेटा माइग्रेट करने और बिना डाउनटाइम के ऐसा करने की स्वाभाविक आवश्यकता के लिए आए हैं। मुख्य परिदृश्य समान हैं: एक आभासी / लोहे के सर्वर से MongoDB का स्थानांतरण Kubernetes में या एक Kubernetes क्लस्टर के भीतर MongoDB का स्थानांतरण (एक नामस्थान से दूसरे में)।

हमारा नुस्खा उन मामलों के लिए अभिप्रेत है जब पुराना MongoDB क्लस्टर कार्य कर रहा है (उदाहरण के लिए, 3 नोड्स और K8s या पुराने सर्वर पर पहले से ही स्थित है) जिसके साथ Kubernetes में होस्ट किया गया एप्लिकेशन काम करता है:



कुबेरनेट्स में हम इस तरह के क्लस्टर को नए उत्पादन में कैसे स्थानांतरित करेंगे?

सिद्धांत

सामान्य माइग्रेशन एल्गोरिथ्म RabbitMQ के साथ स्थिति में वर्णित समान है।

यह ध्यान रखना महत्वपूर्ण है कि स्थानांतरित करने की क्षमता को एक ही नेटवर्क पर होने के लिए MongoDB और Kubernetes के साथ सर्वर की आवश्यकता होती है। MongoDB क्लस्टर के नोड्स पुराने सर्वरों के IP (जहां पुराने MongoDB इंस्टॉलेशन स्थित हैं) पर एक दूसरे के साथ संवाद करेंगे और K8s में MongoDB से पॉड्स के DNS नाम। इसलिए, लोहे के सर्वर पर (पुरानी स्थापनाओं के साथ), पॉड्स के लिए आगे के मार्गों के लिए आवश्यक होगा, और फिर उन्हें कुबेरनेट्स में चल रहे DNS सर्वर का उपयोग करने के लिए कॉन्फ़िगर करें (या आवश्यक नाम /etc/hosts में पंजीकृत करें, हालांकि सामान्य स्थिति में इस संभावना से बचने के लिए बेहतर है। )।

अगला कदम कुबेरनेट्स पॉड्स में MongoDB क्लस्टर बढ़ाने के लिए है। हमारे मामले में, डेटाबेस क्लस्टर में 3 नोड होते हैं और प्रत्येक नोड K8s के एक अलग पॉड में स्थित होता है - हालांकि, उनकी संख्या अलग हो सकती है। विन्यास मानचित्र में आपको पुरानी स्थापना से MongoDB मास्टर का पता निर्दिष्ट करने की आवश्यकता है: फिर K8s में फली में स्थित MongoDB नोड तुरंत इसके साथ सिंक्रनाइज़ करना शुरू कर देगा।

सभी पॉड्स ऊपर जाने के बाद, एक 6-नोड MongoDB क्लस्टर बनता है:



कृपया ध्यान दें कि फली लंबे समय तक बढ़ेगी, क्योंकि प्रत्येक पॉड बारी में शुरू होता है, और लॉन्च के समय यह मास्टर से डेटा को सिंक्रनाइज़ करता है।

उसके बाद, आप नए MongoDB सर्वर का उपयोग करने के लिए एप्लिकेशन को स्विच कर सकते हैं:



और यह केवल MongoDB क्लस्टर से पुराने नोड्स को हटाने के लिए बनी हुई है, जिसके बाद इस कदम को पूरा माना जा सकता है:



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

हम अभ्यास में प्रयास करते हैं

आवश्यकताओं

विवरण:

• कुबेरनेट्स क्लस्टर (मिनिक्यूब भी उपयुक्त है);
• MongoDB क्लस्टर (नंगे धातु पर तैनात किया जा सकता है, और आधिकारिक हेलम चार्ट से कुबेरनेट्स में एक नियमित क्लस्टर के रूप में बनाया गया है)।

नीचे वर्णित उदाहरण में, MongoDB वाले पुराने क्लस्टर को mongo mongo-old कहा जाएगा और उसी Kubernetes क्लस्टर में स्थापित किया जाएगा, जहां भविष्य में हम नए ( mongo-new ) स्थापित करेंगे।

पुराने क्लस्टर को तैयार करना

1. एक उदाहरण के लिए जो वर्णित योजना को कार्रवाई में प्रदर्शित करता है, हम कुबेरनेट्स में सीधे एक "पुराना" (यानी, प्रवास के अधीन) MongoDB क्लस्टर बनाएंगे (वास्तव में, यह K8 के बाहर अलग सर्वर पर भी स्थित हो सकता है)। ऐसा करने के लिए, हेल्म चार्ट डाउनलोड करें:

 helm fetch --untar stable/mongodb-replicaset 

... और प्राधिकरण स्थापित करके इसे थोड़ा संपादित करें:

 auth: enabled: true adminUser: mongo adminPassword: pa33w0rd # metricsUser: metrics # metricsPassword: password # key: keycontent # existingKeySecret: # existingAdminSecret: # exisitingMetricsSecret: 

इसके अलावा values.yaml आप प्रमाण पत्र और बहुत कुछ कॉन्फ़िगर कर सकते हैं।

2. चार्ट सेट करें:

 helm install . --name mongo-old --namespace mongo-old 

उसके बाद, MongoDB की "पुरानी" स्थापना का परीक्षण शुरू किया जाएगा:

 kubectl --namespace=mongo-old get pods 

आइए अपने गुरु के साथ फली जाएं और एक परीक्षण आधार बनाएँ:

 kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo use admin db.auth('mongo','password') use music db.artists.insert({ artistname: "The Tea Party" }) show dbs 

अलग-अलग पॉड्स में जाने पर, मुझे पता चला कि मास्टर mongo-old-mongodb-replicaset-0 । हालाँकि, इस समस्या के अधिक सुविधाजनक समाधान के लिए, हेल्म-चार्ट स्थापित करने के बाद, एक कमांड को प्रदर्शित किया जाता है कि कैसे MASTER_POD का निर्धारण किया MASTER_POD । मेरे मामले में (3 नोड्स के mongo-old के लिए) यह इस तरह दिखता है:

 for ((i = 0; i < 3; ++i)); do kubectl exec --namespace mongo-old mongo-old-mongodb-replicaset-$i -- sh -c 'mongo --eval="printjson(rs.isMaster())"'; done 

इस पर, पुराने MongoDB स्थापना की तैयारी, जिसमें से डेटा स्थानांतरित किया जाएगा, तैयार है।

MongoDB क्लस्टर प्रवासन

अब हम नए MongoDB इंस्टॉलेशन की तैनाती करेंगे, जो Kubernetes में स्थित होगा और उत्पादन में एप्लिकेशन द्वारा उपयोग किया जाएगा।

NB : कृपया ध्यान दें कि MongoDB के समान संस्करण का उपयोग पहले की तरह किया जाना चाहिए। अन्यथा, संगतता समस्याओं का खतरा है।

पिछले खंड (जहां हमने "पुराने" MongoDB इंस्टॉलेशन की नकल की थी) के अनुरूप, हम पहले से ही उल्लेखित हेल्म-चार्ट ( helm fetch कमांड का उपयोग करके) लेते हैं और प्राधिकरण, साथ ही साथ अन्य मापदंडों को कॉन्फ़िगर करते हैं, यदि उपयोग किया जाता है। इसके अलावा, हम अस्थायी रूप से लाइन पर इसे जोड़कर init/on-start.sh फ़ाइल को ठीक कर देंगे। पिछले चरण में प्राप्त विज़ार्ड का पता (या अलग-अलग सर्वर पर MongoDB इंस्टॉलेशन से आपको ज्ञात):

 peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017' 

हम एक नया MongoDB इंस्टॉलेशन बनाने के लिए तैयार हैं:

 helm install . --name mongo-new --namespace mongo-new 

हम तब तक प्रतीक्षा करते हैं जब तक कि सभी पॉड्स शुरू न हो जाएं (यदि बहुत अधिक डेटा है, तो उनके लॉन्च में घंटों लग सकते हैं):



अब हम एक नई फली में exec करते हैं और आधारों की सूची देखते हैं:

 kubectl --namespace=mongo-new exec -ti mongo-new-mongodb-replicaset-0 mongo 

दो MongoDB समूहों को एक में जोड़ा जाता है, जिसमें 6 नोड होते हैं।

फिलहाल, आप एप्लिकेशन को पहले से ही एक नए क्लस्टर में बदल सकते हैं, लेकिन माइग्रेशन को पूरा करने के लिए कुछ चरण शेष हैं।

नई स्थापना में init/on-start.sh से, हम अपने द्वारा जोड़ी गई लाइन को हटा देते हैं:

 peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017' 

अब चलो क्लस्टर के पुराने मास्टर में जाते हैं और इसे "उखाड़ फेंकते हैं" - फिर क्लस्टर में एक नया मास्टर सौंपा जाएगा। हम MongoDB मास्टर के साथ पॉड में जाते हैं:

 kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo use admin db.auth('mongo','password') 

उसके बाद, हम नोड्स की प्राथमिकताओं को बदलते हैं और विज़ार्ड को बदलते हैं:

 cfg = rs.conf() cfg.members[5].priority = 2 rs.reconfig(cfg) rs.stepDown(120) 

वर्तमान नोड एक मास्टर होने के लिए बंद हो गया है - एक नया चुनाव होगा। जैसे-जैसे हमने प्राथमिकताएँ बदलीं, हमें जिस नोड की ज़रूरत है वह मास्टर बन जाएगा।

NB : डिफ़ॉल्ट रूप से, सभी MongoDB नोड्स की प्राथमिकता 1 है। ऊपर हम उस नोड की प्राथमिकता को बढ़ाते हैं जो हमें चाहिए। इस प्रकार, एक नए क्लस्टर का सदस्य निश्चित रूप से एक सामान्य मास्टर बन जाएगा। आप इस बारे में अधिक पढ़ सकते हैं कि ये तंत्र प्रलेखन में MongoDB में कैसे काम करते हैं।

पुराने MongoDB इंस्टॉलेशन को अक्षम करें, फिर नए विज़ार्ड में जाएं और पुराने नोड्स को हटा दें:

 rs.remove("mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017") rs.remove("mongo-old-mongodb-replicaset-1.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017") rs.remove("mongo-old-mongodb-replicaset-2.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017") 

इसके बाद, माइग्रेशन को पूरा माना जा सकता है: हमने पुराने MongoDB क्लस्टर से नए में सफलतापूर्वक स्विच किया!

परिणाम

वर्णित योजना लगभग सभी मामलों के लिए उपयुक्त है जब आपको MongoDB को स्थानांतरित करने या बस एक नए क्लस्टर में स्थानांतरित करने की आवश्यकता होती है।

शायद स्थानांतरण के दौरान मुख्य बारीकियों को नए पॉड्स के आईपी पतों को पुराने MongoDB इंस्टॉलेशन के सर्वरों को अग्रेषित करने की आवश्यकता है, अगर यह K8s के बाहर है, और सही ढंग से उन्हें DNS (या /etc/hosts ) में नाम दें। उदाहरण में, इन चरणों की आवश्यकता नहीं थी, क्योंकि प्रवासन एक ही कुबेरनेट क्लस्टर के विभिन्न नामस्थानों के बीच हुआ था।

पुनश्च

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

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