Резервне копіювання і відновлення

Коли ми говоримо про резервне копіювання і відновлення в контексті vSphere, то перше, з чим варто визначитися, – резервне копіювання чого саме нам необхідно

Варіанти:

Q налаштування ESX

Q налаштування ESXi

Q настройки і дані vCenter

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

Поговоримо спочатку про інфраструктуру

Практично все важливе для vCenter зберігається в базі даних У разі втрати БД vCenter ви втратите настройки кластерів і пулів ресурсів в DRS-кластерах, а також розподілених віртуальних комутаторів

Для здійснення резервного копіювання БД vCenter використовуються звичайні засоби резервного копіювання бази даних використовуваного у вас типу

Крім резервного копіювання БД, слід робити копії сертифікатів та файлу налаштувань vpxdconf

Необхідність організації резервного копіювання серверів багатьма адміністраторами ставиться під сумнів Найчастіше перевстановити сервери з нуля і зробити нечисленні, як правило, налаштування займає порівнянне кількість часу з самим по собі відновленням з резервної копії Тим більше якщо компанія використовує механізм Host Profiles, який дозволить частина

налаштувань підняти з профілю Притому саму неприємну у відновленні частина – налаштування віртуальних комутаторів мережевого екрану

Проте якщо здійснювати резервне копіювання ESX хочеться, то здійснити це можна як для звичайної ОС:

Q зняти образ системного диска

Q зробити резервну копію конфігураційних файлів Для ESX це означає копію каталогу / etc Здійснювати резервне копіювання можна сценарієм чи агентом резервного копіювання, який вміє працювати в Service Console ESX (проте такий сценарій резервного копіювання не дозволені з боку VMware)

Якщо поставлено завдання здійснювати резервне копіювання ESXi, то зробити це можна наступною командою vSphere CLI:

vicfg-cfgbackuppl –server  esxi2vm4ru –username  root   –password  secretpass  -s r:\ esxi2cfg

Для відновлення підійде

vicfg-cfgbackuppl –server  esxi2vm4ru –username  root   –password  secretpass  -l r:\ esxi2cfg

Хочу нагадати, що завантажувальний образ ESXi розташовується на диску в двох копіях Якщо ESXi НЕ стартує, то можна спробувати завантажитися з резервного образу Для цього при старті ESXi (коли побачите Loading VMware Hypervisor ..) натисніть Shift+R

У нас є кілька підходів до резервного копіювання віртуальних машин Тут я коротко опишу кожен з них

Крім підходів, у нас є варіанти того, резервну копію чого ми хочемо зробити

Обєктами резервного копіювання можуть бути файли гостьовий ОС і файли віртуальної машини

Файли віртуальної машини Якщо ми створимо резервну копію файлу vmdk, то ми створимо резервну копію всіх даних ВМ Такий підхід називається image level backup (але тут не мається на увазі зняття образу за допомогою ПО, запущеного всередині віртуальної машини, такого як Ghost або Acronis)

Умовні плюси:

Q легко налаштувати резервне копіювання, легко відновити ВМ

Умовні мінуси:

Q потрібно багато місця для зберігання резервних копій

Q багато даних треба передавати по мережі

Файли гостьовий ОС Ще ми можемо звертатися до даних віртуальної машини на рівні файлів гостьовий ОС Такий підхід називають file level backup

Умовні плюси:

Q можемо забирати лише частину даних, змінених з останнього сеансу резервного копіювання

Q відновлюємо тільки необхідні дані

Умовні мінуси:

Q можливо не для всіх ОС, звичайно тільки Windows

Плюси і мінуси тут «умовні» тому, що серед коштів резервного копіювання спостерігається велика різноманітність за функціями і можливостям Наприклад, VMware Data Recovery, незважаючи на те що резервне копіювання здійснюється саме на рівні vmdk-файлів, може здійснювати інкремен тальне копіювання на рівні змінених блоків цього vmdk

Зверніть увагу, що практично для будь-яких рішень резервного копіювання актуальна проблема цілісності даних (крім агента в гостьовій ОС, який її розвязує своїми способами) Поясню, у чому справа:

1 Для здійснення резервного копіювання працює ВМ ПО резервного копіювання створює знімок стану (snapshot)

2 Віртуальна машина продовжує працювати, але її файл vmdk тепер не змінюється, всі зміни пишуться в deltavmdk

3 Основний файл vmdk ми можемо копіювати або подмонтіровать до зовнішньої системи, для копіювання даних

4 Однак у момент створення знімка частина файлів гостьовий ОС буде відкрита і не дописана на диск, в памяті можуть висіти незавершені транзак ції і незбережені дані програми – і у файлі vmdk ці дані у відриві від даних в ОЗУ ВМ недостатні, нецільні, некоректні А додатка резервного копіювання звертаються тільки до файлу vmdk, не звертаючись до вмісту памяті Таким чином, резервне копіюв вання без механізмів забезпечення цілісності даних, швидше за все, не підійде для баз даних і взагалі будь-яких файлів зі складною структурою, які читаються і записуються на диск не цілком, а частинами Дуже велика ймовірність того, що після відновлення така копія бази даних виявиться повністю або частково непрацездатною

Для вирішення цієї проблеми VMware tools дозволяють звернутися до служби Volume Shadow Copy Services, VSS VSS запитує у гостьовій ОС і приложе ний в ній (що підтримують VSS) створення «контрольної точки »- тобто коректне збереження на диск всіх даних, які знаходяться в роботі на поточний момент У момент «контрольної точки» робиться знімок стану (snapshot), і дані в цьому знімку знаходяться в завершеному і цілісному стані Сам процес створення знімка проходить прозоро для додатків, так як нормаль-

ная робота з диском після створення «контрольної точки» не переривається Але всі зміни, вироблені після створення «контрольної точки», в знімок стану вже не потрапляють Таким чином, для додатків з підтримкою VSS забезпечується консистентность на рівні даних програми

Для додатків, VSS що не підтримують, VMware пропонує компонент Sync driver, який забезпечує цілісність даних на рівні гостьовий ОС, за рахунок скидання на диск всіх буферів операційної системи Це менш ефективне рішення за рахунок того, що воно не здатне забезпечити цілісність даних на рівні додатку Sync driver доступний також не для всіх ОС

Однак VMware tools можуть запускати довільні сценарії до і після створення знімка стану Якщо налаштувати в цих сценаріях зупинку і наступний старт програми, то, особливо разом з sync driver, можна отримати знімок стану ВМ з цілісними даними на диску

Для Windows ВМ сценарій повинен бути розташований в каталозі С: \ Program Files \ VMware \ VMware Tools \ backupScriptsd Запускатися буде перший за алфавітом файл При запуску даного сценарію перед створенням знімка стану він буде запущений з аргументом «freeze»

Сценарій, відробляє після створення знімка, повинен розташовуватися в тому ж каталозі і бути останнім за алфавітом При запуску даного сценарію після створення знімка стану він буде запущений з аргументом «thaw» або

«FreezeFail», залежно від того, чи було створення знімка успішним

Приклад такого сценарію для резервного копіювання ВМ з MySQL:

IF  &quot%1%&quot  == &quotfreeze&quot  goto  doFreeze goto  postThaw

:postThaw

IF  &quot%1%&quot  == &quotthaw goto  doThaw goto  fail

:doFreeze

net  stop  mysql goto  EOF

:doThaw

net  start  mysql goto  EOF

:fail

echo &quot$ERRORLEVEL%  &gt&gt  vcbErrortxt

:EOF

У цьому сценарії обєднані дії перед знімком і після знімка У вказаному каталозі він має бути єдиним, щоб бути і першим, і останнім за алфавітом

Подробиці шукайте в «Virtual Machine Backup Guide»

Тепер поговоримо про підходи до організації та способи резервного копіювання Перше, про що згадаємо, – резервне копіювання на якому рівні можливо для того чи іншого підходу

Зверніть увагу на табл 73

Таблиця 73 Звязок підходів і типів резервного копіювання

Копіювання файлів ВМ

Копіювання файлів гостьовий ОС

Агент в гостьовій ОС

+

Засоби без підтримки VCB / vStorage API for Data Protection

+

Засоби з підтримкою VCB / vStorage API for Data Protection

+

+

У заголовку таблиці ви бачите підходи, описані вище У лівому стовпчику – способи організації резервного копіювання, про які подібно поговоримо нижче На перетині позначені можливості того або іншого підходу до резервного копіювання Наприклад, при резервному копіюванні агентом в гостьовій ОС в якості даних для резервного копіювання можуть виступати лише файли гостьовий ОС, але не файли віртуальної машини

Засоби з підтримкою VCB / vStorage API відрізняються великою різноманітністю, тому їх характеристики в даній таблиці небагато умовні, якісь конкретні рішення можуть не підтримувати резервне копіювання і file-level, і image-level Наприклад, VMware Data Recovery здійснює резервне копіювання тільки на рівні image, а ось відновлення може відбуватися і на рівні окремих файлів гостьовий ОС

Ми можемо здійснювати резервне копіювання віртуальних машин так само, як ми робимо це для наших фізичних серверів, – встановивши агент резервного копіювання в гостьову ОС

Плюси цього підходу:

Q після перенесення інфраструктури в ВМ можна використовувати стару схему резервного копіювання без змін

Q єдина схема резервного копіювання для всієї інфраструктури – і фізкабінет-

чеський, і віртуальної

Q здійснювати резервне копіювання можна для всього, що підтримується агентами, при можливості задіюючи специфічні можливості або особливості додатків

Мінуси:

Q подібна схема не задіює можливості по оптимізації резервного копіювання, які надають віртуалізація і vSphere

Q агенти коштують грошей

Такий тип резервного копіювання дозволяє здійснювати резервне копіювання тільки на рівні файлів гостьовий ОС

Як правило, цю категорію можна ще назвати «Кошти, які не підтримують VCB або vStorage API for Data Protection» Із вартого уваги безкоштовного ПЗ звертаю вашу увагу на Veeam FastSCP Сценарії шукаються в Інтернеті, наприклад тут: http://communitiesvmwarecom/docs/DOC-10780

Плюси:

Q дешево або безкоштовно

Мінуси:

Q сценарії або ПЗ, що працюють в Service console, створюють навантаження на ESX На ESXi подібне ПЗ не буде працювати

Q можуть знадобитися великі зусилля для адміністрування такого рішення

Q сценарії доведеться або написати, або шукати Знайдені готовими сценарії під ваші умови можуть не підійти

За допомогою цього варіанту вам буде доступно, швидше за все, тільки резервне копіювання на рівні файлів vmdk віртуальної машини

Це сама широко представлена ​​категорія Тут ми поговоримо про сторонні кошти резервного копіювання спеціально для vSphere, про рішення VMware для резервного копіювання – VMware Data Recovery і про те, як VMware дозволяє віртуальні машини сторонніх засобів резервного копіювання, що не спеціалізуються на vSphere

Рішення резервного копіювання немає від VMware, спеціалізовані під vSphere Вибір серед засобів резервного копіювання саме під інфраструктуру від VMware досить обширний Щоб було з чого почати, згадаю популярний продукт, що розробляється спеціально для резервного копіювання vSphere: Veeam Backup & Replication

Плюси засобів цієї категорії:

Q закінчене рішення резервного копіювання

Q оптимізовано саме на резервне копіювання віртуальних машин

Q не вимагає установки агентів в ВМ Мінуси:

Q окреме рішення, саме для резервного копіювання віртуальної

середовища

Q коштує грошей

Q не всі рішення працюють з стрічковими накопичувачами

Втім, різноманітність підтримуваних функцій тут достатньо велике, так що з безумовних плюсів і мінусів тут хіба що ненульова ціна

Залежно від рішення вам буде доступно або резервне копіювання тільки на рівні файлів віртуальної машини, або ще й на рівні файлів гостьовий ОС

Рішення резервного копіювання від VMware Це продукт під назвою VMware Data Recovery Поставляється у вигляді Virtual Appliance, віртуальної машини з передвстановленою ОС і ПЗ

Плюси:

Q просто впровадити – всього лише імпортувати віртуальну машину

Q налаштувань мінімум

Q інтерфейс і резервного копіювання, і відновлення інтегрується в клієнт vSphere

Q резервне копіювання здійснюється на рівні файлів vmdk, але підтримується инкрементальное резервне копіювання, на рівні змінених блоків даних

Q для гостьових ОС Windows і Linux підтримується відновлення на

рівні окремих файлів гостьовий ОС

Q VDR здійснює Дедуплікація резервних копій

Q ліцензія на DR входить в багато ліцензії vSphere

Мінуси:

Q налаштувань мінімум

Q не вміє працювати з стрічковими накопичувачами

Це рішення дозволяє здійснювати резервне копіювання тільки на рівні файлів віртуальної машини Про роботу з цим засобом буде розказано трохи нижче

VCB / vStorage API for Data Protection – механізми доступу до ВМ для сторонніх коштів резервного копіювання VCB – це більш рання версія vStorage API for Data Protection Відмінності між версіями – в тому, що VCB – це Windows-додаток, інтегрується зі сторонніми рішеннями резервного копіювання з допомогою сценаріїв А vStorage API for Data Protection – це набір програмних інтерфейсів, який може підтримуватися сторонніми рішеннями резервного копіювання «з коробки» Тобто продукт з підтримкою vStorage API вміє безпосередньо взаємодіяти з ESX (i) для здійснення операцій резервного копіювання

Проте в момент написання цих рядків актуальні обидва підходи, оскільки vStorage API for Data Protection підтримується ще далеко не всіма рішеннями резервного копіювання

Якщо ви плануєте використовувати кошти резервного копіювання з під-

держкой vStorage API for Data Protection, то можуть бути якісь унікальні нюанси у використанні Наприклад, для сервера резервного копіювання можуть підтримуватися різні операційні системи, резервне копіювання може бути можливо як на рівні файлів ВМ, так і на рівні файлів гостьових ОС – а може бути, і тільки якимось одним способом Так що змушений порадити читати документацію від цих систем Але в цілому рішення суть таке ж, як і

у випадку використання VCB, тільки простіше у використанні Тому я опишу рішення з VCB

Ми створюємо виділений сервер резервного копіювання (VCB Proxy) – фізичний або віртуальний сервер з Windows (бо VCB – це додаток під Windows) Встановлюємо на нього VCB і третьесторонній агент резервного копіювання При запуску завдання резервного копіювання, до початку самого копіювання, агент запускає VCB, VCB подмонтірует дані віртуальної машини до цієї Windows Агент резервного копіювання отримує доступ до них так, як ніби це локальні дані тієї Windows, де агент встановлений

Суть VCB (vStorage API) в тому, що той засіб резервного копіювання, яке ми вже використовуємо для резервного копіювання фізичної інфраструктури, здатне зручним чином здійснювати резервне копіювання і віртуальних машин Цим рішенням резервного копіювання можуть бути такі продукти, як CA BrightStor ARCServe, Commvault Galaxy, EMC Avamar, EMC Networker, HP Data Protector, Symantec Backup Exec, Tivoli Storage Manager, Symantec Netbackup та ін

Однак цим агентом може бути і самопісний bat-файл, приклади такого варіанту я приведу в описі роботи з VCB

Плюси:

Q в деяких варіантах інфраструктури і налаштувань дані резервного копіювання можуть передаватися по SAN-мережі Це прискорить процес і знизить навантаження на локальну мережу

Q один агент (який може коштувати грошей) здійснює резервне копіюв-

вання всіх наших ВМ

Q можливо застосовувати один засіб резервного копіювання для фіз ської і віртуальної інфраструктур

Q резервне копіювання і image level, і на рівні файлів гостьовий ОС

(У деяких продуктах це може бути недоступне)

Мінуси:

Q не всі програми можуть бути захищені таким чином через проблеми цілісності даних при знімку стану (це актуально для будь-яких підходів до резервного копіювання, крім хіба що випадки установки агентів всередину гостьових ОС)

Q резервне копіювання на рівні файлів гостя – тільки для ВМ з Win-

dows Втім, це може бути неактуально для якихось коштів з підтримкою vStorage API

Джерело: Міхєєв М О Адміністрування VMware vSphere 41 – М: ДМК Пресс, 2011 – 448 с: Ил

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*