WO2008025929A1 - Gestion de connexions etablies entre un cient et un serveur primaire - Google Patents

Gestion de connexions etablies entre un cient et un serveur primaire Download PDF

Info

Publication number
WO2008025929A1
WO2008025929A1 PCT/FR2007/051854 FR2007051854W WO2008025929A1 WO 2008025929 A1 WO2008025929 A1 WO 2008025929A1 FR 2007051854 W FR2007051854 W FR 2007051854W WO 2008025929 A1 WO2008025929 A1 WO 2008025929A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
connection
client
primary server
backup
Prior art date
Application number
PCT/FR2007/051854
Other languages
English (en)
Inventor
Denis Barbaron
Narjess Ayari
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2008025929A1 publication Critical patent/WO2008025929A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast

Definitions

  • the present invention relates to the field of communications and in particular to the possibility of making highly available an application between at least one client server and a primary server. More particularly, the invention makes it possible to improve the management of connections between at least one client server and a primary server.
  • ST-TCP Server fault-tolerant TCP proposes that part of the data packets exchanged, between at least one client server and the primary server, be copied and saved on this primary server. These copies are deleted when it is certain that at least one backup server has received them.
  • the TCP connection states between the primary server and at least one backup server are thus at best the same. This allows a transparent recovery of the connection by at least one backup server when the primary server becomes faulty.
  • backing up copies of data packets on the primary server is dependent here the ability of the standby server to receive packets from at least one client server.
  • the copies of the packets will accumulate on the primary server, and eventually disrupt the exchange between at least one client server and this server primary.
  • the present invention allows bearing or at least reduce all or part of the aforementioned drawbacks.
  • a first object of the present invention relates to a connection management device during which a client server exchanges data packets with a primary server, said device comprising at least a part of a data packet exchange management device allowing restoring at least one data packet to at least one standby server for synchronizing the state of the connection associated with said data packet in said standby server with the state of said connection in said primary server.
  • the primary server is unloaded from the synchronization of the state of the connection in a backup server with the state of this connection in the primary server.
  • the management device comprises at least a portion of a server failure management device.
  • the management device comprises at least a portion of a management device for switching the connection.
  • the management of the failover is offset in part on the routing device, which relieves the backup server of this task.
  • the invention also relates to a method for managing at least one connection during which a client server exchanges data packets with a primary server, said method comprising a step of restoring at least one data packet to at least one server backup device by a data packet exchange management device for synchronizing the state of the connection associated with said data packet in said backup server with the state of said connection in said primary server.
  • the invention also relates to a computer program on a data carrier and loadable in the internal memory of a computer, the program comprising portions of code for executing the step of the method as described above when the program is run on said computer.
  • FIG. 1 a topology of a network in accordance with the invention
  • Fig. 1 shows a topology of a network according to the invention.
  • At least one client server 11a, 11b exchanges data packets with a primary server 16.
  • Routing means determine, for this, the best path to route these packets between the client server (s) and the primary server.
  • client server it is understood any communicating equipment, such as a computer or a mobile phone, used by a client to access an application.
  • the routing device may consist of a single entity. Alternatively, it may comprise several entities.
  • the routing means thus comprise a dynamic routing device 12, whose routing table is automatically modified in connection with the changes that occur in the networks. This allows data packets to take the best available route.
  • the dynamic routing device also makes it possible to interconnect two networks that may be different.
  • the device 12 may interconnect an Internet network with a LAN.
  • the routing means also comprises a static routing device 13, in which the routing tables are determined in advance.
  • a management device 14, of at least one connection established with at least one client server, is arranged on the static routing device 13. The purpose of this device is to manage the connection or connections established between the client server and the primary server.
  • the management device 14 can be arranged on the dynamic routing device 12.
  • a switching device 15 allows the routing of packets to hosts, that is to say the primary server 16 and at least one backup server 17a, 17b. This switching device thus makes it possible to improve the performance of the network while isolating the data packets. This is done by forwarding the data packets only to the port to which the destination host is attached.
  • the primary server on receiving the packets will process the data to provide the application requested by the client server.
  • the primary server distributes the data processing to at least one secondary server.
  • the primary server can thus be a load balancer.
  • connection In order for a data exchange to take place between the client server and the primary server, a connection has to be established between the two servers.
  • connection is meant a virtual circuit established between two parties, that is to say here the client server and the primary server.
  • the primary server may have different connections with different client servers.
  • a connection uses different protocols to route data packets, including transport protocols such as TCP "Transmission Control Protocol” or SCTP "Stream Control Transmission Protocol” for example. These protocols are said in connected mode, that is, they control the transmission of data during the connection between the client and primary servers.
  • TCP protocol Transmission Control Protocol
  • SCTP Stream Control Transmission Protocol
  • the establishment of the connection takes place in three phases. At first, the client server sends a message with the start SYN connection flag, with the initial sequence specific to this client server. In a second step, the primary server responds by sending a message comprising a start of connection flag SYN with its own initial sequence, and by an acknowledgment with an acknowledgment flag ACK comprising the initial sequence of the incremented client server. In a third step, the client server acknowledges the data of the primary server by sending a message comprising an ACK flag with the initial sequence of the primary server incremented by 1.
  • the backup server must be able to quickly resume existing connections between the client server and the primary server. Indeed, the non-recovery of the connection leads to its closure and the wasting of resources on the primary server and networks. The loss of the connection would suddenly make an application unavailable to customers. They would be forced to wait for the creation of a new TCP connection to be able to use this application again.
  • the backup server (s) 17a, 17b know the information characterizing the existing TCP connection (s). This information is, for example, the initial sequences of the client server and the primary server.
  • the static routing device 13 sends not only the data packets to the primary server 16 but also to the backup servers 17a, 17b.
  • the static routing device 13 thus associates with each data packet, destined for the primary server, a broadcast address at the link layer.
  • each data packet will be copied and broadcast on all its output ports, which will allow the standby servers 17a, 17b to intercept it.
  • the backup server (s) will then analyze each data packet and will be able to synchronize their TCP connection states. Active replication is thus performed by duplicating on the backup server or servers the TCP connection states established and maintained between a client and a primary server. In case of failure of the latter, at least one of the backup servers will take over the primary server, preserving the integrity of TCP connections already established with the client.
  • the standby server it is necessary for the standby server to know the response that the primary server will send to the client server.
  • the static routing device 13 sends not only the data packets to the client server 11a, 11b but also to the backup servers 17a, 17b.
  • the static routing device 13 associates thus to each data packet, destined for the client server, a broadcast address at the link layer.
  • each data packet will be copied and broadcast on all its output ports, which will allow the standby servers 17a, 17b to intercept it.
  • the backup server (s) will then analyze each data packet and will be able to synchronize their TCP connection states.
  • the standby servers 17a, 17b only intercept packets using the TCP transport protocol. In a variant, they intercept all the exchanges between the client server (s) and the primary server. They intercept, for example, packets using other transport protocols such as UDP or DNS ("Domain Name Service").
  • the backup server or servers 17a, 17b may then incorporate a filtering at the IP level which will deliver to the transport layer only the data associated with a TCP connection. Thus, it will avoid overloading the central unit of the backup servers. It should be noted that in order to prevent the intercepted and filtered packet from being destroyed at the IP level, the destination IP address of the packet is modified at the level of the backup server which received it, in order to correspond to the address IP of this backup server.
  • backup server or servers 17a, 17b do not send, unlike the primary server, response to the client server. This one is rather silently destroyed at the level of the corresponding backup server.
  • Fig.2 presents a computer architecture according to the invention. It is represented here a single client server and a single backup server, of course the invention can be applied in the case where there are several client servers and several backup servers.
  • a client server 21 exchanges data packets 50 with a primary server 26 and a backup server 27. These packets are routed via a dynamic routing device 22 and a static routing device 23.
  • a device A server failure management system 42 includes a module 35 for detecting the failure of the primary server, a module 36 for detecting the failure of the backup server, a module 32 for analyzing the failures of a server.
  • a connection switching management device 43 comprises a module 33 for triggering the switchover, a module 37 for switching the identity of the backup server.
  • a data packet exchange management device 44 includes a module 34 for saving a copy of the exchanged data packets, a module 38 for processing the exchanged data packets.
  • the primary server 26 comprises a module 35 for detecting the failure of the primary server.
  • the backup server 27 comprises a module 36 for detecting the failure of the backup server, a module 37 for failover of the identity of the backup server, a module 38 for processing the data packets exchanged.
  • the static routing device 23 comprises a management device 41 of at least one connection established with a client server. This management device 41 comprises at least a part of a management device 44 of data packet exchanges, for example a module 34 for saving a copy of the exchanged data packets.
  • the management device 41 also comprises at least a part of a management device 42 for the failure of a server, for example a module 32 for analyzing the failures of a server.
  • the management device 41 also comprises at least part of a management device 43 for switching the connection, for example a module 33 for triggering the switchover.
  • the modules 32, 33, 34, 35, 36, 37, 38 may be hardware components, alternatively these modules may be software components.
  • the module 34 for backup of a copy of the exchanged data packets is particularly useful when the backup server 27 does not receive packets sent to or by the primary server 16.
  • the server 27 can not update its connection states. TCP.
  • the server 37 detects these losses of data packets in view of the acknowledgment of the primary server, which is sent to the client server. If the backup server fails to intercept this acknowledgment, the subsequent acknowledgment issued by the client will enable it to detect these packet losses.
  • Another benefit for the standby server to examine the acknowledgment of the primary server is that it can synchronize to the earlier its TCP connection states with this primary server.
  • the backup server requests a restitution of packets from the backup module 34. This request is made via the message 51.
  • the module 34 will send in response the missing packets to the module 38 for processing the data packets.
  • the request and the response provided can be transmitted on a dedicated channel, for example a UDP channel (not shown), established between the module 34 and the module 38.
  • a dedicated channel for example a UDP channel (not shown), established between the module 34 and the module 38.
  • the backup of a copy of the exchanged packets is here deported on the static routing device 23.
  • the exchange of the packets between the client server (s) and the primary server is thus little influenced by this backup.
  • all the data packets pass through the static routing device 23, which facilitates the backup of their copy.
  • the module 34 may still receive them via the module 34.
  • the module 34 makes a non-intrusive copy of the packets exchanged. For this, the packets are intercepted and filtered at the IP level. A "Divert Socket" is then opened to intercept, at the application level, the exchanged data.
  • the device for managing the data packet exchanges By the device for managing the data packet exchanges, the synchronization of the TCP states in the backup server with the TCP states in the primary server is ensured. Thus, if it is necessary to switch the connection to the backup server, the initial connection will be maintained. This failover is necessary especially when the primary server becomes faulty.
  • the management device 41 thus makes it possible to limit the effects of edges or latencies inherent to switching the connection to the backup server. This makes it more transparent vis-à-vis the client, its connection with a primary server.
  • the device 41 discharges, for example, the server memory. primary. This primary server is thus no longer available to perform other tasks related to its role.
  • Step 61 a connection is established between the client server and the primary server.
  • Step 62 determines whether the primary server is failing or not.
  • a management device 42 of the failure of a server is used. This device makes it possible to detect and analyze the failures of the servers. The detection of server failure can be done differently depending on the type of failure. We thus distinguish programmed failures, unscheduled failures and failures at the application level.
  • the module 35 detects them and sends a message 52 to the fault analysis module 32.
  • these are detected by the non-receipt of availability announcement messages 53. Indeed, during normal operation of the primary server it sends regularly these messages 53. The lack of reception thereof then characterizes a primary server failure.
  • the module 36 similarly detects the failures of the backup server and sends messages (not shown) to the module 32. This detection is necessary because it is not necessary that the switchover of the connection is towards a faulty server .
  • the message 52 can be sent, for example, on a pre-established UDP channel between the module 35 and the module 32.
  • the server fault analysis module 32 is here deported on the static routing device 23. This minimizes the resource consumption at the backup server 27. Finally, note that once the primary server failure detected, the latter is disabled.
  • the module 32 sends a message 54 to the module 33 of the management device 43 of the switchover of the connection.
  • the module 33 is here represented as integral part of the management device 41. Alternatively this module 33 can be left on the backup server. It will be noted, however, that the deportation of the module 33 improves the management in the choice of the backup server to supply the faulty primary server.
  • Step 63 corresponds to the triggering of the switchover.
  • the module 33 will then select the backup server that will resume the connection with the client server. For this, it sends a message 55 to the failover module 37 of the identity of the selected backup server.
  • the message 55 can be sent for example via an SSL protocol in order to guarantee the security of the exchanges between the module 33 and the module 37. This limits any attack aimed at triggering an unwanted switchover of connections to standby servers.
  • the triggering of the switchover is accompanied by the stop of packet exchanges in step 64 or freezing of the connection.
  • the loss of data packets sent by the client server, during the switchover of the connection is limited.
  • the failover message received by the module 37 it will dismount the network interface of the server and go back by taking the IP address of the primary server.
  • the backup server then resumes the identity of the primary server in step 65.
  • the module 37 informs, of this new identity, the module 38 for processing the data packets exchanged, via a message 56.
  • the module 38 will then activate the standby server as a primary server by disabling IP-level filtering, and disabling the destruction of responses to the client server.
  • This activation of The backup server is in step 66.
  • the packets exchanged with the client can be processed by the backup server that has become the primary server. It will then inform the client server, in step 67, to cancel the freeze of the connection.
  • the backup server can thus send an appropriate message (not shown) to the client server, for example an announcement message of a non-zero reception window.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)

Abstract

L' invention concerne un dispositif (41) de gestion de connexions au cours desquelles un serveur client (21) échange des paquets de données avec un serveur primaire (26), ledit dispositif comprenant au moins une partie (34) d'un dispositif de gestion (44) des échanges de paquets de données permettant la restitution d'au moins un paquet de données à au moins un serveur de secours (27) 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.

Description

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.

Claims

REVENDICATIONS
1. Dispositif (14, 41) de gestion de connexions au cours desquelles un serveur client (lia, 11b, 21) échange des paquets de données avec un serveur primaire , ledit dispositif comprenant: - au moins une partie d'un dispositif de gestion (44) 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.
2. Dispositif selon la revendication précédente caractérisé en ce qu'il comprend au moins une partie d'un dispositif de gestion de la défaillance (42) d'un serveur.
3. 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.
4. Procédé de gestion d'au moins une connexion au cours desquelles un serveur client (lia, 11b, 21) é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.
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.
PCT/FR2007/051854 2006-08-31 2007-08-30 Gestion de connexions etablies entre un cient et un serveur primaire WO2008025929A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0653546A FR2905545A1 (fr) 2006-08-31 2006-08-31 Gestion d'au moins une connexion etablie avec au moins un serveur client
FR0653546 2006-08-31

Publications (1)

Publication Number Publication Date
WO2008025929A1 true WO2008025929A1 (fr) 2008-03-06

Family

ID=38169288

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2007/051854 WO2008025929A1 (fr) 2006-08-31 2007-08-30 Gestion de connexions etablies entre un cient et un serveur primaire

Country Status (2)

Country Link
FR (1) FR2905545A1 (fr)
WO (1) WO2008025929A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200412600A1 (en) * 2017-02-14 2020-12-31 Futurewei Technologies, Inc. High availability using multiple network elements

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050086342A1 (en) * 2003-09-19 2005-04-21 Andrew Burt Techniques for client-transparent TCP migration

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050086342A1 (en) * 2003-09-19 2005-04-21 Andrew Burt Techniques for client-transparent TCP migration

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ALVISI L ET AL: "Wrapping server-side TCP to mask connection failures", PROCEEDINGS IEEE INFOCOM 2001. THE CONFERENCE ON COMPUTER COMMUNICATIONS. 20TH. ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER ANDCOMMUNICATIONS SOCIETIES. ANCHORAGE, AK, APRIL 22 - 26, 2001, PROCEEDINGS IEEE INFOCOM. THE CONFERENCE ON COMPUTER COMMUNI, vol. VOL. 1 OF 3. CONF. 20, 22 April 2001 (2001-04-22), pages 329 - 337, XP010538713, ISBN: 0-7803-7016-3 *
MARWAH M ET AL: "TPC server fault tolerance using connection migration to a backup server", PROCEEDINGS 2003 INTERNATIONAL CONFERENCE ON DEPENDABLE SYSTEMS AND NETWORKS. DSN 2003. SAN FRANCISCO, CA, JUNE 22 - 25, 2003, INTERNATIONAL CONFERENCE ON DEPENDABLE SYSTEMS AND NETWORKS, LOS ALAMITOS, CA : IEEE COMP. SOC, US, 22 June 2003 (2003-06-22), pages 373 - 382, XP010643874, ISBN: 0-7695-1952-0 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200412600A1 (en) * 2017-02-14 2020-12-31 Futurewei Technologies, Inc. High availability using multiple network elements
US11863370B2 (en) * 2017-02-14 2024-01-02 Futurewei Technologies, Inc. High availability using multiple network elements

Also Published As

Publication number Publication date
FR2905545A1 (fr) 2008-03-07

Similar Documents

Publication Publication Date Title
EP1535126B1 (fr) Procede de migration d'une application logicielle dans une architecture multi-ordinateurs, procede et systeme multi-ordinateurs pour realiser une continuite de fonctionnement mettant en oeuvre ce procede de migration
US8683033B2 (en) Apparatus, system, and method for server failover to standby server during broadcast storm or denial-of-service attack
FR2868643A1 (fr) Methode de decouverte d'appareils connectes a un reseau ip et appareil implementant la methode
EP2168358B1 (fr) Procédés et dispositifs por la communication de données de diagnostic dans un réseau de communication temps réel
EP1388058A1 (fr) Procede de communication et/ou de partage de ressources machines, entre une pluralite de membres d'une communaute, au sein d'un reseau de communication
US20020082927A1 (en) Intelligent caching routers
EP3357202B1 (fr) Système de restauration de services fournis par une passerelle résidentielle
EP2210396B1 (fr) Système d'interconnexion entre au moins un appareil de communication et au moins un système d'information distant et procédé d'interconnexion
FR2852753A1 (fr) Systeme de transmission de donnees client/serveur securise
WO2008025929A1 (fr) Gestion de connexions etablies entre un cient et un serveur primaire
EP1223511B1 (fr) Système de routage assurant la continuité de service des interfaces associées aux réseaux voisins
EP4066461B1 (fr) Procédé de coordination de la mitigation d'une attaque informatique, dispositif et système associés
EP3453141B1 (fr) Procédé de contrôle d'une passerelle résidentielle d'un réseau de communication, procédé de supervision, procédé d'exécution d'une action, dispositifs et programme d'ordinateur correspondants
EP2583429B1 (fr) Procédé et système de communication basés sur ws-discovery
WO2020002853A1 (fr) Procédés de gestion du trafic associé à un domaine client, serveur, nœud client et programme d'ordinateur correspondants
CA2533289C (fr) Procede de localisation d'objets mobiles communicants au sein d'un reseau de communications, par transmission d'identifiants de localisation par des repeteurs et mise a jour de serveur
KR100793446B1 (ko) 이중화 통신 시스템의 페일 오버 및 원복 처리 방법
WO2021105617A1 (fr) Procede d'assistance pour la gestion d'une attaque informatique, dispositif et systeme associes
EP2341427B1 (fr) Redémarrage autonome des noeuds d'un réseau pair-à-pair
WO2008031967A2 (fr) Procédé de supervision d'une session d'accès a un service établie par un terminal client au moyen d'un protocole de configuration dynamique
FR3003052A1 (fr) Procede et dispositif de gestion de quorums de nœuds de groupes a haute disponibilite d'un calculateur haute performance

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07823753

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07823753

Country of ref document: EP

Kind code of ref document: A1