Skip to content

Commit 95d2080

Browse files
authored
Merge pull request #241626 from bjqian/main
Add replica document for Azure SignalR and Azure Web PubSub
2 parents 8767207 + f810fa9 commit 95d2080

17 files changed

+205
-2
lines changed

articles/azure-signalr/TOC.yml

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -99,14 +99,16 @@
9999
href: ./security-controls-policy.md
100100
- name: How-to guides
101101
items:
102-
- name: Scale
102+
- name: Scale and geo-replicate
103103
items:
104104
- name: Single instance
105105
href: signalr-howto-scale-signalr.md
106106
- name: Multiple instances
107107
href: signalr-howto-scale-multi-instances.md
108108
- name: Autoscale
109109
href: signalr-howto-scale-autoscale.md
110+
- name: Geo-replication
111+
href: howto-enable-geo-replication.md
110112
- name: Secure
111113
items:
112114
- name: Access key rotation
Lines changed: 100 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,100 @@
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+
![Screenshot of using one Azure SignalR instance to handle traffic from two countries. ](./media/howto-enable-geo-replication/signalr-single.png "Single SignalR Example")
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+
![Screenshot of using two Azure SignalR instances to handle traffic from two countries. ](./media/howto-enable-geo-replication/signalr-multiple.png "Mutiple SignalR Example")
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+
![Screenshot of using one Azure SignalR instance with replica to handle traffic from two countries.](./media/howto-enable-geo-replication/signalr-replica.png "Replica Example")
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+
![Screenshot of creating replica for Azure SignalR on Portal.](./media/howto-enable-geo-replication/signalr-replica-create.png "Replica create")
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+
![Screenshot of overview blade of Azure SignalR replica resource. ](./media/howto-enable-geo-replication/signalr-replica-overview.png "Replica Overview")
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+
![Screenshot of the arch of Azure SignalR replica. ](./media/howto-enable-geo-replication/signalr-replica-arch.png "Replica Arch")
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).
82.2 KB
Loading
91.6 KB
Loading
79.3 KB
Loading
1.9 MB
Loading
81.4 KB
Loading
66.7 KB
Loading

articles/azure-web-pubsub/concept-billing-model.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -69,6 +69,12 @@ For example, an application that uses 6.25 units per day has a daily free quota
6969

7070
As a result, you'll be billed with 6.25 standard units and 8.75 additional message units for the day.
7171

72+
## How replica is billed
73+
74+
Replica is a feature of Premium tier of Azure Web PubSub service. When you create a replica in desired regions, you incur Premium fees for each region.
75+
76+
Each replica is billed separately according to its own units and outbound traffic. Free message quota is also calculated separately.
77+
7278
## Pricing
7379

7480
The Web PubSub service offers multiple tiers with different pricing. For more information about Web PubSub pricing, see [Azure Web PubSub service pricing](https://azure.microsoft.com/pricing/details/web-pubsub).
Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
---
2+
title: How to enable geo-replication for Azure Web PubSub
3+
description: How to enable geo-replication for Web PubSub service
4+
author: biqian
5+
6+
ms.author: biqian
7+
ms.date: 06/01/2023
8+
ms.service: azure-web-pubsub
9+
ms.topic: how-to
10+
---
11+
12+
# Geo-replication (Preview) in Azure Web PubSub
13+
14+
## What is geo-replication feature?
15+
Mission critical apps often need to have a robust failover system and serve users closer to where they are. Before the release of the geo-replication feature, developers needed to deploy multiple Web PubSub resources and write custom code to orchestrate communication across resources. Now, with quick configuration through Azure portal, you can easily enable this feature.
16+
17+
## Benefits of using geo-replication
18+
* **More resilient to regional outage:** If a regional outage happens, clients will be automatically routed to a healthy replica.
19+
* **Cross-region communication:** Developers use a geo-replication-enabled resource as usual, even though behind-the-scenes there are more than one resource. The communication across replicas is handled by the service.
20+
* **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.
21+
* **Ease of management**. All replicas share the configuration of the primary Web PubSub resource.
22+
23+
## Prerequisites
24+
* A Web PubSub resource in [premium tier](https://azure.microsoft.com/pricing/details/web-pubsub/).
25+
26+
## Example use case
27+
### Contoso, a social media company
28+
Contoso is a social media company with its customer base spread across the US and Canada. Contoso provides a mobile and web app to its users so that they can connect with each other. Contoso application is deployed in Central US. As part of Contoso's architecture, Web PubSub is used to establish persistent WebSocket connections between client apps and the application server. Contoso **likes** that they can offload managing WebSocket connections to Web PubSub, but **doesn't** like reading reports of users in Canada experiencing higher latency. Furthermore, Contoso's development team wants to insure the app against regional outage so that the users can access the app with no interruptions.
29+
30+
![Screenshot of using one Azure WebPubSub instance to handle traffic from two countries. ](./media/howto-enable-geo-replication/web-pubsub-single.png "Single WebPubSub Example")
31+
32+
Contoso **could** set up another Web PubSub resource in Canada Central which is geographically closer to its users in Canada. However, managing multiple Web PubSub resources brings some challenges:
33+
1. A cross-region communication mechanism would need to be implemented so that users in Canada and US can interact with each other.
34+
2. The development team would need to manage two separate Web PubSub resources, each with distinct domain and connection string.
35+
3. If a regional outage takes place, the traffic needs to be directed to an available resource.
36+
37+
All of the above takes engineering resources away from focusing on product innovation.
38+
39+
![Screenshot of using two Azure Web PubSub instances to handle traffic from two countries. ](./media/howto-enable-geo-replication/web-pubsub-multiple.png "Mutiple Web PubSub Example")
40+
41+
### Harnessing the geo-replication feature
42+
With the geo-replication feature, Contoso can now establish a replica in Canada Central, effectively overcoming the above-mentioned challenges. The developer team is glad to find out that they don't need to make any code changes. It's as easy as clicking a few buttons on Azure portal. The developer team is also happy to share with the stakeholders that as Contoso plans to enter the European market, they simply need to add another replica in Europe.
43+
44+
![Screenshot of using one Azure Web PubSub instance with replica to handle traffic from two countries.](./media/howto-enable-geo-replication/web-pubsub-replica.png "Replica Example")
45+
46+
## How to enable geo-replication in a Web PubSub resource
47+
To create a replica in an Azure region, go to your Web PubSub resource and find the **Replicas** blade on the Azure portal and click **Add** to create a replica. It will be automatically enabled upon creation.
48+
49+
![Screenshot of creating replica for Azure Web PubSub on Portal.](./media/howto-enable-geo-replication/web-pubsub-replica-create.png "Replica create")
50+
51+
After creation, you would be able to view/edit your replica on the portal by clicking the replica name.
52+
53+
![Screenshot of overview blade of Azure Web PubSub replica resource. ](./media/howto-enable-geo-replication/web-pubsub-replica-overview.svg "Replica Overview")
54+
55+
> [!NOTE]
56+
> * Geo-replication is a feature available in premium tier.
57+
> * A replica is considered a separate resource when it comes to billing. See [Pricing](concept-billing-model.md#how-replica-is-billed) for more details.
58+
59+
## Delete a replica
60+
After you've created a replica for a Web PubSub resource, you can delete it at any time if it's no longer needed.
61+
62+
To delete a replica in the Azure portal:
63+
64+
1. Navigate to your Web PubSub resource, and select **Replicas** blade. Click the replica you want to delete.
65+
2. Click Delete button on the replica overview blade.
66+
67+
## Impact on performance after enabling geo-replication feature
68+
After a replica is created, your clients will be distributed across selected Azure regions based on their geographical locations. Web PubSub service handles synchronizing data across these replicas automatically and this synchronization incurs a low level of cost. The cost is negligible if your use case primarily involves `sendToGroup()` where the group has more than 100 connections. However, the cost may become more apparent when sending to smaller groups (connection count < 10) or a single user.
69+
70+
For more performance evaluation, refer to [Performance](concept-performance.md).
71+
72+
## Best practices
73+
To ensure effective failover management, it is recommended to enable [autoscaling](howto-scale-autoscale.md) for the resource and its replicas. If there are two replicas in a Web PubSub resource and one of the replicas is not available due to an outage, the available replica will receive all the traffic and handle all the WebSocket connections. Auto-scaling can scale up to meet the demand automatically.
74+
> [!NOTE]
75+
> * Autoscaling for replica is configured on its own resource level. Scaling primary resource won't change the unit size of the replica.
76+
77+
## Understand how the geo-replication feature works
78+
79+
![Screenshot of the arch of Azure Web PubSub replica. ](./media/howto-enable-geo-replication/web-pubsub-replica-arch.png "Replica Arch")
80+
81+
1. The client resolves the Fully Qualified Domain Name (FQDN) `contoso.webpubsub.azure.com` of the Web PubSub service. This FQDN points to a Traffic Manager, which returns the Canonical Name (CNAME) of the nearest regional Web PubSub instance.
82+
2. With this CNAME, the client establishes a websocket connection to the regional instance.
83+
3. The two replicas will synchronize data with each other. Messages sent to one replica would be transferred to other replicas if necessary.
84+
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 results.
85+
86+
> [!NOTE]
87+
> * In the data plane, a primary Azure Web PubSub resource functions identically to its replicas
88+
89+
----

0 commit comments

Comments
 (0)