Lors de la configuration du proxy HA, comment décidez-vous des valeurs à affecter aux délais d'expiration? J'ai lu une demi-douzaine d'échantillons dans divers blogs, et tout le monde utilise des délais d'attente différents et personne ne discute pourquoi.

HAProxy semble particulièrement préoccupé par le client, la connexion et le serveur, problème pour lequel HAPRoxy envoie un avertissement si vous laissez complètement non défini:

While not properly invalid, you will certainly encounter various problems
with such a configuration. To fix this, please ensure that all following
timeouts are set to a non-zero value: 'client', 'connect', 'server'.

La documentation est inutile à cet égard: elle suggère "un peu au-dessus de multiples de 3 secondes" mais ne permet pas de choisir un multiple de 1 contre 100 ou 42.

Le RPM que j'utilise (référentiel Amazon Linux) définit les valeurs par défaut suivantes:

timeout connect         10s
timeout client          1m
timeout server          1m

Deux de celles-ci sont des multiples exacts de 3 secondes, en violation du seul conseil officiel que j'ai vu.

Si vous n'avez pas de conseil de réglage spécifique, une question plus simple est peut-être celle-ci: à quoi dois-je m'attendre en cas d'erreur avec des délais très courts ou très longs?

Le délai RTO TCP (délai de réception) commence à trois secondes. ( RFC 1122 ) Si un accusé de réception n'a pas été renvoyé dans ce paquet transmis, il est supposé perdu et retransmis. C'est presque certainement ce à quoi l'auteur fait référence. (Notez que le RTO est optimisé ou optimisé de manière dynamique par différents algorithmes , en dehors du champ de cette question.)

Gardez à l'esprit que cela ne s'applique réellement qu'aux connexions entre votre serveur frontal et les clients (c'est-à-dire les utilisateurs Web). Dans des scénarios normaux, les connexions entre HAProxy et vos serveurs principaux doivent être établies sur un réseau local (LAN) et vous devez utiliser des délais beaucoup plus courts, afin que les moteurs défectueux soient rapidement retirés du service.

En ce qui concerne vos utilisateurs Web, certains d'entre eux peuvent être sur des connexions à latence très élevée, telles que les satellites, et subir une retransmission supérieure à la normale pour cette raison. Le RTT sur une connexion où un satellite est utilisé peut dépasser 2 000 ms, même si tout va bien.

Cela dit, vous souhaiterez généralement des délais très courts timeout connectet très longs timeout client.

Pour timeout server, cela dépend de votre application web. Lors de la définition du délai d'expiration, tenez compte de la complexité de l'application Web servie et du temps requis pour traiter une demande complexe dans le pire des cas. En cas de doute, augmentez la valeur.

Avant-propos

Cela fait un moment que je peaufine HAProxy et que j'ai effectué de nombreux tests de performance. De 100 requêtes HTTP / s à 50 000 requêtes HTTP / s.

Le premier conseil est d’ activer la page de statistiques sur HAProxy . Vous avez besoin de surveillance, sans exception. Vous aurez également besoin d'une mise au point si vous souhaitez dépasser 10 000 requêtes / s.

Les délais d'attente sont une bête déroutante car ils ont un très grand nombre de valeurs possibles, la plupart d'entre elles n'ayant aucune différence observable. Je n'ai pas encore vu quelque chose échouer à cause d'un nombre inférieur de 5% ou supérieur de 5%. 10000 vs 11000 millisecondes, qui s'en soucie? Probablement pas votre système.

Configuration

Je ne peux pas, en toute conscience, donner quelques chiffres comme étant les «meilleurs délais d'expiration de tous les temps».

Ce que je peux dire à la place, ce sont les délais les plus agressifs, qui sont toujours acceptables pour l’équilibrage de charge HTTP (S). Si vous rencontrez des valeurs inférieures, il est temps de reconfigurer votre équilibreur de charge.

timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000

client timeout:

Le délai d'inactivité s'applique lorsque le client doit accuser réception ou envoyer des données. En mode HTTP, il est particulièrement important de prendre en compte ce délai d'attente au cours de la première phase, lorsque le client envoie la demande, et pendant la réponse lors de la lecture des données envoyées par le serveur.

Lecture : c'est le délai maximum pour recevoir les en- têtes de requête HTTP du client.

3G / 4G / 56k / satellite peut être lent parfois. Néanmoins, ils devraient pouvoir envoyer des en-têtes HTTP en quelques secondes, PAS 30.

Si quelqu'un a une connexion si mauvaise qu'il lui faut plus de 30 secondes pour demander une page (plus de 10 * 30 secondes pour demander les 10 images intégrées / CSS / JS), je pense qu'il est acceptable de le rejeter.

serveur timeout:

Le délai d'inactivité s'applique lorsque le serveur doit accuser réception ou envoyer des données. En mode HTTP, il est particulièrement important de prendre en compte ce délai d'attente lors de la première phase de réponse du serveur, lorsqu'il doit envoyer les en-têtes, car il représente directement le temps de traitement du serveur pour la demande. Pour savoir quelle valeur y mettre, il est souvent bon de commencer par ce qui serait considéré comme des temps de réponse inacceptables, puis consultez les journaux pour observer la distribution des temps de réponse et ajustez la valeur en conséquence.

Lecture : il s'agit du délai maximal de réception des en- têtes de réponse HTTP du serveur (après réception de la demande complète du client). En gros, il s’agit du temps de traitement de vos serveurs, avant qu’il ne commence à envoyer la réponse.

Si votre serveur est si lent qu'il faut plus de 30 secondes pour commencer à donner une réponse, je pense qu'il est acceptable de le considérer comme mort.

Cas particulier : Certains services RARE effectuant un traitement très lourd peuvent prendre une minute ou plus avant de donner une réponse. Il peut être nécessaire d’augmenter considérablement ce délai pour cet usage spécifique. (Remarque: il s'agit probablement d'un problème de conception, utilisez une communication de style asynchrone ou n'utilisez pas du tout le protocole HTTP.)

timeout connect:

Définissez le délai maximal d'attente d'une tentative de connexion à un serveur.

Lecture : durée maximale pendant laquelle un serveur doit accepter une connexion TCP.

Les serveurs sont dans le même réseau local que HAProxy, il devrait donc être rapide. Donnez-lui au moins 5 secondes, car le temps requis peut être long en cas d'imprévu (perte d'un paquet TCP à retransmettre, serveur demandant à un nouveau processus de prendre les nouvelles demandes, augmentation du trafic).

Cas spécial : lorsque les serveurs se trouvent sur un autre réseau local ou sur un lien peu fiable. Ce délai peut devoir être considérablement augmenté. (Remarque: il s'agit probablement d'une mauvaise architecture.)

vérification du délai d'attente:

Définissez un délai de vérification supplémentaire, mais uniquement après l’établissement d’une connexion.

Définissez un délai de vérification supplémentaire, mais seulement après qu'une connexion a déjà été définie. Si défini, haproxy utilise min ("timeout connect", "inter") comme délai de connexion pour le contrôle et "vérification du délai" en tant que délai de lecture supplémentaire. Le "min" est utilisé pour que les personnes qui exécutent une "connexion avec timeout" très longue (par exemple, ceux qui en avaient besoin en raison de la file d'attente ou du tarpit) ne ralentissent pas leurs vérifications. (Veuillez également noter qu'il n'y a aucune raison valable d'avoir des délais d'attente de connexion aussi longs, car la "file d'attente de délai d'attente" et le "tarpit de délai d'attente" peuvent toujours être utilisés pour éviter cela).

Lire : lors d'une vérification de santé, le serveur doit timeout connectaccepter la connexion, puis timeout checkdonner la réponse.

Tous les serveurs DOIVENT avoir un contrôle d'intégrité HTTP (S) configuré. C'est la seule façon pour l'équilibreur de charge de savoir si un serveur est disponible. Le bilan de santé est une simple /isalivepage qui répond toujours OK.

Donnez à ce délai au moins 5 secondes, car le temps requis peut être long en cas d'imprévu (perte d'un paquet TCP à retransmettre, serveur forçant un nouveau processus de traitement des nouvelles demandes, augmentation du trafic).

Histoire de guerre : Beaucoup de gens croient à tort que le serveur peut toujours répondre à cette simple page en 3 ms. Ils ont défini un délai d'expiration agressif (<2000 ms) avec un basculement intensif (2 échecs de vérification = serveur mort). J'ai vu des sites Web entiers en panne à cause de cela. En règle générale, il y a une légère augmentation du trafic, les serveurs back-end ralentissent, les contrôles de santé sont retardés ... jusqu'à ce qu'ils cessent tous ensemble, HAProxy pense que TOUS les serveurs sont morts en même temps et que le site entier tombe en panne.