Efficient Use of Network Load-Balancing w/ SSL? 33
vw asks: "I was wondering if anyone has setup a webserver farm that uses both SSL and zero-affinity network-load-balancing. (i.e. requests in an SSL channel can be handled by any server in the farm) I have been having a very difficult time locating information on this specific combination of features in a web server product. The closest I found was WLBS, which implies that there must be an affinity toward a particular server for a given client IP. I understand the problem has something to do with sharing SSL certificates between physical machines. Any suggestions?"
F5 Big ip (Score:2, Interesting)
I'm sure you're right. (Score:1)
Do they have sthe support contracts on eBay too?
Re:I'm sure you're right. (Score:1)
The contract is the same as if you bought the hardware new and tacked on the support.
here (Score:1, Troll)
use CGI;
$q = new CGI;
if (rand()<0.5) {
print $q->redirect("https://www1.yourdomain/");
} else {
print $q->redirect("http://www2.yourdomain/");
}
Re:here (Score:2)
Visitors who bookmark pages will end up with a URL to a specific server -- which could be down for maintenance, failure, or simply decommissioned (or maybe you change your naming scheme for the individual servers at some point).
So always remember to point decomissioned servers DNS records back to the main IP address.
A good load balancing solution will recognize SSL sessions and forward them to the same internal machine with each request.
This does that. You only redirect once, when you hit www.yourdomain.
And any load balancing solution that has a feature like that will also include all the basic failover, redundancy, etc. features larger sites absolutely require.
This can easily be extended to do failover.
A good load balancing solution is more than just spreading requests across a group of servers. It provides scalability, performance, uninterrupted service, easier management and updates, network abstraction, monitoring, and an additional layer of security.
You sound like a commercial. In any case, if you have one of those huge sites with tons of money to waste, go and get a commercial load balancer. Two of them, actually. And don't make slashdot do your job for you. You can afford to hire a professional to do the job.
i have.... (Score:1)
the proxy server set will handle your SSL encryption while your web servers in your cluster serve webpages.
ive only done it with apache on linux so i dont know how any other webserver will work.
Re:i have.... (Score:1)
So whatever you use as first load-balancer, make SURE it knows about SSL sessions! But then you have a complex loadbalancer, which then becomes a single point of failure
Re:i have.... (Score:1)
Apache + Splash is the solution (Score:4, Informative)
Basically, it is an Apache module which uses the spread http://spread.org [spread.org] secure mesaging server to synchronizes ssl conection information.
Re:Apache + Splash is the solution [more info] (Score:3, Informative)
Somewhat Simple -- perhaps non-obvious. (Score:4, Insightful)
Lets you buy a single cert, and with hardware crypto you should be able to handle enough for a modest load -- more than a few million pages daily.
Re:Somewhat Simple -- perhaps non-obvious. (Score:2)
If he has 2 load balancers, then he'll get two of these possibly each with their own cert.
That said, 2 load balaners, 4 switches (infront and behind nat'd load balancers / firewalls), N webservers and probably 2 netapps of somekind isn't cheap -- so 2 crypto boxes probably won't make a dent as they can be fairly lightweight.
Re:Somewhat Simple -- perhaps non-obvious. (Score:2)
I think it will work in a lot of enviroments, but if you're heavily concerned with security (e.g. you're passing around credit card numbers), and it sounds like the poster is, relaying information, at any point, unencrypted is a bad idea. If you can't get around (e.g. sometimes front end webservers must talk to DBs) just to limit that network channel to just those devices to reduce the odds of penetration.
Having said that, your problem shouldn't be too bad -- just make sure each physical server has the correct certificates for www.mydomain.com. Did you run into problems with that?
-Bill
Re:Somewhat Simple -- perhaps non-obvious. (Score:2)
There is more SSL traffic than a single box can handle, and load balancers are already involved so it's probably a pretty valid assumption.
You can also do it with Cisco hardware. (Score:1)
Repeat? (Score:1)
Put simply there is no better solution than a hardware one, for this situation. This [nortelnetworks.com] Nortel solution does it all in one box. However, if your traffic load is great enough you might want to look at splitting out the functions across multiple boxes like these Nortel/Alteoon 180 Series [nortelnetworks.com] switches. There is also a separate SSL concentrator/accelerator.
it's not simple... (Score:4, Informative)
Given the technological design behind SSL (in that it operates immediately above IP, and below TCP/UDP), the summary you provide above is true.
That is, you can set up a cluster of web servers behind a typical redirector. Say Server A, B, and C. Each machine has a different IP address, which is a routable address (let's call it w1.foo.com, w2.foo.com, w3.foo.com). There is a single IP address for the "master" domain (say www.foo.com). All machines are set up to serve www.foo.com, both HTTP and HTTPS. For normal HTTP requests, the redirector does it's thing, with EACH http request coming to www.foo.com being served by the next available machine. Any connection a client makes can potentially be served by any machine.
However, since SSL operates below the TCP/HTTP header, a client making a SSL connection to https://www.foo.com will initially be load-balanced across the machines. However, for the rest of that SSL session, it will continue to communicate ONLY with the machine which initially answered the beginning SSL connection.
This isn't a real big problem for most web apps, since each connection is really just getting a bunch of web pages. If the server goes down, you simply have to push RELOAD on the client, and it re-initiates the HTTPS session, getting another machine to answer. It can be a serious problem with other SSL apps, as the termination of a session by the loss of the answering machine may make it difficult to programatically re-start the session.
Just to make this clear: each time a client initiates an SSL session, it gets bound to a single server. This server may be different for each session, but remember that a "session" may include many data requests.
There is no problem sharing certificates between multiple machines (as the cert is tied to hostname, and it's easy to duplicate across multiple web servers). It's an SSL protocol limitation.
-Erik
There is a paper on this topic (Score:2, Informative)
Hmm (Score:2, Informative)
If you said up a brain dead load balancer, the only real impact you'll have is that it'll have to restablish the SSL connection each time it hops servers. Not wonderful, but not the end of the world.
That's assuming you ARE sharing SSL certificates across machines - and if all the servers are supposed to be serving one secure domain (ie https://www.mydomain.com) then I'm not sure why you wouldn't.
A better solution is to use a load balancer that will support 'sticky' based on the SSL session ID, that way the sessions are kept open, saving both ends from a lot of uneccessary work - but this apparently doesn't suit your needs.
Linux Virtual Server with ip affinity (Score:2)
Re:Linux Virtual Server with ip affinity (Score:1)
Re:Linux Virtual Server with ip affinity (Score:2)
Fastest answer... (Score:1)
Erik