[stunnel-users] Problem with roundrobbin failover mode?

Mon Jan 7 22:13:31 CET 2013

Following up... I have confirmed that in 4.54, delay=yes works fine with multiple connect= options.

--Matt

On Jan 7, 2013, at 12:39 PM, Matt Wise <matt at nextdoor.com> wrote:

> Ah. Thats it! I also see a fix in 4.54, am I right?
>> "delay = yes" fixed to work even if specified *after* "connect" option.
>> Multiple "connect" targets fixed to also work with delayed resolver.
> --Matt
> 
> On Jan 7, 2013, at 11:39 AM, Michal Trojnara <Michal.Trojnara at mirt.net> wrote:
> 
>> Hi Matt,
>> 
>> Load balancing is incompatible with delayed resolver.  Remove "delay =
>> yes" from your configuration file.
>> 
>> Mike
>> 
>> On 2013-01-07 18:38, Matt Wise wrote:
>>> I've got dozens of clients connecting with Stunnel to a group of 5 servers. Each system has a config that looks like this:
>>> 
>>>> cert = /etc/stunnel/zookeeper.pem
>>>> key = /etc/stunnel/zookeeper.key
>>>> CAfile = /etc/stunnel/zookeeper_ca.pem
>>>> verify = 2
>>>> delay = yes
>>>> sslVersion = TLSv1
>>>> client = yes
>>>> setuid = stunnel4
>>>> setgid = stunnel4
>>>> pid = /var/lib/stunnel4/zookeeper.stunnel4.pid
>>>> socket = l:TCP_NODELAY=1
>>>> socket = r:TCP_NODELAY=1
>>>> TIMEOUTconnect = 2
>>>> session = 86400
>>>> debug = 5
>>>> [zookeeper]
>>>> accept  = 127.0.0.1:2182
>>>> failover = rr
>>>> connect = prod-zookeeper:2182
>>>> connect = prod-zookeeper-1:2182
>>>> connect = prod-zookeeper-2:2182
>>>> connect = prod-zookeeper-3:2182
>>>> connect = prod-zookeeper-4:2182
>>>> connect = prod-zookeeper-5:2182
>>> 
>>> Essentially the first host is a load balancer, and the next 5 are the actual zookeeper hosts so that we can bypass the ELB if its giving us fits. Now what we're seeing is that almost every connection ends up on prod-zookeeper-5. Over and over and over again, our hosts pick the same system each time. We're running Stunnel 4.52:
>>> 
>>>> Clients allowed=8000
>>>> stunnel 4.52 on i486-pc-linux-gnu platform
>>>> Compiled/running with OpenSSL 0.9.8k 25 Mar 2009
>>>> Threading:PTHREAD SSL:ENGINE Auth:LIBWRAP Sockets:POLL,IPv6
>>> 
>>> Any ideas what might be wrong here? Obviously we want the connections to be *roughly* random across the list of hosts... and if one of the hosts goes down, and the connection fails, we want the stunnel service to try again, and randomly pick a new host. It doesn't really seem to be doing that though. 
>>> 
>>> --Matt
>>> 
>>> _______________________________________________
>>> stunnel-users mailing list
>>> stunnel-users at stunnel.org
>>> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>> 
>> 
>> _______________________________________________
>> stunnel-users mailing list
>> stunnel-users at stunnel.org
>> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20130107/cebf6b61/attachment.html>