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

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

Info

Publication number
EP2212791A2
EP2212791A2 EP08837674A EP08837674A EP2212791A2 EP 2212791 A2 EP2212791 A2 EP 2212791A2 EP 08837674 A EP08837674 A EP 08837674A EP 08837674 A EP08837674 A EP 08837674A EP 2212791 A2 EP2212791 A2 EP 2212791A2
Authority
EP
European Patent Office
Prior art keywords
index
storage
addresses
virtual
storage unit
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP08837674A
Other languages
German (de)
English (en)
Inventor
Michaël DUSSERE
Samuel Richard
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Seanodes
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
Publication of EP2212791A2 publication Critical patent/EP2212791A2/fr
Withdrawn legal-status Critical Current

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

  • Improved computer system comprising a plurality of networked nodes
  • the invention relates to computer systems comprising several computer stations called nodes interconnected in a network.
  • Modern networks include user stations that are connected to one or more servers and can share applications and / or storage spaces locally or remotely.
  • the invention improves the situation.
  • the invention proposes a computer 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 second storage address from an incoming virtual address.
  • the correspondence module maintains a first table comprising data for identification of failed storage units, as well as a second table comprising data for modifying virtual address blocks, and the computer tool. includes a recovery unit arranged, at the recovery of a failed storage unit, for updating the storage addresses of this storage unit by calling the correspondence module with virtual addresses derived from the second table, on the database of the first 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 in the system of FIG. 1,
  • FIG. 5 shows an exemplary implementation of an element of FIG. 3,
  • FIG. 6 shows a correspondence between logical spaces and physical spaces managed by the element of FIG. 5,
  • FIG. 7 shows an example of a function implemented by the element of FIG. 5 to establish the correspondence of FIG. 6,
  • FIG. 8 shows an exemplary implementation of a 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 part 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 assignment shown in FIG. 6 and that shown in FIG. 11.
  • FIG. 1 represents a general diagram of a computer system according to the invention.
  • an application environment 2 has access to a file system manager 4.
  • a virtualization layer 6 establishes the correspondence between the file system manager 4 and storage servers 8.
  • FIG. 2 represents a logical implementation of the system of FIG. 1.
  • a set of stations 10, also referred to herein as nodes are interconnected in a network of which they constitute the physical and application resources.
  • the network consists of 5 stations, denoted Ni with i varying between 1 and 5.
  • the application environment 2 is made of a distributed application layer 12 on the N1, N2 and N3, in one application layer 14 on the N4 and an application layer 16 on the N5.
  • the file system manager 4 is produced in a distributed file system 18, and two non-distributed file systems 20 and 22.
  • the system 18 is distributed over the N1, N2 and N3 and defines all the files accessible from the distributed application layer 12.
  • the file systems 20 and 22 respectively define the set of files accessible from the application layers 14 and 16.
  • the files designated by the file systems 18, 20 and 22 are 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 "sees” the data stored in the logical space 26 (respectively 28, 30) by means of the file system 18 (respectively 20, 22), although these they are not necessarily physically present on one of the storage disks of the station 10 that uses this application.
  • the spaces 26, 28 and 30 are purely logical, that is, they do not directly represent physical storage spaces.
  • Logical spaces are mapped using virtual addresses that are referenced or contained in file systems 18, 20, and 22.
  • the correspondence module contains a table of correspondence between the virtual addresses of the data in the logical spaces and physical addresses that designate the physical storage spaces in which these data are actually stored.
  • each station is used for both the application layer and the storage layer.
  • This multifunctionality makes it possible to use the free space on all the stations of the network, rather than leaving this space unoccupied.
  • any station can play an application node role, a storage node role, or both these roles at once.
  • All the application, storage and file system resources can be integrated locally on each station, or distributed on the stations of the network.
  • FIG. 3 represents an exemplary architecture of a station 10 of FIG. 2.
  • the station represented in this example can represent one of the stations N1, N2 or N3.
  • Station Nx individually has a structure similar to that of the global structure shown in Figure 1. It thus comprises an application layer 32, a file system 34, a virtualization layer 36 and a storage space 38 in the form of a local memory with direct access.
  • the virtualization layer 36 comprises a motor 40 and a correspondence table 42.
  • the direct access to the storage space 38 is managed by a storage client 44 and a storage server 46. The roles and operations of these elements will be specified below.
  • the example described here represents an improved embodiment of the invention, in which all the resources, both application and storage, are distributed over the network.
  • management module 48 It is the same for the virtualization layer 36, the storage client 44 and the storage server 46.
  • the distribution of these elements is managed by means of a management module 48.
  • the administration module 48 is mainly used during the creation and updating of the logical spaces.
  • the administration module 48 calls the virtualization layer 36 to create the correspondence table between each virtual address of the logical space and a physical address on a given storage node.
  • the look-up table 42 is a table that contains information for retrieving 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 one set much smaller information, sufficient to restore correspondence very quickly.
  • 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: an identifier of the file concerned for the file system and an address in this file,
  • the size of the request that is to say the number of bits to be accessed after the address of the targeted file
  • the file system determines one or more virtual addresses for the data of this file, and generates one or more virtual access requests based on the request 50 and these virtual addresses.
  • Virtual access requests each include:
  • the size of the request that is to say the number of bits to be accessed following the targeted virtual address
  • step 52 consists in determining the logical space and the virtual address (es) on this space designated by the request 50, and to produce 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 file does not necessarily exist beforehand in a storage space 38. Nevertheless, as we have seen above, the correspondences between virtual addresses and physical addresses are frozen, and the motor 40 therefore operates in the same way as in the context of a read request to determine the physical address or addresses of the data.
  • step 56 physical access requests that it transmits to the storage client 44.
  • the physical access requests are generated based on the request 50 and the physical address (es) determined in step 54.
  • These requests include: - the targeted physical address;
  • 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.
  • step 56 all physical access requests in step 56 are represented as successively performed for simplicity. However, the execution can also be performed in parallel, and not only in series.
  • requests are transmitted from layer to layer, up to the physical access layer.
  • the storage client 44 interacts with the storage server 46 of the storage station that contains the storage space 38 on which the physical address designated by the storage address 38 is located. the physical access request concerned.
  • 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 basis of light algorithms while offering a high quality of service. This is much more efficient in terms of processor and memory occupation than the use of a direct look-up table such as a "look-up table" (in English).
  • the function of the cover unit 406 is to update certain physical addresses when a storage space of a given station has ceased 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.
  • failure correlated means a failure that renders inoperative a set of spaces or storage units (hereinafter disks) connected together (hereinafter group of failure).
  • 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 consecutive virtual address data is gathered into hatches that extend over all the disks.
  • the node N1 here comprises three disks MU11, MU12 and MU13, the node N2 three disks MU21, MU22 and MU23, the node N3 a disk MU31, and the node N4 three 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 thus consists of the disks MU 11 to MU13
  • the failure group N2 is composed of the disks MU21 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.
  • the replication group GR1 comprises four disks corresponding respectively to the MLM disks 1, MU21, MU31 and MU43, and the other disks MU12 and MU13 of the failure group N1 are assigned respectively to the groups GR2 and GR3.
  • Other disk allocation algorithms are possible, as those skilled in the art will recognize. It will be noted, for example, that for allocating the disks to the replication groups, it would also be possible to take into account the space available on the disks, so as to ensure replication groups of uniform size. Another possibility would be to take into account their performance to obtain homogeneous performance replication groups.
  • the virtual addresses are assigned on the disks sorted by replication group.
  • each number that is represented means the association of virtual addresses to physical addresses.
  • the virtual addresses are grouped in ascending order in units of hatching ("striping unit" in English) of defined sizes.
  • the hatch units are themselves associated with physical addresses on the disks.
  • 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
  • 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 physical addresses of the disk MU11 of N1 receive the following hatch units: 0, 3, 10, 12, 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.
  • 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.
  • a test is performed to determine if the virtual address is related to a write request. If this is the case, in an operation 2040, a test is performed to determine if the system is in a degraded state, that is, if one of the disks is down. If this is the case, a Wrt_Drt_Z () function is called in 2060.
  • the operations 2040, 2060 and 2080 are connected to functions enabling the rapid recovery 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 SUJ nd () starts from the virtual address whose match 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 table Ngr [] is useful because it allows to quickly find the total number of N disks and the number of Ngr replication group, and to access just as quickly the number of disks by replication group.
  • N and Ngr are arguments, but a computation is then necessary when one needs the number of disks within a given replication group.
  • the role of the Get_Phy_lnd () function is to find the index of the hatch unit in the sort by failure group from its index in the sort by replication group.
  • StripQ determines a principal hatch index k, as well as the 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.
  • each disk within a replication group contains all replicated data from another disk in the same group.
  • a function Mrg () determines a disk index m2 which corresponds to the index q2 within the index replication group p. This is accomplished by applying Equation 27 of Appendix A.
  • the indexes m1 and m2 of disks classified by group of replication are converted into disk indices n1 and n2 of the 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.
  • the 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 first table contains two lines, one of which receives disk IDs and the other receives a growing index.
  • the second table 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 comprises only one line which receives the indices of disks, and it is the index of position of each identifier in the table which serves as increasing index.
  • the Wrt_Drt_Z () function relies on clues in the fault table to maintain an up-to-date view of the areas associated with a failed disk that have been modified.
  • the cover unit 406 may perform the function of Fig. 10 to restore a disk after a failure. For this, 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 index growth and avoids processing too much data.
  • the zone table can receive zones of configurable size. Indeed, 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. Note that the reserved data area of the logical volume 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 virtual spaces to physical spaces as an alternative to that of Figure 6.
  • fault tolerance is also increased, this time voluntarily leaving free spaces within replication groups called resiliency 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 discs, we will define hatching with four hatching units for storing data, and three resiliency units for fault tolerance.
  • the disks are divided into several groups to avoid correlated failures, that is to say affecting several disks at a time.
  • the definition of the resilience units in addition to the hatch units amounts to distributing part of the physical addresses into a working group (those receiving the data from the hatch units) on the one hand, and into fault groups (those 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 function Get_Phy_lnd () receives the following three arguments (operation 2482):
  • the Strip () function determines a principal hatch index k, as well as the index mm1 of the first disk on which 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 the resilience units. As will be seen below, the index m2 that returns the function Cp_Spr () can be an index of a unit of resilience.
  • the physical address indices are returned in 2499.
  • the function Cp_Spr () will now be described with FIG. 13. This function receives as arguments an index of disk mm, a index of unit of hatching k, a total number of disks N and a number of units of resilience S.
  • the Cp_Spr () function 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 disk index mm,
  • 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 disks and is synchronized continuously, together with the fault table for example.
  • 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 index disk data m is stored in each hatch on the resilience unit whose resilience index is indicated by the resilience table, and therefore only the index hatch k to determine the index of the disk on which the desired resilience 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.
  • this function receives the IDs of all failed disks.
  • a function Spr_Dsk modifies the index of the failed disk with which no resilience unit is associated.
  • the value of its resilience index receives the first resilience index not already assigned.
  • the Wrt_Spr_Dsk () function generates queries for writing data available on the remaining hatch unit to the resiliency unit, and these requests are executed in competition with the 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.
  • This function can therefore be performed directly in the virtualization layer or in the administration module, as a separate function as presented here, or as an integral part of the functions 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.
  • N and Ngr are arguments, but a computation is then necessary when one needs the number of disks within a given replication group.
  • Operations 2484 and 2486 are then performed identically to those of FIG. 12, and operation 2488 is performed as step 2088 of FIG.
  • the operations 2490 to 2494 are performed as in the case of Figure 12, taking into account that this operation is performed within a 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 units are here described as having a fixed size. It would nevertheless be possible to implement the invention by assigning different sizes of hatch units according to the replication groups with some modifications to the described functions.
  • the engine and lookup table described herein form a correspondence module capable of assigning the virtual addresses to physical addresses based on a rule having an arithmetic formula defined by the above functions.
  • these functions constitute the essence of the assignment rule, it would be possible to use a rule that fixedly affects a certain part of the virtual addresses, and which affects another part of the virtual addresses with 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 may include a driver that manages the relationships between the various elements such as the application-file system interaction, the file system interaction-correspondence module, the correspondence module-client interaction of storage, implementing the storage server policy by getting each item a result and calling the next item with that result (or a modified form of that result).
  • a driver that manages the relationships between the various elements such as the application-file system interaction, the file system interaction-correspondence module, the correspondence module-client interaction of storage, implementing the storage server policy by getting each item a result and calling the next item with that result (or a modified form of that result).
  • the system is autonomous and does not depend on the application that calls the data, and the elements are able to communicate with each other, so that the information goes down and then goes up the element layers in element.
  • the communications between these elements can be provided in different ways, for example by means of the POSIX interface, IP 1 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 for example of the CISC or RISC type or other type
  • one or more storage disks for example Serial ATA, SCSI, or other hard disk drives
  • any other type of storage and
  • a network interface for example Gigabit, Ethernet, Infiniband, SCI .
  • an operating system-based application environment eg Linux
  • an operating system-based application environment eg Linux
  • an application set for carrying out the correspondence module for example the Clustered Logical Volume Manager module of the Exanodes (registered trademark) application of the company Seanodes (registered trademark),
  • This type of system can be realized in a network comprising: conventional user stations, adapted for application use on a network and acting as application nodes, and
  • 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 method for storing data comprising determining at least a first and a second storage address from a virtual address received at the input, the storage addresses being associated with storage units, and storing data associated with said virtual address in said first and second determined storage addresses, the method being characterized in that: a first table comprising data for identification of failed storage units, and a second table comprising virtual address block modification data are maintained, and
  • the storage addresses of this storage unit are updated from virtual addresses from the second table, based on the data of the first table.
  • the method may further be characterized in that: * the modification of a virtual address, the second table stores an index for the block of virtual addresses to which this address belongs, said index being defined to indicate the posteriority with respect to the most recent failure indicated in the first table;
  • the storage addresses of this storage unit which correspond in the correspondence module to virtual addresses which belong to blocks of virtual addresses whose index in the second table indicates a posteriority relative to the index of the storage unit restored in the first table are updated;
  • the first table stores an index for this storage unit, said index being defined higher than the indices already defined in the first table;
  • the second table stores an index for the virtual address block to which the address belongs, said index being defined equal to the maximum indices defined in the first table in the modification;
  • the storage addresses of this storage unit which correspond in the correspondence module to virtual addresses which belong to blocks of virtual addresses whose index in the second table is greater than or equal to the index of the storage unit restored in the first table are updated;
  • the first table is updated by deleting the corresponding index. to the reinstated storage unit, and the second table is updated by setting the indices of the second table that are greater than the maximum of the indices defined in the first updated table as equal to this maximum.
  • the invention also covers, as products, the software elements described, made available under any “medium” (support) readable by computer.
  • computer readable medium includes data storage media, magnetic, optical and / or electronic, as well as a medium or transmission vehicle, such as an analog or digital signal.

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) étant agencé pour déterminer une correspondance entre des adresses virtuelles et des adresses physiques sur les unités de stockage, chaque adresse virtuelle étant affectée à au moins deux adresses de stockage, caractérisé en ce que le module de correspondance maintient une première table comprenant des données d'identification d'unités de stockage en panne, ainsi qu'une deuxième table comprenant des données de modification de blocs d'adresses virtuelles, l'outil informatique comprenant en outre une unité de recouvrement agencée (406), au rétablissement d'une unité de stockage tombée en panne, pour mettre à jour les adresses de stockage de cette unité de stockage en appelant le module de correspondance avec des adresses virtuelles tirées de la deuxième table, sur la base des données de la première table.

Description

Système informatique amélioré comprenant plusieurs noeuds en réseau
L'invention concerne les systèmes informatiques comprenant plusieurs postes informatiques dits noeuds interconnectés en un réseau.
Les réseaux modernes comportent des stations utilisateurs qui sont reliées à un ou plusieurs serveurs et peuvent partager des applications et/ou des espaces 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 deuxième adresses de stockage à partir d'une adresse virtuelle reçue en entrée.
Selon un aspect particulier, le module de correspondance maintient une première table comprenant des données d'identification d'unités de stockage en panne, ainsi qu'une deuxième table comprenant des données de modification de blocs d'adresses virtuelles, et l'outil informatique comprend une unité de recouvrement agencée, au rétablissement d'une unité de stockage tombée en panne, pour mettre à jour les adresses de stockage de cette unité de stockage en appelant le module de correspondance avec des adresses virtuelles tirées de la deuxième table, sur la base des données de la première table.
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 fichier dans le système de la figure 1,
- la figure 5 montre un exemple d'implémentation d'un élément de la figure 3,
- la figure 6 montre une correspondance entre des espaces logiques et des 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 par l'élément de la figure 5 pour établir la correspondance de la figure 6,
- la figure 8 montre un exemple d'implémentation d'une partie 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 elles constituent les ressources physiques et applicatives.
Dans l'exemple ici décrit, le réseau est constitué de 5 stations, notées Ni avec i variant entre 1 et 5. L'environnement d'application 2 est réalisé en une couche applicative répartie 12 sur les N1 , N2 et N3, en une couche applicative 14 sur le 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èmes 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 (respectivement 14, 16) "voit" les données stockées dans l'espace logique 26 (respectivement 28, 30) au moyen du système de fichiers 18 (respectivement 20, 22), bien que celles-ci ne soient pas forcément physiquement présentes sur l'un des disques de stockage de la station 10 qui utilise cette application.
Par ailleurs, les espaces 26, 28 et 30 sont purement logiques, c'est-à-dire qu'ils 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 les 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, toute station peut jouer un rôle de nœud applicatif, un rôle de nœud stockant, ou encore ces deux rôles à la fois.
L'ensemble des ressources applicatives, de stockage et de système de fichiers peuvent être intégrées localement sur chaque station, ou bien réparties sur les 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'autres nœuds du réseau qui contiennent les données recherchées.
Il en est de même pour la couche de virtualisation 36, le client de stockage 44 et le serveur de stockage 46. La répartition de ces éléments est gérée au 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 sur 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 fichiers de cet espace et les adresses virtuelles de ces données est établi que les adresses physiques sont remplies.
Dans le mode de réalisation décrit ici, la table de correspondance 42 est un tableau qui contient des informations permettant de retrouver les correspondances. Lorsqu'une application fait appel à un espace mémoire 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étermine une ou plusieurs adresses virtuelles pour les données de ce fichier, et génère une ou plusieurs requêtes d'accès virtuel sur la base de la requête 50 et de ces adresses virtuelles.
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 à la suite de 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".
Il 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 écriture, le fichier n'existe pas forcément de manière préalable dans un espace de stockage 38. Néanmoins, comme on l'a vu plus haut, les correspondances entre adresses virtuelles et adresses physiques sont figées, et le moteur 40 opère donc de la même manière que dans le cadre d'une requête en lecture pour déterminer la ou les 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ès physique de l'étape 56 sont représentées comme exécutées successivement pour des raisons de simplicité. Cependant, l'exécution peut également être réalisée en parallèle, et pas seulement en série.
Dans l'exemple décrit, des requêtes sont transmises de couche en couche, jusqu'à la couche d'accès physique. Il serait cependant possible de déterminer 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 qualité de service élevée. Cela est beaucoup plus performant en termes d'occupation processeur et mémoire que l'utilisation d'une table de correspondance directe telle une "look-up table" (en anglais).
L'unité de recouvrement 406 a pour fonction la mise à jour de certaines adresses physiques lorsqu'un espace de stockage d'une station donnée a 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écutives sont rassemblées dans des hachures qui s'étendent sur tous les disques.
Ainsi, sur l'exemple représenté, on part de quatre noeuds N1 à N4. Le nœud N1 comporte ici trois disques MU11, MU12 et MU 13, le nœud N2 trois disques MU21, MU22 et MU23, le nœud N3 un disque MU31 , et le nœud N4 trois 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 MU 11 à MU13, le groupe de défaillance N2 est composé des disques MU21 à 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, il est nécessaire qu'il y ait au moins autant de groupes de réplication qu'il y a de disques dans le groupe de défaillance qui a le plus grand nombre de disques, conformément à l'équation
10 de l'Annexe A.
Ensuite, afin d'effectuer une répartition la plus souple possible en termes de charge, on fixe le nombre de disques par groupe de réplication selon l'équation
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 MLM 1 , 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éplicatipn, 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é, chaque numéro qui est représenté signifie l'association d'adresses virtuelles à des adresses physiques.
En effet, les adresses virtuelles sont réunies par ordre croissant en unités de hachurage ("striping unit" en anglais) de tailles définies. Les unités de hachurage sont elles même associées avec des adresses physiques sur les disques.
Comme on peut le 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 hachurage 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'est pas constant, de sorte que lorsqu'un disque donné tombe en panne, la charge est répartie sur les autres disques.
Ainsi, dans l'exemple représenté sur la figure 6, les adresses physiques du disque MU11 de N1 reçoivent les unités de hachurage suivantes : 0, 3, 10, 12, 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éplication 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é pour déterminer si l'adresse virtuelle est reliée à une requête en écriture. Si c'est le cas, dans une opération 2040, un test est réalisé pour déterminer si le système est en état dégradé, c'est-à-dire si l'un des disques est en panne. Si c'est le cas, une fonction Wrt_Drt_Z() est appelée en 2060.
Les opérations 2040, 2060 et 2080 sont reliées à des fonctions permettant la 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 SUJ nd() 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 valeurs indiquent le nombre de disques pour chaque groupe de réplication.
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 de passer directement N et 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
StripQ détermine un indice de hachure principale k, ainsi 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 utilisables, comme un simple décalage d'indice d'unité de hachurage. Dans ce cas plus simple, chaque disque au sein d'un groupe de réplication contient toutes les données répliquées d'un autre disque du même groupe.
Dans une opération 2097, une fonction Mrg() détermine un indice de disque m2 qui correspond à l'indice q2 au sein du groupe de réplication d'indice p. Cela est 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 Wrt_Drt_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 stockées sont potentiellement distinctes, et il faut rétablir la cohérence avec la version des données qui a subi l'écriture.
Pour cela, deux tables sont maintenues pendant l'exécution. La première table, dite de pannes, contient deux lignes, dont l'une reçoit des identifiants de disques et l'autre reçoit un indice croissant. La deuxième table, dite de zones, contient deux lignes, dont l'une reçoit des identifiants de zones, et l'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 chaque identifiant dans la table qui sert d'indice croissant.
La fonction Wrt_Drt_Z() se base sur les indices de la table de pannes pour maintenir une vue à jour des zones associées à un disque en panne qui ont été 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 et évite de traiter des données trop grandes.
S'il reste des zones à parcourir, l'indice i est incrémenté (opération 2310). Sinon, la fonction se termine dans l'opération 2312.
On notera que la table de zones peut recevoir des zones de taille paramétrable. 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 volume 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.
II 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 directement dans la couche de virtualisation ou dans le module d'administration, en tant que fonctions séparées comme cela est présenté ici, ou en tant que partie intégrante des fonctions présentées plus haut.
La figure 11 représente une attribution des espaces virtuels aux espaces physiques en variante de celui de la figure 6. Ici, la tolérance aux pannes est é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 maintenant être décrite avec la figure 12. On notera tout d'abord la différence de contexte entre l'attribution 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 groupes pour éviter les pannes corrélées, c'est-à-dire affectant plusieurs disques à la fois.
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.
II n'y alors pas a priori de regroupement des disques par groupe de réplication, bien que cela soit possible comme on le 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 arguments suivants (opération 2482) :
* l'indice de l'unité de hachurage dont on cherche la correspondance,
* 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 un indice de hachure principal k, ainsi que l'indice mm1 du premier disque sur lequel 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'indice m2 que retourne la fonction Cp_Spr() peut être un indice d'une unité de résilience.
Une fois les indices m1 et m2 déterminés, les indices d'adresses physiques sont retournés en 2499.
La fonction Cp_Spr() va maintenant être décrite avec la figure 13. Cette fonction reçoit comme arguments un indice de disque mm, un indice d'unité de 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 valeur stockée est alors un indice d'unité de résilience qui permet de déterminer l'indice du disque auquel est attribuée l'unité de résilience qui sera associée au disque d'indice m.
Une telle table de résilience est stockée sur chacun des disques et est synchronisée en permanence, en même temps que la table de pannes par 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ésilience 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 tombe en panne (opération 2700), cette fonction reçoit les identifiants de tous les disques en panne.
Dans une opération 2702, une fonction Spr_Dsk() modifie l'indice du disque en panne auquel n'est associée aucune unité de résilience. La valeur de son indice 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 directement dans la couche de virtualisation ou dans le module d'administration, en tant que fonction séparée comme cela est présenté ici, ou en tant que partie intégrante des fonctions présentées plus haut.
Dans un mode de réalisation avantageux, l'attribution décrite avec la figure 6 et celle décrite avec la figure 11 sont mélangées, pour offrir un support de panne 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 de passer directement N et 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é.
Les opérations 2484 et 2486 sont ensuite réalisées de manière identique à celles de la figure 12, et l'opération 2488 est réalisée comme l'opération 2088 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 figure 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 comme ayant une taille fixe. Il serait néanmoins possible d'implémenter l'invention en affectant des tailles d'unités de hachurage différentes selon les groupes de réplication moyennant quelques modifications aux fonctions décrites.
Le moteur et la table de correspondance décrits ici forment un module de correspondance capable d'affecter les adresses virtuelles à des adresses 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 peut comporter un pilote qui gère les relations entre les divers éléments telle l'interaction application - système de fichiers, l'interaction système de fichiers - module de correspondance, l'interaction module de correspondance - client de stockage, implémentation de la stratégie du serveur de stockage en obtenant de chaque élément un résultat et en appelant l'élément suivant avec ce résultat (ou une 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'interface POSIX, des protocoles IP1 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 module de correspondance, par exemple le module Clustered Logical Volume Manager de l'application Exanodes (marque déposée) de la société Seanodes (marque déposée),
* un ensemble applicatif pour réaliser le client de stockage et le serveur de stockage de chaque NBD, par exemple le module Exanodes Network Block
Device de l'application Exanodes (marque déposée) de la société Seanodes (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 nœuds 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 nœuds 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 couvre notamment l'ensemble des combinaisons entre elles des caractéristiques des variantes décrites.
L'invention couvre également un procédé de stockage de données comprenant la détermination d'au moins une première et une deuxième adresses de stockage à partir d'une adresse virtuelle reçue en entrée, les adresses de stockages étant associées à des unités de stockage, et le stockage de données 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 : * une première table comprenant des données d'identification d'unités de stockage en panne, ainsi qu'une deuxième table comprenant des données de modification de blocs d'adresses virtuelles sont maintenues, et
* au rétablissement d'une unité de stockage tombée en panne, les adresses de stockage de cette unité de stockage sont mises à jour à partir d'adresses virtuelles tirées de la deuxième table, sur la base des données de la première table.
Le procédé peut être en outre caractérisé en ce que : * à la modification d'une adresse virtuelle, la deuxième table stocke un indice pour le bloc d'adresses virtuelles auquel cette adresse appartient, ledit indice étant défini pour indiquer la postériorité par rapport à la panne la plus récente indiquée dans la première table ;
* au rétablissement d'une unité de stockage, les adresses de stockage de cette unité de stockage qui correspondent dans le module de correspondance à des adresses virtuelles qui appartiennent à des blocs d'adresses virtuelles dont l'indice dans la deuxième table indique une postériorité par rapport à l'indice de l'unité de stockage rétablie dans la première table sont mises à jour ;
* lors d'une panne d'une unité de stockage, la première table stocke un indice pour cette unité de stockage, ledit indice étant défini supérieur aux indices déjà définis dans la première table ;
* à la modification d'une adresse virtuelle, la deuxième table stocke un indice pour le bloc d'adresses virtuelles auquel cette adresse appartient, ledit indice étant défini égal au maximum des indices définis dans la première table lors de la modification ;
* au rétablissement d'une unité de stockage, les adresses de stockage de cette unité de stockage qui correspondent dans le module de correspondance à des adresses virtuelles qui appartiennent à des blocs d'adresses virtuelles dont l'indice dans la deuxième table est supérieur ou égal à l'indice de l'unité de stockage rétablie dans la première table sont mises à jour ; et
* lorsque les adresses de stockage d'une unité de stockage rétablie ont été mises à jour, la première table est mise à jour en effaçant l'indice correspondant à l'unité de stockage rétablie, et la deuxième table est mise à jour en définissant les indices de la deuxième table qui sont supérieurs au maximum des indices définis dans la première table mise à jour comme égaux à ce maximum.
L'invention couvre également, en tant que produits, les éléments logiciels décrits, mis à disposition sous tout "médium" (support) lisible par ordinateur. L'expression "médium lisible par ordinateur" comprend les supports de stockage de données, magnétiques, optiques et/ou électroniques, aussi bien qu'un support ou véhicule de transmission, comme un signal analogique ou numérique.
ANNEXE A
SECTION 1
SECTION 2 ANNEXE A (suite)
SECTION 2 (suite)
SECTION 3

Claims

Revendications
1. 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) étant agencé pour déterminer une correspondance entre des adresses virtuelles et des adresses physiques sur les unités de stockage, chaque adresse virtuelle étant affectée à au moins deux adresses de stockage, caractérisé en ce que le module de correspondance maintient une première table comprenant des données d'identification d'unités de stockage en panne, ainsi qu'une deuxième table comprenant des données de modification de blocs d'adresses virtuelles, l'outil informatique comprenant en outre une unité de recouvrement (406) agencée, au rétablissement d'une unité de stockage tombée en panne, pour mettre à jour les adresses de stockage de cette unité de stockage en appelant le module de correspondance avec des adresses virtuelles tirées de la deuxième table, sur la base des données de la première table.
2. Outil informatique selon la revendication 1, caractérisé en ce que le module de correspondance est agencé, lors d'une panne d'une unité de stockage, pour stocker dans la première table un indice pour cette unité de stockage, ledit indice étant défini pour indiquer la postériorité de cette panne par rapport aux pannes déjà indiquées dans la première table.
3. Outil informatique selon la revendication 2, caractérisé en ce que le module de correspondance est agencé, à la modification d'une adresse virtuelle, pour stocker dans la deuxième table un indice pour le bloc d'adresses virtuelles auquel cette adresse appartient, ledit indice étant défini pour indiquer la postériorité par rapport à la panne la plus récente indiquée dans la première table.
4. Outil informatique selon la revendication 3, caractérisé en ce que l'unité de recouvrement est agencée, au rétablissement d'une unité de stockage, pour mettre à jour les adresses de stockage de cette unité de stockage qui correspondent dans le module de correspondance à des adresses virtuelles qui appartiennent à des blocs d'adresses virtuelles dont l'indice dans la deuxième table indique une postériorité par rapport à l'indice de l'unité de stockage rétablie dans la première table.
5. Outil informatique selon l'une des revendications précédentes, caractérisé en ce que le module de correspondance est agencé, lors d'une panne d'une unité de stockage, pour stocker dans la première table un indice pour cette unité de stockage, ledit indice étant défini supérieur aux indices déjà définis dans la première table.
6. Outil informatique selon la revendication 5, caractérisé en ce que le module de correspondance est agencé, à la modification d'une adresse virtuelle, pour stocker dans la deuxième table un indice pour le bloc d'adresses virtuelles auquel cette adresse appartient, ledit indice étant défini égal au maximum des indices définis dans la première table lors de la modification.
7. Outil informatique selon les revendications 6, caractérisé en ce que l'unité de recouvrement est agencée, au rétablissement d'une unité de stockage, pour mettre à jour les adresses de stockage de cette unité de stockage qui correspondent dans le module de correspondance à des adresses virtuelles qui appartiennent à des blocs d'adresses virtuelles dont l'indice dans la deuxième table est supérieur ou égal à l'indice de l'unité de stockage rétablie dans la première table.
8. Outil informatique selon la revendication 7, caractérisé en ce que le module de correspondance est agencé, lorsque l'unité de recouvrement a mis à jour les adresses de stockage d'une unité de stockage rétablie, pour mettre à jour la première table en effaçant l'indice correspondant à l'unité de stockage rétablie, et pour mettre à jour la deuxième table en définissant les indices de la deuxième table qui sont supérieurs au maximum des indices définis dans la première table mise à jour comme égaux à ce maximum.
EP08837674A 2007-10-12 2008-07-23 Système informatique amélioré comprenant plusieurs noeuds en réseau Withdrawn EP2212791A2 (fr)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP2212791A2 true EP2212791A2 (fr) 2010-08-04

Family

ID=39048748

Family Applications (2)

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

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP08841064A Withdrawn EP2212792A1 (fr) 2007-10-12 2008-08-04 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)

Family Cites Families (7)

* 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
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
US5559764A (en) * 1994-08-18 1996-09-24 International Business Machines Corporation HMC: A hybrid mirror-and-chained data replication method to support high data availability for disk arrays
JP3344907B2 (ja) * 1996-11-01 2002-11-18 富士通株式会社 Ｒａｉｄ装置及び論理ボリュームのアクセス制御方法
EP1162537B1 (fr) * 2000-06-09 2007-09-26 Hewlett-Packard Company, A Delaware Corporation Utilisation d'espace disque inutilisé sur les ordinateurs gérés en réseau
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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2009047397A3 *

Also Published As

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

Similar Documents

Publication Publication Date Title
US8548957B2 (en) Method and system for recovering missing information at a computing device using a distributed virtual file system
US7996610B2 (en) Transparent backup service for networked computers
EP1815359A1 (fr) Système et procédé de sauvegarde distribuée pérenne
US8849877B2 (en) Object file system
US8296420B2 (en) Method and apparatus for constructing a DHT-based global namespace
US20110010434A1 (en) Storage system
US8307087B1 (en) Method and system for sharing data storage over a computer network
WO2021043599A1 (fr) Migration d'une chaîne de blocs de données
WO2006016085A1 (fr) Procede de sauvegarde distribuee sur des postes clients dans un reseau informatique
FR2932289A1 (fr) Procede et systeme de synchronisation de modules logiciels d'un systeme informatique distribue en grappe de serveurs, application au stockage de donnees.
WO2008053098A2 (fr) Systeme informatique ameliore comprenant plusieurs noeuds en reseau
EP2212791A2 (fr) Système informatique amélioré comprenant plusieurs noeuds en réseau
WO2011151569A1 (fr) Procede de routage pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procede
FR3025340A1 (fr) Nuage de donnees
FR2907993A1 (fr) Systeme informatique comprenant plusieurs noeuds en reseau.
US8032691B2 (en) Method and system for capacity-balancing cells of a storage system
EP1912408A1 (fr) Procédé de gestion d'une base de données partitionnée dans un réseau de communication
WO2010125257A1 (fr) Système de stockage comprenant plusieurs noeuds en réseau avec gestion de synchronisation d'écriture
EP2353076A1 (fr) Procede et systeme de stockage virtualise d'un ensemble de donnees numeriques
FR2938356A1 (fr) Procede et systeme de synchronisation d'un ensemble de modules logiciels d'un systeme informatique distribue en grappe de serveurs
FR3100350A1 (fr) migration d’une chaîne de blocs de données
FR3100351A1 (fr) connexion à chaîne de blocs de données
FR3094509A1 (fr) Système de stockage redondant de données, procédé et programme d’ordinateur correspondants.
WO2009136030A1 (fr) Procede de sauvegarde/restauration de fichiers dans un reseau pair a pair
Kloudas Leveraging content properties to optimize distributed storage systems

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100512

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

RIN1 Information on inventor provided before grant (corrected)

Inventor name: RICHARD, SAMUEL

Inventor name: DUSSERE, MICHAEL

17Q First examination report despatched

Effective date: 20120214

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120201

DAX Request for extension of the european patent (deleted)