WO2019026222A1 - ストレージシステム及びデータ転送制御方法 - Google Patents
ストレージシステム及びデータ転送制御方法 Download PDFInfo
- Publication number
- WO2019026222A1 WO2019026222A1 PCT/JP2017/028171 JP2017028171W WO2019026222A1 WO 2019026222 A1 WO2019026222 A1 WO 2019026222A1 JP 2017028171 W JP2017028171 W JP 2017028171W WO 2019026222 A1 WO2019026222 A1 WO 2019026222A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data
- storage device
- storage
- request
- volume
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
-
- 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/14—Error detection or correction of the data by redundancy in operation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/061—Improving I/O performance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0614—Improving the reliability of storage systems
- G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
- G06F3/065—Replication mechanisms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0653—Monitoring storage devices or systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0683—Plurality of storage devices
Definitions
- the present invention relates generally to data transfer between locations (between storage devices).
- base is an example of the “first base”
- central data center is an example of the “second base”.
- base refers to a base where a computer system such as a data center or a network segment is installed.
- the computer system at each site includes a storage device.
- Patent Document 1 discloses a technique for duplicating data of a first base to a second base by asynchronously transferring data updates made to the first base to the second base. ing. If this technique is applied between the distributed sites-central data center described above, all updated data is transferred to the central data center. In the technique of Patent Document 1, even when only a part of data is required for analysis, it is necessary to transfer all update data. For this reason, analysis can not be started until transfer of all data of each site to the central data center is completed, and there is a problem that utilization of analysis results in business is delayed. In addition to this, there is also a problem that the network bandwidth between each site and the central data center is consumed excessively.
- Patent Document 2 there is a technology disclosed in, for example, Patent Document 2 as a technology for making data in the first location accessible from the second location without requiring the completion of copying of all the data.
- Patent Document 2 in a plurality of storage devices, when a storage device that has received an access request does not hold data to be accessed according to the request, the external device transfers the access request to an external storage device. Get access target data from storage. Since this processing is processing on a volume basis, all data stored in a single volume is to be transferred. As a result, it is not possible to manage the fine granularity of leaving part of the data in the central data center. As a result, when the analysis process executed in the central data center accesses the data of the remote site, the data access of the analysis process involves the data copy between the sites, which causes the performance degradation of the analysis process.
- Patent Documents 3 and 4 are also known regarding data copying.
- the problem to be solved by the present invention is that, in the case where data stored in a plurality of first bases at the second base is to be accessed (for example, analysis target), the access performance of the second base is improved. It is possible to access the data of each first base without waiting for the completion of data copying from each first base to the second base while suppressing the decrease, and at the same time the first base and the second base Reduce network bandwidth consumption during
- a first storage device exists at the first location.
- a second storage device exists at the second site.
- the second storage device is a storage device connected to the first storage device via a network.
- a first storage device provides a first volume that can include a plurality of first elements, each of which is a volume area or a data set.
- a second storage device provides a second volume that can include a plurality of second elements, each of which is a volume area or data set and corresponds to a plurality of first elements.
- the first storage device transmits an update notification including the ID of the first element updated according to the write request from the first host to the second storage device.
- the data of the first element corresponding to the second element is the latest for the second element corresponding to the first element specified from the update notification Manage as data.
- the second storage device When the second storage device receives a read request from the second host, the data of the first element corresponding to the second element of the read source, which is the second element specified from the read request, is the latest data Determine if there is. If the determination result is true, the second storage device transmits an acquisition request for the latest data to the first storage device. The second storage device takes the latest data acquired from the first storage device in response to the acquisition request as the data of the read source second element, and returns the latest data to the second host.
- the second host can refer to the data in the first location without waiting for all data in the first location to be copied to the second location. Since the data acquired from the first site to the second site by this reference is stored at the second site, it can be used thereafter, and as a result, the access performance at the second site will be degraded thereafter. It can be expected to suppress. In addition, by reducing the amount of data transferred from the first site to the second site, it is possible to reduce the consumption of network bandwidth.
- FIG. 1 is a schematic view showing an outline of the first embodiment.
- FIG. 2 is a block diagram of a computer system in the first embodiment.
- FIG. 3 is a diagram showing a program and a table stored in the memory in the core controller in the first embodiment.
- FIG. 4 is a diagram showing an outline of a snapshot acquisition operation in the first embodiment.
- FIG. 5 is a configuration diagram of a snapshot management table in the first embodiment.
- FIG. 6 is a block diagram of the LU management table in the first embodiment.
- FIG. 7 is a block diagram of the update bit map table in the first embodiment.
- FIG. 8 is a configuration diagram of the LU mapping management table in the first embodiment.
- FIG. 9 is a block diagram of the copy status management table in the first embodiment.
- FIG. 1 is a schematic view showing an outline of the first embodiment.
- FIG. 2 is a block diagram of a computer system in the first embodiment.
- FIG. 3 is a diagram showing a program and a table stored in the memory
- FIG. 10 is a flowchart of the update notification process in the first embodiment.
- FIG. 11 is a flowchart of the core read process in the first embodiment.
- FIG. 12 is a block diagram of a computer system in the second embodiment.
- FIG. 13 is a diagram showing a program and a table stored in the memory in the file controller in the second embodiment.
- FIG. 14 is a block diagram of a first search table in the second embodiment.
- FIG. 15 is a block diagram of a second search table in the second embodiment.
- FIG. 16 is a diagram showing a program and a table stored in the memory in the object controller in the second embodiment.
- FIG. 17 is a configuration diagram of an object management table in the second embodiment.
- FIG. 18 is a block diagram of a stub data table in the second embodiment.
- FIG. 19 is a flowchart of a stub creation process in the second embodiment.
- FIG. 20 is a flowchart of object read processing in the second embodiment.
- FIG. 21 is a flowchart of data copy processing in the second embodiment.
- FIG. 22 is a block diagram of a computer system in the third embodiment.
- FIG. 23 is a block diagram of a computer system in the fourth embodiment.
- FIG. 24 is a block diagram of a migration stub data table in the fourth embodiment.
- FIG. 25 is a configuration diagram of a data request source management table in the fourth embodiment.
- FIG. 26 is a flowchart of the migration destination read process in the fourth embodiment.
- FIG. 27 is a schematic view showing an outline of the fifth embodiment.
- FIG. 28 is a configuration diagram of the LU mapping management table in the fifth embodiment.
- FIG. 29 is a flowchart of the write process in the fifth embodiment.
- FIG. 30 is a schematic view showing an outline of the sixth embodiment.
- FIG. 31
- the “interface unit” may include at least one of a user interface unit and a communication interface unit.
- the user interface unit includes at least one I / O device of one or more I / O devices (eg, input devices (eg, keyboard and pointing device), output devices (eg, display devices)), and a display computer.
- the communication interface unit may include one or more communication interface devices.
- the one or more communication interface devices may be one or more same type communication interface devices (for example, one or more NICs (Network Interface Card)) or two or more different types of communication interface devices (for example NIC and HBA (Host Bus) Adapter)).
- the “memory unit” includes one or more memories.
- the at least one memory may be volatile memory or non-volatile memory.
- the memory unit is mainly used in processing by the processor unit.
- the “processor unit” includes one or more processors. At least one processor is typically a microprocessor, such as a CPU (Central Processing Unit). Each of the one or more processors may be single core or multi-core.
- the processor unit may include a hardware circuit (eg, a circuit for parity calculation) that performs part or all of the processing.
- information may be described by an expression such as “xxx table”, but the information may be expressed by any data structure. That is, the "xxx table” can be called “xxx information” to indicate that the information does not depend on the data structure.
- the configuration of each table is an example, and one table may be divided into two or more tables, or all or part of two or more tables may be one table. Good.
- processing may be described with “program” as the subject, but the program is executed by the processor unit to appropriately execute the processing determined by the memory unit and / or the interface unit, etc.
- the subject of the process may be a processor unit (or an apparatus or system including the processor unit).
- the program may be installed on a device such as a computer from a program source.
- the program source may be, for example, a program distribution server or a computer readable (eg, non-transitory) recording medium.
- two or more programs may be realized as one program, or one program may be realized as two or more programs.
- the “distributed base” is an example of the first base.
- the “central data center” is an example of the second base.
- the “storage system” is a second storage system included in one or more first storage devices respectively owned by one or more first sites, and a second site for one or more first sites. And a storage device.
- Each storage device is configured of one or more storage machines.
- At least one storage machine may be a general-purpose physical computer, or may be a disk array device having two or more storage devices.
- at least one storage machine may be a virtual storage machine or may execute software-defined anything (SDx).
- SDx Software Defined Storage
- SDDC Software-defined Datacenter
- an SDS as a storage device and a virtual computer as a host computer may be executed on a computer system at the same site.
- volume is an abbreviation of logical volume and is a logical storage area.
- the volume may be a physical volume (RVOL) or a virtual volume (VVOL).
- the “RVOL” may be a volume based on physical storage resources (eg, one or more physical drives) of the storage system providing the RVOL.
- the “VVOL” may be a volume that is configured of a plurality of virtual areas (virtual storage areas) and that conforms to a capacity virtualization technology (typically, Thin Provisioning).
- FIG. 1 is a schematic view showing an outline of the first embodiment.
- the computer system 200 has one or more distributed bases 260 (an example of a first base) and one central data center 210 (an example of a second base).
- one distributed base 260 will be taken as an example.
- the distributed base 260 includes a host computer (hereinafter, host) 280 and a storage device (hereinafter, edge storage) 150.
- the host 280 is an example of a first host.
- the edge storage 150 is an example of a first storage device.
- the central data center 210 includes an analysis host computer (hereinafter, analysis host) 230 and a storage device (hereinafter, core storage) 120.
- the analysis host 230 is an example of a second host and is a host used for analysis.
- the core storage 120 is an example of a second storage device.
- the storage system includes edge storage 150 and core storage 120.
- the edge storage 150 provides the host 280 with a volume 151 (an example of a first volume).
- the edge storage 150 receives, from the host 280, an access request (write request or read request) specifying the volume 151.
- an access request write request or read request
- the edge storage 150 writes the data to be written according to the write request in the volume 151.
- the volume 151 is composed of a plurality of volume areas. Data to be written is written to one or more volume areas of the write destination.
- the volume 151 is a VVOL (volume according to Thin Provisioning), and the volume area is a page.
- the volume area is an example of an element in the volume.
- the core storage 120 provides the analysis host 230 with a volume 121 (an example of a second volume).
- the core storage 120 receives an access request specifying the volume 121 from the analysis host 230.
- the core storage 120 reads from the volume 121 data to be read according to the read request, and returns the read data to the analysis host 230 .
- the volume 121 is composed of a plurality of volume areas. Read target data is read from one or more volume areas at the read source.
- the volume 121 is a VVOL (volume according to Thin Provisioning), and the volume area is a page.
- Edge storage 150 manages update bitmap table 340.
- the update bitmap table 340 is a table for managing the presence or absence of update for each page (difference between volumes constituting a volume pair).
- the update bitmap table 340 has a page ID and an update flag for each page of the volume 151.
- the page ID and the update flag for each page are as follows.
- Page ID is the ID of the page.
- the update flag is a flag (bit) indicating the presence or absence of update of the page.
- the edge storage 150 updates the update flag from “OFF” to “ON”.
- the core storage 120 manages the copy status management table 370.
- the copy status management table 370 manages, for each page of the volume 121, whether or not the data acquisition target is to be acquired (whether or not the corresponding page in the edge storage 150 has the latest data).
- the copy status management table 370 has a page ID, an update flag, and an uncopied flag for each page of the volume 121.
- Page ID is the ID of the page.
- the update flag (an example of the first information element) is a flag indicating whether an update notification including the ID of the page corresponding to the page has been received since the last data copy from the edge storage 150 to the core storage 120 is there.
- the uncopied flag (an example of the second information element) is a flag indicating whether data is uncopied from the edge storage 150 to the corresponding page of the core storage 120 after the volume 121 is created (provided). It is.
- the page when at least one of the update flag and the non-copy flag for each page is "ON”, the page is a data acquisition target. If the update flag and the uncopied flag are "OFF”, the page is not a data acquisition target. That is, “latest data” is data that has been recently updated or data that has not been copied (acquired) even once, regardless of whether it has been updated.
- the edge storage 150 When the edge storage 150 receives a write request specifying the volume 151 from the host 280 (S1), it writes data in the write destination page (page belonging to the address specified by the write request). Also, if the edge storage 150 updates the update flag (the update flag in the update bitmap table 340) corresponding to the write destination page to "OFF", the update is updated to "ON" and an update notification including the page ID of the write destination page Are sent to the core storage 120 (S2). That is, when a page is updated, the edge storage 150 notifies the core storage 120 of the updated page. The core storage 120 that has received the update notification updates it to “ON” if the update flag corresponding to the page ID in the update notification is “OFF”. That is, the core storage 120 records, on the copy source volume 151, that an update has occurred in the notified page.
- the update flag the update flag in the update bitmap table 340
- the core storage 120 can know the page updated in the edge storage 150 from the update notification, when the update notification is received, the core storage 120 may not acquire the data in the page. This is because when the data is not to be read in accordance with the read request for analysis, data transfer accompanying the acquisition of the data is wasted.
- the core storage 120 When the core storage 120 receives a read request specifying the volume 121 from the analysis host 230 (S3), it is determined whether the read source page (page to which the address specified in the read request belongs) is the data acquisition target. .
- the core storage 120 copies (acquires) data from the copy source page (page in the volume 151 corresponding to the read source page) corresponding to the read source page (S4), copying
- the returned data is returned to the analysis host 230 as a response to the read request received in S3.
- the core storage 120 is "ON" for both the update flag and the uncopied flag corresponding to the read source page, the core storage 120 updates it to "OFF". Further, the update flag in the update bitmap table 340 may be set to “OFF” for the page storing the acquired data (page in the volume 151 corresponding to the read source page).
- the core storage 120 reads data from the read source page and returns the read data to the analysis host 230.
- FIG. 2 is a block diagram of the computer system 200. As shown in FIG. 1
- the computer system 200 comprises a central data center 210 and one or more distributed points 260.
- the central data center 210 and the distributed points 260 are connected to each other by a wide area network 250 (for example, WAN (Wide Area Network) or the Internet).
- the wide area network 250 may be an internal network.
- the edge storage 150 includes one or more storage media 295 and a controller (hereinafter, edge controller) 290 that controls input / output to the one or more storage media 295.
- the core storage 120 includes one or more storage media 245, and a controller (hereinafter, core controller) 240 that controls input / output to the one or more storage media 245.
- the edge controller 290 is an example of a first controller.
- the core controller 240 is an example of a second controller.
- a core controller 240 and one or more analysis hosts 230 are connected via an internal network 220 connected to a wide area network 250.
- the core controller 240 is a device that stores or provides data to which the analysis host 230 refers.
- the analysis host 230 can access the data stored by the core controller 240 and the edge to which the core controller 240 can be accessed transparently (without the analysis host 230 recognizing that the data is in the edge storage 150). It is a computer that accesses data in the storage 150 and performs processing or analysis.
- the core controller 240 has a function of making the data stored in the edge storage 150 at each of the distribution points 260 transparently accessible to the analysis host 230.
- the core controller 240 includes a CPU 241, a memory 242, a network interface 243, and a storage interface 244, which are internally connected to one another.
- the CPU 241 is an example of a processor unit, and controls the components of the core controller 240 according to the description of the program stored in the memory 242.
- the memory 242 is an example of a memory unit, stores a plurality of programs and tables, and has a disk cache.
- the network interface 243 and the storage interface 244 are an example of an interface unit.
- the core controller 240 processes an access request by the analysis host 230 through the internal network 220 through the network interface 243, and communicates with the edge controller 290 through the wide area network 250.
- a communication protocol via the network interface 243 Ethernet (registered trademark), Fiber Channel, Small Computer System Interface (SCSI), or the like can be used.
- the core storage controller 240 also reads and writes data from and to the storage medium 245 via the storage interface 244.
- a magnetic disk, an optical disk, a NAND flash, a non-volatile memory or the like can be used. Also, other storage controllers can be used hierarchically.
- SCSI Serial Attached SCSI
- SAS Serial Attached SCSI
- ATA Advanced Technology Attachment
- NVMe Non-Volatile Memory Express
- an edge controller 290 and one or more host totals 280 are connected via an internal network 270 connected to the wide area network 250.
- the edge controller 290 is a device that stores data generated by the host 280.
- the host 280 stores data generated and acquired by the host 280 in the edge storage 150.
- the edge controller 290 includes a CPU 291, a memory 292, a network interface 293, and a storage interface 294, which are internally connected to one another.
- the CPU 291 is an example of a processor unit, and controls the components of the edge controller 290 in accordance with the description of the program stored in the memory 292.
- the memory 292 is an example of a memory unit, stores a plurality of programs and tables, and has a disk cache.
- the network interface 293 and the storage interface 294 are an example of an interface unit.
- the edge controller 290 receives an access request by the host 280 via the internal network 270 via the network interface 293, and communicates with the core controller 240 via the wide area network 250. Also, the edge controller 290 reads and writes data from and to the storage medium 295 via the storage interface 294. As each communication protocol and storage medium 295 of the edge storage controller 290, one equivalent to the core storage controller 240 can be used.
- FIG. 3 is a diagram showing various programs and tables stored in the memory 242 in the core controller 240 and the memory 292 in the edge controller 290.
- both memories 242 and 292 will be collectively referred to as “memory 300”.
- Some of the programs and tables in the memory 300 may exist only in one of the memories 242 and 292, but such elements will be described separately. Each element is included in both memories 242 and 292 unless otherwise noted.
- the input / output control program 310 When the core controller 240 or the edge controller 290 receives an access request from the analysis host 230 or host 280, the input / output control program 310 performs inter-base data transfer processing by the remote copy program 350 as necessary. Is a program that reads and writes data in the storage medium 245 or 295 and returns the result to the analysis host 230 or host 280.
- the input / output control program 310 configures and manages LU (Logical Unit), which is a management unit of volumes visible to the analysis host 230 and the host 280.
- the LU is generated by dividing or linking areas of the storage medium 245 or 295. LU may be synonymous with volume.
- the input / output control program 310 can also be accompanied by a redundancy mechanism such as area duplication, redundant array of independent (or inexpensive) disks (RAID), erasure coding, and the like.
- the input / output control program 310 has a function of creating and managing snapshots of LUs.
- the LU management table 320 stores LU configuration information.
- the snapshot management table 330 stores configuration information of snapshots of LUs.
- the update bitmap table 340 is temporarily stored when exchanging bitmap information necessary for snapshot management using CoW (Copy on Write) between bases.
- the remote copy program 350 is a program that communicates with the core controller 240 and the edge controller 290 via the network interface 243 or 293 and the wide area network 250 to transmit and receive data.
- the LU mapping table 360 is a table that is held only by the core controller 240, and is a table that manages association between LUs managed by the core controller 240 and LUs managed by the edge controller 290.
- the copy state management table 370 is a table held only by the core controller 240.
- the copy state management table 370 indicates whether data acquisition from the edge controller 240 is necessary for each area of the LU.
- all or a part of the surplus area other than the area storing the various program tables can be used as the disk cache 380 of the storage medium 245 or 295.
- FIG. 4 is a diagram showing an outline of operations of snapshot acquisition of each of the core controller 240 and the edge controller 290. As shown in FIG. Hereinafter, the core controller 240 will be taken as an example.
- the LU of the access destination of the analysis host 230 is P-vol (Primary Volume) 420.
- the snapshot of P-vol is S-vol (Snapshot Volume) 441.
- S-vol 441 exists for each generation.
- An LU for managing inter-generational differences is D-vol (Differential Volume) 430.
- P-vol 420 and D-vol 430 are stored (or associated) in pool 400 built on one or more storage media 245.
- the S-vol 441 is a virtual volume configured of the P-vol 420 and the D-vol 430, and the S-vol itself is not stored on the storage medium 245. Further, since S-vol 441 exists for each snapshot generation, a plurality of P-vols can be created.
- Each of P-vol 420, D-vol 430, and S-vol 441 is managed in units of fixed-length volume areas (page 411). Each page 411 in each S-vol 441 is associated with the page 411 in the same position in P-vol 420 or page 411 in D-vol 430.
- the core controller 240 receives an access request specifying S-vol 441 from the analysis host 230, the access request corresponds to the access destination page specified in the access request, P-vol 420 or D-vol 430.
- This correspondence relationship is managed by the snapshot management table 330 in the core controller 240.
- pages in P-vol may be called "P-vol pages”
- pages in D-vol may be called “D-vol pages”
- pages in S-vol may be called "S-vol pages” it can.
- the pool 400 may include, for example, a plurality of real areas based on one or more storage media 245. Each real area is a logical storage area. A part of the real areas of the plurality of real areas may be a plurality of D-vol pages constituting the D-vol 430. Also, the real area may be allocated to the P-vol page of P-vol which is a VVOL. Also, a real area may be allocated to a D-vol page when D-vol is also a VVOL.
- FIG. 5 is a configuration diagram of the snapshot management table 330.
- the snapshot management table 330 exists for each LU corresponding to the P-vol 420.
- the snapshot management table 330 can specify the corresponding P-vol page or D-vol page as a reference destination of the S-vol page by the ID of the P-vol page and the generation number of the snapshot.
- the snapshot management table 330 has an entry for each page in P-vol. Each entry stores information such as a page ID 451, a CoW flag 452, and a reference page ID 453.
- one P-vol page is taken as an example (referred to as “target page” in the description of FIG. 5).
- the page ID 451 is an identifier that uniquely indicates the target page.
- a serial number may be assigned to the page group constituting the volume from the top, or a hash value or the like may be used. In the example of the figure, a serial number starting from 0 is assigned as the page ID 451 of P-vol.
- the CoW flag 452 indicates whether or not CoW (to save data in the target page when the target page is a write destination) is necessary for the target page. "ON" means that CoW is required.
- the reference destination page ID 453 is a page ID of the reference destination page of the S-vol page corresponding to the target page for each snapshot generation. Specifically, “ ⁇ 1” indicates the ID of the P-vol page at the same position, that is, the page ID of the target page. Values other than “ ⁇ 1” indicate the ID of the D-vol page.
- the core controller 240 may previously obtain the presence or absence of the reference destination page ID 453 “ ⁇ 1”, and prepare the value of the CoW flag 452 according to the presence or absence.
- the data in P-vol Is shared with the snapshot.
- the core controller 240 saves the data using the CoW.
- the core controller 240 When the P-vol page corresponding to the Cow flag 452 “ON” is the update target (write destination), the core controller 240 performs the following. Copy the data in the P-vol page to be updated to the free D-vol page. -Relocate the reference destination page IDs of all S-vol pages referencing the P-vol page to the page IDs of the copy destination D-vol page. -Update data in the P-vol page to be updated. Change the Cow flag 452 to "OFF".
- the core controller 240 When the P-vol page corresponding to the Cow flag 452 “OFF” is to be updated, the core controller 240 performs the following. -Update data in the P-vol page to be updated.
- the core controller 240 performs the following. -Copy the data in the reference P-vol page of the S-vol page to be updated to the free D-vol page. -Relocate the reference destination page ID of the S-vol page to be updated to the page ID of the copy destination D-vol page. Update the data in the copy destination D-vol.
- the core controller 240 When creating a snapshot, the core controller 240 creates an S-vol associated with a new generation number, and allows the snapshot management table 330 to store reference destination information of the generation. At this moment, since the contents of P-vol and S-vol are equal at the moment of creating the snapshot, the core controller 240 sets the reference destination page ID 453 of all the S-vol pages of the S-vol concerned to "-1". And, the CoW flag 452 of all P-vol pages of the P-vol concerned is set to "ON".
- FIG. 6 is a configuration diagram of the LU management table 320.
- One LU management table 320 exists in each of the core controller 240 and the edge controller 290 for each controller.
- the LU management table 320 has an entry for each LU.
- the LU referred to here corresponds to any of P-vol, D-vol and S-vol.
- Each entry stores information such as LUN 521 and size 522.
- target LU in the description of FIG. 6).
- the LUN 521 is a LUN (Logical Unit Number) which is an example of an ID of a target LU.
- the size 522 indicates the size (capacity) of the target LU.
- FIG. 7 is a block diagram of the update bit map table 340. As shown in FIG.
- the update bit map table 340 is a table that is temporarily generated to exchange information indicating presence / absence of update of each page constituting an LU between the edge controller 290 and the core controller 240.
- the update bitmap table 340 exists for each volume pair (LU pair).
- the volume pair referred to here is a pair of a volume that can be referenced by the analysis host 230 (a volume provided by the core storage 120) and a volume that can be updated by the host 280 (a volume provided by the edge storage 150).
- the update bitmap table 340 has an entry for each page of the volume. Each entry stores information such as a page ID 541 and an update flag 542.
- one page will be taken as an example (referred to as “target page” in the description of FIG. 7).
- the page ID 541 is a page ID of the target page.
- the update flag 542 is a flag (bit) indicating whether the target page has been updated.
- page ID 541 and the update flag 542 another data structure including equivalent content may be used for the target page.
- a data structure in which only page IDs for which update flags are set are listed as a list, or a data structure in which the amount of data is reduced by an algorithm such as Run Length for a bitmap can be applied.
- the update bit map table 340 is, for example, the difference between the volume of the latest generation n (volume in the edge storage 150) and the volume of the generation (for example, snapshot generation (n-1)) when the update notification was sent last time It may be a table indicating the updated page ID).
- the update notification may include the update bitmap table 340.
- FIG. 8 is a configuration diagram of the LU mapping management table 360.
- the LU mapping management table 360 is a table stored by the core controller 240.
- the LU mapping management table 360 has an entry for each LU in the core storage 120.
- Each entry stores information such as a LUN 561, a copy source storage 562, a copy source LUN 563, and a copy source generation number 564.
- one LU will be taken as an example (referred to as “target LU” in the description of FIG. 8).
- the LUN 561 is a LUN of a target LU.
- the copy source storage 562 is an ID (for example, an address) of the edge storage 120 having the copy source LU of the target LU (the LU that forms a pair with the target LU).
- the copy source LUN 563 is the LUN of the copy source LU of the target LU.
- the copy source generation number 564 indicates the generation number associated with the copy source LU of the target LU. “0” means that the copy source LU is P-vol, and a number larger than “0” may mean that the copy source LU is S-vol.
- the copy source LUN 563, and the copy source generation number 564, the edge controller 290 in the distribution base 260 and the LU (generation) managed by the edge controller 290 can be uniquely identified.
- the copy source storage 562 for example, an IP address or host name in TPC / IP, WWN (World Wide Name) in Fiber Channel, or a Qualified Name in iSCSI can be used.
- FIG. 9 is a block diagram of the copy status management table 370. As shown in FIG.
- the copy state management table 370 is a table stored by the core controller 240.
- the copy status management table 370 exists for each LU that configures a volume pair.
- the copy status management table 370 has an entry for each page. Each entry stores information such as a page ID 571, an update flag 572, and an uncopied flag 573.
- a page ID 571 a page ID 571
- an update flag 572 a flag that is updated
- uncopied flag 573 uncopied flag
- the page ID 571 is an ID that uniquely identifies a target page.
- the update flag 572 indicates whether or not updating of the target page has been notified from the edge controller 290 to the core controller 240 since the last data copy from the edge controller 290 to the core controller 240 for the target page.
- the uncopied flag 573 indicates whether data has not been copied to the target page from the edge controller 290 to the core controller 240 after the LU corresponding to the table 370 is created by the core controller 240.
- FIG. 10 is a flowchart of the update notification process.
- the update notification process is started when an edge controller 290 creates a snapshot.
- the edge controller 290 receives the following two snapshot generation numbers as input. ⁇ Snapshot created this time. A snapshot corresponding to the generation number 564 transmitted when the update bitmap table 340 was transmitted to the core controller 240 last time.
- the edge controller 290 transmits, as an output, to the core controller 240 an update bitmap table 340 indicating whether each page has been updated between the two snapshots.
- the detailed procedure of the update notification process is, for example, as follows.
- the edge controller 290 generates the update bit map table 340 based on the snapshot management table 330 (step 610).
- the update bit map table 340 indicates whether or not an update has occurred on each page between snapshots of two generation numbers given as input. The presence / absence of updating of each page can be determined to be updating, for example, due to a mismatch between reference destination pages of both generations of the snapshot management table 330.
- the edge controller 290 relates the generated update bitmap table 340 with the generated snapshot (S-vol) LUN and the newer generation number of the input, and the update bitmap is associated with the LUN and generation number
- the table 340 is sent to the core controller 240 via the wide area network 250 (step 620).
- the core controller 240 When the core controller 240 receives the update bit map table 340 (and the LUN and generation number) from the edge controller 290 (step 630), it starts updating the copy state management table 370.
- the core controller 240 refers to the LU mapping management table 360, searches the corresponding entry including the copy source storage 562 and the copy source LUN 563 that match the source edge controller 290, the sent LUN, and searches the LUN 561 in the corresponding entry. Identify.
- the core controller 240 refers to the entry corresponding to each page in the update bit map table 340, and updates the update flag 572 of the entry whose page ID 571 matches in the copy state management table 370 corresponding to the specified LUN 561.
- Overwrite with the update flag 542 (step 640). When the overwrite process is completed for all pages, the core controller 240 overwrites the received generation number on the copy source generation number 564 of the corresponding entry (entry in the LU mapping management table 360) (step 650).
- FIG. 11 is a flowchart of the core read process started when the core controller 240 receives a read request for an LU from the analysis host 230.
- the core controller 240 refers to the entry in the copy status management table 370 corresponding to the LU and page to be read specified in the read request (step 710).
- the core controller 240 refers to the LU mapping management table 360 to identify the copy source storage 562, the copy source LU 563 and the copy source generation number 564 corresponding to the LU to be read,
- the data acquisition request for the LU and snapshot is sent (step 720). Then, in response to the acquisition request, the core controller 240 writes the data acquired from the copy source edge controller 290 to the LU to be read.
- the core controller 240 sets both the update flag 572 and the uncopied flag 573 in the copy status management table 370 to “OFF” because the contents of the page of the read target LU match the contents of the page of the copy source LU. Thereafter, the core controller 240 reads data in the LU to be read (data acquired and stored from the edge controller 290), and returns it to the analysis request host 230 for analysis of the read request (step 730).
- the analysis host 230 can transparently access data in the edge storage 150. Therefore, the core controller 240 can access the data stored in the edge storage 150 without completion of copying of the data stored in the edge storage 150. Also, at the time of reference, only the page in which the target data is stored is transferred through the wide area network 250, and data not referred to is not transferred. As a result, the transfer amount of the wide area network 250 can be reduced and the transfer time can be shortened, and the amount of data copied (acquired) by the core controller 240 from the edge controller 290 (replication amount of the core controller 240) can be reduced.
- the data access from the edge controller 290 becomes unnecessary in the subsequent access, and the deterioration of access performance can be suppressed. it can.
- copying of data from the edge controller 290 to the core controller 240 is performed when the page specified by the read request is received from the analysis host 230 in response to the read request, but the page is the data acquisition target page.
- reception of a read request may be performed asynchronously. In this case, when asynchronous copying is completed for the page read by the analysis host 230 for the first time, since the latest data is already stored in the page, it is not necessary to acquire data via the wide area network 250. It can be expected that the read response time can be accelerated.
- the analysis host 230 refers to the data stored in the edge storage 150 via the core controller 240. It is possible. When the core storage 120 is newly connected to the edge storage 150 or a large amount of data is generated in the edge storage 150, since it is not necessary to actually wait for all data held by the edge storage 150 to be copied to the core controller 240. Even if this is done, it can be expected that the analysis host 230 will refer to the data of the edge storage 150 immediately.
- Example 2 will be described. Hereinafter, differences from the first embodiment will be mainly described, and the description of the points common to the first embodiment will be simplified or omitted.
- edge storage and core storage it replaces the device that receives the access request specifying the LUN and address (for example, LBA (Logical Block Address)) described in the first embodiment and accesses data according to the request.
- LBA Logical Block Address
- An apparatus for accessing in units of data sets such as files and objects may be employed.
- a file storage may be disposed at each site, and data stored in the file storage may be copied to a storage system that provides data access in object units, such as cloud storage.
- object units such as cloud storage.
- the “data set” is one block of logical electronic data viewed from a program such as an application program, and may be, for example, any of a record, a file, an object, a key-value pair, and a tuple.
- data sets such as files, directories and objects are an example of elements within the volume.
- FIG. 12 is a block diagram of a computer system 800 in the second embodiment.
- an object storage 802 (an example of a second storage device) and one or more analysis hosts 830 (an example of a second storage device) via an internal network 820 connected to the wide area network 850.
- An example of the second host is connected.
- a file gateway 831 may be connected.
- the object storage 840 is a device for storing and providing data referenced by the analysis host 830 in object units.
- the object storage 802 has one or more storage media 848 and a controller (hereinafter, object controller) 840 for controlling input / output to the one or more storage media 848.
- the analysis host 830 is a computer that accesses and processes or analyzes data stored in the object storage 802 and data in the file storage 801 of the distributed base 860 transparently accessible to the object controller 840. If the analysis host 830 does not have a data access function in object units, the object storage 840 is indirectly stored using a file gateway 831 that converts data access in file units and data access in object units separately. Access the data you Hereinafter, access to data in the object storage 840 by the analysis host 830 also includes indirect access via the file gateway 831.
- the directory hierarchical structure is stored in the object storage 802 from the file storage 801, the hierarchical structure is not maintained in the object storage 802, but the file gateway 831 holds information representing the hierarchical structure. That is, the file gateway 831 manages the hierarchical structure of objects in the object storage 802. For example, in response to a request (query) specifying a path name (file name), the file gateway 831 can return an object ID corresponding to the path name.
- the object controller 840 has a function of enabling the data stored in the file storage 890 (an example of the first storage device) in each of the distribution bases 860 (an example of the first base) to be transparently accessible to the analysis host 830.
- the object controller 840 (an example of a second controller) includes a CPU 841, a memory 842, a network interface 843 and a storage interface 844, which are internally connected to one another.
- the CPU 841 controls the components of the object controller 840 in accordance with the description of the program stored in the memory 842.
- the memory 842 stores a plurality of programs and tables, and has a disk cache.
- the object controller 840 processes an access request by the analysis host 830 through the internal network 820 via the network interface 843 and communicates with the file storage 890 through the wide area network 850. Further, the object controller 840 reads and writes data from and to the storage medium 845 via the storage interface 844 and stores object data 846, an object management table 847, and stub data 848 in the storage medium 845. These data may be stored by dividing the area of the storage medium 845 as it is by functions such as partitions or LVM (Logical Volume Management), or a file system is constructed on the storage medium 845 and stored in file units. It is also good.
- LVM Logical Volume Management
- a communication protocol via the network interface 843 As a communication protocol via the network interface 843, a REST (Representational State Transfer) protocol using HTTP (Hypertext Transfer Protocol) or a protocol of the network interface 243 and the storage interface 244 can be used. Also. The communication protocol between the storage interface 844 and the storage medium 845 can utilize the protocol of the storage interface 244.
- the file storage 801 includes one or more storage media 895 and a controller (hereinafter, file controller) 890 that controls input / output to the one or more storage media 895.
- the file controller 890 (an example of a first controller) includes a CPU 891, a memory 892, a network interface 893, and a storage interface 894, which are internally connected to one another.
- the CPU 891 controls the components of the file controller 890 in accordance with the description of the program stored in the memory 892.
- the memory 892 stores a plurality of programs and tables, and has a page cache.
- the file controller 890 receives an access request by the host 880 through the internal network 870 through the network interface 893, and communicates with the object storage 840 in the central data center 810 through the wide area network 850. Also, the file controller 890 reads and writes data from and to the storage medium 895 via the storage interface 894, and constructs a file system 896 on the storage medium 895.
- each communication protocol of the file controller 890 one equivalent to the object storage 840 such as NFS (Network File System) or SMB (Server Message Block) can be used.
- the communication protocol between the storage interface 894 and the storage medium 895 can utilize the protocol of the storage interface 244.
- the file system 896 is an example of the first volume.
- the area where the object data 846 and the stub data 848 are stored is an example of the second volume.
- the storage apparatus in each of the distribution bases 860 may be object storage instead of file storage.
- the storage device in the central data center 810 may be file storage instead of object storage.
- one of the distributed base 860 and the central data center 810 is a file or a directory and the other is an object, the type of data set stored by the dispersed base 860 and the type of data set stored by the central data center 810 are different. It is an example of being different. If the type of the data set is different, the configuration of the ID of the data set is different, so it is necessary to manage the correspondence relationship of the ID of the data set using, for example, a table as shown in FIG. It is preferable to further have a table as shown in FIG.
- FIG. 13 is a view showing various programs and tables stored in the memory 892 in the file controller 890.
- the memory 892 stores a file system program 911, a data transfer program 912, a first search table 913, a second search table 914, and object storage information 915.
- the memory 892 has a page cache 916.
- the page cache 916 may be a surplus area of the memory 892 (at least a part of an area other than the area where various programs and tables are stored).
- the file system program 911 is a program that constructs a file system on the storage medium 896 and realizes data access and data storage in directory and file units.
- the file system program 911 also responds to a file access request (access request to a directory or file by the host 880) via the internal network 870.
- a file access request access request to a directory or file by the host 880
- NFS Network File System
- SMB Server Message Block
- AFP Apple Filing Protocol
- the data transfer program 912 is a program for transmitting and receiving data with the object storage 840 in the central data center 810.
- FIG. 14 is a block diagram of the first search table 913. As shown in FIG. 14
- the first search table 913 is a table showing the correspondence between a directory or file on the file system and an object in the object storage 840, and is a table for searching for an object ID from the file path name.
- the first search table 913 has an entry for each directory or file. Each entry stores information such as path name 921, type 922 and object ID 923.
- path name 921, type 922 and object ID 923 stores information such as path name 921, type 922 and object ID 923.
- target data set one data set (directory or file) will be taken as an example (referred to as “target data set” in the description of FIG. 14).
- the path name 921 indicates the path name to the target data set.
- the path name 921 may be an example of the ID of the target data set.
- the type 922 indicates the type of target data set ("/" (root directory), "directory” or "file”).
- the object ID 923 is an ID for uniquely identifying an object corresponding to the target data set.
- the first search table 914 By using the first search table 914, it is possible to transmit an update notification including an object ID corresponding to a file or a directory.
- the first search table 913 is managed in such a manner that an entry can be searched from the path name 921 at high speed by holding an index such as a hash value for the path name 921.
- FIG. 15 is a block diagram of the second search table 914. As shown in FIG.
- the second search table 914 is a table indicating the correspondence between objects and directories or files, and is a table for searching for path names from object IDs.
- the second search table 914 has an entry for each object. Each entry stores information such as an object ID 931 and a path name 932.
- object ID 931 stores information such as an object ID 931 and a path name 932.
- target object one object will be taken as an example (referred to as “target object” in the description of FIG. 15).
- the object ID 931 is an ID of a target object.
- Path name 932 indicates the path name to the data set corresponding to the target object,
- the second search table 914 By using the second search table 914, it is possible to specify a file or a directory corresponding to the object ID at high speed in response to an acquisition request specifying the object ID. By holding an index such as a hash value for the object ID 931, the entry can be managed in a manner that can be searched at high speed from the object ID 931.
- first search table 913 and the second search table 914 are tables including the same contents, one entry may be shared if the entries can be searched at high speed by both the path name and the object ID.
- FIG. 16 is a view showing various programs and tables stored in the memory 842 in the object controller 840.
- the memory 842 stores an object control program 1011, an object management table 1012 and a stub data table 1013.
- the memory 842 has a disk cache 1014.
- the disk cache 1014 may be a surplus area of the memory 842 (at least a part of the area other than the area storing various programs and tables).
- the object control program 1011 is a program that performs data input / output in object units and responds to an access request from the analysis host 830.
- the object storage 840 can also classify objects in units called a plurality of buckets instead of managing all objects uniformly. In that case, the analysis host 830 identifies the access target by the pair of bucket ID and object ID.
- FIG. 17 is a configuration diagram of the object management table 1012.
- the object management table 1012 is a table indicating information on objects managed by the object control program 1011.
- the object management table 1012 has an entry for each object. Each entry stores information such as object ID 1021, update flag 1022, stub flag (equivalent to uncopied flag) 1023, size 1024 and storage destination 1025.
- object ID 1021 object ID 1021
- update flag 1022 update flag 1022
- stub flag equivalent to uncopied flag
- size 1024 size 1024
- storage destination 1025 storage destination
- one object is taken as an example (referred to as “target object” in the description of FIG. 17).
- the object management table 1012 may have corresponding columns.
- An object ID 1021 is an ID of a target object.
- the update flag 1022 indicates whether an update notification including the ID of the target object has been sent from the file controller 890 to the object controller 840 since the previous data copy of the target object from the file storage 801 to the object storage 802.
- the stub flag 1023 determines whether the target object has not been copied from the file storage 801 to the object storage 802 after creating the LU (object storage space) (whether or not the stub exists instead of the target object) Indicates
- the storage destination 1025 indicates the storage position of the data of the target object (the position in the storage medium 845). As the storage destination 1025, the path name of the file system, the LBA on the LU, and the like are stored.
- the object management table 1012 may exist for each bucket, or a row of bucket IDs is added on one object management table 1012 and an entry (row) on the object management table 1012 is specified by a pair of bucket ID and object ID. It may be possible.
- FIG. 18 is a configuration diagram of the stub data table 1031.
- the stub data table 1031 has an entry for each object. Each entry stores information such as a bucket ID 1031, an object ID 1032, and a data acquisition destination 1033.
- a bucket ID 1031 stores information such as a bucket ID 1031, an object ID 1032, and a data acquisition destination 1033.
- one object is taken as an example (referred to as “target object” in the description of FIG. 18).
- the bucket ID 1031 is an ID of a bucket for storing a target object.
- An object ID 1032 is an ID of a target object.
- the data acquisition destination 1033 indicates the position (the position on the file storage 801) at which the data set corresponding to the target object is stored.
- the data acquisition destination 1033 is represented by, for example, a combination of the identifier of the file storage 801 and the file sharing name on the file storage 801.
- the stub data table 1031 may have a format other than that shown in the figure as long as it indicates the correspondence between an object and a data acquisition destination. For example, if all objects in the bucket are associated with the same data acquisition destination, the column of the object ID 1032 is unnecessary.
- the stub data table 1013 enables data to be acquired transparently from the file storage 890 indicated by the data acquisition destination 1033 when the analysis host 830 is accessed.
- FIG. 19 is a flow diagram of a stub creation process.
- the stub creation process is a process executed when the file storage 801 registers stub data corresponding to a file or directory held by itself in the object storage 802. For example, when a new file is added to the file storage 801, a stub creation process is executed, or a file group (one or more files) created during the period (for example, one day) every fixed period (for example, every day)
- the stub creation process may be executed collectively for the file.
- the stub creation processing targets one data set (file or directory) (“target data set” in FIG. 19)
- the file controller 890 executes a plurality of stub creation processings in parallel or in series. You can also complete stub creation for the file or directory.
- the file controller 890 determines an object ID to be stored in the object controller 840 for the target data set (step 1110).
- the object ID may be generated by the file controller 890 or by the object controller 840 as long as uniqueness is maintained.
- the file controller 890 adds an entry storing the path name 921 corresponding to the target data set, the type 923, and the object ID 924 to the first search table 913 (step 1120).
- the file controller 890 adds an entry storing the path name 931 and the object ID 932 corresponding to the target data set to the second search table 914 (step 1130).
- the file controller 890 sends the object controller 840 a stub creation request (a request to create a stub of the object) that associates the determined object ID with the attribute (size etc.) of the object (step 1140). .
- the object controller 840 When the object controller 840 receives a stub creation request from the file controller 890, the object controller 840 creates an entry of the corresponding stub data table 1031 in response to the stub creation request (step 1150). In the entry created in step 1150, the object ID 1021 associated with the stub creation request is stored.
- the object controller 840 creates an entry of the object management table 1012 (step 1160).
- the entry created in step 1160 stores the object ID 1021 and the size 1024 associated with the stub creation request by the file controller 890. Further, in the entry created in step 1160, the update flag 1022 is set to "OFF" and the stub flag 1023 is set to "ON".
- the object controller 840 creates a stub which is a stub of the object specified in the stub creation request and is recognized by the analysis host 830.
- FIG. 20 is a flowchart of object read processing performed when the object controller 840 receives an object acquisition request from the analysis host 830 or the file gateway 831.
- the object storage 840 When the object storage 840 receives an acquisition request for an object, the object storage 840 refers to the object management table 1012 using the object ID included in the acquisition request, and the target storage (the object specified from the object ID included in the acquisition request) It is determined whether at least one of the update flag 1022 and the stub flag 1023 is "ON" (step 1210).
- the update flag 1022 “ON” means that an update notification has been received from the file controller 890 because the file or directory corresponding to the target object has been updated on the file storage 801.
- a method of sending a list of updated object IDs from the file controller 890 to the object controller 840 can be considered.
- the object controller 840 sets the update flag corresponding to the object ID in the object management table 1012 to “ON” for each object ID included in the list.
- the stub flag 1023 "ON” means that data of the file or directory corresponding to the object data 846 is not held. Therefore, when at least one of the update flag 1022 and the stub flag 1023 is "ON", it means that the data of the object needs to be acquired from the file storage 801. In that case, the object controller 840 starts data copy processing (FIG. 21) so that the object data 846 matches the data of the file or directory in the file system 896 (step 1220). Thereafter, the object controller 840 reads the data 846 of the target object, and returns the read data to the transmission source of the object acquisition request (step 1230).
- FIG. 21 is a flowchart of data copy processing. Data copy processing may be performed during object read processing, or may be performed in the background while the object controller 840 is performing other processing.
- the object controller 840 refers to the stub data table 1013 and identifies the corresponding data acquisition destination 1033 using the object ID of the target object (object to be processed) and the bucket ID of the bucket in which the target object is stored. (Step 1305).
- the object controller 840 transmits an acquisition request associated with the object ID as an argument to the file controller 890 of the data acquisition destination 1033 acquired in step 1305 (step 1310).
- the file controller 890 that has received the acquisition request specifies the path name 932 of the file or directory corresponding to the target object using the second search table 914 based on the object ID of the argument (step 1315). Data of the file or directory according to the path name 932 is read from the file system 896 (step 1320). When the destination indicated by the path name 932 is a directory, the file controller 890 performs stub creation processing on all child data sets (each file and sub directory) stored in the directory (steps 1325 and 1330). That is, a stub for each data set in the directory is created on the file system. As a result, an object of the object storage 802 can be used to restore the namespace (hierarchical structure) in the file storage 801.
- the file controller 890 controls the file or directory data corresponding to the path name (in the case of a directory, "data" means a file name and a subdirectory name (path) as information of files and subdirectories stored in the directory). Returning a list of object names and corresponding object IDs) to the object storage 840 (step 1335).
- the object controller 840 When the object controller 840 receives the response from the file controller 890, it writes the received data as object data 846 (step 1340). Subsequently, the object controller 840 turns the update flag 1022 and the stub flag 1023 of the object management table 1012 "OFF" (step 1345).
- the analysis host 830 can transparently access the data stored in the file storage 801 of the distribution base. As a result, the data copy from the file storage 801 to the object storage 802 is not completed, and the data in the file storage 801 can be referenced from the analysis host 830. Also, at the time of reference, only the object in which the target data is stored is transferred between the distributed base 860 and the central data center 810 through the wide area network 850, and the object which is not referred is not transferred. As a result, the transfer amount of the wide area network 850 can be reduced and the transfer time can be shortened, and the amount of data copied from the file storage 801 by the object storage 802 (replication amount of the object storage 802) can be reduced.
- the object controller 840 when the object controller 840 receives a read request for an object corresponding to a directory, it constructs stub data of files and subdirectories in the directory. Therefore, if only the stub data corresponding to the root directory is stored, the object controller 840 recursively stubs out the components of the path in response to the data acquisition request from the analysis host 830 or the file gateway 831. Copy processing can be performed. Therefore, when object storage 802 is newly connected to file storage 801, or when a large number of files (and directories) are generated in file storage 801, the process waits for copying of data in file storage 801 to object storage 802. It can be expected that the analysis host 830 and the file gateway 831 can immediately refer to the file or directory of the file storage 801 without.
- Example 3 will be described. Hereinafter, differences from the first embodiment will be mainly described, and the description of the points common to the first embodiment will be simplified or omitted.
- data may be migrated from an old storage device to a newly purchased storage device.
- LBA an address
- FIG. 22 is a block diagram of a computer system 1400 in the third embodiment.
- the computer system 1400 comprises a central data center 210 and one or more distributed points 1460.
- Central data center 210 and distributed points 1460 are connected to each other by wide area network 250.
- the central data center 210 has the same configuration as that of the first embodiment.
- the distribution base 1460 has almost the same configuration as the distribution base 260 in the first embodiment, but as an edge controller, a migration source edge controller (edge controller of migration source edge storage 1401) 1410 and a migration destination edge controller (migration destination edge storage 1402) And the edge controller) 1420.
- An example of the migration source edge storage 1401 is the old storage device.
- An example of the migration destination edge storage 1402 is a new storage device.
- the source edge controller 1410 and the destination edge controller 1420 can communicate with each other via the internal network 270. It is assumed that the data and LU configuration stored in the migration source edge storage 1401 are being migrated to the migration destination edge storage 1402. For data migration between controllers 1410 and 1420, the method shown in Patent Document 3 is applicable. When data migration according to the method shown in Patent Document 3 is used, the host 280 can transfer source edge storage via the migration destination edge storage 1402 even when data migration from the migration source edge controller 1410 to the migration destination edge controller 1420 is incomplete. The data of 1401 can be transparently referenced.
- step 720 of the core read process of FIG. 11 can be applied to data migration from the migration source edge controller 1410 to the migration destination edge controller 1420.
- the copy source storage 532 and the copy source LUN 563 in the LU mapping management table 562 held by the core controller 240 are set to refer to the LU on the migration destination edge controller 1420.
- the data acquisition request of the core controller 240 is transmitted to the transition destination edge controller 1420.
- the migration destination edge controller 1420 has a function for transparently referring to the data of the migration source edge storage 1401 in the host 280.
- the migration destination edge controller 1420 applies the function of transparently referring to the data of the migration source edge storage 1401 to obtain the data in the migration source edge storage 1401. It can be acquired.
- the analysis host 230 in the central data center 210 is the migration source edge storage 1401 and Regardless of the location of the data between the migration destination edge storages 1402, the data in the distributed base 1460 can be referenced via the core controller 240.
- the migration source edge storage 1401 may exist outside the distributed base 1460.
- the migration source edge storage 1401 is an example of a third storage device.
- the migration destination edge storage 1402 receives an acquisition request from the core storage 120 while migrating data from the migration source edge storage 1401 to the migration destination edge storage 1402, the latest data of acquisition target according to the acquisition request is It is determined whether migration to the migration destination edge storage 1402 has been completed. If the result of the determination is true, the migration destination edge storage 1402 returns the latest data to the core storage 120. If the result of the determination is false, the migration destination edge storage 1402 acquires the latest data from the migration source edge storage 1401 and returns it to the core storage 120.
- a fourth embodiment will be described.
- the difference from the second embodiment will be mainly described, and the description of the points common to the second embodiment will be simplified or omitted.
- This embodiment is an embodiment in the case of data transfer between file storages at the analysis site.
- FIG. 23 is a block diagram of a computer system 1500 in the fourth embodiment.
- the computer system 1500 comprises a central data center 810 and one or more distributed points 1560.
- Central data center 810 and distributed points 1560 are connected to each other by wide area network 850.
- the central data center 810 has the same configuration as that of the second embodiment.
- the distributed base 1560 has almost the same configuration as the distributed base 860 in the second embodiment, but there are a source file storage 1501 and a target file storage 1502 as file storage.
- the migration source file storage 1501 includes a controller (hereinafter, migration source file controller) 1510.
- the migration destination file storage 1502 includes a controller (hereinafter, migration destination file controller) 1520.
- the migration source file controller 1510 and the migration destination file controller 1520 can communicate with each other via the internal network 870. It is assumed that files and directories are being migrated from the migration source file controller 1510 to the migration destination file controller 1520. For data migration between file controllers 1510 and 1520, the method shown in Patent Document 4 is applicable. When data migration according to the method shown in Patent Document 4 is used, the host 880 can transfer source file storage via the migration destination file storage 1502 even when data migration from the migration source file controller 1510 to the migration destination file controller 1520 is not complete. The data of 1501 can be transparently referenced.
- the migration destination file controller 1520 stores the migration stub data table 1600 shown in FIG. 24 and the data request source management table 1650 shown in FIG. 25 in the memory in addition to the tables in the second embodiment.
- FIG. 24 is a configuration diagram of the migration stub data table 1600.
- the migration stub data table 1600 indicates the correspondence between the file or directory on the migration source file storage 1501 and the file or directory on the migration destination file storage 1502.
- the migration stub data table 1600 has an entry for each data set (file, directory or stub) on the migration destination file storage 1502.
- Each entry stores information such as a file path 1601, a data migration source 1602, a file path 1603 and a stub flag 1604.
- one data set is taken as an example (referred to as “target data set” in the description of FIG. 24).
- the file path 1601 indicates the path name of the target data set.
- the data migration source 1602 indicates an identifier that uniquely identifies the migration source file storage 1501 storing the migration source data set of the target data set.
- the file path 1603 indicates the path name of the migration source data set of the target data set (a file path on the migration source file storage 1501).
- the stub flag 1604 indicates whether the copy data of the target data set is stored in the file system of the migration destination file storage 1502 itself. The stub flag 1604 may be included in the first search table 913.
- FIG. 25 is a configuration diagram of the data request source management table 1650.
- the data request source management table 1650 is a table for temporarily storing on the memory until the transfer destination file storage 1502 returns a response when the host 880 or the object storage 840 transmits a file access request to the transfer destination file storage 1502 .
- the data request source management table 1650 has an entry for each file access request. Each entry stores information such as a request destination file path name 1651 and a request source 1652 indicating an identifier of a transmission source of the file access request.
- an identifier for example, an IP address, a WWN, a host name or the like can be used.
- FIG. 26 is a flowchart of transition destination read processing.
- the migration destination read process is executed by the migration destination file controller 1520 when the migration destination file controller 1520 receives a file read request from the host 880 or the object storage 840. Alternatively, the migration destination read process is executed as step 1320 in the data copy process.
- the migration destination file controller 1520 When receiving the file read request, the migration destination file controller 1520 refers to the stub flag 1604 corresponding to the file path 1601 corresponding to the read request from the migration stub data table 1600 (step 1705).
- the migration destination file controller 1520 stores the same data as the migration source file storage 1501 on the file system of the migration destination file storage 1502. The data on the file system is returned to the request source (step 1745).
- the migration destination file controller 1520 When the stub flag referred to is “ON”, the migration destination file controller 1520 does not store the same data as the migration source file storage 1510 on the file system of the migration destination file storage 1502, so data is stored in the migration source file storage 1510 Send acquisition request. Therefore, the migration destination file controller 1520 refers to the data migration source 1602 and migration source file path 1603 in the migration stub data table 1600, and the migration source file corresponding to the read target file (file specified in the file read request). The files in the storage 1510 and the migration source file storage 1510 are specified (step 1710). Subsequently, the migration destination file controller 1520 registers the request destination file 1651 and the file request source 1652 corresponding to the read target file in the data request source management table 1650 (step 1715).
- the migration destination file controller 1520 acquires data of the file (or directory) corresponding to the read target file from the migration source file storage 1510 (step 1720). Subsequently, the migration destination file controller 1520 refers to the request source 1652 of the data request source management table 1650 registered in step 1715, and determines whether the request source is the object storage 802 outside the distribution base 1560 (step 1725). ).
- the migration destination file controller 1520 makes the data of the migration source file storage 1501 acquired in step 1720 as it is (without storing it in the file system of the migration destination file storage 1502) It returns (step 1730).
- the migration destination file controller 1520 temporarily writes the data of the migration source file storage 1501 acquired in step 1720 into the file storage of the migration destination file storage 1502 (step 1735), and migration stub data The stub flag 1604 on the table 1600 is turned “OFF" (step 1740). Then, the migration destination file controller 1520 returns the data written to the file system to the request source (step 1745). In step 1745, the migration destination file controller 1520 may return the data of the migration source file storage 1501 acquired in step 1720 as it is, as in step 1730. In that case, the number of accesses to the file system can be reduced.
- the analysis host 830 is between the migration source file storage 1502 and the migration source file storage 1501.
- the data in the distributed base 1560 can be referenced via the object storage 802 regardless of the location of the data in
- the migration destination file controller 1520 recognizes whether the file request source is in the distribution base 1560 or the object storage 802, and determines whether to write the data acquired from the migration source file storage 1510 in its own file system. .
- the data acquired from the migration source file storage 1501 is controlled not to be written in its own file system, so that the migration destination file is responded to the request from the object storage 840. It can be expected that the number of accesses (input / output) executed by the controller 1520 can be reduced and the influence of the request from the object storage 802 on the access performance of the host 880 can be suppressed.
- the migration source file storage 1501 may exist outside the distributed base 1560.
- the migration source file storage 1501 is an example of a third storage device.
- Example 5 will be described. Hereinafter, differences from the first embodiment will be mainly described, and the description of the points common to the first embodiment will be simplified or omitted.
- the description of the fifth embodiment is mainly made in contrast to the first embodiment, in the description of the fifth embodiment, the "edge storage” and the “edge controller” are the “file storage” and the “file controller”. It can be read. Also, “core storage” and “core controller” can be read as “object storage” and "object controller”.
- the core controller 240 copies (acquires) data from the edge storage 150 on demand. Therefore, when the analysis host 230 accesses a large amount of data in a short time, if the update flag of these data is "ON", a large amount of data is transferred from the edge storage 150 to the core storage 120 by this extension. Copying may occur. When the network bandwidth between each of the distributed points 260 and the central data center 210 is narrow, it takes a long time to copy data, and there is a concern that the performance of analysis processing executed by the analysis host 230 may be degraded.
- the data updated in the edge storage 150 is immediately copied to the core storage 120 so that a large amount of data can be transferred at one time between each of the distribution bases 260 and the central data center 210. It can be suppressed to be copied.
- the core controller 240 creates a snapshot to allow data access from the analysis host 230 and data copy from the edge storage 150 to the core storage 120. It is possible to prevent collision and loss of consistency in data accessed by the analysis host 230.
- FIG. 27 is a schematic view showing an outline of the fifth embodiment.
- Edge controller 290 does not create a snapshot of volume 1891.
- the edge controller 240 sends differential data (data as a difference between the pre-update volume and the post-update volume) to the core controller 240.
- the core controller 240 stores the received differential data in the copy volume 1822 (an example of a third volume), and creates a reference volume 1821 (an example of a second volume) as a snapshot of the volume 1822.
- the analysis host 230 analyzes with reference to the reference volume 1821.
- the LU mapping management table in the present embodiment is stored in the memory 292 in the edge controller 290. Also, the LU mapping management table has a different configuration from the LU mapping management table 360 of the first embodiment.
- FIG. 28 is a configuration diagram of the LU mapping management table 1900 in the present embodiment.
- the LU mapping management table 1900 has an entry for each LU held by the edge storage 150. Each entry stores information such as a LUN 1901, a copy destination storage 1902, and a copy destination LUN 1903.
- a LUN 1901 stores information such as a LUN 1901, a copy destination storage 1902, and a copy destination LUN 1903.
- target LU one LU will be taken as an example (referred to as “target LU” in the description of FIG. 28).
- the LUN 1901 is a LUN of a target LU.
- the copy destination storage 1902 is an identifier that uniquely indicates the core storage 120 of the copy destination.
- the copy destination LUN 1903 is a LUN of the copy volume 1822 of the copy destination.
- An IP address or a WWN can be used as an identifier that uniquely indicates the copy destination core storage 150.
- the operation and table type of programs stored in the memory 242 in the core storage controller 240 and the memory 292 in the edge storage controller 290 are different from those in the first embodiment.
- the snapshot management table 330 is stored in the memory 242 in the core storage controller 240
- the LU mapping management table 1900 is stored in the edge storage controller 290 as described above.
- the copy status management table 370 does not require either the memory 242 or the memory 292.
- FIG. 29 is a flow diagram of a write process initiated by edge controller 290 when edge controller 290 receives a write request from host 280.
- the edge controller 290 writes the data according to the write request into the volume managed by itself (the volume specified in the write request) (step 2010).
- the edge controller 290 refers to the LU mapping management table 1900 based on the LUN of the write destination volume, and identifies the corresponding copy destination storage 1902 and copy destination LUN 1903 (step 2020).
- the edge controller 290 causes the core controller 240 corresponding to the specified copy destination storage 1902 to specify the specified LUN, the write destination address (for example, the address specified in the write request), and the write size (size of the write target data).
- the core controller 240 When the core controller 240 receives the write request, the core controller 240 writes the write target data to the area to which the address associated with the write request belongs, of the copy volumes 1822 corresponding to the LUN associated with the write request ( Step 2040).
- Steps 2020, 2030 and 2040 may be performed before returning a response to the write request to the host 280, or may be performed after the response.
- the core controller 240 can create a snapshot at any timing regardless of the behavior of the edge controller 290. For example, operations such as creating a snapshot at regular intervals may be considered. Conversely, the core controller 240 may create a snapshot in conjunction with the operation of the edge controller 290 and the host 280. For example, when the host 280 writes a series of data, an operation such as communication between the host 280 and the core controller 240, notification of a state in which data integrity has been obtained, and execution at that timing may be considered.
- Example 6 will be described. The differences from the first and fifth embodiments will be mainly described below, and the description of the points common to the first and fifth embodiments will be simplified or omitted.
- the description of the sixth embodiment is mainly made in comparison with the first and fifth embodiments, in the description of the sixth embodiment, the "edge storage” and the “edge controller” are the “file storage” and the “file controller. It can be read as “. Also, “core storage” and “core controller” can be read as “object storage” and "object controller”.
- FIG. 30 is a schematic view showing an outline of the sixth embodiment.
- the core controller 240 copies data from the distributed base 140 in response to the on-demand data copy (the read request from the analysis host 130) as in the first embodiment (and the second to fourth embodiments).
- the background type data copy (copying data from the distributed base 140 regardless of the presence or absence of a read request from the analysis host 130) as in the fifth embodiment is used in combination or switched. That is, both on-demand data copying and background data copying may be performed at the same time, or one of the copies may not be adopted during the other period.
- the reference volume 2821 is an example of a second volume and is assumed to be a virtual volume.
- the reference destination of the page of the reference volume 2821 may be a page in the copy volume 2822 or a page in the D-vol described above.
- the edge controller 290 when receiving a write request from the host 160, the edge controller 290 sends an update notification including the ID of the write destination page to the core controller 240. As a result, the update of the update bitmap table 340 is reflected in the copy status management table 370.
- the edge controller 290 provides a volume 2891 (an example of a first volume).
- the core controller 240 manages the number of new page accesses for the reference volume 2821.
- the “new page” is a page that is the access destination (read source or write destination) for the first time after the reference volume 2821 is provided to the analysis host 130.
- the core controller 240 updates (for example, increments) the number of times of access to a new page each time a new page of the reference volume 2821 is accessed.
- the core controller 240 periodically resets the number of new page accesses to 0 (zero).
- the trigger of the reset may be, for example, “before execution of analysis processing” in accordance with the execution schedule of analysis processing, or may be every predetermined cycle.
- This state conforms to the storage state condition, which is a condition under which it is considered that data is sufficiently stored in the reference volume 2821.
- An example of the storage state condition is that the new page access frequency is less than or equal to a predetermined frequency (for example, 0).
- Another example of the storage state condition is that the usage rate of the reference volume 2821 is equal to or higher than a predetermined usage rate.
- the usage rate of the reference volume 2821 is a ratio of the amount of data (page in which the reference destination exists) stored in the reference volume 2821 to the capacity of the reference volume 2821.
- the core controller 240 determines whether the storage state condition is satisfied periodically or irregularly (S31).
- the core controller 240 does not start background type data copying, and maintains the state of adopting on-demand type data copying (S32). That is, the core controller 240 receives a read request from the analysis host 130 (S21) and performs core read processing.
- the core controller 240 refers to the copy status management table 370 corresponding to the LU designated by the read request (FIG. 31: step 2110), and the read source page (page belonging to the address designated by the read request) Identify the corresponding entry.
- the core controller 240 increments the number of times of new page access (FIG. 30: S22, FIG. 31: step 2130) And a request for acquiring read target data to the edge storage 150 (FIG. 31: step 2150). Thus, the core controller 240 acquires read target data from the edge storage 150 (FIG. 30: S23).
- the core controller 240 stores the acquired read target data in the read source page (for example, stores the read target data in the empty D-vol page allocated to the read source page), reads the read target data from the page, and analyzes the host 130 Return to After that, the core controller sets both the update flag 572 and the uncopied flag 573 of the page in the copy state management table 370 to “OFF”.
- the core controller 240 transmits an acquisition request for data to be read to the edge storage 150 (FIG. 31: step 2150) although the core controller has been notified but the latest data has not been acquired yet) (FIG. 31: step 2150).
- the core controller 240 stores the acquired read target data in the read source page (for example, stores it in the empty D-vol page newly allocated to the read source page or the allocated D-vol page), and the read target data Are read from the page and returned to the analysis host 130. After that, the core controller sets the update flag 572 of the page in the copy status management table 370 to “OFF”.
- the core controller 240 starts background type data copying (FIG. 30: S33). That is, when the core controller 240 detects that there is updated data in the edge storage 150 (when there is a page corresponding to the update flag 572 “ON”), the data for copying from the edge storage 150 to the volume for copying 2822 ( Copy to an example of the third volume) (S34).
- the on-demand type data copy and the background type data copy are automatically switched back, but may be switched manually by the administrator or the like.
- the core storage 240 notifies the management system (a system that manages the storage system) of information (for example, the number of times of new page access) related to the storage state of the reference volume 2821 and the management system , And may decide whether to start background data copying.
- the core controller 240 may not perform on-demand type data copying regardless of whether the update flag 572 corresponding to the read source page is "ON" or not. When the update flag 572 corresponding to is "ON", on-demand type data copying may also be performed.
- the core controller 240 may issue an update notification indicating a page (or data set) updated after issuing the previous update notification. Even if the copy status management table 370 (or the object management table 1012) is updated based on the update notification (for example, the update bitmap table 340) requested to the 290 (or the file controller 890) and received in response to the request. Good.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Computer Security & Cryptography (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
第2の拠点内の第2のストレージ装置が、第1のホストからのライト要求に従い更新された第1の要素に関する更新通知を、第1の拠点内の第1のストレージ装置から受信した場合、当該更新通知を基に特定された第2の要素について、当該第2の要素に対応した第1の要素のデータが最新データであると管理する。第1のストレージ装置は、複数の第1の要素を含むことが可能な第1のボリュームを提供する。第2のストレージ装置は、複数の第1の要素に対応した複数の第2の要素を含むことが可能な第2のボリュームを提供する。第2のストレージ装置が、第2のホストからリード要求を受けた場合、リード元第2要素(当該リード要求から特定された第2の要素)に対応した第1の要素のデータが最新データであるか否かを判断する。当該判断結果が真の場合、第2のストレージ装置が、最新データを第1のストレージ装置から取得して第2のホストに返す。
Description
本発明は、概して、拠点間(ストレージ装置間)のデータ転送に関する。
計算機システムの用途として、IoT(Internet of Things)等の技術により得られたデータであって拠点内のストレージ装置に格納されたデータを分析し、分析結果をフィードバックすることで、業務を最適化する用途が知られている。このような用途においては、複数の拠点のデータを中央のデータセンタで横断的に分析するために、中央データセンタによって各拠点のデータを参照可能としなければならない。なお、「拠点」は、「第1の拠点」の一例であり、「中央データセンタ」は、「第2の拠点」の一例である。ここで言う「拠点」とは(第1及び第2の拠点のいずれも)、データセンタ又はネットワークセグメントのような計算機システムが設置された拠点を言う。各拠点の計算機システムは、ストレージ装置を含む。
中央データセンタが各拠点のデータを参照するため、各拠点のストレージ装置がデータを中央データセンタに転送する。例えば、特許文献1は、第1の拠点に対し行われたデータの更新を第2の拠点に非同期に転送することで、第1の拠点のデータを第2の拠点に複製する技術を開示している。この技術を前述の分散拠点-中央データセンタ間に適用する場合、全ての更新データが中央データセンタに転送される。特許文献1の技術では、分析に一部のデータしか要しない場合でも全更新データの転送が必要となる。このため、各拠点の全データを中央データセンタに転送完了するまで分析を開始することができず、業務への分析結果の活用が遅れるという問題がある。これに加え、各拠点と中央データセンタとの間のネットワークの帯域を過剰に消費するという問題もある。
一方、全データのコピー完了を必要とせず、第1の拠点のデータを第2の拠点からアクセス可能とする技術として、例えば、特許文献2が開示する技術がある。特許文献2によれば、複数のストレージ装置において、アクセス要求を受けたストレージ装置が、その要求に従うアクセス対象のデータを保有していない場合、アクセス要求を外部のストレージ装置に転送することで、外部ストレージからアクセス対象のデータを取得する。この処理は、ボリューム単位の処理のため、単一のボリュームに格納されているデータは全て転送対象となる。そのため、データの一部を中央データセンタに残すと言った細かい粒度の管理を行うことができない。この結果、中央データセンタで実行される分析処理が、遠隔の拠点のデータにアクセスすると、分析処理のデータアクセスは拠点間のデータコピーを伴うこととなり、分析処理の性能低下を引き起こす。
なお、データコピーに関し、更に、特許文献3及び4に開示の技術も知られている。
従って、本発明が解決しようとする課題は、第2の拠点において複数の第1の拠点で格納されているデータをアクセス対象(例えば分析対象)とする場合、第2の拠点でのアクセス性能の低下を抑えつつ、各第1の拠点から第2の拠点へのデータコピー完了を待たずに各第1の拠点のデータへのアクセスを可能とするとともに、第1の拠点と第2の拠点との間のネットワークの帯域の消費を抑えることである。
第1の拠点に第1のストレージ装置が存在する。第2の拠点に第2のストレージ装置が存在する。第2のストレージ装置は、第1のストレージ装置とネットワークを介して接続されたストレージ装置である。
第1のストレージ装置が、それぞれがボリューム領域又はデータセットである複数の第1の要素を含むことが可能な第1のボリュームを提供する。第2のストレージ装置が、それぞれがボリューム領域又はデータセットであり複数の第1の要素に対応した複数の第2の要素を含むことが可能な第2のボリュームを提供する。
第1のストレージ装置が、第1のホストからのライト要求に従い更新された第1の要素のIDを含む更新通知を前記第2のストレージ装置に送信する。第2のストレージ装置が、更新通知を受信した場合、当該更新通知から特定された第1の要素に対応した第2の要素について、当該第2の要素に対応した第1の要素のデータが最新データであると管理する。
第2のストレージ装置が、第2のホストからリード要求を受けた場合、当該リード要求から特定された第2の要素であるリード元第2要素に対応した第1の要素のデータが最新データであるか否かを判断する。当該判断結果が真の場合、第2のストレージ装置が、最新データの取得要求を第1のストレージ装置に送信する。当該取得要求に応答して第1のストレージ装置から取得された最新データを、第2のストレージ装置が、リード元第2要素のデータとし、且つ、当該最新データを第2のホストに返す。
第1の拠点内の全データを第2の拠点にコピーされることを待つことなく、第2のホストが、第1の拠点内のデータを参照することができる。この参照により第1の拠点から第2の拠点に取得されたデータは第2の拠点に格納されるため、以後利用可能であり、結果として、以後の第2の拠点でのアクセス性能の低下を抑えることが期待できる。また、第1の拠点から第2の拠点へ転送するデータの量を削減することで、ネットワーク帯域の消費を削減することができる。
以下の説明では、「インタフェース部」は、ユーザインタフェース部と、通信インタフェース部とのうちの少なくとも1つを含んでよい。ユーザインタフェース部は、1以上のI/Oデバイス(例えば入力デバイス(例えばキーボード及びポインティングデバイス)と出力デバイス(例えば表示デバイス))と表示用計算機とのうちの少なくとも1つのI/Oデバイスを含んでよい。通信インタフェース部は、1以上の通信インタフェースデバイスを含んでよい。1以上の通信インタフェースデバイスは、1以上の同種の通信インタフェースデバイス(例えば1以上のNIC(Network Interface Card))であってもよいし2以上の異種の通信インタフェースデバイス(例えばNICとHBA(Host Bus Adapter))であってもよい。
また、以下の説明では、「メモリ部」は、1以上のメモリを含む。少なくとも1つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。メモリ部は、主に、プロセッサ部による処理の際に使用される。
また、以下の説明では、「プロセッサ部」は、1以上のプロセッサを含む。少なくとも1つのプロセッサは、典型的には、CPU(Central Processing Unit)のようなマイクロプロセッサである。1以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサ部は、処理の一部または全部を行うハードウェア回路(例えばパリティ計算用の回路)を含んでもよい。
また、以下の説明では、「xxxテーブル」といった表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「xxxテーブル」を「xxx情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、1つのテーブルは、2以上のテーブルに分割されてもよいし、2以上のテーブルの全部又は一部が1つのテーブルであってもよい。
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜にメモリ部及び/又はインタフェース部等を用いながら行うため、処理の主語が、プロセッサ部(或いは、そのプロセッサ部を有する装置又はシステム)とされてもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な(例えば非一時的な)記録媒体であってもよい。また、以下の説明において、2以上のプログラムが1つのプログラムとして実現されてもよいし、1つのプログラムが2以上のプログラムとして実現されてもよい。
また、以下の説明では、「分散拠点」は、第1の拠点の一例である。「中央データセンタ」は、第2の拠点の一例である。
また、以下の説明では、「ストレージシステム」は、1以上の第1の拠点がそれぞれ有する1以上の第1のストレージ装置と、1以上の第1の拠点に対する第2の拠点が有する第2のストレージ装置とを含む。各ストレージ装置は、1以上のストレージマシンで構成される。少なくとも1つのストレージマシンは、汎用的な物理計算機であってもよいし、2以上の記憶デバイスを有するディスクアレイ装置でもよい。また、少なくとも1つのストレージマシンが、仮想的なストレージマシンであってもよいし、SDx(Software-Defined anything)を実行してもよい。SDxとしては、例えば、SDS(Software Defined Storage)(仮想的なストレージ装置の一例)又はSDDC(Software-defined Datacenter)を採用することができる。例えば、ストレージ装置としてのSDSと、ホスト計算機としての仮想的な計算機とが、同一拠点における計算機システム上で実行されてもよい。
また、以下の説明では、「ボリューム」は、論理ボリュームの略であり、論理的な記憶領域である。ボリュームは、実体的なボリューム(RVOL)であってもよいし、仮想的なボリューム(VVOL)であってもよい。「RVOL」は、そのRVOLを提供するストレージシステムが有する物理的な記憶資源(例えば、一以上の物理ドライブ)に基づくボリュームでよい。「VVOL」は、複数の仮想領域(仮想的な記憶領域)で構成されており容量仮想化技術(典型的にはThin Provisioning)に従うボリュームでよい。
図1は、実施例1の概要を示す模式図である。
計算機システム200は、1又は複数の分散拠点260(第1の拠点の一例)と、1つの中央データセンタ210(第2の拠点の一例)とを有する。以下、1つの分散拠点260を例に取る。
分散拠点260には、ホスト計算機(以下、ホスト)280と、ストレージ装置(以下、エッジストレージ)150とが存在する。ホスト280は、第1のホストの一例である。エッジストレージ150は、第1のストレージ装置の一例である。中央データセンタ210には、分析用ホスト計算機(以下、分析用ホスト)230と、ストレージ装置(以下、コアストレージ)120とが存在する。分析用ホスト230は、第2のホストの一例であり、分析のために使用されるホストである。コアストレージ120は、第2のストレージ装置の一例である。ストレージシステムは、エッジストレージ150とコアストレージ120とを含む。
分散拠点260において、エッジストレージ150が、ホスト280にボリューム151(第1のボリュームの一例)を提供する。エッジストレージ150は、ホスト280から、ボリューム151を指定したアクセス要求(ライト要求又はリード要求)を受信する。例えば、エッジストレージ150は、ホスト280から、ボリューム151を指定したライト要求を受信した場合、そのライト要求に従うライト対象のデータを、ボリューム151に書き込む。ボリューム151は、複数のボリューム領域で構成される。ライト対象データが、ライト先の1以上のボリューム領域に書き込まれる。本実施例では、ボリューム151は、VVOL(Thin Provisioningに従うボリューム)であり、ボリューム領域は、ページである。なお、ボリューム領域は、ボリューム内の要素の一例である。
同様に、中央データセンタ210において、コアストレージ120が、分析用ホスト230にボリューム121(第2のボリュームの一例)を提供する。コアストレージ120は、分析用ホスト230から、ボリューム121を指定したアクセス要求を受信する。例えば、コアストレージ120は、分析用ホスト230から、ボリューム121を指定したリード要求を受信した場合、そのリード要求に従うリード対象のデータを、ボリューム121から読み出し、読み出したデータを分析用ホスト230に返す。ボリューム121は、複数のボリューム領域で構成される。リード対象データが、リード元の1以上のボリューム領域から読み出される。本実施例では、ボリューム121は、VVOL(Thin Provisioningに従うボリューム)であり、ボリューム領域は、ページである。
エッジストレージ150が、更新ビットマップテーブル340を管理する。更新ビットマップテーブル340は、ページ毎の更新の有無(ボリュームペアを構成するボリューム間の差分)を管理するためのテーブルである。例えば、更新ビットマップテーブル340は、ボリューム151のページ毎にページID及び更新フラグを有する。各ページについて、ページID及び更新フラグは以下の通りである。
・ページIDは、ページのIDである。
・更新フラグは、当該ページの更新の有無を示すフラグ(ビット))である。
・ページIDは、ページのIDである。
・更新フラグは、当該ページの更新の有無を示すフラグ(ビット))である。
更新フラグ“OFF”のページに対してデータが書き込まれた場合、エッジストレージ150は、当該更新フラグを“OFF”から“ON”に更新する。
コアストレージ120が、コピー状態管理テーブル370を管理する。コピー状態管理テーブル370は、ボリューム121のページ毎にデータ取得対象か否か(エッジストレージ150における対応するページに最新データがあるか否か)を管理する。例えば、コピー状態管理テーブル370は、ボリューム121のページ毎にページID、更新フラグ及び未コピーフラグを有する。各ページについて、ページID、更新フラグ及び未コピーフラグは以下の通りである。
・ページIDは、ページのIDである。
・更新フラグ(第1の情報要素の一例)は、エッジストレージ150からコアストレージ120への前回データコピー以降に当該ページに対応したページのIDを含んだ更新通知を受けたか否かを示すフラグである。
・未コピーフラグ(第2の情報要素の一例)は、ボリューム121が作成(提供)されて以降に、エッジストレージ150からコアストレージ120の当該ページにデータが未コピーであるか否かを示すフラグである。
・ページIDは、ページのIDである。
・更新フラグ(第1の情報要素の一例)は、エッジストレージ150からコアストレージ120への前回データコピー以降に当該ページに対応したページのIDを含んだ更新通知を受けたか否かを示すフラグである。
・未コピーフラグ(第2の情報要素の一例)は、ボリューム121が作成(提供)されて以降に、エッジストレージ150からコアストレージ120の当該ページにデータが未コピーであるか否かを示すフラグである。
コピー状態管理テーブル370に関し、各ページについて、更新フラグ及び未コピーフラグの少なくとも1つが“ON”の場合、当該ページは、データ取得対象である。更新フラグ及び未コピーフラグが“OFF”の場合、当該ページは、データ取得対象ではない。すなわち、「最新データ」は、最近更新されたデータ、又は、更新されたか否かに関わらず一度もコピー(取得)されていないデータである。
エッジストレージ150が、ボリューム151を指定したライト要求をホスト280から受信した場合(S1)、ライト先ページ(ライト要求が指定するアドレスに属するページ)にデータを書き込む。また、エッジストレージ150が、ライト先ページに対応した更新フラグ(更新ビットマップテーブル340における更新フラグ)が“OFF”であれば“ON”に更新し、ライト先ページのページIDを含んだ更新通知をコアストレージ120に送信する(S2)。つまり、エッジストレージ150は、ページが更新された場合、更新されたページをコアストレージ120に通知する。更新通知を受けたコアストレージ120は、更新通知内のページIDに対応した更新フラグが“OFF”であれば“ON”に更新する。つまり、コアストレージ120は、コピー元のボリューム151で、通知されたページに更新が生じたことを記録する。
コアストレージ120は、更新通知から、エッジストレージ150において更新されたページを知ることができるが、更新通知を受けた時点では、当該ページ内のデータを取得しないでよい。分析のためのリード要求に従うリード対象のデータとならない場合、当該データの取得に伴うデータ転送が無駄になるからである。
コアストレージ120が、ボリューム121を指定したリード要求を分析用ホスト230から受信した場合(S3)、リード元ページ(リード要求で指定されたアドレスが属するページ)がデータ取得対象か否かを判断する。
この判断結果が真の場合、コアストレージ120が、リード元ページに対応するコピー元ページ(リード元ページに対応する、ボリューム151内のページ)からデータをコピーし(取得し)(S4)、コピーしたデータを、S3で受信したリード要求に対する応答として、分析用ホスト230に返す。また、コアストレージ120が、リード元ページに対応した更新フラグ及び未コピーフラグにいずれについても“ON”であれば“OFF”に更新する。また、エッジストレージ150が、取得されたデータを格納するページ(リード元ページに対応する、ボリューム151内のページ)について、更新ビットマップテーブル340における更新フラグを“OFF”にしてよい。
この判断結果が偽の場合、コアストレージ120が、リード元ページからデータを読み出し、読み出したデータを分析用ホスト230に返す。
以下、実施例1を詳細に説明する。
図2は、計算機システム200の構成図である。
計算機システム200は、中央データセンタ210と1乃至複数の分散拠点260で構成される。中央データセンタ210及び分散拠点260は、広域ネットワーク250(例えばWAN(Wide Area Network)又はインターネット)により互いに接続される。なお、広域ネットワーク250は、内部ネットワークでもよい。エッジストレージ150は、1以上の記憶媒体295と、1以上の記憶媒体295に対する入出力を制御するコントローラ(以下、エッジコントローラ)290とを有する。コアストレージ120は、1以上の記憶媒体245と、1以上の記憶媒体245に対する入出力を制御するコントローラ(以下、コアコントローラ)240とを有する。エッジコントローラ290は、第1のコントローラの一例である。コアコントローラ240は、第2のコントローラの一例である。
中央データセンタ210内は、広域ネットワーク250と接続された内部ネットワーク220を介し、コアコントローラ240及び1乃至複数の分析用ホスト230が接続されている。コアコントローラ240は、分析用ホスト230が参照するデータを格納又は提供する装置である。分析用ホスト230は、コアコントローラ240が格納するデータ、及びコアコントローラ240が透過的に(分析用ホスト230が、データの所在がエッジストレージ150にあることを認識することなく)アクセス可能としているエッジストレージ150中のデータにアクセスし、加工又は分析を行う計算機である。
このコアコントローラ240は、各分散拠点260にあるエッジストレージ150が格納するデータを分析用ホスト230に透過的にアクセス可能とする機能を備える。コアコントローラ240は、CPU241、メモリ242、ネットワークインタフェース243及びストレージインタフェース244を備え、それらは互いに内部で接続されている。CPU241は、プロセッサ部の一例であり、メモリ242に格納されたプログラムの記載に従い、コアコントローラ240の構成要素を制御する。メモリ242は、メモリ部の一例であり、複数のプログラムやテーブルを格納し、ディスクキャッシュを有する。ネットワークインタフェース243及びストレージインタフェース244は、インタフェース部の一例である。コアコントローラ240は、ネットワークインタフェース243を介し内部ネットワーク220を通じて分析用ホスト230によるアクセス要求を処理したり、広域ネットワーク250を通じてエッジコントローラ290と通信したりする。ネットワークインタフェース243を介した通信プロトコルには、Ethernet(登録商標)、Fibre Channel、SCSI(Small Computer System Interface)等が利用可能である。また、コアストレージコントローラ240は、ストレージインタフェース244を介し記憶媒体245に対するデータの読み書きを行う。記憶媒体245としては、磁気ディスク、光ディスク、NAND Flash、不揮発メモリ等が利用可能である。また、他のストレージコントローラを階層的に用いることもできる。ストレージインタフェース244と記憶媒体245間の通信プロトコルには、SCSI、SAS(Serial Attached SCSI)、ATA(Advanced Technology Attachment)、NVMe(Non-Volatile Memory express)等を利用できる。本実施例は、ここで挙げた通信プロトコルや記憶媒体に限定することなく、一般的な計算機で利用可能な通信プロトコルや記憶媒体に対し適用可能である。
分散拠点260内は、広域ネットワーク250と接続された内部ネットワーク270を介し、エッジスコントローラ290及び1乃至複数のホスト計280が接続されている。エッジコントローラ290は、ホスト280が生成するデータを格納する装置である。ホスト280は、当該ホスト280が生成及び取得するデータをエッジストレージ150に格納する。
エッジコントローラ290は、CPU291、メモリ292、ネットワークインタフェース293及びストレージインタフェース294を備え、それらは互いに内部で接続されている。CPU291は、プロセッサ部の一例であり、メモリ292に格納されたプログラムの記載に従い、エッジコントローラ290の構成要素を制御する。メモリ292は、メモリ部の一例であり、複数のプログラムやテーブルを格納し、ディスクキャッシュを有する。ネットワークインタフェース293及びストレージインタフェース294は、インタフェース部の一例である。エッジコントローラ290は、ネットワークインタフェース293を介し内部ネットワーク270を通じてホスト280によるアクセス要求を受け付けたり、広域ネットワーク250を通じてコアコントローラ240と通信したりする。また、エッジコントローラ290は、ストレージインタフェース294を介し記憶媒体295に対するデータの読み書きを行う。エッジストレージコントローラ290の各通信プロトコルや記憶媒体295には、コアストレージコントローラ240同等のものを利用可能である。
図3は、コアコントローラ240中のメモリ242及びエッジコントローラ290中のメモリ292に格納されている各種プログラム及びテーブルを示す図である。以下、両メモリ242及び292を総称して「メモリ300」と記載する。メモリ300中のプログラム及びテーブルのうち一部要素はメモリ242及び292のいずれかにしか存在しないものもあるが、そのような要素は個別に記載する。特に断りのない場合、各要素はメモリ242及び292の両方に含まれる。
入出力制御プログラム310は、コアコントローラ240又はエッジコントローラ290が分析用ホスト230又はホスト280からのアクセス要求を受信した場合に、必要に応じてリモートコピープログラム350による拠点間データ転送処理を行った上で、記憶媒体245又は295のデータの読み書きを行い、その結果を分析用ホスト230又はホスト280に返すプログラムである。入出力制御プログラム310は、分析用ホスト230やホスト280に可視なボリュームの管理単位であるLU(Logical Unit)を構成及び管理する。LUは、記憶媒体245又は295の領域を分割又は連結することで生成される。LUは、ボリュームと同義でよい。また、入出力制御プログラム310は、領域の複製、RAID(Redundant Array of Independent (or Inexpensive) Disks)、Erasure Codingなどの冗長化機構を伴うこともできる。入出力制御プログラム310は、LUのスナップショットの作成及び管理を行う機能を備える。
LU管理テーブル320は、LUの構成情報を格納する。スナップショット管理テーブル330は、LUのスナップショットの構成情報を格納する。更新ビットマップテーブル340は、CoW(Copy on Write)を用いたスナップショット管理に必要なビットマップ情報を拠点間でやりとりする場合に一時的に格納される。リモートコピープログラム350は、ネットワークインタフェース243又は293及び広域ネットワーク250を介しコアコントローラ240とエッジコントローラ290とで通信し、データの送受信を行うプログラムである。
LUマッピングテーブル360は、コアコントローラ240のみが保持するテーブルであり、コアコントローラ240が管理するLUと、エッジコントローラ290が管理するLUの対応付けを管理するテーブルである。
コピー状態管理テーブル370は、コアコントローラ240のみが保持するテーブルである。コピー状態管理テーブル370は、LUの各領域について、エッジコントローラ240からデータ取得が必要か否かを示す。
メモリ300のうち、これら各種プログラム・テーブルを格納した領域以外の全部又は一部である余剰領域は、記憶媒体245又は295のディスクキャッシュ380として用いることができる。
図4は、コアコントローラ240及びエッジコントローラ290の各々のスナップショット取得の動作の概要を示す図である。以下、例としてコアコントローラ240を例に取る。
分析用ホスト230のアクセス先のLUが、P-vol(Primary Volume)420である。P-volのスナップショットが、S-vol(Snapshot Volume)441である。S-vol441は、世代毎に存在する。世代間の差分を管理するためのLUが、D-vol(Differential Volume)430である。P-vol420及びD-vol430は、1以上の記憶媒体245上に構築されたプール400に格納される(又は関連付けられる)。S-vol441は、P-vol420とD-vol430から構成される仮想的なボリュームであり、記憶媒体245上にS-volそのものが格納されるわけではない。また、S-vol441は、スナップショット世代毎に存在するため、P-volに対し、複数作成可能である。
P-vol420、D-vol430、S-vol441はそれぞれ固定長のボリューム領域(ページ411)単位で管理される。各S-vol441中の各ページ411は、P-vol420中の同じ位置のページ411またはD-vol430中のページ411に対応付けられる。コアコントローラ240は、分析用ホスト230から、S-vol441を指定したアクセス要求を受信した場合、そのアクセス要求を、そのアクセス要求で指定されたアクセス先ページに対応する、P-vol420又はD-vol430中のページ、へのアクセス要求と見なす。この対応関係は、コアコントローラ240内のスナップショット管理テーブル330により管理される。また、P-vol内のページを「P-volページ」、D-vol内のページを「D-volページ」、及び、S-vol内のページを「S-volページ」とそれぞれ呼ぶことができる。
プール400は、例えば、1以上の記憶媒体245に基づく複数の実領域を含んでいてよい。各実領域は、論理的な記憶領域である。複数の実領域のうちの一部の実領域が、D-vol430を構成する複数のD-volページでもよい。また、実領域は、VVOLであるP-volのP-volページに割り当てられてもよい。また、実領域は、D-volもVVOLである場合、D-volページに割り当てられてもよい。
図5は、スナップショット管理テーブル330の構成図である。
スナップショット管理テーブル330は、P-vol420に相当するLU毎に存在する。スナップショット管理テーブル330は、P-volページのIDとスナップショットの世代番号とにより、S-volページの参照先として、対応するP-volページ又はD-volページを特定することができる。スナップショット管理テーブル330は、P-vol内のページ毎に、エントリを有する。各エントリが、ページID451、CoWフラグ452及び参照先ページID453といった情報を格納する。以下、1つのP-volページを例に取る(図5の説明で「対象ページ」と言う)。
ページID451は、対象ページを一意に示す識別子である。ボリュームを構成するページ群に先頭から連番が付与されてもよいし、ハッシュ値等が用いられてもよい。図の例は、P-volのページID451として0から始まる連番が付与されている。CoWフラグ452は、対象ページについてCoW(対象ページがライト先とされた場合に対象ページ内のデータを退避すること)が必要か否かを示す。“ON”は、CoWが必要を意味する。参照先ページID453は、スナップショット世代毎に、対象ページに対応したS-volページの参照先ページのページIDである。具体的には、“-1”は、同じ位置のP-volページのID、すなわち、対象ページのページIDを示している。“-1”以外の値は、D-volページのIDを示している。
世代数が多い場合、参照先ページID453“-1”の格納の有無の判断のため、スナップショット管理テーブル330を1行分全て探索する必要がある。この処理を高速化するため、コアコントローラ240は、事前に参照先ページID453“-1”の有無を求めておき、当該有無に応じてCoWフラグ452の値を準備しておいてもよい。
P-volページが一つでもS-volから参照されている(すなわち、スナップショット管理テーブル330に参照先ページID453“-1”が一つでも格納されている)場合、P-vol中のデータはスナップショットと共有されている状態である。この状態で、P-volページ若しくはP-volページを参照するS-volページに対しデータの更新が行われた場合、コアコントローラ240は、CoWを用いたデータの退避を行う。
Cowフラグ452“ON”に対応したP-volページが更新対象(ライト先)の場合、コアコントローラ240は、下記を行う。
・更新対象のP-volページ中のデータを空きD-volページにコピーする。
・P-volページを参照している全てのS-volページの参照先ページIDをコピー先D-volページのページIDに振り替える。
・更新対象のP-volページ中のデータを更新する。
・Cowフラグ452を“OFF”に変更する。
・更新対象のP-volページ中のデータを空きD-volページにコピーする。
・P-volページを参照している全てのS-volページの参照先ページIDをコピー先D-volページのページIDに振り替える。
・更新対象のP-volページ中のデータを更新する。
・Cowフラグ452を“OFF”に変更する。
Cowフラグ452“OFF”に対応したP-volページが更新対象の場合、コアコントローラ240は、下記を行う。
・更新対象のP-volページ中のデータを更新する。
・更新対象のP-volページ中のデータを更新する。
S-volページが更新対象であり、更新対象のS-volページの参照先ページがP-volページの場合、コアコントローラ240は、下記を行う。
・更新対象のS-volページの参照先P-volページ中のデータを空きD-volページにコピーする。
・更新対象のS-volページの参照先ページIDをコピー先D-volページのページIDに振り替える。
・コピー先D-vol中のデータを更新する。
・更新対象のS-volページの参照先P-volページ中のデータを空きD-volページにコピーする。
・更新対象のS-volページの参照先ページIDをコピー先D-volページのページIDに振り替える。
・コピー先D-vol中のデータを更新する。
このようにして、P-vol又はS-volの更新は、他のP-vol又は世代のS-volのデータに影響を与えずに行うことができる。
スナップショットを作成する場合、コアコントローラ240は、新たな世代番号を関連付けたS-volを作成し、スナップショット管理テーブル330中に、当該世代の参照先情報を格納できるようにする。その際、スナップショットを作成した瞬間は、P-volとS-volの内容は等しいため、コアコントローラ240は、当該S-volの全S-volページの参照先ページID453を“-1”とし、且つ、当該P-volの全P-volページのCoWフラグ452を“ON”にする。
図6は、LU管理テーブル320の構成図である。
LU管理テーブル320は、コアコントローラ240及びエッジコントローラ290の各々において、コントローラ毎に1つ存在する。LU管理テーブル320は、LU毎にエントリを持つ。ここで言うLUには、P-vol、D-vol及びS-volのいずれも該当する。各エントリが、LUN521及びサイズ522といった情報を格納する。以下、1つのLUを例に取る(図6の説明で「対象LU」と言う)。
LUN521は、対象LUのIDの一例であるLUN(Logical Unit Number)である。サイズ522は、対象LUのサイズ(容量)を示す。
図7は、更新ビットマップテーブル340の構成図である。
更新ビットマップテーブル340は、エッジコントローラ290とコアコントローラ240間でLUを構成する各ページの更新の有無を示す情報をやり取りするために一時的に生成されるテーブルである。更新ビットマップテーブル340は、ボリュームペア(LUペア)毎に存在する。ここで言うボリュームペアは、分析用ホスト230により参照され得るボリューム(コアストレージ120が提供するボリューム)と、ホスト280により更新され得るボリューム(エッジストレージ150が提供するボリューム)とのペアである。更新ビットマップテーブル340は、ボリュームのページ毎にエントリを持つ。各エントリは、ページID541及び更新フラグ542といった情報を格納する。以下、1つのページを例に取る(図7の説明で「対象ページ」と言う)。
ページID541は、対象ページのページIDである。更新フラグ542は、対象ページの更新の有無を示すフラグ(ビット))である。
なお、対象ページについて、ページID541及び更新フラグ542に代えて、同等の内容を含む別のデータ構造が用いられてもよい。例えば、更新フラグをセットされたページIDのみをリストとして列挙したデータ構造や、ビットマップをRun Length等のアルゴリズムでデータ量を削減したデータ構造が適用できる。
更新ビットマップテーブル340は、例えば、最新世代nのボリューム(エッジストレージ150内のボリューム)と、前回更新通知を送信したときの世代(例えばスナップショット世代(n-1))のボリュームとの差分(更新されたページのID)を示すテーブルでよい。更新通知は、更新ビットマップテーブル340を含んでよい。
図8は、LUマッピング管理テーブル360の構成図である。
LUマッピング管理テーブル360は、コアコントローラ240が格納するテーブルである。LUマッピング管理テーブル360は、コアストレージ120内のLU毎にエントリを持つ。各エントリは、LUN561、コピー元ストレージ562、コピー元LUN563及びコピー元世代番号564といった情報を格納する。以下、1つのLUを例に取る(図8の説明で「対象LU」と言う)。
LUN561は、対象LUのLUNである。コピー元ストレージ562は、対象LUのコピー元LU(対象LUとペアを構成するLU)を有するエッジストレージ120のID(例えばアドレス)である。コピー元LUN563は、対象LUのコピー元LUのLUNである。
コピー元世代番号564は、対象LUのコピー元LUに関連付いた世代の番号を示す。“0”は、コピー元LUがP-volであることを意味し、“0”より大きい番号は、コピー元LUがS-volであることを意味してもよい。
コピー元ストレージ562、コピー元LUN563及びコピー元世代番号564から、分散拠点260中のエッジコントローラ290及び当該エッジコントローラ290が管理するLU(世代)を一意に識別することができる。コピー元ストレージ562として、例えばTPC/IPにおけるIPアドレスやホスト名、Fibre ChannelにおけるWWN(World Wide Name)、iSCSIにおけるQualified Name等が利用可能である。
図9は、コピー状態管理テーブル370の構成図である。
コピー状態管理テーブル370は、コアコントローラ240が格納するテーブルである。コピー状態管理テーブル370は、ボリュームペアを構成するLU毎に存在する。コピー状態管理テーブル370は、ページ毎に、エントリを持つ。各エントリは、ページID571、更新フラグ572及び未コピーフラグ573といった情報を格納する。以下、1つのページを例に取る(図9の説明で「対象ページ」と言う)。
ページID571は、対象のページを一意に特定するIDである。
更新フラグ572は、対象ページについて、エッジコントローラ290からコアコントローラ240への前回データコピー以降、エッジコントローラ290からコアコントローラ240へ対象ページの更新が通知されたか否かを示す。
未コピーフラグ573は、本テーブル370に対応するLUがコアコントローラ240により作成されて以降、エッジコントローラ290からコアコントローラ240へ対象ページにデータが未コピーであるか否かを示す。
図10は、更新通知処理のフロー図である。
更新通知処理は、エッジコントローラ290においてスナップショットが作成される契機で開始される。
エッジコントローラ290は、下記2つのスナップショットの世代番号を入力として受け取る。
・今回作成したスナップショット。
・前回更新ビットマップテーブル340をコアコントローラ240に送信した際に送信した世代番号564に相当するスナップショット。
・今回作成したスナップショット。
・前回更新ビットマップテーブル340をコアコントローラ240に送信した際に送信した世代番号564に相当するスナップショット。
エッジコントローラ290は、出力として、上記の2つのスナップショット間における各ページの更新の有無を示す更新ビットマップテーブル340を、コアコントローラ240に送信する。
更新通知処理の詳細の手順は、例えば下記の通りである。
エッジコントローラ290は、スナップショット管理テーブル330を基に、更新ビットマップテーブル340を生成する(ステップ610)。この更新ビットマップテーブル340は、入力で与えられた2つの世代番号のスナップショット間で各ページに更新が生じたか否かを示す。各ページの更新の有無は、例えばスナップショット管理テーブル330の両世代の参照先ページの不一致を持って更新有りと判断できる。エッジコントローラ290は、生成した更新ビットマップテーブル340に、生成したスナップショット(S-vol)のLUNと、入力のうち新しい方の世代番号とを関連付け、LUN及び世代番号が関連付けられた更新ビットマップテーブル340を、コアコントローラ240に広域ネットワーク250を介し送信する(ステップ620)。
コアコントローラ240は、エッジコントローラ290より更新ビットマップテーブル340(及びLUN及び世代番号)を受信すると(ステップ630)、コピー状態管理テーブル370の更新を始める。コアコントローラ240は、LUマッピング管理テーブル360を参照し、送信元のエッジコントローラ290及び送信されたLUNと合致するコピー元ストレージ562及びコピー元LUN563を含む該当エントリを検索し、その該当エントリにおけるLUN561を特定する。コアコントローラ240は、更新ビットマップテーブル340中の各ページに対応するエントリを参照し、特定したLUN561に対応するコピー状態管理テーブル370においてページID571が一致するエントリの更新フラグ572を更新ビットマップテーブル340中の更新フラグ542で上書きする(ステップ640)。すべてのページに対し上書き処理を完了すると、コアコントローラ240は、受信した世代番号を、上記該当エントリ(LUマッピング管理テーブル360内のエントリ)のコピー元世代番号564に上書きする(ステップ650)
図11は、コアコントローラ240が分析用ホスト230よりLUに対するリード要求を受信したときに開始されるコアリード処理のフロー図である。
コアコントローラ240は、リード要求で指定されたリード対象のLU及びページに対応するコピー状態管理テーブル370におけるエントリを参照する(ステップ710)。参照したエントリにおいて、未コピーフラグ573若しくは更新フラグ572の少なくとも片方が“ON”の場合、当該LUのリード対象データは、エッジコントローラ290から取得する必要がある。この場合、コアコントローラ240は、LUマッピング管理テーブル360を参照して、リード対象のLUに対応するコピー元ストレージ562、コピー元LU563及びコピー元世代番号564を特定し、コピー元エッジコントローラ290に、当該LU及びスナップショットに対するデータの取得要求を送信する(ステップ720)。そして、コアコントローラ240は、その取得要求に応答してコピー元エッジコントローラ290から取得したデータを、リード対象のLUにライトする。この動作により、リード対象LUとそれのコピー元LUの当該ページの内容は一致するため、コアコントローラ240は、コピー状態管理テーブル370における更新フラグ572及び未コピーフラグ573を共に“OFF”とする。その後、コアコントローラ240は、リード対象のLU内のデータ(エッジコントローラ290から取得され格納されたデータ)をリードし、リード要求元の分析用ホスト230に返す(ステップ730)。
本実施例により、分析用ホスト230がエッジストレージ150内のデータに透過的にアクセスできるようになる。このため、エッジストレージ150が格納するデータのコピー完了をまたず、コアコントローラ240から、エッジストレージ150が格納するデータへアクセスが可能となる。また、参照の際、対象のデータが格納されたページのみ広域ネットワーク250を通じて転送され、参照しないデータは転送されない。これにより、広域ネットワーク250の転送量を抑え転送時間を短縮するとともに、コアコントローラ240がエッジコントローラ290からコピーする(取得する)データの量(コアコントローラ240の複製量)を削減することができる。更に、エッジコントローラ290からコアコントローラ240へコピーしたデータをコアストレージ120内のLUに保存することで、その後のアクセスでは、エッジコントローラ290からのデータコピーが不要となり、アクセス性能の低下を抑えることができる。
本実施例では、エッジコントローラ290からコアコントローラ240へのデータのコピーは、分析用ホスト230からリード要求を受け当該リード要求で指定されたページがデータ取得対象のページである場合に行われるが、この契機に加えて、リード要求の受信とは非同期的に行われてもよい。この場合、分析用ホスト230が初めてリード元とするページに対し非同期コピーが完了している場合、そのページに既に最新データが格納されているため、広域ネットワーク250を介したデータの取得が不要でリード応答時間を高速化できることが期待できる。
また、本実施例では、コアコントローラ240がLUマッピング管理テーブル360とコピー状態管理テーブル370を格納していれば、分析用ホスト230は、コアコントローラ240を介してエッジストレージ150が格納するデータを参照可能である。実際にエッジストレージ150が保持する全データがコアコントローラ240にコピーされるのを待つ必要がないため、コアストレージ120を新規にエッジストレージ150と接続した場合や、エッジストレージ150に大量のデータが生成された場合でも、即座に分析用ホスト230がエッジストレージ150のデータを参照することが期待できる。
実施例2を説明する。以下、実施例1との相違点を主に説明し、実施例1との共通点については説明を簡略又は省略する。
エッジストレージ及びコアストレージのうちの少なくとも1つとしては、実施例1で示したLUNとアドレス(例えばLBA(Logical Block Address))を指定したアクセス要求を受信し当該要求に従うデータにアクセスする装置に代えて、ファイルやオブジェクトといったデータセット単位でアクセスする装置が採用されてよい。特に、各拠点にファイルストレージを配置し、このファイルストレージに格納されたデータを、クラウドストレージなどのオブジェクト単位でのデータアクセスを提供するストレージシステムへデータをコピーする形態がとられることがある。実施例2では、そのような形態が採用されている。なお、「データセット」とは、アプリケーションプログラムのようなプログラムから見た1つの論理的な電子データの塊であり、例えば、レコード、ファイル、オブジェクト、キーバリューペア及びタプルのうちのいずれでもよい。また、実施例2において、ファイル、ディレクトリ及びオブジェクトのようなデータセットは、ボリューム内の要素の一例である。
図12は、実施例2における計算機システム800の構成図である。
中央データセンタ810(第2の拠点の一例)内は、広域ネットワーク850と接続された内部ネットワーク820を介し、オブジェクトストレージ802(第2のストレージ装置の一例)及び1乃至複数の分析用ホスト830(第2のホストの一例)が接続されている。また、ファイルゲートウェイ831が接続されていてもよい。オブジェクトストレージ840は、分析用ホスト830が参照するデータをオブジェクト単位で格納及び提供する装置である。オブジェクトストレージ802が、1以上の記憶媒体848とその1以上の記憶媒体848に対する入出力を制御するコントローラ(以下、オブジェクトコントローラ)840とを有する。分析用ホスト830は、オブジェクトストレージ802が格納するデータ、及びオブジェクトコントローラ840が透過的にアクセス可能としている分散拠点860のファイルストレージ801中のデータにアクセスし、加工又は分析を行う計算機である。なお、分析用ホスト830がオブジェクト単位でのデータアクセス機能を有しない場合、別途ファイル単位でのデータアクセスとオブジェクト単位でのデータアクセスを変換するファイルゲートウェイ831を用いて間接的にオブジェクトストレージ840が格納するデータにアクセスしてもよい。以後、分析用ホスト830がオブジェクトストレージ840内のデータにアクセスするとは、ファイルゲートウェイ831を介した間接的なアクセスする場合も含める。ファイルストレージ801からディレクトリ階層構造がオブジェクトストレージ802に格納されると、オブジェクトストレージ802において階層構造は維持されないが、ファイルゲートウェイ831は、その階層構造を表す情報を保持する。つまり、ファイルゲートウェイ831は、オブジェクトストレージ802内のオブジェクトの階層構造を管理する。ファイルゲートウェイ831は、例えば、パス名(ファイル名)を指定した要求(問合せ)に応答して、そのパス名に対応するオブジェクトIDを返すことができる。
オブジェクトコントローラ840は、各分散拠点860(第1の拠点の一例)にあるファイルストレージ890(第1のストレージ装置の一例)が格納するデータを分析用ホスト830に透過的にアクセス可能とする機能を備える。オブジェクトコントローラ840(第2のコントローラの一例)は、CPU841、メモリ842、ネットワークインタフェース843及びストレージインタフェース844を備え、それらは互いに内部で接続されている。CPU841は、メモリ842に格納されたプログラムの記載に従い、オブジェクトコントローラ840の構成要素を制御する。メモリ842は、複数のプログラムやテーブルを格納し、ディスクキャッシュを有する。オブジェクトコントローラ840は、ネットワークインタフェース843を介し内部ネットワーク820を通じて分析用ホスト830によるアクセス要求を処理したり、広域ネットワーク850を通じてファイルストレージ890と通信したりする。また、オブジェクトコントローラ840は、ストレージインタフェース844を介し記憶媒体845に対するデータの読み書きを行い、記憶媒体845内にオブジェクトデータ846、オブジェクト管理テーブル847、スタブデータ848、を格納する。これらのデータは記憶媒体845の領域をそのままパーティションやLVM(Logical Volume Management)等の機能で区切って格納してもよいし、記憶媒体845上にファイルシステムを構築し、それぞれファイル単位で格納してもよい。ネットワークインタフェース843を介した通信プロトコルには、HTTP(Hypertext Transfer Protocol)を利用したREST(Representational State Transfer)プロトコルや、ネットワークインタフェース243及びストレージインタフェース244のプロトコルを利用できる。また。ストレージインタフェース844と記憶媒体845間の通信プロトコルは、ストレージインタフェース244のプロトコルを利用できる。
ファイルストレージ801が、1以上の記憶媒体895とその1以上の記憶媒体895に対する入出力を制御するコントローラ(以下、ファイルコントローラ)890とを有する。ファイルコントローラ890(第1のコントローラの一例)は、CPU891、メモリ892、ネットワークインタフェース893及びストレージインタフェース894を備え、それらは互いに内部で接続されている。CPU891は、メモリ892に格納されたプログラムの記載に従い、ファイルコントローラ890の構成要素を制御する。メモリ892は、複数のプログラムやテーブルを格納し、ページキャッシュを有する。ファイルコントローラ890は、ネットワークインタフェース893を介し内部ネットワーク870を通じてホスト880によるアクセス要求を受け付けたり、広域ネットワーク850を通じて中央データセンタ810内のオブジェクトストレージ840と通信したりする。また、ファイルコントローラ890は、ストレージインタフェース894を介し記憶媒体895に対するデータの読み書きを行い、記憶媒体895上にファイルシステム896を構築する。ファイルコントローラ890の各通信プロトコルには、NFS(Network File System)やSMB(Server Message Block)をはじめ、オブジェクトストレージ840同等のものを利用可能である。また、ストレージインタフェース894と記憶媒体895間の通信プロトコルは、ストレージインタフェース244のプロトコルを利用できる。
ファイルシステム896が、第1のボリュームの一例である。オブジェクトデータ846やスタブデータ848が格納される領域が、第2のボリュームの一例である。
なお、各分散拠点860内のストレージ装置は、ファイルストレージに代えてオブジェクトストレージであってもよい。中央データセンタ810内のストレージ装置は、オブジェクトストレージに代えてファイルストレージでもよい。また、分散拠点860及び中央データセンタ810の一方がファイル又はディレクトリであり他方がオブジェクトであることは、散拠点860が格納するデータセットの種類と中央データセンタ810が格納するデータセットの種類とが異なっていることの一例である。データセットの種類が異なっていると、データセットのIDの構成が異なり、そのため、データセットのIDの対応関係を、例えば図14に示すようなテーブルを用いて管理する必要がある(後述するように、図15に示すようなテーブルが更にあると好ましい)。
図13は、ファイルコントローラ890中のメモリ892に格納されている各種プログラム及びテーブルを示す図である。
メモリ892は、ファイルシステムプログラム911、データ転送プログラム912、第1検索テーブル913、第2検索テーブル914及びオブジェクトストレージ情報915を格納する。メモリ892は、ページキャッシュ916を有する。ページキャッシュ916は、メモリ892のうちの余剰領域(各種プログラム及びテーブルを格納した領域以外の領域の少なくとも一部)でよい。
ファイルシステムプログラム911は、記憶媒体896上にファイルシステムを構築し、ディレクトリやファイル単位でのデータアクセスやデータ格納を実現するプログラムである。また、ファイルシステムプログラム911は、内部ネットワーク870を介したファイルアクセス要求(ホスト880によるディレクトリ又はファイルへのアクセス要求)への応答も行う。ネットワークを介したファイルアクセス要求のプロトコルには、先に述べたとおり、NFS(Network File System)、SMB(Server Message Block)、AFP(Apple Filing Protocol)等が利用できる。
データ転送プログラム912は、中央データセンタ810にあるオブジェクトストレージ840とのデータ送受信を行うプログラムである。
図14は、第1検索テーブル913の構成図である。
第1検索テーブル913は、ファイルシステム上のディレクトリ又はファイルとオブジェクトストレージ840内のオブジェクトとの対応関係を示すテーブルであって、ファイルパス名からオブジェクトIDを検索するためのテーブルである。第1検索テーブル913は、ディレクトリ又はファイル毎にエントリを有する。各エントリは、パス名921、タイプ922及びオブジェクトID923といった情報を格納する。以下、1つのデータセット(ディレクトリ又はファイル)を例に取る(図14の説明で「対象データセット」と言う)。
パス名921は、対象データセットへのパス名を示す。パス名921は、対象データセットのIDの一例でよい。タイプ922は、対象データセットのタイプ(“/”(ルートディレクトリ)、“ディレクトリ”又は“ファイル”)を示す。オブジェクトID923は、対象データセットに対応したオブジェクトを一意に特定するIDである。
第1検索テーブル914を利用することにより、ファイル又はディレクトリに対応したオブジェクトIDを含んだ更新通知を送信することが可能である。第1検索テーブル913は、パス名921に関しハッシュ値等のインデックスを保持することで、パス名921からエントリを高速に検索可能な形で管理される。
図15は、第2検索テーブル914の構成図である。
第2検索テーブル914は、オブジェクトとディレクトリ又はファイルとの対応関係を示すテーブルであって、オブジェクトIDからパス名を検索するためのテーブルである。第2検索テーブル914は、オブジェクト毎にエントリを有する。各エントリは、オブジェクトID931及びパス名932といった情報を格納する。以下、1つのオブジェクトを例に取る(図15の説明で「対象オブジェクト」と言う)。
オブジェクトID931は、対象オブジェクトのIDである。パス名932は、対象オブジェクトに対応したデータセットへのパス名を示す、
第2検索テーブル914を利用することにより、オブジェクトIDを指定した取得要求に応答して当該オブジェクトIDに対応したファイル又はディレクトリを高速に特定することが可能である。オブジェクトID931に関しハッシュ値等のインデックスを保持することで、オブジェクトID931からエントリを高速に検索可能な形で管理される。
第1検索テーブル913と第2検索テーブル914は同内容を含むテーブルであるため、パス名とオブジェクトIDの両方で高速にエントリを検索可能であるならば、1つのテーブルで兼用してもよい。
図16は、オブジェクトコントローラ840中のメモリ842に格納されている各種プログラム及びテーブルを示す図である。
メモリ842は、オブジェクト制御プログラム1011、オブジェクト管理テーブル1012及びスタブデータテーブル1013を格納する。メモリ842は、ディスクキャッシュ1014を有する。ディスクキャッシュ1014は、メモリ842のうちの余剰領域(各種プログラム及びテーブルを格納した領域以外の領域の少なくとも一部)でよい。
オブジェクト制御プログラム1011は、オブジェクト単位でのデータ入出力を行い、且つ、分析用ホスト830からのアクセス要求に応答するプログラムである。オブジェクトストレージ840は、オブジェクトを全て一律に管理するのではなく、複数のバケットと呼ぶ単位で分類することもできる。その場合、分析用ホスト830はバケットIDとオブジェクトIDの対でアクセス対象を特定する。
図17は、オブジェクト管理テーブル1012の構成図である。
オブジェクト管理テーブル1012は、オブジェクト制御プログラム1011が管理するオブジェクトの情報を示すテーブルである。オブジェクト管理テーブル1012は、オブジェクト毎にエントリを有する。各エントリが、オブジェクトID1021、更新フラグ1022、スタブフラグ(未コピーフラグと同等)1023、サイズ1024及び保存先1025といった情報を格納する。以下、1つのオブジェクトを例に取る(図17の説明で「対象オブジェクト」と言う)。オブジェクトがその他の属性(例えば、オブジェクトの作成日時、所有者、アクセス権等の属性)を持つ場合、オブジェクト管理テーブル1012は、対応する列を有してもよい。
オブジェクトID1021は、対象オブジェクトのIDである。
更新フラグ1022は、ファイルストレージ801からオブジェクトストレージ802への対象オブジェクトの前回データコピー以降、ファイルコントローラ890からオブジェクトコントローラ840へ対象オブジェクトのIDを含んだ更新通知が送信されたか否かを示す。
スタブフラグ1023は、LU(オブジェクト格納空間)を作成して以降、ファイルストレージ801からオブジェクトストレージ802に対象オブジェクトが未コピーであるか否か(対象オブジェクトに代えてそのスタブが存在するか否か)を示す。
保存先1025は、対象オブジェクトのデータの格納位置(記憶媒体845における位置)を示す。保存先1025としては、ファイルシステムのパス名やLU上のLBA等が格納される。
オブジェクト管理テーブル1012はバケット毎に存在してもよいし、1つのオブジェクト管理テーブル1012上にバケットIDの列を加え、バケットIDとオブジェクトIDの対でオブジェクト管理テーブル1012上のエントリ(行)を特定可能としてもよい。
図18は、スタブデータテーブル1031の構成図である。
スタブデータテーブル1031は、オブジェクト毎にエントリを有する。各エントリが、バケットID1031、オブジェクトID1032及びデータ取得先1033といった情報を格納する。以下、1つのオブジェクトを例に取る(図18の説明で「対象オブジェクト」と言う)。
バケットID1031は、対象オブジェクトを格納するバケットのIDである。オブジェクトID1032は、対象オブジェクトのIDである。データ取得先1033は、対象オブジェクトに対応したデータセットが格納されている位置(ファイルストレージ801上の位置)を示す。データ取得先1033は、例えば、ファイルストレージ801の識別子と、ファイルストレージ801上のファイル共有名との組合せ等で表現される。
スタブデータテーブル1031は、オブジェクトとデータ取得先との対応関係を示すものであれば、図に示す以外の形式でもよい。例えばバケット内の全オブジェクトが同一のデータ取得先に対応付けられるのであれば、オブジェクトID1032の列は不要である。スタブデータテーブル1013により、分析用ホスト830のアクセス時に、テータ取得先1033が示すファイルストレージ890より、透過的にデータを取得可能とする。
図19は、スタブ作成処理のフロー図である。
スタブ作成処理は、ファイルストレージ801が自身の保持するファイル又はディレクトリに対応するスタブデータをオブジェクトストレージ802に登録する際に実行される処理である。例えば、ファイルストレージ801に新規ファイルが追加された場合にスタブ作成処理が実行されたり、一定期間毎(例えば1日毎)に当該期間(例えば1日)の間に作成されたファイル群(1以上のファイル)について一括してスタブ作成処理が実行されたりしてもよい。以下、スタブ作成処理は1つのデータセット(ファイル又はディレクトリ)を対象とするが(図19において「対象データセット」)、ファイルコントローラ890はスタブ作成処理を複数並列又は直列に実行することで複数のファイル又はディレクトリに対するスタブ作成を完了することもできる。
ファイルコントローラ890は、対象データセットについて、オブジェクトコントローラ840で格納される際のオブジェクトIDを確定する(ステップ1110)。オブジェクトIDは一意性が保持されるのであればファイルコントローラ890が生成してもよいし、オブジェクトコントローラ840が生成してもよい。ファイルコントローラ890は、確定したオブジェクトIDを取得すると、第1検索テーブル913に、対象データセットに対応するパス名921、タイプ923及びオブジェクトID924を格納したエントリを追加する(ステップ1120)。同様に、ファイルコントローラ890は、第2検索テーブル914に、対象データセットに対応するパス名931及びオブジェクトID932を格納したエントリを追加する(ステップ1130)。続けて、ファイルコントローラ890は、確定したオブジェクトIDとオブジェクトの属性(サイズなど)とを関連付けたスタブ作成要求(オブジェクトのスタブを作成することの要求)を、オブジェクトコントローラ840に送信する(ステップ1140)。
オブジェクトコントローラ840は、ファイルコントローラ890によるスタブ作成要求を受信すると、当該スタブ作成要求に応答して、対応するスタブデータテーブル1031のエントリを作成する(ステップ1150)。ステップ1150で作成されたエントリにおいて、スタブ作成要求に関連付けられているオブジェクトID1021が格納される。
続けて、オブジェクトコントローラ840は、オブジェクト管理テーブル1012のエントリを作成する(ステップ1160)。ステップ1160で作成されたエントリには、ファイルコントローラ890によるスタブ作成要求に関連付けられているオブジェクトID1021及びサイズ1024が格納される。また、ステップ1160で作成されたエントリにおいて、更新フラグ1022は“OFF”とされ、スタブフラグ1023は“ON”とされる。
このようにして、オブジェクトコントローラ840は、ファイルコントローラ890からのスタブ作成要求に応答として、当該スタブ作成要求で指定されているオブジェクトのスタブであって分析用ホスト830から認識されるスタブを作成する。
図20は、分析用ホスト830又はファイルゲートウェイ831からオブジェクトコントローラ840がオブジェクトの取得要求を受けた場合に行われるオブジェクトリード処理のフロー図である。
オブジェクトストレージ840は、オブジェクトの取得要求を受信すると、当該取得要求に含まれるオブジェクトIDを用いてオブジェクト管理テーブル1012を参照し、対象オブジェクト(当該取得要求に含まれるオブジェクトIDから特定されるオブジェクト)の更新フラグ1022及びスタブフラグ1023の少なくとも1つが“ON”か否かを判断する(ステップ1210)。例えば、更新フラグ1022が“ON”は、ファルストレージ801上で対象オブジェクトに対応したファイル又はディレクトリの更新が行われたために、ファイルコントローラ890から更新通知を受けたことを意味する。この通知の方法は、ファイルコントローラ890からオブジェクトコントローラ840に対し、更新したオブジェクトIDの一覧を送信する方法が考えられる。この送信を受け、オブジェクトコントローラ840は、リストに含まれる各オブジェクトIDについて、オブジェクト管理テーブル1012中の当該オブジェクトIDに対応する更新フラグを“ON”にする。また、スタブフラグ1023が“ON”は、オブジェクトデータ846に対応するファイル又はディレクトリのデータを保持していないことを意味する。よって、更新フラグ1022及びスタブフラグ1023の少なくとも1つが“ON”の場合、当該オブジェクトのデータをファルストレージ801から取得する必要があることを意味する。その場合、オブジェクトコントローラ840は、データコピー処理(図21)を開始し、オブジェクトデータ846がファイルシステム896におけるファイル又はディレクトリのデータと一致した状態とするようにする(ステップ1220)。その後、オブジェクトコントローラ840は、対象オブジェクトのデータ846をリードし、リードしたデータを、オブジェクトの取得要求の送信元に返す(ステップ1230)。
図21は、データコピー処理のフロー図である。データコピー処理は、オブジェクトリード処理中に実行されてもよいし、オブジェクトコントローラ840が他の処理を行っている際にバックグラウンドで行われてもよい。
オブジェクトコントローラ840は、スタブデータテーブル1013を参照し、対象オブジェクト(処理対象のオブジェクト)のオブジェクトIDと対象オブジェクトが格納されているバケットのバケットIDとを用いて、対応するデータ取得先1033を特定する(ステップ1305)。オブジェクトコントローラ840は、ステップ1305で取得したデータ取得先1033のファイルコントローラ890に対し、オブジェクトIDを引数として関連付けた取得要求を送信する(ステップ1310)。
当該取得要求を受信したファイルコントローラ890は、引数のオブジェクトIDを基に、第2検索テーブル914を用いて、対象オブジェクトに対応するファイル又はディレクトリのパス名932を特定し(ステップ1315)、特定したパス名932に従うファイル又はディレクトリのデータをファイルシステム896から読み込む(ステップ1320)。パス名932が示す先がディレクトリである場合、ファイルコントローラ890は、ディレクトリ内に格納されたすべての子データセット(各ファイル及びサブディレクトリ)に対し、スタブ作成処理を行う(ステップ1325、1330)。つまり、当該ディレクトリ内の全てのデータセットの各々のスタブがファイルシステム上に作成される。結果として、オブジェクトストレージ802が持つオブジェクトを用いて、ファイルストレージ801においてネームスペース(階層構造)を復元することができる。
その後、ファイルコントローラ890は、パス名に対応するファイル又はディレクトリのデータ(ディレクトリの場合、“データ”とは、ディレクトリ内に格納されたファイル及びサブディレクトリの情報として、ファイル名及びサブディレクトリ名(パス名)と対応するオブジェクトIDとの対のリストを意味する)をオブジェクトストレージ840に返す(ステップ1335)。
オブジェクトコントローラ840は、ファイルコントローラ890からの応答を受信すると、受信したデータをオブジェクトデータ846として書き込む(ステップ1340)。続けて、オブジェクトコントローラ840は、オブジェクト管理テーブル1012の更新フラグ1022とスタブフラグ1023を“OFF”にする(ステップ1345)。
本実施例により、分析用ホスト830が分散拠点のファイルストレージ801が格納するデータに透過的にアクセスできるようになる。これにより、ファイルストレージ801からオブジェクトストレージ802へのデータコピーの完了をまたず、分析用ホスト830からファイルストレージ801のデータを参照可能となる。また、参照の際、対象のデータが格納されたオブジェクトのみ分散拠点860と中央データセンタ810間で広域ネットワーク850を通じて転送され、参照しないオブジェクトは転送されない。これにより、広域ネットワーク850の転送量を抑え転送時間を短縮するとともに、オブジェクトストレージ802がファイルストレージ801からコピーするデータの量(オブジェクトストレージ802の複製量)を削減することができる。
また、本実施例では、オブジェクトコントローラ840が、ディレクトリに対応するオブジェクトのリード要求を受けると、ディレクトリ内のファイル及びサブディレクトリのスタブデータを構築する。よって、オブジェクトコントローラ840は、ルートディレクトリに対応するスタブデータのみ格納した状態であれば、分析用ホスト830やファイルゲートウェイ831からのデータ取得要求に対し、パスの構成要素を再帰的にスタブ化及びデータコピー処理を行える。そのため、オブジェクトストレージ802を新規にファイルストレージ801と接続した場合や、ファイルストレージ801に大量のファイル(及びディレクトリ)が生成された場合でも、ファイルストレージ801のデータをオブジェクトストレージ802にコピーするのを待つことなく即座に分析用ホスト830やファイルゲートウェイ831がファイルストレージ801のファイル又はディレクトリを参照することが期待できる。
実施例3を説明する。以下、実施例1との相違点を主に説明し、実施例1との共通点については説明を簡略又は省略する。
計算機システムにおいては、旧ストレージ装置から、新規購入したストレージ装置へデータを移行することがある。本実施例では、LUNとアドレス(例えばLBA)を指定したアクセス要求を処理するストレージシステムが、このようなデータ移行の際中であっても、実施例1と同様の効果を実現する。
図22は、実施例3における計算機システム1400の構成図である。
計算機システム1400は、中央データセンタ210と1乃至複数の分散拠点1460で構成される。中央データセンタ210及び分散拠点1460は広域ネットワーク250により互いに接続される。中央データセンタ210は実施例1と同等の構成を取る。分散拠点1460は実施例1における分散拠点260とほぼ同等の構成を取るが、エッジコントローラとして、移行元エッジコントローラ(移行元エッジストレージ1401のエッジコントローラ)1410及び移行先エッジコントローラ(移行先エッジストレージ1402のエッジコントローラ)1420とがある。移行元エッジストレージ1401の一例が、旧ストレージ装置である。移行先エッジストレージ1402の一例が、新ストレージ装置である。
移行元エッジコントローラ1410及び移行先エッジコントローラ1420は、互いに内部ネットワーク270を介し通信可能である。移行元エッジストレージ1401が格納しているデータやLU構成を移行先エッジストレージ1402に移行中であるものとする。コントローラ1410及び1420間のデータ移行については、特許文献3に示す方式が適用可能である。特許文献3に示す方式によるデータ移行を用いると、移行元エッジコントローラ1410から移行先エッジコントローラ1420へのデータ移行が未完の状態においても、ホスト280が移行先エッジストレージ1402を介して移行元エッジストレージ1401のデータを透過的に参照できる。
図11のコアリード処理のステップ720の処理を、移行元エッジコントローラ1410から移行先エッジコントローラ1420へのデータ移行に適用することができる。コアコントローラ240が保持するLUマッピング管理テーブル562におけるコピー元ストレージ532及びコピー元LUN563は、移行先エッジコントローラ1420上のLUを参照するように設定しておく。その場合、コアコントローラ240のデータ取得要求は、移行先エッジコントローラ1420に送信される。移行先エッジコントローラ1420は、ホスト280に、移行元エッジストレージ1401のデータを透過的に参照する機能を備えている。同様に、移行先エッジコントローラ1420は、コアコントローラ240からのデータ取得要求に対し、移行元エッジストレージ1401のデータを透過的に参照する機能を適用することで、移行元エッジストレージ1401にあるデータを取得することができる。
本実施例によれば、分散拠点1460においてエッジストレージ1401及び1402間のデータ移行を実施している最中であっても、中央データセンタ210内の分析用ホスト230は、移行元エッジストレージ1401及び移行先エッジストレージ1402間のデータの所在を問わず、コアコントローラ240を介し分散拠点1460内のデータを参照することができる。
なお、本実施例において、移行元エッジストレージ1401は、分散拠点1460の外に存在していてもよい。移行元エッジストレージ1401は、第3のストレージ装置の一例である。移行元エッジストレージ1401から移行先エッジストレージ1402にデータを移行している最中において、移行先エッジストレージ1402が、取得要求をコアストレージ120から受信した場合、当該取得要求に従う取得対象の最新データが移行先エッジストレージ1402に移行済みか否かを判断する。当該判断の結果が真の場合、移行先エッジストレージ1402が、当該最新データをコアストレージ120に返す。当該判断の結果が偽の場合、移行先エッジストレージ1402が、当該最新データを移行元エッジストレージ1401から取得してコアストレージ120に返す。
実施例4を説明する。以下、実施例2との相違点を主に説明し、実施例2との共通点については説明を簡略又は省略する。
本実施例は、分析拠点においてファイルストレージ間でデータ移行の際中である場合の実施例である。
図23は、実施例4における計算機システム1500の構成図である。
計算機システム1500は、中央データセンタ810と1乃至複数の分散拠点1560で構成される。中央データセンタ810及び分散拠点1560は広域ネットワーク850により互いに接続される。中央データセンタ810は実施例2と同等の構成を取る。分散拠点1560は実施例2における分散拠点860とほぼ同等の構成を取るが、ファイルストレージとして、移行元ファイルストレージ1501及び移行先ファイルストレージ1502とが存在する。移行元ファイルストレージ1501は、コントローラ(以下、移行元ファイルコントローラ)1510を含む。移行先ファイルストレージ1502は、コントローラ(以下、移行先ファイルコントローラ)1520を含む。
移行元ファイルコントローラ1510及び移行先ファイルコントローラ1520は、互いに内部ネットワーク870を介し通信可能である。移行元ファイルコントローラ1510からファイルやディレクトリを移行先ファイルコントローラ1520に移行中であるとする。ファイルコントローラ1510及び1520間のデータ移行については、特許文献4に示す方式が適用可能である。特許文献4に示す方式によるデータ移行を用いると、移行元ファイルコントローラ1510から移行先ファイルコントローラ1520へのデータ移行が未完の状態においても、ホスト880が移行先ファイルストレージ1502を介して移行元ファイルストレージ1501のデータを透過的に参照できる。
移行先ファイルコントローラ1520は、実施例2におけるテーブルに加え、図24に示す移行用スタブデータテーブル1600及び図25に示すデータ要求元管理テーブル1650をメモリ中に格納する
図24は、移行用スタブデータテーブル1600の構成図である。
移行用スタブデータテーブル1600は、移行元ファイルストレージ1501上のファイル又はディレクトリと移行先ファイルストレージ1502上のファイル又はディレクトリとの対応関係を示す。移行用スタブデータテーブル1600は、移行先ファイルストレージ1502上のデータセット(ファイル、ディレクトリ若しくはスタブ)毎にエントリを有する。各エントリは、ファイルパス1601、データ移行元1602、ファイルパス1603及びスタブフラグ1604といった情報を格納する。以下、1つのデータセットを例に取る(図24の説明で「対象データセット」と言う)。
ファイルパス1601は、対象データセットのパス名を示す。データ移行元1602は、対象データセットの移行元データセットを格納する移行元ファイルストレージ1501を一意に識別する識別子を示す。ファイルパス1603は、対象データセットの移行元データセットのパス名(移行元ファイルストレージ1501上におけるファイルパス)を示す。スタブフラグ1604は、対象データセットの複製データを移行先ファイルストレージ1502自身のファイルシステムに格納しているか否かを示す。なお、スタブフラグ1604は、第1検索テーブル913に含まれてもよい。
図25は、データ要求元管理テーブル1650の構成図である。
データ要求元管理テーブル1650は、ホスト880又はオブジェクトストレージ840が移行先ファイルストレージ1502にファイルアクセス要求を送信する際、移行先ファイルストレージ1502が応答を返すまで一時的にメモリ上に格納するテーブルである。データ要求元管理テーブル1650は、ファイルアクセス要求毎にエントリを有する。各エントリは、要求先ファイルのパス名1651と、ファイルアクセス要求の送信元の識別子を示す要求元1652といった情報を格納する。識別子として、例えばIPアドレス、WWN、ホスト名等が利用できる。
図26は、移行先リード処理のフロー図である。
移行先リード処理は、ホスト880又はオブジェクトストレージ840から移行先ファイルコントローラ1520がファイルリード要求を受信した場合に移行先ファイルコントローラ1520により実行される。または、移行先リード処理は、データコピー処理においてステップ1320として実行される。
移行先ファイルコントローラ1520は、ファイルリード要求を受信すると、移行用スタブデータテーブル1600から、当該リード要求に対応したファイルパス1601に対応するスタブフラグ1604を参照する(ステップ1705)。
参照したスタブフラグ1604が“OFF”の場合、移行先ファイルコントローラ1520は、移行先ファイルストレージ1502のファイルシステム上に移行元ファイルストレージ1501と同じデータが格納されているため、移行先ファイルストレージ1502のファイルシステム上のデータを要求元に返す(ステップ1745)。
参照したスタブフラグが“ON”の場合、移行先ファイルコントローラ1520は、移行先ファイルストレージ1502のファイルシステム上に移行元ファイルストレージ1510と同じデータが格納されていないため、移行元ファイルストレージ1510にデータ取得要求を送信する。そのため、移行先ファイルコントローラ1520は、移行用スタブデータテーブル1600中のデータ移行元1602及び移行元ファイルパス1603を参照し、リード対象ファイル(ファイルリード要求で指定されたファイル)に対応する移行元ファイルストレージ1510及び移行元ファイルストレージ1510中のファイルを特定する(ステップ1710)。続けて、移行先ファイルコントローラ1520は、リード対象ファイルに対応した要求先ファイル1651及びファイル要求元1652をデータ要求元管理テーブル1650に登録する(ステップ1715)。そして、移行先ファイルコントローラ1520は、移行元ファイルストレージ1510から、リード対象ファイルに対応したファイル(若しくはディレクトリ)のデータを取得する(ステップ1720)。続けて、移行先ファイルコントローラ1520は、ステップ1715で登録したデータ要求元管理テーブル1650の要求元1652を参照し、要求元が分散拠点1560外部にあるオブジェクトストレージ802か否かを判断する(ステップ1725)。
要求元がオブジェクトストレージ802である場合、移行先ファイルコントローラ1520は、ステップ1720で取得した移行元ファイルストレージ1501のデータをそのまま(移行先ファイルストレージ1502のファイルシステムに格納すること無しに)要求元に返す(ステップ1730)。
要求元がオブジェクトストレージ802ではない場合、移行先ファイルコントローラ1520は、ステップ1720で取得した移行元ファイルストレージ1501のデータを一旦移行先ファイルストレージ1502のファイルストレージに書き込み(ステップ1735)、移行用スタブデータテーブル1600上のスタブフラグ1604を“OFF”にする(ステップ1740)。その上で、移行先ファイルコントローラ1520は、ファイルシステムに書き込んだデータを要求元に返す(ステップ1745)。ステップ1745では、移行先ファイルコントローラ1520は、ステップ1730同様、ステップ1720で取得した移行元ファイルストレージ1501のデータをそのまま返してもよい。その場合、ファイルシステムへのアクセス回数を削減することができる。
本実施例によれば、分散拠点1560においてファイルストレージ1501及び1502間のデータ移行を実施している最中であっても、分析用ホスト830は、移行元ファイルストレージ1502及び移行元ファイルストレージ1501間のデータの所在を問わず、オブジェクトストレージ802を介し分散拠点1560内のデータを参照することができる。さらに、移行先ファイルコントローラ1520は、ファイルの要求元が分散拠点1560内かオブジェクトストレージ802かを認識して、移行元ファイルストレージ1510から取得したデータを自身のファイルシステムに書き込むか否かを判断する。これにより、オブジェクトストレージ802からの要求に対しては移行元ファイルストレージ1501から取得したデータを自身のファイルシステムに書かないように制御することで、オブジェクトストレージ840からの要求に応答して移行先ファイルコントローラ1520が実行するアクセス(入出力)の回数を削減し、オブジェクトストレージ802からの要求がホスト880のアクセス性能へ及ぼす影響を抑えることが期待できる。
なお、本実施例において、移行元ファイルストレージ1501は、分散拠点1560の外に存在していてもよい。移行元ファイルストレージ1501は、第3のストレージ装置の一例である。
実施例5を説明する。以下、実施例1との相違点を主に説明し、実施例1との共通点については説明を簡略又は省略する。なお、実施例5の説明は、主に実施例1との対比で行われるが、実施例5の説明において、「エッジストレージ」及び「エッジコントローラ」は、「ファイルストレージ」及び「ファイルコントローラ」と読み替えることができる。また、「コアストレージ」及び「コアコントローラ」は、「オブジェクトストレージ」及び「オブジェクトコントローラ」と読み替えることができる。
実施例1(及び実施例2乃至実施例4)では、分析用ホスト230がデータにアクセスした際、オンデマンドでデータをエッジストレージ150からコアスコントローラ240がデータをコピー(取得)する。このため、分析用ホスト230が短時間に大量のデータにアクセスしたとき、これらのデータの更新フラグが“ON”であった場合、この延長で大容量のデータをエッジストレージ150からコアストレージ120へコピーすることが発生し得る。各分散拠点260と中央データセンタ210間のネットワーク帯域が狭い場合、データコピーに長時間を要し、分析用ホスト230で実行する分析処理の性能が低下する懸念がある。
そこで、本実施例では、これを防ぐため、エッジストレージ150で更新されたデータをコアストレージ120へ直ちにコピーすることで、各分散拠点260と中央データセンタ210間で、一度に大容量のデータがコピーされることを抑えることができる。このとき、分析用ホスト230で分析処理を実行する直前に、コアコントローラ240でスナップショットを作成することにより、分析用ホスト230のデータアクセスと、エッジストレージ150からコアストレージ120へのデータコピーとが衝突して分析用ホスト230がアクセスするデータの一貫性を喪失することを防ぐことができる。
図27は、実施例5の概要を示す模式図である。
エッジコントローラ290はボリューム1891のスナップショットを作成しない。ボリューム1891(第1のボリュームの一例)の更新が行われた場合、エッジコントローラ240は、差分データ(更新前ボリュームと更新後ボリュームとの差分としてデータ)をコアコントローラ240に送る。コアコントローラ240は、受信した差分データをコピー用ボリューム1822(第3のボリュームの一例)に格納し、そのボリューム1822のスナップショットとして参照用ボリューム1821(第2のボリュームの一例)を作成する。分析用ホスト230は、参照用ボリューム1821を参照し、分析を行う。
本実施例におけるLUマッピング管理テーブルはエッジコントローラ290中のメモリ292に格納されている。また、LUマッピング管理テーブルは、実施例1のLUマッピング管理テーブル360と異なる構成を持つ。
図28は、本実施例におけるLUマッピング管理テーブル1900の構成図である。
LUマッピング管理テーブル1900は、エッジストレージ150が保持するLU毎にエントリを持つ。各エントリは、LUN1901、コピー先ストレージ1902及びコピー先LUN1903といった情報を格納する。以下、1つのLUを例に取る(図28の説明で「対象LU」と言う)。
LUN1901は、対象LUのLUNである。コピー先ストレージ1902は、コピー先のコアストレージ120を一意に示す識別子である。コピー先LUN1903は、コピー先のコピー用ボリューム1822のLUNである。コピー先のコアストレージ150を一意に示す識別子には、IPアドレスやWWNが利用できる。
本実施例では、コアストレージコントローラ240中のメモリ242及びエッジストレージコントローラ290中のメモリ292に格納されるプログラムの動作及びテーブル種別が実施例1と異なる。本実施例では、スナップショット管理テーブル330はコアストレージコントローラ240中のメモリ242に格納され、LUマッピング管理テーブル1900は前述のとおりエッジストレージコントローラ290に格納される。また、コピー状態管理テーブル370はメモリ242及びメモリ292のいずれも要しない。
図29は、ホスト280からエッジコントローラ290がライト要求を受信した場合にエッジコントローラ290により開始されるライト処理のフロー図である。
エッジコントローラ290は、ライト要求に従うデータを自身が管理するボリューム(ライト要求で指定されているボリューム)に書き込む(ステップ2010)。次に、エッジコントローラ290は、ライト先ボリュームのLUNを基に、LUマッピング管理テーブル1900を参照し、対応するコピー先ストレージ1902とコピー先LUN1903を特定する(ステップ2020)。続けて、エッジコントローラ290は、特定したコピー先ストレージ1902に対応するコアコントローラ240に、特定したLUNと、書込み先アドレス(例えばライト要求で指定されたアドレス)、書込みサイズ(ライト対象データのサイズ)、ライト対象データ(ライト要求に従うデータ)とが関連付けられたライト要求を送信する(ステップ2030)。
コアコントローラ240は、そのライト要求を受信すると、そのライト要求に関連付いたLUNに対応するコピー用ボリューム1822のうちの、そのライト要求に関連付いたアドレスが属する領域に、ライト対象データを書き込む(ステップ2040)。
なお、ステップ2020、2030及び2040は、ホスト280にライト要求に対する応答を返す前に実施されてもよいし、その応答の後に実施されてもよい。
コアコントローラ240は、エッジコントローラ290の挙動とは関係なく、任意のタイミングでスナップショットを作成できる。例えば、一定時間毎にスナップショットを作成するなどの運用が考えられる。逆に、エッジコントローラ290やホスト280の動作と連動してスナップショットをコアコントローラ240が作成してもよい。例えば、ホスト280が一連のデータを書き込む際、ホスト280とコアコントローラ240で通信を行い、データの整合性が取れた状態を通知し、その契機で実施する、などの動作が考えられる。
実施例6を説明する。以下、実施例1及び5との相違点を主に説明し、実施例1及び5との共通点については説明を簡略又は省略する。なお、実施例6の説明は、主に実施例1及び5との対比で行われるが、実施例6の説明において、「エッジストレージ」及び「エッジコントローラ」は、「ファイルストレージ」及び「ファイルコントローラ」と読み替えることができる。また、「コアストレージ」及び「コアコントローラ」は、「オブジェクトストレージ」及び「オブジェクトコントローラ」と読み替えることができる。
図30は、実施例6の概要を示す模式図である。
実施例6では、コアコントローラ240が、実施例1(及び実施例2乃至4)のようなオンデマンド型データコピー(分析用ホスト130からのリード要求に応答してデータを分散拠点140からコピーすること)と、実施例5のようなバックグラウンド型データコピー(分析用ホスト130からのリード要求の有無に関係無くデータを分散拠点140からコピーすること)とを併用又は切り替える。つまり、オンデマンド型データコピーとバックグラウンド型データコピーの両方が同時期に行われてもよいし、それらのコピーの一方が採用されている期間は他方が採用されないでもよい。
以下が、1つの具体例である。
参照用ボリューム2821は、第2のボリュームの一例であり、仮想的なボリュームであるとする。参照用ボリューム2821のページの参照先は、コピー用ボリューム2822内のページであることもあれば、上述したD-vol内のページであることもあってもよい。
また、エッジコントローラ290は、実施例1と同様、ホスト160からライト要求を受けた場合、ライト先ページのIDを含んだ更新通知をコアコントローラ240に送信するようになっている。結果として、更新ビットマップテーブル340の更新がコピー状態管理テーブル370に反映されるようになっている。エッジコントローラ290が、ボリューム2891(第1のボリュームの一例)を提供する。
コアコントローラ240は、参照用ボリューム2821について、新規ページアクセス回数を管理している。「新規ページ」とは、参照用ボリューム2821が分析用ホスト130に提供されてから初めてアクセス先(リード元又はライト先)とされたページである。
コアコントローラ240は、参照用ボリューム2821の新規ページにアクセスされる都度に、新規ページアクセス回数を更新(例えばインクリメント)する。
コアコントローラ240は、新規ページアクセス回数を、定期的に0(ゼロ)にリセットする。リセットの契機は、例えば,分析処理の実行スケジュールに合わせた「分析処理の実行前」であってもよいし、所定周期毎であってもよい。
新規ページアクセス回数が0ということは、分析処理に必要なデータはすべてエッジストレージ150から取得済ということになる。この状態は、参照用ボリューム2821に十分にデータが格納されているとみなす条件である格納状態条件に適合した状態である。格納状態条件の一例が、新規ページアクセス回数が所定回数以下(例えば0)である。格納状態条件の別の一例は、参照用ボリューム2821の使用率が所定使用率以上である。参照用ボリューム2821の使用率とは、参照用ボリューム2821の容量に対する、参照用ボリューム2821に格納されているデータ(参照先が存在するページ)の量の割合である。
コアコントローラ240は、定期的に又は不定期的に、格納状態条件が満たされているか否かを判断する(S31)。
<格納状態条件が満たされていない場合(例えば、新規ページアクセス回数が1以上の場合)>
コアコントローラ240は、バックグラウンド型データコピーを開始せず、オンデマンド型データコピーを採用している状態を維持する(S32)。つまり、コアコントローラ240は、分析用ホスト130からリード要求を受け(S21)、コアリード処理を行う。
すなわち、コアコントローラ240は、そのリード要求で指定されたLUに対応するコピー状態管理テーブル370を参照し(図31:ステップ2110)、リード元ページ(リード要求で指定されたアドレスに属するページ)に対応するエントリを特定する。
特定したエントリ内の未コピーフラグ573“ON”の場合(つまり、リード元ページが新規ページの場合)、コアコントローラ240は、新規ページアクセス回数をインクリメントし(図30:S22、図31:ステップ2130)、リード対象データの取得要求をエッジストレージ150に送信する(図31:ステップ2150)。これにより、コアコントローラ240は、リード対象データをエッジストレージ150から取得する(図30:S23)。コアコントローラ240は、取得したリード対象データをリード元ページに格納し(例えば、リード元ページに割り当てた空きD-volページに格納し)、そのリード対象データを当該ページから読み出して分析用ホスト130に返す。この後、コアコントローラは、コピー状態管理テーブル370における当該ページの更新フラグ572及び未コピーフラグ573を共に“OFF”にする。
特定したエントリ内の更新フラグ572“ON”の場合(すなわち、未コピーフラグがONであることに起因するコピーが実行されて以降、エッジストレージで当該ページが更新され、かつその更新がエッジコントローラからコアコントローラに通知されたものの、いまだ最新データが取得されていない場合)、コアコントローラ240は、リード対象データの取得要求をエッジストレージ150に送信する(図31:ステップ2150)。コアコントローラ240は、取得したリード対象データをリード元ページに格納し(例えば、リード元ページに新たに割り当てた空きD-volページ又は割当て済のD-volページに格納し)、そのリード対象データを当該ページから読み出して分析用ホスト130に返す。この後、コアコントローラは、コピー状態管理テーブル370における当該ページの更新フラグ572を“OFF”にする。
<格納状態条件が満たされている場合(例えば、新規ページアクセス回数が0の場合)>
コアコントローラ240は、バックグラウンド型データコピーを開始する(図30:S33)。つまり、コアコントローラ240は、エッジストレージ150において更新されたデータがあることを検知した場合(更新フラグ572“ON”に対応したページがある場合)、当該データをエッジストレージ150からコピー用ボリューム2822(第3のボリュームの一例)にコピーする(S34)。
実施例6では、オンデマンド型データコピーとバックグラウンド型データコピーとが自動で切り帰られるが、管理者等の手動により切り替えられてもよい。例えば、コアストレージ240は、参照用ボリューム2821の格納状態に関する情報(例えば新規ページアクセス回数)を管理システム(ストレージシステムを管理するシステム)に通知し、当該情報を見た管理者の指示を管理システムから受けて、バックグラウンド型データコピーを開始するか否かを決定してもよい。コアコントローラ240は、バックグラウンド型データコピーの開始後、リード元ページに対応した更新フラグ572が“ON”であるか否かに関わらずオンデマンド型データコピーを行わないでもよいし、リード元ページに対応した更新フラグ572が“ON”の場合はオンデマンド型データコピーも行ってもよい。
実施例6によれば、実施例1(及び実施例2乃至4)の効果と実施例5の効果の両方の効果を奏することが期待できる。
以上、本発明の幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
例えば、コアコントローラ240(又はオブジェクトコントローラ840)は、分析用ホストからのリード要求を受けたとき、前回更新通知を発行して以降に更新されたページ(又はデータセット)を示す更新通知をエッジコントローラ290(又はファイルコントローラ890)に要求し、当該要求に応答して受けた更新通知(例えば更新ビットマップテーブル340)を基に、コピー状態管理テーブル370(又はオブジェクト管理テーブル1012)を更新してもよい。
200:計算機システム
Claims (15)
- 第1の拠点に存在する第1のストレージ装置と、
第2の拠点に存在するストレージ装置であって、前記第1のストレージ装置とネットワークを介して接続されたストレージ装置である第2のストレージ装置と
を有し、
前記第1のストレージ装置が、それぞれがボリューム領域又はデータセットである複数の第1の要素を含むことが可能な第1のボリュームを提供し、
前記第2のストレージ装置が、それぞれがボリューム領域又はデータセットであり複数の第1の要素に対応した複数の第2の要素を含むことが可能な第2のボリュームを提供し、
前記第1のストレージ装置が、第1のホストからのライト要求に従い更新された第1の要素に関する更新通知を前記第2のストレージ装置に送信し、
前記第2のストレージ装置が、前記更新通知を受信した場合、当該更新通知を基に特定された第2の要素について、当該第2の要素に対応した第1の要素のデータが最新データであると管理し、
前記第2のストレージ装置が、第2のホストからリード要求を受けた場合、
(A)当該リード要求から特定された第2の要素であるリード元第2要素に対応した第1の要素のデータが最新データであるか否かを判断し、
(B)(A)の判断結果が真の場合、前記最新データの取得要求を前記第1のストレージ装置に送信し、
(C)当該取得要求に応答して前記第1のストレージ装置から取得された最新データを、前記リード元第2要素のデータとし、且つ、当該最新データを前記第2のホストに返す、
ストレージシステム。 - 各第1の要素及び各第2の要素は、いずれも、ボリューム領域であり、
前記更新通知は、最新世代の前記第1のボリュームと、更新通知が前回送信されたときの世代の前記第1のボリュームとの差分に相当する第1の要素のIDを含む、
請求項1記載のストレージシステム。 - 各第1の要素及び各第2の要素は、いずれも、ボリューム領域であり、
前記第2のストレージ装置が、コピー管理情報を有し、
前記コピー管理情報は、第2の要素毎に、
前記第1のストレージ装置から前記第2のストレージ装置への前回データコピー以降に当該第2の要素に対応した第1の要素のIDを含む更新通知を受けたか否かを示す第1の情報要素と、
前記第2のボリュームが作成されて以降に、前記第1のストレージ装置から当該第2の要素に対してデータが未コピーであるか否かを示す第2の情報要素と
を含み、
前記リード元第2要素に対応した第1及び第2の情報要素のうちの少なくとも1つが肯定的な値であれば、(A)の判断結果が真である、
請求項1記載のストレージシステム。 - 前記第2のストレージ装置が、 前記更新通知を受信した場合、当該更新通知から特定された第1の要素に対応した第2の要素についての第1の情報要素の値を、肯定的な値に更新する、
請求項3記載のストレージシステム。 - 前記第2のストレージ装置は、前記第1のストレージ装置が前記第1のホストから前記ライト要求を受信した場合に当該ライト要求に従い更新された第1の要素に関する前記更新通知を受信する、
請求項1記載のストレージシステム。 - 各第1の要素及び各第2の要素は、いずれも、データセットであり、
前記第1のストレージ装置が、前記第2のストレージ装置に、データセットのスタブを作成することの要求であるスタブ作成要求を送信し、
前記第2のストレージ装置は、前記第1のストレージ装置からの前記スタブ作成要求に応答として、当該スタブ作成要求で指定されているデータセットのスタブであって前記第2のホストから認識されるスタブを作成し、
前記リード要求は、前記作成されたスタブを指定したリード要求であり、
前記取得要求は、前記スタブに対応したデータセットの取得要求である、
請求項1記載のストレージシステム。 - 前記第2のストレージ装置が、コピー管理情報を有し、
前記コピー管理情報は、第2の要素毎に、
前記第1のストレージ装置から前記第2のストレージ装置への前回データコピー以降に当該第2の要素に対応した第1の要素のIDを含む更新通知を受けたか否かを示す第1の情報要素と、
前記第1のストレージ装置から当該第2の要素としてのデータセットがコピーされたことに代えて当該データセットのスタブか存在するか否かを示す第2の情報要素と
を含み、
前記リード元第2要素に対応した第1及び第2の情報要素のうちの少なくとも1つが肯定的な値であれば、(A)の判断結果が真である、
請求項6記載のストレージシステム。 - 第1の要素であるデータセットの種類と、第2の要素であるデータセットの種類とが異なっており、
前記第1のストレージ装置が、
第1の要素のIDと第2の要素のIDとの対応関係を示す第1の検索用情報と、
第2の要素のIDと第1の要素のIDとの対応関係を示す第2の検索用情報と
を有し、
前記第1のストレージ装置が、当該更新された第1の要素のIDに対応した第2の要素のIDを前記第1の検索用情報から特定し、
前記更新通知は、前記特定された第2の要素のIDを含む更新通知であり、
前記取得要求は、第2の要素のIDとして前記スタブのIDであるスタブIDを含み、
前記第1のストレージ装置が、
(F)当該取得要求内のスタブIDに対応した第1の要素のIDを前記第2の検索用情報から特定し、
(G)(F)で特定したIDに対応した第1の要素としてのデータセットを前記第2のストレージ装置に返す、
請求項6記載のストレージシステム。 - 各第1の要素は、ファイル又はディレクトリであり、
各第2の要素は、オブジェクト又はそのスタブであり、
前記第1のストレージ装置は、(F)で特定したIDに対応した第1の要素としてのデータセットがディレクトリの場合、
(H)当該ディレクトリに格納されている全てのデータセットの各々のスタブを前記第1のボリュームに作成する、
請求項8記載のストレージシステム。 - 第3のストレージ装置から前記第1のストレージ装置にデータを移行している最中において、前記第1のストレージ装置が、前記取得要求を前記第2のストレージ装置から受信した場合、
当該取得要求に従う取得対象の最新データが前記第1のストレージ装置に移行済みか否かを判断し、
当該判断の結果が真の場合、当該最新データを前記第2のストレージ装置に返し、
当該判断の結果が偽の場合、当該最新データを前記第3のストレージ装置から取得して前記第2のストレージ装置に返す、
請求項1記載のストレージシステム。 - 各第1の要素及び各第2の要素は、いずれも、データセットであり、
前記取得対象として前記第1のストレージ装置に存在する対象がデータセットのスタブの場合、前記判断の結果が偽である、
請求項10記載のストレージシステム。 - 前記第3のストレージ装置から前記第1のストレージ装置にデータを移行している最中において受信した要求の要求元が、前記第2のストレージ装置であるか前記第1のホストであるかを判断し、
前記要求元が前記第2のストレージ装置の場合、前記受信した要求は前記取得要求であり、前記第1のストレージ装置は、前記第3のストレージ装置から取得したデータを、前記第1のボリュームに格納すること無しに、前記第2のストレージ装置に返し、
前記要求元が前記第1のホストの場合、前記受信した要求はリード要求であり、前記第1のストレージ装置は、当該リード要求に従うデータであり前記第3のストレージ装置から取得したデータを、前記第1のボリュームに格納して、前記第1のホストに返す、
請求項10記載のストレージシステム。 - 前記第2のストレージ装置は、第3のボリュームを更に有し、
前記第2のストレージ装置は、
前記第2のボリュームに十分にデータが格納されているとみなす条件である格納状態条件が満たされているか否かを判断し、
当該判断の結果が偽の場合、前記第2のホストからのリード要求に応答して当該リード要求から特定された第2の要素に対応した第1の要素のデータが最新データであれば当該最新データを前記第1のストレージ装置から取得することであるオンデマンド型データコピーを採用している状態を維持し、
当該判断の結果が真の場合、前記第2のホストからのリード要求の有無に関わらずデータを前記第1のストレージ装置から前記第3のボリュームに取得することであるバックグラウンド型データコピーを開始する、
請求項1記載のストレージシステム。 - 前記格納状態条件が満たされているとは、前記第2のストレージ装置に新規にアクセスされる第2の要素の数が所定数未満であることである、
請求項13記載のストレージシステム。 - 第2のストレージ装置が、第1のホストからのライト要求に従い更新された第1の要素に関する更新通知を、第1のストレージ装置から受信し、
前記第1のストレージ装置は、それぞれがボリューム領域又はデータセットである複数の第1の要素を含むことが可能な第1のボリュームを提供し、第1の拠点にある装置であり、
前記第2のストレージ装置は、それぞれがボリューム領域又はデータセットであり複数の第1の要素に対応した複数の第2の要素を含むことが可能な第2のボリュームを提供し、第2の拠点にある装置であり、
前記第2のストレージ装置が、前記更新通知を受信した場合、当該更新通知を基に特定された第2の要素について、当該第2の要素に対応した第1の要素のデータが最新データであると管理し、
前記第2のストレージ装置が、第2のホストからリード要求を受けた場合、
(A)当該リード要求から特定された第2の要素であるリード元第2要素に対応した第1の要素のデータが最新データであるか否かを判断し、
(B)(A)の判断結果が真の場合、前記最新データの取得要求を前記第1のストレージ装置に送信し、
(C)当該取得要求に応答して前記第1のストレージ装置から取得された最新データを、前記リード元第2要素のデータとし、且つ、当該最新データを前記第2のホストに返す、
データ転送制御方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2017/028171 WO2019026222A1 (ja) | 2017-08-03 | 2017-08-03 | ストレージシステム及びデータ転送制御方法 |
US16/491,520 US10936243B2 (en) | 2017-08-03 | 2017-08-03 | Storage system and data transfer control method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2017/028171 WO2019026222A1 (ja) | 2017-08-03 | 2017-08-03 | ストレージシステム及びデータ転送制御方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2019026222A1 true WO2019026222A1 (ja) | 2019-02-07 |
Family
ID=65233420
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2017/028171 WO2019026222A1 (ja) | 2017-08-03 | 2017-08-03 | ストレージシステム及びデータ転送制御方法 |
Country Status (2)
Country | Link |
---|---|
US (1) | US10936243B2 (ja) |
WO (1) | WO2019026222A1 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021144288A (ja) * | 2020-03-10 | 2021-09-24 | 株式会社日立製作所 | 計算機システム、ファイルストレージ、及び、データ転送方法 |
CN116112511A (zh) * | 2022-12-28 | 2023-05-12 | 中国人寿保险股份有限公司上海数据中心 | 一种基于多网关的分布式储存系统 |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6878369B2 (ja) * | 2018-09-03 | 2021-05-26 | 株式会社日立製作所 | ボリューム配置管理装置、ボリューム配置管理方法、及びボリューム配置管理プログラム |
US11063811B2 (en) * | 2019-04-24 | 2021-07-13 | Vmware, Inc. | Multi-tenant event sourcing and audit logging in a cloud-based computing infrastructure |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09212398A (ja) * | 1996-02-05 | 1997-08-15 | Fuji Electric Co Ltd | データベース更新参照方法 |
JP2009009333A (ja) * | 2007-06-27 | 2009-01-15 | Hitachi Ltd | 非同期リモートコピーシステムの制御方法及び非同期リモートコピーシステム |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6269431B1 (en) | 1998-08-13 | 2001-07-31 | Emc Corporation | Virtual storage and block level direct access of secondary storage for recovery of backup data |
US7275177B2 (en) | 2003-06-25 | 2007-09-25 | Emc Corporation | Data recovery with internet protocol replication with or without full resync |
US8645653B2 (en) | 2010-10-14 | 2014-02-04 | Hitachi, Ltd | Data migration system and data migration method |
US8856073B2 (en) | 2010-12-14 | 2014-10-07 | Hitachi, Ltd. | Data synchronization among file storages using stub files |
US9594822B1 (en) * | 2013-03-13 | 2017-03-14 | EMC IP Holding Company LLC | Method and apparatus for bandwidth management in a metro cluster environment |
US10082979B2 (en) * | 2013-08-06 | 2018-09-25 | International Business Machines Corporation | Input/output operation management in a device mirror relationship |
US9396121B2 (en) * | 2014-03-12 | 2016-07-19 | International Business Machines Corporation | Managing sequentiality of tracks for asynchronous PPRC tracks on secondary |
US9946604B1 (en) * | 2015-02-04 | 2018-04-17 | Tintri Inc. | Optimized remote cloning |
US10678661B2 (en) * | 2017-03-20 | 2020-06-09 | International Business Machines Corporation | Processing a recall request for data migrated from a primary storage system having data mirrored to a secondary storage system |
US10572507B2 (en) * | 2017-05-24 | 2020-02-25 | International Business Machines Corporation | Coordination of point-in-time copy in asynchronous mirror environment during consistency group formation |
-
2017
- 2017-08-03 US US16/491,520 patent/US10936243B2/en active Active
- 2017-08-03 WO PCT/JP2017/028171 patent/WO2019026222A1/ja active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09212398A (ja) * | 1996-02-05 | 1997-08-15 | Fuji Electric Co Ltd | データベース更新参照方法 |
JP2009009333A (ja) * | 2007-06-27 | 2009-01-15 | Hitachi Ltd | 非同期リモートコピーシステムの制御方法及び非同期リモートコピーシステム |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021144288A (ja) * | 2020-03-10 | 2021-09-24 | 株式会社日立製作所 | 計算機システム、ファイルストレージ、及び、データ転送方法 |
JP7061635B2 (ja) | 2020-03-10 | 2022-04-28 | 株式会社日立製作所 | 計算機システム、ファイルストレージ、及び、データ転送方法 |
CN116112511A (zh) * | 2022-12-28 | 2023-05-12 | 中国人寿保险股份有限公司上海数据中心 | 一种基于多网关的分布式储存系统 |
Also Published As
Publication number | Publication date |
---|---|
US10936243B2 (en) | 2021-03-02 |
US20200073584A1 (en) | 2020-03-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9727430B2 (en) | Failure recovery method in information processing system and information processing system | |
US9529551B2 (en) | Systems and methods for instantaneous cloning | |
JP5507670B2 (ja) | ストライプ化ファイルシステムにおける能力平準化によるデータ分散 | |
US11720525B2 (en) | Flexible tiering of snapshots to archival storage in remote object stores | |
WO2014066417A1 (en) | Simplified copy offload | |
US9075755B1 (en) | Optimizing data less writes for restore operations | |
US10936243B2 (en) | Storage system and data transfer control method | |
US11341056B2 (en) | Low-overhead atomic writes for persistent memory | |
US9063892B1 (en) | Managing restore operations using data less writes | |
US11544007B2 (en) | Forwarding operations to bypass persistent memory | |
EP4124968A1 (en) | Technique for efficiently indexing data of an archival storage system | |
US20210286541A1 (en) | Techniques for data migration | |
US20240241801A1 (en) | Maintaining and recomputing reference counts in a persistent memory file system | |
US20240061603A1 (en) | Co-located Journaling and Data Storage for Write Requests | |
US10324652B2 (en) | Methods for copy-free data migration across filesystems and devices thereof | |
US10089125B2 (en) | Virtual machines accessing file data, object data, and block data | |
US12014201B2 (en) | Policy enforcement and performance monitoring at sub-LUN granularity | |
US11803527B2 (en) | Techniques for efficient data deduplication | |
US10936540B2 (en) | Methods for accelerating storage media access and devices thereof | |
US20230333777A1 (en) | Replication techniques using a replication log | |
US11868256B2 (en) | Techniques for metadata updating and retrieval | |
US12050553B2 (en) | Supporting a lookup structure for a file system implementing hierarchical reference counting | |
US20220107916A1 (en) | Supporting a lookup structure for a file system implementing hierarchical reference counting | |
JP2022070669A (ja) | データベースシステム、及びクエリ実行方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 17919783 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 17919783 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: JP |