eWeek Labs: В версии VMware vSpere 5.0 серьезно улучшены механизмы высокой доступности, управления памятью и работы в сети.

Новая версия VMware vSphere 5.0 продолжает задавать стандарты для виртуализации х86-серверов в центрах обработки данных. Она остается неоспоримым лидером и для тех ИТ-менеджеров, которым необходима виртуальная инфраструктура, успешно контролирующая производственные нагрузки и одновременно сдерживающая операционные расходы.

Тестовая лаборатория eWeek Labs изучила предварительную копию vSphere 5.0.

Оценивая технологию, ИТ-менеджеры должны обратить внимание на значительные изменения функций, включая механизм высокой доступности (High Availability — HA); созданный VMware планировщик распределенных ресурсов (Distributed Resource Scheduler — DRS) и новые инструменты сетевого мониторинга; полную опору на гипервизор ESXi.

Несмотря на изменения в модели лицензирования VMware, итог остается тем же: компании будут платить больше за использование компонентов масштаба предприятия, составляющих основу vSphere 5.0.

ИТ-менеджеры, уже использующие vSpere 4.0 или 4.1, быстро придут к тому, что необходимо ускорить переход на эту последнюю версию. Для опытных пользователей изменения, поддерживающие существующие функции — включая расширения в интерфейсе командной строки, технологии высокой доступности и эксклюзивное для VMware использование ESXi (хосты ESX все еще полностью поддерживаются в vSphere 5.0), — пусть и весьма мощные, не являются чем-то радикально новым по сравнению с предыдущими версиями. Там, где они значительно отличаются, как, например, в механизме высокой доступности, мои тесты показывают, что изменения, как правило, снижают период необходимого обучения.

Область, заслуживающая особого осмысления, — размеры и оснащение физических хостов. Новые максимальные конфигурации позволяют создать виртуальные машины с объемом оперативной памяти до 1 Тб и числом процессоров до 32. Я немного могу сказать по поводу того, как такие огромные системы будут в реальности работать. Наши относительно небольшие нагрузочные тесты, выполняемые на средне- и низкоскоростной памяти iSCSI, показали хорошие результаты.

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

Как мы тестировали

Я использовал четыре Intel-сервера, коммутаторы Cisco 3560G и систему управления внешней памятью OpenFiler iSCSI для хостинга предоставленной на августовский период предварительной версии VMware vSphere 5.0. Два серьезных сервера Hewlett-Packard, DL360 G6 и DL380 G6, были оборудованы процессорами Intel Xeon класса Nehalem. Два других сервера, Lenovo RD210 и Acer AR380 F1, использовали более мощные процессоры Intel и больший объем памяти — 12 и 24 Гб соответственно.

Первый тур тестов я начал с апгрейда на месте двух HP систем, перешедших с vSphere ESX 4.1 на ESXi 5.0. Перевод систем прошёл без запинки, однако я больше выиграл бы от более тщательного планирования в миграции памяти и сетевых настроек Virtual Machine File System (VMFS) — файловой системы VMware.

В новом релизе vSphere файловая система была обновлена с версии 3.0 сразу до 5.0. В версии VMFS 5.0 устранено форматирование с переменным размером блока — используются только блоки размером 1 Мб. надо сказать, что VMFS 5.0 может использовать любую файловую систему, однако для выработки рекомендаций о том, что может быть наилучшим вариантом для работы в смешанных средах, требуется дальнейшее тестирование и опыт эксплуатации в реальных условиях.

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

В подобной, хотя и не такой удачной манере я установил последнюю версию VMware vSphere Distributed Switch (vDS). В конце концов я отбросил все существующие сетевые настройки и переустановил их с нуля.

Хотя вполне можно переходить с vNetwork Standard Switches (виртуальный коммутатор, созданный на отдельном физическом хосте vSphere) на vDS, этот процесс требует тщательного планирования. Наилучшие шансы на успех будут обеспечены, если ИТ-менеджеры начнут с хостов, сконфигурированных с одинаковым количеством сетевых карт (NIC) и с одинаково сконфигурированными автономными Standard Switches.

vDS впервые появился в vSphere 4.0. Те, кто уже имеет опыт работы с ним, найдут процедуру его апгрейда относительно простой. Процесс будет несколько более сложным для организаций, переходящих со Standard Switches. Я выполнил различные варианты миграции — в основном с выключением виртуальных машин и переносом моего небольшого числа хостов на vDS — по одному за раз. Можно также использовать профили хостов для переноса физических хост-систем на vDS.

Наибольшие изменения vDS в vSphere 5.0 заключаются в добавлении некоторых базовых функций поиска и решения сетевых проблем. Я смог использовать недавно добавленный порт сетевого монитора (функция физического коммутатора, разработанная во времена динозавров) для анализа виртуального сетевого трафика без необходимости его перенаправления во внешнюю физическую сеть.

Добавление порта мониторинга — ключевой шаг в дальнейшем развитии VMware vDS. Старая поговорка “ты не можешь управлять тем, что не можешь мониторить” снова подтвердилась: добавление порта мониторинга представляет собой весьма серьезное улучшение в vDS.

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

Переход на vDS и грамотное конфигурирование его для реальной работы потребуют добавления значительной сетевой экспертизы в команду виртуализации. Объединение в пул сетевых карт физического хоста и конфигурирование профилей для корректного применения политик к этим объединенным ресурсам было перегружено деталями и легко ломалось по сравнению с процессом создания и обслуживания виртуальных машин.

Высокая доступность

Добавление новых функций обеспечения высокой доступности стало еще одним направлением, улучшившим обслуживание виртуальных машин в vSphere 5.0. Исчезли первичные и вторичные узлы, замененные концепцией “master-slave”, в результате чего отпала необходимость планировать размещение таких узлов. Вместо этого системы выбирают мастер-машину по мере необходимости.

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

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

Почти все конфигурирование было выполнено за кулисами vSphere 5.0. Я выполнил установку функционала высокой доступности на своей тестовой сети за несколько минут. Как и ожидалось, выдергивание из розетки сетевого шнура на разных хостах приводило к переключению виртуальных машин на запасной хост внутри кластера.

Впервые DRS, разработанный VMware, расширен функциями управления дисковой памятью. Подключение Storage DRS было крайне простым процессом задания политик для моих виртуальных машин. С течением времени Storage DRS самостоятельно принимал решения относительно наилучших хостов для конкретной виртуальной машины. Он выполнял также балансировку доступа виртуальных машин к ресурсам памяти в полном соответствии с уровнями сервиса, которые были указаны в моих политиках. Кроме того, vCenter Server теперь доступен как виртуальное решение.

Несмотря на то,что продукт продемонстрировал недостатки первой версии — например, сетевые детали, такие как DNS, в данный момент определяются через командную строку, а не с помощью Web-консоли — в целом устройство работало достаточно хорошо.

В течение некоторого времени VMware подталкивала пользователей отказаться от ESX и перейти на уменьшенную в размерах консоль ESXi. И вот vSphere 5.0 — первая версия, в которой присутствует только ESXi.