Taxminan 7 yil oldin, birinchi loyihalar bizning bulutimizga oddiy va oddiy tarzda o'tdi. Virtual mashina tasvirlari FTP serveriga yuklangan yoki ular qattiq disklarga yetkazilgan. Keyin maxsus import serveri orqali VMlar bulutga yuklandi.
Agar mijoz virtual mashinani bir yoki ikki kunga o'chirishda muammo bo'lmasa (yoki boshqa variantlar bo'lmasa), unda buni qilish mumkin. Ammo agar to'xtash vaqti maksimal bir soat bo'lishi kerak bo'lsa, unda bu usul ishlamaydi. Bugun men sizga qanday vositalar bulutga minimal uzilishlar bilan o'tishga yordam berishini va bizning migratsiya jarayonimizning o'zi qanday ishlashini aytib beraman.
Veeam Backup va Replication yordamida migratsiya
Hamma Veeam Backup and Replication-ni zahira va nusxalarni yaratish vositasi sifatida biladi. Biz uni saytlarimiz o'rtasida ko'chirish va mijozlarni shaxsiy virtualizatsiyadan bulutga o'tkazish uchun foydalanamiz. Mijozning virtual mashinalari bizning vCenter-ga takrorlanadi, shundan so'ng muhandis ularni vCloud Director-ga qo'shadi.
Birlamchi replikatsiya yoqilgan virtual mashinada sodir bo'ladi. Kelishilgan vaqtda mijoz tomoni mashinasi o'chiriladi. Replikatsiya birinchi takrorlashdan keyin sodir bo'lgan o'zgarishlarni o'tkazish uchun qayta ishlaydi. Shundan so'ng virtual mashina bizning bulutimizda ishga tushadi.
Odatda, mijozning infratuzilmasida mashina o'chirilgan paytdan boshlab u bizning bulutimizda yoqilgunga qadar yarim soatdan ko'proq vaqt o'tmaydi, aksincha 15-20 daqiqa.
Bunday holda, original virtual mashina mijoz saytida qoladi. Agar to'satdan biror narsa noto'g'ri bo'lsa, siz har doim orqaga qaytib, uni yoqishingiz mumkin. Bu usul mijoz uchun ham qulay, chunki u Veeamga ega bo'lishini talab qilmaydi.
1-holat
Mijoz VMware asosidagi o'zining virtual infratuzilmasi - sig'imi 40 TB bo'lgan 30 VMga ega edi. Klaster o'rnatilgan uskunalar allaqachon eskirgan va mijoz yangilarini xarid qilish bilan bezovta qilmaslikka qaror qildi va ommaviy bulutga o'tdi. Muhim tizimlar uchun ishlamay qolish talabi bir soatdan ortiq emas edi. Asbob sifatida Veeam Replication tanlangan. Yana bir afzallik shundaki, mijozning Internet-provayderi bizning ma'lumotlar markazimizda mavjud bo'lib, bu yaxshi kanalni tashkil qilish imkonini berdi. Migratsiya taxminan bir oy davom etdi, almashtirish paytida to'xtash vaqti har bir virtual mashinalar guruhi uchun 30 daqiqagacha bo'lgan.
Veeam Cloud Connect bilan ko'chiring
Veeam Cloud Connect virtual mashina replikatsiyasini sozlash va xizmat ko'rsatuvchi provayder bulutida replikalarni ishga tushirishga yordam beruvchi vositadir. ga yangilangandan so'ng yili virtual mashinalarni to'g'ridan-to'g'ri vCloud Director-ga ko'paytirish mumkin bo'ldi. Yagona shart shundaki, mijoz tomonida Veeam Backup va Replication kamida 9-versiyani o‘rnatishi kerak. Qisqasi (batafsil versiya). ), keyin butun jarayon shunday ko'rinadi.
vCloud Director-da zarur resurslar va tarmoqlar bilan tashkilot yaratiladi. Veeam Cloud Connect-da biz hisob yaratamiz, mijoz unga Veeam B&R-dan ulanadi, DataLine provayderi va tashkilotini tanlaydi va replikatsiya uchun vazifalarni sozlaydi. Bunday migratsiya paytida ishlamay qolish vaqti 15-20 daqiqa ichida bo'lishiga qo'shimcha ravishda, mijoz hech qanday tarzda provayderning texnik yordamiga bog'liq emas va butun jarayonni mustaqil ravishda boshqaradi: replikatsiya vazifalarini yaratadi, replikatsiyaning o'zi, o'chadi. mashinalari va ularni yangi saytda ishga tushiradi.
2-holat
Migratsiya rejalashtirilgan joydan mijozning infratuzilmasi Belorussiyada joylashgan edi. Internet-kanal 90 Mbit/sek bo'lishiga qaramay, umumiy hajmi 27 TB bo'lgan 100 ta VMni tashish kerak edi. Agar siz zaxira nusxasini yaratsangiz va uni darhol bulutimizga yuklasangiz, ba'zi VMlar uchun bir necha kun kerak bo'ladi. Bu vaqt ichida VMda katta delta o'sib chiqqan bo'lardi va bu mashinalarning ishlashiga salbiy ta'sir ko'rsatishi yoki undan ham yomoni, ma'lumotlar omboridagi bo'sh joy tugashi mumkin edi. Biz quyidagicha harakat qildik: birinchidan, mijoz mahalliy toʻliq zaxira nusxasini yaratdi va uning nusxasini Veeam Cloud Connect orqali bulutimizga oʻtkazdi. Keyin men o'sishni yaratdim va bulutga o'tkazdim. Asl virtual mashina ishlashda davom etdi. VMni o'chirib qo'ygandan so'ng, mijoz yana bir o'sishni amalga oshirdi va uni bulutga o'tkazdi. Biz tomonimizdan, biz virtual mashinani to'liq zaxiradan joylashtirdik va keyin unga ikki marta o'stirdik. Ushbu sxema oxir-oqibat bizning saytimizga o'tishda ishlamay qolish vaqtini 2 soatgacha kamaytirishga imkon berdi.
VMware vCloud Availability bilan migratsiya
Joriy yilning mart oyida VMware vCloud Availability 3.0 versiyasini chiqardi, bu sizga virtual mashinalarni turli bulutlar (vCloud Director - vCloud Director) o'rtasida va shaxsiy mijoz virtualizatsiya stendlaridan bulutga (vCenter - vCloud Director) o'tkazish imkonini beradi. Asosiy qulaylik - vCloud Director interfeysi bilan integratsiya. Bu replikatsiyani boshqarish jarayonini sezilarli darajada osonlashtiradi va o'tish vaqtida ishlamay qolish vaqtini kamaytiradi.
Ushbu vositadan foydalanib, biz mijozlardan birini Moskva bulutimizdan Sankt-Peterburgdagi bulutimizga ko'chirdik. Umumiy sig'imi 18 TB bo'lgan 14 ta virtual mashinani tashish kerak edi. Sankt-Peterburg bulutida mijoz uchun tashkilot yaratildi va kerakli tarmoqlar tashkil etildi. Keyinchalik, vCloud Director interfeysidan mijoz vCloud Availability sozlamalariga o'tdi, replikatsiya ishlarini yaratdi va o'zi uchun qulay vaqtda Sankt-Peterburg saytiga o'tdi. Kommutatsiya paytida ishlamay qolish vaqti 12 daqiqani tashkil etdi.
Sankt-Peterburg va Moskvadagi DataLine bulutlari orasidagi migratsiya sxemasi.
vCloud Availability mijozning saytidan VM-larni bulutimizga ko'chirish mexanizmiga ega. Buning uchun mijozning vCenter-da maxsus vCloud Availability ilovasi o'rnatilgan. Oddiy sozlashdan so'ng siz bulutga ulanasiz va migratsiya vazifalarini sozlaysiz. Mijoz, shuningdek, butun jarayonni mustaqil ravishda boshqaradi va migratsiya vaqti minimal darajada saqlanadi.
Virtual mashinalarni shaxsiy o'rnatishdan bulutga o'tkazish sxemasi.
VMware vCloud Availability-da ko'plab boshqa foydalanish holatlari mavjud; biz ular haqida tez orada alohida maqolada gaplashamiz.
Migratsiyaga tayyorgarlik
Asbobni tanlash va aslida migratsiyani boshlash uchun siz quyidagi fikrlarni hal qilishingiz kerak:
Biz qayerdan migratsiya qilamiz? Agar siz shaxsiy yechimdan ko'chib o'tayotgan bo'lsangiz, unda siz vositalarni tanlashda to'liq erkinlikka egasiz. Agar siz provayderingizdan uzoqlashsangiz, unda bu yanada murakkab. Ehtimol, ikkita provayderning infratuzilmasini bog'lash va VMni sudrab olib tashlash xavfsizlik sabablari tufayli ishlamaydi. Ba'zida mijoz rad etmoqchi bo'lgan provayder beadablik qila boshlaydi va vaqtni to'xtatadi. Siz eski uslubda provayderdan uzoqlashishingiz mumkin: VM-larni disklarga va FTP-ga yuklash yoki dastur darajasida ko'chirish orqali. Ikkinchisining nomi shartli bo'lib, u shunday ko'rinadi.
3-holat
Mijozning SAP tizimini Yevropa provayderidan ko‘chirish kerak edi: sig‘imi 34 TB bo‘lgan 54 ta VM. Mijozga bizning bulutimizda resurslar ajratildi. Biz va Yevropa provayderi infratuzilmasi o'rtasida tarmoq ulanishi tashkil etildi. Ilova serverlari kerakli konfiguratsiyalar o'zgartirilgan holda qayta joylashtirildi. Katta ma'lumotlar bazalari bulutga zaxira nusxalarini yuklash orqali ko'chirildi. Keyinchalik, replikatsiya bizning va asl saytlarimizdagi ma'lumotlar bazalari o'rtasida tuzilgan. Kelishilgan vaqtda biz bulutdagi maʼlumotlar bazalariga oʻtdik.
Ma'lumotlar hajmi va Internet kanali. Biz odatda mijozdan tizim tomonidan xotira, protsessor va disk parametrlari bilan yuklashni soʻraymiz. Biz kanalning to'g'ridan-to'g'ri nusxalarini yoki virtual mashinalarning zaxira nusxalarini yuborish uchun etarli yoki yo'qligini baholaymiz.
Qabul qilinadigan ishlamay qolish vaqti. Turli tizimlar va shunga mos ravishda virtual mashinalar uchun ularning biznes kritikligiga qarab farq qilishi mumkin. Odatda mijoz migratsiya vaqtida ishlamay qolish uchun tayyor talablar bilan birga keladi va shu asosda biz tegishli vosita va migratsiya rejasini tanlaymiz. Biz oxirgi almashtirishni tunda yoki dam olish kunlarida rejalashtirishga harakat qilamiz, shunda hatto kichik to'xtab qolishlar mijozning oxirgi foydalanuvchilariga sezilmaydi.
Ushbu ma'lumotlarga asoslanib, siz vositani tanlashingiz va migratsiyani o'zi boshlashingiz mumkin. Mana, keyin nima bo'ladi.
- Tarmoqqa ulanishni sozlash. Biz bulut va mijoz infratuzilmasi o'rtasida tarmoq ulanishini tashkil qilamiz. Virtual mashinalar ushbu tarmoq orqali nusxalanadi. Agar Veeam Backup and Replication ishlatilsa, bu alohida kanal, kamroq VPN kanali. Agar Veeam Cloud Connect bo'lsa, unda hamma narsa Internet yoki bir xil maxsus kanal orqali o'tadi.
Keyin tarmoq bulutdagi VM uchun sozlanadi. Avtomobillar odatda guruhlarda va bir kundan ortiq harakatlanadi. VMlar bizga olib kelingan va ishga tushirilgandan so'ng, ular hali ham asl saytida qoladigan mashinalar bilan aloqa qilishlari kerak.
- Migratsiya jadvali. Avtomobillar ko'p bo'lsa, ularni guruhlarga bo'lish va ularni partiyalarda tashish mantiqan. Mijoz bilan birgalikda biz rejani kelishib olamiz, unda biz qachon va qaysi mashinalar harakatlanishini va oxirgi replikatsiya va yangi saytga o'tish qachon amalga oshirilishini aniqlaymiz.
- Sinov ko'chishi. Biz sinov virtual mashinasini o'tkazamiz va hamma narsa to'g'ri sozlanganligini tekshiramiz: saytlar o'rtasidagi tarmoq ulanishi, virtual mashinaning manba saytidagi mashinalarga mavjudligi, hisob huquqlari va boshqalar. Ushbu test jangovar migratsiya bosqichida muammolardan qochishga yordam beradi.
Men uchun hammasi shu. Izohlarda savollar bering va migratsiya tajribangiz haqida bizga xabar bering.
Manba: www.habr.com