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

Порядок проверки сервисов при 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).

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

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