Что нового в vSphere 5 (часть 1)

Введение

Новая модель лицензирования

Я собираюсь возглавить это обсуждение «что нового», кратко рассмотрев новую модель лицензирования VMware на основе потребления. Я хотел бы предварить этот раздел, сказав, что ходят слухи о том, что VMware может изменить эту модель, чтобы сделать ее менее обременительной для клиентов. Вполне возможно, что к тому времени, когда вы будете читать эту статью, VMware внесет официальные изменения в модель лицензирования. А пока, вот тощий:

Хорошие новости

VMware исключила количество ядер ЦП в качестве показателя лицензирования. Таким образом, если AMD выпустит гиганта с 1024 ядрами, вам не нужно будет беспокоиться о лицензировании vSphere как о ограничивающем факторе на основе процессора.

Плохие новости

VMware заменила количество ядер новой метрикой под названием vRAM. Каждый выпуск vSphere 5 включает в себя права на определенный объем vRAM на лицензию. Использование vRAM — это совокупный общий объем виртуальной памяти, назначенный всем виртуальным машинам в кластере, управляемом vCenter. Итак, если у вас есть два хоста vSphere 5, каждый с 96 ГБ виртуальной ОЗУ, и в общей сложности четыре работающих виртуальных машины, каждой из которых назначено 4 ГБ виртуальной ОЗУ, у вас есть 192 ГБ физической ОЗУ, но только 16 ГБ виртуальной ОЗУ в использовать.

Каждая лицензия для каждого выпуска vSphere включает определенные права на vRAM, которые описаны ниже:

• Основы. 24 ГБ
• Основы плюс. 24 ГБ
• Стандарт. 24 ГБ
• Предприятие. 32 ГБ
• Предприятие Плюс. 48 ГБ

Следует отметить, что VMware также снимает ограничения на физическую память, которые присутствовали во всех редакциях vSphere, кроме Enterprise Plus. Ранее серверы vSphere, за исключением тех, что работают на Enterprise Plus, ограничивались 256 ГБ физической оперативной памяти. Это больше не так, и вы можете упаковать столько физической памяти, сколько хотите, не сталкиваясь с лицензионным барьером. Однако, когда вы фактически начнете использовать эту оперативную память, вы начнете подсчитывать виртуальную оперативную память, контролируемую vCenter, и вам нужно будет убедиться, что у вас достаточно лицензий vSphere, чтобы покрыть объем используемой виртуальной оперативной памяти.

Вам не нужно отслеживать использование vRAM для каждого хоста. vRAM считается объединенным правом, что означает, что, например, если у вас есть два хоста, каждый с 192 ГБ физической ОЗУ и каждый с двумя сокетами процессора, и вы покупаете в общей сложности четыре лицензии Enterprise Plus (по одной на каждый сокет), вы может использовать до 192 ГБ ОЗУ на обоих хостах в совокупности. При желании вы можете использовать все 192 ГБ ОЗУ на виртуальных машинах, работающих на одном хосте, или, что более вероятно, разделить рабочую нагрузку между обоими хостами, если общий объем ОЗУ, используемого на ваших виртуальных машинах, не превышает 192 ГБ.

Мельница слухов

Ходят слухи, что VMware вскоре объявит о некоторых существенных изменениях в этой противоречивой схеме лицензирования vRAM, о которой было объявлено в выпуске vSphere 5.

Вот что говорят слухи о том, какие изменения мы можем увидеть (все значения указаны для сокета/лицензии):

• Essentials: право на 32 ГБ vRAM (было 24 ГБ)
• Essentials Plus: право на 32 ГБ vRAM (было 24 ГБ)
• Предприятие: 64 ГБ (было 32 ГБ)
• Enterprise Plus: 96 ГБ (было 48 ГБ)

Кроме того, слухи указывают на то, что VMware ограничит 96 ГБ ОЗУ на одной виртуальной машине объемом ОЗУ, который учитывается в пуле vRAM. Таким образом, если у вас есть виртуальная машина, которой назначено 128 ГБ ОЗУ, только 96 ГБ будут учитываться при расчетах виртуальной ОЗУ, используемых для целей лицензирования. С исходной схемой массивная виртуальная машина больше не была финансово осуществимой, но это изменение немного возвращает ситуацию к реальности. Первоначально опасения заключались в том, что крупные компании, стремящиеся виртуализировать приложения уровня 1, в конечном итоге будут платить за это значительную сумму в виде лицензий VMware.

Опять же, это все слухи на данный момент. Если это действительно будет реализовано, я обновлю эту статью в блоге на сайте virtualizationadmin.com.

ESX действительно исчез

vSphere 5 — это версия только для ESXi. ESX-версии продукта больше нет. В предыдущих выпусках вы могли выбирать, хотите ли вы ESX или меньший, более быстрый и безопасный ESXi.

Увеличено максимальное количество виртуальных машин

Как это часто бывает, когда VMware выпускает новую основную версию ESX/ESXi/vSphere, теперь вы можете создавать виртуальные машины еще большего размера благодаря увеличению максимального количества виртуального оборудования, которое может быть назначено виртуальной машине. Опять же, некоторые из максимальных значений зависят от конкретных выпусков vSphere, поэтому, если вы используете Standard, вы не сможете масштабироваться, как если бы вы использовали Enterprise Plus.

Тем не менее, vSphere 5 приносит много пользы, позволяя виртуализировать даже самые ресурсоемкие приложения уровня 1, позволяя назначать до 32 виртуальных ЦП на одну виртуальную машину при использовании Enterprise Plus. Редакции Standard и Enterprise vSphere 5 поддерживают до восьми виртуальных ЦП на виртуальную машину.

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

Таблица 1: Максимумы vSphere

Новая версия виртуальной машины

Многие из аппаратных улучшений, которые я упомянул, доступны, потому что VMware представила новую версию своего формата виртуальной машины — версию 8. Помимо включения ряда новых максимумов, версия 8 также включает в себя возможности 3D-графики для обеспечения поддержки Windows Aero. и поддержка высокоскоростных устройств USB 3.0. Эти новые аппаратные возможности расширят потенциальные варианты использования vSphere, особенно в отношении настольных сценариев.

Усовершенствования поддержки гостевой операционной системы

Хотя VMware уже давно является лидером по широте и глубине поддерживаемых операционных систем, vSphere 5 выводит их на совершенно новый уровень благодаря возможности поддержки виртуальных машин на базе Mac OS X Server 10.6 на платформе.

Но есть главная загвоздка.

Вы можете запускать рабочие нагрузки на основе Mac OS X в vSphere только тогда, когда vSphere работает на оборудовании с маркировкой Apple (согласно довольно строгому лицензированию Apple). Итак, я думаю, это отличная вещь, если вы хотите запустить свой центр обработки данных на оборудовании Apple Xserve с истекшим сроком службы? В противном случае я не уверен, какое оборудование для центров обработки данных корпоративного уровня рассчитывают приобрести у Apple.

ВМФС 5

В vSphere 5 компания VMware значительно переработала файловую систему VMware (VMFS) и представила ряд новых привлекательных возможностей. Прежде всего, любой, кто очень долго работает с VMFS, знает, что максимальный размер одного экстента VMFS уже очень давно составляет 2 ТБ. Поскольку вам нужно было увеличить объем хранилища VMFS, для этого вам нужно было использовать экстенты — опять же, каждый из них имел размер 2 ТБ. В VMFS 5 максимальный размер экстента теперь составляет 64 ТБ — увеличение в 32 раза.

Помимо упрощения управления за счет увеличения размера экстента, VMware убрала из процесса создания тома VMFS одно ключевое решение — размер блока. В старых версиях VMFS администраторам приходилось активно выбирать размер блока для хранилища VMFS в блоках по 1, 2, 4 или 8 МБ. Большие размеры блоков были необходимы для больших объемов. В VMFS 5 администраторы могут просто использовать блоки по 1 МБ для тома VMFS любого размера. Это окажется огромным благом для администраторов, которые в прошлом были обожжены, пытаясь увеличить тома со слишком маленькими размерами блоков. Чтобы обойти эту проблему в прошлом, многие администраторы (включая меня) решили просто использовать размер блока 8 МБ для всех томов VMFS, независимо от размера.

Точно так же VMFS 5 также представила меньшие подблоки. В предыдущих версиях VMFS подблоки имели размер 64 КБ, что означало, что файл размером 2 КБ занимал минимум 64 КБ дискового пространства. В VMFS 5 размер этого подблока был уменьшен до 8 КБ. Кроме того, очень маленькие файлы — 1 КБ и меньше — больше даже не хранятся в файловой системе. На самом деле они хранятся в области дескриптора файла метаданных, и только когда размер файла превышает 1 КБ, он использует дисковое пространство на основе блоков.

Размер отдельных файлов VMDK в хранилище VMFS по-прежнему ограничен 2 ТБ — 512 байт. vSphere 5 не позволяет создавать файлы VMDK большего размера. Однако, если вместо этого вы используете сопоставление необработанных устройств (RDM), вам не придется беспокоиться об этом ограничении, и вы получите до 64 ТБ дискового пространства в vSphere 5.

Наконец, VMFS 5 позволяет хранить больше отдельных файлов на томе. Предыдущие версии VMFS позволяют хранить около 30 000 файлов. VMFS 5 увеличивает этот предел до более чем 100 000 файлов.

Обновление до VMFS 5

VMware указала, что администраторы могут обновить свои существующие хранилища VMFS до VMFS 5 без прерывания работы, но есть несколько вещей, на которые следует обратить внимание:

• Размер блока не изменится. Если вы обновите существующее хранилище VMFS, оно сохранит существующий размер блока (т. е. 8 МБ). Для изменения размера блока требуется полная очистка и перестроение.
• Многие администраторы выбирают Storage vMotion. Многие (справедливо) ненавидят делать обновление чего -либо на месте, чтобы оно не пошло не так. Таким образом, многие администраторы предпочтут создать новое хранилище VMFS 5 с блоками по 1 МБ, а затем использовать Storage vMotion для переноса отдельных виртуальных машин на новую VMFS. Я сильно подозреваю, что этот метод будет считаться лучшей практикой.

Резюме

К настоящему моменту вы, вероятно, заметили много новых преимуществ vSphere 5. Я продолжу этот обзор во второй части этой серии статей.