ejabberd 2.0 strongly improves XMPP services clustering. All components included in ejabberd are clustered in this upcoming version, improving scalability and reliability. Moreover, the clustering features are also spreading to external components, thanks to cluster-wide, built-in load-balancing features.
In ejabberd 2.0, code-named Angie for ejabberd Next-Generation, clustering is everywhere. Last week we described how our powerful clustering mechanism evolved into a flexible tool where you can still cluster the router with no single point of failure, but also split the load between front-end and back-end nodes. That’s what Flexarch is about.
This week we will focus on the features we have introduced to enhance services reliability and load-balancing. Some feature described here have been designed with and initially for Portugal Telecom‘s ejabberd large scale deployment and are currently in production already.
Clustered ejabberd components
First of all, all ejabberd components are now supporting ejabberd clustering features. The Multi-user chat components was a component that was known to work only on one node, even in a large cluster. In ejabberd 2.0, this is no longer the case and you can start a MUC instances on all your cluster node if you want to. This make it possible to share the Multi User Chat load on several machines and is a must have for large deployments. In this case chatrooms are distributed among cluster nodes.
ejabberd 2.0 will also include a new proxy server for file transfer, supporting the XEP-0065: Socks Bytestreams. With this Proxy 65 implementation, it means that file transfer can work even if both parties are behind a firewall / NAT. Being clustered, it means that this service can grow with the size of the overall ejabberd domain. This service is also cluster aware from the start.
Clustering is now rooted deeply in ejabberd and module developers are now considering clustering support as a standard requirement.
Clustering for external components
What plays a big part in the success of the Jabber / XMPP protocol is that you can write components in any programming language, as soon as it can talk XML over a simple network connection.
In ejabberd 2.0, we have made the load balancing algorithm used in ejabberd 1.x more generic and more largely useable in various situations. You can plug as many external components that you want per ejabberd node. The traffic will be load balanced according to your need for each specific component type. it means that you can deploy many instances of a single transport on an ejabberd cluster. In this typical case, ejabberd can be configured to distribute the load based on the “from” attribute: The same component instance will get all traffic for a given user, but the overall load will be splitted between all the transport instances. In most cases, with ejabberd you can cluster external components with any modification.
This feature is also very important for reliability: If an instance of a given component goes down, the service can still be up and running: Only the user that were using a given external component instance are affected.
This improved load-balancing is a must-have for large deployments. As an example, Pedro Melo has explained on ejabberd mailing list that this feature is used at Portugal Telecom to distribute the transport load to nine MSN gateways.
Conclusion
With those new features, ejabberd development team shows every one is working hard to make ejabberd the ultimate server for high-performance and critical enterprise XMPP servers. This new release is coming soon. Stay tuned.
