Беспрекорна миграција на RabbitMQ во Kubernetes

RabbitMQ е брокер за пораки напишан во Erlang кој ви овозможува да организирате кластер за фаливер со целосна репликација на податоци низ повеќе јазли, каде што секој јазол може да опслужува барања за читање и запишување. Имајќи многу Kubernetes кластери во производствена операција, поддржуваме голем број на RabbitMQ инсталации и се соочивме со потребата да мигрираме податоци од еден кластер во друг без прекини.

Оваа операција ни требаше во најмалку два случаи:

1. Пренесување податоци од кластер RabbitMQ што не е лоциран во Kubernetes во нов - веќе „кубернетизиран“ (т.е. работи во K8s pods) - кластер.
2. Миграција на RabbitMQ во Kubernetes од еден именски простор во друг (на пример, ако колата се ограничени со именски простори, потоа за пренос на инфраструктура од едно коло во друго).

Рецептот предложен во статијата е фокусиран на ситуации (но воопшто не е ограничен на нив) во кои постои стар кластер RabbitMQ (на пример, од 3 јазли), лоциран или веќе во K8s или на некои стари сервери. Апликација хостирана на Kubernetes (веќе таму или во иднина) работи со неа:

... и ние сме соочени со задача да го префрлиме во новото производство во Кубернетес.

Прво, ќе се опише општиот пристап кон самата миграција, а потоа ќе се опишат техничките детали за нејзината имплементација.

Алгоритам за миграција

Првата, прелиминарна фаза пред било каква акција е да се провери дали режимот со висока достапност е овозможен во старата инсталација RabbitMQ (HA). Причината е очигледна - не сакаме да изгубиме никакви податоци. За да ја извршите оваа проверка, можете да отидете на административниот панел на RabbitMQ и во картичката Администратор → Политики, проверете дали вредноста е поставена ha-mode: all:

Следниот чекор е да се подигне нов RabbitMQ кластер во Kubernetes pods (во нашиот случај, на пример, кој се состои од 3 јазли, но нивниот број може да биде различен).

После ова, ги спојуваме старите и новите RabbitMQ кластери, добивајќи еден кластер (од 6 јазли):

Започнат е процесот на синхронизација на податоците помеѓу старите и новите RabbitMQ кластери. Откако сите податоци ќе се синхронизираат помеѓу сите јазли во кластерот, можеме да ја префрлиме апликацијата да го користи новиот кластер:

По овие операции, доволно е да се отстранат старите јазли од кластерот RabbitMQ и овој потег може да се смета за завршен:

Оваа шема ја користевме многу пати во производството. Сепак, за наша погодност, го имплементиравме во специјализиран систем кој дистрибуира стандардни RMQ конфигурации низ повеќе кластери Kubernetes (за оние кои се љубопитни: зборуваме за додаток-операторза кои ние неодамна кажа). Подолу ќе презентираме поединечни упатства што секој може да ги примени на своите инсталации за да го испроба предложеното решение на дело.

Ајде да се обидеме во пракса

Барања

Деталите се многу едноставни:

1. Кластерот Kubernetes (ќе работи и minikube);
2. RabbitMQ кластер (може да се распореди на гол метал и да се направи како обичен кластер во Kubernetes од официјалната табела Helm).

За примерот подолу, го распоредив RMQ на Kubernetes и го нареков rmq-old.

Подготовка на штандот

1. Преземете ја табелата на Хелм и изменете ја малку:

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 со податоци што треба да се пренесат.

Мигрирање на кластерот 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. RMQ кластерот од 6 јазли е подготвен:

Мора да почекате додека пораките се синхронизираат помеѓу сите јазли. Не е тешко да се погоди дека времето за синхронизација на пораките зависи од капацитетот на хардверот на кој е распореден кластерот и од бројот на пораки. Во опишаното сценарио, има само 10 од нив, така што податоците беа синхронизирани веднаш, но со доволно голем број пораки, синхронизацијата може да трае со часови.

Значи, статусот на синхронизација:

Тука +5 значи дека пораките се веќе вклучени повеќе на 5 јазли (освен она што е наведено во полето Node). Така, синхронизацијата беше успешна.

4. Останува само да ја префрлите RMQ адресата во апликацијата во новиот кластер (специфичните дејства овде зависат од технолошкиот стек што го користите и другите специфики на апликацијата), по што можете да се збогувате со старата.

За последната операција (т.е. веќе по префрлување на апликацијата во нов кластер) одете на секој јазол стар групирајте и извршете ги командите:

rabbitmqctl stop_app
rabbitmqctl reset

Кластерот „заборави“ на старите јазли: можете да го избришете стариот RMQ, во тој момент потегот ќе биде завршен.

Имајте на ум: Ако користите RMQ со сертификати, тогаш ништо суштински не се менува - процесот на поместување ќе се изврши токму исто.

Наоди

Опишаната шема е погодна за скоро сите случаи кога треба да мигрираме RabbitMQ или едноставно да се преселиме во нов кластер.

Во нашиот случај, тешкотиите се појавија само еднаш, кога RMQ беше пристапено од многу места и немавме можност насекаде да ја смениме адресата RMQ на нова. Потоа лансиравме нов RMQ во истиот именски простор со истите етикети за да падне под постоечките сервиси и Ingresses, а при лансирањето на pod рачно манипулиравме со етикетите, отстранувајќи ги на почетокот за да не паѓаат барањата на празен RMQ и нивно додавање откако ќе се синхронизираат пораките.

Ја користевме истата стратегија кога го ажуриравме RabbitMQ на нова верзија со изменета конфигурација - сè работеше како часовник.

PS

Како логично продолжение на овој материјал, подготвуваме статии за MongoDB (миграција од хардверски сервер во Kubernetes) и MySQL (како го подготвуваме овој DBMS внатре во Kubernetes). Тие ќе бидат објавени во наредните месеци.

PPS

Прочитајте и на нашиот блог:

• «Бази на податоци и Kubernetes (преглед и видео извештај)";
• «Совети и трикови за K8s: Забрзување на подигањето за големи бази на податоци".

Извор: www.habr.com