Управление общим состоянием KeyStack

Состав платформы

В состав платформы входят следующие подсистемы:

• Подсистема вычислительных ресурсов — обеспечивает виртуализацию вычислительных ресурсов и управление ими;

• Подсистема хранения данных — обеспечивает управление ресурсами хранения;

• Подсистема передачи данных — обеспечивает реализацию и управление виртуальной сетевой инфраструктурой;

• Подсистема мониторинга — обеспечивает сбор метрик с ресурсов платформы, мониторинг платформы и её сервисов;

• Подсистема оркестрации — обеспечивает возможность автоматизированного управления ресурсами виртуальной инфраструктуры платформы.

Подготовка к работе

Подключение ко всем интерфейсам управления KeyStack описано в разделе Подключение к интерфейсам управления KeyStack.

Системный администратор использует в работе следующие интерфейсы платформы:

• Портал администратора;

• OpenSearch;

• Grafana;

• Интерфейс управления NetBox;

• Портал самообслуживания (Horizon);

• OpenStack CLI.

Основным рабочим веб-интерфейсом является Портал администратора.

Помимо веб-интерфейса в работе используется OpenStack CLI.

Запуск платформы

Почти все сервисы платформы — stateless либо имеют внутренние механизмы failover, обеспечивающие достижение кворума в кластере. Но есть сервис, на который надо обратить особое внимание — Galera Cluster. Поэтому в пункте Выключение всех компонентов платформы важно делать паузы перед выключением следующего узла — это минимизирует до определенной степени шанс получить с «несобранным» кластером Galera Cluster с MariaDB после включения.

Порядок включения серверов платформы в общем случае выглядит так:

Примечание

Если вы используете docker, замените podman на docker в представленных ниже командах.

1. Включите первый управляющий узел. После загрузки сервера (в данном примере — controller1) выполните проверку статуса MariaDB.

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

   # ssh controller1
   # podman exec -it mariadb mysql -uroot  -p<пароль>  -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';"
   

   Ожидаемый вывод:

   wsrep_local_state_comment       Synced
   

   Выполните проверку того, что кластер имеет ID, не равный 0000000000:

   # podman exec -it mariadb mysql -uroot  -p<пароль>  -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_cluster_conf_id';"
   

2. Включите остальные управляющие узлы и дождитесь их загрузки. Затем проверьте статус синхронизации кластера, запустив на первом узле команду:

   # podman exec -it mariadb mysql -uroot  -p<пароль>   -s -s --execute="SHOW GLOBAL STATUS LIKE 'wsrep_local_state_comment';SHOW GLOBAL STATUS LIKE 'wsrep_cluster_weight';SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';"
   

   Ожидаемый вывод (при условии, что количество узлов — 3):

   wsrep_local_state_comment       Synced
   wsrep_cluster_weight            3
   wsrep_cluster_size              3
   

   Если в течение 5 минут статус не перейдет в Synced, проверьте журналы mariadb.log на всех запущенных узлах управления. Если вы видите в логах неуспешные попытки применить журналы предзаписи (WAL) с последующей перезагрузкой контейнера, и таких перезагрузок уже больше трех, выполните процедуру восстановления кластера по приведенным ниже шагам:

   1. Откройте веб-интерфейс GitLab.

   2. Перейдите в репозиторий региона project_k / deployments / <имя региона>.

   3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

   4. В открывшемся окне в параметре KOLLA_ANSIBLE_DEPLOY_ACTION выберете из выпадающего списка mariadb_recovery.

   5. Запустите пайплайн, нажав кнопку New pipeline.

   6. Дождитесь завершения задач на этапе setup.

   7. Запустите задачу deploy на этапе deploy и дождитесь её успешного завершения.

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

3. Выполните проверку всех узлов с помощью инструкций, приведенных в разделе Порядок проверки сервисов при failover.

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

Выключение всех компонентов платформы

Для отключения платформы и её компонентов с сохранением данных выполните следующие шаги:

1. Оповестите владельцев виртуальных машин о предстоящем отключении.

2. Выключите сервис DRS, деактивировав задание в панели администратора.

3. Выключите сервис HA, последовательно подключившись к каждому контроллеру и введя команду systemctl stop kolla-consul-container.service.

4. Зайдите на LCM-узел по SSH.

5. Зафиксируйте состояние виртуальных машин на момент выключения региона, введя команду:

   $ openstack server list --all-projects > VMs.$(date "+%Y-%m-%d-%H-%M-%S").txt
   

6. Выключите виртуальные машины средствами OpenStack, введя команду:

   $ openstack server list --all-projects -c ID -f value | \
   $ xargs -n1 openstack server stop
   

7. Проверьте выключение всех виртуальных машин командой:

   $ openstack server list --all-projects -c ID -c Status -f value | \
   $ grep -v Active
   

   Примечание

   Если проверка покажет наличие виртуальных машин в статусе ACTIVE, то повторите выключение каждой такой виртуальной машины индивидуально, введя команду openstack server stop <VM ID>, подставив в качестве VM ID значение из столбца ID предыдущего вывода.

8. Выключите узлы-гипервизоры средствами операционной системы:

   # for HOST in $(openstack hypervisor list -c "Hypervisor Hostname" -f value);\
       do \
       ssh -x ${HOST} "shutdown -h now";\
       done
   

9. Выключите узлы слоя управления (Control-узлы) средствами операционной системы, с паузами, достаточными для полного выключения сервера (время зависит от используемого аппаратного комплекса), проверяя процесс выключения и состояние серверов через IPMI:

   ssh -x ctl3 ‘shutdown -h now’
   # пауза до полного выключения
   ssh -x ctl2 ‘shutdown -h now’
   # пауза до полного выключения
   ssh -x ctl1 ‘shutdown -h now’
   # пауза до полного выключения
   

После выполнения этих шагов регион платформы будет полностью выключен.