VK WorkSpace On-Premise logo
Помощь
Обновлена 12 ноября 2026 г. в 15:27

Как остановить и запустить Мессенджер

Назначение документа

При эксплуатации Мессенджера может понадобиться выключить серверы или ВМ, на которых расположены его сервисы, — например, для технического обслуживания или плановых работ. Перед выключением корректно остановите Мессенджер: если выключить ВМ без остановки, состояние etcd, баз данных и хранилищ может оказаться несогласованным.

В документе описано, как остановить и запустить распределённую инсталляцию Мессенджера: как переключить нагрузку на одну сторону, в каком порядке выключать и включать ВМ и как вернуть службы аварийного переключения и автофлип.

Топология кластера

Каждый узел Мессенджера принадлежит паре (шарду) и стороне — a или b. На схеме пунктиром выделены пара 1 (vkt01 и vkt02) и сторона a (vkt01, vkt03, vkt05).

Схема топологии кластера Мессенджера

Перед выключением нагрузку переключают на одну сторону, например a: узлы этой стороны выключают последними и включают первыми.

Как остановить Мессенджер

Шаг 1. Проверьте топологию кластера и мониторинг

Проблем в топологии кластера и в мониторинге быть не должно:

vkt01 # /usr/lib/check_mk_agent/local/ctlr_topo_check.sh0 ctlr_topo_check - ctlr topology is OK

Шаг 2. Переключите сервисы IPROS на сторону a

На ВМ стороны a пары 1 (vkt01) переключите сервисы каждой ВМ стороны b:

vkt01 # im_utils drain-ipros vkt02# пример успешного выводаdraining IPROS services from host | host:vkt02draining IPROS services from node vkt02found mains on vkt02: boss-4, cox-1, gbld-st-1flip to boss.vkt01.a-01-4flip to cox.vkt01.cox-1flip to gbld-st.vkt01.gbld-st-1vkt01 # im_utils drain-ipros vkt04# пример успешного выводаdraining IPROS services from host | host:vkt04draining IPROS services from node vkt04found mains on vkt04: boss-13flip to boss.vkt03.a-02-5vkt01 # im_utils drain-ipros vkt06# пример успешного выводаdraining IPROS services from host | host:vkt06draining IPROS services from node vkt06found mains on vkt06: ...

Шаг 3. Переключите оркестратор MySQL и кластер polls

На ВМ стороны a пары 2 (vkt03) переключите оркестратор MySQL и кластер polls:

vkt03 # im_utils drain-orch vkt04# пример успешного выводаdraining orch services from host | host:vkt04orchestrator sanity check OKmaster keycloak-mysql-…-0.mysql.keycloak:3306 is on vkt04, performing takeoversuccessfully initiated takeover to keycloak-mysql-…-1.mysql.keycloak:3306master store-mysql-…-0.mysql.store:3306 is on vkt04, performing takeoversuccessfully initiated takeover to store-mysql-…-1.mysql.store:3306orchestrator topology changed, waiting for 2 minutesperforming new sanity checkorchestrator sanity check OKvkt03 # im_utils drain-vshard vkt04# пример успешного выводаdraining vshard services from host | host:vkt04vshard switchover successful

Команда drain-orch ждёт смены топологии оркестратора около 2 минут — это нормальное поведение.

Убедитесь, что топология MySQL в порядке. Если вывод отличается от штатного, устраните проблемы по инструкции «У сервиса типа MySQL проблемы с топологией кластера»:

vkt03 # /usr/local/bin/orch_topo.sh# штатный вывод для кластера filesfiles-mysql-…-0.mysql.files:3306 (files-mysql-…-0)   [0s,ok,8.0.27-18,rw,ROW,>>,GTID]+ files-mysql-…-1.mysql.files:3306 (files-mysql-…-1) [0s,ok,8.0.27-18,ro,ROW,>>,GTID]

Кластеры keycloak и store выводятся так же: основная реплика (rw) находится на стороне a (vkt03), реплика (ro) — на стороне b (vkt04).

Шаг 4. Остановите службы аварийного переключения кластера polls

На ВМ пары 2 (vkt03 и vkt04) сначала проверьте и запомните, были ли службы запущены, — при запуске Мессенджера их нужно вернуть:

vkt03 # systemctl status polls_{failover,sentinel}vkt04 # systemctl status polls_{failover,sentinel}# остановитьvkt03 # systemctl stop polls_{failover,sentinel}vkt04 # systemctl stop polls_{failover,sentinel}# убедиться, что службы остановленыvkt03 # systemctl status polls_{failover,sentinel}vkt04 # systemctl status polls_{failover,sentinel}

Шаг 5. Переключите контроллер на сторону a и отключите автофлип

Действия зависят от того, где запущен контроллер — в Kubernetes или на хосте.

Контроллер запущен в Kubernetes.

  1. Определите текущий main контроллер. Поды ipros-ctlr-0 и ipros-ctlr-1 соответствуют сторонам a (vkt03) и b (vkt04):

    # kubectl -n vkteams get pod -o wide | grep ctlripros-ctlr-0   1/1  Running  2 (49m ago)  19h   10.32.129.166  vkt03  <none>  <none>ipros-ctlr-1   1/1  Running  2 (49m ago)  19h   10.32.129.239  vkt04  <none>  <none># kubectl -n vkteams get -o yaml ctlr ipros-ctlr | yq '.status.main'ipros-ctlr-1

    В этом примере main контроллер — ipros-ctlr-1 на стороне b.

  2. Переключите main на сторону a, независимо от того, был ли он уже на ней:

    # kubectl -n vkteams annotate ctlr ipros-ctlr vkteams/forced-main=ipros-ctlr-0 --overwritectlr.teams.vk.com/ipros-ctlr annotated# убедиться, что аннотация применилась# kubectl -n vkteams get ctlr ipros-ctlr -o yaml | yq '.metadata.annotations["vkteams/forced-main"]'ipros-ctlr-0# убедиться, что переключение произошло# kubectl -n vkteams get -o yaml ctlr ipros-ctlr | yq '.status.main'ipros-ctlr-0
  3. Отключите автофлип — в разделе spec ресурса ctlr в поле config задайте значение переменной ctlr_autoflip_enable 0:

    # kubectl -n vkteams edit ctlrs ipros-ctlr...spec:  config: |   log_level 2   ctlr_autoflip_enable 0...
  4. Убедитесь, что поды запустились, автофлип отключён и топология в порядке:

    # kubectl -n vkteams get pod -o wide | grep ctlripros-ctlr-0   1/1  Running  2 (49m ago)  19h   10.32.129.166  vkt03  <none>  <none>ipros-ctlr-1   1/1  Running  2 (49m ago)  19h   10.32.129.239  vkt04  <none>  <none># echo 'get ctlr_autoflip_enable' | nc ipros-ctlr-0.ipros-ctlr.vkteams.svc.cluster.local 40200# echo 'get ctlr_autoflip_enable' | nc ipros-ctlr-1.ipros-ctlr.vkteams.svc.cluster.local 40200vkt03 # /usr/lib/check_mk_agent/local/ctlr_topo_check.sh0 ctlr_topo_check - ctlr topology is OK

Шаг 6. Проверьте состояние кластера

Убедитесь, что в мониторинге нет проблем. Если есть проблемы с репликацией или ролями контроллера, устраните их по инструкциям «Проблемы с репликацией контроллера» и «Проблемы с ролями контроллера».

Шаг 7. Выключите ВМ

Сначала выключите ВМ стороны b (vkt02, vkt04, vkt06), затем — стороны a (vkt01, vkt03, vkt05).

Как запустить Мессенджер

Действия зависят от того, где запущен контроллер — в Kubernetes или на хосте.

Контроллер запущен в Kubernetes.

  1. Включите ВМ стороны a (vkt01, vkt03, vkt05).

  2. Включите ВМ стороны b (vkt02, vkt04, vkt06).

  3. Через 10 минут проверьте состояние кластера и мониторинг:

    vkt03 # /usr/lib/check_mk_agent/local/ctlr_topo_check.sh0 ctlr_topo_check - ctlr topology is OKvkt03 # /usr/local/bin/orch_topo.sh
  4. Включите службы аварийного переключения, если до остановки они были запущены. Перед включением убедитесь, что main контроллера и кластер polls находятся на одной стороне, — иначе переключите их на один узел. На узле с main выполните:

    vkt03 # im_deployer -init-ha -ha-master

    На узле со slave:

    vkt04 # im_deployer -init-ha -ha-replica# убедиться, что службы для polls запущеныvkt03 # systemctl status polls_{failover,sentinel}vkt04 # systemctl status polls_{failover,sentinel}

    Службы ctlr_failover и ctlr_sentinel в Kubernetes не используются — их запуск может привести к некорректной работе инсталляции.

  5. Верните автоматический выбор main контроллера:

    # kubectl -n vkteams annotate ctlr ipros-ctlr vkteams/forced-main-
  6. Включите автофлип — в разделе spec ресурса ctlr в поле config задайте значение переменной ctlr_autoflip_enable 1:

    # kubectl -n vkteams edit ctlrs ipros-ctlr...spec:  config: |   log_level 2   ctlr_autoflip_enable 1...# проверить, что изменения применились# echo 'get ctlr_autoflip_enable' | nc ipros-ctlr-0.ipros-ctlr.vkteams.svc.cluster.local 40201# echo 'get ctlr_autoflip_enable' | nc ipros-ctlr-1.ipros-ctlr.vkteams.svc.cluster.local 40201vkt03 # /usr/lib/check_mk_agent/local/ctlr_topo_check.sh0 ctlr_topo_check - ctlr topology is OK
  7. Убедитесь, что в мониторинге нет проблем.


Технический писатель: Москвина Анна

Была ли статья полезна?