- 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: 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
- Performing database maintenance
- Configuring the FQDN post-installation
- Forwarding logs to external tools
- Switching to the secondary cluster manually in an Active/Passive setup
- Converting an existing installation to multi-site setup
- Guidelines on upgrading an Active/Passive deployment
- Guidelines on backing up and restoring an Active/Passive deployment
- Product-specific configuration
- Troubleshooting
Automation Suite on EKS/AKS installation guide
Switching to the secondary cluster manually in an Active/Passive setup
This section provides high-level instructions on how to manually switch the traffic to the secondary cluster in an Active/Passive setup.
To switch to the secondary Automation Suite cluster, take the following steps:
- Turn on all the nodes of the Automation Suite cluster.
-
Bring back all products.
- Wait for all the components and products to be healthy.
- Sync the AI Center skills on the secondary cluster.
- Switch the traffic to the secondary cluster.
When switching to the secondary site, products such as Insights, Task Mining, Process Mining, Integration Service, Studio Web, and Automation Hub are not available.
You can scale up the cluster and bring back all inactive products using the following command:
# Set your namespace
NAMESPACE="uipath"
# Load original replica and suspend state
ORIGINAL_REPLICAS=$(kubectl -n "$NAMESPACE" get configmap "${NAMESPACE}-replica-backup" -o jsonpath="{.data.replicas\.json}")
# Restore Deployments
for deploy in $(kubectl -n "$NAMESPACE" get deploy --no-headers -o custom-columns=NAME:.metadata.name); do
count=$(echo "$ORIGINAL_REPLICAS" | jq --arg deploy "$deploy" --arg type "Deployment" '.[] | select(.name==$deploy and .type==$type) | .replicas')
if [[ -z "$count" || "$count" == "null" ]]; then count=1; fi
kubectl -n "$NAMESPACE" scale deploy "$deploy" --replicas="$count"
done
# Restore StatefulSets
for sts in $(kubectl -n "$NAMESPACE" get statefulset --no-headers -o custom-columns=NAME:.metadata.name); do
count=$(echo "$ORIGINAL_REPLICAS" | jq --arg sts "$sts" --arg type "StatefulSet" '.[] | select(.name==$sts and .type==$type) | .replicas')
if [[ -z "$count" || "$count" == "null" ]]; then count=1; fi
kubectl -n "$NAMESPACE" scale statefulset "$sts" --replicas="$count"
done
# Resume CronJobs only if they were not originally suspended
for cron in $(kubectl -n "$NAMESPACE" get cronjobs --no-headers -o custom-columns=NAME:.metadata.name); do
originally_suspended=$(echo "$ORIGINAL_REPLICAS" | jq --arg cron "$cron" --arg type "CronJob" -r '.[] | select(.name==$cron and .type==$type) | .suspend')
if [[ "$originally_suspended" == "false" ]]; then
kubectl -n "$NAMESPACE" patch cronjob "$cron" -p '{"spec":{"suspend":false}}'
fi
done
# Delete the backup ConfigMap
kubectl -n "$NAMESPACE" delete configmap "${NAMESPACE}-replica-backup" --ignore-not-found# Set your namespace
NAMESPACE="uipath"
# Load original replica and suspend state
ORIGINAL_REPLICAS=$(kubectl -n "$NAMESPACE" get configmap "${NAMESPACE}-replica-backup" -o jsonpath="{.data.replicas\.json}")
# Restore Deployments
for deploy in $(kubectl -n "$NAMESPACE" get deploy --no-headers -o custom-columns=NAME:.metadata.name); do
count=$(echo "$ORIGINAL_REPLICAS" | jq --arg deploy "$deploy" --arg type "Deployment" '.[] | select(.name==$deploy and .type==$type) | .replicas')
if [[ -z "$count" || "$count" == "null" ]]; then count=1; fi
kubectl -n "$NAMESPACE" scale deploy "$deploy" --replicas="$count"
done
# Restore StatefulSets
for sts in $(kubectl -n "$NAMESPACE" get statefulset --no-headers -o custom-columns=NAME:.metadata.name); do
count=$(echo "$ORIGINAL_REPLICAS" | jq --arg sts "$sts" --arg type "StatefulSet" '.[] | select(.name==$sts and .type==$type) | .replicas')
if [[ -z "$count" || "$count" == "null" ]]; then count=1; fi
kubectl -n "$NAMESPACE" scale statefulset "$sts" --replicas="$count"
done
# Resume CronJobs only if they were not originally suspended
for cron in $(kubectl -n "$NAMESPACE" get cronjobs --no-headers -o custom-columns=NAME:.metadata.name); do
originally_suspended=$(echo "$ORIGINAL_REPLICAS" | jq --arg cron "$cron" --arg type "CronJob" -r '.[] | select(.name==$cron and .type==$type) | .suspend')
if [[ "$originally_suspended" == "false" ]]; then
kubectl -n "$NAMESPACE" patch cronjob "$cron" -p '{"spec":{"suspend":false}}'
fi
done
# Delete the backup ConfigMap
kubectl -n "$NAMESPACE" delete configmap "${NAMESPACE}-replica-backup" --ignore-not-foundTo scale down the cluster and switch off inactive products, refer to Switching off inactive products.
You can use the following script to re-sync the AI Center ML Skilll in the secondary cluster. The script triggers the re-sync in the background if no active sync is in progress. You can use the same script to switch back to the primary cluster.
The script syncs the skills in the background (async) and returns. The job ensures that the skills are deployed and updates the DB entry to reflect the current status.
uipathctl service aicenter sync-skills [skill_ids]uipathctl service aicenter sync-skills [skill_ids]|
Parameter |
Description |
|---|---|
|
|
The optional array of the skill IDs separated by space. If you provide the skill ID, then only those skills are updated; otherwise, all deployed skills are re-synced. |
Example:
uipathctl service aicenter sync-skills 783273-3232-3232-323 32-32-323-3232
//this will only sync the skills with ID 783273-3232-3232-323 and 32-32-323-3232uipathctl service aicenter sync-skills 783273-3232-3232-323 32-32-323-3232
//this will only sync the skills with ID 783273-3232-3232-323 and 32-32-323-3232To monitor the skill status, you must run a different script, as shown in the following section.
To view the status of the AI Center ML Skill, run the following command:
uipathctl service aicenter sync-skill-status [skill_ids]uipathctl service aicenter sync-skill-status [skill_ids]-
InProgess- skill deployment is in progress. -
Failed- skill deployment is failed. -
OutOfSync- skill is available in the database; however, it has yet to be deployed. -
Available- when the skills are deployed and available to consume.
