01

Точка отсчётаТочка відлікуThe starting point

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

Строки, а не ціни

Dates, not prices

Дата окончания поддержки определяет график сильнее любой сметы: решение принимается в 2026 году, иначе оно принимается под давлением.

Дата закінчення підтримки визначає графік сильніше за будь-який кошторис: рішення ухвалюється у 2026 році, інакше воно ухвалюється під тиском.

The end-of-support date drives the schedule harder than any estimate: the decision is taken in 2026, or it is taken under pressure.

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

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

I start with the calendar, because it decides more than any estimate. Sales of vSphere 8 end in October 2026 on the announced schedule, general support ends on 11 October 2027, and technical guidance runs to 11 October 2029 — but by then it is advice on existing configurations, not support. Counting backwards: a pilot on real workloads takes a quarter, migrating production takes two quarters to a year, and stabilising plus training the team takes another quarter. The decision is taken in 2026 or at the very start of 2027; otherwise it is taken under deadline pressure, which is the worst possible mode for architecture.

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

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

The commercial side adds three circumstances. Licensing moved to a subscription counted by physical cores with a minimum of 16 cores per processor — a server with an eight-core part is billed as sixteen. An announced minimum of 72 cores per order was withdrawn after market objections, but the fact that it was floated shows the direction. And third: holders of perpetual licences with lapsed support have been receiving letters about the legality of installing updates, while the partner programme for service providers moved to invitation-only, thinning the channel in a number of countries.

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

Кратність зростання платежу при переукладенні називають дуже різну — від півтора раза до порядку, — і залежить вона передусім від знижки в попередньому договорі. Рахуйте свій випадок за своїм ядром. Але розмова про відхід починається не через ціну, а через те, що модель стала непередбачуваною на горизонті наступного продовження, тоді як інфраструктура планується на 3 роки плюс 3 роки другого кола.

The multiple by which payments rise on renewal is quoted very differently — from one and a half times to an order of magnitude — and it depends above all on the discount in the previous contract. Work out your own case on your own core count. But the conversation about leaving starts not because of price, but because the model became unpredictable at the horizon of the next renewal, whereas infrastructure is planned over 3 years plus 3 of a second cycle.

02

Периметр заменыПериметр заміниThe scope of the replacement

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

Змінюється не гіпервізор

It is not the hypervisor that changes

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

Змінюється шість шарів одразу, і гіпервізор серед них — найпростіший. Провали трапляються в управлінні, обв’язці та мережі.

Six layers change at once, and the hypervisor is the simplest of them. Things fail in management, in the surrounding systems and in the network.

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

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

Here is the main error I see in how the task is framed. Leaving VMware is described as swapping one product for another. In reality six layers change at once, and the hypervisor is the simplest of them.

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

Шар перший, обчислення: власне гіпервізор. Тут усе вирішувано — KVM під усіма варіантами працює давно і передбачувано. Шар другий, управління. vCenter іде, а з ним звичні об’єкти: пули ресурсів, ролі, теки, теги, правила розміщення. Усе це збирається заново в чужій моделі, і не все переноситься один в один.

Layer one, compute: the hypervisor itself. Everything here is solvable — KVM under all of the options has worked predictably for years. Layer two, management. vCenter goes, and with it the familiar objects: resource pools, roles, folders, tags, placement rules. All of that is rebuilt inside somebody else’s model, and not all of it maps one to one.

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

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

Layer three, storage, is the heaviest; two sections below are devoted to it. Layer four, the network, is the most often forgotten, and it has a section of its own too.

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

Шар п’ятий, обв’язка: резервне копіювання, катастрофостійкість, моніторинг, інтеграції із системами інформаційної безпеки, агенти, автоматизація. Кожен пункт — окрема перевірка за матрицею сумісності, і провали трапляються саме тут.

Layer five, the surrounding systems: backup, disaster recovery, monitoring, security integrations, agents, automation. Each item is a separate check against a compatibility matrix, and this is exactly where things fail.

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

Шар шостий, про який у технічному завданні не пишуть: ліцензії гостьових операційних систем і знання команди. OEM- та коробкові ліцензії Windows Server прив’язані до обладнання і на нову платформу не переїжджають — потрібні корпоративні угоди. З’ясовувати це краще до підписання.

Layer six, the one never written into a specification: guest operating system licences and the team’s knowledge. OEM and retail Windows Server licences are tied to the hardware and do not move to a new platform — you need volume agreements. Better to establish that before signing.

03

ВариантыВаріантиThe options

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

П’ять кандидатів

Five candidates

Что реально стоит на столе в сентябре 2026 года — с версиями, а не с обещаниями из презентаций.

Що реально стоїть на столі у вересні 2026 року — з версіями, а не з обіцянками з презентацій.

What is actually on the table in September 2026 — with versions rather than promises from slide decks.

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

Коротко про те, що взагалі є на столі. Далі кожен розбирається з погляду сховища, мережі та переви́користання.

Briefly, what is on the table at all. Each option is then examined from the angle of storage, networking and reuse.

• 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 года.

• 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 року.

• Nutanix in its classic hyperconverged form. The current combination as of September 2026 is AOS 7.6, AHV 11.2 and Prism Central 7.6, released in July. Storage is its own and distributed: compute and capacity grow together.
• Nutanix with external storage. A separate licence type: the cluster is built from compute-only nodes, and capacity comes from a qualified external array. This is a fundamentally different architecture.
• Red Hat OpenShift Virtualization. Virtual machines as Kubernetes objects; the current platform branch is 4.21. For those who do not need the container side there is a virtualisation-only edition, with the migration tool included.
• SUSE Virtualization, formerly Harvester. The current line is 1.8, latest patch 1.8.2. Kubernetes under the hood again, with its own distributed storage — SUSE Storage, also known as Longhorn.
• Proxmox VE. Version 9.2 arrived in May 2026: Debian 13.5, kernel 7.0, Ceph Tentacle 20.2.1 as the default storage and Ceph Squid as an option. Managing several clusters is handled by a separate product, Proxmox Datacenter Manager, whose first stable release came at the end of 2025.

04

ТранспортТранспортTransport

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

Мережа, про яку згадують останньою

The network nobody remembers until last

Трафик хранения возвращается из выделенной фабрики в Ethernet. Считать надо не гигабиты на сервер, а полосу на ядро.

Трафік зберігання повертається з виділеної фабрики в Ethernet. Рахувати треба не гігабіти на сервер, а смугу на ядро.

Storage traffic comes back out of the dedicated fabric into Ethernet. The figure to count is not gigabits per server but bandwidth per core.

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

А тепер те, чого немає в жодній комерційній пропозиції на міграцію.

And now the thing that appears in no migration proposal at all.

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

У класичній схемі «ESXi плюс масив по Fibre Channel» трафік зберігання жив у окремій фабриці: виділений фізично, ні з чим не конкурував, у кошторис локальної мережі не потрапляв узагалі. Будь-який із п’яти варіантів вище повертає його в Ethernet — у гіперконвергентних схем як реплікацію між вузлами, у схем із зовнішнім масивом як блоковий доступ або NFS у фронтенді. Мережа перестає бути транспортом і стає шиною зберігання, і залишити її колишньою не можна в жодному з двох кейсів.

In the classic “ESXi plus an array over Fibre Channel” design, storage traffic lived in a separate fabric: physically dedicated, competing with nothing, and absent from the LAN budget entirely. Every one of the five options above brings it back into Ethernet — as inter-node replication in the hyperconverged designs, and as block access or NFS on the front end in the external-array ones. The network stops being transport and becomes the storage bus, and in neither case can it be left as it was.

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

Мережа перестає бути транспортом і стає шиною зберігання.

The network stops being transport and becomes the storage bus.

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

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

The figure to count is not gigabits per server but bandwidth per core. A dual-socket server from 2015 with 24 cores and a pair of 10-gigabit ports gives about 0.8 gigabits per core. A dual-socket machine today means 172 cores, two processors of 86 each, and with the same pair of ports that comes to 0.12. Memory per node reaches 2 terabytes and in places 6, and drives go in at 15.36 terabytes. VM density has grown many times over; the network has stayed where it was.

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

Звідси ступені. Перехід із 10 на 25 гігабіт сьогодні — не апгрейд, а норма доступу: будь-який кластер із софтовим сховищем або з блоковим доступом поверх Ethernet проєктується від 25. Перехід із 25 на 100 потрібен тим, у кого за час життя старого кластера з’явилися нові споживачі.

Hence the steps. Moving from 10 to 25 gigabits today is not an upgrade but the access baseline: any cluster with software-defined storage or block access over Ethernet is designed from 25 up. Moving from 25 to 100 is for those who acquired new consumers over the life of the old cluster.

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

Перебудова надмірності — головний і найбільш недооцінений споживач смуги, але рахувати його треба акуратно. Копії розкладені по всіх вузлах, тому відновлення йде багато-до-багатьох: читається з різних вузлів, пишеться на різні, працює сумарна смуга кластера, а не один лінк. І відновлюється зайнята ємність, а не паспортний обсяг диска. На живому кластері втрата диска закривається за хвилини і виглядає в графіках як сплеск, а не як доба деградації.

The redundancy rebuild is the single largest and most underestimated consumer of bandwidth, but it has to be counted carefully. Copies are spread across all nodes, so recovery runs many-to-many: reads come from various nodes, writes go to various nodes, and the cluster’s aggregate bandwidth is at work rather than one link. And what is rebuilt is the used capacity, not the drive’s nameplate size. On a live cluster the loss of a drive is resolved in minutes and shows up on the graphs as a spike rather than a day of degradation.

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

Уваги варті два інші випадки: відмова вузла цілком, коли обсяг у рази більший, а смуги менше — вузол вибув разом зі своїми портами; і невеликий кластер на повільній мережі, де схема ближча до «небагато до багатьох». Надмірне кодування дорожче за реплікацію: реконструкція читає кілька фрагментів із різних вузлів. Перевіряти треба не «скільки годин це займе», а який пік дає перебудова і з чим він конкурує.

Two other cases deserve attention: the loss of an entire node, where the volume is several times larger and the bandwidth smaller — the node left along with its ports; and a small cluster on a slow network, where the pattern is closer to few-to-many. Erasure coding costs more than replication: reconstruction reads several fragments from different nodes. What to check is not “how many hours will this take” but what peak the rebuild produces and what it competes with.

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

Далі: фронтенд до зовнішнього масиву — той самий трафік, що раніше йшов виділеною фабрикою. Вікно резервного копіювання і, що важливіше, вікно відновлення: цільовий час відновлення впирається у смугу, а не в систему копіювання. Жива міграція при виведенні вузла на обслуговування — і тут важливо не помилитися в порядку величин. Мережею їде не встановлена у вузлі пам’ять, а зайнята пам’ять машин, що евакуюються, і їде не один раз: сторінки копіюються на працюючій машині, потім досилаються змінені, і так по колу, поки залишок не стане достатньо малим для короткої паузи. Виділена, але не зачеплена пам’ять майже нічого не коштує; натомість на активно пишучих машинах переданий обсяг помітно перевищує зайнятий. Нижня межа для вузла на 6 терабайтів, заповненого на дві третини, — 4 терабайти. Диски при спільному сховищі не рухаються: їде лише пам’ять і стан пристроїв.

Then: the front end to the external array — the very traffic that used to run over the dedicated fabric. The backup window and, more importantly, the restore window: the recovery-time target is bounded by bandwidth, not by the backup system. Live migration when draining a node for maintenance — and here it is important not to be out by an order of magnitude. What crosses the network is not the memory installed in the node but the used memory of the machines being evacuated, and it crosses more than once: pages are copied while the machine runs, then the changed ones are sent after, and round again until the remainder is small enough for a brief pause. Allocated but untouched memory costs almost nothing; on actively writing machines, though, the transferred volume noticeably exceeds the used amount. The lower bound for a 6-terabyte node two-thirds full is 4 terabytes. Disks do not move when storage is shared: only memory and device state travel.

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

Окремо про фізику, бо вона ламає бюджет найтихіше, і тут важливо не плутати два різні парки. Якщо доступ зібраний на SFP+ — а так зібрана більшість серверних інсталяцій, — перехід виглядає терпимо: порти SFP28 приймають старі модулі на 10 гігабіт, багатомодова розводка під 25 гігабіт зазвичай годиться, хоча запас за довжиною менший, і майданчик можна переводити частинами. Міняти однаково доведеться карти і комутатори доступу, а от оптику і траси — не обов’язково. Якщо ж доступ на витій парі, все жорсткіше: 25 гігабіт по RJ45 на практиці не живуть, проміжного ступеня немає, і парк 10GBASE-T змінюється цілком, разом із кабельною системою.

A separate word on the physical layer, because it breaks budgets more quietly than anything, and here it matters not to confuse two different estates. If access is built on SFP+ — as most server installations are — the transition looks tolerable: SFP28 ports accept the old 10-gigabit modules, multimode cabling is usually good for 25 gigabits although the length margin is smaller, and the site can be converted in stages. Cards and access switches will have to change regardless, but the optics and the cable runs need not. If access is on twisted pair, it is harsher: 25 gigabits over RJ45 does not work in practice, there is no intermediate step, and the 10GBASE-T estate is replaced wholesale, cabling included.

Дальше по цепочке: аплинки, отдельная фабрика под хранение или хотя бы разделение очередей, сквозной MTU по всему пути — классическое место, где рассыпается производительность блочного доступа поверх Ethernet, — буферы коммутаторов при одновременном ответе многих реплик одному инициатору. И переход к leaf-spine, потому что горизонтальный трафик становится основным.

Далі по ланцюжку: аплінки, окрема фабрика під зберігання або хоча б розділення черг, наскрізний MTU по всьому шляху — класичне місце, де розсипається продуктивність блокового доступу поверх Ethernet, — буфери комутаторів при одночасній відповіді багатьох реплік одному ініціатору. І перехід до leaf-spine, бо горизонтальний трафік стає основним.

Further down the chain: uplinks; a separate fabric for storage or at least queue separation; a consistent MTU end to end along the whole path — the classic place where block-over-Ethernet performance falls apart; and switch buffers when many replicas answer one initiator at once. Plus the move to leaf-spine, because east-west traffic becomes the dominant kind.

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

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

A caveat, so as not to promise too much: 100 gigabits does not cure latency. It shortens frame transmission time and clears queues, but round-trip latency is set by the stack, the switching and the application’s write behaviour.

05

Софтовое хранилищеСофтове сховищеSoftware-defined storage

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

Сховище всередині платформи

Storage inside the platform

Отказ от массива оплачивается полезной ёмкостью, сетью и ресурсами узлов. И отдельный вопрос — файловые и объектные сервисы.

Відмова від масиву оплачується корисною ємністю, мережею і ресурсами вузлів. І окреме питання — файлові та об’єктні сервіси.

Giving up the array is paid for in usable capacity, in network and in node resources. And file and object services are a separate question.

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

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

The first of the two big questions: whether to give up the array altogether and live on the disks inside the servers.

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

У Nutanix це розподілена файлова система з фактором реплікації 2 або 3. Технологія зріла, і граблі відомі: корисна ємність рахується після реплікації, а не до неї, і про це щоразу окрема розмова з фінансистами.

With Nutanix this is a distributed filesystem with a replication factor of 2 or 3. The technology is mature and the pitfall is well known: usable capacity is counted after replication, not before, and that is a separate conversation with the finance people every time.

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

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

In OpenShift Virtualization the built-in storage is OpenShift Data Foundation. In internal mode that is Ceph deployed inside the cluster through Rook, on the nodes’ disks. In external mode it connects to a separately managed Ceph. The second option is the honest one for large installations, but it means another system you have to be able to operate.

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

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

Proxmox has built-in Ceph, with Tentacle as the default in version 9.2. It matters to understand that Ceph is not a hypervisor feature but a distributed system in its own right, with its own failure model and its own node-count requirements. Three nodes is a lab minimum, not a design figure.

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

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

SUSE Virtualization defaults to SUSE Storage, also known as Longhorn, on the v1 engine. There is a v2 engine on SPDK with NVMe-oF access — noticeably faster, and declared generally available upstream in Longhorn 1.12. But in the SUSE Virtualization 1.8 documentation it is still marked experimental and not for production: backing images and volume encryption are unsupported, and each node needs a dedicated core and 2 gigabytes of huge pages. I would not plan production on it in September 2026.

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

І ще одне, про що згадують в останній момент: кластеру часто судилося стати мультизадачним. Крім машин від нього хочуть файлові шари для користувачів і об’єктне сховище під бекапи чи архів. Формально файловий та об’єктний доступ є майже у всіх: у OpenShift через ODF це CephFS і об’єктні шлюзи, у Proxmox — CephFS, а об’єктний шлюз піднімається руками повз інтерфейс. Але це сховище для самого кластера і для подів, а не файловий сервер для людей.

And one more thing remembered at the last moment: a cluster is often destined to become multi-purpose. Beyond virtual machines, people want file shares for users and object storage for backups or an archive from it. Formally, almost everyone has file and object access: in OpenShift through ODF that is CephFS and object gateways, in Proxmox it is CephFS with the object gateway brought up by hand outside the interface. But this is storage for the cluster itself and for its pods, not a file server for people.

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

Якщо потрібні корпоративні сервіси для зовнішніх споживачів — SMB з інтеграцією в домен, мультипротокольний доступ, квоти, аналітика звернень і спрацювання на шифрувальника, об’єктне сховище з версіонуванням і блокуванням об’єктів, — і все це з тієї самої консолі та з однією підтримкою, то з п’яти варіантів таке зібрано лише в Nutanix, у Unified Storage. У решти це конструктор з окремих компонентів, кожен зі своїм життєвим циклом. Застереження обов’язкові: ліцензується окремо і за ємністю, файлові сервери живуть як машини на тому самому кластері і їдять його ресурси та ємність після реплікації, а на зв’язці з обчислювальних вузлів із зовнішнім масивом це перевіряється окремо, а не вважається даністю.

If you need enterprise services for external consumers — SMB with domain integration, multiprotocol access, quotas, access analytics and ransomware detection, object storage with versioning and object lock — and all of it from the same console with a single support contract, then of the five options only Nutanix has it assembled, in Unified Storage. For the others it is a kit of separate components, each with its own lifecycle. The caveats are mandatory: it is licensed separately and by capacity, the file servers run as machines on the same cluster and consume its resources and its post-replication capacity, and on a compute-only-plus-external-array combination this has to be verified separately rather than assumed.

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

Спільне для всіх чотирьох: софтове сховище — не «безкоштовний масив». Платити за нього доводиться тричі. Корисною ємністю: реплікація або надмірне кодування з’їдають від третини до двох третин сирого обсягу. Мережею, про яку був попередній розділ. І процесорним часом та пам’яттю вузлів, які йдуть не на віртуальні машини.

Common to all four: software-defined storage is not a “free array”. You pay for it three times over. In usable capacity: replication or erasure coding eats a third to two thirds of the raw volume. In network, which the previous section was about. And in the CPU time and memory of the nodes, which then do not go to virtual machines.

06

Внешние СХДЗовнішні СЗДExternal storage

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

Зовнішній масив: що підключається зараз

The external array: what connects today

Главная развилка — протокол. Fibre Channel поддерживают не все, и это снимает часть вариантов до разговора о цене.

Головна розвилка — протокол. Fibre Channel підтримують не всі, і це знімає частину варіантів до розмови про ціну.

The main fork is the protocol. Not everyone supports Fibre Channel, and that removes options before price comes up.

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

Друге велике питання, і для більшості моїх замовників — вирішальне, бо масив у них уже є і списувати його ніхто не збирається.

The second big question, and for most of my customers the decisive one, because they already have an array and nobody intends to write it off.

Начну с того, что чаще всего становится сюрпризом. Nutanix с внешней системой хранения принципиально не поддерживает Fibre Channel — ни сейчас, ни в планах. Всё идёт по Ethernet: блочный доступ, NFS или собственный протокол массива. Кластер собирается исключительно из вычислительных узлов, смешивать их с гиперконвергентными в одном кластере нельзя, лицензирование идёт по ядрам, а снапшоты и клоны выполняет сам массив.

Почну з того, що найчастіше стає сюрпризом. Nutanix із зовнішньою системою зберігання принципово не підтримує Fibre Channel — ні зараз, ні в планах. Усе йде по Ethernet: блоковий доступ, NFS або власний протокол масиву. Кластер збирається виключно з обчислювальних вузлів, змішувати їх із гіперконвергентними в одному кластері не можна, ліцензування йде за ядрами, а снапшоти і клони виконує сам масив.

I will start with what most often comes as a surprise. Nutanix with external storage does not support Fibre Channel as a matter of principle — not now and not on the roadmap. Everything goes over Ethernet: block access, NFS or the array’s own protocol. The cluster is built exclusively from compute nodes, mixing them with hyperconverged ones in a single cluster is not allowed, licensing is by cores, and snapshots and clones are performed by the array itself.

Квалифицированные системы на сентябрь 2026 года: Dell PowerFlex — минимум четыре узла хранения, конфигурация полностью на оборудовании Dell и подключение через собственный клиент, а не стандартный блочный протокол; 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 здесь — не деталь подключения, а развилка выбора платформы.

Кваліфіковані системи на вересень 2026 року: Dell PowerFlex — мінімум чотири вузли зберігання, конфігурація повністю на обладнанні Dell і підключення через власний клієнт, а не стандартний блоковий протокол; 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 тут — не деталь підключення, а розвилка вибору платформи.

Qualified systems as of September 2026: Dell PowerFlex — at least four storage nodes, an all-Dell hardware configuration, and connection through its own client rather than a standard block protocol; Pure Storage FlashArray, now Everpure, models //X, //XL and the //C added in 2026; Dell PowerStore, added in July 2026 from AOS 7.6 onward — generations one through three except the X model, single appliance cluster only, connection from 10 gigabits up. NetApp ONTAP is in early access, with general availability stated by the vendor for the third quarter of 2026, connecting over NFS, with AFF A-series and some hybrid FAS systems named; support for Lenovo storage is promised at roughly the same time. In short, Fibre Channel here is not a connection detail but a fork in the choice of platform.

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

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

Fibre Channel here is not a connection detail but a fork in the choice of platform.

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

У OpenShift Virtualization зовнішнє сховище підключається через сторонні драйвери CSI, і ключовий критерій відбору драйвера — підтримка режиму одночасного доступу до блокового тому з кількох вузлів. Без нього не буде живої міграції, і це перше, що треба перевіряти в специфікації драйвера, а не в презентації. Класична фабрика Fibre Channel підключається не напряму: для цього існує окремий продукт, що дозволяє використовувати наявні SAN, по суті кластерна файлова система поверх LUN. Це працює, але це ще одна ліцензія і ще одна система в експлуатації.

In OpenShift Virtualization external storage is connected through third-party CSI drivers, and the key selection criterion for a driver is support for accessing a block volume from several nodes at once. Without it there is no live migration, and that is the first thing to check in the driver’s specification rather than in a presentation. A classic Fibre Channel fabric does not connect directly: there is a separate product for using existing SANs, essentially a clustered filesystem on top of the LUNs. It works, but it is another licence and another system to operate.

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

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

SUSE Virtualization supports third-party CSI drivers, including for root volumes, and in July 2026 it gained its own storage certification programme for virtualisation. But there is a mine buried here that you need to know about before choosing the platform: native VM backup works only with v1 Longhorn volumes. For volumes on external storage the platform can neither create copies nor restore them — the documentation states this plainly. So the entire backup function moves to an external product, whose compatibility is verified separately. Plus the small things that surface during installation: the multipath service on the nodes is disabled by default, and the operating system is immutable, so node preparation is done through the initial-configuration mechanism on each host.

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

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

With Proxmox an existing fabric connects natively: LUNs are presented to the nodes and LVM is built on top. For years the main limitation was the absence of snapshots in such a setup. Version 9 closed that — snapshots are implemented as volume chains and work on thick LVM over iSCSI and Fibre Channel. But even in 9.2 the feature is still a technology preview; taking it out of that status is on the developers’ plans, with no date attached. The platform still has no officially supported clustered filesystem.

07

ГеографияГеографіяGeography

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

Два-три майданчики

Two or three sites

Одноплощадочных заказчиков почти не осталось. Здесь варианты расходятся сильнее, чем по любому другому пункту.

Одномайданчикових замовників майже не залишилося. Тут варіанти розходяться сильніше, ніж за будь-яким іншим пунктом.

Single-site customers have all but disappeared. This is where the options diverge more than on any other point.

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

У моїй практиці одномайданчикових замовників майже не залишилося: два майданчики — норма, три — регулярність. І це не деталь впровадження, а умова вибору платформи, бо розходяться варіанти тут сильніше, ніж за будь-яким іншим пунктом.

In my practice single-site customers have all but disappeared: two sites are the norm, three are common. And this is not a deployment detail but a condition of platform choice, because the options diverge here more than on any other point.

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

Перевіряти треба п’ять речей, саме в такому порядку. Єдина точка управління всіма майданчиками. Синхронна реплікація на другий майданчик для того, що не терпить втрати даних. Асинхронна на третій — для всього іншого. Оркестрація перемикання: не «дані доїхали», а сценарій, який піднімає машини в потрібному порядку і дозволяє перевірити це тестом, не зупиняючи продуктив, — саме тест зазвичай і вимагає аудит. І жива міграція між майданчиками, приємна, але не вирішальна.

Five things to check, in exactly this order. A single point of management for all sites. Synchronous replication to the second site for whatever cannot tolerate data loss. Asynchronous replication to the third for everything else. Failover orchestration: not “the data arrived”, but a plan that brings machines up in the right order and lets you verify it with a test without stopping production — and it is the test that auditors usually ask for. And live migration between sites, pleasant but not decisive.

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

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

How the options line up. With Nutanix it is assembled in one product and managed from one console: synchronous replication between two sites, asynchronous to a third, and recovery plans with test execution. Plus file and object services replicate through the same mechanism — if the cluster is destined to become multi-purpose, that applies to the second site as well.

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

Якщо ви залишаєтеся на VMware, багатомайданчикова схема у вас уже є і працює — це історично сильна сторона платформи, і втрачати її при переїзді найприкріше.

If you stay on VMware, the multi-site design already exists and works — historically a strong side of the platform, and the most galling thing to lose in a move.

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

У OpenShift усе це досяжне, але збирається з кількох продуктів: окремий шар управління множиною кластерів, окремі режими катастрофостійкості для розтягнутої та для асинхронної схеми, вимоги до затримки між майданчиками. Працює, але проєктується і експлуатується помітно складніше.

With OpenShift all of this is achievable but assembled from several products: a separate multi-cluster management layer, separate disaster-recovery modes for stretched and for asynchronous designs, and latency requirements between sites. It works, but it is noticeably harder to design and to run.

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

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

SUSE Virtualization handles multi-cluster management natively, but there is no native replication of machines between sites: what remains is backup to external storage and restore at the second site. For disaster recovery with a short recovery time that is not enough.

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

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

Proxmox’s central manager gives an overall view and live migration between clusters, but it binds the sites loosely: each cluster stays autonomous, there is no shared configuration, and no automatic failover between sites either. Replication between sites is assembled by hand from storage mechanisms and backup-server synchronisation.

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

І попередження, спільне для всіх. Розтягнутий кластер на два майданчики вимагає каналу з гарантованою затримкою і третьої точки для кворуму. Два майданчики без свідка — це не відмовостійкість, це два місця, де все може стати одночасно.

And a warning that applies to all of them. A stretched cluster across two sites requires a link with guaranteed latency and a third point for quorum. Two sites without a witness are not resilience; they are two places where everything can stop at once.

08

Существующий паркНаявний паркThe existing estate

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

Що переїжджає з того, що є

What moves across from what you have

Серверам 2–4 года, массив свежий, фабрика на месте. А если массива нет и всё живёт на vSAN — расклад меняется целиком.

Серверам 2–4 роки, масив свіжий, фабрика на місці. А якщо масиву немає і все живе на vSAN — розклад змінюється цілком.

The servers are 2–4 years old, the array is recent, the fabric is in place. And if there is no array and everything lives on vSAN, the whole picture changes.

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

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

The more common situation: the servers are 2–4 years old, the array is recent, the fabric runs at 32 gigabits, and the customer reasonably does not want to throw all of it away over somebody else’s licensing policy.

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

Якщо ви йдете з vSAN

If you are leaving vSAN

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

Тут розклад інший і загалом простіший. Масиву немає — розвилка з Fibre Channel зникає разом із ним, а варіант із зовнішньою системою зберігання відпадає, якщо тільки замовник заразом не вирішив піти від гіперконвергенції. Вибір звужується до «одна гіперконвергенція замість іншої».

Here the picture is different and generally simpler. There is no array, so the Fibre Channel fork disappears with it, and the external-storage option drops out unless the customer has also decided to leave hyperconvergence behind. The choice narrows to one hyperconverged platform instead of another.

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

Парк при цьому переїжджає краще, ніж у будь-якому іншому кейсі: вузли, локальні NVMe, мережа зберігання, якщо вона вже 25 гігабіт, і сама топологія проєктувалися під розподілене сховище і під нього ж і поїдуть. Міняти треба софт, а не залізо.

The estate moves better here than in any other case: the nodes, the local NVMe, the storage network if it is already at 25 gigabits, and the topology itself were designed for distributed storage and will move to distributed storage. What changes is the software, not the hardware.

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

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

There is one piece of bad news, and it is a big one: there is no in-place conversion of vSAN to another distributed storage system. The data is moved in its entirety, and unlike the array case there is no intermediate shared storage you can attach to both platforms to move machines one at a time without copying disks. The whole volume goes over the network — and the section on bandwidth turns from theory into the project’s schedule calculation.

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

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

And two things that are lost silently. Per-machine storage policies: nobody has a direct equivalent, and redundancy in the other platforms is set at a coarser level. And the stretched cluster with a witness node: it does not move, it is rebuilt under somebody else’s rules and with different latency requirements between sites.

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

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

What moves well. Servers — almost always: compatibility lists are broad, and for Nutanix compute nodes the list reaches back to 2017 generations. NVMe and SSD drives — if they are on the lists and not no-name. The array — if it can present capacity over the required protocol. The team’s knowledge of guest systems and applications — entirely.

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

Що переїжджає із застереженнями. Наявна фабрика Fibre Channel: у схемі з Nutanix на зовнішньому сховищі вона не переїжджає взагалі, у OpenShift вимагає окремого продукту, у Proxmox працює, але зі снапшотами в статусі превʼю, у SUSE — через сторонній драйвер, але тоді ви втрачаєте штатне резервне копіювання. Масив з інтерфейсом лише Fibre Channel: іноді рятує додавання Ethernet-портів, якщо модель це підтримує, іноді ні. Мережа доступу на витій парі: не переїжджає, змінюється.

What moves with caveats. An existing Fibre Channel fabric: with Nutanix on external storage it does not move at all, with OpenShift it needs a separate product, with Proxmox it works but with snapshots in preview status, and with SUSE it works through a third-party driver — but then you lose native backup. An array with Fibre Channel interfaces only: sometimes adding Ethernet ports saves it, if the model supports that; sometimes not. Copper access networking: it does not move, it gets replaced.

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

Що не переїжджає ніколи. Ліцензії гостьових Windows, куплені як OEM. Правила розподілу навантаження, зав’язані на об’єкти старого керуючого сервера. І звичка команди, що снапшот, клон і відновлення робляться в одному місці й одним способом.

What never moves. Guest Windows licences bought as OEM. Load-placement rules tied to objects of the old management server. And the team’s habit that snapshot, clone and restore all happen in one place and in one way.

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

І попереджу про спокусу гібрида: частину навантаження залишити на старій платформі, частину перенести. На практиці ви рік тримаєте дві платформи, два бекапи, два моніторинги і два набори компетенцій — і платите за ліцензії на обох. Перехідний період потрібен, але з датою закінчення в плані.

And a warning about the hybrid temptation: leave part of the workload on the old platform and move part of it. In practice you spend a year running two platforms, two backup systems, two monitoring stacks and two sets of skills — and paying licences on both. A transition period is necessary, but with an end date in the plan.

09

МиграцияМіграціяMigration

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

Інструменти переїзду та обв’язка

Migration tools and the surrounding systems

Инструмент — полдня работы на машину. Резервное копирование, катастрофоустойчивость и мониторинг — месяцы.

Інструмент — півдня роботи на машину. Резервне копіювання, катастрофостійкість і моніторинг — місяці.

The tool is half a day’s work per machine. Backup, disaster recovery and monitoring are months.

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

Інструменти міграції є у всіх, і всі роблять одне: читають диски машини зі старого середовища, конвертують формат, створюють об’єкт у новому.

Everyone has migration tools, and they all do the same thing: read the machine’s disks from the old environment, convert the format, create an object in the new one.

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

У Nutanix це Move, найбільш обкатаний з усіх; там же з’явилося перетворення без копіювання даних — томи vVols перетворюються на диски AHV на місці. У Red Hat — набір інструментів міграції, де у версії 2.11 розвантаження копіювання на масив доведене до загальної доступності: дані переносить сам масив, а не мережа. Плюс тепла міграція, коли основний обсяг копіюється на працюючій машині. Для швидкості потрібен комплект розробника віртуальних дисків від VMware, і збирати образ із ним доведеться самостійно — викладати його в публічний реєстр ліцензія не дозволяє. У SUSE Virtualization — доповнення для імпорту з джерелами vSphere і OpenStack, із неочевидною особливістю: ім’я машини стає ім’ям об’єкта Kubernetes, і машини з іменами не за правилами іменування імпортуються з помилкою. У Proxmox — майстер імпорту з ESXi, теж технологічне превʼю, з обмеженнями щодо vSAN і просіданням швидкості під час роботи через керуючий сервер.

Nutanix has Move, the most road-tested of them; it also gained conversion without copying data — vVols volumes become AHV disks in place. Red Hat has its migration toolkit, where version 2.11 brought array-offloaded copying to general availability: the array moves the data rather than the network. Plus warm migration, where the bulk is copied while the machine runs. For speed you need VMware’s virtual disk development kit, and you will have to build the image containing it yourself — the licence does not allow publishing it to a public registry. SUSE Virtualization has an import add-on with vSphere and OpenStack sources, and a non-obvious quirk: the machine name becomes the Kubernetes object name, so machines whose names break the naming rules fail to import. Proxmox has an ESXi import wizard, also a technology preview, with vSAN limitations and a drop in speed when working through the management server.

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

Але інструмент — це півдня роботи на машину, а обв’язка — місяці. Що перевірити до вибору платформи.

But the tool is half a day’s work per machine, while the surrounding systems are months. Here is what to check before choosing a platform.

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

Резервне копіювання: чи підтримує ваш продукт цільову платформу, на якому рівні — образ цілком чи змінені блоки — і що з відновленням окремих файлів. Якщо платформа SUSE і томи зовнішні, штатного бекапу немає взагалі.

Backup: does your product support the target platform, at what level — whole image or changed blocks — and what about individual file restore? If the platform is SUSE and the volumes are external, there is no native backup at all.

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

І окремий рядок бюджету, який пропускають майже всі: навчання. Не «прочитати документацію», а курс із практикою до запуску. Команда, яка пройшла такий курс, у перші півроку звертається до підтримки помітно рідше — це видно за кількістю звернень.

And a budget line almost everyone skips: training. Not “read the documentation”, but a course with hands-on practice before go-live. A team that has been through one raises noticeably fewer support tickets in the first six months — it shows in the ticket counts.

10

Чек-листЧек-листChecklist

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

Що запитати до того, як обирати платформу

What to ask before choosing a platform

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

Одинадцять питань, які переводять вибір платформи з області вподобань в область обмежень.

Eleven questions that move the platform choice out of preference and into constraint.

1. Какая дата окончания поддержки и сколько до неё осталось окон обслуживания — не месяцев, а именно окон?
2. Сколько трафика хранения уходит из выделенной фабрики в Ethernet после миграции, какая сейчас полоса на узел и какой пик даёт перестроение после отказа узла?
3. Умеет ли имеющийся массив отдавать ёмкость по протоколу, который поддерживает платформа, и если нет — есть ли модуль расширения интерфейсов?
4. Поддерживает ли выбранный драйвер хранения одновременный доступ к блочному тому с нескольких узлов — без этого нет живой миграции?
5. Кто делает снапшоты и клоны в новой схеме — платформа или массив — и как это видит ваша система резервного копирования?
6. Какие лицензии гостевых операционных систем переезжают, а какие придётся покупать заново?
7. Что происходит с катастрофоустойчивостью: остаётся ли текущий механизм или он тоже меняется?
8. Какие нужные вам функции находятся в статусе технологического превью — и что вы будете делать, если они там и останутся?
9. Нужны ли от кластера файловые и объектные сервисы для внешних потребителей — и кто их даёт на выбранной платформе?
10. Сколько у вас площадок, что между ними должно ездить синхронно, а что асинхронно, и кто оркестрирует переключение?
11. Кто в команде отвечает за новую платформу и когда он проходит обучение?

1. Яка дата закінчення підтримки і скільки до неї залишилося вікон обслуговування — не місяців, а саме вікон?
2. Скільки трафіку зберігання йде з виділеної фабрики в Ethernet після міграції, яка зараз смуга на вузол і який пік дає перебудова після відмови вузла?
3. Чи вміє наявний масив віддавати ємність за протоколом, який підтримує платформа, і якщо ні — чи є модуль розширення інтерфейсів?
4. Чи підтримує обраний драйвер сховища одночасний доступ до блокового тому з кількох вузлів — без цього немає живої міграції?
5. Хто робить снапшоти і клони в новій схемі — платформа чи масив — і як це бачить ваша система резервного копіювання?
6. Які ліцензії гостьових операційних систем переїжджають, а які доведеться купувати заново?
7. Що відбувається з катастрофостійкістю: чи залишається поточний механізм, чи він теж змінюється?
8. Які потрібні вам функції перебувають у статусі технологічного превʼю — і що ви робитимете, якщо вони там і залишаться?
9. Чи потрібні від кластера файлові та об’єктні сервіси для зовнішніх споживачів — і хто їх дає на обраній платформі?
10. Скільки у вас майданчиків, що між ними має їздити синхронно, а що асинхронно, і хто оркеструє перемикання?
11. Хто в команді відповідає за нову платформу і коли він проходить навчання?

1. What is the end-of-support date, and how many maintenance windows are left before it — not months, windows?
2. How much storage traffic moves out of the dedicated fabric into Ethernet after migration, what bandwidth per node do you have now, and what peak does a rebuild produce after a node failure?
3. Can your existing array present capacity over a protocol the platform supports, and if not — is there an interface expansion module?
4. Does the chosen storage driver support accessing a block volume from several nodes at once — without which there is no live migration?
5. Who takes snapshots and clones in the new design — the platform or the array — and how does your backup system see that?
6. Which guest operating system licences move across, and which will have to be bought again?
7. What happens to disaster recovery: does the current mechanism stay, or does it change too?
8. Which functions you need are in technology-preview status — and what will you do if they stay there?
9. Does the cluster need file and object services for external consumers — and who provides them on the chosen platform?
10. How many sites do you have, what must travel between them synchronously and what asynchronously, and who orchestrates the failover?
11. Who on the team owns the new platform, and when do they get trained?

11

ИтогПідсумокWrap-up

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

Замість висновку

In place of a conclusion

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

Відхід від VMware — не купівля іншого гіпервізора, а перепроєктування інфраструктури цілком, просто зі збереженням робочих навантажень. Той, хто вважає цю задачу заміною ліцензій, виявляє решту п’ять шарів у процесі — зазвичай у найневідповідніший момент.

Leaving VMware is not buying a different hypervisor; it is redesigning the infrastructure as a whole while keeping the workloads. Anyone who treats the task as a licence swap discovers the other five layers along the way — usually at the least convenient moment.

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

Правильних відповідей кілька. Є майданчики, де свіжий масив і фабрика роблять Proxmox або OpenShift очевидним вибором. Є ті, де відсутність підтримки Fibre Channel знімає половину варіантів. Є ті, де вирішує не техніка, а наявність підтримки і компетенцій у країні. Вибір платформи має випадати з обмежень, а не з презентації.

There is more than one right answer. There are sites where a recent array and fabric make Proxmox or OpenShift the obvious choice. There are those where the absence of Fibre Channel support removes half the options. And there are those where the deciding factor is not the technology but the availability of support and skills in the country. The platform choice should fall out of the constraints, not out of a presentation.

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

За рамками залишилися три теми, кожна на окремий розбір: сценарій «залишитися» на нових редакціях платформи, будівництво з нуля і доля Kubernetes, який іде разом із vSphere.

Three topics were left outside the scope, each deserving its own write-up: the “stay” scenario on the platform’s newer editions, building from scratch, and the fate of the Kubernetes stack that departs together with vSphere.

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

Єдине, про що я прошу: порахуйте мережу. Вона в цій історії не рядок у кошторисі, а умова працездатності всього іншого, і саме її зазвичай «уже купили».

The one thing I ask: do the network arithmetic. In this story it is not a line in the estimate but the precondition for everything else working — and it is usually the part that has “already been bought”.