Настраиваем VMware Auto Deploy

Признаться, я всегда мечтал, чтобы когда-нибудь во всех современных приложениях появилась большая круглая красная кнопка "Работать", нажав которую, администратор по прошествии определенного времени получал бы полностью настроенную и работоспособную систему. И хотя VMware Auto Deploy пока не обладает такой кнопкой, но, во всяком случае, делает уверенные шаги в нужном направлении.


VMware Auto Deploy представляет из себя виртуальную оснастку (Virtual Appliance), которая будучи развернута вместе с VMware vCenter Server позволяет автоматизировать процесс загрузки и настройки серверов виртуализации ESX по сети с использованием протокола PXE. Использование Auto Deploy позволяет, во-первых, отказаться от локальных носителей для установки ESXi, что может несколько повысить надежность сервера, во-вторых, разворачивать новые серверы виртуализации, ограничиваясь тремя операциями - смонтировать сервер, скоммутировать сервер, включить сервер. :-)

На текущий момент Auto Deploy находится на этапе Techinal Preview, что не гарантирует стабильной работы в производственной среде, но не мешает нам опробовать ее в деле. Загрузить предварительную версию Auto Deploy можно по этой ссылке.

Установка Auto Deploy
Распакуйте содержимой в любой доступный для vCenter Server каталог. Подключитесь клиентом VMware vSphere Client к серверу. Запустите мастер импорта виртуальных машин из OVF шаблона, нажав File -> Deploy OVF Template.

На первой странице мастера в поле Deploy from a file or URL укажите путь к .ova файлу из распакованного архива. Нажмите Next.

На странице OVF Template Details нажмите Next.

На странице End User License Agreement прочтите и примите лицензионное соглашение с помощью кнопки Accept и нажите Next.

На странице Name and Location задайте имя (Name) виртуальной машины и укажите ее расположение (ЦОД и папку). Нажите Next.

На странице Host / Cluster укажите сервер виртуализации или кластер, на котором будет зарегистрирована виртуальная машина. Нажмите Next.

На странице Datastore выберите хранилище, на котором будут располагаться файлы виртуальной машины. Нажмите Next.

На странице Disk Format укажите тип виртуального диска. Нажмите Next.

На странице Network Mapping привяжите виртуальный сетевой адаптер к нужному виртуальному коммутатору и группе портов. Нажмите Next.

На странице Ready to Complete нажмите Finish.

Дождитесь, пока файлы скопируются на хранилище и машина будет зарегистрирована в vCenter. Запустите виртуальную машину Auto Deploy.

Настройка Auto Deploy
Откройте консоль виртуальной машины Auto Deploy и дождитесь окончания загрузки ОС. При первом старте будет автоматически запущен мастер настройки, позволяющий задать сетевые параметры ВМ. Если в вашей сети еще не настроен DHCP сервер, можете задать статические настройки.

Затем система предложит задать пароль для административной учетной записи vi-admin. После завершения всех настроек откроется окно приветствия.

Настройка DHCP
Для автоматической выдачи сетевых параметров серверам ESXi вам потребуется развернуть сервер DHCP. Вы можете использовать DHCP сервер, встроенный в виртуальную машину или сторонний сервер DHCP в вашей сети. Для примера рассмотрим конфигурацию DHCP сервера в ОС Windows Server 2008.

Откройте консоль управления DHCP сервером. Если у вас уже настроена область с нужным диапазоном адресов, можете использовать ее, в противном случае создайте новую область.
Раскройте область, щелкните правой кнопкой мыши по Scope Options и выберите Configure Options... На вкладке General укажите в качестве значения для опции 066 Boot Server Host Name имя или IP сервера Auto Deploy.

Для опции 067 Bootfile Name впишите "undionly.kpxe.vmw-hardwired". Сохраните настройки.

Теперь можно попробовать загрузить на сервер виртуализации ESXi по сети. Зайдите на ваш сервер и в качестве предпочитаемого источника загрузки выберите сетевой адаптер. В данном примере в качестве такого сервера я использовал другую виртуальную машину.

Если вы правильно настроили DHCP и Auto Deploy, то сервер виртуализации получит необходимые сетевые настройки и начнет процесс загрузки. После ее завершения вы получите вполне работоспособный сервер ESXi, который можете настроить по собственному желанию.

Использование Host Profiles
Понятно, что  в силу особенностей загрузки ESXi по сети, настройки вашего сервера и все изменения, которые вы на нем выполните сохранятся до первого выключения. И хотя сервер, развернутый в производственной среде, может не перезагружаться месяцами, а то и годами, гораздо более практичным будет использование функции Host Profiles, доступной в редакции vSphere Enterprise Plus, которая позволяет применять нужные настройки автоматически при каждой загрузке сервера.

Для создания профиля в Host Profiles вам понадобится эталонный сервер, например тот, который вы только что загрузили по сети. Для начала откройте локальную консоль и задайте пароль для учетной записи root (по умолчанию пароля нет).

Теперь зарегистрируйте сервер виртуализации в vCenter.

Выполните на нем все необходимые настройки (добавьте виртуальные коммутаторы и группы портов, настройте синхронизацию времени, добавьте учетные записи пользователей и группы).

Откройте окно управления профилями Host -> Host Profiles.

Щелкните кнопкой мыши по кнопке Create Profile.

В мастере создания профиля на первой странице выберите Create Profile from existing host. Нажмите Next.

На странице Specify Reference Host укажите добавленный и настроенный вами сервер. Нажмите Next.

На странице Profile Details задайте имя и описание создаваемого профиля. Нажмите Next.

На странице Ready to complete the profile нажмите Finish.

Настоятельно рекомендуется отредактировать созданный профиль и настроить в нем автоматическое назначение пароля для учетной записи root. Для этого щелкните правой кнопкой мыши по созданному профилю и выберите Edit Profile.

В открывшемся окне раскройте Security configuration -> Administrator password, выберите Configure a fixed administrator password, задайте пароль администратора и нажмите OK для сохранения настроек.

Теперь откройте консоль управления Auto Deploy. В главном меню нажмите комбинацию клавиш Alt + F2, в поле autodeploy login введите имя учетной записи (vi-admin), в поле Password - пароль.

Нам потребуется добавить один или несколько серверов vCenter Server, в которых Auto Deploy будет регистрировать серверы виртуализации при каждой загрузке. Сделать это можно с помощью команды:
vifp addserver <АДРЕС_VCENTER>
, где: <АДРЕС_VCENTER> - DNS имя или IP адрес сервера.

На запрос системы введите имя и пароль учетной записи пользователя, которая имеет административные права на сервере vCenter.

Для проверки успешности добавления сервера можете воспользоваться командой:
vifp listservers

Для каждого сервера виртуализации, который хотя бы раз загрузился, используя Auto Deploy создается отдельная запись в базе "/var/lib/deploy/db". Для просмотра записей вы можете воспользоваться командой:
deploy-cmd listhosts

Каждую запись характеризует следующий набор параметров:

• Boot MAC - MAC адрес сетевой карты, с которой осуществляется загрузка по PXE.
• IP Address - IP адрес, назначенный DHCP сервером.
• Asset Tag - идентификатор данного компьютера.
• Boot Profile - профиль, используемый для загрузки.
• Status - состояние сервера (дата последней загрузки по сети).

Вы можете создать записи для ваших серверов заранее, используя команду:
deploy-cmd addhost --bootmac=<MAC_АДРЕС> --profile=<ПРОФИЛЬ>

При каждой загрузке сервера виртуализации Auto Deploy просматривает базу и, исходя из назначенного серверу профиля, передает ему нужный загрузочный образ ESXi, а также регистрирует сервер в vCenter, применяет Host Profiles и п.р.

Для просмотра списка доступных профилей используйте команду:
deploy-cmd listprofiles

По умолчанию в Auto Deploy присутствует лишь один профиль - default. Для редактирования настроек профиля используется команда deploy-cmd updateprofile:
deploy-cmd updateprofile --name=default --vcenter=<АДРЕС_VCENTER> --hostprofile=<ИМЯ_HOST_PROFILE> --hostfolder=<ПУТЬ_К_ПАПКЕ>
, где: <ПУТЬ_К_ПАПКЕ> - путь, включающий в себя имя датацентра, в котором требуется зарегистрировать сервер виртуализации. При необходимости включения сервер в HA кластер, путь к папке можно указать в формате "/<ИМЯ_ДАТАЦЕНТРА>/<ИМЯ_КЛАСТЕРА>".

Например, следующая команда позволит настроит профиль default так, чтобы Auto Deploy автоматически регистрировал серверы в vCenter и применял к ним ранее созданный Host Profile:

Теперь перезагрузите сервер. Если вы выполнили все настройки правильно, то после загрузки сервер будет автоматически добавлен в vCenter, переведен в режиме обслуживания (Maintenance Mode), для него будут применены настройки из соответствующего профиля, после чего он будет переведен обратно в штатный режим работы.

Дополнительные сведения
Для всех серверов настоятельно рекомендуется создавать резервации в DHCP, это позволит серверу не только получать каждый раз один и тот же IP адрес, но и задавать ряд индивидуальных настроек, в частности - имя сервера (параметр 012 Host Name).

Если вас не устраивает, что в vCenter серверы ESXi регистрируются по IP адресу, а не по DNS имени, то исправить это можно, создав соответствующие PTR записи в reversed lookup зоне на DNS сервере, который обслуживает vCenter.

Наконец, я заметил следующую закономерность. При тестах использовались  виртуальные серверы ESXi. Частенько при добавлении такого сервера в кластер, если для него выделено меньше 3 Гб памяти, можно получить следующее сообщение об ошибке:  "Cannot complete the configuration of the HA agent on the host. Other HA configuration error".

Заключение
Как вы видите VMware Auto Deploy крайне прост в настройке и работе. Тем не менее, его применение рождает следующие вопросы - кто же будет загружать виртуальные машины с Auto Deploy и vCenter, чтобы те, в свою очередь, загружали серверы виртуализации, почему функционал Host Profiles доступен только в редакции Enterprise Plus, и когда в профилях появится поддержка программного инициатора iSCSI?

Установка приложений в среде VMware View 4.5 + ThinApp 4.6

Рабочие станции, пускай и виртуальные, предназначены, в первую очередь, для запуска пользовательских приложений. А чтобы запустить приложение, требуется его установить (а иногда и купить). По этой причине сегодня мы рассмотрим различные варианты установки приложений, виртуализованных с помощью VMware ThinApp 4.6, которые можно использовать для виртуальных рабочих станций, а в частности - для VMware View 4.5.

Варианты установки
Установка приложений в мастер-образ. Многие распространенные приложения, не требующие частых обновлений, такие как архиваторы или программы для чтения документов и просмотра изображений могут быть установлены в эталонный образ, который послужит основой для создания виртуальных рабочих станций. Однако не следует увлекаться и записывать в мастер-образ весь возможный набор приложений. Во-первых, пользователь может запутаться от обилия ярлыков на рабочем столе (должно же на нем еще оставаться место, что хранить документы и папки) и запустить что-то ненужное, во-вторых, увеличит занимаемое клонированными образами дисковое пространство, в-третьих, усложнит процедуру администрирования рабочих станций и обновления приложений. Хотя при назначении разрешений на запуск приложений с помощью ThinApp или групповых политик, использовании дифференциальных дисков (Linked Clones) и функции Recompose вы можете достаточно просто решить эти проблемы.

Копирование и установка приложений вручную. Администратор может выполнять установку отдельных приложений, подключаясь к рабочей станции через vSphere Client или RDP. Кроме того существует простая и функциональная утилита psexec, позволяющая запускать программы и выполнять команды на удаленном компьютере без необходимости отвлекать пользователей от работы. Для установки приложений можно воспользоваться командой вроде этой:
psexec \\<имя_компьютера> /u <имя_пользователя> msiexec /i \\<имя_сервера>\<путь_к_установочному_файлу> /qn

Для некоторых приложений вы можете разрешить рядовым пользователям без административных прав самостоятельно производить установку. В этом случае приложение будет установлено в каталог %AppData% пользователя вместо %ProgramFiles% и будет доступно лишь этому пользователю. Такой вариант может является предпочтительным для  приложений вроде текстовых редакторов или программ обмена мгновенными сообщениями. Для включения режима индивидуальной установки при упаковке приложения с помощью ThinApp требуется отредактировать параметр MSIDefaultInstallAllUsers в файле Package.ini и установить его значение в 0.

Для этого выполните следующие действия. При создании пакетированного приложения с помощью ThinApp в окне Package Settings выберите Generate MSI Package.

Перед финальной сборкой в окне Ready to Build нажмите Edit Package.ini.

При желании вы можете задать параметр MSIDefaultInstallAllUsers=2 и разрешить как административную установку для всех пользователей, так и индивидуальную установку (в зависимости от прав, которыми обладает учетная запись, от имени которой был запущен установочный файл).

Использование групповых политик - данный вариант предоставляет неплохие возможности по автоматизации процесса установки, удаления и обновления приложений, что называется 'из коробки'.

Использование средств электронной дистрибуции ПО (например, Microsoft SCCM 2007). Наиболее функциональный вариант из представленных, позволяет полностью автоматизировать процесс установки, а также проводить инвентаризацию ПО, хотя и требует покупки дополнительных лицензий, установки агентов и настройки серверов управления.

Наконец, начиная с версии 4.5 в VMware View есть собственные встроенные механизмы публикации приложений, виртуализованных с помощью ThinApp. Публиковать приложения можно на пул или на отдельные виртуальные рабочие станции.

VMware View предоставляет на выбор два режима установки:

• В полном (Full) режиме приложение устанавливается на виртуальную рабочую станцию, создает ярлык на рабочем столе и настраивает ассоциации с нужными типами файлов. Процесс установки выполняется в фоновом режиме и не требует от пользователей каких-либо действий. Запуск приложения выполняется с диска виртуальной рабочей станции.
• В потоковом (Streaming) режиме на рабочем столе пользователя создается ярлык, указывающий на исполняемый файл .exe приложения, расположенный на файловом сервере. Запуск приложения выполняется с общей сетевой папки файлового сервера. Такой вариант установки с одной стороны позволит сэкономить место на хранилище, на котором располагаются диски виртуальных рабочих станций, особенно в случае, когда пользователи запускают одинаковый набор приложений, с другой - приведет к увеличению нагрузки на сеть. Также учтите, что в случае отсутствия доступа к файловому серверу, например, при запуске ВМ в Local Mode режиме, приложения не смогут запуститься.

Пример публикации приложений с помощью VMware View
Перед тем, как опубликовать приложение вам потребуется соответствующим образом упаковать его с помощью Setup Capture, входящего в состав VMware ThinApp 4.6. Для режима полной установки достаточно будет создать .msi файл, содержащий нужное приложение.

Для Streaming режима перед сборкой вам потребуется отредактировать файл настроек Package.ini и установить параметр MSIStreaming=1. В этом случае после создания пакета размер .msi файла не превысит нескольких мегабайт и для корректной установки вам потребуется сохранять его вместе с созданным .exe файлом.

После завершения создания пакетов приложений скопируйте их в общую папку на файловом сервере. Убедитесь, что сервер View Connection Server и виртуальные рабочие станции имеют доступ к данной папке. Учтите, что в Streaming режиме доступ к папке будет осуществлять из-под учетной записи пользователя, запускающего приложение. В большинстве случаев стандартных разрешений будет достаточно.

Запустите консоль View Administrator добавьте общую папку файлового сервера в список репозиториев: View Configuration -> ThinApp Configuration кнопка Add Repository.

В поле Display Name введите имя репозитория, в поле Share path введите UNC путь к общей папке, содержащей упакованные приложения (в формате \\<имя_сервера>\<имя_папки>). При желании можете добавить дополнительное описание в поле Description.

Нажмите Save.

Просканируйте и добавьте приложения в список доступных. В консоли View Administrator выберите Inventory -> ThinApps. На вкладке Summary нажмите Scan New ThinApps.

Выберите одно из расположений, добавленных ранее и папку для сканирования, и нажмите Next.

Выберите одно или несколько (с помощью зажатых клавиш CTRL или SHIFT) приложений из списка доступных и нажмите Scan.

После завершения сканирования вы увидите перечень добавленных приложений. Нажмите Finish.

Добавленные приложения появятся в окне на вкладке Summary.

Для назначения приложений вы можете воспользоваться той же вкладкой Inventory -> ThinApps. Выберите необходимое приложение из списка и нажмите Add Assigment и в контекстном меню выберите область назначения - на пул (Pools...) или на рабочие станции (Desktops...).

В открывшемся окне выберите один из двух доступных типов установки (Installation type): Streaming или Full и с помощью кнопки Add... добавьте один или несколько пулов или рабочих станций на которые требуется назначить приложение. Нажмите OK для сохранения настроек.

Теперь пользователям достаточно будет подключиться к своим рабочим станциям и приложение будет автоматически установлено. Учтите, что при использовании Full режима в зависимости от размера приложения для копирования и установки может потребоваться некоторое время, поэтому ярлык может появится не сразу.

Обновление опубликованных приложений
Установка приложений - половина дела. Когда-нибудь вам придется их обновить. ThinApp предоставляет несколькомеханизмов по обновлению приложений, однако их использование совместно с VMware View имеет свои нюансы.

Для обновления приложения вам потребуется выполнить следующие шаги:

1. Удалить назначенное приложение (Remove Assigment) с пула или рабочих станций.
2. Подождать, пока все пользователи войдут на свои рабочие станции, чтобы устаревшая версия приложения удалилась.
3. Удалить устаревшее приложение из списка ThinApps.
4. Скопировать обновленную версию приложения на файловый сервер и добавить его в список ThinApps.
5. Назначить обновленную версию приложения на пул или рабочую станцию.
6. Подождать, пока все пользователи войдут на свои рабочие станции, чтобы обновленная версия приложения установилась.

Не слишком просто и быстрый вариант, учитывая, что из-за некоторых пользователей процесс обновления может растянуться на несколько дней. С другой стороны, для Linked Clones машин также может быть выполнен Refresh, который вернет виртуальную машину к исходному состоянию и удалит установленные приложения.

В ряде случаев вовсе необязательно выполнять полную установку приложения, и достаточно только обновить исполняемые файлы. Для Streaming режима это сделать проще, поскольку достаточно заменить файлы в общей папке, после чего все пользователи смогут запускать обновленную версию приложения.

Более корректным вариантом является использование встроенного механизма обновления, поддерживаемого в ThinApp - исполняемый файл обновленной версии приложения переименовывается из <имя_приложения>.exe в <имя_приложения>.1 (например, "Adobe Reader.1") и помещается в ту же папку, что и исполняемый файл старого приложения. При следующем запуске приложение автоматически обнаружит наличие обновленной версии и запустит ее. При этом пользователи, работающие с текущей версией приложения, смогут продолжать с ней работать до следующего запуска. При необходимости последующего обновления приложения вы можете просто добавлять новые версии .3 или .4 и удалять устаревшие .1 или .2, по мере того, как пользователи будут прекращать работать с ними.

Для Full режима установки ситуация несколько отличается. Вы можете настроить приложение на автоматическую проверку обновленной версии при каждом запуске, указав при создании пакета в параметре AppSyncURL в файле Package.ini путь к обновленной версии на файловом сервере в формате file://<имя_сервера>/<путь_к_файлу> или http://<имя_сервера>/<путь_к_файлу> (например: "file://Fileserver/Software/Firefox/Firefox.exe").

Но поскольку приложение в Full режиме копируется в подпапку в %ProgramFiles%, то для для выполнения установки у учетной записи должны быть права локального администратора, либо права на запись в указанную папку, что довольно рискованно делать для рядовых пользователей даже на индивидуальных виртуальных рабочих станций.

Наконец, вы можете написать скрипт, который бы копировал обновленные версии приложений в нужные папки, однако, выглядит это уже не так удобно и функционально, как хотелось бы.

На сегодня всё.

Статья: Сравнение решений компаний Microsoft и VMware в области виртуализации серверной инфраструктуры

Каждый уважающий себя ресурс по виртуализации хотя бы раз в жизни должен опубликовать сравнение решений Microsoft и VMware. И поскольку VM Press наполнен сам к себе глубоким глубочайшим уважением, то я решил немного подправить свою старую статью, которую делал для знакомых, и представить ее вашему вниманию.

Введение
На сегодняшний день все больше компаний применяют различные решения по виртуализации в своей ИТ инфраструктуре. Так, например, по оценкам аналитического агенства IDC в четвертом квартале 2009 года 18.2% всех поставляемых на рынок серверов использовали те или иные решения по виртуализации. Цифры выглядят не слишком впечатляющими, если не брать в расчет тот факт, что на одном физическом сервере может размещаться, в среднем, от 5-ти до 10 виртуальных машин. Именно за счет столь впечатляющих показателей консолидации вычислительных ресурсов, многие компании рассматривают виртуализацию как основное средство повышения эффективности работы собственной ИТ инфраструктуры.

Виртуализация позволяет не только существенным образом сократить капитальные и операционные затраты на поддержку ИТ инфраструктуры компании, но также упрощает развертывание и управление бизнес-сервисами и предоставляет новые механизмы по повышению уровня доступности сервисов, гарантируя исполнение соглашения об уровне услуг (SLA).

Двумя крупнейшими игроками, предоставляющими решения по виртуализации инфраструктуры, являются компании VMware и Microsoft. Обе компании предлагают различные подходы к организации виртуальной инфраструктуры и предоставляют собственный набор фирменных технологий и решений в области виртуализации.

Ниже будут рассмотрены ключевые особенности организации виртуальной инфраструктуры на базе VMware vSphere 4.1 и Microsoft Hyper-V 2008 R2 и Microsoft System Center Virtual Machine Manager 2008 R2 и описаны преимущества каждого из решений по виртуализации.

Гипервизоры
Решения обеих компаний предоставляют схожий фукнционал в плане создания и конфигурации виртуальных машин, запуска, приостановки работы, создания моментальных снимков, удаленного подключения через служебную консоль и управления виртуальными машинами.

Компания VMware предоставляет комплексное решение по виртуализации инфраструктуры – VMware vSphere 4.1, которое включает в себя как серверы виртуализации (гипервизоры), так и инструменты управления инфраструктурой.

На выбор доступны два варианта гипервизоров – VMware ESXi или VMware ESX. Основное отличие гипервизоров заключается в наличии у VMware ESX так называемой служебной консоли (Service Console) – специализированной виртуальной машины, отвечающей за управление сервером ESX и позволяющей устанавливать программы-агенты сторонних производителей (средства мониторинга и контроля дисковых массиов, переферийного оборудования, ИБП и т.д.). VMware ESXi, в свою очередь, имеет меньший размер, что позволяет записать его, например, на flash накопитель, позволяя отказаться от размещения жестких дисков внутри сервера, снижая, тем самым, энергопотребление и тепловыделение сервера и повышая его надежность за счет уменьшения количества механических компонентов.
Отличительными особенностями гипервизоров VMware ESX/ESXi являются:

• Поддержка большинства современных и унаследованных ОС семейств Windows, Linux или Unix.
• Хранение и запуск виртуальных машин с локальных дисков или хранилищ (DAS), сетей хранения данных (SAN), подключающихся по протоколам Fibre Channel, iSCSI, а также сетевых хранилищ (NAS), использующих протокол NFS.
• Поддержка кластерной файловой системе VMFS для доступа к виртуальным машинам одновременно с нескольких узлов.
• Удаленное управление с помощью клиент VMware vSphere Client, с помощью консоли SSH, набора скриптов (RemoteCLI) или модуля расширения для PowerShell (PowerCLI).
• Поддержка технологий управления и экономии оперативной памятью (Memory Overcommitment), позволяющих улучшить показатели консолидации инфраструктуры по сравнению с решениями конкурентов.
• Поддержка проброса в отдельные виртуальные машины физических устройств с сервера (VMDirectPath I/O), а также устройств, подключенных по шинам USB (USB device passthrough) или COM.
• Возможность настройки последовательности и интервала запуска виртуальных машин при старте или перезагрузке физического сервера.
• Поддержка ˈгорячегоˈ добавления виртуальных устройств: процессоров, памяти, дисков, контроллеров и сетевых карт.

Компания Microsoft предоставляет гипервизор Hyper-V R2 в качестве одной из ролей своей ОС Windows Server 2008 R2 (Hyper-V Role), либо отдельного продукта – Hyper-V Server 2008 R2. Среди особенностей Microsoft Hyper-V 2008 R2 следует отметить:

• Небольшой размер кода гипервизора.
• Поддержку широкого перечня современного аппаратного обеспечения.
• Наличие родительской виртуальной машины (Parent Partition) для управления сервером Hyper-V и распределения ресурсов другим виртуальным машинам (Child Partition).
• Возможность размещения виртуальных машин на локальных дисках или на СХД, подключаемых по протоколам SCSI, Fibre Channel или iSCSI.
• Управление через MMC консоль Hyper-V Manager, или с помощью средств командной строки (Powershell, CMD и т.д.).
• Поддержку отказоустойчивых кластеров (Failover Cluster), включих до 16 узлов.
• Поддержку переноса виртуальных машин с одного узла кластера на другой – Live Migration.
• Интеграцию с доменной инфраструктурой на базе Active Directory.
• Наличие встроенных средств резервного копирования и восстановления виртуальных машин с помощью Windows Server Backup.
• Совместную интеграцию со службами Microsoft Remote Desktop Services для развертывания инфраструктуры виртуальных рабочих станций (VDI).

Централизованное управление
Для крупной ИТ инфраструктуры, насчитывающей десятки или даже сотни серверов виртуализации, работа с каждым сервером в отдельности может стать весьма утомительным и трудоемким занятием. Для решения этой проблемы VMware и Microsoft предлагают свои решения по централизованному управлению виртуальной инфраструктурой.

VMware vCenter Server позволяет:

• Централизованно управлять серверами ESX/ESXi. Несколько серверов vCenter Server могут быть объединены в связанную группу (Linked Groups) для контроля всей виртуальной инфраструктурой из единой консоли.
• Создавать виртуальные машины копированием из заранее настроенных шаблонов для упрощения и ускорения развертывания новых серверов.
• Выполнять автоматическое обновление виртуальных машин, шаблонов и других компонентов виртуальной инфраструктуры с помощью VMware vCenter Update Manager.
• Контролировать и динамически перераспределять вычислительные ресурсы серверов виртуализации (процессоры, память, диски) при помощи пулов ресурсов (Resource Pool).
• Настраивать кластеры высокой доступности (High Availability) и управлять кластерами с распределением ресурсов (Distributed Resource Schedule).
• Выполнять операции переноса виртуальных машин (vMotion и Storage vMotion).
• Мигрировать при помощи VMware vCenter Converter в виртуальную среду существующие физические серверы и виртуальные серверы с других платформ.
• Следить за состоянием гипервизоров и виртуальных машин, создавать отчеты по текущей загрузке инфраструктуры и настраивать выполнение задач по расписанию.
• Настраивать разрешения на управление виртуальной инфраструктурой для учетных записей пользователей.
• Создавать и настраивать распределенные виртуальные коммутаторы (Distributed vSwitches) для централизованного управления виртуальной сетевой инфраструкторой.
• Использовать профили узлов (Hosted Profiles) для быстрого изменения настроек серверов ESX и контроля изменений в их конфигурации.
• Подключать плагины сторонних производителей для управления виртуальной инфраструктой (системами резервного копирования, средствами конвертирования виртуальных машин, антивирусной защитой, управления СХД и т.д.).
• Интегрироваться с VMware View и Citrix XenDesktop для создания инфраструктуры виртуальных рабочих станций (VDI).

Решение Microsoft System Center Virtual Machine Manager 2008 R2 предоставляет следующий функционал:

• Единую консоль управление серверами виртуализации Microsoft Hyper-V и Microsoft Virtual Server 2005 и
• Поддержку управления серверами VMware ESX/ESXi с помощью vCenter Server.
• Поддержку развертывания виртуальных машин из шаблонов.
• Использование библиотек (SCVMM Library) для хранения и организации централизованного доступа к ISO образам дистрибутивов, дискам и шаблонам виртуальных машин.
• Установку актуальных обновлений для виртуальных маши, используя Offline Virtual Machine Servicing Tool.
• Встроенные средства по миграции физических серверов (P2V) и виртуальных серверов (V2V) в инфраструктуру Hyper-V.
• Использование портала самообслуживание для управления виртуальными машинами из Web браузера.
• Выполнение операции Quick Storage Migration для переноса виртуальных машин между хранилищами.
• Интеграцию с Microsoft System Center Operation Manager 2007.
• Интеграцию с Citrix XenDesktop для создания инфраструктуры виртуальных рабочих станций (VDI).
• Поддержку удаленного управления с помощью коммандлет PowerShell.

Технологии повышения доступности виртуальной инфраструктуры
Для повышения надежности работы и уровня доступности виртуальной инфраструктуры каждый из вендоров предоставляет набор технологий для защиты виртуальных машин.

Так, например, технологии VMware vMotion и Microsoft Live Migration обеспечивают перенос работающих машин с одного физического узла на другой в реальном времени без остановки и простоя служб. Это может быть полезно как при проведении технического обслуживание одного из серверов виртуализации, так и при постепенной замене оборудования или обновлении инфраструктуры виртуализации. Аналогично, при необходимости переноса виртуальной машины с одного диска или хранилища на другое могу быть использованы технологии VMware Storage vMotion или Microsoft Quick Storage Migration.

Для снижения времени незапланированного простоя виртуальной среды применяются решения VMware High Availability и Microsoft Failover Cluster. Все защищаемые виртуальные машины должны располагаться на общем хранилище к которому имеют доступ несколько узлов виртуализации, объединенных в кластер. Сбой или отказ одного из узлов отслеживается остальными участниками кластера, а запущенные на нем виртуальные машины автоматически регистрируются и перезапускаются на оставшихся работоспособных узлах. Использование кластеров высокой доступности позволяет уменьшить время незапланированного простоя серверов до 5-20 минут.

Серверы VMware ESX поддерживают организацию двух типов кластеров: высокодоступные кластеры (HA – High Availability) и кластеров с распределением ресурсов (DRS – Distributed Resource Schedule).

Для первоначальной настройки кластера HA, требуется, чтобы все узлы были зарегистрированы на одном сервере VMware vCenter Server, а также были подключены к общему хранилищу, на котором располагаются виртуальные машины. При отказе одного сервера, работавшие на нем виртуальные машины автоматически перезапускаются на других доступных узлах HA кластера.

Кластер DRS позволяет серверу VMware vCenter Server балансировать нагрузку, равномерно распределяя виртуальные машины между всеми узлами и, при необходимости, выполняя перенос виртуальных машин на наименее загруженные узлы.

Одной из разновидностей DRS кластера является кластер распределенного управления питанием (DPM – Distributed Power Management), позволяющий выключать часть серверов ESX при низкой загрузке на серверы, снижая тем самым энергопотребление, и включая их снова, при возникновении потребности виртуальных машин в вычислительных ресурсах.

Кроме того, VMware предоставляет уникальный механизм непрерывной защиты наиболее критических сервисов, путем запуска дополнительной копии виртуальной машины на другом узле, и синхронизации в реальном времени состояния между основной (primary) и дополнительной (secondary) копиями виртуальной машины. В случае сбоя основного сервера, все управление и запросы переходят к дополнительной виртуальной машины без простоя.

Для защиты виртуальных машин Hyper-V от незапланированного простоя используются отказоустойчивые кластеры (Failover Cluster), построенные на базе служб Microsoft Clustering Services, доступных. Для кластера требуется наличие общего дискового хранилища для размещения виртуальных машин, а также доменной инфраструктуры Active Directory.

Системая мониторинга и управления ресурсами (PRO Tips) в SCVMM 2008 R2, работающая совместно с SCOM 2007 R2, отслеживает разничные параметры виртуальной инфраструктуры: доступные вычислительные ресурсы, загрузку физических и виртуальных машин, наличие ошибок в работе различных компонентов и служб, и на основании полученных данных выдавать рекомендации по оптимальному размещению виртуальных машин на кластерах серверов Hyper-V.

Резервное копирование
Виртуальная инфраструктура меняет подход к организации резервного копирования, позволяя отказаться от классической схемы установки агентов и выполнения резервного копирования каждого сервера в отдельности. Вместо этого, доступны решения, позволяющие защищать все виртуальные машины на сервере в реальном времени.

VMware Data Recovery (VDR) позволяет осуществлять централизованное резервное копирование виртуальных машин VMware ESX на локальные диски или сетевую папку по расписанию. Преимущество VDR заключается в использовании технологии дедупликации данных, которая позволяет уменьшать размер резервной копии. VDR позволяет восстанавливать как виртуальные машины целиком, так и отдельные папки и файлы.

Microsoft DPM 2010 позволяет выполнять резервное копирование и восстановление виртуальных машин, расположенных на серверах Hyper-V, а также устанавливать агенты внутри виртуальных машин для резервирования данных приложений (баз SQL серверов, почтовых ящиков Exchange и порталов SharePoint).

Лицензирование
Оба вендора предоставляют решения как для малого и среднего бизнесы, так и для крупных компаний.
Для небольших компаний или удаленных филиалов с несколькими серверами, которым не требуется централизованное управление, доступна бесплатная версия VMware ESXi Free.

Компаниям, испытывающим необходимость в централизованном управлении виртуальной инфраструктурой, предлагаются VMware vSphere Essentials и Essentials Plus, в которые входят лицензии на три двухпроцессорных сервера и одна лицензий VMware vSphere Essentials. Дополнительно, в лицензии Essentials Plus доступны средства резервного копирования VMware Data Recovery, организации HA кластера и выполнения переноса vMotion между узлами.

Для средних и крупных компаний доступны различные типы лицензий для серверов ESX (редакции от Standard до Enterprise Plus) и vCenter Server (редакции Foundation или Standard), обеспечивающих требуемый функционал.

При выборе решений от компании Microsoft, возможно использование гипервизора входящего в состав ОС Windows Server 2008 R2 в редакциях Standard, Enterprise или Datacenter, либо поставляемого в виде отдельного бесплатного продукта Microsoft Hyper-V Server 2008 R2.

Для централизованного управления небольшой инфраструктурой Hyper-V могут применяться продукты System Center Essentials 2010 или System Center Virtual Machine Manager 2008 R2 Workgroup Edition (позволяет управлять пятью серверами виртуализации).

Для средних и крупных компаний доступен SCVMM 2008 R2 в качестве отдельного продукта, либо в составе пакетов лицензий System Center Server Management Suite Enterprise (SMSE) и Datacenter (SMSD), включающих в себя, помимо SCVMM, другие продукты линейки System Center (SCCM, SCOM, SCDPM и т.п.) и предоставляющие расширенные права на установку агентов и управление виртуальными машинами, запущенными на лицензированном сервере.

Заключение
Как видите обе компании предлагают функциональные, гибкие и надежные решения по организации и управлению виртуальной средой Вашей компании. Выбор же конкретного продукта зависит от размера организации, и, само-собой, от тех требований, которые бизнес предъявляет к современной ИТ инфраструктуре: функциональность, доступность, экономичность и простота в управлении. Чего и позволяет добиться серверная виртуализация.