7.5.2. Восстановление контроллера Openstack (УУ)

Внимание.

Восстановление выполняется на 100% исправном СВТ, на который установлена и настроена должным образом операционная система, в том числе – должна быть настроена конфигурация доступа репозиториям, содержащим программные пакеты, образующие ОП TIONIX необходимой версии (релиза).

Установите (из репозитория) пакеты, содержащие средства кластеризации и СУБД, OpenStack, TIONIX:

dnf install \
haproxy memcached corosync pacemaker pcs \
mariadb-galera-server mariadb-galera-common mariadb-server-galera \
mariaDB-server \
rabbitmq-server

Внимание

mariadb д.б. обязательно версии 10.5 (!)

dnf install \
openstack-keystone httpd mod_wsgi \
openstack-glance openstack-nova-api openstack-nova-conductor \
openstack-nova-scheduler openstack-nova-novncproxy \
openstack-nova-placement-api \
openstack-neutron openstack-neutron-ml2 openstack-neutron-openvswitch \
openstack-cinder openstack-dashboard
dnf install \
python-tionix_client \
python-tionix_dashboard \
python-tionix_licensing \
python-tionix_monitor \
python-tionix_node_control \
python-tionix_scheduler \
python-tionix_vdi_server

Разархивируйте из резервной копии сохраненные ранее директории, содержащие конфигурационные файлы, с соблюдением исходных путей.

Включите системные службы:

systemctl enable \
haproxy httpd memcached \
mariadb \
openstack-glance-api openstack-glance-registry \
openstack-nova-api \
openstack-nova-scheduler openstack-nova-conductor \
openstack-nova-novncproxy \
neutron-server neutron-dhcp-agent \
neutron-metadata-agent neutron-l3-agent neutron-openvswitch-agent \
openstack-cinder-api openstack-cinder-scheduler \
tionix-\*

Дальнейшие действия:

  1. Восстановите кластер управления (Раздел 7.5.2.2).
  2. Восстановите кластер Galera (Раздел 7.5.2.1).
  3. Восстановите кластер RabbitMQ (Раздел 7.5.2.3).

7.5.2.1. Восстановление кластера Galera

Примечание.

В случае одновременного отказа всех контроллеров (перезагрузка, либо иная аварийная ситуация) возможна ситуация, когда кластерные ноды Galera отказываются самостоятельно собираться в кластер. В этом случае потребуется выполнение дополнительных действий [1].

Для восстановления необходимо на всех контроллерах запустить команду:

galera_recovery

Будет выведен лог состояния кластерной ноды [2]. Среди вывода будет строка следующего формата:

WSREP: Recovered position <UUID>:1234

где

UUID – (в примере - b95919ad-3b5e-48de-a102-516345783738) будет совпадать между всеми узлами, а число после двоеточия (в примере 1234) являет номер последовательности, которую данный узел «видел» последней.

Из всех кластерных нод необходимо выбрать ту, на которой данный номер последовательности – наибольший (или же любую из нод, если он совпадает). На ней следует выполнить команду:

galera_new_cluster

Выполнение этой команды произведет корректный bootstrap – настройку конфигурации запуска нового кластера [3].

Остальные ноды необходимо стартовать стандартным для ОС Linux путем – поочередно запуская на них сервер БД:

systemctl start mariadb

Если Galera контролируем менеджером ресурсов Pacemaker, то для восстановления кластера необходимо перезапустить ресурс кластера Galera. Выполните команду:

pcs resource restart galera_resource

Внимание.

После проделанных выше действий ноды должны присоединиться к новому кластеру Galera.

Проверьте состояние кластера Galera выполнением SQL-запроса, подключившись к какому-либо узлу кластера при помощи клиента СУБД (mariadb):

mariadb -p -u root -h controller1

где

controller1 – имя хоста, обслуживающего базы данных.

В строке приглашения клиента введите и отправьте на выполнение (нажатием <Enter>) следующий SQL-запрос:

Будут выведены переменные, обслуживаемые с помощью MariaDb-плагина кластера Galera [4].

7.5.2.2. Восстановление кластера управления

При потере одного управляющего узла, прежде всего, остановите работу отказоустойчивого кластера:

pcs cluster stop --all

Удалите выведенный из эксплуатации узел из кластера:

pcs cluster node remove old_node

Примечание.

Дальнейшие действия производятся на новой ноде (new_node).

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

  1. Разархивируйте по соответствующим путям конфигурационные файлы.

  2. Задайте пароль пользователю hacluster (на новой ноде):

    passwd hacluster
    
  3. Запустите и добавьте сервис pcsd в автозапуск:

    systemctl enable --now pcsd
    или
    systemctl enable pcsd; systemctl enable pcsd
    
  4. Аутентифицируйте в кластере новый узел:

    pcs host auth new_node
    
  5. С любого действующего в рамках кластера УУ (контроллера) выполните команду:

    pcs cluster node add new_node
    
  6. На новом узле (new_node) выполните команду:

    pcs cluster enable
    

Выполните восстановление конфигурации сервисов Pacemaker (на новой ноде):

pcs config restore <openstack.tar>

На каждой из нод (УУ), включенных в кластер, выполните команду:

pcs cluster start

Проверьте статус кластера:

pcs status

7.5.2.3. Восстановление кластера RabbitMQ

Способы решения проблем в работе очереди данных (сообщений) RabbitMQ могут быть найдены в официальной документации OpenStack [5]. Дополнительная информация о кластеризованной очереди сообщений, влиянии сетевых неполадок (пропадания связи между физическими нодами) и опциях восстановления, может быть найдена в Интернет. Перейдите по ссылке:

Ниже изложена краткая инструкция по восстановлению работоспособности кластера RabbitMQ.

Разархивируйте каталоги с конфигурационными файлами в соответствующие пути. Удостоверьтесь, что файлы /var/lib/rabbitmq/.erlang.cookie, хранящиеся на узлах кластера, совпадают.

Внимание.

Переименуйте узел кластера, если имя узла отличается:

rabbitmqctl rename_cluster_node <oldnode> <newnode>

Также, следует заменить имя узла во всех конфигурационных файлах.

Запустите системную службу RabbitMQ:

systemctl start rabbitmq-server

Добавьте узел в кластер – выполните составную команду:

rabbitmqctl stop_app && \
rabbitmqctl join_cluster rabbit@имя_узла_кластера && \
rabbitmqctl start_app

Удостоверьтесь, что добавленный узел появился в кластере:

rabbitmqctl cluster_status

Сноски

[1]https://dba.stackexchange.com/questions/157500/how-to-recover-mariadb-galera-cluster-after-full-crash
[2]https://netpoint-dc.com/blog/galera-cluster-principles-deployment-with-clustercontrol/
[3]https://netpoint-dc.com/blog/mariadb-galera-3-node-cluster/
[4]https://mariadb.com/kb/en/galera-cluster-system-variables/
[5]https://docs.openstack.org/operations-guide/ops-maintenance-rabbitmq.html