High Availability for SSL Web Site

One of our web server clusters serves a moderate number of busy e-commerce applications. At present, each site lives on a specific web server and has a hot-spare copy mirrored to another web server in the cluster. If a server fails, there is a manual process to re-activate the sites on their failover server. We're getting to a point where we need a better solution, not only for failures, but also so that we can take machines down for maintenance without downtime for the sites.

We're considering building a cluster of 2-3 HAProxy servers (primarily because it has a great performance record) to put in front of the web servers. From what I've read it will meet most of our needs for session management and keeping users on the same server, etc. Our biggest concern is in regards to the SSL certificates. Each of the sites has its own SSL certificate. Since the end users would be connecting to the HAProxy servers, I can only assume that we would need to move the certificates to each of the machines in the HAProxy cluster. Since HAProxy doesn't handle SSL directly, I've read that we can accomplish this with Apache+mod_ssl on the same system through a reverse proxy type forwarding arrangement.

So, my specific question is whether HAProxy is actually the right tool for the job? Will the existing SSL certificates (on a Windows 2003 Server at present, a few are EV-SSL certs) be portable to Apache? Are there other software or hardware solutions that we should consider instead (using HAProxy with an SSL site seems more complicated than it needs to be)? Any other caveats in setting up a high-availability SSL web cluster that we may not have considered?


Solution 1:

If you're open for a Microsoft/IIS 7 solution, one option is to use IIS7's Application Request Routing (ARR).

There is an introduction/tutorial here in this article on learn.iis.net: HTTP Load Balancing using Application Request Routing. There is a feature called "SSL Offloading":

When this feature is enabled, all communication between the ARR server and the application servers are done in clear text, even for HTTPS requests from clients to the ARR server. When both the ARR server and the application servers are deployed within a trusted network, such as within the same datacenter, enabling SSL offloading does not sacrifice security.

Also, enabling this feature can further help to maximize the server resources on the application servers, since they do not have to spend cycles in encrypting and decrypting requests and responses.

If you want to delve into the subject, here is another article about ARR, which explains how to use the mechanism in combination with hardware load balancers.

Solution 2:

In the past i have setup something similar, but we're running mod perl applications which are quite resource hungry. So we essentially ended up with squid in front of the app servers, and we used apache+proxy to achieve ssl offloading so we could then cache all content through squids. For the clustering part we used LVS(linux virtual server)+heartbeat for failover load balancers For the ssl offloading method i used, see this article on my blog for more info