High availability overview
Architecture
The HA architecture implies having several instances of each server, where one is primary and the others are emergency ones. To provide the availability of services and connectivity among servers, the load balancer is used. The data is replicated via a shared file system. If a server or a component is disabled for any reason, data can still be read from another server.
HA covers both servers' and components' failures. Depending on the type of redundancy in software to be provided for High Availability, the following strategies for servers and components are applied:
- Active-Active: the component is running on both primary and secondary servers in parallel with the data replicated among them. If a server fails, the other takes its place.
- Active-Warm Standby: the component runs on the primary server. The other servers are warm standby, which means all of them are working, while the component is installed on them but not running. In the case of a failure on the primary server, the software component is started with failover scripts on the secondary node. The Data is regularly mirrored to a secondary system using replication or shared disk. This generally provides a recovery time of a few minutes.
For the detailed HA configuration, see the table:
| Component | HA mode |
|---|---|
| MS SQL (on the customer's side) | Active-Active (Always On) |
| Shared file system (on the customer's side) | Replication |
| Control Tower | Active-Warm Standby |
| Workspace | Active-Warm Standby |
| Kibana | Active-Active |
| botmanager | Active-Warm Standby |
| AutoQC | Active-Warm Standby |
| Tableau | Active-Warm Standby |
| RPA/Bot Agents | Active-Active |
| OCR | Active-Active |
| BEP Worker | Active-Active |
| Marathon | Active-Active |
| AutoML (Gateway and Model) | Active-Warm Standby |
| Mesos Master | Active-Active |
| BEP Master Service | Active-Warm Standby |
| RabbitMQ | Active-Active (Mirroring) |
| Nexus | Active-Warm Standby |
| Minio S3 | Active-Active |
| Secrets Vault | Active-Active |
| Zookeeper | Active-Active |
| Elastic Search | Active-Active |
| Hazelcast | Active-Active |
| BEP Task Dispatcher | Active-Warm Standby |
A load balancer (LB) is aimed at providing the availability of services, distributing traffic communication across servers, and is used to increase capacity and reliability of applications. The load balancer must be installed on the customer's side. It accepts all the traffic and forwards the application requests to HAProxy, which is installed on an APP server. After that, HAProxy routes the incoming traffic among Intelligent Automation Cloud servers.
note
HAProxy is always installed on the APP server, even if you are not planning to run Intelligent Automation Cloud Enterprise in the HA mode.
Installation outline
- Deploy the required amount of servers.
- Create users.
- Install and configure load balancer.
- Create a shared directory and mount it to the APP, INT, and BEP Master servers.
- Prepare the installation.
- Install Intelligent Automation Cloud Enterprise.