RabbitMQ-ren migrazioa Kubernetesera

RabbitMQ Erlang-en idatzitako mezu-artekari bat da, eta horrek hutsegiteko kluster bat antolatzeko aukera ematen du hainbat nodotan datuen erreplikazio osoarekin, non nodo bakoitzak irakurketa- eta idazketa-eskaerei erantzuteko. Kubernetes-eko kluster asko ekoizpen-eragiketetan edukita, RabbitMQ instalazio ugari onartzen ditugu eta datuak kluster batetik bestera migratu beharra izan genuen geldialdirik gabe.

Eragiketa hau gutxienez bi kasutan behar izan dugu:

1. Kubernetes-en kokatuta ez dagoen RabbitMQ kluster batetik datuak transferitzea, dagoeneko "kubernetizatuta" (hau da, K8s podetan funtzionatzen duena) kluster batera.
2. Kubernetes-en RabbitMQ-ren migrazioa izen-espazio batetik bestera (adibidez, zirkuituak izen-espazioen bidez mugatzen badira, zirkuitu batetik bestera azpiegitura transferitzeko).

Artikuluan proposatzen den errezeta RabbitMQ kluster zahar bat (adibidez, 3 nodokoa) dagoen egoeretan zentratuta dago (baina ez dago batere mugatuta), jada K8etan edo zerbitzari zahar batzuetan kokatua. Kubernetes-en ostatatutako aplikazio batek (dagoeneko bertan edo etorkizunean) honekin funtzionatzen du:

... eta Kuberneteseko ekoizpen berrira migratzeko zereginaren aurrean gaude.

Lehenik eta behin, migrazioaren beraren ikuspegi orokorra deskribatuko da, eta, horren ondoren, haren ezarpenaren xehetasun teknikoak deskribatuko dira.

Migrazio algoritmoa

Edozein ekintzaren aurretiko lehen fasea RabbitMQ instalazio zaharrean erabilgarritasun handiko modua gaituta dagoela egiaztatzea da (HA). Arrazoia begi-bistakoa da: ez dugu daturik galdu nahi. Egiaztapen hau egiteko, RabbitMQ administrazio panelera joan zaitezke eta Admin → Politikak fitxan ziurtatu balioa ezarrita dagoela. ha-mode: all:

Hurrengo urratsa RabbitMQ kluster berri bat planteatzea da Kubernetes leketan (gure kasuan, adibidez, 3 nodoz osatua, baina haien kopurua ezberdina izan daiteke).

Honen ondoren, RabbitMQ kluster zaharra eta berria batzen ditugu, kluster bakarra lortuz (6 nodoz):

RabbitMQ kluster zaharren eta berriaren arteko datuak sinkronizatzeko prozesua abiarazi da. Datu guztiak klusterreko nodo guztien artean sinkronizatu ondoren, aplikazioa alda dezakegu kluster berria erabiltzeko:

Eragiketa horien ondoren, nahikoa da RabbitMQ klusterreko nodo zaharrak kentzea, eta mugimendua amaitutzat jo daiteke:

Eskema hau askotan erabili dugu ekoizpenean. Hala ere, gure erosotasunerako, Kubernetes kluster anitzetan RMQ konfigurazio estandarrak banatzen dituen sistema espezializatu baten barruan inplementatu dugu. (kuriositatea dutenentzat: hitz egiten ari gara gehigarri-eragilehorri buruz guk berriki kontatua). Jarraian, edonork bere instalazioetan aplika ditzakeen argibide indibidualak aurkeztuko ditugu, proposatutako irtenbidea martxan probatzeko.

Saia gaitezen praktikan

Baldintzak

Xehetasunak oso sinpleak dira:

1. Kubernetes clusterra (minikube ere funtzionatuko du);
2. RabbitMQ klusterra (metal hutsean heda daiteke eta Kubernetes-en ohiko kluster bat bezala egin daiteke Helm taula ofizialetik).

Beheko adibiderako, RMQ zabaldu nuen Kubernetes-en eta deitu nuen rmq-old.

Standaren prestaketa

1. Deskargatu Helm diagrama eta editatu pixka bat:

helm fetch --untar stable/rabbitmq-ha

Erosotasunerako, pasahitz bat ezarri dugu, ErlangCookie eta politika egin ha-allhorrela, lehenespenez, ilarak RMQ klusterreko nodo guztien artean sinkronizatzen dira:

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. Instalatu diagrama:

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

3. Joan RabbitMQ administrazio panelera, sortu ilara berri bat eta gehitu hainbat mezu. Beharrezkoak izango dira, migrazioaren ondoren datu guztiak gordeta daudela eta ezer galdu ez dugula ziurtatu ahal izateko:

Proba-bankua prest dago: RabbitMQ "zaharra" dugu transferitu beharreko datuekin.

RabbitMQ kluster bat migratzen

1. Lehenik eta behin, zabaldu dezagun RabbitMQ berria Lagun izen-eremuarekin bera ErlangCookie eta erabiltzailearen pasahitza. Horretarako, goian deskribatutako eragiketak egingo ditugu, RMQ instalatzeko azken komandoa honela aldatuz:

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

2. Orain kluster berria batu behar duzu zaharrarekin. Horretarako, joan leka bakoitzera berria RabbitMQ eta exekutatu komandoak:

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

Aldagaian OLD_RMQ nodoetako baten helbidea aurkitzen da zaharra RMQ klusterra.

Komando hauek uneko nodoa geldituko dute berria RMQ klusterra, erantsi kluster zaharrari eta abiarazi berriro.

3. 6 nodoko RMQ multzoa prest dago:

Nodo guztien artean mezuak sinkronizatzen diren bitartean itxaron behar duzu. Ez da zaila asmatzea mezuen sinkronizazio-denbora klusterra zabaltzen den hardwarearen ahalmenaren eta mezu kopuruaren araberakoa dela. Deskribatutako eszenatokian, 10 besterik ez daude, beraz, datuak berehala sinkronizatu ziren, baina mezu kopuru nahiko handiarekin, sinkronizazioak orduak iraun dezake.

Beraz, sinkronizazio egoera:

Hemen +5 mezuak dagoeneko sartuta daudela esan nahi du gehiago 5 nodotan (eremuan adierazitakoa izan ezik Node). Horrela, sinkronizazioa arrakastatsua izan zen.

4. Aplikazioko RMQ helbidea kluster berrira aldatzea besterik ez da geratzen (hemen ekintza zehatzak erabiltzen ari zaren teknologia-pilaren eta aplikazioaren beste zehaztasun batzuen araberakoak dira), eta ondoren zaharrari agur esan diezaiokezu.

Azken eragiketarako (hau da, dagoeneko ondoren aplikazioa kluster berri batera aldatuz) joan nodo bakoitzera zaharra multzokatu eta exekutatu komandoak:

rabbitmqctl stop_app
rabbitmqctl reset

Klusterrak nodo zaharrak "ahaztu" zituen: RMQ zaharra ezaba dezakezu, eta une horretan mugimendua amaituko da.

Kontuan izan: RMQ ziurtagiriekin erabiltzen baduzu, ez da ezer aldatzen funtsean - mugimendu-prozesua berdin egingo da.

Findings

Deskribatutako eskema egokia da RabbitMQ migratu edo, besterik gabe, kluster berri batera mugitu behar dugunean ia kasu guztietarako.

Gure kasuan, zailtasunak behin bakarrik sortu ziren, RMQ leku askotatik sartzen zenean, eta ez genuen aukerarik izan RMQ helbidea nonahi berri batera aldatzeko. Ondoren, RMQ berri bat abiarazi genuen izen-espazio berean etiketa berdinekin, lehendik zeuden zerbitzuen eta Ingressen barruan egon zedin, eta pod-a abiarazteko orduan etiketak eskuz manipulatu genituen, hasieran kenduz, eskaerak eror ez zitezen. RMQ hutsik, eta mezuak sinkronizatu ondoren berriro gehitu.

Estrategia bera erabili genuen RabbitMQ bertsio berri batera eguneratzean, konfigurazio aldatuarekin: dena erloju baten moduan funtzionatzen zuen.

PS

Material honen jarraipen logiko gisa, MongoDB (hardware zerbitzari batetik Kubernetesera migrazioa) eta MySQL (DBMS hau Kubernetesen barruan nola prestatzen dugun) artikuluak prestatzen ari gara. Datozen hilabeteetan argitaratuko dira.

PPS

Irakurri ere gure blogean:

• «Datu-baseak eta Kubernetes (berrikuspena eta bideo-txostena)»;
• «K8s aholkuak eta trikimailuak: datu-base handietarako bootstrap bizkortzea'.

Iturria: www.habr.com