Changes to the DRP as of NMC 3.0.1R1
The Newtest business continuity or disaster recovery plan (DRP option) is designed to make probe monitoring and data collection available immediately on a secondary NMC site.
This solution is built on a number of historical internal mechanisms of the Newtest solutions:
- replication of data from robots to several NMC servers
- synchronization of the reference database (NewtestReference) which contains object creation/modification and of the NMC Master server’s robot configurations with its Slave servers
Below is a diagram illustrating the DRP architecture for Newtest from version 2.2.1 to version 3.0.0 with 2 NMC Master/Slave servers (without showing Y-connection of robots) administered by the operator of the Newtest solution:
The advantages this “active/active” solution (both servers operational) were:
- immediate availability of a secondary site
- zero loss of data
Nevertheless, despite continuous improvement to the DRP from v221 to v300, some issues arose through use of the DRP and exercises conducted by our customers. To deal with these issues, the Newtest 3.0.1 DRP solution is now built on the “Disaster Recovery Plan Director”, a new client for controlling the DRP, as well as a Newtest module, the “Disaster Recovery Plan Manager” (or DRP Manager) which is installed on each of the two servers. These two Windows application type components consolidate control and administration of the current solution.
Within the rationale of better controlling a Newtest DRP, it is essential to be able to have a clear view of the state of the DRP architecture in operation, and to be able to make a switch from this control point. A new client application has been developed to suit the purpose: the “DRP Director”, which looks like this:
The “DRP Director” connects to the services of the “DRP Manager” on each of the servers in a DRP configuration to retrieve information about the current role of each server, and can make a switch (the “Set as Master” button) or reset the synchronization directories.
Information is stored locally on the DRP servers in the form of a configuration file which is checked continuously by the “DRP Manager” modules. The architecture diagram below depicts the functionalities of these two new components:
In conclusion, the implementation of “DRP Manager” modules and the remote interface “DRP Director” has greatly simplified the DRP switchover procedure and made it more robust. This solution remains compatible with a Load Balancer server upstream of the NMC front-end servers so that you can switch manually from one web interface to the other.