Architecture multi-nœuds et considération de conception

Le schéma d'architecture suivant décrit un déploiement d'Automation Suite sur Linux avec Kubernetes installé sur six machines, un équilibreur de charge et le stockage de données. Il existe plusieurs types de machines : trois nœuds de serveur, deux nœuds d'agent et un nœud d'agent spécialisé.

Nœuds de serveur

Les nœuds de serveur hébergent le plan de contrôle Kubernetes, qui contrôle cluster Kubernetes complet. Dans un déploiement multi-nœuds standard, un nombre impair de nœuds de serveur est nécessaire, le nombre minimum de serveurs étant de trois. Cette restriction est due au composant etcd, qui fait partie du plan de contrôle Kubernetes. Pour plus de détails, consultez la documentation etcd. Pour la même raison, la majorité des nœuds de serveur doivent être disponibles à tout moment pour maintenir le cluster en bonne santé.

Ces nœuds hébergent également les composants qui nécessitent un stockage de données sur les nœuds, tels que Prometheus, le magasin d'objets intégré au cluster Ceph, UiPath Insights et le registre Docker intégré au cluster.

Nœuds d'agent

Les nœuds d’agent sont parfois appelés nœuds de travail. Ces nœuds ont pour objectif d’héberger les services UiPath® ainsi que d’autres fonctionnalités partagées de la suite. Comme aucun disque de données n’est rattaché à ces nœuds, ils ne peuvent pas héberger les composants nécessitant un stockage sur disque.

Les nœuds d'agent n'imposent aucune restriction sur le nombre de nœuds disponibles à un moment donné. Tant que le cluster résultant a une capacité suffisante pour héberger tous les pods des nœuds perdus, le cluster fonctionnera comme prévu sans aucune interruption.

Nœuds d'agents spécialisés

Ces nœuds sont les nœuds d’agent spéciaux dédiés à des tâches spécifiques, tel que le nœud Task Mining pour les analyses, le nœud Automation Suite Robots pour l’exécution des Robots et le nœud GPU pour le modèle Document Understanding. Vous ne pouvez pas héberger d’autres services UiPath® sur ces nœuds.

Load balancer

L'équilibreur de charge, qui est installé en dehors d'Automation Suite, sert de point d'entrée pour accéder aux applications hébergées sur le cluster Automation Suite. L'équilibreur de charge doit être soumis à la tolérance aux pannes des nœuds. Tous les nœuds de serveur doivent être configurés sur l'équilibreur de charge, mais les nœuds d'agent peuvent également être configurés de manière facultative. Cependant, des nœuds d'agent spécialisés ne sont pas nécessaires.

Lorsque les robots tentent d'accéder à Orchestrator, l'appel arrive sur l'équilibreur de charge, puis est transmis à l'un des nœuds disponibles. Chaque nœud héberge également le composant de mise en réseau appelé Istio, qui est un service Mesh qui agit également comme un équilibreur de charge. Lorsque l'appel est reçu par Istio exécuté sur le nœud, il tente de localiser l'instance Orchestrator sur l'ensemble du cluster. Une fois qu'il est trouvé, il redirige l'appel vers cette instance.

Comment concevoir votre déploiement

Plus de machines plus petites ou moins de machines plus grandes ?

Cela dépend entièrement de vous, les deux options ayant leurs propres avantages et inconvénients. Un nombre plus élevé de machines plus petites offre une meilleure résilience à la tolérance aux pannes de nœud par rapport à un plus petit nombre de machines plus volumineuses. Dans le même temps, elle introduit également des frais généraux de gestion supplémentaires.

Par exemple, si votre cluster Automation Suite nécessite un processeur virtuel 96, vous pouvez opter pour l'une des options suivantes :

• Option 1 : 6 machines de 16 VCPU chacune.
  • Impact : la perte d'une machine ne réduit la capacité du cluster que de 16 processeurs virtuels, et n'a donc un impact sur les services que si le cluster résultant n'a pas la capacité d'héberger tous les pods. Cependant, la gestion de 6 machines implique un effort plus important.
• Option 2 : 3 machines de 32 VCPU chacune
  • Impact : la perte d'une machine réduit la capacité du cluster de 32 vCPU, ce qui a un impact majeur sur Automation Suite. Cependant, la gestion de 3 machines implique un effort moindre.

Pour conclure, la conception du déploiement dépend de l'objectif. Si l'objectif est une meilleure tolérance aux pannes, mieux vaut opter pour des machines plus petites. Cependant, si l'objectif est de réduire les frais généraux de gestion, un plus petit nombre de machines plus volumineuses serait préférable.

Tous les nœuds de serveur au lieu des nœuds d'agent ?

Le fait d'opter pour tous les nœuds de serveur au lieu des nœuds d'agent dépend de votre RTO ou RPO.

Par exemple, supposons que votre installation Automation Suite ait besoin de 80 processeurs virtuels. Vous pouvez parvenir à cette configuration comme suit :

• Option 1 : 5 machines serveur avec 16 vCPU chacune. Dans cette configuration, vous pouvez perdre au maximum 2 nœuds de serveur.
  • Recommandé si vous visez la résilience à la perte de données. Même si 2 nœuds de serveur sont perdus, les données seront intactes et pourront être recréées à partir des répliques restantes.
• Option 2 : 3 nœuds de serveur et les 2 nœuds d'agent avec 16 VCPU chacun. Ici, vous pouvez perdre 1 nœud de serveur et les deux nœuds d'agent, soit un total de 3 machines.
  • Recommandé si vous visez la résilience à la disponibilité des nœuds. Même sans 3 machines, le cluster sera toujours disponible avec une capacité limitée, et une fois les nœuds rétablis, l'intégralité du cluster sera récupérée. Cependant, cette configuration est davantage sujette à la perte de données en raison du stockage lié aux nœuds du serveur. Si 2 nœuds de serveur sont entièrement perdus, il peut être difficile de reconstruire les données sans les restaurer à partir de la sauvegarde.