🥇Sklandus RabbitMQ perkėlimas į Kubernetes

RabbitMQ yra pranešimų tarpininkas, parašytas Erlang kalba, leidžiantis organizuoti perkėlimo klasterį su visu duomenų replikavimu keliuose mazguose, kur kiekvienas mazgas gali aptarnauti skaitymo ir rašymo užklausas. Turėdami daug „Kubernetes“ grupių, veikiančių gamyboje, palaikome daugybę „RabbitMQ“ įrenginių ir susidūrėme su poreikiu perkelti duomenis iš vienos grupės į kitą be prastovų.

Šios operacijos mums prireikė mažiausiai dviem atvejais:

Duomenų perkėlimas iš RabbitMQ klasterio, esančio ne Kubernetes, į naują – jau „kubernetizuotą“ (t. y. veikiantį K8s blokuose) – klasterį.
RabbitMQ perkėlimas Kubernetes viduje iš vienos vardų srities į kitą (pavyzdžiui, jei grandinės ribojamos vardų erdvėmis, tada perkelti infrastruktūrą iš vienos grandinės į kitą).

Straipsnyje siūlomas receptas yra orientuotas į situacijas (bet jomis neapsiriboja), kai yra senas RabbitMQ klasteris (pavyzdžiui, iš 3 mazgų), esantis jau K8 arba kai kuriuose senuose serveriuose. „Kubernetes“ priglobta programa (jau yra arba ateityje) veikia su ja:

... ir mes susiduriame su užduotimi perkelti jį į naują gamybą Kubernetes.

Pirmiausia bus aprašytas bendras požiūris į pačią migraciją, o po to – techninės jos įgyvendinimo detalės.

Migracijos algoritmas

Pirmas, preliminarus, etapas prieš bet kokį veiksmą yra patikrinti, ar aukšto pasiekiamumo režimas įjungtas sename RabbitMQ diegime (HA). Priežastis akivaizdi – nenorime prarasti jokių duomenų. Norėdami atlikti šį patikrinimą, eikite į RabbitMQ administratoriaus skydelį ir skirtuke Administratorius → Politika įsitikinkite, kad reikšmė nustatyta ha-mode: all:

Kitas žingsnis – iškelti naują RabbitMQ klasterį Kubernetes ankštyse (mūsų atveju, pavyzdžiui, susidedantį iš 3 mazgų, bet jų skaičius gali skirtis).

Po to sujungiame seną ir naują RabbitMQ grupes ir gauname vieną klasterį (iš 6 mazgų):

Pradedamas duomenų sinchronizavimo procesas tarp senojo ir naujojo RabbitMQ klasterių. Kai visi duomenys sinchronizuojami tarp visų klasterio mazgų, galime perjungti programą, kad ji naudotų naują klasterį:

Po šių operacijų pakanka pašalinti senus mazgus iš RabbitMQ klasterio, o perkėlimas gali būti laikomas baigtu:

Šią schemą daug kartų naudojome gamyboje. Tačiau savo patogumui mes jį įdiegėme specializuotoje sistemoje, kuri platina standartines RMQ konfigūracijas keliose Kubernetes klasteriuose. (tiems, kam įdomu: mes kalbame apie priedų operatoriusapie kuriuos mes neseniai papasakojo). Žemiau pateiksime individualias instrukcijas, kurias kiekvienas gali pritaikyti savo įrenginiuose, kad išbandytų siūlomą sprendimą.

Pabandykime tai praktiškai

Reikalavimai

Detalės labai paprastos:

Kubernetes klasteris (tiks ir minikube);
RabbitMQ klasteris (gali būti įdiegtas ant pliko metalo ir pagamintas kaip įprastas klasteris Kubernetes iš oficialios Helm diagramos).

Toliau pateiktame pavyzdyje aš įdiegiau RMQ į Kubernetes ir paskambinau rmq-old.

Stovo paruošimas

1. Atsisiųskite vairo diagramą ir šiek tiek ją redaguokite:

helm fetch --untar stable/rabbitmq-ha

Patogumui nustatome slaptažodį, ErlangCookie ir kurti politiką ha-allkad pagal numatytuosius nustatymus eilės būtų sinchronizuojamos tarp visų RMQ klasterio mazgų:

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. Įdiekite diagramą:

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

3. Eikite į RabbitMQ administratoriaus skydelį, sukurkite naują eilę ir pridėkite keletą pranešimų. Jie bus reikalingi, kad po migracijos galėtume įsitikinti, kad visi duomenys yra išsaugoti ir nieko nepraradome:

Bandymų stendas paruoštas: turime „seną“ RabbitMQ su duomenimis, kuriuos reikia perkelti.

RabbitMQ klasterio perkėlimas

1. Pirmiausia įdiekite naują RabbitMQ drauge vardų erdvė su tas pats ErlangCookie ir vartotojo slaptažodį. Norėdami tai padaryti, atliksime aukščiau aprašytas operacijas, pakeisdami paskutinę RMQ diegimo komandą į šią:

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

2. Dabar reikia sujungti naują klasterį su senuoju. Norėdami tai padaryti, eikite į kiekvieną ankštį naujas RabbitMQ ir vykdykite komandas:

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

Kintamajame OLD_RMQ randamas vieno iš mazgų adresas senas RMQ klasteris.

Šios komandos sustabdys dabartinį mazgą naujas RMQ klasterį, prijunkite jį prie senojo klasterio ir paleiskite dar kartą.

3. RMQ klasteris iš 6 mazgų paruoštas:

Turite palaukti, kol pranešimai bus sinchronizuojami tarp visų mazgų. Nesunku atspėti, kad pranešimų sinchronizavimo laikas priklauso nuo aparatinės įrangos, kurioje yra įdiegtas klasteris, talpos ir nuo pranešimų skaičiaus. Aprašytame scenarijuje jų yra tik 10, todėl duomenys buvo sinchronizuoti akimirksniu, tačiau esant pakankamai dideliam žinučių skaičiui, sinchronizacija gali trukti valandas.

Taigi, sinchronizavimo būsena:

Čia +5 reiškia, kad žinutės jau yra daugiau ant 5 mazgų (išskyrus tai, kas nurodyta lauke Node). Taigi sinchronizavimas buvo sėkmingas.

4. Belieka aplikacijoje perjungti RMQ adresą į naują klasterį (čia konkretūs veiksmai priklauso nuo naudojamo technologijų stacko ir kitos aplikacijos specifikos), po to galima atsisveikinti su senuoju.

Paskutinei operacijai (t. y. jau po programos perjungimas į naują klasterį) eikite į kiekvieną mazgą senas sugrupuoti ir vykdyti komandas:

rabbitmqctl stop_app
rabbitmqctl reset

Klasteris „pamiršo“ apie senus mazgus: galite ištrinti seną RMQ, tada perkėlimas bus baigtas.

Atkreipti dėmesį: Jei naudojate RMQ su sertifikatais, niekas iš esmės nesikeičia - perkėlimo procesas bus atliekamas lygiai taip pat.

išvados

Aprašyta schema tinka beveik visais atvejais, kai reikia migruoti RabbitMQ arba tiesiog pereiti į naują klasterį.

Mūsų atveju keblumų iškilo tik vieną kartą, kai prie RMQ buvo prieita iš daugelio vietų, o RMQ adreso ne visur turėjome pakeisti į naują. Tada mes paleidome naują RMQ toje pačioje vardų erdvėje su tomis pačiomis etiketėmis, kad jis patektų į esamas paslaugas ir „Ingresses“ tuščias RMQ ir vėl juos įtraukus sinchronizavus pranešimus.

Tą pačią strategiją naudojome ir atnaujindami RabbitMQ į naują versiją su pakeista konfigūracija – viskas veikė kaip laikrodis.

PS

Kaip logišką šios medžiagos tęsinį, ruošiame straipsnius apie MongoDB (perkėlimas iš aparatinės įrangos serverio į Kubernetes) ir MySQL (kaip ruošiame šią DBVS Kubernetes viduje). Jie bus paskelbti artimiausiais mėnesiais.

PGS

Taip pat skaitykite mūsų tinklaraštyje:

Šaltinis: www.habr.com

Sklandus RabbitMQ perkėlimas į Kubernetes