|
| 1 | +--- |
| 2 | +title: How to enable geo-replication |
| 3 | +description: How to enable geo-replication for Azure SignalR service |
| 4 | +author: biqian |
| 5 | + |
| 6 | +ms.author: biqian |
| 7 | +ms.date: 06/01/2023 |
| 8 | +ms.service: signalr |
| 9 | +ms.topic: how-to |
| 10 | +--- |
| 11 | + |
| 12 | +# Geo-replication (Preview) in Azure SignalR |
| 13 | + |
| 14 | +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. |
| 15 | + |
| 16 | +## Benefits of using geo-replication |
| 17 | +* **More resilient to regional outage:** If a regional outage happens, the Azure SignalR DNS will be resolved to healthy replicas in other regions. |
| 18 | +* **Cross Region Communication**. Different replicas could communicate with each other as if they are the same instance. |
| 19 | +* **Enhanced network speed:** Geographically dispersed clients will connect to the nearest replica. These replicas communicate through [Azure global network backbone](https://azure.microsoft.com/explore/global-infrastructure/global-network), ensuring fast and stable networking. |
| 20 | +* **Shared configurations**. All replicas retain the primary Azure SignalR Service resource's configuration. |
| 21 | + |
| 22 | +## Prerequisites |
| 23 | + |
| 24 | +* An Azure SignalR Service in [Premium tier](https://azure.microsoft.com/pricing/details/signalr-service/). |
| 25 | +* The user needs following permissions to operate on replicas: |
| 26 | + |
| 27 | + | Permission | Description | |
| 28 | + |---------------------------------------------------|---------------------------------------------------| |
| 29 | + | Microsoft.SignalRService/signalr/replicas/write | create, update or delete a replica. | |
| 30 | + | Microsoft.SignalRService/signalr/replicas/read | get meta data of a replica.| |
| 31 | + | Microsoft.SignalRService/signalr/replicas/action | perform actions on a replica, such as restarting. | |
| 32 | + |
| 33 | + |
| 34 | +## Example use case |
| 35 | +Contoso is a social media company with its customer base spread across the US and Canada. To serve those customers and let them communicate with each other, Contoso runs its services in Central US. Azure SignalR Service is used to handle user connections and facilitate communication among users. Contoso's end users are mostly phone users. Due to the long geographical distances, end-users in Canada might experience high latency and poor network quality. |
| 36 | + |
| 37 | + |
| 38 | + |
| 39 | +Before the advent of the geo-replication feature, Contoso could set up another Azure SignalR Service in Canada Central to serve its Canadian users. By setting up a geographically closer Azure SignalR Service, end users now have better network quality and lower latency. |
| 40 | + |
| 41 | +However, managing multiple Azure SignalR Services brings some challenges: |
| 42 | +1. A cross-region communication mechanism would be required to enable conversation between Canada and US users. |
| 43 | +2. The development team would need to manage two separate Azure SignalR Services, each with distinct domain and connection string. |
| 44 | +3. If a regional outage happens, the traffic needs to be switched to another region. |
| 45 | + |
| 46 | + |
| 47 | + |
| 48 | +## Harnessing geo-replication |
| 49 | +With the new geo-replication feature, Contoso can now establish a replica in Canada Central, effectively overcoming the above-mentioned hurdles. |
| 50 | + |
| 51 | + |
| 52 | + |
| 53 | +## Create a SignalR replica |
| 54 | + |
| 55 | +To create a replica, Navigate to the SignalR **Replicas** blade on the Azure portal and click **Add** to create a replica. It will be automatically enabled upon creation. |
| 56 | + |
| 57 | + |
| 58 | + |
| 59 | +> [!NOTE] |
| 60 | +> * Geo-replication is a feature available in premium tier. |
| 61 | +> * A replica is considered a separate resource when it comes to billing. See [Pricing](#pricing) for more details. |
| 62 | +
|
| 63 | +After creation, you would be able to view/edit your replica on the portal by clicking the replica name. |
| 64 | + |
| 65 | + |
| 66 | + |
| 67 | +## Pricing |
| 68 | +Replica is a feature of [Premium tier](https://azure.microsoft.com/pricing/details/signalr-service/) of Azure SignalR Service. Each replica is billed **separately** according to its own units and outbound traffic. Free message quota is also calculated separately. |
| 69 | + |
| 70 | +In the preceding example, Contoso added one replica in Canada Central. Contoso would pay for the replica in Canada Central according to its unit and message in Premium Price. |
| 71 | + |
| 72 | +## Delete a replica |
| 73 | +After you've created a replica for your Azure SignalR Service, you can delete it at any time if it's no longer needed. |
| 74 | + |
| 75 | +To delete a replica in the Azure portal: |
| 76 | + |
| 77 | +1. Navigate to your Azure SignalR Service, and select **Replicas** blade. Click the replica you want to delete. |
| 78 | +2. Click Delete button on the replica overview blade. |
| 79 | + |
| 80 | +## Understanding how the SignalR replica works |
| 81 | + |
| 82 | +The diagram below provides a brief illustration of the SignalR Replicas' functionality: |
| 83 | + |
| 84 | + |
| 85 | + |
| 86 | +1. The client resolves the Fully Qualified Domain Name (FQDN) `contoso.service.signalr.net` of the SignalR service. This FQDN points to a Traffic Manager, which returns the Canonical Name (CNAME) of the nearest regional SignalR instance. |
| 87 | +2. With this CNAME, the client establishes a connection to the regional instance. |
| 88 | +3. The two replicas will synchronize data with each other. Messages sent to one replica would be transferred to other replicas if necessary. |
| 89 | +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. |
| 90 | + |
| 91 | +> [!NOTE] |
| 92 | +> * In the data plane, a primary Azure SignalR resource functions identically to its replicas |
| 93 | +
|
| 94 | +## Impact on performance after adding replicas |
| 95 | + |
| 96 | +Post replica addition, your clients will be distributed across different locations based on their geographical locations. SignalR must synchronize data across these replicas. The cost for synchronization is negligible if your use case primarily involves sending to large groups (size >100) or broadcasting. However, the cost becomes more apparent when sending to smaller groups (size < 10) or a single user. |
| 97 | + |
| 98 | +To ensure effective failover management, it is recommended to set each replica's unit size to handle all traffic. Alternatively, you could enable [autoscaling](signalr-howto-scale-autoscale.md) to manage this. |
| 99 | + |
| 100 | +For more performance evaluation, refer to [Performance](signalr-concept-performance.md). |
0 commit comments