Аварийные ситуации, восстановление данных¶

Порядок проверки сервисов при failover¶

На узле, где был произведен failover, выполните команду:

$ docker ps -a | grep -v Up

Вывод команды должен быть либо пустым, либо содержать только пользовательские контейнеры.

Особое внимание обратите в случае присутствия контейнеров со статусом Restarting.

Проверка состояния кластера RabbitMQ¶

На управляющем узле, где был произведен failover, выполните команду:

$ docker exec -it rabbitmq rabbitmqctl cluster_status

В выводе команды должно быть три узла кластера. Все узлы должны присутствовать как в списке nodes.disc, так и в списке running_nodes.

Пример вывода команды:

$ docker exec -it rabbitmq rabbitmqctl cluster_status
warning: the VM is running with native name encoding of latin1 which may cause Elixir to malfunction as it expects utf8. Please ensure your locale is set to UTF-8 (which can be verified by running "locale" in your shell)
Cluster status of node rabbit@host1 ...
[{nodes,[{disc,['rabbit@host1','rabbit@host2',
'rabbit@host3']}]},
{running_nodes,['rabbit@host13','rabbit@host2',
'rabbit@host3']},
{cluster_name,<<"rabbit@host1">>},
{partitions,[]},
{alarms,[{'host3',[]},
{'rabbit@host2',[]},
{'rabbit@host1',[]}]}]

Зачистка RabbitMQ и перезапуск сервисов¶

Пайплайн по зачистке RabbitMQ (RMQ) и перезапуску сервисов можно применять в случаях, перечисленных далее (по мониторингу или при соответствующих проверках через CLI).

При постоянном росте на протяжении 5 минут следующих метрик:

Messages ready to be delivered to consumers;

Messages pending consumer acknowledgement;

Unroutable messages dropped;

Unacknowledged messages.

При постоянном снижении на протяжении 5 минут следующих метрик:

Total queues;

Total channels;

Total connections.

После применения пайплайна перечисленные выше метрики должны стабилизироваться.

Если вы столкнулись с описанными выше проблемами с RabbitMQ, свяжитесь со службой поддержки.

Проверка состояния кластера MariaDB¶

Для проверки состояния кластера MariaDB, выполните следующие действия:

Войдите в хранилище секретов Vault и перейдите в директорию secret_v2 / deployments / <LCM FQDN> / <имя региона> / passwords_yml.
Скопируйте пароль доступа к сервису базы данных из поля database_password.
Зайдите на переживший failover управляющий узел по SSH.

Выполните команду:

$ mysql -uroot  -p<скопированный пароль> -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"

Пример команды:

$ ssh control1
$ mysql -uroot  -pPassW0rd  -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"
wsrep_local_state_comment       Synced

Состояние узла MariaDB должно отображаться как Synced.

На этом же узле проверьте количество активных узлов в кластере MariaDB:
Пример команды:
$ mysql -uroot -pPassW0rd -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';" wsrep_cluster_size 3
В кластере Wsrep должно быть 3 активных узла.

Проверка вспомогательных компонентов мониторинга и логирования¶

Зайдите на переживший failover управляющий узел по SSH.
Выполните команду:
$ docker ps -a | egrep 'opensearch|prometheus|fluentd|grafana'
Все контейнеры должны быть в запущенном состоянии (Up).
Проверьте журналы сервисов по пути /var/log/kolla/<service.name>/*.log.

Получение списка состояний компонентов сервиса Nova в OpenStack¶

Перейдите на узел с установленным клиентом OpenStack CLI и выполните команду:

$ openstack compute service list | grep <имя узла>
где <имя узла> — имя целевого узла, пережившего failover.

Вывод должен показать состояние всех компонентов Nova на узле, пережившем failover как Up.

Пример команды:
$ openstack  compute service list | grep control1
|  3 | nova-conductor   | control1   | internal | enabled | up    | 2023-08-08T13:38:00.000000 |
| 33 | nova-scheduler   | control1   | internal | enabled | up    | 2023-08-08T13:38:03.000000 |
| 42 | nova-consoleauth | control1   | internal | enabled | up    | 2023-08-08T13:37:57.000000 |

Получите список состояний компонентов сервиса Cinder в OpenStack:
$ openstack volume service list | grep <имя узла>
где <имя узла> — имя целевого узла.

Вывод должен показать состояние всех компонентов Cinder на узле, пережившем failover как Up.

Пример команды:
$ openstack volume service list | grep control1 | cinder-scheduler | control1 | nova | enabled | up | 2023-08-08T13:38:25.000000 | | cinder-backup | control1 | nova | enabled | up | 2023-08-08T13:38:27.000000 |

Проверка журналов компонентов Neutron на наличие актуальных ошибок¶

Выполните команду:

$ ls -t /var/log/kolla/neutron/ | egrep -v 'log..' | grep neutron | xargs -l1 -I {} tail -n 200 /var/log/kolla/neutron/{} | grep -i error

Вывод данной команды должен быть пустым.

Перейдите на узел с установленным клиентом OpenStack CLI и выполните команду для получения статуса компонентов сервиса Neutron.

Пример команды:

$ openstack network agent list | grep network1
| 02480c02-1827-4007-b31a-08c4cb599826 | Metadata agent            | network1    | None              | True  | UP    | neutron-metadata-agent    |
| 67dd92dc-465e-4c28-a52d-9e76b85f66bb | Open vSwitch agent        | network1    | None              | True  | UP    | neutron-openvswitch-agent |
| a0411328-04d9-46b3-a0a2-0c4e23b8eb06 | L3 agent                  | network1    | nova              | True  | UP    | neutron-l3-agent          |
| bf2b46eb-74a5-40b6-bc40-e0e6fb035dd4 | DHCP agent                | network1    | nova              | True  | UP    | neutron-dhcp-agent        |

Failover одного управляющего узла¶

Failover — это процесс переключения на резервный узел при отказе активного узла.

На сервере, пережившем failover, проверьте журналы Keystone и MariaDB:
$ grep -P -ri '(error|trace|\=5\d{2})' /var/log/kolla/keystone/\*.log $ grep -P -ri '(error|trace|\=5\d{2})' /var/log/kolla/mariadb/\*.log
В журналах не должно быть записей 5хх, Traceback, Error.
Если ошибки 5хх, Traceback, Error встречаются только в Keystone, перезапустите контейнеры Keystone:
$ docker restart keystone

При возникновении проблем в MariaDB требуется понять и устранить причину в логах.

Failover двух управляющих узлов¶

Если управляющие узлы выключались штатно, то нужно запомнить последовательность выключения серверов и включить их в обратной последовательности с задержкой в 5 минут.

Обычно 5 минут достаточно, чтобы узлы Galera добавились в кластер и синхронизировали своё состояние.

При этом крайне желательно после загрузки сервера (в данном примере — controller1) выполнить проверку статуса MariaDB.

Пример команд:

$ ssh controller2
$ mysql -uroot  -pPassW0rd  -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"
wsrep_local_state_comment       Synced

$ ssh controller3
$ mysql -uroot  -pPassW0rd  -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"
wsrep_local_state_comment       Synced

Failover всех управляющих узлов¶

Восстановите кластер Galera:
1. Войдите в GitLab и перейдите в репозиторий региона project_k / deployments / <имя региона>.
2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
3. Укажите значение переменной KOLLA_ANSIBLE_DEPLOY_ACTION: mariadb_recovery.
4. Запустите пайплайн и дождитесь его выполнения.
5. Убедитесь, что работа сервисов восстановлена.
Перезапустите все контейнеры, кроме MariaDB и RabbitMQ.
Перезапустите контейнеры OpenStack на Compute-узлах.

Failover вычислительного узла¶

На сервере, пережившем событие failover, выполните следующие проверки:

Проверьте состояние контейнеров nova_compute на вычислительном узле командой:
$ docker ps -a | grep -i nova_compute
Убедитесь, что контейнер nova_compute находится в состоянии Up.
Проверьте лог /var/log/kolla/nova/nova-compute.log на отсутствие событий ERROR или Traceback. При их наличии убедитесь, что на вычислительном узле нет запущенных ВМ. Для этого выполните команду OpenStack CLI:
$ nova openstack server list --all --long | grep <имя Compute-узла>
Зайдите на вычислительный узел и удалите ВМ в контейнере nova_libvirt, выполнив команду:
$ docker exec nova_libvirt virsh undefine <vm_uuid>
Перейдите на узел с установленным клиентов OpenStack CLI и включите вычислительный узел командой:
$ openstack compute service set —enable <имя вычислительного узла> nova-compute

Успешное выполнение приведенного выше сценария зависит от следующих факторов:

Выход вычислительного узла из строя не связан с выходом из строя SDS (Ceph).

Образы ВМ, работавших на этом вычислительном узле, находятся в консистентном состоянии.

Образы ВМ, работавших на этом вычислительном узле, корректно эвакуировались с вычислительного узла.

Восстановление системы после аварии типа blackholing¶

Авария типа blackholing — это авария, блокирующая 5-tuple поток данных в сети между двумя элементами платформы.

В случае мультимастер-кластера MariaDB blackholing может привести к нарушению работы кластера MariaDB. Как определить:

OpenStack-API не работает. Не осуществляется создание, изменение, удаление существующих сущностей OpenStack.

Попытка записи в БД не выполняется (иногда реплика БД переходит в состояние INCONSISTENT).

Во всех компонентах OpenStack появляются записи с ошибкой подключения к БД.

В случае кластера RabbitMQ blackholing может привести к нарушению коммуникации компонентов платформы через брокер сообщений. Как определить:

Некоторые операции создания/изменения объектов OpenStack завершаются ошибкой без явных причин.

Наличие unroutable-сообщений в RabbitMQ WEB-UI и в логах /var/log/kolla/rabbitmq/rabbit@<host-name>.log.

В компонентах OpenStack появляются записи с ошибкой подключения по AMQP.

Ниже приведена последовательность шагов для восстановления системы после аварии типа blackholing для MariaDB и RabbitMQ:

Восстановление работоспособности MariaDB

Восстановление работоспособности RabbitMQ

Проверка работоспособности системы после восстановления

Важно

Ограничения и предостережения:

Пайплайны восстановления БД и сброса RabbitMQ не должны запускаться параллельно.

Повторный запуск пайплайна допускается только после анализа логов предыдущей попытки.

Перед выполнением шагов по восстановлению требуется обеспечить окно для выполнения работ, в рамках которого пользователи/администраторы платформы не будут выполнять операции по созданию/изменению/удалению объектов OpenStack.

Восстановление работоспособности MariaDB¶

Восстановление работоспособности MariaDB выполняется строго в следующей последовательности:

Запустите пайплайн восстановления БД:
1. Откройте веб-интерфейс GitLab.
2. Перейдите в репозиторий региона project_k / deployments / <имя региона>.
3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
4. В параметре KOLLA_ANSIBLE_DEPLOY_ACTION выберите значение mariadb_recovery.
5. Запустите пайплайн: New pipeline.
6. Дождитесь завершения выполнения задач на шаге setup и setup-castellan.
7. Запустите задачу deploy на шаге deploy.
8. Дождитесь завершения выполнения операции.
Выполните проверку состояния кластера MariaDB — Проверка состояния кластера MariaDB.
Проверьте отсутствие активных зависших транзакций:
1. Перейдите в Портал администратора.
2. В левом меню перейдите в раздел Мониторинг.
3. Авторизуйтесь в интерфейсе Grafana и перейдите в меню Dashboards
4. Проанализируйте данные на странице дашборда Galera/MariaDB Dashboard.
Проверьте, что API-сервисы могут устанавливать соединение с БД:
1. В левом меню портала перейдите в раздел Состояние системы.
2. Убедитесь, что все сервисы в разделе OpenStack Services находятся в статусе up.
При необходимости выполните рестарт службы ProxySQL на каждом Control-узле:
# podman restart proxysql
Рестарт нужно выполнять, если:
присутствуют частые постоянные ошибки в сервисе ProxySQL /var/log/kolla/proxysql/proxysql.log;

или в актуальных логах службы все адреса имеют статус SHUNNED;

или при обращении к API (т.е. при любых командах создания/изменения через OpenStack CLI — например: openstack volume create --size 1 <volume-name>) отображается ошибка 500.
Выполните проверку сервисов OpenStack — Получение списка состояний компонентов сервиса Nova в OpenStack; Проверка журналов компонентов Neutron на наличие актуальных ошибок.

Восстановление работоспособности RabbitMQ¶

Предупреждение

Если blackholing затронул и MariaDB, и RabbitMQ, то пайплайн сброса RabbitMQ можно будет запустить только после завершения шагов по восстановлению БД.

Восстановление работоспособности RabbitMQ выполняется строго в следующей последовательности:

Запустите пайплайн сброса RabbitMQ:
1. Откройте веб-интерфейс GitLab.
2. Перейдите в репозиторий региона project_k / deployments / <имя региона>.
3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
4. Запустите пайплайн: New pipeline.
5. Дождитесь завершения выполнения задач на шаге setup и setup-castellan.
6. Запустите задачу rabbitmq-reset. Если задачи rabbitmq-reset нет в списке, свяжитесь со службой поддержки.
7. Дождитесь завершения выполнения операции.
Выполните проверку состояния кластера RabbitMQ — Проверка состояния кластера RabbitMQ.
Выполните проверку сервисов OpenStack — Получение списка состояний компонентов сервиса Nova в OpenStack; Проверка журналов компонентов Neutron на наличие актуальных ошибок.

Проверка работоспособности системы после восстановления¶

Ожидаемый результат одинаков для обоих шагов по восстановлению системы, перечисленных выше. После выполнения шагов по восстановлению следует убедиться, что:

Control Plane возвращён в рабочее состояние.

Новые API-запросы обрабатываются корректно.

Зависшие операции не продолжают выполняться.

VM HA / DRS не инициируют неконтролируемые действия.