Walang putol na paglipat ng RabbitMQ sa Kubernetes

Ang RabbitMQ ay isang message broker na nakasulat sa Erlang na nagbibigay-daan sa iyong mag-organisa ng failover cluster na may ganap na pagtitiklop ng data sa maraming node, kung saan ang bawat node ay maaaring magserbisyo ng mga kahilingan sa pagbasa at pagsulat. Sa pagkakaroon ng maraming cluster ng Kubernetes sa pagpapatakbo ng produksyon, sinusuportahan namin ang malaking bilang ng mga pag-install ng RabbitMQ at nahaharap kami sa pangangailangang maglipat ng data mula sa isang cluster patungo sa isa pa nang walang downtime.

Kailangan namin ang operasyong ito sa hindi bababa sa dalawang kaso:

1. Paglilipat ng data mula sa isang RabbitMQ cluster na hindi matatagpuan sa Kubernetes patungo sa isang bago – “naka-kubernetize” na (ibig sabihin, tumatakbo sa mga K8s pod) – cluster.
2. Ang paglilipat ng RabbitMQ sa loob ng Kubernetes mula sa isang namespace patungo sa isa pa (halimbawa, kung ang mga circuit ay itinatakda ng mga namespace, pagkatapos ay ilipat ang imprastraktura mula sa isang circuit patungo sa isa pa).

Ang recipe na iminungkahi sa artikulo ay nakatuon sa mga sitwasyon (ngunit hindi limitado sa kanila) kung saan mayroong isang lumang RabbitMQ cluster (halimbawa, ng 3 node), na matatagpuan alinman sa K8s o sa ilang mga lumang server. Ang isang application na naka-host sa Kubernetes (naroon na o sa hinaharap) ay gumagana kasama nito:

... at nahaharap tayo sa gawaing ilipat ito sa bagong produksyon sa Kubernetes.

Una, ang pangkalahatang diskarte sa migration mismo ay ilalarawan, at pagkatapos nito ay ilalarawan ang mga teknikal na detalye ng pagpapatupad nito.

Algoritmo ng paglilipat

Ang una, paunang, yugto bago ang anumang aksyon ay upang suriin na ang high availability mode ay pinagana sa lumang RabbitMQ installation (HA). Ang dahilan ay malinaw - hindi namin nais na mawalan ng anumang data. Upang maisagawa ang pagsusuring ito, maaari kang pumunta sa RabbitMQ admin panel at sa tab na Admin → Mga Patakaran tiyaking nakatakda ang halaga ha-mode: all:

Ang susunod na hakbang ay magtaas ng bagong RabbitMQ cluster sa mga Kubernetes pod (sa aming kaso, halimbawa, na binubuo ng 3 node, ngunit maaaring iba ang kanilang bilang).

Pagkatapos nito, pinagsasama namin ang luma at bagong mga kumpol ng RabbitMQ, na nakakakuha ng isang kumpol (ng 6 na node):

Ang proseso ng pag-synchronize ng data sa pagitan ng luma at bagong RabbitMQ cluster ay sinisimulan. Kapag na-synchronize na ang lahat ng data sa pagitan ng lahat ng node sa cluster, maaari nating ilipat ang application para magamit ang bagong cluster:

Pagkatapos ng mga operasyong ito, sapat na upang alisin ang mga lumang node mula sa RabbitMQ cluster, at ang paglipat ay maaaring ituring na kumpleto:

Maraming beses na naming ginamit ang scheme na ito sa produksyon. Gayunpaman, para sa aming sariling kaginhawahan, ipinatupad namin ito sa loob ng isang espesyal na sistema na namamahagi ng mga karaniwang RMQ na configuration sa maraming Kubernetes cluster. (para sa mga curious: pinag-uusapan natin addon-operatortungkol sa kung saan kami kamakailan lang sinabi). Sa ibaba ay magpapakita kami ng mga indibidwal na tagubilin na maaaring ilapat ng sinuman sa kanilang mga pag-install upang subukan ang iminungkahing solusyon sa pagkilos.

Subukan natin ito sa pagsasanay

Kinakailangan sa

Ang mga detalye ay napaka-simple:

1. Kubernetes cluster (gagagana rin ang minikube);
2. RabbitMQ cluster (maaaring i-deploy sa bare metal, at gawin tulad ng isang regular na cluster sa Kubernetes mula sa opisyal na Helm chart).

Para sa halimbawa sa ibaba, nag-deploy ako ng RMQ sa Kubernetes at tinawag ito rmq-old.

Paghahanda ng tumayo

1. I-download ang Helm chart at i-edit ito ng kaunti:

helm fetch --untar stable/rabbitmq-ha

Para sa kaginhawahan, nagtakda kami ng isang password, ErlangCookie at gumawa ng pulitika ha-allupang bilang default, ang mga pila ay naka-synchronize sa pagitan ng lahat ng mga node ng RMQ cluster:

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. I-install ang tsart:

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

3. Pumunta sa RabbitMQ admin panel, gumawa ng bagong pila at magdagdag ng ilang mensahe. Kakailanganin ang mga ito upang pagkatapos ng paglipat ay matiyak namin na ang lahat ng data ay napanatili at wala kaming nawala:

Handa na ang test bench: mayroon kaming "lumang" RabbitMQ na may data na kailangang ilipat.

Paglipat ng RabbitMQ cluster

1. Una, i-deploy natin ang bagong RabbitMQ другом namespace na may pareho ErlangCookie at password para sa gumagamit. Upang gawin ito, isasagawa namin ang mga operasyong inilarawan sa itaas, binabago ang panghuling utos para sa pag-install ng RMQ sa sumusunod:

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

2. Ngayon ay kailangan mong pagsamahin ang bagong cluster sa luma. Upang gawin ito, pumunta sa bawat isa sa mga pod bago RabbitMQ at isagawa ang mga utos:

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

Sa variable OLD_RMQ matatagpuan ang address ng isa sa mga node matanda na RMQ cluster.

Ihihinto ng mga utos na ito ang kasalukuyang node bago RMQ cluster, ikabit ito sa lumang cluster at ilunsad muli.

3. Handa na ang RMQ cluster ng 6 na node:

Dapat kang maghintay habang ang mga mensahe ay naka-synchronize sa pagitan ng lahat ng mga node. Hindi mahirap hulaan na ang oras ng pag-synchronize ng mensahe ay depende sa kapasidad ng hardware kung saan naka-deploy ang cluster at sa bilang ng mga mensahe. Sa inilarawan na senaryo, mayroon lamang 10 sa kanila, kaya ang data ay na-synchronize kaagad, ngunit sa isang sapat na malaking bilang ng mga mensahe, ang pag-synchronize ay maaaring tumagal ng ilang oras.

Kaya, ang katayuan ng pag-synchronize:

Dito +5 nangangahulugan na ang mga mensahe ay nakapasok na higit pa sa 5 node (maliban sa ipinahiwatig sa field Node). Kaya, matagumpay ang pag-synchronize.

4. Ang natitira na lang ay ilipat ang RMQ address sa application sa bagong cluster (ang mga partikular na aksyon dito ay depende sa teknolohiya stack na iyong ginagamit at iba pang mga partikular na application), pagkatapos nito ay maaari kang magpaalam sa luma.

Para sa huling operasyon (i.e. na pagkatapos paglipat ng application sa isang bagong cluster) pumunta sa bawat node matanda na cluster at isagawa ang mga utos:

rabbitmqctl stop_app
rabbitmqctl reset

"Nakalimutan" ng cluster ang tungkol sa mga lumang node: maaari mong tanggalin ang lumang RMQ, kung saan makukumpleto ang paglipat.

Nota: Kung gumagamit ka ng RMQ na may mga sertipiko, kung gayon walang nagbabago sa panimula - ang proseso ng paglipat ay isasagawa nang eksakto pareho.

Natuklasan

Ang inilarawang scheme ay angkop para sa halos lahat ng mga kaso kung kailan kailangan nating mag-migrate ng RabbitMQ o lumipat lamang sa isang bagong cluster.

Sa aming kaso, isang beses lang lumitaw ang mga paghihirap, nang ma-access ang RMQ mula sa maraming lugar, at hindi kami nagkaroon ng pagkakataon na baguhin ang RMQ address sa isang bago sa lahat ng dako. Pagkatapos ay naglunsad kami ng bagong RMQ sa parehong namespace na may parehong mga label upang ito ay mahulog sa ilalim ng mga umiiral na serbisyo at Ingresses, at kapag inilunsad ang pod ay minanipula namin ang mga label sa pamamagitan ng kamay, inalis ang mga ito sa simula upang ang mga kahilingan ay hindi mahulog sa walang laman na RMQ, at idagdag muli ang mga ito pagkatapos na mai-synchronize ang mga mensahe.

Ginamit namin ang parehong diskarte noong ina-update ang RabbitMQ sa isang bagong bersyon na may binagong configuration - lahat ay gumana tulad ng isang orasan.

PS

Bilang lohikal na pagpapatuloy ng materyal na ito, naghahanda kami ng mga artikulo tungkol sa MongoDB (paglipat mula sa isang server ng hardware patungo sa Kubernetes) at MySQL (kung paano namin inihahanda ang DBMS na ito sa loob ng Kubernetes). Ang mga ito ay ilalathala sa mga darating na buwan.

Pps

Basahin din sa aming blog:

• «Mga Database at Kubernetes (review at video report)";
• «Mga tip at trick ng K8s: Pabilisin ang bootstrap para sa malalaking database'.

Pinagmulan: www.habr.com