I posted this topic on the mailing list last night, but it didn't appear to make it public. Anyhow...
I have two ejabberd servers that are interconnected. For clarity they are named server1 and server2. In front of them I have a load balancer with a pool named leadname. I registered an account on server1 and am able to query the vjud without problem (user1@server1). I then registered an account using the leadname and am unable to see the vjud (user2@leadname). I tried modifying ejabberd.cfg like this:
{mod_vcard, [{host, "vjud.leadname.fullyqualified.com"}]},
I tried a few variations of the hostname but in any case, the user logged in as user2@leadname can't see the vjud.
Any ideas how to get the vjud service to be discoverable for clients using a hostname other than the actual hostname of the ejabberd server?
Thanks
cluster related, I'm assuming
I've been battling with clustering ejabberd for about 2-3 weeks (part time) and am still at a loss for understanding how it's supposed to work. Perhaps I'm a retard. I hope that someone (perhaps even Sir Badlop himself) can assist here.
I thought I was getting close when I was able to register accounts with the pooled hostname. I've read that others have used DNS round-robin to achieve load balancing across two or more nodes. Like I said, that was looking good until it came to service discovery. Another article said something about giving the nodes the same name. I can't imagine how that would work.
Right now, I've settled with having server1 be the server that users will register on, and server2 is doing only database replication. Sure, it's an interconnected node, but if server1 goes down, the whole subsystem is down. Is the clustering offered by ejabberd supposed to provide fault tolerance? If so, how?
Just some odd comments
Warning: some of those comments could be erroneous.
The communication between ejabberd nodes in a cluster is done by an unified database, either with replicated or distributed tables. Additional services like MUC does not have any kind of distribution since some of the information they use is not stored in a table.
A user registered in the Jabber server can login to his account on any of the cluster nodes. He specifies the username, server name, password and additionally the server to connect to (psi, tkabber, exodus allow this).
I guess that didn't help in any way :( I experienced with ejabberd clustering last summer and I was able to login on any node. I forgot most of that, and I will not have spare time until this summer.