To mitigate potential failures of an Address Manager server, BlueCat Address Manager has a failover disaster recovery system with a system for application layer clustering, database replication, and manual system failover. The Gateway Address Manager Failover monitoring feature integrates with this system to maintain a connection between Gateway and Address Manager in the case of a failure by the Address Manager server. When the primary Address Manager server fails and is replaced by a standby server, Gateway can detect this and seamlessly switch its connection to the new primary server.
In more detail:
-
Typically, an Address Manager disaster recovery system consists of two Address Manager servers:
The Primary server holds the primary copy of the database.
The Standby server holds a replicated copy of the database.
Address Manager also supports the use of a second Standby server (also called a tertiary server). When you configure database replication with two Standby servers, the Primary server replicates the database to both Standby servers.
If Gateway is logged into a primary Address Manager server that fails and is replaced by another server in its cluster, Gateway (and any applications running on it) will not function unless it can log in to the new primary Address Manager server.
The Gateway Address Manager Failover Monitoring feature makes sure that Gateway is always logged into whatever server is the current "primary" Address Manager server. That means Gateway automatically logs into and uses the new primary Address Manager server whenever a failover takes place. This makes sure that workflows and applications running on the Gateway platform continue to run without any manual intervention.
When the Address Manager Failover Monitoring is configured and running, Gateway periodically checks the health of the primary Address Manager using the Address Manager REST API. If the primary Address Manager server is down or Gateway loses connection with it, Gateway may query the standby Address Manager instances to determine whether a failover has taken place — and if so, which instance in the cluster is now the new primary Address Manager server. During the failover process itself (while the new primary server is being determined), Gateway will not be connected to any Address Manager. However, it will automatically log into the new primary Address Manager when it is available, at which time Gateway workflows and applications can continue normal operations.
Gateway Address Manager Failover Monitoring limitations
The Address Manager Failover Monitoring feature has the following limitations:
In-memory configuration for Failover Monitoring: Configuration for failover monitoring is stored in memory. Some settings in the General Configuration page affect critical components and will automatically trigger an application restart in Gateway. This restart clears in-memory data, including failover monitoring configuration. That means that after Gateway restarts, users must reconfigure failover monitoring settings.
The following General Configuration settings trigger an application restart:
-
Logs: Any changes to log configuration.
-
Gateway Server Certificate: Updates or modifications to the server certificate.
-
CORS/Security Options: Adjustments to Cross-Origin Resource Sharing (CORS) policies or other security-related settings.
-
-
Complex disaster recovery scenarios: If any changes are made to the replication cluster on the Address Manager side (other than the normal failover procedure), best practice is to stop Address Manager failover monitoring in Gateway.
In some disaster scenarios, Address Manager failover monitoring in Gateway will unintentionally stop — such as when Gateway cannot handle states that result from complex recovery steps performed by administrators on the Address Manager side. If this happens, when normal operations are restored in Address Manager, reconfigure failover monitoring in Gateway and start monitoring again.