После приобретения VMware компанией Broadcom подход к лицензированию платформы заметно изменился. Для бизнеса вопрос виртуализации теперь всё чаще связан не только с техническими возможностями VMware, но и со стоимостью владения инфраструктурой.
Переход на подписочную модель и лицензирование по физическим ядрам заставляют компании пересматривать привычную архитектуру: оставаться на VMware, переходить на Proxmox VE, использовать Hyper-V или строить инфраструктуру на KVM.
VMware продолжает развиваться как технологическая платформа, однако коммерческая модель изменилась. Одно из наиболее существенных изменений — переход к лицензированию по количеству физических ядер процессоров.
При расчёте лицензий учитываются физические CPU-ядра ESXi-хостов. Для процессора действует минимальный порог лицензирования в 16 ядер. Поэтому конфигурация физического сервера теперь напрямую влияет не только на его производительность, но и на стоимость программной инфраструктуры.
| Что изменилось | Что это означает для бизнеса |
|---|---|
| Подписочная модель | Расходы на виртуализацию становятся регулярными |
| Лицензирование по ядрам | Количество физических ядер влияет на объём необходимых лицензий |
| Минимум 16 ядер на процессор | Даже CPU с меньшим количеством ядер требует лицензирования минимум 16 ядер |
| Изменение продуктовой структуры | Необходимо заново оценивать состав используемых продуктов и стоимость инфраструктуры |
Нет. Само изменение лицензионной политики не означает, что существующую VMware-инфраструктуру нужно срочно демонтировать.
Сначала имеет смысл сравнить стоимость сохранения текущей платформы со стоимостью миграции. Для крупной инфраструктуры перенос десятков или сотен виртуальных машин также требует ресурсов: времени инженеров, тестирования, перенастройки резервного копирования и возможного обновления оборудования.
Если стоимость VMware перестала устраивать компанию, сегодня существует несколько основных направлений миграции.
Один из наиболее популярных вариантов для малого и среднего бизнеса. Proxmox VE построен на KVM и LXC и позволяет создавать виртуальные машины и контейнеры, объединять серверы в кластер, выполнять миграцию виртуальных машин между узлами и строить отказоустойчивую инфраструктуру.
Подходит: для виртуализации серверов 1С, Linux- и Windows-систем, тестовых сред, внутренних сервисов и большинства типовых корпоративных нагрузок.
Логичный вариант для инфраструктуры, в которой основную часть виртуальных машин составляют Windows Server, Microsoft SQL Server, Active Directory и другие решения Microsoft.
Подходит: компаниям с преимущественно Microsoft-стеком и уже выстроенной экспертизой администраторов вокруг Windows Server.
KVM — технология виртуализации, встроенная в Linux. Она лежит в основе множества коммерческих и open-source платформ.
Подходит: компаниям с собственной Linux-экспертизой, которым нужна гибкая инфраструктура и которые готовы самостоятельно управлять её компонентами.
Для крупных инфраструктур также рассматривают Nutanix AHV, OpenShift Virtualization и другие платформы. Здесь выбор обычно определяется не только стоимостью лицензий, но и требованиями к кластеризации, хранению данных, автоматизации и технической поддержке.
| Платформа | Кому подходит | Особенность |
|---|---|---|
| VMware | Существующая enterprise-инфраструктура | Зрелая экосистема и большой набор инструментов |
| Proxmox VE | Малый и средний бизнес | KVM + LXC, кластеризация, гибкая модель использования |
| Hyper-V | Microsoft-инфраструктура | Интеграция с Windows Server |
| KVM | Linux-инфраструктура | Максимальная гибкость |
Самая распространённая ошибка — сначала выбрать новый гипервизор, а уже потом разбираться, сможет ли существующая инфраструктура нормально на нём работать.
Не обязательно. Если существующие серверы обладают достаточной производительностью и совместимы с новой платформой, их можно продолжить использовать.
Но миграция — хороший момент для аудита инфраструктуры. Старые хосты часто имеют избыток процессорных ядер при недостатке оперативной памяти или медленную дисковую подсистему. В таком случае перенос виртуальных машин на новую платформу сам по себе не решит проблему производительности.
Для виртуализации особенно важны четыре компонента:
Подробнее о подборе оборудования можно прочитать в статье «Как выбрать сервер для виртуализации».
При проектировании дисковой подсистемы также стоит заранее определить, что использовать — NVMe, SAS или SATA, а при работе с аппаратным RAID — выбрать подходящий уровень RAID.
Допустим, компания использует три VMware-хоста, на которых работает 25–30 виртуальных машин: 1С, SQL Server, контроллеры домена, файловый сервер и несколько Linux-сервисов.
Вместо механического переноса каждого старого хоста один к одному можно пересчитать фактическую нагрузку и собрать новый кластер, например на двух или трёх производительных серверах с большим объёмом RAM и NVMe-хранилищем.
Безопаснее выполнять переход поэтапно.
| Этап | Что делаем |
|---|---|
| 1. Аудит | Собираем данные по VM, нагрузкам, хранилищу и сети |
| 2. Выбор платформы | Сравниваем VMware, Proxmox, Hyper-V, KVM и другие варианты |
| 3. Пилот | Разворачиваем новый хост или небольшой кластер |
| 4. Тестовый перенос | Мигрируем некритичные виртуальные машины |
| 5. Проверка | Тестируем производительность, backup и восстановление |
| 6. Основная миграция | Переносим рабочие сервисы по согласованным окнам |
Универсального ответа нет. Если существующая VMware-инфраструктура стабильна, а стоимость лицензирования устраивает компанию, срочная миграция не требуется.
Если же новые условия существенно увеличивают стоимость владения, имеет смысл провести аудит и сравнить альтернативы. Для небольшой и средней инфраструктуры одним из вариантов может быть Proxmox VE, для Microsoft-ориентированной среды — Hyper-V, а для проектов с сильной Linux-командой — решения на базе KVM.
Главное — выбирать не только гипервизор. Производительность будущей инфраструктуры определяется связкой платформа виртуализации + серверы + оперативная память + дисковая подсистема + сеть + резервное копирование.
