HA and DR deployment models

Automation 360 provides several deployment options to meet various levels of enterprise cost/price performance and resiliency requirements. The options include installation on single nodes and on multiple nodes. Multi-node deployments can be configured for highly available (HA) clusters and disaster recovery (DR) sites.

The deployment services are set up using the Automation 360 installer. A typical Automation 360 server node runs the following services:

  • Automation Anywhere Automation Services
  • Automation Anywhere Messaging Services
  • Automation Anywhere Caching Services
  • Automation Anywhere Search Services
  • Repository storage
  • (Optional) IQ Bot VM

The Automation 360 installer also supports the multi-node deployment configuration.

Planning

Identify your requirements before selecting a deployment model. For best results, deploy the same operating systems across the Automation Workspace development, testing, and production environments. At minimum, have the same OS on both test and production environments.

Deployment models

At a high level, there are two ways to deploy or install Automation 360 - single-node and multi-node. Choose the option that meets your business continuity requirements.

Single-node deployment

As the name suggests, there is a single physical server node, on which all the services related to Automation 360 are run. By design, this configuration does not provide any redundancy and hence the availability depends on the services on this single node.

Database
In single-node deployment, the database can be anywhere if the Control Room server is able to connect to the database server. This can involve network configurations.
Note: You cannot host the database server on the same server as the Control Room server as it requires higher processing/memory configuration on the server.
Characteristics
  • No disaster recovery (single point of failure): If the single node fails, RPA operation will be adversely affected.
  • No high availability: If the server is taken offline for upgrade or maintenance, RPA operations will be affected.
  • No RPA up-scaling: When RPA deployments scale up and users increase, the single node will have to manage the increased load. This might adversely affect the RPA performance.
Usage Recommendations
Single-node deployments are typically recommended for small-scale usage in proof of concepts, demos, testing, and trials, to name a few.

Single-node deployments are NOT RECOMMEDED for production usage because any downtime will impair RPA operation and business continuity.

Advantages
  • Quick and easy installation and setup
  • Additional servers not required
  • Load balancers and clustering configuration not required

The following image shows the Automation Anywhere and data center components for a single node. The Automation Anywhere components are shown in orange and components provided by your organization are shown in blue. Components that are centrally hosted on cloud and managed by Automation Anywhere such as license server are shown in light orange.

Single node deployment model

Multi-node deployment

To achieve higher processing scale, higher availability in production setups, Automation 360 services are deployed across multiple server nodes. Installer enables you to setup multi-mode configuration. This involves additional configuration steps such as linking services to same database and so on.

Distributed approach
The Control Room provides the flexibility to process large number of requests in given time window.

Deploy multiple instances of Control Room on multiple physical or virtual servers as required. This also means configuring the cluster setup for the caching, search, and messaging services.

Load balancing
Performed by a load balancer, this is the process of distributing application or network traffic across multiple servers to protect service activities, allowing workloads to be distributed among multiple servers. This ensures automation activity is continued on clustered servers.

Load balancer requirements

Databases
In multi-node deployments, databases use their own built-in failover to protect the data. This ensures database data recovery.

If you use cloud-based database services likes of AWS-RDS, the High Availability and Disaster Recovery as part of their service offerings, in which case no further database configurations are necessary.

For pure on-premises database scenarios, configure synchronous replication between the primary (active) and secondary (passive) clustered Microsoft SQL Server in the data center. This ensures consistency in the event of a database node failure.

For synchronous replication, configure the database using publisher and subscriber model in Microsoft SQL Server from the primary disaster recovery site to the secondary disaster recovery site that is at a geographically separated location from the primary site.

Replicate data between primary and secondary sites

The following image shows the Automation Anywhere and data center components for three nodes in a data center cluster. The Automation Anywhere components are shown in orange and components provided by your organization are shown in blue. Components that are centrally hosted on cloud and managed by Automation Anywhere such as license server are shown in light orange.

High availability (HA) deployment model
Important: Stretch clusters are not supported.
  • Ensure that all the HA cluster nodes are configured in the same location. Do not configure the nodes in a single HA cluster that is located across various sites. Ensure that you configure one HA cluster at the primary site and the other HA cluster at the secondary site.
  • The Control Room and IQ Bot must be configured in the same data center to ensure communication between both the applications.