ServiceControl only supports active/passive clusters. Clustering might not be required as cloud hosting and enterprise virtualization layers provide high availability and data redundancy features and message queueing ensures no messages are lost.
The following procedure is a high level guide on how to deploy ServiceControl onto a fault-tolerant cluster using Windows Failover Clustering.
This guide assumes that MSMQ is the underlying transport. Other transports work as long as these are deployed on a different machine. In that case, skip the MSMQ-specific steps.
Basic setup
- Set up a failover (active/passive) Windows cluster:
- Install ServiceControl on each node, adding it as a "generic service" using the cluster manager. This means that ServiceControl will failover automatically with the cluster.
- Set up an MSMQ cluster group. A cluster group is a group of resources that have a unique DNS name and can be addressed externally like a computer.
- Add the ServiceControl generic clustered service to the MSMQ cluster group:
- Ensure it depends on MSMQ and the MSMQ network name
- Check "use network name as computer name" in the service configuration
Once set up, the ServiceControl queues will be available on the cluster. The server name will be the MSMQ network name, not to be confused with the cluster name.
More information is available on Message Queuing in Server Clusters.
Database high availability
The RavenDB database must be located in shared storage that is highly available and fault tolerant. Shared storage does not mean a network share but shared cluster storage that allows low latency and exclusive access. Access to the data should always be 'local', although physically that data could be stored on a SAN. When this disk is mounted, RavenDB must be configured to use that location. See Customize RavenDB Embedded Location for more information on how to change the ServiceControl database location.
ServiceControl detailed configuration
Once the failover cluster is created and ServiceControl is installed, configure ServiceControl to run in a clustered environment.
The following steps must be applied to all ServiceControl installations on every node in the cluster.
URL ACL(s)
ServiceControl exposes an HTTP API that is used by ServicePulse and ServiceInsight. URL ACL(s) must be defined on each cluster node. The URL must be set to the cluster name and the ACL set to give permissions to the Service Account running ServiceControl.
The default installation of ServiceControl locks down access to localhost only. Once the URL ACL is changed from localhost to the cluster name ServiceControl is accessible from the network.
Configuration
ServiceControl configuration must be customized by changing the following settings:
DbPathto define the path to the shared location where the database will be storedHostnameandportto reflectcluster nameandportauditanderrorqueues to include thecluster name;
The following is a sample ServiceControl configuration file (ServiceControl.exe.config):
<configuration>
<appSettings>
<add key="ServiceControl/DbPath"
value="drive:\SomeDir\" />
<add key="ServiceControl/Hostname"
value="clusterName" />
<add key="ServiceControl/Port"
value="33333" />
<add key="ServiceBus/AuditQueue"
value="audit@clusterName" />
<add key="ServiceBus/ErrorQueue"
value="error@clusterName" />
<add key="ServiceBus/ErrorLogQueue"
value="error.log@clusterName" />
<add key="ServiceBus/AuditLogQueue"
value="audit.log@clusterName" />
</appSettings>
</configuration>
See Customizing ServiceControl Configuration for more information.