Rubackup_AG 29 апр в 18:38

Как настроить резервирование VK Private Cloud с помощью RuBackup

Простой

21 мин

688

Блог компании Группа АстраРезервное копирование*IT-инфраструктура*

Туториал

Дисклеймер
Экосистема «Группы Астра» включа ет собственный портфель решений, покрывающий задачи по созданию облачной ИТ-инфраструктуры и виртуализации. Мы активно сотрудничаем с технологическими партнерами, поэтому значительная часть наших продуктов совместима с продуктами других вендоров.
RuBackup — решение для автоматизированной защиты данных инфраструктурных систем любого масштаба и бизнес‑приложений, входящее в «Группу Астра». Оно может быть применимо в ИТ‑решениях, не входящих в контур «Группы Астра», в том числе в VK Private Cloud. Данная статья описывает кейс применения СРК RuBackup внутри VK Private Cloud.
В настоящий момент мы работаем над созданием полноценного решения для резервного копирования как в частном, так и в публичном облаке.

Получение доступа к VK Private Cloud и настройка модуля rb_module_openstack

При эксплуатации облаков, в частности приватных, становится актуальной проблема резервного копирования ресурсов облака. Систему резервного копирования RuBackup можно использовать в качестве решения резервного копирования для виртуальных машин в облаках на основе VK Private Cloud.

VK Private Cloud это развитая платформа для организации частных облаков. Внутри этой платформы среди прочего используются наработки проекта openstack для организации работы с виртуальными машинами. Решения RuBackup позволяют осуществлять резервное копирование и восстановление виртуальных машин openstack внутри облака VK Private cloud.

В дальнейшем для работы вам потребуется документация по развертыванию вашего конкретного экземпляра VK Pritave Cloud: количество и типы различных узлов, их IP адреса и доменные имена. Все это должно быть вам предоставлено в процессе развертывания VK Private Cloud командной развертывания или администратором VK Private Cloud.

Предположим, что в вашей локальной инфраструктуре уже проинсталирован и настроен экземпляр VK Private Cloud. Чтобы RuBackup смог работать внутри VK Private Cloud, для начала требуется создать пользователя системы виртуализации openstack, от имени которого будет работать модуль rb_module_openstack RuBackup. Для этого нужно зайти по ssh на деплой узел VK Private Cloud. Для определенности будем считать, что в локальной сети настроена служба DNS и все имена хостов находятся в домене второго уровня corp.ru. Таким образом, сначала требуется зайти по ssh на деплой узел deploy.corp.ru, используя приватный ключ id_rsa, полученный при развертывании VK Private Cloud. За доменным именем деплой узла и ключом доступа обратитесь к вашему администратору VK Private Cloud. В примере ниже для подключения на деплой узел использован пользователь 'centos'.

# ssh -i id_rsa centos@deploy.corp.ru

Далее с узла деплоя заходим по ssh на один из узлов cpn VK Private Cloud:

$ ssh cpn001

Потом получаем права суперпользователя командой

$ sudo -i

и переходим в каталог /root:

# cd /root

В домашнем каталоге пользователя root должен лежать файл конфигурации консольной утилиты openstack с названием openrc.sh.

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

# . /root/openrc.sh

чтобы экспортировать переменные, нужные для работы утилиты командной строки openstack и проверьте ее работоспособность командой

# openstack project list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 26824dd0fb5b4732896161025bc72e92 | mcs1112223330 |
| 622592b629954e72aa8751533a3d1b24 | mcs1112223340 |
| 94f916ad2e184c3b92d76ea9da0b557a | service       |
| b82e4490b6a74022a440a7fc53449882 | katana        |
| b8eef202bc554fc5869a35d14a2f3851 | mcs1112223350 |
| be9109b13ad94ec5b34d93b8f2cc44dc | admin         |
| ffbeafe76ec646089486c1c58af3bb5c | mcs1112223360 |
+----------------------------------+---------------+

Вы получите список проектов openstack, доступных в данном VK Private Cloud.

Чтобы узнать, с каким именно из этих проектов вам нужно работать, зайдите в WEB-интерфейс личного кабинета вашего VK Private Cloud и обратите внимание на правый верхний угол — там будет отображено имя вашего текущего проекта в VK Private Cloud и его имя в системе виртуализации openstack. Для получения информации о доступе к WEB‑интерфейсу личного кабинета VK Private Cloud обратитесь к документации VK Private Cloud и администратору вашей инсталляции VK Private Cloud.

В данном случае мы имеем имя проекта openstack mcs1112223330 и оно соответствует id проекта openstack 26824dd0fb5b4732896161025bc72e92. Эту информацию предоставляет вывод команды openstack project list, данные которого приведены выше. Таким образом, идентификатор openstack требуемого проекта будет 26824dd0fb5b4732896161025bc72e92.

Далее создадим пользователя openstack в домене openstack по умолчанию для работы модуля rb_module_openstack RuBackup c именем rubackup:

# openstack user create --domain default --password-prompt rubackup

В процессе работы команды система запросит пароль для вновь создаваемого пользователя. В данном примере будет использован пароль PassW@ord

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

# openstack role add --project 26824dd0fb5b4732896161025bc72e92 --user rubackup mcs_admin_vm# openstack role add --project 26824dd0fb5b4732896161025bc72e92 --user rubackup member# openstack role add --project 26824dd0fb5b4732896161025bc72e92 --user rubackup adminДля вывода полного списка ролей VK Private Cloud выполните команду# openstack role list

Для определения значения каждой роли VK Private Cloud обратитесь к документации VK Private Cloud.

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

Таким образом размер свободного пространства на хосте клиента openstack RuBackup должен быть больше чем максимальный размер дисков виртуальной машины, которые планируется бэкапить. Но это актуально только для одной задачи на восстановление. Если будет запущено несколько задач на восстановление одновременно, то свободного места на виртуальной машине с клиентом RuBackup и модулем rb_module_openstack должно быть достаточно, чтобы распаковать все резервные копии восстанавливаемых виртуальных машин одновременно.

После создания виртуальной машины проинсталлируйте туда те варианты пакетов клиента Rubackup и модуля rb_module_openstack Rubackup, которые соответствуют операционной системе вашей виртуальной машины. Для инсталляции и настройки клиента RuBackup обратитесь к документации RuBackup. Дальше же будет подробно рассмотрено конфигурация модуля rb_module_openstack клиента RuBackup.

Заполнение файла конфигурации модуля rb_module_openstack

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

Для настройки модуля rb_module_openstack RuBackup укажите следующие параметры в файле конфигурации модуля /opt/rubackup/etc/rb_module_openstack.conf

URL для сервиса identity openstack. Для определения этого URL зайдите в WEB-интерфейс личного кабинета вашего VK Private Cloud по адресуhttps://lk.vkpc.corp.ru/app/mcs1112223330/project/endpoints, заменив доменное имя vkpc.corp.ru и VK Private Cloud project id на актуальные значения и возьмите значение таблицы из поля Keystone. Пусть для примера в данном случае это будет https://lk.vkpc.corp.ru/identity/v3/.
Имя пользователя подсистемы openstack. В данном случае rubackup.
Пароль для пользователя из п.2. В данном случае PassW@ord.
Идентификатор проекта openstack, в котором находится учетная запись пользователя из п.2. Здесь это 26824dd0fb5b4732896161025bc72e92
Идентификатор виртуальной машины клиента СРК, то есть той виртуальной машины, на которой работает сервис клиента RuBackup и модуль openstack RuBackup. Список всех виртуальных машин в проекте можно посмотреть командой openstack server list --project 26824dd0fb5b4732896161025bc72e92, и далее выбрать openstack id виртуальной машины клиента RuBackup.
Имя домена openstack, в котором учетная запись пользователя из п.2. Тут может использоваться домен по умолчанию с именем default.
Значение timeout задайте как 120. Это промежуток времени в секундах, в течение которого модуль RuBackup будет ожидать ответа от платформы виртуализации VK Private Cloud на свой REST API запрос.

Таким образом, файл конфигурации модуля rb_module_openstack /opt/rubackup/etc/rb_module_openstack.conf должен выглядеть так:

# Symbol "#" at the beginning of the line treats as a comment
# "#" in the middle of the line treats as a parameter value
# So please do not use comments in one line with parameter

# Mandatory parameters
# Get config URLs at https://<OPENSTACK_WEBUI_IP>/dashboard/project/api_access/
# or https://msk.cloud.vk.com/app/<PROJECT>/project/endpoints
identity_url https://lk.vkpc.corp.ru/identity/v3
# URL to the  compute service, optional
# compute_url http://<OPENSTACK_WEBUI_IP>:8774/v2.1/<PROJECT_ID>/
# URL to the volumev3 service, optional
# volume_url  http://<OPENSTACK_WEBUI_IP>:8776/v3/<PROJECT_ID>/
# URL to the network service, optional
# Network URL must be provided without version in path
# network_url http://<OPENSTACK_WEBUI_IP>:9696
# Image URL must be provided without version in path
# image_url http://<OPENSTACK_WEBUI_IP>:9292
project_id 26824dd0fb5b4732896161025bc72e92
# User name on behalf of which the API requests will proceed
username rubackup
# Password to be used with 'username' to authenticate in API
password PassW@ord
# Domain name to be used with 'username' and 'password' to authenticate in API
domain default
# REST operations timeout, seconds
# minimum 1, maximum 300, default 5
timeout 120
# ID of VM in Openstack platform where current module is deployed - can be obtained from instance info in WEB GUI
rubackup-vm-id 6c5ad270-5a10-4749-abdc-b3a3b32391be
##
## Optional parameters:
#  Admin user account info of OPENSTACK is required to run scripts inside the target VM
#admin_name <admin name>
#admin_password <admin password>
#
## Name of admin's project, optional
## If this value is not set, project_id value will be used instead as admin's project
admin_project_name NONE
## Name of admin's project domain, optional
admin_project_domain_name NONE
#
# If certificate info is not specified the module will connect to API w/o certificate verification
enable_ssl no
ca_info <path to cert>
# Turn on debug of REST requests
curl_verbose no
##
## Transport to execute remote scrips: before_backup, after_backup
# possible values: virsh, ssh
# default value: virsh
script_transport virsh
##
## User name for ssh transport
ssh_user rubackup_service_user
## Connection timeout for ssh transport, seconds
# minimum 1, maximum 300, default 5
ssh_connection_timeout 30
## ssh key file for ssh transport, full path only!
ssh_key_file /root/my_keys/my_key_file
# Project's region, optional
region NONE
## Number of retry attempts for cinder API requests in case of negative response from API
# minimum 0, maximum 10, default 0
cinder_api_request_retry_number 0
## Value of a timeout in seconds to wait for between retry requests to cinder API in case of negative response from API
# minimum 1, maximum 600, default 1
cinder_api_request_retry_timeout 1
## Timeout for creating volumes in openstack platform, seconds
# minimum 100, maximum 600, default 300
volume_creation_timeout 300
## Timeout for creating snapshots in openstack platform, seconds
# minimum 100, maximum 600, default 300
snapshot_creation_timeout 300
## Timeout for attaching and detaching volumes in openstack platform, seconds
# minimum 100, maximum 600, default 300
volume_attachment_timeout 300

В этом файле значения остальных параметров оставлены по умолчанию, кроме admin_name и admin_password, — они закомментированы. Значение для них зададим позднее.

Чтобы проверить работоспособность файла конфигурации, можно выполнить несколько команд:

1.Проверка статуса модуля rb_module_openstack RuBackup:

/opt/rubackup/modules/rb_module_openstack -t
Module version: 2.4.0

2.Вывод списка виртуальных машин-ресурсов для работы модуля rb_module_openstack RuBackup:

# /opt/rubackup/modules/rb_module_openstack -L
ID|Name|Status
a8e7abb3-e4a0-44cf-94c9-d6ca67a21fcb|vm_server3|ACTIVE
594f73b6-48b5-48c6-9cc1-f1514f9f5bd6|vm_server2|ACTIVE
b4abd9e8-a96d-4d77-9dfd-0efe39b67be5|vm_server1|ACTIVE
6c5ad270-5a10-4749-abdc-b3a3b32391be|rubackup-client|ACTIVE

3. Вывод списка параметров восстановления из резервной копии для модуля rb_module_openstack RuBackup:

# /opt/rubackup/modules/rb_module_openstack -o
dd_block_size: unsigned ::Block size for dd operations, Megabytes:
keep_original_vm_name: bool :false:Set this flag when necessary to obtain server with original name after the restore:
network_uuid: UUID :6540e6e5-9ecc-4880-84b5-68e68d7f5977##SEP##d6b0601f-3ddb-444c-94b7-fba92e026214##SEP##ORIGINAL:UUID of network to use for the new server. Set it to ORIGINAL for restore with stored network:
fixed_ip: IPv4 ::Fixed IP address to use for the new server:
image_uuid: UUID :c2bd2c23-5166-477b-8c61-e2fed3e52129##SEP##e0530872-ea11-4ff1-a790-b32a086f73e0##SEP##79160c42-91cf-47b5-b5d1-d0942eeb5546##SEP##cb24f0be-cb17-488a-b9da-ab962b37d590##SEP##5bba1c09-0484-4e79-9a5c-850da2dfbf49##SEP##b1cfe99c-65f2-4de7-979c-ed4ae8df9088##SEP##eec6929e-2562-4a52-9e73-191428218bd6##SEP##3efb94cb-e375-49f5-af63-9cd072837130##SEP##fff1244b-dee9-4b58-b71c-26a7048cf203##SEP##05d6fca7-51ae-4a4f-b6b5-f0e7a693996b##SEP##d22d2659-e505-483f-8a0d-3acf2c08cb3b##SEP##82c5f1b3-3e66-4fe2-a454-93718ff829ea##SEP##f307030a-cfdd-4319-8a1c-8a4bc0470e7a##SEP##b2cef2cd-390f-4f23-b8f0-5128b526bda4##SEP##ef4b3f48-c5d3-4d36-8294-c6a69caaa22a##SEP##709972f0-15e6-4d17-be4c-323e5d8a3a77:Operation system image UUID to use for the new server:
new_name: string ::Specifies the name that will be used for VM at restore:
remove_volumes_at_restore_failure: bool :false:Set this flag when necessary to remove created volumes if an error occurred when creating a VM from backup:
server_group_id: UUID :NONE:UUID of server group to use for the new server. Set it to NONE for restore without server group:
flavor_id: UUID :10a694d3-639c-4ac7-b7e5-42bee5a86b08##SEP##128baa88-0556-4c96-829f-9a91442a03e7##SEP##1446e688-d175-483d-a287-773b222c21bb##SEP##1572c088-3352-48d3-8c31-62ad04361664##SEP##253eb4d7-efbd-42ba-9079-ba21f63b5210##SEP##25593b52-c364-4064-96ed-039c456c3b47##SEP##2a5103c6-cb22-495d-82f4-40b6298bd6ff##SEP##2a6728a1-9c27-4ad1-a074-cad75a0fcc46##SEP##2b11ba4e-4d5a-4f39-a70d-d46c48eed844##SEP##4d5de002-b6f5-4c93-91af-f22593aadb24##SEP##4e794735-c72f-4831-bca9-943c48db5643##SEP##5de47fc6-aa09-4d87-ab75-df8cb95f70b1##SEP##6be18e84-7745-4a80-a06e-a24331d2d5c3##SEP##796c60d6-01cb-4986-885a-908e568eb2cd##SEP##8b34c1b0-0afd-4eaf-9287-c9bc4f247595##SEP##91775385-2c04-4a4e-9de1-9f270ef22d0e##SEP##96af0dbb-7da7-46d5-8d35-9aee4e51d705##SEP##9feb3993-c5ad-4db2-a755-291c9daa3882##SEP##a0d707d2-65a9-441c-9029-e7828287600e##SEP##c29c26eb-dfd3-42d4-a405-7577af216d18##SEP##c3087773-1c9a-4ce3-87b8-2c294b7f746c##SEP##d0b51e4a-3873-4b22-9485-3acacc87643d##SEP##dc1e8df9-634f-4429-a88a-c5fc468361ec##SEP##e62f1564-b386-4723-8960-3eec22ff7af4##SEP##e7babcd1-4355-478c-8af4-53e0eaa410d0##SEP##eb725be6-0c1c-4646-9fb4-bd0e09514a9d##SEP##eed2f810-2396-4a62-adff-aea4e44af1ae:UUID of flavor to use for the new server:
volume_type_id: UUID :b8d80066-e675-4fe4-afad-342180a49ea5##SEP##8222d38e-6867-45db-acc7-184a727e98d5:UUID of volume type to use for the new server's volumes:
server_availability_zone_name: string :AZ1:Name of available availability zone:

Если приведенные выше команды завершились успешно, то с большой долей вероятности вы корректно задали файл конфигурации модуля rb_module_openstack RuBackup /opt/rubackup/etc/rb_module_openstack.conf. Далее нужно перезапустить сервис клиента RuBackup, чтобы он обновил внутри себя информацию о доступности модулей командами:

# systemctl stop rubackup_client# systemctl start rubackup_client

В дальнейшем все операции по работе с RuBackup производим в Linux-консоли, но они также доступны из графической программы RBM RuBackup. Для более подробной информации обратитесь к документу Утилиты командной строки RuBackup.

Далее нужно убедится, что модуль rb_module_openstack RuBackup openstack стал доступен клиенту RuBackup на данном хосте. Этого можно добиться командой:

# rb_archives -L|grep openstack
openstack

Как видим, в выводе команды присутствует модуль openstack, а значит можно начать с ним работу.

Работа с модулем rb_module_openstack

Для начала сделаем рабочую копию для одного из ресурсов на данном VK Private Cloud с идентификатором b4abd9e8-a96d-4d77-9dfd-0efe39b67be5. Для этого выполним команду

# rb_archives -cb4abd9e8-a96d-4d77-9dfd-0efe39b67be5 -mopenstack
TASK WAS ADDED TO QUEUE:1

В данном случае Rubackup создала задачу на срочный бэкап и задача эта получила номер 1.

Следить за статусом выполнения задачи можно через команду rb_tasks, которая выводит список задач RuBackup и их статус:

# rb_tasks
Id | Task type    | Resource                             | Backup type | Status    | Created               
---+--------------+--------------------------------------+-------------+-----------+-----------------------
1  | Backup local | b4abd9e8-a96d-4d77-9dfd-0efe39b67be5 | full        | Execution | 2024-01-01 01:01:01+00

Если задача перешла в статус Done, это означает, что создание резервной копии заданной виртуальной машины закончилось успешно. Если задача перешла в статус Error, значит создание резервной копии закончилось с ошибками. Для диагностики ошибок нужно посмотреть лог-файлы /opt/rubackup/log/RuBackup.log на хостах клиента и сервера RuBackup.

На узле клиента RuBackup для диагностики ошибки может быть полезно проанализировать журнала задачи /opt/rubackup/log/Task_<task_id>.log (в рассмотренном примере — Task_1.log) и журнала модуля RuBackup: /opt/rubackup/log/rb_module_openstack.log.

Если после успешного окончания задачи создания резервной копии набрать команду rb_archives, можно увидеть информацию по только что созданной РК:

Id | Ref ID | Resource                             | Resource type | Backup type | Created                | Crypto  | Signed | Status             
---+--------+--------------------------------------+---------------+-------------+------------------------+---------+--------+-------------------
 1 |        | b4abd9e8-a96d-4d77-9dfd-0efe39b67be5 | OPENSTACK     | full        | 2024-01-01 01:01:01+00 | nocrypt | False  | Not Verified

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

Давайте восстановим эту резервную копию используя параметры восстановления.

Восстанавливаем резервную копию

Для этого можно использовать следующие параметры восстановления:

dd_block_size: необязательный, значение по умолчанию 5. Размер блока данных в мегабайтах, используемый при восстановлении виртуальных дисков виртуальной машины. Если на хосте, где находится клиент Rubackup, достаточно много оперативной памяти, то можно задать это значение вплоть до 100 Мб.

keep_original_vm_name: необязательный, значение по умолчанию false. Этот параметр означает, что если на момент восстановления в данном проекте уже существовала виртуальная машина с таким именем, как в рабочей копии, то она будет удалена и восстановленная виртуальная машина будет иметь свое оригинальное имя.

network_uuid: необязательный. Этот параметр позволяет задать сеть, к которой будет подключена виртуальная машина после восстановления. IP-адрес в этом случае будет задан автоматически. Если этот параметр не задать или задать значение ORIGIANL, то виртуальная машина будет подключена в ту сеть, в которой находилась оригинальная виртуальная машина. Если при этом сеть, в которую подключили оригинальную виртуальную машину, была удалена на момент восстановления и значение этого параметра не задано, или имеет значение ORIGINAL, то задача восстановления резервной копии завершится ошибкой.

fixed_ip: необязательный. Этот параметр позволяет задать IP-адрес в сети, указанный в параметре network_uuid. Если заданный IP-адрес не валиден или не принадлежит ни к одной из подсетей сети, заданной параметром network_uuid, то задача восстановления резервной копии завершится ошибкой.

image_uuid необязательный. Этот параметр позволяет задать образ, который будет использоваться при создании корневого диска виртуальной машины. Если этот параметр не задать, то будет использован тот образ, который использовался при создании корневого диска оригинальной виртуальной машины. Если при этом образ, который пользовался при создании корневого диска оригинальной виртуальной машины, был удален на момент восстановления и значение этого параметра не задано, то задача восстановления резервной копии завершится ошибкой.

new_name: необязательный, это имя восстановлений виртуальной машины. Если этот параметр не задан, то при восстановлении будет выполнена проверка наличия в платформе виртуализации виртуальной машины с оригинальным именем. Если при этом такой виртуальной машины не существует, будет создана виртуальная машина с оригинальным именем. В противном случае к оригинальному имени добавляется 1, 2. _3 и так далее.

remove_volumes_at_restore_failure необязательный, значение по умолчанию false. В случае ошибки восстановления удалять тома, созданные в процессе восстановления резервной копии.

server_group_id: необязательный - это идентификатор серверной группы, в которую нужно включить восстановленную виртуальную машину. Если этот параметр не задан, то виртуальная машина будет включена в ту же серверную группу, в которой была оригинальная виртуальная машина. Если при восстановлении виртуальной машины ее не нужно включать ни в какую серверную группу, то этот параметр должен иметь значение NONE.

flavor_id: необязательный, это идентификатор флавора, который нужно использовать при создании виртуальной машины. Если этот параметр не задан, то при создании виртуальной машины будет задействован тот флавор, который был использован при создании оригинальной виртуальной машины. В платформе виртуализации openstack флавор определяет соотношение количества виртуальных процессоров и оперативной памяти и других параметров, которые будут использованы у создаваемой виртуальной машины.

volume_type_id: необязательный, идентификатор типа томов, который нужно использовать при создании томов виртуальной машины. Если этот параметр не задан, то при создании томов виртуальной машины задействуются те значения, которые были использованы при создании томов оригинальной ВМ.

server_availability_zone_name: необязательный, имя зоны доступности, в которой должна находится созданная виртуальная машина. Если этот параметр не задан, то новая виртуальная машина будет находится в той же зоне доступности, что и оригинальная ВМ.

Давайте для примера восстановим виртуальную машину в новую сеть с новым заданным свободным IP-адресом. В сети d6b0601f-3ddb-444c-94b7-fba92e026214, в которую мы хотим восстановить виртуальную машину, есть подсеть 192.168.0.0/24. Будем использовать для восстановления свободный IP-адрес 192.168.100.100. Сделать восстановление резервной копии можно будет командой:

# rb_archives -x1 -enetwork_uuid:d6b0601f-3ddb-444c-94b7-fba92e026214,fixed_ip:192.168.100.100
Password: 
The archive will be restored in the directory: /tmp
----> Restore archive chain: 1  < ----
Record ID: 1 has status: Not Verified
Continue (y/n)? yes
TASK WAS ADDED TO QUEUE:2

Таким образом, мы создали задачу на восстановление виртуальной машины с идентификатором 2.

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

# rb_tasks
Id | Task type    | Resource                             | Backup type | Status    | Created               
---+--------------+--------------------------------------+-------------+-----------+-----------------------
1  | Backup local | b4abd9e8-a96d-4d77-9dfd-0efe39b67be5 | full        | Execution | 2024-01-01 01:01:01+00
2  | Restore      | b4abd9e8-a96d-4d77-9dfd-0efe39b67be5 | full        | Done      | 2024-01-01 01:01:01+00

Как видите, задача на рестор РК завершилась успешно и новая виртуальная машина создалась.

Выполнение скриптов внутри виртуальной машины модулем rb_module_openstack

Используем virsh

Один из дополнительных способов создания консистентной резервной копии виртуальной машины на уровне приложений ее гостевой операционной системы в модуле rb_module_openstack RuBackup - перед началом бэкапа (перед созданием снэпшотов дисков виртуальной машины) выполнить в гостевой операционной системе скрипт, или исполняемый файл.

Например, это может быть скрипт для остановки кластера СУБД, или какого-либо сервиса или бизнес-приложения. Также после того, как будут созданы снэпшоты дисков виртуальной машины, есть возможность выполнить дополнительный скрипт/исполняемый файл. Например, для старта кластера СУБД. После того как будут созданы снэпшоты дисков виртуальной машины, для которой создается резервная копия, есть возможность выполнить скрипт еще раз, например, для старта кластера СУБД. Для примера создадим в каталоге /root такой скрипт:

#!/usr/bin/env bash

echo [`date`] [`hostname`] $* >>/opt/rubackup/scripts/rubackup_log

и поместим его в файл по пути /opt/rubackup/scripts/rubackup_script.sh в гостевой операционной системе виртуальной машины, для которой предполагается создать резервную копию.

Зададим этому файлу бит исполнения через команду chmod +x /opt/rubackup/scripts/rubackup_script.sh. Файл именно по этому пути ищет по умолчанию при бэкапе модуль rb_module_openstack RuBackup, чтобы выполнить его с аргументами before или after, в соответствии с фазой бэкапа. Если скрипты, которые вам нужны, расположены по другим путям, используйте параметры бэкапа модуля rb_module_openstack script_before_snapshot, script_after_snapshot. Нужно учитывать, что в качестве значений script_before_snapshot, script_after_snapshot нужно указывать полный путь к этим скриптам в гостевой операционной системе. В утилите командной строки rb_archive эти скрипты нужно указывать, используя параметр -e: -escript_before_snapshot:/root/before.sh,script_after_snapshot:/home/rubackup/after.sh.

В гостевой операционной системе резервируемой виртуальной машины создайте каталог /opt/rubackup/scripts/ и файл rubackup_script.sh в этом каталоге из-под аккаунта root.

Для запуска пользовательского скрипта внутри виртуальной машины у модуля rb_module_openstack RuBackup есть две возможности:

Использовать свойства облака VK Private Cloud и как бы "сказать" гипервизору системы виртуализации openstack, на котором находится виртуальная машина, что мы хотим выполнить на ней какую-то команду
Также возможно с помощью клиента ssh непосредственно выполнить эту команду через клиент openstack СРК RuBackup.

Рассмотрим первый способ. Для этого в файл конфигурации модуля нужно добавить следующие параметры:

admin_name admin
admin_password admin_password
#
## Name of admin's project, optional
## If this value is not set, project_id value will be used instead as admin's project
admin_project_name NONE
## Name of admin's project domain, optional
admin_project_domain_name NONE
script_transport virsh

где:

admin_name: имя пользователя с привилегиями администратора облака VK Private Cloud

admin_password: пароль аккаунта admin_name

admin_project_name: имя проекта, в котором является администратором пользователь с именем admin_name

admin_project_domain_name: имя домена в котором находится проект с именем admin_project_name
script_transport virsh: название транспорта, название транспорта, который будет использован для доступа к виртуальной машине, на которой мы хотим выполнить скрипты.

Далее нам потребуется настроить беспарольный доступ по ssh на хост гипервизора, на котором работает наша виртуальная машина для пользователя root. Для этого запустим команду:

openstack server show b4abd9e8-a96d-4d77-9dfd-0efe39b67be5 |grep hypervisor_hostname

| OS-EXT-SRV-ATTR:hypervisor_hostname | kcn003.vkpc.corp.ru  |

из под аккаунта администратора VK Private Cloud. Если в выводе команды выводится пустая строка, значит команда запущена не из-под аккаунта администратора VK Private Cloud.

Далее запустите команду опять же из-под аккаунта администратора VK Private Cloud:

# openstack hypervisor list 
+----+---------------------+-----------------+------------+-------+
| ID | Hypervisor Hostname | Hypervisor Type | Host IP    | State |
+----+---------------------+-----------------+------------+-------+
|  2 | kcn003.vkpc.corp.ru | QEMU            | 10.30.3.16 | up    |
|  5 | kcn002.vkpc.corp.ru | QEMU            | 10.30.3.15 | up    |
|  8 | kcn001.vkpc.corp.ru | QEMU            | 10.30.3.14 | up    |
+----+---------------------+-----------------+------------+-------+

И среди гипервизоров выберете значение поля Host IP того hostname, которое соответствует расположению виртуальной машины, взятой из предыдущего шага.

Далее убедитесь, что из-под пользователя root хоста клиента RuBackup у вас сгенерированы ключи openssh, то есть каталог ~/.ssh содержит файлы типа id_rsa. id_rsa.pub. Если же на данном хосте отсутствуют ключи openssh для пользователя root, сгенерируйте их командой ssh-keygen.

Далее скопируйте открытый ssh-ключ пользователя root на хост-гипервизор виртуальной машины командой ssh-copy-id root@10.30.3.16. Введите пароль пользователя root хоста-гипервизора VK Private Cloud и убедитесь, что команда завершилась успешно. Данную процедуру добавления публичных ключей желательно повторить для каждого из гипервизоров, входящих в состав VK Private Cloud, информацию о которых была получена в выводе команды openstack hypervisor list. Дело в том ,что в случае автоматического создания задачи на резервное копирование виртуальной машины в рамках правила глобального расписания или стратегии заранее неизвестно, на каком именно гипервизоре выполняется виртуальная машина, для которой необходимо выполнить процедуру бэкапа.

Также на виртуальной машине, для которой нужно выполнить процедуру бэкапа, требуется установить сервис qemu-guest-agent. Убедитесь, что сервис установлен, запущен и статус его активен, используя пакетный менеджер и утилиты управления сервисами той операционной системы, которая установлена на вашей виртуальной машине.

Пример сервиса, который запущен и работает:

● qemu-guest-agent.service - QEMU Guest Agent
     Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static; vendor preset: enabled)
     Active: active (running) since Tue 2024-01-01 00:00:00 UTC; 1s ago
   Main PID: 13357 (qemu-ga)
      Tasks: 1 (limit: 2387)
     Memory: 332.0K
     CGroup: /system.slice/qemu-guest-agent.service
             └─13357 /usr/sbin/qemu-ga

Если в вашем случае есть ошибки в работе сервиса qemu-guest-agent, обратитесь к руководству пользователя используемой операционной системы и администратору VK Private Cloud.

Далее убедитесь, что на хосте-клиенте RuBackup установлена утилита командной строки virsh. Если она отсутствует, то установите ее, используя пакетный менеджер той операционной системы, которая стоит на вашем хосте-клиенте RuBackup.

Чтобы убедится, что команда virsh работает, запустите команду:

# virsh -c qemu+ssh://root@10.30.3.16/system list --uuid --name
ce807016-7d30-4fdb-84f2-49f466a23dde instance-0000013d             
b4abd9e8-a96d-4d77-9dfd-0efe39b67be5 instance-0000001a

В выводе команды virsh вы увидите информацию о виртуальных машинах, которые развернуты на данном хосте гипервизора, а именно UUID и имя инстанса виртуальной машины.

Чтобы убедится, что можно посылать команды с виртуальной машины клиента RuBackup на виртуальную машину, предназначенной для задачи бэкапа, выполните команду, указав в качестве имени виртуальной машины ее имя из вывода предыдущей утилиты:

virsh -c qemu+ssh://root@10.30.3.16/system qemu-agent-command instance-0000001a '{"execute": "guest-get-time"}'
{"return":1729587896666110000}

Эта команда запрашивает текущее время в гостевой операционной системы виртуальной машины с именем инстанса instance-0000001a. Если команда завершилась успешно, то команды с виртуальной машины клиента RuBackup могут выполняться на виртуальной машине для бэкапа. Если же команда завершилась ошибкой, то исправьте эти ошибки.

Далее можно запустить команду бэкапа еще раз:

# rb_archives -cb4abd9e8-a96d-4d77-9dfd-0efe39b67be5 -mopenstack
TASK WAS ADDED TO QUEUE:3

и убедиться, что скрипт исполнится на ВМ, предназначенной для бэкапа:

# cat /opt/rubackup/scripts/rubackup_log
[Tue Jan 01 00:00:00 UTC 2024] [rubackup-vm] before
[Tue Jan 01 00:00:10 UTC 2024] [rubackup-vm] after

Также в этом можно убедится по лог-файлу модуля /opt/rubackup/log/rb_module_openstack.log.

Используем ssh

Теперь давайте выполним тот же скрипт на виртуальной машине, предназначенной для бэкапа, но уже используя транспорт ssh. Убедитесь, что на виртуальной машине, предназначенной для бэкапа, установлен и запущен сервис openssh. Далее на виртуальной машине, которая является целью бэкапа, создадим специального пользователя rubackup, из-под которого и будут запускаться скрипты, и сгенерируем для него ssh ключи командой ssh-keygen. За информацией по созданию нового пользователя операционной системы обратитесь к руководству пользователя используемой ОС. Также настроим права доступа скрипта /opt/rubackup/scripts/rubackup_script.sh так, что пользователь rubackup сможет его исполнять и писать в лог-файл /opt/rubackup/scripts/rubackup_log.

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

script_transport ssh

ssh_user rubackup

Остальные параметры оставим без изменения.

Добавим содержимое файла /root/.ssh/id_rsa.pub хоста клиента RuBackup в файл /home/rubackup/.ssh/authorized_keys на виртуальную машину для бэкапа и убедимся, что можно зайти с хоста клиента RuBackup на хост виртуальной машины для бэкапа по протоколу ssh без запроса пароля: ssh rubackup@vm_server1.

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

# rb_archives -cb4abd9e8-a96d-4d77-9dfd-0efe39b67be5 -mopenstack
TASK WAS ADDED TO QUEUE:4

Осталось только убедится, что скрипт исполнился. Это можно сделать по контрольному лог-файлу /opt/rubackup/scripts/rubackup_log, а также лог-файлу модуля /opt/rubackup/log/rb_module_openstack.log

Заключение

В данной мы рассмотрели основные моменты при работе с модулем rb_module_openstack СРК RuBackup. Подробно разобрали, как сконфигурировать свой экземпляр VK Private Cloud для работы с СРК RuBackup. Также были рассмотрены вопросы конфигурирование модуля rb_module_opnestack и запуска пользовательских скриптов перед началом запуска процедуры бэкапа и после на виртуальной машине, выбранной пользователем для бэкапа.

Теги:

Хабы: