Bagikan melalui

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. Ketahanan terhadap pemadaman sumber daya pemrosesan data akibat bencana adalah persyaratan bagi banyak perusahaan dan, dalam beberapa kasus, bahkan diperlukan oleh peraturan industri. Artikel ini menjelaskan teknik yang dapat Anda gunakan untuk melindungi aplikasi Bus Layanan dari potensi gangguan layanan atau bencana.

Azure Bus Layanan sudah menyebarkan risiko kegagalan bencana pada masing-masing mesin atau bahkan menyelesaikan rak di seluruh kluster yang mencakup beberapa domain kegagalan dalam pusat data dan menerapkan deteksi kegagalan transparan dan mekanisme failover sehingga layanan terus beroperasi dalam tingkat layanan yang terjaga dan biasanya tanpa gangguan yang nyata ketika kegagalan tersebut terjadi.

Selain itu, risiko pemadaman semakin tersebar di tiga fasilitas yang dipisahkan secara fisik (zona ketersediaan), dan layanan memiliki cadangan kapasitas yang cukup untuk segera mengatasi hilangnya pusat data yang lengkap dan mengerikan. Model kluster Azure Bus Layanan yang aktif dalam domain kegagalan bersama dengan dukungan zona ketersediaan lebih unggul daripada produk broker pesan lokal dalam hal ketahanan terhadap kegagalan perangkat keras yang berat dan bahkan kehilangan seluruh fasilitas pusat data yang mengerikan. Namun, mungkin ada situasi mengerikan dengan kehancuran fisik meluas yang bahkan langkah-langkah tersebut tidak cukup dapat mencegahnya.

Fitur Bus Layanan Geo-Disaster Recovery dan Geo-Replication dirancang untuk mempermudah pemulihan dari bencana sebesar ini dan meninggalkan wilayah Azure yang gagal untuk selamanya dan tanpa harus mengubah konfigurasi aplikasi Anda.

Pemadaman dan bencana

Penting untuk dicatat perbedaan antara "pemadaman" dan "bencana."

Pemadaman adalah tidak tersedianya Azure Service Bus untuk sementara, dan dapat memengaruhi beberapa komponen layanan, seperti toko olahpesan, atau bahkan seluruh pusat data. Namun, setelah masalah diperbaiki, Service Bus akan tersedia lagi. 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. Beberapa pemadaman hanya kehilangan koneksi sementara karena masalah sementara atau jaringan.

Bencana didefinisikan sebagai kerugian permanen, atau kehilangan jangka panjang atas kluster Service Bus, wilayah Azure, atau pusat data. Wilayah atau pusat data mungkin atau mungkin tidak tersedia lagi, atau mungkin tidak berfungsi selama berjam-jam atau berjam-hari. Contoh bencana tersebut adalah kebakaran, banjir, atau gempa bumi. A disaster that becomes permanent might cause the loss of some messages, events, or other data. Namun, dalam kebanyakan kasus seharusnya tidak ada kehilangan data dan pesan dapat dipulihkan setelah pusat data muncul kembali.

Perlindungan terhadap pemadaman dan bencana

Ada dua fitur yang menyediakan Pemulihan Bencana Geografis di Azure Bus Layanan untuk tingkat Premium. Pertama, ada Geo-Disaster Recovery (Metadata DR) yang menyediakan replikasi metadata (entitas, konfigurasi, properti). Kedua, ada Geo-Replikasi, yang saat ini dalam pratinjau publik, memberikan replikasi metadata dan data (data pesan dan properti pesan / perubahan status) itu sendiri. Fitur Pemulihan Bencana Geografis tidak boleh dikacaukan dengan Zona Ketersediaan. Terlepas dari apakah itu Metadata DR atau Replikasi geografis, kedua fitur pemulihan geo-grafis memberikan ketahanan antara wilayah Azure seperti AS Timur dan AS Barat.

Zona Ketersediaan tersedia di semua tingkat Bus Layanan, dan dukungan memberikan ketahanan dalam wilayah geografis tertentu, seperti AS Timur. Untuk diskusi terperinci tentang pemulihan bencana di Microsoft Azure, lihat artikel ini.

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

Opsi Pemulihan Bencana Geografis

Pemulihan Bencana Geografis

Bus Layanan tingkat premium mendukung Pemulihan Bencana Geografis, di tingkat namespace layanan. Untuk informasi selengkapnya, lihat Azure Bus Layanan Geo-Disaster Recovery. Fitur Pemulihan Bencana Geografis, hanya tersedia untuk tingkat 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.

Geo-Replikasi

Bus Layanan tingkat premium juga mendukung Geo-Replication, di tingkat namespace. Untuk informasi selengkapnya, lihat Azure Bus Layanan Geo-Replication (Pratinjau Umum). Fitur Geo-Replikasi, hanya tersedia untuk tingkat Premium dan saat ini dalam pratinjau publik, menerapkan metadata dan pemulihan bencana data, dan bergantung pada wilayah primer dan sekunder. Dengan Geo-Replikasi, metadata dan data untuk entitas direplikasi antara wilayah primer dan sekunder.

Perbedaan fitur tingkat tinggi

Fitur Geo-Disaster Recovery (Metadata DR) mereplikasi metadata untuk namespace layanan dari namespace utama ke namespace sekunder. Ini mendukung satu kali hanya failover ke wilayah sekunder. Selama failover yang dimulai pelanggan, nama alias untuk namespace ditunjukkan kembali ke namespace sekunder dan kemudian pemasangan rusak. Tidak ada data yang direplikasi selain metadata atau penugasan RBAC yang direplikasi.

Fitur Geo-Replikasi mereplikasi metadata dan semua data dari wilayah utama ke satu atau beberapa wilayah sekunder. Ketika failover dilakukan oleh pelanggan, sekunder yang dipilih menjadi primer dan primer sebelumnya menjadi sekunder. Pengguna dapat melakukan failover kembali ke primer asli jika diinginkan.

Zona ketersediaan

Semua tingkat 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 hanya tersedia di wilayah Azure tempat zona ketersediaan ada.

Saat Anda membuat namespace layanan, dukungan untuk zona ketersediaan (jika tersedia di wilayah yang dipilih) secara otomatis diaktifkan untuk namespace layanan. Tidak ada biaya tambahan untuk menggunakan fitur ini dan Anda tidak dapat menonaktifkan atau mengaktifkan fitur ini setelah pembuatan namespace.

Catatan

Sebelumnya diperlukan untuk mengatur properti zoneRedundant ke untuk true mengaktifkan zona ketersediaan, namun perilaku ini telah berubah untuk mengaktifkan zona ketersediaan secara default. Namespace yang ada juga sedang dimigrasikan ke zona ketersediaan, dan properti zoneRedundant tidak digunakan lagi. Properti zoneRedundant mungkin masih ditampilkan sebagai false, bahkan ketika zona ketersediaan telah diaktifkan.

Perlindungan terhadap bencana - tingkat standar

Untuk mencapai ketahanan terhadap bencana dengan tingkat Standar Bus Layanan, 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.

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: