Merelokasi Azure App Services ke wilayah lain

Artikel
07/27/2024

Artikel ini menjelaskan cara memindahkan sumber daya Azure App Service ke wilayah Azure yang berbeda.

Ada berbagai alasan mengapa Anda mungkin ingin memindahkan sumber daya Azure yang ada dari satu wilayah ke wilayah lain. Anda mungkin ingin:

Manfaatkan wilayah Azure baru.
Sebarkan fitur atau layanan yang hanya tersedia di wilayah tertentu.
Memenuhi persyaratan kebijakan dan tata kelola internal.
Selaras dengan merger dan akuisisi perusahaan
Memenuhi persyaratan perencanaan kapasitas.

Sumber daya Azure App Service dikhususkan untuk satu wilayah dan tidak dapat dipindahkan ke seluruh wilayah. Anda harus membuat salinan sumber daya App Service yang ada di wilayah target, lalu memindahkan konten Anda ke aplikasi baru. Jika aplikasi sumber Anda menggunakan domain kustom, Anda dapat memigrasikannya ke aplikasi baru di wilayah target setelah menyelesaikan relokasi.

Untuk mempermudah penyalinan aplikasi, Anda dapat mencadangkan dan memulihkan aplikasi App Service individual ke dalam paket App Service di wilayah lain.

Prasyarat

Pastikan bahwa aplikasi Azure App Service berada di wilayah Azure yang menjadi asal pemindahan.
Pastikan bahwa wilayah target mendukung Azure App Service dan layanan terkait, yang sumber dayanya ingin Anda pindahkan.
Validasi bahwa ada izin yang memadai untuk menyebarkan sumber daya App Service ke langganan dan wilayah target.
Validasi jika ada kebijakan Azure yang ditetapkan dengan pembatasan wilayah.
Pertimbangkan biaya pengoperasian apa pun, karena harga sumber daya Komputasi dapat bervariasi dari wilayah ke wilayah. Untuk memperkirakan kemungkinan biaya Anda, lihat Kalkulator harga.

Siapkan

Identifikasi semua sumber daya Azure App Service yang saat ini Anda gunakan. Contohnya:

Sumber daya tertentu, seperti sertifikat yang diimpor atau koneksi hibrida, berisi integrasi dengan layanan Azure lainnya. Untuk informasi tentang cara memindahkan sumber daya tersebut di seluruh wilayah, lihat dokumentasi untuk layanan masing-masing.

Paket

Bagian ini adalah daftar periksa perencanaan di area berikut:

Dependensi status, Penyimpanan, dan hilir
Sertifikat
Konfigurasi
Konektivitas VNet / Nama Kustom / DNS
Identitas
Titik Akhir Layanan

Dependensi status, penyimpanan, dan hilir

Tentukan apakah Aplikasi App Service Anda stateful atau stateless. Meskipun kami menyarankan agar App Service Apps tanpa status dan file pada %HOME%\site drive harus hanya yang diperlukan untuk menjalankan aplikasi yang disebarkan dengan file sementara apa pun, masih dimungkinkan untuk menyimpan status aplikasi runtime pada %HOME%\site drive virtual. Jika aplikasi Anda menulis status pada jalur penyimpanan bersama aplikasi, pastikan untuk merencanakan bagaimana Anda akan mengelola status tersebut selama pemindahan sumber daya.

Tip

Anda dapat menggunakan Kudu untuk, bersama dengan akses portal, untuk menyediakan API akses file (Virtual File System (VFS)) yang dapat membaca/menulis file di bawah %HOME%\site direktori. Untuk informasi selengkapnya, lihat Kudu Wiki.
Periksa penembolokan internal dan status dalam kode aplikasi.
Nonaktifkan pengaturan afinitas sesi. Jika memungkinkan, kami sarankan Anda menonaktifkan pengaturan afinitas sesi. Menonaktifkan afinitas sesi meningkatkan penyeimbangan beban untuk peluasan skala horizontal. Status internal apa pun dapat berdampak pada perencanaan pemotongan beban kerja - terutama jika waktu henti nol adalah persyaratan. Jika memungkinkan, mungkin bermanfaat untuk merefaktor status aplikasi apa pun untuk membuat aplikasi tanpa status sebagai persiapan untuk pemindahan.
Menganalisis string koneksi database. String koneksi database dapat ditemukan di Pengaturan Aplikasi. Namun, mereka mungkin juga dikodekan secara permanen atau dikelola dalam file konfigurasi yang dikirim dengan aplikasi. Analisis dan rencanakan migrasi/replikasi data sebagai bagian dari perencanaan tingkat yang lebih tinggi untuk memindahkan beban kerja. Untuk Aplikasi Kritis Chatty atau Latensi, aplikasi tidak berkinerja di wilayah target untuk menjangkau kembali ke sumber data di wilayah sumber.
Analisis penembolokan eksternal (misalnya Redis). Cache aplikasi harus disebarkan sedekat mungkin dengan aplikasi. Analisis bagaimana cache diisi, kebijakan kedaluwarsa/pengeluaran dan dampak apa pun yang mungkin dialami cache dingin pada pengguna pertama untuk mengakses beban kerja setelah cut-over.
Analisis dan rencana untuk dependensi API (atau aplikasi) Komunikasi lintas wilayah secara signifikan kurang berkinerja jika aplikasi di wilayah target mencapai kembali ke dependensi yang masih berada di wilayah sumber. Sebaiknya Anda merelokasi semua dependensi hilir sebagai bagian dari relokasi beban kerja. Namun, sumber daya *lokal* adalah pengecualian, khususnya sumber daya yang secara geografis lebih dekat ke wilayah target (seperti halnya skenario repatriasi).

Azure Container Registry dapat menjadi dependensi hilir (runtime) untuk App Service yang dikonfigurasi untuk dijalankan terhadap Gambar Kontainer Kustom. Lebih masuk akal bagi Container Registry untuk berada di wilayah yang sama dengan Aplikasi itu sendiri. Pertimbangkan untuk mengunggah gambar yang diperlukan ke ACR baru di wilayah dapatkan target. Jika tidak, pertimbangkan untuk menggunakan fitur replikasi geografis jika Anda berencana menyimpan gambar di wilayah sumber.
Menganalisis dan merencanakan layanan regional. Data Application Insights dan Log Analytics adalah layanan regional. Pertimbangkan pembuatan penyimpanan Application Insights dan Log Analytics baru di wilayah target. Untuk App Insights, sumber daya baru juga berdampak pada string koneksi yang harus diperbarui sebagai bagian dari perubahan App Configuration.

Sertifikat

Ada sejumlah jenis sertifikat yang perlu dipertimbangkan saat Anda merencanakan relokasi App Service Anda:

Sertifikat Terkelola Gratis dari App Service tidak dapat diekspor.
Sertifikat App Service melalui Azure Key Vault dapat diekspor menggunakan PS1/CLI.
Sertifikat yang Anda kelola di luar App Service.
Sertifikat App Service, yang tidak dikelola melalui Azure Key Vault, dapat diekspor.
Sumber daya sertifikat App Service dapat dipindahkan ke Grup Sumber Daya atau Langganan baru tetapi bukan lintas wilayah. Relokasi lintas wilayah tidak didukung oleh Sertifikat App Service.
Sertifikat Terkelola yang Anda kelola dan simpan di Azure Key Vault harus terlebih dahulu diekspor dari Key Vault sumber dan diimpor ulang ke Target Key Vault yang terkait dengan aplikasi target.

Beberapa poin lebih lanjut untuk dipertimbangkan:

Alamat yang Ditetapkan Aplikasi, di mana koneksi SSL aplikasi App Service terikat ke IP yang ditunjuk aplikasi tertentu, dapat digunakan untuk mengizinkan daftar panggilan dari jaringan pihak ketiga ke App Service. Misalnya, admin jaringan /TI mungkin ingin mengunci panggilan keluar dari jaringan lokal atau VNet untuk menggunakan alamat statis dan terkenal. Dengan demikian, jika fitur Alamat yang Ditetapkan Aplikasi sedang digunakan, aturan firewall upstream - seperti pihak internal, eksternal, atau ketiga - untuk penelepon ke dalam aplikasi harus diperiksa dan diberi tahu tentang alamat baru. Aturan firewall dapat berupa pihak internal, eksternal, atau ketiga, seperti mitra atau pelanggan terkenal.
Pertimbangkan Appliance Virtual Jaringan (NVA) upstream atau Proksi Terbalik. Konfigurasi NVA mungkin perlu berubah jika Anda menulis ulang header host atau/atau penghentian SSL.

Catatan

Lingkungan App Service adalah satu-satunya penawaran App Service yang memungkinkan panggilan hilir ke dependensi aplikasi hilir melalui SSL, di mana SSL mengandalkan SSL yang ditandatangani sendiri/PKI dengan dibangun dengan sertifikat CA Akar non-standar. Layanan multipenyewa tidak menyediakan akses bagi pelanggan untuk diunggah ke penyimpanan sertifikat tepercaya.

Lingkungan App Service saat ini tidak mengizinkan pembelian sertifikat SSL, hanya Bawa sertifikat Anda Sendiri. IP-SSL tidak dimungkinkan (dan tidak masuk akal), tetapi SNI adalah. Lingkungan App Service Internal tidak akan dikaitkan dengan domain publik dan oleh karena itu sertifikasi SSL yang digunakan harus disediakan oleh pelanggan dan oleh karena itu dapat diangkut, misalnya sertifikasi untuk penggunaan internal yang dihasilkan menggunakan PKI. App Service Environment v3 dalam mode eksternal berbagi fitur yang sama dengan App Service multipenyewa reguler.

Konfigurasi

Tinjau App Configuration untuk Pengaturan khusus lingkungan dan wilayah yang mungkin memerlukan modifikasi. Pastikan untuk memeriksa menyertakan konfigurasi file disk, yang mungkin atau mungkin tidak ditimpa dengan Pengaturan Aplikasi.
Pertimbangkan bahwa konfigurasi juga dapat dikelola dari dependensi database pusat (hilir) atau layanan seperti Azure Application Configuration.
Buat ulang referensi Key Vault App Service. Referensi Key Vault terkait dengan MSI unik yang ditetapkan ke sumber daya (yang memiliki akses data plane KV) dan Key Vault itu sendiri kemungkinan besar harus berada di wilayah sumber yang sama. Konten Az Key Vault tidak dapat diekspor di seluruh batas geografis Azure.

Konektivitas VNet / Nama Kustom / DNS

Lingkungan App Service adalah layanan penyewa tunggal yang disuntikkan VNet. Jaringan App Service Environment berbeda dari App Service multipenyewa, yang memerlukan satu atau kedua "Titik Akhir Privat" atau "Integrasi VNet Regional". Opsi lain yang mungkin sedang dimainkan termasuk integrasi VNet berbasis VPN P2S warisan dan Koneksi Hibrid (layanan Azure Relay).

Catatan

Jaringan ASEv3 disederhanakan - lalu lintas Manajemen Azure dan dependensi hilir lingkungan App Service sendiri tidak terlihat oleh Jaringan Virtual pelanggan, sangat menyederhanakan konfigurasi yang diperlukan di mana pelanggan menggunakan terowongan paksa untuk semua lalu lintas, atau mengirim subset lalu lintas keluar, melalui Network Virtual Appliance/Firewall.

Koneksi Hibrid (Azure Relay) bersifat regional. Jika Koneksi Hibrid digunakan dan meskipun Namespace Layanan Azure Relay dapat dipindahkan ke wilayah lain, akan lebih mudah untuk menyebarkan ulang Koneksi Hibrid (pastikan koneksi Hibrid disiapkan di wilayah baru pada penyebaran sumber daya target) dan menautkannya kembali ke Pengelola Sambungan Hibrid. Lokasi Pengelola Sambungan Hibrid harus dipertimbangkan dengan hati-hati.
Ikuti strategi untuk wilayah siaga yang hangat. Pastikan bahwa jaringan inti dan konektivitas, jaringan Hub, pengendali domain, DNS, VPN atau Rute Ekspres, dll., ada dan diuji sebelum relokasi sumber daya.
Validasi ACL dan konfigurasi jaringan hulu atau hilir apa pun. Misalnya, pertimbangkan layanan hilir eksternal yang hanya mengizinkan lalu lintas Aplikasi Anda. Relokasi ke Paket Aplikasi baru untuk App Service multipenyewa kemudian juga akan menjadi perubahan dalam alamat IP keluar.
Dalam kebanyakan kasus, yang terbaik adalah memastikan bahwa VNet wilayah target memiliki ruang alamat yang unik. Ruang alamat unik memfasilitasi konektivitas VNet jika diperlukan, misalnya, untuk mereplikasi data. Oleh karena itu, dalam skenario ini ada persyaratan implisit untuk berubah:
- DNS Privat
- Konfigurasi hard code atau eksternal apa pun yang mereferensikan sumber daya berdasarkan alamat IP (tanpa nama host)
- ACL jaringan termasuk Grup Keamanan Jaringan dan konfigurasi Firewall (pertimbangkan dampaknya ke NVA lokal di sini juga)
- Aturan perutean apa pun, Tabel Rute yang Ditentukan Pengguna
Selain itu, pastikan untuk memeriksa konfigurasi termasuk Rentang IP / Tag Layanan khusus wilayah jika meneruskan sumber daya penyebaran DevOps yang ada.
Lebih sedikit perubahan yang diperlukan untuk DNS privat yang disebarkan pelanggan yang dikonfigurasi untuk meneruskan ke Azure untuk domain Azure dan Zona Privat Azure DNS. Namun, karena Titik Akhir Privat didasarkan pada sumber daya FQDN dan ini sering juga merupakan nama sumber daya (yang diharapkan berbeda di wilayah target), ingatlah untuk memeriksa silang konfigurasi untuk memastikan bahwa FQDN yang direferensikan dalam konfigurasi diperbarui sesuai.
Buat ulang Titik Akhir Privat, jika digunakan, di wilayah target. Hal yang sama berlaku untuk integrasi VNet Regional.
DNS untuk Lingkungan App Service biasanya dikelola melalui solusi DNS kustom privat pelanggan (ada penimpaan pengaturan manual yang tersedia pada dasar per aplikasi). Lingkungan App Service menyediakan penyeimbang beban untuk masuk/keluar, sementara App Service itu sendiri memfilter pada header Host. Oleh karena itu, beberapa nama kustom dapat diarahkan ke titik akhir ingress Lingkungan App Service yang sama. Lingkungan App Service tidak memerlukan validasi domain.

Catatan

Titik akhir Kudu untuk Lingkungan App Service v3 hanya tersedia di {resourcename}.scm.{asename}.appserviceenvironment.net. Untuk informasi selengkapnya tentang App Service Environment v3 DNS dan Networking, dll, lihat Jaringan App Service Environment.

Untuk Lingkungan App Service, pelanggan memiliki perutean dan oleh karena itu sumber daya yang digunakan untuk cut-over. Di mana pun akses diaktifkan ke Lingkungan App Service secara eksternal - biasanya melalui Layer 7 NVA atau Reverse Proxy - Traffic Manager, atau Azure Front Door/Other L7 Global Load Balancing Service dapat digunakan.
Untuk versi multipenyewa publik layanan, nama {resourcename}.azurwwebsites.net default disediakan untuk titik akhir sarana data, bersama dengan nama default untuk titik akhir Kudu (SCM). Karena layanan menyediakan titik akhir publik secara default, pengikatan harus diverifikasi untuk membuktikan kepemilikan domain. Namun, setelah pengikatan diberlakukannya, verifikasi ulang tidak diperlukan, juga tidak diperlukan agar catatan DNS publik mengarah ke titik akhir App Service.
Jika Anda menggunakan domain kustom, ikat domain tersebut terlebih dahulu ke aplikasi target. Verifikasi dan aktifkan domain di aplikasi target.

Identitas

Buat ulang Identitas Layanan Terkelola App Service di wilayah target baru.
Tetapkan akses layanan hilir kredensial MSI baru (RBAC). Biasanya, Aplikasi ID Microsoft Entra yang dibuat secara otomatis (yang digunakan oleh EasyAuth) secara default ke nama sumber daya Aplikasi. Pertimbangan mungkin diperlukan di sini untuk membuat ulang sumber daya baru di wilayah target. Perwakilan Layanan yang ditentukan pengguna akan berguna - karena dapat diterapkan ke sumber dan target dengan izin akses tambahan ke sumber daya penyebaran target.
Rencanakan untuk memindahkan Penyedia Identitas (IDP) ke wilayah target. Meskipun Microsoft Entra ID adalah layanan global, beberapa solusi mengandalkan IDP lokal (atau hilir lokal).
Perbarui sumber daya apa pun ke App Service yang mungkin mengandalkan kredensial Kudu FTP.

Titik akhir layanan

Titik akhir layanan jaringan virtual untuk Azure App Service membatasi akses ke jaringan virtual tertentu. Titik akhir juga dapat membatasi akses ke daftar rentang alamat IPv4 (protokol internet versi 4). Setiap pengguna yang terhubung ke Azure Event Hubs dari luar sumber tersebut ditolak aksesnya. Jika Titik akhir layanan dikonfigurasi di wilayah sumber untuk sumber daya Azure Event Hubs, hal yang sama perlu dilakukan di target satu.

Agar rekreasi Azure App Service berhasil ke wilayah target, VNet dan Subnet harus dibuat sebelumnya. Jika pemindahan kedua sumber daya ini dilakukan dengan alat Azure Resource Mover, titik akhir layanan tidak akan dikonfigurasi secara otomatis. Oleh karena itu, mereka perlu dikonfigurasi secara manual, yang dapat dilakukan melalui portal Azure, Azure CLI, atau Azure PowerShell.

Pindah

Untuk merelokasi sumber daya App Service, Anda dapat menggunakan portal Azure atau Infrastruktur sebagai Kode (IaC).

Merelokasi menggunakan portal Azure

Keuntungan terbesar menggunakan portal Azure untuk direlokasi adalah kesederhanaannya. Aplikasi, paket, dan konten, serta banyak pengaturan dikloning ke sumber daya dan paket App Service baru.

Perlu diingat bahwa untuk tingkat Lingkungan App Service (Terisolasi), Anda perlu menyebarkan ulang seluruh Lingkungan App Service di wilayah lain terlebih dahulu, lalu Anda dapat mulai menyebarkan ulang paket individual di Lingkungan App Service baru di wilayah baru.

Untuk merelokasi sumber daya App Service Anda ke wilayah baru menggunakan portal Azure:

Membuat cadangan aplikasi sumber.
Membuat aplikasi di paket Azure App Service baru, di wilayah target.
Memulihkan cadangan di aplikasi target
Jika Anda menggunakan domain kustom, ikatkan terlebih dahulu ke aplikasi target dengan asuid. dan aktifkan domain di aplikasi target.
Konfigurasikan semua hal lain di aplikasi target Anda agar sama dengan aplikasi sumber dan periksa konfigurasi Anda.
Saat Anda siap untuk domain kustom untuk mengarahkan ke aplikasi target, petakan ulang nama domain.

Merelokasi menggunakan IaC

Gunakan IaC saat alur Integrasi Berkelanjutan dan Pengiriman Berkelanjutan/Penyebaran (CI/CD) yang ada, atau dapat dibuat. Dengan alur CI/CD di tempat, sumber daya App Service Anda dapat dibuat di wilayah target dengan cara tindakan penyebaran atau penyebaran zip Kudu.

Persyaratan SLA harus menentukan berapa banyak upaya tambahan yang diperlukan. Misalnya: Apakah ini penyebaran ulang dengan waktu henti terbatas, atau apakah diperlukan pemotongan hampir real time dengan waktu henti minimal hingga tanpa waktu henti?

Dimasukkannya layanan edge perutean lalu lintas global eksternal, seperti Traffic Manager, atau Azure Front Door membantu memfasilitasi cut-over untuk pengguna dan aplikasi eksternal.

Tip

Dimungkinkan untuk menggunakan Traffic Manager (ATM) saat gagal melalui App Services di belakang titik akhir privat. Meskipun titik akhir privat tidak dapat dijangkau oleh Pemeriksaan Traffic Manager - jika semua titik akhir terdegradasi, maka ATM memungkinkan perutean. Untuk informasi selengkapnya, lihat Mengontrol lalu lintas Azure App Service dengan Azure Traffic Manager.

Memvalidasi

Setelah relokasi selesai, uji dan validasi Azure App Service dengan panduan yang direkomendasikan:

Setelah Azure App Service dipindahkan ke wilayah target, jalankan uji asap dan integrasi. Anda dapat menguji atau menjalankan pengujian secara manual melalui skrip. Pastikan untuk memvalidasi bahwa semua konfigurasi dan sumber daya dependen ditautkan dengan benar dan semua data yang dikonfigurasi dapat diakses.
Validasi semua komponen dan integrasi Azure App Service.
Lakukan pengujian integrasi pada penyebaran wilayah target, termasuk semua pengujian regresi formal. Pengujian integrasi harus selaras dengan proses penyebaran dan pengujian Rhythm of Business yang biasa berlaku untuk beban kerja.
Dalam beberapa skenario, terutama di mana relokasi mencakup pembaruan, perubahan pada aplikasi atau Sumber Daya Azure, atau perubahan profil penggunaan, gunakan pengujian beban untuk memvalidasi bahwa beban kerja baru cocok untuk tujuan. Pengujian beban juga merupakan kesempatan untuk memvalidasi operasi dan memantau cakupan. Misalnya, gunakan pengujian beban untuk memvalidasi bahwa infrastruktur dan log aplikasi yang diperlukan dihasilkan dengan benar. Pengujian beban harus diukur terhadap garis besar performa beban kerja yang ditetapkan.

Tip

Relokasi App Service juga merupakan kesempatan untuk menilai kembali ketersediaan dan perencanaan Pemulihan Bencana. App Service dan App Service Environment (App Service Environment v3) mendukung zona ketersediaan dan disarankan untuk mengonfigurasi dengan konfigurasi zona ketersediaan. Perlu diingat prasyarat untuk penyebaran, harga, dan batasan dan faktori ini ke dalam perencanaan pemindahan sumber daya. Untuk informasi selengkapnya tentang zona ketersediaan dan App Service, lihat Keandalan di Azure App Service.

Penghapusan

Hapus paket aplikasi sumber dan Azure App Service. Paket Azure App Service di tingkat non-gratis dikenakan biaya, bahkan jika tidak ada aplikasi yang berjalan di dalamnya.

Langkah berikutnya

Kloning Aplikasi Azure App Service Menggunakan PowerShell

Bagikan melalui