On 28/11/2014 05:19 μμ, Lukas Tribus wrote: > Hi, > > >> you're right. >> If you need to scale *a lot* your SSL processing capacity in HAProxy, >> you must use multiple processes. >> That said, multiproc model has some counter parts (stats, server >> status, health checks are local to each process, stick-tables can't be >> synchronized, etc..). >> With HAProxy 1.5, we can now start multiple stats socket and stats >> pages and bind them to each process, lowering the impact. >> That said, if stats, peers, etc matters and you still need a huge SSL >> processing capacity, then the best way is to use a first layer of >> HAProxy multi-process to decipher the traffic and make it point to a >> second layer of HAProxy in single process mode. > > > If that still isn't enough and you need full horizontal scalability: > Handle the SSL load with a two layered load-balancing approach. This > first layer of load-balancers only forwards in TCP mode (with source IP > stickiniess or somethings like this) and you terminate SSL/TLS at the > second load-balancing layer. > > That way you achieve horizontal scalability in the second, SSL/TLS > terminating layer. > >
I have this setup in a different way, where X HAProxies participating in BGP peering(with BFD protocol enabled as well) and upstream routers use ECMP with flow round-robing balancing enabled. But, terminating SSL in multiple end points without any kind of peer information about TLS ticketing and Session IDS, causes problems when you want to implement server-side TLS session resumption. Other people has accomplished this [1] and I am hoping to see support of this setup in 1.6 release:-) > I hope that one day we can move the SSL handshake to dedicated threads, > completely eliminating the event loop blocking and allowing a single > process to forward all the traffic while some parallel threads do all > the heavy SSL handshake lifting. > I was always under the impression that SSL sucks all your CPU resources, therefore it should be used when it is really necessary and when vertical scaling is not a major issue. After the past VelocityConf in Barcelona, I changed my option about it. There are several things that can be done to eliminate the heavy SSL handshake lifting, you mentioned. I have mentioned before [2] that tunning the cipher suite can reduce a lot the CPU load. Other techniques are available as well. By doing all these nice stuff(better products, SSL tuning techinques) not only we safe CPU cycles but most importantly we make user experience better and faster. [1] https://blog.twitter.com/2013/forward-secrecy-at-twitter [2] http://article.gmane.org/gmane.comp.web.haproxy/17663/match=pavlos
signature.asc
Description: OpenPGP digital signature
