Applies To:

Show Versions Show Versions

Manual Chapter: Metric Collection
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Global Traffic Manager system uses specialized software components, called monitors, to capture data regarding the availability of a resource, such as a virtual server. Monitors represent one half of the statistical gathering capabilities of Global Traffic Manager. The second half, metrics collection, captures data about how well network traffic flows between Global Traffic Manager and the external local DNS servers and internal resources with which it communicates.
The resources you make available to your users over the Internet are often critical to your organization; consequently, it is vital that these resources are not only available, but highly responsive to your users. Typically, two main criteria determine the responsiveness of a resource: hops and paths. A hop is one point-to-point transmission between a host and a client server in a network. A network path that includes a stop at a network router has two hops: the first from the client to the router, and the second from the router to the host server. A path is a logical network route between a data center server and an LDNS.
It is important to remember that hops and paths can differ from each other widely on a per-connection basis. For example, an LDNS might take a long path to reach a specific resource, but require only a few hops to get there. On the other hand, that same LDNS might select a short path, yet have to move between a larger number of routers, increasing the number of hops it takes to reach the resource. It is up to you to determine what thresholds for hops and paths are acceptable for your network, as the needs of each network, and even each application within the same network, can vary widely.
Through the metrics collection capabilities of Global Traffic Manager, you can accomplish several tasks related to improving the availability and responsiveness of your network applications and resources. You can:
Define the types of metrics that Global Traffic Manager collects, and how long the system keeps those metrics before acquiring fresh data.
Implement the Quality of Service load balancing mode, which uses metrics to determine the best resource for a particular name resolution request.
When you decide to use Global Traffic Manager to collect metrics on the local DNS servers that attempt to access your network resources, you can define the following characteristics:
While each of these settings is important, the ones that perhaps require the most planning beforehand are the TTL values. In general, the lower the TTL value, the more often Global Traffic Manager probes an LDNS. This improves the accuracy of the data, but increases bandwidth usage. Conversely, increasing the TTL value for a metric lowers the bandwidth your network uses, but increases the chance that Global Traffic Manager is basing its load balancing operations off of stale data
An additional consideration is the number of local DNS servers that Global Traffic Manager queries. The more local DNS servers that the system queries, the more bandwidth is required to ensure those queries are successful. Therefore, setting the TTL values for metrics collection can require incremental fine-tuning. F5 Networks recommends that you periodically check the TTL values, and verify that they are appropriate for your network.
To capture accurate metrics data from the local DNS servers that send name resolution requests to Global Traffic Manager, you assign probes to each LDNS. A probe is a query that employs a specific methodology to learn more about an LDNS.
The DNS_REV probe sends a DNS message to the probe target LDNS querying for a resource record of class IN, type PTR. Most versions of DNS answer with a record containing their fully-qualified domain name. The system makes these requests only to measure network latency and packet loss; it does not use the information contained in the responses.
The DNS.DOT probe sends a DNS message to the probe target LDNS querying for a dot (.). If the LDNS is not blocking queries from unknown addresses, it answers with a list of root nameservers. The system makes these requests only to measure network latency and packet loss; it does not use the information contained in the responses.
The UDP probe uses the user datagram protocol (UDP) to query the responsiveness of an LDNS. The UDP protocol provides simple but unreliable datagram services. The UDP protocol adds a checksum and additional process-to-process addressing information. UDP is a connectionless protocol which, like TCP, is layered on top of IP. UDP neither guarantees delivery nor requires a connection. As a result, it is lightweight and efficient, but the application program must take care of all error processing and retransmission.
The TCP probe uses the transmission control protocol (TCP) to query the responsiveness of an LDNS. The TCP protocol is the most common transport layer protocol used on Ethernet and Internet. The TCP protocol adds reliable communication, flow-control, multiplexing, and connection-oriented communication. It provides full-duplex, process-to-process connections. TCP is connection-oriented and stream-oriented.
The ICMP probe uses the Internet control message protocol (ICMP) to query the responsiveness of an LDNS. The ICMP protocol is an extension to the Internet Protocol (IP). The ICMP protocol generates error messages, test packets, and informational messages related to IP.
With these probes, it does not matter whether Global Traffic Manager receives a valid response, such as the name of the LDNS as queried by the DNS_REV probe, or a request refused statement. The relevant information is the metrics generated between the probe request and the response. For example, Global Traffic Manager uses the DNS_REV probe to query two local DNS servers. The first LDNS responds to the probe with its name, as per the request. The second LDNS, however, responds with a request refused statement, because it is configured to not allow such requests. In both cases, the probe was successful, because Global Traffic Manager was able to acquire data about how long it took for both local DNS servers to respond to the probe.
You can configure Global Traffic Manager to use a select number of probes, or you can assign all five. The more probes that Global Traffic Manager uses, the more bandwidth is required.
When Global Traffic Manager attempts to probe an LDNS, it is actively attempting to acquire data from that LDNS. Certain Internet Service Providers and other organizations might request that you do not probe their local DNS servers, while other local DNS servers might be known to act as proxies, which do not provide accurate metrics data. In these situations, you can configure Global Traffic Manager to exclude local DNS servers from probes. When you exclude an LDNS, Global Traffic Manager does not probe that server; however, Global Traffic Manager is also unable to use the Quality of Service load balancing mode to load balance name resolution requests from that LDNS.
You can remove an LDNS from the address exclusion list at any time. Situations in which you want to remove an LDNS include the LDNS becoming inactive, or the IP address of the LDNS changing to a different network subnet.
Each resource in Global Traffic Manager has an associated time-to-live (TTL) value. A TTL is the amount of time (measured in seconds) for which the system considers metrics valid. The timer values determine how often Global Traffic Manager refreshes the information.
Each resource also has a timer value. A timer value defines the frequency (measured in seconds) at which Global Traffic Manager refreshes the metrics information it collects. In most cases, the default values for the TTL and timer parameters are adequate. However, if you make changes to any TTL or timer values, keep in mind that an objects TTL value must be greater than its timer value.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?

NOTE: Please do not provide personal information.

Additional Comments (optional)