Considérations relatives à l'architecture de base

Infrastructure, latence, source de données, gestion, RTO et RPO pour Automation Suite multi-sites sur EKS/AKS.

Comme pour tout déploiement multi-sites, les principales considérations d'architecture pour Automation Suite concernent l'infrastructure, la latence, la source de données, la gestion, l'objectif de temps de récupération, l'objectif de point de récupération, etc.

Infrastructure

Nous vous recommandons d’utiliser le même matériel pour les deux clusters. Cependant, le cluster Automation Suite fonctionnera probablement avec des configurations matérielles similaires avec peu de différences. Un matériel hétérogène peut augmenter la complexité et ralentir le dépannage.

Gestion

Les deux clusters Automation Suite sont indépendants et ne partagent aucune configuration. Par conséquent, toute activité de gestion ou de maintenance doit être effectuée individuellement sur ces clusters. Par exemple, vous devez mettre à jour les chaînes de connexion SQL sur les deux clusters, configurer les certificats séparément, etc. De plus, vous devez surveiller les deux clusters indépendamment, les mettre à niveau individuellement, etc.

Source de données

Le magasin d’objets, combiné à la base de données SQL, forme l’état d’un produit installé sur Automation Suite.

Configuration de SQL Server

La configuration de serveur SQL joue un rôle essentiel dans un déploiement multi-sites. Bien que SQL Server soit un composant externe à Automation Suite, quelques étapes supplémentaires sont nécessaires pour garantir une véritable haute disponibilité lors de l'utilisation d'Automation Suite.

Le serveur SQL doit être configuré dans le groupe de disponibilité Always On ou dans les groupes d'échec. Il doit être réparti entre les deux sites pour garantir une haute disponibilité précise lorsqu'un site est en panne. Les deux clusters doivent utiliser le même point de terminaison d'écouteur SQL dans la chaîne de connexion. En outre, il est recommandé de définir la propriété MultiSubnetFailover=True dans la chaîne de connexion lorsque le serveur SQL/les bases de données sont répartis sur plusieurs sous-réseaux.

Pour plus de détails, consultez Utilisation de lire des répliques pour Microsoft SQL Server dans Amazon RDS, Groupes de disponibilité toujours activés et Prérequis, restrictions et recommandations pour Groupes de disponibilité toujours activés.

Configuration du serveur PostgreSQL

Comme SQL Server, PostgreSQL est externe à Automation Suite, mais quelques étapes supplémentaires sont requises pour une véritable haute disponibilité dans un déploiement multi-sites. PostgreSQL est utilisé par Process Mining, Autopilot pour Developers et Temporal en tant que service. Pour la récupération d’urgence, l’Autopilot™ pour Developers doit être répliqué sur le site secondaire. La base de données Process Mining ne nécessite pas de réplication inter-sites. TaaS n'est pas pris en charge dans le cluster secondaire; il est pris en charge uniquement dans le site principal d'un déploiement A/P.

Configurez un serveur PostgreSQL principal sur le site 1 avec une réplication physique vers au moins un serveur de secours en lecture seule sur le site 2, et pointez les deux clusters sur le principal actuel via un seul point de terminaison. En cas de sinistre, promouvoir le site 2 de secours en principal et mettre à jour le point de terminaison afin de pointer vers le site 2.

• Service géré: utilisez la réplication multi-région du fournisseur et la mise à jour de son point de terminaison lors du basculement, par exemple Amazon RDS pour PostgreSQL, la base de données globale Amazon Amazon PostgreSQL ou la base de données Azure pour PostgreSQL.
• Autogéré: faites face au principal avec un enregistrement DNS (par exemple, Amazon Route 53) afin que les deux clusters utilisent la même adresse. Mettez à jour l'enregistrement DNS pour pointer vers le secondaire pendant le basculement.

Configuration du magasin d'objets externe

Le magasin d'objets externe est à l'abri d'une éventuelle corruption due à la défaillance d'un nœud. La réplication des données et la reprise après sinistre peuvent être effectuées indépendamment d'Automation Suite. Comme SQL Server, le magasin d'objets externe doit être configuré dans une configuration de Disaster Recovery haute disponibilité.

L'instance Objectstore principale est physiquement située dans le centre de données principal, et au moins une instance secondaire est située dans le centre de données secondaire avec la synchronisation des données activée. Vous pouvez configurer un équilibreur de charge sur le magasin d'objets pour vous assurer que les deux clusters Automation Suite font référence aux mêmes points de terminaison. Cela rend le déploiement indépendant de la configuration interne du magasin d'objets.

Important :

Pour AWS S3, le point d'accès multi-région ne prend pas en charge toutes les API s3 requises par tous les produits s'exécutant dans Automation Suite. Pour plus de détails sur la liste des API de prise en charge, consultez Utilisation de points d'accès multi-régions avec des opérations d'API prises en charge.

Vous pouvez créer deux compartiments par produit/suite dans les deux régions et activer la synchronisation. Le cluster Automation Suite exécuté dans la même région fera référence aux compartiments de la même région.

Objectif de temps de récupération

La politique de votre organisation concernant les RTO est essentielle à la conception de votre cluster Automation Suite multi-sites. Pour atteindre le RTO souhaité, tenez compte des aspects suivants :

• Conception du gestionnaire de trafic ;
• Disponibilité des nœuds dans le cluster secondaire/passif ;
• Disponibilité de la charge de travail dynamique sur le cluster secondaire ; par exemple, CompétenceML ;
• Gestion de la configuration.

Gestionnaire de trafic

Pour libérer tout le potentiel des deux clusters, il est crucial de configurer correctement le gestionnaire de trafic. Dans l’idéal, la configuration devra faciliter la répartition du trafic vers les deux clusters. Cette stratégie garantit non seulement une répartition équilibrée de la charge, mais également la continuité des activités, en atténuant toute perturbation potentielle en cas d’arrêt complet de l’un ou l’autre des deux sites.

Disponibilité des nœuds

Dans l’éventualité où un site devient totalement non opérationnel suite à un sinistre, l’autre site doit disposer d’une capacité suffisante pour garantir que les automatisations de l’entreprise se seront pas impactées. Une capacité insuffisante au niveau du site opérationnel peut avoir un impact négatif sur le fonctionnement de l’entreprise et potentiellement entraîner des problèmes d’exploitation importants.

Disponibilité de la charge de travail dynamique

Quelques produits, tels qu'AI Center, déploient les compétences ML de manière dynamique au moment du runtime. Le déploiement des compétences dans un autre cluster est toujours asynchrone. Cela ne peut pas garantir leur disponibilité. Pour vous assurer que votre solution d'automatisation revient en ligne dans le délai souhaité, vous pouvez périodiquement synchroniser les compétences dans un autre cluster.

Gestion de la configuration

Comme les déploiements multi-sites d'Automation Suite consistent en deux clusters distincts, toute opération effectuée sur un cluster doit être exécutée sur l'autre cluster à temps pour réduire la dérive. Cela permet de s'assurer que les deux clusters possèdent des configurations similaires et qu'aucun effort supplémentaire n'est nécessaire pendant lors de la récupération.

Objectif du point de récupération

La politique de votre organisation concernant l'objectif du point de récupération (RPO) est essentielle à la conception de votre cluster Automation Suite multi-sites. Pour atteindre le RPO souhaité, vous devez prendre en compte les aspects suivants :

• Synchronisation des données ;
• Sauvegarde planifiée.

Synchronisation des données

Lorsqu'elles sont écrites dans la source de données principale, les données doivent également être synchronisées avec le cluster secondaire. Cependant, il existe un risque de perte de données lorsque le centre de données est en panne et que les données ne sont pas synchronisées. Des configurations réseau exemplaires, telles qu'une bande passante élevée et une faible latence entre les deux centres de données, peuvent accélérer la synchronisation.

Sauvegarde planifiée

La reprise après sinistre n'offre pas toujours une immunité totale contre la perte de données. Cependant, vous pouvez déployer une stratégie de sauvegarde régulière et périodique pour minimiser l'impact du sinistre sur la récupération des données. Pour de plus amples informations, consultez la section Sauvegarder et restaurer le cluster.