Patent Application
20080016130
In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:
Many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.
Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
The tape drive 125, RAID controller 115 and disk drives 120, and optical storage device 130 are collectively referred to herein as storage devices. In addition, the system 100 may include one or more alternate storage devices including micromechanical storage devices, semiconductor storage devices, or the like.
In one embodiment, the storage server 110 may backup data from the clients 105. In one example, the storage server 110 may copy one or more data files from a first client 105a to a storage device such as the tape drive 125. If the first client 105a subsequently requires the data files, the storage server 110 may copy the data files from the tape drive 125 to the first client 105. In one embodiment, the storage server 110 copies all data files from a client 105 to a storage device. In an alternate embodiment, the storage server 110 copies each data file that is modified subsequent to a previous backup to the storage device.
The storage devices may also store data directly for the clients 105. In one example, the RAID controller 115 may store database data for the clients on the disk drives 120. The RAID controller 115 may store the database data as redundant data as is well known to those skilled in the art.
The system 100 may organize the storage devices as a plurality of storage pools as will be discussed hereafter. A pool may include a portion of a storage device such as the optical storage device 130, a tape mounted on the tape drive 125, and the like. The system 100 may organize the pools as a storage hierarchy, as will be described hereafter. In addition, the system 100 may move data between pools to provide additional data protection through redundancy.
The system 100 may require available bandwidth if the system is to be able to restore data files from the clients 105 in a timely manner. In addition, the system 100 may require available bandwidth in order to store data for the clients 105. Unfortunately, the bandwidth required to move data between pools and backup and restore data files may exceed the available bandwidth of the system 100. The embodiment of the present invention reduces the bandwidth demands on the system 100 by performing concurrent copies of data files.
In one embodiment, the storage manager 205 organizes the storage devices 210 into a plurality of pools. Each pool may comprise one or more logical volumes and/or one or more storage devices 210 as is well known to those skilled in the art. In one embodiment, the storage manager 205 organizes a storage pool that is configured to store active data files. In one embodiment, an active data file is the most recently backed up instance of a client data file. For example, the storage manager 205 may copy a client data file from the client 105 to the storage pool as an active data file. The copy of the client data file is an active data file until the storage manager 205 copies a subsequent instance of the client data file to the storage pool.
In one example, a first storage device 210a may be organized as the storage pool. However, any number of storage devices 210 may embody the storage pool. In one embodiment, the storage pool is configured as an ADFSP.
In addition, the storage manager 205 may organize a copy pool that is configured to backup the storage pool. Continuing the above example, a second storage device 210b may be organized as the copy pool, although any number of storage devices 210 may embody the copy pool. The copy pool may be configured to store active and inactive data. In one embodiment, copies of client data files become inactive when the client data files are subsequently backed up to a new active data file, and/or when the client data files are deleted from the client 105.
The storage manager 205 may further organize a next pool. The next pool may offload data files from the storage pool, and may store active and inactive data files. Thus the next pool may offload inactive data files from the storage pool so that the storage pool only stores active data files. Continuing the above example, a third storage device 210c may be organized as the next pool.
The storage manager 205 may receive one or more data files from a client 105 through the client interface 225. In one embodiment, the storage manager 205 copies the data files from the client 105. Alternatively, the client 105 may transmit the data files to the storage manager 205. The storage manager 205 may store the data files in a transfer buffer 220. In addition, the storage manager 205 may copy the data files from the transfer buffer 220 to the pools.
The copy module 305 copies one or more data files from a client 105 to a storage pool of a storage subsystem 200 as will be described hereafter. The storage pool may be an ADFSP. In one embodiment, the storage pool only stores active data files. In addition, the copy module 305 concurrently copies the data files to a copy pool. The copy module 305 further concurrently copies the data files to a next pool.
In one embodiment, the migration module 320 migrates one or more active and/or inactive data files from the storage pool to the next pool. The restoration module 315 may restore the data files from the storage pool to the client 105. In one embodiment, the restoration module 315 restores the data files from the next pool to the client 105. Alternatively, the restoration module 315 may restore the data files from the copy pool to the client 105.
In one embodiment, the aggregation module 325 aggregates a plurality of data files into an aggregate file. The storage manager 205 may reference the aggregate file using a single data base entry. Thus the aggregate file appears to the storage manager 205 as a single data file. The aggregate file may be copied and communicated as a single data file, reducing management demands on the storage manager 205. In addition, the aggregate file may include an index to the plurality of data files. In one embodiment, the storage manager 205 stores data files in the pools as aggregate files.
In a certain embodiment, the aggregation module 325 aggregates a first aggregate file into a second aggregate file. The aggregation module 325 may not include one or more inactive data files of the first aggregate file in the second aggregate file.
In one embodiment, the reclamation module 310 reclaims the storage space of the first aggregate file. The reclamation module 310 may reclaim the first aggregate file by deleting the first aggregate file from the storage pool. The reclamation module 310 may not copy the first aggregate file as part of the reclamation of the first aggregate file before deleting the first aggregate file.
The processor module 405, memory module 410, bridge module 415, network interface module 420, and storage interface module 425 may be fabricated of semiconductor gates on one or more semiconductor substrates. Each semiconductor substrate may be packaged in one or more semiconductor devices mounted on circuit cards. Connections between the processor module 405, the memory module 410, the bridge module 415, the network interface module 420, and the storage interface module 425 may be through semiconductor metal layers, substrate to substrate wiring, circuit card traces, and/or wires connecting the semiconductor devices.
The memory module 410 stores software instructions and data. The processor module 405 executes the software instructions and manipulates the data as is well know to those skilled in the art. The processor module 405 communicates with the network interface module 420 and the storage interface module 425 through the bridge module 415.
The client interface 225 may include the network interface module 420. The network interface module 420 may be configured as an Ethernet interface, a token ring interface, or the like. The storage interface module 425 may also be configured as an Ethernet interface, a token ring interface or the like in communication with a similarly configured data channel 445. The storage pool 430, copy pool 435, and next pool 440 may be configured as one or more logical volumes. Each logical volume may be organized as portions of one or more storage devices 210 as is well known to those skilled in the art.
In one embodiment, the memory module 410 stores and the processor module 405 executes one or more software processes comprising the copy module 205, reclamation module 310, restoration module 315, migration module 320, and aggregation module 325. The memory module 410 may also be configured as the transfer buffer 220 of
The schematic flow chart diagrams that follow are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of one embodiment of the presented method. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated method. Additionally, the format and symbols employed are provided to explain the logical steps of the method and are understood not to limit the scope of the method. Although various arrow types and line types may be employed in the flow chart diagrams, they are understood not to limit the scope of the corresponding method. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the method. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted method. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.
The method 500 begins and in one embodiment, the storage manager 205 receives 505 one or more data files from a client 105. The storage manager 205 may temporarily store the data files in the transfer buffer 220.
The copy module 305 copies 510 the data files to the storage pool 430. In addition, the copy module 305 concurrently copies 515 the data files to the copy pool 435. The copy module 305 further concurrently copies 520 the data files to a next pool 440 and the method 500 terminates.
In one embodiment, the storage manager 205 writes the data files from the transfer buffer 220 concurrently to storage pool 430, copy pool 435, and next pool 440. In one example, the storage manager 205 directs the storage pool 430, copy pool 435, and next pool 440 each to receive the data files from the data channel 445. The method 500 concurrently copies 510, 515, 520 the data files to the storage pool 430, copy pool 435, and next pool 440 to reduce subsequent copying of the data files as will be described hereafter.
The method 600 begins, and in one embodiment the storage manager 205 initiates 605 a migration operation. The storage manager 205 may periodically initiate 605 the migration operation. Alternatively, the storage manager 205 may initiate 605 the migration operation when the storage pool 430 exceeds a specified threshold of used storage space.
The migration module 320 may identify 610 one or more migration data file candidates in the storage pool 430. The migration data file candidates are referred to herein as migration data files. In one embodiment, the migration data files are inactive data files. The migration module 320 may identify 610 the migration data files when subsequent active instances of the migration data files are copied 510 to the storage pool 430.
The migration module 320 determines 615 if the migration data files are in the next pool 440. If the migration module 320 determines 615 that the migration data files are not in the next pool 440, the migration module 320 copies 620 the migration data files to the next pool 440. If the migration module 320 determines 615 that the migration data files are in the next pool 440 and/or when the migration data file is copied 620 to the next pool 440, the migration module 320 deletes the migration data files from the storage pool 430 and the method 600 terminates.
In one embodiment, the migration module 320 always determines 615 that the migration data file resides in the next pool 440 as the a result of the copy module 305 copying 520 the instances of the migration data files to the next pool 440 as described in
The method 700 begins and in one embodiment, the storage manager 205 initiates 705 a reclamation operation. The storage manager 205 may initiate 705 the reclamation operation when additional storage space is needed in the storage pool 230. Alternatively, the storage manager 205 may periodically initiate 705 the reclamation operation.
The reclamation module 310 may identify 710 an aggregate file to reclaim. In one embodiment, the reclamation module 310 identifies 710 the aggregate file that includes at least one inactive data file.
In one embodiment, the reclamation module 310 determines 715 if the aggregate file is in the next pool 440. If the reclamation module 310 determines 715 that the aggregate file is not in the next pool 440, the reclamation module 310 may copy 720 the aggregate file to the next pool 440.
If the reclamation module 310 determines 715 that the aggregate file is in the next pool 440 and/or when the aggregation file is copied 720 to the next pool 440, the aggregation module 325 aggregates 725 the aggregate file to a new aggregate file. In one example, the aggregation module 325 aggregates 725 the active data files of a first aggregate file to a second new aggregate file. The second new aggregate file may not include the inactive data files of the first aggregate file.
In one embodiment, the reclamation module 310 always determines 715 that the aggregate file resides in the next pool 440 as the a result of the copy module 305 copying 520 the instances of the each data file to the next pool 440 as described in
The reclamation module 310 further deletes 730 the aggregate file from the storage pool 430 and the method 700 terminates. The reclamation module 310 does not delete 730 the aggregate file from the storage pool 430 unless an aggregate file instance with the inactive data files exists in the next pool 440 so that the next pool 440 includes a copy of the inactive data files. Continuing the example above, the reclamation module 310 may delete 730 the first aggregate file from the storage pool 430 while the second aggregate file resides on the storage pool 430. Thus the storage space in the storage pool 430 occupied by the inactive data files of the first aggregate file is reclaimed.
In one example, file A 810, file B 815, and file C 820 each reside in the storage pool 430, copy pool 435, and next pool 440. The files 810, 815, 820 may be data files. In addition, the files 810, 815, 820 are aggregated into aggregate file A 805 on the storage pool 430, copy pool 435, and next pool 440. In one embodiment, file A 810, file B 815, and file C 820 are active data files.
The copy module 305 concurrently copies 510, 515, 520 file B′ 905 to the storage pool 430, copy pool 435, and next pool 440. In one embodiment, file B′ 905 is a subsequent instance of file B 815. Thus file B′ 905 is an active data file and file B 815 is an inactive file.
The aggregation module 325 aggregates 725 aggregate file A 805 into aggregate file B 1005 as part of the reclamation method 700. Aggregate file B 1005 does not include the inactive file B 815. The reclamation module 310 deletes 730 aggregate file A 805 to reclaim the storage space of inactive file B 815 in the storage pool 430. Therefore, the storage pool 430 as depicted only includes active files 810, 820, 905. Because the copy pool 435 and the next pool 440 may store inactive data files, the copy pool 435 and next pool 440 store both file B 815 and file B′ 905.
The embodiment of the present invention concurrently copies 510, 515, 520 one or more data files to multiple pools. In addition, the embodiment of the present invention may reduce subsequent copying of the data files.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
