Років 7 тому перші проекти переїжджали в нашу хмару просто і невигадливо. Образи віртуальних машин завантажувалися на FTP-сервер, або привозили їх на жорстких дисках. Потім через спеціальний імпорт-сервер ВМ завантажували у хмару.
Якщо для клієнта не проблема вимкнути віртуалку на добу-дві (або немає інших варіантів), то можна й так. Але якщо простий має бути максимум година, то такий спосіб не підійде. Сьогодні розповім, які інструменти допоможуть мігрувати в хмару з мінімальним простоєм і як влаштований сам процес міграції у нас.
Міграція за допомогою Veeam Backup and Replication
Veeam Backup and Replication всі знають як інструмент для створення бекапів та реплік. Ми його використовуємо для міграції між нашими майданчиками та для перевезення клієнтів із приватної віртуалізації до нас у хмару. Віртуальні машини клієнта реплікуються на наш vCenter, після чого інженер додає їх до vCloud Director.
Первинна реплікація виконується на увімкненій віртуальній машині. У погоджений час машина за клієнта вимикається. Реплікація запускається ще раз, щоб перенести зміни, що сталися з першої реплікації. Після цього віртуальна машина стартує вже в нашій хмарі.
Зазвичай з моменту вимикання машини на інфраструктурі клієнта і до моменту включення в нашій хмарі проходить не більше півгодини, а скоріше 15-20 хвилин.
У цьому на майданчику клієнта залишається вихідна віртуальна машина. Якщо раптом щось йде не так, завжди можна відкотитись та включити її. Для клієнта цей спосіб ще й зручний тим, що не потребує наявності Veeam.
Кейс 1
У клієнта була своя віртуальна інфраструктура на базі VMware – 40 ВМ об'ємом 30 Тб. Обладнання, на якому було розгорнуто кластер, вже застаріло, і клієнт вирішив не зв'язуватися із закупівлею нового та переїхати в публічну хмару. Вимога до простою критичних систем була трохи більше години. Як інструмент вибрали Veeam Replication. Плюсом також було те, що інтернет-провайдер клієнта був у нашому ЦОДі, що дозволило організувати хороший канал. Міграція зайняла близько місяця, простий при перемиканні становив до 30 хвилин на одну групу віртуальних машин.
Міграція за допомогою Veeam Cloud Connect
Veeam Cloud Connect – інструмент, що допомагає настроювати реплікацію віртуальних машин та запускати репліки у хмарі сервіс-провайдера. Після оновлення в році з'явилася можливість реплікувати віртуальні машини одразу в vCloud Director. Єдина умова – на стороні клієнта має бути розгорнутий свій Veeam Backup and Replication не нижче версії 9. Якщо коротко (докладна версія ), то весь процес виглядає так.
vCloud Director створюється організація з необхідними ресурсами та мережами. У Veeam Cloud Connect ми створюємо обліковий запис, клієнт до нього підключається зі свого Veeam B&R, вибирає провайдера DataLine та організацію, налаштовує завдання для реплікації. Крім того, що при такій міграції простий буде в межах 15-20 хвилин, клієнт ніяк не залежить від техпідтримки провайдера і керує всім процесом самостійно: створює завдання на реплікацію, реплікацію, вимикає машини і запускає їх старт на новому майданчику.
Кейс 2
Інфраструктура клієнта, звідки планувалась міграція, розташовувалася в Білорусії. Потрібно було перевезти 90 ВМ сумарним обсягом 27 Тб, при тому, що інтернет-канал був 100 мбіт/сек. Якщо робити бекап і одразу заливати його до нас у хмару, то для деяких ВМ це зайняло б кілька діб. За цей час на ВМ виросла б велика дельта, а це вже могло негативно вплинути на продуктивність машин або ще гірше місце на датасторі закінчилося. Діяли таким чином: спочатку клієнт зробив локальний повний бекап і переніс його копію до нас у хмару через Veeam Cloud Connect. Потім зробив і перекинув у хмару інкремент. Початкова віртуальна машина продовжувала працювати. Після вимкнення ВМ клієнт зробив ще один інкремент і також переніс у хмару. На своєму боці ми розгорнули віртуальну машину з повного бекапу, а потім докотили на неї два інкременти. Така схема дозволила зрештою мінімізувати простий до 2 годин при перемиканні на наш майданчик.
Міграція за допомогою VMware vCloud Availability
У березні цього року VMware випустила vCloud Availability 3.0, який дозволяє мігрувати віртуальним машинам між різними хмарами (vCloud Director – vCloud Director) та приватними стендами віртуалізації клієнта в хмару (vCenter – vCloud Director). Основною зручністю є інтеграція з інтерфейсом vCloud Director. Це значно спрощує процес управління реплікацією та зводить до мінімуму простий при перемиканні.
За допомогою цього інструменту ми мігрували одного з клієнтів з нашої московської хмари до нашої хмари в Пітері. Потрібно було перевезти 18 віртуальних машин сумарною ємністю 14 Тб. Для клієнта було створено організацію в пітерській хмарі та організовано необхідні мережі. Далі з інтерфейсу vCloud Director клієнт перейшов до налаштувань vCloud Availability, створив завдання реплікації та у зручний для нього час переключився на пітерський майданчик. Простий при перемиканні становив 12 хвилин.
Схема міграції між хмарами DataLine у Пітері та Москві.
VCloud Availability має механізм міграції ВМ з майданчика клієнта в нашу хмару. Для цього в vCenter клієнта розгортається спеціальний апплаєнс vCloud Availability. Після нескладного налаштування виконується підключення до хмари та налаштовуються завдання міграції. Клієнт також самостійно керує всім процесом, і час міграції зводиться до мінімуму.
Схема міграції віртуальних машин із приватної інсталяції у хмару.
VMware vCloud Availability має багато інших сценаріїв використання, скоро розповімо про них в окремій статті.
Підготовка до міграції
Щоб вибрати інструмент і власне розпочати міграцію, потрібно визначитися з наступними моментами:
Звідки мігруємо. Якщо ви мігруєте з приватного рішення, то у вас є повна свобода у виборі інструментів. Якщо ви з'їжджаєте від провайдера, то тут складніше. Швидше за все, зв'язати інфраструктури двох провайдерів та просто перетягнути ВМ не вийде через міркування безпеки. Іноді провайдер, від якого клієнт збирається відмовитись, і зовсім починає шкодувати і тягне час. З'їжджати від провайдера можна по-старому: через вивантаження ВМ на диски та FTP або мігрувати на рівні програми. Назва останнього умовна, і це виглядає приблизно так.
Кейс 3
Потрібно мігрувати SAP-систему клієнта від європейського провайдера: 34 ВМ об'ємом 54 Тб. Клієнту було виділено ресурси в нашій хмарі. Між нами та інфраструктурою європейського провайдера було організовано мережевий зв'язок. Сервера додатків були знову розгорнуті, з накатом необхідних конфігурацій. Великі бази даних мігрували через завантаження бекапів у нашу хмару. Далі була налаштована реплікація між базами даних на нашому та вихідному майданчиках. У погоджений час ми переключили на бази даних у нашій хмарі.
Обсяг даних та інтернет-канал. Ми зазвичай просимо клієнта надати вивантаження по системах із параметрами пам'яті, CPU, дисків. Оцінюємо, чи вистачить каналу, щоб безпосередньо відправляти репліки чи бекапи віртуальних машин.
Допустимий простий. Для різних систем і, відповідно, віртуальних машин він може бути різним залежно від їхньої критичності для бізнесу. Зазвичай клієнт приходить з готовими вимогами простою при міграції, і на підставі цього ми вибираємо відповідний інструмент і план міграції. Ми намагаємося планувати фінальне перемикання на нічний час або вихідні, щоб навіть незначний простий не був помітним для кінцевих користувачів клієнта.
Виходячи з цих даних, можна вибирати інструмент і приступати до самої міграції. Ось що відбувається далі.
- Налаштування мережного зв'язку. Ми організуємо мережевий зв'язок між нашою хмарою та інфраструктурою клієнта. Цією мережею копіюватимуться віртуальні машини. Якщо використовується Veeam Backup and Replication, це виділений канал, рідше – VPN-канал. Якщо Veeam Cloud Connect, все йде через інтернет або той же виділений канал.
Потім налаштовується мережа для ВМ у хмарі. Машини зазвичай переїжджають групами та не один день. Після того, як ВМ перенесли до нас і запустили, вони повинні взаємодіяти з машинами, які все ще залишаються на вихідному майданчику.
- Розклад міграції. Коли машин багато, розумно розбивати їх на групи та перевозити партіями. Спільно з клієнтом ми погоджуємо план, в якому прописуємо, коли та які машини переїжджають і коли буде виконано фінальну реплікацію та перемикання на новий майданчик.
- Тестова міграція. Мігруємо тестову віртуальну машину та перевіряємо, чи все правильно налаштовано: мережна зв'язність між майданчиками, доступність віртуальної машини для машин на вихідному майданчику, права облікового запису та інше. Такий тест допомагає уникнути заминок на етапі бойової міграції.
На цьому маю все. У коментарях ставте запитання та розповідайте про свій досвід міграції.
Джерело: habr.com