Naadleaze migraasje fan RabbitMQ nei Kubernetes

RabbitMQ is in berjochtmakelaar skreaun yn Erlang wêrmei jo in failover-kluster kinne organisearje mei folsleine gegevensreplikaasje oer meardere knopen, wêrby't elke node lês- en skriuwfersiken kin tsjinje. Mei in protte Kubernetes-klusters yn produksjeoperaasje, stypje wy in grut oantal RabbitMQ-ynstallaasjes en waarden konfrontearre mei de needsaak om gegevens fan it iene kluster nei it oare te migrearjen sûnder downtime.

Wy hawwe dizze operaasje nedich yn op syn minst twa gefallen:

1. It oerdragen fan gegevens fan in RabbitMQ-kluster dat net yn Kubernetes leit nei in nij - al "kubernetisearre" (dus operearje yn K8s-pods) - kluster.
2. Migraasje fan RabbitMQ binnen Kubernetes fan de iene nammeromte nei de oare (bygelyks, as sirkwy wurde skieden troch nammeromten, dan oerdrage ynfrastruktuer fan de iene sirkwy nei de oare).

It resept foarsteld yn it artikel is rjochte op situaasjes (mar is hielendal net beheind ta harren) dêr't der in âlde RabbitMQ kluster (bygelyks, fan 3 knopen), leit itsij al yn K8s of op guon âlde tsjinners. In applikaasje hosted op Kubernetes (dêr al of yn 'e takomst) wurket mei:

... en wy steane foar de taak om it te migrearjen nei de nije produksje yn Kubernetes.

Earst sil de algemiene oanpak fan 'e migraasje sels beskreaun wurde, en dêrnei wurde de technyske details fan har ymplemintaasje beskreaun.

Migraasje algoritme

De earste, foarriedige, poadium foar elke aksje is om te kontrolearjen dat hege beskikberensmodus ynskeakele is yn 'e âlde RabbitMQ-ynstallaasje (HA). De reden is fanselssprekkend - wy wolle gjin gegevens ferlieze. Om dizze kontrôle út te fieren, kinne jo nei it RabbitMQ adminpaniel gean en yn it ljepblêd Admin → Belied soargje derfoar dat de wearde is ynsteld ha-mode: all:

De folgjende stap is om in nij RabbitMQ-kluster te ferheegjen yn Kubernetes-pods (yn ús gefal, bygelyks, besteande út 3 knopen, mar har oantal kin oars wêze).

Hjirnei fusearje wy de âlde en nije RabbitMQ-klusters, en krije in inkele kluster (fan 6 knopen):

It proses fan gegevenssyngronisaasje tusken de âlde en nije RabbitMQ-klusters wurdt inisjeare. Sadree't alle gegevens binne syngronisearre tusken alle knopen yn it kluster, kinne wy ​​de applikaasje wikselje om it nije kluster te brûken:

Nei dizze operaasjes is it genôch om de âlde knopen út it RabbitMQ-kluster te ferwiderjen, en de ferhuzing kin wurde beskôge as folslein:

Wy hawwe dit skema in protte kearen brûkt yn produksje. Foar ús eigen gemak hawwe wy it lykwols ymplementearre binnen in spesjalisearre systeem dat standert RMQ-konfiguraasjes ferspriedt oer meardere Kubernetes-klusters (foar dyjingen dy't nijsgjirrich binne: wy hawwe it oer addon operatoroer dêr't wy krekt koartlyn ferteld). Hjirûnder sille wy yndividuele ynstruksjes presintearje dy't elkenien kin tapasse op har ynstallaasjes om de foarstelde oplossing yn aksje te besykjen.

Litte wy it yn 'e praktyk besykje

easken

De details binne hiel ienfâldich:

1. Kubernetes kluster (minikube sil ek wurkje);
2. RabbitMQ kluster (kin ynset wurde op blank metaal, en makke as in gewoane kluster yn Kubernetes út de offisjele Helm chart).

Foar it foarbyld hjirûnder haw ik RMQ ynset nei Kubernetes en neamde it rmq-old.

Standert tarieding

1. Download it Helm-diagram en bewurkje it in bytsje:

helm fetch --untar stable/rabbitmq-ha

Foar gemak sette wy in wachtwurd yn, ErlangCookie en meitsje polityk ha-allsadat de wachtrijen standert wurde syngronisearre tusken alle knooppunten fan it RMQ-kluster:

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. Ynstallearje it diagram:

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

3. Gean nei it RabbitMQ admin paniel, meitsje in nije wachtrige en foegje ferskate berjochten ta. Se sille nedich wêze, sadat wy nei migraasje kinne soargje dat alle gegevens bewarre wurde en dat wy neat hawwe ferlern:

De testbank is klear: wy hawwe de "âlde" RabbitMQ mei gegevens dy't oerdroegen wurde moatte.

Migrearjen fan in RabbitMQ-kluster

1. Lit ús earst de nije RabbitMQ ynsette freon nammeromte mei selde ErlangCookie en wachtwurd foar de brûker. Om dit te dwaan sille wy de hjirboppe beskreaune operaasjes útfiere, en it lêste kommando foar it ynstallearjen fan RMQ feroarje nei it folgjende:

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

2. No moatte jo de nije kluster gearfoegje mei de âlde. Om dit te dwaan, gean nei elk fan 'e pods nij RabbitMQ en útfiere de kommando's:

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

Yn fariabele OLD_RMQ it adres fan ien fan 'e knopen wurdt fûn âld RMQ kluster.

Dizze kommando's sille de hjoeddeistige knooppunt stopje nij RMQ-kluster, hechtsje it oan it âlde kluster en lansearje it opnij.

3. RMQ-kluster fan 6 knopen is klear:

Jo moatte wachtsje wylst berjochten wurde syngronisearre tusken alle knopen. It is net dreech om te rieden dat de berjochtsyngronisaasjetiid hinget ôf fan 'e kapasiteit fan' e hardware wêrop it kluster wurdt ynset en fan it oantal berjochten. Yn it beskreaune senario binne d'r mar 10 fan har, sadat de gegevens fuortendaliks syngronisearre binne, mar mei in foldwaande grut oantal berjochten kin syngronisaasje oeren duorje.

Dus, de syngronisaasjestatus:

it is +5 betsjut dat berjochten al binnen binne mear op 5 knopen (útsein wat is oanjûn yn it fjild Node). Sa wie de syngronisaasje suksesfol.

4. Alles wat oerbliuwt is om it RMQ-adres yn 'e applikaasje te wikseljen nei it nije kluster (de spesifike aksjes hjir binne ôfhinklik fan' e technologystap dy't jo brûke en oare applikaasjespesifikaasjes), wêrnei't jo ôfskied nimme kinne fan 'e âlde.

Foar de lêste operaasje (dus al после de applikaasje wikselje nei in nij kluster) gean nei elke knooppunt âld cluster en fier de kommando's út:

rabbitmqctl stop_app
rabbitmqctl reset

It kluster "fergeat" oer de âlde knopen: jo kinne de âlde RMQ wiskje, op hokker punt de ferhuzing sil wurde foltôge.

remark: As jo ​​RMQ brûke mei sertifikaten, dan feroaret neat fûneminteel - it ferpleatse proses sil krekt itselde wurde útfierd.

befinings

It beskreaune skema is geskikt foar hast alle gefallen as wy RabbitMQ moatte migrearje of gewoan ferhúzje nei in nij kluster.

Yn ús gefal ûntstiene swierrichheden mar ien kear, doe't RMQ fan in protte plakken tagong waard, en wy hawwe net de mooglikheid om it RMQ-adres oeral te feroarjen nei in nij. Doe lansearren wy in nije RMQ yn deselde nammeromte mei deselde labels sadat it soe falle ûnder besteande tsjinsten en Ingresses, en by it lansearjen fan de pod hawwe wy de labels mei de hân manipulearre, se oan it begjin fuortsmiten sadat fersiken net op 'e lege RMQ, en foegje se werom neidat de berjochten binne syngronisearre.

Wy brûkten deselde strategy by it bywurkjen fan RabbitMQ nei in nije ferzje mei in feroare konfiguraasje - alles wurke as in klok.

PS

As logyske fuortsetting fan dit materiaal, meitsje wy artikels oer MongoDB (migraasje fan in hardware-tsjinner nei Kubernetes) en MySQL (hoe't wy dizze DBMS yn Kubernetes tariede). Se wurde de kommende moannen publisearre.

PPS

Lês ek op ús blog:

• «Databanken en Kubernetes (resinsje en fideorapport)";
• «K8s tips & tricks: Fersnelle bootstrap foar grutte databases".

Boarne: www.habr.com