{"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\/ro\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"Migrarea complicat\u0103 a RabbitMQ \u00een Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Migrarea
\n
\nRabbitMQ \u2013 un broker de mesaje scris \u00een Erlang, care permite organizarea unui cluster rezistent la defecte, cu replicarea complet\u0103 a datelor pe mai multe noduri, fiecare dintre acestea put\u00e2nd gestiona cereri de citire \u0219i scriere. Av\u00e2nd numeroase clustere Kubernetes \u00een exploatare \u00een produc\u021bie, sus\u021binem un num\u0103r mare de instal\u0103ri RabbitMQ \u0219i ne-am confruntat cu necesitatea de a migra date dintr-un cluster \u00een altul f\u0103r\u0103 a avea \u00eentreruperi.<\/a><\/noindex><\/p>\n

Aceast\u0103 opera\u021biune a fost necesar\u0103 \u00een cel pu\u021bin dou\u0103 situa\u021bii:<\/p>\n

    \n
  1. Transferul datelor dintr-un cluster RabbitMQ care nu este \u00een Kubernetes \u00eentr-un nou \u2013 deja \u00abkubernetizat\u00bb (adic\u0103 func\u021bion\u00e2nd \u00een poduri K8s) \u2013 cluster.<\/li>\n
  2. Migrarea RabbitMQ \u00een cadrul Kubernetes dintr-un namespace \u00een altul (de exemplu, dac\u0103 contururile sunt delimitate de spa\u021bii de nume, atunci pentru a transfera infrastructura dintr-un contur \u00een altul).<\/li>\n<\/ol>\n

    \nRe\u021beta propus\u0103 \u00een acest articol este orientat\u0103 spre situa\u021bii (dar nu se limiteaz\u0103 doar la acestea) \u00een care exist\u0103 un vechi cluster RabbitMQ (de exemplu, format din 3 noduri), care este fie deja \u00een K8s, fie pe unele servere vechi. Acesta este folosit de o aplica\u021bie plasat\u0103 \u00een Kubernetes (fie deja acolo sau \u00een perspectiv\u0103):<\/p>\n

    \"Migrarea
    \n
    \n\u2026 \u0219i ne confrunt\u0103m cu sarcina de a-l migra \u00een noul mediu de produc\u021bie \u00een Kubernetes.<\/p>\n

    La \u00eenceput, va fi descris\u0103 abordarea general\u0103 a migra\u021biei, iar ulterior detaliile tehnice ale implement\u0103rii acesteia.<\/p>\n

    Algoritmul de migrare<\/h2>\n

    \nPrimul pas, preliminar, \u00eenainte de orice ac\u021biune \u2013 verificarea dac\u0103 \u00een vechea instalare RabbitMQ este activat modul de \u00eenalt\u0103 disponibilitate (HA<\/a><\/noindex>). Motiva\u021bia este evident\u0103 \u2013 nu dorim s\u0103 pierdem date. Pentru a efectua aceast\u0103 verificare, putem accesa interfa\u021ba de administrare a RabbitMQ \u0219i, \u00een tab-ul Admin \u2192 Policies, ne asigur\u0103m c\u0103 este setat\u0103 valoarea ha-mode: all<\/code>:<\/p>\n

    \"Migrarea
    \n
    \nUrm\u0103torul pas \u2013 ridic\u0103m un nou cluster RabbitMQ \u00een podurile Kubernetes (\u00een cazul nostru, de exemplu, format din 3 noduri, dar num\u0103rul lor poate fi diferit).<\/p>\n

    Dup\u0103 aceasta, combin\u0103m vechiul \u0219i noul cluster RabbitMQ, ob\u021bin\u00e2nd un singur cluster (format din 6 noduri):<\/p>\n

    \"Migrarea
    \n
    \nSe ini\u021biaz\u0103 procesul de sincronizare a datelor \u00eentre vechiul \u0219i noul cluster RabbitMQ. Dup\u0103 ce toate datele sunt sincronizate \u00eentre toate nodurile din cluster, putem comuta aplica\u021bia pentru a folosi noul cluster:<\/p>\n

    \"Migrarea
    \n
    \nDup\u0103 aceste opera\u021biuni, este suficient s\u0103 elimin\u0103m din clusterul RabbitMQ vechile noduri, iar mutarea poate fi considerat\u0103 finalizat\u0103:<\/p>\n

    \"Migrarea
    \n
    \nAceast\u0103 schem\u0103 a fost aplicat\u0103 de mai multe ori \u00een produc\u021bia noastr\u0103. Totu\u0219i, pentru confortul propriu, am implementat-o \u00een cadrul unui sistem specializat, care distribuie configura\u021bii standard RMQ pe un num\u0103r mare de clustere Kubernetes. (pentru cei curio\u0219i: este vorba despre     addon-operator<\/a><\/noindex>, despre care noi tocmai am povestit<\/a><\/noindex>)<\/i>. Mai jos vor fi prezentate instruc\u021biuni separate, pe care fiecare le poate aplica \u00een instal\u0103rile proprii pentru a testa propunerea \u00een ac\u021biune.<\/p>\n

    S\u0103 \u00eencerc\u0103m \u00een practic\u0103<\/h2>\n

    <\/p>\n

    Cerin\u021be<\/h3>\n

    \nCeriuile sunt foarte simple:<\/p>\n

      \n
    1. Cluster Kubernetes (poate fi \u0219i minikube);<\/li>\n
    2. Cluster RabbitMQ (poate fi implementat pe bare metal sau creat ca un cluster obi\u0219nuit \u00een Kubernetes din graficul oficial Helm).<\/li>\n<\/ol>\n

      \nPentru exemplul descris mai jos, am implementat RMQ \u00een Kubernetes \u0219i l-am numit rmq-old<\/code>.<\/p>\n

      Preg\u0103tirea standului<\/h3>\n

      \n1. Vom desc\u0103rca graficul Helm \u0219i \u00eel vom edita pu\u021bin:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nPentru comoditate, stabilim parola, ErlangCookie<\/code> \u0219i facem politica ha-all<\/code>, astfel \u00eenc\u00e2t, implicit, co\u0219urile s\u0103 se sincronizeze \u00eentre toate nodurile clusterului 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. Instal\u0103m graficul:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Acces\u0103m interfa\u021ba de administrare RabbitMQ, cre\u0103m un nou co\u0219 \u0219i ad\u0103ug\u0103m c\u00e2teva mesaje. Acestea vor fi necesare pentru a ne asigura c\u0103, dup\u0103 migrare, toate datele au fost p\u0103strate \u0219i nu am pierdut nimic:<\/p>\n
      \"Migrarea
      \n
      \nStandul de testare este gata: avem un RabbitMQ \u201evechi\u201d cu datele care trebuie migrate.<\/p>\n
      Migrarea clusterului RabbitMQ<\/h3>\n
      \n1. \u00cen primul r\u00e2nd, vom implementa un nou RabbitMQ \u00een alt<\/b> spa\u021biu de nume cu acelea\u0219i<\/b> ErlangCookie<\/code> \u0219i parol\u0103 pentru utilizator. Pentru aceasta, vom efectua opera\u021biile descrise mai sus, modific\u00e2nd comanda final\u0103 de instalare RMQ la urm\u0103toarea:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Acum trebuie s\u0103 unim noul cluster cu cel vechi. Pentru aceasta, acces\u0103m fiecare dintre podurile noului<\/b> RabbitMQ \u0219i execut\u0103m comenzile:<\/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
      \n\u00cen variabila OLD_RMQ<\/code> reprezint\u0103 adresa unuia dintre nodurile vechiului<\/b> cluster RMQ.<\/p>\n
      Aceste comenzi vor opri nodul curent noului<\/b> al clusterului RMQ, \u00eel vor al\u0103tura vechiului cluster \u0219i \u00eel vor reporni.<\/p>\n
      3. Clusterul RMQ din 6 noduri este gata:<\/p>\n
      \"Migrarea
      \n
      \nTrebuie s\u0103 a\u0219tepta\u021bi p\u00e2n\u0103 c\u00e2nd mesajele se sincronizeaz\u0103 \u00eentre toate nodurile. Nu e greu de intuit c\u0103 timpul de sincronizare a mesajelor depinde de puterea hardware-ului pe care este desf\u0103\u0219urat clusterul \u0219i de num\u0103rul de mesaje. \u00cen cazul descris, sunt doar 10, a\u0219a c\u0103 datele s-au sincronizat instantaneu, dar cu un num\u0103r suficient de mare de mesaje, sincronizarea poate dura ore \u00eentregi.<\/p>\n
      A\u0219adar, starea sincroniz\u0103rii:<\/p>\n
      \"Migrarea
      \n
      \nAici +5<\/code> \u00eenseamn\u0103 c\u0103 mesajele sunt deja \u00eenc\u0103<\/b> pe 5 noduri (\u00een afar\u0103 de cel men\u021bionat \u00een c\u00e2mpul Node<\/code>). Astfel, sincronizarea a avut loc cu succes.<\/p>\n
      4. R\u0103m\u00e2ne doar s\u0103 schimb\u0103m \u00een aplica\u021bie adresa RMQ pe noul cluster (ac\u021biunile specifice aici depind de tehnologia pe care o utiliza\u021bi \u0219i de alte particularit\u0103\u021bi ale aplica\u021biei), dup\u0103 care putem lua la revedere de la cel vechi.<\/p>\n
      Pentru ultima opera\u021biune (adic\u0103 deja dup\u0103<\/b> schimbarea aplica\u021biei pe noul cluster) intr\u0103m pe fiecare nod vechiului<\/b> al clusterului \u0219i execut\u0103m comenzile:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nClusterul a \"uitat\" de nodurile vechi: se poate \u0219terge RMQ-ul vechi, iar migrarea va fi complet\u0103.<\/p>\n
      Not\u0103<\/b>: Dac\u0103 utiliza\u021bi RMQ cu certificate, principial nimic nu se schimb\u0103 \u2014 procesul de migrare se va desf\u0103\u0219ura exact la fel.<\/i><\/p>\n
      Conclusions<\/h2>\n
      \nSchema descris\u0103 se potrive\u0219te practic pentru toate cazurile \u00een care trebuie s\u0103 mut\u0103m RabbitMQ sau pur \u0219i simplu s\u0103 ne transfer\u0103m \u00eentr-un nou cluster.<\/p>\n
      \u00cen cazul nostru, dificult\u0103\u021bile au ap\u0103rut doar o dat\u0103, c\u00e2nd RMQ-ul era accesat din multe locuri, iar noi nu aveam posibilitatea s\u0103 schimb\u0103m adresa RMQ la noua loca\u021bie peste tot. Atunci am pornit un nou RMQ \u00een acela\u0219i spa\u021biu de nume cu etichete identice, astfel \u00eenc\u00e2t s\u0103 intre sub serviciile \u0219i Ingress-urile deja existente, iar la pornirea podului am manipulat manual etichetele, elimin\u00e2ndu-le la \u00eenceput pentru ca cererile s\u0103 nu ajung\u0103 la RMQ-ul gol, \u0219i ad\u0103ug\u00e2ndu-le \u00eenapoi dup\u0103 sincronizarea mesajelor.<\/p>\n
      Am aplicat aceea\u0219i strategie \u0219i la actualizarea RabbitMQ la o nou\u0103 versiune cu o configura\u021bie modificat\u0103 \u2014 totul a func\u021bionat ca un ceas.<\/p>\n
      P.S.<\/h2>\n
      \nCa o continuare logic\u0103 a acestui material, preg\u0103tim articole despre MongoDB (migrarea de pe un server fizic \u00een Kubernetes) \u0219i MySQL (cum preg\u0103tim aceast\u0103 SGBD \u00een Kubernetes). Acestea vor fi publicate \u00een lunile urm\u0103toare.<\/p>\n
      P.P.S.<\/h2>\n
      \nCiti\u021bi \u0219i \u00een blogul nostru:<\/p>\n