🥇Migrim i qetë i RabbitMQ në Kubernetes

RabbitMQ është një ndërmjetës mesazhesh i shkruar në Erlang që ju lejon të organizoni një grup të dështimit me përsëritje të plotë të të dhënave nëpër nyje të shumta, ku secila nyje mund të shërbejë kërkesa për lexim dhe shkrim. Duke pasur shumë grupe Kubernetes në funksionimin e prodhimit, ne mbështesim një numër të madh instalimesh RabbitMQ dhe u përballëm me nevojën për të migruar të dhënat nga një grup në tjetrin pa ndërprerje.

Ne kishim nevojë për këtë operacion në të paktën dy raste:

Transferimi i të dhënave nga një grup RabbitMQ që nuk ndodhet në Kubernetes në një grup të ri - tashmë të "kubernetizuar" (d.m.th. që vepron në K8s pods) -.
Migrimi i RabbitMQ brenda Kubernetes nga një hapësirë emri në tjetrën (për shembull, nëse qarqet kufizohen me hapësira emrash, atëherë për të transferuar infrastrukturën nga një qark në tjetrin).

Receta e propozuar në artikull përqendrohet në situata (por nuk është aspak e kufizuar në to) në të cilat ekziston një grup i vjetër RabbitMQ (për shembull, prej 3 nyjesh), i vendosur ose tashmë në K8 ose në disa serverë të vjetër. Një aplikacion i pritur në Kubernetes (tashmë atje ose në të ardhmen) punon me të:

... dhe ne jemi përballur me detyrën për ta migruar atë në prodhimin e ri në Kubernetes.

Së pari, do të përshkruhet qasja e përgjithshme ndaj vetë migrimit dhe më pas do të përshkruhen detajet teknike të zbatimit të tij.

Algoritmi i migrimit

Faza e parë, paraprake, përpara çdo veprimi është të kontrolloni nëse modaliteti i disponueshmërisë së lartë është aktivizuar në instalimin e vjetër të RabbitMQ (HA). Arsyeja është e qartë - ne nuk duam të humbim asnjë të dhënë. Për të kryer këtë kontroll, mund të shkoni te paneli i administrimit të RabbitMQ dhe në skedën Admin → Politikat sigurohuni që vlera të jetë vendosur ha-mode: all:

Hapi tjetër është ngritja e një grupi të ri RabbitMQ në pods Kubernetes (në rastin tonë, për shembull, i përbërë nga 3 nyje, por numri i tyre mund të jetë i ndryshëm).

Pas kësaj, ne bashkojmë grupet e vjetra dhe të reja RabbitMQ, duke marrë një grup të vetëm (me 6 nyje):

Fillon procesi i sinkronizimit të të dhënave midis grupimeve të vjetra dhe të reja RabbitMQ. Pasi të gjitha të dhënat të sinkronizohen midis të gjitha nyjeve në grup, ne mund ta ndërrojmë aplikacionin për të përdorur grupin e ri:

Pas këtyre operacioneve, mjafton të hiqni nyjet e vjetra nga grupi RabbitMQ dhe lëvizja mund të konsiderohet e plotë:

Ne e kemi përdorur këtë skemë shumë herë në prodhim. Megjithatë, për lehtësinë tonë, ne e zbatuam atë brenda një sistemi të specializuar që shpërndan konfigurime standarde RMQ nëpër grupime të shumta Kubernetes (për ata që janë kuriozë: po flasim shtesë-operatorpër të cilat ne sapo u tha kohët e fundit). Më poshtë do të paraqesim udhëzime individuale që çdokush mund të zbatojë në instalimet e tij për të provuar zgjidhjen e propozuar në veprim.

Le ta provojmë në praktikë

Kërkesat

Detajet janë shumë të thjeshta:

Grupi Kubernetes (do të funksionojë gjithashtu minikube);
Grupi RabbitMQ (mund të vendoset në metal të zhveshur dhe të bëhet si një grup i rregullt në Kubernetes nga grafiku zyrtar i Helm).

Për shembullin më poshtë, vendosa RMQ në Kubernetes dhe e quajta atë rmq-old.

Përgatitja e qëndrimit

1. Shkarkoni grafikun Helm dhe modifikoni pak:

helm fetch --untar stable/rabbitmq-ha

Për lehtësi, ne vendosëm një fjalëkalim, ErlangCookie dhe bëni politikë ha-allnë mënyrë që si parazgjedhje radhët të sinkronizohen midis të gjitha nyjeve të grupit 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. Instaloni grafikun:

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

3. Shkoni te paneli admin RabbitMQ, krijoni një radhë të re dhe shtoni disa mesazhe. Ato do të nevojiten në mënyrë që pas migrimit të sigurohemi që të gjitha të dhënat të ruhen dhe të mos kemi humbur asgjë:

Paneli i provës është gati: ne kemi RabbitMQ "të vjetër" me të dhëna që duhen transferuar.

Migrimi i një grupi RabbitMQ

1. Së pari, le të vendosim RabbitMQ të ri në shoku hapësira e emrit me njëjtë ErlangCookie dhe fjalëkalimin për përdoruesin. Për ta bërë këtë, ne do të kryejmë operacionet e përshkruara më sipër, duke ndryshuar komandën përfundimtare për instalimin e RMQ në sa vijon:

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

2. Tani ju duhet të bashkoni grupin e ri me atë të vjetër. Për ta bërë këtë, shkoni në secilën prej bishtajave i ri RabbitMQ dhe ekzekutoni komandat:

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

Në variabël OLD_RMQ gjendet adresa e njërës prej nyjeve e vjetër grupi RMQ.

Këto komanda do të ndalojnë nyjen aktuale i ri Grup RMQ, bashkëngjitni atë në grupin e vjetër dhe lansoni përsëri.

3. Grupi RMQ me 6 nyje është gati:

Duhet të prisni derisa mesazhet të sinkronizohen midis të gjitha nyjeve. Nuk është e vështirë të merret me mend se koha e sinkronizimit të mesazheve varet nga kapaciteti i harduerit në të cilin është vendosur grupi dhe nga numri i mesazheve. Në skenarin e përshkruar, ka vetëm 10 prej tyre, kështu që të dhënat u sinkronizuan menjëherë, por me një numër mjaft të madh mesazhesh, sinkronizimi mund të zgjasë për orë të tëra.

Pra, statusi i sinkronizimit:

Këtu +5 do të thotë se mesazhet janë tashmë në më shumë në 5 nyje (përveç asaj që tregohet në fushë Node). Kështu, sinkronizimi ishte i suksesshëm.

4. Mbetet vetëm të kaloni adresën RMQ në aplikacion në grupin e ri (veprimet specifike këtu varen nga staku i teknologjisë që po përdorni dhe specifikat e tjera të aplikacionit), pas së cilës mund t'i thoni lamtumirë atij të vjetër.

Për operacionin e fundit (d.m.th. tashmë pas kalimi i aplikacionit në një grup të ri) shkoni në çdo nyje e vjetër grumbulloni dhe ekzekutoni komandat:

rabbitmqctl stop_app
rabbitmqctl reset

Grupi "harroi" nyjet e vjetra: mund të fshini RMQ-në e vjetër, në të cilën pikë lëvizja do të përfundojë.

Shënim: Nëse përdorni RMQ me certifikata, atëherë asgjë nuk ndryshon rrënjësisht - procesi i lëvizjes do të kryhet saktësisht i njëjtë.

Gjetjet

Skema e përshkruar është e përshtatshme për pothuajse të gjitha rastet kur duhet të migrojmë RabbitMQ ose thjesht të kalojmë në një grup të ri.

Në rastin tonë, vështirësitë u shfaqën vetëm një herë, kur RMQ u aksesua nga shumë vende dhe ne nuk patëm mundësinë të ndryshonim adresën RMQ në një të re kudo. Më pas lançuam një RMQ të ri në të njëjtën hapësirë emrash me të njëjtat etiketa, në mënyrë që të binte nën shërbimet ekzistuese dhe hyrjet, dhe kur nisnim podin, manipuluam etiketat me dorë, duke i hequr ato në fillim në mënyrë që kërkesat të mos binin në zbrazni RMQ dhe shtoni përsëri pasi mesazhet të sinkronizohen.

Ne përdorëm të njëjtën strategji kur përditësuam RabbitMQ në një version të ri me një konfigurim të ndryshuar - gjithçka funksionoi si një orë.

PS

Si një vazhdim logjik i këtij materiali, ne po përgatisim artikuj rreth MongoDB (migrimi nga një server hardueri në Kubernetes) dhe MySQL (si e përgatisim këtë DBMS brenda Kubernetes). Ato do të publikohen në muajt në vijim.

PPS

Lexoni edhe në blogun tonë:

Burimi: www.habr.com

Migrimi pa probleme i RabbitMQ në Kubernetes