RabbitMQ کی Kubernetes میں بغیر کسی رکاوٹ کی منتقلی

RabbitMQ ایرلنگ میں لکھا ہوا ایک میسج بروکر ہے جو آپ کو ایک سے زیادہ نوڈس میں مکمل ڈیٹا ریپلیکشن کے ساتھ فیل اوور کلسٹر کو منظم کرنے کی اجازت دیتا ہے، جہاں ہر نوڈ درخواستوں کو پڑھنے اور لکھنے کی خدمت کر سکتا ہے۔ پروڈکشن آپریشن میں بہت سے Kubernetes کلسٹرز کے ساتھ، ہم RabbitMQ تنصیبات کی ایک بڑی تعداد کو سپورٹ کرتے ہیں اور ہمیں ڈیٹا کو ایک کلسٹر سے دوسرے کلسٹر میں بغیر ٹائم ٹائم کے منتقل کرنے کی ضرورت کا سامنا تھا۔

ہمیں کم از کم دو صورتوں میں اس آپریشن کی ضرورت ہے:

1. RabbitMQ کلسٹر سے ڈیٹا کی منتقلی جو کہ Kubernetes میں موجود نہیں ہے ایک نئے – پہلے سے “kubernetized” (یعنی K8s pods میں کام کر رہا ہے) – کلسٹر۔
2. Kubernetes کے اندر RabbitMQ کی ایک نیم جگہ سے دوسری جگہ منتقلی (مثال کے طور پر، اگر سرکٹس کو نام کی جگہوں سے الگ کیا جاتا ہے، تو انفراسٹرکچر کو ایک سرکٹ سے دوسرے سرکٹ میں منتقل کرنا)۔

مضمون میں تجویز کردہ نسخہ ان حالات پر مرکوز ہے (لیکن ان تک ہی محدود نہیں ہے) جس میں ایک پرانا RabbitMQ کلسٹر ہے (مثال کے طور پر 3 نوڈس کا)، جو پہلے سے K8s میں یا کچھ پرانے سرورز پر موجود ہے۔ Kubernetes پر میزبانی کی گئی ایک ایپلیکیشن (پہلے سے موجود ہے یا مستقبل میں) اس کے ساتھ کام کرتی ہے:

... اور ہمیں اسے کوبرنیٹس میں نئی ​​پروڈکشن میں منتقل کرنے کے کام کا سامنا ہے۔

سب سے پہلے، خود ہجرت کا عمومی طریقہ بیان کیا جائے گا، اور اس کے بعد اس کے نفاذ کی تکنیکی تفصیلات بیان کی جائیں گی۔

منتقلی الگورتھم

کسی بھی کارروائی سے پہلے پہلا، ابتدائی، مرحلہ یہ چیک کرنا ہے کہ پرانی RabbitMQ انسٹالیشن میں اعلی دستیابی موڈ فعال ہے (HA)۔ وجہ واضح ہے - ہم کوئی ڈیٹا کھونا نہیں چاہتے۔ اس چیک کو انجام دینے کے لیے، آپ RabbitMQ ایڈمن پینل پر جا سکتے ہیں اور ایڈمن → پالیسیوں کے ٹیب میں یقینی بنائیں کہ قدر سیٹ ہے۔ ha-mode: all:

اگلا مرحلہ Kubernetes pods میں ایک نیا RabbitMQ کلسٹر بڑھانا ہے (ہمارے معاملے میں، مثال کے طور پر، 3 نوڈس پر مشتمل ہے، لیکن ان کی تعداد مختلف ہو سکتی ہے)۔

اس کے بعد، ہم پرانے اور نئے RabbitMQ کلسٹرز کو ضم کرتے ہیں، ایک ہی کلسٹر (6 نوڈس کا):

پرانے اور نئے RabbitMQ کلسٹرز کے درمیان ڈیٹا سنکرونائزیشن کا عمل شروع کیا گیا ہے۔ ایک بار جب تمام ڈیٹا کلسٹر میں تمام نوڈس کے درمیان مطابقت پذیر ہو جاتا ہے، ہم نئے کلسٹر کو استعمال کرنے کے لیے ایپلیکیشن کو تبدیل کر سکتے ہیں:

ان کارروائیوں کے بعد، RabbitMQ کلسٹر سے پرانے نوڈس کو ہٹانا کافی ہے، اور اس اقدام کو مکمل سمجھا جا سکتا ہے:

ہم نے اس اسکیم کو پیداوار میں کئی بار استعمال کیا ہے۔ تاہم، ہماری اپنی سہولت کے لیے، ہم نے اسے ایک خصوصی نظام کے اندر لاگو کیا جو متعدد Kubernetes کلسٹرز میں معیاری RMQ کنفیگریشنز کو تقسیم کرتا ہے۔ (ان لوگوں کے لئے جو متجسس ہیں: ہم اس کے بارے میں بات کر رہے ہیں۔ ایڈون آپریٹرجس کے بارے میں ہم حال ہی میں بتایا). ذیل میں ہم انفرادی ہدایات پیش کریں گے جو کوئی بھی اپنی تنصیبات پر لاگو کر سکتا ہے تاکہ مجوزہ حل کو عملی جامہ پہنایا جا سکے۔

آئیے اسے عملی طور پر آزماتے ہیں۔

کے تقاضے

تفصیلات بہت آسان ہیں:

1. Kubernetes کلسٹر (minikube بھی کام کرے گا)؛
2. RabbitMQ کلسٹر (ننگی دھات پر تعینات کیا جا سکتا ہے، اور سرکاری ہیلم چارٹ سے 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. اب آپ کو نئے کلسٹر کو پرانے کے ساتھ ضم کرنے کی ضرورت ہے۔ ایسا کرنے کے لیے، pods میں سے ہر ایک پر جائیں نئی 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 (ہم اس DBMS کو Kubernetes کے اندر کیسے تیار کرتے ہیں) کے بارے میں مضامین تیار کر رہے ہیں۔ وہ آنے والے مہینوں میں شائع ہوں گے۔

پی پی ایس

ہمارے بلاگ پر بھی پڑھیں:

• «ڈیٹا بیس اور کوبرنیٹس (جائزہ اور ویڈیو رپورٹ)؛ "
• «K8s تجاویز اور چالیں: بڑے ڈیٹا بیس کے لیے بوٹسٹریپ کو تیز کرنا'.

ماخذ: www.habr.com