Hi Jim,
On 26 January 2014 20:15, Jim O'Brien <
jimdo...@gmail.com> wrote:
> Hi,
> I'm looking at XMPP servers and find Prosody quite interesting. Feels
> like a really active project which is important and the documentation is
> outstanding (thanks for this, so helpful). I did look into redundancy
> options and saw from recent (mid 2013) that this was on the todo list. Is
> there a timeline for this?
This is firmly on the todo, and we're making our way towards it in
stages (for example with the new async APIs in the next version).
However for clustering to be ready for production we have no firm
timeline.
> Have others written / looked at monitoring the application and using
> something like keepalived to move a VIP between servers (so a un-elegant
> failover) assuming a shared / sync'd back end database? Are their pointers
> to any writeups of same?
Yes, this has been done. I believe (and he'll hopefully correct me if
I'm wrong) that Kim Alvefur wrote a plugin to monitor another server
and assume control when it became unreachable.
> What kinds of systems are others building for scale (more towards the
> clustering aspect here). Is the deployment model really a single monolithic
> server (seems this way so far in my reading, but I have more reading to do,
> so apologize if I am asking a question I should have read about here).
Most people are using a single server, as it gets you a long way. In
some applications you can scale by "sharding" the users, and having
each Prosody instance serve a different (sub)domain. If the client is
custom, you can manage this fairly easily.
A similar scenario is when your users don't need to communicate with
each other (for example just with Prosody or some service). In this
case you can simply set up multiple Prosody identical instances and do
simple load balancing between them (haproxy works well).
Hope this helps, let me know if you have any other questions.
Regards,
Matthew