3.3 Автоматизированное развертывание

Развертывание осуществляется на ресурсах, выделенных на площадке (ЦОД), согласно плана развертывания, разработанного с учетом референсной архитектуры. Под референсной архитектурой понимается совокупность шаблонов (решений), используемых при построении облачной инфраструктуры на базе ОП TIONIX.

Внимание.

Перед выполнением операций по развертыванию (облачной платформы) необходимо убедиться, что выполнены все необходимые и достаточные подготовительные действия.

Активная фаза развертывания представляет собой автоматизированную установку OpenStack и ОП TIONIX на целевые узлы (control/compute). При этом установка ПО осуществляется с помощью Ansible и плейбуков – типовых сценариев, выполненных в формате YAML. «Проигрывание» плейбуков осуществляется для Ansible-ролей, определенных в типовой конфигурации.

Формирование отказойстойчивого кластера опирается на референсную архитектуру. Если IP-адрес VIP не определяеся службой DNS или таковая отсутствует в инфраструктуре, то необходимо добавить записи в файл /etc/hosts:

<vip_address> manage._domain_name

manage._domain_name – это одна из переменных инвентаря (VIP).

Примечание.

Обычно, в нормальном состоянии управляющего кластера, виртуальный адрес (VIP) назначен первому контроллеру – „control1: hostname: <имя_хоста>“).

Укрупненно, процесс автоматизированного развертывания ПО состоит из нескольких фаз:

  1. Установка средств управления конфигурацией и настройка окружения (Раздел 3.2.2).
На каждом узле должны быть доступны средства удаленного доступа (SSH), чтобы было возможно управление конфигурацией на основе сценариев (Ansible).
  1. Установка OpenStack и модулей TIONIX (Раздел 3.3.1).
Установка ПО OpenStack и модулей ОП TIONIX на целевые компьютеры осуществляется поверх ОС (после установки пакетов обновлений).
  1. Установка и/или настройка хранилищ(а).

На программно-определяемые устройства хранения (storage*) должна быть произведена установка или переустановка операционной системы (Раздел 3.2.1.2), с последующей настройкой на предоставление необходимых сервисов по сети.

ВНИМАНИЕ.

Если на накопителях данных управляющих или вычислительных узлов хранится какая-либо информация, то она будет удалена!

Примечания.

Для автоматизированной установки бэкэнда хранилища может быть использован отдельный плейбук (Раздел 3.3.1.3).

Если используется коммерческая реализация хранилища (SAN), то его подключение осуществляется путем настройки соответствующих служб OpenStack, в зависимости от конкретного случая.

3.3.1 Выполнение плейбуков (развертывание ОП)

Плейбуки Ansible доступны из рабочей из рабочей директории – /opt/deploy_TCP3/playbooks (условно <playbooks>). Она содержит файлы шаблона, такие как:

  • Readme.md (краткую инструкцию),
  • changeme.yml (настройка основных переменных),
  • deploy.yml (основной сценарий развертывания);
  • другие файлы типовых конфигураций объектов облачной инфраструктуры (в формате YAML).

ВАЖНО.

Выполнение плейбука развертывания требует определенной подготовленности средств управления конфигурацией и рабочей директории, созданной на первом контроллере (УУ). См. Раздел 3.2.2.

3.3.1.1 Проверка доступности (целевых) узлов

Для проверки доступности целевых узлов и корректности заполнения файла hosts.yml нужно провести проверку эхо-отклика:

ansible -m ping all

При нормальном отклике для каждого из опрашиваемых УУ/ВУ будет выведен ответ в следующем формате:

control<порядковый_номер_УУ> | SUCCESS => {
«ansible_facts»: {
«discovered_interpreter_python»: «/usr/bin/python»
},
«changed»: false,
«ping»: «pong»

3.3.1.2 Запуск сценариев

Для запуска автоматизированного развертывания спланированной облачной инфраструктуры в консоли или окне Терминала выполните команду:

ansible-playbook deploy.yml -vv

Примечания.

Опция -vv используется для расширенного логгирования [2].

Обычное время выполнения плейбука (deploy.yml) может занимать от одного до двух часов; необходимо наблюдать за выполнением плейбука и дождаться завершения процесса развертывания ПО.

В конце процедуры будет выведен сводный отчет о выполнении плейбука (Рис. 3.18). В конце отчета приводится дополнительная информация о времени [s], затраченном на выполнение промежуточных операций.

../_images/ansible-play_report.png

Рис. 3.18 Сводный отчет о выполнении развертывания

В результате успешного развертывания файл /root/admin-openrc.sh будет создан для каждого УУ. В нем прописаны учетные данные для доступа к платформе OpenStack.

ВАЖНО.

После разворачивания необходимо выполнить проверку работоспособности ОП (см. документ Руководство оператора ОП TIONIX).

Примечания.

Настройка отказоустойчивого кластера выполняется с помощью роли roles/openstack_pcs.yml.

Подробности по структуре отказоустойчивого кластера, развертываемого по референсной схеме, изложены в Приложении (Кластер высокой доступности).

Для установки системы мониторинга предусмотрены дополнительные автоматизированные сценарии развертывания.

Внимание.

Уникальные имена (hostname) должны быть установлены на всех узлах (для нормальной работы менеджера ресурсов Pacemaker).

3.3.1.3 Сценарий установки бэкэнда хранилища данных

Автоматизированный сценарий развертывания бэкэнда содержится в отдельном плейбуке – файле storage-backend.yml.

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

3.3.2 Авторизация (вход в Dashboard)

По завершении развертывания необходимо выполнить вход в интерфейс управления инфраструктурой ОП TIONIX, используя VIP – переменную „_vip_address“, назначенную из плейбука changeme.yml.

В адресной строке браузера следует ввести URL (обслуживаемый модулем TIONIX.Dashboard):

http(s)://``cвой_домен``/dashboard

После ввода URL нажмите <Enter> для отправки запроса на авторизацию. Ожидайте появления графического окна (Рис. 3.19), которое откроется как только веб-сервер успешно обработает запрос.

../_images/Web-Logon1.png

Рис. 3.19 Окно авторизации (вход в Dashboard)

Примечание.

Запрос, отправленный по защищенному протоколу (HTTPS), будет успешно обработан только в случае действительности сертификата и соответствующей настройки конфигурации веб-сервера, функционирующего на УУ.

Введите реквизиты администратора:

  • логин – слово admin;
  • пароль (администратора).

В качестве пароля используйте значение параметра „password = „ из секции [keystone], прописанного в конфигурации шаблона развертывания (см. файл vars.conf).

Примечания.

См. описание плейбука – в Приложении (Файл настройки переменных (changeme.yaml)).

3.3.3 Настройка окружения OpenStack

На устанавливаемых в облачную инфраструктуру контроллерах должно быть настроено окружение OpenStack. Для этого используется shell-скрипт – /root/admin-openrc.sh.

Откройте консоль и в командной строке (окне Терминала) выполните команду для безопасного входа в контроллер (УУ):

ssh user@<VIP>

В ответ на запрос ввести пароль учетной записи (user).

Выполнить команду для вывода списка пользователей в текущем проекте можно следующим образом:

source /root/admin-openrc.sh
openstack user list

Примечание.

Команды, выполняемые с помощью утилиты клиента (openstack), могут запускаться из любого другого инфраструктурного узла, на который установлено ПО клиента [3].

Типичное содержание скрипта admin-openrc.sh показано ниже:

#!/bin/bash
export OS_PROJECT_DOMAIN_NAME=default
export OS_USER_DOMAIN_NAME=default
export OS_PROJECT_NAME=admin
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=<пароль>
export OS_AUTH_URL=http://manage.tionix.loc:35357/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2
export OS_AUTH_TYPE=password
export GNOCCHI_ENDPOINT=http://manage.tionix.loc:8041

Окружение может быть просмотрено в Dashboard, после входа с ролью admin. Для этого необходимо выбрать вкладку панели управления Доступ к API.

3.3.4 Проверка работоспособности

После завершения развертывания рекомендуется выполнить полную проверку работоспособности облачной платформы [4] или диагностику работы модулей TIONIX (см. Приложение Выполнение тестов самодиагностики).

См.также

Для проверки работоспособности могут использоваться материалы программы и методики испытаний (в общей или частной форме).

Основные проверки должны касаться:

  • кластера управления;
  • кластера Galera (базы данных);
  • службы вычислений и подсистем виртуализации.

3.3.4.1 Кластер управления

Сетевая связность между рабочей станцией и каждым управлящим узлом кластера проверяется через эхо-отклик:

ping control1.<доменный суффикс>

ping control2.<доменный суффикс>

ping control3.<доменный суффикс>

Проверьте состояние кластера высокой доступности, выполнив с любого УУ команду (см. Приложение Кластер высокой доступности):

pcs status

3.3.4.2 Кластер Galera

Подключитесь к УУ и затем – к БД, используя утилиту клиента MariaDb. Выполните команду:

mariadb --user=<имя_пользователя> --password=<пароль>
или
mariadb -p

Уточните состояние кластера БД при помощи SQL-запросов, которые следует выполнить на всех управляющих узлах:

SHOW STATUS LIKE 'wsrep_ready';
SHOW STATUS LIKE 'wsrep_cluster_size';
SHOW STATUS LIKE 'wsrep_local_state_comment';

Вывод должен содержать, соответственно, следующие значения:

  • ON (узел кластера готов к приёму входящих запросов);
  • 3 (кластер состоит из трёх узлов);
  • Synced (узел подключен к кластеру и работоспособен).

Если эти значения совпадают, значит – кластер полностью работоспособен и «здоров».

В случае, если ни один из запросов не выполняется, потребуется выполнить проверку работы системной службы сервера баз данных (на VIP – точке входа) [5]. Рекомендуется также проверить версию установленной MariaDb:

dnf info mariadb-server

ВАЖНО.

Пакет сервера баз данных (MariaDb) должен быть строго версии 10.5.

3.3.4.3 Очередь сообщений

Выполните команду:

rabbitmqctl cluster_status

Должно быть выведено примерно следующее:

Cluster status of node rabbit@control1 ...
Basics

Cluster name: название кластера (очереди сообщений)

Disk Nodes

rabbit@control1
rabbit@control2
rabbit@control3

Running Nodes

rabbit@control1
rabbit@control2
rabbit@control3

Versions

rabbit@control1: RabbitMQ 3.8.3 on Erlang 22.3.4.1
rabbit@control2: RabbitMQ 3.8.3 on Erlang 22.3.4.1
rabbit@control3: RabbitMQ 3.8.3 on Erlang 22.3.4.1

Alarms

(none)

Network Partitions

(none)

Listeners

Node: rabbit@control1, interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
Node: rabbit@control1, interface: 10.55.13.12, port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
Node: rabbit@control1, interface: [::], port: 15672, protocol: http, purpose: HTTP API
Node: rabbit@control2, interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
Node: rabbit@control2, interface: 10.55.13.21, port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
Node: rabbit@control2, interface: [::], port: 15672, protocol: http, purpose: HTTP API
Node: rabbit@control3, interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
Node: rabbit@control3, interface: 10.55.13.22, port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
Node: rabbit@control3, interface: [::], port: 15672, protocol: http, purpose: HTTP API

Feature flags

Flag: drop_unroutable_metric, state: disabled
Flag: empty_basic_get_metric, state: disabled
Flag: implicit_default_bindings, state: enabled
Flag: quorum_queue, state: enabled
Flag: virtual_host_metadata, state: enabled

3.3.4.4 Служба вычислений

Фактический список доступных гипервизоров может быть выведен с помощью команды openstack hypervisor list (см. Рис. 3.20).

../_images/OS_hypervisors.png

Рис. 3.20 Список ВУ (зарегистрированных гипервизоров)

Проверьте работоспособность вычислительной службы (Nova) и службы хранения образов (Glance), для этого создайте в проекте по-умолчанию (роль администратора) одну виртуальную машину (Рис. 3.21). Используйте образ CirrOS, содержащий минимальный функционал – загрузчик ОС Linux с консолью.

../_images/VM_1st.png

Рис. 3.21 Первая виртуальная машина (на основе CirrOS)

Примечания.

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

Методики функциональной диагностики и нагрузочного тестирования ОП изложены в документе Методики испытаний инфраструктуры TIONIX. См. также материалы технической документации (самодиагностика).

3.3.5 Повторное выполнение развертывания (опционально)

Если при автоматизированной раскатке возникли проблемы (при выполнении роли pacemaker или mysql, то необходимо на каждом управляющем узле (control*) запустить скрипт rm_maria_pcs.sh. Скрипт хранится в архиве шаблона, вместе с плейбуками (в директории playbooks).

Скрипт удаляет все пакеты и конфигурационные файлы, образующие отказоустойчивый кластер (контролируемый с помощью Pacemaker) и кластер БД (образуемый средствами MariaDb и Galera).

После выполнения скрипта необходимо проверить (на каждом УУ), не остались ли рабочие процессы от кластера Galera. Выполните команду:

ps -aux | grep mariadb

Если процессы остались, то необходимо завершить процессы командой:

kill -9 “PID”

После этого, на каждом из УУ, необходимо выполнить команду:

rm -rf /var/lib/mysql/*

После выполнения вышеописанных действий, осуществляющих очистку управляющих узлов от служб СУБД и отказоустойчивого кластера, следует внести исправления в конфигурацию (шаблон) и снова запустить сценарий автоматического развёртывания (Раздел 3.3.1).

Содержимое скрипта (rm_maria_pcs.sh):

#!/bin/bash

yum remove -y mariadb*
yum remove -y haproxy
ps -aux | grep mariadb
killall mariadb
rpm -qa | grep maria

pcs resource delete p_galera-clone
pcs cluster destroy
systemctl stop pcsd.service
systemctl stop pcsd-ruby.service
dnf remove -y pacemaker corosync pcs
rm -rf /var/lib/pcsd/*
rm -rf /var/lib/pacemaker/*
rm -rf /var/lib/corosync/*
rm -rf /var/log/pacemaker/*
rm -rf /var/log/cluster/*
rm -rf /etc/pacemaker/*
rm -rf /etc/sysconfig/pacemaker
rm -rf /etc/sysconfig/crm_mon
rm -rf /etc/sysconfig/clustercheck
rm -rf /var/lib/mysql/*
rm -rf /etc/my.cnf.d/*

Сноски

[1]https://dic.academic.ru/dic.nsf/ruwiki/91036
[2]https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#playbook-syntax
[3]https://ansible-for-network-engineers.readthedocs.io/ru/latest/book/02_playbook_basics/result.html
[4]https://docs.ansible.com/ansible/latest/cli/ansible-playbook.html
[5]https://docs.openstack.org/project-deploy-guide/openstack-ansible/victoria/verify-operation.html