Безпроблемна миграция на RabbitMQ към Kubernetes

RabbitMQ е брокер на съобщения, написан на Erlang, който ви позволява да организирате отказоустойчив клъстер с пълна репликация на данни в множество възли, където всеки възел може да обслужва заявки за четене и запис. Имайки много Kubernetes клъстери в производствена операция, ние поддържаме голям брой RabbitMQ инсталации и бяхме изправени пред необходимостта да мигрираме данни от един клъстер в друг без престой.

Имахме нужда от тази операция в поне два случая:

1. Прехвърляне на данни от RabbitMQ клъстер, който не се намира в Kubernetes, към нов – вече „kubernetized“ (т.е. работещ в K8s pods) – клъстер.
2. Миграция на RabbitMQ в рамките на Kubernetes от едно пространство на имена в друго (например, ако веригите са разделени от пространства на имена, тогава за прехвърляне на инфраструктура от една верига в друга).

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

... и ние сме изправени пред задачата да го мигрираме към новата продукция в Kubernetes.

Първо ще бъде описан общият подход към самата миграция, а след това ще бъдат описани техническите подробности за нейното изпълнение.

Алгоритъм за миграция

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

Следващата стъпка е да създадете нов RabbitMQ клъстер в Kubernetes pods (в ​​нашия случай, например, състоящ се от 3 възела, но техният брой може да е различен).

След това обединяваме старите и новите RabbitMQ клъстери, получавайки един клъстер (от 6 възела):

Стартира процесът на синхронизиране на данни между стария и новия RabbitMQ клъстер. След като всички данни се синхронизират между всички възли в клъстера, можем да превключим приложението да използва новия клъстер:

След тези операции е достатъчно да премахнете старите възли от клъстера RabbitMQ и преместването може да се счита за завършено:

Ние сме използвали тази схема много пъти в производството. Въпреки това, за наше собствено удобство, ние го внедрихме в рамките на специализирана система, която разпространява стандартни RMQ конфигурации в множество Kubernetes клъстери (за любопитните: говорим за addon-операторза които ние съвсем наскоро каза). По-долу ще представим индивидуални инструкции, които всеки може да приложи на своите инсталации, за да изпробва предложеното решение в действие.

Нека да го опитаме на практика

Изисквания

Подробностите са много прости:

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

За примера по-долу внедрих 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 с данни, които трябва да бъдат прехвърлени.

Мигриране на 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 (как подготвяме тази СУБД в Kubernetes). Те ще бъдат публикувани през следващите месеци.

PPS

Прочетете също в нашия блог:

• «Бази данни и Kubernetes (преглед и видео отчет)»;
• «K8s съвети и трикове: Ускоряване на първоначалното зареждане за големи бази данни".

Източник: www.habr.com