Environ 1 a 3 fois par jours la connexion d'un de mes odroid-xu4 saute. Système Ubuntu-Minimal 18.04 (ARM).
Le soucis est détecté par HaProxy ("Layer4 timeout" ou "Layer7 timeout") et ne semble pas durer plus de 1-3 secondes. Par contre rien de spécial ne semble indiqué dans les fichiers logs.
L'odroid est joignable via connexion LAN et via tunneling. Hors le logiciel qui gère le tunneling n'indique rien dans ses logs aux heures ou HaProxy détecte les coupures.
Ca ne semble pas être :
- un reboot
- un soucis de câble
- un problème d'alim
Auriez-vous svp une piste afin de rechercher l'origine du problème ?
Voici un exemple de logs d'HaProxy lors des coupures (le status down indique deux échecs du healthcheck à moins d'une seconde d'intervalle):
May 13 03:17:57 HaProxyServerName haproxy[742]: Backup Server my_wiki/odroid1.tunneling is DOWN, reason: Layer4 timeout, check duration: 5000ms. 1 active and 1 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
May 13 03:17:57 HaProxyServerName haproxy[742]: Backup Server my_wiki/odroid1.tunneling is DOWN, reason: Layer4 timeout, check duration: 5000ms. 1 active and 1 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
May 13 03:18:02 HaProxyServerName haproxy[742]: Backup Server my_wiki/odroid1.tunneling is UP, reason: Layer7 check passed, code: 204, info: "HTTP status check returned code 204", check duration: 11ms. 1 active and 2 backup servers online. 0 sessions requeued, 0 total in queue.
May 13 03:18:02 HaProxyServerName haproxy[742]: Backup Server my_wiki/odroid1.tunneling is UP, reason: Layer7 check passed, code: 204, info: "HTTP status check returned code 204", check duration: 11ms. 1 active and 2 backup servers online. 0 sessions requeued, 0 total in queue.
May 13 13:27:59 HaProxyServerName haproxy[742]: Backup Server my_wiki/odroid1.tunneling is DOWN, reason: Layer7 timeout, check duration: 5000ms. 1 active and 1 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
May 13 13:27:59 HaProxyServerName haproxy[742]: Backup Server my_wiki/odroid1.tunneling is DOWN, reason: Layer7 timeout, check duration: 5000ms. 1 active and 1 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
May 13 13:27:59 HaProxyServerName haproxy[742]: Server my_wiki/odroid1.LAN is DOWN, reason: Layer7 timeout, check duration: 5001ms. 0 active and 1 backup servers left. Running on backup. 1 sessions active, 0 requeued, 0 remaining in queue.
May 13 13:27:59 HaProxyServerName haproxy[742]: Server my_wiki/odroid1.LAN is DOWN, reason: Layer7 timeout, check duration: 5001ms. 0 active and 1 backup servers left. Running on backup. 1 sessions active, 0 requeued, 0 remaining in queue.
May 13 13:28:05 HaProxyServerName haproxy[742]: Backup Server my_wiki/odroid1.tunneling is UP, reason: Layer7 check passed, code: 204, info: "HTTP status check returned code 204", check duration: 18ms. 0 active and 2 backup servers online. Running on backup. 0 sessions requeued, 0 total in queue.
May 13 13:28:05 HaProxyServerName haproxy[742]: Backup Server my_wiki/odroid1.tunneling is UP, reason: Layer7 check passed, code: 204, info: "HTTP status check returned code 204", check duration: 18ms. 0 active and 2 backup servers online. Running on backup. 0 sessions requeued, 0 total in queue.
May 13 13:28:05 HaProxyServerName haproxy[742]: Server my_wiki/odroid1.LAN is UP, reason: Layer7 check passed, code: 204, info: "HTTP status check returned code 204", check duration: 37ms. 1 active and 2 backup servers online. 0 sessions requeued, 0 total in queue.
May 13 13:28:05 HaProxyServerName haproxy[742]: Server my_wiki/odroid1.LAN is UP, reason: Layer7 check passed, code: 204, info: "HTTP status check returned code 204", check duration: 37ms. 1 active and 2 backup servers online. 0 sessions requeued, 0 total in queue.
# des pistes ?
Posté par NeoX . Évalué à 3.
chez moi 5000ms = 5s
ce qui est tres differents de
ca veut donc dire que ton odroid ne repond pas (freeze ?) pendant un temps donné, superieur aux attentes de haproxy, haproxy considere alors le serveur comme down (en tout cas le service qu'il monitore), la machine peut toutefois continuer à fonctionner parfaitement
ex : tu met ton haproxy devant un apache,
tu coupes apache, le haproxy signale un down, pour autant la machine repond, parle meme à ton client ssh, ton ftp, etc, juste le service apache est down
[^] # Re: des pistes ?
Posté par voxdemonix . Évalué à 1. Dernière modification le 14 mai 2019 à 01:57.
"check duration" représente le temps qu'a mis le check. Ici 5s semble être la limite max par défaut ("timeout connect 5000").
D'après ma config HaProxy, lors d'un changement d'état il faut un second tests échoués consécutifs (à intervalles de 0,5s) pour qu'un serveur soit considéré comme DOWN.
Quand apache2 est coupé HaProxy renvoie "Connection refused".
Pour arriver à avoir un "Layer7 timeout" pour odroid1.lan (mais avec un Layer 4 timeout pour odroid1.tunneling, pas comme dans les logs) je dois tuer le logiciel de tunneling vers la BDD. Peut-être que des instabilités provoqueraient des micro-coupures (verbosité augmenté, a voir si les logs seront plus parlant 😋)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.