Update SignalR serverless multiple endpoint doc

Author: Y-Sindo

articles/azure-signalr/signalr-concept-disaster-recovery.md

@@ -8,6 +8,7 @@ ms.devlang: csharp
 ms.custom: devx-track-csharp
 ms.date: 03/01/2019
 ms.author: lianwei
+zone_pivot_groups: azure-signalr-service-mode
 ---
 # Resiliency and disaster recovery in Azure SignalR Service
 
@@ -48,10 +49,9 @@ Multiple SignalR service instances are supported on both app servers and Azure F
 
 Once you have SignalR service and app servers/Azure Functions created in each region, you can configure your app servers/Azure Functions to connect to all SignalR service instances.
 
-### Configure on app servers
-There are two ways you can do it:
+:::zone pivot="default-mode"
 
-#### Through config
+### Through config
 
 You should already know how to set SignalR service connection string through environment variables/app settings/web.cofig, in a config entry named `Azure:SignalR:ConnectionString`.
 If you have multiple endpoints, you can set them in multiple config entries, each in the following format:
@@ -63,7 +63,7 @@ Azure:SignalR:ConnectionString:<name>:<role>
 In the ConnectionString, `<name>` is the name of the endpoint and `<role>` is its role (primary or secondary).
 Name is optional but it's useful if you want to further customize the routing behavior among multiple endpoints.
 
-#### Through code
+### Through code
 
 If you prefer to store the connection strings somewhere else, you can also read them in your code and use them as parameters when calling `AddAzureSignalR()` (in ASP.NET Core) or `MapAzureSignalR()` (in ASP.NET).
 
@@ -94,9 +94,86 @@ You can configure multiple primary or secondary instances. If there are multiple
 
 1. If there is at least one primary instance online, return a random primary online instance.
 2. If all primary instances are down, return a random secondary online instance.
+:::zone-end
+:::zone pivot="serverless-mode"
 
-### Configure on Azure Functions
-See [this article](https://github.com/Azure/azure-functions-signalrservice-extension/blob/dev/docs/sharding.md#configuration-method).
+### For SignalR Functions extensions
+
+To enable multiple SignalR Service instances, you should:
+
+1. Use `Persistent` transport type.
+
+    The default transport type is `Transient` mode. You should add the following entry to your `local.settings.json` file or the application setting on Azure.
+
+    ```json
+    {
+        "AzureSignalRServiceTransportType":"Persistent"
+    }
+    ```
+    >Notes for switching from `Transient` mode to `Persistent` mode on **Azure Functions runtime V3 and above** :
+    >
+    > Under `Transient` mode, `Newtonsoft.Json` library is used to serialize arguments of hub methods, however, under `Persistent` mode, `System.Text.Json` library is used as default on Azure Functions runtime V3 or above. `System.Text.Json` has some key differences in default behavior with `Newtonsoft.Json`. If you want to use `Newtonsoft.Json` under `Persistent` mode, you can add a configuration item: `"Azure:SignalR:HubProtocol":"NewtonsoftJson"` in `local.settings.json` file or `Azure__SignalR__HubProtocol=NewtonsoftJson` on Azure portal.
+
+
+2. Configure multiple SignalR Service endpoints entries in your configuration.
+
+    We use a [`ServiceEndpoint`](https://github.com/Azure/azure-signalr/blob/dev/src/Microsoft.Azure.SignalR.Common/Endpoints/ServiceEndpoint.cs) object to represent a SignalR Service instance. You can define an service endpoint with its `<EndpointName>` and `<EndpointType>` in the entry key, and the connection string in the entry value. The keys are in the following format :
+
+    ```
+    Azure:SignalR:Endpoints:<EndpointName>:<EndpointType>
+    ```
+
+    `<EndpointType>` is optional and defaults to `primary`. See samples below:
+
+    ```json
+    {
+        "Azure:SignalR:Endpoints:EastUs":"<ConnectionString>",
+
+        "Azure:SignalR:Endpoints:EastUs2:Secondary":"<ConnectionString>",
+
+        "Azure:SignalR:Endpoints:WestUs:Primary":"<ConnectionString>"
+    }
+    ```
+
+    > * When you configure Azure SignalR endpoints in the App Service on Azure portal, don't forget to replace `":"` with `"__"`, the double underscore in the keys. For reasons, see [Environment variables](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-5.0#environment-variables).
+    >
+    > * Connection string configured with the key `{ConnectionStringSetting}` (defaults to "AzureSignalRConnectionString") is also recognized as a primary service endpoint with empty name. But this configuration style is not recommended for multiple endpoints.
+
+### For [Management SDK](./signalr-howto-use-management-sdk.md)
+#### Add multiple endpoints from config
+
+Configure with key `Azure:SignalR:Endpoints` for SignalR Service connection string. The key should be in the format `Azure:SignalR:Endpoints:{Name}:{EndpointType}`, where `Name` and `EndpointType` are properties of the `ServiceEndpoint` object, and are accessible from code.
+
+You can add multiple instance connection strings using the following `dotnet` commands:
+
+```cmd
+dotnet user-secrets set Azure:SignalR:Endpoints:east-region-a <ConnectionString1>
+dotnet user-secrets set Azure:SignalR:Endpoints:east-region-b:primary <ConnectionString2>
+dotnet user-secrets set Azure:SignalR:Endpoints:backup:secondary <ConnectionString3>
+```
+
+#### Add multiple endpoints from code
+
+A `ServiceEndpoint` class describes the properties of an Azure SignalR Service endpoint.
+You can configure multiple instance endpoints when using Azure SignalR Management SDK through:
+```cs
+var serviceManager = new ServiceManagerBuilder()
+                    .WithOptions(option =>
+                    {
+                        options.Endpoints = new ServiceEndpoint[]
+                        {
+                            // Note: this is just a demonstration of how to set options.Endpoints
+                            // Having ConnectionStrings explicitly set inside the code is not encouraged
+                            // You can fetch it from a safe place such as Azure KeyVault
+                            new ServiceEndpoint("<ConnectionString0>"),
+                            new ServiceEndpoint("<ConnectionString1>", type: EndpointType.Primary, name: "east-region-a"),
+                            new ServiceEndpoint("<ConnectionString2>", type: EndpointType.Primary, name: "east-region-b"),
+                            new ServiceEndpoint("<ConnectionString3>", type: EndpointType.Secondary, name: "backup"),
+                        };
+                    })
+                    .BuildServiceManager();
+```
+:::zone-end
 
 ## Failover sequence and best practice
 
@@ -127,7 +204,7 @@ After all existing clients disconnect, your system will be back to normal (Fig.1
 
 There are two main patterns for implementing a cross region high available architecture:
 
-1. The first one is to have a pair of app server and SignalR service instance taking all online traffic, and have another pair as a backup (called active/passive, illustrated in Fig.1). 
+1. The first one is to have a pair of app server and SignalR service instance taking all online traffic, and have another pair as a backup (called active/passive, illustrated in Fig.1).
 2. The other one is to have two (or more) pairs of app servers and SignalR service instances, each one taking part of the online traffic and serves as backup for other pairs (called active/active, similar to Fig.3).
 
 SignalR service can support both patterns, the main difference is how you implement app servers.
@@ -143,7 +220,7 @@ You need to handle such cases at client side to make it transparent to your end
 
 Follow the steps to trigger the failover:
 1. In the Networking tab for the primary resource in the portal, **disable** public network access. If the resource has private network enabled, use *access control rules* to deny all the traffic.
-2. **Restart** the primary resource.  
+2. **Restart** the primary resource.
 
 ## Next steps