|
On Tue 09 Aug 2005 02:29:11 BST , Horms <horms@xxxxxxxxxxxx> wrote:
Here is a descrition I wrote a while ago about SSL/LVS
In a nutshell, you probably want to use persistance
and have the real-servers handle the SSL decryption.
<snip>
...this is OK if you have a set of servers onto which you can install
multiple SSL Certs and undergo the pain of potentially having an IP
management nightmare:
1 realserver, 1 site -> 1 "cluster" IP
2 realservers, 1 site -> 2 "cluster" IPs
...
10 realservers, 10 sites -> 100 "cluster" IPs
I think you can see where this is going! Very rapidly the IP address
management becomes unwieldy.
You can of course get around this by assigning different *ports* to
each site on each server, but if you have the cert installed on all
servers in the cluster this soon becomes difficult to manage too.
Offloading onto some sort of SSL "proxy", accelerator, engine (call it
what you will) means that you can then simply utilise the processing
power of that (those) system(s) to do the SSL overhead and keep your
webservers doing just that, serving pages. If each VIP:443 points to a
different port on the "engine" you greatly simplify your address
management too.
Also, most commercial SSL certification authorities will charge you an
additional fee to deploy a cert on more than one machine, so if you can
reduce the number of "engine" servers you reduce your costs by quite
some margin.
You do however still need to use persistence, and potentially deploy
some sort of "pseudo-persistence" in your engines too to ensure that
they are utilising the same backend server. If you don't, you'll get
all sorts of application-based session oddness occurring (unless you
can share session states across the cluster).
HTH
Graeme
|
