Udakara 7 taun kepungkur, proyek sing pertama pindhah menyang awan kanthi gampang lan ora prelu. Gambar mesin virtual diunggah menyang server FTP, utawa dikirim ing hard drive. Banjur, liwat server impor khusus, VM diunggah menyang awan.
Yen ora ana masalah kanggo klien mateni mesin virtual sedina utawa rong dina (utawa ora ana pilihan liyane), mula iki bisa ditindakake. Nanging yen downtime kudu maksimal sak jam, cara iki ora bakal bisa. Dina iki, aku bakal ngandhani alat apa sing bakal mbantu sampeyan pindhah menyang awan kanthi downtime minimal lan kepiye proses migrasi kita dhewe.
Migrasi karo Veeam Backup lan Replikasi
Saben uwong ngerti Veeam Backup lan Replication minangka alat kanggo nggawe serep lan replika. Kita digunakake kanggo migrasi ing antarane situs kita lan kanggo ngangkut klien saka virtualisasi pribadi menyang awan. Mesin virtual klien direplikasi menyang vCenter kita, sawise insinyur nambahake menyang vCloud Director.
Replikasi utama dumadi ing mesin virtual sing aktif. Ing wektu sing disepakati, mesin sisih klien dipateni. Replikasi mlaku maneh kanggo nindakake owah-owahan sing wis kedadeyan wiwit replikasi pisanan. Sawise iki, mesin virtual diwiwiti ing awan kita.
Biasane, saka wayahe mesin dipateni ing infrastruktur klien nganti wayahe diuripake ing awan kita, ora luwih saka setengah jam liwat, nanging luwih 15-20 menit.
Ing kasus iki, mesin virtual asli tetep ing situs klien. Yen dumadakan ana masalah, sampeyan bisa muter maneh lan nguripake. Cara iki uga trep kanggo klien amarga ora mbutuhake dheweke duwe Veeam.
Kasus 1
Klien duwe infrastruktur virtual dhewe adhedhasar VMware - 40 VM kanthi kapasitas 30 TB. Peralatan sing dipasang kluster wis kuna, lan klien mutusake ora repot tuku sing anyar lan pindhah menyang awan umum. Persyaratan downtime kanggo sistem kritis ora luwih saka siji jam. Replikasi Veeam dipilih minangka alat. Plus liyane yaiku panyedhiya Internet klien ana ing pusat data kita, sing ndadekake bisa ngatur saluran sing apik. Migrasi njupuk udakara sewulan, downtime sajrone ngalih nganti 30 menit saben klompok mesin virtual.
Migrasi nganggo Veeam Cloud Connect
Veeam Cloud Connect minangka alat sing mbantu nyiyapake replikasi mesin virtual lan miwiti replika ing awan panyedhiya layanan. Sawise nganyari kanggo taun, dadi bisa kanggo niru mesin virtual langsung menyang vCloud Director. Siji-sijine syarat yaiku ing sisih klien, Veeam Backup lan Replication kudu disebarake paling ora versi 9. Singkatnya (versi rinci ), banjur kabeh proses katon kaya iki.
Ing Direktur vCloud, organisasi digawe kanthi sumber daya lan jaringan sing dibutuhake. Ing Veeam Cloud Connect, kita nggawe akun, klien nyambung saka Veeam B&R, milih panyedhiya lan organisasi DataLine, lan ngatur tugas kanggo replikasi. Saliyane kasunyatan manawa sajrone migrasi kasebut, downtime bakal ana ing 15-20 menit, klien ora gumantung ing dhukungan teknis panyedhiya lan ngatur kabeh proses kanthi mandiri: nggawe tugas replikasi, replikasi dhewe, dipateni. mesin lan miwiti ing situs anyar.
Kasus 2
Infrastruktur klien, saka ngendi migrasi direncanakake, dumunung ing Belarus. Sampeyan kudu ngeterake 90 VM kanthi volume total 27 TB, sanajan kasunyatane saluran Internet 100 Mbit / detik. Yen sampeyan nggawe serep lan langsung ngunggah menyang awan, banjur kanggo sawetara VM mbutuhake sawetara dina. Sak iki wektu, delta gedhe bakal thukul ing VM, lan iki bisa duwe impact negatif ing kinerja mesin utawa, malah Samsaya Awon, papan ing datastore bakal entek. Kita nerusake kaya ing ngisor iki: pisanan, klien nggawe serep lengkap lokal lan nransfer salinan kasebut menyang awan liwat Veeam Cloud Connect. Banjur aku nggawe lan mindhah increment menyang awan. Mesin virtual asli terus mlaku. Sawise mateni VM, klien nggawe tambahan liyane lan uga ditransfer menyang awan. Ing sisih kita, kita masang mesin virtual saka serep lengkap, lan banjur muter rong tambahan. Skema iki pungkasane bisa nyuda downtime nganti 2 jam nalika ngalih menyang situs kita.
Migrasi karo VMware vCloud kasedhiyan
Ing wulan Maret taun iki, VMware ngeculake vCloud Availability 3.0, sing ngidini sampeyan migrasi mesin virtual ing antarane awan sing beda (Direktur vCloud - Direktur vCloud) lan saka virtualisasi klien pribadi menyang awan (vCenter - Direktur vCloud). Penak utama yaiku integrasi karo antarmuka vCloud Director. Iki banget nyederhanakake proses manajemen replikasi lan nyuda downtime sajrone ngalih.
Nggunakake alat iki, kita migrasi salah sawijining klien saka awan Moskow menyang awan ing St. Sampeyan kudu ngangkut 18 mesin virtual kanthi kapasitas total 14 TB. Organisasi digawe kanggo klien ing awan St. Petersburg lan jaringan sing dibutuhake diatur. Sabanjure, saka antarmuka Direktur vCloud, klien pindhah menyang setelan Ketersediaan vCloud, nggawe proyek replikasi lan pindhah menyang situs St. Downtime sajrone ngalih yaiku 12 menit.
Skema migrasi antarane awan DataLine ing St. Petersburg lan Moskow.
Kasedhiyan vCloud duwe mekanisme kanggo migrasi VM saka situs klien menyang awan kita. Kanggo nindakake iki, aplikasi vCloud Availability khusus disebarake ing vCenter klien. Sawise persiyapan prasaja, sampeyan nyambung menyang awan lan ngatur tugas migrasi. Klien uga ngatur kabeh proses kanthi mandiri lan wektu migrasi tetep minimal.
Skema kanggo migrasi mesin virtual saka instalasi pribadi menyang awan.
Kasedhiyan VMware vCloud duwe akeh kasus panggunaan liyane; kita bakal ngomong babagan iki ing artikel sing kapisah.
Nyiapake kanggo migrasi
Kanggo milih alat lan bener miwiti migrasi, sampeyan kudu mutusake perkara ing ngisor iki:
Saka ngendi kita migrasi? Yen sampeyan pindhah saka solusi pribadi, sampeyan duwe kebebasan lengkap kanggo milih alat. Yen sampeyan pindhah saka panyedhiya, banjur luwih rumit. Paling kamungkinan, ngubungake infrastruktur loro panyedhiya lan mung nyeret lan nyelehake VM ora bakal bisa amarga alasan keamanan. Kadhangkala panyedhiya sing bakal ditolak klien wiwit nakal lan mandheg wektu. Sampeyan bisa pindhah saka panyedhiya kanthi cara lawas: kanthi ngunggah VM menyang disk lan FTP, utawa kanthi migrasi ing tingkat aplikasi. Jeneng sing terakhir iku kondisional, lan katon kaya iki.
Kasus 3
Sampeyan kudu migrasi sistem SAP klien saka panyedhiya Eropa: 34 VM kanthi kapasitas 54 TB. Klien dialokasikan sumber daya ing awan kita. Konektivitas jaringan diatur ing antarane kita lan infrastruktur panyedhiya Eropa. Server aplikasi disebarake maneh, kanthi konfigurasi sing dibutuhake digulung. Basis data gedhe dipindhah liwat upload serep menyang awan kita. Sabanjure, replikasi dikonfigurasi ing antarane database ing situs kita lan asli. Ing wektu sing disepakati, kita ngalih menyang database ing awan kita.
Volume data lan saluran Internet. Biasane kita njaluk klien menehi upload dening sistem kanthi parameter memori, CPU, lan disk. Kita ngevaluasi manawa saluran kasebut cukup kanggo ngirim langsung replika utawa serep mesin virtual.
Downtime sing bisa ditampa. Kanggo sistem sing beda-beda lan, miturut, mesin virtual, bisa beda-beda gumantung saka kritisitas bisnis. Biasane klien teka karo syarat siap kanggo downtime sak migrasi, lan adhedhasar iki kita milih alat cocok lan rencana migrasi. Kita nyoba kanggo gawe jadwal switchover pungkasan ing wayah wengi utawa ing akhir minggu supaya downtime cilik ora katon kanggo pangguna pungkasan klien.
Adhedhasar data iki, sampeyan bisa milih alat lan miwiti migrasi dhewe. Mangkene kedadeyan sabanjure.
- Nyetel konektivitas jaringan. Kita ngatur konektivitas jaringan ing antarane awan lan infrastruktur klien. Mesin virtual bakal disalin liwat jaringan iki. Yen Serep lan Replikasi Veeam digunakake, mula iki minangka saluran khusus, kurang asring saluran VPN. Yen Veeam Cloud Connect, banjur kabeh liwat Internet utawa saluran darmabakti padha.
Banjur jaringan dikonfigurasi kanggo VM ing mΓ©ga. Mobil biasane pindhah ing kelompok lan luwih saka sedina. Sawise VM digawa menyang kita lan diluncurake, dheweke kudu komunikasi karo mesin sing isih ana ing situs asli.
- Jadwal migrasi. Nalika ana akeh mobil, iku ndadekake pangertèn kanggo pamisah mau menyang kelompok lan transportasi ing kelompok. Bebarengan karo klien, kita setuju karo rencana sing nemtokake kapan lan mesin sing bakal dipindhah lan nalika replikasi pungkasan lan ngalih menyang situs anyar bakal ditindakake.
- Tes migrasi. Kita migrasi mesin virtual test lan mriksa apa kabeh wis diatur bener: panyambungan jaringan antarane situs, kasedhiyan mesin virtual kanggo mesin ing situs sumber, hak akun, etc. Tes iki mbantu supaya ora ana alangan ing tahap migrasi pertempuran.
Iku kabeh kanggo kula. Ing komentar, takon lan crita babagan pengalaman migrasi sampeyan.
Source: www.habr.com