Для лиги лени: что-то на душном
Пока все ели, на vm-guru вышло две части статьи:
Российские решения виртуализации и VDI: итоги 2025 года - часть 1
Российские решения виртуализации и VDI: итоги 2025 года - часть 2
ссылок нет, чтобы не возникло идей «пришли и рекламируют». Кому надо – нагуглит.
Читать эти две части есть смысл только тем, кто озабочен «импортозамещением», хотя это странное импортозамещение – замена американских ОС на американскую ОС. Учитывая что Microsoft это один из трех крупнейших разработчиков экосистемы Linux, то выглядит как Москвич 3. Тоже импортозамещенный.
Сами статьи очень, очень обзорные. Ни тестирования не проведено, ни опыта эксплуатации. Все продукты все очень хорошие, свежие, сочные, и отлично мажутся.
В самих статьях есть ряд очень некорректных фраз. В частности:
По данным исследования компании «Код Безопасности», уже 78% российских организаций выбирают отечественные средства виртуализации.
Ничего российского в KVM, XEN и bhyve нет вообще. Средства управления – на сколько-то российские, само ядро виртуализации – opensource, читай «разработано в основном в США» или, для средств управления, то есть форков Proxmox - Proxmox Server Solutions GmbH расположен по адресу: Bräuhausgasse 37, Vienna, Austria.
Open Source Contributor Index : Rank and Organization
1 – Google, 6590 Active contributors
2 – Microsoft, 5364 Active contributors (без GitHub)
3 - Red Hat, 3908 Active contributors (без IBM)
4 – Amazon, 2465 Active contributors
5 – Intel, 2364 Active contributors
Есть и решения на базе OpenStack
OpenStack – это не гипервизор, а система управления гипервизорами, то есть она может управлять хоть Broadcom vCenter, хоть чем. Можно же было, перед тем как такое писать, посмотреть картинки в документации.
Здесь можно отметить, что многие российские платформы уже внедрили современные технологии оптимизации ресурсов: поддержка NUMA для эффективной работы с многопроцессорными узлами
С этого момента уже можно сказать, что «в статье все очень плохо».
Первое.
Non-uniform memory access (NUMA) в мире x86 существует больше 20 лет. В Linux kernel поддержку NUMA начали реализовывать с 2002. Что могли внедрить российские платформы из того, что используется в kernel уже больше 20 лет?
Второе.
Если начать читать про проблемы переключения задач в среде x86 с более понятной статьи
Virtual Machine Resource Controls,
продолжить чтение на сайте Red Hat
Red Hat 6. CPU Scheduling
Red Hat 10. Chapter 27. Tuning scheduling policy
То окажется, что у Linux достаточно большие проблемы с планировщиком задач, которые NUMA только усугубляет. Как, впрочем, и с Intel Hyper-Threading Technology, и с Intel Turbo Boost и AMD Precision Boost и вся эта группа настроек энергосбережения.
У всех эти проблемы, особенно в связи с последними движениями AMD и их микроархитектурой.
Linux kernel из коробок (Debian, Ubuntu, Centso, etc), скомпилированный из принципа «чтобы работало почти везде», вообще не очень оптимизирован по скорости, достаточно посмотреть результаты тестирования настроек в проекте Clear Linux
Final Benchmarks Of Clear Linux On Intel: ~48% Faster Than Ubuntu Out-Of-The-Box
Есть определенная ирония в том, что над ускорением Linux работали не какие-то энтузиасты из Apache Software Foundation, а самый проприетарнейший Intel.
Который и закрыл проект в июле 2025 - Intel Announces It's Shutting Down Clear Linux.
И еще больше иронии в том, что спустя два года «оптимизаций» Linux, с декабря 2023 по 1 января 2026, он стал работать медленнее на том же процессоре Intel, достаточно почитать свежую статью Two years after launch Intel Meteor Lake offers 93% of original performance on Linux, tests show.
Так что, и поддержкой NUMA занимаются не разработчики GUI поверх KVM, и с CPU планировщиками проблемы были и есть, и за два года с производительностью все как-то не так.
Проявляется это «не то, чтобы торможение» при хоть как-то нагруженном сервере. Немалая часть обычных пользователей с этим, скорее всего, не столкнется, или спишет проблемы на что угодно, кроме кривеньких настроек kernel «из коробки», и такой же кривенькой настройки планировщика «из коробки».
В некоторых нагруженных сценариях, вне зависимости от того, используется ли KVM, или используется контейнеризация, любая, и система управления контейнерами, NUMA вообще стоит выключить.
Иногда стоит выключить и HT.
И посмотреть на результаты.
Но, повторю, тут много зависит от того, устраивает ли вас ситуация с нагрузкой, снимаете ли вы вообще метрики нагрузок по процессорным ядрам, проводите ли анализ нагрузок (что считается) и загрузки (как эффективно балансируется). Это не так просто, потому что метрики KAVG (Kernel average latency) и GAVG (Guest average latency) в Linux отсутствуют, а без них не всегда понятно, где задержка – на вводе-выводе, или все же надо смотреть в CPU Wait (CPU Ready Time).
Load Average в Linux при этом показывает совсем не то, что рассказывают школьники друг другу, но про это хотя бы пишут, например в статье Linux System Load Average Spikes IO Wait Context Switching and Process Bottlenecks.
Как следствие, получается, что по реальной эффективности работы гипервизора в нагруженной среде платный Microsoft Hyper-V на Intel может оказаться дешевле, чем бесплатный KVM или бесплатный k8s.
И не только потому, что не везде есть множество высококвалифицированных низкооплачиваемых кадров.
Но уж точно, никакого супер-действия нет от «NUMA».
SpaceVM изначально ориентирован на сценарии с графическими рабочими станциями: платформа поддерживает как passthrough GPU для выделения целой видеокарты ВМ, так и технологию FreeGRID – собственную разработку для виртуализации ресурсов NVIDIA-GPU без риска лицензионной блокировки.
Кажется, КОАП не отменяли ?
Резюмируя, производительность российских гипервизоров уже находится на уровне, достаточном для многих корпоративных задач
За исключением того, что KVM, bhyve, и так далее, не являются российскими гипервизорами.
внедрение RBAC/2FA, о которых сказано выше, существенно снижает риски
Role-Based Access Control (RBAC) не имеет ни малейшего отношения к 2FA. Что там оно снижает – надо спросить у Аэрофлота и прочих взломанных, начиная от МТС и СДЭК.
Также важно строить резервное копирование на уровне приложений и данных, а не полагаться только на механизмы платформы.
Авторы принципиально не понимают что пишут, или не смогли написать прямо – в Linux не было и нет механизмов резервного копирования приложений, что из физических, что из виртуальных сред, из-за отсутствия механизма, аналогичного Microsoft Volume Shadow Copy Service (VSS). Функции файловой системы и ядра (freeze_bdev и thaw_bdev) есть, функционала приложений нет. Поэтому «механизмов платформы» нет принципиально, если только вы, конечно, не останавливаете сервис приложения целиком на время снятия снапшота файловой системы.
Паузы недостаточно, да и попробуйте поставить на паузу действительно нагруженную базу данных, потом расскажете, как прошло восстановление и сколько воспроизводились транзакции.
Одно дело снять ночью снапшот postgres в 1с, в которой было 1000 проводок за 8 рабочих часов, другое дело снять снапшот базы биллинга.
Жаль, конечно, что две такие, вроде бы большие, статьи, да еще и с картинками, сводятся к рассказу «Продукт точно хороший, берите, не пожалеете».
В рассказах про Open source Linux вот-вот победит и Microsoft и IBM и всех. Кроме Google. Потому что проприетарный Android это другое, это не проприетарный Microsoft.
В рассказах про импортозамещение есть красивые картинки и даже таблицы.
В реальности прибыль Microsoft, в том числе за счет сдачи в аренду времени под работу Linux серверов и прочего Opensource в облаке (Azure), в том числе Azure Kubernetes Service (AKS) и Azure Container Apps растет каждый год.
В Linux других проблем нет, кроме тех, что надо убрать из ядра поддержку Bcachefs. Не потому, что Bcachefs плохая, а потому, что разработчик Kent Overstreet два года назад кого-то в частной переписке назвал дурачком, и недостаточно хорошо и долго извинялся.
Надеюсь, в следующей статье авторы расскажут, почему Usergate лучше NSX и Microsoft Network Controller вместе взятых, а drbd лучше vSAN и S2D (Storage Spaces Direct), и как хорошо drbd работает с NVMEoF.
И почему для «импортозамещения» надо удвоить, если не утроить, парк техники, и почему рост капитальных и эксплуатационных затрат в 2.5 раза – только на пользу бюджетам.
