🥇 Mudo llyfn RabbitMQ i Kubernetes

Mae RabbitMQ yn frocer negeseuon sydd wedi'i ysgrifennu yn Erlang sy'n eich galluogi i drefnu clwstwr methu drosodd gydag atgynhyrchu data llawn ar draws nodau lluosog, lle gall pob nod wasanaethu ceisiadau darllen ac ysgrifennu. Gyda llawer o glystyrau Kubernetes ar waith, rydym yn cefnogi nifer fawr o osodiadau RabbitMQ ac roeddem yn wynebu'r angen i fudo data o un clwstwr i'r llall heb amser segur.

Roedd angen y llawdriniaeth hon arnom mewn o leiaf ddau achos:

Trosglwyddo data o glwstwr RabbitMQ nad yw wedi’i leoli yn Kubernetes i glwstwr newydd – sydd eisoes yn “kubernetized” (h.y. yn gweithredu mewn codennau K8s).
Mudo RabbitMQ o fewn Kubernetes o un gofod enw i'r llall (er enghraifft, os yw cylchedau wedi'u cyfyngu gan ofodau enwau, yna i drosglwyddo seilwaith o un gylched i'r llall).

Mae'r rysáit a gynigir yn yr erthygl yn canolbwyntio ar sefyllfaoedd (ond nid yw'n gyfyngedig iddynt o gwbl) lle mae hen glwstwr RabbitMQ (er enghraifft, o 3 nod), naill ai eisoes yn K8s neu ar rai hen weinyddion. Mae cais sy'n cael ei gynnal ar Kubernetes (yn barod yno neu yn y dyfodol) yn gweithio gydag ef:

... ac rydym yn wynebu'r dasg o'i fudo i'r cynhyrchiad newydd yn Kubernetes.

Yn gyntaf, disgrifir y dull cyffredinol o ymdrin â'r mudo ei hun, ac ar ôl hynny disgrifir manylion technegol ei weithrediad.

Algorithm mudo

Y cam cyntaf, rhagarweiniol, cyn unrhyw gamau yw gwirio bod modd argaeledd uchel wedi'i alluogi yn yr hen osodiad RabbitMQ (HA). Mae'r rheswm yn amlwg - nid ydym am golli unrhyw ddata. I wneud y gwiriad hwn, gallwch fynd i banel gweinyddol RabbitMQ ac yn y tab Admin → Polisies gwnewch yn siŵr bod y gwerth wedi'i osod ha-mode: all:

Y cam nesaf yw codi clwstwr RabbitMQ newydd mewn codennau Kubernetes (yn ein hachos ni, er enghraifft, yn cynnwys 3 nod, ond gall eu nifer fod yn wahanol).

Ar ôl hyn, rydym yn uno'r clystyrau RabbitMQ hen a newydd, gan gael un clwstwr (o 6 nod):

Dechreuir ar y broses o gydamseru data rhwng yr hen glystyrau RabbitMQ a'r newydd. Unwaith y bydd yr holl ddata wedi'i gydamseru rhwng yr holl nodau yn y clwstwr, gallwn newid y cymhwysiad i ddefnyddio'r clwstwr newydd:

Ar ôl y llawdriniaethau hyn, mae'n ddigon tynnu'r hen nodau o'r clwstwr RabbitMQ, a gellir ystyried bod y symudiad yn gyflawn:

Rydym wedi defnyddio'r cynllun hwn lawer gwaith wrth gynhyrchu. Fodd bynnag, er hwylustod i ni, fe wnaethom ei weithredu o fewn system arbenigol sy'n dosbarthu cyfluniadau RMQ safonol ar draws clystyrau Kubernetes lluosog (ar gyfer y rhai sy'n chwilfrydig: yr ydym yn sôn am gweithredwr addonamdanom ni newydd ddweud yn ddiweddar). Isod byddwn yn cyflwyno cyfarwyddiadau unigol y gall unrhyw un eu cymhwyso ar eu gosodiadau i roi cynnig ar yr ateb arfaethedig ar waith.

Gadewch i ni roi cynnig arni yn ymarferol

Gofynion

Mae'r manylion yn syml iawn:

Clwstwr Kubernetes (bydd minikube hefyd yn gweithio);
Clwstwr RabbitMQ (gellir ei ddefnyddio ar fetel noeth, a'i wneud fel clwstwr rheolaidd yn Kubernetes o'r siart Helm swyddogol).

Ar gyfer yr enghraifft isod, fe wnes i ddefnyddio RMQ i Kubernetes a'i alw rmq-old.

Paratoi stondin

1. Lawrlwythwch y siart Helm a'i olygu ychydig:

helm fetch --untar stable/rabbitmq-ha

Er hwylustod, rydym yn gosod cyfrinair, ErlangCookie a gwneud gwleidyddiaeth ha-allfel bod y ciwiau yn cael eu cysoni yn ddiofyn rhwng holl nodau'r clwstwr 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. Gosodwch y siart:

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

3. Ewch i'r panel gweinyddol RabbitMQ, creu ciw newydd ac ychwanegu nifer o negeseuon. Bydd eu hangen fel y gallwn, ar ôl mudo, sicrhau bod yr holl ddata yn cael ei gadw ac nad ydym wedi colli dim:

Mae’r fainc brawf yn barod: mae gennym yr “hen” RabbitMQ gyda data y mae angen ei drosglwyddo.

Mudo clwstwr RabbitMQ

1. Yn gyntaf, gadewch i ni ddefnyddio'r RabbitMQ newydd i mewn ffrind gofod enw gyda yr un peth ErlangCookie a chyfrinair ar gyfer y defnyddiwr. I wneud hyn, byddwn yn cyflawni'r gweithrediadau a ddisgrifir uchod, gan newid y gorchymyn terfynol ar gyfer gosod RMQ i'r canlynol:

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

2. Nawr mae angen i chi uno'r clwstwr newydd gyda'r hen un. I wneud hyn, ewch i bob un o'r codennau newydd RabbitMQ a gweithredu'r gorchmynion:

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 amrywiol OLD_RMQ ceir cyfeiriad un o'r nodau hen clwstwr RMQ.

Bydd y gorchmynion hyn yn atal y nod cyfredol newydd Clwstwr RMQ, atodwch ef i'r hen glwstwr a'i lansio eto.

3. Mae clwstwr RMQ o 6 nod yn barod:

Rhaid i chi aros tra bod negeseuon yn cael eu cysoni rhwng pob nod. Nid yw'n anodd dyfalu bod yr amser cydamseru negeseuon yn dibynnu ar gynhwysedd y caledwedd y mae'r clwstwr yn cael ei ddefnyddio arno ac ar nifer y negeseuon. Yn y senario a ddisgrifiwyd, dim ond 10 ohonyn nhw sydd, felly cafodd y data ei gydamseru ar unwaith, ond gyda nifer ddigon mawr o negeseuon, gall cydamseru bara am oriau.

Felly, y statws cydamseru:

Yma +5 yn golygu bod negeseuon eisoes i mewn mwy ar 5 nod (ac eithrio'r hyn a nodir yn y maes Node). Felly, roedd y cydamseriad yn llwyddiannus.

4. Y cyfan sydd ar ôl yw newid y cyfeiriad RMQ yn y cymhwysiad i'r clwstwr newydd (mae'r camau gweithredu penodol yma'n dibynnu ar y pentwr technoleg rydych chi'n ei ddefnyddio a manylion cymwysiadau eraill), ac ar ôl hynny gallwch chi ffarwelio â'r hen un.

Ar gyfer y llawdriniaeth olaf (h.y. eisoes ar ôl newid y cymhwysiad i glwstwr newydd) ewch i bob nod hen clystyru a gweithredu'r gorchmynion:

rabbitmqctl stop_app
rabbitmqctl reset

Mae'r clwstwr yn “anghofio” am yr hen nodau: gallwch chi ddileu'r hen RMQ, ac ar yr adeg honno bydd y symudiad yn cael ei gwblhau.

Nodyn: Os ydych chi'n defnyddio RMQ gyda thystysgrifau, yna does dim byd yn newid yn sylfaenol - bydd y broses symud yn cael ei chynnal yn union yr un peth.

Canfyddiadau

Mae'r cynllun a ddisgrifiwyd yn addas ar gyfer bron pob achos pan fydd angen i ni fudo RabbitMQ neu symud i glwstwr newydd.

Yn ein hachos ni, dim ond unwaith y cododd anawsterau, pan gyrchwyd RMQ o lawer o leoedd, ac ni chawsom gyfle i newid cyfeiriad RMQ i un newydd ym mhobman. Yna fe wnaethom lansio RMQ newydd yn yr un gofod enw gyda'r un labeli fel y byddai'n dod o dan y gwasanaethau presennol ac Ingresses, ac wrth lansio'r pod fe wnaethom drin y labeli â llaw, gan eu tynnu ar y dechrau fel na fyddai ceisiadau'n disgyn ar y gwag RMQ, a'u hychwanegu yn ôl ar ôl i'r negeseuon gael eu cysoni.

Fe wnaethon ni ddefnyddio'r un strategaeth wrth ddiweddaru RabbitMQ i fersiwn newydd gyda chyfluniad wedi'i newid - roedd popeth yn gweithio fel cloc.

PS

Fel parhad rhesymegol o'r deunydd hwn, rydym yn paratoi erthyglau am MongoDB (mudo o weinydd caledwedd i Kubernetes) a MySQL (sut rydym yn paratoi'r DBMS hwn y tu mewn i Kubernetes). Byddant yn cael eu cyhoeddi yn y misoedd nesaf.

Pps

Darllenwch hefyd ar ein blog:

Ffynhonnell: hab.com

Mudo di-dor o RabbitMQ i Kubernetes