Cara memigrasikan mesin virtual langkah demi langkah

Migrasi mesin virtual telah menjadi tugas sehari-hari di departemen TI modern mana pun. Ini bukan lagi hanya tentang memindahkan mesin dari satu server ke server lain: saat ini kita berbicara tentang memindahkan dari klaster VMware on-premises ke Azure atau Google Cloud, mengubah platform virtualisasi (misalnya, dari VMware ke KVM/VMmanager ), atau bahkan mengatur ulang sumber daya di dalam pusat data yang sama untuk meningkatkan kinerja atau ketahanan, sambil berupaya meminimalkan waktu henti.

Pada artikel ini, kita akan membahas secara detail cara melakukan migrasi mesin virtual secara terorganisir . Kita akan meninjau kasus penggunaan, jenis migrasi (dingin dan panas), proses spesifik platform seperti Azure Migrate dan Google Cloud Migrate to Virtual Machines, dan cara menangani perubahan hypervisor pada solusi seperti VMmanager. Tujuannya adalah untuk memberikan panduan yang jelas dan praktis guna meminimalkan risiko dan memahami apa yang terjadi "di balik layar".

Mengapa perlu memigrasikan mesin virtual di lingkungan bisnis?

Dalam lingkungan perusahaan, beban kerja terus berubah : lonjakan lalu lintas yang tak terduga, aplikasi baru, kampanye pemasaran yang memicu peningkatan permintaan, pemeliharaan perangkat keras, dan sebagainya. Menerapkan server fisik tambahan setiap kali terjadi masalah tidak selalu memungkinkan, sehingga migrasi mesin virtual menjadi alat kunci untuk mendistribusikan ulang sumber daya secara dinamis.

Salah satu alasan paling umum untuk memindahkan VM adalah untuk melakukan pemeliharaan terjadwal pada host fisik (pembaruan firmware, perubahan perangkat keras, relokasi rak, dll.). Alih-alih mengalami waktu henti bagi pengguna, mesin virtual dipindahkan ke server lain selama jendela pemeliharaan dan kemudian dikembalikan ke host aslinya jika perlu.

Migrasi mesin virtual juga penting untuk memastikan ketersediaan tinggi jika terjadi kegagalan yang tidak terduga . Jika server fisik mengalami kerusakan atau menunjukkan tanda-tanda kegagalan yang akan segera terjadi, kemampuan untuk memindahkan VM dengan cepat ke host atau cloud lain memungkinkan pengguna untuk hampir tidak menyadari insiden tersebut, sehingga aplikasi tetap berjalan.

Kasus penting lainnya adalah pemulihan bencana . Banyak arsitektur mereplikasi mesin virtual dan statusnya (disk dan, dalam beberapa kasus, memori) antara situs utama dan situs pemulihan bencana. Ketika bencana dinyatakan, VM dimigrasikan ke infrastruktur pemulihan, mengurangi total waktu henti dan kehilangan data.

Selain itu, migrasi VM seringkali jauh lebih praktis daripada memindahkan sistem operasi dan aplikasi secara individual. Dengan memigrasikan seluruh mesin virtual , dimungkinkan untuk memindahkan sistem operasi lama dan aplikasi penting dari server lama ke perangkat keras yang lebih baru atau cloud tanpa membangun semuanya dari awal, dan seringkali dengan dampak minimal pada pengguna.

Jenis-jenis migrasi mesin virtual: migrasi dingin dan migrasi panas.

Ketika kita berbicara tentang memindahkan mesin virtual antar host, array penyimpanan, atau bahkan pusat data, kita hampir selalu membedakan antara dua pendekatan: migrasi dingin dan migrasi panas . Perbedaan utamanya adalah keadaan VM selama proses tersebut.

Migrasi dingin

Migrasi dingin melibatkan pemindahan mesin virtual yang dimatikan atau ditangguhkan ke host atau penyimpanan data baru. Proses ini juga dapat melibatkan pemindahan file terkait (konfigurasi, disk, snapshot), memindahkan mesin virtual dari satu switch virtual ke switch virtual lainnya, atau bahkan dari satu pusat data ke pusat data lainnya.

Jenis migrasi ini dapat dilakukan secara manual atau dijadwalkan untuk dijalankan dalam jangka waktu tertentu, tetapi memiliki kelemahan yang jelas: terjadi gangguan layanan yang signifikan karena VM harus dimatikan. Selain itu, seringkali diperlukan tingkat pengetahuan lanjutan tentang hypervisor, jaringan, dan penyimpanan untuk menghindari komplikasi dengan dependensi, jalur, atau izin.

migrasi panas

Dalam migrasi langsung, mesin virtual dipindahkan saat masih menyala , artinya mesin virtual tersebut terus memberikan layanan saat berpindah dari satu host ke host lain. Alat seperti vMotion di VMware atau fitur migrasi langsung dari hypervisor lain memungkinkan ketersediaan yang hampir terus menerus selama proses ini.

Sistem ini menangani penyalinan memori, status CPU, dan informasi lain yang diperlukan agar VM dapat "bangun" di server baru hampir tanpa hambatan, tanpa disadari pengguna. Misalnya, dimungkinkan untuk memindahkan VM yang sedang berjalan antar host yang berbagi penyimpanan yang sama, praktik umum di lingkungan seperti Citrix Hypervisor atau klaster KVM dengan susunan penyimpanan bersama.

Keuntungan utama dari migrasi langsung adalah membebaskan administrator dari banyak tugas manual dan menjaga aplikasi agar selalu tersedia. Namun, hal ini membutuhkan infrastruktur yang dirancang dengan baik (latensi rendah, penyimpanan bersama, dan jaringan yang sesuai) untuk memastikan pengoperasian yang aman dan menghindari penurunan kinerja.

Migrasikan VMware atau AVS on-premises ke Azure dengan Azure Migrate.

Dalam skenario cloud hybrid, salah satu skenario yang paling sering terjadi adalah memindahkan VM dari lingkungan VMware on-premises atau Azure VMware Solution (AVS) ke mesin virtual Azure asli. Untuk tujuan ini, Microsoft menawarkan alat Azure Migrate: Migration and Modernization , yang memungkinkan migrasi berbasis agen dan, semakin sering, migrasi tanpa agen yang sangat otomatis.

Proses Azure Migrate mencakup semuanya, mulai dari persiapan lingkungan hingga replikasi, pengujian migrasi, dan peralihan akhir. Seluruh alur kerja dijelaskan secara rinci di bawah ini, yang menguraikan langkah-langkah dan keputusan yang harus dibuat di setiap tahap.

Prasyarat untuk memigrasikan VM VMware ke Azure

Sebelum memulai prosesnya, Anda perlu memenuhi serangkaian prasyarat dasar di Azure dan lingkungan VMware Anda. Jika Anda tidak mempersiapkannya, kemungkinan besar Anda akan mengalami kesalahan izin atau masalah jaringan di tengah proyek.

Langkah pertama adalah memiliki langganan Azure yang aktif . Jika Anda belum memilikinya, Anda dapat membuat akun gratis dan kemudian mengaktifkan layanan yang dibutuhkan untuk migrasi. Tanpa langganan, Anda jelas tidak akan dapat melakukan deployment apa pun.

Pada tingkat proyek, Microsoft merekomendasikan untuk menyelesaikan setidaknya satu tutorial awal untuk mempersiapkan Azure dan VMware untuk migrasi (konfigurasi jaringan dasar, izin, dll.). Selain itu, menjalankan tutorial penilaian Azure Migrate untuk menganalisis VM VMware sebelum memigrasikannya sangat disarankan, meskipun langkah ini tidak sepenuhnya wajib.

Di Azure Migrate, Anda perlu menggunakan proyek yang sudah ada atau membuat proyek baru tempat penilaian dan migrasi akan dipusatkan. Selain itu, pastikan akun Azure yang Anda gunakan memiliki izin yang cukup untuk membuat mesin virtual dan menulis ke disk terkelola.

Untuk menyempurnakan izin, disarankan untuk meninjau dokumentasi khusus untuk peran bawaan Azure dan izin yang dibutuhkan oleh Azure Migrate (pembuatan proyek, penemuan, penilaian, dan migrasi). Hal ini akan mencegah kejutan saat memulai tugas otomatis yang kemudian gagal membuat sumber daya.

Konfigurasi perangkat Azure Migrate

Solusi migrasi Azure menggunakan appliance ringan yang di deploy di VMware , yang menangani penemuan VM, penilaian, dan replikasi tanpa agen. Jika Anda telah menyelesaikan fase penilaian, appliance ini biasanya akan dikonfigurasi dan didaftarkan ke proyek.

Jika Anda belum memilikinya, Anda dapat menerapkannya dengan dua cara utama, tergantung pada batasan lingkungan Anda dan apakah Anda bekerja dengan cloud publik standar atau lingkungan seperti Azure Government:

• Templat OVAAnda mengunduh templat dan menyebarkannya sebagai VM lain di dalam vSphere. Ini adalah metode paling langsung jika Anda tidak memiliki batasan khusus.
• Skrip PowerShellAnda menginstal perangkat pada mesin virtual VMware atau server fisik menggunakan skrip. Pendekatan ini biasanya digunakan ketika bekerja dengan OVA tidak memungkinkan atau tidak praktis, atau di lingkungan yang diatur secara khusus.

Setelah mesin diinstal, verifikasi bahwa mesin tersebut dapat berkomunikasi dengan lancar dengan Azure Migrate: Server Assessment and Server Migration , selesaikan konfigurasi awal, dan daftarkan di proyek Azure Migrate yang sesuai. Tanpa pendaftaran ini, portal tidak akan dapat mengaitkan informasi penemuan dan replikasi dengan lingkungan Anda.

Aktifkan dan konfigurasikan replikasi VM.

Setelah perangkat aktif dan berjalan serta proses penemuan selesai, langkah selanjutnya adalah mengaktifkan replikasi mesin virtual VMware ke Azure . Azure Migrate mendukung hingga 500 replikasi simultan, meskipun portal hanya memungkinkan Anda memilih 10 VM per operasi, jadi disarankan untuk mengelompokkannya ke dalam beberapa batch.

Untuk memulai replikasi, di proyek Azure Migrate Anda, buka bagian eksekusi dan pilih opsi Mulai migrasi . Di wizard, pilih "Server" atau "Mesin Virtual" sebagai tipe payload dan "Azure VM" sebagai tujuan migrasi.

Selanjutnya, Anda perlu memutuskan cara memilih beban kerja : secara manual dari seluruh inventaris yang ditemukan atau mulai dari penilaian sebelumnya, yang dapat menyederhanakan pemilihan jika Anda sudah mengidentifikasi grup dan ketergantungan.

Pada metode penemuan, pilih perangkat yang sesuai dengan lingkungan sumber (dalam hal ini, appliance VMware vSphere) dan pada "Mode migrasi" pilih opsi migrasi tanpa agen. Kemudian, pilih VM yang ingin Anda replikasi dan jenis keamanan mesin virtual target; Azure mendukung migrasi ke VM dengan Secure Launch dan Virtual TPM (Trusted Launch), yang sangat direkomendasikan jika beban kerja kompatibel.

Pada bagian konfigurasi tujuan, Anda perlu menentukan langganan, wilayah target, dan akun penyimpanan . Langkah ini juga menentukan jaringan virtual dan subnet Azure tempat VM akan ditempatkan setelah migrasi selesai.

Aspek penting lainnya adalah opsi ketersediaan . Anda dapat menetapkan mesin ke zona ketersediaan tertentu untuk mendistribusikan node dari lapisan aplikasi yang sama di berbagai zona, menggunakan set ketersediaan (jika ada di grup sumber daya target), atau tidak menerapkan opsi tambahan apa pun jika tidak diperlukan. Anda juga perlu memilih jenis enkripsi disk: kunci yang dikelola platform, kunci yang dikelola klien, atau enkripsi ganda.

Terkait lisensi, Azure memungkinkan Anda menentukan apakah Anda ingin menggunakan Azure Hybrid Benefit untuk mesin Windows Server dengan Software Assurance atau lisensi aktif. Jika Anda memilih "ya," Anda dapat mengurangi biaya dengan memanfaatkan lisensi yang sudah ada.

Pada tab Komputasi, tinjau dengan cermat nama VM, ukuran, tipe disk sistem operasi, dan pengaturan ketersediaan . Jika Anda berasal dari penilaian sebelumnya, wizard akan menyarankan ukuran yang direkomendasikan; jika tidak, Azure akan memilih ukuran terdekat yang tersedia dalam langganan Anda. Anda selalu dapat menyesuaikan ini secara manual agar sesuai dengan kebutuhan CPU dan RAM Anda.

Anda juga perlu menentukan disk sistem operasi (disk boot) di dalam VM sumber, zona ketersediaan atau set ketersediaan tujuan, dan, jika Anda sudah memiliki reservasi kapasitas, kaitkan SKU mesin virtual dengan reservasi untuk memastikan bahwa sumber daya akan tersedia saat Anda melakukan cutover.

Pada tab Disk, Anda memilih disk mana dari mesin Anda yang ingin direplikasi dan jenis disk apa yang akan Anda gunakan di Azure (Premium v2, Ultra Disk, Standard SSD, Standard HDD, atau disk terkelola Premium). Manfaatkan kesempatan ini untuk memutuskan di mana ada baiknya membayar lebih untuk performa dan di mana penyimpanan yang lebih sederhana sudah cukup.

Untuk menyelesaikan pengaturan awal, Anda dapat memberikan tag pada VM, disk, dan NIC, yang sangat berguna nantinya untuk inventaris, biaya, dan otomatisasi. Setelah meninjau semuanya, konfirmasikan konfigurasi dan mulai replikasi awal.

Memantau dan melacak migrasi di Azure Migrate

Setelah proses berjalan, penting untuk memantau kemajuan replikasi dan berbagai fase migrasi . Dari portal, di bagian eksekusi proyek, Anda dapat melihat migrasi yang dikelompokkan berdasarkan aplikasi atau beban kerja, mana pun yang lebih nyaman bagi Anda.

Operasi ini secara konseptual dibagi menjadi tiga fase: Persiapan, Pengujian, dan Penyelesaian . Setiap server juga menampilkan status: sedang berlangsung, mengalami kesalahan, menunggu tindakan, atau selesai. Selama fase persiapan, replikasi awal sedang berjalan; pada fase pengujian, replikasi diferensial sudah diterapkan dan migrasi uji dapat diluncurkan; pada fase penyelesaian, peralihan dan pembersihan dilakukan.

Saat replikasi awal sedang berlangsung, VM tetap berada dalam fase persiapan, dan Anda dapat menghentikan, menjeda, atau melanjutkan proses sesuai kebutuhan. Setelah sinkronisasi pertama ini selesai, VM beralih ke fase pengujian, dan di sinilah Anda harus merencanakan pengujian migrasi Anda pada jaringan pengujian yang tidak mengganggu produksi.

Jika Anda memilih untuk melewatkan pengujian, Anda dapat langsung melanjutkan ke fase finalisasi, meskipun ini tidak disarankan untuk beban kerja kritis. Setelah replikasi diferensial stabil dan pengujian berhasil, Anda dapat menjadwalkan migrasi akhir (cutover) dan, setelah semuanya diverifikasi, melakukan pembersihan sumber daya migrasi.

Untuk kontrol yang lebih baik, Azure Migrate menyediakan cmdlet PowerShell bernama Get-AzMigrateServerMigrationStatus . Dengan cmdlet ini, Anda dapat melihat sisa waktu replikasi di setiap tahap, kemajuan per disk, kecepatan unggah, dan bahkan rekomendasi untuk mempercepat migrasi.

Dari Azure Cloud Shell, cukup buka konsol, pilih PowerShell, dan jalankan perintah seperti berikut:

Get-AzMigrateServerMigrationStatus -ProjectName « » -NamaGrupSumberDaya « » -Nama Mesin « »

Menambahkan parameter `-Expedite` menyebabkan perintah mengembalikan parameter pengoperasian appliance dan daftar tindakan yang disarankan dengan prioritas untuk mengurangi waktu migrasi yang tersisa. Anda juga dapat menjalankan perintah tanpa `MachineName` untuk melihat status semua VM dalam proyek, atau menggunakan parameter seperti `-Health` untuk mendapatkan informasi detail tentang kesalahan, penyebabnya, dan langkah-langkah pemecahan masalah.

Anda juga dapat memfilter berdasarkan ApplianceName untuk meninjau status global semua server yang terkait dengan appliance Azure Migrate tertentu, yang sangat berguna dalam penerapan skala besar dengan banyak appliance terdistribusi.

Jalankan migrasi uji coba di Azure.

Saat replikasi diferensial diaktifkan, sangat disarankan untuk menjalankan setidaknya satu migrasi uji per VM sebelum melakukan peralihan akhir. Tujuannya adalah untuk memvalidasi bahwa mesin melakukan booting dengan benar di Azure, bahwa aplikasi berfungsi, dan bahwa tidak ada masalah tak terduga dengan dependensi, firewall, atau DNS.

Migrasi pengujian melibatkan pembuatan VM Azure dari data yang direplikasi dan biasanya menempatkannya di jaringan virtual pengujian, yang terisolasi dari lalu lintas produksi. Mesin sumber, baik di lokasi lokal maupun di AVS, terus berjalan dan mereplikasi data selama proses berlangsung, sehingga layanan tidak terganggu.

Untuk menjalankan pengujian, di proyek Azure Migrate, buka bagian migrasi, pilih server yang diinginkan, dan dari menu tarik-turun pengujian, pilih opsi Mulai migrasi pengujian . Kemudian pilih Azure VNet tempat VM pengujian akan dibuat dan tetapkan subnet yang sesuai untuk setiap NIC yang direplikasi.

Keuntungan lainnya adalah Anda dapat memanfaatkan fase pengujian ini untuk memperbarui Windows Server . Jika opsi pembaruan tersedia, pilih versi sistem operasi target dan terapkan perubahannya, sehingga memvalidasi bagaimana aplikasi berperilaku dengan versi baru langsung dalam pengujian.

Setelah memulai migrasi pengujian, portal akan menampilkan kemajuan dalam status eksekusi. Setelah Anda selesai memverifikasi bahwa semuanya berfungsi, jangan lupa untuk membersihkan sumber daya yang telah dibuat dan pilih opsi "Bersihkan Migrasi Pengujian" di menu pengujian yang sama, untuk menghindari VM pengujian yang terus mengonsumsi sumber daya dan menimbulkan biaya yang tidak perlu.

Migrasi akhir (pengalihan) mesin virtual

Setelah memverifikasi bahwa pengujian berhasil, saatnya untuk memigrasikan VM secara permanen dari lingkungan sumber ke Azure. Pada titik inilah jendela pemeliharaan biasanya dijadwalkan, karena biasanya melibatkan pematian mesin sumber.

Di bagian migrasi proyek, pilih server target dan, di menu penyelesaian, pilih opsi Migrasi . Wizard akan menanyakan apakah Anda ingin mematikan VM sumber untuk melakukan migrasi terencana tanpa kehilangan data; jika Anda memilih "Ya," Azure Migrate akan mematikan mesin, melakukan replikasi sesuai permintaan dengan perubahan terbaru, dan memastikan bahwa tidak ada data yang hilang.

Jika karena alasan tertentu Anda tidak ingin mematikan VM sumber, Anda dapat memilih "Tidak," meskipun ini biasanya melibatkan risiko yang lebih besar atau memerlukan kehati-hatian ekstra dengan sinkronisasi data. Anda juga dapat menggunakan kembali fase ini untuk meningkatkan versi Windows Server selama migrasi , dengan memilih versi target yang sesuai.

Jika Anda memiliki reservasi kapasitas untuk SKU VM yang akan Anda gunakan di wilayah tujuan, sebaiknya tautkan reservasi tersebut di sini untuk memastikan ketersediaan sumber daya yang terjamin pada saat peralihan. Setelah Anda mengkonfirmasi semuanya, pekerjaan migrasi akan dimulai, dan Anda dapat melacak kemajuannya di notifikasi Azure dan di tampilan migrasi itu sendiri.

Setelah pekerjaan selesai, mesin virtual tersebut akan tersedia sebagai Azure VM yang sepenuhnya dapat dikelola dari portal, dan statusnya di Azure Migrate akan beralih ke fase penyelesaian sehingga Anda dapat menyelesaikan langkah-langkah penutupan.

Selesaikan dan finalisasi migrasi di Azure.

Setelah VM berjalan di Azure, masih ada beberapa langkah lagi untuk menyelesaikan migrasi dan membuat lingkungan bersih serta terdokumentasi dengan baik. Langkah pertama adalah memberi tahu Azure Migrate bahwa migrasi telah selesai untuk mesin tersebut, menggunakan opsi Selesaikan migrasi di menu penyelesaian.

Setelah migrasi selesai, replikasi dari sumber dihentikan, dan status pelacakan mesin di Azure Migrate dihapus. Selama proses ini, Azure secara otomatis menginstal agen VM untuk Windows dan Linux pada mesin baru, menyederhanakan pengelolaan selanjutnya (pemantauan, ekstensi, dll.).

Selanjutnya, Anda harus memverifikasi bahwa aktivasi Windows pada Azure VM berhasil dan mengatasi peringatan apa pun. Ini juga merupakan waktu yang tepat untuk menyesuaikan pengaturan aplikasi: nama host, string koneksi basis data, jalur internal, konfigurasi server web, aturan firewall, dan parameter lain yang bergantung pada lingkungan.

Dari sudut pandang fungsional, penting untuk melakukan pengujian aplikasi akhir dan validasi bisnis . Setelah semua orang memberikan persetujuan mereka, Anda dapat secara permanen mengalihkan lalu lintas ke instance Azure yang baru (perubahan DNS, konfigurasi ulang load balancer, pembaruan endpoint di aplikasi klien, dll.).

Barulah setelah itu Anda dapat menghapus mesin virtual sumber dari inventaris lokal dan solusi pencadangan lokal Anda, dengan memastikan terlebih dahulu bahwa tidak ada layanan atau dependensi yang tersisa. Jangan lupa untuk memperbarui semua dokumentasi internal agar mencerminkan lokasi, IP, dan karakteristik baru dari VM yang sekarang berada di Azure.

Praktik terbaik setelah migrasi ke Azure

Selain sekadar menjalankan VM, disarankan untuk menerapkan serangkaian prosedur pasca-migrasi yang direkomendasikan untuk memperkuat ketahanan, kinerja, dan keamanan beban kerja yang baru saja Anda pindahkan ke cloud.

Pertama, pertimbangkan bagaimana Anda akan menangani perlindungan data . Azure Backup memungkinkan Anda untuk mencadangkan VM secara terpusat dan mengelola retensi secara fleksibel. Untuk melindungi dari bencana regional, Anda dapat mereplikasi VM ke wilayah lain menggunakan Azure Site Recovery, menambahkan lapisan ekstra untuk kelangsungan bisnis.

Dari segi performa, tinjau pengaturan cache pada disk data Anda . Secara default, banyak disk dibuat dengan cache yang diatur ke "None," tetapi tergantung pada beban kerja (basis data, aplikasi transaksional, server file, dll.), ada baiknya mengubah pengaturan ini untuk performa optimal.

Keamanan dan pemantauan berkelanjutan sama pentingnya. Disarankan untuk mengintegrasikan VM dengan alat pemantauan dan manajemen biaya seperti Microsoft Cost Management untuk melacak konsumsi, serta menggunakan solusi pencatatan terpusat, peringatan, dan analitik keamanan yang memungkinkan Anda bereaksi cepat terhadap anomali.

Terakhir, ada baiknya meninjau Kerangka Kerja Adopsi Cloud Azure , yang menguraikan perjalanan adopsi cloud lengkap di Microsoft, mulai dari strategi hingga tata kelola dan operasi, dan dapat membantu Anda menyesuaikan proyek migrasi VM Anda ke dalam inisiatif yang lebih luas.

Migrasikan VM ke Google Cloud dengan Migrate to Virtual Machines.

Jika tujuan Anda adalah memindahkan mesin virtual dari lingkungan Anda saat ini (misalnya, pusat data VMware) ke Google Cloud , solusi bawaannya adalah Migrate to Virtual Machines, yang berfokus pada migrasi lift-and-shift dengan modifikasi otomatis minimal pada VM target.

Alat ini terintegrasi langsung ke konsol Google Cloud dan menggunakan mekanisme replikasi data berkelanjutan yang mereplikasi disk VM sumber saat VM tersebut masih beroperasi. VM pengujian, klon, dan akhirnya instance produksi di Compute Engine kemudian dibuat di atas data yang direplikasi ini.

Tahapan proses migrasi di Google Cloud

Migrate to Virtual Machines menyusun proses migrasi ke dalam beberapa fase yang sangat jelas: onboarding, replikasi, definisi target, kloning uji, cutover, dan penyelesaian . Alurnya cukup logis dan memungkinkan Anda untuk memvalidasi setiap langkah sebelum melanjutkan.

Selama fase orientasi, Anda memilih mesin virtual sumber yang ingin Anda migrasikan . Di lingkungan vSphere, misalnya, konsol Google Cloud akan menampilkan seluruh inventaris pusat data, dan Anda hanya memilih VM yang ingin Anda pindahkan, lalu menambahkannya ke proyek migrasi.

Selanjutnya, fase replikasi dimulai, di mana data disalin dari disk VM sumber ke Google Cloud tanpa menghentikan mesin. Replikasi berlangsung terus-menerus dan berjalan di latar belakang, meminimalkan dampak pada produksi. Fase ini terdiri dari langkah replikasi penuh awal (snapshot disk awal) dan langkah-langkah inkremental berikutnya, yang dieksekusi secara berkala (secara default, setiap dua jam) menggunakan mekanisme Changed Block Tracking (CBT).

Setelah replikasi berjalan, Anda menentukan detail VM target di Compute Engine : proyek, zona, tipe instance, memori, jaringan, dll. Parameter ini dapat dimodifikasi kapan saja dan akan digunakan saat membuat klon uji atau VM produksi akhir.

Fase selanjutnya adalah kloning uji. Kapan saja setelah menyelesaikan replikasi awal, Anda dapat membuat VM uji di Compute Engine dari data yang direplikasi dan pengaturan target. Kloning ini adalah snapshot statis dari mesin sumber pada saat itu dan berfungsi untuk memvalidasi perilaku di Google Cloud tanpa memodifikasi VM asli.

Selama fase transisi, setelah Anda menguji semua yang dibutuhkan, Migrasi ke Mesin Virtual akan mematikan VM sumber, melakukan replikasi akhir untuk menyinkronkan perubahan, dan membuat instance Compute Engine akhir yang akan menggantikan server asli. Inilah saat jendela pemeliharaan terjadi, karena VM sumber dimatikan untuk mencegah ketidaksesuaian data.

Terakhir, fase penyelesaian melibatkan pembersihan data replikasi dan sumber daya sementara yang terkait dengan migrasi. Penting untuk dicatat bahwa Anda akan terus membayar penyimpanan yang ditempati data ini sampai Anda menghapusnya, jadi sebaiknya selesaikan fase ini hanya setelah memverifikasi bahwa VM yang dimigrasikan berfungsi dengan benar dalam jangka panjang.

Adaptasi sistem operasi di Google Cloud

Agar VM yang dimigrasikan berfungsi dengan benar di Google Cloud, tidak cukup hanya dengan menyalin disk begitu saja; perlu dilakukan serangkaian adaptasi sistem operasi yang diterapkan secara otomatis di akhir setiap langkah replikasi.

Adaptasi ini mencakup perubahan pada konfigurasi jaringan, instalasi agen Compute Engine, dan pengaktifan konsol serial . Jenis penyesuaian yang tepat bergantung pada apakah mesin tersebut menggunakan Linux atau Windows, tetapi tujuannya selalu sama: agar VM dapat berjalan dan terintegrasi dengan benar ke dalam infrastruktur Google Cloud tanpa memerlukan terlalu banyak penyesuaian manual.

Selama pengujian, sangat penting untuk mengisolasi klon pengujian dari lingkungan produksi, karena VM sumber terus berjalan dan mereplikasi data . Jika tidak, Anda dapat memiliki dua instance aktif dari layanan yang sama yang merespons klien dan menyebabkan inkonsistensi.

Skenario keberhasilan dan kegagalan di Google Cloud

Selama fase transisi, beberapa skenario dapat terjadi yang harus dipahami dengan jelas sejak awal. Jika peralihan gagal karena alasan teknis (masalah jaringan, kesalahan konfigurasi, dll.), VM sumber akan dihentikan, tetapi replikasi akhir akan tetap valid. Dalam hal ini, prosedur yang biasa dilakukan adalah menyelidiki penyebab kegagalan dan mencoba kembali transisi.

Jika perubahan selesai tetapi VM baru di Compute Engine tidak berfungsi dengan benar , Anda dapat melakukan rollback: hentikan dan hapus instance yang bermasalah di cloud, mulai ulang VM sumber, dan alihkan lalu lintas kembali ke VM tersebut. Proses ini tidak sepenuhnya otomatis, jadi perlu perencanaan yang cermat, terutama terkait data yang ditulis ke instance yang gagal yang tidak akan direplikasi kembali ke sumber.

Ketika hasilnya memuaskan dan VM di Compute Engine berkinerja sesuai harapan, migrasi dianggap selesai secara operasional. Dari situ, Anda dapat mengoptimalkan instance, menyesuaikan tipe mesin, disk, dan jaringan , serta bersiap untuk menutup migrasi dengan fase finalisasi dan pembersihan data yang direplikasi.

Migrasi VM ke platform virtualisasi Rusia: contoh menggunakan VMmanager

Di beberapa negara, kebijakan sedang dipromosikan untuk mengganti perangkat lunak asing dengan solusi domestik. Hal ini menyebabkan situasi di mana beberapa pelanggan terus menggunakan produk internasional, tetapi dengan risiko yang jelas: masalah dalam memperbarui lisensi, larangan pembaruan, hilangnya dukungan resmi, dan bahkan potensi sanksi tambahan.

Untuk mengurangi risiko ini, banyak organisasi mempertimbangkan untuk beralih ke platform virtualisasi on-premises seperti VMmanager . Solusi yang sudah mapan ini, yang dirancang untuk instalasi kecil maupun infrastruktur besar, memungkinkan konsolidasi VM dari hypervisor yang berbeda tanpa memerlukan alat migrasi yang terlalu rumit.

Dokumentasi resmi VMmanager menjelaskan secara rinci proses impor VM dari Hyper-V, VirtualBox, VMware, Xen, dan platform berbasis QEMU-KVM lainnya . Pendekatan tipikal dibagi menjadi empat langkah: mempersiapkan VM untuk migrasi, mempersiapkan lingkungan VMmanager, mentransfer disk mesin, dan menjalankannya di hypervisor baru.

Selama persiapan VM, Anda biasanya perlu menyesuaikan driver, menghapus alat-alat tertentu dari hypervisor sebelumnya (seperti VMware Tools), dan mengkonfigurasi pengaturan jaringan agar dapat dengan mudah dikonfigurasi ulang di tujuan. Kemudian, Anda mengkonfigurasi VMmanager untuk menerima VM ini, menyalin disk (vmdk, vhdx, qcow2, dll.) ke penyimpanan platform, dan membuat catatan mesin virtual yang mengarah ke disk tersebut.

Jika proses menjadi rumit di titik tertentu, administrator dapat mengandalkan dukungan teknis VMmanager , yang biasanya para insinyurnya membantu menyelesaikan ketidakkompatibilitas dan menyempurnakan detail migrasi agar transfer berjalan semulus mungkin.

Uji migrasi menggunakan konversi disk.

Di banyak lingkungan, terutama saat bekerja dengan penyimpanan berbasis QEMU-KVM atau sistem file tertentu , migrasi percobaan digunakan yang berfokus pada konversi format disk virtual dan pembuatan VM sementara untuk memvalidasi proses tersebut.

Pendekatan umum melibatkan konversi disk VMDK ke format asli lingkungan baru dan meluncurkan mesin virtual dari disk yang telah dikonversi tersebut, lalu menempatkannya di qtree atau volume yang telah ditentukan. Metode ini mensimulasikan migrasi sebenarnya tanpa memengaruhi VM produksi asli.

Pengujian ini memungkinkan kami untuk memverifikasi bahwa sistem operasi melakukan booting dengan benar setelah konversi , bahwa driver yang diperlukan tersedia, bahwa jaringan dikonfigurasi tanpa masalah, dan apakah ada perubahan tambahan yang diperlukan (menginstal agen, mengkonfigurasi ulang layanan, dll.). Migrasi akhir hanya akan dipertimbangkan jika migrasi uji dianggap stabil dan bebas kesalahan.

Perencanaan dan pelaksanaan pengujian yang tepat akan secara drastis mengurangi risiko menghadapi kejutan yang tidak menyenangkan selama periode pemeliharaan, baik saat Anda bermigrasi ke cloud publik atau mengganti platform virtualisasi on-premises Anda.

Migrasi mesin virtual, baik antar host lokal, ke cloud publik seperti Azure atau Google Cloud, atau ke platform yang lebih baru seperti VMmanager, adalah proses yang membutuhkan perencanaan, pengujian, dan pemahaman yang mendalam tentang replikasi, adaptasi sistem operasi, dan fase peralihan . Dengan mengikuti praktik terbaik yang dijelaskan, memanfaatkan alat bawaan dari setiap vendor, dan selalu memvalidasi dengan migrasi uji, Anda dapat mengubah infrastruktur yang mendasarinya hampir tanpa hambatan bagi pengguna, sekaligus meningkatkan ketahanan, kinerja, dan skalabilitas.