Ketahanan dan pemulihan bencana di Azure SignalR Service

Ketahanan dan pemulihan bencana adalah kebutuhan umum untuk sistem online. Azure SignalR Service sudah menyediakan ketersediaan 99,9%, namun masih merupakan layanan regional. Saat terjadi pemadaman di seluruh wilayah, instans layanan Anda tidak gagal ke wilayah lain karena selalu berjalan di satu wilayah.

Untuk pemulihan bencana regional, kami merekomendasikan dua pendekatan berikut:

• Aktifkan Geo-Replikasi (Cara mudah). Fitur ini menangani failover regional untuk Anda secara otomatis. Saat diaktifkan, hanya ada satu instans Azure SignalR dan tidak ada perubahan kode yang diperkenalkan. Periksa replikasi geografis untuk detailnya.
• Menggunakan Beberapa Titik Akhir di Service SDK. SDK layanan kami mendukung beberapa instans layanan SignalR dan secara otomatis beralih ke instans lain ketika beberapa di antaranya tidak tersedia. Dengan fitur ini, Anda dapat pulih ketika bencana terjadi, tetapi Anda perlu menyiapkan topologi sistem yang tepat sendiri. Anda mempelajari cara melakukannya dalam dokumen ini.

Arsitektur dengan ketersediaan tinggi untuk layanan SignalR

Untuk memastikan ketahanan lintas wilayah untuk layanan SignalR, Anda perlu menyiapkan beberapa instans layanan di berbagai wilayah. Jadi ketika satu wilayah mengalami gangguan, wilayah lain dapat digunakan sebagai cadangan. Saat server aplikasi terhubung ke beberapa instans layanan, ada dua peran, primer dan sekunder. Primer adalah instans yang bertanggung jawab untuk menerima lalu lintas online, sementara sekunder berfungsi sebagai instans fallback yang berfungsi penuh. Dalam implementasi SDK kami, negosiasi hanya mengembalikan titik akhir utama, sehingga klien hanya terhubung ke titik akhir utama dalam kasus normal. Tetapi ketika instans utama tidak berfungsi, negosiasi mengembalikan titik akhir sekunder sehingga klien masih dapat membuat koneksi. Instans primer dan server aplikasi terhubung melalui koneksi server normal tetapi instans sekunder dan server aplikasi terhubung melalui jenis koneksi khusus yang disebut koneksi lemah. Salah satu karakteristik yang membedakan koneksi yang lemah adalah tidak dapat menerima perutean koneksi klien karena lokasi instans sekunder di wilayah lain. Perutean klien ke wilayah lain bukanlah pilihan optimal (meningkatkan latensi).

Satu instans layanan dapat memiliki peran yang berbeda saat menyambungkan ke beberapa server aplikasi. Salah satu penyiapan umum untuk skenario lintas wilayah adalah memiliki dua pasang atau lebih instans layanan SignalR dan server aplikasi. Di dalam setiap pasangan server aplikasi dan layanan SignalR terletak di wilayah yang sama, dan layanan SignalR terhubung ke server aplikasi sebagai peran utama. Di antara setiap pasangan server aplikasi dan layanan SignalR juga terhubung, tetapi SignalR menjadi sekunder saat menghubungkan ke server di wilayah lain.

Dengan topologi ini, pesan dari satu server masih dapat dikirimkan ke semua klien karena semua server aplikasi dan instans layanan SignalR saling terhubung. Tetapi ketika klien terhubung, klien merutekan ke server aplikasi di wilayah yang sama untuk mencapai latensi jaringan yang optimal.

Diagram berikut mengilustrasikan topologi tersebut:

Mengonfigurasi beberapa instans layanan SignalR

Beberapa instans layanan SignalR didukung di server aplikasi dan Azure Functions.

Setelah Anda membuat layanan SignalR dan server aplikasi/Azure Functions yang dibuat di setiap wilayah, Anda dapat mengonfigurasi server aplikasi/Azure Functions Anda untuk menyambungkan ke semua instans layanan SignalR.

Konfigurasikan di server aplikasi

Ada dua cara yang dapat Anda lakukan:

Melalui konfigurasi

Anda harus tahu cara mengatur string koneksi layanan SignalR melalui variabel lingkungan/pengaturan aplikasi/web.cofig, dalam entri konfigurasi bernama Azure:SignalR:ConnectionString. Jika Anda memiliki beberapa titik akhir, Anda dapat mengaturnya dalam beberapa entri konfigurasi, masing-masing dalam format berikut:

Azure:SignalR:ConnectionString:<name>:<role>

Dalam Koneksi ionString, <name> adalah nama titik akhir dan <role> merupakan perannya (primer atau sekunder). Nama bersifat opsional tetapi berguna jika Anda ingin menyesuaikan perilaku perutean lebih lanjut di antara beberapa titik akhir.

Melalui kode

Jika Anda lebih suka menyimpan string koneksi di tempat lain, Anda juga dapat membacanya dalam kode Anda dan menggunakannya sebagai parameter saat menelepon AddAzureSignalR() (di ASP.NET Core) atau MapAzureSignalR() (di ASP.NET).

Berikut kode sampelnya.

ASP.NET Core:

services.AddSignalR()
        .AddAzureSignalR(options => options.Endpoints = new ServiceEndpoint[]
        {
            new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
            new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
        });

ASP.NET:

app.MapAzureSignalR(GetType().FullName, hub,  options => options.Endpoints = new ServiceEndpoint[]
    {
        new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
        new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
    };

Anda dapat mengonfigurasi beberapa instans primer atau sekunder. Jika ada beberapa instans utama dan/atau sekunder, negosiasi mengembalikan titik akhir dalam urutan berikut:

1. Jika setidaknya ada satu instans primer online, kembalikan instans online primer acak.
2. Jika semua instans primer mengalami gangguan, kembalikan instans online sekunder acak.

Mengonfigurasi pada Azure Functions

Lihat artikel ini.

Urutan failover dan praktik terbaik

Sekarang Anda memiliki pengaturan topologi sistem yang tepat. Setiap kali satu instans layanan SignalR tidak berfungsi, lalu lintas online dirutekan ke instans lain. Inilah yang terjadi ketika instans utama tidak berfungsi (dan pulih setelah beberapa waktu):

1. Instans layanan utama tidak berfungsi, semua koneksi server pada instans ini hilang.
2. Semua server yang terhubung ke instans ini menandainya sebagai offline, dan negosiasi berhenti mengembalikan titik akhir ini dan mulai mengembalikan titik akhir sekunder.
3. Semua koneksi klien pada instans ini juga ditutup, klien kemudian terhubung kembali. Karena server aplikasi sekarang mengembalikan titik akhir sekunder, klien terhubung ke instans sekunder.
4. Sekarang instans sekunder mengambil semua lalu lintas online. Semua pesan dari server ke klien masih dapat dikirim saat sekunder terhubung ke semua server aplikasi. Tetapi pesan klien ke server hanya dirutekan ke server aplikasi di wilayah yang sama.
5. Setelah instans primer dipulihkan dan kembali online, server aplikasi akan membangun kembali koneksi ke sana dan menandainya sebagai online. Negosiasi sekarang mengembalikan titik akhir utama lagi sehingga klien baru tersambung kembali ke primer. Tetapi klien yang ada tidak menjatuhkan dan masih dirutekan ke sekunder sampai mereka memutuskan sambungan sendiri.

Diagram di bawah ini menggambarkan bagaimana failover dilakukan dalam layanan SignalR:

Gambar.1 Sebelum failover

Gambar 2 Setelah failover

Gambar.3 Waktu singkat setelah primer pulih

Anda dapat melihat dalam kasus normal hanya server aplikasi primer dan layanan SignalR yang memiliki lalu lintas online (berwarna biru). Setelah failover, server aplikasi sekunder dan layanan SignalR juga menjadi aktif. Setelah layanan SignalR primer kembali online, klien baru akan terhubung ke SignalR primer. Tetapi klien yang ada masih terhubung ke sekunder sehingga kedua instans memiliki lalu lintas. Setelah semua klien yang ada terputus, sistem Anda akan kembali normal (Gbr.1).

Ada dua pola utama untuk menerapkan arsitektur lintas wilayah dengan ketersediaan tinggi:

1. Yang pertama adalah memiliki sepasang server aplikasi dan instans layanan SignalR mengambil semua lalu lintas online, dan memiliki pasangan lain sebagai cadangan (disebut aktif/pasif, diilustrasikan di Gambar.1).
2. Yang lain adalah memiliki dua (atau lebih) pasang server aplikasi dan instans layanan SignalR, masing-masing mengambil bagian dari lalu lintas online dan berfungsi sebagai cadangan untuk pasangan lain (disebut aktif/aktif, mirip dengan Gambar. 3).

Layanan SignalR dapat mendukung kedua pola tersebut, perbedaan utamanya adalah cara Anda menerapkan server aplikasi. Jika server aplikasi aktif/pasif, layanan SignalR juga aktif/pasif (karena server aplikasi utama hanya mengembalikan instans layanan SignalR utamanya). Jika server aplikasi aktif/aktif, layanan SignalR juga aktif/aktif (karena semua server aplikasi mengembalikan instans SignalR utama mereka sendiri, sehingga semuanya bisa mendapatkan lalu lintas).

Perhatikan pola mana pun yang Anda pilih untuk digunakan, Anda perlu menghubungkan setiap instans layanan SignalR ke server aplikasi sebagai utama.

Juga karena sifat koneksi SignalR (koneksinya panjang), klien mengalami penurunan koneksi ketika terjadi bencana dan failover. Anda perlu menangani kasus seperti itu di sisi klien untuk membuatnya transparan bagi pelanggan akhir Anda. Misalnya, sambungkan kembali setelah koneksi ditutup.

Cara menguji failover

Ikuti langkah-langkah untuk memicu failover:

1. Di tab Jaringan untuk sumber daya utama di portal, nonaktifkan akses jaringan publik. Jika sumber daya mengaktifkan jaringan privat, gunakan aturan kontrol akses untuk menolak semua lalu lintas.
2. Mulai ulang sumber daya utama.

Langkah berikutnya

Dalam artikel ini, Anda mempelajari cara mengonfigurasi aplikasi untuk mencapai ketahanan untuk layanan SignalR. Untuk memahami detail selengkapnya tentang koneksi server/klien dan perutean koneksi di layanan SignalR, Anda dapat membaca artikel ini untuk internal layanan SignalR.

Untuk skenario penskalaan seperti sharding yang menggunakan beberapa instans bersama-sama untuk menangani sejumlah besar koneksi, baca cara menskalakan beberapa instans.

Untuk detail tentang cara mengonfigurasi Azure Functions dengan beberapa instans layanan SignalR, baca beberapa dukungan instans Azure SignalR Service di Azure Functions.