Sekitar 7 tahun yang lalu, proyek-proyek pertama pindah ke cloud kami dengan sederhana dan sederhana. Gambar mesin virtual diunggah ke server FTP, atau dibawa ke hard drive. Kemudian, melalui server impor khusus, VM diunggah ke cloud.
Jika bukan masalah bagi klien untuk mematikan mesin virtual selama satu atau dua hari (atau bukan opsi lain), maka itu mungkin. Tetapi jika downtime harus maksimum satu jam, maka metode ini tidak akan berfungsi. Hari ini saya akan memberi tahu Anda alat apa yang akan membantu Anda bermigrasi ke cloud dengan downtime minimal dan bagaimana proses migrasi bekerja dengan kami.
Bermigrasi dengan Cadangan dan Replikasi Veeam
Semua orang tahu Cadangan dan Replikasi Veeam sebagai alat untuk membuat cadangan dan replika. Kami menggunakannya untuk migrasi antara situs kami dan untuk mengangkut klien dengan virtualisasi pribadi ke cloud kami. Mesin virtual klien direplikasi ke vCenter kami, setelah itu insinyur menambahkannya ke Direktur vCloud.
Replikasi primer dilakukan pada mesin virtual yang diaktifkan. Pada waktu yang disepakati, mesin di sisi klien mati. Replikasi dimulai lagi untuk mentransfer perubahan yang telah terjadi sejak replikasi pertama. Setelah itu, mesin virtual sudah dimulai di cloud kami.
Biasanya sejak saat mesin dimatikan pada infrastruktur klien dan hingga saat dihidupkan, tidak lebih dari setengah jam, tetapi lebih dari 15-20 menit, lewat di cloud kami.
Pada saat yang sama, mesin virtual asli tetap berada di situs klien. Jika tiba-tiba terjadi kesalahan, Anda selalu dapat memutar dan menyalakannya. Untuk klien, metode ini juga nyaman karena tidak memerlukan Veeam darinya.
Kasus 1
Klien memiliki infrastruktur virtual sendiri berdasarkan VMware - 40 VM dengan kapasitas 30 Tb. Peralatan yang digunakan cluster sudah usang, dan klien memutuskan untuk tidak terlibat dalam pembelian yang baru dan pindah ke cloud publik. Persyaratan untuk downtime sistem kritis tidak lebih dari satu jam. Replikasi Veeam dipilih sebagai alat. Nilai tambahnya juga karena penyedia Internet klien hadir di pusat data kami, yang memungkinkan kami untuk mengatur saluran yang baik. Migrasi memakan waktu sekitar satu bulan, sementara beralih itu sederhana, butuh hingga 30 menit untuk satu kelompok mesin virtual.Bermigrasi dengan Veeam Cloud Connect
Veeam Cloud Connect adalah alat yang membantu Anda mengonfigurasi replikasi mesin virtual dan menjalankan replika di cloud penyedia layanan. Setelah pembaruan pada tahun
2019 , dimungkinkan untuk mereplikasi mesin virtual langsung ke vCloud Director. Satu-satunya syarat adalah bahwa di sisi klien, Cadangan dan Replikasi Veeam Anda harus digunakan setidaknya versi 9. Singkatnya (versi terperinci ada di
sini ), seluruh proses adalah sebagai berikut.
VCloud Director menciptakan organisasi dengan sumber daya dan jaringan yang diperlukan. Di Veeam Cloud Connect, kami membuat akun, klien terhubung dengannya dari Veeam B&R kami, memilih penyedia dan organisasi DataLine, dan mengatur tugas untuk replikasi. Selain fakta bahwa selama migrasi seperti itu, waktu henti akan dalam 15-20 menit, klien tidak bergantung pada dukungan teknis dari penyedia dan mengelola seluruh proses secara mandiri: itu menciptakan tugas replikasi, replikasi itu sendiri, mematikan mesin dan memulai permulaannya di situs baru.
Kasus 2
Infrastruktur klien dari mana migrasi direncanakan terletak di Belarus. Itu perlu untuk mengangkut 90 VMs dengan volume total 27 TB, meskipun faktanya saluran Internet adalah 100 Mbps. Jika Anda membuat cadangan dan segera mengunggahnya ke cloud kami, maka untuk beberapa VM diperlukan beberapa hari. Selama waktu ini, sebuah delta besar akan tumbuh di VM, dan ini sudah dapat mempengaruhi kinerja mesin atau, lebih buruk lagi, tempat di datastore habis. Mereka bertindak sebagai berikut: pertama, klien membuat cadangan penuh lokal dan mentransfer salinannya kepada kami di cloud melalui Veeam Cloud Connect. Lalu dia membuat dan melemparkan kenaikan itu ke awan. Mesin virtual asli terus bekerja. Setelah mematikan VM, klien membuat kenaikan lain dan juga mentransfernya ke cloud. Di pihak kami, kami menggunakan mesin virtual dari cadangan penuh, dan kemudian kami menggulirkan dua peningkatan ke dalamnya. Skema semacam itu memungkinkan kami untuk meminimalkan waktu henti hingga 2 jam saat beralih ke situs kami.Migrasi dengan Ketersediaan VMware vCloud
Pada bulan Maret tahun ini, VMware merilis vCloud Availability 3.0, yang memungkinkan mesin virtual untuk bermigrasi di antara cloud yang berbeda (vCloud Director - vCloud Director) dan dari virtualisasi klien pribadi stand to the cloud (vCenter - vCloud Director). Kenyamanan utama adalah integrasi dengan antarmuka vCloud Director. Ini sangat menyederhanakan manajemen replikasi dan meminimalkan waktu henti saat beralih.
Dengan menggunakan alat ini, kami memigrasikan salah satu klien dari cloud Moskow kami ke cloud kami di St. Petersburg. Itu diperlukan untuk mengangkut 18 mesin virtual dengan total kapasitas 14 TB. Untuk klien, sebuah organisasi diciptakan di cloud St. Petersburg dan jaringan yang diperlukan diorganisasikan. Kemudian, dari antarmuka vCloud Director, klien beralih ke pengaturan Ketersediaan vCloud, membuat tugas replikasi, dan beralih ke situs St. Petersburg pada waktu yang tepat. Downtime saat beralih adalah 12 menit.
Skema migrasi antara awan DataLine di St. Petersburg dan Moskow.Ketersediaan VCloud memiliki mekanisme untuk memigrasi VM dari situs klien ke cloud kami. Untuk melakukan ini, aplikasi Ketersediaan vCloud khusus digunakan di klien vCenter. Setelah penyiapan sederhana, Anda terhubung ke cloud dan tugas migrasi dikonfigurasikan. Klien juga secara mandiri mengelola seluruh proses, dan waktu migrasi diminimalkan.
Diagram migrasi mesin virtual dari instalasi pribadi ke cloud.Ketersediaan VMware vCloud memiliki banyak kasus penggunaan lainnya, kami akan segera membicarakannya dalam artikel terpisah.
Mempersiapkan Migrasi
Untuk memilih alat dan benar-benar melanjutkan migrasi, Anda perlu memutuskan beberapa hal berikut:
Dari mana kita bermigrasi. Jika Anda bermigrasi dari solusi pribadi, maka Anda memiliki kebebasan penuh dalam memilih alat. Jika Anda keluar dari penyedia, maka itu lebih sulit. Kemungkinan besar, menghubungkan infrastruktur kedua penyedia dan hanya menyeret VM akan gagal karena alasan keamanan. Terkadang provider, yang akan ditolak oleh klien, sepenuhnya mulai berbahaya dan membutuhkan waktu. Anda dapat meninggalkan penyedia dengan cara lama: dengan mengunggah VM ke disk dan FTP atau bermigrasi di tingkat aplikasi. Nama yang terakhir adalah arbitrer, dan terlihat seperti ini.
Kasus 3
Itu perlu untuk memigrasi sistem SAP klien dari penyedia Eropa: 34 VM dengan volume 54 Tb. Sumber daya dialokasikan untuk klien di cloud kami. Antara kami dan infrastruktur penyedia Eropa diselenggarakan konektivitas jaringan. Server aplikasi dipekerjakan kembali, dengan roll-up dari konfigurasi yang diperlukan. Database besar dimigrasikan melalui mengunggah cadangan ke cloud kami. Selanjutnya, replikasi antara database di situs kami dan situs sumber telah dikonfigurasi. Pada waktu yang disepakati, kami beralih ke database di cloud kami.Jumlah data dan saluran internet. Kami biasanya meminta klien untuk menyediakan pembongkaran pada sistem dengan parameter memori, CPU, disk. Kami memperkirakan apakah saluran tersebut cukup untuk mengirim langsung replika atau cadangan mesin virtual.
Sederhana dan valid. Untuk sistem yang berbeda dan, dengan demikian, mesin virtual, dapat berbeda tergantung pada kritikalitasnya untuk bisnis. Biasanya, klien datang dengan persyaratan siap pakai untuk waktu henti selama migrasi, dan berdasarkan ini kami memilih alat yang tepat dan rencana migrasi. Kami mencoba merencanakan peralihan terakhir ke malam atau akhir pekan, sehingga bahkan sedikit downtime tidak terlihat oleh pengguna akhir klien.
Berdasarkan data ini, Anda dapat memilih alat dan melanjutkan dengan migrasi itu sendiri. Inilah yang terjadi selanjutnya.
- Mengkonfigurasi konektivitas jaringan. Kami mengatur konektivitas jaringan antara cloud dan infrastruktur pelanggan kami. Mesin virtual akan disalin melalui jaringan ini. Jika Veeam Backup and Replication digunakan, maka ini adalah saluran khusus, lebih jarang saluran VPN. Jika Veeam Cloud Connect, maka semuanya berjalan melalui Internet atau saluran khusus yang sama.
Kemudian jaringan dikonfigurasi untuk VM di cloud. Mobil biasanya bergerak berkelompok dan lebih dari satu hari. Setelah VM ditransfer ke kami dan diluncurkan, mereka harus berinteraksi dengan mesin yang masih tersisa di situs awal. - Jadwal migrasi. Ketika ada banyak mobil, masuk akal untuk memecahnya menjadi kelompok-kelompok dan mengangkutnya dalam batch. Bersama dengan klien, kami sepakat pada rencana di mana kami meresepkan kapan dan mesin mana yang bergerak dan kapan replikasi akhir dan beralih ke situs baru akan dilakukan.
- Tes migrasi. Kami memigrasikan mesin virtual pengujian dan memeriksa apakah semuanya dikonfigurasi dengan benar: konektivitas jaringan antara situs, ketersediaan mesin virtual untuk mesin di situs sumber, hak akun, dan banyak lagi. Tes semacam itu membantu untuk menghindari halangan selama tahap migrasi tempur.
Itu semua untuk saya. Ajukan pertanyaan di komentar dan bicarakan tentang pengalaman migrasi Anda.