Enabling the Dynamic Data Center with BIG-IP v10

OreoDefense BIG-IP v10 is a breakthrough in the Application Delivery Networking (ADN) for many reasons, all of which revolve around understanding how applications are delivered outside the data center to users and services (ie context). Contextual awareness is a cornerstone to Unified Application Delivery and Data Services (UADDS) – delivering applications in out of your data center, your hosted environment, your cloud, in a manageable and predictable manner. One of the revolutionary UADDS features in BIG-IP v10 is Inband Passive Monitors: non-obtrusively monitoring application delivery and making adjustments before there is a problem.

There are (or were at least, until BIG-IP v10) two primary types of application monitors: active and passive. [NOTE: For more details on these types of monitors, check out the whitepaper links at the bottom of this post]. Active monitors are like quality control, taking random samplings of the applications to make sure they’re up and running. Not all applications can tolerate active monitors, however, which can actually jam up the queue on the app server, eventually building up enough to crash the server. In this case, the active monitoring itself can have a detrimental effect on the application server it’s trying to monitor.

Traditional passive monitors are like the people that watch for broken Oreos as they come off the Nabisco assembly line before packaging; if there are too many broken cookies then the line is shut down for repair. F5 pioneered passive monitoring years ago, and for good reason; they serve their purpose and place but they can’t fix the problem while it’s occurring. Passive monitors alone only see the Oreos after they’re all smashed up and lost, not before when they’re still beautifully round cream-filled mini-sandwiches or during production as they’re being crushed...or more importantly, if there are no Oreos on the line at all.

So what’s the solution? Inband Passive Monitoring and iRules. Combine the best of both types of monitors and create a monitor that:

  1. Transparently monitors application services at the network level, and
  2. Can insert a remediation immediately at the application level when a problem is detected

Let’s look at an example:

  • You’re running a Sharepoint service behind a VIP with 100 Sharepoint nodes, with an Inband Passive Monitor specific to Sharepoint attached to each node. The failure threshold is set to 10 failures/minute (more on that below).
  • The service appears to be up and running at the network level because it is accepting connection requests and returning connection responses
  • Using an iRule, BIG-IP detects that Node #39 has started returning “503 Service Unavailable” HTTP responses, yet the rest of the nodes are fine. But node #39 is only doing this about once every few minutes. BIG-IP is configured to resend the request when this happens rather than passing the 503 onto the user. So far the re-requests are working fine, returning happy “200” responses on the 2nd pass.
  • As traffic increases so does the rate at which Node #39 is returning 503s, unfortunately; something isn’t right. As soon as #39 exceeds 10 503 failures/minute, BIG-IP's active monitoring system (a combination of iRules and Inband Passive Monitors) takes over and does a few things:
    1. Takes #39 out of rotation (the node pool) so no new requests will be sent to the dying #39.
    2. Invokes an active monitor on #39 to determine if the problem is consistent, even if no active monitor has previously been attached to this service – an autonomous monitor as it were. The active monitor will continue to test #39 out-of-band based on a threshold configured by the administrator. If #39 shapes up during that threshold the Inband Passive Monitor will return #39 to the assembly line with a pat on the head, all trouble forgotten. If, however, #39 fails to shape up, it’s time to ship it out. The node is marked down for good, the administrator is notified, and the Inband Passive Monitor assumes that #39 is headed off to the application server farm in the sky.
    3. The Inband Passive Monitor will continue to monitor the “location” where node #39 used to live, and once it sees that there’s a new #39 it will make sure that it’s working correctly before adding it back into the active pool of nodes. Slick.

As you can see form this example, the Sharepoint application service associated with the BIG-IP v10 VIP never experiences an interruption. The few requests that would have traditionally received a “503 Service Unavailable” error were never the wiser since BIG-IP proxied that failed response and re-requested the service on behalf of the requestor. And the one faulty node was detected without actually engaging the node until the faults exceeded the administrative threshold.

This is just the tip of the iceberg. You can read (and listen!) more about Inband Passive Monitors in the whitepaper or via the F5 OnDemand Audio Whitepaper version, your choice. Either way, you’ll find more details about why BIG-IP v10 is helping you to revolutionize contextual application delivery in your dynamic data center.