RabbitMQ هو وسيط للرسائل مكتوب بلغة إيرلانغ ، وهو يسمح لك بتنظيم مجموعة تجاوز فشل مع النسخ المتماثل الكامل للبيانات إلى عدة عقد ، حيث يمكن لكل عقدة معالجة طلبات القراءة والكتابة. مع وجود العديد من مجموعات Kubernetes قيد الإنتاج ، فإننا ندعم عددًا كبيرًا من عمليات تثبيت RabbitMQ وتواجه الحاجة إلى ترحيل البيانات من مجموعة إلى أخرى دون توقف.
كانت هذه العملية ضرورية بالنسبة لنا في حالتين على الأقل:
- نقل البيانات من كتلة RabbitMQ غير الموجودة في Kubernetes إلى كتلة جديدة بالفعل "موالفة" (أي ، تعمل في قرون K8s).
- ترحيل RabbitMQ داخل Kubernetes من مساحة اسم إلى أخرى (على سبيل المثال ، إذا تم تحديد المسارات بمسافات الأسماء ، ثم لنقل البنية التحتية من مسار إلى آخر).
تركز الوصفة المقترحة في هذه المقالة على المواقف (ولكن لا تقتصر عليها على الإطلاق) ، حيث توجد مجموعة RabbitMQ قديمة (على سبيل المثال ، من 3 عقد) ، موجودة في K8s أو على بعض الخوادم القديمة. يعمل تطبيق مستضاف في Kubernetes (موجود بالفعل أو في المستقبل):
... ونحن نواجه التحدي المتمثل في نقله إلى إنتاج جديد في Kubernetes.
أولاً ، سيتم وصف نهج عام للهجرة نفسها ، وبعد ذلك ، التفاصيل الفنية حول تنفيذها.
خوارزمية الترحيل
الخطوة الأولى ، الأولية ، قبل أي إجراء هي التحقق من تمكين وضع التوفر العالي (
HA ) في تثبيت RabbitMQ القديم. السبب واضح - نحن لا نريد أن نفقد أي بيانات. لتنفيذ هذا الاختيار ، يمكنك الانتقال إلى لوحة إدارة RabbitMQ وفي علامة التبويب Admin → Policies تأكد من أن
ha-mode: all :
الخطوة التالية هي رفع مجموعة RabbitMQ جديدة في قرون Kubernetes (في حالتنا ، على سبيل المثال ، تتكون من 3 عقد ، ولكن قد يكون عددها مختلفًا).
بعد ذلك ، نقوم بدمج مجموعات RabbitMQ القديمة والجديدة ، والحصول على كتلة واحدة (من 6 عقد):
بدء عملية مزامنة البيانات بين مجموعات RabbitMQ القديمة والجديدة. بعد مزامنة جميع البيانات بين جميع العقد في المجموعة ، يمكننا تبديل التطبيق لاستخدام الكتلة الجديدة:
بعد هذه العمليات ، يكفي إزالة العقد القديمة من نظام مجموعة RabbitMQ ، ويمكن اعتبار الخطوة مكتملة:
لقد استخدمنا هذا المخطط بشكل متكرر في إنتاجنا. ومع ذلك ، من أجل راحتهم الخاصة ، قمنا بتطبيقه في إطار نظام متخصص يوزع تكوينات RMQ النموذجية على مجموعات من مجموعات Kubernetes
(بالنسبة لأولئك الذين لديهم فضول: نحن نتحدث عن مشغل الوظيفة الإضافية
، والذي تحدثنا عنه مؤخرًا ) . فيما يلي إرشادات فردية يمكن لأي شخص التقدم بها على عمليات التثبيت الخاصة به لتجربة الحل المقترح قيد التنفيذ.
نحاول في الممارسة
متطلبات
التفاصيل بسيطة جدا:
- مجموعة Kubernetes (minikube مناسب أيضًا) ؛
- مجموعة RabbitMQ (يمكن نشرها على المعدن العاري ، وجعلها كتلة منتظمة في Kubernetes من مخطط هيلم الرسمي).
على سبيل المثال الموضح أدناه ، قمت بنشر RMQ على Kubernetes وسميته
rmq-old .
الوقوف الاستعداد
1. قم بتنزيل مخطط Helm وقم بتحريره قليلاً:
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 المتغير
OLD_RMQ عنوان أحد عقد نظام المجموعة RMQ
القديم .
هذه الأوامر سوف توقف العقدة الحالية للكتلة RMQ
الجديدة ، وإرفاقها إلى الكتلة القديمة ، وإعادة تشغيله.
3. مجموعة RMQ من 6 عقد جاهزة:
يجب عليك الانتظار حتى تتم مزامنة الرسائل بين جميع العقد. من السهل تخمين أن وقت تزامن الرسائل يعتمد على سعة المكواة التي يتم نشر الكتلة عليها ، وعلى عدد الرسائل. في السيناريو الموضح ، يوجد 10 منها فقط ، لذلك تمت مزامنة البيانات على الفور ، ولكن مع وجود عدد كبير من الرسائل ، يمكن أن تستغرق المزامنة ساعات.
لذلك ، حالة التزامن:
هنا ، يعني
+5 أن الرسائل موجودة
بالفعل على 5 نقاط
أخرى (باستثناء ما تم تحديده في حقل
Node ). وبالتالي ، كانت المزامنة ناجحة.
4. يبقى فقط تبديل عنوان RMQ في التطبيق إلى المجموعة الجديدة (تعتمد الإجراءات المحددة هنا على رصة التكنولوجيا التي تستخدمها وغيرها من تفاصيل التطبيق) ، وبعد ذلك يمكنك أن تقول وداعًا للوحدة القديمة.
لآخر عملية (على سبيل المثال ،
بعد تبديل التطبيق إلى كتلة جديدة) ، نذهب إلى كل عقدة من الكتلة
القديمة وننفذ الأوامر:
rabbitmqctl stop_app rabbitmqctl reset
الكتلة "نسيت" العقد القديمة: يمكنك حذف RMQ القديمة ، والتي سوف تكمل هذه الخطوة.
ملاحظة : إذا كنت تستخدم RMQ مع شهادات ، فلن يتغير شيء في الأساس - سيتم تنفيذ عملية النقل بنفس الطريقة تمامًا.النتائج
المخطط الموضح مناسب لجميع الحالات تقريبًا عندما نحتاج إلى نقل RabbitMQ أو مجرد الانتقال إلى مجموعة جديدة.
في حالتنا ، حدثت صعوبات مرة واحدة فقط عندما تم الوصول إلى RMQ من العديد من الأماكن ، ولم تتح لنا الفرصة لتغيير عنوان RMQ إلى عنوان جديد في كل مكان. بعد ذلك ، أطلقنا RMQ جديدًا في نفس مساحة الاسم بنفس التسميات ، بحيث يقع تحت الخدمات الحالية و Ingresss ، وعندما بدأنا في pod ، تعاملنا مع التسميات بأيدينا ، وحذفها في البداية ، بحيث لم تقع الطلبات على RMQ فارغة ، و إضافتها مرة أخرى بعد مزامنة الرسائل.
استخدمنا نفس الاستراتيجية عند تحديث RabbitMQ إلى إصدار جديد بتكوين معدّل - كل شيء كان يعمل على مدار الساعة.
PS
كاستمرار منطقي لهذه المادة ، نحن نستعد لمقالات حول MongoDB (الترحيل من خادم حديدي إلى Kubernetes) و MySQL (أحد خيارات "تحضير" قواعد بيانات إدارة قواعد البيانات هذه داخل Kubernetes). وسيتم نشرها في الأشهر المقبلة.
PPS
اقرأ أيضًا في مدونتنا: