Memigrasikan beban kerja ke Azure VMware Solution

Artikel ini memberikan panduan untuk membantu pembuat keputusan menentukan strategi migrasi mereka untuk Azure VMware Solution, termasuk fase perencanaan, eksekusi, dan penonaktifan.

Azure VMware Solution menyediakan jalur terstruktur untuk memigrasikan beban kerja berbasis VMware ke Azure dengan perubahan aplikasi minimal. Keberhasilan bergantung pada lebih dari sekadar memindahkan mesin virtual. Organisasi memerlukan kebijakan migrasi yang jelas, kriteria penilaian beban kerja, standar validasi, dan kontrol eksekusi yang mengurangi risiko, menjaga kelangsungan operasional, dan mendukung tujuan platform jangka panjang.

Rekomendasi: Tentukan strategi migrasi, pendekatan penilaian beban kerja, urutan migrasi, dan persyaratan validasi Anda sebelum memigrasikan beban kerja ke Azure VMware Solution.

1. Perencanaan migrasi

Sebelum Anda merancang apa pun, buat gambaran yang jelas tentang apa yang Anda migrasikan, dalam urutan apa, dan mengapa. Gunakan metodologi rencana Cloud Adoption Framework untuk menilai properti Anda. Azure VMware Solution paling sesuai dengan pendekatan rehost, di mana Anda membutuhkan gangguan minimal dan tidak ada modernisasi jangka pendek. Ini bukan rumah yang tepat untuk setiap aplikasi, dan fase perencanaan adalah tempat Anda memutuskan.

1.1 Penemuan dan inventori

Azure Migrate memindai lingkungan vSphere lokal Anda dan membangun inventarisasi komputer virtual, penggunaan sumber dayanya, dan dependensinya. Data ini menginformasikan ukuran (berapa banyak host dan jenis host mana), dan perencanaan gelombang (beban kerja mana yang bergerak bersama). Azure Migrate tidak melakukan pemindahan ke Azure VMware Solution. Ini memberi Anda bukti untuk ukuran dan urutan proyek.

1.2 Strategi migrasi

Azure VMware Solution terutama mendukung pendekatan rehost. Aplikasi yang memerlukan refaktorisasi atau perancangan ulang arsitektur mungkin lebih cocok menggunakan komputasi native Azure. Catat keputusan-keputusan ini agar rencana mencerminkan pilihan yang dipertimbangkan dengan saksama, bukan pengaturan bawaan. Lihat Memilih strategi migrasi cloud.

1.3 Penilaian beban kerja

Tidak setiap beban kerja sama-sama cocok untuk Azure VMware Solution. Sebelum Anda menetapkan beban kerja ke gelombang migrasi, evaluasi persyaratan teknis, dependensi operasional, dan kecocokan platform mereka. Penilaian terstruktur membantu Anda mengidentifikasi risiko lebih awal, memvalidasi kesesuaian, dan memastikan bahwa rencana migrasi mencerminkan prioritas bisnis daripada asumsi.

1.3.1 Persyaratan

Sebelum menugaskan beban kerja ke dalam gelombang migrasi, evaluasilah persyaratan teknis, operasional, dan bisnis yang memengaruhi keberhasilannya di Azure VMware Solution. Penilaian ini membantu Anda menentukan kesesuaian platform, mengidentifikasi potensi tantangan migrasi, dan memberikan informasi yang diperlukan untuk keputusan ukuran, urutan, dan kesiapan. Saat menilai setiap beban kerja, fokus pada:

Persyaratan performa: Pahami permintaan CPU, memori, IOPS penyimpanan, dan throughput jaringan. Petakan persyaratan ini ke SKU host Azure VMware Solution dan kebijakan penyimpanan vSAN, termasuk konfigurasi RAID dan setelan kegagalan yang dapat ditoleransi (FTT).
Dependensi aplikasi: Identifikasi sistem mana yang berkomunikasi dengan setiap beban kerja. Dependensi menentukan perencanaan gelombang migrasi Anda dan apakah sistem dependen perlu bergerak bersama.
Persyaratan kompatibilitas: Konfirmasikan bahwa sistem operasi tamu dan perangkat lunak pihak ketiga didukung pada Azure VMware Solution. Sebagian besar beban kerja yang berjalan di vSphere on-premises dapat berjalan di Azure VMware Solution tanpa perlu dimodifikasi, tetapi lakukan validasi alih-alih berasumsi, dan pastikan Anda menguji pendekatan rollback untuk migrasi yang mengalami masalah.
Persyaratan jaringan: Dokumentasikan segmen jaringan, alamat IP, konfigurasi DNS, dan aturan firewall yang diperlukan setiap beban kerja. Identifikasi beban kerja yang sensitif terhadap latensi dan pastikan arsitektur jaringan dioptimalkan untuk mendukung tuntutannya.

1.3.2 Perawatan beban kerja

Penilaian beban kerja mengidentifikasi apa yang dibutuhkan beban kerja. Penanganan beban kerja menentukan tindakan yang harus diambil. Pengambil keputusan harus mengevaluasi apakah setiap aplikasi berada di Azure VMware Solution, apakah harus tetap lokal, atau apakah bagian aplikasi lebih baik dilayani oleh layanan asli Azure. Untuk setiap beban kerja, tentukan:

Apakah beban kerja itu memang seharusnya ada di sana. Beban kerja yang sudah berjalan dengan baik di vSphere adalah kandidat alami, terutama yang tidak memiliki rencana modernisasi jangka pendek. Untuk beban kerja yang akan dipensiunkan atau digantikan oleh SaaS, pertimbangkan apakah memigrasikannya memberikan nilai tambah atau sebaiknya tetap sebagaimana adanya hingga akhir masa pakainya.
Apakah setiap tingkat memang termasuk di sana. Beban kerja sering kali memiliki lebih dari satu lapisan, seperti front-end web dan database. Anda dapat menjalankan komputer virtual aplikasi pada Azure VMware Solution dan menghubungkannya ke layanan data asli Azure seperti Azure SQL Database. Konfigurasi tersebut memberi Anda manfaat database terkelola bersama beban kerja VMware Anda, dan mengurangi biaya host dan lisensi VMware Anda.

1.4 Kesiapan migrasi

Tentukan persyaratan operasional, performa, keamanan, dan tata kelola minimum yang harus dipenuhi setiap beban kerja sebelum Anda menyetujuinya untuk penggunaan produksi.

Terapkan kerangka kerja validasi yang konsisten di setiap gelombang migrasi. Kerangka kerja harus menetapkan pemeriksaan wajib, kriteria persetujuan, serta bukti yang harus diberikan oleh tim sebelum persetujuan cutover. Setidaknya, validasikan:

Status kesehatan replikasi HCX
Keterutean segmen NSX
Kesehatan host ESXi
Keterjangkauan identitas dan autentikasi dari segmen target
Kesehatan layanan pendukung seperti pencadangan dan pemantauan

Tentukan apakah tim harus mengambil metrik performa dasar dari lingkungan sumber sebelum migrasi. Pengukuran ini menyediakan titik referensi untuk memvalidasi performa pascamigrasi dan mengidentifikasi regresi.

Sebelum cutover, wajibkan tim untuk menentukan apakah rekaman DNS eksternal, konfigurasi load balancer, titik akhir aplikasi, atau dependensi konektivitas lainnya memerlukan pembaruan. Sertakan semua perubahan yang diperlukan dalam rencana cutover untuk gelombang tersebut guna mengurangi risiko gangguan layanan.

1.5 Urutan migrasi Azure VMware Solution

Urutan migrasi menentukan beban kerja mana yang berpindah ke Azure VMware Solution pertama, kedua, dan sebagainya. Perencanaan gelombang yang baik mengurangi risiko dan menghindari gangguan yang tidak perlu.

Kelompokkan menurut dependensi: Gunakan data dependensi dari penemuan untuk menemukan set komputer virtual yang bekerja sama erat, seperti server aplikasi dan databasenya. Pindahkan semuanya dalam gelombang yang sama agar trafik tidak perlu melintasi jaringan untuk setiap permintaan saat satu bagian masih berada di lingkungan lokal.
Petakan aturan yang ada: Dokumentasikan aturan afinitas atau anti-afinitas dari lingkungan lokal Anda dan rencanakan cara mereproduksinya. Azure VMware Solution kebijakan penempatan menerapkan afinitas antara mesin virtual dan host, yang penting untuk kendala lisensi seperti SQL Server dan untuk kebutuhan kinerja yang ketat.
Urutan berdasarkan risiko: Mulailah dengan beban kerja berisiko lebih rendah seperti sistem non-produksi atau aplikasi dengan beberapa dependensi. Tim Anda menumbuhkan keyakinan terhadap proses tersebut sebelum proses itu digunakan untuk aplikasi yang krusial bagi bisnis. Beralih ke beban kerja yang lebih kompleks seiring bertambahnya pengalaman.
Selaraskan dengan paket ekstensi jaringan: Dasarkan urutan Anda pada tata letak jaringan lokal Anda. Ketika beberapa aplikasi berbagi segmen jaringan, migrasikan dalam gelombang yang sama atau dalam gelombang berturut-turut. Anda kemudian dapat memotong segmen ke jaringan asli Azure VMware Solution segera dan menghapus ekstensi sementara.

1.6 Alat migrasi

Gunakan VMware HCX untuk memindahkan beban kerja ke Azure VMware Solution dengan gangguan minimal. HCX Enterprise disertakan tanpa biaya tambahan dan terinstal secara default, sehingga menghadirkan opsi seperti Replication Assisted vMotion dan Mobility Optimized Networking. Anda tidak perlu menggunakan HCX, dan Anda juga dapat memigrasikan beban kerja fisik menggunakan solusi migrasi mitra.

1.6.1 Pendekatan migrasi

vMotion memindahkan beban kerja yang sedang berjalan tanpa waktu henti, dan pada Generasi 2 umumnya berkinerja lebih cepat daripada metode massal. Migrasi yang dibantu replikasi dan massal dapat berjalan lebih lambat pada Generasi 2 saat ini, jadi rencanakan jendela yang lebih panjang dan jadwalkan gelombang yang sesuai. Lihat pertimbangan desain cloud privat Azure VMware Solution Generasi 2.

1.6.2 Tata kelola ekstensi jaringan

Beberapa tim memperlakukan ekstensi jaringan sebagai desain permanen. Bukan begitu. Biarkan ekstensi terbuka hanya untuk jendela migrasi. Ekstensi jaringan HCX membentangkan jaringan lokal ke dalam Azure VMware Solution di Lapisan 2, yang memungkinkan beban kerja menyimpan alamat yang ada selama pemindahan. Desain ini menghindari konfigurasi ulang aplikasi sejak awal, tetapi memiliki konsekuensi yang harus dikelola oleh pengambil keputusan.

Ketergantungan pada infrastruktur lokal. Jaringan yang diperluas biasanya menyimpan gatewaynya secara lokal, sehingga beban kerja masih bergantung pada situs sumber setelah dipindahkan.
Perutean yang tidak efisien. Lalu lintas dapat kembali ke lingkungan on-premises lalu kembali lagi, suatu pola yang disebut tromboning, yang menambah latensi dan titik-titik kegagalan.

Tetapkan kebijakan perusahaan. Perluas jaringan hanya ketika beban kerja tidak dapat mengubah alamatnya, dan menghapus setiap ekstensi setelah beban kerjanya bergerak. Nilai jaringan lokal Anda terlebih dahulu sehingga Anda tahu segmen mana yang membutuhkan ekstensi dan berapa lama. Penilaian tersebut memberi umpan pada rencana gelombang dan garis waktu ekstensi Anda. Mobility Optimized Networking dapat mengurangi tromboning dalam kasus tertentu, jadi konfirmasikan konfigurasi yang didukung sebelum Anda mengaktifkannya. Lihat Mengonfigurasi ekstensi jaringan HCX.

2. Persiapan migrasi

Urutan penyebaran berikut mencerminkan dependensi antar tahap. Setiap langkah mengasumsikan langkah sebelumnya selesai dan divalidasi.

Zona pendaratan platform: Pastikan semua layanan jaringan, identitas, keamanan, dan pemantauan terpusat yang diperlukan siap diintegrasikan dengan beban kerja Azure VMware. Terapkan garis besar tata kelola dan keamanan melalui Azure Policy ke hierarki grup manajemen Anda yang membantu Anda mencapai persyaratan kepatuhan Anda. Generasi 2 disebarkan ke jaringan virtual Anda, sehingga garis besar kebijakan yang memberlakukan aturan ketat pada grup keamanan jaringan atau tabel rute dapat memblokir penyebaran. Hapus kebijakan spesifik tersebut dari jaringan virtual cloud privat sebelum Anda menyebarkan, lalu terapkan kembali setelahnya. Rencanakan pengecualian ini dalam baseline Anda agar tata kelola tidak menghambat peluncuran.
Zona penempatan beban kerja: Tempatkan zona penempatan beban kerja (langganan) Anda dalam grup manajemen yang tepat, baik online maupun internal ("Corp").
Rentang alamat IP: Cadangkan blok alamat minimum /22 untuk cloud privat. Untuk Generasi 2, sediakan juga dua blok /24 tambahan untuk pengelolaan dan uplink HCX. Konfirmasikan bahwa tidak ada rentang ini yang tumpang tindih dengan ruang alamat cloud lokal, Azure, atau lainnya. Anda tidak dapat dengan mudah memperbaikinya setelah penerapan. Lihat Pertimbangan desain Generasi 2.
Permintaan kuota: Meminta kuota lebih awal, karena alokasi dapat memakan waktu hingga lima hari kerja. Ajukan kapasitas yang cukup untuk pertumbuhan dan pemulihan setelah bencana, seperti redundansi N+1, yaitu satu host lebih banyak daripada yang dibutuhkan beban kerja. Pastikan lisensi Portable VMware Cloud Foundation yang diperlukan untuk penerapan baru. Lihat Permintaan kuota host.
Azure VMware Solution penyebaran cloud privat: Provisikan cloud privat Generasi 2 ke dalam jaringan virtual Azure. Lihat Membuat cloud privat Generasi 2.
Konfigurasi jaringan dan identitas: Rekan jaringan cloud privat ke hub Anda dan buat konektivitas lokal. Sambungkan vCenter Server ke sumber identitas eksternal Anda sehingga administrator masuk dengan akun terkelola alih-alih kredensial bawaan bersama.
Pemantauan dan manajemen: Teruskan log ke solusi manajemen log Anda dan konfigurasikan pemberitahuan Service Health. Hubungkan komputer virtual tamu melalui Azure Arc sehingga Anda dapat mengelolanya dengan alat Azure yang sama seperti yang Anda gunakan di tempat lain.
Penginstalan HCX: Instal HCX dan uji konektivitas situs-ke-situs sebelum Anda memulai gelombang pertama.

3. Eksekusi migrasi

Tentukan arti "selesai" sebelum setiap gelombang. Gelombang selesai ketika beban kerja divalidasi, ekstensi jaringan dihapus, dan aplikasi sehat dalam keadaan permanen.

Tentukan kriteria pemulihan sebelum tiap gelombang migrasi dan uji prosedur pemulihan sebelum Anda memigrasikan sistem produksi. HCX mendukung migrasi terbalik, dan pendekatan yang tepat tergantung pada jenis migrasi yang Anda gunakan. Kriteria keberhasilan gelombang meliputi:

Setiap komputer virtual dalam gelombang berjalan pada Azure VMware Solution dan tidak lagi bergantung pada ekstensi jaringan untuk lalu lintas produksi.
Setiap aplikasi dapat dijangkau oleh penggunanya dan sistem dependennya.
Setiap komputer virtual muncul di alat pemantauan Anda tanpa peringatan atau kesalahan.
Putar kembali tidak lagi diperlukan dan Anda dapat secara resmi menutupnya.
Kinerja aplikasi setara dengan atau melampaui tolok ukur dasar.
Beban kerja memenuhi persyaratan keamanan dan kepatuhan Anda.
Beban kerja telah berhasil diintegrasikan ke solusi pencadangan dan pemulihan bencana.

4. Evaluasi migrasi dan penonaktifan

Migrasi tidak berakhir saat beban kerja menyala di Azure VMware Solution. Pastikan bahwa beban kerja beroperasi dengan benar di lingkungan barunya, pastikan bahwa pengaturan sementara selama migrasi telah dihapus, dan nonaktifkan infrastruktur sumber secara resmi. Membiarkan infrastruktur lokal Anda tetap seperti adanya dapat mengakibatkan dependensi yang belum terdeteksi dan tidak terdokumentasi. Proses evaluasi dan penonaktifan yang disiplin memastikan organisasi mewujudkan manfaat migrasi yang diharapkan tanpa membawa biaya atau risiko operasional yang tidak perlu.

4.1 Kesiapan produksi pasca-alih sistem

Tetapkan kriteria pasca-cutover yang memastikan beban kerja berfungsi sebagaimana mestinya. Periksa keterjangkauan jaringan dan resolusi nama. Periksa fungsi aplikasi dan komunikasi dengan sistem dependen. Setelah setiap mesin virtual dipindahkan, pastikan mesin virtual tersebut dapat dijalankan, bahwa sumber dayanya sesuai dengan rencana, dan bahwa kebijakan penyimpanan yang benar diterapkan. Bandingkan kinerja dengan tolok ukur sebelum migrasi.

Tentukan kebijakan paritas Anda. Keputusan utamanya adalah apakah beban kerja yang dimigrasikan harus mencapai paritas penuh dengan status lokal sebelum Anda menyebutnya siap produksi, atau apakah Anda mengizinkan penyimpangan sementara. Banyak organisasi menuntut paritas performa segera untuk sistem yang menghadap pelanggan tetapi memberikan aplikasi internal periode stabilisasi singkat dengan tenggat waktu remediasi tetap.

4.2 Validasi konektivitas

Validasikan konektivitas secara menyeluruh di seluruh Azure VMware Solution, Azure, lingkungan lokal, internet, dan resolusi nama. Jalankan pengujian asap aplikasi untuk mengonfirmasi beban kerja yang melayani tujuannya. Konfirmasi apakah catatan nama eksternal atau pengaturan load balancer perlu diperbarui sebagai bagian dari proses peralihan.

Jika Anda membangun instans sekunder Azure VMware Solution untuk pemulihan bencana, pastikan instans tersebut dapat dijangkau dari instans utama dan dari klien atau layanan pendukung apa pun yang perlu terhubung ke instans tersebut jika diaktifkan.

4.3 Pembubaran ekstensi jaringan

Setelah semua beban kerja pada segmen yang diperluas telah dipindahkan, hapus ekstensi HCX Layer 2 dan konfirmasikan bahwa gateway native Azure VMware Solution merutekan lalu lintas dengan benar. Jangan biarkan ekstensi tetap terpasang lebih lama daripada yang diperlukan untuk migrasi.

4.4 Menonaktifkan lingkungan sumber

Penonaktifan secara resmi membebaskan kapasitas sumber daya, lisensi, dan cakupan operasional. Anggap ini sebagai serah terima yang terkelola, bukan sekadar tugas pembersihan. Jika Anda melewatkan proses dekomisioning, Anda akan tetap membayar infrastruktur yang menganggur dan menanggung risiko keamanan. Gunakan Menonaktifkan beban kerja sumber setelah migrasi ke cloud untuk menetapkan urutan operasi, periode retensi untuk cadangan sumber, persetujuan yang diperlukan untuk mematikan sistem sumber, dan kriteria untuk menarik kembali lisensi dan perangkat keras.

Langkah berikutnya

Desain beban kerja:

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-08-26