Migrare fără probleme a RabbitMQ la Kubernetes

RabbitMQ este un broker de mesaje scris în Erlang care vă permite să organizați un cluster de failover cu replicare completă a datelor pe mai multe noduri, unde fiecare nod poate deservi solicitările de citire și scriere. Având multe clustere Kubernetes în operațiune de producție, acceptăm un număr mare de instalări RabbitMQ și ne-am confruntat cu nevoia de a migra datele de la un cluster la altul fără timpi de nefuncționare.

Am avut nevoie de această operație în cel puțin două cazuri:

1. Transferarea datelor de la un cluster RabbitMQ care nu se află în Kubernetes într-un cluster nou – deja „kubernetizat” (adică care operează în pod-uri K8s).
2. Migrarea lui RabbitMQ în Kubernetes de la un spațiu de nume la altul (de exemplu, dacă circuitele sunt delimitate de spații de nume, atunci pentru a transfera infrastructura de la un circuit la altul).

Rețeta propusă în articol este axată pe situații (dar nu se limitează deloc la acestea) în care există un cluster RabbitMQ vechi (de exemplu, de 3 noduri), aflat fie deja în K8-uri, fie pe niște servere vechi. O aplicație găzduită pe Kubernetes (deja acolo sau în viitor) funcționează cu ea:

... și ne confruntăm cu sarcina de a-l migra la noua producție în Kubernetes.

În primul rând, va fi descrisă abordarea generală a migrației în sine, iar apoi vor fi descrise detaliile tehnice ale implementării acesteia.

Algoritm de migrare

Prima etapă preliminară înainte de orice acțiune este să verificați dacă modul de înaltă disponibilitate este activat în vechea instalare RabbitMQ (HA). Motivul este evident - nu vrem să pierdem date. Pentru a efectua această verificare, puteți accesa panoul de administrare RabbitMQ și în fila Administrator → Politici asigurați-vă că valoarea este setată ha-mode: all:

Următorul pas este să ridicăm un nou cluster RabbitMQ în podurile Kubernetes (în cazul nostru, de exemplu, format din 3 noduri, dar numărul acestora poate fi diferit).

După aceasta, îmbinăm clusterele vechi și noi RabbitMQ, obținând un singur cluster (din 6 noduri):

Procesul de sincronizare a datelor între vechiul și noul cluster RabbitMQ este inițiat. Odată ce toate datele sunt sincronizate între toate nodurile din cluster, putem comuta aplicația pentru a utiliza noul cluster:

După aceste operațiuni, este suficient să eliminați nodurile vechi din clusterul RabbitMQ, iar mutarea poate fi considerată completă:

Am folosit această schemă de multe ori în producție. Cu toate acestea, pentru confortul nostru, l-am implementat într-un sistem specializat care distribuie configurații standard RMQ în mai multe clustere Kubernetes. (pentru cei curioși: vorbim despre addon-operatordespre care noi tocmai recent spus). Mai jos vă vom prezenta instrucțiuni individuale pe care oricine le poate aplica asupra instalațiilor sale pentru a încerca soluția propusă în acțiune.

Să încercăm în practică

Cerințe

Detaliile sunt foarte simple:

1. cluster Kubernetes (va funcționa și minikube);
2. Cluster RabbitMQ (poate fi implementat pe bare metal și realizat ca un cluster obișnuit în Kubernetes din diagrama oficială Helm).

Pentru exemplul de mai jos, am implementat RMQ în Kubernetes și l-am numit rmq-old.

Pregătirea standului

1. Descărcați diagrama Helm și editați-o puțin:

helm fetch --untar stable/rabbitmq-ha

Pentru comoditate, setăm o parolă, ErlangCookie si fac politica ha-allastfel încât, implicit, cozile să fie sincronizate între toate nodurile clusterului 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. Instalați diagrama:

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

3. Accesați panoul de administrare RabbitMQ, creați o nouă coadă și adăugați mai multe mesaje. Ele vor fi necesare pentru ca după migrare să ne asigurăm că toate datele sunt păstrate și că nu am pierdut nimic:

Bancul de testare este gata: avem „vechiul” RabbitMQ cu date care trebuie transferate.

Migrarea unui cluster RabbitMQ

1. Mai întâi, să implementăm noul RabbitMQ în prietene spatiu de nume cu la fel ErlangCookie și parola pentru utilizator. Pentru a face acest lucru, vom efectua operațiunile descrise mai sus, schimbând comanda finală pentru instalarea RMQ în următoarea:

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

2. Acum trebuie să îmbinați noul cluster cu cel vechi. Pentru a face acest lucru, mergeți la fiecare dintre păstăi nou RabbitMQ și executați comenzile:

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

Într-o variabilă OLD_RMQ se găsește adresa unuia dintre noduri vechi cluster RMQ.

Aceste comenzi vor opri nodul curent nou Cluster RMQ, atașați-l la vechiul cluster și lansați-l din nou.

3. Clusterul RMQ de 6 noduri este gata:

Trebuie să așteptați până când mesajele sunt sincronizate între toate nodurile. Nu este greu de ghicit că timpul de sincronizare a mesajelor depinde de capacitatea hardware-ului pe care este implementat clusterul și de numărul de mesaje. În scenariul descris, sunt doar 10, deci datele au fost sincronizate instantaneu, dar cu un număr suficient de mare de mesaje, sincronizarea poate dura ore întregi.

Deci, starea de sincronizare:

Aici +5 înseamnă că mesajele sunt deja introduse mai mult pe 5 noduri (cu excepția a ceea ce este indicat în câmp Node). Astfel, sincronizarea a avut succes.

4. Mai rămâne doar să comutați adresa RMQ din aplicație la noul cluster (acțiunile specifice de aici depind de stiva de tehnologie pe care o utilizați și de alte specificități ale aplicației), după care vă puteți lua rămas bun de la vechiul.

Pentru ultima operație (adică deja după trecerea aplicației la un cluster nou) mergeți la fiecare nod vechi cluster și executați comenzile:

rabbitmqctl stop_app
rabbitmqctl reset

Clusterul a „uitat” de nodurile vechi: puteți șterge vechiul RMQ, moment în care mutarea va fi finalizată.

Nota: Dacă utilizați RMQ cu certificate, atunci nimic nu se schimbă fundamental - procesul de mutare se va desfășura exact la fel.

Constatări

Schema descrisă este potrivită pentru aproape toate cazurile în care trebuie să migrăm RabbitMQ sau pur și simplu să trecem la un cluster nou.

În cazul nostru, dificultățile au apărut o singură dată, când RMQ a fost accesat din multe locuri și nu am avut posibilitatea de a schimba adresa RMQ cu una nouă peste tot. Apoi am lansat un nou RMQ în același spațiu de nume cu aceleași etichete, astfel încât să se încadreze în serviciile și Intrările existente, iar la lansarea podului am manipulat etichetele manual, eliminându-le la început pentru ca cererile să nu cadă pe goliți RMQ și adăugați-le înapoi după ce mesajele sunt sincronizate.

Am folosit aceeași strategie când am actualizat RabbitMQ la o versiune nouă cu o configurație schimbată - totul a funcționat ca un ceas.

PS

Ca o continuare logică a acestui material, pregătim articole despre MongoDB (migrarea de la un server hardware la Kubernetes) și MySQL (cum pregătim acest DBMS în Kubernetes). Acestea vor fi publicate în lunile următoare.

PPS

Citește și pe blogul nostru:

• «Baze de date și Kubernetes (prezentare generală și raport video)»;
• «Sfaturi și trucuri K8s: Accelerarea bootstrapului pentru bazele de date mari".

Sursa: www.habr.com