Привет всем, кто заботится о сохранности данных виртуальных машин (ВМ) и не хочет их потерять. Сегодня мы рассмотрим тему бэкапа ВМ на платформе виртуализации oVirt и oVirt-подобных: ROSA; zVirt, РЕД Виртуализация и HOSTVM. Далее в статье, когда будет идти речь о oVirt, подразумевается, что речь будет идти обо всех этих платформах. Для этого будем использовать систему резервного копирования (СРК) RuBackup.
Дисклеймер
Экосистема «Группы Астра» включает собственный портфель решений, покрывающий задачи по созданию облачной ИТ-инфраструктуры и виртуализации. Мы активно сотрудничаем с технологическими партнерами, поэтому значительная часть наших продуктов совместима с продуктами других вендоров.
RuBackup — решение для автоматизированной защиты данных инфраструктурных систем любого масштаба и бизнес‑приложений, входящее в «Группу Астра». Оно может быть применимо в ИТ‑решениях, не входящих в контур «Группы Астра», в том числе в oVirt-совместимых систем виртуализации (oVirt, zVirt, ROSA Virtualization, Red Virtualization Engine, HOSTVM). Данная статья описывает кейс применения СРК RuBackup внутри oVirt-совместимых систем виртуализации.
В экосистеме «Группы Астра» представлена система виртуализации VMmanager от ISPsystem, поддерживаемая RuBackup. Рекомендую обратить внимание, если вы находитесь в поиске надежного и функционального решения для виртуализации.
В настоящий момент мы работаем над созданием полноценного решения для резервного копирования как в частном, так и в публичном облаке.
В статье расскажу, как установить, настроить и использовать RuBackup для создания резервных копий (РК) ВМ на платформе oVirt, а также разберу некоторые сложности, которые могут возникнуть в процессе работы.
Прежде всего статья будет полезна для администраторов платформы виртуализации oVirt, которым необходимо настроить в системе резервное копирование. И для тех, кто хочет разобраться, как работает резервное копирование в RuBackup.
В конце статьи будут полезные ссылки, не забудьте обратить на них внимание!
Настройка RuBackup для работы с системой виртуализации oVirt
Разберемся с основной архитектурой RuBackup и возможностей, которые эта система предоставляет для резервного копирования ВМ в oVirt, а также обсудим некоторые технические особенности процесса.
Перед началом посмотрим на список версий платформ, которые поддерживает RuBackup:
oVirt: 4.4, 4.5;
zVirt: 4.0, 4.1, 4.2;
ROSA Virtualization: 2.1, 3.0;
Red Virtualization Engine: 7.3.0:
HOSTVM 4.5.
Важно отметить, что мы стараемся постоянно увеличивать список поддерживаемых версий платформ виртуализации, поэтому в будущем возможна поддержка других версий перечисленных платформ и поддержка других платформ основанных на базе oVirt. Следите за обновлениями!
Как работает RuBackup
Для понимания вопроса рассмотрим общую архитектуру RuBackup вне контекста работы с oVirt.
В упрощенном виде RuBackup работает по следующей схеме: на виртуальной (или физической) машине устанавливаются основной сервер (медиа-сервер), клиент и необходимые пользователю модули (в нашем случае — rb_module_ovirt).
Сервер взаимодействует с клиентами, координирует задания СРК и хранит резервные копии на доступных ему ресурсах: файловых системах, блочных устройствах, картриджах ленточных библиотек и облачных сервисах.
Клиент отвечает за резервное копирование ресурсов (например, ВМ oVirt) и передачу их на сервер в хранилища.
Хранение данных резервных копий (архивов) реализовано в виде хранилищ, где каждое хранилище входит в определенный пул. Пул — это логическое объединение однотипных устройств хранения резервных копий. Каждый пул принадлежит определенному медиа-серверу.
При нормальной работе сервер и клиент RuBackup запускаются на хосте как фоновые процессы (демоны).
RuBackup поддерживает полное, инкрементальное и дифференциальное резервное копирование.
Полное резервное копирование — это создание резервной копии всех данных из исходного набора, независимо от того, изменялись ли данные с момента выполнения последней полной резервной копии.
Инкрементальное резервное копирование сохраняет только данные, измененные со времени выполнения предыдущей инкрементальной резервной копии, а при отсутствии таковой — со времени выполнения последней полной резервной копии.
Дифференциальное (разностное) резервное копирование сохраняет только данные, измененные со времени выполнения предыдущего полного резервного копирования.
Ниже представлена архитектура RuBackup.
Более подробное описание ключевых понятий, архитектуры и в целом работы RuBackup можно найти в технической документации.
Установка RuBackup и модуля oVirt
Прежде всего стоит подчеркнуть философию команды RuBackup: мы стремимся сделать процесс резервного копирования доступным и удобным для всех. Именно поэтому было принято решение предоставить пробную лицензию, которая позволяет бесплатно резервировать данные объемом до 1 ТБ и сроком действия до 1 года. Это дает возможность пользователям познакомиться с продуктом и оценить его возможности на практике. Попробовать RuBackup можно по ссылке.
Наиболее подробно процесс установки и первичной настройки RuBackup описан тут, процесс установки модуля oVirt — тут. Там же можно найти информацию о поддерживаемых операционных системах.
Для работы RuBackup серверу требуется PostgreSQL с определёнными настройками, а также дополнительные пакеты (например, mailutils, libcurl и т. д.), корректная настройка файла “.bashrc” и открытие нужных портов. Подробная информация о поддерживаемых версиях PostgreSQL и список необходимых пакетов представлен тут.
Для установки клиента RuBackup необходимо получить два пакета (версии могут отличаться от представленной):
rubackup-ovirt-common-2.4.0.42-1.el8.x86_64;
rubackup-ovirt-client-2.4.0.42-1.el8.x86_64.
Клиент RuBackup рекомендуется установить на все хосты виртуализации платформы.
Для установки сервера RuBackup необходимо получить пять пакетов (версии могут отличаться от представленной):
rubackup-common_2.4.0.42-1_amd64;
rubackup-common-gui_2.4.0.42-1_amd64;
rubackup-client_2.4.0.42-1_amd64;
rubackup-server_2.4.0.42-1_amd64;
rubackup-rbm_2.4.0.42-1_amd64.
Сервер RuBackup необходимо установить на удаленную машину, которая будет подключена к какому-либо хранилищу данных.
Примечание: хотя RuBackup можно использовать без графического интерфейса, далее демонстрация функционала будет показана на примере использования графического менеджера RBM. В качестве альтернативы RBM в RuBackup присутствует веб-интерфейс Tucana для работы с СРК, но в данной статье мы его рассматривать не будем.
После установки пакетов с помощью утилиты “rpm” или “dpkg” необходимо запустить утилиту “rb_init” для настройки RuBackup. Без этой настройки система не будет работать, поэтому важно выполнить её корректно.
На сервере RuBackup “rb_init” необходим для настройки сервера, подключения к базе данных и т.д.
На клиенте RuBackup “rb_init” необходим для настройки клиента, подключения к серверу RuBackup.
В руководстве по установке описаны сценарий установки, когда сервер и клиент RuBackup находятся на разных хостах.
Начиная с версии 2.1, возможна работа с RuBackup через REST API, что детально описано в руководстве по установке и работе с REST API.
Настройка модуля oVirt
Почти все модули в RuBackup требуют дополнительной настройки, модуль для oVirt не исключение. Для корректной работы нужно заполнить конфигурационный файл rb_module_ovirt.config, который появляется в каталоге /opt/rubackup/etc после установки пакетов rubackup-ovirt-common-<version>.el8.x86_64.rpm и rubackup-ovirt-client-<version>.el8.x86_64.rpm. Подробнее о параметрах модуля oVirt описано тут.
Разделим все опции модуля на три группы и опишем.
Первая группа - основные параметры модуля, которые необходимы для базовой работы:
engine - WEB URL oVirt (он же REST API URL);
grant_type - тип аутентификации на платформе виртуализации, на данный момент поддерживается только тип “password”;
username - имя пользователя на платформе виртуализации, например “admin@internal”;
password - пароль пользователя;
ca_info - путь до сертификата SSL;
timeout - тайм-аут (в секундах) ответа от платформы виртуализации на API запросы;
disk_upload_mechanism - механизм загрузки дисков ВМ на платформу виртуализации. Принимает два значения - “file” или “nbd”. По умолчанию “file”;
backup_vm_from_native_host - при использовании нескольких хостов виртуализации, бэкап ВМ будет происходить только с того хоста, на котором работает клиент RuBackup. Принимает значения “yes” и “no”. Подробнее тут;
disk_upload_timeout, disk_download_timeout - тайм-ауты (в минутах) загрузки дисков через API с и на платформу во время бэкапа и восстановления;
allow_work_with_incompatible_versions - параметр для попытки работы с неподдерживаемыми версиями oVirt. Принимает значения “yes” и “no”;
curl_verbose - выводит дополнительную информацию по REST API запросам в журналы. Принимает значения “yes” и “no”.
Для создания сертификата “ca_info” необходимо выполнить две команды в консоли:
curl --output /opt/rubackup/keys/ovirt.ca.crt 'http://ovirtengine.yourdomain.local/ovirt-engine/services/pki-resource?resource=cacertificate&format=X509-PEM-CA'
chown vdsm:kvm /opt/rubackup/keys/ovirt.ca.crt
Вторая группа - параметры настройки работы с платформой, знакомым с oVirt они будут знакомы. Подробнее о них можно почитать тут:
image_transfer_timeout - тайм-аут (в секундах) на создание ImageTransfer на платформе виртуализации для загрузки дисков. Принимает значения от 1 до 3600;
imagetransfer_inactivity_timeout - тайм-аут (в секундах), в течение которых RuBackup ожидает загрузку диска по созданному ImageTransfer. Принимает значения от 5 до 500;
image_transfer_finalize_timeout - тайм-аут (в секундах), в течение которых RuBackup ожидает финализации ImageTransfer. Принимает значения от 1 до 3600.
Третья группа — параметры работы с механизмом бэкапа oVirt. oVirt позволяет использовать внутренние инструменты для резервного копирования ВМ, которые можно использовать пользуясь RuBackup:
backup_using_ovirt_api - использование механизма бэкапов oVirt при резервном копировании ВМ. Принимает значения “yes” и “no”;
remove_vm_checkpoints_at_full_backup - удаление предыдущих чек-пойнтов бэкапа, созданных oVirt-ом при использовании механизма бэкапа oVirt. Принимает значения “yes” и “no”;
platfom_side_backup_timeout - тайм-аут (в секундах), в течение которых RuBackup ожидает, пока бэкап на платформе виртуализации перейдет в состояние “ready”. Принимает значения от 1 до 72000;
backup_finalize_timeout - тайм-аут (в секундах), в течение которых RuBackup ожидает финализации бэкапа на платформе виртуализации. Принимает значения от 1 до 3600;
Обязательные параметры только в первой группе: engine; grant_type; username; password; ca_info и timeout. Остальные параметры имеют значение по умолчанию и необязательны для заполнения.
Однако, может возникнуть ситуация, когда необходимо будет менять некоторые параметры. Например, при восстановлении ВМ диски загружаются с хоста виртуализации на хранилище, если диск достаточно большого объема, то значения “disk_upload_timeout” по умолчанию может не хватить, тогда задача восстановления упадет в ошибку. В таком случае нужно установить значение данного параметра на большее значение и перезапустить задачу.
Параметр конфигурации “backup_using_ovirt_api”
Подробнее рассмотрим параметр конфигурации “backup_using_ovirt_api”, как было сказано выше, он принимает два значения “yes” и “no”.
Значение выставлено - “no”, по умолчанию.
При таком значении RuBackup создает резервную копию средствами QEMU KVM. Во время работы бэкапируемой ВМ RuBackup, используя гипервизор QEMU, создает мгновенные снимки дисков - снэпшоты. Бэкапирует диски ВМ и “сливает” снэпшот с оригинальным диском.
Такой подход наиболее простой, но имеет свои недостатки. Например, если администратор системы виртуализации и администратор СРК — это два разных человека, то в то время, когда второй создает бэкапы, первый не знает об этом. В системе виртуализации не остается никаких записей о том, что ВМ была бэкапирована. Такие записи остаются только в RuBackup.
При создании инкрементальной или дифференциальной РК набор изменений, которые произошли в ВМ с момента создания предыдущей РК определяет СРК RuBackup.
Значение выставлено — “yes”.
Если существует необходимость следить за бэкапированием ВМ из системы виртуализации, то можно использовать механизм бэкапа oVirt. В этом случае RuBackup напрямую использует инструменты платформы виртуализации для бэкапирования. Именно платформа отвечает за создание снэпшотов дисков, RuBackup бэкапирует диски и дает сигнал платформе о том, что бэкапирование завершено.
При создании инкрементальной или дифференциальной РК набор изменений, которые произошли в ВМ с момента создания предыдущей РК определяет oVirt, с помощью аналога технологии Change Block Tracking (CBT).
Так в платформе виртуализации остаются записи о взаимодействии с ВМ. На рисунке 2 показано, как выглядит вкладка “События” в веб-интерфейсе oVirt при использовании механизма бэкапа.
Как видно из рисунка 2, в событиях отображены создание снэпшотов платформы и показаны сообщения о удачном начале и завершении бэкапа. Это пример, в рабочей ВМ могут быть и другие сообщения.
Ниже представлен пример заполненного конфиг файла rb_module_ovirt.config.
Использование RuBackup для бэкапа oVirt
Итак, настройка завершена. Теперь у нас есть как минимум один хост виртуализации с установленным клиентом и сервером RuBackup. Запустим сервер и клиент RuBackup, посмотрим лог-файл "/opt/rubackup/log/RuBackup.log" клиента.
Если на этом этапе возникла ошибка и модуль недоступен, проверьте правильность настроек конфигурационного файла и убедитесь, что доступ к платформе oVirt настроен корректно. Чтобы убедится, что модуль настроен корректно, запустите модуль с опцией "-t". После того как убедились, что проверка завершается успешно, необходимо перезапустить сервис клиента RuBackup.
Далее командой “rbm&” на сервере RuBackup откроем RBM, пройдем авторизацию и в окне “Объекты” увидим список клиентов. Нужно выбрать клиента, на который был установлен модуль oVirt. Если выбрана самая простая настройка с клиентом и сервером на одном хосте, то будет доступен один клиент. Ниже изображен выбранный клиент.
RuBackup поддерживает множество настроек бэкапа, но для примера остановимся на самых простых и часто используемых.
Найдем в веб-интерфейсе oVirt ВМ, которую необходимо бэкапировать, например, ВМ, как на рисунке ниже.
Для создания резервной копии этой ВМ выберите клиента "rosa3-virt1.rubackup.test" (имя клиента может быть другим), у которого активен модуль oVirt и нажмите на кнопку со стрелками над клиентом. Поле "Ресурс" заполните ID виртуальной машины. Это можно сделать через список, нажав на иконку с тремя точками справа от поля "Ресурс". Ниже показан интерфейс Срочного РК в RBM.
Как видно выше, в интерфейсе Срочного РК также можно выбрать множество настроек: Пул — в какой пул будет записана РК; какой срок хранения будет у РК и тд
Запустим резервное копирование, нажав кнопку “Применить” в правом верхнем углу интерфейса Срочного РК (рисунок 7). После этого пойдет процесс бэкапа, и во вкладке “Объекты” появится задача.
После удачного завершения задачи на вкладке “Репозиторий” появится РК.
Как видно из рисунка выше, в репозитории резервная копия забэкапленной виртуальной машины имеет ID 6. ID и имя ВМ отображено в столбце “Ресурс”.
Для восстановления РК кликнем ПКМ по РК и нажмем кнопку “Восстановить”, как показано ниже.
Далее откроется окно Централизованного восстановления РК. В нем необходимо указать “Каталог распаковки” и активировать параметр “Восстановить на целевом ресурсе”. У выбранного каталога распаковки должны быть выставлены права “vdsm:kvm”, иначе задача восстановления упадет в ошибку.
В указанном каталоге должно быть от 110 до 210% места от размера оригинальной ВМ (зависит от настроек используемых при бэкапе и настроек, выставленных перед восстановлением), так как в этот каталог будут распаковываться диски ВМ, текстовые файлы конфигурации и служебная информация.
Активировать параметр “Восстановить на целевом ресурсе” необходимо, чтобы запустился процесс деплоя ВМ на платформу oVirt. Если параметр будет не активирован, то РК ВМ распакуется в указанной директории. В ней будут находится диски ВМ и несколько текстовых файлов конфигурации ВМ.
Пример окна Централизованного восстановления РК с заполненными полями изображен на рисунке.
Далее нужно нажать кнопку “Применить” в правом верхнем углу, в поле “Объекты” отобразится новая задача с типом “Restore". Ждем завершения.
Через некоторое время задача перейдет в статус Done, и на платформе появится новая ВМ, восстановленная из резервной копии.
Как видно из рисунка выше, ВМ восстановилась как полноценная новая ВМ с новым именем (к оригинальному имени добавился префикс “_0”) и с новым ID на платформе. Далее ей можно пользоваться как оригинальной ВМ. Для работы с восстановленной ВМ ее необходимо включить и авторизоваться с помощью данных учетной записи из забэкапленной ВМ.
Параметры резервного копирования модуля oVirt
У большинства модулей RuBackup есть дополнительные параметры резервного копирования. Открыть их можно, если во время создания РК (например, в интерфейсе Срочного РК) нажать на иконку с тремя точками справа от поля "Тип ресурса".
Параметр “backup_if_shutdown” является переключателем. Если параметр выключен, то попытка бэкапирования выключенной ВМ завершится с ошибкой. По умолчанию параметр включен.
В качестве параметров “script_before_snapshot” и “script_after_snapshot” необходимо передавать путь до скриптов в гостевой операционной системе бэкапируемой ВМ. Содержимое скриптов определяет пользователь ВМ или администратор системы виртуализации исходя из того, какое ПО работает в гостевой операционной системе бэкапируемой ВМ. Как понятно по названию, переданные скрипты будут выполняться до и после создания снэпшота. По умолчанию параметры не заданы. Параметр “execution_script_timeout” определяет количество секунд отводимое на выполнение скрипта. По умолчанию выполнение скрипта ограничивается 5-ю секундами.
Параметр “require_consistency” является переключателем и используется при использовании “backup_using_ovirt_api yes”. При включенном параметре задача бэкапа упадет с ошибкой, если платформа oVirt не сможет “подморозить” ВМ. Подробнее о параметре можно посмотреть тут. По умолчанию параметр включен.
Параметры восстановления модуля oVirt
Перед восстановлением РК можно задать специфичные настройки для модуля, которые меняют логику восстановления.
В процессе восстановления в окне "Централизованное восстановление" после нажатия на иконку с тремя точками напротив поля “Параметры восстановления для модуля” (см. рисунок 11) откроется окно:
Каждый из параметров “storage_domain” и “cluster” представляют собой выпадающий список, позволяющий выбрать желаемый Storage Domain и Cluster для восстановления ВМ. Например, если ВМ была забэкаплена в Storage Domain типа FCP, можно восстановить в Storage Domain типа iSCSI. Можно таким образом мигрировать ВМ из одного Cluster в другой. По умолчанию параметры выбраны как “ORIGINAL”, то есть при восстановлении будут выбраны Storage Domain и Cluster, как у оригинальной ВМ. Примечание: необходимо выбирать связанные Storage Domain и Cluster, так как каждый Storage Domain находится в определенном Cluster-е, иначе задача восстановление РК ВМ завершится с ошибкой.
Параметр “keep_original_mac” является переключателем. Если переключатель включен - сохраняем MAC адрес оригинальной ВМ при восстановлении, если переключатель выключен - новый MAC адрес автоматически генерируется платформой. Важно понимать, что два одинаковых MAC адреса существовать не могут, поэтому если на платформе существует оригинальная ВМ, то при восстановлении не нужно включать данный параметр. При этом, если переключатель “keep_original_mac” включен, то у ВМ, созданной в процессе восстановления будет отсутствовать сетевой адаптер. По умолчанию переключатель выключен.
Заключение
В статье я рассмотрел, как использовать систему резервного копирования RuBackup, включая установку и настройку модуля oVirt. Привел примеры выполнения резервного копирования виртуальной машины.
RuBackup также предлагает множество дополнительных функций и настроек для более детальной конфигурации. Например, можно использовать правила и стратегии резервного копирования, а также выполнять инкрементальные и дифференциальные бэкапы. Эти методы позволяют сократить размер резервных копий и повысить скорость резервного копирования.
Упомянута тема о поддержке создания инкрементальных РК с помощью встроенного функционала oVirt (аналог CBT). Данный механизм позволяет эффективнее выполнять инкрементальные и дифференциальные РК. Описание работы и примеры использования этого механизма в связке с модулем oVirt для RuBackup ожидайте в следующих статьях!