Brezhibna selitev RabbitMQ na Kubernetes

RabbitMQ je posrednik sporočil, napisan v Erlangu, ki vam omogoča organiziranje samodejne gruče s popolno replikacijo podatkov v več vozliščih, kjer lahko vsako vozlišče servisira zahteve za branje in pisanje. Ker imamo veliko gruč Kubernetes v produkcijskem delovanju, podpiramo veliko število namestitev RabbitMQ in bili smo soočeni s potrebo po selitvi podatkov iz ene gruče v drugo brez izpadov.

To operacijo smo potrebovali v vsaj dveh primerih:

1. Prenos podatkov iz gruče RabbitMQ, ki se ne nahaja v Kubernetesu, v novo – že »kubernetizirano« (tj. deluje v podih K8s) – gručo.
2. Selitev RabbitMQ znotraj Kubernetesa iz enega imenskega prostora v drugega (na primer, če so vezja razmejena z imenskimi prostori, potem za prenos infrastrukture iz enega vezja v drugega).

Recept, predlagan v članku, je osredotočen na situacije (vendar sploh ni omejen nanje), v katerih obstaja stara gruča RabbitMQ (na primer iz 3 vozlišč), ki se nahaja že v K8 ali na nekaterih starih strežnikih. Aplikacija, ki gostuje na Kubernetesu (že tam ali v prihodnosti), deluje z njim:

... in soočeni smo z nalogo, da ga preselimo v novo produkcijo v Kubernetesu.

Najprej bo opisan splošni pristop k sami migraciji, nato pa bodo opisane tehnične podrobnosti njene izvedbe.

Selitveni algoritem

Prva, predhodna faza pred kakršnim koli dejanjem je preveriti, ali je način visoke razpoložljivosti omogočen v stari namestitvi RabbitMQ (HA). Razlog je očiten - ne želimo izgubiti nobenih podatkov. Če želite izvesti to preverjanje, lahko obiščete skrbniško ploščo RabbitMQ in v zavihku Admin → Policies preverite, ali je vrednost nastavljena ha-mode: all:

Naslednji korak je vzpostavitev nove gruče RabbitMQ v podih Kubernetes (v našem primeru na primer sestavljena iz 3 vozlišč, vendar je njihovo število lahko drugačno).

Po tem združimo staro in novo gručo RabbitMQ, tako da dobimo eno samo gručo (6 vozlišč):

Sprožen je proces sinhronizacije podatkov med starimi in novimi gručami RabbitMQ. Ko so vsi podatki sinhronizirani med vsemi vozlišči v gruči, lahko preklopimo aplikacijo na uporabo nove gruče:

Po teh operacijah je dovolj, da odstranite stara vozlišča iz gruče RabbitMQ in premik se lahko šteje za dokončan:

To shemo smo že večkrat uporabili v proizvodnji. Vendar smo ga zaradi lastnega udobja implementirali v specializiran sistem, ki distribuira standardne konfiguracije RMQ v več gruč Kubernetes (za tiste, ki ste radovedni: govorimo o addon-operatoro katerih smo prav pred kratkim povedal). V nadaljevanju bomo predstavili posamezna navodila, ki jih lahko vsakdo uporabi na svojih napravah in poskusi predlagano rešitev v praksi.

Poskusimo v praksi

Zahteve

Podrobnosti so zelo preproste:

1. Grozd Kubernetes (deloval bo tudi minikube);
2. Gruča RabbitMQ (mogoče jo je namestiti na golo kovino in narediti kot običajno gručo v Kubernetesu iz uradne karte Helm).

Za spodnji primer sem uvedel RMQ v Kubernetes in ga poklical rmq-old.

Priprava stojala

1. Prenesite grafikon Helm in ga malo uredite:

helm fetch --untar stable/rabbitmq-ha

Za udobje smo nastavili geslo, ErlangCookie in delati politiko ha-alltako da so čakalne vrste privzeto sinhronizirane med vsemi vozlišči gruče RMQ:

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. Namestite grafikon:

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

3. Pojdite na skrbniško ploščo RabbitMQ, ustvarite novo čakalno vrsto in dodajte več sporočil. Potrebovali jih bomo, da se po selitvi lahko prepričamo, da so vsi podatki ohranjeni in da nismo ničesar izgubili:

Testna miza je pripravljena: imamo "stari" RabbitMQ s podatki, ki jih je treba prenesti.

Selitev gruče RabbitMQ

1. Najprej namestimo novi RabbitMQ prijatelj imenski prostor z enako ErlangCookie in geslo za uporabnika. Da bi to naredili, bomo izvedli zgoraj opisane operacije in spremenili končni ukaz za namestitev RMQ na naslednje:

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

2. Zdaj morate združiti novo gručo s staro. Če želite to narediti, pojdite na vsako od podov novo RabbitMQ in izvedite ukaze:

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

V spremenljivki OLD_RMQ najde se naslov enega od vozlišč star gruča RMQ.

Ti ukazi bodo zaustavili trenutno vozlišče novo RMQ gruče, jo priključite na staro gručo in jo znova zaženite.

3. Grozd RMQ s 6 vozlišči je pripravljen:

Počakati morate, da se sporočila sinhronizirajo med vsemi vozlišči. Ni težko uganiti, da je čas sinhronizacije sporočil odvisen od zmogljivosti strojne opreme, na kateri je gruča nameščena, in od števila sporočil. V opisanem scenariju jih je le 10, zato so bili podatki sinhronizirani v trenutku, pri dovolj velikem številu sporočil pa lahko sinhronizacija traja več ur.

Torej, stanje sinhronizacije:

Tukaj +5 pomeni, da so sporočila že notri več na 5 vozliščih (razen tistega, kar je navedeno v polju Node). Tako je bila sinhronizacija uspešna.

4. Vse, kar ostane, je, da naslov RMQ v aplikaciji preklopite na novo gručo (specifična dejanja tukaj so odvisna od tehnološkega sklada, ki ga uporabljate, in drugih posebnosti aplikacije), nato pa se lahko poslovite od starega.

Za zadnjo operacijo (tj. že po preklop aplikacije na novo gručo) pojdite na vsako vozlišče star gručo in izvedite ukaze:

rabbitmqctl stop_app
rabbitmqctl reset

Grozd je »pozabil« na stara vozlišča: stari RMQ lahko izbrišete in na tej točki bo premik končan.

Obvestilo: Če uporabljate RMQ s potrdili, se nič bistveno ne spremeni - postopek premikanja bo izveden popolnoma enako.

Ugotovitve

Opisana shema je primerna za skoraj vse primere, ko moramo preseliti RabbitMQ ali se preprosto preseliti v novo gručo.

V našem primeru so se težave pojavile samo enkrat, ko je bil dostop do RMQ iz mnogih krajev in nismo imeli povsod možnosti spremeniti naslova RMQ na novega. Nato smo zagnali nov RMQ v istem imenskem prostoru z enakimi oznakami, tako da bi spadal pod obstoječe storitve in vstope, pri zagonu poda pa smo oznake manipulirali ročno in jih odstranili na začetku, da zahteve ne bi padle na prazen RMQ in jih znova dodajte, ko so sporočila sinhronizirana.

Enako strategijo smo uporabili pri posodabljanju RabbitMQ na novo različico s spremenjeno konfiguracijo - vse je delovalo kot ura.

PS

Kot logično nadaljevanje tega gradiva pripravljamo članke o MongoDB (migracija s strežnika strojne opreme na Kubernetes) in MySQL (kako pripravimo to DBMS znotraj Kubernetesa). Objavljeni bodo v prihodnjih mesecih.

PPS

Preberite tudi na našem blogu:

• «Baze podatkov in Kubernetes (pregled in video poročilo)»;
• «K8s nasveti in triki: Pospešitev zagona za velike podatkovne baze".

Vir: www.habr.com