Гадоў 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) і c прыватных стэндаў віртуалізацыі кліента ў воблака (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