Manual Chapter : 3-DNS Administrator Guide v1.0.6: Load Balancing

Applies To:

Show Versions Show Versions

3-DNS Controller versions 1.x - 4.x

  • 1.0.6
Manual Chapter


5

Load Balancing



How does load balancing work?

Load balancing is handled on a per wide IP basis. When you select a load balancing mode for a given wide IP, you specify how 3DNS Controllers determine which virtual servers to use for connections.

To set a mode of load balancing for a given wide IP, edit the corresponding wideip statement in your 3DNS Controller configuration file.

You can make global load balancing changes using the globals statement in the 3DNS Controller configuration file.

See Chapter 7, Statements and Comments , for more information on all statements and sub-statements.

Load balancing modes

There are three types of load balancing modes: static, dynamic, and specialized.

Dynamic

Dynamic load balancing modes rely on the iQuery protocol to collect important performance information such as Round Trip Times (RTT), which calculates the time a local DNS takes to respond to a ping issued by a BIG/ip Controller, or Least Connections, which calculates the current number of current connections for virtual servers on BIG/ip Controllers.

Static

Static load balancing modes do not require network communications (other than ensuring server availability) and exhibit more predictable load distribution.

Static load balancing modes only use the iQuery protocol to collect server status to determine how connections are made. By incorporating server status into the name resolution and load balancing processes, the 3DNS Controller always sends requests to a live BIG/ip Controller or host machine (assuming that live BIG/ip Controllers or host machines are available). You can change this behavior by setting the globals sub-statement check_static_depends to no.

Both static and dynamic load balancing modes are available when monitoring virtual servers managed by BIG/ip Controllers. However, when monitoring virtual servers managed by other host machines, only the static load balancing modes are available.

Specialized

Specialized modes include the following:

  • Topology access control
  • Topology load balancing
  • E-commerce
  • Quality of service
  • Global availability

    Topology access control and e-commerce go beyond simple load balancing in that they let you fine tune how connections are distributed.

Dynamic modes

Dynamic load balancing modes use the iQuery protocol to collect the information that is used to determine how to direct client requests. When you configure a wide IP for a path-dependent dynamic load balancing mode such as Round Trip Times or Completion Rate, the 3DNS Controller instructs each BIG/ip Controller to collect path metrics for the local DNS. The 3DNS Controller requests path metrics from each BIG/ip Controller the first time a name resolution request is made by the local DNS, and thereafter on a periodic basis.

You can control how often the data is refreshed (the interval between updates) using the globals sub-statements get_path_data and path_ttl. Path metric collection does not occur during the name resolution process.

The 3DNS platform supports these dynamic load balancing modes:

  • Completion Rate
  • Least Connections
  • Packet Rate
  • Round Trip Times (RTT)

Completion Rate
Syntax: completion_rate

Figure 5.1 shows the 3DNS Controller using the Completion Rate load balancing mode. The Completion Rate mode selects a virtual server on the BIG/ip Controller which currently maintains the least number of dropped or timed out packets for transactions between itself and the local DNS.

Figure 5.1 Completion rate mode

Example syntax

 // Completion rate     
wideip {
address 192.168.101.60
port 80
name "cgi.wip.domain.com"
pool {
name "mypool"
type vsb
preferred completion_rate
address 192.168.101.60 // New York
address 192.168.102.60 // Los Angeles
address 192.168.103.60 // Tokyo
}
}

Figure 5.2 Example syntax for completion rate

Related globals sub-statements

timer_get_path_data

path_ttl

rtt_timeout

rtt_sample_count

rtt_packet_length

For information on these and all globals sub-statements, see The globals statement, on page 7-4 .

Least Connections
Syntax: leastconn

The Least Connections mode selects a virtual server on the BIG/ip Controller which currently maintains the least number of connections.

Example syntax

 // Least connections with ratio as an alternate     
wideip {
address 192.168.102.60
service "ftp"
name "ftp.wip.domain.com"
pool {
name "main_pool"
type vsb
preferred leastconn
alternate ratio
address 192.168.101.60 ratio 2 // New York
address 192.168.102.60 ratio 4 // Los Angeles
address 192.168.103.60 ratio 1 // Tokyo
}
}

Figure 5.3 Example syntax for least connections

Related globals sub-statements

timer_get_vs_data

vs_ttl

For information on these and all globals sub-statements, see The globals statement, on page 7-4 .

Packet Rate
Syntax: packet_rate

Figure 5.4 shows the 3DNS Controller using the Packet Rate load balancing mode. The Packet Rate mode selects a virtual server which corresponds to the BIG/ip Controller that is currently processing the least packets per second.

Figure 5.4 Packet rate mode

Example syntax

 // Packet rate     
wideip {
address 192.168.101.60
port 80
name "cgi.wip.domain.com"
pool {
name "mypool"
type vsb
preferred packet_rate
address 192.168.101.60 // New York
address 192.168.102.60 // Los Angeles
address 192.168.103.60 // Tokyo
}
}

Figure 5.5 Example syntax for packet rate

Related globals sub-statements


timer_get_bigip_data

bigip_ttl

For information on these and all globals sub-statements, see The globals statement, on page 7-4 .

Round Trip Times (RTT)
Syntax: rtt

Figure 5.6 shows the 3DNS Controller using the Round Trip Times load balancing mode. The Round Trip Times (RTT) mode selects the virtual server with the fastest measured round trip time using probes from the BIG/ip Controller to the client's local DNS.

Figure 5.6 Round Trip Times mode

In the top half of Figure 5.6 , the New York machine has the lowest score. As a result, the 3DNS Controller selects New York for connections until the round trip times are recalculated. After the data was refreshed, the Los Angeles machine had the lowest score, so subsequent requests were sent to Los Angeles.

Example syntax

 // Round trip time load balancing with topology    
// as alternate load balancing
wideip {
address 192.168.103.60
port 80
name "ntp.wip.domain.com"
pool {
name "poolA"
type vsb
preferred rtt
alternate topology
address 192.168.101.60 // New York
address 192.168.102.60 // Los Angeles
address 192.168.103.60 // Tokyo
}
}

Figure 5.7 Example syntax for round trip time

Related globals sub-statements

timer_get_path_data

path_ttl

rtt_timeout

rtt_sample_count

rtt_packet_length

For information on these and all globals sub-statements, see The globals statement, on page 7-4 .

Static modes

The 3DNS platform supports these static load balancing modes:

  • Random
  • Ratio
  • Round Robin
  • Null
  • Return to DNS

Random
Syntax: random

When you specify a Random load balancing mode, the 3DNS Controller selects a virtual server for the connection at random from the wide IP set of virtual servers.

Example syntax

 // Random     
wideip {
address 192.168.101.60
port 80
name "cgi.wip.domain.com"
pool {
name "mypool"
type vsb
preferred random
address 192.168.101.60 // New York
address 192.168.102.60 // Los Angeles
address 192.168.103.60 // Tokyo
}
}

Figure 5.8 Example syntax for random

Ratio
Syntax: ratio

Figure 5.9 shows the 3DNS Controller using the Ratio load balancing mode. The Ratio mode, also known as Weighted or Administrative Cost, is useful for sites that have servers of varying capabilities. You specify what proportion of connections should go to each virtual server. Over a long period of time, the number of requests resolved to each virtual server in the set is in proportion to the specified weights. This load balancing mode is similar to Round Robin, but with weights assigned to each server. The default ratio for all servers is 1.

Figure 5.9 Ratio mode

Example syntax

 // Least connections with ratio as an alternate     
wideip {
address 192.168.102.60
service "ftp"
name "ftp.wip.domain.com"
pool {
name "main_pool"
type vsb
preferred leastconn
alternate ratio
address 192.168.101.60 ratio 2 // New York
address 192.168.102.60 ratio 4 // Los Angeles
address 192.168.103.60 ratio 1 // Tokyo
}
}

Figure 5.10 Example syntax for ratio

Round Robin
Syntax: rr, round_robin

Figure 5.11 shows the 3DNS Controller using the Round Robin load balancing mode. The Round Robin mode distributes client requests in a circular and sequential pattern. Over a long period of time, the total number of connections for each virtual server is the same.

Figure 5.11 Round Robin mode

Example syntax

 wideip {     
address 192.168.102.60
service "ftp"
name "ftp.wip.domain.com"
pool {
name "main_pool"
type vsb
preferred rr
address 192.168.101.60 // New York
address 192.168.102.60 // Los Angeles
address 192.168.103.60 // Tokyo
}
}

Figure 5.12 Example syntax for round robin

Null
Syntax: null

Specifying the null load balancing mode causes the 3DNS Controller to bypass the current load balancing method. It forces the 3DNS Controller to use the next load balancing method, or to move on to the next available pool.

Return to DNS
Syntax: return_to_dns

The return to DNS mode returns the resolution request to DNS, preventing the 3DNS Controller from using the next load balancing method, or using the next available pool.

The following example shows both null and return to DNS.

Example syntax

 // Global availability pool load balancing between    
// bigip data centers with specialized use of
// preferred, alternate, and fallback load
// balancing methods null and return_to_dns.
wideip {
address 192.168.102.70
port 80
name "www.domain.com"
alias "home.domain.com"
ttl 120
pool_lbmode ga
pool {
name "Tokyo"
type vsb
ratio 1
preferred leastconn
alternate null
fallback return_to_dns
address 192.168.103.50 ratio 3
address 192.168.103.60 ratio 2
address 192.168.103.70 ratio 1
}
}

Figure 5.13 Example syntax for null and return to DNS

Specialized modes

This section describes the following specialized, or more advanced, load balancing modes:

  • Topology access control
  • Topology load balancing
  • E-commerce
  • Quality of service
  • Global availability

    Topology access control and e-commerce go beyond simple load balancing in that they let you fine tune how connections are distributed.

Topology-based access control

You can use topology-based access control to implement a form of wide-area IP filtering. Topology-based access control allows you to specify which data centers are acceptable for a given resolution request, based on the proximity of the data center's IP address to the requesting local DNS server's IP address.

Defining the topology statement

You insert the topology statement at the end of the wideip.conf file. The topology statement consists of three parameters, acl_threshold, limit_probes, and longest_match, followed by a list of records defining a network.

The syntax is as follows:

 topology {    
acl_threshold <1..4294967295>
limit_probes <yes | no>
longest_match <yes | no>
<server cidr> <LDNS cidr> <score>
}

Figure 5.14 Syntax for topology statement

Topology statement example

It is best to explain topology access control with an example. Suppose that your company maintains Spanish web sites. You have data centers in New York, Los Angeles, and Tokyo. You prefer that resolution requests made from clients located in North America are resolved by North American data centers. However, you don't mind if a few requests are sent to Tokyo when requests cannot be resolved in New York or Los Angeles.

However, because of cost issues, you do not want requests made from clients in South America to go to the New York data center. To achieve this, you can configure the topology statement as shown.



topology {

acl_threshold 1

limit_probes yes

longest_match yes



// Server LDNS Score



///////////////////////////

// North American LDNS's:

// 198.0.0.0/8

// 199.0.0.0/8



// North America Priority List

//

// 1. New York

// 2. L.A.

// 3. Tokyo



// New York

192.168.101.0/24 198.0.0.0/8 30

192.168.101.0/24 199.0.0.0/8 30



// Los Angeles

192.168.102.0/24 198.0.0.0/8 20

192.168.102.0/24 199.0.0.0/8 20



// Tokyo

192.168.103.0/24 198.0.0.0/8 10

192.168.103.0/24 199.0.0.0/8 10



///////////////////////////

// South American LDNS's:

// 200.0.0.0/8

// 201.0.0.0/8



// South America Priority List

//

// 1. Tokyo

// 2. L.A.

// (New York excluded by acl_threshold)



// Tokyo

192.168.103.0/24 200.0.0.0/8 30

192.168.103.0/24 201.0.0.0/8 30



// Los Angeles

192.168.102.0/24 200.0.0.0/8 20

192.168.102.0/24 201.0.0.0/8 20



// New York

192.168.101.0/24 200.0.0.0/8 0

192.168.101.0/24 201.0.0.0/8 0





///////////////////////////

// Wildcard List Record

//

// By default, if a list record is not found in the

// topology map for an LDNS, the score is assumed

// to be 0. By including the following "wildcard"

// list record, all other LDNS's (not North or

// South America as specified above) are assigned

// a score of 1 so the acl_threshold does not

// indicate that the virtual servers are down.



0.0.0.0/0 0.0.0.0/0 1



}

Understanding the list records

The record list records in the topology statement define a score for pairs of known local DNS servers and data centers. Essentially, each record defines two network endpoints in CIDR (Classless Interdomain Routing) format, and a score. The CIDR format consists of an IP address and a number n designating a subnet bitmask. The bitmask is made up of n ones followed by 32 - n zeros. For example, for n = 8, the bitmask is:



11111111000000000000000000000000

\______/\______________________/

8 ones 24 zeros

The first endpoint, A, corresponds to the IP address of a server (either a BIG/ip Controller or a host). The second endpoint, B, corresponds to the IP address of the local DNS. Suppose a local DNS, L, requests a name resolution from the 3DNS Controller, and the virtual server being considered as an answer is managed by a BIG/ip Controller, S. The list record that matches is the one where the following equation is TRUE:



((S & A-mask == A & A-mask) && (L & B-mask == B & B-mask))

Referring to the example topology statement above, say that the local DNS 198.0.0.0 requested name resolution for www.domain.com, and a virtual server in the vsb pool belonged to the BIG/ip Controller 192.168.101.0. In this scenario, the 3DNS Controller considers the first list record to be a match.

Understanding the topology score

Each list record includes a score, which is used both in topology-based load balancing, and in topology-based access control. If multiple list records in a topology statement have the exact same server IP/mask and local DNS IP/mask but have different scores, only the last record is declared valid. For example, the following:



192.168.101.0/24 198.0.0.0/24 6

192.168.101.0/8 198.0.0.0/8 1

192.168.101.0/24 198.0.0.0/24 89 <-- replaces 1st record

192.168.101.0/24 198.0.0.0/24 0 <-- replaces previous record

192.168.101.0/24 198.0.0.0/24 3 <-- replaces previous record

Is equivalent to:



192.168.101.0/8 198.0.0.0/8 1

192.168.101.0/24 198.0.0.0/24 3

Note: The term list-record (server, local DNS) refers to the longest matching record for the BIG/ip Controller or host IP address, and the local DNS IP address.

Using the longest match rule

The 3DNS Controller uses the same type of longest match rule that is commonly used by routers. If there are several IP/mask items that match a particular IP address, the 3DNS Controller selects the record that is most specific, and thus has the longest mask (n is the largest).

For example, 192.168.101.4 matches 192.168.101.4/0, 192.168.101.4/8, 192.168.101.4/13, 192.168.101.4/24, and 192.168.101.4/32, but the longest matching IP/mask is 192.168.101.4/32. When the longest_match parameter is set to yes (the default), the longest match rule is obeyed for local DNS IP addresses, and also for server IP addresses, when there are multiple matches for a server/local DNS combination. This means that for the virtual server 192.168.101.50 owned by BIG/ip Controller 192.168.101.40 and local DNS 198.0.0.40, the third list record is the longest match:



192.168.101.0/24 198.0.0.40/24 2

192.168.101.0/8 198.0.0.40/16 0

192.168.101.0/8 198.0.0.40/27 6 <-- Longest Match

192.168.101.0/16 198.0.0.0/24 7

192.168.101.0/32 198.0.0.0/24 3 <-- Second Longest Match

Although this is not how the search is implemented, consider that all the records matching the server and local DNS IP address are gathered into a set. The records in this set are sorted in descending order first by local DNS mask, and then by server mask. The highest record in the sorted set determines which is the shortest path between the client and a virtual server. For example, if the third list record in the above example is removed, then the first and fifth records tie for longest match on local DNS, but the fifth wins because it has the more specific server mask.

Implementing topology-based access control

Any server/local DNS matching a list record with a score below the acl_threshold is interpreted as if the virtual server were unavailable. For example, if a local DNS 198.0.0.0 requests a name resolution, any virtual server owned by BIG/ip Controller 192.168.101.0 is considered down for load balancing purposes due to the first list entry. This provides a hook for an administrator to set up access control to data centers based on local DNS IP address.

Using wildcard list records to explicitly allow or deny access to local DNS servers that do not match a specific list record

You may want to define a wildcard list record that you can use to prevent users from being locked out when access control is turned on (when the acl_threshold is set to a value greater than zero). If the 3DNS Controller compares the local DNS server's IP address to the specific list records but does not find a match, it can use a wildcard list record to determine how to handle the resolution request.

A wildcard list record is the last list record in the topology statement and uses the following syntax:



0.0.0.0/0 0.0.0.0/0 <score>

By using the subnet bitmask values 0 in the wildcard list record, this record will always be chosen last by the longest match rule.

The <score> parameter setting either allows or denies access, depending on whether its value is set greater than or less than the acl_threshold setting. A <score> value that is greater than or equal to the acl_threshold setting allows access. A <score> value that is less than the acl_threshold setting denies access.

If no wildcard list record is provided, the following is assumed:



0.0.0.0/0 0.0.0.0.0/0

Using access control to limit path probing

The limit_probes parameter specifies whether to apply access control to the probing of paths. If this parameter is set to yes, the 3DNS Controller requests a given BIG/ip Controller to probe only those local DNS servers that can connect to it according to the acl_threshold value and the topology map scores. In the example topology statement above, the 3DNS Controller would not send a local DNS 200.0.0.0 connection to the BIG/ip Controller 192.168.101.0 for probing, but would send it to the BIG/ip Controller 192.168.103.0.

Topology load balancing mode
Syntax: topology

The topology mode distributes connections based on the proximity of a local DNS to a particular data center. Proximity is determined by network IP addresses of the local DNS compared to that of the data centers, and not necessarily by geographical location.

Example syntax

 wideip {     
address 192.168.103.60
port 80
name "ntp.wip.domain.com"
pool {
name "poolA"
type vsb
preferred topology
alternate rtt
address 192.168.101.60 // New York
address 192.168.102.60 // Los Angeles
address 192.168.103.60 // Tokyo
}
}

Figure 5.15 Example syntax for topology

E-commerce

For the purposes of conducting business over the Internet, you can configure the wide IP statement so that connections are not sent to a given address unless all specified ports or services are available. To do so, use the wideip port_list sub-statement.

For example:

 wideip {     
address 192.168.101.70
port 80 // http
port_list 80 443 // e-commerce
name "ssl.wip.domain.com"
pool_lbmode rr
pool {
name "bigip_pool"
type vsb
ratio 2
preferred qos
alternate ratio
address 192.168.101.70 ratio 7
address 192.168.102.60 ratio 2
}

Figure 5.16 Syntax for e-commerce

In the above example, ports 80 and 443 must be available before connections are sent to the specified address. If one of the ports in the list is down, the 3DNS Controller will not send traffic to any of the ports defined in the list.

For each virtual server address in the pool, a virtual server must exist for each port in the port list. In the above example, the following virtual servers must exist:

192.168.101.70:80

192.168.101.70:443

192.168.102.60:80

192.168.102.60:443

Use of the port_list parameter is not restricted to e-commerce purposes; you can use port_list in any situation where you want multiple services to be available for resolving requests.

Quality of Service (QOS)
Syntax: qos

In essence, the QOS mode lets you define a custom load balancing mode. The Quality of Service (QOS) score is a user-definable metric that includes a configurable combination of the RTT, Completion Rate, Packet Rate, and Topology modes. The virtual server with the highest metric is used for the connection.

Use this equation to configure QOS:



A (1/packet rate) + B (1/rtt) + C (completion rate) + D (topology)

You specify the coefficients A, B, C, and D. You can set the coefficients on a global basis. You can also override global values for each wide IP by using a qos_coeff declaration in the wide IP definition. The following table shows the user-configurable values that correspond to the coefficients:

Coefficient Global Wide IP override for
qos_coeff {}
A qos_coeff_packet_rate packet_rate
B qos_coeff_rtt rtt
C qos_coeff_completion_rate completion_rate
D qos_coeff_topology topology

The global coefficient settings define default values for all wide IPs that use the QOS load balancing mode. Figure 5.17 shows sample default settings.

 globals {    
qos_coeff_rtt 20
qos_coeff_completion_rate 5
qos_coeff_packet_rate 3
qos_coeff_topology 0
}

Figure 5.17 Global settings

In a wide IP definition, you can override the global coefficient settings. Figure 5.18 displays a wide IP definition that uses overrides for the global settings shown in Figure 5.17 .

  //    

wideip {

address 192.168.101.50

service "http"

name "www.wip.domain.com"

qos_coeff {

rtt 21

completion_rate 7

packet_rate 5

topology 1

}



pool {

name "pool_1"

type vsb

ratio 2

preferred qos

address 192.168.101.50 ratio 2

address 192.168.102.50 ratio 1

address 192.168.103.50 ratio 1

}



pool {

name "pool_2"

type vsb

ratio 1

preferred rr

address 192.168.102.60 ratio 2

address 192.168.103.60 ratio 1

}

}

Figure 5.18 QOS coefficient settings that override the global default settings

Balancing QOS coefficients

Before you change QOS coefficients from their default values, note the following:

  1. The raw metrics for each coefficient are not on the same scale. For example, completion rate is measured in percentages while the packet rate is measured in packets per second.
  2. 3DNS Controller normalizes the raw metrics on the order of 0 to 10.

    As the QOS value is calculated, a high measurement for completion rate is good, because a high percentage of completed connections are being made, but a high value for packet rate is not desirable because you are trying to find a virtual server that is not overly taxed at the moment.

    The following table lists each coefficient, its scale, a likely upper limit for each, and whether a higher or lower value is more efficient.

    Coefficient How measured Example upper limit Higher or lower?
    Packet rate Packets per second 700 Lower
    Round trip times Microseconds 2,000,000 Lower
    Completion rate 0-100% 100% Higher
    Topology 0 (off) or 1 (on) N/A N/A
  3. You can adjust coefficients to emphasize one normalized metric over another.

    For example, by changing the coefficients to the values shown below, you are putting the most emphasis on round trip times:

     globals {    
    qos_coeff_rtt 100
    qos_coeff_completion_rate 20
    qos_coeff_packet_rate 50
    qos_coeff_topology 0
    }

    Figure 5.19 Balancing QOS coefficients to emphasize round trip time

    In the above example, if round trip times for two virtual servers are close, the virtual server with the best packet rate is chosen. If both round trip times and packet rates are close, the completion rate breaks the tie.

  4. If you need help in customizing a QOS equation, contact F5 technical support.

Global Availability
Syntax: global_availability, ga

Figure 5.20 shows the 3DNS Controller using the global availability load balancing mode. The global availability mode selects the first available virtual server in a wide IP definition. If that virtual server becomes unavailable, subsequent connections go to the next listed virtual server in the wide IP definition.

Figure 5.20 Global Availability mode

Example syntax

 // Global availability     
wideip {
address 192.168.101.60
port 80
name "cgi.wip.domain.com"
pool {
name "mypool"
type vsb
preferred ga
address 192.168.101.60 // New York
address 192.168.102.60 // Los Angeles
address 192.168.103.60 // Tokyo
}
}

Figure 5.21 Example syntax for global availability

Load balancing examples

The following examples show only a few of the ways different load balancing modes can be used to optimize performance of your network. Use these examples as a starting point for deciding how you want connections handled.

Configuring a standby data center

Using the global availability load balancing mode, you can configure one data center as your primary service and have several alternate services on standby. In the wideip statement, list the virtual servers in descending order of preference. The first available virtual server is chosen for each resolution request.

For example:

 wideip {     
address 192.168.101.60
port 80
name "www.wip.domain.com"
pool {
name "pool1"
type vsb
preferred ga
address 192.168.101.60
address 192.168.102.60
address 192.168.103.60
}
}

Figure 5.22 Configuring a standby data center

Configuring alternate modes

This section provides two examples of how you can use an alternate load balancing method.

Example A

This example uses the Round Trip Times as the preferred mode. If the preferred mode (round trip times) fails, the 3DNS Controller uses the alternate mode. In this example, global availability is the alternate mode. This means that if the preferred mode fails, the 3DNS Controller in this example chooses the first available virtual server from the list in the wideip statement.

 // From the New York wideip.conf     
wideip {
address 192.168.101.60
port 80
name "www.wip.domain.com"
pool {
name "poolA"
type vsb
preferred rtt
alternate ga
address 192.168.101.60 // New York
address 192.168.102.60 // Los Angeles
address 192.168.103.60 // Tokyo
}
}

Figure 5.23 Using alternate load balancing modes (New York wideip.conf)

To cause the 3DNS Controller in New York to fall back to a New York virtual server and the similar effect to take place on the 3DNS Controller in Los Angeles, the virtual servers nearest to the 3DNS Controller are listed first. One unique and important aspect of this type of configuration is that each 3DNS Controller maintains a different wideip.conf file, rather than working from a synchronized wideip.conf file.

 // From the Los Angeles wideip.conf     
wideip {
address 192.168.101.60
port 80
name "www.wip.domain.com"
pool {
name "poolB"
type vsb
preferred rtt
alternate ga
address 192.168.102.60 // Los Angeles
address 192.168.101.60 // New York
}
}

Figure 5.24 Using alternate load balancing modes (Los Angeles wideip.conf)

Example B

In this example, suppose you are releasing a new version of a software product and plan to distribute it via FTP. You decide to specify the Least Connections as the preferred mode to better guarantee a connection for customers attempting to download the software. You can select Ratio as the alternate mode with weights assigned to certain servers. For this example, assume that the Los Angeles server has the ability to process requests faster than the other servers. Because of this, you choose the Los Angeles server as the preferred virtual server twice as often as the New York server, and three times as often as Tokyo server.

 // Least connections with ratio as an alternate     
wideip {
address 192.168.102.60
service "ftp"
name "ftp.wip.domain.com"
pool {
name "main_pool"
type vsb
preferred leastconn
alternate ratio
address 192.168.101.60 ratio 2 // New York
address 192.168.102.60 ratio 4 // Los Angeles
address 192.168.103.60 ratio 1 // Tokyo
}
}

Figure 5.25 Using alternate load balancing modes

Using multiple resource pools

To help you address common issues, this section provides several examples that offer a variety of solutions.

Example A

In this example, suppose you are a network administrator of a large network. Your network includes a large number of Sendmail servers to help distribute the mail traffic. For example, you've configured one Sendmail server to serve the human resources department, another to serve the engineering group, and another to serve the sales staff. Some Sendmail servers are virtual servers managed by BIG/ip Controllers, while others are virtual servers managed by a host machine.

Maintaining this configuration is time-consuming, since you must configure each client workstation with the address of the appropriate Sendmail server. You must also decide how to deal with issues like disproportionate growth or traffic.

To resolve these problems, you can configure one Sendmail service to manage all the other Sendmail servers. You can configure a super service using the 3DNS Controller and all your individual Sendmail servers. This service load balances traffic across all of your Sendmail servers and sends connections to the fastest-performing server at any given time. This allows you, as the administrator, to configure all client workstations to use the same domain name.

 wideip {     
address 192.168.102.50
service "smtp"
name "mx.wip.domain.com"
pool_lbmode ratio
pool {
name "pool_1"
type vsb
ratio 3
preferred rtt
alternate random
address 192.168.101.50
address 192.168.102.50
address 192.168.103.50
}

pool {
name "pool_2"
type vsh
ratio 1
preferred ratio
address 192.168.104.50 ratio 2
address 192.168.105.50 ratio 1
}
}

Figure 5.26 Configuring one Sendmail service to manage all other Sendmail servers

Example B

The following example uses multiple resource pools to determine how to distribute connections among three data centers: New York, Los Angeles, and Tokyo. The administrator wants resolution requests that are made to the 3DNS Controller in New York to be resolved to virtual servers in the data center in New York. If the data center in New York fills up and becomes unavailable, the administrator wants to send those resolution requests to virtual servers in the data center in Los Angeles. If both the New York and Los Angeles data centers are full, the administrator wants to send resolution requests to virtual servers in the data center in Tokyo.

Note the use of the null and return to DNS load balancing modes. If requests cannot be resolved using the least connections load balancing mode, those requests are ultimately returned to DNS.

 wideip {     
address 192.168.102.70
port 80
name "www.domain.com"
alias "home.domain.com"
ttl 120
pool_lbmode ga
pool {
name "New York"
type vsb
ratio 2
preferred leastconn
alternate null
fallback null
address 192.168.101.50 ratio 2
address 192.168.101.60 ratio 1
address 192.168.101.70 ratio 1
}

Figure 5.27 Distributing connections among three data centers (continued on next page)

   pool {     
name "Los Angeles"
type vsb
ratio 1
preferred leastconn
alternate null
fallback null
address 192.168.102.50 ratio 3
address 192.168.102.60 ratio 2
address 192.168.102.70 ratio 1
}

pool {
name "Tokyo"
type vsb
ratio 1
preferred leastconn
alternate null
fallback return_to_dns
address 192.168.103.50 ratio 3
address 192.168.103.60 ratio 2
address 192.168.103.70 ratio 1
}
}

Figure 5.28 Distributing connections among three data centers (continued from previous page)

The pool_lbmode set at the top of the wideip statement determines how the connection requests are balanced among the three resource pools (New York, Los Angeles, and Tokyo). The 3DNS Controller first tries to resolve requests using the preferred mode. If the preferred mode fails, the 3DNS Controller tries the alternate mode. If the alternate mode fails, the 3DNS Controller tries the fallback mode. If all three modes fail, the 3DNS Controller returns the request to DNS.

Note that in the resource pools above, the alternate and fallback load balancing methods are set to null. Specifying null mode prevents the 3DNS Controller from attempting to do load balancing for the given method. Instead, the 3DNS Controller either goes to the next load balancing method or, if it has cycled through all three load balancing methods for the pool, it then goes to the next resource pool. In this case, because the preferred load balancing method leastconn depends on the same metrics data as any static method for vsb virtual servers, it is more efficient to perform one load balancing attempt per pool, rather than trying three load balancing attempts before moving to the next available pool.

Also note that the fallback load balancing method in the Tokyo pool is set to return_to_dns, instead of being set to null. Because the wideip statement is set to use global availability for load balancing the pools, the 3DNS Controller always utilizes the Tokyo pool last, if at all. If the Tokyo pool fails, the 3DNS Controller returns the resolution request to DNS. This would happen regardless of how the fallback method is set in the Tokyo pool, but it is more efficient to set this last fallback to specifically use return_to_dns.

Configuring for e-commerce

In this example, the administrator is setting up a site for selling a product on the Internet. This site contains secure and non-secure areas. The non-secure area contains the product catalog and the secure area is for placing orders. The administrator can configure a wide IP so that clients are only sent to a virtual server if both the secure and non-secure areas are available.

The key entry here is port_list. The port_list entry specifies that requests can only be sent to virtual servers in this pool if ports 80 (non-secure area) and 443 (secure area) are available.

 wideip {     
address 192.168.101.70
port 80 // http
port_list 80 443 // e-commerce
name "ssl.wip.domain.com"
pool_lbmode rr
pool {
name "bigip_pool"
type vsb
ratio 2
preferred qos
alternate ratio
address 192.168.101.70 ratio 7
address 192.168.102.60 ratio 2
}

pool {
name "host_pool"
type vsh
ratio 1
preferred ratio
address 192.168.104.50 ratio 2
address 192.168.105.60 ratio 1
}
}

Figure 5.29 Configuring for e-commerce