RabbitMQ és un intermediari de missatges escrit en Erlang que us permet organitzar un clúster de migració per error amb replicació completa de dades en diversos nodes, on cada node pot atendre les sol·licituds de lectura i escriptura. Tenint molts clústers de Kubernetes en funcionament de producció, donem suport a un gran nombre d'instal·lacions de RabbitMQ i ens hem enfrontat a la necessitat de migrar les dades d'un clúster a un altre sense temps d'inactivitat.
Vam necessitar aquesta operació en almenys dos casos:
- Transferència de dades d'un clúster RabbitMQ que no es troba a Kubernetes a un clúster nou, ja "kubernetitzat" (és a dir, que funciona en pods K8s).
- Migració de RabbitMQ dins de Kubernetes d'un espai de noms a un altre (per exemple, si els circuits estan delimitats per espais de noms, llavors per transferir infraestructura d'un circuit a un altre).
La recepta que es proposa a l'article està centrada en situacions (però no es limita gens a elles) en què hi ha un clúster RabbitMQ antic (per exemple, de 3 nodes), situat ja sigui en K8s o en alguns servidors antics. Una aplicació allotjada a Kubernetes (ja allà o en el futur) funciona amb ella:
... i estem davant la tasca de migrar-lo a la nova producció de Kubernetes.
En primer lloc, es descriurà l'enfocament general de la pròpia migració, i després es descriuran els detalls tècnics de la seva implementació.
Algorisme de migració
La primera etapa, preliminar, abans de qualsevol acció és comprovar que el mode d'alta disponibilitat està habilitat a l'antiga instal·lació de RabbitMQ (). El motiu és evident: no volem perdre cap dada. Per dur a terme aquesta comprovació, podeu anar al tauler d'administració de RabbitMQ i, a la pestanya Administrador → Polítiques, assegureu-vos que el valor estigui definit ha-mode: all:
El següent pas és crear un nou clúster RabbitMQ als pods de Kubernetes (en el nostre cas, per exemple, format per 3 nodes, però el seu nombre pot ser diferent).
Després d'això, fusionem els clústers antics i nous de RabbitMQ, obtenint un únic clúster (de 6 nodes):
S'inicia el procés de sincronització de dades entre els clústers antics i nous de RabbitMQ. Un cop totes les dades estiguin sincronitzades entre tots els nodes del clúster, podem canviar l'aplicació per utilitzar el nou clúster:
Després d'aquestes operacions, n'hi ha prou amb eliminar els nodes antics del clúster RabbitMQ i el moviment es pot considerar completa:
Hem utilitzat aquest esquema moltes vegades en la producció. No obstant això, per a la nostra pròpia comoditat, el vam implementar dins d'un sistema especialitzat que distribueix configuracions RMQ estàndard entre diversos clústers de Kubernetes. (per als curiosos: estem parlant sobre el qual nosaltres ). A continuació us presentarem instruccions individuals que qualsevol persona pot aplicar a les seves instal·lacions per provar la solució proposada en acció.
Provem-ho a la pràctica
Requisits
Els detalls són molt senzills:
- Clúster Kubernetes (minikube també funcionarà);
- Clúster RabbitMQ (es pot desplegar en metall nu i fer com un clúster normal a Kubernetes a partir del gràfic oficial de Helm).
Per a l'exemple següent, vaig implementar RMQ a Kubernetes i el vaig cridar rmq-old.
Preparació de l'estand
1. Baixeu el gràfic Helm i editeu-lo una mica:
helm fetch --untar stable/rabbitmq-ha
Per comoditat, establim una contrasenya, ErlangCookie i fer política ha-allde manera que, per defecte, les cues es sincronitzen entre tots els nodes del clúster 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. Instal·leu el gràfic:
helm install . --name rmq-old --namespace rmq-old3. Aneu al tauler d'administració de RabbitMQ, creeu una cua nova i afegiu diversos missatges. Seran necessaris perquè després de la migració ens assegurem que es conserven totes les dades i no hem perdut res:
El banc de proves està preparat: tenim el RabbitMQ "vell" amb dades que cal transferir.
Migració d'un clúster RabbitMQ
1. Primer, implementem el nou RabbitMQ a amic espai de noms amb mateix ErlangCookie i contrasenya per a l'usuari. Per fer-ho, realitzarem les operacions descrites anteriorment, canviant l'ordre final per instal·lar RMQ a la següent:
helm install . --name rmq-new --namespace rmq-new2. Ara heu de combinar el nou clúster amb l'antic. Per fer-ho, aneu a cadascuna de les beines nou RabbitMQ i executeu les ordres:
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
En una variable OLD_RMQ es troba l'adreça d'un dels nodes vell Clúster RMQ.
Aquestes ordres aturaran el node actual nou Clúster RMQ, connecteu-lo al clúster antic i torneu-lo a iniciar.
3. El clúster RMQ de 6 nodes està preparat:
Heu d'esperar mentre els missatges es sincronitzin entre tots els nodes. No és difícil endevinar que el temps de sincronització dels missatges depèn de la capacitat del maquinari on es desplega el clúster i del nombre de missatges. En l'escenari descrit, només n'hi ha 10, de manera que les dades es van sincronitzar a l'instant, però amb un nombre prou gran de missatges, la sincronització pot durar hores.
Per tant, l'estat de sincronització:
Aquí +5 vol dir que ja hi ha missatges més en 5 nodes (excepte el que s'indica al camp Node). Així, la sincronització va tenir èxit.
4. Només queda canviar l'adreça RMQ de l'aplicació al nou clúster (les accions específiques aquí depenen de la pila tecnològica que utilitzeu i d'altres característiques específiques de l'aplicació), i després us podeu acomiadar de l'antic.
Per a l'última operació (és a dir, ja després canviar l'aplicació a un clúster nou) aneu a cada node vell cluster i executeu les ordres:
rabbitmqctl stop_app
rabbitmqctl resetEl clúster "s'ha oblidat" dels nodes antics: podeu suprimir l'RMQ antic, moment en què es completarà el moviment.
Nota: Si utilitzeu RMQ amb certificats, no canvia res fonamentalment: el procés de trasllat es farà exactament igual.
Troballes
L'esquema descrit és adequat per a gairebé tots els casos en què necessitem migrar RabbitMQ o simplement passar a un nou clúster.
En el nostre cas, les dificultats van sorgir només una vegada, quan es va accedir a RMQ des de molts llocs, i no vam tenir l'oportunitat de canviar l'adreça de RMQ per una de nova a tot arreu. Llavors vam llançar un nou RMQ al mateix espai de noms amb les mateixes etiquetes perquè caigués en els serveis i Ingresses existents, i en llançar el pod vam manipular les etiquetes a mà, eliminant-les al principi perquè les sol·licituds no caiguessin en el RMQ buit i tornar-los a afegir després de sincronitzar els missatges.
Hem utilitzat la mateixa estratègia en actualitzar RabbitMQ a una versió nova amb una configuració canviada: tot funcionava com un rellotge.
PS
Com a continuació lògica d'aquest material, estem preparant articles sobre MongoDB (migració d'un servidor de maquinari a Kubernetes) i MySQL (com preparem aquest DBMS dins de Kubernetes). Es publicaran en els propers mesos.
PPS
Llegeix també al nostre blog:
- «»;
- «».
Font: www.habr.com