hometocprevnextglossaryfeedbacksearchhelp
PDF

Table Of Contents

Introduction

About LocalDirector

LocalDirector Terminology

LocalDirector Features

LocalDirector Security

LocalDirector Concepts

Virtual and Real Servers

Port-Bound Servers (SecureBind)

Client-Assigned Load Balancing

Server Failure Adjustments

Failed Server Recovery

Slowstart

UDP Traffic Support

IP Precedence


Introduction


This chapter introduces LocalDirector and includes the following sections:

LocalDirector Terminology

LocalDirector Features

LocalDirector Security

LocalDirector Concepts

About LocalDirector

Cisco LocalDirector is a network appliance with a secure, real-time, embedded operating system that intelligently load balances IP traffic across multiple servers. LocalDirector optimizes the performance of your site by distributing client requests across a cluster of low-cost servers (called a server farm), dramatically reducing the cost of providing
large-scale Internet services and accelerating user access to those applications.

Ideal for mission-critical applications, LocalDirector allows you to build a highly redundant and fault-tolerant server farm system. Servers are automatically and transparently placed in and out of service, providing fault tolerance. LocalDirector itself is equipped with an optional hot-standby failover mechanism, which builds increased redundancy for the server farm system.

LocalDirector serves as a transparent learning bridge to forward data packets between its interfaces. Because of its bridge capability, LocalDirector must not be installed on the network parallel to another bridge. shows a basic network configuration for LocalDirector.

Figure 1-1 LocalDirector Bridge between Internet and Servers

The load-balancing options of LocalDirector provide a flexible and adaptable method for directing IP traffic. LocalDirector load balances the following types of IP protocols, which can be specified for virtual servers and real servers:

Transmission Control Protocol (TCP)—The default protocol used by LocalDirector for IP packet transmission.

User Datagram Protocol (UDP)—With the protocol field set to udp, LocalDirector load balances UDP flows.

As a load balancer, LocalDirector can be configured to maximize the number of IP connections a server farm can manage. IP traffic is directed to different servers based on service, speed, quantity of connections, or client IP address. The servers can be a collection of heterogeneous hardware platforms and operating systems.

LocalDirector supports the two industry-standard modes of load balancing, as set with the redirection command:

Directed mode—Uses Network Address Translation (NAT) to translate the IP headers in packets. NAT, supported in LocalDirector since Version 1.0, provides quick setup with no network address changes, reducing system administration time.

Dispatched mode—Substitutes the Media Access Control (MAC) address of the server in the packet for the destination address, thus preserving the IP header information. Dispatched mode increases traffic throughput, but requires the additional setup of assigning an aliased IP address on a real server that matches the virtual IP address on LocalDirector. Dispatched mode should be used for UDP and for TCP when the IP address information needs to remain unchanged.

LocalDirector Terminology

The following are LocalDirector terms and definitions:

Virtual server—The representation of an application server farm for clients. Referred to as the virtual_id argument in configuration commands. The value for a virtual_id argument includes the virtual server IP address or name, an optional port number and bind-id, and a protocol designator.

Real server—The internal representation of a physical server being load balanced. Referred to as the real_id argument in configuration commands. The value for a real_id argument includes the IP address or name of a real server, an optional port number and bind-id, and a protocol designator.

Bind-id—For a virtual server, used with the assign command to direct client requests (based on IP address) to a specific instance of a virtual server. For a real server, the
bind-id specifies the specific virtual server to bind to.

Predictor—The algorithm used to determine which real server is assigned new connections for load balancing.

Failover—A mechanism for providing fault tolerance and high availability.

Dispatched mode—Places the MAC address of the load-balanced real server in a packet for redirection. The real server has an aliased IP address that matches the virtual IP address on LocalDirector. This mode requires subnet adjacency.

Directed mode—Uses NAT to translate the IP headers in packets. NAT translates the IP address of the virtual server to the IP address of the real server that is being load balanced.

LocalDirector Features

The following are LocalDirector features:

Hot-standby stateful failover (optional)—Enables configuration of highly redundant, fault-tolerant systems.

High throughput—Scalable to meet the needs of large Web sites.

Real-time embedded operating system—Provides full utilization of the hardware, CPU, and memory.

Migration into existing server farms is simple—IP addresses need not be reconfigured when the directed mode of load balancing is used.

Combination of virtual addresses and physical addresses—Provides flexibility in domain names and network configuration.

Supports multiple IP addresses—When the alias ip address command is used, allows the virtual server to be placed on a different IP network than the real servers without using a router.

Secure Sockets Layer (SSL)—Extends LocalDirector Version 2.1 implementation of the sticky command to use the SSL session ID as a key for stateful sticky connections (instead of the client IP address). This allows the sticky command to effectively load balance traffic when proxy servers are used. LocalDirector supports SSL3 servers and SSL2/3 (hybrid) clients.

Transparent support for all common TCP/IP Internet services.

Easy administration of servers—Adds and removes servers transparently, and increases quantities of servers as traffic grows.

Compatible with any server operating system—Administrators can mix and match server hardware and operating systems to retain technology investments.

IP precedence—LocalDirector can set an IP precedence value in the IP header, to and from virtual servers. This allows prioritizing of packets for different types of services on virtual servers. The Cisco Policy Manager software, version 1.0, can be used with LocalDirector to support a graphical user interface (GUI) version of this feature.

Support for multiple protocols—By default, LocalDirector supports TCP. You can also configure LocalDirector to load balance UDP connections.

LocalDirector Security

LocalDirector protects your network by only allowing specific traffic to pass between virtual and real servers, thus restricting both internal and external access to servers. LocalDirector security features include the following:

SecureAccess

LocalDirector can determine how to handle connections based on the source IP address of the client. When the assign command and the bind-id of the virtual server are used, traffic can be directed to a specific instance of a virtual server or dropped altogether based on the IP address of the user.

SecureBind

Use port-bound servers to restrict traffic to a specific port. TCP traffic to a port that is not specified is sent a reset packet (TCP RST). This feature is not applicable to UDP traffic.

SecureBridging

Before version 2.1, LocalDirector bridged traffic that was not destined for a virtual server. If a real server had a valid registered IP address, clients could access the server through its IP address. For security, you can now turn bridging off and not allow direct access to real servers. When the secure command is used to turn bridging off for real servers, client traffic must go through a LocalDirector virtual address.

Secure IP address

Use the static command to translate the IP address of real servers to a virtual IP address. This hides the actual IP address of the real server, but allows it to go outside LocalDirector for information requests.

The SecureServices example in Chapter 4, " ," provides details of implementing LocalDirector security features.

LocalDirector Concepts

LocalDirector concepts covered in this section include the following:

Virtual and Real Servers

Port-Bound Servers (SecureBind)

Client-Assigned Load Balancing

Server Failure Adjustments

Failed Server Recovery

Slowstart

UDP Traffic Support

IP Precedence

Virtual and Real Servers

A virtual server presents a single IP address that represents a group of real servers. Service requests to the virtual server are load balanced among the real servers. Real servers are actual host servers with unique IP addresses that provide IP services to the network. The virtual server IP address is published to the user community, but the real server IP addresses can remain unpublished, allowing you to hide actual site implementation details and provide single points of contact for users.

Virtual server addresses can only be accessed from the client side of LocalDirector. Also, clients and the real servers bound to LocalDirector virtual servers cannot be located on the same side of LocalDirector.

Port-Bound Servers (SecureBind)

When you define virtual and real servers, you can specify the port traffic that runs on them, providing the following benefits:

You can configure application-specific server farms. In other words, with one virtual IP address and multiple virtual ports, File Transfer Protocol (FTP) traffic can be directed to one server farm, and Hypertext Transfer Protocol (HTTP) traffic can be sent to another, allowing you to allocate resources more efficiently.

You can deny or accept access to a server based on service. For example, LocalDirector can deny all traffic except for HTTP traffic, providing increased security.

You can continue to access services on a server that has a failed service daemon. If a particular daemon fails, only that daemon or port fails, not the entire server. For example, multiple Web daemons might be running on the same server; if one Web daemon fails, only that TCP service fails, not the whole server. This setup increases server farm reliability.


Note   If you have a TCP port-bound virtual server (for example, 192.168.89.220:80), traffic to any other port on the virtual server results in a TCP RST packet being returned to the client/server requesting the connection (applicable to TCP traffic only).


See the section " Port-bound Servers" in Chapter 4, " ," for a configuration example.

Client-Assigned Load Balancing

This feature allows clients to be load balanced to different real servers according to their source IP address. Client-assigned load balancing is accomplished by extending the concept of a virtual server to include a bind-id. The bind-id is used with the assign command to associate a client IP address with a specific instance of a virtual server.

There are many possible uses of this feature, including:

Grades of service

You can assign known users to a collection of more powerful servers so they can obtain faster service.

Special services

You can take users known to be a part of your company to an internal page, but send unknown users to a generic home page.

Not welcome mats

You can assign "problem" clients to a real server that displays a page indicating that the user is not welcome to your site.

Restricted access

Any client IP address not identified by an assign command statement is directed to the default bind-id of 0. If you do not create the bind-id 0 version of the virtual server, then only specified IP addresses are allowed in; all other requests are blocked.

Server Failure Adjustments

If a server is not responding to requests or is responding with TCP RSTs, LocalDirector fails the server. There are two cases when a real server responds with a TCP RST:

The daemon servicing that type of traffic is down (for example, the HTTP daemon on port 80 has failed).

The server is too busy to accept any more connections.

Values set with the reassign and threshold commands determine if a server is considered failed, and can adjust how quickly a server that is not accepting connections is taken out of service. The default threshold value is 8, and the default reassign value is 3. Each real server can have different threshold and reassign values. A reassign value of 0 prevents the real server from being tested.

The reassign command controls how many times a connection synchronization
(TCP SYN) packet from a requesting client is sent to a nonresponsive server before it is reassigned to another server. The default is three TCP SYN packets. After the third packet receives no response or a TCP RST from the server, the fourth packet is sent to another server.

Each reassign process increments the reassign tally by one. When the tally reaches the threshold value, the server is considered failed. With a default threshold value of 8, the reassign process will happen eight times before the server is considered failed.

To increase the rate at which servers are considered failed, reduce the threshold and reassign values. To keep servers that are refusing connections from being failed by LocalDirector, increase the threshold and reassign values. (For example, a site receiving 400 connections per second may need to increase the threshold value to 30.)

The retry command determines how quickly a server is put in "testing" mode and given another packet after being failed by this process. The retry default is 60 seconds. On the 61st second, a connection from a virtual server is directed to the server to determine if it responds. If that connection receives a response, the server is no longer in the failed state, and is put back in service with the reassign and threshold tallies reset to 0. To increase how quickly a server is given a packet after being failed by LocalDirector, reduce the value of the retry command.


Note   Because a live connection is used to retry a failed server, a virtual server bound to the real server must also receive a connection to send to it. If the virtual server has no traffic, the real server stays in testing mode until a live connection is established, regardless of the retry value.


The autounfail command brings a failed server back in service immediately if it responds with data on an existing connection (established before it was failed by LocalDirector). LocalDirector puts the server into testing mode, and if it responds to a new live connection it is then put in service. If the server does not accept the new connection (either by not answering or by responding with a TCP RST), then the connection is marked as failed again.

When the autounfail command is enabled (it is by default), LocalDirector brings the server back in service as soon as it responds to an existing connection. The server is brought back in service before waiting for the retry time to pass, and working only with servers that are responding with data.

The data command limits the number of connections sent to a server that is not sending data. When a real server reaches the number of unanswered connections set with the data command, LocalDirector checks if other servers bound to the virtual server are also at
80 percent of their threshold capacity (DataIn value). If the other servers are close to reaching this value, LocalDirector assumes the site is busy and does not fail the server.

The timeout command sets the number of minutes an idle connection to the server is maintained, preventing incomplete connections as being counted toward LocalDirector load balancing.

Failed Server Recovery

When a real server is failed (it does not respond to a predetermined number of connections set by the threshold command), the following process is used to test whether the real server is ready to accept more connections:

After the number of minutes set with the retry command has passed (the default is
1 minute), the real server is put into "testing" state. The default for the retry command is 1 minute. If the show real command is used while in the testing state, testing is displayed in the output.

In the testing state, the server receives one live connection from a client. If the server responds, it is moved back into "IS" (in service) state; however, if the real server does not respond (or if it responds with a TCP RST), it is moved back to "failed" state and it is retried again after the number of minutes set with the retry command has passed (as before).

Slowstart

An automatic slowstart algorithm is available to help bring new servers up to speed with the weighted or leastconns options of the predictor command.

Previously, a server brought into service under heavy network traffic would be bombarded with connections because it had 0 connections. The effect of too many connections at once would disable servers or seriously decrease their performance.

The slowstart option can be set using the roundrobin or none options of the predictor command. The roundrobin slowstart option load balances network connections until network traffic is stable. When the number of connections on all bound real servers is within 80 percent of the desired distribution, the predictor switches to either weighted or leastconns, as specified in the configuration.

Slowstart is used when:

A new real server is bound to a virtual server.

A virtual server just comes out of being failed to in service.

A real server is taken from failed or out of service to in service.

A real server is taken from maintenance state to in service.

A real server is taken from external failed state to in service.

An option of the predictor command for the virtual server is changed.


Note   Slowstart is only used with the leastconns and weighted options of the predictor command.


UDP Traffic Support

LocalDirector 3.1 supports UDP load balancing, including a mix of UDP with TCP control streams. UDP streams are kept active with the timeout command.


Note   In directed mode, LocalDirector does not support applications that need an internal IP address translation (that is, where the IP address is contained in the data portion of the IP packet). Applications using embedded IP addresses should use the dispatch mode.


You can set the number of minutes a UDP connection is active by using the timeout command. When a UDP packet is received on the virtual server, LocalDirector checks the connection cache, looking for an existing connection. If the connection exists, the connection timer is restarted. If the connection does not exist, LocalDirector selects a real server for the virtual server in the normal way, based on the predictor command option configured for the server, as in a TCP-based connection.

IP Precedence

IP precedence allows a value or keyword to be added to the IP header information. This value or keyword determines the priority for processing these packets in the routers. The color command in LocalDirector, and the Cisco Policy Manager Version 1.0 application (for a GUI interface), set the IP precedence value on a virtual server basis. A site can assign each type of service it has to a different virtual server, where that virtual server is assigned a precedence.


hometocprevnextglossaryfeedbacksearchhelp

Posted: Wed Nov 10 22:42:43 PST 2004
All contents are Copyright © 1992--2004 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.