The Riverbed Blog

Demo of Riverbed's Performance Platform

This short demo covers Riverbed's Cascade, Stingray Traffic Manager, Stingray Aptimizer, Steelhead / Akamai SaaS acceleration, and Whitewater products through the lens of Microsoft SharePoint.

 

Application Delivery Controllers – it’s all about the Application

Yet again, we hear the same tired, old line that a software ADC is somehow “a lower-end solution. It's got all the functionality but it doesn't have the performance”.  In a recent interview, F5 CEO John McAdam went on to assert that software offers “single-digit gigabits-per-second vs. hundreds of gigabits-per-second” for an integrated hardware solution.  This simultaneously flatters F5’s own Virtual Edition (which tops out at 1 Gbps) and overstates the real-world capacity of integrated hardware appliances that depend on hardware fast paths to achieve such performance heights; layer4/7 fast-paths that preclude the use of the sophisticated ADC functionality that is often needed to support the application.

The application and infrastructure experts who take responsibility for the successful deployment and delivery of a business’s applications think differently in term of performance: page views, site visitors, number of customers, transactions per second, and service levels and page load time.  These need to be measured within the context of the specific capabilities of an ADC that are required to deliver the applications effectively.  Performance depends on the efficiency of the ADC software and scales with the CPU capacity of the server or appliance. 

Measuring the value of an ADC solution in terms of gigabits alone is understandable when hardware is your differentiator, but it misses the value of an ADC.  The value that distinguishes an ADC from a network load balancer is realized when it finds it way to the individual who understands the needs of the applications. An ADC is a tool to help deal with unexpected application problems, application security vulnerabilities, flash floods that need smart prioritization, to facilitate routine maintenance, yet so often we hear the same complaint from application owners at organizations where hardware ADCs are incumbent – frustration that the tool that might fix their problem is managed by another team who have very different goals, constraints and SLAs.

Organizational changes alone cannot resolve these difficulties. There will certainly always be a place for the hulking hardware ADC-asaurus, exiled to the edge of the datacentre to perform basic load balancing and routing with little thought, but the more challenging application delivery problems need the flexibility and scale that only an on-tap software solution can offer.

The emerging datacentre infrastructure, whether physical, virtual or cloud, shows two qualities – programmable to the needs of the business services that are delivered, and responsive to the needs of the applications that make up the services.  Insisting that an ADC will always be tied to a piece of tin fails to recognise neither this trend in infrastructure, nor the needs of the new application users of advanced ADC functionality.

We’re proud to find ourselves helping customers to achieve things with their applications that they could not do with our technology.  Software (ADC, web/app server, whatever), in the hands of the application experts, enables quick prototyping, rapid application release cycles, flexible and immediate test environments, and our customers know their investment in our Stingray technology can grow and move with them as their business grows with their success.

Extending Stingray Traffic Manager with TrafficScript

One of my duties as a Channel System Engineer is to update our partners on our new technologies and products. In the recent months after people heard that we acquired two new outstanding technologies, I was often asked why believe that the Zeus ADC now Stingray Traffic Manager is superior to other ADCs on the market.

Of course there are many different correct answers to this question. But for me one of the main reasons is its flexibility, scalability and of course the fact that it is highly customizable, making it a solution that is easy to adapt to all the customer scenarios out there.

For those who might have missed it: Stingray Traffic Manager is a high-availability, application-centric traffic management and load balancing virtual ADC. It provides control, intelligence, security and resilience for all application traffic. Stingray Traffic Manager is intended for organizations hosting valuable business-critical services, such as TCP and UDP-based services like HTTP (web) and media delivery, and XML-based services such as Web Services.

Stingray Traffic Manager’s architecture ensures it can handle large volumes of network traffic efficiently. Its scalability allows you to add more front-end traffic managers or back-end servers as the need arises. The cluster size is unlimited, and the performance of the traffic manager grows in line with the performance of the underlying hardware.

These are all amazing features Stingray TM provides for scalabilty and felxibilty, but today I would like to talk specifically about one of the capabilities of the Stingray Traffic Manager that extends the possibilities mentioned above and makes it highly adaptable beyond what would be achievable with a monolithic approach: TrafficScript.

Using the TrafficScript language you can write tailored traffic management rules to inspect, manage and route requests and responses in every imaginable way.

TrafficScript rules can be executed whenever a new connection or network request is received, and whenever it receives a response from a node. The rules you create inspect the incoming and outgoing data in the connection, and other aspects such as  e.g. the remote client address, destination address and port. You can write rules that can then modify the request or response (for example, rewriting the URL or headers in an HTTP request), set session persistence parameters, or decide how to route the request or even rewrite the content of the output page.

 

 

There are many occasions when you might want to use a TrafficScript rule.:

• You can use a rule to dictate session persistence information

• Rules can be used to check the response from the server and modify it, or even retry the request (if possible) if a transient error was detected.

•  If you use various back-end systems with different presentation styles or even different protocols, rules can be used to integrate them into a single, coherent and consistent service. Incoming requests can be rewritten into the format suitable for the required service, and responses can be rewritten into a single, consistent form.  For example, HTTP requests that involve a database lookup can be rewritten into SOAP request for a Web Service; the XML response can then be transformed into a suitable HTML document to return via HTTP.

• Rules can specify custom behavior for each connection; e.g. connections to a slow resource can be given a longer response time tolerance for example.

• Security:  You can use a rule to check packets for a match with known web worms or viruses.

• Data Protection: you can write rules that ensure that sensitive data like credit card numbers or social security numbers are automatically hidden even if they were to be displayed in the output of a web page by accident.

 

One of the great properties of TrafficScript is that it is easy to learn and understand! Even for people with little coding experience. You don’t have to worry about having to learn an entirely new, complicated scripting language, TrafficScript will look familiar even to the untrained eye.

 

Here are two examples of TrafficScript rules:

 

1) Restricting Access Based on the Time of Day

This example only allows access to a particular service during office hours (between 9am and 6pm, Monday to Friday). It discards all connections that occur outside these times.

$dayofweek = sys.time.weekDay();

$hourofday = sys.time.hour();

# $dayofweek: Sunday is 1, Saturday is 7

# $hourofday: office hours are between 9am and 5:59pm if( $dayofweek == 1 ||

    $dayofweek == 7 ||

    $hourofday < 9  ||

$hourofday >= 18 ) {

  log.warn( "Warning: access out of hours!" );

  connection.discard();

}

 

2) Customer Prioritization

This example inspects the cookie in an HTTP request. It uses the value of the cookie to determine which pool to direct the request to. One pool is faster than the other because it contains machines that are reserved for premium users.

A company has a customer base divided into “gold” and “silver” membership. It wishes to give priority to the “gold” customers and has five servers, yellow, green, blue, black and purple.

Two server pools are created: standard, for the “silver” customers, containing machines yellow, green and blue; and premium, for the “gold” customers, which includes all five of the servers. Thus black and purple are only available to the “gold” customers.

 

 

The site uses a cookie login system, with the customer type encoded in the cookie. Different membership levels can be detected, and sent to the correct pool.  This is the script needed to achieve this:

$cookie = http.getHeader( "cookie" );

if( string.contains( $cookie, "gold" )) {

   pool.use( "premium" );

} else {

   pool.use( "standard" );

}

5 short lines of code to ensure that your premium customers get the best possible service!

 

These two short examples  show that TrafficScript is indeed a very approachable, easy to learn scripting language. The best part is: our outstanding Support Team will assist you if you have problems writing or adaptig your own TrafficScripts.

This is part of your support contract and ensures that there is someone around to help you at all times at no extra cost.

For a detailed overview and syntax  to get you started, take a look at our Stingray Traffic Manager TrafficScript Guide.

Of course there is also a community of TrafficScript Users that can help you with your first (and further) steps. Visit them  at http://community.riverbed.com/t5/Stingray-Family/ct-p/zeusproducts  for code samples, answers to your questions and further documentation.

 

 

 

Is Optimization The End Game?

Dare I say it?

Ok, I’ll whisper it quietly; there is something beyond optimization and acceleration!

For a long time Riverbed have been telling the World about how to optimize, accelerate, monitor and report on network application traffic. But optimization and acceleration have a finite limit; there is only so much performance you can squeeze out of your infrastructure. At some point you are still going to reach a weight of traffic that the infrastructure is unable to cope with.

It is likely that the first things to suffer will be the web or application servers themselves, especially once you have removed the latency and bandwidth restrictions from your WAN using Steelheads. So what then? Do you just have to accept that this is the case, or deploy more resource to just sit there waiting for these high tides of traffic?

Obviously the answer is no, or I would not have started writing this blog post!

What’s required is intelligence in the data centre, to monitor application responsiveness and to take appropriate action when the performance hits thresholds set by the business. But what is the appropriate action? This is entirely down to the nature of the organisation and the applications that are critical to it.

A couple of examples:

Your organisation has an internal CRM; it is used to handle all the day to day admin required for your customers and also the payments application. On occasion at the end of a month, or more importantly at the end of a quarter, the application slows down to a nearly unusable state. The business requirement here is to ensure that the users inputting orders always get a good service, even at the cost of the users making administrative changes. Remembering that this may be the same user at different times.

Enter Stingray Traffic Manager; deployed in front of the application servers it is able in the first instance to have some impact in improving the performance. Secondly using a feature called Service Level Monitoring, it is able to recognise when the servers start responding slower than the acceptable threshold configured by the business. At this point the choices are numerous, in this particular instance it was decided that the best solution would be to start applying a Request Rate Shape to the less important traffic, slowing down the number of requests per second going into the admin side of the CRM. This frees resource on the application servers, that is then used by the payments service, increasing responsiveness.

When the high tide starts to subside, the service level monitor also picks this up and stops enforcing the rate shape on the admin users. From this point on everyone is getting a good level of service from the CRM.

The second example is of an online, Internet facing business, an eCommerce type site or similar (banking, gaming etc. they all have very familiar issues and requirements).

In this example all users are accessing the same application, and it is the type of user rather than what they are using that we wish to use as the key to our differentiation. Let’s imagine it is November and traffic to the site is starting to build up, with the peak periods causing slow-downs to the service. The business decides that they want to do two things: differentiate between people who have visited the site regularly (and spending lots of money), and those who have visited infrequently or not at all. They also want to make a decision based on what the user has in their shopping cart, which trumps whether they are a frequent visitor or not!

Here comes Stingray Traffic Manager again…

In this case we can use the same Service Level Monitor feature, to be the trigger, and also use Request Rate Shaping to apply different rates to the customers (based on a cookie placed in their browser from previous visits). But we will also have a dedicated “auto-scaling pool” of servers available for those customers who look to be spending big with us today!

Auto-Scaling is a feature that allows the Traffic Manager to communicate with a back end provisioning system and arrange for more resource to be made available. Hitting the API on vCenter, for example, and getting a second (or third, or forth etc.) web server spun up in our ESX Cluster to then spread the traffic load across.

In this case we will have two pools of servers for the Traffic Manager to select from, a normal pool with three servers in it, and an auto-scaling pool that starts with zero servers in it. When the normal pool is coping with traffic happily then all users connections are directed and load balanced to these servers. When it starts to get busy, then users with larger values in their shopping carts are directed to the “auto-scaling pool” that immediately starts to add servers as they are required (either to a limited number or until the service hits an acceptable level of responsiveness). In the other pool of servers because there is a limited number of nodes available, a rate shape is applied based on whether you are a Band A customer or a Band B, C or D. Band A being those customers with a cookie indicating they have spent over $200 this year, Band D meaning the customer has no cookie (i.e. likely to be a new user), and the B and C bands being lesser spending customers.

In both of these examples the result is that traffic/users/applications are prioritised and handled in the way the business requires them to be, based on the present circumstances and the logic put in place. This is the key to TrafficScript (the scripting language at the heart of the Stingray Traffic Manager) it is a tool to turn a business requirement, into the reality of what happens to the application traffic on the network.

So to answer the initial question, no, optimizations and acceleration are not the end game; they are extremely important steps on the way to the end game. But what is really needed is a holistic approach that uses the resource available to it’s furthest limit, but when that resource limit is reached business logic is applied to ensure the organisations objectives are reached.

---

 [NB1]What’s the proper byline we use here?

Riverbed announces Cascade 9.5

Today, Riverbed announced Cascade 9.5 and Virtual Cascade Shark, which will provide customers with the needed visibility into load-balanced and virtualized data centers, and extend end-to-end performance monitoring and troubleshooting deeper into the data center. Other key new capabilities with Cascade 9.5 include multi-segment analysis, precision timestamp support, and VoIP quality reporting – all adding to deeper visibility for more accurate analysis and troubleshooting for delivering performance. 

Press release is here and below is a podcast discussion covering the 9.5 update.

 

 

 

Join Riverbed at AFCEA West 2012

We're making a presence at the first Federal show of the year, the West 2012 conference, which will take place January 24-26 at the San Diego Conference Center in San Diego, California. Visit the Riverbed booth (#1910) to learn about our IT performance solutions, which help defense organizations meet government mandates – to consolidate data centers, reduce costs for IT, and execute on the cloud first policy – without compromising performance.

West 2012 is co-sponsored by AFCEA International and the U.S. Naval Institute, and is the largest defense technology event on the U.S. west coast for communications, electronics, intelligence, information systems and imaging. The theme of this year’s West 2012 conference is “America’s Military at the Crossroads: What’s Out and What’s In for 2012 and Beyond?” Defense and industry leaders will discuss and debate the technologies and approaches for successful military programs this year.

For more information on the West 2012 event, visit: http://www.afcea.org/events/west/12/introduction.asp.

 

What is this Stingray Traffic Manager, anyway? (Part 3)

In the third installment of our introduction to the Stingray Traffic Manager, developer Alex Gosse discusses how STM can be used to balance web site load between multiple physical locations, regardless of how far apart they are.

 

As we go through this multi-part series, if you have questions or want specific information about Stingray Trafffic Manager (or any other Riverbed products), please ask your questions in the comments, and we'll respond there.

What is this Stingray Traffic Manager, anyway? (Part 2)

In this, our second in a series of videos on the Riverbed Stingray Traffic Manager, Developer Alex Gosse talks about its ability to both balance traffic and monitor traffic loads per service or per user.