Skip navigation
572 Views 3 Replies Latest reply: Feb 3, 2012 10:35 AM by David RSS
Kirk Schnable Bronze 2 posts since
Jan 31, 2012
Currently Being Moderated

Jan 31, 2012 2:03 PM

OpenFire 3.7.1 - Good Clustering Solution?

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

Attachments:
  • David Silver 201 posts since
    Feb 15, 2009
    Currently Being Moderated
    Feb 1, 2012 1:01 PM (in response to Kirk Schnable)
    OpenFire 3.7.1 - Good Clustering Solution?

    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).

      • David Silver 201 posts since
        Feb 15, 2009
        Currently Being Moderated
        Feb 3, 2012 10:35 AM (in response to Kirk Schnable)
        OpenFire 3.7.1 - Good Clustering Solution?

        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.

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points