Vue d'ensemble (Overview)

Diagrammes

Le diagramme suivant représente un déploiement actif/passif standard d’Automation Suite :

Prérequis

Matériel	Prérequis
Gestionnaire global de trafic (GTM)	Distribue le trafic vers votre déploiement multi-sites Automation Suite. Le service doit être hautement disponible et insensible à tout site de déploiement. De plus, le GTM doit être en mesure de configurer la vérification de l'état pour isoler rapidement le site défectueux. Le GTM n'est pas obligatoire, mais il est recommandé pour un basculement rapide. Lors de la configuration du Gestionnaire de trafic global (Global Traffic Manager - GTM) pour les déploiements actif/passif, veillez à bien utiliser /orchestrator_/api/status comme point de terminaison de santé. Ceci est crucial pour une gestion efficace de Disaster Recovery.
Load balancer	Chaque site a besoin d'un équilibreur de charge local capable d'équilibrer la charge du trafic vers n'importe quel nœud configuré sur le même site.
Nœud	Les deux sites doivent avoir un nombre identique de nœuds et pour chaque site, vous devez configurer le cluster et les nœuds à l'aide de la documentation fournie à la page Cluster et nœuds Kubernetes (Kubernetes cluster and nodes) . Pour plus de détails, consultez le calculateur de dimensionnement d’installation UiPath Automation Suite.
Base de données SQL	Un serveur SQL externe est nécessaire pour stocker les données. Pour la récupération d'urgence, vous avez besoin de Groupes de disponibilité Always On (Always On Availability Groups) (ou MSSQL d'Amazon RDS avec ReadReplica) avec un serveur SQL principal sur le site 1 et au moins un serveur SQL secondaire (ReadReplica) situé physiquement sur le site 2 avec la synchronisation des données activée. Un processus d'écoute SQL est également déployé par-dessus le serveur SQL. Les deux clusters sont configurés pour utiliser l’adresse du même processus d’écoute. Les sites/clusters actifs (principal) et passifs (secondaires) doivent utiliser le point de terminaison principal de la base de données pour la communication de base de données. En cas de sinistre, une fois que la réplique en lecture est promue au statut principal, son point de terminaison doit être mis à jour dans les sites actif et passif pour servir de nouvelle chaîne de connexion à la base de données. Pour simplifier la gestion des basculements, Amazon Route 53 peut être utilisé pour créer un enregistrement DNS pour la base de données. Initialement, il doit désigner le point de terminaison de base de données principal (ou l'écouteur). En cas de basculement, l'enregistrement Route 53 peut être mis à jour pour pointer vers la base de données principale nouvellement promue (anciennement la réplique en lecture).
Magasin d'objets	Tous les fichiers ou packages téléchargés vers les produits sont stockés dans le magasin d’objets. Pour une plus grande résilience face aux défaillances, les déploiements d’Automation Suite nécessitent un magasin d’objets externe. Pour améliorer l’efficacité de la récupération d’urgence, deux instances de magasin d’objets sont requises, avec une instance située dans chaque centre de données. Il faut constamment qu’une seule instance de magasin d’objets soit utilisée de manière active pour les activités de lecture et d’écriture des deux clusters. Ce processus doit être complété par une réplication asynchrone vers l’instance secondaire.

Équilibreur de charge et configuration DNS

Cette section décrit la configuration de l'infrastructure, l'architecture DNS et la logique de routage d'un système conçu pour fonctionner dans des scénarios normaux et de Disaster Recovery.

Présentation de l’infrastructure

Pour prendre en charge la haute disponibilité et la récupération d'urgence, le système nécessite une configuration à double équilibreur de charge :

• Équilibreur de charge principal (Main Load Balancer) : affecté au cluster actif (principal) pour gérer le trafic d'application standard.
• Équilibreur de charge secondaire: affecté au cluster passif (secondaire), prêt à prendre le contrôle en cas d'échec dans le principal.

Chaque équilibreur de charge se voit attribuer une adresse IP d’Elastic (EIP) unique, qui sert de point de terminaison pour la résolution DNS.

Architecture DNS

Pour faciliter la gestion du trafic et l'accessibilité des services spécifiques au cluster, deux niveaux de configuration DNS sont utilisés.

• Nom de domaine complet: le nom de domaine complet de l'application est le domaine principal utilisé par les utilisateurs finaux pour accéder à l'interface de l'application. Cette valeur correspond au champ fqdn dans input.json. Pour plus de détails, consultez la section Configurations actif/passif.
• Noms de domaine complets spécifiques au cluster: en plus du nom de domaine complet de l'application principale, chaque cluster requiert son propre nom de domaine complet pour les outils d'administration et de surveillance. Cette valeur est définie sous le champ cluster_fqdn dans le input.json de chaque cluster. Pour plus de détails, consultez la section Configurations actif/passif.
• Sous-domaines: pour un accès complet au service, un ensemble de sous-domaines est configuré pour le nom de domaine complet de l'application et chaque nom de domaine complet spécifique au cluster. Celles-ci comprennent :
  • Nom de domaine complet :
    • apps.<domain> : utilisé par les applications.
    • insights.<domain> – utilisé par pour Insights.
  • Nom de domaine complet spécifique au cluster :
    • alm.<domain> – utilisé par ArgoCD et pour la gestion des déploiements. Ceci est requis pour les clusters actif (principal) et passif (secondaire).
    • monitoring.<domain> : utilisé pour l’obserabilité et les alertes. Ceci est requis pour les clusters actif (principal) et passif (secondaire).

  Tous les sous-domaines sont dirigés vers la même adresse IP Elastic (EIP) que leur domaine racine respectif, afin de maintenir la cohérence et de faciliter le routage.

Logique de routage DNS

La logique de routage DNS garantit que le trafic des utilisateurs est dirigé vers l'équilibreur de charge approprié en fonction de l'état du système, soit en cours de fonctionnement normal, soit en cas de reprise après sinistre.

• Opérations normales (le cluster principal est actif)

  En mode de fonctionnement standard, DNS achemine le trafic comme décrit dans le tableau suivant :

  Type de nom de domaine complet	Cible de routage
  Nom de domaine complet	Équilibreur de charge du cluster principal
  Nom de domaine complet du cluster principal	Équilibreur de charge du cluster principal
  Nom de domaine complet du cluster secondaire	Équilibreur de charge de cluster secondaire

• Disaster Recovery (le cluster secondaire est actif)

  Si le cluster principal échoue, le système passe en mode de récupération d'urgence. Dans cet état, le DNS est ajusté pour assurer la continuité du service :

  Type de nom de domaine complet	Cible de routage
  Nom de domaine complet	Équilibreur de charge de cluster secondaire
  Nom de domaine complet du cluster principal	Équilibreur de charge du cluster principal(non modifié)
  Nom de domaine complet du cluster secondaire	Équilibreur de charge de cluster secondaire(non modifié)