Applies To:

Show Versions Show Versions

Manual Chapter: The Logical Network
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

After you define the physical components of your network, such as data centers, servers, and links, you can configure Global Traffic Manager with the logical components of your network. Logical components are abstractions of network resources, such as a virtual servers. Unlike physical components, the logical network can often span multiple physical devices, or encompass a subsection of a single device.
To better understand the interactions between pools, wide IPs, and data centers, consider the fictional company of SiteRequest. SiteRequest is an online application repository. Currently, its presence on the World Wide Web consists of a main site, www.siterequest.com; a download area, downloads.siterequest.com; and a search area, search.siterequest.com.
These three fully-qualified domain names (FQDNs), www.siterequest.com, downloads.siterequest.com, and search.siterequest.com, are wide IPs. Each of these wide IPs contain several pools of virtual servers. For example, www.siterequest.com contains two pools of virtual servers: poolMain, and poolBackup. When Global Traffic Manager receives a connection request for www.siterequest.com, it applies its load balancing logic to select the appropriate pool to handle the request.
After Global Traffic Manager selects a pool, it then load balances the request to the appropriate virtual server. For example, mainPool contains three virtual servers: 192.168.3.10:80, 192.168.4.20:80, and 192.168.5.30:80. Global Traffic Manager responds to the system that made the connection request with the selected virtual server. At this point, Global Traffic Manager steps out of the communication, and the system requesting the resource communicates directly with the virtual server.
Note: If a virtual server is managed by a load balancing server that is not in the BIG-IP® product family, the IP address and port number of the virtual server often point to a proxy on which the load balancing server listens for connection requests. In that case, the load balancing server remains in the communication directing the connection to the appropriate resource.
For administration purposes, the wide IPs downloads.siterequest.com and search.siterequest.com are added to a single distributed application, siterequest_download_store. This configuration provides the IT staff the ability to track the performance of the distributed application, as performance has an immediate impact on the users that visit the web sites.
A pool represents one or more virtual servers that share a common role on the network. A virtual server, in the context of Global Traffic Manager, is a combination of IP address and port number that points to a specific resource on the network.
Global Traffic Manager considers any virtual servers that you add to a pool to be pool members. A pool member is a virtual server that has specific attributes that pertain to the virtual server only in the context of that pool. Through this differentiation, you can customize settings, such as thresholds, dependencies, and health monitors, for a given virtual server on a per-pool basis.
As an example of the difference between pool members and virtual servers, consider the fictional company SiteRequest. In the London data center, the IT team has a virtual server that acts as a proxy for a Local Traffic Manager system. This virtual server is the main resource for name resolution requests for the companys main web page that originate from Europe. This same virtual server is the backup resource for name resolution requests that originate from the United States. Because these are two distinctly different roles, the virtual server is a pool member in two different pools. This configuration allows the IT team to customize the virtual server for each pool to which it belongs, without modifying the actual virtual server itself.
Before you can add virtual servers to Global Traffic Manager, you must define a server that represents a physical component of your network. Then you can add virtual servers to the server, and group the virtual servers in pools.
When you create a pool, you name it and add at least one virtual server as a member of the pool. You can also assign specific load balancing methods, a fallback IP address, and one or more health monitors to the pool. You assign a fallback IP address in the event that the load balancing methods you assign to the pool fail to return a valid virtual server. The health monitors that you assign to the pool use various methods to determine if the virtual servers within the pool are available.
Certain load balancing methods within Global Traffic Manager select virtual servers based on the order in which they are listed in the pool. For example, the load balancing method, Global Availability, instructs Global Traffic Manager to select the first virtual server in the pool until it reaches capacity or goes offline, at which point it selects the next virtual server until the first pool becomes available again.
If you use a load balancing method that selects virtual servers based on the order in which they are listed in the pool, you may want to change the order in which the virtual servers are listed in the Member List. When you organize your virtual servers in conjunction with these load balancing methods, you can ensure that your most robust virtual server always receives resolution requests, while the other virtual servers act as backups in case the primary virtual server becomes unavailable.
One of the load balancing methods that Global Traffic Manager supports is the Ratio mode. This mode instructs the system to load balance network requests based on the weights assigned to a specific resource. If you use the Ratio mode to load balance across virtual servers in a pool, you must assign weights to the virtual servers. A weight is a value assigned to a resource, such as a pool, that Global Traffic Manager uses to determine the frequency at which the resource receives connection requests. Global Traffic Manager selects a resource based on the weight of that resource as a percentage of the total of all weights in that resource group.
To illustrate the use of weights in connection load balancing, consider the fictional company SiteRequest. One of SiteRequests wide IPs, www.siterequest.com, contains a pool labeled poolMain. This pool uses the Ratio load balancing mode and contains three virtual servers, with the following weight assignments:
Notice that the total of all the weights in this pool is 100. Each time Global Traffic Manager selects this pool, it load balances across all three virtual servers. Over time, the load balancing statistics for this pool appear as follows:
This pattern exists because the weight value, 50, is 50 percent of the total weight for all virtual servers (100), while the weight value, 25, is 25 percent.
When you create a pool, instead of adding virtual servers to the pool, you can instead provide a canonical name (CNAME) that the system returns in responses to requests for that pool. In this case, you do not add members to the pool, because the CNAME always takes precedence over pool members. The health monitors that you assign to the pool use various methods to determine if this pool is available for load balancing.
A canonical name is the official name for a domain. In DNS, a CNAME record maps an alias to the canonical name for a domain, for example, a CNAME record can map the alias downloads.siterequest.com to the canonical name siterequest.com. When you define a pool using a canonical name, the system delegates DNS queries by responding to queries with a CNAME record, rather than a pool member.
A content delivery network (CDN) is identified by a domain name (canonical name). A CND is a network that includes devices designed and configured to maximize the speed at which a content provider's content is delivered. The purpose and goal of a CDN is to cache content closer, in Internet terms, to the user than the origin site is. Using a CDN to deliver content greatly reduces wide area network (WAN) latency so the content gets to the user more quickly, and the origin site servers are not overloaded and slowed by requests for content.
A wide IP maps a fully-qualified domain name (FQDN) to a set of virtual servers that host the domains content, such as a web site, an e-commerce site, or a CDN. Wide IPs use pools to organize virtual servers, which creates a tiered load balancing effect: Global Traffic Manager first load balances requests to the appropriate pool of a wide IP, and then load balances within the pool to the appropriate virtual server.
Global Traffic Manager supports wildcard characters in both wide IP names and wide IP aliases. If you have a large quantity of wide IP names and aliases, you can use wildcard characters to simplify your maintenance tasks. The wildcard characters you can use are: the question mark ( ? ), and the asterisk ( * ).
A wide IP must contain at least one pool, which must contain at least one pool member. This hierarchal configuration allows Global Traffic Manager to load balance connection requests for a wide IP at two levels: first, the connection is load balanced across the pools assigned to the wide IP; second, the connection is load balanced across the pool members within the given pool.
Certain load balancing methods within Global Traffic Manager select pools based on the order in which they are listed in the wide IP. For example, the load balancing method, Global Availability, instructs Global Traffic Manager to select the first pool in the wide IP until it becomes unavailable, at which point it selects the next pool until the first pool becomes available again.
If you use a load balancing method that selects pools based on the order in which they are listed in a wide IP, you may want to change the order in which the pools are listed in the Pools List. When you organize your pools in conjunction with these load balancing methods, you can ensure that your most robust pool always receives resolution requests, while the other pools act as backups in case the primary pool becomes unavailable.
One of the load balancing methods that Global Traffic Manager supports is the Ratio mode. This mode instructs the system to load balance network requests based on the weights assigned to a specific resource. If you use the Ratio mode to load balance across pools in a wide IP, you must assign weights to those pools. A weight is a value assigned to a resource, such as a pool, that Global Traffic Manager uses to determine the frequency at which the resource receives connection requests. Global Traffic Manager selects a resource based on the weight of that resource as a percentage of the total of all weights in that resource group.
To illustrate the use of weights in connection load balancing, consider the fictional company SiteRequest. One of SiteRequests wide IPs, www.siterequest.com, uses the Ratio load balancing mode and contains three pools, with the following weight assignments:
Notice that the total of all the weights in this wide IP is 100. Each time Global Traffic Manager selects this wide IP, it load balances across all three pools. Over time, the load balancing statistics for this wide IP appear as follows:
This pattern exists because the weight value, 50, is 50 percent of the total weight for all pools, while the weight value, 25, is 25 percent of the total.
An iRule is a set of one or more Tcl-based expressions that you can use with wide IPs to customize how Global Traffic Manager handles network connection requests.
You can add or remove an iRule to a wide IP at any time. When you add an iRule to a wide IP, Global Traffic Manager uses the iRule to determine how to load balance name resolution requests. Removing an iRule does not delete it from Global Traffic Manager; you can still access the iRule by clicking iRules under Global Traffic on the Main tab.
You can also customize a wide IP using more than one iRule. For example, a wide IP might have an iRule that focuses on the geographical source of the name resolution request, and another that focuses on redirecting specific requests to a different wide IP. If you assign more than one iRule to a wide IP, Global Traffic Manager applies iRules® in the order in which they are listed in the iRules List for the wide IP.
In networks that use IPv6 addresses, a system receiving a Domain Name System (DNS) request for a zone is required to send a specific response, called a NoError response, any time it receives an IPv6 request for a zone that does not contain a corresponding AAAA record. After receiving this response, the client making the request can re-send the request for an equivalent IPv4 A record instead. Using the NoError response allows the client to send the equivalent request sooner and receive the name resolution faster.
By default, Global Traffic Manager does not send a NoError response when it does not have a AAAA record for a given zone. However, you can enable this response on a per-wide IP basis.
A distributed application is a collection of wide IPs that serves as a single application to a site visitor. Within Global Traffic Manager, distributed applications provide you with several advantages:
You can organize logical network components into groups that represent the business environment for which these components were designed.
You can configure a distributed application so that it is dependent on a physical component of your network, such as a data center, server, or link. If this physical component becomes unavailable, Global Traffic Manager flags the distributed application as unavailable as well. These dependencies ensure that a user cannot access a distributed application that does not have all of its resources available.
You can define persistence for a distributed application, ensuring that a user accessing the distributed application uses the same network resources until they end their session.
When you create a distributed application, you name it and add at least one wide IP. You can also configure the distributed application so that its availability depends on the availability of specific servers, virtual servers, or data centers. Additionally, you can configure whether the system routes requests coming from the same source during a specific time period to the same pool, or to a different pool. This is known as persistence.
When you create a distributed application on Global Traffic Manager, the system acquires information about the data centers, servers, and links that make up the application, including the status of each of these components. You have the option of setting the status of the distributed application to be dependent upon the status of one of these types of components. For example, when you configure the distributed application for server dependency, and a specified server becomes unavailable, Global Traffic Manager considers the distributed application to be unavailable as well.
The following examples illustrate how dependencies can affect the availability of a given distributed application. These examples involve the fictional company SiteRequest. This company has a distributed application that consists of two wide IPs: www.siterequest.com and downloads.siterequest.com. The company also has data centers in New York, Paris, and Tokyo, each of which provides resources that the distributed application can access. In each example, a lightning storm caused the New York data center to lose power. Although the emergency power starts immediately, one of the wide IPs, one of the virtual servers, and one of the Internet links used by the application are offline, and thus unavailable.
Example 1: Data Center Dependency
If the application uses data center dependency, Global Traffic Manager considers the entire data center to be unavailable to the application, even if other virtual servers for the application remain available at the data center. Other connection requests, independent of the application, can still be sent to the data center.
Example 2: Server Dependency Level
If the application uses server dependency, Global Traffic Manager considers the server hosting the virtual server to be unavailable to the application, even if other virtual servers on that server are online. Other connection requests, independent of the application, can still be sent to the server.
Example 3: Link Dependency Level
If the application uses link dependency, Global Traffic Manager considers all resources for the application that use that link to be unavailable to the application. Other connection requests, independent of the application, can still be sent to these resources through other links.
Example 4: Wide IP Dependency Level
If the application uses wide IP dependency, Global Traffic Manager considers all wide IPs that host that application to be unavailable, even if only one of the wide IPs is unavailable. Other connection requests, independent of the application, can still be sent to the data center.
Note: You do not have to set a dependency for a distributed application. You can accept the default value of None. If you do not set a dependency, then Global Traffic Manager considers the application available as long as there is at least one wide IP to which it can load balance a name resolution request.
Distributed applications often consist of many data centers, servers, and links. You might find that you need to remove a given physical component without interrupting access to the application. For example, you might want to take a server down to update it, yet do not want its absence to affect the application. To accommodate this and similar situations, Global Traffic Manager provides options so you can enable and disable distributed application traffic for a specific physical component on the network.
Note: When you add a physical component to a distributed application, by default, distributed application traffic is enabled for that component.
Many distributed applications require that users access a single set of resources until they complete their transaction. For example, customers purchasing a product online might need to remain with the same data center until they finish their order. In the context of Global Traffic Manager, this requirement is called persistence. Persistence is the state in which a user of the system remains with the same set of resources until the user closes the connection.
When you enable persistence for a distributed application, and an LDNS makes repetitive requests on behalf of a client, the system reconnects the client to the same resource to which it was connected for previous requests. For persistence to work correctly for a distributed application, you must also specify a dependency level. This is because a connection to the distributed application persists to the dependency object you specify (that is, the specified wide IP, server, data center, or link), and not to a specific pool member.
Table of Contents   |   << Previous Chapter   |   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)