Praktik terbaik untuk mengisolasi aplikasi terhadap gangguan Bus Layanan dan bencana

  • Artikel

Aplikasi misi-kritis harus beroperasi terus menerus, bahkan saat menghadapi gangguan atau bencana yang tidak direncanakan. Artikel ini menjelaskan teknik yang dapat Anda gunakan untuk melindungi aplikasi Bus Layanan dari potensi gangguan layanan atau bencana.

Gangguan didefinisikan sebagai tidak tersedianya Azure Service Bus untuk sementara. Gangguan dapat memengaruhi beberapa komponen Bus Layanan, seperti penyimpanan olahpesan, atau bahkan seluruh pusat data. Namun, setelah masalah diperbaiki, Bus Layanan akan kembali tersedia. Biasanya, pemadaman tidak menyebabkan hilangnya pesan atau data lainnya. Contoh kegagalan komponen adalah tidak tersedianya penyimpanan olahpesan tertentu. Contoh gangguan di seluruh pusat data adalah kegagalan daya pusat data, atau pengalihan jaringan pusat data yang rusak. Gangguan dapat berlangsung dari beberapa menit hingga beberapa hari.

Bencana diartikan sebagai hilangnya unit skala Bus Layanan atau pusat data secara permanen. Pusat data mungkin atau mungkin tidak tersedia lagi. Biasanya bencana menyebabkan hilangnya beberapa atau semua pesan atau data lainnya. Contoh bencana adalah kebakaran, banjir, atau gempa bumi.

Perlindungan terhadap pemadaman dan bencana - tingkat premium

Konsep ketersediaan tinggi dan pemulihan bencana dibangun tepat ke tingkat premium Azure Bus Layanan, baik dalam wilayah yang sama (melalui zona ketersediaan) maupun di berbagai wilayah (melalui Pemulihan bencana geografis).

Pemulihan Bencana Geografis

Bus Layanan tingkat premium mendukung pemulihan bencana geografis, di tingkat namespace layanan. Untuk informasi selengkapnya, lihat Pemulihan bencana geografis Azure Service Bus. Fitur pemulihan bencana, hanya tersedia untuk SKU Premium, menerapkan pemulihan bencana metadata, dan bergantung pada namespace primer dan sekunder. Dengan pemulihan bencana geografis, hanya metadata untuk entitas yang direplikasi antara namespace primer dan sekunder.

Zona ketersediaan

Tingkat premium Bus Layanan mendukung Zona ketersediaan, menyediakan lokasi yang terisolasi kesalahan dalam wilayah Azure yang sama. Bus Layanan mengelola tiga salinan penyimpanan olahpesan (1 primer dan 2 sekunder). Bus Layanan menjaga ketiga salinan tetap sinkron untuk operasi data dan manajemen. Jika salinan primer gagal, salah satu salinan sekunder akan dipromosikan ke primer tanpa waktu henti. Jika aplikasi melihat pemutusan sementara dari Bus Layanan, logika coba lagi di SDK secara otomatis tersambung kembali ke Bus Layanan.

Saat Anda menggunakan zona ketersediaan, metadata dan data (pesan) direplikasi di seluruh pusat data di zona ketersediaan.

Catatan

Dukungan zona ketersediaan untuk tingkat premium hanya tersedia di wilayah Azure tempat zona ketersediaan ada.

Saat Anda membuat namespace tingkat premium melalui portal, dukungan untuk zona ketersediaan (jika tersedia di wilayah yang dipilih) secara otomatis diaktifkan untuk namespace layanan. Saat Anda membuat namespace tingkat premium melalui mekanisme lain, seperti templat Azure Resource Manager / Bicep, CLI, atau PowerShell, properti zoneRedundant harus diatur secara eksplisit ke true untuk mengaktifkan zona ketersediaan (jika tersedia di wilayah yang dipilih). Tidak ada biaya tambahan untuk menggunakan fitur ini dan Anda tidak dapat menonaktifkan atau mengaktifkan fitur ini setelah pembuatan namespace.

Perlindungan terhadap pemadaman dan bencana - tingkat standar

Untuk mencapai ketahanan terhadap pemadaman pusat data dengan tingkat harga olahpesan standar, Anda dapat menggunakan replikasi aktif atau pasif . Untuk setiap pendekatan, jika antrean atau topik yang diberikan harus tetap dapat diakses jika terjadi gangguan pusat data, Anda dapat membuatnya di kedua namespace. Kedua entitas dapat memiliki nama yang sama. Misalnya, antrean primer bisa dicapai di bawah contosoPrimary.servicebus.windows.net/myQueue, sementara rekaman primernya bisa dicapai di bawah contosoSecondary.servicebus.windows.net/myQueue.

Catatan

Replikasi aktif dan penyiapan replikasi pasif adalah solusi tujuan umum dan bukan fitur spesifik Bus Layanan. Logika replikasi (mengirim ke 2 namespace berbeda) ada di aplikasi pengirim dan penerima harus memiliki logika kustom untuk deteksi duplikat.

Jika aplikasi tidak memerlukan komunikasi pengirim-ke-penerima permanen, aplikasi dapat menerapkan antrean sisi klien yang tahan lama untuk mencegah kehilangan pesan dan melindungi pengirim dari kesalahan Bus Layanan sementara.

Replikasi aktif

Replikasi aktif menggunakan entitas di kedua namespace untuk setiap operasi. Setiap klien mengirim pesan dengan mengirim dua salinan pesan yang sama. Salinan pertama dikirim ke entitas primer (misalnya, contosoPrimary.servicebus.windows.net/sales), dan salinan kedua pesan dikirim ke entitas sekunder (misalnya, contosoSecondary.servicebus.windows.net/sales).

Klien menerima pesan dari kedua antrean. Penerima memproses salinan pertama pesan, lalu salinan kedua ditahan. Untuk menyembunyikan pesan duplikat, pengirim harus memberi tag setiap pesan dengan pengidentifikasi unik. Kedua salinan pesan harus diberi tag dengan pengidentifikasi yang sama. Anda dapat menggunakan properti ServiceBusMessage.MessageId atau ServiceBusMessage.Subject , atau properti kustom untuk menandai pesan. Penerima harus mempertahankan daftar pesan yang sudah diterima.

Sampel [geo-replikasi dengan tingkat standar Bus Layanan][Geo-replikasi dengan Bus Layanan Tingkat Standar] menunjukkan replikasi aktif entitas olahpesan.

Catatan

Pendekatan replikasi aktif menggandakan jumlah operasi, karenanya pendekatan ini dapat mengakibatkan biaya yang lebih tinggi.

Replikasi Pasif

Dalam kasus bebas kesalahan, replikasi pasif hanya menggunakan salah satu dari dua entitas olahpesan. Klien mengirim pesan ke entitas aktif. Jika operasi pada entitas aktif gagal dengan kode kesalahan yang menunjukkan pusat data yang menghosting entitas aktif mungkin tidak tersedia, klien mengirim salinan pesan ke entitas cadangan. Pada saat itu, entitas aktif dan cadangan beralih peran. Klien pengirim menganggap entitas aktif lama sebagai entitas cadangan baru, dan entitas cadangan lama adalah entitas aktif baru. Jika kedua operasi pengiriman gagal, peran kedua entitas tetap tidak berubah, dan kesalahan dikembalikan.

Klien menerima pesan dari kedua antrean. Karena ada kemungkinan penerima menerima dua salinan pesan yang sama, penerima harus menekan pesan duplikat. Anda dapat mempertahankan duplikat dengan cara yang sama seperti yang dijelaskan untuk replikasi aktif.

Secara umum, replikasi pasif lebih ekonomis dibandingkan replikasi aktif karena dalam kebanyakan kasus hanya satu operasi yang dilakukan. Latensi, throughput, dan biaya moneter identik dengan skenario yang tidak direplikasi.

Saat Anda menggunakan replikasi pasif, dalam skenario berikut, pesan dapat hilang atau diterima dua kali:

  • Pesan ditunda atau hilang: Asumsikan bahwa pengirim berhasil mengirim pesan m1 ke antrean primer, lalu antrean tidak tersedia sebuah penerima menerima m1. Pengirim mengirim pesan m2 berikutnya ke antrean sekunder. Jika antrean primer untuk sementara tidak tersedia, penerima menerima m1 setelah antrean kembali tersedia. Ketika bencana terjadi, penerima mungkin tidak pernah menerima m1.
  • Penerimaan duplikat: Asumsikan bahwa pengirim mengirimkan pesan m ke antrean primer. Bus Layanan berhasil memproses m tetapi gagal mengirim respons. Setelah operasi pengiriman kehabisan waktu, pengirim mengirimkan salinan m yang identik ke antrean sekunder. Jika penerima dapat menerima salinan pertama m sebelum antrean primer tidak tersedia, penerima menerima kedua salinan m pada waktu yang hampir bersamaan. Jika penerima tidak dapat menerima salinan pertama m sebelum antrean utama menjadi tidak tersedia, penerima awalnya hanya menerima salinan kedua m, tetapi kemudian menerima salinan m kedua ketika antrean utama tersedia.

Azure Messaging Replication Tasks dengan sampel .NET Core menunjukkan replikasi pesan antar namespace.

Langkah berikutnya

Untuk mempelajari selengkapnya tentang pemulihan bencana, lihat artikel ini: