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

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

हामीलाई कम्तिमा दुई केसहरूमा यो अपरेशन चाहिन्छ:

1. RabbitMQ क्लस्टरबाट डाटा स्थानान्तरण गर्दै जुन Kubernetes मा अवस्थित छैन नयाँ - पहिले नै "kubernetized" (अर्थात K8s pods मा सञ्चालन) - क्लस्टर।
2. RabbitMQ को Kubernetes भित्र एक नेमस्पेसबाट अर्कोमा माइग्रेसन (उदाहरणका लागि, यदि सर्किटहरू नेमस्पेसद्वारा छुट्याइएको छ भने, एक सर्किटबाट अर्कोमा पूर्वाधार स्थानान्तरण गर्न)।

लेखमा प्रस्तावित नुस्खा परिस्थितिहरूमा केन्द्रित छ (तर तिनीहरूमा सीमित छैन) जसमा त्यहाँ पुरानो RabbitMQ क्लस्टर (उदाहरणका लागि, 3 नोडहरू) छ, पहिले नै K8s मा वा केही पुरानो सर्भरहरूमा अवस्थित छ। Kubernetes मा होस्ट गरिएको एउटा अनुप्रयोग (पहिले नै त्यहाँ वा भविष्यमा) यसको साथ काम गर्दछ:

... र हामी यसलाई Kubernetes मा नयाँ उत्पादनमा स्थानान्तरण गर्ने कार्यको सामना गरिरहेका छौं।

पहिले, माइग्रेसनको सामान्य दृष्टिकोण वर्णन गरिनेछ, र त्यस पछि यसको कार्यान्वयनको प्राविधिक विवरणहरू वर्णन गरिनेछ।

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

कुनै पनि कार्य गर्नु अघि पहिलो, प्रारम्भिक, चरण भनेको पुरानो RabbitMQ स्थापनामा उच्च उपलब्धता मोड सक्षम गरिएको छ भनी जाँच गर्नु हो।HA)। कारण स्पष्ट छ - हामी कुनै पनि डाटा गुमाउन चाहँदैनौं। यो जाँच गर्न, तपाईं RabbitMQ प्रशासक प्यानलमा जान सक्नुहुन्छ र Admin → नीतिहरू ट्याबमा मान सेट गरिएको छ भनी सुनिश्चित गर्नुहोस्। ha-mode: all:

अर्को चरण Kubernetes पोडहरूमा नयाँ RabbitMQ क्लस्टर उठाउनु हो (हाम्रो अवस्थामा, उदाहरणका लागि, 3 नोडहरू समावेश छन्, तर तिनीहरूको संख्या फरक हुन सक्छ)।

यस पछि, हामी पुरानो र नयाँ RabbitMQ क्लस्टरहरू मर्ज गर्छौं, एकल क्लस्टर (6 नोडहरूको) प्राप्त गर्दै:

पुरानो र नयाँ RabbitMQ क्लस्टरहरू बीच डाटा सिङ्क्रोनाइजेसनको प्रक्रिया प्रारम्भ गरिएको छ। एकपटक सबै डेटा क्लस्टरमा सबै नोडहरू बीच सिङ्क्रोनाइज भएपछि, हामी नयाँ क्लस्टर प्रयोग गर्न अनुप्रयोगलाई स्विच गर्न सक्छौं:

यी अपरेसनहरू पछि, यो RabbitMQ क्लस्टरबाट पुरानो नोडहरू हटाउन पर्याप्त छ, र चाल पूरा मान्न सकिन्छ:

हामीले उत्पादनमा धेरै पटक यो योजना प्रयोग गरेका छौं। यद्यपि, हाम्रो आफ्नै सुविधाको लागि, हामीले यसलाई एक विशेष प्रणाली भित्र लागू गर्यौं जसले मानक RMQ कन्फिगरेसनहरू धेरै Kubernetes क्लस्टरहरूमा वितरण गर्दछ। (जिज्ञासुहरूका लागि: हामी कुरा गर्दैछौं addon-operatorजसको बारेमा हामी भर्खरै बताए)। तल हामी व्यक्तिगत निर्देशनहरू प्रस्तुत गर्नेछौं जुन कसैले पनि तिनीहरूको स्थापनाहरूमा लागू गर्न सक्छन् प्रस्तावित समाधान कार्यमा प्रयास गर्न।

यसलाई व्यवहारमा प्रयास गरौं

आवश्यकताहरू

विवरणहरू धेरै सरल छन्:

1. Kubernetes क्लस्टर (minikube पनि काम गर्नेछ);
2. RabbitMQ क्लस्टर (बेयर मेटलमा प्रयोग गर्न सकिन्छ, र आधिकारिक हेलम चार्टबाट Kubernetes मा नियमित क्लस्टर जस्तै बनाइन्छ)।

तलको उदाहरणको लागि, मैले Kubernetes मा RMQ तैनात गरे र यसलाई बोलाएँ 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 क्लस्टर।

यी आदेशहरूले हालको नोडलाई रोक्नेछ नयाँ RMQ क्लस्टर, यसलाई पुरानो क्लस्टरमा संलग्न गर्नुहोस् र यसलाई फेरि सुरु गर्नुहोस्।

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

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

त्यसैले, सिंक्रोनाइजेसन स्थिति:

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

4. बाँकी रहेको RMQ ठेगानालाई नयाँ क्लस्टरमा एप्लिकेसनमा स्विच गर्नु हो (यहाँ विशिष्ट कार्यहरू तपाईंले प्रयोग गरिरहनु भएको टेक्नोलोजी स्ट्याक र अन्य एप्लिकेसन स्पेसिफिकेशनहरूमा निर्भर गर्दछ), त्यसपछि तपाईंले पुरानोलाई अलविदा भन्न सक्नुहुन्छ।

अन्तिम अपरेशनको लागि (अर्थात् पहिले नै после अनुप्रयोगलाई नयाँ क्लस्टरमा स्विच गर्दै) प्रत्येक नोडमा जानुहोस् पुरानो क्लस्टर गर्नुहोस् र आदेशहरू कार्यान्वयन गर्नुहोस्:

rabbitmqctl stop_app
rabbitmqctl reset

पुरानो नोडहरूको बारेमा क्लस्टर "बिर्सियो": तपाइँ पुरानो RMQ मेटाउन सक्नुहुन्छ, जुन बिन्दुमा चाल पूरा हुनेछ।

भन्नु: यदि तपाइँ प्रमाणपत्रहरूको साथ RMQ प्रयोग गर्नुहुन्छ भने, त्यसपछि केहि पनि मौलिक रूपमा परिवर्तन हुँदैन - चल्ने प्रक्रिया ठ्याक्कै उस्तै हुनेछ।

निष्कर्ष

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

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

परिवर्तन गरिएको कन्फिगरेसनको साथ नयाँ संस्करणमा RabbitMQ अद्यावधिक गर्दा हामीले उही रणनीति प्रयोग गर्‍यौं - सबै कुरा घडीको रूपमा काम गर्‍यो।

PS

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

पीपीएस

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

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

स्रोत: www.habr.com