Header
Home | Set as homepage | Add to favorites
  Search the Site     » Advanced Search
Sections
Syndication


Blogroll:

||||| ALL Cisco-Network ARTICLES |||||  
CCIE Journey,
The CCIE Journey,


Integrating Accelerators into the Network

Jul 29,2008 by admin

image

Integrating Accelerators into the Network

To understand how accelerators coexist with the foundational network technologies for visibility, control, and resource alignment, it is also important to understand how accelerators integrate into the network. Integrating accelerators includes deploying accelerators and delivering to the accelerator traffic that should be optimized or needs to be unoptimized. In essence, deploying an accelerator requires that traffic somehow be given to the accelerator, and that the traffic optimized by the accelerator somehow be delivered to the distant accelerator on the other side of the WAN. This integration can be achieved physically or logically and can leverage network-integrated or nonintegrated mechanisms.

Physical Integration

Physical integration refers to the ability of an accelerator to be deployed directly into a pre-existing network device. This allows IT organizations to collapse the number of devices necessary in the physical infrastructure, which helps to minimize costs related to management, support, and power.

In most cases, physical integration refers to integration directly into the router using modules that have accelerator capabilities. With physical integration, the network device could use an integration protocol such as Web Cache Control Protocol (WCCP) or Cisco Policy Based Routing (discussed in the next section, "Logical Integration"), or another mechanism for routing traffic through the onboard accelerator.

In other cases, physical integration refers to integration of the accelerator directly between the WAN router and the LAN switch using a network card that supports fail-to-wire operation. This mode of physical integration, commonly referred to as physical inline, allows the accelerator to be deployed directly in the network path, and removed from the network path virtually should a failure occur. This is accomplished using the fail-to-wire network card, which physically closes the connection between the two network cables if a software, hardware, or power failure is encountered.

With physical inline, the accelerator sits physically between the WAN router and the LAN switch and sees all traffic traversing that connection. Physical inline provides the simplest, yet least elegant, means of integrating an accelerator into a network architecture, because it requires changing of cables and generally lacks the same levels of scalability and high availability as provided by other integration mechanisms such as WCCPv2 (discussed in the next section). Physical inline also poses the risk that a failure condition encountered by the device that is not recognized by the inline card hardware or driver might not immediately trigger a fail-through condition on the card, thereby preventing network traffic from passing through the device.

Figure 3-21 shows an example of deploying an accelerator as an integrated module within a branch office router.

Figure 3-21. Physical Integration Using Router-Integrated Network Modules


Figure 3-22 shows an example of deploying an accelerator physically inline between the branch office LAN switch and router.

Figure 3-22. Physical Integration Using Physical Inline


Logical Integration

Logical integration, also called network interception, refers to the use of networking protocols, features, or devices to ensure that traffic is routed through the accelerator in such a way that optimization and de-optimization can be applied to those traffic flows. The three most common means of logical integration through network interception include the following:

Web Cache Control Protocol v2

WCCPv2 is a control protocol that allows a WCCP child device such as an accelerator to connect with a network device such as a router, also known as a WCCP server. The result of this connection is that the accelerator notifies the network of the types of traffic it is able to handle so that the network device can intercept traffic (remove it from the normal forwarding path) and forward that traffic to a WCCPv2 child device if the specified type of traffic is encountered. The router maintains a service group of accelerator devices and balances the distribution of workload across the devices within that service group.

WCCPv2 supports up to 32 routers and 32 child devices being joined within the same service group, which allows for near-linear scalability and performance increases as additional accelerator devices are joined into the service group. WCCPv2 also provides fail-through operation; if no service group child devices are present, traffic is not intercepted and is serviced by the router without any form of redirection. With WCCPv2, devices can be dynamically added to or removed from service groups with little to no interruption of service. Because WCCPv2 provides off-path integration, scalability, and load-balancing, it is considered the most desirable architecture for integrating accelerators into a network location.

Figure 3-23 shows an example of how accelerators are deployed within a location where WCCPv2 is configured.

Figure 3-23. WCCPv2 and Accelerators


Policy Based Routing

Policy Based Routing (PBR) is a mechanism implemented in network devices such as routers that allows network administrators to apply a policy to how specific types of traffic should be routed through the network based on something other than the destination IP address. PBR can use access lists or other match conditions to identify traffic that should be routed through the policy route along with the next-hop router through which the traffic should be forwarded.

Using accelerators with PBR allows network administrators to treat the accelerator as a next-hop router for traffic flows that are candidates for optimization. PBR can also be used in conjunction with network availability management mechanisms, such as IP service level agreements (IP SLAs) or Cisco Discovery Protocol (CDP) neighbor adjacency verification, to track the availability of the accelerator as a next-hop router. If no accelerators are available, the policy route is considered invalid because the next-hop router (in this case the accelerator) is not reachable or available on the network. In such a case, the flow is not routed through the accelerator and is instead routed using the entries in the routing table.

Figure 3-24 shows an example of how accelerators can be deployed as next-hop routers when using PBR.

Figure 3-24. Policy-Based Routing and Accelerators


Server Load Balancing

Server load balancer (SLB) devices, also known as Layer 4 or Layer 7 switches, can also be used to integrate accelerator devices into the network. SLB devices can inspect traffic traversing the network and load-balance flows against one or multiple managed accelerators in a farm. SLB devices are typically deployed as an appliance but in many cases can be deployed in an integrated form factor within existing network devices such as data center switches. SLB devices commonly handle flow management and load balancing in hardware, which enables the greater levels of scalability and performance that are required in the enterprise data center.

Many SLB devices offer features beyond server load balancing, including better server scalability and security. This is accomplished through security protocol offload (allowing the SLB to manage SSL termination, encryption and decryption), TCP connection management, application acceleration functionality (complementary to accelerator functionality), and application firewall functionality. SLB devices can scale a farm of accelerators to hundreds of nodes if necessary, supporting multiple gigabits of throughput and millions of TCP connections.

Figure 3-25 shows an example of an intelligent switch with integrated server load-balancing capabilities being used as a means of integrating accelerators transparently into a data center network.

Figure 3-25. Server Load Balancers and Accelerators



283 times read

Related news

» Understanding Accelerator Control Features and Integration
by admin posted on Jul 29,2008
» Nontransparent Accelerators
by admin posted on Jul 29,2008
» Architecture of Accelerator Services
by admin posted on Jul 29,2008
» Overview of Accelerator Technology
by admin posted on Jul 29,2008
» Changing the Application Business Model
by admin posted on Jul 29,2008
Did you enjoy this article?
(total 0 votes)

comment Comments (0 posted) 

More Top News
CCSP-Cisco Certified Security Professional
Most Popular
Most Commented
Featured Author