The Riverbed Blog

Interop 2012 - Stingray Traffic Manager demo

Faisal Memot demonstrates Stingray Traffic Manager, which is Riverbed's advanced virtual application delivery controller.

 

 

 

Riverbed at the DISA Conference

Are you a federal IT manager responsible for the performance of applications and the network? If yes, then join Riverbed (booth# 418) at the Defense Information Systems Agency (DISA) Customer & Industry Forum, taking place May 7-10 at the Tampa Florida Convention Center. At the conference, we will showcase our performance solutions, which are utilized by defense and intelligence agencies to analyze, accelerate and control their IT infrastructure, resulting in improved collaboration among personnel across remote locations – all for supporting the goal of achieving mission success.

This year, the DISA conference theme is “The Joint Enterprise: Delivered Through Partnership,” which will focus on technologies and initiatives to bridge gaps in communications and interoperability for further enabling collaboration with timely information.

How does the Riverbed performance platform benefit in this case? In many important ways:

Enhancing Collaboration and Efficiency Through Visibility, Consolidation, and the Cloud
Accelerated performance of applications and the network enhances collaboration between joint-forces and civilian personnel. However, application and network performance are challenges associated with the Federal Data Center Consolidation Initiative (FDCCI) and Cloud First policy as poor performance can negatively impact personnel trying to access services and applications in the cloud, over the WAN. Riverbed Cascade, an application-aware NPM solution, provides defense and intelligence agencies with complete network visibility to quickly map IT assets and applications, and their dependencies, reducing the risk of network outages during consolidation of infrastructure or a migration to the cloud. This level of visibility also enables IT managers to decide which applications to optimize to help improve productivity and collaboration among personnel. 

As part of the Cloud First policy, each Federal agency will move three services to the cloud. Riverbed performance solutions help agencies build and migrate to a flexible, high-performance hybrid infrastructure of public and private clouds to realize the promised benefits of cost reduction, resilience, and scalability of IT resources. Riverbed Steelhead appliances, with quality-of-service (QoS) capabilities, allow agencies to manage and optimize the network connection, which benefit the common workloads and services being moved to public cloud, including cloud-based email and collaboration services, and batch processing workloads. 

To deliver IT efficiencies and consolidation at branch office locations, Riverbed Granite allows IT managers to consolidate and manage all edge applications, servers, and storage to the data center. This supports the commitment to virtualization and consolidation of global IT infrastructure by removing any remaining servers from branch locations, while enabling the delivery of services to any branch location as if it were local. 

Improving Performance of Collaborative Web-based Applications
To further enhance collaboration among defense and intelligence personnel, agencies leverage Riverbed Stingray Aptimizer to accelerate Web-based applications, such as Microsoft SharePoint, which optimizes Web content on the server delivered to any browser. Stingray Traffic Manager, deployed virtually into a public cloud, enables websites and application to respond more quickly, particularly during unpredictable spikes in traffic and when the ability to collaborate is needed most. 

Learn how governmental organizations utilize other Riverbed performance solutions to overcome application and network performance challenges at http://www.riverbed.com/us/solutions/industry_solutions/government/. 

The backup plan, for the backup plan to the backup plan...

Unless you have been living under a rock for the last ten years, most people in IT have grasped the concept that perfectly working applications will eventually break: sometimes badly, other times CATASTROPHICALLY. Let's chalk this up to a mix of Murphy's and Moore's laws:

"With the speed of technology advancing and refreshing constantly, whatever can to wrong eventually will..."

Or as I like to define my 1st law:

"The amount of entropy in any IT system is directly proportionate to the frequency that things will go horribly wrong."

Now the worst part of this is that business is asking for IT systems to be more dynamic and agile moving forward. The capacity for catastrophic disaster when projects go "agile" or start a "continuous delivery" cycle are much greater if changes are not effectively tested and managed. Discreet infrastructure changes that are needed to support these agile and continuous deliveries can also cause havoc.

Now virtualisation has helped solve entropy in server hardware architecture by providing an abstraction layer between hardware and the operating system.

Moving further up the stack, similarly, Application Delivery Controllers (ADC) have carved out a place in the modern data centre to provide a critical abstraction between the entry point for a service and the resources that actually processes a given request. The abstraction comes when you create a virtual server and define a pool of resources to handle requests to that virtual server: The ADC ensures that the request is serviced by an available resource and that any resources that are not funcitoning correctly are bypassed.

Now we get to my 2nd law:

"Good health checks lead to good traffic management decisions."

The more granular and effective the health checks on any given system, the more effective your traffic management will be.

Now health checks are only half of the solution. Health checks are great at letting you know when a resource fails, but deciding what to do *when* that resource fails is where the "rubber meets the road."

Let's get to the topic in the title of this post: "Just what is the backup plan for the backup plan to the backup plan?"

Over the next four posts, I'll be running through the areas where your humble Stingray Traffic Manager can be configured to provide healthy available applications when things go HORRIBLY wrong. We are going to cover a variety of topics from things you can do inside your data centre to ways you can leverage public and private clouds to ensure you are able to keep on keeping on when DISASTER strikes.

This week we are going to cover:

Load Balancing - your first line of defence.

So you have your shiny new virtual ADC installed and you have set up your first virtual server and pool of resources. You are pretty proud of yourself but you wonder:

"Is there anything I could do to make it... Better?"

Chances are that there might be. There are several things that I do instinctively when setting up ADC virtual servers. Now good decisions come from experience, and experience, as we all know comes from *bad* decisions. So what have I learned in the last few years from all the *bad* decisions I have made looking after ADC's?

1) Make your health checks as granualr as you can: 

• ICMP Ping is better than nothing;
• TCP Port checks are better than ICMP Pings;
• "Basic HTTP" checks are better than TCP port checks (for Webservers anyway); and
• "Full HTTP" checks that actually submit a valid HTTP request and validates the server's response are better still (again for web servers).

If we look at the Basic HTTP checks in the screenshot below, you can see that there is limited scope for customisation.

The basic HTTP check will send a "GET /" and will accept *any* response as a succesful health check. If the web server responds, it is considered healthy.

Now for a more granular health check, we could use the "Full HTTP" check. Out of the box the "Full HTTP" check will perform a similar "GET /" check, but will require the server to respond with a 2XX, 3XX or 4XX server response code to be considered healthy. A "500 Internal Server Error" status code would cause the node to fail the health check:

As you can see, we could also specify:

• A Host Header (in case we have virtual hosts being used to present multiple sites on a single back end node )
• A Path to retrieve: /myapplication/login.aspx for example
• A Status Regex to match ('^[234][0-9][0-9]$' is the default that will ensure a 2XX, 3XX or 4XX message is returned)
• An HTTP response body value to match so you can ensure your application is responding correctly.

Now that we have granular health checks in place, it is time to look at what we do when health checks fail.

2) Failure Pools

Failure Pools are designed to let you have a pool that has one or more servers to use if there are no healthy members of the default pool to service the request.

A common use for failure pools is to host a "Sorry" page - a pretty static content page advising users connecting to a service that there is a technical fault or a scheduled outage. To define a Failure Pool, just create a pool in the normal fashion. Lets say we called our failure pool  "my_failure_pool". You can then configure our main pool to use it as a backup. Inside the configuration of the main pool, drop down the "Failure Pool" list and select it. It really is that simple, as you can see from the screenshot below:

3) Priority Lists

Priority lists are designed to allow you to control which hosts get used in a particular pool. A common use case for Priority Lists is when there is connectivity between two data centres, a pool definition might include resources from two different sites. Ideally, you want to always use the nodes that are local to the ADC. If enough of the local nodes are not available, then you want to expand the pool definition to include the nodes on the remote site. In the screen shot below, you can see I have configured the 172.16.10.x nodes as the highest priority group, but if the number of nodes in this group drops below 1, it will engage the next Priority Group level and use the nodes in the 172.16.135.x range.

4) Autoscaling Pools

Stingray Traffic Manager support the ability for the STM to automatically scale the number of nodes in a pool based on demand for the service. Out of the box VMWare ESX (tm), Amazon EC2 (tm) and Rackspace (tm) are supported targets.

Many integrations have been performed by Stingray customers into other API's for Autoscaling such as environments built on OpenStack and CloudStack. The Autoscale feature is provided with appropriate credentials to the Hypervisor or cloud environment and monitors server response times. If the defined percentage of server responses exceed the required maximum threshold for response times, the STM will trigger an autoscale to increase the number of nodes in the pool. The size of the Autoscaled pool can have a low and high watermark set to allow you to constrain the minimum and maximum nodes that will be dynamically provisioned. As you can see from the screen shot below, Autoscaling has been set up onto a VMWare hypervisor for a mimumum of 2 nodes and a maximum of 10 nodes.

In the screenshots above, if 40 percent of the connections exceed 1000ms response times for a period of 20 seconds, the STM will initiate a scale up of the pool. If 95 percent of the connections return under the 1000ms response time for more than 20 sec, the STM will initiate a scale down of the pool.

So as you can see, even with basic load balancing features such as Advanced Health Checks, Failure Pools, Priority Group Lists and some advances features such as Pool Autoscaling, there really are many things that you can do to add more resiliency to your deployment.

Top tips for accelerating SharePoint

Looking to accelerate SharePoint? Check out some time-tested advice from SharePoint Dragons:

http://sharepointdragons.com/2012/04/25/optimize-with-aptimize/

Cybersecurity Act of 2012

Currently in front of the US Congress is the Cybersecurity Act of 2012. With so much of today's infrastructure and economy dependent on the Internet the US Govt is considering what additional measures it can take to protect critical infrastructure, government assets, companies and individuals. A portion of this act is focused on education and awareness, which we all can use in the fast moving world of security.

While we can't control what the US Govt, or any other govt does to protect us, we certainly can take action to protect our own infrastructures. Designing a strong security architecture requires building layers of security.  By this I mean, having multiple security and monitoring systems that provide many methods of monitoring, detection, defense, etc. However, to do this you need to consider the various attack vectors, your gaps, and how to economically implement the architecture. In many cases, making security economical within a large organization requires leveraging solutions you already have, but possibly haven't utilized to their maximum capability.

Riverbed's IT Performance solutions not only contribute to improving efficiencies, they also have extensive capabilities related to monitoring and security. However, often our clients aren't leveraging these existing capabilities as part of their security architecture. Using tools already deployed in your infrastructure can help your organization improve security, while saving money.

In today's blog we'll briefly cover some of the security and monitoring capabilities in Riverbed's solution portfolio.

Stingray supports:

• Application delivery controller service protection capabilities against attacks such as malformed requests, Denial of Service (DOS), Distributed DOS, etc.
• Access rules to deny unauthorized addresses, as well as user authentication integration to deny to unauthorized users.
• The Web Application Firewall (WAF) can block application layer attacks, such as code injection, cross site scripting, phishing attacks, spiders and much more.  This can be done in software on the servers or in the Traffic Manager itself.  This architecture enables massive scaling that is cloud ready, can be distributed globally, all while being centrally managed.   
• Develop sophisticated OSI layer 3 - 7 security policies, to include shadow rule sets to model how a policy will affect traffic prior to applying it.
• Bandwidth management capabilities to limit requests, bandwidth, etc.
• Global Load Balancing for COOP scenarios.
• Extensive and customizable web logging for deep application analysis both onboard Stingray or using third-party web log analysis tools.
• Request tracing and packet capture for deeply analyzing attacks or suspicious users.
• Traffic Script and Java integration provides extensibility to build custom security capabilities.  Your imagination is truly the limit with these unique options.

Cascade supports:

• Drill-able network visualization tools to easily see who did what to whom and what happened.
• Extensive flow reporting to cost effectively monitor every conversation within an enterprise.  
• Network Behavior Analysis and Detection (NBAD) and Rule Based Events (RBE) for performance and security event alerting. Enabling you to be told about security events or anomalies very efficiently - such as new hosts, suspicious hosts, worms, unauthorized scanners, servers transmitting on unauthorized ports, backdoored hosts, unauthorized firewall policies, and much more.
• Integration with vulnerability scanners, SIMs, Active Directory, DHCP and DNS architectures to enable streamlined analysis and security automation.
• Automated and/or manual right-click integration with switching and routing infrastructure to disable interfaces with compromised hosts so they can be quickly and easily quarantined.  
• Shark provides continuous high-speed long-term packet capture with analysis via PIlot.
• Shark can export packets in PCAP format to support analysis with third-party tools, like your favorite reconstruction tool. This enables deep forensic analysis and the packets to prove exactly what happened.

Steelhead supports:

• Flow export to Cascade and/or Security Information Management (SIM) frameworks so you can monitor host level conversation details globally.
• Continuous packet capture for forensic analysis (tcpdump format).
• QoS and Inpath rules to deny or block suspect traffic types - such as P2P, malware, etc.  This enables distributed blocking of unwanted traffic.  When using Central Management Console (CMC) your organization can enforce actions globally within seconds.
• RSP/VSP virtualization frameworks to deploy your favorite security tools within a remote site without the need for more hardware (VPN, Firewalls, IDS/IPS, open source tools, etc).  For example, a SNORT package is available for RSP from the Riverbed Community site.

While Rivered is know as the IT Performance company, you can see we also have useful security capabilities.

Scary Fact: The Verizon 2012 Data Breach Investigations Report analyzed over 855 data breaches (i.e. compromised records).  Of these data breaches the attacked organization only discovered eight percent of the breaches.  Ninety-two percent of the breaches were discovered by other parties (law enforcement, fraud detection services, customers, etc).  Records were exfiltrated in seconds to hours in sixty percent of the cases, while in eighty-three percent of the cases it took weeks to months for the breach to be discovered.

Are your web applications protected from code injection, cross-site scripting, insecure direct object references or cross-site request forgery?  These are just a few of the most common web application vulnerabilities. If you are interested in learning more about web application security there are outstanding free resources at the Open Web Application Security Project (OWASP). One my my favorites is the WAF Best Practices article. OWASP hosted AppSec 2012 recently and was kind enough to invite Riverbed's Alex Meseil, Director of WAF, to discuss his experience and lessons learned about Cloud-based Distributed WAF - an architecture being used by some of the largest Internet content providers today.

We all need to be aware of the challenges with security, especially at the application layer.  Contact Riverbed today to discuss how we can further assist.

 

 

Four Steps to a Faster, Happier Microsoft SharePoint Deployment

One customer was faxing documents back and forth rather than waiting for slow Microsoft SharePoint® downloads. It's not SharePoint's fault; it's often other factors outside SharePoint involving the network. Fact is, people will drop any technology like a hot brick when the WAN slows the end-user experience.

But it does not have to be that way because Riverbed® products give users the SharePoint experience they need to be productive.

Think Centralized SharePoint - We are not talking about a distributed environment in which each branch needs additional hardware and in-branch IT talent—not to mention the unavoidable complexity involved. Instead, you can get a centralized SharePoint deployment with the performance of a local setup. For that you will need a performance platform from Riverbed.

So without further ado, here are the steps for giving your users a faster, happier SharePoint deployment.

Step 1: Know what is on your SharePoint network and who is using what
Riverbed® Cascade®

• Four reasons to centralize SharePoint
• Powerful search indexesLess hardware
• Less in-branch IT administration
• Simplified backup processes

Start by building an accurate picture of your SharePoint landscapes. That is, understand what and who is on your networks. Cascade accomplishes this with an unrivaled speed and top-to-bottom accuracy.

• Discover all hosts in 2- and 3-tier SharePoint farms
• Map dependencies between web, app, and data tiers
• Identify which users are connecting to which hosts

In addition to providing visibility into network performance to resolve users' SharePoint performance complaints, Cascade can help accelerate SharePoint deployment and re-architecture projects, while reducing outage risks and failed cutovers. Within a few hours, Cascade can discover all systems, identify server and client dependencies and locations, and show the information in a graphical, interactive format.

Step 2: Centralize and consolidate SharePoint server farms
Riverbed® Steelhead® appliances

Why distance causes problems
Start with the physics of traveling great distances, toss in application chattiness that causes hundreds or thousands of round trips, and you've got a recipe for slow applications.

Armed with your SharePoint map courtesy of Cascade, next it's time to make improvements by centralizing and consolidating SharePoint server farms. For this, you need to banish the performance blocks with:

• Data deduplication
• TCP protocol optimization
• Streamlining chatty protocols
• Prioritization and quality-of-service (QoS) management

The results speak for themselves:

• SharePoint operations are up to 30x faster
• Bandwidth utilization is reduced by up to 99%

Step 3: Managing sudden popularity
Riverbed® Stingray™ Traffic Manager

With Steelhead appliances juicing SharePoint performance, everyone now loves collaborating, so the load increases. And traffic now spikes when, for example, the CEO asks everyone to read the quarterly results and everyone tries to download the document all at once.

To increase the throughput of that SharePoint server farm, use Stingray Traffic Manager. With it SharePoint servers can support a greater number of users. How? Stingray Traffic Manager manages those requests more efficiently, including offloading some heavy lifting and repetitive tasks from the servers themselves. That means you can support more users. Bonus: You may even be able to reduce the number of servers in the farm.

Steelhead appliances optimize the limitations of SharePoint over the WAN: limited bandwidth, the impact of latency, protocol chattiness, and QoS management

Stingray Traffic Manager addresses server availability and supports greater throughput and performance from the SharePoint server farmStingray Aptimizer dynamically tunes the content on the SharePoint webpages themselves for faster load times.

Step 4: Happiness is a faster-loading page
Riverbed Stingray Aptimizer

As SharePoint users navigate around the site they must wait for each page to load—just like for Internet-based webpages. SharePoint components such as style sheets and images slow load times, as the browser has to fetch each piece from the server.

Stingray Aptimizer—a simple software installation on the SharePoint web server—can dynamically tune SharePoint pages, reducing the number and weight of those page components, leading to improved load times for SharePoint users. It's done by:

• Merging files for fewer round trips
• Shrinking and compressing files for less data
• Increasing caching to reduce reloads
• Tuning the page layout

Results:

• Up to 76% reduction in load times
• Up to 43% less traffic

Analysing Page Load Time with Stingray

Here in the Stingray unit of Riverbed we are all too familiar with the online tools which help profile the performance of your web services. Sites like webpagetest.org which allows you to run simulated tests from various locations over the globe, using a multitude of different User-Agents or browsers. Yet as good as these tools are, at the end of the day they are just simulations. What if you want to see what your actual users are experiencing when they attempt to visit your pages from the shores of Peru, snow dusted Moscow, or even good old London town? Well if you have a Stingray Traffic Manager, then I may just have the answer.

 

The map pictured above is using the OpenLayers API to plot client locations and colour code them according to the page load times they achieved.

Introducing Stingray PageSpeed...

Stingray PageSpeed is a little tool I built on top of the Traffic Manager to help our customers record and visualise exactly that data. Stingray (for the un-initiated) is an intelligent Layer 7 Application Delivery Controller (ADC), and as such it has all of the tools necessary to help you build your LIVE performance picture. All we need is a little bit of TrafficScript magic.

Stingray PageSpeed is actually just two TrafficScript rules coupled with a little bit of HTML for graphical representation of the data it collects. The system works by recording the time at which clients hit a predefined set of pages on your site, and then recording how long it takes to download and render the entire page. That data can be recorded to a log file via the Alerting system, dumped out to the Stingray Event Log, or simply made available through the PageSpeed UI.

 

Once you have a performance picture of how well your site is performing for real world, living and breathing customers you may find some performance optimizations are in order. Why not give your local Stingray team a call to discuss your options? You may want to give Stingray Aptimizer a trial; to optimize the web pages themselves. Or perhaps deploy a web-caching Stingray instance in a Data Centre or Public Cloud; to bring the content physically closer to the end users.

If you want to check out Stingray PageSpeed for yourself then go ahead and download the extension from the Riverbed Community Portal.

 

Riverbed Stingray ADC and IBM PureFlex Systems

Unimaginable complexity, combined with a lack of resources (time, money, skills) has created a situation in corporate IT  where $2.5 Trillion – 70% of the global IT budget – is spent just making sure the status quo works. As a result, 1 in 5 projects never see the light of day and there is a backlog in IT of more than 18 months.  

Its time to stop the complexity and redirect this time and money to projects that will help businesses innovate and succeed in today’s dynamic marketplace.

Riverbed and the Stingray software ADC family are proud to announce that we’ve joined IBM in pioneering a new era of computing that will help eliminate complexity and fundamentally transforming the experience and economics of enterprise IT. Expert Integrated Systems is a new category of smarter computing that combines the flexibility of a general purpose system, the elasticity of cloud and the simplicity of an appliance.  

IBM PureSystems is a new family of expert integrated systems offered by IBM that combines hardware, software and expertise into one solution, allowing us to help our clients eliminate the complexities of enterprise IT, reduce cost and encourage innovation. We are confident that this new system will significantly simplify IT infrastructure by tackling the biggest, consistent IT pain points that the industry has faced for years, resulting in more time and money for the IT projects that actually matter. 

Riverbed is among the first group of companies to learn about, test and develop applications for IBM PureSystems.  

For customers who are looking for a more flexible, dynamic way to implement their application delivery fabric within a virtual environment, Stingray is the software ADC of choice. For more information on Stingray, visit http://www.riverbed.com/us/products/stingray/

For more information about IBM PureSystems visit www.ibm.com/puresystems.

 

Custom Silicon - Compression and SSL Offload - Why (v)CPU is better than Silicon

Since I started with Riverbed in the Stingray Business Unit, many customers have been asking me about SSL offload, and why they would want to move away from their existing hardware ADC's with SSL offloaded into dedicated silicon.  It would seem that many vendors of legacy hardware ADC appliances have zeroed in on this in their defence of their install bases with customers who are looking seriously at the benefits of a software of virtualised ADC solution.

With the advent of virtualisation and the push into elastic computation environments whether "on-premise" or into private or public clouds, much focus has shifted to the conversations of infrastructure automation to provide varying levels of elasticity.  All of this is essentially aimed at a couple of key objectives:

• Reducing the time to deploy new initiatives
• Allowing applications to scale up and down as needed to meet demand
• Drive better economies by meeting demand when it is needed without having to over provision from the start

So how does this map to SSL acceleration being performed in CPU or on dedicated hardware?  It all comes down to the basics of where this elasticity is coming from: Network and Compute capacities, when virtualised, become commodities that can be consumed dynamically and on demand.  Now this level of commoditisation is not just about virtual machines or networks being provisioned, scaled or de-provisioned - it is more fundamental than that:

By moving SSL offload onto commodity (v)CPU on a soft/virtual ADC, it means the whole pool of compute is available to service your total ADC workload - regardless of whether it is SSL offload, Web Application Firewall, compression, complex L7 content rewrites or any other of a host of things that ADC's can do for your application.

Now this statement on the surface might seem vague and non specific, so let me nail this down with a specific customer example.

Last week one of our Cloud Service Providers had an opportunity laid in their lap to take on the hosting for an iPhone application that had started to grow in popularity and had hit severe scalability issues in their previous cloud hosting provider.  The team did a great job of spinning up the capacity and helping the end user migrate their application in a very short time.  All assisted of course with the Stingray Traffic Manager that was front ending the application and allowing it to scale onto a large pool of resources.

Now this might not seem incredible - ADC's have been "saving the day" in these kinds of use cases for a long time now.  What sets this story apart is what happened next.

The application grew in popularity again, and the Stingray ADC was able to scale for the end users workload without costing any more money.  The customers Stingray Traffic Manager had a sufficient license to meet their throughput requirements.  What they needed was more "grunt" in the ADC they had for a combination of elements: more SSL, more caching, more buffering and more L7 Application handling smarts.

So what did they do? They Quadrupled the vCPU and memory allocations to their Stingray Traffic Managers almost instantaneously - this gave them an immediate boost to their whole ADC workload - SSL, Caching, Buffering and L7 functions all at once.

If they had been using a hardware ADC, while the SSL might have been offloaded into silicon, the scalability of the rest of the solution would have meant upgrading the *whole hardware ADC* to get at more compute power and memory.  There was no ability to "re-route" the unused SSL hardware offload capacity to make more Compression or Application Firewall throughput.  No using it to help with L7 content rewrites, no tapping into the dedicated hardware compression chips to help with content switching...

Any un-used SSL or compression hardware processing power is essentially "lost".

As you can see, by moving to a (v)CPU centric ADC model, the deployment is much more flexible and offers better value for the customer's dollar - the ADC will service the whole workload efficiently - not just elements of it.  You have elastic capacity *inside* your ADC too now.

So do you still think you want to do SSL offload or compression in hardware?

Matching Optimization with Demand: Private Cloud Computing

There has been a lot of recent interest in industry efforts towards virtualizing the network to match the transformational results realized by virtualized computing.  The argument goes, “we now have all this great virtualized compute capacity that give us the ability to better match services with demand, but the network remains stuck in the past as the LAN/WAN services are still deployed and provisioned in more static ways.”  There is some truth to this argument along with some promising new directions (like OpenFlow), but as far as making existing the networks of applications of today and the foreseeable future run better, private clouds and technologies like VDI can be flexibly deployed and optimized using technology available now.

A key consideration, and an essential component of any enterprise cloud that hosts critical services,  is how to intercept traffic in the data center so that the right protocol traffic can be optimized for each group of applications while still maintaining enough “on-demand” capability so that your cloud can handle traffic growth, new architectures (Citrix ICA optimization, for example) and avoid any brittleness that might go along with static provisioning.  One approach is VRF-aware WCCP:  a way to hand-off traffic to optimizers as it travels to these independently provisioned services at lower layers in enterprise network.  For example, IT for different business units might be provisioned as separate collections of VMs on separate VLANs and subnets, each with its own IPv4/IPv6 routing table.  This approach allows out-of-path interception at core/aggregation layer where traffic can be better abstracted.

If you are involved in planning or thinking about your next private cloud deployment, a straightforward discussion of how to actually make these decisions is discussed in Chapter 6 of a new book by our own Dr. Steve Smoot and Nam Kee Tan.  The book, Private Cloud Computing:  Consolidation, Virtualization, and Service-Oriented Infrastructure, recently reached the top 50 in its category on Amazon and covers a whole lot more on this topic, including other key considerations like storage architecture, Infrastructure-as-a-Service, and example case studies.  There is just the right amount of depth (such as configuration examples) for designing new networking services for clouds -- services like subtenant provisioning that are central to the concept.

In short, optimization can be easily deployed ways that are fully compatible with deploying applications virtually in the enterprise using existing capabilities on your networking gear.  Future technologies changing how we think of networking VMs, such as with a FlowVisor, may also enable new ways of optimizing traffic wherever it needs to be.  Multi-tenant optimization is real today in a practical sense (it's technically very doable) and it supports the strategic gains of deploying a private cloud:  more effectively matching services with demand. 

Cloud Bursting with Stingray

Hello World! This is my first post on the Riverbed blog. So let me start it by asking you a question "How many times has someone asked you about your cloud strategy over the past three months?" Is it every day, every other day, a few times, or not at all? If this were a slashdot poll I bet the "not at all" option would be running last. It seems clouds are every where (they certainly are in Cambridge, UK this morning). So what is your cloud strategy? Hah. Now you have to change your answer!

Regardless of how you currently stand on "The Cloud" or where you strategy will take over the next few months, Riverbed can help. We can help in Physical Data Centres, we can help in Virtual Environments, and we can help in the cloud. So even if your cloud strategy is "No thank you", we can help. But as you're still reading a post titled "Cloud Bursting..." lets suppose that you're atleast a little curious about this cloud thing.

So now I could start talking about the Riverbed Cloud Steelhead and how it can help accelerate your data between the cloud and you physical DC or branch office. Alternatively I could start waxing lyrical about the SaaS accelerator we've recently launched with our good friends Akamai. But I'm not going to talk about either of those. The title of this post says Stingray, and Stingray is what you're going to get. Stingray Traffic Manager and Cloud-Bursting specifically.

So What is Cloud Bursting?

Cloud-Bursting is a deployment model which allows you to make use of cloud infrastructure on your own terms. It's often a hybrid cloud model where you continue to use your current physical or virtual Data Centre, and simply utilize resource within a third party cloud on demand. We're effectively taking dynamic infrastructure to it's logical conclusion; Data Centre on Demand. Hang on, that sounds complicated... How does it work?

Auto-Scaling

An important component in bringing up Data Centres on Demand is the ability to bring up individual servers on demand. Fortunately Stingray TM allows you to do just that with the Auto-Scaling module. This can be used in Virtual or cloud environments with or without cloud bursting. Sometimes you just want to scale up within your Data Centre, Stingray Auto-Scaling allows you to do that. It's an important feature in cloud environments where you are billed per minute for running services. Stingray will ensure that you only have the servers running required to meet demand.

Global Load Balancing

Another important component in our Data Centre on Demand strategy is a Global Load Balancer (GLB). We need a GLB component to detect when new Data Centres are spun up and to start directing traffic over to them, once they are ready to receive that traffic. Obviously the GLB component needs to include sophisticated monitoring to achieve this. Guess what? Stingray Traffic Manager has this too.

Event Mapping (Orchestration)

Thirdly we need some way to detect the need for a new Data Centre and trigger the deployment process. Stingrays sophisticated Alerting and Event system allows us to trigger the Cloud-Bursting based on any number of events. We could trigger it from Stingrays scripting language TrafficScript, we could use a local Auto-Scaling limit, or Service Level Monitoring thresholds. We could even base it on how much money your website is turning over per minute. Extensibility is Stingrays middle name.

Show me the demo

So this all sounds very good, but I'll believe it when I see it. Right? Well then, let me show it to you..

 

 

 

Using Stingray Traffic Manager to load Balance Microsoft RDP with a Session Broker

With the rise of pocket computing, users can access their applications and data from anywhere any time.  The only issue with this is that now, there is an expectation that the applications will be available… you guessed it… any where any time… (sheesh!)

But how do we do it?  How do we make sure that your critical application or resource is up all of the time:  Enter the ADC.  These are problems that ADC's are born to solve.  ADC's are the best way to keep your application ticking along regardless of outage, change window, administration errors and all the other things that plague your application stack.

Now, a misconception that I come across regularly is that ADC's can only provide value if the application is web based.  This, simply put, is not true.  In this example, I am going to show you how to make a farm of Microsoft Windows 2008R2 Remote Desktop Services servers highly available with a little more intelligence than using knuckle-headed "Round Robin" DNS, in an environment where direct connections to the servers just aren't possible.

In my example, I built a farm of three Remote Desktop Servers in under an hour in Amazon's Virtual Private Cloud, and front ended it with a Stingray Traffic Manager.  Now, the AWS VPC setups and instructions for enabling MS RDS are pretty well documented, so I am not going to go into it here.  The magic here lies in Traffic Script being able to parse just about any application protocol and interpret it at the application layer to make smart traffic management decisions.

In this instance, we are parsing the RDS x.224 headers that RDS Session brokers use to instruct an RDS client to connect to a particular RDS server.  Traffic script can grab the header and read the important RDC Routing Token like this:

Cookie: msts=2232680714.15629.0000

Now this is a numeric value that, when decoded, will tell the Traffic Manager which back end node to send the traffic to.  The Traffic Script in questions is available here:

http://community.riverbed.com/t5/Code-Samples/Load-Balancing-MS-RDP-with-a-Session-Broker/td-p/20449

See? ADC's are *perfectly* placed to keep those applications up 24/7.

Happy Traffic Managing!

One day, I might need to drive to the moon...

Traditionally, sizing hardware for an ADC deployment has been one of those things that required a mix of many skills. It was part science, part instinct, part experience, part crystal ball and part gamble. If there was a chance, or sometimes a hope, that you your application, product or offering would "take off", you would have to be ready to scale on the ADC you had picked months or years ahead. Add to that the variables where at some arbitrary point in the future, you might like to turn on advanced layer 7 functionality like an application firewall, heavy content re-writes or even just adding an additional ADC feature module, and you are left trying to size based on what you might be doing one day far off in the future. The only problem is, you are paying for it now.

It is literally like sitting in a car yard, trying to decide on which car to buy, trying to factor in that one day, you might want to drive to the moon...

I have just been reminded of this while sitting with one of our system integration partners that commented that one of their customers bought a pair of chassis based hardware ADC's from a different vendor for… wait for it… a total of 5 back end web servers because, one day, their application might "take off".

Now, I don't know about you, but if I was the customer staring down the barrel of a quote for $150k US RRP for a pair of ADC's that were taking a very modest load from day one on the chance that my application might need to scale I would be looking for a better way to do it.

I can see why Stingray's ability to scale on your commodity compute from 10Mb/s all the way to 40Gb/s and beyond with a license key upgrade seems so much more palatable to the customers I am talking to. I know if I was managing IT infrastructure budgets, the opportunity to buy only what I need right now and scale as I need to would make it much easier to get my application to market without shelling out megabucks up front.

 

 

 

The niceties of TrafficScript

So having worked with several ADC vendors over the last few years, I have had my fare share of interaction with manipulating traffic with a rules based framework like TrafficScript.  One of the niceties of Stingray TrafficScript is that is truly has come from an applications

background rather than a "packet mangling" network appliance.  For example, the first time I had to use TrafficScript to help a customer parse a response body, I was pleasantly surprised when I read the TrafficScript Reference for the http.getResponseBody() command (nb: the interesting bit is underlined below):

http.getResponseBody( [count] )

Returns the body of the HTTP response. 
If the response has chunked transfer encoding this function will return the de-chunked body. Similarly if the response is gzip or deflate compressed the body will be returned uncompressed.
If the optional 'count' parameter is provided, http.getResponseBody() will read and return the first 'count' bytes of the response. If count is 0, http.getResponseBody() will return the entire response.

# Read the entire response body
$body = http.getResponseBody();

Now, having done similar things with both iRules on F5 BigIP and with actions on Citrix NetScaler, the fact that the Traffic manipulation language takes care of de-chunking and decompressing the body content means one simple thing:

With Stingray Traffic Manager, I can spend more time doing what I sat down to do and less time fiddling with the ADC platform...

Simple really..

Top Ten Reasons why Stingray is better for your environment than a legacy hardware ADC

Since joining Riverbed 3 months ago to be their Lead ADC Systems Engineer here in Australia and New Zealand, I have been overwhelmed with the interest in the Stingray offerings.  For many, they are able to see straight away how a purely software or virtual ADC offering will fit perfectly into their environment.  Some customers that are currently using other vendors ADC products have been asking me to clarify for them the key reasons that we feel the Stingray virtual ADC offerings are better than what the others are offering.  So here it is, my "Top Ten Reasons why Stingray is better for your environment than a legacy hardware ADC":

10:      Virtual / Software ADC is in our blood:

Stingray has thousands of software ADC / virtual customers globally and pioneered this market many years ago.  The Stingray family has both enterprise grade virtual appliances and pure software deployment models, serving some of the largest telco hosting providers, massive clouds and major Financial Services Industry (FSI) providers.  Stingray supports enterprise applications such as Microsoft Exchange 2010 in *massive* environments with a level of flexibility that leaves legacy physical ADCs seem like they are standing still! (No pun intended…)  Gartner reports that the virtual ADC market is growing at 3x the physical one - the world is moving to "Tidal Data Centres", Private, public, and hybrid clouds. Simply put, the last generation was about racking and stacking boxes. But in the next gen of data centers, it's software that wins the day because of its flexibility, scalability, and responsiveness.  Other vendor's ADC virtual appliances are an afterthought to their legacy hardware platforms.

9:        Simplification:

Stingray provides simplification for customers, removing another physical layer of static physical technology and leveraging the virtual server platform you have already invested in for compute power. It is one less hardware platform to manage and one less capex item to refresh every three years.

8:        Performance:

Stingray offers the full throughput – whether it be 4Gbps or 40Gbps for example – regardless of security and other L7 functionality being used.  If you are licensed for 4gbps throughput with Stingray, you will get that full throughput. All you need to do is resource the virtual instance(s) appropriately with your commodity compute.  This is a huge differentiator in any customer looking to do L7 for CPU bound actions like Web Application Firewall (WAF) or complex traffic rules.  I have seen 10Gbps hardware ADC's that could not push more than 1Gbps once the system was doing complex Layer 7 content manipulation, and 40Gbps Solutions that could only do 140Mbps of throughput once the application firewall was turned on!  I don't know about you but if I was getting a 10:1 or 285:1 *reduction* in the throughput I had paid for, I would be pretty unhappy.

7:        Product Packaging vs. Performance/Price:

Our key competitors do not do a virtual appliance higher than 1Gbps throughput.  Customers who start down the virtual ADC path with other vendors will need to move to physical ADCs, or look at a capex heavy physical chassis solution with the same cpu bound performance degradation when using L7 activities like WAF.

6:        Real L7 Application Firewall Throughput:

Stingray Web App Firewall (WAF) is an enterprise grade Application Firewall, used in large clusters by organisations with serious throughput requirements like banks and massive online content providers.  The major differences to physical WAF vendors is the scalability.  Stingray's WAF scales in a totally unique way.  Stingray WAF has 'distributed' deployment models and a solution to the major 'degradation of throughput' issue experienced with physical ADCs that are 'CPU bound in a box'.  Even if you move to carving up a large chassis physical ADC, aside from the major “Cap-Ex” heavy model, you still are performance bound to CPU within the system.

5:        Agile application development/Dev-Ops

Stingray has an all software L7 application history (as oppose to a L4 network origin), which manifests itself in the ability to run in extremely automated deployments.  Because we are software we can be provisioned dynamically the same way that all your other server / virtual servers are.  In addition to this, Stingray is unbelievably application developer friendly.  Whether it is using the built in Rule Builder or Traffic Script capacities, or leveraging existing investments by being able to call custom authentication libraries that can live on box in the built in J2EE environment.  Incidentally, Stingray is already available in Amazon EC2 for example.. How would you like your ADC by the hour?!?!

4:        L7 Acceleration

Stingray Aptimizer provides market leading L7 Web Content Optimisation for Microsoft SharePoint and websites.  There is no better reference than Microsoft themselves using this visionary technology to accelerate http://sharepoint.microsoft.com to reduce page download times.   Who else has a Web Content Optimisation solution the can scale to literally thousands of web servers?

3:        Commercial:

Stingray is either procured 1) as a perpetual license only bought once, not refreshed every 4 years like HW, and is built to provide a 30% or better cost advantage against traditional physical ADC vendors  or 2) As a monthly subscription model for utility compute in a cloud environment. Oh: and our developer licenses are free…  as in beer...

2:        Scale:

Stingray will scale right up all with incremental soft upgrades, no new plumbing, network replacement, new hardware or massive “Cap-Ex” outlay etc.  This provides an unparalleled price/performance model.  In Stingray’s unique horizontal clustering technology, all configs are synced and Stingray can scale up and out active/active to 64 active nodes.   This is how Stingray is able to scale to massive sustained throughputs for media hosting companies while performing heavy duty traffic management.

1:         Automation:

Stingray is the only ADC to provide autoscaling functionality on box to dynamically scale your back end nodes when your application needs it, both on premise and into cloud environments like Amazon EC2 and Rackspace.

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 Granite In Action

"It does what...?"

I've heard this double-take question more than once as we describe what Riverbed Granite is able to do.  The innovation sometimes takes a minute to sink in.  "Separate storage from compute?  Solve the problem at the block-level? What does that mean anyway?"  What it means is that Riverbed customers have a new arrow in their consolidation quiver.  

By delivering the breakthrough of accelerating at the block-level across the WAN, Granite enables organizations to do things they couldn't do before. We sometimes have described Granite as being able to "consolidate the un-consolidatable."  And its true.  Anyone who has found themselves shackled by requirements for servers in the branch because of the need for local block-storage access should keep reading. In the remainder of this entry I will highlight examples of Granite in action.  In other words - let me give a few use cases - and hopefully if you've got anything considered "un-consolidatable" you'll see how Granite - and the new Edge-VSI approach can help you.

Consolidate and Control

Imagine a growing business - one that is generating a lot of data with custom applications that are running in global locations. You're happy to be growing, but you're left managing servers in places you never thought you'd visit. Ever. You've got valuable data "assets" in locations that lets say are a bit on the sketchy side.  But business is business. Can't strip out the servers/storage or else business can't flow - or can it?  Granite's unique capability to project block-level storage from the data center to the edge means you CAN CONTROL the data in the data center, and run virtualized instances of your branch-bound applications at the edge. Every single block of data is managed on your enterprise-class storage area network (SAN) in the data center even though it is serving the needs of far flung branches. Go and Grow - your concerns about where that data is are alleviated. You know where it is. You control it.

Consolidate and Simplify

What about management? We've heard from many customers about the cost and effort of managing the remaining infrastructure in the branch - servers, storage, backup. Granite and the concept of Edge-VSI make it possible to establish a "stateless" branch office in the sense that virtualized applications can run on compute in the branch but data stores are located within and managed from the data center. Here your business can Grow as you Go.  A site can easily connect a VM to a Granite "projected" storage LUN from the data center.  Size it for today.  Need more space in the future?  Expand the LUN at the data center and the branch gets more space - just like that.  No need to fly in to install new hard drives.  

Consolidate and Protect

Backup in the branch. It's not really your ideal scenario, but the data is there so you've mapped out how to make sure it's protected. Maybe it's a tape backup once every 24 hours - sent back to HQ - and recovery is that in reverse. Or maybe you backup over the WAN. In either case there's the added expense and worry of setting up the infrastructure, managing it - and hoping for the best. With Granite, data that was once thousands of miles away is now within your enterprise SAN - a very well qualified "offsite location". In the data center it can be protected with your mature data center data protection practices. It's much easier to move beyond once-a-day recovery points to something more frequent. Pair that with youre already-established replication between data centers and you've got full fledged enterprise-class protection for that data that was once somewhere "out there." You can restore in a number of ways. Catastrophic loss in the branch? Set up a new Granite Edge and reconnect to the data center. Or restore at a more granular level and stream back to the branch on demand. Even if your active branch doesn't quite appreciate the new level of protection, they will be very happy with faster restores.

Hopefully these use cases illuminate for you what we mean when we say that Granite enables a new architectural approach to consolidation. It is of course exciting to launch a new technology in the marketplace - and we at Riverbed are equally excited for you to try Granite for yourself to see the possibilities it can bring to your business.