🥇Seisakuvaba RabbitMQ migratsioon Kuberneteses

RabbitMQ – Erlang keeles kirjutatud sõnumite vahetaja, mis võimaldab luua usaldusväärse klastriga, millel on täielik andmete replikatsioon mitmel sõlmel, kus iga sõlm suudab teenindada lugemis- ja kirjutamissoove. Tootmiskeskkonnas oleme haldanud mitmeid Kubernetes klastri, mis tähendab, et toetame suurt hulka RabbitMQ paigaldusi ning oleme silmitsi seisnud vajadusega migratsioonida andmeid ühest klastrist teise katkestusteta.

See operatsioon oli vajalik meile vähemalt kahes olukorras:

Andmete edastamine RabbitMQ klastrist, mis ei asunud Kuberneteses, uude – nüüd juba "kuberiseeritud" (st K8s pod'ides töötav) – klastrisse.
RabbitMQ migratsioon Kuberneteses ühe nimeduse alt teise (näiteks kui piirid on jaotatud nimede järgi, siis infrastruktuuri edastamiseks ühest piirist teise).

Artiklis pakutud retsept on suunatud olukordadele (aga mitte ainult nendele), kus on olemas vana RabbitMQ klaster (näiteks 3 sõlmega), mis asub kas juba K8s-is või mingitel vanadel serveritel. Sellega töötatakse rakendusega, mis on paigutatud Kubernetesesse (kas juba seal või tulevikus):

… ja meie ees on ülesanne migratsiooni tegemiseks uude production keskkonda Kubernetes'is.

Esmalt kirjeldatakse üldiselt migratsiooni lähenemist, seejärel jagatakse tehnilisi detaile selle rakendamise kohta.

Migratsioonialgoritm

Esimene, etapp enne mis tahes toimingute tegemist — kontrollida, et vana RabbitMQ installatsioonis on sisse lülitatud kõrge kättesaadavuse režiim (HA). Põhjus on ilmne — me ei taha ju andmeid kaotada. Selle kontrollimiseks saab minna RabbitMQ adminpaneelile ja vahekaardil Admin → Policies veenduda, et väärtus on seadistatud ha-mode: all:

Järgmine samm — tõstame üles uue RabbitMQ klastrite Kubernetes'i pod'id (meie puhul näiteks koosnedes 3 sõlmest, kuid nende arv võib olla ka erinev).

Pärast seda ühendame vana ja uue RabbitMQ klastri, saades ühe klastrina (6 sõlmega):

Algatatakse andmete sünkroonimise protsess vana ja uue RabbitMQ klastri vahel. Pärast seda, kui kõik andmed on kõigi sõlmede vahel klastris sünkroonitud, saame rakenduse suunata uue klastri kasutamisele:

Pärast neid toiminguid piisab, kui eemaldada RabbitMQ klastrist vanad sõlmed, ja migratsioon on lõpetatud:

Me oleme seda skeemi korduvalt kasutanud oma tootmises. Küll aga oleme enda mugavuse huvides realiseerinud selle spetsialiseeritud süsteemi raames, mis jagab tüüpilisi RMQ konfiguratsioone paljude Kubernetes klastrite vahel. (neile, keda huvitab: on juttu addon-operator, millest me just hiljuti rääkisime). Allpool on esitatud eraldi juhised, mida igaüks saab oma installatsioonides rakendada, et proovida ettepanekut praktikas.

Proovime praktikas

Nõuded

Andmed on väga lihtsad:

Kubernetes klaster (sobib ka minikube);
RabbitMQ klaster (see võib olla üles seatud nii bare metalil kui ka tavalisena Kubernetesis ametlikust Helm-chart'ist).

Allpool kirjeldatud näite jaoks olen ma seadistanud RMQ Kubernetesis ja kutsunud seda rmq-old.

Stendi ettevalmistamine

1. Lae alla Helm-chart ja tee sellest veidi muudatusi:

helm fetch --untar stable/rabbitmq-ha

Mugavuse mõttes seadistame parooli, ErlangCookie ja teeme poliitika ha-all, et vaikimisi oleksid järjekorrad sünkroonitud kõigi RMQ klastriga seotud 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. Seame diagramm:

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

3. Logi RabbitMQ admin paneeli, loo uus järjekord ja lisa mõned sõnumid. Neid on vaja, et pärast migreerimist saaksime veenduda, et kõik andmed on alles ja me midagi ei kaotanud:

Testkeskkond on valmis: meil on "vana" RabbitMQ andmetega, mis tuleb üle kanda.

RabbitMQ klastrite migreerimine

1. Alustame uue RabbitMQ käivitamisega sõbraga nimede ruumis samade ErlangCookie ja kasutaja parooliga. Selleks teeme ülaltoodud operatsioonid, muutes RMQ installimise lõppkäsku järgmisega:

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

2. Nüüd tuleb ühendada uus klaster vanaga. Selleks logime iga podi uue RabbitMQ sisse ja täidame järgmised käsklused:

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

Muutujas OLD_RMQ on ühe vana RMQ klastrite sõlme aadress. Need käsklused peatavad praeguse

RMQ klastris sõlme, liidavad selle vana klastriga ja käivitavad uuesti. uue 3. RMQ klaster, mis koosneb 6 sõlmest, on valmis:

3. Кластер RMQ из 6 узлов готов:

Peab ootama, kuni sõnumid sünkroniseeritakse kõigi sõlmpunktide vahel. Pole raske arvata, et sõnumite sünkroniseerimise aeg sõltub riistvara võimsusest, millel klaster on rajatud, ja sõnumite arvust. Kirjeldatud stsenaariumi puhul on neid vaid 10, seega andmed sünkroniseerusid kohe, kuid piisavalt suurte sõnumite arvu korral võib sünkroniseerimine kesta tunde.

Nii et sünkroniseerimise staatus:

Siit +5 tähendab, et sõnumid on juba veel 5 sõlmpunktis (välja arvatud see, mis on näidatud väljal Sõlm). Seega on sünkroniseerimine õnnestunud.

4. Jääb vaid rakenduses RMQ aadress uuele klastrile üle lülitada (konkreetsed toimingud sõltuvad siin teie kasutatavast tehnoloogiamaastikust ja rakenduse muudest eripäradest), pärast mida saab vanast lahkuda.

Viimase operatsiooni jaoks (st pärast rakenduse uuele klastrile üleminek) siseneme iga sõlmpunkti RMQ klastrite sõlme aadress. klastris ja täidame käsklused:

rabbitmqctl stop_app
rabbitmqctl reset

Klaster on "unustanud" vanad sõlmed: vana RMQ võib eemaldada, millega kolimine on lõpetatud.

Märkus: Kui kasutate RMQ-d koos sertifikaatidega, ei muutu põhimõtteliselt midagi — migratsiooniprotsess toimub täpselt nii nagu tavaliselt.

Järeldused

Kirjeldatud skeem sobib peaaegu kõikidele juhtumitele, kus peame RabbitMQ-d migreerima või lihtsalt uude klastrisse liikuma.

Meie juhul tekkis probleeme ainult üks kord, kui RMQ-le pöörduti paljusid kohti, kuid meil ei olnud võimalust adresseerida RMQ-d kõikjal. Sel juhul käivitasime uue RMQ sama nimelises ruumis sama etikettidega, et see satuks juba olemasolevate teenuste ja Ingress’ite alla ning pod’i käsitsi käivitamisel manipuleerisime etiketiga, eemaldades need alguses, et tühja RMQ-le ei satuks päringud, ja lisades need tagasi pärast sõnumite sünkroneerimist.

Sama strateegiat rakendasime RabbitMQ uuendamisel uue versiooniga, millel oli muudetud konfiguratsioon — kõik toimis nagu kellavärk.

P.S.

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