Patriot Service Clustering

Requirements

Both the Patriot Data service and Patriot Task service can be installed in a Windows Failover Cluster configuration to provide a high availability solution.

The services are designed to be independent, and each service can failover within the cluster seamlessly with no disruption to other components in the system.

The Patriot Data Service and Task service can be installed on the same cluster as SQL but generally will be installed on a separate cluster. Generally the Data Service and Task Service would be installed together as separate resources within the same cluster.

Cluster Setup

Creating the cluster itself is outside the normal bounds of Patriot support and should be performed by suitably trained IT professionals.

Cluster considerations:

The diagram below illustrates the basic structure of the Patriot Service cluster.

Patriot cluster

Service Setup

Begin by installing both the Patriot Data and Task services on all nodes. This needs to be a local installation on each node, not an installation to a shared cluster storage drive. Using Windows Services, change each service to Manual Start mode, as the Cluster will be responsible for starting / stopping the services as required.

Once the services are installed, run the High Availability Wizard to add each service using the Generic Service option. In the Client Access Point section, give the service a unique name and static IP Address. This name will be used to reference the service by anything accessing it from outside the cluster. In the Select Storage page, assign a volume to the cluster that the service will use. No changes are required on the Replicate Registry Settings page.

When the roles for the services are setup using the High Availability Wizard, they will automatically enable the option 'Use Network Name As Hostname'. This option must remain checked for the services to function correctly.

Configuration

Any configuration changes such as config file settings, firewall changes or opened ports (e.g. Data Service, SQL Server, API Access) need to be made on all nodes.

External IP Clients

Any alarm receivers etc. which connect to the task service as IP clients will need to be configured to connect to the Task Service access point name or IP as entered during Task Service setup. If these IP Clients are remote, this may only require a reconfiguration of the NAT rules in the firewall.

Data Service

The Data Service will need to be configured to connect to the SQL Virtual Cluster Address (assuming SQL is also installed on a cluster). This will need to be performed on all individual nodes within the cluster. Use the Patriot configurator or edit the config settings file directly in the Data Service install folder.

Ensure the data service has been configured so the local resources are stored in shared storage. To configure this, edit the PatriotService.exe.config file in the Patriot Data Service installation folder. Look for the <PatriotService.Settings1> section, and update the following setting (add it if its missing):

<setting name="LocalStorageDirectory" serializeAs="String">

<value>C:\ClusterStorage\Volume1\PatriotDataService</value>

</setting>

In the above example the shared volume is located in C:\ClusterStorage\Volume1\, change this to the location of your shared volume. This will need to be performed on all individual nodes within the cluster.

Task Service

The Task Service will need to be configured to connect to the Data Service access point as entered during the Data Service setup. This will need to be performed on all individual nodes within the cluster. Use the Patriot configurator or edit the config settings file directly in the Task Service install folder.

In a non-cluster environment it is sometimes necessary to have multiple distinct Task Services running different tasks connected to your Data Service. This could be due to specific hardware requirements or when task load requires moving tasks off of the main server(s). When setting up the Task Service in the cluster each Task Service instance needed should be treated as completely separate service and all need to be clustered and have their own separate instance of shared storage. It is impossible for separate Task Services to run on the same server simultaneously, so each clustered Task Service will need its own set of nodes in the cluster. If some tasks are not able to be clustered such as a local serial device they should be moved to a non-clustered Task Service outside the cluster.

Ensure the Task Service has been configured so the local resources are stored in shared storage. To configure this, edit the CSMService.exe.config file in the Patriot Task Service installation folder. Look for the <CSMService.Settings1> section, and update the following setting (add it if its missing):

<setting name="LocalStorageDirectory" serializeAs="String">

<value>C:\ClusterStorage\Volume1\PatriotTaskService</value>

</setting>

In the above example the shared volume is located in C:\ClusterStorage\Volume1\, change this to the location of your shared volume. This will need to be performed on all individual nodes within the cluster.

Check that all tasks setup to run on the clustered Task Service are all configured to run using the Task Service access point name. Note that they will default to the node name when creating new tasks, and will need to be manually changed.

Client Configuration

Each Patriot Client will need to be configured to connect to the Data Service access point as entered during the Data Service setup. There is no other special setup or configuration required on the client.

Failover Procedures

A Failover Cluster has automatic failure recovery. If one of the nodes should fail, another node will take over automatically. This will have the effect of making the service unavailable momentarily. You may experience a short disruption and/or receive warning messages on the client, but it will reconnect automatically as soon as the failover has completed.

Any signals received during the failover are automatically cached and re-logged once service resumes. See Signal Caching for more information.

Applying Updates

Windows Updates

Windows Updates and other maintenance can easily be done in a clustered environment:

  1. Apply any updates to the non-active node(s)
  2. Perform a manual failover of services onto updated node(s)
  3. Apply any updates to the previously-active nodes which are now inactive

Patriot Patching

The recommended approach to patching the Patriot software in a clustered environment is as follows

  1. Apply the patch to all the non-active nodes. Note the auto patcher will default to not restarting the services and will give you a warning regarding this. Ignore the warning, the services should not be started on non-active nodes.
  2. Copy the patch file into the Shared Storage / PatriotDataService folder (to allow easy client patching).
  3. Inform operators to exit the Patriot client on all workstations. Use the Network Diagram feature to wait for all operators to log out.
  4. Manually failover the active node onto one of the newly patched nodes.
  5. Inform all operators to start the Patriot client. At this point the operators will be notified that a patch is available to be applied and request their confirmation before the patch is automatically applied.
  6. Finally apply the patch to the server node that was previously active.