Primary data storage systems provide data services to their clients through the abstraction of data stores, for example, as virtual volumes. These virtual volumes could be of different types, such as fully pre-provisioned or thin-provisioned or thin-provisioned and deduplicated.
Certain exemplary embodiments are described in the following detailed description and in reference to the drawings, in which:
Primary data storage systems provide data services to their clients through the abstraction of data stores, for example, as virtual volumes. These virtual volumes could be of different types, such as fully pre-provisioned or thin-provisioned or thin-provisioned and deduplicated. Such virtual volumes eventually need physical storage to store the data written to the virtual volumes. Normal thin-provisioned volumes can have data stores that are private to each such virtual volume. When a storage service provides deduplication among multiple virtual volumes, there can be a common deduplication store that is shared among such virtual volumes. Often, all data, whether it is duplicate data with multiple references or not, is saved in the common deduplication store. The virtual volumes only save deduplication collision data on local data stores when the data is different from data already residing in the deduplication store but has the same fingerprint signature.
Techniques described herein combine data stores, such as virtual volumes, with a deduplication store to efficiently store data. In examples described herein, the common deduplication store is used only to store duplicate data. When new data gets written to a client data store, such as a data store associated with a virtual volume, for the first time, the data gets stored in the client data store. A link to the data in the data store is written to the deduplication store, wherein the link includes the fingerprint, or hash code, associated with the data and a back reference to the data store holding the data. When a subsequent write to any of the other client data stores occurs, a fingerprint of the new data is computed and compared to the fingerprints in the deduplication store. If the new fingerprint matches a fingerprint previously stored in the deduplication store, the new data is moved to the deduplication store. Back references are then written to the associated client data stores to point to the deduplication store.
In deduplication systems without reference counting, unreferenced pages in the deduplication store are garbage collected periodically. If the deduplication store is used for all data, there can be a lot of data in the deduplication store with only single references. When such singleton data gets overwritten, it will create a lot of unreferenced pages that need to be garbage collected. This demands more aggressive garbage collection, which can adversely impact data services. If garbage collection is not aggressive enough, it may lead to larger deduplication store sizes. Thus, the aggressiveness of the garbage collection is balanced with the size of the storage space. In deduplication systems without reference counts and with background garbage collection, the approach described herein may result in less garbage, e.g., orphaned data occupying system storage space, and fewer singleton references in the deduplication store.
With data stored in the private data stores, data that is overwritten may be done by replacement of the old data with the new data in place. The new data and old data may have different fingerprints, and when the fingerprint of the new data is calculated, the old link in the deduplication store may be replaced. Further, by storing singleton references in private data stores, better performance may be achieved for sequential writes of singleton references, through coalescing writes to backend disks.
The server 102 may include a processor (or processors) 122 that is configured to execute stored instructions, as well as a memory device (or memory devices) 124 that stores instructions that are executable by the processor 122. The processor 122 can be a single core processor, a dual-core processor, a multi-core processor, a computing cluster, a cloud sever, or the like. The processor 122 may be coupled to the memory device 124 by a bus 126 where the bus 126 may be a communication system that transfers data between various components of the server 102. In embodiments, the bus 126 may be a PCI, ISA, PCI-Express, or the like.
The memory device 124 can include random access memory (RAM), e.g., static RAM, DRAM, zero capacitor RAM, eDRAM, EDO RAM, DDR RAM, RRAM, PRAM, read only memory (ROM), e.g., Mask ROM, PROM, EPROM, EEPROM, flash memory, or any other suitable memory systems. The memory device 124 may store code and links configured to administer the data stores 104-110.
The server 102 may also include a storage device 128. In some examples, multiple storage devices 128 are used, such as in a storage attached network (SAN). The storage device 128 may include non-volatile storage devices, such as a solid-state drive, a hard drive, an optical drive, a flash drive, an array of drives, or any combinations thereof. In some examples, the storage device 128 may include non-volatile memory, such as non-volatile RAM (NVRAM), battery backed up DRAM, and the like.
A network interface controller (NIC) 130 may also be linked to the processor 122. The NIC 130 may link the server 102 to a network 132, for example, to couple the server to clients located in a computing cloud 134. Further, the network 132 may couple the server 102 to management devices 136 in a data center to set up and control the client data stores 104-110.
The storage device 128 may include a number of modules configured to provide the server 102 with the deduplication functionality. For example, a fingerprint generator (FG) 138, which may be located in the client data stores 104-110, may be utilized to calculate a fingerprint, e.g., a hash code, for new data written to the client data store. A fingerprint comparator (FC) 140 may be used to compare the fingerprints generated to fingerprints in the deduplication store, e.g., associated with either links 142 and 144 or data 146 and 148. If a fingerprint matches, a data mover (DM) 150 may then be used to move the data to the deduplication store 112, if it is not already present. If the data is already in the deduplication store 112, the DM 150 may be used to copy a back reference to the client data store 104-110 to point to the data in the deduplication store 112 and remove the data from the client data store 104-110. The process is explained further with respect to the schematic drawings of
In the present example, a single copy of data D1152 is saved to client data store 106 in virtual machine 2116. An associated link L1144, including a fingerprint of the data D1152 and a backreference to the data D1152 in the client data store 106 is in the deduplication store 112. A single copy of a second piece of data D2154 is saved to client data store 108 in virtual machine 3118. An associated link L2142, including a fingerprint of the data D2154 and a backreference to the data D2154 in the client data store 108 is in the deduplication store 112.
Further, in this example, data D3146 is duplicate data that has been written to more than one client data store. A single copy of the data D3146 is saved to the deduplication store 112 along with the fingerprint of the data. Links L3156 to this data D3146, are saved to the associated client data stores 104 and 110. Similarly, data D4148 is duplicate data, in which a single copy is saved to the deduplication store 112 along with the fingerprint of the data. Links L4158 to this data D3148, are in the associated client data stores 106 and 108. It may be noted that this example has been simplified for clarity. In a real system, there may be many thousands of individual data blocks and links.
The block diagram of
The techniques described herein may be clarified by stepping through individual data writes. This is described with respect to
Similarly, more new (unmatched) data, DATA2212 is written 214 to virtual machine 3118, and saved to the client data store 108 as DATA2216. A fingerprint is generated for DATA2216, but since there are no matching fingerprints in the deduplication store 112, a link, Link2218 is saved in the deduplication store 112. As for Link1208, Link2218 includes the fingerprint of DATA2216 and a backreference 220 to the location of DATA2216 in the client data store 108.
If, at block 408, a matching fingerprint is not found in the deduplication store, process flow proceeds to block 410. At block 410, a link to the data in the client data store is saved in the deduplication store. The link includes the fingerprint of the data and a backreference to the location of the data in the client data store. If there is an old link associated with old data, it should be removed after the new link to new data is created in DEDUP. The method 400 then ends at block 412.
If a matching fingerprint is found at block 408, at block 414, the data is moved to the deduplication store. In one example, the data already exists in the deduplication store, in which case, no data is moved. At block 416, links to the data are saved to the associated client data stores. These links may include the fingerprint of the data and a backreference to the data saved in the deduplication store. The original fingerprint of the data may also be retained in the deduplication store for further comparisons.
If the data is removed from all but one client, it may be left in the deduplication store to minimize unnecessary data moves that consume resources. If the data is deleted from that final client, then garbage collection may be used to remove the data from the deduplication store.
The computer readable medium 500 includes a block 506 of code to direct one of the one or more processors 502 to calculate a fingerprint for data written to a client data store. Another block 508 of code directs one of the one or more processors 502 to compare the fingerprint to fingerprints stored in the deduplication store. The computer readable medium 500 also includes a block 510 of code to direct one of the one or more processors 502 to move data to the deduplication store. A block 512 of code may direct one of the one or more processors 502 to write links to the data to each client data store that is associated with that data. Further, a block 514 of code may direct one of the one or more processors 502 to erase the linked data from the client data stores. In one example, the data that is no longer needed in the client data store, e.g., because it is duplicate data saved in the deduplication store, may be marked and removed to free storage space as part of the normal garbage collection functions in the data store.
The code blocks above do not have to be separated as shown, the functions may be recombined into different blocks that perform the functions. Further, the computer readable medium does not have to include all of the blocks shown in
While the present techniques may be susceptible to various modifications and alternative forms, the exemplary examples discussed above have been shown only by way of example. It is to be understood that the technique is not intended to be limited to the particular examples disclosed herein. Indeed, the present techniques include all alternatives, modifications, and equivalents falling within the scope of the present techniques.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2015/042831 | 7/30/2015 | WO | 00 |