Шесть серверов в два: как считали коэффициент консолидации на VMware

У одного из клиентов в серверной стояло шесть физических серверов. Не потому что нагрузка требовала шести машин - просто так исторически сложилось: каждый год добавляли по серверу под новую задачу, и вот их уже шесть. Контроллер домена, файловый сервер, почта, веб, база 1С, тестовая среда. Шесть блоков питания, шесть комплектов вентиляторов, шесть машин, которые надо патчить, мониторить и обслуживать. При этом реальная утилизация у большинства из них - 10-20% по процессору, остальное время железо просто греет воздух.

Разговор о консолидации шёл давно. В январе мы впервые запустили боевую виртуалку на ESX и убедились, что это не эксперимент, а рабочий инструмент. Теперь взялись за полноценную перестройку серверной.

Что решили сделать

Цель была простая: вместо шести серверов - два. Один мощный под продакшн, один попроще под тестовую среду. VMware ESX на обоих.

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

Как считали коэффициент консолидации

Вот тут главная часть. Просто взять шесть серверов и сказать «ставим шесть виртуалок» - неправильно. Переуплотнить хост легко, и тогда все виртуалки начнут страдать одновременно.

Мы подходили к расчёту так.

Первое - собрали реальную нагрузку, а не паспортную. Снял с каждого сервера средний и пиковый CPU и RAM за последние два месяца - через Nagios у нас это накоплено. Средняя утилизация по процессору у пяти из шести серверов оказалась ниже 15%. Пиковая - до 60-70%, но это у файловика в момент резервного копирования и у базы 1С в период отчётности.

Второе - посчитали суммарный пик, а не суммарное среднее. Ошибка, которую делают часто: складывают средние значения и получают оптимистичную картину. Нам нужна сумма пиков с учётом того, насколько эти пики совпадают по времени. У файловика пик в час ночи (бэкап), у 1С - в конец квартала в рабочее время. Они почти не пересекаются. Это важно - можно взять хост с меньшим запасом.

Третье - заложили оверхед гипервизора и резерв роста. ESX сам потребляет ресурсы, плюс каждая виртуалка хочет немного больше RAM чем её реальный рабочий набор. Из практики: закладывай 15-20% сверху на оверхед VMware и ещё 25-30% резерв на рост нагрузки. Итого гипервизор должен вмещать сумму пиков всех гостей умноженную примерно на 1.4.

Посчитали - под продакшн нужен сервер с 16 гигабайтами RAM и двумя двухпроцессорными Xeon. Пять виртуальных машин туда встают с нормальным запасом. Шестая, тестовая среда, уходит на второй хост.

Коэффициент консолидации получился 5:1 для продакшн-хоста. Вполне реалистично - цифра 4-8 виртуалок на физический сервер, которую VMware приводит в материалах, примерно это и означает. Переуплотнения мы не допустили, потому что считали пики, а не средние.

Дисковая подсистема

Это отдельный разговор, и он важный. Мы уже сталкивались с тем, что дисковый I/O становится узким местом, когда несколько виртуалок работают с одним массивом.

На продакшн-хосте под хранилище взяли отдельный массив RAID 10 из шести дисков - не RAID 5, именно 10. Разница в скорости записи при смешанной нагрузке заметна. VMFS-тома разнесли: системные диски виртуалок на одном томе, данные (база 1С, почтовое хранилище, пользовательские файлы) - на другом. Это позволяет ограничить влияние бэкапных операций на рабочий I/O через расписание и приоритеты.

Что по деньгам

Лицензии VMware ESX стоят денег, это факт. Клиент спросил прямо: когда это окупится?

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

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

Как проходила миграция

Переносили по одной виртуалке, без спешки. Сначала подняли тестовую среду на втором хосте - туда перенесли тестовый сервер, убедились что всё работает. Потом последовательно мигрировали боевые системы: сначала те, где окно обслуживания взять проще (веб, файловик), в конце - почта и 1С, где клиент болезненнее реагирует на простой.

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

Итог

Серверная стала заметно тише и холоднее. Шесть машин в двух стойках превратились в два сервера. Физических - два, виртуальных - шесть, и добавить ещё проблемы нет.

Главное что мы вынесли из этого проекта: коэффициент консолидации надо считать честно, по пикам и с резервом, а не по средним значениям. Кто считает по средним - рано или поздно получает хост, у которого кончается RAM в самый неподходящий момент. Мы это видели у других, сами наступать не стали.

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