Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Artikel ini menjelaskan dukungan keandalan di Azure Event Hubs, yang mencakup ketahanan intra-regional melalui zona ketersediaan dan penyebaran multi-wilayah.
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.
Azure Event Hubs adalah layanan cloud asli yang dapat mengalirkan jutaan peristiwa per detik dengan latensi rendah, dari sumber apa pun ke tujuan mana pun. Gunakan Azure Event Hubs untuk menyerap dan menyimpan data streaming, dan berintegrasi dengan aplikasi klien yang dibangun untuk Apache Kafka atau aplikasi yang menggunakan SDK klien Azure Event Hubs.
Rekomendasi penyebaran produksi
Untuk mempelajari cara menyebarkan Azure Event Hubs untuk mendukung persyaratan keandalan solusi Anda dan memahami bagaimana keandalan memengaruhi aspek lain dari arsitektur Anda, lihat Praktik terbaik arsitektur untuk Azure Event Hubs di Azure Well-Architected Framework.
Gambaran umum arsitektur keandalan
Bagian ini menjelaskan aspek penting tentang cara kerja Azure Event Hubs dari perspektif keandalan. Ini memperkenalkan arsitektur logis, yang mencakup sumber daya dan fitur yang Anda sebarkan dan gunakan. Ini juga menjelaskan arsitektur fisik, yang memberikan detail tentang bagaimana layanan mengelola operasi secara internal.
Arsitektur logis
Namespace Event Hubs berfungsi sebagai kontainer manajemen untuk satu atau beberapa hub peristiwa. Anda mengonfigurasi layanan, seperti mengalokasikan kapasitas streaming, mengonfigurasi keamanan jaringan, dan mengaktifkan pemulihan ketahanan geografis dan bencana geografis, di tingkat namespace layanan.
Dalam namespace, Anda dapat mengatur peristiwa ke Event Hub. Ekosistem Apache® Kafka mengacu pada jenis entitas ini sebagai topik. Pusat aktivitas atau topik adalah log terdistribusi khusus tambahan dari peristiwa Anda.
Setiap hub peristiwa berisi satu atau beberapa partisi, yang merupakan log peristiwa berurutan. Hub peristiwa dapat menggunakan beberapa partisi untuk melakukan pemrosesan paralel dan penskalaan horizontal. Azure Event Hubs 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 memaksimalkan ketersediaan untuk sebagian besar aplikasi, hindari mengakses partisi secara langsung dari aplikasi klien Anda. Untuk informasi selengkapnya, lihat Ketersediaan dan konsistensi di Azure Event Hubs.
Konsumen yang membaca dari pusat aktivitas dapat membaca peristiwa mereka secara berurutan dengan mempertahankan titik pemeriksaan mereka sendiri, yang mengidentifikasi peristiwa terakhir yang mereka terima.
Untuk informasi selengkapnya tentang partisi dan konsep dasar lainnya di Azure Event Hubs, lihat Fitur dan terminologi di Azure Event Hubs.
Arsitektur fisik
Dalam arsitektur fisik, namespace Layanan Pusat Aktivitas berjalan dalam kluster. Kluster menyediakan sumber daya komputasi dan penyimpanan yang mendasar. Sebagian besar namespace berjalan pada kluster yang dibagikan pelanggan Azure lainnya. Saat Anda menggunakan tingkat Premium, namespace dialokasikan sumber daya khusus dalam kluster bersama. Saat Anda menggunakan Dedicated tier, sebuah kluster didedikasikan untuk namespace Anda. Untuk informasi selengkapnya tentang kluster khusus, lihat Gambaran umum tingkat Khusus Azure Event Hubs. Terlepas dari jenis tingkat dan kluster, Microsoft mengelola kluster dan komputer virtual dan penyimpanan yang mendasarnya.
Untuk mencapai redundansi, setiap kluster memiliki beberapa replika yang memproses permintaan baca dan tulis. Untuk ketersediaan tinggi dan pengoptimalan performa, semua data disimpan pada tiga replika penyimpanan. Untuk menskalakan sumber daya komputasi namespace Anda, sebarkan unit throughput (TU), unit pemrosesan (PUs), atau unit kapasitas (CUs), tergantung pada tingkatannya. Untuk informasi lebih lanjut, lihat Scaling with Azure Event Hubs.
Kluster mencakup beberapa komputer fisik dan rak, yang mengurangi risiko kegagalan bencana yang memengaruhi namespace Anda. Di wilayah yang memiliki zona availabilitas, kluster mencakup beberapa pusat data fisik yang terpisah. Untuk informasi selengkapnya, lihat Dukungan zona ketersediaan.
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.
Azure Event Hubs menerapkan deteksi kegagalan transparan dan mekanisme failover sehingga layanan terus beroperasi dalam tingkat layanan yang terjaga, biasanya tanpa gangguan yang nyata ketika kegagalan terjadi.
Saat Anda merancang aplikasi klien untuk bekerja dengan Azure Event Hubs, ikuti panduan ini:
Gunakan kebijakan retry bawaan. Event Hubs dan Apache Kafka SDK secara otomatis mencoba kembali operasi untuk kesalahan yang dapat diulang seperti batas waktu jaringan, respons pembatasan, atau saat server sibuk. Untuk menghindari kelebihan beban layanan yang tidak perlu, mereka menerapkan backoff eksponensial secara default.
Konfigurasikan nilai batas waktu yang sesuai berdasarkan persyaratan aplikasi Anda. Batas waktu default biasanya 60 detik, tetapi Anda dapat menyesuaikannya berdasarkan skenario Anda.
Terapkan titik pemeriksaan di prosesor peristiwa Anda untuk melacak kemajuan dan mengaktifkan pemulihan dari posisi terakhir yang diproses setelah kegagalan sementara.
Gunakan batching untuk mengirim operasi untuk meningkatkan throughput dan mengurangi dampak masalah jaringan sementara pada pesan individual.
Gunakan Apache Kafka SDK jika Anda bekerja dengan protokol Kafka. Kafka SDK juga menerapkan kebijakan coba lagi dan praktik terbaik lainnya yang membantu menangani kesalahan sementara.
Dukungan 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 Event Hubs mendukung penyebaran zona-redundan di semua tingkat layanan. Saat Anda membuat namespace Layanan Pusat Aktivitas di wilayah yang didukung, redundansi zona secara otomatis diaktifkan tanpa biaya tambahan. Tetapi, pada tingkat Terdedikasi, zona ketersediaan hanya didukung dengan syarat minimal tiga CUs. Model penyebaran zona-redundan berlaku untuk semua fitur Azure Event Hubs, termasuk dukungan protokol Capture, Schema Registry, dan Kafka.
Azure Event Hubs secara transparan mereplikasi konfigurasi, metadata, dan data peristiwa Anda di tiga zona ketersediaan di wilayah tersebut. Redundansi zona menyediakan failover otomatis tanpa intervensi apa pun yang diperlukan dari Anda. Semua komponen Azure Event Hubs termasuk komputasi, jaringan, dan penyimpanan direplikasi di seluruh zona. Azure Event Hubs memiliki cadangan kapasitas yang cukup untuk segera menangani hilangnya seluruh zona. Bahkan jika seluruh zona ketersediaan menjadi tidak tersedia, Azure Event Hubs terus beroperasi tanpa kehilangan data atau gangguan pada aplikasi streaming.
Diagram menunjukkan kluster Azure Event Hubs yang didistribusikan di tiga zona ketersediaan. Setiap zona berisi namespace bersama, dan kluster mencakup semua zona untuk memberikan ketersediaan tinggi.
Dukungan wilayah
Namespace Event Hubs yang mendukung redundansi zona dapat disebarkan ke wilayah Azure mana pun yang mendukung zona ketersediaan.
Persyaratan
Tingkat Standar dan Premium mendukung zona ketersediaan tanpa konfigurasi tambahan yang diperlukan.
Untuk tingkat Dedicated, zona ketersediaan memerlukan minimal tiga CU.
Biaya
Redundansi zona di Azure Event Hubs tidak menambahkan biaya tambahan.
Mengonfigurasi dukungan zona ketersediaan
Namespace layanan Azure Event Hubs secara otomatis mendukung redundansi zona saat disebarkan di wilayah yang didukung. Tidak diperlukan konfigurasi lainnya.
Operasi normal
Saat namespace Azure Event Hubs menggunakan redundansi zona dan semua zona ketersediaan beroperasi secara normal, harapkan perilaku berikut:
Pengarahan lalu lintas antar zona: Event Hubs beroperasi dalam model aktif-aktif di mana infrastruktur di tiga zona ketersediaan secara bersamaan memproses event masuk.
Replikasi data antar zona: Azure Event Hubs menggunakan replikasi sinkron di seluruh zona ketersediaan. Saat penghasil peristiwa mengirimkan peristiwa, Azure Event Hubs menulis peristiwa tersebut ke replika di beberapa zona sebelum mengonfirmasi kepada klien bahwa operasi tulis telah selesai. Pendekatan ini memastikan tidak ada kehilangan data, bahkan jika seluruh zona menjadi tidak tersedia. Pendekatan replikasi sinkron memberikan jaminan konsistensi yang kuat sambil mempertahankan latensi rendah melalui protokol replikasi yang dioptimalkan.
Pengalaman penutupan zona
Saat namespace Event Hubs menggunakan redundansi zona dan terjadi pemadaman zona ketersediaan, perkirakan perilaku berikut:
Deteksi dan respons: Azure Event Hubs bertanggung jawab untuk mendeteksi kegagalan secara otomatis di zona ketersediaan. Anda tidak perlu memulai failover zona.
Pemberitahuan: Azure Event Hubs tidak memberi tahu Anda saat zona tidak berfungsi. Tetapi Anda dapat menggunakan Azure Service Health untuk memahami kesehatan keseluruhan layanan Azure Event Hubs, termasuk kegagalan zona.
Siapkan pemberitahuan untuk menerima pemberitahuan masalah tingkat zona. Untuk informasi selengkapnya, lihat Membuat pemberitahuan Service Health di portal Microsoft Azure.
Permintaan aktif: Selama kegagalan zona, Azure Event Hubs 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 Event Hubs secara sinkron mereplikasi peristiwa 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: Event Hubs mendeteksi hilangnya zona dan secara otomatis mengalihkan permintaan yang baru diterima ke replika lain di salah satu zona ketersediaan yang masih sehat.
SDK klien Azure Event Hubs biasanya menangani manajemen koneksi dan mencoba kembali logika secara transparan.
Pemulihan zona
Saat zona ketersediaan pulih, Azure Event Hubs secara otomatis mengintegrasi ulang zona ke dalam topologi layanan aktif. Zona yang dipulihkan mulai menerima koneksi baru dan memproses peristiwa bersama zona lain. Data yang telah 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 dan reintegrasi.
Pengujian kegagalan zona
Azure Event Hubs mengelola perutean lalu lintas, failover, dan pemulihan zona untuk kegagalan zona, sehingga Anda tidak perlu memvalidasi proses kegagalan zona ketersediaan atau memberikan input lebih lanjut.
Dukungan multi-wilayah
Azure Event Hubs menyediakan dua jenis dukungan multi-wilayah:
Replikasi geografis (tingkat Premium dan Khusus) menyediakan replikasi aktif-aktif metadata dan data peristiwa antara wilayah utama dan satu atau beberapa wilayah sekunder. Gunakan replikasi geografis untuk sebagian besar aplikasi yang perlu tetap tahan terhadap pemadaman wilayah dan memiliki toleransi rendah untuk kehilangan data peristiwa.
Pemulihan metadata bencana geografis (Tingkat standar dan yang lebih tinggi) menyediakan replikasi pasif-aktif konfigurasi dan metadata antara wilayah primer dan sekunder, tetapi tidak mereplikasi data peristiwa. Gunakan pemulihan bencana geografis untuk aplikasi yang dapat mentolerir beberapa kehilangan data peristiwa selama skenario bencana, dan yang perlu dengan cepat melanjutkan operasi di wilayah lain.
Pemulihan geo-replikasi dan pemulihan bencana geografis metadata mengharuskan Anda untuk memulai failover atau mengubah status wilayah sekunder secara manual agar menjadi wilayah primer yang baru. Microsoft tidak secara otomatis melakukan failover atau promosi, meskipun wilayah utama Anda tidak berfungsi.
Replikasi geografis
Tingkat Premium dan Khusus mendukung replikasi geografis. Fitur ini mereplikasi metadata (seperti entitas, konfigurasi, dan properti) dan data (seperti payload peristiwa) untuk namespace. Anda mengonfigurasi pendekatan replikasi untuk konfigurasi dan data peristiwa namespace Anda. Fitur ini memastikan bahwa peristiwa Anda tetap tersedia di wilayah lain dan memungkinkan Anda beralih ke wilayah sekunder saat diperlukan. Ini juga mereplikasi metadata dan data registri skema.
Gunakan replikasi geografis untuk skenario yang memerlukan ketahanan terhadap pemadaman wilayah dan memiliki toleransi rendah untuk kehilangan data peristiwa.
Namespace secara esensial berlaku di beberapa wilayah. Satu wilayah berfungsi sebagai wilayah utama, dan wilayah lainnya berfungsi sebagai sekunder. Langganan Azure Anda menampilkan satu namespace saja, tidak peduli berapa banyak wilayah sekunder yang Anda konfigurasi untuk replikasi geografis.
Kapan saja, Anda dapat mempromosikan wilayah sekunder ke wilayah utama. Saat Anda mempromosikan wilayah sekunder, Azure Event Hubs 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
Replikasi geografis Azure Event Hubs menggunakan istilah promosi karena paling baik mewakili proses mempromosikan wilayah sekunder ke wilayah utama (dan kemudian menurunkan wilayah utama ke wilayah sekunder). Anda mungkin juga melihat istilah failover yang digunakan untuk menjelaskan proses umum.
Bagian ini meringkas aspek-aspek penting dari replikasi geografis. Tinjau dokumentasi lengkap untuk memahami dengan tepat cara kerjanya. Untuk informasi selengkapnya, lihat Replikasi geografis Azure Event Hubs.
Dukungan wilayah
Anda dapat memilih wilayah Azure apa pun yang mendukung Azure Event Hubs sebagai wilayah utama atau wilayah sekunder Anda. Anda tidak perlu menggunakan wilayah berpasangan Azure, sehingga Anda dapat memilih wilayah sekunder berdasarkan persyaratan latensi, kepatuhan, atau residensi data Anda.
Persyaratan
Untuk mengaktifkan replikasi geografis, namespace Anda harus menggunakan tingkat Premium atau Khusus.
Pertimbangan
Saat Anda mengaktifkan replikasi geografis, pertimbangkan faktor-faktor berikut:
Format titik pemeriksaan: Format titik pemeriksaan berubah. Untuk informasi selengkapnya, lihat Replikasi geografis: Mengonsumsi data.
Titik akhir privat: Jika Anda menggunakan titik akhir privat untuk menyambungkan ke namespace, Anda juga perlu mengonfigurasi jaringan di wilayah utama dan sekunder Anda. Untuk informasi selengkapnya, lihat Titik akhir privat.
Biaya
Untuk memahami cara kerja harga untuk replikasi geografis, lihat Harga.
Mengonfigurasi dukungan multiregional
Aktifkan replikasi geografis pada namespace baru atau yang sudah ada. Untuk menyiapkan replikasi aktif-aktif untuk namespace yang baru dibuat, lihat Mengaktifkan replikasi geografis pada namespace baru. Untuk menyiapkan replikasi aktif-aktif pada namespace yang ada, lihat Mengaktifkan replikasi geografis pada namespace yang ada.
Ubah pendekatan replikasi. Untuk mengubah antara mode replikasi sinkron dan asinkron, lihat Beralih mode replikasi.
Nonaktifkan replikasi geografis. Untuk menonaktifkan replikasi geografis ke wilayah sekunder, lihat Menghapus wilayah sekunder.
Operasi normal
Bagian ini menjelaskan apa yang diharapkan ketika namespace Layanan Pusat Aktivitas dikonfigurasi untuk replikasi geografis, 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 peristiwa dari klien selama operasi normal. Wilayah sekunder menerima peristiwa yang direplikasi tetapi sebaliknya tetap pasif dalam mode siaga.
Replikasi data antar wilayah: Perilaku replikasi data antara wilayah utama dan sekunder bergantung pada apakah Anda mengonfigurasi pasangan replikasi untuk menggunakan replikasi sinkron atau asinkron.
Sinkron: Peristiwa direplikasi ke wilayah sekunder sebelum operasi tulis selesai.
Mode ini memberikan jaminan terbesar bahwa data peristiwa Anda aman karena harus dicatat di wilayah primer dan sekunder. Namun, replikasi sinkron secara substansial meningkatkan latensi tulis untuk peristiwa masuk. Ini juga mengharuskan wilayah sekunder tersedia untuk menerima operasi tulis, sehingga pemadaman di wilayah sekunder menyebabkan operasi tulis gagal.
- Asynchronous: Event ditulis ke wilayah utama dan kemudian operasi tulis selesai. Beberapa saat kemudian, ini mereplikasi peristiwa ke wilayah sekunder.
Mode ini menyediakan throughput tulis yang lebih tinggi daripada replikasi sinkron karena tidak ada latensi replikasi antar-wilayah selama operasi tulis. Selain itu, mode replikasi asinkron dapat mentolerir hilangnya wilayah sekunder sambil tetap mengizinkan operasi tulis di wilayah utama. Namun, jika wilayah utama mengalami pemadaman, data apa pun yang belum direplikasi ke wilayah sekunder mungkin tidak tersedia atau hilang.
Saat mengonfigurasi replikasi asinkron, Anda mengonfigurasi waktu jeda maksimum yang dapat diterima untuk diambil 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, penting untuk memilih wilayah sekunder yang tidak terlalu jauh secara geografis, dan untuk memastikan bahwa kapasitas Anda cukup untuk throughput.
Untuk informasi selengkapnya, lihat Mode replikasi.
Pengalaman wilayah yang mengalami gangguan
Bagian ini menjelaskan apa yang diharapkan ketika namespace Layanan Pusat Aktivitas dikonfigurasi untuk replikasi geografis dan ada pemadaman di wilayah utama atau sekunder.
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 informasi selengkapnya tentang cara mempromosikan wilayah sekunder ke primer baru, lihat Mempromosikan sekunder.
Saat Anda mempromosikan wilayah sekunder, pilih apakah akan melakukan promosi yang direncanakan atau promosi paksa. Promosi yang direncanakan menunggu wilayah sekunder siap sebelum menerima lalu lintas baru. Pendekatan ini menghilangkan kehilangan data tetapi memperkenalkan waktu henti.
Selama pemadaman di wilayah utama, Anda biasanya perlu melakukan promosi paksa. Jika wilayah utama tersedia dan Anda mengaktifkan promosi karena alasan lain, Anda dapat memilih promosi terencana.
Pemberitahuan: Azure Event Hubs tidak memberi tahu Anda saat suatu wilayah tidak berfungsi. Tetapi Anda dapat menggunakan Service Health untuk memahami kesehatan Event Hubs secara keseluruhan, termasuk kegagalan regional. Gunakan informasi tersebut dan metrik lainnya untuk memutuskan kapan harus mempromosikan wilayah sekunder ke wilayah utama.
Siapkan pemberitahuan untuk menerima pemberitahuan tentang masalah tingkat wilayah. Untuk informasi selengkapnya, lihat Membuat pemberitahuan Service Health di portal Microsoft Azure.
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 menahan dan tidak menerima peristiwa baru setelah tunda replikasi mencapai maksimum yang telah Anda konfigurasi.
Untuk terus menggunakan namespace di wilayah utama, hapus namespace sekunder dari konfigurasi replikasi geografis Anda.
Kehilangan data yang diharapkan: Jumlah kehilangan data tergantung pada jenis promosi yang Anda lakukan (direncanakan atau dipaksakan) dan mode replikasi (sinkron atau asinkron):
Promosi yang direncanakan: Tidak ada kehilangan data yang diharapkan. Namun, selama pemadaman wilayah, promosi yang direncanakan mungkin tidak dimungkinkan karena mengharuskan semua wilayah primer dan sekunder tersedia.
Promosi paksa, replikasi sinkron: Tidak ada kehilangan data yang diharapkan.
Promosi paksa, replikasi asinkron: Anda mungkin mengalami beberapa kehilangan data untuk peristiwa terbaru yang tidak direplikasi ke wilayah sekunder. 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, Azure Event Hubs 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 catatan DNS klien diperbarui, termasuk agar server DNS mereka mematuhi time-to-live (TTL) dari catatan DNS namespace.
Dalam beberapa situasi, Anda harus mengonfigurasi aplikasi konsumen agar bertingkah konsisten setelah promosi wilayah terjadi. Untuk informasi selengkapnya, lihat Replikasi geografis: Mengonsumsi data.
Pemulihan wilayah
Setelah wilayah utama asli pulih, jika Anda ingin mengembalikan namespace ke wilayah utama aslinya, ikuti proses promosi wilayah yang sama.
Jika Anda melakukan promosi paksa selama gangguan wilayah, Anda tidak dapat memulihkan data yang hilang, bahkan setelah wilayah utama tersedia.
Pengujian untuk kegagalan di dalam wilayah
Untuk menguji replikasi geografis, 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 replikasi geografis di lingkungan nonproduksi yang mencerminkan konfigurasi namespace produksi Anda.
Pemulihan metadata bencana geo-geografis
Tingkat Standar dan yang lebih tinggi mendukung pemulihan bencana geografis metadata. Fitur ini meningkatkan pemulihan dari skenario bencana, termasuk kerugian bencana suatu wilayah. Pemulihan bencana geografis hanya mereplikasi konfigurasi dan metadata namespace Anda. Namun, itu tidak mereplikasi data peristiwa. Untuk mendukung pemulihan bencana, fitur ini memastikan bahwa namespace layanan di wilayah lain telah dikonfigurasi sebelumnya dan siap untuk segera menerima peristiwa dari klien. Pemulihan bencana geografis berfungsi sebagai solusi pemulihan satu arah dan tidak mendukung failback ke wilayah utama sebelumnya.
Pemulihan bencana geografis metadata berfungsi paling baik untuk aplikasi yang tidak benar-benar perlu mempertahankan setiap peristiwa dan dapat mentolerir beberapa kehilangan data selama skenario bencana. Misalnya, jika peristiwa Anda mewakili pembacaan sensor yang kemudian Anda agregat, Anda mungkin memutuskan bahwa Anda mampu kehilangan beberapa peristiwa dari wilayah yang gagal jika Anda dapat dengan cepat melanjutkan pemrosesan peristiwa baru di wilayah lain.
Penting
Pemulihan bencana geografis memungkinkan kelangsungan operasi yang memiliki konfigurasi yang sama tetapi tidak mereplikasi data peristiwa. Jika Anda perlu mereplikasi data peristiwa, pertimbangkan untuk menggunakan replikasi geografis.
Saat mengonfigurasi pemulihan bencana geografis metadata, Anda membuat alias yang dihubungkan oleh aplikasi klien. Alias adalah FQDN yang mengarahkan semua lalu lintas ke namespace utama secara default.
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. Proses failover selesai hampir seketika. Selama proses failover, alias pemulihan bencana geografis menunjuk kembali ke namespace sekunder dan pasangan dihapus.
Bagian ini merangkum aspek penting dari pemulihan bencana geografis. Tinjau dokumentasi lengkap untuk memahami dengan tepat cara kerjanya. Untuk informasi selengkapnya, lihat Pemulihan bencana geografis Event Hubs.
Dukungan wilayah
Anda dapat memilih wilayah Azure apa pun yang mendukung Azure Event Hubs sebagai namespace utama atau sekunder Anda. Anda tidak perlu menggunakan wilayah berpasangan Azure, sehingga Anda dapat memilih wilayah sekunder berdasarkan persyaratan latensi, kepatuhan, atau residensi data Anda.
Persyaratan
Tingkat namespace utama: Namespace utama Anda harus berada di tingkat Standar atau lebih tinggi untuk menggunakan pemulihan bencana geografis metadata.
Tingkat namespace sekunder: Pemulihan bencana geo metadata mendukung kombinasi tingkat tertentu untuk namespace primer dan sekunder. Untuk informasi selengkapnya, lihat Pasangan namespace yang didukung.
Pertimbangan
Penetapan peran: Penetapan kontrol akses berbasis peran (RBAC) Microsoft Entra ke entitas di namespace utama tidak akan direplikasi ke namespace sekunder. Buat tugas peran secara manual di namespace layanan sekunder untuk mengamankan aksesnya.
Registri skema: Metadata registri skema mereplikasi saat Anda menggunakan pemulihan bencana geografis metadata, tetapi skema yang terdaftar di registri skema tidak mereplikasi.
Desain aplikasi: Pemulihan bencana geografis 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 Titik akhir privat.
Biaya
Saat Anda mengaktifkan pemulihan bencana geografis metadata, Anda membayar untuk kedua namespace utama dan sekunder.
Mengonfigurasi dukungan multiregional
Buat pasangan pemulihan bencana geografis metadata. Untuk mengonfigurasi disaster recovery antara namespace primer dan sekunder, lihat Setup dan alur failover.
Nonaktifkan pemulihan bencana geografis 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 memilih untuk 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.
Operasi normal
Bagian ini menjelaskan apa yang diharapkan ketika namespace Layanan Pusat Aktivitas dikonfigurasi untuk pemulihan bencana geografis, dan wilayah utama beroperasi.
Pengaturan lalu lintas antar wilayah: Aplikasi klien terhubung melalui alias pemulihan bencana regional untuk namespace Anda, dan mengalihkan lalu lintas mereka ke namespace utama di wilayah utama.
Hanya namespace utama yang secara aktif memproses peristiwa dari klien selama operasi normal. Namespace layanan sekunder tetap pasif 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 peristiwa tetap berada di namespace utama saja dan tidak direplikasi ke namespace sekunder.
Pengalaman wilayah yang mengalami gangguan
Bagian ini menjelaskan apa yang diharapkan ketika namespace Layanan Pusat Aktivitas dikonfigurasi untuk pemulihan bencana geografis dan ada pemadaman di wilayah utama.
Deteksi dan respons: Anda bertanggung jawab untuk memantau kesehatan wilayah dan memulai failover secara manual. Microsoft tidak melakukan failover atau mempromosikan wilayah sekunder secara otomatis, meskipun wilayah utama Anda tidak berfungsi.
Untuk informasi selengkapnya tentang cara memulai failover, lihat Failover manual.
Failover adalah operasi satu arah, jadi Anda perlu mengatur ulang pasangan pemulihan bencana geografis nanti. Untuk informasi selengkapnya, lihat Pemulihan wilayah.
Pemberitahuan: Azure Event Hubs tidak memberi tahu Anda saat suatu wilayah tidak berfungsi. Tetapi Anda dapat menggunakan Service Health untuk memahami kesehatan Event Hubs secara keseluruhan, termasuk kegagalan regional. Gunakan informasi tersebut dan metrik lain untuk memutuskan kapan memulai failover.
Siapkan pemberitahuan untuk menerima pemberitahuan tentang masalah tingkat wilayah. Untuk informasi selengkapnya, lihat Membuat pemberitahuan Service Health di portal Microsoft Azure.
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. Tetapi replikasi metadata terjadi secara asinkron, sehingga perubahan terbaru mungkin tidak mereplikasi, terutama perubahan kompleks. Verifikasi konfigurasi namespace sekunder Anda sebelum klien mengaksesnya.
Data peristiwa: Data peristiwa tidak mereplikasi antar wilayah. Jika region utama tidak berfungsi, event di namespace utama Anda menjadi tidak tersedia.
Peristiwa tidak hilang secara permanen kecuali bencana besar menyebabkan kehilangan total wilayah utama. Jika wilayah pulih, Anda dapat mengambil event dari namespace utama kemudian.
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 pemulihan bencana geografis untuk terhubung ke namespace secara otomatis dialihkan 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 secara manual membuat ulang pasangan dan secara opsional mengembalikan ke keadaan sebelumnya. Buat pasangan pemulihan bencana geografis baru dengan wilayah yang dipulihkan sebagai sekunder, lalu lakukan failover lain jika Anda ingin kembali ke wilayah asli. Proses ini melibatkan potensi kehilangan data peristiwa yang dikirim ke primer sementara.
Jika bencana menyebabkan hilangnya semua zona di wilayah utama, data Anda mungkin tidak dapat dipulihkan. Dalam skenario lain, data peristiwa Anda tetap berada di namespace utama dan dapat dipulihkan dari kondisi sebelum failover. Anda dapat memperoleh peristiwa bersejarah dari namespace utama lama setelah memulihkan akses. Anda bertanggung jawab untuk mengonfigurasi aplikasi Anda untuk menerima dan memproses peristiwa tersebut. Microsoft tidak secara otomatis memulihkannya ke wilayah sekunder Anda.
Pengujian untuk kegagalan di dalam 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 peristiwa dari primer 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 replikasi geografis di lingkungan nonproduksi yang mencerminkan konfigurasi namespace produksi Anda.
Pendekatan multi-wilayah alternatif
Replikasi geografis dan pemulihan bencana geografis metadata memberikan ketahanan terhadap pemadaman wilayah dan masalah lainnya, dan mendukung sebagian besar beban kerja. Beberapa tingkatan Azure Event Hubs tidak mendukung fitur ini, atau Anda mungkin memerlukan replikasi kustom atau perlu mempertahankan beberapa wilayah aktif secara bersamaan.
Berbagai pola desain dapat mencapai berbagai jenis dukungan multi-wilayah di Azure Event Hubs. Banyak pola mengharuskan menyebarkan beberapa namespace dan menggunakan layanan-layanan seperti Azure Functions untuk mereplikasi peristiwa di antara namespace tersebut. Untuk informasi selengkapnya, lihat Federasi multi-situs dan multi-wilayah.
Backups
Azure Event Hubs tidak dirancang sebagai lokasi penyimpanan jangka panjang untuk data Anda. Biasanya, Anda menyimpan data di pusat aktivitas untuk waktu yang singkat dan kemudian memprosesnya atau mempertahankannya di sistem penyimpanan data lain. Anda dapat mengonfigurasi periode retensi data untuk pusat aktivitas berdasarkan kebutuhan Anda dan tingkat yang digunakan namespace Anda. Untuk informasi selengkapnya, lihat Retensi aktivitas.
Jika Anda perlu menyimpan salinan peristiwa Anda, pertimbangkan untuk menggunakan Azure Event Hubs Capture, yang menyimpan salinan peristiwa ke akun Azure Blob Storage.
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.
SLA ketersediaan namespace Anda lebih tinggi ketika menggunakan tingkat Premium atau Dedikasi.