The added value feature of clustering changes in jabberd2 is a possibility to multiplicate not only Session Manager component, but also components connected with XEP-0114 component protocol. Namely: Transports to other networks.
Component protocol connections differ from jabberd2 components that the hash used for selecting component instance to route to is computed using a ‘from’ address, not ‘to’ address. This means that the server (and s2s) userbase is distributed amongst the components (evenly).
I am currently running several clustered transports with no changes to the transport code. Pretty neat. :-)
Hi,
we developed our load-balancer component at SAPO some years back. Using `from` you can load-balance normal transports like MSN, ICQ and something like that, but you need also `to` if you want to load-balance MUC components.
Also, sometimes you want the full JID, but usually you need to balance using the bare jid. I assume that the current code uses the bare jid?
Finally, one question: if you have 4 transports connected and you loose one of them, do you rebalance the JIDs across 3 components, or you keep balancing over 4 transports leaving 1/4 of your customers without service until the transport comes back?
You pointed the deficiencies of the current scheme (that I am aware of).
- It does not work for components that keep some kind of session (like MUC and SM). These need the ‘to’ based hashing – thus SM connects selecting ‘to’ based hash.
- The problem of rebalancing when number of cluster components change. I change the number of the distributed components. This means that some users will loose their transport session. It’s not easy to solve this problem, so I guess we have to live with it.
It does not hurt me that much, as I have the watchdog implemented to keep the components up. :-)
And I couldn’t come up with a scenario that needs full JID hashing.
Regarding the number of external components, after playing with our options, we decided to include in the configuration the total number of connections.
So if we had 4 MSN transports, we specify 4 in the config file, and the load balancer will always hash over the 4 components, independently on how many connections where actually alive.
Our transports where also supervised so any transports would quickly be up and running.
The hard coded number of components makes the hashing more stable, and avoids re-balancing of connections if you loose one of them. It still impacts your customers, but impacts a lower number of them, not all.
Best regards,
when will be official stable release ???
Since AFAIK nobody besides me is testing the development code, stabilisation for the release is taking time.