Clustering Component

Overview

The clustering component is intended to be an add-on to Jabberd2 installations to provide a clustered, fault-tolerant and redundant environment, by ensuring that functionality of a given domain is provided on multiple machines, and that no single machine is a critical point of failure. This is done by having the cluster component serve two roles; that of a front end to the local session manager, and being a meta-router.

Basic Outline

In broad terms, a 'cluster' refers to a set of machines that all provide service for the same domain. On each machine, or node, within the cluster, the local instance of the cluster component puts itself between the local c2s and s2s instances, and the local session manager instance for the clustered domain(s).

Each instance of the cluster component keeps track of JIDs and domains that are available on the local machine, and passes that information to other instances of the cluster component on other machines.

When a message is received by the cluster component, it passes it to the appropriate local or remote component, based on whether the JID it is being sent to is local or remote.

Note that each machine can still serve multiple domains via multiple session managers, and that these domains do not have to be clustered.

Clustering is not for everyone

Without a connection to a cluster component on a remote machine, the clustering component actually introduces unneeded overhead to local message passing. Standalone machines, with no intention to be part of a cluster, should not run the clustering component, as its functionality provides no additional benefit.

Local Behaviour

As mentioned, the cluster component lies between the c2s/s2s instances, and the local session manager. To the c2s and s2s instances, it appears as the session manager for the clustered domain. To the session manager, it appears as the c2s instance and the s2s instance.

As each local JID connects and disconnects via the local session manager, and connections to external domains are made and lost by the local session manager, the cluster component keeps its own routing tables, and passes this information to other instances.

As incoming routing information is received from other cluster components remotely, the local cluster component updates its local routing table, and binds to the local router as the domains known. [edit] Inter-cluster behaviour

Each cluster instance swaps routing information with other instances. See the Clustering_Routing page for further details of how this is done. Each cluster instance also sends and receives message packets concerning JIDs and domains that it knows about locally.

Note that each cluster instance only communicates with the local router. It relies on a locally-connected s2s instance to handle actual communications with other cluster instances (no point in reinventing the wheel).

Current Status

Nothing of the clustering component has been implemented as yet. (20050425)