RabbitMQ का कुबेरनेट्स में निर्बाध प्रवासन

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

हमें कम से कम दो मामलों में इस ऑपरेशन की आवश्यकता थी:

1. एक RabbitMQ क्लस्टर से डेटा स्थानांतरित करना जो Kubernetes में स्थित नहीं है, एक नए - पहले से ही "kubernetized" (यानी K8s पॉड्स में काम कर रहा है) - क्लस्टर में।
2. Kubernetes के भीतर RabbitMQ का एक नामस्थान से दूसरे नामस्थान में स्थानांतरण (उदाहरण के लिए, यदि सर्किट को नामस्थान द्वारा सीमांकित किया जाता है, तो बुनियादी ढांचे को एक सर्किट से दूसरे सर्किट में स्थानांतरित करने के लिए)।

लेख में प्रस्तावित नुस्खा उन स्थितियों पर केंद्रित है (लेकिन उन तक बिल्कुल भी सीमित नहीं है) जिसमें एक पुराना RabbitMQ क्लस्टर है (उदाहरण के लिए, 3 नोड्स का), या तो पहले से ही K8 में या कुछ पुराने सर्वर पर स्थित है। कुबेरनेट्स पर होस्ट किया गया एक एप्लिकेशन (पहले से ही या भविष्य में) इसके साथ काम करता है:

... और हमें इसे कुबेरनेट्स में नए उत्पादन में स्थानांतरित करने के कार्य का सामना करना पड़ रहा है।

सबसे पहले, प्रवासन के सामान्य दृष्टिकोण का वर्णन किया जाएगा, और उसके बाद इसके कार्यान्वयन के तकनीकी विवरण का वर्णन किया जाएगा।

माइग्रेशन एल्गोरिदम

किसी भी कार्रवाई से पहले पहला, प्रारंभिक चरण यह जांचना है कि पुराने RabbitMQ इंस्टॉलेशन में उच्च उपलब्धता मोड सक्षम है (HA). कारण स्पष्ट है - हम कोई भी डेटा खोना नहीं चाहते। इस जाँच को करने के लिए, आप RabbitMQ एडमिन पैनल पर जा सकते हैं और एडमिन → नीतियाँ टैब में सुनिश्चित कर सकते हैं कि मान सेट है ha-mode: all:

अगला कदम कुबेरनेट्स पॉड्स में एक नया RabbitMQ क्लस्टर तैयार करना है (हमारे मामले में, उदाहरण के लिए, 3 नोड्स से मिलकर, लेकिन उनकी संख्या भिन्न हो सकती है)।

इसके बाद, हम पुराने और नए RabbitMQ क्लस्टर को मर्ज करते हैं, जिससे एक क्लस्टर (6 नोड्स का) प्राप्त होता है:

पुराने और नए RabbitMQ क्लस्टर के बीच डेटा सिंक्रनाइज़ेशन की प्रक्रिया शुरू की गई है। एक बार जब सभी डेटा क्लस्टर में सभी नोड्स के बीच सिंक्रनाइज़ हो जाता है, तो हम नए क्लस्टर का उपयोग करने के लिए एप्लिकेशन को स्विच कर सकते हैं:

इन ऑपरेशनों के बाद, यह RabbitMQ क्लस्टर से पुराने नोड्स को हटाने के लिए पर्याप्त है, और इस कदम को पूरा माना जा सकता है:

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

आइए इसे व्यवहार में आज़माएँ

आवश्यकताएँ

विवरण बहुत सरल हैं:

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

नीचे दिए गए उदाहरण के लिए, मैंने कुबेरनेट्स पर आरएमक्यू तैनात किया और इसे कॉल किया rmq-old.

स्टैंड की तैयारी

1. हेल्म चार्ट डाउनलोड करें और इसे थोड़ा संपादित करें:

helm fetch --untar stable/rabbitmq-ha

सुविधा के लिए, हम एक पासवर्ड सेट करते हैं, ErlangCookie और राजनीति करो ha-allताकि डिफ़ॉल्ट रूप से कतारें RMQ क्लस्टर के सभी नोड्स के बीच सिंक्रनाइज़ हो जाएं:

rabbitmqPassword: guest
rabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we
definitions:
policies: |-
  {
    "name": "ha-all",
    "pattern": ".*",
    "vhost": "/",
    "definition": {
      "ha-mode": "all",
      "ha-sync-mode": "automatic",
      "ha-sync-batch-size": 81920
    }
  }

2. चार्ट स्थापित करें:

helm install . --name rmq-old --namespace rmq-old

3. RabbitMQ एडमिन पैनल पर जाएं, एक नई कतार बनाएं और कई संदेश जोड़ें। इनकी आवश्यकता होगी ताकि माइग्रेशन के बाद हम यह सुनिश्चित कर सकें कि सारा डेटा संरक्षित है और हमने कुछ भी नहीं खोया है:

परीक्षण बेंच तैयार है: हमारे पास डेटा के साथ "पुराना" RabbitMQ है जिसे स्थानांतरित करने की आवश्यकता है।

RabbitMQ क्लस्टर को माइग्रेट करना

1. सबसे पहले, आइए नए RabbitMQ को तैनात करें एक दोस्त नेमस्पेस के साथ वही ErlangCookie और उपयोगकर्ता के लिए पासवर्ड. ऐसा करने के लिए, हम ऊपर वर्णित ऑपरेशन करेंगे, RMQ स्थापित करने के लिए अंतिम कमांड को निम्नलिखित में बदल देंगे:

helm install . --name rmq-new --namespace rmq-new

2. अब आपको नए क्लस्टर को पुराने क्लस्टर के साथ मर्ज करना होगा। ऐसा करने के लिए, प्रत्येक पॉड पर जाएँ नई RabbitMQ और कमांड निष्पादित करें:

export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && 
  rabbitmqctl stop_app && 
  rabbitmqctl join_cluster $OLD_RMQ && 
  rabbitmqctl start_app

परिवर्तनशील में OLD_RMQ नोड्स में से एक का पता मिल गया है पुराना आरएमक्यू क्लस्टर।

ये आदेश वर्तमान नोड को रोक देंगे नई RMQ क्लस्टर, इसे पुराने क्लस्टर से जोड़ें और इसे फिर से लॉन्च करें।

3. 6 नोड्स का RMQ क्लस्टर तैयार है:

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

तो, सिंक्रनाइज़ेशन स्थिति:

यहां +5 इसका मतलब है कि संदेश पहले से ही मौजूद हैं अधिक 5 नोड्स पर (फ़ील्ड में जो दर्शाया गया है उसे छोड़कर)। Node). इस प्रकार, सिंक्रनाइज़ेशन सफल रहा.

4. केवल एप्लिकेशन में RMQ पते को नए क्लस्टर में स्विच करना बाकी है (यहां विशिष्ट क्रियाएं आपके द्वारा उपयोग किए जा रहे प्रौद्योगिकी स्टैक और अन्य एप्लिकेशन विशिष्टताओं पर निर्भर करती हैं), जिसके बाद आप पुराने को अलविदा कह सकते हैं।

अंतिम ऑपरेशन के लिए (अर्थात पहले से ही के बाद एप्लिकेशन को नए क्लस्टर में स्विच करना) प्रत्येक नोड पर जाएं पुराना क्लस्टर बनाएं और कमांड निष्पादित करें:

rabbitmqctl stop_app
rabbitmqctl reset

क्लस्टर पुराने नोड्स के बारे में "भूल गया": आप पुराने RMQ को हटा सकते हैं, जिस बिंदु पर चाल पूरी हो जाएगी।

नोट: यदि आप प्रमाणपत्रों के साथ आरएमक्यू का उपयोग करते हैं, तो मौलिक रूप से कुछ भी नहीं बदलता है - चलती प्रक्रिया बिल्कुल उसी तरह से की जाएगी।

निष्कर्ष

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

हमारे मामले में, कठिनाइयाँ केवल एक बार उत्पन्न हुईं, जब RMQ को कई स्थानों से एक्सेस किया गया था, और हमें हर जगह RMQ पते को एक नए में बदलने का अवसर नहीं मिला। फिर हमने उसी नेमस्पेस में समान लेबल के साथ एक नया आरएमक्यू लॉन्च किया ताकि यह मौजूदा सेवाओं और इंग्रेसेस के अंतर्गत आ जाए, और पॉड लॉन्च करते समय हमने लेबल को हाथ से हेरफेर किया, उन्हें शुरुआत में हटा दिया ताकि अनुरोधों पर असर न पड़े। खाली RMQ, और संदेशों के सिंक्रनाइज़ होने के बाद उन्हें वापस जोड़ना।

परिवर्तित कॉन्फ़िगरेशन के साथ RabbitMQ को नए संस्करण में अपडेट करते समय हमने उसी रणनीति का उपयोग किया - सब कुछ एक घड़ी की तरह काम करता था।

पुनश्च

इस सामग्री की तार्किक निरंतरता के रूप में, हम MongoDB (हार्डवेयर सर्वर से Kubernetes में माइग्रेशन) और MySQL (हम Kubernetes के अंदर इस DBMS को कैसे तैयार करते हैं) के बारे में लेख तैयार कर रहे हैं। इन्हें आने वाले महीनों में प्रकाशित किया जाएगा।

पीपीएस

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

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

स्रोत: www.habr.com