Initial Configuration

This chapter explains how to set up a basic traffic-managed site.

Architecture Concepts

A Traffic Manager manages traffic for network services like Web and application servers (HTTP, HTTPS), Web services (SOAP), mail (SMTP, POP, IMAP) and other protocols such as DNS and streaming media.

A “service” is published as an IP address and port, and accepts traffic using the appropriate protocol.

A website might be hosted at www.example.com. This website name is then mapped through DNS to resolve to an IP address, and you configure your Traffic Manager service to listen on that IP address for a particular traffic type on the corresponding port (for example, HTTP traffic on port 80).

For example, an Internet Service Provider (ISP) publishes its POP3 and SMTP mail servers as pop.example.com and smtp.example.com. Each of these servers has a DNS entry linking it to an IP address:

•pop.example.com has address 192.0.2.150

•smtp.example.com has address 192.0.2.151

pop.example.com listens on port 110 for POP3 traffic, while smtp.example.com listens on port 25 for SMTP traffic.

Within a Traffic Manager, all the traffic for a particular service is handled by a “virtual server”. This is the interface between a Traffic Manager and the Internet, and is set up for a specified port and protocol; typically, it will manage all the traffic for that protocol.

When the virtual server receives a request, it assigns it to a “pool”. This is a collection of “nodes”, each corresponding to a back-end server and port, such as server1.example.com:80. The pool load-balances traffic across the nodes. You can set up several pools, which might have nodes in common.

To decide which pool to use for a request, the virtual server can apply a list of “rules”. A rule inspects the incoming request, and decides what action to take with it. It can choose a pool to handle the request, close the request, or pass the request on to the next rule in the list. If no rule makes a positive routing decision, the request is assigned to the virtual server's “default pool”.

If a node in the pool should fail, the Traffic Manager’s “monitors” detect this automatically. Consequently, the Traffic Manager stops sending requests to that node. Traffic is distributed among the other nodes in the pool with no visible disruption to the service.

A Traffic Manager machine can run many virtual servers, one for each service it manages. Each virtual server can use several rules and pools, and various monitors can watch the pools.

Rules and monitors are organized into “Catalogs”. The Rules Catalog, for instance, holds all the rules which have been written for the system. A rule in the catalog can be applied to any virtual server easily. Other shared items, such as SSL certificates and service protection classes, are also held in catalogs.

Two or more Traffic Manager machines can be arranged in a “cluster”. Configuration is shared across all the Traffic Manager machines in the cluster; each machine runs the same virtual servers, using the same rules, and so on.

The public traffic IP addresses used for your services can be arranged into “traffic IP groups”. A traffic IP group spans some or all of the Traffic Managers in the cluster, and these Traffic Managers host the group’s IP addresses between them. If a Traffic Manager machine should fail, one of the other machines in its traffic IP group raises its IP address. This, with the pools’ failover system, gives full fault-tolerance for both front ends and back ends.

While a Traffic Manager is running, hostnames are re-resolved at regular intervals, usually of no more than 5 minutes. This provides an efficient re-resolving of nodes whenever the DNS changes.