Patriot Service Clustering
Requirements
- Patriot Enterprise Edition or Enterprise Database Module.
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
While Patriot recommends running Data Services and Task Services within a Failover Cluster, creating the cluster itself is outside the normal bounds of Patriot support and should be performed by suitably trained IT professionals. See Create a failover cluster for more information.
Cluster considerations
- Cluster servers (nodes) can be local Virtual Machines, Azure VMs, or physical servers. You will require at least two servers. If using VMs, ensure these are not on the same physical hypervisor / host.
- Shared storage will be required to reliably store local files. For on-premises deployments, a Storage Area Network (SAN) device is strongly recommended to provide storage-level redundancy. In Azure, Shared Disks can be used. The Data Service and Task Service will each need their own shared storage volume in the cluster.
The diagram below illustrates the basic structure of the Patriot Service cluster.
Azure Cluster
Patriot supports a full cloud based Azure Failover Cluster setup, which is set-up in a very similar manner to a traditional stand-alone WFC. However the shared storage requirement is replaced with Azure Share Disks (Zone-redundant storage type).
Workstations We recommend restricting which clients can connect to the data service. This can be done with a VPN between the workstations and the Patriot services, IP whitelisting, or by enabling encryption. You could also use Azure Desktop to host the Patriot workstations in Azure.
Public IP addresses are not required for the virtual servers to run.
However Patriot support will require remote access for remote support connections, this could be via a remote desktop software using port 443 or port 80.
Virtual Hardware Resources Resizing resources later can result in significant down time while resources are allocated from Microsoft, resource requirements should be considered carefully before beginning this process.
- Required shared Disk size may be impacted by floor plans, Patrol images, CCTV footage etc.
see Server Hardware as a guide for server requirements.
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. Tasks 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:
- Apply any updates to the non-active node(s)
- Perform a manual failover of services onto updated node(s)
- 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
- Apply the patch to all the non-active nodes. 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.
- Copy the patch file into the Shared Storage / PatriotDataService folder (to allow easy client patching).
- Inform operators to exit the Patriot client on all workstations. Use the Network Diagram feature to wait for all operators to log out.
- Manually failover the active node onto one of the newly patched nodes.
- 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.
- Finally apply the patch to the server node that was previously active.