Keandalan di Azure App Service
Artikel ini menjelaskan dukungan keandalan di Azure App Service, dan mencakup ketahanan intra-regional dengan zona ketersediaan dan pemulihan bencana lintas wilayah dan kelangsungan bisnis. Untuk gambaran umum yang lebih rinci tentang prinsip keandalan di Azure, lihat Keandalan Azure.
Azure App Service adalah layanan berbasis HTTP untuk menghosting aplikasi web, REST API, dan back end seluler; dan menambahkan kekuatan Microsoft Azure ke aplikasi Anda, seperti:
- Keamanan
- Penyeimbangan Beban
- Penskalaan otomatis
- Manajemen otomatis
Untuk menjelajahi bagaimana Azure App Service dapat meningkatkan keandalan dan ketahanan beban kerja aplikasi Anda, lihat Mengapa menggunakan App Service?
Dukungan zona ketersediaan
Zona ketersediaan Azure adalah setidaknya tiga grup pusat data yang terpisah secara fisik dalam setiap wilayah Azure. Pusat data dalam setiap zona dilengkapi dengan infrastruktur daya, pendinginan, dan jaringan independen. Dalam kasus kegagalan zona lokal, zona ketersediaan dirancang sehingga jika satu zona terpengaruh, layanan regional, kapasitas, dan ketersediaan tinggi didukung oleh dua zona yang tersisa.
Kegagalan dapat berkisar dari kegagalan perangkat lunak dan perangkat keras hingga peristiwa seperti gempa bumi, banjir, dan kebakaran. Toleransi terhadap kegagalan dicapai dengan redundansi dan isolasi logis layanan Azure. Untuk informasi selengkapnya tentang zona ketersediaan di Azure, lihat Wilayah dan zona ketersediaan.
Layanan berkemampuan zona ketersediaan Azure dirancang untuk memberikan tingkat keandalan dan fleksibilitas yang tepat. Mereka dapat dikonfigurasi dalam dua cara. Mereka dapat berupa zona redundan,dengan replikasi otomatis di seluruh zona, atau zonal, dengan instans yang disematkan ke zona tertentu. Anda juga dapat menggabungkan pendekatan ini. Untuk informasi selengkapnya tentang arsitektur zonal vs. zona-redundan, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.
Azure App Service dapat disebarkan di seluruh zona ketersediaan (AZ) untuk membantu Anda mencapai ketahanan dan keandalan untuk beban kerja penting bisnis Anda. Arsitektur ini juga dikenal sebagai redundansi zona.
Saat Anda mengonfigurasi App Service sebagai zona redundan, platform secara otomatis menyebarkan instans paket Azure App Service di tiga zona di wilayah yang dipilih.
Instans yang menyebar dengan penyebaran zona-redundan ditentukan di dalam aturan berikut, bahkan saat aplikasi menskalakan masuk dan keluar:
- Jumlah instans Paket App Service minimum adalah tiga.
- Jika Anda menentukan kapasitas yang lebih besar dari tiga, dan jumlah instans habis dibagi tiga, instans akan tersebar merata.
- Setiap instans dihitung di luar 3*N tersebar di satu atau dua zona yang tersisa.
Dukungan zona ketersediaan adalah properti dari paket App Service. Paket App Service dapat dibuat pada lingkungan multi-penyewa terkelola atau lingkungan khusus menggunakan App Service Environment v3. Untuk Mempelajari selengkapnya mengenai App Service Environment v3, lihat Ringkasan App Service Environment v3.
Untuk App Services yang tidak dikonfigurasi menjadi zona redundan, instans VM bukan tangguh zona dan dapat mengalami waktu henti selama pemadaman di zona mana pun di wilayah tersebut.
Untuk informasi tentang arsitektur penyebaran perusahaan, lihat Penyebaran perusahaan ketersediaan tinggi menggunakan Lingkungan App Service.
Prasyarat
Persyaratan/batasan saat ini untuk mengaktifkan zona ketersediaan adalah:
Aplikasi Windows dan Linux didukung.
Zona ketersediaan hanya didukung pada jejak App Service yang lebih baru. Bahkan jika Anda menggunakan salah satu wilayah yang didukung, Anda akan menerima kesalahan jika zona ketersediaan tidak didukung untuk grup sumber daya Anda. Untuk memastikan beban kerja Anda mendarat di stempel yang mendukung zona ketersediaan, Anda mungkin perlu membuat grup sumber daya baru, paket App Service, dan App Service.
Paket App Services Anda harus menjadi salah satu paket berikut yang mendukung zona ketersediaan:
- Di lingkungan multi-penyewa menggunakan paket App Service Premium v2 atau Premium v3.
- Di lingkungan khusus menggunakan App Service Environment v3, yang digunakan dengan paket App Service v2 Terisolasi.
Untuk lingkungan khusus, Lingkungan App Service Anda harus v3.
Penting
Lingkungan App Service v2 dan v1 akan dihentikan pada 31 Agustus 2024. App Service Environment v3 lebih mudah digunakan dan dijalankan pada infrastruktur yang lebih kuat. Untuk mempelajari selengkapnya tentang Lingkungan App Service v3, lihat Ringkasan Lingkungan App Service. Jika saat ini Anda menggunakan App Service Environment v2 atau v1 dan ingin meningkatkan ke v3, ikuti langkah-langkah dalam artikel ini untuk bermigrasi ke versi baru.
Jumlah instans minimum tiga zona diberlakukan. Platform ini akan menerapkan jumlah minimum ini di belakang layar jika Anda menentukan jumlah instans kurang dari tiga.
Zona ketersediaan hanya dapat ditentukan saat membuat paket App Service baru . Paket App Service yang sudah ada sebelumnya tidak dapat dikonversi untuk menggunakan zona ketersediaan.
Wilayah berikut mendukung Azure App Services yang berjalan di lingkungan multi-penyewa:
- Australia Timur
- Brasil Selatan
- Kanada Tengah
- India Tengah
- US Tengah
- Asia Timur
- AS Timur
- AS Timur 2
- Prancis Tengah
- Jerman Barat Tengah
- Israel Tengah
- Italia Utara
- Jepang Timur
- Korea Tengah
- Meksiko Tengah
- Eropa Utara
- Norwegia Timur
- Polandia Tengah
- Qatar Tengah
- Afrika Selatan Utara
- US Tengah Selatan
- Asia Tenggara
- Spanyol Tengah
- Swedia Tengah
- Swiss Utara
- Arab Saudi Utara
- UK Selatan
- Eropa Barat
- US Barat 2
- AS Barat 3
- Microsoft Azure dioperasikan oleh 21Vianet - Tiongkok Utara 3
- Azure Government - US Gov Virginia
Untuk melihat wilayah mana yang mendukung zona ketersediaan untuk App Service Environment v3, lihat Wilayah.
Membuat sumber daya dengan zona ketersediaan diaktifkan
Untuk menyebarkan App Service zona-redundan multi-penyewa
Untuk mengaktifkan zona ketersediaan menggunakan Azure CLI, sertakan --zone-redundant parameter saat Anda membuat paket App Service. Anda juga dapat menyertakan parameter --number-of-workers untuk menentukan kapasitas. Jika Anda tidak menentukan kapasitas, platform secara default menjadi tiga. Kapasitas harus ditetapkan berdasarkan kebutuhan beban kerja, tetapi tidak kurang dari tiga. Aturan praktis yang baik untuk memilih kapasitas adalah memastikan waktu yang cukup untuk aplikasi sehingga kehilangan satu zona instans meninggalkan kapasitas yang cukup untuk menghandel beban yang diharapkan.
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
Tip
Untuk menentukan kapasitas instans, Anda dapat menggunakan perhitungan berikut:
Karena platform menyebarkan VM di tiga zona dan Anda harus memperhitungkan setidaknya kegagalan satu zona, kalikan jumlah instans beban kerja puncak dengan faktor zona/(zona-1), atau 3/2. Misalnya, jika beban kerja puncak umum Anda memerlukan empat instans, Anda harus menyediakan enam instans: (2/3 * 6 instans) = 4 instans.
Menyebarkan App Service zona-redundan menggunakan lingkungan khusus
Untuk mempelajari cara membuat Lingkungan App Service v3 pada paket V2 Terisolasi, lihat Membuat Lingkungan App Service.
Pemecahan Masalah
| Pesan kesalahan | Deskripsi | Rekomendasi |
|---|---|---|
| Redundansi zona tidak tersedia untuk grup sumber daya 'RG-NAME'. Sebarkan paket layanan aplikasi 'ASP-NAME' ke grup sumber daya baru. | Zona ketersediaan hanya didukung pada jejak App Service yang lebih baru. Bahkan jika Anda menggunakan salah satu wilayah yang didukung, Anda akan menerima kesalahan jika zona ketersediaan tidak didukung untuk grup sumber daya Anda. | Untuk memastikan beban kerja Anda mendarat di stempel yang mendukung zona ketersediaan, buat grup sumber daya baru, paket App Service, dan App Service. |
Toleransi kegagalan
Untuk mempersiapkan kegagalan zona ketersediaan, Anda harus menyediakan kapasitas layanan secara berlebihan untuk memastikan bahwa solusi dapat mentolerir kehilangan kapasitas 1/3 dan terus berfungsi tanpa performa yang terdegradasi selama pemadaman di seluruh zona. Karena platform menyebarkan VM di tiga zona dan Anda harus memperhitungkan setidaknya kegagalan satu zona, kalikan jumlah instans beban kerja puncak dengan faktor zona/(zona-1), atau 3/2. Misalnya, jika beban kerja puncak umum Anda memerlukan empat instans, Anda harus menyediakan enam instans: (2/3 * 6 instans) = 4 instans.
Pengalaman zona tidak berfungsi
Lalu lintas dirutekan ke semua instans App Service yang tersedia. Jika zona tidak berfungsi, platform App Service akan mendeteksi instans yang hilang dan secara otomatis berusaha menemukan instans pengganti baru dan menyebarkan lalu lintas sesuai kebutuhan. Jika Anda telah mengonfigurasi penskalaan otomatis, dan jika memutuskan lebih banyak instans diperlukan, penskalaan otomatis juga akan mengeluarkan permintaan ke App Service untuk menambahkan lebih banyak instans. Harap diingat bahwa perilaku penskalaan otomatis tidak bergantung pada perilaku platform App Service dan spesifikasi jumlah instans penskalaan otomatis Anda tidak harus kelipatan tiga.
Catatan
Tidak ada jaminan bahwa permintaan untuk instans tambahan dalam skenario zona tidak berfungsi akan berhasil. Pengisian kembali instans yang hilang terjadi berdasarkan upaya terbaik. Solusi yang direkomendasikan adalah membuat dan mengonfigurasi paket App Service Anda untuk memperhitungkan kehilangan zona seperti yang dijelaskan di bagian berikutnya.
Aplikasi yang disebarkan dalam paket App Service yang mengaktifkan zona ketersediaan akan terus berjalan dan melayani lalu lintas meskipun zona lain di wilayah yang sama mengalami pemadaman. Ada kemungkinan bahwa perilaku non-runtime bahasa umum, termasuk; penskalaan paket App Service, pembuatan aplikasi, konfigurasi aplikasi, dan penerbitan aplikasi mungkin masih terpengaruh dari pemadaman di Zona Ketersediaan lainnya. Redundansi zona untuk paket App Service hanya memastikan waktu aktif lanjutan untuk aplikasi yang disebar.
Ketika platform App Service mengalokasikan instans ke paket App Service zona redundan, ini akan menggunakan penyeimbangan zona upaya terbaik yang ditawarkan oleh Virtual Machine Scale Sets yang mendasarinya. Paket App Service akan "seimbang" jika setiap zona memiliki jumlah VM yang sama, atau +/- satu VM di semua zona lain yang digunakan oleh paket App Service.
Migrasi zona ketersediaan
Anda tidak dapat memigrasikan instans App Service atau sumber daya lingkungan yang ada dari dukungan zona non-ketersediaan ke dukungan zona ketersediaan. Untuk mendapatkan dukungan untuk zona ketersediaan, Anda harus membuat sumber daya dengan zona ketersediaan diaktifkan.
Harga
Untuk lingkungan multi-penyewa yang menggunakan paket App Service Premium v2 atau Premium v3, tidak ada biaya tambahan yang terkait dengan mengaktifkan zona ketersediaan selama Anda memiliki tiga instans atau lebih dalam paket App Service Anda. Anda akan dikenakan biaya berdasarkan SKU paket App Service Anda, kapasitas yang Anda tentukan, dan setiap instans yang Anda skalakan berdasarkan kriteria penskalaan otomatis Anda. Jika Anda mengaktifkan zona ketersediaan, tetapi menetapkan kapasitas kurang dari tiga, platform akan memberlakukan jumlah instans minimum, yaitu tiga, dan mengenakan biaya kepada Anda untuk tiga instans tersebut. App Service Environment v3 memiliki model harga yang berbeda untuk zona ketersediaan. Untuk informasi harga untuk Lingkungan App Service v3, lihat Harga.
Pemulihan bencana lintas wilayah dan kelangsungan bisnis
Pemulihan bencana (DR) adalah tentang pemulihan dari peristiwa berdampak tinggi, seperti bencana alam atau penyebaran gagal yang mengakibatkan waktu henti dan kehilangan data. Terlepas dari penyebabnya, obat terbaik untuk bencana adalah rencana DR yang terdefinisi dan teruji dengan baik dan desain aplikasi yang secara aktif mendukung DR. Sebelum Anda mulai berpikir tentang membuat rencana pemulihan bencana Anda, lihat Rekomendasi untuk merancang strategi pemulihan bencana.
Ketika datang ke DR, Microsoft menggunakan model tanggung jawab bersama. Dalam model tanggung jawab bersama, Microsoft memastikan bahwa infrastruktur dasar dan layanan platform tersedia. Pada saat yang sama, banyak layanan Azure tidak secara otomatis mereplikasi data atau mundur dari wilayah yang gagal untuk mereplikasi silang ke wilayah lain yang diaktifkan. Untuk layanan tersebut, Anda bertanggung jawab untuk menyiapkan rencana pemulihan bencana yang berfungsi untuk beban kerja Anda. Sebagian besar layanan yang berjalan pada penawaran platform as a service (PaaS) Azure menyediakan fitur dan panduan untuk mendukung DR dan Anda dapat menggunakan fitur khusus layanan untuk mendukung pemulihan cepat untuk membantu mengembangkan rencana DR Anda.
Bagian ini mencakup beberapa strategi umum untuk aplikasi web yang disebarkan ke App Service.
Saat Anda membuat aplikasi web di App Service dan memilih wilayah Azure selama pembuatan sumber daya, aplikasi ini adalah aplikasi satu wilayah. Ketika wilayah menjadi tidak tersedia selama bencana, aplikasi Anda juga menjadi tidak tersedia. Jika Anda membuat penyebaran yang identik di wilayah Azure sekunder menggunakan arsitektur geografi multi-wilayah, aplikasi Anda menjadi kurang rentan terhadap bencana satu wilayah, yang menjamin kelangsungan bisnis. Setiap replikasi data di seluruh wilayah memungkinkan Anda memulihkan status aplikasi terakhir Anda.
Untuk IT, rencana kelangsungan bisnis sebagian besar didorong oleh Recovery Time Objective (RTO) dan Recovery Point Objective (RPO). Untuk informasi selengkapnya tentang RTO dan RPO, lihat Tujuan pemulihan.
Biasanya, mempertahankan SLA di sekitar RTO tidak praktis untuk bencana regional, dan Anda biasanya akan merancang strategi pemulihan bencana Anda di sekitar RPO saja (yaitu fokus pada pemulihan data dan bukan meminimalkan gangguan). Namun, dengan Azure, ini tidak hanya praktis tetapi bahkan dapat mudah untuk menyebarkan App Service untuk geo-failover otomatis. Ini memungkinkan Anda untuk membuktikan bencana aplikasi Anda lebih lanjut dengan mengurus RTO dan RPO.
Bergantung pada metrik RTO dan RPO yang Anda inginkan, tiga arsitektur pemulihan bencana biasanya digunakan untuk multipenyewa App Service dan Lingkungan App Service. Setiap arsitektur dijelaskan dalam tabel berikut:
| Metrik | Aktif-Aktif | Aktif-Pasif | Pasif/Dingin |
|---|---|---|---|
| RTO | Real time atau detik | Menit | Jam |
| RPO | Real time atau detik | Menit | Jam |
| Biaya | $$$ | $$ | $ |
| Skenario | Aplikasi misi penting | Aplikasi berprioritas tinggi | Aplikasi berprioritas rendah |
| Kemampuan untuk melayani lalu lintas pengguna multi-wilayah | Ya | Ya/mungkin | No |
| Penyebaran kode | Alur CI/CD lebih disukai | Alur CI/CD lebih disukai | Pencadangan dan pemulihan |
| Pembuatan sumber daya App Service baru selama waktu henti | Tidak diperlukan | Tidak diperlukan | Diperlukan |
Catatan
Aplikasi Anda kemungkinan besar bergantung pada layanan data lain di Azure, seperti akun Azure SQL Database dan Azure Storage. Disarankan agar Anda mengembangkan strategi pemulihan bencana untuk masing-masing Layanan Azure dependen ini juga. Untuk SQL Database, lihat Replikasi geografis aktif untuk Azure SQL Database. Untuk Azure Storage, lihat Redundansi Azure Storage.
Pemulihan bencana dalam geografi multi-wilayah
Ada beberapa cara untuk mereplikasi konten dan konfigurasi aplikasi web Anda di seluruh wilayah Azure dalam arsitektur aktif-aktif atau pasif aktif, seperti menggunakan pencadangan dan pemulihan layanan Aplikasi. Namun, pencadangan dan pemulihan membuat rekam jepret titik waktu dan akhirnya menyebabkan tantangan penerapan versi aplikasi web di seluruh wilayah. Lihat tabel berikut ini untuk perbandingan antara panduan pemulihan dan balik vs. panduan pemulihan diaster:
Pencadangan dan pemulihan vs. pemulihan bencana
| Platform | Panduan pencadangan dan pemulihan | Panduan pemulihan bencana |
|---|---|---|
| Aplikasi web App Service (Tingkat harga Gratis dan Bersama) |
Jika Anda memiliki aplikasi web yang disebarkan ke tingkat Gratis atau Bersama dan memerlukan akses untuk mencadangkan dan memulihkan kemampuan untuk aplikasi web ini, tingkatkan ke tingkat Dasar atau yang lebih tinggi. | Bawa sumber daya App Service kembali online di wilayah Azure yang berbeda selama bencana regional. Mulai 31 Maret 2025, aplikasi App Service tidak akan ditempatkan dalam mode pemulihan bencana selama bencana di wilayah Azure seperti yang dijelaskan dalam artikel pemulihan dari kegagalan di seluruh wilayah. Kami menyarankan agar Anda menerapkan teknik pemulihan bencana yang umum digunakan untuk mencegah waktu henti dan kehilangan data selama bencana regional. |
| Aplikasi web App Service (Tingkat harga Dasar, Standar, dan Premium) |
Di Azure App Service, Anda dapat membuat cadangan kustom sesuai permintaan atau menggunakan pencadangan otomatis. Anda dapat memulihkan cadangan dengan menimpa aplikasi yang ada atau dengan memulihkan ke aplikasi atau slot baru. Lihat Mencadangkan dan memulihkan aplikasi Anda di Azure App Service untuk informasi selengkapnya. |
Panduan saat ini mengenai cara membawa sumber daya App Service kembali online di wilayah Azure yang berbeda selama bencana regional tersedia di Pulihkan dari kegagalan di seluruh wilayah - Azure App Service. Mulai 31 Maret 2025, aplikasi web Azure App Service tidak akan lagi ditempatkan dalam mode pemulihan bencana selama bencana di wilayah Azure seperti yang dijelaskan dalam artikel pemulihan dari kegagalan di seluruh wilayah. Kami mendorong Anda untuk menerapkan teknik pemulihan bencana yang umum digunakan untuk mencegah hilangnya fungsionalitas atau data untuk aplikasi web Anda jika ada bencana regional. |
| Lingkungan App Service (V2 dan V3) | Di Lingkungan Azure App Service, Anda dapat membuat cadangan kustom sesuai permintaan atau menggunakan pencadangan otomatis. Pencadangan otomatis dapat dipulihkan ke aplikasi target dalam Lingkungan App Service yang sama, bukan di Lingkungan App Service lain. Cadangan kustom dapat dipulihkan ke aplikasi target di Lingkungan App Service lain (seperti dari Lingkungan App Service V2 ke Lingkungan App Service V3). Cadangan dapat dipulihkan ke aplikasi target dari platform OS yang sama dengan aplikasi sumber. Lihat Mencadangkan dan memulihkan aplikasi Anda di Azure App Service untuk detail selengkapnya. |
Kami mendorong Anda untuk menerapkan panduan pemulihan bencana untuk aplikasi web yang disebarkan ke Lingkungan App Service menggunakan teknik pemulihan bencana yang umum digunakan. |
| Azure Functions: Paket khusus |
Saat Anda menjalankan aplikasi fungsi dalam paket Khusus (App Service), konten aplikasi fungsi yang diperlukan dipertahankan menggunakan penyimpanan bawaan. Dalam paket Khusus, Anda dapat membuat cadangan kustom sesuai permintaan atau menggunakan cadangan otomatis. Anda dapat memulihkan cadangan dengan menimpa aplikasi yang ada atau dengan memulihkan ke aplikasi atau slot baru. Untuk informasi selengkapnya, lihat Mencadangkan dan memulihkan aplikasi Anda di Azure App Service. Azure Files tidak digunakan oleh paket Khusus, tetapi jika Anda telah salah mengonfigurasi aplikasi Anda dengan koneksi Azure Files, pencadangan tidak didukung. |
Panduan saat ini mengenai cara membawa sumber daya aplikasi fungsi dalam paket Khusus kembali online di wilayah Azure yang berbeda selama bencana regional tersedia di Pulihkan dari kegagalan di seluruh wilayah - Azure App Service. Mulai 31 Maret 2025, aplikasi App Service tidak akan ditempatkan dalam mode pemulihan bencana selama bencana di wilayah Azure seperti yang dijelaskan dalam artikel pemulihan dari kegagalan di seluruh wilayah. Sebagai gantinya , Anda harus merencanakan keandalan di aplikasi fungsi Anda. Anda juga dapat merujuk ke teknik pemulihan bencana yang umum digunakan untuk aplikasi fungsi dalam paket Khusus. |
| Azure Functions: Konsumsi Flex, Paket Konsumsi, dan Premium |
Aplikasi fungsi yang berjalan dalam paket Konsumsi Flex, dalam paket Konsumsi, atau dalam paket Premium tidak dapat menggunakan fungsionalitas pencadangan kustom atau otomatis di App Service. Dalam paket skala dinamis ini, konten aplikasi fungsi dipertahankan di Azure Storage. Gunakan opsi redundansi Azure Storage untuk memastikan akun penyimpanan Anda memenuhi target ketersediaan dan durabilitasnya selama pemadaman. Anda juga dapat mengunduh proyek aplikasi fungsi yang ada sebagai file .zip dari portal Azure. |
Kami sangat mendorong Anda untuk merencanakan keandalan di aplikasi fungsi Anda. |
Untuk menghindari batasan metode pencadangan dan pemulihan, konfigurasikan alur CI/CD Anda untuk menyebarkan kode ke kedua wilayah Azure. Pertimbangkan untuk menggunakan Azure Pipelines atau GitHub Actions. Untuk informasi selengkapnya, lihat Penyebaran berkelanjutan ke Azure App Service.
Deteksi, pemberitahuan, dan manajemen pemadaman
Disarankan agar Anda menyiapkan pemantauan dan pemberitahuan untuk aplikasi web Anda untuk pemberitahuan tepat waktu selama bencana. Untuk informasi selengkapnya, lihat Pengujian ketersediaan Application Insights.
Untuk mengelola sumber daya aplikasi Anda di Azure, gunakan mekanisme infrastructure-as-Code (IaC). Dalam penyebaran yang kompleks di beberapa wilayah, untuk mengelola wilayah secara independen dan untuk menjaga konfigurasi tetap sinkron di seluruh wilayah dengan cara yang dapat diandalkan memerlukan proses yang dapat diprediksi, dapat diuji, dan dapat diulang. Pertimbangkan alat IaC seperti templat Azure Resource Manager atau Terraform.
Menyiapkan pemulihan bencana dan deteksi pemadaman
Untuk mempersiapkan pemulihan bencana dalam geografi multi-wilayah, Anda dapat menggunakan arsitektur aktif-aktif atau pasif aktif.
Arsitektur Aktif-Aktif
Dalam arsitektur pemulihan bencana aktif-aktif, aplikasi web yang identik disebarkan di dua wilayah terpisah dan Azure Front door digunakan untuk merutekan lalu lintas ke kedua wilayah aktif.
Dengan contoh arsitektur ini:
- Aplikasi App Service yang identik disebarkan di dua wilayah terpisah, termasuk tingkat harga dan jumlah instans.
- Lalu lintas publik langsung ke aplikasi App Service diblokir.
- Azure Front Door digunakan untuk merutekan lalu lintas ke kedua wilayah aktif.
- Selama bencana, salah satu wilayah menjadi offline, dan Azure Front Door merutekan lalu lintas secara eksklusif ke wilayah yang tetap online. RTO selama geo-failover seperti itu mendekati nol.
- File aplikasi harus disebarkan ke kedua aplikasi web dengan solusi CI/CD. Ini memastikan bahwa RPO praktis nol.
- Jika aplikasi Anda secara aktif memodifikasi sistem file, cara terbaik untuk meminimalkan RPO adalah dengan hanya menulis ke berbagi Azure Storage yang dipasang alih-alih menulis langsung ke berbagi konten /beranda aplikasi web. Kemudian, gunakan fitur redundansi Azure Storage (GZRS atau GRS) untuk berbagi yang dipasang, yang memiliki RPO sekitar 15 menit.
Langkah-langkah untuk membuat arsitektur aktif-aktif untuk aplikasi web Anda di App Service diringkas sebagai berikut:
Buat dua paket App Service di dua wilayah Azure yang berbeda. Konfigurasikan dua paket App Service secara identik.
Buat dua instans aplikasi web Anda, dengan satu di setiap paket App Service.
Buat profil Azure Front Door dengan:
- Titik akhir.
- Dua grup asal, masing-masing dengan prioritas 1. Prioritas yang sama memberi tahu Azure Front Door untuk merutekan lalu lintas ke kedua wilayah secara merata (sehingga aktif-aktif).
- Sebuah rute.
Batasi lalu lintas jaringan ke aplikasi web hanya dari instans Azure Front Door.
Menyiapkan dan mengonfigurasi semua layanan Azure back-end lainnya, seperti database, akun penyimpanan, dan penyedia autentikasi.
Sebarkan kode ke kedua aplikasi web dengan penyebaran berkelanjutan.
Tutorial: Membuat aplikasi multi-wilayah yang sangat tersedia di Azure App Service menunjukkan cara menyiapkan arsitektur pasif aktif. Langkah yang sama dengan perubahan minimal (mengatur prioritas ke "1" untuk kedua asal dalam grup asal di Azure Front Door) memberi Anda arsitektur aktif-aktif.
Arsitektur pasif aktif
Dalam pendekatan pemulihan bencana ini, aplikasi web yang identik disebarkan di dua wilayah terpisah dan Azure Front door digunakan untuk merutekan lalu lintas ke satu wilayah saja ( wilayah aktif ).
Dengan contoh arsitektur ini:
Aplikasi App Service yang identik disebarkan di dua wilayah terpisah.
Lalu lintas publik langsung ke aplikasi App Service diblokir.
Azure Front Door digunakan untuk merutekan lalu lintas ke wilayah utama.
Untuk menghemat biaya, paket App Service sekunder dikonfigurasi untuk memiliki lebih sedikit instans dan/atau berada di tingkat harga yang lebih rendah. Ada tiga kemungkinan pendekatan:
Pilihan Paket App Service sekunder memiliki tingkat harga yang sama dengan yang utama, dengan jumlah instans yang sama atau lebih sedikit. Pendekatan ini memastikan paritas dalam ukuran fitur dan VM untuk dua paket App Service. RTO selama geo-failover hanya tergantung pada waktu untuk menskalakan instans.
Kurang disukai Paket App Service sekunder memiliki jenis tingkat harga yang sama (seperti PremiumV3) tetapi ukuran VM yang lebih kecil, dengan instans yang lebih sedikit. Misalnya, wilayah utama mungkin berada di tingkat P3V3 saat wilayah sekunder berada di tingkat P1V3. Pendekatan ini masih memastikan paritas fitur untuk dua paket App Service, tetapi kurangnya paritas ukuran mungkin memerlukan peningkatan skala manual ketika wilayah sekunder menjadi wilayah aktif. RTO selama geo-failover tergantung pada waktu untuk meningkatkan dan menskalakan instans.
Paling tidak disukai Paket App Service sekunder memiliki tingkat harga yang berbeda dari instans utama dan yang lebih rendah. Misalnya, wilayah utama mungkin berada di tingkat P3V3 saat wilayah sekunder berada di tingkat S1. Pastikan paket App Service sekunder memiliki semua fitur yang dibutuhkan aplikasi Anda untuk dijalankan. Perbedaan ketersediaan fitur antara keduanya dapat menyebabkan penundaan pemulihan aplikasi web Anda. RTO selama geo-failover tergantung pada waktu untuk meningkatkan dan menskalakan instans.
Skala otomatis dikonfigurasi pada wilayah sekunder jika wilayah aktif menjadi tidak aktif. Disarankan untuk memiliki aturan skala otomatis serupa di wilayah aktif dan pasif.
Selama bencana, wilayah utama menjadi tidak aktif, dan wilayah sekunder mulai menerima lalu lintas dan menjadi wilayah aktif.
Setelah wilayah sekunder menjadi aktif, beban jaringan memicu aturan skala otomatis yang telah dikonfigurasi sebelumnya untuk memperluas skala aplikasi web sekunder.
Anda mungkin perlu meningkatkan tingkat harga untuk wilayah sekunder secara manual, jika belum memiliki fitur yang diperlukan untuk dijalankan sebagai wilayah aktif. Misalnya, penskalaan otomatis memerlukan tingkat Standar atau lebih tinggi.
Ketika wilayah utama aktif lagi, Azure Front Door secara otomatis mengarahkan lalu lintas kembali ke wilayah tersebut, dan arsitektur kembali ke pasif aktif seperti sebelumnya.
File aplikasi harus disebarkan ke kedua aplikasi web dengan solusi CI/CD. Ini memastikan bahwa RPO praktis nol.
Jika aplikasi Anda secara aktif memodifikasi sistem file, cara terbaik untuk meminimalkan RPO adalah dengan hanya menulis ke berbagi Azure Storage yang dipasang alih-alih menulis langsung ke berbagi konten /beranda aplikasi web. Kemudian, gunakan fitur redundansi Azure Storage (GZRS atau GRS) untuk berbagi yang dipasang, yang memiliki RPO sekitar 15 menit.
Langkah-langkah untuk membuat arsitektur pasif aktif untuk aplikasi web Anda di App Service dirangkum sebagai berikut:
- Buat dua paket App Service di dua wilayah Azure yang berbeda. Paket App Service sekunder dapat disediakan menggunakan salah satu pendekatan yang disebutkan sebelumnya.
- Konfigurasikan aturan penskalaan otomatis untuk paket App Service sekunder sehingga diskalakan ke jumlah instans yang sama dengan yang utama ketika wilayah utama menjadi tidak aktif.
- Buat dua instans aplikasi web Anda, dengan satu di setiap paket App Service.
- Buat profil Azure Front Door dengan:
- Titik akhir.
- Grup asal dengan prioritas 1 untuk wilayah utama.
- Grup asal kedua dengan prioritas 2 untuk wilayah sekunder. Perbedaan prioritas memberi tahu Azure Front Door untuk lebih memilih wilayah utama saat online (dengan demikian pasif aktif).
- Sebuah rute.
- Batasi lalu lintas jaringan ke aplikasi web hanya dari instans Azure Front Door.
- Menyiapkan dan mengonfigurasi semua layanan Azure back-end lainnya, seperti database, akun penyimpanan, dan penyedia autentikasi.
- Sebarkan kode ke kedua aplikasi web dengan penyebaran berkelanjutan.
Tutorial: Membuat aplikasi multi-wilayah yang sangat tersedia di Azure App Service menunjukkan cara menyiapkan arsitektur pasif aktif.
Arsitektur pasif-dingin
Gunakan arsitektur pasif/dingin untuk membuat dan memelihara cadangan reguler aplikasi web Anda di akun Azure Storage yang terletak di wilayah lain.
Dengan contoh arsitektur ini:
Satu aplikasi web disebarkan ke satu wilayah.
Aplikasi web secara teratur dicadangkan ke akun Azure Storage di wilayah yang sama.
Replikasi lintas wilayah cadangan Anda bergantung pada konfigurasi redundansi data di akun penyimpanan Azure. Anda harus mengatur akun Azure Storage Anda sebagai GZRS jika memungkinkan. GZRS menawarkan redundansi zona sinkron dalam suatu wilayah dan asinkron di wilayah sekunder. Jika GZRS tidak tersedia, konfigurasikan akun sebagai GRS. Baik GZRS maupun GRS memiliki RPO sekitar 15 menit.
Untuk memastikan bahwa Anda dapat mengambil cadangan ketika wilayah utama akun penyimpanan menjadi tidak tersedia, aktifkan akses baca saja ke wilayah sekunder (masing-masing membuat akun penyimpanan RA-GZRS atau RA-GRS). Untuk informasi selengkapnya tentang merancang aplikasi Anda untuk memanfaatkan geo-redundansi, lihat Menggunakan geo-redundansi untuk merancang aplikasi yang sangat tersedia.
Selama bencana di wilayah aplikasi web, Anda harus menyebarkan semua sumber daya dependen App Service yang diperlukan secara manual dengan menggunakan cadangan dari akun Azure Storage, kemungkinan besar dari wilayah sekunder dengan akses baca. RTO mungkin berjam-jam atau ber hari.
Untuk meminimalkan RTO, sangat disarankan agar Anda memiliki playbook komprehensif yang menguraikan semua langkah yang diperlukan untuk memulihkan cadangan aplikasi web Anda ke Wilayah Azure lain.
Langkah-langkah untuk membuat wilayah dingin pasif untuk aplikasi web Anda di App Service dirangkum sebagai berikut:
Buat akun penyimpanan Azure di wilayah yang sama dengan aplikasi web Anda. Pilih Tingkat performa standar dan pilih redundansi sebagai Penyimpanan geo-redundan (GRS) atau penyimpanan geo-zona-redundan (GZRS).
Aktifkan RA-GRS atau RA-GZRS (akses baca untuk wilayah sekunder).
Konfigurasikan cadangan kustom untuk aplikasi web Anda. Anda dapat memutuskan untuk mengatur jadwal pencadangan aplikasi web Anda, seperti per jam.
Verifikasi bahwa file cadangan aplikasi web dapat diambil wilayah sekunder dari akun penyimpanan Anda.
Tip
Selain Azure Front Door, Azure menyediakan opsi penyeimbangan beban lainnya, seperti Azure Traffic Manager. Untuk perbandingan berbagai opsi, lihat Opsi penyeimbangan beban - Azure Architecture Center.
Pemulihan bencana dalam geografi wilayah tunggal
Jika wilayah aplikasi web Anda tidak memiliki penyimpanan GZRS atau GRS atau jika Anda berada di wilayah Azure yang bukan salah satu pasangan regional, Anda harus menggunakan penyimpanan redundan zona (ZRS) atau penyimpanan redundan lokal (LRS) untuk membuat arsitektur serupa. Misalnya, Anda dapat membuat wilayah sekunder secara manual untuk akun penyimpanan sebagai berikut:
Langkah-langkah untuk membuat wilayah dingin pasif tanpa GRS dan GZRS dirangkum sebagai berikut:
Buat akun penyimpanan Azure di wilayah yang sama dengan aplikasi web Anda. Pilih Tingkat performa standar dan pilih redundansi sebagai penyimpanan redundansi zona (ZRS).
Konfigurasikan cadangan kustom untuk aplikasi web Anda. Anda dapat memutuskan untuk mengatur jadwal pencadangan aplikasi web Anda, seperti per jam.
Verifikasi bahwa file cadangan aplikasi web dapat diambil wilayah sekunder dari akun penyimpanan Anda.
Buat akun penyimpanan Azure kedua di wilayah lain. Pilih Tingkat performa standar dan pilih redundansi sebagai penyimpanan redundan lokal (LRS).
Dengan menggunakan alat seperti AzCopy, replikasi cadangan kustom Anda (Zip, XML, dan file log) dari wilayah utama ke penyimpanan sekunder. Contohnya:
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'Anda dapat menggunakan Azure Automation dengan runbook PowerShell Workflow untuk menjalankan skrip replikasi Anda sesuai jadwal. Pastikan bahwa jadwal replikasi mengikuti jadwal serupa dengan cadangan aplikasi web.