Если продление vSphere не состоялось, сначала выясняют тип ключа и права текущей установки. На vSphere и ESXi могут работать критичные ВМ, поэтому продолжение их работы нельзя принимать за отсутствие ограничений. Разберем диагностику лицензии, управление хостами и действия до продления или миграции.
Что изменилось у VMware после покупки Broadcom
После приобретения VMware Broadcom изменила модель продаж и состав предложений. Для действующей инфраструктуры важнее конкретный договор: продукт, редакция, метрика, срок лицензии и поддержки. Минимальный объем заказа и доступность поставки проверяют по датированному КП и применимым условиям, а не считают неизменными для всех продуктов.
При бессрочной лицензии окончание поддержки не отменяет право использовать уже лицензированную версию. При истечении subscription или evaluation возникают ограничения управления и включения ВМ. Работающие гости могут продолжать работу, но выключенный гость может не включиться, а связь хоста с vCenter — нарушиться. Состав ограничений сверяют отдельно для версии ESXi и vCenter по документации Broadcom.
Продление, временная эксплуатация и подготовка к миграции
Сценарий 1: проверяемое продление
Если посредник предлагает продление, запросите источник лицензии, право перепродажи, продукт, срок и условия поддержки. Проверьте, кому принадлежат учетная запись и доступ к порталу, как передаются права и где подтверждается приобретение. Полученный ключ и обещание партнера сами по себе не подтверждают весь объем прав. До изменения контура сохраните текущую лицензионную информацию и согласуйте окно работ.
Законность конкретной цепочки поставки проверяют с юристом по сторонам, продукту, юрисдикциям и маршруту, включая применимые экспортные ограничения. Нельзя заранее объявить любую схему законной или незаконной. Для технической части поставщик должен подтвердить активацию, доступ к обновлениям и поддержку. Цену сравнивают с датированными предложениями одинакового состава.
Вариант подходит инсталляциям с критичной зависимостью от функций vSphere вроде vSAN, NSX или DRS, когда стоимость миграции выше стоимости продления на обозримом горизонте.
Сценарий 2: жизнь без активной подписки
Сценарий продолжения эксплуатации без поддержки применим только после проверки прав. Бессрочный ключ и истекшая подписная лицензия ведут себя по-разному. Убедитесь, что доступные операции позволяют восстановить критичные ВМ после отказа. Отсутствие платежа за продление не обнуляет расходы на эксплуатацию, безопасность и запасные компоненты.
Проверяют известные уязвимости конкретной версии ESXi и возможность получения исправлений. Новые GPU, сетевые карты и запасные серверы сверяют с матрицей совместимости. Если восстановление требует другого хоста, заранее испытывают подключение хранения и включение гостей на нем. Изоляция и мониторинг снижают отдельные риски, но не заменяют патч и не гарантируют безопасность.
Возможность временной эксплуатации оценивают по угрозам, правам, критичности сервисов и требованиям проекта. Назначают владельца решения, компенсирующие меры и срок пересмотра. Для регулируемых контуров отдельно проверяют нормы управления уязвимостями: общего разрешения на год-два без обновлений нет.
Миграцию рассматривают, если права или поддержка не покрывают необходимый срок эксплуатации. Альтернативы подробно сопоставлены в материале zVirt, Proxmox и Hyper-V. Здесь проверяют, какие ограничения текущей лицензии влияют на экспорт, резервные копии, API и окно переноса.
Как считать экономику решения
Сравнить три сценария помогает простая модель на горизонте 3-5 лет.
Продление оценивают по подтвержденной цене и составу прав. Дополнительно сравнивают сценарии доступности активации, обновлений и поддержки. Вероятности используют только как явно обозначенные допущения заказчика с указанным происхождением. Итоговую смету проверяют на чувствительность к недоступности канала поставки.
Продолжение работы без поддержки включает расходы на сопровождение, резервирование, запасные узлы и меры безопасности. Сценарии простоя оценивают по конкретным сервисам и времени восстановления. Универсальную вероятность блокировки ключа или одинаковый размер ущерба для всех организаций в расчет не подставляют.
Миграция включает разовые затраты на проект, консалтинг, лицензии новой платформы, обучение и оборудование параллельного контура. К ним добавляют расходы эксплуатации новой платформы на сопоставимом горизонте 3–5 лет.
Срок окупаемости рассчитывают по сопоставимым предложениям: дополнительные затраты миграции делят на ежегодную экономию. Учитывают параллельный контур, обучение, гостевые лицензии и резервное копирование. Если положительной экономии нет, срока окупаемости нет. Число ВМ не задает универсального решения или порога в 18–24 месяца.
Если решение в пользу перехода принято, дальше нужен расчет под целевую платформу: сервер для миграции с VMware подбирают исходя из требований новой системы виртуализации к процессору, памяти и сети, а не переносят конфигурацию vSphere один в один.
Пошаговый алгоритм действий
Что делать прямо сейчас, если подписка закончилась
- Инвентаризация начинается с ESXi и vCenter: версии, build, тип ключа, редакция, срок и назначенные ресурсы. Сверяют данные интерфейса лицензирования с договором и доступом к порталу. Затем фиксируют критичные функции, роли ВМ и зависимости. Различают дату окончания поддержки и дату окончания прав, чтобы не применить неверный сценарий.
- Для регулируемого контура определяют применимые требования к управлению уязвимостями и срокам устранения. Учитывают субъект, значимость объекта КИИ и модель угроз. Правила закрепляют в регламенте. Неназванный единый срок работы без патчей не является достаточным основанием для правового вывода.
- План строят по сроку прав и критичности операций. В отдельном тестовом контуре проверяют включение выключенной ВМ, доступ к хосту и vCenter, возможности резервного копирования и переноса. Пилот целевой платформы включает тест приложений и откат. Критичные гости не выключают ради проверки истекшей лицензии без подтвержденного пути восстановления.
- Усиление внешнего периметра: пока инфраструктура работает на VMware без обновлений, файрвол, IPS/IDS и мониторинг событий безопасности должны быть настроены максимально жестко. Они частично компенсируют невозможность закрывать уязвимости гипервизора патчами.
Типичные ошибки в этот период
Чаще всего компании спотыкаются на одних и тех же шагах.
- Откладывание решения до последнего: подписка кончилась, инженер надеется, что ситуация изменится сама, а время уходит без плана.
- Экстренная миграция за месяц: под давлением команда переносит критичные машины на новую платформу без тестов, и потом вылезают проблемы совместимости и производительности.
- Выбор новой платформы по репутации, без пилота: не учитывается, что нужный функционал, например снимки для баз данных или интеграция с СХД, реализован иначе.
- Экономия на дублирующем оборудовании при переходе: миграция идет на то же оборудование, и при отказе не остается пути отката.
- Забытая переподготовка команды: инженеры знают VMware, а на zVirt, Proxmox или Hyper-V нужны другие процедуры эксплуатации.
- Миграция без пересмотра архитектуры: инфраструктуру переносят как есть, не используя момент, чтобы оптимизировать размещение нагрузок.
- Серое продление без юридической оценки: риск получить претензию со стороны Broadcom или столкнуться с таможенными проблемами.
- Не проверено восстановление существующих копий на целевой платформе. Нужны поддерживаемая версия backup-системы, действующая лицензия и тест. Старым копиям назначают срок хранения и документируют ограничения, вместо общего вывода об их бесполезности.
Заключение
Действия после окончания лицензии определяет тип прав. У бессрочного ключа может закончиться только поддержка, а subscription и evaluation ограничивают операции ESXi и vCenter. Первые шаги — инвентаризация, проверка возможностей восстановления и согласованный план. Продление или миграцию выбирают по подтвержденным правам, рискам и смете, без универсального срока окупаемости.
Если компания остается на VMware и продлевает лицензию, или готовится к переходу на другую платформу, сервер под VMware ESXi подбирают под конкретную конфигурацию нагрузки, будь то поддержка текущей версии гипервизора или запас мощности на время миграции.