Applies To:

Show Versions Show Versions

Manual Chapter: GTM Load Balancing
Manual Chapter
Table of Contents   |   Next Chapter >>

Introducing the Global Traffic Manager

BIG-IP® Global Traffic Manager™ (GTM™) is a system that monitors the availability and performance of global resources and uses that information to manage network traffic patterns. BIG-IP GTM uses load balancing algorithms, topology-based routing, and iRules® to control and distribute traffic according to specific policies.

About global server load balancing

BIG-IP® Global Traffic Manager™ (GTM™) provides tiered global server load balancing (GSLB). BIG-IP GTM distributes DNS name resolution requests, first to the best available pool in a wide IP, and then to the best available virtual server within that pool. GTM selects the best available resource using either a static or a dynamic load balancing method. Using a static load balancing method, BIG-IP GTM selects a resource based on a pre-defined pattern. Using a dynamic load balancing method, BIG-IP GTM selects a resource based on current performance metrics collected by the big3d agents running in each data center.

Static load balancing methods

This table describes the static load balancing methods available in BIG-IP Global Traffic Manager (GTM).

Name Description Recommended Use Wide IP Load Balancing Preferred Method Alternate Method Fallback Method
Drop Packet BIG-IP GTM drops the DNS request. Use Drop Packet for the Alternate load balancing method when you want to ensure that GTM does not offer in a response a virtual server that is potentially unavailable. No Yes Yes Yes
Fallback IP BIG-IP GTM distributes DNS name resolution requests to a virtual server that you specify. This virtual server is not monitored for availability. Use Fallback IP for the fallback load balancing method when you want GTM to return a disaster recovery site when the preferred and alternate load balancing methods do not return an available virtual server. No No No Yes
Global Availability BIG-IP GTM distributes DNS name resolution requests to the first available virtual server in a pool. BIG-IP GTM starts at the top of a manually configured list of virtual servers and sends requests to the first available virtual server in the list. Only when the virtual server becomes unavailable does BIG-IP GTM send requests to the next virtual server in the list. Over time, the first virtual server in the list receives the most requests and the last virtual server in the list receives the least requests. Use Global Availability when you have specific virtual servers that you want to handle most of the requests. Yes Yes Yes Yes
None BIG-IP GTM distributes DNS name resolution requests skipping either the next available pool in a multiple pool configuration or the current load balancing method. If all pools are unavailable, BIG-IP GTM returns an aggregate of the IP addresses of all the virtual servers in the pool using BIND. Use None for the alternate and fallback methods when you want to limit each pool to a single load balancing method. If the preferred load balancing method fails, GTM offers the next pool in a load balancing response. No No Yes Yes
Ratio BIG-IP GTM distributes DNS name resolution requests among the virtual servers in a pool or among pools in a multiple pool configuration using weighted round robin, a load balancing pattern in which requests are distributed among several resources based on a priority level or weight assigned to each resource. Use Ratio when you want to send twice as many connections to a fast server and half as many connections to a slow server. Yes Yes Yes Yes
Return to DNS BIG-IP GTM immediately distributes DNS name resolution requests to an LDNS for resolution. Use Return to DNS when you want to temporarily remove a pool from service. You can also use Return to DNS when you want to limit a pool in a single pool configuration to only one or two load balancing attempts. No Yes Yes Yes
Round Robin BIG-IP GTM distributes DNS name resolution requests in a circular and sequential pattern among the virtual servers in a pool. Over time each virtual server receives an equal number of requests. Use Round Robin when you want to distribute requests equally among all virtual servers in a pool. Yes Yes Yes Yes
Static Persist BIG-IP GTM distributes DNS name resolution requests to the first available virtual server in a pool using the persist mask with the source IP address of the LDNS and a hash algorithm to determine the order of the virtual servers in the list. This hash algorithm orders the virtual servers in the list differently for each LDNS that is passing traffic to the system taking into account the specified CIDR of the LDNS. Each LDNS (and thus each client) generally resolves to the same virtual server; however, when the selected virtual server becomes unavailable, BIG-IP GTM sends requests to another virtual server until the original virtual server becomes available. Then BIG-IP GTM again resolves requests to that virtual server. Use Static Persist when you want requests from a specific LDNS to resolve to a specific virtual server. No Yes Yes Yes
Topology BIG-IP GTM distributes DNS name resolution requests using proximity-based load balancing. BIG-IP GTM determines the proximity of the resource by comparing location information derived from the DNS message to the topology records in a topology statement you have configured. Use Topology when you want to send requests from a client in a particular geographic region to a data center or server located in that region. Yes Yes Yes Yes

Dynamic load balancing methods

This table describes the dynamic load balancing methods available in BIG-IP Global Traffic Manager (GTM).

Name Description Wide IP load balancing Preferred method Alternate method Fallback method
Completion Rate BIG-IP GTM distributes DNS name resolution requests to the virtual server that currently maintains the least number of dropped or timed-out packets during a transaction between a data center and the client's LDNS. No Yes No Yes
CPU BIG-IP GTM distributes DNS name resolution requests to the virtual server that currently has the most CPU processing time available. No Yes No Yes
Hops BIG-IP GTM distributes DNS name resolution requests to a virtual server in the data center that has the fewest router hops from the client's LDNS. BIG-IP GTM uses the traceroute utility to track the number of router hops between a client's LDNS and each data center. No Yes No Yes
Kilobytes/Second BIG-IP GTM distributes DNS name resolution requests to the virtual server that is currently processing the fewest number of kilobytes per second. Use Kilobytes/Second only with virtual servers for which BIG-IP GTM can collect the kilobytes per second metric. No Yes No Yes
Least Connections BIG-IP GTM distributes DNS name resolution requests to virtual servers on BIG-IP Local Traffic Manager (LTM) that currently hosts the fewest connections. Use Least Connections only with LTM servers. No Yes No Yes
Packet Rate BIG-IP GTM distributes DNS name resolution requests to the virtual server that is currently processing the fewest number of packets per second. No Yes Yes Yes
Quality of Service BIG-IP GTM distributes DNS name resolution requests to virtual servers based on a score assigned to each virtual server that is calculated from current performance metrics. Use Quality of Service only when you have configured BIG-IP GTM to calculate an overall score for each virtual server based on performance metrics. No Yes No Yes
Round Trip Time BIG-IP GTM distributes DNS name resolution requests to the virtual server with the fastest measured round trip time between a data center and a client's LDNS. No Yes No Yes
Virtual Server Score BIG-IP GTM distributes DNS name resolution requests to virtual servers on LTM based on a user-defined ranking. Use Virtual Server Score only with LTM systems on which you have assigned scores to each virtual server. No Yes Yes Yes
Virtual Server Capacity BIG-IP GTM distributes DNS name resolution requests to virtual servers in a list that are weighted by the number of available virtual servers in the pool. The pool with the most available virtual servers is sent more requests; however, over time all the virtual servers in all the pools are sent requests. If more than one virtual server has the same weight, then BIG-IP GTM distributes DNS requests among those virtual servers using the round-robin load balancing method. No Yes Yes Yes

About load balancing and resource availability

BIG-IP® Global Traffic Manager™ (GTM™) load balances DNS name resolution requests to resources based on availability. A resource is available when it meets one or more pre-defined requirements. BIG-IP GTM uses three methods to determine resource availability: a dependency on another resource, limit settings, or a set of values returned by a monitor. When BIG-IP GTM considers a resource unavailable, BIG-IP GTM attempts to select the next resource based on the current load balancing method.

About virtual server dependency

Within BIG-IP GTM, you can configure a virtual server to be available based on the availability of other virtual servers.

Consider the fictional company SiteRequest. One of the servers, serverMain, at the Tokyo data center has two virtual servers: vsContact, which points to the contacts page of the web site, and vsMail, which points to the mail system. The vsMail virtual server is in the Dependency List of the vsContact virtual server. As a result, BIG-IP GTM considers the vsContact virtual server available only if the vsMail virtual server is also available.

Configuring virtual server availability to be dependent on the status of other virtual servers

Ensure that multiple virtual servers are configured on the server. Determine the virtual servers upon which you want the availability of a virtual server to be dependent.
Configure a virtual server to be available based on the availability of other virtual servers by configuring a Dependency List for the virtual server.
  1. On the Main tab, click Global Traffic > Servers. The Server List screen opens.
  2. In the Server List, click a server name. The server settings and values display.
  3. On the menu bar, click Virtual Servers. A list of the virtual servers configured on the server displays.
  4. In the Virtual Servers list, click a virtual server name. The virtual server settings and values display.
  5. From the Configuration list, select Advanced. Additional controls display on the screen.
  6. In the Dependency List area, from the Virtual Servers list, select each virtual server on which you want the virtual server to be dependent, and then click Add. The virtual servers display in the list as you add them.
  7. Click Finished.
The virtual server is now available only when the virtual servers on the dependency list are also available.

Limit settings for resource availability

This table describes the limit settings BIG-IP Global Traffic Manager (GTM) uses to determine resource availability. A limit setting is a threshold for a statistic associated with a system.

Limit setting Server-level Pool-level Virtual Server-level BIG-IP Systems Other Load Balancers Hosts
Maximum allowable throughput in bits per second Y Y Y Y Y Y
Packets Y Y Y Y Y Y
Current connections Y Y Y Y Y Y
Connection N N Y Y N N
CPU Y N N N Y Y
Memory Y N N N Y Y

About wide IP-level load balancing

BIG-IP® Global Traffic Manager™ (GTM™) selects pools based on the order in which they are listed in a wide IP. When you organize pools in conjunction with the Global Availability, Ratio, Round Robin, and Topology load balancing methods, consider the order in which the pools are listed in the Pool List.

The Global Availability load balancing method instructs BIG-IP GTM to select the first pool in the wide IP pool list until it becomes unavailable, and then to select the next pool in the list until the first pool becomes available again. This ensures that the most robust pool receives DNS name resolution requests, while the other pools act as backups in case the primary pool becomes unavailable.

About the Global Availability load balancing method

The Global Availability load balancing method distributes DNS name resolution requests based on the order of resources in a list. Using global availability, BIG-IP® GTM™ sends a request to the first available pool in the list of pools in a wide IP, or the first available virtual server in a list of virtual servers in a pool. Only when the resource becomes unavailable does BIG-IP GTM send requests to the next resource in the list. Over time, the first resource in the list receives the most requests and the last resource in the list receives the least requests.

Testing global server load balancing without verifying availability of virtual servers

You can configure BIG-IP GTM load balancing in a staging environment to load balance DNS name resolution requests to virtual servers without verifying the availability of the virtual servers.
  1. On the Main tab, click System > Configuration > Global Traffic > Load Balancing. The Load Balancing configuration screen opens.
  2. Deselect the Verify Virtual Server Availability check box.
  3. Click Update.

About the Ratio load balancing method

The Ratio load balancing method distributes DNS name resolution requests among the virtual servers in a pool or among pools in a multiple pool configuration using weighted round robin, a load balancing pattern in which requests are distributed among several resources based on a priority level or weight assigned to each resource.

Using the Ratio method, you can configure BIG-IP GTM to send twice as many connections to a fast, new server, and half as many connections to an older, slower server.

About wide IPs and weighting pools for the Ratio load balancing method

When you configure a wide IP to use the Ratio load balancing method, BIG-IP®GTM™ load balances DNS name resolution requests across the pools in the wide IP based on the weight assigned to each pool. BIG-IP GTM uses pool weight as a percentage of the total of the weights of all the pools in the wide IP to determine the frequency at which a pool receives connection requests.

Consider the fictional company SiteRequest, where the wide IP www.siterequest.com contains three pools, with the following weight assignments:
  • Pool 1: weight 50
  • Pool 2: weight 25
  • Pool 3: weight 25
Each time GTM selects this wide IP, it load balances DNS name resolution requests across all three pools. Over time, the load balancing statistics for this wide IP appear as follows:
  • Pool 1: selected 50 percent of the time
  • Pool 2: selected 25 percent of the time
  • Pool 3: selected 25 percent of the time

About pools and weighting pool members for the Ratio load balancing method

When you configure a pool to use the Ratio load balancing method, the Global Traffic Manager™ load balances requests across the pool members based on the weight assigned to each pool member (virtual server). The system uses pool member weight as a percentage of the total of the weights of all the members assigned to the pool to determine the frequency at which a pool member receives connection requests.

Consider the fictional company SiteRequest, where the wide IP www.siterequest.com contains a pool named poolMain. This pool contains three members, with the following weight assignments:
  • Virtual Server 1: weight 50
  • Virtual Server 2: weight 25
  • Virtual Server 3: weight 25
Each time the Global Traffic Manager selects this pool, it load balances across all three members. Over time, the load balancing statistics for this pool appear as follows:
  • Virtual Server 1: selected 50 percent of the time
  • Virtual Server 2: selected 25 percent of the time
  • Virtual Server 3: selected 25 percent of the time

About the Round Robin load balancing method

The Round Robin load balancing method distributes DNS name resolution requests in a circular and sequential pattern among the virtual servers in a pool. Over time, each virtual server receives an equal number of connections.

About the Topology load balancing method

The Topology load balancing method distributes DNS name resolution requests based on the proximity of the client's LDNS to the data center housing the resource that responds to the request. BIG-IP GTM determines the proximity of the resources by comparing the location information in the DNS request to a topology statement in the BIG-IP GTM configuration file that reflects the location of the resources.

Using the Topology method, BIG-IP GTM directs DNS name resolution requests from a client in a specific geographic region to the data center or server within that same region.

Configuring Topology load balancing at the wide IP-level

When you configure BIG-IP GTM for Topology load balancing at the wide IP-level, the system load balances connection requests to the pools that are associated with the wide IP. This configuration routes connection requests to the data center that is closest to the client making the request, and then uses another load balancing mode to route these connections among the resources in that data center.

Important: When you configure Topology load balancing at the wide IP-level to route connections to a specific data center, you must create pools that have all of their members in the same data center.
Example of Topology load balancing at the wide IP-level
The following illustration shows siterequest.net configured for Topology load balancing at the wide IP-level. All connection requests from a local domain name server (LDNS) in South America with an IP address of 10.0.0.1 are directed to Pool2 in SouthAmericaDC. All connection requests from an LDNS in North America with an IP address of 11.0.0.1 are directed to Pool1 in NorthAmericaDC. In this example, BIG-IP GTM selects a pool to which to direct a connection based on topology records that match an LDNS (request source) to a pool (destination). How the system distributes the connections to the members is based on the load balancing mode that you set for each pool.
Topology load balancing at the wide IP-level Topology load balancing at the wide IP-level
Example topology records for wide IP-level load balancing
The following illustration shows the topology records that the Site Request administrator created. Based on these records, when a connection request comes in from the LDNS with an IP address of 10.0.0.1, BIG-IP GTM assigns a weight of 100 to Pool2 and routes the request to Pool2 . When a connection request comes in from the LDNS with an IP address of 11.0.0.1, BIG-IP GTM assigns a weight of 100 to Pool1 and routes the request to Pool1.
Example topology records for wide IP-level load balancing Example topology records for wide IP-level load balancing
Configuring a wide IP for Topology load balancing
Ensure that at least two pools are associated with the wide IP that you are configuring for Topology load balancing.
Use the Topology load balancing mode to distribute DNS name resolution requests among the pools in a wide IP, based on the geographic location of the client making the request and the server that handles the response.
  1. On the Main tab, click Global Traffic > Wide IPs. The Wide IPs List screen opens.
  2. Click the name of the wide IP you want to modify.
  3. On the menu bar, click Pools.
  4. In the Pools area, from the Load Balancing Method list, select Topology.
  5. Click Update.
Repeat this process for each wide IP that you want to configure for Topology load balancing.

Configuring Topology load balancing at the pool level

When you configure BIG-IP GTM for Topology load balancing at the pool level, the system load balances connection requests to the members of a pool. This configuration sets the weight of pool members in different data centers at different levels, and instructs the system to direct traffic to the pool members in a specific data center.

Example of Topology load balancing at the pool-level
The following illustration shows siterequest.net configured for Topology load balancing at the pool level with all connection requests being directed from an LDNS with an IP address of 10.0.0.1 to pool members that are located in the SouthAmericaDC, , and all connection requests being directed from an LDNS with an IP address of 10.1.0.0 to pool members that are located in the NorthAmericaDC. In this example, BIG-IP GTM selects a pool member to which to direct a request based on topology records that match a specific LDNS (request source) to a specific virtual server (destination).
Topology load balancing at the pool level Topology load balancing at the pool level
Example topology records for pool-level load balancing
The following screen shows the topology records that the Site Request administrator created. Based on these records, when a connection request comes in from the LDNS with an IP address of 10.0.0.1, BIG-IP GTM assigns a weight of 100 to SouthAmericaDC and routes the request to SouthAmericaDC. When a connection request comes in from the LDNS with an IP address of 10.1.0.0, BIG-IP GTM assigns a weight of 100 to NorthAmericaDC and routes the request to NorthAmericaDC.
Topology record that the Global Traffic Manager uses to direct these connection     requestsExample topology records for pool level load balancing
Configuring a pool for Topology load balancing
You can use the Topology load balancing method to distribute DNS name resolution requests among the pools in a wide IP, based on the geographic location of the client making the request and the server that handles the response.
  1. On the Main tab, click Global Traffic > Pools. The Pools list screen opens.
  2. Click the name of the pool to which you want to assign topology-based load balancing.
  3. On the menu bar, click Members.
  4. In the Load Balancing Method area, from the Preferred list, select Topology.
  5. Click Update.
Repeat this process for each member that you want to configure for Topology load balancing.

Configuring Topology load balancing at both the wide IP and pool levels

When you configure BIG-IP GTM for Topology load balancing at both the wide IP and pool levels, the system first load balances the requests to a pool assigned to the wide IP and then to a member of the pool.

Example of Topology load balancing at both the wide IP and pool-levels
The following illustration shows siterequest.net configured for Topology load balancing at both the wide IP and pool levels with connection requests being directed from an LDNS in Buenos Aires to the SpanishPool in the SouthAmericaDC. In this example, BIG-IP GTM selects a pool to which to direct a connection based on topology records that match an LDNS (request source) to a pool (destination). How the system distributes the connections to the members of SpanishPool is based on topology records that match a specific LDNS (request source) to a specific virtual server (destination).
Topology load balancing at the wide IP and pool levels Topology load balancing at the wide IP and pool levels
Example topology records for wide IP and pool-level load balancing
The following screen shows the topology records that the Site Request administrator created. Based on these records, when a connection request comes in from an LDNS in Buenos Aires, BIG-IP GTM assigns a weight of 100 to SpanishPool and the SouthAmericaDC. The system routes the request to the SpanishPool pool members that are in SouthAmericaDC.
Topology records that the Global Traffic Manager uses to direct these connection requests Example topology records for wide IP and pool-level load balancing

Understanding topology records

A topology record is a set of characteristics that maps the origin of a connection request to a specific destination. Topology records instruct BIG-IP GTM where to route connection requests when Topology load balancing is enabled. The following illustration shows the Topology record creation screen in the Configuration utility.

Topology record creation screenTopology record creation screen

Each topology record contains the following elements:

  • A request source statement that defines the origin of a connection request.
  • A destination statement that defines the resource to which BIG-IP GTM directs the connection request.
  • A weight (topology score) that the system assigns to a server object during the load balancing process.
Understanding how the system sorts and prioritizes topology records
By default, each time the system configuration is loaded, theBIG-IP® system automatically sorts topology records into an ordered list using the longest match sorting algorithm. The system sorts the records in this manner:
  • First, by the request source statement (LDNS or right-side of the record).
  • If the LDNS match priority is the same in multiple topology records, the system sorts these records by the server match priority (server object or left-side of the record).

The system sorts both the LDNS and server objects using this priority from highest to lowest:

  • IP subnet in CIDR format (the system sorts the most specific IP subnet to the top of the list); for example, these IP subnets are ordered as follows: 10.15.1.0/24, 10.15.0.0/16, 10.0.0.0/8
  • Data center
  • Pool
  • Region (customized collection of topologies that you create)
  • ISP
  • State
  • Country
  • Continent
  • Server negation (record that excludes a server object)
  • LDNS negation (record that excludes an LDNS)
  • Wildcard records (the system sorts records that include a wildcard to the bottom of the list, because these records are the least specific)
Understanding user-defined regions

A region is a customized collection of topologies that defines a specific geographical location that has meaning for your network. To further refine the Topology load balancing capabilities of the BIG-IP system, you can create regions. For example, you can create a custom region called Scandinavia that includes Denmark, Iceland, Finland, Norway, and Sweden. After you create a region, you can create a topology record based on that region. The system tests region membership for CIDR-based region members using a (log N) route lookup-based method; for topology record matches, the system uses a linear (N squared) search-based method.

Thhis table describes how the use of topology regions improves the load balancing performance of the BIG-IP system.

Faster Load Balancing Configuration Slower Load Balancing Configuration
2 data centers 2 data centers
1000 pool members in each data center 1000 pool members in each data center
2 regions with 5000 CIDR entries each  
2 topology records: 10,000 topology records:
1 entry routes all requests from region1 to data center1 5000 CIDR topology records route requests to data center1
1 entry routes all requests from region2 to data center2 5000 CIDR topology records route requests to data center2
About topology longest match

When Topology load balancing is enabled, BIG-IP® GTM™ load balances connection requests using the longest match sorting algorithm by default. When a connection request comes into the system the load balancing decision is based on this process:

  • For each server object that BIG-IP GTM load balances connection requests to, the system iterates through an ordered list of topology records from first to last and assigns a weight to every server object.
  • The system locates the first topology record that most specifically matches both the LDNS and the server object and assigns the topology score in the record to the server object.
  • If the iteration through the list does not find a topology record that matches both the LDNS and the server object, then that server object is assigned a zero score.
  • BIG-IP GTM routes the connection request to the server object with the highest score.
  • When server objects have equal scores, the Global Traffic Manager distributes connection requests among those server objects in a round robin fashion.
Topology load balancing default behavior

To understand the default behavior when Topology load balancing is configured, consider this scenario: The company Site Request has internal and external customers. The IT department wants to route all connection requests from internal customers on the 10.15.0.0/16 IP subnet to the internal_customer_pool, and all connection requests from external customers on the 10.0.0.0/8 IP subnet to the external_customer_pool.

To do this the system administrator creates two topology records as shown in the figure. Note that the weights of the topology records are different. This instructs BIG-IP GTM to route the connection requests correctly. When a connection request arrives from a source with an IP address of 10.15.65.8, BIG-IP GTM assigns a weight of 200 to the internal_customer_pool and a weight of 10 to the >external_customer_poo. This is because the LDNS 10.15.65.8 matches both request sources 10.15.0.0/16 and 10.0.0.0/8. However, the system load balances the request to the internal_customer_pool, because the weight assigned to that server object is higher.

Example topology records Example topology records
Creating a topology record
Before you create topology records, it is essential that you understand how the system sorts the topology record list, and then uses the ordered list to load balance connection requests.
You can create topology records that instruct the system where to route connection requests when Topology load balancing is enabled.
Tip: BIG-IP is much more efficient when using the region topology for load balancing, because when setting load balancing scores for server objects the system iterates through the topology records in order from first to last.
  1. On the Main tab, click Global Traffic > Topology.
  2. Click Create. The new record screen opens.
  3. To create a request source statement, use the Request Source settings:
    1. Select an origin type from the first list.
    2. Select an operator, either is or is not.
    3. Define the criteria for the request source statement based on the request source type you selected.
  4. To create a request source statement, use the Destination settings:
    1. Select a destination type from the first list.
    2. Select an operator, either is or is not.
    3. Define the criteria for the destination statement based on the destination type you selected.
  5. In the Weight box, specify the priority this record has over other topology records.
  6. Click Create.
Deleting a topology record
Delete existing topology records as your network changes. For example, when you add a new data center to your network, the topology records that BIG-IP® GTM™ uses to distribute DNS name resolution requests can become obsolete, requiring deletion.
Note: You cannot modify topology records; you can delete records and create new ones that meet your needs.
  1. On the Main tab, click Global Traffic > Topology.
  2. Select the topology record that you want to remove from the topology records list by selecting the corresponding Select check box.
  3. Click Delete. A confirmation screen appears.
  4. Click Delete.

About IP geolocation data

The BIG-IP® Global Traffic Manager™ (BIG-IP GTM) uses an IP geolocation database to determine the origin of connection requests. The database that comes with BIG-IP GTM provides geolocation data for IPv6 addresses at the continent and country levels. It also provides geolocation data for IPv4 addresses at the continent, country, state, ISP, and organization levels. The state-level data is worldwide, and thus includes designations in other countries that correspond to the U.S. state-level in the geolocation hierarchy, such as, provinces in Canada.

Note: If you require geolocation data at the city-level, contact your F5 Networks sales representative to purchase additional database files.
Downloading and installing updates to the IP geolocation data
You can download a monthly update to the IP geolocation database from F5 Networks®. BIG-IP GTM uses the IP geolocation database to determine the origin of connection requests.
  1. Log in to the F5 Networks customer web site at http://downloads.f5.com, and click Find a Download.
  2. In the F5 Product Family column, find BIG-IP, and then in the Product Line column, click BIG-IP v10.x.
  3. Select a version from the list preceding the table.
  4. In the Name column, click GeolocationUpdates.
  5. Click I Accept to accept the license.
  6. In the Filename column, click the name of the most recent compressed file that you want to download.
  7. In the Ready to Download table, click the download method that you want to use.
  8. In the dialog box, click OK.
  9. Select the directory in which you want to save the compressed file, and then decompress the file to save the RPM files on the system.
  10. Install and load one of the RPM files using the following command, where the path and file name are case-sensitive: geoip_update_data -f </path to RPM file and file name >. The system installs and loads the specified database file.
  11. Repeat step 10 for each of the RPM files that you saved to the system in step 9.
You can access the ISP and organization-level geolocation data for IPv4 addresses only using the iRules® whereis command.
Reloading default geolocation data using the Configuration utility
Before you reload the default geolocation data, delete the RPM files that are in the /shared/GeoIP directory.
To uninstall an update to the IP geolocation database, reload the default geolocation database files using the Configuration utility.
  1. At the BASH prompt, to query the RPM database to determine what geolocation data is installed, run this command: rpm -qa --dbpath /shared/lib/rpm/ The system returns a list of RPMs, for example: geoip-data-ISP-1.0.0-20110203.61.0, geoip-data-Region2-1.0.0-20110203.61.0, and geoip-data-Org-1.0.0-20110203.61.0.
  2. To uninstall the RPMs, run this command for each RPM in the list: rpm -e --dbpath /shared/lib/rpm/ <name of file>, for example, to uninstall geoip-data-ISP-1.0.0-20110203.61.0, run this command: rpm -e --dbpath /shared/lib/rpm/ geoip-data-ISP-1.0.0-20110203.61.0
  3. To remove the symlink in the /shared/GeoIP directory, run this command: rm -f /shared/GeoIP/*
  4. Log on to the Configuration utility.
  5. On the Main tab, click System > Configuration.
  6. In the Geolocation area, click Reload in the Operations setting. The system reloads the default geolocation database files that are stored in /usr/share/GeoIP.
Reloading default geolocation data using tmsh
To uninstall an update to the IP geolocation database, delete the RPM files, and then reload the default geolocation database files using tmsh.
  1. At the BASH prompt, to query the RPM database to determine what geolocation data is installed, run this command: rpm -qa --dbpath /shared/lib/rpm/ The system returns a list of RPMs, for example: geoip-data-ISP-1.0.0-20110203.61.0, geoip-data-Region2-1.0.0-20110203.61.0, and geoip-data-Org-1.0.0-20110203.61.0.
  2. To uninstall the RPMs, run this command for each RPM in the list: rpm -e --dbpath /shared/lib/rpm/ <name of file>, for example, to uninstall geoip-data-ISP-1.0.0-20110203.61.0, run this command: rpm -e --dbpath /shared/lib/rpm/ geoip-data-ISP-1.0.0-20110203.61.0
  3. To remove the symlink in the /shared/GeoIP directory, run this command: rm -f /shared/GeoIP/*
  4. Log on to tmsh.
  5. Run the command sequence: load / sys geoip The system reloads the default geolocation database files that are stored in /usr/share/GeoIP.

About pool-level load balancing

BIG-IP® Global Traffic Manager™ (GTM™) provides three tiers of pool-level load balancing to identify a virtual server to handle a DNS name resolution request.

Preferred Load Balancing Method
The first load balancing method BIG-IP GTM uses to return the IP address of a virtual server in response to a DNS name resolution request.
Note: The preferred method can be either static or dynamic.
Alternate Load Balancing Method
If the preferred load balancing method fails to return a valid resource in response to a DNS name resolution request, it is likely that BIG-IP GTM was unable to acquire the proper metrics to perform load balancing.
Note: The alternate method can be only static.
Fallback Load Balancing Method
If the alternate load balancing method fails to return a valid resource in response to a DNS name resolution request, BIG-IP GTM uses the fallback method. To ensure that BIG-IP GTM returns a response to a request, the fallback method ignores the availability status of a resource.
Note: The fallback method can be either static or dynamic.

If all of the configured load balancing methods fail to provide a valid resource in response to a DNS name resolution request, either the request fails or BIG-IP GTM uses the local BIND to resolve the request.

About the Drop Packet load balancing method

The Drop Packet load balancing method indicates that BIG-IP Global Traffic Manager (GTM) drops a DNS name resolution request. This load balancing method is most often selected for the Alternate load balancing method to ensure that BIG-IP GTM does note return an IP address for an unavailable resource.

About the Virtual Server Score load balancing method

The Virtual Server Score load balancing method distributes DNS name resolution requests to pool members (virtual servers) based on a user-defined ranking system.

Note: This method can be used only for distributing requests to pool members controlled by BIG-IP Local Traffic Manager (LTM) systems.

About the Virtual Server Capacity load balancing method

The Virtual Server Capacity load balancing method distributes DNS name resolution requests to pool members (virtual servers) based on a system-generated list of pool members (virtual servers) weighted by capacity. BIG-IP GTM selects the pool member with the greatest capacity most often, but over time, all pool members are returned in responses. When pool members have the same capacity, BIG-IP GTM uses the Round Robin method to select a pool member.

About the Round Trip Times load balancing method

The Round Trip Times load balancing method distributes DNS name resolution requests to the pool member (virtual server) with the fastest measured round trip time between a data center and a client's LDNS.

About the Packet Rate load balancing method

The Packet Rate load balancing method distributes DNS name resolution requests to the pool member (virtual server) that is currently processing the fewest number of packets per second.

About the Least Connections load balancing method

The Least Connections load balancing method distributes DNS name resolution requests to pool members (virtual servers) that are managed by load balancing servers, such as BIG-IP Local Traffic Manager (LTM). BIG-IP GTM selects a pool member that currently hosts the fewest connections.

About the Kilobyte/Second load balancing method

The Kilobyte/Second load balancing method distributes DNS name resolution requests to the pool member (virtual server) that is currently processing the fewest number of kilobytes per second.

Note: This method can be used only with servers for which BIG-IP GTM can collect the kilobytes per second metric.

About the Hops load balancing method

The Hops load balancing method distributes DNS name resolution requests based on the traceroute utility and tracks the number of intermediate system transitions (router hops) between a client's LDNS and each data center. BIG-IP GTM distributes requests to a pool member in the data center that is the fewest router hops from the LDNS.

About the Completion Rate load balancing method

The Completion Rate load balancing method distributes DNS name resolution requests to the pool member (virtual server) that currently maintains the least number of dropped or timed-out packets during a transaction between a pool member in a data center and the client's LDNS.

About the CPU load balancing method

The CPU load balancing method distributes DNS name resolution requests to the pool member (virtual server) that currently has the most CPU processing time available.

About the Return to DNS load balancing method

The Return to DNS load balancing method immediately returns DNS name resolution requests to the LDNS for resolution. When you use this load balancing method, for client queries, the BIG-iP system increments the Return to DNS statistics; otherwise, the system increments the Return from DNS statistics.

Use this method when you want to temporarily remove a pool from service or when you want to limit a pool, in a single pool configuration, to only one or two request attempts.

About the Static Persist load balancing method

The Static Persist load balancing method uses the persist mask with the source IP address of the LDNS in a deterministic algorithm to send requests to a specific pool member (virtual server). Using this method, BIG-IP GTM sends DNS name resolution requests to the first available pool member based on a hash algorithm that determines the order of the pool members. This algorithm orders the pool members differently for each LDNS that is sending requests to BIG-IP GTM taking into account the CIDR of the LDNS. As BIG-IP GTM distributes requests across all pool members, requests from each LDNS (and thus each client) are generally sent to the same pool member. When the selected pool member becomes unavailable, BIG-IP GTM sends requests to another pool member. When the original pool member becomes available again, BIG-IP GTM again sends request to that pool member.

About the Fallback IP load balancing method

The Fallback IP load balancing method distributes DNS name resolution requests to a specific user-specified IP address. This IP address is not monitored for availability. Use this load balancing method only for the Fallback IP method and specifically to provide a disaster recovery site.

Verifying the availability of virtual servers when using the fallback load balancing method

You can configure BIG-IP GTM to verify that a virtual server is up before returning the IP address of the virtual server in a response to a DNS name resolution request. Do this when the preferred and alternate load balancing methods assigned to a pool do not return a valid response and BIG-IP GTM begins to use the configured fallback load balancing method.
  1. On the Main tab, click System > Configuration > Global Traffic > Load Balancing. The Load Balancing configuration screen opens.
  2. Select the Respect Fallback Dependency check box.
  3. Click Update.

About the None load balancing method

The None load balancing method skips the current load balancing method, distributes DNS name resolution requests to the next available pool in a multi-pool configuration.

If the alternate load balancing method for a pool is None, BIG-IP GTM skips the alternate method and immediately tries the fallback method. If the fallback method is None, and there are multiple pools configured, BIG-IP GTM uses the next available pool. If all pools are unavailable, BIG-IP GTM returns an aggregate of the IP addresses of all pool members using BIND. Alternatively, when the preferred method for all pools is configured, but the alternate and fallback methods are set to None, if the preferred method fails, BIG-IP GTM uses the next available pool.

About the QoS load balancing method

The Quality of Service (QoS) dynamic load balancing method uses current performance metrics to calculate an overall QoS score for each pool member (virtual server). When load balancing DNS name resolution requests, BIG-IP GTM selects a virtual server with the best overall QoS score. If virtual servers have identical scores, BIG-IP GTM load balances connections to those virtual servers using the round robin method. If QoS scores cannot be determined, BIG-IP GTM load balances connections across all pool members using the round robin method.

Understanding the QoS equation

The equation for calculating the overall Quality of Service (QoS) score is:POOL_CONFIG->rtt * (GLOBALS->rtt / path->rtt) * 10 + POOL_CONFIG->hops * (GLOBALS->hops / path->hops) + POOL_CONFIG->hit_ratio * (path->hit_ratio / GLOBALS->hit_ration+ POOL_CONFIG->packet_rate * (GLOBALS->packet_rate / vs->packet_rate) * 100 + POOL_CONFIG->bps * (GLOBALS->bps / vs->bps) + POOL_CONFIG->topology * (topology_match->score / GLOBALS->topology) + POOL_CONFIG->vs_capacity * vs->cur_serv_cnt + POOL_CONFIG->vs_score * vs->cur_vs_score + POOL_CONFIG->lcs * vs->link->lcs * 10

Pool members (virtual servers) inherit the QoS settings from the pool. In the equation, the value of POOL_CONFIG->"setting name" can be found in the properties of a pool, the value of GLOBALS->"setting name" in the global BIG-IP GTM setting, and the value of path->"setting name" These are measured values that come from path metrics. If there are no path metrics, the system does not perform path metric calculations and computes the QoS score using the other calculations. vs->"field" These are measured values that come from measurements the system makes on virtual servers. If there are no measurements, the system does not perform these calculations and computes the QoS score using the other calculations. Each QoS coefficient, its scale, default value, upper limit, and whether a higher or lower value is more efficient are defined in the table.

Table 1. QoS coefficients defined
Coefficient Scale Default value Upper limit Is higher or lower value more efficient?
Round trip time (rtt) Microseconds 50 2,000,000 L
Completion rate (hit ratio) Percentage of successfully transferred packets (0-100%) 5 100% H
Hops Number of intermediate systems transitions 0 64 L
Packet rate Packets per second 1 700 L
bits/second Bits per second throughput 3 15000 L
Topology Score that defines network proximity by comparing server and LDNS IP addresses (0-232) 0 100 H
Virtual server capacity (vs capacity) Number of nodes up 0 20 H
Virtual server score (vs score) User-defined ranking of virtual servers 0 100 H
Link capacity (lcs) Based on the target dynamic ratio 30 2,000,000 H

About customizing the QoS equation

When you customize the QoS equation, consider these three concepts:
Scale
The raw metrics for the coefficients in the QoS equation are on different scales. For example, completion rate is measured in percentages, while packet rate is measured in packets per second.
Normalization
BIG-IP GTM normalizes the raw metrics to values in the range of 0 - 10.
Emphasis
You can adjust coefficients to emphasize one normalized metric over another.
When you customize the QoS equation configuration using the values in the table, if the completion rates for two virtual servers are close, the system chooses the virtual server with the best packet rate. If both the completion rates and the packet rates are close, the round trip time (RTT) breaks the tie. In this example, BIG-IP GTM does not use the metrics for topology, hops, link capacity, vs capacity, and kilobytes/second to determine how to distribute connections.
Note: You can set a value for either RTT or hops. If you set both, BIG-IP GTM incorporates the RTT and resets the hops to 0 (zero).
Coefficient Value
Round Trip Time 50
Hops 0
Topology 0
Completion Rate 5
Packet Rate 10
VS Capacity 0
Bits/second 35
Link Capacity 30
Virtual Server Score 10
Kilobytes/Second (KBPS) 3

Customizing the QoS equation for load balancing global traffic

Determine the pool to which you want to apply a customized QoS equation.
Customize the QoS equation to load balance the DNS name resolution requests the members of this pool handle.
  1. On the Main tab, click Global Traffic > Pools.
  2. Click the name of the pool for which you want to modify the QoS equation. The Pool Properties screen displays.
  3. On the menu bar, click Members. The Members Properties screen displays.
  4. Select Quality of Service from either the Preferred or Fallback list. The Quality of Service Weights area displays.
  5. Define the QoS coefficients for this pool.
  6. Click Update.

About dynamic ratio load balancing

When you use dynamic ratio load balancing, BIG-IP GTM treats dynamic load balancing values as ratios, and distributes DNS name resolution requests to the virtual servers in the pool in proportion to these ratios.

Consider a pool named primaryOne, which contains two virtual servers: memberOne and memberTwo. primaryOne is configured with the Preferred load balancing method set to Round Trip Time. BIG-IP GTM determines that the round trip time for memberOne is 50 microseconds and the round trip time for memberTwo is 100 microseconds. When the Dynamic Ratio setting on the primaryOne pool is disabled, BIG-IP GTM always sends DNS name resolution requests to memberOne, because that virtual server has the lowest round trip time value. When the Dynamic Ratio setting on the primaryOne pool is enabled, BIG-IP GTM treats the round trip time values as ratios and sends twice as many DNS name resolution requests to memberOne as it sends to memberTwo, because the round trip time for memberOne is twice as fast as the round trip time for memberTwo.

Distributing DNS requests based on weighted virtual servers

Determine the pool to which you want to apply the dynamic ratio feature.
Configure BIG-IP GTM to use dynamic load balancing values as ratios, and distribute DNS name resolution requests to virtual servers in a pool in proportion to these ratios.
  1. On the Main tab, click Global Traffic > Pools. The Pools list screen opens.
  2. Click the name of the pool that you want to modify.
  3. From the Configuration list, select Advanced.
  4. Select the Dynamic Ratio check box.
  5. Click Update.

Using the preferred load balancing method when metrics are unavailable

Configure BIG-IP GTM to use the preferred load balancing method assigned to a pool even when metrics for the pool are unavailable. BIG-IP GTM uses old metrics, rather than the alternate load balancing method assigned to the pool.
  1. On the Main tab, click System > Configuration > Global Traffic > Load Balancing. The Load Balancing configuration screen opens.
  2. Select the Ignore Path TTL check box.
  3. Click Update.
BIG-IP GTM uses path information gathered during metrics collection even if the time-to-live (TTL) value of that information has expired.

Configuring the resources in a pool for manual resume

Determine the pool to which you want to apply the manual resume feature.
When a virtual server goes offline, BIG-IP GTM proceeds to send DNS name resolution requests to other virtual servers, based on the current load balancing method. By default, when the virtual server becomes available again, BIG-IP GTM resumes sending requests to that resource. When you do not want BIG-IP GTM to resume to send requests to the virtual servers in a pool immediately after the resources become available, enable the manual resume feature on the pool.
  1. On the Main tab, click Global Traffic > Pools. The Pools list screen opens.
  2. Click the name of the pool that you want to modify.
  3. From the Configuration list, select Advanced.
  4. Select the Manual Resume check box.
  5. Click Update.
After a virtual server in this pool goes offline, you must manually enable the virtual server before BIG-IP GTM can resume sending requests to the virtual server.

Restoring availability of a pool member manually

Determine the virtual server that you want to manually enable.
When a virtual server in a pool that is configured for manual resume becomes available, you must manually enable the virtual server before BIG-IP GTM can begin sending DNS name resolution requests to the virtual server.
  1. On the Main tab, click Global Traffic > Pools. The Pools list screen opens.
  2. Click the name of the pool to which the virtual server you want to enable belongs.
  3. On the menu bar, click Members.
  4. Select the check box next to the virtual server that you want to enable, and then click Enable.
The virtual server is now available to receive DNS name resolution requests.
Table of Contents   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)