WO2016170619A1

WO2016170619A1 - Computer system

Info

Publication number: WO2016170619A1
Application number: PCT/JP2015/062259
Authority: WO
Inventors: 慎二小笠原; 康雄山崎; 幸二帆波; 健志北村; 純平滝安; 信之雑賀
Original assignee: 株式会社日立製作所
Priority date: 2015-04-22
Filing date: 2015-04-22
Publication date: 2016-10-27

Abstract

A computer system according to one aspect of the present invention comprises a host computer, a first storage device further comprising a first and a second volume, and a second storage device further comprising a third and a fourth volume. When writing a file to storage, the host computer writes actual file data to the first volume, and writes to the second volume metadata which is management information, such as the location where the actual file data is stored. With the first storage device, the data which is written to the first volume is mirrored on the third volume in an asynchronous copy mode, and the data which is written to the second volume is mirrored on the fourth volume in a synchronous copy mode.

Description

Computer system

The present invention relates to a file server.

Currently, many storage apparatuses provide reliability exceeding the reliability of a single HDD by adopting high reliability technology such as RAID (Redundant Array of Independent (or Inexpensive) Disks) technology. However, due to the recent evolution of the information society, there is a scene where the reliability that can be provided by the RAID technology is insufficient.

As a high availability technology corresponding to such a situation, as disclosed in Patent Document 1, for example, an information system using a plurality of (for example, two) storage apparatuses (hereinafter referred to as apparatus A and apparatus B). Is constructed, and data is replicated (mirrored) between the device A and the device B. In the information system disclosed in Patent Document 1, when the host issues a request (write command) for writing data to the volume of the device A, the device A stores a copy of the data in the volume of the device B. After the copy of the data is stored in the volume of the device B, the device A returns to the host that the write command is completed. As a result, the same data is always stored in the volume of the device A and the volume of the device B.

When the host fails to access the volume of device A (I / O processing), the access destination is switched to access the volume of device B. Since the same data as the volume of the device A is stored in the volume of the device B, the host can continue the business without any problem.

US Pat. No. 8,595,549 Specification

In the technique disclosed in Patent Document 1, the device A does not send a reply that the write command is completed to the host until it is confirmed that the data copy is stored in the volume of the device B. Make a copy of Therefore, the problem is that the host write response time becomes long. In particular, in the case of a system in which the device B is installed at a remote location away from the device A, the write response time becomes longer, which may adversely affect the performance of the computer system.

A computer system according to an aspect of the present invention includes a host computer, a first storage device having first and second volumes, and a second storage device having third and fourth volumes. When the host computer writes a file to the storage, the file actual data is written to the first volume, and metadata that is management information such as the storage location of the file actual data is written to the second volume. In the first storage device, data written to the first volume is replicated to the third volume in the asynchronous copy mode, and data written to the second volume is replicated to the fourth volume in the synchronous copy mode.

According to the present invention, the I / O response time during normal operation can be shortened, and the business can be continued when a failure occurs.

It is a hardware block diagram of the computer system which concerns on an Example. It is a software block diagram of the computer system which concerns on an Example. It is explanatory drawing of the structure of a metadata area | region. It is explanatory drawing of the structure of real data. It is the figure which showed the content of the alternative path management table. It is the figure which showed the content of the scsi block mapping table. It is a flowchart of a file open process. It is a flowchart of an access object file search process. It is a flowchart of a file write process. It is a flowchart of the process performed by path replacement software. It is a figure which shows the whole flow of a write process. It is a flowchart of a file read process. FIG. 10 is a diagram illustrating an overall flow of a write process according to a second embodiment. It is explanatory drawing of the structure of cache information. 10 is a flowchart of file read processing according to the second embodiment.

Hereinafter, embodiments of the present invention will be described with reference to the drawings. The embodiments described below do not limit the invention according to the claims, and all the elements and combinations described in the embodiments are essential for the solution of the invention. Is not limited.

In the following description, “program” may be used as the subject, but in practice, the program is executed by a processor (CPU (Central Processing Unit)) to perform a predetermined process. However, to prevent the explanation from becoming redundant, the program may be described as the subject. Further, part or all of the program may be realized by dedicated hardware. Various programs may be installed in each apparatus by a program distribution server or a computer-readable storage medium. As the storage medium, for example, an IC card, an SD card, a DVD, or the like may be used.

Before starting the description of the embodiments, various terms used in the embodiments described below will be described.

“Volume” means a storage area (storage space) provided by the storage device to the host. A storage apparatus according to an embodiment described below can provide one or more volumes to a host. In this specification, the term “logical device” may be used instead of the term “volume”.

“Remote copy” means a process of creating a copy of a storage device volume in a volume of another storage device. In the embodiment described below, the storage apparatus has a function of performing remote copy. Upon receiving write data for the volume from the host, the storage apparatus writes the write data to the volumes of the two storage apparatuses.

Also, when data is stored in two volumes by remote copy, the volume in which data is stored first is called “primary volume”. The second volume in which data is stored is called a “secondary volume”. A pair of a primary volume and a secondary volume is called a “volume pair”.

A “file system” generally means a program that searches and manipulates data stored in a volume, or is created on a volume to enable data retrieval and manipulation. It may mean a data structure. In this specification, in order to avoid confusion, a program for searching and operating data stored in a volume is called a “file system program”, and a data structure created on the volume is called a “file system”. Call it. The process of creating a data structure for storing a file on a volume is expressed as “creating a file system”.

“Mount” means a procedure (process) for allowing an application program or operating system to access a file system. The procedure for enabling access to a data structure (file system) stored in a volume is called "mounting a file system".

“Device file” refers to an interface for a program executed on the host to access an input / output device such as a disk. In the embodiment described below, a program such as a device driver manages a unique device file name in association with each volume provided by the storage apparatus. A program executed on the host 30 can access a volume associated with a device file name by specifying a device file name and issuing an access request.

Hereinafter, the configuration of the computer system according to the embodiment of the present invention will be described. FIG. 1 is a diagram illustrating a hardware configuration of the computer system according to the first embodiment.

The computer system according to the embodiment of the present invention has a host 30 and two storage devices (20a, 20b). The host 30 is connected to one or more clients 40 via the network 50.

The storage device 20a and the storage device 20b are devices that store files created by the host 30. The storage device 20 a and the storage device 20 b are connected to the host 30 via the network 60. Although the hardware configuration of the storage device 20b is not necessarily the same as the hardware configuration of the storage device 20a, in this embodiment, an example in which both hardware configurations are the same will be described. In the present specification, when a component or function common to the storage apparatus 20a and the storage apparatus 20b is described, reference numbers without suffix such as “a” and “b” are used.

The hardware configuration of the storage apparatus 20 will be described by taking the storage apparatus 20a as an example. The storage device 20a includes a storage controller (sometimes abbreviated as CTL) 21a and a plurality of DISKs 23a. The storage controller 21a is a device that includes a communication interface for communicating with the host 30 and the storage device 20b, a processor for processing an I / O request from the host 30, a cache memory, and the like. The DISK 23 a is a storage device that stores write data from the host 30. As an example, an HDD (Hard Disk Drive) can be used for the DISK 23a. However, in addition to the HDD, a storage device such as an SSD (Solid State Drive) may be applied to the DISK 23a.

The storage device 20a and the storage device 20b are connected via a communication path 70. The storage apparatus 20a can transmit a copy of data written from the host 30 to the storage apparatus 20a via the communication path 70 to the storage apparatus 20b.

FIG. 1 shows a configuration in which each storage apparatus 20 has one CTL 21 and two DISKs 23, but the number is not limited to this. Two or more CTLs 21 may exist in the storage apparatus 20, or three or more DISKs 23 may exist.

The host 30 is a computer that operates as a file server for the client 40, and includes a CPU 31, a memory 32, a NIC (Network Interface Controller) 33, and an HBA (Host Bus Adapter) 34. The NIC 33 is a communication interface device for communicating with the client 40. The HBA 34 is a communication interface device for communicating with the storage apparatus 20.

The memory 32 is a high-speed accessible storage device such as RAM (Random Access Memory) or ROM (Read Only Memory). In the host 30, a program for controlling the host 30 is read onto the memory 32, and the CPU 31 executes the program. The host 30 may have another type of storage resource (such as an HDD) in addition to or instead of the memory 32. The memory 32 is an example of a storage device.

The host 30 receives a file level I / O request from the client 40 via the NIC 33. The host 30 converts the file level I / O request into a block level I / O request and transmits it to the storage apparatus 20.

The client 40 includes a CPU 41, a memory 42, and a NIC 43. The client 40 may have other types of storage resources in addition to or instead of the memory 42. The client 40 transmits a file level I / O request to the host 30 via the NIC 43.

FIG. 2 is a software configuration diagram of the computer system according to the present embodiment. In the CTL 21 of the storage device 20a (20b), the processor executes the control program 201. By executing the control program, the CTL 21 forms a RAID group using one or more storage areas of the DISK 23. As a result, even when a failure occurs in one DISK 23, data can be recovered and data loss can be prevented.

Further, the CTL 21 forms a logical storage device 24 using a part or all of the storage area of the RAID group. In this embodiment, this logical storage device is called a logical device (LDEV). The CTL 21 can form a plurality of logical devices. The storage apparatus 20 provides the LDEV 24 to the host 30, and the host 30 issues an I / O request (read command, write command, etc.) to the LDEV 24 provided from the storage apparatus 20. The CTL 21 executes data access to the LDEV 24 in response to the I / O request received from the host 30.

Note that the storage apparatus 20 according to the present embodiment stores the write data received from the host 30 in the cache memory of the CTL 21 before storing it in the DISK 23 configuring the LDEV 24. The CTL 21 performs writing by the write back method. That is, when the write data is stored in the cache memory, the CTL 21 responds to the host 30 that the write processing is completed, and writing of the write data to the DISK 23 is performed asynchronously with the response to the host 30. Therefore, in this embodiment, not only when the write data is stored in the DISK 23 constituting the LDEV, but also when the write data for the LDEV is written into the cache memory of the CTL 21, the data is stored in the LDEV. (Written) ".

FIG. 2 shows a configuration in which the storage apparatus 20a has two LDEVs 24 (LDEV 24a-1 and LDEV 24a-2) and the storage apparatus 20b has two LDEVs 24 (LDEV 24b-1 and LDEV 24b-2). However, the storage apparatus 20 can have more than two LDEVs. Hereinafter, the LDEV 24a-1 may be referred to as “LDEVa”, the LDEV 24a-2 as “LDEVc”, the LDEV 24b-1 as “LDEVb”, and the LDEV 24b-2 as “LDEVe”.

The storage device 20 further has a function of performing remote copy processing. The storage apparatus 20 according to this embodiment manages LDEVa and LDEVb as volume pairs, and manages LDEVc and LDEVe as separate volume pairs. LDEVa and LDEVc are set as primary volumes, and LDEVb and LDEVe are set as secondary volumes.

By the remote copy function, LDEVa and LDEVb, which are volume pairs, maintain the same data stored state. Further, LDEVc and LDEVe, which are different volume pairs, also maintain the same data stored state. Therefore, even when a failure occurs in the storage device 20a and access from the host 30 to the LDEVa or LDEVc becomes impossible, if the host 30 accesses the storage device 20b, the host 30 stores it in the LDEVa or LDEVc. Can access (replicated) data.

Explains the outline of the data write process to the volume by remote copy. When the storage apparatus 20a accepts a data write request from the host 30 to the LDEVa area (assuming the address of this area is A), the storage apparatus 20a writes the data to the address A of the LDEVa and, via the communication path 70, the storage apparatus 20b is instructed to write the data passed from the host 30 to the address A of the LDEVb. When the storage device 20b receives this instruction (and data), it writes the data to the address A of the LDEVb. By performing such processing, the state in which the same data is stored in LDEVa and LDEVb is maintained.

Remote copy has two types of copy modes: synchronous copy mode and asynchronous copy mode. In remote copy in synchronous copy mode (also called synchronous remote copy), when the storage apparatus 20 receives a write request for the LDEV 24 from the host 30, processing related to the write request is performed until data is stored in both the primary volume and the secondary volume. Does not respond to the host that In other words, when a completion response to the write request is returned from the storage apparatus 20 to the host 30, it is guaranteed that data has been stored in the two volumes constituting the volume pair.

In remote copy in asynchronous copy mode (also called asynchronous remote copy), when the storage apparatus 20 receives a write request for the LDEV 24 from the host 30, it indicates that the processing related to the write request has been completed when data is stored in the primary volume. Responds to the host 30. The storage of data in the secondary volume may be performed after a notification that processing related to the write request is completed is returned to the host.

Therefore, in the remote copy in the asynchronous copy mode, the I / O response time of the host 30 is shorter than in the remote copy in the synchronous copy mode. However, when the response to the write request is returned from the storage apparatus 20a to the host 30, it is guaranteed that data is stored in the primary volume, but data may not be stored in the secondary volume. is there. Therefore, if a failure occurs in the primary volume at this time, and the host 30 becomes inaccessible, even if the host 30 reads data from the secondary volume, the correct data (the same as the latest data written by the host 30 to the primary volume) Data) may not be read. As a result, the host 30 may not be able to continue business using the secondary volume.

On the other hand, in the case of remote copy in the synchronous copy mode, when writing from the host 30 to the storage apparatus 20 is completed (a completion response is returned from the storage apparatus 20), data is stored in the two volumes constituting the volume pair. It is guaranteed that For this reason, even if the primary volume fails and becomes inaccessible, the host 30 can read the latest data by accessing the secondary volume, and can continuously execute programs and operations such as AP. . However, when the synchronous copy mode is used, the I / O response time of the host 30 becomes longer than when the asynchronous copy mode is used. In particular, when the distance of the communication path 70 is long, the I / O response time is prolonged, which may adversely affect the performance of the entire computer system.

The

storage apparatuses

20a and 20b according to the present embodiment are set so that remote copy is performed in the synchronous copy mode for the volume pair of LDEVa and LDEVb. On the other hand, the LDEVc and LDEVe volume pair is set to perform remote copy in the asynchronous copy mode. This setting is performed in advance by a user (administrator) of the computer system.

In addition, the

storage apparatuses

20a and 20b according to the present embodiment allow the host 30 to access any LDEV 24 that constitutes the volume pair for the volume pair that is to be remotely copied in the synchronous copy mode. Therefore, the host 30 may access either the LDEVa or the LDEVb for the LDEVa and LDEVb volume pair. When the host 30 sends a write request and write data to the LDEVb of the storage device 20b, the storage device 20b sends the write request and write data to the storage device 20a, and the storage device 20a sends the write data to LDEVa that is the primary volume. Write. After the writing of the write data to the LDEVa is completed, the storage apparatus 20b stores the write data in the LDEVb, and then returns a completion response to the host 30.

On the other hand, since the LDEVc and LDEVe volume pairs are remotely copied in the asynchronous copy mode, the same data as the LDEVc may not always be stored in the LDEVe. For this reason, LDEVe should not be accessed unless LDEVc is not accessible.

Next, various programs executed by the host 30 will be described. The memory 32 of the host 30 stores at least a file service daemon 301, a file system program 302, path replacement software 303, and a device driver 304.

The device driver 304 is a program for providing an access interface to the LDEV 24 for a higher-level program (file system program 302, path replacement software 303). The device driver 304 maps the LDEV 24 to the device file. When the host program designates a device file and issues a read or write request, the device driver 304 issues a read command or a write command to the LDEV 24 mapped to the designated device file.

In the computer system according to the present embodiment, the device driver 304 maps LDEVa to the device file sda (341), maps LDEVb to the device file sdb (342), maps LDEVc to the device file sdc (343), and LDEVe is mapped to the device file sde (344). Hereinafter, the device files (device files sda (341) to sde (344)) to which the device driver 304 maps the LDEV 24 are referred to as “scsi device files”.

The path replacement software 303 is a program that dynamically switches the access path to the device file. The path alternation software 303 provides device files sddlma (331) and sddlmb (332) to a higher-level program such as the file system program 302. Device files sda (341) and sdb (342) are mapped to the device file sddlma (331). Device files sdcmb (332) and device files sdc (343) and sde (344) are mapped.

For example, when the file system program 302 accesses (reads or writes) sdlma (331), the path replacement software 303 accesses either sda (341) or sdb (342). When the LDEVa (sda (341)) is not accessible, the path replacement software 303 changes the access destination to LDEVb (sdb (342)). The access destination is changed transparently to the file system program 302, and it is not necessary to stop the processing in the file system program 302.

Similarly, when the file system program 302 accesses (reads or writes) sddlmb (332), the path replacement software 303 accesses either sdc (343) or sde (344). If LDEVc (sdc (343)) is inaccessible, the path replacement software 303 changes the access destination to LDEVe (sde (344)) transparently to the file system program 302.

The file system program 302 is a program for executing access to a file stored in the LDEV 24. The file system program 302 creates a data structure called a file system in the LDEV 24, thereby storing the file in the LDEV 24 or reading the file stored in the LDEV 24. Details of the file system will be described later.

The file service daemon 301 is a program that provides a file sharing service to the client 40 using a communication protocol defined for file access, such as CIFS (Common Internet File System) or NFS (Network File System). When the file service daemon 301 receives a file access request (for example, a read request) from the client 40, the file service daemon 301 calls the file system program 302, reads the file to be accessed from the LDEV 24, and returns it to the client 40.

Subsequently, the structure of the file system created by the file system program 302 will be described. In general, file management information (metadata) required for file access, such as an area for storing data (actual data) written from the host 30 and a position where the actual data is written, is stored in the file system. ) Is stored. In the present specification, the former is sometimes referred to as “actual data area”, and the latter is sometimes referred to as “metadata area”.

The file system program 302 uses two LDEVs 24 to store one file system. In the file system program 302, one LDEV 24 is provided with a metadata area, and the other LDEV 24 is provided with an actual data area. Hereinafter, the LDEV 24 provided with the metadata area is referred to as “metadata VOL”, and the LDEV 24 provided with the actual data area is referred to as “real VOL”.

In the example of FIG. 2, LDEVa and LDEVc are used to store one file system. Since LDEVb and LDEVe store the replicated data of LDEVa and LDEVc, respectively, it can be said that LDEVb and LDEVe are used to store one file system. In this embodiment, an example will be described in which a metadata area is provided in LDEVa (LDEVb) and an actual data area is provided in LDEVc (LDEVe).

The structure of the metadata area will be described with reference to FIG. The metadata area includes areas of Superblock (may be abbreviated as SB) 241, InodeEntry block 242, and Inode block 243. The SB 241 is always arranged at a fixed position on the LDEV (for example, the head of the LDEV). The SB 241 has at least areas s_volume_name (241-1), ie_offset (241-2), and i_offset (241-3).

S_volume_name (241-1) is an area for storing the name (identifier) of the LDEV 24 in which the actual data area is provided. As the name of the LDEV 24 stored in the s_volume_name (241-1), the device file name provided by the path replacement software 303 (sddlmb (332) in the example of FIG. 2) is used.

Ie_offset (241-2) is an area in which the head address of the InodeEntry block 242 is stored. Further, i_offset (241-3) is an area in which the head address of the Inode block 243 is stored. When the file system program 302 creates a file system, values are stored in these areas.

The information of the SB 241 is used when the file system program 302 mounts the file system. When a user (administrator) of the computer system wants to mount a file system, the user makes a device file (sddlma) corresponding to an LDEV (in this embodiment, LDEVa or LDEVc) having a metadata area to the file system program 302. ) Is specified and a mount instruction is issued. The file system program 302 acquires the SB 241 by reading the device file “sddlma” during the mount process. The file system program 302 identifies the LDEV in which the actual data area is stored by referring to s_volume_name (241-1) stored in the SB 241. The file system program 302 makes the SB 241 resident in the memory 32.

Subsequently, information stored in the InodeEntry block 242 and the Inode block 243 will be described. The InodeEntry block 242 stores a plurality of InodeEntry. A plurality of inodes are stored in the inode block 243.

Inode and InodeEntry are file management information. There is one Inode and one InodeEntry for each file. In this specification, a set of Inode and InodeEntry is called file metadata. As shown in FIG. 3, the Inode includes information of i_no (243-1), offset (243-2), size (243-3), and prechk (243-4).

・ Each Inode in the file system is given a unique identification number in the file system. This number is called the Inode number. Inode number is stored in i_no (243-1). The file system program 302 according to the present embodiment uses an integer value of 0 or more for the Inode number.

Offset (243-2) and size (243-3) are areas for storing information for specifying the area where the actual data of the file is stored. In the offset (243-2), the head address of the area where the actual data of the file is stored is stored. When the actual data area is provided in the LDEVc (that is, when s_volume_name 241-1 is “sddlmb”), an address (for example, LBA) on the LDEVc is stored in offset (243-2). The size of the file is stored in size (243-3). The definition of the file size will be described later.

Prechk (243-4) is an area of a fixed size (for example, 16 bytes), and stores a check code for enabling later confirmation that the actual data of the file has been correctly written. Details will be described later.

Note that the Inode may include things other than the information described above. For example, file access rights, access date information, and the like may be included.

Information included in InodeEntry will be described. As shown in FIG. 3, InodeEntry includes i_no (242-1) and fileName (242-2). i_no (242-1) is an Inode number, similarly to i_no (243-1). The file name of the file is stored in fileName (242-2).

Both InodeEntry and Inode are fixed size information. In the InodeEntry block 242, a plurality of InodeEntry is successively stored in order from the smallest i_no (242-1) (number 0). In the Inode block 243, a plurality of Inodes are continuously stored in order from the smallest i_no (243-1).

InodeEntry is information for file search. The file system program 302 receives, for example, a read request for a file whose file name is “A” from the application program (hereinafter abbreviated as “AP”) executed on the client 40 via the file service daemon 301 (more precisely, When a file open request and a read request are received, the file system program 302 searches the InodeEntry block 242 for an InodeEntry whose fileName (242-2) is “A”. Then, i_no (242-1) of the searched InodeEntry is specified.

If i_no (242-1) of the retrieved InodeEntry is N (N is an integer value equal to or greater than 0), the file system program 302 subsequently searches in the Inode block 243 to obtain i_no (243-1). ) Identifies N inodes. Then, the file system program 302 accesses the actual data using the offset (243-2) and size (243-3) included in the specified Inode.

The structure of actual data will be described with reference to FIG. The actual data is stored in the actual VOL (LDEVc in this embodiment). The actual data includes prechk (251) and filedata (252). filedata (252) is the actual data of the file (data requested to be written by the client 40). prechk (251) is the same information as prechk (243-4) included in the inode of the file. When the file system program 302 writes a file, the same information is written to prechk (251) and prechk (243-4) included in the inode of the file. The file system program 302 according to the present embodiment stores an integer value with 1 as an initial value in prechk (251) and prechk (243-4). When writing a file for the first time, 1 is written to prechk (251) and prechk (243-4), and prechk (251) is used for the nth write (n is an integer value, n> 1). ) And prechk (243-4) are written n. That is, prechk (243-4) and prechk (251) store values corresponding to the number of file writes. Since the actual data includes prechk (251), the file size (value stored in the size of Inode (243-3)) is set to the length of filedata (252) by the length of prechk (251). It is the added value.

Next, the contents of management information used by each program (303, 304) will be described. FIG. 5 shows an example of the contents of the alternate path management table 330. The alternate path management table 330 is a table for storing management information used by the path alternate software 303, and includes columns of an scsi device file 501, a DM device file 502, an attribute 503, a copy method 504, and an access state 505.

The DM device file 502 stores the device file name of the device file provided to the upper program by the path replacement software 303. On the other hand, the scsi device file 501 stores the scsi device file name mapped to the DM device file 502. The attribute 503 stores the LDEV attribute mapped to the device file specified by the DM device file 502. When 0 is stored, this indicates that the LDEV is a primary volume. When other values (for example, 1) are stored, this indicates that the LDEV is a secondary volume.

The copy method 504 stores information on the remote copy method executed for the LDEV pair mapped to the DM device file 502. When 0 is stored, copying in the synchronous copy mode is performed, and when 1 is stored, copying in the asynchronous copy mode is performed.

In the access state 505, information indicating the state of the LDEV 24 mapped to the scsi device file 501 is stored. When 0 is stored, the state of the LDEV 24 is normal and the host 30 can access the LDEV 24. When 1 is stored, the status of the LDEV 24 is not normal and the host 30 cannot access the LDEV 24. Information registration in the alternate path management table 330 is performed by a user of the computer system except for information registered in the access state 505.

FIG. 6 is a diagram showing an example of the contents of the scsi block mapping table 340. The scsi block mapping table 340 includes columns of a storage 521, an LDEV 522, and an scsi device file 523. The scsi block mapping table 340 stores information used by the device driver 304. The device file specified by the device file name stored in the scsi device file 523 is mapped to the LDEV specified by the LDEV 522. Represents that Further, the storage 521 stores identification information (such as a serial number) of the storage apparatus to which the LDEV specified by the LDEV 522 belongs. By referring to the scsi block mapping table 340, the device driver 304 recognizes that when a higher-level program (such as the path replacement software 303) issues an access request for the device file “sdb”, for example, the LDEVb may be accessed. it can. Information registration in the scsi block mapping table 340 is performed by a user of the computer system. However, as another embodiment, information may be automatically registered in the scsi block mapping table 340 by the device driver 304 acquiring information from the storage apparatus 20.

Subsequently, the flow of processing performed by the host 30 when the host 30 receives a file access request from the client 40 will be described with reference to FIG. The client 40 makes a file open request before performing file access. FIG. 7 shows the flow of processing executed when the file system program 302 receives a file open request.

In step 1001, the file system program 302 receives a file open request. Since the file open request includes the file name of the access target file, the file system program 302 acquires it.

In step 1002, the file system program 302 reads the inode of the access target file. Details of this processing will be described later. In step 1003, the file system program 302 generates a file descriptor corresponding to the access target file, and stores the generated file descriptor on the memory 32 together with the inode of the access target file. This set of file descriptors stored together with Inode and Inode is called a file structure. A file descriptor is a type of key used to access a file. When a file is read or written after file open processing is executed, a file request program is called a file system program. By passing to 302, the file to be accessed can be taught to the file system program 302. The file descriptor and the file structure are held on the memory 32 until receiving a file close request issued when the client 40 ends the file access. In the present embodiment, the description of the processing when the file close request is received is omitted.

Finally, the file system program 302 returns the file descriptor to the calling program (file service daemon 301, AP of the client 40) (step 1004), and ends the process.

Subsequently, the process of reading the inode of the access target file performed in step 1002 will be described with reference to FIG. First, in step 1041, the file system program 302 reads ie_offset (241-2) and i_offset (241-3) in the SB 241 in the metadata area, and stores the value of ie_offset (241-2) in the variable offset1.

In the computer system according to the present embodiment, the metadata area is provided in LDEVa (LDEVb), and the device file for accessing LDEVa (LDEVb) is “sddlma”. Therefore, in step 1041, the file system program 302 issues a read request for “sddlma”. This read request is received by the path replacement software 303, and the path replacement software 303 executes reading to LDEVa (LDEVc). In

steps

1042 and 1046, which will be described later, data in the metadata area is also read. Similarly to step 1041, the file system program 302 issues a read request for “sdddlma”. Details of this processing will be described later.

Subsequently, the file system program 302 reads InodeEntry of the InodeEntry block 242 (Step 1042). The read destination address at this time is the address offset1 of LDEVa (LDEVb). If the read FileName (242-2) of InodeEntry matches the file name to be accessed (step 1043: Yes), the processing after step 1045 is performed. However, if fileName (242-2) is different from the file name to be accessed (step 1043: No), the file system program 302 adds the size of InodeEntry to the variable offset1 (step 1044), and executes the processing of step 1042 again. To do. Steps 1042 to 1044 are repeated until an InodeEntry whose fileName (242-2) matches the file name to be accessed is found. When all the InodeEntry are searched, but the InodeEntry whose fileName (242-2) matches the name of the file to be accessed is not found, the file system program 302 returns an error to the calling program.

In step 1045, the file system program 302 specifies the address at which the Inode to be read is stored based on i_no (242-1) included in the found InodeEntry. The storage address of the inode where i_no (242-1) is N is
“I_offset (241-3) + Inode size × N”
Can be specified. The file system program 302 stores the address specified here in the variable offset2.

In step 1046, the file system program 302 reads the data from the address offset2 of the device file sddlma to acquire the Inode of the access target file, and ends the process.

Next, the flow of file write processing executed by the file system program 302 will be described with reference to FIG. Here, the flow of processing when data is overwritten (updated) on a file that has already been written to the file system (hereinafter referred to as “file before update”) will be described. . In order to prevent the description from becoming redundant, an example will be described in which the size of the write data is within the range of the area where the pre-update file is stored (file size expansion does not occur).

First, the file system program 302 receives information (offset, size) of the write position of the file descriptor and write data from the calling program (step 1201). In step 1201, the file system program 302 further searches the memory 32 to identify a file structure including a file descriptor having the same value as the received file descriptor. Thereby, the inode information of the access target file can be obtained.

Next, the file system program 302 receives write data from the calling program and calculates the write data write position (step 1202). The write data write start address is obtained by adding the offset received in step 1201 to the offset (243-2) included in the Inode. The write data write range is equal to the size received in step 1201.

Subsequently, the file system program 302 updates information in the Inode stored in the memory 32 (step 1203). Specifically, 1 is added to the value of prechk (243-4). Further, offset (243-2) and size (243-3) are updated when it is necessary to change (when the file size is enlarged or reduced, or when the file storage position is changed).

In step 1204, the file system program 302 writes the inode information updated in step 1203 in the metadata area. If the inode has been successfully written (step 1205: Yes), the processing from step 1206 is performed. If the inode writing has failed (step 1205: No, this is a case where an error is returned from the path replacement software 303), the file system program 302 notifies the calling program of the error (step 1209). The process is terminated.

Subsequently, in step 1206, the file system program 302 writes the write data in the actual data area. If the write data has been successfully written (step 1207: Yes), the file system program 302 notifies the calling program that the process has been completed normally (step 1208), and the process is terminated. If it fails, the file system program 302 notifies the calling program of an error (step 1209) and ends the process.

As described above, the actual data is stored with prechk 251 added. Therefore, in step 1206, the file system program 302 adds the information of prechk (243-4) updated in step 1203 to the head of the write data, and then writes it in the actual data area. If the processes of steps 1204 and 1206 are normally performed, prechk (243-4) included in the Inode stored in the Inode block 243 and prechk (251) added to the file actual data stored in the actual data area. Will have the same value.

Note that, here, it has been described that the inode is written in the metadata area (step 1204) and then the actual data area is written (step 1206), but this order may be reversed.

In the computer system according to the present embodiment, the actual data area is provided in LDEVc (LDEVe), and the device file for accessing LDEVc (LDEVe) is “sddlmb”. Therefore, in steps 1204 and 1206, the file system program 302 issues a write request for “sddlmb”. This write request is received by the path replacement software 303, and the path replacement software 303 executes reading to LDEVc (or LDEVe).

Subsequently, the processing performed in

steps

1041, 1042, 1046, 1204, and 1206 of the processing described above, that is, the file system program 302 makes an access request (read request or write request) to the device file (sddlmma or sddlmb). The flow of processing performed by the path replacement software 303 and the device driver 304 when issuing the command will be described with reference to FIG.

Hereinafter, the case where the device file to be accessed is “sddlma” and the state of the alternate path management table 330 is the state shown in FIG. 5 will be described as an example. In step 2001, the path replacement software 303 refers to the line “sddlma” in the DM device file 502 of the replacement path management table 330. Referring to this line, it can be seen that scsi device files “sda” and “sdb” are mapped to the device file “sddlma”. The path replacement software 303 selects one to be used from the two scsi device files. The path replacement software 303 according to the present embodiment performs selection by the following method.

The path replacement software 303 confirms the attributes 503, the copy method 504, and the access status 505 of each scsi device file (“sda” and “sdb”), and selects an scsi device file whose access status 505 is 0 (normal). However, when there are a plurality of scsi device files whose access status 505 is 0, the copy method 504 is confirmed. When the copy method 504 is “1”, an scsi device file having an attribute 503 of 0 is selected. On the other hand, when the copy method 504 is “0”, any scsi device file may be selected.

Referring to the alternate path management table 330 in FIG. 5, the attribute 503, the copy method 504, and the access status 505 of the scsi device file “sda” are “0”, “synchronization”, and “0”, respectively. On the other hand, the attribute 503, copy method 504, and access state 505 of the scsi device file “sdb” are “1”, “0”, and “0”, respectively. In this case, any scsi device file may be selected. Hereinafter, a case where the device file “sda” is selected will be described as an example.

In step 2002, the path replacement software 303 reads or writes the scsi device file (“sda” in the above example) selected in step 2001. When reading or writing is performed on the scsi device file “sda”, the device driver 304 is called. The device driver 304 recognizes that the LDEVa in the storage apparatus 20a is mapped to the scsi device file “sda” by referring to the scsi block mapping table 340. Therefore, an access command (read command or read command) is sent to the LDEVa. Write command) is issued (step 2003).

In step 2004, the device driver 304 receives a response to the access command issued in step 2003 from the storage apparatus 20. When the response indicating that the access command processing is successful is received (step 2004: Yes), the device driver 304 returns a response indicating that the processing is successful to the calling program (that is, the path replacement software 303). Further, the path replacement software 303 returns a response indicating that the process is successful to the file system program 302 (step 2005), and ends the process. If the access request received from the file system program 302 is a read request, the read data is returned to the file system program 302 together with a response indicating that the processing has been successful.

When the device driver 304 receives a response indicating that the access command processing has failed (step 2004: No), the device driver 304 returns a response indicating that an error has occurred to the path replacement software 303. Upon receiving this response, the path replacement software 303 changes the access state 505 of the scsi device file “sda” to “1” (step 2006).

In step 2007, the path replacement software 303 refers to the alternate path management table 330 and confirms whether the access states 505 of the scsi device files (“sda” and “sdb”) are both “1”. If both the access states 505 of the scsi device files (“sda” and “sdb”) are “1”, the path replacement software 303 returns a response indicating that an error has occurred to the file system program 302 (step 2008). The process is terminated.

In step 2007, as a result of referring to the access state 505 of the scsi device file (“sda” and “sdb”), if either one is “0”, the path replacement software 303 executes step 2001 again. Therefore, for example, when the access to the scsi device file “sda” fails in the first access, but the access state 505 of “sdb” is “0”, the path replacement software 303 gives an error to the file system program 302. Steps 2001 to 2003 are executed again without returning. Therefore, even when access to the scsi device file “sda” (that is, access to LDEVa) fails, the file system program 302 can be changed to the LDEVb as the access destination LDEV without stopping.

FIG. 11 shows a flow of write processing including processing performed in the storage apparatus 20. The flow shown in FIG. 11 is a flow of processing when LDEVa and LDEVc are normal and no error occurs during processing. In FIG. 11, the flow of processing after step 1204 in FIG. 9 is described.

When the file system program 302 receives a write request from the AP executed by the client 40 (Op. 001), the file system program 302 writes to the device file “sddlm” (Op. 003) and moves to the device file “sddlmb”. Is written (Op.004). Op. 003 corresponds to step 1204 in FIG. 004 is a process corresponding to step 1206.

When the path replacement software 303 receives writing to the device file “sddlma”, it issues a write request to “sda” (Op. 005). When the path replacement software 303 receives writing to the device file “sddlmb”, it issues a write request to “sdc” (Op.006). Op. 005, Op. The process of 006 is a process corresponding to

steps

2001 and 2002 in FIG.

When the device driver 304 receives a write to the device file “sda”, the device driver 304 issues a write command to the LDEVa (Op.007). When the device driver 304 receives a write to the device file “sdc”, the device driver 304 issues a write command to the LDEVc ( Op.008). This process corresponds to step 2003 in FIG.

When the storage device 20a receives a write command for the LDEVa, the storage device 20a stores the write data in the LDEVa and instructs the storage device 20b to write the write data to the LDEVb (Op.009). This is because LDEVa and LDEVb are set to perform remote copy in the synchronous copy mode. When the storage device 20a receives a response from the storage device 20b indicating that the writing to the LDEVb has been completed (Ret.009), the storage device 20a returns a write completion response to the host 30 (device driver 304) (Ret.007). This response is sent back to the file system program 302 via the path replacement software 303 (Ret.005) (Ret.003).

When the storage device 20a receives a write command for the LDEVc, the storage device 20a stores the write data in the LDEVc (Op.008). When the storage of the write data to the LDEVc is completed, the storage apparatus 20a returns a write completion response to the host 30 (device driver 304) (Ret.008). This response is returned to the file system program 302 via the path replacement software 303 (Ret.006) (Ret.004). Since LDEVc and LDEVe are set to perform remote copy in the asynchronous copy mode, the storage apparatus 20a also performs data copy to LDEVe, which is independent of the response to the host 30 (Ret.008). (Op. 010).

In the example of FIG. 11, the response (Ret.004) for writing to the device file “sddlmb” arrives at the file system program 302 earlier than the response (Ret.003) for writing to the device file “sddlmma”. Yes. This is an example, and the response Ret. 003 is a response Ret. It may happen that the file system program 302 arrives earlier than 004. However, when writing to the device file “sddlmb” is performed, a response is returned to the host 30 without waiting for the write data to be written to the LDEV of the storage apparatus 20b (Ret. 008). Therefore, the response Ret. 004 is a response Ret. It may happen that the file system program 302 arrives earlier than 003. Further, since the storage device 20 performs copying to the LDEVe in the asynchronous copy mode, the response time of the host 30 can be shortened.

If the storage device 20a returns a response to the host 30 after confirming that it has been written to the LDEV of the storage device 20b, the response (Ret. 004) is returned to the file system program 302 at least Ret. . After 010. In that case, the response time of the client deteriorates (becomes longer). In particular, when the storage device 20a and the storage device 20b are installed in geographically distant places and the communication path 70 is long, the deterioration of the response time becomes so large that it cannot be ignored. In general, the actual data of a file is larger in size than metadata (Inode), and therefore the influence on the response time due to the increase in the distance of the communication path 70 is great. Therefore, if the asynchronous copy mode is used for data copy of the LDEV that stores the actual data of the file as in the computer system according to the present embodiment, the access response time can be shortened.

Next, the processing flow of the computer system when a failure occurs in the storage device 20a will be described. For example, it is assumed that writing to LDEVa and LDEVc succeeds, but a failure occurs in the storage apparatus 20a after that, and writing to LDEVe does not succeed. This is described in Ret. 007, and Op. This is a case where a failure has occurred before (or during) 010.

This case will be described with reference to FIG. In this case, the storage apparatus 20a responds to the host 30 that writing to the LDEVa and LDEVc has been completed (Ret.007, Ret.008). Therefore, the file system program 302 recognizes that the write process requested by the client 40 has been completed normally, and responds to the client 40 that the write process has been completed normally (Ret. 001). However, if a failure occurs in the storage apparatus 20a thereafter, writing to the LDEVe (Op. 010) is not executed. Therefore, the latest data (the same data as the data written to LDEVc) is not written in LDEVe.

After that, when the client 40 issues a read request to the host 30 in order to access the file, the storage apparatus 20a is in an inaccessible state, so the host 30 reads data from the LDEVb and LDEVe of the storage apparatus 20b. . However, since the latest data is not written in the LDEVe, if the host 30 performs data reading from the LDEVe, erroneous (not latest) data may be read out.

In the computer system according to the present embodiment, erroneous (not up-to-date) data is prevented from being read by performing the processing described below when reading a file. The flow of read processing executed by the file system program 302 will be described with reference to FIG. Prior to the read process described below, the file system program 302 performs the file open process shown in FIG. 7 to acquire an Inode from the storage apparatus 20. As described above, Inode is read from LDEVa in the course of the file open process, but when storage device 20a (LDEVa) cannot be accessed (read), reading is performed from LDEVb. The description of the file open process is omitted below.

The file system program 302 receives a read request from the AP of the client 40 via the file service daemon 301 and also receives information (offset, size) of the file descriptor and read data storage position of the read target file (step 1401). ). Here, similar to the processing in step 1201, the file system program 302 uses the file descriptor to obtain the inode information of the access target file.

Subsequently, the file system program 302 calculates the storage location of the read data, and executes the read for the device file “sddlmb” (step 1402). Similar to step 1204, the storage address of the read data is obtained by adding the offset received in step 1401 to the offset (243-2) included in the Inode. The lead range is equal to the size received in step 1401. Further, when the read for the device file “sddlmb” is executed, the processing of FIG. 10 is performed.

In step 1402, when the reading of the device file “sddlmb” is successful (step 1403: Yes), the processing from step 1404 is performed. On the other hand, when the reading of the device file “sddlmb” has failed (step 1403: No), the file system program 302 notifies the calling source program of an error (step 1410) and ends the processing. The case where reading of the device file “sddlmb” has failed is a case where both of the LDEVc and LDEVe cannot be accessed, for example, when both the

storage apparatuses

20a and 20b are stopped.

In step 1404, the file system program 302 compares the contents of prechk 251 added to the actual data read in step 1402 and prechk (243-4) included in the Inode. If both are the same value (step 1404: Yes), the file system program 302 returns the actual data to the caller program, responds that the read process has been completed normally (step 1405), and ends the process. . If both are different values (step 1404: No), the file system program 302 returns an error to the calling program and ends the processing (step 1420).

In the processing of FIG. 12, an example in which access to the LDEVc has failed (because a failure has occurred in the storage device 20a), but the LDEVe is in an accessible state will be described. In this case, the determination at step 1403 is Yes, and the file system program 302 performs the processing after step 1404.

In the file write process performed before the read process, it is assumed that writing to the LDEVc and LDEVe has succeeded, and then the storage device 20a has failed and the LDEVc cannot be read. In this case, the prechk (243-4) included in the Inode stored in the LDEVa (or LDEVb) and the prechk 251 included in the actual data stored in the LDEVe are file write processing performed before the read processing. Both have been updated. Therefore, in this case, the determination in step 1404 is Yes, and the file system program 302 returns actual data to the calling program.

On the other hand, if a failure occurs in the storage apparatus 20a during the file write process performed before the read process and writing to the LDEVe is not successful, the prechk 251 included in the actual data stored in the LDEVe is updated. Not. Therefore, the value of prechk (243-4) included in Inode stored in LDEVb is different from the value of prechk 251 included in actual data stored in LDEVe. In such a case, the file system program 302 returns an error to the caller program (file service daemon 301). The file system program 302 operates so as to return read data to the calling program only when the contents of prechk 251 and prechk (243-4) are the same, and therefore erroneous (not correctly updated) data. Can be prevented from being read out.

The above is the description of the first embodiment. The computer system according to the first embodiment stores the actual data of a file in a volume pair where asynchronous remote copy is performed, and stores the inode (metadata) of the file in a volume pair where synchronous remote copy is performed. As a result, in the event of a failure in the storage apparatus, it is possible to continue business using the storage apparatus in which the copy is stored. In addition, since real data (larger than metadata) is replicated to two storage apparatuses by asynchronous remote copy, the response time at the time of file write can be shortened.

Since the asynchronous remote copy is used in the computer system according to the first embodiment, when a failure occurs in the storage device (primary volume) immediately after the actual file data is written to the primary volume, the latest data ( The same data as the data written to the primary volume may not be stored. In the computer system according to the first embodiment, the file system program assigns and stores the same check code to the actual data of the file and the Inode, and compares the two check codes when reading the file, thereby comparing the actual data and the meta data. It is determined whether or not the data is updated at the same time. If the actual data and metadata are not updated at the same time, it is determined that the latest actual data is not stored in the storage device, and an error occurs without returning the actual data to the file request source such as the client. To be notified. As a result, even when a failure occurs in the storage apparatus, it is possible to prevent erroneous (not correctly updated) data from being read.

Subsequently, Example 2 will be described. The hardware configuration of the computer system according to the second embodiment is the same as that described in the first embodiment. In the first embodiment and the second embodiment, a part of the processing of the file system program 302 and a part of the processing of the storage apparatus 20 are different. Below, it demonstrates focusing on the point. The flow of the write process executed by the computer system according to the second embodiment will be described with reference to FIG. Note that Op. 001 to Op. 010, Ret. 001 to Ret. 010 means the same processing (issue of request, return of response) as in FIG.

A file system program executed by the host 30 (hereinafter referred to as “file system program 302 ′”) reserves a partial area in the memory 32 as a cache area in advance (when the system is started). . When the file system program 302 'executes file writing (Op.003, Op.004), the actual data and additional information of the file are stored in the cache area (Op. 101). The additional information stored in the cache area together with the actual data is referred to as “cache information”. When a response to the effect that writing to LDEVa and LDEVc is completed is received from the storage device 20a (Ret.007 → Ret.005 → Ret.003, and Ret.008 → Ret.006 → Ret.004), the file system program 302 'responds to the client 40 that the write processing is completed (Ret. 001). The processing up to this point is Op. Except for 101, it is the same as that described in the first embodiment (FIG. 11).

Here, the file system program 302 ′ is Op. The contents of the cache information 400 stored in the cache area 101 will be described with reference to FIG. The cache information 400 includes s_volume_name (401), d_offset (402), d_size (403), and actual data 404.

S_volume_name (401) is LDEV information (device file name) in which actual data is written, and stores the same information as s_volume_name (241-1) included in SB241. d_offset (402) and d_size (403) are the start address of the actual data write destination and the size of the actual data, respectively. The actual data 404 also includes prechk.

Returning to the explanation of FIG. The storage apparatus 20a issues a request for copying the write data for LDEVc to the LDEVe to the storage apparatus 20b (Op. 010). When the storage of the write data in LDEVe is normally completed, the storage apparatus 20b returns a response to the storage apparatus 20a (Ret. 010). This process is also the same as that described in the first embodiment.

When the control program 201a of the storage apparatus 20a according to the second embodiment receives a write request for a volume pair for which remote copy is performed in the asynchronous copy mode, when the write data storage to the secondary volume is completed, the control program 201a It has a function of notifying the host 30. Specifically, when the storage apparatus 20a receives the response (Ret. 010) from the storage apparatus 20b, the storage apparatus 20a notifies the host 30 that the copying from the LDEVc to the LDEVe has been normally completed. Hereinafter, this notification is referred to as “remote copy completion notification”. The remote copy completion notification includes information that can identify the LDEVc (LDEV identification number and the like) and a write data write position (LBA, size).

The remote copy completion notification is received by the file system program 302 ′ via the device driver 304 of the host 30 and the path replacement software 303. In addition, the format of the notification content is changed in the process in which the remote copy completion notification passes through the device driver 304 and the path replacement software 303. Upon receiving the remote copy completion notification, the device driver 304 changes the LDEV identification number included in the notification to the scsl device file name. This can be done by referring to the scsi block mapping table 340. Similarly, when the path replacement software 303 receives a remote copy completion notification from the device driver 304, the scsl device file included in the notification is changed to a device file name. This can be done by referring to the alternate path management table 330.

The file system program 302 'refers to the content of the received remote copy completion notification and the cache information 400 stored in the cache area, and deletes the data for which the remote copy has been completed from the cache area (Op.102). Specifically, among the plurality of cache information 400, s_volume_name (401), offset (402), and size (403) are information on the device file name and data write position (LBA, size) included in the remote copy notification. The matching cache information 400 is specified, and the specified cache information 400 is deleted from the cache area.

As another embodiment, instead of sending a remote copy completion notification from the storage apparatus 20a to the host 30, whether or not the host 30 has periodically completed remote copy from the LDEVc to the LDEV to the storage apparatus 20a. You may inquire.

The flow of read processing executed by the file system program 302 'according to the second embodiment will be described with reference to FIG. Steps 1401 to 1410 are the same as the read process (FIG. 12) described in the first embodiment.

In step 1404, if the contents of prechk 251 added to the actual data read in step 1402 and prechk (243-4) included in the Inode are different (step 1404: No), the file system program 302 ′ searches the cache area and determines whether the read target data is cached (step 1412). This can be determined by comparing the offset (402) and size (403) of the cache information 400 with the storage location of the data to be read in the current read process.

When the read target data is cached (step 1412: Yes), the file system program 302 'returns the actual data included in the cache information 400 to the caller program (step 1413). Thereafter, the file system program 302 'writes the actual data included in the cache information 400 (step 1414), and the process is terminated. As a result, the actual data is written to the storage device 20 (LDEVe). When the read process is performed thereafter, the data is normally read from the LDEVe. If the read target data has not been cached (step 1412: No), the file system program 302 ′ returns an error to the calling source program and ends the processing, as in the read process described in the first embodiment ( Step 1420).

If a failure occurs in the storage apparatus 20a in the course of the file write process performed before the read process and writing to the LDEVe is not successful, the computer system according to the first embodiment is erroneous (not updated correctly). ) Although data can be prevented from being read, data read fails. In the case of the computer system according to the second embodiment, the file system program 302 ′ caches data until it is confirmed that the data has been written to the two storage apparatuses 20, so that the latest data is stored in the client 40. Can be returned.

As mentioned above, although the Example of this invention was described, this is an illustration for description of this invention, Comprising: It is not the meaning which limits the scope of the present invention only to these Examples. That is, the present invention can be implemented in various other forms.

For example, in the embodiment described above, an example in which information corresponding to the number of times of writing a file is recorded in actual data and inode prechk is described. However, the value stored in prechk is not limited to this. Information other than this may be stored as long as it can be identified that the actual data and the inode are written at the same time. For example, an error detection code such as a CRC (Cyclic Redundancy Check) code calculated using the actual data or a checksum may be stored in the actual data and inode prechk. When the error detection code is stored in the inode, it is not necessary to add the error detection code to the actual data. This is because the file system program can generate an error detection code from the actual data read from the LDEV. Then, the file system program compares the error detection code added to the inode with the error detection code generated from the actual data, and returns an error to the caller if they do not match.

20: Storage device, 30: Host, 40: Client

Claims

A host computer,
A first storage device connected to the host computer and having a first volume and a second volume;
A second storage device connected to the host computer and the first storage device and having a third volume and a fourth volume;
In a computer system having
The host computer, when storing a file in the first storage device, writes the actual data of the file to the first volume, and writes metadata including information regarding the storage location of the actual data to the second volume,
The first storage device replicates data written to the first volume to the third volume in an asynchronous copy mode, and replicates data written to the second volume to the fourth volume in a synchronous copy mode. ,
A computer system characterized by that.
The host computer executes file storage in the first storage in response to receiving a file write request from a client,
When the host computer receives a write completion response to the first volume and a write completion response to the second volume from the first storage device, it responds to the client that the file writing has been completed. ,
The computer system according to claim 1, wherein:
When the host computer cannot read data from the first storage device,
The host computer reads the metadata of the file from the fourth volume,
Read the actual data of the file from the third volume,
The computer system according to claim 2, wherein:
The host computer determines whether the latest actual data can be read using the read metadata and actual data of the file,
If the latest actual data could not be read, an error is returned to the client.
The computer system according to claim 3, wherein:
The host computer assigns the same check code to the metadata and actual data of the file, and stores it in the first storage device,
The host computer determines that the latest actual data could not be read if the same check code is not assigned to the read metadata and the actual data.
The computer system according to claim 4, wherein:
The host computer attaches an error detection code generated from the actual data to the metadata and stores it in the first storage device,
If the error detection code generated from the read actual data and the error detection code added to the read metadata do not match, the host computer has not been able to read the latest actual data. judge,
The computer system according to claim 4, wherein:
The host computer stores the file in the memory of the host computer after storing the file in the first storage device.
The computer system according to claim 1, wherein:
When the first storage device receives a write request and write data to the first volume from the host computer, it returns a write completion response to the host computer when the write data is stored in the first volume. And
When the storage of the write data in the third volume is completed, a remote copy completion notification is returned to the host computer.
The computer system according to claim 7, wherein:
When the host computer receives the remote copy completion notification, the host computer deletes the held file from the memory.
The computer system according to claim 8, wherein:
The host computer reads the actual data and metadata of the file from the first storage device or the second storage device,
Using the read actual data and metadata, determine whether the latest actual data could be read,
When the latest actual data could not be read, the file stored in the memory is returned to the request source of the file.
The computer system according to claim 7, wherein:
A host computer,
A first storage device connected to the host computer and having a first volume and a second volume;
A second storage device connected to the host computer and the first storage device and having a third volume and a fourth volume;
A computer system control method comprising:
Upon receiving a file write request, the host computer writes the actual data of the file to the first volume, and writes metadata including information regarding the storage location of the actual data to the second volume,
The first storage device replicates data written to the first volume to the third volume in an asynchronous copy mode, and replicates data written to the second volume to the fourth volume in a synchronous copy mode. ,
When the host computer receives a write completion response to the first volume and a write completion response to the second volume from the first storage device, the file writing is completed at the request source of the file write request. Reply that
A computer system control method characterized by the above.
When the host computer cannot read data from the first storage device,
The host computer reads the metadata of the file from the fourth volume,
Read the actual data of the file from the third volume,
The computer system control method according to claim 11, wherein:
The host computer determines whether the latest actual data can be read using the read metadata and actual data of the file,
If the latest actual data could not be read, an error is returned to the requester of the file.
The computer system control method according to claim 12, wherein:
The host computer assigns the same check code to the metadata and the actual data when the file is written, and stores the same check code in the first storage device,
The host computer determines that the latest actual data could not be read if the same check code is not given to the read metadata and the actual data when the file is read.
The computer system control method according to claim 13, wherein:
The host computer stores the file in the first storage device and then stores the file in the memory of the host computer until receiving a notification from the first storage device that data storage to the third volume is completed. Keep files,
The computer system control method according to claim 11, wherein: