Как стать автором
Обновить

Yandex Planner. Как планировать вычислительные мощности

Время на прочтение14 мин
Количество просмотров12K
Всего голосов 47: ↑47 и ↓0+47
Комментарии3

Комментарии 3

Очень интересный пост! Спасибо! Полный технический доклад про дефрагментацию еще не смотрел, но есть пара интересных вопросов.

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

Еще интересен вопрос по поводу динамической аллокации ресурсов. Насколько я знаю, Kubernetes поддерживает динамический горизонтальный скейлинг подов в случае повышенной нагрузки или наоборот сниженной нагрузки. Кажется, для сервисов Яндекса это было бы очень полезно, ведь большинство трафика приходится на дневное время суток. В сожительстве с батчевыми задачами (например, Map Reduce) ресурсы можно было бы динамически шарить в течение дня: например днем, когда пользователи активно пользуются сервисами Яндекса, эти ресурсы можно было поставлять сервисам, а ночью, когда столько ресурсов уже не нужно, отдавать батчевым асинхронным задачам. Вы в целом такое собираетесь делать или это уже реализовано в каком-то виде?

На количество переселяемых подов есть ограничение сверху, поскольку, по закону распределения максимумов случайных величин, выселение 10 подов может сходиться довольно долго. А ещё ситуация на кластере постоянно меняется, и чем дольше мы исполняем план, тем более вероятно, что он уже потерял актуальность. Также в функционал ЦЛП с небольшим весом включено кол-во переселяемых подов - так что, при прочих равных, дефрагментатор предпочитает переселять поменьше.

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

Вы упоминаете, что используете солвер от google, который выдает решение примерно за полминуты для небольшого числа подов-серверов. Означает ли это, что для размещения нового пода нужно ждать полминуты для выбора оптимального размещения? И что происходит при массовых запусках подов, например, в сценариях включения множества серверов после устранения аварий в ДЦ – делается ли какой-то батчинг при расчете размещений, чтобы ускорить запуск?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий