Комментарии 20
VMware vSphere умеет оптимизировать размещение VM, но делает это, насколько я разобрался, на основе краткосрочных трендов (анализирует нагрузку за несколько минут) + порог, по которому она будет перемещать VM на другой сервер, администратор устанавливает сам. В продакшне это чревато тем, что VM может уехать на сервер, на котором уйдет в своп и оттуда её нужно будет доставать руками. И при оптимизации не учитываются долгосрочные тренды, а как раз их учет дает возможность построить глобально оптимальное размещение VM.
Microsoft SCOM не имеет встроенного оптимизатора ресурсов, аналогичного тому что мы делаем.
Чтобы получить такую функциональность в Openstack, вы должны будете развернуть Openstack Watcher. Мы неделю на это убили, но Watcher так и не запустили, всегда что-то, от чего он зависел, не работало или работало не так, как надо. И я пока не смог найти среди эксплуатантов Openstack кого-то, кто использует Watcher, хотя он больше всего похож на то, что мы делаем, и в части функционала ушел вперед.
В целом же то, что мы делаем, укладывается в мировой тренд cloud management automation, и не надо думать, что в этой области все задачи решены и решены идеально.
Глобальной оптимизацией кластера он тоже не занимается.
Я приведу простой пример. Вот у вас есть куча камней, вам нужно уложить их как можно более плотно в емкость. Вы можете просчитать идеальное расположение каждого камня и сложить их (глобальная оптимизация), а можете просто высыпать кучей, а потом ее потрясти (динамическая оптимизация). И вот тут сразу возникает два вопроса:
- Первый способ, очевидно, намного сложнее, а вот насколько он будет эффективнее?
- А если камни могут менять размер и форму, имеет ли первый способ смысл в принципе?
Иными словами — нужна ли тут на самом деле глобальная оптимизация, или же достаточно локальных динамических оптимизаций, которые сойдутся к тому же (если не лучшему, с учетом динамического потребления ресурсов), результату?
Disclaimer. Это вопрос, на который я тоже не знаю ответа, а не попытка как-то умалить вашу работу. :)
У меня есть некоторое объяснение, которое ни к коем случае не претендует на какую-либо строгость в математическом смысле или общность, скорее это наблюдение. Мы некоторое время уже занимаемся оптимизационными задачами, и для их решения используем 2 подхода — линейное программирование или эвристики на основе его и генетические алгоритмы. Производительность у них примерно равная, если запускать их с одного начального неоптимального состояния. Но если сначала применить метод, основанный на линейном программировании, а получившееся решение подать на вход генетического алгоритма, то генетический алгоритм добавит еще 10%.
Можно провести грубую аналогию между генетическим алгоритмом (потрясти камешки) и динамической оптимизацией, то вроде как получается, что имеет смысл получить глобально оптимальное состояние, и от него делать уже локальные динамические оптимизации.
Причиной того, что так можно делать, мне кажется, является тот факт, что все алгоритмы находят субоптимальные состояния, а до настоящего глобального оптимума все равно достаточно далеко, и в этом случае начальная точка имеет значение.
делает это, насколько я разобрался, на основе краткосрочных трендов (анализирует нагрузку за несколько минут) + порог, по которому она будет перемещать VM на другой сервер, администратор устанавливает сам.
Это уж слишком сжатое описание мануалов на сотни страниц. :) VMWare может делать в том числе ровно то же, что и вы (задать фиксированный резерв для каждой машины и раскидать по имеющимся нодам), плюс много-много чего ещё.
В продакшне это чревато тем, что VM может уехать на сервер, на котором уйдет в своп и оттуда её нужно будет доставать руками.
Ну, наверное, специально такого можно добиться (особенно на кластере с оверкоммитом), но это вопрос выстрела себе в ногу, а не возможностей системы.
Microsoft SCOM не имеет встроенного оптимизатора ресурсов, аналогичного тому что мы делаем.
Даже голый Hyper-V 2016 имеет примитивный оптимизатор, а System Сenter — уже много лет как. Не знаю, что вы понимаете под "аналогичным". Если алгоритм — наверное, не имеет. Если конечный результат — вполне себе.
то, что мы делаем, укладывается в мировой тренд cloud management automation, и не надо думать, что в этой области все задачи решены и решены идеально.
Я потому и спрашиваю — область применимости вашего решения какая? :) Что вы можете делать лучше, чем другие, и как вас с этими другими сравнить? :)
И да, это все про оверкоммит, потому что если не делать его, то задача давно решенная.
Мы решаем следующий вопрос: как делать максимально возможный при данных нагрузках оверкоммит так, чтобы он не ухудшал работу VM в кластере.
Как правило всегда оставляют некий запас оборудования на случай выход аварий/обслуживания
Данная задача в научной литературе называется bin packing problem (как это будет по-русски?)
Да примерно так же и будет: задача упаковки в контейнеры. Вариация — задача об укладке ранца (задача о ранце), когда в один заданный надо положить как можно больше всего.
Вот дочитал и автор выше(Dr_Wut) как раз задал мой вопрос, о котором я как раз подумал. Первое интересует, это обслуживание, второе это выход диска/сервера.
Немного не в тему вопрос будет, но как вы в clickhouse складываете данные? Через файл CSV и клиента командной строки или как то ещё?
Интересно получил ли какоето развитие проект?
Оптимизация размещения виртуальных машин по серверам