Импортозамещение виртуализации в 2026: где ломается «совместимое» железо
Фраза «сервер есть в матрице совместимости, для нашей схемы подойдёт» — одна из самых дорогостоящих в ИТ-проектах 2024–2026 годов. Её произносят между закупкой и запуском, а потом выясняется, что компоненты несовместимы и не работают вместе.
В реестре российского ПО несколько десятков решений по виртуализации, но реально жизнеспособных для промышленной эксплуатации — заметно меньше. Попытка протестировать всё и выбрать лучшее превращает каждый пилот в исследовательский проект.
В статье — о том, где именно ломается стек сервер + прошивка + сеть + СХД + платформа виртуализации, и что с этим делать.
Почему матрица совместимости не даёт гарантий
Гарантии вендора означают одно: можно начинать пилот. Не больше.
Даже на зрелом западном стеке Broadcom указывает: апгрейд ESXi может упереться в версию BIOS, прошивку HBA-адаптера или конкретную связку NIC firmware и driver. Совместимость на версии n−1 не гарантирует нормальный переход на версию n. Вендор сервера сам проводит тестирование BIOS, драйверов и firmware, а значит, совместимость живёт на уровне конкретной комбинации компонентов и версий.
У российских платформ картина такая же — просто рынок моложе. SpaceVM фиксирует список совместимостей на момент релиза, и он может включать результаты как для актуальных, так и для предыдущих версий продукта. У zVirt матрица совместимости — многомерная таблица: отдельно учитываются ОС, Ethernet-адаптеры, HBA, GPU и другие компоненты.
Добавим аппаратную вариативность. Один и тот же артикул сервера — например, Aquarius AQserv T50 D110CF или OpenYard RS202I — существует в разных исполнениях с разными версиями прошивок BMC, BIOS, наборами сетевых карт и FC-адаптеров. Когда в закупке пишут «совместимый сервер такой-то модели», это не один конкретный объект, а класс конфигураций, внутри которого могут различаться критичные для виртуализации компоненты.
Чтобы фраза «железо совместимо» что-то значила, рядом должны лежать: точный BOM, ревизии плат и адаптеров, версии BIOS/BMC, версии firmware контроллеров, версия платформы виртуализации, схема подключения к СХД, сетевой профиль, сценарий отказов и порядок обновления. Без этого всё может сломаться в любой момент.
Где именно может ломаться стек
Слой 1. Аппаратная база и контур управления
Сервер загружается, но периодически перезапускается удалённая консоль. BMC живёт своей жизнью. Часть устройств определяется нестабильно. Сетевые адаптеры или диски то видно, то нет без очевидной логики. До виртуализации ещё не дошли, а проект уже буксует.
Слой 2. Связка firmware и driver
Всё вроде работает: линк поднимается, часть трафика ходит. Но отдельные VLAN, отдельные пути до СХД или отдельные типы трафика ведут себя не корректно. Broadcom публично разбирал именно такую ситуацию: после обновления firmware адаптера виртуальные машины потеряли сетевую связность — проблема оказалась в несоответствии версии драйвера новой прошивке.
Слой 3. Топология SAN и FC
Пока кластер маленький, хочется упростить схему: подключить СХД напрямую, не ставить FC-коммутаторы на первом этапе, оставить масштабирование на потом. Это может работать до первого расширения. Кроме того, может оказаться, что в топологии point-to-point все работало, а переключение на fc-al потребует дополнительных исследований, настроек и прошивок.
Документация SpaceVM однозначна: для GFS2-кластера нужны дублирование коммутаторов, Active-Backup для внутренних сетей, Multipath для сети СХД. Отсутствие дублирования делает коммутатор единой точкой отказа, а его обслуживание потребует полного отключения связи между кластером и СХД.
Слой 4. Кластерный транспорт и кворум-механика
На ряде отечественных платформ под капотом — связка corosync, DLM, SBD, NTP, watchdog и кластерная файловая система. Отсутствие кворума блокирует обмен данными. Fencing может происходить через watchdog, и в журналах BMC при этом видно срабатывание WDT. GFS2, кстати, не предполагает использование HDD для разделяемого хранилища. Симптом часто оказывается следствием сетевой нестабильности или неверно спроектированной схемы хранения.
Слой 5. Эксплуатационные изменения
Небольшой кластер, который однажды настроили и почти не трогают, может жить спокойно. Промышленный кластер, где регулярно добавляют сети, диски, пулы, новые хосты и сценарии миграции, постоянно оказывается в непредсказуемых состояниях. В 2026 году это особенно заметно на проектах по импортозамещению — продукты плохие проходят ту стадию инженерного взросления, которую старые западные стеки проходили гораздо дольше.
Слой 6. Границы ответственности
Вендор железа говорит: «это вопрос гипервизора». Вендор виртуализации отвечает: «проверьте сеть и СХД». Сетевики уверены, что у них всё в порядке. Интегратор, если проект построен плохо, остаётся между всеми одновременно. Здесь становится понятно, почему понятное SLA и сервисную модель нужно обсуждать особенно внимательно.
Четыре ситуации из практики
1. Миф о едином стеке от одного производителя
Заказчик сознательно выбрал серверы и СХД одного вендора — «так будет проще с поддержкой и совместимостью». На практике серверы не увидели СХД так, как должны были. Месяцы переписки с техподдержкой, попытки собрать реплику стенда у вендора — и месяцы работы. В итоге пришлось закупать другое, совместимое оборудование.
2. Кластерный транспорт и внезапные ребуты
Всё выглядело нормально до тех пор, пока не начали собирать кластерный транспорт. После этого узлы уходили в непредсказуемые перезагрузки. Недели перепроверяли сети, VLAN, схему подключения. Решение нашлось в timeout аппаратного watchdog. Проблема была на стыке транспорта, quorum-логики и watchdog-механики — именно то, о чём предупреждает документация SpaceVM по GFS2.
3. Ложное ощущение завершённой миграции
Платформа внедрена, миграция пройдена, всё спокойно. А потом всплывает инцидент в хранилище: странное поведение диска, риск потери данных при неверном действии оператора. Выяснилось, что проблема в совместимости диска — пришлось покупать новый.
4. Сервисная модель против самостоятельной закупки
Когда мы сами подбираем стек под бизнес-задачи, существующие процессы и отвечаем за сопровождение, риск ниже: оборудование подобрано под платформу, слабые места известны. Когда заказчик самостоятельно закупает большую партию серверов и лицензий, а интегратора зовёт уже на проектирование и ПНР, как было, например, здесь, возникает другая экономика риска. Компания закупила лицензии, которые не подходили под ИТ-инфраструктуру, в итоге пришлось закупать и настраивать другие.
О том, как глобальное импортозамещение всей ИТ-инфраструктуры упёрлось в неправильный выбор системы резервного копирования — рассказывали здесь. Недавнюю историю про FC-подключение СХД напрямую к хостам без FC-коммутаторов — здесь.
Что из этого следует
1. Виртуализацию нельзя покупать как категорию «ПО плюс серверы». Её нужно покупать как целостный эксплуатационный стек. Формула совместимости выглядит так: модель сервера × точная конфигурация × версии BIOS/BMC × firmware контроллеров и NIC × драйверы × схема хранения × схема сети × точная версия платформы виртуализации × профиль дальнейших изменений. Всё выброшенное из этой формулы ради упрощения почти гарантированно вернётся в виде инцидента.
2. Выбирать железо без сценария эксплуатации — ошибка. Не «запустится ли гипервизор», а: как это будет обновляться, как переживёт отказ одного свитча, как поведёт себя кластерный транспорт при потере пути до СХД, кто увидит срабатывание fencing и кто несёт за это ответственность. Правильная логика: сначала точный пилот на точном BOM — потом закупка партии. Не наоборот.
3. Экономия на коммутации и резерве — это перенос платежа в будущее с процентами. Односвитчевая или временная схема может быть рабочей на старте, но она же потом становится точкой отказа и блокирует расширение. Архитектурный долг в виртуализации оплачивается в самый неудобный момент — когда кластер загружен под завязку, а бизнес требует «ничего не выключать».
4. Сервисная модель снижает CAPEX и неопределённость. В сервисной схеме подрядчик берёт на себя мониторинг, инциденты, обновление и масштабирование. Риск сосредоточен в понятной зоне ответственности, а не размазан по четырём подрядчикам и внутренней команде заказчика. В импортозамещении это часто важнее, чем выигрыш в цене железа на тендере.
5. Маленький «замороженный» кластер — не доказательство зрелости платформы. Настоящая проверка начинается с расширением, новыми сервисами, апдейтами, заменой железа и регулярной эксплуатационной рутиной. В разговоре с бизнесом стоит отказаться от формулировки «совместимо / несовместимо». Правильнее: «этот стек протестирован в таком-то составе, на таких-то версиях, для таких-то сценариев, и вот где его границы».
Если вы хотите доверить импортозамещение нам и не переплачивать деньгами за замену оборудования и временем за тестирование – заполните короткую форму. Мы свяжемся с вами и обсудим проект под ваши задачи и бюджет.
В следующем материале расскажем, что именно проверять до закупки, какие вопросы задавать вендору, что фиксировать в ТЗ и ПМИ и какие сценарии обязательно прогонять на пилоте.