Performing a side-by-side upgrade

Perform a side-by-side upgrade for Automation Suite using a parallel environment to safely switch traffic to a new cluster.

The Automation Suite side-by-side upgrade allows you to perform upgrade operations safely using a parallel environment instead of upgrading in place.

This method allows administrators to switch traffic from the old Automation Suite cluster (for example, the blue deployment) to the new Automation Suite cluster (for example, the green deployment) after verifying the new deployment. If you detect a problem, you can roll back to the old deployment quickly.

When performing a side-by side upgrade, the two parallel clusters share one single license.

Requirements

• If AI Center is enabled, make sure you meet the CUDA requirements.
• Hardware requirements, depending on the model that you chose:
  • Side-by-side upgrade (identically sized target cluster) - Both the source and the target environments must meet the same hardware and software requirements.
  • Side-by-side upgrade (single node start) - You can setup a single node target cluster and then scale it up. Ensure that you meet the hardware requirements suggested by the Automation Suite Install Sizing Calculator based on your product selection and usage details.
• Software requirements: Both the source and the target environments must meet the same hardware and software requirements.

Data migration and responsibilities

The following table describes the data migration status and responsibilities for each component during the upgrade.

Data	Status	Responsibility
SQL	Retained	Customer
FQDN	Retained; optional You must choose a new FQDN for the new cluster. Optionally, you can revert to the previous FQDN if needed.	Customer
On-demand bundles	Not migrated Run a script to see which bundles are in the cluster. Manual seeding is needed.	Customer
Certificates	Not migrated You must bring certificates as part of the new cluster installation.	Customer
Cluster configuration	Not migrated You must generate cluster_config.json from the original source cluster to map the same services to the new cluster installation.	Customer
Custom alerts and dashboards created by users	Not migrated You must reconfigure the custom alerts and dashboards post-upgrade.	Customer
Application logs / Prometheus streaming configuration created by users	Not migrated You must reconfigure application log and Prometheus streaming.	Customer
Dynamic workloads	Depends on application AI Center training jobs are lost; Skills are retained.	Skills (script needed to be executed after upgrade): UiPath® / Training jobs: Customer
Objectstore	Retained	In-cluster objectstore (Ceph): UiPath® / External objectstore: Customer
Insights	Retained	UiPath®
MongoDB data	Retained MongoDB data is moved to the target SQL.	UiPath®
RabbitMQ	Not needed	UiPath®
Monitoring (data)	Not needed Monitoring data does not apply to the new cluster. If you do not use the built-in monitoring components, you must set up external monitoring components after the migration upgrade.	N/A
Docker registry	Not needed You must install an in-cluster docker registry or bring an external docker registry.	N/A

Process overview

To perform a side-by-side upgrade, complete the following steps:

1. Prepare the new cluster:

   • Prepare the cluster_config.json file.
   • Install your new cluster (infrastructure and in-cluster objectstore (if applicable) only).
   • Configure the additional CA certificates.

2. Migrate the data to the new cluster:

   • Hydrate the docker registry with the offline upgrade images.
   • Put the cluster in maintenance mode.
   • Clone your source cluster databases.
   • Run the data migration script on the source cluster.
   • If you configured an external objectstore, clone the objectstore buckets.

3. Complete the upgrade:

   • Edit the cluster_config.json file to point to the cloned databases and buckets.
   • Run the installer on the target cluster.
   • If you did not provide the certificates during installation, update them post-installation.
   • Validate if the target cluster works as expected.
   • If you opted for the side-by-side upgrade (identically sized target cluster), you can optionally update the FQDN of the target cluster to match the source cluster FQDN, or use a new FQDN. If you opted for the side-by-side upgrade (single node start), you can update the FQDN later.
   • Enable the backup on the target cluster.

4. Scale the target cluster - applicable only if you opted for the side-by-side upgrade (single node start):

   • Take the backup of the source cluster (recommended).
   • Add server and agent nodes similar to your source cluster.
   • Edit the cluster_config.json file.
   • Rerun the installer to scale the cluster into HA setup.
   • Optionally update the FQDN of the target cluster to match the source cluster FQDN, or use a new FQDN.

Side-by-side upgrade models

We offer two models for side-by-side upgrades:

1. Side-by-side upgrade (identically sized target cluster):
   • Requires the target cluster to have the same hardware resources as the source cluster.
   • Ready for traffic once:
     • Data migration is complete.
     • Sanity checks are successful.
2. Side-by-side upgrade (single node start):
   • Starts with a single-node setup, then scales up to an HA setup. This reduces the initial hardware requirements needed for side-by-side upgrade.
   • Hardware for single-node setup must meet the recommendations of the Capacity Calculator for the single node setup.
   • For scaling:
     • Nodes from the source cluster can be decommissioned and added to the target cluster.
   • Ready for traffic once:
     • Data migration is complete.
     • Cluster is scaled to multi-node.
     • Sanity checks are successful.

You can find a comparison between the two models in the following table:

	Side-by-side upgrade (identically sized target cluster)	Side-by-side upgrade (single node start)
Hardware requirements	Requires identical hardware for both source and target clusters.	Starts with minimal hardware, scaling up as needed.
Downtime	Minimal downtime due to fully redundant target environment.	Higher downtime due to node scaling operations.
Impact on source cluster	No impact.	Source nodes can be decommissioned and joined to the target cluster.
Rollback process	Simple rollback as the source remains untouched.	If scaling operation fails in the target cluster, rollback involves reintegrating nodes into the source cluster.
Cost impact	Higher costs due to duplicate infrastructure.	Lower costs with reduced initial hardware requirements.