Skip to main content

Please log into UltraDNS for full Help Center and Community access

Traffic Controller Pool

Updated

A Traffic Controller (TC) pool is a grouping of A or CNAME records that extends SiteBacker as a Global Server Load Balancing solution. Traffic Controller and SiteBacker pools are very similar in their makeup, therefore in this guide, certain tabs may be referred back to the SiteBacker section that has already explained their usage.

Creating a TC Pool

  1. Select either an A or AAAA record type, and then click the +Add Pool button.

  2. Select Traffic Controller (TC) from the Select Pool Type drop-down menu.

  3. Provide the Host and the Points To fields.

  4. Click Save when finished.

 

Editing a TC Pool

Traffic Controller pools consists of various tabs of available functions and details that beyond just displaying associated records. So when editing a Traffic Controller pool, there are multiple sections that you can edit.

Pool Information

  1. Once the pool is created, you will be taken to the Traffic Controller Pool display.

    1. You can also click the pencil icon next to the Traffic Controller pool from your records section to navigate to this section.

  2. From the Pool Information tab, you will see the following details you can edit:

    1. Description – Defaults to the pool name. The description can be a maximum of 255 characters.

    2. Pool Type – Displays if the pool is a Sitebacker pool, or a Traffic Controller pool. This field cannot be edited.

    3. Failover – Select Enabled if you want to enable a failover record, or Disabled if you wish to only serve the primary record.

    4. Probing– When probing is Enabled, a probe can be sent to verify that a URL can be reached, and that the record can be served.

      1. Note – Probing cannot be set to Disabled unless Failover is set to Disabled.

    5. Max Active to LB - Specifies the maximum number of active servers in the pool, and determines when Traffic Controller takes backup servers offline. For example, consider a pool with six servers. Setting Max Active to 4 means Traffic Controller takes two servers offline and sends the four active records in the answer.

    6. TTL - Specifies the Time to Live value for the pool.

    7. Configured - Displays the current number of records (including sub-pools) in the pool.

    8. Failure Threshold - Select from the drop-down menu the number of priority records, which indicates the minimum number of records that must fail for a pool to be labeled 'FAILED'. If the number of failed records in the pool is greater than or equal to the 'Failure Threshold' value, the pool will be labeled FAILED.

  3. Click Save once you make any of your changes.

 

Records List

The Records List displays all of the currently associated records to the Traffic Controller pool. From this section, you can Add, Edit, or Delete records from the pool list as needed.

Add a Record

  1. Click the +Add Record button.

  2. Provide the IP address or hostname for the record in the Points To field.

  3. Select the Failover Delay value from the drop-down menu, which is measured in minutes.

  4. Provide an even integer value for the Weight for the record.

    1. The Weight value determines the traffic load to send to each server in the pool.

  5. Check the box to designate if this record will be a part of the All Fail record(s) or not.

  6. Select the Probe Threshold value from the drop-down menu.

  7. Select the Record State value from the drop-down menu.

  8. Choose whether to Enable or Disable Probes for the record.

  9. Provide an integer value for the Priority of the record.

  10. Click Save when you are finished.

 

Viewing the Records List

The Records list displays your current Traffic Controller pool records as follows:

  • Points To - Displays the IPv4 address or hostname for the record.

  • Record Type - The available record types can include A, SB (SiteBacker) / TC (Traffic Controller), or CNAME.

  • Record State- Lists how the record should behave.

    • The default value, Normal, indicates that a pool record succeeds and fails with normal behavior (that is, SiteBacker serves records with the highest priority first).

    • Force Fail - Forces a record into a not-served state.

    • Force Active - Forces a record into a served state.

  • Status- The current status of Record which can be one of the following:

    • OK - The number of records serving is equal to the Max Active value, and all the active records are top priority records. For example, if a pool has a Max Active of 1 and the Priority 1 record is serving, the pool will be marked OK.

    • WARNING - The number of records serving is equal to the Max Active value, and the active records are not top priority records. For example, if a pool has a Max Active of 1 and the Priority 1 records is not serving and the Priority 2 record is serving, the pool will be marked WARNING.

    • CRITICAL - The number of records serving is less than the Max Active value, or the All Fail record is being served. For example, if a pool has a Max Active of 2, and only one record is serving, the pool will be marked CRITICAL.

    • FAILED - No records are serving and there is no All Fail record configured, or the Failure Threshold has been reached.

  • Probing - Signifies if Probing is enabled for the record or not.

  • Weight – The integer value that helps determine the traffic load that is sent to each server in the pool.

  • Priority - Displays the priority value for the records, which is used to determine the order in which records are returned via the Response Method.

  • Serving - Signifies if the record is Available to Serve or not (meaning if a probe was successful or not). A check mark indicates that serving is available, while an X indicates it is not.

 

Probes

The Probes list includes Enabled (the default) or Disabled.

Tip: Combinations of the Record State and Probes states produce the following results:

  • Record State Force Active + Probes Enabled = forces a record into a served state and probes the record, but does not act on the results.

  • Record State Force Active + Probes Disabled = forces a record into a served state and does not probe the record.

  • Record State Force Fail + Probes Enabled = forces a record into a not-served state and probes the record, but does not act on the results.

  • Record State Force Fail + Probes Disabled = forces a record into a not-served state and does not probe the record.

Probe Definitions

There are two types of probes:

  • Pool probes - These probe types probe all records in a pool.

  • Record probes - These probe types probe only a specific record.

Within these two types of probes, are seven probe classes: DNS, FTP, HTTP, Ping, Proxy, SMTP, and TCP.

 

Create a Probe

  1. Click the +Add Probe button.

  2. Select the Probe Type (class) from the drop-down menu.

  3. Select the Host Type, which can either be Pool, or a specific record within your pool.

  4. Click in the Select Regions box to select a maximum of four regions to possibly probe from.

  5. Select the Region Threshold value from the drop-down menu. This will determine how many probe failures are required before a failover occurs.

  6. Select the Probe Interval value from the drop-down menu. This will determine how often a probe runs.

  7. Based upon the Probe Type selected, the Probe Transactions section will request specific probe details.

  8. Click the Save Probe button when you are finished

Probe Types and Definitions

All probes require a Probe Interval (30 seconds or 1-15 minutes) and an Agent Threshold. The Agent Threshold is the number of agents running the probe that must fail for SiteBacker/Traffic Controller to consider the probe failed. Records also have thresholds to determine the number of probes that must fail for SiteBacker/Traffic Controller to fail the record and possibly take further action.

DNS Probes

  • A DNS probe verifies a DNS service. This probe requires two fields: Port (defaults to 53) and TCP only (defaults to No, which means that the probe uses UDP first, and then TCP if the UDP fails; Yes skips UDP and just uses TCP). If you set the Resource Record type to NULL and leave the Name to query blank, the application sends a bogus A record query and expects a name error in response, thus verifying the DNS service. You can complete these fields with valid data for your site.

  • If you select a record in the Resource Record type list and leave Name to query blank, the DNS probe ensures the query returns a properly formatted response.

  • If you select a record in the Resource Record type list and complete the Name to query, the DNS probe ensures the appropriate record responds to the query. The Resource Record Type AXFR tests if an AXFR (complete zone transfer) completed successfully. AXFR ignores the Response field.

FTP Probe

  • The FTP probe verifies an FTP service. This probe requires Port (typically 21), Passive Mode (if Yes, initiates both connections to the FTP server), and Path to file (for example, /pub/testfile)

  • You can also specify a username and password, if required by your FTP service.

HTTP/HTTPS Probe

  • The HTTP probe verifies an HTTP service by making a request to a web server and testing the response. Any status code in a response other than a number in the 200's (including 301 - Moved Permanently) will fail a probe, regardless of a specified search string.

  • The HTTP probe requires Port (typically 80 for HTTP and 443 for HTTPS), Host name, Web page, Protocol (HTTP or HTTPS), and Method (GET or POST). The Transmitted Data field applies to the POST method only.

  • If Follow Redirects is set to Yes (default is No), and you have configured Web Forwarding redirection, then SiteBacker will follow the redirection with these restrictions:

  • For DNS-level and web server-level redirects, SiteBacker will follow 300, 301, 302, and 307 redirect codes. For DNS-level and web server-level redirects, SiteBacker will not follow HTTP 303, 304, 305, and 306 redirect codes.

  • If IP addresses are pool records in a Load Balancing pool, and the domain name is the hostname for the Load Balancing pool, SiteBacker will not recognize the DNS-level redirect; however, if the domain name is a CNAME pool record, SiteBacker will recognize the DNS-level redirect.

  • If the domain name (example.com) is a CNAME pool record in a Load Balancing pool, redirects from example.com/pageA.html to example.com/pageB.html will not work, and the HTTP probe will fail.

  • If a non-apex level host name (hostname.example.com) is configured as a CNAME pool record in a Load Balancing pool, then a redirect to another host name will not work and the HTTP probe will fail.

Ping Probe

  • The ping probe determines if a host is reachable across the network via the ICMP echo request/reply protocol (also known as ping).

  • The ping probe requires Number of packets (defaults to 3) and Size of packets (does not include the IP and ICMP headers and defaults to 56 bytes).

Proxy Probe

  • The proxy probe connects to a proxy server and has it request the specified URL.

  • The proxy probe requires the URL and Port.

SMTP Availability and SMTP Send Mail Probes

  • The SMTP probes test a mail server.

  • SMTP Availability requires the Port (default 25), Connect time and Run time.

  • SMTP Send Mail requires the Port (default 25), Mail From Address, Mail To Address, Connect time and Run time.

TCP Probe

  • The TCP probe attempts connection to a specified port (Port is the only required field). If you specify a Control IP Address, you can provide a control mechanism that allows the web administrators to stop the TCP port on the control system and thus cause a failover of resources to backup resources.

HTTP Probe Transaction

Configuring an HTTP Probe Transaction allows you to configure and customize specific probing attributes and expected results for your Probe.

 

The HTTP Probe Transaction consists of the following fields.

  • URL – The URL that is being probed. You can select the Validate URL button to ensure the URL you are attempting to probe is a valid URL that can be reached.

  • Version – The HTTP Method version number for the server.

    • HTTP/1

    • HTTP/1.1

    • HTTP/2

  • Method – The type of method to determine the results of the Probe Transaction.

    • GET

    • POST

  • Transmitted Data - Allows you to provide specific details to be included with the Probe details.

  • Follow Redirect - Indicating Yes or No will determine if the Probe will continue to the redirected URL (if there is one), or return the results based upon the URL initially indicated.

  • Expected HTTP Response - Select from the drop-down menu the response type that is expected to be returned by the probe when returned.

  • Advanced Options – Selecting the Advanced Option will allow you to provide a custom HTTP code, or multiple codes.

  • Probe Fail Specifications – The Probe Fail Specifications allow you to configure various custom parameters for the probe, that include run duration time, and search string parameters.

 

HTTP probes will only correctly work if the indicated server supports the configured HTTP protocol version, otherwise the probe will fail. Meaning, if your server is not configured for HTTP/2, and you have indicated HTTP/2 as the Protocol Version, the probe will fail.

 

Once you have configured a Probe Transaction, click the Done button to add it to the Probe.

Scheduled Events

The Scheduled Events tab lists any upcoming events for your pool records. For example, you can schedule an event to test the failover functionality of your pool.

Schedule an Event

  1. Click the +Add Event button.

  2. From the Select Host drop-down menu, select a record.

  3. Select an Event Type from the drop-down menu:

    1. The default value, Normal, indicates that a pool record succeeds and fails with normal behavior (that is, SiteBacker serves records with the highest priority first).

    2. Force Active - Test forces a record into a served state and probes the record, but does not act on the results.

    3. Force Active - No Test forces a record into a served state and does not probe the record.

    4. Force Fail - Test forces a record into a not-served state and probes the record, but does not act on the results.

    5. Force Fail - No Test forces a record into a not-served state and does not probe the record.

  4. Select how the Notify On configuration should be set.

    1. Never Notify - You won't receive notifications related to the scheduled events.

    2. Notify only on error - You will only receive an email notification if there is an error or failure.

    3. Notify on error and success - You will receive an email notification for both failures and successes.

  5. Select the check box for Recurring Event if you wish to schedule this event more than once.

  6. Select the Event Start by either typing in a date by following the designated format, or by using the calendar icon. Additionally, you can set the specific hour and minute you want the event to begin.

  7. Click Save when you are finish.

 

Notifications

The Notifications tab allows you to add email addresses that you can then associate different notification types to.

  1. In the Email List section, provide a valid email address in the addr-spec format. Multiple email addresses can be separated with a space or comma.

  2. Once an email address is provided, select the different event types for each record that you want to receive notifications for.

    1. Probe Event

    2. Record Event

    3. Scheduled Event

  3. Click Save once you've added the necessary email addresses, and selected the notification types per record that you want to receive.

 

Alerts

The Alerts section displays all of the alerts for the pool's probes. The alerts page is laid out as follows:

  • Latest Probe Status - Displays the most recent returned probe status result.

  • IP Address - Displays the IP Address that was probed / associated to the probe.

  • Probe Type - Displays whether the Probe was a POST (send a request) or a GET (receive a response).

  • Date/Time - The Date and Time in which the alert occurred.

Click on the link for the probe alert to obtain additional alert details.

Tip: Add an email addresses to the Notifications section for automatic event notifications.

 

 

Was this article helpful?
0 out of 0 found this helpful
Return to top

Related articles