High Availability in PubSub+ Event Broker: Cloud
PubSub+ Event Broker: Cloud is deployed in high-availability (HA) redundancy groups for fault tolerance. HA redundancy provides 1:1 message broker sparing to increase overall service availability. If one of the message brokers fails or is taken out of service, the other message broker automatically takes over and provides service to the clients that were previously served by the now-out-of-service message broker.
To learn more about HA redundancy, see Software Event Broker Redundancy & Fault Tolerance.
PubSub+ Event Broker: Cloud automates this HA redundancy group setup, and makes it easy to use.
PubSub+ Event Broker: Cloud implements HA using an Active/Standby model with an arbiter node (Monitoring Node) for split-brain detection. This requires three nodes each running the software event broker:
- Primary node
- Backup node
- Monitoring node
The primary and backup nodes both run the software event broker under the messaging node role, while the monitoring node runs it under the monitoring node role. Each of their respective roles is fixed by the configuration and never changes.
When in operation, the messaging nodes will assume one of these Active/Standby roles: Primary or Backup. At any one time, one node is the primary and the other is the backup.
Upon a failover, connections to the broker are switched over from the Primary to the Backup node automatically.
Connecting to a Cloud HA Group
Typically, applications using HA would have to provide a host list: one IP address for the primary node and another for the backup node. However, this approach (providing hosts list) will not work for 3rd-party messaging APIs, so PubSub+ Event Broker: Cloud uses a single DNS entry for applications to use (behind a load balancer) abstracting away the switchover between primary and backup in the event of a failure.
HA and Service Types
The following service types deploy an HA redundancy group by default:
- Professional (Standard account)
- Enterprise (Enterprise account)
PubSub+ Cloud automates all of the configuration and setup when you create your messaging service. Once the service is created, applications can use the DNS name entry provided in the connectivity tab in the console.