Bagikan melalui

Keandalan dalam Azure Functions

Artikel ini menjelaskan dukungan keandalan di Azure Functions, dan mencakup ketahanan intra-regional dengan zona ketersediaan dan pemulihan lintas wilayah dan kelangsungan bisnis. Untuk gambaran umum yang lebih rinci tentang prinsip keandalan di Azure, lihat Keandalan Azure.

Dukungan zona ketersediaan untuk Azure Functions bergantung pada paket hosting Functions Anda:

Paket hosting Tingkat dukungan Untuk informasi selengkapnya...
Rencana Konsumsi Fleksibel GA Pilih Konsumsi Fleksibel di bagian atas artikel ini.
Paket Elastic Premium GA Pilih Premium di bagian atas artikel ini.
Paket (App Service) khusus GA Lihat Keandalan di Azure App Service.
Rencana Konsumsi N/a Tidak didukung oleh rencana Konsumsi.

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Azure Functions mendukung penyebaran redundansi zona.

Dukungan zona ketersediaan

Saat Anda mengonfigurasi aplikasi paket Konsumsi Flex sebagai redundansi zona, platform secara otomatis menyebarkan instans aplikasi fungsi Anda di seluruh zona di wilayah yang dipilih, dengan aturan yang berbeda untuk instans yang selalu siap versus sesuai permintaan.

Ketika redundansi zona diaktifkan dalam rencana Konsumsi Fleksibel, penyebaran instansi ditentukan berdasarkan aturan berikut:

  • Instans yang selalu siap didistribusikan di setidaknya dua zona secara bergiliran.
  • Instans on-demand, yang dibuat sebagai hasil dari volume sumber event ketika aplikasi diskalakan melebihi kapasitas siap pakai, didistribusikan di seluruh zona ketersediaan berdasarkan prinsip terbaik. Ini berarti bahwa untuk instans sesuai permintaan, peluasan skala yang lebih cepat diberikan preferensi atas distribusi yang merata di seluruh zona ketersediaan. Platform ini mencoba meratakan distribusi dari waktu ke waktu.
  • Untuk memastikan ketahanan zona dengan zona ketersediaan, platform secara otomatis mempertahankan setidaknya dua instans yang selalu siap untuk setiap fungsi atau grup penskalaan per fungsi, terlepas dari konfigurasi yang selalu siap untuk aplikasi. Setiap instans yang dibuat oleh platform dikelola platform, ditagih sebagai instans yang selalu siap, dan tidak mengubah pengaturan konfigurasi yang selalu siap.

Saat Anda mengonfigurasi paket aplikasi fungsi Elastic Premium sebagai zona redundan, platform secara otomatis menyebarkan instans aplikasi fungsi di seluruh 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 minimum instans aplikasi fungsi adalah dua.
  • Ketika Anda menentukan kapasitas yang lebih besar dari jumlah zona, instans akan tersebar secara merata hanya jika kapasitas yang ditentukan merupakan kelipatan dari jumlah zona.
  • Untuk nilai kapasitas yang lebih besar dari hasil perkalian Jumlah Zona dengan Jumlah instans, instans tambahan akan tersebar di zona-zona yang tersisa.

Penting

Azure Functions dapat berjalan di platform Azure App Service. Di platform App Service, paket yang menghosting aplikasi fungsi paket Premium disebut sebagai paket Elastic Premium, dengan nama SKU seperti EP1. Jika Anda memilih untuk menjalankan aplikasi fungsi pada paket Premium, pastikan untuk membuat paket dengan nama SKU yang dimulai dengan E, seperti EP1. Nama SKU paket App Service yang dimulai dengan P, seperti P1V2 (paket Premium V2 Small), adalah paket hosting Khusus. Karena didedikasikan dan bukan Elastic Premium, paket dengan nama SKU dimulai dengan P tidak menskalakan secara dinamis dan dapat meningkatkan biaya Anda.

Ketersediaan regional

Saat ini, tidak semua wilayah mendukung redundansi zona untuk paket Konsumsi Flex. Anda dapat menggunakan Azure CLI untuk melihat wilayah yang mendukungnya:

  1. Jika Anda belum melakukannya, instal dan masuk ke Azure menggunakan Azure CLI:

    az login

    Perintah memasukkan az login Anda ke akun Azure Anda.

  2. Gunakan perintah az functionapp list-flexconsumption-locations ini dengan opsi --zone-redundant=true yang menampilkan daftar wilayah yang saat ini mendukung paket Konsumsi Fleksibel zona redundan.

    az functionapp list-flexconsumption-locations --zone-redundant=true --query "sort_by(@, &name)[].{Region:name}" -o table

Saat Anda membuat aplikasi Konsumsi Flex di portal Microsoft Azure, Zone redundancy bagian halaman Dasar diaktifkan saat wilayah yang Anda pilih mendukungnya.

Paket Premium dengan redundansi zona tersedia di wilayah berikut:

Amerika Eropa Timur Tengah Afrika Asia Pasifik
Brasil Selatan Prancis Tengah Israel Tengah Afrika Selatan Utara Australia Timur
Kanada Tengah Jerman Barat Tengah Qatar Tengah India Tengah
US Tengah Italia Utara UAE Utara Tiongkok Utara 3
US Timur Eropa Utara Asia Timur
US Timur 2 Norwegia Timur Jepang Timur
US Tengah Selatan Swedia Tengah Asia Tenggara
Barat AS 2 Swiss Utara
Barat AS 3 UK Selatan
Eropa Barat

Prasyarat

Dukungan zona ketersediaan adalah fitur dari paket Flex Consumption. Berikut adalah pertimbangan saat ini untuk menggunakan zona ketersediaan:

Dukungan zona ketersediaan merupakan fitur dari paket Premium. Berikut adalah pertimbangan saat ini untuk zona ketersediaan:

  • Anda hanya dapat mengaktifkan zona ketersediaan dalam paket saat membuat aplikasi. Anda tidak dapat mengonversi paket Premium yang ada untuk menggunakan zona ketersediaan.
  • Anda harus menggunakan akun penyimpanan zona redundan (ZRS) untuk akun penyimpanan host default aplikasi fungsi Anda. Jika Anda menggunakan jenis akun penyimpanan yang berbeda, aplikasi Anda mungkin berperilaku tidak terduga selama pemadaman zona.
  • Aplikasi Windows dan Linux didukung.
  • Aplikasi fungsi yang dihosting pada paket Premium harus memiliki minimal dua instans yang selalu siap.
  • Platform menerapkan jumlah minimum di balik layar jika Anda menentukan jumlah instance kurang dari dua.
  • Jika Anda tidak menggunakan paket Premium atau unit skala yang mendukung zona ketersediaan, berada di wilayah yang tidak didukung, atau tidak yakin, lihat panduan migrasi.

Harga

Tidak ada pengukur terpisah yang terkait dengan mengaktifkan zona ketersediaan. Harga untuk instance yang digunakan dalam aplikasi Konsumsi Fleksibel redundan-zona sama dengan aplikasi Konsumsi Fleksibel zona tunggal. Untuk mempelajari lebih lanjut, lihat Tagihan.

Saat Anda mengaktifkan zona ketersediaan di aplikasi dengan konfigurasi instans yang selalu siap kurang dari dua instans untuk setiap fungsi atau grup penskalaan per fungsi, platform secara otomatis membuat dua instans jenis yang selalu siap untuk setiap fungsi atau grup penskalaan per fungsi. Instans baru ini juga disebut sebagai instans yang selalu siap digunakan.

Tidak ada biaya tambahan yang terkait dengan mengaktifkan zona ketersediaan. Harga untuk paket Premium App Service zona redundan sama dengan paket Premium zona tunggal. Untuk setiap paket App Service yang Anda gunakan, Anda dikenakan biaya berdasarkan SKU yang Anda pilih, kapasitas yang Anda tentukan, dan instans apa pun yang Anda skalakan berdasarkan kriteria skala otomatis Anda. Jika Anda mengaktifkan zona ketersediaan pada paket dengan kurang dari dua instans, platform memberlakukan jumlah instans minimum dua untuk paket App Service tersebut, dan Anda dikenakan biaya untuk kedua instans.

Buat aplikasi fungsi dalam rencana dengan redundansi zona

Saat ini ada beberapa cara untuk menyebarkan aplikasi Flex Consumption yang redundan zona.

  1. Untuk membuat aplikasi fungsi dalam paket berzona-redundan, Anda harus memiliki akun penyimpanan zona redundan yang sudah ada. Jika Anda belum memiliki akun penyimpanan zona-redundan, buat akun penyimpanan sebelum melanjutkan.

  2. Di portal Azure, buka halaman Buat Aplikasi Fungsi. Untuk informasi selengkapnya tentang membuat aplikasi fungsi di portal, lihat Membuat aplikasi fungsi.

  3. Pilih Konsumsi Fleksibel lalu pilih tombol Pilih .

  4. Pada halaman Buat Aplikasi Fungsi (Konsumsi Flex), pada tab Dasar , masukkan pengaturan untuk aplikasi fungsi Anda. Beri perhatian khusus pada pengaturan dalam tabel berikut (juga disorot dalam cuplikan layar berikut), yang memiliki persyaratan khusus untuk redundansi zona.

    Pengaturan Nilai yang disarankan Catatan untuk redundansi zona
    Wilayah Wilayah yang didukung pilihan Anda Wilayah tempat paket Konsumsi Flex Anda dibuat. Anda harus memilih wilayah yang mendukung zona ketersediaan. Lihat daftar ketersediaan wilayah.
    Zona redundansi Diaktifkan Pengaturan ini menentukan apakah aplikasi Anda memiliki redundansi zona. Anda hanya dapat memilih Enabled kapan Anda telah memilih wilayah yang mendukung redundansi zona.

    Cuplikan layar tab Dasar dari halaman buat aplikasi fungsi Flex Consumption.

  5. Pada tab Penyimpanan , pilih akun penyimpanan zona-redundan untuk aplikasi fungsi Anda. Beri perhatian khusus pada pengaturan dalam tabel berikut, yang memiliki persyaratan khusus untuk redundansi zona.

    Pengaturan Nilai yang disarankan Catatan untuk redundansi zona
    Akun penyimpanan Akun penyimpanan zona redundan Seperti dijelaskan di bagian prasyarat, kami sangat menyarankan menggunakan akun penyimpanan dengan redundansi zona untuk aplikasi fungsi dengan redundansi zona Anda.

  6. Untuk proses pembuatan aplikasi fungsi lainnya, buat aplikasi fungsi Anda seperti biasa. Tidak ada pengaturan di sisa proses pembuatan yang memengaruhi redundansi zona.

Setelah rencana redundansi zona dibuat dan disebarkan, aplikasi fungsi Flex Consumption yang dihosting dalam rencana baru Anda dianggap memiliki redundansi zona.

Memperbarui paket Konsumsi Flex menjadi zona redundan

Untuk mengubah redundansi zona aplikasi Anda, diperlukan mulai ulang, yang menyebabkan waktu tidak aktif di aplikasi Anda.

Sebelum memperbarui paket Konsumsi Flex Anda menjadi redundansi zona, Anda harus memperbarui akun penyimpanan host default agar juga menjadi zona redundan. Jika Anda menggunakan akun penyimpanan terpisah untuk kontainer penyebaran aplikasi, Anda harus memperbaruinya menjadi zona redundan juga.

Gunakan langkah-langkah ini untuk menyiapkan akun penyimpanan Anda untuk perubahan:

  1. Tinjau Pertimbangan Penyimpanan.
  2. Buat atau identifikasi akun penyimpanan zona-redundan untuk menjadi akun penyimpanan host default untuk aplikasi.
  3. Perbarui pengaturan terkait penyimpanan aplikasi, seperti AzureWebJobsStorage, untuk mengacu pada akun penyimpanan zona redundan. Lihat Bekerja dengan pengaturan aplikasi.
  4. Perbarui akun penyimpanan penyebaran untuk aplikasi, yang dapat sama atau berbeda dengan akun penyimpanan yang terkait dengan aplikasi. Lihat Mengonfigurasi pengaturan penyebaran.

Setelah akun penyimpanan yang digunakan oleh aplikasi Anda diperbarui, Anda dapat memperbarui paket Konsumsi Flex menjadi redundansi zona menggunakan templat Bicep atau ARM. Portal Microsoft Azure saat ini tidak mendukung pembuatan pembaruan redundansi zona untuk paket tersebut.

  1. Di portal Microsoft Azure, cari dan pilih aplikasi fungsi yang akan diperbarui.

  2. Di bawah Pengaturan, pilih Skala dan Konkurensi.

  3. Pada tab Redundansi zona , centang Tambahkan redundansi zona untuk mengaktifkan fitur. Jika sudah dicentang, Anda dapat menghapus centang kotak ini untuk menonaktifkan fitur.

  4. Pilih Simpan untuk menerapkan perubahan Anda dan memulai ulang aplikasi.

Cuplikan layar tab Skala dan Konkurensi dari aplikasi fungsi Konsumsi Flex.

Saat ini ada dua cara untuk menyebarkan paket Premium dan aplikasi fungsi zona redundan. Anda harus menggunakan portal Microsoft Azure atau templat ARM.

  1. Di portal Azure, buka halaman Buat Aplikasi Fungsi. Untuk informasi selengkapnya tentang membuat aplikasi fungsi di portal, lihat Membuat aplikasi fungsi.

  2. Pilih Functions Premium lalu pilih tombol Pilih .

  3. Pada halaman Buat Aplikasi Fungsi (Functions Premium), pada tab Dasar , masukkan pengaturan untuk aplikasi fungsi Anda. Beri perhatian khusus pada pengaturan dalam tabel berikut (juga disorot dalam cuplikan layar berikut), yang memiliki persyaratan khusus untuk redundansi zona.

    Pengaturan Nilai yang disarankan Catatan untuk redundansi zona
    Wilayah Wilayah yang didukung pilihan Anda Wilayah tempat paket Elastic Premium Anda dibuat. Anda harus memilih wilayah yang mendukung zona ketersediaan. Lihat daftar ketersediaan wilayah.
    Paket harga Salah satu paket Elastic Premium. Untuk informasi selengkapnya, lihat instans SKU yang tersedia. Artikel ini menjelaskan cara membuat aplikasi zona redundan dalam paket Premium. Redundansi zona saat ini tidak tersedia dalam paket Konsumsi. Untuk informasi tentang redundansi zona pada paket App Service, lihat Keandalan di Azure App Service.
    Zona redundansi Diaktifkan Pengaturan ini menentukan apakah aplikasi Anda memiliki redundansi zona. Anda tidak akan dapat memilih Enabled kecuali Anda telah memilih wilayah yang mendukung redundansi zona, seperti yang dijelaskan sebelumnya.

    Cuplikan layar tab Dasar dari halaman pembuatan aplikasi fungsi.

  4. Pada tab Penyimpanan , masukkan pengaturan untuk akun penyimpanan aplikasi fungsi Anda. Beri perhatian khusus pada pengaturan dalam tabel berikut, yang memiliki persyaratan khusus untuk redundansi zona.

    Pengaturan Nilai yang disarankan Catatan untuk redundansi zona
    Akun penyimpanan Akun penyimpanan zona redundan Seperti dijelaskan di bagian prasyarat, kami sangat menyarankan menggunakan akun penyimpanan dengan redundansi zona untuk aplikasi fungsi dengan redundansi zona Anda.

  5. Untuk proses pembuatan aplikasi fungsi lainnya, buat aplikasi fungsi Anda seperti biasa. Tidak ada pengaturan di sisa proses pembuatan yang memengaruhi redundansi zona.

Setelah rencana zona-redundan dibuat dan diterapkan, aplikasi fungsi apa pun yang dihosting pada rencana baru Anda dianggap sebagai zona-redundan.

Migrasi zona ketersediaan

Saat ini Anda tidak dapat mengubah dukungan zona ketersediaan paket Elastic Premium untuk aplikasi fungsi yang ada. Untuk informasi tentang cara memigrasi paket Premium publik dengan penyewa ganda dari zona tanpa ketersediaan ke dukungan zona ketersediaan, lihat Memigrasi App Service ke dukungan zona ketersediaan.

Pengalaman penurunan zona

Semua instance aplikasi fungsi yang tersedia dari aplikasi paket Konsumsi Flex dengan zona redundan sedang diaktifkan dan memproses acara. Aplikasi Konsumsi Flex terus berjalan bahkan ketika zona lain di wilayah yang sama mengalami pemadaman. Namun, ada kemungkinan bahwa perilaku nonruntime mungkin terpengaruh sebagai akibat dari pemadaman di zona ketersediaan lainnya. Perilaku aplikasi fungsi standar yang dapat memengaruhi ketersediaan meliputi:

  • Skalabilitas
  • Pembuatan aplikasi
  • Perubahan konfigurasi
  • Penyebaran

Redundansi zona untuk paket Flex Consumption hanya menjamin kelangsungan waktu aktif untuk aplikasi yang disebarkan dan berjalan.

Saat zona tidak berfungsi, Functions mendeteksi instans yang hilang dan secara otomatis mencoba menemukan atau membuat instans pengganti, sesuai kebutuhan, di zona yang tersedia. Selama pemadaman zonal, platform mencoba memulihkan keseimbangan pada zona-zona yang tersisa yang tersedia.

Semua instans aplikasi fungsi yang tersedia pada aplikasi fungsi dengan redundansi zona diaktifkan dan memproses event. Saat zona tidak berfungsi, Functions mendeteksi instans yang hilang dan secara otomatis mencoba menemukan instans pengganti baru jika diperlukan. Perilaku skala elastis tetap berlaku. Namun, dalam skenario penurunan zona, tidak ada jaminan bahwa permintaan untuk lebih banyak instance dapat berhasil, karena mengisi ulang instance yang hilang dilakukan berdasarkan upaya terbaik. Aplikasi yang disebarkan dalam paket Premium yang diaktifkan zona ketersediaan terus berjalan bahkan ketika zona lain di wilayah yang sama mengalami pemadaman. Namun, ada kemungkinan bahwa perilaku nonruntime masih dapat terpengaruh oleh pemadaman pada zona ketersediaan lainnya. Perilaku yang terpengaruh ini mungkin mencakup penskalaan paket Premium, pembuatan aplikasi, konfigurasi aplikasi, dan penerbitan aplikasi. Redundansi zona untuk paket Premium hanya memastikan uptime lanjutan untuk aplikasi yang telah diterapkan.

Saat mengalokasikan instans ke paket Premium zona redundan, Functions menggunakan penyeimbangan zona upaya terbaik yang ditawarkan oleh Azure Virtual Machine Scale Sets dasar. Paket Premium dianggap seimbang ketika setiap zona memiliki jumlah komputer virtual yang sama di semua zona lain yang digunakan oleh paket Premium, ditambah atau dikurangi satu komputer virtual.

Pemulihan bencana lintas wilayah dan kelangsungan bisnis

Pemulihan bencana (DR) mengacu pada praktik yang digunakan organisasi untuk pulih 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 membuat rencana pemulihan bencana, lihat rekomendasi untuk merancang strategi pemulihan bencana.

Untuk DR, Microsoft menggunakan model tanggung jawab bersama . Dalam model ini, Microsoft memastikan bahwa infrastruktur dasar dan layanan platform tersedia. Namun, banyak layanan Azure tidak secara otomatis mereplikasi data atau beralih dari wilayah yang gagal untuk mereplikasi ke wilayah lain yang tersedia. Untuk layanan tersebut, Anda bertanggung jawab untuk menyiapkan rencana pemulihan bencana yang berfungsi untuk beban kerja Anda. Sebagian besar layanan yang berjalan di penawaran platform as a service (PaaS) Azure menyediakan fitur dan panduan untuk mendukung DR. Anda dapat menggunakan fitur khusus layanan untuk mendukung pemulihan cepat dan membantu mengembangkan rencana DR Anda.

Bagian ini menjelaskan beberapa strategi yang dapat Anda gunakan untuk menyebarkan aplikasi fungsi untuk memungkinkan pemulihan bencana.

Untuk pemulihan bencana untuk Durable Functions, lihat Pemulihan bencana dan distribusi geografis di Azure Durable Functions.

Pemulihan bencana multi-wilayah

Karena tidak ada redundansi bawaan yang tersedia, fungsi berjalan di aplikasi fungsi di wilayah Azure tertentu. Untuk menghindari kehilangan eksekusi selama pemadaman, Anda dapat menerapkan secara redundan fungsi yang sama ke aplikasi fungsi di beberapa wilayah. Untuk mempelajari lebih lanjut tentang penyebaran multi-wilayah, lihat panduan dalam aplikasi web multi-wilayah yang sangat tersedia.

Saat Anda menjalankan kode fungsi yang sama di beberapa wilayah, ada dua pola yang perlu dipertimbangkan, aktif-aktif dan aktif-pasif.

Pola aktif-aktif untuk fungsi pemicu HTTP

Dengan pola aktif-aktif, fungsi di kedua wilayah berjalan aktif dan memproses kejadian, baik secara duplikat maupun secara bergantian. Anda harus menggunakan pola aktif-aktif dalam kombinasi dengan Azure Front Door untuk fungsi penting yang dipicu oleh HTTP Anda, yang dapat merutekan permintaan HTTP secara round-robin antara fungsi yang berjalan di beberapa wilayah. Front door juga dapat secara berkala memeriksa kesehatan setiap endpoint. Ketika fungsi di satu wilayah berhenti merespons pemeriksaan kesehatan, Azure Front Door mengeluarkannya dari sirkulasi dan hanya meneruskan lalu lintas ke fungsi sehat lainnya.

Arsitektur untuk Azure Front Door dan Fungsi.

Pola pasif aktif untuk fungsi pemicu non-HTTPS

Disarankan agar Anda menggunakan pola aktif-pasif untuk fungsi yang dipicu berbasis peristiwa dan non-HTTP, seperti fungsi yang dipicu Bus Layanan dan Event Hubs.

Untuk membuat redundansi untuk fungsi pemicu non-HTTP, gunakan pola pasif aktif. Dengan pola pasif aktif, fungsi berjalan secara aktif di wilayah yang menerima peristiwa; sementara fungsi yang sama di wilayah kedua tetap menganggur. Pola aktif-pasif menyediakan cara bagi hanya satu fungsi untuk memproses setiap pesan sambil menyediakan mekanisme untuk melakukan failover ke wilayah sekunder dalam bencana. Aplikasi Function bekerja dengan perilaku failover dari layanan rekanan, seperti pemulihan geografis Azure Service Bus dan pemulihan geografis Azure Event Hubs.

Pertimbangkan contoh topologi dengan menggunakan pemicu Azure Event Hubs. Dalam hal ini, pola aktif/pasif perlu melibatkan komponen berikut:

  • Azure Event Hubs disebarkan ke wilayah utama dan sekunder.
  • Bencana geografis diaktifkan untuk memasangkan hub peristiwa primer dan sekunder. Cara ini juga membuat alias yang dapat Anda gunakan untuk menyambungkan ke hub peristiwa dan beralih dari utama ke sekunder tanpa mengubah info koneksi.
  • Aplikasi fungsional ditempatkan di wilayah primer dan sekunder (failover), dengan aplikasi di wilayah sekunder pada dasarnya tidak aktif karena pesan tidak dikirim ke sana.
  • Pengaktifan aplikasi fungsi dilakukan pada string koneksi langsung (nonalias) yang sesuai untuk hub acara masing-masing.
  • Penerbit pada hub acara harus menerbitkan pada string koneksi alias.

Arsitektur contoh aktif-pasif.

Sebelum alih fungsi, penerbit yang mengirim ke alias bersama akan merutekan ke hub peristiwa utama. Aplikasi fungsi utama mendengarkan secara eksklusif pada hub peristiwa utama. Aplikasi fungsi sekunder adalah pasif dan diam. Segera setelah failover dimulai, penerbit yang mengirim melalui alias bersama dirutekan ke hub peristiwa sekunder. Aplikasi fungsi sekunder sekarang menjadi aktif dan mulai memicu secara otomatis. Failover yang efektif ke wilayah sekunder dapat dijalankan sepenuhnya dari event hub, dengan fungsi yang hanya aktif ketika event hub terkait aktif.

Baca lebih banyak informasi dan pertimbangan untuk pengalihan kegagalan dengan Service Bus dan Event Hubs.

Pola aktif-aktif untuk fungsi pemicu non-HTTPS

Meskipun Anda dianjurkan untuk menggunakan pola aktif-pasif untuk fungsi pemicu non-HTTPS, Anda masih dapat membuat penyebaran aktif-aktif untuk fungsi yang dipicu non-HTTP. Sebelum menerapkan pola ini, Anda harus mempertimbangkan bagaimana dua wilayah aktif berinteraksi atau berkoordinasi satu sama lain dan sumber pemicu.

Misalnya, pertimbangkan kode fungsi pemicu Service Bus yang sama yang disebarkan ke dua wilayah tetapi memicu pada antrean Service Bus yang sama. Dalam hal ini, kedua fungsi bertindak sebagai konsumen yang bersaing dalam menghapus antrean tunggal. Meskipun setiap pesan hanya dapat diproses oleh salah satu dari dua instance aplikasi, ini juga berarti masih ada satu titik kegagalan, yaitu instance tunggal dari Service Bus. Pertimbangkan untuk mengaktifkan fitur pemulihan bencana geografis dan replikasi geografis Service Bus untuk memastikannya juga tangguh.

Langkah berikutnya

  • Last updated on