Deep Dive on Load Balancing: Failover, Site Monitoring and Configuring Alerts

In our previous post we looked at the benefits of load balancing for website availability, such as common topologies and different scenarios for load distribution. In this post I’ll cover failover configuration, site monitoring and configuring alerts.

Global Server Geographic Assignment

If you’re using one of the global load balancing settings, either Geo-targeting required or Geo-targeting preferred, the Add Geography button under Global Server Load Balancing Attributesassigns a region to each of your data centers. For each data center, you can select a specific geographic region. If your topology has servers for handling requests where geographic region doesn’t matter, assign Rest Of The World from the last row of the list.

Origin Server Identification

When you add each origin server to Incapsula for load balancing, you can identify it by IP address or CNAME. You’ll need to use external CNAMEs in place of an explicit IP address when dealing with cloud-based servers, such as Amazon Web Service alias names.

When adding or editing origin servers, the IP Address field under Server IPs accepts either an explicit IP address or a CNAME. Be aware that when you’re configuring origin servers using CNAMEs, you can use only one CNAME per data center.

Failover Configuration in Multiple Data Center Topologies

Failover takes place when you have configured a standby data center. Incapsula doesn’t require configuration for failover conditions in a single data center topology, because the load balancing algorithms automatically take care of individual origin server failures.

You configure failover settings in the Failover Attributes section of the load balancing dashboard. Following are the settings you’ll need to make:

• Standby DC Name – The name of the standby data center. This is the data center to which Incapsula routes requests if all other data centers are unavailable. Note that your standby data center cannot be one of your geo-targeted data centers. If you don’t want to enable failover, select None.
• Monitors required to decide on failover – The number of failed monitoring assessments required before Incapsula stops sending requests to all servers in that data center. Each Incapsula global data center (PoP) constantly monitors the health of each of your data centers. You configure health monitoring to determine how Incapsula assesses the health of your data centers. This parameter determines now many failed assessments must occur before Incapsula stops sending requests to the data center. You can choose from among:
  • One – Only one failed assessment takes the data center off line.
  • More than one – More than one failed assessment must occur to take the data center off line.
  • Most – The majority of health assessments must fail to take the data center off line.
  • All – All assessments must fail to take the data center off line.
• Standby DC Kickstart URL – An optional URL that Incapsula calls when it decides to fail over and bring your standby data center on line. You must configure the URL as a “kickstart” function that initializes the standby data center.
• Credentials for Kickstart URL (if required) – The user name and password required to call the Kickstart URL, if needed.
• Minimum number of servers for “DC UP” – The minimum number of origin servers within each data center that must be available at any given time for Incapsula to consider that data center to be available. If the specified number of servers is not available, Incapsula stops sending requests to all servers in that data center.

Site Monitoring

Incapsula lets you configure various parameters for monitoring the health of your data centers. The settings you configure determine when Incapsula takes a data center off line, according to the settings you make in Monitors required to decide on failover, as described in the preceding topic. You can access the Site Monitoring page by clicking the Monitoring icon in the left navigation menu of the Incapsula management console. Here you’ll find several settings that you can configure to meet your monitoring needs, including:

Monitoring parameters

• Percentage of failed requests to mark a server “Down” – The percentage of failed requests that, if exceeded for the period of time specified in the following parameter, results in Incapsula considering the origin server to be unavailable. Use the parameters under Failed Requests Criteria to define the types of errors that Incapsula considers to be failed requests.
• Mark server as “Down” if failed request percentage is above threshold for the last _____ – The time period during which Incapsula looks for failed requests. Smaller periods make your site more sensitive to short periods of failure.

Failed Requests Criteria

• HTTP Request timeout – The period of time after which Incapsula counts a request as a failure if no response occurs.
• HTTP response error codes to be treated as down – The range or pattern of error codes that Incapsula counts as request failures. You can specify individual codes (404), patterns with wildcards (4xx) or ranges (501-599). Use commas to separate multiple values (404, 407, 501-599).

Note that Incapsula considers all TCP connection errors and TCP timeouts as failed requests.

Verify “Down”/“Up”

• Use verification checks to mark server as “Down” – Select this check box to use Incapsula-generated verification checks to monitor site health. If you enable verification checks, and Incapsula detects that an origin server is down according to your failed request settings, it initiates another request and tests the response to confirm that the origin server is down. You define this request in the URL for monitoring field, and its response in the Expected receive string. Clear this check box if you want Incapsula to verify site health by monitoring only regular site traffic.
• URL for monitoring – The URL suffix (without the http:// prefix) that refers to your site. The default value of “/” instructs Incapsula to access the site’s root. Alternatively, you can specify a specific URL to use to test the origin server’s health. In both cases, Incapsula tests the response according to the rule you define in the Expected receive string.

Note: If you need to specify a port number in this URL, contact Incapsula support.

• Expected receive string (if left empty – per error codes above) – The string you expect to receive from the response to the URL for monitoring. Leave this field empty if you want Incapsula to consider a success any response other than the previously-defined HTTP response error codes to be treated as down. Otherwise, enter a value that must appear within the response string for Incapsula to consider the verification a success.
• Interval for “Up” verifications – The time interval to test an origin server after Incapsula identifies it as down, to determine whether it is up.
• Retries for “Up” verifications – The number of times during each “Up” verification interval that Incapsula retries the test. Only if all tests succeed does Incapsula consider the origin server to be up.

E-mail Alerts

On the Site Monitoring page, you can configure email alerts that Incapsula sends under the scenarios you select.

• Scenarios – The scenarios that can be enabled to generate email alerts. You can choose any combination of the following scenarios:
  • Failover to STBY DC – Select this check box to send an email alert if Incapsula fails over to the standby data center.
  • DC Down – Select this check box to send an email alert when Incapsula determines that a data center is down and fails over to another active data center.
  • Server Down – Select this check box to send an email alert when Incapsula detects that any origin server is down.
• Monitors required to report server/DC as down – The number of failed monitoring assessments required to cause Incapsula to send an email alert. Each Incapsula data center (PoP) constantly monitors the health of each of your data centers and origin servers. You can choose from among:
  • One – Only one failed assessment generates an email alert.
  • More than one – More than one failed assessment must occur to generate an email alert.
  • Most – The majority of health assessments must fail to generate an email alert.
  • All – All assessments must fail to generate an email alert.

Manually Taking a Data Center Offline

If you have multiple data centers covering your client requests (for example, at least two data centers per geographic region), you can take a data center off line at any time without impacting users’ ability to connect to your services. To temporarily take a data center off line, clear the Enabled check box adjacent to the data center name in the Multiple Data Centers Settings dashboard, and then click Save. When you are ready to return the data center to active status, select the Enabled check box, and then click Save.

Control and Visibility

Our cloud-based load balancing solution lets you control and make immediate changes to your server topology. You can instantly add, change, or remove individual origin servers and complete data centers from any web browser, from anywhere in the world. Additionally, you can monitor performance of all of your individual origin servers and data centers by using the Real Time Monitoring feature to keep your services available to your users.

Our live 27/7/365 support is available at any time if you have an issue with performance, configuration, or any other load balancing issue.