Vue d'ensemble (Overview)

Architecture et topologie pour les déploiements actif/passif et actif/actif d'Automation Suite.

Diagrammes

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

Prérequis

Les composants matériels et d'infrastructure suivants sont requis pour un déploiement multi-sites.

Gestionnaire global de trafic (GTM)

Le GTM distribue le trafic sur l'ensemble de votre déploiement multi-sites Automation Suite. Il doit être hautement disponible et à l'abri des défaillances sur un site de déploiement unique. Le GTM doit également prendre en charge les vérifications de l'état qui isolent rapidement un site défectueux. Le GTM n'est pas obligatoire, mais il est recommandé pour un basculement rapide.

Lors de la configuration du GTM pour les déploiements actif/passif, utilisez /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. Pour chaque site, vous devez configurer le cluster et les nœuds à l'aide de la documentation dans Cluster et nœuds Kubernetes. Pour de plus amples informations, consultez la section Calculateur de dimensionnement d’installation d’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é toujours activés (ou MSSQL d’Amazon RDS avec ReadReplica) avec un serveur SQL principal sur le site 1 et au moins un serveur SQL secondaire situé physiquement sur le site 2, avec la synchronisation des données activée. Un processus d'écoute SQL est déployé sur le serveur SQL, et les deux clusters sont configurés pour utiliser l'adresse du même processus d'écoute.

Base de données PostgreSQL

Process Mining, Autopilot pour Developers et Temporal en tant que service nécessitent un serveur PostgreSQL externe. Pour la récupération d’urgence, seules les bases de données Autopilot pour Developers doivent être répliquées sur le site secondaire. La base de données Process Mining/Airflow ne nécessite pas de réplication entre les sites, mais une instance PostgreSQL est toujours requise sur chaque site. TaaS n'est pas pris en charge dans le cluster secondaire; il est pris en charge uniquement dans le site principal dans un déploiement actif/passif.

Configurez un serveur PostgreSQL principal sur le site 1 avec une réplication de flux physique vers au moins une réplique en lecture seule sur le site 2, ou utilisez la fonctionnalité de réplication du fournisseur géré, telle que les répliques de lecture Amazon RDS, la base de données Automation PostgreSQL ou la base de données Azure pour PostgreSQL Flex Réplications géographique du serveur.

PostgreSQL ne prend en charge qu'une seule entité inscriptible à la fois, de sorte que les clusters actif et passif doivent utiliser le point de terminaison principal actuel de la base de données. Lors de la reprise après sinistre, une fois la réplique du site 2 hôte, mettez à jour le point de terminaison de la base de données dans les deux sites pour pointer vers l'hôte nouvellement promu. Pour simplifier le basculement, utilisez un enregistrement DNS pour le point de terminaison de la base de données et mettez-le à jour lors du basculement.

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, soit une 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, complétées par une réplication asynchrone vers l’instance secondaire.

Temporel en tant que service (TaaS)

Si Maestro est activé, un seul cluster à la fois peut exécuter activement TaaS. Sur le cluster passif, mettez à l'échelle tous les déploiements TaaS à zéro réplique. Si les deux clusters se connectent simultanément au même magasin de persistance PostgreSQL, le conflit de verrouillage se produit et diminue les performances. Pour plus de détails, consultez la section Résolution des problèmes de Temporal en tant que service.

Équilibreur de charge et configuration DNS

Cette section décrit 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.

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 principal domaine utilisé par les utilisateurs finaux pour accéder à l'interface de l'application. Cette valeur correspond au champ fqdn dans input.json. Pour des détails, reportez-vous à Configurations actif/passif.
• Noms de domaine complets spécifiques au cluster: en plus du nom de domaine complet de l'application principale, chaque cluster nécessite 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 fichier input.json de chaque cluster. Pour des détails, reportez-vous à Configurations actif/passif.
• Sous-domaines: pour un accès complet au service, un ensemble de sous-domaines est configuré à la fois 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 Apps.
    • insights.<domain> : utilisé par pour Insights.
  • Nom de domaine complet spécifique au cluster :
    • alm.<domain> : utilisé par ArgoCD et pour la gestion du déploiement. Cela est requis pour les clusters actif (principal) et passés (secondes).
    • monitoring.<domain> : utilisé pour l’observabilité et les alertes. Cela est requis à la fois pour les clusters actifs (principals) et passifs (secondes).Tous les sous-domaines sont redirigés vers le même équilibreur de charge que leur domaine racine respectif, afin de maintenir la cohérence et la facilité de routage.

Logique de routage DNS

La logique de routage DNS garantit que le trafic utilisateur est dirigé vers l'équilibreur de charge approprié en fonction de l'état du système.

• soit pendant un fonctionnement normal, soit lors d’une récupération d’urgence.

• Opérations normales (le cluster principal est actif) En mode d'exploitation 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

• Récupération d'urgence (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 de cluster principal*
  Nom de domaine complet du cluster secondaire	Équilibreur de charge de cluster secondaire*(non modifié)*