WO2014087518A1 - ネットワークシステム及びその運用方法 - Google Patents

ネットワークシステム及びその運用方法 Download PDF

Info

Publication number
WO2014087518A1
WO2014087518A1 PCT/JP2012/081656 JP2012081656W WO2014087518A1 WO 2014087518 A1 WO2014087518 A1 WO 2014087518A1 JP 2012081656 W JP2012081656 W JP 2012081656W WO 2014087518 A1 WO2014087518 A1 WO 2014087518A1
Authority
WO
WIPO (PCT)
Prior art keywords
storage
rank
tier
information
network system
Prior art date
Application number
PCT/JP2012/081656
Other languages
English (en)
French (fr)
Inventor
宏典 仲眞
Original Assignee
株式会社 日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社 日立製作所 filed Critical 株式会社 日立製作所
Priority to PCT/JP2012/081656 priority Critical patent/WO2014087518A1/ja
Priority to US13/981,228 priority patent/US8793373B2/en
Publication of WO2014087518A1 publication Critical patent/WO2014087518A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Definitions

  • the present invention relates to a network system for allocating storage resources to a host device and an operation method thereof.
  • SSPs Storage service providers
  • SSP Storage service providers
  • the like are strengthening network systems by introducing additional storage devices to satisfy the storage capacity required by end users.
  • SSP etc.
  • Patent Document 1 discloses a method and system for enabling storage virtualization of a physical storage device when allocating storage resources to a virtual machine (hereinafter referred to as VM) operating on a physical host device. This method and system allocates a storage resource that satisfies the requirements regarding storage characteristics and capacity (quota) included in a storage resource allocation request from the VM to the VM.
  • VM virtual machine
  • Patent Document 2 discloses a technology for efficiently and efficiently allocating storage resources in a balanced manner in terms of performance and capacity.
  • the technology of Patent Document 2 relates to a storage system and its operation method.
  • This storage system includes performance information indicating I / O performance of a storage device such as an HDD (Hard Disk Drive) constituting the array group, and the storage device. Capacity information representing the storage capacity is received, performance requirement information and capacity requirement information required for the storage area are received, and a storage device that satisfies the requirements is selected.
  • HDD Hard Disk Drive
  • SSP etc. wants to minimize the additional introduction cost of storage devices as much as possible, but it is necessary to satisfy users with high performance requirements in an environment where users with high performance requirements and users with low performance are used together. . Therefore, the SSP is forced to introduce an expensive storage device with high performance. The cost of introducing expensive storage devices and maintenance costs are high, and the usage costs of users are inevitably high, so that storage with high usage fees and excessive performance is necessary for users who need only low performance. Resources will be used.
  • pNFS parallel NFS
  • NFS Network File System
  • IETF Internet Engineering Task Force
  • pNFS Using this pNFS, the performance of the distributed file system can be improved.
  • pNFS is unaware of the specifications of the individual storage devices that make up the data storage at the data storage destination and the type of storage medium installed in the storage device. For this reason, pNFS has a problem that the characteristics of each storage device and storage medium cannot be fully utilized.
  • the present invention provides a storage device that takes advantage of the characteristics of individual storage devices constituting the data storage and individual storage media installed in the storage device in an environment where a distributed file system is adopted for the network system.
  • the purpose is to improve system performance.
  • the network system of the present invention collects storage configuration information of a storage resource that is a data storage destination and VM resource information related to a VM that is a storage resource allocation destination. Then, storage areas for different storage tiers having different characteristics are configured based on the collected storage configuration information, and the storage tier of the storage area to be allocated to the VM is specified by the VM resource information.
  • an appropriate storage resource can be allocated to a virtual machine operating on the host device, so that the performance of the entire system can be improved.
  • FIG. 1 is a diagram showing a configuration example of a network system according to the first embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of the internal configuration of the storage apparatus.
  • FIG. 3 is a diagram illustrating an internal configuration example of the metadata server.
  • FIG. 4 is a schematic diagram of a network system compliant with the conventional pNFS standard.
  • FIG. 5 is a sequence diagram illustrating a process of allocating storage resources to the VM.
  • FIG. 6 is a flowchart showing storage LU Tier rank generation / update processing.
  • FIG. 7 is a diagram illustrating a configuration example of a model rank determination table.
  • FIG. 8 is a diagram illustrating a configuration example of an LU rank management table.
  • FIG. 1 is a diagram showing a configuration example of a network system according to the first embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of the internal configuration of the storage apparatus.
  • FIG. 3 is a diagram illustrating an internal configuration
  • FIG. 9 is a flowchart showing processing for determining the model rank in the storage apparatus.
  • FIG. 10 is a flowchart showing the medium rank determination process of the storage medium constituting the LU.
  • FIG. 11 is a diagram illustrating a configuration example of an LU Tier rank determination table.
  • FIG. 12 is a diagram illustrating a configuration example of the LU Tier rank management table.
  • FIG. 13 is a flowchart showing LU Tier rank determination processing.
  • FIG. 14 is a diagram illustrating a configuration example of a resource-specific share rank determination table.
  • FIG. 15 is a diagram illustrating a configuration example of a VM resource share rank management table.
  • FIG. 16 is a flowchart showing a VM resource information collection process.
  • FIG. 17 is a diagram illustrating a configuration example of a VM Tier rank determination table.
  • FIG. 18 is a diagram illustrating a configuration example of a VM Tier rank management table.
  • FIG. 19 is a flowchart showing the VM Tier rank determination process.
  • FIG. 20 is a diagram illustrating a configuration example of a volume layout table.
  • FIG. 21 is a flowchart showing LU Tier rank determination processing and volume layout generation / update processing.
  • FIG. 22 is a diagram illustrating a configuration example of a network system according to the second embodiment of the present invention.
  • FIG. 23 is a sequence diagram showing processing for assigning storage resources to a VM according to the second embodiment of the present invention.
  • FIG. 24 is a diagram illustrating a configuration example of a network system according to the third embodiment of the present invention.
  • FIG. 25 is a diagram showing a configuration example of a network system according to the fourth embodiment of the present invention.
  • the processing is executed by a processor such as an MP (Micro Processor) or a CPU (Central Processing Unit), and performs a predetermined process.
  • a processor such as an MP (Micro Processor) or a CPU (Central Processing Unit)
  • the processing subject may be a processor because the storage resources (for example, a memory) and a communication interface device (for example, a communication port) are used as appropriate.
  • the processor may have dedicated hardware in addition to the CPU.
  • the computer program may be installed on each computer from a program source.
  • the program source may be provided by, for example, a program distribution server or a storage medium.
  • each element for example, the controller can be identified by a number or the like, but other types of identification information such as a name may be used as long as it is identifiable information.
  • identification information such as a name
  • the same reference numerals are given to the same parts, but the present invention is not limited to the present embodiment, and any application examples that meet the idea of the present invention are technical. Included in the range. Further, unless specifically limited, each component may be plural or singular.
  • FIG. 1 is a diagram showing a configuration example of a network system 1 according to the first embodiment of the present invention.
  • the network system 1 makes it possible to allocate storage resources to VMs according to the characteristics of VMs (virtual machines) that could not be realized with conventional distributed file systems.
  • the network system 1 includes one or more host devices 2, one or more data storages 3, a storage management server 4, and a metadata server 5, and the devices are connected via networks 6, 7, and 8.
  • the host device 2 is a computer device provided with information processing resources such as a CPU and a memory, and includes, for example, a personal computer (hereinafter abbreviated as a PC), a mainframe, a server, and the like.
  • the host device 2 may be composed of one computer device or a plurality of computer devices.
  • the host device 2 further includes an information input device (not shown) such as a keyboard, a pointing device, and a microphone, and an information output device (not shown) such as a monitor display and a speaker.
  • an information input device such as a keyboard, a pointing device, and a microphone
  • an information output device such as a monitor display and a speaker.
  • the host device 2 can also include a virtualization mechanism capable of operating a plurality of VMs 10 on a physical computer device.
  • a virtualization mechanism capable of operating a plurality of VMs 10 on a physical computer device.
  • hypervisor virtualization a case where “hypervisor virtualization” is used for the host device 2 among “host OS virtualization” and “hypervisor virtualization”, which are widely used virtualization methods. The following description is given as an example.
  • the hypervisor becomes a virtualization layer on the physical computer device, and a plurality of VMs 10 can be simultaneously operated on the virtualization layer.
  • the hypervisor 9 manages physical resources such as a CPU, a memory, a storage device, and a connection path (hereinafter referred to as a path) as a virtual resource pool. Then, the hypervisor 9 provides each VM with a resource required for each VM as a virtual resource from the virtual resource pool. The hypervisor 9 manages and holds virtual resource allocation information for each VM 10 as VM resource information 11.
  • the networks 6, 7, and 8 are configured by an arbitrary network such as a SAN (Storage Area Network), a LAN (Local Area Network), the Internet, a public line, or a dedicated line. Communication between the host device 2, the data storage 3, the storage management server 4, and the metadata server 5 via the networks 6, 7 and 8 is, for example, according to the fiber channel protocol when the network 6, 7 or 8 is a SAN. If it is a LAN, it is performed according to TCP / IP (Transmission Control Protocol / Internet Protocol).
  • TCP / IP Transmission Control Protocol / Internet Protocol
  • the data storage 3 is composed of one or more storage devices, and in this embodiment, one data storage 3 is configured with five storage devices 13a, 13b, 13c, 13d, and 13e. (Hereinafter, the storage devices 13a to 13e may be referred to as the storage device 13).
  • Each storage device 13 may be the same or different in performance, capacity, and usage. Depending on the characteristics of the VM10, one or more storage devices with different performance, capacity, and usage may be allocated to the VM10 when a virtual storage resource configured using multiple storage tier LUs (Logical Units) is allocated to the VM10. If the storage tiers are configured in combination with various storage tiers, the degree of freedom in tier selection increases and allocation becomes easier.
  • tier LUs Logical Units
  • a group of high-end storage devices 13a and 13b aimed at improving fault tolerance and I / O performance by multiplexing parts and connections from the cost with five storage devices, cost and performance
  • the example which forms is shown.
  • distributed storage of data may be realized by using a plurality of inexpensive storage devices such as low-end storage devices and entry storage devices.
  • the storage device 13 constituting the data storage 3 has, as storage access protocols, NAS (Network Attached Storage) that is accessed on a file basis, SAN (Storage Area Network) storage that is accessed on a block basis, and OSD (Object that is accessed on an object basis).
  • An interface such as Storage Device can be used.
  • a description will be given on the assumption that SAN storage is adopted for the storage device 13 and the host device 2 and the storage device 13 communicate with each other using the SAN protocol.
  • the storage apparatus 13 can form one or more LUs 12a, 12b, 12c,... 12o (hereinafter sometimes collectively referred to as LU12) in the apparatus, and can be managed in units of LUs. .
  • these networks can be connected by wire or wirelessly.
  • the storage management server 4 is a computer device provided with information processing resources such as a CPU and a memory, and is composed of, for example, a PC, a mainframe, a server, and the like, similar to the host device 2.
  • the storage management server 4 is connected to each storage device 13 via the network 8 and communicates with a maintenance management terminal (not shown) of each storage device 13 to thereby maintain and set / change storage configurations of the plurality of storage devices 13. Can be centrally managed. *
  • the storage management server 4 is installed and information on physical resources (number of CPUs, cache memory capacity, type / capacity / performance of storage medium, number of external connection paths, etc.) provided in each storage device 13.
  • Software local copy, synchronous / asynchronous remote copy, virtualization, thin provisioning, dynamic tier control, etc.
  • the storage management server 4 is connected to the host device 2 and the metadata server 5 via the network 7 and sends the storage configuration information 14 to the host device 2 and the metadata server 5.
  • the metadata server 5 is a computer device provided with information processing resources such as a CPU and a memory, and includes a PC, a mainframe, a server, and the like, similar to the host device 2 and the storage management server 4.
  • the metadata server 5 is connected to the host device 2, the storage device 13, and the storage management server 4 via the network 7.
  • the metadata server 5 controls a distributed file system that executes data input / output from the host device 2 to the data storage 3 in parallel and writes and reads data across a plurality of storage devices 13 constituting the data storage 3. It is a device to do.
  • HDFS Hadoop Distributed File System
  • the metadata server 5 is a virtual network composed of layered LUs, which is a feature of the present invention, in addition to a function provided as a pNFS standard in a metadata server of a standard network system constructed according to the pNFS standard described later (FIG. 4).
  • a Tier determination / volume layout function unit 15 and storage / VM / Tier information 16 for enabling storage resources to be allocated according to VM characteristics are provided.
  • the Tier determination / volume layout function unit 15 determines the Tier rank of each LU using the storage configuration information 14 described above, and determines the Tier rank of each VM using the virtual resource allocation information required by each VM 10. To do.
  • the Tier determination / volume layout function unit 15 determines the volume layout represented by the LU type (Tier rank) required by the VM 10 and the number thereof from the determined Tier rank of the LU and the Tier rank of the VM. .
  • the storage / VM / Tier information 16 includes storage configuration information collected by the Tier determination / volume layout function unit 15, VM resource information, the Tier rank and VM Tier rank of the determined and determined LU, the determined volume layout, etc. Store information.
  • the LU tier is similar in characteristics required by the host device for the LU, such as I / O processing speed, failure tolerance, cost, capacity, etc. of the storage device or storage medium forming the LU. Are grouped into one category. Also, VM Tiers have the same or similar characteristics depending on the usage such as mission critical, OLTP (On-Line Transaction Processing), general office work, and archiving based on the virtual CPU and virtual memory capacity allocated to the VM. Are grouped into one category.
  • LUs and VMs having the same or similar characteristics are classified and ranked into groups called Tiers to which the respective characteristics correspond.
  • the VM Tier rank is determined based on the characteristics of each VM, and the LU Tier rank that matches the determined VM Tier rank is determined.
  • the volume layout (LU layout: storage location) is determined by determining the LU type that matches the determined LU Tier rank and the number of LUs according to the distribution policy (such as the number of storage devices that distribute and store data and files). LU information) is determined.
  • FIG. 2 is a diagram illustrating an example of the internal configuration of the storage apparatus.
  • FIG. 2 shows a configuration example of a high-end storage device 13a that is expensive but has high performance and high reliability among the SAN storages used as the storage device 13 in this embodiment.
  • the high-end storage device 13a unlike PCs and PC servers used for general purposes, is specialized in storage and is excellent in performance and expandability, and can be configured in a scalable manner according to the application. However, the use of a PC or a PC server as the storage device 13 is not prevented.
  • the storage device 13 a includes a storage medium group 202 composed of storage media 201 such as a plurality of SSDs (Solid State Drives) and HDDs, and a controller unit 203 that controls the storage medium group 202.
  • storage media 201 such as a plurality of SSDs (Solid State Drives) and HDDs
  • controller unit 203 that controls the storage medium group 202.
  • Examples of the storage medium 201 constituting the storage medium group 202 include optical disks in addition to HDDs such as the above-described SSD and SAS (Serial Attached SCSI) drives, nearline SAS drives, and SATA (Serial ATA) drives.
  • HDDs such as the above-described SSD and SAS (Serial Attached SCSI) drives, nearline SAS drives, and SATA (Serial ATA) drives.
  • Each storage medium 201 is operated by the control unit 203 in a RAID (Redundant Array of Inexpensive Disks) method, and realizes high reliability in the entire storage apparatus 13a.
  • a RAID group is composed of a plurality of storage media, and one or more LUs 12 can be generated in each physical storage area provided by each RAID group.
  • the storage device 13a generates three LUs 12a, 12b, and 12c inside the device and provides them to the host device 2.
  • data from the host apparatus 2 is stored in the LU 12 in units of a predetermined size block.
  • one piece of data is divided and stored in a plurality of LUs 12 of different storage apparatuses 13. Since data is distributed and stored in a plurality of LUs 12, each LU 12 needs to be identified. For this reason, each LU 12 is assigned a unique identifier (hereinafter referred to as an LU number) and is sent to the VM 10. The virtual storage resource is allocated using this LU number.
  • the LU 12 is configured on a physical storage area of a RAID group composed of the same type of storage medium in the network system 1, and the storage tier (grouped for each type of storage medium constituting the LU 12).
  • An example of forming (Tier) will be described.
  • the network system 1 selects two or more LUs 12 made of the same type of storage medium from different storage devices 13 and lays out (forms) one volume across the plurality of LUs 12.
  • the controller unit 203 includes a channel interface 204, a CPU 205, a local memory 206, a data transfer controller 207, a cache memory 208, a disk interface 209, and a communication interface 211.
  • a channel interface 204 In the high-end storage device 13a, high reliability and high availability are realized by using a plurality of components of the controller unit 203 such as the channel interface 204 and the CPU 205 for redundancy.
  • the channel interface 204 is a communication controller that connects the storage device 13a and the network 6 to the network 7. Using the channel interface 204, the storage apparatus 13 sends write data from the host apparatus 2, read data to the host apparatus 2, volume layout information regarding various volume layouts, various commands, and the like with the host apparatus 2 and the metadata server 5. Send and receive between.
  • the CPU 205 is a processor that controls various processes such as a data input / output process to the storage medium 201 in response to a data input / output request (data write request or data read request) from the host device 2.
  • the local memory 206 is used as a work memory of the CPU 205 and stores various control programs and system control information read from the cache memory 208, calculation results in the CPU 205, and the like.
  • the data transfer controller 207 is a controller that controls data transfer among the CPU 205, the channel interface 204, the disk interface 209, and the cache memory 208.
  • the cache memory 208 is a memory for temporarily storing data transferred between the channel interface 204 and the disk interface 209.
  • the cache memory 208 also stores system control information read from the storage medium 201 when the storage apparatus 13 is activated, various control programs, and the like.
  • the CPU 205 reads requests from the cache memory 208 and executes these control programs as necessary to process requests from the host apparatus 2 to the storage apparatus 13.
  • the disk interface 209 is a communication controller that connects the storage medium 201 and the controller unit 203. For example, according to the fiber channel protocol, transmission of write data to the storage medium 201, reception of data read from the storage medium 201, and Send and receive various commands.
  • the maintenance management terminal 210 is a terminal that performs maintenance and management of the storage apparatus 13, and for example, a notebook PC is used.
  • the maintenance management terminal 210 is connected to the network 8 and is also connected to the controller unit 203 via the communication interface 211.
  • the maintenance management terminal 210 monitors the presence or absence of a failure in the storage device 13, and displays failure information such as a failure location and an emergency level when a failure occurs. It has a function of displaying on a display and a function of notifying a system administrator.
  • the system administrator can use the maintenance management terminal 210 to set the system configuration in the storage apparatus 13 or update the set configuration.
  • the storage apparatus 13 forms one or more LUs 12 according to the configuration and operation described above and provides them to the host apparatus 2, and transmits the storage configuration information 14 set and managed in the storage apparatus 13 to the metadata server 5. it can.
  • FIG. 3 is a diagram illustrating an internal configuration example of the metadata server.
  • the metadata server 5 holds metadata indicating the storage location and storage method of files and data. Note that the host device 2 and the storage management server 4 have the same configuration as the metadata server 5.
  • the metadata server 5 includes a CPU 51, an input device 52, an output device 53, a communication interface 54, a memory 55, and a storage device 56, and is connected to each other via an internal bus 57.
  • the CPU 51 is a processor that controls the entire metadata server 5.
  • the CPU 51 reads various programs stored in the memory 55 and storage configuration information stored in the storage device 56 as necessary, and executes processing such as Tier rank determination and volume layout generation described later. .
  • the input device 52 is a device that inputs information to the metadata server 5 from the outside, and is, for example, a keyboard, a mouse, a pointing device, a microphone, or the like.
  • the output device 53 is a device that outputs information to the outside of the metadata server 5, and is, for example, a display, a speaker, a printer, or the like.
  • the communication interface 54 is a communication controller for connecting the host device 2, the data storage 3, the storage management server 4 and the metadata server 5 via the network 7.
  • the communication interface 54 is, for example, a NIC (Network Interface Card).
  • the memory 55 temporarily stores various programs such as the OS and applications and the calculation results of the CPU 51, and is configured by a volatile memory such as a RAM (Random Access Memory) or a nonvolatile memory such as a flash memory. .
  • the memory 55 stores a Tier determination / volume layout function unit 15 which is a control program group for realizing the present invention.
  • the storage device 56 is a non-volatile device that stores various programs, various information, and the like, and uses, for example, a plurality of HDDs.
  • the storage device 56 stores storage / VM / Tier information 16 that is a feature of the present invention.
  • the metadata server 5 is composed of a hierarchical LU that is a feature of the present invention, in addition to the functions possessed as the pNFS standard in the metadata server of a standard network system constructed in accordance with the pNFS standard described later (FIG. 4).
  • the virtual storage resource includes a Tier determination / volume layout function unit 15 and storage / VM / Tier information 16 for allocating the virtual storage resource according to the VM characteristics.
  • the Tier determination / volume layout function unit 15 includes a storage Ltier management program 301 that manages LU Tiers, a VM Tier management program 302 that manages VM Tiers, and a volume management program 303 that manages volume layouts.
  • the storage LU tier management program 301 determines the tier rank of the LU 12 held by each storage device 13 based on the storage configuration information collection processing 304 that collects the storage configuration information 14 of the storage device 13 and the collected storage configuration information 14 A storage LU tier generation / update process 305 is provided.
  • the VM Tier management program 302 includes a VM resource information collection process 306 that collects VM resource information related to virtual resource resources allocated to the VM 10, and a VM Tier rank determination process that determines the Tier rank of each VM 10 based on the collected VM resource information 307.
  • the volume management program 303 determines the assigned LU Tier rank determination processing 308 for determining the Tier rank of the LU 12 assigned to each VM 10, and the LU 12 Tier rank assigned to the determined VM 10.
  • a volume layout process 309 for determining the volume layout of the virtual storage resource provided to the VM 10 based on the distribution policy is provided.
  • the distribution policy determines how many storage apparatuses 13 store and distribute one file or data block. For example, if the distribution policy is to store files and data blocks distributed to three storage devices 13, three LUs 12 having the same Tier rank are selected from the three storage devices, and the files and data blocks are selected. Are stored simultaneously in each LU 12. That is, if the distribution policy is “3”, the volume management program 303 selects three LUs 12 having the same Tier rank.
  • the volume layout is to form a volume with a plurality of LUs 12 (storage destination LUs) selected according to the distribution policy, and to associate a VM number for identifying the VM 10 with a storage destination LU number group.
  • LUs 12 storage destination LUs
  • the storage / VM / Tier information 16 includes the storage configuration information 14 collected by the Tier determination / volume layout function unit 15, the VM resource information 11, the Tier rank of the LU 12 and the Tier rank of the VM 10 determined by each program, the determined allocation LU Information such as Tier rank and volume layout.
  • the tier determination / volume layout function unit 15 of the metadata server 5 and the storage / VM / Tier information 16 are provided, so that virtual storage resources that match the VM characteristics can be appropriately allocated to each VM 10. Is possible.
  • FIG. 4 is a schematic diagram of a network system compliant with the conventional pNFS standard. The configuration and operation of a conventional standard distributed file system 40 will be described with reference to FIG.
  • the distributed file system 40 includes a pNFS client 401, a data storage 402 including a plurality of storage devices 403, and a metadata server 404.
  • the pNFS client 401, the data storage 402, and the metadata server 404 correspond to the host device 2, the data storage 3, and the metadata server 5 of FIG.
  • transmission / reception of metadata which is data storage location information, is executed between the pNFS client 401 and the metadata server 404 in accordance with the pNFS protocol.
  • transmission / reception of actual data is executed between the pNFS client 401 and the data storage 402 according to a predetermined storage access protocol without passing through the metadata server 404.
  • the metadata server 404 manages a volume layout representing how the actual data is distributed and stored in the plurality of storage apparatuses 403 constituting the data storage 402. This volume layout is transmitted and received between the metadata server 404 and the data storage 402 according to a predetermined control protocol.
  • the metadata server 404 provides the pNFS client 401 with metadata indicating a data storage destination so that the pNFS client 401 can directly access the data storage 402.
  • the metadata server 404 holds metadata / layout information including metadata and volume layout configuration information.
  • the pNFS client 401 is connected to the storage device 403 constituting the data storage 402 through a parallel data path.
  • the pNFS client 401 can simultaneously access a plurality of storage apparatuses 403 in parallel with this parallel data path based on the metadata acquired from the metadata server 404.
  • the state of the metadata server 404 and the state of the data storage 402 are synchronized.
  • the metadata communication and the actual data communication are separated, and the pNFS client accesses a plurality of storage devices simultaneously in parallel.
  • high-speed data writing to the data storage and high-speed data reading from the data storage are realized.
  • FIG. 5 is a sequence diagram showing a process of allocating storage resources to a VM.
  • FIG. 5 is a sequence diagram between the system apparatuses showing the entire processing from the generation of the virtual storage resource allocation request to the newly created VM 10 to the completion of the allocation of the virtual storage resource to the VM 10 in the network system 1. is there.
  • a request between each device constituting the network system 1, a response to the request, and a process in each device will be specifically described.
  • the main subject of the processing is the device itself or a program such as a hypervisor that operates on the device, a CPU or various controllers that operate the device or program may be used.
  • the hypervisor 9 of the host device 2 receives a new VM creation request (or an existing VM configuration change request or the like) from the user, it is a virtual host resource (hereinafter abbreviated as a virtual resource) of the host device 2.
  • a virtual CPU or virtual memory is allocated to a new VM according to the contents of the creation request (or update request).
  • the virtual CPU has processing performance such as the number of CPUs / operation frequency / IOPS (I / O per second).
  • IOPS I / O per second
  • the virtual resource information allocated to the new VM (hereinafter referred to as new VM) 10 is managed as VM resource information 11 by the hypervisor 9.
  • the hypervisor 9 executes a process of assigning virtual storage resources to the new VM 10.
  • the above processing is the new VM virtual resource allocation acceptance processing in FIG. 5 (SP501).
  • the hypervisor 9 requests the metadata server 5 to allocate a new VM storage resource including information on the storage capacity required for the new VM 10 (SP502).
  • the metadata server 5 Upon receiving the new VM storage resource allocation request from the hypervisor 9, the metadata server 5 requests the storage management server 4 to obtain the latest storage configuration information (SP503).
  • the storage management server 4 When the storage management server 4 receives the latest storage configuration information acquisition request, the storage management server 4 transmits the storage configuration information 14 stored inside the apparatus to the metadata server 5 as the latest storage configuration information (SP504).
  • the storage management server 4 collects the storage configuration information of each storage device 13 again, not the storage configuration information 14 stored in itself, generates the latest storage configuration information 14, and sends it to the metadata server 5. You may transmit to.
  • the metadata server 5 performs storage LU tier generation / update processing based on the acquired latest storage configuration information 14, and determines the tier rank of the LU 12 generated in each storage device 13 (SP505).
  • SP503 and SP504 corresponds to the storage configuration information collection processing 304 of the storage LU Tier management program 301 shown in FIG. 3, and the processing of SP505 corresponds to the storage LU Tier generation / update processing 305. Detailed processing operations will be described with reference to FIGS.
  • the metadata server 5 sends a request for providing virtual host resource information to be allocated to the new VM to the hypervisor 9, that is, a request for acquiring the allocated virtual resource information for new VM. (SP506).
  • the hypervisor 9 When the hypervisor 9 receives the new virtual machine allocation virtual resource information acquisition request from the metadata server 5, the hypervisor 9 transmits the stored VM resource information 11 to the metadata server 5 (SP507).
  • the metadata server 5 performs a VM Tier rank determination process based on the acquired VM resource information 11, and determines the Tier rank of each VM 10 (SP508).
  • SP506 and SP507 corresponds to the VM resource information collection processing 306 of the VM Tier management program 302 shown in FIG. 3, and the processing of SP508 corresponds to the VM Tier rank determination processing 307. Detailed processing operations will be described with reference to FIGS.
  • the metadata server 5 determines the Tier rank of the LU assigned to each VM 10 (SP509).
  • the metadata server 5 selects the number of LUs 12 corresponding to the LU Tier rank determined in SP509 by the number required by the distribution policy, and lays out the virtual storage resource volume to be allocated to the VM 10 (SP510).
  • This volume layout information includes a VM number for identifying the VM 10, an LU number as a data storage destination, a storage capacity, and the like.
  • the metadata server 5 transmits a new VM storage resource allocation response including volume layout information to the hypervisor 9 and provides the volume of the laid out virtual storage resource to the VM 10 (SP511).
  • SP509 corresponds to the allocated LU Tier rank determination processing 308 of the volume management program 303 shown in FIG. 3, and the processing of SP510 and SP511 corresponds to the volume layout processing 309. Detailed processing operations will be described with reference to FIGS. 20 and 21.
  • FIG. 20 The processing of SP509 corresponds to the allocated LU Tier rank determination processing 308 of the volume management program 303 shown in FIG. 3, and the processing of SP510 and SP511 corresponds to the volume layout processing 309. Detailed processing operations will be described with reference to FIGS. 20 and 21.
  • the hypervisor 9 makes a storage allocation request for a new VM to the metadata server 5 without specifying the Tier rank of the LU 12 and specifying only the storage capacity.
  • the Tier rank of the required LU 12 may also be specified together with the storage capacity, and a new VM storage resource allocation may be requested to the metadata server 5.
  • the metadata server 5 omits the VM Tier rank determination process based on the acquired VM resource information 11, and adds the LU 12 corresponding to the LU Tier rank specified in the new VM storage allocation request according to the distribution policy.
  • a logical volume that is selected and allocated to the new VM 10 may be laid out.
  • virtual storage resources (storage tier LU) satisfying the VM characteristics can be appropriately allocated to the VM 10.
  • FIG. 6 is a flowchart showing storage LU Tier rank generation / update processing. This process is a flowchart showing the process from when the metadata server 5 receives the new VM storage resource allocation request from the hypervisor 9 until the storage LU Tier generation / update process is completed, from SP502 to SP505 in FIG. It corresponds to the process.
  • the storage LU tier management program 301 executes the processing shown in this flowchart, whereby the tier rank for each LU formed in the storage apparatus 13 can be determined and updated. This process is started when the metadata server 5 receives a new VM storage resource allocation request from the hypervisor 9.
  • the storage LU tier management program 301 sends the latest storage configuration information acquisition request to the storage management server 4.
  • the storage management server 4 receives the latest storage configuration information acquisition request
  • the storage management server 4 transmits the storage configuration information 14 stored inside the apparatus to the metadata server 5 as the latest storage configuration information.
  • the storage LU tier management program 301 receives it (SP601).
  • the storage LU tier management program 301 determines whether the storage LU tier rank (hereinafter referred to as LU tier rank) is the first determination by the storage device 13 itself or the LU of the storage device 13 based on the acquired latest storage configuration information 14. Determine (SP602).
  • the storage LU Tier management program 301 determines the model of each storage device 13 constituting the data storage 3 from the acquired latest storage configuration information 14 (SP604).
  • the storage LU tier management program 301 determines the type of the storage medium 201 that constitutes each storage LU (hereinafter LU) 12 (SP605).
  • the storage LU tier management program 301 determines the tier rank of each LU 12 and ends the processing (SP606).
  • the storage LU Tier management program 301 compares the latest storage configuration information acquired with the storage configuration information acquired last time, and the storage configuration has changed. (SP603).
  • the storage LU Tier management program 301 executes the processing from SP604 to SP606, updates the Tier rank of each LU 12, and ends the processing.
  • the storage LU Tier management program 301 ends the process.
  • the tier rank of each LU 12 in each storage device determined last time is used. By executing the above processing, a Tier rank can be set for each LU 12 of the storage apparatus.
  • FIG. 7 is a diagram illustrating a configuration example of a model rank determination table.
  • the model rank table 700 is a table for determining the model rank 701 that is the rank in each storage device 13 from the model name 702. Focusing on the fact that storage devices 13 of the same class are generally given the same series name, in this embodiment, a characteristic location indicating the same series name is extracted from the storage configuration information 14. Thus, the extracted information is registered and managed as the model name 702 in the model rank table 700.
  • a model having a name starting with “SSS” such as row 711 is ranked “high-end”, and a model having a name beginning with “BBB” is designated as “midrange” as shown in row 712. Yes.
  • the “***” portion such as “SSS ***” indicates that any name may be used.
  • model rank determination process of FIG. 9 it is determined whether or not the storage device name hits the model name 702, and if it hits, the storage device 13 is ranked with the corresponding model rank 701.
  • the classification of the model rank may be performed based on other information that can identify each storage device 13 that can be acquired by the storage management server 4 without depending on the information indicating the same series name.
  • FIG. 8 is a diagram illustrating a configuration example of an LU rank management table.
  • the LU rank management table 800 is a table for managing the model rank 802 and medium rank 803 for each LU (LU number 801).
  • the model rank and medium rank for the LU 12 determined by the model rank determination process (FIG. 9) and the medium rank determination process (FIG. 10) described later are stored and managed.
  • the LU rank management table 800 is referred to in the process of determining the LU tier rank described in FIG.
  • FIG. 9 is a flowchart showing a process for determining the model rank of the storage apparatus 13 constituting the data storage 3.
  • the storage LU tier management program 301 determines the model rank of each storage device 13 using the model rank determination table 700 and stores the result in the LU rank management table 800.
  • This process is a model rank determination process in SP604 of FIG.
  • MTBF Mobile Time Between Failures
  • MTTR Storage devices that can obtain an average repair time (Mean Time To Repair) small) shall be a high-end rank group.
  • a storage device that is used as a file server or Web server for sharing in-house information and can achieve a balance between cost and performance is made a mid-range rank group.
  • a storage apparatus configured to be suitable for backup of large-capacity data and long-term storage of data is set as an archive rank group. Then, ranking as the storage device 13 is performed using a model rank determination table 700 indicating which model belongs to each group. The specific operation will be described.
  • the storage LU tier management program 301 extracts the model name of each storage device 13 and the LU number that is information of the LU 12 configured inside the device from the acquired latest storage configuration information 14.
  • the storage LU tier management program 301 compares the extracted model name with the model name 802 of the model rank determination table 700 to determine whether the storage device is registered in the high end rank whose model rank is “high end” (SP901). ).
  • the storage LU Tier management program 301 records the LU number and the high-end rank in the LU rank management table 800 of FIG. The process ends (SP902). For example, if the storage apparatus 13a has LUs with numbers 00 to 02, the LU number 801 stores “high end” in the entry of the model rank 802 corresponding to “LU00” to “LU02”.
  • the storage LU Tier management program 301 determines whether it is a storage device registered in the midrange rank (SP903). If the storage device is registered in the midrange rank (“Yes” in SP903), the storage LU Tier management program 301 records the LU number and the midrange rank in the LU rank management table 800, and ends the processing. (SP902).
  • the storage LU Tier management program 301 determines whether it is a storage device registered in the archive rank (SP904). If the storage device is registered in the archive rank (“Yes” in SP904), the storage LU Tier management program 301 records the LU number and the archive rank in the LU rank management table 800, and ends the processing ( SP902).
  • the storage LU Tier management program 301 has no LU number and model rank in the LU rank management table 800 as shown in row 814. That is, “no model information” is recorded, and the process ends (SP905).
  • model ranks are classified into four types: high end, mid range, archive, and no model information.
  • the number of ranks may be larger or smaller.
  • the rank criteria need not be classified as high-end, mid-range, and archive according to these performances and applications.
  • the LU information configured in the storage apparatus 13 and the model rank can be determined, and the information corresponding to the entries of LU number 801 and model rank 802 in the LU rank management table 800 Can be stored.
  • FIG. 10 is a flowchart showing the medium rank determination process of the storage medium constituting the LU.
  • the storage LU Tier management program 301 determines the type of the storage medium 201 constituting the LU 12 and performs ranking, and stores the ranking result in the entry of the medium rank 803 of the LU rank management table 800. This process is the medium rank determination process in SP605 of FIG.
  • SSD is the medium rank “A” as the storage medium 201 having excellent performance in terms of throughput and I / O response time
  • the SAS drive is the medium rank “B” as the storage medium having the next performance after the SSD, and the others.
  • the storage media are classified into three media ranks “C”.
  • the storage LU tier management program 301 determines whether the storage medium 201 constituting each LU 12 is an SSD based on the acquired latest storage configuration information 14 (SP1001).
  • the storage LU Tier management program 301 sets “A” to the entry of the medium rank 803 in the LU rank management table 800 as shown in the row 811. Recording is performed, and the process ends (SP1002).
  • the storage LU Tier management program 301 determines whether the storage medium is a SAS drive (SP1003).
  • the storage LU Tier management program 301 sets “B” to the entry of the medium rank 803 in the LU rank management table 800 as shown in the row 812. Recording is performed, and the process is terminated (SP1004).
  • the storage LU Tier management program 301 sets “C” to the entry of the medium rank 803 in the LU rank management table 800 as shown in line 813. Recording is performed, and the processing is terminated (SP1005).
  • the media rank is classified into three levels A, B, and C, but the number of rank levels may be larger or smaller.
  • the medium type to be determined is classified into three types other than SSD, SAS, SSD, and SAS.
  • near-line SAS drive, SATA drive, optical drive, FC (Fibre Channel) are used.
  • FC Fibre Channel
  • each LU 12 is configured with the same type of storage medium is described.
  • the different storage medium configuration rank “D” is used. "Etc. may be provided for classification.
  • the storage medium constituting the LU can be ranked, and the result of ranking the medium rank 803 entry of the LU rank management table 800 is stored.
  • the LU number, the corresponding model rank and medium rank can be managed.
  • FIG. 11 is a diagram illustrating a configuration example of an LU Tier rank determination table.
  • the LU tier rank determination table 1100 determines an LU tier rank from the model rank 1201 and medium rank 1202 of the LU 12 in the storage apparatus 13, and is composed of a model rank 1101, a medium rank 1102, and an LU tier rank 1110.
  • Tier 0 is the highest rank
  • Tier 3 is the lowest rank
  • LU capable of high-speed I / O processing is changed to a higher-ranked LU Tier
  • I / O processing is slow but large at low cost.
  • LUs that require capacity storage are classified into lower rank LU Tiers.
  • the storage LU tier management program 301 determines that the LU tier rank 1110 is “Tier0” with the model rank 1101 being “high end” and the medium rank 1102 is “A”, and the “midrange” is “B”.
  • the Tier rank 1110 is determined as “Tier1.5”.
  • the LU tier rank determination table 1100 of this embodiment shows a table for determining the corresponding LU tier rank based on the model rank 1101 classified into four stages in the LU rank management table 800 and the medium rank 1102 classified into three stages.
  • the LU Tier rank determination table 1100 may be configured by classifying the model rank into 3 levels or less or 5 levels or more, and the medium rank may also be configured by classifying from 2 levels to 4 levels or more. Good.
  • the LU tier rank is classified into seven stages: “Tier0”, “Tier0.5”, “Tier1”, “Tier1.5”, “Tier2”, “Tier2.5”, “Tier3”.
  • the LU tier rank determined by each model rank and each media rank is an example, and the LU tier rank determination method different from this embodiment, for example, “high”, “medium”, “low” instead of the model rank
  • the LU tier rank may be determined by defining the three-stage model performance ranks in place of the medium rank and defining the four-stage medium performance ranks of “high speed”, “fast”, “normal”, and “slow”.
  • FIG. 12 is a diagram illustrating a configuration example of the LU Tier rank management table.
  • the LU tier rank management table 1200 is a table that stores and manages the LU number 1201 and various ranks corresponding thereto in the entries of the model rank 1202, the medium rank 1203, and the LU tier rank 1204.
  • the LU number 1201, the model rank 1202, and the medium rank 1203, information of the LU rank management table 800 is stored.
  • the LU tier rank 1204 stores information on the LU tier rank determined by the LU tier rank determination table 1100 from the model rank and the medium rank.
  • the LU Tier rank management table 1200 is referred to by an allocation LU Tier rank determination process of the volume management program 303 described later, and determines the LU Tier rank of the storage resource allocated to the VM 10.
  • an LU whose LU number 1201 is “LU00” has “high end” in the model rank 1202 entry, “A” in the media rank 1203 entry, and “Tier0” in the LU Tier rank 1204 entry.
  • “midrange”, “B”, and “Tier1.5” are stored and managed in “LU10” in the row 1212. The same applies to the rows 1213 and 1214.
  • FIG. 13 is a flowchart showing LU Tier rank determination processing.
  • the storage LU Tier management program 301 ranks the LU Tier and stores the ranking result in the LU Tier rank management table 1200. This process corresponds to the SP606LU Tier rank determination process of FIG.
  • the storage LU tier management program 301 acquires the model rank information and medium rank information of the LU 12 to be determined from the LU rank management table 800 (SP1301). For example, as shown in the row 813, in order to determine the Tier rank of the LU whose LU number 801 is “LU20”, the storage LU Tier management program 301 uses the model rank information “archive” from the model rank 802 as the medium rank. From 803, medium rank information “C” is acquired.
  • the storage LU Tier management program 301 acquires LU Tier rank information that matches both the acquired model rank information and medium rank information from the LU Tier rank determination table 1100 (SP1302).
  • the storage LU Tier management program 301 acquires “Tier 3” as the Tier rank information.
  • the storage LU tier management program 301 After acquiring the LU tier rank information, the storage LU tier management program 301 records the acquired LU number, model rank information, medium rank information, and LU tier rank information that is the determination result in the LU tier rank management table 1200 for processing. Is terminated (SP1303).
  • the LU Tier rank corresponding to the LU 12 can be determined by executing the processing from SP1301 to SP1303.
  • FIG. 14 is a diagram illustrating a configuration example of a resource-specific share rank determination table.
  • the resource-specific share rank determination table includes a virtual CPU share share 1401 and a virtual CPU share rank determination table 1400 in which a corresponding virtual CPU share rank 1402 is defined, a virtual memory allocation share 1411 and a corresponding virtual memory share rank 1412.
  • the virtual memory share rank determination table 1410 is defined as two types of tables.
  • the VM Tier management program 302 obtains a virtual CPU share rank determination table 1400 and a virtual memory share rank determination table 1410 from the virtual CPU allocation share and virtual memory allocation share in the new VM allocation virtual resource information 11 acquired from the hypervisor 9. Used to determine the virtual CPU share rank and the virtual memory share rank.
  • the allocation share 1401/1411 and the share rank 1402/1412 are classified into three stages, but the number of classifications may be larger or smaller.
  • other criteria such as the number of connected ports of the storage device 12 other than the CPU and the memory, the network path bandwidth (kbps: kilo bits per second), and the storage capacity (GB: Giga Bytes) may be adopted as a criterion.
  • the virtual resource amount allocated to each VM may be acquired, and the rank may be determined based on the virtual resource amount, or the share of each VM may be calculated from the total virtual resource amount. . For example, when there are a plurality of host devices 2, the virtual resource amount allocated to the VM operating on each host device 2 is acquired, and the share of each VM is calculated from the total virtual resource amount.
  • the share rank of each VM can be determined.
  • FIG. 15 is a diagram illustrating a configuration example of a VM resource share rank management table.
  • the VM resource share rank management table 1500 is a table for managing collection / determination results in a VM resource information collection process (FIG. 16) described later.
  • a VM resource information collection process (FIG. 16) described later.
  • the VM Tier determination information table 1500 is referred to in the VM Tier rank determination process 307 (FIG. 19) of the VM Tier management program 302 in order to determine the VM Tier rank.
  • FIG. 16 is a flowchart showing a VM resource information collection process.
  • the VM resource information collection process 306 (FIG. 3) acquires new VM allocation virtual resource information (VM resource information 11) from the hypervisor 9 and records it in the VM resource share rank management table 1500.
  • the VM Tier management program 302 acquires the allocated virtual resource information for new VM (VM resource information 11) from the hypervisor 9 (SP1601).
  • the VM Tier management program 302 determines whether the VM resource allocation method in the acquired new VM allocation virtual resource information is a share rank method represented by “high”, “standard”, or “low” (SP1602). ).
  • the share rank method is a method in which, for example, the allocated virtual memory capacity is not represented by quantitative information such as “2 GB” but by qualitative information such as share rank “high”, “standard”, and “low”. Based on the priorities compared with other VMs 10 operating simultaneously, the amount of virtual resources that can be used by the VM can be calculated from the entire resources and determined by this share rank method, so the allocated capacity of storage resources to the VM 10 Can be prevented.
  • the VM Tier management program 302 acquires the information (high / standard / low) of the share rank method (SP1603). Then, the VM Tier management program 302 stores the VM number in the acquired VM resource information 11, the acquired virtual CPU share rank, and the virtual memory share rank in each entry of the VM resource share rank management table 1500 (SP1604). The VM Tier management program 302 ends the process after storing the information.
  • the VM Tier management program 302 uses the VM resource information 11 (in this embodiment, share (%)) as a resource-specific share rank determination table ( Compared with the virtual CPU share rank determination table 1400 and the virtual memory share rank determination table 1410), the share rank for each virtual resource is obtained (SP1605). Then, the VM Tier management program 302 stores the VM number in the acquired VM resource information 11, the obtained virtual CPU share rank, and the virtual memory share rank in each entry of the VM resource share rank management table 1500 (SP1604). The VM Tier management program 302 ends the process after storing the information.
  • share (%) a resource-specific share rank determination table
  • the VM resource share rank is determined by the share (%) of the virtual resource, but it may be determined by the actual allocation amount instead of the share. Further, the VM resource share rank may be classified according to information on the OS and application installed in the VM, the number of VMs created at the same time, in addition to the information related to the virtual resource amount, or separated from the virtual resource amount. May be.
  • the virtual resource amount of all VMs operating on a plurality of host devices is acquired, and the ratio of the VM allocation resource share is calculated by calculating the ratio of the total virtual resources. You may decide.
  • FIG. 17 is a diagram illustrating a configuration example of a VM Tier rank determination table.
  • the VM Tier rank determination table 1700 is a table for determining the Tier rank 1710 of each VM 10 based on the virtual memory share rank 1701 and the virtual CPU share rank 1702 of each VM 10.
  • a VM Tier rank determination table 1700 for obtaining a VM Tier rank from a three-stage virtual memory share rank 1701 and a three-stage virtual CPU share rank 1702 is shown.
  • the VM Tier rank determination table 1700 may be a table according to the classification of the virtual CPU share rank and the virtual memory share rank, and the VM Tier rank 1710 has two or four or more levels of virtual CPU share rank. Or it may be obtained from the virtual memory share rank of four or more levels.
  • the VM Tier rank 1710 is classified into five, namely Tier 0, Tier 0.5, Tier 1, Tier 1.5, and Tier 2. However, the number of classifications may be larger or smaller. In this embodiment, the VM Tier rank 1710 is determined and determined based on the virtual memory share rank 1701 and the virtual CPU share rank 1702, but other virtual resource share ranks (for example, the operating frequency of the CPU, the number of ports connected to the storage device 13) The VM Tier rank may be determined based on the path bandwidth of the connection network), or may be determined by adding another virtual resource share rank.
  • FIG. 18 is a diagram illustrating a configuration example of the VM Tier rank management table.
  • the VM Tier rank management table 1800 shows the VM Tier rank ranked by the VM Tier rank determination processing 307 (specific operation is the flowchart of FIG. 19) of SP508 (FIG. 5), the share rank of the virtual CPU and the virtual memory. There is a table to manage with.
  • the VM Tier rank management table 1800 stores and manages information on the virtual CPU share rank 1802, the virtual memory share rank 1803, and the VM Tier rank 1804 obtained or requested by the VM Tier management program 302 for each VM number 1801.
  • the contents of the VM resource share rank management table may be set in the VM Tier rank management table 1800.
  • the VM Tier rank 1804 is obtained by the VM Tier management program 302 by comparing the virtual CPU share rank 1802 and the virtual memory share rank 1803 against the VM Tier rank determination table 1700.
  • the VM Tier rank management table 1800 is referred to by an allocation LU Tier rank determination process 308 (FIG. 21) of the volume management program 303 described later, and determines the LU Tier rank of the storage resource allocated to the VM.
  • FIG. 19 is a flowchart showing a VM Tier rank determination process.
  • the VM Tier rank determination process 307 is a process executed following the VM resource information collection process (FIG. 16), and determines the VM Tier rank and stores the rank in the VM Tier rank management table 1800.
  • the VM Tier management program 302 acquires the virtual CPU share rank and the virtual memory share rank in the VM 10 that determines the VM Tier rank from the VM resource share rank management table 1500 (FIG. 15) (SP1901).
  • the VM Tier management program 302 finds a VM Tier rank that matches both the virtual CPU share rank and the virtual memory share rank in the VM Tier rank determination table 1700 (SP1902).
  • the VM Tier management program 302 records the VM Tier rank and the corresponding VM number / virtual CPU share rank / virtual memory share rank in the VM Tier rank management table 1800, and ends the processing (SP1903).
  • the VM Tier rank in the VM 10 can be determined.
  • FIG. 20 is a diagram illustrating a configuration example of a volume layout table.
  • the volume layout table 2000 configures a virtual resource share rank, a VM Tier rank, an LU Tier rank, a storage destination LU number (a logical volume to be provided to the host device 2) for each VM 10 in order to provide a virtual storage resource for the VM.
  • This is a table for managing (LU group).
  • the volume layout table 2000 is a table that is generated and managed by the allocated LU Tier rank determination processing 308 (SP509 in FIG. 5) and the volume layout processing 309 (SP510 in FIG. 5) of the volume management program 303.
  • the volume layout table 2000 includes a VM number 2001 for identifying the VM 10, a virtual CPU share rank 2002, a virtual memory share rank 2003, a VM Tier rank 2004, an LU Tier rank 2005, and a storage destination LU number 2006.
  • the LU Tier rank 2005 is the Tier rank of the available LU determined in the assigned LU Tier rank determination process / volume layout process shown in FIG.
  • the storage destination LU number 2006 is LU information selected according to the distributed storage layout policy (hereinafter, distributed policy) in the allocated LU Tier rank determination process / volume layout process of FIG.
  • This embodiment shows a case where a distribution policy is applied in which data is divided into the same size and distributed and stored in three LUs having the same Tier rank. Therefore, information of three different LU numbers is stored in each entry of the storage destination LU number 2006. Note that the number of LUs to be distributed and stored may be larger or smaller than three.
  • Another distribution policy for example, a distribution policy that stores data in different sizes for each LU, or a distribution policy that determines a storage destination by combining LUs with different Tier ranks may be adopted. Further, the same LU may be shared by a plurality of VMs 10 (for example, “LU15” in row 2012 and row 2014 in FIG. 20).
  • each VM can be assigned a virtual storage resource (represented by LU Tier rank) composed of LUs in the storage tier according to the VM characteristics (represented by VM Tier rank) .
  • FIG. 21 is a flowchart showing LU Tier rank determination processing and volume layout generation / update processing.
  • the allocated LU Tier rank determination processing 308 (SP509) and the volume layout processing 309 (SP510) are executed by the volume management program 303 of the metadata server 5 after the VM Tier rank determination processing 307 (SP508) is completed.
  • the metadata server 5 returns a new VM storage resource allocation response to the hypervisor 9 of the host apparatus 2 and provides the laid out virtual storage resources to the VM 10.
  • the volume management program 303 refers to the LU tier rank management table 1200 and the VM tier rank management table 1800, and determines whether an LU 12 having the same rank as the tier rank of each VM 10 is available (SP2101). For example, if the VM Tier rank 1804 of the VM 10 is “Tier0.5”, the volume management program 303 selects an LU whose LU Tier rank 1204 is “Tier0.5”.
  • the volume management program 303 records the available LU Tier rank in the LU Tier rank 2005 of the volume layout table 2000. (SP2102).
  • the volume management program 303 selects the number of LUs that match the distribution policy in the distributed file system from the LUs corresponding to the LU Tier rank, and selects the LU selected as the storage destination LU number 2006 in the volume layout table 2000.
  • the LU number is recorded, and the process ends (SP2103).
  • an LU group (volume) having an LU tier rank 2005 that satisfies the VM tier rank 2004 can be configured.
  • the volume management program 303 is one layer lower (Tier rank is one higher, for example, Tier 0 if it is Tier 0) .5) is determined whether the LU is available (SP2104).
  • the volume management program 303 executes the LU Tier rank recording of SP2102, the LU selection of SP2103, and the recording in the volume layout table.
  • an LU group (volume) having an LU Tier rank that substantially satisfies the VM Tier rank 2004 can be configured as shown in a row 2014.
  • the volume management program 303 checks whether there is an LU in the lower hierarchy (SP2105).
  • the volume management program 303 executes the processing of SP2104 again to determine whether the LU lower LU can be used.
  • the error reporting method includes error display on the output device 53 of the metadata server 5 and error transmission to the host device 2.
  • the Tier rank and volume layout of the LU provided to the VM 10 can be determined.
  • storage resources suitable for the characteristics of the storage device 13 constituting the data storage 3 and the characteristics of the storage medium 12 mounted on the storage device 13 are stored in the host device 2. It can be provided appropriately according to the characteristics. Furthermore, in the present invention, storage resources suitable for the characteristics of the VM 10 operating on the host device 2 can be allocated to the VM 10 even in an environment where a server virtualization mechanism is adopted for the host device 2. Therefore, the present invention can realize efficient use and effective utilization of storage resources.
  • FIG. 22 is a diagram illustrating a configuration example of a network system according to the second embodiment of the present invention.
  • a feature of the network system 2201 according to the second embodiment of the present invention is that an integrated management server 2217 is added to the network system 1 according to the first embodiment.
  • the integrated management server 2217 is a computer device having an internal configuration similar to that of the metadata server 5 and includes a PC, a mainframe, a server, and the like.
  • the integrated management server 2217 is connected to the host device 2, the storage device 13, the storage management server 4, and the metadata server 5 via the network 7.
  • the types and amounts of various virtual resources (virtual CPU, virtual memory, virtual storage, virtual path, etc.) allocated to the VM 10 are set in the host device 2, the storage device 13, and the network device (not shown). Judging and providing to VM10. For this reason, time is required for allocation to the VM 10, and the characteristics of each device that provides virtual resources cannot be fully utilized, and high processing performance in the VM cannot be realized.
  • the integrated management server 2217 collectively determines and centrally manages the types and amounts of various virtual resources allocated to the VM 10.
  • the integrated management server 2217 includes the storage configuration information 14 obtained from the storage management server 4 by the metadata server 5 and the VM obtained from the hypervisor 9 in the network system 1 according to the first embodiment.
  • the resource information 11 is stored as VM resource information / storage configuration information 2218 in the integrated management server 2217.
  • the metadata server 5 requests and obtains the information that the storage management server 4 and the hypervisor 9 have requested and obtained from the integrated management server 2217.
  • virtual storage resources configured with storage tier volumes corresponding to VM characteristics can be allocated to VMs.
  • FIG. 23 is a sequence diagram showing processing for allocating storage resources to VMs according to the second embodiment of the present invention.
  • the integrated management server 2217 performs the processing performed by the hypervisor 9 and the storage management server 4 of the host device 2. Therefore, before starting the storage resource allocation process to the VM 10, the integrated management server 2217 acquires the VM resource information 11 from the host device 2 and the storage configuration information 14 from the storage management server 4 in advance, and stores the VM resource / Stored as storage configuration information 2218.
  • the VM resource / storage configuration information 2218 may be acquired when the storage resource allocation process to the VM 10 is started, or may be periodically acquired.
  • the integrated management server 2217 When the integrated management server 2217 receives a request for virtual storage resource allocation for a newly created VM from the hypervisor 9 of the host apparatus 2 in SP501, the integrated management server 2217 executes storage resource allocation processing for the VM 10.
  • the integrated management server 2217 When the integrated management server 2217 receives the new VM storage resource allocation response from the metadata server 5 in SP511, it sends the volume layout information to the host apparatus 2 and provides the VM 10 with virtual storage resources.
  • the storage device suitable for the characteristics of the storage device 13 constituting the data storage 3 and the characteristics of the storage medium 12 installed in the storage device is appropriately hosted. 2 can be provided. Furthermore, in the present invention, storage resources suitable for the characteristics of the VM 10 operating on the host device 2 can be appropriately allocated to the VM 10 even in an environment in which the server virtualization mechanism is adopted for the host device 2. In addition, since the integrated management server 2217 can collectively execute each process for providing storage resources to the VM 10 and management of each information, the allocation process can be speeded up.
  • FIG. 24 is a diagram illustrating a configuration example of a network system according to the third embodiment of the present invention.
  • a network system according to a third embodiment of the present invention will be described with reference to FIG.
  • the same parts as those in the first embodiment and the second embodiment are denoted by the same reference numerals, and the difference from the first embodiment and the second embodiment will be mainly described.
  • the metadata server 5 and the integrated management server 2217 operate as separate computer devices.
  • the metadata The computer apparatus in which the server 5 and the integrated management server 2217 are integrated that is, the integrated management / metadata server 2405 is configured to execute the process of allocating storage resources to the VM 10.
  • the integrated management / metadata server 2405 is a computer device having an internal configuration similar to that of the integrated management server 2217 and the metadata server 5, and includes a PC, a mainframe, a server, and the like.
  • the integrated management / metadata server 2405 is connected to the host device 2, the storage device 13, and the storage management server 4 through the second network 7.
  • the integrated management / metadata server 2405 can appropriately allocate virtual storage resources configured with storage tier volumes that conform to the VM characteristics to the VM 10 by the same processing as in the second embodiment.
  • FIG. 25 is a diagram showing a configuration example of a network system according to the fourth embodiment of the present invention.
  • the metadata server 5 and the integrated management server 2217 are configured by different physical computer devices.
  • a computer device in which the metadata server 5 and the integrated management server 2217 are integrated that is, the integrated management / metadata server 2405 executes processing for allocating storage resources to the VM 10. did.
  • the metadata server 5 and the integrated management server 2217 operate as a virtual server that operates on the hypervisor 9 of the host device 2, that is, the metadata virtual server 2505 and the integrated management virtual server 2517. It is the example of a structure to do.
  • the metadata virtual server 2505 and the integrated management virtual server 2517 execute the same processing as the metadata server 5 and the integrated management server 2217 of the network system 2201 according to the second embodiment, so that the above-described first embodiment can be used. Similar to the third embodiment, virtual storage resources configured with storage tier volumes that conform to the VM characteristics can be appropriately allocated to the VM 10.
  • this invention is not limited to the above-mentioned Example, Various modifications are included.
  • the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. Further, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. Further, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.
  • each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit.
  • Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor.
  • Information such as programs, tables, and files for realizing each function may be stored in a memory, a recording device such as a hard disk or SSD, or a recording medium such as an IC card, SD card, or DVD.
  • control lines and information lines indicate what is considered necessary for the explanation, and not all the control lines and information lines on the product are necessarily shown. Actually, it may be considered that almost all the components are connected to each other.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　ネットワークシステムにおいて、ＶＭ特性に適合したストレージリソースをＶＭに提供するため、データ格納先であるストレージリソースのストレージ構成情報と、ストレージリソース割当て先であるＶＭに関するＶＭリソース情報とを収集する。そして、収集したストレージ構成情報に基づき特性の異なるストレージ階層別の記憶領域を構成し、ＶＭリソース情報でＶＭに割当てる記憶領域のストレージ階層を特定する。

Description

ネットワークシステム及びその運用方法
　本発明は、ホスト装置にストレージリソースを割当てるネットワークシステム及びその運用方法に関する。
　近年、社会におけるクラウドサービスに対する需要の高まりにみられるように、ネットワークシステム上で扱われる情報量が増大し、データを格納するのに必要なストレージ容量も急激に増加している。
　ストレージ・サービス・プロバイダ（ＳＳＰ）などは、エンドユーザから要求されるストレージ容量を満足させるためストレージ装置を追加導入し、ネットワークシステムを増強している。なお、ＳＳＰなどでは、ただストレージ装置を追加導入して容量を増やせば良いというわけではなく、エンドユーザが必要とする性能や信頼性などの条件を満足したストレージリソースを要求された容量分、迅速に提供できなければならない。
　特許文献１に、物理ホスト装置上で動作する仮想マシン（Virtual　Machine、以下ＶＭと略す）にストレージリソースを割当てる際、物理ストレージ装置のストレージ仮想化を可能にする方法とシステムが開示されている。この方法とシステムは、ＶＭからのストレージリソース割当てリクエストに含まれる、ストレージの特性と容量（クォータ）に関する要件を満たしたストレージリソースを、ＶＭに割当てるものである。
　また、ストレージリソースを性能面及び容量面で、バランスよく効率的に記憶領域として割当てる技術が、特許文献２に開示されている。特許文献２の技術はストレージシステムとその運用方法に関するものであり、このストレージシステムは、アレイグループを構成するＨＤＤ（Hard　Disk　Drive）などの記憶デバイスのＩ／Ｏ性能を表す性能情報と、記憶デバイスの記憶容量を表す容量情報を保持し、記憶領域に要求される性能要件情報と容量要件情報とを受け付け、要件を満足する記憶デバイスを選択するものである。
米国特許公開２０１０／０２３５８３２号公報 日本特許公開２０１０－１２２８１４号公報　　　　　　　　　（対応米国特許公開２０１０／０１２５７１５号公報）
　ＳＳＰなどは、ストレージ装置の追加導入コストをできるだけ抑えたいが、性能要求の高いユーザと低いユーザが混在してストレージシステムを利用される環境下では、性能要求の高いユーザ側を満足させる必要がある。そのため、ＳＳＰは性能の高い高価なストレージ装置を導入せざるを得ない。高価なストレージ装置の導入費用及び保守などの維持費用が高くなり、ユーザの利用費用も必然的に高くなるので、低い性能しか必要としないユーザから見れば、高い利用料金かつ過剰な性能を持つストレージリソースを利用することとなる。
　また、この問題を解決する従来技術のアプローチでは、性能要求の高いユーザ用と低いユーザ用にネットワークドメインを分離する方法や、割当てるストレージリソースをユーザ毎に個別に詳細設定するなどの方法がある。しかしながら、これらの方法では、管理が困難になることに加え、煩雑になるという問題がある。更に今日では、大量のＶＭの生成を短時間で行なうことが一般的になっており、この様な利用環境下では、ユーザ個々に異なったストレージ装置の利用設定を行なうことは、一層困難で煩雑となる。
　一方、ストレージ装置の性能向上の一手法として、分散ファイルシステムの利用がある。この分散ファイルシステムを実現する方式は複数あるが、標準的なものとしてｐＮＦＳ（parallel　NFS）がある。このｐＮＦＳは、多くの企業や研究者により検討され２０１０年に標準化組織のＩＥＴＦ（Internet　Engineering　Task　Force）により、ＮＦＳ（Network　File　System）（登録商標）バージョン４．１のプロトコル規格として追加された。このｐＮＦＳは、他の分散ファイルシステムと共に今後の普及が見込まれている。
　このｐＮＦＳを用いると、分散ファイルシステムの性能は向上できる。しかしながら、ｐＮＦＳでは、データ格納先のデータストレージを構成するストレージ装置個別の仕様や、ストレージ装置に搭載されるストレージ媒体の種類などは意識しない。このため、ｐＮＦＳは、それぞれのストレージ装置やストレージ媒体の特性を十分に生かしきれていないという課題が存在する。
　そこで本発明は、ネットワークシステムに分散ファイルシステムを採用した環境下において、データストレージを構成する個々のストレージ装置やそのストレージ装置に搭載される個々のストレージ媒体の特性を生かしたストレージリソースを、ホスト装置に提供しシステムの性能を向上させることを目的とする。
　更に、ホスト装置にサーバ仮想化機構を採用した環境下において、サーバ仮想化機構によって動作するＶＭの特性に応じて、適切なストレージリソースをＶＭに割当てることを目的とする。
　この課題を解決するために、本発明のネットワークシステムでは、データ格納先であるストレージリソースのストレージ構成情報と、ストレージリソース割当て先であるＶＭに関するＶＭリソース情報とを収集する。そして、収集したストレージ構成情報に基づき特性の異なるストレージ階層別の記憶領域を構成し、ＶＭリソース情報でＶＭに割当てる記憶領域のストレージ階層を特定する。
　本発明によれば、分散ファイルシステムにおいて、ホスト装置上で動作する仮想マシンへ適切なストレージリソースを割り当てることができるので、システム全体の性能を向上できる。上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
図１は、本発明の第１実施形態に係るネットワークシステムの構成例を示す図である。 図２は、ストレージ装置の内部構成例を示した図である。 図３は、メタデータサーバの内部構成例を示した図である。 図４は、従来のｐＮＦＳ規格に準拠したネットワークシステムの概略図である。 図５は、ＶＭへのストレージリソースを割当てる処理を示すシーケンス図である。 図６は、ストレージＬＵ　Ｔｉｅｒランクの生成・更新処理を示すフローチャートである。 図７は、機種ランク判定テーブルの構成例を示す図である。 図８は、ＬＵランク管理テーブルの構成例を示す図である。 図９は、ストレージ装置における機種ランクを判定する処理を示すフローチャートである。 図１０は、ＬＵを構成するストレージ媒体の媒体ランクの判定処理を示すフローチャートである。 図１１は、ＬＵ　Ｔｉｅｒランク判定テーブルの構成例を示す図である。 図１２は、ＬＵ　Ｔｉｅｒランク管理テーブルの構成例を示す図である。 図１３は、ＬＵ　Ｔｉｅｒランクの判定処理を示すフローチャートである。 図１４は、リソース別シェアランク判定テーブルの構成例を示す図である。 図１５は、ＶＭリソースシェアランク管理テーブルの構成例を示す図である。 図１６は、ＶＭリソース情報の収集処理を示すフローチャートである。 図１７は、ＶＭ　Ｔｉｅｒランク判定テーブルの構成例を示す図である。 図１８は、ＶＭ　Ｔｉｅｒランク管理テーブルの構成例を示す図である。 図１９は、ＶＭ　Ｔｉｅｒランクの判定処理を示すフローチャートである。 図２０は、ボリュームレイアウトテーブルの構成例を示す図である。 図２１は、ＬＵ　Ｔｉｅｒランク判定処理とボリュームレイアウトの生成・更新処理を示すフローチャートである。 図２２は、本発明の第２実施形態に係るネットワークシステムの構成例を示す図である。 図２３は、本発明の第２実施形態に係るＶＭへのストレージリソースを割当てる処理を示すシーケンス図である。 図２４は、本発明の第３実施形態に係るネットワークシステムの構成例を示す図である。 図２５は、本発明の第４実施形態に係るネットワークシステムの構成例を示す図である。
　以下、図面を参照しながら本発明の実施の形態を説明する。なお、以下の説明では、“テーブル”等の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。また、データ構造に依存しないことを示すために“テーブル”を“情報”と呼ぶことができる。
　また、“プログラム”を主語として処理を説明する場合がある。そのプログラムは、プロセッサ、例えば、ＭＰ（Micro　Processor）やＣＰＵ（Central　Processing　Unit）によって実行されるもので、定められた処理をするものである。なお、適宜に記憶資源（例えばメモリ）及び通信インタフェイス装置（例えば、通信ポート）を用いながら行うため、処理の主語がプロセッサとされてもよい。プロセッサは、ＣＰＵの他に専用ハードウェアを有していても良い。コンピュータプログラムは、プログラムソースから各コンピュータにインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアなどで提供されるものであっても良い。
　また、各要素、例えば、コントローラは番号などで識別可能であるが、識別可能な情報であれば、名前など他種の識別情報が用いられても良い。本発明の図及び説明において同一部分には同一符号を付与しているが、本発明が本実施例に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に限定しない限り、各構成要素は複数でも単数でも構わない。
（１）ネットワークシステムの全体構成
　図１は、本発明の第１実施形態に係るネットワークシステム１の構成例を示す図である。ネットワークシステム１により、従来の分散ファイルシステムでは実現できなかったＶＭ（仮想マシン）の特性に応じたストレージリソースのＶＭへの割り当てが可能となる。
　ネットワークシステム１は、１つ以上のホスト装置２、１つ以上のデータストレージ３、ストレージ管理サーバ４、メタデータサーバ５から構成され、ネットワーク６、７及び８で各装置が接続される。
　ホスト装置２は、ＣＰＵやメモリなどの情報処理資源を備えたコンピュータ装置であり、例えばパーソナルコンピュータ（以下ＰＣと略す）や、メインフレーム、サーバなどから構成される。なお、ホスト装置２は、１台のコンピュータ装置で構成しても、複数のコンピュータ装置で構成してもよい。
　また、ホスト装置２は、ＣＰＵやメモリの他に、キーボード、ポインティングデバイス、マイクロフォンなどの情報入力装置（図示せず）と、モニタディスプレイやスピーカなどの情報出力装置（図示せず）を更に備える。
　ホスト装置２は、物理コンピュータ装置上に複数のＶＭ１０を稼動させることが可能な仮想化機構を備えることもできる。本実施例では、広く採用されている仮想化手法である、“ホストＯＳ型仮想化”と“ハイパーバイザ型仮想化”の内、“ハイパーバイザ型仮想化”をホスト装置２に用いた場合を例として、以下説明を行う。ハイパーバイザ型仮想化では、物理コンピュータ装置上でハイパーバイザが仮想化レイヤとなり、この仮想化レイヤ上で複数のＶＭ１０を同時に稼動することができる。
　ハイパーバイザ９は、ＣＰＵ、メモリ、ストレージデバイス、接続パス（以下、パス）といった物理リソースを仮想リソースプールとして管理する。そして、ハイパーバイザ９は、この仮想リソースプールの中から各ＶＭに対し、各ＶＭが必要なリソースを仮想リソースとして提供する。ハイパーバイザ９は、各ＶＭ１０への仮想リソース割当て情報をＶＭリソース情報１１として管理・保持する。
　ネットワーク６、７及び８は、ＳＡＮ（Storage　Area　Network）、ＬＡＮ（Local　Area　Network）、インターネット、公衆回線又は専用回線などの任意のネットワークから構成される。ネットワーク６、７及び８を介したホスト装置２、データストレージ３、ストレージ管理サーバ４、メタデータサーバ５間の通信は、例えば、ネットワーク６、７または８がＳＡＮである場合にはファイバーチャネルプロトコルに従って行われ、ＬＡＮである場合にはＴＣＰ／ＩＰ（Transmission　Control　Protocol／Internet　Protocol）に従って行われる。
　データストレージ３は、一つ以上のストレージ装置からなり、本実施例ではストレージ装置１３ａ、１３ｂ、１３ｃ、１３ｄ、１３ｅの５台のストレージ装置で、１つのデータストレージ３を構成した例を示している（以降、ストレージ装置１３ａ～１３ｅをストレージ装置１３と称することがある）。
　各ストレージ装置１３は、性能・容量・用途が異なるものでも同じものでもよい。なお、ＶＭ１０の特性に応じて、ストレージ階層のＬＵ（Logical　Unit）を複数個使用して構成された仮想ストレージリソースをＶＭ１０に割当てるケースでは、性能・容量・用途が異なるストレージ装置を１台ないし複数台組み合わせて用い様々なストレージ階層を構成した方が、階層選択の自由度が高まり割り当てが容易となる。
　本実施例では、５台のストレージ装置で、コストより部品や接続を多重化することで故障耐性とＩ／Ｏ性能の向上などを目指したハイエンドストレージ装置１３ａ、１３ｂのグループと、コストと性能、故障耐性のバランスを図ることなどを目指したミッドレンジストレージ装置１３ｃ、１３ｄのグループと、データの長期保管の用途で大容量化とデータ改竄防止などを目指したアーカイブストレージ装置１３ｅのグループという３グループを形成している例を示している。上記ストレージ装置以外にローエンドストレージ装置、エントリストレージ装置など廉価であるストレージ装置を複数台使用してデータの分散格納を実現してもよい。
　データストレージ３を構成するストレージ装置１３には、ストレージアクセスプロトコルとして、ファイルベースでアクセスするＮＡＳ（Network　Attached　Storage）、ブロックベースでアクセスするＳＡＮ（Storage　Area　Network）ストレージ、オブジェクトベースでアクセスするＯＳＤ（Object　Storage　Device）などのインタフェイスを用いることができる。本実施例では、ストレージ装置１３にＳＡＮストレージを採用し、ホスト装置２とストレージ装置１３との間をＳＡＮプロトコルで通信するものとして説明する。また、ストレージ装置１３は、ＬＵ１２ａ、１２ｂ、１２ｃ・・・・１２ｏ（以降、ＬＵ１２と総称することがある）を装置内部に１つ以上形成することが可能で、各ＬＵ単位での管理ができる。なお、これらのネットワークでの接続は、有線ないし無線で行うことができる。
　ストレージ管理サーバ４は、ＣＰＵやメモリなどの情報処理資源を備えたコンピュータ装置であり、ホスト装置２と同じように、例えば、ＰＣ、メインフレーム、サーバなどから構成される。ストレージ管理サーバ４は、各ストレージ装置１３とネットワーク８で接続され、各ストレージ装置１３の保守管理端末（図示せず）と通信することで、複数のストレージ装置１３の保守やストレージ構成の設定・変更といったタスクを一元管理することができる。　
　また、ストレージ管理サーバ４は、各ストレージ装置１３に備えている物理リソース（ＣＰＵ数、キャッシュメモリ容量、ストレージ媒体の種類・容量・性能、外部との接続パス数など）の情報やインストールされているソフトウェア（ローカルコピー、同期／非同期リモートコピー、仮想化、シンプロビジョニング、動的階層制御など）の情報、保守情報、ＬＵ構成や複数のＬＵで構成しホスト装置２に提供される論理ボリュームなどの論理構成情報や管理情報などを有するストレージ構成情報１４を持つ。ストレージ管理サーバ４は、ネットワーク７を介しホスト装置２やメタデータサーバ５と接続し、ストレージ構成情報１４をホスト装置２やメタデータサーバ５へ送る。
　メタデータサーバ５は、ＣＰＵやメモリなどの情報処理資源を備えたコンピュータ装置であり、ホスト装置２やストレージ管理サーバ４と同様に、ＰＣ、メインフレーム、サーバなどから構成される。メタデータサーバ５は、ホスト装置２、ストレージ装置１３、ストレージ管理サーバ４とネットワーク７で接続される。
　メタデータサーバ５は、ホスト装置２からデータストレージ３へのデータ入出力を、データストレージ３を構成する複数のストレージ装置１３に跨ってデータの書き込みと読み出しを並行的に実行する分散ファイルシステムを制御する装置である。
　図１に示す構成例は、分散ファイルシステムを実現する方式として、標準化組織ＩＥＴＦで制定されたＮＦＳバージョン４.１のｐＮＦＳ規格を適用した例である。なお、分散ファイルシステムを実現する方式としては、ｐＮＦＳ以外にＨＤＦＳ（HDFS：Hadoop　Distributed　File　System）（登録商標）といった方式があり、それを適用してもよい。
　メタデータサーバ５は、後述（図４）のｐＮＦＳ規格に従って構築した標準的なネットワークシステムのメタデータサーバにｐＮＦＳ規格として備える機能に加え、本発明の特徴である階層化されたＬＵで構成した仮想ストレージリソースを、ＶＭ特性に応じて割当てることを可能にするためのＴｉｅｒ判定・ボリュームレイアウト機能部１５とストレージ／ＶＭ／Ｔｉｅｒ情報１６とを備える。
　Ｔｉｅｒ判定・ボリュームレイアウト機能部１５は、前述のストレージ構成情報１４を用いて各ＬＵのＴｉｅｒランクを決定し、また、各ＶＭ１０が必要とする仮想リソース割当て情報を用いて各ＶＭのＴｉｅｒランクを決定する。そして、Ｔｉｅｒ判定・ボリュームレイアウト機能部１５は、決定されたＬＵのＴｉｅｒランクとＶＭのＴｉｅｒランクとから、ＶＭ１０が必要とするＬＵタイプ（Ｔｉｅｒランク）とその個数で表されるボリュームレイアウトを決定する。
　また、ストレージ／ＶＭ／Ｔｉｅｒ情報１６は、Ｔｉｅｒ判定・ボリュームレイアウト機能部１５により収集されるストレージ構成情報、ＶＭリソース情報、判定し決定したＬＵのＴｉｅｒランクとＶＭ　Ｔｉｅｒランク、決定したボリュームレイアウトなどの情報を格納する。
　なお、ＬＵのＴｉｅｒとは、例えばＬＵを形成するストレージ装置やストレージ媒体のＩ／Ｏ処理速度、故障耐性、コスト、容量などといった、ホスト装置がＬＵに対して必要とする要件において、同様の特性を持つＬＵを一つのカテゴリーにグループ化するものである。また、ＶＭのＴｉｅｒも、そのＶＭに割当てられる仮想ＣＰＵや仮想メモリ容量などから、ミッションクリティカル、ＯＬＴＰ（On-Line　Transaction　Processing）、一般事務用、アーカイブといった用途別に、同一または似通った特性を持つＶＭを一つのカテゴリーにグループ化するものである。
　本発明では、同一または似通った特性を持つＬＵやＶＭを、それぞれの特性が該当するＴｉｅｒというグループに分類し、ランク付けする。つまり、各ＶＭの特性でＶＭ　Ｔｉｅｒランクを決定し、決定されたＶＭ　Ｔｉｅｒランクに合致するＬＵ　Ｔｉｅｒランクを決定する。そして、決定されたＬＵ　Ｔｉｅｒランクに適合するＬＵの種別と、分散ポリシー（データやファイルを分散して格納するストレージ装置の数など）に従ったＬＵ数を判定しボリュームレイアウト（ＬＵレイアウト：格納先ＬＵ情報）を決定する。
　このようなシステム構成及び処理で、ＶＭ特性に応じた適切なストレージリソースをＶＭに割当てることができる。以下、その詳細を説明する。
＜ストレージ装置の内部構成＞
　図２は、ストレージ装置の内部構成例を示した図である。図２では、本実施例でストレージ装置１３として用いるＳＡＮストレージの中で、高価であるが高性能かつ高信頼性であるハイエンドストレージ装置１３ａの構成例を示したものである。ハイエンドストレージ装置１３ａは、汎用的に使用されるＰＣやＰＣサーバとは異なり、ストレージ専用に特化することで性能や拡張性に優れており、用途に応じたスケーラブルな装置構成が可能である。但し、ストレージ装置１３としてＰＣやＰＣサーバを採用することを妨げるものではない。
　図２に示すようにストレージ装置１３ａは、複数のＳＳＤ（Solid　State　Drive）やＨＤＤなどのストレージ媒体２０１から構成するストレージ媒体群２０２と、ストレージ媒体群２０２を制御するコントローラ部２０３とを備える。
　ストレージ媒体群２０２を構成するストレージ媒体２０１として、例えば前述のＳＳＤやＳＡＳ（Serial　Attached　SCSI）ドライブ、ニアラインＳＡＳドライブ、ＳＡＴＡ（Serial　ATA）ドライブなどのＨＤＤの他に、光ディスクなどがある。
　各ストレージ媒体２０１は、コントロール部２０３によりＲＡＩＤ（Redundant　Array　of　Inexpensive　Disks）方式で運用され、ストレージ装置１３ａ全体での高信頼性を実現している。複数のストレージ媒体でＲＡＩＤグループが構成され、各ＲＡＩＤグループが提供する物理的な記憶領域それぞれに、１つ以上のＬＵ１２を生成することができる。ストレージ装置１３ａは、装置内部に３つのＬＵ１２ａ、１２ｂ、１２ｃを生成し、ホスト装置２に提供する。
　また、ホスト装置２からのデータは、このＬＵ１２内に所定サイズのブロック単位で記憶される。なお、分散ファイルシステムでは、１つのデータを分割し複数の異なるストレージ装置１３のＬＵ１２に分散して格納される。複数のＬＵ１２にデータを分散して格納するため、各ＬＵ１２を識別する必要があり、そのために、各ＬＵ１２には、それぞれ固有の識別子（以下、これをＬＵ番号と呼ぶ）が付与され、ＶＭ１０への仮想ストレージリソースの割当ては、このＬＵ番号を用いて行われる。
　本実施例は、ネットワークシステム１で同じ種類のストレージ媒体から構成されるＲＡＩＤグループの物理的な記憶領域上にＬＵ１２を構成し、ＬＵ１２を構成するストレージ媒体の種類毎にグループ分けしてストレージ階層（Ｔｉｅｒ）を形成する例で説明する。　ネットワークシステム１は、同じ種類のストレージ媒体からなるＬＵ１２を２つ以上、異なるストレージ装置１３からそれぞれ選択し、１つのボリュームをこれら複数のＬＵ１２に跨ってレイアウト（形成）する。
　コントローラ部２０３は、チャネルインタフェイス２０４、ＣＰＵ２０５、ローカルメモリ２０６、データ転送コントローラ２０７、キャッシュメモリ２０８、ディスクインタフェイス２０９、通信インタフェイス２１１を備える。ハイエンドストレージ装置１３ａでは、チャネルインタフェイス２０４、ＣＰＵ２０５などのコントローラ部２０３の構成要素を複数使用して冗長化することにより、高信頼性及び高可用性を実現している。
　チャネルインタフェイス２０４は、ストレージ装置１３ａとネットワーク６ないしネットワーク７とを接続する通信コントローラである。チャネルインタフェイス２０４を用いて、ストレージ装置１３は、ホスト装置２からの書込みデータやホスト装置２への読出しデータ、ボリュームレイアウトに関するボリュームレイアウト情報や各種コマンドなどを、ホスト装置２やメタデータサーバ５との間で送受信する。
　ＣＰＵ２０５は、ホスト装置２からのデータ入出力要求（データ書込み要求又はデータ読出し要求）に応答して、ストレージ媒体２０１へのデータ入出力処理などの各種処理を制御するプロセッサである。
　ローカルメモリ２０６は、ＣＰＵ２０５のワークメモリとして使用され、キャッシュメモリ２０８から読み出された様々な制御プログラムやシステム制御情報、ＣＰＵ２０５での演算結果などが格納される。
　データ転送コントローラ２０７は、ＣＰＵ２０５、チャネルインタフェイス２０４、ディスクインタフェイス２０９、キャッシュメモリ２０８間のデータ転送を制御するコントローラである。
　キャッシュメモリ２０８は、チャネルインタフェイス２０４及びディスクインタフェイス２０９間において転送されるデータを一時的に記憶するためのメモリである。また、キャッシュメモリ２０８には、ストレージ装置１３の起動時にストレージ媒体２０１から読み出されたシステム制御情報や、各種制御プログラムなども格納される。ＣＰＵ２０５は、これら制御プログラムを必要に応じてキャッシュメモリ２０８から読み出して実行することにより、ホスト装置２からのストレージ装置１３への要求などを処理する。
　ディスクインタフェイス２０９は、ストレージ媒体２０１とコンローラ部２０３とを接続する通信コントローラであり、例えばファイバーチャネルプロトコルに従って、ストレージ媒体２０１への書込みデータの送信、ストレージ媒体２０１から読み出されたデータの受信及び各種コマンドの送受信などを行う。
　保守管理端末２１０は、ストレージ装置１３の保守及び管理を行う端末で、例えばノート型ＰＣが用いられる。保守管理端末２１０はネットワーク８と接続すると共に通信インタフェイス２１１を介してコントローラ部２０３と接続され、ストレージ装置１３内の障害の有無を監視し、障害発生時に障害箇所や緊急度などの障害情報をディスプレイに表示する機能やシステム管理者に通知する機能を有する。また、システム管理者は、この保守管理端末２１０を用いてストレージ装置１３へのシステム構成の設定や設定された構成の更新などを行うことができる。
　ストレージ装置１３は、前述の構成及び動作により、一つ以上のＬＵ１２を形成してホスト装置２へ提供するとともに、メタデータサーバ５へストレージ装置１３に設定・管理されているストレージ構成情報１４を送信できる。
＜メタデータサーバの内部構成＞
　図３は、メタデータサーバの内部構成例を示した図である。メタデータサーバ５は、ファイルやデータの格納場所および格納方法を示したメタデータを保持するものである。なお、ホスト装置２やストレージ管理サーバ４もメタデータサーバ５と同等の構成をしている。
　メタデータサーバ５は、ＣＰＵ５１、入力装置５２、出力装置５３、通信インタフェイス５４、メモリ５５、記憶デバイス５６を備え、内部バス５７を介して相互に接続される。
　ＣＰＵ５１は、メタデータサーバ５全体を制御するプロセッサである。ＣＰＵ５１は、必要に応じて、メモリ５５に格納されている各種プログラムや、記憶デバイス５６に格納されているストレージ構成情報などを読み出して、後述するＴｉｅｒランク判定やボリュームレイアウト生成などの処理を実行する。
　入力装置５２は、外部からメタデータサーバ５へ情報を入力する装置で、例えば、キーボード、マウス、ポインティングデバイス、マイクロフォンなどである。
　出力装置５３は、メタデータサーバ５の外部へ情報を出力する装置で、例えば、ディスプレイ、スピーカ、プリンタなどである。
　通信インタフェイス５４は、ネットワーク７を介してホスト装置２、データストレージ３、ストレージ管理サーバ４とメタデータサーバ５とを接続するための通信コントローラである。通信インタフェイス５４は、例えばＮＩＣ（Network　Interface　Card）である。
　メモリ５５は、ＯＳやアプリケーションなどの各種プログラムやＣＰＵ５１での演算結果などを一時的に記憶するもので、ＲＡＭ（Random　Access　Memory）などの揮発性メモリまたはフラッシュメモリなどの不揮発性メモリで構成される。このメモリ５５には、本発明を実現するための制御プログラム群であるＴｉｅｒ判定・ボリュームレイアウト機能部１５が格納されている。
　記憶デバイス５６は、各種プログラムや各種情報などを格納する不揮発性デバイスで、例えば、複数のＨＤＤを用いる。この記憶デバイス５６には、本発明の特徴であるストレージ／ＶＭ／Ｔｉｅｒ情報１６が格納されている。
　メタデータサーバ５は、後述（図４）のｐＮＦＳ規格に沿って構築した標準的なネットワークシステムのメタデータサーバにおいてｐＮＦＳ規格として有する機能に加え、本発明の特徴である階層化されたＬＵで構成した仮想ストレージリソースを、ＶＭ特性に応じて割当てることを可能にするためのＴｉｅｒ判定・ボリュームレイアウト機能部１５とストレージ／ＶＭ／Ｔｉｅｒ情報１６とを備える。
　Ｔｉｅｒ判定・ボリュームレイアウト機能部１５は、ＬＵのＴｉｅｒを管理するストレージＬＵＴｉｅｒ管理プログラム３０１、ＶＭのＴｉｅｒを管理するＶＭ　Ｔｉｅｒ管理プログラム３０２及びボリュームレイアウトを管理するボリューム管理プログラム３０３を備える。
　ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、ストレージ装置１３のストレージ構成情報１４を収集するストレージ構成情報収集処理３０４と、収集したストレージ構成情報１４に基づき、各ストレージ装置１３が保持するＬＵ１２のＴｉｅｒランクを判定するストレージＬＵ　Ｔｉｅｒ生成・更新処理３０５を備える。
　ＶＭ　Ｔｉｅｒ管理プログラム３０２は、ＶＭ１０に割当てられる仮想資源リソースに関するＶＭリソース情報を収集するＶＭリソース情報収集処理３０６と、収集したＶＭリソース情報に基づき、各ＶＭ１０のＴｉｅｒランクを判定するＶＭ　Ｔｉｅｒランク判定処理３０７を備える。
　ボリューム管理プログラム３０３は、判定されたＬＵ　ＴｉｅｒランクとＶＭ　Ｔｉｅｒランクに基づき、各ＶＭ１０に割当てるＬＵ１２のＴｉｅｒランクを決定する割当てＬＵ　Ｔｉｅｒランク決定処理３０８と、決定されたＶＭ１０に割当てるＬＵ１２のＴｉｅｒランクと分散ポリシーに基づき、ＶＭ１０に提供される仮想ストレージリソースのボリュームレイアウトを決定するボリュームレイアウト処理３０９を備える。
　ちなみに、分散ポリシーとは、１つのファイルまたはデータブロックを分割して何台のストレージ装置１３に分散して格納するかを決めるものである。例えば、分散ポリシーが３台のストレージ装置１３に分散してファイルやデータブロックを格納するものであれば、同じＴｉｅｒランクを持つ３つのＬＵ１２を３台のストレージ装置それぞれから選択し、ファイルやデータブロックを各ＬＵ１２に分けて同時に格納する。つまり、分散ポリシーが“３”であれば、ボリューム管理プログラム３０３は、同じＴｉｅｒランクのＬＵ１２を３つ選択する。
　また、ボリュームレイアウトとは、分散ポリシーに従って選択された複数のＬＵ１２（格納先ＬＵ）でボリュームを形成し、ＶＭ１０を識別するＶＭ番号と格納先のＬＵ番号群とを対応付けることである。
　ストレージ／ＶＭ／Ｔｉｅｒ情報１６は、Ｔｉｅｒ判定・ボリュームレイアウト機能部１５により収集されたストレージ構成情報１４、ＶＭリソース情報１１、各プログラムで判定したＬＵ１２のＴｉｅｒランクとＶＭ１０のＴｉｅｒランク、決定した割当てＬＵ　Ｔｉｅｒランクやボリュームレイアウトなどの情報である。
　このように、本発明ではメタデータサーバ５のＴｉｅｒ判定・ボリュームレイアウト機能部１５とストレージ／ＶＭ／Ｔｉｅｒ情報１６を備えることにより、ＶＭ特性に合致した仮想ストレージリソースを、各ＶＭ１０へ適切に割当てることが可能となる。
（２）標準的な分散ファイルシステム（従来）
　図４は、従来のｐＮＦＳ規格に準拠したネットワークシステムの概略図である。図４を用いて、従来の標準的な分散ファイルシステム４０の構成及び動作を説明する。
　分散ファイルシステム４０は、ｐＮＦＳクライアント４０１、複数のストレージ装置４０３で構成されるデータストレージ４０２、メタデータサーバ４０４から構成される。ｐＮＦＳクライアント４０１、データストレージ４０２、メタデータサーバ４０４が、図１のホスト装置２、データストレージ３、メタデータサーバ５それぞれに相当する。
　分散ファイルシステム４０では、データの格納先情報であるメタデータの送受信は、ｐＮＦＳプロトコルに従って、ｐＮＦＳクライアント４０１とメタデータサーバ４０４との間で実行される。また、分散ファイルシステム４０では、実データの送受信は、メタデータサーバ４０４を介しないで、ｐＮＦＳクライアント４０１とデータストレージ４０２との間で、所定のストレージアクセスプロトコルに従って実行される。
　メタデータサーバ４０４は、データストレージ４０２を構成する複数ストレージ装置４０３に、実データをどのように分散して格納するかを表すボリュームレイアウトを管理する。このボリュームレイアウトが、メタデータサーバ４０４とデータストレージ４０２との間で所定の制御プロトコルに従って送受信される。
　また、メタデータサーバ４０４は、ｐＮＦＳクライアント４０１がデータストレージ４０２に直接アクセスできるよう、データ格納先を示すメタデータをｐＮＦＳクライアント４０１に提供する。メタデータサーバ４０４は、メタデータとボリュームレイアウト構成の情報からなるメタデータ／レイアウト情報を保持する。
　ｐＮＦＳクライアント４０１は、データストレージ４０２を構成するストレージ装置４０３と、パラレルデータパスで接続される。ｐＮＦＳクライアント４０１は、このパラレルデータパスで、メタデータサーバ４０４から取得したメタデータに基づき、複数のストレージ装置４０３へ同時に並行してアクセスできる。また、メタデータサーバ４０４とデータストレージ４０２の間では、メタデータサーバ４０４の状態とデータストレージ４０２の状態との同期が図られる。
　以上のようなシステム構成とアクセス動作により、ｐＮＦＳ規格に従って構築した分散ファイルシステムでは、このメタデータの通信と実データの通信を分離し、ｐＮＦＳクライアントが複数のストレージ装置へ同時に並行してアクセスすることにより、データストレージへの高速なデータの書き込み、データストレージからの高速なデータ読み出しを実現している。
（３）ＶＭへの仮想ストレージリソース割当て
　図５は、ＶＭへのストレージリソースを割当てる処理を示すシーケンス図である。図５は、ネットワークシステム１において、新規に作成されるＶＭ１０に対する仮想ストレージリソースの割当て要求の発生から、このＶＭ１０への仮想ストレージリソースの割当ての完了までの処理全体を示すシステム装置間のシーケンス図である。このシーケンス図を用いて、ネットワークシステム１を構成する各装置間の要求とそれに対する応答、各装置における処理について、具体的に説明する。なお、処理の主体を装置自体または装置上で動作するハイパーバイザなどのプログラムとしているが、装置やプログラムを動作させるＣＰＵや各種コントローラでもよい。
　まず、ホスト装置２のハイパーバイザ９は、ユーザからの新規ＶＭ作成要求（または、既存ＶＭの構成変更要求など）を受信すると、ホスト装置２の仮想ホストリソース（以下、仮想リソースと略す）である仮想ＣＰＵや仮想メモリを作成要求（または更新要求）の内容に従って、新規ＶＭに割り当てる。なお、割当てる量の尺度として、仮想ＣＰＵでは、ＣＰＵの個数／動作周波数／ＩＯＰＳ（I/O　per　second）などの処理性能がある。また、仮想メモリでは、メモリ容量、アクセス性能などである。新規ＶＭ（以下、新ＶＭ）１０に割当てた仮想リソース情報は、ハイパーバイザ９によりＶＭリソース情報１１として管理される。
　次に、ハイパーバイザ９は、新ＶＭ１０への仮想ストレージリソースの割当て処理を実行する。以上の処理が、図５での新ＶＭ用仮想リソース割当て受付処理である（ＳＰ５０１）。
　ハイパーバイザ９は、メタデータサーバ５に対し新ＶＭ１０で必要とするストレージ容量の情報を含んだ新ＶＭ用ストレージリソース割当て要求を行なう（ＳＰ５０２）。
　メタデータサーバ５は、ハイパーバイザ９からの新ＶＭ用ストレージリソース割当て要求を受信すると、ストレージ管理サーバ４に対し、最新のストレージ構成情報取得を要求する（ＳＰ５０３）。
　ストレージ管理サーバ４は、最新ストレージ構成情報取得要求を受信すると、装置内部に格納してあるストレージ構成情報１４を最新ストレージ構成情報としてメタデータサーバ５に対して送信する（ＳＰ５０４）。なお、ストレージ管理サーバ４は、自身に保管してあるストレージ構成情報１４ではなく、各ストレージ装置１３のストレージ構成情報を再度収集し、最新のストレージ構成情報１４を生成して、メタデータサーバ５に対して送信してもよい。
　次に、メタデータサーバ５は、取得した最新ストレージ構成情報１４に基づき、ストレージＬＵ　Ｔｉｅｒ生成・更新処理を実施し、各ストレージ装置１３に生成されているＬＵ１２のＴｉｅｒランクを判定する（ＳＰ５０５）。
　ＳＰ５０３とＳＰ５０４の処理が、図３に示すストレージＬＵ　Ｔｉｅｒ管理プログラム３０１のストレージ構成情報収集処理３０４に、ＳＰ５０５の処理がストレージＬＵ　Ｔｉｅｒ生成・更新処理３０５に相当する。詳細な処理の動作については、図６から図１２で説明する。
　ストレージＬＵ　Ｔｉｅｒ生成・更新処理（ＳＰ５０５）を完了すると、メタデータサーバ５は、ハイパーバイザ９へ新ＶＭに割当てる仮想ホストリソース情報の提供要求、すなわち、新ＶＭ用割当て仮想リソース情報取得要求を送信する（ＳＰ５０６）。
　ハイパーバイザ９は、メタデータサーバ５からの新ＶＭ用割当て仮想リソース情報取得要求を受信すると、保管しているＶＭリソース情報１１をメタデータサーバ５に対して送信する（ＳＰ５０７）。
　メタデータサーバ５は、取得したＶＭリソース情報１１に基づきＶＭ　Ｔｉｅｒランク判定処理を実施し、各ＶＭ１０のＴｉｅｒランクを判定する（ＳＰ５０８）。
　ＳＰ５０６とＳＰ５０７の処理が、図３に示すＶＭ　Ｔｉｅｒ管理プログラム３０２のＶＭリソース情報収集処理３０６に、ＳＰ５０８の処理がＶＭ　Ｔｉｅｒランク判定処理３０７に相当する。詳細な処理の動作については、図１６から図１８で説明する。
　メタデータサーバ５は、前述のＶＭ　Ｔｉｅｒランク判定処理を終えると、各ＶＭ１０に割当てるＬＵのＴｉｅｒランクを決定する（ＳＰ５０９）。
　メタデータサーバ５は、ＳＰ５０９で決定されたＬＵ　Ｔｉｅｒランクに該当するＬＵ１２を、分散ポリシーで要求される個数分選択し、ＶＭ１０に割り当てる仮想ストレージリソースのボリュームをレイアウトする（ＳＰ５１０）。このボリュームレイアウト情報は、ＶＭ１０を識別するＶＭ番号と、データ格納先であるＬＵ番号、ストレージ容量などで構成する。
　最後に、メタデータサーバ５は、ハイパーバイザ９に、ボリュームレイアウト情報を含めた新ＶＭ用ストレージリソース割当て応答を送信し、レイアウトした仮想ストレージリソースのボリュームをＶＭ１０に提供する（ＳＰ５１１）。
　ＳＰ５０９の処理が、図３に示すボリューム管理プログラム３０３の割当てＬＵ　Ｔｉｅｒランク決定処理３０８に、ＳＰ５１０とＳＰ５１１の処理がボリュームレイアウト処理３０９に相当する。詳細な処理の動作については、図２０及び図２１で説明する。
　本実施例では、ハイパーバイザ９がメタデータサーバ５に対し、ＬＵ１２のＴｉｅｒランクは指定せずストレージ容量のみを指定して新ＶＭ用ストレージ割当て要求を行うケースで説明した。しかしながら、必要なＬＵ１２のＴｉｅｒランクもストレージ容量とともに指定し新ＶＭ用ストレージリソース割当てをメタデータサーバ５に要求するようにしてもよい。この場合、メタデータサーバ５は、取得したＶＭリソース情報１１に基づくＶＭ　Ｔｉｅｒランク判定処理を省き、新ＶＭ用ストレージ割当て要求で指定されたＬＵ　Ｔｉｅｒランクに該当するＬＵ１２を分散ポリシーに従った個数分選択し、新ＶＭ１０に割り当てる論理ボリュームをレイアウトすればよい。
　以上の処理により、本実施例によるネットワークシステムにおいて、ＶＭ特性を満足する仮想ストレージリソース（ストレージ階層のＬＵ）を、ＶＭ１０へ適切に割当てることが可能となる。
　次に、図６から図２０を用いて、ＶＭ１０へのストレージリソース割当て処理の詳細な動作について説明する。
　（３－１）ストレージＬＵ　Ｔｉｅｒ生成・更新処理
　図６は、ストレージＬＵ　Ｔｉｅｒランクの生成・更新処理を示すフローチャートである。本処理は、メタデータサーバ５がハイパーバイザ９から新ＶＭ用ストレージリソース割当て要求を受信してから、ストレージＬＵ　Ｔｉｅｒ生成・更新処理を完了するまでを示したフローチャートで、図５のＳＰ５０２からＳＰ５０５までの処理に相当する。
　ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１が、このフローチャートに示す処理を実行することで、ストレージ装置１３で形成されるＬＵ毎のＴｉｅｒランクを判定・更新することができる。この処理は、メタデータサーバ５がハイパーバイザ９から新ＶＭ用ストレージリソース割当て要求を受信することで開始される。
　最初に、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、ストレージ管理サーバ４に対し、最新のストレージ構成情報取得要求を送信する。そして、ストレージ管理サーバ４は、最新ストレージ構成情報取得要求を受信すると、装置内部に格納してあるストレージ構成情報１４を最新ストレージ構成情報としてメタデータサーバ５に対して送信し、メタデータサーバ５のストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、それを受信する（ＳＰ６０１）。
　次に、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、取得した最新ストレージ構成情報１４により、ストレージ装置１３自体ないしストレージ装置１３のＬＵでストレージＬＵ　Ｔｉｅｒランク（以下、ＬＵ　Ｔｉｅｒランク）の判定が初めてであるかを判定する（ＳＰ６０２）。
　ＬＵ　Ｔｉｅｒランクの判定が初めてであれば（ＳＰ６０２で“Ｙｅｓ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、取得した最新ストレージ構成情報１４から、データストレージ３を構成する各ストレージ装置１３の機種を判定する（ＳＰ６０４）。
　ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、各ストレージＬＵ（以下ＬＵ）１２を構成するストレージ媒体２０１の種類を判定する（ＳＰ６０５）。
　ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、各ＬＵ１２のＴｉｅｒランクを判定し、処理を終了する（ＳＰ６０６）。
　ストレージＬＵ　Ｔｉｅｒの判定が今回初めてでなければ（ＳＰ６０２で“Ｎｏ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、取得した最新ストレージ構成情報と前回取得したストレージ構成情報を比較し、ストレージ構成に変更があるか判定する（ＳＰ６０３）。
　ストレージ構成に変更があれば（ＳＰ６０３で“Ｙｅｓ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、前述のＳＰ６０４からＳＰ６０６の処理を実行し各ＬＵ１２のＴｉｅｒランクを更新し、処理を終了する。
　ストレージ構成に変更がなければ（ＳＰ６０３で“Ｎｏ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、処理を終了する。そして、割当てＬＵ　Ｔｉｅｒランク決定処理では、前回判定した各ストレージ装置における各ＬＵ１２のＴｉｅｒランクを使用する。以上の処理を実行することで、ストレージ装置のＬＵ１２毎にＴｉｅｒランクを設定することができる。
　＜機種ランク判定テーブル＞
　図７は、機種ランク判定テーブルの構成例を示す図である。機種ランクテーブル７００は、各ストレージ装置１３でのランクである機種ランク７０１を機種名称７０２から判定するためのテーブルである。一般的に同一クラスのストレージ装置１３には同一シリーズの名称が付けられていることに着目して、本実施例では、ストレージ構成情報１４の中で、同一シリーズ名称を示す特徴的な箇所を抽出して、抽出情報を機種ランクテーブル７００の機種名称７０２として登録・管理している。
　例えば、行７１１のように“ＳＳＳ”で始まる名称（ＳＳＳ１２３など）を持つ機種は“ハイエンド”のランクとし、行７１２のように“ＢＢＢ”で始まる名称を持つ機種は“ミッドレンジ”のランクとしている。なお、“ＳＳＳ＊＊＊”等の“＊＊＊”部分はどのような名称でもよいことを示す。
　そして、図９の機種ランク判定処理では、ストレージ装置名が機種名称７０２にヒットするかどうかで判断し、ヒットした場合は該当する機種ランク７０１で、ストレージ装置１３のランク付けを行うものである。なお、機種ランクの分類は、同一シリーズ名称を示す情報に依らなくとも、ストレージ管理サーバ４が取得可能な各ストレージ装置１３を特定できる他の情報に基づいて分類してもよい。
　＜ＬＵランク管理テーブル＞
　図８は、ＬＵランク管理テーブルの構成例を示す図である。ＬＵランク管理テーブル８００は、ＬＵ毎（ＬＵ番号８０１）の機種ランク８０２と媒体ランク８０３を管理するテーブルである。後述する機種ランク判定処理（図９）及び媒体ランク判定処理（図１０）で判定されたＬＵ１２に対する機種ランクと媒体ランクを格納して管理する。ＬＵランク管理テーブル８００は、図１４以降で説明するＬＵ　Ｔｉｅｒランクを判定する処理で参照される。
＜機種ランク判定処理＞
　図９は、データストレージ３を構成するストレージ装置１３の機種ランクを判定する処理を示すフローチャートである。ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、機種ランク判定テーブル７００を使用して各ストレージ装置１３の機種ランクを決定し、結果をＬＵランク管理テーブル８００に格納する。この処理が、図６のＳＰ６０４での機種ランク判定処理である。
　本実施例では、ミッションクリティカルなシステムやＯＬＴＰ（On-Line　Transaction　Processing）などには、Ｉ／Ｏ処理の高速化や高信頼性（ＭＴＢＦ（平均故障間隔：Mean　Time　Between　Failures）を大きく、ＭＴＴＲ（平均修復時間：Mean　Time　To　Repair）を小さく）を得られるストレージ装置をハイエンドランクのグループとする。
　また、社内情報を共用するためのファイルサーバやＷｅｂサーバとして使用され、コストと性能のバランスを得られるストレージ装置をミッドレンジランクのグループとする。更に、大容量データのバックアップやデータの長期保存に適するよう構成されたストレージ装置をアーカイブランクのグループとする。そして、それぞれのグループにどのような機種が属するかを示す機種ランク判定テーブル７００を用いて、ストレージ装置１３としてのランク付けを行うものである。その具体的な動作を説明する。
　最初に、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、取得した最新ストレージ構成情報１４から各ストレージ装置１３の機種名称と、装置内部に構成されているＬＵ１２の情報であるＬＵ番号を抽出する。ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、抽出した機種名称を機種ランク判定テーブル７００の機種名称８０２と照合し、機種ランクが“ハイエンド”であるハイエンドランクに登録されたストレージ装置であるかを判定する（ＳＰ９０１）。
　ハイエンドランクに登録されたストレージ装置であれば（ＳＰ９０１で“Ｙｅｓ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、図８のＬＵランク管理テーブル８００にＬＵ番号とハイエンドランクであることを記録し、処理を終了する（ＳＰ９０２）。例えば、ストレージ装置１３ａが番号００から０２のＬＵを有していれば、ＬＵ番号８０１が“ＬＵ００”から“ＬＵ０２”に対応する機種ランク８０２のエントリに“ハイエンド”と格納する。
　ストレージ装置１３がハイエンドランクに登録されたストレージ装置でなければ（ＳＰ９０１で“Ｎｏ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、ミッドレンジランクに登録されたストレージ装置であるか判定する（ＳＰ９０３）。ミッドレンジランクに登録されたストレージ装置であれば（ＳＰ９０３で“Ｙｅｓ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、ＬＵランク管理テーブル８００にＬＵ番号とミッドレンジランクであることを記録し、処理を終了する（ＳＰ９０２）。
　ストレージ装置１３がミッドレンジランクに登録されたストレージ装置でなければ（ＳＰ９０３で“Ｎｏ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、アーカイブランクに登録されたストレージ装置であるか判定する（ＳＰ９０４）。アーカイブランクに登録されたストレージ装置であれば（ＳＰ９０４で“Ｙｅｓ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、ＬＵランク管理テーブル８００にＬＵ番号とアーカイブランクであることを記録し、処理を終了する（ＳＰ９０２）。
　ストレージ装置１３がアーカイブランクに登録されたストレージ装置でなければ（ＳＰ９０４で“Ｎｏ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、行８１４のようにＬＵランク管理テーブル８００へＬＵ番号と機種ランクなしであること、すなわち、“機種情報なし”と記録し、処理を終了する（ＳＰ９０５）。
　本実施例では、機種ランクをハイエンド、ミッドレンジ、アーカイブ、機種情報なしの４つに分類しているが、ランクの分類数はこれよりも多くても少なくてもよい。また、ランク基準もこれら性能や用途によるハイエンド、ミッドレンジ、アーカイブといった分類でなくともよい。
　上記ＳＰ９０１からＳＰ９０５までの機種ランク判定処理により、ストレージ装置１３で構成するＬＵ情報の取得と、機種ランクの判定ができ、ＬＵランク管理テーブル８００のＬＵ番号８０１及び機種ランク８０２のエントリに該当する情報を格納できる。
＜媒体ランク判定処理＞
　図１０は、ＬＵを構成するストレージ媒体の媒体ランクの判定処理を示すフローチャートである。ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１が、ＬＵ１２を構成するストレージ媒体２０１の種類を判定しランク付けを行い、ランク付けした結果をＬＵランク管理テーブル８００の媒体ランク８０３のエントリに格納する。この処理が、図６のＳＰ６０５での媒体ランク判定処理である。
　本実施例では、スループットやＩ／Ｏレスポンスタイムで優れた性能を持つストレージ媒体２０１としてＳＳＤを媒体ランク“Ａ”、ＳＳＤに次ぐ性能を持つストレージ媒体としてＳＡＳドライブを媒体ランク“Ｂ”、それ以外のストレージ媒体を媒体ランク“Ｃ”と３つに分類した場合を示している。
　ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、取得した最新のストレージ構成情報１４に基づき、各ＬＵ１２を構成するストレージ媒体２０１が、ＳＳＤであるかを判定する（ＳＰ１００１）。
　ＬＵ１２を構成するストレージ媒体２０１がＳＳＤであれば（ＳＰ１００１で“Ｙｅｓ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、行８１１のように、ＬＵランク管理テーブル８００の媒体ランク８０３のエントリに“Ａ”を記録し、処理を終了する（ＳＰ１００２）。
　ＬＵを構成するストレージ媒体がＳＳＤでなければ（ＳＰ１００１で“Ｎｏ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、ストレージ媒体がＳＡＳドライブであるか判定する（ＳＰ１００３）。
　ＬＵを構成するストレージ媒体がＳＡＳドライブであれば（ＳＰ１００３で“Ｙｅｓ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、行８１２のように、ＬＵランク管理テーブル８００に媒体ランク８０３のエントリに“Ｂ”を記録し、処理を終了する（ＳＰ１００４）。
　ＬＵを構成するストレージ媒体がＳＡＳドライブでなければ（ＳＰ１００３で“Ｎｏ”）、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、行８１３のように、ＬＵランク管理テーブル８００に媒体ランク８０３のエントリに“Ｃ”を記録し、処理を終了する（ＳＰ１００５）。
　本実施例では、媒体ランクをＡ、Ｂ及びＣの３段階に分類しているが、ランク段階の数はこれよりも多くても少なくてもよい。また、本実施例では、判定する媒体の種別をＳＳＤ、ＳＡＳ、ＳＳＤ及びＳＡＳ以外の３つに分類して判定しているが、例えば、ニアラインＳＡＳドライブ、ＳＡＴＡドライブ、光ドライブ、ＦＣ（Fibre　Channel）ドライブやＦｌａｓｈモジュールなどを用いて細分化して分類してもよい。また本実施例では、各ＬＵ１２が同種のストレージ媒体で構成されている場合で説明しているが、異種のストレージ媒体で構成されているものがある場合には、例えば異種ストレージ媒体構成ランク“Ｄ”などを設けて分類してもよい。
　本発明では、上記ＳＰ１００１からＳＰ１００５までのストレージ媒体判定処理を実行することで、ＬＵを構成するストレージ媒体のランク付けができ、ＬＵランク管理テーブル８００の媒体ランク８０３のエントリにランク付けした結果を格納し、ＬＵ番号とそれに対応する機種ランク及び媒体ランクを管理することができる。
＜＜ＬＵ　Ｔｉｅｒランクの判定＞＞
＜ＬＵ　Ｔｉｅｒランク判定テーブル＞
　図１１は、ＬＵ　Ｔｉｅｒランク判定テーブルの構成例を示す図である。ＬＵ　Ｔｉｅｒランク判定テーブル１１００は、ストレージ装置１３内のＬＵ１２の機種ランク１２０１と媒体ランク１２０２から、ＬＵ　Ｔｉｅｒランクを判定するもので、機種ランク１１０１、媒体ランク１１０２及びＬＵ　Ｔｉｅｒランク１１１０で構成される。
　本実施例では、Ｔｉｅｒ　０を最高ランク、Ｔｉｅｒ　３を最低ランクとし、高速なＩ／Ｏ処理が可能なＬＵをより高いランクのＬＵ　Ｔｉｅｒに、Ｉ／Ｏ処理は低速であるが低コストで大容量記憶が必要であるＬＵをより低いランクのＬＵ　Ｔｉｅｒに分類した場合を示している。例えば、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、機種ランク１１０１が“ハイエンド”、媒体ランク１１０２が“Ａ”であるＬＵ　Ｔｉｅｒランク１１１０は“Ｔｉｅｒ０”と判定し、“ミッドレンジ”で“Ｂ”であるＬＵ　Ｔｉｅｒランク１１１０は“Ｔｉｅｒ１．５”と判定する。
　本実施例のＬＵ　Ｔｉｅｒランク判定テーブル１１００では、ＬＵランク管理テーブル８００で４段階に分類した機種ランク１１０１と、３段階に分類した媒体ランク１１０２により対応したＬＵ　Ｔｉｅｒランクを判定するテーブルを示している。なお、また、ＬＵ　Ｔｉｅｒランク判定テーブル１１００は、機種ランクを３段階以下または５段階以上に分類して構成してもよく、媒体ランクも同じく２段階ないし４段階以上に分類して構成してもよい。
　また、本実施例ではＬＵ　Ｔｉｅｒランクを、“Ｔｉｅｒ０”、“Ｔｉｅｒ０.５”、“Ｔｉｅｒ１”、“Ｔｉｅｒ１．５”、“Ｔｉｅｒ２”、“Ｔｉｅｒ２．５”、“Ｔｉｅｒ３”と７つの段階に分類しているが、分類数はこれよりも多くても少なくてもよい。各機種ランクと各媒体ランクで判定したＬＵ　Ｔｉｅｒランクは一例であって、本実施例と異なるＬＵ　Ｔｉｅｒランクの判定の仕方、例えば、機種ランクの代わりに　“高”、“中”、“低”という３段階の機種性能ランクを、媒体ランクの代わりに　“高速”、“速い”、“普通”、“遅い”という４段階の媒体性能ランクを定義してＬＵ　Ｔｉｅｒランクを判定してもよい。
　＜ＬＵ　Ｔｉｅｒランク管理テーブル＞
　図１２は、ＬＵ　Ｔｉｅｒランク管理テーブルの構成例を示す図である。ＬＵ　Ｔｉｅｒランク管理テーブル１２００は、ＬＵ番号１２０１と、それに対応する各種ランクを、機種ランク１２０２、媒体ランク１２０３及びＬＵ　Ｔｉｅｒランク１２０４の各エントリに格納し管理するテーブルである。ＬＵ番号１２０１、機種ランク１２０２、媒体ランク１２０３には、ＬＵランク管理テーブル８００の情報が格納される。ＬＵ　Ｔｉｅｒランク１２０４には、機種ランクと媒体ランクからＬＵ　Ｔｉｅｒランク判定テーブル１１００で判定したＬＵ　Ｔｉｅｒランクの情報が格納される。なお、このＬＵ　Ｔｉｅｒランク管理テーブル１２００は、後述のボリューム管理プログラム３０３の割当てＬＵ　Ｔｉｅｒランク決定処理が参照し、ＶＭ１０に割当てるストレージリソースのＬＵ　Ｔｉｅｒランクを決定する。
　行１２１１に示すように、ＬＵ番号１２０１が“ＬＵ００”であるＬＵは、機種ランク１２０２のエントリに“ハイエンド”、媒体ランク１２０３のエントリに“Ａ”、ＬＵ　Ｔｉｅｒランク１２０４のエントリに“Ｔｉｅｒ０”が格納される。同じく、行１２１２の“ＬＵ１０”には“ミッドレンジ”、“Ｂ”、“Ｔｉｅｒ１．５”が格納され管理される。行１２１３、行１２１４も同様である。
＜ＬＵ　Ｔｉｅｒランクの判定処理＞
　図１３は、ＬＵ　Ｔｉｅｒランクの判定処理を示すフローチャートである。ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１が、ＬＵ　Ｔｉｅｒのランク付けを行い、ランク付けした結果をＬＵ　Ｔｉｅｒランク管理テーブル１２００に格納する。この処理が、図６のＳＰ６０６ＬＵ　Ｔｉｅｒランク判定処理に該当する。
　まず、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、判定を行うＬＵ１２の機種ランク情報と媒体ランク情報を、ＬＵランク管理テーブル８００から取得する（ＳＰ１３０１）。例えば、行８１３に示すように、ＬＵ番号８０１が“ＬＵ２０”であるＬＵのＴｉｅｒランクを判定するため、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、機種ランク８０２より“アーカイブ”という機種ランク情報を、媒体ランク８０３より“Ｃ”という媒体ランク情報を取得する。
　次に、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、ＬＵ　Ｔｉｅｒランク判定テーブル１１００から、取得した機種ランク情報と媒体ランク情報の双方に合致するＬＵ　Ｔｉｅｒランク情報を取得する（ＳＰ１３０２）。
　機種ランク情報が“アーカイブ”、媒体ランク情報“Ｃ”であるＬＵ　Ｔｉｅｒランク１１１０は“Ｔｉｅｒ３”なので、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、Ｔｉｅｒランク情報として“Ｔｉｅｒ３”を取得する。
　ＬＵ　Ｔｉｅｒランク情報を取得したら、ストレージＬＵ　Ｔｉｅｒ管理プログラム３０１は、ＬＵ　Ｔｉｅｒランク管理テーブル１２００に、取得したＬＵ番号、機種ランク情報、媒体ランク情報及び判定結果であるＬＵ　Ｔｉｅｒランク情報を記録し、処理を終了する（ＳＰ１３０３）。
　上記のＳＰ１３０１からＳＰ１３０３までの処理を実行することで、ＬＵ１２に対応するＬＵ　Ｔｉｅｒランクを決定することができる。
（３－２）ＶＭ　Ｔｉｅｒランク判定
＜＜ＶＭリソースシェアランク判定＞＞
＜リソース別シェアランク判定テーブル＞
　図１４は、リソース別シェアランク判定テーブルの構成例を示す図である。リソース別シェアランク判定テーブルは、仮想ＣＰＵ割当てシェア１４０１とそれに対応した仮想ＣＰＵシェアランク１４０２が定義された仮想ＣＰＵシェアランク判定テーブル１４００と、仮想メモリ割当てシェア１４１１とそれに対応した仮想メモリシェアランク１４１２が定義された仮想メモリシェアランク判定テーブル１４１０の２種類のテーブルからなる。
　ＶＭ　Ｔｉｅｒ管理プログラム３０２は、ハイパーバイザ９から取得した新ＶＭ用割当て仮想リソース情報１１での仮想ＣＰＵ割当てシェア及び仮想メモリ割当てシェアから、仮想ＣＰＵシェアランク判定テーブル１４００及び仮想メモリシェアランク判定テーブル１４１０を用い、仮想ＣＰＵシェアランク及び仮想メモリシェアランクを判定するものである。
　本実施例では、割当てシェア１４０１／１４１１及びシェアランク１４０２／１４１２を３段階に分類しているが、分類の数はこれよりも多くても少なくてもよい。また、判定基準として、ＣＰＵ及びメモリ以外のストレージ装置１２の接続ポート数、ネットワークのパス帯域（kbps：kilo　bits　per　second）やストレージ容量（GB：Giga　Bytes）といった別の対象を採用してもよい。更に、割当てシェアではなく、各ＶＭに割当てられた仮想リソース量を取得し、その仮想リソース量でランクを決定してもよいし、仮想リソース量の総計から各ＶＭのシェアを算出してもよい。例えば、ホスト装置２が複数存在する場合、各ホスト装置２で動作するＶＭに割当てられた仮想リソース量を取得し、仮想リソース量の総計から各ＶＭのシェアを算出することで、ホスト装置２毎の各ＶＭのシェアランクを決定できる。
＜ＶＭリソースシェアランク管理テーブル＞
　図１５は、ＶＭリソースシェアランク管理テーブルの構成例を示す図である。ＶＭリソースシェアランク管理テーブル１５００は、後述のＶＭリソース情報収集処理（図１６）での収集・判定結果を管理するテーブルである。ＶＭリソースシェアランク管理テーブル１５００は、各ＶＭ番号１５０１に対し、仮想ＣＰＵシェアランク１５０２と仮想メモリシェアランク１５０３に関する情報が記録され管理されている。このＶＭ　Ｔｉｅｒ判定情報テーブル１５００は、ＶＭ　Ｔｉｅｒランクを決定するため、ＶＭ　Ｔｉｅｒ管理プログラム３０２のＶＭ　Ｔｉｅｒランク判定処理３０７（図１９）で参照される。
＜ＶＭリソース情報収集処理＞
　図１６は、ＶＭリソース情報の収集処理を示すフローチャートである。ＶＭリソース情報収集処理３０６（図３）は、ハイパーバイザ９から新ＶＭ用割当て仮想リソース情報（ＶＭリソース情報１１）を取得し、ＶＭリソースシェアランク管理テーブル１５００に記録するものである。
　最初に、ＶＭ　Ｔｉｅｒ管理プログラム３０２は、ハイパーバイザ９から新ＶＭ用割当て仮想リソース情報（ＶＭリソース情報１１）を取得する（ＳＰ１６０１）。
　ＶＭ　Ｔｉｅｒ管理プログラム３０２は、取得した新ＶＭ用割当て仮想リソース情報でのＶＭリソース割当て方式が、“高”、“標準”、“低”で表されたシェアランク方式であるかを判断する（ＳＰ１６０２）。
　ここでシェアランク方式とは、例えば割当てられている仮想メモリ容量を“２ＧＢ”といった定量情報ではなく、シェアランク“高”、“標準”、“低”といった定性情報で表された方式である。このシェアランク方式での判定により、同時に稼動する他のＶＭ１０と比較した優先順位に基づき、そのＶＭが使用できる仮想リソース量をリソース全体から算出して決定できるので、ストレージリソースのＶＭ１０への割当て容量の不足や偏りを防止できる。
　ＶＭへの仮想リソースの割当て方式がシェアランク方式であれば（ＳＰ１６０２で“Ｙｅｓ”）、ＶＭ　Ｔｉｅｒ管理プログラム３０２は、そのシェアランク方式の情報（高・標準・低）を取得する（ＳＰ１６０３）。そして、ＶＭ　Ｔｉｅｒ管理プログラム３０２は、取得したＶＭリソース情報１１でのＶＭ番号、取得した仮想ＣＰＵシェアランク及び仮想メモリシェアランクをＶＭリソースシェアランク管理テーブル１５００の各エントリに格納する（ＳＰ１６０４）。ＶＭ　Ｔｉｅｒ管理プログラム３０２は、情報の格納後に、処理を終了する。
　仮想リソースの割当て方式がシェアランク方式でなければ（ＳＰ１６０２で“Ｎｏ”）、ＶＭ　Ｔｉｅｒ管理プログラム３０２は、ＶＭリソース情報１１（本実施例では、シェア（％））をリソース別シェアランク判定テーブル（仮想ＣＰＵシェアランク判定テーブル１４００及び仮想メモリシェアランク判定テーブル１４１０）と比較して、仮想リソース毎のシェアランクを求める（ＳＰ１６０５）。そして、ＶＭ　Ｔｉｅｒ管理プログラム３０２は、取得したＶＭリソース情報１１でのＶＭ番号、求めた仮想ＣＰＵシェアランク及び仮想メモリシェアランクをＶＭリソースシェアランク管理テーブル１５００の各エントリに格納する（ＳＰ１６０４）。ＶＭ　Ｔｉｅｒ管理プログラム３０２は、情報の格納後に、処理を終了する。
　本実施例では、ＶＭリソースシェアランクを仮想リソースのシェア（％）で判定しているが、シェアではなく実際の割当て量で判定してもよい。また、ＶＭリソースシェアランクは、仮想リソース量に関する情報に加えてＶＭに搭載されるＯＳやアプリケーションの情報、同時に作成されるＶＭ数などにより分類してもよいし、仮想リソース量とは切り離して分類してもよい。
　また、複数のホスト装置（ホスト装置２からホスト装置２ｎ）上で動作する全てのＶＭの仮想リソース量を取得して、仮想リソース全体に占める割合を算出することで、ＶＭ割当てリソースシェアのランクを決定してもよい。
＜＜ＶＭ　Ｔｉｅｒランクの判定＞＞
＜ＶＭ　Ｔｉｅｒランク判定テーブル＞
　図１７は、ＶＭ　Ｔｉｅｒランク判定テーブルの構成例を示す図である。ＶＭ　Ｔｉｅｒランク判定テーブル１７００は、各ＶＭ１０の仮想メモリシェアランク１７０１と仮想ＣＰＵシェアランク１７０２で、各ＶＭ１０のＴｉｅｒランク１７１０を決定するためのテーブルである。
　本実施例では、３段階の仮想メモリシェアランク１７０１と３段階の仮想ＣＰＵシェアランク１７０２からＶＭ　Ｔｉｅｒランクを求めるＶＭ　Ｔｉｅｒランク判定テーブル１７００を示している。しかしながら、ＶＭ　Ｔｉｅｒランク判定テーブル１７００は、仮想ＣＰＵシェアランクと仮想メモリシェアランクの分類に従ったテーブルであればよく、ＶＭ　Ｔｉｅｒランク１７１０は、２段階ないし４段階以上の仮想ＣＰＵシェアランクと２段階ないし４段階以上の仮想メモリシェアランクとから求められてもよい。
　また、本実施例ではＶＭ　Ｔｉｅｒランク１７１０を、Ｔｉｅｒ０、Ｔｉｅｒ０.５、Ｔｉｅｒ１、Ｔｉｅｒ１．５、Ｔｉｅｒ２の５つに分類しているが、分類数はこれよりも多くても少なくてもよい。本実施例では、仮想メモリシェアランク１７０１と仮想ＣＰＵシェアランク１７０２によりＶＭ　Ｔｉｅｒランク１７１０を判定し求めたが、他の仮想リソースシェアランク（例えば、ＣＰＵの動作周波数、ストレージ装置１３への接続ポート数、接続ネットワークのパス帯域など）でＶＭ　Ｔｉｅｒランクを判定してもよいし、他の仮想リソースシェアランクを追加して判定してもよい。
　＜ＶＭ　Ｔｉｅｒランク管理テーブル＞
　図１８は、ＶＭ　Ｔｉｅｒランク管理テーブルの構成例を示す図である。ＶＭ　Ｔｉｅｒランク管理テーブル１８００は、ＳＰ５０８（図５）のＶＭ　Ｔｉｅｒランク判定処理３０７（具体的な動作は、図１９のフローチャート）によりランク付けされたＶＭ　Ｔｉｅｒランクを、仮想ＣＰＵ及び仮想メモリのシェアランクと一緒に管理するテーブルある。
　ＶＭ　Ｔｉｅｒランク管理テーブル１８００には、各ＶＭ番号１８０１に対し、ＶＭ　Ｔｉｅｒ管理プログラム３０２で取得または求められた仮想ＣＰＵシェアランク１８０２、仮想メモリシェアランク１８０３、ＶＭ　Ｔｉｅｒランク１８０４に関する情報が格納され管理される。ＶＭリソースシェアランク管理テーブルの内容を、ＶＭ　Ｔｉｅｒランク管理テーブル１８００に設定してもよい。
　ＶＭ　Ｔｉｅｒランク１８０４は、ＶＭ　Ｔｉｅｒ管理プログラム３０２により、仮想ＣＰＵシェアランク１８０２と仮想メモリシェアランク１８０３をＶＭ　Ｔｉｅｒランク判定テーブル１７００に照し合せて求められる。
　このＶＭ　Ｔｉｅｒランク管理テーブル１８００は、後述のボリューム管理プログラム３０３の割当てＬＵ　Ｔｉｅｒランク決定処理３０８（図２１）が参照し、ＶＭに割当てるストレージリソースのＬＵ　Ｔｉｅｒランクを決定する。
　＜ＶＭ　Ｔｉｅｒランクの判定処理＞
　図１９は、ＶＭ　Ｔｉｅｒランクの判定処理を示すフローチャートである。ＶＭ　Ｔｉｅｒランク判定処理３０７は、ＶＭリソース情報収集処理（図１６）に続き実施される処理で、ＶＭ　Ｔｉｅｒランクの決定とＶＭ　Ｔｉｅｒランク管理テーブル１８００へのランク格納を行う。
　まず、ＶＭ　Ｔｉｅｒ管理プログラム３０２は、ＶＭリソースシェアランク管理テーブル１５００（図１５）から、ＶＭ　Ｔｉｅｒランクを判定するＶＭ１０での仮想ＣＰＵシェアランクと仮想メモリシェアランクを取得する（ＳＰ１９０１）。
　次に、ＶＭ　Ｔｉｅｒ管理プログラム３０２は、ＶＭ　Ｔｉｅｒランク判定テーブル１７００で、仮想ＣＰＵシェアランクと仮想メモリシェアランクの双方に合致するＶＭ　Ｔｉｅｒランクを見つけ出す（ＳＰ１９０２）。
　ＶＭ　Ｔｉｅｒ管理プログラム３０２は、ＶＭ　Ｔｉｅｒランク管理テーブル１８００に、ＶＭ　Ｔｉｅｒランクと、対応するＶＭ番号／仮想ＣＰＵシェアランク／仮想メモリシェアランクとを記録し、処理を終了する（ＳＰ１９０３）。
　以上のＳＰ１９０１からＳＰ１９０３までの処理を実行することで、ＶＭ１０におけるＶＭ　Ｔｉｅｒランクを決定できる。
（３－３）割当てＬＵ　Ｔｉｅｒランク決定・ボリュームレイアウト
＜ボリュームレイアウトテーブル＞
　図２０は、ボリュームレイアウトテーブルの構成例を示す図である。ボリュームレイアウトテーブル２０００は、ＶＭに対する仮想ストレージリソースを提供するために、各ＶＭ１０に対する仮想リソースのシェアランク、ＶＭ　Ｔｉｅｒランク、ＬＵ　Ｔｉｅｒランク、格納先ＬＵ番号（ホスト装置２に提供する論理ボリュームを構成するＬＵ群）を管理するテーブルである。
　ボリュームレイアウトテーブル２０００は、ボリューム管理プログラム３０３の割当てＬＵ　Ｔｉｅｒランク決定処理３０８（図５のＳＰ５０９）とボリュームレイアウト処理３０９（図５のＳＰ５１０）により生成され管理されるテーブルである。
　ボリュームレイアウトテーブル２０００は、ＶＭ１０を識別するＶＭ番号２００１、仮想ＣＰＵシェアランク２００２、仮想メモリシェアランク２００３、ＶＭ　Ｔｉｅｒランク２００４、ＬＵ　Ｔｉｅｒランク２００５、格納先ＬＵ番号２００６で構成する。
　ＬＵ　Ｔｉｅｒランク２００５は、図２１に示す割当てＬＵ　Ｔｉｅｒランク決定処理・ボリュームレイアウト処理で判定された利用可能なＬＵのＴｉｅｒランクである。
　格納先ＬＵ番号２００６は、同じく図２１の割当てＬＵ　Ｔｉｅｒランク決定処理・ボリュームレイアウト処理で、分散格納レイアウトポリシー（以下、分散ポリシー）に従って選択されたＬＵ情報である。
　本実施例は、データを同一サイズに分割して、同一のＴｉｅｒランクを有する３つのＬＵへ分散して格納するという分散ポリシーを適用した場合を示す。そのため、格納先ＬＵ番号２００６の各エントリには、３つの異なるＬＵ番号の情報が格納される。なお、分散して格納させるＬＵの数は３つより大きくても小さくてもよい。また、別の分散ポリシー、例えば、データをＬＵ毎に異なるサイズで格納する分散ポリシーや、異なるＴｉｅｒランクのＬＵを組み合わせて格納先を決定する分散ポリシーなどを採用してもよい。また、同じＬＵを複数のＶＭ１０で共有して使用するようにしてもよい（例えば、図２０の行２０１２と行２０１４の“ＬＵ１５”）。
　ボリュームレイアウトテーブルが示すように、各ＶＭに対し、ＶＭの特性（ＶＭ　Ｔｉｅｒランクで表される）に応じたストレージ階層のＬＵで構成した仮想ストレージリソース（ＬＵ　Ｔｉｅｒランクで表される）を割当てられる。
　＜ＬＵ　Ｔｉｅｒランク判定処理とボリュームレイアウトの生成・更新処理＞
　図２１は、ＬＵ　Ｔｉｅｒランク判定処理とボリュームレイアウトの生成・更新処理を示すフローチャートである。この割当てＬＵ　Ｔｉｅｒランク決定処理３０８（ＳＰ５０９）とボリュームレイアウト処理３０９（ＳＰ５１０）は、ＶＭ　Ｔｉｅｒランク判定処理３０７（ＳＰ５０８）が完了した後、メタデータサーバ５のボリューム管理プログラム３０３により実行される。そして、ボリュームのレイアウトが完了すると、メタデータサーバ５は、ホスト装置２のハイパーバイザ９に新ＶＭ用ストレージリソース割当て応答を返信し、レイアウトした仮想ストレージリソースをＶＭ１０に提供する。
　最初に、ボリューム管理プログラム３０３は、ＬＵ　Ｔｉｅｒランク管理テーブル１２００とＶＭ　Ｔｉｅｒランク管理テーブル１８００を参照し、各ＶＭ１０のＴｉｅｒランクと同じランクのＬＵ１２が利用可能か判定する（ＳＰ２１０１）。例えば、ＶＭ１０のＶＭ　Ｔｉｅｒランク１８０４が“Ｔｉｅｒ０．５”であれば、ボリューム管理プログラム３０３は、ＬＵ　Ｔｉｅｒランク１２０４が“Ｔｉｅｒ０．５”であるＬＵを選び出す。
　次に、ＶＭ　Ｔｉｅｒに該当するＴｉｅｒのＬＵ　が利用可能であれば（ＳＰ２１０１で“Ｙｅｓ”）、ボリューム管理プログラム３０３は、ボリュームレイアウトテーブル２０００のＬＵ　Ｔｉｅｒランク２００５に、利用可能なＬＵ　Ｔｉｅｒランクを記録する（ＳＰ２１０２）。
　そして、ボリューム管理プログラム３０３は、ＬＵ　Ｔｉｅｒランクに該当するＬＵの中から、分散ファイルシステムでの分散ポリシーに合致した個数のＬＵを選択し、ボリュームレイアウトテーブル２０００の格納先ＬＵ番号２００６に選択したＬＵのＬＵ番号を記録し、処理を終了する（ＳＰ２１０３）。
　以上のＳＰ２１０１からＳＰ２１０３までの処理で、行２０１１、２０１２、２０１３に示すように、ＶＭ　Ｔｉｅｒランク２００４を満足するＬＵ　Ｔｉｅｒランク２００５を有するＬＵグループ（ボリューム）を構成できる。
　ＶＭのＴｉｅｒに該当するＴｉｅｒのＬＵが利用可能でなければ（ＳＰ２１０１で“Ｎｏ”）、ボリューム管理プログラム３０３は、一階層下位（Ｔｉｅｒランクが１つ大きい、例えば、Ｔｉｅｒ０であったならば、Ｔｉｅｒ０．５）のＬＵが利用可能か判定する（ＳＰ２１０４）。
　一階層下位のＬＵが利用可能であれば（ＳＰ２１０４で“Ｙｅｓ”）、ボリューム管理プログラム３０３は、ＳＰ２１０２のＬＵ　Ｔｉｅｒランクの記録とＳＰ２１０３のＬＵの選択及びボリュームレイアウトテーブルへの記録を実行する。
　以上のＳＰ２１０１からＳＰ２１０４までの処理で、行２０１４に示すように、ＶＭ　Ｔｉｅｒランク２００４をほぼ満足するＬＵ　Ｔｉｅｒランクを有するＬＵグループ（ボリューム）を構成できる。
　一階層下位のＬＵが利用可能でなければ（ＳＰ２１０４で“Ｎｏ”）、ボリューム管理プログラム３０３は、もう一階層下位のＬＵが存在するか確認する（ＳＰ２１０５）。
　もう一階層下位のＬＵが存在するのであれば（ＳＰ２１０５で“Ｙｅｓ”）、ボリューム管理プログラム３０３は、再び、ＳＰ２１０４の処理を実行し、その一階層下位のＬＵが利用可能か判定する。
　もう一階層下位のＬＵが存在しなければ（ＳＰ２１０５で“Ｎｏ”）、ボリューム管理プログラム３０３は、エラー報告を行ない、処理を終了する（ＳＰ２１０６）。このエラー報告の方法としては、メタデータサーバ５の出力装置５３でのエラー表示、ホスト装置２へのエラー送信などである。
　以上のＳＰ２１０１からＳＰ２１０６までの処理を実行することで、ＶＭ１０に提供するＬＵのＴｉｅｒランクとボリュームのレイアウトを決定できる。
　以上説明したように、本発明では、ネットワークシステムにおいて、データストレージ３を構成するストレージ装置１３の特性やそのストレージ装置１３に搭載されるストレージ媒体１２の特性に適合したストレージリソースを、ホスト装置２の特性に合わせて適切に提供することができる。更に、本発明では、ホスト装置２にサーバ仮想化機構を採用した環境でも、ホスト装置２上で動作するＶＭ１０の特性に適合したストレージリソースをＶＭ１０に割当てることができる。そのため、本発明は、ストレージリソースの効率的な利用と有効活用を実現できる。
（４）第２実施形態によるネットワークシステムの構成
　次に、本発明の第２実施形態に係るネットワークシステムについて図２２及び図２３で説明する。なお、第２実施形態の図面で第１実施形態と同じ部分には同一の符号を付し、第１実施形態との差異を中心に説明する。
　図２２は、本発明の第２実施形態に係るネットワークシステムの構成例を示す図である。
本発明の第２実施形態に係るネットワークシステム２２０１の特徴は、第１の実施形態に係るネットワークシステム１に統合管理サーバ２２１７を付け加えたことである。
　統合管理サーバ２２１７は、メタデータサーバ５と同様な内部構成を有するコンピュータ装置であり、ＰＣ、メインフレーム、サーバなどから構成される。また、統合管理サーバ２２１７は、ホスト装置２、ストレージ装置１３、ストレージ管理サーバ４、メタデータサーバ５とネットワーク７で接続される。
　従来のネットワークシステムでは、ＶＭ１０に割当てる各種の仮想リソース（仮想ＣＰＵ、仮想メモリ、仮想ストレージ、仮想パスなど）の種別や量を、ホスト装置２、ストレージ装置１３、ネットワーク装置（図示せず）それぞれで判断して、ＶＭ１０に提供していた。そのため、ＶＭ１０への割当てに時間を要し、また、仮想リソースを提供する各装置の特性を充分に生かすことができず、ＶＭでの高い処理性能を実現できなかった。
　本実施例では、ＶＭ１０に割当てる各種の仮想リソースの種別や量を、統合管理サーバ２２１７が、一括して判定し一元管理する。
　この統合管理サーバ２２１７は、実施例１のネットワークシステム１において、メタデータサーバ５がストレージ管理サーバ４から入手していたストレージ構成情報１４と、メタデータサーバ５がハイパーバイザ９から入手していたＶＭリソース情報１１を、統合管理サーバ２２１７の内部にＶＭリソース情報・ストレージ構成情報２２１８として格納している。
　ネットワークシステム２２０１では、第１実施形態のネットワークシステム１において、メタデータサーバ５がストレージ管理サーバ４とハイパーバイザ９に要求・入手していた情報を、統合管理サーバ２２１７に要求・入手することで、本実施例によるネットワークシステムにおいて、ＶＭ特性に応じたストレージ階層ボリュームで構成した仮想ストレージリソースを、ＶＭに割当てることが可能となる。
（４－１）ＶＭへの仮想ストレージリソースの割当て
　図２３は、本発明の第２実施形態に係るＶＭへのストレージリソースを割当てる処理を示すシーケンス図である。図５で、ホスト装置２のハイパーバイザ９及びストレージ管理サーバ４が行っていた処理を統合管理サーバ２２１７が行う。そのため、ＶＭ１０へのストレージリソース割当て処理を開始する前に、統合管理サーバ２２１７はホスト装置２よりＶＭリソース情報１１を、ストレージ管理サーバ４からストレージ構成情報１４を事前に取得し装置内部にＶＭリソース・ストレージ構成情報２２１８として格納しておく。なお、ＶＭリソース・ストレージ構成情報２２１８は、ＶＭ１０へのストレージリソース割当て処理の開始を契機に取得しても良いし、定期的に取得する処理を実行しても良い。
　統合管理サーバ２２１７は、ＳＰ５０１で、ホスト装置２のハイパーバイザ９から、新規に作成するＶＭに対する仮想ストレージリソース割当ての要求を受け付けると、ＶＭ１０へのストレージリソース割当て処理を実行する。
　統合管理サーバ２２１７は、ＳＰ５１１で、メタデータサーバ５からの新ＶＭ用ストレージリソース割当て応答を受信すると、ボリュームレイアウト情報をホスト装置２に送信し、ＶＭ１０に仮想ストレージリソースを提供する。
　本実施例のネットワークシステム２２０１でも、実施例１と同様に、データストレージ３を構成するストレージ装置１３の特性やそのストレージ装置に搭載されるストレージ媒体１２の特性に適合したストレージリソースを適切にホスト装置２へ提供することができる。更に、本発明では、ホスト装置２にサーバ仮想化機構を採用した環境でも、ホスト装置２上で動作するＶＭ１０の特性に適合したストレージリソースをＶＭ１０へ適切に割当てることができる。加えて、ストレージリソースをＶＭ１０へ提供するための各処理及び各情報の管理を、統合管理サーバ２２１７が一括して実行できるので、割当て処理の高速化が図れる。
（５）第３実施形態によるネットワークシステムの構成
　図２４は、本発明の第３実施形態に係るネットワークシステムの構成例を示す図である。次に、本発明の第３実施形態に係るネットワークシステムについて図２４で説明する。なお、第３実施形態の図面で第１実施形態及び第２実施形態と同じ部分には同一の符号を付し、第１実施形態及び第２実施形態との差異を中心に説明する。
　第２の実施形態に係るネットワークシステム２２０１では、メタデータサーバ５と統合管理サーバ２２１７が、それぞれ別のコンピュータ装置として動作する例を示していたが、第３実施形態のネットワークシステム２４０１では、メタデータサーバ５と統合管理サーバ２２１７を一体化したコンピュータ装置、すなわち統合管理・メタデータサーバ２４０５がストレージリソースのＶＭ１０への割当て処理を実行する構成とした。
　統合管理・メタデータサーバ２４０５は、統合管理サーバ２２１７やメタデータサーバ５と同様な内部構成を有するコンピュータ装置であり、ＰＣ、メインフレーム、サーバなどから構成される。また、統合管理・メタデータサーバ２４０５は、ホスト装置２、ストレージ装置１３、ストレージ管理サーバ４と第２のネットワーク７で接続される。
　統合管理・メタデータサーバ２４０５は、第２の実施形態と同様の処理によりＶＭ特性に適合したストレージ階層ボリュームで構成した仮想ストレージリソースを、ＶＭ１０へ適切に割当てることが可能となる。
　（６）第４実施形態によるネットワークシステムの構成
　次に、本発明の第４実施形態に係るネットワークシステムについて、図２５で説明する。なお、第４実施形態の図面で、第１実施形態、第２実施形態または第３実施形態と同じ部分には同一の符号を付すこととし、第１実施形態、第２実施形態または第３実施形態との差異を中心に説明する。
　図２５は、本発明の第４実施形態に係るネットワークシステムの構成例を示す図である。第２の実施形態に係るネットワークシステム２２０１では、メタデータサーバ５と統合管理サーバ２２１７を、異なった物理的なコンピュータ装置で構成していた。また、第３実施形態のネットワークシステム２４０１では、メタデータサーバ５と統合管理サーバ２２１７を一体化したコンピュータ装置、すなわち統合管理・メタデータサーバ２４０５がストレージリソースのＶＭ１０への割当て処理を実行する構成とした。
　第４実施形態のネットワークシステム２５０１は、メタデータサーバ５と統合管理サーバ２２１７が、ホスト装置２のハイパーバイザ９上で動作する仮想サーバ、すなわち、メタデータ仮想サーバ２５０５と統合管理仮想サーバ２５１７として動作する構成例である。
　このメタデータ仮想サーバ２５０５と統合管理仮想サーバ２５１７が、第２の実施形態に係るネットワークシステム２２０１のメタデータサーバ５と統合管理サーバ２２１７と同じ処理を実行することで、前述の第１実施形態から第３実施形態と同様に、ＶＭ特性に適合したストレージ階層ボリュームで構成した仮想ストレージリソースを、ＶＭ１０へ適切に割当てることが可能となる。
　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。
　各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置いてもよい。
　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
　１　ネットワークシステム
　２　ホスト装置
　３　データストレージ
　４　ストレージ管理サーバ
　５　メタデータサーバ
　６、７、８　ネットワーク
　９　ハイパーバイザ
　１０　ＶＭ
　１１　ＶＭリソース情報
　１２　ＬＵ
　１３　ストレージ装置
　１４　ストレージ構成情報
　１５　Ｔｉｅｒ判定・ボリュームレイアウト機能部
　１６　ストレージ／ＶＭ／Ｔｉｅｒ情報
　２０１　ストレージ媒体
　２０２　ストレージ媒体群
　３０１　ストレージＬＵ　Ｔｉｅｒ管理プログラム
　３０２　ＶＭ　Ｔｉｅｒ管理プログラム
　３０３　ボリューム管理プログラム
　３０４　ストレージ構成情報収集処理
　３０５　ストレージＬＵ　Ｔｉｅｒ生成・更新処理
　３０６　ＶＭリソース情報収集処理
　３０７　ＶＭ　Ｔｉｅｒランク判定処理
　３０８　割当てＬＵ　Ｔｉｅｒランク決定処理
　３０９　ボリュームレイアウト処理
　７００　機種ランク判定テーブル
　８００　ＬＵランク管理テーブル
　１１００　ＬＵ　Ｔｉｅｒランク判定テーブル
　１２００　ＬＵ　Ｔｉｅｒランク管理テーブル
　１４００　仮想ＣＰＵシェアランク判定テーブル
　１４１０　仮想メモリシェアランク判定テーブル
　１５００　ＶＭリソースシェアランク管理テーブル
　１７００　ＶＭ　Ｔｉｅｒランク判定テーブル
　１８００　ＶＭ　Ｔｉｅｒランク管理テーブル
　２０００　ボリュームレイアウトテーブル
　２２０１、２４０１、２５０１　ネットワークシステム
　２２１７　統合管理サーバ
　２２１８　リソース・装置構成情報
　２４０５　統合管理・メタデータサーバ
　２５０２　ホスト装置
　２５０５　メタデータ仮想サーバ
　２５１７　統合管理仮想サーバ

Claims (14)

  1. 　ネットワークシステムであって、
    　前記ネットワークシステムは、
    　第１制御部と、
    　ホスト装置に異なるストレージ特性を有する複数のサブ記憶領域（ＬＵ）を提供するデータ記憶システムとを備え、
    　前記ホスト装置は第２制御部を備え、前記第２制御部で制御される１つ以上の仮想マシンが動作し、前記仮想マシン毎に仮想マシンリソースが割り当てられ、
    　前記第１制御部が、
    　前記仮想マシンリソースの情報を取得し、
    　前記仮想マシンリソース情報に基づき前記仮想マシンへ割当てるサブ記憶領域のストレージ特性（ＬＵ　Ｔｉｅｒランク）を決定し、
    　複数の同一ストレージ特性を有するサブ記憶領域からデータ格納領域（ボリューム）を構成し、　
    　前記データ格納領域に前記仮想マシンのデータを格納する
    　ことを特徴とするネットワークシステム。
     
  2. 　請求項１記載のネットワークシステムであって、
    　前記データ格納領域に前記仮想マシンのデータを分散して格納する
    　ことを特徴とするネットワークシステム。
     
  3. 　請求項２記載のネットワークシステムであって、
    　前記データ記憶システムは複数のストレージ装置で構成され、ストレージ装置は複数のストレージ媒体を搭載し、
    　ストレージ構成情報は、前記ストレージ装置の種類を表す機種情報と、前記搭載されたストレージ媒体の種類を表す媒体情報である
    　ことを特徴とするネットワークシステム。
     
  4. 　請求項３記載のネットワークシステムであって、
    　前記ホスト装置は、処理を実行する複数のＣＰＵ部と、所定の記憶容量を有するメモリ部と、データ記憶システムと接続する複数のパスを有する通信部と、情報を格納するストレージ部とを更に備え、
    　前記仮想マシンリソース情報は前記ストレージ部に格納され、
    　前記仮想マシンリソース情報は、前記仮想マシンに割当てられる
    　　（ａ１）仮想ＣＰＵの個数
    　　（ａ２）仮想ＣＰＵの動作周波数
    　　（ａ３）仮想メモリの記憶容量
    　　（ａ４）仮想接続ポート数
    　　（ａ５）仮想通信パス帯域
    のいずれか１つ以上の情報で構成される
    　または、
    　前記仮想マシンリソース情報は、前記仮想マシンに割当てられる
    　　（ｂ１）仮想ＣＰＵの全個数に対する割当て個数の割合
    　　（ｂ２）仮想ＣＰＵの全動作周波数に対する割当て動作周波数の割合
    　　（ｂ３）仮想メモリの全記憶容量に対する割当て記憶容量の割合
    　　（ｂ４）仮想接続ポートの全数に対する割当てポート数の割合
    　　（ｂ５）仮想通信パスの帯域に対する割当て帯域の割合
    のいずれか１つ以上の情報で構成される
    　ことを特徴とするネットワークシステム。
     
  5. 　請求項４記載のネットワークシステムであって、
    　前記第１制御部は、
    　前記機種情報より前記ストレージ装置毎の機種ランクを決定し、前記媒体情報より前記ストレージ媒体毎の媒体ランクを決定し、
    　前記機種ランクと前記媒体ランクにより、複数の前記ストレージ媒体で構成されたサブ記憶領域のストレージ特性（ＬＵ　Ｔｉｅｒランク）を求める
    ことを特徴とするネットワークシステム。
     
  6. 　請求項５記載のネットワークシステムであって、
    　前記第１制御部は、
    　前記仮想マシンリソース情報より前記仮想マシン特性（ＶＭ　Ｔｉｅｒランク）を求める
    　ことを特徴とするネットワークシステム。
     
  7. 　請求項６記載のネットワークシステムであって、
    　前記第１制御部は、
    　前記仮想マシン特性から予め決定しておいた対応関係に基づき、前記仮想マシンに割当てるサブ記憶領域のストレージ特性（ＬＵ　Ｔｉｅｒランク）を決定する
    　ことを特徴とするネットワークシステム。
     
  8. 　請求項７記載のネットワークシステムであって、
    　前記ネットワークシステムは、メタデータサーバを更に備え、前記第１制御部は前記メタデータサーバに搭載される
    　ことを特徴とするネットワークシステム。
     
  9. 　請求項８記載のネットワークシステムであって、
    　前記ネットワークシステムは、ストレージ管理サーバを更に備え、前記データ記憶システムのストレージ構成情報は、前記ストレージ管理サーバ経由で前記メタデータサーバの第１制御部が取得する
    　ことを特徴とするネットワークシステム。
     
  10. 　請求項８記載のネットワークシステムであって、
    　前記ネットワークシステムは、ストレージ管理サーバ及び統合管理サーバとを更に備え、
    　前記ストレージ管理サーバで取得された前記データ記憶システムのストレージ構成情報及び前記仮想マシンリソース情報は、前記統合管理サーバを介して前記メタデータサーバの第１制御部が取得する
    　ことを特徴とするネットワークシステム。
     
  11. 　請求項７記載のネットワークシステムであって、
    　前記ネットワークシステムは、ストレージ管理サーバ及び統合管理・メタデータサーバとを更に備え、
    　前記統合管理・メタデータサーバに前記第１制御部が搭載され、
    　前記ストレージ管理サーバで取得された前記データ記憶システムのストレージ構成情報及び前記仮想マシンリソース情報は、前記統合管理・メタデータサーバの前記第１制御部が取得する
    　ことを特徴とするネットワークシステム。
     
  12. 　請求項７記載のネットワークシステムであって、
    　前記ホスト装置は前記第２制御部で制御される１つ以上の仮想サーバが動作し、
    　前記仮想サーバが、
    　前記仮想マシンリソース情報及び前記ストレージ構成情報を取得し、
    　前記仮想マシンリソース情報に基づき、前記仮想マシンへの割当てサブ記憶領域のストレージ特性を決定し、
    　複数の同一ストレージ特性を有するサブ記憶領域からデータ格納領域（ボリューム）を形成し、　
    　前記データ格納領域に格納するデータは、前記サブ記憶領域に分散されて格納される
    　ことを特徴とするネットワークシステム。
     
  13. 　記憶領域を提供するネットワークシステムの運用方法であって、
    　前記記憶領域を提供する装置のストレージ構成情報を取得し、
    　前記ストレージ構成情報に基づき、異なるストレージ特性を有する複数のサブ記憶領域を同一のストレージ特性を有するサブ記憶領域毎に分類し、
    　前記記憶領域を提供される装置のシステム特性情報を取得し、
    　前記システム特性情報に基づき、前記記憶領域を提供される装置へ割当てるサブ記憶領域のストレージ特性を決定し、
    　前記複数の前記割当てサブ記憶領域からデータ格納領域（ボリューム）を形成し、　
    　前記データ格納領域（ボリューム）にデータを格納する
    　ことを特徴とする運用方法。
     
  14. 　請求項１３記載の運用方法であって、
    　前記データ格納領域の前記サブ記憶領域に前記データを分散して格納する
    　ことを特徴とする運用方法。
     
PCT/JP2012/081656 2012-12-06 2012-12-06 ネットワークシステム及びその運用方法 WO2014087518A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2012/081656 WO2014087518A1 (ja) 2012-12-06 2012-12-06 ネットワークシステム及びその運用方法
US13/981,228 US8793373B2 (en) 2012-12-06 2012-12-06 Network system and method for operating the same

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/081656 WO2014087518A1 (ja) 2012-12-06 2012-12-06 ネットワークシステム及びその運用方法

Publications (1)

Publication Number Publication Date
WO2014087518A1 true WO2014087518A1 (ja) 2014-06-12

Family

ID=50882261

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/081656 WO2014087518A1 (ja) 2012-12-06 2012-12-06 ネットワークシステム及びその運用方法

Country Status (2)

Country Link
US (1) US8793373B2 (ja)
WO (1) WO2014087518A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016143166A (ja) * 2015-01-30 2016-08-08 富士通株式会社 制御装置，ストレージシステム及び制御プログラム
WO2017046864A1 (ja) * 2015-09-15 2017-03-23 株式会社日立製作所 ストレージシステム、計算機システム、およびストレージシステムの制御方法

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9515899B2 (en) * 2012-12-19 2016-12-06 Veritas Technologies Llc Providing optimized quality of service to prioritized virtual machines and applications based on quality of shared resources
US9092451B1 (en) * 2013-03-14 2015-07-28 Emc Corporation Genomic application data storage
EP2997470A4 (en) * 2013-05-13 2017-01-18 Telefonaktiebolaget LM Ericsson (publ) Node in a telecommunications network, a virtual network element and methods for retrieving resource identification information
US10225162B1 (en) * 2013-09-26 2019-03-05 EMC IP Holding Company LLC Methods and apparatus for array agnostic automated storage tiering
JP6131170B2 (ja) * 2013-10-29 2017-05-17 株式会社日立製作所 計算機システム、及びデータ配置制御方法
US20150201016A1 (en) * 2014-01-14 2015-07-16 Amit Golander Methods and system for incorporating a direct attached storage to a network attached storage
US9576039B2 (en) 2014-02-19 2017-02-21 Snowflake Computing Inc. Resource provisioning systems and methods
US10169169B1 (en) 2014-05-08 2019-01-01 Cisco Technology, Inc. Highly available transaction logs for storing multi-tenant data sets on shared hybrid storage pools
US9378067B1 (en) * 2014-05-08 2016-06-28 Springpath, Inc. Automated load balancing across the distributed system of hybrid storage and compute nodes
US9628350B2 (en) * 2014-11-05 2017-04-18 Amazon Technologies, Inc. Dynamic scaling of storage volumes for storage client file systems
US20170013046A1 (en) * 2014-11-18 2017-01-12 Primarydata, Inc. Data-centric data storage
US11100415B2 (en) * 2016-10-04 2021-08-24 University Of Louisiana At Lafayette Architecture and method for providing insights in networks domain
US10379912B2 (en) 2017-04-11 2019-08-13 International Business Machines Corporation Data storage allocation utilizing virtual machine resource allocation
FR3081609A1 (fr) 2018-06-29 2019-11-29 Orange Systeme de commande d'objets connectes, procede de commande et programme d'ordinateur correspondants
US10956365B2 (en) 2018-07-09 2021-03-23 Cisco Technology, Inc. System and method for garbage collecting inline erasure coded data for a distributed log structured storage system
US10642689B2 (en) 2018-07-09 2020-05-05 Cisco Technology, Inc. System and method for inline erasure coding for a distributed log structured storage system
US10691611B2 (en) * 2018-07-13 2020-06-23 Micron Technology, Inc. Isolated performance domains in a memory system
US11100007B2 (en) 2019-05-28 2021-08-24 Micron Technology, Inc. Memory management unit (MMU) for accessing borrowed memory
US11334387B2 (en) * 2019-05-28 2022-05-17 Micron Technology, Inc. Throttle memory as a service based on connectivity bandwidth
US11169930B2 (en) 2019-05-28 2021-11-09 Micron Technology, Inc. Fine grain data migration to or from borrowed memory
US11061819B2 (en) 2019-05-28 2021-07-13 Micron Technology, Inc. Distributed computing based on memory as a service
US11256624B2 (en) 2019-05-28 2022-02-22 Micron Technology, Inc. Intelligent content migration with borrowed memory
US11438414B2 (en) 2019-05-28 2022-09-06 Micron Technology, Inc. Inter operating system memory services over communication network connections
US20220318040A1 (en) * 2021-03-31 2022-10-06 Ati Technologies Ulc System and method for providing page migration
CN113703685B (zh) * 2021-08-31 2023-09-08 网易（杭州）网络有限公司 一种数据存储方法、装置、设备及介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003345631A (ja) * 2002-05-28 2003-12-05 Hitachi Ltd 計算機システム及び記憶領域の割当方法
JP2006003973A (ja) * 2004-06-15 2006-01-05 Nec Corp ストレージ装置とその論理記憶装置割り当て制御方法
JP2006031668A (ja) * 2004-07-15 2006-02-02 Hitachi Ltd データ価値に基づく階層型ストレージ管理の為の方法と装置
JP2010140273A (ja) * 2008-12-11 2010-06-24 Hitachi Ltd 情報処理システム、情報処理方法、及び管理装置
JP2012128756A (ja) * 2010-12-17 2012-07-05 Mitsubishi Electric Corp ファイル複製装置、ファイル複製装置のファイル複製方法およびファイル複製プログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010122814A (ja) 2008-11-18 2010-06-03 Hitachi Ltd ストレージシステム及びストレージシステムの運用方法
US8291159B2 (en) 2009-03-12 2012-10-16 Vmware, Inc. Monitoring and updating mapping of physical storage allocation of virtual machine without changing identifier of the storage volume assigned to virtual machine

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003345631A (ja) * 2002-05-28 2003-12-05 Hitachi Ltd 計算機システム及び記憶領域の割当方法
JP2006003973A (ja) * 2004-06-15 2006-01-05 Nec Corp ストレージ装置とその論理記憶装置割り当て制御方法
JP2006031668A (ja) * 2004-07-15 2006-02-02 Hitachi Ltd データ価値に基づく階層型ストレージ管理の為の方法と装置
JP2010140273A (ja) * 2008-12-11 2010-06-24 Hitachi Ltd 情報処理システム、情報処理方法、及び管理装置
JP2012128756A (ja) * 2010-12-17 2012-07-05 Mitsubishi Electric Corp ファイル複製装置、ファイル複製装置のファイル複製方法およびファイル複製プログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016143166A (ja) * 2015-01-30 2016-08-08 富士通株式会社 制御装置，ストレージシステム及び制御プログラム
WO2017046864A1 (ja) * 2015-09-15 2017-03-23 株式会社日立製作所 ストレージシステム、計算機システム、およびストレージシステムの制御方法
JPWO2017046864A1 (ja) * 2015-09-15 2017-09-14 株式会社日立製作所 ストレージシステム、計算機システム、およびストレージシステムの制御方法

Also Published As

Publication number Publication date
US8793373B2 (en) 2014-07-29
US20140164621A1 (en) 2014-06-12

Similar Documents

Publication Publication Date Title
WO2014087518A1 (ja) ネットワークシステム及びその運用方法
US9229645B2 (en) Storage management method and storage system in virtual volume having data arranged astride storage devices
US9285992B2 (en) System and method for optimally creating storage objects in a storage system
JP5830599B2 (ja) 計算機システム及びその管理システム
US8578121B2 (en) Computer system and control method of the same
US9110591B2 (en) Memory resource provisioning using SAS zoning
WO2014018742A1 (en) Contention-free multi-path storage access in distributed compute systems
US11086535B2 (en) Thin provisioning using cloud based ranks
US20140195698A1 (en) Non-disruptive configuration of a virtualization cotroller in a data storage system
US10855556B2 (en) Methods for facilitating adaptive quality of service in storage networks and devices thereof
WO2019053565A1 (en) STORAGE SYSTEM USING CLOUD STORAGE AS A ROW
US10019182B2 (en) Management system and management method of computer system
JP2015531090A (ja) ストレージデバイスの高速アクセス及びデータ保護を実現する計算機、計算機システム、及びｉ／ｏ要求処理方法
US9940073B1 (en) Method and apparatus for automated selection of a storage group for storage tiering
US20180052715A1 (en) Computer system including server storage system
US10242053B2 (en) Computer and data read method
Cha et al. Analysis of i/o performance for optimizing software defined storage in cloud integration
TW202018521A (zh) 具多平台相容性模組之資料儲存子系統之儲存系統架構及其方法
WO2016174739A1 (ja) 複合計算機システム、管理計算機、およびデータ連携管理方法
US11768744B2 (en) Alerting and managing data storage system port overload due to host path failures
US9870152B2 (en) Management system and management method for managing data units constituting schemas of a database
US11201788B2 (en) Distributed computing system and resource allocation method
JP2011070464A (ja) 計算機システム及び計算機システムの性能管理方法
US10768834B2 (en) Methods for managing group objects with different service level objectives for an application and devices thereof
US20220308794A1 (en) Distributed storage system and management method

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 13981228

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12889433

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12889433

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP