Server Load Balancer:GWLB health checks

États des contrôles d'intégrité

Les serveurs backend peuvent se trouver dans les états suivants :

Fonctionnement

Contrôle d'intégrité TCP

GWLB utilise des sondes TCP personnalisées pour vérifier efficacement l'état des serveurs backend.

Voici le processus de contrôle d'intégrité TCP :

1. Selon la configuration de l'écouteur, GWLB envoie un paquet TCP SYN à l'adresse IP privée et au port de contrôle d'intégrité du serveur backend.

2. Si le port du serveur backend est en écoute, le serveur répond par un paquet SYN+ACK.

3. Si GWLB ne reçoit pas de paquet SYN+ACK du serveur backend dans le délai d'attente spécifié, le contrôle d'intégrité échoue.

4. Si GWLB reçoit un paquet SYN+ACK du serveur backend dans le délai imparti, le contrôle d'intégrité réussit. GWLB envoie ensuite un paquet RST pour fermer la connexion TCP.

Contrôle d'intégrité HTTP

Les contrôles d'intégrité HTTP envoient des requêtes GET pour récupérer les informations d'état des serveurs backend.

Voici le processus de contrôle d'intégrité HTTP :

1. Selon la configuration de l'écouteur, GWLB envoie une requête HTTP GET à l'adresse IP privée, au port de contrôle d'intégrité et au chemin de vérification du serveur backend. La requête inclut le nom de domaine configuré.

2. Le serveur backend renvoie un code d'état HTTP selon son état opérationnel.

3. Si GWLB ne reçoit pas de réponse du serveur backend dans le délai d'attente spécifié, le contrôle d'intégrité échoue.

4. Si GWLB reçoit une réponse dans le délai imparti, il compare le code d'état renvoyé au code attendu. S'ils correspondent, le contrôle d'intégrité réussit. Sinon, il échoue.

Fenêtre temporelle des contrôles d'intégrité

Pour éviter des basculements fréquents dus à des pannes transitoires, GWLB modifie l'état d'intégrité d'un serveur uniquement après un nombre consécutif spécifié de succès ou d'échecs. Trois facteurs déterminent la fenêtre temporelle des contrôles d'intégrité :

• intervalle de contrôle d'intégrité : durée entre deux contrôles.

• délai d'attente de réponse : temps maximal d'attente d'une réponse.

• seuil de contrôle d'intégrité : nombre de contrôles consécutifs requis pour modifier l'état d'intégrité d'un serveur.

Utilisez les formules suivantes pour calculer la fenêtre temporelle des contrôles d'intégrité :

• Fenêtre d'échec = délai d'attente de réponse × seuil unhealthy + intervalle de contrôle d'intégrité × (seuil unhealthy - 1)

• Fenêtre de succès = (temps de réponse d'un contrôle réussi × seuil healthy) + intervalle de contrôle d'intégrité × (seuil healthy - 1)

  Remarque

  Le temps de réponse d'un contrôle d'intégrité réussi correspond à la durée écoulée entre l'envoi de la requête et la réception de la réponse. Pour un contrôle TCP, ce temps est négligeable car la sonde vérifie uniquement si le port est actif. Pour un contrôle HTTP, ce temps dépend des performances et de la charge du serveur applicatif, mais reste généralement de l'ordre de quelques secondes.

  

L'état du contrôle d'intégrité affecte le transfert des requêtes comme suit :

• Si un serveur backend échoue au contrôle d'intégrité, GWLB ne lui distribue plus les nouvelles requêtes. L'accès client n'est pas affecté.

• Si un serveur backend réussit le contrôle d'intégrité, GWLB lui distribue les nouvelles requêtes. L'accès client se déroule normalement.

• Si un serveur backend rencontre un problème mais n'a pas encore atteint le seuil unhealthy, GWLB continue de lui envoyer des requêtes. Cela peut entraîner l'échec de ces requêtes. Par défaut, le seuil unhealthy est fixé à trois échecs consécutifs.

Exemple : Délai d'attente de réponse et intervalle de contrôle d'intégrité

Prenons les paramètres de contrôle d'intégrité suivants :

• response timeout: 5 seconds

• health check interval: 2 seconds

• healthy threshold: 3

• unhealthy threshold: 3

Fenêtre d'échec = délai d'attente de réponse × seuil unhealthy + intervalle de contrôle d'intégrité × (seuil unhealthy - 1). Dans cet exemple, la fenêtre temporelle est de 19 secondes : 5 × 3 + 2 × (3 - 1) = 19 secondes. Après 19 secondes d'échecs consécutifs, l'état du serveur passe à unhealthy.

La figure suivante illustre le passage d'un serveur de l'état healthy à l'état unhealthy.

Fenêtre de succès = (temps de réponse d'un contrôle réussi × seuil healthy) + intervalle de contrôle d'intégrité × (seuil healthy - 1). En supposant un temps de réponse du serveur de 1 seconde, la fenêtre temporelle est de 7 secondes : (1 × 3) + 2 × (3 - 1) = 7 secondes. Après 7 secondes de succès consécutifs, l'état du serveur passe à healthy.

La figure suivante illustre le passage d'un serveur de l'état unhealthy à l'état healthy, en supposant un temps de réponse du serveur de 1 seconde.

Nom de domaine pour les contrôles d'intégrité HTTP

La spécification d'un nom de domaine pour les contrôles d'intégrité HTTP est facultative. Cependant, certains serveurs backend valident l'en-tête host des requêtes entrantes. Si vous spécifiez un nom de domaine, GWLB l'inclut dans l'en-tête host de la sonde de contrôle. Si vous ne spécifiez pas de nom de domaine et sélectionnez Use private IP of the backend server, GWLB utilise l'adresse IP privée et le port du serveur comme valeur host. Le serveur backend peut rejeter cette requête s'il ne reconnaît pas la valeur, ce qui entraîne l'échec du contrôle d'intégrité.

Par conséquent, si votre serveur backend valide l'en-tête host, vous devez configurer un nom de domaine pour garantir le bon fonctionnement des contrôles d'intégrité.

Références

Configurer et gérer les contrôles d'intégrité