RabbitMQ â njĂ« broker mesazhesh i shkruar nĂ« gjuhĂ«n Erlang, qĂ« mundĂ«son organizimin e njĂ« klasteri tĂ« qĂ«ndrueshĂ«m me replikim tĂ« plotĂ« tĂ« tĂ« dhĂ«nave nĂ« disa nyje, ku çdo nyje mund tĂ« shĂ«rbejĂ« kĂ«rkesat pĂ«r lexim dhe shkrim. Duke pasur nĂ« eksploatimin e production shumĂ« klasterĂ« Kubernetes, mbĂ«shtesim njĂ« numĂ«r tĂ« madh instalimesh RabbitMQ dhe jemi pĂ«rballur me nevojĂ«n pĂ«r tĂ« migruar tĂ« dhĂ«na nga njĂ« klaster nĂ« tjetĂ«r pa ndalesĂ«.
Kjo operacion ishte i nevojshëm për ne në dy raste të paktën:
- Transferimi i tĂ« dhĂ«nave nga klasteri RabbitMQ, i cili nuk Ă«shtĂ« nĂ« Kubernetes, nĂ« njĂ« tĂ« ri â tashmĂ« "kubernetizuar" (pra, qĂ« funksionon nĂ« podâĂ« K8s) â klaster.
- Migroja e RabbitMQ brenda Kubernetes nga një namespace në tjetër (për shembull, nëse konturat janë të ndara përmes hapësirave të emrave, atëherë për të transferuar infrastrukturën nga një kontur në tjetrin).
Recepti i propozuar në këtë artikull është të orientuar për situata (por aspak i kufizuar në to), ku ka një klaster të vjetër RabbitMQ (p.sh., me 3 nyje), që është tashmë në K8s, ose në disa servera të vjetër. Një aplikacion e përdor atë, të vendosur në Kubernetes (apo në perspektivë):
⊠dhe përpara nesh është detyra e migrimit të tij në një production të ri në Kubernetes.
SĂ« pari do tĂ« pĂ«rshkruhet qasja e pĂ«rgjithshme pĂ«r vetĂ« migrimin, dhe mĂ« pas â detajet teknike pĂ«r implementimin e tij.
Algoritmi i migrimit
Hapi i parĂ«, paraprak, pĂ«rpara ndonjĂ« veprime â kontrolli qĂ« nĂ« instalimin e vjetĂ«r tĂ« RabbitMQ Ă«shtĂ« aktivizuar moda e disponueshmĂ«risĂ« sĂ« lartĂ« (). Arsyja Ă«shtĂ« e qartĂ« â ne nuk duam tĂ« humbasim ndonjĂ« tĂ« dhĂ«nĂ«. PĂ«r tĂ« realizuar kĂ«tĂ« kontroll, mund tĂ« hyni nĂ« administratĂ«n e RabbitMQ dhe nĂ« seksionin Admin â Policies tĂ« siguroheni qĂ« Ă«shtĂ« vendosur vlera ha-mode: all:
Hapi tjetĂ«r â ngrisim njĂ« klaster tĂ« ri RabbitMQ nĂ« podâĂ« Kubernetes (nĂ« rastin tonĂ«, pĂ«r shembull, pĂ«rbĂ«rĂ« nga 3 nyje, por numri i tyre mund tĂ« jetĂ« edhe tjetĂ«r).
Pas kësaj, ne bashkojmë klasterin e vjetër dhe atë të ri të RabbitMQ, duke formuar një klaster të vetëm (me 6 nyje):
Iniciatet procesi i sinkronizimit të të dhënave midis klasterit të vjetër dhe atij të ri të RabbitMQ. Pas përfundimit të sinkronizimit të të gjitha të dhënave midis të gjitha nyjeve në klaster, mund ta çelim aplikacionin për të përdorur klasterin e ri:
Pas këtyre veprimeve, mjafton të heqim nga klasteri RabbitMQ nyjet e vjetra, dhe mund të konsiderohet se migroja është përfunduar:
Këtë skemë e kemi aplikuar disa herë në prodhimin tonë. Megjithatë, për lehtësinë tonë, e kemi realizuar brenda një sistemi të specializuar që shpërndan konfiguracione standarde RMQ në grupe të shumta Kubernetes. (për ata që janë kuriozë: bëhet fjalë për , për të cilin ne ). Më poshtë do të paraqiten udhëzime të veçanta, të cilat secili mund t'i zbatojë në instalimet e tij, për të provuar zgjidhjen e propozuar në veprim.
Provojmë në praktikë
KĂ«rkesat
Rrethanat janë shumë të thjeshta:
- Kluster Kubernetes (i përshtatshëm edhe për minikube);
- Klastri RabbitMQ (mund të jetë i instaluar në bare metal, ose të krijohet si një klastri normal në Kubernetes nga një helm-chart zyrtar).
Për shembullin e përshkruar më poshtë, unë kam instaluar RMQ në Kubernetes dhe e kam quajtur rmq-old.
Përgatitja e skenës
1. Do të shkarkojmë helm-chart dhe do ta redaktojmë pak:
helm fetch --untar stable/rabbitmq-ha Për lehtësi, përcaktojmë fjalëkalimin, ErlangCookie dhe krijojmë politikën ha-all, që me default të sinkronizohen radhët ndërmjet të gjithë nodëve të klastri 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. Instalo çartin:
helm install . --name rmq-old --namespace rmq-old3. Hyni në admin panelin e RabbitMQ, krijoni një radhë të re dhe shtoni disa mesazhe. Këto do të nevojiten që pas migrimit të mund të sigurohemi se të gjitha të dhënat janë ruajtur dhe nuk kemi humbur asgjë:
Skena testuese është gati: kemi "RabbitMQ të vjetër" me të dhëna që duhet të transferohen.
Migrimi i klastri RabbitMQ
1. Fillimisht, do të instalojmë një RabbitMQ të ri në tjetër hapësirën emërtuese me të njëjtat ErlangCookie dhe fjalëkalim për përdoruesin. Për këtë do të kryejmë operacionet e përshkruara më lart, duke ndryshuar komandën për instalimin e RMQ në këtë:
helm install . --name rmq-new --namespace rmq-new2. Tani kërkohet të bashkohet klasteri i ri me atë të vjetër. Për këtë, hyjmë në secilin nga pod-et të reja RabbitMQ dhe ekzekutojmë 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ë variablin OLD_RMQ është adresa e një prej nodëve të vjetra klastri RMQ.
Këto komanda do të ndalojnë nodin aktual të reja të klastri RMQ, do ta bashkojnë atë me klastri e vjetër dhe do ta rinasin.
3. Klasteri RMQ me 6 nodë është gati:
Duhet pritur derisa mesazhet të sinkronizohen midis të gjithë nodelave. Nuk është e vështirë të kuptohet se koha e sinkronizimit të mesazheve varet nga fuqia e harduerit ku është vendosur klasteri 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 nëse numri i mesazheve është mjaft i madh, sinkronizimi mund të zgjasë orë të tëra.
Pra, statusi i sinkronizimit:
Këtu +5 do të thotë se mesazhet tashmë janë përgjigjesha në 5 nodelat (përveç asaj që është e shënuar në fushën Nyja). Kështu, sinkronizimi arriti me sukses.
4. E vetmja gjë e mbetur është të kaloni në aplikacion adresën RMQ në klasterin e ri (veprimet specifike këtu varen nga stoku i teknologjisë që po përdorni dhe nga specifika tjetër e aplikacionit), pas të cilit mund të despedoni nga i vjetri.
Për operacionin e fundit (dmth, tashmë pas kalimi i aplikacionit në klasterin e ri), shkojmë në secilën nodë të vjetra të klasterit dhe ekzekutojmë komandat:
rabbitmqctl stop_app
rabbitmqctl resetKlasteri "e harroi" për nodelat e vjetra: mund të fshijmë RMQ-në e vjetër, duke e përfunduar kështu migrimin.
ShĂ«nim: NĂ«se po pĂ«rdorni RMQ me certifikata, atĂ«herĂ« principi Ă«shtĂ« nĂ« fakt i njĂ«jtĂ« â procesi i migrimit do tĂ« realizohet saktĂ«sisht njĂ«soj.
PĂ«rfundimet
Skema e përshkruar është e përshtatshme praktikisht për të gjitha rastet kur na nevojitet të transferojmë RabbitMQ ose thjesht të migriojmë në një klaster të ri.
Në rastin tonë, vështirësitë ndodhën vetëm një herë, kur RMQ ishte shqyrtuar nga shumë vende, dhe ne nuk kishim mundësi të ndryshonim adresën RMQ në të gjithë. Atëherë ne e dëgjonim RMQ-në e re në të njëjtin emër me etiketat e njëjta, për të rënë nën shërbimet dhe Ingress-ët ekzistues, dhe gjatë nisjes së pod-it manipuluam etiketat me duar, duke i hequr ato fillimisht që kërkesat të mos shkonin në RMQ-në bosh, dhe duke i shtuar përsëri pas sinkronizimit të mesazheve.
TĂ« njĂ«jtĂ«n strategji e kemi pĂ«rdorur edhe nĂ« pĂ«rmirĂ«simin e RabbitMQ nĂ« njĂ« version tĂ« ri me konfigurim tĂ« ndryshuar â gjithçka funksionoi siç pritej.
P.S.
Si një vazhdim logjik i këtij materiali, ne po përgatisim artikuj për MongoDB (migrimi nga serveri në harduer 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
