HA Configuration for Appliance Event Brokers

Two Solace Appliance Event Brokers can be configured as a high-availability (HA) redundant pair so that if one appliance event broker is taken out-of-service or fails, the other will automatically take over servicing clients for the downed appliance event broker. This eliminates the potential for a single point of failure with Solace Platform.

The HA redundancy feature is largely transparent to clients and other appliance event brokers in the network. Only the two appliance event brokers that are paired as mates require explicit configuration to take advantage of the feature — there is no special configuration needed on client host computers.

Appliance Event Brokers support two HA redundancy models:

  • Active/Standby—a primary appliance event broker provides service to clients and sends and receives data and messages, while a backup appliance event broker waits in standby mode—it only provides service should the primary appliance event broker fail. Simultaneous load sharing between the two appliance event brokers is not supported. The active/standby model supports Direct and Guaranteed Messaging clients.
  • Active/Active—both appliance event brokers simultaneously provide service to clients during normal operating conditions. That is, some clients connect to the primary IP interface of one appliance event broker and the rest connect to the primary IP interface of the other appliance event broker that is its mate. This allows for load-sharing between the two appliance event brokers. However, should one of the appliance event brokers go out of service, the remaining appliance event broker can provide the service ordinarily provided by both of the appliance event brokers individually. The active/active model supports Direct Messaging clients.

Before you begin

The instructions that follow assume some familiarity with the appliance event broker's HA feature. For some more detailed information, consider consulting High Availability for Appliance Event Brokers.

Prerequisites

Before configuring the redundancy settings for each appliance event broker to be used in an HA pair, ensure you read and observe all of the following information:

  1. Both appliance event brokers in an HA pair should be the same. That is, appliance event brokers should be the same model (for example, both 3530s or both 3560s) and use the same model Network Acceleration Blades (NABs), Assured Delivery Blades (ADBs), and Host Bus Adapters (HBAs).

    Using matching appliance event brokers avoid potential reductions in messaging performance and/or the number of available client connections if a failover occurs and activity switches over to the appliance event brokers with less capabilities.

  2. Primary, backup, and static IP interfaces must use valid IP addresses, and the primary, backup, and static IP interfaces used by a NAB port should be part of the same IP subnet. This requirement is not enforced by the system.
  3. The Solace Platform version must be the same on both appliance event brokers.
  4. The underlying signaling for HA appliance redundancy is based on RFC 3768. Observe all precautions in RFC 3768 regarding VRRP Virtual Router Identifier (VRID) and uniqueness of protected addresses when configuring system redundancy. In particular:
    1. Both appliance event brokers in the redundant pair must use the same VRRP VRID.
    2. The VRRP VRID used by the HA pair must be different from the VRRP ID used by any other devices on the Layer 2 segment (such as IP routers, or other redundant pairs of appliance event brokers).
  5. The appliance event brokers in an HA pair must have equivalent physical interfaces configured. For example, if all of the physical interfaces for one appliance event broker are configured in a single Link Aggregation Group (LAG), all of the physical interfaces for its mate should also be configured in a single LAG. The Solace Event Broker CLI doesn't enforce this requirement.
  6. When running appliance event brokers as an HA pair, the Spanning Tree Protocol (STP) must either be disabled or set to portfast mode (or equivalent) on the Layer 2 switch ports that the appliance event brokers are connected to. If the switch ports are part of a LAG, then STP must be disabled, or portfast enabled, both on the individual ports, and on the entire LAG.
  7. For an HA pair to function properly, both appliance event brokers in the pair must have the same configuration. For example, they must both have the same Message VPNs, client profiles, and client user names provisioned. For more information, see Config-Sync Configuration.
  8. When you are implementing redundancy with Guaranteed Messaging:
    • Only the active/standby redundancy model is supported.
    • A customer-supplied external disk storage array must be used. See Configuring an External Disk Array for Guaranteed Messaging for more information.
    • The redundant pair of appliance event brokers must be connected to the same external disk storage array and be configured with the same WWN to use the same logical disk on that external disk storage array.
    • Physically connect the ADB mate links of both appliance event brokers together with approved MMF fibre cables. Both ports of the SPF modules in each ADB should be cabled.
    • Use approved MMF fibre cables to physically connect both SPF module ports in the ADB of the primaryappliance with the corresponding SFP module ports in the ADB of its mate. For more information on establishing these mate links, see one of the following topics in the Installation sections for the type of appliance event brokers being paired:
    • Queues and topic endpoints can be configured on either the primary or backup appliance event broker as long as it is active, and this configuration is propagated automatically to the mate appliance event broker.

Appliance Event Brokers in an HA pair should have their clocks synchronized with PTP or an NTP server for Guaranteed message expiry to work as expected in redundant configurations. If the backup appliance event broker doesn't have the same clock time as the primary, then the message will not expire at the expected time if there is a failover between when the message is published and when it is set to expire.