Продолжая тему резервного копирования, в этой части мы рассмотрим практический пример автоматизации регулярного резервного копирования виртуальных машин в кластере oVirt 4.0.4, а также посмотрим на процедуру восстановления виртуальной машины из резервной копии.
Варианты резервного копирования виртуальных машин
Исходя из той информации, что мне удалось собрать о возможностях резервного копирования ВМ в oVirt, на данный момент имеется два основных варианта – это либо использовать коммерческие программные продукты сторонних производителей, либо использовать автоматизацию на базе скриптов с применением возможностей oVirt API. При этом, насколько я понимаю, платные решения строятся всё на том же API.
Так как ранее в комментариях был задан вопрос о коммерческих решениях, сделаю небольшое отступление в эту сторону. Информацию о коммерческих решениях мне удалось найти в двух местах:
- На публично доступной странице Red Hat Products & Services - Ecosystem - Certified Software, где среди сертифицированных Red Hat продуктов, что-то более или менее подходящее по смыслу - это Acronis Backup & Recovery 11.5 Virtual Edition for RHEV, но это только для 3 ветки RHEV.
- В документе базы знаний Red Hat с ограниченным доступом (хотя непонятно, зачем было ограничивать доступ к информации такого рода) - How to backup and restore a VM on RHEV
Наберусь наглости и позволю себе процитировать небольшой отрывок из второго документа:
For backing up VMs online:
• From RHEV 3.3 onwards, you can also back up VMs online using the the backup and restore API with a third-party backup software. See The Backup and Restore API in the RHEV REST API Guide for more information. For upstream docs, see http://www.ovirt.org/develop/release-management/features/storage/backup-restore-api-integration/.
• Third-party online backup solutions certified by Red Hat include Acronis, Commvault, SEP, and Veritas (previously part of Symantec Corporation) . See https://access.redhat.com/ecosystem/search/#/vendor/ for more information. Note that third-party products are not supported by Red Hat. Contact the third-party support for more details.
• For Red Hat Virtualization (RHV) 4.0, Commvault and SEP are certified third-party online backup solutions.
То есть, для RHV/oVirt 4 на данный момент подходящим сертифицированным решением будут продукты компаний SEP и Commvault.
Если же говорить о решении, не требующем финансовых затрат на сторонне ПО, то на GitHub доступен набор скриптов wefixit-AT - oVirtBackup. Применение этих скриптов мы и рассмотрим в данной заметке. Данный набор скриптов позволяет выполнять резервное копирование виртуальных машин без остановки этих виртуальных машин и без прерывания работы сервисов внутри гостевых ОС на этих виртуальных машинах.
Общий порядок работы скриптов при резервном копировании каждой отдельно взятой ВМ следующий:
- Для целевой виртуальной машины создаётся онлайн-снапшот;
- Созданный снапшот клонируется в новую виртуальную машину на том же хранилище Data Domain, где расположена целевая ВМ;
- После создания клона, из целевой ВМ удаляется созданный ранее снапшот;
- Выполняется экспорт созданной виртуальной машины - клона в специальное хранилище в виде NFS шары, подключенное к oVirt в качестве Export Domain;
- С основного хранилища Data Domain удаляется созданный ранее клон ВМ.
Далее мы рассмотрим необходимые действия для настройки скриптов резервного копирования.
Подготовительные мероприятия
Скрипты в своей работе используют oVirt Python-SDK, поэтому для начала убедимся в том, что нужный пакет есть в системе на сервере oVirt Engine (насколько я понимаю, этот пакет устанавливается в составе oVirt Engine):
# yum info ovirt-engine-sdk-python
Installed Packages
Name : ovirt-engine-sdk-python
Arch : noarch
Version : 3.6.9.1
Release : 1.el7.centos
Size : 6.8 M
Repo : installed
From repo : ovirt-4.0
Summary : oVirt Engine Software Development Kit (Python)
URL : http://ovirt.org
License : ASL 2.0
Description : This package contains The oVirt-Engine Software Development Kit.
: With this package, custom software can be built for oVirt-Engine.
<
p align="center">***
Настроим NFS сервер для хранения резервных копий виртуальных машин. Создадим отдельную NFS-шару, к которой ограничим доступ - разрешим доступ на чтение и запись в шару только для NFS-клиента с сервера oVirt Engine.
На NFS-сервере создаём каталог для сохранения резервных копий ВМ и меняем для него владельца и группу (36:36 это UID/GID vdsm:kvm):
# mkdir -p /mnt/mdadm-vv1/nfs/ovirt-vm-backup # chown -R 36:36 /mnt/mdadm-vv1/nfs/ovirt-vm-backup # chmod 755 /mnt/mdadm-vv1/nfs/ovirt-vm-backup
Добавляем в конфигурационный файл /etc/exports запись о NFS-шаре, доступ к которой разрешаем для всех допустимых NFS-клиентов (хостов виртуализации в кластере oVirt) с назначением для всех подключающихся NFS-клиентов UID/GID равными также 36:36:
/mnt/mdadm-vv1/nfs/ovirt-vm-backup KOM-AD01-VM3*.holding.com(rw,sync,no_subtree_check,all_squash,anonuid=36,anongid=36)
Заставляем службу nfs-server перечитать конфигурацию и проверяем результат:
# exportfs -r
# exportfs
...
/mnt/mdadm-vv1/nfs/ovirt-vm-backup
KOM-AD01-VM3*.holding.com
...
Переходим на веб-портал администрирования oVirt в раздел Storage и добавляем Export Domain, указав путь в ранее созданной NFS-шаре на файловом сервере
Теперь можно переходить к настройке скриптов резервного копирования.
Настройка скриптов резервного копирования
Загружаем и распаковываем скрипты на сервер oVirt Engine:
# wget https://codeload.github.com/wefixit-AT/oVirtBackup/zip/master -O /usr/local/sbin/oVirtBackup.zip # unzip /usr/local/sbin/oVirtBackup.zip -d /usr/local/sbin/ # rm -f /usr/local/sbin/oVirtBackup.zip # mv /usr/local/sbin/oVirtBackup-master /usr/local/sbin/ovirt-vm-backup
Таким образом скрипты резервного копирования будут размещаться в каталоге /usr/local/sbin/ovirt-vm-backup.
***
Создаём конфигурационный файл, скопировав его из шаблона config_example.cfg:
# cp /usr/local/sbin/ovirt-vm-backup/config_example.cfg /usr/local/sbin/ovirt-vm-backup/config.cfg # nano /usr/local/sbin/ovirt-vm-backup/config.cfg
Настраиваем параметры конфигурационного файла. В шаблоне все параметры имеют небольшие комментарии, поэтому несложно понять какой параметр за что отвечает. Привожу пример уже настроенного конфигурационного файла без комментариев:
[config] vm_names: ["KOM-AD01-APP31"] vm_middle=_BACKUP snapshot_description=Snapshot for backup script server=https://kom-ad01-ovirt1.ad.ies-holding.com/ovirt-engine/api username=admin@internal password=P@ssw0rd export_domain=NFS-VM-BACKUP timeout=5 cluster_name=Default backup_keep_count=3 dry_run=False vm_name_max_length=64 use_short_suffix=False storage_domain=3PAR-VOLUME2 storage_space_threshold=0.1
В параметре vm_names для начала указываем одну какую-нибудь не особо критичную виртуальную машину. Красным цветом я подкрасил те параметры, которые были в моём случае изменены.
Так как в данном файле мы сохраняем учётные данные локального администратора oVirt, то желательно ограничить доступ к этому файлу:
# chmod 600 /usr/local/sbin/ovirt-vm-backup/config.cfg
***
Посмотрим, какие параметры имеет текущая версия главного скрипта, который вызывается для запуска задач резервного копирования:
# /usr/local/sbin/ovirt-vm-backup-master/backup.py -h Usage: backup.py -c[-a] [-d] [-h] -c Path to the config file -a Backup all VM's and override the list of VM's in the config file -d Debug flag -h Display this help and exit
Как видим, скрипт может выполняться с явным указанием того или иного конфигурационного файла. И это хорошо, так как добавляет дополнительную гибкость в случае необходимости настройки резервного копирования разных виртуальных машин по разным правилам.
Выполним проверочный запуск скрипта с ранее настроенным нами конфигурационным файлом, включив дополнительно флаг отладки:
# /usr/local/sbin/ovirt-vm-backup/backup.py -c /usr/local/sbin/ovirt-vm-backup/config.cfg -d
Oct 05 17:44:04: Start backup for: KOM-AD01-APP31 Oct 05 17:44:05: Snapshot creation started ... Oct 05 17:44:08: Snapshot operation(creation) in progress ... Oct 05 17:44:19: Snapshot created Oct 05 17:44:29: Clone into VM started ... Oct 05 17:44:33: Cloning in progress ... Oct 05 17:45:08: Cloning finished Oct 05 17:45:09: Found snapshots(1): Oct 05 17:45:09: Snapshots description: Snapshot for backup script, Created on: 2016-10-05 17:44:08.258000+03:00 Oct 05 17:45:09: Snapshot deletion started ... Oct 05 17:47:14: Snapshot operation(deletion) in progress ... Oct 05 17:47:19: Snapshots deleted Oct 05 17:47:19: Export started ... Oct 05 17:47:22: Exporting in progress ... Oct 05 17:49:40: Exporting finished Oct 05 17:49:40: Delete cloned VM started ... Oct 05 17:49:43: Cloned VM deleted Oct 05 17:49:43: Duration: 5:39 minutes Oct 05 17:49:43: VM exported as KOM-AD01-APP31_BACKUP_20161005_174404 Oct 05 17:49:43: Backup done for: KOM-AD01-APP31 Oct 05 17:49:43: All backups done
Как видно, все ранее описанные этапы работы скрипта прошли успешно. В ходе работы скрипта в веб-консоли oVirt можно наблюдать появление снапшота для целевой виртуальной машины, из которого в последствии создаётся временная клонированная ВМ для последующей выгрузки в Export Domain
В завершающей стадии временная виртуальная машина и снапшот, из которого она была сделана удаляются. На протяжении всего процесса резервного копирования гостевая ОС виртуальной машины продолжает работать.
Убедившись в том, что резервное копирование одной виртуальной машины отработало успешно, возвращаемся в конфигурационный файл config.cfg и дополняем список всеми машинами, которые мы хотим на регулярной основе подвергать резервному копированию.
... vm_names: ["KOM-AD01-APP31","KOM-AD01-APP32","KOM-AD01-WEB01"] ...
При этом, как я уже заметил ранее, если для некоторых машин требуется какая-то иная конфигурация резервного копирования, например, сохранение в какой-то другой выделенный Export Domain или увеличенный/сокращённый срок хранения копий, то для таких ВМ мы просто настраиваем дополнительные конфигурационные файлы по аналогии с config.cfg.
***
Теперь нам нужно настроить периодическое выполнение скрипта резервного копирования. Создадим для этого файл задачи cron:
# nano -Y sh /etc/cron.d/ovirt-vm-backup
Наполним его содержимым таким образом, чтобы наш скрипт выполнялся, например, раз в сутки по ночам, сохраняя при этом весь отладочный вывод в лог-файл:
# Regular cron job for the oVirt VMs full backup 10 00 * * * root /usr/local/sbin/ovirt-vm-backup/backup.py -c /usr/local/sbin/ovirt-vm-backup/config.cfg -d >> /var/log/ovirt-vm-backup/ovirt-vm-backup.log
***
Настроим логирование. Создадим каталог для лог-файлов:
# mkdir /var/log/ovirt-vm-backup
А также создадим файл правил ротации логов для утилиты logrotate:
# nano -Y sh /etc/logrotate.d/ovirt-vm-backup
Наполним файл примерно следующим содержимым:
/var/log/ovirt-vm-backup/*.log {
daily
rotate 30
compress
delaycompress
missingok
notifempty
}
Теперь ежедневно будет создаваться новый лог-файл со сжатием старых логов, при этом будет сохраняться не более 30 предыдущих сжатых файлов.
Восстановление виртуальной машины из резервной копии
Теперь рассмотрим практический пример процедуры восстановления отдельно взятой виртуальной машины. Для восстановления будем использовать туже виртуальную машину, которая ранее фигурировала в процессе создания резервной копии – KOM-AD01-APP31.
На веб-портале администрирования oVirt на закладке Storage выберем Export Domain, который мы ранее делали для сохранения резервных копий виртуальных машин и переключимся на вкладку VM Import
Здесь мы увидим информацию о всех копиях виртуальных машин, которые сделаны нашим скриптом резервного копирования. Каждая копия при этом будет иметь в имени отметку времени создания. Здесь можно выбрать ту копию, которую мы хотим восстановить и нажать кнопку Import.
В открывшейся форме импорта, выбрав закладку General мы сможем при желании изменить имя создаваемой при восстановлении виртуальной машины. При этом имя импортируемой ВМ не должно совпадать с именами существующих в кластере виртуальных машин, иначе oVirt попросту откажет нам в импорте.
Параметры, перечисленные на других закладках, на данный момент носят исключительно информативный характер и не имеют возможности корректировки. После нажатия кнопки ОК в форме импорта виртуальной машины мы получим сообщение о том, что окончание процедуры импорта можно отследить на закладке Events
В итоге в перечне виртуальных машин появится восстановленная нами копия с указанным ранее именем в выключенном состоянии. И тут нужно обратить внимание на одну немаловажную вещь. Если вы сравните MAC-адресы виртуальных сетевых интерфейсов исходной и восстановленной из копии виртуальных машин, то сможете заметить то, что они различаются. При импорте виртуальной машины oVirt автоматически назначает новые MAC-и из своего пула, чтобы свести к минимуму возможность конфликтов с другими ВМ.
В некоторых случаях это может привести к тому, что если сразу включить восстановленную виртуальную машину, то в гостевой ОС может потребоваться дополнительная настройка сети, так как виртуальный сетевой адаптер с новым MAС-адресом будет распознан как новое устройство. Если мы хотим оставить для восстановленной ВМ новый MAC адрес, то тогда возможно будет полезен ранее описанный способ изменения настроек сетевых интерфейсов в гостевой ОС, чтобы потом не пришлось менять настройки TCP/IP. Если же мы хотим использовать для восстановленной ВМ тот же MAC-адрес, который был у оригинальной ВМ, то перед запуском ВМ с помощью кнопки Edit можно будет задать нужное значение.
При этом нужно помнить про то, что старый MAC, который мы хотим назначить восстановленной ВМ, не должен быть использован ни на какой другой ВМ в oVirt, то есть если старая ВМ всё ещё не удалена, то ей придётся задать предварительно какой-нибудь другой MAC, чтобы освободить нужный нам MAC-адрес. В противном случае oVirt нам попросту не даст произвести замену адреса.
Теперь мы можем запустить нашу восстановленную виртуальную машину и убедиться в том, что она работает с прежними сетевыми настройками и как и раньше доступна по сети.
Всё что нам останется сделать, это проверить работоспособность всех значимых для нас сервисов внутри гостевой ВМ и удалить старую ВМ, если она ещё не была удалена ранее.
***
Таким образом, один раз настроив резервное копирование виртуальных машин на стороне сервера oVirt Engine, мы получаем вполне жизнеспособный функционал последующего управления резервными копиями непосредственно из веб-консоли администрирования oVirt. И это хорошо.
Единственным, существенным на мой взгляд, недостатком в данном способе резервного копирования ВМ является невозможность инкрементального копирования, что, при использовании ВМ с дисками большого объёма может привести к необходимости наличия существенного объёма дисковых ресурсов под резервные копии, хранимые в Export Domain. Однако не стоит забывать и про то, что выше рассмотренный скрипт резервного копирования можно вызывать с разными настройками для разных виртуальных машин, например машины малого объёма хранить большее количество дней, а машины большого объёма – меньшее количество дней. При этом также можно использовать разные хранилища Export Domain с разным объёмом и разными физическими дисками.
RSS - Записи
Отлично описанная процедура. Собственно у нас так и работает. И мы испытываем трудности по времени резервирования, точнее не по самому времени резервирования, а по времени экспорту клонов в хранилище. Ну и конечно нет невозможность инкрементального копирования, как в принципе и компрессии, последнее конечно можно делать тем же скриптов, но это уже не будет вариант, который можно сразу же импортировать из экспорт домена, да и время будет потрачено на компрессию. В общем время как всегда не хватает.
Может быть возможно как-то распараллелить процесс экспорта, используя не один Export Domain а несколько.
Дело в том, что Export Domain может быть только один (
Хм. Об этом я не знал. Удручает.
export domains скоро вообще отменят. обычные домены будут уметь все то же самое
Скорее всего проблему можно решить через интеграцию с cinder или вручную, но о готовых решениях я не знаю.
Кстати SEP работает и с версией 3.6. Мы его тестили на этой версии.
Если кого-то заинтересует: http://download.sep.de/testing/
Для экономии места можно развернуть NFS сервер на Windows Server 2012 R2 с включенной дедупликацией. Тогда по идее проблемы со свободным местом не будет.
Для этого нужен отдельный физический сервер, которому потребуется лицензия Windows Server. Не очень привлекательный вариант. Я вот начинаю подумывать, а не замахнуться ли на что-нибудь типа OpenDedupe для тома, который используется под Export Domain (для хранения бэкапов ВМ) и ISO Domain.
Спасибо за замечательную серию статей, с нетерпением жду продолжения, на пример про мониторинг всего этого богатства и про GlusterFS.
А пока вопросы :) :
1. "Созданный снапшот клонируется в новую виртуальную машину на том же хранилище Data Domain, где расположена целевая ВМ;"
А клон занимает столько же места на "том же" хранилище? Если да, то получается нужно держать двойной объем резерва, а то и больше, если конечно можно делать параллельные бекапы или вдруг клоны не успели или не захотели удалиться по какой-то причине иначе просто может кончиться место га хоанилище?
И можно ли сразу клонировать на бекап сервер, чтобы избежать переполнения хранилища?
2. "chmod 755 /mnt/mdadm-vv1/nfs/ovirt-vm-backup"
Если у нас к экспорту подключаются под 36:36, может можно хотябы 750 поставить?
Про мониторинг возможно что-то будет в перспективе (с выбором платформы для мониторинга Linux-систем пока не определился). С GlasterFS точно связываться не буду, так как вполне хватает имеющихся FC СХД.
По вопросам:
1) Насколько я понимаю, клон занимает столько же места, ведь это по сути полная копия исходной виртуальной машины. Необходимый запас будет рассчитываться исходя из того, как именно будет настроено резервное копирование. В рассмотренном примере последовательно бэкапятся все виртуальные машины перечисленные в параметре vm_names, то есть запас сводного места в таком случае должен быть, как минимум, равен размеру самой объёмной виртуальной машины из списка vm_names. С распараллеливанием пока всё грустно (комментарии выше). Сам не совсем понимаю зачем в oVirt создано ограничение в виде единственного Export Domain. В конфиге скрипта резервного копирования есть параметр storage_space_threshold. Он используется скриптом для того, чтобы дополнительно предварительно проконтролировать объём свободного места на Storage Domain.
2) Вроде бы не подключался у меня Export Domain с такими разрешениями. К тому же в гайде по траблшутингу nfs приведены именно такие права
http://www.ovirt.org/documentation/how-to/troubleshooting/troubleshooting-nfs-storage-issues/
распаралелить экспорт ВМ, можно если процесс бекапа выполнять в нескольких потоках, одновременно бекапить несколько ВМ, а не последовательно, как в данном скрипте.
1. В описанных выше скриптах используется API функционал, который в свою очередь передает движку команды, которые могут быть исполнены. Функционал движка не позволяет производить экспорт виртуальных машин во включенном состоянии, поэтому и делается клон, а затем уже экспорт клона.
Сори, не совсем верно я сказал, но смысл тот же. Функционал движка не позволяет производить экспорт, когда вы сделали снапшет (произвести экспорт можно только для выключенной ВМ), однако позволяет вам при клонировании указать нужный вам датастор (который вы к примеру специально подключили для задач при создании резервных копий). Ну в общем это в итоге на время никак не влияет, т.к. все равно есть задача которая выполняется последовательно.
К снапшотам претензий нет, там механизм понятен.
Я так и не понял.
"И можно ли сразу клонировать на бекап сервер, чтобы избежать переполнения хранилища?"
Или клонировать на еще один промежуточный NFS datastore или этот промежуточный будет тоже считаться "Export Domain"?
В принципе да). Можно подключить к примеру несколько nfs (ну или не nfs) датадоменов (data_backup1...data_backupN) и туда клонировать после создания снапшета ВМ при этом в имени создавая префикс ВМ_date. И тогда у вас в этих датадоменах будут копии ВМ, которые можно даже сразу запускать на различных хостах, т.к. эти датадомены там будут смонтированы))) Но для хорошей производительности при даже допустим одновременном запуске задач из крона по созданию клонов необходимо иметь разные физически дисковые подсистемы, так как объем данных при таком параллелизме туда будет пихаться ровно такой какие и сами машины.
Но учтите, что при такой схеме все эти клоны с датой будут видны вам как остановленный ВМ, т.е. если у вас к примеру около 50 ВМ, и вы все их бэкапити каждый день и храните 3 последних копии, то у вас в консоли будет мрак))) 200 виртуалок, 150 из которых это всего лишь ваш бэкап ))
Павел, извеняюсь за назойливость.
Я правильно понял, что я могу сделать клон сразу на nfs шару бекап сервера, на которую по данной инструкции мы делаем экспорт клона и по факту экспорт виртуалки будет моментальным т. к. клон будет уже лежать на ней?
Ничего страшного)))
Есть датадомен, а есть экспортдомен - это два разных типа доменов храниния и служат они для разных целей. В инструкции мы делаем снапшет, из снапшета клон, а затем грубо говоря перемещаем этот клон (т.е. 2 раза копируем одни и теже данные). ВМ в экспортдомене не отображается в списке ВМ датацентра к которому принадлежит экспортдомен - это "+", но для её запуска необходимо её импортировать в любой датадомен - это "-" (т.к. увеличивает время восстановления). Этим "+" и "-" неограничиваются, просто концептуально эти домены хранения имею разные цели. Можно не перемещать клон в экспортдомен после его создания, а так же не обязательно делать клон в том же датадомене в котором основная ВМ.
Главное это:
Создание клона - это процесс копирования всей ВМ (т.е. это не моментальное действия, по сравнению например с созданием снапшета).
Процесс экспорта ВМ - это тоже процесс копирования всей ВМ.
Даже если они будут в одном хранилище, но на разных диска - все равно двойное копирования, и даже если эти диски в одном массиве и там включена дедупликация на уровне массива, а вы разделили массив на 2 луна и отдали 1 для клона, 2 для экспорта -копирования вам не избежать - но эта система уже грабли какие то )))
Если мы после создания клона в любом подключенном нами датадомене его там оставляем, то он отображается в списке ВМ датацентра - это крайне не удобно (об этом я выше писал).
1. Я правильно понял, что я могу сделать клон сразу на nfs шару бекап сервера
Да можете, но получите то, что выше описано
2. на которую по данной инструкции мы делаем экспорт клона
Не совсем так я выше попытался объяснить
3. и по факту экспорт виртуалки будет моментальным т. к. клон будет уже лежать на ней
Нет это не так, как бы и это я попытался объяснить
Не стесняйтесь - спрашивайте. ))
Ну в принципе понятно, спасибо.
Надо будет поподробнее где-нибудь почитать про типы доменов.
Но на мой (первый) взгляд эта схема костыль. В vmware на датасторе может лежать что угодно, а виртуалки добавляются ручками.
Тут кстати вполне здравая идея - использовать tags, и отображать в UI только определенные метки, а остальные (бекапы) просто не показывать.
Еще как вариант, можно выдирать машины прямо из дата доменов на отдельно стоящий дата домен, который не был создан оВирт, и при надобности делать из него экспорт и цеплять к системе. Вообще вариантов много, надо только сесть и написать под них код
С выходом Ovirt 4.1 этот скрипт перестанет работать, в рассылке овирта предлагают использовать https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/vm_backup.py Кто нибудь пробовал использовать?
Здравствуйте, Денис. Спасибо за информацию. А откуда информация о том, что скрипт перестанет работать? Да и потом, релиз 4.1 всё же еще не вышел.
SDKv3 уходит с 4.1, наверное поэтому
Релиз 4.1 объявлен, но в Release Notes нет информации о том, что SDKv3 больше не поддерживается.
Здравствуйте, Алексей из рассылки ovirt-users процитирую ответ на вопрос одного из пользователей
"Nathanaël Blanchet кому: users
Ещё
30 янв.
Hello,
With ovirt 4.0, jhernandez has recently posted a new python script based on the new v4 API : https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/vm_backup.py
I personnally didn't try it, maybe someone could give a feedback.
…
--
Nathanaël Blanchet
Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5
Tél. 33 (0)4 67 54 84 55
Fax 33 (0)4 67 54 84 14
blanchet@abes.fr "
Возможно я поторопился с выводами и им просто не рекомендуется пользоваться в 4.1
может и нет, но я знаю что v3 скоро должен уйти, не в 4.1 так в 4.2, так что я бы ничего долгосрочного на нем не завязывал
Мне кажется эти скрипты нужно опубликовать на GitHub и написать базовый README на английском. Это будет полезно десяткам админов oVirt, так как сейчас каждый пишет свой костыль.
https://github.com/wefixit-AT/oVirtBackup
ыыы, спасибо, надо было читать внимательней :)
ovirt 3.6. Скрипт зависает на стадии удаления снепшота у целевой ВМ, потомучто снепшоты не удаляются у запущенной ВМ. Не понятно, как у нарола этот скрипт работает?
oVirt 3.4 - ситуация аналогичная.
detail: Cannot remove Snapshot. At least one of the VMs is not down.
В 3.4 на уровне гипервизора вообще нет такой возможности:
https://www.ovirt.org/develop/release-management/features/storage/live-merge/
В более новых версиях, вероятно, нужны гипервизоры не ниже el7 с правильными версиями libvirt и qemu.
Не дочитал, спасибо =)
серверы старые, el7 не поставить, ладно будем думать костыли =)
Я нашел новый способ, написал пост насчет самого примитивного использования, и собираюсь развить на более сложные случаи: https://dyasny.blogspot.ca/2017/06/exploring-backup-options-for-rhvovirt.html
Во первых, большой респект автору. Перечитал все статьи из цикла про ovirt - грамотно, толково и по делу.
Развернул кластер на базе дистрибутива ovirt 4.1.2 - данный скрипт работает без проблем.
Очень хорошо описано пробовал, реально работает. Единственно это будет работать только для тестов с легкими машинками по 10-30гб если машина весит около 500гб, ее бэкап описанный тут займет часов 5. В Ovirt вообще очень тяжело и нереально долго выполняет задачи если машины весят больше 100гб. Клон созданного snapshot-a с машины в 300гб у меня делался полтора часа, при этом если машина нагружена он на ней пишет image locked на вм появляется замок и она становится не доступной на время пока ovirt не закончит, а когда он закончит одному богу известно потому что сколько осталось времени или хотя бы вывод в процентах разработчики посчитали ненужным выводить нигде эту информацию. В принципе это неудивительно потому что в принципе все действия с тяжелыми ВМ, oVirt может выполнять только в теории, даже самую обычную миграцию с хоста на хост к примеру sql сервера не выключая его выполнить невозможно.
У вас тормозит сеть, и возможно диски тоже. Овирт не способен нарушать законы физики, и если ваша сеть позволяет переписать 500Гб только за час, то нечего удивляться когда процесс занимает именно столько.
С миграцией то же самое, если машина нагружена и ее память меняется быстрее чем гипервизоры способны синхронизироваться, то миграция не пройдет.
Это верно для ЛЮБОЙ системы виртуализации.
Добрый день! Подскажите пожалуйста, есть ли какой-то вариант бекапить только определенный диск ВМ. На основном диске АТС, а на втором записи разговоров, которые не страшно потерять.
Здравствуйте, Alex.
Базово в рассмотренном в статье скрипте wefixit-AT/oVirtBackup нет возможности исключить определённые диски для какой-либо ВМ. Но Вы можете задать вопрос разработчику скрипта. Похожий вопрос задавался ему здесь https://github.com/wefixit-AT/oVirtBackup/issues/48, но был слит из-за отсутствия активности вопрошающего.