Понятное дело, что cgroups можно использовать с более умными алгоритмами и более красиво, но, в рамках MVP, на мой взгляд реализация более чем допустима :)
P.S Да, в статье изначально надо было отписать, что речь про оверселлинг по процессору, мой недочет
Теперь попробуйте провести эксперимент с десятками ВМ:
Укажите всем ограничения через -smp по числу ядер и оперативной памяти, запустите на всех нагрузку, посмотрите как со временем ВМ начнут вести себя, и вы явно заметите что одни ВМ начнут забирать больше ресурсов чем другие при указанных ограничениях, это и называется проблема шумного соседа, ваш флаг -smp на уровне qemu, а проблема на уровне ядра, оно указывает сколько vCPU и RAM забирать, но не указывает то, сколько процессорного времени забирать
В моем коде по пути проекта: agent/client/pycgroup/ctl/cpu_ctl.py
Я перевожу ограничения по ядрам эквивалентно процессорному времени. Вы можете создать 2 ВМ которые берут по 6 ядер, хотя по факту у вас физически ядер 6, первая ВМ при нагрузке сможет спокойно забирать больше 90% процессорного времени, потому что вы честно указали - у тебя есть 6 ядер
P.S На крупных платформах сумма vCPU всех ВМ почти всегда в разы превышает количество физических ядер на хосте(Overcommit)
Остальные и другие технологии добавить не является абсолютно никакой проблемой
со стороны бизнеса действительно звучит как недооценка рисков - буду аккуратнее в формулировках. И про одиночку тоже верно: сейчас я работаю над децентрализованной GPU-сетью, но уже с командой. Спасибо, что подметили - полезная обратная связь.
Прошу вас предоставить доказательную базу почему мои наработки это "поделки студента для образовательных целей", иначе ваш комментарий рискует превратиться в комментарии без ценности, ведь, я предполагаю, что вы подробно изучили проект перед тем как выдать свой вердикт, заранее благодарю.
P.S Проект - POC, и в статье я честно пишу, что он не взлетел по бизнес-причинам, основной функционал виртуализации на уровне агента полностью рабочий, что подтверждается автотестами: agent/client/tests/
Был реализован базовый функционал который позволял использовать платформу полноценно, я не фокусировался на одном лишь распределении ресурсов, но это была фича которую я хорошо реализовал, она решала конкретную доказанную боль, решения которой я не увидел ни у одного крупного вендора. Миграции и отказоустойчивость это две стороны одной технологии, когда ВМ выходит из строя она автоматически мигрирует в соседнюю работающую ноду, поскольку конфиги и данные хранятся на удаленных хранилищах. Остальные и другие технологии добавить не является абсолютно никакой проблемой в большинстве своем, это вопрос запросов заказчика и потребностей рынка.
Да, абсолютно с вами согласен, я писал также множеству интеграторов с предложением о сотрудничестве. Но так или иначе отклика не последовало, зато опыт)
DRA штука интересная, вопрос только в себестоимости перехода, пет проектом и подобным это и не нужно, а вот чтобы кластер перевести да и так чтобы ничего не сломать, у многих еще и множество иных расширений, не будут ли они мешать друг другу, да и в целом важно еще оценить себестоимость в соответствии с решением боли, можно легко написать какой-нибудь python или иной скрипт/API эндпоинт который всю нужную инфу по узлу будет подтягивать куда нужно не влезая в эту махину
cgroups это официальный механизм иерархического распределения ресурсов - https://linux.googlesource.com/virt/kvm/kvm/+/9d4ac8b6302c60a1949560e501fc1d0b4654b9c6/Documentation/admin-guide/cgroup-v2.rst
Понятное дело, что cgroups можно использовать с более умными алгоритмами и более красиво, но, в рамках MVP, на мой взгляд реализация более чем допустима :)
P.S Да, в статье изначально надо было отписать, что речь про оверселлинг по процессору, мой недочет
Теперь попробуйте провести эксперимент с десятками ВМ:
Укажите всем ограничения через -smp по числу ядер и оперативной памяти, запустите на всех нагрузку, посмотрите как со временем ВМ начнут вести себя, и вы явно заметите что одни ВМ начнут забирать больше ресурсов чем другие при указанных ограничениях, это и называется проблема шумного соседа, ваш флаг
-smpна уровне qemu, а проблема на уровне ядра, оно указывает сколько vCPU и RAM забирать, но не указывает то, сколько процессорного времени забиратьВ моем коде по пути проекта: agent/client/pycgroup/ctl/cpu_ctl.py
Я перевожу ограничения по ядрам эквивалентно процессорному времени. Вы можете создать 2 ВМ которые берут по 6 ядер, хотя по факту у вас физически ядер 6, первая ВМ при нагрузке сможет спокойно забирать больше 90% процессорного времени, потому что вы честно указали - у тебя есть 6 ядер
P.S На крупных платформах сумма vCPU всех ВМ почти всегда в разы превышает количество физических ядер на хосте(Overcommit)
Да, полностью согласен. Фраза
со стороны бизнеса действительно звучит как недооценка рисков - буду аккуратнее в формулировках. И про одиночку тоже верно: сейчас я работаю над децентрализованной GPU-сетью, но уже с командой. Спасибо, что подметили - полезная обратная связь.
Прошу вас предоставить доказательную базу почему мои наработки это "поделки студента для образовательных целей", иначе ваш комментарий рискует превратиться в комментарии без ценности, ведь, я предполагаю, что вы подробно изучили проект перед тем как выдать свой вердикт, заранее благодарю.
P.S Проект - POC, и в статье я честно пишу, что он не взлетел по бизнес-причинам, основной функционал виртуализации на уровне агента полностью рабочий, что подтверждается автотестами: agent/client/tests/
Согласен. Это система где всем удобно, все походили на мероприятия, получили награды, подписали контракты и разошлись
Спасибо за отличный пример. Можно создать очень хороший продукт, но если не будет каналов доверия, даже самое передовое окажется никому не нужно
Был реализован базовый функционал который позволял использовать платформу полноценно, я не фокусировался на одном лишь распределении ресурсов, но это была фича которую я хорошо реализовал, она решала конкретную доказанную боль, решения которой я не увидел ни у одного крупного вендора. Миграции и отказоустойчивость это две стороны одной технологии, когда ВМ выходит из строя она автоматически мигрирует в соседнюю работающую ноду, поскольку конфиги и данные хранятся на удаленных хранилищах. Остальные и другие технологии добавить не является абсолютно никакой проблемой в большинстве своем, это вопрос запросов заказчика и потребностей рынка.
Да, абсолютно с вами согласен, я писал также множеству интеграторов с предложением о сотрудничестве. Но так или иначе отклика не последовало, зато опыт)
DRA штука интересная, вопрос только в себестоимости перехода, пет проектом и подобным это и не нужно, а вот чтобы кластер перевести да и так чтобы ничего не сломать, у многих еще и множество иных расширений, не будут ли они мешать друг другу, да и в целом важно еще оценить себестоимость в соответствии с решением боли, можно легко написать какой-нибудь python или иной скрипт/API эндпоинт который всю нужную инфу по узлу будет подтягивать куда нужно не влезая в эту махину
@Myskat_90 Как вы на это смотрите ?