SQL clustering offers high availability for your SQL database, and Patriot supports connecting to a SQL clustered database.
The Patriot software itself is not cluster aware so doesn't fully support running on a clustered server. The following documentation relates to running SQL on a clustered server, and the Patriot services running on a separate non clustered server.
The setup of the SQL clustered machine is outside the bounds of Patriot support. This should be performed by suitably trained IT professionals.
Once the SQL clustered server is available, it can be thought of from a Patriot perspective as a normal SQL Server. The clustered SQL server will have one IP address for accessing the server.
Install the Patriot database using the Patriot setup wizard following the instructions for installing SQL on a standalone server (ie where the Patriot services are installed on a separate machine).
Then install the Patriot services on the Primary Patriot server, and optionally on the backup Patriot server. Configure the Data Services (on the primary and back server) to connect to the SQL Server. Leave the backup SQL server details empty.
Then configure the Task Service on the primary Patriot server to connect to the Data Service on the primary server, and set the back settings to connect to the backup Data Service. On the backup server, configure the settings for the task service in reverse, by setting the primary data service to the data service on the backup server, and the backup data service to the data service on the primary server. The Services on the backup server should be left turned off, once they have been tested.
Configure all workstations with both the primary data service settings, and backup data service settings.
Patriot software supports SQL Multi-Subnet clusters. If you are using a Multi-Subnet SQL cluster, Patriot should be configured to enable Multisubnet failover. This setting improves failover detection and recovery so it should always be enabled when using this server setup. To enable this mode, edit the PatriotService.exe.config file in the Patriot Data Service installation folder. Look for the <PatriotService.Settings1> section, and locate the following setting:
<setting name="SQLMultiSubnet" serializeAs="String">
<value>False</value>
</setting>
Change the value to True to enable the multisubnet support. If this setting is missing from your configuration file, add it below the other settings, or contact Patriot support for assistance.
The changes will take effect the next time that the Data Service is restarted.
Note: Multi-Subnet clustering is only supported in the Enterprise edition of Patriot or if you have the Enterprise Database module registered to your license.
IP receivers are recommended as they generally support dual path reporting better than serial receivers, but some serial receivers do have the capacity to dual report.
The receiver should be setup to report on its primary connection to the task service on the Patriot primary server, and its backup connection to the task service on the backup Patriot server. An appropriate receiver task will need to be setup on both the primary and backup task service. The receiver should be configured to failover to reporting on the backup connection only when the primary fails.
Patriot does not support reporting on both paths simultaneously, except when using two completely independent systems. This is not the recommended solution, as operators are required to maintain both systems at the same time.
A clustered SQL Server has built in redundancy. If one of the nodes should fail, another node will take over automaticially if required. This will have the effect of making SQL unavailable momentarily. The data service is designed to handle this situation. You may get notified that a signal failed to log, but it will get logged soon after on a retry once SQL comes back online. So no signal or data lose will occur in this situation. No intervention is required.
If there is a fault on the primary Patriot server, which stops the data service from working, the data service on the backup server will need to be manually started. If the task service on the primary Patriot server is unaffected by this fault, it will automatically switch over the backup data service. If the fault also stops the primary task service, the backup task service will also need to be manually started.
If the primary data service goes offline, the client programs will be notified very quickly. Once the backup data service is brought online, the clients will need to switch over to the backup data service. This can be done from the login window, or by clicking on the data service failure icon.
Use this procedure for regular failover testing, or when the fault on the primary server has been rectified, and you need to swap from the backup server, back to the primary server.
To avoid confusion because this procedure can be used to swap from the primary server to the backup server or the reverse, we will call the server running the servers as Server A, and the server that wants to be changed over to, Server B.
Stop the Task service on server A.
Stop the Data Service on server A.
Start the Data Service on Server B.
Start the Task Service on Server B.
Swap all workstations over to connect to Server B.