Re: haproxy + stunnel

I will go with stunnel for now. Thank you all!

On Fri, Apr 16, 2010 at 3:06 AM, duncan hall <duncan#viator.com> wrote:
> While I agree NGINX will offer much more flexibility (caching, ssl offload
> and compression), stunnel can be configured for multiple vhosts:
>
> I have moved to NGINX but here is a copy of my old stunnel.conf showing 2
> hosts
>
> cat /etc/stunnel/stunnel.conf
>
>
> pid = /var/run/stunnel.pid
>
> #debug = 7
> output = /var/log/stunnel.log
>
>   socket=l:TCP_NODELAY=1
>   socket=r:TCP_NODELAY=1
>
>   [https-hotelsite]
>   cert=/etc/stunnel/hotelsite.crt
>   key=/etc/stunnel/hotelsite.key
>   accept=10.20.19.118:443
>   connect=10.20.19.118:80
>   xforwardedfor=yes
>   options = NO_SSLv2
>
>   [https-flightsite]
>   cert=/etc/stunnel/flightsite.crt
>   key=/etc/stunnel/flightsite.key
>   accept=10.20.19.115:443
>   connect=10.20.19.115:80
>   xforwardedfor=yes
>   options = NO_SSLv2
>
> #OEF
>
>
> Bernhard Krieger wrote:
>>
>> We changed from stunnel to nginx.
>> If you have several Vhosts (Certs ), you need several stunnel instances.
>> Now its one instance.
>> Additionally nginx has more options to configure....
>>
>> regards
>> Bernhard
>>
>> Am 16.04.2010 06:45, schrieb Willy Tarreau:
>>>
>>> Hi Gabriel,
>>>
>>> On Thu, Apr 15, 2010 at 11:23:37PM -0300, Gabriel Sosa wrote:
>>>
>>>>
>>>> I'm really happy using haproxy so far (so thank you), we are doing
>>>> load balancing of http and smtp with great results
>>>>
>>>> now we need to be able to LB ssl connections and get the ip of our
>>>> customers.
>>>>
>>>
>>> For that you can use the x-forwarded-for patch for stunnel, available on
>>> haproxy's site.
>>>
>>>
>>>>
>>>> In the official haproxy's site you guys recommend Stunnel as an option
>>>> to complement haproxy for ssl.
>>>>
>>>> Now, I know that haproxy can handle a good amount of traffic but do
>>>> you have any idea about this regarding Stunnel? Ssl will be used only
>>>> in few parts of the site but I still want know that Stunnel wont be my
>>>> bottle neck in the future.
>>>>
>>>
>>> In my experience, it performs quite well. You can get around 2000
>>> connections per second per 2GHz CPU core in thread mode. This assumes
>>> that keys are not renewed too often, of course. The thread model will
>>> inevitably limit the number of concurrent connections. I remember
>>> having performed some tests around a few thousand concurrent connections
>>> (around 2-3000), but you will probably not get much higher than that in
>>> this model. Also, SSL connections require heavy memory buffers, so if
>>> you're planning on reaching such numbers, you should definitely run
>>> some tests first to find the memory usage associated with your load.
>>> I may be wrong, but I recall numbers around 64kB per connection, plus
>>> the thread-local context.
>>>
>>> The advantage of using a TCP-level component such as stunnel is that
>>> it is completely scalable. Need more connections ? run it on multiple
>>> machines with LVS or haproxy in front of it and you're done.
>>>
>>> Regards,
>>> Willy
>>>
>>>
>>>
>>
>
>
>

-- 
Gabriel Sosa
Si buscas resultados distintos, no hagas siempre lo mismo. - Einstein