Detail teknis migrasi ke Azure Cloud Services (dukungan diperpanjang)
Artikel ini membahas detail teknis mengenai alat migrasi yang berkaitan dengan Cloud Services (klasik).
Detail tentang fitur/skenario yang didukung untuk migrasi
Ekstensi dan migrasi plugin
- Semua ekstensi yang diaktifkan dan didukung dimigrasikan.
- Ekstensi yang dinonaktifkan tidak akan dimigrasikan.
- Plugin adalah konsep warisan dan harus dihapus sebelum migrasi. Mereka didukung untuk migrasi, tetapi setelah migrasi, jika ekstensi perlu diaktifkan, plugin perlu dihapus sebelum menginstal ekstensi. Batasan ini paling memengaruhi plugin dan ekstensi desktop jarak jauh.
Migrasi sertifikat
- Di Cloud Services (dukungan diperpanjang), sertifikat disimpan di Key Vault. Sebagai bagian dari migrasi, kami membuat Key Vault untuk pelanggan yang memiliki nama Cloud Service dan mentransfer semua sertifikat dari Azure Service Manager ke Key Vault.
- Referensi ke Key Vault ini ditentukan dalam template atau melewati PowerShell atau Azure CLI.
File Konfigurasi Layanan dan Definisi Layanan
- File .cscfg dan .csdef perlu diperbarui untuk Cloud Services (dukungan yang diperluas) dengan perubahan kecil.
- Nama sumber daya seperti jaringan virtual dan SKU komputer virtual (VM) berbeda. Lihat Terjemahan sumber daya dan penamaan konvensi pasca migrasi
- Pelanggan dapat mengambil penyebaran baru mereka melalui PowerShell dan REST API.
Cloud Service dan penyebaran
- Setiap penerapan Cloud Services (dukungan yang diperluas) adalah Cloud Services independen. Penyebaran tidak lagi dikelompokkan ke dalam layanan cloud menggunakan slot.
- Jika Anda memiliki dua slot di Cloud Service (klasik), Anda perlu menghapus satu slot (penahapan) dan menggunakan alat migrasi untuk memindahkan slot (produksi) lainnya ke Azure Resource Manager.
- Alamat IP publik pada penyebaran Cloud Services tetap sama setelah migrasi ke Azure Resource Manager dan diekspos sebagai sumber daya IP SKU Dasar (dinamis atau statis).
- Nama DNS dan domain (cloudapp.net) untuk layanan awan yang dimigrasikan tetap sama.
Migrasi jaringan virtual
- Jika penyebaran Cloud Services berada dalam jaringan virtual, maka selama migrasi semua Cloud Services dan sumber daya jaringan virtual terkait dimigrasikan bersama-sama.
- Setelah migrasi, jaringan virtual ditempatkan dalam grup sumber daya yang berbeda dari Cloud Service.
- Untuk jaringan virtual dengan beberapa Cloud Services, setiap Cloud Services dimigrasikan satu demi satu.
Migrasi penyebaran tidak dalam jaringan virtual
- Pada akhir 2018, Azure mulai secara otomatis membuat penyebaran baru (tanpa jaringan virtual yang ditentukan pelanggan) ke dalam jaringan virtual "default" yang dibuat platform. Jaringan virtual default ini disembunyikan dari pelanggan.
- Sebagai bagian dari migrasi, jaringan virtual default ini diekspos ke pelanggan sekali di Azure Resource Manager. Untuk mengelola atau memperbarui penyebaran di Azure Resource Manager, pelanggan perlu menambahkan informasi jaringan virtual ini di bagian Konfigurasi Jaringan dari file .cscfg.
- Jaringan virtual default, saat dimigrasikan ke Azure Resource Manager, ditempatkan dalam grup sumber daya yang sama dengan Cloud Service.
- Cloud Services yang dibuat sebelum waktu ini (sebelum akhir 2018) tidak akan berada di jaringan virtual apa pun dan tidak dapat dimigrasikan menggunakan alat ini. Pertimbangkan untuk melakukan penerapan ulang Cloud Services ini secara langsung di Azure Resource Manager. Pendekatan lain adalah bermigrasi melalui pembuatan penyebaran Penahapan baru dan VIPSwap Periksa detail selengkapnya di sini
- Untuk memeriksa apakah penyebaran memenuhi syarat untuk dimigrasikan, jalankan API validasi pada penyebaran. Hasil Validasi API berisi pesan kesalahan yang secara eksplisit menyebutkan apakah penyebaran ini memenuhi syarat untuk dimigrasikan.
Load Balancer
- Untuk Cloud Services menggunakan titik akhir publik, platform yang dibuat load balancer yang terkait dengan Cloud Services terekspos di dalam langganan pelanggan di Azure Resource Manager. Load balancer adalah sumber daya baca-saja, dan pembaruan hanya dibatasi melalui file Konfigurasi Layanan (.cscfg) dan Definisi Layanan (.csdef).
Key Vault
- Sebagai bagian dari migrasi, Azure secara otomatis membuat Key Vault baru dan memigrasikan semua sertifikat ke dalamnya. Alat ini tidak memungkinkan Anda untuk menggunakan Key Vault yang ada.
- Cloud Services (dukungan yang diperluas) memerlukan Key Vault yang terletak di wilayah dan langganan yang sama. Key Vault ini secara otomatis dibuat sebagai bagian dari migrasi.
Sumber daya dan fitur yang tidak tersedia untuk migrasi
Daftar ini berisi skenario teratas yang melibatkan kombinasi sumber daya, fitur, dan Cloud Services. Daftar ini tidak lengkap.
| Sumber daya | Langkah berikutnya/penyelesaian pekerjaan |
|---|---|
| Aturan Skala Otomatis | Migrasi berjalan tetapi aturan diabaikan. Buat ulang aturan setelah migrasi di Cloud Services (dukungan diperpanjang). |
| Peringatan | Migrasi dilalui tetapi pemberitahuan diabaikan. Buat ulang aturan setelah migrasi di Cloud Services (dukungan diperpanjang). |
| VPN Gateway | Hapus Gateway VPN sebelum memulai migrasi lalu buat ulang Gateway VPN setelah migrasi selesai. |
| Express Route Gateway (hanya dalam langganan yang sama dengan Jaringan Virtual) | Hapus Express Route Gateway sebelum memulai migrasi lalu buat ulang Gateway setelah migrasi selesai. |
| Kuota | Kuota tidak dimigrasikan. Minta kuota baru di Azure Resource Manager sebelum migrasi agar validasi berhasil. |
| Grup Afinitas | Tidak didukung. Hapus grup afinitas apa pun sebelum migrasi. |
| Jaringan virtual menggunakan peering jaringan virtual | Sebelum memigrasikan jaringan virtual yang dilakukan peering ke jaringan virtual lain, hapus peering, migrasikan jaringan virtual ke Resource Manager dan buat kembali peering. Proses ini dapat menyebabkan waktu henti tergantung pada arsitektur. |
| Jaringan virtual yang berisi lingkungan App Service | Tidak didukung |
| Jaringan virtual dengan Penyebaran Azure Batch | Tidak didukung |
| Jaringan virtual yang berisi layanan HDInsight | Tidak didukung. |
| Jaringan virtual yang berisi penyebaran Azure API Management | Tidak didukung. Untuk memigrasikan jaringan virtual, ubah jaringan virtual penyebaran API Management. Ini bukan operasi downtime. |
| Sirkuit Rute Ekspres Klasik | Tidak didukung. Sirkuit ini perlu dimigrasikan ke Azure Resource Manager sebelum memulai migrasi PaaS. Untuk mempelajari lebih lanjut, lihat Memindahkan sirkuit ExpressRoute dari model penyebaran Klasik ke Manajer Sumber Daya. |
| Access Control Berbasis Peran | Pasca migrasi, URI perubahan sumber daya dari Microsoft.ClassicCompute ke Microsoft.Compute kebijakan RBAC perlu diperbarui setelah migrasi. |
| Application Gateway | Tidak didukung. Hapus Application Gateway sebelum memulai migrasi lalu buat ulang Application Gateway setelah migrasi selesai ke Azure Resource Manager |
Konfigurasi/skenario migrasi yang tidak didukung
| Konfigurasi/Skenario | Langkah berikutnya/penyelesaian pekerjaan |
|---|---|
| Migrasi beberapa penyebaran lama tidak dalam jaringan virtual | Beberapa penyebaran Cloud Service yang tidak berada di jaringan virtual tidak didukung untuk migrasi. 1. Gunakan API validasi untuk memeriksa apakah deployment memenuhi syarat untuk melakukan migrasi. 2. Jika memenuhi syarat, penyebaran berpindah ke Azure Resource Manager di bawah jaringan virtual dengan awalan "DefaultRdfeVnet" |
| Migrasi penyebaran yang berisi penyebaran slot produksi dan penahapan menggunakan alamat IP dinamis | Migrasi dua slot Cloud Service memerlukan penghapusan slot penahapan. Setelah slot penahapan dihapus, migrasikan slot produksi sebagai Cloud Services independen (dukungan diperpanjang) di Azure Resource Manager. Kemudian terapkan ulang lingkungan penahapan sebagai Cloud Services baru (dukungan diperpanjang) dan membuatnya dapat ditukar dengan yang pertama. |
| Migrasi penyebaran yang berisi penyebaran slot produksi dan penahapan menggunakan alamat IP Terpesan | Tidak didukung. |
| Migrasi penyebaran produksi dan penahapan di jaringan virtual yang berbeda | Migrasi layanan cloud dua slot memerlukan penghapusan slot penahapan. Setelah slot penahapan dihapus, migrasikan slot produksi sebagai cloud service independen (dukungan diperpanjang) di Azure Resource Manager. Penyebaran Cloud Services (dukungan yang diperluas) baru kemudian dapat ditautkan ke penyebaran yang dimigrasikan dengan properti yang dapat ditukar diaktifkan. File penyebaran slot penahapan lama dapat digunakan kembali untuk membuat penyebaran baru yang dapat ditukar. |
| Migrasi Cloud Service kosong (Cloud Service tanpa penyebaran) | Tidak didukung. |
| Migrasi penyebaran yang berisi plugin desktop jarak jauh dan ekstensi desktop jarak jauh | Opsi 1: Hapus plugin desktop jarak jauh sebelum migrasi. Opsi ini memerlukan perubahan pada file penyebaran. Migrasi kemudian dilalui. Opsi 2: Hapus ekstensi desktop jarak jauh dan migrasi penyebaran. Pasca migrasi, hapus plugin dan instal ekstensi. Opsi ini memerlukan perubahan pada file penyebaran. Hapus plugin dan ekstensi sebelum migrasi. Plugin tidak disarankan untuk digunakan di Cloud Services (dukungan yang diperluas). |
| Jaringan virtual dengan penyebaran PaaS dan IaaS | Tidak Didukung Pindahkan penyebaran PaaS atau IaaS ke jaringan virtual yang berbeda. Ini menyebabkan waktu henti. |
| Penerapan Layanan Cloud menggunakan ukuran peran lama (seperti Small atau ExtraLarge). | Ukuran peran perlu diperbarui sebelum migrasi. Perbarui semua artefak penyebaran untuk mereferensikan ukuran peran modern baru ini. Untuk mengetahui informasi selengkapnya, lihat Ukuran VM yang tersedia |
| Migrasi Cloud Service ke jaringan virtual yang berbeda | Tidak didukung 1. Pindahkan penyebaran ke jaringan virtual klasik yang berbeda sebelum migrasi. Ini menyebabkan waktu henti. 2. Migrasikan jaringan virtual baru ke Azure Resource Manager. Atau 1. Memigrasikan jaringan virtual ke Azure Resource Manager 2. Pindahkan Cloud Service ke jaringan virtual baru. Ini menyebabkan waktu henti. |
| Cloud Service dalam jaringan virtual tetapi tidak memiliki subnet eksplisit yang ditetapkan | Tidak didukung. Mitigasi melibatkan pemindahan peran ke subnet, yang memerlukan proses menghidupkan ulang peran (downtime) |
Terjemahan sumber daya dan penamaan konvensi pasca migrasi
Sebagai bagian dari migrasi, nama sumber daya diubah, dan beberapa fitur Cloud Services diekspos sebagai sumber daya Azure Resource Manager. Tabel meringkas perubahan khusus untuk migrasi Cloud Services.
| Cloud Services (klasik) Nama sumber daya |
Cloud Services (klasik) Sintaks |
Cloud Services (dukungan yang diperluas) Nama sumber daya |
Cloud Services (dukungan yang diperluas) Sintaks |
|---|---|---|---|
| Layanan Cloud | cloudservicename |
Tidak terkait | Tidak terkait |
| Penyebaran (portal dibuat) Penyebaran (nonportal dibuat) |
deploymentname |
Cloud Services (dukungan yang diperluas) | cloudservicename |
| Virtual Network | vnetname Group resourcegroupname vnetname Tidak terkait |
Virtual Network (bukan portal yang dibuat) Virtual Network (portal dibuat) Virtual Networks (Default) |
vnetname group-resourcegroupname-vnetname VNet-cloudservicename |
| Tidak terkait | Tidak terkait | Key Vault | KV-cloudservicename |
| Tidak terkait | Tidak terkait | Grup Sumber Daya untuk Penerapan Cloud Service | cloudservicename-migrated |
| Tidak terkait | Tidak terkait | Grup Sumber Daya untuk Virtual Network | vnetname-migrated group-resourcegroupname-vnetname-migrated |
| Tidak terkait | Tidak terkait | IP Publik (Dinamis) | cloudservicenameContractContract |
| Nama IP Tercadangkan | reservedipname |
IP yang dicadangkan (nonportal dibuat) IP Tercadangkan (portal dibuat) |
reservedipname group-resourcegroupname-reservedipname |
| Tidak terkait | Tidak terkait | Load Balancer | LB-cloudservicename |
Masalah migrasi dan cara menanganinya.
Migrasi terjebak dalam operasi untuk waktu yang lama.
- Menerapkan, mempersiapkan, dan membatalkan dapat memakan waktu lama tergantung pada jumlah penyebaran. Operasi akan habis setelah 24 jam.
- Menerapkan, mempersiapkan, dan membatalkan operasi adalah idempoten. Sebagian besar masalah dapat diperbaiki dengan mencoba kembali. Mungkin ada kesalahan sementara, yang dapat hilang dalam beberapa menit, kami sarankan untuk mencoba kembali setelah celah. Jika bermigrasi menggunakan portal Azure dan operasi terjebak dalam "status sedang berlangsung", gunakan PowerShell untuk mencoba kembali operasi.
- Hubungi dukungan untuk membantu memigrasikan atau mengembalikan penyebaran dari backend.
Migrasi gagal dalam operasi.
- Jika validasi gagal, itu karena penyebaran atau jaringan virtual berisi skenario/fitur/sumber daya yang tidak didukung. Gunakan daftar skenario yang tidak didukung untuk menemukan pekerjaan di dokumen.
- Siapkan operasi terlebih dahulu melakukan validasi termasuk beberapa validasi mahal (tidak tercakup dalam validasi). Kegagalan persiapan bisa disebabkan oleh skenario yang tidak didukung. Temukan skenario dan penyelesaiannya dalam dokumen publik. Pembatalan perlu dipanggil untuk kembali ke keadaan semula dan membuka penyebaran untuk pembaruan dan menghapus operasi.
- Jika pembatalan gagal, coba lagi operasinya. Jika coba lagi gagal, hubungi dukungan.
- Jika penerapan gagal, coba lagi operasi. Jika coba lagi gagal, hubungi dukungan. Bahkan dalam kegagalan penerapan, seharusnya tidak ada masalah pesawat data untuk penyebaran Anda. Penyebaran Anda harus dapat menangani lalu lintas pelanggan tanpa masalah.
Portal disegarkan setelah Bersiap. Pengalaman dimulai ulang dan Penerapan atau Batalkan tidak terlihat lagi.
- Portal menyimpan informasi migrasi secara lokal dan oleh karena itu setelah refresh, itu akan dimulai dari fase validasi bahkan jika Layanan Cloud berada dalam fase persiapan.
- Anda dapat menggunakan portal untuk melewati validasi dan menyiapkan langkah-langkah lagi untuk mengekspos tombol Batalkan dan Terapkan. Ini tidak akan menyebabkan kegagalan.
- Pelanggan dapat menggunakan PowerShell atau REST API untuk membatalkan atau menerapkan.
Berapa banyak waktu yang dapat diambil operasi?
Validasi dirancang agar cepat. Persiapan terpanjang dan membutuhkan waktu tergantung pada jumlah total instans peran yang dimigrasikan. Membatalkan dan menerapkan juga dapat memakan waktu tetapi membutuhkan lebih sedikit waktu dibandingkan dengan persiapan. Semua operasi akan habis setelah 24 jam.
Langkah berikutnya
Untuk bantuan yang memigrasikan penyebaran Layanan Cloud (klasik) Anda ke Layanan Cloud (dukungan diperpanjang) lihat halaman arahan Dukungan dan pemecahan masalah kami.