Keandalan di Azure Service Bus

Azure Service Bus adalah layanan broker pesan perusahaan yang dikelola sepenuhnya yang menyediakan kemampuan olahpesan asinkron yang andal untuk memisahkan aplikasi dan layanan. Service Bus mendukung antrean untuk komunikasi titik-ke-titik dan topik dengan langganan untuk pola olahpesan publish-subscribe. Layanan ini menyediakan fitur keandalan bawaan, termasuk durabilitas pesan, jaminan pengiriman setidaknya sekali, dan antrean surat mati untuk menangani pemrosesan pesan yang gagal.

Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.

Artikel ini menjelaskan cara membuat Azure Service Bus tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, pemadaman zona ketersediaan, dan pemadaman wilayah. Ini juga menekankan beberapa informasi utama tentang perjanjian tingkat layanan (SLA) Service Bus.

Rekomendasi penyebaran produksi

Azure Well-Architected Framework memberikan rekomendasi dalam keandalan, performa, keamanan, biaya, dan operasi. Untuk mempelajari bagaimana area ini saling memengaruhi dan berkontribusi pada solusi Azure Service Bus yang andal, lihat Praktik terbaik arsitektur untuk Service Bus.

Gambaran umum arsitektur keandalan

Bagian ini menjelaskan beberapa aspek penting tentang cara kerja layanan yang paling relevan dari perspektif keandalan. Bagian ini memperkenalkan arsitektur logis, yang mencakup beberapa sumber daya dan fitur yang Anda sebarkan dan gunakan. Ini juga membahas arsitektur fisik, yang memberikan detail tentang cara kerja layanan di bawah sampul.

Arsitektur logika

Namespace berfungsi sebagai kontainer manajemen untuk Azure Service Bus dan dapat dikonfigurasi untuk menggunakan tingkat Dasar, Standar, atau Premium. Anda mengonfigurasi layanan di tingkat namespace dengan mengalokasikan kapasitas, mengonfigurasi keamanan jaringan, dan mengaktifkan Geo-Replication serta Pemulihan Geo-Disaster.

Dalam namespace, Anda menyebarkan antrean dan topik, yang merupakan entitas pesan yang memiliki semantik berbeda. Untuk informasi selengkapnya, lihat Antrean, topik, dan langganan Service Bus.

Anda dapat secara opsional mengonfigurasi partisi di namespace Anda, yang menyebarkan antrean dan topik di beberapa broker pesan dan penyimpanan olahpesan. Namespace dapat menggunakan beberapa partisi untuk menangani pemrosesan paralel dan penskalaan horizontal. Service Bus hanya menjamin pemesanan dalam satu partisi. Partisi memainkan peran kunci dalam desain keandalan aplikasi Anda. Saat Anda merancang aplikasi, lakukan trade-off antara memaksimalkan ketersediaan dan konsistensi. Untuk tingkat Premium, aktifkan partisi pada namespace. Untuk namespace tingkat Dasar dan Standar, konfigurasikan partisi pada entitas dan secara opsional saat Anda mengirim pesan.

Anda dapat menggunakan Service Bus dan pendekatan desain asinkronnya untuk meningkatkan ketersediaan aplikasi Anda. Untuk informasi selengkapnya, lihat Pola olahpesan asinkron dan ketersediaan tinggi.

Arsitektur fisik

Service Bus menyediakan sumber daya komputasi dan penyimpanan yang mendasar. Untuk setiap namespace, beberapa broker pesan memproses pesan, dan beberapa sistem penyimpanan pesan menyimpan pesan. Setiap penyimpanan olahpesan memiliki tiga salinan: satu salinan utama dan dua salinan sekunder. Service Bus menjaga ketiga salinan tetap sinkron untuk operasi data dan operasi manajemen. Jika salinan utama gagal, Service Bus mempromosikan salinan sekunder ke primer tanpa waktu henti untuk klien.

Untuk namespace yang menggunakan tingkat Dasar atau Standar, Azure Service Bus menyediakan redundansi melalui infrastruktur multipenyewa bersama yang secara otomatis mereplikasi pesan di seluruh zona ketersediaan jika tersedia. Layanan ini mempertahankan beberapa penyimpanan pesan dan menjaga semua salinan tetap tersinkronisasi untuk fungsi data dan manajemen.

Untuk namespace tingkat Premium, Azure Service Bus menyediakan unit olahpesan khusus (MUs) yang masing-masing memiliki sumber daya CPU dan memori khusus. Namespace tingkat premium dapat menskalakan secara otomatis berdasarkan tuntutan beban kerja. Untuk informasi selengkapnya, lihat Memperbarui MUs namespace Service Bus secara otomatis.

Infrastruktur Service Bus mencakup beberapa komputer fisik dan rak yang tersebar di domain kesalahan, yang mengurangi risiko kegagalan bencana yang memengaruhi namespace layanan Anda. Di wilayah yang memiliki zona ketersediaan, infrastruktur dibangun di beberapa pusat data fisik terpisah. Layanan ini menerapkan deteksi kegagalan transparan dan mekanisme failover sehingga terus beroperasi dalam tingkat layanan yang terjaga dan biasanya tanpa gangguan yang nyata ketika kegagalan ini terjadi.

Ketahanan terhadap kesalahan sementara

Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.

Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.

Service Bus SDK menyertakan logika coba lagi otomatis dengan backoff eksponensial untuk operasi yang gagal karena kondisi sementara seperti batas waktu jaringan atau tidak tersedianya layanan sementara. Ketika aplikasi mengalami pemutusan sementara dari Service Bus, SDK secara otomatis mencoba untuk terhubung kembali dengan menggunakan kebijakan coba lagi yang dikonfigurasi.

Untuk mengoptimalkan penanganan kesalahan sementara di aplikasi Anda, gunakan Service Bus SDK terbaru, yang mencakup logika coba lagi terbaru dan fitur manajemen koneksi. Untuk informasi selengkapnya, lihat Pustaka klien Service Bus untuk .NET.

Ketahanan terhadap kegagalan zona ketersediaan

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 Service Bus mendukung penyebaran redundansi zona di semua tingkat layanan. Saat Anda membuat namespace Bus Layanan di wilayah yang didukung, redundansi zona secara otomatis diaktifkan tanpa biaya tambahan. Model penyebaran zona-redundan berlaku untuk semua fitur Azure Service Bus, termasuk partisi dan sesi.

Azure Service Bus secara transparan mereplikasi konfigurasi, metadata, dan data pesan Anda di beberapa zona ketersediaan di wilayah tersebut. Redundansi zona menyediakan failover otomatis tanpa intervensi dari Anda. Semua komponen Azure Service Bus, termasuk komputasi, jaringan, dan penyimpanan, direplikasi di seluruh zona. Azure Service Bus memiliki cadangan kapasitas yang cukup untuk langsung menangani hilangnya zona secara instan. Ini terus beroperasi tanpa kehilangan data atau gangguan pada aplikasi olahpesan, bahkan jika seluruh zona ketersediaan menjadi tidak tersedia.

Diagram yang menunjukkan namespace Service Bus yang redundan pada zona. Ini mencakup tiga zona ketersediaan, diurutkan dari kiri ke kanan.

Persyaratan

• Dukungan wilayah: Anda dapat menerapkan namespace Service Bus zona redundan ke wilayah Azure yang mendukung zona ketersediaan. Azure Service Bus secara otomatis mengaktifkan dukungan zona ketersediaan saat Anda membuat namespace layanan di wilayah yang didukung, tanpa memerlukan konfigurasi tambahan.

• Tingkatan: Semua tingkatan Azure Service Bus (Dasar, Standar, dan Premium) mendukung zona ketersediaan tanpa persyaratan tambahan.

Pertimbangan

Namespace Service Bus menyertakan zoneRedundant properti. Sebelumnya, properti ini diperlukan untuk mengaktifkan zona ketersediaan, tetapi persyaratan ini telah berubah dan zoneRedundant properti tidak digunakan lagi. Properti ini dapat muncul sebagai false bahkan ketika redundansi zona diaktifkan. Semua namespace di wilayah yang memiliki zona ketersediaan adalah zona redundan.

Biaya

Redundansi zona di Azure Service Bus tidak menambahkan biaya tambahan.

Mengonfigurasi dukungan zona ketersediaan

Namespace Service Bus secara otomatis mendukung redundansi zona saat Anda menyebarkannya di wilayah yang didukung. Tidak diperlukan konfigurasi lainnya.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang dapat diharapkan ketika namespace Service Bus dikonfigurasi untuk redundansi wilayah dan semua zona ketersediaan berfungsi secara optimal.

• Pengaturan lalu lintas antar zona: Azure Service Bus menggunakan model aktif-aktif di mana pesan didistribusikan di beberapa zona ketersediaan. Koneksi klien secara otomatis diseimbangkan beban di seluruh zona, dan layanan merutekan operasi ke infrastruktur olahpesan yang tersedia terlepas dari zonanya.

• Replikasi data antar zona: Azure Service Bus menggunakan replikasi sinkron di seluruh zona ketersediaan, termasuk untuk metadata dan data pesan. Beberapa salinan penyimpanan pesan harus mengonfirmasi operasi tulis sebelum layanan menganggapnya selesai, yang memastikan konsistensi data di seluruh zona selama operasi normal.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika namespace Service Bus dikonfigurasi untuk redundansi zona dan terjadi gangguan pada zona ketersediaan.

• Deteksi dan respons: Microsoft secara otomatis mendeteksi kegagalan zona dan memulai failover ke zona sehat. Tidak ada tindakan pelanggan yang diperlukan untuk failover tingkat zona.

• Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

• Permintaan aktif: Selama kegagalan zona, Azure Service Bus mungkin menghilangkan permintaan aktif. Jika klien Anda menangani kesalahan sementara dengan tepat dengan mencoba kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.

• Kehilangan data yang diharapkan: Tidak ada kehilangan data yang terjadi selama kegagalan zona karena Azure Service Bus secara sinkron mereplikasi pesan di seluruh zona sebelum pengakuan.

• Waktu henti yang diharapkan: Kegagalan zona dapat menyebabkan beberapa detik waktu henti. Jika klien Anda menangani kesalahan sementara dengan tepat dengan mencoba kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.

• Pengalihan lalu lintas: Azure Service Bus mendeteksi hilangnya zona dan secara otomatis mengalihkan permintaan baru ke replika lain di salah satu zona ketersediaan yang sehat.

  Service Bus SDK biasanya menangani manajemen koneksi dan mencoba kembali logika secara transparan.

Pemulihan Zona

Saat zona ketersediaan pulih, Service Bus secara otomatis mengintegrasi ulang zona ke dalam topologi layanan aktif. Zona yang dipulihkan kemudian menerima koneksi baru dan memproses pesan bersama zona lain. Data yang direplikasi ke zona yang bertahan selama pemadaman tetap utuh, dan replikasi sinkron normal dilanjutkan di semua zona. Anda tidak perlu mengambil tindakan untuk pemulihan zona atau reintegrasi.

Uji kegagalan zona

Service Bus mengelola perutean lalu lintas, failover, dan pemulihan zona saat terjadi kegagalan zona, sehingga Anda tidak perlu memvalidasi proses kegagalan zona ketersediaan atau memberikan input lebih lanjut.

Ketahanan terhadap kegagalan di seluruh wilayah

Azure Service Bus menyediakan dua jenis dukungan multi-wilayah, yang keduanya memerlukan namespace tingkat Premium:

• Geo-Replikasi menyediakan replikasi pasif aktif metadata dan data pesan antara wilayah utama dan wilayah sekunder. Gunakan Geo-Replication untuk sebagian besar aplikasi yang harus tetap tahan terhadap pemadaman wilayah dan memiliki toleransi rendah untuk kehilangan data pesan.

• Metadata Geo-Disaster Recovery menyediakan replikasi konfigurasi dan metadata pasif aktif antara wilayah primer dan sekunder, tetapi tidak mereplikasi data pesan. Pertimbangkan untuk menggunakan Geo-Disaster Recovery untuk aplikasi yang menangani replikasi data mereka sendiri atau tidak memerlukan replikasi data.

Tabel berikut ini meringkas perbedaan utama antara kedua fitur:

Capability	Geo-Replikasi	Pemulihan Bencana Geografis
Apa yang direplikasi	Metadata dan data (pesan, status pesan, perubahan properti)	Metadata saja (entitas, konfigurasi, properti)
Kehilangan data saat failover	Tidak ada kehilangan data dengan promosi yang direncanakan; kemungkinan kehilangan data dengan promosi paksa	Pesan tidak direplikasi; harus dipulihkan secara manual dari namespace utama lama
Perilaku failover	Mempromosikan sekunder ke primer; primer lama menjadi sekunder	Failover tunggal; pemadanan rusak setelah failover
Kemampuan pemulihan sistem setelah kegagalan	Ya, dapat mengembalikan ke utama asli	Tidak, harus menyiapkan pasangan baru
Mode replikasi	Sinkron atau asinkron	Tidak berlaku (hanya metadata)

Untuk sebagian besar skenario pemulihan bencana, Geo-Replication adalah pilihan yang direkomendasikan karena memberikan perlindungan data lengkap. Pertimbangkan Geo-Disaster Recovery hanya ketika Anda secara khusus memerlukan replikasi khusus metadata.

Geo-Replication dan Pemulihan Bencana Geo mengharuskan Anda secara manual memulai failover atau promosi wilayah sekunder untuk menjadi wilayah utama baru. Microsoft tidak secara otomatis memulai failover atau promosi, meskipun wilayah utama Anda tidak berfungsi.

Namespace pada tingkatan Dasar dan Standar tidak menyertakan fitur multi-wilayah asli, tetapi Anda dapat menerapkan pola replikasi tingkat aplikasi dengan menggunakan beberapa namespace lintas wilayah. Untuk informasi selengkapnya, lihat Solusi multi-wilayah kustom untuk ketahanan.

Geo-Replikasi

Tingkat Premium mendukung Geo-Replication. Fitur ini mereplikasi metadata, seperti entitas, konfigurasi, dan properti, untuk namespace. Ini juga mereplikasi data, seperti pesan di dalam antrean dan topik milik Anda, bersama dengan sifat dan status pesan. Anda mengonfigurasi pendekatan replikasi untuk konfigurasi dan data namespace Anda. Fitur ini memastikan bahwa pesan Anda tetap tersedia di wilayah lain dan memungkinkan Anda beralih ke wilayah sekunder saat diperlukan.

Gunakan Geo-Replication untuk skenario yang memerlukan ketahanan terhadap pemadaman wilayah dan memiliki toleransi rendah untuk kehilangan data pesan.

Namespace secara esensial berlaku di beberapa wilayah. Satu wilayah berfungsi sebagai wilayah utama, dan wilayah lainnya berfungsi sebagai sekunder. Langganan Azure Anda memperlihatkan satu namespace.

Diagram yang memperlihatkan namespace Service Bus yang dikonfigurasi untuk Geo-Replication yang mencakup dua wilayah. Di bagian atas, aplikasi klien terhubung ke namespace FQDN. Di bawah ini adalah dua wilayah dalam pengaturan horizontal: wilayah utama di sebelah kiri dan wilayah sekunder di sebelah kanan. Setiap wilayah berisi namespace Service Bus dengan metadata dan bagian data pesan. Panah dua arah antara wilayah menunjukkan replikasi metadata konfigurasi dan data pesan. Selama operasi normal, namespace layanan FQDN merutekan ke wilayah utama. Selama promosi, FQDN mengalihkan ke wilayah sekunder, yang menjadi wilayah utama yang baru, sementara wilayah utama yang lama menjadi wilayah sekunder.

Kapan saja, Anda dapat mempromosikan wilayah sekunder ke wilayah utama. Saat Anda mempromosikan wilayah sekunder, Azure Service Bus menunjuk kembali nama domain namespace yang sepenuhnya memenuhi syarat (FQDN) ke wilayah sekunder yang dipilih dan menurunkan wilayah utama sebelumnya ke wilayah sekunder. Anda memutuskan apakah akan melakukan promosi yang direncanakan, yang berarti Anda menunggu replikasi data selesai, atau promosi paksa, yang dapat mengakibatkan kehilangan data.

Nota

Service Bus Geo-Replication menggunakan istilah promosi karena paling baik mewakili proses mempromosikan wilayah sekunder ke wilayah utama (dan kemudian menurunkan wilayah utama ke wilayah sekunder). Istilah failover juga digunakan untuk menjelaskan proses umum ini.

Bagian ini merangkum aspek-aspek penting dari Geo-Replikasi. Tinjau dokumentasi lengkap untuk mempelajari cara kerjanya. Untuk informasi selengkapnya, lihat Replikasi Geografis Service Bus.

Persyaratan

• Dukungan wilayah: Anda dapat memilih wilayah Azure apa pun yang mendukung Service Bus sebagai wilayah utama atau sekunder Anda. Anda tidak perlu menggunakan wilayah berpasangan Azure, jadi pilih wilayah sekunder berdasarkan persyaratan latensi, kepatuhan, atau residensi data Anda.

• Tier: Untuk mengaktifkan Geo-Replication, namespace Anda harus menggunakan tingkat Premium.

• Pemulihan Bencana Geo Metadata: Anda tidak dapat mengonfigurasi namespace untuk menggunakan replikasi-geo dan pemulihan bencana geo.

Pertimbangan

• Batasan fitur: Saat Anda mengaktifkan Geo-Replikasi, beberapa batasan berlaku. Untuk informasi selengkapnya, lihat Replikasi Geografis Service Bus.

• Titik akhir privat: Jika Anda menggunakan titik akhir privat untuk menyambungkan ke namespace, Anda juga harus mengonfigurasi jaringan di wilayah utama dan sekunder Anda. Untuk informasi selengkapnya, lihat Endpoint privat.

Biaya

Untuk mempelajari cara kerja harga untuk Geo-Replikasi, lihat Harga.

Mengonfigurasi dukungan multiregional

• Aktifkan Geo-Replication pada namespace baru. Untuk mengaktifkan Geo-Replication pada namespace selama pembuatan, lihat Menyiapkan Geo-Replikasi.

• Migrasikan metadata dari Pemulihan Bencana Geo ke Geo-Replikasi.Beralih dari pemakaian metadata Pemulihan Bencana Geo ke Geo-Replikasi.

• Ubah pendekatan replikasi. Untuk beralih antara mode replikasi sinkron dan asinkron, lihat Beralih mode replikasi.

• Nonaktifkan Geo-Replikasi. Untuk menonaktifkan Geo-Replication untuk wilayah sekunder, lihat Menghapus wilayah sekunder.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan ketika namespace Service Bus dikonfigurasi untuk Geo-Replication dan wilayah utama beroperasi.

• Perutean lalu lintas antar wilayah: Aplikasi klien terhubung melalui FQDN untuk namespace Anda, dan rute lalu lintas mereka ke wilayah utama.

  Hanya wilayah utama yang secara aktif memproses pesan dari klien selama operasi normal. Wilayah sekunder menerima pesan yang direplikasi tetapi sebaliknya tetap dalam mode siaga.

• Replikasi data antar wilayah: Perilaku replikasi data antara wilayah utama dan sekunder tergantung pada apakah pasangan replikasi Anda menggunakan replikasi sinkron atau asinkron.

  • Sinkron: Pesan direplikasi ke wilayah sekunder sebelum operasi tulis selesai.

    Mode ini memberikan jaminan terbesar bahwa data pesan Anda aman karena harus dicatat di wilayah utama dan sekunder. Tetapi replikasi sinkron secara substansial meningkatkan latensi tulis untuk pesan masuk. Ini juga mengharuskan wilayah sekunder tersedia untuk menerima operasi tulis, sehingga pemadaman di wilayah sekunder menyebabkan operasi tulis gagal.

  • Asynchronous: Layanan menulis pesan ke wilayah utama lalu menyelesaikan operasi tulis. Beberapa saat kemudian, pesan akan direplikasi ke wilayah sekunder.

    Mode ini menyediakan throughput tulis yang lebih tinggi daripada replikasi sinkron karena tidak ada latensi replikasi antar-wilayah selama operasi tulis. Ini juga dapat mentolerir hilangnya wilayah sekunder sambil tetap mengizinkan operasi tulis di wilayah utama. Tetapi jika pemadaman terjadi di wilayah utama, data apa pun yang tidak direplikasi ke wilayah sekunder mungkin tidak tersedia atau hilang.

    Saat mengonfigurasi replikasi asinkron, Anda mengatur waktu jeda maksimum yang dapat diterima untuk replikasi. Kapan saja, Anda dapat memverifikasi jeda replikasi saat ini dengan menggunakan metrik Azure Monitor.

    Jika lag replikasi asinkron meningkat melebihi maksimum yang Anda tentukan, wilayah utama mulai membatasi permintaan masuk sehingga replikasi dapat mengejar ketinggalan. Untuk menghindari situasi ini, pilih wilayah sekunder yang tidak terlalu jauh secara geografis dan pastikan kapasitas Anda cukup untuk throughput.

    Beberapa jenis metadata direplikasi secara sinkron bahkan ketika Anda memilih mode replikasi asinkron.

    Untuk informasi selengkapnya, lihat Mode replikasi.

Perilaku selama pemadaman wilayah

Bagian ini menjelaskan apa yang diharapkan ketika namespace Service Bus dikonfigurasi untuk Geo-Replication dan ada pemadaman di wilayah utama atau sekunder.

• Deteksi dan respons: Anda bertanggung jawab untuk memutuskan kapan harus mempromosikan wilayah sekunder namespace Anda untuk menjadi wilayah utama baru. Microsoft tidak membuat keputusan ini atau memulai proses atas nama Anda, meskipun ada gangguan regional. Untuk kriteria yang perlu dipertimbangkan saat memutuskan apakah akan gagal, lihat Skenario yang direkomendasikan untuk memicu promosi.

  Untuk informasi selengkapnya tentang cara mempromosikan wilayah sekunder ke primer baru, lihat Alur promosi.

  Saat Anda mempromosikan wilayah sekunder, pilih antara promosi yang direncanakan atau promosi paksa. Promosi yang direncanakan menunggu wilayah sekunder mengejar ketinggalan sebelum menerima lalu lintas baru. Pendekatan ini mencegah kehilangan data tetapi menghasilkan waktu henti.

  Selama pemadaman di wilayah utama, Anda biasanya perlu melakukan promosi paksa. Jika wilayah utama tersedia dan Anda melakukan promosi karena alasan lain, Anda bisa memilih promosi terencana sebagai alternatif.

• Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

• Permintaan aktif: Perilaku tergantung pada apakah pemadaman wilayah terjadi di wilayah utama atau wilayah sekunder:

  • Pemadaman wilayah utama: Jika wilayah utama tidak tersedia, semua permintaan aktif dihentikan. Aplikasi klien harus mencoba kembali operasi setelah promosi selesai.

  • Pemadaman wilayah sekunder: Pemadaman di wilayah sekunder dapat menyebabkan masalah untuk permintaan aktif dalam situasi berikut:

    • Jika Anda menggunakan mode replikasi sinkron, wilayah utama tidak dapat menyelesaikan operasi tulis jika wilayah sekunder tidak tersedia.

    • Jika Anda menggunakan mode replikasi asinkron, namespace Anda akan menahan dan tidak menerima pesan baru setelah waktu jeda replikasi mencapai maksimum yang Anda konfigurasikan.

    Untuk melanjutkan penggunaan namespace layanan di wilayah utama, hapus namespace sekunder dari konfigurasi Geo-Replication Anda.

• Kehilangan data yang diharapkan: Jumlah kehilangan data tergantung pada apakah Anda melakukan promosi yang direncanakan atau dipaksakan dan apakah mode replikasi sinkron atau asinkron:

  • Promosi yang direncanakan: Tidak ada kehilangan data yang diharapkan. Tetapi selama pemadaman wilayah, promosi yang direncanakan mungkin tidak dimungkinkan karena mengharuskan semua wilayah utama dan sekunder tersedia.

  • Promosi paksa, replikasi sinkron: Tidak ada kehilangan data yang diharapkan.

  • Promosi paksa, replikasi asinkron: Anda mungkin mengalami beberapa kehilangan data untuk pesan terbaru yang tidak direplikasi ke wilayah sekunder dan untuk perubahan status yang tidak direplikasi. Jumlahnya tergantung pada jeda replikasi. Untuk memverifikasi lag replikasi saat ini, gunakan metrik Azure Monitor.

  Jika Anda melakukan promosi paksa, Anda tidak dapat memulihkan data yang hilang, bahkan setelah wilayah utama tersedia.

• Waktu henti yang diharapkan: Jumlah waktu henti yang diharapkan tergantung pada apakah Anda melakukan promosi yang direncanakan atau dipaksakan:

  • Promosi yang direncanakan: Langkah pertama dalam promosi yang direncanakan mereplikasi data ke wilayah sekunder. Proses itu biasanya selesai dengan cepat, tetapi dalam beberapa situasi, mungkin perlu waktu hingga panjang jeda replikasi. Setelah replikasi selesai, proses promosi biasanya memakan waktu sekitar 5 hingga 10 menit. Terkadang perlu waktu lebih lama bagi server Sistem Nama Domain (DNS) untuk memperbarui entri dan sepenuhnya mereplikasi catatan mereka ke klien.

    Wilayah utama tidak menerima operasi tulis selama proses promosi berlangsung.

    Opsi ini mungkin tidak dimungkinkan selama pemadaman wilayah karena mengharuskan semua wilayah primer dan sekunder tersedia.

  • Promosi paksa: Selama promosi paksa, Service Bus tidak menunggu replikasi data selesai dan segera memulai promosi. Proses promosi biasanya memakan waktu sekitar 5 hingga 10 menit. Terkadang perlu waktu lebih lama agar entri DNS sepenuhnya direplikasi dan diperbarui di seluruh klien.

    Wilayah utama tidak menerima operasi tulis selama proses promosi berlangsung.

• Pengalihan lalu lintas: Setelah promosi selesai, FQDN namespace menunjuk ke wilayah utama baru. Tetapi pengalihan ini tergantung pada seberapa cepat rekaman DNS klien diperbarui, termasuk apakah server DNS mereka mematuhi batas waktu hidup (TTL) rekaman DNS namespace.

Pemulihan wilayah

Setelah wilayah utama asli pulih, jika Anda ingin memulihkan namespace ke wilayah tersebut, ikuti proses promosi wilayah yang sama.

Jika Anda melakukan promosi paksa selama pemadaman wilayah, Anda tidak dapat memulihkan data yang hilang, bahkan setelah wilayah utama tersedia.

Pengujian untuk mendeteksi kegagalan wilayah

Untuk menguji Geo-Replikasi, promosikan sementara wilayah sekunder ke primer dan validasi bahwa aplikasi klien Anda dapat beralih antar wilayah dengan gangguan minimal.

Pantau durasi promosi dan pastikan bahwa runbook dan otomatisasi Anda berfungsi dengan benar. Setelah pengujian, Anda dapat mengembalikan ke konfigurasi asli.

Pahami potensi waktu henti dan kehilangan data yang mungkin Anda alami selama dan setelah proses promosi. Uji Geo-Replication di lingkungan nonproduksi yang mencerminkan konfigurasi namespace produksi Anda.

Pemulihan Metadata Bencana Geologi

Tingkat Premium mendukung metadata Geo-Disaster Recovery. Fitur ini meningkatkan pemulihan dari skenario bencana, termasuk kerugian bencana suatu wilayah. Geo-Disaster Recovery hanya mereplikasi konfigurasi dan metadata namespace Anda, dan tidak mereplikasi data pesan. Untuk mendukung pemulihan bencana, fitur ini memastikan bahwa namespace layanan di wilayah lain telah dikonfigurasi sebelumnya dan siap untuk segera menerima pesan dari klien. Geo-Disaster Recovery berfungsi sebagai solusi pemulihan satu arah dan tidak mendukung failback ke wilayah utama sebelumnya.

Metadata Geo-Disaster Recovery berfungsi paling baik untuk aplikasi yang tidak benar-benar perlu mempertahankan setiap pesan dan dapat mentolerir beberapa kehilangan data selama skenario bencana. Metadata Geo-Disaster Recovery mungkin juga sesuai untuk aplikasi yang mereplikasi data itu sendiri, atau yang tidak memerlukan replikasi data. Misalnya, ketika pesan berisi gambar besar yang nantinya Anda konversi menjadi gambar mini, kehilangan beberapa pesan dari wilayah yang gagal mungkin dapat diterima jika Anda dapat dengan cepat melanjutkan pemrosesan pesan baru di wilayah lain dan membangun kembali pesan yang hilang nanti.

Penting

Geo-Disaster Recovery memungkinkan kelangsungan operasi yang memiliki konfigurasi yang sama tetapi tidak mereplikasi data pesan. Jika Anda harus mereplikasi data pesan, pertimbangkan untuk menggunakan Geo-Replikasi.

Saat mengonfigurasi metadata Geo-Disaster Recovery, Anda membuat alias yang digunakan untuk menghubungkan aplikasi klien. Alias adalah FQDN yang mengarahkan semua lalu lintas ke namespace utama secara default.

Diagram yang memperlihatkan aplikasi klien di bagian atas yang tersambung ke alias. Di bawah ini adalah dua wilayah yang diatur secara horizontal. Wilayah utama di sebelah kiri berisi namespace utama dengan metadata dan bagian data pesan. Wilayah sekunder di sebelah kanan berisi namespace sekunder dengan bagian metadata. Panah bertitik berlabel metadata replikasi asinkron hanya menunjuk dari bagian metadata di namespace utama ke bagian metadata di namespace sekunder. Alias merutekan lalu lintas klien ke namespace utama selama operasi normal dan mengalihkan ke namespace sekunder selama failover.

Jika wilayah utama gagal atau jenis bencana lain terjadi, Anda dapat memulai perpindahan failover satu arah secara manual dari wilayah utama ke wilayah sekunder kapan saja. Anda dapat melakukan failover yang aman dengan menunggu replikasi selesai sebelum beralih ke server sekunder. Opsi ini mungkin tidak tersedia selama pemadaman wilayah. Setelah failover dimulai, proses tersebut selesai hampir seketika. Selama proses failover, alias Geo-Disaster Recovery mengarah ke namespace sekunder dan pemasangan pasangan ditiadakan.

Bagian ini merangkum aspek penting Geo-Disaster Recovery. Tinjau dokumentasi lengkap untuk mempelajari cara kerjanya. Untuk informasi selengkapnya, lihat Service Bus Geo-Disaster Recovery.

Persyaratan

• Dukungan wilayah: Anda dapat memilih wilayah Azure apa pun yang mendukung Service Bus sebagai namespace layanan utama atau sekunder Anda. Anda tidak perlu menggunakan wilayah berpasangan Azure, jadi pilih wilayah sekunder berdasarkan persyaratan latensi, kepatuhan, atau residensi data Anda.

• Tier: Untuk mengaktifkan metadata Geo-Disaster Recovery, kedua namespace harus menggunakan tingkat Premium.

• Partisi: Tidak dimungkinkan untuk memasangkan namespace yang dipartisi dengan namespace yang tidak dipartisi.

• Pemulihan Bencana Geo Metadata: Anda tidak dapat mengonfigurasi namespace untuk menggunakan replikasi-geo dan pemulihan bencana geo.

Pertimbangan

• Batasan fitur: Saat Anda mengaktifkan Geo-Disaster Recovery, beberapa batasan berlaku. Untuk informasi selengkapnya, lihat Poin penting untuk dipertimbangkan dan Pertimbangan.

• Penetapan peran: Penetapan kontrol akses berbasis peran (RBAC) Microsoft Entra ke entitas di namespace utama tidak akan direplikasi ke namespace sekunder. Buat penetapan peran secara manual di namespace sekunder untuk mengamankan akses ke entitas tersebut.

• Desain aplikasi: Geo-Disaster Recovery memerlukan pertimbangan khusus saat Anda merancang aplikasi klien Anda. Untuk informasi selengkapnya, lihat Pertimbangan .

• Titik akhir privat: Jika Anda menggunakan titik akhir privat untuk menyambungkan ke namespace Anda, konfigurasikan jaringan di wilayah utama dan sekunder Anda. Untuk informasi selengkapnya, lihat Endpoint privat.

• Namespace yang dimigrasikan dari Standar ke Premium: Jika namespace Anda berada di tingkat Standar dan Anda memigrasikannya ke tingkat Premium, Anda harus menangani alias secara berbeda. Untuk informasi selengkapnya, lihat Service Bus Standard menjadi Premium.

Biaya

Saat Anda mengaktifkan metadata Geo-Disaster Recovery, Anda membayar untuk baik namespace primer maupun sekunder.

Mengonfigurasi dukungan multiregional

• Buat pemasangan Geo-Disaster Recovery metadata. Untuk mengonfigurasi disaster recovery antara namespace primer dan sekunder, lihat Setup dan alur failover.

• Nonaktifkan pemulihan bencana geo metadata. Untuk memutuskan hubungan di antara namespace, lihat Penyiapan dan alur failover.

Perencanaan dan manajemen kapasitas

Saat Anda merencanakan penyebaran multi-wilayah, pastikan kedua wilayah memiliki kapasitas yang memadai untuk menangani beban penuh jika satu wilayah gagal. Wilayah sekunder tetap pasif selama operasi normal, tetapi harus segera menangani lalu lintas setelah failover. Rencanakan cara menskalakan kapasitas namespace sekunder sehingga dapat menerima lalu lintas produksi tanpa penundaan. Jika Anda dapat mentolerir waktu henti ekstra selama proses failover, Anda dapat menskalakan kapasitas namespace sekunder selama atau setelah failover. Untuk mengurangi waktu henti, provisikan kapasitas di namespace sekunder terlebih dahulu sehingga tetap siap menerima beban produksi.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan ketika namespace Service Bus dikonfigurasi untuk Geo-Disaster Recovery dan wilayah utama beroperasi.

• Pemilihan jalur lalu lintas antar wilayah: Aplikasi klien terhubung menggunakan alias Pemulihan Bencana Geo untuk namespace Anda, dan lalu lintasnya diarahkan ke namespace utama di wilayah utama.

  Hanya namespace utama yang secara aktif memproses pesan dari klien selama operasi normal. Namespace layanan sekunder tetap dalam mode siaga, dan permintaan apa pun untuk mengakses data gagal.

• Replikasi data antar wilayah: Hanya metadata konfigurasi yang mereplikasi antara namespace. Replikasi konfigurasi terjadi terus menerus dan asinkron.

  Semua data pesan tetap berada di namespace utama saja dan tidak direplikasi ke namespace sekunder.

Perilaku selama pemadaman wilayah

Bagian ini menjelaskan apa yang diharapkan ketika namespace Service Bus dikonfigurasi untuk Geo-Disaster Recovery dan ada pemadaman di wilayah utama.

• Deteksi dan respons: Anda bertanggung jawab untuk memantau kesehatan wilayah dan memulai failover secara manual. Microsoft tidak memulai failover atau mempromosikan wilayah sekunder secara otomatis, meskipun wilayah utama Anda tidak berfungsi.

  Untuk informasi selengkapnya tentang cara memulai failover, lihat Alur failover.

  Saat Anda memulai failover, pilih apakah akan melakukan failover aman atau failover standar, seperti failover paksa atau manual. Failover yang aman akan menunggu hingga replikasi ke wilayah sekunder selesai sebelum memulai failover. Pendekatan ini mengurangi hilangnya metadata tetapi memperkenalkan waktu henti. Failover aman mengharuskan namespace berada dalam langganan Azure yang sama.

  Selama pemadaman di wilayah utama, Anda biasanya harus melakukan failover paksa. Jika wilayah utama tersedia dan Anda memicu failover karena alasan lain, Anda dapat memilih failover yang direncanakan.

  Failover adalah operasi satu arah, jadi Anda harus membangun kembali pasangan Geo-Disaster Recovery nanti. Untuk informasi selengkapnya, lihat Pemulihan wilayah.

• Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

• Permintaan aktif: Permintaan aktif yang sedang berlangsung berakhir ketika failover dimulai. Aplikasi klien harus mencoba kembali operasi setelah failover selesai.

• Kehilangan data yang diharapkan:

  • Metadata: Konfigurasi dan metadata biasanya direplikasi ke namespace sekunder. Replikasi metadata terjadi secara asinkron, sehingga perubahan terbaru mungkin tidak mereplikasi, terutama perubahan kompleks. Verifikasi konfigurasi namespace sekunder Anda sebelum klien mengaksesnya.

  • Data pesan: Data pesan tidak mereplikasi antar wilayah. Jika wilayah utama tidak berfungsi, pesan di namespace utama Anda menjadi tidak tersedia.

    Pesan tidak hilang secara permanen kecuali bencana besar menyebabkan kehilangan total regional utama. Jika wilayah pulih, Anda dapat mengambil pesan dari namespace utama nanti.

• Waktu henti yang diharapkan: Failover biasanya terjadi dalam waktu 5 hingga 10 menit. Dibutuhkan waktu lebih lama bagi klien untuk sepenuhnya mereplikasi dan memperbarui entri DNS.

• Pengalihan lalu lintas: Klien yang menggunakan alias Geo-Disaster Recovery untuk terhubung ke namespace secara otomatis mengarahkannya ke namespace sekunder setelah failover. Tetapi pengalihan ini tergantung pada server DNS yang mematuhi TTL catatan DNS namespace dan klien yang menerima catatan DNS yang diperbarui tersebut.

Pemulihan wilayah

Setelah wilayah utama asli pulih, Anda harus membangun kembali pasangan secara manual dan dengan opsi melakukan failback. Buat pasangan Geo-Disaster Recovery baru dengan wilayah yang baru dipulihkan sebagai wilayah sekunder, lalu lakukan failover lain jika Anda ingin kembali ke wilayah asal. Proses ini melibatkan potensi kehilangan data pesan yang dikirim ke namespace utama sementara.

Jika bencana menyebabkan hilangnya semua zona di wilayah utama, data Anda mungkin tidak dapat dipulihkan. Dalam skenario lain, data pesan yang tetap berada di namespace utama dari sebelum failover dapat dipulihkan. Anda dapat memperoleh pesan historis dari namespace utama lama setelah memulihkan akses. Anda bertanggung jawab untuk mengonfigurasi aplikasi Anda untuk menerima dan memproses pesan tersebut. Microsoft tidak secara otomatis memulihkannya ke wilayah sekunder Anda.

Pengujian untuk mendeteksi kegagalan wilayah

Untuk menguji proses respons dan pemulihan bencana Anda, lakukan failover yang direncanakan selama jendela pemeliharaan. Mulai failover dari namespace utama ke namespace sekunder Anda dan verifikasi bahwa aplikasi Anda dapat menyambungkan dan memproses pesan dari namespace utama baru.

Pantau durasi failover dan pastikan bahwa runbook serta otomatisasi milik Anda berfungsi dengan benar. Setelah pengujian, Anda dapat mengembalikan ke konfigurasi asli.

Pahami potensi waktu henti dan kehilangan data yang mungkin Anda alami selama dan setelah proses failover. Uji metadata Pemulihan Geo-Bencana di lingkungan nonproduksi yang mencerminkan konfigurasi namespace produksi Anda.

Solusi multi-wilayah kustom untuk ketahanan

Geo-Replication dan metadata Geo-Disaster Recovery memberikan ketahanan terhadap pemadaman wilayah dan masalah lainnya, dan cocok untuk sebagian besar beban kerja. Kemampuan ini mungkin tidak sesuai dengan kebutuhan Anda dalam situasi berikut:

• Anda memiliki persyaratan untuk replikasi kustom atau untuk mempertahankan beberapa wilayah aktif secara bersamaan.

• Anda menggunakan tingkat Bus Layanan yang tidak mendukung fitur-fitur ini.

Ada beberapa pola desain yang menyediakan berbagai jenis dukungan multi-wilayah di Azure Service Bus. Banyak dari pola ini mengharuskan Anda untuk menerapkan beberapa namespace dan mengonfigurasi aplikasi Anda untuk menggunakannya dengan tepat. Untuk informasi selengkapnya, lihat sumber daya berikut ini:

• Melindungi aplikasi Service Bus dari pemadaman dan bencana
• Replikasi pesan dan federasi lintas wilayah

Ketahanan terhadap pemeliharaan layanan

Service Bus melakukan pemeliharaan rutin. Selama pemeliharaan terencana, namespace dipindahkan ke simpul redundan yang berisi pembaruan terbaru. Selama pemindahan, SDK klien terputus dan kemudian terhubung kembali secara otomatis ke namespace. Peningkatan biasanya selesai dalam waktu 30 detik. Penting bahwa aplikasi Anda disiapkan untuk pemutusan jaringan sementara yang mungkin terjadi selama periode pemeliharaan.

Untuk informasi selengkapnya, lihat Peristiwa pemeliharaan Azure untuk Service Bus.

Pencadangan dan pemulihan

Azure Service Bus tidak dirancang untuk penyimpanan data jangka panjang. Data biasanya disimpan dalam topik atau antrian hanya untuk waktu yang singkat. Kemudian diproses atau disimpan ke sistem penyimpanan data lain lalu dihapus. Karena desain ini, Service Bus secara otomatis mempertahankan replika data pesan tetapi tidak menyediakan kemampuan pencadangan dan pemulihan untuk data tersebut.

Untuk skenario yang memerlukan retensi pesan jangka panjang, pertimbangkan untuk menerapkan pengarsipan tingkat aplikasi ke Azure Storage atau layanan penyimpanan tahan lama lainnya.

Perjanjian tingkat layanan

Perjanjian tingkat layanan (SLA) untuk layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.

Service Bus menyediakan SLA untuk semua namespace. SLA ketersediaan lebih tinggi saat namespace Anda memenuhi kriteria berikut:

• Ini menggunakan tingkat Premium.
• Ini terletak di wilayah yang memiliki zona ketersediaan.
• Ini menggunakan sistem partisi.

Konten terkait

• Pengantar Service Bus
• Pemulihan Geo-Bencana Service Bus
• Replikasi Geografis Azure Service Bus