НОВЕ ЖИТТЯ старих додатків в Microsoft Virtual Server

1. Переходимо з фізичної середовища в віртуальну У кожного з нас можуть бути різні підстави, щоб відкласти...
2. Налаштування хоста
3. Додавання VM
4. перенесення додатків
5. Міграція стає простіше
6. Міграція і не тільки
7. Інтеграція з процедурами резервного копіювання та відновлення

Переходимо з фізичної середовища в віртуальну

У кожного з нас можуть бути різні підстави, щоб відкласти міграцію з операційної системи Windows NT, але одна з найбільш важливих причин - несумісність додатків. Якщо додаток, встановлений на NT, не може стабільно функціонувати в Windows 2000 або Windows 2003, то я, наприклад, швидше за піду на періодичну перезавантаження NT як рішення проблеми в роботі програми, ніж погоджуся на перехід до нової операційної системи. Хоча деякі компанії йдуть на заміну або оновлення застарілих додатків, щоб приступити до міграції, не всі організації можуть дозволити собі таку розкіш, тому змушені працювати з більш ранніми версіями операційної системи, використовуючи старі, але необхідні додатки.

Багато системні адміністратори вже знають, що здійснити міграцію може допомогти технологія віртуальних машин (VM). Технологія VM дозволяє запускати на одній машині кілька операційних систем одночасно. Фактично ні мережеві комп'ютери, ні додатки жодним чином не можуть відрізнити VM від фізичної машини. Перед тим як почати використовувати VM, потрібно підібрати додатки, на базі яких потрібно розгортати власне віртуальну систему. VMware Workstation (VMware GSX Server або VMware ESX Server), а також Microsoft Virtual Server - два потенційних рішення подібного класу. Ці додатки дають можливість створювати віртуальні машини, укомплектовані віртуальними жорсткими дисками (інтерфейс IDE або SCSI), віртуальної оперативною пам'яттю і іншими віртуальними ресурсами, такими як мережеві інтерфейси, за допомогою яких можна буде підключатися до фізичної мережі. Після того як віртуальне обладнання VM задано, віртуальний сервер може бути включений і на ньому може бути встановлена ​​необхідна операційна система. Всім, хто зацікавився продуктами компанії VMware, рекомендую прочитати статтю «VMware GSX Server 2.5», опубліковану в «Windows & .NET Magazine / RE» № 6 за 2003 рік. Я використовував в процесі міграції Microsoft Virtual Server і тепер пропоную розпочати розгляд можливостей цього продукту.

Коротко про Virtual Server

Virtual Server все ще перебуває в стані бета-версії, в нього активно вносяться зміни, тому зараз немає сенсу детально описувати особливості роботи цього додатка. Однак ми будемо продовжувати спостерігати за розробкою даного продукту.

Народження Virtual Server пов'язано з придбанням Microsoft лінії продуктів Connectix Virtual Server. На відміну від продуктів VMware, Virtual Server розроблявся виключно для використання на платформах Windows (зокрема, Windows 2000 і пізніших версіях Windows, на яких запущено Microsoft IIS). Оскільки віртуальні машини, побудовані на базі Virtual Server, повністю інтегровані з операційною системою комп'ютера-хоста, потреба в мережевих і графічних драйверах від незалежних постачальників відпадає. Замість цього віртуальні пристрої емулюють роботу PnP-обладнання, «рідного» для даної версії Windows. На додаток до PnP-інтеграції, Virtual Server пропонує для моніторингу VM лічильники продуктивності і підтримує такі функції, як підтримка застарілих операційних систем і менеджмент за допомогою сценаріїв.

Лічильники System Monitor для моніторингу VM. Коли встановлюється Virtual Server, на додаток до вже наявних на базовій системі лічильників System Monitor додаються лічильники VM. Ці лічильники дозволяють збирати інформацію про роботу всіх VM хоста. На екрані 1 наведено приклад вибірки VM-даних, які були зібрані за допомогою System Monitor.

Підтримка застарілих операційних систем (NT, Windows 2000, OS / 2). Підтримка застарілих операційних систем означає, що завдяки Virtual Server можна відмовитися від «антикваріату», який зберігався в компанії тільки тому, що доводилося забезпечувати роботу декількох старих додатків. Не так давно я працював в організації, де не видаляли NT через одного-єдиного додатка. Перейшовши на VM, така компанія могла б відмовитися від NT.

Менеджмент за допомогою сценаріїв. Ще одна корисна функція Virtual Server - інтегрована підтримка сценаріїв. Фактично до складу даного продукту входить кілька сценаріїв, на прикладі яких можна познайомитися з технікою складання сценаріїв. У тому числі є сценарій під назвою FailOver.vbs, з його допомогою можна стежити за станом роботи VM і автоматично переходити на резервну VM, якщо перша VM перестає відповідати. Ще один сценарій, DuplicateVM.js, дозволяє клонувати VM - він працює навіть на активній віртуальній машині. DuplicateVM.js - ідеальний засіб для створення резервних копій VM, і якщо віртуальний сервер випадково пошкоджується або його робота аварійно зупиняється, відновити працездатність VM дуже просто - достатньо скористатися резервною копією сервера, додатків і даних.

Налаштування хоста

Необхідно переконатися, що хост для VM функціонує під управлінням Windows 2000 Service Pack 3 (SP3) або більш пізніх версій Windows і в системі працює IIS. Останнє потрібно для того, щоб посилати команди службі Virtual Server, так як Virtual Server не має окремого додатка для даного завдання (це стосується бета 1). Якщо запускати на хості IIS небажане, можна налаштувати Virtual Server, Web-сайт на альтернативний сервер (оперативна підказка містить відповідну інструкцію). Якщо IIS запустити неможливо, Microsoft рекомендує задіяти інший продукт, Microsoft Virtual PC, замість Virtual Server для управління VM (Virtual PC не така надійне рішення, як Virtual Server, але зате не вимагає IIS).

Важливо пам'ятати про те, що віртуальні машини витрачають ресурси системи, як і звичайні фізичні сервери, тому треба переконатися, що на хості досить оперативної пам'яті і дискового простору для підтримки роботи всіх VM, які передбачається одночасно запускати на хості. Наприклад, якщо планується виділити по 128 Мбайт пам'яті кожного з трьох віртуальних серверів NT, додатково до вже наявної пам'яті хоста необхідно додати 384 Мбайт. Далі слід переконатися, що виділено достатньо місця на диску для віртуальних дисків VM. Спеціально створювати розділи на жорстких дисках для віртуальних дисків не потрібно, оскільки віртуальні диски зберігаються в файлі з розширенням .vhd.

Після того як для всіх VM виділена достатня кількість ресурсів, треба визначитися з роботою VM в мережі. Можна надати мережевий адаптер хоста в спільне використання та підключатися безпосередньо до робочої мережі. Можна зробити так, щоб віртуальна мережа замикалася лише на хост. Я віддаю перевагу останній підхід, оскільки в цьому випадку VM ізолюються від фізичних систем решти мережі. Крім того, створення віртуальних мережевих з'єднань усуває конфлікти, що відбуваються через помилки NetBIOS під час процесу міграції, і дає можливість повністю протестувати і налаштувати віртуальні машини без будь-якого зовнішнього впливу на фізичні робочі сервери NT.

Щоб встановити віртуальну мережу, потрібно відкрити в Control Panel додаток Add / Remove Hardware для установки адаптера Microsoft Loopback Adapter. Потім необхідно відредагувати налаштування TCP / IP і призначити перший IP-адреса в унікальній мережі, такий, наприклад, як 10.1.0.1/24. Коли на хості будуть встановлені всі віртуальні машини, можна буде налаштувати їх мережеві інтерфейси для використання інших IP-адрес в тій же віртуальної підмережі.

Звичайно, віртуальна мережа, яку видно лише віртуальним машинам, не має сенсу, якщо у користувачів не буде доступу до віртуального сервера NT. Щоб надати користувачам доступ і зберегти приналежність всіх віртуальних машин їх власної мережі, на хості була налаштована служба Routing and Remote Access, яка діяла як мережевий маршрутизатор. Можна скористатися оснащенням Routing and Remote Access Service в консолі Microsoft Management Console (MMC) для установки параметрів служби за допомогою майстра установки, який викликається при самому першому зверненні до служби віддаленого доступу. Щоб будь-який адміністратор зміг звернутися до віртуальної мережі і працюють VM, можна видати команду Route Add і додати статичні маршрути для комп'ютерів адміністраторів. Наприклад, щоб отримати доступ до віртуальної мережі 10.1.0.0/24, прив'язаною до хосту з IP-адресою 172.16.12.34, слід ввести команду:

route add p 10.1.0.0
mask 255.255.255.0 172.16.12.34

Коли все буде готово до перекладу всіх VM в робочу мережу для заміни фізичних NT-серверів, потрібно буде просто оновити таблиці маршрутів мережевих маршрутизаторів, а потім модифікувати А-записи хоста для кожної VM на робочому DNS-сервері.

Якщо маршрути змінювати небажано, завжди можна модифікувати настройки мережевих інтерфейсів конкретної VM, щоб використовувати мережеві інтерфейси фізичного хоста. Така конфігурація дозволить напряму підключати VM до робочої мережі, і все, що буде потрібно, - зробити так, щоб віртуальні мережеві інтерфейси мали унікальну мережеву робочу адресу IP. При використанні такого підходу потрібно обов'язково ізолювати VM від робочого сервера, який замінюється віртуальним сервером, інакше будуть виникати помилки в NetBIOS через те, що ідентичні системи «бачать» одне одного в одному і тому ж сегменті фізичної мережі.

Додавання VM

Коли буде визначено, скільки дискового простору і пам'яті повинні використовувати віртуальні машини, і на хості будуть налаштовані віртуальні мережі, можна встановлювати додаток Virtual Server. Для цього необхідно завантажити виконуваний модуль і запустити процедуру установки, а потім настроїти VM. Щоб додати VM, потрібно звернутися до сторінці Virtual Server Master Status (Start, Programs, Microsoft Virtual Server, Master Status) або запустити Microsoft Internet Explorer (IE) 5.5 або вище і вказати адресу http: // host server name 1024 / virtualserver / vswebapp / vswebapp.exe для виклику Web-консолі управління (див. екран 2).

Потім потрібно налаштувати віртуальну мережу, щоб почати використовувати віртуальний сервер. У меню Tools слід клацнути Virtual Network Manager і вибрати Create Virtual Network. Необхідно присвоїти віртуальної мережі ім'я і зі списку Host Network Adapter вибрати потрібну мережу для підключення до адаптера Microsoft Loopback Adapter.

Тепер можна створити нову VM. У меню Tools слід клацнути Add Virtual Machine і виділити для нової VM пам'ять і віртуальний жорсткий диск. Для віртуального мережевого інтерфейсу в поле Ethernet NIC потрібно вибрати тільки що створену віртуальну мережу. І нарешті, потрібно клацнути Create Virtual Machine для створення VM. Після того як нова VM буде налаштована, залишається просто її запустити. Необхідно клацнути Master Status, помістити курсор поверх імені створеної VM і вибрати Power On для запуску нової віртуальної машини. Для управління станом VM потрібно клацнути піктограму VM на сторінці Master Status. Імітація комбінації Ctrl + Alt + Del здійснюється натисканням правої клавіші Alt і клавіші Del. Щоб вийти з VM, потрібно натиснути праву клавішу Alt (призначення клавіш, задані за замовчуванням, можуть бути змінені).

Тепер необхідно встановити на VM операційну систему, як це зазвичай відбувається на фізичній машині. Під час установки операційної системи слід переконатися в тому, що мережевий інтерфейс (IP-адреса) налаштований на роботу в віртуальної мережі даної VM. Для найпершої VM в своїй віртуальній мережі я призначив IP-адреса 10.1.0.2/24 і вказав шлюз 10.1.0.1. Адреса 10.1.0.1 був привласнений інтерфейсу Microsoft Loopback Adapter, який функціонував як шлюз для всіх віртуальних машин в мережі 10.1.0.0/24. Оскільки моя віртуальна NT 4.0 замінила фізичний NT-сервер з ім'ям BSOD, те ж саме ім'я - BSOD - я привласнив та даної VM.

Після установки базової операційної системи має сенс запустити процедуру Sysprep, а потім сценарій DuplicateVM.js для створення нового базового образу VM. Після цього можна буде використовувати пропущений через Sysprep клон VM як вихідний для установки додаткових віртуальних серверів NT.

перенесення додатків

Тепер, коли операційна система запрацювала на віртуальній машині, можна приступати до перенесення додатків. Потрібно мати на увазі, що VM ще не включена в робочий домен - якщо спробувати це зробити при функціонуючому робочому сервері, можна заблокувати обліковий запис робочого сервера, так як включення сервера до складу домену призводить до автоматичної генерації нового пароля облікового запису комп'ютера. В результаті пароль облікового запису робочого сервера більше не відповідав би паролю, що зберігається на контролері домену. Це призвело б до збою аутентифікації робочого сервера на контролерах домену і тривало б до тих пір, поки робочий сервер заново не був включений до складу домену, що, в свою чергу, призвело б до блокування VM. Для перенесення програми я вважаю за краще використовувати установку додатка на VM «з нуля». Після цього можна скопіювати дані програми на один з жорстких дисків VM. Якщо дані додатка при його роботі виявляються заблоковані, можна скористатися програмою резервного копіювання і спочатку зберегти дані на робочий сервер, а потім відновити їх на VM.

Після залишити програму і даних на нову віртуальну машину слід протестувати роботу програми і переконатися, що все йде так, як очікувалося. І тільки після цього можна ввести VM до складу домену, оновити записи DNS і перевірити всі маршрути (т. Е. Переконатися, що всі клієнти можуть підключатися до VM). Тепер можна вважати, що перехід до віртуального життя додатки завершено. Ми можемо знову скористатися сценарієм DuplicateVM.js для створення і збереження резервної копії VM. Якщо в подальшому відбудеться повна відмова системи, досить просто запустити програму резервування і відновити збережену копію VM і найостанніші дані. Детальніше про резервування файлів VM розказано в урізанні «Інтеграція з процедурами резервного копіювання та відновлення».

Однак необхідно пам'ятати, що можна зіткнутися з проблемами при роботі з двома копіями одного і того ж віртуального сервера. Наприклад, якщо на контролері домену (DC) змінюється пароль облікового запису комп'ютера для однієї версії VM, потрібно вручну повторно включити клон VM в домен. Для запобігання періодичного скидання паролів VM слід запустити редактор реєстру на кожній з VM, відкрити розділ HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServices NetlogonParameters і привласнити параметру DisablePasswordChange значення 1.

Міграція стає простіше

Якщо потрібно просто клонувати робочу систему на VM, можна скористатися майстром установки Physical to Virtual Wizard. Ця програма дозволяє уявити фізичну систему у вигляді віртуальної і протестувати її в процесі міграції, усунувши всі негативні ефекти. Коли продуктивність роботи VM стане задовільною, робочий сервер може бути переведений в резерв. Інший приклад використання Physical to Virtual Wizard - клонування серверів NT перед їх оновленням, т. Е. Якщо сервер виявляється непрацездатним під час процедури оновлення, можна буде перевести його VM-клон в оперативний режим в якості тимчасового вирішення проблеми, поки на фізичному сервері виконуються відновлювальні роботи.

Розробники Microsoft стверджують, що Physical to Virtual Wizard з успіхом може застосовуватися для клонування додатків Microsoft. Разом з тим слід провести ретельну перевірку працездатності інших клонованих додатків на новоствореному віртуальному сервері, перш ніж остаточно відмовлятися від колишньої робочої системи.

Microsoft планує включити Virtual to Physical Wizard і Virtual to Virtual Wizard до складу Virtual Server. Virtual to Physical Wizard - ідеальний засіб для тестування нового сервера перед введенням в експлуатацію замість фізичного робочого сервера. Virtual to Virtual Wizard дозволить полегшити процес клонування VM. Наприклад, можна буде налаштувати «VM за замовчуванням», запустити Sysprep, після чого запустити Virtual to Virtual Wizard для копіювання даної VM в нову VM і отримати на кілька хвилин «чисту» віртуальну операційну систему.

Міграція і не тільки

Хоча продукт Microsoft Virtual Server дуже добре пристосований для консолідації систем NT в мережі корпорації, причому кілька VM можуть запускатися на одній фізичній системі, крім цього технологія віртуальних машин надає нові способи управління мережевими системами. Наприклад, вона дозволяє:

• налаштовуваті Віртуальні SCSI-диски для роботи з віртуальнім кластером, Який організованій на одній фізічній системе. Це можна розглядаті як прекрасний засіб для проведення тестів, демонстрацій и тренінгу;
• налаштовуваті жорсткі диски VM для использование режиму undo drives, коли VM скасовує всі зроблені в процесі роботи Зміни при віключенні VM. Це властівість надає відмінні возможности для тестування, тренінгу та навчання;
• налаштовуваті VM для Отримання Нових ІНСТРУМЕНТІВ обслуговування таких платформ, як Windows 2003, Windows 2000, Linux, NetWare. Альо необходимо пам'ятати, что запуск однієї операційної системи поверх Іншої может негативно позначітіся на продуктівності. При плануванні консолідації кількох VM в рамках одного комп'ютера нужно обов'язково провести випробування системи з НАВАНТАЖЕННЯ;
• в разі катастрофічного руйнування системи відновіті роботу на ІНШОМУ обладнанні.

Ті, кому доводилося хоча б один раз перебудовуваті сервер Windows 2000 после катастрофічного руйнування системи на новому обладнанні, знають, Наскільки це буває складно сделать. Оскільки VM емулює апаратне забезпечення, відмінності в апаратних засобах фактично усуваються, точно так само як ці відмінності не мають значення і для переміщення операційної системи і додатків з одного віртуального хоста на інший. Якщо VM зруйнована або якщо VM-хост несправний, можна відновити резервну копію віртуальних дисків VM і конфігураційні файли на іншому сервері без будь-яких ускладнень. Подібна гнучкість дуже корисна і при роботі з поштовими серверами. Якщо поштовий сервер VM перестав працювати, швидко включається клонована репліка оригінальної VM і як мінімум забезпечується доступ користувачів до їх поштових скриньках. Якщо програмне забезпечення резервного копіювання підтримує відновлення на рівні повідомлень, то на тлі звичайної роботи користувачів по відправленню і приймання нових повідомлень можна виконати відновлення поштових повідомлень на момент збою VM. При використанні технології віртуальних машин загальний час простою поштового сервера може бути скорочено до кількох хвилин, а не годин або днів.

Спрощення процесу міграції застарілих додатків - це тільки початок. Хоча ми продовжуємо накопичувати досвід роботи з VM і Virtual Server поступово, вже зараз можна сказати, що переваги описаних технологій будуть залучати до себе увагу в майбутньому. Очікується, що Virtual Server з'явиться в продажу в четвертому кварталі 2003 року. А ми будемо продовжувати стежити за розвитком цих технологій.

Кріс Вольф ( http://www.chriswolf.com ) - консультант в CommVault Systems. Спеціалізується на кластерах, системах зберігання і діагностиці мережевих проблем, має сертифікати MCT, MCSE, CCNA

Інтеграція з процедурами резервного копіювання та відновлення

Оскільки програма не в змозі відрізнити віртуальну машину (VM) від фізичної, можна встановлювати і запускати на VM наявні агенти резервного копіювання (або додаток Windows Backup). Таким чином, можна створювати резервні копії систем, як якщо б це були звичайні фізичні системи. Деякі постачальники програм резервного копіювання розглядають питання створення агента резервування, який зможе працювати з конкретною VM. При цьому дані інших VM, запущених на хост-системі, будуть надійно захищені. В даний час подібна функціональність ще не підтримується, але я вважаю, що протягом найближчого року такі рішення з'являться на ринку програмногозабезпечення.