> Persistence (cont'd)
3. Persistence limitations - SSL
We've reviewed methods involving snooping on the user-server
exchanges, and sometimes even modifications. But with the ever
growing number of applications relying on SSL for their
security, the load balancer will not always be able to access
HTTP contents. For this reason, we see more and more software
load balancers providing support for SSL. The principle is
rather simple : the load balancer acts as a reverse proxy and
serves as the SSL server end. It holds the servers's
certificates, deciphers the request, accesses the contents and
directs the request to the servers (either clear text or
slightly re-ciphered). This gives a new performance boost to the
application servers which do not have to manage SSL
anymore. However, the load balancer becomes the bottleneck : a
single software-based load balancer will not be faster to
process SSL than an eight-servers farm. Because of this
architectural error, the load balancer will saturate before the
application servers, and the only remedy will be to put another
level of load balancers in front of it, and adding more load
balancers to handle the SSL load. Obviously, this is
wrong. Maintaining a farm of load balancers is very difficult,
and the health-checks sent by all those load balancers will
induce a noticeable load to the servers. The right solution is
to have a dedicated SSL farm.
4. Dedicated SSL-Cache Farm
The most scalable solution when applications require SSL is to
dedicate a farm of reverse-proxies only for this matter. There
are only advantages to this solution :
-
SSL reverse proxies are very cheap yet powerful. Anyone can
build powerful Apache-based SSL reverse proxies for less than
$1000. This has to be compared to the cost of a same
performance SSL-enabled load balancer (more than $15000), and
to the cost of multi-processor servers used for the
application, which will not have to be wasted to do SSL
anymore.
-
SSL reverse proxies almost always provide caching, and
sometimes even compression. Most e-business applications
present a cacheability rate between 80 and 90%, which means
that these reverse proxy caches will offload the servers by at
least 80% of the requests.
-
adding this to the fact that SSL proxies can be shared between
multiple applications, the overall gain reduces the need for
big and numerous application servers, which impacts
maintenance and licencing costs too.
-
the SSL farm can grow as the traffic increases, without
requiring load balancer upgrades nor replacements. Load
balancers' capacities are often well over most site's
requirements, provided that the architecture is properly
designed.
-
the first level of proxy provides a very good level of
security by filtering invalid requests and often providing the
ability to add URL filters for known attacks.
-
it is very easy to replace the product involved in the SSL
farm when very specific needs are identified (eg: strong
authentication). On the opposite, replacing the SSL-enabled
load balancer for this might have terrible impacts on the
application's behaviour because of different health-checks
methods, load balancing algorithms and means of persistence.
-
the load balancer choice will be based only on load balancing
capabilities and not on its SSL performance. It will always be
more adapted and far cheaper than an all-in-one solution.
An SSL-proxy-cache farm consists in a set of identical servers,
almost always running any flavour of Apache + ModSSL (even in
disguised commercial solutions), which are load-balanced either by
an external network load balancer, or by an internal software load
balancer such as LVS under Linux. These servers require nearly no
maintenance, as their only tasks is to turn the HTTPS traffic into
HTTP, check the cache, and forward the non-cacheable requests to
the application server farm, represented by the load balancer and
the application servers. Interesting to note, the same load
balancer may be shared between the reverse proxies and the
application servers.
<<<
[ 5/10 ]
>>>
