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 xmlns="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 xmlns="urn:orleans">
<Tracing DefaultTraceLevel="Info"
TraceToConsole="true"
TraceToFile="C:\OrleansLogs\WebApiClient-{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 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.
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!!!