Migration entre les clusters Automation Suite

Migrez les données et les configurations entre les clusters Automation Suite sur EKS/AKS.

À propos de la migration du cluster

Vous pouvez migrer d'un cluster Automation Suite à un autre si vous utilisez l'espace de noms uipath au lieu d'un espace de noms personnalisé et que vous souhaitez passer d'une version d'Automation Suite à une autre. Nous prenons en charge les scénarios suivants :

• faire migrer depuis Automation Suite sur Linux vers une nouvelle installation d'Automation Suite sur EKS/AKS ;
• Effectuez la migration depuis Automation Suite sur Linux vers une nouvelle installation d'Automation Suite sur OpenShift.

Tout scénario de migration non répertorié ci-dessus n'est pas pris en charge.

Notez que vous pouvez tenter d'effectuer l'opération de migration plusieurs fois sans avoir d'impact sur votre cluster existant.

Les scénarios de migration suivants ne sont pas pris en charge :

• Migration d'Automation Suite vers Linux vers une installation existante d'Automation Suite sous EKS/AKS ou Automation Suite sous OpenShift;
• Migration d'un cluster Automation Suite sur OpenShift vers un cluster Automation Suite sur Linux;
• Migration d'Automation Suite sur EKS/AKS vers une nouvelle installation d'Automation Suite sur OpenShift;
• Migration d'Automation Suite sur OpenShift vers une nouvelle installation d'Automation Suite sur EKS/AKS;
• Migration d'Automation Suite sur EKS vers Automation Suite sur AKS ou d'Automation Suite sur AKS vers Automation Suite sur EKS;
• Migration d'Automation Suite sur EKS vers une nouvelle installation d'Automation Suite sur EKS;
• Migration d'Automation Suite sur AKS vers une nouvelle installation d'Automation Suite sur AKS;
• Migration d'Automation Suite sur OpenShift vers une nouvelle installation d'Automation Suite sur OpenShift.

Vue d'ensemble du processus

Le tableau suivant donne un aperçu du processus de migration du cluster.

Étape	Description
1.	Obligatoire . Assurez-vous de répondre aux exigences de migration. Prérequis Migration de données et responsabilités
2.	Obligatoire. Préparez le cluster cible et les images Docker pour le cluster source et le cluster cible. Préparation du cluster cible Facultatif. Si votre déploiement est hors ligne ou si vous utilisez un registre OCI privé, assurez-vous que les images requises sont disponibles. Hydratation du registre compatible OCI dans une configuration hors ligne Hydratation du registre compatible OCI dans une configuration en ligne
3.	Obligatoire. Démarrez la migration, déplacez les données et exécutez l'installation d'Automation Suite. Exécution de la migration du cluster
4.	Facultatif . Si AI Center est activé à la fois sur les clusters source et cible, migrez les compétences. Migration des compétences d'AI Center

Pour obtenir des instructions de migration détaillées, consultez le Guide d'installation d'Automation Suite sur EKS/AKS.

Prérequis

Pour migrer d'un cluster Automation Suite à un autre, vous devez répondre aux exigences suivantes :

• Téléchargez les artefacts suivants :
  • uipathctl
  • versions.json
• Vous devez établir la connectivité entre les deux environnements.
• Un magasin d'objets externe doit être configuré dans votre cluster source. Si vous utilisez le stockage intégré au cluster, reportez-vous à la section Migration du magasin d'objets du cluster vers un magasin d'objets externe.
• Vous devez accorder les autorisations de lecture/écriture du cluster source au magasin d'objets de destination. Lorsque les volumes persistants (PV) sont copiés, le cluster source écrit ses données dans le magasin d'objets de destination, puis le cluster de destination extrait les données du magasin d'objets et crée les PV correspondants.
• Si vous migrez depuis Automation Suite sur Linux, la version de votre cluster source doit être 2022.10 ou une version plus récente.
• Si vous migrez vers Automation Suite sur OpenShift, la version de votre cluster source doit être 2023.10 ou une version plus récente.
• Exigences pour le mode hors ligne uniquement : vous devez hydrater le cluster cible.

Migration de données et responsabilités

Le tableau suivant décrit les mécanismes de migration des données ainsi que les responsabilités pour chaque composant.

Données	Mécanisme de migration
	État (Status)	Responsabilité
SQL	Retained (Conservé) Vous avez deux options : Réutilisez les mêmes bases de données pour la nouvelle installation. Pointez les chaînes de connexion SQL de la configuration du cluster sur le serveur de base de données existant. Clonez vos bases de données et utilisez plutôt les clones.	Client
Registre Docker	Non migré Si vous utilisez un registre privé, vous devez hydrater le registre cible. Si vous utilisez registry.uipath.com pour le cluster cible, aucune autre étape n'est nécessaire.)	Client
Nom de domaine complet	Requis Vous devez choisir un nouveau nom de domaine complet pour le nouveau cluster. Vous pouvez éventuellement revenir au nom de domaine complet précédent si nécessaire.	Client
Certificats	Non migré Vous devez apporter des certificats dans le cadre de la nouvelle installation de cluster.	Client
Configuration du cluster	Non migré Vous devez générer le nouveau input.json applicable au type de cluster cible (AKS ou EKS).	Client
Alertes et tableaux de bord personnalisés créés par les utilisateurs	Non migré Après la migration, vous devez reconfigurer toutes les alertes personnalisées dans le gestionnaire d'alertes et les tableaux de bord Grafana.	Client
Journaux d'application/configuration du flux Prometheus créés par les utilisateurs	Non migré Vous devez reconfigurer le journal des applications et le flux Prometheus.	Client
Charges de travail dynamiques	Dépend de l'application Les tâches d'entraînement AI Center sont perdues ; les compétences sont conservées.	Compétences (script nécessaire pour une exécution après la mise à niveau) : UiPath® Tâches d'entraînement : Client
Magasin d'objets	Magasin d'objets externe : Conservé (Retained) Pour le magasin d'objets externe, vous avez deux options : Réutiliser le magasin d'objets externe existant et le connecter au nouvel environnement. Créer une réplique de votre magasin d'objets actuel et l'utiliser pour la nouvelle configuration. Attention : si vous utilisez un magasin d'objets intégré au cluster, vous devez effectuer une migration ceph vers un système externe avant la mise à niveau.	Migration d'un magasin d'objets intégré au cluster vers un magasin externe : Client (Customer) Magasin d’objets externe : UiPath®
Insights	Retained (Conservé)	UiPath®
Données MongoDB	Retained (Conservé) Les données MongoDB sont déplacées vers le serveur SQL cible.	UiPath®
RabbitMQ	Non nécessaire	UiPath®
Surveillance (données)	Non nécessaire Les données de surveillance ne s'appliquent pas au nouveau cluster. Si vous n'utilisez pas les composants de surveillance intégrés, vous devez configurer des composants de surveillance externes après la mise à niveau de la migration.	S/O

Préparation de la migration du cluster

Préparation du cluster cible

Important :

N'exécutez pas uipathctl manifest apply tant que vous n'avez pas terminé l'Étape 1 dans la section Exécuter la migration du cluster . L'exécution de cette commande trop tôt peut entraîner des incohérences de configuration dans le cluster cible.

Remarque :

Ne modifiez pas le cluster source après le démarrage du processus de migration.

Pour préparer le cluster cible, procédez comme suit :

1. Téléchargez la version ciblée de input.json sur le cluster source et générez le fichier input.json en exécutant la commande suivante :

   uipathctl manifest get-revision
   

   Pour plus de détails, reportez-vous au schéma suivant :

   

2. Sur la base du fichier input.json généré précédemment, modifiez le fichier input.json du cluster cible.

   Vous devez transférer la configuration spécifique à Orchestrator qui inclut les paramètres.

   De plus, vous devez mettre à jour les composants suivants afin qu'ils référencent l'infrastructure correcte dans le cluster cible :

   • Magasin d'objets externe
   • Détails de la connexion SQL Server ou PostgreSQL
   • Configuration du cluster Redis
   Remarque :

   La base de données Microsoft SQL Server et PostgreSQL pour Process Mining Airflow est requise pour Process Mining sur Automation Suite 2.2510.

   Si vous migrez à partir d’une version antérieure à 2024.10.3, le fichier input.json généré pour le cluster cible ne contient pas la chaîne de connexion de la base de données Airflow PostgreSQL. Pour utiliser la dernière version de Airflow, qui nécessite PostgreSQL, vous devrez ajouter manuellement le modèle de chaîne de connexion sqlalchemy pour PostgreSQL au fichier input.json pour le cluster cible avant la migration.

   Postgresql_connection_string_template_sqlalchemy_pyodbc

   postgresql+psycopg2://<user>:<password>@<postgresql host>:<postgresql port>/DB_NAME_PLACEHOLDER
   

3. Validez les prérequis dans le cluster cible en exécutant la commande suivante :

   uipathctl prereq run input-target.json --kubeconfig kubeconfig.target --versions versions.json
   

   Remarque :

   input-target.json est le fichier input.json correspondant au cluster cible.

   Pour générer le fichier kubeconfig , reportez-vous à Génération du fichier kubeconfig.

4. Si vous migrez d’Automation Suite sur Linux vers un déploiement EKS/AKS, vous devez mettre le cluster source en mode de maintenance. Pour plus de détails, consultez la section Mettre le cluster en mode maintenance.

5. Clonez les bases de données SQL du déploiement source vers le déploiement cible.

Hydrater le registre compatible OCI sans accès Internet

Le processus de migration nécessite que la dernière balise d'image Docker uipathcore soit disponible à la fois pour les clusters source et cible. Si votre cluster source est hors ligne, rendez l'image disponible en procédant comme suit :

1. Suivez les étapes pour hydrater le registre utilisé par le cluster cible avec le bundle hors ligne décrites dans Option B : Hydratation du registre avec le bundle hors ligne.

2. Copiez le binaire uipathctl et le fichier versions.json sur une machine virtuelle avec accès au cluster source.

3. Exécutez la commande suivante :

   jq -r '.[][] | select(.name=="uipath/uipathcore") | .ref + ":" + .version' "/path/to/versions.json" > images.txt
   

4. Référencez l'image uipathcore du registre du cluster cible vers le registre du cluster source :

   ./uipathctl registry seed --tag-file ./images.txt \
               --source-registry "target.registry.fqdn.com" \
               --source-password "target-registry-username" \
               --source-username "target-registry-password" \
               --dest-registry "source.registry.fqdn.com" \
               --dest-username "source-registry-username" \
               --dest-password "source-registry-password"
   

Remarque :

Assurez-vous de mettre à jour la commande comme suit :

• Remplacez target.registry.fqdn.com, target.registry.fqdn.com et target-registry-password par les valeurs appropriées qui correspondent au registre associé au cluster cible ;
• Remplacez source.registry.fqdn.com, source.registry.fqdn.com et source-registry-password par les valeurs appropriées qui correspondent au registre associé au cluster source.

Hydratation du registre conforme à OCI avec accès à Internet

Si vous utilisez un registre privé, vous devez le référencer. Pour obtenir des instructions, consultez la section Configuration du registre compatible OCI.

Exécution de la migration du cluster

Pour migrer vers le cluster Automation Suite cible, procédez comme suit :

1. Effectuez la migration en exécutant la commande suivante :

   uipathctl cluster migration run input-target.json --kubeconfig kubeconfig.source --target-kubeconfig kubeconfig.target --versions versions-target.json
   

2. Terminez l'installation d'Automation Suite sur le cluster cible en exécutant la commande suivante :

   uipathctl manifest apply input-target.json --kubeconfig kubeconfig.target --versions versions-target.json
   

Migrer des compétences AI Center

Les étapes de cette section ne s'appliquent que si vous avez activé AI Center sur les clusters source et cible. Notez que les instructions supposent que AI Center au niveau du cluster cible pointe vers la base de données contenant les données de compétence pour exécuter les compétences.

Une fois la migration terminée, vous devez synchroniser les compétences AI Center afin de pouvoir les utiliser à nouveau.

Vérification du statut de la migration des compétences

Vous pouvez utiliser le script suivant pour synchroniser la compétence ML d'AI Center avec le cluster cible. Le script déclenche la synchronisation en arrière-plan si aucune synchronisation active n'est en cours.

Le script synchronise les compétences en arrière-plan (async) et les renvoie. La tâche garantit que les compétences sont déployées et met à jour l'entrée de la base de données pour refléter le statut actuel.

uipathctl service aicenter sync-skills [skill_ids]

• [skill_ids]: Facultatif. Tableau d'ID de compétence séparés par un espace. Si vous fournissez l'ID de compétence, seules ces compétences sont mises à jour ; sinon, toutes les compétences déployées sont resynchronisées.

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-3232

Pour afficher le statut de la compétence ML d'AI Center, exécutez la commande suivante :

uipathctl service aicenter sync-skill-status [skill_ids]

La commande peut renvoyer l'un des statuts suivants :

• InProgess : le déploiement de la compétence est en cours.
• Failed - le déploiement de la compétence a échoué.
• OutOfSync - la compétence est disponible dans la base de données ; cependant, elle n'a pas encore été déployée.
• Available : lorsque les compétences sont déployées et disponibles à l'utilisation.