Considérations relatives à l'architecture de base

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.

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 Groupes de disponibilité Always On et Prérequis, restrictions et recommandations pour Groupes de disponibilité Always On.

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

Vous pouvez réduire le temps de récupération en configurant Traffic Manager pour toujours acheminer le trafic vers le cluster principal lorsqu'il est disponible. La redirection vers le cluster secondaire doit être effectuée uniquement lorsque le cluster principal est en panne. Cela garantit que le basculement du trafic est automatique et réduit le temps nécessaire à un basculement manuel. Vous pouvez utiliser les points de terminaison de santé des deux clusters pour y parvenir.

Disponibilité des nœuds

Si tous les nœuds du cluster secondaire sont en cours d'exécution, vous pouvez gagner du temps en allumant les nœuds et en attendant que le cluster soit actif. Cependant, cela peut multiplier par deux le coût de votre infrastructure.

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 la phase de 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 plus de détails, voir Sauvegarder et restaurer le cluster.