ProHoster > Blog > башкаруу > RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы

RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы

RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы

RabbitMQ - бул Erlang тилинде жазылган билдирүү брокери, ал сизге бир нече түйүндөрдө маалыматтарды толук репликациялоо менен иштен чыгуу кластерин уюштурууга мүмкүндүк берет, мында ар бир түйүн окуу жана жазуу сурамдарын тейлей алат. Өндүрүштө көптөгөн Kubernetes кластерлери болгондуктан, биз көп сандаган RabbitMQ орнотууларын колдойбуз жана маалыматтарды бир кластерден экинчисине токтоосуз көчүрүү зарылдыгына туш болдук.

Бизге бул операция жок дегенде эки учурда керек болчу:

  1. Кубернетеде жайгашпаган RabbitMQ кластеринен берилиштерди жаңы - мурунтан эле "кубернетизацияланган" (б.а. K8s поддондорунда иштеген) - кластерге өткөрүү.
  2. Kubernetes ичиндеги RabbitMQ бир аттар мейкиндигинен экинчисине көчүрүү (мисалы, схемалар аттар мейкиндиктери менен бөлүнгөн болсо, анда инфраструктураны бир схемадан экинчисине өткөрүү үчүн).

Макалада сунушталган рецепт K3s же кээ бир эски серверлерде жайгашкан эски RabbitMQ кластери (мисалы, 8 түйүн) бар кырдаалдарга багытталган (бирок алар менен чектелбейт). Kubernetes'те жайгаштырылган тиркеме (ал жакта же келечекте) аны менен иштейт:

RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы

... жана биздин алдыбызда аны Кубернетестеги жаңы өндүрүшкө көчүрүү милдети турат.

Биринчиден, миграциянын өзүнө болгон жалпы мамиле баяндалат, андан кийин аны ишке ашыруунун техникалык деталдары баяндалат.

Миграция алгоритми

Биринчи, алдын ала, кандайдыр бир иш-аракеттин алдындагы этап - эски RabbitMQ орнотуусунда жогорку жеткиликтүүлүк режими иштетилгенин текшерүү (HA). Себеби түшүнүктүү - биз эч кандай маалыматты жоготкубуз келбейт. Бул текшерүүнү жүргүзүү үчүн, сиз RabbitMQ администратор панелине өтүп, Admin → Саясат өтмөгүндө маани коюлганын текшериңиз ha-mode: all:

RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы

Кийинки кадам - ​​Kubernetes подкасттарында жаңы RabbitMQ кластерин көтөрүү (биздин учурда, мисалы, 3 түйүндөн турат, бирок алардын саны ар кандай болушу мүмкүн).

Андан кийин, биз эски жана жаңы RabbitMQ кластерлерин бириктирип, бир кластерди (6 түйүндөн) алабыз:

RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы

Эски жана жаңы RabbitMQ кластерлеринин ортосунда маалыматтарды синхрондоштуруу процесси башталды. Бардык маалыматтар кластердеги бардык түйүндөрдүн ортосунда синхрондоштуруудан кийин, биз жаңы кластерди колдонуу үчүн колдонмону которсок болот:

RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы

Бул операциялардан кийин, RabbitMQ кластеринен эски түйүндөрдү алып салуу жетиштүү жана кыймылды аяктады деп эсептесе болот:

RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы

Бул схеманы биз өндүрүштө көп жолу колдонгонбуз. Бирок, өзүбүзгө ыңгайлуу болушу үчүн, биз аны бир нече Kubernetes кластерлери боюнча стандарттык RMQ конфигурацияларын таратуучу адистештирилген системанын ичинде ишке ашырдык. (кызыккандар үчүн: биз айтып жатабыз addon-operatorбул жөнүндө биз жакында эле айтты). Төмөндө биз сунуш кылынган чечимди иш жүзүндө сынап көрүү үчүн ар ким өзүнүн орнотууларына колдоно ала турган жеке көрсөтмөлөрдү беребиз.

Келгиле, аны иш жүзүндө колдонуп көрөлү

талаптар

чоо-жайы абдан жөнөкөй:

  1. Kubernetes кластери (minikube да иштейт);
  2. RabbitMQ кластери (жылаңач металлга жайгаштырылышы мүмкүн жана расмий Helm диаграммасынан Kubernetesтеги кадимки кластер сыяктуу жасалышы мүмкүн).

Төмөндөгү мисал үчүн, мен RMQди Kubernetesке жайгаштырдым жана аны чакырдым rmq-old.

Стенд даярдоо

1. Helm диаграммасын жүктөп алып, аны бир аз түзөтүңүз:

helm fetch --untar stable/rabbitmq-ha

Ыңгайлуу болуу үчүн биз сырсөз койдук, ErlangCookie жана саясат жасашат ha-allОшентип, демейки боюнча кезектер бардык 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. Диаграмманы орнотуңуз:

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

3. RabbitMQ администратор панелине өтүп, жаңы кезек түзүп, бир нече билдирүүлөрдү кошуңуз. Алар миграциядан кийин бардык маалыматтар сакталып, эч нерсе жоготпогондугуна ынануу үчүн керек болот:

RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы

Сыноочу стенд даяр: бизде берилиш керек болгон "эски" RabbitMQ бар.

RabbitMQ кластерин көчүрүү

1. Биринчиден, келгиле, жаңы RabbitMQ орнотобуз другом менен аттар мейкиндиги бирдей ErlangCookie жана колдонуучу үчүн сырсөз. Бул үчүн, биз жогоруда сүрөттөлгөн операцияларды аткарып, RMQ орнотуунун акыркы буйругун төмөнкүгө өзгөртөбүз:

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

2. Эми сиз жаңы кластерди эскиси менен бириктиришиңиз керек. Бул үчүн, ар бирине барыңыз жаңы RabbitMQ жана буйруктарды аткарыңыз:

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

өзгөрмөлүү OLD_RMQ түйүндөрдүн биринин дареги табылган эски RMQ кластери.

Бул буйруктар учурдагы түйүндү токтотот жаңы RMQ кластери, аны эски кластерге тиркиңиз жана кайра ишке киргизиңиз.

3. 6 түйүндөрдүн RMQ кластери даяр:

RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы

Кабарлар бардык түйүндөр ортосунда синхрондоштурууга чейин күтүшүңүз керек. Кабарды синхрондоштуруу убактысы кластер орнотулган аппараттык камсыздоонун кубаттуулугуна жана билдирүүлөрдүн санына жараша болорун болжолдоо кыйын эмес. Сүрөттөлгөн сценарийде алардын 10у гана бар, ошондуктан маалыматтар заматта синхрондоштурулган, бирок жетиштүү сандагы билдирүүлөр менен синхрондоштуруу бир нече саатка созулушу мүмкүн.

Ошентип, синхрондоштуруу абалы:

RabbitMQнын Kubernetesке үзгүлтүксүз миграциясы

бул +5 билдирүүлөр мурунтан эле киргизилген дегенди билдирет More 5 түйүн боюнча (талаада көрсөтүлгөндөн башкасы Node). Ошентип, синхрондоштуруу ийгиликтүү болду.

4. Тиркемедеги RMQ дарегин жаңы кластерге которуу гана калды (бул жердеги конкреттүү аракеттер сиз колдонуп жаткан технология стекине жана колдонмонун башка өзгөчөлүктөрүнө жараша болот), андан кийин эскиси менен коштошсоңуз болот.

Акыркы операция үчүн (б.а. буга чейин после тиркемени жаңы кластерге которуу) ар бир түйүнгө өтүңүз эски кластер жана буйруктарды аткаруу:

rabbitmqctl stop_app
rabbitmqctl reset

Кластер эски түйүндөр жөнүндө "унутуп койду": сиз эски RMQди жок кылсаңыз болот, анда көчүрүү аяктайт.

пикир: Эгерде сиз сертификаттар менен RMQ колдонсоңуз, анда эч нерсе түп-тамырынан бери өзгөрбөйт - жылдыруу процесси дал ушундай ишке ашат.

табылгалары

Сүрөттөлгөн схема биз RabbitMQ көчүрүү же жөн гана жаңы кластерге көчүү керек болгон дээрлик бардык учурларда ылайыктуу.

Биздин учурда кыйынчылыктар бир гана жолу пайда болгон, RMQ көп жерден киргенде, бизде бардык жерде RMQ дарегин жаңысына өзгөртүүгө мүмкүнчүлүк болгон эмес. Андан кийин биз ошол эле аттар мейкиндигинде жаңы RMQди ишке киргиздик, ал учурдагы кызматтарга жана Инресстерге кирет, ал эми подключканы ишке киргизүүдө биз энбелгилерди кол менен иштетип, өтүнүчтөр мейкиндикке түшүп калбашы үчүн башында алып салдык. бош RMQ жана билдирүүлөр синхрондоштуруудан кийин аларды кайра кошуу.

Биз RabbitMQ-ну өзгөртүлгөн конфигурациялуу жаңы версияга жаңыртууда ушул эле стратегияны колдондук - баары саат сыяктуу иштеди.

PS

Бул материалдын логикалык уландысы катары, биз MongoDB (аппараттык серверден Kubernetesке өтүү) жана MySQL (бул DBMSди Kubernetes ичинде кантип даярдайбыз) жөнүндө макалаларды даярдап жатабыз. Алар жакынкы айларда жарыяланат.

PPS

Биздин блогдон дагы окуңуз:

Source: www.habr.com

Комментарий кошуу