RabbitMQ sujuv migreerimine Kubernetesesse

RabbitMQ on Erlangi keeles kirjutatud sõnumimaakler, mis võimaldab teil korraldada tõrkesiirdeklastri täieliku andmete replikatsiooniga mitme sõlme vahel, kus iga sõlm saab teenindada lugemis- ja kirjutamispäringuid. Kuna tootmistegevuses on palju Kubernetese klastreid, toetame suurt hulka RabbitMQ installimisi ja seisime silmitsi vajadusega migreerida andmeid ühest klastrist teise ilma seisakuta.

Vajasime seda toimingut vähemalt kahel juhul:

1. Andmete ülekandmine RabbitMQ klastrist, mis ei asu Kubernetesis, uude – juba "kubernetiseeritud" (st. mis töötab K8s kaustades) - klastrisse.
2. RabbitMQ migratsioon Kubernetesis ühest nimeruumist teise (näiteks kui ahelad on nimeruumidega piiritletud, siis infrastruktuuri ülekandmiseks ühest vooluringist teise).

Artiklis pakutud retsept on keskendunud olukordadele (kuid ei piirdu nendega üldse), kus on olemas vana RabbitMQ klaster (näiteks 3 sõlmest), mis asub kas juba K8s või mõnes vanas serveris. Kuberneteses hostitud rakendus (juba olemas või tulevikus) töötab sellega:

... ja meie ees seisab ülesanne migreerida see Kubernetese uude lavastusse.

Kõigepealt kirjeldatakse üldist lähenemist migratsioonile endale ning seejärel kirjeldatakse selle rakendamise tehnilisi üksikasju.

Migratsiooni algoritm

Esimene, esialgne etapp enne mis tahes toimingut on kontrollida, kas kõrge kättesaadavuse režiim on vanas RabbitMQ installis lubatud (HA). Põhjus on ilmne – me ei taha andmeid kaotada. Selle kontrolli tegemiseks võite minna RabbitMQ administraatoripaneelile ja veenduda vahekaardil Administraator → Reeglid, et väärtus oleks määratud ha-mode: all:

Järgmise sammuna tuleb Kubernetese kaunadesse tõsta uus RabbitMQ klaster (meie puhul näiteks 3 sõlmest koosnev, kuid nende arv võib olla erinev).

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

Käivitatakse andmete sünkroonimise protsess vana ja uue RabbitMQ klastrite vahel. Kui kõik andmed on sünkroonitud klastri kõigi sõlmede vahel, saame lülitada rakenduse uue klastri kasutamiseks:

Pärast neid toiminguid piisab vanade sõlmede eemaldamisest RabbitMQ klastrist ja käigu võib lugeda lõpetatuks:

Oleme seda skeemi tootmises korduvalt kasutanud. Enda mugavuse huvides rakendasime selle aga spetsiaalses süsteemis, mis jaotab standardsed RMQ konfiguratsioonid mitme Kubernetese klastri vahel. ( neile, kes on uudishimulikud: me räägime lisand-operaatormille kohta me just hiljuti öeldi). Allpool esitame individuaalsed juhised, mida igaüks saab oma paigaldistele rakendada, et pakutud lahendust ellu viia.

Proovime seda praktikas

Nõuded

Üksikasjad on väga lihtsad:

1. Kubernetese klaster (töötab ka minikube);
2. RabbitMQ klaster (saab juurutada paljale metallile ja teha nagu tavaline klaster Kuberneteses ametlikult Helmi diagrammil).

Alloleva näite puhul juurutasin RMQ Kubernetesesse ja helistasin sellele rmq-old.

Stendi ettevalmistamine

1. Laadige alla Helmi diagramm ja muutke seda veidi.

helm fetch --untar stable/rabbitmq-ha

Mugavuse huvides määrasime parooli, ErlangCookie ja teha poliitikat ha-allnii et vaikimisi sünkroonitakse järjekorrad RMQ-klastri kõigi 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. Installige diagramm:

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

3. Minge RabbitMQ administraatoripaneelile, looge uus järjekord ja lisage mitu sõnumit. Neid läheb vaja selleks, et pärast migreerimist saaksime veenduda, et kõik andmed on säilinud ja me pole midagi kaotanud:

Katsestend on valmis: meil on “vana” RabbitMQ andmetega, mida tuleb üle kanda.

RabbitMQ klastri migreerimine

1. Esmalt juurutagem uus RabbitMQ sõber nimeruum koos sama ErlangCookie ja kasutaja parool. Selleks teostame ülalkirjeldatud toimingud, muutes RMQ installimise viimase käsu järgmiseks:

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

2. Nüüd peate uue klastri vanaga liitma. Selleks minge iga kauna juurde uus RabbitMQ ja täitke 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

Muutuvas OLD_RMQ leitakse ühe sõlme aadress vana RMQ klaster.

Need käsud peatavad praeguse sõlme uus RMQ-klastri, ühendage see vana klastriga ja käivitage see uuesti.

3. Kuuest sõlmest koosnev RMQ-klaster on valmis:

Peate ootama, kuni sõnumid kõigi sõlmede vahel sünkroonitakse. Pole raske arvata, et sõnumite sünkroonimisaeg sõltub klastri juurutatud riistvara võimsusest ja sõnumite arvust. Kirjeldatud stsenaariumi korral on neid ainult 10, seega sünkrooniti andmed hetkega, kuid piisavalt suure sõnumite arvu korral võib sünkroonimine kesta tunde.

Niisiis, sünkroonimise olek:

see on +5 tähendab, et sõnumid on juba sees rohkem 5 sõlmel (välja arvatud väljal märgitud Node). Seega oli sünkroonimine edukas.

4. Jääb üle vaid rakenduses olev RMQ aadress uude klastrisse lülitada (siinkohal sõltuvad konkreetsed toimingud kasutatavast tehnoloogiapinust ja muust rakenduse spetsiifikast), misjärel saad vanaga hüvasti jätta.

Viimase operatsiooni jaoks (st juba pärast rakenduse ümberlülitamine uude klastrisse) minge igasse sõlme vana klastrisse ja täitke käsud:

rabbitmqctl stop_app
rabbitmqctl reset

Klaster "unustas" vanad sõlmed: saate vana RMQ kustutada, misjärel liigutamine lõpetatakse.

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

Järeldused

Kirjeldatud skeem sobib peaaegu kõikidel juhtudel, kui meil on vaja RabbitMQ-d migreerida või lihtsalt uude klastrisse kolida.

Meie puhul tekkisid raskused vaid ühel korral, kui RMQ-le pääses ligi paljudest kohtadest ja meil ei olnud võimalust igal pool RMQ aadressi uue vastu vahetada. Seejärel käivitasime samas nimeruumis samade siltidega uue RMQ, et see jääks olemasolevate teenuste ja Ingresside alla ning podi käivitamisel manipuleerisime siltidega käsitsi, eemaldades need alguses, et päringud ei langeks tühjendada RMQ ja lisada need pärast sõnumite sünkroonimist tagasi.

Sama strateegiat kasutasime ka RabbitMQ uuendamisel muudetud konfiguratsiooniga uuele versioonile – kõik töötas nagu kell.

PS

Selle materjali loogilise jätkuna valmistame ette artikleid MongoDB-st (migratsioon riistvaraserverist Kubernetesesse) ja MySQL-ist (kuidas me Kubernetese sees seda DBMS-i ette valmistame). Need avaldatakse lähikuudel.

PPS

Loe ka meie blogist:

• «Andmebaasid ja Kubernetes (ülevaade ja videoaruanne)";
• «K8s näpunäited ja nipid: suurte andmebaaside alglaadimise kiirendamine'.

Allikas: www.habr.com