"Железная" виртуализация серверов

ОБЗОРЫ  

Гибкое и недорогое решение Virtual Iron 3.5

ПО Virtual Iron одноименной компании, построенное на гипервизоре Xen и других компонентах с открытым исходным кодом, представляет собой эффективное и недорогое решение виртуализации, и не исключено, что его невысокая стоимость заставит призадуматься лидера этого рынка - VMware.

При тестировании Virtual Iron 3.5 в Тестовом центре eWeek Labs нас особенно впечатлили его возможности распределения ресурсов. Мы попросту подключали хост-серверы, предназначенные для поддержки виртуальных систем, к сети управления, и управляющий сервер Virtual Iron загружал на них среду PXE (Preboot Execution Environment). Тотчас же после этого мы могли приступать к созданию виртуальных машин с припиской их к нашим узлам.

При проверке Virtual Iron 3.5 в eWeek Labs нас особенно впечатлили возможности распределения ресурсов.

Мы просто подключали свои хост-серверы для поддержки виртуальных систем к сети управления, и с

управляющего сервера Virtual Iron на них загружалась среда PXE. Сразу после этого можно было

приступать к созданию ВМ с припиской их к нашим узлам

Одним из главных отличий Virtual Iron 3.5 от его более ранних аналогов на основе Xen является способность продукта обеспечивать виртуализацию практически всех ОС для платформ x86 или x86-64 без специальной модификации ядер под Xen. Это важное достоинство Virtual Iron и другие нынешние продукты для виртуализации на базе Xen приобрели благодаря функционированию на процессорах Advanced Micro Devices и Intel с аппаратными расширениями соответственно AMD-V и Intel VT.

Самое главное, что новые аппаратные средства теперь позволяют Xen поддерживать Windows - такая способность долгое время считалась привилегией продуктов VMware. Однако в отличие от XenEnterprise компании XenSource пакет Virtual Iron 3.5 не работает на аппаратуре без виртуализационных расширений, и это может озадачить пользователей, надеявшихся на виртуализацию, чтобы получать максимальную отдачу от уже имеющегося оборудования.

Тем не менее имеющиеся в Virtual Iron расширения постепенно становятся аппаратурной нормой. Более того, если учесть ценовые выгоды Virtual Iron по сравнению с продуктами VMware, то предприятия, выбирающие это ПО, вероятно, смогут позволить себе часть сэкономленных средств употребить на модернизацию оборудования.

Полнофункциональный корпоративный вариант Virtual Iron 3.5, включающий функции онлайнового переноса виртуальных машин, отработки отказов и управления объемом выделяемых ресурсов, а также поддержку сетевой памяти Fibre Channel SAN и iSCSI, стоит $499 в расчете на каждый цельный процессор. Столько же - $1000 за пару "процессорных гнезд" - стоит и начальный вариант предложения VMware (Virtual Infrastructure 3 Starter), который, однако, не поддерживает SAN и iSCSI. А вот VMware VI3 Standard продается уже по $3750 за пару процессоров, а VI3 Enterprise, где добавляется поддержка оперативного переноса VMotion и другие функции высокой готовности, обойдется в $5750 за два цельных процессора.

Мы протестировали Virtual Iron 3.5 Enterprise Edition, используя бесплатную 30-дневную пробную лицензию (www.virtualiron.com/products/free_download.cfm). В бесплатном варианте есть еще односерверная версия Virtual Iron, в которой управляющий сервер и хост виртуализации умещаются на одной физической системе.

Управление

Управляющий сервер Virtual Iron может работать в среде Linux и Microsoft Windows - а если конкретно, то под управлением 32- и 64-разрядных вариантов RHEL (Red Hat Enterprise Linux) 4 U2 (Update 2) и U4 (Update 4) фирмы Red Hat; под 32- и 64-разрядными версиями SLES (SUSE Linux Enterprise Server) 9 SP (Service Pack) 3 компании Novell, а также под 32-разрядными Windows XP Professional и Windows Server 2003.

eWeek Labs протестировала Virtual Iron (управляющий сервер действует на базе Java) в средах Windows Server 2003 SP2 и CentOS 4.2 (клон RHEL 4 U2).

Для Windows-гостей инструменты VS Tools принимают вид инсталляционного exe-файла с адаптированными

под Virtual Iron драйверами устройств. Для Linux в Virtual Iron имеются бинарные пакеты с драйверами,

которые скомпилированы под поддерживаемые ядра

Столь же дружествен к разным платформам и присутствующий в Virtual Iron компонент Management Console - довольно богатое приложение, связанное с технологией Java Web Start фирмы Sun Microsystems. Пользуясь этой консолью, мы могли с одинаковым удобством управлять нашими узлами и из Windows, и из Linux, что особенно радует на фоне впечатлений от нашего недавнего тестирования продукта VMware VI3, который всецело привязан к Windows со стороны как серверного, так и клиентского ПО управления.

Virtual Iron может быть хостом почти любой ОС, созданной для архитектур x86 или x86-64, однако немало его функций обеспечиваются добавочным ПО под названием Virtual Server Tools, которое умеет работать лишь с избранными ОС (с теми же версиями Windows и Linux, в которых можно инсталлировать управляющий сервер Virtual Iron).

Без VS Tools не действуют такие функции Virtual Iron, как LiveMigrate и LiveRecovery, которые при использовании управляющей консоли позволяют видеть информацию о производительности гостевых виртуальных машин (ВМ) и корректно (образно говоря, без грубого выдергивания виртуальных вилок) завершать работу этих ВМ или перезагружать их.

Для Windows-гостей эти инструменты принимают вид инсталляционных exe-файлов с адаптированными под Virtual Iron драйверами устройств. А для Linux в Virtual Iron имеются бинарные пакеты с драйверами, которые скомпилированы под поддерживаемые ядра.

По нашему мнению, разработчикам Virtual Iron стоило бы смягчить свой подход к поставке этих средств для Linux. Ведь в VMware, например, администраторы вовсе не ограничены небольшой группой заранее заготовленных опций, а могут компилировать драйверы под фактически используемое ядро.

Подобная гибкость помогла бы избежать одной загвоздки, с которой мы столкнулись при тестировании. Мы инсталлировали x86-64-версию CentOS 4.4, и, вероятно, потому, что созданная ВМ задействовала один процессор, установщик CentOS 4.4 инсталлировал однопроцессорную версию ядра Linux. Однако VS Tools из Virtual Iron существуют только в симметрично-мультипроцессорных SMP-вариантах и для их корректной установки требуется SMP-ядро. Когда же мы для нашей системы инсталлировали из сетевого репозитория SMP-ядро, оказалось, что его версия отличается от версии, к которой приспособлены средства пакета VS Tools, и, чтобы последние как-то работали, нам пришлось вернуться к прежнему ядру.

Несколько удивляет, что Virtual Iron не предлагает VS Tools под rPath Linux, хотя Virtual Iron имеет договоренность с rPath, согласно которой та добавляет Virtual Iron как опцию компоновки "программных приставок" (software appliances), создаваемых при помощи платформы rBuilder.

В ходе тестов мы загрузили rPath-устройство MediaWiki в формате Virtual Iron, поместили его виртуальный диск в подходящую папку нашего управляющего сервера Virtual Iron и приписали этот диск к новой ВМ. Однако без поддержки VS Tools от виртуального устройства куда меньше пользы. При реальной нужде мы, наверное, смогли бы адаптировать для работы нашего MediaWiki поддерживаемое ядро Red Hat, но хотелось бы, чтобы такие вопросы решали разработчики из Virtual Iron.

Создание ВМ

Создавать новые ВМ при помощи Virtual Iron Management Console не так уж сложно, но процесс не настолько отшлифован, как в аналогичных продуктах VMware. Например, при конфигурировании установок ВМ, касающихся процессоров, ОЗУ, сетевых адаптеров и виртуальных дисков, приходится прыгать по разным секциям консоли. В тестах же VI3 мы подключали свои серверы VMware ESX к серверу FTP, где хранились и инсталляционные образы ОС. Далее мы могли подключать эти образы к созданным ВМ в качестве виртуальных CD- или DVD-дисков, осуществлять из них инсталляцию, а после установки ВМ пользоваться доступом к их содержимому.

В Virtual Iron интерфейс создания ВМ имеет удобное выпадающее меню с наличными образами инсталляции, однако чтобы эти образы попали в список, они должны размещаться в специальной папке управляющего сервера. То есть вначале их нужно скопировать на этот сервер из обычного FTP-хранилища.

Нас удивило, что Virtual Iron не предлагает VS Tools под rPath Linux, хотя Virtual Iron имеет договоренность

с rPath, в соответствии с которой та добавляет Virtual Iron как опцию компоновки “программных устройств”,

создаваемых при помощи платформы rBuilder

В итоге мы отказались от использования системы Windows Server 2003, первоначально выбранной для хостинга управляющего сервера, заменив ее сервером CentOS 4.2 и смонтировав хранилище образов ОС как общий ресурс Sun NFS (Network File System). Затем в соответствующем каталоге Virtual Iron мы создали символьные ссылки на нужные нам iso-образы. Лично для нас этот обходной прием был не так уж сложен, поскольку мы все равно собирались проверить управляющий сервер и на Windows-, и на Linux-хосте, однако желательно, чтобы будущие версии Virtual Iron обеспечивали более гибкий доступ к хранилищам.

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

Функций мгновенных снимков состояния ВМ наподобие предлагаемых VMware также обнаружено не было, хотя мы могли клонировать свои виртуальные диски, чтобы потом возвращать ВМ к более раннему состоянию, заменяя текущее содержимое дисков клоном.

Для перевода гостевых систем в Virtual Iron при установленных VS Tools служит функция LiveMigrate, которая у нас сработала на "отлично". Сохраняя диски на iSCSI-устройстве, мы всего лишь перетаскивали ВМ мышью с одного узла на другой и нажимали кнопку подтверждения. Отдельная процедура переноса занимала меньше 15 с.

Мы имели доступ к ВМ и могли их контролировать через консольные окна, запущенные из интерфейса

 управления. При работе с виртуальными системами, для которых были инсталлированы VS Tools,

можно запускать, перезагружать или отключать ВМ, но нельзя их на время останавливать,

хотя это довольно привычная функция для других виртуализационных продуктов

Не столь гладко прошла проба функции LiveRecovery. Мы преднамеренно нарушили электропитание одного из узлов, служившего хостом для гостевых Windows Server 2003 и CentOS, однако управляющий сервер нас проинформировал, что автовосстановление не предпринималось, так как узел "возможно, еще активен".

Далее мы отсоединили один из узлов от управляющего сервера, но и это не привело к автоматическому запуску процедуры восстановления. Причиной загвоздок оказались функции защиты от так называемых "сценариев расщепленного интеллекта" (split brain scenarios), но мы поняли, в чем дело, только по окончании тестов.

Поддержка аппаратуры

Как мы уже говорили, для хост-узлов Virtual Iron необходимо серверное оборудование с технологиями AMD-V или Intel VT.

Сам управляющий сервер не требует какого-то конкретного типа процессора, но для него важна надежность с аппаратным резервированием и быстрый ввод-вывод, так как от этого зависит работа узлов. Virtual Iron 3.5 поддерживает максимум 32 процессора и 96 Гб ОЗУ на один хост-узел, а его гостевые ВМ могут рассчитывать на то, что им будет выделено до восьми процессоров.

Мы проверяли Virtual Iron 3.5 на паре серверов Dell PowerEdge 430, имевших процессоры Intel Pentium D 3 ГГц и по 2 Гб оперативной памяти. На каждом сервере было по три сетевых контроллера - для сети управления, для сети iSCSI, а также для доступа в Интернет и к другим серверам нашей среды. (Virtual Iron публикует информацию об аппаратной совместимости своих продуктов на странице www.virtualiron.com/products/ servers.cfm.)

Поддержка iSCSI в Virtual Iron появилась только в последней версии, 3.5, и официальный перечень поддерживаемой iSCSI-аппаратуры, понятно, пока еще скудноват. Поэтому мы воспользовались тем же самым самодельным исполнительным устройством iSCSI на базе Openfiler, с которым недавно проверяли VI3.

Мы смогли обеспечить доступ к тому, созданному для работы с Virtual Iron на iSCSI-устройстве при помощи

 Openfiler, разделить его на диски и нормально инсталлировать ВМ. Нам удалось инсталлировать

ВМ и на локальных дисках каждого узла, однако такая конфигурация не позволяет использовать

функциональность LiveMigrate

Поначалу, немного помучившись над конфигурированием сети, мы смогли обеспечить доступ к созданному в Openfiler тому для работы с Virtual Iron, поделить его на диски и спокойно инсталлировать ВМ. Нам удалось инсталлировать ВМ и на локальных дисках каждого из наших узлов, однако такая конфигурация не позволяет использовать LiveMigrate.

С аналитиком по новым технологиям Джейсоном Бруксом можно связаться по адресу: jason_brooks@ziffdavis.com.