Keep Alive

De DocUnix.

Problématique :

Sur des réseaux, lorsqu'aucun trafic ne passe sur une connexion tcp pendant 1 heure et qu'elle traverse un firewall, le firewall coupe brutalement la connexion. Cela peut créer des connexions orphelines côté serveur (connexions sans client à l'autre bout sur lequel plus aucune demande n'arrivera; par exemple plantage de la machine cliente) ou des connexions non rattachées à un serveur côté client (on aura une erreur lorsque l'on voudra envoyer des données dessus).

Solutions :

  • Une 1ère solution est d'activer le keepalive tcp sur la connexion et de baisser le keepalive à moins d'une heure (par défaut c'est configuré à 2h) il peut être activé côté client et/ou côté serveur si ce n'est activé que du côté client, un plantage de la machine cliente laissera des connexions orphelines mais il faut que cela ait été prévu par les développeurs.
    • Pour AIX le paramètre "no" a régler est tcp_keepidle exprimé en seconde.
  • Une seconde solution est qu'il y ait un trafic applicatif régulier, même s'il ne contient aucune donnée utile c'est ce que Oracle a mis en oeuvre avec le "Dead Connection Detection" qui provoque l'envoi de paquets de test par le serveur Oracle. Les connexions ne répondant pas à la demande du serveur passent alors dans un état "SNIPED" et doivent être nettoyées.
    • Pour Oracle, c'est paramétré dans .../oracle/adm/network/sqlnet.ora : SQLNET.EXPIRE_TIME = 15 et en crontab oracle un script exécute régulièrement un kill des connexions "SNIPED" (.../oracle/adm/scripts/ChkErr_Instance.ksh qui exécute Kill_Sniped_Connexion.sql).
  • Une 3ème solution est l'expiration de session qui fait qu'une session non utilisée depuis un certain temps tombe en timeout et est alors fermée. Cela est également mis en oeuvre dans oracle, notamment pour les connexions acetp_readonly (c'est également utilisé sur le serveur LDAP couplé à un keepalive côté client car cela vire les connexions orphelines mais cela n'empêche pas le firewall de couper en absence de trafic pendant 1 heure).


Côté client :

Il faut que le mécanisme gérant les connexions ou le pool de connexions permette la reprise sur une fermeture inopinée d'une connexion inactive. C'est le cas avec Weblogic, avec notamment le test "SELECT 1 FROM DUAL" effectué avant l'utilisation d'une connexion.

Outils personnels