3.7 Архивная копия конфигурации ОП и БД

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

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

Для управляющих узлов – контроллеров OpenStack – содержание некоторых конфигурационных файлов может разниться. Для вычислительных узлов принципиальной разницы в конфигурации – нет, поэтому достаточно ограничиться сохранением архивной копии конфигурации первого (исправного) узла вычислительного кластера. Однако, если брать в расчёт конфигурационные файлы операционной системы (директории /etc/), то различия всё же могут быть, как минимум, в настройке сетевого имени хоста (hostname).

Примечание.

Способы восстановления отдельных компонентов референсной архитектуры рассмотрены в документе Руководство по техническому обслуживанию.

ВАЖНО.

После проверки общей функциональности следует экспортировать файл определений очереди сообщений и также сохранить его копию (definitions.file.json).

3.7.1 Управляющие узлы

На управляющих узлах следует снимать копии следующих директорий и файлов, содержащих настройки служб OpenStack и TIONIX, а также шины данных RabbitMQ:

/etc/keystone/

/etc/glance/

/etc/nova/

/etc/neutron/

/etc/cinder/

/etc/httpd/

/etc/openstack-dashboard/

/etc/tionix/

/etc/my.cnf

/etc/my.cnf.d/

/etc/haproxy/

/etc/rabbitmq

/var/lib/rabbitmq/

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

Соответственно, необходимо остановить системные службы, находящиеся в статусе Active и обеспечивающие работу сервисов в понимании архитектуры OpenStack.

3.7.1.1 База данных

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

mysqldump --all-databases | gzip > <openstack.sql>.gz

Настройка регулярного бэкапирования по расписанию (cron), без перерыва в обслуживании, выполняется вносом в файл /etc/crontab следующей строки:

0 2 * * * mysqldump -u root –all-databases –single-transaction –quick –lock-tables=false > /var/lib/mysql/backup/OS_db-backup.sql

где

OS_db-backup.sql – текстовый файл, содержащий полный дамп БД (OpenStack).

Примечания.

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

gzip -cd <OS_db-backup.sql>.gz | mysql

Внимание.

Следите за наличием свободного места в файловой системе, содержащей директорию /var/lib/mysql.

Заранее выполните оценку расширения БД, после загрузки образа, создания одного проекта, и одной-двух виртуальных машин (в проекте).

3.7.1.2 Конфигурация кластера Pacemaker

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

pcs config backup <openstack>

3.7.2 Вычислительные узлы (ВУ)

На вычислительных узлах следует снимать архивные копии следующих директорий:

/etc/nova/
/etc/neutron/
/etc/tionix