Pull to refresh

Comments 19

Вроде бы все приличные системы управления виртуализацией умеют оптимизировать нагрузку, причем динамически, поэтому я не очень понимаю область практической применимости решения. Самописный скрипт для кучи неуправляемых серверов?
Давайте сначала перечислим все приличные системы управления виртуализацией, которые реально часто встречаются в продакшн. Мой опыт ограничивается 3 продуктами: VMware vSphere, Mircosoft SCOM и Openstack. Плюс самописные системы, такое тоже встречается.

VMware vSphere умеет оптимизировать размещение VM, но делает это, насколько я разобрался, на основе краткосрочных трендов (анализирует нагрузку за несколько минут) + порог, по которому она будет перемещать VM на другой сервер, администратор устанавливает сам. В продакшне это чревато тем, что VM может уехать на сервер, на котором уйдет в своп и оттуда её нужно будет доставать руками. И при оптимизации не учитываются долгосрочные тренды, а как раз их учет дает возможность построить глобально оптимальное размещение VM.

Microsoft SCOM не имеет встроенного оптимизатора ресурсов, аналогичного тому что мы делаем.

Чтобы получить такую функциональность в Openstack, вы должны будете развернуть Openstack Watcher. Мы неделю на это убили, но Watcher так и не запустили, всегда что-то, от чего он зависел, не работало или работало не так, как надо. И я пока не смог найти среди эксплуатантов Openstack кого-то, кто использует Watcher, хотя он больше всего похож на то, что мы делаем, и в части функционала ушел вперед.

В целом же то, что мы делаем, укладывается в мировой тренд cloud management automation, и не надо думать, что в этой области все задачи решены и решены идеально.
Небольшое уточнение к предыдущему комментарию. У Microsoft есть продукт SCVMM, который, судя по документации, по стратегиям оптимизации размещения VM аналогичен vSphere — основываясь на краткосрочных трендах, перемещает VM с перегруженных серверов на ненагруженные. Глобальной оптимизацией кластера он тоже не занимается.
Глобальной оптимизацией кластера он тоже не занимается.

Я приведу простой пример. Вот у вас есть куча камней, вам нужно уложить их как можно более плотно в емкость. Вы можете просчитать идеальное расположение каждого камня и сложить их (глобальная оптимизация), а можете просто высыпать кучей, а потом ее потрясти (динамическая оптимизация). И вот тут сразу возникает два вопроса:


  1. Первый способ, очевидно, намного сложнее, а вот насколько он будет эффективнее?
  2. А если камни могут менять размер и форму, имеет ли первый способ смысл в принципе?

Иными словами — нужна ли тут на самом деле глобальная оптимизация, или же достаточно локальных динамических оптимизаций, которые сойдутся к тому же (если не лучшему, с учетом динамического потребления ресурсов), результату?


Disclaimer. Это вопрос, на который я тоже не знаю ответа, а не попытка как-то умалить вашу работу. :)

Есть предположение, что никто не знает ответа на этот вопрос )))

У меня есть некоторое объяснение, которое ни к коем случае не претендует на какую-либо строгость в математическом смысле или общность, скорее это наблюдение. Мы некоторое время уже занимаемся оптимизационными задачами, и для их решения используем 2 подхода — линейное программирование или эвристики на основе его и генетические алгоритмы. Производительность у них примерно равная, если запускать их с одного начального неоптимального состояния. Но если сначала применить метод, основанный на линейном программировании, а получившееся решение подать на вход генетического алгоритма, то генетический алгоритм добавит еще 10%.

Можно провести грубую аналогию между генетическим алгоритмом (потрясти камешки) и динамической оптимизацией, то вроде как получается, что имеет смысл получить глобально оптимальное состояние, и от него делать уже локальные динамические оптимизации.

Причиной того, что так можно делать, мне кажется, является тот факт, что все алгоритмы находят субоптимальные состояния, а до настоящего глобального оптимума все равно достаточно далеко, и в этом случае начальная точка имеет значение.
Про камни, меняющие форму — следующая статья )
делает это, насколько я разобрался, на основе краткосрочных трендов (анализирует нагрузку за несколько минут) + порог, по которому она будет перемещать VM на другой сервер, администратор устанавливает сам.

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


В продакшне это чревато тем, что VM может уехать на сервер, на котором уйдет в своп и оттуда её нужно будет доставать руками.

Ну, наверное, специально такого можно добиться (особенно на кластере с оверкоммитом), но это вопрос выстрела себе в ногу, а не возможностей системы.


Microsoft SCOM не имеет встроенного оптимизатора ресурсов, аналогичного тому что мы делаем.

Даже голый Hyper-V 2016 имеет примитивный оптимизатор, а System Сenter — уже много лет как. Не знаю, что вы понимаете под "аналогичным". Если алгоритм — наверное, не имеет. Если конечный результат — вполне себе.


то, что мы делаем, укладывается в мировой тренд cloud management automation, и не надо думать, что в этой области все задачи решены и решены идеально.

Я потому и спрашиваю — область применимости вашего решения какая? :) Что вы можете делать лучше, чем другие, и как вас с этими другими сравнить? :)

Мы гораздо лучше учитываем совместимость VM в рамках одной ноды в долгосрочной перспективе, и про то, как мы это делаем, будет следующая статья.
И да, это все про оверкоммит, потому что если не делать его, то задача давно решенная.
Мы решаем следующий вопрос: как делать максимально возможный при данных нагрузках оверкоммит так, чтобы он не ухудшал работу VM в кластере.
Еще вроде есть 5nine manager для управления hyper-v
VMware DRS у нас уже все это делает, причем очень эффективно. Учитываются как тренды, так и аптайм конкретного хоста, средняя нагрузка, учитывается очень много параметров, включая объем памяти на хосте, отношение к ядрам. И работает это очень эффективно для производительности конкретных машин. Если надо чтоб какая-то виртуалка не уезжала на другой хост, а была только на каком-то конкретном или ездила только между какими-то хостами, а не по всему кластеру — тоже легко делается.

Всё верно, только максимальный размер кластера — 64 сервера.

у меня только один вопрос — что сделают с этим «оптимизатором» когда произойдет поломка оборудования и у него будет жесткий недостаток ресурсов?
Как правило всегда оставляют некий запас оборудования на случай выход аварий/обслуживания
Не понимаю проблемы. На кластере даже в несколько десятков серверов выход одного сервера из строя не приведет росту нагрузки на остальные сервера в разы, а только на проценты, а с этим кластер справится.
Данная задача в научной литературе называется bin packing problem (как это будет по-русски?)

Да примерно так же и будет: задача упаковки в контейнеры. Вариация — задача об укладке ранца (задача о ранце), когда в один заданный надо положить как можно больше всего.

Вот дочитал и автор выше(Dr_Wut) как раз задал мой вопрос, о котором я как раз подумал. Первое интересует, это обслуживание, второе это выход диска/сервера.

UFO just landed and posted this here
Мы не имеем доступ внутрь VM. Так что код переписать точно не получится )

Немного не в тему вопрос будет, но как вы в clickhouse складываете данные? Через файл CSV и клиента командной строки или как то ещё?

Подозреваю, что как мы — при помощи telegraf, скриптов, снимающих данные о вм и какой-то матери :-)
Sign up to leave a comment.

Articles