Kelangsungan bisnis dan pemulihan bencana untuk Azure Logic Apps

  • Artikel

Untuk membantu mengurangi dampak dan efek yang ditimbulkan oleh kejadian tak terduga pada bisnis dan pelanggan Anda, pastikan Anda memiliki solusi pemulihan bencana (DR) sehingga Anda dapat melindungi data, dengan cepat memulihkan sumber daya yang mendukung fungsi bisnis penting, dan menjaga operasi tetap berjalan untuk menjaga kelangsungan bisnis (BC). Misalnya, gangguan dapat mencakup pemadaman, kerugian dalam infrastruktur atau komponen yang mendasarinya seperti penyimpanan, jaringan, atau sumber daya komputasi, kegagalan aplikasi yang tidak dapat dipulihkan, atau bahkan kehilangan pusat data penuh. Dengan memiliki solusi kelangsungan bisnis dan pemulihan bencana (BCDR), perusahaan atau organisasi Anda dapat merespons lebih cepat terhadap gangguan, direncanakan atau tidak direncanakan, dan mengurangi waktu henti bagi pelanggan Anda.

Artikel ini menyediakan panduan dan strategi BCDR yang dapat Anda terapkan saat Anda membangun alur kerja otomatis dengan menggunakan Azure Logic Apps. Alur kerja aplikasi logika membantu Anda lebih mudah mengintegrasikan dan mengatur data antara aplikasi, layanan cloud, dan sistem lokal dengan mengurangi berapa banyak kode yang harus Anda tulis. Saat Anda merencanakan BCDR, pastikan Anda tidak hanya mempertimbangkan aplikasi logika Anda, tetapi juga sumber daya Azure yang Anda gunakan dengan aplikasi logika Anda:

Lokasi utama dan sekunder

Setiap aplikasi logika perlu menentukan lokasi yang ingin Anda gunakan untuk penyebaran. Lokasi ini adalah wilayah publik di Azure multi-penyewa global, seperti "US Barat", atau lingkungan layanan integrasi (ISE) yang sebelumnya Anda buat dan sebarkan ke jaringan virtual Azure. Menjalankan aplikasi logika dalam ISE mirip dengan menjalankan aplikasi logika di wilayah Azure global, yang berarti strategi pemulihan bencana Anda dapat diterapkan ke kedua skenario. Namun, ISES memiliki pertimbangan lain seperti mengonfigurasi akses ke sumber daya yang hanya tersedia untuk ISES.

Catatan

Jika aplikasi logika Anda juga berfungsi dengan artefak B2B, seperti mitra dagang, perjanjian, skema, peta, dan sertifikat, yang disimpan dalam akun integrasi, akun integrasi dan aplikasi logika Anda harus menentukan lokasi yang sama.

Strategi pemulihan bencana ini berfokus pada pengaturan aplikasi logika utama Anda untuk kegagalan ke aplikasi logika siaga atau cadangan di lokasi alternatif di mana Azure Logic Apps juga tersedia. Dengan begitu, jika primer mengalami kerugian, gangguan, atau kegagalan, sekunder dapat mengambil pekerjaan. Strategi ini mengharuskan aplikasi logika sekunder dan sumber daya dependen Anda sudah disebarkan dan siap di lokasi alternatif.

Jika Anda mengikuti praktik DevOps yang baik, Anda sudah menggunakan Templat Azure Resource Manager untuk menentukan dan menyebarkan aplikasi logika Anda dan sumber daya dependennya. Templat Resource Manager memberi Anda kemampuan untuk menggunakan definisi penyebaran tunggal lalu menggunakan file parameter untuk menyediakan nilai konfigurasi yang akan digunakan untuk setiap tujuan penyebaran. Kemampuan ini berarti Anda dapat menyebarkan aplikasi logika yang sama ke lingkungan yang berbeda, misalnya, pengembangan, pengujian, dan produksi. Anda juga dapat menyebarkan aplikasi logika yang sama ke wilayah atau ISE Azure yang berbeda, yang mendukung strategi pemulihan bencana yang menggunakan wilayah berpasangan.

Untuk strategi kegagalan, aplikasi dan lokasi logika Anda harus memenuhi persyaratan berikut:

  • Instans aplikasi logika sekunder memiliki akses ke aplikasi, layanan, dan sistem yang sama dengan instans aplikasi logika utama.

  • Kedua instans aplikasi logika memiliki jenis host yang sama. Jadi, kedua instans tersebut disebarkan ke wilayah di Azure multi-penyewa global, atau kedua instans tersebut disebarkan ke ISES, yang memungkinkan aplikasi logika Anda mengakses sumber daya secara langsung di jaringan virtual Azure. Untuk praktik terbaik dan informasi selengkapnya tentang wilayah yang dipasangkan untuk BCDR, lihat Replikasi lintas wilayah di Azure: Kesinambungan bisnis dan pemulihan bencana.

    Misalnya, lokasi utama dan sekunder harus isi saat aplikasi logika utama berjalan di ISE dan menggunakan konektor versi ISE, tindakanHTTP untuk memanggil sumber daya di jaringan virtual Azure, atau keduanya. Dalam skenario ini, aplikasi logika sekunder Anda juga harus memiliki pengaturan serupa di lokasi sekunder sebagai aplikasi logika utama.

    Catatan

    Untuk skenario yang lebih canggih, Anda dapat mencampur Azure multi-penyewa dan ISE sebagai lokasi. Namun, pastikan Anda mempertimbangkan dan memahami perbedaan antara cara aplikasi logika berjalan dalam ISE versus Azure multi-penyewa.

  • Jika Anda menggunakan ISES, pastikan bahwa ISI diskalakan atau memiliki kapasitas yang cukup untuk menangani beban.

Contoh: Azure multi-penyewa

Contoh ini menunjukkan instans aplikasi logika primer dan sekunder, yang disebarkan ke wilayah terpisah di Azure multi-penyewa global untuk skenario ini. Templat Resource Manager tunggal mendefinisikan instans aplikasi logika dan sumber daya dependen yang diperlukan oleh aplikasi logika tersebut. File parameter terpisah menentukan nilai konfigurasi yang akan digunakan untuk setiap lokasi penyebaran:

Instans aplikasi logika primer dan sekunder di lokasi terpisah

Contoh: Mengintegrasi lingkungan layanan

Contoh ini menunjukkan instans aplikasi logika primer dan sekunder sebelumnya tetapi disebarkan untuk memisahkan ISES. Templat Resource Manager tunggal mendefinisikan instans aplikasi logika, sumber daya dependen yang diperlukan oleh aplikasi logika tersebut, dan ISE sebagai lokasi penyebaran. File parameter terpisah menentukan nilai konfigurasi yang akan digunakan untuk penyebaran di setiap lokasi:

Aplikasi logika primer dan sekunder di lokasi yang berbeda

Koneksi ke sumber daya

Azure Logic Apps menyediakan ratusan operasi konektor yang dapat digunakan alur kerja aplikasi logika Anda untuk bekerja dengan aplikasi, layanan, sistem, dan sumber daya lainnya lainnya, seperti akun Azure Storage, database SQL Server, akun email kantor atau sekolah, dan sebagainya. Jika aplikasi logika Anda memerlukan akses ke sumber daya ini, Anda membuat koneksi yang mengautentikasi akses ke sumber daya ini. Setiap koneksi adalah sumber daya Azure terpisah yang ada di lokasi tertentu dan tidak dapat digunakan oleh sumber daya di lokasi lain.

Untuk strategi pemulihan bencana Anda, pertimbangkan lokasi di mana sumber daya dependen ada relatif terhadap instans aplikasi logika Anda:

  • Instans utama dan sumber daya dependen Anda ada di lokasi yang berbeda. Dalam hal ini, instans sekunder Anda dapat terhubung ke sumber daya atau titik akhir dependen yang sama. Namun, Anda harus membuat koneksi khusus untuk instans sekunder Anda. Dengan demikian, jika lokasi utama Anda menjadi tidak tersedia, koneksi sekunder Anda tidak terpengaruh.

    Misalnya, misalkan aplikasi logika utama Anda terhubung ke layanan eksternal seperti Salesforce. Biasanya, ketersediaan dan lokasi layanan eksternal independen dari ketersediaan aplikasi logika Anda. Dalam hal ini, instans sekunder Anda dapat terhubung ke layanan yang sama tetapi harus memiliki koneksinya sendiri.

  • Instans utama dan sumber daya dependen Anda ada berada di lokasi yang sama. Dalam hal ini, sumber daya dependen harus memiliki cadangan atau versi yang direplikasi di lokasi yang berbeda sehingga instans sekunder Anda masih dapat mengakses sumber daya tersebut.

    Misalnya, misalkan aplikasi logika utama Anda terhubung ke layanan yang berada di lokasi atau wilayah yang sama, misalnya, Azure SQL Database. Jika seluruh wilayah ini menjadi tidak tersedia, layanan Azure SQL Database di wilayah tersebut juga kemungkinan tidak tersedia. Dalam hal ini, Anda ingin instans sekunder Anda menggunakan database yang direplikasi atau dicadangkan bersama dengan koneksi terpisah ke database tersebut.

Gateway data lokal

Jika aplikasi logika Anda berjalan di Azure multi-penyewa dan memerlukan akses ke sumber daya lokal seperti database SQL Server, Anda perlu menginstal gateway data lokal di komputer lokal. Anda kemudian dapat membuat sumber daya gateway data di portal Azure sehingga aplikasi logika Anda dapat menggunakan gateway saat Anda membuat koneksi ke sumber daya.

Sumber daya gateway data dikaitkan dengan lokasi atau wilayah Azure, sama seperti sumber daya aplikasi logika Anda. Dalam strategi pemulihan bencana Anda, pastikan gateway data tetap tersedia untuk digunakan aplikasi logika Anda. Anda dapat mengaktifkan ketersediaan tinggi untuk gateway Anda saat Anda memiliki beberapa penginstalan gateway.

Catatan

Jika aplikasi logika Anda berjalan di lingkungan layanan integrasi (ISE) dan hanya menggunakan konektor versi ISE untuk sumber data lokal, Anda tidak memerlukan gateway data karena konektor ISE menyediakan akses langsung ke sumber daya lokal.

Jika tidak ada konektor versi ISE yang tersedia untuk sumber daya lokal yang Anda inginkan, aplikasi logika Anda masih dapat membuat koneksi dengan menggunakan konektor non-ISE, yang berjalan di Azure multi-penyewa global, bukan ISE Anda. Namun, koneksi ini memerlukan gateway data lokal.

Peran aktif-aktif versus aktif-pasif

Anda dapat menyiapkan lokasi utama dan sekunder sehingga instans aplikasi logika di lokasi ini dapat memainkan peran berikut:

Peran primer-sekunder Deskripsi
Aktif-aktif Instans aplikasi logika primer dan sekunder di kedua lokasi secara aktif menangani permintaan dengan mengikuti salah satu dari pola ini:

- Keseimbangan beban: Anda dapat membuat kedua instans mendengarkan lalu lintas titik akhir dan keseimbangan beban ke setiap instans seperlunya.

- Konsumen yang bersaing: Anda dapat memiliki kedua instans bertindak sebagai konsumen yang bersaing sehingga instans bersaing untuk pesan dari antrian. Jika satu instans gagal, instance lain mengambil alih beban kerja.
Aktif-pasif Instans aplikasi logika utama secara aktif menangani seluruh beban kerja, sedangkan instans sekunder pasif (dinonaktifkan atau tidak aktif). Sekunder menunggu sinyal bahwa primer tidak tersedia atau tidak berfungsi karena gangguan atau kegagalan dan mengambil alih beban kerja sebagai instans aktif.
Kombinasi Beberapa aplikasi logika memainkan peran aktif-aktif, sementara aplikasi logika lainnya memainkan peran aktif-pasif.

Contoh aktif-aktif

Contoh ini menampilkan penyiapan aktif-aktif di mana kedua instans aplikasi logika secara aktif menangani permintaan atau pesan. Beberapa sistem atau layanan lain mendistribusikan permintaan atau pesan antar instans, misalnya, salah satu opsi berikut:

  • Penyeimbang beban "fisik", seperti perangkat keras yang merutekan lalu lintas

  • Penyeimbang muatan "lunak" seperti Azure Load Balancer atau Azure API Management. Dengan API Management, Anda dapat menentukan kebijakan yang menentukan cara memuat traffic masuk saldo. Atau, Anda dapat menggunakan layanan yang mendukung pelacakan status, misalnya, Azure Service Bus.

    Meskipun contoh ini terutama menunjukkan Azure Load Balancer, Anda dapat menggunakan opsi yang paling sesuai dengan kebutuhan skenario Anda:

    Pengaturan

  • Setiap instans aplikasi logika bertindak sebagai konsumen dan memiliki kedua instans bersaing untuk pesan dari antrian:

    Pengaturan

Contoh aktif-pasif

Contoh ini menunjukkan penyiapan pasif aktif di mana instans aplikasi logika utama aktif di satu lokasi, sementara instans sekunder tetap tidak aktif di lokasi lain. Jika utama mengalami gangguan atau kegagalan, Anda dapat meminta operator menjalankan skrip yang mengaktifkan sekunder untuk mengambil beban kerja.

Pengaturan

Kombinasi dengan aktif-aktif dan aktif-pasif

Contoh ini menunjukkan pengaturan gabungan di mana lokasi utama memiliki kedua instans aplikasi logika aktif, sementara lokasi sekunder memiliki instans aplikasi logika pasif aktif. Jika lokasi utama mengalami gangguan atau kegagalan, aplikasi logika aktif di lokasi sekunder, yang sudah menangani beban kerja parsial, dapat mengambil alih seluruh beban kerja.

  • Di lokasi utama, aplikasi logika aktif mendengarkan antrean Azure Service Bus untuk pesan, sementara aplikasi logika aktif lainnya memeriksa email dengan menggunakan pemicu polling Outlook Office 365.

  • Di lokasi sekunder, aplikasi logika aktif bekerja dengan aplikasi logika di lokasi utama dengan mendengarkan dan bersaing untuk pesan dari antrean Bus Layanan yang sama. Sementara itu, aplikasi logika tidak aktif pasif menunggu siaga untuk memeriksa email ketika lokasi utama menjadi tidak tersedia tetapi dinonaktifkan untuk menghindari membaca ulang email.

Kombinasi

Status dan riwayat aplikasi logika

Saat aplikasi logika Anda dipicu dan mulai berjalan, status aplikasi disimpan di lokasi yang sama tempat aplikasi dimulai dan tidak dapat ditransfer ke lokasi lain. Jika kegagalan atau gangguan terjadi, setiap instans alur kerja yang sedang berlangsung akan ditinggalkan. Saat Anda memiliki lokasi utama dan sekunder yang disiapkan, instans alur kerja baru mulai berjalan di lokasi sekunder.

Mengurangi instans yang sedang berlangsung yang ditinggalkan

Untuk meminimalkan jumlah instans alur kerja dalam proses yang ditinggalkan, Anda dapat memilih dari berbagai pola pesan yang dapat Anda terapkan, misalnya:

  • Pola slip perutean tetap

    Pola pesan perusahaan ini yang membagi proses bisnis ke tahap yang lebih kecil. Untuk setiap tahap, Anda menyiapkan aplikasi logika yang menangani beban kerja untuk tahap tersebut. Untuk berkomunikasi satu sama lain, aplikasi logika Anda menggunakan protokol perpesanan asinkron seperti antrean atau topik Azure Service Bus. Saat Anda membagi proses ke tahap yang lebih kecil, Anda mengurangi jumlah proses bisnis yang mungkin terjebak pada instans aplikasi logika yang gagal. Untuk informasi umum selengkapnya tentang pola ini, lihat Pola integrasi perusahaan - Slip perutean.

    Contoh ini menunjukkan pola slip perutean di mana setiap aplikasi logika mewakili tahap dan menggunakan antrean Bus Layanan untuk berkomunikasi dengan aplikasi logika berikutnya dalam prosesnya.

    Pisahkan proses bisnis menjadi tahapan yang diwakili oleh aplikasi logika, yang berkomunikasi satu sama lain dengan menggunakan antrean Azure Service Bus

    Jika instans aplikasi logika primer dan sekunder mengikuti pola slip perutean yang sama di lokasinya, Anda dapat menerapkan pola konsumen yang bersaing dengan menyiapkan peran aktif-aktif untuk instans tersebut.

  • Pola manajer proses (broker)

  • Pola peek-lock tanpa waktu habis

Mengakses pemicu dan menjalankan riwayat

Untuk mendapatkan informasi selengkapnya tentang eksekusi alur kerja aplikasi logika Anda sebelumnya, Anda dapat meninjau pemicu aplikasi dan menjalankan riwayat. Riwayat eksekusi aplikasi logika disimpan di lokasi atau wilayah yang sama tempat aplikasi logika tersebut berjalan, yang berarti Anda tidak dapat memigrasikan riwayat ini ke lokasi yang berbeda. Jika instans utama Anda gagal ke instans sekunder, Anda hanya dapat mengakses pemicu setiap instans dan menjalankan riwayat di masing-masing lokasi tempat instans tersebut dijalankan. Namun, Anda dapat mendapatkan informasi lokasi-agnostik tentang riwayat aplikasi logika Anda dengan menyiapkan aplikasi logika Anda untuk mengirim peristiwa diagnostik ke ruang kerja Azure Log Analytics. Anda kemudian dapat meninjau kesehatan dan riwayat di seluruh aplikasi logika yang berjalan di beberapa lokasi.

Panduan tipe pemicu

Jenis pemicu yang Anda gunakan di aplikasi logika menentukan opsi untuk cara Anda dapat mengatur aplikasi logika di seluruh lokasi dalam strategi pemulihan bencana Anda. Berikut adalah jenis pemicu yang tersedia yang dapat Anda gunakan di aplikasi logika:

Pemicu Pengulangan

Pemicu Pengulangan independen dari layanan atau titik akhir tertentu, dan hanya menembak berdasarkan jadwal yang ditentukan dan tidak ada kriteria lain, misalnya:

  • Frekuensi dan interval tetap, seperti setiap 10 menit
  • Jadwal yang lebih lanjut, seperti Senin terakhir setiap bulan pukul 17.00

Saat aplikasi logika Anda dimulai dengan pemicu Pengulangan, Anda harus menyiapkan instans aplikasi logika utama dan sekunder Anda dengan peran pasif aktif. Untuk mengurangi tujuan waktu pemulihan (RTO), yang mengacu pada durasi target untuk memulihkan proses bisnis setelah gangguan atau bencana, Anda dapat mengatur instans aplikasi logika Anda dengan kombinasi peran aktif-pasif dan peran pasif-aktif. Dalam pengaturan ini, Anda membagi jadwal di seluruh lokasi.

Misalnya, Anda memiliki aplikasi logika yang perlu berjalan setiap 10 menit. Anda dapat mengatur aplikasi dan lokasi logika sehingga jika lokasi utama tidak tersedia, lokasi sekunder dapat mengambil alih pekerjaan:

Kombinasi

  • Di lokasi utama, siapkan peran pasif aktif untuk aplikasi logika ini:

    • Untuk aplikasi logika aktif yang diaktifkan, atur pemicu Pengulangan untuk memulai di bagian atas jam dan ulangi setiap 20 menit, misalnya, 09.00, 09.20, dan sebagainya.

    • Untuk aplikasi logika pasif yang dinonaktifkan, atur pemicu Pengulangan ke jadwal yang sama tetapi memulai 10 menit setelah satu jam dan berulang setiap 20 menit, misalnya 09.10, 09.30, dan sebagainya.

  • Di lokasi sekunder, siapkan pasif-aktif untuk aplikasi logika ini:

    • Untuk aplikasi logika pasif yang dinonaktifkan, atur pemicu Pengulangan ke jadwal yang sama dengan aplikasi logika aktif di lokasi utama, yang berada di atas satu jam dan ulangi setiap 20 menit, misalnya 09.00, 09.10, dan sebagainya.

    • Untuk aplikasi logika aktif yang dinonaktifkan, atur pemicu Pengulangan ke jadwal yang sama dengan aplikasi logika pasif di lokasi utama, yang dimulai 10 menit setelah satu jam dan berulang setiap 20 menit, misalnya 09.10, 09.20, dan sebagainya.

Sekarang, jika peristiwa yang mengganggu terjadi di lokasi utama, aktifkan aplikasi logika pasif di lokasi alternatif. Dengan begitu, jika menemukan kegagalan membutuhkan waktu, pengaturan ini membatasi jumlah pengulangan yang terlewat selama penundaan itu.

Pemicu Polling

Untuk secara teratur memeriksa apakah data baru untuk diproses tersedia dari layanan atau titik akhir tertentu, aplikasi logika Anda dapat menggunakan pemicu polling yang berulang kali memanggil layanan atau titik akhir berdasarkan jadwal pengulangan tetap. Data yang disediakan layanan atau titik akhir dapat memiliki salah satu tipe berikut:

  • Data statis, yang menjelaskan data yang selalu tersedia untuk dibaca
  • Data volatil, yang menjelaskan data yang tidak lagi tersedia setelah dibaca

Untuk menghindari berulang kali membaca data yang sama, aplikasi logika Anda perlu mengingat data mana yang sebelumnya dibaca dengan mempertahankan status baik di sisi klien atau di server, layanan, atau sisi sistem.

  • Aplikasi logika yang bekerja dengan pemicu penggunaan status pihak klien yang dapat mempertahankan status.

    Misalnya, pemicu yang membaca pesan baru dari kotak masuk email mengharuskan pemicunya dapat mengingat pesan yang terakhir dibaca. Dengan begitu, pemicu memulai aplikasi logika hanya ketika pesan yang belum dibaca berikutnya tiba.

  • Aplikasi logika yang bekerja dengan server, layanan, atau status sisi sistem menggunakan nilai properti atau pengaturan yang ada di server, layanan, atau sisi sistem.

    Misalnya, pemicu berbasis kueri yang membaca baris dari database mengharuskan baris memiliki kolom isRead yang diatur ke FALSE. Setiap kali pemicu membaca baris, aplikasi logika memperbarui baris itu dengan mengubah kolom isRead dari FALSE ke TRUE.

    Pendekatan sisi server ini berfungsi sama untuk antrean Bus Layanan atau topik yang memiliki semantik antrian di mana pemicu dapat membaca dan mengunci pesan saat aplikasi logika memproses pesan. Ketika aplikasi logika selesai diproses, pemicu akan menghapus pesan dari antrean atau topik.

Dari perspektif pemulihan bencana, saat Anda menyiapkan instans utama dan sekunder aplikasi logika, pastikan Anda memperhitungkan perilaku ini berdasarkan apakah track aplikasi logika Anda menyatakan di sisi klien atau di sisi server:

  • Untuk aplikasi logika yang berfungsi dengan status pihak klien, pastikan aplikasi logika Anda tidak membaca pesan yang sama lebih dari satu kali. Hanya satu lokasi yang dapat memiliki instans aplikasi logika aktif pada waktu tertentu. Pastikan bahwa instans aplikasi logika di lokasi alternatif tidak aktif atau dinonaktifkan hingga instans utama gagal ke lokasi alternatif.

    Misalnya, pemicu Outlook Office 365 mempertahankan status pihak klien dan melacak cap waktu untuk email yang terakhir dibaca untuk menghindari membaca duplikat.

  • Untuk aplikasi logika yang berfungsi dengan status sisi server, Anda dapat mengatur instans aplikasi logika Anda untuk memainkan peran aktif-aktif di mana mereka bekerja sebagai konsumen yang bersaing atau peran aktif-pasif di mana instans alternatif menunggu sampai instans utama gagal ke lokasi alternatif.

    Misalnya, membaca dari antrean pesan, seperti antrean Azure Service Bus, menggunakan status sisi server karena layanan antrian mempertahankan kunci pada pesan untuk mencegah klien lain membaca pesan yang sama.

    Catatan

    Jika aplikasi logika Anda perlu membaca pesan dalam urutan tertentu, misalnya, dari antrean Bus Layanan, Anda dapat menggunakan pola konsumen yang bersaing tetapi hanya jika dikombinasikan dengan sesi Bus Layanan, yang juga dikenal sebagai pola konvoi berurutan. Jika tidak, Anda harus menyiapkan instans aplikasi logika Anda dengan peran pasif aktif.

Pemicu Permintaan

Pemicu Permintaan membuat aplikasi logika Anda dapat dihubungi dari aplikasi, layanan, dan sistem lain dan biasanya digunakan untuk menyediakan kemampuan ini:

  • API REST langsung untuk aplikasi logika yang dapat dihubungi orang lain

    Misalnya, gunakan pemicu Permintaan untuk memulai aplikasi logika Anda sehingga aplikasi logika lain dapat memanggil pemicu dengan menggunakan tindakan Alur kerja panggilan - Logic Apps.

  • Mekanisme webhook atau panggilan balik untuk aplikasi logika Anda

  • Cara menjalankan operasi atau rutinitas pengguna secara manual untuk memanggil aplikasi logika Anda, misalnya, dengan menggunakan skrip PowerShell yang melakukan tugas tertentu

Dari perspektif pemulihan bencana, pemicu Permintaan adalah penerima pasif karena aplikasi logika tidak melakukan pekerjaan apa pun dan menunggu sampai beberapa layanan atau sistem lain secara eksplisit memanggil pemicunya. Sebagai titik akhir pasif, Anda dapat mengatur instans utama dan sekunder dengan cara berikut:

  • Aktif-aktif : Kedua instans secara aktif menangani permintaan atau panggilan. Penelepon atau router menyeimbangkan atau mendistribusikan lalu lintas di antara instans tersebut.

  • Active-passive: Hanya instance utama yang aktif dan menangani semua pekerjaan, sementara instans sekunder menunggu hingga gangguan atau kegagalan pengalaman utama. Penelepon atau perute menentukan kapan harus memanggil instance sekunder.

Sebagai arsitektur yang direkomendasikan, Anda dapat menggunakan Azure API Management sebagai proxy untuk aplikasi logika yang menggunakan pemicu Permintaan. API Management menyediakan ketahanan lintas regional bawaan dan kemampuan untuk merutekan lalu lintas di beberapa titik akhir.

Pemicu Webhook

Pemicu webhook menyediakan kemampuan bagi aplikasi logika Anda untuk berlangganan layanan dengan meneruskan URL panggilan balik ke layanan tersebut. Aplikasi logika Anda kemudian dapat mendengarkan dan menunggu peristiwa tertentu terjadi di titik akhir layanan tersebut. Ketika peristiwa terjadi, layanan memanggil pemicu webhook dengan menggunakan URL panggilan balik, yang kemudian menjalankan aplikasi logika. Ketika diaktifkan, pemicu webhook berlangganan layanan. Ketika dinonaktifkan, pemicu berhenti berlangganan layanan.

Dari perspektif pemulihan bencana, siapkan instans primer dan sekunder yang menggunakan pemicu webhook untuk memainkan peran pasif aktif karena hanya satu instans yang harus menerima peristiwa atau pesan dari titik akhir berlangganan.

Menilai kesehatan instans primer

Agar strategi pemulihan bencana Anda berfungsi, solusi Anda memerlukan cara untuk melakukan tugas-tugas ini:

Bagian ini menjelaskan salah satu solusi yang dapat Anda gunakan langsung atau sebagai fondasi untuk desain Anda sendiri. Berikut adalah gambaran umum visual tingkat tinggi untuk solusi ini:

Membuat aplikasi logika pengawasan yang memantau aplikasi logika pemeriksaan kesehatan di lokasi utama

Periksa ketersediaan instans utama

Untuk menentukan apakah instans utama tersedia, berjalan, dan dapat berfungsi, Anda dapat membuat aplikasi logika "pemeriksaan kesehatan" yang berada di lokasi yang sama dengan instans utama. Anda kemudian dapat menghubungi aplikasi pemeriksaan kesehatan ini dari lokasi alternatif. Jika aplikasi pemeriksaan kesehatan berhasil merespons, infrastruktur yang mendasari untuk layanan Azure Logic Apps di wilayah tersebut tersedia dan berfungsi. Jika aplikasi pemeriksaan kesehatan gagal merespons, Anda dapat berasumsi bahwa lokasinya tidak lagi sehat.

Untuk tugas ini, buat aplikasi logika pemeriksaan kesehatan dasar yang melakukan tugas-tugas ini:

  1. Menerima panggilan dari aplikasi pengawas dengan menggunakan pemicu Permintaan.

  2. Merespons dengan status yang menunjukkan apakah aplikasi logika yang diperiksa masih berfungsi dengan menggunakan tindakan Respons.

    Penting

    Aplikasi logika pemeriksaan kesehatan harus menggunakan tindakan Respons sehingga aplikasi merespons secara sinkron, tidak sinkron.

  3. Secara opsional, untuk menentukan lebih lanjut apakah lokasi utama sehat, Anda dapat memperhitungkan kesehatan layanan lain yang berinteraksi dengan aplikasi logika target di lokasi ini. Cukup perluas aplikasi logika pemeriksaan kesehatan untuk menilai kesehatan untuk layanan lain ini juga.

Membuat aplikasi logika pengawasan

Untuk memantau kesehatan instans utama dan memanggil aplikasi logika pemeriksaan kesehatan, buat aplikasi logika "pengawas" di lokasi alternatif. Misalnya, Anda dapat mengatur aplikasi logika pengawas sehingga jika memanggil logika pemeriksaan kesehatan gagal, pengawas dapat mengirim peringatan ke tim operasi Anda sehingga mereka dapat menyelidiki kegagalan dan mengapa instans utama tidak merespons.

Penting

Pastikan bahwa aplikasi logika pengawasan Anda berada di lokasi yang berbeda dari lokasi utama. Jika Azure Logic Apps di lokasi utama mengalami masalah, alur kerja aplikasi logika pengawas Anda mungkin tidak berjalan.

Untuk tugas ini, di lokasi sekunder, buat aplikasi logika pengawas yang melakukan tugas-tugas ini:

  1. Jalankan berdasarkan pengulangan tetap atau terjadwal dengan menggunakan pemicu Pengulangan.

    Anda dapat mengatur pengulangan ke nilai yang berada di bawah tingkat toleransi untuk tujuan waktu pemulihan (RTO) Anda.

  2. Panggil alur kerja aplikasi logika pemeriksaan kesehatan di lokasi utama dengan menggunakan tindakan HTTP.

Anda juga dapat membuat aplikasi logika pengawas yang lebih canggih, yang setelah sejumlah kegagalan, yang memanggil aplikasi logika lain yang secara otomatis menangani peralihan ke lokasi sekunder saat primer gagal.

Mengaktifkan instans sekunder Anda

Untuk mengaktifkan instans sekunder secara otomatis, Anda dapat membuat aplikasi logika yang memanggil API manajemen seperti konektor Azure Resource Manager untuk mengaktifkan aplikasi logika yang sesuai di lokasi sekunder. Anda dapat memperluas aplikasi pengawasan untuk memanggil aplikasi logika aktivasi ini setelah terjadi sejumlah kegagalan tertentu.

Redundansi zona dengan zona ketersediaan

Di wilayah Azure, zona ketersediaan adalah lokasi yang terpisah secara fisik yang dapat menerima kegagalan lokal. Kegagalan dapat mencakup kegagalan perangkat lunak dan perangkat keras hingga peristiwa seperti gempa bumi, banjir, dan kebakaran. Zona ini mencapai toleransi melalui redundansi dan isolasi logis layanan Azure.

Untuk memberikan ketahanan dan ketersediaan terdistribusi, setidaknya ada tiga zona ketersediaan terpisah di setiap wilayah Azure yang mendukung dan mengaktifkan redundansi zona. Platform Azure Logic Apps mendistribusikan zona ini dan beban kerja aplikasi logika di seluruh zona ini. Kemampuan ini adalah persyaratan utama untuk mengaktifkan arsitektur tangguh dan memberikan ketersediaan tinggi jika kegagalan pusat data terjadi di suatu wilayah.

Saat ini, kemampuan ini masih dalam pratinjau dan tersedia untuk aplikasi logika Consumption baru di wilayah tertentu. Untuk informasi selengkapnya, lihat dokumentasi berikut:

Kumpulkan data diagnostik

Anda dapat menyiapkan pembuatan log untuk aplikasi logika Anda berjalan dan mengirim data diagnostik yang dihasilkan ke layanan seperti Azure Storage, Azure Event Hubs, dan Azure Log Analytics untuk penanganan dan pemrosesan lebih lanjut.

Langkah berikutnya