Components of a Traffic Manager GLB Deployment

This section provides an overview of the Traffic Manager GLB architecture and outlines the key concepts of a working global load balancer.

Ivanti recommends that you read this section before configuring your GLB deployment. To configure GLB, see Configuring GLB .

GLB Locations

The Traffic Manager considers GLB Locations as independent sites that you use to provide your service. Often, a GLB Location represents a datacenter. You might have two or more GLB Locations in different countries around the world, deployed in order to provide a suitable application delivery infrastructure appropriate to local requirements, or for full disaster recovery for critical systems. Your Traffic Managers do not need to be physically present at a GLB Location, although there are performance and availability benefits for being so.

The Traffic Manager uses a Service Monitor to determine the health of the service being provided by a GLB Location. When a client makes a DNS lookup, the Traffic Manager’s GLB Service chooses the GLB Location most appropriate for that client. The Traffic Manager then returns a DNS response to the client directing it to the chosen GLB Location.

GLB Locations are an independent concept to Configuration Locations, as discussed in Configuration Locations. If you are implementing GLB, a Traffic Manager might be marked as present at a Configuration Location, but this has no bearing on the GLB services it manages.

Traffic Managers in different locations can use the same DNS servers. However, for performance and reliability reasons, Ivanti recommends that you configure your Traffic Managers to use DNS servers local to them. To achieve this, combine your GLB Locations with the Configuration Location functionality described in Multi-Site Cluster Management.

GLB Services

A GLB service represents the global load balancing configuration that you want to use for a set of DNS domains. Within a GLB service, you configure the following core information:

•The domains the GLB service applies to.

•The GLB Locations that are hosting the services for those domains.

•The load-balancing algorithm to use for your GLB Locations.

You can also configure additional settings:

•The TTL (Time-To-Live) value, which determines how frequently a DNS client checks the DNS information for the domain.

•Draining: you can drain a GLB Location to stop clients being directed to it.

•Monitors: you can configure one or more Service Monitors to check the correct operation of the services and hosts in each GLB Location.

•Logging: you can log every DNS request and response for inspection and debugging.

GLB Configured Virtual Servers and Pools

Each Traffic Manager listens for incoming DNS requests through a specially configured Virtual Server for your GLB Services. This Virtual Server uses DNS (UDP or TCP) to load balance traffic to a pool consisting of your back-end DNS Server nodes.

If you have multiple GLB Services assigned to a Virtual Server, the Traffic Manager picks the correct GLB Service based on the domain being requested.

DNS Servers

You create a pool containing your DNS Servers as nodes, and the Traffic Manager load balances this pool according to the load balancing algorithm defined within the pool configuration. If one DNS server node times out, an alert is raised and the Traffic Manager handling the request tries the next DNS server.

You might want to install your Traffic Managers in the same physical location as your DNS server(s) for performance reasons, but this is not mandatory.

Service IP Addresses

For the Traffic Manager to manipulate the answers it sends to a client, it must know which IP addresses belong to which GLB Locations. Service IP addresses correspond to the IP addresses that your DNS Servers return, typically using a round-robin mechanism, when queried for the domains you are managing.

Service Monitors

You can configure each individual GLB Service with a list of Service Monitors that should be run in each GLB Location. All of the Service Monitors you define for a GLB Location must succeed for the Traffic Manager to consider that GLB Location in its load balancing decision for that GLB Service.

If any monitor fails (within the failure threshold limits defined in the monitor), the entire GLB Location is marked as down and those Traffic Managers that detected the failure avoid this location when load-balancing clients.

In some circumstances, one or more Traffic Managers in your geographically distributed GLB deployment might not detect the same failure as their peers, due perhaps to an isolated network outage. These Traffic Managers can continue to use the GLB Location that their peers have detected as unavailable, provided the Service Monitor returns to them a successful response.

Service Monitors typically test a specific named service IP address or hostname for correct operation. For example, you might configure a Service Monitor to test the primary server load balancer in that GLB Location to verify that it is correctly serving content. The primary server load balancer has the IP address that is published using DNS for that service in that GLB Location.

You can assign multiple Service Monitors to a GLB Location if you want to test several services or hosts for correct operation.

If you have configured GLB Locations in multiple GLB Services, the Service Monitors for each operate independently. Even though a GLB Location might fail for one GLB Service, the other GLB Services continue to use that GLB Location if their monitors are successful.

Service Monitors can optionally provide performance information to the load balancing algorithm if you are using a "Load" or "Adaptive" load balancing method. The load balancing algorithm then sends more traffic to the GLB Location that reports the best performance.

Performance data is based on the time the Service Monitor takes to complete. In other words, this is the response time of the monitored GLB Location.