Comments 22
Почему проект оказался мертворожденным
Потому что Вы фокусируетесь только на распределении ресурсов, игнорируя остальные 95-99% продукта. Во всяком случае, я так вижу после прочтения статьи и README.md репозитория.
Система виртуализации - это сотни технологий и, в случае с зарубежными топовыми вендорами, десятки лет поедания колючек для получения уникального решения.
Миграции, бэкапы, отказоустойчивость, таски, внешние интеграции, не говорю уж просто про хранилки и сети - где это всё? С точки зрения заказчика, лучше open-source, чем ничего.
Вендоров псевдоимпортозамещения я не оправдываю. Это всё понятно, бюджеты сами себя не освоят. Я говорю именно про то, что прочитал здесь
Был реализован базовый функционал который позволял использовать платформу полноценно, я не фокусировался на одном лишь распределении ресурсов, но это была фича которую я хорошо реализовал, она решала конкретную доказанную боль, решения которой я не увидел ни у одного крупного вендора. Миграции и отказоустойчивость это две стороны одной технологии, когда ВМ выходит из строя она автоматически мигрирует в соседнюю работающую ноду, поскольку конфиги и данные хранятся на удаленных хранилищах. Остальные и другие технологии добавить не является абсолютно никакой проблемой в большинстве своем, это вопрос запросов заказчика и потребностей рынка.
Как технарь, я Вас и Ваше начинание безусловно поддерживаю. Вы проделали отличную работу, которую даже при отсутствии заказчиков можно применить в домашней ферме и получить удовлетворение от работы.
Остальные и другие технологии добавить не является абсолютно никакой проблемой
А вот если бы я был на стороне заказчика, разговор бы закончился на этом моменте :) Любая работа занимает больше времени, чем планировалось. И когда один человек - незнакомый, пусть даже талантливый - заявляет о том что он готов заместить собой наработки целого сообщества, это звучит как огромный риск потратить деньги и энергию впустую. Потратить на, уж простите, очередного гения с самомнением. Это я не от своего лица говорю, так воспринимают на другом конце провода.
С Вашими наработками нужно идти не в бизнес, а в инвесторов и в акселераторы. И то, когда появится один-два единомышленника, потому что Ваш замах - это не мобильное приложение в одиночку делать.
Да, полностью согласен. Фраза
Остальные и другие технологии добавить не является абсолютно никакой проблемой
со стороны бизнеса действительно звучит как недооценка рисков - буду аккуратнее в формулировках. И про одиночку тоже верно: сейчас я работаю над децентрализованной GPU-сетью, но уже с командой. Спасибо, что подметили - полезная обратная связь.
OpenSource под видом импортозамещения удобен всем сторонам, потому и существует: инженеры получают опыт, который смогут вписать в резюме, ну а "кто-то" получает деньги. Именно поэтому же и "свое, новое уникальное" решение ровно также никому и не нужно.
а, не торопитесь. просто продолжайте, такое часто вот бывает, кажется, что все не так. дорогу осилит идущий. идея норм, хоть пилить еще много по обвязке чего нужно.
Ни одна нормальная компания не будет связываться с непонятным челом или конторой Рога и Копыта, где работает один чел.
А как это потом им поддерживать, если вдруг вы пропадёт?
Тут вопрос в экономике. Вам надо с большой компанией договариваться, например продать или просто отдать долю им и они будут толкать ваше решение.
Когда есть альтернативы, всегда выберут большую контору.
когда один профессор математики американского университета решил сделать файловую систему (которая здравствует до сих пор) опытные люди дали ему в помощь одну оооочень большую корпорацию, для "партнерства". потому что было понятно, что ни один серьезный заказчик не будет работать даже с самым умным профессором, если он один. продукт - это не только хорошая идея. и даже хорошей реализации совершенно недосточно чтобы этот продукт стали покупать.
Ваши наработки это максимум поделки студента для образовательных целей. Поздравляю вас, вы открыли для себя пару системных вызовов и осознали что заменить их из юзер спейса то еще велосипедостроение. Сама статья очень худая, даже то что есть можно было бы поддержать ну хоть минимум одним примером реального использования. О какой конкуренции с опен сорс решениями вообще можно говорить я даже не представляю…
Прошу вас предоставить доказательную базу почему мои наработки это "поделки студента для образовательных целей", иначе ваш комментарий рискует превратиться в комментарии без ценности, ведь, я предполагаю, что вы подробно изучили проект перед тем как выдать свой вердикт, заранее благодарю.
P.S Проект - POC, и в статье я честно пишу, что он не взлетел по бизнес-причинам, основной функционал виртуализации на уровне агента полностью рабочий, что подтверждается автотестами: agent/client/tests/
У нас, видимо, открылся сезон антипиара открытых облачных платформ (особенно, суверенных), как идеи, и в принципе.
Видимо, с приходом ИИ стоимость эксплуатации и настройки всего этого добра на столько сократилась, что "проприетарные" вендоры секут это на корню, как идею, и, еще и приплачивают за это))))
Видимо, подгорает...
Control plane отправляет запрос на 2 vCPU и 4 ГБ RAM, но когда ВМ начинает активно нагружаться, шедулер Linux отдаёт ей всё свободное время.
Как вы сумели такого добиться? Вот тупо взял qemu без libvirt, указал нужное количество памяти через -m и число ядер через -smp, нагрузил числом активных процессов раза в два побольше ядер, чем выдал — жрёт столько, сколько указано ядре, а не сколько процессов.
Теперь попробуйте провести эксперимент с десятками ВМ:
Укажите всем ограничения через -smp по числу ядер и оперативной памяти, запустите на всех нагрузку, посмотрите как со временем ВМ начнут вести себя, и вы явно заметите что одни ВМ начнут забирать больше ресурсов чем другие при указанных ограничениях, это и называется проблема шумного соседа, ваш флаг -smp на уровне qemu, а проблема на уровне ядра, оно указывает сколько vCPU и RAM забирать, но не указывает то, сколько процессорного времени забирать
В моем коде по пути проекта: agent/client/pycgroup/ctl/cpu_ctl.py
Я перевожу ограничения по ядрам эквивалентно процессорному времени. Вы можете создать 2 ВМ которые берут по 6 ядер, хотя по факту у вас физически ядер 6, первая ВМ при нагрузке сможет спокойно забирать больше 90% процессорного времени, потому что вы честно указали - у тебя есть 6 ядер
P.S На крупных платформах сумма vCPU всех ВМ почти всегда в разы превышает количество физических ядер на хосте(Overcommit)
Из текста далеко не ясно, что речь про оверселлинг по процессору. Лично я понял это как "отдаём внутрь вм все ядра, ограничиваем только снаружи, потому что по-другому не умеем" и никак иначе.
Ну и, кстати, борьба с легитимной нагрузкой на вм путём уменьшения реально отданного процессорного времени с точки зрения клиента выглядит странно (из заметного, кроме уменьшения быстродействия от ожидаемого — рост steal). Проходили лет 10-15 назад...
cgroups это официальный механизм иерархического распределения ресурсов - https://linux.googlesource.com/virt/kvm/kvm/+/9d4ac8b6302c60a1949560e501fc1d0b4654b9c6/Documentation/admin-guide/cgroup-v2.rst
Понятное дело, что cgroups можно использовать с более умными алгоритмами и более красиво, но, в рамках MVP, на мой взгляд реализация более чем допустима :)
P.S Да, в статье изначально надо было отписать, что речь про оверселлинг по процессору, мой недочет
Таки я в курсе про cgroups, им и делали в своё время.
Тут, скорее, надо более-менее автоматически понижать приоритет жрущих и возвращать обратно, когда перестают, а не тупо ограничивать проц. Ибо если никто на процессор не претендует — пусть кушают, сколько получится. Ну это если нет возможности организационно разделить редких крупных потребителей, которым можно отдать ядра без соседей и мелочь, где и десяток виртуальных ядер на одно реальное норма.
Опыт разработки российской платформы виртуализации с нуля: libvirt, cgroups v2 и почему это никому не нужно