Migrazione perfetta di RabbitMQ à Kubernetes

RabbitMQ hè un broker di messagiu scrittu in Erlang chì vi permette di urganizà un cluster di failover cù a replicazione completa di dati in parechji nodi, induve ogni nodu pò serve à leghje è scrive richieste. Avè parechji clusters Kubernetes in operazione di pruduzzione, supportemu un gran numaru di installazioni RabbitMQ è sò stati affruntati cù a necessità di migrà e dati da un cluster à l'altru senza downtime.

Avemu bisognu di sta operazione in almenu dui casi:

1. Trasferendu dati da un cluster RabbitMQ chì ùn hè micca situatu in Kubernetes à un novu cluster - digià "kubernetized" (vale à dì chì opera in pods K8s).
2. Migrazione di RabbitMQ in Kubernetes da un spaziu di nomi à l'altru (per esempiu, se i circuiti sò delimitati da spazii di nomi, allora per trasfiriri l'infrastruttura da un circuitu à l'altru).

A ricetta pruposta in l'articulu hè focu annantu à e situazioni (ma ùn hè micca limitatu à elli) in quale ci hè un vechju cluster RabbitMQ (per esempiu, di nodi 3), situatu o digià in K8s o in certi servitori antichi. Una applicazione ospitata in Kubernetes (dighjà quì o in u futuru) travaglia cun ella:

... è avemu affruntatu cù u compitu di migrallu à a nova pruduzzione in Kubernetes.

Prima, l'approcciu generale di a migrazione stessu serà discrittu, è dopu chì i dettagli tecnichi di a so implementazione seranu discritti.

Algoritmu di migrazione

A prima tappa preliminare prima di ogni azzione hè di verificà chì u modu di alta dispunibilità hè attivatu in a vechja installazione RabbitMQ (HA). U mutivu hè ovvi - ùn vulemu perde ogni dati. Per fà sta verificazione, pudete andà à u pannellu di amministrazione RabbitMQ è in a tabulazione Admin → Politiche assicuratevi chì u valore hè stabilitu. ha-mode: all:

U prossimu passu hè di suscitarà un novu cluster RabbitMQ in pods Kubernetes (in u nostru casu, per esempiu, custituitu di nodi 3, ma u so numeru pò esse diversu).

Dopu questu, fusionemu i vechji è novi clusters RabbitMQ, ottenendu un solu cluster (di 6 nodi):

U prucessu di sincronizazione di dati trà i vechji è novi clusters RabbitMQ hè iniziatu. Una volta chì tutti i dati sò sincronizati trà tutti i nodi in u cluster, pudemu cambià l'applicazione per utilizà u novu cluster:

Dopu queste operazioni, hè abbastanza per sguassà i vechji nodi da u cluster RabbitMQ, è u muvimentu pò esse cunsideratu cumpletu:

Avemu usatu stu schema parechje volte in a produzzione. Tuttavia, per a nostra propria cunvenzione, l'avemu implementatu in un sistema specializatu chì distribuisce cunfigurazioni RMQ standard in più cluster Kubernetes. (per quelli chì sò curiosi : si ne parla addun-operatorecirca chì noi appena dittu). Quì sottu vi prisintà struzzioni individuale chì qualcunu pò applicà nantu à e so installazioni per pruvà a suluzione pruposta in azzione.

Pruvemu in pratica

esigenze

I dettagli sò assai sèmplice:

1. Kubernetes cluster (minikube ancu travaglià);
2. RabbitMQ cluster (pò esse implementatu nantu à u metale nudu, è fattu cum'è un cluster regular in Kubernetes da u graficu ufficiale Helm).

Per l'esempiu quì sottu, aghju implementatu RMQ à Kubernetes è u chjamatu rmq-old.

Preparazione di stand

1. Scaricate u graficu Helm è edità un pocu:

helm fetch --untar stable/rabbitmq-ha

Per comodità, avemu stabilitu una password, ErlangCookie è fà a pulitica ha-allcusì chì, per difettu, e file sò sincronizate trà tutti i nodi di u cluster 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. Installa u cartulare:

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

3. Andà à u panel admin RabbitMQ, crea una nova fila è aghjunghje parechji missaghji. Seranu necessariu per chì dopu a migrazione pudemu assicurà chì tutti i dati sò cunservati è ùn avemu micca persu nunda:

U bancu di teste hè prontu: avemu u "vechju" RabbitMQ cù dati chì deve esse trasferitu.

Migrazione di un cluster RabbitMQ

1. Prima, deployemu u novu RabbitMQ in amicu namespace cun listessu ErlangCookie è password per l'utilizatore. Per fà questu, faremu l'operazioni descritte sopra, cambiendu u cumandamentu finali per installà RMQ à i seguenti:

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

2. Avà avete bisognu di unisce u novu cluster cù u vechju. Per fà questu, andate à ognuna di i baccelli novu RabbitMQ è eseguite i cumandamenti:

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

In una variabile OLD_RMQ l'indirizzu di unu di i nodi si trova vechju cluster RMQ.

Questi cumandamenti fermanu u node attuale novu RMQ cluster, attaccallu à u vechju cluster è lanciallu di novu.

3. U cluster RMQ di 6 nodi hè pronta:

Duvete aspittà mentre i missaghji sò sincronizati trà tutti i nodi. Ùn hè micca difficiule di guessà chì u tempu di sincronizazione di u messagiu dipende da a capacità di u hardware nantu à quale u cluster hè implementatu è da u numeru di missaghji. In u scenariu discrittu, ci sò solu 10 di elli, cusì i dati sò stati sincronizati istantaneamente, ma cù un numeru abbastanza grande di missaghji, a sincronizazione pò durà ore.

Allora, u statu di sincronizazione:

hè +5 significa chì i missaghji sò digià in di più nantu à i nodi 5 (eccettu ciò chì hè indicatu in u campu Node). Cusì, a sincronizazione hè stata successu.

4. Tuttu ciò chì resta hè di cambià l'indirizzu RMQ in l'appiecazione à u novu cluster (l'azzioni specifichi quì dipendenu da a pila di tecnulugia chì avete utilizatu è altre specificità di l'applicazione), dopu chì pudete dì addiu à u vechju.

Per l'ultima operazione (vale à dì digià после cambiendu l'applicazione à un novu cluster) andate à ogni node vechju cluster è eseguite i cumandamenti:

rabbitmqctl stop_app
rabbitmqctl reset

U cluster "scurdatu" di i vechji nodi: pudete sguassà l'antica RMQ, à quale puntu u muvimentu serà cumpletu.

Vita: Sè vo aduprate RMQ cù certificati, allura nunda di funnamintali cambia - u prucessu muvimenti sarà realizatu esattamente u listessu.

scuperti

U schema descrittu hè adattatu per quasi tutti i casi quandu avemu bisognu di migrà RabbitMQ o simpricimenti spustà à un novu cluster.

In u nostru casu, i difficultà sò ghjunti solu una volta, quandu RMQ hè stata accessu da parechji posti, è ùn avemu micca avutu l'uppurtunità di cambià l'indirizzu RMQ à un novu in ogni locu. Allora avemu lanciatu un novu RMQ in u stessu spaziu di nomi cù e stesse etichette per ch'ella cascassi in i servizii esistenti è Ingressi, è quandu lanciamu u pod avemu manipulatu l'etichette à a manu, sguassate à u principiu in modu chì e dumande ùn cascanu micca nantu à u RMQ viotu, è aghjunghjendu torna dopu chì i missaghji sò sincronizati.

Avemu usatu a stessa strategia quandu aghjurnà RabbitMQ à una nova versione cù una cunfigurazione cambiata - tuttu hà travagliatu cum'è un clock.

PS

Cum'è una continuazione logica di stu materiale, avemu preparatu articuli nantu à MongoDB (migrazione da un servitore hardware à Kubernetes) è MySQL (cumu preparemu stu DBMS in Kubernetes). Seranu publicati in i mesi à vene.

PPS

Leghjite puru nant'à u nostru blog:

• «Basi di dati è Kubernetes (revisione è video rapportu)";
• «Cunsiglii è trucchi di K8s: Accelerazione di bootstrap per grandi basa di dati».

Source: www.habr.com