Monitoring/Management

Cloud Computing: What's stopping service-oriented clouds?

Lori MacVittie — Wed, 12 Nov 2008 16:52:03 GMT

Whenever there is a shift in architectural thinking about technology, such as is happening right now with cloud computing and virtualization, we start thinking forward, past the now, and into the future about how that technology might be leveraged. We start looking at the impact to architecture from the top of the stack to the bottom. For a company that's focused on application delivery, that means taking a good hard look at how that new technology might impact the architecture of applications.

It's been suggested that perhaps, just maybe, we'll see service-oriented clouds; that the concepts of SOA (service oriented architecture) might be abstracted even further and moved into the cloud. Basically, it's like ripping apart the n-tiered application architecture we've been building on for years and spinning each tier into the cloud; database there, presentation layer here, middleware layer over there. And not just in one place, either, but rather duplicating these "services" to provide failover, availability assurance, and context-aware access that takes into consideration variables like location and response time.

That would certainly be more efficient than current architectures which deploy entire applications as virtual images or packages in the cloud. If the database tier needs more compute resources, then just the database tier expands, rather than the entire application. That's the principle of SOA at work, as well. Decompose business processes and applications into their composite services and deploy. If one service is heavily reused, you can replicate and load balance just that service, not the entire application.

But applying SOA to the cloud may be more difficult than it sounds. While there are often discrete tiers of architecture within an application, even within a SOA-based architecture, it is still somewhat difficult to envision deploying those tiers across multiple clouds. Application infrastructure is certainly just as capable of communicating across the Internet as it is a local network, so the problem isn't so much with technology and its capabilities as it is with actually managing such a dispersed and distributed application infrastructure.

Troubleshooting such an architecture would certainly be problematic. Trying to recreate an issues for troubleshooting has always required replicating the environment as closely as possible, and it may be exceedingly difficult to even get that information in a service-oriented cloud architecture. Which data center, which database instance, which front end, which network? The variables become as overwhelming to manage as calculus appears to a third grade math student.

Further complicating the potential deployment of databases, specifically, into the cloud is the integral web of applications and systems reliant on those databases for day to day operations - both IT and business focused. Data mining, business activity monitoring, business process management, supply chain, and ERP systems are often all tied into databases around the enterprise. Move any single database and you become mired in a dependency chain that is serial, not parallel, in nature with the database being the foremost link in the chain. Access or availability to that database can bring applications - and the business - to a screeching halt.

It's that kind of risk rather than the traditional security risks and concerns surrounding offsite data storage that needs to be addressed before critical infrastructure like databases can be decoupled from the internal control that exists in the local data center. SOA addresses the architectural coupling of data and logic to applications, but it cannot adequately address at this time the need to have tightly coupled control over the availability of that data.

Applying the principles of SOA to the enterprise and the cloud can indeed have benefits in terms of reduced infrastructure costs and the ability to scale on-demand, but it still can't address the vulnerabilities inherently present from our reliance on data.

Data is the lifeblood of an organization. Applications, like the heart, keep that data pumping through the complex network of veins and arteries that are the corporate and Internet infrastructure. But like human beings even though the heart and some of the infrastructure can be outsourced, without blood (data), everything else is irrelevant.

Given our dependency on data and its availability, it's unlikely we'll see fully service-oriented clouds in the ether anytime soon. Not until we have the same guarantees of availability and access and ultimately, control, that we have in the local data center.

Technorati Tags: MacVittie,F5,cloud computing infrastructure,cloud computing,infrastructure,architecture,SOA,services,database,internet,network,application delivery,blog

Virtual Server Sprawl: FUD or FACT?

Lori MacVittie — Wed, 01 Oct 2008 10:43:49 GMT

At Interop this week, security experts have begun sounding the drum regarding the security risks of virtualization and reminding us that virtual server sprawl magnifies that risk because, well, there are more virtual servers to manage at risk.

Virtual sprawl isn't defined by numbers; it's defined as the proliferation of virtual machines without adequate IT control, [David] Lynch said.

That's good, because the numbers as often cited just don't add up. A NetworkWorld article in December 2007 cited two different sets of numbers from Forrester Research on the implementation of virtualization in surveyed organizations.

First we are told that:

IT departments already using virtualization have virtualized 24% of servers, and that number is expected to grow to 45% by 2009.

And later in the article we are told:

The latest report finds that 37% of IT departments have virtualized servers already, and another 13% plan to do so by July 2008. An additional 15% think they will virtualize x86 servers by 2009.

It's not clear where the first data point is coming from, but it appears to come from a Forrester Research survey cited in the first paragraph while the latter data set appears to come from the same recent study. The Big Hairy Question is: how many virtual servers does that mean?

This sounds a lot like the great BPM (Business Process Management) scare of 2005 when it was predicted that business users would be creating SOA-based composite applications willy nilly using BPM tools because it required no development skills, just a really good mouse finger with which you could drag and drop web services to create your own customized application.

Didn't happen. Or if it did, it happened in development and test and local environments and never made it to the all important production environment, where IT generally maintains strict control. Every time you hear virtual server sprawl mentioned it goes something like this: "When your users figure out how easy it is..."

"Users", whether IT or business, are not launching virtual servers in production in the data center. If they are, then an organization has bigger concerns on their hands than the issue of sprawl. Are they launching virtual servers on their desktop? Might be. On a test or development machine? Probably. In production? Not likely. And that's where management and capacity issues matter; that's where the bottom line is potentially impacted from a technological black plague like virtual server sprawl; that's where the biggest security and management risks associated with virtualization are going to show themselves.

None of the research cited ever discusses the number of virtual servers running, just the number of organizations in which virtualization has been implemented. That could mean 1 or 10 or 100 virtual servers. We just don't know because no one has real numbers to back it up; nothing but limited anecdotal evidence has been presented to indicate that there is a problem with virtual server sprawl.

I see problems with virtualization. I see the potential for virtualizing solutions that shouldn't be virtualized for myriad reasons. I see the potential problems inherent in virtualizing everything from the desktop to the data center. But I don't see virtual server sprawl as the Big Hairy Monster hiding under the virtual bed.

So as much as I'd like to jump on the virtual sprawl bandwagon and make scary faces in your general direction about the dangers that lie within the virtual world - because many of them are very real and you do need to be aware of them - there just doesn't seem to be any real data to back up the claim that virtual sprawl is - or will become - a problem.

Technorati Tags: MacVittie,F5,virtual server sprawl,server sprawl,virtualization,consolidation,security,capacity,management,Interop,NetworkWorld

Load Balancing: Welcome to the 21st Century

Lori MacVittie — Wed, 11 Jun 2008 12:12:19 GMT

Kevin Saitta, a solution consultant, has a nice blog post on architecting a Microsoft BizTalk 2006 R2 solution. Unfortunately, amidst the goodness, is a statement regarding load balancers that needs to be corrected. Kevin is not alone in his beliefs regarding load balancers, unfortunately, I've seen a lot of posts lately that seem to indicate that folks out there still have a circa 1999 knowledge set regarding the capabilities of load balancers.

Kevin writes

Load Balancer
A load balancer balances the load between servers, but more importantly, if one server goes down, the load balancer sends all requests to the server(s) left running. An example of hardware load balancing is BIG-IP from F5 Networks. An example of software load balancing is the Network Load Balancing Service included in Windows.

NOTE: Load balancers only understand server level availability and have no understanding of the application that run on the servers. This means that if the application is unavailable the load balancer will still deliver request to the server, hence the need for a monitoring solution as SCOM.

It is the "NOTE" that needs to be addressed, especially given the reference to BIG-IP, which is absolutely capable of understanding applications that run on the servers and, in fact, does understand the applications and their protocols and is capable of optimizing, accelerating, and securing those applications.

BIG-IP is capable of recognizing the difference between the server being available, and the application being available and has the ability to understand when the application is serving the right content or not. BIG-IP can even dig into the payload, the application messages, and apply policies based on the application-specific nuggets of information, rather than just HTTP headers or even application(HTTP)/transport layer (TCP) protocols. Add in iRules and BIG-IP becomes an application delivery platform: extensible, dynamic, and extremely intelligent.

The problem is that load balancers aren't just load balancers any more. They have evolved into application delivery controllers, and are capable of much more intelligence and integration with the applications they are tasked to deliver and are just as capable of intelligent monitoring of applications to ensure they are actually available.

Kevin's assertion that a load balancer will deliver requests to the server even if it's down is wrong, at least in the case of BIG-IP. While Windows NLB is certainly incapable of this particular functionality (it's called network load balancing for a reason), application delivery controllers like BIG-IP and its competitors are capable of intelligent monitoring, dynamic routing, and recognizing when an application is no longer available or responding correctly.

As Deb pointed out in response to a previous post, there are plenty of examples and samples for BIG-IP which illustrate the powerful, flexible, application aware monitoring capabilities of BIG-IP.

To be fair to Kevin, who wrote a really informative and interesting post, this is not the first blog or forum post I've seen in the last two weeks that improperly tags modern load balancers as "dumb" network devices incapable of understanding application layer protocols and messages. There's a perception - and a wrong one at that- that load balancers are still just simple layer 4 devices that add very little value to the network or application architecture.

As it's part of my job to educate folks on topics like this, I guess I'm not doing very well, am I? I'll get to work on that, pronto, after my upcoming mini-vacation.

For starters I'd like to say to everyone out there interested in load balancing: welcome to the 21st century, where application delivery controllers have replaced load balancers, and where intelligent, application aware devices are capable of much, much more than their predecessors.

Stay tuned, there's much, much more to come.

Imbibing: Coffee

Technorati Tags: MacVittie,F5,BIG-IP,load balancing,application aware,monitoring,iRules,application delivery

Top 3 Lessons We Can Learn from Amazon's Outage

Lori MacVittie — Tue, 10 Jun 2008 12:50:11 GMT

Everyone's now familiar with last week's Amazon outage, it's been all over the web. Amazon is still not detailing what went wrong, but lots of folks are speculating on the reasons for the failure. Alistair Croll over at gigaom had a nice recap of the recent Amazon outage, including a list of facts and what we can deduce them, and the rumor mill is, of course, churning away with fantastic stories of what went wrong.

Rather than add to the speculation on the reasons behind Amazon's outage - because we may never know the truth - it's a good time to look at the outage from the perspective of what lessons we can learn about application delivery and building a resilient web architecture.

3. Implement GSLB (Global Server Load Balancing)

In the fact of disaster - natural or otherwise - a secondary data center physically separated from the main data center can be used to enable business continuity as well as disaster recovery. Using a global server load balancer, if the primary data center is down - regardless of the reasons - requests can be automatically directed to a second data center until the primary returns to service. This results in less disruption of service to customers and remote employees alike.

2. Configure "Apology" pages

Apology pages are simply content displayed when no servers can be reached. Apology pages are similar to "maintenance" pages often displayed when a site is unavailable due to maintenance, upgrades, or problems. The ability to display apology or maintenance pages is available in all major load balancers (application delivery controllers) today and are fully configurable. The pages need not even be "real" pages, as most application delivery controllers are capable of returning content directly.

1. Use intelligent health checks (a.k.a. Advanced health monitoring)

All load balancers are capable of "health checks" on servers. This is basic feature that uses ICMP or a TCP connection to verify that a server in the pool (farm) is available. The problem with basic health checks is that they only verify network connectivity (ICMP) or transport layer connectivity (TCP) or, if you're lucky, application layer connectivity (HTTP).

What's really necessary is to be able to not only verify that the server is reachable, available, and responding but that it is also responding with the appropriate content. Just because a web servers returns a 200 OK status does not mean the content is correct. It's quite possible that one or more dependent services responded incorrectly, leaving the page with "most of its content" but potentially with errors embedded. This is often the case with data-driven web sites, where SQL errors are not properly caught and end up returning errors inside otherwise appropriate content.

Advanced health monitoring in application delivery controllers provides organizations with the means by which both servers and applications can be verified as being "available". By not only verifying IP and TCP availability, organizations can ensure that should an "HTTP 1.1" message be returned by a server that the application delivery controller can (1) detect the problem and (2) remove the affected server from the pool of available servers. If enough of the servers are responding incorrectly, the application delivery controller would discover that no servers are available and then respond with an "apology page".

"Load balancing" has come a long way, baby, since the days of simple round-robin DNS. It has evolved into application delivery, and the products providing application delivery services are no longer dumb endpoints on the network, they're sophisticated, intelligent devices capable of not only providing basic load balancing services, but augmenting the entire application delivery process by ensuring that applications are always available through intelligence and advanced feature sets.

Application delivery controllers aren't your daddy's load balancers, so take advantage of capabilities like advanced health monitoring and dynamic server selection to build a resilient, failsafe architecture that responds to your customers no matter what might be going on behind the data center doors.

Imbibing: Coffee

Resources on BIG-IP and its advanced health checking capabilities:

Technorati Tags: MacVittie,F5,BIG-IP,application delivery,load balancing,health checking,apology page,availability

iControl and Web 2.0

Lori MacVittie — Tue, 13 May 2008 12:05:01 GMT

There's a lot of things that BIG-IP can do to improve the reliability, scalability, and performance of Web 2.0 applications. But there are always two sides to every story, and so it is with BIG-IP and Web 2.0, or specifically, AJAX.

This latest article, Getting Started with iControl and AJAX, offers advice and code to get you started building a custom AJAX-based dashboard for BIG-IP.

Imbibing: Coffee

Technorati Tags: MacVittie,development,iControl,BIG-IP,F5,AJAX,Web 2.0

A Virtual Challenge

Lori MacVittie — Tue, 06 May 2008 13:38:26 GMT

According to a recent CIO article and survey data, the top challenge to virtualization success today is balancing server workloads and maintaining application service levels. That makes sense; if you're going to create 3 or 4 or 99 virtual servers you need to be sure that the workload isn't going to suck dry the resources available on any particular machine. And, too, you'll probably need some solution to load balance those applications across virtual instances.

That part, at least, seems easy: get thee a load balancer, pronto. Turns out that the concern regarding balancing server workloads is more complex than most likely realize. A load balancer will, in fact, distribute server workloads across virtual instances. It likely won't, however, do so in an intelligent way and it almost certainly won't do much to ensure that service levels are maintained.

Top Challenges to Virtualization Success

Balancing server workloads and maintaining application service levels	64%
IT organization politics	37%
Measuring ROI	30%
Governance	24%
Pushback from business leaders	20%
Revamping chargeback systems for the business	20%
None of the above/not applicable	11%

(Respondents chose up to three)

SOURCE: CIO research

Application delivery will, however, address both those challenges in an easy, consolidated, green, efficient (have I hit all the buzzwords yet?) and flexible way. Seriously, an application delivery fabric is the best way to address this type of challenge and it does provide all benefits in one way or another.

You see, an intelligent application delivery controller understands the load on the server and can decide - in real-time - whether any given request should go to one server or another based on that understanding. So if Virtual Server A on Real Server 1 super busy at the moment, an application delivery controller can send the request to Virtual Server B , instead. Virtual Server B might be on Real Server 1, or it might be on Real Server 2. It really doesn't matter, unless you want to start factoring in both the current application performance within a virtual server AND the resources available on the real server. Regardless of what factors you want to consider, an intelligent application delivery controller can take them into consideration and balance server workload across instances in a way that maintains application service levels.

Want to take it further? Do you want to automatically provision those servers to get the most out of your resources? Consider an application delivery network that can integrate with popular virtualization technology like VMWare. Such integration takes solves the problem of balancing server workload by dynamically increasing or decreasing the available server instances in real-time, according to current network, server, and user conditions.

So if you're struggling with balancing the load across servers - virtual or not - check out an application delivery network so you can move on to the next challenge: IT organizational politics.

Sorry, I wouldn't touch that one with a 10 foot patch cable.

Imbibing: Coffee

Technorati tags: MacVittie, F5, application delivery, virtualization, load balancing, service level agreements

KPiRules

Lori MacVittie — Fri, 13 Jul 2007 16:36:08 GMT

KPI (Key Performance Indicators) are quantifiable metrics that can be measured against organizational goals. KPIs vary from business to business, based on what the company does. If it's a sales oriented company, a KPI might be something like "increase sales by X% year over year"; if it's a retail company it might be both "increase sales" and "increase customer retention". The key is that a KPI must be measurable in some way. That's why most KPIs are directly related to revenue, customer retention/churn, and other quantifiable aspects of doing business.

Aggregating this measurable data is generally the responsibility of BI (Business Intelligence) suites. These products aggregate and assemble massive amounts of data, usually on a weekly or monthly basis, into a form that analysts can use to determine whether the company is on track to meeting its goals. These forms are often OLAP cubes and require lengthy processing to assemble, so they're usually only created on a weekly or nightly basis.

But what if you wanted something a bit more "real time"? Maybe you wanted to know on an hourly basis how sales was doing so you weren't surprised when you finally got the weekly or daily update.

If you've got a BIG-IP (v9.2+) and it's part of the infrastructure managing transactions, you're in luck. Using iRules and custom statistics profiles you can collect that data in real-time so you can satisfy your curiosity any time of the day or week.

What You Need

First you'll need a custom statistics profile so you have a place to store the data as it's collected. Joe's got a great article on how to create a custom statistics profile and walks through the steps required to assign it to the appropriate virtual server.

As an example, I created a custom statistics profile with two custom fields: total_value and orders. After saving it, I then assigned it to a virtual server. Use the Advanced settings to find the "Statistics Profile" drop-down associated with your virtual server, and choose your newly created custom profile.

The last step is to create an iRule that extracts the data you're interested in and stores it in your custom statistics profile. You might also add a few additional processing-oriented rules within the iRule to handle resetting the statistics as well as displaying the statistics.

Basically, we're creating a KPIService with a REST style interface. By default, the rule will extract the appropriate data and update the statistics profile, but by directly invoking a specific URI, e.g. /statistics/display, /statistics/reset, you can create a service that provides some amount of control over your custom profile.

The iRule

The following iRule is not optimized and it's rather simplistic in its nature, but it does present the basic concept of extracting specific data from transactions and storing them in a custom profile for retrieval whenever you desire. If you were really ambitious, you could output the statistics in XML or CSV and import them right into something like Microsoft Excel so you could view the data over time.

when HTTP_REQUEST {
set PROFILE_NAME "MyKPIStats" 
set t [STATS::get $PROFILE_NAME "total_value"]
set o [STATS::get $PROFILE_NAME "orders"] 
set uri [HTTP::uri]

set FIELD_NAME "totalvalue"

if {$uri starts_with "/statistics/display"} {
   HTTP::respond 200 content "<format your data how you like, with fields placed where appropriate>"

} 
else if {$uri starts_with "/statistics/reset"} {
    STATS::set $PROFILE_NAME "total_value" 0
    STATS::set $PROFILE_NAME "orders" 0

    HTTP::respond 200 content "Statistics have been reset"

} else {

   set postvalues [split [HTTP::payload] "&"]
   foreach p $postvalues {
      set pval [split $p "="]

      if {[lindex $pval 0] eq $FIELD_NAME} {      
         set newtotal [expr [lindex $pval 1] + $t]

      }
   }
   STATS::set $PROFILE_NAME "total_value" $newtotal

   // This piece of the profile counts the number of orders we've received 
   set neworders [expr $o + 1]
   STATS::set $PROFILE_NAME "orders" $neworders

}

KPIs aren't the only thing you could capture with custom profiles - you could measure a lot of customer-oriented actions as well, such as the number of users who loaded the "checkout" page and how many loaded the "final_checkout" page, as a real time view of abandonment rates. While iRules aren't meant to - and won't - take the place of business intelligence suites, they can provide some interesting real-time visibility into your business without requiring modification to existing applications or the purchase of additional software.

Imbibing: Coffee

Technorati tags: iRule, F5, MacVittie, business rules, SOA, application delivery

Syndicate your BIG-IP

Lori MacVittie — Thu, 22 Mar 2007 22:04:41 GMT

Enhancing visibility through iRules and RSS

The business folks in your organization like to have visibility into every aspect of the business, including the disparate pieces of infrastructure that deliver the applications crucial to the company's bottom line. There are a number of ways in which you can provide visiblity into the delivery of those applications via BIG-IP.

Yes, you could export logs and create charts in Excel, but that's not very real-time. You could also use the administrative domain features in v9.4 to give business owners view-only access to your BIG-IP so they can view the statistics themselves.

Another possibility (and much cooler in my opinion) is to provide an RSS feed via an iRule. Yes, I'm saying you can syndicate the performance of your BIG-IP. This provides an easy mechanism through which business and management stakeholders can monitor the performance and delivery statistics of their mission critical applications without you generating reports or requiring the stakeholders to bother IT for their credentials yet again.

How to Set up an RSS Feed for your BIG-IP

First, find an appropriate URI that is unique that can return the RSS feed on your virtual server. For example, I chose "/rss". Then collect the appropriate statistics from the stats profile and craft your RSS response. If you aren't familiar with RSS there are number of sites that provide good examples for the most popular RSS format specifications (0.9, 0.91, 2.0). I like 2.0, but that's a matter of (sometimes hotly debated) opinion.

Here's a simple example of an RSS 2.0 feed:

<?xml version="1.0"?>

  <rss version="2.0">

      <channel>

         <title>BIG-IP Statistics</title>

         <link>http://myvirtualip.com/</link>

         <description>Statistics for My Virtual Server</description>

         <item>

            <title>Current Connections</title>

            <description>12345</description>

         </item>

         <item>

            <title>Total Requests</title>

            <description>456781919</description>

         </item>

      </channel>

   </rss>

You'll of course want to modify the titles, and if you really get crazy RSS 2.0 includes the ability to embed images as well. You can use iRules to gather virtual server specific information such as its name, active members, etc... as well, so you can really customize the heck out of the feed.

You can put whatever statistics you think are relevant from the statistics profile, and just because we like flexibility you can even create custom statistics profiles and report on more application specific statistics. Joe wrote a great tech tip on retreiving statistics from your BIG-IP using iRules that is a great place to start checking out the possibilities. His examples include the ability to reset the statistics, and outputs in HTML, but the concept is the same.

This iRule itself is pretty simple, Joe's includes the ability to process several reporting-specific URIs so you could modify his example to support multiple syndication formats based on the URI.

when HTTP_REQUEST {

   set uri [HTTP::uri]

   if { $uri starts_with "/rss"} {

       # get the statistics you want to report

       HTTP::respond 200 " ** output the RSS format of choice with the statistics ** "

Go on, syndicate your BIG-IP. Your enterprise stakeholders will thank you for it.

Imbibing: Mountain Dew

Technorati tags: F5, BIG-IP, application delivery, XML, Web 2.0, iRules