Architecture de déploiement

Modes de déploiement, concepts d'architecture et options de topologie de nœud pris en charge pour Automation Suite.

Terminologie

Pour plus de détails sur les concepts de base utilisés dans un déploiement Automation Suite, consultez Glossaire.

Modes de déploiement et cas d'utilisation

Automation Suite prend en charge les modes de déploiement suivants :

Mode de déploiement	Description
Nœud unique	Prise en charge des scénarios d’évaluation et de démonstration. Pour plus de détails, consultez la section Déploiement en mode d'évaluation à nœud unique. Peut également être utilisé en production dans des conditions spécifiques. Pour plus de détails, consultez la section Déploiement en mode de production à nœud unique.
Multi-nœuds	Pris en charge pour une utilisation en production. Les modes suivants sont disponibles: - Mode léger: déploiement léger avec configuration haute disponibilité sélective. Pour des détails, reportez-vous à Déploiement en mode léger. - Mode haute disponibilité: entièrement activé. Pour plus de détails, consultez la section Déploiement en mode de production multi-nœuds compatible haute disponibilité.

Remarque :

Les déploiements à nœud unique peuvent être convertis en configurations haute disponibilité en ajoutant le matériel supplémentaire requis pour les déploiements multi-nœuds. Pour plus de détails, consultez la page Mise à l’échelle d’un déploiement à nœud unique (évaluation) vers un déploiement multi-nœuds .

Automation Suite utilise une architecture cloud native basée sur Kubernetes. Celle-ci offre tous les avantages d'évolutivité, de gestion automatique des ressources et de fiabilité qui accompagnent Kubernetes.

Pour proposer ces avantages, la conception de Kubernetes repose sur les aspects fondamentaux suivants :

• Exécution sur un nombre impair de machines multiples (3, 5, 7, etc.) ;
• Utilisation du principe de quorum pour gérer les problématiques de défaillance entre nœuds indépendants et de corruption des données. Pour un cluster de N machines, tant qu'il existe un résultat positif au calcul N/2 + 1 machines disposant de quorum, le cluster sera opérationnel et pourra se rétablir correctement sans échec.

Architecture de déploiement

Cette page offre un aperçu de l'architecture d'Automation Suite et décrit les composants intégrés au programme d'installation.

Types de nœuds

Le diagramme suivant montre les types de nœuds disponibles dans un déploiement Automation Suite.

Un nœud de serveur héberge des services de gestion de cluster (plan de contrôle) qui effectuent des opérations de cluster importantes telles que l’orchestration de la charge de travail, la gestion de l’état du cluster, les demandes entrantes d’équilibrage de charge, etc. Kubernetes peut également exécuter certains produits UiPath® ainsi que des composants partagés, en fonction de la disponibilité des ressources sous-jacentes.

Un nœud d’agent est uniquement responsable de l’exécution de produits UiPath® et de composants partagés.

Un nœud d’ agent spécialisé exécute des charges de travail spéciales telles que des pipelines Document Understanding qui nécessitent une capacité GPU, ou des Automation Suite Robots. Cependant, les services principaux de Document Understanding ou d'Automation Suite Robots s'exécuteront toujours sur des nœuds de serveur ou des nœuds d'agent. Les nœuds d’agents spécialisés n’hébergent aucun produit UiPath® et aucun composant partagé.

Important :

Automation Suite ne peut pas garantir quel produit UiPath® s’exécute sur chaque nœud. Ceci est uniquement géré par Kubernetes.

Déploiement en mode d'évaluation à nœud unique

Un déploiement en mode d'évaluation à nœud unique désigne ici un nœud à serveur unique. Cela n'implique pas le déploiement de l'intégralité d'Automation Suite sur une seule machine. Vous devrez peut-être ajouter des nœuds d'agent supplémentaires ou des nœuds d'agent spécialisés si l'ensemble de la suite de produits ne peut pas tenir dans un seul nœud de serveur, ou si vous souhaitez exécuter des tâches spéciales telles que les pipelines Document Understanding, qui nécessitent des capacités GPU.

Le diagramme suivant montre le déploiement en mode d'évaluation à nœud unique.

Déploiement en mode de production à nœud unique

Un déploiement à nœud unique est généralement utilisé dans le cadre de scénarios d'évaluation ou de démonstration. Dans des cas limités, il peut également être utilisé pour la production, mais uniquement si toutes les conditions suivantes sont remplies :

• Vous devez acheter un package d'assistance UiPath.
• Vous devez utiliser un magasin d'objets externe. Pour de plus amples informations, consultez la section Configurer un magasin d'objets externe.
• Vous devez activer la sauvegarde. Pour de plus amples informations, consultez la section Sauvegarder et restaurer le cluster.
• Vous devez configurer les solutions de surveillance prises en charge pour permettre un dépannage efficace. Pour de plus amples informations, consultez la section Monitoring Automation Suite.

Vous pouvez ensuite passer à un déploiement multi-nœuds en ajoutant de nouveaux nœuds de serveur au cluster et convertir le déploiement en déploiement multi-nœuds (HA). Pour plus d'informations, reportez-vous à la page Mise à l'échelle d'un déploiement à nœud unique (évaluation) vers un déploiement multi-nœuds (HA) .

Important :

Cette configuration n’offre pas une haute disponibilité et doit être prise en compte uniquement lorsqu’une configuration multi-nœuds n’est pas possible. Un déploiement multi-nœuds compatible haute disponibilité reste l'option recommandée à long terme.

Déploiement en mode Lite

Le mode léger est un déploiement léger qui exige moins de ressources d’infrastructure. Il offre davantage de flexibilité grâce à sa haute configurabilité pour les services nécessitant une haute disponibilité. Par défaut, l'infrastructure et les composants partagés sont déployés en mode haute disponibilité, et tous les services sont en mode léger (la mise à l'échelle automatique des pods horizontaux est activée avec au moins une réplique).

Vous pouvez faire basculer des services spécifiques en mode haute disponibilité. Vous avez également la possibilité d'effectuer une configuration supplémentaire après le déploiement pour bénéficier de toutes les fonctionnalités haute disponibilité.

Important :

Vous pouvez utiliser le mode Lite en production, mais vous devez être conscient des implications et des risques d'avoir des services sans haute disponibilité activée.

Déploiement en mode de production multi-nœuds compatible haute disponibilité

Un déploiement en mode de production multi-nœuds compatible haute implique 3 nœuds de serveur ou plus derrière un équilibreur de charge. Cela permet de s’assurer qu’en cas de sinistre, lorsque l’un des nœuds du serveur tombe en panne, Automation Suite sera toujours en mesure d’exécuter les workflows essentiels de l’entreprise. Il prend en charge à la fois la haute disponibilité au niveau du cluster et en externe. Le nombre de nœuds d’agent est facultatif et est basé sur l’utilisation réelle.

Le diagramme suivant montre le déploiement en mode de production multi-nœuds compatible haute disponibilité.

High Availability Add-on

Dans une configuration multi-nœuds, la haute disponibilité (HA) est activée par défaut. Cependant, le cache en mémoire basé sur Redis utilisé par les services de cluster s'exécute sur un seul pod et représente un point de défaillance unique. Pour atténuer l'impact d'une défaillance ou d'un redémarrage d'un nœud de cache, vous pouvez acheter le module complémentaire haute disponibilité (High Availability Add-on ou HAA), qui permet un déploiement redondant et multi-pods du cache.

Pour plus de détails sur l'activation de l' High Availability Add-on dans une configuration multi-nœuds, reportez-vous à Activation du module complémentaire de haute disponibilité pour le cluster .

Déploiement en ligne

Un déploiement en ligne implique qu'Automation Suite nécessitera un accès à Internet pendant l'installation et l'exécution. Tous les produits UiPath® et les bibliothèques associées sont hébergés soit dans le registre UiPath®, soit dans un magasin tiers approuvé par UiPath®.

Vous pouvez restreindre l'accès à Internet à l'aide d'un pare-feu restreint ou d'un serveur proxy en bloquant tout trafic Internet autre que celui requis par Automation Suite. Ce type de configuration est également appelé déploiement semi-en ligne. Pour plus de détails, consultez Configuration du pare-feu et Configuration du serveur proxy.

Ces types de déploiements sont plus faciles, plus rapides et nécessitent moins de ressources matérielles à installer et à gérer par rapport aux déploiements hors ligne.

Le diagramme suivant présente le modèle de déploiement en ligne.

Déploiement hors ligne

Un déploiement hors ligne (air-gapped) est une configuration complètement isolée, sans accès à Internet. Ce type de configuration nécessite l’installation d’un registre supplémentaire pour stocker toutes les images de conteneur et les fichiers binaires des produits UiPath®, livrés sous la forme d’une archive tar.

Le diagramme suivant montre le modèle de déploiement hors ligne physiquement isolé.

Remarque :

Le téléchargement de fichiers binaires (hydratation) dans le registre implique des exigences matérielles supplémentaires et une complexité d'installation, augmentant le temps nécessaire pour effectuer une installation par rapport à un déploiement en ligne.

Une installation hors ligne augmente non seulement la complexité de l'installation, mais également certains opérations de gestion du cluster telles que la maintenance de la machine, la récupération d'urgence, la mise à niveau vers des versions plus récentes, l'application de correctifs de sécurité, etc.

Vous n'êtes pas autorisé à modifier la méthode de déploiement après l'installation. Cela signifie que vous ne pouvez pas passer en mode hors ligne si l'installation est effectuée en ligne, et vice versa. Il est recommandé de choisir votre stratégie de déploiement après un examen approfondi.

Architecture d'Automation Suite

Le diagramme suivant illustre l'architecture d'Automation Suite. Notez que le registre Docker et le magasin d'objets compatible S3 peuvent également être hébergés en externe.

Le tableau suivant répertorie les composants tiers livrés avec Automation Suite :

Composant (Component)	Facultatif/obligatoire	Description
RKE2	Requis	Distribution Kubernetes fournie par Rancher. Il s'agit de la plate-forme d'orchestration de conteneurs qui exécute tous les composants et services architecturaux.
Magasin d'objets CEPH	Facultatif (si vous disposez d’un magasin d’objets externe)	Fournisseur de stockage open source qui expose le stockage d’objet/blob conforme à Amazon S3. Il permet aux services d’utiliser le stockage blob comme fonctionnalité pour leurs opérations.
Argo CD	Requis	Outil CD déclaratif open source pour Kubernetes. Il suit le modèle GitOps d’utilisation des référentiels Git comme source centralisée de données pour définir l’état d’application souhaité. Il comprend des fonctionnalités de gestion du cycle de vie des applications (ALM) pour les composants Automation Suite et les services UiPath® qui s’exécutent dans un cluster Kubernetes.
Registre Docker	Facultatif (si vous avez un registre externe)	Registre docker open source utilisé pour transférer et extraire des images de conteneurs de temps d'installation et d'exécution dans vos locaux.
Istio	Requis	Service mesh open source qui fournit des fonctionnalités telles que l'entrée, le routage des demandes, la surveillance du trafic, etc., pour les microservices exécutés à l'intérieur du cluster Kubernetes.
Prometheus	Facultatif (vous pouvez exclure les composants de surveillance intégrés)	Boîte à outils de surveillance système open source pour Kubernetes. Il peut extraire ou accepter les métriques des composants Kubernetes ainsi que les charges de travail exécutées dans les clusters et les stocker dans une base de données de séries chronologiques.
Grafana	Facultatif (vous pouvez exclure les composants de surveillance intégrés)	Outil de visualisation open source utilisé pour interroger et visualiser les données stockées dans Prometheus. Vous pouvez créer et fournir une variété de tableaux de bord pour la surveillance des clusters et des services.
Alertmanager	Facultatif (vous pouvez exclure les composants de surveillance intégrés)	Outil open source qui aide à gérer les alertes envoyées par les applications clientes telles que le serveur Prometheus. Il est chargé de les dédupliquer, de les regrouper et de les acheminer vers les intégrations de récepteur appropriées, telles que la messagerie électronique, PagerDuty ou OpsGenie.
Redis	Requis	Redis Enterprise non-HA (partition unique) utilisé par certains services UiPath® pour obtenir une fonctionnalité de cache centralisée.
FluentD et Fluentbit	Requis	Solution d'extraction de journaux fiable et open source. L'opérateur de journalisation déploie et configure un processus d'arrière-plan sur chaque nœud pour collecter les journaux de conteneur et d'application à partir du système de fichiers du nœud.
Gatekeeper	Requis	Outil open source qui permet à un administrateur Kubernetes de mettre en œuvre des politiques pour garantir la conformité et les meilleures pratiques dans son cluster.
velero	Requis1	Outil open source qui vous permet de sauvegarder et de restaurer un instantané.
Thanos	Requis	Outil open source pour transmettre la matrice Prometheus à un magasin d'objets à des fins de persistance.

¹ Installé uniquement lors de la sauvegarde et de la restauration.

Composants externes

Vous devez également apporter quelques composants externes, tels que des équilibreurs de charge externes et un serveur SQL. Notez que la Suite comprend quelques points d'extension.