WO2020116221A1 - Ｉｃｔ資源管理装置、ｉｃｔ資源管理方法、および、ｉｃｔ資源管理プログラム - Google Patents

Ｉｃｔ資源管理装置、ｉｃｔ資源管理方法、および、ｉｃｔ資源管理プログラム Download PDF

Info

Publication number
WO2020116221A1
WO2020116221A1 PCT/JP2019/045932 JP2019045932W WO2020116221A1 WO 2020116221 A1 WO2020116221 A1 WO 2020116221A1 JP 2019045932 W JP2019045932 W JP 2019045932W WO 2020116221 A1 WO2020116221 A1 WO 2020116221A1
Authority
WO
WIPO (PCT)
Prior art keywords
configuration information
virtual
resource management
layer
information
Prior art date
Application number
PCT/JP2019/045932
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 SG11202105923VA priority Critical patent/SG11202105923VA/en
Priority to US17/311,073 priority patent/US20220043946A1/en
Priority to AU2019393436A priority patent/AU2019393436B2/en
Priority to JP2020559060A priority patent/JP7056759B2/ja
Publication of WO2020116221A1 publication Critical patent/WO2020116221A1/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/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
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/18—Network design, e.g. design based on topological or interconnect aspects of utility systems, piping, heating ventilation air conditioning [HVAC] or cabling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/76—Adapting program code to run in a different environment; Porting
    • 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/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/45562—Creating, deleting, cloning virtual machine instances

Definitions

  • the present invention relates to an ICT (Information and Communication Technology) resource management device, an ICT resource management method, and an ICT resource management program.
  • ICT Information and Communication Technology
  • Patent Document 1 "one different communication service that is disclosed by a communication service API for each wholesale service provider in response to an order request for use of a communication service from a terminal that provides communication to a user" is disclosed.
  • An inter-provider batch service construction device for collectively providing one or more of the above, which holds a catalog in which specifications of communication wholesale services are described and a cooperation rule which defines cooperation of various communication services,
  • the communication service APIs corresponding to the plurality of communication services requested for the order are collectively cooperated based on the held catalog and the cooperation rule.
  • a cooperative service is constructed, and a collective construction function unit for providing the constructed cooperative service to the terminal is provided.
  • a distributed system to which the virtualization technology is applied includes a physical layer that is an aggregate of physical nodes (eg, computers, routers, sensors) included in the distributed system, and an aggregate of virtual nodes configured and operating on the physical node. And a virtual layer.
  • configuration management for the physical layer
  • configuration management for the virtual layer
  • configuration management for the virtual layer.
  • the engineer of the distributed system designs both the physical layer and the virtual layer.
  • a configuration change such as allocating a new application to a virtual node is made so that the service can be used by a device (eg, IoT (Internet of Things) device) connected to the physical node.
  • a device eg, IoT (Internet of Things) device
  • IoT Internet of Things
  • an engineer has used a method of identifying a virtual node by collating a physical layer and a virtual layer.
  • such a method requires manual labor, it obstructs the automation of the operation of the distributed system, resulting in an increase in the operating cost of the distributed system.
  • an object of the present invention is to automate the operation of the distributed system and reduce the operation cost of the distributed system to which the virtualization technology is applied.
  • the invention according to claim 1 is an ICT resource management device that manages a physical node and a virtual node, which are ICT resources, and is configuration information regarding the physical node on a physical layer.
  • a physical layer configuration information, and a configuration information management unit that manages virtual layer configuration information that is configuration information regarding the virtual node on the virtual layer, a layer mapping unit that performs mapping between the physical layer and the virtual layer, and external
  • the physical layer configuration information, the virtual layer configuration information, and the mapping information that is the result of the mapping based on the design information of the infrastructure necessary for the configuration change blue
  • the invention according to claim 4 is an ICT resource management method in an ICT resource management device for managing a physical node and a virtual node which are ICT resources, wherein the ICT resource management device is the physical layer on a physical layer.
  • the physical layer configuration information, the virtual layer configuration information, and based on the mapping information that is the result of the mapping it becomes the infrastructure design information necessary for the configuration change.
  • Performing a step of creating a blueprint and a step of performing orchestration for the virtual layer by accessing and executing a program that can be operated through an API based on the blueprint. Characterize.
  • the association between the physical node and the virtual node becomes clear by the mapping between the physical layer and the virtual layer, and the virtual node for the configuration change is specified without human intervention. be able to. Therefore, automation of operation can be realized. Therefore, it is possible to automate the operation of the distributed system and reduce the operating cost of the distributed system to which the virtualization technology is applied.
  • the invention according to claim 2 is the ICT resource management device according to claim 1, wherein the blueprint includes a collection of catalogs indicating steps for providing a service, and input information for the catalogs. The following parameters are included.
  • a workflow for executing the orchestration can be easily configured.
  • the invention according to claim 3 is the ICT resource management device according to claim 1 or 2, further comprising a monitoring unit that monitors the physical node and the virtual node, and the configuration information management
  • the unit generates the physical layer configuration information and the virtual layer configuration information from the information collected by the monitoring of the monitoring unit, and the layer mapping unit generates the mapping information from the information collected by the monitoring of the monitoring unit. It is characterized in that it is generated.
  • the configuration information and the mapping information can be held in the latest state, a blueprint is created and orchestration is executed without human intervention, which contributes to automation of operations. be able to.
  • the invention according to claim 5 is an ICT resource management program for causing a computer to function as the ICT resource management device according to any one of claims 1 to 3.
  • the construction of the ICT resource management device can be facilitated.
  • the distributed system 100 including the ICT resource management device 1 of the present embodiment is a system to which virtualization technology is applied, and the ICT resource management device 1, the service provider terminal 2, and the server 3 are provided. , Edge 4, and device 5.
  • the distributed system 100 can manage a physical layer that is an aggregate of physical nodes and a virtual layer that is an aggregate of virtual nodes configured and operating on the physical nodes.
  • the server 3, the edge 4, and the device 5 are physical nodes forming a physical layer.
  • a VM (Virtual Machine) 7 arranged on the virtual layer shown in FIG. 1 is a virtual node in which the server 3 or the edge 4 is virtualized.
  • the ICT resource management device 1 manages physical nodes and virtual nodes as ICT resources.
  • the service provider terminal 2 is a terminal that requests configuration changes such as initial deployment and variable scale.
  • the service provider terminal 2 makes the request through an API (Application Programming Interface).
  • the API is a Northbound API between the ICT resource management device 1 and the service provider terminal 2.
  • the service provider terminal 2 is used by a service provider or the like.
  • the server 3 is a computer that executes processes related to service provision.
  • the server 3 shown in FIG. 1 is located on the cloud platform A and executes processes for cloud services.
  • Edge 4 is a relay device arranged on the NW (network), and corresponds to, for example, a router, a bridge, or a gateway. At the edge 4, one or a plurality of applications 6 for executing a process related to service provision are arranged. The server 3 and the edge 4 are communicably connected.
  • the device 5 is a device that the end user uses the service, and corresponds to, for example, an IoT device.
  • the device 5 can use the service by connecting to the edge 4.
  • the ICT resource management device 1 can collect information about physical nodes and virtual nodes. Further, the ICT resource management device 1 can perform mapping between the physical layer and the virtual layer by using the collected information (see the broken double-headed arrow in FIG. 1). Further, the ICT resource management device 1 can execute orchestration on the virtual layer. Specifically, it is possible to deploy a service and allocate resources to the VM 7.
  • the ICT resource management device 1 includes a request acquisition unit 11, a blueprint creation unit 12, a configuration information management unit 13, a layer mapping unit 14, a workflow execution unit 15, and an API adapter unit 16. And a functional unit such as the monitoring unit 17. Further, the ICT resource management device 1 stores the configuration information DB 21, the mapping information 22, the catalog group 23, and the blueprint 24 in the storage unit.
  • the storage unit included in the ICT resource management device 1 may be, for example, inside the ICT resource management device 1 or outside the ICT resource management device 1.
  • the request acquisition unit 11 acquires a configuration change request from the service provider terminal 2.
  • the request acquired by the request acquisition unit 11 may be called “order information”.
  • the configuration change request can be made not only from the service provider terminal 2 but also from the terminal of the maintenance person of the distributed system 100, for example.
  • the service provider terminal 2 and the maintenance person's terminal are examples of external devices.
  • the blueprint creation unit 12 creates the blueprint 24 corresponding to the order information acquired by the request acquisition unit 11.
  • the blueprint 24 is the design information of the infrastructure required for the requested configuration change.
  • the infrastructure indicates the components of the operating environment of the service. For example, the ICT resource itself, ICT resource setting information (eg VM name, IP address, host name), allocated resources, LB (load balancer) set on the NW. ), FW (firewall), and containers.
  • the configuration information management unit 13 manages information about ICT resources as configuration information.
  • the configuration information management unit 13 can collect information about physical nodes and virtual nodes by accessing the API for collecting resource information, for example.
  • the resource information collection API is an API for providing resource information prepared by the orchestration target.
  • the API for collecting resource information is a southbound API between the ICT resource management device 1 and the orchestration target.
  • the information to be collected can be, for example, a MIB (Management Information Base) based on Simple Network Management Protocol (SNMP), but is not limited to this.
  • MIB Management Information Base
  • SNMP Simple Network Management Protocol
  • Orchestration targets include, but are not limited to, physical nodes and virtual nodes.
  • the interface provided by the orchestration target can be provided by, for example, a controller (not shown) that controls the orchestration target, or can be provided by each of the physical node and the virtual node.
  • the physical layer configuration information 21a is configuration information regarding physical nodes on the physical layer. As shown in FIG. 3, the physical layer configuration information 21a manages, for example, “node ID”, “state”, “host name”, “IP address”, “VMID”, “use service”, and “user”. It has items, and the value of each management item is stored for each physical node.
  • the management item of “node ID” stores the identifier of the target physical node.
  • the management item of "state” stores the operating state of the target physical node ("OK" for normal, "NG” for failure).
  • the host name of the target physical node is stored in the management item of “host name”.
  • the IP address assigned to the target physical node is stored in the management item of “IP address”.
  • the “VMID” management item stores the identifier of the VM operating on the target physical node.
  • the management item of "utilization service” stores the identifier of the service available in the target physical node.
  • Utilization services include, for example, cloud services and edge computing services, but are not limited to these. Further, the service to be used can include a service that enables a plurality of physical nodes to provide the same service.
  • the “user” management item stores the identifier of the user who uses the service indicated by the corresponding “use service”.
  • the user may be, for example, a corporation or an individual. Further, for example, when the corresponding physical node is an edge device, only the owner of the edge device can be the user.
  • the management items of the physical layer configuration information 21a shown in FIG. 3 are examples, and more can be set.
  • the management items of the physical layer configuration information 21a it is possible to set the memory size of the VM operating on the target physical node, the CPU frequency, the power state, and the VM name.
  • the name and ID of the resource pool used for the target physical node can be set.
  • the management item of the physical layer configuration information 21a the type, ID, and name of the network in which the target physical node is arranged can be set.
  • the ID, type, and name of the folder used by the target physical node can be set.
  • the management items of the physical layer configuration information 21a the storage capacity, ID, type, and name of the data store used by the target physical node can be set. Further, as the management item of the physical layer configuration information 21a, the ID and name of the data center controlling the target physical node can be set. Further, as the management items of the physical layer configuration information 21a, it is possible to set a user name and a password which are authentication information of a user who accesses the target physical node.
  • the virtual layer configuration information 21b is configuration information regarding virtual nodes on the virtual layer. As shown in FIG. 4, the virtual layer configuration information 21b has management items such as “node ID”, “state”, “VM name”, “IP address”, and “physical device ID”. The value of each management item is stored in.
  • the management item of “node ID” stores the identifier of the target virtual node.
  • the management item of "state” stores the operating state of the target operating node ("OK" for normal operation, "NG” for failure).
  • the name of the target virtual node is stored in the management item of “VM name”.
  • the IP address assigned to the target virtual node is stored in the management item of “IP address”.
  • the management item of “physical device ID” stores the identifier of the physical node in which the target virtual node is arranged.
  • the management items of the virtual layer configuration information 21b shown in FIG. 4 are examples, and more can be set.
  • a VMID that is ID information of the target virtual node can be set.
  • the management items of the virtual layer configuration information 21b it is possible to set the memory size and the CPU frequency that are resources of the target virtual node.
  • the power state of the target virtual node can be set as a management item of the virtual layer configuration information 21b.
  • the management items of the virtual layer configuration information 21b it is possible to set a user name and a password which are authentication information of a user who accesses the target virtual node.
  • a gateway used by the target virtual node a VXLAN (Virtual eXtensible Local Area Network), and a static route can be set.
  • the host name of the physical node in which the target virtual node is arranged can be set as the management item of the virtual layer configuration information 21b.
  • the management item of the virtual layer configuration information 21b it is possible to set information regarding the hypervisor that generates the target virtual node.
  • the management item of the container application can be set as the management item set in the virtual layer configuration information 21b.
  • the management items of the virtual layer configuration information 21b the host name, label, state, and account ID of the container host registered for the container used by the target virtual node can be set.
  • the management items of the virtual layer configuration information 21b it is possible to set the ID, name, state, and scale (the number of utilization servers) of the service provided by the container used by the target virtual node.
  • the management items of the virtual layer configuration information 21b it is possible to set the volume mount, ID (only when using the Collinser NFS (Network File System)) and image ID of the storage device provided in the container used by the target virtual node. it can.
  • the management items of the virtual layer configuration information 21b it is possible to set the stack group of the storage device provided in the container used by the target virtual node, the health state, the stack ID, and the ID of the service used.
  • the layer mapping unit 14 performs mapping between the physical layer and the virtual layer. Specifically, the layer mapping unit 14 uses the configuration information managed by the configuration information management unit 13 to determine which physical node on the physical layer the virtual node on the virtual layer is (or the application arranged on the physical node). 6) It is determined whether or not it is associated with.
  • the ICT resource management device 1 stores, as the mapping information 22, the determination result of the association of the physical node and the virtual node by the layer mapping unit 14.
  • the layer mapping unit 14 refers to the management item of “VMID” of the physical layer configuration information 21a (FIG. 3) and the management item of “Physical device ID” of the virtual layer configuration information 21b (FIG. 4), The association between the physical node and the virtual node can be determined.
  • FIG. 5 is an explanatory diagram of a blueprint for initial deployment.
  • the blueprint 24 can be configured as a set of a service template and parameters.
  • the service template can be a collection of catalogs.
  • the catalog is a template of processes used for providing services, and is an element of the catalog group 23 stored in the ICT resource management device 1.
  • the catalog itself is well known, and detailed description thereof will be omitted.
  • the parameter is input information for each catalog.
  • the order information acquired by the request acquisition unit 11 is the order information related to the initial deployment.
  • the blueprint creation unit 12 can configure a service template by selecting a catalog for VM creation, a catalog for NW setting, and a catalog for container setting from the catalog group 23, for example. ..
  • the parameters input to the catalog for VM creation are, for example, the number and type of VMs created.
  • parameters for designating three VMs that function as Web servers and two VMs that function as AP servers (application servers), that is, a total of five VMs are input to the catalog for VM creation.
  • the parameter input to the catalog for VM creation can be input by the service provider terminal 2, for example.
  • the parameter input to the NW setting catalog is, for example, IP address allocation (IP allocation).
  • IP allocation IP allocation
  • the parameter designating the IP address assigned to the created VM is input to the NW setting catalog.
  • the parameters input to the NW setting catalog can be acquired from the distributed system 100, for example.
  • the parameter input to the container setting catalog is, for example, the setting method of the container used by the created VM.
  • a parameter indicating the setting method of copy execution by Collinser is input to the container setting catalog.
  • the parameter input to the container setting catalog can be input by the service provider terminal 2, for example.
  • the blueprint creation unit 12 selects a required catalog from the catalog group 23 according to the operation indicated by the order information acquired by the request acquisition unit 11, and forms a service template.
  • the blueprint creating unit 12 can acquire the parameters input to the selected catalog from the order information and the distributed system 100.
  • the blueprint creation unit 12 requests the parameters input to the selected catalog from the service provider terminal 2 or the like that has sent the order information, and receives the order information that is a response to the request again, thereby ordering the order. Parameters can be obtained from the information.
  • the distributed system 100 itself can acquire the parameters such as the allocation of the IP address
  • the blueprint creation unit 12 can acquire the parameters input to the selected catalog from the distributed system 100.
  • the blueprint creating unit 12 refers to the configuration information managed by the configuration information managing unit 13 and the mapping information 22 stored by the layer mapping unit 14. That is, the blueprint creating unit 12 determines the current state of the physical node and the virtual node determined from the physical layer configuration information 21a, the virtual layer configuration information 21b, and the mapping information 22 and the service provider, which is indicated by the order information. It is possible to create the blueprint 24 by collating with the request such as.
  • the workflow execution unit 15 executes the workflow according to the blueprint 24 created by the blueprint creation unit 12.
  • the workflow is a process in which the steps indicated by the catalog included in the blueprint 24 are connected in a predetermined order.
  • the workflow for initial deployment is such that the order is determined and linked, such as VM creation ⁇ NW setting ⁇ container setting.
  • orchestration is executed and resources are assigned to the ICT resources.
  • the API adapter unit 16 is an interface for accessing a program that can be operated through the API in response to a command from the workflow execution unit 15 that executes a workflow.
  • the API is a southbound API between the API adapter unit 16 (or the ICT resource management device 1 including the API adapter unit 16) and the orchestration target.
  • the API adapter unit 16 can be interface-connected for each orchestration target.
  • a plurality of API adapter units 16 can be prepared for each program that can be operated through the API.
  • the workflow execution unit 15 can execute a workflow by executing a program that can be operated through the API.
  • the combination of the workflow execution unit 15 and the API adapter unit 16 functions as an orchestrator unit that executes orchestration.
  • the monitoring unit 17 monitors the physical node on the physical layer and the virtual node on the virtual layer by, for example, SNMP.
  • the monitoring result by the monitoring unit 17 indicates the usage status of the service which has been orchestrated and has become available.
  • the monitoring result of the monitoring unit 17 can be transmitted to the configuration information management unit 13.
  • the configuration information management unit 13 can collect information about physical nodes and virtual nodes based on the monitoring result of the monitoring unit 17.
  • the processing executed by the ICT resource management device 1 of this embodiment will be described with reference to FIG. This process is started, for example, when there is a request for an operation such as a configuration change from the service provider terminal 2 or the like.
  • the request acquisition unit 11 outputs order information indicating operations such as configuration change to the blueprint creation unit 12 (step S1).
  • the blueprint creation unit 12 requests the configuration information from the configuration information management unit 13 (step S2).
  • the configuration information management unit 13 outputs the configuration information stored in the configuration information DB 21, specifically, the physical layer configuration information 21a and the virtual layer configuration information 21b to the blueprint creation unit 12 (step S3). ..
  • the blueprint creation unit 12 requests the mapping information 22 from the layer mapping unit 14 (step S4).
  • the layer mapping unit 14 outputs the mapping information 22 to the blueprint creating unit 12 (step S5).
  • the blueprint creating unit 12 creates the blueprint 24 for the order information based on the configuration information and the mapping information (step S6). At this time, the blueprint creating unit 12 selects a catalog required for the operation from the catalog group 23 according to the order information, and acquires the parameters to be input to the selected catalog from the order information or the distribution system 100.
  • the blueprint creation unit 12 sends the created blueprint 24 to the service provider terminal 2 or the like that sent the order information via the request acquisition unit 11, and requests confirmation of the blueprint 24 (step S7). If there is no problem in confirming the blueprint 24, the request acquisition unit 11 transmits information indicating approval from the service provider terminal 2 or the like to the blueprint creation unit 12 (step S8). Steps S1 to S8 constitute an infrastructure design process in the entire process executed by the ICT resource management device 1. Note that steps S7 and S8 may be omitted in order to speed up the process.
  • the blueprint creation unit 12 creates a script for executing orchestration based on the approved blueprint 24 (step S9). Techniques for creating scripts are well known, and detailed description thereof will be omitted.
  • the blueprint creation unit 12 outputs the created script to the workflow execution unit 15 (step S10). Steps S9 to S10 constitute a script creation process in the entire process executed by the ICT resource management device 1.
  • the workflow execution unit 15 interprets the script acquired from the blueprint creation unit 12 (step S11). Techniques for interpreting scripts are well known, and detailed description thereof will be omitted. Next, the workflow execution unit 15 instructs the API adapter unit 16 for each program that can be operated through the API (step S12) and executes the process.
  • the API adapter unit 16 When the execution of the process is completed, the API adapter unit 16 notifies the workflow execution unit 15 of the completion of the process execution (step S13). Next, the workflow execution unit 15 notifies the blueprint creation unit 12 of the completion of the process execution (step S14).
  • the completion of the process execution means the completion of the orchestration execution from the ICT resource management device 1 to the virtual layer, and the service after the configuration change is available. Steps S11 to S14 constitute an orchestration process in the entire process executed by the ICT resource management device 1.
  • the monitoring unit 17 starts monitoring the physical nodes on the physical layer and the virtual nodes on the virtual layer.
  • the monitoring unit 17 notifies the configuration information management unit 13 of the information collected by the monitoring (step S15).
  • the configuration information management unit 13 notifies the layer mapping unit 14 of the information collected from the monitoring unit 17 (step S16).
  • Steps S15 to S16 constitute a monitoring process in the entire process executed by the ICT resource management device 1.
  • the configuration information management unit 13 generates configuration information from the information collected by the monitoring unit 17, and stores it in the configuration information DB 21.
  • the layer mapping unit 14 also generates mapping information 22 from the information collected by the monitoring unit 17 via the configuration information management unit 13. The generated configuration information and mapping information 22 is used to create a new blueprint.
  • the ICT resource management device 1 can hold the configuration information and the mapping information 22 in the latest state, so that the blueprint is created, the orchestration is executed, and the operation is performed without human intervention. Can be automated.
  • the workflow of initial deployment can be defined using, for example, MSA (Micro Service Architecture), and can be designed in three layers of a service layer, a baseline, and a micro service.
  • MSA Micro Service Architecture
  • the service layer registers each process of the workflow of initial deployment in a linked state in a predetermined order.
  • the workflow of initial deployment is as follows: catalog/configuration information acquisition A1, surplus resource acquisition/accommodation destination setting A2, VM creation A3, LB/FW group addition A4, container host registration A5, container image expansion A6,
  • the process can be divided into a process of state confirmation A7, which is performed in this order.
  • the catalog/configuration information acquisition A1 is a step showing selection of a catalog from the catalog group 23 and acquisition of configuration information by the configuration information management unit 13.
  • the surplus resource acquisition/accommodation destination setting A2 is a step of acquiring the surplus resources of each ICT resource and setting the physical node that is the accommodation destination of the created VM.
  • the VM creation A3 is a step of creating a VM in which an application provided for a service is arranged.
  • the LB/FW group addition A4 is a step showing that a load balancer group and a firewall group are added on the NW.
  • the container host registration A5 is a step showing the environment construction for executing the container used by the created VM.
  • a host machine for operating the container is additionally created, and the added host machine is registered in the controller that manages the container.
  • the container image expansion A6 is a step of arranging a containerized application on a host machine for operating the container.
  • the containerized application is in the form of an image file, and is placed in the host machine that indicates the image.
  • the state confirmation A7 is a step of confirming the state of the created VM as the final stage of the initial deployment.
  • the baseline registers the parts of each process in the service layer.
  • the registered parts can be configured as a catalog.
  • Each process shown in the service layer can be realized as a combination of parts shown in the baseline.
  • a surplus resource acquisition B1, VM creation B2, LB/FW group addition B3, container host registration B4, container image expansion B5, and status confirmation B6 are registered in the baseline of initial deployment.
  • the surplus resource acquisition B1 registers the parts of the surplus resource acquisition/accommodation destination setting A2.
  • the components registered in the surplus resource acquisition B1 include, for example, [1] host and VM list acquisition, [2] VM allocation specification acquisition, and [3] host allocation specification aggregation, but are not limited to these.
  • VM creation B2 registers the parts of VM creation A3.
  • the parts registered in the VM creation B2 are, for example, [1] acquisition of all VM names, [2] VM name determination, [3] IP payout, [4] VM clone, [5] SSH (Secure Shell) individual setting , But is not limited to these.
  • LB/FW group addition B3 registers the parts of LB/FW group addition A4. Parts registered in the LB/FW group addition B3 include, for example, [1] LB group addition and [2] FW group addition, but are not limited to these.
  • the container host registration B4 registers the parts of the container host registration A5.
  • Parts registered in the container host registration B4 include, for example, [1] token acquisition and [2] host addition, but are not limited to these.
  • the container image expansion B5 registers the parts of the container image expansion A6.
  • the component registered in the container image development B5 includes, for example, [1] image development, and SSH individual setting can be prepared as necessary, but the component is not limited to these.
  • Status check B6 registers the parts of status check A7.
  • Parts registered in the status confirmation B6 include, for example, the [1] Ping test, but are not limited to these.
  • Microservice registers the function to execute the components registered in the baseline. As shown in FIG. 7, [host] information acquisition C1, [VM] information acquisition C2, [host] information acquisition C3, [NSX] IP payout C4, [VM] clone C5, [ VM] SSH execution C6, [NSX] LB addition C7, [NSX] FW addition C8, [Rancher] token acquisition C9, [VM] SSH execution C10, [Rancher] container creation C11, [VM] Ping test C12 are registered. ing.
  • the [host] information acquisition C1 acquires the information of the management item of the physical node (for example, see FIG. 3), and realizes the [1] host and VM list acquisition of the surplus resource acquisition B1.
  • the [VM] information acquisition C2 acquires the information of the management item (for example, see FIG. 4) of the virtual node, and realizes the [2] VM allocation specification acquisition of the surplus resource acquisition B1.
  • the [host] information acquisition C3 acquires information on the management item of the physical node (for example, see FIG. 3), and realizes [1] acquisition of all VM names of the VM creation B2.
  • the [NSX] IP payout C4 pays out the IP address of the VM and realizes [3] IP payout of the VM creation B2.
  • the [VM] clone C5 performs the VM duplication process to realize the [4] VM clone of the VM creation B2.
  • [VM] SSH execution C6 realizes the [5] SSH (Secure Shell) individual setting of VM creation B2 by logging in to the VM and executing the command.
  • [NSX] LB addition C7 adds LB on the network and realizes [1] LB group addition of LB/FW group addition B3.
  • the [NSX]FW addition C8 adds the FW on the network and realizes the [2]FW group addition of the LB/FW group addition B3.
  • [Rancher] token acquisition C9 creates a container that acquires the authority to perform processing, and realizes [1] token acquisition of container host registration B4.
  • the [VM] SSH execution C10 logs in to the VM and executes the command to realize [2] host addition of the container host registration B4.
  • Container creation C11 creates a containerized application and realizes [1] image expansion of container image expansion B5.
  • the [VM] Ping test C12 confirms the communication and realizes the [1] Ping test of the state confirmation B6.
  • Each process (A1 to A7) shown in the service layer corresponds to the catalog, and the parts registered in the baseline correspond to the catalog part.
  • the various functions (C1 to 12) shown in the microservice can input parameters for the corresponding parts registered in the baseline.
  • the workflow execution unit 15 creates a VM based on the blueprint 24 created in advance and executes container image expansion. In this way, the workflow execution unit 15 can connect the processes that are originally separate and can automate the process that requires parameters for each process.
  • the association between the physical node and the virtual node becomes clear, and the virtual node for the configuration change can be specified without manual intervention. Therefore, automation of operation can be realized. Therefore, it is possible to automate the operation of the distributed system and reduce the operating cost of the distributed system to which the virtualization technology is applied.
  • the blueprint 24 so as to include the collection of catalogs and parameters (see FIG. 5 )
  • the configuration information and the mapping information can be held in the latest state by providing the monitoring unit 17, it is possible to create a blueprint, perform orchestration, and contribute to automation of operations without human intervention. You can Further, the ICT resource management program described later can facilitate the construction of the ICT resource management device.
  • program It is also possible to create a program in which the processing executed by the ICT resource management device 1 according to the above-described embodiment is described in a computer-executable language. In this case, the computer executes the program to obtain the same effect as that of the above embodiment. Furthermore, the same processing as that in the above-described embodiment may be realized by recording such a program in a computer-readable recording medium and causing the computer to read and execute the program recorded in the recording medium.
  • An example of a computer that executes an ICT resource management program that realizes the same function as the ICT resource management device 1 will be described below.
  • FIG. 8 is a diagram showing a computer that executes an ICT resource management program.
  • the computer 1000 has, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These units are connected by a bus 1080.
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012.
  • the ROM 1011 stores, for example, a boot program such as BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • the hard disk drive interface 1030 is connected to the hard disk drive 1090.
  • the disk drive interface 1040 is connected to the disk drive 1100.
  • a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100.
  • a mouse 1110 and a keyboard 1120 are connected to the serial port interface 1050, for example.
  • a display 1130 is connected to the video adapter 1060, for example.
  • the memory 1010, the hard disk drive 1090, the disk drive 1100, and the storage medium inserted into the disk drive 1100 are specific hardware resources of the storage unit included in the ICT resource management device 1.
  • the hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094.
  • Each table described in the above embodiment is stored in, for example, the hard disk drive 1090 or the memory 1010.
  • the ICT resource management program is stored in the hard disk drive 1090 as a program module in which a command executed by the computer 1000 is described, for example.
  • the program module in which each process executed by the ICT resource management device 1 described in the above embodiment is described is stored in the hard disk drive 1090.
  • the data used for information processing by the ICT resource management program is stored as program data in, for example, the hard disk drive 1090. Then, the CPU 1020 reads the program module 1093 and the program data 1094 stored in the hard disk drive 1090 into the RAM 1012 as necessary, and executes the above-described procedures.
  • the program module 1093 and the program data 1094 related to the ICT resource management program are not limited to being stored in the hard disk drive 1090, and may be stored in a removable storage medium, for example, by the CPU 1020 via the disk drive 1100 or the like. It may be read.
  • the program module 1093 and the program data 1094 related to the ICT resource management program are stored in another computer connected via a network such as a LAN (Local Area Network) or a WAN (Wide Area Network), and the network interface 1070 It may be read by the CPU 1020 via the.
  • the configuration information management unit 13 can manage the position information of the physical node.
  • the configuration information management unit 13 can manage information regarding a user who uses the device 5 connected to the edge 4 as a physical node, or information regarding a tenant of the user. Therefore, the configuration information managed as the physical layer configuration information 21a can be the configuration information for each user or each tenant.
  • the layer mapping unit 14 maps the physical layer and the virtual layer, the configuration information in units of users or units of tenants can be configuration information managed as the virtual layer configuration information 21b.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Geometry (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Computational Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Control Of Heat Treatment Processes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

ＩＣＴ資源となる、物理ノードおよび仮想ノードを管理するＩＣＴ資源管理装置（１）は、物理レイヤ構成情報（２１ａ）、および、仮想レイヤ構成情報（２１ｂ）を管理する構成情報管理部（１３）と、物理レイヤおよび仮想レイヤとのマッピングを行うレイヤマッピング部（１４）と、構成変更の要求に対して、物理レイヤ構成情報（２１ａ）、仮想レイヤ構成情報（２１ｂ）、および、マッピングの結果であるマッピング情報（２２）に基づいて、構成変更に必要なインフラの設計情報となるブループリント（２４）を作成するブループリント作成部（１２）と、ブループリント（２４）に基づいて、ＡＰＩを通じ操作することができるプログラムにアクセスして実行することで、仮想レイヤに対するオーケストレーションを実行するオーケストレータ部（１５，１６）と、を備える。

Description

ＩＣＴ資源管理装置、ＩＣＴ資源管理方法、および、ＩＣＴ資源管理プログラム
　本発明は、ＩＣＴ（Information and Communication Technology）資源管理装置、ＩＣＴ資源管理方法、および、ＩＣＴ資源管理プログラムに関する。
　近年、サービス事業者がサービスをエンドユーザに提供するための技術開発が盛んに行われている。例えば、特許文献１には、「ユーザに通信を提供する端末機からの通信サービス利用のためのオーダ要求に応じて、卸サービス事業者毎に通信サービスＡＰＩで公開される各々異なる１つの通信サービスを１又は複数一括して提供する事業者間一括サービス構築装置であって、通信の卸サービスの仕様が記述されたカタログと、各種の通信サービスの連携を定めた連携ルールとを保持し、前記端末機から複数の通信サービス利用のオーダ要求があった場合に、前記保持された前記カタログ及び前記連携ルールに基づき、当該オーダ要求された複数の通信サービスに対応する前記通信サービスＡＰＩを一括に連携させて連携サービスを構築し、この構築された連携サービスを前記端末機へ提供する一括構築機能部を備えることを特徴とする事業者間一括サービス構築装置」について開示されている。
特開２０１８－３２８９７号公報（請求項１）
　また、サービスが提供されるシステムとして、例えば、仮想化技術が適用される分散システムがある。分散システムは、例えば、地理的に異なる場所に配置される複数のデータセンタが備える装置群から構築することができるが、これに限らない。仮想化技術が適用される分散システムは、分散システムが備える物理ノード（例：計算機、ルータ、センサ）の集合体となる物理レイヤと、物理ノード上に構成されて稼働する仮想ノードの集合体となる仮想レイヤとを備える。仮想化技術が適用される分散システムでは、物理レイヤに対する構成管理と、仮想レイヤに対する構成管理との２種類の構成管理が行われる。また、分散システムのエンジニアは、物理レイヤの設計と、仮想レイヤの設計との両方を行う。
　例えば、物理ノードに接続しているデバイス（例：ＩｏＴ（Internet of Things）機器）でサービスが利用可能となるように、仮想ノードに新たなアプリケーションを配置するといった構成変更を行う場合がある。この場合、仮想化技術によって物理レイヤが抽象化されているため、アプリケーションを配置する仮想ノードを特定することが直ちにできない。従来では、エンジニアが物理レイヤと仮想レイヤとを照合して仮想ノードを特定するという手法をとっていた。しかし、このような手法は、人手を介するため、分散システムのオペレーションの自動化を妨げてしまい、分散システムの運用コストの増大を招くという問題がある。
　このような背景に鑑みて、本発明は、分散システムのオペレーションを自動化し、仮想化技術が適用される分散システムの運用コストを低減することを課題とする。
　前記した課題を解決するため、請求項１に記載の発明は、ＩＣＴ資源となる、物理ノードおよび仮想ノードを管理するＩＣＴ資源管理装置であって、物理レイヤ上の前記物理ノードに関する構成情報である物理レイヤ構成情報、および、仮想レイヤ上の前記仮想ノードに関する構成情報である仮想レイヤ構成情報を管理する構成情報管理部と、前記物理レイヤおよび前記仮想レイヤとのマッピングを行うレイヤマッピング部と、外部装置からの構成変更の要求に対して、前記物理レイヤ構成情報、前記仮想レイヤ構成情報、および、前記マッピングの結果であるマッピング情報に基づいて、前記構成変更に必要なインフラの設計情報となるブループリントを作成するブループリント作成部と、前記ブループリントに基づいて、ＡＰＩを通じ操作することができるプログラムにアクセスして実行することで、前記仮想レイヤに対するオーケストレーションを実行するオーケストレータ部と、を備える、ことを特徴とする。
　また、請求項４に記載の発明は、ＩＣＴ資源となる、物理ノードおよび仮想ノードを管理するＩＣＴ資源管理装置におけるＩＣＴ資源管理方法であって、前記ＩＣＴ資源管理装置は、物理レイヤ上の前記物理ノードに関する構成情報である物理レイヤ構成情報、および、仮想レイヤ上の前記仮想ノードに関する構成情報である仮想レイヤ構成情報を収集するステップと、前記物理レイヤおよび前記仮想レイヤとのマッピングを行うステップと、外部装置からの構成変更の要求に対して、前記物理レイヤ構成情報、前記仮想レイヤ構成情報、および、前記マッピングの結果であるマッピング情報に基づいて、前記構成変更に必要なインフラの設計情報となるブループリントを作成するステップと、前記ブループリントに基づいて、ＡＰＩを通じ操作することができるプログラムにアクセスして実行することで、前記仮想レイヤに対するオーケストレーションを実行するステップと、を実行する、ことを特徴とする。
　請求項１，４に記載の発明によれば、物理レイヤと仮想レイヤとのマッピングによって、物理ノードと仮想ノードとの紐付けが明らかとなり、構成変更に対する仮想ノードを、人手を介することなく特定することができる。このため、オペレーションの自動化を実現することができる。
　したがって、分散システムのオペレーションを自動化し、仮想化技術が適用される分散システムの運用コストを低減することができる。
　また、請求項２に記載の発明は、請求項１に記載のＩＣＴ資源管理装置であって、前記ブループリントは、サービスの提供に供する工程を示すカタログの集合体と、前記カタログに対するインプット情報となるパラメータとを含む、ことを特徴とする。
　請求項２に記載の発明によれば、オーケストレーションを実行するためのワークフローを容易に構成することができる。
　また、請求項３に記載の発明は、請求項１または請求項２に記載のＩＣＴ資源管理装置であって、前記物理ノードおよび前記仮想ノードを監視する監視部、をさらに備え、前記構成情報管理部は、前記監視部の監視によって収集した情報から、前記物理レイヤ構成情報および前記仮想レイヤ構成情報を生成し、前記レイヤマッピング部は、前記監視部の監視によって収集した情報から、前記マッピング情報を生成する、ことを特徴とする。
　請求項３に記載の発明によれば、構成情報およびマッピング情報を最新状態で保持することができるため、人手を介することなくブループリントを作成し、オーケストレーションを実行し、オペレーションの自動化に寄与することができる。
　また、請求項５に記載の発明は、コンピュータを、請求項１から請求項３の何れか１項に記載のＩＣＴ資源管理装置として機能させるためのＩＣＴ資源管理プログラムである。
　請求項５に記載の発明によれば、ＩＣＴ資源管理装置の構築を容易にすることができる。
　本発明によれば、分散システムのオペレーションを自動化し、仮想化技術が適用される分散システムの運用コストを低減することができる。
本実施形態のＩＣＴ資源管理装置を含む分散システムの機能構成図の例である。 ＩＣＴ資源管理装置の機能構成図の例である。 物理レイヤ構成情報のデータ構造図の例である。 仮想レイヤ構成情報のデータ構造図の例である。 ブループリントの例の説明図である。 本実施形態で実行される処理を示すシーケンスの例である。 初期デプロイの動作例の説明図である。 本実施形態で実行される処理のプログラムを実行するコンピュータを示す図である。
　以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）について説明する。
≪構成≫
　図１に示すように、本実施形態のＩＣＴ資源管理装置１を含む分散システム１００は、仮想化技術が適用されるシステムであり、ＩＣＴ資源管理装置１と、サービス事業者端末２と、サーバ３と、エッジ４と、デバイス５とを備える。また、分散システム１００は、物理ノードの集合体となる物理レイヤと、物理ノード上に構成されて稼働する仮想ノードの集合体となる仮想レイヤとを管理することができる。サーバ３と、エッジ４と、デバイス５は、物理レイヤを構成する物理ノードとなる。また、図１に示す、仮想レイヤ上に配置されているＶＭ（Virtual Machine）７は、サーバ３またはエッジ４を仮想化した仮想ノードである。
　ＩＣＴ資源管理装置１は、物理ノードおよび仮想ノードをＩＣＴ資源として管理する。
　サービス事業者端末２は、初期デプロイやスケール可変などの構成変更を要求する端末である。サービス事業者端末２は、当該要求をＡＰＩ（Application Programming Interface）を通じて行う。当該ＡＰＩは、ＩＣＴ資源管理装置１とサービス事業者端末２との間のNorthbound APIである。また、サービス事業者端末２は、サービス事業者等が用いる。
　サーバ３は、サービスの提供に係るプロセスを実行する計算機である。図１に示すサーバ３は、クラウド基盤Ａに配置されており、クラウドサービス用のプロセスを実行する。サーバ３には、サービスの提供に係るプロセスを実行するための１または複数のアプリ（アプリケーションの略）６が配置される。
　エッジ４は、ＮＷ（ネットワーク）上に配置される中継装置であり、例えば、ルータ、ブリッジ、ゲートウェイが該当する。エッジ４には、サービスの提供に係るプロセスを実行するための１または複数のアプリ６が配置される。サーバ３およびエッジ４は、通信可能に接続されている。
　デバイス５は、エンドユーザがサービスを利用する機器であり、例えば、ＩｏＴ機器が該当する。デバイス５は、エッジ４に接続することで、サービスを利用することができる。
　ＩＣＴ資源管理装置１は、物理ノードおよび仮想ノードに関する情報収集をすることができる。また、ＩＣＴ資源管理装置１は、収集した情報を用いて、物理レイヤと仮想レイヤとのマッピングを行うことができる（図１中、破線両矢印参照）。
　また、ＩＣＴ資源管理装置１は、仮想レイヤに対してオーケストレーションを実行することができる。具体的には、サービスのデプロイや、ＶＭ７へのリソース割り当てをすることができる。
（ＩＣＴ資源管理装置１の詳細）
　図２に示すように、ＩＣＴ資源管理装置１は、要求取得部１１と、ブループリント作成部１２と、構成情報管理部１３と、レイヤマッピング部１４と、ワークフロー実行部１５と、ＡＰＩアダプタ部１６と、監視部１７といった機能部を備える。また、ＩＣＴ資源管理装置１は、構成情報ＤＢ２１と、マッピング情報２２と、カタログ群２３と、ブループリント２４を記憶部で記憶する。ＩＣＴ資源管理装置１が備える前記記憶部は、例えば、ＩＣＴ資源管理装置１の内部にあってもよいし、ＩＣＴ資源管理装置１の外部の装置にあってもよい。
［要求取得部１１］
　要求取得部１１は、サービス事業者端末２からの構成変更の要求を取得する。要求取得部１１が取得した要求を「オーダ情報」と呼ぶ場合がある。また、構成変更の要求は、サービス事業者端末２に限らず、例えば、分散システム１００の保守者の端末からも行うことができる。サービス事業者端末２、および、保守者の端末は、外部装置の例となる。
［ブループリント作成部１２］
　ブループリント作成部１２は、要求取得部１１が取得したオーダ情報に対応するブループリント２４を作成する。ブループリント２４は、要求された構成変更に必要となるインフラの設計情報である。インフラは、サービスの動作環境の構成要素を示し、例えば、ＩＣＴ資源そのもの、ＩＣＴ資源の設定情報（例：ＶＭ名、ＩＰアドレス、ホスト名）や割当リソース、ＮＷ上に設定されるＬＢ（ロードバランサ）、ＦＷ（ファイアウォール）、コンテナといったさまざまな要素を指す。
［構成情報管理部１３］
　構成情報管理部１３は、ＩＣＴ資源に関する情報を構成情報として管理する。構成情報管理部１３は、例えば、リソース情報収集のＡＰＩにアクセスすることで、物理ノードおよび仮想ノードに関する情報を収集することができる。リソース情報収集のＡＰＩとは、オーケストレーション対象がそれぞれに用意するリソース情報を提供するためのＡＰＩである。リソース情報収集のＡＰＩは、ＩＣＴ資源管理装置１とオーケストレーション対象との間のsouthbound APIである。収集する情報は、例えば、ＳＮＭＰ（Simple Network Management Protocol）によるＭＩＢ（Management Information Base）とすることができるが、これに限定されない。構成情報管理部１３が管理する構成情報は、構成情報ＤＢ２１に格納されており、物理レイヤ構成情報２１ａと、仮想レイヤ構成情報２１ｂに分類される。
　オーケストレーション対象は、物理ノードおよび仮想ノードを含むが、これらに限定されない。オーケストレーション対象が提供するインタフェースは、例えば、当該オーケストレーション対象を制御するコントローラ（図示せず）が提供することもできるし、物理ノードおよび仮想ノードの各々が提供することもできる。
　物理レイヤ構成情報２１ａは、物理レイヤ上の物理ノードに関する構成情報である。図３に示すように、物理レイヤ構成情報２１ａは、例えば、「ノードＩＤ」、「状態」、「ホスト名」、「ＩＰアドレス」、「ＶＭＩＤ」、「利用サービス」、「利用者」といった管理項目を有し、物理ノードごとに各管理項目の値が格納されている。
　「ノードＩＤ」の管理項目には、対象の物理ノードの識別子が格納される。
　「状態」の管理項目には、対象の物理ノードの稼働状態が格納される（正常の場合「ＯＫ」、故障の場合「ＮＧ」）。
　「ホスト名」の管理項目には、対象の物理ノードのホスト名が格納される。
　「ＩＰアドレス」の管理項目には、対象の物理ノードに割り当てられたＩＰアドレスが格納される。
　「ＶＭＩＤ」の管理項目には、対象の物理ノード上で稼働するＶＭの識別子が格納される。
　「利用サービス」の管理項目には、対象の物理ノードで利用可能なサービスの識別子が格納される。利用サービスは、例えば、クラウドサービス、エッジコンピューティングサービスがあるが、これらに限定されない。また、利用サービスには、複数の物理ノードで同一のサービスを提供可能となるサービスを含めることができる。
　「利用者」の管理項目には、対応の「利用サービス」に示すサービスを利用する利用者の識別子が格納される。利用者は、例えば、法人であってもよいし、個人であってもよい。また、例えば、該当の物理ノードがエッジ装置であった場合、当該エッジ装置の所有者のみを利用者とすることができる。
　図３に示す物理レイヤ構成情報２１ａの管理項目は、一例であり、より多く設定することができる。例えば、物理レイヤ構成情報２１ａの管理項目として、対象の物理ノード上で稼働するＶＭのメモリサイズ、ＣＰＵ周波数、電源状態、ＶＭ名を設定することができる。
　また、物理レイヤ構成情報２１ａの管理項目として、対象の物理ノードに用いるリソースプールの名称、ＩＤを設定することができる。
　また、物理レイヤ構成情報２１ａの管理項目として、対象の物理ノードが配置されるネットワークの型、ＩＤ、名称を設定することができる。
　また、物理レイヤ構成情報２１ａの管理項目として、対象の物理ノードが用いるフォルダのＩＤ、型、名称を設定することができる。
　また、物理レイヤ構成情報２１ａの管理項目として、対象の物理ノードが使用するデータストアの記憶容量、ＩＤ、型、名称を設定することができる。
　また、物理レイヤ構成情報２１ａの管理項目として、対象の物理ノードを制御するデータセンタのＩＤ、名称を設定することができる。
　また、物理レイヤ構成情報２１ａの管理項目として、対象の物理ノードにアクセスするユーザの認証情報となるユーザ名、パスワードを設定することができる。
　図２に戻って、仮想レイヤ構成情報２１ｂは、仮想レイヤ上の仮想ノードに関する構成情報である。図４に示すように、仮想レイヤ構成情報２１ｂは、例えば、「ノードＩＤ」、「状態」、「ＶＭ名」、「ＩＰアドレス」、「物理デバイスＩＤ」といった管理項目を有し、仮想ノードごとに各管理項目の値が格納されている。
　「ノードＩＤ」の管理項目には、対象の仮想ノードの識別子が格納される。
　「状態」の管理項目には、対象の稼働ノードの稼働状態が格納される（正常の場合「ＯＫ」、故障の場合「ＮＧ」）。
　「ＶＭ名」の管理項目には、対象の仮想ノードの名称が格納される。
　「ＩＰアドレス」の管理項目には、対象の仮想ノードに割り当てられたＩＰアドレスが格納される。
　「物理デバイスＩＤ」の管理項目には、対象の仮想ノードが配置される物理ノードの識別子が格納される。
　図４に示す仮想レイヤ構成情報２１ｂの管理項目は、一例であり、より多く設定することができる。例えば、仮想レイヤ構成情報２１ｂの管理項目として、対象の仮想ノードのＩＤ情報となるＶＭＩＤを設定することができる。
　また、仮想レイヤ構成情報２１ｂの管理項目として、対象の仮想ノードのリソースとなるメモリサイズ、ＣＰＵ周波数を設定することができる。
　また、仮想レイヤ構成情報２１ｂの管理項目として、対象の仮想ノードの電源状態を設定することができる。
　また、仮想レイヤ構成情報２１ｂの管理項目として、対象の仮想ノードにアクセスするユーザの認証情報となるユーザ名、パスワードを設定することができる。
　また、仮想レイヤ構成情報２１ｂの管理項目として、対象の仮想ノードが使用するゲートウェイ、ＶＸＬＡＮ（Virtual eXtensible Local Area Network）、スタティックルートを設定することができる。
　また、仮想レイヤ構成情報２１ｂの管理項目として、対象の仮想ノードが配置される物理ノードのホスト名を設定することができる。
　また、仮想レイヤ構成情報２１ｂの管理項目として、対象の仮想ノードを生成するハイパバイザに関する情報を設定することができる。
　また、仮想レイヤ構成情報２１ｂに設定される管理項目として、コンテナアプリケーションの管理項目を設定することができる。例えば、仮想レイヤ構成情報２１ｂの管理項目として、対象の仮想ノードが用いるコンテナに対して登録されるコンテナホストのホスト名、ラベル、状態、アカウントＩＤを設定することができる。
　また、仮想レイヤ構成情報２１ｂの管理項目として、対象の仮想ノードが用いるコンテナで提供されるサービスのＩＤ、名称、状態、スケール（利用サーバの台数）を設定することができる。
　また、仮想レイヤ構成情報２１ｂの管理項目として、対象の仮想ノードが用いるコンテナで提供されるストレージ装置のボリュームのマウント、ＩＤ（RancherNFS（Network File System）利用時のみ）、イメージＩＤを設定することができる。
　また、仮想レイヤ構成情報２１ｂの管理項目として、対象の仮想ノードが用いるコンテナで提供されるストレージ装置のスタックのグループ、ヘルス状態、スタックＩＤ、利用されるサービスのＩＤを設定することができる。
［レイヤマッピング部１４］
　図２に戻って、レイヤマッピング部１４は、物理レイヤと仮想レイヤとのマッピングを行う。具体的には、レイヤマッピング部１４は、構成情報管理部１３が管理する構成情報に基づいて、仮想レイヤ上の仮想ノードが物理レイヤ上のいずれの物理ノード（または当該物理ノードに配置されたアプリ６）に紐付けられているかを判定する。ＩＣＴ資源管理装置１は、レイヤマッピング部１４による、物理ノードと仮想ノードとの紐付けの判定結果を、マッピング情報２２として保存する。例えば、レイヤマッピング部１４は、物理レイヤ構成情報２１ａ（図３）の「ＶＭＩＤ」の管理項目と、仮想レイヤ構成情報２１ｂ（図４）の「物理デバイスＩＤ」の管理項目を参照することで、物理ノードと仮想ノードとの紐付けを判定することができる。
　ここで、ブループリント２４の詳細を、図５を参照して説明する。図５は、初期デプロイのブループリントの説明図である。図５に示すように、ブループリント２４は、サービステンプレートとパラメータとの組として構成することができる。サービステンプレートは、カタログの集合体とすることができる。カタログは、サービスの提供に供する工程の雛型であり、ＩＣＴ資源管理装置１が記憶するカタログ群２３の要素である。カタログ自体は周知であり、詳細な説明は省略する。また、パラメータは、各カタログに対するインプット情報である。
　図５に示す初期デプロイのブループリント２４の場合、要求取得部１１が取得したオーダ情報は、初期デプロイに関するオーダ情報となる。初期デプロイの場合、ブループリント作成部１２は、例えば、カタログ群２３から、ＶＭ作成用のカタログ、ＮＷ設定用のカタログ、および、コンテナ設定用のカタログを選択し、サービステンプレートを構成することができる。
　ＶＭ作成用のカタログに入力するパラメータは、例えば、作成するＶＭの個数および種類である。図５では、Ｗｅｂサーバとして機能するＶＭを３つ、および、ＡＰサーバ（アプリケーションサーバ）として機能するＶＭを２つの計５つのＶＭを指定するパラメータがＶＭ作成用のカタログに入力される。ＶＭ作成用のカタログに入力するパラメータは、例えば、サービス事業者端末２が入力することができる。
　ＮＷ設定用のカタログに入力するパラメータは、例えば、ＩＰアドレスの割り当て（ＩＰ割り当て）である。図５では、作成されるＶＭに割り当てられるＩＰアドレスを指定するパラメータがＮＷ設定用のカタログに入力される。ＮＷ設定用のカタログに入力するパラメータは、例えば、分散システム１００から取得することができる。
　コンテナ設定用のカタログに入力するパラメータは、例えば、作成されるＶＭが用いるコンテナの設定方式である。図５では、Rancherによるコピー実行という設定方式を示すパラメータがコンテナ設定用のカタログに入力される。コンテナ設定用のカタログに入力するパラメータは、例えば、サービス事業者端末２が入力することができる。
　ブループリント作成部１２は、要求取得部１１が取得したオーダ情報が示すオペレーションに応じて、カタログ群２３から、必要となるカタログを選択し、サービステンプレートを構成する。また、ブループリント作成部１２は、選択したカタログに入力されるパラメータを、オーダ情報や分散システム１００から取得することができる。つまり、ブループリント作成部１２は、選択したカタログに入力されるパラメータを、オーダ情報を送信したサービス事業者端末２などに要求し、当該要求の応答となるオーダ情報を改めて受信することで、オーダ情報からパラメータを取得することができる。また、ＩＰアドレスの払い出しなどの、分散システム１００自身でパラメータ取得可能となる場合には、ブループリント作成部１２は、選択したカタログに入力されるパラメータを、分散システム１００から取得することができる。
　ブループリント作成部１２は、ブループリント２４を作成する際、構成情報管理部１３が管理する構成情報、および、レイヤマッピング部１４が保存するマッピング情報２２を参照する。つまり、ブループリント作成部１２は、物理レイヤ構成情報２１ａ、仮想レイヤ構成情報２１ｂ、および、マッピング情報２２から決定される、物理ノードおよび仮想ノードの現在の状態と、オーダ情報が示す、サービス事業者等の要求とを照合して、ブループリント２４を作成することができる。
［ワークフロー実行部１５］
　ワークフロー実行部１５は、ブループリント作成部１２が作成したブループリント２４に従って、ワークフローを実行する。ワークフローは、ブループリント２４に含まれるカタログが示す工程を、順序を定めて連結したものである。図５に示す初期デプロイのブループリント２４に対しては、初期デプロイのワークフローは、ＶＭ作成→ＮＷ設定→コンテナ設定、のように順序を定めて連結したものとなる。ワークフロー実行部１５がワークフローを実行することで、オーケストレーションが実行され、ＩＣＴ資源にリソースが割り当てられる。
［ＡＰＩアダプタ部１６］
　ＡＰＩアダプタ部１６は、ワークフローを実行するワークフロー実行部１５からの命令に対し、ＡＰＩを通じ操作することができるプログラムにアクセスするためのインタフェースである。当該ＡＰＩは、ＡＰＩアダプタ部１６（またはＡＰＩアダプタ部１６を備えるＩＣＴ資源管理装置１）とオーケストレーション対象との間のsouthbound APIである。ＡＰＩアダプタ部１６は、オーケストレーション対象ごとにインタフェース接続することができる。ＡＰＩアダプタ部１６は、ＡＰＩを通じ操作することができるプログラムごとに複数用意することができる。ワークフロー実行部１５は、ＡＰＩを通じ操作することができるプログラムを実行することで、ワークフローを実行することができる。
　ワークフロー実行部１５およびＡＰＩアダプタ部１６の組合せは、オーケストレーションを実行するオーケストレータ部として機能する。
［監視部１７］
　監視部１７は、物理レイヤ上の物理ノード、および、仮想レイヤ上の仮想ノードを、例えば、ＳＮＭＰによって監視する。監視部１７による監視結果は、オーケストレーションが実行され、利用可能となったサービスの使用状況を示している。監視部１７による監視結果は、構成情報管理部１３に送信することができる。構成情報管理部１３は、監視部１７の監視結果で、物理ノードおよび仮想ノードに関する情報を収集することができる。
≪処理≫
　本実施形態のＩＣＴ資源管理装置１が実行する処理を、図６を参照して説明する。この処理は、例えば、サービス事業者端末２などから構成変更等のオペレーションの要求があった場合に開始する。
　まず、要求取得部１１は、構成変更等のオペレーションが示されたオーダ情報をブループリント作成部１２に出力する（ステップＳ１）。次に、ブループリント作成部１２は、構成情報管理部１３に対し、構成情報を要求する（ステップＳ２）。次に、構成情報管理部１３は、構成情報ＤＢ２１に格納されている構成情報、具体的には、物理レイヤ構成情報２１ａおよび仮想レイヤ構成情報２１ｂをブループリント作成部１２に出力する（ステップＳ３）。
　次に、ブループリント作成部１２は、レイヤマッピング部１４に対し、マッピング情報２２を要求する（ステップＳ４）。次に、レイヤマッピング部１４は、マッピング情報２２をブループリント作成部１２に出力する（ステップＳ５）。
　次に、ブループリント作成部１２は、オーダ情報に対して、構成情報、および、マッピング情報に基づいてブループリント２４を作成する（ステップＳ６）。このとき、ブループリント作成部１２は、オーダ情報に応じて、カタログ群２３からオペレーションに必要となるカタログを選択するとともに、オーダ情報または分散システム１００から、選択したカタログに入力するパラメータを取得する。
　次に、ブループリント作成部１２は、作成したブループリント２４を、要求取得部１１を介して、オーダ情報を送信したサービス事業者端末２等に送信し、ブループリント２４の確認依頼をする（ステップＳ７）。ブループリント２４の確認に問題が無ければ、要求取得部１１は、サービス事業者端末２等からの承認を示す情報をブループリント作成部１２に送信する（ステップＳ８）。
　ステップＳ１～ステップＳ８は、ＩＣＴ資源管理装置１が実行する処理全体のうち、インフラ設計の処理を構成する。
　なお、処理を迅速にするため、ステップＳ７、ステップＳ８は、省略してもよい。
　次に、ブループリント作成部１２は、承認を得たブループリント２４に基づくオーケストレーションを実行するためのスクリプトを作成する（ステップＳ９）。スクリプトの作成の技術は周知であり、詳細な説明は省略する。次に、ブループリント作成部１２は、作成したスクリプトをワークフロー実行部１５に出力する（ステップＳ１０）。
　ステップＳ９～ステップＳ１０は、ＩＣＴ資源管理装置１が実行する処理全体のうち、スクリプト作成の処理を構成する。
　次に、ワークフロー実行部１５は、ブループリント作成部１２から取得したスクリプトを解釈する（ステップＳ１１）。スクリプトの解釈の技術は周知であり、詳細な説明は省略する。次に、ワークフロー実行部１５は、ＡＰＩアダプタ部１６に対し、ＡＰＩを通じ操作することができるプログラムごとに命令し（ステップＳ１２）、プロセスを実行する。
　プロセスの実行が完了した場合、ＡＰＩアダプタ部１６は、ワークフロー実行部１５に、プロセスの実行の完了を通知する（ステップＳ１３）。次に、ワークフロー実行部１５は、ブループリント作成部１２に、プロセスの実行の完了を通知する（ステップＳ１４）。プロセスの実行の完了は、ＩＣＴ資源管理装置１から仮想レイヤに対するオーケストレーションの実行の完了を意味し、構成変更後のサービスが利用可能になったことを意味する。
　ステップＳ１１～ステップＳ１４は、ＩＣＴ資源管理装置１が実行する処理全体のうち、オーケストレーションの処理を構成する。
　その後、監視部１７は、物理レイヤ上の物理ノード、および、仮想レイヤ上の仮想ノードの監視を開始する。監視部１７は、監視によって収集した情報を構成情報管理部１３に通知する（ステップＳ１５）。次に、構成情報管理部１３は、監視部１７から収集した情報をレイヤマッピング部１４に通知する（ステップＳ１６）。
　ステップＳ１５～ステップＳ１６は、ＩＣＴ資源管理装置１が実行する処理全体のうち、監視の処理を構成する。
　構成情報管理部１３は、監視部１７が収集した情報から構成情報を生成し、構成情報ＤＢ２１に格納する。また、レイヤマッピング部１４は、構成情報管理部１３を介して、監視部１７が収集した情報からマッピング情報２２を生成する。生成された構成情報およびマッピング情報２２は、新たなブループリントの作成に用いられる。
　図６の処理によれば、ＩＣＴ資源管理装置１は、構成情報およびマッピング情報２２を最新状態で保持することができるため、人手を介することなくブループリントを作成し、オーケストレーションを実行し、オペレーションを自動化することができる。
＜初期デプロイの具体例＞
　次に、自動化されるオペレーションとして、初期デプロイについてのワークフローの実行例について、図７を参照して詳細に説明する。図７に示すように、初期デプロイのワークフローは、例えば、ＭＳＡ（Micro Service Architecture）を用いて定義することができ、サービスレイヤ、ベースライン、マイクロサービスの３層で設計することができる。
　サービスレイヤは、初期デプロイのワークフローの各工程を、順序を定めて連結された状態で登録する。図７に示すように、初期デプロイのワークフローは、カタログ／構成情報取得Ａ１、余剰リソース取得／収容先設定Ａ２、ＶＭ作成Ａ３、ＬＢ／ＦＷグループ追加Ａ４、コンテナホスト登録Ａ５、コンテナイメージ展開Ａ６、状態確認Ａ７、という工程に分けることができ、この順序で実行される。
　カタログ／構成情報取得Ａ１は、カタログ群２３からのカタログの選択、および、構成情報管理部１３による構成情報の取得を示す工程である。
　余剰リソース取得／収容先設定Ａ２は、ＩＣＴ資源の各々の余剰リソースの取得、および、作成されるＶＭの収容先となる物理ノードの設定を示す工程である。
　ＶＭ作成Ａ３は、サービスに供するアプリケーションが配置されるＶＭの作成を示す工程である。
　ＬＢ／ＦＷグループ追加Ａ４は、ロードバランサのグループおよびファイアウォールのグループをＮＷ上に追加することを示す工程である。
　コンテナホスト登録Ａ５は、作成されるＶＭが用いるコンテナを実行させるための環境構築を示す工程である。コンテナを動作させるためのホストマシンを追加作成し、追加されたホストマシンは、コンテナを管理するコントローラへ登録される。
　コンテナイメージ展開Ａ６は、コンテナを動作させるためのホストマシンに、コンテナ化されたアプリケーションを配置する工程である。コンテナ化されたアプリケーションはイメージファイル化されており、当該イメージを指示するホストマシンに配置される。
　状態確認Ａ７は、初期デプロイの最終段階として、作成したＶＭの状態を確認する工程である。
　ベースラインは、サービスレイヤの各工程の部品を登録する。登録された部品は、カタログとして構成することができる。サービスレイヤに示す各工程は、ベースラインに示す部品の組合せとして実現することができる。図７に示すように、初期デプロイのベースラインには、余剰リソース取得Ｂ１、ＶＭ作成Ｂ２、ＬＢ／ＦＷグループ追加Ｂ３、コンテナホスト登録Ｂ４、コンテナイメージ展開Ｂ５、状態確認Ｂ６が登録されている。
　余剰リソース取得Ｂ１は、余剰リソース取得／収容先設定Ａ２の部品を登録する。余剰リソース取得Ｂ１に登録される部品は、例えば、［１］ホスト、ＶＭ一覧取得と、［２］ＶＭ割当スペック取得と、［３］ホスト割当スペック集計とがあるが、これらに限定されない。
　ＶＭ作成Ｂ２は、ＶＭ作成Ａ３の部品を登録する。ＶＭ作成Ｂ２に登録される部品は、例えば、［１］全ＶＭ名取得、［２］ＶＭ名決定、［３］ＩＰ払出、［４］ＶＭクローン、［５］ＳＳＨ（Secure Shell）個別設定と、があるが、これらに限定されない。
　ＬＢ／ＦＷグループ追加Ｂ３は、ＬＢ／ＦＷグループ追加Ａ４の部品を登録する。ＬＢ／ＦＷグループ追加Ｂ３に登録される部品は、例えば、［１］ＬＢグループ追加、［２］ＦＷグループ追加とがあるが、これらに限定されない。
　コンテナホスト登録Ｂ４は、コンテナホスト登録Ａ５の部品を登録する。コンテナホスト登録Ｂ４に登録される部品は、例えば、［１］トークン取得、［２］ホスト追加とがあるが、これらに限定されない。
　コンテナイメージ展開Ｂ５は、コンテナイメージ展開Ａ６の部品を登録する。コンテナイメージ展開Ｂ５に登録される部品は、例えば、［１］イメージ展開があり、必要に応じてＳＳＨ個別設定を用意することができるが、これらに限定されない。
　状態確認Ｂ６は、状態確認Ａ７の部品を登録する。状態確認Ｂ６に登録される部品は、例えば、［１］Pingテストがあるがこれらに限定されない。
　マイクロサービスは、ベースラインに登録されている部品を実行するための機能を登録する。図７に示すように、初期デプロイのマイクロサービスには、［ホスト］情報取得Ｃ１、［ＶＭ］情報取得Ｃ２、［ホスト］情報取得Ｃ３、［ＮＳＸ］ＩＰ払出Ｃ４、［ＶＭ］クローンＣ５、［ＶＭ］ＳＳＨ実行Ｃ６、［ＮＳＸ］ＬＢ追加Ｃ７、［ＮＳＸ］ＦＷ追加Ｃ８、［Rancher］トークン取得Ｃ９、［ＶＭ］ＳＳＨ実行Ｃ１０、［Rancher］コンテナ作成Ｃ１１、［ＶＭ］PingテストＣ１２が登録されている。
　［ホスト］情報取得Ｃ１は、物理ノードの管理項目（例えば、図３参照）の情報を取得し、余剰リソース取得Ｂ１の［１］ホスト、ＶＭ一覧取得を実現する。
　［ＶＭ］情報取得Ｃ２は、仮想ノードの管理項目（例えば、図４参照）の情報を取得し、余剰リソース取得Ｂ１の［２］ＶＭ割当スペック取得を実現する。
　［ホスト］情報取得Ｃ３は、物理ノードの管理項目（例えば、図３参照）の情報を取得し、ＶＭ作成Ｂ２の［１］全ＶＭ名取得を実現する。
　［ＮＳＸ］ＩＰ払出Ｃ４は、ＶＭのＩＰアドレスを払い出し、ＶＭ作成Ｂ２の［３］ＩＰ払出を実現する。
　［ＶＭ］クローンＣ５は、ＶＭの複製処理をし、ＶＭ作成Ｂ２の［４］ＶＭクローンを実現する。
　［ＶＭ］ＳＳＨ実行Ｃ６は、ＶＭへログインして命令を実行し、ＶＭ作成Ｂ２の［５］ＳＳＨ（Secure Shell）個別設定を実現する。
　［ＮＳＸ］ＬＢ追加Ｃ７は、ネットワーク上にＬＢを追加し、ＬＢ／ＦＷグループ追加Ｂ３の［１］ＬＢグループ追加を実現する。
　［ＮＳＸ］ＦＷ追加Ｃ８は、ネットワーク上にＦＷを追加し、ＬＢ／ＦＷグループ追加Ｂ３の［２］ＦＷグループ追加を実現する。
　［Rancher］トークン取得Ｃ９は、処理を行うための権限を取得するコンテナを作成し、コンテナホスト登録Ｂ４の［１］トークン取得を実現する。
　［ＶＭ］ＳＳＨ実行Ｃ１０は、ＶＭへログインして命令を実行し、コンテナホスト登録Ｂ４の［２］ホスト追加を実現する。
　［Rancher］コンテナ作成Ｃ１１は、コンテナ化されたアプリケーションを作成し、コンテナイメージ展開Ｂ５の［１］イメージ展開を実現する。
　［ＶＭ］PingテストＣ１２は、疎通確認をし、状態確認Ｂ６の［１］Pingテストを実現する。
　サービスレイヤに示す各工程（Ａ１～Ａ７）は、カタログに相当し、ベースラインに登録されている部品は、カタログの部分に相当する。マイクロサービスに示す各種機能（Ｃ１～１２）は、ベースラインに登録されている対応する部品に対してパラメータを入力することができる。
　図７に示すように、ワークフロー実行部１５は、初期デプロイについては、事前に作成したブループリント２４を基づいてＶＭを作成し、コンテナイメージ展開を実行する。このように、ワークフロー実行部１５は、本来は別々となる工程を連結し、各工程についてパラメータが必要となる処理を自動化することができる。
　本実施形態によれば、物理レイヤと仮想レイヤとのマッピングによって、物理ノードと仮想ノードとの紐付けが明らかとなり、構成変更に対する仮想ノードを、人手を介することなく特定することができる。このため、オペレーションの自動化を実現することができる。
　したがって、分散システムのオペレーションを自動化し、仮想化技術が適用される分散システムの運用コストを低減することができる。
　特に、ブループリント２４を、カタログの集合体とパラメータを含むように構成することで（図５参照）、オーケストレーションを実行するためのワークフローを容易に構成することができる。
　また、監視部１７を備えることで、構成情報およびマッピング情報を最新状態で保持することができるため、人手を介することなくブループリントを作成し、オーケストレーションを実行し、オペレーションの自動化に寄与することができる。
　また、後記のＩＣＴ資源管理プログラムは、ＩＣＴ資源管理装置の構築を容易にすることができる。
　（プログラム）
　また、上記実施形態に係るＩＣＴ資源管理装置１が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、ＩＣＴ資源管理装置１と同様の機能を実現するＩＣＴ資源管理プログラムを実行するコンピュータの一例を説明する。
　図８は、ＩＣＴ資源管理プログラムを実行するコンピュータを示す図である。図８に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ＲＯＭ（Read　Only　Memory）１０１１およびＲＡＭ（Random　Access　Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。メモリ１０１０、ハードディスクドライブ１０９０、ディスクドライブ１１００、および、ディスクドライブ１１００に挿入される記憶媒体は、ＩＣＴ資源管理装置１が備える記憶部の具体的なハードウェア資源となる。
　ここで、図８に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各テーブルは、例えばハードディスクドライブ１０９０やメモリ１０１０に記憶される。
　また、ＩＣＴ資源管理プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、ハードディスクドライブ１０９０に記憶される。具体的には、上記実施形態で説明したＩＣＴ資源管理装置１が実行する各処理が記述されたプログラムモジュールが、ハードディスクドライブ１０９０に記憶される。
　また、ＩＣＴ資源管理プログラムによる情報処理に用いられるデータは、プログラムデータとして、例えば、ハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。
　なお、ＩＣＴ資源管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、ＩＣＴ資源管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮ（Local　Area　Network）やＷＡＮ（Wide　Area　Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
（その他）
　（ａ）構成情報管理部１３は、物理ノードの位置情報を管理することができる。
　（ｂ）構成情報管理部１３は、物理ノードとしてのエッジ４に接続しているデバイス５を使用するユーザに関する情報、または、ユーザのテナントに関する情報を管理することができる。よって、物理レイヤ構成情報２１ａとして管理される構成情報は、ユーザ単位またはテナント単位の構成情報とすることができる。レイヤマッピング部１４が、物理レイヤと仮想レイヤとのマッピングを行った場合、ユーザ単位またはテナント単位の構成情報は、仮想レイヤ構成情報２１ｂとして管理される構成情報とすることができる。
　１００　分散システム
　１　　　ＩＣＴ資源管理装置
　２　　　サービス事業者端末
　３　　　サーバ
　４　　　エッジ
　５　　　デバイス
　６　　　アプリ（アプリケーション）
　７　　　ＶＭ
　１１　　要求取得部
　１２　　ブループリント作成部
　１３　　構成情報管理部
　１４　　レイヤマッピング部
　１５　　ワークフロー実行部（オーケストレータ部）
　１６　　ＡＰＩアダプタ部（オーケストレータ部）
　１７　　監視部
　２１　　構成情報ＤＢ
　２１ａ　物理レイヤ構成情報
　２１ｂ　仮想レイヤ構成情報
　２２　　マッピング情報
　２３　　カタログ群
　２４　　ブループリント

Claims (5)

  1. 　ＩＣＴ資源となる、物理ノードおよび仮想ノードを管理するＩＣＴ資源管理装置であって、
    　物理レイヤ上の前記物理ノードに関する構成情報である物理レイヤ構成情報、および、仮想レイヤ上の前記仮想ノードに関する構成情報である仮想レイヤ構成情報を管理する構成情報管理部と、
    　前記物理レイヤおよび前記仮想レイヤとのマッピングを行うレイヤマッピング部と、
    　外部装置からの構成変更の要求に対して、前記物理レイヤ構成情報、前記仮想レイヤ構成情報、および、前記マッピングの結果であるマッピング情報に基づいて、前記構成変更に必要なインフラの設計情報となるブループリントを作成するブループリント作成部と、
    　前記ブループリントに基づいて、ＡＰＩを通じ操作することができるプログラムにアクセスして実行することで、前記仮想レイヤに対するオーケストレーションを実行するオーケストレータ部と、を備える、
    　ことを特徴とするＩＣＴ資源管理装置。
  2. 　前記ブループリントは、サービスの提供に供する工程を示すカタログの集合体と、前記カタログに対するインプット情報となるパラメータとを含む、
    　ことを特徴とする請求項１に記載のＩＣＴ資源管理装置。
  3. 　前記物理ノードおよび前記仮想ノードを監視する監視部、をさらに備え、
    　前記構成情報管理部は、前記監視部の監視によって収集した情報から、前記物理レイヤ構成情報および前記仮想レイヤ構成情報を生成し、
    　前記レイヤマッピング部は、前記監視部の監視によって収集した情報から、前記マッピング情報を生成する、
    　ことを特徴とする請求項１または請求項２に記載のＩＣＴ資源管理装置。
  4. 　ＩＣＴ資源となる、物理ノードおよび仮想ノードを管理するＩＣＴ資源管理装置におけるＩＣＴ資源管理方法であって、
    　前記ＩＣＴ資源管理装置は、
    　物理レイヤ上の前記物理ノードに関する構成情報である物理レイヤ構成情報、および、仮想レイヤ上の前記仮想ノードに関する構成情報である仮想レイヤ構成情報を収集するステップと、
    　前記物理レイヤおよび前記仮想レイヤとのマッピングを行うステップと、
    　外部装置からの構成変更の要求に対して、前記物理レイヤ構成情報、前記仮想レイヤ構成情報、および、前記マッピングの結果であるマッピング情報に基づいて、前記構成変更に必要なインフラの設計情報となるブループリントを作成するステップと、
    　前記ブループリントに基づいて、ＡＰＩを通じ操作することができるプログラムにアクセスして実行することで、前記仮想レイヤに対するオーケストレーションを実行するステップと、を実行する、
    　ことを特徴とするＩＣＴ資源管理方法。
  5. 　コンピュータを、請求項１から請求項３の何れか１項に記載のＩＣＴ資源管理装置として機能させるためのＩＣＴ資源管理プログラム。
PCT/JP2019/045932 2018-12-04 2019-11-25 Ｉｃｔ資源管理装置、ｉｃｔ資源管理方法、および、ｉｃｔ資源管理プログラム WO2020116221A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
SG11202105923VA SG11202105923VA (en) 2018-12-04 2019-11-25 Ict resource management device, ict resource management method and ict resource management program
US17/311,073 US20220043946A1 (en) 2018-12-04 2019-11-25 Ict resource management device, ict resource management method, and ict resource management program
AU2019393436A AU2019393436B2 (en) 2018-12-04 2019-11-25 ICT resource management device, ICT resource management method and Ict resource management program
JP2020559060A JP7056759B2 (ja) 2018-12-04 2019-11-25 Ｉｃｔ資源管理装置、ｉｃｔ資源管理方法、および、ｉｃｔ資源管理プログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018227538 2018-12-04
JP2018-227538 2018-12-04

Publications (1)

Publication Number Publication Date
WO2020116221A1 true WO2020116221A1 (ja) 2020-06-11

Family

ID=70975261

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/045932 WO2020116221A1 (ja) 2018-12-04 2019-11-25 Ｉｃｔ資源管理装置、ｉｃｔ資源管理方法、および、ｉｃｔ資源管理プログラム

Country Status (6)

Country Link
US (1) US20220043946A1 (ja)
JP (1) JP7056759B2 (ja)
AU (1) AU2019393436B2 (ja)
SG (1) SG11202105923VA (ja)
TW (1) TWI807139B (ja)
WO (1) WO2020116221A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111800506A (zh) * 2020-07-06 2020-10-20 深圳市网心科技有限公司 一种边缘计算节点部署方法及相关装置
WO2022254728A1 (ja) * 2021-06-04 2022-12-08 楽天モバイル株式会社 ネットワーク管理システム、ネットワーク管理方法およびプログラム

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113111374B (zh) * 2021-05-13 2022-09-23 上海交通大学 一种端边云的工业微服务系统、数据交互方法及介质
TWI821038B (zh) * 2022-11-22 2023-11-01 財團法人工業技術研究院 運算工作分派方法及應用其之終端電子裝置與運算系統

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015056182A (ja) * 2013-09-13 2015-03-23 株式会社Ｎｔｔドコモ ネットワーク仮想化のための方法及び装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6499622B2 (ja) * 2016-08-22 2019-04-10 日本電信電話株式会社 事業者間一括サービス構築装置及び事業者間一括サービス構築方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015056182A (ja) * 2013-09-13 2015-03-23 株式会社Ｎｔｔドコモ ネットワーク仮想化のための方法及び装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111800506A (zh) * 2020-07-06 2020-10-20 深圳市网心科技有限公司 一种边缘计算节点部署方法及相关装置
CN111800506B (zh) * 2020-07-06 2023-09-19 深圳市网心科技有限公司 一种边缘计算节点部署方法及相关装置
WO2022254728A1 (ja) * 2021-06-04 2022-12-08 楽天モバイル株式会社 ネットワーク管理システム、ネットワーク管理方法およびプログラム

Also Published As

Publication number Publication date
SG11202105923VA (en) 2021-07-29
TWI807139B (zh) 2023-07-01
AU2019393436B2 (en) 2022-08-04
AU2019393436A1 (en) 2021-06-24
US20220043946A1 (en) 2022-02-10
JP7056759B2 (ja) 2022-04-19
TW202037132A (zh) 2020-10-01
JPWO2020116221A1 (ja) 2021-09-27

Similar Documents

Publication Publication Date Title
JP7056759B2 (ja) Ｉｃｔ資源管理装置、ｉｃｔ資源管理方法、および、ｉｃｔ資源管理プログラム
AU2020200723B2 (en) Systems and methods for blueprint-based cloud management
US11321130B2 (en) Container orchestration in decentralized network computing environments
EP2926253B1 (en) Diagnostic virtual machine
WO2016121802A1 (ja) 仮想化管理・オーケストレーション装置、仮想化管理・オーケストレーション方法、および、プログラム
US20130339510A1 (en) Fast provisioning service for cloud computing
CN105379185B (zh) 用于创建和管理网络群组的方法和系统
US20100293269A1 (en) Inventory management in a computing-on-demand system
US9116874B2 (en) Virtual machine test system, virtual machine test method
US20110072505A1 (en) Process for Installing Software Application and Platform Operating System
WO2016121736A1 (ja) オーケストレータ装置、システム、仮想マシンの作成方法及びプログラム
JP7056760B2 (ja) Ｉｃｔ資源管理装置、ｉｃｔ資源管理方法、および、ｉｃｔ資源管理プログラム
JP6393612B2 (ja) システムのバックアップ装置及びバックアップ方法
JP2017068480A (ja) ジョブ管理方法、ジョブ管理装置及びプログラム
CN114461303A (zh) 一种访问集群内部服务的方法和装置
JP7115561B2 (ja) Ｉｃｔ資源管理装置、ｉｃｔ資源管理方法、および、ｉｃｔ資源管理プログラム
Aznar et al. CNSMO: A Network Services Manager/Orchestrator tool for cloud federated environments
GORDIN et al. Web portal development with different cloud containers: Docker vs. Kubernetes.
Comas Gómez Despliegue de un gestor de infraestructura virtual basado en Openstack para NFV
SYN et al. D3. 3: Infrastructures Management Toolkit API

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: 19894225

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020559060

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019393436

Country of ref document: AU

Date of ref document: 20191125

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 19894225

Country of ref document: EP

Kind code of ref document: A1