Deploying WebSphere with BIG-IP LTM as the web tier

Managing enterprise web architectures has meant three tier environments for more than a decade.  We deploy our databases, we deploy our web application servers (WebSphere, WebLogic, Tomcat, etc), and we deploy our web tier (Apache, IBM HTTP servers, etc).  We pack the whole thing in a firewall sandwich and then we throw a couple of load balancers in front of the web tier. It’s now fast, secure and available.  But how fast and available is it really?

Pictured above, your typical three-tier web application environment.

While this architecture works pretty well, it certainly has some problems which we’ve all come to live with over the years.  The biggest issue is that we are losing a lot of visibility with our BIG-IPs in front of the web tier.  The BIG-IPs are monitoring the web servers, which is okay, but what about what’s going on at the application tier?  We also have to deal with a bunch of web servers, maintaining their OS and the web server software.

Erase the web tier

We have had some proposed solutions on F5 Networks’s DevCentral about replacing the web tier with an iRule and giving greater visibility and our IBM team, with the help of Project Management Engineering we went ahead and tested, revamped and documented the iRule in a full deployment guide. The result of this is the "Deploying BIG-IP LTM with WebSphere 8 deployment guide.” In this guide, we show how you can map your application contexts within the iRule and essentially make BIG-IP your web tier.

 

Pictured above, a whiteboard showing the removal of the HTTP layer.

How does it work?

The details are spelled out in the deployment guide but in a nutshell the steps are as follows:

• Gather the application contexts (URIs) associated with each of your WebSphere applications,
• Gather the port numbers or IP addresses associated with the applications,
• Setup pools for your applications on BIG-IP bases on the port number and IP addresses,
• Modify the iRule to allow BIG-IP to make pool selections based on the application context.

That’s about all it takes. The benefits and tradeoffs are numerous. On the downside, administrators have to get used to entering the mapping into the iRule.  This is fairly straightforward but definitely has a small learning curve (this will certainly be addressed in an iApp in the near future).  On the upside, we have reduced the complexity of the environment, increased security through the use of BIG-IP as a firewall, given better visibility (health monitoring) of the WebSphere application servers, reduced operational expenses of maintaining OSes and Apache servers, reduced capital expenses and given better scalability.

We’ve had good feedback on this deployment guide and I hope to hear your experiences as well.