- Overview
- Requirements
- Pre-installation
- Installation
- Post-installation
- Migration and upgrade
- Upgrading Automation Suite
- Migrating standalone products to Automation Suite
- Step 1: Restoring the standalone product database
- Step 2: Updating the schema of the restored product database
- Step 3: Moving the Identity organization data from standalone to Automation Suite
- Step 4: Backing up the platform database in Automation Suite
- Step 5: Merging organizations in Automation Suite
- Step 6: Updating the migrated product connection strings
- Step 7: Migrating standalone Orchestrator
- Step 8: Migrating standalone Insights
- Step 9: Migrating standalone Test Manager
- Step 10: Deleting the default tenant
- Performing a single tenant migration
- Migrating between Automation Suite clusters
- Migrating from Automation Suite on EKS/AKS to Automation Suite on OpenShift
- Monitoring and alerting
- Cluster administration
- Product-specific configuration
- Orchestrator advanced configuration
- Configuring Orchestrator parameters
- Configuring appSettings
- Configuring the maximum request size
- Overriding cluster-level storage configuration
- Configuring NLog
- Saving robot logs to Elasticsearch
- Configuring credential stores
- Configuring encryption key per tenant
- Cleaning up the Orchestrator database
- Skipping host library creation
- Troubleshooting
- The backup setup does not work due to a failure to connect to Azure Government
- Pods in the uipath namespace stuck when enabling custom node taints
- Unable to launch Automation Hub and Apps with proxy setup
- Robot cannot connect to an Automation Suite Orchestrator instance
- Log streaming does not work in proxy setups
- Velero backup fails with FailedValidation error
- Accessing FQDN returns RBAC: access denied error
Automation Suite on EKS/AKS installation guide
Disaster recovery - Active/Passive
This article walks you through the core concepts and architecture of Automation Suite disaster recovery, covering Active/Passive deployments.
Active/Passive mode is currently available only for EKS.
Ensuring continuous business automation is at the core of any automation platform. Automation Suite can withstand the complete failure of nodes, entire data centers, or regions. You can deploy Automation Suite as an Active/Passive configuration.
Automation Suite multi-site deployments in Active/Passive mode support the following scenarios:
- Same-region deployment - Two Automation Suite clusters deployed in the same region;
- Cross-region deployment - Two Automation Suite clusters deployed in different regions.
The following table provides details on which Automation Suite products you can deploy in Active/Passive mode.
| Product | Support for Active/Passive |
|---|---|
| Orchestrator | ✅ |
| Action Center | ✅ |
| AI Center | ✅ |
| Apps | ✅ |
| Automation Ops | ✅ |
| Automation Suite Robots | ✅ |
| Computer Vision | ✅ |
| Data Service | ✅ |
| Document Understanding | ✅ |
| Test Manager | ✅ |
| Automation Hub | ❌ |
| Insights | ❌ |
| Process Mining | ❌ |
| Task Mining | ❌ |
| Integration Service | ❌ |
| Studio Web | ❌ |
- You can install products that are not supported in Disaster Recovery with Active/Passive . However, you cannot use these products when the primary cluster is down.
- For AI Center, the training pipeline functionality is available only in the primary cluster.
Requirements
To configure an Active/Passive deployment, make sure you meet the following requirements:
- Hardware
- Database
- Amazon Elastic Cache (Redis)
- S3 (Object Store)
- SQS (Queues)
- Route 53
Hardware
The secondary (Passive) hardware cluster must be identical to the Primary hardware cluster.
Database
The database must be accessible from both the Active and Passive clusters.
Amazon Elastic Cache (Redis)
The system must operate separately for both the Active cluster and the Passive cluster.
S3 (Object Store)
The S3 system must be synchronized and it must support Cross-Region Replication (CRR).
SQS (Queues)
SQS must operate separately on Active and Passive setups.
Route 53
Route53 must be used to control the routing of traffic. Configuration in Route53 is required to direct traffic to the active load balancer when functional.
In case of a disaster, the traffic must be re-routed to the passive load balancer using route 53.