Простий і гнучкий спосіб відновлення після аварії
Віртуалізація успішно застосовується в різних областях, зокрема в цілях забезпечення безперебійної роботи підприємства і для відновлення після аварій. Такі початку притаманні віртуалізації якості, як інкапсуляція, консолідація і незалежність від апаратної платформи, дозволяють підвищити керованість, гнучкість і знизити вартість відновлення.
Завдяки властивостям інкапсуляції (повна обчислювальна середовище містить операційну систему, BIOS, додатки і віртуалізовані апаратні засоби) віртуальні машини (VM) можна відновлювати на будь-яких сумісних серверах з процесорами AMD і Intel, не звертаючи уваги на відмінності в базовому фізичному обладнанні. Таким чином, усувається необхідність відновлення на фізично ідентичному (по збірці, моделі і конфігурації) сервері: виключені проблеми системної сумісності між апаратними засобами і операційною системою за місцем відновлення, підвищується надійність відновлення. Ще одна перевага віртуалізації - можливість консолідувати сервери за місцем відновлення, розмістивши кілька VM на одному фізичному сервері. У разі аварійного переходу на інший ресурс зазвичай допускається тимчасове зниження продуктивності додатків. Завдяки можливості покласти на обладнання кілька функцій при мінімальному зниженні продуктивності дана модель відновлення стає економічно ефективною. В ході повсякденної роботи сервери можна використовувати для тестування і розробки, а після аварії закрити ці завдання і запустити відновлювальні VM. Таким чином забезпечується повнота використання ресурсів, а потреба в реконфігурації системи зводиться до мінімуму.
Отже, робимо перші кроки до використання віртуалізації в процесі відновлення після аварії.
початок
Припустимо, що в компанії використовується кілька додатків Windows, кожне на виділеному сервері з локальним сховищем даних SCSI. Спільно використовувані пристрої зберігання даних (Fibre Channel SAN, NAS або ISCSI) відсутні. Додатки ранжовані в залежності від важливості для компанії. Увагу сконцентровано насамперед на додатках другого рівня з менш суворими вимогами до точки (Recover Point Objective, RPO) і часу (Recovery Time Objective, RTO) відновлення. Поточні вимоги інформаційної інфраструктури та виробництва визначать механізми реплікації даних з виробничого сайту в сайт відновлення.
Провідні продукти серверної віртуалізації - Microsoft Virtual Server і ESX Server компанії VMware. Їх функціональність порівнянна, і, хоча в даній статті розглядається платформа віртуалізації ESX Server, основні етапи тут ті ж, що і для Virtual Server. Virtual Server встановлюється на існуючій базовій операційній системі Windows, такий як Windows Server 2003 або Small Business Server (SBS) 2003р, а ESX Server встановлюється безпосередньо на апаратних засобах сервера (на «голому залізі») і формує шар віртуалізації між апаратними пристроями і окремої гостьової операційною системою. ESX Server ділить фізичний сервер на кілька захищених і переносяться VM, які функціонують паралельно на одному фізичному сервері. Шар віртуалізації абстрагує базові процесор, пам'ять, пристрої зберігання даних і мережеві ресурси для кількох VM.
Завершивши підготовку платформи віртуалізації, необхідно розглянути три основних способи переміщення даних з вихідного сайту в сайт відновлення: резервне копіювання / відновлення, серверна або хост-реплікація або реплікація на основі масиву зберігання даних. У табл. 1 показані варіанти реплікації, які відповідають різним вимогам до відновлення. Об'єкти застосування механізмів захисту даних також залежать від місця розташування системи ESX Server і файлів VM (див. Табл. 2). У нашому прикладі використовуються тільки локальні SCSI-накопичувачі, тому варіанти для поділюваних пристроїв зберігання даних незастосовні. У статті розглядаються тільки сценарії резервного копіювання / відновлення і хост-реплікації.
Таблиця 1 . Відновлення та способи реплікації даних 
Таблиця 2 . Механізми відновлення для локальних і загальних сховищ даних 
Щоб зробити віртуалізацію частиною плану відновлення після аварії, можна застосувати дві базові архітектури - фізичну-віртуалів і віртуальну-віртуальну. Розглянемо поетапну реалізацію обох архітектур. Почнемо зі сценарію резервного копіювання / відновлення.
Фізична-віртуальна архітектура
У фізичної-віртуальної архітектури вихідні (виробничі) додатки продовжують працювати на існуючих фізичних серверах. На відновної платформі додатки будуть виконуватися в віртуальних машинах на ESX Server. У механізмі реплікації використовується метод резервного копіювання / відновлення.
Щоб сформувати середовище, в першу чергу необхідно визначити додатки, які увійдуть до плану відновлення після аварії. Потім слід підтвердити, що поточна політика резервного копіювання на рівні файлів (наприклад, повна, інкрементна, диференціальна, часткова) для кожного фізичного сервера відповідає цілям відновлення. Як об'єкт відновлення вибирається фізичний сервер, на якому належить встановити ESX Server. Перш ніж зробити цей крок, слід перевірити інформацію про сумісність в документі VMware Systems Compatibility Guide for ESX Server 3.x ( http://www.vmware.com/pdf/vi3_systems_guide.pdf ). Тепер все готово для установки ESX Server 3.x Standard на фізичному сервері.
Після завершення установки необхідно перетворити вибрані фізичні сервери в віртуальні машини. Для цього можна використовувати VMware Converter 3.0, який перетворює фізичні комп'ютери Windows і образи сторонніх форматів в віртуальні машини VMware. Віртуальна машина VMware, створена Converter, містить точну копію стану диска з вихідного фізичного комп'ютера, за винятком деяких апаратно-залежних драйверів (і іноді узгоджених символьних позначень дисків). Серед параметрів вихідного комп'ютера, які залишаються ідентичними, - налаштування операційної системи (наприклад, ім'я комп'ютера, код безпеки, облікові записи користувачів, профілі та переваги), додатки та файли даних, а також серійний номер тому кожного розділу диска.
Після того як буде завантажений VMware Converter, його можна встановити на Перетворювані або окремому комп'ютері. Має бути перетворити кілька фізичних комп'ютерів, тому рекомендується встановити Converter на окремому комп'ютері - тоді доведеться виконати тільки одну установку.
В VMware Converter потрібно клацнути на кнопці Import Machine, а потім вибрати фізичний комп'ютер в якості вихідного. Дотримуйтесь інструкцій майстра, вибравши віддалений або локальний комп'ютер. Якщо вибрати віддалений комп'ютер, необхідно ввести ім'я комп'ютера або IP-адреса і облікові дані для перевірки автентичності. Виберіть диски, які належить імпортувати, і вкажіть бажаний розмір томи. Розмір диска можна залишити колишнім, зменшити до мінімуму або вказати точний розмір. Виберіть місце призначення для нової VM і дотримуйтесь вказівок майстра, щоб вибрати систему ESX Server. Необхідно зареєструватися в системі та призначити ім'я VM, а потім вказати сховище даних, щоб зберегти файли конфігурації і диски VM.
Потім виконується настройка гостьовий операційної системи нової VM. Можна задати посвідчення VM (ім'я комп'ютера, ім'я власника, організацію, новий код безпеки), інформацію про ліцензії сервера, тимчасову зону і властивості кожного мережевого інтерфейсу. Після того як нове завдання імпорту буде завершено, можна повторити процес VMware Converter для всіх серверів, які Ви бажаєте перевести.
Тепер все готово, щоб запустити новостворену VM і протестувати додатки. Можна виконати пробне відновлення з минулого резервної копії вихідного фізичного сервера на підходящої VM. Якщо перевірка пройшла успішно, систему ESX Server можна перенести в місце відновлення. Для забезпечення коректного обслуговування необхідно завжди синхронізувати версії і виправлення між вихідними серверами і відповідними VM в відновної системі. Рекомендується періодично виконувати пробні відновлення.
Віртуальна-віртуальна архітектура
У віртуальній-віртуальної архітектурі як виробничі, так і відновні програми виконуються в VM. Тому спочатку необхідно перетворити вихідні сервери в VM, і як вихідна, так і відновна платформи будуть засновані на ESX Server. Очевидна перевага такого підходу - повністю віртуалізованних архітектура з підвищеною гнучкістю і керованістю. Для міграції VM можна просто скопіювати потрібну конфігурацію і файли віртуального диска з джерела на цільову платформу. До цієї архітектурі можна застосувати резервне копіювання / відновлення або механізм хост-реплікації. Існує два варіанти резервного копіювання / відновлення.
Створення копії VM як фізичного сервера. Такий метод застосовується для копіювання на файловому рівні даних, збережених в образі диска VM. В цьому випадку потрібно встановити агент резервного копіювання на кожній VM. По можливості слід переконатися, що копійований VM заморожена. При цьому додаток знаходиться в стабільному стані і не втрачає ніяких незавершених транзакцій. Операція ділиться на дві фази: консолідація сервера, в ході якої існуючі вихідні фізичні сервери перетворюються в віртуальні машини на основі ESX Server, і підготовча фаза для об'єктів відновлення.
Перше завдання - перетворити існуючі фізичні вихідні сервери в віртуальні машини. Для цього досить дотримуватися наведених вище інструкцій щодо вибору серверів, встановлення ESX Server і перетворення вихідних комп'ютерів в віртуальні машини. Потім потрібно налаштувати системи ESX Server, які передбачається використовувати в якості об'єктів відновлення. Після застосування VMware Converter для імпорту існуючих віртуальних машин з джерела в відновлювальні системи ESX Server слід встановити будь-який відповідний агент резервного копіювання на кожній VM, яку належить копіювати (т. Е. На вихідних серверах ESX). Список сумісних агентів резервного копіювання наведено в документі Backup Software Compatibility for ESX Server 3.x ( http://www.vmware.com/pdf/vi3_backup_guide.pdf ) Компанії VMware.
На стороні джерела потрібно налаштувати сервер і пристрій архівування (на диску або магнітній стрічці). Для цього необхідно виконати три операції:
Налаштувати сервер резервного копіювання для використання пристрою архівування та встановити відповідні драйвери і будь-який зручний програмне забезпечення сервера.
Переконатися, що мережа налаштована для доступу між сервером резервного копіювання та віртуальними машинами, які належить копіювати. Якщо і копійований VM, і сервер знаходяться на одній системі ESX Server, їх слід підключити через приватний віртуальний комутатор.
Скласти розклад сеансів копіювання та управляти архівними носіями.
Для відновлення потрібно встановити агент резервного копіювання на кожній VM на відновлювальних серверах ESX. Виконайте пробне відновлення з вихідної VM в відповідну VM на сервері відновлення ESX. З метою підтримки працездатності слід завжди перевіряти синхронізацію між версіями операційної системи, додатками і виправленнями. Обов'язково періодично проводите пробні відновлення.
Резервне копіювання VM як набору файлів. Цей метод застосовується для резервного копіювання на рівні образу або копіювання цілих віртуальних машин. У ньому використовуються переваги інкапсуляції VM, що дозволяє копіювати цілу VM разом з системними настройками, програмами та даними. Віртуальні машини можна відтворювати повністю, відновлюючи окремі файли.
ESX Server зберігає віртуальні машини в файлової системі VMware File System (VMFS). VMFS - проста високопродуктивна файлова система на фізичних SCSI-дисках і розділах, що забезпечує зберігання великих файлів, таких як образи віртуальних дисків для віртуальних машин ESX Server і образи пам'яті призупинених VM.
У ESX Server 3.x VMFS підтримує каталоги. Зазвичай для кожної VM в VMFS існує один каталог. Цей каталог містить всі файли, що становлять VM. Повний список файлів, що утворюють VM, наведено в табл. 3.
Таблиця 3. Файли віртуальної машини VMware 
При даному способі резервного копіювання неможливо відновити окремі файли для кожної VM. Щоб відновити єдиний файл, потрібно відновлювати всю VM. Розмір файлів віртуального диска нерідко перевищує 1 Гбайт, що може обмежити вибір програми резервного копіювання. Через потенційно великого розміру файлу віртуального диска час відновлення напевно збільшиться.
Архівний образ буде містити стан VM в певний час. У ньому немає незафіксованих змін даних або стану пам'яті. Оскільки в процесі резервного копіювання віртуальний диск розглядається як ціле і не пов'язаний з додатками, створені архівні копії узгоджені тільки з файлової системою. В результаті архівна копія може перебувати в аварійному стані. Щоб уникнути подібної ситуації, можна відключити VM або заморозити додаток (якщо можливо) перед резервним копіюванням. Інший спосіб - використовувати утиліти зі складу ESX Server на рівні образу, докладніше про це читайте в урізанні «Спеціалізований інструмент архівування для VMware».
Щоб сформувати середовище, слід налаштувати джерело установки і відновні сайти, як описано вище. Встановіть сумісний агент резервного копіювання на службовій консолі кожного комп'ютера ESX Server (як на вихідній, так і на відновної системі ESX Server). На вихідної стороні потрібно налаштувати сервер і пристрій резервного копіювання (на диску або магнітній стрічці) наступним чином:
Налаштувати сервер резервного копіювання для використання архівної пристрою і встановити відповідні драйвери і архівну програму за власним вибором.
Мережеві функції повинні бути налаштовані для доступу між сервером резервного копіювання та віртуальними машинами, які належить архівувати. Якщо архівіруемие VM і сервер резервного копіювання знаходяться на одному комп'ютері ESX Server, то для їх з'єднання потрібно приватний віртуальний комутатор.
Необхідно підготувати графік архівування на основі рекомендованої політики, як показано в табл. 4. Велика ймовірність частої зміни дисків, приписаних до кожної VM. Тому рекомендується щодня виконувати інкрементне копіювання. Образ завантажувального диска змінюється не настільки часто, і його слід копіювати принаймні один раз в тиждень. Зміни службової консолі ESX Server мінімальні, тому в даному випадку політику архівування цілком визначає адміністратор. Якщо можливо, слід відключити VM перед резервним копіюванням. Не забудьте скопіювати кожну папку, яка містить VM.
Таблиця 4. Пріоритети політики резервного копіювання 
Потім потрібно виконати пробне відновлення машини ESX Server. Обов'язково відновите набір файлів у відповідному каталозі на відновної системі ESX Server. Далі необхідно зареєструвати VM. За допомогою клієнта VMware VI потрібно підключитися до відновного комп'ютера ESX Server. Слід вибрати комп'ютер, перейти на вкладку Configuration і вибрати пункт Storage. Клацніть правою кнопкою миші в списку на сховище даних і виберіть пункт Browse Datastore для доступу до діалогового вікна Datastore Browser. У правій стороні вікна відображається файлова система сховища даних. Потрібно перейти за ієрархією сховища даних на вкладку Folders. Щоб зареєструвати VM, слід перейти до файлу конфігурації (.vmx), клацнути на ньому правою кнопкою миші і вибрати пункт Add to inventory. При необхідності можна змінити мережеву конфігурацію віртуальної машини. Тепер все готово для запуску VM.
Важливо мати на увазі, що зі службового консолі ESX Server можна переглядати і маніпулювати файлами в каталогах / vmfs / volumes монтованих томів VMFS з використанням звичайних файлових команд, таких як ls і cp. Монтовані томи VMFS можуть бути схожі на будь-яку іншу файлову систему (наприклад, ext3), але VMFS орієнтована в основному на зберігання великих файлів, таких як образи диска розміром близько 2 Тбайт. Можна використовувати команди ftp, scp і cp для копіювання файлів в тому VMFS і з цих томів (якщо базова файлова система підтримує великі файли).
Серверна і хост-реплікація
Як правило, Механізми реплікації на основе файлів реплікують файли асинхронно через IP-ятір при збереженні порядку записи. Існує два основних способи реплікації на основе файлів. В одному випадка необходимо скачать агент в VM. Цей метод допускає Зміни на файловому Рівні в операційній системе, а такоже реплікацію Даних через IP-ятір на заздалегідь підготовленій віртуальний вузол у відновному сайті. Потім оновлюються Дублікати файлів на цільовому комп'ютері. Таким чином, тільки байтові зміни передаються через IP-з'єднання в реальному часі. Інший спосіб заснований на реплікації власне набору файлів, складових VM (наприклад, віртуальний диск, конфігурація). При будь-якої реалізації обов'язково пам'ятайте, що, якщо активність диски не заморожена для реплікації, копія буде вразлива в разі збою. Завдяки таким продуктам, як Double-Take компанії Double-Take Software і RepliStor компанії EMC зі службою Microsoft Volume Shadow Copy Service (VSS), можливе створення узгоджених з додатками моментальних знімків на вторинному сервері. Це дозволяє відновити дані і додатки Windows в разі псування або аварії на вихідному сервері.
Щоб сформувати середовище, слід налаштувати сайти джерела установки і відновлення, як описано вище. Потім потрібно встановити додаток реплікації і агента як на вихідній VM, так і на відповідних VM в цільовій системі ESX Server. Потрібно створити завдання реплікації, вказавши файли і каталоги для реплікації і частоту операцій. Після початкової реплікації слід виконати просте тестування і переконатися, що вибрані файли, каталоги і зміни пересилаються, а дані коректні.
обов'язкове тестування
Початкова та регулярне тестування необхідно, щоб бути повністю готовим до усунення наслідків аварії. Серед рекомендованих запобіжних заходів - перевірка документації та її своєчасне оновлення, тестування процедур відновлення і автоматичного переходу на інший ресурс, а також перевірка їх відповідності бізнес-цілям і тестування процедур обробки відмов. У міру зміни вимог і технологій може змінюватися поточна реалізація і план відновлення після аварії.
Ми розглянули різні варіанти застосування технології віртуалізації до відновлення після збою в середовищі з локальними SCSI-сховищами даних. У кожної середовища є свої особливості, тому остаточне рішення може являти собою поєднання представлених в статті варіантів. Віртуалізація серверів дозволяє вирішити багато проблем, пов'язаних зі складністю і негнучкістю фізичної інфраструктури, але правильне планування, архітектура та тестування - необхідна умова безперервності виробничого процесу і успішного відновлення після аварій.
Кріс Бенсон - Незалежний автор. Спеціалізується на нових технологіях, мережевих рішеннях, сховищах даних і всеосяжної зв'язку на підприємстві Має сертифікати MCSE, MCP і CNE. [email protected]
Рекомендації Microsoft щодо створення резервної копії віртуальних серверів
Які можливості перетворення для Microsoft Virtual Server? Щоб спростити процес, перетворення фізичних комп'ютерів в віртуальні машини автоматизується за допомогою набору інструментів Virtual Server 2005 Migration Toolkit (VSMT). Щоб скористатися VSMT, необхідний контролер Automated Deployment Services (ADS) 1.0, що функціонує на Windows Server 2003, Enterprise Edition, а також Virtual Server 2005. VSMT забезпечує міграцію Windows 2003, Windows 2000 Server Service Pack 4 (SP4) і Windows NT 4.0 Server SP6 .
За допомогою функцій управління віртуальним диском утиліти Administration продукту Virtual Server можна створити копію фізичного диска для використання в якості віртуального жорсткого диска. Ця процедура призначена тільки для дисків даних. Можна створити віртуальний жорсткий диск, пов'язаний з фізичним диском даних. Слід зазначити, що пов'язаний віртуальний диск не містить копії вмісту фізичного диска. Він тільки посилається на нього. Щоб скопіювати вміст диска в файл віртуального жорсткого диска, необхідно перетворити пов'язаний диск в динамічно розширюваний віртуальний жорсткий диск.
Існує ряд особливостей, які потрібно враховувати при архівування. Важливі файли віртуальної машини Virtual Server - .vmc (конфігурація VM), .vhd (віртуальний жорсткий диск), .vsv (збережений стан VM) та .vnc (конфігурація віртуальної мережі). Щоб скопіювати конфігурацію VM і файли ресурсів, рекомендується копіювати тільки .vmc, .vsv і пов'язані .vhd-файли для віртуальних машин, які відключені або знаходяться в збереженому стані. В іншому випадку, швидше за все, вони будуть неузгодженими.
Спеціалізований інструмент архівування для VMware
Ще один варіант - використовувати вбудовані утиліти ESX Server компанії VMware для резервного копіювання на рівні образів. За допомогою утиліти vcbMounter можна отримати архівну копію всієї VM в службовій консолі. Інструмент приховано створює моментальний знімок VM і експортує його в набір файлів, які згодом можна використовувати, щоб відновити VM. Зробити копію набору файлів можна за допомогою сумісної програми архівування або застосувати scp для простої пересилання файлів.
На вихідних комп'ютерах ESX Server слід отримати резервні копії файлів VM за допомогою утиліти vcbMounter. Синтаксис наступний:
vcbMounter -a -r
де VM identifier - унікальний ідентифікатор копируемой VM, а backup destination вказує місце для зберігання архівних даних. Типовий спосіб ідентифікувати віртуальні машини - використовувати ім'я DNS або IP-адресу. Scp можна задіяти для копіювання VM в локальний каталог або на віддалений сервер. Наприклад, щоб архівувати VM w2k3vm.acme.com в локальний каталог / home / vmbackup / w2k3vm, слід ввести команду
vcbMounter -a ipaddr: w2k3vm.acme.com -r / home / vmbackup / w2k3vm
Щоб відновити файли в заданому каталозі в консолі ESX Server, необхідно використовувати файл каталогу VM. Утиліта vcbMounter створює цей файл для кожної архівується VM. Потрібно зробити копію цього файлу. В даному прикладі потрібно зробити копію файлу каталогу VM / home / vmbackup / w2k3m. Для цього можна ввести команду
cp / home / vmbackup / w2k3m / catalog / tmp / catalog-w2k3m
У копії файлу каталогу слід вказати нові параметри для сховищ даних і шлях папки. Сховище даних вказує, де зберігати всі файли, які складають VM. Список коректних імен сховищ даних можна отримати з браузера сховищ даних в клієнті VI або глянувши на ярлики файлової системи томи VMFS в службовій консолі під / vmfs / volumes. Шлях вказує папку, в якій буде зберігатися VM.
Змінивши параметри файлу каталогу VM, слід використовувати цей файл для відновлення VM. Щоб відновити VM, потрібно вказати альтернативний файл каталогу за допомогою ключа -a. Наприклад, щоб відновити VM, копія якої знаходиться в / home / vmbackup / w2k3m, з використанням альтернативного файлу каталогу / tmp / catalog-w2k3m, слід ввести команду
vcbRestore -s / home / vmbackup / w2k3m -a / tmp / catalog-w2k3m.
Кріс Бенсон