Есть ли разница между ESXi 4.0 installable и embedded?

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

На сегодня существует 3 дистрибутива ESX 4: ESX 4.0, ESXi 4.0 installable, ESXi 4.0 embedded. Разнице “полного” от i посвящена целая статья в базе знаний, а вот чем отличаются два последних сказать затруднительно.

Что нам говорит документация? Практически ничего:

  • An ESXi Embedded host is a physical server that contains an ESX image preinstalled as firmware in the factory or burned onto an external USB key. (Moving ESXi Embedded USB keys from one server to another is not supported.)
  • You do not need to install ESXi Embedded because it is embedded as firmware on hardware that you purchase from a vendor.
  • ESXi Embedded must not be on the host. ESXi Installable and ESXi Embedded cannot exist on the same host.
  • You can install ESXi Installable on any hard drive on your server. (You use the ESXi 4.0 CD to install the ESXi 4.0 software onto a SAS, SATA, or SCSI hard drive. Installing on a Fibre Channel SAN is supported experimentally. Do not attempt to install ESXi with a SAN attached, unless you want to try this experimental feature. Installing on IP storage, such as NAS or iSCSI SAN, is not supported.)

Из этого следует вывод – ESXi Embedded ставится производителем самостоятельно, в заводских условиях, на USB-носители, а ESXi Installable условно на жёсткие диски.
Как бы не так. По факту, ESXi Installable при установке предлагает выбрать, в том числе, USB- носители и спокойно на них ставится и работает. А ESXi Embedded с чистой душой качается с сайта VMware под основные бренды, при этом есть обе версии с CIM агентами от вендоров.
Итак, разницы никакой – ESXi Embedded имеет слегка урезанную версию установщика, который ставит только на USB-хранилища. Можете ставить ESXi Installable на свои USB-flash, если он больше нравится или доступней.
Для встроенных в сервера flash-карты советую использовать ESXi Embedded от вендора, так как вопрос гарантии это отдельная сказка.

Dell’ьный ESXi

Так сложилось, что на сервера было решено ставить ESXi, так как сам он бесплатный, можно спокойно множить для тестов, а для промышленной эксплуатации полноценно управляется vCenter. Но возникла проблема мониторинга и управления на железном уровне, vCenter хорошо, но RAID на подключенной полке не переразобьёшь.

Для управления серверами Dell используется продукт OpenManage Server Administrator. До ESXi 3.5u4 вариант был один – ставить полный ESX, в котором, правда, неофициально работают бесплатные ключи от ESXi, а поверх ставить Linux версию OpenManage.

С версией  ESXi 3.5u4 проблема была решена с помощью механизма CIM. Вышла специальная версия гипервизора со втроенным посредством CIM  OpenManage агентом, а также новая отдельная версия OpenManage Server Administrator 6.0.3.

OpenManage Server Administrator можно установить на любой компьютер в сети и посредством web-интерфейса  подключиться к хосту под управлением ESXi, а затем получить полный доступ аналогичный родной установке OMSA .esxi_dell_open_manage Парочка ссылок:

документация по OMSA,

Dell ESXi 3.5u4 emb,

Dell ESXi 3.5u4 inst.

Что за лицензия Enterprise Plus?

Попытка установить сегодня финальный релиз VMware vSphere заставила меня задуматься об этой новой странной лицензии Enterprise Plus. А уж эта статья посадила меня за компьютер, читал её с телефона, а пальцы забегали по клавиатуре.

Начну со статьи. Автор “просочивших мыслей” рассуждает об отличии Enterprise лицензии от Enterprise Plus, рассматривая новые технологии: Host Profiles, без которой невозможна ещё одна – VMware vNetwork Distributed Switch, без которой, в свою очередь, невозможен Cisco Nexus 1000V. Кроме этого, в “плюс” попал и multipath plug-in support, который даёт возможность использовать расширения третьих сторон для балансировки путей до хранилищ. На основе рассуждений автор делает вывод:

Enterprise + Enabling Technologies for Third Party Integration = Enterprise Plus

И, подведя итог,  “плюс” нужен только, как возможность использовать третьесторонние разработки, так почему же мы должны платить за “плюс”, если плагины за деньги, и почему лицензия будет существовать только до конца года!?

А теперь, о чём я думал во время установки? С какого перепугу для vSphere RC не подходит ключ от Enterprise Plus, да-да , именно так – к финалу подходит, а  к релиз кандидату нет. Значит, на момент релиз кандидата не существовало такой лицензии, все возможности от “плюса” были в простом Enterprise. Чтобы это могло значит, скорей всего желание срубить побольше капусты. Ведь понятно, что все, кто на подписке, автоматом получат лицензию, как из них выжать ещё немного? Давайте ещё один уровень лицензий придумаем! А вдруг, кому эти функции не нужны, не захотят платить нам и нашим ближайшим партнерам, пока это EMC и Cisco. Давайте закроем старую лицензию! Сказано – сделано.

Все вышенаписанные буковки  моё личное мнение и вольный пересказ статьи Edward L. Haletky.  С моим мнением вы можете, как согласится, так и оставить своё при себе. 😉

Энергопотребление vSphere

Зелёные тенденции, в особенности снижение энергопотребления, в ИТ во время кризиса становятся популярными и в России, даже за пределами МКАД. Как известно, виртуализация неплохо позволяет экономить драгоценные ватты за счёт консолидации и энергосберегающих технологий таких, как DRS(DPM). В vSphere данное направление получило дальнейшее развитие и одной из ключевых функций стала поддержка динамического управления частотой процессора Intel SpeedStep, Enhanced AMD PowerNow!.

Имеется ли поддержка данной технологии можно посмотреть на закладке процессоров в конфигурации хоста.
vsphere_intel_speed_step

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

vsphere_advanced_power

Так как эффективность данных технологий видна только при низкой загрузке, то для испытаний было взято два хоста без виртуалок. На первом хосте установлен ESXi 3.5u4, на втором ESX 4emb RC. Но неожиданно вспомнил, что последний вместо жесткого диска установлен на USB-флеш, так что тесты могут просто показывать простой винчестеров ;). Энергопотребление смотрел с помощью мониторинга питания в iDrac лезвия.

Результаты: сервер с ESXi3.5u4 потребляет 120-124 ватта, ESX 4emb RC 104-108 ватт, разница 10%.

VMware Webservice

После борьбы с FT, у меня обнаружились две проблемы, которых изначально не было: не работал Storage Maps и новый Performance Overview, а также не стартовал VMware VirtualCenter Management Webservices – писал ошибку. Связать проблемы воедино меня не осеняло, пока одна из попыток просмотра странички с графиками производительности не вывела, что, дескать, страничка не доступа.
Никакие попытки запустить Webservice не помогали, в логе писалось, типа, не хватает памяти в куче для содания Java VM. Почесав репу, вспомнил, что Андрей писал о минимуме 2 Гб ОЗУ для работы четвертого центра. Добавил памяти – ошибка осталась. Погуглил-1, не помогло. Переустановил весь vCenter, не помогло. Погуглил-2, перечитал прочитанное в “Погуглил-1”, нашёл параметр, отвечающий за выделение памяти при запуске JVM, уменьшил Maximum memory pool с 1024 до 512 MB. VMware Webservice запустился.

jvm_memory_poolИ всё встало на свои места – Storage Maps, Performance Overview заработали. Похоже, через WebService работают соответствующие плагины.
В очередной раз пришла мысль, что без документации, как без рук.

Тестирование vSphere Fault Tolerance

После короткого перерыва снова принялся за изучение гипервизора нового поколения от VMware. Одна из ключевых функций, которая интересует многих, изначально называвшаяся HA continuous, – Fault Tolerance.
Итак, снова в моём распоряжении два лезвия Dell M600, хранилище EMC AX4-5 FC, ESXi embedded 4.0.0 RC и виртуалка Windows 2003 Server с vCenter 4.0 RC.
Так как мне было лениво создавать ещё одну виртуальную машину, то решил экспериментировать на этой, от этого видать и половина возникших проблем. 😉
Сначала, попытка включить FT не удалась по причине невыделения сетевых интерфейсов для логирования FT. Включил в настройках сетевых интерфейсов все галки подряд – vMotion, FT logging… Гигабитные интерфейсы работают два в паре, разделения функционального не делал, чего вам не рекомендую.
ft_network_enabled
На втором этапе система ругнулась на несоответствие типа жёсткого диска, быстренько сделал Storage vMotion на другой раздел с указанием “толстого” типа.

storage_migrate_thick Ура! FT, покряхтев минуты 2-3, заработал!
Проверку Testing Failover прошёл на отлично, удивило только мигание хостов.
ft_context_menu
После этого решил напрямую ребутить хосты из интерфейса vCenter, отказываясь от спасения виртуалок.  Первый хост ребутнулся успешно, подождав пару минут и проверив, что FT работает, перезагрузил второй хост… И вот тут я залип, виртуальная машина зависла насмерть, картинка на основной машине стала отличаться от вторичной, а так как там был vCenter, то всей моей инфраструктуре пришёл конец. Попытка насильно ребутнуть из vClient виртуалку не помогла, но подозреваю, что отработал HA во время моих инсинуаций, и из ребута загрузилась VM.
После такого развлечения принял решение – отрубить FT. Но, не тут-то было, в меню оказалось два замечательных выбора Off FT и Disable FT. Я сделал Off, и… В общем, произошло не пойми чего, меню FT стало серым, а вторичная виртуалка в статусе disabled. Шаманства не помогли, пришлось всё перезагрузить и ручками удалить вторичную VM.

Как итог, FT стал работать, как часы: отлично включается, выключается, “приостанавливается”, чистить за собой при удалении вторичные виртуалки.

ft_status

Очередное сравнение гипервизоров. Русская версия

Чуть меньше месяца назад в блоге была опубликована таблица сравнений современных гипервизоров, подготовленная маркетинговым отделом VMware к выходу Vsphere. Сегодня в руки попалась официальная руссифицированная версия, которую и представляю вашему вниманию.
hypervisors_compare1
hypervisors_compare2
hypervisors_compare3

Тестирование Citrix XenServer. Другое

Как и Андрей, я решил потестировать Xen. Потестировать-то потестировал, но решил отписать только сейчас – был в отпуске.

В моём случае установка производилась на железо – 2 лезвия Dell M600 и SAN EMC AX4-5 FC.  Citrix разместился на локальных SAS-дисках, тестовую виртуальную машину положил в виде LVM-диска.
Первый момент, который изрядно удивил – это прогон HD-Tune по диску. Картинка представляла собой набор ежесекундных перепадов скорости  от 0,5  до 70 МБ/сек. После нескольких прогонов скорость стабилизировалась.  Оригинальной картинки нет, но местами данные провалы остались. Не знаю, проблема это хранилища, но таких приколов раньше не видел, или LVM. На картинке выделил эллипсом, как выглядели перепады.
xen disk speed
Второй момент, который заинтересовал это поведение XenMotion. Запустив команду ping -t и сделав “движение”, увидел довольно занимательную картину – рост времени ответов до 30-50 мсек, проблема по истечению пары недель не повторилась (возможно помогло обновление прошивки хранилища). Как и у ESX теряется только один “пинг” в момент переключения на второй хост.

Что понравилось, так это библиотека образов ISO, которые хост цепляет напрямую с общих дисков, просто удобно. Ещё оценил разные кнопки у консоли – докинг, масштабирование, подключение по RDP.

При установке столкнулся с проблемами, видать от непривычки. Во-первых, FC-лун смог подключить только через GUI, через CLI-меню не нашёлся. Во-вторых, последовательность добавления хостов в пул слегка напрягла, если у хостов есть одинаковый лун, то нельзя добавить хосты, нужно вначале добавлять хосты, а потом уже к пулу лун. В-третьих, при нахождении GUI-клиента в одной подсетке не получалось добавить второй хост в пул, ругался, что не виден первый хост.

Общее впечатление: бесплатная версия имеет один плюс над Hyper-V – XenMotion, но есть и один жирный минус, чего-то я затруднился представить схему резервного копирования с LVM.

Citrix, ESX, USB-диски и разделы

Выход новых версий продуктов каждый раз заставляет планировать куда устанавливать и какой дистрибутив выбрать. Неделю назад задача для меня усложнилась вдвое: я решил потестировать Citrix XenServer 5, и в тот же день мне попал в руки дистрибутив ESX 4.0. Под тестирование я выделил два лезвия в блейд-центре, но основным желанием было посмотреть на XenMotion, так что Citrix я поставил на жёсткие диски обоих серверов. Что оставалось делать с ESX? По велению судьбы, в виде Google, у меня был RecoveryCD дистрибутив embedded версии, что спасло меня от дальнейших раздумий, воткнув свой USB-диск и отобрав у жены гламурную флешку, вставил их в те же самые лезвия, на которых уже стоял XenServer, и установил ESXi 4.

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

Достав из сервера и подключив к компьютеру, запустил управление дисками Windows. Картинка была следующая.

win drive manager
Пощелкав мышкой по разделам, я понял, что попадаю – разделы удалить нельзя, на свободном месте создать раздел также нельзя. Размер флешек 2 и 16 ГБ, а занимаемое место всего 704 МБ, поэтому  очень хотелось “вытащить” 16-гиговую, не пропадать же добру в размере 14+ ГБ.

Придя на работу, решил поискать современное ПО управления разделами. Скачал две пробные версии: Acronis Disk Director и Paragon Partition Manager.

Acronis показал лучшие знания структуры, определив даже swap-партицию VMware,  но пробная версия не дала мне возможности что-то менять.

acronis disk director
Paragon оказался более щедрым и все нужные мне функции были доступны. Так я получил универсальную флешку и файлики носить, и ESX запускать где угодно.

paragon partition manager
Теперь переход с Citrix на VMware занимает у меня 3 минуты времени, столько требуется перезагрузить сервера с выбором откуда грузиться, да и флешки при делах ;).