Как остановить и запустить Мессенджер
При эксплуатации Мессенджера может понадобиться выключить серверы или ВМ, на которых расположены его сервисы, — например, для технического обслуживания или плановых работ. Перед выключением корректно остановите Мессенджер: если выключить ВМ без остановки, состояние etcd, баз данных и хранилищ может оказаться несогласованным.
В документе описано, как остановить и запустить распределённую инсталляцию Мессенджера: как переключить нагрузку на одну сторону, в каком порядке выключать и включать ВМ и как вернуть службы аварийного переключения и автофлип.
Каждый узел Мессенджера принадлежит паре (шарду) и стороне — a или b. На схеме пунктиром выделены пара 1 (vkt01 и vkt02) и сторона a (vkt01, vkt03, vkt05).
Перед выключением нагрузку переключают на одну сторону, например a: узлы этой стороны выключают последними и включают первыми.
Проблем в топологии кластера и в мониторинге быть не должно:
vkt01 # /usr/lib/check_mk_agent/local/ctlr_topo_check.sh0 ctlr_topo_check - ctlr topology is OK
На ВМ стороны 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: ...
На ВМ стороны 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).
На ВМ пары 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}
Действия зависят от того, где запущен контроллер — в Kubernetes или на хосте.
Контроллер запущен в Kubernetes.
-
Определите текущий 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. -
Переключите 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 -
Отключите автофлип — в разделе
specресурсаctlrв полеconfigзадайте значение переменнойctlr_autoflip_enable 0:# kubectl -n vkteams edit ctlrs ipros-ctlr...spec:config: |log_level 2ctlr_autoflip_enable 0... -
Убедитесь, что поды запустились, автофлип отключён и топология в порядке:
# 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
Убедитесь, что в мониторинге нет проблем. Если есть проблемы с репликацией или ролями контроллера, устраните их по инструкциям «Проблемы с репликацией контроллера» и «Проблемы с ролями контроллера».
Сначала выключите ВМ стороны b (vkt02, vkt04, vkt06), затем — стороны a (vkt01, vkt03, vkt05).
Действия зависят от того, где запущен контроллер — в Kubernetes или на хосте.
Контроллер запущен в Kubernetes.
-
Включите ВМ стороны a (vkt01, vkt03, vkt05).
-
Включите ВМ стороны b (vkt02, vkt04, vkt06).
-
Через 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 -
Включите службы аварийного переключения, если до остановки они были запущены. Перед включением убедитесь, что 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 не используются — их запуск может привести к некорректной работе инсталляции. -
Верните автоматический выбор main контроллера:
# kubectl -n vkteams annotate ctlr ipros-ctlr vkteams/forced-main- -
Включите автофлип — в разделе
specресурсаctlrв полеconfigзадайте значение переменнойctlr_autoflip_enable 1:# kubectl -n vkteams edit ctlrs ipros-ctlr...spec:config: |log_level 2ctlr_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 -
Убедитесь, что в мониторинге нет проблем.
Технический писатель: Москвина Анна