Sekitar 7 tahun yang lalu, proyek pertama dipindahkan ke cloud kami dengan sederhana dan sederhana. Gambar mesin virtual diunggah ke server FTP, atau dikirim ke hard drive. Kemudian, melalui server impor khusus, VM diunggah ke cloud.
Jika tidak menjadi masalah bagi klien untuk mematikan mesin virtual selama satu atau dua hari (atau tidak ada pilihan lain), maka hal ini dapat dilakukan. Namun jika downtimenya maksimal satu jam, maka cara ini tidak akan berhasil. Hari ini saya akan memberi tahu Anda alat apa yang akan membantu Anda bermigrasi ke cloud dengan waktu henti minimal dan cara kerja proses migrasi kami.
Migrasi dengan Pencadangan dan Replikasi Veeam
Semua orang tahu Veeam Backup dan Replikasi sebagai alat untuk membuat cadangan dan replika. Kami menggunakannya untuk migrasi antar situs kami dan untuk memindahkan klien dari virtualisasi pribadi ke cloud kami. Mesin virtual klien direplikasi ke vCenter kami, setelah itu teknisi menambahkannya ke vCloud Director.
Replikasi primer terjadi pada mesin virtual yang dihidupkan. Pada waktu yang disepakati, mesin sisi klien dimatikan. Replikasi dijalankan kembali untuk meneruskan perubahan yang telah terjadi sejak replikasi pertama. Setelah ini, mesin virtual dimulai di cloud kami.
Biasanya, dari saat mesin dimatikan pada infrastruktur klien hingga mesin dihidupkan di cloud kami, tidak lebih dari setengah jam berlalu, melainkan 15-20 menit.
Dalam hal ini, mesin virtual asli tetap berada di situs klien. Jika tiba-tiba terjadi kesalahan, Anda selalu dapat memutar kembali dan menyalakannya. Metode ini juga nyaman bagi klien karena tidak mengharuskan dia untuk memiliki Veeam.
Kasus 1
Klien memiliki infrastruktur virtualnya sendiri berdasarkan VMware - 40 VM dengan kapasitas 30 TB. Peralatan yang digunakan untuk menyebarkan cluster sudah ketinggalan jaman, dan klien memutuskan untuk tidak repot membeli yang baru dan pindah ke cloud publik. Persyaratan waktu henti untuk sistem kritis tidak lebih dari satu jam. Replikasi Veeam dipilih sebagai alatnya. Kelebihan lainnya adalah penyedia Internet klien hadir di pusat data kami, yang memungkinkan pengorganisasian saluran yang baik. Migrasi memakan waktu sekitar satu bulan, waktu henti selama peralihan hingga 30 menit per grup mesin virtual.
Bermigrasi dengan Veeam Cloud Connect
Veeam Cloud Connect adalah alat yang membantu Anda mengatur replikasi mesin virtual dan meluncurkan replika di cloud penyedia layanan. Setelah memperbarui ke tahun ini, mesin virtual dapat direplikasi langsung ke vCloud Director. Satu-satunya syarat adalah di sisi klien, Pencadangan dan Replikasi Veeam harus diterapkan setidaknya versi 9. Singkatnya (versi detail ), maka seluruh prosesnya terlihat seperti ini.
Di vCloud Director, sebuah organisasi dibuat dengan sumber daya dan jaringan yang diperlukan. Di Veeam Cloud Connect, kami membuat akun, klien menghubungkannya dari Veeam B&R miliknya, memilih penyedia dan organisasi DataLine, dan mengonfigurasi tugas untuk replikasi. Selain fakta bahwa selama migrasi tersebut, waktu henti akan terjadi dalam waktu 15-20 menit, klien sama sekali tidak bergantung pada dukungan teknis penyedia dan mengelola seluruh proses secara mandiri: membuat tugas replikasi, replikasi itu sendiri, mematikan mesin dan memulainya di lokasi baru.
Kasus 2
Infrastruktur klien, tempat migrasi direncanakan, berlokasi di Belarus. Diperlukan untuk mengangkut 90 VM dengan total volume 27 TB, meskipun saluran Internetnya 100 Mbit/detik. Jika Anda membuat cadangan dan segera mengunggahnya ke cloud kami, maka untuk beberapa VM akan memakan waktu beberapa hari. Selama waktu ini, delta besar akan berkembang di VM, dan hal ini dapat berdampak negatif pada performa mesin atau, lebih buruk lagi, ruang di penyimpanan data akan habis. Kami melanjutkan sebagai berikut: pertama, klien membuat cadangan penuh lokal dan mentransfer salinannya ke cloud kami melalui Veeam Cloud Connect. Kemudian saya membuat dan mentransfer kenaikan tersebut ke cloud. Mesin virtual asli terus berjalan. Setelah mematikan VM, klien membuat peningkatan lagi dan juga mentransfernya ke cloud. Di pihak kami, kami menerapkan mesin virtual dari cadangan penuh, lalu menerapkan dua peningkatan ke dalamnya. Skema ini pada akhirnya memungkinkan meminimalkan waktu henti hingga 2 jam saat berpindah ke situs kami.
Migrasi dengan Ketersediaan VMware vCloud
Pada bulan Maret tahun ini, VMware merilis vCloud Availability 3.0, yang memungkinkan Anda memigrasikan mesin virtual antara cloud yang berbeda (vCloud Director - vCloud Director) dan dari virtualisasi klien pribadi ke cloud (vCenter - vCloud Director). Kemudahan utamanya adalah integrasi dengan antarmuka vCloud Director. Hal ini sangat menyederhanakan proses manajemen replikasi dan meminimalkan waktu henti selama peralihan.
Dengan menggunakan alat ini, kami memigrasikan salah satu klien dari cloud Moskow ke cloud kami di St. Petersburg. Diperlukan pengangkutan 18 mesin virtual dengan total kapasitas 14 TB. Sebuah organisasi dibuat untuk klien di cloud St. Petersburg dan jaringan yang diperlukan diatur. Selanjutnya, dari antarmuka vCloud Director, klien membuka pengaturan Ketersediaan vCloud, membuat pekerjaan replikasi dan beralih ke situs St. Petersburg pada waktu yang tepat baginya. Waktu henti selama peralihan adalah 12 menit.
Skema migrasi antara cloud DataLine di St. Petersburg dan Moskow.
Ketersediaan vCloud memiliki mekanisme untuk memigrasikan VM dari situs klien ke cloud kami. Untuk melakukan hal ini, aplikasi Ketersediaan vCloud khusus diterapkan di vCenter klien. Setelah penyiapan sederhana, Anda terhubung ke cloud dan mengonfigurasi tugas migrasi. Klien juga mengelola seluruh proses secara mandiri dan waktu migrasi dijaga seminimal mungkin.
Skema untuk memigrasi mesin virtual dari instalasi pribadi ke cloud.
Ketersediaan VMware vCloud memiliki banyak kasus penggunaan lainnya; kami akan segera membicarakannya di artikel terpisah.
Mempersiapkan migrasi
Untuk memilih alat dan benar-benar mulai bermigrasi, Anda perlu memutuskan hal-hal berikut:
Dari mana kita bermigrasi? Jika Anda bermigrasi dari solusi pribadi, Anda memiliki kebebasan penuh dalam memilih alat. Jika Anda menjauh dari penyedia Anda, maka segalanya menjadi lebih rumit. Kemungkinan besar, menghubungkan infrastruktur dua penyedia dan sekadar menyeret dan melepas VM tidak akan berfungsi karena alasan keamanan. Terkadang penyedia yang akan ditolak klien mulai nakal dan mengulur waktu. Anda dapat beralih dari penyedia dengan cara lama: dengan mengunggah VM ke disk dan FTP, atau dengan bermigrasi di tingkat aplikasi. Nama yang terakhir ini bersyarat, dan tampilannya seperti ini.
Kasus 3
Sistem SAP klien perlu dimigrasi dari penyedia Eropa: 34 VM dengan kapasitas 54 TB. Klien dialokasikan sumber daya di cloud kami. Konektivitas jaringan diatur antara kami dan infrastruktur penyedia Eropa. Server aplikasi dikerahkan kembali, dengan konfigurasi yang diperlukan dialihkan. Basis data besar dimigrasikan melalui pengunggahan cadangan ke cloud kami. Selanjutnya, replikasi dikonfigurasi antara database di situs kami dan situs asli. Pada waktu yang disepakati, kami beralih ke database di cloud kami.
Volume data dan saluran Internet. Kami biasanya meminta klien untuk menyediakan unggahan berdasarkan sistem dengan parameter memori, CPU, dan disk. Kami mengevaluasi apakah saluran tersebut cukup untuk mengirim replika atau cadangan mesin virtual secara langsung.
Waktu henti yang dapat diterima. Untuk sistem yang berbeda dan, karenanya, mesin virtual, ini bisa berbeda tergantung pada kekritisan bisnisnya. Biasanya klien dilengkapi dengan persyaratan siap pakai untuk waktu henti selama migrasi, dan berdasarkan ini kami memilih alat dan rencana migrasi yang sesuai. Kami mencoba menjadwalkan peralihan terakhir pada malam hari atau akhir pekan sehingga downtime kecil sekalipun tidak terlihat oleh pengguna akhir klien.
Berdasarkan data ini, Anda dapat memilih alat dan memulai migrasi itu sendiri. Inilah yang terjadi selanjutnya.
- Menyiapkan konektivitas jaringan. Kami mengatur konektivitas jaringan antara cloud kami dan infrastruktur klien. Mesin virtual akan disalin melalui jaringan ini. Jika Pencadangan dan Replikasi Veeam 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 dibawa ke kami dan diluncurkan, mereka harus berkomunikasi dengan mesin yang masih berada di situs aslinya.
- Jadwal migrasi. Jika terdapat banyak mobil, masuk akal untuk membaginya menjadi beberapa kelompok dan mengangkutnya secara berkelompok. Bersama dengan klien, kami menyetujui rencana di mana kami menentukan kapan dan mesin mana yang akan dipindahkan dan kapan replikasi terakhir dan peralihan ke situs baru akan dilakukan.
- Uji migrasi. Kami memigrasikan mesin virtual pengujian dan memeriksa apakah semuanya telah dikonfigurasi dengan benar: konektivitas jaringan antar situs, ketersediaan mesin virtual ke mesin di situs sumber, hak akun, dll. Tes ini membantu menghindari hambatan pada tahap migrasi tempur.
Itu saja untukku. Di komentar, ajukan pertanyaan dan beri tahu kami tentang pengalaman migrasi Anda.
Sumber: www.habr.com