GESTION DE CONNEXIONS ETABLIES ENTRE UN CLIENT ET UN SERVEUR PRIMAIRE

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

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 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 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 de connexions au cours desquelles un serveur client échange des paquets de données avec un serveur primaire , ledit dispositif comprenant au moins une partie d'un dispositif de gestion des échanges de paquets de données permettant la restitution d'au moins un paquet de données à au moins un serveur de secours en vue de synchroniser l'état de la connexion associée audit paquet de données dans ledit serveur de secours avec l'état de ladite connexion dans ledit serveur primaire. Ainsi, le serveur primaire est déchargé de la synchronisation de l'état de la connexion dans un serveur de secours avec l'état de cette connexion dans le serveur primaire.

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 ou en combinaison, énoncées ci-après:

Le dispositif de gestion comprend au moins une partie d'un dispositif de gestion de la défaillance d'un serveur.

Le dispositif de gestion comprend au moins une partie d'un dispositif de gestion du basculement de la connexion.

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.

L'invention concerne aussi un procédé de gestion d'au moins une connexion au cours desquelles un serveur client échange des paquets de données avec un serveur primaire ledit procédé comprenant une étape de restitution d'au moins un paquet de données à au moins un serveur de secours par un dispositif de gestion des échanges de paquets de données en vue de synchroniser l'état de la connexion associée audit paquet de données dans ledit serveur de secours avec l'état de ladite connexion dans ledit serveur primaire .

L'invention concerne aussi 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 l'exécution de l'étape du procédé tel que décrit ci-dessus lorsque le programme est exécuté sur ledit ordinateur.

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 représentant:

- A la Fig.l, une topologie d'un réseau conforme à 1 ' invention;

- A la Fig.2, une architecture informatique conforme à l'invention; - 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. Au moins un serveur client lia, 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 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é 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 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 interconnecter un réseau Internet avec un réseau LAN. 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 é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 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 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é. 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 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 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 clients.

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 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 . 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 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 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é 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 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 création d'une nouvelle connexion TCP pour pouvoir utiliser de nouveau cette application.

En variante, plusieurs serveurs de secours peuvent reprendre la connexion.

Afin de garantir, que le ou les serveurs de secours puissent reprendre la ou les connexions

existantes entre le ou les serveurs client lia, 11b et le serveur primaire 16, il faut que le ou les serveurs de secours 17a, 17b connaissent les 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 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 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 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 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 .

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 seulement les paquets de données au serveur client lia, 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 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 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 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 échanges entre le ou les serveurs clients et le serveur primaire. Ils interceptent, par exemple, des paquets utilisant d'autres protocoles de transport comme 1 ' UDP ou le DNS ("Domain Name Service") . Le ou les serveurs de secours 17a, 17b peuvent alors 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é ne soit détruit au niveau IP, l'adresse IP de 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 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.

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 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 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 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.

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.

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, 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 é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.

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.

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.

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 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 serveur primaire, qui est émis à destination du 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 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 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.

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 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 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 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 les recevoir via le module 34. Enfin, la présence du 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 non intrusive des paquets échangés. Pour cela les paquets sont interceptés et filtrés au niveau IP. Une

"Divert Socket" est ensuite ouverte pour intercepter, au niveau applicatif, les données échangées.

Par le dispositif de gestion des échanges de 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 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 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, à 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.

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 serveur client et le serveur primaire. L'étape 62, 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 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 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. 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 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 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. 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 primaire détectée, ce dernier est désactivé.

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 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 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 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 é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 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 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 module 38 de traitement des paquets de données é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 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 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 nulle. Ainsi, l'échange des paquets de données avec le client pourra reprendre plus rapidement.