Chained Health Checking (Pre-7.1.35)
Contents
1 Introduction
It is possible to performed chained health checks in the LoadMaster. Chaining health checks is much easier in firmware version 7.1.35 and above, with the introduction of the Healthcheck On field. For further information on how to perform chained health checking in version 7.1.35 and above, please refer to the Health Checking, Feature Description.
However, it is also possible to perform chained health checks in versions 7.1-28 to 7.1.34.1, by using fixed weighting, content rules or port following.
1.1 Document Purpose
This document provides example scenarios and instructions on how to perform chained health checking using LoadMasters with versions 7.1-28 to 7.1.34.1.
1.2 Intended Audience
This document is intended to be used by anyone interested in finding out how to perform chained health checking using LoadMasters with versions 7.1-28 to 7.1.34.1.
2 Performing Chained Health Checks - Pre-7.1.35
Chained health checking provides the ability to:
Health check multiple services on multiple ports that are all critical to the health of the Virtual Service
Health check multiple HTTP/HTTPS services on Real Servers that are critical to the health of the Virtual Service
Some options for using chained health checks on firmware versions 7.1-28 to 7.1.34.1 are outlined in the sections below.
2.1 Multi-Port Health Checks
There are a number of ways to perform multi-port health checks:
Using fixed weighting - this method can be used with any Virtual Services
Using content rules - this method can only be used with HTTP and/or HTTPS Virtual Services
Using port following - all health checks can be used if the Virtual Service allows it
The methods above will only work if the client does not need access to the other SubVSs, due to the fact that the Extra Ports field cannot be used with SubVSs. However, you can still use additional Virtual Services instead. For an example of this, please refer to the Multi-Port Health Checks Using Port Following section.
When using extra ports, the destination port on the Real Server is also changed. For example, if:
A Virtual Service is on port 25,
26 is set as an extra port, and;
the Real Server is on port 25 -
A call to port 26 will go to port 26 on the Real Server. Due to how the system works, it is currently not possible to pass this mapping to the SubVS.
In all examples given, traffic is redirected to a single SubVS - either via fixed weights or content rules.
Refer to the relevant section below to find out how to configure the LoadMaster to perform multi-port health checking. These instructions assume the Virtual Service, SubVSs and Real Servers have already been added.
2.1.1 Multi-Port Health Checks Using Fixed Weighting
Multi-port health checks are useful in situations where the primary service (for example, an HTTP server) has critical dependencies on services running on other Real Servers that must be checked using different health checks than the primary service. The client does not directly access these other Real Servers, but if one of them goes down, the entire Virtual Service should be considered unavailable. This can be configured using fixed weighting, as shown below.
In our example scenario, we have:
A Virtual Service on port 80
Three SubVSs:
- One with a Real Server on Port 81, which will only be used to health check Port 81 (TCP Connection Only health checking)
- One with a Real Server on Port 25, which will only be used to health check Port 25 (Mail (SMTP) Protocol health checking)
- One with a Real Server on Port 80, which all traffic will be directed to (HTTP Protocol health checking using a health check URL)
Each SubVS should be marked as Critical, so if any go down the entire Virtual Service will be marked as down.
Fixed weighting will be applied to ensure that all traffic is directed towards the Port 80 Real Server, and no traffic is directed using the other two ports.
Refer to the sub-sections below for instructions on configuring the LoadMaster to perform multi-port health checks using fixed weighting.
2.1.1.1 Set the SubVS Weights
In order for the traffic to always be directed towards the correct SubVS (the port 80 one in the example scenario), set the weights of the SubVSs so that the correct SubVS always has priority (the highest weight), for example:
Port 80 SubVS weight: 1000
Port 81 SubVS weight: 999
Port 25 SubVS weight: 999
To configure fixed weighting, follow the steps below:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the Standard Options section.
In this scenario, the Persistence Mode should be set to None. Another Persistence Mode, such as Active Cookie, can be selected for the SubVSs.
4. Select fixed weighting as the Scheduling Method.
5. Expand the SubVSs section.
6. Click Modify on the relevant SubVS.
7. Enter the SubVS Weight and click Set Weight.
8. Modify the weight for the other SubVSs, as needed by following the steps above.
2.1.1.2 Set the SubVSs as Critical
When using fixed weighting to perform multi-port health checks, the SubVS to which traffic will be directed to needs to be marked as critical. This is to ensure that traffic does not get sent to any of the other SubVSs if the SubVS goes down. To set the SubVS to Critical, follow the steps below:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the SubVSs section.
4. Tick the Critical check box.
5. Repeat the steps above for the other SubVSs.
2.1.2 Multi-Port Health Checks Using Content Rules
For HTTP and HTTPS Virtual Services being used in scenarios like the one described in the Multi-Port Health Checks Using Fixed Weighting section, chained health checks can also be configured using content rules instead of fixed weights. This allows you to choose a load balancing policy other than fixed weighting, while still taking advantage of chained health checks. An example is shown below.
In our example scenario, we have:
A Virtual Service on port 80
In this scenario, the Persistence Mode should be set to None. Another Persistence Mode, such as Active Cookie, can be selected for the SubVSs.
Three SubVSs:
- One with a Real Server on Port 81, which will only be used to health check Port 81 (TCP Connection Only health checking)
- One with a Real Server on Port 25, which will only be used to health check Port 25 (Mail (SMTP) Protocol health checking)
- One with a Real Server on Port 80, which all traffic will be directed to (HTTP Protocol health checking using a health check URL)
Each of the SubVSs are marked as Critical, so if one is marked as down the entire Virtual Service will be marked as down.
Content rules will be applied to ensure that all traffic is directed towards the Port 80 Real Server, and no traffic is directed using the other two ports.
Refer to the sections below for instructions on how to create and assign the content rules, and set the SubVSs to critical.
2.1.2.1 Assign the Default Content Rule to the Relevant SubVS
The default content rule should be assigned to the SubVS with the Real Server on the port which traffic should be directed towards:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the Advanced Properties section.
4. Click Enable on the Content Switching option.
5. Expand the SubVSs section.
6. Click None on the SubVS containing the Real Server to direct the traffic to.
7. Click Add to add the default rule to that SubVS.
2.1.2.2 Create a Content Rule which will Never be Matched
Create a content rule which will never be matched. To do this, follow the steps below:
8. In the LoadMaster WUI, go to Rules & Checking > Content Rules.
9. Click Create New.
10. Enter a name for the rule, for example NeverMatch.
11. Select Content Matching as the Rule Type.
12. Enter some text in the Match String text box.
13. In order to perform multi-port health checks, this rule must never be matched. A way in which this could be ensured, is by setting the Perform If Flag Set field to a flag number which is never set.
14. When finished configuring the rule, click the Create Rule button.
2.1.2.3 Assign the Content Rule to the Relevant SubVSs
This rule then needs to be assigned to the relevant Real Servers. In our example, there are three SubVSs:
One with a Real Server on port 81
One with a Real Server on port 25
One with a Real Server on port 80 which is the same port as the Virtual Service.
We will add the content rule to the SubVSs with the Real Servers on port 81 and 25. To add the content rule to a SubVS, follow the steps below:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the Advanced Properties section.
4. Expand the SubVSs section.
5. Click None in the Rules column for the Real Server to add the rule to.
6. Select the rule which was created previously from the Rule drop-down list, and click Add.
7. Repeat the previous two steps to add the rule to any other SubVSs, as needed.
Do not add the rule to the SubVS where you want to direct the traffic to, because the rule will never be met.
2.1.2.4 Set the SubVSs as Critical
To set the SubVSs as critical, follow the steps below:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the SubVSs section.
4. Tick the Enhanced Options check box.
5. Select the desired number for the Minimum number of RS required for VS to be considered up drop-down list.
6. Tick the Critical check box for each relevant SubVS.
2.1.3 Multi-Port Health Checks Using Port Following
HTTP and HTTPS Virtual Services are sometimes used together with Port Following enabled, so that client requests sent via HTTP can be seamlessly redirected to HTTPS services. In this scenario, both the HTTP Virtual Service and the HTTPS Virtual Service have the same IP:port combination, and Port Following is enabled on the HTTPS Virtual Service. In this example, two URLs will be health checked; both the URL to which the client will connect and another URL that must be available in order for the Virtual Service to be considered healthy. An example is shown in the diagram below.
Here are some points about the example scenario above:
- The Service Type field in the Virtual Service must be set to HTTP/HTTPS.
- There are two parent Virtual Services - one on port 80 and one on port 443.
- Port following is enabled on both of the parent Virtual Services. For step-by-step instructions on how to do this, please refer to the Port Following, Feature Description.
- Each of the parent Virtual Services have two SubVSs.
- The Scheduling Method for the parent Virtual Service is set to Fixed Weighting.
- The Persistence Mode needs to be the same in both Virtual Services.
- The IP addresses of both Virtual Services must be the same.
- All SubVSs are marked as Critical, so if one goes down, the parent Virtual Service will be marked as down.
- The weight of the SubVSs which traffic should be directed towards should be set to a higher value than the other SubVSs. In our example, it is set to 1000. This is to ensure that all traffic gets directed to those SubVSs.
- Real Servers 1 and 2 are added to each of the SubVSs.
- Health checks are performed on different ports and health check URLs.
2.1.3.1 Set the Scheduling Method to Fixed Weighting on the Parent Virtual Services
To simplify the scheduling, the Scheduling Method of the parent Virtual Services should be set to fixed weighting. The Scheduling Method for the SubVSs should be set to something else, depending on the environment. For instructions on how to set the scheduling method, follow the steps below:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the Standard Options section.
In this scenario, the Persistence Mode should be set to None. Another Persistence Mode, such as Active Cookie, can be selected for the SubVSs.
4. Select fixed weighting as the Scheduling Method.
5. In order to set the Scheduling Method of the SubVS, expand the SubVSs section, click Modify on the relevant SubVS and select a different Scheduling Method from the drop-down list in the Standard Options section.
2.1.3.2 Set the SubVS Weights
In our example scenario, the weight of SubVS 1 is set to 1000. To configure the weight, follow the steps below:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the SubVSs section.
4. Click Modify on the relevant SubVS.
5. Enter the SubVS Weight and click Set Weight.
6. Modify the weight for the other SubVS, as needed by following the steps above.
2.1.3.3 Set the SubVSs as Critical
In this example scenario, each of the SubVSs are marked as critical. This means - if any of the SubVSs go down, the parent Virtual Service will be marked as down. Follow the steps below to set the SubVSs as critical:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the SubVSs section.
4. Tick the Critical check box.
5. Repeat these steps as needed to set the other SubVS as critical.
2.1.3.4 Set the Health Check URLs
Follow the steps below to set the health check URLs for the Real Server:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the SubVSs section.
4. Click Modify.
5. Expand the Real Servers section.
6. Enter the health check URL and click Set URL.
7. Repeat these steps to set the other health check URL for the Real Servers.
2.2 Chained Health Checks using Different Health Check URLs
The Multi-Port Health Checks section provides example scenarios using multi-port health checking. This section provides an example scenario which does not use multi-port health checking but instead uses different health check URLs.
This is essentially the same example configuration used in the HTTPS Virtual Service in the previous section (Multi-Port Health Checks Using Port Following), with these differences:
- Port following is not enabled, so there is no HTTP Virtual Service shown
- The Real Servers with the /index.html URL are on port 443 rather than port 80
In the example scenario above, there is:
- A parent Virtual Service on port 443.
- Two SubVSs which are both marked as critical - so if one goes down the parent Virtual Service will be marked as down.
- The weight of the SubVS that you want to direct traffic to should be set higher than the other SubVS weights - in this scenario it is set to 1000.
- To help simplify the scheduling, set the Scheduling Method to fixed weighting on the parent Virtual Service, and another Scheduling Method for the SubVSs.
- The same Real Server is added to both SubVS 1 and SubVS 2.
- Different health check URLs are specified for the Real Server health check in each of the SubVSs.
2.2.0.1 Set the Scheduling Method to Fixed Weighting on the Parent Virtual Service
To simplify the scheduling, the Scheduling Method of the parent Virtual Service should be set to fixed weighting. The Scheduling Method for the SubVSs should be set to something else, depending on the environment. For instructions on how to set the scheduling method, follow the steps below:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the Standard Options section.
In this scenario, the Persistence Mode should be set to None. Another Persistence Mode, such as Active Cookie, can be selected for the SubVSs.
4. Select fixed weighting as the Scheduling Method.
5. In order to set the Scheduling Method of the SubVS, expand the SubVSs section, click Modify on the relevant SubVS and select a different Scheduling Method from the drop-down list in the Standard Options section.
2.2.0.2 Set the SubVS Weights
To configure fixed weighting, follow the steps below:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the SubVSs section.
4. Click Modify on the relevant SubVS.
5. Enter the SubVS Weight and click Set Weight.
6. Modify the weight for the other SubVS, as needed by following the steps above.
2.2.0.3 Set the SubVSs as Critical
Follow the steps below to set the SubVSs as critical:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the SubVSs section.
4. Tick the Critical check box.
5. Repeat these steps as needed to set the other SubVS as critical.
2.2.0.4 Set the Health Check URLs
Follow the steps below to set the health check URLs for the Real Server:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > View/Modify Services.
2. Click Modify on the relevant Virtual Service.
3. Expand the SubVSs section.
4. Click Modify.
5. Enter the health check URL and click Set URL.
6. Repeat these steps to set the other health check URL for the Real Server in the other SubVS.
References
Unless otherwise specified, the following documents can be found at http://kemptechnologies.com/documentation.
Health Checking, Feature Description
Port Following, Feature Description
Last Updated Date
This document was last updated on 07 December 2020.