Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up
Network + Systems Infrastructure
W O R K S H O P  
Making Layer 7 Work for You

  February 20, 2003
  By Lori MacVittie


>> continued from previous page

Up in Arms
TOC Issue TOC
Printer Print full article
Printer Print this page
Printer Download as PDF
E-Mail E-Mail this URL
Discuss Discuss this article
flame author Flame the author
 
  In this article
arrow
Introduction
arrow
Up in Arms
arrow
Sharing the Load

The topology of your network dictates where the content networking device physically sits. There are three server-farm topologies: inline, one-arm and side-arm.

When a content networking device is deployed in an inline network topology, it sits between the router and the network switch that's physically connected to the server farm. The downside of this configuration is that all traffic must return via the Layer 7 device regardless of whether the device needs to see the traffic on the egress route. If the device can't handle high throughput, performance will suffer.

Deploying and configuring an inline topology with a load balancer in proxy mode is simple. But high-availability Web environments with this topology need an additional load balancer to support failover and to avoid a single point of failure (see "Sharing the Load," page 71). The inline topology diagram above illustrates this type of setup.



In one-arm and side-arm topologies, the Layer 7 device hangs off the network switch rather than being sandwiched between the router and switch (see "Armed and Ready," page 69). The main difference between the two topologies is the number of interfaces between the content networking device and the switch: One-arm topology uses a single interface; side-arm uses two.

So which topology do you use when? It depends on the amount of traffic passing through the switch. If the switch has heavy traffic, side-arm is best; otherwise, one-arm will suffice.



Staying Inline

click to enlarge

A word of caution: When your content-networking device is configured in proxy mode in a one-arm or a side-arm topology, you must reconfigure the default gateway on the servers to point to its IP address. But if the device is configured in transparent mode in this case, reconfiguration likely won't be necessary because the device automatically intercepts traffic destined for the specified ports and/or IP addresses.

Be More Direct

A key component of a Web services configuration is setting up how your Web servers get content to the client machine. There are two ways to configure this in a load balancer, the most common of which is to have the device provide the client access to the Web content. Another approach, called direct-return configuration, has the Web server ship the content to the client rather than having the load balancer or other content-aware device handle the task.

Different vendors use different terms for this direct-return configuration. Nortel calls it Direct Server Return (DSR); F5 Networks calls it nPath; Foundry Networks, SwitchBack; and Radware, Out of Path. But don't let the terms throw you; they all mean when the server sends Web content directly to the client. In our Real-World Labs®, we use the term DSR when we review a content-aware device because it best describes the direct-return configuration.

DSR makes sense in cases where outbound traffic in the Web infrastructure is significantly heavier than inbound traffic. Eliminating that extra stop at the load balancer for outbound traffic can increase the throughput and response time of your Web infrastructure, a big plus when you're load balancing heavy content.



To Proxy or Not to Proxy

click to enlarge

When outbound traffic isn't heavy, DSR may be unnecessary. There are about 10 outbound packets for every inbound packet in a typical Web infrastructure, so if you're handling 100 inbound packets per second, that's only 1,000 outbound packets per second. That's not enough to tax the load balancer or other content networking device, so DSR wouldn't be the best fit here.

Inline, one-arm and side-arm topologies are often used in conjunction with DSR so servers in the farm can bypass the content networking device and route directly to the client. Then you don't have to reconfigure servers in the farm when you install a load balancer.

Upon Closer Inspection

Content networking will continue to be a major part of a successful Web infrastructure design, especially with the emergence of Web services and XML for e-business. Load balancers and other Layer 7 content networking devices from F5 Networks are already digging even deeper into application traffic, giving you more control in managing your Web traffic and making it easier to develop automated e-business and e-commerce applications. So it's important to know the ins and outs of how to design your Web infrastructure with these devices.

Technology editor Lori MacVittie has been a software developer, a network administrator and a member of the technical architecture team for a global transportation and logistics organization. Write to her at lmacvittie@nwc.com.

Post a comment or question on this story.


start top  Introduction Sharing the Load 

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers