WO2006051599A1 - リソース管理プログラム、リソース管理方法、およびリソース管理装置 - Google Patents

リソース管理プログラム、リソース管理方法、およびリソース管理装置 Download PDF

Info

Publication number
WO2006051599A1
WO2006051599A1 PCT/JP2004/016843 JP2004016843W WO2006051599A1 WO 2006051599 A1 WO2006051599 A1 WO 2006051599A1 JP 2004016843 W JP2004016843 W JP 2004016843W WO 2006051599 A1 WO2006051599 A1 WO 2006051599A1
Authority
WO
WIPO (PCT)
Prior art keywords
action
request
resource management
handler
processing
Prior art date
Application number
PCT/JP2004/016843
Other languages
English (en)
French (fr)
Inventor
Masazumi Matsubara
Akira Katsuno
Hiroshi Yazawa
Takashi Fujiwara
Original Assignee
Fujitsu Limited
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 Fujitsu Limited filed Critical Fujitsu Limited
Priority to JP2006544704A priority Critical patent/JP4522413B2/ja
Priority to PCT/JP2004/016843 priority patent/WO2006051599A1/ja
Publication of WO2006051599A1 publication Critical patent/WO2006051599A1/ja
Priority to US11/798,339 priority patent/US8589381B2/en

Links

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/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/509—Offload

Definitions

  • Resource management program Resource management program, resource management method, and resource management apparatus
  • the present invention relates to a resource management program, a resource management method, and a resource management apparatus for managing IT (Information Technology) resources such as hardware and software, and in particular, resource management operable in cooperation with other management systems.
  • IT Information Technology
  • the present invention relates to a program, a resource management method, and a resource management device.
  • resource managers that manage IT resources such as software and software are widely used in order to reduce manual work.
  • the resource manager can often manage a plurality of resources in an integrated manner.
  • the management method differs for each resource type. Therefore, the types of resources that can be managed by a single resource manager are limited. Therefore, in a system having various types of resources, resource management of the entire system is performed by a plurality of resource managers.
  • a dedicated resource manager is generally used to manage each resource.
  • a resource manager is provided for each hardware device such as a server, storage, or network, or a unique resource manager is provided for each company's product.
  • the promotion of this trend is a natural flow, considering the distribution of processing and the optimal use of unique functions.
  • the interface for exchanging messages with the outside differs for each resource manager. Therefore, it is difficult to operate multiple resource managers in cooperation with each other. For example, introducing new server and storage products Even so, the server's resource manager and storage 'resource manager cannot be interconnected. For this reason, the administrator must manually specify the environment settings for each of the server resource manager and storage resource manager. As a result, troubles such as incorrect connection between the two devices are likely to occur, causing problems in service operation.
  • Patent Document 1 Japanese Patent Laid-Open No. 10-11347
  • the present invention has been made in view of the above points, and the hierarchical resource management functions can request mutual processing while maintaining the uniqueness of the processing contents of each resource management function. It is an object to provide a resource management program, a resource management method, and a resource management apparatus.
  • the present invention provides a resource management program that realizes the functions shown in FIG. 1 by a computer.
  • the resource management program of the present invention manages resources by sharing processing with other resource management functions.
  • the computer that executes this resource management program has the functions shown in FIG.
  • the storage unit la stores an action node table laa in which an action node in which at least a part of execution contents of processing according to the request content is defined is registered for each processing request content.
  • the action handler search means lb receives the first action request 7a in which the content of the processing request is shown in a common data structure shared with other resource management functions, the action action 7a The request contents are analyzed, and an action handler corresponding to the request contents shown in the first action request 7a is searched from the action notable table laa.
  • the action execution means Id activates the action handler detected by the action handler search means lb, executes the processing defined in the action handler, and the request contents shown in the first action request 7a are not yet received.
  • a second action request 7b indicating the content of the request for incomplete processing is generated in the common data structure, and for other resource management functions that manage the managed device that is the target of incomplete processing Send a second action request 7b.
  • the content of the request by the first action request 7a is analyzed by the action handler search means lb, and the first action request 7a is analyzed.
  • the action handler table laa is searched for an action handler corresponding to the request content shown in the action request 7a.
  • the action execution means Id starts the action handler detected by the action handler search means lb, executes the processing defined in the started action handler, and executes the first action list.
  • a second action request 7b indicating the content of the incomplete processing request is generated in the common data structure, and the management target that is the target of the incomplete processing
  • a second action request 7b is sent to other resource management functions that manage the device.
  • the storage unit includes a request.
  • An action handler in which at least a part of the execution contents of the process corresponding to the contents is defined stores in advance an action handler table registered for each request contents of the process, and the action handler search means includes the other Upon receiving the first action request that indicates the processing request content in a common data structure that is shared with the resource management function, the request content by the first action request is analyzed, and the first key is analyzed. The action handler table power is also searched for the action handler corresponding to the request content indicated in the request, and the action handler table is searched.
  • Action execution means power Starts the action handler detected by the action handler search means, executes the process defined in the action handler, and the request content shown in the first action request is incomplete In this case, a second action request indicating the details of the incomplete processing request is generated in the common data structure, and other resource management functions for managing the management target device that is the target of the incomplete processing are generated. And transmitting the second action request.
  • a resource management method is provided.
  • a resource management apparatus that manages resources by sharing processing with other resource management functions can perform processing corresponding to the content of the request.
  • the request content by the first action request is analyzed, and the action corresponding to the request content indicated in the first action request
  • Action handler search means for searching for handlers and action handler search means for searching for handlers and action handler search means for detecting handlers.
  • the action handler to start, action Nono command If the request content shown in the first action request is incomplete, a second action request indicating the request content of the incomplete processing in the common data structure is sent.
  • Resource management comprising: an action execution means for transmitting the second action request to another resource management function for managing a device to be managed that is generated and processed for incomplete processing.
  • the processing defined in the action handler corresponding to the request content is executed in response to the first action request in which the processing request content is indicated by the common data structure, and the request content is When is not completed, the second action request indicating the details of the request for incomplete processing in the common data structure is sent to other resource management functions.
  • the data structure for defining the content of the processing request can be made common so that interconnection is possible, and the execution content of the requested processing can be uniquely defined by the action handler.
  • the processing according to the first action request is distributed using the hierarchical resource management function. Can be executed.
  • FIG. 1 is a conceptual diagram of an invention applied to an embodiment.
  • FIG. 2 is a diagram showing a system configuration of the present embodiment.
  • FIG. 3 is a diagram showing a hardware configuration example of a management server computer used in the embodiment of the present invention.
  • FIG. 4 is a diagram showing a configuration of a resource management function.
  • FIG. 5 is a diagram showing the internal structure of the system RM.
  • FIG. 6 is a diagram showing the internal structure of the agent.
  • FIG. 7 is a UML (Unified Modeling Language) model diagram showing a data model of action information.
  • UML Unified Modeling Language
  • FIG. 8 is a diagram showing an example data structure of an action handler table.
  • FIG. 9 A flowchart showing the processing procedure of the resource manager in response to an action request.
  • FIG. 10 is a flowchart showing an agent processing procedure in response to an action request.
  • FIG. 11 is a diagram showing the concept of action request propagation.
  • FIG. 12 is a diagram showing an example of the data structure of a log DB.
  • FIG. 13 is a diagram showing an example of an action node table stored in a management server computer that performs overall management.
  • FIG. 14 is a diagram showing an example of an action handler table stored in a management server computer that manages a server.
  • FIG. 15 is a diagram showing an example of an action handler table stored in a lower management server computer that manages network devices.
  • FIG. 16 is a diagram showing an example of an action handler table stored in a server computer capable of providing a Web service.
  • FIG. 17 is a first sequence diagram showing a procedure for server addition processing.
  • FIG. 18 is a second sequence diagram showing a procedure for server addition processing.
  • FIG. 19 is a third sequence diagram illustrating a procedure for server addition processing.
  • FIG. 20 is a propagation diagram of an action request when acquiring server configuration information.
  • FIG. 21 is a diagram showing an example of an action request that is output first when server configuration information is acquired.
  • FIG. 22 is a diagram showing an example of an action request after being transferred by the system RM.
  • FIG. 23 is an action request propagation diagram when adding a server.
  • FIG. 24 is a diagram showing an example of an action request that is output first when a server is added.
  • FIG. 25 is a diagram showing an example of an action request after being transferred by the system RM.
  • FIG. 26 is a diagram showing an example of an action request after being transferred by the system RM.
  • FIG. 27 is a diagram showing an example of an action request after being transferred by the system RM.
  • FIG. 1 is a conceptual diagram of the invention applied to the embodiment.
  • a resource management program to which the present invention is applied is implemented on the management server computers 1, 2, 3, and 4.
  • the storage means la stores an action nodal table laa.
  • an action handler in which at least a part of execution contents corresponding to the request contents is defined is registered for each request contents.
  • the action handler search means lb receives the first action request 7a in which the content of the processing request is indicated in a common data structure (common data format) shared with other resource management functions.
  • the other resource management function in the example of FIG. 1, the resource management function in the management server computer 2
  • the request content by the first action request 7a is analyzed.
  • the action handler search means lb searches the action handler table laa for an action handler corresponding to the request content indicated in the first action request 7a.
  • the action execution means Id activates the action handler detected by the action handler search means lb, and executes the processing defined in the action handler. Note that even if the processing defined in the action handler is executed, the content of the request shown in the first action request 7a may not be completed. In this case, the action execution means Id generates a second action request 7b indicating the content of the request for incomplete processing in the common data structure.
  • the action execution means Id performs other resource management functions (resource management functions in the management server computer 4 in the example of FIG. 1) that manage the managed devices that are the targets of incomplete processing. Send a second action request 7b.
  • the action handler forwarding means lc detects that the action handler is not detected by the action handler search means lb, the action request forwarding means lc manages other devices that manage the management target device to be processed in the first action request 7a.
  • a third action request 7c having the same request content as the first action request 7a is transmitted to the resource management function (in the example of FIG. 1, the resource management function in the management server computer 3).
  • the management server computer 1 has such a function, when the first action request 7a is input, a request by the first action request 7a is made by the action node search means lb. The content is analyzed. Then, the action handler search means lb searches the action handler table laa for the action handler corresponding to the request content indicated in the first action request 7a.
  • the action execution means Id starts up the action handle detected by the action handle search means lb, and the process defined in the started action handle is executed.
  • the action execution means Id generates the second action request 7b indicating the request content of the incomplete processing in the common data structure. .
  • the action execution means Id transmits the second action request 7b to the other resource management function that manages the management target device that is the target of the incomplete processing.
  • the action request transfer means lc manages the management target device to be processed in the first action request 7a.
  • a third action request 7c having the same request content as the first action request 7a is transmitted to other resource management functions.
  • the first action request 7a, the second action request 7b, and the third action request 7c include, for example, the name of the resource management function that generated the action request, and the relayed resource management function. , The information about the operation target resource, the information about the operation part of the operation target resource, and the content of the action to be executed.
  • each management server computer 11-4 By passing the action request in which the request content is defined in such a common data structure by the resource management function implemented in the management server computer 11-4, each management server computer 11-4 The contents of the request by the received action request can be analyzed. However, the execution content corresponding to the requested content can be defined independently by the action handler. Therefore, it is possible to pass action requests between resource management functions while maintaining the advanced management functions unique to each resource management function.
  • the requesting side can generate an action request without depending on the processing function of the requesting party.
  • the contents of the request indicated by the action request are associated with an action node that performs advanced resource management for each resource management function via the action node table laa.
  • the management server computer 2 that first outputs the first action request 7a does not need to recognize whether or not it has a resource management function capability hierarchical structure ahead of the management server computer 1.
  • the management server computer 2 that first outputs the first action request 7a does not need to recognize whether or not it has a resource management function capability hierarchical structure ahead of the management server computer 1.
  • the resource management function arranged on the management server computer that manages resources is called a resource manager.
  • a resource management function that manages resources according to the instructions of the resource manager and that is placed on a device that has resources to be managed is called an agent.
  • the resource management functions of both the resource manager and the agent are collectively called a component.
  • server when simply called “server”, it means a server function realized by a computer executing a server application.
  • server computer it refers to a computer that executes server applications.
  • FIG. 2 is a diagram showing a system configuration of the present embodiment.
  • a system is assumed in which services are provided to the clients 21, 22,.
  • resources are managed separately for a plurality of sites 100 and 200.
  • the connection relationship for system management is indicated by a broken line.
  • the site 100 includes management server computers 110, 120, 130, server computers 140, 150, and network devices 160, 170.
  • the management server computer 110 is connected to the management server computers 120 and 130 and manages the entire resources in the site 100 as a whole.
  • the management server computer 120 is connected to the server computers 140 and 150 and manages resources provided by the server computers 140 and 150.
  • the management server computer 130 is connected to the network devices 160 and 170 and manages resources provided by the network devices 160 and 170.
  • the server computers 140 and 150 are connected to the clients 21, 22, ⁇ via the network 10 and provide, for example, functions such as a Web server application to the clients 21, 22, ⁇ . To do.
  • the network devices 160 and 170 are connected between the server computers 140 and 150 and the storage devices 230 and 240 belonging to the site 200, and have a packet transfer function between the devices.
  • Management server computers 210 and 220 and storage devices 230 and 240 belong to the site 200.
  • the management server computer 210 is connected to the management server computer 220 and manages the overall resources in the site 100.
  • the management server computer 220 is connected to the storage devices 230 and 240 and manages resources provided by the storage devices 230 and 240.
  • the storage devices 230 and 240 store and manage information and provide information input / output functions to the server computers 140 and 150.
  • FIG. 3 is a diagram showing an example of the hardware configuration of the management server computer used in the embodiment of the present invention.
  • the entire management server computer 110 is controlled by a CPU (Central Processing Unit) 110a.
  • CPU lOa has RAM (Random Access Memory) 110b, hard disk drive (HDD) 110c, graphics processing unit 110d, input interface 110e, and one or more communication interfaces 110f via bus l lOg. Connected.
  • the RAMI 10b temporarily stores at least a part of an OS (Operating System) program application program to be executed by the CPU 110a.
  • the RAMI 10b stores various data necessary for processing by the CPUIOa.
  • HDDlOc stores OS and application programs.
  • a monitor 11 is connected to the graphic processing device 110d.
  • the graphic processing device 110d displays an image on the screen of the monitor 11 according to a command from the CPU 110a.
  • a keyboard 12 and a mouse 13 are connected to the input interface 110e.
  • the input interface 110e sends a signal sent from the keyboard 12 or mouse 13 to the CPU 110a via the bus lOg.
  • the communication interface 110f is connected to a network.
  • the communication interface 11 Of transmits / receives data to / from other computers via a network.
  • FIG. 3 shows only the hardware configuration of the management server computer 110, other management server computers 120, 130, server computers 140, 150, management server computers 210, 220, storage devices 230, 240, Can be realized with the same hardware configuration.
  • FIG. 4 is a diagram showing a configuration of the resource management function. First, the functions and data of each device belonging to the sites 100 and 200 will be described.
  • a system RM (resource manager) 111 having an action handler table 11 la and a log DB (database) 11 lb is provided.
  • the management server computer 120 has an action handler table 121a and a log D
  • a network RM (resource manager) 131 having an action handler table 131a and a log DB (database) 13 lb is provided.
  • an agent 141 having an action handler table 141a and a log DB (database) 141b is provided in the server computer 140.
  • an agent 151 having an action handler table 15 la and a log DB (database) 151b is provided!
  • the system RM111 is a higher-level resource manager that integrally manages the entire site 100 or a part thereof.
  • the system RM111 can manage all resources in the site 100 in cooperation with the server RM121 and the network RM131.
  • the server RM 121 manages resources provided by the server computers 140 and 150 in cooperation with the agents 141 and 151.
  • the network RM 130 manages resources provided by the network devices 160 and 170.
  • the agents 141 and 151 manage resources in the server computers 140 and 150, respectively, in accordance with instructions from the server RM121.
  • a system RM (resource manager) 211 having an action handler table 21 la and a log DB (database) 21 lb is provided in the management server computer 210.
  • a storage RM (resource manager) 221 having an action handler table 221a and a log DB (database) 221b is provided in the management server computer 210.
  • an agent 231 having an action handler table 23 la and a log DB (database) 231b is provided in the storage device 230.
  • an agent 241 having an action handler table 241a and a log DB (database) 241b is provided in the storage device 230.
  • the system RM211 is a higher-level resource manager that integrally manages the entire site 200 or a part thereof.
  • the system RM211 can manage all resources in the site 200 in cooperation with the storage RM221.
  • the storage RM 221 cooperates with the agents 231, 241, and the storage devices 230, 24 Manage resources provided by 0.
  • the agents 231 and 241 manage the resources in the storage devices 230 and 240, respectively, according to the instructions from the storage RM 241 force.
  • the action handler tables 11la, 121a, 131a, 141a, 151a, 211a, 221a, 231a, and 241a provided in each device execute processing according to the action information sent to each device.
  • Log DB1 l ib, 121b, 131b, 141b, 151b, 211b, 2 21b, 231b, 241b provided in each device contains the action information sent to each device and the history of action information generated by each device. Stored.
  • system RM111 and server RM211 Between system RM111 and server RM211, between system RM111 and server RM121, between system RM111 and server RM131, between server RM121 and agent 141, between server RM131 and agent 151, system The common interface 21-28 is mutually connected between the RM211 and the storage RM221, the storage RM221 and the agent 231, and the storage RM211 and the agent 241.
  • Non-common interface 31 a standardized interface such as SNMP (Simple Network Management Protocol) or CLI (Command-Line Interface) is used.
  • each resource manager shown in Fig. 4 virtually manages multiple resources as a single resource, groups resources of the same architecture, and performs various management. Function can be provided.
  • the site 100 has a two-layer structure in which a server RM 121 and a network RM 131 are arranged in a lower structure of the system RM 110.
  • the site 200 has a two-layer structure in which the storage RM 221 is arranged in a lower structure of the system RM 210.
  • This hierarchical structure is an example, and may be a deeper hierarchical structure.
  • actions that can be performed on the resource are limited to actions that can be instructed by an external force.
  • a non-common interface 31 such as a unique interface or SNMP is used between a resource without an agent and the manager of the resource.
  • action information including an action to be executed by the server computer 140 is issued from the system RM211.
  • the action information is passed from the system RM211 to the system RM111 using the common interface 21.
  • the system RM 111 refers to the action handler table 11 la and determines an action according to the received action information. Then, the system RM111 executes an action to be executed by itself, recognizes that it is action information for the server computer 140 connected to the server RM121, and transmits the action information to the server RM121 via the common interface 22. Send to. At this time, the system RM 111 stores the contents of the received action information, the contents of the action executed by the system RM 111, and the contents of the transmitted action information in the log DB1 ib.
  • the server RM 121 refers to the action handler table 121a to determine an action according to the received action information. Then, the server RM 121 executes an action to be executed by itself, recognizes that it is action information for the server computer 140, and transmits the action information to the agent 141 via the common interface 24. At this time, the server RM 121 stores the content of the received action information, the content of the action executed by the server RM 121, and the content of the transmitted action information in the log DB 12 lb.
  • the agent 141 refers to the action handler table 141a, determines a process according to the received action information, and executes the process. At this time, the agent 141 stores the content of the received action information and the content of the action executed by the agent 141 in the log DB 14 lb. [0064] In this way, the action information power system RM111, server RM121, and agent 141 that are issued in the system RM211 are transmitted in order, and commands corresponding to the action information designated by the agent 141 are finally transmitted. Executed.
  • FIG. 5 shows the internal structure of the system RM.
  • System RM111 consists of action handler table 11 la, log DBl l lb, multiple action handlers 11 lc, action handler search unit ll ld, action request transfer unit 11 le, action execution unit 11 If, and mouth collection unit 11 have lg
  • the contents of the action handler table 11 la and the log DB 11 lb are as described with reference to FIG.
  • the plurality of action handlers 111c are programs (commands, scripts, etc.) in which the contents of resource management processing to be executed according to action information are described.
  • the action handler search unit 11 Id refers to the action handler table 11 la and searches for an action handler corresponding to the action indicated by the action request 33. Then, the action handler search unit 11 Id notifies the action execution unit 11 If of the name of the detected action handler. In addition, when the action handler is detected, the action handler search unit 11 Id notifies the action request transfer unit 11 le that there is no corresponding action handler.
  • the action request forwarding unit 1 l ie recognizes that there is no action handler corresponding to the action request 33 based on the notification from the action handler search unit 11 Id, and executes the action indicated by the action request 33. Determine other components that should be done. For example, if the management target indicated by the action request 33 is a server, the action request transfer unit 1 ie determines that the server RM 121 is a component that should execute the action indicated by the action request 33. Then, the action request transfer unit 1 lie transmits an action request 34 that requests the same action as the action request 33 to the component that should execute the action indicated by the action request 33.
  • the action execution unit 11 If is the action handler search unit 11 Id to the action handler When the name is received, the action action handlers of the action action ll lc are obtained. Then, the action execution unit 11 If starts the acquired action handler.
  • the action execution unit 11 If processing that should be requested to other components occurs in the activated action handler, the action execution unit 11 If generates a new action. Then, the action execution unit 11 If transmits an action request 35 for requesting the generated action to another component. Further, when the process is completed, the action execution unit 11 If returns a process result 36 to the action generation source in the action request 33.
  • the log collection unit 11 lg acquires the contents of the executed processing as log information from the action request transfer unit 1 lie and the action execution unit 11 If. Then, the log collection unit 11 lg stores the acquired log information in the log DB 11 lb.
  • the system RM111 Since the system RM111 has the functions as described above, the action request is exchanged with other components using the common interface, and the action specified by the received action request is sent. Execution becomes possible. Note that FIG. 5 shows the functions of the system RM111 and other resource managers have similar functions.
  • FIG. 6 is a diagram showing the internal structure of the agent.
  • the agent 141 has an action handler table 141a, a log DB 141b, a plurality of action handlers 141c, an action handler search unit 141d, an action execution unit 141e, and a log collection unit 141f.
  • the information about the action handler table 141a, the log DB 141b, and the plurality of action handlers 141c is the same information as the action handler table 11 la, the log DBl l lb, and the plurality of action handlers 11 lc of the system RM111, respectively.
  • the action handler search unit 141d responds to the action request 37 in the same way as the action handler table 11 Id of the system RM111 shown in FIG. 14 Search action nodola from la. However, if the corresponding action handler is not detected by the search, an error message is returned to the sender of the action request 37.
  • the action execution unit 141e executes processing based on the action handler detected by the action router search unit 141d, and the processing result 38 Is output. However, action request generation processing for other components is not performed.
  • the log collection unit 141f stores a log of processing contents of the action execution unit 141e in the log DB 141b.
  • FIG. 6 shows the function of the agent 141 of the server computer 140, but other agents have the same function.
  • the action information exchanged between components as a common interface includes information on the component that generated the instruction, the relayed component, and the resource to be operated, information on the operation site of the operation target resource, and action information. Type information is included.
  • FIG. 7 is a UML (Unified Modeling Language) model diagram showing a data model of action information.
  • UML Unified Modeling Language
  • the ActionRequest element 41 is the top-level element. Action requests are sent and received between components using the ActionRequest element 41 as a unit.
  • the ActionRequest element 41 has an ID and createDate indicating the generated date and time as attributes.
  • the ActionRequest element 41 holds a Creator element 42, a Sender element 43, and an ActionEntity element 47 as contents.
  • the Creator element 42 has component information (resource manager identification information) that generated the action.
  • the Sender element 43 has component information of the transfer source that has transferred the action request.
  • the ManagedObject element 44 indicates a component or resource that is an operation execution target. Taste. ManagedObject 44 is further derived into three Creator elements 42, Sender elements 43, and Target elements 50 according to their responsibilities. Further, the ManagedObject element 44 has name and ID which are name attributes as attributes.
  • the ActionGroup element 45 is a class representing a set of actions.
  • ActionGroup element 45 includes one or more ActionEntity elements 47.
  • the ActionGroup element 45 has an order attribute that specifies the execution order of the plurality of ActionEntitty elements 47 included in the ActionGroup element 45.
  • the Action element 46 is an abstract class (a class that performs abstract definition and is based on the assumption that an instance cannot be generated and inherited) that represents the content of each action.
  • the ActionEntity element 47 is an abstract class indicating the action content, and the Action element 46 and the ActionGroup element 45 are derived from it.
  • the ActionRequest element 41 contains only one ActionEntity element 47, which means that the ActionRequest element 41 may contain either the Action element 46 or the ActionGroup element 45.
  • ActionEntity element 47 also has an ID attribute, a sync attribute that specifies whether to wait until a result is returned, and a priority attribute that indicates the priority of the action.
  • Both GetAction element 48 and SetAction element 49 are concrete classes of the Action class (classes that are not abstract classes).
  • the GetAction element 48 and the SetAction element 49 are used to specify information acquisition (get) and information setting (set) actions, respectively.
  • information acquisition (get) and information setting (set) actions respectively.
  • what actions can be performed on the action execution target is defined in advance and registered in the action handler table, so that the appropriate action can be set to the GetAction element 48, It can be specified in the action request in the same way as the SetAction element 49.
  • the Target element 50 specifies an object on which an action is to be executed.
  • the server Z storage Z network Z software and other resources are the target of action execution.
  • a server that logically groups services and multiple servers Domains can also be targeted.
  • the Target element 50 has a class attribute as an attribute indicating the target type.
  • the Target element 50 has name and id attributes as information indicating which instance of the class specifically. In the Target element 50, there is also a site attribute for designating which site is the target.
  • Property element 51 is an element for designating a site where an action acts
  • Target element Indicates the state and configuration of the object specified in 50.
  • the Property element 51 has a key attribute that designates the key of the part to act on as an attribute.
  • Property element 51 specifies the setting value for the specified part in the value attribute in the case of a setting action.
  • Property element 51 is a State element 52 that represents a state, and represents a configuration
  • the State element 52 indicates the state of the target object. States such as server usage and software START / STOP states are treated as State element 52, and actions such as acquisition 'setting are executed on objects in that state. State element 52
  • the InternalState element 53 indicates the internal state of the target object.
  • the CPU usage rate of the server and the START / STOP status of the software correspond to the nternalState element 53.
  • the ExternalState element 54 indicates the external state of the target object. This is the state of the target object observed from the outside (elements other than the target object). For example, the life or death status of the server corresponds to the external status. Therefore, in the case of an action that specifies the class of the ExternalState element 54, it means that the component that monitors the target object must respond responsibly.
  • the Configuration element 55 indicates the configuration 'setting of the target object. Increase / decrease in the amount of resources included in the target object, setting parameters, etc. are handled as the Configuration element 55, and actions such as “get” setting are executed for it.
  • the class of Configuration element 55 is further derived into Structure element 56 and Parameter element 57.
  • Configuration element 55 has a uri attribute for referencing external entities such as files Is provided. External entities are files, Web pages, etc., assuming that configuration information, etc. that is acquired and set is stored.
  • the format of the stored information may be in a format that can be interpreted by the component executing the action.
  • the Structure element 56 indicates the configuration of the target object. For example, this includes a server group registered in the server domain and a combination of applications constituting a service.
  • the Parameter element 57 indicates the setting of the target object. For example, the amount of memory used by the software or switch VLAN (Virtual Local Area Network) settings
  • the data may include additional information other than the above, such as action generation date / time information.
  • the data format can be sent and received in any format as long as the above information is included, but XML (eXtensible Markup Language) format is desirable from the viewpoint of portability and expandability.
  • FIG. 8 is a diagram showing an example of the data structure of the action handler table.
  • the action handler table 102 includes items of target type, property, action, and execution contents, and data of each item is associated with each other and registered as one record.
  • the type of the target on which the action acts is set.
  • a service a service provided to a user
  • Z server a processing function that performs a process for providing a service
  • Z network device Z software or the like is set as a type.
  • an attribute of a target on which the action acts is set.
  • configuration process related to system configuration
  • Z parameter operation such as parameter setting
  • Z status operation status monitoring processing
  • a type of action that can be executed for the property of the target object on which the action acts is set. For example, “set” and “get” are set.
  • the identification information for example, file name
  • action handlers such as commands and scripts that are actually executed
  • FIG. 9 is a flowchart showing the processing procedure of the resource manager in response to the action request.
  • the process illustrated in FIG. 9 will be described in order of step number.
  • the same processing is performed by other resource managers.
  • Step S11 The action handler search unit l l ld of the system RM111 receives the action request 33.
  • the action handler search unit 11 Id interprets the action in the received action request 33 and searches whether the action handler corresponding to the action is registered in the action handler table 11 la. Specifically, the action handler search unit 11 Id refers to the action handler table 11 la and searches for an appropriate record using the target object type, property, and action type described in the action request as keys. If there is a matching record as a result of the search, the action handler search unit 11 Id acquires the execution content of the matching record (name of the action handler).
  • Step S 13 If the action handler is registered, the action handler search unit 11 Id notifies the action execution unit 11 If of the name of the action handler, and advances the process to step S16. If the action handler is not registered, the action handler search unit 11 Id notifies the action request transfer unit l l le that the action handler is not registered, and the process proceeds to step S14.
  • Step S 14 The action request forwarding unit ll le corrects the sender information (Sender) of the action request 33 if no record matching the action handler table 111a is registered. . Specifically, system RM111 rewrites the transmission source information of action request 33 with its own identification information.
  • Step S 15 The action request transfer unit ll le forwards the action request 34 modified in step S 14 to a component suitable for processing the action request 33. Thereafter, the process proceeds to step S21.
  • the action execution unit ll lf references the action handler table 11 la, it searches for an appropriate record using the target object type, property, and action type described in the action as keys. If there is a match, the action handler (command, script, etc.) described as the execution content of the matched record is executed. At this time, the action execution unit 11 If converts the action content into a format suitable for the input of the specified command and script, and passes it to the execution process of the command or script.
  • Step S 17 Action Execution Unit 11 If determines whether all the processes necessary to satisfy action request 33 have been completed! If all the processes are completed! / ⁇ , the process proceeds to step S20. If there is an incomplete process, the process proceeds to step S18.
  • Step S18 If there is an incomplete process for satisfying the action request 33, the action execution unit l l lf creates a new action request 35 for executing the process.
  • Step S 19 The action execution unit 11 If transmits the action request 35 created in step S 18 to the appropriate component for executing the incomplete processing of the action request 33. Thereafter, the process proceeds to step S21.
  • Step S20 Action Execution Unit 11 If completes all processing required to satisfy action request 33, it returns the execution result to the request sender.
  • Step S21 The system RM111 stores the processing contents in the log DB1 l ib. Thereafter, the process ends.
  • FIG. 10 is a flowchart showing the processing procedure of the agent in response to the action request.
  • the process illustrated in FIG. 10 will be described in order of step number.
  • the same processing is also performed for other agents.
  • the action candidate search unit 141d receives the action request 37.
  • the action handler search unit 141d interprets the action in the received action request 37, and searches the action handler table 141a for an action handler corresponding to the action. Specifically, the action handler search unit 141d searches the action handler table 141a and searches for an appropriate record using the target object type, property, and action type described in the action request 37 as keys. If there is a record that matches as a result of the search, the action node search unit 141d acquires the execution content (action node, name of the task) of the matching record.
  • Step S33 When the action execution unit 141e refers to the action handler table 141a, the action execution unit 141e searches for an appropriate record using the target object type, property, and action type described in the action as a key. Execute the commands, scripts, etc. described as the execution contents of. At this time, the action execution unit 141e converts the content of the action into a format suitable for the input of the specified command and script, and passes it to the execution process of the command and script.
  • Step S34 The action execution unit 141e returns the execution result to the request transmission source.
  • Step S35 The action execution unit 141e stores the processing content in the log DB 141b. Thereafter, the process ends.
  • the action request is not always directly delivered to the component that executes the generating force action.
  • FIG. 11 is a diagram showing the concept of action request propagation.
  • seven components 61-67 are shown.
  • Components 61-67 are resource managers or agents that run on resources.
  • each component 61-67 shows the force generated by that component, or the action 61a, 62a, 63a, 63b, 63c, 63d, 63e force passed from other components! / Speak.
  • the same action is shown with the same shape and pattern.
  • the action 61a generated by the component 61 starts with the component. To 62. Then, in component 62, the action request is changed to another action request. In other words, it means that an action node and a handler corresponding to the received action request are registered in the action handler table of the component 62, and a new action 62a is generated as a result of calling the handler. This situation occurs in the following two cases.
  • the action request received by the component 62 may be modified into a more appropriate and specific action request and passed to other components.
  • the action request changed in the component 62 is sent to the component 63. Then, a new component action 63a, 63b, 63c, 63d, 63e is generated. An action request for action 63a is issued to component 64. An action request for action 63b is issued to component 65. Action requests for actions 63c, 63d, and 63e are issued to component 66.
  • action processing requests may be issued to other components 64-66.
  • multiple actions may be issued for the same component, such as actions 63c, 63d, and 63e. This is used when it is necessary to execute the next process after executing a certain process.
  • component 63 sends multiple components 63c, 63d, 63e to a single component 66, component 63 specifies the order relationship between the components 63c, 63d, 63e, and a plurality of action groups. Send action 63c, 63d, 63e in one request.
  • the action 63a generated by the component 63 is executed by the component 64 in accordance with the action request.
  • component 63 is a system RM that manages the entire site
  • component 65 is a server RM that manages a group of servers
  • agent that runs on a server with component 67.
  • the system RM recognizes that the generated action 63b is a server-related action, but does not need to recognize the power of which server actually is or where the server is. means. That is, the system RM throws the action 63a to the Sano RM that manages the entire server, and has the action 63a handed over to the agent that is actually in charge of the Sano RM. In this way, processing can be delegated.
  • the server RM does not pass the passed action request to the lower agent as it is. At least the source information (Sender) is changed to the server RM and transmitted by force. This is to ensure traceability of action propagation described later.
  • the action 6 la generated in the component 61 is divided into various actions, and finally reflected in the components 64, 66, and 67. With this configuration, each component does not necessarily need to know the existence of all other components.
  • the server RM 121 needs to know what kind of server is in the site 100.
  • the host system RM111 only needs to recognize that the server RM121 is managing the servers in the site 100 in a unified manner. The same applies to the network.
  • system RM211 at the site 200 only needs to know the existence of the system RM11 1 that manages the entire site 100 and can communicate with it only. All action requests related to resources at site 100 are sent to system RM111, and then the specified action is executed via the appropriate resource manager.
  • Figure 11 shows an action propagation diagram that covers the actions related to action 61a.
  • each component has a database that holds a log of actions, thereby satisfying such an action propagation relationship. It can be easily acquired. In other words, traceability can be ensured. As a result, it is possible to acquire all the actions related to an arbitrary action after an action request and cancel the issued request.
  • FIG. 12 is a diagram showing an example of the data structure of the log DB.
  • the log DB 103 has columns for operation type and individual blueprint.
  • the operation type column indicates the type of operation executed by the component. For example, action request generation, action request transmission, action request reception, and action execution are registered as operation types.
  • Information indicating the content of the operation is registered in the log information. For example, when an action request is generated, the entire content of the generated action request is retained. At this time, if the request is generated by executing an action corresponding to the preceding action request, the request ID of the preceding action request is also recorded. When sending an action request, the request ID and destination of the sent action request are recorded. When an action request is received, the received action request ID and sender are recorded. When an action is executed, the request ID of the action request and the action ID of the executed action are recorded.
  • the Web service is provided by using the storage device 230 at the site 200 and the server computer 150 at the site 100.
  • the server computer 140 is not providing a service.
  • the network device (for example, switch) 160 prevents the influence on other resources by setting a VLAN for the service.
  • FIG. 13 is a diagram showing an example of an action nodal table stored in the management server computer that performs overall management.
  • the action handler table 11 la stored in the management server computer 110 that performs overall management contains the action handler “ SVCC tl” for the set action for the service configuration and the get (get) for the service configuration. )
  • Action handler "svcctl" related to action is set.
  • the program specified by the execution contents is the same. This means that in the corresponding program, the set action or get action is executed according to the variable input when the action is executed.
  • This action handler table 11 la is referred to by the system RM111.
  • FIG. 14 is a diagram showing an example of the action handler table stored in the management server computer that manages the server.
  • the action handler table 121a stored in the management server computer 120 that manages the server contains the action handler “powerctl” for the set action for the server power status and the action handler for the set action for the server domain configuration. "Svrdomainctl.sh” and server The action handler “svrdomainctl.shj” is set for the get action for the domain configuration.
  • This action handler table 121a is referred to by the server RM121.
  • FIG. 15 is a diagram showing an example of an action node table stored in a lower management server computer that manages network devices.
  • the action handler table 131a stored in the management server computer 130 that manages the network device contains the action handler “nwctl” for the set action for the network device parameter and the set (get) for the network device parameter.
  • the action handler “nwctl” for the action is set.
  • This action handler table 131a is referred to by the network RM 131.
  • FIG. 16 is a diagram illustrating an example of an action handler table stored in a server computer that can provide a Web service.
  • the action handler table 141a stored in the server computer 140 that can provide the Web service contains an action handler “swctl” for the software state set action and an action for the software state get action. Handler "swctl" is set! RU
  • This action handler table 141a is referred to by the agent 141.
  • FIG. 17 is a first sequence diagram showing a procedure for server addition processing.
  • Step S41 the system RM 211 generates an action request for acquiring information indicating what free servers exist, and transmits the action request to the system RM 111.
  • Step S42 The system RM 111 obtains the action handler table 11 la and searches for the action specified in the action request.
  • Step S43 Since there is no appropriate handler in this example, the system RM 111 transfers an action request to the server RM 121, which is responsible for the server.
  • Step S44 Upon receiving the action request, the server RM 121 acquires the action handler table 121a and searches for the action specified in the action request. As a result, the command “svrdomainctl.sh” specifying the script name is detected (see Figure 14). [0141] [Step S45] The server RM 121 calls the corresponding command “svrdomainctl.sh”. By executing the command “svrdomainctl.sh”, the server RM 121 acquires free (currently providing service, server computer) sanolist information.
  • Step S46 The server RM121 notifies the system RM111 of the acquired sanolist.
  • Step S47 The system RM111 notifies the system RM211 of the free server list received from the server RM121.
  • Step S48 The system RM 211 generates an action request for adding the server computer 140 to the service based on the server information indicated by the acquired free sano list. Then, the system RM211 transmits the generated action request to the system RM111 that manages the entire site 100.
  • Step S49 The system RM 111 obtains the action handler table 11 la and searches for an action specified in the action request. As a result, the action handler “svcctlj” is detected (see FIG. 14).
  • Step S50 The system RM 111 calls the action handler “svcctl” obtained as a result of the search. Then, the system RM 111 executes the action handler “svcctl”.
  • Step S51 The system RM 111 executes the process defined by the action handler “svcctl”. Then, the system RM111 recognizes that in order to execute the specified action, it is necessary to first set the VLAN and start the application on the new server. Then, the system RM 111 generates an action request for network setting and an action request for server setting in accordance with the definition in the action handler “svcctl”.
  • Step S52 The system RM 111 first transmits an action request for network setting to the network RM 131.
  • FIG. 18 is a second sequence diagram illustrating the procedure of the server addition process.
  • Step S53 The network RM 131 obtains the action handler table 13 la and searches for the action specified in the action request. This will cause the action handler “Nwctl” is detected (see Figure 15).
  • Step S54 The network RM 131 executes the set action of the action handler “nwctl”.
  • Step S55 Since there is no agent in the network device 160, the network RM 131 performs settings related to the network device 160 VLAN using a standard or proprietary protocol such as SNMP according to the action handler.
  • Step S56 The network device 160 returns the execution result to the network RM 131.
  • Step S57 The network RM 131 returns the setting result of the network device 160 to the system RM 111.
  • FIG. 19 is a third sequence diagram illustrating a procedure for server addition processing.
  • System RM111 receives the completion of the network device settings.
  • an action request for starting the application is transmitted to the server RM121.
  • Step S59 The server RM 121 obtains the action handler table 121a, and searches for an action specified in the action request. In this case, the action nodal table 121a cannot find a suitable record.
  • Step S60 The server RM 121 recognizes that the received action request is for the server computer 140 based on the Target element 50 (see FIG. 7).
  • the server RM 121 transfers the action request to the agent 141 of the server computer 140.
  • Step S61 The agent 141 acquires the action handler table 141a, and searches for an action specified by the action request. At this time, the action setr “ SWC lt” of the software set action is detected (see FIG. 16).
  • Step S62 The agent 141 executes the set action of the action handler “swctl”.
  • Step S63 The agent 141 activates the service as an action based on the action handler.
  • Step S64 The agent 141 notifies the server RM 121 that the application has been started.
  • Step S65 The server RM 121 notifies the system RM 111 that the application has been started.
  • Step S66 The system RM 111 notifies the system RM 211 that the application has been started.
  • the Web server is added in the system managed at the site 100 according to the instruction from the system RM 211 on the site 200 side.
  • the following describes the action request propagation and a specific example of an action request.
  • a character string obtained by adding the code in FIG. 4 to the name of each component is used as a name for uniquely identifying each component in this system.
  • the name of system RM211 (“211” is the symbol in FIG. 4) is “system RM211”.
  • FIG. 20 is an action request propagation diagram when acquiring server configuration information.
  • An action 71 is generated for acquiring information on what free servers are available. Then, an action request 81 for requesting the action 71 is passed from the system RM 211 to the system RM 111.
  • the system RM111 does not have an action handler (acquisition of free server information) corresponding to the processing content of the specified action 71. Therefore, the system RM 111 rewrites the content of the transmission source of the action request 81 to make an action request 82. Then, the system RM111 passes the action request 82 to the server RM121.
  • the server RM121 executes processing (acquisition of free server information) corresponding to the action 71 specified by the action request 82.
  • FIG. 21 is a diagram showing an example of an action request that is output first when server configuration information is acquired. This action request 81 is described in XML.
  • ⁇ Structure key ⁇ FreeServerList7> indicates the name of the data to be acquired as a result.
  • Action request 81 like this is passed from system RM211 to system RM111
  • the action request 82 generated based on the action request 81 is passed from the system RM111 to the server RM121.
  • FIG. 22 is a diagram showing an example of an action request after being transferred by the system RM.
  • this action request 82 the identification information power of the action request is changed to “aq2”, and the name power of the sender is changed to “system RM 111.”
  • the content of the action is the same.
  • Sarnolist information is sent to RM211.
  • FIG. 23 is a propagation diagram of an action request when adding a server.
  • System RM2
  • an action 72 is created that adds the server computer 140 to the service. Then, the system RM 211 generates an action request 91 for requesting processing of the generated action 72, and passes it to the system RM 111.
  • Action 74 to be passed to 121 is generated. Then, an action request 92 for requesting processing of the action 73 is generated and passed to the network RM 131. Then, the process of action 73 is executed in network RM131. [0171] Thereafter, in the system RM111, an action request 93 force S for requesting the processing of the action 74 is generated and passed to the server RM121. The server RM 121 confirms that an action handler corresponding to the action 74 has been registered, and passes an action request 94 for requesting processing of the action 74 to the agent 141. Then, in the agent 141, the process of action 74 is executed.
  • FIG. 24 is a diagram showing an example of an action request that is output first when a server is added.
  • This action request 91 is described in XML.
  • the name of the system RM211 is set as the generation source, and the system RM211 is set as the transmission source. Then, an action is set to assign a new server to an active service!
  • Such an action request 91 is passed from the system RM 211 to the system RM 111.
  • the action request 92 generated based on the action request 91 is passed from the system RM111 to the network RM131.
  • FIG. 25 is a diagram showing an example of an action request after being transferred by the system RM.
  • this action request 92 the name of the system RM111 is set as the generation source, and the name of the system RM111 is set as the transmission source.
  • the content of the action is changed to an action for changing the VLAN setting of the network device 160.
  • the network RM 131 By passing such an action request 92 to the network RM 131, the network RM 131 performs VLAN setting of the network device 160.
  • the action request 93 generated based on the action request 91 V is passed from the system RM111 to the network RM131.
  • FIG. 26 is a diagram showing an example of an action request after being transferred by the system RM.
  • this action request 93 the name of the system RM111 is set as the generation source, and the name of the system RM111 is set as the transmission source.
  • the content of the action has been changed to an application activation process by the server computer 140.
  • FIG. 27 is a diagram showing an example of an action request after being transferred by the system RM.
  • the identification information of the action request is changed to “aq5”, and is changed to the name server RM121 of the transmission source.
  • the server application 140 starts up in the server computer 140 in the agent 141.
  • the resource manager and the agent operating on the resource are exchanged using a common interface.
  • the specified action is assigned to the component's own command or script by the action handler prepared for each component.
  • each component the action-related process execution history is recorded in the log.
  • each action request is held in the mouth DB on the component that generated the request.
  • Various information other than the information shown in FIG. 12 can be recorded as the log. This ensures action traceability and leads to improved management functions.
  • each component is mounted on an individual server computer, but a plurality of components can be mounted on one server computer.
  • the above processing functions can be realized by a computer.
  • a program that describes the processing contents of the functions that the management server computer and the server computer should have is provided.
  • the program that describes the processing contents The data can be recorded on a recording medium readable by a computer.
  • the computer-readable recording medium include a magnetic recording device, an optical disk, a magneto-optical recording medium, and a semiconductor memory.
  • Magnetic recording devices include hard disk drives (HDD), flexible disks (FD), and magnetic tapes.
  • Optical disks include DVD (Digital Versatile Disc), DV D—RAM (Random Access Memory), CD-ROM (Compact Disc Read Only Memory), and CD—R (Recordable) ZRW (Rewritable).
  • Magneto-optical recording media include MO (Magneto-Optical disk).
  • Portable recording media such as ROM are sold. It is also possible to store the program in a storage device of the server computer and transfer the program to other computers via the network.
  • the computer that executes the program stores, for example, the program recorded on the portable recording medium or the server computer-transferred program in its own storage device. Then, the computer reads its own storage device power program and executes processing according to the program. The computer can also read the program directly from the portable recording medium and execute processing according to the program. The computer can also execute processing according to the received program sequentially each time the program is transferred to the server computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Multi Processors (AREA)

Abstract

　各リソース管理機能における処理内容の独自性を維持しながら、階層化されたリソース管理機能同士で相互に処理を依頼できるようにする。 　第１のアクションリクエスト（７ａ）が入力されると、アクションハンドラ検索手段（１ｂ）により、第１のアクションリクエスト（７ａ）による依頼内容が解析され、第１のアクションリクエスト（７ａ）に示される依頼内容に対応するアクションハンドラがアクションハンドラテーブル（１ａａ）から検索される。すると、アクション実行手段（１ｄ）により、アクションハンドラ検索手段（１ｂ）で検出されたアクションハンドラが起動され、起動されたアクションハンドラに定義された処理が実行され、第１のアクションリクエスト（７ａ）に示される依頼内容が未完了の場合、共通データ構造で未完了分の処理の依頼内容を示す第２のアクションリクエスト（７ｂ）が生成され、送信される。                                                                                 

Description

明 細 書
リソース管理プログラム、リソース管理方法、およびリソース管理装置 技術分野
[0001] 本発明はハードウェアやソフトウェアなどの IT(Information Technology)リソースを管 理するリソース管理プログラム、リソース管理方法、およびリソース管理装置に関し、 特に他の管理システムと連携して動作可能なリソース管理プログラム、リソース管理方 法、およびリソース管理装置に関する。
背景技術
[0002] データセンターなどでは、人手による作業を軽減するために、ノ、一ドウエアやソフト ウェアなどの ITリソースを管理するリソースマネージャと呼ばれるソフトウェアが広く利 用されている。リソースマネージャは複数のリソースを統合管理できる場合が多い。た だし、リソース種別ごとに管理方法が異なる。そのため、 1つのリソースマネージャ単 独で管理可能なリソースの種別は限定される。したがって、様々な種類のリソースを 有するシステムでは、複数のリソースマネージャによってシステム全体のリソース管理 が行われる。
[0003] し力も、各リソースの機能が高度化するのに伴い、各リソースを管理するためには、 専用のリソースマネージャを用いるのが一般的である。例えば、サーバ、ストレージ、 ネットワークなどのハードウェア機器毎にリソースマネージャが設けられたり、各社製 品向けに独自のリソースマネージャが設けられたりする。このような傾向が促進される ことは、処理の分散、独自機能の最適利用などを考慮すると、しごく自然な流れであ る。
[0004] 複数のリソースマネージャが同一システム上で稼働していると、リソースの構成変更 などの各種操作がシステムの広範囲に及ぶ場合には、リソースマネージャ間で協調 動作する必要がある。
[0005] ところが、一般的には、リソースマネージャごとに、外部とメッセージの受け渡しをす るためのインタフェースが異なっている。そのため、複数のリソースマネージャを相互 に連携して運用するのは困難である。例えば、新規にサーバとストレージ製品を導入 したとしても、サーバ'リソースマネージャとストレージ 'リソースマネージャとの間で相 互接続できない。そのため、サーバ'リソースマネージャ、ストレージ 'リソースマネー ジャそれぞれに対してまったく独立に、管理者が手動で環境設定内容を指示しなけ ればならない。その結果、設定ミスなどにより両者を正しく接続できないといったトラブ ルが発生しやすくなり、サービス運用に支障をきたす原因となっていた。
[0006] そこで、異なるアーキテクチャの元で作られたリソースマネージャが混在するへテロ 環境における複数のリソースマネージャによるシステム運用が不可欠となる。すなわ ち、管理対象リソースとの間で独自プロトコルで通信することが前提として設計されて いる専用のリソースマネージャ相互の通信技術が必要である。
[0007] 例えば、マネージャとリソースマネージャとの間に配置したエージェントで、インタフ エースの違いを吸収する技術がある。この技術では、マネージャとエージェント間の 通信は標準プロトコルを使い、エージェントは、受け取った操作要求をリソースマネー ジャ用の独自コマンドに変換する。これにより、開発負荷の低減、保守性の向上を図 る手段が提案されている (例えば、特許文献 1参照)。
特許文献 1：特開 10— 11347号公報
発明の開示
発明が解決しょうとする課題
[0008] し力し、エージェントによってコマンドを変更する手法では、独自プロトコルで通信を 行うリソースマネージャが複数存在した場合、対応が困難となる。すなわち、独自プロ トコルで通信を行うリソースマネージャが複数存在した場合、各リソースマネージャに 対応するエージェントは、他のリソースマネージャに応じた全てのプロトコルに対応す る必要がある。独自プロトコルで通信を行うリソースマネージャが追加される度に、他 の全てのリソースマネージャのエージェントを更新するのは、システム管理効率上困 難である。
[0009] 特に、今後は同一サイト内の統合運用管理から、企業内複数サイト間、企業間、さ らにはグリッドによる全世界的なリソース運用へと展開されると予想される。そのため、 リソースマネージャを階層化することで、大規模なシステムのリソース管理が求められ る。以上のことから、階層化されたヘテロ環境において、リソース管理間の相互接続 性が確保されることが望まれて ヽる。
[0010] 本発明はこのような点に鑑みてなされたものであり、各リソース管理機能における処 理内容の独自性を維持しながら、階層化されたリソース管理機能同士で相互に処理 を依頼できるリソース管理プログラム、リソース管理方法、およびリソース管理装置を 提供することを目的とする。
課題を解決するための手段
[0011] 本発明では上記課題を解決するために、図 1に示すような機能をコンピュータで実 現するリソース管理プログラムが提供される。本発明のリソース管理プログラムは、他 のリソース管理機能との間で処理を分担してリソースを管理するものである。このリソ ース管理プログラムを実行するコンピュータは、図 1に示す機能を有する。
[0012] 記憶手段 laは、依頼内容に応じた処理の少なくとも一部の実行内容が定義された アクションノヽンドラが処理の依頼内容毎に登録されたアクションノヽンドラテーブル laa を記憶する。アクションノヽンドラ検索手段 lbは、他のリソース管理機能との間で共通 化された共通データ構造で処理の依頼内容が示された第 1のアクションリクエスト 7a を受け取ると、第 1のアクションリクエスト 7aによる依頼内容を解析し、第 1のアクション リクエスト 7aに示される依頼内容に対応するアクションハンドラをアクションノヽンドラテ 一ブル laaから検索する。アクション実行手段 Idは、アクションノヽンドラ検索手段 lb で検出されたアクションノヽンドラを起動して、アクションノヽンドラに定義された処理を実 行し、第 1のアクションリクエスト 7aに示される依頼内容が未完了の場合、共通データ 構造で未完了分の処理の依頼内容を示す第 2のアクションリクエスト 7bを生成し、未 完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能に対して 第 2のアクションリクエスト 7bを送信する。
[0013] このような機能が実現されたコンピュータは、第 1のアクションリクエスト 7aが入力さ れると、アクションノヽンドラ検索手段 lbにより、第 1のアクションリクエスト 7aによる依頼 内容が解析され、第 1のアクションリクエスト 7aに示される依頼内容に対応するァクシ ヨンノヽンドラがアクションハンドラテーブル laaから検索される。すると、アクション実行 手段 Idにより、アクションノヽンドラ検索手段 lbで検出されたアクションノヽンドラが起動 され、起動されたアクションノヽンドラに定義された処理が実行され、第 1のアクションリ タエスト 7aに示される依頼内容が未完了の場合、共通データ構造で未完了分の処 理の依頼内容を示す第 2のアクションリクエスト 7bが生成され、未完了分の処理の対 象となる管理対象機器を管理する他のリソース管理機能に対して第 2のアクションリク ェスト 7bが送信される。
[0014] また、本発明では上記課題を解決するために、コンピュータにより、他のリソース管 理機能との間で処理を分担してリソースを管理するためのリソース管理方法において 、記憶手段が、依頼内容に応じた処理の少なくとも一部の実行内容が定義されたァ クシヨンノヽンドラが処理の依頼内容毎に登録されたアクションノヽンドラテーブルを予め 記憶しており、アクションハンドラ検索手段が、前記他のリソース管理機能との間で共 通化された共通データ構造で処理の依頼内容が示された第 1のアクションリクエスト を受け取ると、前記第 1のアクションリクエストによる依頼内容を解析し、前記第 1のァ クシヨンリクエストに示される依頼内容に対応するアクションノヽンドラを、前記アクション ハンドラテーブル力も検索し、アクション実行手段力 前記アクションノヽンドラ検索手 段で検出されたアクションノヽンドラを起動して、アクションノヽンドラに定義された処理を 実行し、前記第 1のアクションリクエストに示される依頼内容が未完了の場合、前記共 通データ構造で未完了分の処理の依頼内容を示す第 2のアクションリクエストを生成 し、未完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能に 対して前記第 2のアクションリクエストを送信する、ことを特徴とするリソース管理方法 が提供される。
[0015] さらに、本発明では上記課題を解決するために、他のリソース管理機能との間で処 理を分担してリソースを管理するリソース管理装置にぉ 、て、依頼内容に応じた処理 の少なくとも一部の実行内容が定義されたアクションノヽンドラが処理の依頼内容毎に 登録されたアクションノ、ンドラテーブルを記憶する記憶手段と、前記他のリソース管理 機能との間で共通化された共通データ構造で処理の依頼内容が示された第 1のァク シヨンリクエストを受け取ると、前記第 1のアクションリクエストによる依頼内容を解析し 、前記第 1のアクションリクエストに示される依頼内容に対応するアクションハンドラを 前記アクションノヽンドラテーブル力 検索するアクションノヽンドラ検索手段と、前記ァク シヨンハンドラ検索手段で検出されたアクションハンドラを起動して、アクションノヽンド ラに定義された処理を実行し、前記第 1のアクションリクエストに示される依頼内容が 未完了の場合、前記共通データ構造で未完了分の処理の依頼内容を示す第 2のァ クシヨンリクエストを生成し、未完了分の処理の対象となる管理対象機器を管理する 他のリソース管理機能に対して前記第 2のアクションリクエストを送信するアクション実 行手段と、を有することを特徴とするリソース管理装置が提供される。
発明の効果
[0016] 本発明では、共通データ構造で処理の依頼内容が示された第 1のアクションリクェ ストに応じて、依頼内容に対応するアクションノヽンドラに定義された処理を実行し、依 頼内容が未完了の場合、共通データ構造で未完了分の処理の依頼内容を示す第 2 のアクションリクエストを他のリソース管理機能に対して送信するようにした。これにより 、処理の依頼内容を定義するためのデータ構造が共通化されることで相互接続が可 能となるとともに、依頼された処理の実行内容はアクションノヽンドラによって独自の定 義が可能となる。し力も、未完了分の処理の依頼内容を第 2のアクションリクエストで 他のリソース管理機能に送信することで、階層化されたリソース管理機能で分散して 第 1のアクションリクエストに応じた処理を実行できる。
[0017] 本発明の上記および他の目的、特徴および利点は本発明の例として好ま U、実施 の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。
図面の簡単な説明
[0018] [図 1]実施の形態に適用される発明の概念図である。
[図 2]本実施の形態のシステム構成を示す図である。
[図 3]本発明の実施の形態に用いる管理サーバコンピュータのハードウェア構成例を 示す図である。
[図 4]リソース管理機能の構成を示す図である。
[図 5]システム RMの内部構造を示す図である。
[図 6]エージェントの内部構造を示す図である。
[図 7]アクション情報のデータモデルを示す UML(Unified Modeling Language)モデル 図である。
[図 8]アクションハンドラテーブルのデータ構造例を示す図である。 [図 9]アクションリクエストに応じたリソースマネージャの処理手順を示すフローチヤ一 トである。
[図 10]アクションリクエストに応じたエージェントの処理手順を示すフローチャートであ る。
[図 11]アクションリクエストの伝搬の概念を示す図である。
[図 12]ログ DBのデータ構造例を示す図である。
[図 13]統括管理を行う管理サーバコンピュータに格納されたアクションノヽンドラテープ ルの例を示す図である。
[図 14]サーバを管理する管理サーバコンピュータに格納されたアクションハンドラテ 一ブルの例を示す図である。
[図 15]ネットワーク機器を管理する下位の管理サーバコンピュータに格納されたァク シヨンハンドラテーブルの例を示す図である。
[図 16]Webサービスを提供可能なサーバコンピュータに格納されたアクションハンド ラテーブルの例を示す図である。
[図 17]サーバ追加処理の手順を示す第 1のシーケンス図である。
[図 18]サーバ追加処理の手順を示す第 2のシーケンス図である。
[図 19]サーバ追加処理の手順を示す第 3のシーケンス図である。
[図 20]サーバの構成情報を取得する際のアクションリクエストの伝搬図である。
[図 21]サーバの構成情報を取得する際に最初に出力されるアクションリクエストの例 を示す図である。
[図 22]システム RMで転送された後のアクションリクエストの例を示す図である。
[図 23]サーバを追加する際のアクションリクエストの伝搬図である。
[図 24]サーバを追加する際に最初に出力されるアクションリクエストの例を示す図で ある。
[図 25]システム RMで転送された後のアクションリクエストの例を示す図である。
[図 26]システム RMで転送された後のアクションリクエストの例を示す図である。
[図 27]システム RMで転送された後のアクションリクエストの例を示す図である。
発明を実施するための最良の形態 [0019] 以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態 の具体的な内容を説明する。
[0020] 図 1は、実施の形態に適用される発明の概念図である。図 1では、管理サーバコン ピュータ 1, 2, 3, 4に、本発明を適用したリソース管理プログラムが実装されている。 記憶手段 laは、アクションノヽンドラテーブル laaを記憶する。アクションノヽンドラテー ブル laaには、依頼内容に応じた処理の少なくとも一部の実行内容が定義されたァク シヨンハンドラが処理の依頼内容毎に登録されて 、る。
[0021] アクションハンドラ検索手段 lbは、他のリソース管理機能との間で共通化された共 通データ構造 (共通データフォーマット)で処理の依頼内容が示された第 1のァクショ ンリクエスト 7aを、他のリソース管理機能（図 1の例では、管理サーバコンピュータ 2内 のリソース管理機能)力 受け取ると、第 1のアクションリクエスト 7aによる依頼内容を 解析する。そして、アクションハンドラ検索手段 lbは、第 1のアクションリクエスト 7aに 示される依頼内容に対応するアクションノヽンドラをアクションハンドラテーブル laaか ら検索する。
[0022] アクション実行手段 Idは、アクションノヽンドラ検索手段 lbで検出されたアクションノヽ ンドラを起動して、アクションノヽンドラに定義された処理を実行する。なお、アクション ハンドラに定義された処理を実行しても、第 1のアクションリクエスト 7aに示される依頼 内容が未完了の場合がある。この場合、アクション実行手段 Idは、共通データ構造 で未完了分の処理の依頼内容を示す第 2のアクションリクエスト 7bを生成する。そし て、アクション実行手段 Idは、未完了分の処理の対象となる管理対象機器を管理す る他のリソース管理機能（図 1の例では、管理サーバコンピュータ 4内のリソース管理 機能）に対して第 2のアクションリクエスト 7bを送信する。
[0023] アクションリクエスト転送手段 lcは、アクションハンドラ検索手段 lbでアクションハン ドラが検出されな力つた場合、第 1のアクションリクエスト 7aに含まれる処理の対象とな る管理対象機器を管理する他のリソース管理機能（図 1の例では、管理サーバコンビ ユータ 3内のリソース管理機能）に対して、第 1のアクションリクエスト 7aと同じ依頼内 容を有する第 3のアクションリクエスト 7cを送信する。 [0024] このような機能を管理サーバコンピュータ 1が有していれば、第 1のアクションリクェ スト 7aが入力されると、アクションノヽンドラ検索手段 lbにより、第 1のアクションリクエス ト 7aによる依頼内容が解析される。そして、アクションノヽンドラ検索手段 lbにより、第 1 のアクションリクエスト 7aに示される依頼内容に対応するアクションノヽンドラがァクショ ンハンドラテーブル laaから検索される。
[0025] すると、アクション実行手段 Idにより、アクションノヽンドラ検索手段 lbで検出された アクションノヽンドラが起動され、起動されたアクションノヽンドラに定義された処理が実 行される。ここで、第 1のアクションリクエスト 7aに示される依頼内容が未完了の場合、 アクション実行手段 Idにより、共通データ構造で未完了分の処理の依頼内容を示す 第 2のアクションリクエスト 7bが生成される。そして、アクション実行手段 Idにより、未 完了分の処理の対象となる管理対象機器を管理する他のリソース管理機能に対して 第 2のアクションリクエスト 7bが送信される。
[0026] また、アクションノヽンドラ検索手段 lbでアクションノヽンドラが検出されな力つた場合、 アクションリクエスト転送手段 lcにより、第 1のアクションリクエスト 7aに含まれる処理の 対象となる管理対象機器を管理する他のリソース管理機能に対して、第 1のァクショ ンリクエスト 7aと同じ依頼内容を有する第 3のアクションリクエスト 7cが送信される。
[0027] なお、第 1のアクションリクエスト 7a、第 2のアクションリクエスト 7b、および第 3のァク シヨンリクエスト 7cには、例えば、そのアクションリクエストを生成したリソース管理機能 の名称、中継したリソース管理機能の名称、そして操作対象のリソースに関する情報 、操作対象リソースの作用部分に関する情報、および実行したいアクションの内容が 格納される。
[0028] このような共通データ構造で依頼内容が定義されたアクションリクエストを、管理サ 一バコンピュータ 1一 4に実装されたリソース管理機能で受け渡すことで、各管理サー ノコンピュータ 1一 4では、受け取ったアクションリクエストによる依頼内容を解析でき る。し力も、依頼内容に応じた実行内容は、アクションノヽンドラで独自に定義すること ができる。そのため、各リソース管理機能独自の高度な管理機能を維持したまま、リソ ース管理機能間のアクションリクエストの受け渡しが可能となる。
[0029] すなわち、リソース管理機能間でやりとりされるアクションリクエストのデータフォーマ ットを共通化したことで、処理を依頼する側では、依頼相手の処理機能に依存せず にアクションリクエストを生成できる。そして、アクションリクエストで示された依頼内容 は、アクションノヽンドラテーブル laaを介して、各リソース管理機能毎の高度なリソース 管理を行うアクションノヽンドラに対応付けられる。
[0030] その結果、独自プロトコルでのメッセージ交換を前提に作られたリソースマネージャ 同士の協働処理が可能となる。例えば、異なるオペレーティングシステム (OS)が搭 載された 2台のサーバコンピュータで、同じ内容のリソース管理処理を実行する場合 、各サーバコンピュータでは、異なるコンポーネントが機能している。このような場合で も、外部のリソースマネージャからは同じ内容のアクションリクエストを送れば良ぐ相 互運用がやりやすくなる。
[0031] し力も、アクションノヽンドラに基づく処理を実行しても、まだ依頼内容が未完了の場 合、未完了の処理に応じたアクションリクエストが出力される。これにより、リソース管 理機能が階層構造を採っている場合であっても、上位のリソース管理機能力 下位 のリソース管理機能へ、自動的に処理が依頼される。
[0032] すなわち、最初に第 1のアクションリクエスト 7aを出力した管理サーバコンピュータ 2 では、管理サーバコンピュータ 1より先のリソース管理機能力 階層構造になっている か否かを認識する必要がない。その結果、階層構造でリソース管理が行われている システムであっても、アクションリクエストによる処理の依頼が容易となる。
[0033] 次に、本発明の実施の形態について詳細に説明する。なお、以下の説明では、リソ ースを管理する管理サーバコンピュータに配置されたリソース管理機能を、リソースマ ネージャと呼ぶ。また、管理対象であるリソースを有する機器に配置され、リソースマ ネージャの指示に従ってリソースを管理するリソース管理機能をエージェントと呼ぶ。 また、リソースマネージャとエージェントとの双方のリソース管理機能を纏めて、コンポ 一ネントと呼ぶ。
[0034] さらに、以下の説明で単に「サーバ」と呼んだ場合は、サーバアプリケーションをコン ピュータが実行することによって実現されるサーバ機能を指すものとする。「サーバコ ンピュータ」と呼んだ場合は、サーバアプリケーションを実行するコンピュータを指す。
[0035] なお、以下の実施の形態では、図 1に示した機能に加え、各コンポーネントは、送 受信したアクションリクエストや実行したアクション等のログを格納するデータベースを 有する。送受信したアクションリクエストおよびアクション実行のログを各コンポーネン トで保持しておくことにより、対象アクションリクエストが影響を及ぼしたコンポーネント 、リソースを追跡することができ、アクションの取り消しや影響範囲の可視化などを容 易に行えるようになる。
[0036] 図 2は、本実施の形態のシステム構成を示す図である。本実施の形態では、クライ アント 21, 22, · · ·に対してネットワーク 10を介してサービスを提供するシステムを想 定している。この実施の形態では、複数のサイト 100, 200に分けてリソースが管理さ れている。なお、図 2において、システム管理用の接続関係は、破線で示されている
[0037] サイト 100には、管理サーバコンピュータ 110, 120, 130、サーバコンピュータ 140 , 150、およびネットワーク機器 160, 170力属している。管理サーバコンピュータ 11 0は、管理サーバコンピュータ 120, 130に接続されており、サイト 100内の全体のリ ソースを統括管理する。管理サーバコンピュータ 120は、サーバコンピュータ 140, 1 50に接続されており、サーバコンピュータ 140, 150で提供されるリソースを管理する 。管理サーバコンピュータ 130は、ネットワーク機器 160, 170に接続されており、ネッ トワーク機器 160, 170で提供されるリソースを管理する。
[0038] サーバコンピュータ 140, 150は、ネットワーク 10を介してクライアント 21, 22, · · · に接続されており、例えば、 Webサーバアプリケーション等の機能をクライアント 21, 22, · · ·に対して提供する。ネットワーク機器 160, 170は、サーバコンピュータ 140, 150と、サイト 200に属するストレージ装置 230, 240との間に接続されており、各装 置間のパケット転送機能を有する。
[0039] サイト 200には、管理サーバコンピュータ 210, 220およびストレージ装置 230, 24 0が属している。管理サーバコンピュータ 210は、管理サーバコンピュータ 220に接 続されており、サイト 100内の全体のリソースを統括管理する。管理サーバコンビユー タ 220は、ストレージ装置 230, 240に接続されており、ストレージ装置 230, 240で 提供されるリソースを管理する。ストレージ装置 230, 240は、情報の記憶および管理 を行っており、サーバコンピュータ 140, 150に対して情報の入出力機能を提供する [0040] 図 3は、本発明の実施の形態に用いる管理サーバコンピュータのハードウェア構成 例を示す図である。管理サーバコンピュータ 110は、 CPU(Central Processing Unit) 110aによって装置全体が制御されている。 CPUl lOaには、バス l lOgを介して RA M(Random Access Memory) 110b,ハードディスクドライブ（HDD:Hard Disk Drive) 110c,グラフィック処理装置 110d、入力インタフェース 110e、および 1つまたは複数 の通信インタフェース 110fが接続されて 、る。
[0041] RAMI 10bには、 CPUl lOaに実行させる OS(Operating System)のプログラムゃァ プリケーシヨンプログラムの少なくとも一部が一時的に格納される。また、 RAMI 10b には、 CPUl lOaによる処理に必要な各種データが格納される。 HDDl lOcには、 O Sやアプリケーションプログラムが格納される。
[0042] グラフィック処理装置 110dには、モニタ 11が接続されている。グラフィック処理装置 110dは、 CPUl lOaからの命令に従って、画像をモニタ 11の画面に表示させる。入 力インタフェース 110eには、キーボード 12とマウス 13とが接続されている。入力イン タフエース 110eは、キーボード 12やマウス 13から送られてくる信号を、バス l lOgを 介して CPU110aに送信する。
[0043] 通信インタフェース 110fは、ネットワークに接続されて 、る。通信インタフェース 11 Ofは、ネットワークを介して、他のコンピュータとの間でデータの送受信を行う。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現すること ができる。なお、図 3には、管理サーバコンピュータ 110のハードウェア構成のみを示 したが、他の管理サーバコンピュータ 120, 130,サーバコンピュータ 140, 150、管 理サーバコンピュータ 210, 220、ストレージ装置 230, 240、も同様のハードウェア 構成で実現することができる。
[0044] 図 4は、リソース管理機能の構成を示す図である。まず、サイト 100、 200それぞれ に属する各装置が有する機能およびデータについて説明する。
管理サーバコンピュータ 110内には、アクションハンドラテーブル 11 laとログ DB ( データベース） 11 lbとを有するシステム RM (リソースマネージャ） 111が設けられて いる。管理サーバコンピュータ 120内には、アクションハンドラテーブル 121aとログ D B (データベース） 12 lbとを有するサーバ RM (リソースマネージャ） 121が設けられて いる。管理サーバコンピュータ 130内には、アクションハンドラテーブル 131aとログ D B (データベース） 13 lbとを有するネットワーク RM (リソースマネージャ） 131が設けら れている。
[0045] サーバコンピュータ 140内には、アクションハンドラテーブル 141aとログ DB (データ ベース） 141bとを有するエージェント 141が設けられている。サーバコンピュータ 150 内には、アクションハンドラテーブル 15 laとログ DB (データベース） 151bとを有する エージェント 151が設けられて!/、る。
[0046] システム RM111は、サイト 100全体もしくはその一部分を統合管理する上位のリソ ースマネージャである。システム RM111は、サーバ RM121、ネットワーク RM131と 連携して、サイト 100内の全リソースを管理することができる。
[0047] サーバ RM121は、エージェント 141, 151と連携して、サーバコンピュータ 140, 1 50で提供されるリソースを管理する。ネットワーク RM130は、ネットワーク機器 160, 170で提供されるリソースを管理する。エージェント 141, 151は、サーバ RM121か らの指示に従って、それぞれサーバコンピュータ 140, 150内のリソースを管理する。
[0048] 管理サーバコンピュータ 210内には、アクションハンドラテーブル 21 laとログ DB ( データベース） 21 lbとを有するシステム RM (リソースマネージャ） 211が設けられて いる。管理サーバコンピュータ 220内には、アクションハンドラテーブル 221aとログ D B (データベース） 221bとを有するストレージ RM (リソースマネージャ） 221が設けら れている。
[0049] ストレージ装置 230内には、アクションハンドラテーブル 23 laとログ DB (データべ ース） 231bとを有するエージェント 231が設けられている。ストレージ装置 240内には 、アクションハンドラテーブル 241aとログ DB (データベース） 241bとを有するエージ ェント 241が設けられている。
[0050] システム RM211は、サイト 200全体もしくはその一部分を統合管理する上位のリソ ースマネージャである。システム RM211は、ストレージ RM221と連携して、サイト 20 0内の全リソースを管理することができる。
[0051] ストレージ RM221は、エージェント 231, 241と連携して、ストレージ装置 230, 24 0で提供されるリソースを管理する。エージェント 231, 241は、ストレージ RM241力 らの指示に従って、それぞれストレージ装置 230, 240内のリソースを管理する。
[0052] 各装置に設けられたアクションハンドラテーブル 11 la, 121a, 131a, 141a, 151a , 211a, 221a, 231a, 241aは、各装置に送られたアクション情報に応じた処理を実 行する。各装置に設けられたログ DB1 l ib, 121b, 131b, 141b, 151b, 211b, 2 21b, 231b, 241bには、各装置に送られたアクション情報および各装置で生成され たアクション情報の履歴が格納される。
[0053] ここで、各機能間の通信インタフェースについて説明する。システム RM111とサー バ RM211との間、システム RM111とサーバ RM121との間、システム RM111とサ ーバ RM131との間、サーバ RM121とエージェント 141との間、サーバ RM131とェ ージェント 151との間、システム RM211とストレージ RM221との間、ストレージ RM2 21とエージェント 231との間、ストレージ RM211とエージェント 241との間は、それぞ れ共通インタフェース 21— 28で相互に接続される。
[0054] また、ネットワーク RM131とネットワーク機器 160, 170との間は、共通化されてい な 、非共通インタフェース 31で接続される。共通化されて!/、な 、非共通インタフエ一 ス 31としては、例えば、 SNMP(Simple Network Management Protocol)や CLI (Command-Line Interface)などの標準化されたインタフェースが用いられる。
[0055] なお、図 4に示す各リソースマネージャは、対象リソースを直接管理する以外にも、 複数のリソースを仮想的に 1つのリソースとしたり、同じアーキテクチャのリソース群を グルーピングしたり、様々な管理機能を提供することができる。
[0056] また、図 4では、サイト 100内では、システム RM110の下位構造にサーバ RM121 とネットワーク RM131とが配置された 2階層構造になっている。同様に、サイト 200内 では、システム RM210の下位構造にストレージ RM221が配置された 2階層構造に なっている。この階層構造は、一例であり、より深い階層構造になっていてもよい。
[0057] なお、ネットワーク機器 160, 170のようにエージェントが設けられていない場合、当 該リソースに対して実行できるアクションは外部力 指示可能なアクションに限定され る。
[0058] また、本実施の形態は、説明の便宜上、 2つのサイト、 2台のサーバ機器、 2台のスト レージ機器、および 1台のネットワーク機器の構成例を示しているが、任意数のサイト
、サーバ機器、ストレージ機器、およびネットワーク機器で構成可能である。
[0059] 以上の構成において、リソースマネージャ間、リソースマネージャ 'エージェント間の 通信は共通インタフェース 21— 28を用いて行われる。ただし、エージェントが備わつ ていないリソースと当該リソースのマネージャ間は独自インタフェースや SNMPなど の非共通インタフェース 31が用 、られる。
[0060] 上記の構成において、例えば、システム RM211から、サーバコンピュータ 140が実 行すべきアクションを含むアクション情報が発行された場合を考える。この場合、ァク シヨン情報が、システム RM211から共通インタフェース 21を使用してシステム RM11 1に渡される。
[0061] システム RM111は、アクションハンドラテーブル 11 laを参照して、受け取ったァク シヨン情報に応じたアクションを判断する。そして、システム RM111は、 自分が実行 すべきアクションを実行すると共に、サーバ RM121に接続されたサーバコンピュータ 140に対するアクション情報であることを認識し、共通インタフェース 22を介して、ァク シヨン情報をサーバ RM121に送信する。この際、システム RM111は、受け取ったァ クシヨン情報の内容、システム RM111で実行したアクションの内容、および送信した アクション情報の内容をログ DB1 l ibに格納する。
[0062] サーバ RM121は、アクションハンドラテーブル 121aを参照して、受け取ったァクシ ヨン情報に応じたアクションを判断する。そして、サーバ RM121は、 自分が実行すベ きアクションを実行すると共に、サーバコンピュータ 140に対するアクション情報であ ることを認識し、共通インタフェース 24を介して、アクション情報をエージェント 141に 送信する。この際、サーバ RM121は、受け取ったアクション情報の内容、サーバ RM 121で実行したアクションの内容、送信したアクション情報の内容をログ DB 12 lbに 格納する。
[0063] エージェント 141は、アクションハンドラテーブル 141aを参照して、受け取ったァク シヨン情報に応じた処理を判断し、その処理を実行する。この際、エージェント 141は 、受け取ったアクション情報の内容とエージェント 141が実行したアクションの内容と をログ DB 14 lbに格納する。 [0064] このように、システム RM211で発行されたアクション情報力 システム RM111、サ ーバ RM121、エージェント 141と順に伝達され、そして最終的にエージェント 141に よって指定されたアクション情報に対応するコマンド等が実行される。
[0065] 次に、図 4に示す各コンポーネント（リソースマネージャとエージェント）が有する機 能について具体的に説明する。
図 5は、システム RMの内部構造を示す図である。システム RM111は、アクションハ ンドラテーブル 11 la、ログ DBl l lb、複数のアクションハンドラ 11 lc、アクションハン ドラ検索部 l l ld、アクションリクエスト転送部 11 le、アクション実行部 11 If、および口 グ採取部 11 lgを有して 、る。アクションハンドラテーブル 11 laとログ DB11 lbとの内 容は、図 4を用いて説明した通りである。
[0066] 複数のアクションノヽンドラ 111cは、アクション情報に応じて実行するリソース管理処 理の内容が記述されたプログラム (コマンドやスクリプト等)である。
アクションハンドラ検索部 11 Idは、他のコンポーネントからアクションリクエスト 33を 受け取ると、アクションハンドラテーブル 11 la参照し、そのアクションリクエスト 33で示 されるアクションに対応するアクションノヽンドラを検索する。そして、アクションハンドラ 検索部 11 Idは、検出されたアクションノヽンドラの名称をアクション実行部 11 Ifに通 知する。また、アクションノヽンドラを検出できな力つた場合、アクションノヽンドラ検索部 1 1 Idは、対応するアクションハンドラが無 、ことをアクションリクエスト転送部 11 leに通 知する。
[0067] アクションリクエスト転送部 1 l ieは、アクションハンドラ検索部 11 Idからの通知によ り、アクションリクエスト 33に対応するアクションノヽンドラが無いことを認識し、アクション リクエスト 33で示されるアクションを実行すべき他のコンポーネントを判断する。例え ば、アクションリクエスト 33で示される管理対象がサーバであれば、アクションリクエス ト転送部 1 l ieは、サーバ RM121を、アクションリクエスト 33で示されるアクションを実 行すべきコンポーネントと判断する。そして、アクションリクエスト転送部 1 l ieは、ァク シヨンリクエスト 33で示されるアクションを実行すべきコンポーネントに対して、ァクショ ンリクエスト 33と同じアクションを依頼するアクションリクエスト 34を送信する。
[0068] アクション実行部 11 Ifは、アクションハンドラ検索部 11 Idからアクションハンドラの 名称を受け取ると、複数のアクションノヽンドラ l l lcの中力 該当するアクションノヽンド ラを取得する。そして、アクション実行部 11 Ifは、取得したアクションノヽンドラを起動し
、そのアクションノヽンドラで定義されて 、る処理を実行する。
[0069] このとき、起動したアクションハンドラにおいて、他のコンポーネントへの依頼すべき 処理が発生すると、アクション実行部 11 Ifは、新たなアクションを生成する。そして、 アクション実行部 11 Ifは、生成したアクションを依頼するためのアクションリクエスト 35 を、他のコンポーネントへ送信する。また、アクション実行部 11 Ifは、処理が終了する と、アクションリクエスト 33におけるアクションの生成元に対して、処理結果 36を応答 する。
[0070] なお、アクションリクエストを定義した共通化データ構造では、複数の処理を依頼す ることができると共に、各処理の実行順を指定可能である。入力されたアクションリク ェストにお 1、て複数処理の実行順が指定されて!、た場合、アクション実行部 11 Ifは 、指定された順に、各処理に対応するアクションハンドラを起動する。
[0071] ログ採取部 11 lgは、アクションリクエスト転送部 1 l ieとアクション実行部 11 Ifから、 実行した処理の内容をログ情報として取得する。そして、ログ採取部 11 lgは、取得し たログ情報をログ DB11 lbに格納する。
[0072] 以上のような機能をシステム RM111が有していることで、他のコンポーネントとの間 で、共通インタフェースを用いたアクションリクエストの受け渡し、および受け取ったァ クシヨンリクエストで指定されたアクションの実行が可能となる。なお、図 5には、システ ム RM111の機能を示した力 他のリソースマネージャも同様の機能を有して 、る。
[0073] 図 6は、エージェントの内部構造を示す図である。エージェント 141は、アクションハ ンドラテーブル 141a、ログ DB141b、複数のアクションハンドラ 141c、アクションハン ドラ検索部 141d、アクション実行部 141e、およびログ採取部 141fを有している。ァク シヨンハンドラテーブル 141a、ログ DB141b、複数のアクションハンドラ 141cについ ては、それぞれシステム RM111のアクションハンドラテーブル 11 la、ログ DBl l lb、 複数のアクションノヽンドラ 11 lcと同様の情報である。
[0074] アクションハンドラ検索部 141dは、図 5に示したシステム RM111のアクションハンド ラ検索部 11 Idと同様に、アクションリクエスト 37に応じて、アクションハンドラテーブル 14 laからアクションノヽンドラを検索する。ただし、検索により該当するアクションノヽンド ラが検出されない場合には、アクションリクエスト 37の送信元に対してエラーメッセ一 ジを応答する。
[0075] アクション実行部 141eは、図 5に示したシステム RM111のアクション実行部 11 Ifと 同様に、アクションノヽンドラ検索部 141dで検出されたアクションノヽンドラに基づいて 処理を実行し、処理結果 38を出力する。但し、他のコンポーネントに対するアクション リクエストの生成処理は行われない。ログ採取部 141fは、アクション実行部 141eの 処理内容等のログを、ログ DB141bに格納する。
[0076] このように、エージェント 141は、他のコンポーネントへ処理を依頼する必要がない 。そのため、エージェント 141には、アクションリクエスト転送部 1 l ieに対応する機能 は不要である。なお、図 6には、サーバコンピュータ 140のエージェント 141の機能を 示したが、他のエージェントも同様の機能を有している。
[0077] 次に、アクション情報のデータ構造について詳細に説明する。共通インタフェースと してコンポーネント間で交換されるアクション情報には、当該指示を生成したコンポ一 ネント、中継したコンポーネント、そして操作対象のリソースに関する情報と、操作対 象リソースの作用部位に関する情報およびアクションの種別情報が含まれる。
[0078] 図 7は、アクション情報のデータモデルを示す UML(Unified Modeling Language)モ デル図である。以下、要素に含まれるデータの内容について説明する。
ActionRequest要素 41は最上位の要素である。 ActionRequest要素 41を単位として コンポーネント間でアクションリクエストが送受信される。 ActionRequest要素 41は、属 性として IDと生成された日時を示す createDateとを有する。また、 ActionRequest要素 41は、 Creator要素 42、 Sender要素 43、および ActionEntity要素 47を内容として保 持する。
[0079] Creator要素 42では、アクションを生成したコンポーネント情報（リソースマネージャ の識別情報)を有する。
Sender要素 43は、アクションリクエストを転送してきた転送元のコンポーネント情報 を有する。
[0080] ManagedObject要素 44は、操作実行対象となるコンポーネントもしくはリソースを意 味する。 ManagedObject44は責務に応じてさらに 3つの Creator要素 42、 Sender要素 43、 Target要素 50に派生する。また、 ManagedObject要素 44は、属性として名前属 性である nameおよび IDを有する。
[0081] ActionGroup要素 45はアクションの集合を表すクラスである。 ActionGroup要素 45 には、 1つ以上の ActionEntity要素 47が含まれる。また、 ActionGroup要素 45は、 ActionGroup要素 45に含まれる複数の ActionEntitty要素 47の実行順序を指定する order属性を有する。
[0082] Action要素 46は個々のアクション内容を表す抽象クラス (抽象的な定義を行うクラス であり、インスタンスを生成できず、継承を行うことを前提としたクラス)である。
ActionEntity要素 47はアクション内容を示す抽象クラスであり、 Action要素 46およ び ActionGroup要素 45が派生する。 ActionRequest要素 41には 1つの ActionEntity要 素 47のみ含まれるが、それは ActionRequest要素 41に含まれるのが Action要素 46で も ActionGroup要素 45でもよいことを意味する。つまり、アクションリクエストとして、単 一のアクションを指定する以外に、複数のアクション力 成るアクショングループを指 定したり、また内部にさらに複数のアクショングループが含まれる階層構造を成すァク シヨングループを指定したりすることも可能である。また、 ActionEntity要素 47は ID属 性と、結果が返ってくるまで待つかどうかを指定する sync属性、および当該アクション の優先度を示す priority属性を持ってもょ 、。
[0083] GetAction要素 48と SetAction要素 49とは、共に Actionクラスの具象クラス（抽象クラ スではないクラス）である。 GetAction要素 48と SetAction要素 49とは、それぞれ情報 取得 (get)、情報設定 (set)系のアクションを指定する際に使用される。 get, set以外に も、アクション実行対象に対してどのようなアクションを実行可能かは予め定義してァ クシヨンノヽンドラテーブルに登録しておくことにより、その中力も適切なアクションを GetAction要素 48、 SetAction要素 49と同様の形で、アクションリクエストに指定するこ とがでさる。
[0084] Target要素 50は、アクションを実行する対象のオブジェクトを指定している。一般的 にはサーバ Zストレージ Zネットワーク Zソフトウェアと 、つたリソースが、アクションの 実行対象である。なお、サービスや複数のサーバを論理的にグループ化したサーバ ドメインなどもターゲットとすることができる。
[0085] Target要素 50は、ターゲット種類を示す属性として class属性を有する。さらに、
Target要素 50は、そのクラスの具体的にどのインスタンスかを示す情報として name, id属性を有する。また、 Target要素 50内には、どのサイトにあるターゲットなのかを指 定する site属性も存在する。
[0086] Property要素 51は、アクションが作用する部位を指定するための要素であり、
Target要素 50で指定されたオブジェクトの状態や構成を指し示す。 Property要素 51 は、属性として、作用する部位のキーを指定する key属性を有する。また、 Property要 素 51は、設定系のアクションの場合には指定された部位に対する設定値を value属 性に指定する。 Property要素 51は、状態を表す State要素 52、構成を表す
Configuration要素 55へと派生する。
[0087] State要素 52は、対象オブジェクトの状態を指す。サーバの使用率やソフトウェアの START/STOP状態などの状態が State要素 52として扱われ、その状態のオブジェクト に対して取得 '設定などのアクションが実行される。 State要素 52は、さらに
InternalState要素 53、 ExternalState要素 54に派生する。
[0088] InternalState要素 53は、対象オブジェクトの内部状態を示している。例えば、サー バの CPU使用率やソフトウェアの START/STOP状態などが nternalState要素 53に該 当する。
[0089] ExternalState要素 54は、対象オブジェクトの外部状態を指す。これは、外部（対象 オブジェクト以外の要素）から観測される対象オブジェクトの状態のことである。例え ば、サーバの生死状態などが、外部状態に該当する。したがって、 ExternalState要素 54のクラスを指定したアクションの場合は、対象オブジェクトを監視するコンポーネン トが責任を持って対応しなければならないことを意味する。
[0090] Configuration要素 55は、対象オブジェクトの構成'設定を指す。対象オブジェクトに 含まれるリソース量の増減や設定パラメータなどが Configuration要素 55として扱われ 、それに対して取得'設定などのアクションが実行される。 Configuration要素 55のクラ スは、さらに Structure要素 56、 Parameter要素 57に派生する。
[0091] Configuration要素 55には、ファイルなど外部エンティティを参照するための uri属性 が設けてある。外部エンティティとはファイルや Webページなどであり、取得'設定し た 、構成情報などが格納されて 、ることを想定して 、る。格納されて 、る情報のフォ 一マットに関しては、当該アクションを実行するコンポーネントが解釈できる形式であ ればよい。
[0092] Structure要素 56は、対象オブジェクトの構成を指す。例えば、サーバドメインに登 録されているサーバ群やサービスを構成するアプリケーションの組み合わせなどが該 当する。
[0093] Parameter要素 57は、対象オブジェクトの設定を指す。例えば、ソフトウェアが使用 するメモリ量やスィッチの VLAN(Virtual Local Area Network)の設定などが該当する
[0094] 図 7に示すように、データには上記以外の例えばアクション生成日時情報など付加 情報を含んでいてもよい。また、データ形式は、最低限上記情報が含まれていれば どのような形式で送受信してもよいが、可搬性、拡張性の観点から XML(eXtensible Markup Language)形式力望 しい。
[0095] 図 8は、アクションハンドラテーブルのデータ構造例を示す図である。アクションハン ドラテーブル 102には、対象種別、プロパティ、アクション、および実行内容の各項目 が設けられており、各項目のデータが互いに関連付けられ、 1つのレコードとして登 録されている。
[0096] 対象種別には、アクションが作用する対象の種別が設定される。例えば、サービス ( ユーザに提供されるサービス) Zサーバ（サービスを提供するための処理を行う処理 機能) Zネットワーク機器 Zソフトウェア等が、種別として設定される。
[0097] プロパティには、アクションが作用する対象の属性が設定される。例えば、構成 (シ ステム構成に関する処理) Zパラメータ (パラメータの設定等の操作) Z状態 (運用状 態の監視処理)などが、プロパティに設定される。
[0098] アクションには、アクションが作用する対象オブジェクトのプロパティに対して実行可 能なアクションの種別が設定されている。例えば、「set」 「get」が設定される。
実行内容には、実際に実行されるコマンドやスクリプト等のアクションノヽンドラの識別 情報 (例えば、ファイル名）が設定される。 [0099] 次に、各コンポーネントがアクションリクエストを受け取った際の処理について説明 する。
図 9は、アクションリクエストに応じたリソースマネージャの処理手順を示すフローチ ヤートである。以下、図 9に示す処理をステップ番号に沿って説明する。ここで、シス テム RM111に対してアクションリクエストが送られた場合のシステム RM111の処理 として説明する力 他のリソースマネージャでも同様の処理が行われる。
[0100] [ステップ S11]システム RM111のアクションハンドラ検索部 l l ldは、アクションリク ェスト 33を受信する。
[ステップ S 12]アクションノヽンドラ検索部 11 Idは、受信したアクションリクエスト 33 内のアクションを解釈して、そのアクションに対応するアクションハンドラがアクション ハンドラテーブル 11 laに登録されているかどうか検索する。具体的には、アクション ハンドラ検索部 11 Idは、アクションハンドラテーブル 11 laを参照し、アクションリクェ ストに記載されている対象オブジェクト種別、プロパティ、アクション種別をキーに、適 切なレコードを検索する。そして、検索の結果合致するレコードがあった場合には、ァ クシヨンノヽンドラ検索部 11 Idは、合致するレコードの実行内容 (アクションノヽンドラの 名称)を取得する。
[0101] [ステップ S 13]アクションハンドラ検索部 11 Idは、アクションハンドラが登録されて いれば、そのアクションノヽンドラの名称をアクション実行部 11 Ifに通知し、処理をステ ップ S16に進める。また、アクションハンドラ検索部 11 Idは、アクションハンドラが登 録されていなければ、アクションノヽンドラが登録されていな旨をアクションリクエスト転 送部 l l leに通知し、処理をステップ S 14に進める。
[0102] [ステップ S 14]アクションリクエスト転送部 l l leは、アクションハンドラテーブル 111 aに合致するレコードが登録されていな力つた場合には、アクションリクエスト 33の送 信元情報（Sender)を修正する。具体的には、システム RM111は、アクションリクエス ト 33の送信元情報を、自分自身の識別情報に書き換える。
[0103] [ステップ S 15]アクションリクエスト転送部 l l leは、アクションリクエスト 33を処理す るのに適切なコンポーネントに対して、ステップ S14で修正したアクションリクエスト 34 を転送する。その後、処理がステップ S 21に進められる。 [0104] [ステップ S16]アクション実行部 l l lfは、アクションハンドラテーブル 11 laを参照 したときに、アクションに記載されている対象オブジェクト種別、プロパティ、およびァ クシヨン種別をキーに適切なレコードを検索し、合致するものがあった場合には、合 致したレコードの実行内容として記載されているアクションノヽンドラ (コマンド、スクリブ ト等）を実行する。この際、アクション実行部 11 Ifは、アクション内容を、指定されたコ マンド、スクリプトの入力に適切な形式に変換して、コマンドやスクリプトの実行プロセ スに渡す。
[0105] [ステップ S 17]アクション実行部 11 Ifは、アクションリクエスト 33を満たすために必 要な全ての処理が完了して!/ヽる力否かを判断する。全ての処理が完了して!/ヽれば、 処理がステップ S20に進められ、未完了の処理があれば、処理がステップ S18に進 められる。
[0106] [ステップ S18]アクション実行部 l l lfは、アクションリクエスト 33を満たすための未 完了の処理があれば、その処理を実行するための新規のアクションリクエスト 35を作 成する。
[0107] [ステップ S 19]アクション実行部 11 Ifは、アクションリクエスト 33の未完了の処理を 実行するのに適切なコンポーネントに対して、ステップ S18で作成したアクションリク ェスト 35を送信する。その後、処理がステップ S21に進められる。
[0108] [ステップ S20]アクション実行部 11 Ifは、アクションリクエスト 33を満たすために必 要な全ての処理が完了した場合は、その実行結果をリクエスト送信元に返す。
[ステップ S21]システム RM111は、処理内容をログ DB1 l ibに格納する。その後 、処理が終了する。
[0109] 次に、アクションリクエストに応じたエージェントの処理について説明する。
図 10は、アクションリクエストに応じたエージェントの処理手順を示すフローチャート である。以下、図 10に示す処理をステップ番号に沿って説明する。ここで、エージ ント 141に対してアクションリクエストが送られた場合のエージェント 141の処理として 説明する力 他のエージヱントでも同様の処理が行われる。
[0110] [ステップ S31]アクションノヽンドラ検索部 141dは、アクションリクエスト 37を受信す る。 [ステップ S32]アクションノヽンドラ検索部 141dは、受信したアクションリクエスト 37 内のアクションを解釈して、そのアクションに対応するアクションハンドラをアクションハ ンドラテーブル 141aから検索する。具体的には、アクションノヽンドラ検索部 141dは、 アクションハンドラテーブル 141aを参照し、アクションリクエスト 37に記載されている 対象オブジェクト種別、プロパティ、アクション種別をキーに、適切なレコードを検索 する。そして、検索の結果合致するレコードがあった場合には、アクションノヽンドラ検 索部 141dは、合致するレコードの実行内容 (アクションノ、ンドラの名称)を取得する。
[0111] [ステップ S33]アクション実行部 141eは、アクションハンドラテーブル 141aを参照 したときに、アクションに記載されている対象オブジェクト種別、プロパティ、アクション 種別をキーに適切なレコードを検索し、合致したレコードの実行内容として記載され ているコマンド、スクリプト等を実行する。この際、アクション実行部 141eは、ァクショ ン内容を、指定されたコマンド、スクリプトの入力に適切な形式に変換して、コマンド やスクリプトの実行プロセスに渡す。
[0112] [ステップ S34]アクション実行部 141eは、実行結果をリクエスト送信元に返す。
[ステップ S35]アクション実行部 141eは、処理内容をログ DB141bに格納する。そ の後、処理が終了する。
[0113] このように、エージェント 141は、他のコンポーネントにアクションリクエストを送信す る必要はないため、アクションリクエストの変更、生成等の処理は行われない。
図 9、図 10に示したフローチャートからも明らかのように、本実施の形態のシステム では、生成元力 アクションを実行するコンポーネントにアクションリクエストが直接配 送されるとは限らない。
[0114] 図 11は、アクションリクエストの伝搬の概念を示す図である。この図には、 7つのコン ポーネント 61— 67が示されている。コンポーネント 61— 67は、リソースマネージャも しくはリソース上で稼動するエージェントである。図中、各コンポーネント 61— 67内に は、そのコンポーネントで生成される力、あるいは他のコンポーネントから渡されたァ クシヨン 61a, 62a, 63a, 63b, 63c, 63d, 63e力 ^示されて!/ヽる。同一のアクション【ま 、同じ形状、同じ模様で示されている。
[0115] 図 11において、コンポーネント 61で生成されたアクション 61aは、まずコンポーネン ト 62に送信される。すると、コンポーネント 62において、別のアクションリクエストに変 更される。つまり、コンポーネント 62のアクションハンドラテーブルに、受け取ったァク シヨンリクエストに該当するアクションノ、ンドラが登録してあり、そのハンドラを呼び出し た結果新たなアクション 62aが生成されたことを意味する。このような状況になるのは 、以下の 2通りの場合である。
[0116] これは、例えば、コンポーネント 62において、受け取ったアクションリクエストの要求 を満たす処理をしたが、それは一部分であり、残りの処理を実行するために他のコン ポーネントに処理を依頼する必要がある場合、あるいは、コンポーネント 62が受け取 つたアクションリクエストをより適切かつ具体的なアクションリクエストに修正して他のコ ンポーネントに渡す場合の 2通りが考えられる。
[0117] 次に、コンポーネント 62で変更されたアクションリクエストは、コンポーネント 63に送 られる。そして、コンポ一ネン卜 63【こお!ヽて、新たな複数のアクション 63a, 63b, 63c , 63d, 63eが生成されている。アクション 63aのアクションリクエストは、コンポーネント 64に対して出されている。アクション 63bのアクションリクエストは、コンポーネント 65 に対して出されている。アクション 63c, 63d, 63eのアクションリクエストは、コンポ一 ネント 66に対して出されている。
[0118] このように、他の複数のコンポーネント 64— 66に対してアクションの処理依頼を発 行する場合もある。また、アクション 63c, 63d, 63eのように、同一コンポーネントに対 して複数のアクションを発行する場合もある。これは、ある処理を実行してから次の処 理を実行する必要がある場合などに用いられる。コンポーネント 63は、複数のァクシ 3ン 63c, 63d, 63eを 1つのコンポ一ネン卜 66に送信する場合、ァクシ 3ン 63c, 63d , 63e間の順序関係を指定しておき、アクショングループとして複数のアクション 63c, 63d, 63eを 1つのリクエストにまとめて送信する。
[0119] コンポーネント 63で生成されたアクション 63aは、コンポーネント 64において、ァク シヨンリクエストに応じたアクションが実行される。
さらに、コンポーネント 63で生成されたアクション 63bはコンポーネント 65を経由し てコンポーネント 67にそのまま渡されている。例えば、コンポーネント 63がサイト全体 を管理するシステム RM、コンポーネント 65がサーバ群を管理するサーバ RM、そし てコンポーネント 67があるサーバ上で稼動するエージェントだとする。
[0120] この場合、システム RMは生成したアクション 63bがサーバ関連のアクションであるこ とは認識しているが実際どのサーバのものなの力 もしくはそのサーバがどこにあるか までは認識する必要はないことを意味する。すなわち、システム RMは、サーバ全体 を管理するサーノ RMにアクション 63aを投げて、サーノ RMによって実際に担当す べきエージェントにそのアクション 63aを渡してもらう。このようにして、処理の委譲を 行うことができる。
[0121] ただし、サーバ RMは渡されたアクションリクエストをそのまま下位のエージェントに 渡すわけではなぐ少なくとも送信元情報 (Sender)はサーバ RMに変更して力 送信 する。これは後述のアクション伝播の追跡可能性を確保するためである。
[0122] コンポーネント 61で生成されたアクション 6 laは様々なアクションに分かれ、最終的 にコンポーネント 64, 66, 67にまで反映される。このような構成をとることにより、各コ ンポーネントは必ずしも他のコンポーネント全ての存在を知る必要はなくなる。
[0123] 例えば図 4のような構成の場合、サイト 100内ではどのようなサーバがあるかは、サ ーバ RM121のみが知っていればよい。また、上位のシステム RM111はサイト 100 内のサーバを統一管理しているのがサーバ RM121であることを認識しさえすればよ い。ネットワークに関しても同様である。
[0124] 一方、サイト 200のシステム RM211は、サイト 100全体を管理するシステム RM11 1の存在を知ってそれとのみ通信できればよい。サイト 100のリソースに関するァクシ ヨンリクエストは全てシステム RM111に対して送信することで、後は適切なリソースマ ネージャを介して指定されたアクションが実行される。
[0125] また、ストレージ RM221からサイト 100のリソースに対してアクションリクエストを発 行する場合は、ー且上位のシステム RM211に処理を委譲して、後は上述同様に処 理を進めればよい。つまり、ストレージ RM221は、他サイトのリソースマネージャ構成 はまったく意識しなくても済む。
[0126] 図 11はアクション 61aに関係のあるアクションを網羅したアクション伝播図を示して いることになる。本実施の形態のシステムでは、各コンポーネントにアクションに関す るログを保持するデータベースを持たせることで、このようなアクション伝播関係を容 易に取得可能とする。つまり追跡可能性を確保することができる。これにより、ァクショ ンリクエスト後に任意のアクションに関係するアクション全てを取得したり、発行したリ タエストを取り消したりすることが可能となる。
[0127] 図 12は、ログ DBのデータ構造例を示す図である。ログ DB103には、動作種別と口 グ个青報との欄が設けられて ヽる。
動作種別の欄には、コンポーネントで実行された動作の種別を示している。例えば 、アクションリクエスト生成、アクションリクエスト送信、アクションリクエスト受信、ァクショ ン実行などが動作種別として登録される。
[0128] ログ情報には、動作の内容を示す情報が登録される。例えば、アクションリクエスト 生成時には、生成したアクションリクエストの内容全体が保持される。この時、当該リク ェストが、先行するアクションリクエストに応じたアクションを実行することで生成された 場合は、その先行するアクションリクエストのリクエスト IDも記録する。アクションリクェ スト送信時は、送信されたアクションリクエストのリクエスト IDと送信先が記録される。ァ クシヨンリクエスト受信時は、受信したアクションリクエスト IDと送信元が記録される。そ して、アクション実行時は、アクションリクエストのリクエスト IDと、実行されたアクション のアクション IDとが記録される。
[0129] 基本的に送受信するアクションリクエストすべての内容を保持するので、図 7のデー タモデルに示す Creator要素 42、 Sender要素 43およびログの通信相手情報を迪るこ とで図 11に示すような伝播図を求めることができる。さらに、各アクションでどのような コマンド、スクリプトを実行した力も各コンポーネントのアクションノヽンドラテーブルと照 らし合わせることで把握できる。
[0130] 次に、本実施の形態のシステムを利用したシステム管理用のアクション実施例を、 具体的に説明する。本実施の形態において、サイト 200のストレージ装置 230とサイ ト 100のサーバコンピュータ 150とを利用して、 Webサービスを提供しているものとす る。このとき、サーバコンピュータ 140は、サービスの提供を行っていないものとする。 また、ネットワーク機器 (例えば、スィッチ） 160では、当該サービス用に VLANを設 定することで、他のリソースへの影響を防いでいる。
[0131] ここで、サーバの処理性能が足らず、ストレージ性能を活力しきれていないことをシ ステム RM211が検出した場合を想定して、具体的なリソース管理例を説明する。こ の状況において、システム RM211が当該サービスに対して新たにサーバコンビユー タ 140のサーバ機能を追加指示する際の処理手順を示す。なお、サイト 100, 200に 存在するシステム RM111、 211は互 、の存在は認識するものの他サイトのほかのリ ソースマネージャに関しては認識していないものとする。また、今回は明示的にシス テム RM211から特定のサーバコンピュータ 140のサーバ機能を追加する旨の指示 を発行する場合を示すが、どのサーバを追加するかは他のリソースマネージャ (例え ば、システム RM111やサーバ RM121)に委任することもありうる。
[0132] なお、システム RM210が当該サービスに対するサーバコンピュータ 140の追加指 示をする際の処理手順では、サイト 100側の管理サーバコンピュータ 110, 120, 13 0、およびサーバコンピュータ 140に設定されたアクションハンドラテーブル 11 la, 1 21a, 131a, 141aが参照される。そこで、処理手順を説明する前に、参照されるァク シヨンハンドラテーブル 11 la, 121a, 131a, 141aの内容を、図 13—図 16を参照し て説明する。
[0133] 図 13は、統括管理を行う管理サーバコンピュータに格納されたアクションノヽンドラテ 一ブルの例を示す図である。統括管理を行う管理サーバコンピュータ 110に格納さ れたアクションノヽンドラテーブル 11 laには、サービスの構成に対する set (設定)ァク シヨンに関するアクションノヽンドラ「SVCCtl」と、サービスの構成に対する get (取得)ァク シヨンに関するアクションハンドラ「svcctl」とが設定されている。なお、この例では、実 行内容で指定されるプログラムが同じである。これは、該当するプログラムでは、ァク シヨン実行時に入力する変数に応じて、 setアクション若しくは getアクションが実行さ れることを示している。
[0134] このアクションハンドラテーブル 11 laは、システム RM111によって参照される。
図 14は、サーバを管理する管理サーバコンピュータに格納されたアクションハンド ラテーブルの例を示す図である。サーバを管理する管理サーバコンピュータ 120に 格納されたアクションハンドラテーブル 121aには、サーバの電源ステータスに対する set (設定）アクションに関するアクションハンドラ「powerctl」、サーバドメインの構成に 対する set (設定）アクションに関するアクションハンドラ「svrdomainctl.sh」、およびサー バドメインの構成に対する get (取得)アクションに関するアクションノヽンドラ「 svrdomainctl.shjが設定されて 、る。
[0135] このアクションハンドラテーブル 121aは、サーバ RM121によって参照される。
図 15は、ネットワーク機器を管理する下位の管理サーバコンピュータに格納された アクションノヽンドラテーブルの例を示す図である。ネットワーク機器を管理する管理サ 一バコンピュータ 130に格納されたアクションハンドラテーブル 131aには、ネットヮー ク機器のパラメータに対する set (設定)アクションに関するアクションノヽンドラ「nwctl」と ネットワーク機器のパラメータに対する set (取得)アクションに関するアクションノヽンド ラ「nwctl」とが設定されて 、る。
[0136] このアクションハンドラテーブル 131aは、ネットワーク RM131によって参照される。
図 16は、 Webサービスを提供可能なサーバコンピュータに格納されたアクションハ ンドラテーブルの例を示す図である。 Webサービスを提供可能なサーバコンピュータ 140に格納されたアクションハンドラテーブル 141aには、ソフトウェアの状態の set (設 定)アクションに関するアクションハンドラ「swctl」と、ソフトウェアの状態の get (取得)ァ クシヨンに関するアクションハンドラ「swctl」とが設定されて！、る。
[0137] このアクションハンドラテーブル 141aは、エージェント 141によって参照される。
以下、図 17—図 19に示すシーケンス図を参照して、サーバ追加処理手順を、シー ケンス図内に示したステップ番号に沿って説明する。
[0138] 図 17は、サーバ追加処理の手順を示す第 1のシーケンス図である。
[ステップ S41]システム RM211は、まず、どのような空きサーバがあるかの情報を 取得するためのアクションリクエストを生成し、システム RM111に対して送信する。
[0139] [ステップ S42]システム RM111は、アクションハンドラテーブル 11 laを取得し、ァ クシヨンリクエストで指定されたアクションを検索する。
[ステップ S43]この例では適当なハンドラが存在しないため、システム RM111は、 サーバ関連を受け持つサーバ RM121に対してアクションリクエストを転送する。
[0140] [ステップ S44]アクションリクエストを受け取ったサーバ RM121は、アクションハンド ラテーブル 121aを取得し、アクションリクエストで指定されたアクションを検索する。こ れにより、スクリプト名を指定したコマンド「svrdomainctl.sh」が検出される（図 14参照） [0141] [ステップ S45]サーバ RM121は、該当したコマンド「svrdomainctl.sh」を呼び出す 。サーバ RM121はコマンド「svrdomainctl.sh」を実行することにより、フリー（現在サー ビスを提供して 、な 、サーバコンピュータ）のサーノ リスト情報を取得する。
[0142] [ステップ S46]サーバ RM121は、取得したサーノ リストをシステム RM111に通知 する。
[ステップ S47]システム RM111は、サーバ RM121から受け取ったフリーのサーバ リストを、システム RM211に通知する。
[0143] [ステップ S48]システム RM211は、取得したフリーのサーノ リストで示されるサー バ情報に基づいて、サーバコンピュータ 140をサービスに追加するアクションリクエス トを生成する。そして、システム RM211は、サイト 100全体を管理するシステム RM1 11に対して、生成したアクションリクエストを送信する。
[0144] [ステップ S49]システム RM111は、アクションハンドラテーブル 11 laを取得し、ァ クシヨンリクエストで指定されたアクションを検索する。これにより、アクションハンドラ「 svcctljが検出される（図 14参照)。
[0145] [ステップ S50]システム RM111は、検索の結果得られたアクションハンドラ「svcctl 」を呼び出す。そして、システム RM111は、アクションハンドラ「svcctl」を実行する。
[0146] [ステップ S51]システム RM111は、アクションハンドラ「svcctl」で定義された処理を 実行する。すると、システム RM111は、指定されたアクションを実行するためにはま ずは VL ANの設定をして力 新規サーバ上でアプリケーションを起動する必要があ ることを認識する。そして、システム RM111は、アクションハンドラ「svcctl」内での定 義に従って、ネットワーク設定用のアクションリクエストとサーバ設定用のアクションリク エストを生成する。
[0147] [ステップ S52]システム RM111は、まずはネットワーク RM131に対して、ネットヮ ーク設定用のアクションリクエストを送信する。
図 18は、サーバ追加処理の手順を示す第 2のシーケンス図である。
[0148] [ステップ S53]ネットワーク RM131は、アクションハンドラテーブル 13 laを取得し、 アクションリクエストで指定されたアクションを検索する。これにより、アクションハンドラ 「nwctl」が検出される（図 15参照）。
[0149] [ステップ S54]ネットワーク RM131は、アクションハンドラ「nwctl」の setアクションを 実行する。
[ステップ S55]ネットワーク RM131は、ネットワーク機器 160にはエージェントが存 在しないので、アクションハンドラに従って、 SNMP等の標準もしくは独自プロトコル を用 、てネットワーク機器 160VLANに関する設定を行う。
[0150] [ステップ S56]ネットワーク機器 160は、実行結果をネットワーク RM131に返す。
[ステップ S57]ネットワーク RM131は、ネットワーク機器 160の設定結果を、システ ム RM111に返す。
[0151] 図 19は、サーバ追加処理の手順を示す第 3のシーケンス図である。
[ステップ S58]システム RM111は、ネットワーク機器の設定が完了したのを受けて
、アプリケーション起動のアクションリクエストをサーバ RM121に対して送信する。
[0152] [ステップ S59]サーバ RM121は、アクションハンドラテーブル 121aを取得し、ァク シヨンリクエストで指定されたアクションを検索する。この場合、アクションノヽンドラテー ブル 121a力らは、適当なレコードが見つからない。
[0153] [ステップ S60]サーバ RM121は、 Target要素 50 (図 7参照）に基づいて、受け取 つたアクションリクエストがサーバコンピュータ 140に対するものであることを認識する
。そこで、サーバ RM121は、サーバコンピュータ 140のエージェント 141に向けてァ クシヨンリクエストを転送する。
[0154] [ステップ S61]エージェント 141は、アクションハンドラテーブル 141aを取得し、ァ クシヨンリクエストで指定されたアクションを検索する。このとき、ソフトウェアの setァク シヨンのアクションノヽンドラ「SWClt」が検出される（図 16参照)。
[0155] [ステップ S62]エージェント 141は、アクションハンドラ「swctl」の setアクションを実 行する。
[ステップ S63]エージェント 141は、アクションハンドラに基づくアクションとして、サ 一ビスを起動する。
[0156] [ステップ S64]エージェント 141は、アプリケーションを起動したことを、サーバ RM 121に通知する。 [ステップ S65]サーバ RM121は、アプリケーションを起動したことを、システム RM 111に通知する。
[0157] [ステップ S66]システム RM111は、アプリケーションを起動したことを、システム R M211に通知する。
以上のようにして、サイト 200側のシステム RM211からの指示によって、サイト 100 で管理されているシステム内で、 Webサーバの追加が行われる。以下、アクションリク ェストの伝搬の様子およびアクションリクエストの具体例を説明する。
[0158] なお、以下の説明において、各コンポーネントの名称に図 4中の符号を付加した文 字列を、本システム内で各コンポーネントを一意に識別するための名称とする。例え ば、システム RM211 (「 211」は図 4における符号）の名称を「システム RM211」とす る。
[0159] 図 20は、サーバの構成情報を取得する際のアクションリクエストの伝搬図である。シ ステム RM211にお!/、て、どのような空きサーバがあるかの情報を取得するためのァ クシヨン 71が生成される。そして、システム RM211からシステム RM111に、そのァク シヨン 71を依頼するためのアクションリクエスト 81が渡される。
[0160] システム RM111では、指定されたアクション 71の処理内容に対応するアクションハ ンドラ（空きサーバの情報取得）を有していない。そのため、システム RM111は、ァク シヨンリクエスト 81の送信元の内容を書き換え、アクションリクエスト 82とする。そして、 システム RM111は、アクションリクエスト 82をサーバ RM121に渡す。
[0161] サーバ RM121では、アクションリクエスト 82で指定されたアクション 71に対応する 処理 (空きサーバの情報取得)を実行する。
図 21は、サーバの構成情報を取得する際に最初に出力されるアクションリクエスト の例を示す図である。このアクションリクエスト 81は、 XMLで記述されている。
[0162] <?xml version="1.0"？〉は、 XMLのバーシヨンが示されている。く ActionRequest id="aql" createDte="2004- 08- 24T12:00:00"〉は、アクションリクエストの識別情報 "aql"と、生成日時" 2004- 08- 24Τ12:00:00"とを示している。
[0163] く Creator name= "システム RM211" id="SysRM27〉は、システム RM211で生成さ れたことを示している。く Sender name= "システム RM211〃
Figure imgf000033_0001
システ ム RM211から送信されたことを示して!/、る。
[0164] く!一フリーのサーノ リスト情報を取得する一〉以下の記述でアクションが定義されて いる。
く GetAction id="action Γ sync="false"〉は、 getのアクションであり、識別情報が "action 1"であることを示している。
[0165] ^ Target site= Sitel class= ServerDomain name=〃¾erverPool id= svcpool 、 対象のサイト名、処理の対象種別等を示している。
く Structure key=〃FreeServerList7〉は、結果として取得すべきデータの名称を示し ている。
[0166] このようなアクションリクエスト 81がシステム RM211からシステム RM111に渡される
。システム RM111からサーバ RM121へは、アクションリクエスト 81に基づいて生成 されたアクションリクエスト 82が渡される。
[0167] 図 22は、システム RMで転送された後のアクションリクエストの例を示す図である。こ のアクションリクエスト 82では、アクションリクエストの識別情報力 "aq2"に変更され、送 信元の名称力 'システム RM 111"に変更されて 、る。ァクションの内容は同じである。
[0168] このようなアクションリクエスト 82がサーバ RM121に渡されることで、サーバ RM12
1においてフリーのサーノ リスト情報が生成され、アクションの生成もとであるシステム
RM211にサーノ リスト情報が送られる。
[0169] 次に、システム RM211からの指示に応じたサーバ追加処理の際のアクションリクェ ストの伝搬の様子およびアクションリクエストの具体例を説明する。
図 23は、サーバを追加する際のアクションリクエストの伝搬図である。システム RM2
11では、サーバコンピュータ 140をサービスに追加するアクション 72が生成される。 そして、システム RM211は、生成したアクション 72の処理を依頼するためのァクショ ンリクエスト 91を生成し、システム RM111に渡す。
[0170] システム RM111では、ネットワーク RM131に渡すべきアクション 73と、サーバ RM
121に渡すべきアクション 74とが生成される。そして、アクション 73の処理を依頼する アクションリクエスト 92が生成され、ネットワーク RM131に渡される。すると、ネットヮ ーク RM131において、アクション 73の処理が実行される。 [0171] その後、システム RM111において、アクション 74の処理を依頼するアクションリクェ スト 93力 S生成され、サーバ RM121に渡される。サーバ RM121では、アクション 74に 対応するアクションハンドラが登録されて 、な 、ことを確認し、アクション 74の処理を 依頼するアクションリクエスト 94をエージェント 141に渡す。すると、エージェント 141 において、アクション 74の処理が実行される。
[0172] 図 24は、サーバを追加する際に最初に出力されるアクションリクエストの例を示す 図である。このアクションリクエスト 91は、 XMLで記述されている。アクションリクエスト 91では、生成元としてシステム RM211の名称が設定され、送信元としてシステム R M211が設定されている。そして、稼働中のサービスにサーバを新たに割り当てるた めのアクションが設定されて!、る。
[0173] このようなアクションリクエスト 91がシステム RM211からシステム RM111に渡される 。システム RM111からネットワーク RM131へは、アクションリクエスト 91に基づいて 生成されたアクションリクエスト 92が渡される。
[0174] 図 25は、システム RMで転送された後のアクションリクエストの例を示す図である。こ のアクションリクエスト 92では、生成元としてシステム RM111の名称が設定され送信 元として、システム RM111の名称が設定されている。また、アクションの内容が、ネッ トワーク機器 160の VLAN設定を変更するためのアクションに変更されている。
[0175] このようなアクションリクエスト 92がネットワーク RM131に渡されることで、ネットヮー ク RM131において、ネットワーク機器 160の VLAN設定が行われる。
その後、システム RM111からネットワーク RM131へ、アクションリクエスト 91に基づ V、て生成されたアクションリクエスト 93が渡される。
[0176] 図 26は、システム RMで転送された後のアクションリクエストの例を示す図である。こ のアクションリクエスト 93では、生成元としてシステム RM111の名称が設定され送信 元として、システム RM111の名称が設定されている。また、アクションの内容が、サ 一バコンピュータ 140によるアプリケーションの起動処理に変更されている。
[0177] このようなアクションリクエスト 93がシステム RM111からサーバ RM121に渡される 。サーバ RM121からエージェント 141へは、アクションリクエスト 93に基づいて生成 されたアクションリクエスト 94が渡される。 [0178] 図 27は、システム RMで転送された後のアクションリクエストの例を示す図である。こ のアクションリクエスト 94では、アクションリクエストの識別情報が" aq5"に変更され、送 信元の名称力 サーバ RM121 "に変更されている。アクションの内容は同じである。
[0179] このようなアクションリクエスト 94がエージェント 141に渡されることで、エージェント 1 41において、サーバコンピュータ 140内でのサーバアプリケーションの起動処理が 行われる。
[0180] 以上のようにして、リソースマネージャ間の相互接続性を向上させ、さらに高度な管 理機能を提供することが可能となる。これは、高機能、高信頼、高可用なリソース管理 システムの構築に対して有用である。
[0181] すなわち、本実施形態のリソース管理方法によれば、リソースマネージャおよびリソ ース上で稼動するエージェント間を共通インタフェースを用いてやりとりする。そして、 コンポーネントごとに用意するアクションノヽンドラによって、指定されたアクションが当 該コンポーネント独自のコマンド、スクリプトに割り付けられる。これによつて、従来より も相互接続性が格段に向上する。その結果、これまで人手で各リソースマネージャ、 リソースの設定を行っていた処理を自動化することが可能となり、リソース管理の容易 ィ匕、コスト削減へと結びつく。
[0182] また、各コンポーネントではアクション関係の処理実行履歴はすべてログに記録さ れる。例えば、各アクションリクエストはそのリクエストを生成したコンポーネント上の口 グ DBに保持される。なお、ログとしては、図 12に示す情報以外にも様々な情報を記 録することもできる。これにより、アクションの追跡可能性を確保することができ、管理 機能の向上につながる。
[0183] なお、図 2に示した例では、各コンポーネントが個別のサーバコンピュータに実装さ れているが、 1つのサーバコンピュータ内に複数のコンポーネントを実装することもで きる。
[0184] なお、上記の処理機能は、コンピュータによって実現することができる。その場合、 管理サーバコンピュータやサーバコンピュータが有すべき機能の処理内容を記述し たプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記 処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンビュ ータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り 可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモ リなどがある。磁気記録装置には、ハードディスク装置 (HDD)、フレキシブルディスク (FD)、磁気テープなどがある。光ディスクには、 DVD (Digital Versatile Disc)、 DV D— RAM (Random Access Memory)、 CD-ROM (Compact Disc Read Only Memory)、 CD— R (Recordable) ZRW (Rewritable)などがある。光磁気記録媒体に は、 MO (Magneto-Optical disk)などがある。
[0185] プログラムを流通させる場合には、例えば、そのプログラムが記録された DVD、 CD
ROMなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータ の記憶装置に格納しておき、ネットワークを介して、サーバコンピュータ力 他のコン ピュータにそのプログラムを転送することもできる。
[0186] プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプロ グラムもしくはサーバコンピュータ力 転送されたプログラムを、 自己の記憶装置に格 納する。そして、コンピュータは、自己の記憶装置力 プログラムを読み取り、プロダラ ムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログ ラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンビュ ータは、サーバコンピュータ力もプログラムが転送される毎に、逐次、受け取ったプロ グラムに従った処理を実行することもできる。
[0187] 上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が 当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用 例に限定されるものではなぐ対応するすべての変形例および均等物は、添付の請 求項およびその均等物による本発明の範囲とみなされる。
符号の説明
[0188] 1, 2, 3, 4 管理サーバコンピュータ
la 記憶手段
laa アクションハンドラテーブル
lb アクションハンドラ検索手段
lc アクションリクエスト転送手段 Id アクション実行手段 7a 第 1のアクションリクエスト 7b 第 2のアクションリクエスト 7c 第 3のアクションリクエスト

Claims

請求の範囲
[1] 他のリソース管理機能との間で処理を分担してリソースを管理するリソース管理プロ グラムにおいて、
コンピュータを、
依頼内容に応じた処理の少なくとも一部の実行内容が定義されたアクションノヽンド ラが処理の依頼内容毎に登録されたアクションノ、ンドラテーブルを記憶する記憶手 段、
前記他のリソース管理機能との間で共通化された共通データ構造で処理の依頼内 容が示された第 1のアクションリクエストを受け取ると、前記第 1のアクションリクエスト による依頼内容を解析し、前記第 1のアクションリクエストに示される依頼内容に対応 するアクションハンドラを前記アクションハンドラテーブル力 検索するアクションハン ドラ検索手段、
前記アクションハンドラ検索手段で検出されたアクションハンドラを起動して、ァクシ ヨンノヽンドラに定義された処理を実行し、前記第 1のアクションリクエストに示される依 頼内容が未完了の場合、前記共通データ構造で未完了分の処理の依頼内容を示 す第 2のアクションリクエストを生成し、未完了分の処理の対象となる管理対象機器を 管理する他のリソース管理機能に対して前記第 2のアクションリクエストを送信するァ クシヨン実行手段、
として機能させることを特徴とするリソース管理プログラム。
[2] 前記コンピュータを、さらに、
前記アクションハンドラ検索手段が受け取った前記第 1のアクションリクエストの内容 、前記アクション実行手段における処理の実行内容、および前記アクション実行手段 が送信した前記第 2のアクションリクエストの内容を取得し、ログデータベースに格納 するログ採取手段、
として機能させることを特徴とする請求の範囲第 1項記載のリソース管理プログラム
[3] 前記コンピュータを、さらに、
前記アクションハンドラ検索手段でアクションノヽンドラが検出されな力つた場合、前 記第 1のアクションリクエストに含まれる処理の対象となる管理対象機器を管理する他 のリソース管理機能に対して、前記第 1のアクションリクエストと同じ依頼内容を有する 第 3のアクションリクエストを送信するアクションリクエスト転送手段、
として機能させることを特徴とする請求の範囲第 1項記載のリソース管理プログラム
[4] 前記コンピュータを、さらに、
前記アクションハンドラ検索手段が受け取った前記第 1のアクションリクエストの内容 、前記アクション実行手段における処理の実行内容、前記アクション実行手段が送信 した前記第 2のアクションリクエストの内容、および前記アクションリクエスト転送手段 が送信した前記第 3のアクションリクエストの内容を取得し、ログデータベースに格納 するログ採取手段、
として機能させることを特徴とする請求の範囲第 3項記載のリソース管理プログラム
[5] 前記共通化データ構造では、複数の処理を依頼することができると共に、各処理の 実行順を指定可能であり、前記アクション実行手段は、前記第 1のアクションリクエスト において複数処理の実行順が指定されていた場合、指定された順に、各処理に対 応するアクションノヽンドラを起動することを特徴とする請求の範囲第 1項記載のリソー ス管理プログラム。
[6] 処理の依頼内容の共通化が図られた前記リソース管理機能には、リソースを有する 管理対象機器に対して処理を依頼するリソースマネージャと、前記管理対象機器内 に設けられ、前記リソースマネージャ力 の依頼に応じてリソースの環境設定を行うェ ージェントとが含まれることを特徴とする請求の範囲第 1項記載のリソース管理プログ ラム。
[7] コンピュータにより、他のリソース管理機能との間で処理を分担してリソースを管理 するためのリソース管理方法において、
記憶手段が、依頼内容に応じた処理の少なくとも一部の実行内容が定義されたァ クシヨンノヽンドラが処理の依頼内容毎に登録されたアクションノヽンドラテーブルを予め 記憶しており、 アクションハンドラ検索手段が、前記他のリソース管理機能との間で共通化された共 通データ構造で処理の依頼内容が示された第 1のアクションリクエストを受け取ると、 前記第 1のアクションリクエストによる依頼内容を解析し、前記第 1のアクションリクエス トに示される依頼内容に対応するアクションノヽンドラを、前記アクションノヽンドラテープ ルカ 検索し、
アクション実行手段が、前記アクションノヽンドラ検索手段で検出されたアクションノヽ ンドラを起動して、アクションノヽンドラに定義された処理を実行し、前記第 1のァクショ ンリクエストに示される依頼内容が未完了の場合、前記共通データ構造で未完了分 の処理の依頼内容を示す第 2のアクションリクエストを生成し、未完了分の処理の対 象となる管理対象機器を管理する他のリソース管理機能に対して前記第 2のァクショ ンリクエストを送信する、
ことを特徴とするリソース管理方法。
他のリソース管理機能との間で処理を分担してリソースを管理するリソース管理装置 において、
依頼内容に応じた処理の少なくとも一部の実行内容が定義されたアクションノヽンド ラが処理の依頼内容毎に登録されたアクションノ、ンドラテーブルを記憶する記憶手 段と、
前記他のリソース管理機能との間で共通化された共通データ構造で処理の依頼内 容が示された第 1のアクションリクエストを受け取ると、前記第 1のアクションリクエスト による依頼内容を解析し、前記第 1のアクションリクエストに示される依頼内容に対応 するアクションハンドラを前記アクションハンドラテーブル力 検索するアクションハン ドラ検索手段と、
前記アクションハンドラ検索手段で検出されたアクションハンドラを起動して、ァクシ ヨンノヽンドラに定義された処理を実行し、前記第 1のアクションリクエストに示される依 頼内容が未完了の場合、前記共通データ構造で未完了分の処理の依頼内容を示 す第 2のアクションリクエストを生成し、未完了分の処理の対象となる管理対象機器を 管理する他のリソース管理機能に対して前記第 2のアクションリクエストを送信するァ クシヨン実行手段と、 を有することを特徴とするリソース管理装置。
[9] 前記アクションハンドラ検索手段が受け取った前記第 1のアクションリクエストの内容 、前記アクション実行手段における処理の実行内容、および前記アクション実行手段 が送信した前記第 2のアクションリクエストの内容を取得し、ログデータベースに格納 するログ採取手段、
を有することを特徴とする請求の範囲第 8項記載のリソース管理装置。
[10] 他のリソース管理機能との間で処理を分担してリソースを管理するリソース管理プロ グラムを記録したコンピュータ読み取り可能な記録媒体において、
コンピュータを、
依頼内容に応じた処理の少なくとも一部の実行内容が定義されたアクションノヽンド ラが処理の依頼内容毎に登録されたアクションノ、ンドラテーブルを記憶する記憶手 段、
前記他のリソース管理機能との間で共通化された共通データ構造で処理の依頼内 容が示された第 1のアクションリクエストを受け取ると、前記第 1のアクションリクエスト による依頼内容を解析し、前記第 1のアクションリクエストに示される依頼内容に対応 するアクションハンドラを前記アクションハンドラテーブル力 検索するアクションハン ドラ検索手段、
前記アクションハンドラ検索手段で検出されたアクションハンドラを起動して、ァクシ ヨンノヽンドラに定義された処理を実行し、前記第 1のアクションリクエストに示される依 頼内容が未完了の場合、前記共通データ構造で未完了分の処理の依頼内容を示 す第 2のアクションリクエストを生成し、未完了分の処理の対象となる管理対象機器を 管理する他のリソース管理機能に対して前記第 2のアクションリクエストを送信するァ クシヨン実行手段、
として機能させることを特徴とするリソース管理プログラムを記録したコンピュータ読 み取り可能な記録媒体。
PCT/JP2004/016843 2004-11-12 2004-11-12 リソース管理プログラム、リソース管理方法、およびリソース管理装置 WO2006051599A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2006544704A JP4522413B2 (ja) 2004-11-12 2004-11-12 リソース管理プログラム、リソース管理方法、およびリソース管理装置
PCT/JP2004/016843 WO2006051599A1 (ja) 2004-11-12 2004-11-12 リソース管理プログラム、リソース管理方法、およびリソース管理装置
US11/798,339 US8589381B2 (en) 2004-11-12 2007-05-11 Resource management program, resource management process, and resource management apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2004/016843 WO2006051599A1 (ja) 2004-11-12 2004-11-12 リソース管理プログラム、リソース管理方法、およびリソース管理装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/798,339 Continuation US8589381B2 (en) 2004-11-12 2007-05-11 Resource management program, resource management process, and resource management apparatus

Publications (1)

Publication Number Publication Date
WO2006051599A1 true WO2006051599A1 (ja) 2006-05-18

Family

ID=36336285

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/016843 WO2006051599A1 (ja) 2004-11-12 2004-11-12 リソース管理プログラム、リソース管理方法、およびリソース管理装置

Country Status (3)

Country Link
US (1) US8589381B2 (ja)
JP (1) JP4522413B2 (ja)
WO (1) WO2006051599A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009245409A (ja) * 2008-04-01 2009-10-22 Nec Corp リソース自動構築システム及び自動構築方法並びにそのための管理用端末

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7987225B2 (en) * 2004-12-22 2011-07-26 International Business Machines Corporation Method for remembering resource allocation in grids
US7756888B2 (en) * 2007-07-03 2010-07-13 Oracle America, Inc. Method and apparatus for providing heterogeneous resources for client systems
US9253016B2 (en) 2010-11-02 2016-02-02 International Business Machines Corporation Management of a data network of a computing environment
US8984109B2 (en) 2010-11-02 2015-03-17 International Business Machines Corporation Ensemble having one or more computing systems and a controller thereof
US9081613B2 (en) 2010-11-02 2015-07-14 International Business Machines Corporation Unified resource manager providing a single point of control
US8966020B2 (en) 2010-11-02 2015-02-24 International Business Machines Corporation Integration of heterogeneous computing systems into a hybrid computing system
US8959220B2 (en) 2010-11-02 2015-02-17 International Business Machines Corporation Managing a workload of a plurality of virtual servers of a computing environment
CN109560958B (zh) * 2017-09-27 2022-02-18 精工爱普生株式会社 设备管理系统、装置和方法、中继管理装置以及记录介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002512400A (ja) * 1998-04-22 2002-04-23 ユニシス コーポレイシヨン 第１のトランザクション処理環境におけるコンポーネントを能動化して別の環境におけるリソースにアクセスするための方法および装置
JP2003157178A (ja) * 2001-11-21 2003-05-30 Hitachi Ltd Ｘｍｌデータによる遠隔オブジェクト呼出し方法
JP2003248636A (ja) * 2002-02-11 2003-09-05 Ricoh Co Ltd インタフェースデバイスの通信手段確立方法及び制御デバイス

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5355484A (en) * 1991-08-12 1994-10-11 International Business Machines Corporation Dynamically established event monitors in event management services of a computer system
US6529932B1 (en) * 1998-04-01 2003-03-04 Microsoft Corporation Method and system for distributed transaction processing with asynchronous message delivery
US6738971B2 (en) * 1999-03-10 2004-05-18 Oracle International Corporation Using a resource manager to coordinate the comitting of a distributed transaction
US20020032783A1 (en) * 1999-12-30 2002-03-14 Tuatini Jeffrey T. Shared service funtionality invocation
JP2003050964A (ja) * 2000-11-30 2003-02-21 Kokusai Zunou Sangyo Kk 表計算ウェブサーバシステムおよび表計算ウェブシステム
US7058968B2 (en) * 2001-01-10 2006-06-06 Cisco Technology, Inc. Computer security and management system
US7581230B2 (en) * 2001-02-06 2009-08-25 Siebel Systems, Inc. Adaptive communication application programming interface
ES2262792T3 (es) * 2002-03-28 2006-12-01 Telefonaktiebolaget Lm Ericsson (Publ) Una disposicion y un metodo para soportar el control de procesos/aplicaciones.
US7707141B1 (en) * 2002-11-27 2010-04-27 Microsoft Corporation Use of a set based approach to constructing complex queries for managing resources built from a set of simple underlying operations
US7543297B2 (en) * 2003-11-24 2009-06-02 International Business Machines Corporation Collaborative planning actions and recipes

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002512400A (ja) * 1998-04-22 2002-04-23 ユニシス コーポレイシヨン 第１のトランザクション処理環境におけるコンポーネントを能動化して別の環境におけるリソースにアクセスするための方法および装置
JP2003157178A (ja) * 2001-11-21 2003-05-30 Hitachi Ltd Ｘｍｌデータによる遠隔オブジェクト呼出し方法
JP2003248636A (ja) * 2002-02-11 2003-09-05 Ricoh Co Ltd インタフェースデバイスの通信手段確立方法及び制御デバイス

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009245409A (ja) * 2008-04-01 2009-10-22 Nec Corp リソース自動構築システム及び自動構築方法並びにそのための管理用端末

Also Published As

Publication number Publication date
JPWO2006051599A1 (ja) 2008-05-29
JP4522413B2 (ja) 2010-08-11
US20070288512A1 (en) 2007-12-13
US8589381B2 (en) 2013-11-19

Similar Documents

Publication Publication Date Title
Li et al. Design patterns and extensibility of REST API for networking applications
Zhou et al. REST API design patterns for SDN northbound API
US6976262B1 (en) Web-based enterprise management with multiple repository capability
JP4504762B2 (ja) ストレージネットワークの移行方法、管理装置、管理プログラムおよびストレージネットワークシステム
RU2357289C2 (ru) Администрирование удаленной системы с использованием среды командной строки
US6959329B2 (en) System and method for transforming configuration commands
TWI317503B (en) System and method for remote installation of application programs in mobile derices
US8589381B2 (en) Resource management program, resource management process, and resource management apparatus
US20090182880A1 (en) System and Method to Synthesize Custom Metric Attributes from Available MBean Attributes on an Application Server
JP2001216226A (ja) アプリケーション間データ送受信方式及びアプリケーション間データ送受信方法及びアプリケーション間データ送受信方法をコンピュータに動作させるプログラムを記録したコンピュータで読取可能な記録媒体
JP2006146927A (ja) Ｓｎｍｐ基盤のネットワーク管理装置および方法
US20030055862A1 (en) Methods, systems, and articles of manufacture for managing systems using operation objects
US20050188067A1 (en) Network management system, display method, and program
Mogul et al. Experiences with modeling network topologies at multiple levels of abstraction
US20030220963A1 (en) System and method for converting data structures
CN113381870B (zh) 报文处理方法和设备
US8650568B2 (en) Method and system for transforming orders for executing them in standard workflow engines
CN102684894B (zh) 一种实现北向接口的方法及装置
JP2005202851A (ja) 仮想私設組織に対するポリシの実施システム及びその方法
EP1061445A2 (en) Web-based enterprise management with transport neutral client interface
US20050216477A1 (en) Computer network management apparatus and method
Pell et al. Managing in a distributed world
US20050076343A1 (en) Persistent storage of network management data using object references
JP3845070B2 (ja) エレメント管理システム、エレメント管理方法及びエレメント管理プログラム
van Gurp et al. Service grid variability realization

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006544704

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 11798339

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 04822396

Country of ref document: EP

Kind code of ref document: A1

WWP Wipo information: published in national office

Ref document number: 11798339

Country of ref document: US