![]()
The biggest toughest fish in the sea…and load-balancer on earth…
Might as well call it CryptoFish…
Up until this point, we've never had the pleasure of using SLB-based SSL-offload. We've just trudged along…scaling the ol' SSL proxies along with the app servers. While cost-effective, the customer doesn't get Speedy Gonzales latencies, and the number of moving parts goes up. As you might guess from yesterday's entry, a main design goal for us is reducing moving parts. DigiTar believes y'all can't break stuff that doesn't exist. Needless to say, moving to SSL-offload in our load-balancers is something we're pretty keen on. Among other things, we'll be able re-purpose all those beefy SSL proxy servers for other things…like space heaters.
Enter today's first chore…migrate the HTTP SLB VIP to an HTTPS config leveraging the SSL-offload capabilities of the SunFish. While we've never configured SSL-offload before, given this review on the Alteon 2424-SSL, I was prepped for beastly day. In case you don't want to read the link, on a 2424-SSL, you're looking at a configuration task that involves redirection and 3 sets of filters on 3 different VLANs. This is all to get the traffic to and from the SSL card…which is more of a suckerfish (yeah the ones that feed on sharks) than a real part of the box.
![]()
An Alteon 2424 with its SSL card in tow…
So what's all this leading up to? We had SSL up on the SunFish in about 5 minutes! That's right, four clicks of the mouse and bang I was done. What's more…it worked! The hardest part was trying to pull the proxies' key and cert out of the Subversion repository. Here's the 4 steps to converting an existing SunFish HTTP SLB group to utilize SSL-offload goodness:
Its that easy. No redirection filters. No funky hidden VLANs. No nothin'…no kidding. There was so much time left-over, I spent 20 minutes figuring out how to do on-the-fly HTTP header modification…which also worked perfectly. The SunFish is so easy to use for crypto, its purchase price is probably justified by what we'll save doing things other than configuring Apache SSL proxies. If the 2424 wasn't dead on our purchase list by now, this was certainly a double-tap to its mainboard.
You need GigE?
Well we tried to setup redundancy…but the effort was a bit stillborn. One of the only complaints I've got about the physical aspects of the SunFish is that all of its ports are SFPs. As a result, to use RJ-45 cables you have to use GigE copper SFPs (which David C was very generous to provide). The problem is that an SFP has no concept of 10/100/1000. Its designed to be a gig optical port. As a result, we're pretty limited in our dev server room as to what we can hook it up to. In terms of the test, the X4100s are directly connected (they've got GigE ports), and the “Internet” port goes to a GigE-capable firewall we use. Yeah…I know. Its weird. We have a GigE firewall but no GigE switches in our dev lab. Alas, that means we can't test the redundancy…but that doesn't mean I can't pontificate about it.
The SunFish definitely has Alteon-rising when it comes to redundancy. No elegant custom protocol that binds two units as one. Rather, they use VRRP to tie the interfaces of redundant SunFish together, and an unnatural progeny of VRRP they call VSRP to handle failover of SLB virtual services between units. All-in-all darn identical to the Alteon…almost.
Like the Alteon, VRRP has to be set up separately on each interface you want failover for. That's a royal pain in the keester. However, VSRP is a little different, and lot better than the Alteon's way of hacking VRRP to handle virtual service failover. With the Alteon you have to configure a VRRP instance for each SLB virtual service…just like the interfaces. When you're running close to 15 virtual services per web switch, this is beyond a royal pain. Its excruciating. Rube Goldberg could design a better way.
The SunFish does it much better. You just turn VSRP on. Yes…that's just about it. Of course, you have to set which unit in a pair is the master and which is the backup…but that's all you're required to do. No matter how many virtual services across a disparate number of vSwitches might catch your fancy, you only have one VSRP instance to enable per web switch. For us that's incredible! As much as I would prefer a custom protocol that makes the entire process transparent, I'll take a SunFish thank you very much.
Feelings thus far…
So far I've been incredibly impressed by the SunFish. It is by far the most robust and powerful web switch a kid with a shiny nickel can buy (OK…500,000 shiny nickels)…without buying its big brother. There isn't one thing so far that wouldn't allow the SunFish to surpass our needs in the following areas:
The one area I can't really stress enough is the amount of flexibility the SunFish will give us. The raw power combined with the virtualization capabilities will only increase our ability to deliver mind-blowing solutions to our customers (and keep the price lower than our competitors). Now the task is to put these boxes into a more production environment. More on this soon.
P.S.
We still want our AlteonEMS for SunFish! This would make the SunFish far and above the best web switch period. Yeah F5 may have its iRules…but you put a few of those on one of their boxes and the gear keels over. To meet our needs with F5 gear we'd need to buy enough to finance a fleet of Ferraris. SunFish or Alteons baby. Power over looks.
Leave a reply