ESXi без лицензии: переводим сервер с ESX и считаем, что сломалось

В начале января VMware убрала последний барьер для ESXi: теперь его можно скачать и использовать без лицензии вообще. Не триал, не регистрация с ключом на почту - просто качаешь ISO и ставишь. Для нас это повод закрыть давно открытый вопрос про один из хостов у клиента.

Немного предыстории. Когда мы впервые посмотрели на ESXi в 2007-м, вывод был такой: интересно, но переходить с рабочего ESX нет смысла, пока мониторинговая инфраструктура завязана на Service Console. С тех пор прошло два года. У одного из клиентов появился небольшой физический сервер - не главный продакшн-хост, но и не тестовый стенд: крутит несколько VM с внутренними сервисами. На нём стоит ESX 3.0 с лицензией, которая оплачивается ежегодно. Экономика простая: если ESXi справляется с той же задачей и стоит ноль рублей - зачем платить?

Решили проверить на практике.

Что переехало и как

Сервер небольшой - два процессора, восемь гигабайт памяти, локальные диски RAID 5. Виртуалок три: внутренний файловый сервис, DNS/DHCP-резерв и тестовая среда разработки. Ничего критического с точки зрения SLA, но живое.

Процедура переноса прямолинейная: экспортировали VMDK из ESX, подготовили носитель с ESXi 3.5, поставили на тот же сервер. ESXi встаёт быстро - установка занимает минут пятнадцать, после чего загружается минималистичная текстовая консоль DCUI. Никакого Linux-окружения, никакого bash-шелла, который привычно открывался по SSH в ESX. Виртуалки подключили через VI Client - завелись без проблем, сетевые адаптеры пересоздали руками.

По footprint разница заметная. ESX занимал на служебном разделе несколько гигабайт под Service Console и её зависимости. ESXi - около 32 МБ, и всё. На сервере с локальными дисками это не критично, но опрятно.

Где полезло

Ровно там, где мы и ожидали - скрипты.

За два года на ESX накопился набор небольших shell-скриптов, которые жили в Service Console и делали разную рутину: собирали метрики виртуалок через vmware-cmd, дёргали статус дисков через esxcfg-info, отправляли всё это в Nagios через NRPE. Уютная экосистема, держалась на том, что к хосту можно зайти по SSH и запустить что угодно.

В ESXi ничего этого нет.

Мониторинг через NRPE - отпал целиком. На хосте нет окружения, куда его поставить. Опрос хоста теперь только через SNMP или VMware VI API. SNMP у ESXi есть из коробки, настроили его - базовые метрики (загрузка CPU, память, диски) пошли в Nagios через стандартные SNMP-чеки. Это хуже, чем было: часть специфичных для VMware параметров через SNMP не вытащить, только через API. До переписывания проверок на API руки пока не дошли - живём на SNMP.

HP Insight Manager Agent - та же история. Агент под ESX работал в Service Console и докладывал о состоянии железа: температуры, вентиляторы, RAID-контроллер. Под ESXi HP предлагает CIM-провайдеры - это другой механизм, требует отдельной настройки. Настроили, часть данных видна, но не всё. Статус массива теперь проверяем через iLO напрямую - медленнее, чем раньше, но не критично.

Собственные скрипты через vmware-cmd - переписали на Remote CLI. VMware поставляет набор утилит для удалённого управления хостом, запускаются с отдельной Linux-машины. Функционально перекрывают большую часть задач, но синтаксис другой, пришлось переделывать.

Что в итоге

Хост работает на ESXi третью неделю, виртуалки живые, клиент не замечает разницы. Лицензионный платёж за ESX снят с повестки - это конкретная экономия, небольшая, но реальная.

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

Для хоста с несложными требованиями к управлению ESXi - нормальный выбор. Для инфраструктуры, где на ESX завязан глубокий мониторинг и автоматизация через Service Console - переход потребует внимательного аудита того, что именно там живёт, прежде чем что-то трогать.

У клиентов, чью инфраструктуру мы ведём, такие переносы надо готовить заранее, а не обнаруживать сломанный мониторинг постфактум. На этот раз успели - потому что хост был не главным. На главном сначала починим инструменты, потом переедем.