Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

F5 Fires Back On Open Source SSL Accelerator

timothy posted more than 5 years ago | from the first-name-basis dept.

Encryption 120

Random Feature writes "In response to Build an Open Source SSL Accelerator, in which o3 magazine detailed how to build a solution comparable to an F5 BIG-IP 6900 on the cheap, F5 Fires Back claiming it's not as cheap as it appears and pointing out the potential performance implications of a 'cobbled together set of components designed to mimic similar functionality.' The discussion on the performance of the Open Source solution based on Opteron RSA operation processing capabilities brings into question the validity of the 'more SSL TPS for cheaper' argument presented by o3."

cancel ×

120 comments

Less expensive alternatives to F5.... (1)

AbbeyRoad (198852) | more than 5 years ago | (#27612099)

Try protobalance.com

Re:Less expensive alternatives to F5.... (1)

Darby (84953) | more than 5 years ago | (#27618409)

http://kemptechnologies.com/ [kemptechnologies.com]

Happy customer.

Win (0, Insightful)

Anonymous Coward | more than 5 years ago | (#27612151)

Finally, someone who isn't a raisin sack aptly describes all of FOSS:

'cobbled together set of components designed to mimic similar functionality.'

Re:Win (1)

Midnight Thunder (17205) | more than 5 years ago | (#27612425)

'cobbled together set of components designed to mimic similar functionality.'

And in certain cases do a pretty darn good job of it. Just don't expect us to be there 24/7, since the developers might be in a different time zone.

Re:Win (1)

corsec67 (627446) | more than 5 years ago | (#27612621)

But, if you had a few developers spread out (say Europe, USA, and Japan) in enough time zones, you could have 24/7 support.

Justifying the Price Tag, nothing more... (5, Insightful)

geekmux (1040042) | more than 5 years ago | (#27612647)

Finally, someone who isn't a raisin sack aptly describes all of FOSS: 'cobbled together set of components designed to mimic similar functionality.'

Ah, FOSS may be cobbled together at times, and it also may be as polished and clean as many commercial apps, but it still does not erase the bottom line that F5 is still charging an asinine amount of money for their hardware. And in this economy, the financial bottom line tends to speak volumes over F5 coming out and trying to justify their price tag with a weak "yeah, but yours sucks" argument.

This reminds me of my first time opening up the lid on a $30,000 Nokia Firewall-1 rack-mount firewall "appliance". They wanted to sell me a $2000 "upgrade". When I slid the mobo out of the fancy chassis, I found I was staring at a generic Intel mobo with a slot-1 celeron proc and 64MB of SDRAM. I then found out that the $2000 "upgrade" was merely a Pentium Proc and 256MB SDRAM stick. Needless to say, I've been rather tainted with justification for commercial hardware.

Re:Justifying the Price Tag, nothing more... (1)

Zeinfeld (263942) | more than 5 years ago | (#27613575)

At $50K, the F5 offering is hardly going to save anyone much in the way of SSL certs.

But a lower cost open source accelerator might well do so. Offloading the RSA operations to a server farm makes excellent sense. But what might well make a lot more sense is to find a way to use graphics processor cards as SSL accelerators. They are not purpose designed but they are made in vast volume and contain all the parts for a vector processor machine.

A machine that sells a thousand units a year is going to be a lot more expensive price/performance wise than one based on a chip that sells by the hundred million.

If I was starting out 18 months ago I might well think of building something like that. But I strongly suspect that we will see several products of that type being announced next week at RSA.

BTW before folk start accusing me of shilling for my employer, I no longer work there. I am now spending my time making podcasts (see http://quantumofstupid.com [quantumofstupid.com] ) and building daleks [projectdalek.com] in my basement. p Just burning a podcast on Ubuntu at the moment which should be up in about an hour and will be putting together a podcast to handicap and explain the prospects of interesting announcements at next week's RSA cryptographers panel later on today.

SSL on a USB keychain device? (1)

coryking (104614) | more than 5 years ago | (#27614155)

Is there any reason you couldn't put an SSL accelerator on a USB device? Lots of servers have a ton of unused USB ports sitting around. If you could make it USB, you wouldn't have to rip open the web server/reverse proxy server to install it. Sure somebody might walk off with the device, but if you can mitigate that somehow, is there anything technically wrong with the idea?

Re:SSL on a USB keychain device? (1)

Mr. Sanity (1161283) | more than 5 years ago | (#27614257)

If your appliance can handle having the SSL ops throttled to USB 2.0 bandwidth levels, then odds are, you don't need something like an F5. If your question is aimed more at doing this for a small operation, then it may be feasible. But in that situation, the server acting as a load-balancer probably has the cycles to spare to do it on one of its cores.

Re:SSL on a USB keychain device? (1)

Kaboom13 (235759) | more than 5 years ago | (#27614767)

USB is slow, and is CPU dependent. What you gain in offloading the ssl to an usb device you would lose a decent chunk of to USB overhead. USB is the redheaded step-child of the server world for a reason.

Re:Justifying the Price Tag, nothing more... (3, Interesting)

Fulcrum of Evil (560260) | more than 5 years ago | (#27615509)

But what might well make a lot more sense is to find a way to use graphics processor cards as SSL accelerators.

Stick a GTX250 in your server and use a CUDA enabled RSA codec and you're set.

Re:Justifying the Price Tag, nothing more... (1)

afidel (530433) | more than 5 years ago | (#27616505)

You could EASILY save $50k on cert's considering an EV cert is ~$1K/server/year, if you have a few dozen domains and a handful of servers being load balanced then over the three year (conservative) life of the device it could save you money. If you have a large LB farm it's pretty much a no brainer. Of course there are few organizations that buy a BigIP just to save on SSL certs, they are usually bought to allow a scalable, reconfigurable, dynamic farm of servers to handle high traffic loads.

Re:Justifying the Price Tag, nothing more... (1)

MassacrE (763) | more than 5 years ago | (#27620709)

How would an accel. save you a dime on certificates?

Re:Justifying the Price Tag, nothing more... (1)

russg (64596) | more than 5 years ago | (#27614247)

I don't understand your argument. You want to say that the vendor used off the shelf components and imply that for this reason the application wasn't worthy of the costs? In reality the hardware is a very small cost compared to the application development and maintenance. I'm so happy that vendors have been steadily moving to commodity hardware since I date back to years when special built hardware was the norm and it was an enormous cost.

Re:Justifying the Price Tag, nothing more... (1)

Dr_Barnowl (709838) | more than 5 years ago | (#27614925)

I think he was more miffed about being asked to shell out $2000 for about $300 of components.

It's better than the rates that IBM used to charge to send an engineer to snip a single wire link, but not much better.

Re:Justifying the Price Tag, nothing more... (1)

LordLimecat (1103839) | more than 5 years ago | (#27615079)

Part of his complaint seems to be that while it may be fine to pay boatloads for the device because of an OS, its a bit lame for the vendor to then use the situation to try to make ridiculous profits on the extras that DONT have those R&D costs.

I would feel its less of an issue when there arent licensing restrictions that prevent you from doing the hardware upgrade yourself, and it would be excellent if NAS | Firewall | router | etc vendors were willing to sell you support and a bootable flash card containing the OS, as well as having the option to buy the appliance. Then they could charge whatever fee helps them to turn a profit, and WE could worry about the hardware costs.

Re:Justifying the Price Tag, nothing more... (1)

Bert64 (520050) | more than 5 years ago | (#27617613)

A lot of these vendors nowadays use not only commodity hardware, but rebranded OSS software on top of it...
How many of these appliances are based on Linux or BSD?
A lot are also based on quite old versions, and the vendor specific updates tend to trickle down a lot slower than upstream patches do...
Quite often you just don't get value for money at all, you receive commodity hardware and free software and pay a premium for it.

Re:Justifying the Price Tag, nothing more... (1)

idontgno (624372) | more than 5 years ago | (#27617801)

How many of these appliances are based on Linux or BSD?

Well, ironically (and yet apropos at the same time), F5 BIG-IP products [wikipedia.org] . (Currently, Linux; in an earlier incarnation, they ran BSDi; the organization I worked for had a few of these installed at that time.)

Re:Justifying the Price Tag, nothing more... (0)

Anonymous Coward | more than 5 years ago | (#27618811)

The F5 packet processing happens on its own microkernel (TMM) . The linux host is a separate entity on the same box.

I hate to say aynthing in defense of F5, but: (1)

wsanders (114993) | more than 5 years ago | (#27615699)

> F5 is still charging an asinine amount of money for their hardware

Actually, you are paying for the software. Plus support. documentation, etc, that is generally OK. If your IT staff is an army of untrained contractors and support contract administrators it is probably worth it.

But then in a past job I had to stand at attention in front of the CEO and answer the question "WHY THE FUCK DO WE HAVE THESE F5 DEVICES?", and "Because our CIO likes them?" is not really a good answer in a situation like that. So - Am I biased? A tad!

Re:Justifying the Price Tag, nothing more... (1)

AmiMoJo (196126) | more than 5 years ago | (#27616365)

The only real difference between FOS and commercial software, from a purely business point of view, is the support available.

With commercial software you get masses of marketing bullshit and a hotline to India if anything goes wrong. With FOS you get to choose your own support people, quicker fixes for security problems and the option to pay someone to add any feature you like.

Unfortunately, the latter transfers responsibility on to management who can no longer just blame the vendor. It's harder to purchase too because it doesn't come with a glossy brochure.

Re:Justifying the Price Tag, nothing more... (1)

Bert64 (520050) | more than 5 years ago | (#27617495)

A lot of commercial appliances these days are also a bundle of OSS code with a fancy frontend slapped on top and as you pointed out, installed on bargain basement hardware.
Some of these companies are up front about it, and you're paying for the support package... Others actually try to hide the true nature of their appliances.

Re:Win (4, Insightful)

sqlrob (173498) | more than 5 years ago | (#27612815)

'Cobbled Together' describes most proprietary development as well.

Re:Win (4, Insightful)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#27613083)

Ah, but it is harder to see the cobblers, so it must be better.

Re:Win (4, Interesting)

hackus (159037) | more than 5 years ago | (#27613459)

It is even worse than that I am afraid.

Most commercial products do not even have a dividing line between "cobbled" and "polished" now days.

How many different commercial off the shelf Wireless AP's now days come with "cobbled" open source software?

I do not mind paying for software, I do. I just do not like companies that rip off the open source community, then whine and complain when their proprietary code is leaked to the net and it is a crime along with prison and fines, if you touch our code. Apparently you can do anything you like with GNU software.

I want to see Cisco execs in jail like the Pirate Bay people. Unlike the Pirate Bay people though they are actively making a direct profit from breaking the law.

5 years in the pen along with 50 Million put in a trust to start and fund more open source projects. Preferably building open wireless drivers for more cards.

http://www.guardian.co.uk/technology/blog/2008/dec/12/cisco-fsf-opensource [guardian.co.uk]

-Hack

Re:Win (1)

abigor (540274) | more than 5 years ago | (#27615189)

The code used in Linksys routers is available for download. How is Cisco breaking the law?

Re:Win (0)

csartanis (863147) | more than 5 years ago | (#27616323)

rtfa

The FSF has documented many instances where Cisco has distributed licensed software but failed to provide its customers with the corresponding source code.

Re:Win (1)

abigor (540274) | more than 5 years ago | (#27617415)

I did read it. It's all to do with Linksys, which was a Cisco acquisition, and the source has been available for ages. So I'm not sure what the FSF is complaining about - unfortunately, there are no specifics given.

Re:Win (0)

Jah-Wren Ryel (80510) | more than 5 years ago | (#27618201)

It isn't hard to imagine that the FSF is suing because only some of "the source has been available for ages" or maybe Cisco's been adding restriction beyond the GPL to the source code that they do distribute. I bet google could tell you this in about 60 seconds.

Re:Win (1)

abigor (540274) | more than 5 years ago | (#27621253)

I happen to know that code rather well, and it's all there, at least for the routers. Cisco hasn't added anything they haven't released. The existing complaints that I know of (and the ones Google turns up) mostly have to do with build scripts, as what you download can be annoying to build. And it's true that they can be slow to release source when new firmware comes out, but they always do in the end.

Anyway, the poster above that I initially responded to implied that Cisco has released nothing (false), and wants to see Cisco execs imprisoned (absurd).

Re:Win (1)

Wrath0fb0b (302444) | more than 5 years ago | (#27616093)

I do not mind paying for software, I do. I just do not like companies that rip off the open source community, then whine and complain when their proprietary code is leaked to the net and it is a crime along with prison and fines, if you touch our code. Apparently you can do anything you like with GNU software.

No, you have to follow the terms of the license that the creators voluntarily agreed to.

I want to see Cisco execs in jail like the Pirate Bay people.

Did they violate the terms of the GPL. I see their source code posted, so I don't think so ....

Re:Win (0)

Jah-Wren Ryel (80510) | more than 5 years ago | (#27617937)

Did they violate the terms of the GPL. I see their source code posted, so I don't think so ....

Looks like the FSF disagrees with you since they filed suit against cisco and the article was posted only a few months ago.

Re:Win (1)

MikeFM (12491) | more than 5 years ago | (#27615309)

Have you seen non-free code? FOSS may be a cobbled together mess but the vast majority of non-free code is much worse.

Re:Win (1)

Bert64 (520050) | more than 5 years ago | (#27617661)

The messiest FOSS code i have seen, is where a commercial product has been opened up... Quite often it takes several months of OSS development before the mess can even be compiled - proprietary code tends not to have configure scripts or similar, and is nastily kludged to build in a particular unchanging environment.

Got news for ya pal (2, Insightful)

Weaselmancer (533834) | more than 5 years ago | (#27616223)

Everything made today is a "cobbled together set of components." The chips come from Taiwan or Korea or Germany, the plastic from China, the metal from the USA or pretty much anywhere else...you name it. That's why we have standards - so you can replace one part with another.

The difference is in the quality of the cobbling.

And the final proof is in dollars per something-or-other, engineering aside. In this case SSL throughput. Let's see some benchmarks and let's see some dollar signs. Then we'll decide what's useless and what isn't.

How is that different from F5? (2, Interesting)

Anonymous Coward | more than 5 years ago | (#27612223)

The F5 load balancers we have (admittedly not the newest) are just standard ATX & PCI off the shelf products and BSD.

Re:How is that different from F5? (2, Insightful)

Anonymous Coward | more than 5 years ago | (#27612517)

And custom software and encryption accelerator cards.

Re:How is that different from F5? (0)

Anonymous Coward | more than 5 years ago | (#27612765)

It's not any different. They are just mad because someone has the nerve to reproduce in FOSS what they are doing under proprietary wrappings.

Re:How is that different from F5? (5, Funny)

Script Cat (832717) | more than 5 years ago | (#27612771)

I once worked on binary load lifters which are very similar to your F5 load balances in many respects.

Re:How is that different from F5? (0)

Anonymous Coward | more than 5 years ago | (#27613691)

I once worked on binary load lifters which are very similar to your F5 load balances in many respects.

Beep wheep beeeep weeeoooh.

Re:How is that different from F5? (1)

psydeshow (154300) | more than 5 years ago | (#27616181)

We used to cobble together SSL Accelerators from womp rats back home, and they're not much less scalable than a BIG IP-6900.

Re:How is that different from F5? (1)

idontgno (624372) | more than 5 years ago | (#27617901)

Linux, now. Formerly BSDi BSD/OS, but Wind River Systems bought out BSDi in 2001 and pretty much EOL'd BSD/OS by 2004.

Linky [wikipedia.org]

Re:How is that different from F5? (1)

gavint (785035) | more than 5 years ago | (#27620199)

They're two generations old.

The generation after that ran Linux (they dropped BSD) on a server motherboard and a Broadcom switchplane at the front to do the simple stuff.

I've not seen inside the latest generation but I'm told they use a completely custom-fabricated motherboard which integrates the two parts. These still run Linux. Both use SSL accelerator chips.

That said, the hardware is only a small part of what you're paying for, you're also paying for the TMOS operating system, administration interface, other software, support and testing. Obviously there is also some profit, as you can see from their accounts, but if people thought this was unreasonable they would buy an alternative - there are plenty out there.

Shill (1, Interesting)

LordKazan (558383) | more than 5 years ago | (#27612339)

Shilling much?

Re:Shill (1, Troll)

drinkypoo (153816) | more than 5 years ago | (#27613263)

The parent has a point; this response is not only predictable, but precisely the same kind of FUD [slashdot.org] used to sell closed-source products. The difference is that since the F5 is made up of the same stuff that you can roll yourself, it's even less warranted.

Re:Shill (1, Troll)

RiotingPacifist (1228016) | more than 5 years ago | (#27613593)

you know your a shill when:
*Page served on aspx
*You make lists that contain just 2 valid criticisms then bloat it out to 5 with shillness

* TCP connection setup and teardown processing
* Inspection of application data (layer 7 inspection is rarely computationally inexpensive)
* Execution of functionality (caching, security, acceleration, etcâ¦) [does their software magically do these without executing the different operations]
* Transfer of data between proxies (when deployed on the same device this is minimized) [A way of doing it, which is impossible to do with their stack, vs a way both systems can be deployed]
* Multiple log files [cat log1 log2 log3 log4 > logALL too much? I'm sure many loggers could make it even simpler and that's assuming you don't prefer separate log files, for separate steps in the operation]

*You use very artificial scenarios to make your point:

In situations where images are being delivered over a LAN, for example, this will not provide any significant performance benefit and in fact will likely degrade performance.

would you really need ssl acceleration for your lan? would it really be the same one you use for web serving?

He also claims it's impossible to secure a Linux box against ARP poisoning and DoS attacks, which is a shame because in amongst the shilling there are some good points.

Nothing wrong with cobbled together (0, Troll)

sakdoctor (1087155) | more than 5 years ago | (#27612399)

Obviously any company selling "integrated solutions" will say otherwise.

Where is the total non-story tag?

Re:Nothing wrong with cobbled together (1)

backwardMechanic (959818) | more than 5 years ago | (#27612527)

I thought "integrated solution" was business speak for "cobbled together"? You mean there's a difference?

Re:Nothing wrong with cobbled together (2)

lawaetf1 (613291) | more than 5 years ago | (#27612643)

Yes, usually $30k or more in difference.

Re:Nothing wrong with cobbled together (1)

blippo (158203) | more than 5 years ago | (#27615569)

It's the margin on selling things to people who should know their job better.

CHAINING PROXIES vs INTEGRATED SOLUTIONS (3, Insightful)

RiotingPacifist (1228016) | more than 5 years ago | (#27613067)

I'm a huge fan of chaining proxies, one program doing one thing then passing it on to the next, for the security, compatibility & debugging (contrary to what TFA say's you can check the pieces of a chain, but with an integrated solution you can't) benefits. The article does however raise a good point, the integrated solutions will have better performance:

# TCP connection setup and teardown processing
# Inspection of application data (layer 7 inspection is rarely computationally inexpensive)

Which means you'd have to consider the options carefully when looking for an accelerator

Re:Nothing wrong with cobbled together (1)

Bert64 (520050) | more than 5 years ago | (#27617733)

While these "integrated solutions" do have some value inherent in the integration and support, many of them are based on commodity hardware and free software and are massively overpriced... The vendors selling these things don't want people to realise their true value, as it will significantly reduce their profit margins.

Why (1)

jgtg32a (1173373) | more than 5 years ago | (#27612437)

Why would they actually respond to that article, from what it appeared to me the general mood on /. was that it was neat but would be more trouble than its worth.

Re:Why (0)

Anonymous Coward | more than 5 years ago | (#27612651)

scared.
they were scared their sophisticated customers would jump ship. the emperor has no clothes.

it also shows you the power of an open source solution.

Re:Why (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27612709)

Because a lot of us in the technology industry will read /. and investigate the technologies discussed. F5 had to respond in order to provide a counterclaim. You can't let something like the aforementioned article go without response, especially on a forum that will be frequented by those who have a chance of understanding what they or O3 magazine was talking about in the first place.

Rejoice, for /. == 1337

Re:Why (0, Flamebait)

Galactic Dominator (944134) | more than 5 years ago | (#27615353)

Maybe because the "general mood on Slashdot" is completely and utterly irrelevant to people who might be interested in such a solution?

Common response (3, Interesting)

Lord Grey (463613) | more than 5 years ago | (#27612635)

At the risk of being flamed as a troll and getting modded to hell, I'd like to point out that F5's response is exactly the same kind of thing one hears when comparing special-purpose (or custom-written) software to the integration of COTS applications, libraries or frameworks. Sure, with the latter option you get something that works, eventually, but at what cost to maintainability and performance?

I say this after coming out of a meeting where a large Rube Goldberg system of Java tools was presented as the best solution to a high-volume ETL problem that has particular performance and distribution requirements. The resemblance is uncanny.

I'm all for not reinventing the wheel, but if that's what is required, then just do it.

Re:Common response (2, Insightful)

spinkham (56603) | more than 5 years ago | (#27613167)

If you have the experience with Linux based fail over solutions and apache or nginx to pull this off, more power to you. Go ahead and save some bucks, but make sure you test the heck out of it first, and have a plan for updates and failures.
If not, the money you would save is probably not worth the potential downtime you could experience.

Big iron boxes have big iron price tags, and you can almost always hack together something cheaper. The question is how much more reliable, easy to configure, and easy to upgrade is the big iron? In most organizations, buying equipment is cheaper in the long run then buying experience and maintenance for a home grown solution.

Re:Common response (1)

Dare nMc (468959) | more than 5 years ago | (#27613935)

I don't think it is much different, in the "test the heck out of it", etc. It is more can your company afford to internalize the risk, and does your contract with the vendor reduce that. And can you afford the extra time required to DIY. Regardless the solution, you better test the heck out of it if you can't afford the downtime. In times like these it is often more of a, if you can't afford the big iron, then do what you can afford. for example, that is why I went to a (unrelated to the discussion at hand) linux based system 8 years ago over a big iron system. But you know what, that allowed us to learn to support/test our own system, and look through the FUD that any "Big Iron" sales person will fling your way. Now that this updates to the linux system are more "supported" than the big Iron servers (Home office bought the big iron system, it now has less features, and in order to catch up they have to keep buying upgraded software, hardware, and licenses...)
So if you hold onto your employees, your company will likely be better off with any system they are allowed to use/touch/change, than one they pay for and forget about until something changes, and don't be surprised if you scramble to get a response like "we don't support that on the box you have anymore, here buy the new more expensive one".

Re:Common response (1)

Bert64 (520050) | more than 5 years ago | (#27617777)

What these big vendors don't want, is for smaller companies with capable staff creating their own massively cheaper appliances... This will force the big vendors to bring their prices back down to more realistic levels. A lot of these companies are very top heavy, and would experience significant pain if they had to operate on a less extortionate profit margin or against competition.

Re:Common response (1)

zyzko (6739) | more than 5 years ago | (#27617979)

Big iron boxes have big iron price tags, and you can almost always hack together something cheaper. The question is how much more reliable, easy to configure, and easy to upgrade is the big iron? In most organizations, buying equipment is cheaper in the long run then buying experience and maintenance for a home grown solution.

Yes, but big iron boxes are just boxes. They might have special hardware optimized to do what they do, but it just might also be cheaper to DIY. Case in point - EMC Celerra: It is basicly a Redhat with custom management software (with nice but quite expensive hardware). Doing the same thing homegrown (iSCSI + NAS-gui) can be cheaper and you can even have more features. You can buy a support contract and you have a clear upgrade path, and there are propably contractors willing to work for you even if you can't hire a full time admin. But as with SAN/NAS boxes SSL accelerators are not excatly very complicated - a sysadmin with few years experience can get a grip of a homegrown solution within days (without manufacturers expensive training courses).

Re:Common response (2, Informative)

222 (551054) | more than 5 years ago | (#27613505)

With all due respect, load balancing SSL isn't exactly rocket science. It serves a fairly straight-forward purpose. Hell, I did something like this with an Apache box serving as a reverse proxy to an internal web server; my setup isn't designed to accommodate the load discussed in this article, but it does just that. Connections from the outside are secure between my Apache box and the outside world, and my internal web server doesn't worry about a thing.

The Apache reverse proxy was more of a security measure, but SSL offload is just an added benefit.

Re:Common response (1)

Mr. Sanity (1161283) | more than 5 years ago | (#27614063)

...my setup isn't designed to accommodate the load discussed in this article...

Color me surprised. If your solution can't play in the big leagues that an F5 is aiming at, then what are you bragging about?

An F5 isn't aimed at the problem you solved (at least not at that small a scale). It's intended for high-traffic, bandwidth-intensive applications and sites. Did you post to confirm the premise of the article? If so, I totally missed that, what with the way text often fails to convey tone.

Re:Common response (2, Interesting)

222 (551054) | more than 5 years ago | (#27615035)

Again, with all due respect load balancing is something that the Apache crowd figured out a long time ago. My particular setup might not be ripe for the big leagues, but reproduced on an industrial scale Apache is quite capable. I also wasn't "bragging", I was simply sharing my personal experience with this sort of thing. I often appreciate it when other slashdotters do the same.

If you'd like more info on Apache HA, I'd start here:

http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html [apache.org]

You also might want to look at this discussion; its not directly related but has some good commentary:

http://ask.slashdot.org/article.pl?sid=02/06/26/2026217 [slashdot.org]

Re:Common response (1)

Raenex (947668) | more than 5 years ago | (#27615153)

Why did you cut off the ", but it does just that." part?

Re:Common response (1)

Burkin (1534829) | more than 5 years ago | (#27615695)

Because it's easier to attack someone when you take the quote you want out of its context?

Large volume ETL problem (1)

melted (227442) | more than 5 years ago | (#27614775)

Interesting. We use perl scripts and Pentaho to do VERY high volume ETL. One could argue it's a bit Rube Goldberg, but it also works without a hitch, and software cost us $0.

You must be smart when buying these things (4, Insightful)

C_Kode (102755) | more than 5 years ago | (#27612663)

You must be smart when buying stuff like this.

First off, if I'm handling 25k+ SSL TPS, point blank, I pay the money for an F5. A home built solution will only get you fired when something goes seriously wrong.

Secondly, if an F5 is out of your budge and you aren't handling 10s of thousands of SSL TPS, look elsewhere. Kemp Technologies makes a solution that support up to 10k SSL TPS for less than half the price and even cheaper if you handle even less. If you're not even handling a thousand of TPS, let your Apache servers handle SSL and be done with it.

Re:You must be smart when buying these things (0)

Anonymous Coward | more than 5 years ago | (#27612997)

bingo. If you need em, it's worth it to get something that can handle the TPS. If you're running a low volume site, you don't need em.

Re:You must be smart when buying these things (0)

Anonymous Coward | more than 5 years ago | (#27613357)

No one is arguing that the F5 doesn't work, or that no one has enough traffic to justify spending $50k on such a solution.

The question is whether that $50k might be better spent somewhere else -- for that much money you could throw an awful lot of hardware at the home-built solution, so even if you needed 4x as much hardware to reach the same transaction rate you might come out ahead. And if the performance isn't 4x as bad you've probably got enough leftover to implement any entirely separate redundant system with a different technology stack, just in case the first one fails.

Proving a (price) Point... (2, Insightful)

geekmux (1040042) | more than 5 years ago | (#27613411)

You must be smart when buying stuff like this. First off, if I'm handling 25k+ SSL TPS, point blank, I pay the money for an F5. A home built solution will only get you fired when something goes seriously wrong.

I agree you must be wise with your purchases. At times, commercial hardware is justified. That being said, the entire point of the original article was to prove that there's NOT THAT much magic behind F5 hardware to justify the price tag. Accelerating SSL isn't rocket science, nor is it some uber-secret. The main point here was an attempt to prove the FOSS can and will do exactly what commercial software and hardware does at a micro-fraction of the cost. As I've said before, in this economy and shrinking IT budgets, I'm finding it harder and harder to justify uber-elite solutions with obscene price tags.

Re:Proving a (price) Point... (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27617121)

The main point here was an attempt to prove the FOSS can and will do exactly what commercial software

except all f5's products are is open source software + a few application specific chips they wrote drivers for and never reshared their oss updates

Re:Proving a (price) Point... (0)

Anonymous Coward | more than 5 years ago | (#27617483)

You are high.

Re:Proving a (price) Point... (0)

Anonymous Coward | more than 5 years ago | (#27619437)

Furthermore, just because it's FOSS, doesn't mean it has to be home built. If it's a good solution and substantially cheaper than what you can get from F5, someone will come along and sell you a prebuilt hardware package using the FOSS components and a support contract.

Re:You must be smart when buying these things (0)

Anonymous Coward | more than 5 years ago | (#27613573)

DO NOT USE KEMP!!! Their products are incredibly buggy. F5 is worth the money, but it would be a better idea to build your own than to use Kemp.

Re:You must be smart when buying these things (1)

Bert64 (520050) | more than 5 years ago | (#27617811)

So the commercial offerings can and do fail as well...
With your own OSS based setup you have a chance of fixing it, with a commercial setup all you can really do is cast blame, but how exactly does casting blame help you get real work done?

Re:You must be smart when buying these things (1)

RiotingPacifist (1228016) | more than 5 years ago | (#27613899)

A home built solution will only get you fired when something goes seriously wrong.

If you need commercial support, pay for it, my guess is that it will come to less than 45k

F5 is pretty useless too... (4, Insightful)

SuperBanana (662181) | more than 5 years ago | (#27614215)

First off, if I'm handling 25k+ SSL TPS, point blank, I pay the money for an F5. A home built solution will only get you fired when something goes seriously wrong.

An old boss has spent the last FOUR WEEKS with F5 and Cisco trying to figure out why their F5 load balancer starts dropping ACKS on the floor...at connection rates well under advertised capacity of the particular model in question, which has been in production use for months/year+. How the fuck about that- a load balancer that craps out...under load. How useful. The bug is triggered daily when this particular unnamed CA major internet company hits peak usage in the day.

At least with the open source community, you can hire someone to look at the code, or report the bug and try and get it fixed by the community. F5 has been completely useless, reportedly.

Re:F5 is pretty useless too... (3, Interesting)

Anonymous Coward | more than 5 years ago | (#27617355)

Posting anonymously...'cause I work at F5, 3rd tier support.

I'd have to say your former boss' experience and opinion are atypical. Our customer sats are *awesome*, and the problems we address are the most complex. Turnaround time for serious bugs is *incredibly* fast. Open Source fast. Enhancements and minor tweaks, maybe never, and yeah, you can't add them yourself. Unless the behavior you want is in packet processing, in which case you can use TCL based iRules to do unimaginably brutal things to your packets. So most of the flexibility argument is moot.

Without knowing your former boss's case, I can't address it directly. In my own experience, cases drag on when it is difficult to gather the data necessary to show the problem. Often the customer is the bottleneck, and this tracks with customer attitude. The less cooperative and helpful tend to be the least patient as well. "I can't get you tcpdumps! Fix it!" It is also often the case that F5 gets blamed because we're more responsive than the other vendors in the equation and the customers can at least talk to someone.

Your snark is well constructed, but logically inert. F5 stuff handles the biggest loads going. Name a vendor that can compete on pps, thruput or other performance stat. Then show evidence from a repeatable, reasonable test rather than benchmarketing.

If what you need is simple load balancing, you don't need F5. Many situations require more. And yes, the F5 solution is more integrated in a meaningful way than a chain of separate proxies.

Re:F5 is pretty useless too... (1)

idontgno (624372) | more than 5 years ago | (#27618379)

So your answer is, "Our stuff rox, if yours isn't working it's your fault."

Weak.

"Your snark is well constructed, but logically inert. F5 stuff handles the biggest loads going. Name a vendor that can compete on pps, thruput or other performance stat. Then show evidence from a repeatable, reasonable test rather than benchmarketing."

-1, off-topic. (And also -1, marketing.)

He's not talking about throughput, other than the fact that in his specific case, BIG-IP doesn't have it. Corner case, exceptional case, freak accident? Sure. We'll stipulate that. But also valid. Statistical evaluation is the tool of marketing. The current, real-world, bare-metal case at hand is reality. "It usually works" is unacceptable. "It works for everyone but you" is even worse.

If what you need is simple load balancing, you don't need F5. Many situations require more. And yes, the F5 solution is more integrated in a meaningful way than a chain of separate proxies.

"integrated in a meaningful way" isn't particularly meaningful, except in a market-buzzword sense. Care to cite concrete examples of how integration improves throughput in BIG-IP products?

Now, all that said, I generally like F5 products. I've been in large military data centers where the load-balancer of choice was BIG-IP, and almost always it worked out well. Performance was good, reliability was good, and it certainly made DoD PKI easy to deploy.

But your response would have been completely unacceptable if we had a problem with our F5 products and you were handling our case. Entirely blaming the customer for the joint (customer and tech) inability to resolve a crippling problem is just wrong.

Re:F5 is pretty useless too... (0)

Anonymous Coward | more than 5 years ago | (#27619205)

That wasn't my point at all, and no reasonable reading of what I said could lead to that conclusion. Parent said "F5 is useless" and cited his old boss's complaint about a support case. I cited awesome customer satisfaction stats that are especially impressive given the complexity of the issues we deal with.

I don't have the case, so again, I can't comment on the specifics. I'm not saying that in the aggregate we're great. I'm saying in tons of specific cases we're great and if you aggregate them, the sum is great. Our benchmarks are repeatable and we publish the test specs. I don't see that a lot from other vendors. I see competitors "sponsoring" favorable results in a ham fisted way. And this would not be my final response to a customer - we'd dig into the corner case and most probably fix it. BIG-IP is deployed in a tremendous variety of settings because of corner cases ironed out one by one. I would not draw any conclusions from a second hand report from a disgruntled customer who may not have assisted in the resolution of his own problem (an issue in my current caseload). It is very common for a case such as this to be resolved when we demonstrate that the problem lies elsewhere. (again, an issue in my current caseload). That's why I'm not falling on my sword because that customer is unsatisfied. It's just too common for the source of dissatisfaction to be with the customer for me to assume F5 blew it. I'm not closing the case "Close code: customer is a bozo". I am saying this is atypical and its plausible that F5 may not be at fault.

"integrated in a meaningful way" is addressed in the devcentral.f5.com article. I quote from it the following costs to the proxy chain:

* TCP connection setup and teardown processing (surprisingly big win)
* Inspection of application data (layer 7 inspection is rarely computationally inexpensive) (will grant this has to be done somewhere, once the data arrives)
* Execution of functionality (caching, security, acceleration, etc...)
* Transfer of data between proxies (when deployed on the same device this is minimized)
* Multiple log files (most people ignore these, but does suggest troubleshooting headaches)

I'm not going to post internal architecture details, sorry. But draw your own picture from the above.

Re:F5 is pretty useless too... (1)

Skuld-Chan (302449) | more than 5 years ago | (#27619315)

Actually his experience is pretty accurate - I used to work as a Tier 3 for a particular enterprise application. I'd tell TAM's and Tier 2's all the time that engineering can turn around fixes rather quickly if we have a test case and some data to go on.

Sadly our most vocal customers who had cases that would drag on for ages almost always refused to offer data, or give me access to custom applications or workflows so I could reproduce the issue etc.

All he's saying is - if you cooperate and do what I say - we can fix stuff fast, but if you like to dick around - have fun.

Re:F5 is pretty useless too... (1)

bernywork (57298) | more than 5 years ago | (#27619383)

"integrated in a meaningful way" isn't particularly meaningful, except in a market-buzzword sense. Care to cite concrete examples of how integration improves throughput in BIG-IP products?

How about FTFA:

"Chaining proxies incurs latency at every point in the process. If you chain proxies, you are going to incur latency in the form of:

        * TCP connection setup and teardown processing
        * Inspection of application data (layer 7 inspection is rarely computationally inexpensive)
        * Execution of functionality (caching, security, acceleration, etc...)
        * Transfer of data between proxies (when deployed on the same device this is minimized)
        * Multiple log files
"

Simply, going from kernel memory to user memory doing the work, back to kernel memory (For the IP stack), back to user memory, back to kernel memory, back to kernel memory (Hang on, where was I?) That's right, I was running around all over the place causing latency, lets not forget that writing IO takes CPU time, as the article stated TCP connection setup and tear down and everything else, and it's going to add latency and thus decrease the bandwidth capability of the box.

Re:You must be smart when buying these things (0)

Anonymous Coward | more than 5 years ago | (#27616315)

Just build out a normal load balancer/apache web farm, but use Sun systems with the T2/T2+ CPUs for the web servers. These systems have crypto acceleration built into the CPUs and it is amazingly fast. These servers are also pretty cheap. Here's [sun.com] some benchmarks.

Re:You must be smart when buying these things (0)

Anonymous Coward | more than 5 years ago | (#27616447)

nCipher sells an SSL-inline NIC that does 10k TPS/300mbit bulk, called nFast. I used to support these things and they're pretty cool. I'd just connection-balance 25k connection traffic across a few of those and let Apache sort out the web server affinity/balancing issues.

FOSS won't ever touch commercial QoS on SSL unless they approach it with some honesty about the actual cost of transactions, and that doesn't mean freaking out over a $50k pricetag for bulk-processing equipment.

SSL TPS Reports (1)

igibo (726664) | more than 5 years ago | (#27614029)

Hi, Peter. What's happening? We need to talk about your SSL TPS reports.

Of course I could produce something similar (5, Informative)

russg (64596) | more than 5 years ago | (#27614087)

Let me first state that I over see a large deployment of F5 systems and I have compared commercial offerings in this space many times over the years. I have a deep understanding of the tools available and see the work product every day.

Both articles are great for debate. Showing that FOSS and tools available could produce a solution that resembles a commercial product is wonderful in promoting the power and breadth of FOSS. F5's response is good but also a bit disappointing as I find they have much more than is covered in their response.

I'm honestly surprised that F5 responded at all as there's really no comparison between the solutions for real world work loads and support. First and foremost is the thought that these are only load-balancers. The term used most appropriately today is "ADC" (Application Delivery Controller). The reason is that they not only perform load-balancing but reverse proxy cache, compression, acceleration, tuning, and in-stream logic decisions.

F5's products allow you to create profiles for services that are reusable and easy to maintain. You can deliver new configurations in minutes. They also work with the major application vendors to produce proper configurations that you can use out of the box. iRules (TCL) is an awesome tool directly integrated into the product that as F5's tag line says, "With iRules you can". Even with all of the this power and robust tools you will see little or no impact on high performance applications.

F5 also offers the community DevCentral which, in my opinion, gives back to the community in a proper FOSS style.

I won't even go into the underlying architecture such as the TMM kernel and separate management kernel.

F5's article does state one thing very clear and I would want to emphasis it. Humans cost far more over time than capitol expenditures.

I believe that F5 has taken FOSS to proper pedestal in the industry. If anyone thought for one second that FOSS was toys and not to be considered for serious work loads then F5 proves them wrong. Cisco has been trying to chase F5 for years and are still nowhere near them. F5 systems are my swiss-army knife of networking and I'm proud to purchase and use them from my FOSS background but also know they save my butt every day.

Re:Of course I could produce something similar (2, Interesting)

Jah-Wren Ryel (80510) | more than 5 years ago | (#27617889)

I'm honestly surprised that F5 responded at all as there's really no comparison between the solutions for real world work loads and support.

Me too. If anything, making a defensive response like that is going to lend credence to the other side of the argument. People who know what F5 does don't need to be convinced, but those don't know are now thinking "hey, F5 is afraid of this." Seems like bad marketing to me.

Both F5 and o3 missed the real differences (0)

Anonymous Coward | more than 5 years ago | (#27614279)

Oddly enough, F5's reply missed the one bit that is their strongest difference and the one bit I was disappointed to not see in the original article, namely offloading the SSL to the NIC. This really comes down to a scaling issue. It costs to service interrupts copy data up to user-land, do the ssl, block on write, copy it down, catch another interrupt, .... So what tends to give out first using 'plain old nics' is the kernel io and process swap times. Now you might say, "go scale it horizontally and keep the cheap hardware". But how are you doing that? Put it behind a load balancer? Well if the LB has SSL acceleration (and don't they all) then why not just do that. Now maybe you can dodge that a bit with some round robin DNS or similar. But in the end you want a single entry point that scales. Really you want a HA clustered entry point that looks like a single entry point, which would be the next issue I'd have with the solution proposed by o3.

I'm not saying that o3's idea doesn't have some merit on the low end. But its not an apples to apples comparison with a BigIP. And it would be possible to do an open source, home brew system that did hardware SSL acceleration and supported HA clustering, and is a fairer comparison. That a project like that would have been a heck of a lot more interesting. And that that's kind of what I expected from the term "Open Source SSL Acceleration."

Anonymous Coward recommends: (0)

Anonymous Coward | more than 5 years ago | (#27615211)

If you want to improve raw SSL performance, you can use a specialised SSL card. I had the opportunity to play with a card made by the company Dajeil ( http://www.dajeil.com/ [dajeil.com] ). They accelerate RSA, docs say it does "1,500 2048-bit (or 11,000 1024-bit)" RSA TPS. I tested it and the numbers were not inflated. I don't remember exactly how many 512-bit TPS it had but it was probably above 50kTPS. I tested it in a regular Dell desktop, I'm not even sure the CPU had more than one core. They provide a modified openssl library so it works fine with linux. It's been almost 2 years since I had it so maybe they use the newer openssl engine interface (I had problems getting it working with apps that were compiled against a different version of openssl). With a working openssl library, anything that is dynamically linked against it is automagically accelerated, which includes apache's mod_ssl and I assume nginx too.

As far as I remember it cost less than 2k EUR, which is next to nothing for that kind of performance.

Original article was a lame fanboy piece (0)

Anonymous Coward | more than 5 years ago | (#27615713)

[ I'm no f5 fan but they're right.. reposting my comment from the last thread: ]
Hmm, why no mention of nginx's thread limitations? By design, nginx does not use threads and as a result has performance issues scaling beyond one CPU or core. Those limitations will become apparent on certain real world workloads and with realistic tests. Those are important issues and this piece, like many nginx discussions, glosses over them. It also disingenuously tries to compare nginx to commercial solutions.

I like nginx a *lot* and have tested and deployed it in many different situations. But it is not always the best choice, and in some cases is a poor choice.

When I rolled out some new nginx services 6 months ago, nginx was only being developed by one person. Again, not a showstopper for everyone but it would be for some.. and Very worth mentioning in an article that compares nginx to commercial solutions. Nginx is great at some things but it is still maturing.

aSSL anyone? (1)

cybernytrix (1238764) | more than 5 years ago | (#27616603)

Why even bother with SSL? If your main audience is the web crowd, you can simply use something like aSSL [http://assl.sullof.com/]. Then transfer statically encrypted content via http. This does work for most but not all. I know I'll get flamed to death, but I just filed for a patent that addresses the Achilles heal of aSSL - man-in-the-middle attacks.

Re:aSSL anyone? (0)

Anonymous Coward | more than 5 years ago | (#27616953)

Encryption with javascript on the browser just sounds wrong. SSL provides encryption of the data and Verification of the Host. More than just MITM, dns poisoning/ pharming would be easier as well.

Re:aSSL anyone? (1)

cybernytrix (1238764) | more than 5 years ago | (#27617263)

Yes, but there are ways to get around all these problems and still be able to do it! The idea is to use a combination of HTTPS and HTTP wisely so that AJAX requests can be done without the HTTPS overhead. HTTPS is only used once during login.

Re:aSSL anyone? (0)

Anonymous Coward | more than 5 years ago | (#27621941)

and leak personal info
no thanx

Right tool for the job^H^H^H company (2, Insightful)

neurovish (315867) | more than 5 years ago | (#27616641)

If a site is big enough that it really needs the performance/scale of such an F5 appliance, then the price tag is not that great and likely reflects .001% of the IT budget or less. Some shops will be better served with the cheap OSS solutions, and others would blow one up fairly quickly. If you blow it up fairly quickly and the $50k price tag is also hard to justify, then your cost of doing business is severely out of whack.

Re:Right tool for the job^H^H^H company (0)

Anonymous Coward | more than 5 years ago | (#27619621)

If a site is big enough that it really needs the performance/scale of such an F5 appliance, then the price tag is not that great and likely reflects .001% of the IT budget or less. Some shops will be better served with the cheap OSS solutions, and others would blow one up fairly quickly. If you blow it up fairly quickly and the $50k price tag is also hard to justify, then your cost of doing business is severely out of whack.

So to purchase this $50,000 item it will only be 0.001% of your budget.

$50,000 / 0.00001 = 5000000000.0

= $ 5,000,000,000

So the IT budget of companies that buy this is $5 billion.

Marketing barrage (2, Insightful)

jlmale0 (1087135) | more than 5 years ago | (#27616801)

Simply enough, they're firing back because with the popularity of slashdot, now every time some manager goes to scope out Big-IP or their 6900 the slashdot discussion and the original project will rise to the top of the search results.

Big IP isn't worried about this home grown solution, because in the end, businesses buy warranties, maintenance and upgrade paths. Something the FOSS solution doesn't have prepackaged.

Enjoy o3's article; it's a great project. Have fun building it, but don't take offense at Big-IPs defense of their product; they're obligated.

The best thing to take away from all this, if you're in the market for SSL offloading, is to print out the article and slashdot discussion, pass it to the check-writer and let her use it as leverage to get an additional 5% savings off list.

is it just me (0)

Anonymous Coward | more than 5 years ago | (#27617981)

is it just me or does this post sound like a bunch of corporate QQing?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...