17.10.2026
Как выбрать платформу виртуализации для корпоративной инфраструктуры: пошаговая инструкция
zVirt
Введение
Чтобы выбрать платформу виртуализации в 2026 году, ИТ-директору и архитектору нужно смотреть шире гипервизора. Представьте: виртуальные машины перенесли, но бэкап перестал работать или сеть ведёт себя иначе. Формально миграция завершена, а бизнес получил проблему.
;В этой статье пошагово разберём процесс выбора сервиса для виртуализации: от аудита серверов до пилота на реальной нагрузке. В качестве одного из примеров рассмотрим платформу zVirt от Orion soft, но основные критерии и этапы выбора подойдут для оценки любой платформы виртуализации.
Из чего состоит платформа виртуализации и почему выбирать её нужно системно
Гипервизор — только основа: что ещё входит в платформу
Гипервизор распределяет ресурсы сервера между ВМ. Первый тип работает напрямую с оборудованием и обычно используется в ЦОДах. Второй запускается поверх ОС и чаще применяется для тестов и разработки.
;Платформа добавляет к гипервизору управление кластерами, сетями, СХД, мониторинг и API. Для непрерывности работы нужны HA, живая миграция, репликация, DR и разграничение прав. Бэкап восстанавливает данные; DR — работу сервисов.
Почему выбор платформы виртуализации — стратегическое решение, а не закупка ПО
Почему не стоит относиться к такой закупке как к обычной замене программы? Потому что решение остаётся с компанией на годы. Вместе с ним вы выбираете способ обновлять хосты, подключать новое железо, восстанавливаться после аварии и управлять ресурсами. При смене платформы меняется не одна кнопка в интерфейсе: приходится учитывать гостевые ОС, сети, хранилища и работу команды.
;CIO важно оценить поддержку, обучение, документацию и дорожную карту: всё это влияет на зависимость от вендора и эксплуатацию распределённых ЦОДов.
Пошаговый план выбора системы виртуализации
Не стоит начинать выбор системы виртуализации с презентации вендора. На демо любое решение выглядит удобным. Подойдёт ли оно ЦОДу, станет ясно, когда запишем ограничения и проверим реальные сценарии. Поэтому выбор виртуализации лучше разбить на шесть проверок.
;Итог каждого шага измерим:
- аудит — реестр нагрузок;
- критерии — матрица;
- отбор — шорт-лист;
- ИБ — комплект документов;
- экономика — TCO (совокупная стоимость владения);
- пилот — протокол испытаний.
Распределите роли: архитектор отвечает за требования, ИБ — за защиту, эксплуатация — за регламенты, финансы — за TCO. Так меньше шансов забыть важную интеграцию.
Сначала отсейте варианты, которые не выполняют обязательные условия. Несовместимость с критичной ОС или отсутствие нужного DR не компенсирует удобный интерфейс.
Шаг 1. Зафиксируйте текущую среду и ограничения проекта
Сначала ответьте себе, какую задачу решаем. Заменяем платформу в работающем ЦОДе? Строим новый кластер? Переносим VDI или филиалы? За этими словами разные требования к доступности, сети и срокам миграции. Без такого ответа любая таблица характеристик будет довольно абстрактной.
Инвентаризация: ВМ, хосты, СХД, сети, зависимости
Соберите число ВМ и хостов, CPU, RAM, версии гостевых ОС, IOPS, задержки и пиковые нагрузки. Не ограничивайтесь средними цифрами: база данных может спокойно работать днём, а затем резко нагрузить СХД. Именно тогда проявляются ограничения архитектуры.
Составьте схему VLAN, маршрутов, правил, каналов, протоколов СХД и резервных путей. Зафиксируйте интеграции с каталогом, мониторингом, CMDB и бэкапом. Добавьте зависимости между ВМ: часть сервисов может остаться в старой среде.
Рамки проекта: регуляторика, сроки, бюджет, компетенции команды
Отметьте, относятся ли системы к КИИ, ГИС или ИСПДн. Для рамки используйте Федеральный закон № 187-ФЗ о КИИ и № 152-ФЗ о персональных данных, а конкретные меры согласуйте с ИБ. Российское происхождение ПО не гарантирует соответствия каждому защищённому контуру.
Зафиксируйте сроки, бюджет, тестовое оборудование и компетенции команды. Разделите требования на обязательные и желательные: без нужного сертификата кандидат не проходит, к новому интерфейсу можно привыкнуть.
Переходный период: что останется на старой платформе
Не рассчитывайте, что за один вечер все ВМ исчезнут со старой платформы и появятся на новой. Перенос обычно идёт волнами: две среды временно делят сети, каталог, мониторинг и бэкап. Сразу определите окна переключения, конвертер, откат и стоимость параллельной эксплуатации.
Шаг 2. Определите критерии выбора и их вес
Составьте матрицу из критерия, веса, минимума и метода проверки. Баллы можно ставить от 0 до 5, но блокирующие условия оценивают отдельно.
;Функциональные возможности: HA, живая миграция, снапшоты, DR, API
Отделите обязательные функции от опций «на вырост». Проверьте HA, живую миграцию, снимки, DR и API в нужных сценариях. Снапшоты не заменяют бэкап.
Производительность и масштабируемость
Учитывайте, что производительность в презентации и производительность вашего приложения — не одно и то же. Проверяйте задержку дисков, IOPS, нагрузку CPU/RAM, скорость миграции и поведение кластера после потери узла. Если при отказе одного хоста оставшиеся работают на пределе, формально успешный тест мало о чём говорит.
Совместимость: оборудование, гостевые ОС, интеграции
Проверьте точные модели серверов, процессоров, СХД, адаптеров и гостевых ОС по матрицам. Тестируйте multipathing, бэкап, мониторинг и каталог пользователей. Одного устного обещания недостаточно.
Эксплуатация, экосистема и поддержка вендора
Предложите инженерам выполнить обычный рабочий день: развернуть ВМ из шаблона, назначить права, найти лог, обновить хост, восстановить управление. Сразу станет понятно, где есть автоматизация, а где каждую операцию придётся делать вручную. Для небольшой команды такая разница важнее десятка редких функций.
Как выбрать платформу виртуализации на основе матрицы
Дальше всё прозрачно: оцениваем прошедших обязательные условия кандидатов, умножаем баллы на веса, складываем. Но к каждому баллу должен прилагаться ответ на вопрос «чем подтвердили?». Укажите версию, дату проверки, ссылку на документацию или результат испытаний. Иначе это будет не матрица, а набор мнений.
Шаг 3. Составьте список: какие бывают платформы виртуализации
Коммерческие платформы предлагают готовое управление и поддержку. Open Source гибче, но требует компетенций команды. HCI объединяет вычисления и хранение, CMP помогает управлять несколькими средами. Это разные уровни инфраструктуры: сопоставлять их как одинаковые продукты некорректно.
;Выясните, нужны ли только серверные ВМ или также филиалы, VDI и контейнеры. Сравнивайте подходящие редакции с проверенной поддержкой. Чтобы выбрать платформу виртуализации объективно, используйте одну матрицу.
Шаг 4. Проверьте безопасность, сертификацию и вендора
В защищённом контуре недостаточно услышать от производителя: «У нас есть сертификат». Сразу уточняйте, на какую редакцию и версию он выдан и что именно покрывает.
Сертификация и реестры: ФСТЭК, реестр Минцифры
Проверьте сведения о продукте в реестре российского ПО Минцифры и государственном реестре сертифицированных средств защиты информации ФСТЭК. Зафиксируйте номер, срок, класс, уровень доверия и точную версию сертификата. Подтверждение для старой редакции не распространяется автоматически на новую.
Безопасность архитектуры: изоляция ВМ, доступ, журналирование
На пилоте проверьте изоляцию ВМ, роли, доступ, шифрование соединений, журналы, SIEM и микросегментацию. Оцените устранение уязвимостей. Наличие механизма ещё не означает соответствие защищённому контуру.
Устойчивость вендора и модель поддержки
Смотрите не только на SLA, но и на выпуск обновлений и поддержку интеграций. Кто отвечает за сбой на стыке гипервизора и СХД? Кто воспроизведёт ошибку, выпустит исправление и поможет его установить? Спросите до договора.
Шаг 5. Посчитайте стоимость владения и риски
Цену лицензии учитывать нужно, но останавливаться на ней не стоит. Считайте TCO на три-пять лет с единым объёмом ресурсов, количеством площадок, ростом и поддержкой. Лицензии по ядрам, сокетам и хостам сначала приводят к одной конфигурации.
Из чего складывается TCO
В расчёте важно разделять разовые расходы на переход и постоянные затраты на эксплуатацию. Иначе два коммерческих предложения сложно сравнить. Ниже — статьи, которые стоит учесть для каждого варианта.
Учтите стрессовый сценарий: задержку миграции, несовместимость и рост затрат. Разовые расходы отделяйте от регулярных.
Скрытые затраты миграции и обучения
Часто за скобками остаётся работа людей. После миграции нужно проверить приложения, переписать часть скриптов, подключить резервное копирование, обучить дежурных. Уточните, входят ли в договор инструменты переноса и помощь вендора. А стоимость простоя считайте по конкретному сервису, а не по усреднённой цифре.
Добавьте реестр рисков: вероятность, ущерб, ответственный, меры снижения. Он нужен для защиты бюджета.
Шаг 6. Проведите пилот и примите решение
Пилот — это не экскурсия по интерфейсу. К нему стоит подходить как к эксперименту: заранее задать требования, оборудование, нагрузку, метрики и допустимые отклонения. И проводить одинаковые испытания на сопоставимых версиях всех кандидатов.
;Проверьте реальные аварийные ситуации: пик нагрузки, отказ хоста, потерю сетевого пути, живую миграцию, восстановление из бэкапа и перенос рабочей ВМ. Для DR измеряйте RTO и RPO. Недостаточно увидеть запущенную ВМ — важно, когда сервис снова доступен пользователям.
В пилоте участвуют архитектор, инженеры виртуализации, сетей, СХД, ИБ и владелец приложения. Каждый подтверждает свою часть. Результаты сравнивают с заранее установленными порогами.
Для zVirt проверьте V2V, REST API и выбранный способ репликации. В 5.0 доступны сценарии миграции между ЦОДами и задания по расписанию. Проверяйте точную редакцию и актуальную документацию.
Типичные ошибки при выборе платформы виртуализации
Можно подробно сравнить функции и всё равно ошибиться. Обычно причина не в гипервизоре, а в непроверенных предположениях о нагрузке, миграции и поддержке. Разберём шесть типичных ошибок:
;1. Сравнивать только цену лицензии. Без расчёта миграции, поддержки и аппаратного резерва бюджет окажется неполным. Решение — оценивать TCO за единый период.
2. Не фиксировать исходную нагрузку. Пилот на пустых ВМ не показывает работу базы данных или VDI в пике. Решение — снимать метрики продуктивной среды до начала проекта.
3. Считать все функции равнозначными. Отсутствие критичного механизма HA нельзя компенсировать удобным интерфейсом. Решение — выделять блокирующие требования до выставления баллов.
4. Не проверять конкретную редакцию. Функция из презентации может быть доступна только в расширенной поставке или будущем релизе. Решение — сверять версии и лицензионные ограничения.
5. Игнорировать переходный период. Две инфраструктуры требуют общих сетевых правил, резервного копирования и дополнительной поддержки. Решение — планировать перенос волнами.
6. Ограничиваться демонстрацией без испытаний. Красивый интерфейс не подтверждает восстановление сервисов после сбоя. Решение — заранее утвердить нагрузочные и аварийные сценарии пилота.
Как выбор платформы виртуализации отличается для разных организаций
Универсального веса критериев здесь нет. Для одного заказчика первое место занимает сертификация, для другого — масштабирование, для третьего — возможность обходиться небольшой командой.
КИИ и госсектор: приоритет сертификации и защищённого контура
Для значимых объектов КИИ и ГИС критичны сертификаты, область их действия, доступ и аудит. В линейке Orion soft есть защищённые редакции платформы виртуализации zVirt, предназначенные для использования в инфраструктурах с повышенными требованиями к безопасности.
Крупный enterprise с гетерогенной средой
В крупных компаниях с несколькими ЦОДами и разнородной ИТ-инфраструктурой важно оценивать не только возможности гипервизора, но и то, насколько удобно управлять ресурсами в разных средах. Ключевыми критериями становятся масштабируемость, автоматизация типовых операций, интеграция с системами хранения данных (СХД), а также единые правила выделения и контроля ресурсов.
Для упрощения управления такой инфраструктурой можно использовать Cloudlink от Orion soft — платформу управления облачной ИТ-инфраструктурой. Она помогает централизовать работу с ресурсами и упростить управление разными средами в период миграции или при сохранении смешанной инфраструктуры.
Среднее предприятие с небольшой командой
Для небольшой команды главный вопрос звучит просто: сколько операций придётся делать руками и кого будить ночью при сбое? Здесь особенно важны поддержка, документация, обучение и понятная стоимость. Сложный SDN или DR имеет смысл только тогда, когда за ним стоит реальная задача.
Платформа виртуализации zVirt от Orion soft
Теперь посмотрим, как эта методика применяется к конкретному продукту.
;Orion soft развивает zVirt с 2018 года на основе oVirt. С тех пор платформа получила собственные компоненты и сервисы; оценивать её стоит по тем же правилам, что и других кандидатов.
zVirt управляет хостами, кластерами, ВМ, сетями и дисками. Есть HA, живая миграция, API, разграничение прав, балансировка ресурсов и папки ВМ. V2V помогает при переносе; сценарии сверяют с документацией.
На своем вебинаре эксперты Orion soft объясняли архитектурный переход zVirt 5.0 на специализированную ОС zVirt Node 2.0 собственной сборки. Зачем это заказчику? Разработчик контролирует системные пакеты и обновления, убирает лишние компоненты. В новом релизе также появились миграция ВМ между ЦОДами без общего хранилища, задания по расписанию и функции SDN; часть относится к Advanced.
Для непрерывности работы используется zVirt DR с программной и аппаратной репликацией совместимых СХД. В версии 5.0 расширена поддержка NetApp и сетевых настроек при восстановлении. zVirt SDN обеспечивает логические сети, маршрутизацию и микросегментацию. Конкретную комбинацию оборудования и редакции нужно проверить по матрице.
Чек-лист выбора системы виртуализации
Чтобы выбрать платформу виртуализации без лишнего риска, начните с реального состояния инфраструктуры и доведите процесс до воспроизводимого пилота. Окончательное решение должно опираться на документы, измерения и полную стоимость владения, а не только на перечень функций. zVirt от Orion soft можно включить в шорт-лист и изучить на сайте разработчика, оценив нужную редакцию по тем же правилам.
;- Есть перечень ВМ, нагрузки, зависимостей и аппаратных компонентов.
- Определены обязательные требования, RTO/RPO и сроки.
- Описан переходный период и план возврата.
- Утверждены веса критериев и пороговые условия.
- Проверены совместимость, ОС, СХД и интеграции.
- Сверены сертификаты, редакции и срок их действия.
- Рассчитан TCO на 3–5 лет с рисками миграции.
- Есть программа пилота с реальными нагрузками и отказами.
- Получены результаты тестирования и протокол решения.
Часто задаваемые вопросы
На какие критерии ориентироваться при выборе платформы виртуализации для бизнеса?
Сначала оцените доступность, совместимость и ИБ. Затем задайте веса производительности, поддержке, эксплуатации и TCO.
;Чем отличаются решения для небольшой компании и крупного enterprise?
Небольшому бизнесу важны простота и бюджет; enterprise — масштаб, несколько площадок, автоматизация и DR.
;Как проверить соответствие требованиям безопасности?
Проверьте сертификат ФСТЭК и точную редакцию, затем испытайте права, аудит, сегментацию и обновления.
;Как оценить совместимость с действующим оборудованием?
Сверьте серверы, СХД, адаптеры и гостевые ОС с матрицами. Критичные комбинации проверьте на стенде.
;Можно ли мигрировать с другой платформы без остановки бизнес-сервисов?
Не всегда. Перенос между гипервизорами — не живая миграция внутри платформы. Простой зависит от приложения и переключения.
;Чем аварийное восстановление отличается от резервного копирования?
Бэкап возвращает данные, DR — работу сервисов по сценарию переключения с заданными RTO/RPO. Нужны оба механизма.
;zVirt