|
|
This chapter includes the following sections:
Follow these guidelines to ensure general safety:
Install LocalDirector as follows:
Step 1 Unpack LocalDirector and place it in your equipment rack or on a level surface.
Step 2 Connect the power cord to LocalDirector and plug it in.
Step 3 Connect the null modem serial cable to the LocalDirector DB-9 console port.
Step 4 Connect the LocalDirector serial console cable connector to your ASCII terminal or computer. Use the gender adapter if necessary.
Step 5 Configure the serial port in your computer or terminal with these settings: 9600 baud, 8 data bits, no parity, and 1 stop bit; that is, set 9600, 8-N-1. Ensure your communications software is running.
Step 6 Connect the network cable from the hub or switch containing the physical servers to one of the network interface connections on the LocalDirector.
Step 7 Connect the network cable from the router on the remainder of your network to another network interface connection on the LocalDirector.
Configure LocalDirector system settings (primary configuration) as follows:
Step 1 Turn on the power switch. Because LocalDirector ships with its software already in Flash memory, LocalDirector can boot without a system diskette.
As LocalDirector boots, messages such as the following are displayed:
Finesse Bios V3.3
Booting Floppy
Loading from Flash
128MB RAM
rns23x0 Ethernet @ irq 11 dev 4 index 3 MAC: 0000.bc11.4c6b
rns23x0 Ethernet @ irq 10 dev 5 index 2 MAC: 0000.bc11.4c6a
rns23x0 Ethernet @ irq 15 dev 6 index 1 MAC: 0000.bc11.4c69
rns23x0 Ethernet @ irq 9 dev 7 index 0 MAC: 0000.bc11.4c68
Flash=AT29C040A @ 0x300
LocalDirector 420 Version 2.1.1
........................................
Copyright (c) 1998 by Cisco Systems, Inc.
Restricted Rights Legend
Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706
Step 2 Enter the enable command to access privileged mode, and the configure terminal command to access LocalDirector configuration commands.
Step 3 Assign the LocalDirector IP address and subnet mask with the ip address command. If this is a failover configuration, use the failover ip address command to set the IP address for the standby unit.
Step 4 Use the ping command to determine if the LocalDirector has connectivity or if a host is available on the network. If this test fails, try the following:
Step 5 Change the privileged mode password with the enable password command.
Step 6 If preferred, change the host name for the LocalDirector command line prompt with the hostname command. Note that in a failover configuration, both units will have the same host name because the configuration is copied from one unit to the other.
Configure the LocalDirector server farm (secondary configuration) as follows:
Step 1 Define virtual servers with the virtual command.
Step 2 Set the type of load balancing for each virtual server with the predictor command.
Step 3 Define real servers with the real command.
Step 4 Associate each virtual server to real server(s) with the bind command.
Step 5 Designate real and virtual servers as in service with the in-service command. This can also be done when the virtual and real servers are defined.
Step 6 Check the configuration by using the write terminal, show real, show virtual, and show bind commands.
Step 7 Store the configuration in Flash memory with the write memory command. The configuration stored in Flash memory can be verified with the show config command.
The basic configuration is complete. Exit configuration mode by entering ^Z, and exit privileged mode with the disable command.
Figure 4-1 shows an example of a basic configuration with one virtual server bound to two real servers:
LocalDirector# show configuration
: Saved
: Local Director Version 2.1.1
syslog output 20.3
no syslog console
hostname LocalDirector
interface ethernet 0 auto
interface ethernet 1 auto
ip address 192.168.1.89 255.255.255.0
no rip passive
no failover
virtual 192.168.1.99:0:0 is
predictor 192.168.1.99:0:0 leastconns
real 192.168.1.1:0 is
real 192.168.1.2:0 is
bind 192.168.1.99:0:0 192.168.1.1:0
bind 192.168.1.99:0:0 192.168.1.2:0
no snmp-server contact
no snmp-server location
LocalDirector#
To help determine virtual and real server configurations, diagram the implementation before you begin. Ensure that any virtual IP address you configure is from a valid IP network. If the virtual address is to be accessed from the Internet, the IP address must be part of a NIC-allocated network number.
This section provides example server configurations, including the following:
The following are LocalDirector default configuration settings:
In this example, the LocalDirector is load balancing all TCP traffic over two servers to provide Web services. Figure 4-2 shows the network configuration:
All traffic destined for virtual IP address 192.168.1.99 is load balanced across real servers with IP addresses 192.168.1.1 and 192.168.1.2. Only the virtual server appears in the Domain Name System (DNS). The following example shows the commands used to set up this configuration:
The enable command starts privileged mode. Then configure t starts configuration mode:
LocalDirector> enable
Password:
LocalDirector# configure t
The ip address command specifies LocalDirector IP address 192.168.1.89, and subnet mask 255.255.255.0:
ip address 192.168.1.89 255.255.255.0
The interface ethernet command with the auto option automatically determines the speed of the Ethernet interface:
interface ethernet 0 auto
interface ethernet 1 auto
The no failover command indicates that the failover option is not being used:
no failover
The name command is used to identify 192.168.1.99 as Domain, and then the virtual command is used to define Domain as a virtual server:
name 192.168.1.99 domain
virtual domain
The name command is used to identify IP address 192.168.1.1 as Server1 and 192.168.1.2 as Server2:
name 192.168.1.1 server1
name 192.168.1.2 server2
The real command is used to identify Server1 and Server2 as real servers, and the is (in-service) option enables the real servers to start accepting connections:
real server1 is
real server2 is
The bind command associates Domain with Server1 and Server2 and establishes the load-balancing relationship between the virtual and real servers:
bind domain server1 server2
The is (in-service) command brings the virtual server in-service:
is virtual domain
Finally, the write mem command saves the new settings:
LocalDirector(config)# write mem
Building configuration...
[OK]
Use the write terminal command to view the running configuration before it is saved. View the saved configuration with the show configuration command, as follows:
LocalDirector# show configuration
: Saved
: Local Director Version 2.1.1
syslog output 20.3
no syslog console
hostname LocalDirector
interface ethernet 0 auto
interface ethernet 1 auto
ip address 192.168.1.89 255.255.255.0
no rip passive
no failover
virtual 192.168.1.99:0:0 is
predictor 192.168.1.99:0:0 leastconns
real 192.168.1.2:0 is
real 192.168.1.1:0 is
name 192.168.1.1:0 server1
name 192.168.1.2:0 server2
name 192.168.1.99:0:0 domain
bind 192.168.1.99:0:0 192.168.1.1:0
bind 192.168.1.99:0:0 192.168.1.2:0
no snmp-server contact
no snmp-server location
LocalDirector#
In this example, four virtual addresses are bound to a single web server, as shown in Figure 4-3, allowing you to provide multiple DNS entries with one server. In other words, one real server supports multiple domain names. Virtual IP addresses 192.168.1.99, 192.168.1.100, 192.168.1.101, and 192.168.1.102 are identified as Domain1, Domain2, Domain3, and Domain4, respectively. Port 80 traffic for each virtual IP address is bound to different ports on real server IP 192.168.1.2.
All Web traffic destined for Domain1 will access information on real server 192.168.1.2 through port 8000. Traffic destined for Domain2 will access information on real server 192.168.1.2 through port 8001, and so on.
Also, by defining a virtual server as an IP address and a port, you can restrict traffic to a specific port. Port 80 is specified for each of the virtual servers, and ports 8000, 8001, 8002, and 8003 are specified for the real server. The virtual server ports and real server ports are bound to each other directly. In addition, if the application running on port 8000 fails, the entire server will not be failed by LocalDirector; the remaining ports will continue to accept connections.
A configuration example follows:
The name command is used to identify the IP addresses of the virtual and real servers:
name 192.168.1.99 domain1
name 192.168.1.100 domain2
name 192.168.1.101 domain3
name 192.168.1.102 domain4
name 192.168.1.2 server
The real command is used to identify the IP address named "Server" as a real server that is accepting connections on ports 8000, 8001, 8002, and 8003:
real server:8000
real server:8001
real server:8002
real server:8003
The virtual command is used to identify the named IP addresses "Domain1," "Domain2," "Domain3," and "Domain4" as virtual servers accepting connections on port 80:
virtual domain1:80
virtual domain2:80
virtual domain3:80
virtual domain4:80
The bind command is used to direct port 80 network traffic from each virtual server to a different port on the real server:
bind domain1:80 server:8000
bind domain2:80 server:8001
bind domain3:80 server:8002
bind domain4:80 server:8003
The is (in-service) command is used with the all option to indicate that all ports of the real server are in service:
is real server all
The is (in-service) command is used to indicate that the virtual servers are in service:
is virtual domain1:80
is virtual domain2:80
is virtual domain3:80
is virtual domain4:80
The show bind command is used to view the association between the virtual server ports and real server ports:
LocalDirector(config)# show bind
Virtual Real
domain4:80:0(IS)
server:8003(IS)
domain3:80:0(IS)
server:8002(IS)
domain2:80:0(IS)
server:8001(IS)
domain1:80:0(IS)
server:8000(IS)
LocalDirector(config)#
You can combine multiple virtual and real servers so that each virtual server sends network traffic to the same port across real servers, as shown in Figure 4-4. All traffic destined for virtual server 192.168.1.100 is load balanced across the three real servers on port 8001. Traffic destined for virtual server 192.168.1.101 is load balanced across the real servers on port 8002.
A combination of virtual servers and real servers can also be used to load balance traffic across server clusters, as shown in Figure 4-5.
Each virtual server can have a different load balancing option set with the predictor command. For example, 192.168.1.100 can be configured to use the leastconns option, and 192.168.1.101 can be configured to use the weighted option.
A configuration example follows:
The real command is used to identify three real servers, each accepting connections on ports 8001 and 8002. The is (in-service) option is used to indicate that the real servers are in service:
real 192.168.1.1:8001 is
real 192.168.1.1:8002 is
real 192.168.1.2:8001 is
real 192.168.1.2:8002 is
real 192.168.1.3:8001 is
real 192.168.1.3:8002 is
The virtual command is used to create two virtual servers accepting connections on port 80:
virtual 192.168.1.100:80
virtual 192.168.1.101:80
The bind command is used to direct network traffic from port 80 on the two virtual servers to ports 8001 and 8002 on the three real servers:
bind 192.168.1.100:80 192.168.1.1:8001
bind 192.168.1.100:80 192.168.1.2:8001
bind 192.168.1.100:80 192.168.1.3:8001
bind 192.168.1.101:80 192.168.1.1:8002
bind 192.168.1.101:80 192.168.1.2:8002
bind 192.168.1.101:80 192.168.1.3:8002
The is (in-service) command is used to bring the virtual servers in service:
is virtual 192.168.1.100:80
is virtual 192.168.1.101:80
The show bind command is used to view the association between the virtual and real servers:
LocalDirector(config)# show bind
Virtual Real
192.168.1.101:80:0(IS)
192.168.1.3:8002(IS)
192.168.1.2:8002(IS)
192.168.1.1:8002(IS)
192.168.1.100:80:0(IS)
192.168.1.3:8001(IS)
192.168.1.2:8001(IS)
192.168.1.1:8001(IS)
LocalDirector(config)#
In Figure 4-5, TCP connections to Domain1 are load balanced across real servers 192.168.1.1, 192.168.1.2, and 192.168.1.3. Connections to Domain2 are load balanced across servers 192.168.1.4, 192.168.1.5, and 192.168.1.6.
A configuration example follows:
The real command is used to identify the six real servers, and the is (in-service) option is used to indicate that the real servers are in service:
real 192.168.1.1 is
real 192.168.1.2 is
real 192.168.1.3 is
real 192.168.1.4 is
real 192.168.1.5 is
real 192.168.1.6 is
The virtual command is used to identify the two virtual servers:
virtual 192.168.1.100
virtual 192.168.1.101
The bind command is used to direct network traffic from virtual server 192.168.1.100 to real servers 192.168.1.1, 192.168.1.2, and 192.168.1.3, and to direct network traffic from virtual server 192.168.1.101 to real servers 192.168.1.4, 192.168.1.5, and 192.168.1.6:
bind 192.168.1.100 192.168.1.1 192.168.1.2 192.168.1.3
bind 192.168.1.101 192.168.1.4 192.168.1.5 192.168.1.6
The is (in-service) command is used to bring the virtual servers in service:
is virtual 192.168.1.100
is virtual 192.168.1.101
The show bind command is used to view the association between the virtual and real servers:
LocalDirector(config)# show bind
Virtual Real
192.168.1.101:0:0(IS)
192.168.1.6:0(IS)
192.168.1.5:0(IS)
192.168.1.4:0(IS)
192.168.1.100:0:0(IS)
192.168.1.3:0(IS)
192.168.1.2:0(IS)
192.168.1.1:0(IS)
LocalDirector(config)
The sticky command ensures that the same client gets the same real server for multiple connections. The sticky command allows you to get back to the same real server again and retain the statefulness of the client-server connection. For example, if a client is completing an online form, the sticky command ensures that multiple connections are sent to the same server in order to complete the transaction. Without this command set, each connection attempt to a virtual server is routed according to the predictor option selected for that virtual server, without regard to prior history of the foreign host.
The sticky command does not time how long a client is connected, it times periods of inactivity. If the sticky command is set to five, and the client is active, new requests from the client are not sent to another server via load balancing after five minutes. However, if five minutes of connection inactivity elapse, the requests from the client could be sent to another real server.
The sticky command is essential for the Secure Socket Layer (SSL) protocol and Active Server Pages (ASP). With SSL, the sticky command enables an SSL handshake to occur between the client and server. This establishes an SSL session which then allows all communication to be encrypted. With ASP, the sticky command allows the server to maintain session variables while the client navigates between pages within the ASP application.
A configuration example follows:
The virtual command is used to identify 192.168.1.1 as a virtual server accepting traffic on port 80 (HTTP) and port 443 (SSL):
ld(config) 5# virtual 192.168.1.1:80:0
ld(config) 6# virtual 192.168.1.1:443:0
The real command is used to identify 192.168.1.220 and 192.168.221 as real servers accepting traffic on port 80 (HTTP) and port 443 (SSL):
ld(config) 7# real 192.168.1.220:80 is
ld(config) 8# real 192.168.1.221:80 is
ld(config) 9# real 192.168.1.220:443 is
ld(config) 0# real 192.168.1.221:443 is
The bind command is used to bind the virtual servers accepting traffic on port 80 to the real servers accepting traffic on port 80:
ld(config) 1# bind 192.168.1.1:80:0 192.168.1.220:80 192.168.1.221:80
The bind command is used to bind the virtual servers accepting traffic on port 443 to the real servers accepting traffic on port 443:
ld(config) 2# bind 192.168.1.1:443:0 192.168.1.220:443 192.168.1.221:443
The sticky command is used to ensure that requests to virtual server 192.168.1.1:443 are sent to the same real server until 10 minutes of inactivity elapse:
ld(config) 3# sticky 192.168.1.1:443:0 10
The is (in-service) command is used to place the virtual servers in service:
ld(config) 4# is virtual 192.168.1.1:80:0
ld(config) 5# is virtual 192.168.1.1:443:0
The show bind command is used to view server bind associations:
ld(config) 6# show bind
Virtual Real
192.168.1.1:443:0(IS)
192.168.1.221:443(IS)
192.168.1.220:443(IS)
192.168.1.1:80:0(IS)
192.168.1.221:80(IS)
192.168.1.220:80(IS)
The show sticky command is used to view the sticky command setting:
ld(config) 7# show sticky
Machine Sticky
192.168.1.1:443:0 10
192.168.1.1:80:0 0
ld(config) 8#
Use the assign command to associate real servers to the bind-ids of virtual servers, and direct client request to a specific instance of a virtual server, as shown in Figure 4-6. Depending on the bindings of virtual servers to real servers, different real machines are used for different clients.
In this example, clients from 204.31.17.0 will be directed through the virtual server with a bind-id of 1 to the real servers with IP addresses 10.10.20.1, 10.10.20.2, and 10.10.20.3. Client requests from 192.150.50.0 will go through the virtual server with a bind-id of 2 to real servers with IP addresses 10.10.30.1 and 10.10.30.2. Requests from any other source IP address will go to the virtual server with the default bind-id of 0, and that virtual server is bound to real servers 10.10.10.1, 10.10.10.2, and 10.10.10.3.
A configuration example follows.
A virtual server that will accept client traffic that is not assigned to a specific bind-id is created, and three real servers are bound to it:
virtual 192.168.1.1:80:0
real 10.10.10.1:80
real 10.10.10.2:80
real 10.10.10.3:80
bind 192.168.1.1:80:0 10.10.10.1:80
bind 192.168.1.1:80:0 10.10.10.2:80
bind 192.168.1.1:80:0 10.10.10.3:80
A virtual server with a bind-id of :1 is created, and three real servers are bound to it:
virtual 192.168.1.1:80:1
real 10.10.20.1:80
real 10.10.20.2:80
real 10.10.20.3:80
bind 192.168.1.1:80:1 10.10.20.1:80
bind 192.168.1.1:80:1 10.10.20.2:80
bind 192.168.1.1:80:1 10.10.20.3:80
A virtual server with a bind-id of :2 is created, and two real servers are bound to it:
virtual 192.168.1.1:80:2
real 10.10.30.1:80
real 10.10.30.2:80
bind 192.168.1.1:80:2 10.10.30.1:80 10.10.30.2:80
Clients from network 204.31.17.0 are assigned to the virtual server with a bind-id of :1, and clients from 192.150.50.0 are assigned to the virtual server with a bind-id of :2. Using a zero in the fourth octet of the subnet mask includes the entire range for the client IP address:
assign 192.168.1.1:80:1 204.31.17.0 255.255.255.0
assign 192.168.1.1:80:2 192.150.50.0 255.255.255.0
The example shown in Figure 4-7 uses the LocalDirector security features of SecureAccess, SecureBind, and SecureBridge in order to secure a network both internally and externally.
In this example, the company has a Class C network with an IP address of 192.168.1.0. The virtual address in DNS is 192.168.1.8 for www.domain.com. Requests from internal clients will be directed to wwwin.domain.com. The system administrator's IP address is 192.168.1.101.
A configuration example follows.
To turn on the SecureBridge feature:
secure 0
secure 1
Create a virtual address for Internet Web access:
virtual 192.168.1.8:80:0 is
Create a virtual address for internal Web access:
virtual 192.168.1.8:80:1 is
Create virtual addresses for the system administrator to access the real servers via Telnet:
virtual 192.168.1.8:2310:1 is
virtual 192.168.1.8:2311:1 is
virtual 192.168.1.8:2312:1 is
Define the three real servers that are serving the Internet Web:
real 192.168.1.10:80 is
real 192.168.1.11:80 is
real 192.168.1.12:80 is
Define the three real servers that are serving the internal Web:
real 192.168.1.10:8000 is
real 192.168.1.11:8000 is
real 192.168.1.12:8000 is
Define the three real servers that will provide Telnet access for the system administrator:
real 192.168.1.10:23 is
real 192.168.1.11:23 is
real 192.168.1.12:23 is
Bind the system administrator virtual addresses to the real servers:
bind 192.168.1.8:2310:1 192.168.1.10:23
bind 192.168.1.8:2311:1 192.168.1.11:23
bind 192.168.1.8:2312:1 192.168.1.12:23
Bind the Internet Web server virtual address to the real servers:
bind 192.168.1.8:80:0 192.168.1.10:80
bind 192.168.1.8:80:0 192.168.1.11:80
bind 192.168.1.8:80:0 192.168.1.12:80
Bind the intranet Web server virtual address to the real servers:
bind 192.168.1.1:80:1 192.168.1.10:8000
bind 192.168.1.1:80:1 192.168.1.11:8000
bind 192.168.1.1:80:1 192.168.1.12:8000
Give only the system administrator access to the Telnet virtual addresses. The subnet mask of 255.255.255.255 restricts access to the individual IP address:
assign 192.168.1.8:2310:1 192.168.1.101 255.255.255.255
assign 192.168.1.8:2311:1 192.168.1.101 255.255.255.255
assign 192.168.1.8:2312:1 192.168.1.101 255.255.255.255
Give only internal clients access to the virtual addresses for the internal Web. The subnet mask of 255.255.255.0 restricts access to the network IP address:
assign 192.168.1.8:80:1 192.168.1.0 255.255.255.0
TCP services can be directed to specific servers. Figure 4-8 illustrates how to send HTTP traffic to Server A, Telnet traffic to Server B, and direct all other traffic to Servers C and D. Three virtual servers have IP address 192.168.1.100; one accepts only HTTP traffic (port 80), one accepts Telnet traffic (port 23), and the other accepts all other connections (default).
Names can also be used to refer to the real and virtual servers in this example.
A sample configuration follows.
The real command is used to identify a real server accepting connections on port 80, one accepting connections on port 23, and two real servers accepting default traffic:
real 192.168.1.1:80 is
real 192.168.1.2:23 is
real 192.168.1.3 is
real 192.168.1.4 is
The virtual command is used to identify three virtual servers for IP address 192.168.1.100, one accepting connections on port 80, one accepting connections on port 23, and the other two accepting default traffic:
virtual 192.168.1.100:80 is
virtual 192.168.1.100:23 is
virtual 192.168.1.100 is
The bind command is used to direct HTTP traffic for virtual server 192.168.1.100, port 80 to real server 192.168.1.1, port 80:
bind 192.168.1.100:80 192.168.1.1:80
The bind command is used to direct Telnet traffic for virtual server 192.168.1.100, port 23 to real server 192.168.1.2, port 23:
bind 192.168.1.100:23 192.168.1.2:23
The bind command is used to direct all other connections for virtual server 192.168.1.100 to real servers 192.168.1.3 and 192.168.1.4:
bind 192.168.1.100 192.168.1.3 192.168.1.4
The show bind command is used to view the association between the virtual and real servers:
LocalDirector(config)# show bind
Virtual Real
192.168.1.100:0:0(IS)
192.168.1.4:0(IS)
192.168.1.3:0(IS)
192.168.1.100:23:0(IS)
192.168.1.2:23(IS)
192.168.1.100:80:0(IS)
192.168.1.1:80(IS)
LocalDirector(config)#
With the maxconns command you can specify the maximum number of connections that each real server can have at one time. A server administrator can set the maximum connections to a level that avoids exceeding the capacity threshold of the server. Often, server administrators have a good idea of the load that a server can bear, and the maxconns command can be used to prevent a server from failing due to capacity overload. Clients requesting connections to a server farm with no available connections will receive a timeout message.
A higher percentage of connections can be directed to servers with increased performance. This is done by selecting the weighted option of the predictor command and setting values with the weight command.
Figure 4-9 shows four servers with varying performance indexes, maximum connections settings, and weight values set. In this example, a weight of 2 is assigned to the low-end server, which will send 13 percent of the connections to that server. This particular server cannot accept more than 500 simultaneous connections, so maxconns is set to 500. The same reasoning applies to the mid-range server and the two high-end servers.
A sample configuration follows:
The virtual command is used to identify 192.168.1.100 as a virtual server. The is (in-service) option indicates that it is in service:
virtual 192.168.1.100 is
The name command is used to associate a name to the virtual server:
name 192.168.1.100 domain
The real command is used to identify four real servers. The is (in-service) option indicates that they are in service:
real 192.168.1.1 is
real 192.168.1.2 is
real 192.168.1.3 is
real 192.168.1.4 is
The name command is used to associate names to the real servers:
name 192.168.1.1 low-end
name 192.168.1.2 mid-range
name 192.168.1.3 high-end1
name 192.168.1.4 high-end2
The bind command is used to direct traffic for virtual server Domain to real servers Low-end, Mid-range, High-end1, and High-end2:
bind domain low-end mid-range high-end1 high-end2
The predictor command is used to set load balancing to the weighted option:
predictor domain weighted
The weight command is used to assign weight values to each of the real servers:
weight low-end 2
weight mid-range 3
weight high-end1 5
weight high-end2 5
The maxconns command is used to limit the number of connections that each real server can accept:
maxconns low-end 500
maxconns mid-range 1000
maxconns high-end1 2000
maxconns high-end2 2000
The show bind command is used to view the association between the virtual and real servers:
ld(config) 1# show bind
Virtual Real
domain:0:0(IS)
high-end2:0(IS)
high-end1:0(IS)
mid-range:0(IS)
low-end:0(IS)
The show weight command is used to view the weight values assigned to the real servers:
ld(config) 2# show weight
Machine Weight
high-end1:0 5
mid-range:0 3
low-end:0 2
high-end2:0 5
For real servers, a backup is used if the real server is failed or out-of-service. For a virtual server, a backup is used if all real servers (and their backups) bound to the virtual server are failed or out-of-service. If the virtual server itself is out-of-service, a TCP RST will be sent to the client requesting the connection.
When the server being backed up returns to service, connections are no longer directed to the backup server and they are sent according to the LocalDirector configuration.
You can back up real servers with virtual addresses, and you can back up virtual servers with a real server. You can use a backup server when the real or virtual server is not in service (for example, it is failed or out of service). Note that if the backup server itself is not available, LocalDirector will not check the backup server's backup. The backup feature only checks one level.
The following example shows a virtual server backing up another virtual server. If real servers 1.1.1.2 and 1.1.1.3 fail (thus failing virtual 10.10.10.10), the real servers bound to virtual 10.10.10.20 will be used instead:
virtual 10.10.10.10
real 1.1.1.2
real 1.1.1.3
bind 10.10.10.10 1.1.1.2 1.1.1.3
virtual 10.10.10.20
real 1.1.1.4
real 1.1.1.5
real 1.1.1.6
bind 10.10.10.20 1.1.1.4 1.1.1.5 1.1.1.6
backup 10.10.10.10 10.10.10.20
In the following example, real server 1.1.1.4 is backing up the two real servers bound to virtual server 10.10.10.10:
virtual 10.10.10.10
real 1.1.1.2
real 1.1.1.3
bind 10.10.10.10 1.1.1.2 1.1.1.3
real 1.1.1.4
backup 10.10.10.10 1.1.1.4
The same result could be achieved with the following configuration, where real server 1.1.1.4 backs up the two real servers directly, instead of backing up the virtual:
virtual 10.10.10.10
real 1.1.1.2
real 1.1.1.3
bind 10.10.10.10 1.1.1.2 1.1.1.3
real 1.1.1.4
backup 1.1.1.2 1.1.1.4
backup 1.1.1.3 1.1.1.4
The LocalDirector tracks connections and can detect when clients are requesting data and the server is not responding with data. If a server's DataIn Conns value exceeds the defined threshold and all other real servers bound to the virtual are at less than 80% of their DataIn capacity, the server will be failed. The DataIn Conns value is displayed by the show real command.
|
|