🥇 Sujuv RabbitMQ migreerimine Kubernetesesse

RabbitMQ on Erlangi kirjutatud sõnumibroker, mis võimaldab organiseerida talitlushäireteta klastrit täieliku andmete replikatsiooniga mitmele sõlmele, kus iga sõlm suudab teenindada lugemis- ja kirjutamissoove. Olles tootes mitmeid Kubernetes klastri, toetame suurt hulka RabbitMQ paigaldisi ja seisime silmitsi vajadusega migreerida andmed ühest klastrist teise ilma seiskumiseta.

See operatsioon oli vajalik meile vähemalt kahe juhtumi puhul:

Andmete üleviimine RabbitMQ klastrist, mis ei asu Kuberneteses, uude - juba „kuberneeritud“ (st toimiv K8s pod'ides) - klastrisse.
RabbitMQ migratsioon Kuberneteses ühe nimede ruumist teise (näiteks, kui piirid on jagatud nimede ruumide kaudu, siis infrastruktuuri üleviimiseks ühest piirist teise).

Artiklis pakutud retsept on suunatud olukordadele (aga mitte ainult neile), kus on vana RabbitMQ klaster (näiteks koosneb 3 sõlmest), mis asub kas K8s-is või mõnel vanemal serveril. Selle kallal töötab rakendus, mis on paigutatud Kubernetesesse (kas juba seal või perspektiivis):

… ja meie ees on ülesanne migreerida see uude produktsiooni Kubernetesesse.

Esiteks kirjeldatakse üldist lähenemist migreerimisele, seejärel tehnilisi üksikasju selle rakendamisest.

Migreerimise algoritm

Esimene, eelnev etapp enne igasuguseid tegevusi - kontrollimine, et vanas RabbitMQ paigalduses on aktiveeritud kõrge saadavuse režiim (HA). Põhjus on ilmne - me ei soovi kaotada andmeid. Selle kontrollimiseks saab siseneda RabbitMQ administraatori paneeli ja vahekaardil Admin → Policies veenduda, et väärtus on seatud ha-mode: all:

Järgmine samm - tõstame üles uue RabbitMQ klastris pod'ides Kuberneteses (näiteks koosnedes 3 sõlmest, kuid neid võib olla ka teisi).

Pärast seda ühendame vana ja uue RabbitMQ klastrid, saades ühe klastrisse (6 sõlme):

Algatatakse andmete sünkroonimise protsess vana ja uue RabbitMQ klastrite vahel. Pärast seda, kui kõik andmed sünkroniseeritakse nii, et kõik sõlmed klastris, saame rakenduse suunata kasutama uut klastrit:

Pärast neid toiminguid piisab, kui võtta RabbitMQ klastri vanad sõlmed välja ja kolimine võib lugeda lõpetatuks:

Seda me oleme korduvalt kasutanud meie tootmises. Kuid enda mugavuse huvides rakendasime selle spetsialiseeritud süsteemi raames, mis levitab tüüpilisi RMQ konfiguratsioone paljudele Kubernetes klastritele. (neile, kellel on huvi: räägime addon-operator, millest me hiljuti rääkisime.)Allpool on esitatud eraldi juhised, mida igaüks saab rakendada oma paigaldustes, et proovida pakutavat lahendust praktikas.

Proovime praktikas

Nõuded

Nõuded on väga lihtsad:

Kubernetes klaster (sobib ka minikube);
RabbitMQ klaster (võib olla paigaldatud bare metal'i peale või loodud tavaliseks klastri Kubernetes'is ametlikust Helm-keskkonnast).

Allpool kirjeldatud näite jaoks paigaldasin RMQ Kubernetes'is ja nimetasime selle rmq-old.

Stendi ettevalmistamine

1. Laadime alla Helm-chart'i ja redigeerime seda veidi:

helm fetch --untar stable/rabbitmq-ha

Mugavuse huvides määrame parooli, ErlangCookie ja loome poliitika ha-all, et vaikimisi järjekorrad sünkroniseeritakse kõigi RMQ klastri sõlmede vahel:

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. Paigaldame chart'i:

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

3. Siseneme RabbitMQ haldussüsteemi, loome uue järjekorra ja lisame paar sõnumit. Need on vajalikud, et pärast migratsiooni saaksime veenduda, et kõik andmed on säilinud ja me ei ole midagi kaotanud:

Teststend on valmis: meil on «vana» RabbitMQ andmetega, mis tuleb üle kanda.

RabbitMQ klastrite migratsioon

1. Esiteks paigaldame uue RabbitMQ teises nimetuses sama ja parooliga kasutajale. Selleks teeme ülaltoodud toimingud, muutes RMQ paigaldamise lõppkäsku järgmisele: ErlangCookie helm install . --name rmq-new --namespace rmq-new

2. Nüüd tuleb ühendada uus klaster vanaga. Selleks siseneme igasse pod'i

uue RabbitMQ ja täidame käsud: 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

Mu variables on ühe vana RMQ klastris oleva sõlme aadress. Need käsud peatavad praeguse sõlme RMQ klastri, ühendavad selle vanasse klastrisse ja käivitavad uuesti.

3. RMQ klaster, kus on 6 sõlme, on valmis: RabbitMQ ja täidame käsud: RMQ klaster, liidetakse vanale klasterile ja käivitatakse uuesti.

3. RMQ klaster koosneb 6 sõlmest ja on valmis:

Peate ootama, kuni sõnumid sünkroonitakse kõigi sõlmede vahel. Ei ole raske arvata, et sõnumite sünkroonimise aeg sõltub klastrit käitavast riistvarast ja sõnumite arvust. Kirjeldatud stsenaariumis on neid ainult 10, seega andmed sünkrooniti hetkega, kuid piisavalt suures sõnumite arvus võib sünkroonimine kesta tunde.

Nii et, sünkroonimise staatus:

Siin +5 tähendab, et sõnumid on juba veel 5 sõlmes (lisaks sellele, mis on märgitud väljale Node). Nii et, sünkroonimine läks edukalt läbi.

4. Jääb vaid rakenduses RMQ aadress vahetada uuele klastrile (konkreetsed tegevused sõltuvad teie kasutatavast tehnoloogiapaagist ja muudest rakenduse eripäradest), pärast mida saab vanaga hüvasti jätta.

Viimase toimingu jaoks (st pärast rakenduse mõnel uuele klastrile üleviimine) siseneme iga sõlme Need käsud peatavad praeguse sõlme klastris ja täidame käsud:

rabbitmqctl stop_app
rabbitmqctl reset

Klastril on "unustanud" vanad sõlmed: vana RMQ-deleting ja kolimine on lõpetatud.

Märkus: Kui kasutate RMQ-d sertifikaatidega, siis põhimõtteliselt ei muutu midagi — kolimisprotsess toimub täpselt samamoodi.

Järeldused

Kirjeldatud skeem sobib praktiliselt kõikides olukordades, kui peame RabbitMQ-d üleviima või lihtsalt uuele klastrile kolima.

Meie puhul tekkisid raskused vaid üks kord, kui RMQ-d kasutati paljusid kohti, ja meil ei olnud võimalust igal pool RMQ aadressi uuele vahetada. Siis käivitasime uue RMQ sama nimekirjaga samas nimes, nii et see vastaks juba olemasolevatele teenustele ja Ingress'idele, ja käivitasime pod'i käsitsi märkide manipuleerimisega, eemaldades need alguses, et tühjad RMQ-le ei laekuks päringud, ja lisades need pärast sõnumite sünkroonimist tagasi.

Sarnast strateegiat kasutasime RabbitMQ versiooniuuendamiseks koos muudetud konfiguratsiooniga — kõik töötas nagu kell.

P.S.

Selle teema loogilise jätkuna valmistame ette artikleid MongoDB (migratsioon rauaserverist Kubernetesesse) ja MySQL (kuidas me seda andmebaasi Kuberneteses valmistame). Need avaldatakse lähikuudel.