Technical Note - Chained Health Checking Pre - 7.1.35

 

1Introduction

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.1Document 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.2Intended 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.

2Performing 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.1Multi-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 Section 2.1.3.

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.1Multi-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.

Figure 2‑1: Multi-Port Health Checks - Fixed Weighting Example

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.

1

2

2.1

2.2

2.3

2.4

2.4.1

2.4.1.1

2.1.1.1Set 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the Standard Options section.

Figure 2‑2: Fixed Weighting

In this scenario, the Persistence Mode should be set to None. Another Persistence Mode, such as Active Cookie, can be selected for the SubVSs.

  1. Select fixed weighting as the Scheduling Method.
  2. Expand the SubVSs section.
  3. Click Modify on the relevant SubVS.

Figure 2‑3: SubVS Weight

  1. Enter the SubVS Weight and click Set Weight.
  2. Modify the weight for the other SubVSs, as needed by following the steps above.
2.1.1.2Set 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the SubVSs section.

Figure 2‑4: Critical

  1. Tick the Critical check box.
  2. Repeat the steps above for the other SubVSs.

2.1.2Multi-Port Health Checks Using Content Rules

For HTTP and HTTPS Virtual Services being used in scenarios like the one described in Section 2.1.1, 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.

Figure 2‑5: Multi-Port Health Checks - Content Rule Example

In our example scenario, we have:

  • A Virtual Service on port 80
  • In this scenario, the Persistence Modeshould 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.4.1.2

2.4.1.3

2.1.2.1Assign 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the Advanced Properties section.

Figure 2‑6: Advanced Properties

  1. Click Enable on the Content Switching option.
  2. Expand the SubVSs section.

Figure 2‑7: Add Content Rule

  1. Click None on the SubVS containing the Real Server to direct the traffic to.

Figure 2‑8: Add Rule

  1. Click Add to add the default rule to that SubVS.
2.1.2.2Create a Content Rule which will Never be Matched

Create a content rule which will never be matched. To do this, follow the steps below:

  1. In the LoadMaster WUI, go to Rules & Checking > Content Rules.
  1. Click Create New.

Figure 2‑9: Create Rule

  1. Enter a name for the rule, for example NeverMatch.
  2. Select Content Matching as the Rule Type.
  3. Enter some text in the Match String text box.
  4. 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.
  1. When finished configuring the rule, click the Create Rule button.
2.1.2.3Assign 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.
  1. Click Modify on the relevant Virtual Service.
  1. Expand the Advanced Properties section.
  2. Expand the SubVSs section.

Figure 2‑10: Rules

  1. Click None in the Rules column for the Real Server to add the rule to.

Figure 2‑11: Select Rule

  1. Select the rule which was created previously from the Rule drop-down list, and click Add.
  2. 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.4Set 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the SubVSs section.

Figure 2‑12: Real Servers section

  1. Tick the Enhanced Options check box.
  2. Select the desired number for the Minimum number of RS required for VS to be considered up drop-down list.

Figure 2‑13: Critical

  1. Tick the Critical check box for each relevant SubVS.

2.1.3Multi-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.

Figure 2‑14: Multi-Port Health Checks Using Port Following

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.d
  • 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.1Set 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the Standard Options section.

Figure 2‑15: Fixed Weighting

In this scenario, the Persistence Mode should be set to None. Another Persistence Mode, such as Active Cookie, can be selected for the SubVSs.

  1. Select fixed weighting as the Scheduling Method.
  1. 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.2Set 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the SubVSs section.
  3. Click Modify on the relevant SubVS.

Figure 2‑16: SubVS Weight

  1. Enter the SubVS Weight and click Set Weight.
  2. Modify the weight for the other SubVS, as needed by following the steps above.
2.1.3.3Set 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the SubVSs section.

Figure 2‑17: Critical

  1. Tick the Critical check box.
  2. Repeat these steps as needed to set the other SubVS as critical.
2.1.3.4Set 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the SubVSs section.
  3. Click Modify.
  4. Expand the Real Servers section.

Figure 2‑18: Health Check URL

  1. Enter the health check URL and click Set URL.
  2. Repeat these steps to set the other health check URL for the Real Servers.

2.2Chained Health Checks using Different Health Check URLs

Section 2.1 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 2.1.3, 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

Figure 2‑19: Chained health checks - different health check URLs

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.1.1Set 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the Standard Options section.

Figure 2‑20: Fixed Weighting

In this scenario, the Persistence Mode should be set to None. Another Persistence Mode, such as Active Cookie, can be selected for the SubVSs.

  1. Select fixed weighting as the Scheduling Method.
  1. 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.1.2Set 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the SubVSs section.
  3. Click Modify on the relevant SubVS.

Figure 2‑21: SubVS Weight

  1. Enter the SubVS Weight and click Set Weight.
  2. Modify the weight for the other SubVS, as needed by following the steps above.
2.2.1.3Set 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the SubVSs section.

Figure 2‑22: Critical

  1. Tick the Critical check box.
  2. Repeat these steps as needed to set the other SubVS as critical.
2.2.1.4Set 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.
  1. Click Modify on the relevant Virtual Service.
  2. Expand the SubVSs section.
  3. Click Modify.

Figure 2‑23: Health Check URL

  1. Enter the health check URL and click Set URL.
  2. 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

Document History

Date

Change

Reason for Change

Version

Resp.

July 2016

Initial draft

First draft of document

1.0

LB

Was this article helpful?

0 out of 0 found this helpful

Comments