Major Description
The Java Qpid Broker currently supports only 2-nodes HA cluster with BDB JE message store. This JIRA aims to extend the current HA functionality and add support for multi-node HA cluster into BDB JE message store.
Here is the list of high-level requirements for the HA multi-node support:
- Only persistent messages are to be replicated. Transient messages will be lost on failover.
- System must support clusters formed of an arbitrary number of nodes
- System must continue to support clusters formed of two nodes. Existing public interfaces (notably JMX and existing virtualhost.xml format) must be retained (though may be deprecated) to allow existing users a convenient upgrade path.
- System must allow a user to completely configure a new node via the web-management interface.
- System must allow a user to monitor the nodes of the cluster in order to ascertain its health and perform day to day operations for via the web-management interface.
- expose statistics to allow the health of the cluster to be established (exact details to be determined: could be low level like DbPing or something more abstract)
- System must be amenable to monitoring by third-party tools. The Broker should emit clear operational log messages as it transitions between states. These messages will be targeted at the end-user.
- System must permit a mode of operation whereby the user (or other external agent) determines which virtual host becomes active following a store failover. In this mode of operation, following a failure, the store nodes in the cluster will elect a new master and the replica node will still sync-up with the new master node, but the system will not automatically mark the virtual host corresponding to the master as active. The user will then transfer the master to the desired location and make the virtualhost as active, allowing business traffic to recommence.
- System must permit a mode of operation whereby the election of a store node as master also causes the corresponding virtual host to become active.
- System must allow a user to influence a node's electability. These features will allow a customer whose cluster spans primary/DR sites to keep the active virtual hosts on the primary site in normal situations by favouring failover within the primary site.Specifically, this will allow:
- making a node unelectable - the node, even though it remains part of the cluster, will never be elected as master)
- making a node more likely to be elected master than other nodes - that is, if two or more nodes have an equally up to date set of transactions, the node with the highest priority will be elected master
- node electability settings must survive restart,
- node electability settings must be alterable at run-time.
- System must allow a user to alter quorum. This feature is required in extraordinary situations where the system is required to continue to operate despite the loss of sufficient nodes to mean there is no longer simple majority.
- System must allow the user to move the active virtual host from one node to another. This feature will help a user to restore a system to its BAU state following an extraordinary situation.
- System must provide a user with a read-only view Queue when the underlying store is in a replica state. This must provide at least queue name and queue depth. This feature will allow a user to be able to see that replication is indeed functioning.
- System must allow all HA operations to be allowed/denied according to rules in the ACL.
Attachments
Issue Links
- is related to
-
QPID-5543 BDBHAMessageStoreManagerMBean is not unregistered when the corresponding virtual host is deleted
-
- Closed
-