Переподписка — способ разместить на сервере больше виртуальных машин, чем позволяет простая арифметика. Вопрос «как у вас задаётся overcommit» звучит почти на каждой встрече с заказчиками. Разбираем, что это такое, где переподписка задаётся в Inscale, как на неё влияет режим балансировщика и как выбирать значения.
Что такое переподписка ресурсов
Переподписка (overcommit) — это ситуация, когда виртуальным машинам суммарно выделено больше ресурсов, чем физически есть на сервере. Она работает потому, что машины редко нагружены одновременно: пока одна простаивает, её процессорное время и память может использовать другая.
Переподписка полезна, когда пики нагрузки разных машин не совпадают. Если все машины загружены одновременно, ресурсов на всех не хватит — и чем выше коэффициент, тем заметнее это для пользователей. Поэтому главный вопрос не «какой коэффициент поставить», а «каким машинам можно уступать ресурсы, а каким нельзя».
Общий коэффициент и чего он не говорит
Обычно переподписку описывают одним числом на сервер или кластер: например, «процессор — 4 к 1». Такое число удобно для планирования: по нему считают, сколько машин поместится на сервер. Но оно ничего не говорит о том, какая машина уступит ресурсы, когда их не хватит. На одном сервере могут работать второстепенный служебный сервис, которому не страшно подождать, и рабочие места сотрудников, для которых задержка заметна сразу. Общее число заставляет выбирать: либо осторожное значение для всех и недогруженные серверы, либо высокое — и риск для важных машин.
Как это сделано в Inscale: гарантированные и максимальные ресурсы
В Inscale общего коэффициента на сервер или кластер нет. Для каждой виртуальной машины указываются два значения — отдельно для процессора и для памяти:
- Гарантированные ресурсы — то, что балансировщик нагрузки платформы закрепляет за машиной. На них не претендуют другие машины, и они остаются за ней при любой нагрузке на сервер. Платформа не даст создать машину, если гарантированных ресурсов на сервере уже не хватает.
- Максимальные ресурсы — потолок, до которого машина может вырасти, если в общем пуле есть свободные ресурсы. Машина берёт их на время пиковой операции и возвращает обратно.
Например, некритичному сервису можно гарантировать одно ядро и разрешить рост до десяти: гостевая система видит десять ядер и использует их, когда сервер свободен, а под нагрузкой за машиной остаётся её гарантированное ядро.
Коэффициент переподписки в такой схеме — это отношение максимальных ресурсов к гарантированным, и у каждой машины он свой. Изменения в пределах заранее заданных максимумов применяются без остановки машины, если гостевая система поддерживает горячее добавление ресурсов.
Как платформа ограничивает ресурсы внутри сервера — в статье Управление ресурсами виртуальных машин через cgroups.
Режим балансировщика: насколько переподписка используется
Значения у машины задают, сколько ресурсов она может получить. Насколько переподписка используется на деле, зависит ещё от режима балансировщика нагрузки, который настраивается в кластере:
- Максимальная производительность — машины распределяются по большему числу серверов, у каждой остаётся больше свободных ресурсов, переподписка используется меньше.
- Максимальная плотность — машины размещаются плотнее, серверы загружаются по максимуму; так экономят на электропитании и охлаждении, когда нагрузка невелика.
У профилей балансировки есть расписание. Например, днём кластер VDI работает в режиме производительности, чтобы пользователям было комфортно, а ночью переходит в режим плотности, когда работают немногие сотрудники и сервисы.
Как выбирать значения
Общего «правильного» коэффициента нет — реальную плотность подбирают под рабочие сценарии. Практические ориентиры, которые команда Inscale называет на встречах:
- второстепенным сервисам, которые могут подождать, допустима высокая переподписка — в несколько раз;
- важным пользовательским машинам потолок лучше держать близко к гарантии: больше двукратного превышения ставить не стоит.
Три правила, которые стоит соблюдать при любом значении:
- Проверять на реальной нагрузке. Эффект оценивают по времени входа пользователей, отклику приложений, памяти и задержкам хранилища, а не по загрузке процессора.
- Оставлять резерв под отказ сервера. При уплотнении нужно сохранить ресурсы, на которых перезапустятся машины отказавшего узла.
- Повторять тест с отключённым сервером. Если при потере одного узла пользователи укладываются в согласованные требования по отклику — значения выбраны верно.
Переподписка диска: политика на золотой реплике
В VDI есть второй вид переподписки — по диску. Рабочие столы в пуле создаются из золотой реплики, и место на хранилище расходуется по мере того, как диски машин растут. Сколько им разрешено вырасти — это и есть политика переподписки диска.
В Inscale эта политика задаётся не на хранилище, а на золотой реплике. Причина — в типичной ситуации: заказчику выделено одно хранилище на несколько терабайт, и на нём живут очень разные машины. Массовые пулы работают на перемещаемых профилях — данные пользователей лежат отдельно, диски самих машин почти не растут, и ограничение им не нужно. Рядом — машины системных администраторов, которым без жёсткого лимита хватит времени занять всё место. Одна политика на всё хранилище не подходит ни тем, ни другим; политика на реплике позволяет задать каждому пулу своё правило.
Итог
Переподписка — это не один коэффициент, а решение для каждой группы машин. В Inscale по процессору и памяти она задаётся на уровне виртуальной машины через гарантированные и максимальные ресурсы, а по диску в VDI — на уровне золотой реплики. Насколько она используется, определяет режим балансировщика в кластере. Значения подбирают на реальной нагрузке и с запасом под отказ сервера.
Как это выглядит в интерфейсе — в документации Inscale. Чтобы посмотреть платформу на своих задачах — оставьте заявку.
