WO2015049789A1 - リソース管理システムおよびリソース管理方法 - Google Patents

リソース管理システムおよびリソース管理方法 Download PDF

Info

Publication number
WO2015049789A1
WO2015049789A1 PCT/JP2013/077063 JP2013077063W WO2015049789A1 WO 2015049789 A1 WO2015049789 A1 WO 2015049789A1 JP 2013077063 W JP2013077063 W JP 2013077063W WO 2015049789 A1 WO2015049789 A1 WO 2015049789A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
container
application
resources
predetermined
Prior art date
Application number
PCT/JP2013/077063
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 US14/770,081 priority Critical patent/US9495195B2/en
Priority to JP2015540343A priority patent/JP5976230B2/ja
Priority to PCT/JP2013/077063 priority patent/WO2015049789A1/ja
Publication of WO2015049789A1 publication Critical patent/WO2015049789A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Definitions

  • the present invention relates to a resource management system and a resource management method.
  • a system that has been operating on resources in a fixed manner is separated from resources using virtualization technology, and the system is migrated between multiple physical computer resources according to the operating status of business applications. Thereby, load imbalance can be leveled dynamically.
  • Patent Document 1 discloses a technique for quickly eliminating a load imbalance between groups in a virtual machine system in which a plurality of tenants use a plurality of physical machine resources.
  • a plurality of virtual machines are managed on a plurality of resource groups, and a plurality of virtual machines are migrated between physical computer resources according to the load, thereby distributing the load.
  • the conventional technology uniformly evaluates the performance load of the virtual server, and does not consider the performance characteristics of the application provided on the virtual server.
  • business applications have requirements for resources, but these resource requirements are not constant depending on the type of application and the configuration scale.
  • a method of defining a dedicated resource area sized according to the performance characteristics of the application in the tenant can be considered. For example, a resource area for application A and a resource area for application B are prepared in the tenant. A user generates a virtual server using resources in the dedicated resource area according to a desired application. According to this method, although it is possible to operate efficiently in each dedicated resource area, it is not possible to expect an improvement in the utilization rate in the entire resource.
  • the present invention has been made in view of the above problems, and an object of the present invention is to provide a resource management system and a resource management method capable of improving resource utilization efficiency in response to a change in situation.
  • a resource management system is capable of communicating with a plurality of physical computers that provide resources, a plurality of virtual computers that execute at least one application program, a plurality of physical computers, and a plurality of virtual computers.
  • the integrated resource management unit prepares a plurality of containers for managing a part of the associated resources and providing them as virtual resources in advance, and determines the usage range of the provided virtual resources.
  • the resource partition to be defined is managed, and the container is associated with one of the application programs. When a resource configuration change request for an application program operating in the resource partition is received, another container is added to the container associated with the application program.
  • Resources managed in , Amount of resources managed by other containers may be smaller than the virtual resources provided by other containers.
  • a container is associated with one of application programs.
  • the container associated with the application program is managed by another container. Migrated resources Therefore, according to the present invention, resources can be migrated according to a change in situation, and resource utilization efficiency can be increased.
  • the block diagram of the computer system which manages a resource Explanatory drawing which shows the outline
  • the flowchart which shows the process which changes the structure of a container according to the request
  • resources are allocated according to changes in the demand of the computer system beyond the resource area defined for each tenant or the resource area defined for each application. Improve resource utilization efficiency of the entire data center by dynamically adapting.
  • performance characteristics (resource requirements) required by a plurality of applications are acquired from an application management unit for managing each application.
  • the resource demand for the entire resource is calculated from a unified viewpoint in consideration of the performance characteristics required by each application.
  • the arrangement of the entire resource is planned based on the resource demand considering the performance characteristics required by the application.
  • the resource pool is reconfigured beyond the resource area dedicated to the application.
  • the present embodiment it is possible to optimize the utilization rate of the entire resource in a data center where demand changes every moment without contradicting the resource management system and application management system for each tenant.
  • the application management know-how cultivated in the conventional operation can be continuously utilized while ensuring security for each tenant.
  • each instance is configured to satisfy the resource requirements required by the application, and the utilization rate of the entire resource is increased.
  • FIG. 1 shows the configuration of a computer system in this embodiment.
  • the computer system can include, for example, a host 10 and a host 20 that operate information processing services, a client computer 70 that is used by a user who requests the service, and a management computer 200 that manages the computer system.
  • the host 10 is configured by a general computer architecture including, for example, a physical CPU, a memory (main storage device), an input / output device, a network interface, and an internal bus that interconnects them.
  • a general computer architecture including, for example, a physical CPU, a memory (main storage device), an input / output device, a network interface, and an internal bus that interconnects them.
  • An OS (Operating System) 13 that directly controls physical processing resources is running on the host 10.
  • the application administrator or user can directly control the logical configuration of the host 10 by using the OS 13 on the host 10 as the guest OS 13.
  • the host 10 Since the guest OS 13 can control the configuration of all physical processing resources of the host 10, the host 10 is referred to as a bare metal host 10 in this embodiment.
  • a logical server configuration controlled by the guest OS 13 is referred to as an instance 11.
  • the user can enjoy a desired information processing service by operating one or more applications 12 in the instance 11.
  • the application may be abbreviated as “App”.
  • the host 20 also has a configuration similar to that of the host 10, but includes virtualization software called a hypervisor 24 or a virtual machine monitor. With the virtualization software, physical resources are logically divided into one or more guest OS areas and provided to an application administrator or user. These guest OS areas are generally called virtual machines 21 or logical partitions, and the host 20 is called a virtual machine host 20.
  • virtualization software With the virtualization software, physical resources are logically divided into one or more guest OS areas and provided to an application administrator or user. These guest OS areas are generally called virtual machines 21 or logical partitions, and the host 20 is called a virtual machine host 20.
  • These guest OS areas may be virtual machines that share physical components such as CPU cores by time scheduling, for example, or may be logical partitions that are associated with physical components in a fixed manner. There may be. Here, for the sake of simplicity, these are not particularly distinguished and are simply called virtual machines.
  • a guest OS 23 is running in the virtual machine, and an application 22 for use by the user is running.
  • a virtual machine corresponds to one logical server configuration. Similar to the bare metal host 10, the virtual machine is referred to as an instance 21.
  • the computer system according to the present embodiment uses a physical server and storage having the same configuration in two ways: a bare metal host 10 and a virtual machine host 20. However, unless otherwise specified in the following description, the instance 11 on the bare metal host 10 and the instance 21 on the virtual machine host 20 are not distinguished from each other and are simply described as the instance 11.
  • a virtual machine In a system that dynamically creates an instance in response to a user creation request, generally called a cloud, a virtual machine is often used.
  • the instance configuration can be separated from the physical resource configuration of the host.
  • the server configuration for operating the application can be generated flexibly and immediately, and the configuration can be easily changed after generation.
  • the virtual machine since the virtual machine shares the physical resources of the virtual machine host 20, it must be influenced by performance from other virtual machines provided in the same virtual machine host 20. Such an environment is not suitable for applications with strict performance requirements, such as databases that require stable disk I / O (Input / Output) performance.
  • a bare metal host 10 corresponding to a physical resource is prepared.
  • a server environment having stable performance is provided by utilizing the bare metal host 10.
  • resource allocation suitable for the performance requirements and life cycle of the application can be realized.
  • the storage apparatus 100 has a function of providing storage resources to the instances 11 and 21.
  • the storage apparatus 100 is a computer system specialized for data input / output processing, and includes a CPU, a memory, and the like.
  • the CPU of the storage apparatus 100 operates a control program for controlling the configuration of storage resources.
  • a physical storage medium such as an HDD (hard disk drive) is provided for each logical area called a volume 101.
  • the storage medium is not limited to the HDD, but, for example, a flash memory device, MRAM (Magnetoresistive Random Access Memory), phase change memory (Phase-Change Memory), ReRAM (Resistive random-accessromemory), FeRAM (Ferroelectric Random Access Memory) Etc. may be used.
  • the volume 101 is recognized as a storage resource (logical device) by the OS 13. Data required for the OS 13 and the application 12 is read from and written to the volume 101.
  • the hypervisor 24 further divides the volume 101 into areas called virtual disks 102.
  • Virtual disks are often files on a file system.
  • the OS 23 on the virtual machine 21 recognizes the data area in the virtual disk 102 as the virtual volume 103.
  • the hosts 10 and 20 and the storage apparatus 100 are connected by a SAN (Storage Area Network).
  • a SAN Storage Area Network
  • An example of a SAN is FC_SAN.
  • the FC_SAN includes one or a plurality of fiber channel switches (FC SW) 50, a fiber channel cable 51, and an HBA (host bus adapter) 52 that connects each data input / output device.
  • FC SW fiber channel switches
  • HBA host bus adapter
  • SAN implementations are not limited to Fiber Channel, but can achieve the same purpose of large-capacity data communication, such as iSCSI (Internet Small Computer System Interface), FCoE (Fibre Channel over Ethernet (registered trademark)), Infini- Other types of devices and protocols such as band may be used.
  • iSCSI Internet Small Computer System Interface
  • FCoE Fibre Channel over Ethernet (registered trademark)
  • Infini- Other types of devices and protocols such as band may be used.
  • the hosts 10 and 20 that provide the service, the client computer 70 that requests the service, and the management computer 200 that manages the computer system are connected to each other via a communication network.
  • the communication network is physically connected by an Ethernet (registered trademark) switch 60 and a cable, and bi-directionally communicates application data and control information using a protocol such as TCP / IP.
  • these communication networks are roughly divided into a service network 300 and management networks 301 and 302.
  • traffic in which the service client 71 communicates with the applications 12 and 22 mainly flows.
  • the service network 300 transmits and receives data necessary for the information processing service.
  • management network traffic in which the management client 72 and the management servers 201, 203, 204, 295 communicate with the control components in the devices 10, 20, 50, 100 mainly flows.
  • the management network transmits and receives control data for managing the configuration of each information processing apparatus 10, 20, 50, 100.
  • These communication networks may be physically separated, or may be configured by logical network division such as layer 3 switch setting or layer 2 switch setting (VLAN, virtual local area network).
  • the management network 302 has a firewall 303 for mainly controlling communication between the application management server 201 and each of the hosts 10 and 20.
  • the firewall 303 has a function of permitting or blocking a connection from a specific application management server 201 to a specific host, for example, in response to a request from the network management unit 204.
  • the firewall 303 performs communication connection or blocking using an IP address, a host name, or the like.
  • the client computer 70 is physically configured based on a general computer architecture such as a CPU, a memory, and a non-volatile storage device, similarly to the hosts 10 and 20.
  • the client computer 70 includes a service client 71 and a management client 72.
  • the service client 71 is software that receives provision of an information processing service from the applications 12 and 22 on the hosts 10 and 20.
  • the management client 72 is software that connects to the management computer 200 and manages the configuration of the computer system.
  • Each software 71 and 72 on the client computer 70 is not necessarily a dedicated program, and may be a general-purpose program such as a Web browser as long as it has a function to achieve the same purpose.
  • the service client 71 may be prepared for each application, or may be configured such that a plurality of applications can be managed by one service client 71.
  • the management client 72 may be prepared for each device to be managed, or may be configured to manage a plurality of target devices.
  • the management computer 200 changes the configuration of the computer system in response to a user request transmitted from the client computer 70.
  • the management computer 200 has a general computer architecture like other computers, and operates a management program necessary for realizing each function.
  • the management programs in this embodiment are, for example, the application management server 201, the integrated resource management unit 202, the server management unit 203, the network management unit 204, and the storage management unit 205.
  • Each management program may be subdivided for each function, or a plurality of programs may be combined into one.
  • a configuration in which a plurality of management computers 200 cooperate to operate these management programs may be employed.
  • At least a part of the management program may be distributed and arranged in a part of the management target.
  • As an arrangement destination for example, there is an agent program on the host 10 or the FC SW 50.
  • a plurality of management programs are prepared according to the scope and responsibilities of the devices managed by each administrator, and access control for each function of the management program is provided by account authentication.
  • Application management server 201 provides a function of managing applications 12 and 22 on instances 11 and 21.
  • the applications 12 and 21 have unique data structures, functions, and processing flows suitable for processing by the applications themselves. Therefore, a dedicated application management server 201 may be required to manage the applications 12 and 22.
  • the application administrator who manages the application is familiar with the original management method and the operation of the application management server.
  • the application management and resource configuration management it is possible to obtain great convenience that application managers can make use of know-how.
  • the application management server may have a function of managing a part of the resource configuration. Therefore, in this embodiment, the application management server 201 and the integrated resource management unit 202 are configured to be able to change the configuration of the management target by mutually transmitting and receiving control information.
  • a plug-in is provided in the application management server 201, or an API (Application Programmable Interface) is provided in the integrated resource management unit 202.
  • the application management server 201 can designate a specific physical device as a management target and have the authority to change the configuration of the specific physical device exclusively with other application management servers.
  • the hypervisor 24 can be considered as one application in that it is deployed on a physical host. Accordingly, a hypervisor management server for managing the hypervisor 24 may be provided.
  • the resource configuration of each device 10, 20, 50, 60, 100 managed by the management computer 200 is managed by the integrated resource management unit 202 and each device management unit.
  • the device management units are the server management unit 203, the network management unit 204, and the storage management unit 205.
  • Each device management unit manages the configuration of the physical server device such as the hosts 10 and 20, the network switch such as the FC SW 50 and the Ethernet SW 60, and the storage device 100 via the management network 302.
  • each device management unit changes the configuration of logical resources that operate on the devices to be managed, acquires and accumulates the operation information of the resources, It has a function to set attribute values.
  • Each device management unit may be a dedicated management program provided by a vendor who develops or manufactures a device.
  • Each device management unit and the integrated resource management unit 202 transmit and receive control information using a management interface such as an API, for example.
  • the integrated resource management unit 202 controls each device management unit in response to a request from the management client 72.
  • the integrated resource management unit 202 creates an instance and changes a device configuration necessary for configuration change through each device management unit. A specific configuration of the integrated resource management unit 202 will be described later.
  • a tenant is an example of a “resource partition”.
  • Each tenant is associated with each piece of configuration information such as users and user groups belonging to the tenant, definition of administrator authority for managing the tenant, and resources available in the tenant.
  • tenants which are resource partitions
  • hardware and physical data centers can be shared among multiple user groups while maintaining security and processing performance independence, and the overall resource utilization can be reduced. Can be increased.
  • a tenant is a group of users who share resources, for example.
  • an application management server 201 is prepared for each tenant. This is because the information processing system managed by the application management server 201 holds a lot of confidential information such as customer data and business data.
  • the application management server 201 can identify physical resources managed by the application management server 201 itself, and can use these physical resources exclusively from other types of application management servers.
  • one of the configuration management information possessed by tenants is the amount of resources.
  • the usage fee charged to each user is a pay-per-use charge calculated based on the amount of resources used by the user.
  • the physical resource amount held by the computer system does not necessarily match the amount that the user can contract (virtual resource amount).
  • the total amount of resources that each user can contract can be larger than the actual physical resource amount.
  • the purchase frequency and the number of purchased physical resources cannot be determined regardless of the user resource demand. Furthermore, the demand trend varies depending on the group to which the user belongs and the application to be used, and it is impossible to predict the amount of resource supply by ignoring them.
  • the simplest and most general method is a method of determining a certain amount of physical resources to be used for each user group to be contracted, that is, each tenant.
  • Such a range of resources available to a tenant is referred to as a resource pool.
  • User 301 creates instance 11 (or 21) in order to use a desired application.
  • the physical resources necessary for operating the instance are managed in advance in the resource pool 303.
  • the resource pool 303 is set by the device administrator using each device management unit on the management computer 200.
  • the device managers are, for example, a server manager 305a, a network manager 305b, and a storage manager 305c.
  • the device management units are, for example, a server management unit 203, a network management unit 204, and a storage management unit 205.
  • the resource pool 303 a combination of resources necessary for configuring an instance, such as the host 10 (or 20), the isolated network 304, and the volume 101, is registered in advance by each device management unit.
  • Various management operations such as instance creation and resource configuration change by the user 301 are performed by communicating with the management client 72, and are completed by the self-service of the user 301.
  • the user 301 may query the application management servers 201a and 201b in advance for requirements required by the application to be installed, and specify the requirements during various management operations.
  • the management client 72 has a function of requesting each configuration management component for at least operations related to configuration management of instances.
  • the application management servers 201a and 201b set in advance what is managed as a dedicated area for each application from among the resources registered in the resource pool 303. As a result, the application management servers 201a and 201b accumulate the detailed configuration and operation information of physical resources, and can manage applications more efficiently.
  • the application management servers 201a and 201b are referred to as application management servers 201.
  • the user 301 When the instance 11 (or 21) is prepared in the tenant 300, the user 301 notifies the application management server 201 of the desired instance, and constructs the desired application inside the desired instance.
  • the user 301 collaborates with the application manager 306 to examine details of the resource configuration or ask the application manager 306 to design. Also good. Further, the application management server 201 creates a new instance for constructing an application so that the application management server 201 can manage the physical device in which the instance is operating, or the application management server 201 dedicates the instance. A process of migrating to a physical device may be performed.
  • a dedicated application management server 201 is provided for each tenant 300, and an instance 11 (or 21) is created using physical resources deployed in the resource pool 303.
  • Each application management server 201 occupies a specific resource (host, network, volume, etc.).
  • the application management server 201 exclusively manages an application that is a management target of the application management server 201 with other application management servers.
  • applications businesses
  • applications can be transferred by transferring applications between virtual machine hosts according to the performance load of the instance 21, or by adding or deleting resources to the resource pool 303.
  • a resource pool to be allocated to a tenant is dynamically configured based on application requirements and operation information.
  • FIG. 3 is an explanatory diagram showing an overview of the resource management system and the resource management method according to this embodiment.
  • One of the concepts characteristic of this embodiment is a container 310 that manages a part of associated resources and provides it as a virtual resource.
  • the container 310 is a component corresponding to a physical resource (physical device) registered with the application management server 201 in the comparative example of FIG.
  • the container 310 has a role of virtualizing an actual physical hardware configuration.
  • alphabets attached to symbols are ignored.
  • the tenants 300a and 300b may be referred to as the tenant 300, the resource pools 303a and 303b as the resource pool 303, and the application management servers 201a and 201b as the application management server 201.
  • the container 310 is used as a resource pool for each application.
  • Each tenant manages resource information such as the contract resource amount for each tenant.
  • the integrated resource management unit 202 configures all physical resources in advance as containers 310 and registers them as management targets in each application management server 201. As will be described later, it is not necessary to match the virtual resource configuration provided by the container 310 with the physical resource configuration registered in the container. Therefore, the resource amount of the container 310 can be defined exceeding the total amount of physical resources.
  • Examples of physical resources as “resources” associated with the container 310 include a server (calculation resource), a network (communication resource), and a storage resource.
  • the container 310 is configured by a combination of these physical resources, and can be registered as a management target of the application management server 201.
  • a server cluster configured by combining a plurality of servers may be used.
  • a logical partition (LPAR) host is a server resource that logically divides each component such as a CPU and a network adapter.
  • the server cluster for example, there are a redundant virtual machine host 20, a redundant bare metal host 10, or a server group having a SMP (symmetric multiprocessing) configuration by combining buses of a plurality of servers.
  • the network resource 311b is a range (isolated network) that can be communicated between hosts, such as a virtual LAN, subnet, or virtual private network controlled by layer 2 or layer 3.
  • the network resource 311b may be an appliance that provides a network function, such as a firewall, a load balancer, and a VPN (Virtual Private Network) gateway.
  • the storage resource 311c is, for example, a volume 101 provided by the storage apparatus 100, or a directory on the network file system.
  • the above-mentioned resources 311a, 311b, and 311c may be specific devices provided in the data center, or may be server instances or object storage procured from an external IaaS cloud.
  • the configuration of the container 310 is managed by the integrated resource management unit 202.
  • the application management server 201 procures necessary containers 310 by requesting resources from the integrated resource management unit 202.
  • the application management server 201 can occupy a desired container 310 and use the container 310 as a resource area dedicated to the application.
  • the integrated resource management unit 202 controls configuration management such as which resources 311 are physically allocated to which containers 310.
  • the integrated resource management unit 202 can change the physical configuration of the container 310 without being involved in the application management server 201. Therefore, according to the present embodiment, resources can be interchanged between a plurality of applications or a plurality of tenants without interfering with the application management system, and the resource utilization rate can be leveled.
  • resources managed by the same application management server 201a can be adjusted between containers provided to different tenants.
  • the resource of the first container 310 (1) managed by the management server 201a of application A is used for the instance 11a via the resource pool 303a of the first tenant 300a.
  • the resources of the second container 310 (2) managed by the same application management server 201a are used for the two instances 11b via the resource pool 303b of the second tenant 300b.
  • the user 301b using the instance 11b requests resource addition to the second container 310 (2).
  • This resource addition request is sent from the client computer 70 to the management computer 200 via the communication network 301.
  • resources are migrated from the first container 310 (1) to the second container 310 (2) managed by the same application management server 201a.
  • the first container 310 (1) in which resources are reduced may be referred to as a migration source container
  • the second container 310 (2) to which resources are added may be referred to as a migration destination container.
  • the first container 310 satisfies a predetermined migration source selection condition such as a low resource utilization rate.
  • a predetermined migration source selection condition such as a low resource utilization rate.
  • the resource utilization rate is below the reference value (or the utilization rate is the lowest)
  • the functions indispensable for applications that use the resource migration destination container Have satisfy application constraint conditions
  • no performance degradation such as bottleneck.
  • Conditions other than these may be added to the migration source selection conditions, and some of the above conditions may be excluded from the migration source selection conditions.
  • the processing capacity of the second container 310 (2) increases and the load is reduced.
  • FIG. 3 also shows an example (312b) of adjusting resources between different applications.
  • the third container 310 (3) managed by the management server 201b of the application B is used for the instance 11a via the resource pool 303a of the first tenant 300a.
  • the application management server 201b manages another container 310, but the container 310 is not used.
  • the user 301a desires to improve the response performance of the instance 11a that uses the third container 310 (3)
  • the user 301a requests the management computer 200 to add resources to the third container 310 (3).
  • a part of the resources virtually allocated to the first container 310 (1) moves to the third container 310 (3).
  • the first container 310 (1) is selected as a resource migration source container in order to satisfy a predetermined migration source selection condition.
  • the resource presented to the application management server 201 can be virtualized by the container 310 created and managed by the integrated resource management unit 202. Therefore, even when there is a change in the physical device configuration allocated to the container 310, such as addition or deletion of a storage medium, the application management server 201 has no knowledge of the change in the physical device configuration.
  • the application management server 201 can manage applications regardless of changes in the physical device configuration.
  • FIG. 4 shows a management component group that is provided in the management computer 200 and implements functions characteristic of the present embodiment.
  • the integrated resource management unit 202 provides a function of allocating resources between containers according to the resource usage rate.
  • the user request management unit 210 is a function for managing user requests.
  • the user request management unit 210 receives a configuration change request such as a user instance creation request from the management client 72.
  • the user request management unit 210 returns the result of the configuration change by the integrated resource management unit 202 to the management client 72.
  • the user request management unit 210 controls the execution order, progress status, and the like.
  • the integrated resource management unit 202 uses the instance management table 211 and the tenant management table 212 to hold configuration information provided to the user and the application management server 201.
  • the virtual resource configuration provided to the tenant 300 or the application management server 201 is managed for each container 310 and held in the container management table 215.
  • the resource configuration management unit 213 is a function for managing the resource configuration, and operates in cooperation with the application management server 201.
  • the resource configuration management unit 213 controls the association between the container 310 and the physical device (resource) while referring to the operation information held in the resource operation information database 216.
  • the resource configuration management unit 213 processes the operation information of each resource according to a management method set in advance, and stores the processing result in the performance evaluation table 214. Specifically, the resource configuration management unit 213 evaluates or processes resource operation information based on resource requirements (performance requirements) requested by the application, and stores the results in the performance evaluation table 214.
  • the integrated resource management unit 202 transmits a control command for the configuration of each device 10, 20, 50, 100 to be managed to each device management unit 203, 204, 205.
  • the device management units 203, 204, and 205 obtain the utilization rate and actual performance from each managed device and store them in the resource operation information database 216.
  • the resource operation information database 216 has a function of providing a history of operation information for each component using the device identifier and time stored in the container management table 215 as keys.
  • the application management server 201 includes, for example, a resource management unit 206, a resource requirement definition table 207, and an application operation information database 208.
  • the resource management unit 206 requests the integrated resource management unit 202 to change the configuration in order to manage the configuration of the target resource used by the application.
  • the application management server 201 defines requirements suitable for the application, and holds these requirements in the resource requirement definition table 207. Since resource requirements differ depending on the type of application, the format of the resource requirement definition table 207 for managing resource requirements is not constant and may vary from application to application.
  • the application operation information database 208 holds operation information such as application setting values and performance values.
  • the application operation information includes, for example, a calculation resource, a connection established with the service client 71, a use status of the connection, and the like.
  • the calculation resource is, for example, a process, thread, memory space, etc. used by the application.
  • the connection usage status is, for example, response time, number of transactions, and the like.
  • the operation information has a data structure such as a unique name and attribute based on the design of each application.
  • FIG. 5 shows an instance management table 211 for storing setting values and attributes managed for each instance.
  • Information described in the instance management table 211 is provided to the user via the client computer 70.
  • the identification information of the physical device assigned to the instance is provided to the user in an abstracted manner. The user does not necessarily need to know which physical resource is actually allocated to the instance 11 used by the user.
  • the instance management table 211 includes, for example, an instance identifier 211a, an instance owner 211b, a resource pool 211c to which the instance belongs, a container 211d, a resource configuration 211e, a network policy 211f, a grade 211g, a consumption point 211h, an expiration date 211j, ( The application management server identification name 211k is stored in association with it (if necessary).
  • each instance 11 represents a logical computer having a guest OS.
  • a virtual resource configuration 211e is defined in the table 211.
  • the instance identifier 211a is information for uniquely identifying the instance 11.
  • the owner 211b is information that uniquely identifies a user who uses the instance 11.
  • the resource pool 211c is information for uniquely identifying the resource pool 303 to which the container 310 used by the instance 11 belongs.
  • the container 211d is information that uniquely identifies the container 310 that provides resources to the instance 11.
  • the resource configuration 211e is composed of components such as a CPU and a memory as in a general computer architecture.
  • the contents of the resource configuration 211e can be individually set according to a user request.
  • template data of the resource configuration 211e may be prepared.
  • the total of the resource configurations 211e of the instances having the same container identifier 211d is set so as not to exceed the resource capacity provided by the container 310.
  • the resource configuration 211e does not necessarily match the resource configuration of the physical device associated with the container 310.
  • the network policy 211f sets a protocol to be used and communication permission or disapproval regarding communication between instances and communication with other hosts on the public communication network.
  • the grade 211g sets a service level for the resource performance assigned to the instance.
  • the instance 11 can be associated with contract information based on, for example, a contract between a data center operator and a user.
  • the contract information includes, for example, a consumption point 211h for determining a usage fee, a usage time limit 211j indicating the remaining period of a valid contract, and the like.
  • Information related to licenses, user application identification information, and the like may be managed in the table 211 in accordance with the subject and form of the contract.
  • the user can introduce and operate a desired application to the instance by notifying the application management server 211k or application manager of the identifier 211d of the container used by the user's instance. .
  • FIG. 6 shows a tenant management table 212 for managing tenants.
  • the tenant management table 212 stores setting values and attributes managed for each tenant.
  • a tenant ID 212a for example, a tenant ID 212a, a user group ID 212b, a management role definition 212c, a resource pool ID 212d, an instance management table ID 212e, and a remaining available point 212f are stored in association with each other.
  • the tenant ID 212a is information for uniquely identifying the tenant 300.
  • the user group ID 212b is information that uniquely identifies a user group.
  • the management role definition 212c is information for identifying information that defines a user role and management authority.
  • the resource pool ID 212d is information for uniquely identifying the resource pool 303 provided in the tenant.
  • the instance management table ID 212e is information for uniquely identifying the instance management table 211 for managing instances operating in the tenant.
  • the remaining available point 212f is information representing the usage fee of the available contract resource.
  • FIG. 7 shows a container management table 215 for managing containers.
  • the container management table 215 stores setting values and attributes managed for each container.
  • the container management table 215 manages the correspondence between container information and physical devices (resources) notified to the application management server 201.
  • the container ID 215a and the access authority 215b necessary for the configuration change are delivered to the application management server 201.
  • the application management server 201 does not disclose information 215c to 215k related to the physical device configuration.
  • Container ID 215a is information for uniquely identifying a container.
  • the access authority 215b is information for uniquely identifying access authority information for accessing a container and managing a logical resource configuration.
  • the application management server 215c is information that uniquely identifies the application management server 201 that manages applications that use containers.
  • the container management table 215 holds, for example, a combination of the server 215d, the network 215e, and the storage 215g as the contents of the container 310.
  • the total amount of resources constituting the container 310 is held in the virtual resource capacity 215j and the real resource capacity k.
  • the virtual resource capacity 215j and the actual resource capacity k are both amounts managed by the integrated resource management unit 202.
  • the actual resource capacity 215k is equal to the total of the resource capacity physically possessed by the device managed as one container
  • the virtual resource capacity 215j is a virtual resource capacity provided to the application management server 201. is there. Due to the function of the integrated resource management unit 202, the two may not match.
  • the instance type 215f indicates the type of instance running on the container.
  • a configuration management method and a device management unit can be managed by the instance type 215f.
  • the instance type 215f for example, “VM” is set if the container is the virtual machine host 20, and “PM” is set if the container is the bare metal host 10.
  • the application management server 201 cannot use the container 310 specified by the container ID 215a as a management target unless the access authority information specified by the access authority 215b is used. However, only a specific application may be available depending on the container configuration. Information for identifying an application that can use a container having a specific configuration is set in the application constraint 215h.
  • only a specific application can be used.
  • the hardware certified by the application developer is guaranteed to operate
  • a specific hardware function is required to operate the application
  • the firmware configuration of a specific version There is a case where the operation is guaranteed only with.
  • the application constraint field 215h is set manually or automatically by the administrator or the application management server 201, and the value is updated when the configuration of the container specified by the container ID 215a is changed.
  • the container 310 by introducing a characteristic configuration called the container 310, the physical device configuration and the logical device configuration recognized by the application management server 201 or the tenant 300 can be separated.
  • a physical device to be transferred into a container can be interchanged or the entire container can be exchanged between different types of applications or between different tenants.
  • the resource configuration allocated to the business system (application) can be dynamically changed according to the usage status without affecting the existing application management system or tenant management system.
  • the resource utilization of the entire data center can be increased by performing resource allocation to containers based on different types of application requirements (conditions required by applications for resources). It is therefore important to evaluate and adjust different types of application requirements from a unified perspective.
  • FIG. 8 shows the concept of a method for evaluating performance in consideration of application requirements.
  • FIG. 8 is a two-dimensional plan view for the sake of explanation, the same applies to the case of evaluating with any positive N-dimension according to the number of performance indexes to be considered.
  • FIG. 8A shows the distribution of each of the containers 310a to 310d in a certain performance index (for example, CPU usage rate and disk IOPS).
  • a certain performance index for example, CPU usage rate and disk IOPS.
  • the range of the target performance value defined by the resource manager is indicated by a dotted line 321.
  • One idea is to define a service level using a target performance value range 321 based on the performance of a physical device (resource) itself and present it to the user as a grade.
  • the usage status of each container is evaluated based on the distance from the origin. For example, it can be analyzed that the resource usage rate of the container 310c is relatively low and the resource usage rate of the container 310b is high. Regarding the containers 310a and 310b, it is determined that the usage tendency is biased.
  • the type of required resource differs depending on the type of application running on the container. Therefore, a method for uniformly evaluating the performance index without considering the type of application is not appropriate. That is, if the resource requirements defined by the application management server 201 and know-how for application management can be taken into consideration, the resource utilization rate can be determined fairly based on the demand trend of resources in the container.
  • Fig. 8 (b) shows a performance evaluation method that takes into account the usage characteristics of different resources for each application.
  • the resource usage trend of application A is shown as a performance characteristic curve 322.
  • the performance characteristic curve 322 of the application A and the performance values of the containers 310c and 310d in which the application A operates are superimposed, it can be seen that the container 310c has a resource utilization rate suitable for the application A. However, it turns out that the container 310d is not suitable for the application A.
  • the reason why the container 310d is not suitable for the performance trend of the application A is that a bottleneck exists in another resource element (for example, network performance) associated with the container 310d, or is assigned to the container 310d. If there is too much CPU resource amount, it is estimated that either or both of them are used.
  • another resource element for example, network performance
  • the same analysis is possible for application B.
  • the performance characteristic curve 323 indicating the resource usage tendency of the application B and the performance values of the containers 310a and 310b in which the application B operates are overlapped for determination. It can be seen that the container 310a is not suitable for the performance trend of the application B.
  • the containers 310a and 310d are exchanged between the application A and the application B, or the resource configuration of the container 310a is changed to be close to the resource configuration of the container 310d. Improvement measures such as
  • the resource utilization rate of the entire data center can be maximized in consideration of application characteristics.
  • the first technical feature is the concept of “container” that separates the resource configuration targeted by the application management server 201 and the configuration of the physical device.
  • a second technical feature is an expression format for uniformly comparing resource requirements of heterogeneous applications. This will be described later.
  • a third technical feature is a configuration management method for accommodating physical devices (resources) among a plurality of containers.
  • information related to the resource configuration required by the application management server 201 is held in the resource requirement definition table 207.
  • Information regarding these resource requirements is not constant for each application, and the resource requirement expression format held by the application management server 201 is also different for each application.
  • FIG. 9 shows an example of the resource requirement definition table 207 for defining resource requirements.
  • the resource requirement definition table 207 shown in FIG. 9A manages the target 207a, resource item 207b, request value 207c, operation status 207d, and evaluation value 207e in association with each other.
  • the target 207a is information for uniquely identifying the container 310 to be used by the application.
  • the resource item 207b is information indicating a resource item associated with the target container 207a.
  • the request value 207c is a condition that the application requests to the resource.
  • the operating status 207d is an actual measurement value of the performance index indicated by the resource item 207b.
  • the evaluation value 207e is information that determines whether or not the value of the operation status 207d satisfies the request value 207c.
  • FIG. 9B shows a resource requirement definition table 207 (1) in another format.
  • the target 207f and the evaluation value 207g are managed in association with each other, and other items (resource items, request values, operating status) are not managed.
  • a performance requirement (207b) is defined for a specific component (resource), and as shown in FIG.
  • performance requirements are defined using performance values that are not directly related to resource requirements, such as the number of processing threads.
  • FIG. 10 shows a performance evaluation table 214 specific to the present embodiment, which is used by the resource management unit 213 to calculate operation information for the entire resource.
  • a performance index 214b that needs to be evaluated and its actual measurement value 214c are held for the container ID 214a based on the resource requirements determined for each type of application.
  • a correction coefficient 214d is provided in order to compare and evaluate resource requirements by a plurality of different types of applications in common.
  • the actual measurement value 214c of each performance index 214b is corrected by the correction coefficient 214d, and the correction result is recorded in the correction value 214e.
  • the correction value 214e is calculated as a simple product of the actual measurement value 214b and the correction coefficient 214d, and is a dimensionless value.
  • the performance index 214b includes not only an index indicating the high resource utilization rate but also an index indicating the degradation of resource performance.
  • an index indicating the degradation of resource performance for example, an index in which the magnitude of performance degradation appears as a numerical value, such as a response time of disk I / O, and the like, it is used for determining a comprehensive performance bottleneck. There are also indicators.
  • Which component (resource) is selected as the performance index 214b may be automatically set by the application management server 201 or may be set by an administrator.
  • the correction coefficient 214d is an important value for fairly comparing the performance of the container 310 with respect to a plurality of different applications, and has a meaning of a weight for giving a quantitative value indicating how much each performance index is important. .
  • the correction coefficient 214d the resource performance characteristics for each application described above can be expressed.
  • the CPU usage rate (the ratio of CPU time to the total processing time) in the container ID: CNT-A021 is 45%
  • the CPU usage rate in the container ID: CNT-A025 is 69%.
  • the correction coefficient 214d may be set by the hand of each application administrator, or may be automatically set by the application management server 201.
  • the resource configuration management unit 213 may calculate the correction coefficient by statistically processing the operation information.
  • the above magnification is calculated using, for example, the following formula using values that can be taken for each performance value.
  • the application magnification represents the importance and popularity of the application, and is evaluated based on the number of applications installed (number of instances).
  • the evaluation value 207g is calculated from the following equation.
  • simultaneous equations are established with the number of records in the resource requirement definition table 207 held in the same application as the order. If each performance index 214b is independent of each other, the simultaneous equations have a solution, and the correction coefficient 214d is determined. When one or more sets of each performance index 214b are dependent, an approximate solution obtained by the least square method or the like may be used as the correction coefficient 214d.
  • FIG. 11 is a flowchart of processing for correcting the operation information of each container based on the resource requirement requested by the application, calculating the operation information for the entire resource, and determining a container that accommodates the resource.
  • the resource configuration management unit 213 When the resource configuration management unit 213 receives, for example, a resource addition request from the application management server 201 (S10), the subsequent processing is triggered by the reception.
  • the resource addition request includes the type of the application 12 (or 22). It may also include the amount of resources to be added.
  • the predetermined trigger for starting a series of processes for changing the resource allocation by changing the configuration of the container 310 is not limited to the reception of the resource addition request described above. For example, this processing may be started when the system administrator explicitly instructs.
  • the integrated resource management unit 202 may periodically execute this process.
  • the application management server 211k When the user request management unit 210 receives a request for an instance configuration change, the application management server 211k may be identified from the instance management table 211 and this process may be executed.
  • a configuration may be employed in which the type and amount of additional necessary resources are automatically specified by automatically calculating based on the history of resource utilization.
  • step S11 the integrated resource management unit 202 determines whether or not the resource requirements defined in the application management server 201 have changed. Specifically, the resource configuration management unit 213 refers to the resource requirement definition table 207 via the resource management unit 206 on the application management server 201 and determines whether there is an update. If there is an update as a result of the determination (S11: YES), the resource configuration management unit 213 calculates the correction coefficient 214d again in step S12, and updates the performance evaluation table 214 to the latest state.
  • step S13 the resource configuration management unit 213 acquires the actual measurement value 214c of the operation information from the resource operation information database 216, calculates the correction value 214e, and stores it in the performance evaluation table 214.
  • step S14 the resource configuration management unit 213 sequentially searches the records described in the container management table 215, and starts a process of detecting a container having a low resource utilization rate.
  • a container with a low resource utilization rate is determined by calculating the sum of correction values 214e related to positive influence determination (+) in the performance evaluation table 214 and selecting one having a small total value.
  • step S15 the resource configuration management unit 213 refers to the application restriction 215h in the container management table 215, and determines whether the application that requests the addition of the resource can be operated on the processing target container. If the resource configuration management unit 213 determines that the processing target container violates the application restriction 215h (S15: YES), the resource configuration management unit 213 returns to step S14 and selects another container having a low sum of the correction values 214e as the processing target container.
  • step S16 the resource configuration management unit 213 refers to the influence determination 214f of the performance evaluation table 214 to determine whether there is a performance deterioration larger than a predetermined performance deterioration reference value.
  • a method for determining the presence or absence of performance degradation for example, in addition to a method based on a threshold, a method of comparing the magnitude of the negative performance influence degree 214f between a candidate container that has already been selected and a processing target container There is.
  • the negative performance influence degree 214f of the processing target container is larger than the corresponding value 214f of the candidate container, it may be determined that there is performance degradation.
  • the resource configuration management unit 213 selects the processing target container as a candidate container for reviewing the resource configuration in step S17.
  • the number of containers selected as candidates is not limited to one, and a plurality of containers may be selected as candidates. Note that candidate containers may be selected in consideration of the container type 215f shown in FIG.
  • step S18 the resource configuration management unit 213 determines whether there is an unprocessed container among the containers described in the container management table 215. If there is an existing container (S18: YES), the resource configuration management unit 213 returns to step S14 to Repeat the steps.
  • step S19 the resource configuration management unit 213 changes the resource configuration of the candidate container when one or more candidate containers are detected.
  • a change in the resource configuration of a candidate container is typically a resource reduction.
  • the processing for reducing the resource configuration of the container in step S19 includes, for example, processing for deleting one or more nodes (physical servers) from the server cluster, processing for reducing volumes from storage resources, and communication priority set for network resources. There is a process to reduce the degree.
  • the process of consolidating instances may be executed in another container managed by the same application management server 201.
  • a new container having a resource capacity smaller than that of the candidate container is created, and the newly created small container executes processing for taking over the instance running on the candidate container and the identification information of the candidate container. May be.
  • step S19 the identification information and instance of the candidate container are not deleted, and the record of the container management table 215 is updated to an appropriate value by the resource configuration management unit 213. Is done. More specifically, for example, in step S19, when a node is deleted from the server cluster of the migration source container, if the virtual server is operating on the node, the virtual server is in the same server cluster. It is migrated to the node and remains in the migration source container. At this time, the instance management table 211 and the virtual resource capacity j of the container management table 215 are not changed. As a result, the user who uses the migration source container and the application management server 201 can continue to use it without noticing the physical configuration change in step 19. On the other hand, the identifier of the node is deleted from the server field 215d of the record that manages the migration source container in the container management table 215, and the resources of the node are subtracted from the actual resource capacity k field.
  • step S19 the surplus resources generated by the candidate container reduction process are moved to the container for which resource addition is requested in step S10.
  • the resource configuration management unit 213 updates the record of the container management table 215 to an appropriate value.
  • the virtual resource capacity j Add the capacity for the added resource.
  • the migration destination container performs a process of adding resources constituting the container. Thereafter, a process of leveling the load in the same container, for example, a process of rearranging virtual machines in the virtual machine host cluster may be performed.
  • the application management server 201 When the application management server 201 manages the container 310, access to a physical device is required.
  • the application management server 201 accesses the physical device using the access information.
  • the access information for example, a management IP address, an authentication account, and a device ID can be used.
  • the application management server 201 can change the resource configuration of the container 310 safely and reliably by using appropriate access information.
  • the configuration change here refers to, for example, a change in power supply state, a change in BIOS (Basic Input / Output System) setting values such as a boot option, a change in network adapter settings such as a physical address, and an input / output device switching.
  • BIOS Basic Input / Output System
  • the OS on the physical device is used. Therefore, by reconfiguring or reinstalling the OS, any number of new server environments can be created. Access information could be set.
  • step S19 in the process of FIG. 11 described above when the container 310 is composed of a single physical device (for example, when the bare metal host 10 is used), the same physical device is transferred to another application management server container. You need to register again. For this reason, it is necessary to transfer access information from the migration source application management server to the migration destination application management server.
  • migration of access information does not mean that the access information used at the migration source can be used as it is at the migration destination, but for the migration destination application management server to use the migration destination container safely. This means that access information is set in the migration destination application management server.
  • the migration source application management server that originally used the physical device can still access the migrated physical device. is there. Therefore, unauthorized access, system failure, data loss, etc. may occur.
  • appropriate migration of access information is indispensable.
  • FIG. 12 is a flowchart showing processing for migrating access information.
  • the access information may be referred to as access authority information.
  • step S30 the resource configuration management unit 213 invalidates the access authority set in the migration target physical device and used by the migration source application management server 201.
  • the reason why the access authority is not completely deleted is to prevent the effective access authority from being lost even if an unexpected failure occurs during the subsequent processing.
  • step S31 the resource configuration management unit 213 requests the resource management unit 206 of the migration source application management server 201 to delete the access authority for the migration target physical device.
  • the firewall 303 on the management network may block the access path from the migration source application management server 201 to the migration target physical device.
  • step S32 the resource configuration management unit 213 creates a new access authority on the physical device to be migrated through the server management unit 203 and validates it.
  • step S33 the resource configuration management unit 213 notifies the migration destination application management server 201 of the new access authority generated in step S32, and sets to use the new access authority in the future.
  • the firewall 303 on the management network permits the access path between the migration destination application management server 201 and the physical device to be migrated. That's fine.
  • step S34 the resource configuration management unit 213 confirms that the access authority has been appropriately transferred.
  • confirmation means, for example, a connection test is performed from the migration source application management server and the migration destination application management server 201 to each physical device to be migrated.
  • the resource configuration management unit 213 proceeds to step S36, returns the state to the start point of this flowchart, and ends with an error.
  • step S35 the resource configuration management unit 213 deletes the old access authority that has been revoked in step S30 from the physical device to be transferred, and executes this process. Finish normally. Thereby, the migration source application management server 201 cannot permanently access the migrated physical device, and safety is maintained.
  • the resources allocated in advance to the application program may be set to be less than the usage amount specified in the resource addition request.
  • additional allocation of resources is possible at any time according to the subsequent usage status. Therefore, the computer system can be efficiently operated with few resources.
  • the expression “the resource may be set to be smaller than the specified usage amount” may be rephrased as “the resource is set to be lower than the specified usage amount”.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)

Abstract

　統合リソース管理部２０２は、リソース３１１ａ、３１１ｂ、３１１ｃの一部を管理し仮想リソースとして提供する複数のコンテナ３１０を、アプリケーションプログラム毎に予め用意している。統合リソース管理部は、使用するリソースを区分けするために予め設定されるテナント３００ａ、３００ｂのうちいずれかのテナントに関して発行される所定の要求に応じて、複数のコンテナの中から選択するコンテナを要求元のテナントに提供する。統合リソース管理部が要求元のテナントに提供するコンテナには、リソースのうち、所定の要求で指定されたアプリケーションプログラムに予め割り当てられているリソースを指定された使用量よりも少なく設定する場合がある。

Description

リソース管理システムおよびリソース管理方法
　本発明は、リソース管理システムおよびリソース管理方法に関する。
　近年、データセンタ全体のリソース利用効率を高めるべく、サーバを仮想化する技術を用いて、複数の業務システムを物理計算機リソース上に集約する情報処理システム基盤が普及している。
　リソース上で固定的に稼働していたシステムを仮想化技術によりリソースから分離し、業務アプリケーションの稼働状況に応じて、システムを複数の物理計算機リソース間で移行させる。これにより、負荷の不均衡を動的に平準化できる。
　一方、仮想マシンの物理配置に合わせてネットワーク構成を制御することで、特定のユーザグループが使用するシステム群をテナントと呼ばれるリソース空間に隔離できる。これにより、テナントのセキュリティを確保することができる。
　例えば特許文献１では、複数のテナントが複数の物理計算機リソースを使用する仮想計算機システムにおいて、グループ間の負荷の不均衡を迅速に解消する技術を開示する。特許文献１では、複数の仮想計算機を複数のリソースグループ上で管理し、負荷に応じて複数の仮想計算機を物理計算機リソース間で移行させることで、負荷を分散する。
米国特許出願公開第２０１２/０２５４４４５号明細書
　しかしながら、従来技術では、物理計算機リソースと仮想計算機とを直接的に対応付けて管理するため、柔軟性に乏しく、時々刻々と変化する環境への適応能力についてまだ改善の余地がある。
　また、従来技術は、仮想サーバの性能負荷を画一的に評価するものであり、仮想サーバ上に設けられているアプリケーションの性能特性を考慮していない。一般に業務アプリケーションには、リソースに対する要件が存在するが、アプリケーションの種類や構成規模などにより、それらリソース要件は一定ではない。
　特にＩａａＳ（Infrastructure as a Service）クラウドと呼ばれ、セルフサービス方式の利用形態をとる計算機システムにおいては、どの仮想サーバにどのアプリケーションを構築するか、という決定権は仮想サーバのユーザに委ねられている。しかし、ユーザの需要傾向や業務サービスの需要傾向を事前に予測するのは困難である。したがって、そのような計算機システムでは、一つのシステム環境に異なる種類のアプリケーションが混在することになる。
　混在するアプリケーションの比率によって、利用率の低いリソースが生じる。例えば、ＣＰＵ（Central Processing Unit）性能に対する要求が高くストレージ性能に対する要求が低いアプリケーションと、メモリ性能に対する要求が高くストレージ性能に対する要求が低いアプリケーションとが混在する場合、ストレージリソースの性能に余剰が生じてしまう。
　このような非効率なリソース利用を避けるために、テナント内に、アプリケーションの性能特性に応じてサイジングした、専用のリソース領域を定める方法が考えられる。例えば、テナント内に、アプリケーションＡ向けのリソース領域と、アプリケーションＢ向けのリソース領域とを用意する。ユーザは、所望のアプリケーションに応じて、それら専用のリソース領域のリソースを利用して仮想サーバを生成する。この方法によれば、専用のリソース領域それぞれでは効率的に運用できるものの、リソース全体における利用率の向上は望めない。
　本発明は、上記の問題に鑑みてなされたもので、その目的は、状況変化に対応して、リソースの利用効率を高めることができるリソース管理システムおよびリソース管理方法を提供することにある。
　本発明の一つの観点に係るリソース管理システムは、リソースを提供する複数の物理計算機と、少なくとも一つのアプリケーションプログラムを実行する複数の仮想計算機と、複数の物理計算機および複数の仮想計算機に通信可能に接続される統合リソース管理部とを有し、統合リソース管理部は、対応づけられるリソースの一部を管理し仮想リソースとして提供する複数のコンテナを予め用意し、提供される仮想リソースの利用範囲を定義するリソース区画を管理し、コンテナはアプリケーションプログラムの何れかに対応づけられており、リソース区画で動作するアプリケーションプログラムのリソース構成変更要求を受けると、当該アプリケーションプログラムに対応づけられるコンテナに他のコンテナで管理されるリソースを移行し、他のコンテナの管理するリソース量は他のコンテナの提供する仮想リソースより少なくなることがある。
　本発明によれば、コンテナはアプリケーションプログラムの何れかに対応づけられており、リソース区画で動作するアプリケーションプログラムのリソース構成変更要求を受けると、当該アプリケーションプログラムに対応づけられるコンテナに他のコンテナで管理されるリソースを移行する。したがって、本発明によれば、状況変化に応じてリソースを移行させることができ、リソースの利用効率を高めることができる。
リソースを管理する計算機システムの構成図。 比較例としてのリソース管理方法の概要を示す説明図。 本実施例によるリソース管理方法の概要を示す説明図。 管理コンピュータに設けられる管理プログラムなどを示す説明図。 インスタンスを管理するテーブルの構成図。 テナントを管理するテーブルの構成図。 コンテナを管理するテーブルの構成図。 異なるアプリケーション間で性能を統一的に評価する概念を示す説明図。 アプリケーションの要求するリソース要件を定義するテーブルの例。 コンテナの性能を統一的に評価するテーブルの構成図。 テナントからの要求に応じてコンテナの構成を変更する処理を示すフローチャート。 アクセス権限を移行する処理を示すフローチャート。
　以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。本実施形態で開示される複数の特徴は、様々に組み合わせることができる。本実施形態の処理動作の説明では、「コンピュータプログラム」を動作主体（主語）として説明することがある。コンピュータプログラムは、マイクロプロセッサによって実行される。したがって、プロセッサを動作主体として読み替えても良い。
　本実施形態では、複数のアプリケーションが混在して稼働するクラウド環境において、テナントごとに定められたリソース領域、あるいはアプリケーションごとに定められたリソース領域を越えて、計算機システムの需要変化に応じてリソースを動的に融通しあうことにより、データセンタ全体のリソース利用効率を向上させる。
　本実施形態では、複数のアプリケーションが要求する性能特性（リソース要件）を、それぞれのアプリケーションを管理するためのアプリケーション管理部より取得する。本実施形態では、各アプリケーションの要求する性能特性を考慮して、リソース全体におけるリソース需要を統一的な観点で算出する。
　さらに、本実施形態では、アプリケーションの要求する性能特性を考慮したリソース需要に基づいて、リソース全体の配置を計画する。本実施形態では、アプリケーション専用のリソース領域を越えて、リソースプールを再構成する。
　本実施形態によれば、テナント毎のリソース管理体系やアプリケーション管理体系に矛盾することなく、時々刻々と需要が変化するデータセンタにおいて、リソース全体の利用率を最適化することができる。また、本実施形態によれば、テナントごとのセキュリティを確保しつつ、従来の運用で培ったアプリケーション管理のノウハウを引き続き活用することができる。
　図１～図１２を用いて第１実施例を説明する。本実施例では、アプリケーションの要求するリソース要件を満足するように各インスタンスを構成し、かつリソース全体の利用率を高める。
　＜システム構成＞
　図１は、本実施例における計算機システムの構成を示す。計算機システムは、例えば、情報処理サービスを稼働させるホスト１０およびホスト２０と、サービスを要求するユーザが使用するクライアントコンピュータ７０と、計算機システムを管理する管理コンピュータ２００とを含んで構成することができる。
　ホスト１０は、例えば、物理的なＣＰＵ、メモリ（主記憶装置）、入出力装置、ネットワークインタフェース、およびそれらを相互に接続する内部バスなどを備える一般的なコンピュータアーキテクチャによって構成されている。
　ホスト１０上には、物理的な処理リソースを直接的に制御するＯＳ（Operating System）１３が稼働している。アプリケーション管理者またはユーザは、ホスト１０上のＯＳ１３をゲストＯＳ１３として利用することで、直接的にホスト１０の論理構成を制御することができる。
　ゲストＯＳ１３がホスト１０の全ての物理的な処理リソースの構成を制御できるため、本実施例では、ホスト１０をベアメタルホスト１０と呼ぶ。本実施例では、ゲストＯＳ１３により制御される論理的なサーバ構成を、インスタンス１１と呼ぶ。インスタンス１１において、一つ以上のアプリケーション１２を稼働させることで、ユーザは所望の情報処理サービスを享受できる。なお、図中では、アプリケーションを「Ａｐｐ」と略記する場合がある。
　ホスト２０も、ホスト１０と同様の構成を有するが、ハイパバイザ２４、または仮想マシンモニタなどと呼ばれる仮想化ソフトウェアを備える。仮想化ソフトウェアにより、物理リソースは論理的に一つ以上のゲストＯＳ領域に分割されて、アプリケーション管理者またはユーザに提供される。これらゲストＯＳ領域を一般に仮想マシン２１または論理パーティションと呼び、ホスト２０を仮想マシンホスト２０と呼ぶ。
　これらゲストＯＳ領域は、仮想化ソフトウェアの方式により、例えばタイムスケジューリングによりＣＰＵコアなどの物理コンポーネントを共有する仮想マシンであっても良いし、あるいは、固定的に物理コンポーネントを対応付けておく論理パーティションであっても良い。ここでは簡単のため、特にこれらを区別せず単に仮想マシンと呼ぶ。仮想マシン内ではゲストＯＳ２３が稼働しており、さらにユーザが利用するためのアプリケーション２２が稼働している。仮想マシンは一つの論理的なサーバ構成に相当する。ベアメタルホスト１０と同様に、仮想マシンをインスタンス２１と呼ぶことにする。本実施例にかかる計算機システムは、同様の構成を持つ物理サーバおよびストレージを、ベアメタルホスト１０および仮想マシンホスト２０の二通りに利用する。ただし、以降の説明において特に断らない限り、ベアメタルホスト１０上のインスタンス１１および仮想マシンホスト２０上のインスタンス２１を区別せず、単にインスタンス１１と記載する。
　一般にクラウドと呼ばれるような、ユーザの作成要求に応じて動的にインスタンスを作成するシステムでは、仮想マシンを利用する場合が多い。仮想マシンを利用すると、インスタンス構成をホストの物理リソース構成から分離することができる。これにより、アプリケーションを稼働させるサーバ構成を柔軟かつ即座に生成することができ、かつ生成後の構成変更も容易である。
　一方、仮想マシンは、仮想マシンホスト２０が有する物理リソースを共有しているため、同一の仮想マシンホスト２０に設けられている他の仮想マシンから性能上の影響を受けざるを得ない。このような環境は、例えば安定したディスクＩ／Ｏ（Input/Output）性能を必要とするデータベースなど、要求性能の厳しいアプリケーションには適さない。
　そこで、本実施例では、物理リソースと一対一に対応するベアメタルホスト１０を用意している。本実施例では、ベアメタルホスト１０を活用することで、安定した性能を有するサーバ環境を提供する。さらに、本実施例では、仮想マシンホスト２０とベアメタルホスト１０との両方を利用できる環境を提供することで、アプリケーションの性能要件やライフサイクルに適したリソース割り当てを実現することができる。
　ストレージ装置１００は、各インスタンス１１、２１にストレージ資源を提供する機能を有する。ストレージ装置１００は、データ入出力処理に特化したコンピュータシステムであり、ＣＰＵやメモリなどを備える。ストレージ装置１００のＣＰＵは、ストレージ資源の構成を制御するための制御プログラムを稼働させる。この制御プログラムにより、例えばＨＤＤ（ハードディスクドライブ）といった物理的な記憶媒体が、ボリューム１０１と呼ばれる論理的な領域ごとに提供される。記憶媒体としては、ＨＤＤに限らず、例えば、フラッシュメモリデバイス、ＭＲＡＭ（Magnetoresistive Random Access Memory）、相変化メモリ（Phase-Change Memory）、ＲｅＲＡＭ（Resistive random-access memory）、ＦｅＲＡＭ（Ferroelectric Random Access Memory）等を用いてもよい。
　ベアメタルホスト１０の場合、ＯＳ１３によりボリューム１０１がストレージ資源（論理デバイス）として認識される。ボリューム１０１に対して、ＯＳ１３およびアプリケーション１２が必要とするデータの読み書きが行われる。
　仮想マシンホスト２０では、ハイパバイザ２４がボリューム１０１をさらに仮想ディスク１０２と呼ばれる領域に分割する。仮想ディスクは、多くの場合、ファイルシステム上のファイルである。仮想マシン２１上のＯＳ２３には、仮想ディスク１０２内のデータ領域が仮想的なボリューム１０３として認識される。
　ホスト１０、２０とストレージ装置１００とは、ＳＡＮ（Storage Area Network）により接続されている。ＳＡＮの実現例として、ＦＣ＿ＳＡＮがある。ＦＣ＿ＳＡＮは、一つまたは複数のファイバチャネルスイッチ（ＦＣ　ＳＷ）５０、ファイバチャネルケーブル５１、各データ入出力装置を接続するＨＢＡ（ホストバスアダプタ）５２を含んで構成される。
　ＳＡＮの実装例はファイバチャネルに限らず、大容量データ通信という同じ目的を達成できるものであれば、例えばｉＳＣＳＩ（Internet Small Computer System Interface）やＦＣｏＥ（Fibre Channel over Ethernet（登録商標））、Ｉｎｆｉｎｉ－ｂａｎｄといった他の種類のデバイスおよびプロトコルでもよい。
　サービスを提供するホスト１０、２０、サービスを要求するクライアントコンピュータ７０、計算機システムを管理する管理コンピュータ２００は、通信ネットワークを介して相互に接続される。通信ネットワークは、イーサネット（登録商標）スイッチ６０やケーブルにより物理的に結線されており、例えばＴＣＰ／ＩＰといったプロトコルを利用してアプリケーションデータや制御情報を双方向通信する。
　本実施例では、それら通信ネットワークを、サービスネットワーク３００と、管理ネットワーク３０１、３０２とに大別する。サービスネットワーク３００には、サービスクライアント７１がアプリケーション１２、２２と通信するトラフィックが主に流れる。サービスネットワーク３００は、情報処理サービスに必要なデータを送受信する。
　一方、管理ネットワークでは、管理クライアント７２や各管理サーバ２０１、２０３、２０４、２９５が各装置１０、２０、５０、１００内の制御コンポーネントと通信するトラフィックが主に流れる。管理ネットワークは、各情報処理装置１０、２０、５０、１００の構成を管理する制御データを送受信する。
　これらの通信ネットワークは、物理的に分離されても良いし、レイヤ３スイッチの設定やレイヤ２スイッチの設定（ＶＬＡＮ、仮想ローカルエリアネットワーク）などの論理的なネットワーク分割によって構成されてもよい。さらに、管理ネットワーク３０２上には、主にアプリケーション管理サーバ２０１と各ホスト１０、２０との間の通信を制御するための、ファイヤウォール３０３を有する。
　ファイヤウォール３０３は、ネットワーク管理部２０４からの要求に応じ、例えば特定のアプリケーション管理サーバ２０１から特定のホストへの接続を許可したり、あるいは遮断したりする機能を有する。ファイアウォール３０３は、ＩＰアドレスやホスト名などを用いて、通信の接続または遮断を実行する。
　クライアントコンピュータ７０は、物理的には各ホスト１０、２０と同様に、ＣＰＵやメモリ、不揮発性記憶デバイスといった一般的なコンピュータアーキテクチャに基づき構成されている。クライアントコンピュータ７０は、サービスクライアント７１と、管理クライアント７２を有する。サービスクライアント７１は、ホスト１０、２０上のアプリケーション１２、２２から情報処理サービスの提供を受けるソフトウェアである。管理クライアント７２は、管理コンピュータ２００に接続して、計算機システムの構成を管理するソフトウェアである。
　クライアントコンピュータ７０上の各ソフトウェア７１、７２は、必ずしも専用プログラムである必要はなく、同じ目的を達成する機能を有していれば、例えばＷｅｂブラウザのような汎用的なプログラムであってもよい。サービスクライアント７１は、アプリケーションごとに用意してもよいし、複数のアプリケーションを一つのサービスクライアント７１で管理できる構成でもよい。同様に、管理クライアント７２も管理対象の装置ごとに用意してもよいし、複数の対象装置を管理できる構成でもよい。
　管理コンピュータ２００は、クライアントコンピュータ７０から送信されるユーザ要求に応じて、計算機システムの構成を変更する。管理コンピュータ２００は、他の計算機と同様に一般的なコンピュータアーキテクチャを有し、各機能を実現するために必要な管理プログラムを内部に稼動させる。
　本実施例における管理プログラムとは、例えば、アプリケーション管理サーバ２０１、統合リソース管理部２０２、サーバ管理部２０３、ネットワーク管理部２０４、ストレージ管理部２０５である。それぞれの管理プログラムは、機能ごとに細分化されてもよいし、複数プログラムが一つにまとめて構成されてもよい。複数の管理コンピュータ２００が連携することで、これら管理プログラムを動作させる構成でもよい。管理プログラムの少なくとも一部は、管理対象の一部に分散して配置されてもよい。配置先としては、例えば、ホスト１０やＦＣ　ＳＷ５０上の、エージェントプログラムなどがある。
　実際には、管理者がこれら管理プログラムを使用している。各管理者が管轄する装置の範囲や職責により、複数の管理プログラムを用意したり、アカウント認証により管理プログラムの各機能に対するアクセス制御を設けたりする。
　アプリケーション管理サーバ２０１は、インスタンス１１、２１上のアプリケーション１２、２２を管理する機能を提供する。一般に、アプリケーション１２、２１は、アプリケーション自身が処理するのに適した独自のデータ構造、機能、処理フローを持つ。したがって、アプリケーション１２、２２を管理するためには、専用のアプリケーション管理サーバ２０１が必要となる場合がある。
　広く普及しているアプリケーションであれば、そのアプリケーションを管理するアプリケーション管理者は、独自の管理方法や、アプリケーション管理サーバの操作に習熟している。そこで、アプリケーション管理とリソース構成管理とを連携させることで、アプリケーション管理者はノウハウを活かせる、という大きな利便性が得られる。
　性能要件の要求などのようにリソース構成に対する要求が発生するアプリケーションについては、アプリケーション管理サーバが、一部のリソース構成を管理する機能を有してもよい。したがって、本実施例では、アプリケーション管理サーバ２０１と統合リソース管理部２０２とは、互いに制御情報を送受信して、管理対象の構成を変更できる構成としている。アプリケーション管理サーバ２０１と統合リソース管理部２０２の連携を実現するために、例えばアプリケーション管理サーバ２０１にプラグインを設けたり、統合リソース管理部２０２にＡＰＩ（Application Programmable Interface）を設けたりする。
　アプリケーション管理サーバ２０１は、特定の物理装置を管理対象に指定し、その特定の物理装置の構成を変更する権限を他のアプリケーション管理サーバとは排他的に有することもできる。
　物理ホスト上に展開されているという点で、ハイパバイザ２４も一つのアプリケーションであると考えることができる。したがって、ハイパバイザ２４を管理するためのハイパバイザ管理サーバを設ける構成としてもよい。
　管理コンピュータ２００が管理する各装置１０、２０、５０、６０、１００のリソース構成は、統合リソース管理部２０２および各装置管理部により管理される。各装置管理部とは、サーバ管理部２０３、ネットワーク管理部２０４、ストレージ管理部２０５のことである。各装置管理部は、管理ネットワーク３０２を経由して、ホスト１０、２０などの物理サーバ装置と、ＦＣ　ＳＷ５０やイーサＳＷ６０などのネットワークスイッチと、ストレージ装置１００との、構成を管理する。
　より具体的に言えば、各装置管理部は、それぞれの管理対象となる装置上で稼動する論理的なリソースの構成を変更したり、そのリソースの稼働情報を取得したり蓄積したり、あるいは各属性値を設定したりする機能を有する。
　各装置管理部は、装置を開発または製造するベンダから提供される専用の管理プログラムであってもよい。各装置管理部と統合リソース管理部２０２とは、例えばＡＰＩなどの管理インタフェースを利用して制御情報を送受信する。
　統合リソース管理部２０２は、管理クライアント７２の要求に応じて、各装置管理部を制御する。統合リソース管理部２０２は、各装置管理部を通じて、インスタンスを作成したり、構成変更に必要となる装置構成を変更したりする。統合リソース管理部２０２の具体的な構成については、後述する。
　＜テナントにおけるリソースの管理方法＞
　サーバ仮想化技術やストレージ仮想化技術が発展した結果、多数の情報処理システムが、一か所のハードウェアに集約されるようになった。これに伴い、従来は、例えば部署ごとにハードウェアを個別に所有するという運用形態であったが、近年では、複数の部署で同じハードウェアを共有する運用形態に変わりつつある。
　しかし、部署ごとにシステム環境を分けたいという要求は根強いため、リソースを論理的に区分けするための「テナント」と呼ばれる論理構成が設けられている。テナントは「リソース区画」の一例である。テナントには、例えば、そのテナントに属するユーザやユーザグループ、そのテナントを管理する管理者権限の定義、そのテナントで使用可能なリソースなどの、各構成情報が関連付けられている。リソース区画であるテナントを導入することにより、複数のユーザグループ間でセキュリティおよび処理性能上の独立性を保ちながら、ハードウェアや物理的なデータセンタを共有することができ、リソース全体の利用率を高めることができる。テナントは、例えば、リソースを共用するユーザをグループ化したものである。
　各管理プログラムは、複数存在してよいことは前述した。特に複数のテナントを提供する環境では、テナントごとにアプリケーション管理サーバ２０１を用意する。アプリケーション管理サーバ２０１が管理する情報処理システムが、多くの顧客データや業務データなどの機密情報を保持しているためである。
　企業セキュリティの観点からは、これらの機密情報を複数のテナントで共有することは許されない。その一方、アプリケーションの中には、扱うデータの意味により、処理方法や管理方法、リソース構成を変えるものが多く存在する。したがって、アプリケーション管理サーバ２０１をテナントごとに独立させて構築したほうが扱い易い。アプリケーション管理サーバ２０１は、アプリケーション管理サーバ２０１自身の管理する物理リソースを特定し、他の種類のアプリケーション管理サーバとは排他的に、それらの物理リソースを利用することができる。
　ところで、テナントが有する構成管理情報の中の一つに、リソース量が挙げられる。各ユーザに課される利用料は、ユーザの使用するリソース量に基づいて計算される従量課金である。
　仮想化技術により、計算機システムの保持する物理リソース量は、必ずしもユーザが契約可能な量（仮想リソース量）とは一致しない。各ユーザの契約可能なリソース量の合計値は、実際の物理リソース量よりも多くできる。
　しかし、ユーザのリソース需要と全くの無関係に、物理リソースの購入頻度や購入台数を決定することはできない。さらには、ユーザが属するグループや使用するアプリケーションによって、需要傾向はまちまちであり、それらを無視してリソースの供給量を予測することは不可能である。
　したがって、最も簡潔で一般的なやり方は、契約するユーザのグループ、すなわちテナントごとに使用する物理リソースをある程度、決めておくやり方である。ただし、仮想化技術を用いることで、複数のテナントが一つの物理リソース（装置）を共有する構成を許容して、リソースの利用率を高める。このような、あるテナントの利用可能なリソースの範囲を、リソースプールと呼ぶことにする。
　図２に示す比較例を参照し、リソースプールを用いてテナントにおけるリソースを管理する例を説明する。　
　ユーザ３０１は、所望のアプリケーションを利用するために、インスタンス１１（または２１）を作成する。インスタンスを稼働させるために必要な物理リソースは、事前にリソースプール３０３で管理されている。
　リソースプール３０３は、装置管理者が管理コンピュータ２００上の各装置管理部を利用して設定される。装置管理者とは、例えばサーバ管理者３０５ａ、ネットワーク管理者３０５ｂ、ストレージ管理者３０５ｃである。各装置管理部とは、例えばサーバ管理部２０３、ネットワーク管理部２０４、ストレージ管理部２０５である。
　リソースプール３０３には、ホスト１０（または２０）や、隔離ネットワーク３０４、ボリューム１０１など、インスタンスを構成するために必要なリソースの組み合わせが各装置管理部により予め登録されている。
　ユーザ３０１によるインスタンスの作成やリソース構成変更といった各種管理操作は、管理クライアント７２との交信により行われ、ユーザ３０１のセルフサービスにより完結する。ユーザ３０１は、導入予定のアプリケーションの要求する要件をアプリケーション管理サーバ２０１ａ、２０１ｂに事前に問合せ、各種管理操作の際に要件を指定してもよい。
　管理クライアント７２は、少なくともインスタンスの構成管理に関わる操作について、各構成管理コンポーネントに要求する機能を有する。アプリケーション管理サーバ２０１ａ、２０１ｂは、リソースプール３０３に登録されているリソースの中から、それぞれのアプリケーションに専用の領域として管理するものを事前に設定しておく。これにより、アプリケーション管理サーバ２０１ａ、２０１ｂは、物理リソースの詳細な構成や稼働情報を蓄積し、より効率的にアプリケーションを管理できる。以下、特に区別しない場合、アプリケーション管理サーバ２０１ａ、２０１ｂをアプリケーション管理サーバ２０１と呼ぶ。
　テナント３００内にインスタンス１１（あるいは２１）が用意されると、ユーザ３０１は、所望のインスタンスをアプリケーション管理サーバ２０１に連絡し、所望のインスタンスの内部に所望のアプリケーションを構築する。
　必要であれば、インスタンスを作成する際や、アプリケーションを構築する際に、ユーザ３０１は、アプリケーション管理者３０６と連携してリソース構成の詳細を検討したり、アプリケーション管理者３０６に設計を依頼してもよい。さらに、アプリケーション管理サーバ２０１が、インスタンスの稼働している物理装置を管理できるように、アプリケーションを構築するインスタンスをアプリケーション管理サーバ２０１が新たに作成したり、あるいは、アプリケーション管理サーバ２０１がインスタンスを専用の物理装置上に移行する処理を行ったりしてもよい。
　以上の例では、テナント３００ごとに専用のアプリケーション管理サーバ２０１を設け、リソースプール３０３内に配備された物理リソースを利用してインスタンス１１（または２１）を作成する。
　各アプリケーション管理サーバ２０１は、特定のリソース（ホスト、ネットワーク、ボリュームなど）を占有する。アプリケーション管理サーバ２０１は、自身の管理対象であるアプリケーションを、他のアプリケーション管理サーバと排他的に管理する。
　例えば、仮想マシンホスト２０から構成されるテナントでは、インスタンス２１の性能負荷に応じてアプリケーションを仮想マシンホスト間で移行したり、リソースプール３０３にリソースを追加または削除したりすることで、アプリケーション（業務）を停止することなく負荷の平準化とリソース利用率の向上を実現できるであろう。
　しかし、図２の比較例に示す構成におけるリソース利用率の向上は、同一のテナント内部に留まらざるを得ない。また、図２の比較例では、セキュリティ確保の観点から、複数のテナント間でアプリケーション管理サーバを共有することも困難である。
　そこで、本実施例のリソース管理システムでは、以下に述べるように、アプリケーション管理とリソース管理とを連携させることで、データセンタ全体のリソース利用率を最適化する。具体的には、本実施例では、アプリケーション要件や稼働情報をもとに、テナントに割り当てるリソースプールを動的に構成する。
　図３は、本実施例によるリソース管理システムおよびリソース管理方法の概要を示す説明図である。本実施例に特徴的な概念の一つは、対応づけられるリソースの一部を管理し仮想リソースとして提供するコンテナ３１０である。コンテナ３１０は、図２の比較例においてアプリケーション管理サーバ２０１に対して登録された、物理リソース（物理装置）に相当する構成要素である。コンテナ３１０は、実際の物理ハードウェア構成を仮想化する役割を持つ。なお、以下の説明では、特に区別しない場合、符号に添えるアルファベットを無視して表記する。例えば、テナント３００ａ、３００ｂをテナント３００と、リソースプール３０３ａ、３０３ｂをリソースプール３０３と、アプリケーション管理サーバ２０１ａ、２０１ｂをアプリケーション管理サーバ２０１と、表記する場合がある。
　テナント３００内では、コンテナ３１０をアプリケーションごとのリソースプールとして利用する。各テナントでは、テナントごとの契約リソース量等のリソース情報を管理している。
　統合リソース管理部２０２は、全ての物理的なリソースを予めコンテナ３１０として構成しておき、各アプリケーション管理サーバ２０１へ管理対象として登録しておく。後述の通り、コンテナ３１０が提供することになる仮想的なリソース構成と、コンテナに登録される物理リソース構成とを一致させる必要はない。したがって、物理的なリソースの総量を超えて、コンテナ３１０のリソース量を定義することができる。
　コンテナ３１０に対応付けられる「リソース」としての物理リソースには、例えば、サーバ（計算リソース）、ネットワーク（通信リソース）、ストレージリソースなどがある。コンテナ３１０は、これら物理リソースの組み合わせにより構成されており、アプリケーション管理サーバ２０１の管理対象として登録可能である。
　サーバリソース３１１ａの種類としては、例えばベアメタルホスト１０、仮想マシンホスト２０、論理パーティションホストなどを単体で使用する場合、複数のサーバを組み合わせて構成されるサーバクラスタを使用する場合がある。論理パーティション（ＬＰＡＲ）ホストとは、ＣＰＵやネットワークアダプタなどの各コンポーネントを論理的に分割したサーバリソースである。サーバクラスタとしては、例えば、冗長化された仮想マシンホスト２０、冗長化されたベアメタルホスト１０、あるいは、複数サーバのバスを結合してＳＭＰ（対称型マルチプロセッシング）構成としたサーバ群がある。
　ネットワークリソース３１１ｂとは、レイヤ２またはレイヤ３で制御される例えば仮想ＬＡＮや、サブネット、仮想プライベートネットワークなどのように、ホスト間で通信可能な範囲（隔離ネットワーク）である。あるいは、ネットワークリソース３１１ｂは、ファイヤウォール、ロードバランサ、ＶＰＮ（Virtual Private Network）ゲートウェイなどの、ネットワーク機能を提供するアプライアンスであっても良い。
　ストレージリソース３１１ｃとは、例えば、ストレージ装置１００が提供するボリューム１０１、ネットワークファイルシステム上のディレクトリである。
　前述のリソース３１１ａ、３１１ｂ、３１１ｃは、データセンタ内に設けられている特定の装置であってもよいし、外部のＩａａＳクラウドから調達したサーバインスタンスやオブジェクトストレージであってもよい。
　コンテナ３１０の構成は、統合リソース管理部２０２により管理される。アプリケーション管理サーバ２０１は、統合リソース管理部２０２へリソースを要求することにより、必要なコンテナ３１０を調達する。
　アプリケーション管理サーバ２０１は、所望のコンテナ３１０を占有して、そのコンテナ３１０を当該アプリケーション専用のリソース領域として利用できる。統合リソース管理部２０２は、物理的にどのリソース３１１をどのコンテナ３１０に割り当てるか、という構成管理を制御する。統合リソース管理部２０２は、アプリケーション管理サーバ２０１に関与されることなく、コンテナ３１０の物理構成を変更することができる。したがって、本実施例によれば、アプリケーションの管理体系に干渉せずに、複数アプリケーション間または複数テナント間で、リソースを融通しあい、リソースの利用率を平準化することができる。
　例えば図３中の矢印３１２ａに示すように、同一のアプリケーション管理サーバ２０１ａで管理されるリソースを、異なるテナントに提供されているコンテナ間で調整することができる。具体的には、アプリケーションＡの管理サーバ２０１ａが管理する第１のコンテナ３１０（１）の有するリソースは、第１のテナント３００ａのリソースプール３０３ａを介してインスタンス１１ａに使用されている。同じアプリケーション管理サーバ２０１ａの管理する第２のコンテナ３１０（２）の有するリソースは、第２のテナント３００ｂのリソースプール３０３ｂを介して２つのインスタンス１１ｂに使用されている。
　複数インスタンス１１ｂにより使用される第２のコンテナ３１０（２）の負荷が増大すると、インスタンス１１ｂを使用するユーザ３０１ｂは、第２のコンテナ３１０（２）へのリソース追加を要求する。このリソース追加要求は、クライアントコンピュータ７０から通信ネットワーク３０１を介して、管理コンピュータ２００に送られる。この要求に従い、同一のアプリケーション管理サーバ２０１ａで管理されている、第１のコンテナ３１０（１）から第２のコンテナ３１０（２）へ、リソースが移行される。説明の理解のために、リソースが減少する第１のコンテナ３１０（１）を移行元コンテナと、リソースが追加される第２のコンテナ３１０（２）を移行先コンテナと、それぞれ呼ぶ場合がある。
　ここで、第１のコンテナ３１０は、例えばリソース利用率が低いなどの、所定の移行元選択条件を満たしているものとする。移行元のコンテナを選択するための条件としては、例えば、リソース利用率が基準値以下であること（または利用率が最も低いこと）、リソース移行先のコンテナを使用するアプリケーションに欠かせない機能を有していること（アプリケーション制約条件を満たすこと）、ボトルネックなどの性能劣化が生じていないこと、がある。これら以外の条件を移行元選択条件に加えてもよいし、上記条件の幾つかを移行元選択条件から外してもよい。
　第１のコンテナ３１０（１）から第２のコンテナ３１０（２）へリソースを移すことにより、第２のコンテナ３１０（２）の処理能力が増大し、負荷が軽減する。
　図３には、異なるアプリケーション間でリソースを調整する例（３１２ｂ）も示されている。図示の例では、アプリケーションＢの管理サーバ２０１ｂの管理する第３のコンテナ３１０（３）は、第１のテナント３００ａのリソースプール３０３ａを介して、インスタンス１１ａに使用されている。なお、アプリケーション管理サーバ２０１ｂは、もう一つのコンテナ３１０も管理しているが、そのコンテナ３１０は使用されていない。
　例えばユーザ３０１ａが、第３のコンテナ３１０（３）を使用するインスタンス１１ａの応答性能の改善を希望する場合、第３のコンテナ３１０（３）へのリソース追加を管理コンピュータ２００に要求する。この要求に従い、第１のコンテナ３１０（１）に仮想的に割り当てられているリソースの一部が、第３のコンテナ３１０（３）に移る。上記同様に、第１のコンテナ３１０（１）は所定の移行元選択条件を満たすために、リソースの移行元コンテナとして選択されたとする。
　統合リソース管理部２０２が作成して管理するコンテナ３１０により、アプリケーション管理サーバ２０１へ提示するリソースを仮想化することができる。したがって、例えば記憶媒体の追加または削除などの、コンテナ３１０に割り当てられる物理的な装置構成に変更があった場合でも、アプリケーション管理サーバ２０１は物理的装置構成の変更に全く関知しない。アプリケーション管理サーバ２０１は、物理的装置構成の変更と無関係に、アプリケーションを管理することができる。
　図４は、管理コンピュータ２００に設けられ、本実施例に特徴的な機能を実現するための管理コンポーネント群を示す。前述の通り、統合リソース管理部２０２は、リソース利用率に応じて、コンテナ間でリソースを配分する機能を提供する。
　ユーザ要求管理部２１０は、ユーザ要求を管理する機能である。ユーザ要求管理部２１０は、ユーザのインスタンス作成要求などの構成変更要求を管理クライアント７２から受信する。ユーザ要求管理部２１０は、統合リソース管理部２０２が構成変更した結果を管理クライアント７２に返信する。ユーザ要求管理部２１０は、管理クライアント７２から複数の要求を受け付けた場合、実行順序や進捗状況などを制御する。
　統合リソース管理部２０２は、インスタンス管理テーブル２１１やテナント管理テーブル２１２を用いて、ユーザやアプリケーション管理サーバ２０１に提供する構成情報を保持する。テナント３００あるいはアプリケーション管理サーバ２０１に提供される仮想的なリソース構成は、コンテナ３１０ごとに管理され、コンテナ管理テーブル２１５に保持される。
　リソース構成管理部２１３は、リソース構成を管理する機能であり、アプリケーション管理サーバ２０１と連携して動作する。リソース構成管理部２１３は、リソース稼働情報データベース２１６に保持されている稼働情報を参照しながら、コンテナ３１０と物理装置（リソース）との関連付けを制御する。
　リソース構成管理部２１３は、予め設定された管理方法に従って、各リソースの稼働情報を処理し、処理結果を性能評価テーブル２１４に格納する。具体的には、リソース構成管理部２１３は、アプリケーションの要求するリソース要件（性能要件）に基づいて、リソースの稼働情報を評価したり加工したりし、その結果を性能評価テーブル２１４に記憶する。
　統合リソース管理部２０２は、管理対象の各装置１０、２０、５０、１００の構成に対する制御命令を、各装置管理部２０３、２０４、２０５に送信する。
　装置管理部２０３、２０４、２０５は、管理対象の各装置から利用率および実性能を取得し、リソース稼働情報データベース２１６に格納する。リソース稼働情報データベース２１６は、コンテナ管理テーブル２１５に保持される装置識別子や時期をキーにして、構成要素毎に稼働情報の履歴を提供する機能を有する。
　アプリケーション管理サーバ２０１の機能構成を説明する。アプリケーション管理サーバ２０１は、例えば、リソース管理部２０６、リソース要件定義テーブル２０７、アプリケーション稼働情報データベース２０８を備える。
　リソース管理部２０６は、アプリケーションが利用している対象リソースの構成を管理するために、統合リソース管理部２０２に構成変更を要求する。アプリケーション管理サーバ２０１は、アプリケーションに適した要件を定めており、この要件をリソース要件定義テーブル２０７に保持している。リソース要件は、アプリケーションの種類に応じて異なるため、リソース要件を管理するリソース要件定義テーブル２０７の形式も一定ではなく、アプリケーションごとに異なる可能性がある。
　アプリケーション稼働情報データベース２０８は、アプリケーションの設定値や性能値などの稼働情報を保持する。アプリケーションの稼働情報とは、例えば、計算リソース、サービスクライアント７１との間に確立されたコネクション、そのコネクションの利用状況などである。計算リソースとは、例えば、当該アプリケーションが利用するプロセス、スレッド、メモリ空間などである。コネクションの利用状況とは、例えば、応答時間、トランザクション数などである。これらの稼働情報は、各アプリケーションの設計に基づき、独自の名称や属性などのデータ構造を有する。
　図５は、インスタンスごとに管理される設定値や属性を格納するためのインスタンス管理テーブル２１１を示す。ユーザには、インスタンス管理テーブル２１１に記載の情報がクライアントコンピュータ７０を介して提供される。つまり、ユーザには、インスタンスに割り当てられている物理的装置の識別情報は抽象化されて提供される。ユーザは、自分が利用するインスタンス１１に実際に割り当てられている物理リソースがどれなのか知る必要は必ずしもない。
　インスタンス管理テーブル２１１は、例えば、インスタンスの識別子２１１ａ、インスタンスの所有者２１１ｂ、所属しているリソースプール２１１ｃ、コンテナ２１１ｄ、リソース構成２１１ｅ、ネットワークポリシ２１１ｆ、グレード２１１ｇ、消費ポイント２１１ｈ、利用期限２１１ｊ、（必要であれば）アプリケーション管理サーバ識別名２１１ｋを対応付けて保持する。
　前述の通り、インスタンス１１とは、それぞれゲストＯＳを有する論理的な計算機を表現している。インスタンス１１は物理装置から抽象化されているという意味で、テーブル２１１には、仮想的なリソース構成２１１ｅが定義されている。
　インスタンス識別子２１１ａは、インスタンス１１を一意に識別する情報である。所有者２１１ｂは、インスタンス１１を使用するユーザを一意に識別する情報である。リソースプール２１１ｃは、インスタンス１１が使用するコンテナ３１０の所属しているリソースプール３０３を一意に識別する情報である。コンテナ２１１ｄは、インスタンス１１にリソースを提供するコンテナ３１０を一意に識別する情報である。
　リソース構成２１１ｅは、一般的なコンピュータアーキテクチャと同じくＣＰＵやメモリなどの構成要素からなる。リソース構成２１１ｅの内容は、ユーザの要求に応じて個別に設定することもできる。ユーザ要求管理部２１０に保持されるカタログテンプレートとして、リソース構成２１１ｅの雛形データを用意してもよい。ただし、同じコンテナ識別子２１１ｄを有するインスタンスのリソース構成２１１ｅの総計が、コンテナ３１０が提供するリソース容量を超えないように設定される。前述の通り、コンテナ３１０は仮想的なリソース構成を定義したものであるから、リソース構成２１１ｅはコンテナ３１０へ対応付けられた物理的な装置のリソース構成とは必ずしも一致しない。
　ネットワークポリシ２１１ｆは、インスタンス間の通信や、公衆通信網上の他のホストとの通信に関して、使用するプロトコルや、通信の許可または不許可を設定する。グレード２１１ｇは、インスタンスに割り当てられるリソース性能に対して、サービスレベルを設定する。
　インスタンス１１には、例えばデータセンタ事業者とユーザとの間の契約に基づき、契約情報を関連付けることができる。契約情報としては、例えば、利用料を定めるための消費ポイント２１１ｈや、有効な契約の残り期間を示す利用期限２１１ｊなどがある。契約の主体や形態に応じて、ライセンスに関する情報や、ユーザ申請の識別情報などもテーブル２１１で管理してもよい。
　必要であれば、ユーザは、アプリケーション管理サーバ２１１ｋやアプリケーション管理者へ、ユーザのインスタンスが利用しているコンテナの識別子２１１ｄを通知することで、所望のアプリケーションをインスタンスに導入し、運用することができる。
　図６は、テナントを管理するためのテナント管理テーブル２１２を示す。テナント管理テーブル２１２は、テナントごとに管理される設定値や属性を格納する。テナント管理テーブル２１２には、例えば、テナントＩＤ２１２ａ、ユーザグループＩＤ２１２ｂ、管理ロール定義２１２ｃ、リソースプールＩＤ２１２ｄ、インスタンス管理テーブルＩＤ２１２ｅ、残り利用可能ポイント２１２ｆを対応付けて保持する。
　テナントＩＤ２１２ａは、テナント３００を一意に識別する情報である。ユーザグループＩＤ２１２ｂは、ユーザグループを一意に識別する情報である。管理ロール定義２１２ｃは、ユーザの役割と管理権限とを定義する情報を特定するための情報である。リソースプールＩＤ２１２ｄは、テナントに設けられたリソースプール３０３を一意に識別する情報である。インスタンス管理テーブルＩＤ２１２ｅは、テナントで稼働するインスタンスを管理するためのインスタンス管理テーブル２１１を一意に識別する情報である。
　テナントではセキュリティが確保されており、インスタンス管理テーブル２１１で述べたネットワークポリシ２１１ｆのような形式で、リソース構成情報に対するアクセス可否を管理できる。残り利用可能ポイント２１２ｆは、利用可能な契約リソースの利用料を表す情報である。
　図７は、コンテナを管理するコンテナ管理テーブル２１５を示す。コンテナ管理テーブル２１５は、コンテナごとに管理される設定値や属性を格納する。コンテナ管理テーブル２１５は、アプリケーション管理サーバ２０１に通知される、コンテナ情報および物理装置（リソース）の対応付けを管理する。
　コンテナ管理テーブル２１５において、アプリケーション管理サーバ２０１には、構成変更に必要な、コンテナＩＤ２１５ａとアクセス権限２１５ｂが引き渡される。アプリケーション管理サーバ２０１には、物理装置構成などに関する情報２１５ｃ～２１５ｋは公開されない。
　コンテナＩＤ２１５ａは、コンテナを一意に識別する情報である。アクセス権限２１５ｂは、コンテナにアクセスして、論理的なリソース構成を管理するためのアクセス権限情報を一意に識別する情報である。アプリケーション管理サーバ２１５ｃは、コンテナを利用するアプリケーションを管理しているアプリケーション管理サーバ２０１を一意に識別する情報である。
　コンテナ管理テーブル２１５には、コンテナ３１０の内容として、例えば、サーバ２１５ｄ、ネットワーク２１５e、ストレージ２１５ｇの組み合わせが保持される。これらコンテナ３１０を構成するリソースの総量は、仮想リソース容量２１５ｊおよび実リソース容量ｋに保持される。仮想リソース容量２１５ｊおよび実リソース容量ｋは、いずれも統合リソース管理部２０２により管理される量である。ただし、実リソース容量２１５ｋが一つのコンテナとして管理される装置が物理的に有しているリソース容量の総和に等しい一方、仮想リソース容量２１５ｊはアプリケーション管理サーバ２０１へ提供される仮想的なリソース容量である。統合リソース管理部２０２の働きにより、両者は一致しないことがある。
　インスタンス種別２１５ｆは、コンテナ上で稼働するインスタンスの種別を示す。インスタンス種別２１５ｆにより、構成の管理方法や装置管理部を管理できる。インスタンス種別２１５ｆには、例えばコンテナが仮想マシンホスト２０であれば“ＶＭ”が、ベアメタルホスト１０であれば“ＰＭ”が設定される。
　アプリケーション管理サーバ２０１は、アクセス権限２１５ｂで特定されるアクセス権限情報を利用しなければ、コンテナＩＤ２１５ａで特定されるコンテナ３１０を管理対象とすることができない。ただし、コンテナの構成によっては、特定のアプリケーションのみが利用可能な場合がある。特有の構成を備えるコンテナを利用可能なアプリケーションを識別する情報は、アプリケーション制約２１５ｈに設定される。
　特定のアプリケーションのみ利用可能な例としては、例えば、アプリケーション開発元において認証済みのハードウェアのみ動作を保証する場合、アプリケーションを動作させるために所定のハードウェア機能が必要な場合、特定バージョンのファームウェア構成でのみ動作が保証されている場合などがある。
　アプリケーション制約フィールド２１５ｈは、管理者またはアプリケーション管理サーバ２０１により手動または自動で設定され、コンテナＩＤ２１５ａで特定されるコンテナの構成に変更が生じた場合、その値が更新される。
　＜リソースプールの構成改善方法＞
　本実施例では、コンテナ３１０という特徴的な構成を導入することで、物理的な装置構成と、アプリケーション管理サーバ２０１やテナント３００に認識させる論理的な装置構成とを分離することができる。
　本実施例では、異種アプリケーション間あるいは異なるテナント間で、コンテナに編入する物理的な装置を融通したり、コンテナ全体を入れ替えたりすることができる。これにより、本実施例では、既存のアプリケーション管理体系やテナント管理体系に影響することなく、業務システム（アプリケーション）に割り当てるリソース構成を使用状況に応じて動的に変更することができる。
　コンテナへのリソース割り当てを、異なる複数種類のアプリケーション要件（アプリケーションがリソースに要求する条件）に基づいて実施することで、データセンタ全体のリソース利用率を高めることができる。そこで、異なる種類でのアプリケーション要件を統一された観点で評価し、調整することが重要となる。
　図８は、アプリケーション要件を考慮して性能を評価する方法の概念を示す。図８は説明のため２次元平面図としたが、考慮する性能指標の数に応じた任意の正数Ｎ次元で評価する場合も同じである。
　図８（ａ）は、ある性能指標（例えばＣＰＵ利用率およびディスクＩＯＰＳ）における各コンテナ３１０ａ～３１０ｄの分布を表す。図８（ａ）では、リソース管理者が定義する目標性能値の範囲を点線３２１で示している。
　一つの考え方として、例えば物理装置（リソース）そのものが有する性能に基づく目標性能値の範囲３２１を用いてサービスレベルを定義し、グレードとしてユーザに提示する方法がある。
　各コンテナ上で稼働するアプリケーションごとの要件（リソース要求）を考慮しない場合、図８（ａ）のように、物理装置の性能指標をそのまま採用して評価するより他に方法はない。この場合、原点からの距離により、各コンテナの利用状況を評価する。例えばコンテナ３１０ｃはリソース利用率が比較的低く、コンテナ３１０ｂはリソース利用率が高い、と分析できる。コンテナ３１０ａ、３１０ｂについては、利用傾向が偏っていると判断される。
　しかし、コンテナ上で稼働するアプリケーションの種類により、必要となるリソースの種別は異なるのが自然である。したがって、アプリケーションの種類を考慮せずに、性能指標を均一に評価する方法は適切ではない。つまり、アプリケーション管理サーバ２０１が定義するリソース要件や、アプリケーション管理のためのノウハウを考慮することができれば、コンテナでのリソースの需要傾向に基づいてリソース利用率を公平に判定することができる。
　図８（ｂ）は、アプリケーションごとに異なるリソースの利用特性を考慮した、性能評価の方法を示す。
　例えば、図８（ａ）に記載の各コンテナ３１０ａ～３１０ｄにおいて、コンテナ３１０ｃおよび３１０ｄでアプリケーションＡを稼働させ、コンテナ３１０ａおよび３１０ｂでアプリケーションＢを稼働させるとする。
　アプリケーションＡのリソース利用傾向を性能特性曲線３２２として示す。アプリケーションＡの性能特性曲線３２２と、アプリケーションＡが稼働するコンテナ３１０ｃ、３１０ｄの性能値とを重ね合わせると、コンテナ３１０ｃはアプリケーションＡに適したリソース利用率であることがわかる。しかし、コンテナ３１０ｄはアプリケーションＡに適していないことが判明する。
　コンテナ３１０ｄがアプリケーションＡの性能傾向に適していない理由としては、コンテナ３１０ｄに対応付けられている他のリソース要素（例えばネットワーク性能など）にボトルネックが存在している場合や、コンテナ３１０ｄに割り当てられるべきＣＰＵリソース量が多すぎる場合、のいずれか又は両方であると推定される。
　アプリケーションＢについても同様の分析が可能である。アプリケーションＢのリソース利用傾向を示す性能特性曲線３２３と、アプリケーションＢが稼働するコンテナ３１０ａ、３１０ｂの性能値とを重ね合わせて判断する。コンテナ３１０ａは、アプリケーションＢの性能傾向に適していないことがわかる。
　図８（ｂ）に示す場合は、例えばコンテナ３１０ａと３１０ｄをアプリケーションＡとアプリケーションＢとの間で交換したり、あるいは、コンテナ３１０ａのリソース構成をコンテナ３１０ｄのリソース構成と近くなるよう変更したりする、といった改善方策が考えられる。
　本実施例では、少なくとも３つの技術的特徴を備えているため、アプリケーションの特性を考慮して、データセンタ全体のリソース利用率を最大化することができる。第１の技術的特徴は、アプリケーション管理サーバ２０１が対象とするリソース構成と、物理装置の構成とを分離する「コンテナ」の概念である。第２の技術的特徴は、異種アプリケーションのリソース要件を統一的に比較するための表現形式である。これについては、後述する。第３の技術的特徴は、複数コンテナ間で物理装置（リソース）を融通する構成管理方法である。
　前述の通り、アプリケーション管理サーバ２０１が必要とするリソース構成に関連する情報は、リソース要件定義テーブル２０７に保持される。これらリソース要件に関する情報は、アプリケーションごとに一定ではなく、アプリケーション管理サーバ２０１が保持するリソース要件の表現形式もそれぞれに異なる。
　図９は、リソース要件を定義するリソース要件定義テーブル２０７の例を示す。例えば、図９（ａ）に示すリソース要件定義テーブル２０７は、ターゲット２０７ａ、リソース項目２０７ｂ、要求値２０７ｃ、稼働状況２０７ｄ、評価値２０７ｅを対応付けて管理している。ターゲット２０７ａは、アプリケーションの使用対象となるコンテナ３１０を一意に識別する情報である。リソース項目２０７ｂは、対象コンテナ２０７ａに対応付けられるリソースの項目を示す情報である。要求値２０７ｃは、アプリケーションがリソースに要求する条件である。稼働状況２０７ｄは、リソース項目２０７ｂで示す性能指標の実測値である。評価値２０７ｅは、稼働状況２０７ｄの値が要求値２０７ｃを満たしているか否かを判定した情報である。
　図９（ｂ）に、他の形式のリソース要件定義テーブル２０７（１）を示す。このテーブル２０７（１）では、ターゲット２０７ｆと、評価値２０７ｇとを対応付けて管理し、他の項目（リソース項目、要求値、稼働状況）は管理していない。
　図９（ａ）に示すように、特定の構成要素（リソース）に対して性能要件（２０７ｂ）が定義されている場合もあれば、図９（ｂ）に示すように、アプリケーションの応答性能や処理スレッド数などの、リソース要件に直接的に関連付けられない性能値を用いて性能要件が定義されている場合もある。
　図１０を用いて、アプリケーションがリソースに求めるリソース要件を異種アプリケーション間で統一的に比較するための表現形式を説明する。
　図１０は、全体リソースに対する稼働情報を算出するために、リソース管理部２１３が使用する、本実施例に特有の性能評価テーブル２１４を示す。性能評価テーブル２１４では、アプリケーションの種類ごとに定められるリソース要件に基づき、コンテナＩＤ２１４ａに対して、評価が必要な性能指標２１４ｂと、その実計測値２１４ｃとが保持されている。
　さらに、テーブル２１４では、複数の異種アプリケーションによるリソース要件を共通的に比較評価するため、補正係数２１４ｄを設けている。それぞれの性能指標２１４ｂの実計測値２１４ｃを補正係数２１４ｄで補正し、その補正結果を補正値２１４ｅに記録する。補正値２１４ｅは、実計測値２１４ｂと補正係数２１４ｄとの単純な積として算出しており、無次元の値である。
　性能指標２１４ｂには、リソース利用率の高さを示す指標のみならず、リソース性能の劣化を示す指標が存在する。リソース性能の劣化を示す指標としては、例えばディスクＩ／Ｏの応答時間などのように、性能劣化の大きさが数値の大きさに現れる指標のほか、総合的な性能ボトルネックの判定に使用する指標もある。
　例えば、ＣＰＵ利用率が高い場合は、一見すると計算リソースの利用率が高まっているかのように思われる。しかし実際には、メモリ不足に伴ってスワップ処理が発生しており、スワップ処理の影響がＣＰＵ負荷として現れていることもある。
　そこで、性能評価テーブル２１４では、性能上のボトルネックを考慮し、リソースの利用率向上のために良い影響を与えていれば「＋」を、悪い影響を与えていれば「－」を、保持するための影響判定２１４ｆを有する。
　性能指標２１４ｂとしてどの構成要素（リソース）を選ぶかについては、アプリケーション管理サーバ２０１により自動的に設定されてもよいし、管理者の手によって設定されてもよい。
　補正係数２１４ｄは、複数の異なるアプリケーションに対するコンテナ３１０の性能比較を公平に行うために重要な値であり、各性能指標をどの程度、重要視するかという定量値を与えるための重みという意味を持つ。補正係数２１４ｄを用いることにより、前述したアプリケーションごとのリソース性能特性を表現することができる。
　例えば、コンテナＩＤ：ＣＮＴ－Ａ０２１におけるＣＰＵ利用率（総処理時間に対するＣＰＵ時間の比率）は４５％であるのに対し、コンテナＩＤ：ＣＮＴ－Ａ０２５のＣＰＵ利用率は６９％である。
　この単純な比較では、後者のコンテナＣＮＴ－Ａ０２５のほうが、リソース利用率が高いように思われる。しかし、実は、コンテナＣＮＴ－Ａ０２５上で稼働するアプリケーションは、ＣＰＵに高い演算性能を必要とする。このようなアプリケーションの特性の差を各補正係数２１４ｄにより重みづけして、補正値２１４ｅを得る。実測されたＣＰＵ利用率が４５％のコンテナＣＮＴ－Ａ０２１の補正値は９０となり、実測されたＣＰＵ利用率が６９％のコンテナＣＮＴ－Ａ０２５の補正値は３５となる。このように、アプリケーション間の特性の差を考慮した補正値を算出することで、コンテナＣＮＴ－Ａ０２５ではＣＰＵを利用しきれておらず、見かけ上の数値が低いコンテナＣＮＴ－Ａ０２１のほうが、逆にリソース利用率が高いことを表現することができる。
　補正係数２１４ｄは、各アプリケーション管理者の手により設定されてもよいし、アプリケーション管理サーバ２０１により自動的に設定されてもよい。稼働情報を統計処理することで、リソース構成管理部２１３が補正係数を算出してもよい。
　統計的な稼働情報をもとに補正係数２１４ｄを算出する方法の例を示す。ただし、本実施例にかかる計算機システムにおいて、アプリケーションを稼働させるコンテナについて十分に多数の稼働実績があり、稼働情報の履歴が保持されているものとする。例えば図９（ａ）に示すように各リソース項目について要求値２０７ｃが設定されている場合、これを閾値にして、下記のように計算する。要求値の不等号の向きにより、下限を定める要求値と上限を定める要求値とを判別する。以下の各式では理解のために、一部の変数にテーブル項目の符号を添える。式中の補正係数は、図１０の補正係数２１４ｄのことであるから符号の記載を省略する。
　補正係数＝倍率／下限要求値２０７ｃ，影響判定２１４ｆ＝（＋）・・・式１
　補正係数＝倍率／上限要求値２０７ｃ，影響判定２１４ｆ＝（－）・・・式２
　上記倍率は、性能値ごとにとり得る値を用いて、例えば次式のように算出する。
　倍率＝(アプリケーション倍率)×(履歴最大値－履歴最小値)／定義域・・・式３
　アプリケーション倍率は、アプリケーションの重要度や人気の度合いを表し、アプリケーションの導入数（インスタンス台数）に基づいて評価する。あるいは、図９（ｂ）のように、あるインスタンスまたはコンテナに対して、アプリケーション独自の評価値２０７ｇを有する場合には、次式から評価値２０７ｇを算出する。
　[全性能指標２１４ｂの総和](補正係数×性能履歴の平均値)＝評価値・・・式４
　このとき、同一のアプリケーション内で保持されるリソース要件定義テーブル２０７のレコード数を次数とする連立方程式が成立する。各性能指標２１４ｂが互いに独立であればその連立方程式は解を持ち、補正係数２１４ｄが決定される。各性能指標２１４ｂの一組以上が従属である場合には、最小二乗法等で求めた近似解を補正係数２１４ｄとしてもよい。
　図１１は、アプリケーションの要求するリソース要件に基づいて各コンテナの稼働情報を補正し、リソース全体における稼働情報を算出し、リソースを融通するコンテナを決定するための処理のフローチャートである。
　リソース構成管理部２１３が、例えばアプリケーション管理サーバ２０１からリソースの追加要求を受信すると（Ｓ１０）、その受信を契機に以降の処理が開始される。リソースの追加要求には、アプリケーション１２（または２２）の種別を含む。さらに追加されるべきリソース量を含む場合もある。コンテナ３１０の構成を変更することによりリソース配分を変更する一連の処理を開始する所定の契機としては、前述のリソースの追加要求の受信に限らない。例えば、システム管理者が明示的に指示した場合に本処理を開始してもよい。統合リソース管理部２０２が本処理を定期的に実行してもよい。ユーザ要求管理部２１０が、インスタンスの構成変更についての要求を受信した場合に、インスタンス管理テーブル２１１からアプリケーション管理サーバ２１１ｋを特定し本処理を実行してもよい。
　また、どの種別のリソース（サーバ、ネットワーク、ストレージ）の追加であるかを判別する方法にも複数ある。例えば、ユーザが、必要なリソースの種別を明示して、リソース追加要求を指示してもよい。リソース利用率の履歴をもとに自動計算することで、追加の必要なリソースの種別と量を自動的に特定する構成でもよい。
　後者の自動計算には、アプリケーション管理サーバ２０１が有するリソース要求定義テーブル２０７やアプリケーション稼働情報テーブル２０８を利用して、リソースの消費傾向を算出し、消費傾向の大きいリソースを追加対象として決定する方法がある。統合リソース管理部２０２が有する性能評価テーブル２１４のうち、補正係数２１４ｄの値が大きいリソースを、追加すべきリソースであるとして決定する方法も考えられる。
　ステップＳ１１において、統合リソース管理部２０２は、アプリケーション管理サーバ２０１に定義されたリソース要件に変更があったか否かを判定する。具体的には、リソース構成管理部２１３が、アプリケーション管理サーバ２０１上のリソース管理部２０６を経由してリソース要件定義テーブル２０７を参照し、更新の有無を判定する。判定の結果、更新があった場合（Ｓ１１：ＹＥＳ）、リソース構成管理部２１３は、ステップＳ１２において、補正係数２１４ｄを再度計算し、性能評価テーブル２１４を最新の状態に更新する。
　ステップＳ１３において、リソース構成管理部２１３は、稼働情報の実計測値２１４ｃをリソース稼働情報データベース２１６より取得し、補正値２１４ｅを算出して性能評価テーブル２１４に格納する。
　ステップＳ１４において、リソース構成管理部２１３は、コンテナ管理テーブル２１５に記載されたレコードを順に探索し、リソース利用率の低いコンテナを検出する処理を開始する。リソース利用率の低いコンテナは、性能評価テーブル２１４において、正の影響判定（＋）に関する補正値２１４ｅの総和を計算し、その合計値が小さいものを選ぶことにより決定される。
　ステップＳ１５において、リソース構成管理部２１３は、コンテナ管理テーブル２１５におけるアプリケーション制約２１５ｈを参照し、リソースの追加を要求するアプリケーションが、処理対象のコンテナ上で稼働可能であるかを判定する。リソース構成管理部２１３は、処理対象コンテナがアプリケーション制約２１５ｈに違反すると判定すると（Ｓ１５：ＹＥＳ）、ステップＳ１４へ戻り、補正値２１４ｅの総和の低い他のコンテナを処理対象コンテナとして選択する。
　ステップＳ１６において、リソース構成管理部２１３は、性能評価テーブル２１４の影響判定２１４ｆを参照することで、所定の性能劣化基準値よりも大きい性能劣化があるか判定する。
　性能劣化の有無を判定する方法として、例えば、閾値に基づく方法の他に、既に選ばれている候補コンテナと処理対象コンテナとの間で、負の性能影響の度合い２１４ｆの大きさを比較する方法がある。処理対象コンテナの負の性能影響の度合い２１４ｆが候補コンテナの対応する値２１４ｆよりも大きい場合、性能劣化が有ると判定してもよい。
　性能劣化が生じていない場合（Ｓ１６：ＹＥＳ）、リソース構成管理部２１３は、ステップＳ１７において、その処理対象コンテナを、リソース構成を見直す候補コンテナとして選定する。候補として選ばれるコンテナは、一つとは限らず、複数のコンテナが候補として選択される場合もある。なお、図７に示すコンテナの種別２１５ｆなどを考慮して、候補コンテナを選定しても良い。
　ステップＳ１８において、リソース構成管理部２１３は、コンテナ管理テーブル２１５に記載のコンテナの内、未処理のコンテナが存在するか判定し、存在する場合には（Ｓ１８：ＹＥＳ）、ステップＳ１４へ戻り、前述のステップを繰り返す。
　未処理のコンテナが無くなった場合（Ｓ１８：ＮＯ）、ステップＳ１９において、リソース構成管理部２１３は、候補コンテナが一つ以上検出されていた場合、その候補コンテナのリソース構成を変更する。
　候補コンテナのリソース構成の変更とは、代表的には、リソースの減設である。ステップＳ１９においてコンテナのリソース構成を減設する処理としては、例えばサーバクラスタから一つ以上のノード（物理サーバ）を削除する処理、ストレージリソースからボリュームを削減する処理、ネットワークリソースに設定された通信優先度を下げる処理、などがある。あるいは、ステップＳ１９では、同じアプリケーション管理サーバ２０１が管理する他のコンテナに、インスタンスを集約する処理を実行してもよい。ステップＳ１９では、候補コンテナよりもリソース容量の小さなコンテナを新たに作成し、その新たに作成した小型コンテナに、候補コンテナ上で稼働しているインスタンスと候補コンテナの識別情報とを引き継がせる処理を実行してもよい。
　ただし、前述したステップＳ１９での処理内容の全ての場合において、候補コンテナの識別情報およびインスタンスは削除されることはなく、コンテナ管理テーブル２１５のレコードは、リソース構成管理部２１３により適切な値に更新される。より具体的には、例えばステップＳ１９において、移行元コンテナのサーバクラスタからノードが削除されるとき、当該ノード上に仮想サーバが稼働していた場合には、当該仮想サーバは同じサーバクラスタ内の他のノード上へ移行されて移行元コンテナに留まる。このとき、インスタンス管理テーブル２１１や、コンテナ管理テーブル２１５の仮想リソース容量ｊには変更を生じない。これにより、移行元コンテナを使用しているユーザおよびアプリケーション管理サーバ２０１は、ステップ１９における物理的な構成の変更を察知せず使用を継続できる。一方で、コンテナ管理テーブル２１５において当該移行元コンテナを管理するレコードのサーバフィールド２１５ｄから当該ノードの識別子が削除され、実リソース容量ｋフィールドでは当該ノードが有していた分のリソースが減算される。
　ステップＳ１９では、さらに、候補コンテナの減設処理によって生じたリソースの余裕分を、ステップＳ１０でリソース追加が要求されたコンテナに移動する。このとき、移行元コンテナと同様に、リソース構成管理部２１３により、コンテナ管理テーブル２１５のレコードが適切な値に更新される。ただし、コンテナ管理テーブル２１５における、リソース追加が要求された移行先コンテナについてのレコードを更新する際には、いずれかの装置の識別子の追加および実リソース容量ｋフィールドの更新に加え、仮想リソース容量ｊに追加されたリソース分の容量を加算する。
　移行元コンテナから移行先コンテナにリソースを移す処理では、移行先コンテナにおいて、当該コンテナを構成するリソースを増設する処理が行われる。その後さらに同一コンテナ内で負荷を平準化する処理、例えば仮想マシンを仮想マシンホストクラスタ内で再配置する処理を行ってもよい。
　＜物理装置に関するアクセス情報の管理方法＞
　アプリケーション管理サーバ２０１がコンテナ３１０を管理する場合、物理的な装置へのアクセスが必要となる。アプリケーション管理サーバ２０１は、アクセス情報を用いて物理装置にアクセスする。アクセス情報としては、例えば管理ＩＰアドレス、認証アカウント、装置ＩＤを利用することができる。
　アプリケーション管理サーバ２０１は、適切なアクセス情報を使用することで、安全かつ確実にコンテナ３１０のリソース構成を変更できる。ここでいう構成変更とは、例えば電源状態の変更、ブートオプションなどＢＩＯＳ（Basic Input/Output System）設定値の変更、物理アドレスなどネットワークアダプタの設定変更、入出力デバイスの切り替え、などを指す。
　一方、仮想サーバ環境や、テナント管理を必要としない他のサーバ環境においては、物理装置上のＯＳを利用しているため、ＯＳを再設定したり再インストールしたりすることで、幾らでも新たなアクセス情報を設定することができた。
　しかし、仮想化されていないサーバ環境を、複数のアプリケーションごとに権限を委譲して利用させる場合、物理装置に基づくアクセス情報を開示する必要がある。アプリケーション管理サーバ２０１と各物理装置とのアクセスを制御するには、アプリケーション管理サーバ２０１が保持するホストの認証アカウントを変更するか、あるいは管理ネットワーク上のファイヤウォール３０３においてアクセス経路を変更する方法がある。
　前述した図１１の処理中のステップＳ１９において、コンテナ３１０が単一の物理装置から構成されていた場合（例えばベアメタルホスト１０を使用する場合）、同じ物理装置を他のアプリケーション管理サーバ用のコンテナへ登録し直す必要がある。このため、移行元アプリケーション管理サーバから移行先アプリケーション管理サーバにアクセス情報を移す必要がある。
　ここでアクセス情報の移行とは、移行元で使用していたアクセス情報をそのまま移行先でも使用できるようにするという意味ではなく、移行先のアプリケーション管理サーバが移行先コンテナを安全に使用するためのアクセス情報を移行先アプリケーション管理サーバに設定するという意味である。
　移行対象の物理装置についてのアクセス情報が移行先アプリケーション管理サーバに移行されない場合、元々その物理装置を使用していた移行元アプリケーション管理サーバは、今まで通り、その移行された物理装置にアクセス可能である。したがって、不正アクセス、システム障害、データ損失などが生じうる。本実施例では、複数コンテナ間で物理装置を融通するため、アクセス情報の適切な移行は欠かせない。
　図１２は、アクセス情報を移行する処理を示すフローチャートである。以下の説明では、アクセス情報をアクセス権限情報と呼ぶ場合がある。
　ステップＳ３０において、リソース構成管理部２１３は、移行対象の物理装置に設定されているアクセス権限であって、移行元アプリケーション管理サーバ２０１が使用していたアクセス権限を無効化する。ここで、アクセス権限を完全に削除しないのは、以降の処理中に万が一不測の障害が発生した場合であっても、有効なアクセス権限が失われないようにするためである。
　ステップＳ３１において、リソース構成管理部２１３は、移行元アプリケーション管理サーバ２０１のリソース管理部２０６に対して、移行対象の物理装置についてのアクセス権限を削除するよう要求する。移行元アプリケーション管理サーバ２０１が、アクセス権限の変更機能を提供しない場合は、管理ネットワーク上のファイヤウォール３０３が移行元アプリケーション管理サーバ２０１から移行対象の物理装置へのアクセス経路を遮断してもよい。
　ステップＳ３２において、リソース構成管理部２１３は、サーバ管理部２０３を通じて移行対象の物理装置上に、新たなアクセス権限を作成し、有効化する。
　ステップＳ３３において、リソース構成管理部２１３は、ステップＳ３２で生成した新アクセス権限を、移行先アプリケーション管理サーバ２０１へ通知し、今後は新アクセス権限を使用するよう設定する。
　ただし、移行先アプリケーション管理サーバ２０１が、アクセス権限の変更機能を提供しない場合は、管理ネットワーク上のファイヤウォール３０３にて、移行先アプリケーション管理サーバ２０１と移行対象の物理装置とのアクセス経路を許可すればよい。
　ステップＳ３４において、リソース構成管理部２１３は、アクセス権限が適切に移行されたことを確認する。確認手段として、例えば、移行元アプリケーション管理サーバおよび移行先アプリケーション管理サーバ２０１から、移行対象の物理装置へそれぞれ接続試験を行う。その接続試験の結果、アクセス権限の移行が失敗していたら（Ｓ３４：ＮＯ）、リソース構成管理部２１３は、ステップＳ３６へ進んで、本フローチャートの開始時点まで状態を戻し、エラー終了する。
　アクセス権限が正常に移行した場合（Ｓ３４：ＹＥＳ）、ステップＳ３５において、リソース構成管理部２１３は、ステップＳ３０で一旦無効化しておいた旧アクセス権限を移行対象の物理装置から削除し、本処理を正常に終了する。これにより、恒久的に移行元アプリケーション管理サーバ２０１は、移行された物理装置に恒久的にアクセスすることができず、安全が維持される。
　本実施例によれば、リソースの使用状況の変化に対応して、コンテナ間でリソースを動的に移動させることができ、リソースの利用効率を高めることができる。
　本実施例によれば、テナント毎のリソース管理体系やアプリケーション管理体系に矛盾することなく、時々刻々と需要が変化するデータセンタにおいて、リソース全体の利用効率を最適化することができる。
　また、本実施例によれば、テナントごとのセキュリティを確保しつつ、従来の運用で培ったアプリケーション管理のノウハウを引き続き活用することができる。
　本実施例では、アプリケーションプログラムに予め割り当てられているリソースを、リソース追加要求で指定された使用量よりも少なく設定する場合があるが、その後の使用状況に応じて、いつでもリソースの追加割当が可能であり、計算機システムを少ないリソースで効率的に運用することができる。なお、「リソースを指定された使用量よりも少なく設定する場合がある」という表現を、「リソースを指定された使用量よりも少なく設定する」と言い換えてもよい。
　なお、本発明は、前述した実施例に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、前述された本発明の技術的特徴は、適宜結合させて実施することができる。
　１０、２０：ホスト、１１、２１：インスタンス、５０、６０：スイッチ、７０：クライアントコンピュータ、１００：ストレージ装置、２００：管理コンピュータ、２０１：アプリケーション管理サーバ、２０２：統合リソース管理部、２０３：サーバ管理部、２０４：ネットワーク管理部、２０５：ストレージ管理部

Claims (13)

  1. 　リソースを管理するリソース管理システムであって、
    　前記リソースを提供する複数の物理計算機と、
    　少なくとも一つのアプリケーションプログラムを実行する複数の仮想計算機と、
    　前記複数の物理計算機および前記複数の仮想計算機に通信可能に接続される統合リソース管理部とを有し、
    　前記統合リソース管理部は、
    　　対応づけられる前記リソースの一部を管理し仮想リソースとして提供する複数のコンテナを予め用意し、
    　　前記提供される仮想リソースの利用範囲を定義するリソース区画を管理し、
    　　前記コンテナは前記アプリケーションプログラムの何れかに対応づけられており、
    前記リソース区画で動作するアプリケーションプログラムのリソース構成変更要求を受けると、当該アプリケーションプログラムに対応づけられる前記コンテナに他のコンテナで管理される前記リソースを移行し、前記他のコンテナの管理する前記リソース量は前記他のコンテナの提供する前記仮想リソースより少なくなることがあるリソース管理システム。
  2. 　前記統合リソース管理部は、前記複数のリソース区画のうち第１のリソース区画に提供する第１のコンテナに対応付けられている前記リソースの一部である第１所定リソースを、前記複数のリソース区画のうち第２のリソース区画に提供する第２のコンテナに対応付けることで、前記第１所定リソースの所属先を前記第２のリソース区画に移す、請求項１に記載のリソース管理システム。
  3. 　前記統合リソース管理部は、前記複数のリソースについての前記アプリケーションプログラムによる利用率を管理しており、前記複数のリソースのうち最も利用率の低いリソースを前記第１所定リソースとして選択する、
    請求項２に記載のリソース管理システム。
  4. 　前記統合リソース管理部は、前記複数のリソースについての性能劣化を管理しており、最も利用率の低い前記リソースについての前記性能劣化が所定値よりも小さい場合に、前記利用率が最も低く、かつ、前記性能劣化が前記所定値よりも小さいリソースを前記第１所定リソースとして選択する、
    請求項３に記載のリソース管理システム。
  5. 　前記統合リソース管理部は、前記第２のアプリケーションプログラムが使用するための所定の制約条件を前記第１所定リソースが満足するかを判定し、前記利用率が最も低く、かつ、前記性能劣化が前記所定値よりも小さく、かつ、前記所定の制約条件を満たす仮想リソースを前記第１所定リソースとして選択する、
    請求項４に記載のリソース管理システム。
  6. 　前記統合リソース管理部は、
    　　前記第１のコンテナを使用する第１のアプリケーションプログラムを管理するための第１アプリケーション管理部と、前記第２のコンテナを使用する第２のアプリケーションプログラムを管理するための第２アプリケーション管理部とに、通信可能に接続されており、
    　　前記第１所定リソースを前記第１のコンテナから前記第２のコンテナに移す際に、前記第１所定リソースに設定されている、前記第１アプリケーション管理部が前記第１所定リソースにアクセスするための旧アクセス権限情報を無効化し、
    　　前記旧アクセス権限情報を前記第１アプリケーション管理部から削除し、
    　　新たなアクセス権限情報を生成して、前記新たなアクセス権限情報を前記第１所定リソースに設定し、
    　　前記新たなアクセス権限情報を前記第２のアプリケーション管理部に設定し、
    　　前記第１所定リソースにアクセスするためのアクセス権限が前記第１アプリケーション管理部から前記第２アプリケーション管理部に移行したことを確認し、
    　　前記旧アクセス権限情報を前記第１アプリケーション管理部から削除する、
    請求項５に記載のリソース管理システム。
  7. 　前記統合リソース管理部は、前記複数のコンテナに対応付けられている前記リソースのそれぞれに予め設定されている所定の性能指標の実測値を用いて所定の演算を行うことにより、前記コンテナを使用する前記アプリケーションプログラムの種類に依存せずに前記複数のコンテナの性能を評価するための性能評価値を算出し、前記算出した性能評価値を提示する、
    請求項１のいずれかに記載のリソース管理システム。
  8. 　前記統合リソース管理部は、前記複数のコンテナに対応付けられている前記リソースのそれぞれに予め設定されている所定の性能指標の実測値を用いて所定の演算を行うことにより、前記コンテナを使用する前記アプリケーションプログラムの種類に依存せずに前記複数のコンテナの性能を評価するための性能評価値を算出し、算出した性能評価値を前記所定の要求を発行する装置に通知し、
    　前記所定の要求は、前記性能評価値からボトルネックであると判定された前記リソースの追加を要求するものである、
    請求項４に記載のリソース管理システム。
  9. 　前記統合リソース管理部は、
    　　前記複数のコンテナに対応付けられている前記リソースのそれぞれに予め設定されている所定の性能指標の実測値を用いて所定の演算を行うことにより、前記コンテナを使用する前記アプリケーションプログラムの種類に依存せずに前記複数のコンテナの性能を評価するための性能評価値を算出し、
    　　前記算出した性能評価値に基づいて前記複数のコンテナについての性能劣化を管理し、
    　　最も利用率の低い前記コンテナについての前記性能劣化が所定値よりも小さい場合に、前記利用率が最も低く、かつ、前記性能劣化が前記所定値よりも小さいリソースを前記第１所定リソースとして選択する、
    請求項３に記載のリソース管理システム。
  10. 　情報処理システムのリソースを管理コンピュータを用いて管理する方法であって、
    　前記情報処理システムは、前記リソースを提供する複数の物理計算機と、少なくとも一つのアプリケーションプログラムを実行する複数の仮想計算機と、前記複数の物理計算機および前記複数の仮想計算機に通信可能に接続される管理コンピュータとを有し、
    　前記管理コンピュータは、
    　　対応付けられる前記リソースの一部を管理し仮想リソースとして提供する複数のコンテナを予め用意し、
    　前記提供される仮想リソースの利用範囲を定義するリソース区画を管理し、
    　前記コンテナは前記アプリケーションプログラムの何れかに対応づけられており、
    　前記リソース区画で動作するアプリケーションプログラムのリソース構成変更要求を受けると、当該アプリケーションプログラムに対応づけられる前記コンテナに他のコンテナで管理される前記リソースを移行し、前記他のコンテナの管理する前記リソース量は前記他のコンテナの提供する前記仮想リソースより少なくなることがある、
    　リソース管理方法。
  11. 　前記管理コンピュータは、前記複数のリソース区画のうち第１のリソース区画に提供する第１のコンテナに対応付けられている前記リソースの一部である第１所定リソースを、前記複数のリソース区画のうち第２のリソース区画に提供する第２のコンテナに対応付けることで、前記第１所定リソースの所属先を前記第２リソース区画に移す、請求項１０に記載のリソース管理方法。
  12. 　コンピュータを、情報処理システムのリソースを管理するための管理コンピュータとして機能させるためのコンピュータプログラムであって、
    　前記情報処理システムは、所定リソースを提供する複数の物理計算機と、少なくとも一つのアプリケーションプログラムを実行する複数の仮想計算機と、前記複数の物理計算機および前記複数の仮想計算機に通信可能に接続される管理コンピュータとを有し、
    　前記コンピュータに、対応付けられる前記リソースの一部を管理し仮想リソースとして提供する複数のコンテナを予め用意し、
    　前記提供される仮想リソースの利用範囲を定義するリソース区画を管理し、
    　前記コンテナは前記アプリケーションプログラムの何れかに対応づけられており、
    　前記リソース区画で動作するアプリケーションプログラムのリソース構成変更要求を受けると、当該アプリケーションプログラムに対応づけられる前記コンテナに他のコンテナで管理される前記リソースを移行し、前記他のコンテナの管理する前記リソース量は前記他のコンテナの提供する前記仮想リソースより少なくなることがある、
    　コンピュータプログラム。
  13. 　前記コンピュータプログラムは、前記コンピュータに、前記複数のリソース区画のうち第１のリソース区画に提供する第１のコンテナに対応付けられている前記リソースの一部である第１所定リソースを、前記複数のリソース区画のうち第２のリソース区画に提供する第２のコンテナに対応付けることで、前記第１所定リソースの所属先を前記第２仮想リソースに移させる、請求項１２に記載のコンピュータプログラム。
PCT/JP2013/077063 2013-10-04 2013-10-04 リソース管理システムおよびリソース管理方法 WO2015049789A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US14/770,081 US9495195B2 (en) 2013-10-04 2013-10-04 Resource migration between virtual containers based on utilization rate and performance degradation
JP2015540343A JP5976230B2 (ja) 2013-10-04 2013-10-04 リソース管理システムおよびリソース管理方法
PCT/JP2013/077063 WO2015049789A1 (ja) 2013-10-04 2013-10-04 リソース管理システムおよびリソース管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/077063 WO2015049789A1 (ja) 2013-10-04 2013-10-04 リソース管理システムおよびリソース管理方法

Publications (1)

Publication Number Publication Date
WO2015049789A1 true WO2015049789A1 (ja) 2015-04-09

Family

ID=52778397

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/077063 WO2015049789A1 (ja) 2013-10-04 2013-10-04 リソース管理システムおよびリソース管理方法

Country Status (3)

Country Link
US (1) US9495195B2 (ja)
JP (1) JP5976230B2 (ja)
WO (1) WO2015049789A1 (ja)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016167086A1 (ja) * 2015-04-17 2016-10-20 日本電信電話株式会社 サーバ選択装置、サーバ選択方法及びサーバ選択プログラム
JP2017037403A (ja) * 2015-08-07 2017-02-16 株式会社日立製作所 計算機システム及びコンテナ管理方法
JP2017107555A (ja) * 2015-12-11 2017-06-15 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ ソフトウェア・コンテナ中のソフトウェアの識別を決定するための方法、システム、およびプログラム
JP2017111761A (ja) * 2015-12-18 2017-06-22 エヌ・ティ・ティ・コミュニケーションズ株式会社 コンテナ収容装置、コンテナ作成方法、及びプログラム
JP2019503535A (ja) * 2016-02-25 2019-02-07 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 自動アプリケーション展開のための方法およびクラウド管理ノード
CN111200595A (zh) * 2019-12-20 2020-05-26 北京淇瑀信息科技有限公司 一种访问容器的权限管理方法、装置和电子设备
WO2021095943A1 (ko) * 2019-11-15 2021-05-20 대구대학교 산학협력단 서비스 프로파일을 고려한 컨테이너의 배치 방법
US11252228B2 (en) 2015-10-19 2022-02-15 Citrix Systems, Inc. Multi-tenant multi-session catalogs with machine-level isolation
JP7455813B2 (ja) 2018-08-28 2024-03-26 ノボ・ノルデイスク・エー／エス コンテナベースの医薬品投与ガイダンスを提供して、糖尿病を治療するためのシステムおよび方法

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6033985B2 (ja) * 2014-03-07 2016-11-30 株式会社日立製作所 性能評価方法及び情報処理装置
US9703611B1 (en) * 2014-03-21 2017-07-11 Amazon Technologies, Inc. Isolating resources for utilization by tenants executing in multi-tenant software containers
JP6326913B2 (ja) * 2014-03-31 2018-05-23 富士通株式会社 制御プログラムおよび制御方法
US9843478B2 (en) * 2014-06-12 2017-12-12 Dell Products L.P. Template builder for end-to-end provisioning and lifecycle management of it infrastructure and services
US9563475B2 (en) 2014-09-30 2017-02-07 International Business Machines Corporation Merging connection pools to form a logical pool of connections during a preset period of time thereby more efficiently utilizing connections in connection pools
JP6540356B2 (ja) * 2015-08-10 2019-07-10 富士通株式会社 システム複製制御装置およびシステムの複製制御方法
US9846602B2 (en) * 2016-02-12 2017-12-19 International Business Machines Corporation Migration of a logical partition or virtual machine with inactive input/output hosting server
US10034407B2 (en) * 2016-07-22 2018-07-24 Intel Corporation Storage sled for a data center
US10348813B2 (en) * 2016-10-28 2019-07-09 International Business Machines Corporation Provisioning a bare-metal server
US10684933B2 (en) * 2016-11-28 2020-06-16 Sap Se Smart self-healing service for data analytics systems
CN106878058B (zh) * 2017-01-03 2020-11-06 新华三技术有限公司 一种服务节点复用方法及装置
US10409702B2 (en) * 2017-03-20 2019-09-10 Netapp, Inc. Methods and systems for managing networked storage system resources
US10884816B2 (en) 2017-03-28 2021-01-05 International Business Machines Corporation Managing system resources in containers and virtual machines in a coexisting environment
US10387212B2 (en) * 2017-06-15 2019-08-20 Microsoft Technology Licensing, Llc Attribute collection and tenant selection for on-boarding to a workload
CN109254843A (zh) * 2017-07-14 2019-01-22 华为技术有限公司 分配资源的方法和装置
KR102052652B1 (ko) * 2017-12-05 2019-12-06 광주과학기술원 클라우드 서비스 시스템
US11513864B2 (en) * 2018-03-22 2022-11-29 Amazon Technologies, Inc. Adoption of existing virtual computing resources into logical containers for management operations
US11086685B1 (en) 2018-04-25 2021-08-10 Amazon Technologies, Inc. Deployment of virtual computing resources with repeatable configuration as a resource set
JP6957431B2 (ja) * 2018-09-27 2021-11-02 株式会社日立製作所 Ｈｃｉ環境でのｖｍ／コンテナおよびボリューム配置決定方法及びストレージシステム
US11086686B2 (en) * 2018-09-28 2021-08-10 International Business Machines Corporation Dynamic logical partition provisioning
US11500874B2 (en) * 2019-01-23 2022-11-15 Servicenow, Inc. Systems and methods for linking metric data to resources
US11416264B2 (en) * 2019-08-27 2022-08-16 Sap Se Software component configuration alignment
US11356317B2 (en) * 2019-12-24 2022-06-07 Vmware, Inc. Alarm prioritization in a 5G telco network
US20230057210A1 (en) 2020-02-26 2023-02-23 Rakuten Symphony Singapore Pte. Ltd. Network service construction system and network service construction method
WO2021171211A1 (ja) * 2020-02-26 2021-09-02 ラクテン・シンフォニー・シンガポール・プライベート・リミテッド リソースプール管理システム、リソースプール管理方法及びプログラム
JP7389351B2 (ja) * 2020-03-23 2023-11-30 富士通株式会社 移動対象コンテナ決定方法および移動対象コンテナ決定プログラム
US11875046B2 (en) * 2021-02-05 2024-01-16 Samsung Electronics Co., Ltd. Systems and methods for storage device resource management

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010282420A (ja) * 2009-06-04 2010-12-16 Hitachi Ltd 管理計算機、リソース管理方法、リソース管理プログラム、記録媒体および情報処理システム

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7140020B2 (en) * 2000-01-28 2006-11-21 Hewlett-Packard Development Company, L.P. Dynamic management of virtual partition computer workloads through service level optimization
US7748005B2 (en) * 2000-01-28 2010-06-29 Hewlett-Packard Development Company, L.P. System and method for allocating a plurality of resources between a plurality of computing domains
US7694303B2 (en) * 2001-09-25 2010-04-06 Sun Microsystems, Inc. Method for dynamic optimization of multiplexed resource partitions
US7299468B2 (en) * 2003-04-29 2007-11-20 International Business Machines Corporation Management of virtual machines to utilize shared resources
US8560671B1 (en) * 2003-10-23 2013-10-15 Netapp, Inc. Systems and methods for path-based management of virtual servers in storage network environments
US7752623B1 (en) * 2004-09-16 2010-07-06 Hewlett-Packard Development Company, L.P. System and method for allocating resources by examining a system characteristic
US7765552B2 (en) * 2004-09-17 2010-07-27 Hewlett-Packard Development Company, L.P. System and method for allocating computing resources for a grid virtual system
US7752624B2 (en) * 2004-12-21 2010-07-06 Hewlett-Packard Development Company, L.P. System and method for associating workload management definitions with computing containers
US7458066B2 (en) * 2005-02-28 2008-11-25 Hewlett-Packard Development Company, L.P. Computer system and method for transferring executables between partitions
US7730486B2 (en) * 2005-02-28 2010-06-01 Hewlett-Packard Development Company, L.P. System and method for migrating virtual machines on cluster systems
US8020164B2 (en) * 2005-12-22 2011-09-13 International Business Machines Corporation System for determining and reporting benefits of borrowed computing resources in a partitioned environment
US8146091B2 (en) * 2008-05-01 2012-03-27 International Business Machines Corporation Expansion and contraction of logical partitions on virtualized hardware
US8856783B2 (en) * 2010-10-12 2014-10-07 Citrix Systems, Inc. Allocating virtual machines according to user-specific virtual machine metrics
US8707300B2 (en) * 2010-07-26 2014-04-22 Microsoft Corporation Workload interference estimation and performance optimization
US8667496B2 (en) * 2011-01-04 2014-03-04 Host Dynamics Ltd. Methods and systems of managing resources allocated to guest virtual machines
US8601483B2 (en) * 2011-03-22 2013-12-03 International Business Machines Corporation Forecasting based service for virtual machine reassignment in computing environment
JP5691062B2 (ja) 2011-04-04 2015-04-01 株式会社日立製作所 仮想計算機の制御方法及び管理計算機
US8694995B2 (en) * 2011-12-14 2014-04-08 International Business Machines Corporation Application initiated negotiations for resources meeting a performance parameter in a virtualized computing environment
TW201407476A (zh) * 2012-08-06 2014-02-16 Hon Hai Prec Ind Co Ltd 虛擬機資源配置系統及方法
US9858095B2 (en) * 2012-09-17 2018-01-02 International Business Machines Corporation Dynamic virtual machine resizing in a cloud computing infrastructure
CN104956325A (zh) * 2013-01-31 2015-09-30 惠普发展公司，有限责任合伙企业 物理资源分配
US9251115B2 (en) * 2013-03-07 2016-02-02 Citrix Systems, Inc. Dynamic configuration in cloud computing environments
US8904389B2 (en) * 2013-04-30 2014-12-02 Splunk Inc. Determining performance states of components in a virtual machine environment based on performance states of related subcomponents
US9348654B2 (en) * 2013-11-19 2016-05-24 International Business Machines Corporation Management of virtual machine migration in an operating environment
US10142192B2 (en) * 2014-04-09 2018-11-27 International Business Machines Corporation Management of virtual machine resources in computing environments
US9280392B1 (en) * 2014-10-02 2016-03-08 International Business Machines Corporation Resource substitution and reallocation in a virtual computing environment

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010282420A (ja) * 2009-06-04 2010-12-16 Hitachi Ltd 管理計算機、リソース管理方法、リソース管理プログラム、記録媒体および情報処理システム

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016167086A1 (ja) * 2015-04-17 2016-10-20 日本電信電話株式会社 サーバ選択装置、サーバ選択方法及びサーバ選択プログラム
JPWO2016167086A1 (ja) * 2015-04-17 2017-09-14 日本電信電話株式会社 サーバ選択装置、サーバ選択方法及びサーバ選択プログラム
US10445128B2 (en) 2015-04-17 2019-10-15 Nippon Telegraph And Telephone Corporation Server selection device, server selection method, and server selection program
JP2017037403A (ja) * 2015-08-07 2017-02-16 株式会社日立製作所 計算機システム及びコンテナ管理方法
US11252228B2 (en) 2015-10-19 2022-02-15 Citrix Systems, Inc. Multi-tenant multi-session catalogs with machine-level isolation
JP2017107555A (ja) * 2015-12-11 2017-06-15 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ ソフトウェア・コンテナ中のソフトウェアの識別を決定するための方法、システム、およびプログラム
JP2017111761A (ja) * 2015-12-18 2017-06-22 エヌ・ティ・ティ・コミュニケーションズ株式会社 コンテナ収容装置、コンテナ作成方法、及びプログラム
JP2019503535A (ja) * 2016-02-25 2019-02-07 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 自動アプリケーション展開のための方法およびクラウド管理ノード
US10824408B2 (en) 2016-02-25 2020-11-03 Huawei Technologies, Co., Ltd. Method for automatic application deployment and cloud management node
JP7455813B2 (ja) 2018-08-28 2024-03-26 ノボ・ノルデイスク・エー／エス コンテナベースの医薬品投与ガイダンスを提供して、糖尿病を治療するためのシステムおよび方法
WO2021095943A1 (ko) * 2019-11-15 2021-05-20 대구대학교 산학협력단 서비스 프로파일을 고려한 컨테이너의 배치 방법
CN111200595A (zh) * 2019-12-20 2020-05-26 北京淇瑀信息科技有限公司 一种访问容器的权限管理方法、装置和电子设备

Also Published As

Publication number Publication date
US9495195B2 (en) 2016-11-15
US20160004551A1 (en) 2016-01-07
JP5976230B2 (ja) 2016-08-23
JPWO2015049789A1 (ja) 2017-03-09

Similar Documents

Publication Publication Date Title
JP5976230B2 (ja) リソース管理システムおよびリソース管理方法
JP5478107B2 (ja) 仮想ストレージ装置を管理する管理サーバ装置及び仮想ストレージ装置の管理方法
CN106168884B (zh) 访问对象存储系统的计算机系统
US8909767B2 (en) Cloud federation in a cloud computing environment
US8656018B1 (en) System and method for automated allocation of hosting resources controlled by different hypervisors
JP5174747B2 (ja) 計算機システムおよび管理装置
CN110955487A (zh) Hci环境下的vm/容器和卷配置决定方法及存储系统
US8051262B2 (en) Storage system storing golden image of a server or a physical/virtual machine execution environment
US20110276963A1 (en) Virtual Data Storage Devices and Applications Over Wide Area Networks
US20120233315A1 (en) Systems and methods for sizing resources in a cloud-based environment
US20110078334A1 (en) Methods and apparatus for managing virtual ports and logical units on storage systems
US8412901B2 (en) Making automated use of data volume copy service targets
JP2006092322A (ja) ファイルアクセスサービスシステムとスイッチ装置及びクオータ管理方法並びにプログラム
WO2014184893A1 (ja) 計算機システム及びリソース管理方法
CN101656718A (zh) 网络服务器系统与其虚拟机器的建立与开启的方法
US9535629B1 (en) Storage provisioning in a data storage environment
JP2010257274A (ja) 仮想化環境におけるストレージ管理システム及びストレージ管理方法
JP6055924B2 (ja) ストレージシステム及びストレージシステムの制御方法
US9940073B1 (en) Method and apparatus for automated selection of a storage group for storage tiering
KR101563292B1 (ko) 가상 세션 관리자를 이용한 클라우드 가상화 시스템 및 방법
JP2011170679A (ja) 仮想計算機システムおよびその資源配分制御方法
US8055867B2 (en) Methods, apparatuses, and computer program products for protecting pre-staged provisioned data in a storage system
US11900160B2 (en) Methods for managing storage quota assignment in a distributed system and devices thereof
JP6244496B2 (ja) サーバストレージシステムの管理システム及び管理方法
WO2014148142A1 (ja) クラウド向け計算機システム

Legal Events

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

Ref document number: 13895058

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14770081

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2015540343

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13895058

Country of ref document: EP

Kind code of ref document: A1