Table Of Contents
Port-Bound Servers (SecureBind)
Client-Assigned Load Balancing
Server Failure Adjustments—TCP Only
User Datagram Protocol Traffic Support
Accelerated Server Load Balancing
LocalDirector Hardware Platforms
Introduction
This chapter provides an overview of LocalDirector and describes its features and terminology. Topics include:
•
LocalDirector Hardware Platforms
Overview
Cisco LocalDirector is a network appliance that load balances TCP/IP traffic across multiple servers. LocalDirector optimizes the performance of your site by distributing client requests across low-cost servers (called a server farm). LocalDirector reduces the cost of providing large-scale Internet services and accelerates user access to server farm applications.
With LocalDirector you can build a highly redundant and fault-tolerant server farm system. Mission-critical application servers are automatically and transparently placed in and out of service, providing fault tolerance. LocalDirector itself is available with a 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. Figure 1-1 shows a basic network configuration for LocalDirector.
Figure 1-1 LocalDirector Bridge Between Internet and Servers
The load-balancing functions of LocalDirector provide a flexible and adaptable method for directing TCP/IP traffic. LocalDirector load balances the following types of IP protocols, which can be specified for virtual servers and real servers:
•
•
As a load balancer, LocalDirector can be configured to maximize the number of TCP/IP connections a server farm can manage. TCP/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:
•
•
LocalDirector Terminology
The following are LocalDirector terms and definitions:
•
•
•
•
•
•
•
•
LocalDirector Features
The following list describes LocalDirector features:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
LocalDirector Security
LocalDirector protects your network by allowing only specific traffic to pass between virtual and real servers, thus restricting both internal and external access to servers. LocalDirector security features include the following:
•
•
•
•
The secure services configuration example in Chapter 3, "Configuring LocalDirector," provides implementation details for LocalDirector security features.
LocalDirector Concepts
LocalDirector concepts in this section include the following:
•
•
•
•
•
•
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 TCP/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, so that you can 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:
•
•
•
Note
Client-Assigned Load Balancing
Using client-assigned load balancing, you can load balance clients 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:
•
•
•
•
Server Failure Adjustments—TCP Only
If a server is not responding to requests or is responding with TCP RSTs, LocalDirector considers the server to have failed. There are two cases when a real server responds with a TCP RST:
•
•
Values set with the reassign and threshold commands determine whether 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
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, 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 whether other servers bound to the virtual server are also at 80 percent of their threshold capacity (DataIn value from the output of the show real command). 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 from 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:
•
•
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 in the following instances:
•
•
•
•
•
•
Note
User Datagram Protocol Traffic Support
In software Version 3.1 and later, LocalDirector supports User Datagram Protocol (UDP) load balancing, including a mix of UDP with TCP control streams. UDP streams are kept active with the timeout command.
Note
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.
For failure of UDP real servers in software Version 3.3 and later, LocalDirector watches for an Internet Control Message Protocol (ICMP) port unreachable message.
Note
When an application uses a known connection port, the buddy command can be used to group the connections to ensure that activity on one stream updates timers on all streams.
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, in conjunction with the Cisco Quality of Service (QoS) Policy Manager, supports the use of an IP precedence value on a virtual server basis. A site can assign each type of service it has to a different virtual server. Each virtual server is assigned an IP precedence value.
Accelerated Server Load Balancing
Accelerated server load balancing (ASLB) allows LocalDirector to use the faster packet-switching speed of Catalyst 6000 family switches to accelerate load-balanced traffic. The Catalyst 6000 family switch forwards the first packet in a flow through LocalDirector, which selects the real server for the connection. The Catalyst 6000 family switch forwards all subsequent packets directly to and from the real server until the client or the server terminates or resets the connection.
ASLB operates on any LocalDirector model with LocalDirector Version 3.2 and later software. Dispatched assisted mode has been added to the redirection command to enable ASLB. Two 10/100BASE-T (all LocalDirector models) or two 1000BASE-SX Gigabit Ethernet ports (LocalDirector 430 only) are required for interface connections with the Catalyst 6000 family switches.
With the Catalyst 6000 family switches, you can specify up to 1024 server virtual IP addresses and TCP port pairs for ASLB. For instructions on configuring Catalyst 6000 family switches, refer to the Catalyst 6000 Family Accelerated Server Load Balancing Installation and Configuration Note.
Buddy Virtuals
With UDP support, a client requests a service from a server and the server responds with the requested data. Generally, a TCP connection is received from the client on the server over a well-known port. As a result of that TCP control connection, the server sends back one or more UDP sessions with the data encapsulated in IP datagrams.
UDP is a connectionless transport layer protocol. If the TCP control connection fails, UDP data flow stops. UDP continues as long as the TCP control connection is active.
LocalDirector Hardware Platforms
The LocalDirector 417 platform was introduced in software Version 3.3.4, and the LocalDirector 417G was introduced in software Version 4.1.2. The LocalDirector 430 and 416 hardware platforms were introduced in software Version 2.2.1. Support continues for the previous LocalDirector hardware platforms (the 410, 415, and 420).
For LocalDirector installation instructions and information, refer to the hardware installation guide that is shipped with your LocalDirector.
LocalDirector 417
Local Director software Version 3.3.4 supports the 417 platform. Minimum system requirements are:
•
•
•
•
•
•
LocalDirector 430
The LocalDirector 430 platform minimum system requirements are:
•
•
•
•
•
•
LocalDirector 416
The LocalDirector 416 platform minimum system requirements are:
•
•
•
•
•
•
