WO2019026222A1 - ストレージシステム及びデータ転送制御方法 - Google Patents

ストレージシステム及びデータ転送制御方法 Download PDF

Info

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
Application number
PCT/JP2017/028171
Other languages
English (en)
French (fr)
Inventor
彰義 土谷
敬一 松澤
光雄 早坂
山本　彰
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2017/028171 priority Critical patent/WO2019026222A1/ja
Priority to US16/491,520 priority patent/US10936243B2/en
Publication of WO2019026222A1 publication Critical patent/WO2019026222A1/ja

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

第２の拠点内の第２のストレージ装置が、第１のホストからのライト要求に従い更新された第１の要素に関する更新通知を、第１の拠点内の第１のストレージ装置から受信した場合、当該更新通知を基に特定された第２の要素について、当該第２の要素に対応した第１の要素のデータが最新データであると管理する。第１のストレージ装置は、複数の第１の要素を含むことが可能な第１のボリュームを提供する。第２のストレージ装置は、複数の第１の要素に対応した複数の第２の要素を含むことが可能な第２のボリュームを提供する。第２のストレージ装置が、第２のホストからリード要求を受けた場合、リード元第２要素（当該リード要求から特定された第２の要素）に対応した第１の要素のデータが最新データであるか否かを判断する。当該判断結果が真の場合、第２のストレージ装置が、最新データを第１のストレージ装置から取得して第２のホストに返す。

Description

ストレージシステム及びデータ転送制御方法
　本発明は、概して、拠点間（ストレージ装置間）のデータ転送に関する。
　計算機システムの用途として、ＩｏＴ（Internet of Things）等の技術により得られたデータであって拠点内のストレージ装置に格納されたデータを分析し、分析結果をフィードバックすることで、業務を最適化する用途が知られている。このような用途においては、複数の拠点のデータを中央のデータセンタで横断的に分析するために、中央データセンタによって各拠点のデータを参照可能としなければならない。なお、「拠点」は、「第１の拠点」の一例であり、「中央データセンタ」は、「第２の拠点」の一例である。ここで言う「拠点」とは（第１及び第２の拠点のいずれも）、データセンタ又はネットワークセグメントのような計算機システムが設置された拠点を言う。各拠点の計算機システムは、ストレージ装置を含む。
　中央データセンタが各拠点のデータを参照するため、各拠点のストレージ装置がデータを中央データセンタに転送する。例えば、特許文献１は、第１の拠点に対し行われたデータの更新を第２の拠点に非同期に転送することで、第１の拠点のデータを第２の拠点に複製する技術を開示している。この技術を前述の分散拠点－中央データセンタ間に適用する場合、全ての更新データが中央データセンタに転送される。特許文献１の技術では、分析に一部のデータしか要しない場合でも全更新データの転送が必要となる。このため、各拠点の全データを中央データセンタに転送完了するまで分析を開始することができず、業務への分析結果の活用が遅れるという問題がある。これに加え、各拠点と中央データセンタとの間のネットワークの帯域を過剰に消費するという問題もある。
　一方、全データのコピー完了を必要とせず、第１の拠点のデータを第２の拠点からアクセス可能とする技術として、例えば、特許文献２が開示する技術がある。特許文献２によれば、複数のストレージ装置において、アクセス要求を受けたストレージ装置が、その要求に従うアクセス対象のデータを保有していない場合、アクセス要求を外部のストレージ装置に転送することで、外部ストレージからアクセス対象のデータを取得する。この処理は、ボリューム単位の処理のため、単一のボリュームに格納されているデータは全て転送対象となる。そのため、データの一部を中央データセンタに残すと言った細かい粒度の管理を行うことができない。この結果、中央データセンタで実行される分析処理が、遠隔の拠点のデータにアクセスすると、分析処理のデータアクセスは拠点間のデータコピーを伴うこととなり、分析処理の性能低下を引き起こす。
　なお、データコピーに関し、更に、特許文献３及び４に開示の技術も知られている。
US7,275,177 US6,269,431 US8,984,248 US8,856,073
　従って、本発明が解決しようとする課題は、第２の拠点において複数の第１の拠点で格納されているデータをアクセス対象（例えば分析対象）とする場合、第２の拠点でのアクセス性能の低下を抑えつつ、各第１の拠点から第２の拠点へのデータコピー完了を待たずに各第１の拠点のデータへのアクセスを可能とするとともに、第１の拠点と第２の拠点との間のネットワークの帯域の消費を抑えることである。
　第１の拠点に第１のストレージ装置が存在する。第２の拠点に第２のストレージ装置が存在する。第２のストレージ装置は、第１のストレージ装置とネットワークを介して接続されたストレージ装置である。
　第１のストレージ装置が、それぞれがボリューム領域又はデータセットである複数の第１の要素を含むことが可能な第１のボリュームを提供する。第２のストレージ装置が、それぞれがボリューム領域又はデータセットであり複数の第１の要素に対応した複数の第２の要素を含むことが可能な第２のボリュームを提供する。
　第１のストレージ装置が、第１のホストからのライト要求に従い更新された第１の要素のＩＤを含む更新通知を前記第２のストレージ装置に送信する。第２のストレージ装置が、更新通知を受信した場合、当該更新通知から特定された第１の要素に対応した第２の要素について、当該第２の要素に対応した第１の要素のデータが最新データであると管理する。
　第２のストレージ装置が、第２のホストからリード要求を受けた場合、当該リード要求から特定された第２の要素であるリード元第２要素に対応した第１の要素のデータが最新データであるか否かを判断する。当該判断結果が真の場合、第２のストレージ装置が、最新データの取得要求を第１のストレージ装置に送信する。当該取得要求に応答して第１のストレージ装置から取得された最新データを、第２のストレージ装置が、リード元第２要素のデータとし、且つ、当該最新データを第２のホストに返す。
　第１の拠点内の全データを第２の拠点にコピーされることを待つことなく、第２のホストが、第１の拠点内のデータを参照することができる。この参照により第１の拠点から第２の拠点に取得されたデータは第２の拠点に格納されるため、以後利用可能であり、結果として、以後の第２の拠点でのアクセス性能の低下を抑えることが期待できる。また、第１の拠点から第２の拠点へ転送するデータの量を削減することで、ネットワーク帯域の消費を削減することができる。
図１は、実施例１の概要を示す模式図である。 図２は、実施例１における計算機システムの構成図である。 図３は、実施例１におけるコアコントローラ中のメモリに格納されたプログラム及びテーブルを示す図である。 図４は、実施例１におけるスナップショット取得動作の概要を示す図である。 図５は、実施例１におけるスナップショット管理テーブルの構成図である。 図６は、実施例１におけるＬＵ管理テーブルの構成図である。 図７は、実施例１における更新ビットマップテーブルの構成図である。 図８は、実施例１におけるＬＵマッピング管理テーブルの構成図である。 図９は、実施例１におけるコピー状態管理テーブルの構成図である。 図１０は、実施例１における更新通知処理のフロー図である。 図１１は、実施例１におけるコアリード処理のフロー図である。 図１２は、実施例２における計算機システムの構成図である。 図１３は、実施例２におけるファイルコントローラ中のメモリに格納されたプログラム及びテーブルを示す図である。 図１４は、実施例２における第１検索テーブルの構成図である。 図１５は、実施例２における第２検索テーブルの構成図である。 図１６は、実施例２におけるオブジェクトコントローラ中のメモリに格納されたプログラム及びテーブルを示す図である。 図１７は、実施例２におけるオブジェクト管理テーブルの構成図である。 図１８は、実施例２におけるスタブデータテーブルの構成図である。 図１９は、実施例２におけるスタブ作成処理のフロー図である。 図２０は、実施例２におけるオブジェクリード処理のフロー図である。 図２１は、実施例２におけるデータコピー処理のフロー図である。 図２２は、実施例３における計算機システムの構成図である。 図２３は、実施例４における計算機システムの構成図である。 図２４は、実施例４における移行用スタブデータテーブルの構成図である。 図２５は、実施例４におけるデータ要求元管理テーブルの構成図である。 図２６は、実施例４における移行先リード処理のフロー図である。 図２７は、実施例５の概要を示す模式図である。 図２８は、実施例５におけるＬＵマッピング管理テーブルの構成図である。 図２９は、実施例５におけるライト処理のフロー図である。 図３０は、実施例６の概要を示す模式図である。 図３１は、実施例６におけるコアリード処理のフロー図である。
　以下の説明では、「インタフェース部」は、ユーザインタフェース部と、通信インタフェース部とのうちの少なくとも１つを含んでよい。ユーザインタフェース部は、１以上のＩ／Ｏデバイス（例えば入力デバイス（例えばキーボード及びポインティングデバイス）と出力デバイス（例えば表示デバイス））と表示用計算機とのうちの少なくとも１つのＩ／Ｏデバイスを含んでよい。通信インタフェース部は、１以上の通信インタフェースデバイスを含んでよい。１以上の通信インタフェースデバイスは、１以上の同種の通信インタフェースデバイス（例えば１以上のNIC（Network Interface Card））であってもよいし２以上の異種の通信インタフェースデバイス（例えばNICとHBA（Host Bus Adapter））であってもよい。
　また、以下の説明では、「メモリ部」は、１以上のメモリを含む。少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。メモリ部は、主に、プロセッサ部による処理の際に使用される。
　また、以下の説明では、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサである。１以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサ部は、処理の一部または全部を行うハードウェア回路（例えばパリティ計算用の回路）を含んでもよい。
　また、以下の説明では、「ｘｘｘテーブル」といった表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。
　また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜にメモリ部及び／又はインタフェース部等を用いながら行うため、処理の主語が、プロセッサ部（或いは、そのプロセッサ部を有する装置又はシステム）とされてもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な（例えば非一時的な）記録媒体であってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
　また、以下の説明では、「分散拠点」は、第１の拠点の一例である。「中央データセンタ」は、第２の拠点の一例である。
　また、以下の説明では、「ストレージシステム」は、１以上の第１の拠点がそれぞれ有する１以上の第１のストレージ装置と、１以上の第１の拠点に対する第２の拠点が有する第２のストレージ装置とを含む。各ストレージ装置は、１以上のストレージマシンで構成される。少なくとも１つのストレージマシンは、汎用的な物理計算機であってもよいし、２以上の記憶デバイスを有するディスクアレイ装置でもよい。また、少なくとも１つのストレージマシンが、仮想的なストレージマシンであってもよいし、ＳＤｘ（Software-Defined anything）を実行してもよい。ＳＤｘとしては、例えば、ＳＤＳ（Software Defined Storage）（仮想的なストレージ装置の一例）又はＳＤＤＣ（Software-defined Datacenter）を採用することができる。例えば、ストレージ装置としてのＳＤＳと、ホスト計算機としての仮想的な計算機とが、同一拠点における計算機システム上で実行されてもよい。
　また、以下の説明では、「ボリューム」は、論理ボリュームの略であり、論理的な記憶領域である。ボリュームは、実体的なボリューム（ＲＶＯＬ）であってもよいし、仮想的なボリューム（ＶＶＯＬ）であってもよい。「ＲＶＯＬ」は、そのＲＶＯＬを提供するストレージシステムが有する物理的な記憶資源（例えば、一以上の物理ドライブ）に基づくボリュームでよい。「ＶＶＯＬ」は、複数の仮想領域（仮想的な記憶領域）で構成されており容量仮想化技術（典型的にはThin Provisioning）に従うボリュームでよい。
　図１は、実施例１の概要を示す模式図である。
　計算機システム２００は、１又は複数の分散拠点２６０（第１の拠点の一例）と、１つの中央データセンタ２１０（第２の拠点の一例）とを有する。以下、１つの分散拠点２６０を例に取る。
　分散拠点２６０には、ホスト計算機（以下、ホスト）２８０と、ストレージ装置（以下、エッジストレージ）１５０とが存在する。ホスト２８０は、第１のホストの一例である。エッジストレージ１５０は、第１のストレージ装置の一例である。中央データセンタ２１０には、分析用ホスト計算機（以下、分析用ホスト）２３０と、ストレージ装置（以下、コアストレージ）１２０とが存在する。分析用ホスト２３０は、第２のホストの一例であり、分析のために使用されるホストである。コアストレージ１２０は、第２のストレージ装置の一例である。ストレージシステムは、エッジストレージ１５０とコアストレージ１２０とを含む。
　分散拠点２６０において、エッジストレージ１５０が、ホスト２８０にボリューム１５１（第１のボリュームの一例）を提供する。エッジストレージ１５０は、ホスト２８０から、ボリューム１５１を指定したアクセス要求（ライト要求又はリード要求）を受信する。例えば、エッジストレージ１５０は、ホスト２８０から、ボリューム１５１を指定したライト要求を受信した場合、そのライト要求に従うライト対象のデータを、ボリューム１５１に書き込む。ボリューム１５１は、複数のボリューム領域で構成される。ライト対象データが、ライト先の１以上のボリューム領域に書き込まれる。本実施例では、ボリューム１５１は、ＶＶＯＬ（Thin Provisioningに従うボリューム）であり、ボリューム領域は、ページである。なお、ボリューム領域は、ボリューム内の要素の一例である。
　同様に、中央データセンタ２１０において、コアストレージ１２０が、分析用ホスト２３０にボリューム１２１（第２のボリュームの一例）を提供する。コアストレージ１２０は、分析用ホスト２３０から、ボリューム１２１を指定したアクセス要求を受信する。例えば、コアストレージ１２０は、分析用ホスト２３０から、ボリューム１２１を指定したリード要求を受信した場合、そのリード要求に従うリード対象のデータを、ボリューム１２１から読み出し、読み出したデータを分析用ホスト２３０に返す。ボリューム１２１は、複数のボリューム領域で構成される。リード対象データが、リード元の１以上のボリューム領域から読み出される。本実施例では、ボリューム１２１は、ＶＶＯＬ（Thin Provisioningに従うボリューム）であり、ボリューム領域は、ページである。
　エッジストレージ１５０が、更新ビットマップテーブル３４０を管理する。更新ビットマップテーブル３４０は、ページ毎の更新の有無（ボリュームペアを構成するボリューム間の差分）を管理するためのテーブルである。例えば、更新ビットマップテーブル３４０は、ボリューム１５１のページ毎にページＩＤ及び更新フラグを有する。各ページについて、ページＩＤ及び更新フラグは以下の通りである。
・ページＩＤは、ページのＩＤである。
・更新フラグは、当該ページの更新の有無を示すフラグ（ビット））である。
　更新フラグ“OFF”のページに対してデータが書き込まれた場合、エッジストレージ１５０は、当該更新フラグを“OFF”から“ON”に更新する。
　コアストレージ１２０が、コピー状態管理テーブル３７０を管理する。コピー状態管理テーブル３７０は、ボリューム１２１のページ毎にデータ取得対象か否か（エッジストレージ１５０における対応するページに最新データがあるか否か）を管理する。例えば、コピー状態管理テーブル３７０は、ボリューム１２１のページ毎にページＩＤ、更新フラグ及び未コピーフラグを有する。各ページについて、ページＩＤ、更新フラグ及び未コピーフラグは以下の通りである。
・ページＩＤは、ページのＩＤである。
・更新フラグ（第１の情報要素の一例）は、エッジストレージ１５０からコアストレージ１２０への前回データコピー以降に当該ページに対応したページのＩＤを含んだ更新通知を受けたか否かを示すフラグである。
・未コピーフラグ（第２の情報要素の一例）は、ボリューム１２１が作成（提供）されて以降に、エッジストレージ１５０からコアストレージ１２０の当該ページにデータが未コピーであるか否かを示すフラグである。
　コピー状態管理テーブル３７０に関し、各ページについて、更新フラグ及び未コピーフラグの少なくとも１つが“ON”の場合、当該ページは、データ取得対象である。更新フラグ及び未コピーフラグが“OFF”の場合、当該ページは、データ取得対象ではない。すなわち、「最新データ」は、最近更新されたデータ、又は、更新されたか否かに関わらず一度もコピー（取得）されていないデータである。
　エッジストレージ１５０が、ボリューム１５１を指定したライト要求をホスト２８０から受信した場合（Ｓ１）、ライト先ページ（ライト要求が指定するアドレスに属するページ）にデータを書き込む。また、エッジストレージ１５０が、ライト先ページに対応した更新フラグ（更新ビットマップテーブル３４０における更新フラグ）が“OFF”であれば“ON”に更新し、ライト先ページのページＩＤを含んだ更新通知をコアストレージ１２０に送信する（Ｓ２）。つまり、エッジストレージ１５０は、ページが更新された場合、更新されたページをコアストレージ１２０に通知する。更新通知を受けたコアストレージ１２０は、更新通知内のページＩＤに対応した更新フラグが“OFF”であれば“ON”に更新する。つまり、コアストレージ１２０は、コピー元のボリューム１５１で、通知されたページに更新が生じたことを記録する。
　コアストレージ１２０は、更新通知から、エッジストレージ１５０において更新されたページを知ることができるが、更新通知を受けた時点では、当該ページ内のデータを取得しないでよい。分析のためのリード要求に従うリード対象のデータとならない場合、当該データの取得に伴うデータ転送が無駄になるからである。
　コアストレージ１２０が、ボリューム１２１を指定したリード要求を分析用ホスト２３０から受信した場合（Ｓ３）、リード元ページ（リード要求で指定されたアドレスが属するページ）がデータ取得対象か否かを判断する。
　この判断結果が真の場合、コアストレージ１２０が、リード元ページに対応するコピー元ページ（リード元ページに対応する、ボリューム１５１内のページ）からデータをコピーし（取得し）（Ｓ４）、コピーしたデータを、Ｓ３で受信したリード要求に対する応答として、分析用ホスト２３０に返す。また、コアストレージ１２０が、リード元ページに対応した更新フラグ及び未コピーフラグにいずれについても“ON”であれば“OFF”に更新する。また、エッジストレージ１５０が、取得されたデータを格納するページ（リード元ページに対応する、ボリューム１５１内のページ）について、更新ビットマップテーブル３４０における更新フラグを“OFF”にしてよい。
　この判断結果が偽の場合、コアストレージ１２０が、リード元ページからデータを読み出し、読み出したデータを分析用ホスト２３０に返す。
　以下、実施例１を詳細に説明する。
　図２は、計算機システム２００の構成図である。
　計算機システム２００は、中央データセンタ２１０と１乃至複数の分散拠点２６０で構成される。中央データセンタ２１０及び分散拠点２６０は、広域ネットワーク２５０（例えばＷＡＮ（Wide Area Network）又はインターネット）により互いに接続される。なお、広域ネットワーク２５０は、内部ネットワークでもよい。エッジストレージ１５０は、１以上の記憶媒体２９５と、１以上の記憶媒体２９５に対する入出力を制御するコントローラ（以下、エッジコントローラ）２９０とを有する。コアストレージ１２０は、１以上の記憶媒体２４５と、１以上の記憶媒体２４５に対する入出力を制御するコントローラ（以下、コアコントローラ）２４０とを有する。エッジコントローラ２９０は、第１のコントローラの一例である。コアコントローラ２４０は、第２のコントローラの一例である。
　中央データセンタ２１０内は、広域ネットワーク２５０と接続された内部ネットワーク２２０を介し、コアコントローラ２４０及び１乃至複数の分析用ホスト２３０が接続されている。コアコントローラ２４０は、分析用ホスト２３０が参照するデータを格納又は提供する装置である。分析用ホスト２３０は、コアコントローラ２４０が格納するデータ、及びコアコントローラ２４０が透過的に（分析用ホスト２３０が、データの所在がエッジストレージ１５０にあることを認識することなく）アクセス可能としているエッジストレージ１５０中のデータにアクセスし、加工又は分析を行う計算機である。
　このコアコントローラ２４０は、各分散拠点２６０にあるエッジストレージ１５０が格納するデータを分析用ホスト２３０に透過的にアクセス可能とする機能を備える。コアコントローラ２４０は、ＣＰＵ２４１、メモリ２４２、ネットワークインタフェース２４３及びストレージインタフェース２４４を備え、それらは互いに内部で接続されている。ＣＰＵ２４１は、プロセッサ部の一例であり、メモリ２４２に格納されたプログラムの記載に従い、コアコントローラ２４０の構成要素を制御する。メモリ２４２は、メモリ部の一例であり、複数のプログラムやテーブルを格納し、ディスクキャッシュを有する。ネットワークインタフェース２４３及びストレージインタフェース２４４は、インタフェース部の一例である。コアコントローラ２４０は、ネットワークインタフェース２４３を介し内部ネットワーク２２０を通じて分析用ホスト２３０によるアクセス要求を処理したり、広域ネットワーク２５０を通じてエッジコントローラ２９０と通信したりする。ネットワークインタフェース２４３を介した通信プロトコルには、Ethernet（登録商標）、Fibre Channel、ＳＣＳＩ（Small Computer System Interface）等が利用可能である。また、コアストレージコントローラ２４０は、ストレージインタフェース２４４を介し記憶媒体２４５に対するデータの読み書きを行う。記憶媒体２４５としては、磁気ディスク、光ディスク、NAND Flash、不揮発メモリ等が利用可能である。また、他のストレージコントローラを階層的に用いることもできる。ストレージインタフェース２４４と記憶媒体２４５間の通信プロトコルには、ＳＣＳＩ、ＳＡＳ（Serial Attached SCSI）、ＡＴＡ（Advanced Technology Attachment）、ＮＶＭｅ（Non-Volatile Memory express）等を利用できる。本実施例は、ここで挙げた通信プロトコルや記憶媒体に限定することなく、一般的な計算機で利用可能な通信プロトコルや記憶媒体に対し適用可能である。
　分散拠点２６０内は、広域ネットワーク２５０と接続された内部ネットワーク２７０を介し、エッジスコントローラ２９０及び１乃至複数のホスト計２８０が接続されている。エッジコントローラ２９０は、ホスト２８０が生成するデータを格納する装置である。ホスト２８０は、当該ホスト２８０が生成及び取得するデータをエッジストレージ１５０に格納する。
　エッジコントローラ２９０は、ＣＰＵ２９１、メモリ２９２、ネットワークインタフェース２９３及びストレージインタフェース２９４を備え、それらは互いに内部で接続されている。ＣＰＵ２９１は、プロセッサ部の一例であり、メモリ２９２に格納されたプログラムの記載に従い、エッジコントローラ２９０の構成要素を制御する。メモリ２９２は、メモリ部の一例であり、複数のプログラムやテーブルを格納し、ディスクキャッシュを有する。ネットワークインタフェース２９３及びストレージインタフェース２９４は、インタフェース部の一例である。エッジコントローラ２９０は、ネットワークインタフェース２９３を介し内部ネットワーク２７０を通じてホスト２８０によるアクセス要求を受け付けたり、広域ネットワーク２５０を通じてコアコントローラ２４０と通信したりする。また、エッジコントローラ２９０は、ストレージインタフェース２９４を介し記憶媒体２９５に対するデータの読み書きを行う。エッジストレージコントローラ２９０の各通信プロトコルや記憶媒体２９５には、コアストレージコントローラ２４０同等のものを利用可能である。
　図３は、コアコントローラ２４０中のメモリ２４２及びエッジコントローラ２９０中のメモリ２９２に格納されている各種プログラム及びテーブルを示す図である。以下、両メモリ２４２及び２９２を総称して「メモリ３００」と記載する。メモリ３００中のプログラム及びテーブルのうち一部要素はメモリ２４２及び２９２のいずれかにしか存在しないものもあるが、そのような要素は個別に記載する。特に断りのない場合、各要素はメモリ２４２及び２９２の両方に含まれる。
　入出力制御プログラム３１０は、コアコントローラ２４０又はエッジコントローラ２９０が分析用ホスト２３０又はホスト２８０からのアクセス要求を受信した場合に、必要に応じてリモートコピープログラム３５０による拠点間データ転送処理を行った上で、記憶媒体２４５又は２９５のデータの読み書きを行い、その結果を分析用ホスト２３０又はホスト２８０に返すプログラムである。入出力制御プログラム３１０は、分析用ホスト２３０やホスト２８０に可視なボリュームの管理単位であるＬＵ（Logical Unit）を構成及び管理する。ＬＵは、記憶媒体２４５又は２９５の領域を分割又は連結することで生成される。ＬＵは、ボリュームと同義でよい。また、入出力制御プログラム３１０は、領域の複製、ＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）、Erasure Codingなどの冗長化機構を伴うこともできる。入出力制御プログラム３１０は、ＬＵのスナップショットの作成及び管理を行う機能を備える。
　ＬＵ管理テーブル３２０は、ＬＵの構成情報を格納する。スナップショット管理テーブル３３０は、ＬＵのスナップショットの構成情報を格納する。更新ビットマップテーブル３４０は、ＣｏＷ（Copy on Write）を用いたスナップショット管理に必要なビットマップ情報を拠点間でやりとりする場合に一時的に格納される。リモートコピープログラム３５０は、ネットワークインタフェース２４３又は２９３及び広域ネットワーク２５０を介しコアコントローラ２４０とエッジコントローラ２９０とで通信し、データの送受信を行うプログラムである。
　ＬＵマッピングテーブル３６０は、コアコントローラ２４０のみが保持するテーブルであり、コアコントローラ２４０が管理するＬＵと、エッジコントローラ２９０が管理するＬＵの対応付けを管理するテーブルである。
　コピー状態管理テーブル３７０は、コアコントローラ２４０のみが保持するテーブルである。コピー状態管理テーブル３７０は、ＬＵの各領域について、エッジコントローラ２４０からデータ取得が必要か否かを示す。
　メモリ３００のうち、これら各種プログラム・テーブルを格納した領域以外の全部又は一部である余剰領域は、記憶媒体２４５又は２９５のディスクキャッシュ３８０として用いることができる。
　図４は、コアコントローラ２４０及びエッジコントローラ２９０の各々のスナップショット取得の動作の概要を示す図である。以下、例としてコアコントローラ２４０を例に取る。
　分析用ホスト２３０のアクセス先のＬＵが、Ｐ－ｖｏｌ（Primary Volume）４２０である。Ｐ－ｖｏｌのスナップショットが、Ｓ－ｖｏｌ（Snapshot Volume）４４１である。Ｓ－ｖｏｌ４４１は、世代毎に存在する。世代間の差分を管理するためのＬＵが、Ｄ－ｖｏｌ（Differential Volume）４３０である。Ｐ－ｖｏｌ４２０及びＤ－ｖｏｌ４３０は、１以上の記憶媒体２４５上に構築されたプール４００に格納される（又は関連付けられる）。Ｓ－ｖｏｌ４４１は、Ｐ－ｖｏｌ４２０とＤ－ｖｏｌ４３０から構成される仮想的なボリュームであり、記憶媒体２４５上にＳ－ｖｏｌそのものが格納されるわけではない。また、Ｓ－ｖｏｌ４４１は、スナップショット世代毎に存在するため、Ｐ－ｖｏｌに対し、複数作成可能である。
　Ｐ－ｖｏｌ４２０、Ｄ－ｖｏｌ４３０、Ｓ－ｖｏｌ４４１はそれぞれ固定長のボリューム領域（ページ４１１）単位で管理される。各Ｓ－ｖｏｌ４４１中の各ページ４１１は、Ｐ－ｖｏｌ４２０中の同じ位置のページ４１１またはＤ－ｖｏｌ４３０中のページ４１１に対応付けられる。コアコントローラ２４０は、分析用ホスト２３０から、Ｓ－ｖｏｌ４４１を指定したアクセス要求を受信した場合、そのアクセス要求を、そのアクセス要求で指定されたアクセス先ページに対応する、Ｐ－ｖｏｌ４２０又はＤ－ｖｏｌ４３０中のページ、へのアクセス要求と見なす。この対応関係は、コアコントローラ２４０内のスナップショット管理テーブル３３０により管理される。また、Ｐ－ｖｏｌ内のページを「Ｐ－ｖｏｌページ」、Ｄ－ｖｏｌ内のページを「Ｄ－ｖｏｌページ」、及び、Ｓ－ｖｏｌ内のページを「Ｓ－ｖｏｌページ」とそれぞれ呼ぶことができる。
　プール４００は、例えば、１以上の記憶媒体２４５に基づく複数の実領域を含んでいてよい。各実領域は、論理的な記憶領域である。複数の実領域のうちの一部の実領域が、Ｄ－ｖｏｌ４３０を構成する複数のＤ－ｖｏｌページでもよい。また、実領域は、ＶＶＯＬであるＰ－ｖｏｌのＰ－ｖｏｌページに割り当てられてもよい。また、実領域は、Ｄ－ｖｏｌもＶＶＯＬである場合、Ｄ－ｖｏｌページに割り当てられてもよい。
　図５は、スナップショット管理テーブル３３０の構成図である。
　スナップショット管理テーブル３３０は、Ｐ－ｖｏｌ４２０に相当するＬＵ毎に存在する。スナップショット管理テーブル３３０は、Ｐ－ｖｏｌページのＩＤとスナップショットの世代番号とにより、Ｓ－ｖｏｌページの参照先として、対応するＰ－ｖｏｌページ又はＤ－ｖｏｌページを特定することができる。スナップショット管理テーブル３３０は、Ｐ－ｖｏｌ内のページ毎に、エントリを有する。各エントリが、ページＩＤ４５１、ＣｏＷフラグ４５２及び参照先ページＩＤ４５３といった情報を格納する。以下、１つのＰ－ｖｏｌページを例に取る（図５の説明で「対象ページ」と言う）。
　ページＩＤ４５１は、対象ページを一意に示す識別子である。ボリュームを構成するページ群に先頭から連番が付与されてもよいし、ハッシュ値等が用いられてもよい。図の例は、Ｐ－ｖｏｌのページＩＤ４５１として０から始まる連番が付与されている。ＣｏＷフラグ４５２は、対象ページについてＣｏＷ（対象ページがライト先とされた場合に対象ページ内のデータを退避すること）が必要か否かを示す。“ON”は、ＣｏＷが必要を意味する。参照先ページＩＤ４５３は、スナップショット世代毎に、対象ページに対応したＳ－ｖｏｌページの参照先ページのページＩＤである。具体的には、“－１”は、同じ位置のＰ－ｖｏｌページのＩＤ、すなわち、対象ページのページＩＤを示している。“－１”以外の値は、Ｄ－ｖｏｌページのＩＤを示している。
　世代数が多い場合、参照先ページＩＤ４５３“－１”の格納の有無の判断のため、スナップショット管理テーブル３３０を１行分全て探索する必要がある。この処理を高速化するため、コアコントローラ２４０は、事前に参照先ページＩＤ４５３“－１”の有無を求めておき、当該有無に応じてＣｏＷフラグ４５２の値を準備しておいてもよい。
　Ｐ－ｖｏｌページが一つでもＳ－ｖｏｌから参照されている（すなわち、スナップショット管理テーブル３３０に参照先ページＩＤ４５３“－１”が一つでも格納されている）場合、Ｐ－ｖｏｌ中のデータはスナップショットと共有されている状態である。この状態で、Ｐ－ｖｏｌページ若しくはＰ－ｖｏｌページを参照するＳ－ｖｏｌページに対しデータの更新が行われた場合、コアコントローラ２４０は、ＣｏＷを用いたデータの退避を行う。
　Ｃｏｗフラグ４５２“ON”に対応したＰ－ｖｏｌページが更新対象（ライト先）の場合、コアコントローラ２４０は、下記を行う。
・更新対象のＰ－ｖｏｌページ中のデータを空きＤ－ｖｏｌページにコピーする。
・Ｐ－ｖｏｌページを参照している全てのＳ－ｖｏｌページの参照先ページＩＤをコピー先Ｄ－ｖｏｌページのページＩＤに振り替える。
・更新対象のＰ－ｖｏｌページ中のデータを更新する。
・Ｃｏｗフラグ４５２を“OFF”に変更する。
　Ｃｏｗフラグ４５２“OFF”に対応したＰ－ｖｏｌページが更新対象の場合、コアコントローラ２４０は、下記を行う。
・更新対象のＰ－ｖｏｌページ中のデータを更新する。
　Ｓ－ｖｏｌページが更新対象であり、更新対象のＳ－ｖｏｌページの参照先ページがＰ－ｖｏｌページの場合、コアコントローラ２４０は、下記を行う。
・更新対象のＳ－ｖｏｌページの参照先Ｐ－ｖｏｌページ中のデータを空きＤ－ｖｏｌページにコピーする。
・更新対象のＳ－ｖｏｌページの参照先ページＩＤをコピー先Ｄ－ｖｏｌページのページＩＤに振り替える。
・コピー先Ｄ－ｖｏｌ中のデータを更新する。
　このようにして、Ｐ－ｖｏｌ又はＳ－ｖｏｌの更新は、他のＰ－ｖｏｌ又は世代のＳ－ｖｏｌのデータに影響を与えずに行うことができる。
　スナップショットを作成する場合、コアコントローラ２４０は、新たな世代番号を関連付けたＳ－ｖｏｌを作成し、スナップショット管理テーブル３３０中に、当該世代の参照先情報を格納できるようにする。その際、スナップショットを作成した瞬間は、Ｐ－ｖｏｌとＳ－ｖｏｌの内容は等しいため、コアコントローラ２４０は、当該Ｓ－ｖｏｌの全Ｓ－ｖｏｌページの参照先ページＩＤ４５３を“－１”とし、且つ、当該Ｐ－ｖｏｌの全Ｐ－ｖｏｌページのＣｏＷフラグ４５２を“ON”にする。
　図６は、ＬＵ管理テーブル３２０の構成図である。
　ＬＵ管理テーブル３２０は、コアコントローラ２４０及びエッジコントローラ２９０の各々において、コントローラ毎に１つ存在する。ＬＵ管理テーブル３２０は、ＬＵ毎にエントリを持つ。ここで言うＬＵには、Ｐ－ｖｏｌ、Ｄ－ｖｏｌ及びＳ－ｖｏｌのいずれも該当する。各エントリが、ＬＵＮ５２１及びサイズ５２２といった情報を格納する。以下、１つのＬＵを例に取る（図６の説明で「対象ＬＵ」と言う）。
　ＬＵＮ５２１は、対象ＬＵのＩＤの一例であるＬＵＮ（Logical Unit Number）である。サイズ５２２は、対象ＬＵのサイズ（容量）を示す。
　図７は、更新ビットマップテーブル３４０の構成図である。
　更新ビットマップテーブル３４０は、エッジコントローラ２９０とコアコントローラ２４０間でＬＵを構成する各ページの更新の有無を示す情報をやり取りするために一時的に生成されるテーブルである。更新ビットマップテーブル３４０は、ボリュームペア（ＬＵペア）毎に存在する。ここで言うボリュームペアは、分析用ホスト２３０により参照され得るボリューム（コアストレージ１２０が提供するボリューム）と、ホスト２８０により更新され得るボリューム（エッジストレージ１５０が提供するボリューム）とのペアである。更新ビットマップテーブル３４０は、ボリュームのページ毎にエントリを持つ。各エントリは、ページＩＤ５４１及び更新フラグ５４２といった情報を格納する。以下、１つのページを例に取る（図７の説明で「対象ページ」と言う）。
　ページＩＤ５４１は、対象ページのページＩＤである。更新フラグ５４２は、対象ページの更新の有無を示すフラグ（ビット））である。
　なお、対象ページについて、ページＩＤ５４１及び更新フラグ５４２に代えて、同等の内容を含む別のデータ構造が用いられてもよい。例えば、更新フラグをセットされたページＩＤのみをリストとして列挙したデータ構造や、ビットマップをRun Length等のアルゴリズムでデータ量を削減したデータ構造が適用できる。
　更新ビットマップテーブル３４０は、例えば、最新世代ｎのボリューム（エッジストレージ１５０内のボリューム）と、前回更新通知を送信したときの世代（例えばスナップショット世代（ｎ－１））のボリュームとの差分（更新されたページのＩＤ）を示すテーブルでよい。更新通知は、更新ビットマップテーブル３４０を含んでよい。
　図８は、ＬＵマッピング管理テーブル３６０の構成図である。
　ＬＵマッピング管理テーブル３６０は、コアコントローラ２４０が格納するテーブルである。ＬＵマッピング管理テーブル３６０は、コアストレージ１２０内のＬＵ毎にエントリを持つ。各エントリは、ＬＵＮ５６１、コピー元ストレージ５６２、コピー元ＬＵＮ５６３及びコピー元世代番号５６４といった情報を格納する。以下、１つのＬＵを例に取る（図８の説明で「対象ＬＵ」と言う）。
　ＬＵＮ５６１は、対象ＬＵのＬＵＮである。コピー元ストレージ５６２は、対象ＬＵのコピー元ＬＵ（対象ＬＵとペアを構成するＬＵ）を有するエッジストレージ１２０のＩＤ（例えばアドレス）である。コピー元ＬＵＮ５６３は、対象ＬＵのコピー元ＬＵのＬＵＮである。
　コピー元世代番号５６４は、対象ＬＵのコピー元ＬＵに関連付いた世代の番号を示す。“０”は、コピー元ＬＵがＰ－ｖｏｌであることを意味し、“０”より大きい番号は、コピー元ＬＵがＳ－ｖｏｌであることを意味してもよい。
　コピー元ストレージ５６２、コピー元ＬＵＮ５６３及びコピー元世代番号５６４から、分散拠点２６０中のエッジコントローラ２９０及び当該エッジコントローラ２９０が管理するＬＵ（世代）を一意に識別することができる。コピー元ストレージ５６２として、例えばＴＰＣ／ＩＰにおけるＩＰアドレスやホスト名、Fibre ChannelにおけるＷＷＮ（World Wide Name）、ｉＳＣＳＩにおけるQualified Name等が利用可能である。
　図９は、コピー状態管理テーブル３７０の構成図である。
　コピー状態管理テーブル３７０は、コアコントローラ２４０が格納するテーブルである。コピー状態管理テーブル３７０は、ボリュームペアを構成するＬＵ毎に存在する。コピー状態管理テーブル３７０は、ページ毎に、エントリを持つ。各エントリは、ページＩＤ５７１、更新フラグ５７２及び未コピーフラグ５７３といった情報を格納する。以下、１つのページを例に取る（図９の説明で「対象ページ」と言う）。
　ページＩＤ５７１は、対象のページを一意に特定するＩＤである。
　更新フラグ５７２は、対象ページについて、エッジコントローラ２９０からコアコントローラ２４０への前回データコピー以降、エッジコントローラ２９０からコアコントローラ２４０へ対象ページの更新が通知されたか否かを示す。
　未コピーフラグ５７３は、本テーブル３７０に対応するＬＵがコアコントローラ２４０により作成されて以降、エッジコントローラ２９０からコアコントローラ２４０へ対象ページにデータが未コピーであるか否かを示す。
　図１０は、更新通知処理のフロー図である。
　更新通知処理は、エッジコントローラ２９０においてスナップショットが作成される契機で開始される。
　エッジコントローラ２９０は、下記２つのスナップショットの世代番号を入力として受け取る。
・今回作成したスナップショット。
・前回更新ビットマップテーブル３４０をコアコントローラ２４０に送信した際に送信した世代番号５６４に相当するスナップショット。
　エッジコントローラ２９０は、出力として、上記の２つのスナップショット間における各ページの更新の有無を示す更新ビットマップテーブル３４０を、コアコントローラ２４０に送信する。
　更新通知処理の詳細の手順は、例えば下記の通りである。
　エッジコントローラ２９０は、スナップショット管理テーブル３３０を基に、更新ビットマップテーブル３４０を生成する（ステップ６１０）。この更新ビットマップテーブル３４０は、入力で与えられた２つの世代番号のスナップショット間で各ページに更新が生じたか否かを示す。各ページの更新の有無は、例えばスナップショット管理テーブル３３０の両世代の参照先ページの不一致を持って更新有りと判断できる。エッジコントローラ２９０は、生成した更新ビットマップテーブル３４０に、生成したスナップショット（Ｓ－ｖｏｌ）のＬＵＮと、入力のうち新しい方の世代番号とを関連付け、ＬＵＮ及び世代番号が関連付けられた更新ビットマップテーブル３４０を、コアコントローラ２４０に広域ネットワーク２５０を介し送信する（ステップ６２０）。
　コアコントローラ２４０は、エッジコントローラ２９０より更新ビットマップテーブル３４０（及びＬＵＮ及び世代番号）を受信すると（ステップ６３０）、コピー状態管理テーブル３７０の更新を始める。コアコントローラ２４０は、ＬＵマッピング管理テーブル３６０を参照し、送信元のエッジコントローラ２９０及び送信されたＬＵＮと合致するコピー元ストレージ５６２及びコピー元ＬＵＮ５６３を含む該当エントリを検索し、その該当エントリにおけるＬＵＮ５６１を特定する。コアコントローラ２４０は、更新ビットマップテーブル３４０中の各ページに対応するエントリを参照し、特定したＬＵＮ５６１に対応するコピー状態管理テーブル３７０においてページＩＤ５７１が一致するエントリの更新フラグ５７２を更新ビットマップテーブル３４０中の更新フラグ５４２で上書きする（ステップ６４０）。すべてのページに対し上書き処理を完了すると、コアコントローラ２４０は、受信した世代番号を、上記該当エントリ（ＬＵマッピング管理テーブル３６０内のエントリ）のコピー元世代番号５６４に上書きする（ステップ６５０）
　図１１は、コアコントローラ２４０が分析用ホスト２３０よりＬＵに対するリード要求を受信したときに開始されるコアリード処理のフロー図である。
　コアコントローラ２４０は、リード要求で指定されたリード対象のＬＵ及びページに対応するコピー状態管理テーブル３７０におけるエントリを参照する（ステップ７１０）。参照したエントリにおいて、未コピーフラグ５７３若しくは更新フラグ５７２の少なくとも片方が“ON”の場合、当該ＬＵのリード対象データは、エッジコントローラ２９０から取得する必要がある。この場合、コアコントローラ２４０は、ＬＵマッピング管理テーブル３６０を参照して、リード対象のＬＵに対応するコピー元ストレージ５６２、コピー元ＬＵ５６３及びコピー元世代番号５６４を特定し、コピー元エッジコントローラ２９０に、当該ＬＵ及びスナップショットに対するデータの取得要求を送信する（ステップ７２０）。そして、コアコントローラ２４０は、その取得要求に応答してコピー元エッジコントローラ２９０から取得したデータを、リード対象のＬＵにライトする。この動作により、リード対象ＬＵとそれのコピー元ＬＵの当該ページの内容は一致するため、コアコントローラ２４０は、コピー状態管理テーブル３７０における更新フラグ５７２及び未コピーフラグ５７３を共に“OFF”とする。その後、コアコントローラ２４０は、リード対象のＬＵ内のデータ（エッジコントローラ２９０から取得され格納されたデータ）をリードし、リード要求元の分析用ホスト２３０に返す（ステップ７３０）。
　本実施例により、分析用ホスト２３０がエッジストレージ１５０内のデータに透過的にアクセスできるようになる。このため、エッジストレージ１５０が格納するデータのコピー完了をまたず、コアコントローラ２４０から、エッジストレージ１５０が格納するデータへアクセスが可能となる。また、参照の際、対象のデータが格納されたページのみ広域ネットワーク２５０を通じて転送され、参照しないデータは転送されない。これにより、広域ネットワーク２５０の転送量を抑え転送時間を短縮するとともに、コアコントローラ２４０がエッジコントローラ２９０からコピーする（取得する）データの量（コアコントローラ２４０の複製量）を削減することができる。更に、エッジコントローラ２９０からコアコントローラ２４０へコピーしたデータをコアストレージ１２０内のＬＵに保存することで、その後のアクセスでは、エッジコントローラ２９０からのデータコピーが不要となり、アクセス性能の低下を抑えることができる。
　本実施例では、エッジコントローラ２９０からコアコントローラ２４０へのデータのコピーは、分析用ホスト２３０からリード要求を受け当該リード要求で指定されたページがデータ取得対象のページである場合に行われるが、この契機に加えて、リード要求の受信とは非同期的に行われてもよい。この場合、分析用ホスト２３０が初めてリード元とするページに対し非同期コピーが完了している場合、そのページに既に最新データが格納されているため、広域ネットワーク２５０を介したデータの取得が不要でリード応答時間を高速化できることが期待できる。
　また、本実施例では、コアコントローラ２４０がＬＵマッピング管理テーブル３６０とコピー状態管理テーブル３７０を格納していれば、分析用ホスト２３０は、コアコントローラ２４０を介してエッジストレージ１５０が格納するデータを参照可能である。実際にエッジストレージ１５０が保持する全データがコアコントローラ２４０にコピーされるのを待つ必要がないため、コアストレージ１２０を新規にエッジストレージ１５０と接続した場合や、エッジストレージ１５０に大量のデータが生成された場合でも、即座に分析用ホスト２３０がエッジストレージ１５０のデータを参照することが期待できる。
　実施例２を説明する。以下、実施例１との相違点を主に説明し、実施例１との共通点については説明を簡略又は省略する。
　エッジストレージ及びコアストレージのうちの少なくとも１つとしては、実施例１で示したＬＵＮとアドレス（例えばＬＢＡ（Logical Block Address））を指定したアクセス要求を受信し当該要求に従うデータにアクセスする装置に代えて、ファイルやオブジェクトといったデータセット単位でアクセスする装置が採用されてよい。特に、各拠点にファイルストレージを配置し、このファイルストレージに格納されたデータを、クラウドストレージなどのオブジェクト単位でのデータアクセスを提供するストレージシステムへデータをコピーする形態がとられることがある。実施例２では、そのような形態が採用されている。なお、「データセット」とは、アプリケーションプログラムのようなプログラムから見た１つの論理的な電子データの塊であり、例えば、レコード、ファイル、オブジェクト、キーバリューペア及びタプルのうちのいずれでもよい。また、実施例２において、ファイル、ディレクトリ及びオブジェクトのようなデータセットは、ボリューム内の要素の一例である。
　図１２は、実施例２における計算機システム８００の構成図である。
　中央データセンタ８１０（第２の拠点の一例）内は、広域ネットワーク８５０と接続された内部ネットワーク８２０を介し、オブジェクトストレージ８０２（第２のストレージ装置の一例）及び１乃至複数の分析用ホスト８３０（第２のホストの一例）が接続されている。また、ファイルゲートウェイ８３１が接続されていてもよい。オブジェクトストレージ８４０は、分析用ホスト８３０が参照するデータをオブジェクト単位で格納及び提供する装置である。オブジェクトストレージ８０２が、１以上の記憶媒体８４８とその１以上の記憶媒体８４８に対する入出力を制御するコントローラ（以下、オブジェクトコントローラ）８４０とを有する。分析用ホスト８３０は、オブジェクトストレージ８０２が格納するデータ、及びオブジェクトコントローラ８４０が透過的にアクセス可能としている分散拠点８６０のファイルストレージ８０１中のデータにアクセスし、加工又は分析を行う計算機である。なお、分析用ホスト８３０がオブジェクト単位でのデータアクセス機能を有しない場合、別途ファイル単位でのデータアクセスとオブジェクト単位でのデータアクセスを変換するファイルゲートウェイ８３１を用いて間接的にオブジェクトストレージ８４０が格納するデータにアクセスしてもよい。以後、分析用ホスト８３０がオブジェクトストレージ８４０内のデータにアクセスするとは、ファイルゲートウェイ８３１を介した間接的なアクセスする場合も含める。ファイルストレージ８０１からディレクトリ階層構造がオブジェクトストレージ８０２に格納されると、オブジェクトストレージ８０２において階層構造は維持されないが、ファイルゲートウェイ８３１は、その階層構造を表す情報を保持する。つまり、ファイルゲートウェイ８３１は、オブジェクトストレージ８０２内のオブジェクトの階層構造を管理する。ファイルゲートウェイ８３１は、例えば、パス名（ファイル名）を指定した要求（問合せ）に応答して、そのパス名に対応するオブジェクトＩＤを返すことができる。
　オブジェクトコントローラ８４０は、各分散拠点８６０（第１の拠点の一例）にあるファイルストレージ８９０（第１のストレージ装置の一例）が格納するデータを分析用ホスト８３０に透過的にアクセス可能とする機能を備える。オブジェクトコントローラ８４０（第２のコントローラの一例）は、ＣＰＵ８４１、メモリ８４２、ネットワークインタフェース８４３及びストレージインタフェース８４４を備え、それらは互いに内部で接続されている。ＣＰＵ８４１は、メモリ８４２に格納されたプログラムの記載に従い、オブジェクトコントローラ８４０の構成要素を制御する。メモリ８４２は、複数のプログラムやテーブルを格納し、ディスクキャッシュを有する。オブジェクトコントローラ８４０は、ネットワークインタフェース８４３を介し内部ネットワーク８２０を通じて分析用ホスト８３０によるアクセス要求を処理したり、広域ネットワーク８５０を通じてファイルストレージ８９０と通信したりする。また、オブジェクトコントローラ８４０は、ストレージインタフェース８４４を介し記憶媒体８４５に対するデータの読み書きを行い、記憶媒体８４５内にオブジェクトデータ８４６、オブジェクト管理テーブル８４７、スタブデータ８４８、を格納する。これらのデータは記憶媒体８４５の領域をそのままパーティションやＬＶＭ（Logical Volume Management）等の機能で区切って格納してもよいし、記憶媒体８４５上にファイルシステムを構築し、それぞれファイル単位で格納してもよい。ネットワークインタフェース８４３を介した通信プロトコルには、ＨＴＴＰ（Hypertext Transfer Protocol）を利用したＲＥＳＴ（Representational State Transfer）プロトコルや、ネットワークインタフェース２４３及びストレージインタフェース２４４のプロトコルを利用できる。また。ストレージインタフェース８４４と記憶媒体８４５間の通信プロトコルは、ストレージインタフェース２４４のプロトコルを利用できる。
　ファイルストレージ８０１が、１以上の記憶媒体８９５とその１以上の記憶媒体８９５に対する入出力を制御するコントローラ（以下、ファイルコントローラ）８９０とを有する。ファイルコントローラ８９０（第１のコントローラの一例）は、ＣＰＵ８９１、メモリ８９２、ネットワークインタフェース８９３及びストレージインタフェース８９４を備え、それらは互いに内部で接続されている。ＣＰＵ８９１は、メモリ８９２に格納されたプログラムの記載に従い、ファイルコントローラ８９０の構成要素を制御する。メモリ８９２は、複数のプログラムやテーブルを格納し、ページキャッシュを有する。ファイルコントローラ８９０は、ネットワークインタフェース８９３を介し内部ネットワーク８７０を通じてホスト８８０によるアクセス要求を受け付けたり、広域ネットワーク８５０を通じて中央データセンタ８１０内のオブジェクトストレージ８４０と通信したりする。また、ファイルコントローラ８９０は、ストレージインタフェース８９４を介し記憶媒体８９５に対するデータの読み書きを行い、記憶媒体８９５上にファイルシステム８９６を構築する。ファイルコントローラ８９０の各通信プロトコルには、ＮＦＳ（Network File System）やＳＭＢ（Server Message Block）をはじめ、オブジェクトストレージ８４０同等のものを利用可能である。また、ストレージインタフェース８９４と記憶媒体８９５間の通信プロトコルは、ストレージインタフェース２４４のプロトコルを利用できる。
　ファイルシステム８９６が、第１のボリュームの一例である。オブジェクトデータ８４６やスタブデータ８４８が格納される領域が、第２のボリュームの一例である。
　なお、各分散拠点８６０内のストレージ装置は、ファイルストレージに代えてオブジェクトストレージであってもよい。中央データセンタ８１０内のストレージ装置は、オブジェクトストレージに代えてファイルストレージでもよい。また、分散拠点８６０及び中央データセンタ８１０の一方がファイル又はディレクトリであり他方がオブジェクトであることは、散拠点８６０が格納するデータセットの種類と中央データセンタ８１０が格納するデータセットの種類とが異なっていることの一例である。データセットの種類が異なっていると、データセットのＩＤの構成が異なり、そのため、データセットのＩＤの対応関係を、例えば図１４に示すようなテーブルを用いて管理する必要がある（後述するように、図１５に示すようなテーブルが更にあると好ましい）。
　図１３は、ファイルコントローラ８９０中のメモリ８９２に格納されている各種プログラム及びテーブルを示す図である。
　メモリ８９２は、ファイルシステムプログラム９１１、データ転送プログラム９１２、第１検索テーブル９１３、第２検索テーブル９１４及びオブジェクトストレージ情報９１５を格納する。メモリ８９２は、ページキャッシュ９１６を有する。ページキャッシュ９１６は、メモリ８９２のうちの余剰領域（各種プログラム及びテーブルを格納した領域以外の領域の少なくとも一部）でよい。
　ファイルシステムプログラム９１１は、記憶媒体８９６上にファイルシステムを構築し、ディレクトリやファイル単位でのデータアクセスやデータ格納を実現するプログラムである。また、ファイルシステムプログラム９１１は、内部ネットワーク８７０を介したファイルアクセス要求（ホスト８８０によるディレクトリ又はファイルへのアクセス要求）への応答も行う。ネットワークを介したファイルアクセス要求のプロトコルには、先に述べたとおり、ＮＦＳ（Network File System）、ＳＭＢ（Server Message Block）、ＡＦＰ（Apple Filing Protocol）等が利用できる。
　データ転送プログラム９１２は、中央データセンタ８１０にあるオブジェクトストレージ８４０とのデータ送受信を行うプログラムである。
　図１４は、第１検索テーブル９１３の構成図である。
　第１検索テーブル９１３は、ファイルシステム上のディレクトリ又はファイルとオブジェクトストレージ８４０内のオブジェクトとの対応関係を示すテーブルであって、ファイルパス名からオブジェクトＩＤを検索するためのテーブルである。第１検索テーブル９１３は、ディレクトリ又はファイル毎にエントリを有する。各エントリは、パス名９２１、タイプ９２２及びオブジェクトＩＤ９２３といった情報を格納する。以下、１つのデータセット（ディレクトリ又はファイル）を例に取る（図１４の説明で「対象データセット」と言う）。
　パス名９２１は、対象データセットへのパス名を示す。パス名９２１は、対象データセットのＩＤの一例でよい。タイプ９２２は、対象データセットのタイプ（“／”（ルートディレクトリ）、“ディレクトリ”又は“ファイル”）を示す。オブジェクトＩＤ９２３は、対象データセットに対応したオブジェクトを一意に特定するＩＤである。
　第１検索テーブル９１４を利用することにより、ファイル又はディレクトリに対応したオブジェクトＩＤを含んだ更新通知を送信することが可能である。第１検索テーブル９１３は、パス名９２１に関しハッシュ値等のインデックスを保持することで、パス名９２１からエントリを高速に検索可能な形で管理される。
　図１５は、第２検索テーブル９１４の構成図である。
　第２検索テーブル９１４は、オブジェクトとディレクトリ又はファイルとの対応関係を示すテーブルであって、オブジェクトＩＤからパス名を検索するためのテーブルである。第２検索テーブル９１４は、オブジェクト毎にエントリを有する。各エントリは、オブジェクトＩＤ９３１及びパス名９３２といった情報を格納する。以下、１つのオブジェクトを例に取る（図１５の説明で「対象オブジェクト」と言う）。
　オブジェクトＩＤ９３１は、対象オブジェクトのＩＤである。パス名９３２は、対象オブジェクトに対応したデータセットへのパス名を示す、
　第２検索テーブル９１４を利用することにより、オブジェクトＩＤを指定した取得要求に応答して当該オブジェクトＩＤに対応したファイル又はディレクトリを高速に特定することが可能である。オブジェクトＩＤ９３１に関しハッシュ値等のインデックスを保持することで、オブジェクトＩＤ９３１からエントリを高速に検索可能な形で管理される。
　第１検索テーブル９１３と第２検索テーブル９１４は同内容を含むテーブルであるため、パス名とオブジェクトＩＤの両方で高速にエントリを検索可能であるならば、１つのテーブルで兼用してもよい。
　図１６は、オブジェクトコントローラ８４０中のメモリ８４２に格納されている各種プログラム及びテーブルを示す図である。
　メモリ８４２は、オブジェクト制御プログラム１０１１、オブジェクト管理テーブル１０１２及びスタブデータテーブル１０１３を格納する。メモリ８４２は、ディスクキャッシュ１０１４を有する。ディスクキャッシュ１０１４は、メモリ８４２のうちの余剰領域（各種プログラム及びテーブルを格納した領域以外の領域の少なくとも一部）でよい。
　オブジェクト制御プログラム１０１１は、オブジェクト単位でのデータ入出力を行い、且つ、分析用ホスト８３０からのアクセス要求に応答するプログラムである。オブジェクトストレージ８４０は、オブジェクトを全て一律に管理するのではなく、複数のバケットと呼ぶ単位で分類することもできる。その場合、分析用ホスト８３０はバケットＩＤとオブジェクトＩＤの対でアクセス対象を特定する。
　図１７は、オブジェクト管理テーブル１０１２の構成図である。
　オブジェクト管理テーブル１０１２は、オブジェクト制御プログラム１０１１が管理するオブジェクトの情報を示すテーブルである。オブジェクト管理テーブル１０１２は、オブジェクト毎にエントリを有する。各エントリが、オブジェクトＩＤ１０２１、更新フラグ１０２２、スタブフラグ（未コピーフラグと同等）１０２３、サイズ１０２４及び保存先１０２５といった情報を格納する。以下、１つのオブジェクトを例に取る（図１７の説明で「対象オブジェクト」と言う）。オブジェクトがその他の属性（例えば、オブジェクトの作成日時、所有者、アクセス権等の属性）を持つ場合、オブジェクト管理テーブル１０１２は、対応する列を有してもよい。
　オブジェクトＩＤ１０２１は、対象オブジェクトのＩＤである。
　更新フラグ１０２２は、ファイルストレージ８０１からオブジェクトストレージ８０２への対象オブジェクトの前回データコピー以降、ファイルコントローラ８９０からオブジェクトコントローラ８４０へ対象オブジェクトのＩＤを含んだ更新通知が送信されたか否かを示す。
　スタブフラグ１０２３は、ＬＵ（オブジェクト格納空間）を作成して以降、ファイルストレージ８０１からオブジェクトストレージ８０２に対象オブジェクトが未コピーであるか否か（対象オブジェクトに代えてそのスタブが存在するか否か）を示す。
　保存先１０２５は、対象オブジェクトのデータの格納位置（記憶媒体８４５における位置）を示す。保存先１０２５としては、ファイルシステムのパス名やＬＵ上のＬＢＡ等が格納される。
　オブジェクト管理テーブル１０１２はバケット毎に存在してもよいし、１つのオブジェクト管理テーブル１０１２上にバケットＩＤの列を加え、バケットＩＤとオブジェクトＩＤの対でオブジェクト管理テーブル１０１２上のエントリ（行）を特定可能としてもよい。
　図１８は、スタブデータテーブル１０３１の構成図である。
　スタブデータテーブル１０３１は、オブジェクト毎にエントリを有する。各エントリが、バケットＩＤ１０３１、オブジェクトＩＤ１０３２及びデータ取得先１０３３といった情報を格納する。以下、１つのオブジェクトを例に取る（図１８の説明で「対象オブジェクト」と言う）。
　バケットＩＤ１０３１は、対象オブジェクトを格納するバケットのＩＤである。オブジェクトＩＤ１０３２は、対象オブジェクトのＩＤである。データ取得先１０３３は、対象オブジェクトに対応したデータセットが格納されている位置（ファイルストレージ８０１上の位置）を示す。データ取得先１０３３は、例えば、ファイルストレージ８０１の識別子と、ファイルストレージ８０１上のファイル共有名との組合せ等で表現される。
　スタブデータテーブル１０３１は、オブジェクトとデータ取得先との対応関係を示すものであれば、図に示す以外の形式でもよい。例えばバケット内の全オブジェクトが同一のデータ取得先に対応付けられるのであれば、オブジェクトＩＤ１０３２の列は不要である。スタブデータテーブル１０１３により、分析用ホスト８３０のアクセス時に、テータ取得先１０３３が示すファイルストレージ８９０より、透過的にデータを取得可能とする。
　図１９は、スタブ作成処理のフロー図である。
　スタブ作成処理は、ファイルストレージ８０１が自身の保持するファイル又はディレクトリに対応するスタブデータをオブジェクトストレージ８０２に登録する際に実行される処理である。例えば、ファイルストレージ８０１に新規ファイルが追加された場合にスタブ作成処理が実行されたり、一定期間毎（例えば１日毎）に当該期間（例えば１日）の間に作成されたファイル群（１以上のファイル）について一括してスタブ作成処理が実行されたりしてもよい。以下、スタブ作成処理は１つのデータセット（ファイル又はディレクトリ）を対象とするが（図１９において「対象データセット」）、ファイルコントローラ８９０はスタブ作成処理を複数並列又は直列に実行することで複数のファイル又はディレクトリに対するスタブ作成を完了することもできる。
　ファイルコントローラ８９０は、対象データセットについて、オブジェクトコントローラ８４０で格納される際のオブジェクトＩＤを確定する（ステップ１１１０）。オブジェクトＩＤは一意性が保持されるのであればファイルコントローラ８９０が生成してもよいし、オブジェクトコントローラ８４０が生成してもよい。ファイルコントローラ８９０は、確定したオブジェクトＩＤを取得すると、第１検索テーブル９１３に、対象データセットに対応するパス名９２１、タイプ９２３及びオブジェクトＩＤ９２４を格納したエントリを追加する（ステップ１１２０）。同様に、ファイルコントローラ８９０は、第２検索テーブル９１４に、対象データセットに対応するパス名９３１及びオブジェクトＩＤ９３２を格納したエントリを追加する（ステップ１１３０）。続けて、ファイルコントローラ８９０は、確定したオブジェクトＩＤとオブジェクトの属性（サイズなど）とを関連付けたスタブ作成要求（オブジェクトのスタブを作成することの要求）を、オブジェクトコントローラ８４０に送信する（ステップ１１４０）。
　オブジェクトコントローラ８４０は、ファイルコントローラ８９０によるスタブ作成要求を受信すると、当該スタブ作成要求に応答して、対応するスタブデータテーブル１０３１のエントリを作成する（ステップ１１５０）。ステップ１１５０で作成されたエントリにおいて、スタブ作成要求に関連付けられているオブジェクトＩＤ１０２１が格納される。
　続けて、オブジェクトコントローラ８４０は、オブジェクト管理テーブル１０１２のエントリを作成する（ステップ１１６０）。ステップ１１６０で作成されたエントリには、ファイルコントローラ８９０によるスタブ作成要求に関連付けられているオブジェクトＩＤ１０２１及びサイズ１０２４が格納される。また、ステップ１１６０で作成されたエントリにおいて、更新フラグ１０２２は“OFF”とされ、スタブフラグ１０２３は“ON”とされる。
　このようにして、オブジェクトコントローラ８４０は、ファイルコントローラ８９０からのスタブ作成要求に応答として、当該スタブ作成要求で指定されているオブジェクトのスタブであって分析用ホスト８３０から認識されるスタブを作成する。
　図２０は、分析用ホスト８３０又はファイルゲートウェイ８３１からオブジェクトコントローラ８４０がオブジェクトの取得要求を受けた場合に行われるオブジェクトリード処理のフロー図である。
　オブジェクトストレージ８４０は、オブジェクトの取得要求を受信すると、当該取得要求に含まれるオブジェクトＩＤを用いてオブジェクト管理テーブル１０１２を参照し、対象オブジェクト（当該取得要求に含まれるオブジェクトＩＤから特定されるオブジェクト）の更新フラグ１０２２及びスタブフラグ１０２３の少なくとも１つが“ON”か否かを判断する（ステップ１２１０）。例えば、更新フラグ１０２２が“ON”は、ファルストレージ８０１上で対象オブジェクトに対応したファイル又はディレクトリの更新が行われたために、ファイルコントローラ８９０から更新通知を受けたことを意味する。この通知の方法は、ファイルコントローラ８９０からオブジェクトコントローラ８４０に対し、更新したオブジェクトＩＤの一覧を送信する方法が考えられる。この送信を受け、オブジェクトコントローラ８４０は、リストに含まれる各オブジェクトＩＤについて、オブジェクト管理テーブル１０１２中の当該オブジェクトＩＤに対応する更新フラグを“ON”にする。また、スタブフラグ１０２３が“ON”は、オブジェクトデータ８４６に対応するファイル又はディレクトリのデータを保持していないことを意味する。よって、更新フラグ１０２２及びスタブフラグ１０２３の少なくとも１つが“ON”の場合、当該オブジェクトのデータをファルストレージ８０１から取得する必要があることを意味する。その場合、オブジェクトコントローラ８４０は、データコピー処理（図２１）を開始し、オブジェクトデータ８４６がファイルシステム８９６におけるファイル又はディレクトリのデータと一致した状態とするようにする（ステップ１２２０）。その後、オブジェクトコントローラ８４０は、対象オブジェクトのデータ８４６をリードし、リードしたデータを、オブジェクトの取得要求の送信元に返す（ステップ１２３０）。
　図２１は、データコピー処理のフロー図である。データコピー処理は、オブジェクトリード処理中に実行されてもよいし、オブジェクトコントローラ８４０が他の処理を行っている際にバックグラウンドで行われてもよい。
　オブジェクトコントローラ８４０は、スタブデータテーブル１０１３を参照し、対象オブジェクト（処理対象のオブジェクト）のオブジェクトＩＤと対象オブジェクトが格納されているバケットのバケットＩＤとを用いて、対応するデータ取得先１０３３を特定する（ステップ１３０５）。オブジェクトコントローラ８４０は、ステップ１３０５で取得したデータ取得先１０３３のファイルコントローラ８９０に対し、オブジェクトＩＤを引数として関連付けた取得要求を送信する（ステップ１３１０）。
　当該取得要求を受信したファイルコントローラ８９０は、引数のオブジェクトＩＤを基に、第２検索テーブル９１４を用いて、対象オブジェクトに対応するファイル又はディレクトリのパス名９３２を特定し（ステップ１３１５）、特定したパス名９３２に従うファイル又はディレクトリのデータをファイルシステム８９６から読み込む（ステップ１３２０）。パス名９３２が示す先がディレクトリである場合、ファイルコントローラ８９０は、ディレクトリ内に格納されたすべての子データセット（各ファイル及びサブディレクトリ）に対し、スタブ作成処理を行う（ステップ１３２５、１３３０）。つまり、当該ディレクトリ内の全てのデータセットの各々のスタブがファイルシステム上に作成される。結果として、オブジェクトストレージ８０２が持つオブジェクトを用いて、ファイルストレージ８０１においてネームスペース（階層構造）を復元することができる。
　その後、ファイルコントローラ８９０は、パス名に対応するファイル又はディレクトリのデータ（ディレクトリの場合、“データ”とは、ディレクトリ内に格納されたファイル及びサブディレクトリの情報として、ファイル名及びサブディレクトリ名（パス名）と対応するオブジェクトＩＤとの対のリストを意味する）をオブジェクトストレージ８４０に返す（ステップ１３３５）。
　オブジェクトコントローラ８４０は、ファイルコントローラ８９０からの応答を受信すると、受信したデータをオブジェクトデータ８４６として書き込む（ステップ１３４０）。続けて、オブジェクトコントローラ８４０は、オブジェクト管理テーブル１０１２の更新フラグ１０２２とスタブフラグ１０２３を“OFF”にする（ステップ１３４５）。
　本実施例により、分析用ホスト８３０が分散拠点のファイルストレージ８０１が格納するデータに透過的にアクセスできるようになる。これにより、ファイルストレージ８０１からオブジェクトストレージ８０２へのデータコピーの完了をまたず、分析用ホスト８３０からファイルストレージ８０１のデータを参照可能となる。また、参照の際、対象のデータが格納されたオブジェクトのみ分散拠点８６０と中央データセンタ８１０間で広域ネットワーク８５０を通じて転送され、参照しないオブジェクトは転送されない。これにより、広域ネットワーク８５０の転送量を抑え転送時間を短縮するとともに、オブジェクトストレージ８０２がファイルストレージ８０１からコピーするデータの量（オブジェクトストレージ８０２の複製量）を削減することができる。
　また、本実施例では、オブジェクトコントローラ８４０が、ディレクトリに対応するオブジェクトのリード要求を受けると、ディレクトリ内のファイル及びサブディレクトリのスタブデータを構築する。よって、オブジェクトコントローラ８４０は、ルートディレクトリに対応するスタブデータのみ格納した状態であれば、分析用ホスト８３０やファイルゲートウェイ８３１からのデータ取得要求に対し、パスの構成要素を再帰的にスタブ化及びデータコピー処理を行える。そのため、オブジェクトストレージ８０２を新規にファイルストレージ８０１と接続した場合や、ファイルストレージ８０１に大量のファイル（及びディレクトリ）が生成された場合でも、ファイルストレージ８０１のデータをオブジェクトストレージ８０２にコピーするのを待つことなく即座に分析用ホスト８３０やファイルゲートウェイ８３１がファイルストレージ８０１のファイル又はディレクトリを参照することが期待できる。
　実施例３を説明する。以下、実施例１との相違点を主に説明し、実施例１との共通点については説明を簡略又は省略する。
　計算機システムにおいては、旧ストレージ装置から、新規購入したストレージ装置へデータを移行することがある。本実施例では、ＬＵＮとアドレス（例えばＬＢＡ）を指定したアクセス要求を処理するストレージシステムが、このようなデータ移行の際中であっても、実施例１と同様の効果を実現する。
　図２２は、実施例３における計算機システム１４００の構成図である。
　計算機システム１４００は、中央データセンタ２１０と１乃至複数の分散拠点１４６０で構成される。中央データセンタ２１０及び分散拠点１４６０は広域ネットワーク２５０により互いに接続される。中央データセンタ２１０は実施例１と同等の構成を取る。分散拠点１４６０は実施例１における分散拠点２６０とほぼ同等の構成を取るが、エッジコントローラとして、移行元エッジコントローラ（移行元エッジストレージ１４０１のエッジコントローラ）１４１０及び移行先エッジコントローラ（移行先エッジストレージ１４０２のエッジコントローラ）１４２０とがある。移行元エッジストレージ１４０１の一例が、旧ストレージ装置である。移行先エッジストレージ１４０２の一例が、新ストレージ装置である。
　移行元エッジコントローラ１４１０及び移行先エッジコントローラ１４２０は、互いに内部ネットワーク２７０を介し通信可能である。移行元エッジストレージ１４０１が格納しているデータやＬＵ構成を移行先エッジストレージ１４０２に移行中であるものとする。コントローラ１４１０及び１４２０間のデータ移行については、特許文献３に示す方式が適用可能である。特許文献３に示す方式によるデータ移行を用いると、移行元エッジコントローラ１４１０から移行先エッジコントローラ１４２０へのデータ移行が未完の状態においても、ホスト２８０が移行先エッジストレージ１４０２を介して移行元エッジストレージ１４０１のデータを透過的に参照できる。
　図１１のコアリード処理のステップ７２０の処理を、移行元エッジコントローラ１４１０から移行先エッジコントローラ１４２０へのデータ移行に適用することができる。コアコントローラ２４０が保持するＬＵマッピング管理テーブル５６２におけるコピー元ストレージ５３２及びコピー元ＬＵＮ５６３は、移行先エッジコントローラ１４２０上のＬＵを参照するように設定しておく。その場合、コアコントローラ２４０のデータ取得要求は、移行先エッジコントローラ１４２０に送信される。移行先エッジコントローラ１４２０は、ホスト２８０に、移行元エッジストレージ１４０１のデータを透過的に参照する機能を備えている。同様に、移行先エッジコントローラ１４２０は、コアコントローラ２４０からのデータ取得要求に対し、移行元エッジストレージ１４０１のデータを透過的に参照する機能を適用することで、移行元エッジストレージ１４０１にあるデータを取得することができる。
　本実施例によれば、分散拠点１４６０においてエッジストレージ１４０１及び１４０２間のデータ移行を実施している最中であっても、中央データセンタ２１０内の分析用ホスト２３０は、移行元エッジストレージ１４０１及び移行先エッジストレージ１４０２間のデータの所在を問わず、コアコントローラ２４０を介し分散拠点１４６０内のデータを参照することができる。
　なお、本実施例において、移行元エッジストレージ１４０１は、分散拠点１４６０の外に存在していてもよい。移行元エッジストレージ１４０１は、第３のストレージ装置の一例である。移行元エッジストレージ１４０１から移行先エッジストレージ１４０２にデータを移行している最中において、移行先エッジストレージ１４０２が、取得要求をコアストレージ１２０から受信した場合、当該取得要求に従う取得対象の最新データが移行先エッジストレージ１４０２に移行済みか否かを判断する。当該判断の結果が真の場合、移行先エッジストレージ１４０２が、当該最新データをコアストレージ１２０に返す。当該判断の結果が偽の場合、移行先エッジストレージ１４０２が、当該最新データを移行元エッジストレージ１４０１から取得してコアストレージ１２０に返す。
　実施例４を説明する。以下、実施例２との相違点を主に説明し、実施例２との共通点については説明を簡略又は省略する。
　本実施例は、分析拠点においてファイルストレージ間でデータ移行の際中である場合の実施例である。
　図２３は、実施例４における計算機システム１５００の構成図である。
　計算機システム１５００は、中央データセンタ８１０と１乃至複数の分散拠点１５６０で構成される。中央データセンタ８１０及び分散拠点１５６０は広域ネットワーク８５０により互いに接続される。中央データセンタ８１０は実施例２と同等の構成を取る。分散拠点１５６０は実施例２における分散拠点８６０とほぼ同等の構成を取るが、ファイルストレージとして、移行元ファイルストレージ１５０１及び移行先ファイルストレージ１５０２とが存在する。移行元ファイルストレージ１５０１は、コントローラ（以下、移行元ファイルコントローラ）１５１０を含む。移行先ファイルストレージ１５０２は、コントローラ（以下、移行先ファイルコントローラ）１５２０を含む。
　移行元ファイルコントローラ１５１０及び移行先ファイルコントローラ１５２０は、互いに内部ネットワーク８７０を介し通信可能である。移行元ファイルコントローラ１５１０からファイルやディレクトリを移行先ファイルコントローラ１５２０に移行中であるとする。ファイルコントローラ１５１０及び１５２０間のデータ移行については、特許文献４に示す方式が適用可能である。特許文献４に示す方式によるデータ移行を用いると、移行元ファイルコントローラ１５１０から移行先ファイルコントローラ１５２０へのデータ移行が未完の状態においても、ホスト８８０が移行先ファイルストレージ１５０２を介して移行元ファイルストレージ１５０１のデータを透過的に参照できる。
　移行先ファイルコントローラ１５２０は、実施例２におけるテーブルに加え、図２４に示す移行用スタブデータテーブル１６００及び図２５に示すデータ要求元管理テーブル１６５０をメモリ中に格納する
　図２４は、移行用スタブデータテーブル１６００の構成図である。
　移行用スタブデータテーブル１６００は、移行元ファイルストレージ１５０１上のファイル又はディレクトリと移行先ファイルストレージ１５０２上のファイル又はディレクトリとの対応関係を示す。移行用スタブデータテーブル１６００は、移行先ファイルストレージ１５０２上のデータセット（ファイル、ディレクトリ若しくはスタブ）毎にエントリを有する。各エントリは、ファイルパス１６０１、データ移行元１６０２、ファイルパス１６０３及びスタブフラグ１６０４といった情報を格納する。以下、１つのデータセットを例に取る（図２４の説明で「対象データセット」と言う）。
　ファイルパス１６０１は、対象データセットのパス名を示す。データ移行元１６０２は、対象データセットの移行元データセットを格納する移行元ファイルストレージ１５０１を一意に識別する識別子を示す。ファイルパス１６０３は、対象データセットの移行元データセットのパス名（移行元ファイルストレージ１５０１上におけるファイルパス）を示す。スタブフラグ１６０４は、対象データセットの複製データを移行先ファイルストレージ１５０２自身のファイルシステムに格納しているか否かを示す。なお、スタブフラグ１６０４は、第１検索テーブル９１３に含まれてもよい。
　図２５は、データ要求元管理テーブル１６５０の構成図である。
　データ要求元管理テーブル１６５０は、ホスト８８０又はオブジェクトストレージ８４０が移行先ファイルストレージ１５０２にファイルアクセス要求を送信する際、移行先ファイルストレージ１５０２が応答を返すまで一時的にメモリ上に格納するテーブルである。データ要求元管理テーブル１６５０は、ファイルアクセス要求毎にエントリを有する。各エントリは、要求先ファイルのパス名１６５１と、ファイルアクセス要求の送信元の識別子を示す要求元１６５２といった情報を格納する。識別子として、例えばＩＰアドレス、ＷＷＮ、ホスト名等が利用できる。
　図２６は、移行先リード処理のフロー図である。
　移行先リード処理は、ホスト８８０又はオブジェクトストレージ８４０から移行先ファイルコントローラ１５２０がファイルリード要求を受信した場合に移行先ファイルコントローラ１５２０により実行される。または、移行先リード処理は、データコピー処理においてステップ１３２０として実行される。
　移行先ファイルコントローラ１５２０は、ファイルリード要求を受信すると、移行用スタブデータテーブル１６００から、当該リード要求に対応したファイルパス１６０１に対応するスタブフラグ１６０４を参照する（ステップ１７０５）。
　参照したスタブフラグ１６０４が“OFF”の場合、移行先ファイルコントローラ１５２０は、移行先ファイルストレージ１５０２のファイルシステム上に移行元ファイルストレージ１５０１と同じデータが格納されているため、移行先ファイルストレージ１５０２のファイルシステム上のデータを要求元に返す（ステップ１７４５）。
　参照したスタブフラグが“ON”の場合、移行先ファイルコントローラ１５２０は、移行先ファイルストレージ１５０２のファイルシステム上に移行元ファイルストレージ１５１０と同じデータが格納されていないため、移行元ファイルストレージ１５１０にデータ取得要求を送信する。そのため、移行先ファイルコントローラ１５２０は、移行用スタブデータテーブル１６００中のデータ移行元１６０２及び移行元ファイルパス１６０３を参照し、リード対象ファイル（ファイルリード要求で指定されたファイル）に対応する移行元ファイルストレージ１５１０及び移行元ファイルストレージ１５１０中のファイルを特定する（ステップ１７１０）。続けて、移行先ファイルコントローラ１５２０は、リード対象ファイルに対応した要求先ファイル１６５１及びファイル要求元１６５２をデータ要求元管理テーブル１６５０に登録する（ステップ１７１５）。そして、移行先ファイルコントローラ１５２０は、移行元ファイルストレージ１５１０から、リード対象ファイルに対応したファイル（若しくはディレクトリ）のデータを取得する（ステップ１７２０）。続けて、移行先ファイルコントローラ１５２０は、ステップ１７１５で登録したデータ要求元管理テーブル１６５０の要求元１６５２を参照し、要求元が分散拠点１５６０外部にあるオブジェクトストレージ８０２か否かを判断する（ステップ１７２５）。
　要求元がオブジェクトストレージ８０２である場合、移行先ファイルコントローラ１５２０は、ステップ１７２０で取得した移行元ファイルストレージ１５０１のデータをそのまま（移行先ファイルストレージ１５０２のファイルシステムに格納すること無しに）要求元に返す（ステップ１７３０）。
　要求元がオブジェクトストレージ８０２ではない場合、移行先ファイルコントローラ１５２０は、ステップ１７２０で取得した移行元ファイルストレージ１５０１のデータを一旦移行先ファイルストレージ１５０２のファイルストレージに書き込み（ステップ１７３５）、移行用スタブデータテーブル１６００上のスタブフラグ１６０４を“OFF”にする（ステップ１７４０）。その上で、移行先ファイルコントローラ１５２０は、ファイルシステムに書き込んだデータを要求元に返す（ステップ１７４５）。ステップ１７４５では、移行先ファイルコントローラ１５２０は、ステップ１７３０同様、ステップ１７２０で取得した移行元ファイルストレージ１５０１のデータをそのまま返してもよい。その場合、ファイルシステムへのアクセス回数を削減することができる。
　本実施例によれば、分散拠点１５６０においてファイルストレージ１５０１及び１５０２間のデータ移行を実施している最中であっても、分析用ホスト８３０は、移行元ファイルストレージ１５０２及び移行元ファイルストレージ１５０１間のデータの所在を問わず、オブジェクトストレージ８０２を介し分散拠点１５６０内のデータを参照することができる。さらに、移行先ファイルコントローラ１５２０は、ファイルの要求元が分散拠点１５６０内かオブジェクトストレージ８０２かを認識して、移行元ファイルストレージ１５１０から取得したデータを自身のファイルシステムに書き込むか否かを判断する。これにより、オブジェクトストレージ８０２からの要求に対しては移行元ファイルストレージ１５０１から取得したデータを自身のファイルシステムに書かないように制御することで、オブジェクトストレージ８４０からの要求に応答して移行先ファイルコントローラ１５２０が実行するアクセス（入出力）の回数を削減し、オブジェクトストレージ８０２からの要求がホスト８８０のアクセス性能へ及ぼす影響を抑えることが期待できる。
　なお、本実施例において、移行元ファイルストレージ１５０１は、分散拠点１５６０の外に存在していてもよい。移行元ファイルストレージ１５０１は、第３のストレージ装置の一例である。
　実施例５を説明する。以下、実施例１との相違点を主に説明し、実施例１との共通点については説明を簡略又は省略する。なお、実施例５の説明は、主に実施例１との対比で行われるが、実施例５の説明において、「エッジストレージ」及び「エッジコントローラ」は、「ファイルストレージ」及び「ファイルコントローラ」と読み替えることができる。また、「コアストレージ」及び「コアコントローラ」は、「オブジェクトストレージ」及び「オブジェクトコントローラ」と読み替えることができる。
　実施例１（及び実施例２乃至実施例４）では、分析用ホスト２３０がデータにアクセスした際、オンデマンドでデータをエッジストレージ１５０からコアスコントローラ２４０がデータをコピー（取得）する。このため、分析用ホスト２３０が短時間に大量のデータにアクセスしたとき、これらのデータの更新フラグが“ON”であった場合、この延長で大容量のデータをエッジストレージ１５０からコアストレージ１２０へコピーすることが発生し得る。各分散拠点２６０と中央データセンタ２１０間のネットワーク帯域が狭い場合、データコピーに長時間を要し、分析用ホスト２３０で実行する分析処理の性能が低下する懸念がある。
　そこで、本実施例では、これを防ぐため、エッジストレージ１５０で更新されたデータをコアストレージ１２０へ直ちにコピーすることで、各分散拠点２６０と中央データセンタ２１０間で、一度に大容量のデータがコピーされることを抑えることができる。このとき、分析用ホスト２３０で分析処理を実行する直前に、コアコントローラ２４０でスナップショットを作成することにより、分析用ホスト２３０のデータアクセスと、エッジストレージ１５０からコアストレージ１２０へのデータコピーとが衝突して分析用ホスト２３０がアクセスするデータの一貫性を喪失することを防ぐことができる。
　図２７は、実施例５の概要を示す模式図である。
　エッジコントローラ２９０はボリューム１８９１のスナップショットを作成しない。ボリューム１８９１（第１のボリュームの一例）の更新が行われた場合、エッジコントローラ２４０は、差分データ（更新前ボリュームと更新後ボリュームとの差分としてデータ）をコアコントローラ２４０に送る。コアコントローラ２４０は、受信した差分データをコピー用ボリューム１８２２（第３のボリュームの一例）に格納し、そのボリューム１８２２のスナップショットとして参照用ボリューム１８２１（第２のボリュームの一例）を作成する。分析用ホスト２３０は、参照用ボリューム１８２１を参照し、分析を行う。
　本実施例におけるＬＵマッピング管理テーブルはエッジコントローラ２９０中のメモリ２９２に格納されている。また、ＬＵマッピング管理テーブルは、実施例１のＬＵマッピング管理テーブル３６０と異なる構成を持つ。
　図２８は、本実施例におけるＬＵマッピング管理テーブル１９００の構成図である。
　ＬＵマッピング管理テーブル１９００は、エッジストレージ１５０が保持するＬＵ毎にエントリを持つ。各エントリは、ＬＵＮ１９０１、コピー先ストレージ１９０２及びコピー先ＬＵＮ１９０３といった情報を格納する。以下、１つのＬＵを例に取る（図２８の説明で「対象ＬＵ」と言う）。
　ＬＵＮ１９０１は、対象ＬＵのＬＵＮである。コピー先ストレージ１９０２は、コピー先のコアストレージ１２０を一意に示す識別子である。コピー先ＬＵＮ１９０３は、コピー先のコピー用ボリューム１８２２のＬＵＮである。コピー先のコアストレージ１５０を一意に示す識別子には、ＩＰアドレスやＷＷＮが利用できる。
　本実施例では、コアストレージコントローラ２４０中のメモリ２４２及びエッジストレージコントローラ２９０中のメモリ２９２に格納されるプログラムの動作及びテーブル種別が実施例１と異なる。本実施例では、スナップショット管理テーブル３３０はコアストレージコントローラ２４０中のメモリ２４２に格納され、ＬＵマッピング管理テーブル１９００は前述のとおりエッジストレージコントローラ２９０に格納される。また、コピー状態管理テーブル３７０はメモリ２４２及びメモリ２９２のいずれも要しない。
　図２９は、ホスト２８０からエッジコントローラ２９０がライト要求を受信した場合にエッジコントローラ２９０により開始されるライト処理のフロー図である。
　エッジコントローラ２９０は、ライト要求に従うデータを自身が管理するボリューム（ライト要求で指定されているボリューム）に書き込む（ステップ２０１０）。次に、エッジコントローラ２９０は、ライト先ボリュームのＬＵＮを基に、ＬＵマッピング管理テーブル１９００を参照し、対応するコピー先ストレージ１９０２とコピー先ＬＵＮ１９０３を特定する（ステップ２０２０）。続けて、エッジコントローラ２９０は、特定したコピー先ストレージ１９０２に対応するコアコントローラ２４０に、特定したＬＵＮと、書込み先アドレス（例えばライト要求で指定されたアドレス）、書込みサイズ（ライト対象データのサイズ）、ライト対象データ（ライト要求に従うデータ）とが関連付けられたライト要求を送信する（ステップ２０３０）。
　コアコントローラ２４０は、そのライト要求を受信すると、そのライト要求に関連付いたＬＵＮに対応するコピー用ボリューム１８２２のうちの、そのライト要求に関連付いたアドレスが属する領域に、ライト対象データを書き込む（ステップ２０４０）。
　なお、ステップ２０２０、２０３０及び２０４０は、ホスト２８０にライト要求に対する応答を返す前に実施されてもよいし、その応答の後に実施されてもよい。
　コアコントローラ２４０は、エッジコントローラ２９０の挙動とは関係なく、任意のタイミングでスナップショットを作成できる。例えば、一定時間毎にスナップショットを作成するなどの運用が考えられる。逆に、エッジコントローラ２９０やホスト２８０の動作と連動してスナップショットをコアコントローラ２４０が作成してもよい。例えば、ホスト２８０が一連のデータを書き込む際、ホスト２８０とコアコントローラ２４０で通信を行い、データの整合性が取れた状態を通知し、その契機で実施する、などの動作が考えられる。
　実施例６を説明する。以下、実施例１及び５との相違点を主に説明し、実施例１及び５との共通点については説明を簡略又は省略する。なお、実施例６の説明は、主に実施例１及び５との対比で行われるが、実施例６の説明において、「エッジストレージ」及び「エッジコントローラ」は、「ファイルストレージ」及び「ファイルコントローラ」と読み替えることができる。また、「コアストレージ」及び「コアコントローラ」は、「オブジェクトストレージ」及び「オブジェクトコントローラ」と読み替えることができる。
　図３０は、実施例６の概要を示す模式図である。
　実施例６では、コアコントローラ２４０が、実施例１（及び実施例２乃至４）のようなオンデマンド型データコピー（分析用ホスト１３０からのリード要求に応答してデータを分散拠点１４０からコピーすること）と、実施例５のようなバックグラウンド型データコピー（分析用ホスト１３０からのリード要求の有無に関係無くデータを分散拠点１４０からコピーすること）とを併用又は切り替える。つまり、オンデマンド型データコピーとバックグラウンド型データコピーの両方が同時期に行われてもよいし、それらのコピーの一方が採用されている期間は他方が採用されないでもよい。
　以下が、１つの具体例である。
　参照用ボリューム２８２１は、第２のボリュームの一例であり、仮想的なボリュームであるとする。参照用ボリューム２８２１のページの参照先は、コピー用ボリューム２８２２内のページであることもあれば、上述したＤ－ｖｏｌ内のページであることもあってもよい。
　また、エッジコントローラ２９０は、実施例１と同様、ホスト１６０からライト要求を受けた場合、ライト先ページのＩＤを含んだ更新通知をコアコントローラ２４０に送信するようになっている。結果として、更新ビットマップテーブル３４０の更新がコピー状態管理テーブル３７０に反映されるようになっている。エッジコントローラ２９０が、ボリューム２８９１（第１のボリュームの一例）を提供する。
　コアコントローラ２４０は、参照用ボリューム２８２１について、新規ページアクセス回数を管理している。「新規ページ」とは、参照用ボリューム２８２１が分析用ホスト１３０に提供されてから初めてアクセス先（リード元又はライト先）とされたページである。
　コアコントローラ２４０は、参照用ボリューム２８２１の新規ページにアクセスされる都度に、新規ページアクセス回数を更新（例えばインクリメント）する。
　コアコントローラ２４０は、新規ページアクセス回数を、定期的に０（ゼロ）にリセットする。リセットの契機は、例えば，分析処理の実行スケジュールに合わせた「分析処理の実行前」であってもよいし、所定周期毎であってもよい。
　新規ページアクセス回数が０ということは、分析処理に必要なデータはすべてエッジストレージ１５０から取得済ということになる。この状態は、参照用ボリューム２８２１に十分にデータが格納されているとみなす条件である格納状態条件に適合した状態である。格納状態条件の一例が、新規ページアクセス回数が所定回数以下（例えば０）である。格納状態条件の別の一例は、参照用ボリューム２８２１の使用率が所定使用率以上である。参照用ボリューム２８２１の使用率とは、参照用ボリューム２８２１の容量に対する、参照用ボリューム２８２１に格納されているデータ（参照先が存在するページ）の量の割合である。
　コアコントローラ２４０は、定期的に又は不定期的に、格納状態条件が満たされているか否かを判断する（Ｓ３１）。
　＜格納状態条件が満たされていない場合（例えば、新規ページアクセス回数が１以上の場合）＞
　コアコントローラ２４０は、バックグラウンド型データコピーを開始せず、オンデマンド型データコピーを採用している状態を維持する（Ｓ３２）。つまり、コアコントローラ２４０は、分析用ホスト１３０からリード要求を受け（Ｓ２１）、コアリード処理を行う。
　すなわち、コアコントローラ２４０は、そのリード要求で指定されたＬＵに対応するコピー状態管理テーブル３７０を参照し（図３１：ステップ２１１０）、リード元ページ（リード要求で指定されたアドレスに属するページ）に対応するエントリを特定する。
　特定したエントリ内の未コピーフラグ５７３“ON”の場合（つまり、リード元ページが新規ページの場合）、コアコントローラ２４０は、新規ページアクセス回数をインクリメントし（図３０：Ｓ２２、図３１：ステップ２１３０）、リード対象データの取得要求をエッジストレージ１５０に送信する（図３１：ステップ２１５０）。これにより、コアコントローラ２４０は、リード対象データをエッジストレージ１５０から取得する（図３０：Ｓ２３）。コアコントローラ２４０は、取得したリード対象データをリード元ページに格納し（例えば、リード元ページに割り当てた空きＤ－ｖｏｌページに格納し）、そのリード対象データを当該ページから読み出して分析用ホスト１３０に返す。この後、コアコントローラは、コピー状態管理テーブル３７０における当該ページの更新フラグ５７２及び未コピーフラグ５７３を共に“OFF”にする。
　特定したエントリ内の更新フラグ５７２“ON”の場合（すなわち、未コピーフラグがONであることに起因するコピーが実行されて以降、エッジストレージで当該ページが更新され、かつその更新がエッジコントローラからコアコントローラに通知されたものの、いまだ最新データが取得されていない場合）、コアコントローラ２４０は、リード対象データの取得要求をエッジストレージ１５０に送信する（図３１：ステップ２１５０）。コアコントローラ２４０は、取得したリード対象データをリード元ページに格納し（例えば、リード元ページに新たに割り当てた空きＤ－ｖｏｌページ又は割当て済のＤ－ｖｏｌページに格納し）、そのリード対象データを当該ページから読み出して分析用ホスト１３０に返す。この後、コアコントローラは、コピー状態管理テーブル３７０における当該ページの更新フラグ５７２を“OFF”にする。
　＜格納状態条件が満たされている場合（例えば、新規ページアクセス回数が０の場合）＞
　コアコントローラ２４０は、バックグラウンド型データコピーを開始する（図３０：Ｓ３３）。つまり、コアコントローラ２４０は、エッジストレージ１５０において更新されたデータがあることを検知した場合（更新フラグ５７２“ON”に対応したページがある場合）、当該データをエッジストレージ１５０からコピー用ボリューム２８２２（第３のボリュームの一例）にコピーする（Ｓ３４）。
　実施例６では、オンデマンド型データコピーとバックグラウンド型データコピーとが自動で切り帰られるが、管理者等の手動により切り替えられてもよい。例えば、コアストレージ２４０は、参照用ボリューム２８２１の格納状態に関する情報（例えば新規ページアクセス回数）を管理システム（ストレージシステムを管理するシステム）に通知し、当該情報を見た管理者の指示を管理システムから受けて、バックグラウンド型データコピーを開始するか否かを決定してもよい。コアコントローラ２４０は、バックグラウンド型データコピーの開始後、リード元ページに対応した更新フラグ５７２が“ON”であるか否かに関わらずオンデマンド型データコピーを行わないでもよいし、リード元ページに対応した更新フラグ５７２が“ON”の場合はオンデマンド型データコピーも行ってもよい。
　実施例６によれば、実施例１（及び実施例２乃至４）の効果と実施例５の効果の両方の効果を奏することが期待できる。
　以上、本発明の幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
　例えば、コアコントローラ２４０（又はオブジェクトコントローラ８４０）は、分析用ホストからのリード要求を受けたとき、前回更新通知を発行して以降に更新されたページ（又はデータセット）を示す更新通知をエッジコントローラ２９０（又はファイルコントローラ８９０）に要求し、当該要求に応答して受けた更新通知（例えば更新ビットマップテーブル３４０）を基に、コピー状態管理テーブル３７０（又はオブジェクト管理テーブル１０１２）を更新してもよい。
２００：計算機システム

Claims (15)

  1. 　第１の拠点に存在する第１のストレージ装置と、
    　第２の拠点に存在するストレージ装置であって、前記第１のストレージ装置とネットワークを介して接続されたストレージ装置である第２のストレージ装置と
    を有し、
    　前記第１のストレージ装置が、それぞれがボリューム領域又はデータセットである複数の第１の要素を含むことが可能な第１のボリュームを提供し、
    　前記第２のストレージ装置が、それぞれがボリューム領域又はデータセットであり複数の第１の要素に対応した複数の第２の要素を含むことが可能な第２のボリュームを提供し、
    　前記第１のストレージ装置が、第１のホストからのライト要求に従い更新された第１の要素に関する更新通知を前記第２のストレージ装置に送信し、
    　前記第２のストレージ装置が、前記更新通知を受信した場合、当該更新通知を基に特定された第２の要素について、当該第２の要素に対応した第１の要素のデータが最新データであると管理し、
    　前記第２のストレージ装置が、第２のホストからリード要求を受けた場合、
    　　（Ａ）当該リード要求から特定された第２の要素であるリード元第２要素に対応した第１の要素のデータが最新データであるか否かを判断し、
    　　（Ｂ）（Ａ）の判断結果が真の場合、前記最新データの取得要求を前記第１のストレージ装置に送信し、
    　　（Ｃ）当該取得要求に応答して前記第１のストレージ装置から取得された最新データを、前記リード元第２要素のデータとし、且つ、当該最新データを前記第２のホストに返す、
    ストレージシステム。
  2. 　各第１の要素及び各第２の要素は、いずれも、ボリューム領域であり、
    　前記更新通知は、最新世代の前記第１のボリュームと、更新通知が前回送信されたときの世代の前記第１のボリュームとの差分に相当する第１の要素のＩＤを含む、
    請求項１記載のストレージシステム。
  3. 　各第１の要素及び各第２の要素は、いずれも、ボリューム領域であり、
    　前記第２のストレージ装置が、コピー管理情報を有し、
    　前記コピー管理情報は、第２の要素毎に、
    　　前記第１のストレージ装置から前記第２のストレージ装置への前回データコピー以降に当該第２の要素に対応した第１の要素のＩＤを含む更新通知を受けたか否かを示す第１の情報要素と、
    　　前記第２のボリュームが作成されて以降に、前記第１のストレージ装置から当該第２の要素に対してデータが未コピーであるか否かを示す第２の情報要素と
    を含み、
    　前記リード元第２要素に対応した第１及び第２の情報要素のうちの少なくとも１つが肯定的な値であれば、（Ａ）の判断結果が真である、
    請求項１記載のストレージシステム。
  4. 　前記第２のストレージ装置が、 前記更新通知を受信した場合、当該更新通知から特定された第１の要素に対応した第２の要素についての第１の情報要素の値を、肯定的な値に更新する、
    請求項３記載のストレージシステム。
  5. 　前記第２のストレージ装置は、前記第１のストレージ装置が前記第１のホストから前記ライト要求を受信した場合に当該ライト要求に従い更新された第１の要素に関する前記更新通知を受信する、
    請求項１記載のストレージシステム。
  6. 　各第１の要素及び各第２の要素は、いずれも、データセットであり、
    　前記第１のストレージ装置が、前記第２のストレージ装置に、データセットのスタブを作成することの要求であるスタブ作成要求を送信し、
    　前記第２のストレージ装置は、前記第１のストレージ装置からの前記スタブ作成要求に応答として、当該スタブ作成要求で指定されているデータセットのスタブであって前記第２のホストから認識されるスタブを作成し、
    　前記リード要求は、前記作成されたスタブを指定したリード要求であり、
    　前記取得要求は、前記スタブに対応したデータセットの取得要求である、
    請求項１記載のストレージシステム。
  7. 　前記第２のストレージ装置が、コピー管理情報を有し、
    　前記コピー管理情報は、第２の要素毎に、
    　　前記第１のストレージ装置から前記第２のストレージ装置への前回データコピー以降に当該第２の要素に対応した第１の要素のＩＤを含む更新通知を受けたか否かを示す第１の情報要素と、
    　　前記第１のストレージ装置から当該第２の要素としてのデータセットがコピーされたことに代えて当該データセットのスタブか存在するか否かを示す第２の情報要素と
    を含み、
    　前記リード元第２要素に対応した第１及び第２の情報要素のうちの少なくとも１つが肯定的な値であれば、（Ａ）の判断結果が真である、
    請求項６記載のストレージシステム。
  8. 　第１の要素であるデータセットの種類と、第２の要素であるデータセットの種類とが異なっており、
    　前記第１のストレージ装置が、
    　　第１の要素のＩＤと第２の要素のＩＤとの対応関係を示す第１の検索用情報と、
    　　第２の要素のＩＤと第１の要素のＩＤとの対応関係を示す第２の検索用情報と
    を有し、
    　前記第１のストレージ装置が、当該更新された第１の要素のＩＤに対応した第２の要素のＩＤを前記第１の検索用情報から特定し、
    　前記更新通知は、前記特定された第２の要素のＩＤを含む更新通知であり、
    　前記取得要求は、第２の要素のＩＤとして前記スタブのＩＤであるスタブＩＤを含み、
    　前記第１のストレージ装置が、
    　　（Ｆ）当該取得要求内のスタブＩＤに対応した第１の要素のＩＤを前記第２の検索用情報から特定し、
    　　（Ｇ）（Ｆ）で特定したＩＤに対応した第１の要素としてのデータセットを前記第２のストレージ装置に返す、
    請求項６記載のストレージシステム。
  9. 　各第１の要素は、ファイル又はディレクトリであり、
    　各第２の要素は、オブジェクト又はそのスタブであり、
    　前記第１のストレージ装置は、（Ｆ）で特定したＩＤに対応した第１の要素としてのデータセットがディレクトリの場合、
    　　（Ｈ）当該ディレクトリに格納されている全てのデータセットの各々のスタブを前記第１のボリュームに作成する、
    請求項８記載のストレージシステム。
  10. 　第３のストレージ装置から前記第１のストレージ装置にデータを移行している最中において、前記第１のストレージ装置が、前記取得要求を前記第２のストレージ装置から受信した場合、
    　　当該取得要求に従う取得対象の最新データが前記第１のストレージ装置に移行済みか否かを判断し、
    　　当該判断の結果が真の場合、当該最新データを前記第２のストレージ装置に返し、
    　　当該判断の結果が偽の場合、当該最新データを前記第３のストレージ装置から取得して前記第２のストレージ装置に返す、
    請求項１記載のストレージシステム。
  11. 　各第１の要素及び各第２の要素は、いずれも、データセットであり、
    　前記取得対象として前記第１のストレージ装置に存在する対象がデータセットのスタブの場合、前記判断の結果が偽である、
    請求項１０記載のストレージシステム。
  12. 　前記第３のストレージ装置から前記第１のストレージ装置にデータを移行している最中において受信した要求の要求元が、前記第２のストレージ装置であるか前記第１のホストであるかを判断し、
    　前記要求元が前記第２のストレージ装置の場合、前記受信した要求は前記取得要求であり、前記第１のストレージ装置は、前記第３のストレージ装置から取得したデータを、前記第１のボリュームに格納すること無しに、前記第２のストレージ装置に返し、
    　前記要求元が前記第１のホストの場合、前記受信した要求はリード要求であり、前記第１のストレージ装置は、当該リード要求に従うデータであり前記第３のストレージ装置から取得したデータを、前記第１のボリュームに格納して、前記第１のホストに返す、
    請求項１０記載のストレージシステム。
  13. 　前記第２のストレージ装置は、第３のボリュームを更に有し、
    　前記第２のストレージ装置は、
    　　前記第２のボリュームに十分にデータが格納されているとみなす条件である格納状態条件が満たされているか否かを判断し、
    　　当該判断の結果が偽の場合、前記第２のホストからのリード要求に応答して当該リード要求から特定された第２の要素に対応した第１の要素のデータが最新データであれば当該最新データを前記第１のストレージ装置から取得することであるオンデマンド型データコピーを採用している状態を維持し、
    　　当該判断の結果が真の場合、前記第２のホストからのリード要求の有無に関わらずデータを前記第１のストレージ装置から前記第３のボリュームに取得することであるバックグラウンド型データコピーを開始する、
    請求項１記載のストレージシステム。
  14. 　前記格納状態条件が満たされているとは、前記第２のストレージ装置に新規にアクセスされる第２の要素の数が所定数未満であることである、
    請求項１３記載のストレージシステム。
  15. 　第２のストレージ装置が、第１のホストからのライト要求に従い更新された第１の要素に関する更新通知を、第１のストレージ装置から受信し、
    　　前記第１のストレージ装置は、それぞれがボリューム領域又はデータセットである複数の第１の要素を含むことが可能な第１のボリュームを提供し、第１の拠点にある装置であり、
    　　前記第２のストレージ装置は、それぞれがボリューム領域又はデータセットであり複数の第１の要素に対応した複数の第２の要素を含むことが可能な第２のボリュームを提供し、第２の拠点にある装置であり、
    　前記第２のストレージ装置が、前記更新通知を受信した場合、当該更新通知を基に特定された第２の要素について、当該第２の要素に対応した第１の要素のデータが最新データであると管理し、
    　前記第２のストレージ装置が、第２のホストからリード要求を受けた場合、
    　　（Ａ）当該リード要求から特定された第２の要素であるリード元第２要素に対応した第１の要素のデータが最新データであるか否かを判断し、
    　　（Ｂ）（Ａ）の判断結果が真の場合、前記最新データの取得要求を前記第１のストレージ装置に送信し、
    　　（Ｃ）当該取得要求に応答して前記第１のストレージ装置から取得された最新データを、前記リード元第２要素のデータとし、且つ、当該最新データを前記第２のホストに返す、
    データ転送制御方法。
PCT/JP2017/028171 2017-08-03 2017-08-03 ストレージシステム及びデータ転送制御方法 WO2019026222A1 (ja)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Patent Citations (2)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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