Міграція з VMware до WebDisk Cloud: що переносити, у якому п

Блог WebDisk · категорія: Публічна хмара · час читання: ~10 хвилин

Коротко:- Після придбання VMware компанією Broadcom змінилася модель ліцензування та партнерська програма, тож під час поновлення підтримки дедалі більше компаній прораховує альтернативи. Найчастіше розглядають KVM під керуванням Apache CloudStack – бо модель роботи близька до того, що адміністратор знає з vCenter.- Два шляхи: перенести машини та мережі до публічної хмари WebDisk або розгорнути CloudStack у себе, з нашою підтримкою. Обидва можна вести етапами, паралельно до працюючого vSphere.- Технічна суть – це три методи (OVA/OVF, конвертація дисків у qcow2, синхронізація на рівні системи), одна класична пастка (драйвери virtio) і одна річ, яку не можна пропустити: план відкату. >Не працюєте з терміналом? Пропустіть блоки команд – порядок робіт, пастки й чекліст описані словами.

Розмова зазвичай починається однаково: ІТ-відділ отримує пропозицію поновлення підтримки для vSphere, дивиться на умови, дивиться на бюджет і вперше за багато років ставить собі запитання «а чи мусимо?». Після придбання VMware компанією Broadcom (угоду закрито наприкінці 2023 року) змінилося кілька речей одночасно: портфель консолідували у великі пакети, безстрокові ліцензії поступилися місцем підпискам, а перебудова партнерської програми у 2024 році змінила перелік компаній, які можуть продавати та поновлювати ліцензії. Фінансовий наслідок залежить від конкретного контракту, а не від статті в блозі – тому замість відсотків ви отримуєте тут план дій на випадок, якщо ваші власні розрахунки виявляться невигідними.

У цій статті ми показуємо, що переносити і в якому порядку, трьома методами перенесення машини, а також де міграції найчастіше провалюються – з чеклістом однієї машини та планом відкату. Текст призначений для ІТ-команд, які стоять перед поновленням підтримки vSphere: адміністраторів, які це робитимуть, і людей, які мають оцінити ризик та бюджет.

Два шляхи: наша хмара або CloudStack у вас

Шлях перший – публічна хмара. Ви переносите машини та мережі до публічної хмари WebDisk, припиняєте утримувати власний гіпервізор (гіпервізор – програмне забезпечення, яке запускає віртуальні машини на фізичному сервері) і керуєте середовищем з панелі WebDisk Cloud. Кластер Kubernetes ви відтворюєте в новому середовищі – у нас як послугу WebDisk K8s – переносячи навантаження та томи, а не машини. Розрахунок щомісячний, за придбаний пул ресурсів, з публічним прайс-листом у злотих – тож порівняння витрат робиться на ваших числах: сумі vCPU, RAM, ємності та трафіку, зіставленій з повною вартістю власної серверної, разом з електроенергією, оновленням обладнання та часом людей.

Шлях другий – CloudStack у власній серверній. Ви залишаєтесь на своєму обладнанні, але знімаєте з нього ліцензійну залежність: Apache CloudStack – це вільне програмне забезпечення (ліцензія Apache 2.0), яке розвиває фундація Apache. Наша роль у такому разі — підтримка, а її обсяг – проєкт, впровадження, перенесення машин, навчання команди – ми узгоджуємо індивідуально. Обидва шляхи можна поєднати – частина середовища у вас, частина в нас; спосіб з’єднання обох локацій узгоджуємо в проєкті.

Варто назвати речі своїми іменами: якщо ви свідомо не оберете відкритий шар, ви лише міняєте одну залежність на іншу – про що ми писали в тексті про залежність від постачальника.

Чому CloudStack є природною альтернативою vSphere?

Для адміністратора vSphere CloudStack – це м’яка посадка, і то з конкретних причин, а не із симпатії:

Операційна модель знайома. Ієрархія зон, подів, кластерів і хостів відтворює те, що у vCenter називається datacenter → cluster → host, а робота відбувається в одній вебпанелі. CloudStack монолітний, тому впроваджується й обслуговується простіше, ніж платформи, складені з десятка компонентів.
Один оркестратор, багато гіпервізорів. CloudStack керує KVM, але також VMware vSphere чи XCP-ng. Це відкриває варіант переходу з найменшим ризиком відступу: ви запускаєте CloudStack поруч із працюючим vSphere, підключаєте наявний кластер як ресурс і мігруєте машини поступово.
Спрощений режим для on-premise. Зону можна запустити без віртуалізації мережі – інстанси потрапляють просто у спільну мережу на ваших VLAN-ах, що компаніям з упорядкованою адресацією економить цілий шар складності. А кластери Kubernetes мають власну послугу платформи: control plane створює CloudStack, а ви завантажуєте в нього свої навантаження та дані. Якщо ви волієте віддати утримання кластера, ми маємо технічну підтримку для Kubernetes.
Storage. Наша платформа спирається на Ceph – як блокове сховище для машин і як об’єктне сховище, сумісне з S3. Ємність додається через додавання вузлів, без простою машин.

Додатковим читанням є публічний посібник «VMware to Apache CloudStack Migration Guide» компанії ShapeBlue, яка сильно долучена до розвитку CloudStack.

Що переносити спершу, а що наприкінці?

Найчастіша помилка – почати з машини, на якій хтось знається найкраще, тобто з найважливішої. Порядок, який себе виправдовує, зворотний:

Інвентаризація. Експорт списку машин з vCenter: vCPU, RAM, диски та їхнє реальне заповнення, IP- та MAC-адреси, версія системи, прошивка (старіший BIOS чи новіший UEFI – режим, у якому машина запускається), агенти, ліцензії, прив’язані до обладнання. Ця таблиця – основа графіка.
Карта залежностей. Що з чим спілкується і якими портами. Машина, перенесена без своєї бази даних, – це не міграція, а аварія з відкладеним займанням.
Фундамент у новому середовищі. Спершу мережа (VPC, підмережі, правила, NAT, з’єднання з вашою мережею), потім DNS, ідентичність і доступ, резервне копіювання та моніторинг. Лише на цьому ставлять машини.
Нульова хвиля – одна невиробнича машина. Мета процедурна: виміряти, скільки реально триває передавання та конвертація, і відпрацювати відкат на чомусь, чого не шкода.
Перша хвиля – послуги без стану. Сервери застосунків, фронтенди, допоміжні машини. Перемикання (англ. cutover) дешеве, бо дані не мігрують разом з машиною.
Друга хвиля – дані. Великі томи варто «засіяти» заздалегідь (повна копія наперед, у вікні – тільки різниця), а архіви перенести одразу до об’єктного сховища, замість возити їх у віртуальному диску.
Остання хвиля – критичні системи, уже за відпрацьованою процедурою.

Перед першою хвилею зробіть резервну копію поза обома середовищами – міграція — це єдиний момент, коли ті самі дані існують у двох місцях і обидва в русі (про принципи розповідає текст про резервне копіювання в хмарі, а про сховища класу WORM – тобто такі, у яких записану копію не можна перезаписати чи видалити до закінчення терміну – текст про S3 Object Lock).

Як перенести віртуальну машину з VMware на KVM? Три методи

Метод A – експорт OVA/OVF (OVA та OVF – це стандартні формати експорту віртуальної машини у файл). Класика: машину вимикають, експортують в один файл та імпортують у новому середовищі. Передбачуваний, але потребує повного сервісного вікна і місця на дві копії диска.

# експорт машини з vSphere до OVA (ovftool, з хоста, який має доступ до vCenter)
ovftool --noSSLVerify \
vi://uzytkownik@vcenter.firma.local/Datacenter/vm/app-01 \
./app-01.ova

Метод B – конвертація дисків. Формат VMware (VMDK) ви перетворюєте на нативний для KVM формат (QCOW2 або RAW) і реєструєте як шаблон або том.

# розпакування OVA і конвертація диска VMDK -> QCOW2
tar -xvf app-01.ova # -> app-01.ovf, app-01-disk1.vmdk
qemu-img convert -p -f vmdk -O qcow2 app-01-disk1.vmdk app-01.qcow2
qemu-img info app-01.qcow2 # контроль: формат і віртуальний розмір

Безпечніший варіант – це virt-v2v: він конвертує образ і водночас вставляє в гостьову систему драйвери, потрібні для KVM – тобто вирішує найбільшу пастку з наступного розділу. Є одна умова: для машин з Windows драйвери virtio-win мають бути встановлені на машині, на якій ви конвертуєте. Без них конвертація вдасться, а система все одно не запуститься.

# конвертація + підготовка гостьової системи під KVM в одному кроці
virt-v2v -i ova app-01.ova -o local -os /var/tmp/wynik -of qcow2

Готовий образ ви публікуєте за адресою HTTP(S) і реєструєте в CloudStack як шаблон (форма «Register template» в панелі або register template у cloudmonkey – формат QCOW2, гіпервізор KVM). Новіші випуски вміють також завантажити машину просто з vCenter і сконвертувати її на KVM без ручного перенесення файлів; доступність залежить від версії, тож перевірте це на своєму впровадженні, перш ніж складати графік.

Метод C – синхронізація на рівні системи. Замість возити диск, ви ставите в новому середовищі чисту машину, встановлюєте програмне забезпечення і переносите дані. Тоді ви не тягнете за собою ні старих драйверів, ні залишків від VMware Tools, ні історії оновлень.

# перший прохід – наживо, джерело далі працює
rsync -aHAX --numeric-ids --info=progress2 root@stara-vm:/srv/ /srv/

# завершальний прохід – у сервісному вікні, після зупинки служб;
# переносить уже тільки різницю, тому вікно коротке
rsync -aHAX --numeric-ids --delete root@stara-vm:/srv/ /srv/

На практиці: A для простих, поодиноких машин; B для appliance’ів – готових машин від виробника програмного забезпечення, які не поставиш з інсталятора; C для всього, що ви збудуєте наново – і всюди там, де важливе коротке вікно.

Пастки, які з’їдають сервісне вікно

Драйвери virtio. Номер один у списку. Virtio – це родина драйверів, якими віртуальна машина спілкується з диском і мережею під KVM. Windows без попередньо встановлених драйверів virtio не запуститься (класична помилка зупинки «inaccessible boot device»); Linux з initramfs – маленькою стартовою системою в пам’яті, яка завантажується перш ніж стане доступним справжній диск – зібраним без модулів virtio зупиниться на відсутності диска. Ліки прості, за умови, що ви застосуєте їх перед вимкненням машини-джерела: доінсталюйте драйвери та перезберіть initramfs, або скористайтеся virt-v2v – за умови, що на машині, на якій ви конвертуєте, встановлені драйвери virtio-win; без них конвертація вдасться, а Windows усе одно не запуститься.
Назви мережевих інтерфейсів. Новий тип картки – це нова назва інтерфейсу (ens192 може змінитися на ens3). Конфігурація, прив’язана до старої назви або до MAC-адреси, означає машину, яка запускається без мережі. Перегляньте netplan, файли ifcfg і правила udev перед перенесенням.
MAC-адреси, ліцензії та знімки. Частина програмного забезпечення прив’язує ліцензію до MAC-адреси, UUID машини або серійного номера плати – складіть список таких систем завчасно, бо переліцензування залагоджують перед міграцією, а не в сервісному вікні. Машини з ланцюжком знімків мігруйте лише після консолідації: експорт з активним ланцюжком – це найкоротший шлях до образу, який не запускається.
VMware Tools, UEFI і fstab. VMware Tools видаліть перед міграцією, а в новому середовищі встановіть qemu-guest-agent. Машина, яка стартує в UEFI, має потрапити на інстанс в UEFI (несумісність проявляється «чорним екраном без причини»), а fstab – файл зі списком дисків, які монтуються під час старту системи – описаний назвами пристроїв замість ідентифікаторів UUID, це гарантована аварія старту, коли зміниться дисковий контролер.
Час передавання і DNS. Час копіювання порахуйте завчасно – ємність поділена на реальну пропускну здатність каналу; кілька десятків терабайтів – це не завдання на вихідні. А TTL записів DNS – тобто час, протягом якого сервери та браузери тримають у пам’яті стару відповідь – знизьте за добу до перемикання, бо інакше перемикання триває стільки, скільки найдовший кеш на шляху – і відкат рівно стільки ж.

План тестів і відкату

Міграція без визначеного відкату – це не міграція, а парі. Мінімум, який треба вписати в процедуру:

Критерії приймання (перш ніж трафік піде на нове середовище): система запускається після двох перезавантажень; консоль з панелі працює; адресація, маршрути та DNS відповідають проєкту; послуга проходить наскрізний (end-to-end) тест (не «процес працює», а «користувач виконав операцію»); продуктивність диска порівняна зі станом до міграції; резервна копія виконалася і була пробно відновлена; моніторинг – ваш або узгоджений з нами – бачить машину й сигналізує.

Відкат: машина-джерело залишається вимкненою, але недоторканою протягом узгодженого часу (розумний мінімум – це два тижні стабільної роботи). Визначте точку неповернення – момент, у який у новому середовищі з’являються записи, яких немає в старому: до цього моменту відступ безкоштовний, після нього він потребує міграції даних назад. Визначте також особу, яка оголошує рішення, і жорстку годину, о якій воно ухвалюється («якщо о 4:00 у нас немає зеленого тесту, повертаємось») – о третій ночі ніхто не хоче бути тим, хто першим запропонує відступ.

Після перемикання одразу переконайтеся, що машина охоплена вашим моніторингом – а якщо ви хочете, щоб зависла система перезавантажувалася сама, оснастіть її watchdog’ом (реакцією є жорсткий ресет, а не ремонт).

Чекліст однієї машини

T-14: інвентаризація та залежності · переліцензування там, де ліцензія тримається на обладнанні · драйвери virtio встановлені на джерелі · пробне відновлення резервної копії
T-2: консолідація знімків · мережа відв’язана від назв інтерфейсів і MAC-адрес · перший прохід копіювання «наживо» · перевірка образу після конвертації
T-1: знижений TTL у DNS · розіслане сервісне вікно · письмові критерії приймання та година рішення про відкат
T-0: зупинка служб · завершальний прохід даних · старт цільової машини · наскрізний тест · перемикання трафіку
T+1: резервна копія й моніторинг підтверджені · машина-джерело вимкнена, але збережена · документація та адресація оновлені

Чого міграція з VMware не вирішить?

Не кожна функція має відповідник один до одного. Автоматичне балансування навантаження кластера чи розподілений брандмауер з NSX мають у світі KVM/CloudStack власні, але інші рішення. Замість шукати кальку, перевірте, яке з них справді у вас працює.
Кластери Kubernetes будують наново. Міграції підлягають маніфести, образи та дані на томах – не вузли. Заплануйте це як окремий проєкт, а не як одну з хвиль перенесення машин.
Гіпервізор – це не вся платформа. Резервне копіювання, моніторинг і керування ідентичністю треба відтворити свідомо – це зазвичай більша частина проєкту, ніж саме перенесення дисків.
Міграція коштує одноразово: час людей, сервісні вікна, ризик. Поставте цю вартість поруч з економією на ліцензіях, перш ніж це зробить за вас бізнес.
Залишаючись на власному обладнанні, ви залишаєтесь оператором хмари. Вільне програмне забезпечення знімає ліцензійну плату, а не обов’язки: оновлення, заміну дисків, ємність, чергування.

Часті запитання

Чи мушу мігрувати все одразу? Ні – і краще, щоб ви не мігрували. CloudStack керує одночасно KVM і vSphere, тож обидва середовища можуть працювати паралельно протягом усього перехідного періоду, а перемикання відбувається хвилями.

Чи можна перенести машини з Windows? Так, за умови попередньої підготовки драйверів virtio на джерелі – або використання virt-v2v, який зробить це під час конвертації, якщо на машині, що конвертує, встановлені драйвери virtio-win (без них конвертація вдасться, а Windows усе одно не запуститься). Ліцензії системи та застосунків перевірте окремо – їх часом прив’язують до обладнання.

Чим відрізняються три методи перенесення машини: OVA/OVF, конвертація диска та синхронізація даних? Експорт OVA/OVF переносить усю машину одним файлом – він передбачуваний, але потребує повного сервісного вікна і місця на дві копії диска. Конвертація дисків (VMDK у QCOW2, найкраще інструментом virt-v2v, який водночас вставляє драйвери) підходить для appliance’ів, які не поставиш з інсталятора. Синхронізація на рівні системи – чиста машина в новому середовищі плюс перенесення самих даних – дає найкоротше вікно і не тягне за собою залишків від VMware.

Чому Windows або Linux не запускається після міграції з VMware на KVM? Найчастіша причина – відсутність драйверів virtio: Windows завершується помилкою зупинки «inaccessible boot device», а Linux з initramfs, зібраним без модулів virtio, зупиняється на відсутності диска. Двоє інших підозрюваних – несумісність режиму старту (машина UEFI, запущена як BIOS) та fstab, описаний назвами пристроїв замість ідентифікаторів UUID. Ліки застосовують перед вимкненням машини-джерела: доінсталювання драйверів і перезбирання initramfs або конвертація через virt-v2v.

Чи мої дані залишаться в Європі? Так. Інфраструктура, на якій ми надаємо послуги, розташована на території Польщі – це декларує наша Політика конфіденційності; той самий документ описує винятки (аналітичні та розрахункові дані, які обробляють постачальники з-поза ЄЕЗ на стандартних договірних положеннях). Договір про доручення обробки (DPA) разом зі списком субпідрядників ми надаємо клієнтам на запит. Чому для частини організацій це вирішальний аргумент, ми описали в тексті про польську хмару обчислень.

Ми хочемо залишитися у себе. Допоможете? Так – обсяг (проєкт, впровадження CloudStack на вашому обладнанні, перенесення машин, навчання команди) ми узгоджуємо індивідуально. CloudStack – це вільне програмне забезпечення, тож після завершення проєкту середовище залишається вашим.

Підсумок

Міграція з VMware не є складною технічно – вона складна організаційно. Конвертація диска – це кілька команд; те, чи перемикання закінчиться о другій ночі, чи о шостій ранку, визначають графік хвиль, карта залежностей, підготовлені завчасно драйвери та узгоджений момент відступу. А якщо рахунок усе ще відкритий і поруч із CloudStack ви прораховуєте також гіперскейлерів, вам допоможе зіставлення гіперскейлер чи польська хмара.

Найдешевший перший крок – це розмова і тест на одній машині: ми проходимо через вашу інвентаризаційну таблицю, показуємо, як виглядає робота в панелі, і кажемо прямо, що перенесеться гладко, а що вимагатиме роботи. Напишіть нам або подивіться публічну хмару WebDisk.

Міграція з VMware до WebDisk Cloud: що переносити, у якому порядку і чим це робити