WO2009053557A1 - Système informatique amélioré comprenant plusieurs noeuds en réseau - Google Patents

Système informatique amélioré comprenant plusieurs noeuds en réseau Download PDF

Info

Publication number
WO2009053557A1
WO2009053557A1 PCT/FR2008/001168 FR2008001168W WO2009053557A1 WO 2009053557 A1 WO2009053557 A1 WO 2009053557A1 FR 2008001168 W FR2008001168 W FR 2008001168W WO 2009053557 A1 WO2009053557 A1 WO 2009053557A1
Authority
WO
WIPO (PCT)
Prior art keywords
storage
addresses
group
failure
function
Prior art date
Application number
PCT/FR2008/001168
Other languages
English (en)
Other versions
WO2009053557A9 (fr
Inventor
Michaël DUSSERE
Samuel Richard
Original Assignee
Seanodes
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 Seanodes filed Critical Seanodes
Priority to EP08841064A priority Critical patent/EP2212792A1/fr
Publication of WO2009053557A1 publication Critical patent/WO2009053557A1/fr
Publication of WO2009053557A9 publication Critical patent/WO2009053557A9/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2061—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring combined with de-clustering of data

Definitions

  • the invention relates to computer systems comprising computer folds called nodes interconnected in a network.
  • Modern networks have user stations that serve as one or more servers and can share applications and / or storage locally or remotely.
  • the invention improves the situation.
  • the invention proposes a computer data storage tool comprising a correspondence module connected to storage units, said correspondence module comprising a correspondence function for determining at least a first and a starting from a virtual address received as input.
  • the tool comprises a rule for distributing at least one storage part in a workgroup and a selected number of groups the basis of a fault tolerance criterion, said rule providing for one of the storage units has storage addresses associated with the workgroup and storage addresses associated with at least one failure group,
  • the tool also maintains a resilience table comprising inputs each associating a fault group and a storage unit, according to a failure state of this storage unit,
  • mapping function is arranged to block at least a portion of the virtual addresses, to storage addresses belonging to the workgroup, by hatching the virtual addresses on the workgroup, and
  • said matching function is arranged to assign, in the event of failure of a storage unit, at least a part of the virtual addresses associated with the storage addresses on this storage unit, to storage addresses belonging to a fault group to which the failed storage unit is associated in the resiliency table.
  • 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
  • FIG. 5 shows an example of implementation of an element of
  • FIG. 6 shows a correspondence between spaces IOJ physical spaces managed by the element of FIG. 5,
  • FIG. 7 shows an example of a function implemented by FIG. 5 to establish the correspondence of FIG. 6,
  • FIG. 8 shows an exemplary implementation of part of FIG. 7,
  • FIGS. 9 and 10 show examples of functions running in parallel with the function of FIG. 7,
  • FIG. 11 shows an allocation of the logical spaces over the physical spaces as a variant of the correspondence represented in FIG. 6;
  • FIG. 12 shows a variant of the function of FIG. 8 adapted to take account of the allocation of FIG. 11;
  • FIG. 13 shows an exemplary implementation of a portion of FIG. 12;
  • FIG. 14 shows an example of a function running in parallel with the function of FIG. 7, and
  • FIG. 15 shows a variant of FIGS. 8 and 12 which implements both the allocation represented in FIG. 6 and that shown in FIG. 11.
  • the drawings and the description below contain, for the most part, elements of a certain character. They can therefore not only serve to better understand the present invention, but also contribute to its definition, if any.
  • 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 called here nodes are interconnected in a network including physical and application.
  • the network consists of 5 stations, varying between 1 and 5.
  • the application environment 2 is implemented distributed application 12 on the N1, N2 and N3, in an application layer N4 and a application layer 16 on the N5.
  • station or station used here should be interpreted broadly, and as designating network computing elements on which applications or server programs run, or both.
  • 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 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 divided into 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 (resf: data stored in the logical space 26 (reî of the file system 18 (respectively 20, 22), although that not necessarily physically present on one of the S-station disks 10 who uses this application.
  • the spaces 26, 28 and 30 are purely logical, it does 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 correspondence table between the virtual addresses of the data in the logical spaces and the 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.
  • All application, storage and system resources can be integrated locally on each station, or network stations.
  • 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.
  • the client d ⁇ and the storage server 46.
  • the distribution of these elements means an administration 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 if r a node of given storage.
  • the table corresponds to table which contains information allowing r matches.
  • the engine 40 interacts with the table 42 to establish the corresponding physical address.
  • the lookup table 42 does not contain all the matches, but only a much narrower set of information sufficient to quickly restore the match.
  • 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
  • step 52 the virtual file system for the data of this file, and virtual access gei based on the query 50 and these virti addresses.
  • Virtual access requests each include:
  • the size of the request that is to say the number of bits to access 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. .
  • file access requests 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 engine 40 and the look-up 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 correspondence between physical address addresses are fixed, and the engine 40 operates so that in the context of a read request for determining the physical 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 initiated, in which a stopping condition 58 is reached when a physical access request has been issued 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. In this loop, all the access requests represented as executed successively However, the execution can also be performed in trim only in series.
  • queries are transmitted from couch to the physical access layer. It would be possible, however, to transmit only addresses (virtual and then physical), and to recover, at the level of the physical layer, selected properties of the initial file request to form the physical access requests.
  • 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.
  • FIG. 5 represents an exemplary embodiment of the virtualization layer 36 of FIG.
  • the engine 40 includes a queue 402, an address determination unit 404 and a cover unit 406.
  • Queue 402 receives all virtual access requests for the determination of the corresponding physical addresses.
  • the determination of the physical addresses is carried out by the address determination unit 404, in collaboration with the correspondence table 42.
  • the correspondence table 42 contains only an extremely limited set of data which will be described later.
  • the invention proposes several schemes for assigning virtual spaces to physical spaces. These assignments make it possible to quickly and inexpensively determine the virtual address / physical address correspondences on the base of lightweight algorithms while offering a qu; much more efficient in terms of occupation the use of a direct correspondence table such a "look- English".
  • the purpose of the recovery unit 406 is to update physical addresses when a storage space of a stati ceases to function, as will be described below.
  • FIG. 6 illustrates a first scheme for allocating virtual spaces to physical spaces so as to tolerate so-called correlated failures.
  • Correlated failure means a failure that renders inoperative a set of spaces or storage units (hereinafter disks) interconnected (hereinafter failure group).
  • the disks can be grouped by failure group on the basis of a fault dependency criterion.
  • a fault dependence criterion aims to bring together disks for which the probability of a simultaneous failure is important, so as to ensure that the data of these disks are not replicated on one of them. .
  • a fault dependency criterion mention may be made of the fact that the same node-node belongs, from both a hardware and software point of view, to the link to the same network node, from a material point of view that software, the proximity of geographical location, etc.
  • the allocation of virtual space to the physical spaces is carried out so that: - the data of a virtual address is stored on disks that belong to distinct fault groups; and - the consecutive virtual address data hatches that span all the disks.
  • nodes N1 to N4 here comprises three disks MU11, MU12 and MU13, the node N2 MU21, MU22 and MU23, the node N3 a disk MU31, and the n disks MU41, MU42 and MU43.
  • each node forms a failure group, i.e., in terms of failure, it is assumed that the disks of a node depend on it, but that the node disks distinct are independent of each other.
  • the failure group N1 is composed of the disks MU11 to MU13
  • the failure group N2 is composed of the disks M J21 to MU23
  • the failure group N3 is composed of the disk MU31
  • the failure group N4 is composed of the disks MU41. at MU43.
  • the groups of failures could be defined differently, for example by belonging to a network unit. It is therefore important to understand that disks are first grouped by failure group and not only by node.
  • the assignment of the failure group disks to a replication group follows an allocation algorithm that implements the constraints described above. To account for the first constraint, fewer as many replication groups as there is a failure that has the largest number of disks, conformally
  • the replication group GR1 comprises four disks which respectively correspond to the disks MU11, MU21, MU31 and MU43, and the other disks MU12 and MU13 of the failure group N1 are respectively assigned to the groups GR2. and GR3.
  • the virtual addresses are assigned on the disks sorted by group of replication.
  • ch ⁇ means the association of virtual addresses with ⁇
  • the virtual addresses are grouped in ascending order hatch ("striping unit") of defined sizes.
  • the hatching are themselves associated with physical disk addresses.
  • the hatch units are assigned to all disks of all replication groups in ascending order, line by line.
  • the virtual addresses are thus allocated in block to the replication groups, in an increasing manner.
  • the first hatch unit of the first disk of the first replication group receives the index 0
  • the first hatch unit of the second disk of the first replication group receives the index 1, and so on.
  • a line of hatch units will subsequently be called the actual hatch. Note also in the upper part of Figure 6 that for every other line, the hatch units are not ordered by increasing index.
  • the disk addresses MU11 of N1 receive the following hatching units 20, 21, 30, 33, 40 and 42.
  • the data is replicated to directly consecutive true hatches within the main hatch.
  • the replicated data could be in non-consecutive real hatches.
  • the correspondence table 42 is thus reduced to its simplest expression. Note also that, because of the data replication mentioned above, there are twice as many physical addresses as virtual addresses.
  • Figure 7 shows the example of a function that allows to find a physical address from a virtual address.
  • this function is implemented in the address determination unit 404. It starts in an operation 2000 of a virtual address, for example taken from the queue 402. In a 2020 operation, a test is performed ⁇ virtual is connected to a write request. If 2040, a test is performed to determine if the system is in, that is, if one of the disks is down. If so, Wrt_Drt_Z () is called in 2060.
  • the operations 2040, 2060 and 2080 are connected to fast recovery functions of a disk failure which will be described further with FIGS. 9 and 10.
  • a function SU_lnd () is called in a operation 2070.
  • the function SU_lnd () starts from the virtual address whose correspondence is sought, and returns the index of the hatch unit SU Ind. associated with it. This is easily achievable as the size of each hatching unit is known.
  • a Get_Phy_lnd () function is called in an operation 2080 which determines corresponding physical address indices.
  • the physical address indices are converted into physical addresses by a function Phy_Ad (). This is easily achievable as the size of each hatching unit is known.
  • the function Get_Phy_lnd () receives the following two arguments (operation 2082): * the index of the unit of hatching of which one seeks the correspondence, and * An array Ngr [] containing a line whose disks for each replication group.
  • the table Ngr [] is useful because it allows to quickly find the N disks and the number of replication group Ngr, and quickly access the number of disks per replication group.
  • a Strip () function determines a principal hatch index k, air if that index m1 in the replication groups of the first disk on which the virtual address is stored. This is accomplished by applying Equations 20 and 21 of Appendix A.
  • a function Repl () determines the actual hatch indices k1 and k2 to account for data replication. This is accomplished by applying Equations 22 and 23 of Appendix A.
  • a function Spl () determines the index p of the replication group that corresponds to the disk index m1, as well as the index q1 of the disk m1 within this replication group. This is accomplished by applying Equations 24 and 25 of Appendix A.
  • a function Shft () determines an index q2 within the index replication group p of the disk on which the replicated data is stored. This is accomplished by applying Equation 26 of Appendix A. Other equations would obviously be offset unit index hatch. In disk within a replication group contains all replicated from another disk in the same group.
  • a function Mrg () determines an index which corresponds to the index q2 within the indi replication group realized by applying Equation 27 of Annex A.
  • the indexes m1 and m2 of the disks classified by group of replication are converted into disk indices n1 and n2 of disks classified by failure group by a function Get_Dsk_lnd (). This function performs the inverse operation of equation 12 and applies equations 28 and 29 of Appendix A.
  • Get_Phy_lnd () function returns the physical address indices determined in a 2099 operation.
  • the principle of this reintegration is based on the marking of the virtual zones associated with a failed disk during a write.
  • the fault sheet contains two lines, one of which receives discs and the other receives an increasing index.
  • the second table, d contains two lines, one of which receives zone identifiers, and the other receives a modification index.
  • the fault table is stored on each of the disks in a space reserved by the administration module which is not usable for storing the data. This table is kept consistent on all the disks by the administration module. This table has a fixed size equal to the total number of disks.
  • the fault table is filled by means of the function shown in FIG. 9.
  • this function receives the identifiers of all the failed disks.
  • a function ls_Tgd_Dsk () searches for each failed disk identifier in the fault table.
  • the fault table For each missing identifier, the fault table creates a new entry that receives the disk identifier in the first line, and an index incremented in the second line (operation 2204). Otherwise the function processes the next identifier (operation 2206).
  • the fault table is implemented as a stack or linked list. Therefore, it has only one line that receives the indices of disks, and this is the position index of each of them serves as a growing index.
  • the Wrt_Drt_Z () function relies on the indexes of the table to maintain an up-to-date view of the areas associated with a modified pan disk.
  • the cover unit 406 may perform the function of Fig. 10 to restore a disk after a failure.
  • the unit 406 starts with a subscript i set to zero (operation 2300) and goes through the zone table.
  • a function Upd_Z (i) updates the data of the area concerned by retrieving the corresponding replicated data (operation 2304).
  • the zone table is updated to reflect this operation (2306).
  • an End_Drt_Zone () function deletes the entry from the fault table associated with the restored disk, and goes through the fault table to increase the index of the zones by the maximum of the remaining indices. This ensures slow growth of the indices too large.
  • zone table can receive size zones
  • an entry in the zone table is associated with a plurality of contiguous virtual addresses.
  • this table is stored in the reserved data area of the logical volume to which the virtual addresses belong, that is, it is equally distributed on all the disks.
  • the reserved data area of the logical void is not extensible indefinitely. It should also be noted that the call to the zone table constitutes a read request in the system.
  • FIGS. 9 and 10 can be seen as functions that loop in parallel with the main execution of the system. Indeed, to ensure maximum information security, these functions constitute "interruptions".
  • Figure 11 shows an assignment of physical virtual spaces as an alternative to that of Figure 6.
  • the tolerance also increased, this time voluntarily leaving free spaces within the replication groups called resilience units.
  • FIG. 1 For the sake of clarity, there is shown in this figure a single replication group that includes seven disks. Among these seven disks, we will define hatches comprising four hatch units for storing data, and three resilience units for fault tolerance.
  • the disks are divided into several groups, the correlated faults, that is to say, affecting several disks at the same time.
  • resiliency units in addition to hatch units amounts to splitting some of the physical addresses into a workgroup (those receiving the data from the hatch units) on the one hand, and into fault groups (the ones that receive data from the resiliency units) on the other hand, according to a fault tolerance criterion.
  • Such fault tolerance criterion relates for example to the number of successive failures that one wishes to support, and therefore the number of fault groups to manage. In the present example, this number is three. Other criteria could nevertheless be used.
  • a processing block A for determining the disk and hatch indices as before, without taking into account the presence of the resilience units
  • the Strip () function determines the main hatch k, as well as the index mm1 of the first disk where the virtual address is stored.
  • Operation 2484 differs from operation 2084 of Figure 8 in that the Strip () function is called with the number of hatch units, i.e. the number of disks minus the number of units. of resilience.
  • the function Repl () determines the actual hatch indices k1 and k2 to account for the replication of the data as the operation 2086.
  • the Shft () function determines a mm2 index of the disk that receives the replicated data. Operation 2490 differs from operation 2090 of Figure 8 in that the function Shft () is called with the number of hatch units, i.e., the number of disks minus the number of units of resilience.
  • a function Cp_Spr () determines an index m1 which corresponds to the real index of the disk associated with the index mm1. This function is used to modify the mm1 index to take into account the presence of the resilience units. As we will see below, the index m1 that returns the function Cp_Spr () can be an index of a unit of resilience.
  • a function Cp_Spr () determines an index m2 which corresponds to the real index of the disk associated with the index mm2. This function is used to modify the mm2 index to take into account the presence of resilience. As we will see below, the Cp_Spr () can be an index of a unit of resilience
  • the address indices are returned in 2499.
  • the function Cp_Spr () will now be described with FIG. 13. receives as arguments a disk index mm, a unit index ⁇ e hatch k, a total number of disks N and a number of units of resilience S.
  • the function Cp_Spr () starts by executing a Spr () function in 2602.
  • the Spr () function implements Equation 30 of Appendix A.
  • the Spr () function receives three input arguments:
  • the function Spr () thus makes it possible to establish an index m which takes into account the presence of the S units of resilience.
  • a test determines in an operation 2604 whether the disk associated with the real index m has failed and whether a resiliency unit has been assigned to it.
  • An example of implementation of the function 2604 is the holding of a table here called resilience table.
  • This table contains a single line, in which each column corresponds to a disk of index m corresponding to the number of the column.
  • Such a resilience table is stored on each of the d synchronized continuously, at the same time as the example table.
  • the index mm is updated in an operation 2606 by a function Spr_2 () which implements equation 31 of Annex A using as arguments the total number of disks N , the number of resilience units S, and the index m that has just been calculated.
  • This function assumes that the data of the index disk m is stored in each hatch on the resistivity unit whose resilience index is indicated by the resilience table, and that it is therefore sufficient to know the hatch index k to determine the index of the disk on which the desired resiliency unit is allocated.
  • the Cp_Spr () function is restarted.
  • the function Cp_Spr () is repeated again, so that the The returned index corresponds to a resiliency unit on a functional disk.
  • a function Spr_Dsk () modifies the index ⁇ failure with which no resilience unit is associated.
  • Resiliency value c receives the first resilience index not already assigned.
  • the function Wrt_Spr_Dsk () generates queries for writing the data available on the remaining hatchery unit to the unit "? resilience, and these queries are executed in competition with other access requests. This means that the resiliency unit can not be used until this write request has been made. Finally, the function ends in 2706.
  • the Wrt_Spr_Dsk () function generates the write requests on the resiliency units and executes these requests before any other access request. Note that when the disk is restored, it is also necessary to copy again the replicated data on it.
  • This function can therefore be realized as virtualization or in the administration module, as an ion as presented here, or as an integral part presented above.
  • FIG. 15 The function shown in FIG. 15 is a mixture of the variants of the Get_Phy_lnd () function described with FIGS. 8 and 12. Thus, it has great similarities with them. This is why some operations have not been renumbered.
  • the Get_Phy_lnd () function receives the following arguments:
  • the table Ngr [] is useful because it allows to quickly find the total number of N disks and the number of Ngr replication group, and access just as quickly to the number of disks per replication group. In another implementation, it is possible as arguments, but a computation is then born from the number of disks within a given replication group.
  • the indices of the disks q1 and q2 within the replication group p are then transformed into disk indices m1 and m2 in operations 2496 and 2497 in a similar manner to the operation 2097 of FIG. 8.
  • indexes m1 and m2 of disks classified by replication group are converted into disks indexes n1 and n2 disks classified by failure group in an operation 2498 as the operation 2098 of Figure 8.
  • This embodiment is the embodiment is very advantageous because it offers a very high tolerance to various failures, both through the distribution of data on disks belonging to different failure groups that through the use of the units of resilience that can contain failures within replication groups.
  • hatching distribution described in the modes described allows to obtain very improved performance, as the accesses are distributed on separate disks.
  • the hatching units are here described, however, possible to implement the invention by assigning different hatches depending on the replication groups meansr modifications to the described functions.
  • the engine and lookup table described here form a match capable of assigning the virtual to physical addresses based on a rule having an arithmetic formula defined by the above functions.
  • obtaining addresses that are called "physical address” means above all a disassembly of the virtualization layer. These addresses could indeed themselves be virtual addresses of a logical space of a storage server. In the same way, the virtual addresses received upstream could themselves correspond to a disabstraction of a higher virtualization layer.
  • the application that accesses the stored data manages the relationships between the various elements t file system, the file system-correspondence interaction, the matching module interaction - client implementation of the storage server policy gets a result element and calling the next element with this modified form of this 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.
  • a specialized or general-purpose processor eg the type CISC or RISC or other
  • one or more storage disks eg hard drives to Serial ATA or SCSI, or otherwise
  • storage disks eg hard drives to Serial ATA or SCSI, or otherwise
  • a network interface for example Gigabit, Ethernet, Infiniband, SCI .
  • 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 a data storage method determining at least a first and a second; storage from a received virtual address, the storages being associated with storage units, and storing associated with said virtual address in said first and second storage addresses determined, the method being characterized in that: at least a portion of the storage addresses are divided into a workgroup and a selected number of fault groups, based on a fault tolerance criterion, based on a rule that at least one of the units storage includes storage addresses associated with the workgroup and storage addresses associated with at least one failure group;
  • said determination comprises the block allocation of at least a portion of the virtual addresses, to storage addresses belonging to the workgroup, by hatching the virtual addresses on the workgroup, * a resilience table is maintained said resilience table comprising inputs each associating a failure group and a storage unit, depending on a failure state of that storage unit, and
  • said determination comprises, in case of failure of a storage unit, the assignment of at least a part of the virtual addresses associated with the storage addresses on this storage unit, to storage addresses belonging to a fault group to which this storage unit is associated in the resilience table.
  • the method may further be characterized in that: at least a portion of the storage units are divided into replication groups, based on a fault dependency criterion, in that at least a portion of the storage addresses are storage in each grouoe replication are divided into a workgroup and a failure, on the basis of a determination tolerance criterion comprises the block allocation of at least one virtual address, to storage addresses of the group of tr on units of storage of the same replication group, in hatching of the virtual addresses on the replication group, e failure of a storage unit, at least part of the addresses associated with the storage addresses on this storage unit, are assigned to storage addresses belonging to a failure group of the relevant replication group, based on this failure;
  • the first storage addresses associated with each block are allocated by hatching all storage units in the given replication group, and the second storage addresses. are assigned to all storage units in the given replication group by performing a specific hatch for each block;
  • said distribution of the storage units into replication groups is based on a chosen arithmetic formula; said arithmetic formula is arranged to define a number of replication groups greater than or equal to the maximum number of dependent storage units according to the fault dependence criterion;
  • the invention also covers, as products, the elements described, made available under any “medium” (support) lilsible
  • medium includes data storage, magnetic, optical and / or electronic, also although a support or transmission vehicle, such as an analog or digital signal.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)

Abstract

Outil informatique de stockage de données comprenant un module de correspondance (40) relié à des unités de stockage (38), ledit module de correspondance (40) comprenant une fonction de correspondance pour déterminer au moins une première et une deuxième adresses de stockage à partir d'une adresse virtuelle reçue en entrée, caractérisé en ce que, la fonction de correspondance est agencée pour : l'outil comporte une règle pour répartir au moins une partie des adresses de stockage en un groupe de travail et un nombre choisi de groupes de panne, sur la base d'un critère de tolérance de panne, ladite règle prévoyant qu'au moins une des unités de stockages comporte des adresses de stockage associées au groupe de travail et des adresses de stockage associées à au moins un groupe de panne, l'outil maintient en outre une table de résilience comprenant des entrées associant chacune un groupe de panne et une unité de stockage, en fonction d'un état de panne de cette unité de stockage, ladite fonction de correspondance est agencée pour affecter par blocs au moins une partie des adresses virtuelles, à des adresses de stockage appartenant au groupe de travail, en réalisant un hachurage des adresses virtuelles sur le groupe de travail, et ladite fonction de correspondance est agencée pour affecter, en cas de panne d'une unité de stockage, au moins une partie des adresses virtuelles associées aux adresses de stockage sur cette unité de stockage, à des adresses de stockage appartenant à un groupe de panne auquel l'unité de stockage en panne est associée dans la table de résilience.

Description

Système informatique amélioré comprenant plus
L'invention concerne les systèmes informatiques comprenant pli informatiques dits noeuds interconnectés en un réseau.
Les réseaux modernes comportent des stations utilisateurs qui so ou plusieurs serveurs et peuvent partager des applications et/ou de stockage de manière locale ou distante.
Dans le cadre d'applications partagées faisant usage d'une quantité importante de données ou dans le cadre du partage d'une quantité importante de données, il est fréquent de faire appel à des systèmes de stockage spécialisés, tels que les Storage Area Network (ou SAN).
L'utilisation de ces systèmes perfectionnés présente certains désavantages, comme les coûts associés, les limitations de performance et d'extensibilité, et la lourdeur générale de l'installation qui leur correspond.
Par ailleurs, avec les réseaux modernes, l'utilisation de ces systèmes perfectionnés représente une sous utilisation du matériel déjà présent dans le réseau.
Enfin, les systèmes qui ont été proposés qui utilisent le matériel déjà présent dans le réseau ont des performances insatisfaisantes, notamment en termes de gestion des pannes.
L'invention vient améliorer la situation.
À cet effet, l'invention propose un outil informatique de stockage de données comprenant un module de correspondance relié à des unités de stockage, ledit module de correspondance comprenant une fonction de correspondance pour déterminer au moins une première et une dei partir d'une adresse virtuelle reçue en entrée.
Selon un aspect particulier : * l'outil comporte une règle pour répartir au moins une partie de stockage en un groupe de travail et un nombre choisi de groupes la base d'un critère de tolérance de panne, ladite règle prévoyar une des unités de stockages comporte des adresses de stockage associées au groupe de travail et des adresses de stockage associées à au moins un groupe dé panne,
* l'outil maintient en outre une table de résilience comprenant des entrées associant chacune un groupe de panne et une unité de stockage, en fonction d'un état de panne de cette unité de stockage,
* ladite fonction de correspondance est agencée pour affecter par blocs au moins une partie des adresses virtuelles, à des adresses de stockage appartenant au groupe de travail, en réalisant un hachurage des adresses virtuelles sur le groupe de travail, et
* ladite fonction de correspondance est agencée pour affecter, en cas de panne d'une unité de stockage, au moins une partie des adresses virtuelles associées aux adresses de stockage sur cette unité de stockage, à des adresses de stockage appartenant à un groupe de panne auquel l'unité de stockage en panne est associée dans la table de résilience.
D'autres avantages et caractéristiques de l'invention apparaîtront mieux à la lecture de la description qui suit d'exemples, donnée à titre illustratif et non limitatif, à partir des dessins sur lesquels :
- la figure 1 montre une vue fonctionnelle générale d'un système informatique selon l'invention,
- la figure 2 montre un exemple d'implémentation logique du système de la figure 1 ,
- la figure 3 montre un exemple de composition d'un élément de la figure 2, - la figure 4 montre un procédé d'accès à un fich
1 ,
- la figure 5 montre un exemple d'implémentation d'un élément de
- la figure 6 montre une correspondance entre des espaces IOJ espaces physiques gérée par l'élément de la figure 5,
- la figure 7 montre un exemple d'une fonction mise en œuvre pa la figure 5 pour établir la correspondance de la figure 6,
- la figure 8 montre un exemple d'implémentation d'une partie de de la figure 7,
- les figures 9 et 10 montrent des exemples de fonctions s'exécutant en parallèle avec la fonction de la figure 7,
- la figure 11 montre une attribution des espaces logiques sur les espaces physiques en variante de la correspondance représentée sur la figure 6,
- la figure 12 montre une variante de la fonction de la figure 8 adaptée pour tenir compte de l'attribution de la figure 11 , - la figure 13 montre un exemple d'implémentation d'une partie de la figure 12,
- la figure 14 montre un exemple d'une fonction s'exécutant en parallèle avec la fonction de la figure 7, et
- la figure 15 montre une variante des figures 8 et 12 qui met en œuvre à la fois l'attribution représentée sur la figure 6 et celle représentée sur la figure 11. Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant.
La figure 1 représente un schéma général d'un système informatique selon l'invention. Dans ce système, un environnement d'application 2 a accès à un gestionnaire de système de fichiers 4. Une couche de virtualisation 6 établit la correspondance entre le gestionnaire de système de fichiers 4 et des serveurs de stockage 8.
La figure 2 représente une implémentation logique du système de la figure 1. Dans cette implémentation, un ensemble de stations 10, également appelées ici noeuds sont interconnectées en un réseau dont physiques et applicatives.
Dans l'exemple ici décrit, le réseau est constitué de 5 stations, ne variant entre 1 et 5. L'environnement d'application 2 est réalisé e applicative répartie 12 sur les N1 , N2 et N3, en une couche applic N4 et une couche applicative 16 sur le N5.
On notera que le terme poste ou station utilisé ici doit être interprété de manière générale, et comme désignant des éléments informatiques du réseau sur lesquels tournent des applications ou des programmes de serveur, ou les deux.
Le gestionnaire de système de fichiers 4 est réalisé en un système de fichiers réparti 18, et deux systèmes de fichiers non répartis 20 et 22. Le système 18 est réparti sur les N1, N2 et N3 et définit l'ensemble des fichiers accessibles depuis la couche applicative répartie 12. Les systèm es de fichiers 20 et 22 définissent respectivement l'ensemble des fichiers accessibles depuis les couches applicatives 14 et 16.
Les fichiers désignés par les systèmes de fichiers 18, 20 et 22 sont stockés dans un espace de stockage virtuel 24 qui est réparti sur l'ensemble des Ni avec i variant entre 1 et 5. L'espace de stockage virtuel 24 est ici réparti en un espace logique partagé 26, et deux espaces logiques privés 28 et 30.
L'espace logique partagé 26 correspond à l'espace accessible depuis la couche applicative répartie 12 au moyen du système de fichiers réparti 18, et les espaces logiques privés 28 et 30 à l'espace accessible depuis les couches applicatives 14 et 16 au moyen des systèmes de fichiers 20 et 22.
L'espace logique 26 est réparti sur les N1 , N2 et N3, l'espace logique privé 28 sur les N3 et N4, et l'espace logique privé 30 sur le N5. Ainsi, une application de la couche 12 (resf: données stockées dans l'espace logique 26 (reî du système de fichiers 18 (respectivement 20, 22), bien que celle pas forcément physiquement présentes sur l'un des disques de S- station 10 qui utilise cette application.
Par ailleurs, les espaces 26, 28 et 30 sont purement logiques, c'est ne représentent pas directement des espaces de stockage physiques. Les espaces logiques sont cartographiés au moyen d'adresses virtuelles qui sont référencées ou contenues dans les systèmes de fichiers 18, 20 et 22.
Pour accéder aux données de ces fichiers, il est nécessaire de faire appel à un module de correspondance. Le module de correspondance contient une table de correspondance entre les adresses virtuelles des données dans les espaces logiques et des adresses physiques qui désignent le; espaces de stockage physiques dans lesquels ces données sont réellement stockées.
Plusieurs réalisations sont possibles pour le module de correspondance. La répartition des espaces de stockage physiques décrite ici est un exemple destiné à montrer la portée très générale de l'invention.
Comme on peut le voir dans l'exemple présenté, chaque station est utilisée à la fois pour la couche applicative et pour la couche de stockage. Cette multifonctionnalité permet d'utiliser l'espace libre sur l'ensemble des stations du réseau, plutôt que laisser cet espace inoccupé.
Dans le cadre de l'invention, il serait cependant possible de spécialiser certaines des stations, et de créer un nœud dédié au stockage ou un noeud dédié à des applications. Cela signifie que, dans le cadre de l'invention, de nœud applicatif, un rôle de nœud stockant, fois.
L'ensemble des ressources applicatives, de stockage et de systè peuvent être intégrées localement sur chaque station, ou bien ré stations du réseau.
C'est par exemple le cas des stations N1 , N2 et N3, dont les ressources sont intégralement réparties, tant au niveau applicatif qu'au niveau du système de fichiers et du stockage.
La figure 3 représente un exemple d'architecture d'une station 10 de la figure 2. La station représentée dans cet exemple peut représenter l'une des stations N1 , N2 ou N3.
La station Nx présente individuellement une structure semblable à celle de la structure globale représentée sur la figure 1. Elle comporte ainsi une couche applicative 32, un système de fichiers 34, une couche de virtualisation 36 et un espace de stockage 38 sous la forme d'une mémoire locale à accès direct.
La couche de virtualisation 36 comporte un moteur 40 et une table de correspondance 42. L'accès direct à l'espace de stockage 38 est géré par un client de stockage 44 et un serveur de stockage 46. Les rôles et les fonctionnements de ces éléments seront précisés plus bas.
L'exemple décrit ici représente un mode de réalisation perfectionné de l'invention, dans lequel toutes les ressources, tant applicatives que de stockage, sont réparties sur le réseau.
Cela signifie par exemple que le système de fichiers 34 n'est pas intégralement présent sur cette station, mais réparti sur plusieurs d'entre elles, et que l'accès à celui-ci implique la communication avec d contiennent les données recherchées.
Il en est de même pour la couche de virtualisation 36, le client d< et le serveur de stockage 46. La répartition de ces éléments moyen d'un module d'administration 48.
Pour la suite de la description, il importe peu que les ressources considérées soient réparties ou pas.
Le module d'administration 48 est principalement utilisé lors de la création et de la mise à jour des espaces logiques. Lors de la création ou de la modification d'un espace logique, le module d'administration 48 appelle la couche de virtualisation 36 pour créer la table de correspondance entre chaque adresse virtuelle de l'espace logique et une adresse physique si r un nœud de stockage donné.
Ensuite, les correspondances entre un fichier accessible par ce système de fichiers et les adresses virtuelles des données qui composent ce fichier sont réalisées au niveau du système de fichiers qui exploite cet espace logique, les données "physiques" étant stockées aux adresses physiques associées dans la table de correspondance aux adresses virtuelles, conformément à la cartographie établie lors de la création de l'espace logique.
Cela signifie que, dès la création d'un espace logique par le module d'administration, les correspondances entre les adresses virtuelles et les adresses physiques sont établies. Les adresses virtuelles apparaissent ainsi "vides" au système de fichier accédant à l'espace logique, bien que les adresses physiques qui leur correspondent soient déjà "réservées" par le biais de la table de correspondance. C'est lorsque le lien entre les données des adresses virtuelles de ces données est établi qi remplies.
Dans le mode de réalisation décrit ici, la table de correspondar tableau qui contient des informations permettant de r correspondances. Lorsqu'une application fait appel à un esp donné, le moteur 40 interagit avec la table 42 pour établir l'adresse physique correspondante.
Comme cela apparaîtra mieux par la suite, la table de correspondance 42 ne contient pas la totalité des correspondances, mais seulement un jeu d'informations nettement plus restreint, suffisant à rétablir extrêmement rapidement la correspondance.
Afin de mieux comprendre l'invention, il convient de bien différencier la couche applicative de la couche de stockage. En effet, la gestion de l'accès aux données stockées dans la couche de stockage est une approche qui présente de nombreux avantages par rapport à l'existant.
La figure 4 représente un procédé mis en œuvre par le système pour accéder à un fichier.
L'accès à un fichier par une application de la couche applicative d'un nœud donné est initialisé par une requête d'accès fichier 50. La requête d'accès fichier 50 comporte :
- un identifiant du fichier concerné pour le système de fichiers et une adresse dans ce fichier,
- la taille de la requête, c'est-à-dire le nombre de bits à accéder à la suite de l'adresse du fichier visé, et
- le type de requête, à savoir la lecture ou l'écriture. Dans une étape 52, le système de fichiers déter virtuelles pour les données de ce fichier, et géi d'accès virtuel sur la base de Ia requête 50 et de ces adresses virti
Les requêtes d'accès virtuel comportent chacune :
- l'adresse virtuelle visée,
- la taille de la requête, c'est-à-dire le nombre de bits à accéder l'adresse virtuelle visée, et
- le type de requête, qui est identique à celui de la requête 50.
Si l'on se rapporte au système décrit sur la figure 2, l'étape 52 consiste à déterminer l'espace logique et la ou les adresses virtuelles sur cet espace désignées par la requête 50, et à produire une ou plusieurs requêtes "virtuelles".
II existe une différence de niveau entre les requêtes d'accès fichiers et les requêtes d'accès virtuel. En effet, une requête d'accès fichier va viser le contenu d'une quantité importante d'adresses virtuelles, afin de permettre de reconstituer le contenu d'un fichier, alors qu'une requête virtuelle vise le contenu d'un bloc de données associé à cette adresse.
La ou les requêtes d'accès virtuel obtenues sont alors transmises à la couche de virtualisation, qui détermine la ou les adresses physiques et les espaces de stockage correspondants dans une étape 54.
Pour déterminer les adresses physiques, la couche de virtualisation opère en utilisant le moteur 40 et la table de correspondance 42.
Dans le cadre d'une requête d'accès en lecture, le fichier recherché existe déjà dans un espace de stockage 38, et le moteur 40 appelle la table de correspondance 42 avec la ou les adresses virtuelles pour déterminer par correspondance la ou les adresses physiques des données du fichier. Dans le cadre d'une requête d'accès en é< forcément de manière préalable dans un espac comme on l'a vu plus haut, les correspondances entre adresses adresses physiques sont figées, et le moteur 40 opère donc manière que dans le cadre d'une requête en lecture pour déterm adresses physiques des données.
Dans tous les cas, une fois que le moteur 40 a déterminé les adresses physiques, il génère dans une étape 56 des requêtes d'accès physique qu'il transmet au client de stockage 44.
Dans l'étape 56, les requêtes d'accès physique sont générées sur la base de la requête 50 et de la ou des adresses physiques déterminées à l'étape 54.
Ces requêtes comportent :
- l'adresse physique visée ;
- la taille de la requête, c'est-à-dire le nombre de bits à accéder à la suite de l'adresse physique visée par la requête ; et
- le type d'action visée, à savoir la lecture ou l'écriture.
L'adresse physique et la taille de la requête sont obtenues directement de l'étape 54, et le type de la requête est hérité du type de la requête d'accès virtuel concernée.
Une boucle est alors lancée, dans laquelle une condition d'arrêt 58 est atteinte lorsqu'une requête d'accès physique a été émise au client de stockage 44 pour toutes les adresses physiques obtenues à l'étape 52.
En fait, chaque requête d'accès physique est placée dans une file d'attente de requête du client de stockage 44 pour exécution dans une étape 60. Le client de stockage 44 peut optionnellement comporter plusieurs files d'attente, par exemple une file d'attente par serveur de stockage 46 avec lequel il interagit. Dans cette boucle, toutes les requêtes d'accè représentées comme exécutées successivemen Cependant, l'exécution peut également être réalisée en paré seulement en série.
Dans l'exemple décrit, des requêtes sont transmises de couch jusqu'à la couche d'accès physique. Il serait cependant possible et de transmettre uniquement des adresses (virtuelles puis physiques), et de récupérer, au niveau de la couche physique, des propriétés choisies de la requête de fichier initiale pour former les requêtes d'accès physique.
Pour l'exécution d'une requête d'accès physique donnée, le client de stockage 44 interagit avec le serveur de stockage 46 de la station de stockage qui contient l'espace de stockage 38 sur lequel est située l'adresse physique désignée par la requête d'accès physique concernée.
La figure 5 représente un exemple de réalisation de la couche de virtualisation 36 de la figure 3.
Le moteur 40 comporte une file d'attente 402, une unité de détermination d'adresse 404 et une unité de recouvrement 406.
La file d'attente 402 reçoit toutes les requêtes d'accès virtuel pour la détermination des adresses physiques correspondantes. La détermination des adresses physiques est réalisée par l'unité de détermination d'adresse 404, en collaboration avec la table de correspondance 42.
Dans l'exemple décrit ici, la table de correspondance 42 ne contient qu'un jeu extrêmement restreint de données qui seront décrites par la suite. En effet, l'invention propose plusieurs schémas d'attribution d'espaces virtuels aux espaces physiques. Ces attributions permettent de déterminer rapidement et à moindre coût les correspondances adresse virtuelle / adresse physique sur la base d'algorithmes légers tout en offrant une qu; beaucoup plus performant en termes d'occupat l'utilisation d'une table de correspondance directe telle une "look- anglais).
L'unité de recouvrement 406 a pour fonction la mise à jour adresses physiques lorsqu'un espace de stockage d'une stati cessé de fonctionner, comme cela sera décrit plus bas.
La figure 6 illustre un premier schéma d'attribution d'espaces virtuels aux espaces physiques de manière à tolérer des pannes dites corrélées. Par panne corrélée, on entend une panne qui rend inopérant un ensemble d'espaces ou unités de stockage (ci-après disques) reliés entre eux (ci-après groupe de défaillance).
Dans d'autres modes de réalisation, on peut regrouper les disques par groupe de défaillance sur la base d'un critère de dépendance de panne. Un tel critère de dépendance de panne vise à rassembler entre eux des disques pour lesquels la probabilité d'une panne simultanée est importante, de manière à s'assurer que les données de ces disques ne sont pas répliquées sur l'un d'entre eux.
Comme exemple de critère de dépendance de panne, on peut citer l'appartenance à une même station-noeud, tant d'un point de vue matériel que logiciel, la liaison à un même nœud de réseau, tant d'un point de vue matériel que logiciel, la proximité de situation géographique, etc.
Pour prévenir de telles pannes, l'attribution d'espace virtuels aux espaces physiques est réalisée de sorte que : - les données d'une adresse virtuelle sont stockées sur des disques qui appartiennent à des groupes de défaillance distincts ; et - les données d'adresses virtuelles consécutivi hachures qui s'étendent sur tous les disques.
Ainsi, sur l'exemple représenté, on part de quatre nœuds N1 à N4 comporte ici trois disques MU11 , MU 12 et MU 13, le nœud N2 MU21, MU22 et MU23, le nœud N3 un disque MU31, et le n disques MU41 , MU42 et MU43.
Dans l'exemple décrit ici, chaque nœud forme un groupe de défaillance, c'est-à- dire que, en termes de panne, on considère que les disques d'un nœud dépendent de celui-ci, mais que les disques de nœuds distincts sont indépendants les uns des autres.
Le groupe de défaillance N1 est donc composé des disques MU11 à MU13, le groupe de défaillance N2 est composé des disques M J21 à MU23, le groupe de défaillance N3 est composé du disque MU31 , et le groupe de défaillance N4 est composé des disques MU41 à MU43.
Dans d'autres modes de réalisation, on pourrait définir les groupes de défaillances de manière différente, par exemple par appartenance à une unité de réseau. Il est donc important de comprendre que les disques sont d'abord regroupés par groupe de défaillance et non seulement par nœud.
Dans un premier temps, l'attribution représentée sur la figure 6 part des groupes de défaillances pour définir des groupes de réplication qui permettent une duplication sûre des données.
L'affectation des disques des groupes de défaillance à un groupe de réplication suit un algorithme d'attribution qui met en œuvre les contraintes décrites plus haut. Pour tenir compte de la première contrainte, moins autant de groupes de réplication qu'il y i défaillance qui a le plus grand nombre de disques, conformémei
10 de l'Annexe A.
Ensuite, afin d'effectuer une répartition la plus souple possible charge, on fixe le nombre de disques par groupe de réplication s<
11 de l'Annexe A. Enfin, les disques sont attribués individuellement dans chaque groupe de réplication selon l'équation 12 de l'Annexe A.
Ainsi, dans l'exemple de la figure 6, le groupe de réplication GR1 comprend quatre disques qui correspondent respectivement aux disques MU11 , MU21 , MU31 et MU43, et les autres disques MU12 et MU13 du groupe de défaillance N1 sont respectivement affectés aux groupes GR2 et GR3.
D'autres algorithmes d'attribution des disques sont possibles, comme l'homme du métier le reconnaîtra. On notera par exemple que, pour l'attribution des disques aux groupes de réplication, il serait également possible de prendre en compte l'espace disponible sur les disques, de manière à assurer des groupes de réplication de taille homogène. Une autre possibilité serait de prendre en compte leur performance pour obtenir des groupes de réplication de performance homogène.
Cela pourrait par exemple être réalisé : * lors de l'attribution des disques aux groupes de réplication, en compliquant l'algorithme, ou
* après l'attribution décrite plus haut, en effectuant des échanges de disques entre groupes de réplication.
Dans un deuxième temps, pour tenir compte de la deuxième contrainte, les adresses virtuelles sont attribuées sur les disques triés par groupe de réplication. Dans chaque disque représenté, chε signifie l'association d'adresses virtuelles à des ε
En effet, les adresses virtuelles sont réunies par ordre croissant hachurage ("striping unit" en anglais) de tailles définies. Lc hachurage sont elles même associées avec des adresses phys disques.
Comme on peut Ie voir dans la partie supérieure de la figure 6, les unités de hachurage sont affectées sur tous les disques de tous les groupes de réplication par ordre croissant, ligne par ligne. Les adresses virtuelles sont ainsi affectées par bloc aux groupes de réplication, de manière croissante.
Ainsi, la première unité de hachurage du premier disque du premier groupe de réplication reçoit l'indice 0, la première unité de hachurε ge du deuxième disque du premier groupe de réplication reçoit l'indice 1 , etc.
Une ligne d'unités de hachurage sera par la suite appelée hachure réelle. On remarque également dans la partie supérieure de la figure 6 que, pour une ligne sur deux, les unités de hachurage ne sont pas ordonnées par indice croissant.
Cela est du au fait que, pour tenir compte de la première contrainte, les données de chaque hachure réelle sont répliquées au sein du groupe de réplication auquel la première version est affectée. De ce fait, on associe des hachures réelles correspondantes par paires pour former à chaque fois une hachure principale.
Pour déterminer l'attribution des unités de hachurage pour la réplication, on utilise une équation qui assure que : * deux répliques d'une même unité de hachurage ne sont pas stockées sur le même disque, et que * le décalage qui est réalisé à cet effet n'es lorsqu'un disque donné tombe en panne, la ch disques.
Ainsi, dans l'exemple représenté sur la figure 6, les adresses disque MU11 de N1 reçoivent les unités de hachurage suivantes 20, 21 , 30, 33, 40 et 42.
En outre, dans l'exemple décrit ici, les données sont répliquées sur des hachures réelles directement consécutives au sein de la hachure principale. Dans d'autres modes de réalisation, les données répliquées pourraient l'être dans des hachures réelles non consécutives.
Comme on peut le voir de ce qui précède, il suffit donc de connaître le nombre total de disques ainsi que le nombre de groupes de rép lication pour déterminer une adresse physique à partir d'une adresse virtuelle.
La table de correspondance 42 est donc réduite à sa plus simple expression. On notera par ailleurs que, du fait de la réplication de données mentionnée plus haut, il y a deux fois plus d'adresses physiques que d'adresses virtuelles.
Dans l'exemple présenté sur la figure 6, ainsi que dans la suite de ce document, on réalise une réplication simple des données, ce qui a pour résultat de doubler la quantité de données stockées. Cependant, il serait possible de réaliser plus de deux répliques des données.
La figure 7 montre l'exemple d'une fonction qui permet de retrouver une adresse physique à partir d'une adresse virtuelle.
Dans l'exemple décrit ici, cette fonction est implémentée dans l'unité de détermination d'adresse 404. Elle part dans une opération 2000 d'une adresse virtuelle, par exemple tirée de la file d'attente 402. Dans une opération 2020, un test est réalis< virtuelle est reliée à une requête en écriture. Si 2040, un test est réalisé pour déterminer si le système est en c'est-à-dire si l'un des disques est en panne. Si c'est le cas, Wrt_Drt_Z() est appelée en 2060.
Les opérations 2040, 2060 et 2080 sont reliées à des fonctions récupération rapide d'une panne de disque qui sera décrite plus avant avec les figures 9 et 10.
Dans le cas où la requête associée à l'adresse virtuelle est une requête de lecture, ou lorsque l'état du système est non dégradé, ou encore lorsque la fonction Wrt_Drt_Z() s'achève, une fonction SU_lnd() est appelée dans une opération 2070.
La fonction SU_lnd() part de l'adresse virtuelle dont on cherche la correspondance, et retourne l'indice d'unité de hachurage SU Ind. qui lui est associé. Cela est aisément réalisable comme la taille de chaque unité de hachurage est connue.
Sur la base de cet indice, une fonction Get_Phy_lnd() est appelée dans une opération 2080 qui détermine des indices d'adresses physiques correspondants.
Enfin, dans une opération 2100, les indices d'adresses physiques sont convertis en adresses physiques par une fonction Phy_Ad(). Cela est aisément réalisable comme la taille de chaque unité de hachurage est connue.
La fonction Get_Phy_lnd() va maintenant être décrite avec la figure 8. La fonction Get_Phy_lnd() reçoit les deux arguments suivants (opération 2082) : * l'indice de l'unité de hachurage dont on cherche la correspondance, et * un tableau Ngr[] contenant une ligne dont les disques pour chaque groupe de réplication.
Le tableau Ngr[] est utile car il permet de retrouver rapidement le de disques N et le nombre de groupe de réplication Ngr, et d'accé rapidement au nombre de disques par groupe de réplication.
Dans une autre implémentation, il est possible de passer directement IM ex Ngr en tant qu'arguments, mais un calcul est alors nécessaire lorsque l'on a besoin du nombre de disques au sein d'un groupe de réplication donné.
Le rôle de la fonction Get_Phy_lnd() est de retrouver l'indice de l'unité de hachurage dans le tri par groupe de défaillance à partir de son indice dans le tri par groupe de réplication. Dans une première opération 2084, une fonction Strip() détermine un indice de hachure principale k, air si que l'indice m1 dans les groupes de réplication du premier disque sur lequel l'adresse virtuelle est stockée. Cela est réalisé en appliquant les équations 20 et 21 de l'Annexe A.
Dans une opération 2086, une fonction Repl() détermine les indices de hachure réelle k1 et k2 pour tenir compte de la réplication des données. Cela est réalisé en appliquant les équations 22 et 23 de l'Annexe A.
Dans une opération 2088, une fonction Spl() détermine l'indice p du groupe de réplication qui correspond à l'indice de disque m1 , ainsi que l'indice q1 du disque m1 au sein de ce groupe de réplication. Cela est réalisé en appliquant les équations 24 et 25 de l'Annexe A.
Dans une opération 2090, une fonction Shft() détermine un indice q2 au sein du groupe de réplication d'indice p du disque sur lequel les données répliquées sont stockées. Cela est réalisé en appliquant l'équation 26 de l'Annexe A. D'autres équations seraient bien évidemment décalage d'indice d'unité de hachurage. Dans disque au sein d'un groupe de réplication contient toutes répliquées d'un autre disque du même groupe.
Dans une opération 2097, une fonction Mrg() détermine un indice qui correspond à l'indice q2 au sein du groupe de réplication d'indi réalisé en appliquant l'équation 27 de l'Annexe A.
Dans une opération 2098, les indices m1 et m2 des disques classés par groupe de réplication sont convertis en indices de disques ni et n2 des disques classés par groupe de défaillance par une fonction Get_Dsk_lnd(). Cette fonction réalise l'opération inverse de l'équation 12 et applique les équations 28 et 29 de l'Annexe A.
Enfin, la fonction Get_Phy_lnd() retourne les indices adresses physiques déterminées dans une opération 2099.
Maintenant, la fonction Wrt_Drt_Z() va être décrite en rapport avec les figures 9 et 10. Comme mentionné plus haut, l'invention repose en partie sur la réplication des données en cas de panne. La fonction WrtJDrt_Z() ainsi que la fonction décrite avec la figure 9 permettent une réintégration rapide d'un disque après une panne. Cette réintégration est décrite avec la figure 10.
Le principe de cette réintégration repose sur le marquage des zones virtuelles associées à un disque en panne lors d'une écriture.
En effet, aussi bien lors d'une requête en lecture que lors d'une absence d'accès, les données stockées ne sont pas modifiées. Dès lors, lorsqu'un disque revient d'une panne, il n'est pas nécessaire de mettre à jour ces données puisqu'elles n'ont pas été modifiées. En revanche, s'il y a eu écriture, les données distinctes, et il faut rétablir la cohérence avec la l'écriture.
Pour cela, deux tables sont maintenues pendant l'exécution. La pr dite de pannes, contient deux lignes, dont l'une reçoit des ic disques et l'autre reçoit un indice croissant. La deuxième table, d contient deux lignes, dont l'une reçoit des identifiants de zones, et ol'autre reçoit un indice de modification.
Dans l'exemple décrit ici, la table de pannes est stockée sur chacun des disques dans un espace réservé par le module d'administration qui n'est pas utilisable pour le stockage des données. Cette table est maintenue cohérente sur l'ensemble des disques par le module d'administration. Cette table a une taille fixée égale au nombre total de disques. La table de pannes est remplie au moyen de la fonction représentée sur la figure 9.
Ainsi, lorsqu'une panne est détectée, par exemple par le module d'administration 48 (opération 2200), cette fonction reçoit les identifiants de tous les disques en panne.
Dans une opération 2202, une fonction ls_Tgd_Dsk() cherche chacun des identifiants de disque en panne dans la table de pannes.
Pour chaque identifiant absent, la table de pannes crée une nouvelle entrée qui reçoit l'identifiant de disque dans la première ligne, et un indice incrémenté dans la seconde ligne (opération 2204). Sinon la fonction traite l'identifiant suivant (opération 2206).
En variante, la table de pannes est implémentée sous la forme d'une pile ou d'une liste chaînée. Dès lors, elle ne comporte qu'une ligne qui reçoit les indices de disques, et c'est l'indice de position de chac sert d'indice croissant.
La fonction Wrt_Drt_Z() se base sur les indices de la table de maintenir une vue à jour des zones associées à un disque en pan modifiées.
Ainsi, comme on l'a vu plus haut, la fonction Wrt_Drt_Z() est appelée pour chaque requête en écriture, et elle a pour fonction de marquer dans la table de zones l'indice le plus élevé de la table de pannes.
Ainsi, lorsqu'une zone a un indice supérieur ou égal à celui d'un disque de la table de pannes, cela signifie que celle-ci a été modifiée après la panne du disque considéré.
Sur cette base, l'unité de recouvrement 406 peut exécuter la fonction de la figure 10 pour rétablir un disque après une panne. Pour cela, l'unité 406 part d'un indice i mis à zéro (opération 2300) et parcourt la table de zones.
A chaque fois, une comparaison entre l'indice associé au disque qu'on rétablit dans la table de pannes et celui de la zone d'indice i dans la table de zones indique si la zone a été modifiée après la panne du disque considéré (opération 2302).
Si oui, alors une fonction Upd_Z(i) met à jour les données de la zone concernée en récupérant les données répliquées qui lui correspondent (opération 2304). Ensuite, la table de zones est mise à jour pour refléter cette opération (2306).
Une fois la zone d'indice i à jour, une fonction End_Drt_Zone() supprime l'entrée de la table de pannes associée au disque rétabli, et parcourt la table de pannes pour majorer l'indice des zones par le maximum des indices restants. Cela assure une croissance lente des indices e trop grandes.
S'il reste des zones à parcourir, l'indice i est incrémenté (opé Sinon, la fonction se termine dans l'opération 2312.
On notera que la table de zones peut recevoir des zones de taille | En effet, une entrée dans la table de zones est associée à une pluralité d'adresses virtuelles contiguës.
Dans le mode de réalisation décrit ici, cette table est stockée dans la zone des données réservées du volume logique auxquelles appartiennent les adresses virtuelles, c'est-à-dire qu'elle est également répartie sur tous les disques.
On notera que la zone des données réservées du vo urne logique n'est pas extensible indéfiniment. On notera également que l'appel à la table de zones constitue une requête en lecture dans le système.
Il est donc nécessaire de trouver un compromis entre la granularité des données de la table de zones (qui augmente la performance du mécanisme de recouvrement), et le coût qui est associé à la multiplication des requêtes (qui augmente avec la granularité).
On peut voir les fonctions décrites avec les figures 9 et 10 comme des fonctions qui bouclent en parallèle avec l'exécution principale du système. En effet, pour assurer une sécurité maximale des informations, ces fonctions constituent des "interruptions".
Cela signifie que si la condition de leur lancement (disque qui tombe en panne ou disque qui est rétabli) est rencontrée, les requêtes de détermination d'adresse physique en cours d'exécution sont annulées et rejouées après exécution de ces fonctions. Ces fonctions peuvent donc être réalisées dii virtualisation ou dans le module d'administr séparées comme cela est présenté ici, ou en tant que partie ir fonctions présentées plus haut.
La figure 11 représente une attribution des espaces virtuels physiques en variante de celui de la figure 6. Ici, la tolérance au également accrue, cette fois laissant volontairement des espaces libres au sein des groupes de réplication appelés unités de résilience.
Pour des raisons de clarté, on a représenté sur cette figure un seul groupe de réplication qui comprend sept disques. Parmi ces sept disques, on va définir des hachures comprenant quatre unités de hachurage pour le stockage des données, et trois unités de résilience pour la tolérance des pannes.
Comme on le voit sur la figure 11 , les données sont toujours répliquées une fois, selon la même méthode que précédemment, mais il existe également un décalage avec chaque hachure. Ce décalage sert à assurer que tous les espaces laissés libres sont répartis sur l'ensemble des disques, ce qui garantit un meilleur équilibrage de la charge.
Comme pour les unités de hachurage, deux adresses physiques sont associées sur les disques à chaque unité de résilience SpO, Sp1 et Sp2. Sur la figure 11, les adresses physiques associées à la même unité de résilience dans une hachure principale donnée sont référencées de manière identique.
Pour la détermination d'adresse physique avec l'attribution décrite avec la figure 11, la fonction décrite avec la figure 7 reste utilisable, moyennant quelques modifications à la fonction Get_Phy_lnd(). Une telle fonction Get_Phy_lnd() en variante va figure 12. On notera tout d'abord la différence présentée sur la figure 6 et celle présentée sur la figure 11.
Dans le premier cas, les disques sont répartis en plusieurs groupi les pannes corrélées, c'est-à-dire affectant plusieurs disques à la f
Dans le deuxième cas, certaines des unités de hachurage sont utilisées comme espace libre pour palier à une panne d'un ou plusieurs des disques, comme cela apparaîtra mieux plus bas.
Il n'y alors pas a priori de regroupement des disques par groupe de réplication, bien que cela soit possible comme on Ie verra avec la figure 15.
La définition des unités de résilience en plus des unités de hachurage revient à répartir une partie des adresses physiques en un groupe de travail (celles qui reçoivent les données des unités de hachurage) d'une part, et en des groupes de panne (celles qui reçoivent les données des unités de résilience) d'autre part, en fonction d'un critère de tolérance de panne.
Un tel critère de tolérance de panne porte par exemple sur le nombre de pannes successives que l'on souhaite supporter, et donc le nombre de groupes de panne à gérer. Dans l'exemple présent, ce nombre est de trois. D'autres critères pourraient néanmoins être employés.
Dans l'exemple de la figure 12, la fonction Get_Phy_lnd () peut être vue comme deux blocs successifs :
* un bloc de traitement A pour déterminer les indices de disque et de hachure comme précédemment, sans tenir compte de la présence des unités de résilience, et
* un bloc B qui traite les indices ainsi calculés pour tenir compte de la présence des unités de résilience et obtenir les indices réels. La fonction Get_Phy_lnd() reçoit les trois argume
* l'indice de l'unité de hachurage dont on cherche
* le nombre de disques dans le système, et
* le nombre d'unités de résilience.
Dans une première opération 2484, la fonction Strip() détermine hachure principal k, ainsi que l'indice mm1 du premier disqi l'adresse virtuelle est stockée.
L'opération 2484 diffère de l'opération 2084 de la figure 8 en ce que la fonction Strip() est appelée avec le nombre d'unités de hachurage, c'est-à-dire le nombre de disques moins le nombre d'unités de résilience.
Dans une opération 2486, la fonction Repl() détermine les indices de hachure réels k1 et k2 pour tenir compte de la réplication des données comme l'opération 2086.
Dans une opération 2490, la fonction Shft() détermine un indice mm2 du disque qui reçoit les données répliquées. L'opération 2490 diffère de l'opération 2090 de la figure 8 en ce que la fonction Shft() est appelée avec le nombre d'unités de hachurage, c'est-à-dire le nombre de disques moins le nombre d'unités de résilience.
Dans une opération 2492, une fonction Cp_Spr() détermine un indice m1 qui correspond à l'indice réel du disque associé à l'indice mm1. Cette fonction sert à modifier l'indice mm1 pour tenir compte de la présence des unités de résilience. Comme on le verra plus bas, l'indice m1 que retourne la fonction Cp_Spr() peut être un indice d'une unité de résilience.
Dans une opération 2494, une fonction Cp_Spr() détermine un indice m2 qui correspond à l'indice réel du disque associé à l'indice mm2. Cette fonction sert à modifier l'indice mm2 pour tenir compte de la présence des unités de résilience. Comme on le verra plus bas, l'indic Cp_Spr() peut être un indice d'une unité de résil
Une fois les indices m1 et m2 déterminés, les indices d'adress sont retournés en 2499.
La fonction Cp_Spr() va maintenant être décrite avec la figure 13. reçoit comme arguments un indice de disque mm, un indice d'unité αe hachurage k, un nombre total de disques N et un nombre d'unités de résilience S. La fonction Cp_Spr() commence par exécuter une fonction Spr() en 2602.
La fonction Spr() implémente l'équation 30 de l'Annexe A. La fonction Spr() reçoit trois arguments en entrée :
* l'indice de disque mm, * l'indice d'unité de hachurage k ;
* le nombre total de disques N.
Comme l'indice mm a été établi sur un nombre N-S de disques, la fonction Spr() permet donc d'établir un indice m qui prend en compte la présence des S unités de résilience.
Ensuite, un test détermine dans une opération 2604 si le disque associé à l'indice réel m est en panne et si une unité de résilience lui a été affectée.
Un exemple de mise en œuvre de la fonction 2604 est la tenue d'une table appelée ici table de résilience. Cette table contient une unique ligne, dans laquelle chaque colonne correspond à un disque d'indice m correspondant au numéro de la colonne.
La valeur stockée dans chaque colonne indique :
* que le disque d'indice m n'est pas en panne, ou * que le disque d'indice m est en panne, et la v, d'unité de résilience qui permet de détermine attribuée l'unité de résilience qui sera associée au disque d'indice
Une telle table de résilience est stockée sur chacun des d synchronisée en permanence, en même temps que la table d exemple.
S'il faut utiliser une unité de résilience, alors l'indice mm est mis à jour dans une opération 2606 par une fonction Spr_2() qui implémente l'équation 31 de l'Annexe A en utilisant comme arguments le nombre total de disques N, le nombre d'unité de résilience S, et l'indice m qui vient d'être calculé.
Cette fonction part du principe que les données du disque d'indice m sont stockées dans chaque hachure sur l'unité de rési ience dont l'indice de résilience est indiqué par la table de résilience, et qu'il suffit donc de connaître l'indice de hachure k pour déterminer l'indice du disque sur lequel l'unité de résilience voulue est attribuée.
Pour cela, après la mise à jour de l'indice mm, la fonction Cp_Spr() est relancée. Ainsi, dans le cas où deux pannes ont lieu successivement, si l'unité de résilience associée à l'un des disques en panne est située sur le deuxième disque en panne, la fonction Cp_Spr() est à nouveau répétée, de sorte que l'indice retourné correspond à une unité de résilience sur un disque fonctionnel.
De cette manière, de multiples pannes peuvent être tolérées, comme les unités de résilience peuvent être utilisées pour remplacer d'autres unités de résilience. Pour maintenir la table de résilience, et pour remplir les adresses physiques associées aux unités de résilience lors d'une panne, une fonction va maintenant être décrite avec la figure 14. Lorsque le système détecte qu'un disque tomb cette fonction reçoit les identifiants de tous les dis
Dans une opération 2702, une fonction Spr_Dsk() modifie l'indice < panne auquel n'est associée aucune unité de résilience. La valeur c de résilience reçoit le premier indice de résilience non déjà attribué.
Ensuite, dans une opération 2704, les données répliquées des unités de hachurage qui étaient situées sur le disque qui est tombé en panne sont recopiées sur les unités de résilience associées au moyen d'une fonction Wrt__Spr_Dsk().
Pour améliorer la performance, la recopie n'est pas immédiatement réalisée : la fonction Wrt_Spr_Dsk() génère des requêtes d'écriture des données disponibles sur l'unité de hachurage restante vers l'unit» ? de résilience, et ces requêtes sont exécutées en concurrence avec les autres requêtes d'accès. Cela signifie que l'unité de résilience ne peut pas être utilisée tant que cette requête d'écriture n'a pas été réalisée. Enfin, la fonction se termine en 2706.
En variante, la fonction Wrt_Spr_Dsk() génère les requêtes d'écriture sur les unités de résilience et exécute ces requêtes avant toute autre requête d'accès. On notera que, lorsque le disque est rétabli, il faut également recopier à nouveau les données répliquées sur celui-ci.
On peut voir la fonction décrite avec la figure 14 comme une fonction qui boucle en parallèle avec l'exécution principale du système. En effet, pour assurer une sécurité maximale des informations, cette fonction constitue une "interruption".
Cela signifie que si la condition de son lancement (disque qui tombe en panne) est rencontrée, les requêtes de détermination d'adresse physique en cours d'exécution sont annulées et rejouées après exécution de cette fonction. Cette fonction peut donc être réalisée dire virtualisation ou dans le module d'administration, en tant qu'ion comme cela est présenté ici, ou en tant que partie intégrante présentées plus haut.
Dans un mode de réalisation avantageux, l'attribution décrite avec celle décrite avec la figure 11 sont mélangées, pour offrir un supi optimal.
Pour la détermination d'adresse physique avec une telle attribution, la fonction décrite avec la figure 7 reste utilisable, moyennant quelques modifications à la fonction Get_Phy_lnd().
Une telle fonction Get_Phy_lnd() en variante va maintenant être décrite avec la figure 15.
La fonction représentée sur la figure 15 est un mélange des variantes de la fonction Get_Phy_lnd() décrite avec les figures 8 et 12. Ainsi, elle présente de grandes similitudes avec celles-ci. C'est pourquoi certaines opérations n'ont pas été renumérotées.
Dans une opération 2482, la fonction Get_Phy_lnd() reçoit les arguments suivants :
* l'indice de l'unité de hachurage dont on cherche la correspondance, * un tableau Ngr[] contenant une ligne dont les valeurs indiquent le nombre de disques pour chaque groupe de réplication, et
* le nombre d'unités de résilience.
Comme pour la figure 8, le tableau Ngr[] est utile car il permet de retrouver rapidement le nombre total de disques N et le nombre de groupe de réplication Ngr, et d'accéder tout aussi rapidement au nombre de disques par groupe de réplication. Dans une autre implémentation, il est possible d en tant qu'arguments, mais un calcul est alors né du nombre de disques au sein d'un groupe de réplication donné.
Les opérations 2484 et 2486 sont ensuite réalisées de manière celles de la figure 12, et l'opération 2488 est réalisée comme l'op de la figure 8.
Ensuite, les opérations 2490 à 2494 sont réalisées comme dans le cas de la figure 12, en tenant compte du fait que cette opération est réalisée au sein d'un groupe de réplication.
Les indices des disques q1 et q2 au sein du groupe de réplication p sont ensuite transformés en indices de disque m1 et m2 dans des opérations 2496 et 2497 de manière analogue à l'opération 2097 de la figi re 8.
Ensuite les indices m1 et m2 des disques classés par groupe de réplication sont convertis en indices de disques ni et n2 des disques classés par groupe de défaillance dans une opération 2498 comme l'opération 2098 de la figure 8.
Enfin, l'opération 2499 est réalisée comme l'opération 2099 de la figure 8, afin de retourner les indices d'adresses physiques.
Ce mode de réalisation est le mode de réalisation est très avantageux, car il offre une très grande tolérance aux diverses pannes, tant grâce à la répartition des données sur des disques appartenant à des groupes de défaillance distincts que grâce à l'utilisation des unités de résilience qui permet de contenir des pannes au sein des groupes de réplication.
En outre, la répartition par hachures décrite dans les modes décrits permet d'obtenir des performances très améliorées, comme les accès sont répartis sur des disques distincts. Les unités de hachurage sont ici décrites comr néanmoins possible d'implémenter l'invention en affectant des hachurage différentes selon les groupes de réplication moyenr modifications aux fonctions décrites.
Le moteur et la table de correspondance décrits ici forment i correspondance capable d'affecter les adresses virtuelles à physiques sur la base d'une règle comportant une formule arithmétique définie par les fonctions ci-dessus.
Bien que dans les modes de réalisation décrits plus haut ces fonctions constituent l'essentiel de la règle d'affectation, il serait possible d'utiliser une règle qui affecte de manière fixe une certaine partie des adresses virtuelles, et qui affecte une autre partie des adresses virtuelles avec les fonctions.
Bien que les modes de réalisations décrits ci-dessus lient la couche de virtualisation à un environnement applicatif en amont et à des disques physiques (ou unité de mémoires locales) en aval, l'homme du métier comprendra bien que la couche de virtualisation présentée ici pourrait être isolée de ces éléments.
Il faut donc envisager cette couche de manière indépendante, comme une brique logique (de virtualisation) au dessus et en dessous de laquelle peuvent être empilées des briques logiques supplémentaires.
Dans ce cadre, l'obtention d'adresses qui sont qualifiées "d'adresse physique" signifie avant tout une désabstraction de la couche de virtualisation. Ces adresses pourraient en effet être elles mêmes des adresses virtuelles d'un espace logique d'un serveur de stockage. De la même façon, les adresses virtuelles reçues en amont pourraient elles même correspondre à une désabstraction d'une couche de virtualisation supérieure. L'application qui accède aux données stockées gère les relations entre les divers éléments t système de fichiers, l'interaction système de fichiers - correspondance, l'interaction module de correspondance - client implémentation de la stratégie du serveur de stockage en obtenai élément un résultat et en appelant l'élément suivant avec ce rés forme modifiée de ce résultat).
En variante, le système est autonome et ne dépend pas de l'application qui appelle les données, et les éléments sont capables de communiquer entre eux, de sorte que l'information descend puis remonte les couches d'élément en élément.
De même, les communications entre ces éléments peuvent être assurées de différentes manières, par exemple au moyen de l'i <τterface POSIX, des protocoles IP, TCP, UDP, d'une mémoire partagée, d'une RDMA (Remote Direct Access Memory). Il convient de garder à l'esprit que le but de l'invention est d'offrir les avantages de systèmes de stockage spécialisés sur la base des ressources réseaux existantes.
Un exemple de réalisation du système décrit ci-dessus est basé sur un réseau dans lequel les stations sont réalisées avec des ordinateurs comprenant :
* un processeur spécialisé ou généraliste (par exemple du type CISC ou RISC ou autre), * un ou plusieurs disques de stockage (par exemple des disques durs à interface Sériai ATA, ou SCSI, ou autre) ou tout autre type de stockage, et
* une interface réseau (par exemple Gigabit, Ethernet, Infiniband, SCI...)
* un environnement d'application basé sur un système d'exploitation (par exemple Linux) pour supporter des applications et offrir un gestionnaire de système de fichiers, * un ensemble applicatif pour réaliser le mo exemple le module Clustered Logical Vol u m e
Exanodes (marque déposée) de la société Seanodes (marque dépi
* un ensemble applicatif pour réaliser le client de stockage et Ii stockage de chaque NBD, par exemple le module Exanodes U
Device de l'application Exanodes (marque déposée) de la socié (marque déposée),
* un ensemble applicatif pour gérer les éléments répartis, par exemple le module Exanodes Clustered Service Manager de l'application Exanodes (marque déposée) de la société Seanodes (marque déposée). Ce type de système peut être réalisé dans un réseau comportant :
* des stations utilisateurs classiques, adaptées à un usage applicatif sur un réseau et qui jouent le rôle de nœuds applicatifs, et
* un ensemble de dispositifs informatiques réalisés conformément à ce qui précède, et qui jouent le rôle de serveurs du réseau et de noeuds de stockage.
D'autres matériels et applications apparaîtront à l'homme du métier pour réaliser des dispositifs en variante dans le cadre de l'invention.
L'invention englobe le système informatique comprenant les noeuds applicatifs et les nœuds stockant dans leur ensemble. Elle englobe également les éléments individuels de ce système informatique, et notamment les nœuds applicatifs et les nœuds stockants dans leur individualité, ainsi que les divers moyens pour les réaliser.
De même, le procédé de gestion de données est à considérer dans sa globalité, c'est-à-dire dans l'interaction des nœuds applicatifs et des nœuds stockants, mais également dans l'individualité des postes informatiques adaptés pour réaliser les nœuds applicatifs et les nœuds stockants de ce procédé.
La description qui précède a pour but de décrire un mode de réalisation particulier de l'invention. Elle ne saurait être considérée comme limitant ou décrivant celle-ci de manière limitative, et couv combinaisons entre elles des caractéristiques des
L'invention couvre également un procédé de stockage de données la détermination d'au moins une première et une deuxième ; stockage à partir d'une adresse virtuelle reçue en entrée, les stockages étant associées à des unités de stockage, et le stockage associées à ladite adresse virtuelle dans lesdites première et deuxième adresses de stockages déterminées, le procédé étant caractérisé en ce que : * au moins une partie des adresses de stockage sont réparties en un groupe de travail et un nombre choisi de groupes de panne, sur la base d'un critère de tolérance de panne, sur la base d'une règle assurant qu'au moins une des unités de stockage comporte des adresses de stockage associées au groupe de travail et des adresses de stockage associées à au moins un groupe de panne ;
* ladite détermination comprend l'affectation par blocs d'au moins une partie des adresses virtuelles, à des adresses de stockage appartenant au groupe de travail, en réalisant un hachurage des adresses virtuelles sur le groupe de travail, * une table de résilience est maintenue, ladite table de résilience comprenant des entrées associant chacune un groupe de panne et une unité de stockage, en fonction d'un état de panne de cette unité de stockage, et
* ladite détermination comprend, en cas de panne d'une unité de stockage, l'affectation d'au moins une partie des adresses virtuelles associées aux adresses de stockage sur cette unité de stockage, à des adresses de stockage appartenant à un groupe de panne auquel cette unité de stockage est associée dans la table de résilience.
Le procédé peut être en outre caractérisé en ce que : * au moins une partie des unités de stockage sont réparties en groupes de réplication, sur la base d'un critère de dépendance de panne, en ce qu'au moins une partie des adresses de stockage dans chaque grouoe de réplication sont réparties en un groupe de travail et en un panne, sur la base d'un critère de tolérance d détermination comprend l'affectation par blocs d'au moins une adresses virtuelles, à des adresses de stockage du groupe de tr sur des unités de stockage d'un même groupe de réplication, en hachurage des adresses virtuelles sur le groupe de réplication, e panne d'une unité de stockage, au moins une partie des adress associées aux adresses de stockage sur cette unité de stockage, sont affectées à des adresses de stockage appartenant à un groupe de panne du groupe de réplication concerné, en fonction de cette panne ;
* les blocs d'adresses virtuelles consécutifs sont affectés en réalisant un hachurage des adresses virtuelles qu'ils contiennent sur toutes les unités de stockages ;
* pour un bloc d'adresses virtuelles affecté à un groupe de réplication donné, les adresses de stockage correspondantes sont réparties sur toutes les unités de stockage du groupe de réplication donné en réalisant un hachurage ;
* pour deux blocs d'adresses virtuelles affectés consécutivement à un groupe de réplication donné, les premières adresses de stockage associées à chaque bloc sont affectées en réalisant un hachurage sur toutes les unités de stockage du groupe de réplication donné, et les deuxièmes adresses de stockage sont affectées sur toutes les unités de stockage du groupe de réplication donné en réalisant un hachurage propre à chaque bloc ;
* ladite répartition des unités de stockage en groupes de réplication est basée sur une formule arithmétique choisie ; * ladite formule arithmétique est agencée pour définir un nombre de groupes de réplication supérieur ou égal au nombre maximum d'unités de stockage dépendantes selon le critère de dépendance de panne ;
* la formule arithmétique part d'une répartition des unités de stockages dépendantes selon le critère de dépendance de panne en groupes de défaillance, et affecte chaque unité de stockage de chaque groupe de défaillance à un groupe de réplication distinct ; et * la répartition des adresses de stockage groupes de panne est basée sur une formule arithmétique choi
L'invention couvre également, en tant que produits, les éléments décrits, mis à disposition sous tout "médium" (support) lilsible L'expression "médium lisible par ordinateur" comprend stockage de données, magnétiques, optiques et/ou électroniques, aussiu bien qu'un support ou véhicule de transmission, comme un signal analogique ou numérique.
ANNEXE A
SECTION 1
Figure imgf000039_0001
SECTION 2
Figure imgf000039_0002
ANNEXE A (suite)
SECTION 2 (suite)
Figure imgf000040_0001
SECTION 3
Figure imgf000040_0002

Claims

Revendications
1. Outil informatique de stockage de données comprenant un correspondance (40) relié à des unités de stockage (38), ledit correspondance (40) comprenant une fonction de correspondant déterminer au moins une première et une deuxième adresses de partir d'une adresse virtuelle reçue en entrée (402), caractérisé en c
* l'outil comporte une règle pour répartir au moins une partie des adresses de stockage en un groupe de travail et un nombre choisi de groupes de panne, sur la base d'un critère de tolérance de panne, ladite règle prévoyant qu'au moins une des unités de stockages comporte des adresses de stockage associées au groupe de travail et des adresses de stockage associées à au moins un groupe de panne,
* l'outil maintient en outre une table de résilience comprenant des entrées associant chacune un groupe de panne et une unité de stockage, en fonction d'un état de panne de cette unité de stockage,
* ladite fonction de correspondance est agencée pour affecter par blocs au moins une partie des adresses virtuelles, à des adresses de stockage appartenant au groupe de travail, en réalisant un hachurage des adresses virtuelles sur le groupe de travail, et
* ladite fonction de correspondance est agencée pour affecter, en cas de panne d'une unité de stockage, au moins une partie des adresses virtuelles associées aux adresses de stockage sur cette unité de stockage, à des adresses de stockage appartenant à un groupe de panne auquel l'unité de stockage en panne est associée dans la table de résilience.
2. Outil informatique selon la revendication 1 , caractérisé en ce que la fonction de correspondance est agencée pour : * répartir au moins une partie des unités de stockage en groupes de réplication, sur la base d'un critère de dépendance de panne, * répartir au moins une partie des adresses de s de réplication en un groupe de travail et en un panne, sur la base d'un critère de tolérance de panne, pour
* affecter par blocs au moins une partie des adresses virtuelles, à ci de stockage du groupe de travail situées sur des unités de stockage groupe de réplication, en réalisant un hachurage des adresses viri groupe de réplication, et pour
* affecter, en cas de panne d'une unité de stockage, au moins une partie des adresses virtuelles associées aux adresses de stockage sur cette unité de stockage, à des adresses de stockage appartenant à un groupe de panne du groupe de réplication concerné, en fonction de cette panne.
3. Outil informatique selon la revendication 2, caractérisé en ce que la fonction de correspondance est agencée pour affecter les blocs d'adresses virtuelles consécutifs en réalisant un hachurage sur toutes les uniti ss de stockages.
4. Outil informatique selon la revendication 2 ou 3, caractérisé en ce que la fonction de correspondance est agencée, pour un bloc d'adresses virtuelles affecté à un groupe de réplication donné, pour répartir les adresses de stockage correspondantes sur toutes les unités de stockage du groupe de réplication donné en réalisant un hachurage.
5. Outil informatique selon la revendication 4, caractérisé en ce que la fonction de correspondance est agencée, pour deux blocs d'adresses virtuelles affectés consécutivement à un groupe de réplication donné, pour affecter les premières adresses de stockage associées à chaque bloc en réalisant un hachurage sur toutes les unités de stockage du groupe de réplication donné, et pour affecter les deuxièmes adresses de stockage sur toutes les unités de stockage du groupe de réplication donné en réalisant un hachurage propre à chaque bloc.
6. Outil informatique selon l'une des revendicatior les unités de stockage sont réparties dans les grc formule arithmétique choisie.
7. Outil informatique selon la revendication 6, caractérisé en o formule arithmétique est agencée pour définir un nombre de réplication supérieur ou égal au nombre maximum d'unités < dépendantes selon le critère de dépendance de panne.
8. Outil informatique selon la revendication 7, caractérisé en ce que la formule arithmétique est en outre agencée pour répartir les unités de stockages dépendantes selon le critère de dépendance de panne en groupes de défaillance, et pour affecter chaque unité de stockage de chaque groupe de défaillance à un groupe de réplication distinct.
9. Outil informatique selon l'une des revendications précédentes, caractérisé en ce que les adresses de stockage sont réparties dans le groupe de travail et les groupes de panne selon une formule arithmétique choisie.
PCT/FR2008/001168 2007-10-12 2008-08-04 Système informatique amélioré comprenant plusieurs noeuds en réseau WO2009053557A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP08841064A EP2212792A1 (fr) 2007-10-12 2008-08-04 Système informatique amélioré comprenant plusieurs noeuds en réseau

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0707189 2007-10-12
FR0707189A FR2922335A1 (fr) 2007-10-12 2007-10-12 Systeme informatique ameliore comprenant plusieurs noeuds en reseau.

Publications (2)

Publication Number Publication Date
WO2009053557A1 true WO2009053557A1 (fr) 2009-04-30
WO2009053557A9 WO2009053557A9 (fr) 2010-04-22

Family

ID=39048748

Family Applications (3)

Application Number Title Priority Date Filing Date
PCT/FR2008/001089 WO2009047398A2 (fr) 2007-10-12 2008-07-23 Système informatique amélioré comprenant plusieurs noeuds en réseau
PCT/FR2008/001088 WO2009047397A2 (fr) 2007-10-12 2008-07-23 Système informatique amélioré comprenant plusieurs noeuds en réseau
PCT/FR2008/001168 WO2009053557A1 (fr) 2007-10-12 2008-08-04 Système informatique amélioré comprenant plusieurs noeuds en réseau

Family Applications Before (2)

Application Number Title Priority Date Filing Date
PCT/FR2008/001089 WO2009047398A2 (fr) 2007-10-12 2008-07-23 Système informatique amélioré comprenant plusieurs noeuds en réseau
PCT/FR2008/001088 WO2009047397A2 (fr) 2007-10-12 2008-07-23 Système informatique amélioré comprenant plusieurs noeuds en réseau

Country Status (3)

Country Link
EP (2) EP2212791A2 (fr)
FR (1) FR2922335A1 (fr)
WO (3) WO2009047398A2 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0697660A1 (fr) * 1994-08-18 1996-02-21 International Business Machines Corporation HMC: Une méthode hybride, de miroir et de chaîne, pour la réplication des données, pour soutenir la haute disponibilité dans un réseau de disques
US5636356A (en) * 1992-09-09 1997-06-03 Hitachi, Ltd. Disk array with original data stored in one disk drive and duplexed data distributed and stored in different disk drives
EP1162537A1 (fr) * 2000-06-09 2001-12-12 Hewlett-Packard Company, A Delaware Corporation Utilisation d'espace disque inutilisé sur les ordinateurs gérés en réseau

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4498146A (en) * 1982-07-30 1985-02-05 At&T Bell Laboratories Management of defects in storage media
JP3344907B2 (ja) * 1996-11-01 2002-11-18 富士通株式会社 Ｒａｉｄ装置及び論理ボリュームのアクセス制御方法
GB2378277B (en) * 2001-07-31 2003-06-25 Sun Microsystems Inc Multiple address translations
US7035922B2 (en) * 2001-11-27 2006-04-25 Microsoft Corporation Non-invasive latency monitoring in a store-and-forward replication system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5636356A (en) * 1992-09-09 1997-06-03 Hitachi, Ltd. Disk array with original data stored in one disk drive and duplexed data distributed and stored in different disk drives
EP0697660A1 (fr) * 1994-08-18 1996-02-21 International Business Machines Corporation HMC: Une méthode hybride, de miroir et de chaîne, pour la réplication des données, pour soutenir la haute disponibilité dans un réseau de disques
EP1162537A1 (fr) * 2000-06-09 2001-12-12 Hewlett-Packard Company, A Delaware Corporation Utilisation d'espace disque inutilisé sur les ordinateurs gérés en réseau

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HSIAO H-I ET AL: "Chained declustering: a new availability strategy for multiprocessor database machines", 5 February 1990, PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON DATA ENGINEERING. LOS ANGELES, FEB. 5 - 9, 1990; [PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON DATA ENGINEERING], LOS ALAMITOS, IEEE. COMP. SOC. PRESS, US, PAGE(S) 456 - 465, ISBN: 978-0-8186-2025-6, XP010018233 *

Also Published As

Publication number Publication date
EP2212791A2 (fr) 2010-08-04
EP2212792A1 (fr) 2010-08-04
WO2009047397A3 (fr) 2009-06-04
FR2922335A1 (fr) 2009-04-17
WO2009053557A9 (fr) 2010-04-22
WO2009047398A2 (fr) 2009-04-16
WO2009047398A3 (fr) 2009-06-04
WO2009047397A2 (fr) 2009-04-16

Similar Documents

Publication Publication Date Title
JP6510112B2 (ja) データストリーム取り込み及び永続性ポリシ
JP6246358B2 (ja) 大規模データストリームの取得、記憶、及び消費のための管理型サービス
US7653699B1 (en) System and method for partitioning a file system for enhanced availability and scalability
US8055615B2 (en) Method for efficient storage node replacement
US20130218934A1 (en) Method for directory entries split and merge in distributed file system
US20110055494A1 (en) Method for distributed direct object access storage
US20110066668A1 (en) Method and System for Providing On-Demand Services Through a Virtual File System at a Computing Device
US20090222509A1 (en) System and Method for Sharing Storage Devices over a Network
US20130066830A1 (en) Peer-to-peer redundant file server system and methods
US8296420B2 (en) Method and apparatus for constructing a DHT-based global namespace
WO2013152358A1 (fr) Espaces de noms en anneau cohérents facilitant un stockage et une organisation de données dans des infrastructures de réseau
Frey et al. Probabilistic deduplication for cluster-based storage systems
KR20080091171A (ko) 웹 서비스 클라이언트 인터페이스를 갖는 분배형 저장시스템
US8307087B1 (en) Method and system for sharing data storage over a computer network
WO2006016085A1 (fr) Procede de sauvegarde distribuee sur des postes clients dans un reseau informatique
EP3788501B1 (fr) Partitionnement de données dans un système de stockage distribué
WO2009053557A1 (fr) Système informatique amélioré comprenant plusieurs noeuds en réseau
WO2008053098A2 (fr) Systeme informatique ameliore comprenant plusieurs noeuds en reseau
US8868970B2 (en) Object based storage system and method of operating thereof
FR3050848B1 (fr) Architecture de serveurs et methode de redistribution des donnees pour la distribution d&#39;un graphe versionne.
EP1912408B1 (fr) Procédé de gestion d&#39;une base de données partitionnée dans un réseau de communication
WO2011151569A1 (fr) Procede de routage pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d&#39;ordinateur mettant en oeuvre ce procede
US8032691B2 (en) Method and system for capacity-balancing cells of a storage system
FR2907993A1 (fr) Systeme informatique comprenant plusieurs noeuds en reseau.
FR2923112A1 (fr) Systeme informatique ameliore comprenant plusieurs noeuds en reseau

Legal Events

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

Ref document number: 08841064

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2008841064

Country of ref document: EP