Переходим из физической среды в виртуальную

У каждого из нас могут быть разные основания, чтобы отложить миграцию с операционной системы 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.

Экран 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).

Экран 2. Web-интерфейс управления Virtual Server

Затем нужно настроить виртуальную сеть, чтобы начать использовать виртуальный сервер. В меню 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, запущенных на хост-системе, будут надежно защищены. В настоящее время подобная функциональность еще не поддерживается, но я полагаю, что в течение ближайшего года такие решения появятся на рынке программногообеспечения.