RabbitMQ â njĂ« broker mesazhesh i shkruar nĂ« gjuhĂ«n Erlang, qĂ« mundĂ«son organizimin e njĂ« klasteri qĂ« ka qĂ«ndrueshmĂ«ri ndaj dĂ«shtimeve me replika tĂ« plotĂ« tĂ« tĂ« dhĂ«nave nĂ« disa nyje, ku secila nyje mund tĂ« shĂ«rbejĂ« kĂ«rkesat pĂ«r lexim dhe shkwrite. Duke pasur nĂ« prodhim shumĂ« klastera Kubernetes, mbĂ«shtesim njĂ« numĂ«r tĂ« madh instalimesh RabbitMQ dhe kemi hasur nevojĂ«n pĂ«r migrimin e tĂ« dhĂ«nave nga njĂ« klaster nĂ« tjetrin pa ndalim.
Kjo operacion ishte e nevojshme për ne të paktën në dy raste:
- Transferimi i tĂ« dhĂ«nave nga njĂ« klaster RabbitMQ, qĂ« nuk ndodhet nĂ« Kubernetes, nĂ« njĂ« tĂ« ri â tashmĂ« «kubernetizuar» (dmth. qĂ« funksionon nĂ« podâ a K8s) â klaster.
- Migrimi i RabbitMQ brenda Kubernetes nga një namespace në tjetrin (për shembull, nëse kufijtë janë të ndara nga hapësirat e emrave, atëherë për të transferuar infrastrukturën nga një kufi në tjetrin).
Receta e propozuar në këtë artikull është orientuar në situata (por aspak e kufizuar në to), ku ka një klaster të vjetër RabbitMQ (për shembull, prej 3 nyjesh), që ndodhet ose tashmë në K8s, ose në ndonjë server të vjetër. Me të punon një aplikacion, i vendosur në Kubernetes (tashmë atje ose në perspektivë):
⊠dhe para nesh qëndron detyra e migrimit të tij në production të ri në Kubernetes.
Më parë do të përshkruhet qasja e përgjithshme për migrimin, dhe më pas do të vijnë detajet teknike për implementimin e saj.
Algoritmi i migrimit
Hapi i parĂ«, paraprak, para çdo veprimi â verifikimi qĂ« nĂ« instalimin e vjetĂ«r tĂ« RabbitMQ Ă«shtĂ« aktivizuar moda e disponibilitetit tĂ« lartĂ« (). Arsyeja Ă«shtĂ« e qartĂ« â ne nuk duam tĂ« humbim asnjĂ« tĂ« dhĂ«nĂ«. PĂ«r tĂ« realizuar kĂ«tĂ« verifikim, mund tĂ« hyni nĂ« panelin administrativ tĂ« RabbitMQ dhe nĂ« skedarin Admin â Policies tĂ« siguroheni qĂ« vlera e vendosur Ă«shtĂ« ha-mode: all:
Hapi tjetĂ«r â ngritja e njĂ« klasteri tĂ« ri tĂ« RabbitMQ nĂ« pod-at e Kubernetes (nĂ« rastin tonĂ«, pĂ«r shembull, duke pĂ«rfshirĂ« 3 node, por numri i tyre mund tĂ« jetĂ« ndryshe).
Pas kësaj, ne bashkojmë klasterin e vjetër dhe atë të ri të RabbitMQ, duke marrë një klaster të vetëm (nga 6 node):
Iniciuhet procesi i sinkronizimit të të dhënave midis klastereve të vjetër dhe të ri të RabbitMQ. Pas përfundimit të sinkronizimit të të gjitha të dhënave midis të gjithë node-ve në klaster, ne mund të kalojmë aplikacionin në përdorimin e klasterit të ri:
Pas këtyre operacioneve, mjafton të nxjerrim nga klasteri të vjetrit të RabbitMQ, dhe kalimi mund të konsiderohet i përfunduar:
Këtë skemë e kemi aplikuar disa herë në produkcion. Megjithatë, për komoditetin tonë, e realizuam atë brenda një sistemi të specializuar, që shpërndan konfigurime standart RMQ në shumë klasterë Kubernetes. (për ata që janë kurioz: po flasim për , për të cilin ne ). Më poshtë do të paraqiten udhëzime të veçanta që secili mund të aplikojë në instalimet e tij për të provuar zgjidhjen e propozuar në veprim.
Të provojmë në praktikë
KĂ«rkesat
Detajet janë shumë të thjeshta:
- Kluster Kubernetes (minikube është gjithashtu në rregull);
- Kluster RabbitMQ (mund të vendoset gjithashtu në bare metal, si edhe të bëhet si një kluster i zakonshëm në Kubernetes nga Helm-chart zyrtar).
Për shembullin e përshkruar më poshtë, unë kam vendosur RMQ në Kubernetes dhe e quajta rmq-old.
Përgatitja e skenës
1. Do të shkarkojmë Helm-chart dhe pak do ta redaktojmë atë:
helm fetch --untar stable/rabbitmq-ha Për lehtësim, do të caktuam fjalëkalimin, ErlangCookie dhe do të krijojmë politikën ha-all, në mënyrë që rreshtat të sinkronizohen automatikisht midis të gjitha nyjeve të klustrit 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 grafikën:
helm install . --name rmq-old --namespace rmq-old3. Hyni në panelin administrativ të RabbitMQ, krijoni një radhë të re dhe shtoni disa mesazhe. Ato do të nevojiten për të siguruar që, pas migrimit, të gjitha të dhënat të ruhen dhe asgjë të mos humbasë:
Stendi i testit është gati: kemi një RabbitMQ "të vjetër" me të dhëna që duhet të transferohen.
Migrimi i grupit të RabbitMQ
1. Fillimisht, do të vendosim një RabbitMQ të ri në një tjetër hapësirë emri me të njëjtat ErlangCookie dhe fjalëkalim për përdoruesin. Prandaj, do të kryejmë operacionet e përshkruara më sipër, duke ndryshuar komandën përfundimtare të instalimit të RMQ në këtë:
helm install . --name rmq-new --namespace rmq-new2. Tani është e nevojshme të kombinohet grupi i ri me atë të vjetër. Për të bërë këtë, hyni në secilin nga podët e reja RabbitMQ dhe kryeni 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ë variablën OLD_RMQ është adresa e njërit nga node-t e vjetër grupi RMQ.
Këto komandat do të ndalojnë nodin aktual e reja e grupit RMQ, do ta bashkojnë atë me grupin e vjetër dhe do ta fillojnë përsëri.
3. Grupe RMQ me 6 node është gati:
Duhet të prisni, derisa mesazhet të sinkronizohen midis të gjithë nyjeve. Nuk është e vështirë të kuptohet se koha e sinkronizimit të mesazheve varet nga kapacitetet e harduerit mbi të cilin është vendosur klusteri, si dhe nga numri i mesazheve. Në skenarin e përshkruar, ka vetëm 10, prandaj të dhënat u sinkronizuan menjëherë, por me një numër të mjaftueshëm 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ë ende në 5 nyje (përveç asaj që është e specifikuar në fushën Node). Kështu, sinkronizimi kaloi me sukses.
4. Vetëm duhet të ndërroni në aplikacion adresën RMQ në klusterin e ri (veprimet specifike këtu varet nga pena e teknologjisë që përdorni dhe specifika të tjera të aplikacionit), pas së cilës mund të despedoni nga i vjetri.
Për operacionin e fundit (dmth tashmë pas ndërrimin e aplikacionit në klusterin e ri) hyjmë në çdo nyjë e vjetër të klusterit dhe ekzekutojmë komandat:
rabbitmqctl stop_app
rabbitmqctl resetKlusteri «e ka harruar» nyjet e vjetra: mund të largoni RMQ-në e vjetër, duke përfunduar kështu migrimin.
ShĂ«nim: NĂ«se po pĂ«rdorni RMQ me certifikata, atĂ«herĂ« asgjĂ« nuk ndryshon thelbĂ«sisht â procesi i migrimit do tĂ« zhvillohet pikĂ«risht ashtu siç Ă«shtĂ«.
PĂ«rfundimet
Skema e përshkruar është e përshtatshme praktikisht për të gjitha rastet kur duhet të transferojmë RabbitMQ ose thjesht të kalojmë në një klaster të ri.
Në rastin tonë, vështirësitë u shfaqën vetëm një herë, kur RMQ u kërkua nga shumë vende, dhe ne nuk kishim mundësi të ndryshonim adresën e RMQ në të gjithë vendet. Atëherë ne nisëm një RMQ të ri në të njëjtin hapësirë emri me etiketat e njëjta, në mënyrë që të përfshiheshin në shërbimet dhe Ingress-at ekzistues, dhe kur nisim pod-in manualisht, manipuluam etiketat, duke i hequr ato në fillim, për të siguruar që kërkesat të mos kalonin në RMQ-në e zbrazët dhe duke i shtuar përsëri pas sinkronizimit të mesazheve.
Ne kemi aplikuar tĂ« njĂ«jtĂ«n strategji kur azhurnuam RabbitMQ nĂ« njĂ« version tĂ« ri me konfigurim tĂ« ndryshuar â gjithçka funksionoi pa probleme.
P.S.
Si një vazhdim logjik i këtij materiali, ne po përgatisim artikuj për MongoDB (migrimi nga serveri fizik në Kubernetes) dhe MySQL (si e përgatisim këtë DBMS brenda Kubernetes). Ato do të publikohen në muajt e ardhshëm.
P.P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «».
Burimi: habr.com
