FR 2905545 A1 20080307 FR 0653546 A 20060831 1 Gestion d'au moins une connexion établie avec au moins un serveur client. La présente invention se rapporte au domaine des communications et notamment à la possibilité de rendre hautement disponible une application entre au moins un serveur client et un serveur primaire. Plus particulièrement, l'invention permet d'améliorer la gestion des connexions entre au moins un serveur client et un serveur primaire. Pour rendre hautement disponible une application entre au moins un serveur client et un serveur primaire, il est nécessaire de maintenir, du côté de ce serveur primaire, l'intégrité de la ou des connexions entre ledit serveur primaire et au moins un serveur client. Pour maintenir cette intégrité, il convient de gérer au mieux la situation où le serveur primaire devient défaillant. ST-TCP (Serveur fault-tolerant TCP) propose ainsi qu'une partie des paquets de données échangées, entre au moins un serveur client et le serveur primaire, soit copiée et sauvegardée sur ce serveur primaire. Ces copies sont supprimées lorsqu'il est sûr qu'au moins un serveur de secours les a bien reçus. Les états de connexion TCP entre le serveur primaire et au moins un serveur de secours sont ainsi au mieux identiques. Ceci permet une reprise transparente de la connexion par au moins un serveur de secours lorsque le serveur primaire devient défaillant. Cependant, la sauvegarde des copies des paquets de données sur le serveur primaire est ici dépendante 2905545 2 de la capacité du serveur de secours à bien recevoir les paquets venant d'au moins un serveur client. En cas de lenteur de lecture d'une grande quantité de paquets de données par le serveur de secours, les 5 copies des paquets vont s'accumuler sur le serveur primaire, et à terme, perturber les échanges entre au moins un serveur client et ce serveur primaire. Ainsi, la présente invention permet de palier ou 10 pour le moins de réduire tout ou partie des inconvénients précités. Un premier objet de la présente invention concerne un dispositif de gestion d'au moins une connexion 15 établie avec au moins un serveur client, ledit dispositif comprenant: - au moins une partie d'un dispositif de gestion des échanges de paquets de données, - au moins une partie d'un dispositif de gestion 20 de la défaillance d'un serveur. Ainsi, le serveur primaire est déchargé d'une partie de la gestion des connexions établies. Ceci limite les risques de perturbation des échanges de données lorsque le serveur primaire est en connexion 25 avec au moins un serveur client. Selon des modes de réalisation préférentiels non limitatifs, le procédé objet de l'invention présente les caractéristiques supplémentaires prises isolément 30 ou en combinaison, énoncées ci-après: Le dispositif de gestion comprend au moins une partie d'un dispositif de gestion du basculement de la connexion. 2905545 3 Ainsi, la gestion du basculement est déportée en partie sur le dispositif de routage, ce qui décharge le serveur de secours de cette tâche. 5 Le basculement de la connexion se fait vers plusieurs serveurs de secours. Ainsi, si le serveur de secours a plusieurs connexions avec différents serveurs clients, ces connexions pourront être réparties sur différents 10 serveurs de secours. Un deuxième objet de l'invention concerne un procédé de gestion d'au moins une connexion établie avec au moins un serveur client dans lequel au cours 15 du basculement de la connexion vers au moins un serveur de secours, l'échange de paquets de données est arrêté. Ainsi, la perte de paquets de données au cours du basculement de la connexion est limitée. 20 Un troisième objet de l'invention concerne un programme d'ordinateur sur un support de données et chargeable dans la mémoire interne d'un ordinateur, le programme comprenant des portions de code pour 25 l'exécution des étapes du procédé selon le deuxième objet de l'invention, lorsque le programme est exécuté sur ledit ordinateur. Un quatrième objet de l'invention concerne un 30 composant programmable comportant un programme comprenant des portions de code pour l'exécution des étapes du procédé selon le deuxième objet de l'invention lorsque le composant exécute ledit programme. 35 2905545 4 Un cinquième objet de l'invention concerne un dispositif de routage comportant un dispositif de gestion d'au moins une connexion établie avec au moins un serveur client selon le premier objet de 5 l'invention. Ainsi, le dispositif de routage a en charge la gestion d'au moins une connexion établie avec un serveur client, ce qui décharge le serveur primaire et le serveur de secours de tout ou partie de cette 10 tâche. Selon des modes de réalisation préférentiels non limitatifs, le dispositif de routage associe à chaque paquet de données, en destination du serveur 15 primaire, une adresse de diffusion. Ainsi, les serveurs de secours reçoivent passivement tous les paquets de données à destination du serveur primaire. 20 Le dispositif de routage associe à chaque paquet de données, en destination du serveur client, une adresse de diffusion. Ainsi, les serveurs de secours reçoivent passivement tous les paquets de données à destination 25 du serveur client. Un sixième objet de l'invention concerne un serveur primaire en connexion avec un serveur client, ladite connexion étant gérée par le dispositif selon 30 le premier objet de l'invention, le serveur primaire répartissant la charge de traitement des données vers au moins un serveur secondaire. Ainsi, le traitement des données est facilité. 2905545 5 L'invention sera mieux comprise et d'autres particularités et avantages apparaîtront à la lecture de la description, faîte à titre d'exemple, cette description faisant références aux dessins annexés 5 représentant: - A la Fig.l, une topologie d'un réseau conforme à l'invention; - A la Fig.2, une architecture informatique conforme à l'invention; 10 - A la Fig.3, un procédé de gestion des connexions conforme à l'invention. La Fig. 1 présente une topologie d'un réseau conforme à l'invention. 15 Au moins un serveur client 11a, 11b échange des paquets de données avec un serveur primaire 16. Des moyens de routage déterminent, pour cela, le meilleur chemin pour acheminer ces paquets entre le ou les serveurs clients et le serveur primaire. Par serveur 20 client, il faut comprendre tout équipement communiquant, comme par exemple un ordinateur ou un téléphone portable, utilisé par un client pour accéder à une application. Le dispositif de routage peut être constitué 25 d'une seule entité. En variante, il peut comprendre plusieurs entités. A la Fig. 1, les moyens de routage comprennent ainsi un dispositif de routage dynamique 12, dont la table de routage est modifiée automatiquement en lien avec les changements qui 30 surviennent dans les réseaux. Ceci permet aux paquets de données d'emprunter la meilleure voie disponible. Le dispositif de routage dynamique permet en outre d'interconnecter deux réseaux qui peuvent être différents. Par exemple, le dispositif 12 peut 35 interconnecter un réseau Internet avec un réseau LAN. 2905545 6 Les moyens de routage comprennent également un dispositif de routage statique 13, dans lequel les tables de routage sont déterminées à l'avance. Un dispositif 14 de gestion, d'au moins une connexion 5 établie avec au moins un serveur client, est disposé sur le dispositif de routage statique 13. Ce dispositif a pour but de gérer la ou les connexions établies entre le serveur client et le serveur primaire. En variante, le dispositif 14 de gestion 10 peut être disposé sur le dispositif de routage dynamique 12. Un dispositif de commutation 15, permet l'acheminement des paquets vers des hôtes, c'est à dire le serveur primaire 16 et au moins un serveur de 15 secours 17a, 17b. Ce dispositif de commutation permet ainsi d'améliorer les performances du réseau tout en isolant les paquets de données. Pour cela, il ne fait suivre les paquets de données qu'au seul port auquel l'hôte de destination est attaché. 20 Le serveur primaire à la réception des paquets traitera les données afin de fournir l'application demandée par le serveur client. En variante, le serveur primaire répartit le traitement des données vers au moins un serveur secondaire. Le serveur 25 primaire peut être ainsi un répartiteur de charge. Pour qu'un échange de données puisse se dérouler entre le serveur client et le serveur primaire, il faut qu'une connexion ait pu être établie entre les 30 deux serveurs. Par connexion on entend un circuit virtuel établit entre deux parties, c'est-à-dire ici le serveur client et le serveur primaire. On notera cependant que le serveur primaire peut avoir différentes connexions avec différents serveurs 35 clients. 2905545 7 Une connexion utilise différents protocoles pour acheminer des paquets de données, et notamment des protocoles de transport tels que TCP "Transmission Control Protocol" ou SCTP "Stream Control 5 Transmission Protocol" par exemple. Ces protocoles sont dits en mode connecté, c'est-à-dire qu'ils opèrent un contrôle de la transmission des données pendant la connexion entre les serveurs clients et primaires. 10 Dans le cas où le protocole TCP est utilisé comme protocole de transport, l'établissement de la connexion s'effectue en trois phases. Dans un premier temps, le serveur client envoie un message comportant le drapeau de début de connexion SYN, avec la 15 séquence initiale propre à ce serveur client. Dans un deuxième temps, le serveur primaire répond par l'envoie d'un message comportant un drapeau de début de connexion SYN avec sa propre séquence initiale, et par un acquittement avec un drapeau d'acquittement 20 ACK comportant la séquence initiale du serveur client incrémenté de 1. Dans un troisième temps, le serveur client acquitte les données du serveur primaire par l'envoie d'un message comprenant un drapeau ACK avec la séquence initiale du serveur primaire incrémenté 25 de 1. Si le serveur primaire devient défaillant, il faut que le serveur de secours puisse reprendre rapidement les connexions existantes, entre le serveur client et le serveur primaire. En effet, la 30 non reprise de la connexion entraîne sa fermeture et le gaspillage des ressources sur le serveur primaire et sur les réseaux. La perte de la connexion rendrait ainsi subitement une application indisponible aux clients. Ceux-ci seraient donc obligés d'attendre la 2905545 8 création d'une nouvelle connexion TCP pour pouvoir utiliser de nouveau cette application. En variante, plusieurs serveurs de secours peuvent reprendre la connexion. 5 Afin de garantir, que le ou les serveurs de secours puissent reprendre la ou les connexions existantes entre le ou les serveurs client 11a, 11b et le serveur primaire 16, il faut que le ou les serveurs de secours 17a, 17b connaissent les 10 informations caractérisant la ou les connexions TCP existantes. Ces informations sont, par exemple, les séquences initiales du serveur client et du serveur primaire. Pour cela, le dispositif de routage statique 13 15 envoie non seulement les paquets de données au serveur primaire 16 mais également aux serveurs de secours 17a, 17b. Le dispositif de routage statique 13 associe ainsi à chaque paquet de données, en destination du serveur primaire, une adresse de 20 diffusion au niveau de la couche liaison. Au niveau du dispositif de commutation 15, chaque paquet de données sera copié et diffusé sur tous ses ports de sortie, ce qui permettra aux serveurs de secours 17a, 17b de l'intercepter. Le ou les serveurs de secours 25 vont alors analyser chaque paquet de données et vont pouvoir synchroniser leurs états de connexion TCP. On réalise ainsi une réplication active, en dupliquant sur le ou les serveurs de secours, les états de connexion TCP établies et maintenues entre un client 30 et un serveur primaire. En cas de panne de ce dernier, au moins un des serveurs de secours prendra le relais du serveur primaire, en préservant l'intégrité des connexions TCP déjà établies avec le client. 2905545 9 En outre, il est nécessaire au serveur de secours de connaître la réponse que le serveur primaire enverra au serveur client. Pour cela, le dispositif de routage statique 13 envoie non 5 seulement les paquets de données au serveur client 11a, 11b mais également aux serveurs de secours 17a, 17b. Le dispositif de routage statique 13 associe ainsi à chaque paquet de données, en destination du serveur client, une adresse de diffusion au niveau de 10 la couche liaison. Au niveau du dispositif de commutation 15, chaque paquet de données sera copié et diffusé sur tous ses ports de sortie, ce qui permettra aux serveurs de secours 17a, 17b de l'intercepter. Le ou les serveurs de secours vont 15 alors analyser chaque paquet de données et vont pouvoir synchroniser leurs états de connexion TCP. L'utilisation d'une adresse de diffusion, par le dispositif de routage statique 13, permet de s'assurer que les paquets de données ne seront pas 20 ignorés par le dispositif de commutation 15, et ceci quelque soit le dispositif de commutation 15 utilisé. Les serveurs de secours 17a, 17b n'interceptent que les paquets utilisant le protocole de transport TCP. En variante, ils interceptent la totalité des 25 échanges entre le ou les serveurs clients et le serveur primaire. Ils interceptent, par exemple, des paquets utilisant d'autres protocoles de transport comme l'UDP ou le DNS ("Domain Name Service"). Le ou les serveurs de secours 17a, 17b peuvent alors 30 incorporer un filtrage au niveau IP qui ne délivrera à la couche de transport que les données associées à une connexion TCP. Ainsi, on évitera de surcharger l'unité centrale des serveurs de secours. On notera qu'afin d'éviter que le paquet intercepté et filtré 35 ne soit détruit au niveau IP, l'adresse IP de 2905545 10 destination du paquet est modifiée au niveau du serveur de secours qui l'a reçue, afin de correspondre à l'adresse IP de ce serveur de secours. On notera enfin, que le ou les serveurs de 5 secours 17a, 17b n'envoient pas, contrairement au serveur primaire, de réponse au serveur client. Celle-ci est plutôt silencieusement détruite au niveau du serveur de secours correspondant. 10 La Fig.2 présente une architecture informatique selon l'invention. Il est représenté ici un seul serveur client et un seul serveur de secours, bien entendu l'invention peut s'appliquer dans le cas où il y a plusieurs serveurs clients et plusieurs 15 serveurs de secours. Un serveur client 21 échanges des paquets de données 50 avec un serveur primaire 26 et un serveur de secours 27. Ces paquets sont acheminés par l'intermédiaire d'un dispositif de routage dynamique 20 22 et d'un dispositif de routage statique 23. Un dispositif de gestion 42 de la défaillance d'un serveur comporte un module 35 de détection de la défaillance du serveur primaire, un module 36 de détection de la défaillance du serveur de secours, un 25 module 32 d'analyse des défaillances d'un serveur. Un dispositif de gestion 43 du basculement de la connexion comporte un module 33 de déclenchement du basculement, un module 37 de basculement de l'identité du serveur de secours. 30 Un dispositif de gestion 44 des échanges de paquets de données comporte un module 34 de sauvegarde d'une copie des paquets de données échangés, un module 38 de traitement des paquets de données échangés. 2905545 11 Le serveur primaire 26 comporte un module 35 de détection de la défaillance du serveur primaire. Le serveur de secours 27 comporte un module 36 de détection de la défaillance du serveur de secours, 5 un module 37 de basculement de l'identité du serveur de secours, un module 38 de traitement des paquets de données échangés. Le dispositif de routage statique 23 comporte un dispositif de gestion 41 d'au moins une connexion 10 établie avec un serveur client. Ce dispositif de gestion 41 comporte au moins une partie d'un dispositif de gestion 44 des échanges de paquets de données, par exemple un module 34 de sauvegarde d'une copie des paquets de données échangés. 15 En variante, le dispositif de gestion 41 comporte également au moins une partie d'un dispositif de gestion 42 de la défaillance d'un serveur, par exemple un module 32 d'analyse des défaillances d'un serveur. 20 En variante, le dispositif de gestion 41 comporte également au moins une partie d'un dispositif de gestion 43 du basculement de la connexion, par exemple un module 33 de déclenchement du basculement. 25 Les modules 32, 33, 34, 35, 36, 37, 38 peuvent être des composants matériels, en variante ces modules peuvent être des composants logiciels. Le module 34 de sauvegarde d'une copie des paquets de données échangés est particulièrement 30 utile lorsque le serveur de secours 27 ne reçoit pas des paquets émis vers ou par le serveur primaire 16. Le serveur 27 ne peut donc mettre à jour ses états de connexion TCP. Le serveur 37 détecte ces pertes de paquets de données au vue de l'acquittement du 35 serveur primaire, qui est émis à destination du 2905545 12 serveur client. Si le serveur de secours échoue à intercepter cet acquittement, l'acquittement ultérieur émis par le client, lui permettra de détecter ces pertes de paquets. Un autre avantage 5 pour le serveur de secours d'examiner l'acquittement du serveur primaire, est qu'il peut synchroniser au plus tôt ses états de connexion TCP avec ce serveur primaire. Une fois la perte de données détectée, le 10 serveur de secours demande une restitution de paquets auprès du module 34 de sauvegarde. Cette demande se fait via le message 51. Le module 34 enverra en réponse les paquets manquants, au module 38 de traitement des paquets de données. 15 La demande et la réponse apportée peuvent être transmises sur un canal dédié, par exemple un canal UDP (non représenté), établi entre le module 34 et le module 38. On notera que si aucune demande n'est reçue par 20 le module 34 pour la restitution d'une copie de paquets sauvegardés, ceux-ci seront détruits au bout d'un certain temps. La sauvegarde d'une copie des paquets échangés est donc ici déportée sur le dispositif de routage 25 statique 23. Ceci permet de décharger, par exemple, le serveur primaire de cette fonction. L'échange des paquets entre le ou les serveurs clients et le serveur primaire est ainsi peu influencé par cette sauvegarde. De plus, tous les paquets de données 30 transitent par le dispositif de routage statique 23, ce qui facilite la sauvegarde de leur copie. En outre, dans le cas d'une défaillance du serveur primaire cumulée à une perte de paquets de données par le serveur de secours, ce dernier pourra toujours 35 les recevoir via le module 34. Enfin, la présence du 2905545 13 module 34 sur un dispositif de routage statique 13, proche du serveur de secours, facilite la restitution des paquets perdus. On notera que le module 34 effectue une copie 5 non intrusive des paquets échangés. Pour cela les paquets sont interceptés et filtrés au niveau IP. Une "Divert Sachet" est ensuite ouverte pour intercepter, au niveau applicatif, les données échangées. Par le dispositif de gestion des échanges de 10 paquets données, la synchronisation des états TCP dans le serveur de secours avec les états TCP dans le serveur primaire est assuré. Ainsi, en cas de nécessité de basculement de la connexion vers le serveur de secours, la connexion initiale sera 15 maintenue. Ce basculement est nécessaire notamment lorsque le serveur primaire devient défaillant. Le dispositif de gestion 41 permet donc de limiter les effets de bords ou latences inhérentes au basculement de la connexion vers le serveur de secours. On rend 20 ainsi plus transparent vis-à-vis du client, sa connexion avec un serveur primaire. En outre, en reprenant plusieurs fonctionnalités liées à la gestion des échanges des paquets de données, à la gestion de la défaillance d'un serveur, 25 à la gestion du basculement de la connexion, le dispositif 41 décharge, par exemple, la mémoire du serveur primaire. Ce serveur primaire est ainsi plus disponible pour effectuer d'autres tâches en lien avec son rôle. 30 Nous allons maintenant décrire le dispositif de gestion de la connexion avec un serveur client ainsi que le procédé de gestion d'une telle connexion en lien avec les Fig.2 et 3. A l'étape 61, une connexion est établie entre le 35 serveur client et le serveur primaire. L'étape 62, 2905545 14 quant à elle, détermine si le serveur primaire est défaillant ou non. Pour cela, un dispositif de gestion 42 de la défaillance d'un serveur est utilisé. Ce dispositif permet de détecter et 5 d'analyser les défaillances des serveurs. La détection de la défaillance des serveurs peut se faire de manière différente selon le type de panne. On distingue ainsi les pannes programmées, les pannes non programmées et les pannes au niveau 10 applicatif. Dans le cas de pannes programmées et des pannes au niveau applicatif sur le serveur primaire 26, le module 35 les détecte et envoie un message 52 au module 32 d'analyse des défaillances. 15 Dans le cas de pannes non programmées, celles-ci sont détectées par la non-réception de messages 53 d'annonce de disponibilité. En effet, au cours du fonctionnement normal du serveur primaire celui-ci envoie régulièrement ces messages 53. L'absence de 20 réception de ceux- ci caractérise alors une défaillance du serveur primaire. Le module 36 détecte de la même manière les défaillances du serveur de secours et envoie des messages (non représentés) au module 32. Cette détection est nécessaire car il ne 25 faut pas que le basculement de la connexion se fasse en direction d'un serveur défaillant. On notera que le message 52 peut être envoyé, par exemple, sur un canal UDP préétabli entre le module 35 et le module 32. 30 Le module 32 d'analyse des défaillances d'un serveur est ici déporté sur le dispositif de routage statique 23. Ceci permet de minimiser la consommation en ressources au niveau du serveur de secours 27. On notera, enfin, qu'une fois la défaillance du serveur 35 primaire détectée, ce dernier est désactivé. 2905545 15 En cas de défaillance du serveur primaire, le module 32 envoie un message 54 au module 33 du dispositif de gestion 43 du basculement de la 5 connexion. Le module 33 est ici représenté comme parti intégrante du dispositif de gestion 41. En variante ce module 33 peut être laissé sur le serveur de secours. On notera, cependant, que le déport du module 33 améliore la gestion dans le choix du 10 serveur de secours pour suppléer au serveur primaire défaillant. L'étape 63 correspond au déclenchement du basculement. Le module 33 va alors sélectionner le serveur de secours qui va reprendre la connexion avec 15 le serveur client. Pour cela, il envoie un message 55 vers le module 37 de basculement de l'identité du serveur de secours sélectionné. Le message 55 peut être envoyé par exemple via un protocole SSL afin de garantir la sécurité des 20 échanges entre le module 33 et le module 37. On limite ainsi toute attaque visant à déclencher un basculement intempestif des connexions vers des serveurs de secours. Le déclenchement du basculement s'accompagne de 25 l'arrêt des échanges de paquets à l'étape 64 ou gel de la connexion. Ainsi, la perte de paquets de données émis par le serveur client, au cours du basculement de la connexion, est limitée. Une fois le message 55 de basculement reçu par 30 le module 37, celui-ci va démonter l'interface réseau du serveur et le remonter en reprenant l'adresse IP du serveur primaire. Le serveur de secours reprend alors l'identité du serveur primaire à l'étape 65. Le module 37 informe, de cette nouvelle identité, le 35 module 38 de traitement des paquets de données 2905545 16 échangés, via un message 56. Le module 38 va alors activer le serveur de secours en tant que serveur primaire en désactivant le filtrage au niveau IP, et en désactivant la destruction des réponses faites en 5 direction du serveur client. Cette activation du serveur de secours se fait à l'étape 66. Une fois le serveur activé, les paquets échangés avec le client pourront être traités par le serveur de secours devenu serveur primaire. Celui-ci va alors en 10 informer le serveur client, à l'étape 67, afin d'annuler le gel de la connexion. Le serveur de secours peut ainsi envoyer un message (non représenté) approprié au serveur client, par exemple un message d'annonce d'une fenêtre de réception non 15 nulle. Ainsi, l'échange des paquets de données avec le client pourra reprendre plus rapidement. 20 REVENDICATIONS 1. Dispositif (14, 41) de gestion d'au moins une connexion établie avec au moins un serveur client (11a, llb, 21), ledit dispositif comprenant: - au moins une partie d'un dispositif de gestion (44) des échanges de paquets de données, - au moins une partie d'un dispositif de gestion de la défaillance (42) d'un serveur. 2. Dispositif de gestion selon la revendication précédente caractérisé en ce qu'il comprend au moins une partie d'un dispositif de gestion (43) du basculement de la connexion. 3. Dispositif de gestion selon la revendication précédente caractérisé en ce que le basculement de la connexion se fait vers plusieurs serveurs de secours (17a, 17b, 27). 4. Procédé de gestion d'au moins une connexion établie avec au moins un serveur client (11a, llb, 21) caractérisé en ce qu'au cours du basculement de la connexion vers au moins un serveur de secours (17a, 17b, 27), l'échange de paquets de données est arrêté. 5. Programme d'ordinateur sur un support de données et chargeable dans la mémoire interne d'un ordinateur, le programme comprenant des portions de code pour l'exécution des étapes du procédé selon la revendication 4 lorsque le programme est exécuté sur ledit ordinateur. 17 2905545 18 6. Composant programmable comportant un programme comprenant des portions de code pour l'exécution des étapes du procédé selon la revendication 4 lorsque le composant exécute 5 ledit programme. 7. Dispositif de routage caractérisé en ce qu'il comporte un dispositif de gestion d'au moins une connexion établie avec au moins un 10 serveur client (11a, 11b, 21) selon l'une quelconque des revendications 1 à 3. 8. Dispositif de routage selon la revendication précédente caractérisé en ce qu'il 15 associe à chaque paquet de données, en destination du serveur primaire (16, 26), une adresse de diffusion. 9. Dispositif de routage selon l'une 20 quelconque des revendications 7 à 8 caractérisé en ce qu'il associe à chaque paquet de données, en destination du serveur client (11a, 11b, 21), une adresse de diffusion. 25 10. Serveur primaire en connexion avec un serveur client (11a, 11b, 21), ladite connexion étant gérée par le dispositif selon l'une quelconque des revendications 1 à 3 caractérisé en ce que le serveur primaire (16, 26) répartit 30 la charge de traitement des données vers au moins un serveur secondaire.