To plan for the event that the Master becomes unavailable for a substantial period of time, Fox Technologies strongly recommends that you designate at least one of your Replicas as a failover Replica to back up the Master. In the event that the Master needs to be replaced, it would be this Replica that you would convert to become the new Master, perhaps only until the old Master can be brought back online.
This article details how to configure such a failover Replica.
Failover Replicas require a number of preparatory steps to ensure they can be quickly brought into production as the Master if needed.
The failover Replica should:
- Have an identical $BOKS_etc/ENV file as the Master, with the exception that the BOKSINIT variable should be set to server rather than master. In addition, the variable ISMASTER must NOT be set on the failover Replica. For a full list of the variables that must be identical on the Master and Failover Replica, see "ENV variables" below.
- Have the same hotfixes installed as are installed on the Master to ensure a smooth transition and equal operation after converting the Replica to the Master.
- If you have installed the presentation server for FoxT Control Center on the Master, it should also be installed on the failover Replica. In the file /etc/opt/bccps.properties, use the hostname for the Replica rather than the (current) Master for the AdminServerURL attribute.
Note: If you have installed the FCC presentation server on a host other than the Master, you need to update the file /etc/opt/bccps.properties with the name of the failover Replica in the AdminServerURL attribute if it is converted to become the Master.
- Have the following BoKS ENV variable settings: BCCASD=on and BCCASD_ABAC=on (this one is only needed if you are using ABAC). This will ensure that the BoKS admin server is automatically started if the Replica is converted to become the new Master.
- The shared memory size SHM_SIZE should be the same and large enough to provide a sufficient amount of free space. Preferably 50% or more recommended. You can check the available space using the command dumpbase -m.
- Have a copy of the directory $BOKS_var/sso_creds, or on BoKS 7.2 $BOKS_var/ca, that is identical to the directory on the Master on the failover Replica. This directory contains the PKI infrastructure for BoKS. You can configure the program push_files to copy this directory (and other files) to the failover Replica by adding the following lines to the file $BOKS_etc/distrib.cfg:
or for pre-7.2 versions:
For more information see the BoKS man page push_files and the comments in the distrib.cfg file.
- The Replica must have a host certificate (BoKS 7.2 and later) or host virtual card (BoKS pre-7.2 versions).
- The root account on the Replica must be properly protected
- If you are using BoKS password checkout, the Replica must have a copy of the password encryption key $BOKS_etc/pwm/keys/pwmd.key identical to the key on the BoKS Master.
In addition, Fox Technologies recommends following these best practices for your failover Replica:
- This Replica should match the configuration of the Master.
- This Replica should be as far removed from the Master as possible, so as not to be affected by the same disaster.
- Define disaster recovery procedures.
- Plan for multiple types of disaster, for example the Master being out of commission, the Master and Replicas being separated for an extended period.
- Practice disaster recovery regularly.
- Use backup to create an archive copy of the database, making sure you follow your organization’s record retention policy with the backup.
Root Account on Failover Replica
Plan to protect the root account on this Replica just as you do for the root account on the Master. This might include:
- Restrict knowledge of the root password on this Replica to a limited number of administrators.
- Consider creating a Host Group for administration that includes only the Master and the Replica that is designated as backup to the Master, so that Access Routes for administration can be easily set up and will already be in place if the Replica needs to be quickly converted to Master.
You need to have a BoKS account for the root account on this backup Replica. A BoKS account is needed for administration on any host, but is particularly important to have in place for the backup Replica, since access as root is required during and after conversion, and at a time when you cannot use the Master to add the account to the database. With no local root account in the database, you would need to either work locally on the console or deactivate BoKS Protection.
List of ENV variables that should be the same on the Master and Failover Replica where applicable (some are normally left at the default setting or not set at all):
- ADSYNC (if AD Bridge is being used)
- BCCASD_ABAC (if ABAC is being used)
- DRAINMAST_LOG_SLOW_SECONDS, DRAINMAST_PSWUPDATE_LOG_SLOW_SECONDS
- DRAINMAST_STAT_INTERVAL_MINUTES, DRAINMAST_PSWUPDATE_STAT_INTERVAL_MINUTES
- DRAINMAST_STAT_INTERVAL_SECONDS, DRAINMAST_PSWUPDATE_STAT_INTERVAL_SECONDS
- DRAINMAST_STAT_SLOW_LIST_SECONDS, DRAINMAST_PSWUPDATE_STAT_SLOW_LIST_SECONDS
- DRAINMAST_STATLOG_MAXFILESIZE_KB, DRAINMAST_PSWUPDATE_STATLOG_MAXFILESIZE_KB
Note: The variable BCCASD_LISTENADDR should be the same on the Master and the Failover Replica only if the 2 hosts have the same IP address.
For information on recovery procedures in the event of an outage of the BoKS Master, see the BoKS Manager Administration Guide for your BoKS Manager version.