VMware vSphere 4.1 остается лидером на рынке корпоративных платформ виртуализации. Новые функции сетевого администрирования, управления памятью и хранением данных позволяют создать пул ресурсов большего масштаба и с меньшими потерями в производительности.
В vSphere 4.1 большое внимание уделено управлению виртуальными машинами, и ИТ-менеджерам следует посвятить изучению новых функций достаточно времени, чтобы с их помощью действительно улучшить использование хост-систем и автоматическое масштабирование систем виртуальных машин.
Занимаясь тестированием в eWeek Labs, я узнал, что vCenter 4.1 (командный и управляющий модуль виртуальной инфраструктуры VMware) теперь представлен только в 64-разрядной версии. Соответственно ИТ-менеджерам следует тщательно спланировать переход на vSphere 4.1, предусмотрев предварительный перевод серверов с vCenter 4.0 или другими младшими версиями этого ПО под управление 64-разрядной ОС.
Выигрыш при переходе на новую версию vCenter — существенное увеличение числа виртуальных машин на кластер и физических хостов, которые он способен охватить. Я не смог проверить заявленные пределы ввиду ограниченности имеющегося в моем распоряжении оборудования, но VMware указывает, что новая версия vCenter может обслуживать 3000 виртуальных машин в кластере и до 1000 хостов на каждый сервер vCenter. Обе эти цифры в три раза превышают возможности vSphere 4.0.
Помимо этого главным улучшением версии 4.1 стало дальнейшее расширение функционала, позволяющего более эффективно распределять ресурсы между виртуальными машинами. В ходе тестирования я проверил новые средства управления вводом-выводом в сети и на СХД, помогающие управлять таким распределением.
ИТ-менеджерам, уже привыкшим к управлению ресурсами в настройках ЦП виртуальных машин, будет легче освоить новые функции управления вводом-выводом. Однако обнаружилось заметное количество ограничений, наводящих на мысль о “синдроме версии 1.0”.
Управление сетевым вводом-выводом приоритизирует сетевой трафик как при использовании пулов сетевых ресурсов и родного VMware vNetwork Distributed Switch. Эти функции работают только с версией 4.1 vNetwork Distributed Switch, но не с коммутатором VMware.
Установка проста
Вообще требуется хорошее знание сетей, чтобы разработать и настроить политику, управляющую параметрами сетевого ввода-вывода, но внедрение самой функции осуществляется довольно просто. Чтобы задействовать эту функцию и задать конкретные общие физические сетевые адаптеры, достаточно пройти пару конфигурационных экранов, которые легко вызываются из клиента vSphere.
Администратор может выбрать уровень (низкий, средний, нормальный, высокий либо “другой”), задающий количество общих сетевых ресурсов, которые будут назначаться трафику VM, администрирования и отказоустойчивости (политику, которая задает относительную важность виртуальных машин, использующих одни и те же общие ресурсы).
Функции управления вводом-выводом для хранения было столь же легко сконфигурировать после того, как заданы политики и исходные физические параметры. В моей довольно скромной среде тестирования я легко запустил эти функции на одном сервере vCenter. Я тестировал эту функцию на СХД, подключенной через интерфейс iSCSI. Она работает также на матрицах с Fibre Channel, но не на матрицах с NFS или Raw Device Mapping.
Виртуальные машины можно ограничить по параметру IOPS (числу операций ввода-вывода в секунду) или пропускной способности (количеству мегабайтов в секунду). В обоих случаях я использовал функции управления вводом-выводом хранения, чтобы ограничить некоторые виртуальные машины, дав другим приоритет.
Вследствие множества разных соображений (например, каждый виртуальный диск, связанный с каждой VM, должен быть под контролем, чтобы реализовать требуемое ограничение) я потратил немало времени на продумывание политики, но получил весьма скромный выигрыш, когда всё заработало.
Новшества в памяти
VMware предложила удобное новшество в версии vSphere 4.1, названное “сжатие памяти”. ИТ-менеджерам следует знать, что эта функция включается по умолчанию.
При тестировании я заметил увеличение производительности виртуальных машин после того, как искусственно ограничил размер физической памяти хоста. Когда мои системы с VM начали обращаться к памяти при обработке рабочих нагрузок, сервер с EXS 4.1 начал сжимать страницы виртуальной памяти и хранить их в сжатом кэше.
Поскольку доступ к этой памяти происходит гораздо быстрее, чем подкачка страниц памяти на диск, виртуальные машины с этой функцией работали намного быстрее, чем когда она была отключена, и поданы те же самые рабочие нагрузки.
ИТ-менеджерам придется посвятить как минимум несколько недель тщательному анализу, чтобы определить самую эффективную конфигурацию сжатия памяти для каждой рабочей нагрузки.
В дополнение к изменениям в управлении системными ресурсами VMware навела порядок в компонентах релиза vSphere. Клиент vSphere все еще доступен в списке установки vCenter 4.1, но уже не входит в код ESX и ESXi. Сделан также ряд мелких изменений в разных экранах интерфейса, но нет ничего такого, что затруднило бы опытного ИТ-администратора.
