Orleans runs on a cluster of servers in a data center, each running a container process that creates and hosts actor activation. A service built on Orleans is deployed on a cluster of nodes. When deployed to a cluster of nodes, Orleans internally implements a set of protocols to discover and maintain membership of Orleans silos in the cluster, including detection of node failures and automatic reconfiguration.
Cluster management is supported in Orleans via a built in membership protocol, also referred to as Silo membership. The goal of this protocol is for all silos to agree on the set of currently alive silos, detect failed silos, and allow new silos to join the cluster. For reliable management of cluster membership, Orleans uses Azure Table, SQL Server or Apache ZooKeeper for synchronization of nodes.
This post we’ll see how we can use the SQL server implementation of the membership table and make use of the cluster management feature.
Step 1: Creating the database
Create a new database OrleansMembership in your SQL server and run the below given script to create the required tables and data for SQL server membership provider.
Step 2: Configuring the membership setup in the SystemStore element settings:
In the silo configuration file (OrleansConfiguration.xml), add a new section SystemStore in the Globals section with the connection string for the OrleansMembership table we created in step 1.
<Liveness LivenessType="SqlServer" />
DataConnectionString="Data Source=.\SQLEXPRESS;Initial Catalog=OrleansMembership;Integrated Security=True;Pooling=False;Max Pool Size=200;Asynchronous Processing=True;MultipleActiveResultSets=True"
Step 3: Update the silo projects with the nuget packages for sql client and sql utils:
Step 4: Update the client configuration with the membership table information:
The client configuration should also be updated with the OrleansMembership table using the SystemStore element.
<Statistics MetricsTableWriteInterval="300s" PerfCounterWriteInterval="30s" LogWriteInterval="300s" WriteLogStatisticsToTable="true" StatisticsCollectionLevel="Info"/>
<Messaging ResponseTimeout="30s" ClientSenderBuckets="8192" MaxResendCount="0"/>
<SystemStore SystemStoreType ="SqlServer"
DataConnectionString="Data Source=.\SQLEXPRESS;Initial Catalog=OrleansMembership;Integrated Security=True;Pooling=False;Max Pool Size=200;Asynchronous Processing=True;MultipleActiveResultSets=True" AdoInvariant="System.Data.SqlClient" />
Also notice that you don't need to use the ProxyingGateway anymore for the Primary silo address. Instead the client can now use the membership data for grain references.
We have created a reliable deployment that is configured with membership using SQL server. In this case, all silos are created equal, with no notion of a primary of secondary silos. This is the recommended production deployment scenario where a failure of a single node or a combination of nodes does not affect other silos in the cluster. This also means that you don't need to provide a Seed node option in your silo configuration anymore!!!