High Availability for CRL Monitor
In a load-balanced configuration there are two or more ADSS Server instances handling front-end services such as the OCSP Service. The background task of CRL polling, i.e. retrieving CRLs from online repositories should be performed by only one instance of ADSS Server. This is because if several ADSS Server instances were polling for CRLs they would simultaneously download and attempt to process the same CRL, which is obviously pointless. However this leads to a potential situation where the ADSS instance which is retrieving CRLs (referred to as the “Master”) can become a single point of failure. If this instance fails then polling for CRLs will not be conducted by any other instance. To overcome this issue, ADSS CRL Monitor implements a high availability option such that if the master ADSS Server instance fails (e.g. the server fails), then another ADSS Server can automatically promote itself to Master and take over the responsibility for CRL polling.
All ADSS Server instances use the same database and use this to check what their status is. The first installed instance of ADSS Server automatically becomes the Master and all subsequent instances act as Slaves. This only applies to the CRL Monitor polling process; other front-end services (e.g. the OCSP service, Signing service, etc) are generally provided by all ADSS Server instances and typically accessed using a hardware load-balancer.
The screen shot below shows the status of two ADSS Servers and the configuration information.
The configuration items are as follows:
Item | Description |
Slave should check Master active status every (sec) |
A Slave ADSS Server instance will regularly check that the Master ADSS instance is still active. This parameter defines how often the Slave should check the status of the Master. |
Number of times slave should re-check before becoming Master | In case the Slave finds the Master to be inactive, then this parameter defines how many times it should recheck the Master’s online status before promoting itself to become the new Master. |
Up, Down | Use these buttons to re-arrange the ordering of Master and Slave instances. |
Remove | Use this button to remove a CRL Monitor Host from the High Availability configuration. |
Synchronising ADSS Server instances deployed in an HA Configuration:
ADSS Server administrators should make sure that the master and slave instances of ADSS Server are synchronised whenever any changes are made to the low-level system files. This can be achieved by following these instructions.
If at any stage changes are made in the following configuration files then the ADSS Server administrators need to copy these files from the master instance of the ADSS Server and overwrite the existing files present on all slave instances:
See also