This is one in a series of messages describing new features in Isode R14.4, scheduled to ship in April 2009. You can see all of the messages on this blog relating to R14.4 by clicking on this link
The core XMPP model is one server per domain. A single M-Link Server can support multiple domains, with delegated administration of users within each supported domain. XMPP Clustering is a technique to enable a single domain to be supported by multiple servers. XMPP clustering is provided by some XMPP servers, using vendor-specific techniques. The capabilities provided varies widely between products, and so features provided should be reviewed with care. Isode is adding XMPP Clustering to M-Link in R14.4.
XMPP Clustering needs to synchronize "state" between servers to ensure that messages are routed to correct destinations and the presence information is correct.
It is also important that information from various services (Presence, Multi User Chat (MUC), and Publish Subscribe (PubSub)) are sent on the local server where possible. For example, where MUC subscribers are on multiple servers, participant groups should be managed locally on each server, and messages sent directly to other local users without having to go to another server first. A related characteristic is the MUC and Pubsub will continue operation in the event of any cluster node failing.
One goal of XMPP Clustering is to support "LAN Clustering", where there are multiple clustered XMPP servers operating on a common fast highly reliable local network. Clustering in this environment is important for large deployments, as it enables servers to be added to support load levels greater than can be handled by a single server. This horizontal scaling is important for service providers and large enterprises. It also provides reliability, so that service can continue in the event of failure (accidental or planned) of a server.
A second and harder goal is to support "Wide Area Clustering", where the XMPP servers are interconnected by links that may be slower and less reliable than a LAN. There are various scenarios where this is important:
- Off site operation of a server, so that service can continue in event of site failure (disaster recovery)
- Support of organizations with multiple sites, so that a server can be run at each site.
- Support of a distributed military deployment, for example with one server at HQ and another in the field.
Supporting Wide Area Clustering requires protocols and algorithms that will deal with wide area network throughput/latency and periods where connectivity is lost. Servers need to be kept in sync, but
operations should continue as well as possible when there are network failures. Having a server close to a client with good connectivity will give a fast and robust client experience. It is important that local traffic is optimized, and not switch between servers except where needed. Handling traffic locally to a server without unnecessary switching is particularly important for Wide Area Clustering.
Isode's XMPP Clustering implementation is designed to work well for both LAN Clustering and Wide Area Clustering environments.
Comments