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

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

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

$ docker ps -a | grep -v Up

$ podman ps -a | grep -v Up

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

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

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

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

$ docker exec -it rabbitmq rabbitmqctl cluster_status

$ podman 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',[]}]}]

$ podman 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  -p<скопированный пароль>  -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"
wsrep_local_state_comment       Synced

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

На этом же узле проверьте количество активных узлов в кластере MariaDB:
Пример команды:
$ mysql -uroot -p<скопированный пароль> -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 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 (см. Использование 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
$ podman restart keystone

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

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

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

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

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

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

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

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

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

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

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

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

Проверьте состояние контейнеров nova_compute на вычислительном узле командой:
$ docker ps -a | grep -i nova_compute
$ podman ps -a | grep -i nova_compute
Убедитесь, что контейнер nova_compute находится в состоянии Up.
Проверьте лог /var/log/kolla/nova/nova-compute.log на отсутствие событий ERROR или Traceback. При их наличии убедитесь, что на вычислительном узле нет запущенных ВМ. Для этого подключитесь к OpenStack CLI (см. Использование OpenStack CLI) и выполните команду:
# nova openstack server list --all --long | grep <имя Compute-узла>
Зайдите на вычислительный узел и удалите ВМ в контейнере nova_libvirt, выполнив команду:
$ docker exec nova_libvirt virsh undefine <vm_uuid>
$ podman exec nova_libvirt virsh undefine <vm_uuid>
Подключитесь к OpenStack CLI (см. Использование 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. При включенной ролевой модели действие выполняет пользователь с ролью admin.
2. Перейдите в репозиторий региона project_k / deployments / <имя региона>.
3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
4. Оставьте ветку по умолчанию, соответствующую установленному релизу.
5. В параметре KOLLA_ANSIBLE_DEPLOY_ACTION выберите значение mariadb_recovery.
6. Запустите пайплайн: New pipeline.
7. Дождитесь завершения выполнения задач на шаге setup.
8. Запустите задачу deploy на шаге deploy.
9. Дождитесь завершения выполнения операции.
Выполните проверку состояния кластера MariaDB — Проверка состояния кластера MariaDB.
Проверьте отсутствие активных зависших транзакций:
1. Перейдите в Портал администратора.
2. В левом меню перейдите в раздел Мониторинг.
3. Перейдите в интерфейс Grafana и откройте меню Dashboards.
4. Если ролевая модель выключена или Grafana настроена без интеграции с Порталом администратора, пройдите авторизацию в Grafana.
5. Проанализируйте данные на странице дашборда 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-reset становятся недоступны сервисы Nova и RabbitMQ, а также передача heartbeat гипервизоров. Если хост-агрегаты не переведены в режим NOOP, KeyVRM продолжает анализировать состояние региона, считает гипервизоры отказавшими и запускает фенсинг и эвакуацию размещённых на них ВМ.

Не запускайте задачу rabbitmq-reset, пока все хост-агрегаты региона не переведены в режим NOOP.

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

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

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

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

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

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

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

KeyVRM не инициирует неконтролируемые автоматические действия. При необходимости переведите затронутые хост-агрегаты в режим NOOP.