Безпечна інтеграція в майбутнє


Безпечна інтеграція в майбутнє

Не лише ліцензії: технічні виклики, про які варто знати до початку міграції з VMware

Майстер-клас: секрети випікання найсмачніших млинців!

18.08.2026

Після переходу Broadcom на пакетні підписки рахунки за віртуалізацію зросли у 2–5 разів. У першій частині ми розібрали фінансовий бік питання — як розрахувати TCO міграції та чому іноді вигідніше ущільнити ресурси й залишитися на VMware.
Але вартість переходу також залежить від технічних особливостей вашої інфраструктури. Застаріла гостьова ОС без драйверів на новій платформі, кластер бази даних на RDM-дисках, слабка пропускна здатність мережі або втрата підтримки вендорських систем здатні перекреслити будь-який розрахунок.
Усі ці технічні нюанси об'єднує одне: якщо не врахувати їх на старті, посеред міграції вони перетворяться на зірвані терміни, додаткові витрати на закупівлю обладнання або простої критичних систем. Розглянемо головні підводні камені переходу, щоб ви могли закласти їх у план до ухвалення рішення, а не боротися з наслідками вже в процесі.

Що стає несподіванкою під час міграції?

Коректний розрахунок міграції спирається на 6 блоків TCO: ● ліцензії;● обладнання;● мережу;● операційні витрати;● процес перенесення;● ризики.
Прогнозувати перші чотири нескладно завдяки фіксованим тарифам. Складність полягає у двох останніх: вони охоплюють технічні нюанси, які непомітні на етапі планування, проте призводять до надлишкових витрат уже в процесі міграції. 
Розглянемо 5 таких чинників, які варто виявити заздалегідь під час інвентаризації середовища. 
Застарілі гостьові ОС
VMware підтримує дуже широкий перелік гостьових систем, тож у зрілих інфраструктурах десятиліттями працюють машини з Windows Server 2008/2012 чи старими Linux-дистрибутивами під успадковані застосунки. В альтернативних платформах переліки сумісності вужчі, а драйверів для давніх ОС часто просто немає. 
Вибір зводиться до трьох варіантів, і кожен має свою ціну: ● оновити ОС і доопрацювати застосунок;● відмовитися від системи;● залишити для таких машин ізольований «острівець» старої платформи.
Усі 3 шляхи означають додаткові витрати часу фахівців та ліцензії, які необхідно внести в розрахунок TCO ще до ухвалення рішення.
Спосіб підключення дисків
Віртуальні машини з RDM (прямим підключенням тому даних із масиву) найскладніше піддаються міграції. Такий підхід є типовим для кластерів СУБД зі спільними дисками. Проблема полягає в тому, що цей механізм не підтримує знімки стану (снапшоти), на яких працюють інструменти перенесення, і не має аналогічного функціоналу на інших гіпервізорах.
Інженерам доведеться конвертувати формати дисків і повністю перепроєктувати кластерні конфігурації. Ситуація ускладнюється тим, що на RDM зазвичай розгорнуті найкритичніші системи компанії. Відповідно, найважча частина міграції припадає на навантаження, для яких тривала недоступність сервісів є неприпустимою.
Простої під час перемикання платформ
Між різними гіпервізорами не існує живої міграції — технологія vMotion працює лише всередині екосистеми VMware. Сучасні інструменти здатні копіювати дані у фоновому режимі, поки віртуальна машина продовжує працювати, проте фінальне перемикання завжди вимагає її зупинки. 
Для однієї системи це означає хвилини чи години недоступності. Якщо ж помножити цей час на сотні машин, міграція перетворюється на тижні узгоджених вікон обслуговування та робіт у нічну зміну. Графік таких простоїв необхідно погоджувати з власниками бізнес-систем ще на етапі планування. 
Подвійні дискові ресурси
Конвертація форматів вимагає одночасного зберігання даних у двох примірниках: на вихідній і на цільовій платформах. Також інструментам міграції потрібен проміжний простір для роботи. 
Згідно з практичними настановами, варто закладати додаткову дискову ємність у розмірі до двократного обсягу наявних даних. Якщо ваша інфраструктура вимірюється десятками терабайт, це перетворюється на значні капітальні витрати на диски, які часто не враховують на початку розрахунків. 
Ресурси зовнішніх підрядників
Міграція сотень віртуальних машин створює екстремальне навантаження на ІТ-відділ. Внутрішня команда не може займатися лише перенесенням, адже вона продовжує адмініструвати поточні робочі процеси. 
Для такого проєкту необхідні зовнішні інтегратори з експертизою в обраній новій платформі. Нововведення Broadcom створили дефіцит кваліфікованих підрядників — ринок перевантажений, тому вартість і терміни варто узгоджувати заздалегідь. 

«Залізо» і мережа — приховані витрати міграції

Зміна платформи віртуалізації — це також перехід на іншу логіку обміну даними. На практиці наявної мережі часто виявляється недостатньо для нових навантажень, і на це впливають 3 чинники. 
Вимоги гіперконвергентних платформ (HCI)
Рішення на кшталт Nutanix чи Azure Local будують сховище даних поверх мережі між вузлами. Для постійної синхронізації потрібна пропускна здатність від 10 Гбіт/с для базових кластерів і щонайменше 25 Гбіт/с для навантажених конфігурацій. Якщо поточні комутатори на це не розраховані — доведеться купувати нове обладнання та перекладати кабелі. 
Заміна віртуальної мережі (VMware NSX)
Якщо NSX використовувався для внутрішньої безпеки, розподілених фаєрволів чи балансування трафіку, після міграції ці функції зникнуть. Їх доведеться відтворювати: докуповувати апаратні рішення або перепроєктувати мережу під обрану платформу. 
Продуктивність програмно-визначених сховищ (SDS)
Класичний масив із блочним доступом дає передбачувано низькі затримки. Натомість розподілені сховища (Nutanix AOS, Storage Spaces Direct, Ceph) працюють інакше: дані розподіляються між вузлами, і кожен запис синхронно реплікується мережею. 
До затримки диска додається час очікування мережі — для транзакційних СУБД та інших чутливих навантажень це прямий ризик деградації, який компенсують «залізом»: швидшими накопичувачами, додатковими вузлами, потужнішою мережею. Рекомендована для таких кластерів технологія RDMA вимагає дорогих комутаторів корпоративного класу зі складним налаштуванням. Тож «безкоштовне» сховище швидко перетворюється на окрему статтю капітальних витрат. 
Отже, оновлення мережі може скласти левову частку бюджету міграції. Саме тому в розрахунках TCO ці витрати необхідно виділяти окремо, а не включати до загальної вартості серверів.

 

Технологічний розрив: функції VMware, які не мають прямої заміни

Частину вартості міграції неможливо побачити у прайс-листах вендорів. Це ті інструменти, які роками безвідмовно працювали у VMware, проте в альтернативних рішеннях або відсутні, або ж значно слабші. Розглянемо ключові функції, втрата яких вимагатиме архітектурних змін. 
Автоматичне балансування навантаження (DRS)
У середовищі VMware інструмент DRS безперервно аналізує кластер і самостійно переміщує віртуальні машини між серверами за встановленими правилами. Повного аналога немає: 
● у Hyper-V подібну роль виконує System Center (окремий продукт із простішою логікою);● у Nutanix працює власний планувальник;● у Proxmox балансування залишається базовим.
Без звичної автоматики значна частина роботи з розподілу ресурсів потребує залучення інженерів. 
Кластерна файлова система VMFS
У VMware десятки серверів паралельно працюють з одним спільним томом на FC- чи iSCSI-масиві — це фундамент класичних інфраструктур із SAN. Платформи KVM/Proxmox не мають вбудованого аналога: спільний том підключається з функціональними обмеженнями, а повноцінні кластерні файлові системи доведеться розгортати й супроводжувати власноруч. 
Гіпервізор Hyper-V пропонує Cluster Shared Volumes, але це інша архітектура зі специфічною поведінкою під навантаженням. Для компаній, які інвестували в блочні системи зберігання, існує ризик неповної реалізації продуктивності наявного масиву в новому середовищі.
Сучасні протоколи доступу до сховищ
Платформа vSphere має зрілу підтримку NVMe over Fabrics, зокрема через Fibre Channel. В альтернативних рішеннях вона обмежена або відсутня. Через це швидкісні флешмасиви, придбані під VMware, після переходу можуть працювати через повільніші протоколи, що робить попередні інвестиції в обладнання невиправданими. 
Моніторинг і планування потужностей «з коробки»
Нові пакети Broadcom критикують за примусовість, але вони вирішують операційні питання без додаткових закупівель. Підписки VVF і VCF містять VCF Operations для моніторингу й аналізу продуктивності, а також інструменти для централізованої роботи з логами. 
В інших гіпервізорах ці функції доведеться докуповувати або збирати самостійно: для Hyper-V це платний System Center, у Nutanix — розширені рівні Prism, а на Proxmox стек спостереження будують з open-source компонентів. Тож у TCO коректно порівнювати не тільки гіпервізори, а й повні операційні стеки. 
Специфічні інструменти VMware
Такі технології, як миттєве перемикання машини без втрати стану (Fault Tolerance), автоматизація аварійного відновлення (Site Recovery Manager) або розподілені віртуальні комутатори, теж потребуватимуть заміни. Для кожної з цих функцій доведеться шукати окремий продукт, будувати обхідне рішення або свідомо погоджуватися на нижчий рівень сервісу.
Висновок для TCO-моделі: складіть перелік усіх критичних для вас функцій VMware і для кожної визначте альтернативу та ціну заміни — у фінансах, додатковому обладнанні чи припустимому зниженні рівня сервісу (SLA).

ШІ-навантаження та GPU: новий вимір порівняння платформ

Корпоративний ШІ перейшов до етапу промислової експлуатації, а графічні процесори (GPU) стали найдорожчим ресурсом у дата-центрах. Ефективність керування прискорювачами перетворилася на вагомий фактор розрахунку TCO, і саме в цьому аспекті Broadcom пропонує сильний аргумент на користь VCF. 
Пакет VCF містить Private AI Foundation with NVIDIA — платформу для запуску ШІ-навантажень у приватному дата-центрі. Її головна перевага полягає в підтримці NVIDIA vGPU: фізичний прискорювач ділиться між кількома віртуальними машинами зі збереженням технології vMotion. 
У версії VCF 9 жива міграція машини з GPU відбувається з паузою менш ніж на секунду, тому сервери можна виводити на обслуговування без зупинки ШІ-сервісів. Додатково платформа забезпечує телеметрію використання GPU, квотування та реалізацію моделі «GPU як сервіс» для внутрішніх команд. 
Технічний бар'єр більшості альтернативних рішень криється у способі виділення ресурсів. Зазвичай GPU передається у віртуальну машину через пряме підключення (passthrough), що закріплює її до конкретного фізичного сервера. 
Жива міграція таких навантажень неможлива або суттєво обмежена, тому обслуговування обладнання неминуче призводить до зупинки роботи алгоритмів ШІ. Підтримку vGPU поза екосистемою vSphere варто перевіряти окремо для кожної платформи й версії, а результати перевірки — закладати в кошторис міграції як ризик простоїв. 
Архітектурний підхід Red Hat OpenShift
Серед альтернатив вартий уваги Red Hat OpenShift. Завдяки компоненту OpenShift Virtualization класичні віртуальні машини працюють поруч із контейнерами Kubernetes під єдиним управлінням, а інструмент Migration Toolkit for Virtualization автоматизує перенесення з vSphere.
Для роботи з ШІ це один із найбільш перевірених варіантів. Сучасні інструменти машинного навчання від початку створюються для Kubernetes, а інтеграція з OpenShift AI та операторами NVIDIA забезпечує нативний доступ до GPU. Наслідком такого вибору є перехід на філософію адміністрування Kubernetes-first. Це вимагає перенавчання команди, оплати підписок за ядрами та готовності до складнішої міграції й оновлень. 
Kubernetes та приховане споживання ресурсів
Технологія Kubernetes сьогодні є майже у кожній інфраструктурній екосистемі; різниця полягає лише у глибині інтеграції. У Broadcom компонент Tanzu входить до складу VCF, Nutanix пропонує власну платформу NKP, а на Proxmox кластери Kubernetes доводиться розгортати власноруч у віртуальних машинах без вендорської підтримки.
Справжній вибір зводиться до архітектурної моделі: Kubernetes поверх віртуалізації (шлях VMware та Nutanix) чи віртуалізація поверх Kubernetes (шлях OpenShift). Це рішення визначає вимоги до компетенцій команди та структуру витрат на довгі роки, тому його слід ретельно оцінювати.
Під час переходу на контейнерну архітектуру варто враховувати значне споживання ресурсів самим середовищем Kubernetes. Керівні вузли кластера, системні агенти, дубльовані репліки для відмовостійкості та додаткові резервування від розробників суттєво збільшують навантаження на інфраструктуру. За галузевими дослідженнями, фактична утилізація багатьох кластерів не перевищує кількох десятків відсотків. 
Раніше на такий надлишок часто не звертали уваги, проте зі значним подорожчанням серверної пам'яті та ліцензованих ядер ситуація змінилася. Аудит контейнерних платформ (перегляд резервувань, кількості реплік та видалення покинутих тестових середовищ) має стати обов'язковим етапом оцінки інфраструктури на рівні з аудитом віртуальних машин. 

Екосистема навколо гіпервізора — бекапи, DR та вендорські віртуальні модулі

Останній блок, який часто не враховують у розрахунках TCO, стосується сумісності суміжних систем, що працюють навколо платформи віртуалізації. 
Резервне копіювання
Провідні рішення для резервного копіювання вже адаптовані до основних альтернатив. Наприклад, Veeam працює з VMware, Hyper-V, Azure Local, Proxmox VE, Nutanix AHV та платформами Red Hat і Oracle. Проте глибина такої підтримки суттєво відрізняється. Для Proxmox, наприклад, не резервуються LXC-контейнери, а відновлення на рівні застосунків потребує агентів усередині машин. 
Якщо компанія використовує нішеву або застарілу систему резервного копіювання, вона не зможе застосовувати її з новим гіпервізором. У такому разі до бюджету міграції доведеться закласти витрати на повну заміну інструментарію.
Плани аварійного відновлення (DR)
Оркестрація рівня Site Recovery Manager забезпечує автоматизовані плани відновлення, тестові перемикання без впливу на робоче середовище та зворотну реплікацію. У більшості альтернативних платформ такий функціонал або відсутній, або його потрібно збирати з окремих компонентів. План дій на випадок катастрофи доведеться перепроєктувати й повторно протестувати — це тижні роботи команди, що варто врахувати заздалегідь. 
Сертифікація та підтримка бізнес-систем
Міграція критичних інформаційних систем вимагає обов'язкового погодження з їхніми розробниками або інтеграторами. Постачальники ERP, CRM, білінгових чи банківських рішень чітко фіксують у договорах перелік сертифікованих середовищ. Перенесення системи на непідтримувану платформу загрожує втратою допомоги вендора в критичний момент або відмовою розслідувати інциденти до повернення в сертифіковану конфігурацію. 
Тому ще до вибору гіпервізора потрібно надіслати офіційний запит усім постачальникам програмного забезпечення та з'ясувати умови підтримки нового середовища. Ці дані є таким самим базовим параметром для TCO-моделі, як і вартість ліцензій. 
Навіть за умови позитивної відповіді міграція для підрядника, що супроводжує систему, — це окремий обсяг робіт, який включає:● створення тестових середовищ на новому гіпервізорі;● адаптацію й повторну перевірку процедур оновлення;● налаштування резервного копіювання;● перевірку планів реагування на інциденти.
Якщо поточні контракти не передбачають таких робіт, виникнуть додаткові рахунки та затримки. Тож договори з підрядниками критичних систем варто переглянути до старту проєкту, щоб ці цифри потрапили в TCO-модель, а не в позапланові витрати під час міграції.
Вендорські віртуальні модулі
Спеціалізовані віртуальні пристрої, такі як шлюзи безпеки, балансувальники трафіку чи системи телефонії, зазвичай сертифікуються насамперед для VMware, рідше — для Hyper-V. Офіційна підтримка KVM-платформ залишається вибірковою.
Технічно запустити такий образ на Proxmox здебільшого можливо. Проте без підтримки вендора компанія залишається з проблемами сам на сам, що є неприйнятним ризиком для корпоративної інфраструктури. Тому перед вибором платформи варто скласти реєстр усіх appliance та звірити матриці сумісності їхніх виробників.

Технічний асесмент інфраструктури з IT Specialist

Кожен із перелічених ризиків має вартісний вимір, хоча жоден не є критичним. Оцінити цю вартість слід на етапі планування, а не в процесі міграції, коли бюджет затверджено, а графік уже не підлягає коригуванню.
Технічний асесмент від IT Specialist — це глибока інвентаризація середовища під конкретний сценарій переходу. Ми аналізуємо чинники, що реально впливають на складність робіт:● Сумісність систем і застосунків. Визначаємо, які гостьові ОС та вендорські appliance готові до перенесення, а де потрібне оновлення чи збереження старого контуру.● Мережу, сховища та диски. Виявляємо обмеження продуктивності, аналізуємо RDM-диски та плануємо конвертацію форматів.● Бекапи та аварійне відновлення. З'ясовуємо, що працюватиме без змін, а що потребує перепроєктування.● Фактичну утилізацію ресурсів. Оцінюємо споживання ядер і пам'яті, прибираючи накопичені «про запас» резерви.
Ви отримуєте чіткий план: перелік навантажень за складністю перенесення, необхідні вікна простоїв, додаткові закупівлі та ризики, переведені у фінансові та часові показники.
Залишайте заявку на технічний асесмент, щоб планувати міграцію на основі даних вашої інфраструктури.
Автор статті — Олексій Бутич, провідний фахівець з підтримки та впровадження інфраструктури кіберзахисту.

Illustration


Зателефонувати

Офіс+38 (044) 390 81 90

Департамент продажів+38 (096) 390 81 90

Написати

moc.tsilaicepsti-ym%40olleh

Приїхати на каву

Бізнес-центр Sigma,бульвар Вацлава Гавела, 6, корпус 3, Україна, Київ, 03124

Illustration


Зателефонувати

Офіс+38 (044) 390 81 90

Департамент продажів+38 (096) 390 81 90

Написати

moc.tsilaicepsti-ym%40olleh

Приїхати на каву

Бізнес-центр Sigma,бульвар Вацлава Гавела, 6, корпус 3, Україна, Київ, 03124