Validating Failover Before Going into Production

After configuring a redundant pair of Solace PubSub+ event brokers, and prior to deploying them into production, it's recommended that the administrator validate their failover operation.

SolAdmin includes the Router Audit tool to verify the correct configuration of redundant event broker pairs. Solace recommends using SolAdmin to manage the event brokers in a redundant pair, thereby automatically ensuring consistency of configuration for both primary and backup event brokers when making configuration changes.

Validating Active/Standby Failover Operation

The following steps are recommended to validate active/standby failover. Validate message flows for all Message VPNs configured on the event brokers.

  1. Connect Direct and Guaranteed clients to the primary event broker, as applicable, and verify message flow.
  2. Run the release-activity Redundancy CONFIG command on the primary event broker. Verify that clients reconnect to the backup event broker, and verify message flow.
  3. Run the no release-activity Redundancy CONFIG command on the primary event broker.
  4. Run the redundancy revert-activity Admin EXEC command on the backup event broker. Verify that clients reconnect to the primary event broker, and verify message flow.

Validating Active/Active Failover Operation

Given physical event brokers R1 and R2, the following steps are recommended to validate active/active failover. Validate message flows for all Message VPNs configured on the event brokers.

  1. Connect Direct clients to the two virtual routers (one on each physical event broker), and verify message flow on both virtual routers.
  2. Run the release-activity Redundancy CONFIG command on R1. Verify that R1’s clients reconnect to R2, and verify message flow for both virtual routers.
  3. Run the no release-activity Redundancy CONFIG command on R1.
  4. Run the redundancy revert-activity Admin EXEC command on R2. Verify that R1 takes over activity for it’s primary virtual router, and that R1’s clients reconnect to R1. Verify message flow on both virtual routers.
  5. Run the release-activity Redundancy CONFIG command on R2. Verify that R2’s clients reconnect to R1, and verify message flow for both virtual routers.
  6. Run the no release-activity Redundancy CONFIG command on R2.
  7. Run the redundancy revert-activity Admin EXEC command on R1. Verify that R2 takes over activity for it’s primary virtual router, and that R2’s clients reconnect to R2. Verify message flow on both virtual routers.