Эта статья ломает стереотипы, честно и аргументированно объясняя инженерный прагматизм: почему ядро KVM трогать бессмысленно, но где именно проходит граница между «взяли готовое» и «написали свой Enterprise».
Когда отечественные ИТ-директора и системные архитекторы выбирают платформу для миграции с VMware vSphere или Microsoft Hyper-V, один из первых вопросов, который они задают разработчикам: «А что у вас под капотом? Очередной open-source, в котором просто перерисовали логотипы, или вы всё написали сами?»
В ответ вендоры часто уходят в крайности. Одни бьют себя в грудь, заявляя об «уникальном отечественном ядре, написанном с чистого листа», другие скромно умалчивают детали.
Давайте снимем маски и поговорим на чистоту. Мы открыто говорим: базой нашей платформы является патченный QEMU/KVM. И это не компромисс, а единственно верное, прагматичное инженерное решение. Рассказываем, почему разработка ядра виртуализации с нуля сегодня — это экономическая утопия, и где на самом деле должна проходить граница между open-source базой и коммерческим проприетарным кодом.
Математика разработки: цена велосипеда
Перед тем как заложить архитектуру нашей платформы виртуализации, мы провели детальные расчеты. Сколько стоит написать полноценное, стабильное и безопасное ядро гипервизора, способное работать на любом коммерческом «железе» корпоративного класса?
По самым консервативным оценкам, инвестиции в создание такого ядра с нуля сегодня составляют не менее 1,5 миллиардов рублей, а цикл разработки и стабилизации занял бы от 5 до 7 лет жесткого прессинга команды топ-уровня.
Но главная проблема даже не в деньгах. Написать код — это 20% задачи. Остальные 80% — это поддержка бесконечного парка серверного оборудования, сетевых карт, процессоров (Intel, AMD, отечественные архитектуры) и систем хранения данных от сотен мировых производителей. Open-source сообщество и мировые ИТ-гиганты полировали ядро KVM десятилетиями, оперативно закрывая уязвимости и добавляя поддержку новых инструкций CPU.
Пытаться в одиночку воспроизвести этот стек в рамках одной компании — инженерное безумие, за которое в конечном итоге заплатил бы заказчик. Ни один бизнес или государственный сектор не готов ждать 5 лет и платить миллиарды ради сомнительного удовольствия тестировать сырое, «абсолютно свое» ядро на своей «живой» инфраструктуре.
Хирургия KVM: что мы «отрезали» и оставили
Наш подход — это жесткий прагматизм. Мы взяли за основу проверенное временем ядро KVM/QEMU, но подвергли его глубокой технологической хирургии.
Мы полностью удалили из него все лишние модули, подсистемы и legacy-код, который десятилетиями копился в open-source и не имеет отношения к enterprise-виртуализации. Оставлено только «чистое» монолитное ядро, отвечающее за базовые низкоуровневые операции: работу с инструкциями процессора и виртуализацию памяти.
Само ядро было серьезно пропатчено под требования безопасности и производительности. Но всё, что находится выше этого фундамента — уровень управления, логика и оркестрация — не имеет к стандартному open-source никакого отношения.
Где начинается Enterprise: что написано с нуля?
Разница между «сборкой из репозитория» и коммерческим продуктом заключается в уровне управления (Control Plane). В стандартном Linux-окружении управление виртуализацией — это разрозненный набор утилит и скриптов. Для промышленной эксплуатации в масштабах крупного предприятия или ЦОД это неприменимо.
Мы полностью, с первого символа в коде, написали собственные проприетарные модули для управления критически важными функциями платформы:
1. Control Level (Центральный сервер управления): Архитектура управления написана с нуля. Она работает в распределенном или геораспределенном режиме. В отличие от стандартных решений, мы отказались от классических реляционных баз данных (SQL-like) в пользу Event Storing архитектуры. Это позволяет мгновенно синхронизировать состояние хостов и применять фичи, недоступные в базовом KVM.
2. Собственная служба High Availability (HA): За отказоустойчивость кластера отвечает наш собственный «серый кардинал» — служба High Availability Cluster Controller. Этот сервис живет на уровне гипервизора и управляет запуском и миграцией виртуальных машин даже в случае полной изоляции хостов (Split-Brain) или падения центрального сервера управления.
3. Управление устройствами и проброс (Passthrough): Механизмы подключения, изоляции, автообнаружения LUN в iSCSI и Fibre Channel, а также интеллектуальный проброс USB-контроллеров и vGPU были спроектированы нашей командой с нуля. Это позволяет платформе запускаться и стабильно администрироваться на любом физическом железе, обеспечивая независимость кодовой базы.
Итог: честный подход к импортозамещению
Создание коммерческого ИТ-продукта сегодня — это умение правильно распределять ресурсы. Потратить 1,5 миллиарда рублей на то, чтобы переписать ядро KVM и получить на выходе продукт с сомнительной стабильностью — тупиковый путь.
Мы направили эти ресурсы на создание надежного, безопасного и функционального уровня управления (Control Plane), автоматизацию рутины администраторов и обеспечение катастрофоустойчивости. Заказчик получает предсказуемое, производительное решение корпоративного класса, которое опирается на мировой стандарт низкоуровневой виртуализации, но полностью контролируется отечественной кодовой базой на уровне бизнес-логики и оркестрации. Это и есть настоящий, зрелый Enterprise.
Далее предлагаем вашему вниманию статью Виртуализация «для зумеров»: как интерфейсная верификация спасает инфраструктуру от человеческого фактора https://dzen.ru/a/aiZXv6HaDiuGjCU6