7.3 Включение/выключение оборудования платформы

Ниже изложен порядок запуска в эксплуатацию всех объектов ОИ, включенных в отказоустойчивый кластер.

Исходное состояние – полностью отключенное оборудование на площадке, регламентируемое понятием «технологического перерыва».

Главная задача – произвести корректное включение оборудования и запуск сервисов платформы виртуализации (ОП TIONIX) после проведения планово-профилактических (сервисных) работ, связанных с ремонтом/заменой оборудования или временного выхода инфраструктуры из строя (пропадание электропитания и т.п.).

После включения оборудования следует произвести экспресс-проверку состояния служб (Самодиагностика платформы).

Внимание.

Включение оборудования инфраструктуры (аппаратных средств) следует выполнять в соответствии с инструкциями по эксплуатации от производителя оборудования.

7.3.1 Включение оборудования (запуск компонентов инфраструктуры)

Процедуру включения оборудования производить в следующем порядке:

  • в первую очередь, произведите включение вычислительных узлов (далее ВУ);
  • в последнюю очередь, произвести включение устройств управления (далее УУ).

Примечание.

После загрузки операционных систем происходит инициализация служб ОП. На запуск и инициализацию требуется некоторое время.

7.3.1.1 Проверка состояния технологических сервисов

Подключитесь к консоли контроллера под учетной записью root и проверьте состояние ресурсов отказоустойчивого кластера (PCS). Выполните команду:

# pcs status

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

Cluster name osc
Stack: corosync
Current DC: control3 (version 1.1.18-11.res7c.2-2b07d5c5a9) - partition with quorum
Last updated: Tue Nov  3 12:00:51 2020
Last change: Wed Oct 21 20:11:01 2020 by root via crm_resource on control2

3 nodes configured
41 resources configured

Online: [ control1 control2 control3 ]

Full list of resources:

Master/Slave Set: p_galera-master [p_galera]
        Masters: [ control1 control2 control3 ]
p_haproxy  (systemd:haproxy):  Started control3
Master/Slave Set: p_redis-master [p_redis]
        Masters: [ control1 ]
        Slaves: [ control2 control3 ]
Clone Set: p_memcached-clone [p_memcached]
        Started: [ control1 control2 control3 ]
Resource Group: vip
        mgmt_vip   (ocf::heartbeat:IPaddr2):   Started control3
        public_vip (ocf::heartbeat:IPaddr2):   Started control3
        internal_vip   (ocf::heartbeat:IPaddr2):   Started control3
Clone Set: openstack-cinder-api-clone [openstack-cinder-api]
        Started: [ control1 control2 control3 ]
Clone Set: openstack-cinder-scheduler-clone [openstack-cinder-scheduler]
        Started: [ control1 control2 control3 ]
openstack-cinder-volume    (systemd:openstack-cinder-volume):  Started control1
Clone Set: nova-placement-api-clone [nova-placement-api]
        Started: [ control1 control2 control3 ]
Clone Set: openstack-nova-api.service-clone [openstack-nova-api.service]
        Started: [ control1 control2 control3 ]
Clone Set: openstack-nova-conductor.service-clone [openstack-nova-conductor.service]
        Started: [ control1 control2 control3 ]
Clone Set: openstack-nova-scheduler.service-clone [openstack-nova-scheduler.service]
        Started: [ control1 control2 control3 ]
Clone Set: neutron-server-clone [neutron-server]
        Started: [ control1 control2 control3 ]
Clone Set: openstack-glance-api-clone [openstack-glance-api]
        Started: [ control1 control2 control3 ]
Clone Set: openstack-glance-registry-clone [openstack-glance registry]
        Started: [ control1 control2 control3 ]

Daemon Status:
        corosync: active/enabled
        pacemaker: active/enabled
        pcsd: active/enabled

Обратите внимание на строку Online – полный список управляющих узлов:

[ control1 control2 control3 ]

ВАЖНО.

Обратить внимание на запущенные экземпляры ресурсов в соответствии с их моделями кластеризации.

Проверьте состояние кластера Galera, выполнив команду:

# mysql -p -e "SHOW STATUS LIKE'wsrep_cluster_size';"

Enter password:

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

Значение параметра „wsrep_cluster_size“ показывает количество активных засинхронизированных узлов кластера.

Примечание.

Дополнительная информация о состоянии кластера Galera (синхронизации) может быть получена с помощью команды clustercheck (Раздел 7.4.5.2).

Проверьте состояние кластера очередей сообщений RabbitMQ. Выполните команду:

# rabbitmqctl cluster_status

Убедитесь, что все узлы кластера запущены (Раздел 7.4.5.3).

На всем оборудовании платформы виртуализации проверьте наличие синхронизации системного времени (Раздел 7.4.2). Выполните команду:

# chronyc sources

Пример правильного вывода команды:

210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 10.0.210.126                  7   7   377   119    -13ms[  -14ms] +/-   31ms

Наличие символа «*» в выводе команды означает состояние синхронизации от соответствующего источника.

7.3.1.2 Проверка состояния служб системы виртуализации

Из консоли контроллера загрузите профиль переменных пользователя admin. Выполните команду:

# . admin-openrc.sh

Произведите контроль состояния сервисов службы вычислений Nova (Раздел 7.4.6.2). Выполните команду:

# openstack compute service list

Произведите контроль состояния агентов сетевой службы Neutron:

# openstack network agent list

Произведите проверку состояния службы блочных устройств Cinder. Выполните команду:

# openstack volume service list

Пример правильного вывода команды:

+------------------+-------------------------------------------+------+---------+-------+----------------------------+
| Binary           | Host                                      | Zone | Status  | State | Updated At                 |
+------------------+-------------------------------------------+------+---------+-------+----------------------------+
| cinder-scheduler | internal.tionix.loc                       | nova | enabled | down  | 2020-10-20T07:18:43.000000 |
| cinder-volume    | internal.tionix.loc@huawei_backend        | nova | enabled | up    | 2020-11-03T09:39:57.000000 |
| cinder-volume    | internal.tionix.loc@huawei_backend_glance | nova | enabled | up    | 2020-11-03T09:39:56.000000 |
| cinder-scheduler | control2.tionix.loc                       | nova | enabled | up    | 2020-11-03T09:39:57.000000 |
| cinder-scheduler | control3.tionix.loc                       | nova | enabled | up    | 2020-11-03T09:40:02.000000 |
| cinder-scheduler | control1.tionix.loc                       | nova | enabled | up    | 2020-11-03T09:39:57.000000 |
+------------------+-------------------------------------------+------+---------+-------+----------------------------+

7.3.2 Самодиагностика платформы

Выполните вход в графический интерфейс управления платформой виртуализации с правами администратора. Перейдите

ТИОНИКС >> Обзор

и кликните кнопку [Запустить самодиагностику].

Кнопка управления [Скачать отчет самодиагностики] станет неактивной до окончания процесса. Необходимо дождаться окончания (кнопка станет активной).

Далее – кликнуть кнопку [Скачать отчет самодиагностики] и выбрать – либо сохранение отчета в виде файла, либо загрузку отчета в текстовый редактор.

Проанализируйте отчет о самодиагностике платформы (модулей TIONIX).

7.3.3 Выключение ОП (с корректным завершением работы служб)

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

Для отключения виртуальных машин может быть использован механизм планирования задач – служба планировщика (модуль TIONIX.Scheduler), обеспечивающая выполнение административных действий в заданное время. Планирование отключения ВМ позволит равномерно распределить нагрузку на подсистемы виртуализации и хранения, так как планировщик использует очередь.

Примечание.

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

Внимание.

После выполнения операций по завершению работы ВМ рекомендуется выполнить контрольную проверку ВУ, прежде чем производить отключение УУ. Это можно сделать с помощью интерфейса управления (TIONIX.Dashboard).

7.3.3.1 Завершение работы виртуальных машин

Внимание.

Если выключаемая ВМ используется в инфраструктуре VDI, то желательно корректно завершить работу (бизнес-) приложений гостевой ОС.

Выполните вход в интерфейс управления с правами администратора (роль - admin). Перейдите:

Проект >> Администратор >> Вычисления >> Виртуальные машины

Отметьте (галочкой) чек-бокс «Все ВМ».

Из контекстного меню «Еще действия» выберите – «Выключить машину».

7.3.3.2 Завершение работы средств вычислительной техники

По завершении процесса отключения виртуальных машин необходимо последовательно выполнить удаленное подключение ко всем узлам платформы (сначала – ВУ, затем – УУ) и, команду отключения poweroff (с полномочиями суперпользователя).

Процедуру выключения СВТ необходимо производить в следующем порядке:

  • первыми выключать ВУ, один за другим (согласно пула IP-адресов);
  • в последнюю очередь произвести выключение УУ.

Для того, чтобы сократить количество операций ввода команд, рекомендуется выполнять безопасное подключение с указанием команды выключения, которая должна быть выполнена на удаленной ноде:

ssh tionix@copmute1 -c "poweroff"

ssh tionix@copmute2 -c "poweroff"

и т.д.