Snapshots віртуальних машин

1. Резервне копіювання за допомогою знімків VMware
2. Резервне копіювання за допомогою апаратних знімків

Всім відомо, які переваги дають моментальні знімки (snapshots) віртуальних машин VMware. Наприклад, це дозволяє швидко створити точку відновлення працюючої машини. Після цього робити будь-які системні зміни або встановлювати оновлення прикладного програмного забезпечення, і в разі необхідності відкинути редагування до останньої робочої версії системи. Технологія моментальних знімків віртуальних машин дуже важлива для систем резервного копіювання , Тому розробники програмного забезпечення в своїх рішеннях пропонують різні варіанти застосування снапшотов.

Резервне копіювання за допомогою знімків VMware

Використання знімків VMware - найбільш частий на сьогодні метод резервного копіювання віртуального середовища. Створюючи знімок ВМ засобами VMware, такі постачальники, як Veeam, обробляють дані з диска, призначеного тільки для читання, в той час як ВМ продовжує працювати і записує дані в журнали оновлень (redo logs). Звичайний порядок використання знімків ВМ в рішеннях для захисту даних виглядає наступним чином:

1. Зупинка запису даних на диск ВМ (* .vmdk диск), переклад диска в режим читання, створення знімка віртуальної машини
2. Створення журналу оновлень віртуального диска для запису і читання всіх нових або змінених блоків даних. Реєстрація в файлі метаданих журналу змін. Це дозволяє визначити, які блоки були змінені під час створення знімка ВМ. Після створення журналу оновлень сервер резервного копіювання може почати обробку даних на диску, призначеному тільки для читання.
3. Після обробки все нові або змінені блоки з журналу оновлень копіюються на вихідний диск, а журнал оновлень і знімок видаляються.

Природно, чим довше використовується знімок ВМ, тим вище кількість змінених блоків і більше розмір журналу оновлень. Іноді журнали оновлень можуть досягти обсягу вихідного диска ВМ, якщо буде змінено кожен блок даних. Коли одночасно створюється кілька знімків, то може швидко виникнути нестача місця.
Так само в результаті оновлень метаданих і журналу, здійснює велику кількість операцій введення-виведення, отже, збільшується навантаження на сховище.

З урахуванням цього навантаження і можливої ​​нестачі місця в сховищі не рекомендується зберігати знімки ВМ довгий час. Виходячи з цих міркувань, розробники програм резервного копіювання почали шукати інші варіанти вивільнення вихідних
даних ВМ, в тому числі резервне копіювання за допомогою апаратних знімків, яке
дозволяє виконувати копіювати знімки віртуальних машин прямо в сховище.

Резервне копіювання за допомогою апаратних знімків

Розробники таких рішень для резервного копіювання, як Veeam Backup , Veritas NetBackup, Commvault (Simpana) врахували проблеми, пов'язані з миттєвими знімками віртуальних машин засобами гипервизора (VMware), і допрацювали свої рішення, з метою скорочення часу існування знімка. Для цього виробники включили в свої рішення підтримку резервного копіювання програмних снепшот, засобами апаратних знімків сховищ (іноді їх називають знімками SAN або LUN). Крім переваг, які дає скорочення часу використання знімка, апаратні знімки дозволяють скоротити загальний час резервного копіювання. По завершенню роботи не потрібно зливати великі знімки з робочою ВМ, тому система резервного копіювання не використовує стек гипервизора, а підключається прямо до сховища. Резервне копіювання за допомогою апаратних знімків виконується наступним чином:

1. Створюється знімок на рівні ВМ, всі операції запису, як і в першому варіанті, перенаправляються на журнали оновлень, а вихідні диски переводяться в стан «тільки читання».
   «Хоча резервне копіювання виконується на рівні апаратного знімка, знімок ВМ все одно необхідний для забезпечення цілісності додатків операційної системи».
2. Потім створюється апаратний знімок томи LUN (-а), який містить вихідні * .vmdk диски (в стані «тільки для читання») і новостворений знімок засобами гипервизора (VMware).
3. Після цього, як і в першому варіанті, знімок створений засобами VMware в вихідному сховище відразу ж видаляється і віртуальна машина продовжує працює в звичайному режимі, без порушення продуктивності і зменшення місця в сховищі.
4. У свою чергу сервер резервного копіювання вже робить бекап апаратного знімка.
5. Після завершення бекапа, апаратний знімок, створений на другому етапі, також видаляється.
6. Таким чином, за рахунок застосування апаратних знімків, час використання програмних знімків гипервизора (VMware) значно скорочується, рівно стільки скільки необхідно для створення апаратного знімка, що як правило відбувається досить швидко. Після цього знімки будуть видалені.

З огляду на проблеми з продуктивністю і браком місця, а також те, що для однієї ВМ можна зробити до 32 знімків, важливо, щоб система резервного копіювання мала можливість видаляти створені знімки. Іноді vCenter API повідомляє про успішне видалення знімка, але фактично видалення було виконано в повному обсязі. І не важливо, чи було це наслідком помилки API або наслідком обриву зв'язку. Так само іноді на диску залишаються втрачені або невраховані знімки, які не відображаються в vCenter. Тому важливо відслідковувати наявність неврахованих знімків, які були видалені некоректно.

Щоб вирішити це завдання, такі компанії, як Veeam, реалізували функцію опитування середовища, яка дозволяє забезпечити успішне завершення консолідації або видалення знімка. Кожен раз, коли в ході резервного копіювання відбувається злиття або видалення знімка, запускається процедура «Snapshot Hunter». При виявленні неврахованих або фантомних знімків, «Snapshot Hunter» намагаючись видалити знімок відразу по завершенню резервного копіювання ВМ. Якщо видалити знімок при першому проходить не
вдалося, «Snapshot Hunter» автоматично переходить до другого етапу, застосовуючи технології рекомендовані VMware. Якщо і після цього знімки залишилися, «Snapshot Hunter» повідомить користувача про те, що необхідно вживати додаткових заходів.

поділіться з друзями: