Présentation de la haute disponibilité et de la reprise après sinistre
- Dernière mise à jour2023/11/22
Présentation de la haute disponibilité et de la reprise après sinistre
La haute disponibilité (HA) offre un mécanisme de basculement en cas de panne d'un service ou d'un serveur IQ Bot. La reprise après sinistre (DR) permet une reprise à partir d'un site distant en cas de sinistre entraînant la défaillance de l'ensemble du centre de données.
IQ Bot utilise au moins trois nœuds et un maximum de cinq nœuds dans un cluster pour une haute disponibilité (HA).
IQ Bot Solution HA et DR
Dans le contexte d'IQ Bot, la mise en œuvre de la haute disponibilité (HA) et de la reprise après sinistre (DR) réduit les temps d'arrêt et assure la continuité des activités de vos robot.
- Haute disponibilité (HA) : la haute disponibilité est une conception de système architectural qui tente de protéger un système contre certains scénarios de défaillance. Cela signifie que même si des parties d'un système échouent, celui-ci reste dans son ensemble accessible et utilisable. Les solutions de haute disponibilité protègent généralement contre des scénarios spécifiques tels que des défaillances de serveur, des défaillances de composant unique, des défaillances de dépendance, des augmentations de charge variables et des fractionnements de réseaux où des composants système deviennent inaccessibles sur un réseau.
- Reprise après sinistre (DR) : la reprise après sinistre implique un ensemble de stratégies et de procédures permettant la récupération ou la poursuite de l'infrastructure et des systèmes essentiels après une catastrophe naturelle ou d'origine humaine. La reprise après sinistre corrige de nombreuses causes d'échecs différentes dans un système alors que la haute disponibilité n'en gère qu'un certain nombre prévisible. La reprise après sinistre a pour objectif de rétablir les services après un incident et pas seulement après un basculement. La récupération d'un système inclut des scénarios tels que le redémarrage d'un service ou d'un système et la restauration de fichiers de configuration ou d'une base de données à partir de sauvegardes.
Éléments d'infrastructure HA et DR requis
- Approche distribuée : en plus du clustering des composants de centre de données associés à IQ Bot, nous vous recommandons également de déployer IQ Bot sur plusieurs serveurs physiques et/ou virtuels.
- Équilibrage des charges : exécuté par un équilibreur des charges, il s'agit du processus de distribution du trafic d'application ou réseau sur plusieurs serveurs afin de protéger les activités de service et de répartir les charges de travail entre plusieurs serveurs. Cela garantit la poursuite des activités des robots situés sur les serveurs en cluster.
-
Bases de données : les bases de données utilisent leur propre basculement intégré pour protéger les données. Cela garantit les données de la base de données sont récupérées.
- Entre les clusters HA, configurez la réplication synchrone entre les instances Microsoft SQL Server principale (active) et secondaire (passive) regroupées en cluster dans le centre de données. La cohérence des données est ainsi assurée en cas de défaillance d'un nœud de base de données.
Pour la réplication synchrone HA requise, configurez l'un des éléments suivants :
- Réplica de sauvegarde sur les groupes de disponibilité Mode de validation synchrone de SQL Server AlwaysOn
- SQL vers la mise en miroir de la base de données du serveur
- Entre les sites de reprise après sinistre (DR), configurez la base de données pour prendre en charge la réplication asynchrone du site DR principal (production) vers le site DR secondaire (reprise) situé à un emplacement séparé géographiquement du site DR principal.
- Entre les clusters HA, configurez la réplication synchrone entre les instances Microsoft SQL Server principale (active) et secondaire (passive) regroupées en cluster dans le centre de données. La cohérence des données est ainsi assurée en cas de défaillance d'un nœud de base de données.
Exemple de scénario
Pointez toutes les instances de la IQ Bot d'un même cluster vers la même base de données et les mêmes fichiers de référentiel. Cela est nécessaire pour permettre le partage de données sur plusieurs serveurs et s'assurer que l'intégrité des données est assurée sur plusieurs IQ Bots au sein d'un cluster.
Modèles de déploiement HA et DR
Pour faire en sorte qu'IQ Bot bénéficie d'une protection HA et/ou DR, configurez vos centres de données en fonction des modèles de déploiement décrits dans :
Exigences de mise en œuvre HA
- Installez IQ Bot sur plusieurs serveurs.
- L'accès à IQ Bot se fait via un équilibreur de charge.
- Ouvrez un port de synchronisation RabbitMQ v3.8.18 entre les serveurs IQ Bot.
- Configurez Microsoft SQL Server en mode haute disponibilité.
Configuration requise pour l'installation et la configuration HA et DR
- Le programme d'installation d'IQ Bot ne prend pas directement en charge l'installation du cluster. Pour configurer un cluster, effectuez les opérations suivantes :
- Exécutez le programme d'installation sur chaque nœud du serveur d'applications.
- Partagez l'
output folder
à l'aide du rôle d'accèsEveryone
. - Après l'installation, exécutez le
messagequeue_cluster_configuration.bat
avec les arguments de ligne de commande appropriés.
- Configurez IQ Bot dans une configuration de haute disponibilité.
- Ouvrez les ports de pare-feu : 4369 et 25672.
- Installez RabbitMQ v3.8.18 sur chaque nœud IQ Bot du cluster.
Le premier nœud où IQ Bot a été installé devient le nœud RabbitMQ v3.8.18 principal. Le nom d'hôte du nœud principal est utilisé pour configurer le cluster RabbitMQ v3.8.18.
- L'équilibreur de charge est nécessaire pour distribuer un trafic à tous les nœuds de serveur IQ Bot.
- Configurez Microsoft SQL Server pour la haute disponibilité. Utilisez l'option Always On de Microsoft SQL Server.
- Pour une installation spécifique de RabbitMQ v3.8.18, consultez votre documentation RabbitMQ v3.8.18.
Limitations connues de HA et DR
- Pour découvrir la disponibilité des instances IQ Bot, un équilibreur des charges envoie périodiquement des pings, des tentatives de connexion ou envoie des demandes pour tester les instances IQ Bot. Ces tests sont appelés des tests d'intégrité.
- Les tests d'intégrité ne vérifient pas la disponibilité des instances RabbitMQ v3.8.18.