Discussion:
Passing XMPP/Jabber through haproxy?
Morgan Aldridge
2010-03-02 19:25:21 UTC
Permalink
I'm running haproxy 1.3.15.7 under OpenBSD 4.6 macppc and am having
issues passing XMPP/Jabber through haproxy to Mac OS X 10.5 Server's
jabberd. My /etc/haproxy/haproxy.cfg contains the following:

listen xmpp_proxy
bind *:5222
bind *:5223
bind *:5269
mode tcp
balance roundrobin
server server_xmpp 10.0.1.3 check

Client connections disconnect after a minute or two, whether there's
an active discussion or not, but there doesn't seem to be any other
negative issues (e.g. s2s works correctly and such). I have tried both
"mode tcp" and "mode http".

The only reference I've seen to people load-balancing XMPP/Jabber is
<http://www.formilux.org/archives/haproxy/att-0617/haproxy.cfg> and
nothing's jumping out at me regarding that configuration and mine.

Any tips and/or suggestions would be greatly appreciated.

Morgan
---
http://www.makkintosshu.com/
Morgan Aldridge
2010-03-31 22:33:33 UTC
Permalink
On Tue, Mar 2, 2010 at 2:25 PM, Morgan Aldridge
Post by Morgan Aldridge
I'm running haproxy 1.3.15.7 under OpenBSD 4.6 macppc and am having
issues passing XMPP/Jabber through haproxy to Mac OS X 10.5 Server's
   listen xmpp_proxy
       bind *:5222
       bind *:5223
       bind *:5269
       mode tcp
       balance roundrobin
       server server_xmpp 10.0.1.3 check
Client connections disconnect after a minute or two, whether there's
an active discussion or not, but there doesn't seem to be any other
negative issues (e.g. s2s works correctly and such). I have tried both
"mode tcp" and "mode http".
The only reference I've seen to people load-balancing XMPP/Jabber is
<http://www.formilux.org/archives/haproxy/att-0617/haproxy.cfg> and
nothing's jumping out at me regarding that configuration and mine.
I've tried adding 'option tcpka', to no avail. Obviously, increasing
'srvtimeout' (which is set to '50000' in my defaults) helps, but
shouldn't 'option tcpka' prevent that need? Or, is there a value I
should set 'srvtimeout' to which will be higher than the number of
milliseconds between keep-alive packets?

Morgan
---
http://www.makkintosshu.com/
Willy Tarreau
2010-04-01 05:18:58 UTC
Permalink
Post by Morgan Aldridge
On Tue, Mar 2, 2010 at 2:25 PM, Morgan Aldridge
Post by Morgan Aldridge
I'm running haproxy 1.3.15.7 under OpenBSD 4.6 macppc and am having
issues passing XMPP/Jabber through haproxy to Mac OS X 10.5 Server's
   listen xmpp_proxy
       bind *:5222
       bind *:5223
       bind *:5269
       mode tcp
       balance roundrobin
       server server_xmpp 10.0.1.3 check
Client connections disconnect after a minute or two, whether there's
an active discussion or not, but there doesn't seem to be any other
negative issues (e.g. s2s works correctly and such). I have tried both
"mode tcp" and "mode http".
The only reference I've seen to people load-balancing XMPP/Jabber is
<http://www.formilux.org/archives/haproxy/att-0617/haproxy.cfg> and
nothing's jumping out at me regarding that configuration and mine.
I've tried adding 'option tcpka', to no avail. Obviously, increasing
'srvtimeout' (which is set to '50000' in my defaults) helps, but
shouldn't 'option tcpka' prevent that need? Or, is there a value I
should set 'srvtimeout' to which will be higher than the number of
milliseconds between keep-alive packets?
No, "option tcpka" only enables TCP-level keep-alives. The application
layer cannot be aware of that. It just ensures that all components
along the whole chain see traffic and don't close the connection (eg:
firewalls). By default, TCP keepalives are quite rare, generally one
every 2 hours.

I'm sorry, but I know absolutely nothing about your protocol, so it's
hard to help for your specific case. What I can suggest you however
is to ensure that your "clitimeout" and "srvtimeout" are both equal,
because when any of the two strikes, the connection will be terminated.

Some application-level protocols provide keep-alives (eg, some remote
desktop protocols, SSH, etc...). I don't know if your protocol supports
that. If it does, it would probably be a good idea to enable them,
because the issue you're having with haproxy timing out will be true
for any other component along the chain between the client and the
server. For instance, some HTTP proxies reduce their timeouts under
high loads, and clients passing through them using a CONNECT method
may experience frequent disconnections. I've already seen sub-second
timeouts after one exchange in each direction (agreed, that was a bit
extreme and HTTPS did not work very well) !

Just a few hints...
Willy
Morgan Aldridge
2010-04-01 12:59:51 UTC
Permalink
Post by Willy Tarreau
Post by Morgan Aldridge
I've tried adding 'option tcpka', to no avail. Obviously, increasing
'srvtimeout' (which is set to '50000' in my defaults) helps, but
shouldn't 'option tcpka' prevent that need? Or, is there a value I
should set 'srvtimeout' to which will be higher than the number of
milliseconds between keep-alive packets?
No, "option tcpka" only enables TCP-level keep-alives. The application
layer cannot be aware of that. It just ensures that all components
firewalls). By default, TCP keepalives are quite rare, generally one
every 2 hours.
Okay, now I understand.

I'm running jabber2 on the server side and have found the
configuration settings in c2s.xml (specifically, 'keepalive') for
enabling keep-alives (they appear to be disabled by default). So, I'll
configure that for an appropriate value and make sure the timeouts in
the haproxy listener are set accordingly.
Post by Willy Tarreau
I'm sorry, but I know absolutely nothing about your protocol, so it's
hard to help for your specific case. What I can suggest you however
is to ensure that your "clitimeout" and "srvtimeout" are both equal,
because when any of the two strikes, the connection will be terminated.
Ah, good to know. I'll probably set those timeouts to 5-10 seconds
higher than the keep-alive to make sure no latency in
sending/receiving the keep-alive causes the connection to be closed.

Many thanks for the suggestions!

Morgan
---
http://www.makkintosshu.com/

Loading...