WO2004074959A2 - Procede de production d’une grappe de traitement de donnees et systeme informatique pour fonctionner en grappe - Google Patents

Procede de production d’une grappe de traitement de donnees et systeme informatique pour fonctionner en grappe Download PDF

Info

Publication number
WO2004074959A2
WO2004074959A2 PCT/FR2004/000426 FR2004000426W WO2004074959A2 WO 2004074959 A2 WO2004074959 A2 WO 2004074959A2 FR 2004000426 W FR2004000426 W FR 2004000426W WO 2004074959 A2 WO2004074959 A2 WO 2004074959A2
Authority
WO
WIPO (PCT)
Prior art keywords
operating system
server
data processing
network
digital data
Prior art date
Application number
PCT/FR2004/000426
Other languages
English (en)
Other versions
WO2004074959A3 (fr
Inventor
Philippe Augerat
Yves Denneulin
Simon Derr
Pierre Lombard
Original Assignee
Centre National De La Recherche Scientifique -Cnrs-
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 Centre National De La Recherche Scientifique -Cnrs- filed Critical Centre National De La Recherche Scientifique -Cnrs-
Publication of WO2004074959A2 publication Critical patent/WO2004074959A2/fr
Publication of WO2004074959A3 publication Critical patent/WO2004074959A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment

Definitions

  • the field of the invention is that of clusters for computing and processing information.
  • a data processing cluster consists of several computers that communicate in order to divide up the data processing tasks that they each execute on an independent operating system.
  • Processing tasks are those of applications which require considerable calculations.
  • Applications are for example traditional applications of intensive computing (molecular dynamics, chemistry ab initio, oceanography, meteorology) or even more recent applications of information processing (indexing of web documents, distributed storage, risk analysis in finance, search for similarity in genomics, database).
  • Other technologies exist such as those of multiprocessor machines with a common operating system, but these are outside the scope of the invention.
  • the state of the art in the field of the invention includes different architectures of computer clusters. There are those in which computers are permanently dedicated to the cluster operating mode. A significant quantity of computer directly influences the price of such architectures.
  • solutions which consist in deploying a computing application above the operating system present on each computer with a protection system which prevents the computing application from corrupting the computer or the network.
  • This technique called sandboxing (sandboxing in the literature) is found for example in the known software Condor and XtremWeb.
  • the drawbacks of this technique are the limitations in terms of performance rights and the installation constraints which lack flexibility.
  • the object of the invention is to propose a network infrastructure which aggregates information processing equipment within a virtual processing cluster with an operation similar to that of equipment arranged as a permanent cluster.
  • Information processing equipment is understood to mean all digital data processing equipment such as for example personal computers connected to a local corporate network of the Intranet type or else devices connected to a home automation network each with a hardware interface (abbreviated to Basic Input Output System in English) to launch a stand-alone operating system that allows calculations to be performed on digital data.
  • a first object of the invention is a method for producing a data processing cluster.
  • the method is remarkable in that it comprises: steps consisting in advance: - taking digital data processing equipment which are connected in a network and which are usually provided for processing each of the data while being active on a first system of operation launched from a hardware interface system; configure the hardware interface system of each digital data processing equipment with a network boot capability; connect to said network, at least one server comprising a second operating system which is designed to operate in cluster mode; and steps consisting in: booting from the server, each digital data processing equipment that the server detects inactive on the first operating system, by means of a network boot protocol; load from the server, the second operating system into RAM of each digital data processing equipment thus started.
  • the method comprises a step consisting in previously configuring the second operating system of. so that it does not include any access driver to a first mass storage system which is managed by the first operating system.
  • the method comprises a step consisting in assigning a private network address to the server and to each computer of the cluster.
  • the method comprises a step consisting in configuring the second operating system before loading into random access memory of each computer so as to encrypt each communication on the network.
  • the encryption of communications on the network isolates digital data processing equipment from an outside world.
  • the server uses a data service parallelization environment arranged to direct on the network, a request to load data coming from a digital data processing equipment to a daemon which returns a response to the request.
  • the daemon is for example another piece of digital data processing equipment or another server which has the data to be loaded.
  • the data can relate to both executable code data and numeric value data.
  • the additional technical effect is on a scaling of a large number of workstations which results from the reduction in server load to load the second operating system and also to load applications to be executed by digital data processing equipment.
  • a second object of the invention is a computer system allowing operation in a data processing cluster.
  • the computer system is remarkable in that it comprises: a network of digital data processing equipment which is usually provided for processing each of the data while being active on a first operating system, the hardware interface system of each digital data processing equipment having network boot capability; a server connected to the network comprising a second operating system which is designed to operate in cluster mode; and in that the server is arranged to detect at least one inactive digital data processing equipment on the first operating system, to start up by means of a network boot protocol the detected inactive digital data processing equipment and to load the second operating system in random access memory of the digital data processing equipment thus started.
  • the second operating system does not include any access driver to a first mass storage system which is managed by the first operating system.
  • the server and each digital data processing equipment of the network have a private network address.
  • the second operating system comprises means for encrypting each communication on the network. More particularly, the second operating system includes a parallelization environment arranged to direct a load request from a digital data processing equipment, to a daemon which returns a response to the request.
  • FIG. 1 is a diagram of production process steps according to the invention.
  • FIG. 2 is a diagram of a computer system in which the invention is implemented
  • Figure 1 shows process steps according to the invention for producing a data processing cluster (cluster in English).
  • a data processing cluster cluster in English.
  • steps 16, 17, 18 to prepare a hardware configuration of computers so as to be able to operate these computers in cluster mode.
  • steps 26, 27, 28 for temporarily producing a cluster using these computers.
  • Step 16 consists of taking standard computers arranged for other operations than that in cluster mode.
  • FIG. 2 shows several computers 1, 2, 3 connected to a private network 4, each respectively by means of a coupler 14, 24, 34.
  • Computers 1, 2, 3 are conventional computers such as personal microcomputers who each include a microprocessor 10, 20, 30, a re-programmable memory 12, 22, 32, a random access memory 11, 21, 31, input-output couplers 15, 25, 35 and a mass memory 13, 23, 33.
  • the mass memory 13, 23, 33 is for example a hard disk. More generally, it is a mass storage system intended to contain executable files and data files which the computer user can access to use different applications.
  • the input-output couplers 15, 25, 35 are generally connected for each computer to a keyboard, a mouse, a floppy drive and a screen not shown in the figure.
  • BIOS Basic Input Output System
  • BIOS functions are generally configurable such as for example those to define a computer boot sequence, turning on the computer from the local power switch or from the network coupler, prior execution environment ( PXE abbreviated for Preboot eXecution Environment in English) which allows to execute a launch program (Boot in English for shoehorn) in order to load and initialize in RAM, an operating system (OS abbreviated for Operating System computer), from the network, from the hard drive or from a floppy disk.
  • PXE abbreviated for Preboot eXecution Environment in English prior execution environment
  • a launch program Boot in English for shoehorn
  • OS operating system
  • OS Operating System computer
  • the random access memory 11, 21, 31 differs from mass memory and from re-programmable memory in that it is reset each time the computer is restarted.
  • a first operating system loaded into random access memory 11 includes access drivers to a first mass storage system comprising mass memory 13 and s' it is distributed, possibly all or part of the mass memories 23, 33. It is the same for the random access memories 21, 31 respectively of the computers 21, 31 and other computers connected to the network 4.
  • each user of a computer can do run resident applications on the first mass storage system and communicate with other users of other computers over the network 4.
  • step 17 consists in configuring the hardware interface system of the computers which one wishes to be able to use in cluster mode, with a network booting ability.
  • the hardware interface system of computers is already configured with this possibility of booting by the network for reasons other than those which are the subject of the invention, it suffices to ensure that this faculty is present for each network coupler 14, 24, 34 of each computer 1, 2, 3.
  • This option is for example provided by recording in reprogrammable memory 12, 22, 32, of PXE functionalities which emit a DHCP request (abbreviation of Dynamic Host Configuration Protocol in English ) in priority to a request to access the boot sector of a disk and capable of using the TFTP protocol (abbreviation of Trivial File Transfer Protocol in English).
  • DHCP request abbreviation of Dynamic Host Configuration Protocol in English
  • TFTP protocol abbreviation of Trivial File Transfer Protocol in English
  • step 18 consists in connecting a server 5 to the network 4.
  • the server 5 comprises an operating system different from that usually used by computers 1, 2, 3 to operate individually in a station. job.
  • This second operating system is intended for operation in cluster mode. It is for example stored on a second mass storage system for which the second operating system includes access drivers.
  • the second operating system is the OS known Linux for its known properties of open system which make it possible to intervene even on its kernel to adapt it to a targeted use such as particularly here, in the cluster operating mode according to the invention.
  • the second operating system is configurable in such a way that the security level is also.
  • the second operating system is for example configured to use private network addressing, to filter network access both to the server and to each computer then considered as a client, to encrypt connections, to contain no user account interactive individual or to authorize no other service than those provided by the server 5.
  • the second operating system is configured in a step 19, so as to ensure complete partitioning between the individual user mode and the cluster operating mode.
  • the access drivers to the first mass storage system are deleted in the second operating system.
  • the individual and cluster user operating modes have physically separate mass storage systems.
  • Network security can also be improved by assigning private addresses to computers and the server in a step 29 or by imposing in a step 36 to encrypt communications on the network 4.
  • the second operating system is enhanced with cryptographic means.
  • step 50 in which the server is arranged with a filtering table which references the network addresses of each item of equipment to be introduced into the cluster so that the server broadcasts the addresses allowed to each device in the cluster to limit communications on the network to these devices only. You can also configure the network switches firmware to lock the communication ports on the network.
  • the server 5 also includes a file containing a sequence of commands (script in current computer vocabulary) arranged to start each computer on which it is downloaded.
  • the sequence includes commands which, when executed by a computer 1, 2, 3, on which it is downloaded, load the second operating system into respective RAM 11, 21, 31, from the server 5.
  • the sequence does includes no command to install the second operating system in respective mass memory 13, 23, 33.
  • the server 5 does not provide any software installation on the individual computers 1, 2, 3 for the operation in cluster mode. This minimizes the impact of the cluster operating mode on the work of the administrator and on the work of each individual user.
  • the administrator After the administrator has made sure in the preliminary phase that the BIOS is configured to allow booting by network 4 of each computer once and for all in step 16, the administrator does not need to provide maintenance, updating or uninstalling software on computers as client workstations.
  • the administrator only needs to worry about reconfiguration on the server 5 without having to intervene individually on each client station, for example in the event of a local failure. This absence of software installation on client workstations considerably facilitates the deployment of clustered applications, updates and deletions.
  • the server 5 allows operation in cluster mode, transparent for each individual user. Both the operating system and the application software of the cluster mode, being limited to the single RAM 11, 21, 31 of each computer 1, 2, 3, each individual user only needs to restart his machine in the event of operating failure in cluster mode. When his machine restarts on the first operating system, the individual user sees no trace of operation in cluster mode.
  • the server 5 is arranged to centralize the operation of the individual computers which, in cluster mode, behave like diskless machines.
  • a cache functionality cache in English
  • such a choice requires taking certain precautions because of a loss of the strong security aspect which is provided by a total lack of disk access in the computer.
  • a parallelization environment for processing requests from client stations.
  • This environment includes functions for implementing at least one of the protocols explained now with reference to FIGS. 3 to 5.
  • the protocol explained with reference to FIG. 3 is suitable for any type of data loading request. It has the advantage of being standard at a client station, request transmission, response reception. It is particularly suitable for implementing an imposed protocol such as for example NFS (abbreviation of Network File System in English). It is also very appropriate when the source of the response is not known a priori at the time of issuing the request.
  • NFS abbreviation of Network File System in English
  • a client transmits in a known manner a request to a server with a source IP network address C ⁇ , a destination IP network address se , a source port Port C ⁇ , a destination port Port se .
  • a transition 41 validated by reception of the request sent by the client activates a step 37.
  • the server processes the metadata of the request, that is to say for example for a request for access to a file, date and time information, owner, access permissions, file size, memory location, etc.
  • the server sends a request to a daemon.
  • daemon a machine or system available on the network and which has the data to respond to the request.
  • the server reports the body of the request received from the client in the body of the request sent to the devil with the header EPDI demon network address and port of the devil as Port address and destination port.
  • the source port is generally freely chosen at random by a request transmitter.
  • the server places in the header of its request, the network address of the IP client C ⁇ and the client port Port C ⁇ as source address and port source.
  • a transition 38 validated by reception of the request sent by the server activates a step 39.
  • the daemon sends a response with the network address of the IP client C ⁇ and the port of the client Port C ⁇ as the address and destination port.
  • the daemon places the network address in the header of its response of the IP server se and the server port Port se as source address and source port.
  • each server also incorporates its IP network address se and its Port port se in the request body in step 37 so as to bring them to the knowledge of the daemon for activation of the step 39.
  • the service expected of the demon being identical to that expected from the server, port Port may also simply be identical to the port Portde-
  • IP address is as source address, IP address C ⁇ as a destination network address, port to port as the source port and the port Port C ⁇ as a destination port.
  • the essential modifications are located at the server and daemon level which introduce source addresses and fake source ports in the transmission of messages (spoofing in English).
  • the server When the client issues a read access request with a file name, the server simply reads the metadata, determines the daemon which manages the data to be read and transfers this request to the determined daemon. The server is then quickly available to process a new request. It is the daemon which transfers the data read to the client, which represents the most considerable load in processing the request.
  • the server When the client issues a write access request with a file name, the server simply updates the metadata, determines the daemon that manages the data to be written and transfers this request to the determined daemon. The server is then quickly available to process a new request. It is the daemon which writes the data, writing which represents the most considerable load of processing of the request with emission of an acknowledgment to the client at the end of writing.
  • the server When the client issues an access request for creation or deletion with a file name, the server simply updates the metadata, determines the daemon which manages the physical file medium to be created or deleted and to transfer this request to the determined daemon. The server is then quickly available to process a new request. It is the daemon which creates or deletes files on the physical medium, creation or deletion which represents the most considerable load of processing the request.
  • the foregoing explanations can also apply to accesses to data structures (variables, arrays or others) in random access memory as we will see later.
  • the daemon can be any machine on the network such as another server or such as another computer 2, 3 using its RAM.
  • the protocols explained with reference to FIGS. 4 and 5 differ from that explained with reference to FIG. 3 in that the daemon responds to a request sent by the client without having passed through the server and identifies itself as being the transmitter of the response without replacing the server. Establishing a direct communication dialogue between the client and the daemon, increases the throughput performance on the network for subsequent requests concerning the same identified daemon.
  • These protocols are suitable for any type of data loading request. They have the advantage of being standard at the level of a daemon, emission request, reception response.
  • the protocol explained with reference to FIG. 4 is particularly suitable when it is possible to choose a protocol such as for example PVFS (abbreviation for Parallel Virtual File System in English). This protocol was developed by the University of Clemson and NASA, for clusters of Workstations of the type known as Beowulf. It is also very appropriate when the source of the response is not known a priori at the time of issuing the request.
  • PVFS abbreviation for Parallel Virtual File System in English
  • a client transmits in a known manner a request to a server with a source IP network address C ⁇ , a destination IP network address se , a source port Port C ⁇ , a destination port Port se -
  • a transition 41 validated by reception of the request sent by the client activates a step 43.
  • the server issues a redirect command to the client.
  • the server indicates in the body of the redirection command, the IP network address of e and the Port port of the daemon capable of returning a response to the request, with the network address of the IP server se and the port of the Port server is the source address and port.
  • a transition 44 validated by the redirection command activates a step 45.
  • step 45 the client sends the request to the daemon with the source IP network address C ⁇ , a destination IP network address from , the source port Port C ⁇ , a destination port Port from .
  • the transition 38 validated by reception of the request sent by the client in step 45 activates a step 46.
  • step 46 the daemon emits a response with the network address of the client IP C ⁇ and the port of the client Port C ⁇ as the address and destination port.
  • the demon up in the header of its response, its IP address and e title to Port port source address and source port.
  • a transition 47 validated by receiving the response sent by the daemon allows it to continue executing the process in progress.
  • the protocol explained with reference to FIG. 5 is particularly suitable when the source of the response is known by the server before the request is issued by the client.
  • the server issues a redirect command to the client.
  • the server indicates in the body of the redirection command, the IP address network and the port port of the daemon capable of returning a response to a request that it is expected to be issued by the client, with the address in header IP server network se and Port server port se as address and source port.
  • a transition 44 validated by the redirection command activates a step 45.
  • step 45 the client sends the request to the daemon with the source IP network address C ⁇ , a destination IP network address d e, the source port Port C ⁇ , a destination port Portde-
  • the transition 38 validated by reception of the request sent by the client activates a step 46.
  • the daemon issues a response with the network address of the IP client C
  • the daemon places at the head of its response, its IP network address of and its Port d e port as source address and source port.
  • a transition 47 validated by receiving the response sent by the daemon allows it to continue executing the process in progress.
  • the following requests concerning data for which the daemon is capable of providing a response can be addressed directly to the daemon without passing through the server.
  • the server 5 is produced in the distributed form of sub-servers each assigned to a sub-network of the network 4. Each set of computers connected to the same sub-network only knows the sub- server assigned to this subnet. Each sub-server can then have a second independent storage system with its daemon (s).
  • the first and second solutions can also be combined by considering as a daemon of a sub-server assigned to a sub-network, a sub-server assigned to another sub-network.
  • steps 16 to 18 now provides a hardware configuration suitable for producing a data processing cluster in accordance with the invention as often as certain conditions are fulfilled by executing steps 26 to 27.
  • These conditions are essentially qu 'A sufficient number of computers 1, 2, 3 are inactive on their first usual operating system so as to be available to produce a data processing cluster.
  • the inactivity of computers results for example from their extinction by their individual users at the end of the working day.
  • Step 26 is for example activated outside the working hours of individual users or at a fixed time at which individual users have been asked to turn off their computers.
  • the server 5 detects the computers connected to the network which are inactive on the first operating system. These are, for example, computers that are turned off or, more specifically, computers on standby on which no interaction has been engaged for some time.
  • the server 5 then starts each computer by means of a protocol of known type such as "Wake on LAN" and then the network boot protocol mentioned previously in the PXE environment.
  • each computer 1, 2, 3 sends a DHCP request to server 5 which returns a response with a private IP network address for the computer, a name of command program executable by computer and a command sequence download option.
  • the computer then usually sends a so-called GET request under TFTP to load the executable command program into RAM.
  • the computer sends a GET request under TFTP to load into RAM, the command sequence indicated as an option.
  • Step 27 uses the downloaded sequence of commands to load the second operating system into RAM from the server 5.
  • the sequence of commands a first command "TFTP Get: Linux kernel” and a second command “TFTP Get: Linux data” where Linux denotes the second operating system, kernel denotes the kernel of the second operating system and data denotes configuration data for the second operating system.
  • computer 1 By executing the first command, computer 1 generates a first request to server 5 which returns to computer 1, a first response containing the kernel of the second operating system. After loading the kernel of the second operating system into memory 11, the computer 1 executes the second command which generates a second request to the server 5. The server 5 then returns to the computer 1, a second response which contains configuration data for the second operating system.
  • the computer 2 then the computer 3, execute the same successively the first and the second command to achieve the same result as that of the computer 1.
  • the configuration data of the second operating system includes the parallelization environment previously explained with reference to one of FIGS. 3 to 5 with in particular the parameters of the parallelization protocol making it possible to also give demon behavior.
  • the server 5 lists the last computer to which it sent a second response and considers this last computer, then called the previous computer, as a daemon for implementing the protocol previously explained with reference to one of FIGS. 3 to 5.
  • the explained protocol with reference to FIG. 5 is well suited since it is the server which determines the daemon for loading the operating system into the following computer.
  • the server 5 has not sent a second response to a previous computer, it is responsible for transmitting any response to any request received from a computer. After sending a second response to a previous computer, different variants are possible according to the protocol of the parallelization environment implemented.
  • the server 5 retransmits any first request and any second request coming from a current computer, to the previous computer which then acts like the daemon of FIG. 3 to send a first and / or second response to the current computer.
  • the server 5 When the server 5 receives the first request from the computer 2, it routes this request to the last listed computer to apply the protocol previously explained with reference to FIG. 3. If no computer is listed, the server 5 sends itself the first response to computer 2. If computer 1 is listed, the server 5 directs the first request to computer 1 which sends the first response to computer 2 according to the protocol previously explained in. reference to FIG. 3. When the server 5 receives the second request from the computer 2, the computer 1 being listed, the server 5 directs the second request to the computer 1 which sends the second response to the computer 2 in accordance with the protocol previously explained with reference to FIG. 3.
  • the server 5 When the server 5 receives the first request from the computer 3, it routes this request to the last listed computer to apply the protocol previously explained with reference to FIG. 3. If the computer 1 is the one listed, the server 5 directs the first request to computer 1 which sends the first response to computer 3 in accordance with the protocol previously explained with reference to FIG. 3. If computer 2 is listed, the server 5 directs the first request to computer 2 which sends the first response to computer 3 in accordance with the protocol previously explained with reference to FIG. 3. When the server 5 receives the second request from computer 3, computer 2 being listed, the server 5 points the second request to computer 2 which sends the second response to computer 3 in accordance with the protocol previously explained in r refer to figure 3.
  • the server 5 sends a redirection command to any very first request from a current computer.
  • the command addressed to the current computer is to redirect to the previous computer which then acts like the daemon in FIG. 4 to send a first and or a second response to the current computer.
  • the server 5 sends a redirection command as soon as it comes into contact with a next computer considered to be the current computer.
  • the command addressed to the current computer is to redirect to the previous computer which then acts as the daemon in FIG. 5 to send a first and or a second response to the current computer.
  • the process of loading the second operating system which has just been explained for computers 1, 2, 3, continues in the same way for the following computers. We thus observe a loading in pipeline of the components of the operating system. As computers work only on their virtual memory, daemon responses are made from virtual memory.
  • NFSp distributed file system of known type NFS
  • the loading of files from the server 5 on the individual computers remains standard on the individual computer side considered as that customer.
  • the known NFSROOT kernel therefore remains applicable without modification.
  • the storage of the second operating system on the virtual disk then allows the computer to use the NFSp environment to be used as a daemon.
  • the NFSp environment offers a file service which enables scaling up on several hundred clients.
  • the NFSp environment advantageously includes known functionalities for managing a large capacity storage system with high security (RAID for short for Redundant Array of Inexpensive Disks). This makes it possible to support sub-server failures when the server 5 is distributed, including in the personal computers.
  • the second data storage system can also advantageously use the known iSCSI technology as an alternative to the NFSp environment.
  • the daemon can then be of SCSI or SAN type.
  • Step 28 is that which exits the individual computers from the cluster operating mode. Step 28 is either activated at a specific time, for example at the end of the night to allow individual computers to resume their workstation functionality during the day, or activated on detection of human intervention by the keyboard, mouse or the local computer start button. In step 28, the computer's RAM is reset, possibly by shutting down the computer, so as to purge the second operating system and the data and or programs related to the operation in cluster mode. A personal computer is then again available to operate on its first operating system. Step 28 is re-looped pending execution of step 26 for possible subsequent cluster production.
  • the cluster produced by the method according to the invention allows data processing which requires a lot of computing resources thanks to a distribution of faults between the different computers of the cluster.
  • the server centralizes the operation of the cluster, it does not constitute a bottleneck on the network thanks to the implementation of the protocol of FIG. 3 or 4 for any loading of application data in a computer of the cluster in during operation on the second operating system loaded, preferentially but not necessarily by implementing the protocol of FIG. 5.
  • the example of a cluster described above by way of illustration relates to personal computers but it is understood that any data processing equipment which can load an operating system from a network is suitable for creating a virtual cluster.
  • the ease of loading a second operating system for operating in cluster mode provided by the invention, makes it possible to benefit from existing equipment in a particularly flexible manner when it is available while it is not called upon to operate in a mode for which they are normally intended, and this without affecting this usual mode of operation.
  • Equipment is available both during a shutdown period and during a so-called hibernation period such as the standby mode in which it is inactive on its first usual operating system.
  • the loading mode of the second operating system allows easy scaling in that it does not limit the number of devices to be introduced into the cluster.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)
  • Multi Processors (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)

Abstract

Procede de production d'une grappe de traitement de donnees et systeme informatique pour fonctionner en grappe. Pour produire une grappe de traitement de donnees, le procede comprend des etapes consistant a prealablement prendre des equipements de traitement de donnees numeriques (1,2,3) qui sont relies en reseau et qui sont habituellement prevus pour traiter chacun des donnees en etant actifs sur un premier systeme d'exploitation lance a partir d'un systeme d'interface materiel, configurer le systeme d'interface materiel de chaque equipements de traitement de donnees numeriques avec une faculte d'amorcage reseau, relier au reseau (4), au moins un serveur (5) comprenant un deuxieme systeme d'exploitation qui est prevu pour fonctionner en mode grappe et des etapes consistant a demarrer a partir du serveur (5), chaque equipements de traitement de donnees numeriques que le serveur detecte inactif sur le premier systeme d'exploitation, au moyen d'un protocole d'amorgage reseau puis a charger a partir du serveur (5), le deuxieme systeme d'exploitation en memoire vive de chaque equipements de traitement de donnees numeriques ainsi demarre.

Description

Procédé de production d'une grappe de traitement de données et système informatique pour fonctionner en grappe.
Le domaine de l'invention est celui des grappes pour le calcul et le traitement de l'information. Une grappe de traitement de données comprend plusieurs ordinateurs qui communiquent de façon à se répartir des tâches de traitement de données qu'ils exécutent chacun sur un système d'exploitation indépendant.
Les tâches de traitement sont celles d'applications qui nécessitent des calculs considérables. Les applications sont par exemple les applications traditionnelles du calcul intensif (dynamique moléculaire, chimie ab initio, océanographie, météorologie) ou encore les applications plus récentes du traitement de l'information (indexation de documents web, stockage distribué, analyse de risque en finance, recherche de similarité en génomique, base de données). D'autres technologies existent telles que celles des machines multiprocesseurs avec système d'exploitation commun mais celles-ci sortent du domaine de l'invention.
L'état de la technique du domaine de l'invention comprend différentes architectures de grappes d'ordinateur. II existe celles dans lesquelles les ordinateurs sont dédiés à demeure au mode de fonctionnement en grappe. Un quantité importante d'ordinateur influe directement sur le prix de telles architectures.
On connaît par exemple les solutions qui consistent à déployer une application de calcul au dessus du système d'exploitation présent sur chaque ordinateur avec un système de protection qui empêche l'application de calcul de corrompre l'ordinateur ou le réseau. Cette technique dite du bac à sable (sandboxing dans la littérature) se retrouve par exemple dans les logiciels connus Condor et XtremWeb. Les inconvénient de cette technique sont dans les limitations en terme de droit d'exécution et dans les contraintes d'installation qui manquent de souplesse.
On connaît aussi les solutions qui consistent à commuter vers un environnement de fonctionnement en mode grappe disposant d'un système d'exploitation distinct. Le système d'exploitation en mode grappe réside généralement sur une partition de disque dur avec possibilité de double amorçage sur le système d'exploitation habituel ou en mode grappe. Cependant le coût d'administration est considérable, par exemple pour tenir à jour le système de grappe sur chaque ordinateur. Un système d'exploitation centralisé limite nécessairement le nombre d'ordinateurs aux capacités d'un serveur pour communiquer sur le réseau auquel ils sont reliés.
L'invention a pour but de proposer une infrastructure pour réseau qui agrège des équipements de traitement de l'information au sein d'une grappe virtuelle de traitement avec un fonctionnement semblable à celui d'équipements agencés en grappe à demeure. On entend par équipements de traitement de l'information tous équipements de traitement de données numériques tels que par exemple des ordinateurs personnels reliés à un réseau local d'entreprise de type Intranet ou encore des appareils reliés à un réseau domotique avec chacun un système d'interface matériel ( BIOS en abrégé pour Basic Input Output System en anglais) pour lancer un système d'exploitation autonome qui permet de faire des calculs sur des données numériques.
Un premier objet de l'invention est un procédé pour produire une grappe de traitement de données. Le procédé est remarquable en ce qu'il comprend: des étapes consistant à préalablement: - prendre des équipements de traitement de données numériques qui sont reliés en réseau et qui sont habituellement prévus pour traiter chacun des données en étant actifs sur un premier système d'exploitation lancé à partir d'un système d'interface matériel; configurer le système d'interface matériel de chaque équipements de traitement de données numériques avec une faculté d'amorçage réseau; relier au dit réseau, au moins un serveur comprenant un deuxième système d'exploitation qui est prévu pour fonctionner en mode grappe; et des étapes consistant à: démarrer à partir du serveur, chaque équipements de traitement de données numériques que le serveur détecte inactif sur le premier système d'exploitation, au moyen d'un protocole d'amorçage réseau; charger à partir du serveur, le deuxième système d'exploitation en mémoire vive de chaque équipement de traitement de données numériques ainsi démarré.
La détection d'inactivité d'un équipement de traitement de données numériques pour être démarré à partir du serveur et le chargement du deuxième système d'exploitation uniquement en mémoire vive, ont pour effet technique, une utilisation transparente vis à vis de l'usage traditionnel des équipements de traitement de données numériques par l'absence d'impact qui en résulte sur le travail des utilisateurs individuels ou de l'administrateur du réseau. Le chargement à partir du serveur du deuxième système d'exploitation apporte une souplesse de configuration appréciable. Le fait de prendre des équipements de traitement de données numériques déjà reliés en réseau pour d'autre usage réduit les coûts de production de la grappe.
Particulièrement, le procédé comprend une étape consistant à préalablement configurer le deuxième système d'exploitation de. façon à ce qu'il ne comprenne aucun pilote d'accès à un premier système de stockage de masse qui est géré par le premier système d'exploitation.
Ainsi, l'absence par défaut de pilote d'accès au premier système de stockage de masse, seulement accessible au premier système d'exploitation, évite au deuxième système d'exploitation de corrompre le fonctionnement sur le premier système d'exploitation.
Particulièrement aussi, le procédé comprend une étape consistant à attribuer une adresse réseau privée au serveur et à chaque ordinateur de la grappe.
Ainsi, une adresse réseau privée par défaut entrave d'éventuelles tentatives d'intrusions extérieures au réseau.
Particulièrement encore, le procédé comprend une étape consistant à configurer le deuxième système d'exploitation avant chargement en mémoire vive de chaque ordinateur de façon à crypter chaque communication sur le réseau.
Ainsi, le chiffrement des communications sur le réseau, isole les équipements de traitement de données numériques d'un monde extérieur.
L'effet technique supplémentaire est sur un renforcement de sécurité des données locales à une entreprise ou à un domicile. D'autres moyens techniques équivalents pour empêcher par défaut toute communication avec d'autres machines sont par exemple des tables de filtrage à l'entrée du réseau qui n'autorise que des communications à des adresses préalablement répertoriées. Plus particulièrement, le serveur utilise un environnement de parallélisation de service de données agencé pour aiguiller sur le réseau, une requête de chargement de données en provenance d'un équipement de traitement de données numériques vers un démon qui retourne une réponse à la requête.
Le démon est par exemple un autre équipement de traitement de données numériques ou un autre serveur qui dispose des données à charger. Les données peuvent concerner tant des données de code exécutable que des données de valeurs numériques. L'effet technique supplémentaire est sur un passage à l'échelle (scaling en anglais) d'un grand nombre de postes de travail qui résulte de l'allégement de charge du serveur pour charger le deuxième système d'exploitation et aussi pour charger des applications à exécuter par les équipements de traitement de données numériques.
Plus particulièrement encore, le procédé comprend une étape consistant à redémarrer sur le premier système d'exploitation, tout ordinateur pour lequel le deuxième système d'exploitation détecte une intervention locale. Un deuxième objet de l'invention est un système informatique permettant un fonctionnement en grappe de traitement de données. Le système informatique est remarquable en ce qu'il comprend: un réseau d'équipements de traitement de données numériques qui sont habituellement prévus pour traiter chacun des données en étant actifs sur un premier système d'exploitation, le système d'interface matériel de chaque équipement de traitement de données numériques ayant une faculté d'amorçage réseau; un serveur relié au réseau comprenant un deuxième système d'exploitation qui est prévu pour fonctionner en mode grappe; et en ce que le serveur est agencé pour détecter au moins un équipement de traitement de données numériques inactif sur le premier système d'exploitation, pour démarrer au moyen d'un protocole d'amorçage réseau l'équipement de traitement de données numériques détecté inactif et pour charger le deuxième système d'exploitation en mémoire vive de l'équipement de traitement de données numériques ainsi démarré.
Particulièrement, dans le système informatique le deuxième système d'exploitation ne comprend aucun pilote d'accès à un premier système de stockage de masse qui est géré par le premier système d'exploitation.
Particulièrement aussi, le serveur et chaque équipement de traitement de données numériques du réseau possèdent une adresse réseau privée.
Particulièrement encore, le deuxième système d'exploitation comprend des moyens pour crypter chaque communication sur le réseau. Plus particulièrement, le deuxième système d'exploitation comprend un environnement de parallélisation agencé pour aiguiller une requête de chargement en provenance d'un équipement de traitement de données numériques, vers un démon qui retourne une réponse à la requête.
Les caractéristiques énoncées avec d'autres détails et avantages ressortent d'un exemple de mise en œuvre dont la description suit en référence aux dessins annexés dans lesquels:
- la figure 1 est un diagramme d'étapes de procédé de production conforme à l'invention;
- la figure 2 est un schéma de système informatique dans lequel est mise en œuvre l'invention;
- les figures 3, 4 et 5 sont des logigrammes de protocoles utiles dans le cadre de l'invention.
La figure 1 montre des étapes de procédé conforme à l'invention pour produire une grappe de traitement de données (cluster en anglais). On distingue d'une part des étapes préalables 16, 17, 18 pour préparer une configuration matérielle d'ordinateurs de façon à pouvoir faire fonctionner ces ordinateurs en mode grappe. On distingue d'autre part des étapes 26, 27, 28 pour produire temporairement une grappe au moyen de ces ordinateurs.
L'étape 16 consiste à prendre des ordinateurs standards agencés pour d'autres fonctionnement que celui en mode grappe.
La figure 2 montre plusieurs ordinateurs 1 , 2, 3 relié à un réseau privé 4, chacun respectivement au moyen d'un coupleur 14, 24, 34. Les ordinateurs 1 , 2, 3 sont des ordinateurs classiques tels que des micro-ordinateurs personnels qui comprennent chacun respectivement un micro-processeur 10, 20, 30, une mémoire re-programmable 12, 22, 32, une mémoire vive 11 , 21 , 31 , des coupleurs d'entrée- sortie 15, 25, 35 et une mémoire de masse 13, 23, 33.
La mémoire de masse 13, 23, 33 est par exemple un disque dur. Plus généralement, c'est un système de stockage de masse destiné à contenir des fichiers exécutables et des fichiers de données auxquels l'utilisateur de l'ordinateur peut accéder pour utiliser différentes applications
Les coupleurs d'entrée sortie 15, 25, 35 sont généralement raccordés pour chaque ordinateur à un clavier, à une souris, à un lecteur de disquette et à un écran non représentés sur la figure.
La mémoire re-programmable 12, 22, 32, contient un système d'interface matériel ( BIOS en abrégé pour Basic Input Output System) qui comprend différentes fonctions de bas niveau pour gérer physiquement les différents composants matériels de l'ordinateur. Certaines fonctions du BIOS sont généralement configurables telles que par exemple celles pour définir une séquence de démarrage de l'ordinateur, allumage de l'ordinateur à partir de l'interrupteur local de mise sous tension ou du coupleur réseau, environnement d'exécution préalable (PXE en abrégé pour Preboot eXecution Environment en anglais) qui permet d'exécuter un programme de lancement (Boot en anglais pour chausse-pied) de façon à charger et initialiser en mémoire vive, un système d'exploitation ( OS en abrégé pour Operating System en anglais) de l'ordinateur, à partir du réseau, du disque dur ou d'une disquette.
La mémoire vive 11 , 21 , 31 , se distingue de la mémoire de masse et de la mémoire re-programmable en ce qu'elle est réinitialisée à chaque redémarrage de l'ordinateur.
Le fonctionnement habituel des ordinateurs représentés en figure 1 , est celui de stations individuelles de travail. D'autres ordinateurs semblables non représentés, peuvent être reliés au réseau 4. Un premier système d'exploitation chargé en mémoire vive 11 , comprend des pilotes d'accès à un premier système de stockage de masse comprenant la mémoire de masse 13 et s'il est distribué, éventuellement tout ou partie des mémoires de masse 23, 33. Il en est de même pour les mémoires vives 21 , 31 respectivement des ordinateurs 21 , 31 et d'autres ordinateurs reliés au réseau 4. Ainsi, chaque utilisateur d'un ordinateur peut faire exécuter des applications résidentes sur le premier système de stockage de masse et communiquer avec d'autres utilisateurs d'autres ordinateurs au moyen du réseau 4.
Lorsque l'utilisateur de l'ordinateur 1 , 2, 3, n'utilise pas son ordinateur, celui- ci est inactif sur le premier système d'exploitation. Les ressources de traitement de données constituées par le processeur 10, 20, 30 et la mémoire vive 11 , 21 , 31 , sont alors disponibles. Ceci peut être le cas lorsque l'utilisateur éteint son ordinateur avant de quitter son lieu de travail ou lorsqu'il laisse son ordinateur en veille sans intervenir par le clavier ou la souris. Pour produire une grappe de traitement de données en exploitant cette disponibilité d'ordinateurs, l'étape 17 consiste à configurer le système d'interface matériel des ordinateurs que l'on veut pouvoir utiliser en mode grappe, avec une faculté d'amorçage réseau. Lorsque le système d'interface matériel des ordinateurs est déjà configuré avec cette faculté d'amorçage par le réseau pour des raisons autres que celles qui font l'objet de l'invention, il suffit de s'assurer que cette faculté est présente pour chaque coupleur réseau 14, 24, 34 de chaque ordinateur 1 , 2, 3. Cette faculté est par exemple procurée par enregistrement en mémoire reprogrammable 12, 22, 32, des fonctionnalités PXE qui émettent une requête DHCP (abréviation de Dynamic Host Configuration Protocol en anglais) prioritairement à une requête d'accès au secteur d'amorce d'un disque et capables d'utiliser le protocole TFTP (abréviation de Trivial File Transfer Protocol en anglais).
Le seul ajout matériel substantiel est dans l'étape 18 qui consiste à relier un serveur 5 au réseau 4. Le serveur 5 comprend un système d'exploitation différent de celui habituellement utilisé par les ordinateurs 1 , 2, 3 pour fonctionner individuellement en station de travail. Ce deuxième système d'exploitation est prévu pour un fonctionnement en mode grappe. Il est par exemple stocké sur un deuxième système de stockage de masse pour lequel le deuxième système d'exploitation comprend des pilotes d'accès. Dans une mise en œuvre préférée de l'invention, le deuxième système d'exploitation est l'OS connu Linux pour ses propriétés connues de système ouvert qui permettent d'intervenir jusque sur son noyau pour l'adapter à une utilisation ciblée telle que particulièrement ici, au mode de fonctionnement en grappe selon l'invention. Le deuxième système d'exploitation est configurable de telle façon que le niveau de sécurité le soit aussi. En termes de sécurité réseau, le deuxième système d'exploitation est par exemple configuré pour utiliser un adressage réseau privé, pour filtrer les accès réseau tant à destination du serveur que de chaque ordinateur alors considéré comme client, pour crypter les connexions, pour ne contenir aucun compte utilisateur individuel interactif ou encore pour n'autoriser aucun autre service que ceux fournis par le serveur 5.
Pour améliorer la sécurité des données propres à chaque utilisateur individuel d'un ordinateur, le deuxième système d'exploitation est configuré dans une étape 19, de façon à assurer un cloisonnement complet entre le mode utilisateur individuel et le mode de fonctionnement en grappe. Particulièrement, de façon à éviter les intrusions volontaires ou involontaires dans le premier système de stockage de masse utilisé par chaque ordinateur lorsqu'il fonctionne en mode utilisateur individuel, les pilotes d'accès au premier système de stockage de masse, sont supprimés dans le deuxième système d'exploitation. Ainsi, les mode de fonctionnement utilisateur individuel et en grappe disposent de systèmes de stockage de masse physiquement distincts.
On peut aussi améliorer la sécurité sur le réseau par attribution d'adresses privées aux ordinateurs et au serveur dans une étape 29 ou par imposition dans une étape 36 de crypter les communications sur le réseau 4. Pour exécution de l'étape 36, le deuxième système d'exploitation est agrémenté de moyens cryptographiques.
Un moyen équivalent à celui de l'étape 29 peut être procuré par une étape 50 dans laquelle on agence le serveur avec une table de filtrage qui référence les adresses réseau de chaque équipement à introduire dans la grappe de façon à ce que le serveur diffuse les adresses autorisées vers chaque équipement de la grappe pour limiter les communications sur le réseau à ces seuls équipements. On peut aussi paramétrer le micrologiciel des commutateurs du réseau de façon à verrouiller les ports de communication sur le réseau.
Le serveur 5 comprend aussi un fichier contenant une séquence de commandes (script dans le vocabulaire informatique courant) agencée pour démarrer chaque ordinateur sur lequel elle est téléchargée. La séquence comprend des commandes qui, lorsqu'elles sont exécutées par un ordinateur 1 , 2, 3, sur lequel elle est téléchargée, chargent le deuxième système d'exploitation en mémoire vive respective 11 , 21 , 31 , à partir du serveur 5. La séquence ne comprend aucune commande pour installer le deuxième système d'exploitation en mémoire de masse respective 13, 23, 33.
Plus généralement, le serveur 5 ne prévoit aucune installation de logiciel sur les ordinateurs individuels 1 , 2, 3 pour le fonctionnement en mode grappe. Ceci permet de minimiser l'impact du mode de fonctionnement en grappe sur le travail de l'administrateur et sur le travail de chaque utilisateur individuel.
Après que l'administrateur se soit assuré en phase préliminaire que le BIOS est configuré pour permettre un amorçage par le réseau 4 de chaque ordinateur une fois pour toutes en étape 16, l'administrateur n'a pas besoin d'assurer une maintenance, une mise à jour ou une désinstallation de logiciel sur les ordinateurs en tant que postes clients. L'administrateur n'a besoin de se préoccuper de reconfiguration que sur le serveur 5 sans avoir à intervenir individuellement sur chaque poste client, par exemple en cas de panne locale. Cette absence d'installation de logiciel sur les postes client, facilite considérablement le déploiement d'applications en mode grappe, les mises à jour et les suppressions.
Le serveur 5 permet un fonctionnement en mode grappe, transparent pour chaque utilisateur individuel. Tant le système d'exploitation que les logiciels applicatifs du mode grappe, étant limités à la seule mémoire vive 11 , 21 , 31 de chaque ordinateur 1 , 2, 3, chaque utilisateur individuel n'a besoin que de redémarrer sa machine en cas de panne de fonctionnement en mode grappe. Lorsque sa machine redémarre sur le premier système d'exploitation, l'utilisateur individuel ne voit aucune trace d'un fonctionnement en mode grappe.
Le serveur 5 est agencé pour centraliser le fonctionnement des ordinateurs individuels qui en mode grappe, se comportent comme des machines sans disque. On peut éventuellement prévoir sur chaque ordinateur, une partition de disque accessible uniquement par le deuxième système d'exploitation sans l'être par le premier système d'exploitation pour mettre en œuvre une fonctionnalité antémémoire (cache en anglais) mais cela n'est pas obligatoire. Un tel choix demande cependant à prendre certaines précautions à cause d'une perte de l'aspect sécurité fort qui est procuré par une absence totale d'accès disque dans l'ordinateur.
Dans ce mode centralisé de fonctionnement en grappe, il est prévu de faire accéder de nombreux ordinateurs aux données par l'intermédiaire du serveur 5 relié au réseau 4. Le nombre d'ordinateurs, généralement bien supérieur aux trois représentés sur la figure 2, peut poser des problèmes de passage à l'échelle (scalability en anglais). En fonctionnement sans disque local, le nombre de postes d'une grappe est limité par les performance du serveur. L'invention propose plusieurs solutions pour repousser ces limites. Des essais ont été effectués avec une grappe de 255 ordinateurs personnels.
Selon une première solution, on implémente dans le serveur 5, un environnement de parallélisation de traitement de requêtes en provenance de postes clients. Cet environnement comprend des fonctions pour mettre en œuvre au moins l'un des protocoles expliqués à présent en référence aux figures 3 à 5.
Le protocole expliqué en référence à la figure 3 convient pour tout type de requête de chargement de données. Il présente l'avantage d'être standard au niveau d'un poste client, émission requête, réception réponse. Il est particulièrement approprié pour mettre en œuvre un protocole imposé tel que par exemple NFS (abréviation de Network File System en anglais). Il est bien approprié aussi lorsque la source de la réponse n'est pas connue a priori au moment de l'émission de la requête.
Dans une étape 40, un client émet de façon connue une requête à destination d'un serveur avec en entête une adresse réseau source IPCι, une adresse réseau destination IPse, un port source PortCι, un port destination Portse.
Dans un serveur, une transition 41 validée par une réception de la requête émise par le client, active une étape 37. Le serveur traite les méta-données de la requête, c'est à dire par exemple pour une requête d'accès à un fichier, les données relatives aux informations de date et d'heure, propriétaire, permissions d'accès, taille du fichier, emplacement de stockage en mémoire, etc.
Dans l'étape 37, le serveur émet une requête à destination d'un démon. On appelle ici démon, une machine ou système disponible sur le réseau et qui possède les données pour répondre à la requête. Le serveur reporte le corps de la requête reçue du client dans le corps de la requête émise vers le démon avec en entête l'adresse réseau du démon IPde et le port du démon Portde comme adresse et port de destination. On sait que le port source est généralement librement choisi de façon aléatoire par un émetteur de requête. Par dérogation au principes généraux de transmission qui voudraient que ce soit l'adresse réseau du serveur qui figure à titre d'adresse source en entête de la requête émise à destination du démon, le serveur place en entête de sa requête, l'adresse réseau du client IPCι et le port client PortCι à titre d'adresse source et de port source.
Dans le démon, une transition 38 validée par une réception de la requête émise par le serveur, active une étape 39.
Dans l'étape 39, le démon émet une réponse avec en entête l'adresse réseau du client IPCι et le port du client PortCι comme adresse et port de destination. Par dérogation au principes généraux de transmission qui voudraient que ce soit l'adresse réseau du démon qui figure à titre d'adresse source en entête de la réponse émise à destination du client, le démon place en entête de sa réponse, l'adresse réseau du serveur IPse et le port serveur Portse à titre d'adresse source et de port source. Lorsque le serveur est unique, la connaissance de l'adresse et du port du serveur peut être implicite dans le démon. Pour permettre à plusieurs serveurs d'utiliser les services du démon, chaque serveur incorpore aussi son adresse réseau IPse et son port Portse dans le corps de requête en étape 37 de façon à les porter à la connaissance du démon pour activation de l'étape 39. Le service attendu du démon étant identique à celui attendu du serveur, le port Portse peut aussi simplement être identique au port Portde-
Dans le client, une transition 42 validée par une réception de la réponse émise par le démon, a le même effet que si elle était validée par une réception de réponse en provenance du serveur car on retrouve en entête l'adresse réseau IPse à titre d'adresse source, l'adresse réseau IPCι à titre d'adresse de destination, le port Portse à titre de port source et le port PortCι à titre de port de destination. On note que l'environnement de parallélisation n'apporte aucune modification au niveau du client qui continue à utiliser un protocole standard d'émission de requête et de réception de réponse. Les modifications essentielles se situent au niveau du serveur et du démon qui introduisent des adresses sources et des ports sources factices dans les émissions de messages (spoofing en anglais).
On observe que le protocole de parallélisation précédemment décrit, allège considérablement la charge du serveur en la répartissant sur un ou plusieurs démons.
Lorsque le client émet une requête d'accès en lecture avec un nom de fichier, le serveur se contente de lire les méta-données, de déterminer le démon qui gère les données à lire et de transférer cette requête au démon déterminé. Le serveur est alors rapidement disponible pour traiter une nouvelle requête. C'est le démon qui assure le transfert des données lues vers le client, transfert qui représente la charge la plus considérable de traitement de la requête. Lorsque le client émet une requête d'accès en écriture avec un nom de fichier, le serveur se contente de mettre à jour les méta-données, de déterminer le démon qui gère les données à écrire et de transférer cette requête au démon déterminé. Le serveur est alors rapidement disponible pour traiter une nouvelle requête. C'est le démon qui assure l'écriture des données, écriture qui représente la charge la plus considérable de traitement de la requête avec émission d'un acquittement au client en fin d'écriture.
Lorsque le client émet une requête d'accès en création ou en suppression avec un nom de fichier, le serveur se contente de mettre à jour les méta-données, de déterminer le démon qui gère le support physique de fichier à créer ou à supprimer et de transférer cette requête au démon déterminé. Le serveur est alors rapidement disponible pour traiter une nouvelle requête. C'est le démon qui assure la création ou la suppression de fichier sur le support physique, création ou suppression qui représente la charge la plus considérable de traitement de la requête. Les explications qui précèdent peuvent aussi s'appliquer à des accès à des structures de données (variables, tableaux ou autres) en mémoire vive comme nous le verrons par la suite.
Considérant les ordinateurs 1 , 2, 3 à titre de clients, aucune modification n'y est nécessaire pour mettre en œuvre l'environnement de parallélisation. Les clients n'ayant à connaître que le serveur 5 où sont mises en œuvre les particularités de cet environnement. Le ou les démons peuvent être une machine quelconque du réseau tel qu'un autre serveur ou tel qu'un autre ordinateur 2, 3 utilisant sa mémoire vive.
Les protocoles expliqués en référence aux figures 4 et 5, diffèrent de celui expliqué en référence à la figure 3 en ce que le démon répond à une requête émise par le client sans être passée par le serveur et s'identifie comme étant l'émetteur de la réponse sans se substituer au serveur. L'établissement d'un dialogue de communication directe entre le client et le démon, permet d'augmenter les performances de débit sur le réseau pour des requêtes subséquentes qui concernent un même démon identifié. Ces protocoles conviennent pour tout type de requête de chargement de données. Ils présentent l'avantage d'être standard au niveau d'un démon, émission requête, réception réponse. Le protocole expliqué en référence à la figure 4 est particulièrement approprié lorsqu'on peut choisir un protocole tel que par exemple PVFS (abréviation de Parallel Virtual File System en anglais). Ce protocole a été développé par l'université de Clemson et la NASA, pour des grappes de Stations de Travail de type connu sous le nom de Beowulf. Il est bien approprié aussi lorsque la source de la réponse n'est pas connue a priori au moment de l'émission de la requête.
Dans une étape 40, un client émet de façon connue une requête à destination d'un serveur avec en entête une adresse réseau source IPCι, une adresse réseau destination IPse, un port source PortCι, un port destination Portse- Dans un serveur, une transition 41 validée par une réception de la requête émise par le client, active une étape 43.
Dans l'étape 43, le serveur émet une commande de redirection à destination du client. Le serveur indique dans le corps de la commande de redirection, l'adresse réseau IPde et le port Portde du démon apte à renvoyer une réponse à la requête, avec en entête l'adresse réseau du serveur IPse et le port du serveur Portse comme adresse et port de source.
Dans le client, une transition 44 validée par la commande de redirection, active une étape 45.
Dans l'étape 45, le client émet la requête à destination du démon avec en entête l'adresse réseau source IPCι, une adresse réseau destination IPde, le port source PortCι, un port destination Portde.
Dans le démon, la transition 38 validée par une réception de la requête émise par le client en étape 45, active une étape 46.
Dans l'étape 46, le démon émet une réponse avec en entête l'adresse réseau du client IPCι et le port du client PortCι comme adresse et port de destination. Le démon place en entête de sa réponse, son adresse réseau IP e et son port Portde à titre d'adresse source et de port source. Dans le client, une transition 47 validée par une réception de la réponse émise par le démon, lui permet de poursuivre l'exécution du processus en cours.
En particulier les requêtes suivantes concernant des données pour lesquelles le démon est apte à fournir une réponse peuvent être adressées directement au démon sans repasser par le serveur.
Le protocole expliqué en référence à la figure 5 est particulièrement approprié lorsque la source de la réponse est connue par le serveur préalablement à l'émission de la requête par le client.
Dans l'étape 43, le serveur émet une commande de redirection à destination du client. Le serveur indique dans le corps de la commande de redirection, l'adresse réseau IPde et le port Portde du démon apte à renvoyer une réponse à une requête qu'il est prévue d'être émise par le client, avec en entête l'adresse réseau du serveur IPse et le port du serveur Portse comme adresse et port de source.
Dans le client, une transition 44 validée par la commande de rédirection, active une étape 45.
Dans l'étape 45, le client émet la requête à destination du démon avec en entête l'adresse réseau source IPCι, une adresse réseau destination IPde, le port source PortCι, un port destination Portde-
Dans le démon, la transition 38 validée par une réception de la requête émise par le client, active une étape 46.
Dans l'étape 46, le démon émet une réponse avec en entête l'adresse réseau du client IPC| et le port du client PortCι comme adresse et port de destination. Le démon place en entête de sa réponse, son adresse réseau IPde et son port Portde à titre d'adresse source et de port source. Dans le client, une transition 47 validée par une réception de la réponse émise par le démon, lui permet de poursuivre l'exécution du processus en cours. En particulier les requêtes suivantes concernant des données pour lesquelles le démon est apte à fournir une réponse peuvent être adressées directement au démon sans repasser par le serveur. Selon une deuxième solution, on réalise le serveur 5 sous forme distribuée de sous-serveurs affectés chacun à un sous-réseau du réseau 4. Chaque ensemble d'ordinateurs reliés à un même sous réseau ne connaît que le sous- serveur affecté à ce sous-réseau. Chaque sous-serveur peut alors disposer d'un deuxième système de stockage indépendant avec son ou ses démons.
La première et la deuxième solution peuvent aussi être combinées en considérant comme démon d'un sous-serveur affecté à un sous-réseau, un sous- serveur affecté à un autre sous-réseau.
L'exécution préalable des étapes 16 à 18 met maintenant à disposition une configuration matérielle propice à produire une grappe de traitement de données conformément à l'invention aussi souvent que certaines conditions sont remplies en exécutant des étapes 26 à 27. Ces conditions sont essentiellement qu'un nombre suffisant d'ordinateurs 1 , 2, 3 soient inactifs sur leur premier système d'exploitation habituel de façon à être disponibles pour produire une grappe de traitement de données. L'inactivité des ordinateurs résulte par exemple de leur extinction par leurs utilisateurs individuels en fin de journée de travail.
L'étape 26 est par exemple activée en dehors des horaires de travail des utilisateurs individuels ou à heure déterminée à laquelle on a demandé aux utilisateurs individuels d'éteindre leurs ordinateurs. Dans l'étape 26, le serveur 5 détecte les ordinateurs reliés au réseau qui sont inactifs sur le premier système d'exploitation. Ce sont par exemple les ordinateurs éteints ou de façon plus poussée les ordinateurs en veille sur lesquels aucune interaction n'a été engagée depuis un certain temps. Le serveur 5 démarre alors chaque ordinateur au moyen d'un protocole de type connu tel que "Wake on LAN" puis du protocole d'amorçage réseau mentionné précédemment dans l'environnement PXE. A son allumage par le réseau à partir du serveur 5, chaque ordinateur 1 , 2, 3, envoie une requête DHCP au serveur 5 qui retourne une réponse avec une adresse réseau privée IP pour l'ordinateur, un nom de programme de commandes exécutables par l'ordinateur et une option de téléchargement de séquence de commandes. L'ordinateur envoie alors de façon usuelle une requête dite GET sous TFTP pour charger en mémoire vive le programme de commandes exécutables. A réception du programme de commandes exécutables, l'ordinateur envoie une requête GET sous TFTP pour charger en mémoire vive, la séquence de commandes indiquée en option.
L'étape 27 utilise la séquence de commandes téléchargée pour charger le deuxième système d'exploitation en mémoire vive à partir du serveur 5. En particulier, la séquence de commandes une première commande "TFTP Get: Linux kernel" et une deuxième commande "TFTP Get: Linux data" où Linux désigne le deuxième système d'exploitation, kernel désigne le noyau du deuxième système d'exploitation et data désigne les données de configuration du deuxième système d'exploitation.
A titre illustratif, supposons que les ordinateurs sont démarrés par le serveur 5, dans un ordre ordinateur 1 , ordinateur 2, ordinateur 3 et ainsi de suite pour les ordinateurs suivants non représentés sur la figure 2.
En exécutant la première commande, l'ordinateur 1 génère une première requête à destination du serveur 5 qui retourne à l'ordinateur 1 , une première réponse contenant le noyau du deuxième système d'exploitation. Après avoir chargé le noyau du deuxième système d'exploitation en mémoire 11 , l'ordinateur 1 exécute la deuxième commande qui génère une deuxième requête à destination du serveur 5. Le serveur 5 retourne alors à l'ordinateur 1 , une deuxième réponse qui contient les données de configuration du deuxième système d'exploitation.
L'ordinateur 2 puis l'ordinateur 3, exécutent de même successivement la première et la deuxième commande pour aboutir au même résultat que celui de l'ordinateur 1.
Avantageusement, les données de configuration du deuxième système d'exploitation comprennent l'environnement de parallélisation précédemment expliqué en référence à l'une des figures 3 à 5 avec particulièrement les paramètres du protocole de parallélisation permettant de donner aussi un comportement de démon.
Le serveur 5 répertorie le dernier ordinateur auquel il a envoyé une deuxième réponse et considère ce dernier ordinateur, dit alors ordinateur précédent, comme démon pour mettre en œuvre le protocole précédemment expliqué en référence à l'une des figures 3 à 5. Le protocole expliqué en référence à la figure 5 est bien adapté car c'est le serveur qui détermine le démon pour le chargement du système d'exploitation dans l'ordinateur suivant. Tant que le serveur 5 n'a pas envoyé de deuxième réponse à un ordinateur précédent, il se charge de transmettre toute réponse à toute requête reçue d'un ordinateur. Après avoir envoyé une deuxième réponse à un ordinateur précédent, différentes variantes sont possibles selon le protocole de l'environnement de parallélisation mis en œuvre.
Dans une variante où le protocole est celui de la figure 3, le serveur 5 retransmet toute première requête et toute deuxième requête en provenance d'un ordinateur courant, à l'ordinateur précédent qui agit alors comme le démon de la figure 3 pour envoyer une première et ou une deuxième réponse à l'ordinateur courant.
Lorsque le serveur 5 reçoit la première requête en provenance de l'ordinateur 2, il aiguille cette requête vers le dernier ordinateur répertorié pour appliquer le protocole précédemment expliqué en référence à la figure 3. Si aucun ordinateur n'est répertorié, le serveur 5 envoie lui même la première réponse à l'ordinateur 2. Si l'ordinateur 1 est répertorié, le serveur 5 aiguille la première requête vers l'ordinateur 1 qui envoie la première réponse à l'ordinateur 2 conformément au protocole précédemment expliqué en. référence à la figure 3. Lorsque le serveur 5 reçoit la deuxième requête en provenance de l'ordinateur 2, l'ordinateur 1 étant répertorié, le serveur 5 aiguille la deuxième requête vers l'ordinateur 1 qui envoie la deuxième réponse à l'ordinateur 2 conformément au protocole précédemment expliqué en référence à la figure 3.
Lorsque le serveur 5 reçoit la première requête en provenance de l'ordinateur 3, il aiguille cette requête vers le dernier ordinateur répertorié pour appliquer le protocole précédemment expliqué en référence à la figure 3. Si l'ordinateur 1 est celui répertorié, le serveur 5 aiguille la première requête vers l'ordinateur 1 qui envoie la première réponse à l'ordinateur 3 conformément au protocole précédemment expliqué en référence à la figure 3. Si l'ordinateur 2 est répertorié, le serveur 5 aiguille la première requête vers l'ordinateur 2 qui envoie la première réponse à l'ordinateur 3 conformément au protocole précédemment expliqué en référence à la figure 3. Lorsque le serveur 5 reçoit la deuxième requête en provenance de l'ordinateur 3, l'ordinateur 2 étant répertorié, le serveur 5 aiguille la deuxième requête vers l'ordinateur 2 qui envoie la deuxième réponse à l'ordinateur 3 conformément au protocole précédemment expliqué en référence à la figure 3.
Dans une variante où le protocole est celui de la figure 4, le serveur 5 renvoie une commande de redirection à toute première requête en provenance d'un ordinateur courant. La commande adressée à l'ordinateur courant, est de redirection vers l'ordinateur précédent qui agit alors comme le démon de la figure 4 pour envoyer une première et ou une deuxième réponse à l'ordinateur courant.
Dans une variante préférée où le protocole est celui de la figure 5, le serveur 5 envoie une commande de redirection dès qu'il entre en relation avec un ordinateur suivant considéré comme ordinateur courant. La commande adressée à l'ordinateur courant, est de redirection vers l'ordinateur précédent qui agit alors comme le démon de la figure 5 pour envoyer une première et ou une deuxième réponse à l'ordinateur courant. Le processus de chargement du deuxième système d'exploitation qui vient d'être expliqué pour les ordinateurs 1 , 2, 3, se poursuit de même pour les ordinateurs suivants. On observe ainsi un chargement en pipeline des composants du système d'exploitation. Les ordinateurs travaillant uniquement sur leur mémoire virtuelle, les réponse de démon sont effectuées à partir de la mémoire virtuelle. Lorsqu'on utilise un système de fichier réparti de type connu NFS, on nomme NFSp l'environnement précédemment expliqué en référence à la figure 3. Le chargement des fichiers à partir du serveur 5 sur les ordinateurs individuels reste standard coté ordinateur individuel considéré en tant que client. Le noyau connu NFSROOT reste donc applicable sans modification. On peut aussi prévoir dans la séquence de commandes téléchargée, une commande pour créer un disque virtuel en mémoire vive. Le disque virtuel disparaîtra au redémarrage de l'ordinateur individuel sans laisser de trace. Le stockage du deuxième système d'exploitation sur le disque virtuel permet alors à l'ordinateur d'utiliser l'environnement NFSp pour être utilisé en tant que démon. L'environnement NFSp offre un service de fichier qui permet de passer à l'échelle sur plusieurs centaines de clients.
L'environnement NFSp comprend avantageusement des fonctionnalités connues de gestion de système de stockage de grande capacité à grande sûreté (RAID en abrégé pour Redundant Array of Inexpensive Disks en anglais). Ceci permet de supporter des pannes de sous-serveur lorsque le serveur 5 est réparti, y compris dans les ordinateurs individuels.
Lorsqu'une entreprise possède déjà un matériel performant de type SCSI ou SAN (abréviation de Storage Area Network en anglais) pour accéder à un disque distant, le deuxième système de stockage de données peut aussi avantageusement utiliser la technologie connue iSCSI comme alternative à l'environnement NFSp. Le démon peut alors être de type SCSI ou SAN.
L'avantage de l'environnement NFSp est qu'il ne nécessite pas d'investissement coûteux dans un matériel performant tel que celui qui vient d'être mentionné.
L'étape 28 est celle qui fait sortir les ordinateurs individuels du mode de fonctionnement en grappe. L'étape 28 est soit activée à heure déterminée, par exemple en fin de nuit pour permettre aux ordinateurs individuels de reprendre leurs fonctionnalités de station de travail dans la journée, soit activée sur détection d'une intervention humaine par le clavier, la souris ou le bouton local de démarrage de l'ordinateur. Dans l'étape 28, la mémoire vive de l'ordinateur est réinitialisée, éventuellement par arrêt de l'ordinateur, de façon à en purger le deuxième système d'exploitation et les données et ou programmes liés au fonctionnement en mode grappe. Un ordinateur individuel est alors à nouveau disponible pour fonctionner sur son premier système d'exploitation. L'étape 28 est re-bouclée en attente d'exécution de l'étape 26 pour une éventuelle production de grappe ultérieure.
Entre l'étape 27 et l'étape 28, la grappe produite par le procédé selon l'invention, permet un traitement de données qui demande beaucoup de ressources de calcul grâce à une répartition de fâches entre les différents ordinateurs de la grappe. Bien que le serveur centralise le fonctionnement de la grappe, il ne constitue pas un goulot d'étranglement sur le réseau grâce à la mise en œuvre du protocole de la figure 3 ou 4 pour tout chargement de données applicatives dans un ordinateur de la grappe en cours de fonctionnement sur le deuxième système d'exploitation chargé quant à lui, preferentiellement mais non nécessairement par mise en œuvre du protocole de la figure 5.
L'exemple de grappe décrit ci dessus à titre illustratif concerne des ordinateurs personnels mais on comprend que tout équipement de traitement de données pouvant charger un système d'exploitation à partir d'un réseau, convient pour une création de grappe virtuelle. On pense par exemple à divers périphériques informatiques tels que des imprimantes ou à des automates programmables en domotique ou en conduite de processus industriel. La facilité de chargement d'un deuxième système d'exploitation pour fonctionner en mode grappe, procuré par l'invention, permet de bénéficier d'équipements existants de façon particulièrement souple lorsque ceux-ci sont disponibles pendant qu'ils ne sont pas appelés à fonctionner dans un mode pour lequel ils sont normalement prévus, et ceci sans nuire à ce mode habituel de fonctionnement. Un équipement est disponible tant pendant une période d'arrêt que pendant une période dite d'hibernation comme le mode de veille dans laquelle il est inactif sur son premier système d'exploitation habituel. Le mode pipeline de chargement du deuxième système d'exploitation permet une mise à l'échelle aisée en ce qu'il ne limite pas le nombre d'équipements à introduire dans la grappe.

Claims

REVENDICATIONS:
1. Procédé pour produire une grappe de traitement de données, caractérisé en ce qu'il comprend: des étapes consistant à préalablement: prendre des équipements de traitement de données numériques (1 ,2,3) qui sont reliés en réseau et qui sont habituellement prévus pour traiter chacun des données en étant actifs sur un premier système d'exploitation lancé à partir d'un système d'interface matériel; - configurer le système d'interface matériel de chaque équipements de traitement de données numériques avec une faculté d'amorçage réseau; relier au dit réseau (4), au moins un serveur (5) comprenant un deuxième système d'exploitation qui est prévu pour fonctionner en mode grappe; et des étapes consistant à: - démarrer à partir du serveur (5), chaque équipements de traitement de données numériques que le serveur détecte inactif sur le premier système d'exploitation, au moyen d'un protocole d'amorçage réseau; charger à partir du serveur (5), le deuxième système d'exploitation en mémoire vive de chaque équipements de traitement de données numériques ainsi démarré.
2. Procédé selon la revendication 1 , caractérisé en ce qu'il comprend une étape (19) consistant à préalablement configurer le deuxième système d'exploitation de façon à ce qu'il ne comprenne aucun pilote d'accès à un premier système de stockage de masse (13,23,33) qui est géré par le premier système d'exploitation.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comprend une étape (29) consistant à attribuer une adresse réseau privée au serveur et à chaque équipements de traitement de données numériques de la grappe.
4. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une étape (36) consistant à configurer le deuxième système d'exploitation avant chargement en mémoire vive de chaque équipements de traitement de données numériques de façon à crypter chaque communication sur le réseau.
5. Procédé selon l'une des revendications précédentes, caractérisé en ce que, pour charger le deuxième système d'exploitation dans chaque équipements de traitement de données numériques, le serveur utilise un environnement de parallélisation agencé pour aiguiller une requête de chargement en provenance d'un ordinateur vers un démon qui retourne une réponse à la requête.
6. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une étape (28) consistant à redémarrer sur le premier système d'exploitation, tout équipements de traitement de données numériques pour lequel le deuxième système d'exploitation détecte une intervention locale.
7. Système informatique permettant un fonctionnement en grappe de traitement de données, caractérisé en ce qu'il comprend: un réseau (4) d'équipements de traitement de données numériques (1 ,2,3) qui sont habituellement prévus pour traiter chacun des données en étant actifs sur un premier système d'exploitation, le système d'interface matériel de chaque équipement de traitement de données numériques ayant une faculté d'amorçage réseau; un serveur (5) relié au réseau (4) comprenant un deuxième système d'exploitation qui est prévu pour fonctionner en mode grappe; et en ce que le serveur (5) est agencé pour détecter au moins un équipements de traitement de données numériques (1 ,2,3) inactif sur le premier système d'exploitation, pour démarrer au moyen d'un protocole d'amorçage réseau l'équipement de traitement de données numériques (1 ,2,3) détecté inactif et pour charger le deuxième système d'exploitation en mémoire vive (11 ,21 ,31) de l'équipement de traitement de données numériques ainsi démarré.
8. Système informatique selon la revendication 7, caractérisé en ce que le deuxième système d'exploitation ne comprend aucun pilote d'accès à un premier système de stockage de masse (13,23,33) qui est géré par le premier système d'exploitation.
9. Système informatique selon la revendication 7 ou 8, caractérisé en ce que le serveur (5) et chaque équipement de traitement de données numériques (1 ,2,3) du réseau (4) possèdent une adresse réseau privée.
10. Système informatique selon l'une des revendications 7 à 9, caractérisé en ce que le deuxième système d'exploitation comprend des moyens pour crypter chaque communication sur le réseau (4).
11. Système informatique selon l'une des revendications 7 à 10, caractérisé en ce que le deuxième système d'exploitation comprend un environnement de parallélisation agencé pour aiguiller une requête de chargement en provenance d'un équipement de traitement de données numériques (2), vers un démon (1 ) qui retourne une réponse à la requête.
PCT/FR2004/000426 2003-02-18 2004-02-17 Procede de production d’une grappe de traitement de donnees et systeme informatique pour fonctionner en grappe WO2004074959A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0301975A FR2851351A1 (fr) 2003-02-18 2003-02-18 Procede de production d'une grappe de traitement de donnees et systeme informatique pour fonctionner en grappe
FR03/01975 2003-02-18

Publications (2)

Publication Number Publication Date
WO2004074959A2 true WO2004074959A2 (fr) 2004-09-02
WO2004074959A3 WO2004074959A3 (fr) 2005-04-14

Family

ID=32749658

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/000426 WO2004074959A2 (fr) 2003-02-18 2004-02-17 Procede de production d’une grappe de traitement de donnees et systeme informatique pour fonctionner en grappe

Country Status (2)

Country Link
FR (1) FR2851351A1 (fr)
WO (1) WO2004074959A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012040606A3 (fr) * 2010-09-23 2012-05-10 Intel Corporation Informatique en grappe - mise en place d'un os basé sur une nic
CN111507649A (zh) * 2020-06-30 2020-08-07 南昌木本医疗科技有限公司 一种基于区块链的金融大数据风控平台

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CHANCE RESCHKE <RESCHKEÐASTRO.WASHINGTON.EDU>: "Re: Remote reboot of Windows NT ?" PUBLIC MAILING LIST ARCHIVE, [Online] 4 August 1998 (1998-08-04), XP002257690 beowulfÐbeowulf.org Retrieved from the Internet: URL:http://www.beowulf.org/listarchives/be owulf/1998/08/0007.html> [retrieved on 2003-10-09] *
FLATFISH+++ <FLATFISHÐNOWHERE.SOMEWHERE: "RedHat 7.1 Review" NEWSGROUP MESSAGE, [Online] 10 August 2001 (2001-08-10), XP002257691 Retrieved from the Internet: URL:http://groups.google.com/groups?selm=2 77unt8fihpmdcj4evp6j3vfastgtli2a2%404ax.co m&oe=utf-8&output=gplain> [retrieved on 2003-10-13] *
JUSTIN MOORE, JEFF CHASE: "Cluster On Demand" TECHNICAL REPORT, [Online] May 2002 (2002-05), XP002257693 Durham, Caroline du Nord, États-Unis d'Amérique Retrieved from the Internet: URL:http://www.cs.duke.edu/~justin/cod/CS- 2002-07.ps> [retrieved on 2003-10-13] *
MICHAEL STEIN <MASÐUCLA.EDU>: "Re: flopies boot disks" PUBLIC MAILING LIST ARCHIVE, [Online] 19 March 1999 (1999-03-19), XP002257692 Retrieved from the Internet: URL:http://www.beowulf.org/listarchives/be owulf/1999/03/0180.html> [retrieved on 2003-10-13] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012040606A3 (fr) * 2010-09-23 2012-05-10 Intel Corporation Informatique en grappe - mise en place d'un os basé sur une nic
US8688812B2 (en) 2010-09-23 2014-04-01 Intel Corporation Cluster computing—NIC based OS provision
CN111507649A (zh) * 2020-06-30 2020-08-07 南昌木本医疗科技有限公司 一种基于区块链的金融大数据风控平台

Also Published As

Publication number Publication date
WO2004074959A3 (fr) 2005-04-14
FR2851351A1 (fr) 2004-08-20

Similar Documents

Publication Publication Date Title
US8688965B2 (en) System and method for increasing platform network boot efficiency
EP2727001B1 (fr) Passerelle de stockage de réplication
US9886257B1 (en) Methods and apparatus for remotely updating executing processes
EP2726975B1 (fr) Processus d&#39;activation de passerelle de stockage
US9497295B2 (en) Redistribution of operating environments for the redeployment of grid clients
US9176744B2 (en) Quickly provisioning a virtual machine by identifying a path to a differential file during pre-boot
US6954852B2 (en) System for and method of network booting of an operating system to a client computer using hibernation
US20120239729A1 (en) Methods and apparatus for connecting a thin client to a virtual desktop
EP2449751B1 (fr) Procédé de démarrage d&#39;un dispositif informatique dans un réseau, serveur et réseau de dispositifs informatiques pour sa mise en oeuvre
JP2009544072A (ja) アプライアンスの仮想化のための方法と装置
TW200834421A (en) Instant-on platform
JP2002123400A (ja) 転送方法、システム、コンピュータ可読媒体及びプログラム
KR101730291B1 (ko) 디스크 배신 시스템
WO2008107438A1 (fr) Procede pour executer un programme relatif a plusieurs services, systeme et dispositif electroniques correspondants
US9026627B2 (en) Method and system for switching between remote console sessions
WO2007096554A2 (fr) Procede et dispositif de configuration securisee d&#39;un terminal
FR3013866A1 (fr) Procede, programme d&#39;ordinateur et dispositif de configuration ou de maintenance d&#39;un systeme informatique dans un cluster
WO2017153302A1 (fr) Procede de gestion memoire au sein d&#39;un ensemble de dispositifs de traitement de l&#39;information
WO2004074959A2 (fr) Procede de production d’une grappe de traitement de donnees et systeme informatique pour fonctionner en grappe
US20050125648A1 (en) System for establishing hardware-based remote console sessions and software-based remote console sessions
EP1728164B1 (fr) Procede pour l&#39;emulation logicielle de disques durs d&#39;une plate-forme informatique au niveau du systeme d&#39;exploitation avec gestion parametrable a la volee des requetes d&#39;ecriture et de lecture
JP2005523514A (ja) データをネットワーク上のコンピューターにストリームするためのシステム及び方法
CN111679838A (zh) 镜像上传下发的方法及装置
FR2906958A1 (fr) Connexion d&#39;un terminal a un serveur distant.

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase