OpenFire 3.7.1 - Good Clustering Solution?

Openfire Openfire Support
1

Hello to the OpenFire Community -

I am presently looking into launching an OpenFire-powered XMPP chat network. I want to be fairly redundant and reliable, and support a huge potential number of clients, so I am looking into a clustering solution.

So far, I have found two clustering solutions for OpenFire:

  1. The one in the Plugins Installation tool in OpenFire Admin GUI. This one does not seem to work, and throws a Java exception when you go to the Clustering page. Some people on the community seem to think it requires proprietary Oracle files to work (where do I obtain those, if so?) Others seem to be saying “oh, the new plugin doesn’t need those”.

  2. The one available from Google Code called open-clustering, but upon emailing and corresponding with its developer, I was discouraged from using it, and he encouraged me to use option 1.

My intended network layout is attached, in case I explain it poorly…

I want to have multiple servers, with 1 unified set of login credentials. Servers will have SSL server-to-server connections, and clients will have an SSL connection to a server of their choice, or decided by round-robin DNS. Users on any server will be able to communicate with users on the other server, as though they’re on the same server, similar to how an IRC network is constructed.

I am more familiar with an IRC network than with a Jabber XMPP network. It is my growing understanding that XMPP is capable of actual mesh clustering? In IRC, there is a hub and leaf approach to networks, which creates single points of failure resulting in netsplits. Since I have setup IRC networks before, but never an XMPP network, I’m a little uncertain about this new topology from a technical standpoint.

It’s also my understanding that clustered OpenFire servers need to have the same MySQL database? That doesn’t make sense to me. Am I supposed to use the same MySQL server for all of my OpenFire cluster - creating a single bottleneck\point of failure, or am I totally missing something here? It seems to me the Jabber servers should be able to transfer all the needed data back and forth to keep their databases in sync. I’m not sure how multiple servers could share one database without running into conflicts of some kind?

____________________________________________________________________________

TL;DR: If you are running an OpenFire cluster, I would love to hear from you. It seems like there’s a fair amount of people asking about clustering but the responses are vague and not helpful to me as a newcomer. If my attached network map looks anything like yours - how did you do it?

**____________________________________________________________________________
**

I don’t want to invest significant time and resources into something that’s already been proven to be impossible, or isn’t going to be supported in future versions of the software. I’m fairly sure I didn’t miss a tutorial… I have been researching this for several days in my free time.

Thank you, and I look forward to finally getting somewhere on this project!

Cheers,

Kirk

proposed-network-map.png1306×681 90.8 KB

2

We run clustered Openfire on 2 servers utilizing the standard clustering plugin with Coherence. You can find the 3.3.1 coherence jars in the forum, or you can find the new beta version of the plugin which works with Coherence 3.7 (We use 3.7.1.0). I never figured out how to get the shoal/open-clustering plugin working properly, so gave up and used Coherence instead.

Since we archive everything, we run a shared database which both Openfire servers connect to - You will need to build appropriate resiliancy into your database infrastructure so it is not a single point of failure. We use Oracle RAC, but MySQL has some replication/fail-over options also. You could probably run independent databases, but every change would have to be replicated to the other database - Any MUC changes, system property changes/adds, etc. You could probably implement a custom process to update/replicate tables, and just make changes in one place.

You might also want to provision a number of connection manager instances in front of your Openfire cluster, as this allows more users to connect and requires fewer resources on the central server(s). You probably also need to replicate your authentication backend somehow (we use AD, so that’s easy to do).

3

Thank you for your response, David.

I have found the jars for Coherence 3.3. on the forums… I am not seeing 3.3.1 anywhere. Does someone have a link to that thread? And, also maybe to a thread on how to implement the Jars?

I will have to look into MySQL replication solutions. Does the entire database need to be replicated on every server then? I would think that would conflict with the configurations - but I suppose that’s not true provided all server-specific configuration is flatfile.

I have been told that connection managers are not needed in a 64-bit architecture, and they were mostly to deal with 32-bit limitations. From what you’re saying, it sounds like that’s not true?

Replicating my authentication backend should be easy, since I plan on using the MySQL backend, which keeps all the credentials right in the database which I’m going to apparently need to repliace anyway.

Cheers,

Kirk

4

Maybe 3.3 was the most current - If you search the forums, there are lots of threads about configuring clustering with both 3.3 and 3.7 releases of Coherence.

In general, the databases need to be identical, so it’s probably best to replicate all tables. There should be no uniqueness within the database to cause a conflict - I run multiple Openfire instances out of the same database without any issues. Even /opt/openfire is from a replicated filesystem, so that’s the same everywhere too.

Not sure on the 32/64bit stuff with connection managers. Certainly there are efficiencies which come from using connection managers, as well as security considerations if you don’t want your Openfire servers on the public internet, or directly accessible externally.

5

Hi,

i think having a big cluster of OpenFire servers would be a pain and a mess. It handles many plugins and has a strong reliability on its MySQL db.

If i had to build an XMPP network with high availability, i’d use 2 OpenFire with a master-master MySQL replication and smaller jabber “proxies”.

There is a POC to do and if you want my opinion i do think the web lacks of a really lightweight C/Go/… xmpp server/client that could handle at least proxying to another server depending on the features it serves.

The XMPP servers comparison on Wikipedia is clear : there is no efficient and open-source xmpp server handling all the possibilities given by this wonderful protocol. If we can’t make one good, why not have both and a reverse proxy ?

Actually i created my account to post this message, and i’ll be interested in hearing your accomplishments in your project, and if anyone is interested about building a small xmpp minion, let’s have a chat