From 60014a2818bd17c9fc5a1d0f4e9ba3d1794cfde2 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Thu, 13 Nov 2025 22:37:26 +0000 Subject: [PATCH 1/3] Initial plan From a476bea3c08d082676186686a79bb23207205f68 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Thu, 13 Nov 2025 22:43:22 +0000 Subject: [PATCH 2/3] Remove Orleans multi-clustering documentation Co-authored-by: ReubenBond <203839+ReubenBond@users.noreply.github.com> --- .../global-single-instance.md | 48 -------- .../multi-cluster-support/gossip-channels.md | 70 ----------- .../multi-cluster-configuration.md | 115 ------------------ .../multi-cluster-support/overview.md | 36 ------ .../silo-configuration.md | 77 ------------ .../event-sourcing/replicated-instances.md | 2 +- .../list-of-options-classes.md | 1 - docs/orleans/index.yml | 3 - docs/orleans/toc.yml | 12 -- 9 files changed, 1 insertion(+), 363 deletions(-) delete mode 100644 docs/orleans/deployment/multi-cluster-support/global-single-instance.md delete mode 100644 docs/orleans/deployment/multi-cluster-support/gossip-channels.md delete mode 100644 docs/orleans/deployment/multi-cluster-support/multi-cluster-configuration.md delete mode 100644 docs/orleans/deployment/multi-cluster-support/overview.md delete mode 100644 docs/orleans/deployment/multi-cluster-support/silo-configuration.md diff --git a/docs/orleans/deployment/multi-cluster-support/global-single-instance.md b/docs/orleans/deployment/multi-cluster-support/global-single-instance.md deleted file mode 100644 index 5a43ef2fa287f..0000000000000 --- a/docs/orleans/deployment/multi-cluster-support/global-single-instance.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Global single-instance grains -description: Learn about global single-instance grains and coordination attributes in .NET Orleans. -ms.date: 05/23/2025 -ms.topic: conceptual ---- - -# Grain coordination attributes - -You can indicate when and how clusters should coordinate their grain directories for a particular grain class. The means you want the same behavior as when running Orleans in a single global cluster: route all calls to a single activation of the grain. Conversely, the `[OneInstancePerCluster]` attribute indicates that each cluster can have its independent activation. This is appropriate if you don't want communication between clusters. - -Place the attributes on grain implementations. For example: - -```csharp -using Orleans.MultiCluster; - -[GlobalSingleInstance] -public class MyGlobalGrain : Orleans.Grain, IMyGrain -{ - // ... -} - -[OneInstancePerCluster] -public class MyLocalGrain : Orleans.Grain, IMyGrain -{ - // ... -} -``` - -If a grain class doesn't specify either of these attributes, it defaults to . However, it defaults to if you set the configuration parameter to `true`. - -## Protocol for global single-instance grains - -When you access a global-single-instance (GSI) grain, and no activation is known to exist, Orleans executes a special GSI activation protocol before activating a new instance. Specifically, it sends a request to all other clusters in the current [multi-cluster configuration](multi-cluster-configuration.md) to check if they already have an activation for this grain. If all responses are negative, Orleans creates a new activation in the current cluster. Otherwise, it uses the remote activation (and caches a reference to it in the local directory). - -## Protocol for one-instance-per-cluster grains - -There is no inter-cluster communication for one-instance-per-cluster grains. They simply use the standard Orleans mechanism independently within each cluster. Inside the Orleans framework itself, the following grain classes are marked with the : - -- `ManagementGrain` -- `SystemTargetBasedMembershipTable` -- `GrainBasedReminderTable` - -## Doubtful activations - -If the GSI protocol doesn't receive conclusive responses from all clusters after 3 retries (or the number specified by the configuration parameter), it optimistically creates a new local "doubtful" activation, favoring availability over consistency. - -"Doubtful" means the activation might be a duplicate because a remote cluster that didn't respond during the GSI protocol might still have an activation for this grain. Therefore, periodically, every 30 seconds (or the interval specified by the configuration parameter), Orleans runs the GSI protocol again for all doubtful activations. This process ensures that once communication between clusters is restored, the system can detect and remove duplicate activations. diff --git a/docs/orleans/deployment/multi-cluster-support/gossip-channels.md b/docs/orleans/deployment/multi-cluster-support/gossip-channels.md deleted file mode 100644 index d81d80e9e6e19..0000000000000 --- a/docs/orleans/deployment/multi-cluster-support/gossip-channels.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: Multi-cluster communication -description: Learn about multi-cluster communication in .NET Orleans. -ms.date: 05/23/2025 -ms.topic: conceptual ---- - -# Multi-cluster communication - -You must configure the network so that any Orleans silo can connect to any other Orleans silo via TCP/IP, regardless of where in the world it's located. Exactly how you achieve this is outside the scope of Orleans, as it depends on how and where you deploy the silos. - -For example, on Azure, you can use VNets to connect multiple deployments within a region and gateways to connect VNets across different regions. - -## Cluster identifier - -Each cluster has its own unique cluster ID. You must specify the cluster ID in the global configuration. - -Cluster IDs cannot be empty, nor can they contain commas. Also, if you use Azure Table Storage, cluster IDs cannot contain characters forbidden for row keys (/, \, #, ?). - -We recommend using very short strings for cluster IDs because they are transmitted frequently and might be stored in storage by some log-view providers. - -## Cluster gateways - -Each cluster automatically designates a subset of its active silos to serve as *cluster gateways*. Cluster gateways directly advertise their IP addresses to other clusters and can thus serve as "points of first contact". By default, Orleans designates at most 10 silos (or the number configured as ) as cluster gateways. - -Communication between silos in different clusters does *not* always pass through a gateway. Once a silo learns and caches the location of a grain activation (regardless of the cluster), it sends messages directly to that silo, even if the target silo isn't a cluster gateway. - -## Gossip - -Gossip is a mechanism for clusters to share configuration and status information. As the name suggests, gossip is decentralized and bidirectional: each silo communicates directly with other silos (both in the same cluster and in other clusters) to exchange information in both directions. - -**Content**: Gossip contains some or all of the following information: - -- The current time-stamped [multi-cluster configuration](multi-cluster-configuration.md). -- A dictionary containing information about cluster gateways. The key is the silo address, and the value contains (1) a timestamp, (2) the cluster ID, and (3) a status (either active or inactive). - -**Fast & Slow Propagation**: When a gateway changes its status, or when an operator injects a new configuration, this gossip information is immediately sent to all silos, clusters, and gossip channels. This happens quickly but isn't reliable. If the message is lost for any reason (for example,, races, broken sockets, silo failures), periodic background gossip ensures the information eventually spreads, albeit more slowly. All information eventually propagates everywhere and is highly resilient to occasional message loss and failures. - -All gossip data is timestamped. This ensures that newer information replaces older information, regardless of the relative timing of messages. For example, newer multi-cluster configurations replace older ones, and newer information about a gateway replaces older information about that gateway. For more details on the representation of gossip data, see the `MultiClusterData` class. It has a `Merge` method that combines gossip data, resolving conflicts using timestamps. - -## Gossip channels - -When a silo first starts, or when it restarts after a failure, it needs a way to **bootstrap the gossip**. This is the role of the *gossip channel*, which you can configure in the [Silo Configuration](silo-configuration.md). On startup, a silo fetches all information from the gossip channels. After startup, a silo continues gossiping periodically every 30 seconds (or the interval configured as `BackgroundGossipInterval`). Each time, it synchronizes its gossip information with a partner randomly selected from all cluster gateways and gossip channels. - -- Although not strictly required, we recommend always configuring at least two gossip channels in distinct regions for better availability. -- Latency of communication with gossip channels isn't critical. -- Multiple different services can use the same gossip channel without interference, as long as the `ServiceId` `Guid` (specified in their respective configurations) is distinct. -- There's no strict requirement that all silos use the same gossip channels, as long as the channels are sufficient to let a silo initially connect with the "gossiping community" when it starts. However, if a gossip channel isn't part of a silo's configuration, and that silo is a gateway, it doesn't push its status updates to that channel (fast propagation). Therefore, it might take longer for those updates to reach the channel via periodic background gossip (slow propagation). - -### Azure Table-based gossip channel - -We have implemented a gossip channel based on Azure Tables. The configuration specifies standard connection strings used for Azure accounts. For example, a configuration could specify two gossip channels with separate Azure storage accounts `usa` and `europe` as follows: - -```csharp -var silo = new HostBuilder() - .UseOrleans(builder => - { - builder.Configure(options => - { - options.GossipChannels.Add( - "AzureTable", - "DefaultEndpointsProtocol=https;AccountName=usa;AccountKey=..."); - options.GossipChannels.Add( - "AzureTable", - "DefaultEndpointsProtocol=https;AccountName=europe;AccountKey=...") - }); - }) -``` - -Multiple different services can use the same gossip channel without interference, as long as the `ServiceId` `Guid` specified by their respective configurations is distinct. diff --git a/docs/orleans/deployment/multi-cluster-support/multi-cluster-configuration.md b/docs/orleans/deployment/multi-cluster-support/multi-cluster-configuration.md deleted file mode 100644 index 1d6e2ad045944..0000000000000 --- a/docs/orleans/deployment/multi-cluster-support/multi-cluster-configuration.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Multi-cluster configuration -description: Learn about multi-cluster configuration in .NET Orleans. -ms.date: 05/23/2025 -ms.topic: conceptual ---- - -# Multi-cluster configuration - -The multi-cluster configuration determines which clusters are currently part of the multi-cluster. It doesn't change automatically; instead, the operator controls it. Thus, it's quite different from the membership mechanism used within a cluster, which automatically determines the set of silos that are part of that cluster. - -We use the following terminology for clusters in a service: - -- A cluster is *active* if it has at least one active silo, and *inactive* otherwise. -- A cluster is *joined* if it is part of the current multi-cluster configuration, and *non-joined* otherwise. - -Being active/inactive is independent of being joined/non-joined: all four combinations are possible. - -All clusters for a particular service connect via a [gossip network](gossip-channels.md). The gossip network propagates configuration and status information. - -## Inject a configuration - -An operator issues configuration changes by injecting them into the multi-cluster network. You can inject configurations into any cluster, and they spread from there to all active clusters. Each new configuration consists of a list of cluster IDs that form the multi-cluster. It also has a UTC timestamp used to track its propagation through the gossip network. - -Initially, the multi-cluster configuration is null, meaning the multi-cluster list is empty (contains no clusters). Thus, the operator *must* initially inject a multi-cluster configuration. Once injected, this configuration persists in all connected silos (while running) and in all specified gossip channels (if those channels are persistent). - -We impose some restrictions on injecting new configurations that an operator must follow: - -- Each new configuration may add several clusters, or remove some clusters (but not both at the same time). -- An operator should not issue a new configuration while a previous configuration change is still processing. - -These restrictions ensure that protocols like the single-instance protocol can correctly maintain the mutual exclusion of activations, even during configuration changes. - -### Management grain - -You can inject multi-cluster configurations on any node in any cluster using the Orleans Management Grain. -For example, to inject a multi-cluster configuration consisting of the three clusters { us1, eu1, us2 }, pass a string enumerable to the management grain: - -```csharp -var clusters = "us1,eu1,us2".Split(','); -var mgtGrain = client.GetGrain(0); -mgtGrain.InjectMultiClusterConfiguration(clusters, "my comment here")); -``` - -The first argument to is a collection of cluster IDs that defines the new multi-cluster configuration. The second argument is an optional comment string that you can use to tag configurations with arbitrary information, such as who injected them and why. - -There's an optional third argument, a boolean named `checkForLaggingSilosFirst`, which defaults to true. It means the system performs a best-effort check to see if any silos anywhere haven't caught up to the current configuration yet. If it finds such a silo, it rejects the change. This helps detect violations of the restriction that only one configuration change should be pending at a time (though it cannot guarantee this under all circumstances). - -### Default configuration - -In situations where the multi-cluster configuration is known in advance and the deployment is fresh every time (for testing), you might want to supply a default configuration. The global configuration supports an optional attribute which takes a comma-separated list of cluster IDs: - -```csharp -var silo = new HostBuilder() - .UseOrleans(builder => - { - builder.Configure(options => - { - options.DefaultMultiCluster = new[] { "us1", "eu1", "us2" }; - }) - }) - .Build(); -``` - -After a silo starts with this setting, it checks if the current multi-cluster configuration is null. If it is, the silo injects the given configuration with the current UTC timestamp. - -> [!WARNING] -> Persistent multi-cluster gossip channels (based on AzureTable) retain the last injected configuration unless they are deleted explicitly. In that case, specifying a `DefaultMultiCluster` has no effect when re-deploying a cluster because the configuration stored in the gossip channels is not null.> - -### Gossip channel - -An operator can also inject the configuration directly into the gossip channel. Periodic background gossip automatically picks up and propagates changes in the channel, although possibly very slowly (using the management grain is much faster). A rough estimate of the propagation time is 30 seconds (or the gossip interval specified in the global configuration) times the binary logarithm of the total number of silos across all clusters. However, since gossip pairs are selected randomly, propagation can be much quicker or much slower. - -If you use the Azure table-based gossip channel, operators can inject a new configuration simply by editing the configuration record in the `OrleansGossipTable` using a tool for editing Azure table data. The configuration record has the following format: - -| Name | Type | Value | -|-----------------|----------|---------------------------------------------------------| -| PartitionKey | String | the ServiceId | -| RowKey | String | "CONFIG" | -| Clusters | String | comma-separated list of cluster IDs, for example, "us1,eu1,us2" | -| Comment | String | optional comment | -| GossipTimestamp | DateTime | UTC timestamp for the configuration | - -> [!NOTE] -> When editing this record in storage, you must also set the `GossipTimestamp` to a newer value than its current value (otherwise, the change is ignored). The most convenient and recommended way to do this is to *delete the `GossipTimestamp` field*. The gossip channel implementation then automatically replaces it with a correct, current timestamp (it uses the Azure Table Timestamp). - -## Cluster procedures - -Adding or removing a cluster from the multi-cluster often needs coordination within a larger context. We recommend always following the procedures described below when adding or removing clusters from the multi-cluster. - -### Procedure for adding a cluster - -1. Start a new Orleans cluster and wait until all silos are up and running. -1. Inject a configuration that includes the new cluster. -1. Start routing user requests to the new cluster. - -### Procedure for removing a cluster - -1. Stop routing new user requests to the cluster. -1. Inject a configuration that no longer includes the cluster. -1. Stop all silos of the cluster. - -Once you remove a cluster this way, you can re-add it by following the procedure for adding a new cluster. - -## Activity on non-joined clusters - -There can be brief, temporary periods when a cluster is both active and non-joined: - -- A freshly started cluster might start executing code before it's included in the multi-cluster configuration (between steps 1 and 2 of the procedure for adding a cluster). -- A cluster being decommissioned might still execute code before the silos shut down (between steps 2 and 3 of the procedure for removing a cluster). - -During these intermediate situations, the following are possible: - -- For global-single-instance grains: A grain might have a duplicate activation on a non-joined cluster. -- For versioned grains: Activations on non-joined clusters don't receive notifications when the grain state changes. diff --git a/docs/orleans/deployment/multi-cluster-support/overview.md b/docs/orleans/deployment/multi-cluster-support/overview.md deleted file mode 100644 index 328960a67d494..0000000000000 --- a/docs/orleans/deployment/multi-cluster-support/overview.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Multi-cluster support -description: Learn about multi-cluster support in .NET Orleans. -ms.date: 05/23/2025 -ms.topic: overview ---- - -# Multi-cluster support - -> [!IMPORTANT] -> Multi-Cluster support was removed in Orleans v2. The documentation below refers to Orleans v1. - -Orleans v1.3.0 added support for federating several Orleans clusters into a loosely connected *multi-cluster* that acts as a single service. Multi-clusters facilitate *geo-distribution* as a service, making it easier to run an Orleans application in multiple data centers around the world. You can also run a multi-cluster within a single datacenter to get better failure and performance isolation. - -All mechanisms are designed with particular attention to: - -1. Minimize communication between clusters. -1. Let each cluster run autonomously, even if other clusters fail or become unreachable. - -## Configuration and operation - -Below, we document how to configure and operate a multi-cluster. - -[**Communication**](gossip-channels.md): Clusters communicate via the same silo-to-silo connections used within a cluster. To exchange status and configuration information, clusters use a gossip mechanism and gossip channel implementations. - -[**Silo Configuration**](silo-configuration.md): You need to configure silos so they know which cluster they belong to (each cluster is identified by a unique string). Also, you need to configure each silo with connection strings that allow it to connect to one or more [gossip channels](gossip-channels.md) on startup. - -[**Multi-Cluster Configuration Injection**](multi-cluster-configuration.md): At runtime, the service operator can specify and/or change the *multi-cluster configuration*, which contains a list of cluster IDs, to specify which clusters are part of the current multi-cluster. You do this by calling the management grain in any one of the clusters. - -## Multi-cluster grains - -Below, we document how to use multi-cluster functionality at the application level. - -[**Global-Single-Instance Grains**](global-single-instance.md): You can indicate when and how clusters should coordinate their grain directories for a particular grain class. The means you want the same behavior as when running Orleans in a single global cluster: route all calls to a single activation of the grain. Conversely, the indicates that each cluster can have its independent activation. This is appropriate if you don't want communication between clusters. - -**Log-view grains** *(not in v1.3.0)*: A special type of grain that uses a new API, similar to event sourcing, for synchronizing or persisting grain state. You can use it to automatically and efficiently synchronize the state of a grain between clusters and with storage. Because its synchronization algorithms are safe for use with reentrant grains and are optimized for batching and replication, it can perform better than standard grains when a grain is frequently accessed in multiple clusters and/or written to storage frequently. Support for log-view grains isn't part of the main branch yet. We have a prerelease including samples and some documentation in the [`geo-orleans` branch](https://github.com/sebastianburckhardt/orleans/tree/geo-samples). It's currently being evaluated in production by an early adopter. diff --git a/docs/orleans/deployment/multi-cluster-support/silo-configuration.md b/docs/orleans/deployment/multi-cluster-support/silo-configuration.md deleted file mode 100644 index a18d3ff12669f..0000000000000 --- a/docs/orleans/deployment/multi-cluster-support/silo-configuration.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: Silo configuration -description: Learn about silo configuration for multi-cluster support in .NET Orleans. -ms.date: 05/23/2025 -ms.topic: conceptual -ms.custom: sfi-ropc-nochange ---- - -# Orleans silo configuration - -For a quick overview, we show all relevant configuration parameters (including optional ones) in XML syntax below: - -```xml - - - - - - - - - - -``` - -```csharp -var silo = new HostBuilder() - .UseOrleans(builder => - { - builder.Configure(options => - { - options.ClusterId = "us3"; - options.ServiceId = "myawesomeservice"; - }) - .Configure(options => - { - options.HasMultiClusterNetwork = true; - options.DefaultMultiCluster = new[] { "us1", "eu1", "us2" }; - options.BackgroundGossipInterval = TimeSpan.FromSeconds(30); - options.UseGlobalSingleInstanceByDefault = false; - options.GlobalSingleInstanceRetryInterval = TimeSpan.FromSeconds(30); - options.GlobalSingleInstanceNumberRetries = 3; - options.MaxMultiClusterGateways = 10; - options.GossipChannels.Add( - "AzureTable", - "DefaultEndpointsProtocol=https;AccountName=usa;AccountKey=..."); - options.GossipChannels.Add( - "AzureTable", - "DefaultEndpointsProtocol=https;AccountName=europe;AccountKey=...") - }); - }); -``` - -As usual, you can also read and write all configuration settings programmatically via the respective members of the class. - -The is an arbitrary ID for identifying this service. It must be the same for all clusters and all silos. - -The `MultiClusterNetwork` section is optional. If it's not present, all multi-cluster support is disabled for this silo. - -The **required parameters** and are explained in [Multi-cluster communication](gossip-channels.md). - -The optional parameters and are explained in [Multi-cluster communication](gossip-channels.md). - -The optional parameter is explained in [Multi-cluster configuration](multi-cluster-configuration.md). - -The optional parameters , , and are explained in [Global single-instance grains](global-single-instance.md). - -## Orleans client configuration - -No extra configuration is required for the Orleans client. The same client cannot connect to silos in different clusters (the silo refuses the connection in that situation). diff --git a/docs/orleans/grains/event-sourcing/replicated-instances.md b/docs/orleans/grains/event-sourcing/replicated-instances.md index ffcb1416e0230..6a1994dd3d175 100644 --- a/docs/orleans/grains/event-sourcing/replicated-instances.md +++ b/docs/orleans/grains/event-sourcing/replicated-instances.md @@ -7,7 +7,7 @@ ms.topic: conceptual # Replicated grains -Sometimes, multiple instances of the same grain can be active, such as when operating a multi-cluster and using the . `JournaledGrain` is designed to support replicated instances with minimal friction. It relies on *log-consistency providers* to run the necessary protocols ensuring all instances agree on the same sequence of events. In particular, it handles the following aspects: +Multiple instances of the same grain can be active in certain scenarios. `JournaledGrain` is designed to support replicated instances with minimal friction. It relies on *log-consistency providers* to run the necessary protocols ensuring all instances agree on the same sequence of events. In particular, it handles the following aspects: - **Consistent versions**: All versions of the grain state (except tentative versions) are based on the same global sequence of events. In particular, if two instances see the same version number, they see the same state. diff --git a/docs/orleans/host/configuration-guide/list-of-options-classes.md b/docs/orleans/host/configuration-guide/list-of-options-classes.md index 1f4003a4ee2f4..5a7417d2361ba 100644 --- a/docs/orleans/host/configuration-guide/list-of-options-classes.md +++ b/docs/orleans/host/configuration-guide/list-of-options-classes.md @@ -37,7 +37,6 @@ All options classes used to configure Orleans are found in the `Orleans.Configur | | Options for grain garbage collection | | | Governs grain implementation selection in heterogeneous deployments | | | Settings for load shedding configuration. Must have a registered implementation of such as through or (Windows only) for `LoadShedding` to function. | -| | Options for configuring multi-cluster support | | | Performance tuning options (networking, number of threads) | | | Configure silo behavior on process exit | | | Configuring scheduler behavior | diff --git a/docs/orleans/index.yml b/docs/orleans/index.yml index 4a10724fe0b0c..4127a538215f8 100644 --- a/docs/orleans/index.yml +++ b/docs/orleans/index.yml @@ -95,9 +95,6 @@ conceptualContent: - itemType: concept text: Azure Container Apps url: deployment/deploy-to-azure-container-apps.md - - itemType: concept - text: Multi-cluster deployment - url: deployment/multi-cluster-support/overview.md - title: Host Orleans apps links: - itemType: get-started diff --git a/docs/orleans/toc.yml b/docs/orleans/toc.yml index dfe8f075f6811..72ec1a29e0fc7 100644 --- a/docs/orleans/toc.yml +++ b/docs/orleans/toc.yml @@ -197,18 +197,6 @@ items: href: deployment/docker-deployment.md - name: Troubleshoot deployments href: deployment/troubleshooting-deployments.md - - name: Multi-cluster support - items: - - name: Overview - href: deployment/multi-cluster-support/overview.md - - name: Multi-cluster configuration - href: deployment/multi-cluster-support/multi-cluster-configuration.md - - name: Gossip channels - href: deployment/multi-cluster-support/gossip-channels.md - - name: Silo configuration - href: deployment/multi-cluster-support/silo-configuration.md - - name: Global-single-instance grains - href: deployment/multi-cluster-support/global-single-instance.md - name: Code samples items: - name: Overview From def55fc6f00291abb92df745da886fbd6a8d6639 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 14 Nov 2025 15:02:03 +0000 Subject: [PATCH 3/3] Add redirections for deleted multi-cluster support pages Co-authored-by: ReubenBond <203839+ReubenBond@users.noreply.github.com> --- .openpublishing.redirection.orleans.json | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/.openpublishing.redirection.orleans.json b/.openpublishing.redirection.orleans.json index 7bd96a87a188f..667ca31b549bc 100644 --- a/.openpublishing.redirection.orleans.json +++ b/.openpublishing.redirection.orleans.json @@ -43,6 +43,26 @@ { "source_path_from_root": "/docs/orleans/implementation/cluster-configuration.md", "redirect_url": "/dotnet/orleans/implementation/cluster-management" + }, + { + "source_path_from_root": "/docs/orleans/deployment/multi-cluster-support/global-single-instance.md", + "redirect_url": "/dotnet/orleans/deployment/" + }, + { + "source_path_from_root": "/docs/orleans/deployment/multi-cluster-support/gossip-channels.md", + "redirect_url": "/dotnet/orleans/deployment/" + }, + { + "source_path_from_root": "/docs/orleans/deployment/multi-cluster-support/multi-cluster-configuration.md", + "redirect_url": "/dotnet/orleans/deployment/" + }, + { + "source_path_from_root": "/docs/orleans/deployment/multi-cluster-support/overview.md", + "redirect_url": "/dotnet/orleans/deployment/" + }, + { + "source_path_from_root": "/docs/orleans/deployment/multi-cluster-support/silo-configuration.md", + "redirect_url": "/dotnet/orleans/deployment/" } ]