Новости
- Варіанти резервного копіювання віртуальних машин
- підготовчі заходи
- Налаштування скриптів резервного копіювання
- Відновлення віртуальної машини з резервної копії
Продовжуючи тему резервного копіювання, у цій частині ми розглянемо практичний приклад автоматизації регулярного резервного копіювання віртуальних машин в кластері 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.
***
Налаштуємо 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 з різним об'ємом і різними фізичними дисками.