[recovery mode] Оver-provisioning ресурсов в кластерах на базе mesos
Разработчики Apache mesos заявляют, что mesos научился делать overprovisioning начиная с версии 0.23.0, вышедшей в сентябре прошлого года. Для этого ввели понятие отзываемых (revocable) ресурсов, и если приложение выполняется на отзываемых ресурсах — его всегда можно попросить освободить ресурсы частично (throttle) или полностью (kill). Определить, на каких ресурсах будет выполняться задача можно на этапе запуска, пометив некоторые (или все) запрошенные задачей ресурсы как revocable.
На практике, для использования этой фичи нужно:
- Заявить о поддержке REVOCABLE_RESOURCES при регистрации framework в mesos
- Подключить к mesos slave модуль resource estimator, который бы оценивал количество отзываемых ресурсов (например измеряя разницу между потребленными и выделенными ресурсами) и предсказывал изменения в потреблении ресурсов (например на основе статистической модели)
- Подключить к mesos slave модуль QoS Controller, который бы убивал или ограничивал в ресурсах задачи, запущенные на отзываемых ресурсах.
Как видно из требований выше, для эффективного использования предложенной модели требуется некоторая поддержка со стороны выполняемых в mesos задач, как минимум в части управления потребляемыми ресурсами. Конечно, будет очень круто написать resource estimator привязанный к логике приложения, но даже предсказания на основе ежедневной статистики изменения нагрузки дадут неплохой эффект.
В комплекте с mesos сейчас поставляются пара resource estimator’ов:
noop— заглушка, запрещающая oversubscriptionfixed— позволяющий объявить отзываемыми фиксированное количество ресурсов хоста.
и пара qos controller’ов:
noop— отключит отзыв ресурсов на уровне хостаload— умеет убивать все задачи, выполняемые на отзываемых ресурсах, если load average на хосте превысит пороговые значения
К сожалению на этом хорошие новости пока заканчиваются, т.к. поддержка со стороны распространенных framework’ов практически отсутствует.
В Marathon например поддержка отзываемых ресурсов пока реализована крайне слабо:
Кстати, в вышеупомянутой статье есть утверждение которое полезно показать менеджменту, требующему оптимизировать использование ресурсов отталкиваясь от низкой утилизации cpu на хостах, например:
While CPU and memory allocation is often close to or above 80% of those peak loads, the average usage is typically below 20%.
В kubernets, и того меньше — удалось найти один непопулярный issue с упоминанием проблемы.
Таким образом, сейчас на базе стека mesos-marathon не получится использовать over-provisioned ресурсы, что явно сказывается на экономической эффективности решения.
