SiteBacker

A SiteBacker (SB) pool is a grouping of A or CNAME records that monitors your servers and redirects traffic to a host standby in case of server failure. More simplistically, SiteBacker returns multiple IP addresses in an answer to ensure continual website access.

Monitoring and Failover Service

As your web-based operations become increasingly mission-critical, a server failure can massively disrupt your business — losing customers, impacting employee productivity, and negatively impacting the bottom line. Traditional monitoring and failover solutions that require deploying and supporting expensive hardware and software are cost prohibitive for many enterprises, particularly as the number of mission-critical servers grows exponentially.

The SiteBacker service leverages the UltraDNS Managed DNS infrastructure, a carrier-class DNS services platform that supports a significant portion of key domains on the Internet. Monitoring agents at multiple locations across the globe continually perform standard protocol or transaction-based testing against preselected servers. Each server is monitored by multiple agents to assure testing integrity. If pre-configured thresholds for the number of probes and locations confirming a particular test has failed are exceeded, SiteBacker concludes the corresponding server is down and initiates server failover. This failover mechanism involves automatically modifying the DNS response record for the monitored server. In addition, an email alert is sent to a list of predetermined contacts. When the server is restored to service, SiteBacker automatically recognizes the server’s online status and restores it to in-service by replacing the DNS response record with the original one.

Editing / Viewing a SiteBacker Pool

Sitebacker pools consists of various tabs of additional functions and details allowing you to configure your pool details. After creating your SiteBacker pool, you will be directed to the SiteBacker pool details screen.

 

 

Pool Information

When viewing your SiteBacker pool, the first tab (by default) is the Pool Information. The following Pool Information fields are displayed:

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

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

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

• 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.

  • Note - Probing cannot be set to Disabled unless Failover is set to Disabled.

• Response Method – Determines in what type of order that records will be returned.

  • Fixed – The records will appear in the order in which they are set.

  • Random – The records appear in a completely random order.

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

• Max Served Records - Specifies whether all records will be served, or only a specified number will be.

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

  • This value is automatically updated if you add or delete a record in the pool.

If you make any changes to your Pool Information details, make sure you click the Save button.

 

 

Records List

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

Add a Record

To add a new record to your pool:

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.

   1. The Failover Delay specifies the time that SiteBacker waits after detecting that the pool record has failed before confirming that the record is still in failure and activating secondary records. The default value is 1 minute.

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

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

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

7. You can choose to either Enable(d) or Disable(d) Probes for the record.

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

9. Click Save when you are finished.

 

Records List

The Records list displays your current Sitebacker 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.

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

• 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 green check mark indicates that serving is available, while a red X indicates it is not.

 

 

Add a Sub Pool

To add a Sub Pool to an existing pool:

1. Edit the primary pool by clicking the pencil icon.

2. Click the Add Record button.

3. In the Points To field, provide the existing pool name that you want to use as the sub pool.

4. Complete the rest of the required fields.

5. Click the Save button.

After successfully saving, your subpool will be listed in the Records List section, and the Record Type column will display the type of subpool you added.

 

 

Probe Definitions

There are 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.

 

 

To 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 the selected regional probes will run.

7. Based upon the Probe Type selected, the Probe Transactions section will request different configuration parameters.

8. Click the Save Probe button when you are finished.

 

 

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 Types

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

• 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 Query Name, 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 Query Name, 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

• 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

• 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

• 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).

SMTP Availability and SMTP Send Mail

• 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

• 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.

Scheduled Events

The Scheduled Events tab lists any upcoming events for your pool records, and allows you to schedule various event types to occur per record within the pool. For example, you can schedule an event to test the failover functionality of your pool.

It is important to note that if you schedule an event to perform a certain action, you will either need to schedule an additional event (after wards) to revert the previous action, or resolve it manually. For example, if you schedule an event to Force Fail – Test a record, that record will remain in a not-served state until you create an event to return it to a Normal or Forced-Active state, or if you manually change the record’s state from the SiteBacker pool menu.

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 finished.

 

 

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.

   1. It may be helpful to list a personal email address as a backup to ensure notifications are received.

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.

 

 

Data Flow

Figures in this section indicate:

• Pool probes with dashed lines

• Record probes with solid lines

• Served records with green lines

• Failed records and probes with red lines

The following figure presents a sample SiteBacker Pool serving the fictitious Web site www.example.biz.

The server 10.1.1.1 has the highest priority. Given the pool’s Max Active and Max Served parameters of 1, SiteBacker serves the 10.1.1.1 record in most circumstances.

If the Max Active and Max Served parameters were 2, SiteBacker would serve both 10.1.1.1 and 10.1.1.2 in normal operations. If one of those records failed, SiteBacker would bring up 10.1.1.3. If all records failed, SiteBacker would bring up 10.1.1.4 (the All Fail record).

SiteBacker Pool Example

 

SiteBacker Pool Serving Highest-Priority Record

 

In the next figure, the HTTP pool probe for 10.1.1.1 failed at all three locations, and the FTP record probe failed at one location.

Because the HTTP probe has met its threshold of 3, the probe status changes to failed. However, because the FTP record probe has not met its threshold, its status is good, even though it has failed at one location.

At the record level, only one probe has failed (the HTTP probe), so the record does not meet its threshold of 2, and SiteBacker continues to serve 10.1.1.1.

SiteBacker Pool with Probe Failures Not Meeting Record Threshold

 

If the FTP probe fails at the second location, then the FTP probe status meets its threshold of two, and, because both the HTTP probe and the FTP probes have failed, the 10.1.1.1 record meets its threshold of 2, and the record fails.

This causes SiteBacker to fail the 10.1.1.1 record and serve the record with the next highest priority, 10.1.1.2.

SiteBacker Pool with Failed Record

 

Next, a catastrophe causes the 10.1.1.1, 10.1.1.2, and 10.1.1.3 records to fail (note that to meet the 10.1.1.3 record threshold, 3 probes had to fail). Because SiteBacker cannot serve any records in the active set, it serves the 10.1.1.4 (All Fail) record. The All Fail record may display, for example, a web page stating that the service is down.

SiteBacker Serving the All Fail Record

Sub Pools

You can also create a second SiteBacker or Traffic Controller Pool and configure that pool as a sub-pool to the primary pool. SiteBacker and Traffic Controller treat the sub-pool as an internal reference. In this case, if the sub-pool is an in-domain hostname, the system will serve the sub-pools records as the response. If the sub-pool is a hostname that is outside of the domain, the system will treat it as a CNAME and only deliver the hostname as the response.

SiteBacker Pool with Sub Pool

 

 

 

test link