Build an Open Source SSL Accelerator

Amin Zelfani writes "SSL accelerators like Big-IP 6900 from F5 Networks typically carry a $50k or more price tag. An article over at o3magazine.com shows you how to build an SSL accelerator that's on par with the commercial solutions, using Open Source projects. SSL Accelerators offload the encryption / decryption process from web servers, reducing load and reducing the number of certificates needed."

Re:Huh?

[TheRaven64]

I think the newer Geodes do, but the older ones have been around for a long while and are still cheap. No idea about Linux - I've no idea why you'd run anything other than OpenBSD on a machine like that.

Re:Huh?

[Anonymous Coward]

nginx, haproxy, varnish-cache

Ok. Lets say your geek is $65k+stuff a year. It takes your geek 6 months to fully ascend the nginx/haproxy/varnish-cache learning curve and get the stack working properly. A geek making only $65k WILL take that long trying to achieve some semblance of parity with a commercial quality, regression tested appliance. That's around $50k in labor (remember, employers pay hidden costs) + hardware (still not free, that.) Meanwhile, you've lost some number of eyeballs to glitches and poor performance and disappointed whomever wanted it 12 weeks ago.

You could use a better geek, but those cost more and you overrun your $50k budget faster, so that's a wash. Might lose fewer eyeballs that way...

Now you rely on a "one off" mystery that your geek, and only your geek, can possibly manage without learning the hard way WHY he's the only one. On the upside you also have the beginnings of a network appliance you might try to productize... if you can get your geek to document it.

Or you could drop $50k now and put your geek on something that doesn't come in a box.

I know, I know. "SIX MONTHS!!!111 What kind of idiot..." I've been involved with this stuff a long time. It isn't done when the light comes on. It takes lots of effort to go from "oh look, it lit up!" to a finished product. In the end you'll spend every damn minute of that 6 months whether you do it up front or amortize it over half a decade. If you take the long view you realize that there is a reason BigIP has customers.

Re:Huh?

[Anonymous Coward]

And an order of magnitude less user-friendliness.

Re:Why a card?

[raddan]

The problem with wiring the accelerator into the CPU is that, although the CPU can perform the calculation faster, it does not actually free the CPU from having to do the packet processing. In addition to CPU time spent, you also need to consider interrupt overhead, which for high-speed networks (like 10GbE) is pretty significant. A separate TCP offload engine, with hardware encryption support, and access to memory via DMA, can significantly reduce the amount of time a CPU spends processing packets. It just interrupts the CPU when a decrypted TCP payload is ready and waiting in memory. And since your add-in card doesn't need a large instruction set, you can make it very, very fast.

Re:Huh?

[Anonymous Coward]

You're confusing 'the time it takes to solve the problem' (i.e., accelerate SSL performance by offloading) against 'the time it takes to produce a a shrink wrapped product that I can sell.'

See, the 50K big-iron will solve the problem; yes. But the goal isn't to replicate what that big-iron never-ever-fail comes-with-a-cherry-on-top can do, the goal is to accelerate *this web server*. Not your web server, not everyone's web servers, but THIS one.

And on THIS web server, we might not *care* about 90% of the things that are supposidly tested on that commerical grade piece of equipment, which is why the geek will only take a week to get it working.

(It's also been my experience that commerical grade tested stuff somehow doesn't seem to work with your piece of equipment, even though the brouchure said it did, meaning you've got both the 50K expenditure AND all the geek time required to get the 50K box doing what it was supposed to do.)

Big iron gear is usually unnecessary. The main question is whether this open source box can keep up with the demand - and, for a lot of situations, it can.