Bagikan melalui

Merencanakan migrasi sumber daya IaaS dari klasik ke Azure Resource Manager

  • Artikel

Berlaku untuk: ✔️ VM Linux ✔️ VM Windows

Penting

Saat ini, sekitar 90% Komputer Virtual IaaS menggunakan Azure Resource Manager. Pada 28 Februari 2020, VM klasik telah ditolak dan akan sepenuhnya dihentikan pada 6 September 2023. Pelajari lebih lanjut tentang penghentian ini dan bagaimana hal itu memengaruhi Anda.

Meskipun Azure Resource Manager menawarkan banyak fitur luar biasa, sangat penting untuk merencanakan perjalanan migrasi Anda untuk memastikan semuanya berjalan lancar. Menghabiskan waktu untuk perencanaan akan memastikan bahwa Anda tidak mengalami masalah saat menjalankan aktivitas migrasi.

Catatan

Panduan berikut ini banyak diisi oleh tim Penasihat Pelanggan Azure dan arsitek Cloud Solution yang bekerja bersama pelanggan untuk memigrasikan lingkungan besar. Dengan demikian, dokumen ini akan terus diperbarui karena pola keberhasilan baru muncul, jadi periksa kembali dari waktu ke waktu untuk melihat apakah ada rekomendasi baru.

Ada empat fase umum pada perjalanan migrasi:

Fase migrasi

Paket

Pertimbangan teknis dan tradeoff

Bergantung pada ukuran persyaratan teknis, geografi, dan praktik operasional, Anda mungkin ingin mempertimbangkan:

  1. Mengapa Azure Resource Manager diperlukan untuk organisasi Anda? Apa alasan perusahaan untuk migrasi?
  2. Apa alasan teknis memilih Azure Resource Manager? Bagaimana (jika ada) layanan Azure lainnya yang ingin Anda gunakan?
  3. Aplikasi mana (atau kumpulan komputer virtual) yang disertakan dalam migrasi?
  4. Skenario mana yang didukung dengan API migrasi? Tinjau fitur dan konfigurasi yang tidak didukung.
  5. Apakah tim operasional Anda sekarang akan mendukung aplikasi/VM di Klasik dan Azure Resource Manager?
  6. Bagaimana Azure Resource Manager mengubah proses penyebaran, manajemen, pemantauan, dan pelaporan VM Anda? Apakah skrip penyebaran Anda perlu diperbarui?
  7. Apa rencana komunikasi untuk memperingatkan pemangku kepentingan (pengguna akhir, pemilik aplikasi, dan pemilik infrastruktur)?
  8. Bergantung pada kompleksitas lingkungan, haruskah ada periode pemeliharaan di mana aplikasi tidak dapat diakses bagi pengguna akhir dan pemilik aplikasi? Jika iya, untuk berapa lama?
  9. Apa rencana pelatihan untuk memastikan pemangku kepentingan dapat memahami dengan baik dan mahir menggunakan Azure Resource Manager?
  10. Apa rencana manajemen program atau manajemen proyek untuk migrasi ini?
  11. Bagaimana garis waktu untuk migrasi Azure Resource Manager dan peta strategi teknologi yang terkait lainnya? Apakah mereka selaras secara optimal?

Pola keberhasilan

Pelanggan yang sukses memiliki rencana terperinci di mana pertanyaan sebelumnya dibahas, didokumentasikan, dan diatur. Pastikan rencana migrasi dikomunikasikan secara luas kepada sponsor dan pemangku kepentingan. Pastikan Anda paham tentang opsi migrasi; sangat disarankan untuk membaca dokumen migrasi yang diatur di bawah ini.

Perangkap yang harus dihindari

  • Kegagalan saat merencanakan. Langkah-langkah teknologi dari migrasi ini terbukti dan hasilnya dapat diprediksi.
  • Berasumsi bahwa API migrasi yang didukung platform akan memperhitungkan semua skenario. Baca fitur dan konfigurasi yang tidak didukung untuk memahami skenario mana yang didukung.
  • Tidak merencanakan potensi penonaktifan aplikasi untuk pengguna akhir. Rencanakan buffer yang cukup untuk memperingatkan pengguna akhir tentang waktu aplikasi yang mungkin tidak tersedia.

Uji Lab

Replikasi lingkungan Anda dan lakukan migrasi uji

Catatan

Replikasi yang tepat dari lingkungan yang sudah ada dijalankan dengan menggunakan alat yang dibuat komunitas, yang tidak didukung secara resmi oleh Dukungan Microsoft. Oleh karena itu, langkah ini opsional tetapi ini adalah cara terbaik untuk mengetahui masalah tanpa menyentuh lingkungan produksi Anda. Jika menggunakan alat yang dibuat komunitas bukanlah pilihan, maka baca tentang rekomendasi Memvalidasi/Menyiapkan/Membatalkan Dry Run di bawah ini.

Melakukan uji lab skenario yang tepat (komputasi, jaringan, dan penyimpanan) adalah cara terbaik untuk memastikan migrasi yang lancar. Pengujian ini akan membantu memastikan:

  • Lab yang sepenuhnya terpisah atau lingkungan non-produksi yang sudah ada untuk diuji. Kami merekomendasikan lab yang sepenuhnya terpisah yang dapat dimigrasikan berulang kali dan dapat dimodifikasi secara destruktif. Skrip untuk mengumpulkan/menghidrasi metadata dari langganan yang nyata tercantum di bawah ini.

  • Ada baiknya membuat lab dalam langganan terpisah. Alasannya yaitu lab akan dirobohkan berulang kali, dan memiliki langganan yang terpisah dan terisolasi akan mengurangi kemungkinan terhapusnya sesuatu yang nyata secara tidak sengaja.

    Hal ini dapat dilakukan dengan menggunakan alat AsmMetadataParser. Baca selengkapnya tentang alat ini di sini

Pola keberhasilan

Berikut ini adalah masalah yang ditemukan di kasus migrasi yang lebih besar. Ini bukan daftar lengkap dan Anda harus merujuk ke fitur dan konfigurasi yang tidak didukung untuk detail selengkapnya. Anda mungkin mengalami atau tidak mengalami masalah teknis ini tetapi jika Anda menyelesaikannya sebelum mencoba migrasi, mungkin akan memastikan pengalaman yang lebih lancar.

  • Lakukan Validasi/Siapkan/Batalkan Dry Run - Langkah ini mungkin yang terpenting untuk memastikan kesuksesan migrasi Klasik ke Azure Resource Manager. API migrasi memiliki tiga langkah utama: Validasi, Siapkan, dan Terapkan. Validasi akan membaca keadaan lingkungan klasik Anda dan mengembalikan hasil dari semua masalah. Namun, karena beberapa masalah mungkin ada di tumpukan Azure Resource Manager, Validasi tidak akan menangkap semuanya. Langkah selanjutnya dalam proses migrasi, langkah Siapkan akan membantu mengekspos masalah tersebut. Persiapan akan memindahkan metadata dari Klasik ke Azure Resource Manager, tetapi tidak akan menerapkan pemindahan, dan tidak akan menghapus atau mengubah apa pun di sisi Klasik. Dry run melibatkan persiapan migrasi, lalu membatalkan (tidak melakukan) persiapan migrasi. Tujuan memvalidasi/menyiapkan/membatalkan dry run adalah untuk melihat semua metadata di tumpukan Azure Resource Manager, memeriksanya (secara terprogram atau di Portal), dan memverifikasi bahwa semuanya bermigrasi dengan benar, dan menyelesaikan masalah teknis. Langkah ini juga akan memberi Anda durasi migrasi sehingga Anda dapat merencanakan waktu henti yang sesuai. Validasi/siapkan/batalkan tidak menyebabkan waktu henti pengguna; oleh karena itu, tidak mengganggu penggunaan aplikasi.

    • Item di bawah ini perlu dipecahkan sebelum dry run, tetapi dry run test juga akan membersihkan langkah-langkah persiapan ini dengan aman jika terlewatkan. Selama migrasi perusahaan, kami telah menetapkan dry run sebagai cara yang aman dan tak ternilai untuk memastikan kesiapan migrasi.
    • Saat persiapan sedang berjalan, sarana kontrol (operasi manajemen Azure) akan dikunci untuk seluruh jaringan virtual, sehingga tidak ada perubahan yang dapat dilakukan pada metadata VM selama memvalidasi/mempersiapkan/membatalkan. Tetapi jika tidak, fungsi aplikasi apa pun (RD, penggunaan VM, dll.) tidak akan terpengaruh. Pengguna VM tidak akan tahu bahwa dry run sedang dijalankan.

  • Sirkuit Rute Ekspres dan VPN. Saat ini Gateway Rute Ekspres dengan tautan otorisasi tidak dapat dimigrasikan tanpa waktu henti. Untuk solusinya, lihat Memigrasikan sirkuit ExpressRoute dan jaringan virtual terkait dari model penyebaran klasik ke Resource Manager.

  • Ekstensi VM - Ekstensi Virtual Machine berpotensi menjadi salah satu hambatan terbesar untuk memigrasikan VM yang sedang berjalan. Perbaikan Ekstensi VM bisa memakan waktu 1-2 hari ke depan, jadi rencanakan jadwal tersebut. Agen Azure yang berfungsi diperlukan untuk melaporkan kembali status Ekstensi VM yang menjalankan VM. Jika status kembali seburuk VM yang sedang berjalan, migrasi akan dihentikan. Agen itu sendiri tidak perlu bekerja untuk mengaktifkan migrasi, tetapi jika ekstensi ada di VM, maka agen kerja DAN konektivitas internet keluar (dengan DNS) akan diperlukan agar migrasi bergerak maju.

    • Jika konektivitas ke server DNS hilang selama migrasi, semua Ekstensi VM kecuali BGInfo v1. harus terlebih dahulu dihapus dari setiap VM sebelum migrasi disiapkan, kemudian ditambahkan kembali ke VM setelah migrasi Azure Resource Manager. Pengaturan ini hanya untuk VM yang sedang berjalan. Jika VM dihentikan alokasinya, Ekstensi VM tidak perlu dihapus. Catatan: Banyak ekstensi seperti diagnostik Azure dan pemantauan Defender untuk Cloud akan menginstal ulang diri setelah migrasi, jadi menghapusnya bukan masalah.

    • Selain itu, pastikan Kelompok Keamanan Jaringan tidak membatasi akses internet keluar. Hal ini bisa terjadi dengan beberapa konfigurasi Grup Keamanan Jaringan. Akses internet keluar (dan DNS) diperlukan agar Ekstensi VM dimigrasikan ke Azure Resource Manager.

    • Ada dua versi ekstensi BGInfo: v1 dan v2. Jika VM dibuat menggunakan portal Microsoft Azure atau PowerShell, VM kemungkinan akan memiliki ekstensi v1 di dalamnya. Ekstensi ini tidak perlu dihapus dan akan dilewati (tidak dimigrasikan) oleh API migrasi. Namun, jika VM Klasik dibuat dengan portal Microsoft Azure baru, kemungkinan akan memiliki BGInfo versi v2 berbasis JSON, yang dapat dimigrasikan ke Azure Resource Manager asalkan agen bekerja dan memiliki akses internet keluar (dan DNS).

    • Opsi Remediasi 1. Jika Anda tahu VM Anda tidak akan memiliki akses internet keluar, layanan DNS yang berfungsi, dan agen Azure yang berfungsi pada VM, maka hapus instalan semua ekstensi VM sebagai bagian dari migrasi sebelum Persiapan, lalu instal ulang Ekstensi VM setelah migrasi.

    • Opsi Remediasi 2. Jika ekstensi VM terlalu besar, opsi lain adalah mematikan/tidak mengalokasikan semua VM sebelum migrasi. Migrasikan VM yang tidak dialokasikan, lalu hidupkan ulang di sisi Azure Resource Manager. Keuntungannya yaitu ekstensi VM akan bermigrasi. Kelemahannya adalah bahwa semua IP Virtual yang dilihat publik akan hilang (mungkin non-starter), dan jelas VM akan ditutup, hal ini menyebabkan dampak yang jauh lebih besar pada aplikasi yang bekerja.

      Catatan

      Jika kebijakan Pertahanan Microsoft untuk Cloud dikonfigurasi terhadap VM yang sedang berjalan yang dimigrasikan, kebijakan keamanan perlu dihentikan sebelum menghapus ekstensi, jika tidak, ekstensi pemantauan keamanan akan dipasang ulang secara otomatis pada VM setelah menghapusnya.

  • Rangkaian Ketersediaan - Agar jaringan virtual (vNet) dimigrasikan ke Azure Resource Manager, penyebaran Klasik (yaitu layanan cloud) berisi semua VM harus dalam satu rangkaian ketersediaan, atau semua VM tidak boleh dalam rangkaian ketersediaan apa pun. Memiliki lebih dari satu set ketersediaan di layanan cloud tidak kompatibel dengan Azure Resource Manager dan akan menghentikan migrasi. Selain itu, tidak boleh ada beberapa VM dalam set ketersediaan, dan beberapa VM tidak dalam set ketersediaan. Untuk mengatasinya, Anda harus memulihkan atau mengalihkan layanan awan Anda. Merencanakan sesuai dengan ini mungkin memakan waktu.

  • Penyebaran Peran Web/Pekerja - Cloud Services yang berisi peran web dan pekerja tidak dapat bermigrasi ke Azure Resource Manager. Peran web/pekerja harus terlebih dahulu dihapus dari jaringan virtual sebelum migrasi dapat dimulai. Solusi yang umum adalah memindahkan instans peran web/pekerja ke jaringan virtual Klasik terpisah yang juga terkait dengan sirkuit ExpressRoute, atau untuk memigrasikan kode ke App Services PaaS yang lebih baru (pembahasan terkait ini di luar lingkup dokumen ini). Dalam kasus pemindahan ulang sebelumnya, buat jaringan virtual Klasik baru, pindahkan/sebarkan ulang peran web/pekerja ke jaringan virtual baru itu, lalu hapus penyebaran dari jaringan virtual yang dipindahkan. Tidak perlu perubahan kode. Kemampuan Virtual Network Peering baru dapat digunakan untuk menyatukan jaringan virtual klasik yang berisi peran web/pekerja dan jaringan virtual lainnya di wilayah Azure yang sama seperti jaringan virtual yang sedang dimigrasikan (setelah migrasi jaringan virtual selesai karena jaringan virtual peered tidak dapat dimigrasikan), karenanya memberikan kemampuan yang sama tanpa kehilangan performa dan tidak ada penalti latensi/bandwidth. Mengingat penambahan Virtual Network Peering, penyebaran peran web/pekerja kini dapat dengan mudah dimitigasi dan tidak memblokir migrasi ke Azure Resource Manager.

  • Kuota Azure Resource Manager - Wilayah Azure memiliki kuota/batasan terpisah untuk Klasik dan Azure Resource Manager. Meskipun dalam skenario migrasi perangkat keras baru tidak sedang digunakan (kami menukar VM yang ada dari Klasik ke Azure Resource Manager), kuota Azure Resource Manager masih harus diberlakukan dengan kapasitas yang cukup sebelum migrasi dapat dimulai. Tercantum di bawah ini adalah batas utama yang menyebabkan masalah. Buka tiket dukungan kuota untuk menaikkan batas.

    Catatan

    Batas-batas ini perlu dinaikkan di wilayah yang sama dengan lingkungan Anda saat ini untuk dimigrasikan.

    • Antarmuka Jaringan

    • Load Balancer

    • IP Publik

    • IP Publik Statis

    • Core

    • Kelompok Keamanan Jaringan

    • Tabel Rute

      Anda dapat memeriksa kuota Azure Resource Manager saat ini menggunakan perintah berikut dengan versi terbaru Azure CLI.

      Komputasi (Inti, Rangkaian Ketersediaan)

      az vm list-usage -l <azure-region> -o jsonc

      Jaringan (Jaringan Virtual, IP Publik Statis, IP Publik, Grup Keamanan Jaringan, Antarmuka Jaringan, Load Balancer, Tabel Rute)

      az network list-usages -l <azure-region> -o jsonc

      Penyimpanan (Akun Penyimpanan)

      az storage account show-usage

  • Batas pembatasan API Azure Resource Manager - Jika Anda memiliki lingkungan yang cukup besar (misalnya, > 400 VM dalam VNET), Anda mungkin mencapai batas pembatasan API default untuk operasi tulis (saat ini 1200 tulis/jam) di Azure Resource Manager. Sebelum memulai migrasi, Anda harus menaikkan tiket dukungan untuk meningkatkan batas langganan Anda.

  • Status Provisi VM dengan Waktu Habis - Jika ada VM yang memiliki status waktu provisi habis, perlu diselesaikan sebelum migrasi. Satu-satunya cara untuk melakukan ini adalah dengan memberikan waktu henti dengan membatalkan provisi/ memprovisi ulang VM (menghapusnya, menyimpan disk, dan membuat ulang VM).

  • Status VM RoleStateUnknown - Jika migrasi berhenti karena pesan kesalahan yang tidak diketahui status peran, periksa VM menggunakan portal dan pastikan komputer virtual berjalan. Kesalahan ini biasanya akan hilang sendiri (tidak perlu perbaikan) setelah beberapa menit dan seringkali merupakan kesalahan jenis sementara yang sering terlihat selama operasi Virtual Machine memulai, berhenti, dan menghidupkan ulang. Latihan yang direkomendasikan: coba migrasi lagi setelah beberapa menit.

  • Kluster Fabric tidak ada - Dalam beberapa kasus, VM tertentu tidak dapat dimigrasikan karena berbagai alasan aneh. Salah satu kasus yang diketahui ini adalah jika VM baru-baru ini dibuat (dalam seminggu terakhir atau lebih) dan kebetulan mendaratkan kluster Azure yang belum dilengkapi untuk beban kerja Azure Resource Manager. Anda akan mendapatkan kesalahan yang mengatakan kluster fabric tidak ada dan VM tidak dapat dimigrasikan. Anda bisa menunggu beberapa hari biasanya untuk menyelesaikan masalah khusus ini karena kluster akan segera mengaktifkan Azure Resource Manager. Namun, satu solusi langsung adalah dengan stop-deallocate VM, lalu lanjutkan dengan migrasi, dan mulai cadangkan VM di Azure Resource Manager setelah bermigrasi.

Perangkap yang harus dihindari

  • Jangan mengambil pintasan dan menghilangkan migrasi dry run validasi/siap/batalkan.
  • Sebagian besar, jika tidak semua, masalah potensial Anda akan muncul selama langkah-langkah validasi/siapkan/batalkan.

Migration

Pertimbangan teknis dan tradeoff

Sekarang Anda siap karena Anda telah bekerja melalui masalah yang diketahui dengan lingkungan Anda.

Untuk migrasi nyata, Anda mungkin ingin mempertimbangkan:

  1. Rencana dan jadwal jaringan virtual (unit migrasi terkecil) dengan prioritas yang meningkat. Lakukan jaringan virtual sederhana terlebih dahulu, dan lanjutkan dengan jaringan virtual yang lebih rumit.
  2. Sebagian besar pelanggan akan memiliki lingkungan non-produksi dan produksi. Jadwalkan produksi terakhir.
  3. (OPSIONAL) Jadwalkan waktu henti pemeliharaan dengan buffer yang lama jika muncul masalah tak terduga.
  4. Berkomunikasi dan selaraskan ide dengan tim dukungan Anda jika timbul masalah.

Pola keberhasilan

Panduan teknis dari bagian Uji Lab di atas harus dipertimbangkan dan dimitigasi sebelum migrasi nyata. Dengan pengujian yang memadai, migrasi sebenarnya non-aktivitas. Untuk lingkungan produksi, mungkin berguna untuk memiliki dukungan tambahan, seperti mitra Microsoft tepercaya atau layanan Microsoft Premier.

Perangkap yang harus dihindari

Pengujian tidak sepenuhnya dapat menyebabkan masalah dan keterlambatan dalam migrasi.

Di Luar Migrasi

Pertimbangan teknis dan tradeoff

Sekarang setelah Anda berada di Azure Resource Manager, maksimalkan platform. Baca gambaran umum Azure Resource Manager untuk mencari tahu tentang keuntungan tambahan.

Hal-hal yang perlu dipertimbangkan:

  • Bundling migrasi dengan kegiatan lain. Sebagian besar pelanggan memilih jendela pemeliharaan aplikasi. Jika demikian, Anda mungkin ingin menggunakan waktu henti ini untuk mengaktifkan kapabilitas Azure Resource Manager lainnya seperti enkripsi dan migrasi ke Disk Terkelola.
  • Mengunjungi kembali alasan teknis dan bisnis untuk Azure Resource Manager; aktifkan layanan tambahan yang hanya tersedia di Azure Resource Manager yang berlaku untuk lingkungan Anda.
  • Modernisasi lingkungan Anda dengan layanan PaaS.

Pola keberhasilan

Jadilah tujuan pada layanan yang sekarang ingin Anda aktifkan di Azure Resource Manager. Banyak pelanggan untuk menemukan hal-hal di bawah ini yang menarik untuk lingkungan Azure mereka:

Perangkap yang harus dihindari

Ingat mengapa Anda memulai perjalanan migrasi Klasik to Azure Resource Manager ini. Apa alasan bisnis pada awalnya? Apakah Anda memenuhi alasan bisnis?

Langkah berikutnya