Considérations relatives à l'architecture de base

Principales considérations d'architecture pour les déploiements multi-sites d'Automation Suite, y compris les facteurs de latence, RTO et RPO.

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.

Latence

La latence est d’une importance capitale pour la conception d’un modèle actif/actif. Elle indique le temps d’aller-retour (RTT) entre les deux clusters Automation Suite. Un niveau de latence minimal entre les deux sites est idéal afin de réduire considérablement le risque de perte de données en cas de panne. Le seuil RTT doit être inférieur à 10 ms.

Il est impératif de tester rigoureusement le RTT avant de passer en phase de production, en raison de son effet direct sur les indicateurs de performances. Si le niveau de latence dépasse le seuil de référence de 10 ms entre les deux sites, nous vous recommandons d’envisager une configuration actif/passif plutôt qu’une configuration actif/actif.

Remarque :

Tout composant nécessitant une synchronisation doit avoir un RTT inférieur à 10 ms. Cela inclut les serveurs SQL, HAA, le magasin d’objets, etc.

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 les sections Groupes de disponibilité toujours activés et Prérequis, restrictions et recommandations pour Groupes de disponibilité toujours activés.

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.