Azure Service Bus Geo-Replication

Fitur Geo-Replication pada Azure Service Bus adalah salah satu opsi untuk melindungi aplikasi Azure Service Bus dari pemadaman dan bencana, dengan menyediakan replikasi metadata (entitas, konfigurasi, properti) dan data (data pesan dan perubahan properti pesan dan status). Anda dapat mengaktifkan Geo-Replication pada namespace baru dan yang sudah ada.

Fitur Geo-Replikasi memastikan bahwa metadata dan data namespace terus direplikasi dari wilayah utama ke satu atau beberapa wilayah sekunder.

• Antrean, topik, langganan, filter.
• Data yang tersimpan di entitas.
• Semua perubahan status dan perubahan properti dijalankan terhadap pesan dalam namespace.
• Konfigurasi namespace.

Fitur ini memungkinkan mempromosikan wilayah sekunder apa pun ke primer, kapan saja. Memindahkan status sekunder akan mengarahkan ulang namespace layanan ke wilayah sekunder yang dipilih, dan bertukar peran antara wilayah utama dan sekunder.

Catatan

• Fitur ini tersedia untuk tingkatan Premium Layanan Bus Azure.
• Saat ini hanya satu wilayah sekunder yang didukung.

Penting

• Fitur ini tidak dapat digunakan dalam kombinasi dengan fitur Azure Bus Layanan Geo-Disaster Recovery.
• Fitur berikut saat ini belum tersedia (sepenuhnya). Kami terus berupaya menghadirkan lebih banyak fitur, dan akan memperbarui daftar ini dengan status terbaru.
  • Pesan berukuran besar belum didukung.
  • Geo-Replication pada partitioned namespace masih dalam pratinjau publik.
• Saat ini, ketika failover dilakukan, pengatur waktu untuk entitas yang memiliki fitur penghapusan otomatis saat tidak aktif diaktifkan di-reset, masalah ini akan diperbaiki pada rilis mendatang.
• Saat Anda mengaktifkan integrasi Event Grid pada namespace layanan yang menggunakan Geo-Replication, perhatikan hal berikut.
  • Event Grid mereplikasi ke lokasi yang dipasangkan secara geografis, bukan wilayah sekunder yang disiapkan untuk replikasi geografis.
  • Pengaktifan wilayah sekunder untuk Service Bus tidak memicu failover pada Event Grid. Akibatnya, setelah promosi, Service Bus sekarang berjalan di wilayah utama baru, namun Event Grid masih berjalan di wilayah utama awal.
  • Jika wilayah utama awal dihapus dari konfigurasi Geo-Replication, ini akan merusak integrasi Event Grid.

Perbandingan dengan Pemulihan Geo-Disaster

Azure Service Bus menawarkan dua fitur untuk ketahanan geografis: Geo-Replication dan pemulihanGeo-Disaster. Perbedaan utamanya adalah Geo-Replication mereplikasi metadata dan data (pesan, status pesan, perubahan properti), sementara Geo-Disaster Recovery hanya mereplikasi metadata. Untuk sebagian besar skenario pemulihan bencana, Geo-Replication adalah pilihan yang direkomendasikan. Untuk perbandingan terperinci, lihat Perbedaan fitur tingkat tinggi.

Skenario

Fitur Geo-Replication dapat digunakan untuk menerapkan skenario yang berbeda, seperti yang dijelaskan di sini. Untuk panduan tentang kapan harus memicu promosi, lihat Skenario yang direkomendasikan untuk memicu promosi.

Pemulihan dari bencana

Data dan metadata terus disinkronkan antara wilayah utama dan sekunder. Jika wilayah utama Anda mengalami degradasi layanan, dimungkinkan untuk mempromosikan wilayah sekunder sebagai wilayah utama. Promosi ini memungkinkan operasi beban kerja yang tidak terganggu di wilayah yang baru dipromosikan. Promosi semacam itu mungkin diperlukan oleh kemunduran Service Bus atau layanan lain dalam aktivitas Anda, terutama jika Anda bertujuan untuk menjalankan berbagai komponen secara bersamaan. Tergantung pada tingkat keparahan dan layanan yang terkena dampak, promosi dapat direncanakan atau dipaksakan. Jika pesan promosi dalam penerbangan yang direncanakan direplikasi sebelum menyelesaikan promosi, sementara dengan promosi paksa, ini segera dijalankan.

Migrasi wilayah

Ada kalanya Anda ingin memigrasikan beban kerja Bus Layanan Anda untuk berjalan di wilayah yang berbeda. Misalnya, saat Azure menambahkan wilayah baru yang secara geografis lebih dekat ke lokasi, pengguna, atau layanan Anda lainnya. Atau, Anda mungkin ingin bermigrasi ketika wilayah tempat sebagian besar beban kerja Anda berjalan digeser. Fitur Geo-Replikasi juga memberikan solusi yang baik dalam kasus ini. Dalam hal ini, Anda akan menyiapkan Geo-Replikasi pada namespace layanan yang ada dengan wilayah baru yang diinginkan sebagai wilayah sekunder dan menunggu sinkronisasi selesai. Pada titik ini, Anda akan memulai promosi yang direncanakan, memungkinkan pesan dalam penerbangan direplikasi. Setelah promosi selesai, Anda sekarang dapat secara opsional menghapus wilayah lama, yang sekarang menjadi wilayah sekunder, dan terus menjalankan beban kerja Anda di wilayah yang diinginkan.

Pemeliharaan terencana

Selama aktivitas pemeliharaan terencana di wilayah utama, Anda dapat mempromosikan wilayah sekunder untuk mempertahankan ketersediaan tinggi untuk aplikasi misi penting. Pendekatan ini memungkinkan Anda melakukan pemeliharaan tanpa memengaruhi beban kerja Anda.

Konsep dasar

Fitur Geo-Replikasi mengimplementasikan metadata dan replikasi data dalam model replikasi sekunder utama. Pada waktu tertentu ada satu wilayah utama, yang melayani produsen dan konsumen. Wilayah sekunder dapat berada di salah satu dari dua status:

• Sekunder aktif: Wilayah sekunder yang merupakan bagian dari konfigurasi replikasi dan secara aktif sedang direplikasi. Sekunder aktif adalah bagian dari kuorum untuk replikasi sinkron. Untuk informasi selengkapnya, lihat status Siap dalam Manajemen.
• Sekunder siaga: Wilayah sekunder yang sedang disiapkan atau disinkronkan ulang setelah promosi. Sekunder menganggur bukan bagian dari kuorum dan tidak memengaruhi pengesahan dalam mode sinkron. Untuk informasi selengkapnya, lihat status InBuild di Manajemen.

Wilayah sekunder bertindak sebagai wilayah siaga panas, yang berarti bahwa tidak mungkin untuk berinteraksi dengan wilayah sekunder ini. Namun, mereka berjalan dalam konfigurasi yang sama dengan wilayah utama, memungkinkan promosi cepat, dan yang berarti beban kerja Anda dapat segera terus berjalan setelah promosi selesai.

Beberapa aspek utama fitur Geo-Replikasi adalah:

• Layanan Service Bus (Bus Layanan) melakukan replikasi penuh dan terkelola dari metadata, data pesan, serta perubahan status dan properti pesan di seluruh wilayah, sesuai dengan konsistensi replikasi yang dikonfigurasi pada namespace.
• Nama host namespace tunggal; Setelah berhasil mengonfigurasikan namespace yang diaktifkan Geo-Replication, pengguna dapat menggunakan nama host namespace di aplikasi klien mereka. Nama host tidak terpengaruh oleh wilayah utama dan sekunder yang dikonfigurasi, dan selalu menunjuk ke wilayah utama yang dikonfigurasi.
• Saat pelanggan memulai promosi, nama host menunjuk ke wilayah yang dipilih untuk menjadi wilayah utama baru. Wilayah primer yang lama menjadi wilayah sekunder.
• Tidak dimungkinkan untuk membaca atau menulis di wilayah sekunder.
• Tidak ada perubahan pada SDK bidang data atau aplikasi klien yang diperlukan untuk menggunakan Geo-Replikasi.
• Mode replikasi sinkron dan asinkron, dijelaskan lebih lanjut di sini.
• Pemindahan yang dikelola pelanggan dari wilayah utama ke sekunder, memberikan kepemilikan dan visibilitas penuh untuk penyelesaian gangguan. Metrik jeda replikasi tersedia, yang dapat digunakan untuk memantau status replikasi dan mengotomatiskan promosi.
• Wilayah sekunder dapat ditambahkan atau dihapus atas kebijakan pelanggan.
• Ketika lag replikasi mencapai maksimum yang dikonfigurasi, permintaan penerbit akan dibatasi.

Mode replikasi

Ada dua mode replikasi, sinkron dan asinkron. Penting untuk mengetahui perbedaan antara kedua mode.

Replikasi asinkron

Menggunakan replikasi asinkron, semua permintaan diselesaikan di server utama, setelah itu pengakuan dikirim ke klien. Replikasi ke wilayah sekunder terjadi secara asinkron. Pengguna dapat mengonfigurasi jumlah waktu jeda maksimum yang dapat diterima. Waktu jeda adalah selisih sisi layanan antara tindakan terbaru di wilayah utama dan sekunder. Layanan ini terus mereplikasi data dan metadata, memastikan jeda tetap sesedikcil mungkin. Jika jeda untuk sekunder aktif tumbuh di luar lag replikasi maksimum yang dikonfigurasi pengguna, primer mulai membatasi permintaan masuk.

Replikasi sinkron

Dengan menggunakan replikasi sinkron, semua permintaan dianggap pada server primer dan sekunder sebelum pengakuan dikirimkan kepada klien. Dengan demikian, aplikasi Anda menerbitkan dengan kecepatan penerbitan yang diperlukan untuk mencakup semua wilayah. Selain itu, ini juga berarti bahwa aplikasi Anda terkait dengan ketersediaan kedua wilayah. Jika wilayah sekunder tertinggal atau tidak tersedia, pesan tidak akan diakui dan dicatat, dan wilayah utama akan mengatur laju permintaan masuk.

Perbandingan mode replikasi

Dengan replikasi sinkron :

• Latensi lebih tinggi karena operasi komitmen terdistribusi.
• Ketersediaan bergantung pada ketersediaan dua wilayah.

Di sisi lain, replikasi sinkron memberikan jaminan terbesar bahwa data Anda aman. Jika Anda memiliki replikasi sinkron, maka ketika kami menerapkannya, replikasi tersebut berkomitmen di semua wilayah yang Anda konfigurasi untuk Geo-Replikasi, memberikan jaminan data terbaik.

Dengan replikasi asinkron :

• Dampak terhadap latensi adalah minimal.
• Hilangnya wilayah sekunder tidak segera berdampak pada ketersediaan. Namun, ketersediaan akan terpengaruh setelah lag replikasi maksimum yang dikonfigurasi tercapai.

Dengan demikian, tidak memiliki jaminan absolut bahwa semua wilayah memiliki data sebelum kami menerapkannya seperti replikasi sinkron, dan kehilangan data atau duplikasi dapat terjadi ketika promosi paksa digunakan. Namun, karena Anda tidak lagi segera terpengaruh ketika satu wilayah tertinggal atau tidak tersedia, ketersediaan aplikasi meningkat, selain memiliki latensi yang lebih rendah.

Kemampuan	Replikasi sinkron	Replikasi asinkron
Latensi	Lebih lama karena operasi komit terdistribusi	Terdampak minimal
Ketersediaan	Terkait dengan ketersediaan wilayah sekunder	Hilangnya wilayah sekunder tidak segera berdampak pada ketersediaan
Konsistensi data	Data selalu diterapkan di kedua wilayah sebelum pengakuan	Data hanya dapat dicatat di server utama sebelum mendapatkan pengakuan
RPO (Tujuan Titik Pemulihan)	RPO 0, tidak ada kehilangan data saat pengalihan	RPO dalam jeda yang dikonfigurasi, kemungkinan kehilangan data pada promosi paksa

Mode replikasi dapat diubah setelah mengonfigurasi Geo-Replikasi. Anda dapat beralih dari sinkron ke asinkron atau dari asinkron ke sinkron. Jika Anda beralih dari asinkron ke sinkron, server sekunder Anda akan dikonfigurasi sebagai sinkron setelah penundaan mencapai nol. Jika Anda menjalankan sistem dengan penundaan yang terus-menerus karena alasan apa pun, maka Anda mungkin perlu menjeda penerbit Anda agar penundaan mencapai nol dan mode Anda agar dapat beralih ke sinkron. Alasan untuk mengaktifkan replikasi sinkron, alih-alih replikasi asinkron, terkait dengan pentingnya data, kebutuhan bisnis tertentu, atau alasan kepatuhan, daripada ketersediaan aplikasi Anda.

Catatan

Jika wilayah sekunder tertinggal atau menjadi tidak tersedia, aplikasi tidak akan lagi dapat mereplikasi ke wilayah ini dan akan mulai mengendalikan laju setelah penundaan replikasi tercapai. Untuk terus menggunakan namespace di lokasi utama, wilayah sekunder yang terpengaruh dapat dihapus. Jika tidak ada lagi wilayah sekunder yang dikonfigurasi, namespace akan dilanjutkan tanpa Geo-Replication aktif. Anda dapat menambahkan wilayah sekunder tambahan kapan saja. Entitas tingkat atas, yang merupakan antrean dan topik, direplikasi secara sinkron, terlepas dari mode replikasi yang dikonfigurasi. Namun, langganan topik mematuhi mode replikasi yang dipilih, dan oleh karena itu, sangat penting untuk memperhitungkannya saat memutuskan mode replikasi yang sesuai.

Pilihan wilayah sekunder

Fitur Geo-Replikasi tergantung pada mampu mereplikasi pesan yang diterbitkan dari wilayah utama ke sekunder. Jika wilayah sekunder berada di benua lain, ini berdampak besar pada jeda replikasi dari wilayah primer ke sekunder. Jika menggunakan Geo-Replikasi demi ketersediaan, sebaiknya memilih wilayah sekunder yang 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.

Manajemen Geo-Replikasi

Fitur Geo-Replikasi memungkinkan pelanggan mengonfigurasi wilayah sekunder untuk mereplikasi metadata dan data. Dengan demikian, pelanggan dapat melakukan tugas manajemen berikut:

• Mengonfigurasi Geo-Replikasi; Wilayah sekunder dapat dikonfigurasi pada namespace baru atau yang sudah ada dalam wilayah dengan fitur Geo-Replikasi diaktifkan.
• Mengonfigurasi konsistensi replikasi; Replikasi sinkron dan asinkron diatur ketika Geo-Replikasi dikonfigurasi tetapi juga dapat dialihkan setelahnya.
• Promosi pemicu; Semua promosi diinisiasi pelanggan.
• Hapus sekunder; Jika kapan saja Anda ingin menghapus wilayah sekunder, Anda dapat melakukannya setelah data di wilayah sekunder dihapus.

Pengaturan

Menggunakan portal Azure

Bagian berikut adalah gambaran umum untuk menyiapkan fitur Geo-Replikasi pada namespace baru melalui portal Azure.

1. Buat namespace tingkat premium baru.
2. Centang kotak aktifkan Replikasi geografis di bawah bagian Replikasi Geografis .
3. Klik tombol Tambahkan wilayah sekunder, dan pilih wilayah.
4. Periksa kotak centang Replikasi sinkron , atau tentukan nilai untuk nilai Lag Replikasi Asinkron - Replikasi Maks dalam hitungan menit.

Menggunakan file Bicep

Untuk membuat namespace dengan fitur Geo-Replication diaktifkan, tambahkan bagian properti geoDataReplication .

param serviceBusName string
param primaryLocation string
param secondaryLocation string
param maxReplicationLagInSeconds int

resource sb 'Microsoft.ServiceBus/namespaces@2024-01-01' = {
  name: serviceBusName
  location: primaryLocation
  sku: {
    name: 'Premium'
    tier: 'Premium'
    capacity: 1
  }
  properties: {
    geoDataReplication: {
      maxReplicationLagDurationInSeconds: maxReplicationLagInSeconds
      locations: [
        {
          locationName: primaryLocation
          roleType: 'Primary'
        }
        {
          locationName: secondaryLocation
          roleType: 'Secondary'
        }
      ]
    }
  }
}

Manajemen

Setelah membuat namespace dengan fitur Geo-Replication diaktifkan, Anda dapat mengelola fitur dari bilah Geo-Replication .

Wilayah sekunder dapat berada di salah satu status berikut:

State	Description
InBuild	Wilayah sekunder sedang disiapkan dan sinkronisasi awal sedang berlangsung, atau wilayah sedang disinkronkan ulang setelah promosi paksa. Wilayah sekunder dalam status InBuild tidak termasuk bagian dari kuorum.
Siap	Wilayah sekunder adalah bagian dari konfigurasi replikasi dan saat ini sedang direplikasi secara aktif.
Menghapus	Wilayah sekunder sedang dihapus dari konfigurasi replikasi.

Beralih ke mode replikasi

Untuk beralih di antara mode replikasi, atau memperbarui jeda replikasi maksimum, klik tautan di bawah Konsistensi replikasi, dan klik kotak centang untuk mengaktifkan/menonaktifkan replikasi sinkron, atau perbarui nilai di kotak teks untuk mengubah jeda replikasi maksimum asinkron.

Menghapus wilayah sekunder

Untuk menghapus wilayah sekunder, klik tombol Hapus , dan ikuti instruksi di bilah pop-up. Saat penghapusan sedang berlangsung, wilayah menunjukkan status Penghapusan .

Alur promosi

Promosi dipicu secara manual oleh pelanggan (baik secara eksplisit melalui perintah, atau melalui logika bisnis milik klien yang memicu perintah) dan tidak pernah oleh Azure. Ini memberi pelanggan kepemilikan penuh dan visibilitas untuk penyelesaian pemadaman pada infrastruktur Azure.

Ada dua jenis promosi:

• Promosi yang direncanakan: Layanan menunggu untuk mengejar ketertinggalan replikasi sebelum memulai promosi. Namespace ditempatkan dalam mode baca-saja selama waktu ini, menolak pesan baru dan operasi konsumen hingga promosi selesai.
• Promosi paksa: Layanan segera memulai promosi tanpa menunggu replikasi mengejar ketinggalan.

Dimungkinkan untuk melakukan promosi paksa kapan saja setelah promosi yang direncanakan telah dimulai, menempatkan pengguna dalam kontrol untuk mempercepat promosi ketika promosi yang direncanakan membutuhkan waktu lebih lama dari yang diinginkan. Namun, beralih ke promosi paksa membawa risiko kehilangan data yang sama seperti memulai promosi paksa secara langsung.

Penting

Saat menggunakan Promosi paksa , data atau metadata apa pun yang belum direplikasi mungkin hilang. Selain itu, karena perubahan status tertentu belum direplikasi, ini juga dapat mengakibatkan pesan duplikat diterima, misalnya ketika perubahan status Selesai atau Tangguhkan tidak direplikasi.

Setelah promosi yang dipaksakan, sistem primer lama (sekarang menjadi sekunder) masih berisi data yang belum direplikasi. Data ini hilang ketika primer lama disinkronkan ulang sebagai sekunder baru.

Setelah promosi dimulai:

1. Nama host diperbarui untuk menunjuk ke wilayah sekunder, yang dapat memakan waktu beberapa menit.

   Catatan

   Anda dapat memeriksa wilayah utama saat ini dengan memulai perintah ping: ping your-namespace-fully-qualified-name

2. Klien secara otomatis terhubung kembali ke wilayah sekunder.

3. Jika promosi paksa digunakan, wilayah sekunder baru memasuki status InBuild saat disinkronkan ulang, lalu transisi ke Siap.

Anda dapat mengotomatiskan promosi baik dengan sistem pemantauan, atau dengan solusi pemantauan yang dibuat khusus. Namun, otomatisasi semacam itu membutuhkan perencanaan dan pekerjaan ekstra, yang tidak dicakup dalam artikel ini.

Menggunakan portal Azure

Di portal, klik ikon Promosikan , dan ikuti instruksi di bilah pop-up untuk menghapus wilayah.

Menggunakan Azure CLI

Jalankan perintah Azure CLI untuk memulai promosi.

az servicebus namespace failover --namespace-name <your-namespace-name> --resource-group <your-resource-group> --primary-location <new-primary-location>

Memantau replikasi data

Pengguna dapat memantau kemajuan pekerjaan replikasi dengan memantau metrik jeda replikasi. Untuk daftar lengkap metrik yang tersedia, lihat Metrik Azure Service Bus.

Menampilkan lag replikasi di portal Microsoft Azure

Untuk memantau jeda replikasi di portal Microsoft Azure:

1. Navigasi ke namespace Bus Layanan Anda di portal Microsoft Azure.
2. Pilih Metrik di bawah bagian Pemantauan .
3. Pilih metrik ReplicationLagDuration dari menu dropdown.
4. Bagan menampilkan lag replikasi antara wilayah primer dan sekunder dalam detik.

Anda juga dapat menyiapkan pemberitahuan pada metrik ini untuk diberi tahu saat jeda melebihi ambang batas.

Melihat lag replikasi di Analitik Log

Untuk menggunakan Analitik Log untuk kueri dan analisis historis:

1. Aktifkan log metrik di namespace Service Bus Anda seperti yang dijelaskan di Monitor Azure Service Bus.
2. Setelah log Metrik diaktifkan, Anda perlu menghasilkan dan menggunakan data dari namespace selama beberapa menit sebelum Anda mulai melihat log.
3. Untuk melihat log Metrik, navigasikan ke bagian Pemantauan dari Service Bus dan pilih bilah Log. Anda dapat menggunakan kueri berikut untuk menemukan lag replikasi (dalam detik) antara wilayah utama dan sekunder.

AzureMetrics
| where TimeGenerated > ago(1h)
| where MetricName == "ReplicationLagDuration"

Pertimbangan

Perhatikan pertimbangan berikut untuk diingat dengan fitur ini:

• Dalam perencanaan promosi Anda, Anda juga harus mempertimbangkan faktor waktu. Misalnya, jika Anda kehilangan konektivitas selama lebih dari 15 hingga 20 menit, Anda dapat memutuskan untuk memulai promosi.
• Mempromosikan infrastruktur terdistribusi yang kompleks harus diuji coba setidaknya sekali.

Harga

Tingkat Premium untuk Service Bus dihargai per Unit Olahpesan. Dengan fitur Geo-Replication, setiap wilayah berjalan pada jumlah MUs yang sama seperti yang dikonfigurasi pada primer, dan Anda dikenakan biaya untuk total MUs di semua wilayah. Selain itu, dikenakan biaya berdasarkan data yang direplikasi ke wilayah sekunder. Tingkat transfer data ditentukan oleh zona tempat wilayah utama berada pada saat replikasi. Untuk detail harga saat ini, termasuk tarif transfer data, lihat halaman harga Azure Service Bus.

Total biaya dapat dihitung sebagai berikut:
(jumlah wilayah x MU yang dikonfigurasi pada sistem primer x jam x tarif per jam per MU) + (GB yang direplikasi x tarif transfer data per GB)

Misalnya, jika Anda memiliki 2 MUs yang dikonfigurasi pada namespace utama dengan 10 GB data yang direplikasi:
(2 wilayah x 2 MUs x jam x tarif per jam) + (10 GB x kecepatan transfer data)

Skenario yang direkomendasikan untuk memicu promosi

Meskipun Anda dapat mengaktifkan promosi kapan saja, berikut adalah beberapa skenario yang direkomendasikan di mana disarankan untuk mempromosikan sekunder ke primer. Untuk detail selengkapnya tentang setiap skenario, lihat Skenario.

• Pemadaman regional: Jika ada pemadaman regional yang memengaruhi wilayah utama, promosikan wilayah sekunder untuk memastikan kelangsungan bisnis dan meminimalkan waktu henti.
• Penurunan performa: Jika wilayah utama mengalami masalah performa yang memengaruhi ketersediaan atau keandalan namespace Layanan Anda, mempromosikan wilayah sekunder dapat membantu mengurangi masalah ini.
• Pemeliharaan terencana: Selama aktivitas pemeliharaan terjadwal di wilayah utama, mempromosikan wilayah sekunder membantu menjaga ketersediaan tinggi.
• Pengujian pemulihan bencana: Uji mekanisme failover Anda secara berkala untuk memastikan rencana kelangsungan bisnis Anda efektif dan aplikasi Anda dapat beralih dengan mulus ke wilayah sekunder saat diperlukan.

Migrasi

Untuk bermigrasi dari Geo-Disaster Recovery ke Geo-Replication, pertama-tama batalkan penghubungan pada namespace utama Anda.

Setelah pasangan terputus, Anda dapat mengikuti penyiapan untuk mengaktifkan Geo-Replication.

Titik akhir pribadi

Bagian ini memberikan pertimbangan tambahan saat menggunakan Geo-Replication dengan ruang nama yang memanfaatkan titik-titik akhir privat. Untuk informasi umum tentang menggunakan titik akhir privat dengan Azure Service Bus, lihat Mengintegrasikan Azure Service Bus dengan Azure Private Link.

Saat menerapkan Geo-Replication untuk namespace Service Bus yang menggunakan titik akhir privat, penting untuk membuat titik akhir privat untuk wilayah utama dan sekunder. Titik akhir ini harus dikonfigurasi terhadap jaringan virtual yang menghosting instans utama dan sekunder aplikasi Anda. Misalnya, jika Anda memiliki dua jaringan virtual, VNET-1 dan VNET-2, Anda perlu membuat dua titik akhir privat pada namespace Service Bus, masing-masing menggunakan subnet dari VNET-1 dan VNET-2. Selain itu, VNET harus disiapkan dengan peering lintas wilayah, sehingga klien dapat berkomunikasi dengan salah satu titik akhir privat. Terakhir, DNS perlu dikelola sedemikian rupa sehingga semua klien mendapatkan informasi DNS, yang harus mengarahkan endpoint namespace (namespacename.servicebus.windows.net) ke alamat IP titik akhir pribadi di wilayah utama saat ini.

Penting

Saat mempromosikan wilayah sekunder untuk Service Bus, entri DNS juga perlu diperbarui untuk menunjuk ke titik akhir yang sesuai.

Keuntungan dari pendekatan ini adalah bahwa failover dapat terjadi secara independen di lapisan aplikasi atau pada namespace Service Bus:

• Failover khusus aplikasi: Dalam skenario ini, aplikasi berpindah dari VNET-1 ke VNET-2. Karena titik akhir privat dikonfigurasi pada VNET-1 dan VNET-2 untuk namespace primer dan sekunder, aplikasi terus berfungsi dengan mulus.
• Failover khusus namespace Service Bus: Demikian pula, jika failover hanya terjadi di tingkat namespace Service Bus, aplikasi tetap beroperasi karena titik akhir privat dikonfigurasi di kedua jaringan virtual.

Dengan mengikuti panduan ini, Anda dapat memastikan mekanisme failover yang andal dan kuat untuk namespace Service Bus Anda dengan menggunakan titik akhir privat.

Langkah berikutnya

Untuk mempelajari selengkapnya tentang pesan Service Bus, lihat artikel berikut:

• Antrean, topik, dan langganan Service Bus
• Memulai dengan antrean Service Bus
• Cara menggunakan topik dan langganan Microsoft Azure Service Bus
• REST API