GTM (Global Traffic Manager)

GTM (Global Traffic Manager) is the global traffic management module of TR7 that works at the DNS layer. It turns TR7 into an authoritative DNS server for the domain names that are asked; however, instead of returning fixed answers, it produces the most suitable answer by evaluating every query according to the health of the target addresses, the location of the client and the data center metrics.

In this way the traffic is routed to the correct data center, only to the healthy addresses and to the most suitable target at the moment of the DNS resolution, before the client establishes its first connection. GTM forms the basis of the multi-region, disaster-recovery-capable and business-continuity oriented architectures that go beyond a single data center.

The module is in the GTM tab (its title is Global Traffic Management) in the Configuration Menu. The first decision of every connection is given in DNS; GTM turns this first moment into a control point that monitors the health and the performance of the resources continuously and turns them into a routing decision.

Its difference from local load balancing

GTM is a separate product that works at the DNS layer: while local load balancing (Load Balancer - ADC) distributes the traffic to the servers within a data center, GTM routes between data centers. When the two products are used together, in the Datacenter mode the status and the metrics of the vServices are also used as a decision input. The addresses that the records show do not have to be a vService on TR7; external services are targeted as well.

TR7 Product

GTM (Global Traffic Manager) is the TR7 GTM (Global Traffic Manager) product, one of the four separately licensed products of TR7. The products are licensed on their own or in packages; the licensing details are on tr7.com.

The TR7 products: Load Balancer - ADC · WAF - WAAP · AGS - AAM · GTM (Global Traffic Manager)

Operating mode

Standalone · Disaster Recovery · Datacenter; it is selected per domain name

DNS record type

From A, AAAA, CNAME, MX, TXT and SRV to CAA, TLSA and SMIMEA

Health Check type

TCP, HTTP(S), DNS, Ping, LDAP, SMTP, Oracle and the data center metrics

Distribution algorithm

All, the first N healthy, round robin, weighted, random, geographic proximity

Data center selection source

All DC Records · DC Based · Service Based · Client Based

Free Target

Any address

The records can show the vServices on TR7 or external services

10 Years

Retrospective monitoring

Dashboards at the service, domain name and record level; the measurements are stored on the device

No Code

Configuration from the web interface

From the scenarios to the routing rules, it does not require a script or programming

License and authorization

The GTM tab in the Configuration Menu is visible to the users who have the GTM module in their license and who have authorization in the GTM area; the tab is not present on the devices that work in the EAL mode. The GTM screens require full authorization in the GTM area.

What Is GTM (Global Traffic Manager)?

A classic DNS server always returns the same static answer for a domain name; even if the target server has crashed or the client is on the other side of the world. GTM makes this behavior intelligent: before giving the answer, it checks the health of the target addresses, takes the location of the client into account and evaluates the instant load of the data centers.

Every DNS service defined on GTM hosts one or more domain names (zones); and every domain name carries its own DNS records. More than one address can be assigned to a record, a health condition to every address (the HC column in the record table), a distribution algorithm to the record and fail-safe addresses as a last resort. When a query comes, GTM combines this information and returns only the suitable addresses.

In this way GTM takes DNS out of being a static name-address matcher and turns it into an active layer where the traffic routing and business continuity decisions are given. The whole of the configuration, from the health scenarios to the routing rules, is done from the web interface without requiring programming, script or code knowledge.

Its Difference From Local Load Balancing

GTM and local load balancing (vService) decide at different layers and at different moments; when they are used together they complement each other:

	Local Load Balancing (vService)	GTM
Scope	Within a data center	Between data centers / geographic
Layer	Connection and application (L4–L7)	DNS (name resolution)
Decision moment	After the connection is established	Before the connection is established (in the DNS query)
Target	Load distribution between servers	Routing between data centers / regions

GTM on TR7

GTM works on TR7 as isolated DNS services: more than one service is present side by side on one device; every service has its own listener addresses, cache, resource limits (QOS) and log setting. The definitions that the services use while deciding, on the other hand, are device-wide: Remote Devices, Health Checks, Health Scenarios, Trigger Actions, Express Profiles and DNS Forwarder Profiles are defined once and used in all the services.

Intelligent routing is not compulsory: GTM also works as a standard authoritative DNS server in the situations where the advanced features are not needed. By defining the domain names and the records, classic DNS service is given; the health-aware resolution, the topology and the multi-data-center modes are put into effect only when they are required.

Why Is It Needed?

The structures that are single-data-center and based on static DNS become insufficient as the scale and continuity requirements increase. GTM responds to each of these limits directly:

Difficulty	The solution with GTM
A single data center, a single point of failure	Multi-data-center DNS; when one center goes down, the traffic shifts to the other automatically.
Geographic delay (a distant user)	Routing according to the network, the country, the continent or the network proximity of the client.
Manual DNS change is slow and open to errors	Automatic switching without human intervention with the health scenarios.
"Blind" DNS: an answer returns even if the server has crashed	Health-aware resolution; only the healthy addresses take part in the answer.
Load imbalance between the regions	Selection according to the CPU / memory / bandwidth metrics of the data center device or to the request, connection, session and healthy Backend Service number metrics of a vService.
Controlled handover at the moment of a disaster	Automatic active-passive switching between the Main DC / DR DC and an automatic return when the condition disappears.

How Does It Work?

When a DNS query reaches GTM, the answer is determined not at once but with an evaluation chain:

01 · QueryThe DNS query arrivesThe client asks the domain name for which GTM is authoritative

02 · HealthThe addresses are filteredAccording to the HC condition, the unhealthy and disabled addresses are eliminated

03 · ModeThe scope is determinedThe Standalone, Disaster Recovery or Datacenter rule is applied

04 · AlgorithmThe candidates are selectedThe addresses are determined with the distribution algorithm and the topology rules

05 · AnswerIt returns to the clientIf no candidate address remains, the fail-safe records are returned

This evaluation is made continuously: as the health checks and the metrics change, the answers are updated. If the deactivation setting of a health scenario is Automatic, the scenario returns to passive by itself when the conditions return to normal; if it is With Trigger, the return is bound to a separate verification condition; and if it is Off, the scenario remains active until the scenario is edited.

The answer changing and the handover being completed are separate

The answer that GTM produces changes together with the switching decision; however, the clients and the intermediate resolvers keep the previous answer in the cache during the TTL period of the record. The real handover is completed when the TTL of the old answer expires and a new query is made. The record TTL is 3600 seconds by default; in the structures where a fast handover is required, a short TTL (e.g. 60–300 seconds) is recommended.

GTM uses two types of proximity in the routing:

Static proximity: according to the fixed topology rules such as the network, the country, the continent or the ASN of the client; the rules are also written in the "those that do not meet this criterion" form by being reversed with Negate. It is used in every mode.
Dynamic proximity: according to the network performance measured to the client (Number of Hops, MOS, Packet Loss, TTL). It is used only in the Datacenter mode, in the Client Based data center selection; in this selection the topology rules and the Total DCs to Select From limit are not applied.

Operating Modes

Every domain name is configured with an operating mode (Default Mode in the domain name form) that determines how its records will be resolved; all the records of the domain name take this mode. For the details see Domains › Operating Modes.

Mode	Data Center Groups	Behavior
Standalone	Single (local)	A single data center group; a flexible configuration from a simple authoritative DNS to a conditional resolution bound to the health scenarios and to load handover with fail-safe records.
Disaster Recovery	Two (Main DC + DR DC)	Automatic active-passive switching between the main and the backup data center. The switching condition is selected per record: the default Automatic (when no healthy primary records left) or a health scenario; when the condition disappears, the answers return to the Main DC.
Datacenter	One or more (DC № 1, DC № 2 …)	The data centers are sorted according to the selected source and the records of the first Total DCs to Select From of them take part in the answer (except Client Based).

Core Building Blocks

The working structure of GTM consists of a few components bound to each other. The layers below together produce the health-aware, location-aware DNS behavior:

DNS Service Entry point

It is the authoritative DNS listener that the queries reach; the listener addresses, the cache, QOS, the query logging and the optional forwarder are defined here. All the domain names and the records are bound to a service.

Domain The carrier of the operating mode

It is the zone for which the service is authoritative. Every domain name carries its own operating mode, the record management form per data center group (Local / Express) and the DNSSEC, SOA serial format and slave server settings independently.

Record The health-aware answer

It is the unit in which the answer is produced. More than one address is assigned to a record, an HC condition to every address (Static, Disabled or a scenario), a distribution algorithm to the record, topology rules and fail-safe addresses that are not bound to a health condition.

Health Check · Health Scenario The decision logic

Health Check measures the status of the targets or of the data centers; Health Scenario reduces these checks to a single decision with AND / OR groups (by reversing them with UNLESS if necessary) and manages the addresses in the records and the Disaster Recovery switching.

Remote Device The metric source

It collects the WAN/LAN access, the internet status and the CPU, memory, bandwidth and vService metrics of the TR7 devices in the other data centers; it produces automatic health checks for every data center.

Automation and Integration Trigger · Express · Forwarder

Trigger Actions calls an external HTTP(S) endpoint or an Oracle database in the scenario transitions and evaluates its response; Express pulls the records from the external DNS servers with AXFR; DNS Forwarder forwards the queries for which there is no authority to the default addresses, optionally according to the domain-name-based rules.

Monitoring and Visibility

The decisions of GTM and the behavior of the services are monitored live and retrospectively:

The service dashboard Dashboard

The query rate, the response codes, the record type, country, domain name and record breakdowns, the cache, the latency, the forwarder and the system metrics of a DNS service are collected in seven view tabs.

The domain name and record dashboards Domains · Records

The query, existing / non-existing name and record type breakdowns of every domain name and the query rate of every record are monitored in their own dashboards.

Device-wide Home · Left Monitor Panel

The GTM tab of the home page shows the totals of all the services in four sub-tabs; in the Left Monitor Panel the GTM, GTM Domains and GTM Records tabs list the services, the domain names and the records with their statuses.

The event log GTM Logs

The health check and scenario status changes, the Disaster Recovery and fail-safe transitions of the records, the AXFR operations, the trigger actions, the data center access events and the user operations are monitored on the GTM Logs screen and in the Log window on the preview of every object.

Key Features

Health-aware resolutionEvery address is bound to Static, Disabled or a health scenario (HC Scenario); only the healthy addresses take part in the answer.

Nine distribution algorithmsAll Records, First Healthy Record / First 2 / First 3 Healthy Records, Round Robin, Weighted Round Robin, Random, Weighted Random and Geographic Proximity (only on the A / AAAA records).

Topology routingA different answer according to the network, the country, the continent or the ASN of the client, with the rules that match or exclude.

Free routing targetThe records are routed to any address; the target does not have to be a vService on TR7.

Disaster RecoveryAutomatic active-passive switching between the Main DC / DR DC; the switching condition is selected per record, and when the condition disappears the answers return to the Main DC.

Metric-based data center selectionIn the Datacenter mode the data centers are sorted according to the All DC Records, DC Based, Service Based or Client Based source.

Fail-safe recordsThe last resort answer to be returned when no candidate address remains; these addresses are not bound to a health condition.

Express (AXFR)The records being pulled from the external master DNS servers; synchronization with the NOTIFY coming from the source and the bulk transfer of the records manually with Zone Transfer.

Slave serversZone transfer permission and change notification (NOTIFY) to the servers defined with Slave Server IPs per domain name.

DNS ForwarderThe queries for which there is no authority being forwarded according to the default addresses and the domain-name-based rules; it can be skipped per address with DIRECT.

DNSSECProtection against DNS spoofing with signed answers per domain name; the DS records are read from the interface.

Multiple independent servicesMore than one isolated DNS service on one device; with QOS the core, processor and memory resources are separated from each other.

It does not require codeEverything is configured from the web interface; it does not require a programming language, script or code knowledge.

Management and Operation

The services are isolated. More than one DNS service works on one device; the addresses, the domain names, the records, the cache and the resource limits of every service belong only to itself.
The decision definitions are shared. The Remote Devices, Health Checks, Health Scenarios, Trigger Actions, Express and DNS Forwarder profiles are defined once device-wide and used in all the services.
The mode comes from the domain name. The mode of the record is taken from the Default Mode setting of the domain name and cannot be changed in the form; when the mode of the domain name changes, all of its records are re-established according to the new mode.
The cluster behavior. The service, domain name and record definitions are reflected to the peer device; every device calculates the health checks and the record status itself, and for this reason a separate status per device is seen in the lists and the previews.
The authorization comes from a single area. All of the GTM screens require full authorization in the GTM area; if there is no GTM module in the license, the screens do not open.

Use Cases

Single Center / Flexible DNS Management Standalone

In the structures where multi-data-center routing is not needed, standard authoritative DNS service is given; with the health scenarios and the fail-safe records a flexible, conditional configuration is established. A wide range from a simple DNS need to a single-center load handover is met in a single mode.

Multi-Data-Center Load Distribution Datacenter

In the services spread over two or more data centers, the data centers are sorted according to the instant load, the metrics of a vService or the client proximity, and the selected number of data centers take part in the answer.

Disaster Recovery Disaster Recovery

When no healthy address remains in the main data center or when the selected scenario becomes active, the answers pass to the backup data center; when the condition disappears, they return to the main data center.

Geographic Routing Topology

The users are routed to the most suitable address according to the country, the continent or the network they are in, and in this way the delay is reduced and the data locality is provided.

Hybrid / External DNS Integration Express · Forwarder

Working together with the existing DNS infrastructure: the records are synchronized with Express (AXFR), and the queries for which there is no authority are forwarded with the DNS Forwarder.

Object Model

The GTM building blocks of TR7 correspond to the global server load balancing (GSLB) model that is widely used in the sector; only the naming is specific to TR7:

TR7 object	What it is	Industry equivalent
DNS Service	The authoritative DNS listener that listens to the queries	GSLB listener / DNS listener
Domain	The zone for which the service is authoritative	zone / wide IP
Record	The answer unit with its addresses, algorithm and conditions	resource record / pool
Remote Device	The TR7 device in the other data center	data center / site
Health Check	The check that measures the status of the target or of the data center	monitor
Health Scenario	The logic that reduces the checks to a single decision	health rule / condition
Topological Selection	The address selection according to the client location	topology / geo-routing

Terminology

Term	Description
DNS Service	The authoritative DNS entry point that the queries reach. All the domain names and the records are bound to a service.
Domain	The zone for which the service is authoritative. It carries the operating mode (Default Mode), the record management form per data center group and the DNSSEC / SOA / slave server settings.
Record	The unit in which the answer is produced; it contains the addresses, the HC condition per address, the distribution algorithm, the topology and the fail-safe.
Operating Mode	How the domain name will resolve its records: Standalone, Disaster Recovery or Datacenter.
Health Check	The periodic check that measures the status of the targets or of the data centers (TCP, HTTP(S), DNS, Ping, Oracle, Datacenter HC, etc.).
Health Scenario	The mechanism that reduces the health checks to a single decision with AND / OR groups (by reversing them with UNLESS per check).
Trigger Action	The action profile that calls an external HTTP(S) endpoint or an Oracle database in the scenario transitions and evaluates its response.
Remote Device	The definition that collects the WAN/LAN access and the resource metrics of the other data centers.
Fail-Safe Record	The backup answer that is returned when no candidate address remains.
Local / Express	Whether the records in a data center group are managed manually or pulled from an external DNS server with AXFR.

Sections

Typical Setup Flow

A multi-data-center GTM structure is generally established in the following order:

Step 1 The local and remote data centers are defined

The name and the access addresses of the local data center and the other data centers are added from the Remote Devices screen; the WAN/LAN access and the metric collection start.

Step 2 The health checks are created

Health Checks are defined in order to measure the status of the targets or of the data centers; the automatic checks per data center are created by themselves.

Step 3 The health scenarios are established

The checks are turned into decision conditions with AND / OR groups (by reversing them with UNLESS if necessary) with Health Scenarios; Trigger Actions are added if necessary.

Step 4 The DNS service is created

A DNS service is added with Service Management with the vDevice, the route table, the listener addresses and the cache / QOS settings.

Step 5 The domain name is added and the mode is selected

A domain name is added to the service from the Domains tab and the operating mode (Standalone / Disaster Recovery / Datacenter) is determined.

Step 6 The DNS records are defined

The records are added from the Records tab or transferred with Zone Transfer; the addresses, the HC conditions, the distribution algorithm and the fail-safe are configured.

Step 7 The domain name is delegated to TR7

In the parent zone or at the domain name operator, the NS records are updated so that they point to the listener address of the TR7 DNS service. This step is done outside TR7; afterwards the real DNS queries reach TR7 and are answered by GTM.

Step 8 It is monitored

The traffic, the health and the transitions are monitored continuously from the service, domain name and record dashboards and from the GTM Logs screen.

Logs & Tracking

Logs

HTTP

TCP

WAF Management

WAF Rules (Page Types)

Path Check Fields

Inspection & Blocking

Learning & Reporting

Virtual Host Groups

Bot/DDoS Management

Bot/DDoS Protection Mode

Learning

L7 DDoS Protection

IP Reputation Protection

Bot Protection

L4 DDoS Management

L4 DDoS Protection Mode

Learning

TCP

UDP

ICMP & Reflection

Packet Integrity

TR7 Management Access

Flowchart

Authentication Providers

ags

gtm

lb

network

settings

waf

Network Diagnostics

DNS & IP Calculation

Connection, Port & Scan

Packet & TLS Analysis

HTTP & Load Testing

IP & Interface Status

Maintenance & Interactive

Files & Context

GTM (Global Traffic Manager) ​

What Is GTM (Global Traffic Manager)? ​

Its Difference From Local Load Balancing ​

GTM on TR7 ​

Why Is It Needed? ​

How Does It Work? ​

Operating Modes ​

Core Building Blocks ​

Monitoring and Visibility ​

Key Features ​

Management and Operation ​

Use Cases ​

Object Model ​

Terminology ​

Sections ​

Service, Domain Name and Record Management ​

The Data Center and the Health Decision ​

DNS Integration ​

Typical Setup Flow ​