Notes from MS Learn AZ-700 Module 4: Load balance non-HTTP(S) traffic in Azure – Unit 5: Explore Azure Traffic Manager
Azure Traffic Manager is DNS based. Allows distribution of traffic to public facing apps across global Azure regions. Also, public endpoints with HA and fast response.
Uses DNS to direct client requests to service endpoint based on traffic-routing. Also has health monitor for endpoints. Endpoint can be internet-facing service inside or outside Azure. Offers range of traffic-routing methods. Endpoint monitoring options suit different app requirements and automatic failover. Resilient to failure even of an entire region
- Key Features
- (Table below from MS Learn)
-
- (Table below from MS Learn)
- How Traffic Manager Works
- Enables control of traffic distribution across app endpoints. Endpoint = internet-facing hosted inside/outside Azure
- Traffic Manager Key Benefits
- Distribution of traffic per one of traffic-routing methods
- Continuous monitoring of endpoints and auto failover when endpoints fail
- Client must first resolve DNS name to IP. Client connects to IP of services
- Traffic Managers utilizes DNS to direct client to endpoint based on rules of traffic-routing method.
- Client connects to selected endpoint directly
- Traffic Manager isn’t proxy or gateway, does not see traffic between client and service
- DNS Level with is App layer (L7)
- Traffic Manager example deployment
- Example Steps
- Deploy 3 instances of service.
- DNS names are different
- Create Traffic Manager Profile
- Configure to use Performance traffic-routing method across the 3 endpoints
- Configure vanity domain name
- Points to traffic manager profile name using DNS CNAME record
- Deploy 3 instances of service.
- Example Steps
- Traffic Manager client usage example
- Client request follows example steps
- Client queries DNS to configured recursive DNS service to resolve Traffic Manager profile name
- Recursive DNS finds name server for DNS name to lookup name servers for main DNS and returns CNAME record
- Recursive DNS service finds trafficmanager name provided by trafficmanager service
- Traffic Manager name server choose endpoint based on
- Configured state of endpoint
- Health of endpoint (based on health checks)
- Chosen traffic-routing method
- Chosen endpoint CNAME returned
- Recursive lookup for A record of primary domain
- Client receives DNS results to connect to given IP directly
- Recursive DNS caches responses it receives. DNS on client also caches results.
- TTL on caches can be as low as 0 sec and and high as 2,147,483,647 sec (per RFC-1035)
- Client request follows example steps
- Traffic routing methods
- Six possible per profile.
- (Table below from MS Learn)
-
- Routing Method Examples
- Priority
- Priority traffic-routing method
- Weighted
- Weighted traffic-routing method
- Performance
- Performance traffic-routing method
- Geographic
- Traffic Manager Profiles
- Only one routing method at a time. Select from different routing method at any time. Changes applied within 1 minute – no downtime
- All Traffic Manager profiles include health monitoring and automatic endpoint failover
- See Nested Traffic Manager profiles
- Nested Traffic Manager Profiles
- Since Traffic Manager profiles can only specify one routing method you have to nest to combine
- Parent profile sends traffic as normal
- Traffic Manager Endpoints
- Azure Traffic Manager allows control on how net traffic is distributed to app deployments running in different DCs
- Configure each app deployment as an endpoint in Traffic Manager
- When TM receives DNS request, it chooses an endpoint to return for DNS response
- Bases choice on endpoint status and traffic-routing method
- Three endpoint types
- Azure endpoint
- Use to load-balance traffic to cloud service, web app, or public IP in same subscription in Azure
- External endpoint
- Use to load balance traffic for IPv4/6 addr, FQDN, or services outside Azure
- On-prem or hosted with different hosting provider
- Nested endpoint
- Use to combine TM profiles to create flexible traffic-routing for complex deployments
- Child profile added as endpoint to parent profile
- Child and parent can contain other endpoints of any type
- Azure endpoint
- Visit Traffic Manager endpoints
- Configuring Traffic Manager Profiles
- Example Steps
- Search and Select Traffic Manager Profile from Azure Portal
- Select Create
- Enter values
- Name – Unique name for profile
- Routing Method
- Subscription
- Resource Group – Existing or create new
- Resource Group Location – Azure TM is global. This refers to location of selected RG
- Click Create
- Add endpoints to TM profile
- From portal select All Resources
- Select TM profile
- Under Settings click Endpoints > Add
- Enter required values
- Type
- Azure endpoint
- External endpoint
- Nested endpoint
- Name – Unique to endpoint
- Target resource type (for Azure endpoints only) – if Azure endpoint
- Cloud service
- App Service
- App Service slot
- Public IP address
- Target resource (for Azure and Nested endpoints only)
- Target Service
- IP address
- Profile
- FQDN or IP (for External endpoints only)
- Specify FQDN or IP for endpoint
- Type
- Priority
- If 1 all traffic goes to this endpoint when healthy
- Minimum child endpoints (nested only)
- Specify min number of endpoints available in child TM profile for it to receive traffic
- If threshold not reached, endpoint considered degraded
- Customer Header (optional)
- Configure customer headers for endpoint with format
- Host:domain.com,customerheader:name
- Max pairs = 8
- HTTP and HTTPS
- Overrides settings configured in profile
- Configure customer headers for endpoint with format
- Add as disabled (optional)
- Disabling endpoint in TM can be useful to temp remove traffic from endpoint in maintenance or redelployment
- Once running can be re-enabled
- Click Add
- If adding failover endpoint for another region, add endpoint for said region. App target in other region has priority of 2
- When adding endpoints to TM profile status is checked
- Once validated Monitor status becomes “Online”
- Example Steps
- Configuring endpoint monitoring
- Azure Traffic Manager has build-in endpoint monitoring and auto endpoint failover to aid in delivering HA apps resilient to endpoint failure including Azure region failures
- Example Steps
- Open Config page for TM profile
- Under Endpoint Monitor settings specify settings
- (Table below from MS Learn)
- Click Add
- If adding failover endpoint for another region
- Add another endpoint for that region
- App target resource in other region and priority setting 2
- When endpoints added to TM profile, status is checked
- Once checked should result in Monitor Status of Online
- Configuring Endpoint Monitoring
- Azure Traffic Manager has built-in endpoint monitoring with auto failover
- Sample steps
- Open Configuration page for Traffic Manager Profile
- Under endpoint monitor settings (Table below from MS Learn)
- Setting Description Protocol Chooses HTTP, HTTPS, or TCP as the protocol that Traffic Manager uses when probing your endpoint to check its health. HTTPS monitoring doesn’t verify whether your TLS/SSL certificate is valid; it only checks that the certificate is present. Port Chooses the port used for the request. Path This configuration setting is valid only for the HTTP and HTTPS protocols, for which specifying the path setting is required. Providing this setting for the TCP monitoring protocol results in an error. For HTTP and HTTPS protocol, give the relative path and the name of the webpage or the file that the monitoring accesses. A forward slash (/) is a valid entry for the relative path. This value implies that the file is in the root directory (default). Custom Header settings This configuration setting helps you add specific HTTP headers to the health checks that Traffic Manager sends to endpoints under a profile. The custom headers can be specified at a profile level to be applicable for all endpoints in that profile and / or at an endpoint level applicable only to that endpoint. You can use custom headers for health checks of endpoints in a multitenant environment. That way it can be routed correctly to their destination by specifying a host header. You can also use this setting by adding unique headers that can be used to identify Traffic Manager originated HTTP(S) requests and processes them differently. You can specify up to eight header:value pairs separated by a comma. Example – header1:value1, header2:value2 Expected Status Code Ranges This setting allows you to specify multiple success code ranges in the format 200-299, 301-301. If these status codes are received as response from an endpoint when a health check is done, Traffic Manager marks those endpoints as healthy. You can specify a maximum of eight status code ranges. This setting is applicable only to HTTP and HTTPS protocol and to all endpoints. This setting is at the Traffic Manager profile level and by default the value 200 is defined as the success status code. Probing interval This value specifies how often an endpoint is checked for its health from a Traffic Manager probing agent. You can specify two values here: 30 seconds (normal probing) and 10 seconds (fast probing). If no values are provided, the profile sets to a default value of 30 seconds. Visit the Traffic Manager Pricing page to learn more about fast probing pricing. Tolerated number of failures This value specifies how many failures a Traffic Manager probing agent tolerates before marking that endpoint as unhealthy. Its value can range between 0 and 9. A value of 0 means a single monitoring failure can cause that endpoint to be marked as unhealthy. If no value is specified, it uses the default value of 3. Probe timeout This property specifies the amount of time the Traffic Manager probing agent should wait before considering a health probe check to an endpoint a failure. If the Probing Interval is set to 30 seconds, then you can set the Timeout value between 5 and 10 seconds. If no value is specified, it uses a default value of 10 seconds. If the Probing Interval is set to 10 seconds, then you can set the Timeout value between 5 and 9 seconds. If no Timeout value is specified, it uses a default value of 9 seconds.
- Click Save
- How endpoint monitoring works
- When monitoring is set as HTTP or HTTPS TM probing makes GET requests to endpoint.
- Endpoint healthy if probe receives a 200-OK response or any response configured in Expected status code ranges
- When monitoring protocol is TCP TM probe creates TCP connection requests using port configured
- If endpoint responds with establishment it’s considered a success
- TM probe resets TCP connection
- If response different value or no response within timeout probe reattempts according to Tolerated Number of Failures
- No reattempts if set to 0
- If higher than value endpoint unhealthy
- In all cases TM probe from multiple locations
- Consecutive failure determines what happens in each region
- Endpoints receiving probes from TM with higher frequency
- For HTTP/HTTPS common practice on endpoint is a custom page in app to check
- All endpoints in TM profile share monitoring settings – if different needed create nested TM profiles
- When monitoring is set as HTTP or HTTPS TM probing makes GET requests to endpoint.