Операции с управляющими узлами

Не все управляющие узлы полностью равнозначны. Один из управляющих узлов содержит в себе мастер-ноды кластеров СУБД Tarantool (Breeze, Dusk), которые используются другими компонентами Платформы (например, IAM). Все остальные управляющие узлы содержат реплики этих кластеров (доступные только для чтения).

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

 
$ ls /etc/tarantool/instances.available

Для определения того, является ли управляющий узел Главным управляющим узлом, достаточно подключиться к одному из инстансов Tarantool командой tarantoolctl enter <ИМЯ_ИНСТАНСА> и проверить значение параметра read_only из box.cfg при помощи команды box.info.ro.

 
$ sudo bash# tarantoolctl enter breeze_01# box.info.ro

Возможные результаты:

• true — текущий узел является обычным управляющим узлом с репликой Tarantool.
• false — текущий узел является Главным управляющим узлом с мастером Tarantool.

 
~> tarantoolctl enter breeze_01connected to unix/:/var/run/tarantool/breeze_01.controlunix/:/var/run/tarantool/breeze_01.control> box.info.ro---- false...

Для обслуживания управляющего узла предусмотрен механизм его временного отключения из кластера.

Чтобы вывести управляющий узел из кластера:

1. В Портале мониторинга установите период технического обслуживания (Maintenance periods) для отключаемого вычислительного узла:

   1. Перейдите в раздел Configuration → Maintenance.

   2. В верхнем правом углу нажмите кнопку Create maintenance period.

   3. Задайте параметры:

      • Name — название периода. Обязательное поле.

      • Maintenance type — тип периода:

        • With data collection — со сбором данных.
        • No data collection — без сбора данных.

      • Active since — начало активности периода технического обслуживания. Обязательное поле.

      • Active till — конец активности периода технического обслуживания. Обязательное поле.

      • Periods — нажмите на ссылку Add в таблице Periods. В открывшемся модальном окне укажите периодичность и продолжительность периода технического обслуживания и нажмите кнопку Add.
      • Host groups — группы хостов. Нажмите кнопку Select справа от названия, выберите пункты списка и нажмите кнопку Select. Выберите из списка вычислительный узел, который необходимо вывести из кластера.
      • Hosts — хосты. Нажмите кнопку Select справа от названия, выберите пункты списка и нажмите кнопку Select.
      • Tags — поиск по тегам.

   4. Нажмите кнопку Add в нижней части вкладки. На странице Maintenance periods появится новая запись.

2. Перейдите на отключаемый управляющий узел по SSH.

3. Проверьте состояние таймеров биллинга и сервисов, которые они запускают:

    
   $ systemctl list-timers --all scrooge-charger.timer scrooge-billing.timer$ systemctl list-units --all scrooge-charger.service scrooge-billing.service

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

4. Выполните команду остановки сервера:

 
$ shutdown now

После выведения из кластера управляющий узел можно отключить от сети, отключить питание и выполнить работы по ремонту/модернизации.

Чтобы включить управляющий узел:

1. Убедитесь, что управляющий узел физически включен и выполнен автоматический запуск сервисов.

2. Перейдите на включенный управляющий узел по SSH.

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

    
   $ systemctl list-units --all --type=service

4. Если сервисы из списка выше не запустились автоматически, выполните их перезапуск вручную.

5. При включении узла cpn001 проверьте работу сервиса биллинга, выполнив команду:

    
   $ systemctl | grep scrooge

   Убедитесь, что сервисы находятся в статусах active и running. Для таймеров допускается статус waiting.

6. Переключитесь на пользователя root, выполнив команду sudo bash.

7. Проверьте наличие запущенных Docker-контейнеров, выполнив команды:

    
   $ docker ps | grep gb_tarantool$ docker ps | grep rabbit_persistent

8. Запустите неработающие контейнеры, выполнив команды:

    
   $ docker start gb_tarantool$ docker start rabbit_persistent

9. Выполните подготовительные операции (подробнее — в разделе Вход для Администратора Платформы).

10. Проверьте состояние нод и сервисов Kubernetes:

     
    # kubectl get nodes# kubectl get pods -A | grep 0/

    Все ноды должны находиться в статусе Ready.

11. Проверьте состояние агентов Neutron:

     
    # openstack network agent list

    Агенты должны находиться в состоянии Alive — True, State — UP.

12. Проверьте состояние сервисов Nova:

     
    # openstack compute service list

    Сервисы должны находиться в статусе enabled, up.

Сервисы OpenStack для хранения информации используют БД MySQL, которые располагаются на управляющих узлах (контроллерах).

Отдельные серверы БД предоставляются для каждого сервиса и объединяются в единый кластер Galera.

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

 
$ ansible-playbook -i vkcloud.yml \   -e env=stage_name \   ./playbooks/galera.yml

Чтобы восстановить кластер Galera, запустите плейбук для роли galera с тегом recovery и передайте переменную galera_recovery_group с именем группы для кластера.

 
$ ansible-playbook -i vkcloud.yml\   -e env=vkcloud \   -e galera_recovery_group=vkcloud_galera_nova \   -t recovery \   ../ansible-openstack/playbooks/galera.yml

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

• Вручную создайте каталог для резервного копирования на нужном узле или узлах, по умолчанию это каталог /srv/backup (в дальнейшем указывается в переменной xtrabackup_dir). Запустите плейбук для роли galera как описано в разделе Управление кластерами БД.
• В файле inventory установите переменную galera_create_backup_script_dir: True для нужного хоста.

Восстановление БД имеет смысл выполнять, только когда нет других вариантов.

Чтобы восстановить БД из резервной копии, запустите плейбук для роли galera со следующими переменными:

 
$ ansible-playbook -i vkcloud.yml \   -e env=vkcloud \   -e db_restore_name=nova \   -e xtrabackup_dir="/srv/backup" \   -e db_backup_file_time=20220816_1428 \   -e galera_recovery_group=vkcloud_galera_nova \   -t recovery \   ../ansible-openstack/playbooks/galera.yml

Чтобы восстановление прошло без ошибок, должны быть выполнены условия:

• Резервная копия БД должна быть создана скриптом /srv/backup/backup_xtra_<db_name>.sh.
• Файл с резервной копией должен быть хотя бы на одном из узлов с БД.
• В команде восстановления БД все переменные должны быть обязательно заданы, кроме xtrabackup_dir (по умолчанию берется из файла inventory).

При восстановлении БД будут созданы временные ресурсы:

• Файл резервной копии будет скопирован на деплой-ноду в /tmp и в дальнейшем автоматически удален.
• Файл резервной копии будет скопирован на ноду, выбранную в качестве bootstrap-ноды для кластера, и не будет удален.
• Будет разархивирован каталог <xtrabackup_dir>/extrabackup_<db_restore_name> и не будет удален.

Логика по восстановлению кластера определена в файле roles/galera/tasks/dbrecovery.yml.