Архив

Публикации с меткой ‘VSphere’

Auto Deploy GUI Plug-In

Очень стоящую вещь выложили вчера на labs.vmware.com — Auto Deploy GUI. Это плагин к VSphere Client, который может найти сервера и как AutoDeploy модуль загрузить на них Image File нашего ESXi 5.0.

Быть может данная фича покажется кому-то очень удобной :)

Categories: VMware Tags: , ,

Software iSCSI

Появилось желание выложить на блог пару статей настройки и конфигурации продуктов для построения iSCSI хранилищ на программном уровне. Но предварительно немного расскажу о том, какие продукты более всего мне интересны, и на какие также стоит обратить внимание (конечно список будет весьма субъективный, так как каждый сам выбирает подходящее решение, о некоторых я мог даже и не слышать). Здесь я расскажу лишь о тех продуктах, с которыми имел дело лично, будь то настройка в компаниях, либо тестовое изучение.

Прежде всего, что из себя представляют данные продукты в целом. Есть разные модификации, как платные, так и бесплатные, с различным функционалом (повышенная отказоустойчивость, безопасность с разными уровнями аутентификации и т.д.), но суть сводится к одному: имея несколько гипервизоров со своими локальными дисковыми подсистемами, на основе одного из этих гипервизоров, мы создаем одно общее дисковое пространство (DataStore), которое будет видно всем остальным гипервизорам. Этим, по сути, мы создаем общее СХД для всех гипервизоров, которое будет необходимо для таких технологий, как HA, DRS, vMotion.

Для этого нам нужно одной ВМ, назовем ее iSCSI VM, выдать диск большого объема (такого объема, которого нужно нам общее хранилище) и технологиями программных решений построения софтверных iSCSI создать так называемый iSCSI Target, который мы впоследствии покажем нашим гипервизорам. Далее технологиями vSphere мы создаем датастор, который будет ссылаться на этот диск ВМ, и на котором будут лежать другие ВМ. Выглядеть это будет примерно следующим образом:

Конечно, по картинке ясно, что если ESXi01 упадет, то будут недоступны не только данные iSCSI VM, но и данные всех остальных ВМ, которые лежат на нашем общем датасторе. Некоторые продукты умеют создавать реплицированную копию, примерно так же, как технология Fault Tolerance, тем самым обеспечивая зеркалированную запись данных на несколько гипервизоров, при этом в случае падения одного из них, ЦОД останется функциональным.

Итак, приведу примеры таких продуктов, с которыми лично сталкивался:

  1. StarWind iSCSI – один из наиболее популярных продуктов, довольно простой в управлении и умеющий создавать зеркала, о которых я говорил выше. Существует как в бесплатной версии, так и в платной (в бесплатной довольно порезанный функционал, создавать “зеркала” нельзя). О том, как его устанавливать и настраивать я уже писал на сайте нашей компании. Мне этот продукт очень понравился, есть русская техподдержка, довольно быстро работают специалисты. Установка: ставится как программа на ОС Windows Server. Плюсы: огромное количество фич, легкость в настройки, поддержка русскими специалистами, довольно популярна, поэтому всегда найдется тот, кто может подсказать что-нибудь по этому продукту. Минусы: немалая цена, что неудивительно при таких плюсах, поэтому для местного использования подойдет лишь в виде Free Edition, что довольно урезает ее преимущества (лицензию на Windows Server никто не отменял).
  2. vSphere Storage Appliance – довольно новый продукт, появившийся с выходом пятого поколения VSphere. Примечательно то, что этот продукт является родным продуктом компании VMware, довольно удобен тем, что выпускается как .ova файл, который сам разворачивается в ВМ. Сам функционал будет доступен в виде плагина к VSphere Client, поэтому в других окнах нам сидеть не придется, что очень радует, в этом смысле VMware о нас заботится (vDR, Operations, vShield). Продукт также умеет создавать свои зеркала, и недавно (об этом писал в прошлой статье) стал поддерживать RAID5 и RAID6. Установка: как отдельная ВМ с уже установленной ОС и всеми сервисами. Плюсы: интеграция в VSphere, наличие специального бандла Essentials Plus с лицензией VSA, который сильно снижает стоимость продуктов. Минусы: довольно новый продукт, на практике его пробовало меньшее количество людей, чем Starwind, могут возникнуть вопросы технического характера, которые на форумах останутся без решения.
  3. Openfiler – продукт, выпускающийся в бесплатном варианте с полным набором функций, поддерживающий не только iSCSI Target, но и такие фичи, как FTP, sFTP, NFS, FC, а также умеющий создавать различные типы рейдов на основе дисков .vmdk, подключенных к нему. В ближайшее время я немного постараюсь повысить его популярность и выложу подробное описание продукта с пошаговой установкой и настройкой (разработчики пошли другим путем и начали брать деньги с поддержки, например Admin Guide обойдется вам в 40 евро). Довольно интересный продукт, на нем я поднимал пилотный проект View и Openfiler показал себя довольно достойно. Установка: монтируется как образ к Linux 32-bit OS, ставится на отдельную ВМ. Плюсы: бесплатный продукт с множеством функций, хотя если мы говорим здесь об iSCSI Software, то это не считаем, довольно прост в настройке и управлении, в интерфейс всегда можно попасть из WEB. Минусы: нет поддержки продукта в бесплатном варианте, даже документацию придется покупать, защиту в виде зеркалирования и т.д. придется тоже покупать за деньги.
  4. FreeNAS – этим продуктом довольны многие, наверное, уже пользовались, довольно часто слышал, что его используют в Production и весьма довольны. Как понятно из названия, бесплатный продукт на базе FreeBSD. Один раз настраиваем и спокойно пользуемся, также есть поддержка рейдов и дополнительных опций, правда чтобы настроить все правильно, придется потратить не одну минуту. Разработчики продукта решили, что продукт будет бесплатным, однако совместно с iXsystems выпускают сервера с встроенной СХД на базе FreeNAS, своеобразные software iSCSI стораджи, которые стоят денег, и за которые отвечает компания FreeNAS в плане технического обслуживания. Установка: ставится на отдельную FreeBSD ВМ. Плюсы: бесплатный продукт с множеством фич. Минусы: довольно сложно настраивается, нет поддержки на русском языке.

Также есть продукт Microsoft iSCSI Target, но я никогда им не пользовался, если есть те, кто пользовался и кому есть, с чем сравнивать, можете описать продукт, и я с удовольствием добавлю его в этот пост с пометкой Вашего авторства :)

Диски в Виртуальных Машинах

При создании ВМ, самое большое количество выбора настроек приходится на диски. Если Вы не очень знакомы с этими настройками, вы оставляете все по умолчанию и это правильно. Получаем обычный диск, который нам и нужен. Но эти настройки довольно много значат, если нам нужна специфическая задача. Допустим, нам нужно, чтобы при каждом рестарте ВМ мы получали первоначально созданную конфигурацию. Это нужно, допустим, для тестирования оборудования, или мы из ВМ сделали ThinApp Packager. Тогда дефолтная конфигурация нам не поможет.

Начнем с типов дисков. В новой версии VSphere 5 у нашей ВМ 3 варианта выбора диска:

  1. Thick Lazy
  2. Thick Eager
  3. Thin

Что каждый вариант обозначает:

  1. Lazy диск является толстым и при создании такого диска он будет сразу весь завербован ВМ, то есть другие блоки туда записаны не будут. Но при забронировании блоки не будут очищены от прошлых данных, то есть все данные будут сразу писаться поверх старых. Плюс: моментально создается. Минус: при первом обращении, то есть в первые 2 недели работы, будет понижена производительность;
  2. Eager диски тоже толстые, но в отличие от Lazy, система почистит прошлые блоки и новые данные будут записаны моментально. Плюс: самая быстрая система, только с ней можно использовать технологию Fault Tolerance. Минус: долго создается ВМ (чем больше диск, тем дольше создание);
  3. Thin диски являются тонкими и мы можем выдать им сколько угодно место, все равно физически будет использовать лишь пространство, использованное ВМ на данные момент. Плюс: огромная экономия пространства. Минус: более низкая производительность и надежность, ибо ВМ в каждый момент времени необходимо искать пустые блоки и не факт что она всегда их найдет.

Но эти настройки важный с точки зрения скорости работы, но сам принцип записи и чтения данных остается одинаковым. Но вот за то, какой диск и как данные будут храниться, отвечают другие настройки. Это Independent, Persistent, Non-Persistent. Теперь подробнее о каждом.

По умолчанию у нас следующая картинка:

Это значит, что диск у нас стандартный, все данные попадают на дельта-диск, который создается после создания снимка (snapshot). При откате к прошлому снимку мы получаем диск, который выглядел точь-в-точь, как диск во время делания снимка. Допустим, у нас два диска, системный и пользовательский. Если они оба в таком положении, то по мере создания снапшотов, мы получаем следующую конфигурацию с двумя дельта дисков. Если откатывается назад, то и оба диска откатываются.

Вторая конфигурация, это Independent Persistent disk:

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

Последний вариант – это Non-Persistent disk:

Такой тип диска нужен как раз в тестовых средах. Данная конфигурация означает, что во время перезагрузки мы получаем диск, каким он был до внесения на него изменений. Дельта файл, на который попадают изменения, удаляется, и мы получаем прошлую конфигурацию. Это удобно, если мы установили тестовое ПО, либо тот же ThinApp, который должен использоваться при незагрязненной системе. Также удобно, если ВМ использует много народу и нужно приводить ее постоянно к прошлому состоянию.

При понимании этих значений, мы никогда не потеряем данные, и у нас будет диск настроен так, как нам нужно.

Categories: VMware Tags: , ,

Назначение доменным пользователям администраторских прав на ESXi

Как то на официальном форуме я поднимал тему о том, как назначить доменным пользователям права в ESXi. В итоге так и утихло дело, но то было на 4 версии. На 5 же версии теперь в Advanced Settings можно назначать специальную группу для администраторов. В блоге v-reality.info подробно описан данный процесс.

Categories: VMware Tags: , ,

Поддержка VSA RAID5 и RAID6

VMware с выпуском VSphere 5 добавила в перечень своих продуктов еще один пункт: VSphere Storage Appliance. Это продукт создания софтверного хранилища – альтернатива Starwind’у, правда еще довольно сырой. В августе выйдя, данный продукт поддерживал лишь RAID10, что сильно потребляло дисковое пространство и многим было не выгодно.

И вот теперь, пару дней назад VMware выпустила обновленную версию VSA, поддерживающую еще два рейда, RAID5 и RAID6. Привожу ссылку на данную новость.

Categories: VMware Tags: , , ,

Сертификаты и звания у VMware

Недавно узнал очень интересную информацию :) До этого даже что-то не замечал. Решил всерьез освоить понимание личной сертификации и вот как у нас все проходит:

Первом делом нужно получить сертификат VCP (VMware Certified Proffesional), это первый важный сертификат, открывающий нам кабинет VCP. Вот как его получить:

Как я понимаю, сертификация VCP4 уже закрыта, остается взять 5 серию (что в среду я и собираюсь делать, поеду в Микроинформ :)). Тут есть несколько вариантов, в зависимости от того, чем мы обладаем и что у нас из прошлых сертификатов есть.

Далее у нас идут два сертификата уровня Advanced, это VCAP-DCA (VMware Certified Advanced Proffesional — Data Center Administration)(экзамен на знания администрирования, то есть несколько десятков лабораторных) и VCAP-DCD (VMware Certified Advanced Proffesional — Data Center Design)(экзамен на знания дизайна VSphere, то есть около 130 вопросов на то, как правильно создать VSphere виртуализацию из ничего). У них также есть свой личный кабинет.

Для VCAP-DCD нужно:

Для VCAP-DCA:

Как уже понятно, для сдачи обоих экзаменов нам нужно быть VCP. Кроме того, заранее нужно их заказать. Как я понял, пока 5 версий этих экзаменов нет, так что тот, у кого есть VCP5, но нет VCP4 пока ждет.

На этом я думал, что все заканчивается. Но насколько я удивился, узнав, что есть еще один экзамен (про него, по-моему рассказывал на форуме Антон Жбанков). Это высшая ступень эволюции у VMware — экзамен VCDX (VMware Certified Design Expert) — экзамен, который можно сдать лишь устно перед комиссией в определенные моменты времени заграницей. Ну и конечно же тут есть свой кабинет :)

Вот что для него требуется:

Для этого экзамена нужно получить и DCA, и DCD, разумеется сейчас доступна лишь версия 4 поколения VSphere.

И вот ближайшие даты защиты:

  • November 14-18, 2011 — Singapore: Registrations closed
  • February 6-10, 2012 — Frankfurt, Germany
    • Registrations closed now
    • Applications were due December 5, 2011, 5:00 PM Pacific Time (UTC-8)
  • May 7-11, 2012 — Toronto, Canada
    • Pre-register now
    • Registration opens February 20, 2012
    • Applications due: March 12, 2012, 5:00 PM Pacific Time (UTC-7)

Конечно же даты больше условно написал, так как просто так они никому не интересны, а кому интересны, прекрасно их уже знает.

Но теперь мне по крайней мере есть к чему реально стремиться :)

Из данных http://vinfrastructure.it/en/2012/02/top-it-certifications/ следует, что VCDX на шестом месте по крутости в мире :)

Подведем итоги: получаем VCP, далее параллельно VCAP-DCA и VCAP-DCD, а далее ночами учим всю VSphere и сопутствующие продукты, а также английский язык, так как VCDX нельзя сдавать на русском. Если кто его уже сдал, пишите, поделитесь опытом :)

Если смотреть в линейку View, то там тоже есть свои 2 звания — VCA4-DT и VCP4-DT, но это отдельное направление.

Описание всех сертификатов можно найти на официальном сайте VMware.

Categories: VMware Tags: , , ,

Ограничения для Fault Tolerance

Технологию высокой доступности Fault Tolerance уже знают многие, с ней приходилось работать многим, кому было необходимо обеспечить виртуальную среду гостевыми машинами с отсутствием потерь информации в случае падения серверного оборудования. Технология очень интересная, если кратко, то FT создает на другом сервере из кластера HA (High Availability) теневую копию ВМ, которая в случае падения сервера с основной ВМ берет на себя все ее функции. Сразу же на последующем сервере поднимается другая ВМ, которая становится теневой, а наша бывшая теневая основной. Вот описание этого процесса:

Как уже понятно, для этого нужно несколько серверов (минимум два), а также кластер HA. И также понятно, что теневая ВМ постоянно синхронизируется с нашей основной, то есть в случае падения моментально начинает работать. Это значит, что она должна постоянно задействовать ресурсы второго сервера. Вот бывает так, что эти ресурсы (CPU, RAM) не всегда совместимы с нашим первым сервером, ведь чтобы обе одинаковые ВМ работали на двух серверах, эти сервера должны быть одинаковыми, или близкими по своим критериям. Оперативная память понятно, должна быть зарезервирована и по ней лишь то ограничение, чтобы ее хватало. А вот с CPU все гораздо сложнее. Далее расскажу о том, какие ограничения нас ждут, если мы решили устанавливать FT.

У этой функции довольно много ограничений, начну, пожалуй, с самых важных. Самым важным ограничением, является совместимость CPU:

FT до сих пор не научился работать между процессорами разных производителей. То есть, если у Вас кластер HA с гибридными серверами, где есть и Intel и AMD процессора, то это не очень хорошо. Если их много, то лучше разнести ВМ на два кластера, где будут сервера с разными процессорами. Но и процессора одного производителя, в частности это относится к Intel не всегда будут поддерживать FT, приведу таблицу совместимости процессоров для FT:

Intel
3100
Intel
3300
Intel
5200
Intel
5400
Intel
5500
Intel
7400
AMD
1300
AMD
2300
AMD
8300
Intel 3100

V

V

V

V

X

V

X

X

X

Intel 3300

V

V

V

V

X

V

X

X

X

Intel 5200

V

V

V

V

X

V

X

X

X

Intel 5400

V

V

V

V

X

V

X

X

X

Intel 5500

X

X

X

X

V

X

X

X

X

Intel 7400

V

V

V

V

X

V

X

X

X

AMD 1300

X

X

X

X

X

X

V

V

V

AMD 2300

X

X

X

X

X

X

V

V

V

AMD 8300

X

X

X

X

X

X

V

V

V

Из этого можно заключить следующее, все процессора AMD из этого списка работают друг с другом, а также все процессора Intel работают друг с другом, кроме серии Intel 5500. Процессора этой серии работают лишь с такими же из серии 5500.

Стоит также отметить ограничения на частоту процессора, FT работает только с процессорами с частотой 400 MHz и выше, хотя теперь это уже не особо актуально.

До патча ESX(i)400-200906401-BG FT переводил работоспособность на вторую ВМ спустя пару секунд, что значительно мешало бесперебойной работе. ESX/ESXi для работы FT требуются одинаковой версии.

В логах биоса серверов можно найти следующие ошибки, свидетельствующие о неработоспособности FT, означать они могут следующее:

  • IncompatibleProduct – на сервере запущен продукт, отличающийся от официальных ESX/ESXi (сторонний продукт или продукт без подписи VMware);
  • IncompatibleCpu – ESX/ESXi сервер не поддерживает аппаратную виртуализацию (Intel-VT, AMD-V), необходимую для работы FT;
  • hvDisabled – сервер поддерживает виртуализацию, но она отключена в настройках BIOS, на котором исполняется FT;
  • cpuidLimitSet – на сервере ESX/ESXi включена опция, которая осуществляет максимальный предел на CPUID, препятствующий тому, чтобы FT работал;
  • oldBIOS – BIOS старой версии, требуется обновление;
  • Unknown — неизвестная конфигурация BIOS препятствует тому, чтобы FT работал должным образом.

Существует требование по сетевому оборудованию. У каждого ESX/ESXi должно быть минимум по 2 сетевые карты скоростью минимум 1 Гбит/сек., находящиеся в одной сети. 1 сетевая карта должна быть выделена для FT, вторая для vMotion.

Само собой, так как ВМ, защищенная FT, использует технологию HA для данного процесса, то ВМ должна находиться на общей СХД.

В данный момент у ВМ может быть лишь 1 vCPU, но VMware обещает в ближайшее время исправить этот момент.

Технология FT не поддерживает тонкие диски. Если ВМ находится в выключенном состоянии, и Вы включаете FT, тонкий диск автоматически будет преобразован в толстый.

Все снимки (snapshots) должны быть удалены у ВМ, так как с ними FT работать не будет.

Само собой, для использования FT должна быть лицензия Enterprise или Enterprise Plus.

Не все ОС будут работать с FT. В данный момент выявлено например, что на процессорах AMD Barcelona не будут работать следующие системы:

  • Windows XP (64 bit)
  • Windows XP (32 bit)
  • Windows 2000
  • Solaris 10 (32 bit)

Физические RDM не поддерживаются технологий FT, только виртуальные.

NPIV и VMI ROM не поддерживаются не ОС, защищенных FT.

CD-ROM’ы и Floppy диски, направленные на физические устройства или удаленные также не поддерживаются, с .ISO образами на общем СХД FT работает.

NIC Passthrough и VMXNET2 адаптеры не поддериживаются.

Вот такие ограничения существуют. Далее приведу список всех поддерживающих на данный момент процессоров технологию FT:

Intel Xeon Penryn Category:

  • 31xx Series
  • 33xx Series
  • 52xx Series
  • 54xx Series
  • 74xx Series

Intel Xeon Nehalem Category:

  • 34xx Series (Lynnfield)
  • 35xx Series
  • 55xx Series
  • 65xx Series
  • 75xx Series

Intel Xeon Westmere Category:

  • 34xx Series (Clarkdale)
  • 36xx Series
  • 56xx Series
  • E7-28xx Series
  • E7-48xx Series
  • E7-88xx Series
  • i3/i5 (Clarkdale)

Intel Xeon Sandy Bridge Category 1:

  • E3-12xx Series

Intel Xeon Sandy Bridge Category 2:

  • i3-21xx Series

AMD Opteron Barcelona Category:

  • 13xx Series
  • 23xx and 24xx Series (DP)
  • 41xx Series
  • 61xx Series
  • 83xx and 84xx Series (MP)

А также таблицу с официально поддерживаемыми гостевыми ОС:

Гостевая ОС Поддержка
Windows 7 Поддерживается всеТребуется VSphere 4.0U1 и выше
Windows Server 2008 Поддерживается все
Windows Vista Поддерживается все
Windows Server 2003 (64 bit) Поддерживается все
Windows Server 2003 (32 bit) Intel ПоддерживаетсяЕсли используется процессор AMD, нужен SP2 или выше
Windows XP (64 bit) Поддерживается
Windows XP (32 bit) Intel ПоддерживаетсяAMD не поддерживается
Windows 2000 Intel ПоддерживаетсяAMD не поддерживается
Windows NT 4.0 Intel ПоддерживаетсяAMD не поддерживается
Linux (all ESX-supported distributions) Поддерживается
Netware Server Нет данных
Solaris 10 (64-bit) ПоддерживаетсяЕсли используется процессор AMD, нужен Solaris U1 или выше
Solaris 10 (32-bit) Intel ПоддерживаетсяAMD не поддерживается
FreeBSD (all ESX-supported distributions) Поддерживается все

Вот примерно так обстоят дела. Если не хочется проверять все самому, или не уверены в точности проверки, воспользуйтесь утилитами VMware Site Survey и CPU Identification Utility для проверки на совместимость с FT.

Совместимость VSphere и XenDesktop

Сегодня получил запрос, касающийся совмещения двух продуктов компаний VMware и Citrix. Задумка следующая: развернуть на гипервизоре ESXi платформу для VDI от Citrix – XenDesktop. Вопросы были примерно следующие: можно ли сие сделать, будет ли работать, нужно ли докупать что-то дополнительно, к кому обращаться в случае краха всего этого и т.д.
Так как ESXi – это гипервизор и ему не важно, что на нем крутится, главное чтобы это были ВМ, то и запустить на нем можно любые приложения и сервисы (поправьте меня списком неработающих :) ). Поэтому XenDesktop работать будет, более того, у VMware есть специальный продукт, VSphere Desktop, который выключает ограничение по лицензированию оперативной памяти при использовании сторонних продуктов VDI. Но сомнительный выигрыш в стоимости лицензий никак не окупит возможного возникновения проблем с таким гибридным построением VDI. Дело в том, что VMware поддерживает лишь инфраструктуру в этом случае, за неработающую платформу на базе XenDesktop VMware не отвечает. С другой стороны Citrix поддерживает свой продукт лишь на базе гипервизора XenServer. Так что лучшим вариантом будет выбрать одну линейку продуктов, либо ESXi и View, либо XenServer и XenDesktop, так мы избавимся от головной боли и лишних проблем в совместимости.

Альтернатива команде vihostupdate

В 4 версии, если нам нужно было:

  • Произвести апгрейд ESX/ESXi;
  • Добавить драйвера для оборудования в гипервизор;
  • Добавить драйвера для сторонних производителей;

Мы использовали команду vihostupdate, либо Update Manager.


В 5 версии нам предложено использовать локальную команду esxcli, либо vMA. Теперь, скажем, чтобы установить новую версию гипервизора, нам придется писать примерно следующее:

esxcli —server=x.x.x.x —username=root software vib update —depot=/vmfs/volumes/datastore/ESXi500-201109001.zip

Categories: VMware Tags: , ,

Новое лицензирование Виртуальных Машин

Немного хочу затронуть аспекты нового лицензирования в версии VSphere 5, а именно нюансы лицензирования “тяжелых” ВМ с большим количеством RAM. Как известно, теперь само ограничение на количество ядер снято, то есть теперь мы на это не обращаем внимания, зато появилось новое ограничение на общее количество сконфигурированной памяти, не путать с памятью в пуле (vRAM)! Общая память в пуле – это сколько всего оперативной памяти на всех серверах с установленными лицензиями VSphere, сконфигурированными через VCenter Server, либо отдельно, на каждом хосте ESXi. А вот сконфигурированная память – это количество выданной оперативной памяти всем запущенным ВМ в пуле vRAM, то есть если у нас лицензиями доступно, скажем, 96 Гб, а на серверах у нас 192 Гб, это не нарушение лицензии, это всего-лишь значит, что мы не можем запустить ВМ более чем на 96 Гб в сумме. Но и это не до конца правильно, такое утверждение справедливо лишь для лицензий Essentials и Essentials Plus. У лицензий Standard, Enterprise и Enterprise Plus нет явных ограничений по запуску ВМ, там расчет идет среднего использования памяти в год, если порог за год превышен, то это уже нарушение лицензии. Допустим, у нас лицензиями разрешено использовать 32 Гб, мы полгода использовали 64 Гб, а полгода вообще не использовали сервера, в среднем у нас за год – 32 Гб, и нарушения лицензии не будет. У Essentials китов такой свободы нет, если мы перейдем порог в 192 Гб, а именно столько разрешено использовать в начальных китах, далее ВМ просто не будут запускаться.

Так вот, вернемся к лицензированию “тяжелых” ВМ. Дело в том, что ВМ в новой версии VSphere мы теперь можем выдавать оперативной памяти вплоть до 1 Тб. Но лицензироваться, отбирать vRAM у пула ВМ будет лишь до 96 Гб, далее все будет бесплатно. Например, у нас лицензиями выдано 256 Гб, у нас 2 ВМ по 128 Гб RAM. По идее, вся лицензированная память закончена, но VMware сделала некий бонус, ограничивая снятие памяти с лицензий до 96 ГБ, тем самым 2 ВМ будут работать как 128 Гб памяти но лицензия будет видеть их, как 96 Гб, то есть в сумме 192 Гб, оставив нам еще 64 Гб. Такой бонус не работает для Essentials и Essentials Plus, там если мы используем ВМ 192 Гб, а это значит что она должна исполняться на одном сервере, всего у нас будет 1 сервер, то и вся лицензия будет использована. Это сделано потому, что уровень консолидации будет 1к1, а значит и виртуализироваться смысла не будет. Привожу ссылку на данные ограничения:
Блог VMware
Есть еще один интересный нюанс, меня как то спросили, а что будет если у нас есть 256 Гб в лицензии, и мы включим ВМ 1 Тб, что будет первее, VSphere поймет, что это всего лишь 96 Гб лицензии и пропустит такую ВМ, или скажет что нам выдано 256 Гб и может нам столько не выдать, например нужно создать ВМ с 100 Гб RAM и потом повысить до нужного нам 1 Тб. Тут все просто и ничего не меняется: как я уже писал выше, мы можем включить ВМ даже, если у нас не будет столько в лицензии (для Std, Ent, Ent+), ограничение считается в среднем за год, поэтому все пропустится, включится и ничего дополнительного делать не надо, может быть это еще одна из причин, почему на редакциях Ess, Ess+ данное правило не работает.

Categories: VMware Tags: , , ,