RabbitMQ estas mesaĝmakleristo skribita en Erlang, kiu ebligas al vi organizi malsukcesan grapolon kun plena reproduktado de datumoj tra pluraj nodoj, kie ĉiu nodo povas servi legi kaj skribi petojn. Havante multajn Kubernetes-aretojn en produktadoperacio, ni subtenas grandan nombron da RabbitMQ-instalaĵoj kaj estis alfrontitaj kun la bezono migri datumojn de unu areto al alia sen malfunkcio.
Ni bezonis ĉi tiun operacion en almenaŭ du kazoj:
- Transdonante datumojn de RabbitMQ-areto, kiu ne situas en Kubernetes, al nova - jam "kubernetigita" (t.e. funkcianta en K8s-podoj) - areto.
- Migrado de RabbitMQ ene de Kubernetes de unu nomspaco al alia (ekzemple, se cirkvitoj estas limigitaj per nomspacoj, tiam transdoni infrastrukturon de unu cirkvito al alia).
La recepto proponita en la artikolo fokusiĝas al situacioj (sed tute ne limiĝas al ili) en kiuj ekzistas malnova RabbitMQ-areo (ekzemple de 3 nodoj), situanta aŭ jam en K8s aŭ sur iuj malnovaj serviloj. Apliko gastigita ĉe Kubernetes (jam tie aŭ estonte) funkcias kun ĝi:
... kaj ni alfrontas la taskon migri ĝin al la nova produktado en Kubernetes.
Unue, la ĝenerala aliro al la migrado mem estos priskribita, kaj post tio la teknikaj detaloj de ĝia efektivigo estos priskribitaj.
Algoritmo de migrado
La unua, prepara etapo antaŭ iu ajn ago estas kontroli, ke alta havebleca reĝimo estas ebligita en la malnova instalado de RabbitMQ (). La kialo estas evidenta - ni ne volas perdi ajnajn datumojn. Por fari ĉi tiun kontrolon, vi povas iri al la administra panelo de RabbitMQ kaj en la langeto Administranto → Politikoj certigu, ke la valoro estas agordita. ha-mode: all:
La sekva paŝo estas levi novan RabbitMQ-areton en Kubernetes-podoj (en nia kazo, ekzemple, konsistanta el 3 nodoj, sed ilia nombro povas esti malsama).
Post ĉi tio, ni kunfandas la malnovajn kaj novajn RabbitMQ-aretojn, akirante ununuran areton (el 6 nodoj):
La procezo de datumsinkronigado inter la malnovaj kaj novaj RabbitMQ-aretoj estas komencita. Post kiam ĉiuj datumoj estas sinkronigitaj inter ĉiuj nodoj en la areto, ni povas ŝanĝi la aplikaĵon por uzi la novan areton:
Post ĉi tiuj operacioj, sufiĉas forigi la malnovajn nodojn de la RabbitMQ-areto, kaj la movo povas esti konsiderata kompleta:
Ni uzis ĉi tiun skemon multajn fojojn en produktado. Tamen, por nia propra komforto, ni efektivigis ĝin ene de specialeca sistemo kiu distribuas normajn RMQ-agordojn tra pluraj Kubernetes-aretoj. (por scivolemuloj: ni parolas pri pri kiu ni ). Malsupre ni prezentos individuajn instrukciojn, kiujn ĉiu povas apliki sur siaj instalaĵoj por provi la proponitan solvon en ago.
Ni provu ĝin praktike
postuloj
La detaloj estas tre simplaj:
- Kubernetes-grupo (ankaŭ minikube funkcios);
- RabbitMQ-areto (povas esti deplojita sur nuda metalo, kaj farita kiel regula areto en Kubernetes de la oficiala Helm-diagramo).
Por la suba ekzemplo, mi deplojis RMQ al Kubernetes kaj vokis ĝin rmq-old.
Standpreparo
1. Elŝutu la Helm-diagramon kaj redaktu ĝin iomete:
helm fetch --untar stable/rabbitmq-ha
Por komforto, ni starigas pasvorton, ErlangCookie kaj fari politikon ha-alltiel ke defaŭlte la atendovicoj estas sinkronigitaj inter ĉiuj nodoj de la RMQ-areto:
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. Instalu la diagramon:
helm install . --name rmq-old --namespace rmq-old3. Iru al la administra panelo de RabbitMQ, kreu novan voston kaj aldonu plurajn mesaĝojn. Ili estos bezonataj por ke post migrado ni povu certigi, ke ĉiuj datumoj estas konservitaj kaj ni nenion perdis:
La testbenko estas preta: ni havas la "malnovan" RabbitMQ kun datumoj, kiuj devas esti translokigitaj.
Migrado RabbitMQ-areto
1. Unue, ni deplojigu la novan RabbitMQ enen amiko nomspaco kun sama ErlangCookie kaj pasvorto por la uzanto. Por fari tion, ni faros la supre priskribitajn operaciojn, ŝanĝante la finan komandon por instali RMQ al la jena:
helm install . --name rmq-new --namespace rmq-new2. Nun vi devas kunfandi la novan areton kun la malnova. Por fari tion, iru al ĉiu el la guŝoj novaj RabbitMQ kaj plenumu la komandojn:
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
En variablo OLD_RMQ la adreso de unu el la nodoj estas trovita malnova RMQ-areto.
Ĉi tiuj komandoj haltigos la nunan nodon novaj RMQ-grupo, aligu ĝin al la malnova areto kaj lanĉu ĝin denove.
3. RMQ-grupo de 6 nodoj estas preta:
Vi devas atendi dum mesaĝoj estas sinkronigitaj inter ĉiuj nodoj. Ne estas malfacile konjekti, ke la mesaĝsinkroniga tempo dependas de la kapablo de la aparataro sur kiu la areto estas deplojita kaj de la nombro da mesaĝoj. En la priskribita scenaro, estas nur 10 el ili, do la datumoj estis tuj sinkronigitaj, sed kun sufiĉe granda nombro da mesaĝoj, sinkronigado povas daŭri horojn.
Do, la sinkroniga stato:
estas +5 signifas mesaĝojn jam enen pli sur 5 nodoj (krom tio, kio estas indikita en la kampo Node). Tiel, la sinkronigo estis sukcesa.
4. Restas nur ŝanĝi la RMQ-adreson en la aplikaĵo al la nova areto (la specifaj agoj ĉi tie dependas de la teknologia stako, kiun vi uzas kaj aliaj specifaĵoj de la aplikaĵo), post kio vi povas adiaŭi la malnovan.
Por la lasta operacio (t.e. jam после ŝanĝante la aplikaĵon al nova areto) iru al ĉiu nodo malnova cluster kaj ekzekuti la komandojn:
rabbitmqctl stop_app
rabbitmqctl resetLa areto "forgesis" pri la malnovaj nodoj: vi povas forigi la malnovan RMQ, ĉe kiu punkto la movo estos finita.
Примечание: Se vi uzas RMQ kun atestiloj, tiam nenio esence ŝanĝiĝas - la mova procezo efektiviĝos ĝuste same.
trovoj
La priskribita skemo taŭgas por preskaŭ ĉiuj kazoj, kiam ni bezonas migri RabbitMQ aŭ simple moviĝi al nova areto.
En nia kazo, malfacilaĵoj aperis nur unufoje, kiam RMQ estis alirita de multaj lokoj, kaj ni ne havis la ŝancon ŝanĝi la RMQ-adreson al nova ĉie. Poste ni lanĉis novan RMQ en la sama nomspaco kun la samaj etikedoj por ke ĝi falu sub ekzistantaj servoj kaj Eniroj, kaj dum lanĉo de la pod ni manipulis la etikedojn mane, forigante ilin komence por ke petoj ne falu sur la malplena RMQ, kaj aldonante ilin reen post kiam la mesaĝoj estas sinkronigitaj.
Ni uzis la saman strategion dum ĝisdatigo de RabbitMQ al nova versio kun ŝanĝita agordo - ĉio funkciis kiel horloĝo.
PS
Kiel logika daŭrigo de ĉi tiu materialo, ni preparas artikolojn pri MongoDB (migrado de aparataro servilo al Kubernetes) kaj MySQL (kiel ni preparas ĉi tiun DBMS ene de Kubernetes). Ili estos publikigitaj en la venontaj monatoj.
PPS
Legu ankaŭ en nia blogo:
- «»;
- «".
fonto: www.habr.com