Network storage system with a clustered configuration sharing a namespace, and control method therefor

Provided is a storage system as follows. A server holds a management table that serves to manage a mount point of a file system. The management table stores a file system identifier that uniquely identifies the file system within the storage system, mount point information that indicates the mount point of the file system, and a management server identifier that indicates an identifier of the server that manages the file system. The contents stored in the management table of each server are the same. Upon reception of a request to obtain a file handle, each server returns the file handle requested to be obtained. The file handle indicates, uniquely within the storage system, the storage area on the disk subsystem in which the file relating to the request is stored.

BACKGROUND OF THE INVENTION

This invention relates to a network attached storage (NAS) having a clustered configuration.

There has been proposed a network attached storage (NAS) that is a storage system connected to a network and used as a shared disk for computers connected to the network. The NAS is composed of a server including a network interface and disk drives storing data. Further, there is disclosed a NAS that includes a plurality of servers and has a clustered configuration in which each of the servers is connected to a network (see, for example, U.S. Pat. No. 6,671,773).

In U.S. Pat. No. 6,671,773, network elements, a switching fabric, and disk elements correspond to the servers of the NAS. The plurality of network elements provided can share a file system. In addition, the plurality of disk elements provided allow migration of the file system on a disk basis.

On the other hand, a network file system (NFS) has been proposed as one of file systems that allow an access to files distributed on a network. According to NFSv4 (RFC 3530), which is the most updated version of the NFS protocol specification as of now, when a file system is migrated between servers, the migration source server responds to an access requested from a client to the file system to notify the client of information on a location of the file system at a migration destination (see the IETF home page at the Internet URL: http://www.ieff.org/home.html, (a search was made online for this specification on Nov. 11, 2004)). Therefore, the client can access the file system at the migration destination based on the notified location information. In addition, a file handle, which is an identifier used for an access, consists of two types, a volatile file handle and a persistent file handle. When the file system is migrated, the volatile file handle thereof can be set to invalid.

SUMMARY OF THE INVENTION

In the case where access loads are concentrated on a particular portion in a NAS having a clustered configuration, a possible solution is to distribute the loads by migrating a file system. However, according to U.S. Pat. No. 6,671,773, it depends on a client which a network element is connected to. As a result, even migration of the file system cannot distribute the access loads on the network element.

Also, according to the IETF home page at the Internet URL: http://www.ieff.org/home.html, for an access to the file system at the migration destination, it is necessary to perform name resolution again and obtain another file handle.

This invention has been made in view of the above-mentioned problem. In one embodiment of the invention, a storage system, including: a plurality of servers; and a disk subsystem that is coupled to the plurality of servers, the disk subsystem including: at least one logical device; and at least one file system that is stored in the at least one logical device, wherein: the servers each hold a management table that serves to manage a mount point of the file system; the management table stores a file system identifier that uniquely identifies the file system within the storage system, mount point information that indicates the mount point of the file system, and a management server identifier that indicates an identifier of the server that manages the file system, while sharing the same contents among the servers; and upon reception of a request to obtain a file handle that indicates a storage area on the disk subsystem in which data on a file within the file system is stored, the servers each return the file handle that indicates, uniquely within the storage system, the storage area on the disk subsystem in which the data on the file relating to the request is stored.

According to this invention, by migrating a file system, it is possible to distribute access loads on a server.

Further, according to this invention, for an access to a file system at a migration destination, it is possible to use a file handle that was obtained before migration of the file system. Consequently, it is unnecessary to perform name resolution again and obtain another file handle.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1is a block diagram showing a structure of a storage system according to an embodiment of this invention.

A storage system100of this embodiment is connected to a management terminal140and clients150through a LAN160.

The management terminal140is a computer that instructs the storage system100to create, mount, and migrate a file system within the storage system100. The management terminal140includes at least an input/output device (not shown) that has, for example, a management screen and a pointing device. Description will be made later inFIGS. 12 and 13of contents displayed on the management screen and an operation using the pointing device.

The client150is a computer that accesses a file in the storage system100. To be specific, the client150writes a file to the storage system100or reads a file from the storage system100. At this time, the file system of the storage system100is used.

FIG. 1shows only two clients (150A and150B), but an arbitrary number of clients may be connected to the LAN160and access the storage system100.

The LAN160is a network that performs communications via a protocol such as TCP/IP.

The storage system100is a so-called network attached storage (NAS). The storage system100is composed of a plurality of servers110, a disk subsystem120, and a storage area network (SAN)130that connects those elements to each other.

The servers110each access the disk subsystem120in response to an access request from the client150.

FIG. 1shows two servers (110A and110B). The storage system100may include more servers110. The server110is also called a NAS head or a NAS node.

The server110A is composed of a network interface111A, a CPU112A, a local memory113A, and an adapter116A.

The network interface111A is an interface that is connected to the LAN160and communicates with the management terminal140and the client150.

The CPU112A is a processor that controls an operation of the server110A. To be specific, the CPU112A executes a program stored in the local memory113A.

The local memory113A is, for example, a semiconductor memory, and stores a program executed by the CPU112A and data referenced by the CPU112A. To be specific, the local memory113A stores server software114A and a mount point control table115A.

The server software114A consists of a plurality of programs executed by the CPU112A.FIG. 3will be referenced to describe the server software114A later in detail.

The mount point control table115A is a table for managing the mount point of a file system included in the disk subsystem120. The mount point control table115A is referenced when the server110A receives an access request from the client150, and updated when a file system is added, deleted, or migrated.

The adapter116A is an interface that is connected to the SAN130and communicates with the disk subsystem120.

Similarly to the server110A, the server110B is composed of a network interface111B, a CPU112B, a local memory113B, and an adapter116B. Those elements are the same as the network interface11A, the CPU112A, the local memory113A, and the adapter116A, respectively, so description thereof will be omitted.

Even when the storage system100includes more servers110, the servers110each have the same configuration as the server110A.

The SAN130is a network that performs communications via a protocol such as Fibre Channel (FC) or SCSI, for example.

When the storage system100includes a plurality of servers110, the servers110are connected to each other through an inter-server communication path135. The servers110can communicate with each other through the inter-server communication path135. To be specific, when the contents of the mount point control table115of one server110is updated, the updated contents are sent to another server110through the inter-server communication path135. Upon reception, the server110reflects the updated contents that have been received on the mount point control table115within the server110.

In this embodiment, as shown inFIG. 1, the storage system100includes the inter-server communication path135independently of the SAN130and the LAN160. However, the servers110may communicate with each other through the SAN130or the LAN160. Alternatively, the servers110may communicate with each other by using a disk cache122of the disk subsystem120. In other words, after the mount point control table115of one server110is updated, the server110writes the updated contents to the disk cache122. Another server110reads out the updated contents written in the disk cache122, and updates each mount point control table115. This invention can be implemented regardless of which path the servers110may communicate through.

The disk subsystem120is composed of a disk controller121, the disk cache122, and disk drives123.

The disk controller121, which includes at least one port (not shown) connected to the SAN130, communicates with the servers110and controls the disk subsystem120. To be specific, the disk controller121communicates with the servers110through the SAN130, and writes or reads out data to/from the disk drives123in response to a request from the server110.

The disk cache122is, for example, a semiconductor memory, and temporarily stores the data written to or read out from the disk drive123.

The disk drives123are hard disk drives that store data. The disk subsystem120includes an arbitrary number of disk drives123. The disk drives123may configure a RAID array.FIG. 1shows four disk drives (123A to123D).

A storage areas of the disk drives123are divided into an arbitrary number of logical devices (LDEVs)124. An LDEV124is an area that is used as a logical disk drive by the disk controller121. When the disk drives123configure a RAID array, as shown inFIG. 1, an LDEV124may be defined by the storage areas of a plurality of disk drives. The size of each LDEV124is arbitrarily set.

FIG. 1shows an example of the four LDEVs (124A to124D). Each LDEV124is assigned with an LDEV identifier (ID). In the example ofFIG. 1, IDs of the LDEVs121A to124D are LDEV0to LDEV3, respectively. Hereinafter, the respective LDEVs are represented by the LDEV IDs (LDEV0to LDEV3).

FIG. 2will be referenced to describe the contents of the respective LDEVs later in detail.

The storage system100may include a plurality of disk subsystems120. In that case, the disk subsystems120are each connected to the SAN130. The servers110can access any of the disk subsystems120through the SAN130.

FIG. 2is a block diagram showing a logical structure of the disk subsystem120according to the embodiment of this invention.

As shown inFIG. 1, the disk subsystem120includes an arbitrary number of LDEVs124. The LDEVs124each have a corresponding logical unit (LU)201.

The LU201is an area used as a logical disk drive by the servers110. In general, one LDEV124may correspond to one LU201, or include a plurality of LUs201. In this embodiment, the LDEV124corresponds to the LU201in a one-to-one manner. The LDEVs124A to124D correspond to the LUs201A to201D, respectively.

The LUs201are each assigned with an LU identifier (ID).

In general, the disk controller121, which includes a plurality of ports, may have a plurality of paths through which the servers110access one LU201. The LU ID is assigned to each LU based on each path by the disk subsystem120. For example, “0” and “1” may be assigned as LU ID of the same LU201within an LDEV0based on a path A (not shown) and a path B (not shown), respectively.

The disk controller121includes a table (not shown), which associates the LU IDs with the LDEVs124, for each path. When a request to access an LU “0” is received from the server110through the path A, the disk controller121references the table and accesses the LU201within the LDEV0. Similarly, when a request to access an LU “1” is received from the server110through the path B, the disk controller121references the table and accesses the LU201within the LDEV0.

In this embodiment, the correspondences between LDEV IDs and LU IDs are shared within the storage system100regardless of the paths. In other words, the server110identifies an identical LU201based on an identical LU ID. In the example ofFIG. 2, the IDs of the LUs201A to201D are LU0to LU3, respectively. Hereinafter, the respective LUs201are represented by the LU IDs (LU0to LU3).

However, this invention can be applied to the case where the correspondences between LDEV IDs and LU IDs are not shared within the storage system100(in other words, the case where the correspondences differ among the paths).

The LUs201each include a file system (FS)202. In general, one LU201may have a plurality of file systems202. In this embodiment, one LU201has one file system202. The file systems202A to202D are included in the LU0to the LU3, respectively.

The file systems202are each assigned with a file system identifier (ID). In the example ofFIG. 2, the IDs of the file systems202A to202D are FS0to FS3, respectively. Hereinafter, the file systems202are represented by the file system IDs (FS0to FS3).

FIG. 3shows an explanatory diagram of a configuration of the server software114according to the embodiment of this invention.

The server software114includes programs that are executed by the CPU112and consist of a network processing module301, a file system processing module302, a disk access module303, a device number control module304, a server management processing module305, an inter-server communication processing module306, and a migration processing module307.

The network processing module301is a program for controlling communications through the LAN160with respect to the management terminal140and the clients150.

The file system processing module302is a program for processing a request to access from the client150to a file within the file system202. To be specific, for example, according to an instruction from the management terminal140, the file system processing module302creates a new file system. In addition, for example, when a request to obtain a file handle, as shown inFIG. 6, which designates a directory name or a file name, is received from the client150, the file system processing module302performs name resolution and returns the file handle.FIG. 9will be referenced to describe a processing executed by the file system processing module302later in detail.

The disk access module303is a program for executing an access to data within the file system202in response to the access request from the client150.

The device number control module304is a program for obtaining the LDEV ID from the disk subsystem120. The LDEV ID is an identifier assigned to the LDEV124to be managed by the disk subsystem120. Thus, generally, the servers110have no need to know the LDEV ID. However, the LDEV ID is uniquely determined within the disk subsystem120regardless of which server110accesses the disk subsystem120. Therefore, by using the LDEV ID as a file system ID, as shown inFIG. 6, within a file handle or a portion of the file system ID, it is possible that the file system202is uniquely identified by all the servers110. The device number control module304makes an inquiry to the disk subsystem120and obtains the LDEV ID.

The server management processing module305is a program for communicating with the management terminal140to set a NAS. For example, upon reception of an instruction to create a new file system from the management terminal140, the server management processing module305passes the instruction to the file system processing module302and causes the creation of a new file system to be executed. In addition, upon reception of an instruction of migration from the management terminal140, the server management processing module305passes the instruction to the migration processing module307and causes the migration to be executed.

The inter-server communication processing module306is a program for controlling communications between the servers110through the inter-server communication path135. For example, when the contents of the mount point control table115is updated, the inter-server communication processing module306sends the updated contents to another server110.

The migration processing module307is a program for executing migration.FIG. 10is used for the specific description later in detail.

FIG. 4is an explanatory diagram of the mount point control table115according to the embodiment of this invention.

The mount point control table115is a table used for managing a mount point of the file system202included in the disk subsystem120, and includes a file system ID401, a path402, and a server ID403.

One entry (row) of the mount point control table115corresponds to one file system202.

The file system ID401is the ID of the mounted file system202. In the example ofFIG. 4, four file systems202(FS0to FS3) are mounted. In this invention, the file system ID401needs to be unique within the storage system100.

As in this embodiment, when one LDEV124has only one file system202and has an LDEV ID unique within the storage system100, the LDEV ID may be used as the file system ID401. In this case, the device number control module304obtains the LDEV ID from the disk subsystem120. The file system processing module302uses the LDEV ID, which has been obtained by the device number control module304, as the file system ID401.

In the above-mentioned case, when one LDEV124corresponds to one LU201and when the correspondences between the LDEVs and the LU IDs are shared on all the paths, the LU ID may be used as the file system ID401.

In contrast, when one LDEV124has a plurality of file systems202and when the file systems202are each assigned with a file system number unique within the LDEV124, the combination of an LDEV ID unique within the storage system100and the above file system number may be used as the file system ID401.

When the storage system100includes a plurality of disk subsystems120, there may exist a plurality of LDEVs124having the same LDEV ID within the storage system100. In this case, the combination of an LDEV ID (and a file system number) and an identifier of the disk subsystem120may be used as the file system ID401. The identifier of the disk subsystem120is used for uniquely identifying each of the disk subsystems120within the storage system100.

It should be noted that the file system ID401may be created by any method other than the above-mentioned methods as long as the file system ID401uniquely identifies the file system202within the storage system100.

For example, the servers110hold the same numerical value, and when one of the servers110creates a new file system202, the numerical value is used as the file system ID401. At this time, the numerical value is updated into a value incremented by “1”, all the other servers110are notified of the updated numerical value. The server110to subsequently create another new file system202uses the updated numerical value as the file system ID401. As a result, the file system ID401becomes unique within the storage system100.

The path402indicates a mount point of each file system202. In the example ofFIG. 4, an FS0is mounted under “/dira”. Similarly, an FS1, an FS2, and an FS3are mounted under “/dirb”, “/dirc/subdir1”, and “/dirc/subdir2”, respectively.FIG. 5will be referenced to describe a namespace, which is provided when the file systems are mounted as shown inFIG. 4, later in detail.

The server ID403is a unique identifier of the server110that manages each file system202. Each server110can access only the file system202managed by the server110itself. In other words, for accessing a file, the client150needs to issue an access request to the server110that manages the file system202including the file.

In the example ofFIG. 4, “sid1” is an ID of the server110A, and “sid2” is an ID of the server110B. In other words, the FS0and FS1are managed by the server110A, and the FS2and FS3are managed by the server110B.

When the file system202is migrated, the contents of the server ID403are updated. For example, when the FS0is migrated from the server110A to the server110B, the server ID403of the FS0is updated from “sid1” into “sid2”. In addition, a notification of the updated contents is sent to all the servers110within the storage system100through the inter-server communication path135. The servers110that have received the notification each update the mount point control table115according to the notification. As a result, the mount point control tables115of all the servers110have the same contents.

FIG. 5is an explanatory diagram of the namespace provided to the client150according to the embodiment of this invention.

FIG. 5shows an example of the namespace provided when the file systems202are mounted as shown inFIG. 4.FIG. 5shows only minimum directories and files that are necessary for explanation, but the file systems202may include more directories and files.

InFIG. 5, the FS0has a directory “df11” and a directory “df12” under the highest directory, and has a file “file1” under the directory “df11”.

According toFIG. 4, the FS0is mounted under “/dira”. Therefore, the highest directory of the FS0is a directory “dira” under a directory “/” (root directory). At this time, the path to the “file1” is “/dira/df11/file1”.

Similarly, the FS1has a directory “df21” and a directory “df22” under the highest directory, and has a file “file2” under the directory “df21”. As shown inFIG. 4, the FS1is mounted under “/dirb”. Therefore, the highest directory of the FS1is a directory “dirb” under the root directory. At this time, the path to the “file2” is “/dirb/df21/file2”.

The FS2has a directory “df31” and a directory “df32” under the highest directory. As shown inFIG. 4, the FS2is mounted under “/dirc/subdir1”. Therefore, the highest directory of the FS2is a directory “subdir1” under a directory “dirc” further under the root directory.

The FS3has a directory “df41” under the highest directory. As shown inFIG. 4, the FS3is mounted under “/dirc/subdir2”. Therefore, the highest directory of the FS3is a directory “subdir2” under the directory “dirc” further under the root directory.

Since the mount point control tables115of the servers110have the same contents, the servers110provide the same namespace, as shown inFIG. 5, to the client150.

InFIG. 5, the root directory and the directory “dirc” are defined for providing a shared namespace in which the FS0to FS3are mounted. Those directories do not correspond to a storage area on the disk subsystem120, so files (data) cannot be stored directly under those directories. Therefore, in the namespace ofFIG. 5, an area including the root directory and the directory “dirc” is called “pseudo file system”. On the other hand, the FS0to FS3may be called “real file systems” in contrast to the pseudo file system.

Each server110is capable of name resolution within the pseudo file system and name resolution within the corresponding real file system that is managed by the server110.

For example, the server110A manages the FS0, and the server110B manages the FS1. When the server110B receives a request to access “/dira/df11/file1”, the server110B can perform name resolution for the root directory, but cannot perform name resolution for the directory “dira”. At this time, the server110B references the mount point control table115to notify the client150that has issued the access request that the directory “dira” is under management of the server110A.FIG. 9will be referenced to describe the above procedure later in detail.

FIG. 6is an explanatory diagram of a file handle according to the embodiment of this invention.

The file handle is an identifier having a fixed length, which is assigned to each file (or directory) in a network file system (NFS). The file handle indicates a storage area on the disk subsystem120that stores data on the file.

A file handle600is composed of three fields consisting of a file system ID601, i-node number602, and a generation603. Of those fields, the i-node number602and the generation603are the same as in a file handle used in a conventional NFS, so detailed description thereof will be omitted.

The file system ID601uniquely identifies the file system202to which a file belongs within the storage system100. The file system ID601is created by the file system processing module302upon name resolution.

The file system ID601may be created in the same manner as the file system ID401, as shown inFIG. 4, of the mount point control table115. However, the file system ID601does not need to be the same as the file system ID401as long as the file system202is uniquely identified within the storage system100.

As described above, the file system ID601uniquely identifies each file system202within the storage system100. As a result, a storage area on the disk subsystem120, which stores the data on each file, is uniquely indicated within the storage system100by the file handle600.

FIG. 7is an explanatory diagram of an outline of a processing executed according to the embodiment of this invention.

The configuration and logical structure shown inFIG. 7is the same as the configuration and logical structure shown inFIGS. 1 and 2. However, unnecessary portions are omitted for explanation.

InFIG. 7, first, the FS0and the FS1are both under management of the server110A (hereinafter, referred to as “server1”). Accordingly, before accessing a file (for example, the “file2” ofFIG. 5) within the FS1, the client150issues a request to obtain a file handle of the target file “file2” to the server1. The server1performs name resolution in response to the request to obtain a file handle, and returns the file handle600of the target file “file2” to the client150. Hereinafter, for accessing the target file, the client150issues the access request to the server1using the obtained file handle600. The server1accesses the “file2” according to the file handle600, and responds to the client150.

After that, the FS1is migrated from the server1to the server110B (hereinafter, referred to as “server2”) (701). The purpose of the migration is, for example, distribution of access loads. When the access loads on the server1is high and when the access loads on the server2is low, the FS1, which is one of the two file systems202managed by the server1, is placed under management of the server2, thereby distributing the access loads on the servers110.

As a result, the FS1is released from under management of the server1and placed under the management of the server2. At this time, in the mount point control table115, the server ID403corresponding to the FS1is updated from “sid1” (the ID of the server1) into “sid2” (the ID of the server2). After that, the server1cannot access files within the FS1.

Migration is executed according to an instruction from the management terminal140, so the client150does not know that the migration has been executed. Therefore, for accessing the “file2” again, the client150uses the file handle600, which has already been obtained, to issue an access request to the server1(702).

The server1references the file system ID601of the file handle600received from the client150and determines that the access request has been made for the FS1. Further, the server1references the server ID403corresponding to the FS1in the mount point control table115. Since the referenced server ID403has a value of “sid2”, the server1determines that the FS1is under management of the server2. Then, the server1sends to the client150a notification that the FS1including the target file “file2” is under management of the server2(703).

Upon reception of the notification from the server1, the client150issues a request to access the “file2” to the server2(704).

At this time, in the conventional NFS, the client150needs to issue the request to obtain a file handle of the target file “file2”, and obtain a new file handle600of the “file2”.

However, according to this invention, as shown inFIG. 5, the server1and the server2share the namespace, and the file system ID601included in the file handle600uniquely identifies each file system202within the storage system100. Therefore, the client150can issue a request to access the “file2” to the server2by using the file handle600obtained from the server1. The server2accesses “file2” according to the file handle600and responds to the client150.

Hereinafter, detailed description will be made of the processing executed according to the embodiment of this invention.

FIG. 8is a flowchart of a file system creating processing executed according to the embodiment of this invention.

The file system creating processing is executed by the file system processing module302. As described later, the file system creating processing is composed of three stages consisting of a new allocation processing (801to804) for an LDEV124, a new creation processing (805to807) for a file system202, and a mount processing (808to810).

When an instruction to create a new file system202is received from the management terminal140, the file system processing module302may execute the three stages in order. Alternatively, the file system processing module302may execute the steps801to804upon reception of an instruction to allocate a new LDEV124from the management terminal140, execute the steps805to807upon reception of an instruction to create a new file system202, and execute the steps808to810upon reception of a mount instruction.

When the file system creating processing starts, the file system processing module302first judges whether a new LDEV124needs to be allocated (801). For example, when the management terminal140issues the instruction to allocate a new LDEV124, and when the LDEV124in which a new file system202is to be created is not allocated, it is judged that a new LDEV124needs to be allocated.

When it is judged that a new LDEV124does not need to be allocated, the procedure advances to the step805.

On the other hand, when it is judged that a new LDEV124needs to be allocated, the file system processing module302establishes connection to a LDEV124designated by the management terminal140(802). To be specific, the file system processing module302causes the LDEV124designated by the management terminal140to be recognized by an operating system (OS) on the server110.

Then, the LDEV ID of the newly-allocated LDEV124is obtained (803). To be specific, the device number control module304, which has received the instruction from the file system processing module302, obtains the LDEV ID from the disk subsystem120. The LDEV ID may be used for creating the file system ID601of the file handle600and the file system ID401of the mount point control table115.

Then, the file system processing module302formats the newly-allocated LDEV124(804).

Next, the file system processing module302judges whether a new file system202needs to be created (805). For example, it is judged that a new file system202does not need to be created in the case where a file system202has already been created in the LDEV124newly allocated in the steps801to804, and where the file system202is to be used.

When it is judged that a new file system202does not need to be created, the procedure advances to the step808.

On the other hand, when it is judged that a new file system202needs to be created, the file system processing module302creates a new file system202in the LDEV124designated by the management terminal140(806).

Then, the file system processing module302assigns the file system ID401to the newly-created file system202(807). As described later with reference to the step810, the assigned file system ID401is stored in the mount point control table115. In the step807, the file system ID401is created as described with reference toFIG. 4.

Next, the file system processing module302creates a mount point (808). To be specific, the file system processing module302creates a directory to which the newly-created file system202is mounted. For example, inFIG. 5, when the FS0is newly created, the directory “/dira” to which the FS0is mounted is created. It should be noted that a directory to which the newly-created file system202is mounted is designated by the management terminal140.

Then, the file system processing module302mounts the newly-created file system202to the mount point created in the step808(809). To be specific, the file system processing module302reads out management information (not shown) on the file system202from the disk drive123, and sets the access to the file system202to valid.

Then, the file system processing module302updates the mount point control table115(810). To be specific, the file system processing module302adds a new entry to the mount point control table115. The new entry has the file system ID401set to the file system ID401created in the step807, the path402set to the directory created in the step808, and the server ID403set to the identifier of the server110that manages the newly-created file system202.

Further, in the step810, the file system processing module302notifies the other servers110of the updated contents of the mount point control table115. The notification is sent by the inter-server communication processing module306that has received the instruction from the file system processing module302. Each server110that has received the notification updates the mount point control table115within the server110based on the contents of the notification.

After the above-mentioned procedure, the file system creating processing ends.

FIG. 9is a sequential diagram of a file access processing executed according to the embodiment of this invention.

Here, for convenience, description will be made by using an example case where the client150accesses the “file2” ofFIG. 5through the server2. The FS1including the “file2” is initially managed by the server1. However, without its knowledge, the client150intends to access “file2” through the server2.

The client150first issues a request to obtain a file handle of the root directory to the server2(901).

The root directory belongs to the pseudo file system. Therefore, both server1and server2are capable of name resolution of the root directory. The server2performs the name resolution of the root directory and returns the file handle600of the root directory to the client150(902).

Of directories included in the path leading to the target file, when a directory belonging to the pseudo file system exists under the root directory, the client150issues the request to obtain a file system with respect to such a directory (903). The server2returns the file handle600to the request (904). When there exist a plurality of such directories, the same procedure as the steps903and904is repeated with respect to such a directories. It should be noted that “lookup” shown inFIG. 9represents a command that requests to obtain a file handle.

In the example ofFIG. 5, the directory lower than the root directory by one level is the “dirb”. The “dirb” is a mount point for the FS1(in other words, the highest directory of the FS1). On the path to the “file2”, there exists no directory belonging to the pseudo file system under the root directory. Therefore, for accessing the “file2” ofFIG. 5, the client150issues the request to obtain a file handle of the directory “dirb” subsequently to the step902(905).

In the step905, the client150issues the request to obtain a file handle of the directory “dirb” to the server2. However, the real file system FS1to which the “dirb” belongs is under management of the server1, the server2cannot perform name resolution of the “dirb”. The server2references the mount point control table115for the path402relating to the FS1to send to the client150a notification that the “dirb” is under management of the server1(906).

The client150receives the notification of a file system location of the step906, and then issues the request to obtain a file handle of the directory “dirb” to the server1(907). The server1returns the file handle600of the directory “dirb” to the client150(908).

Similarly, the client150issues requests to obtain file handles of the directory “df21” and the “file2” to the server1, and the server1returns the file handles to the respective requests (not shown). As a result, the client150obtains the file handle of the “file2”.

Next, the client150uses the file handle600of the “file2” to issue a file access request to the server1(909). In response to the request, the server1accesses “file2” of the FS1and responds to the client150(910).

After that, when the need arises for accessing the “file2”, the client150uses the file handle600obtained in the step908to access the “file2” through the server1(909,910).

Next, the FS1is migrated from the server1to the server2(911). As a result, in the mount point control table115, the value of the server ID403corresponding to the FS1is updated into “sid2” (ID of the server2).FIG. 10will be referenced to describe the procedure of the migration later in detail.

At this time, the client150does not know that the FS1has been migrated. Therefore, when the need arises to for accessing the “file2”, the client150issues to the server1a file access request using the file handle600obtained in the step908(912).

At this time, the FS1to which the “file2” belongs is not under management of the server1. Therefore, the server1cannot access the “file2”. The server1references the file system ID601of the file handle600and the file system ID401and server ID403of the mount point control table115to send to the client150a notification that the FS1has been migrated to the server2(913).

The client150receives the notification and issues to the server2a file access request to access the “file2” (914).

Conventionally, at this time, similarly to the steps901to906, it is necessary that the client150issue the request to obtain a file handle to the server2and that the server2perform name resolution.

However, according to this invention, the servers110share a namespace, and the file handle600is uniquely determined within the storage system100. Therefore, in the step914, the client150may use the file handle600used in the steps909and912as it is.

In response to the file access request from the client150, the server1accesses the “file2” of the FS1and responds to the client150(915).

FIG. 10is a flowchart of a migration processing executed according to the embodiment of this invention.

FIG. 10shows an example of a procedure of migration of the FS1from the server1to the server2, which is executed in the step911ofFIG. 9. The migration processing ofFIG. 10is executed by the migration processing modules307of the server1and the server2.

First, description will be made of the migration processing executed by the migration processing module307on the server1(in other words, a migration source).

In response to a migration instruction from the management terminal140, the server1starts the migration processing (1001). The migration instruction includes the file system ID of a file system202to be migrated and the server ID of a migration destination server110.

In the example ofFIG. 10, the file system202to be migrated is the FS1. The migration destination server110is the server2.

When the migration processing starts, the server1first sends to the server2a notification that the migration processing has started (1002). The notification includes the file system ID of a file system202to be migrated.

The notification is sent through the inter-server communication path135by the inter-server communication processing module306that has received the migration instruction from the migration processing module307.

After execution of the step1002, the server1receives from the client150the request to obtain a file handle or the file access request for a file (for example, “file2”) within the FS1, and then returns a file system location notification to the client150in the step906or913ofFIG. 9. The server1may reference the migration instruction from the management terminal140to return the migration destination server ID to the client150.

Then, the server1updates the mount point control table115(1003). To be specific, in the mount point control table115, the value of the server ID403corresponding to the FS1is updated from “sid1” (ID of the server1) into “sid2” (ID of the server2).

The server1notifies all the other servers110within the storage system100, of the updated contents of the mount point control table115. The notification is sent by the inter-server communication processing module306that has received the migration instruction from the migration processing module307. Each server110that has received the notification updates the mount point control table115within the server110based on the notified contents.

Then, the server1writes dirty data to the disk drive123(1004). In other words, when data on a file belonging to the FS1is not written to the disk drive123and is written only to the disk cache122, the data is written to the disk drive123.

Then, the server1unmounts the file system202(1005). To be specific, the access from the server1to the FS1is set to invalid.

Then, the server1disconnects the LDEV124(1006). To be specific, it is made impossible that the LDEV1storing the FS1is recognized by the OS on the server1.

Then, the server1sends to the server2a notification that the migration processing has ended (1007). The notification is sent through the inter-server communication path135by the inter-server communication processing module306that has received the migration instruction from the migration processing module307.

After the above-mentioned procedure, the migration processing executed by the migration processing module307on the server1ends.

Next, description will be made of the migration processing executed by the migration processing module307on the server2(in other words, a migration destination).

In response to a migration instruction from the management terminal140, the server2starts the migration processing (1011). The migration instruction includes the file system ID of the file system202to be migrated (FS1in the example ofFIG. 10).

Then, the server2receives the migration start notification (1002) from the server1.

It should be noted that when information included in the migration instruction of the step1011is also included in the migration start notification (1002), the step1011is unnecessary. In that case, the server2receives the migration start notification from the server1, and then starts the migration processing.

When the file access request for a file (for example, “file2”) within the file system202to be migrated is received from the client150after reception of the migration start notification (1002) and before the end of mount (1014), the server2suspends the file access request or returns a temporary error (1012). The same applies to the case where the request to obtain a file handle with respect to the FS1is received.

In the case where the file access request is suspended, the server2executes the suspended access after the end of the migration processing, and responds to the client150.

In the case where the temporary error is returned, the client150issues the same file access request again after a while. Here, the term “temporary error” represents an error to notify the client150that the processing cannot be executed within a predetermined time due to an increase in loads. According to NFSv4, for example, NFS4ERR_DELAY is returned as the temporary error.

In the conventional migration processing, the migration start notification (1002) is not issued, so the server2cannot know that the server2itself is set as the migration destination until the end of migration. Therefore, when the file access request for the file system202to be migrated is received from the client150after the start of migration and before the end of migration, the server2returns a message that the desired file does not exist, which becomes an application error.

On the other hand, according to this invention, the server2knows that the server2itself is set as the migration destination by the migration start notification (1002). Accordingly, even in the case where the server2cannot access the file system202upon reception of the file access request for the file system202to be migrated, the server2knows that the access becomes possible after a while. Therefore, the server2can suspend such a file access request or return the temporary error. As a result, the application error can be avoided.

Upon reception of the migration end notification (1007), the server2connects the LDEV124(1013). To be specific, the OS on the server2is caused to recognize the LDEV124including the migrated file system202.

Then, the server2mounts the migrated file system202(1014). To be specific, the same procedure as the step809ofFIG. 8is executed.

Upon completion of the mount of the step1014, the server2starts a service for the client150(1015). To be specific, the server2starts to provide the client150with the access to the FS1. When the file access request suspended in the step1012, the access is executed.

After the above-mentioned procedure, the migration processing executed by the migration processing module307on the server2ends.

The migration processing ofFIG. 10does not copy data on the FS1itself and changes only logical connection between the server110and the FS1. However, the migration processing may be executed by copying the data through remote copy etc. The same procedure as that ofFIG. 10is executed even in that case.

For example, the migration processing may be executed by copying all data on the file system202to the newly-created LDEV124.

Here, when the file system ID601of the file handle600is determined based on the LDEV ID, the LDEV ID of a copy source LDEV124is taken over to a copy destination LDEV124. In other words, the LDEV ID of the copy destination LDEV124becomes the same as the LDEV ID of the copy source LDEV124which is used before the execution of copy. The copy source LDEV124is deleted or has its LDEV ID changed into another value. As a result, the file system ID601of the file handle600holds the same value before and after the migration. Accordingly, the same file handle600as before can be used after the migration.

Another example of copying data for migration is the case where a plurality of file systems202are stored in one LDEV124, and one of the file systems202is migrated to another server110. In this case, a file system that is not to be migrated is stored within the same LDEV124, so the migration cannot be executed by the change in logical connection. Therefore, all the data on the file system202to be migrated need to be copied to another LDEV124.

Here, when the file system ID601of the file handle600is determined based on the LDEV ID, the LDEV ID of the copy source LDEV124cannot be taken over to the copy destination LDEV124. This is because other file systems202remain in the copy destination LDEV124, which is allowed neither to be deleted nor to have its LDEV ID changed. As a result, the file system ID601of the file handle600changes before and after the migration. Accordingly, the same file handle600as before cannot be used after the migration.

Therefore, in order to implement this invention even in the case where a plurality of file systems202are stored in one LDEV124, it is necessary that the file system ID601of the file handle600be determined regardless of the LDEV ID.

It should be noted that the copy of the file system202and the takeover of the LDEV ID may be executed based on an instruction from the migration source server110or on an instruction from the migration destination server110.

FIGS. 11A and 11Bare flowcharts showing an outline of a processing executed by the client according to the embodiment of this invention.

FIG. 11Ais the flowchart of the processing executed by the client150that accesses the conventional storage system.

FIG. 11Bis the flowchart of the processing executed by the client150that accesses the storage system100according to the embodiment of this invention.

FIGS. 11A and 11Bboth show the processing executed by the client150that accesses the file system202that has been migrated. At this time, the client150issues a file access request to the migration destination server110without knowing that the migration has been executed.

First,FIG. 11Awill be referenced to describe the processing.

The client150receives a file system location notification from a server (1101).

Then, the client150issues the request to obtain a file handle a migration destination server (new server) notified of in the step1101, and causes the server to perform name resolution (1102).

Then, the client150restarts the access to a desired file. To be specific, the client150uses the file handle obtained in the step1102to issue a file access request to the migration destination server (1103).

Next,FIG. 11Bwill be referenced to describe the processing.

The client150receives the file system location notification from the server110(1111).

Then, the client150executes the access to the desired file. To be specific, the client150uses the file handle600obtained before the execution of migration to issue a file access request to the migration destination server (new server)110(1112).

As described above, conventionally, in order to access the file system202that has been migrated, a file handle needs to be obtained again. Thus, the client150needs to return an error to the application. Upon reception of the error, the application needs to open the file again. Alternatively, the client150may store the path name of the desired file. However, the currently-available client150has no such function.

However, according to this invention, the file handle600obtained before the execution of migration may be used after the migration. Therefore, the file handle600does not need to be obtained again after migration.

When NFSv4 is adopted, in the conventional processing as shown inFIG. 11A, a file handle is set to invalid after migration, so a volatile file handle is used. On the other hand, in the processing according to the embodiment of this invention as shown inFIG. 11B, a file handle does not need to be set to invalid, so a persistent file handle is used.

Next, description will be made of an interface for managing the storage system100according to the embodiment of this invention. The interface is provided to the administrator of the storage system100by the management terminal140.

FIG. 12is an explanatory diagram of a file system list display screen that is displayed on a management screen of the management terminal140according to the embodiment of this invention.

The file system list display screen includes a file system list1200, a create button1207, a delete button1208, and a migrate button1209.

In the file system list1200, an LDEV1201indicates LDEV IDs of the LDEVs124managed by the management terminal140. The example ofFIG. 12shows the same LDEVs124as those shown inFIG. 2.

An FS1202indicates file system IDs of the file system202stored in the LDEVs124. In the example ofFIG. 12, the same file system202as that shown inFIG. 2is stored in each LDEV124. The FS1202ofFIG. 12is the same as the file system ID401ofFIG. 4.

A size1203indicates a storage capacity (megabyte) that is allocated to each LDEV124. In the example ofFIG. 12, the LDEV0, LDEV1, LDEV2, and LDEV3are allocated with 50 gigabytes (GB), 30 GB, 20 GB, and 200 GB, respectively.

A mount point1204indicates a mount point that is set for each file system202. In the example ofFIG. 12, the same mount point as the path402ofFIG. 4is set.

A server1205indicates an identifier of the server110that manages each file system202. In the example ofFIG. 12, the relationship between each file system202and the server110that manages the file system202is the same asFIG. 4. Therefore, the servers1205have the same values as the server IDs403ofFIG. 4.

An option1206indicates an attribute that is set for each LDEV124. In the example ofFIG. 12, the options1206of the LDEV0, LDEV1, and LDEV3are set to “rw” (read/write). This implies that the three LDEVs124permit data write and read. In other words, the client150can write and read out data to/from the three LDEVs124.

In contrast, the option1206of the LDEV2is set to “ro” (read_only). This implies that the LDEV2inhibits data write. In other words, the client150cannot write data to the LDEV2.

The create button1207is used to create a new file system202.

The delete button1208is used to delete the file system202. For example, when the administrator selects the file system202to be deleted and operates the delete button1208, the selected file system202is deleted. Here, the selection of the file system202may be executed by operating (for example, mouse-clicking) a circle mark on the left of each LDEV1201ofFIG. 12with a pointing device (not shown). The delete button1208may be operated with the pointing device similarly.

The migrate button1209is used when the file system202is migrated. For example, when the administrator selects the file system202to be migrated and operates the migrate button1209, another screen as shown inFIG. 13is displayed, and migration is executed.

FIG. 13is an explanatory diagram of a migration setting screen that is displayed on the management screen of the management terminal140according to the embodiment of this invention.

The migration setting screen is displayed when the administrator selects the file system202on the file system list display screen as shown inFIG. 12and operates the migrate button1209.FIG. 13shows the example of the migration setting screen in the case where the administrator selects the FS1on the file system list display screen.

The migration setting screen includes an LDEV display field1301, a file system display field1302, a server entry field1303, and an execute button1304.

The LDEV display field1301displays the LDEV ID of the LDEV124corresponding to the file system202selected by the administrator. In the example ofFIG. 13, the LDEV1is displayed.

The file system display field1302displays the file system ID of the file system202selected by the administrator. In the example ofFIG. 13, the FS1is displayed.

In the server entry field1303, the ID of the migration destination server110is entered. In the example ofFIG. 13, “sid2” is entered. This implies that the administrator intends to migrate the FS1to the server2.

The execute button1304is used to execute migration. When the administrator operates the execute button1304, the migration processing starts to migrate the FS1stored in the LDEV1to the server2.

As has been described above, according to this invention, it is possible to distribute the access loads on servers by migrating a file system between the servers.

Further, according to this invention, all servers within a storage system share a namespace. The file handle corresponding to each file is uniquely set within the storage system. Each file handle holds the same values even after the execution of migration. As a result, the file handle obtained before the execution of migration can be used even after the execution of migration.

Further, according to this invention, the migration destination server is notified that the execution of migration has started. When the file access request for a file system to be migrated is received during the execution of migration, the migration destination server suspends the file access request or returns the temporary error. In either case, the access is executed after the execution of migration, the client does not need to return the error to the application.