Excerpt from Deploying Cisco Wide Area Application Services, 2nd Edition.
| Excerpt from Deploying Cisco Wide Area Application Services, 2nd Edition. | |
By Zach Seils, Joel Christner, Nancy Jin Published by Cisco Press ISBN-10: 1-58705-912-6 ISBN-13: 978-1-58705-912-4 | |
E-mail this to a friend
Newsletters: Sign-Up & Save! Receive Special Offers.
IT organizations struggle with two opposing challenges: to provide high levels of application performance for an increasingly distributed workforce and to consolidate costly infrastructure to streamline management, improve data protection, and contain costs. Separating the growing remote workforce from the location that IT desires to deploy infrastructure is the wide-area network (WAN), which introduces significant delay, packet loss, congestion, and bandwidth limitations, impeding a users’ abilities to interact with applications and the data they need in a high-performance manner conducive to productivity. These opposing challenges place IT organizations in a difficult position as they must make tradeoffs between performance and cost, as shown in Figure 1-1.
Tradeoffs Between Performance and Cost
Cisco Wide Area Application Services (WAAS) is a solution designed to bridge the divide between application performance and infrastructure consolidation in WAN environments. Leveraging appliances, router modules, or software deployed at both ends of a WAN connection and employing robust optimizations at multiple layers, Cisco WAAS is able to ensure high-performance access for remote workers who access distant application infrastructure and information, including file services, e-mail, the Web, intranet and portal applications, and data protection. By mitigating the performance-limiting factors of the WAN, Cisco WAAS not only improves performance, but also positions IT organizations to better consolidate distributed infrastructure to better control costs and ensure a stronger position toward data protection and compliance. Coupled with providing performance-improving techniques to enable consolidation of branch office infrastructure into the data center, Cisco WAAS provides an extensive platform for branch office virtualization, enabling IT organizations to deploy or retain applications and services in the branch office in a more cost-effective manner.
Figure 1-2 shows the deployment architecture for the Cisco WAAS solution.
Cisco WAAS Solution Architecture
The purpose of this book is to discuss the Cisco WAAS solution in depth, including a thorough examination of how to design and deploy Cisco WAAS in today’s challenging enterprise networks. This chapter provides an introduction to the performance barriers that are created by the WAN and a technical introduction to Cisco WAAS and its capabilities. This chapter also examines the software architecture of Cisco WAAS and outlines how each of the fundamental optimization components overcomes those application performance barriers. Additionally, this chapter examines the virtualization capabilities provided by Cisco WAAS to enable branch infrastructure consolidation while allowing applications that must be deployed in the branch office to remain deployed in the branch office.
The chapter ends with a discussion of how Cisco WAAS fits into a network-based architecture of optimization technologies and how these technologies can be deployed in conjunction with Cisco WAAS to provide a holistic solution for improving application performance over the WAN. This book was written according to version 4.1.3 of the Cisco WAAS solution, whereas the first edition was written according to version 4.0.13. Although this book provides thorough coverage of Cisco WAAS, it does not provide thorough coverage of Cisco WAAS Mobile, which is the software client deployed on laptops and desktops that provides similar functionality. However, many of the same principles that apply to Cisco WAAS Mobile are similar to those described in this book as it relates to performance challenges and overcoming them.
Understanding Application Performance Barriers
Before examining how Cisco WAAS overcomes performance challenges created by network conditions found in the WAN, it is important to have an understanding of what conditions are found in the WAN and how they impact application performance. Applications today are becoming increasingly robust and complex compared to applications of ten years ago—making them more sensitive to network conditions—and it is certain that this trend will continue. The first performance-limiting factors to examine are those that are present in the application stack on the endpoints (sender and receiver). The second set of performance-limiting factors, which are examined later in this section, are those the network causes. Figure 1-3 shows a high-level overview of these challenges, each of which is discussed in this section.
Factors Impacting Application Performance
Layer 4 Through Layer 7
Server application instances primarily interact with user application instances at the application layer of the Open Systems Interconnection (OSI) model. At this layer, application layer control and data messages are exchanged to perform functions based on the b process or transaction being performed. For instance, a user might ‘GET’ an object stored on a web server using HTTP, or perform write operations against a file stored on a file server in the data center. Interaction at this layer is complex because the number of operations that can be performed over a proprietary protocol or even a standards-based protocol can be literally in the hundreds or thousands. This is generally a direct result of the complexity of the application itself and is commonly caused by the need for end-to-end state management between the client and the server to ensure that operations complete successfully—or can be undone if the transaction or any of its steps happens to fail. This leads to a high degree of overhead in the form of chatter—which, as you see later, can significantly impact performance in environments with high latency. As the chatter increases, the efficiency of the protocol decreases due to the amount of data and time spent on the network devoted to nonproductive process increases. Consider the following examples:
A user accessing his portal homepage on the company intranet might require the download of an applet to the local machine, which after it is downloaded, uses some form of middleware or web services to exchange control messages to populate the dashboard with individual objects, which are each generally fetched sequentially with metadata about each object exchanged and examined beforehand.
A user processing transactions on an online order processing system might cause several requests against the server application to allow the browser to appropriately render all of the elements—including images and text—contained in the construction of the page.
A user interactively working with a file on a file server causes numerous control and data requests to be exchanged with the server to manage the authenticity and authorization of the user, file metadata, and the file itself. Further, after the server has determined the user is able to access the file in a certain capacity, the interactive operations against the file are typically performed using small block sizes and have a tendency to jump around the file erratically.
Between the application layers on a given pair of nodes exists a hierarchical structure of layers between the server application instance and user application instance, which also add complexity—and performance constraints—above and beyond the overhead produced by the application layer chatter described previously. For instance, data that is to be transmitted between application instances might pass through a shared (and pre-negotiated) presentation layer. This layer might be present depending on the application, because many applications have built-in semantics around data representation that enable the application to not require a distinct presentation layer. In such cases, the presentation layer is handled in the application layer directly. When a discrete presentation layer exists for an application, it becomes responsible for ensuring that the data conforms to a specific structure, such as ASCII, Extended Binary Coded Decimal Interchange Code (EBCDIC), or Extensible Markup Language (XML). If such a layer exists, data might need to be rendered prior to being handed off to the transport layer for delivery over an established session or over the network directly, or prior to being delivered to the application layer for processing. The presentation layer would also take responsibility for ensuring that application messages conform to the appropriate format. If the application messages do not conform to the appropriate format, the presentation layer would be responsible for notifying the peer that the message structure was incorrect.
From the presentation layer, the data might be delivered to a session layer, which is responsible for establishing an overlay session between two endpoints. Session layer protocols are commonly found in applications that are considered stateful, that is, transactions are performed in a nonatomic manner and in a particular sequence or order. This means that a sequence of exchanges is necessary to complete an operation, and a failure of any sequence causes the entire transaction to fail. In such scenarios, all exchanges up to the failed exchange for the same operation must be performed again. Session layer protocols commonly provide operation-layer error correction on behalf of the application, that is, should a part of an operation fail, the session layer can manage the next attempt on behalf of the application layer to offload it transparently so that the user is not impacted. This is in stark contrast with stateless applications, where each transaction or piece of a transaction is atomic and recovered directly by the application. In other words, all the details necessary to complete an operation or portion of an operation are fully contained in a single exchange. If an exchange fails in a stateless application, it can simply be attempted again by the application without the burden of having to attempt an entire sequence of operations.
Session layer protocols provide applications with the capability to manage checkpoints and recovery of upper-layer protocol (ULP) message exchanges, which occur at a transactional or procedural layer as compared to the transport of raw segments (which are chunks of data transmitted by a transport protocol such as the Transmission Control Protocol [TCP], which is discussed later). Similar to the presentation layer, many applications might have built-in semantics around session management and might not use a discrete session layer. However, some applications—commonly those that use some form of remote procedure calls (RPC)—do require a discrete session layer. When present, the session layer manages the exchange of data through the underlying transport protocol based on the state of the checkpoints and of the current session between the two communicating nodes. When the session layer is not present, applications have direct access to the underlying connection that exists between sender and receiver and thus must own the burden of session and state management.
Whether the data to be exchanged between a user application instance and server application instance requires the use of a presentation layer or session layer, data to be transmitted across an internetwork between two endpoints is generally handled by a transport protocol.
The transport protocol is primarily responsible for data delivery and data multiplexing. It provides facilities that transmit data from a local socket (that is, an endpoint on the transmitter, generally referenced by an IP address, port number, and protocol) to a socket on a remote node over an internetwork. This is commonly called end-to-end delivery, as data is taken from a socket (generally handled as a file descriptor in the application) on the transmitting node and marshaled across the network to a socket on the receiving node.
Commonly used transport layer protocols include TCP, User Datagram Protocol (UDP), and Stream Control Transmission Protocol (SCTP). Along with data delivery and multiplexing, the transport protocol is commonly responsible for providing guaranteed delivery and adaptation to changing network conditions, such as bandwidth changes or congestion. Some transport protocols, such as UDP, do not provide such capabilities. Applications that leverage UDP either implement their own means of guaranteed delivery or congestion control, or these capabilities simply are not required for the application. For transport protocols that do provide guaranteed delivery, additional capabilities are almost always implemented to provide for loss recovery (retransmission when data is lost due to congestion or other reasons), sharing of the available network capacity with other communicating nodes (fairness through congestion avoidance), and opportunistically searching for additional bandwidth to improve throughput (also part of congestion avoidance).