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 “Primary”) 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 Primary ADSS Server instance fails (e.g. the server fails), then another ADSS Server can automatically promote itself to Primary 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 Primary and all subsequent instances act as Secondarys. 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:

Items	Description
Secondary should check Primary active status every (sec)	A Secondary ADSS Server instance will regularly check that the Primary ADSS instance is still active. This parameter defines how often the Secondary should check the status of the Primary.
Number of times Secondary should re-check before becoming Primary	In case the Secondary finds the Primary to be inactive, then this parameter defines how many times it should recheck the Primary’s online status before promoting itself to become the new Primary.
Up, Down	Use these buttons to re-arrange the ordering of Primary and Secondary 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 Primary and Secondary 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 Primary instance of the ADSS Server and overwrite the existing files present on all Secondary instances:

algorithm.properties file present at the location: “<ADSS installation directory>/console”
Message properties files from the following locations:

“<ADSS installation directory>/console/console_messages.properties”
“<ADSS installation directory>/service/service_messages.properties”
“<ADSS installation directory>/conf/messages.properties”

notification.properties file present at the location: “<ADSS installation directory>/conf/notifications”
service.bat file present at the location: “<ADSS installation directory>/tomcat/bin”
server.xml file present at the locations:

“<ADSS installation directory>/console/server/conf”
“<ADSS installation directory>/console/server/conf”
“<ADSS installation directory>/console/server/conf”