|
|
This chapter provides an overview of LocalDirector and describes its features and terminology. Topics include:
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.
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:
The following are LocalDirector terms and definitions:
The following list describes LocalDirector features:
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:
LocalDirector concepts in this section include the following:
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.
When you define virtual and real servers, you can specify the port traffic that runs on them, providing the following benefits:
 |
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 or server requesting the connection (applicable to TCP traffic only). |
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:
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.)
|
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. |
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.
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:
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 Slowstart is only used with the leastconns and weighted options of the predictor command. |
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 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.
For failure of UDP real servers in software version 3.3 and later, LocalDirector watches for an ICMP port unreachable message.
|
Note A timeout command set to 0 for the real server prevents LocalDirector from caching connection objects. You must then use the predictor command with the roundrobin or loaded arguments. |
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 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 (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.
LocalDirector uses the Cisco Appliance Server Architecture (CASA) to exist in the Multi-Node Load Balancing (MNLB) environment. In the MNLB environment, LocalDirector is configured as a Service Manager. Cisco routers are configured as Forwarding Agents. The Service Manager determines the load balancing for the Forwarding Agents, based on information it receives from real servers. This increases network efficiency and scalability, and also adds application-aware balancing.
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.
The LocalDirector 417 platform is introduced in software version 3.3.4. LocalDirector introduced the 430 and 416 hardware platforms 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, see the hardware installation guide that is shipped with your LocalDirector.
Local Director software version 3.3.4 supports the 417 platform. Minimum system requirements are:
The LocalDirector 430 platform minimum system requirements are:
The LocalDirector 416 platform minimum system requirements are:
Posted: Wed Jan 3 13:25:59 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.