Главная ценность виртуализации — упаковать больше нагрузок на меньшем числе серверов. Но «упаковать» не значит «свалить в кучу»: если сто виртуальных машин расставить по узлам как попало, один сервер будет задыхаться, а три соседних — простаивать. За правильную расстановку отвечает балансировщик нагрузки. Разбираем, как он устроен в AirCloud и откуда берётся цифра «до 40% больше машин на том же оборудовании» и что она значит для числа серверов.
Что делает балансировщик
Балансировщик решает, на каком узле кластера запустить каждую машину, а при доступной живой миграции — когда её стоит перенести. Он смотрит на загрузку процессора и памяти по всем узлам, на заданные машинам гарантии и максимумы, на пороги и расписание — и принимает решения без участия администратора.
В AirCloud балансировщик — собственная разработка на математической модели, а не набор скриптов. Он справляется с разнородным железом: кластер может состоять из серверов разного поколения и размера, и балансировщик учитывает это при расстановке.
Два режима: производительность или плотность
Ключевая возможность — управлять нагрузкой в двух противоположных логиках:
Режим максимальной производительности. Балансировщик задействует максимум узлов, чтобы переподписка стремилась к нулю и каждая машина получала ровно свои ресурсы. Это режим для критичных нагрузок: базы данных, платёжные системы, всё, где важна предсказуемая скорость.
Режим максимальной плотности. Наоборот: машины размещаются на минимальном числе серверов — с пониманием, что не все нагружают процессор на 100% одновременно. Когда узел освобождается — его машины выключены по расписанию или перенесены, если доступна живая миграция, — система отправляет его в гибернацию или выключает через интерфейс управления питанием IPMI. Когда нагрузка растёт — будит серверы обратно и возвращает в работу.
Для дата-центра это прямые деньги: выключенный сервер не потребляет электричество и не греет воздух, который потом охлаждают. Именно этот режим и даёт основную экономию.
Веса, пороги, расписание
Балансировщик настраивается профилями, и в них есть всё, что нужно инженеру:
- Веса процессора и памяти — в сумме единица, каждый от 0,1 до 0,9; меняются на лету. Кластеру с прожорливыми по памяти нагрузками — вес памяти выше.
- Пороги — при какой загрузке узла менять размещение новых машин и, если доступна живая миграция, начинать перераспределение работающих.
- Расписание — днём режим производительности, ночью и в выходные плотность: узлы, освободившиеся после выключения машин, уходят в гибернацию.
- Обычный и критический профили — при приближении к пределу срабатывает критический профиль с более жёсткой логикой.
Всё это задаётся в консоли, без командной строки, и применяется без перезапуска машин.
Гарантии и максимумы: оверкоммит под контролем
Балансировка работает поверх того, как заданы ресурсы самим машинам. Каждой машине назначаются гарантированный минимум и допустимый максимум процессора и памяти. Гарантия — это то, что машина получит всегда; максимум — то, что ей позволят взять, если ресурсы свободны.
Под капотом ресурсы нарезаются на уровне ядра, вплоть до доли гигагерца, — поэтому переподписка не превращается в лотерею: гарантии соблюдаются, пока сумма гарантированных ресурсов машин на узле не превышает его физические ресурсы. Для рабочих столов степень переподписки задаётся один раз на уровне золотой реплики — подробнее в статье про реплики и пулы.
Горячее добавление процессора и памяти работает в пределах заданного максимума, если его поддерживает гостевая ОС. Платёж за эту гибкость — предразметка максимумов в наших замерах стоила 3–5% производительности; «вечный» горячий резерв без разметки обходился бы примерно в 20%. Цифры зависят от конфигурации и профиля нагрузки.
Откуда берётся экономия
Три источника, и они складываются:
- Меньше серверов под ту же нагрузку. В тестах балансировщик позволял разместить до 40% больше машин на том же железе. Плотность ×1,4 в идеальном расчёте даёт до ~29% меньше серверов (1 − 1/1,4); фактическое число зависит от округления до целых серверов, резерва под HA и профиля нагрузки.
- Меньше электричества и охлаждения. Режим плотности гасит незагруженные серверы. В одном проекте у крупного телеком-оператора совокупная стоимость владения снизилась примерно на 20% за счёт гибернации; результат зависит от профиля нагрузки, состава затрат и конфигурации.
- Меньше ручной работы. Администратор не расставляет машины руками и не следит за загрузкой по ночам.
Как посчитать это для своей инфраструктуры — в методике TCO виртуализации.
Балансировка и перенос машин
Полноценная автоматическая балансировка работающих машин опирается на живую миграцию — перенос машины между узлами без остановки. Доступность живой миграции и поддерживаемые конфигурации зависят от версии AirCloud — для вашей инсталляции уточняем на демонстрации. Без неё балансировщик влияет на размещение машин при запуске и по расписанию. Подробнее — в статье про живую миграцию.
На что смотреть при выборе платформы
При оценке платформы стоит уточнить, есть ли тонкое управление ресурсами помимо обычной переподписки, умеет ли балансировщик гасить серверы, а не только расставлять машины, и настраивается ли он по расписанию. Именно это отличает инструмент операционной эффективности от простого «запускателя» виртуальных машин. Из чего ещё состоит зрелая платформа — в разборе системы виртуализации.
Хотите увидеть, как балансировщик гасит серверы ночью и будит их утром, — запросите демо, покажем на живом стенде.