RabbitMQ-ning Kubernetes-ga uzluksiz ko'chishi

RabbitMQ - bu Erlang tilida yozilgan xabarlar brokeri bo'lib, u har bir tugun o'qish va yozish so'rovlariga xizmat ko'rsatishi mumkin bo'lgan bir nechta tugunlar bo'ylab to'liq ma'lumotlar replikatsiyasiga ega bo'lmagan klasterni tashkil qilish imkonini beradi. Ishlab chiqarishda ko'plab Kubernetes klasterlariga ega bo'lgan holda, biz ko'p sonli RabbitMQ o'rnatishlarini qo'llab-quvvatlaymiz va ma'lumotlarni bir klasterdan ikkinchisiga uzilishlarsiz o'tkazish zarurati bilan duch keldik.

Bizga bu operatsiya kamida ikkita holatda kerak edi:

1. Kubernetesda joylashgan RabbitMQ klasteridan yangi - allaqachon "kubernetlashtirilgan" (ya'ni K8s podslarida ishlaydigan) klasterga ma'lumotlarni uzatish.
2. RabbitMQ-ning Kubernetes ichida bir nom maydonidan ikkinchisiga ko'chishi (masalan, agar sxemalar nomlar bo'shliqlari bilan ajratilgan bo'lsa, u holda infratuzilmani bir sxemadan ikkinchisiga o'tkazish uchun).

Maqolada taklif qilingan retsept K3-larda yoki ba'zi eski serverlarda joylashgan eski RabbitMQ klasteri (masalan, 8 ta tugun) mavjud bo'lgan holatlarga qaratilgan (lekin ular bilan cheklanmagan). Kubernetes-da joylashtirilgan dastur (allaqachon yoki kelajakda) u bilan ishlaydi:

... va biz uni Kubernetesdagi yangi ishlab chiqarishga ko'chirish vazifasiga duch keldik.

Birinchidan, migratsiyaning o'ziga umumiy yondashuv tavsiflanadi va undan keyin uni amalga oshirishning texnik tafsilotlari tavsiflanadi.

Migratsiya algoritmi

Har qanday harakatdan oldingi birinchi, dastlabki bosqich - bu eski RabbitMQ o'rnatishda yuqori mavjudlik rejimi yoqilganligini tekshirish (HA). Sababi aniq - biz hech qanday ma'lumotni yo'qotmoqchi emasmiz. Ushbu tekshirishni amalga oshirish uchun siz RabbitMQ administrator paneliga o'tishingiz mumkin va Admin → Policies yorlig'ida qiymat o'rnatilganligiga ishonch hosil qiling. ha-mode: all:

Keyingi qadam Kubernetes podslarida yangi RabbitMQ klasterini ko'tarishdir (bizning holatda, masalan, 3 tugundan iborat, lekin ularning soni boshqacha bo'lishi mumkin).

Shundan so'ng, biz eski va yangi RabbitMQ klasterlarini birlashtirib, bitta klasterni (6 ta tugundan) olamiz:

Eski va yangi RabbitMQ klasterlari o'rtasida ma'lumotlarni sinxronlashtirish jarayoni boshlandi. Barcha ma'lumotlar klasterdagi barcha tugunlar o'rtasida sinxronlashtirilgach, biz ilovani yangi klasterdan foydalanishga o'zgartirishimiz mumkin:

Ushbu operatsiyalardan so'ng RabbitMQ klasteridan eski tugunlarni olib tashlash kifoya va harakatni tugallangan deb hisoblash mumkin:

Biz ushbu sxemani ishlab chiqarishda ko'p marta ishlatganmiz. Biroq, biz o'zimizga qulaylik yaratish uchun uni bir nechta Kubernetes klasterlari bo'ylab standart RMQ konfiguratsiyalarini tarqatuvchi maxsus tizim doirasida amalga oshirdik. (qiziqadiganlar uchun: biz gaplashamiz addon-operatorbu haqda biz yaqinda aytdim). Quyida biz taklif qilingan yechimni amalda sinab ko'rish uchun har kim o'z o'rnatishlarida qo'llashi mumkin bo'lgan individual ko'rsatmalarni taqdim etamiz.

Keling, buni amalda sinab ko'raylik

talablar

Tafsilotlar juda oddiy:

1. Kubernetes klasteri (minikube ham ishlaydi);
2. RabbitMQ klasteri (yalang'och metallga joylashtirilishi mumkin va rasmiy Helm diagrammasidan Kubernetesda oddiy klaster kabi tuzilishi mumkin).

Quyidagi misol uchun men RMQ-ni Kubernetes-ga joylashtirdim va uni chaqirdim rmq-old.

Stend tayyorlash

1. Helm diagrammasini yuklab oling va uni biroz tahrirlang:

helm fetch --untar stable/rabbitmq-ha

Qulaylik uchun biz parol o'rnatdik, ErlangCookie va siyosat qiling ha-allShunday qilib, sukut bo'yicha navbatlar RMQ klasterining barcha tugunlari o'rtasida sinxronlashtiriladi:

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. Diagrammani o'rnating:

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

3. RabbitMQ boshqaruv paneliga o'ting, yangi navbat yarating va bir nechta xabarlarni qo'shing. Migratsiyadan so'ng biz barcha ma'lumotlar saqlanganligiga va hech narsani yo'qotmaganligiga ishonch hosil qilishimiz uchun ular kerak bo'ladi:

Sinov dastgohi tayyor: bizda uzatilishi kerak bo'lgan ma'lumotlarga ega "eski" RabbitMQ mavjud.

RabbitMQ klasterini ko'chirish

1. Birinchidan, yangi RabbitMQ ni joylashtiramiz другом bilan nom maydoni bir xil ErlangCookie va foydalanuvchi uchun parol. Buning uchun biz yuqorida tavsiflangan amallarni bajaramiz, RMQ ni o'rnatishning yakuniy buyrug'ini quyidagilarga o'zgartiramiz:

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

2. Endi siz yangi klasterni eskisi bilan birlashtirishingiz kerak. Buning uchun podkastlarning har biriga o'ting yangi RabbitMQ va buyruqlarni bajaring:

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

O'zgaruvchida OLD_RMQ tugunlardan birining manzili topiladi eski RMQ klasteri.

Ushbu buyruqlar joriy tugunni to'xtatadi yangi RMQ klasterini o'rnating, uni eski klasterga biriktiring va qayta ishga tushiring.

3. 6 ta tugunning RMQ klasteri tayyor:

Xabarlar barcha tugunlar o'rtasida sinxronlashtirilguncha kutishingiz kerak. Xabarlarni sinxronlashtirish vaqti klaster o'rnatilgan apparatning sig'imi va xabarlar soniga bog'liqligini taxmin qilish qiyin emas. Ta'riflangan stsenariyda ulardan faqat 10 tasi bor, shuning uchun ma'lumotlar bir zumda sinxronlashtirildi, ammo etarlicha ko'p xabarlar bilan sinxronizatsiya soatlab davom etishi mumkin.

Shunday qilib, sinxronizatsiya holati:

u +5 xabarlar allaqachon kiritilganligini bildiradi ko'proq 5 tugunlarda (maydonda ko'rsatilganlardan tashqari). Node). Shunday qilib, sinxronizatsiya muvaffaqiyatli bo'ldi.

4. Ilovadagi RMQ manzilini yangi klasterga o‘tkazish qoladi (bu yerdagi aniq harakatlar siz foydalanayotgan texnologiya stekiga va boshqa dastur xususiyatlariga bog‘liq), shundan so‘ng siz eskisi bilan xayrlashishingiz mumkin.

Oxirgi operatsiya uchun (ya'ni allaqachon после ilovani yangi klasterga o'tkazish) har bir tugunga o'ting eski klaster qiling va buyruqlarni bajaring:

rabbitmqctl stop_app
rabbitmqctl reset

Klaster eski tugunlar haqida "unutdi": siz eski RMQni o'chirishingiz mumkin, bunda ko'chirish tugallanadi.

nota: Agar siz RMQ-dan sertifikatlar bilan foydalansangiz, unda hech narsa tubdan o'zgarmaydi - ko'chirish jarayoni xuddi shunday amalga oshiriladi.

topilmalar

Ta'riflangan sxema RabbitMQ-ni ko'chirish yoki oddiygina yangi klasterga o'tish kerak bo'lgan deyarli barcha holatlar uchun javob beradi.

Bizning holatda, RMQ ga ko'p joylardan kirishda faqat bir marta qiyinchiliklar paydo bo'ldi va biz hamma joyda RMQ manzilini yangisiga o'zgartirish imkoniga ega bo'lmadik. Keyin biz bir xil yorliqlar bilan bir xil nomlar maydonida yangi RMQ-ni ishga tushirdik, shunda u mavjud xizmatlar va kirishlar ostida qoladi va podni ishga tushirayotganda biz so'rovlar serverga tushmasligi uchun yorliqlarni qo'lda o'zgartirib, boshida olib tashladik. RMQ-ni bo'shating va xabarlar sinxronlangandan keyin ularni qayta qo'shing.

RabbitMQ-ni o'zgartirilgan konfiguratsiyaga ega yangi versiyaga yangilashda biz xuddi shu strategiyadan foydalandik - hamma narsa soat kabi ishladi.

PS

Ushbu materialning mantiqiy davomi sifatida biz MongoDB (apparat serveridan Kubernetesga o'tish) va MySQL (bu DBMSni Kubernetes ichida qanday tayyorlaymiz) haqida maqolalar tayyorlayapmiz. Ular yaqin oylarda nashr etiladi.

PPS

Shuningdek, bizning blogimizda o'qing:

• «Ma'lumotlar bazalari va Kubernetes (ko'rib chiqish va video hisobot)";
• «K8s maslahatlari va fokuslari: Katta ma'lumotlar bazalari uchun yuklashni tezlashtirish".

Manba: www.habr.com