VMware ESX в продакшне: первая боевая виртуалка вместо второго сервера

Года четыре назад мы смотрели на VMware с осторожностью: тестовые стенды - да, охотно, но боевые сервисы клиента - на голое железо, без вариантов. С тех пор VMware выпустила ESX - это уже не Workstation с надстройкой поверх Windows, а отдельный гипервизор, который встаёт прямо на железо. Разница принципиальная. В конце декабря мы впервые отдали под него настоящий продакшн.

Клиент - небольшая компания, у которых на аутсорсе у нас вся инфраструктура. Конфигурация до переезда: два физических сервера. На одном - веб-сервис и база данных под него, на втором - файлы и почта. Второй сервер старше, железо слабее, и как раз подошло время его менять. Руководство поставило вопрос прямо: берём новое железо или попробуем консолидировать всё на одну мощную машину с виртуализацией?

Попробовали.

Что поставили и как мигрировали

Взяли двухпроцессорный сервер с запасом по памяти - восемь гигабайт, конфигурация серьёзная. ESX встаёт на своей маленькой служебной партиции, управление через отдельный Windows-клиент - VirtualCenter. Каждая виртуальная машина видит выделенные ей ресурсы и не знает о соседях.

Миграцию делали в два захода. Сначала подняли виртуалки параллельно с живым железом, синхронизировали данные, потом в согласованное с клиентом окно переключили DNS и почту. Суммарный простой - меньше часа. Это хорошо.

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

Что реально дала консолидация

Деньги. Один новый сервер вместо одного нового и одного старого. Экономия очевидная, клиент её видит.

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

Снапшоты как рабочий инструмент. Это изменило психологию обновлений. Раньше - нервотрёпка и перестраховка. Теперь - снял снапшот, сделал работу, удалил снапшот. Страх убрать что-то не то заметно меньше.

Изоляция сервисов. Веб и почта живут в отдельных виртуалках и не мешают друг другу. Если один из сервисов начинает жрать процессор - у соседа есть свои гарантированные ресурсы.

Где споткнулись

Дисковая подсистема. Именно там оказался главный сюрприз, и не сказать что приятный.

ESX хранит диски виртуальных машин в больших vmdk-файлах на своей файловой системе VMFS. Всё ввод-вывод от обеих виртуалок идёт через одни и те же физические диски. У клиента стоит RAID 5 из четырёх дисков - казалось бы, приличная конфигурация. Но когда ночью начинается бэкап одной виртуалки, а параллельно на второй идёт почтовый трафик, дисковая очередь начинает замедляться заметнее, чем мы ожидали.

На практике это проявилось так: несколько раз ночью длинный запрос к базе данных занимал вдвое больше обычного именно в момент пика I/O от соседней машины. Днём, при нормальной нагрузке, всё нормально. Но ночные задачи у клиента есть - отчёты, регламентные операции в 1С.

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

Второй момент, который стоит отметить: если физический сервер ложится - ложатся все виртуалки сразу. Раньше у клиента было два сервера, и выход одного не останавливал всё. Теперь единая точка отказа стала жёстче. Мы это клиенту объяснили, он принял. Компенсируем качеством железа и мониторингом, но иллюзий не строим.

Итог на сегодня

ESX в продакшне - это уже не эксперимент. Виртуалка вместо второго сервера работает, клиент доволен экономией, снапшоты изменили нашу повседневную работу к лучшему.

При этом консолидация - это не просто «поставил и забыл». Дисковая подсистема требует внимания с самого начала, её надо планировать под суммарную нагрузку, а не под каждую машину по отдельности. Единая точка отказа никуда не делась - её надо признать и компенсировать другими средствами.

Мы это теперь знаем не из документации, а из первых рук. И следующий клиент с похожей задачей получит уже другой разговор на старте.