IMPROVING PERFORMANCE FOR MOSTLY-LOCAL DISTRIBUTED APPLICATIONS

Transcription

1 IMPROVIN PERFORMANCE FOR MOSTLY-LOCAL DISTRIBUTED APPLICATIONS STEELHEAD WAN OPTIMIZATION AND RANITE STORAE DELIVERY TECHNOLOY 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 WAN optimization technology and TM 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 -accelerated remote access 3. Local servers using -projected central storage, with -accelerated remote access Before taking up those three cases, it s useful to examine the limits that motivate these architectures.

2 AUTONOMY AND OTHER LIMITS A modern WAN optimization system incorporating Riverbed technology makes it possible to deliver a wide variety of applications to remote locations directly from servers in a consolidated data center, completely eliminating the need for branch servers. Figure 1 shows 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 Figure 2 shows the same application after a classic based consolidation. The application servers are now in the data center and are accessed by clients across the WAN. No servers, storage, or backup infrastructure remains in the branches. Instead, instances (appliances, virtual appliances, software) deployed at the 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 -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 important 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 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 unrecognized 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, applications 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 technology. 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, 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 consolidation into the data center. Figure 2. Server consolidation using technology

3 SERVERS IN THE BRANCH WITH OCCASIONAL REMOTE ACCESS The base case for the discussion is a deployment with local servers in branches. These might be file servers, database servers, 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 summarizes this arrangement for our two-branch example. Since the applications of interest are mostly-local the poor performance for non-local users is unfortunate, but acceptable. Historically, Figure 3. Mostly-local application with branch servers 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. ADDIN STEELHEAD-BASED ACCELERATION OF REMOTE ACCESS If autonomy constraints prevent consolidation, but the application itself is well suited to WAN optimization, deploying technology can improve the remote-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, -based acceleration can offer dramatic improvement compared to unoptimized access over the WAN. 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 4 summarizes 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 technology, while another set of applications remains in the branch due to autonomy or political considerations. Although the products being used for the consolidated applications may have been purchased for those particular applications and the branch- Figure 4. optimization of remote access to-data-center traffic, those products are often usable for this mostly-local, occasionally remote use case. In particular, 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 constraints 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.

4 ADDIN RANITE-BASED PROJECTION OF CENTRAL STORAE Riverbed products support the projection of centrally managed storage into branches with local-storage performance. Effectively, 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 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 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. deployment to support projecting servers from the data center 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, technology can accelerate remote access to those local servers. Figure 7 shows the deployment of both and products in our example network. Figure 5. Projecting servers from data center to branch Figure 6 shows the use of technology in the data center and branches to achieve this projection of servers. Although is another two-ended technology that improves performance over the WAN, it is distinct from WAN optimization and has different capabilities. In particular, can support its style of consolidation even for applications or use cases that are not directly optimizable by WAN optimization technology. In the WAN optimization scenario, client/server traffic is examined and modified to achieve acceleration. In contrast, with, client/server traffic is unaffected; instead, server/storage traffic is examined and modified to achieve acceleration. In the Figure 7 arrangement, local users access their apparently local server as projected via technology; that is, is effectively optimizing their access to the relevant server in the data center. Non-local users access the non-local server via technology but that non-local server is again actually projected by technology. Thus both and are effectively optimizing a non-local user s access to the relevant server in the data center. and 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 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, Figure 7. Combined / deployment for optimizable app with autonomy requirements.

5 ADDIN RANITE-BASED PROJECTION OF CENTRAL STORAE Figure 8 shows the more-typical usage of combined / devices in the branch for such a deployment. In this setup, appliances provide both and functionality in a combined package. Although the boxes are not drawn on top of the inter-branch traffic arrows, autodiscovery means that it is possible to optimize the inter-branch traffic as long as it crosses a pair of devices. In this combined package, it s also easy to use and technologies individually for application traffic that does not need the more elaborate configurations described in this paper. with with CONCLUSION Mostly-local applications are often good candidates for classic consolidation using WAN optimization. However, sometimes those applications have limits related to autonomy or are unoptimizable. Even in those situations where a simple deployment is not possible, it s often possible to achieve dramatic improvements in performance and/ or manageability with an appropriate combination of and technology. Figure 8. Combined / deployment, typical use cases

6 APPENDIX: ADDIN WHITEWATER ACCELERATION OF CLOUD BACKUP This paper described how could consolidate a mostly-local 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 lacier. Whitewater 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 and 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. The Whitewater device then deduplicates the backup data, encrypts 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. Storage Cloud Figure 10 shows Whitewater added in to the configuration previously shown in Figure 8. Storage Cloud In this most-sophisticated deployment, products still project centralized storage to the branches as in the previous section. Likewise, products still perform acceleration for remote access to branch servers as in the previous two sections. Whitewater 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 appliance or virtual appliance. Figure 9 Figure 10 ABOUT RIVERBED 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 Riverbed Technology, Inc. 199 Fremont Street San Francisco, CA Tel: (415) Riverbed Technology Ltd. One Thames Valley Wokingham Road, Level 2 Bracknell. R42 1N United Kingdom Tel: Riverbed Technology Pte. Ltd. 391A Orchard Road #22-06/10 Ngee Ann City Tower A Singapore Tel: Riverbed Technology K.K. Shiba-Koen Plaza Building 9F 3-6-9, Shiba, Minato-ku Tokyo, Japan Tel: 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.