Виртуализация в России — тема горячая. VMware ушёл, Hyper‑V под вопросом, Proxmox — открытый, но не «суверенный». Я задался вопросом: а можно ли написать платформу управления KVM с нуля, с полным контролем ресурсов через cgroups v2, без единой строки GPL‑кода?
Спойлер: да. Встречайте Eskvisor — мой проект, переросший в зарегистрированную в Роспатенте программу для ЭВМ. Под капотом — архитектура, грабли с cgroups, и почему полностью суверенный проект был мертворожденным.
Темы
-
Почему возникла идея, как велась разработка и что там с импортозамещением
-
Как я нативно внедрил cgroups v2 для полного контроля ресурсов системы с гарантией
-
Почему проект оказался мертворожденным
Почему возникла идея , как велась разработка и что там с импортозамещением
В надежде среди мыслительных процессов найти ту самую идею стартапа, которая «выстрелит», я пришел к мысли: в РФ сейчас тренд на отечественные разработки. Учитывая также мой опыт в работе в компании в РФ, которая специализируется на продуктах, связанных с виртуализацией, я понял — надо делать, это можно будет продать.
Но к разработке я приступил не сразу, перед разработкой тщательно изучил рынок. Полностью отечественных проектов в принципе нет, а если они есть — то имеют тяжелое легаси, которое само по себе дороже поддерживать. Большинство проектов(не будем называть имён) чаще всего основываются на OpenSource решениях, а те, в свою очередь, основываются на libvirt. И выходит так, что коммерческая компания со своим штатом программистов, вместо того, чтобы предложить действительно суверенный софт — берет OpenSource, немного его шлифует, клеит свою наклейку и продает как «отечественное решение», где из отечественного лишь верхнеуровневая доработка, но чаще всего — без своей глубокой реализации. Так и клепают год за годом «убийц VMware». Мой проект также был основан на libvirt, но я сознательно отказался от копирования чужих решений. ИИ — только для ускорения кодогенерации, не более.
Проект был полностью написан мной с нуля, на протяжении 45+ дней непрерывного кодинга (а до этого — анализа рынка и конкурентов) с выполнением своего минимального функционала, включая фишку контроля ресурсов через cgroup v2.
Возникает риторический вопрос: если я один смог накинуть ядро кода, лишь немного капнув в этом направлении, включая нативный контроль ресурсов через cgroup v2, чем занимаются целые штаты программистов у крупных вендоров?
Ведь одно дело — разработка по-настоящему сложной и зрелой системы, например, живой миграции ВМ между хостами (это нетривиальная задача, требующая огромных ресурсов; я, кстати, тоже смог её в минимальном функционале реализовать, но поддерживать такую махину в одиночку, особенно на старте и для крупных вендоров, было бы архи-сложно, поэтому я выпилил большую часть кода).
И совсем другое — взять готовое OpenSource-решение, слегка его зашлифовать и наклеить свой логотип.
Неужели продукту, который на 90% состоит из OpenSource-компонентов (и чьи критические баги за вас исправляет всё мировое сообщество), нужен целый штат программистов, чтобы делать из него «импортозамещение»?
Абсурд ситуации усиливает один неподтверждённый, но показательный кейс (источник, увы, не могу раскрыть): некая российская компания с крупным контрактом на виртуализацию проводила миграции ВМ с помощью OpenSource‑решения без своих доработок на коммерческих платформах заказчика.
А теперь внимательно следим за контекстом:
——————————————————————————————————————————
Ситуация получилась такой, что заказчик заплатил за «отечественную разработку», функционала которой оказалось недостаточно, в итоге сверху этого команде пришлось использовать другое OpenSource решение для решения проблемы.
——————————————————————————————————————————
Тендер на поставку ПО выиграла не та компания, у которой оказалось более качественное ПО, а та которой нужно было выиграть. Вся «суверенность» свелась к красивой презентации и закрытым глазам на происхождение кода.
Верить или нет — решать вам.
Как я внедрял нативное использование cgroup v2 для полного контроля ресурсов системы с гарантией
Ключевая проблема большинства платформ виртуализации — номинальное ограничение ресурсов. Control plane отправляет запрос на 2 vCPU и 4 ГБ RAM, но когда ВМ начинает активно нагружаться, шедулер Linux отдаёт ей всё свободное время. В результате дашборд показывает честные 70% (потому что именно столько мы записали в БД), а по факту система потребляет 80%, 90% или вообще всё, что есть.
Я пробовал решить проблему хранением метрик в JSON — написал систему для трекинга и будущих интеграций. Эффективность оказалась нулевой: мы лишь фиксировали проблему, но не решали её.
Единственное работающее решение — cgroups v2. Эта технология ограничивает ресурсы на уровне ядра Linux. Бесполезно пытаться через libvirt увеличить доступные мощности — cgroup просто не отдаст лишнее, даже если создать новую ВМ с большим количеством ресурсов(например 4 vCPU) но закинуть ее в limit на 2 ядра — ВМ не сможет использовать больше 2 ядер
В моей реализации при создании ВМ мы:
-
Вычисляем PID процесса QEMU/KVM (по имени из конфигов libvirt)
-
Добавляем этот PID в заранее созданный пул ресурсов
-
Пул уже имеет жёсткие лимиты CPU и RAM на уровне cgroups
Теперь ВМ физически не может выйти за рамки. Дашборд показывает реальное положение, а не то, что «должно быть».
Модуль управления cgroups v2 в Eskvisor
Ядро ресурсного контроля платформы — модуль pycgroup, реализующий прямое взаимодействие с иерархией cgroups v2. Модуль построен по принципу трёхуровневой абстракции: контроллеры (CPUController, MemoryController, PidController) → фасад PYCGroup → бизнес‑логика агента.
CPUController управляет лимитами через cpu.max и cpu.weight, поддерживая установку ограничений в процентах или ядрах. Ключевая особенность — метод get_cpu_available_cores, вычисляющий остаточный ресурс пула для планирования новых ВМ.
MemoryController оперирует контроллерами memory.max, memory.high и memory.min для жёстких, мягких и гарантированных лимитов памяти.
Иерархическая модель разделяет пулы (группы ВМ) и контейнеры (отдельные ВМ). Дочерняя cgroup не может превышать лимиты родительской — это обеспечивает предсказуемое распределение ресурсов.
Для сохранения состояния разработаны bash‑скрипты save.sh/restore.sh с интеграцией в systemd (таймер на каждые 6 часов). Скрипт migrate.sh через rsync переносит конфигурации между хостами, сохраняя все настройки cgroup.
Модуль полностью автономен, не требует перезагрузки и работает поверх стандартного KVM/libvirt без модификации ядра. Более подробно изучить модель и в целом проект можно в репозитории GitHub.
Почему проект оказался мертворожденным
Все до безобразия просто, рынок поделен между крупными игроками, даже имея хорошо написанный код и полностью с нуля разработанную архитектуру — это не дает никакой гарантии на то, что проект будет интересен хоть кому‑то. Параллельно с разработкой я рассылал множество писем различным компаниям, интеграторам, включая гос заказы(более 80 писем, звонки и прочее), где я писал всем с одним предложением — все подключим и сделаем абсолютно бесплатно, нам нужна будет лишь обратная связь, а при заинтересованности в коммерческом контракте — постараемся получить и лицензию Минцифры, включение в реестр отечественного ПО и так далее. Модель была максимально простой — если понравится, возьмите, если не понравится — нам ничего не нужно.
Всем спасибо, кто дочитал до этого места. Если вы из компании, которой надоели «отечественные обёртки над OpenSource», или просто хотите посмотреть на честный код — репозиторий открыт. Мне же — собирать карму и доделывать Atomic AI Cloud. Увидимся там
ссылка на оригинал статьи https://habr.com/ru/articles/1046175/