Гипервизор выбирают не по бренду и не по привычке, а по соответствию требованиям вашей инфраструктуры. Метод простой: сформулировать требования по восьми критериям — совместимость с железом и гостевыми системами, экосистема резервного копирования, отказоустойчивость и миграция, управление, навыки команды, поддержка и жизненный цикл, стоимость владения, путь миграции и выхода — и сопоставить с ними платформы-кандидаты, проверяя каждый пункт по документации и на пилоте, а не по маркетинговым страницам.
Эта статья — развёрнутая методика такого выбора. Что такое виртуализация и гипервизор и где применяются распространённые платформы — в разборе виртуализации сервера; как устроена вся виртуальная инфраструктура целиком — в хабе рубрики «Виртуализация».
Что разобрано в статье
Метод, не рейтинг
Статья не называет «лучшую платформу» — она даёт способ сформулировать требования вашего бизнеса и честно сопоставить с ними кандидатов.
Восемь критериев
От совместимости с железом и гостевыми системами до пути миграции и выхода — по каждому критерию: что именно проверить и какие грабли типичны.
Бэкап как критерий
Платформа виртуализации должна дружить с резервным копированием: консистентные снапшоты для СРК, восстановление машин и файлов, проверка восстановимости.
Команда решает
Возможности платформы работают вместе с людьми: навыки, доступность специалистов на рынке, документация и сообщество — полноценный критерий выбора.
Профили бизнеса
Малый офис, растущая компания с 1С, критичный контур с жёстким RTO, смешанный парк — матрица показывает, какие критерии выходят на первый план в каждом профиле.
Чек-лист и пилот
Вопросы, на которые стоит получить ответы до внедрения, и правило финальной проверки: кандидат подтверждается пилотом на вашей нагрузке.
Выбирают не бренд, а соответствие требованиям
Обсуждение выбора гипервизора легко начать не с того конца — со сравнения платформ между собой. Продуктивнее обратный порядок: сначала сформулировать требования вашей инфраструктуры, а потом проверить кандидатов на соответствие им. Одна и та же платформа может быть отличным ответом для одного парка задач и источником постоянных проблем для другого — при одинаковых «характеристиках на бумаге».
Кандидаты при этом известны и перечислены в обзорных материалах: коммерческие платформы с вендорской поддержкой (класс VMware vSphere и Microsoft Hyper-V), открытые платформы (класс Proxmox VE и решений на KVM и Xen) и отечественные платформы виртуализации. Что представляет собой каждая и где применяется — в разборе виртуализации сервера; эта статья имена дальше почти не использует, потому что метод от них не зависит.
Требования стоит зафиксировать письменно — хватает одной страницы: список серверов и СХД, перечень гостевых систем и ключевых приложений, допустимый простой по системам, кто эксплуатирует. Этот документ дисциплинирует сравнение кандидатов, а позже превращается в протокол пилота: каждый пункт из него — проверка на стенде.
Требования удобно раскладывать по восьми критериям следующей секции. Два правила до старта. Первое: критерии сравниваются по документации и проверяются на пилоте — маркетинговые страницы для этого не годятся. Второе: вес критериев у каждого бизнеса свой, и определяется он задачами: профиль нагрузки, допустимый простой, доступная команда. Матрица профилей в конце статьи помогает расставить веса честно.
Восемь критериев: что проверить и где грабли
| Критерий | Что проверить | Типовые грабли |
|---|---|---|
| 1. Совместимость с железом | Ваши серверы, контроллеры, сетевые карты и СХД — в списке совместимости платформы (HCL); требования к CPU и памяти | Платформа выбрана, а парк несовместим — драйверы, контроллеры, BMC |
| 2. Гостевые системы и приложения | Поддержка нужных ОС (включая устаревшие, которые нельзя обновить) и требования вендоров ключевых приложений | Одна критичная легаси-система ломает всю миграцию |
| 3. Резервное копирование | Консистентные снапшоты для СРК, поддержка вашей системы копирования, восстановление машин и отдельных файлов | Платформа внедрена, а привычная СРК её не поддерживает |
| 4. Отказоустойчивость и миграция | Кластер, живая миграция, поведение при отказе узла — в объёме, который требуют ваши цели простоя | Оплаченные возможности HA, которые могут быть избыточны для парка из двух хостов |
| 5. Управление и автоматизация | Консоль, шаблоны ВМ, API и интеграции, мониторинг, управление несколькими хостами | Рутина руками там, где ожидали автоматизацию |
| 6. Команда и рынок специалистов | Навыки текущей команды, доступность администраторов на рынке, качество документации и сообщества | Сильная по возможностям платформа, которую некому эксплуатировать |
| 7. Поддержка и жизненный цикл | Канал поддержки (вендор/партнёр/сообщество), частота обновлений, сроки поддержки версий, доступность обновлений для вас | Версия без обновлений безопасности в основе продуктива |
| 8. Путь миграции и выхода | Перенос существующих ВМ на платформу и с неё: форматы дисков, инструменты конвертации, оценка простоя на переезд | Вход спланирован, выход — нет: смена платформы через годы превращается в проект-заложник |
Дальше — четыре критерия, ошибки в которых труднее всего исправлять после внедрения: совместимость, резервное копирование, отказоустойчивость и команда. Остальные не менее реальны; их можно проверить по документации жизненного цикла, консоли пилота и плану миграции.
Совместимость: железо, гостевые системы, парк
Первый вопрос к кандидату — «встанет ли он на наши серверы и потянет ли наши системы». Проверка по трём слоям. Железо: серверы, RAID- и HBA-контроллеры, сетевые карты и подключение СХД сверяются со списком совместимости платформы; отдельно — требования к процессорным расширениям виртуализации и памяти. Гостевые системы: список нужных ОС включает не только свежие, но и устаревшие, которые нельзя обновить из-за прикладного ПО, — они могут ограничить выбор. Приложения: у вендоров ключевых систем бывают собственные требования и матрицы поддержки сред виртуализации — их стоит прочитать до выбора, а не после.
Отдельный слой совместимости — спецоборудование и проброс устройств: аппаратные ключи защиты учётных систем, токены, специализированные платы. Если такие устройства в парке есть, способ их проброса в виртуальные машины и его надёжность проверяются на пилоте в первую очередь — без такой проверки спецоборудование может стать ограничением уже после выбора платформы.
Связка с выбором железа работает в обе стороны: если парк уже есть — платформа проверяется по нему; если инфраструктура закупается под задачу — сервер подбирается под требования выбранной платформы. Как собирается хост под виртуализацию — ядра, память, хранилище, запас на рост — в разборе сервера для виртуализации; посчитать ресурсы под конкретный план машин помогает методика расчёта «сколько ВМ потянет сервер».
Под выбранную платформу и план машин подбирается и сам хост: серверы в каталоге ANDPRO — с проверкой конфигурации по требованиям платформы.
Критерий бэкапа: как платформа дружит с копиями
Резервное копирование виртуальной инфраструктуры опирается на возможности гипервизора: система копирования создаёт консистентный снапшот машины, копирует зафиксированное состояние и удаляет снапшот. Поэтому у кандидата проверяются: механизм консистентной фиксации (включая согласование с гостевой системой для баз данных), поддержка со стороны вашей системы резервного копирования, восстановление на уровне машины целиком и отдельных файлов, поведение под нагрузкой.
Классическая ловушка — выбрать платформу и обнаружить, что привычная система копирования её не поддерживает или поддерживает ограниченно: без гранулярного восстановления, без автоматической верификации, с ручными обходами. Тогда к смене гипервизора добавляется смена СРК — со своим бюджетом, обучением и рисками. Проверять связку «гипервизор + СРК» нужно как единое целое и на пилоте.
К критерию относится и скорость восстановления: время подъёма машины из копии на этой платформе — часть фактического времени восстановления ваших сервисов, и его стоит замерить на пилоте, а на проде — проверять регулярно. Сам замер и регламент — методика в гайде по тестовому восстановлению.
Важно и не переоценивать встроенные механизмы платформы: снапшоты — точки отката, а не резервные копии, у этой границы есть строгая механика — она разобрана в статье о снапшотах и репликации.
Отказоустойчивость и миграция: что реально нужно
Возможности этого блока — кластер, живая миграция машин между хостами, автоматический перезапуск при отказе узла — сильно различаются по редакциям и лицензиям платформ и заметно влияют на требования к инфраструктуре: общее хранилище или синхронизация, дублированная сеть, запас ёмкости под отказ узла.
Поэтому проверка здесь двухшаговая. Сначала честный ответ на вопрос «что нам нужно»: допустимый простой каждой системы уже определяет, нужен ли кластер, достаточно ли быстрого восстановления из копии или требуется живая миграция для обслуживания без остановки. Затем — проверка кандидата: как его редакции закрывают именно этот уровень, что происходит при отказе узла на практике, сколько времени занимает переключение на пилотном стенде.
Между «ничего» и полноценным кластером есть промежуточные схемы: подготовленный резервный хост с регулярным восстановлением из копий, реплика критичных машин на второй узел. Для части задач малого и среднего бизнеса такого уровня достаточно — если это подтверждено целевым простоем и проверено тестом, а не принято по умолчанию. Достаточность схемы — вопрос целей, не привычки.
Ошибка возможна в обе стороны: оплатить кластерные возможности парку, которому хватило бы ночной копии и запасного железа, — или наоборот, собрать критичный контур на минимальной редакции без HA и узнать об этом в первый серьёзный отказ. Из чего состоит минимальный отказоустойчивый контур и когда он оправдан — тема статьи о высокой доступности.
Управление, автоматизация и команда
Платформа живёт не в презентации, а в ежедневной эксплуатации: создать машину из шаблона, раздать права, обновить хосты, найти причину деградации. Поэтому у кандидата проверяются консоль управления (в том числе несколькими хостами сразу), шаблоны и клонирование ВМ, API для автоматизации, интеграция с мониторингом, а также то, как выглядят типовые операции — на пилоте, руками вашего же администратора.
С управлением связан и регламент обновлений: хосты нужно обновлять регулярно, а сервисы при этом останавливать нельзя или можно лишь в короткое окно. Проверьте на пилоте, как у кандидата выглядит обновление хоста: переносятся ли машины на соседний узел на время работ, что происходит при сбое обновления, сколько занимает возврат. Это будничная операция, и удобство именно будничных операций определяет качество жизни с платформой.
Критерий команды при этом самостоятелен и весом. В него входят: навыки текущих специалистов (переучивание — реальная статья затрат и рисков), доступность администраторов нужной платформы на рынке труда, качество документации и живость сообщества или базы знаний вендора. Инцидент в три часа ночи решает не «набор возможностей», а человек, который понимает, что делать, — и скорость, с которой он находит ответ.
Практичный способ проверить оба пункта разом — пилот силами своей команды без внешних консультантов: развернуть, создать машины, настроить копирование, «уронить» тестовый узел. Сколько вопросов останется без ответа после недели пилота — честная метрика управляемости платформы для вашей команды.
Стоимость владения без иллюзий
Сравнение платформ только по цене лицензии ведёт к неполному выводу. Стоимость владения складывается из нескольких статей: лицензии или подписки самой платформы и сопутствующего ПО (система копирования, мониторинг), поддержка (вендорская, партнёрская или собственными силами), железо под требования платформы и её редакций, обучение или наём людей, стоимость самой миграции — и стоимость будущего выхода, если платформу придётся менять.
У конкретных платформ эти статьи распределяются по-разному: в одном расчёте больший вес дадут лицензии и подписки, в другом — поддержка и компетенции команды. Какое распределение выгоднее — зависит от вашего масштаба, парка и людей; универсального ответа у этого сравнения нет, а честную картину даёт расчёт всех статей на горизонте нескольких лет для вашей конкретной ситуации.
В смету стоит включить и пилот: стенд, время команды, при необходимости — временные лицензии. Это не накладные расходы, а страховка от дорогой ошибки — внедрения платформы, которая не подошла.
Условия лицензирования, поддержки и доступность конкретных платформ в РФ проверяйте у вендора и поставщика на момент выбора — они меняются, и опираться на прошлогодние сведения при закупке рискованно.
Матрица: профиль бизнеса → приоритетные критерии
Веса критериев расставляются задачами. Четыре типовых профиля — иллюстрации метода, не нормативы; ваш профиль может сочетать несколько строк:
| Профиль | Приоритетные критерии | На что смотреть в первую очередь |
|---|---|---|
| Малый офис без выделенного администратора | Команда и простота управления; резервное копирование; стоимость владения | Понятная консоль, простое восстановление, доступность приходящего специалиста под платформу |
| Растущий бизнес с 1С и филиалами | Гостевые системы и приложения; бэкап; управление несколькими хостами; путь миграции | Требования вендоров учётных систем, консистентные копии баз, шаблоны и централизованное управление |
| Критичный контур с жёстким временем восстановления | Отказоустойчивость и миграция; бэкап и проверка восстановления; поддержка и жизненный цикл | Поведение кластера при отказе узла на пилоте, замер переключения, канал поддержки с обязательствами |
| Смешанный парк и тестовые среды | Совместимость с разнородным железом; управление и автоматизация; стоимость владения | API и шаблоны, работа на разнородных хостах, экономика лицензирования при большом числе некритичных машин |
Работать с матрицей удобно так: определите свой профиль (или сочетание), раздайте восьми критериям веса от «критично» до «желательно» и пройдитесь по кандидатам построчно, отмечая подтверждённые пункты. Не превращайте это в псевдоточную математику со средним баллом — таблица структурирует обсуждение и делает разногласия видимыми, а решение принимается по итогам пилота, где «критичные» пункты проверены руками.
Матрица не выбирает платформу — она выбирает, какие секции этой статьи читать с карандашом и какие пункты пилота обязательны именно вам.
Чек-лист перед выбором
Десять вопросов, на которые стоит получить подтверждённые ответы до внедрения:
| Вопрос | Зачем спрашивать | Красный флаг |
|---|---|---|
| Весь ли наш парк в списке совместимости? | Железо — первый фильтр кандидатов | «Должно заработать» без проверки по HCL |
| Поддержаны ли все нужные гостевые ОС, включая легаси? | Одна неподдержанная система срывает миграцию | Список гостевых систем никто не составлял |
| Поддерживает ли наша СРК эту платформу полноценно? | Связка «гипервизор + СРК» работает как единое целое | «Что-нибудь придумаем» вместо проверенной интеграции |
| Какой уровень отказоустойчивости нам нужен по целям простоя? | HA-возможности выбираются от требований, не от прайса | Редакция выбрана до ответа на вопрос о простое |
| Кто будет эксплуатировать платформу завтра и через год? | Управляемость определяется людьми | Единственный носитель знаний — внешний подрядчик без договора поддержки |
| Проведён ли пилот на нашей нагрузке силами нашей команды? | Кандидат подтверждается стендом | Решение принято по презентации и чужим обзорам |
| Понятен ли канал поддержки и жизненный цикл версий? | Продуктив живёт на обновляемой и поддерживаемой версии | Неясно, откуда придёт следующее обновление безопасности |
| Как мы перенесём существующие машины? | Миграция — проект со своим простоем и рисками | План миграции «разберёмся по ходу» |
| Что будет стоить владение на горизонте нескольких лет? | Цена лицензии — только одна статья из многих | Сравнение платформ по одной цифре |
| Как мы будем уходить, если придётся? | Путь выхода планируется на входе | Ответ «зачем об этом думать сейчас» |
Ответы на эти вопросы вместе с матрицей профилей помогают сузить список кандидатов до одного-двух — дальше решает пилот на вашей нагрузке и расчёт стоимости владения по всем статьям. Если на три и больше вопросов ответа нет, выбирать рано: сначала закрыть пробелы, потом сравнивать.
Частые вопросы
Можно ли просто взять самую распространённую платформу?
Распространённость — полезный сигнал по критерию команды: специалистов, документацию и ответы на вопросы может быть легче найти. Но остальные критерии она не закрывает: совместимость с вашим парком, поддержку нужных гостевых систем, связку с СРК и стоимость владения для вашего масштаба всё равно нужно проверять. Распространённое решение, несовместимое с вашей СХД или учётной системой, проиграет менее известному, которое проходит все проверки.
Что важнее: возможности платформы или навыки команды?
Для эксплуатации — паритет, и в спорных случаях команда перевешивает: возможности, которыми некому пользоваться, не работают, а инциденты решают люди. Практичный компромисс: сначала отфильтровать кандидатов по жёстким техническим критериям (совместимость, гостевые системы, СРК), а между оставшимися выбирать с весом на команду — навыки, рынок специалистов, документацию. Пилот силами своей команды делает этот критерий проверяемым.
Как учитывать отечественные платформы виртуализации?
По тем же восьми критериям, что и любые другие: совместимость с парком, гостевые системы, связка с резервным копированием, отказоустойчивость, управление, команда, поддержка, путь миграции — и обязательный пилот. Отдельный пласт — требования регулируемых закупок и реестров: это самостоятельная тема со своими правилами, выходящая за рамки технического выбора; условия и статусы проверяйте по официальным источникам на момент закупки. Пилот для отечественных платформ так же обязателен, как для любых других, — методика исключений по происхождению платформы не делает.
Авторство и ответственность
Материал подготовлен для блога ANDPRO / ООО «АНД-Системс» как информационная статья о методике выбора гипервизора: восемь критериев с проверками и типовыми ошибками, разбор ключевых критериев, матрица профилей бизнеса и чек-лист. Статья описывает метод и не заменяет проектирование виртуальной инфраструктуры под конкретный парк, приложения и требования; конкретные платформы проверяются по их актуальной документации и на пилоте.
Материал подготовлен при участии AI-ассистента, прошёл фактчекинг и редакторскую вычитку. Статья намеренно не содержит характеристик и сравнений конкретных продуктов: имена платформ упоминаются только как иллюстрации классов (согласованы с обзором виртуализации сервера в блоге), все проверки адресованы к документации и пилоту читателя. Критерии, матрица профилей и чек-лист — методика ANDPRO; условия лицензирования, поддержки и доступность платформ в РФ проверяются у вендора и поставщика на момент выбора.
Для подбора сервера под требования выбранной платформы, проверки совместимости конфигурации, подготовки КП и документов обратитесь в ANDPRO: info@andpro.ru, +7 (495) 545-48-70, +7 (800) 707-78-15.
Дата последнего обновления материала: 25 июля 2026 года.
