Working with Probes

Learn about the general principles behind probes and see practical examples of probes being used.

With the OVHcloud Load Balancer, you can distribute a front-end’s incoming traffic across a set of servers in a destination cluster.

There may be instances where a server in your cluster becomes unavailable for some reason, including oversaturation, an incident, or scheduled maintenance. When the OVHcloud Load Balancer detects a connection error, it will try to redirect traffic to another server. The connection will be slower, but it will continue to work.

However, the reasons behind certain types of unavailability can be harder to pinpoint. For example, if a new version of code is being deployed, the application may momentarily experience a glitch and return a 500 error. In this particular case, a solution would be to mark the servers concerned as unavailable in the API before you begin the maintenance work, apply the configuration and update, and then mark the server as available again. This method is not ideal, but it works. For more information, please read our guide on deploying a blue-green architecture with an OVHcloud Load Balancer.

The purpose of a probe is to test an infrastructure’s health. It periodically examines each of your servers, to ensure that they are working properly. If it detects an error, the server is automatically disabled until the situation is resolved.

Since this service is still very new, its basic features are only available in the API.

Requirements

• a correctly configured OVHcloud Load Balancer, with clusters and servers set

Instructions

An introduction to the API

The API for probes in the OVHcloud Load Balancer is designed to be flexible and scalable.

The probes can be configured directly on the clusters (farms). All of the servers from a single cluster will have the same probe applied. However, probe activation and deactivation are specific for each server. As a result, it is possible to only monitor certain servers within a single cluster.

You can view the list of available probes and their settings with the following API call:

GET /ipLoadbalancing/{serviceName}/availableFarmProbes

For more information on this call, please read the Available probes section at the bottom of this guide.

The probes in this list can be configured on http and tcp clusters (farms) via the following calls:

• POST /ipLoadbalancing/{serviceName}/http/farm
• PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId}
• POST /ipLoadbalancing/{serviceName}/tcp/farm
• PUT /ipLoadbalancing/{serviceName}/tcp/farm/{farmId}

For more information on these calls, please read the Probe configuration section at the bottom of this guide.

Examples

Check if the server accepts TCP connections

This is the simplest method to set up. It is compatible with tcp and http cluster. If no other probes are configured, you can activate it to start. It works by periodically attempting to establish a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again.

In practice, this gives a probe:

All other probe fields can keep their default values. Just apply the configuration to the zone concerned, and the probe will begin to work.

Test a specific HTTP page

By default, the HTTP probe sends an "OPTIONS" request on "/" in HTTP/1.0, without a domain name. In many cases, this is sufficient, but some servers do not manage this method. You can carry out much more powerful tests with the HTTP probe. For example, a good practice when exposing an HTTP service is to add a router dedicated to probes. It is normal to see "/status", "/health", and "/check", which summarize the service’s status.

In practice, if you want to configure the probe to send a "GET" request on http://api.example.com/status, it gives:

All other probe fields can keep their default values. Finally, apply the configuration to the zone concerned.

Use an external HTTP test

What happens if, for example, your service is an IMAP server that relies on an LDAP server for authentication? The server may accept connections, but experience a temporary connection issue with the LDAP server. If this happens, the customers redirected to this server would be able to connect, but wouldn’t be able to authenticate. As a result, the server would need to be removed from the cluster.

If you are using a tcp probe, it will manage to connect. As a result, it will consider the service to be available, even though this is not the case.

In this situation, the health test would ideally be able to confirm that the basic service works. You can provide a specific port to use in the tests. This way, you can set up arbitrary tests for a service, and expose them to HTTP on a dedicated port.

For example, in this situation, you can have an HTTP server on port 8080. It will test the IMAP server via the URL "/service/imap/status", and will return ‘OK’ when everything is working properly. In practice, this will return:

Just apply the configuration to the zone concerned, and the probe will begin to work.

Reference

Probe configuration

Configure a probe

Probes can be configured on a new cluster (POST) or an existing one (PUT). Since the two methods are equivalent, only the second (PUT) method is presented here.

Service: PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId}

Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here.

If a port other than the cluster's base port is configured on the probe, the proxyprotocol and ssl settings are reset. As an example, we will take a configured cluster to use proxyprotocol on port 4242, and an associated probe using port 8080. The probe will not send the proxyprotocol header when it connects on port 8080. The same goes for ssl, but it can be forced.

Activate probes on a server

For a probe to be active, it must be configured on the cluster and activated on the servers concerned. With this call, you can activate the probe being taken into account:

Service: PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server/{serverId}

Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here.

Available comparison types

Four comparison types are available to confirm a probe’s results:

‘Contains’ and ‘matches’ comparison types find a correspondence in the first 16 KB of the response. If the response is longer than 16 KB, whatever comes afterward will be ignored during the test. Please note that to optimize your performance, we recommend returning as little information as possible in your probes.

Available probes

You can get a list of the available probes using the following API call:

Service: GET /ipLoadbalancing/{serviceName}/availableFarmProbes

TCP

This probe attempts to establish a TCP connection to the server. If the server sends a “banner”, you can check if it matches a schema. The default test simply ensures that the connection can be established.

HTTP

This probe attempts to establish an HTTP connection to the server. If the server responds, you can check its HTTP status code, and that the response body matches a schema. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without a Host field.

If the URL is specified, the domain name and protocol are operational. If a domain name is specified, the “Host” field of the request will be filled in, and the request will be sent to HTTP/1.1. If the protocol is specified, it must be consistent with the cluster's SSL configuration.

SMTP

This probe attempts to establish an SMTP connection with the server and sends the command "HELLO localhost". If the server responds, the probe checks that the response code starts with a ‘2’ (success). This probe does not have any specific configuration options.

MySQL

This probe attempts to establish a MySQL connection with the server and analyzes the server’s response. This probe does not have any specific configuration options.

PostgreSQL

This probe attempts to establish a PostgreSQL connection with the server and analyzes the server’s response. This probe does not have any specific configuration options.

oco

This probe attempts to establish a TCP connection on port 79 of your server and checks that the response starts with a ‘2’ (success). This probe does not have any specific configuration options.

Via the OVHcloud Control Panel

From the OVHcloud Control Panel:

1. Select Bare Metal Cloud from the top navigation bar.
2. Expand the Network section in the left-hand menu.
3. Click Load Balancer and select your service.
4. Choose the Server clusters tab.
5. Click the more options ... button to the right of your cluster and select Edit.

On the Home screen, you will see the following:

You can configure probes when you add (or modify) a server cluster, in Advanced settings.

If you can do so with the probe type you have selected, the Probe settings button will allow for more advanced configuration.

A new configuration window will appear, with the probe’s settings.

Go further

For more information and tutorials, please see our other OVHcloud Load Balancer guides or explore the guides for other OVHcloud products and services.