{"id":33075,"date":"2019-10-31T21:50:35","date_gmt":"2019-10-31T18:50:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes\/"},"modified":"2019-10-31T21:50:35","modified_gmt":"2019-10-31T18:50:35","slug":"besprostojnaya-migratsiya-rabbitmq-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"Migrazione non semplice di RabbitMQ in Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Migrazione
\n
\nRabbitMQ \u00e8 un broker di messaggi scritto in Erlang, che consente di organizzare un cluster ad alta disponibilit\u00e0 con replicazione completa dei dati su pi\u00f9 nodi, dove ogni nodo pu\u00f2 gestire richieste di lettura e scrittura. Avendo in produzione molti cluster Kubernetes, gestiamo un gran numero di installazioni di RabbitMQ e ci siamo trovati nella necessit\u00e0 di migrare dati da un cluster all'altro senza downtime.<\/a><\/noindex><\/p>\n

Questa operazione \u00e8 stata necessaria in almeno due casi:<\/p>\n

    \n
  1. Trasferire dati da un cluster RabbitMQ non Kubernetes a un nuovo cluster 'kubernetesizzato' (cio\u00e8 funzionante in pod K8s).<\/li>\n
  2. Migrazione di RabbitMQ all'interno di Kubernetes da un namespace a un altro (ad esempio, se i confini sono delimitati dagli spazi dei nomi, \u00e8 necessario trasferire l'infrastruttura da un confine all'altro).<\/li>\n<\/ol>\n

    \nLa ricetta proposta nell'articolo \u00e8 orientata a situazioni (ma non limitata a esse) in cui \u00e8 presente un vecchio cluster RabbitMQ (ad esempio, composto da 3 nodi), che \u00e8 gi\u00e0 in K8s o su server obsoleti. Un'applicazione, gi\u00e0 presente o prevista, lavora con questo cluster in Kubernetes:<\/p>\n

    \"Migrazione
    \n
    \n\u2026 e ci troviamo di fronte alla necessit\u00e0 di migrare il cluster in un nuovo ambiente di produzione in Kubernetes.<\/p>\n

    Inizialmente verr\u00e0 descritto l'approccio generale alla migrazione, seguito da dettagli tecnici sulla sua attuazione.<\/p>\n

    Algoritmo di migrazione<\/h2>\n

    \nIl primo passo preliminare prima di qualsiasi azione \u00e8 verificare che nella vecchia installazione di RabbitMQ sia attivata la modalit\u00e0 ad alta disponibilit\u00e0 (HA<\/a><\/noindex>). La ragione \u00e8 ovvia: non vogliamo perdere alcun dato. Per effettuare questo controllo, \u00e8 possibile accedere all'interfaccia di amministrazione di RabbitMQ e nella scheda Admin \u2192 Policies verificare che il valore sia impostato su ha-mode: all<\/code>:<\/p>\n

    \"Migrazione
    \n
    \nIl passo successivo consiste nel creare un nuovo cluster RabbitMQ in pod Kubernetes (nel nostro caso, ad esempio, composto da 3 nodi, ma il numero pu\u00f2 variare).<\/p>\n

    Dopo di ci\u00f2, uniamo il vecchio e il nuovo cluster RabbitMQ, ottenendo un unico cluster (di 6 nodi):<\/p>\n

    \"Migrazione
    \n
    \nViene avviato il processo di sincronizzazione dei dati tra il vecchio e il nuovo cluster RabbitMQ. Dopo che tutti i dati sono stati sincronizzati tra tutti i nodi del cluster, possiamo passare l'applicazione all'uso del nuovo cluster:<\/p>\n

    \"Migrazione
    \n
    \nDopo queste operazioni, \u00e8 sufficiente disattivare i vecchi nodi dal cluster RabbitMQ, e il trasferimento pu\u00f2 considerarsi completato:<\/p>\n

    \"Migrazione
    \n
    \nAbbiamo applicato questo schema pi\u00f9 volte nella nostra produzione. Tuttavia, per comodit\u00e0, lo abbiamo implementato all'interno di un sistema specializzato che distribuisce configurazioni standard RMQ su pi\u00f9 cluster Kubernetes. (per chi \u00e8 curioso: si tratta di     addon-operator<\/a><\/noindex>, di cui abbiamo proprio recentemente abbiamo parlato<\/a><\/noindex>)<\/i>. Di seguito verranno presentate singole istruzioni che ognuno pu\u00f2 applicare nelle proprie installazioni per provare la soluzione proposta in azione.<\/p>\n

    Proviamo nella pratica<\/h2>\n

    <\/p>\n

    Requisiti<\/h3>\n

    \nI requisiti sono molto semplici:<\/p>\n

      \n
    1. Un cluster Kubernetes (va bene anche minikube);<\/li>\n
    2. Un cluster RabbitMQ (pu\u00f2 essere implementato su bare metal o come un normale cluster in Kubernetes utilizzando il Helm-chart ufficiale).<\/li>\n<\/ol>\n

      \nPer l'esempio descritto di seguito, ho implementato RMQ in Kubernetes e l'ho chiamato rmq-old<\/code>.<\/p>\n

      Preparazione dell'ambiente<\/h3>\n

      \n1. Scarichiamo il Helm-chart e lo modifichiamo leggermente:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nPer comodit\u00e0 impostiamo la password, ErlangCookie<\/code> e impostiamo la policy ha-all<\/code>, in modo che per default le code siano sincronizzate tra tutti i nodi del cluster RMQ:<\/p>\n
      rabbitmqPassword: guest\nrabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we\ndefinitions:\npolicies: |-\n  {\n    \"name\": \"ha-all\",\n    \"pattern\": \".*\",\n    \"vhost\": \"\\\/\",\n    \"definition\": {\n      \"ha-mode\": \"all\",\n      \"ha-sync-mode\": \"automatic\",\n      \"ha-sync-batch-size\": 81920\n    }\n  }<\/code><\/pre>\n
      \n2. Installiamo il chart:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Accediamo all'amministrazione di RabbitMQ, creiamo una nuova coda e aggiungiamo alcuni messaggi. Ci serviranno per verificare che tutti i dati siano stati salvati e che non abbiamo perso nulla dopo la migrazione:<\/p>\n
      \"Migrazione
      \n
      \nL'ambiente di test \u00e8 pronto: abbiamo un RabbitMQ \"vecchio\" con i dati che devono essere trasferiti.<\/p>\n
      Migrazione del cluster RabbitMQ<\/h3>\n
      \n1. Per prima cosa, implementiamo un nuovo RabbitMQ in un'altra<\/b> namespace con le stesse<\/b> ErlangCookie<\/code> e password per l'utente. Per farlo, effettuiamo le operazioni descritte sopra, modificando il comando finale per l'installazione di RMQ come segue:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Ora dobbiamo unire il nuovo cluster con quello vecchio. A tal fine, accediamo a ciascun pod del nuovo<\/b> RabbitMQ ed eseguiamo i seguenti comandi:<\/p>\n
      export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && \n  rabbitmqctl stop_app && \n  rabbitmqctl join_cluster $OLD_RMQ && \n  rabbitmqctl start_app<\/code><\/pre>\n
      \nNella variabile OLD_RMQ<\/code> c'\u00e8 l'indirizzo di uno dei nodi del vecchio<\/b> cluster RMQ.<\/p>\n
      Questi comandi fermeranno il nodo attuale nuovo<\/b> del cluster RMQ, lo uniranno al cluster vecchio e lo riavvieranno.<\/p>\n
      3. Il cluster RMQ con 6 nodi \u00e8 pronto:<\/p>\n
      \"Migrazione
      \n
      \n\u00c8 necessario attendere che i messaggi vengano sincronizzati tra tutti i nodi. Non \u00e8 difficile intuire che il tempo di sincronizzazione dei messaggi dipende dalle capacit\u00e0 hardware su cui \u00e8 distribuito il cluster e dal numero di messaggi. Nel caso descritto, ce ne sono solo 10, quindi i dati si sono sincronizzati istantaneamente, ma con un numero sufficientemente elevato di messaggi, la sincronizzazione pu\u00f2 durare ore.<\/p>\n
      Quindi, stato di sincronizzazione:<\/p>\n
      \"Migrazione
      \n
      \nQui +5<\/code> significa che i messaggi si trovano gi\u00e0 ancora<\/b> su 5 nodi (oltre a quello specificato nel campo Node<\/code>). Pertanto, la sincronizzazione \u00e8 stata completata con successo.<\/p>\n
      4. Resta solo da cambiare nell'app l'indirizzo RMQ al nuovo cluster (le azioni specifiche qui dipendono dal stack tecnologico che stai utilizzando e da altre specificit\u00e0 dell'app), dopo di che puoi salutare il vecchio.<\/p>\n
      Per l'ultima operazione (cio\u00e8 gi\u00e0 la data rientri nel PITR.<\/b> il passaggio dell'app al nuovo cluster), accediamo a ciascun nodo del vecchio<\/b> del cluster e eseguiamo i comandi:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nIl cluster ha \"dimenticato\" i vecchi nodi: puoi rimuovere il vecchio RMQ, a quel punto la migrazione sar\u00e0 completata.<\/p>\n
      Nota<\/b>: Se utilizzi RMQ con certificati, non cambia nulla di sostanziale: il processo di migrazione avverr\u00e0 proprio allo stesso modo.<\/i><\/p>\n
      Conclusioni<\/h2>\n
      \nLo schema descritto si adatta praticamente a tutti i casi in cui dobbiamo migrare RabbitMQ o semplicemente trasferirci a un nuovo cluster.<\/p>\n
      Nel nostro caso, le difficolt\u00e0 si sono presentate solo una volta, quando RMQ veniva utilizzato da molti luoghi e non avevamo la possibilit\u00e0 di cambiare ovunque l'indirizzo RMQ al nuovo. In quel caso, abbiamo avviato un nuovo RMQ nella stessa namespace con gli stessi label, affinch\u00e9 rientrasse nei servizi e negli ingress gi\u00e0 esistenti. Durante l'avvio del pod, abbiamo manipolato manualmente le etichette, rimuovendole all'inizio in modo che i richieste non andassero a un RMQ vuoto, e aggiungendole di nuovo dopo la sincronizzazione dei messaggi.<\/p>\n
      Abbiamo applicato la stessa strategia durante l'aggiornamento di RabbitMQ a una nuova versione con una configurazione modificata: tutto ha funzionato perfettamente.<\/p>\n
      P.S.<\/h2>\n
      \nCome naturale continuazione di questo materiale, stiamo preparando articoli su MongoDB (migrazione da server fisico a Kubernetes) e MySQL (come prepariamo questo DBMS all'interno di Kubernetes). Saranno pubblicati nei prossimi mesi.<\/p>\n
      P.P.S.<\/h2>\n
      \nLeggi anche nel nostro blog:<\/p>\n