L’évolution du PRA (Plan de Reprise d’Activité) Newtest

17 octobre 2016 Par Posté dans Infos Produits

La solution de Plan de Reprise d’Activité (option PRA) Newtest est destinée à rendre immédiatement disponible la supervision des sondes et la collecte des données sur un site NMC secondaire.

Cette solution se base sur plusieurs mécanismes internes historiques à la solution Newtest :

  • Duplication des données envoyées des robots à plusieurs serveurs NMC.
  • Synchronisation de la base de données de référence (NewtestReference) contenant les créations/modifications d’objets et des configurations de robots du serveur NMC maître avec ses serveurs esclaves.

Ci-dessous un schéma illustrant l’architecture PRA Newtest depuis la version 2.2.1 à la version 3.0.0 avec 2 serveurs NMC maître/esclave (sans la représentation de l’alimentation en Y des robots) à administrer par les exploitants de la solution Newtest :

 

PRA Newtest

 

 

 

 

 

 

 

 

 

Les avantages qu’offre cette solution en « actif/actif » (les 2 serveurs sont opérationnels) sont donc :

  • une disponibilité immédiate d’un site secondaire,
  • aucune perte de données.

Néanmoins, malgré plusieurs évolutions du PRA entre la v221 et la v300, certaines contraintes sont apparues gênantes au fil des usages et exercices de PRA chez nos clients. Pour pallier ces contraintes, un nouveau client de pilotage du PRA, le « Disaster Recovery Plan Director » ainsi qu’un module Newtest installé sur chacun des deux serveurs en PRA, le « Disaster Recovery Plan Manager » (ou DRP Manager) ont été introduits dans la solution de PRA Newtest 3.0.1R1. Ces deux composants de type application Windows consolident le pilotage et l’administration de la solution actuelle.

Dans la logique de mieux contrôler un PRA Newtest, il est essentiel de pouvoir visualiser simplement l’état de l’architecture PRA en fonctionnement depuis un poste tiers et de commander une bascule depuis ce point de contrôle. Une nouvelle application cliente a été développée dans ce sens, le « DRP Director » dont voici un aperçu ci-dessous :

master

 

 

 

 

 

 

 

 

 

Le « DRP Director » se connecte aux services « DRP Manager » sur chacun des serveurs en PRA pour récupérer les informations sur les rôles courants des serveurs et potentiellement commander une bascule (bouton «Set as Master»), une réinitialisation des répertoires de synchronisation, réinitialisation de rôle, un reboot…

Ces informations du rôle des serveurs, stockées localement sur les serveurs en PRA sous forme de fichier de configuration sont vérifiées en permanence par les modules « DRP Manager » qui agissent mutuellement en conséquence et de façon synchronisée lors d’un changement de rôle. Le schéma d’architecture ci-dessous illustre les fonctionnalités de ces deux nouveaux composants :

serveur

 

 

 

 

 

 

 

 

 

 

En résumé, avec l’introduction des composants module « DRP Manager » et l’interface distante « DRP Director » la procédure de bascule du PRA s’en trouve grandement simplifiée et plus robuste. Cette solution se complète idéalement avec un serveur Load Balancer en amont des serveurs web frontaux NMC permettant une bascule manuelle d’une interface web à l’autre.

 

Laisser un commentaire

Votre adresse email ne sera pas publié