Импортозамещение виртуализации: как выбрать оборудование и вендора, чтобы не переделывать всё через полгода

Типичная картина при переходе на российские системы виртуализации: на старте смотрят на модель сервера и название гипервизора, но не проверяют, как они работают вместе на конкретном стеке. И вскоре выясняется, что компоненты несовместимы. В итоге кластер нестабилен, а переделка обходится дороже первоначального внедрения.

В статье разбираем, как выбрать железо и вендора виртуализации так, чтобы не попасть в эту ловушку.

Почему совместимость — это не «сервер + гипервизор», а полный стек

Когда выбирают платформу виртуализации, обычно смотрят на две вещи: модель сервера и название гипервизора. Но работоспособность кластера зависит от того, как согласованы все компоненты стека:

• модель сервера
• прошивка BIOS/BMC
• модели контроллеров и их прошивки
• модели сетевых адаптеров, FC-адаптеров и их прошивки
• модель СХД и ее прошивка
• схема подключения к СХД
• платформа виртуализации

Мы уже отмечали, что даже в зрелой VMware обновление гипервизора может провалиться из-за устаревшего BIOS или несогласованной прошивки сетевой/дисковой карты. Иными словами, совместимость действует лишь на уровне конкретной комбинации компонентов.

На практике мы видим одну и ту же картину: в кластере разные узлы могут иметь разный BMC, разные сетевые адаптеры или разные контроллеры СХД, их прошивки. 

Чтобы железо работало, нужно задать в ТЗ под целевую версию гипервизора конкретный BOM – ревизию материнской платы, BIOS/BMC и даже NIC/HBA (какие сетевые адаптеры и RAID-контроллеры туда пойдут).

Какой должна быть конфигурация в пилоте

Идеальный сценарий – собрать пилотный стенд с железом, которое вы собираетесь закупать (такая же модель сервера, сеть, СХД и т.д.), и повесить на него вашу нагрузку. 

Выделите 2-4 недели и прогоните четыре сценария:

1. Поднимите несколько типовых виртуальным машин (ВМ)  — включая самые тяжёлые и чувствительные — и проверьте, насколько быстро они стартуют и мигрируют между хостами, а также нет ли проблем при пиковых нагрузках.
2. Настройте резервное копирование и воспроизведите сценарий восстановления.
3. Смоделируйте падение хоста: принудительно отключите один сервер, чтобы понять, как кластер распределит ВМ и укладывается ли в допустимый RTO.
4. Перезагружайте коммутаторы и дисковые контроллеры поочерёдно, убедитесь, что сеть и СХД реагируют правильно.

Таким образом, наиболее правильный и полный вариант — выполнить целиком ПМИ системы. Оптимально выбрать 2–3 кандидата и протестировать их на этих сценариях. Именно так выплывают «подводные камни»: например, выясняется, что при заявленной поддержке нужных NIC один канал раздаёт всё, а второй – ничего (ошибка конфигурации драйверов), или что при «нужном» обновлении прошивки часть VLAN не работает. Поэтому тестируйте конфигурацию заранее на продуктивных нагрузках.

Сеть и хранилище: как добиться отказоустойчивости

Архитектура подключения к СХД и внутренней сети кластера – ещё одна частая ловушка. На старте хочется сэкономить, но потом это дорого обходится. 

Несколько правил, которые стоит заложить в архитектуру сразу: 

1. Дублирование коммутаторов. Обслуживание одного свитча без дублирования может вызвать остановку кластера.
2. Разделение трафика. Отдельные изолированные сети (VLAN) для кластерного транспорта, миграций ВМ и пользовательских ВМ. Минимум необходимо разделить трафик сети управления и сети ВМ, чтобы при нештатных ситуациях и аномальном всплеске трафика ВМ, вы не потеряли доступ к управлению кластером.
3. Multipath к СХД. Рекомендуем использовать многопутевой доступ к дисковым контроллерам СХД. Без этого отказ одного пути сделает СХД недоступной для части узлов кластера.
4. Никаких HDD в GFS2. Для разделяемого тома GFS2 допускаются только SSD, иначе падение диска может повредить файловую систему. Кроме того, при работе системы пишется большой объем метаданных ВМ на диски и тип диска напрямую влияет на быстродействие системы в целом.
5. Отказоустойчивый кластер. Включите зеркалирование дисков контроллера и продумайте резервирование питания. Любой «одиночный» элемент в цепочке (свитч, линк, контроллер) превращается в точку отказа.

Временная схема «один свитч» может сработать на пилоте, но гарантированно станет головной болью при масштабировании или техническом обслуживании. Чтобы потом не «ломать и строить по-новому», лучше сразу заложить избыточную топологию и отработать процедуру обновления.

Почему нужен единый ответственный за весь стек

Одного пилота и правильной топологии мало – нужны понятные роли и процессы. Перебрасывание мяча в случае проблем происходит на стыке: производитель сервера скажет «дело в гипервизоре», а вендор виртуализации – «смотрите сетевую карту и контроллеры». Если проект отдан четырём разным подрядчикам, риск неразберихи очень велик. Поэтому заранее договоритесь, кто будет отвечать за поддержку на каждом этапе.

Также уделите внимание настройкам BIOS/BMC. Перед вводом в эксплуатацию убедитесь, что нужный режим загрузки установлен и сохраняется через BMC. В нашей практике бывало, что после обновления БСВВ сервера сбрасывались в режим UEFI, и кластер переставал стартовать — приходилось фиксировать это «вручную» при каждом перезапуске. Лучший выход – задокументировать версии BIOS и BMC прошивки и согласовать процедуру обновления (кто как и когда прошивает, и как это тестируется).

Чек-лист: что проверить перед закупкой и пилотом

• Инвентаризация и прогноз нагрузки. Соберите метрики текущей нагрузки (CPU, RAM, IOPS, сеть) и спрогнозируйте рост на 1–3 года. Оцените всё: не только количество ВМ, но и характер (базы данных, файловые и почтовые сервисы, 1С, тестовые стенды и т.д.). Это позволит понять, сколько узлов, памяти и дисков какого типа нужно закладывать с запасом (не покупайте «впритык» под текущие объёмы). Не забывайте закладывать запасы вычислительной мощности на обеспечение работы самой системы виртуализации. А также про схему N+1 для обеспечения отказоустойчивости. Также следует помнить про необходимые запасы дискового пространства на СХД для предотвращения ее деградации.
• Сложность лицензирования. Уточните модель лицензирования (по узлам, сокетам, ядрам) и что входит в базовую поставку. Например, возможно, кластер и миграции потребуют доплаты. Учтите резервное копирование и шифрование: дешёвая лицензия может оказаться дороже в эксплуатации, если потом придётся докупать модули.
• Совместимость оборудования. Убедитесь, что выбранные серверы и контроллеры поддерживаются платформой виртуализации. Проверьте в матрице совместимости, что процессор, сетевые и SCSI-контроллеры, RAID-карты именно вашей ревизии сертифицированы для целевой версии ПО. Помните: документация вендора виртуализации может быть неполной, поэтому перепроверьте через профильные форумы и кейсы коллег.
• Сертификация системы и требования ИБ. Требует ли законодательство обязательного использования сертифицированных версий ПО. Требуется ли приобретение дополнительных наложенных средств защиты.
• Архитектура отказоустойчивости. Детально пропишите схему сети и хранения. Стоит задокументировать, сколько коммутаторов каждого уровня, используется ли агрегация каналов, какая схема хранения (прямое подключение или через SAN-коммутатор), есть ли мультипатч. Любая «одиночная» траектория должна стать «красной строкой»: с одним узлом, свитчем или линком отказоустойчивость невозможна.
• Демо и пилот. Включите в техзадание этап пилота: поднимите кластеры с выбранным железом и перенесите несколько ВМ. На этом же этапе проверяйте recovery-сценарии (фейл одной ноды, full-restore из бэкапа) и процедуру обновления ПО. В постановке целей пилота опишите сценарии (миграция ВМ, отключение питания узла, сбой коммутатора) и критерии «успеха/неудачи».
• Ответственность и SLA. Пропишите в договоре, кто на каком этапе отвечает за поддержку. Если планируете самостоятельно поддерживать инфраструктуру, согласуйте SLA с каждым вендором. Если используете сервисный контракт с интегратором (например, модель private cloud), включите в него контрольные точки (мониторинг, обновление, эскалации). В российских реалиях часто выгоднее иметь единого гаранта работоспособности (мы видели, как мультивендорная схема сводит разработку происшествий к поискам виновных).

«Совместимость» в 2026 году – гипотеза, а не факт. Проверяйте её на вашем конкретном стеке, на ваших планах роста и отказов. И лучше всего делать это вместе с теми, кто потом будет этот стек поддерживать. Проверка точной конфигурации до закупки – главный способ избежать «полгода переписки между вендорами».

Если хотите доверить импортозамещение экспертам и делегировать все этапы – от определения потребностей бизнеса и аудита компонентов до закупки, внедрения и администрирования – заполните короткую форму. Наши инженеры свяжутся с вами.