🥇 Gladde migrasie van RabbitMQ na Kubernetes

RabbitMQ is 'n boodskapmakelaar geskryf in Erlang wat jou toelaat om 'n failover-kluster te organiseer met volledige data-replikasie oor verskeie nodusse, waar elke nodus lees- en skryfversoeke kan bedien. Met baie Kubernetes-klusters in produksiebedryf, ondersteun ons 'n groot aantal RabbitMQ-installasies en het ons gekonfronteer met die behoefte om data van een groep na 'n ander te migreer sonder stilstand.

Ons het hierdie operasie in ten minste twee gevalle nodig:

Die oordrag van data vanaf 'n RabbitMQ-groepering wat nie in Kubernetes geleë is nie, na 'n nuwe - reeds "gekubernetiseerde" (d.i. werk in K8s-peule) - groepering.
Migrasie van RabbitMQ binne Kubernetes van een naamruimte na 'n ander (byvoorbeeld, as stroombane deur naamruimtes afgebaken word, dan om infrastruktuur van een stroombaan na 'n ander oor te dra).

Die resep wat in die artikel voorgestel word, is gefokus op situasies (maar is glad nie daartoe beperk nie) waarin daar 'n ou RabbitMQ-kluster is (byvoorbeeld van 3 nodusse), óf reeds in K8's óf op sommige ou bedieners geleë. 'n Toepassing wat op Kubernetes aangebied word (reeds daar of in die toekoms) werk daarmee:

... en ons staan voor die taak om dit na die nuwe produksie in Kubernetes te migreer.

Eerstens sal die algemene benadering tot die migrasie self beskryf word, en daarna sal die tegniese besonderhede van die implementering daarvan beskryf word.

Migrasie-algoritme

Die eerste, voorlopige, stadium voor enige aksie is om te kontroleer dat hoë beskikbaarheid-modus in die ou RabbitMQ-installasie (HA). Die rede is voor die hand liggend - ons wil geen data verloor nie. Om hierdie kontrole uit te voer, kan jy na die RabbitMQ-adminpaneel gaan en in die Admin → Beleide-oortjie seker maak dat die waarde gestel is ha-mode: all:

Die volgende stap is om 'n nuwe RabbitMQ-kluster in Kubernetes-peule te verhoog (in ons geval, byvoorbeeld, bestaande uit 3 nodusse, maar hul aantal kan anders wees).

Hierna voeg ons die ou en nuwe RabbitMQ-klusters saam en verkry 'n enkele groep (van 6 nodusse):

Die proses van datasinchronisasie tussen die ou en nuwe RabbitMQ-klusters word begin. Sodra alle data tussen alle nodusse in die groep gesinchroniseer is, kan ons die toepassing oorskakel om die nuwe groep te gebruik:

Na hierdie operasies is dit genoeg om die ou nodusse uit die RabbitMQ-groepering te verwyder, en die skuif kan as voltooi beskou word:

Ons het hierdie skema al baie keer in produksie gebruik. Ons het dit egter vir ons eie gerief binne 'n gespesialiseerde stelsel geïmplementeer wat standaard RMQ-konfigurasies oor verskeie Kubernetes-klusters versprei (vir diegene wat nuuskierig is: ons praat van addon-operateurwaaroor ons pas onlangs vertel). Hieronder sal ons individuele instruksies aanbied wat enigiemand op hul installasies kan toepas om die voorgestelde oplossing in aksie te probeer.

Kom ons probeer dit in die praktyk

Vereistes

Die besonderhede is baie eenvoudig:

Kubernetes-kluster (minikube sal ook werk);
RabbitMQ-kluster (kan op kaal metaal ontplooi word, en gemaak word soos 'n gewone groep in Kubernetes vanaf die amptelike Helm-kaart).

Vir die voorbeeld hieronder het ek RMQ na Kubernetes ontplooi en dit genoem rmq-old.

Standvoorbereiding

1. Laai die Helm-kaart af en wysig dit 'n bietjie:

helm fetch --untar stable/rabbitmq-ha

Vir gerief stel ons 'n wagwoord, ErlangCookie en politiek maak ha-allsodat die rye by verstek gesinchroniseer word tussen alle nodusse van die RMQ-groepering:

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. Installeer die grafiek:

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

3. Gaan na die RabbitMQ admin paneel, skep 'n nuwe tou en voeg verskeie boodskappe by. Dit sal nodig wees sodat ons na migrasie seker kan maak dat al die data bewaar word en dat ons niks verloor het nie:

Die toetsbank is gereed: ons het die "ou" RabbitMQ met data wat oorgedra moet word.

Migreer 'n RabbitMQ-groepering

1. Kom ons ontplooi eers die nuwe RabbitMQ in vriend naamruimte met dieselfde ErlangCookie en wagwoord vir die gebruiker. Om dit te doen, sal ons die bewerkings uitvoer wat hierbo beskryf word, en die finale opdrag vir die installering van RMQ verander na die volgende:

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

2. Nou moet jy die nuwe cluster met die ou een saamsmelt. Om dit te doen, gaan na elkeen van die peule nuut RabbitMQ en voer die opdragte uit:

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 'n veranderlike OLD_RMQ die adres van een van die nodusse word gevind oud RMQ-groepering.

Hierdie opdragte sal die huidige nodus stop nuut RMQ cluster, heg dit aan die ou cluster en begin dit weer.

3. RMQ-groepering van 6 nodusse is gereed:

Jy moet wag terwyl boodskappe tussen alle nodusse gesinchroniseer word. Dit is nie moeilik om te raai dat die boodskapsinchronisasietyd afhang van die kapasiteit van die hardeware waarop die groepering ontplooi word en van die aantal boodskappe nie. In die beskryfde scenario is daar net 10 van hulle, so die data is onmiddellik gesinchroniseer, maar met 'n voldoende groot aantal boodskappe kan sinchronisasie vir ure duur.

Dus, die sinchronisasiestatus:

Hier +5 beteken boodskappe is reeds in ещё op 5 nodusse (behalwe vir wat in die veld aangedui word Node). Die sinchronisasie was dus suksesvol.

4. Al wat oorbly, is om die RMQ-adres in die toepassing na die nuwe cluster oor te skakel (die spesifieke aksies hier hang af van die tegnologiestapel wat jy gebruik en ander toepassingspesifieke), waarna jy die ou een kan groet.

Vir die laaste operasie (d.w.s. reeds na die toepassing na 'n nuwe groep oor te skakel) gaan na elke nodus oud groepeer en voer die opdragte uit:

rabbitmqctl stop_app
rabbitmqctl reset

Die groep het die ou nodusse "vergeet": jy kan die ou RMQ uitvee, op watter punt die skuif voltooi sal wees.

Let daarop: As jy RMQ met sertifikate gebruik, verander niks fundamenteel nie - die skuifproses sal presies dieselfde uitgevoer word.

Bevindinge

Die beskryfde skema is geskik vir byna alle gevalle wanneer ons RabbitMQ moet migreer of bloot na 'n nuwe groep moet skuif.

In ons geval het probleme net een keer ontstaan, toe toegang tot RMQ vanaf baie plekke verkry is, en ons het nie oral die geleentheid gehad om die RMQ-adres na 'n nuwe een te verander nie. Toe het ons 'n nuwe RMQ in dieselfde naamruimte met dieselfde etikette geloods sodat dit onder bestaande dienste en Ingresse sou val, en toe ons die pod begin het, het ons die etikette met die hand gemanipuleer en hulle aan die begin verwyder sodat versoeke nie op die leë RMQ, en voeg dit terug nadat die boodskappe gesinchroniseer is.

Ons het dieselfde strategie gebruik toe ons RabbitMQ opgedateer het na 'n nuwe weergawe met 'n veranderde konfigurasie - alles het soos 'n horlosie gewerk.

PS

As 'n logiese voortsetting van hierdie materiaal, berei ons artikels voor oor MongoDB (migrasie van 'n hardewarebediener na Kubernetes) en MySQL (hoe ons hierdie DBMS binne Kubernetes voorberei). Hulle sal in die komende maande gepubliseer word.

Naatlose RabbitMQ na Kubernetes migrasie