[ejabberd] Re: Highly Available setup Qs

Jeff McAdams jeffm at iglou.com
Wed Dec 20 23:36:52 MSK 2006


Badlop wrote:
> 2006/12/19, Daryl Herzmann <akrherz at iastate.edu>:
>> > Anybody have ideas / docs on the best way to approach this?
>> Hi,  Anybody have comments?  Am I missing something obvious?

> You may be missing this newspost, currently the second on ejabberd front
> page:
>  Fault-tolerant XMPP Environment Using Cisco Server Load Balancing
> http://ejabberd.jabber.ru/cisco-slb

couple of comments...

First...Cisco is *EXPENSIVE*.  If you're interested in a hardware
platform to do load-balancing, I can recommend F5 Networks' Big-IP
devices...we use them and they're quite nice, and considerably less
expensive than Cisco.

However, I think I can speak a little bit to Daryl's question, being
somewhat familiar with what he's doing with XMPP.  First, I'm pretty
sure he doesn't need load balancing at all, though it might end up being
a nice bonus.  I think the consideration is purely for High
Availability, with heavy emphasis on mod_muc.

So, let me contribute what I *think* is going to answer Daryl's
questions, with the caveat that I've never actually done any of this, so
I could get some of it wrong, but also with hopes that by posting this,
it will encourage others to jump in and correct where I'm wrong.  :)

The basic ejabberd server is clusterable to have multiple nodes act as
if they are a single server, so basic authentication and presence will
work as expected regardless of which node you connect to.

If you're connected to a node and it fails, then your connection will
get dropped (ie, no stateful fail-over of connections), but you could
then immediately reconnect to another node and go on about your business.

My understanding is that mod_muc is *not* a clusterable component, so if
you run mod_muc on two clustered nodes, you would end up with two
independant sets of chat-rooms.  I'm presuming that two copies of
mod_muc would even start on the nodes with the same configurations...or
would it get started on one and the second one trying to start up result
in some sort of conflict with the first if they were trying to use the
same jid?


This may work for you, Daryl...

I'm guessing something like using Linux heartbeat to have a shared IP
address that will be active on one of the nodes.  Having mod_muc,
configured the same, running on both nodes (again, assuming that they
won't fight over having the same jid in an otherwise clustered
situation), then, if the active server fails, everyone's connection will
get dropped, heartbeat fails over the shared IP address to the other
node, and when everyone reconnects, they rejoin the much chat-rooms on
the second node.  The only thing you would lose is that the history in
the chat-room would be lost for people joining, but I think you're going
to lose that if your mod_muc gets restarted (whether as part of a full
server restart or just restarting mod_muc) anyway, so I don't think
you're any worse off for that.

So...if you ensure that *all* of the people connected to the server are
connected to only one of the nodes, do you really *need* mod_muc to be
clusterable?  To take it a step farther, do you really need (other than
just for ease of management) any of ejabberd's clustering capabilities?
 Perhaps not.  *shrug*
-- 
Jeff McAdams
"They that can give up essential liberty to obtain a
little temporary safety deserve neither liberty nor safety."
                                       -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.jabber.ru/pipermail/ejabberd/attachments/20061220/4dc4efe7/signature.pgp


More information about the ejabberd mailing list