Развилка после vSphere

Последние месяцев восемь почти каждый разговор про инфраструктуру рано или поздно сворачивает в одну и ту же точку: «мы смотрим, куда уходить с VMware». Дальше обычно называется платформа — одна, уже выбранная где-то на стороне, — и задаётся единственный вопрос: сколько это будет стоить в железе.

Вопрос задан не тот. Цена железа здесь не самая интересная переменная и уж точно не первая. Первая — что именно вы меняете. Потому что меняете вы не гипервизор.

Этот выпуск — про пять вариантов замены и про то, что происходит с хранилищем и сетью, когда из схемы исчезает связка «ESXi плюс массив по Fibre Channel». Отправных точек тоже две, и они ведут в разные стороны: классика с внешним массивом и кластер на vSAN, где массива нет вовсе. Версии, статусы и поддерживаемые конфигурации проверены на сентябрь 2026 года: область меняется быстро, и верное прошлой осенью местами уже неверно.

Точка отсчёта

Сроки, а не цены

Начнём с календаря, потому что он определяет больше, чем любая смета. Продажи vSphere 8 по объявленному графику прекращаются в октябре 2026 года, общая поддержка заканчивается 11 октября 2027-го, а техническое сопровождение тянется до 11 октября 2029-го — но это уже консультации по существующим конфигурациям, а не поддержка. Отсюда обратный отсчёт: пилот на реальной нагрузке — квартал, миграция продуктива — от двух кварталов до года, стабилизация и обучение команды — ещё квартал. Решение принимается в 2026 году или в самом начале 2027-го, иначе оно будет приниматься под давлением срока, а это худший режим для архитектуры.

Коммерческая часть добавляет три обстоятельства. Лицензирование перешло на подписку по физическим ядрам с минимумом 16 ядер на процессор — сервер с восьмиядерником оплачивается как шестнадцатиядерный. Анонсированный минимум в 72 ядра на заказ после возражений рынка был отозван, но сам факт обсуждения показывает направление. И третье: держателям бессрочных лицензий с истёкшей поддержкой рассылаются письма о правомерности установки обновлений, а партнёрская программа для сервис-провайдеров переведена в режим по приглашениям, из-за чего в ряде стран сократился канал.

Кратность роста платежа при перезаключении называют очень разную — от полутора раз до порядка, — и зависит она прежде всего от скидки в предыдущем договоре. Считайте свой случай по своему ядру. Но разговор про уход начинается не из-за цены, а из-за того, что модель стала непредсказуемой на горизонте следующего продления, тогда как инфраструктура планируется на 3 года плюс 3 года второго круга.

Периметр замены

Меняется не гипервизор

Вот главная ошибка, которую мы видим в постановке задачи. Уход с VMware описывают как замену одного продукта на другой продукт. На деле меняется шесть слоёв сразу, и гипервизор среди них — самый простой.

Слой первый, вычисления: собственно гипервизор. Здесь всё решаемо — KVM под всеми вариантами работает давно и предсказуемо. Слой второй, управление. vCenter уходит, а с ним привычные объекты: пулы ресурсов, роли, папки, теги, правила размещения. Всё это собирается заново в чужой модели, и не всё переносится один в один.

Слой третий, хранилище, — самый тяжёлый, ему посвящены два раздела ниже. Слой четвёртый, сеть, — про неё забывают чаще всего, и о ней тоже отдельный раздел.

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

Слой шестой, про который в техническом задании не пишут: лицензии гостевых операционных систем и знания команды. OEM- и коробочные лицензии Windows Server привязаны к оборудованию и на новую платформу не переезжают — нужны корпоративные соглашения. Выяснять это лучше до подписания.

Варианты

Пять кандидатов

Коротко о том, что вообще есть на столе. Дальше каждый разбирается с точки зрения хранилища, сети и переиспользования.

Nutanix в классическом гиперконвергентном виде. Актуальная связка на сентябрь 2026 — AOS 7.6, AHV 11.2 и Prism Central 7.6, вышли в июле. Хранилище своё, распределённое: вычисления и ёмкость растут вместе.

Nutanix с внешней системой хранения. Отдельный лицензионный тип, кластер собирается только из вычислительных узлов, а ёмкость даёт квалифицированный внешний массив. Это принципиально другая архитектура, и в разделе про внешние массивы она разбирается подробно.

Red Hat OpenShift Virtualization. Виртуальные машины как объекты Kubernetes; текущая ветка платформы — 4.21. Тем, кому не нужна контейнерная часть, есть отдельная редакция только под виртуализацию, в неё включён инструмент миграции.

SUSE Virtualization, бывший Harvester. Текущая линейка — 1.8, актуальный патч 1.8.2. Тоже Kubernetes под капотом, собственное распределённое хранилище — SUSE Storage, он же Longhorn.

Proxmox VE. Версия 9.2 вышла в мае 2026 года: Debian 13.5, ядро 7.0, Ceph Tentacle 20.2.1 как хранилище по умолчанию и Ceph Squid как опция. Управление несколькими кластерами закрывается отдельным продуктом — Proxmox Datacenter Manager, первая стабильная версия которого появилась в конце 2025 года.

Транспорт

Сеть, о которой вспоминают последней

А теперь то, чего нет ни в одном коммерческом предложении на миграцию.

В классической схеме «ESXi плюс массив по Fibre Channel» трафик хранения жил в отдельной фабрике: выделен физически, ни с чем не конкурировал, в смету локальной сети не попадал вообще. Любой из пяти вариантов выше возвращает его в Ethernet — у гиперконвергентных схем как репликацию между узлами, у схем с внешним массивом как NVMe/TCP или NFS во фронтенде. Сеть перестаёт быть транспортом и становится шиной хранения, и оставить её прежней нельзя ни в одном из двух кейсов.

Сеть перестаёт быть транспортом и становится шиной хранения.

Считать надо не гигабиты на сервер, а полосу на ядро. Двухсокетный сервер 2015 года с 24 ядрами и парой 10-гигабитных портов — примерно 0,8 гигабита на ядро. Сегодняшний двухсокетник — это уже 172 ядра, два процессора по 86, и с той же парой портов получается 0,12. Память на узел доходит до 2, а местами и до 6 терабайт, диски ставятся по 15,36 терабайта. Плотность виртуальных машин выросла кратно, сеть осталась прежней.

Отсюда ступени. Переход с 10 на 25 гигабит сегодня — не апгрейд, а норма доступа: любой кластер с софтовым хранилищем или с блочным доступом поверх Ethernet проектируется от 25. Переход с 25 на 100 нужен тем, у кого за время жизни старого кластера появились новые потребители. Вот кого мы бы проверили первым.

Перестроение избыточности — главный и самый недооценённый потребитель полосы, но считать его надо аккуратно. Копии разложены по всем узлам, поэтому восстановление идёт многие-ко-многим: читается с разных узлов, пишется на разные, работает суммарная полоса кластера, а не один линк. И восстанавливается занятая ёмкость, а не паспортный объём диска. На живом кластере потеря диска закрывается за минуты и выглядит в графиках как всплеск, а не как сутки деградации.

Внимания стоят два других случая: отказ узла целиком, когда объём в разы больше, а полосы меньше — узел выбыл вместе со своими портами; и небольшой кластер на медленной сети, где схема ближе к «немногие ко многим». Избыточное кодирование дороже репликации: реконструкция читает несколько фрагментов с разных узлов. Проверять надо не «сколько часов это займёт», а какой пик даёт перестроение и с чем он конкурирует. Дальше: фронтенд к внешнему массиву — тот самый трафик, что раньше шёл по выделенной фабрике. Окно резервного копирования и, что важнее, окно восстановления: целевое время восстановления упирается в полосу, а не в систему копирования. Живая миграция при выводе узла на обслуживание — и здесь важно не ошибиться в порядке величин. По сети уезжает не установленная в узле память, а занятая память эвакуируемых машин, и уезжает не один раз: страницы копируются на работающей машине, затем досылаются изменённые, и так по кругу, пока остаток не станет достаточно мал для короткой паузы. Выделенная, но не тронутая память почти ничего не стоит; зато на активно пишущих машинах переданный объём заметно превышает занятый. Нижняя граница для узла на 6 терабайт, заполненного на две трети, — 4 терабайта. Диски при общем хранилище не двигаются: уезжает только память и состояние устройств.

Дальше нагрузки, появившиеся сами по себе, без связи с миграцией. Приватный интерконнект кластера Oracle RAC — там, правда, критична не столько полоса, сколько отсутствие потерь и стабильная задержка. Синхронная репликация крупных баз PostgreSQL с потоком журнала предзаписи. Перебалансировка разделов Kafka и обмен промежуточными данными в Spark. Перестроение индексов в поисковых кластерах. Выгрузка в объектный ярус. Загрузка датасетов и запись контрольных точек, если рядом появился сегмент с графическими ускорителями. Утренний массовый запуск рабочих мест виртуальных столов. И репликация между площадками, если катастрофоустойчивость перевели с суточного режима на близкий к синхронному.

Отдельно про физику, потому что она ломает бюджет тише всего, и тут важно не путать два разных парка. Если доступ собран на SFP+ — а так собрано большинство серверных инсталляций, — переход выглядит терпимо: порты SFP28 принимают старые модули на 10 гигабит, многомодовая разводка под 25 гигабит обычно годится, хотя запас по длине меньше, и площадку можно переводить частями. Менять всё равно придётся карты и коммутаторы доступа, а вот оптику и трассы — не обязательно. Если же доступ на витой паре, всё жёстче: 25 гигабит по RJ45 на практике не живут, промежуточной ступени нет, и парк 10GBASE-T меняется целиком, вместе с кабельной системой. Дальше по цепочке: аплинки, отдельная фабрика под хранение или хотя бы разделение очередей, сквозной MTU по всему пути — классическое место, где рассыпается производительность блочного доступа поверх Ethernet, — буферы коммутаторов при одновременном ответе многих реплик одному инициатору. И переход к leaf-spine, потому что горизонтальный трафик становится основным.

Оговорка, чтобы не обещать лишнего: 100 гигабит не лечат задержку. Они сокращают время передачи кадра и убирают очереди, но круговая задержка определяется стеком, коммутацией и поведением приложения при записи.

Софтовое хранилище

Хранилище внутри платформы

Первый из двух больших вопросов: отказываться ли от массива вообще и жить на дисках внутри серверов.

У Nutanix это распределённая файловая система с фактором репликации 2 или 3. Технология зрелая, и грабли известны: полезная ёмкость считается после репликации, а не до неё, и об этом каждый раз отдельный разговор с финансистами.

У OpenShift Virtualization встроенное хранилище — это OpenShift Data Foundation. Во внутреннем режиме — Ceph, развёрнутый внутри кластера через Rook, на дисках узлов. Во внешнем — подключение к отдельно управляемому Ceph. Второй вариант честнее для крупных инсталляций, но означает ещё одну систему, которую надо уметь эксплуатировать.

У Proxmox встроенный Ceph, в версии 9.2 по умолчанию Tentacle. Здесь важно понимать: Ceph — не функция гипервизора, а самостоятельная распределённая система со своей моделью отказов и своими требованиями к числу узлов. Три узла — лабораторный минимум, а не проектная величина.

У SUSE Virtualization по умолчанию SUSE Storage, он же Longhorn, движок первой версии. Есть движок второй версии на SPDK с доступом по NVMe-oF — он заметно быстрее, и в апстриме, в Longhorn 1.12, объявлен общедоступным. Но в документации SUSE Virtualization 1.8 он по-прежнему помечен как экспериментальный и не для продуктивной эксплуатации: не поддерживаются образы-подложки и шифрование тома, а каждому узлу нужны выделенное ядро и 2 гигабайта huge pages. Планировать на него продуктив в сентябре 2026 года мы бы не стали.

И ещё одно, о чём вспоминают в последний момент: кластеру часто суждено стать мультизадачным. Кроме машин от него хотят файловые шары для пользователей и объектное хранилище под бэкапы или архив. Формально файловый и объектный доступ есть почти у всех: у OpenShift через ODF это CephFS и шлюзы RGW и NooBaa, у Proxmox — CephFS, а объектный шлюз поднимается руками мимо интерфейса. Но это хранилище для самого кластера и для подов, а не файловый сервер для людей.

Если нужны корпоративные сервисы для внешних потребителей — SMB с интеграцией в домен, мультипротокольный доступ, квоты, аналитика обращений и срабатывание на шифровальщика, объектное хранилище с версионированием и блокировкой объектов, — и всё это из той же консоли и с одной поддержкой, то из пяти вариантов такое собрано только у Nutanix, в Unified Storage. У остальных это конструктор из отдельных компонентов, каждый со своим жизненным циклом. Оговорки обязательны: лицензируется отдельно и по ёмкости, файловые серверы живут как машины на том же кластере и едят его ресурсы и ёмкость после репликации, а на связке из compute-only узлов с внешним массивом это проверяется отдельно, а не считается данностью.

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

Внешние СХД

Внешний массив: что подключается сейчас

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

Начнём с того, что чаще всего становится сюрпризом. Nutanix с внешней системой хранения принципиально не поддерживает Fibre Channel — ни сейчас, ни в планах. Всё идёт по Ethernet: NVMe/TCP, NFS или собственный протокол массива. Кластер собирается исключительно из вычислительных узлов, смешивать их с гиперконвергентными в одном кластере нельзя, лицензирование идёт по ядрам, а снапшоты и клоны выполняет сам массив. Квалифицированные системы на сентябрь 2026 года: Dell PowerFlex — минимум четыре узла хранения, конфигурация полностью на оборудовании Dell и подключение через собственный клиент SDC, а не NVMe/TCP; FlashArray от Pure Storage, ныне Everpure, модели //X, //XL и добавленная в 2026 году //C; Dell PowerStore, добавленный в июле 2026 года начиная с AOS 7.6 — поколения с первого по третье кроме модели X, только как одиночный кластер-аплайнс, подключение от 10 гигабит. NetApp ONTAP — в раннем доступе, общая доступность заявлена вендором на третий квартал 2026 года, подключение по NFS, из систем названы AFF A-серии и часть гибридных FAS; примерно в те же сроки обещана поддержка систем хранения Lenovo. Проще говоря, Fibre Channel здесь — не деталь подключения, а развилка выбора платформы.

Fibre Channel здесь — не деталь подключения, а развилка выбора платформы.

У OpenShift Virtualization внешнее хранилище подключается через сторонние драйверы CSI, и ключевой критерий отбора драйвера — поддержка режима одновременного доступа к блочному тому с нескольких узлов. Без него не будет живой миграции, и это первое, что надо проверять в спецификации драйвера, а не в презентации. Классическая фабрика Fibre Channel подключается не напрямую: для этого существует отдельный продукт IBM Fusion Access for SAN, позволяющий использовать имеющиеся SAN, по сути кластерная файловая система поверх LUN. Это работает, но это ещё одна лицензия и ещё одна система в эксплуатации.

У SUSE Virtualization сторонние драйверы CSI поддерживаются, в том числе для корневых томов, а в июле 2026 года появилась собственная программа сертификации хранилищ для виртуализации. Но здесь зарыта мина, которую надо знать до выбора платформы: штатное резервное копирование виртуальных машин работает только с томами Longhorn первой версии. Для томов на внешнем хранилище платформа не умеет ни создавать копии, ни восстанавливать их — это прямо написано в документации. Значит, весь бэкап уезжает во внешний продукт, и его совместимость проверяется отдельно. Плюс мелочи, всплывающие на монтаже: служба многопутевого доступа на узлах по умолчанию выключена, а операционная система иммутабельная, поэтому подготовка узлов делается через механизм начальной конфигурации на каждом хосте.

У Proxmox существующая фабрика подключается штатно: LUN отдаётся узлам, поверх собирается LVM. Долгие годы главным ограничением было отсутствие снапшотов на такой схеме. В версии 9 это закрыли — снапшоты реализованы как цепочки томов и работают на толстых LVM поверх iSCSI и Fibre Channel. Но и в 9.2 статус функции — всё ещё технологическое превью; вывод её из этого статуса стоит в планах разработчиков, но даты нет. Официально поддерживаемой кластерной файловой системы у платформы по-прежнему нет.

География

Две-три площадки

В нашей практике одноплощадочных заказчиков почти не осталось: две площадки — норма, три — регулярность. И это не деталь внедрения, а условие выбора платформы, потому что расходятся варианты здесь сильнее, чем по любому другому пункту.

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

Расклад по вариантам. У Nutanix это собрано в одном продукте и управляется из одной консоли: синхронная репликация между двумя площадками, асинхронная на третью, планы восстановления с тестовым запуском. Плюс файловые и объектные сервисы реплицируются той же механикой — если кластеру суждено стать мультизадачным, второй площадке это тоже касается.

Если вы остаётесь на VMware, многоплощадочная схема у вас уже есть и работает — это исторически сильная сторона платформы, и терять её при переезде обиднее всего.

У OpenShift всё это достижимо, но собирается из нескольких продуктов: отдельный слой управления множеством кластеров, отдельные режимы катастрофоустойчивости для растянутой и для асинхронной схемы, требования к задержке между площадками. Работает, но проектируется и эксплуатируется заметно сложнее.

У SUSE Virtualization управление несколькими кластерами закрывается штатно, а вот штатной репликации машин между площадками нет: остаётся резервное копирование во внешнее хранилище и восстановление на второй площадке. Для катастрофоустойчивости с коротким временем восстановления этого мало.

У Proxmox центральный диспетчер даёт общий обзор и живую миграцию между кластерами, но связывает площадки слабо: каждый кластер остаётся автономным, общей конфигурации нет, автоматического переключения между площадками нет тоже. Репликация между площадками собирается руками из механизмов хранилища и синхронизации сервера резервного копирования.

И предупреждение, общее для всех. Растянутый кластер на две площадки требует канала с гарантированной задержкой и третьей точки для кворума. Две площадки без свидетеля — это не отказоустойчивость, это два места, где всё может встать одновременно.

Существующий парк

Что переезжает из того, что есть

Ситуация более частая: серверам 2–4 года, массив свежий, фабрика на 32 гигабита, и заказчик резонно не хочет всё это выбрасывать из-за чужой лицензионной политики.

Если вы уходите с vSAN

Здесь расклад другой и в целом проще. Массива нет — развилка с Fibre Channel исчезает вместе с ним, а вариант с внешней системой хранения отпадает, если только заказчик заодно не решил уйти от гиперконвергенции. Выбор сужается до «одна гиперконвергенция вместо другой».

Парк при этом переезжает лучше, чем в любом другом кейсе: узлы, локальные NVMe, сеть хранения, если она уже 25 гигабит, и сама топология проектировались под распределённое хранилище и под него же и уедут. Менять надо софт, а не железо.

Плохая новость одна, зато крупная: конвертации vSAN в другое распределённое хранилище на месте не существует. Данные перекладываются целиком, и, в отличие от схемы с массивом, нет промежуточного общего хранилища, которое можно подцепить к обеим платформам и переносить машины по одной, не копируя диски. Весь объём идёт по сети — и раздел про полосу превращается из теории в расчёт срока проекта.

И две вещи, которые теряются молча. Политики хранения на уровне отдельной машины: прямого аналога нет ни у кого, избыточность в других платформах задаётся грубее. И растянутый кластер с узлом-свидетелем: он не переезжает, а собирается заново по чужим правилам и с другими требованиями к задержке между площадками.

Что переезжает хорошо. Серверы — почти всегда: списки совместимости широкие, у Nutanix для вычислительных узлов он уходит до поколений 2017 года. Диски NVMe и SSD — если они в списках, а не безымянные. Массив — если умеет отдавать ёмкость по нужному протоколу. Знания команды по гостевым системам и приложениям — полностью.

Что переезжает с оговорками. Существующая фабрика Fibre Channel: в схеме с Nutanix на внешнем хранилище она не переезжает вообще, у OpenShift требует отдельного продукта, у Proxmox работает, но со снапшотами в статусе превью, у SUSE — через сторонний драйвер, но тогда вы теряете штатное резервное копирование. Массив с интерфейсом только Fibre Channel: иногда спасает добавление Ethernet-портов, если модель это поддерживает, иногда нет. Сеть доступа на витой паре: не переезжает, меняется.

Что не переезжает никогда. Лицензии гостевых Windows, купленные как OEM. Правила распределения нагрузки, завязанные на объекты старого управляющего сервера. И привычка команды, что снапшот, клон и восстановление делаются в одном месте и одним способом.

И предупредим про соблазн гибрида: часть нагрузки оставить на старой платформе, часть перенести. На практике вы год держите две платформы, два бэкапа, два мониторинга и два набора компетенций — и платите за лицензии на обеих. Переходный период нужен, но с датой окончания в плане.

Миграция

Инструменты переезда и обвязка

Инструменты миграции есть у всех, и все делают одно: читают диски машины из старой среды, конвертируют формат, создают объект в новой.

У Nutanix это Move, самый обкатанный из всех; там же появилось преобразование без копирования данных — тома vVols превращаются в диски AHV на месте. У Red Hat — migration toolkit for virtualization, где в версии 2.11 разгрузка копирования на массив доведена до общей доступности: данные переносит сам массив, а не сеть. Плюс тёплая миграция, когда основной объём копируется на работающей машине. Для скорости нужен комплект разработчика виртуальных дисков от VMware, и собирать образ с ним придётся самостоятельно — выкладывать его в публичный реестр лицензия не позволяет. У SUSE Virtualization — дополнение vm-import-controller с источниками vSphere и OpenStack, с неочевидной особенностью: имя машины становится именем объекта Kubernetes, и машины с именами не по правилам именования импортируются с ошибкой. У Proxmox — мастер импорта из ESXi, тоже технологическое превью, с ограничениями по vSAN и просадкой скорости при работе через управляющий сервер.

Но инструмент — это полдня работы на машину, а обвязка — месяцы. Что проверить до выбора платформы.

Резервное копирование: поддерживает ли ваш продукт целевую платформу, на каком уровне — образ целиком или изменённые блоки — и что с восстановлением отдельных файлов. Если платформа SUSE и тома внешние, штатного бэкапа нет вообще.

И отдельная строка бюджета, которую пропускают почти все: обучение. Не «прочитать документацию», а курс с практикой до запуска. Мы такие курсы проводим сами и видим разницу в числе обращений в поддержку в первые полгода.

Чек-лист

Что спросить до того, как выбирать платформу

Итог

Вместо вывода

Уход с VMware — не покупка другого гипервизора, а перепроектирование инфраструктуры целиком, просто с сохранением рабочих нагрузок. Тот, кто считает эту задачу заменой лицензий, обнаруживает остальные пять слоёв в процессе — обычно в самый неподходящий момент.

Правильных ответов несколько. Есть площадки, где свежий массив и фабрика делают Proxmox или OpenShift очевидным выбором. Есть те, где отсутствие поддержки Fibre Channel снимает половину вариантов. Есть те, где решает не техника, а наличие поддержки и компетенций в стране. Выбор платформы должен выпадать из ограничений, а не из презентации.

За рамками остались три темы, каждая на отдельный разбор: сценарий «остаться» на VVF 9 или VCF 9, строительство с нуля и судьба Kubernetes — Tanzu уходит вместе с vSphere.

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