My wife has somewhat normal ideas of fun. She reads the latest Twilight novel, watches “The Biggest Loser” (OK, so do I), hanging out with friends and enjoys teasing me when I deserve it. You know, the normal things.
Me? I have fun too. Although lately my fun comes from fooling around with the a couple of bad-ass BIG-IP boxes from F5 Networks.
Traditionally thought of as load-balancing devices, these new F5’s can do a lot more. In addition to the load-balancing functionality, my team will be using them to enhance server/application performance and to bring better security controls on to the network. They’ll eventually be sitting in front of Internet-facing servers in a DMZ environment and will proxy all of the inbound/outbound connections to and from the DMZ.
Physically, the installation is pretty simple and straightforward. Two uplink switches sit in front of the two BIP-IP’s while two back-end switches sit behind them. Each switch has a gig link to each one of the F5’s. We also have a direct gig connection between the two F5’s, although it doesn’t seem like it’s used for anything (for some reason F5 doesn’t recommend using this connection for the high availability failover feature).
All of the DMZ servers are plugged into the back-end switches, and not plugged into the F5’s directly. This allows one of the F5’s to be taken down or lost and still have full server availability in the DMZ. For further redundancy,the server pools are divided between the back-end switches. Half the servers for each application in production are connected to one switch, and the other half of the servers are connected to the other.
There are a few apps that only run on a single server, so with this design those apps will have a single point of failure on the network. This is unfortunate, but my group has very little influence on server architecture with the client.
One interesting (and surprising) note – the load-balancing devices don’t load balance between themselves! Instead, they run in an active/passive mode, where one F5 is simply lurking in the background waiting for the other to fail. Maybe other F5 models handle this differently – I must admit I don’t know enough about the product line to be sure.
More on the F5’s later, where I’ll go further into the features and give some insights into how they’re configured.
Jason
{ 3 trackbacks }
{ 3 comments… read them below or add one }
IMO, applications delivery architecture & application availability would benefit greatly if only network folks & application folks talked more! Btw, the reason that load balancers don’t load balance themselves is that they behave more like clustered devices. You’ll find similar capabilities & behaviors on products like Cisco ACE and Citrix Netscaler.
Hi AppGirl, thanks for the clarification about the load balancers – I’ve got a lot to learn in this area
.
I absolutely agree with you on the communications angle. I suffer from it every day at my current client. The Networking group here is very rarely asked to comment on application architecture in the planning stages – it’s only after an app reaches QA that they realize there are often some issues interfacing with the network. We then are forced to try to fit a square peg in a round hole and make it all work. On the other hand, our Networking group doesn’t exactly reach out to the app folks when we’re selecting/implementing networking hardware (like these F5’s).
Love you site, btw. The tag cloud in your header is awesome.
Thanks for checking out my site Jason! Looking forward to seeing more postings from you on your experience.