Haute disponibilité des applications

Redondance des services & réplication base de données

La disponibilité de votre application est essentielle. Pour vous prémunir de la défaillance d’un des serveurs de l’application, le module COOX-RS propose la redondance des services systèmes et applicatifs et la réplication de la base de données par la mise en place d’un ou plusieurs serveurs secondaires qui prendront la main en cas de problème.

Haute disponibilité des applications

Le module COOX-RS permet la mise en place aisée des mécanismes de redondance et de réplication par simple configuration. Des serveurs différents peuvent être associés à la redondance de chacun des services (système, communication, base de données), ce qui permet au module une efficacité optimale dans de nombreuses architectures.

Le module assure redondance et réplication pour tous les packs MESbox de la gamme COOX.

Objectif : Assurer une continuité de production et d’enregistrement des données

Une architecture matérielle type met en jeu différents acteurs : des serveurs, des clients en réseau, ainsi que des automates programmables industriels, reliés par le réseau de terrain aux serveurs.
Le module COOX-RS fonctionne sur le principe d’un serveur principal et d’un serveur secondaire. Plusieurs couples de serveurs peuvent être mis en place. L’exécution d’un ensemble de services de COOX s’effectue sur un seul des serveurs. En cas de défaillance du serveur principal ou sur action de l’administrateur, l’ensemble des services bascule sur le serveur secondaire.
Les services redémarrent automatiquement. La poursuite du procédé est validée par une action des opérateurs. Les clients se reconnectent automatiquement sur le serveur valide.
Ces capacités sont complétées par une réplication, qui consiste à écrire les données sur deux bases identiques.

L’activation de la redondance est possible dans de nombreux cas qui permettent de couvrir de multiples situations de défaillance en fonction de l’architecture retenue, à savoir :

•  Le serveur principal devient inopérant (crash)
•  Le processus COOX cesse d’être actif sur le serveur principal
•  Le serveur principal n’est plus visible du serveur secondaire
•  Le basculement est forcé par l’applicatif (par exemple sur détection d’un problème de communication entre les automates ou la base de données)
•  Le basculement est demandé par l’administrateur

Exemple d’architecture : redondance d’une application mono-serveur

L’application repose sur deux serveurs seulement, un serveur principal et un serveur secondaire. Pour assurer une continuité de production, les services de COOX, mais aussi les autres programmes (communication, base de données) doivent être présents sur les deux serveurs. Le déploiement des services de COOX est automatique. Le module COOX-RS est également capable de lancer automatiquement les serveurs de communication de type OPC sur le serveur secondaire en cas de basculement.
Le module COOX-RS réplique automatiquement les données en base et entretient le contexte d’exécution du procédé sur les deux serveurs. En cas de basculement, le procédé peut être repris dans l’état où il était parvenu.

Exemple d’architecture : serveurs de communication et ateliers déportés

Dans cet exemple d’architecture, les services de gestion d’un atelier, le client de communication COOX et le serveur de communication sont déportés sur un serveur groupe.

Cette configuration convient bien aux installations qui s’étendent sur de multiples ateliers. Les liaisons de communication sont optimisées, la charge est répartie et les mises à jour d’ateliers sont facilitées.