В лабиринтах лицензирования VMware

Алан Сугано (asugano@adscon.com) — президент компании ADS Consulting Group, специализирующейся на разработках в области Microsoft.NET, SQL Server и сетевых технологиях

.

Выделение vRAM

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

Условия лицензирования в vSphere 4.x были связаны с некоторыми ограничениями в зависимости от числа ядер в процессоре. Однако число ядер, приходящихся на один процессор в современных серверах, существенно возросло. Можно приобрести процессор с 10-ю ядрами! В vSphere 5.0 принято решение лицензировать VMware ESX на основе виртуальной памяти (vRAM), предоставляемой для каждой лицензии разъема процессора. В таблице 1 показан размер vRAM, предоставляемый в каждой версии vSphere.

Например, обладатели узла VMware ESX с двумя разъемами и vSphere Enterprise получают 128 Гбайт (то есть два разъема по 64 Гбайт каждый) vRAM на данном узле ESX. Таким образом, можно запускать виртуальные машины с общим размером памяти 128 Гбайт на каждом узле ESX. Скользящее среднее значение использования памяти за 12 месяцев должно быть не больше выделенной величины vRAM. При превышении этого предела работа виртуальной машины не блокируется, но пользователь получает уведомление о нарушении от VMware vCenter Server.

Области vRAM можно объединять в пул. Например, если имеется кластер ESX с двумя узлами и vSphere Enterprise Plus, то требуется не менее четырех разъемов Enterprise Plus, что соответствует выделению в общей сложности 384 Гбайт (четыре разъема по 96 Гбайт) vRAM. Не важно, размещены ли все виртуальные машины на одном узле при бездействующем втором, если общая память для всех виртуальных машин не превышает 384 Гбайт.

При этом максимальный размер vRAM для одной виртуальной машины ограничен величиной 96 Гбайт. Поэтому одна виртуальная машина не может затребовать из пула vRAM больше 96 Гбайт памяти, независимо от настроек. Поэтому виртуальная машина, которой назначено 512 Гбайт, занимает только 96 Гбайт из пула vRAM. А выделение vRAM для трех однотерабайтных виртуальных машин составит 288 Гбайт (по 96 Гбайт для каждой из трех).

Что делать, если требуется больше vRAM?

Если поступают предупреждения о превышении выделенного размера vRAM, вы можете воспользоваться одним из способов увеличения пула vRAM.

* Приобрести дополнительные лицензии для того же выпуска vSphere.

* Обновить имеющуюся редакцию vSphere до более высокого уровня. При переходе от vSphere Standard к vSphere Enterprise выделяется дополнительно 32 Гбайт vRAM для каждой лицензии на разъем процессора. Этот вариант не подходит обладателям Enterprise Plus: размер vRAM, выделяемой для этого выпуска, самый большой.

* Ввести дополнительный узел (или узлы) с той же редакцией vSphere, что у существующих узлов в кластере ESX. Учтите, что для совместимости с VMware vMotion необходим узел с идентичными или почти идентичными процессорами.

Обратите внимание, что увеличить количество vRAM в пуле vSphere 5.0 Essentials или Essentials Plus нельзя. Только выпуски с vSphere 5.0 Standard до Enterprise Plus можно расширять бесконечно, и необходимо приобрести такую же редакцию vSphere для расширения существующего пула vRAM.

Если для развертывания Virtual Desktop Infrastructure (VDI) использовалась версия vSphere 4.x, лицензии vSphere были приобретены до 30 сентября 2011 года и имеется действующий договор о техническом обслуживании, то можно перейти на vSphere 5.0, сохранив неограниченный пул vRAM. Однако необходимо использовать отдельный экземпляр vCenter Server, управляющий только VDI. Любые лицензии vSphere, купленные отдельно для работы с VMware View (решение VDI компании VMware), по-прежнему должны соответствовать модели лицензирования vRAM Entitlement. Дополнительные сведения можно найти в публикации сообщества VMware «Desktop Virtualization with vSphere 5: Licensing Overview» (http://blogs.vmware.com/euc/2011/08/desktop-virtualization-with-vsphere-5-licensing-overview.html). Хорошие новости для обладателей выпуска vSphere Advanced: если в вашем распоряжении имеется vSphere 4.x Advanced и действующий договор об обслуживании, вы можете получить vSphere 5.0 Enterprise. Версии vSphere 5.0 Advanced не существует, вместо нее распространяется vSphere 5.0 Enterprise.

Пять основных функций vSphere

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

#1. Только ESXi. Несколько лет назад компания VMware объявила, что vSphere 4.1 — последняя версия, содержащая как ESX, так и VMware ESXi. Как и было обещано, vSphere 5.0 поставляется только с ESXi. В сущности, это ESX без консоли Service Console на основе Red Hat и Web Server. ESXi гораздо компактнее и защищена лучше, чем ESX. Но при наличии программ (например, агента резервного копирования), выполняемых в консоли Service Console, требуется найти замену этим службам перед переходом на vSphere 5.0.

Для многих наших клиентов мы использовали удаленный агент для серверов Linux и UNIX (RALUS) из пакета Symantec Backup Exec, чтобы получить архивные образы своих виртуальных машин, функционирующих на узле. Чтобы перейти на vSphere 5.0 и по-прежнему получать архивные образы виртуальных машин, необходимо приобрести решение резервного копирования vSphere 5.0, такое как Veeam Backup & Replication, Quest Software vRanger Pro или Symantec Backup Exec. Обратите внимание, что в этих решениях резервного копирования предусмотрено сохранение копий на диске, поэтому возможно фрагментарное восстановление отдельных файлов с использованием файла архивного образа виртуальной машины. В связи с этим, возможно, придется покупать дополнительные жесткие диски или устройство NAS, чтобы получить достаточно места для сохранения виртуальных машин на диске. Конечно, мы рекомендуем переместить архивные образы на какой-нибудь автономный носитель (например, магнитную ленту) на случай проникновения опасного вируса, способного уничтожить архивные файлы виртуальной машины на диске.

#2. Поддержка памяти размером до 1 Тбайт на виртуальной машине. В большинстве экземпляров vSphere 5.0 память — первое слабое звено, с которым сталкивается администратор. Версия vSphere 4.1 была рассчитана на виртуальные машины с памятью 255 Гбайт, но vSphere 5.0 поддерживает память размером до 1 Тбайт! На самом деле, можно купить сервер с объемом памяти 2 Тбайт. Конечно, ограничение в 2 Тбайт действует не для узла, а для vSphere 5.0, поэтому для программы будет существовать только 2 Тбайт памяти, даже если в действительности ее больше. У некоторых наших клиентов есть серверы, для которых требуется более 1 Тбайт памяти. На сегодня память объемом 1 Тбайт для виртуальной машины, возможно, избыточна, но не мешает иметь пространство для роста.

#3. До 32 виртуальных процессоров в версии Enterprise Plus. Владельцы версии vSphere 5.0 Enterprise Plus могут строить виртуальные машины с 32-мя виртуальными процессорами. В версиях vSphere 5.0 Essentials, Essentials Plus, Standard и Enterprise число виртуальных процессоров виртуальной машины ограничено восемью. Помимо количества виртуальных процессоров в виртуальной машине, можно указать число ядер в каждом vCPU. Для приложений виртуальной машины, не подготовленных к SMP, добавление виртуальных процессоров не увеличивает производительность виртуальной машины. Однако для приложения виртуальной машины, готового для SMP (например, Exchange Server 2010), можно увеличить мощность единственного процессора, выбрав конфигурацию с несколькими ядрами.

Учтите, что vSphere 5.0 не позволит превысить число физических процессоров на узле. Если имеется процессор с двумя разъемами и шестью ядрами, то разрешается выделить не более 12 ядер для виртуальной машины. При настройке виртуальных процессоров в виртуальной машине выясняется, что с увеличением числа виртуальных процессоров число ядер уменьшается, и наоборот. Используя предыдущий пример с 12-ядерным узлом и vSphere 5.0 Enterprise Plus, можно получить виртуальные машины с 12 виртуальными процессорами с одним ядром, один vCPU с 12 ядрами или любой приемлемой комбинацией в этом диапазоне. Благодаря возможности указать число как виртуальных процессоров, так и ядер в каждом vCPU, администраторы могут точно настроить производительность виртуальной машины, что было непростой задачей в vSphere 4.1.

#4. Поддержка VMFS5. Для VMware VMFS3 максимальный размер экстента составляет чуть менее 2 Тбайт. Если размер экстента — точно 2 Тбайт, то не всегда можно увидеть раздел на узле ESX. С появлением VMFS3 количество экстентов увеличивается до 32 на группу хранения, поэтому размер самой большой группы хранения достигает 64 Тбайт. Однако мы сохранили отношение экстентов к группам хранения «один к одному», чтобы упростить управление хранением данных. В VMFS3 приходилось учитывать размер самого большого файла *.vmdk или диска виртуальной машины, сохраняемого в группе хранения, а затем форматировать группу хранения, указав подходящий размер блока. Некоторые администраторы ESX всегда форматируют группы хранения в блоки по 8 Мбайт ради увеличения файла *.vmdk. По умолчанию размер блока VMFS3 — 1 Мбайт, поэтому максимальный файл *.vmdk составляет 256 Гбайт. Соотношение между размером блока VMFS3 и максимальным файлом *.vmdk показано в таблице 2.

При работе с VMFS3 не следует создавать файлы *.vmdk максимального размера, разрешенного для группы хранения, иначе не удастся получить моментальный снимок виртуальной машины. При создании моментального снимка размер файла *.vmdk слегка увеличивается, поэтому, если задан максимальный размер, создание моментального снимка завершится ошибкой.

vSphere 5.0 поддерживает VMFS5, что обеспечивает значительные преимущества перед VMFS3:

* максимальный размер группы хранения; в разделах VMFS5 максимальный размер экстента — 64 Тбайт;

* размер блока; по умолчанию разделы VMFS5 форматируются блоками в 1 Мбайт, но максимальный размер файла *.vmdk по-прежнему 2 Тбайт; другими словами, больше не придется беспокоиться о соотношении между размером блока и максимальным размером *.vmdk;

* субблоки VMFS5; размер субблока в VMFS5 уменьшен с 64 Кбайт до 8 Кбайт, поэтому небольшие файлы занимают меньше места в разделе VMFS5;

* предельное количество файлов; количество файлов увеличено с 30 720 в VMFS3 до более чем 130 000 файлов в VMFS5.

Возможно неразрушающее преобразование существующего раздела VMFS3 в VMFS5, но при этом сохраняется прежний размер блока VMFS3, теряются преимущества малых субблоков, а предельное количество файлов остается равным примерно 30 000. Рекомендуется создать новую группу хранения в формате VMFS5, а затем использовать VMware Storage vMotion для перемещения виртуальных машин в новую группу хранения. Хотя переход на VMFS5 «по месту» возможен, это рискованная операция, а последствия сбоя могут быть катастрофическими.

#5. Группы хранения SSD. vSphere 5.0 распознает группу хранения с твердотельными накопителями (SSD) и позволяет задействовать их для обмена памятью. Как правило, мы стараемся не выделять виртуальным машинам больше памяти, чем присутствует физически (memory overcommit), так как это может отрицательно сказаться на производительности виртуальных машин на узле. Но что делать, если необходимо запустить больше виртуальных машин на узле ESXi, на котором уже установлено максимальное количество памяти. Возможное решение — группы хранения SSD. Их быстродействие ниже, чем у собственной памяти, установленной на узле, но SSD-накопители все же значительно быстрее других устройств хранения данных. Цена производственных SSD-накопителей по-прежнему высока — от 3400 долл. за типовой накопитель на 200 Гбайт, до 7000 долл. за устройство на 200 Гбайт с быстродействием корпоративного уровня. Тем не менее, такое решение может оказаться экономически выгодным, если приходится заменять несколько ESXi в кластере. Конечно, у этого подхода есть недостатки. Оптимальное решение зависит от конкретных обстоятельств. Применение SSD-накопителей на узлах ESXi также оправдано в случаях, когда требуется высокое быстродействие дисков. Один из наших клиентов имеет старое приложение для планирования ресурсов предприятия (ERP), работающее с Microsoft SQL Server 2000. Максимальный размер памяти для SQL Server 2000 — 4 Гбайт на сервере, два из которых доступно для SQL Server. Если клиент пригоден для запуска новейшей версии SQL Server на платформе x64, можно было бы просто увеличить память сервера и сохранить все данные в кэше. Но такой вариант был недоступен, а клиент все же нуждался в масштабировании, и мы разместили базу данных SQL Server 2000 на SSD-накопителе, что позволило значительно повысить быстродействие приложения.

Своевременная миграция повышает доходность

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