Geo-replication in Azure SignalR

Companies seeking local presence or requiring a robust failover system often choose to deploy services across multiple Azure regions. With the integration of geo-replication in Azure SignalR, managing multi-region scenarios has become significantly easier.

Benefits of using geo-replication

• More resilient to regional outage: If a regional outage happens, the Azure SignalR DNS will be resolved to healthy replicas in other regions.
• Cross Region Communication. Different replicas could communicate with each other as if they are the same instance.
• Enhanced network speed: Geographically dispersed clients will connect to the nearest replica. These replicas communicate through Azure global network backbone, ensuring fast and stable networking.
• Shared configurations. All replicas retain the primary Azure SignalR Service resource's configuration.

Prerequisites

• An Azure SignalR Service in Premium tier.

• The user needs following permissions to operate on replicas:

  Permission	Description
  Microsoft.SignalRService/signalr/replicas/write	create, update or delete a replica.
  Microsoft.SignalRService/signalr/replicas/read	get meta data of a replica.
  Microsoft.SignalRService/signalr/replicas/action	perform actions on a replica, such as restarting.

Create a SignalR replica

@description('The name for your SignalR service')
param primaryName string = 'contoso'

@description('The region in which to create your SignalR service')
param primaryLocation string = 'chinaeast'

@description('Unit count of your SignalR service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/signalr@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your SignalR replica')
param replicaName string = 'contoso-chinanorth'

@description('The region in which to create the SignalR replica')
param replicaLocation string = 'chinanorth'

@description('Unit count of the SignalR replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/signalr/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

az group create --name MyResourceGroup --location chinaeast
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

Pricing and resource unit

Each replica has its own unit and autoscale settings.

Replica is a feature of Premium tier of Azure SignalR Service. Each replica is billed separately according to its own unit and outbound traffic. Free message quota is also calculated separately.

There will be egress fees for cross region outbound traffic. If a message is transferred across replicas and successfully sent to a client or server after the transfer, it will be billed as an outbound message.

Delete a replica

After you've created a replica for your Azure SignalR Service, you can delete it at any time if it's no longer needed.

To delete a replica in the Azure portal:

1. Navigate to your Azure SignalR Service, and select Replicas blade. Click the replica you want to delete.
2. Click Delete button on the replica overview blade.

Understand how the SignalR replica works

The diagram below provides a brief illustration of the SignalR Replicas' functionality:

1. The client negotiates with the app server and receives a redirection to the Azure SignalR service. It then resolves the SignalR service's Fully Qualified Domain Name (FQDN) — contoso.signalr.azure.cn. This FQDN points to a Traffic Manager, which returns the Canonical Name (CNAME) of the nearest regional SignalR instance.
2. With this CNAME, the client establishes a connection to the regional instance (Replica).
3. The two replicas will synchronize data with each other. Messages sent to one replica would be transferred to other replicas if necessary.
4. In case a replica fails the health check conducted by the Traffic Manager (TM), the TM will exclude the failed instance's endpoint from its domain resolution process. For details, refer to below Resiliency and Disaster Recovery

Resiliency and disaster recovery

Azure SignalR Service utilizes a traffic manager for health checks and DNS resolution towards its replicas. Under normal circumstances, when all replicas are functioning properly, clients will be directed to the closest replica. For instance:

• Clients close to chinaeast2 will be directed to the replica located in chinaeast2.
• Similarly, clients close to chinanorth2 will be directed to the replica in chinanorth2.

In the event of a regional outage in chinaeast2 (illustrated below), the traffic manager will detect the health check failure for that region. Then, this faulty replica's DNS will be excluded from the traffic manager's DNS resolution results. After a DNS Time-to-Live (TTL) duration, which is set to 90 seconds, clients in chinaeast2 will be redirected to connect with the replica in chinanorth2.

Once the issue in chinaeast2 is resolved and the region is back online, the health check will succeed. Clients in chinaeast2 will then, once again, be directed to the replica in their region. This transition is smooth as the connected clients will not be impacted until those existing connections are closed.

This failover and recovery process is automatic and requires no manual intervention.

For server connections, the failover and recovery work the same way as it does for client connections.

Impact on performance after adding replicas

After replicas are enabled, clients will naturally distribute based on their geographical locations. While SignalR takes on the responsibility to synchronize data across these replicas, you'll be pleased to know that the associated overhead on Server Load is minimal for most common use cases.

Specifically, if your application typically broadcasts to larger groups (size >10) or a single connection, the performance impact of synchronization is barely noticeable. If you're messaging small groups (size < 10) or individual users, you might notice a bit more synchronization overhead.

To ensure effective failover management, it is recommended to set each replica's unit size to handle all traffic. Alternatively, you could enable autoscaling to manage this.

For more performance evaluation, refer to Performance.