Операция „Миграция“: как да се преместите в облака DataLine

Преди около 7 години първите проекти се преместиха в нашия облак просто и непретенциозно. Изображенията на виртуалната машина са качени на FTP сървър или са доставени на твърди дискове. След това чрез специален сървър за импортиране виртуалните машини бяха качени в облака.

Ако за клиента не е проблем да изключи виртуалната машина за ден-два (или няма други опции), тогава това може да се направи. Но ако времето за престой трябва да бъде максимум час, тогава този метод няма да работи. Днес ще ви кажа какви инструменти ще ви помогнат да мигрирате към облака с минимално време на престой и как работи самият процес на миграция.

Миграция с Veeam Backup and Replication

Всеки познава Veeam Backup and Replication като инструмент за създаване на резервни копия и реплики. Използваме го за миграция между нашите сайтове и за транспортиране на клиенти от частна виртуализация към нашия облак. Виртуалните машини на клиента се копират в нашия vCenter, след което инженерът ги добавя към vCloud Director.

Първичната репликация се извършва на включена виртуална машина. В уговореното време клиентската машина се изключва. Репликацията се изпълнява отново, за да пренесе промените, настъпили след първото репликиране. След това виртуалната машина стартира в нашия облак.

Обикновено от момента, в който машината е изключена в инфраструктурата на клиента до момента, в който е включена в нашия облак, минава не повече от половин час, а по-скоро 15-20 минути.

В този случай оригиналната виртуална машина остава на сайта на клиента. Ако изведнъж нещо се обърка, винаги можете да се върнете назад и да го включите. Този метод е удобен и за клиента, тъй като не изисква да има Veeam.

Случай 1
Клиентът разполагаше със собствена виртуална инфраструктура, базирана на VMware - 40 VM с капацитет 30 TB. Оборудването, на което беше разположен клъстерът, вече беше остаряло и клиентът реши да не си прави труда да купува нови и се премести в публичния облак. Изискването за престой за критични системи беше не повече от час. Като инструмент беше избран Veeam Replication. Друг плюс беше, че интернет доставчикът на клиента присъстваше в нашия център за данни, което направи възможно организирането на добър канал. Миграцията отне около месец, времето на престой по време на превключване беше до 30 минути на група виртуални машини.

Мигрирайте с Veeam Cloud Connect

Veeam Cloud Connect е инструмент, който ви помага да настроите репликация на виртуална машина и да стартирате реплики в облака на доставчика на услуги. След актуализиране до 2019 година стана възможно да се репликират виртуални машини директно във vCloud Director. Единственото условие е, че от страна на клиента Veeam Backup and Replication трябва да бъде внедрена поне версия 9. Накратко (подробна версия тук), тогава целият процес изглежда така.

Във vCloud Director се създава организация с необходимите ресурси и мрежи. Във Veeam Cloud Connect създаваме акаунт, клиентът се свързва с него от своя Veeam B&R, избира доставчик и организация на DataLine и конфигурира задачи за репликация. В допълнение към факта, че по време на такава миграция времето на престой ще бъде в рамките на 15-20 минути, клиентът не зависи по никакъв начин от техническата поддръжка на доставчика и управлява целия процес независимо: създава задачи за репликация, самата репликация се изключва машините и ги стартира на новия сайт.

Случай 2
Инфраструктурата на клиента, откъдето е планирана миграцията, се намира в Беларус. Беше необходимо да се транспортират 90 виртуални машини с общ обем от 27 TB, въпреки факта, че интернет каналът беше 100 Mbit/sec. Ако направите резервно копие и веднага го качите в нашия облак, тогава за някои виртуални машини това ще отнеме няколко дни. През това време голяма делта би нараснала във VM и това може да има отрицателно въздействие върху производителността на машините или, още по-лошо, мястото в хранилището за данни щеше да свърши. Продължихме по следния начин: първо, клиентът направи локално пълно архивиране и прехвърли копие от него в нашия облак чрез Veeam Cloud Connect. След това направих и прехвърлих увеличението в облака. Оригиналната виртуална машина продължи да работи. След като изключи VM, клиентът направи още едно увеличение и също го прехвърли в облака. От наша страна разположихме виртуална машина от пълно архивиране и след това превъртяхме две стъпки върху нея. Тази схема в крайна сметка направи възможно минимизирането на времето за престой до 2 часа при превключване към нашия сайт.

Миграция с наличност на VMware vCloud

През март тази година VMware пусна vCloud Availability 3.0, който ви позволява да мигрирате виртуални машини между различни облаци (vCloud Director - vCloud Director) и от частни клиентски щандове за виртуализация към облака (vCenter - vCloud Director). Основното удобство е интеграцията с интерфейса vCloud Director. Това значително опростява процеса на управление на репликацията и минимизира времето за престой по време на превключване.

С помощта на този инструмент мигрирахме един от клиентите от нашия московски облак в нашия облак в Санкт Петербург. Беше необходимо да се транспортират 18 виртуални машини с общ капацитет 14 TB. Създадена е организация за клиента в облака Санкт Петербург и са организирани необходимите мрежи. След това от интерфейса на vCloud Director клиентът отиде в настройките за наличност на vCloud, създаде задания за репликация и превключи към сайта в Санкт Петербург в удобно за него време. Престоят по време на превключването беше 12 минути.

Схема за миграция между облаците DataLine в Санкт Петербург и Москва.

vCloud Availability има механизъм за мигриране на виртуални машини от сайта на клиента към нашия облак. За да направите това, във vCenter на клиента се разполага специално приложение за vCloud Availability. След проста настройка се свързвате с облака и конфигурирате задачи за мигриране. Клиентът също управлява целия процес независимо и времето за миграция е сведено до минимум.

Схема за мигриране на виртуални машини от частна инсталация към облака.

VMware vCloud Availability има много други случаи на употреба; скоро ще говорим за тях в отделна статия.

Подготовка за миграция

За да изберете инструмент и действително да започнете мигрирането, трябва да вземете решение относно следните точки:

Откъде да мигрираме? Ако мигрирате от частно решение, тогава имате пълна свобода при избора на инструменти. Ако се отдалечите от вашия доставчик, тогава е по-сложно. Най-вероятно свързването на инфраструктурите на два доставчика и простото плъзгане и пускане на виртуална машина няма да работи поради съображения за сигурност. Понякога доставчикът, на когото клиентът се кани да откаже, започва да злослови и да се задържа. Можете да се отдалечите от доставчика по старомодния начин: чрез качване на виртуални машини на дискове и FTP или чрез мигриране на ниво приложение. Името на последното е условно и изглежда по следния начин.

Случай 3
Беше необходимо да се мигрира SAP системата на клиента от европейски доставчик: 34 VM с капацитет 54 TB. На клиента бяха разпределени ресурси в нашия облак. Беше организирана мрежова свързаност между нас и инфраструктурата на европейския доставчик. Сървърите на приложения бяха преразположени, като необходимите конфигурации бяха прехвърлени. Големите бази данни бяха мигрирани чрез качване на резервни копия в нашия облак. След това беше конфигурирана репликация между базите данни на нашия и оригиналния сайт. В уговореното време преминахме към бази данни в нашия облак.

Обем данни и интернет канал. Обикновено молим клиента да предостави качване по система с параметри на паметта, процесора и диска. Оценяваме дали каналът е достатъчен за директно изпращане на реплики или резервни копия на виртуални машини.

Приемлив престой. За различните системи и съответно виртуални машини може да е различно в зависимост от тяхната бизнес критичност. Обикновено клиентът идва с готови изисквания за престой за миграция и въз основа на това ние избираме подходящия инструмент и план за миграция. Опитваме се да насрочим окончателното превключване през нощта или през почивните дни, така че дори и незначителни прекъсвания да не бъдат забележими за крайните потребители на клиента.

Въз основа на тези данни можете да изберете инструмент и да започнете самата миграция. Ето какво се случва след това.

1. Настройка на мрежова свързаност. Ние организираме мрежова свързаност между нашия облак и инфраструктурата на клиента. Виртуалните машини ще бъдат копирани през тази мрежа. Ако се използва Veeam Backup and Replication, тогава това е специален канал, по-рядко VPN канал. Ако Veeam Cloud Connect, тогава всичко минава през интернет или същия специален канал.

   След това мрежата се конфигурира за VM в облака. Автомобилите обикновено се движат на групи и за повече от един ден. След като виртуалните машини бъдат донесени до нас и стартирани, те трябва да комуникират с машините, които все още остават на оригиналния сайт.

2. График за миграция. Когато има много автомобили, има смисъл да ги разделите на групи и да ги транспортирате на партиди. Съвместно с клиента съгласуваме план, в който уточняваме кога и кои машини ще се преместят и кога ще се извърши финалната репликация и превключване към новия сайт.
3. Тестова миграция. Ние мигрираме тестовата виртуална машина и проверяваме дали всичко е конфигурирано правилно: мрежова свързаност между сайтове, наличност на виртуалната машина за машини на сайта източник, права на акаунт и т.н. Този тест помага да се избегнат спънки на етапа на бойна миграция.

Това е всичко за мен. В коментарите задавайте въпроси и ни разкажете за вашия опит с миграцията.

Източник: www.habr.com