IMPROVING
PERFORMANCE
FOR “MOSTLY-LOCAL”
DISTRIBUTED APPLICATIONS
STEELHEAD WAN OPTIMIZATION AND
GRANITE STORAGE DELIVERY TECHNOLOGY
MOSTLY-LOCAL…
BUT STILL DISTRIBUTED
A common application architecture today is to use a local server in a branch that is mostly – but not exclusively – accessed by users at that branch. Although WAN optimization technology has allowed many of these applications to be fully consolidated into a data center, such an approach is not always workable.
Some applications have autonomy requirements (caused by regulation and/or network reliability concerns) that mean local servers are still required, even if central consolidation is desirable.
Riverbed Technology can now address these subtle requirements, providing a rich design space for differing business needs. In particular, Riverbed® offers both Steelhead® WAN optimization technology and GraniteTM storage delivery technology, which can be used separately or together. This document outlines three different approaches:
1. Servers in the branch, no consolidation or acceleration (base case) 2. Local servers with Steelhead-accelerated remote access
3. Local servers using Granite-projected central storage, with Steelhead-accelerated remote access
Before taking up those three cases, it’s useful to examine the limits that motivate these architectures.
A modern WAN optimization system incorporating Riverbed Steelhead technology makes it possible to deliver a wide variety of applications to remote locations directly from servers in a consolidat- ed data center, completely eliminating the need for branch servers.
Figure 1shows a “two-branch plus data center” example that we will use throughout this paper.
The application of interest has the characteristic that the client/server traffic is mostly – but not exclusively – local to the branch. Thus we show a heavy two-way arrow for the application traffic within each branch, and light two-way arrows for the application traffic between branches.
Figure 1. Two branches and a data center
AUTONOMY AND OTHER LIMITS
Figure 2. Server consolidation using Steelhead technology
Figure 2 shows the same application after a “classic” Steelhead- based consolidation. The application servers are now in the data cen- ter and are accessed by clients across the WAN. No servers, storage, or backup infrastructure remains in the branches. Instead, Steelhead instances (appliances, virtual appliances, software) deployed at the
Data Center
Branch 2
Steelhead Steelhead
Steelhead
Branch 1
Data Center
Branch 2
Branch 1
branches and in the data center work together to deliver the effect of local servers in the branches.
There are three primary limits to a “classic” Steelhead-based consolidation: data autonomy, operational autonomy, and unoptimizable applications.
Data autonomy is the need for a local organizational unit to retain
“ownership” of local data. Such autonomy generally runs counter to best practices for overall corporate data management, but may be imposed by national laws, industry regulations, longstanding company practices, or highly-decentralized approaches to business continuity.
Operational autonomy is the need for a local organizational unit to continue business operations despite failures in communication and/or operations elsewhere in the organization. Typically such concerns are driven by low-reliability network connections at remote branches, but there can sometimes be other reasons why it’s import- ant to consider situations where a central data center has failed or is unreachable.
Unoptimizable applications refer to cases in which one or more key applications perform poorly in a consolidated configuration, even when Steelhead WAN optimization is applied. All of the other applications in use might still be successfully consolidated using WAN optimization, but some branch server support is still needed to support the problematic application(s). In turn, there are two primary reasons for unoptimizable applications: write intensity and unrecog- nized or unfixable chattiness.
• Write intensity refers to workloads that have a high proportion of new data written at the edge, especially when that data is unlikely to be repeating previously seen data patterns. For example, appli- cations that scan images at the edge for archiving in a data center generate large amounts of distinct data.
• Unrecognized or unfixable chattiness refers to workloads that have a high degree of back-and-forth client/server interaction that is not understood or cannot be improved by current Steelhead technolo- gy. For example, legacy applications developed in-house that were not designed for WAN deployment are likely to have this style of chattiness. Because substantial engineering is required for each protocol that receives chattiness reduction, Steelhead technology will likely not be applicable for such narrow-usage applications any time in the foreseeable future.
As outlined above, WAN optimization has not been useful for all applications. Next, let’s review how an application server is typically deployed in a branch when one of these reasons has prevented con- solidation into the data center.
The “base case” for the discussion is a deployment with local servers in branches. These might be file servers, da- tabase servers, email servers, or other application servers.
For the clients in the branch, these local servers give good local service. The performance does not incur any WAN-related penalties. For clients outside the branch, using a non-local server gives relatively poor service. If the service has any degree of chattiness, the performance for non-local users declines dramatically as distance increases.
If the WAN connection is at all unreliable, that unreliability translates directly into poor availability for non-local users. Figure 3 summariz- es this arrangement for our two-branch example.
Since the applications of interest are “mostly-local” the poor perfor- mance for non-local users is unfortunate, but acceptable. Historically,
If autonomy constraints prevent consolidation, but the application itself is well suited to WAN optimization, deploying Steelhead technology can improve the re- mote-user experience compared to the previous “base case” description.
As with the previous case, local servers are deployed in branches. For the clients in the branch, these local servers give good local service and the performance does not incur any WAN-related penalties. For clients outside the branch, Steelhead-based acceleration can offer dramatic improvement compared to unoptimized access over the WAN.
Steelhead technology can even improve the quality of access over poor quality (high error rate) network links, but does not offer any improvement for remote clients if the network link is unreliable – it remains true that if the WAN link is down, the server is unavailable to remote clients. Figure 4summarizes this arrangement.
There is a notable special case where this architecture may be particularly easy to adopt. Sometimes, one set of applications are consolidated from the branch to the data center using Steelhead technology, while another set of applications remains in the branch due to autonomy or political considerations. Although the Steelhead products being used for the consolidated applications may have been purchased for those particular applications and the branch-
SERVERS IN THE BRANCH WITH OCCASIONAL REMOTE ACCESS
ADDING STEELHEAD-BASED ACCELERATION OF REMOTE ACCESS
Figure 4. Steelhead optimization of remote access
this arrangement has typically been the best choice available for unoptimizable applications. As the following sections describe, there are better architectures available for optimizable applications that could not be consolidated due to autonomy concerns.
to-data-center traffic, those products are often usable for this mostly-local, occasionally remote use case. In particular, Steelhead products are inherently capable of supporting dynamically discovered branch-to-branch mesh communication, even if they were purchased to support a simple hub-and-spokes topology.
Again, this deployment is not relevant for unoptimizable applications, but instead is used for optimizable applications when other con- straints like autonomy prevent straightforward consolidation into the data center. The next deployment option is usually the best bet for improving the manageability of unoptimizable applications.
Figure 3. Mostly-local application with branch servers
Branch 2
Branch 1
Branch 2
Branch 1
Steelhead Steelhead
Riverbed Granite products support the projection of centrally managed storage into branches with local-storage performance. Ef- fectively, Granite allows for the consolidation of storage even while leaving servers in the branch. It’s worth noting that all the server software can also be stored in Granite systems and, in many cases, booted over the WAN. Such an arrangement means that there is physical server hardware in the branch but all the server software and storage can be managed centrally. Deploying Granite gives users the effect of local servers and storage while improving costs and manageability for the IT organization via partial consolidation.
Figure 5 shows this idea of projecting “branch-local” servers from the data center.
Figure 6 shows the use of Granite technology in the data center and branches to achieve this projection of servers.
Although Granite is another two-ended technology that improves performance over the WAN, it is distinct from Steelhead WAN optimization and has different capabilities. In particular, Granite can support its style of consolidation even for applications or use cases that are not directly optimizable by Steelhead WAN optimization technology. In the Steelhead WAN optimization scenario, client/server traffic is examined and modified to achieve acceleration. In contrast, with Granite, client/server traffic is unaffected; instead, server/storage traffic is examined and modified to achieve acceleration.
Steelhead and Granite technologies can both be used in the same branch, but are typically not used for the same server. In general, if an application can be consolidated using Steelhead technology, that approach is more cost-effective. However, there is one notable exception: If an application is optimizable and requires operational autonomy to overcome network unreliability. In such a situation,
ADDING GRANITE-BASED PROJECTION
OF CENTRAL STORAGE
Granite technology can provide operational autonomy by delivering the effect of local servers and local storage, even though the servers and storage are managed (provisioned, updated, snapshotted, backed up) at the data center. Meanwhile, Steelhead technology can accelerate remote access to those local servers. Figure 7 shows the deployment of both Granite and Steelhead products in our example network.
In the Figure 7 arrangement, local users access their apparently local server as projected via Granite technology; that is, Granite is effec- tively optimizing their access to the relevant server in the data center.
Non-local users access the non-local server via Steelhead technolo- gy – but that non-local server is again actually projected by Granite technology. Thus both Steelhead and Granite are effectively optimiz- ing a non-local user’s access to the relevant server in the data center.
Figure 5. Projecting servers from data center to branch
Figure 6. Granite deployment to support projecting servers from the data center
Figure 7. Combined Granite/Steelhead deployment for optimizable app with autonomy requirements.
Branch 2
Branch 1
Data Center
Branch 2
Branch 1
Data Center
Granite
Granite Granite
Branch 2
Branch 1
Data Center
Granite
Granite Granite
Steelhead Steelhead
Figure 8 shows the more-typical usage of combined Steelhead/Granite devices in the branch for such a deployment.
In this setup, Steelhead EX appliances provide both Steelhead and Granite functionality in a combined package. Although the boxes are not drawn on top of the inter-branch traffic arrows, Steelhead auto- discovery means that it is possible to optimize the inter-branch traffic as long as it crosses a pair of Steelhead devices. In this combined package, it’s also easy to use Steelhead and Granite technologies individually for application traffic that does
not need the more elaborate configurations described in this paper.
ADDING GRANITE-BASED PROJECTION OF CENTRAL STORAGE
Branch 2
Branch 1
Data Center
Granite
Steelhead EX with Granite Steelhead EX
with Granite EX
G
EX
G
Figure 8. Combined Granite/Steelhead deployment, typical use cases Mostly-local applications are often good
candidates for “classic” consolidation using Steelhead WAN optimization.
However, sometimes those applications have limits related to autonomy or are
unoptimizable. Even in those situations where a simple Steelhead deployment is not possible, it’s often possible to achieve dramatic improvements in performance and/
or manageability with an appropriate combination of Steelhead and Granite technology.
CONCLUSION
©2013 Riverbed Technology. All rights reserved. Riverbed and any Riverbed product or service name or logo used herein are trademarks of Riverbed Technology. All other trademarks used herein belong to their respective owners. The trademarks and logos displayed herein may not be used without the prior written consent of Riverbed Technology or their respective owners.
Riverbed delivers performance for the globally connected enterprise. With Riverbed, enterprises can successfully and intelligently implement strategic initiatives such as virtualization, consolidation, cloud computing, and disaster recovery without fear of compromising performance. By giving enterprises the platform they need to understand, optimize and consolidate their IT, Riverbed helps enterprises to build a fast, fluid and dynamic IT architecture that aligns with the business needs of the organization. Additional information about Riverbed (NASDAQ: RVBD) is available at www.riverbed.com.
Riverbed Technology, Inc.
199 Fremont Street San Francisco, CA 94105 Tel: (415) 247-8800 www.riverbed.com
Riverbed Technology Ltd.
One Thames Valley Wokingham Road, Level 2 Bracknell. RG42 1NG United Kingdom Tel: +44 1344 31 7100
Riverbed Technology Pte. Ltd.
391A Orchard Road #22-06/10 Ngee Ann City Tower A Singapore 238873 Tel: +65 6508-7400
Riverbed Technology K.K.
Shiba-Koen Plaza Building 9F 3-6-9, Shiba, Minato-ku Tokyo, Japan 105-0014 Tel: +81 3 5419 1990
ABOUT RIVERBED
This paper described how Granite could consolidate a mostly-lo- cal distributed application into a data center while still delivering local-server performance and local-server autonomy. A further improvement in manageability and efficiency is possible after that: the centralized data can be efficiently backed up to low-cost cloud storage, including ultra-low-cost Amazon Glacier. Whitewa- ter® cloud storage appliances bridge between backup products and storage clouds, and they support more choices of both kinds than any competing product. Figure 9 shows a data center being backed up to a storage cloud using Whitewater technology.
In contrast to Steelhead and Granite technologies, Whitewater is a one-sided technology that is deployed only in the data center – the storage cloud does not need to deploy Whitewater itself, nor does the storage cloud need to be aware of Whitewater usage.
Figure 10shows Whitewater added in to the configuration previ- ously shown in Figure 8.
In this most-sophisticated de- ployment, Granite products still project centralized storage to the branches as in the previous sec- tion. Likewise, Steelhead prod- ucts still perform acceleration for remote access to branch servers as in the previous two sections.
The one change is that storage being projected to branches – as well as any other storage in the data center – can be backed up by one of several popular backup products to a Whitewater appli- ance or virtual appliance.
APPENDIX: ADDING WHITEWATER ACCELERATION OF CLOUD BACKUP
The Whitewater device then deduplicates the backup data, en- crypts it, and sends it in to one of a number of storage clouds.
An intact Whitewater device supports rapid recovery of recent backups – the most common case. And even if a Whitewater device is completely destroyed, recovery is straightforward: a small amount of key and configuration information loaded onto a virtual Whitewater is enough to start the process of reconstituting backups from the data stored in the cloud.
Figure 9 Whitewater
Data Center Storage Cloud
Branch 2 Branch 1
Data Center
EX G
EX G
Storage Cloud
Figure 10
