RabbitMQ चे Kubernetes मध्ये अखंड स्थलांतर

RabbitMQ हा Erlang मध्ये लिहिलेला संदेश ब्रोकर आहे जो तुम्हाला एकाधिक नोड्सवर संपूर्ण डेटा प्रतिकृतीसह एक फेलओव्हर क्लस्टर आयोजित करण्यास अनुमती देतो, जेथे प्रत्येक नोड विनंत्या वाचू आणि लिहू शकतो. उत्पादन ऑपरेशनमध्ये अनेक कुबर्नेट्स क्लस्टर्स असल्यामुळे, आम्ही मोठ्या संख्येने RabbitMQ इंस्टॉलेशनला समर्थन देतो आणि डाउनटाइमशिवाय डेटा एका क्लस्टरमधून दुसर्‍या क्लस्टरमध्ये स्थलांतरित करण्याची गरज होती.

आम्हाला किमान दोन प्रकरणांमध्ये या ऑपरेशनची आवश्यकता आहे:

1. Kubernetes मध्ये नसलेल्या RabbitMQ क्लस्टरमधील डेटा नवीन – आधीच “kubernetized” (म्हणजे K8s पॉड्समध्ये कार्यरत) – क्लस्टरमध्ये हस्तांतरित करणे.
2. कुबर्नेट्समधील रॅबिटएमक्यूचे एका नेमस्पेसमधून दुस-या नेमस्पेसमध्ये स्थलांतरण (उदाहरणार्थ, जर नेमस्पेसद्वारे सर्किट्सचे सीमांकन केले असेल, तर पायाभूत सुविधा एका सर्किटमधून दुसऱ्या सर्किटमध्ये हस्तांतरित करण्यासाठी).

लेखात प्रस्तावित केलेली रेसिपी परिस्थितींवर केंद्रित आहे (परंतु त्यांच्यापुरतेच मर्यादित नाही) ज्यामध्ये एक जुना RabbitMQ क्लस्टर आहे (उदाहरणार्थ, 3 नोड्सचा), एकतर आधीपासून K8 मध्ये किंवा काही जुन्या सर्व्हरवर आहे. Kubernetes वर होस्ट केलेला अनुप्रयोग (आधीपासूनच आहे किंवा भविष्यात) त्याच्यासह कार्य करतो:

... आणि कुबेरनेट्समधील नवीन उत्पादनामध्ये ते स्थलांतरित करण्याचे कार्य आमच्याकडे आहे.

प्रथम, स्थलांतराचा सामान्य दृष्टिकोन स्वतःच वर्णन केला जाईल आणि त्यानंतर त्याच्या अंमलबजावणीचे तांत्रिक तपशील वर्णन केले जातील.

स्थलांतर अल्गोरिदम

कोणत्याही कृतीपूर्वीचा पहिला, प्राथमिक, टप्पा म्हणजे जुन्या RabbitMQ इंस्टॉलेशनमध्ये उच्च उपलब्धता मोड सक्षम आहे हे तपासणे (HA). कारण स्पष्ट आहे - आम्ही कोणताही डेटा गमावू इच्छित नाही. ही तपासणी करण्यासाठी, तुम्ही RabbitMQ अॅडमिन पॅनलवर जाऊ शकता आणि अॅडमिन → पॉलिसीज टॅबमध्ये मूल्य सेट केले असल्याची खात्री करा. ha-mode: all:

पुढची पायरी म्हणजे कुबर्नेट्स पॉड्समध्ये नवीन रॅबिटएमक्यू क्लस्टर वाढवणे (आमच्या बाबतीत, उदाहरणार्थ, 3 नोड्स आहेत, परंतु त्यांची संख्या भिन्न असू शकते).

यानंतर, आम्ही जुने आणि नवीन RabbitMQ क्लस्टर्स एकत्र करतो, एकच क्लस्टर (6 नोड्सचा):

जुन्या आणि नवीन RabbitMQ क्लस्टर्समधील डेटा सिंक्रोनाइझेशनची प्रक्रिया सुरू केली आहे. क्लस्टरमधील सर्व नोड्समध्ये सर्व डेटा सिंक्रोनाइझ झाल्यानंतर, आम्ही नवीन क्लस्टर वापरण्यासाठी ऍप्लिकेशन स्विच करू शकतो:

या ऑपरेशन्सनंतर, रॅबिटएमक्यू क्लस्टरमधून जुने नोड्स काढणे पुरेसे आहे आणि हलविणे पूर्ण मानले जाऊ शकते:

आम्ही ही योजना उत्पादनामध्ये अनेक वेळा वापरली आहे. तथापि, आमच्या स्वतःच्या सोयीसाठी, आम्ही ते एका विशेष प्रणालीमध्ये लागू केले आहे जे एकाधिक कुबर्नेट्स क्लस्टर्समध्ये मानक RMQ कॉन्फिगरेशन वितरीत करते. (जे जिज्ञासू आहेत त्यांच्यासाठी: आम्ही बोलत आहोत अॅडऑन-ऑपरेटरज्याबद्दल आम्ही नुकतेच सांगितले). खाली आम्ही वैयक्तिक सूचना सादर करू ज्या कोणीही त्यांच्या स्थापनेवर लागू करू शकेल आणि कृतीत प्रस्तावित उपाय वापरून पहा.

चला सरावाने प्रयत्न करूया

आवश्यकता

तपशील खूप सोपे आहेत:

1. कुबर्नेट्स क्लस्टर (मिनीक्यूब देखील कार्य करेल);
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 हटवू शकता, ज्या वेळी हलवा पूर्ण होईल.

शेरा: जर तुम्ही प्रमाणपत्रांसह आरएमक्यू वापरत असाल, तर मूलभूतपणे काहीही बदलत नाही - हलवण्याची प्रक्रिया अगदी सारखीच केली जाईल.

निष्कर्ष

वर्णन केलेली योजना जवळजवळ सर्व प्रकरणांसाठी योग्य आहे जेव्हा आम्हाला RabbitMQ स्थलांतरित करण्याची किंवा फक्त नवीन क्लस्टरमध्ये जाण्याची आवश्यकता असते.

आमच्या बाबतीत, अडचणी फक्त एकदाच उद्भवल्या, जेव्हा अनेक ठिकाणांहून RMQ ऍक्सेस केले गेले आणि आम्हाला सर्वत्र RMQ पत्ता बदलून नवीन करण्याची संधी मिळाली नाही. मग आम्ही त्याच नेमस्पेसमध्ये समान लेबलांसह एक नवीन RMQ लाँच केला जेणेकरुन ते विद्यमान सेवा आणि प्रवेशाच्या अंतर्गत येईल आणि पॉड लाँच करताना आम्ही लेबले हाताने हाताळली, सुरुवातीला ती काढून टाकली जेणेकरून विनंत्या येणार नाहीत. रिक्त RMQ, आणि संदेश सिंक्रोनाइझ झाल्यानंतर ते परत जोडणे.

बदललेल्या कॉन्फिगरेशनसह नवीन आवृत्तीमध्ये RabbitMQ अद्यतनित करताना आम्ही समान धोरण वापरले - सर्वकाही घड्याळासारखे कार्य करते.

PS

या सामग्रीचे तार्किक सातत्य म्हणून, आम्ही मोंगोडीबी (हार्डवेअर सर्व्हरवरून कुबर्नेट्समध्ये स्थलांतर) आणि मायएसक्यूएल (आम्ही हे डीबीएमएस कुबर्नेट्समध्ये कसे तयार करतो) बद्दल लेख तयार करत आहोत. येत्या काही महिन्यांत ते प्रकाशित केले जातील.

पीपीएस

आमच्या ब्लॉगवर देखील वाचा:

• «डेटाबेस आणि कुबर्नेट्स (पुनरावलोकन आणि व्हिडिओ अहवाल)";
• «K8s टिपा आणि युक्त्या: मोठ्या डेटाबेससाठी बूटस्ट्रॅपचा वेग वाढवणे».

स्त्रोत: www.habr.com