HAProxy ferme de longue vie connexions TCP en ignorant TCP keepalive

J'ai configuré HAProxy (1.5.4, mais j'ai essayé aussi 1.5.14) à l'équilibre en mode TCP deux serveur d'exposer protocole AMQP (WSO2 Message Broker) sur 5672 port.
Les clients de créer et d'utiliser une connexion permanente pour la AMQP Serveurs, par HAProxy.

J'ai changé le client et le serveur TCP keepalive délai d'attente, réglage du net.ipv4.tcp_keepalive_time=120 (CentOS 7).

Dans HAProxy j'ai placé délai d'attente de client/serveur à 200 secondes (>120 secondes de la persistantes paquets) et utilisé l'option clitcpka.

Puis j'ai commencé à wireshark et renifla tout le trafic tcp: après la dernière demande de la part des clients, le tcp keepalived paquets sont sente régulièrement après 120 secondes, mais après 200 secondes après la dernière demande de la part des clients de la connexion sont fermés (en ignorant l'keepalived paquet).

Ci-dessous la configuration:

haproxy.conf

global
    log 127.0.0.1   local3
    maxconn 4096
    user haproxy
    group haproxy
    daemon
    debug

listen messagebroker_balancer 172.19.19.91:5672
    mode tcp
    log global
    retries 3
    timeout connect 5000ms
    option redispatch
    timeout client 200000ms
    timeout server 200000ms
    option tcplog
    option clitcpka 
    balance leastconn
    server s1 172.19.19.79:5672 check inter 5s rise 2 fall 3
    server s2 172.19.19.80:5672 check inter 5s rise 2 fall 3

OriginalL'auteur Paolo Parlato | 2015-09-17

  1. 8

    TCP keep alive est à la couche de transport et est utilisé uniquement pour faire un peu de trafic sur la connexion afin intermédiaire comme les systèmes de filtres de paquets de ne pas perdre tous les états et que les systèmes d'extrémité peut remarquer si la connexion de l'autre côté cassé (peut-être parce que quelque chose s'est écrasé ou d'un câble réseau cassé).

    TCP keep alive n'a rien à voir avec le niveau d'application du délai d'inactivité que vous avez mis explicitement à 200s:

    timeout client 200000ms
timeout server 200000ms

    Ce délais d'attente est déclenchée si la connexion est inactive, c'est si pas de données transféré. TCP keep alive ne pas transporter tout type de données, la charge utile de ces paquets est vide.

    Je ne suis pas un expert de HAProxy, mais il semble qu'elle fonctionne au niveau TCP, comme décrit dans la serverfault.com/questions/589804/...
    le niveau TCP est grand 🙂 HA proxy fonctionne au niveau de l'espace utilisateur où vous pouvez contrôler la garder vivante minuteries, mais vous ne pouvez pas envoyer ou receiveTCP garder en vie les paquets directement. Vous ne pouvez lire et écrire des données réelles qui ont une taille de plus de 0 octets et de garder en vie les paquets sont vides. Et encore une fois, le délai d'inactivité en HA proxy ne se préoccupe que de transfert de données alors que le protocole TCP keep alive n'a pas de transfert de données.

    OriginalL'auteur Steffen Ullrich

  2. 1

    Vous devez définir timeout client de très grande taille ou de durée indéfinie. Ce délai sert à détecter une impasse application client sur un réactif de système d'exploitation client. Vous pouvez toujours avoir une application qui occupe une connexion, mais ne parle pas pour vous. C'est mauvais parce que le nombre de connexions n'est pas infinie (maxconn).

    De même timeout server pour le backend.

    Avec option clitcpka ou option srvtcpka ou option tcpka la connexion inactive est détecté et tué par l'OS, pas par haproxy.

     sysctl net.ipv4.tcp_keepalive_time=110  # if no data sent for 110 seconds, enable KA, then immediately send the first KA, don't kill connection yet
 sysctl net.ipv4.tcp_keepalive_intvl=30  # wait for 30 seconds after each KA, once they're enabled
 sysctl net.ipv4.tcp_keepalive_probes=3  # send 3 KAs unacknowledged, then kill the TCP connection

    Lorsque des paquets arrêter de venir ces paramètres du système d'exploitation collectivement tuer la connexion après 200 secondes.

    OriginalL'auteur kubanczyk