BIG-IP DNS 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 DNS 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 DNS considers a resource unavailable, BIG-IP DNS attempts to select the next resource based on the current load balancing method.
Within BIG-IP® DNS, you can configure a virtual server to be available based on the availability of other virtual servers.
This table describes the limit settings BIG-IP DNS 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|
BIG-IP® DNS 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 distributes DNS name resolution requests based on the order of resources in a list. Using global availability, BIG-IP® DNS sends a request to the first available resource in a list. Only when a resource becomes unavailable does BIG-IP DNS send requests to the next resource in the list. You can only select the next resource in the list if the Fallback load balancing method is set to None. Over time, the first resource in the list receives the most requests and the last resource in the list receives the least requests.
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.
When you configure a wide IP to use the Ratio load balancing method, BIG-IP®DNS load balances DNS name resolution requests across the pools in the wide IP based on the weight assigned to each pool. BIG-IP DNS 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.
When you configure a pool to use the Ratio load balancing method, BIG-IP® DNS, formerly Global Traffic Manager™ (GTM™), 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.
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.
BIG-IP® DNS provides three tiers of pool-level load balancing to identify a virtual server to handle a DNS name resolution request.
When the fallback method is set to Return to DNS, the response from BIND is processed the same as any other DNS packet. If the response from BIND matches a wide IP, the load balancing algorithm may use a downed pool. If the downed pool is not configured to select another pool based on availability of the pool members, you can select a downed pool. For this scenario, BIND is not used a second time.
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 DNS uses the local BIND to resolve the request.
The Drop Packet load balancing method indicates that BIG-IP® DNS 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 DNS does note return an IP address for an unavailable resource.
The Virtual Server Score load balancing method distributes DNS name resolution requests to pool members (virtual servers) based on a user-defined ranking system.
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 DNS 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 DNS uses the Round Robin method to select a pool member.
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.
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.
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 DNS selects a pool member that currently hosts the fewest connections.
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.
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 DNS distributes requests to a pool member in the data center that is the fewest router hops from the LDNS.
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.
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.
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.
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® DNS 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 DNS, taking into account the Classless Inter-Domain Routing (CIDR) of the LDNS. As BIG-IP DNS 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 DNS sends requests to another pool member. When the original pool member becomes available again, BIG-IP DNS sends requests to that pool member.
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.
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.
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 DNS selects a virtual server with the best overall QoS score. If virtual servers have identical scores, BIG-IP® DNS load balances connections to those virtual servers using the round robin method. If QoS scores cannot be determined, BIG-IP DNS load balances connections across all pool members using the round robin method.
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 DNS 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.
|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|
When you customize the QoS equation, consider these three concepts:
|Round Trip Time||50|
|Virtual Server Score||10|
When you use dynamic ratio load balancing, BIG-IP DNS 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.
Run a big3d agent on at least one BIG-IP® system in each data center to ensure that the BIG-IP DNS has timely access to path and network traffic metrics.
If you use dynamic load balancing modes, you must run a big3d agent on every BIG-IP system in your network.
The load on the big3d agents depends on the timer settings that you assign to the different types of data the agents collect. The shorter the timers, the more frequently the agent needs to refresh the data. While short timers guarantee that you always have valid data readily available for load balancing, they also increase the frequency of data collection.
The more local DNS servers that make resolution requests, the more path data that the big3d agents have to collect. While round trip time for a given path may vary constantly due to current network load, the number of hops along a network path between a data center and a specific LDNS does not often change. Consequently, you may want to set short timer settings for round trip time data so that it refreshes more often, but set high timer settings for hops data because it does not need to be refreshed often.
If you turn off the big3d agent on a BIG-IP system, the BIG-IP DNS can no longer check the availability of the server or its virtual servers. Therefore, the statistics screens display the status of these servers as unknown.