Yeddi il əvvəlki ilk layihələr buludumuza sadə və həm də asan şəkildə köçürülürdü. Virtual maşınların şəkilləri FTP-serverə yüklənir, ya da sərt disklərlə gətirilirdi. Sonra xüsusi idxal serveri vasitəsi ilə VM-lər buluda yüklənirdi.
Əgər müştəri üçün virtual maşını bir iki gün söndürmək problem deyilsə (ya da başqa variant yoxdursa), o zaman bu cür mümkündür. Lakin, dayanmaların maksimum bir saat olmasını istəsələr, belə bir üsul uyğun olmayacaq. Bu gün, buluda minimal dayanmalarla köçürmə üçün hansı alətlərin kömək olacağını və köçürmə prosesinin necə təşkil olunduğunu izah edəcəyəm.
Veeam Backup and Replication vasitəsi ilə köçürmə
Veeam Backup and Replication, ehtiyat nüsxələrin və replika yaratmaq üçün bir araç olaraq məşhurdur. Biz onu öz məkanlarımız arasında köçürmə üçün və müştəriləri özəl virtualizasiyadan buludumuza köçürmək üçün istifadə edirik. Müştərinin virtual maşınları bizim vCenter-də replika edilir, sonra mühəndis onları vCloud Director-a əlavə edir.
İlk replika aktiv virtual maşında həyata keçirilir. Müəyyən edilmiş vaxtda müştəri tərəfindəki maşın söndürülür. Replika prosesində bir daha başlayır, beləliklə, ilk replika başlamasından sonra baş verən dəyişikliklər köçürülür. Bundan sonra virtual maşın bizim buludda işə salınır.
Adətən müştərinin infrastrukturasında maşın söndürüldükdən və bizim buludda işə salınmasına qədər 30 dəqiqədən çox vaxt keçmir, daha çox 15-20 dəqiqədir.
Bu zaman müştəri tərəfində ilkin virtual maşın qalır. Əgər birdən nəsə yolunda getməzsə, həmişə ondan geri dönüb tanış edə bilər. Müştəri üçün bu üsul həmçinin Veeam-a sahib olmağı tələb etmədiyi üçün də rahatdır.
Məsələ 1
Müştərinin VMware bazasında öz virtual infrastrukturu var idi – 40 VM 30 TB həcmində. Klasterin yerləşdiyi avadanlıq artıq köhnəlmişdi və müştəri yeni satın almayacağına qərar verdi və ictimai buluda köçməyi seçdi. Kritik sistemlərin dayanmaları tələbi daha çox bir saatdan çox olmamalıdır. Alət kimi Veeam Replication seçildi. Həmçinin müştərinin internet provayderinin bizim Mərkəzdə olması yaxşı bir kanalın qurulmasına imkan tanıdı. Məsafə təxminən bir ay sürdü, keçid zamanı dayanma bir qrup virtual maşın üçün 30 dəqiqəyə qədərdir.
Veeam Cloud Connect vasitəsi ilə köçürmə
Veeam Cloud Connect, virtual maşınların replika qurmağı və servis provayderinin buludunda replikalarını işə salmağı asanlaşdıran bir alətdir. Yeniləmədən sonra ilində virtual maşınları birbaşa vCloud Director-a replika etmək imkanı yarandı. Tək tələb odur ki, müştəri tərəfində öz Veeam Backup and Replication-in 9-cu versiyasından aşağı olmayanının quraşdırılması gereklidir. Qısaca (ətraflı versiya ), bu proses belə görünür.
vCloud Director-da lazım olan resurslar və şəbəkələrlə bir təşkilat yaradılır. Veeam Cloud Connect-də bir hesab yaradaraq, müştəri öz Veeam B&R-dən qoşulur, DataLine provayderini seçir və təşkilatı təyin edir, replikasiya tapşırıqlarını konfiqurasiya edir. Bu cür mühacirətdə durğunluq 15-20 dəqiqə arasında olacaq, müştəri provayderin texniki dəstəyindən asılı olmayacaq və bütün prosesi özü idarə edəcək: replikasiya tapşırıqları yaradır, replikasiyanı həyata keçirir, maşınları söndərir və onları yeni yerdə işə salır.
Məsəl 2
Müştərinin mühacirət planladığı infrastruktur Belarusda yerləşirdi. 27 TB-lıq cəmi həcmi olan 90 VM-nin daşınması lazım idi, internet kanalı isə 100 Mbit/s olub. Kopyalasalar və onu dərhal buluda yükləsələr, bəzi VM-lər üçün bu proses bir neçə gün çəkə bilərdi. Bu müddət ərzində VM-də böyük bir delta yaranardı, bu isə maşınların performansına mənfi təsir edə bilərdi, ya da daha pis halda, datastore-da yer tükənə bilərdi. Bu şəkildə hərəkət edirdilər: əvvəlcə müştəri lokaldan tam bir backup etdi və onun kopyasını Veeam Cloud Connect vasitəsi ilə buluda apardı. Sonra inkrement yaratdı və buluda göndərdi. Əsas virtual maşın işini davam etdirirdi. VM söndürüldükdən sonra müştəri yenidən bir inkrement etdi və onu da buluda apardı. Biz öz tərəfimizdə tam backup-dan virtual maşın yaratdıq və sonra iki inkrementi ona əlavə etdik. Bu sxema nəticədə bizim platformaya keçid zamanı durğunluğu 2 saata minimuma endirdi.
VMware vCloud Availability vasitəsilə mühacirət
Bu ilin martında VMware vCloud Availability 3.0-ı buraxdı ki, bu da virtual maşınların müxtəlif buludlar arasında (vCloud Director – vCloud Director) və müştərinin öz privat virtualizasiya stendindən buluda (vCenter – vCloud Director) mühacirət etməyə imkan tanıyır. Əsas rahatlıq vCloud Director interfeysi ilə inteqrasiya olunmasıdır. Bu, replikasiyanı idarə etmə prosesini xeyli sadəcə edərək, keçid zamanı durğunluğu minimuma endirir.
Bu alətlə biz müştərilərimizdən birini Moskvadakı buludumuzdan Sankt-Peterburqdakı buludumuza mühacirət etdik. 14 TB-lıq cəmi həcmi olan 18 virtual maşının daşınması lazım idi. Müştəri üçün Sankt-Peterburq buludunda bir təşkilat yaradıldı və lazım olan şəbəkələr təşkil edildi. Daha sonra müştəri vCloud Director interfeysindən vCloud Availability ayarlarına keçdi, replikasiya tapşırıqları yaratdı və özünə rahat vaxtda Peterburqdakı platformaya keçdi. Keçid zamanı durğunluq 12 dəqiqə oldu.
DataLine-in Sankt-Peterburq və Moskva arasında buludlararası mühacirət sxeması.
vCloud Availability-də müştərinin platformasından buludumuza VM-lərin köçürülməsi üçün bir mexanizm mövcuddur. Bunun üçün müştərinin vCenter-i içində xüsusi bir vCloud Availability appliance-i yerləşdirilir. Sadə konfiqurasiyadan sonra buluda qoşulma həyata keçirilir və köçürülmə tapşırıqları yaradılır. Müştəri fəaliyyətini tam şəkildə öz idarəsinə alır və köçürmə müddəti minimuma endirilir.
Müxtəlif virtual maşınların özəl quraşdırmadan buluda köçürülməsi sxemi.
VMware vCloud Availability-nin bir çox başqa istifadə senariləri var, tezliklə bunlar haqqında ayrı bir məqalədə danışacağıq.
Köçürməyə hazırlıq
Aləti seçmək və köçürməyə başlamaq üçün aşağıdakı məsələlərlə aydın olmalısınız:
Haradan köçürürük. Əgər siz özəl həll yolu ilə köçürürsünüzsə, alətlərin seçimində tam azadlığınız var. Əgər provayderdən çıxırsınızsa, burada vəziyyət daha mürəkkəbdir. Çox güman ki, iki provayderin infrastrukturlarını birləşdirərək sadəcə VM-ləri köçürmək mümkün olmayacaq, çünki təhlükəsizlik məsələləri bu işdə maneə ola bilər. Bəzən müştəri ayrılmağa qərar verəndə provayder çətinlik yaratmağa başlayır və müddəti uzadır. Provayderdən ayrılmanın ənənəvi yolu disklərə VM-lərin yüklənməsi və FTP vasitəsilə həyata keçirilir, yaxud tətbiq səviyyəsində köçürülmə baş verə bilər. İkinci yolun adı şərtidir və təxminən belə görünür.
Məsələ 3
Müəyyən edilmiş hesablara görə müştərinin SAP sistemini Avropa provayderindən köçürmək lazım idi: 34 VM, həcmi 54 TB. Müştəriyə buludumuzda resurs ayrıldı. Bizimlə Avropa provayderinin infrastrukturu arasında şəbəkə əlaqəsi təşkil edildi. Tətbiq serverləri yenidən quraşdırıldı, lazım olan konfiqurasiyalar yükləndi. Böyük verilənlər bazaları buludumuza yedəkləmə yükləmələri vasitəsilə köçürüldü. Sonra bizim və ilkin platformadakı verilənlər bazaları arasında replikasiya quruldu. Razılaşdırılmış vaxtda buludumuzdakı verilənlər bazalarına keçid edildi.
Verilənlərin həcmi və internet kanalı. Adətən müştəridən yaddaş, CPU, disk parametrləri olan sistemlər üçün yükləməni təqdim etmələrini istəyirik. Daxil olan replikaların və ya virtual maşınların yedəklərinin birbaşa göndərilməsi üçün kanalın kifayət qədər olub olmadığını dəyərləndiririk.
Qəbul edilən dayandırma. Müxtəlif sistemlər və müvafiq olaraq virtual maşınlar üçün bu, biznesin əhəmiyyətinə bağlı olaraq müxtəlif ola bilər. Adətən müştəri köçürmə zamanı dayandırma üçün hazır tələblərlə gəlir, və bu əsasında uyğun aləti və köçürmə planını seçirik. Həmişə son keçidi gecə saatlarında və ya həftə sonları planlaşdırmağa çalışırıq ki, hətta kiçik dayandırma son istifadəçilər üçün görünməsin.
Bu məlumatlara əsaslanaraq aləti seçmək və köçürməyə başlamaq mümkündür. Sonra bu baş verir.
- Şəbəkə əlaqəsinin qurulması. Biz buludumuz ilə müştərinin infrastrukturu arasında şəbəkə bağlantısı təşkil edirik. Bu şəbəkə vasitəsilə virtual maşınlar köçürüləcək. Əgər Veeam Backup and Replication istifadə olunursa, o zaman bu xüsusi kanaldır, nadir hallarda isə – VPN kanalıdır. Əgər Veeam Cloud Connect istifadə olunursa, o zaman hər şey internet vasitəsilə və ya eyni xüsusi kanal vasitəsilə həyata keçirilir.
Sonra buludda VM üçün şəbəkə konfiqurasiya edilir. Maşınlar adətən qruplar halında köçürülür və bu proses bir neçə gün çəkə bilər. VM-lar bizə köçürüldükdən və işə salındıqdan sonra, hələ də köhnə platformada qalan maşınlarla əlaqə saxlamalıdırlar.
- Köçürmə cədvəli. Maşın sayı çox olduqda, onları qruplara bölmək və partiya ilə daşımaq məntiqlidir. Müştəri ilə birlikdə, hansı maşınların nə vaxt köçəcəyini və son replikasiyanın nə zaman həyata keçiriləcəyini müəyyən etdiyimiz bir plan tərtib edirik.
- Sınaq köçürməsi. Sınaq virtual maşınını köçürürük və bütün konfiqurasiyaların düzgün olub-olmadığını yoxlayırıq: platformalar arasında şəbəkə bağlantısı, virtual maşının köhnə platformadakı maşınlara əlçatanlığı, hesabın hüquqları və s. Belə bir test əməliyyat köçürməsi mərhələsində gecikmələrin qarşısını almağa kömək edir.
Bununla da mənim sizə demək istəyim bu qədər. Şərhlərdə suallarınızı verə bilər və köçürmə təcrübənizlə bölüşə bilərsiniz.
Mənbə: habr.com
