Re: SSL farm
Or you may use PROXY protocol and set send-proxy in your haproxy configuration and ask stud to merge this : https://github.com/bumptech/stud/pull/81 Hervé. On 05/22/2012 05:48 PM, Allan Wind wrote: I read through the last 6 months of archive and the usual answer for SSL support is put nginx/stunnel/stud in front. This, as far as I can tell, means a single server handling SSL, and this is the whathttp://haproxy.1wt.eu/#desi suggest is a non-scalable solution. You can obviously configure haproxy to route ssl connections to a form via the tcp mode, but you then lose the client IP. The transparent keyword is promising but apparently requires haproxy box to be the gateway. Not sure that is possible with our cloud environment. I understand from: http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html#setting-a-session-cache-with-apache-nginx that session reuse (i.e. mod_gnutls in our case) would need to be configured on the backend to permit ssl resume. But how do you go about distributing traffic to a ssl form without losing the client IP? /Allan -- Hervé COMMOWICK Ingénieur systèmes et réseaux. http://www.rezulteo.com by Lizeo Online Media Group http://www.lizeo-online-media-group.com/ 42 quai Rambaud - 69002 Lyon (France) ⎮ ☎ +33 (0)4 63 05 95 30
Re: SSL farm
On 2012-05-23 11:42:24, Hervé COMMOWICK wrote: Or you may use PROXY protocol and set send-proxy in your haproxy configuration and ask stud to merge this : https://github.com/bumptech/stud/pull/81 This is the single ssl server configuration that I explicitly wanted to avoid. Right? /Allan -- Allan Wind Life Integrity, LLC http://lifeintegrity.com
Re: SSL farm
No, you may have multiple stud. On 05/23/2012 04:12 PM, Allan Wind wrote: On 2012-05-23 11:42:24, Hervé COMMOWICK wrote: Or you may use PROXY protocol and set send-proxy in your haproxy configuration and ask stud to merge this : https://github.com/bumptech/stud/pull/81 This is the single ssl server configuration that I explicitly wanted to avoid. Right? /Allan -- Hervé COMMOWICK Ingénieur systèmes et réseaux. http://www.rezulteo.com by Lizeo Online Media Group http://www.lizeo-online-media-group.com/ 42 quai Rambaud - 69002 Lyon (France) ⎮ ☎ +33 (0)4 63 05 95 30
Re: SSL farm
On 2012-05-23 16:21:35, Hervé COMMOWICK wrote: No, you may have multiple stud. And how do you load balance between them? DNS round robin is not good enough. /Allan -- Allan Wind Life Integrity, LLC http://lifeintegrity.com
RE: SSL farm
Or put keepalived in front of 2 or more machines with stud/stunnel/nginx for SSL termination and HAProxy for distributing the traffic to all backends. Keepalived can move a floating IP between multiple machines, and as long as each machine can do ssl termination and load balancing, you've got no single machine that can cause a failure. A crude ASCII drawing should illustrate what I mean: /---machine 1--\ / \ internet---floating ip*-machine 2*---all backend servers \ / \---machine 3--/ Regards, Jens Dueholm Christensen From: Hervé COMMOWICK [herve.commow...@lizeo-group.com] Sent: 23 May 2012 16:37 To: haproxy@formilux.org Subject: Re: SSL farm just use HAProxy to load balance to multiple stud, with send-proxy on HAProxy side, and --read-proxy on stud side. Hervé. On 05/23/2012 04:27 PM, Allan Wind wrote: On 2012-05-23 16:21:35, Hervé COMMOWICK wrote: No, you may have multiple stud. And how do you load balance between them? DNS round robin is not good enough. /Allan -- Hervé COMMOWICK Ingénieur systèmes et réseaux. http://www.rezulteo.com by Lizeo Online Media Group http://www.lizeo-online-media-group.com/ 42 quai Rambaud - 69002 Lyon (France) ⎮ ☎ +33 (0)4 63 05 95 30
Re: SSL farm
On 2012-05-23 16:37:53, Hervé COMMOWICK wrote: just use HAProxy to load balance to multiple stud, with send-proxy on HAProxy side, and --read-proxy on stud side. Thanks for the pointers, Hervé. stud is not in debian stable, and both haproxy and stunnel are too old to have this feature. mod_gnutls doesn't support the proxy protocol as far as I can tell. What happens to a browser session when a ssl connection moves from one server to another without the resume feature mid-stream? Reload, at least with stunnel, implies renegotiation of the ssl connection as far as I can tell. /Allan -- Allan Wind Life Integrity, LLC http://lifeintegrity.com
Re: SSL farm
Without SSL resume, the client will make the server to generate a new asymetric key. Which takes much more resources than a simple SSL transaction. So it's better to be able to resume if your clients move from one LB to an other one very often ;) cheers
SSL farm
I read through the last 6 months of archive and the usual answer for SSL support is put nginx/stunnel/stud in front. This, as far as I can tell, means a single server handling SSL, and this is the what http://haproxy.1wt.eu/#desi suggest is a non-scalable solution. You can obviously configure haproxy to route ssl connections to a form via the tcp mode, but you then lose the client IP. The transparent keyword is promising but apparently requires haproxy box to be the gateway. Not sure that is possible with our cloud environment. I understand from: http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html#setting-a-session-cache-with-apache-nginx that session reuse (i.e. mod_gnutls in our case) would need to be configured on the backend to permit ssl resume. But how do you go about distributing traffic to a ssl form without losing the client IP? /Allan -- Allan Wind Life Integrity, LLC http://lifeintegrity.com
Re: SSL farm
OoO Lors de la soirée naissante du mardi 22 mai 2012, vers 17:52, Bar Ziony bar...@gmail.com disait : You need to place a packet load balancer such as LVS in front of haproxy, which directs SSL traffic to an SSL farm (which saves the client IP), and regular HTTP access to haproxy. That's how I understand it at least. Yes. And solve session problem by using some kind of persistence, for example source hashing load balancing algorithm. -- Vincent Bernat ☯ http://vincent.bernat.im panic (No CPUs found. System halted.\n); 2.4.3 linux/arch/parisc/kernel/setup.c
Re: SSL farm
On 2012-05-22 19:46:45, Vincent Bernat wrote: Yes. And solve session problem by using some kind of persistence, for example source hashing load balancing algorithm. Persistence here meaning ssl packets for a given session goes to the same ssl server? If so what happens if that ssl server dies? /Allan -- Allan Wind Life Integrity, LLC http://lifeintegrity.com
Re: SSL farm
if a SSL server dies, LVS can direct the traffic to another server. Alternatively you can save SSL sessions in memcached for example, to share between SSL servers in the SSL farm. I once stumbled upon a patch for nginx that can do that. Regards, Bar. On Tue, May 22, 2012 at 9:16 PM, Allan Wind allan_w...@lifeintegrity.comwrote: On 2012-05-22 19:46:45, Vincent Bernat wrote: Yes. And solve session problem by using some kind of persistence, for example source hashing load balancing algorithm. Persistence here meaning ssl packets for a given session goes to the same ssl server? If so what happens if that ssl server dies? /Allan -- Allan Wind Life Integrity, LLC http://lifeintegrity.com
