Replikasi geografis di Azure SignalR

Perusahaan yang mencari kehadiran lokal atau memerlukan sistem failover yang kuat sering memilih untuk menyebarkan layanan di beberapa wilayah Azure. Dengan integrasi replikasi geografis di Azure SignalR, mengelola skenario multi-wilayah telah menjadi jauh lebih mudah.

Manfaat menggunakan replikasi geografis

  • Lebih tahan terhadap pemadaman regional: Jika pemadaman regional terjadi, Azure SignalR DNS akan diselesaikan ke replika yang sehat di wilayah lain.
  • Komunikasi Lintas Wilayah. Replika yang berbeda dapat berkomunikasi satu sama lain seolah-olah mereka adalah instans yang sama.
  • Kecepatan jaringan yang ditingkatkan: Klien yang tersebar secara geografis akan terhubung ke replika terdekat. Replika ini berkomunikasi melalui backbone jaringan global Azure, memastikan jaringan yang cepat dan stabil.
  • Konfigurasi bersama. Semua replika mempertahankan konfigurasi sumber daya Azure SignalR Service utama.

Prasyarat

  • Azure SignalR Service di tingkat Premium.

Contoh kasus penggunaan

Contoso adalah perusahaan media sosial dengan basis pelanggannya yang tersebar di AS dan Kanada. Untuk melayani pelanggan tersebut dan membiarkan mereka berkomunikasi satu sama lain, Contoso menjalankan layanannya di AS Tengah. Azure SignalR Service digunakan untuk menangani koneksi pengguna dan memfasilitasi komunikasi di antara pengguna. Pengguna akhir Contoso sebagian besar adalah pengguna telepon. Karena jarak geografis yang panjang, pengguna akhir di Kanada mungkin mengalami latensi tinggi dan kualitas jaringan yang buruk.

Diagram menggunakan satu instans Azure SignalR untuk menangani lalu lintas dari dua negara.

Sebelum munculnya fitur replikasi geografis, Contoso dapat menyiapkan Azure SignalR Service lain di Kanada Tengah untuk melayani penggunanya di Kanada. Dengan menyiapkan Azure SignalR Service yang lebih dekat secara geografis, pengguna akhir sekarang memiliki kualitas jaringan yang lebih baik dan latensi yang lebih rendah.

Namun, mengelola beberapa Azure SignalR Services membawa beberapa tantangan:

  1. Mekanisme komunikasi lintas wilayah akan diperlukan untuk mengaktifkan percakapan antara pengguna Kanada dan AS.
  2. Tim pengembangan perlu mengelola dua Azure SignalR Services terpisah, masing-masing dengan domain dan string koneksi yang berbeda.
  3. Jika pemadaman regional terjadi, lalu lintas perlu dialihkan ke wilayah lain.

Diagram penggunaan dua instans Azure SignalR untuk menangani lalu lintas dari dua negara.

Memanfaatkan replikasi geografis

Dengan fitur geo-replikasi baru, Contoso sekarang dapat membuat replika di Kanada Tengah, secara efektif mengatasi rintangan yang disebutkan di atas.

Diagram menggunakan satu instans Azure SignalR dengan replika untuk menangani lalu lintas dari dua negara.

Membuat replika SignalR

Untuk membuat replika, Navigasikan ke bilah Replika SignalR di portal Azure dan klik Tambahkan untuk membuat replika. Ini akan diaktifkan secara otomatis saat dibuat.

Cuplikan layar pembuatan replika untuk Azure SignalR di Portal.

Setelah pembuatan, Anda akan dapat melihat/mengedit replika Anda di portal dengan mengklik nama replika.

Cuplikan layar bilah gambaran umum sumber daya replika Azure SignalR.

Harga dan unit sumber daya

Setiap replika memiliki sendiriunit dan autoscale settings.

Replika adalah fitur tingkat Premium Azure SignalR Service. Setiap replika ditagih secara terpisah sesuai dengan unit dan lalu lintas keluarnya sendiri. Kuota pesan gratis juga dihitung secara terpisah.

Dalam contoh sebelumnya, Contoso menambahkan satu replika di Kanada Tengah. Contoso akan membayar replika di Kanada Tengah sesuai dengan unit dan pesannya dalam Harga Premium.

Akan ada biaya keluar untuk lalu lintas keluar lintas wilayah. Jika pesan ditransfer ke seluruh replika dan berhasil dikirim ke klien atau server setelah transfer, pesan akan ditagih sebagai pesan keluar.

Menghapus replika

Setelah membuat replika untuk Azure SignalR Service, Anda dapat menghapusnya kapan saja jika tidak lagi diperlukan.

Untuk menghapus replika di portal Microsoft Azure:

  1. Navigasikan ke Azure SignalR Service Anda, dan pilih bilah Replika . Klik replika yang ingin Anda hapus.
  2. Klik tombol Hapus pada bilah gambaran umum replika.

Memahami cara kerja replika SignalR

Diagram di bawah ini memberikan ilustrasi singkat tentang fungsionalitas Replika SignalR:

Diagram lengkungan replika Azure SignalR.

  1. Klien bernegosiasi dengan server aplikasi dan menerima pengalihan ke layanan Azure SignalR. Kemudian menyelesaikan Nama Domain Yang Sepenuhnya Memenuhi Syarat (FQDN) layanan SignalR — contoso.service.signalr.net. FQDN ini menunjuk ke Traffic Manager, yang mengembalikan Nama Kanonis (CNAME) dari instans SignalR regional terdekat.
  2. Dengan CNAME ini, klien membuat koneksi ke instans regional (Replika).
  3. Kedua replika akan menyinkronkan data satu sama lain. Pesan yang dikirim ke satu replika akan ditransfer ke replika lain jika perlu.
  4. Jika replika gagal dalam pemeriksaan kesehatan yang dilakukan oleh Traffic Manager (TM), TM akan mengecualikan titik akhir instans yang gagal dari proses resolusi domainnya. Untuk detailnya, lihat Ketahanan dan Pemulihan Bencana di bawah ini

Catatan

  • Dalam bidang data, sumber daya Azure SignalR utama berfungsi identik dengan replikanya

Ketahanan dan pemulihan bencana

Azure SignalR Service menggunakan manajer lalu lintas untuk pemeriksaan kesehatan dan resolusi DNS terhadap replikanya. Dalam keadaan normal, ketika semua replika berfungsi dengan baik, klien akan diarahkan ke replika terdekat. Contohnya:

  • Klien yang dekat eastus dengan akan diarahkan ke replika yang terletak di eastus.
  • Demikian pula, klien yang dekat dengan westus akan diarahkan ke replika di westus.

Jika terjadi pemadaman regional di eastus (diilustrasikan di bawah), manajer lalu lintas akan mendeteksi kegagalan pemeriksaan kesehatan untuk wilayah tersebut. Kemudian, DNS replika yang salah ini akan dikecualikan dari hasil resolusi DNS traffic manager. Setelah durasi DNS Time-to-Live (TTL), yang diatur ke 90 detik, klien di akan dialihkan eastus untuk terhubung dengan replika di westus.

Diagram failover replika Azure SignalR.

Setelah masalah selesai eastus dan wilayah kembali online, pemeriksaan kesehatan akan berhasil. Klien di eastus kemudian akan, sekali lagi, diarahkan ke replika di wilayah mereka. Transisi ini lancar karena klien yang terhubung tidak akan terpengaruh sampai koneksi yang ada ditutup.

Diagram pemulihan failover replika Azure SignalR.

Proses failover dan pemulihan ini bersifat otomatis dan tidak memerlukan intervensi manual.

Untuk koneksi server, failover dan pemulihan bekerja dengan cara yang sama seperti halnya untuk koneksi klien.

Catatan

  • Mekanisme failover ini untuk layanan Azure SignalR. Pemadaman regional server aplikasi berada di luar cakupan dokumen ini.

Menonaktifkan atau mengaktifkan titik akhir replika

Saat menyiapkan replika, Anda memiliki opsi untuk mengaktifkan atau menonaktifkan titik akhirnya. Jika dinonaktifkan, resolusi DNS FQDN utama tidak akan menyertakan replika, dan oleh karena itu, lalu lintas tidak akan diarahkan ke replika tersebut.

Diagram pengaturan titik akhir replika Azure SignalR.

Anda juga dapat mengaktifkan nonaktifkan titik akhir setelah dibuat. Pada bilah replika sumber daya utama, klik tombol elipsis di sisi kanan replika dan pilih Aktifkan Titik Akhir atau Nonaktifkan Titik Akhir:

Diagram modifikasi titik akhir replika Azure SignalR.

Sebelum menghapus replikasi, pertimbangkan untuk menonaktifkan titik akhirnya terlebih dahulu. Seiring waktu, koneksi yang ada akan terputus. Karena tidak ada koneksi baru yang datang, replikasi menjadi menganggur akhirnya. Ini memastikan proses penghapusan yang mulus.

Fitur ini juga berguna untuk memecahkan masalah regional.

Catatan

  • Karena cache DNS, mungkin perlu waktu beberapa menit agar pembaruan DNS berlaku.
  • Koneksi yang ada tetap tidak terpengaruh sampai sambungan terputus.

Dampak pada performa setelah menambahkan replika

Setelah replika diaktifkan, klien akan secara alami mendistribusikan berdasarkan lokasi geografis mereka. Meskipun SignalR bertanggung jawab untuk menyinkronkan data di seluruh replika ini, Anda akan senang mengetahui bahwa overhead terkait pada Beban Server minimal untuk kasus penggunaan yang paling umum.

Secara khusus, jika aplikasi Anda biasanya disiarkan ke grup yang lebih besar (ukuran >10) atau satu koneksi, dampak performa sinkronisasi hampir tidak terlihat. Jika Anda olahpesan grup kecil (ukuran < 10) atau pengguna individual, Anda mungkin melihat sedikit lebih banyak overhead sinkronisasi.

Untuk memastikan manajemen failover yang efektif, disarankan untuk mengatur ukuran unit setiap replika untuk menangani semua lalu lintas. Atau, Anda dapat mengaktifkan autoscaling untuk mengelola ini.

Untuk evaluasi performa lainnya, lihat Performa.