In the next section, we discuss basic concepts behind JBoss' clustering services. It is helpful that you understand these concepts before reading the rest of the Clustering Guide.
A cluster is a set of nodes that communicate with each other and work toward a common goal. In a JBoss Enterprise Web Platform cluster (also known as a partition), a node is an JBoss Enterprise Web Platform instance. Communication between the nodes is handled by the JGroups group communication library, with a JGroups
Channel providing the core functionality of tracking who is in the cluster and reliably exchanging messages between the cluster members. JGroups channels with the same configuration and name have the ability to dynamically discover each other and form a group. This is why simply executing run -c production on two Enterprise Web Platform instances on the same network is enough for them to form a cluster — each Enterprise Web Platform starts one or more Channels with the same default configuration, so that they dynamically discover each other and form a cluster. Nodes can be dynamically added to or removed from clusters at any time, simply by starting or stopping a Channel with a configuration and name that matches the other cluster members.
On the same Enterprise Web Platform instance, different services can create their own
Channel. In a standard startup of the Enterprise Web Platform 5 production configuration, a core general purpose clustering service known as HAPartition creates two channels. If you deploy clustered web applications or a clustered JPA/Hibernate entity cache, additional channels will be created. The channels the Enterprise Web Platform connects can be divided into two broad categories: a general purpose channel used by the HAPartition service, and channels created by JBoss Cache for special purpose caching and cluster wide state replication.
So, if you go to two Enterprise Web Platform 5 instances and execute
run -c production, the channels will discover each other and you'll have a conceptual cluster. It is easy to think of this as a two node cluster, but it's important to understand that you really have multiple channels, and hence multiple two node clusters.
On the same network, you may have different sets of servers whose services wish to cluster. Figure 16.1, “Clusters and server nodes” shows an example network of JBoss server instances divided into three sets, with the third set only having one node. This sort of topology can be set up simply by configuring the Enterprise Web Platform instances such that within a set of nodes meant to form a cluster the
Channel configurations and names match while they differ from any other channel configurations and names match while they differ from any other channels on the same network. The Enterprise Web Platform tries to make this as easy as possible, such that servers that are meant to cluster only need to have the same values passed on the command line to the -g (partition name) and -u (multicast address) startup switches. Different values should be chosen for each set of servers. Section 23.1, “Configuring a JGroups Channel's Protocol Stack” and Section 23.6.2, “Isolating JGroups Channels” cover in detail how to configure the Enterprise Web Platform such that desired peers find each other and unwanted peers do not.
