vSphere 5 beta: Storage DRS, 10 GbE vMotion и лицензия по vRAM, которая пугает

VMware на прошлой неделе анонсировала vSphere 5 и открыла бета-программу. Мы немедленно записались: на одном из клиентских кластеров у нас стоит ESX 4.1, и вопрос «когда переходить» стал актуальным. Первые два дня в бете дали ответы на часть вопросов - и подняли новые, куда менее приятные.

Что реально интересного в ESXi 5

Главное изменение, которое видно сразу: классический ESX с Service Console окончательно убит. Остаётся только ESXi - тот самый, который мы разбирали ещё в 2007-м как bare-metal альтернативу классическому ESX. Теперь это не альтернатива, а единственный вариант. Для наших клиентских хостов это означает финальный переезд мониторинга с NRPE на SNMP и VI API - задача, которую мы откладывали несколько кварталов.

Storage DRS - это то, что нас привлекло больше всего. По аналогии с обычным DRS, который балансирует виртуалки между хостами по CPU/RAM, Storage DRS балансирует датасторы по I/O и свободному месту. В нашем случае клиент с четырьмя LUN-ами на FC-полке регулярно получает ситуацию, когда один LUN забит под завязку, а три других полупустые. Сейчас это решается руками через Storage vMotion. Storage DRS должен делать это автоматически - как минимум при начальном размещении новой VM, как максимум при вечерней перебалансировке.

В бете Storage DRS выглядит работающим. Настраивается через Datastore Cluster - группируешь несколько датасторов в кластер, задаёшь пороги по месту и латентности, дальше система сама. Мы не успели гонять его достаточно долго, чтобы оценивать надёжность, но первые тесты с принудительной загрузкой одного LUN показали - перебалансировка запускается, рекомендации генерируются, в автоматическом режиме Storage vMotion выполняется без участия человека.

vMotion по 10 GbE - второй пункт нашего теста. У клиента с этого квартала стоит 10-гигабитный коммутатор, и мы давно хотели перетащить vMotion-трафик с гигабита на десятку. В ESX 4.1 это теоретически поддерживалось, но требовало ручной настройки Jumbo Frames и отдельного vmkernel-порта. В vSphere 5 конфигурация выглядит проще, и результат ощутимый: миграция нагруженной виртуалки с 32 ГБ занятой памяти - меньше минуты против четырёх-пяти на гигабите. Для живых миграций во время обслуживания хостов это принципиально важно - окно прерывания сокращается.

Из менее заметного, но полезного: улучшенный Auto Deploy для бездисковых хостов, нормальный PowerCLI под новое API, расширенные возможности distributed switch. Всё это мы ещё не трогали вплотную.

Лицензирование по vRAM: считаем в живых деньгах

А вот тут начинается неприятная часть.

VMware меняет модель лицензирования. Раньше лицензия vSphere привязывалась к физическому процессору (сокету) - купил лицензию на двухсокетный хост, получил гипервизор без ограничений по памяти. Теперь вводится понятие vRAM Entitlement: каждая лицензия покрывает определённый объём виртуальной памяти, которую можно одновременно раздать виртуалкам. Превысил - либо докупаешь лицензии, либо режешь ресурсы VM.

Лимиты по редакциям примерно такие: vSphere Enterprise Plus даёт 96 ГБ vRAM на лицензию. Стандарт - 32 ГБ. Essentials Plus - и того меньше.

Берём продакшн-кластер клиента: три хоста по 96 ГБ физической RAM, запущено около сорока виртуалок с суммарно выделенными 180 ГБ vRAM. По старой модели нам хватало шести процессорных лицензий (два сокета на хост). По новой - при Enterprise Plus с 96 ГБ на лицензию - нужно как минимум две лицензии только чтобы покрыть 180 ГБ vRAM. Звучит терпимо, но только пока кластер не растёт.

Проблема в том, что виртуализация предполагает оверкоммит памяти. Вы выделяете виртуалке 8 ГБ, она реально использует 4 ГБ, и это нормально - так работает balloon driver и transparent page sharing. Но по новой модели VMware считает выделенную память, а не используемую. Если вы агрессивно оверкоммититесь - вы платите за все выделенные гигабайты, даже если хост физически не видит больше половины из них реально занятыми.

Сообщество VMware отреагировало предсказуемо - форумы кипят. Главный аргумент: оверкоммит - это не баг, это фича, ради которой виртуализация и покупалась. Теперь фича монетизируется.

VMware пока говорит, что модель может корректироваться по итогам бета-программы. Возможно. Но рассчитывать на это серьёзно не стоит.

Что мы делаем прямо сейчас

Тестирование продолжается. Storage DRS хотим погонять на более интенсивной нагрузке, чтобы понять, насколько агрессивно он перекладывает I/O и не создаёт ли лишней нагрузки на хранилище во время перебалансировки.

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

В управлении клиентской инфраструктурой у нас сейчас семь кластеров на ESX 4.x, и ни одного перевода на ESXi 5 в продакшне до выхода релиза мы не планируем. Beta есть beta. Но подготовительная работа - инвентаризация выделенной vRAM и расчёт стоимости апгрейда - идёт уже сейчас.