Sample High Availability plan
Introduction
High availability (aka HA) refers to a system or component that is continuously operational for a desirably long length of time.
Planning
WorkFusion platform has multiple system components and hence each component can have its own HA plan. To achieve high availability its advisable to have standby servers similar to primary servers.
Platform Monitor Server
WorkFusion Platform Monitor is a proprietary system, allowing to measure and control the application health by analyzing multiple metrics of the target system. This application component should be restored before any other components. This is required to monitor the health of other application/system components switch over.
The HA of platform monitor component is achieved using Active-Passive model where standby server is to be brought up if primary server is down. The preparation of the secondary stand by can be chosen from any of the recommended strategies. The standby server should have the same DNS name as of primary, which can be achieved using DNS Switch over, so that no configuration changes are required in other application components.
Database Server
The WorkFusion Platform has two important database servers namely MySQL and PostgreSQL. In current context the database servers are primary database server and secondary database server, where primary is active while secondary is passive, either of following approaches can be taken to achieve standby server.
- DB Server sharing same highly available db storage (e.g. NAS)
- Continuous Replication
- Hypervisor
- Backup and Restore
The performance of the software and databases stored on NAS devices depends on the performance of the network connection between the DB server and the NAS device.
For this reason, WorkFusion recommends that you connect the server to the NAS device using a private dedicated network connection, which should be Gigabit Ethernet or better. In case of failure of first db instance, a dns switch over of the database server is done, this need to be done for no configuration changes in the other calling WorkFusion application components. Once an appropriate strategy of having standby DB server is chosen then the bringing up of the DB service is same as standard maintenance.
Application Server
WorkFusion APP includes Control Tower, Workspace and RPA Manager. High Availability is achieved using Active-Passive model, where the secondary system is in stand by.
The secondary system can be created using Hypervisor or Warm Site Strategies, where the secondary system can be brought using standard services maintenance. In case of failure of primary WorkFusion APP, the standby server is started, where a dns switch over of application server is done, keeping the same dns name as it was for the primary. The load balancer can also be configured in a way that dynamic service resolution of active service can be identified.
OCR Server
OCR is a shared stateless component which only stores current in-progress request. In case of any in-progress entry is lost, the request might be resubmitted by the core application services.
Any of the below recommended approaches can be adopted
- Active Passive fail-over to the Local Server or the Warm Site instance occurs the same way, by a DNS switch to preserve a component FQDN while an actual endpoint IP address might differ.
- Hypervisor. When standby server is made active, the dns name should be preserved as same it was configured for previous active server.
RPA Cluster
RPA cluster consists of a set of Windows-based machines with stateless components pre-provisioned. No operational data is required to be restored in order to recover the service, which means that the fail over procedure include only configuration switch.
Fail over to the Local Server is based on built-in MS Terminal Server capabilities, as the RPA Grid is based on Selenograph cluster which is able to detect execution nodes availability and redirect RPA requests to available server.
ML Server
ML is a shared stateless component which operates with a two major types of data:
- In-progress request data so the NAS Mirroring is sufficient to provide a data required to recover the service. In case of any in-progress entry is lost, the request might be resubmitted by the core application services.
- Static rarely updated file-based data, which means that NAS Mirror can provide a reliable recovery of N-1 version of the model which is enough for the most cases. To ensure that the most recent data model is recovered, staging or backup data can be used.
Fail over to the Local Server or the Warm Site instance occurs the same way, by a DNS switch to preserve a component FQDN while an actual endpoint IP address might differ.