0 comments
.NET 
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.
<OrleansConfiguration >=“urn:orleans“>
<Globals>
<Liveness LivenessType=“SqlServer“ />
<SystemStore SystemStoreType=“SqlServer“
DeploymentId=“OrleansClusterDemo“
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“ />
</Globals>
</OrleansConfiguration>
Step 3: Update the silo projects with the nuget packages for sql client and sql utils:
“Microsoft.Orleans.OrleansSqlUtils”: “1.4.0”,
“System.Data.SqlClient”: “4.3.0”
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.
<ClientConfiguration >=“urn:orleans“>
<Gateway Address=“localhost“ Port=“30003“/>
<Tracing DefaultTraceLevel=“Info“
TraceToConsole=“true“
TraceToFile=“C:OrleansLogsWebApiClient-{0}-{1}.log“
WriteTraces=“false“/>
<Statistics MetricsTableWriteInterval=“300s“ PerfCounterWriteInterval=“30s“ LogWriteInterval=“300s“ WriteLogStatisticsToTable=“true“ StatisticsCollectionLevel=“Info“/>
<Messaging ResponseTimeout=“30s“ ClientSenderBuckets=“8192“ MaxResendCount=“0“/>
<SystemStore SystemStoreType =“SqlServer“
DeploymentId=“OrleansClusterDemo“
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“ />
</ClientConfiguration>
Also notice that you can use any of the ProxyingGateway address location of the silos instead of the Primary silo one.
Conclusion:
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!!!