Configuring Health Checks using Radware AppDirector
Health monitoring provides a way to continuously test the status of your servers to ensure they are successfully providing the services they are intended for. This ensures availability for your applications by automatically removing faulty servers from the webfarm, guaranteeing a smooth and transparent experience for your end users. This automatic removal also allows the administrator to focus on remediating the problem on the server rather than making emergency changes to remove the server from the farm. The AppDirector provides a wide range of health checks, with or without the health monitoring module, allowing you to health check everything from a simple ping all the way to specific HTTP content checks. Even more brilliant is the ability to health check any Layer 2/Layer 3 element, on any server or network devices, and bind it to an application server. Examples include the ability to bind a health check to a SQL server that directly supports the web servers in Site A or running a health check against a public site to ensure Site A has internet connectivity.
The concept of health monitoring is fairly simple. Providing a number of specific values, the AppDirector will send a request to the server and determine if it’s successful or not. If the request is returned successfully, the check passes. If not, the health check fails. Again, these can be as simple as a ICMP reply, a successful HTTP return code of 200, or as complicated as ensuring a specific string exists on a webpage. The diagram below shows health checks passing on all three servers in a farm, therefore all three servers remain in the farm:
In the event that a health check fails and you have it bound to an application server, the AppDirector will remove it from service and send redirect users to the remaining servers in the farm. This ensures an error-free experience for your end users while giving you the freedom to troubleshoot why server 2 is no longer serving up your application correctly. Additionally, failed health checks can be used, if using GSLB, to fail to a secondary site. For example, if your SQL server in Site A fails to your backup server in Site B, you might want the application to fail to site B to maintain a speedy connection to your database, avoiding potential latency between sites, negatively affecting your application and, eventually, your end users. The diagram below displays a failed health check in which only Server 1 & 3 are active in the farm:
Configuring Health Checks using the Radware AppDirector
Configuration in the Radware AppDirector is fairly simple but I’ll walk you through, step-by-step, in configuring a simple HTTP health check for an application server which looks for a particular string on the page. I prefer this over a typical health check looking for an HTTP return code of 200 as it ensures that IIS is pointed at the correct path on the server.
1) Enable the Health Monitoring Module as it’s disabled by default. To do this, go to Health Monitoring –> Global Parameters and set the Health Monitoring Status to Enabled.
2) Create a health check. Go to Health Monitoring –> Check Table. Click on Create to open the Health Monitoring Check Table Create page.
3) At a minimum, fill out the following fields:
a) Check Name – Name it something informative. Also you might indicate which server you are writing it for as you’ll like have multiple checks for each application
b) Destination Host – IP address the application is utilizing on the server
c) Method – Choose HTTP for this example
d) Arguments – Click the Arguments box to bring up the Arguments window. *Keep in mind that the Method Arguments box will have different fields for different types of Methods.
1) Path – Path of the page you want to health check (i.e. /mywebpage.aspx)
2) Match Search String – Type the string you want to check for (i.e Welcome to My Webpage)
3) Match Mode – String Exists (if the string exists, the health check passes)
e) Other fields to consider:
1) Interval – How frequently (in seconds) you want the health checks to run
2) Timeout – Maximum number of seconds the AppDirector waits for a response to the Health Check
3) Retries – Number of times that a health check must fail before the module reevaluates the server’s availability status
4) Bind the Health Check to an Application Server – Without binding a health check, the module will not fail a server when the health check fails. Bind a Health check by going to Health Monitoring –> Binding Table.
a) Check – Select the Health Check you wish to bind. Same Name as you used in Step 3a above.
b) Server – Select the Application Server you wish to bind the health check to.
Now that your health check is configured, and bound to your application server, you now have some protection against a server/IIS failure. With the above configuration, if IIS is returning a HTTP return code of 400, or if an admin points the website to the wrong path, the AppDirector will catch this mistake, fail the server in the farm and prevent end users from being redirected to it. If you have syslog setup, you can also get email alerts for any failures so you can take action.