Replikasi geografis (Pratinjau Umum)

Ada dua fitur yang menyediakan pemulihan bencana geografis di Azure Event Hubs.

• Pemulihan bencana geografis (Metadata DR), yang hanya menyediakan replikasi metadata saja.
• Replikasi geografis (pratinjau publik), yang menyediakan replikasi metadata dan data.

Fitur-fitur ini tidak boleh dikacaukan dengan Zona Ketersediaan. Kedua fitur pemulihan geografis memberikan ketahanan antara wilayah Azure seperti US Timur dan AS Barat. Dukungan Zona Ketersediaan memberikan ketahanan dalam wilayah geografis tertentu, seperti US Timur. Untuk informasi selengkapnya tentang Zona Ketersediaan, lihat Dukungan Zona Ketersediaan Azure Event Hubs.

Penting

• Fitur ini saat ini dalam pratinjau publik, dan karenanya tidak boleh digunakan dalam skenario produksi.
• Wilayah berikut saat ini didukung dalam pratinjau publik.

US	Eropa
US Tengah EUAP	Italia Utara
	Spanyol Tengah
	Norwegia Timur

Pemulihan bencana metadata vs. Replikasi geo metadata dan data

Fitur Metadata DR mereplikasi informasi konfigurasi 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 informasi konfigurasi atau penetapan izin yang direplikasi.

Fitur Geo-replikasi yang lebih baru mereplikasi informasi konfigurasi dan semua data dari namespace utama ke satu, atau beberapa namespace sekunder. Ketika failover dilakukan, sekunder yang dipilih menjadi primer dan primer sebelumnya menjadi sekunder. Pengguna dapat melakukan failover kembali ke primer asli jika diinginkan.

Sisa artikel ini berfokus pada fitur Geo-replikasi. Untuk detail tentang fitur metadata DR, lihat Pemulihan penyelesaian geo Azure Event Hubs untuk metadata.

Replikasi lokasi geografis

Pratinjau publik fitur Replikasi geografis didukung untuk namespace layanan di kluster khusus penskalaan layanan mandiri Azure Event Hubs. Anda dapat menggunakan fitur dengan namespace layanan baru atau yang sudah ada di kluster layanan mandiri khusus. Fitur berikut ini tidak didukung dengan Replikasi geografis:

• Kunci yang dikelola Pelanggan (CMK)
• Identitas terkelola untuk pengambilan
• Fitur jaringan virtual (titik akhir layanan, atau titik akhir privat)
• Dukungan pesan besar (sekarang dalam pratinjau publik)
• Transaksi Kafka (sekarang dalam pratinjau publik)

Beberapa aspek utama pratinjau publik Replikasi Geo-data adalah:

• Model replikasi primer-sekunder – Replikasi geografis dibangun pada model replikasi sekunder primer, di mana pada waktu tertentu hanya ada satu namespace layanan utama yang melayani produsen peristiwa dan konsumen peristiwa.
• Azure Event Hubs melakukan replikasi byte ke byte yang dikelola sepenuhnya dari metadata, data peristiwa, dan offset konsumen di seluruh sekunder dengan tingkat konsistensi yang dikonfigurasi.
• Namespace layanan stabil yang sepenuhnya memenuhi syarat nama domain (FQDN) – FQDN tidak perlu berubah saat promosi dilakukan.
• Konsistensi replikasi - Ada dua pengaturan konsistensi replikasi, sinkron dan asinkron.
• Promosi sekunder yang dikelola pengguna menjadi primer baru.

Mengubah sekunder menjadi primer baru dilakukan dua cara:

• Direncanakan: promosi sekunder ke primer di mana lalu lintas tidak diproses sampai primer baru mengejar semua data yang disimpan oleh instans utama sebelumnya.
• Dipaksa: sebagai failover di mana sekunder menjadi primer secepat mungkin. Fitur Geo-replikasi mereplikasi semua data dan metadata dari wilayah utama ke wilayah sekunder yang dipilih. Namespace layanan FQDN selalu menunjuk ke wilayah utama.

Saat Anda memulai promosi sekunder, FQDN menunjuk ke wilayah yang dipilih untuk menjadi primer baru. Primer lama kemudian menjadi sekunder. Anda dapat mempromosikan sekunder Anda menjadi primer baru karena alasan selain failover. Alasan tersebut dapat mencakup peningkatan aplikasi, pengujian failover, atau sejumlah hal lainnya. Dalam situasi tersebut, biasanya beralih kembali ketika aktivitas tersebut selesai.

Wilayah sekunder ditambahkan, atau dihapus atas kebijakan pelanggan. Ada beberapa batasan saat ini yang perlu dicatat:

• Tidak ada kemampuan untuk mendukung tampilan baca-saja di wilayah sekunder.
• Tidak ada kemampuan promosi/failover otomatis. Semua promosi diinisiasi pelanggan.
• Wilayah sekunder harus berbeda dari wilayah utama. Anda tidak dapat memilih kluster khusus lain di wilayah yang sama.
• Hanya satu sekunder yang didukung untuk pratinjau publik.

Konsistensi replikasi

Ada dua konfigurasi konsistensi replikasi, sinkron dan asinkron. Penting untuk mengetahui perbedaan antara kedua konfigurasi karena berdampak pada aplikasi Anda dan konsistensi data Anda.

Replikasi asinkron

Dengan replikasi asinkron diaktifkan, semua pesan diterapkan di primer dan kemudian dikirim ke sekunder. Pengguna dapat mengonfigurasi jumlah waktu jeda yang dapat diterima yang harus ditinggalkan sekunder. Ketika lag untuk sekunder aktif lebih besar dari konfigurasi jeda pengguna, wilayah utama membatasi permintaan penerbitan masuk.

Replikasi sinkron

Ketika replikasi sinkron diaktifkan, peristiwa yang diterbitkan direplikasi ke sekunder, yang harus mengonfirmasi pesan sebelum diterapkan di primer. Dengan replikasi sinkron, aplikasi Anda menerbitkan dengan kecepatan yang diperlukan untuk menerbitkan, mereplikasi, mengakui, dan menerapkan. Ini juga berarti bahwa aplikasi Anda terkait dengan ketersediaan kedua wilayah. Jika wilayah sekunder tidak berfungsi, pesan tidak dapat diakui atau diterapkan.

Perbandingan konsistensi replikasi

Dengan replikasi sinkron:

• Latensi lebih lama karena penerapan terdistribusi.
• Ketersediaan terkait dengan ketersediaan dua wilayah. Jika satu wilayah tidak berfungsi, namespace Anda tidak tersedia.
• Data yang diterima selalu berada di setidaknya dua wilayah (hanya dua wilayah yang didukung dalam pratinjau publik awal).

Replikasi sinkron memberikan jaminan terbesar bahwa data Anda aman. Jika Anda memiliki replikasi sinkron, maka ketika diterapkan, maka replikasi tersebut diterapkan di semua wilayah yang dikonfigurasi untuk Replikasi geografis. Namun, ketika replikasi sinkron diaktifkan, ketersediaan aplikasi Anda dapat dikurangi karena tergantung pada ketersediaan kedua wilayah.

Mengaktifkan replikasi asinkron tidak terlalu memengaruhi latensi, dan ketersediaan layanan tidak terpengaruh oleh hilangnya wilayah sekunder. Replikasi asinkron tidak memiliki jaminan absolut bahwa semua wilayah memiliki data sebelum diterapkan seperti replikasi sinkron. Anda juga dapat mengatur jumlah waktu sekunder Anda dapat tidak sinkron sebelum lalu lintas masuk dibatasi. Pengaturannya bisa dari 5 menit hingga 1.440 menit, yaitu satu hari. Jika Anda ingin menggunakan wilayah dengan jarak yang jauh di antaranya, replikasi asinkron kemungkinan merupakan opsi terbaik untuk Anda.

Konfigurasi konsistensi replikasi dapat berubah setelah konfigurasi Geo-replikasi. Anda dapat pergi dari sinkron ke asinkron, atau dari asinkron ke sinkron. Jika Anda dari sinkron ke asinkron, latensi Anda, dan ketersediaan aplikasi akan meningkat. Jika Anda pergi dari asinkron ke sinkron, sekunder Anda menjadi dikonfigurasi sebagai sinkron setelah jeda mencapai nol. Jika Anda berjalan dengan jeda berkelanjutan karena alasan apa pun, maka Anda mungkin perlu menjeda penerbit Anda agar jeda mencapai nol dan mode Anda untuk dapat beralih ke sinkron.

Alasan umum untuk mengaktifkan replikasi sinkron terkait dengan pentingnya data, kebutuhan bisnis tertentu, atau alasan kepatuhan. Jika tujuan utama Anda adalah ketersediaan aplikasi daripada jaminan data, maka konsistensi asinkron kemungkinan adalah pilihan yang lebih baik.

Pilihan wilayah sekunder

Untuk mengaktifkan fitur Geo-replikasi, Anda perlu menggunakan wilayah primer dan sekunder tempat fitur Replikasi geografis diaktifkan. Anda juga harus memiliki kluster Azure Event Hubs yang sudah ada di wilayah utama dan sekunder.

Fitur Geo-replikasi tergantung pada mampu mereplikasi peristiwa yang diterbitkan dari wilayah utama ke sekunder. Jika wilayah sekunder berada di benua lain, wilayah tersebut berdampak besar pada jeda replikasi dari wilayah primer ke sekunder. Jika menggunakan Geo-replikasi untuk alasan ketersediaan dan keandalan, Anda paling baik dengan wilayah sekunder setidaknya berada di benua yang sama jika memungkinkan. Untuk mendapatkan pemahaman yang lebih baik tentang latensi yang diinduksi oleh jarak geografis, Anda dapat mempelajari lebih lanjut dari statistik latensi pulang pergi jaringan Azure | Microsoft Learn.

Manajemen replikasi geografis

Fitur Geo-replikasi memungkinkan Anda mengonfigurasi wilayah sekunder untuk mereplikasi konfigurasi dan data. Anda dapat:

• Mengonfigurasi Geo-replikasi - Wilayah sekunder dapat dikonfigurasi pada namespace layanan apa pun yang ada di kluster khusus layanan mandiri di suatu wilayah dengan kumpulan fitur Geo-replikasi diaktifkan. Ini juga dapat dikonfigurasi selama pembuatan namespace layanan pada kluster khusus yang sama. Untuk memilih wilayah sekunder, Anda harus memiliki kluster khusus yang tersedia di wilayah sekunder tersebut dan wilayah sekunder juga harus mengaktifkan set fitur Geo-replikasi untuk wilayah tersebut.
• Konfigurasikan konsistensi replikasi - Replikasi sinkron dan asinkron diatur saat Replikasi geografis dikonfigurasi tetapi juga dapat dialihkan setelahnya. Dengan konsistensi asinkron, Anda dapat mengonfigurasi jumlah waktu wilayah sekunder diizinkan untuk tertinggal.
• Memicu promosi/failover - Semua promosi, atau failover dimulai pelanggan. Selama promosi, Anda dapat memilih untuk membuatnya Dipaksa sejak awal, atau bahkan berubah pikiran setelah promosi dimulai dan membuatnya dipaksa.
• Hapus sekunder - Jika kapan saja Anda ingin menghapus pemasangan geografis antara wilayah primer dan sekunder, Anda dapat melakukannya dan data di wilayah sekunder akan dihapus.

Memantau replikasi data

Pengguna dapat memantau kemajuan pekerjaan replikasi dengan memantau metrik jeda replikasi di log Metrik Aplikasi.

• Aktifkan log Metrik Aplikasi di namespace Layanan Pusat Aktivitas Anda setelah Memantau Azure Event Hubs - Azure Event Hubs | Microsoft Learn.

• Setelah log Metrik Aplikasi diaktifkan, Anda perlu menghasilkan dan menggunakan data dari namespace selama beberapa menit sebelum Anda mulai melihat log.

• Untuk melihat log Metrik Aplikasi, navigasikan ke bagian Pemantauan halaman Azure Event Hubs, dan pilih Log di menu sebelah kiri. Anda dapat menggunakan kueri berikut untuk menemukan jeda replikasi (dalam detik) antara namespace primer dan sekunder.

  AzureDiagnostics
    | where TimeGenerated > ago(1h)
    | where Category == "ApplicationMetricsLogs"
    | where ActivityName_s == "ReplicationLag
  

• Kolom count_d menunjukkan lag replikasi dalam detik antara wilayah primer dan sekunder.

Menerbitkan Data

Aplikasi penerbitan peristiwa dapat menerbitkan data ke namespace layanan yang direplikasi secara geografis melalui FQDN namespace layanan yang direplikasi secara geografis. Pendekatan penerbitan peristiwa sama dengan kasus DR non-Geo dan tidak ada perubahan pada aplikasi klien yang diperlukan.

Penerbitan peristiwa mungkin tidak tersedia selama keadaan berikut:

• Selama masa tenggang Failover, wilayah utama yang ada menolak peristiwa baru yang diterbitkan ke pusat aktivitas.
• Ketika lag replikasi antara wilayah primer dan sekunder mencapai durasi jeda replikasi maksimum, beban kerja masuk penerbit mungkin dibatasi. Aplikasi publisher tidak dapat langsung mengakses namespace layanan apa pun di wilayah sekunder.

Mengkonsumsi Data

Aplikasi yang menggunakan peristiwa dapat menggunakan data menggunakan FQDN namespace layanan stabil dari namespace layanan yang direplikasi secara geografis. Operasi konsumen tidak didukung, dari kapan failover dimulai hingga selesai.

Manajemen Titik Pemeriksaan/Offset

Aplikasi yang mengonsumsi peristiwa dapat terus mempertahankan manajemen offset karena mereka akan melakukannya dengan satu namespace layanan.

Kafka

Offset berkomitmen untuk Event Hubs secara langsung dan offset direplikasi di seluruh wilayah. Oleh karena itu, konsumen dapat mulai mengkonsumsi dari tempat yang ditinggalkannya di wilayah utama.

Event Hubs SDK/AMQP

Klien yang menggunakan Azure Event Hubs SDK perlu meningkatkan ke SDK versi April 2024. Versi terbaru SDK Azure Event Hubs mendukung failover dengan pembaruan ke titik pemeriksaan. Titik pemeriksaan dikelola oleh pengguna dengan penyimpanan titik pemeriksaan seperti penyimpanan Azure Blob, atau solusi penyimpanan kustom. Jika ada failover, penyimpanan titik pemeriksaan harus tersedia dari wilayah sekunder sehingga klien dapat mengambil data titik pemeriksaan dan menghindari hilangnya pesan.

Harga

Kluster khusus Azure Event Hubs dihargai secara independen dari replikasi geografis. Penggunaan replikasi geografis dengan Azure Event Hubs khusus mengharuskan Anda memiliki setidaknya dua kluster khusus di wilayah terpisah. Kluster khusus yang digunakan sebagai instans sekunder untuk replikasi geografis dapat digunakan untuk beban kerja lainnya. Ada biaya untuk replikasi geografis berdasarkan bandwidth yang diterbitkan * jumlah wilayah sekunder. Biaya replikasi geografis dibebaskan dalam pratinjau publik awal.

Konten terkait

Untuk mempelajari cara menggunakan fitur Geo-replikasi, lihat Menggunakan Replikasi geografis.