WO2008053098A2 - Systeme informatique ameliore comprenant plusieurs noeuds en reseau - Google Patents
Systeme informatique ameliore comprenant plusieurs noeuds en reseau Download PDFInfo
- Publication number
- WO2008053098A2 WO2008053098A2 PCT/FR2007/001765 FR2007001765W WO2008053098A2 WO 2008053098 A2 WO2008053098 A2 WO 2008053098A2 FR 2007001765 W FR2007001765 W FR 2007001765W WO 2008053098 A2 WO2008053098 A2 WO 2008053098A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- storage
- queue
- rule
- request
- access
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
Definitions
- Improved computer system comprising a plurality of networked nodes
- the invention relates to computer systems comprising several computer stations called nodes interconnected in a network.
- Modern networks include user stations that are connected to one or more servers and can share applications and / or storage spaces locally or remotely.
- the invention improves the situation.
- the invention proposes a computer system comprising several computer stations called nodes interconnected in a network. At least some of the nodes, known as storage nodes, comprise at least one local random access memory unit, and a storage server arranged to manage access to this local memory unit on the basis of a request queue. access.
- a file system manager arranged to maintain a representation of files accessible from this node in the form of virtual addresses
- a correspondence module capable of maintaining a correspondence between each virtual address and at least one physical address on a local memory unit of a storing node
- a storage client capable of interacting with any of the storage servers, based on an access request designating a physical address.
- At least one of the storage servers comprises a scheduler able to execute the access requests contained in its queue in a determined order, and in that the scheduler is arranged to determine this order according to a set of rules forming performance criteria, and involving one or more state parameters of the queue and / or the storing node on which it resides.
- Such a computer system has the advantage of using the intrinsic storage resources of the stations (which will also be called nodes) of the network in order to effectively store the data.
- the storage server can be used to optimize the use of the network and storage resources. This system thus makes it possible to make maximum use of the intrinsic capacities of the network without using specialized systems.
- the invention also relates to a data management method, applicable in a network comprising several interconnected computer stations, called nodes, comprising the following steps: at. issue a file request from an application node of the network, on the basis of a representation in the form of virtual addresses,
- FIG. 1 shows a general functional view of a computer system according to the invention
- FIG. 2 shows an example of a logical implementation of the system of FIG. 1,
- FIG. 3 shows an exemplary composition of an element of FIG.
- FIG. 4 shows a method of accessing a file in the system of FIG. 1
- FIG. 5 shows an example of a functional implementation of part of the process of FIG. 4,
- FIG. 6 shows an example of a scheduling and execution loop in a storage server as part of the implementation of FIG. 5,
- FIGS. 7 to 10 show examples of functions of FIG. 6,
- FIG. 11 shows an example of a scheduling and execution loop in an alternative storage server
- FIG. 12 shows an example of a function of FIG. 11,
- FIGS. 13 to 15 show examples of functions of FIG. 12.
- FIG. 1 represents a general diagram of a computer system according to the invention.
- an application environment 2 has access to a file system manager 4.
- a virtualization layer 6 establishes the correspondence between the file system manager 4 and storage servers 8.
- FIG. 2 represents a logical implementation of the system of FIG. 1.
- a set of stations 10, also referred to herein as nodes, are interconnected in a network of which they constitute the physical and application resources.
- the network consists of 5 stations, denoted Ni with i varying between 1 and 5.
- the application environment 2 is made of a distributed application layer 12 on the N1, N2 and N3, in one application layer 14 on the N4 and an application layer 16 on the N5.
- the file system manager 4 is produced in a distributed file system 18, and two non-distributed file systems 20 and 22.
- the system 18 is distributed over the N1, N2 and N3 and defines all the files accessible from the distributed application layer 12.
- the file systems 20 and 22 respectively define the set of files accessible from the application layers 14 and 16.
- the files designated by the file systems 18, 20 and 22 are physically stored in a virtual storage space 24 which is distributed over the set of Ni with i varying between 1 and 5.
- the virtual storage space 24 is here distributed in a shared logical space 26, and two private logical spaces 28 and 30.
- the shared logical space 26 corresponds to the space accessible from the distributed application layer 12 by means of the distributed file system 18, and the private logical spaces 28 and 30 to the space accessible from the application layers 14 and 16 by means of the file systems 20 and 22.
- the logical space 26 is distributed over the N1, N2 and N3, the private logical space 28 on the N3 and N4, and the private logical space 30 on the N5.
- an application of the layer 12 "sees” the data stored in the logical space 26 (respectively 28, 30) by means of the file system 18 (respectively 20, 22), although these they are not necessarily physically present on one of the storage disks of the station 10 that uses this application.
- the spaces 26, 28 and 30 are purely logical, that is, they do not directly represent physical storage spaces. Logical spaces are mapped using virtual addresses that are referenced or contained in file systems 18, 20, and 22.
- the correspondence module contains a table of correspondence between the virtual addresses of the data in the logical spaces and physical addresses that designate the physical storage spaces in which these data are actually stored.
- each station is used for both the application layer and the storage layer.
- This multifunctionality makes it possible to use the free space on all the stations of the network, rather than leaving this space unoccupied.
- any station can play an application node role, a storage node role, or both these roles at once.
- All the application, storage and file system resources can be integrated locally on each station, or distributed on the stations of the network.
- N1, N2 and N3 stations This is for example the case of N1, N2 and N3 stations, whose resources are fully distributed, both at the application level and at the level of the file system and storage.
- FIG. 3 represents an exemplary architecture of a station 10 of FIG. 2.
- the station represented in this example can represent one of the stations N1, N2 or N3.
- Station Nx individually has a structure similar to that of the global structure shown in Figure 1. It thus comprises an application layer 32, a file system 34, a virtualization layer 36 and a storage space 38 in the form of a local memory with direct access.
- the virtualization layer 36 comprises a motor 40 and a correspondence table 42.
- the direct access to the storage space 38 is managed by a storage client 44 and a storage server 46. The roles and operations of these elements will be specified below.
- the example described here represents an improved embodiment of the invention, in which all the resources, both application and storage, are distributed over the network.
- management module 48 It is the same for the virtualization layer 36, the storage client 44 and the storage server 46.
- the distribution of these elements is managed by means of a management module 48.
- the administration module 48 is mainly used during the creation and updating of the logical spaces.
- the administration module 48 calls the virtualization layer 36 to create the correspondence table between each virtual address of the logical space and a physical address on a storage node given.
- the virtualization layer distributes the data on the heterogeneous storage resources to find the best compromise between the exploitation of the flow of the storage resources of the network, and the exploitation of the storage capacity of these resources.
- An example of this virtualization layer is described in paragraphs [0046] to [0062] of EP 1 454 269 B1.
- the virtualization layer 36 may also incorporate a mechanism for backing up the written data. This mechanism can for example be based on a selective duplication of each write request with physical addresses located on physical storage spaces located on separate stations, in the manner of a RAID.
- the lookup table 42 is not necessarily a simple table. In particular, it can contain configuration information concerning the logical space or spaces for which it maintains the correspondences. In this case, it can inter alia interact with mechanisms of the virtualization layer 36 which to update the distribution of the virtual addresses / physical addresses to ensure the best compromise between the exploitation of the network storage resource rate , and exploiting the storage capacity of these resources.
- An exemplary embodiment of these mechanisms is described in paragraphs [0063] to [0075] of patent EP 1 454 269 B1.
- Figure 4 shows a method implemented by the system to access a file.
- the access to a file by an application of the application layer of a given node is initialized by a file access request 50.
- the file access request 50 comprises:
- the size of the request that is to say the number of bits to be accessed after the address of the targeted file
- the file system determines one or more virtual addresses for the data of this file, and generates one or more virtual access requests based on the request 50 and these virtual addresses.
- Virtual access requests each include:
- the size of the request that is to say the number of bits to be accessed following the targeted virtual address
- step 52 consists of determining the logical space and the virtual address (es) on this space designated by the request 50, and producing one or more "virtual" requests. .
- a file access request will target the content of a large quantity of virtual addresses, to enable the content of a file to be reconstructed, whereas a virtual request targets the contents of a data block. associated with this address.
- the resulting virtual access request (s) are then transmitted to the virtualization layer, which determines the physical address (es) and the corresponding storage spaces in a step 54.
- the virtualization layer operates using the virtualization layer. motor 40 and correspondence table 42.
- the searched file already exists in a storage space 38, and the engine 40 calls the correspondence table 42 with the virtual address or addresses to determine by correspondence the physical address or addresses. data from the file.
- the file does not necessarily exist beforehand in a storage space 38. Nevertheless, as we have seen above, the correspondences between virtual addresses and physical addresses are frozen, and the motor 40 therefore operates in the same way as in the context of a read request to determine the physical address or addresses of the data.
- the engine 40 once the engine 40 has determined the physical addresses, it generates in a step 56 physical access requests that it transmits to the storage client 44.
- step 56 the physical access requests are generated based on the request 50 and the physical address (es) determined in step 54.
- the size of the request that is to say the number of bits to be accessed following the physical address targeted by the request
- the physical address and the size of the request are obtained directly from step 54, and the type of the request is inherited from the type of the virtual access request concerned.
- a loop is then started, in which a stopping condition 58 is reached when a physical access request has been sent to the storage client 44 for all physical addresses obtained in step 52.
- each physical access request is placed in a request queue of the storage client 44 for execution in a step 60.
- the storage client 44 may optionally include several queues, for example a queue of data storage requests. wait by storage server 46 with which it interacts.
- step 56 all physical access requests in step 56 are represented as successively performed for simplicity. However, the execution can also be performed in parallel, and not only in series.
- requests are transmitted from layer to layer, up to the physical access layer.
- the storage client 44 interacts with the storage server 46 of the storage station that contains the storage space 38 on which the physical address designated by the storage address 38 is located. the physical access request concerned. This interaction will be specified using Figure 5.
- the execution of a physical access request by a storage client 44 firstly comprises the reception of the physical access request by the storage server 46 in question.
- This reception is here performed in the form of sending a header or "header" 62 which indicates to the storage server 46 the type of request, the size of this request, and the physical address that are targeted.
- the request via its header is then stored in a queue 64 of the storage server 46.
- the queue 64 includes all the access requests not yet executed sent by all the storage clients. 44 to the storage server 46 in question, and their execution status.
- a storage server 46 may comprise several queues 64, for example a queue for each storage client 44 of the network, or a queue for each storage space whose storage server 46 manages the storage. access, or any other arrangement useful for the implementation of the scheduling strategies which will be described below.
- the storage server 46 can thus receive in cascade a large quantity of requests from one or more storage clients and execute them in the most favorable order for the occupation of the station on which it is executing. occupation of the disks it manages, and network occupation in general.
- the customer relationship of storage / storage server is said to be "customer-oriented". In this type of relationship, it is the queuing queue of the storage client 44 that prevails, and the client is only allowed to send a new access request to a server when it has responded to the request. the previous request.
- the architecture described here is a "server orientation" for managing access to storage space. Contrary to what is known, a given storage client 44 can thus send a multitude of access requests to the same storage server 46, without it having to return the result of a request first. previously issued by the storage client 44. This makes it possible to better balance the disk and network load in the input / output ports and is particularly advantageous.
- the storage server 46 performs a step 66 in a loop in which it orders and executes the requests received in the queue.
- the request corresponding to the header 62 is therefore processed in this loop, in the order determined by the storage server.
- step 66 the server executes a scheduling of requests in the queue 64, in order to locally optimize the use of the storage spaces which it manages access as well as the use of the station on which it Executes by taking into account parameters such as processor load, station memory usage, etc.
- the storage server 46 has in its queue a set of requests that can take various states. These states can be for example “to be processed” (when a request has just been received in the queue), "pending execution” (when the storage server 46 has all the data necessary to execute a request and programmed its execution at a later time), or "running".
- a first nature is called “network”, and refers to an exchange that must be performed between the storage server 46 and a given storage client 44.
- the other nature is called “disk” and refers to an access that must be made by the storage server 46 on one of the storage spaces that it manages, to read or write data.
- step 66 The scheduling of step 66 is performed based on the nature of these queries and their status, system network state parameters, and storage space state parameters managed by the storage server. , as well as the use of the station on which it runs by taking into account parameters such as the processor load, the occupancy of the central memory of the station, etc.
- step 66 The description of step 66 will be made in the case where the storage server manages multiple data storage disks. As a result, many elements that are global in nature with respect to the loop are tables, possibly multidimensional.
- Last_Sect array which has a single line, and each column refers to the last sector accessed for the disk corresponding to this column.
- a matrix Tm_Used will be used, in which the lines each designate a storage client, and the columns each a disk, the values of the elements at the intersection of the line x and the column y representing the time of storage. disk occupation y for queries issued by the client x.
- the loop of step 66 processes data 70.
- Data 70 contains a list of requests File and a list of requests List_Req.
- the list of Queries File contains a set of queries with a status "to process", that is to say the queries received instantly in the queue or queues of the storage server.
- the List_Req list contains a set of queries that have a status of "pending" or "running". These queries are each accompanied by an age indicator.
- the age indicator of a query indicates the number of loops that have been traversed since this query was added to the List_Req list.
- a step 72 the storage server calls an lnit () function with the argument File and List_Req.
- the InitQ function is described further with Figure 7.
- the function lnit () starts in a step 700, with in a step 702 the call of an Add_New_Req () function whose arguments are the lists File and List_Req.
- the Add_New_Req () function is to take all the new queries from the File list and add them to the List_Req list.
- the age indicator for new queries is initialized to 0 by the Add_New_Req () function.
- Step 702 is followed by a dual condition relating to the occupation of the storage server, in order to optimize the operation of the system.
- the first condition is tested in a step 704, in which a wait flag Stat_Wt is tested.
- the lnit () function continues in a step 708 in which the flag Stat_Wt is set to 0 for the next loop.
- the storage server tests whether the List List Req is empty. If it is not, the lnit () function ends in step 712, and the scheduling loop can be extended to process the requests in the List_Req list.
- the storage server If the List Req list is empty, then there is no need to continue the scheduling loop, and the storage server expects a millisecond by a Wait (1) function in a step 714, and then sets the Stat_Wt flag at 1 for the next loop and resumes at step 702, to recover any new requests received by the queue or queues of the storage server.
- the storage server calls a Run_Old () function in a step 76.
- This function is intended to execute List_Req queries that have a very high age indicator.
- Run_Old () is described by means of FIG. 8, and returns an indicator Rst equal to 1 if an aged request is executed, and equal to 0 otherwise.
- the storage server calls in a step 802 a Max_Age () function.
- the Max_Age () function takes the List_Req list as its argument and returns the highest age indicator for List Req queries. If this age indicator is greater than 150, then in step 804, the storage server calls an Age () function that takes the List_Req list and the number 120 as arguments.
- the Age () function determines the set of queries. of List Req that have an age indicator greater than 120. These queries are stored in a list of List_Old queries.
- the storage server calls a function Req_Min_Sect () with the list List_Old and the array Last_Sect as arguments.
- the Req_Min_Sect () function is used to determine which query is in the List Old list that shows the query access sector closest to the last sector accessed recently.
- the storage server executes the request Req by calling it as an argument of an Exec () function in a step 808.
- the Exec () function executes the Req request, measures the execution time of this request and stores this time in a T_ex number.
- FIG. 9 The execution of a request is described using FIG. 9. This execution is based on a physical address - request size 900 type triplet that contains the header in the queue 64.
- a test on the type of the request determines the chain of disk and network I / O to be performed.
- the storage server If it is a write request, the storage server requests the storage client to send the write data to it in a step 904. The server The storage waits for the data, and on receipt writes the data to the space designated by the physical address in a step 906.
- the storage server 46 then sends a write acknowledgment 908 to the storage client 44 to confirm the write. After that, the execution ends in a step 914.
- the storage server 46 accesses the data contained in the space designated by the physical address in a step 910, up to the size of the request, and transmits them to the client of storage 44 in a step 912. After that, the execution ends in a step 914.
- the storage server updates the List_Req list in a step 810. This update is performed by calling a function Upd () with the List_Req list and the T_ex number as arguments.
- This function removes the Req request from the List_Req and List_Old lists, and updates a Tm Used matrix, by adding the number T_ex to the element at the crossing of the line corresponding to the storage client 44 that issued the Req request, and of the column corresponding to the disk targeted by the Req. This makes it possible to maintain the occupation of each disk by each storage client. Finally, the Last Sect table is updated to the disk column that was accessed by the Req query, to reflect the last sector actually accessed.
- the storage server 46 then tests in a step 812 if the list ListJDId is empty. If so, then the Rst flag is set in step 814 to indicate that an "aged" request has been executed and the Run_Old () function ends in a step 816. If not not the case, the function Run_Old () returns to step 806 to execute the other remaining old queries.
- the scheduling and execution loop then continues with a test on the Rst flag in a step 78 to determine if an "aged" request has been executed. If this is the case, then the storage server repeats the loop with step 72 by calling the lnit () function again.
- the storage server terminates the scheduling and execution loop by calling a Run_Min_Use () function with the List_Req list as argument.
- the function Run_Min_Use () is described using FIG. 10. After initialization in a step 1000, the storage server 46 calls an Add_Age () function with the number 1 as argument in a step 1002. The Add_Age () function increments the age indicator of all queries in the List_Req list by 1, and sets a Min_t counter to 0.
- the storage server 46 calls a Use_lnf_Min_t () function with the List_Req list and the Min_t counter as arguments.
- the Use_lnf_Min_t () function goes through the List_Req list, and checks for each request if the element of the matrix TmJJsed at the intersection of the line corresponding to the storage client 44 that sent it and the column corresponding to the disk it designates. is less than Min_t.
- the storage server tests whether List_Min_Req is empty. If this is the case, then the counter Min_t is incremented by 1 in a step 1008, and the step 1004 is repeated.
- the storage server 46 executes steps 1010, 1012 and 1014 which differ from the steps 906, 908, and 910 previously described only in that it is the list List_Min_Req which is used here, instead of the List Old list.
- the storage server 46 After executing the most favorable request according to steps 1010, 1012 and 1014, the storage server 46 calls a function Rst_Tm_Used () in a step 1016.
- the purpose of the Rst_Tm_Used () function is to reset the TmJJsed matrix in the case where a storage client 44 has used the disks extensively compared to other storage clients.
- the function Rst_Tm_Used () adds all the elements of the matrix TmJJsed. This represents the total sum of the occupation times of the disks managed by the storage server 46, by the totality of the storage clients 44.
- step 1016 the function Run_Min_Use () ends in a step 1018, and the scheduling and execution loop is restarted in step 72.
- the function Run_Min_Use () thus makes it possible to order the execution of the queries based on information contained in the request header, regardless of the presence of the data possibly designated by these requests.
- step 66 was made in the case where the storage server manages multiple data storage disks.
- the scheduling was performed here by placing all queries of the storage server queues together. However, it would be possible to distinguish the queries according to the queue from which they came respectively, either by indicating the List_Req list, or by executing a scheduling for each queue, in series or in parallel.
- FIG. 11 There is shown in Figure 11 an alternative scheduling and execution loop.
- the scheduling and execution loop is essentially identical to that shown in FIG. 6, except that it additionally comprises a sleep loop 110 which is executed before the steps represented on FIG. Figure 6.
- the sleep loop 110 includes a sleep management function Sleep_Mng () 112 whose result is stored in a variable SIp.
- variable SIp indicates the decision of a temporary sleep of the storage server or not. This function will be described further with FIGS. 13 to 15.
- the sleep loop 110 comprises a test 114 relating to the value of the variable SIp.
- the Force_Slp () function 116 "dumps" the storage server by sending a so-called sleep request to the queue.
- the sleep request has priority over all other requests. When executed, it runs the storage server idle for a configurable duration. This function can be seen as the equivalent of the Wait () function of Figure 7.
- the scheduling and execution loop executes exactly as shown in FIG. 6.
- the function Slp_Mng () will now be described using FIG. as can be seen in this figure, the function Slp_Mng () includes the sequential execution of a function Upd_Slp_Par () 1122, a function Perf_Slp () 1124, and a function Mnt_Slp () 1126, before ending in 1128.
- Upd_Slp_Par () 1122 The purpose of the function Upd_Slp_Par () 1122 is to update the parameters used to decide whether to fall asleep or not. This function will now be described using Figure 13.
- the function Upd_Slp_Par () 1122 updates two parameters Tm_psd, Nb_Rq_Slp and the variable SIp.
- the parameter Tm_psd is updated with an Elps_Time () function.
- the Elps_Time () function calculates how much time has elapsed since the last time the Upd_Slp_Par () 1122 function was executed.
- the parameter Nb_Rq_Slp is incremented by a value Tm_psd * Fq_Rq_Slp.
- the Nb_Rq_Slp parameter represents a number of sleep requests.
- the first is a type of performance-related condition.
- the second is a type relating to a nominal occupancy rate. This rate can in particular be defined through the administration module or generally be seen as a parameter set by the system administrator.
- the parameter Nb_Rq_Slp falls within this second type. It is a counter that provides that the server creates sleep requests with a frequency Fq_Rq_Slp which is a parameter set by the storage server administrator.
- the variable SIp is reset to 0 for the current sleep loop, and the function Upd_Par_Slp () ends in 1308.
- the Perf_Slp () function will now be described using Figure 14. This function makes it possible to decide whether to fall asleep based on the state parameters of the storing node and the queue.
- the first test 1402 relates to the occupation of local resources, that is to say the resources of the storage node on which the storage server runs.
- the processor If the processor is already heavily loaded (above 90% for example), then it is decided to put the storage server to sleep so that it does not degrade the performance of the storing node.
- the SIp variable is set to 1406 and the Perf_Slp () function ends in 1408.
- the processor load such as the access load of the local memory unit, for example, or other than the human the profession will consider.
- the second test 1404 is performed only if the first test 1402 is negative, that is to say if the processor load is not too important. This second test is about evaluating the number of queries in the queue.
- the storage server does not take advantage of the scheduling loop, potentially reducing performance.
- the variable SIp is set to 1 at 1406, and the function Perf_Slp () ends at 1408. Otherwise, the function ends directly at 1408.
- the function Mnt_Slp () will now be described using Figure 15. This function allows you to cancel a sleep that was planned or otherwise to impose a falling asleep of "maintenance”.
- the Mnt_Slp () function is based on two tests 1502 and 1508.
- the first test 1502 compares the parameter Nb_Rq_Slp to a minimum number of sleep requests to have to allow the execution of one of them. This comes down to whether many sleep queries have been executed recently.
- variable SIp is set to 0 in 1504 and the function ends in 1506.
- the second test 1508 is performed only if the first test 1502 is positive. This second test compares the Nb_Rq_Slp parameter to a maximum number of sleep requests. This is to determine if it has been a long time since any sleep request has been executed.
- the scheduling and execution loop comprises three main parts processed in series and an optional pre-loop:
- a third party for processing requests from storage clients that have used the storage server the least.
- the general concept is to order queries based on a quantitative criterion based on the relationship between the storage client and the storage server.
- a quantitative criterion of time of use of the local memory units is used to discriminate the requests between them.
- the scheduling is based on a strategy favoring two main axes: the execution of old requests, and the sharing of the load between the disks and the clients.
- maximizing disk bandwidth utilization for example by aggregating queries that are contiguous or nearly in a single request, thereby saving disk access; maximizing the exploitation of disk latency, for example by generating at the storage server level optimization requests aimed at the center of the disk (s) to reduce latency, or by generating predictive requests (ie ie targeting data in anticipation of a future request) at the storage server level.
- the application that accesses the stored data may include a driver that manages the relationships between the various elements such as the application-file system interaction, the file system-matching module interaction, the matching module interaction- storage client, implementing the storage server policy by getting each item a result and calling the next item with that result (or a modified form of that result).
- a driver that manages the relationships between the various elements such as the application-file system interaction, the file system-matching module interaction, the matching module interaction- storage client, implementing the storage server policy by getting each item a result and calling the next item with that result (or a modified form of that result).
- the system is autonomous and does not depend on the application that calls the data, and the elements are able to communicate with each other, so that the information goes down and then back up the element layers into element.
- the communications between these elements can be provided in different ways, for example by means of the POSIX interface, IP, TCP, UDP protocols, shared memory, RDMA (Remote Direct Access Memory). It should be borne in mind that the object of the invention is to provide the advantages of specialized storage systems based on existing network resources.
- An exemplary embodiment of the system described above is based on a network in which the stations are made with computers comprising: * a specialized or generalist processor (for example of the CISC or RISC type or other),
- one or more storage disks for example Serial ATA, or SCSI, or other hard disk drives
- storage disks for example Serial ATA, or SCSI, or other hard disk drives
- a network interface for example Gigabit, Ethernet, Infiniband, SCI .
- an operating system-based application environment eg Linux
- an operating system-based application environment eg Linux
- an application set for carrying out the correspondence module for example the Clustered Logical Volume Manager module of the Exanodes (registered trademark) application of the company Seanodes (registered trademark),
- This type of system can be realized in a network comprising:
- the invention encompasses the computer system comprising the application nodes and the nodes storing as a whole. It also encompasses the individual elements of this computer system, and in particular the application nodes and the storage nodes in their individuality, as well as the various means for carrying them out.
- the data management method is to be considered in its entirety, that is to say in the interaction of the application nodes and the storage nodes, but also in the individuality of the computer stations adapted to achieve the application nodes. and the storage nodes of this process.
- the invention also covers, as products, the software elements described, made available under any “medium” (support) readable by computer.
- computer readable medium includes data storage media, magnetic, optical and / or electronic, as well as a medium or transmission vehicle, such as an analog or digital signal.
- Such media cover both the software elements themselves, that is to say the elements to be executed directly, the software elements that are used for installation and / or deployment, as when a disk of installation or a downloadable installer.
- Such an installation can be carried out globally, on client stations and server stations, or separately, with each time appropriate products.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Computer And Data Communications (AREA)
Abstract
Description
Claims
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/445,581 US20100299386A1 (en) | 2006-10-26 | 2007-10-25 | Computer-based system comprising several nodes in a network |
JP2009533900A JP2010507851A (ja) | 2006-10-26 | 2007-10-25 | ネットワーク中に幾つかのノードを備える改良型のコンピュータベースシステム |
CA002667107A CA2667107A1 (fr) | 2006-10-26 | 2007-10-25 | Systeme informatique ameliore comprenant plusieurs noeuds en reseau |
EP07866438A EP2090052A2 (fr) | 2006-10-26 | 2007-10-25 | Systeme informatique ameliore comprenant plusieurs noeuds en reseau |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0609406 | 2006-10-26 | ||
FR0609406A FR2907993B1 (fr) | 2006-10-26 | 2006-10-26 | Systeme informatique comprenant plusieurs noeuds en reseau. |
FR0707476 | 2007-10-24 | ||
FR0707476A FR2923112B1 (fr) | 2007-10-24 | 2007-10-24 | Systeme informatique ameliore comprenant plusieurs noeuds en reseau |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2008053098A2 true WO2008053098A2 (fr) | 2008-05-08 |
WO2008053098A3 WO2008053098A3 (fr) | 2008-10-09 |
Family
ID=39344642
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/FR2007/001765 WO2008053098A2 (fr) | 2006-10-26 | 2007-10-25 | Systeme informatique ameliore comprenant plusieurs noeuds en reseau |
Country Status (5)
Country | Link |
---|---|
US (1) | US20100299386A1 (fr) |
EP (1) | EP2090052A2 (fr) |
JP (1) | JP2010507851A (fr) |
CA (1) | CA2667107A1 (fr) |
WO (1) | WO2008053098A2 (fr) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2940570A1 (fr) * | 2008-12-23 | 2010-06-25 | Seanodes | Systeme de stockage comprenant plusieurs noeuds en reseau avec gestion de la parite |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9037692B2 (en) * | 2008-11-26 | 2015-05-19 | Red Hat, Inc. | Multiple cloud marketplace aggregation |
CN102595574A (zh) * | 2011-08-09 | 2012-07-18 | 北京新岸线无线技术有限公司 | 节电方法及装置 |
CN106547517B (zh) * | 2016-11-03 | 2018-11-20 | 浪潮金融信息技术有限公司 | 一种控制等待时间的方法及装置 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000041510A2 (fr) * | 1999-01-15 | 2000-07-20 | Storage Technology Corporation | Gestionnaire de memoire intelligent |
US6308245B1 (en) * | 1999-05-13 | 2001-10-23 | International Business Machines Corporation | Adaptive, time-based synchronization mechanism for an integrated posix file system |
US20030120751A1 (en) * | 2001-11-21 | 2003-06-26 | Husain Syed Mohammad Amir | System and method for providing virtual network attached storage using excess distributed storage capacity |
US20040133577A1 (en) * | 2001-01-11 | 2004-07-08 | Z-Force Communications, Inc. | Rule based aggregation of files and transactions in a switched file system |
US20050195660A1 (en) * | 2004-02-11 | 2005-09-08 | Kavuri Ravi K. | Clustered hierarchical file services |
US20050198194A1 (en) * | 2004-02-18 | 2005-09-08 | Xiotech Corporation | Method, apparatus and program storage device for providing wireless storage |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6684250B2 (en) * | 2000-04-03 | 2004-01-27 | Quova, Inc. | Method and apparatus for estimating a geographic location of a networked entity |
US20040249939A1 (en) * | 2003-05-23 | 2004-12-09 | International Business Machines Corporation | Methods and apparatus for dynamic and optimal server set selection |
-
2007
- 2007-10-25 WO PCT/FR2007/001765 patent/WO2008053098A2/fr active Application Filing
- 2007-10-25 US US12/445,581 patent/US20100299386A1/en not_active Abandoned
- 2007-10-25 JP JP2009533900A patent/JP2010507851A/ja active Pending
- 2007-10-25 EP EP07866438A patent/EP2090052A2/fr not_active Withdrawn
- 2007-10-25 CA CA002667107A patent/CA2667107A1/fr not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000041510A2 (fr) * | 1999-01-15 | 2000-07-20 | Storage Technology Corporation | Gestionnaire de memoire intelligent |
US6308245B1 (en) * | 1999-05-13 | 2001-10-23 | International Business Machines Corporation | Adaptive, time-based synchronization mechanism for an integrated posix file system |
US20040133577A1 (en) * | 2001-01-11 | 2004-07-08 | Z-Force Communications, Inc. | Rule based aggregation of files and transactions in a switched file system |
US20030120751A1 (en) * | 2001-11-21 | 2003-06-26 | Husain Syed Mohammad Amir | System and method for providing virtual network attached storage using excess distributed storage capacity |
US20050195660A1 (en) * | 2004-02-11 | 2005-09-08 | Kavuri Ravi K. | Clustered hierarchical file services |
US20050198194A1 (en) * | 2004-02-18 | 2005-09-08 | Xiotech Corporation | Method, apparatus and program storage device for providing wireless storage |
Non-Patent Citations (2)
Title |
---|
FEELEY M J ET AL: "IMPLEMENTING GLOBAL MEMORY MANAGEMENT IN A WORKSTATION CLUSTER" OPERATING SYSTEMS REVIEW, ACM, NEW YORK, NY, US, vol. 29, no. 5, décembre 1995 (1995-12), pages 201-212, XP000584826 ISSN: 0163-5980 * |
VINCENT BERDOT: "Seanodes fusionne cluster d'applications et de stockage" 01NET, [Online] no. 1799, 28 janvier 2005 (2005-01-28), XP002440987 Extrait de l'Internet: URL:http://www.01net.com/article/266276.html> [extrait le 2007-07-05] * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2940570A1 (fr) * | 2008-12-23 | 2010-06-25 | Seanodes | Systeme de stockage comprenant plusieurs noeuds en reseau avec gestion de la parite |
Also Published As
Publication number | Publication date |
---|---|
CA2667107A1 (fr) | 2008-05-08 |
WO2008053098A3 (fr) | 2008-10-09 |
US20100299386A1 (en) | 2010-11-25 |
EP2090052A2 (fr) | 2009-08-19 |
JP2010507851A (ja) | 2010-03-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
FR2681707A1 (fr) | Systeme de fichiers pour redistribuer selectivement des fichiers et procede pour affecter un espace de memoire dans un systeme informatique comportant de multiples dispositifs de stockage de donnees. | |
US10601901B2 (en) | Methods, systems, and media for stored content distribution and access | |
FR2906908A1 (fr) | Dispositif de memorisation qui est connecte a une memoire externe | |
FR2884632A1 (fr) | Systemes distribues de calcul bases sur des informations d'etat distribuees et procedes et protocoles correspondants | |
FR2959089A1 (fr) | Outil de gestion de ressources et d'infrastructures informatiques et reseaux | |
EP2559224B1 (fr) | Outil de gestion de ressources et d'infrastructures informatiques et de réseaux | |
FR2980008A1 (fr) | Controleur pour dispositif de memorisation et procede de commande d'un dispositif de memorisation | |
WO2018154197A1 (fr) | Procédé, équipement et système de gestion du système de fichiers | |
EP2366147A1 (fr) | Gestionnaire physique de barriere de synchronisation entre processus multiples | |
FR2959091A1 (fr) | Outil de gestion de ressources et d'infrastructures informatiques et reseaux | |
EP2090052A2 (fr) | Systeme informatique ameliore comprenant plusieurs noeuds en reseau | |
FR3007542A1 (fr) | File d'echange de donnees ayant une profondeur illimitee | |
EP2709008B1 (fr) | Procédé et dispositif de décompte du temps déporté pour unité de traitement dans un système de traitement de l'information | |
FR2907993A1 (fr) | Systeme informatique comprenant plusieurs noeuds en reseau. | |
FR2819321A1 (fr) | Procede de traitement et d'acces a des donnees dans un systeme de reservation par ordinateur, et systeme de mise en oeuvre | |
EP2726985B1 (fr) | Dispositif et procede de synchronisation de taches executees en parallele sur une plateforme comprenant plusieurs unites de calcul | |
FR2923112A1 (fr) | Systeme informatique ameliore comprenant plusieurs noeuds en reseau | |
EP2039126A1 (fr) | Procede pour lutter contre la diffusion illicite d'oeuvres protegees et systeme informatique pour la mise en oeuvre d'un tel procede | |
WO2019115929A1 (fr) | Procede de gestion du systeme de fichiers d'un terminal informatique | |
FR2995425A1 (fr) | Procede et systeme de mise en oeuvre d'une infrastructure informatique en nuage agregeant des ressources isolees mises a disposition a travers un reseau | |
EP1952599B1 (fr) | Procede de diffusion maitrisee d'informations | |
WO2010125257A1 (fr) | Système de stockage comprenant plusieurs noeuds en réseau avec gestion de synchronisation d'écriture | |
EP2212791A2 (fr) | Système informatique amélioré comprenant plusieurs noeuds en réseau | |
EP4113297A1 (fr) | Procédé de gestion des travaux dans un système informatique et système associé | |
EP2860630A1 (fr) | Procédé de transfert de données dans un environnement dynamique |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 200780039790.2 Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 07866438 Country of ref document: EP Kind code of ref document: A2 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 12445581 Country of ref document: US Ref document number: 2007866438 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2667107 Country of ref document: CA |
|
ENP | Entry into the national phase |
Ref document number: 2009533900 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |