JP2017045079A - Cloud management method and cloud management system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technique capable of informing an occurrence of an incident in a business system including a point in a cloud system at which the incident has occurred to a management person of cloud systems based on the importance of the incident changing over time.SOLUTION: A cloud management system 10 operates a plurality of cloud systems to manage incidents on business servers of a plurality of tenants 13. An information integration server 11 includes: an incident reception section that receives and merges incident information from the business servers; a priority determination section that calculates the priority of the incidents in the plurality of cloud systems based on the type and time of occurrence of the merged incident information; and an output section that outputs a piece of incident information according to the calculated priority.SELECTED DRAWING: Figure 1

Description

The present invention relates to a cloud management system.

  In the following Patent Document 1, an incident including a failure of a target system is managed as incident information in a first database, and the configuration of the target system is managed as a configuration information in a second database. It is disclosed that it cooperates with a service portal system that provides an information screen to a terminal and cooperates with a failure monitoring system that monitors incidents including failures of the target system.

  The cloud management system uses the configuration information and the incident information to create a screen for visualizing the incident status including the configuration of the target system, the failure influence range, and the failure influence destination service, and provides the screen to the person in charge. And a second function for setting, in the configuration information, a configuration including a configuration part designed in consideration of fault tolerance in the target system as a configuration management model.

  In the configuration management model, each component part including a component part designed in consideration of fault tolerance is set as the first configuration item, and the fault tolerance for the first configuration item is set to the second configuration item. It is set as an item, and the dependency between configuration items including the first and second configuration items is set as a link. On the screen by the first function, it is disclosed that an incident occurrence status including a configuration management model, a failure influence range, and a failure influence destination service of a target system is displayed in a structure in which configuration items are connected by links.

JP2012-38028

Patent Document 1 discloses a technology that visualizes the situation such as the failure impact range in a target system configured with consideration of the cloud environment and fault tolerance, but works in a hybrid cloud environment composed of multiple cloud systems. It is not considered to inform the system administrator of which cloud system the incident occurred when the system was configured.
Also, there is no consideration given to the incident that the administrator must deal with preferentially based on the importance of incidents that change over time, and the business server that runs on the virtual machines that make up the business system When an incident moves to another cloud system, the administrator uses the incident reporting mechanism provided by the moved cloud system to determine which cloud system the incident report has and how much impact it has. It is not considered to report to

  The above problem is a cloud management system that manages incidents of business servers of multiple tenants running on virtual machines running on multiple cloud systems, and has been merged with an incident receiver that receives and merges incident information from business servers Solved by a system including a priority determination unit that determines the priority of an incident in the plurality of cloud systems based on the type and occurrence time of incident information, and an output unit that outputs incident information according to the determined priority .

  Individual problems that cannot be solved by the above system will be solved by adding the components described in the embodiments.

  ADVANTAGE OF THE INVENTION According to this invention, the burden of the administrator who copes with the incident of the business system implement | achieved using cloud can be reduced.

It is an example of the block diagram which shows the structure of the cloud system in a present Example. It is an example of the block diagram of the information aggregation server of the cloud management system in a present Example. It is an example of the block diagram of the navigation server of the cloud management system in a present Example. It is an example of the block diagram of a tenant in a present Example. It is an example of the block diagram of the data center in a present Example. It is an example of the block diagram of the monitoring server which operate | moves with the physical computer in a present Example. It is an example of the incident information table in a present Example. It is an example of the operation data information table in a present Example. It is an example of the system information table in a present Example. It is an example of the incident response table in a present Example. It is an example of the table of incident information with priority in a present Example. It is an example of the operation data information table in a present Example. It is an example of the important operation data table in a present Example. It is an example of the incident information display table in a present Example. It is an example of the system infrastructure information table in a present Example. It is an example of the incident response history table in a present Example. It is an example of the table of the escalation information in a present Example. It is an example of the incident list screen in a present Example. It is an example of the incident detail display screen in a present Example. It is an example of the operation data monitoring flowchart of the monitoring server in a present Example. It is an example of the business log monitoring flowchart of the monitoring server in a present Example. It is an example of the priority definition flowchart 1 of the information aggregation server in a present Example. It is an example of the priority definition flowchart 2 of the information aggregation server in a present Example. It is an example of the incident acquisition and registration flowchart of the navigation server in a present Example. It is an example of the incident list display flowchart of the navigation server in a present Example. It is an example of the flowchart at the time of the business server transfer to the other cloud system in a present Example.

  FIG. 1 is an overall configuration diagram of a cloud management system 10 according to the present embodiment and a tenant system to be managed. In this embodiment, the cloud management system 10 is connected from the data center 1 to the data center N via the Internet via a network device. The business system that is the customer tenant 13 may be realized by using a plurality of data centers, and each data center may be a data center provided by a different operator.

  FIG. 2 is a block diagram of the information aggregation server 11. The information aggregation server 11 includes a receiving unit 101 and a network interface unit 102, and the receiving unit 101 receives incidents and operation data transmitted from a tenant business server via the network interface unit 102. The priority determination unit 111 stored in the main storage area 18 and executed by the CPU 15 prioritizes the received incident based on the information in the system information table 121, the incident response table 122, the operation data information table 123, and the important operation data table 124. Determining the degree and adding the determined priority information to the incident. The incident registration unit 112 registers the incident with the added priority in the incident information table with priority 125.

FIG. 3 is a block diagram of the navigation server 12. The navigation server 12 includes a display unit 201 and a network interface unit 202. In this example, the display unit 201 is included in the navigation server 12, but it may be displayed via a browser connected to the Internet. The navigation server has an incident acquisition unit 211 for acquiring information of the priority-added incident information table 125 held by the information aggregation server 11 via the network interface unit 202. The priority-added incident registration unit 212 extracts system infrastructure information related to the acquired incident from the system infrastructure information table 221, adds the system infrastructure information and the incident ID to the incident, and registers them in the incident information display table 222. . The incident response history registration unit 213 registers the response information input to the incident response history table 223 when a new incident occurs and is registered in the incident information display table 222 or when the operator inputs incident response information. To do. The incident list display unit 214 reads the incident information from the incident information display table 222, extracts correspondence information related to the incident from the incident response history table 223, and adds information to the incident. The incident list display unit 214 displays incident information on the screen via the display unit 201 in order of priority. When the business server moves to another cloud system, the system infrastructure information registration unit 215 receives the destination system infrastructure information sent from the business server and rewrites the information of the corresponding record in the system infrastructure information table 221. . The mail transmission unit 216 reads a notification destination from the escalation information table 224 when an incident occurs or when the business server moves to another cloud system, and transmits a mail via the network interface unit 202. Each processing unit such as the incident acquisition unit 211, the incident registration unit 212 with priority, the incident response history registration unit 213, and the like is stored in the main storage area 19 and executed by the CPU 16.
FIG. 4 is a block diagram of the tenant 13. The tenant 13 has a plurality of data centers 21, and a plurality of business systems 22 exist in the data center. The data center 21 has a line connected to the Internet network, and the business system 22 connects to the Internet via the line.

  FIG. 5 is a block diagram of the data center 21. Virtualization software 33 is installed on the physical computer 32 of the business system 22, and a plurality of VMs (Virtual Machines) 31 operate on the virtualization software 33. Some non-virtualized physical computers 32 run an OS 34.

  FIG. 6 is a block diagram of the monitoring server 350 operating on the physical computer. The monitoring server 350 may be executed by the same VM as the VM that executes the business server, or may be executed by a VM independent of the VM that executes the business server. A monitoring server 350 is installed in the VM 31, and includes a log monitoring unit 301 that monitors the OS event log 321 and the business log 322, and an operation data monitoring unit that monitors the operation data 323 of the business server.

The monitoring server 350 may be installed in units of physical computers, or may be installed in units of business systems or tenants. Efficient monitoring is possible by installing based on the amount of incidents and the size of the business system.
The log monitoring unit 301 reads the log information to be monitored from the log monitoring table 311 and, when a specific character string is output to the log, calls the incident generation unit 313 to generate an incident. The generated incident is transmitted to the information aggregation server 11 by the transmission unit 303. The operating data monitoring unit 302 reads the monitoring target operating data information from the operating data monitoring table 312 and acquires the monitoring target operating data information. The acquired operation data information is transmitted to the information aggregation server 11 by the transmission unit 303. If the operation data exceeds the threshold value at the time of acquisition, the incident generation unit 313 is called to generate an incident, and the transmission unit 303 transmits the incident to the information aggregation server 11. A monitoring server 350 including processing units such as a log monitoring unit 301, an operation data monitoring unit 302, and a transmission unit 303 is stored in the main storage area 360 and executed by the CPU 17.

  FIG. 7 shows a table of incident information 400 and a table of operation data information 410 that the business server 31 transmits to the information aggregation server 11. In the drawing, the upper and lower parts are separately described due to space problems, but in the present embodiment, an example realized as one table will be described. The same notation applies to the drawings of the following tables. Incident information 400 includes tenant ID 401, incident group name 402, instance ID 403, severity 404, incident occurrence date / time 405, incident type 406, and message 407. The tenant ID 401 is an ID of a tenant to which the business server in which the incident has occurred and identifies each tenant. The incident group name 402 is the name of the business system 22 to which the business server where the incident occurred belongs, and identifies the business system 22 in the same tenant. The instance ID 403 is the name of the business server in which the incident has occurred, and identifies the business server in the same business system 22. The severity 404 indicates the severity of the incident that has occurred, and one of two types of “Error” and “Warning” is input. Incident type 406 indicates the type of incident and can be freely defined by the operator. A message 407 indicates the contents of the incident. The operation data information 410 includes a tenant ID 411, an incident group name 412, an instance ID 413, an acquisition date 414, and operation data 415. The acquisition date and time is the date and time when the operation data 415 is acquired, and the operation data 415 is added only for the operation data to be acquired designated by the system operator.

  FIG. 8 shows the data structure of the system information table 121 and the incident response table 122 that the information aggregation server 11 has. The system information table 121 and the incident response table 122 are tables that are read in order for the priority determination unit 111 to define the priority of incidents. The system information table 121 includes a tenant ID 501, an incident group name 502, a business function 503, a service operation rate 504, and a service core time 505. The business function 503 is the name of a business function that operates in the business system 22, and the service operation rate 504 indicates the service operation rate of the business function 503. The service core time 505 indicates a period during which the degree of influence on the business function is large when an incident such as a time zone in which the business function 503 is most used occurs. The incident correspondence table 122 includes a tenant ID 511, an incident group name 512, an instance ID 513, a message 514, a recovery limit time 515, a recovery work time 516, and a business function 517. The recovery limit time 515 indicates the limit time that the corresponding incident must be recovered, and the recovery work time 516 indicates the time required for the recovery work for the incident. When an incident occurs, the priority determination unit 111 compares the incident information 400 with the tenant ID 401, incident group name 402, instance ID 403, and message 407 of the incident information 400, and the incident is registered in the incident response table 122. Check if it is.

  FIG. 9 shows the data structure of the priority-added incident information table 125 that the information aggregation server 11 has. The incident information table with priority 125 includes tenant ID 521, incident group name 522, business function 523, priority 524, instance ID 525, severity 526, incident occurrence date / time 527, incident type 528, message 529, recovery limit time 530, recovery It consists of a work time 516. When an incident occurs, the priority determination unit 111 defines the priority, and the incident registration unit 112 registers the incident information in the incident information table 125 with priority. In addition, information is periodically acquired from the navigation server 12. The acquired record is deleted.

  FIG. 10 shows the data structure of the operation data information table 123 and the important operation data table 124 that the information aggregation server 11 has. The operation data information table 123 includes a tenant ID 541, an incident group name 542, an instance ID 543, an acquisition date and time 544, and operation data 545. The information aggregation server 11 registers the operating data information 410 received from the business server 31 in the operating data information table 123 as it is. The important operation data table 124 includes a tenant ID 551, an incident group name 552, an instance ID 553, and important operation data 554. The important operation data 554 can register the most important operation data among a plurality of operation data 323 acquired on the business server 31 by the operator up to a maximum of four. The two tables are tables that are read when the priority determination unit 111 defines priorities when an incident occurs.

  FIG. 11 shows a data configuration example of the incident information display table 222 included in the navigation server 12. Incident information display table 222 includes tenant ID 601, incident group name 602, business function 603, priority 604, instance ID 605, incident ID 606, severity 607, incident occurrence date and time 608, incident type 609, message 610, recovery limit time 611, It consists of a recovery work time 612, infrastructure information 613, and center information 614. The incident information display table 222 is a table read from the incident display unit 214 when an incident list display request is received from a user. The incident ID 606 is an ID for identifying an incident that is generated when the incident registration unit with priority 212 registers an incident in the incident information display table 222. The base information 613 indicates the name of the cloud system on which the business server 31 is operating and the on-pre environment, and the center information 614 indicates the location of the center where the business server 31 is operating.

FIG. 12 shows a data configuration example of the system infrastructure information table 221 and the incident response history table 223 that the navigation server 12 has. The system infrastructure information table 221 includes a tenant ID 621, an incident group name 622, an instance ID 623, infrastructure information 624, and center information 625, and information is registered in advance by a person in charge of operations. Further, the system infrastructure information table 221 is called when the incident registration section 212 with priority registers an incident in the incident information display table 222, and the information of the corresponding infrastructure information 624 and center information 625 is added to the incident. The incident response history table 223 includes a tenant ID 631, an incident group name 632, an instance ID 633, an incident ID 634, a user name 635, a status 636, a registration date and time 637, and a response history 638. In the incident handling history table 223, a new record is created when an incident occurs, the status 636 is registered as “open”, the user name 635, and the handling history 638 are registered without inputting any information. When the user updates the information, the user name 635 contains the name of the user who entered the information, and the status 636 is input with either “going” or “close” according to the content of the correspondence. The incident response content is entered.
FIG. 13 shows the data structure of the escalation information table 224 that the navigation server 12 has. The escalation information table 224 includes a tenant ID 641, an incident group name 642, an instance ID 643, infrastructure information 644, center information 645, and a contact address 646. A plurality of contact addresses 646 can be designated and can be freely registered by the operator. Information is read from the escalation information table 224 as a notification destination corresponding to an incident when the incident occurs. Further, when the business server 31 is transferred to another cloud system, the base information 644, the center information 645, and the contact information 646 are updated to the information of the destination cloud system.

  FIG. 14 shows a screen of the incident list 700 displayed by the navigation server 12. The screen configuration is a screen configuration in which the “important incident 711” list for displaying high priority incidents is arranged at the top and the “incident 712” list for displaying low priority incidents is arranged at the bottom, and the list display is distinguished by priority. It is. In each list, information on the “remaining time” calculated based on the recovery limit time 611 and the recovery work time 612 read from the incident information display table 222 and the current time is displayed, and the “remaining time” is small. Incidents are displayed in order. For incidents for which the recovery limit time 611 is not registered, “-” is displayed in “Remaining time”. In addition, the incident displayed in the “incident 712” list has a “remaining time” that decreases with the passage of time. When the time is less than 3 hours, the priority is changed to “high”, and the “important incident 711” list. Displayed on the side. It also has a search function that can extract only a specific incident by inputting an arbitrary character string.

  FIG. 15 shows a screen of the incident details display 720 displayed by the navigation server 12. The incident detail display 720 is a transition destination screen when one incident displayed in the incident list 700 is selected and the button of the incident detail display 701 is clicked in the selected state. The screen is configured to read information from the incident information display table 222 such as “basic information”, “center information”, and “business function” affected by the incident that are not displayed in the incident list 700.

  FIG. 16 is a flowchart showing the operation of the monitoring server.

  Step 801: The operation data monitoring unit 302 reads the operation data and threshold information to be monitored from the operation data monitoring table 312 and acquires the numerical value of the corresponding operation data 323.

  Step 802: The operating data monitoring unit 302 compares the acquired numerical value with a threshold value, and moves to step 805 if the threshold value is exceeded.

  Step 803: The operation data monitoring unit 302 calls the transmission unit 303, generates operation data information 410 from the acquired operation data 323, and transmits it to the information aggregation server 11.

  Step 804: The operating data monitoring unit 302 waits for the defined monitoring interval and returns to step 801.

  Step 805: The operation data monitoring unit 302 calls the incident generation unit 313 to generate the incident information 400. Step 806: The operation data monitoring unit 302 calls the transmission unit 303, transmits the generated incident information 400 to the information aggregation server 11, and proceeds to step 803.

  FIG. 17 is a flowchart showing the log monitoring operation of the monitoring server 350.

  Step 811: The log monitoring unit 301 reads information on a monitoring target log and a monitoring character string from the log monitoring table 313, and acquires information on the corresponding OS event log 321 and business log 322.

  Step 812: The log monitoring unit 301 confirms whether or not the acquired log information has been updated. If it has not been updated, the log monitoring unit 301 proceeds to step 816.

  Step 813: The log monitoring unit 301 compares the acquired log information with the monitoring character string to determine whether they match, and if not, moves to step 816.

Step 814: The log monitoring unit 301 calls the incident generation unit 313 to generate incident information 400.
Step 815: The log monitoring unit 301 calls the transmission unit 303 and transmits the generated incident information 400 to the information aggregation server 11.

  Step 816: The log monitoring unit 301 waits for the defined monitoring interval, and returns to Step 811.

  Next, processing of the information aggregation server 11 will be described. The information aggregation server 11 receives the operation data and incident information transmitted from the monitoring server 350 via the receiving unit 101, and the operation data registration unit 113 registers them in the operation data information table 123. Information from all the monitoring servers 350 handled by the information aggregation server 11 is received, and the received operation data and incident information are merged and stored.

  FIG. 18 is a flowchart illustrating an operation in which the information aggregation server 11 defines priority for an incident.

  Step 821: The information aggregation server 11 receives the incident information 400 transmitted from the monitoring server 350 from the receiving unit 101.

  Step 822: The priority determination unit 111 reads the incident correspondence table 122 and compares the received incident information 400 with an incident registered in the incident correspondence table 122.

  Step 823: If the incident information 400 is not registered in the incident correspondence table 122, the process proceeds to Step 830.

  Step 824: The priority determination unit 111 extracts information on the corresponding business function 517 from the incident correspondence table 122 and adds it to the incident information 400.

  Step 825: The priority determination unit 111 reads the corresponding recovery limit time 515 from the incident response table 122, and if the recovery limit time 515 is not registered, the priority determination unit 111 proceeds to step 831.

  Step 826: The priority determination unit 111 extracts the corresponding recovery limit time 515 and the recovery work time 516 from the incident correspondence table 122, and adds them to the incident information 400.

  Step 827: If the extracted recovery limit time 515 exceeds 3 hours, the process proceeds to Step 831.

  Step 828: The priority determination unit 111 adds priority information “high” to the incident information 400.

  Step 829: The priority determination unit 111 calls the incident registration unit 112 and registers the incident information 400 in the incident information table with priority 125.

  Step 830: The priority determination unit 111 adds priority information “low” to the incident information 400, and proceeds to step 829.

  FIG. 19 is a flowchart illustrating an operation in which the information aggregation server 11 defines priority for an incident.

  Step 841: The priority determination unit 111 reads from the system information table 121 a record in which the tenant ID 401 of the incident information 400, the incident group name 402, and the business function 517 added to the incident information 400 in Step 824 match, and the corresponding record Information of the service operation rate 504 is acquired.

  Step 842: If the service operation rate 504 is 99.7% or more, the procedure goes to Step 848.

  Step 843: The priority determination unit 111 acquires information on the service core time 505 of the record read in Step 841.

  Step 844: The priority determination unit 111 reads a record that matches the tenant ID 401, the incident group name 402, and the instance ID 403 of the incident information 400 from the important operation data table 124, and acquires information on the important operation data 554 of the corresponding record. To do. The priority determination unit 111 further reads a record that matches the tenant ID 401, the incident group name 402, and the instance ID 403 of the incident information 400 from the operation data table 123, and acquires the operation data 545 that matches the important operation data 554.

  Step 845: When the incident occurrence date / time 405 of the incident information 400 is within the service core time 505 acquired at step 842 and there are two or more data exceeding the threshold among the operation data 545 acquired at step 844 , Step 848 is entered.

  Step 846: The priority determination unit 111 can lower the priority of the incident by adding the priority information “low” to the incident information 400.

  Step 847: The priority determination unit 111 calls the incident registration unit 112 and registers the incident information 400 in the incident information table 125 with priority. Since the registered incident information is merged from the collected incident information of multiple cloud systems, the incident with the highest priority among the incidents that occur in the system managed by this cloud management system. It becomes possible to output.

  Step 848: The priority determination unit 111 adds priority information “high” to the incident information 400, and proceeds to step 847.

  FIG. 20 is a flowchart of an operation in which the navigation server 12 acquires and registers an incident.

  Step 861: The navigation server 12 connects from the incident acquisition unit 211 to the information aggregation server 11.

  Step 862: The incident acquisition unit 211 acquires unacquired incident information from the priority incident information table 125 of the information aggregation server 11.

  Step 863: The incident registration unit with priority 212 compares the acquired incident information with the tenant ID 621, the incident group name 622, and the instance ID 623 of the system infrastructure information table 221, reads the matching records, and the infrastructure information 624 of the corresponding records The information of the center information 625 is acquired.

  Step 864: The priority-added incident registration unit 212 adds the base information 624 and the center information 625 to the acquired incident information.

  Step 865: The priority-added incident registration unit 212 generates an incident ID for identifying the incident and adds it to the incident information.

  Step 866: The incident response history registration unit 213 adds a new record to the incident response history table 223, and inputs incident information for the tenant ID 631, the incident group name 632, the instance ID, and the incident ID. “Open” is input to the status 636, and nothing is input to the user name 635 and the corresponding content 637.

  Step 867: The priority-affected incident registration unit 212 registers incident information in the incident information display table 222.

  Step 868: If the incident acquisition unit 211 has not acquired all of the incident information in the incident information table 125 with priority of the information aggregation server 11, the process proceeds to step 862.

  Step 869: The incident acquisition unit 211 waits for the defined monitoring interval, and proceeds to Step 861.

  FIG. 21 is a flowchart of an operation in which the navigation server 12 displays the incident list screen 700.

  Step 881: The navigation server 12 receives a request for the incident list screen 700 from the user.

  Step 882: The incident display unit 214 of the navigation server 12 acquires incident information from the incident information display table 222.

  Step 883: If the recovery limit time 611 of the acquired incident information is not registered, the incident display unit 214 proceeds to step 889.

  Step 884: The incident display unit 214 calculates “remaining time” by (incident occurrence date / time 608 + recovery limit time 611) − (current time + recovery work time 612).

  Step 885: If the priority 604 of the incident information is “high”, the process proceeds to step 887.

  Step 886: If the “remaining time” calculated in step 884 is 3 hours or less, the process proceeds to step 890.

  Step 887: The incident display unit 214 adds the “remaining time” information to the incident information.

  Step 888: The incident display unit 214 reads the status 636 of the record with the matching incident ID 634 from the incident response history table 223 and adds it to the incident information.

Step 889: The incident display unit 214 displays incident information on the incident list screen 700 according to the priority. If there is another business server running on the same physical computer as the business server where the incident occurs, information indicating that the business server is also affected by the incident may be added to the incident screen 700 good.

  Step 890: The incident display unit 214 changes the priority of the incident information to “high”, and proceeds to step 887.

  FIG. 22 is a flowchart of the operation when the business server 31 is transferred to another cloud system.

  Step 901: The business server 31 moves to another cloud system.

  Step 902: The business server 31 transmits the migration destination cloud system information from the transmission unit 303 to the navigation server 12.

  Step 903: The navigation server 12 calls the system infrastructure information registration unit 215, reads the record corresponding to the migrated business server 31 in the system infrastructure information table 221, and converts the infrastructure information 624 and the center information 625 to the migration destination cloud system information. Update.

  Step 904: The navigation server 12 calls the mail transmission unit 216, and matches the tenant ID 641, infrastructure information 644, and center information 645 in the escalation information table 224 from the migration destination cloud system information transmitted from the migrated business server 31. The record contact information 646 is acquired.

  Step 905: The mail transmission unit 216 notifies the contact address 646 that the business server 31 has been migrated.

DESCRIPTION OF SYMBOLS 10 ... Cloud management system, 11 ... Information aggregation server, 12 ... Navigation server, 13 ... Tenant, 31 ... Business server, 101 ... Receiving part, 102 ... Network interface part, 111: Priority determination unit, 112: Incident registration unit, 113: Operation data registration unit, 121 ... System information table, 122 ... Incident response table, 123 ... Operation data information table 124 ... Important operation data table, 125 ... incident information table with priority, 201 ... display unit, 214 ... incident list display unit, 222 ... incident information display table, 301 ... Log monitoring unit, 302... Operation data monitoring unit, 321... OS event log, 322. Log, 323 ... operational data, 700 ... incident list screen, 720... Incident details display screen.

Claims (12)

A cloud management system for managing incidents of business servers of multiple tenants running on virtual machines running on multiple cloud systems,
An incident receiver that receives and merges incident information from the business server;
A priority determination unit that determines the priority of the incident in the plurality of cloud systems based on the type and occurrence time of the merged incident information;
A cloud management system comprising an output unit that outputs incident information according to a determined priority. Each business server has priority information that describes the incident priority according to the incident type and time of occurrence.
The cloud management system according to claim 1, wherein the priority determination unit obtains the priority of an incident that has occurred based on information in the priority table. A server load measurement unit that measures the load of each business server
3. The cloud management system according to claim 2, further comprising a priority adjustment unit that increases an incident priority of the business server during a time period in which the business server load measured by the server load measurement unit exceeds a predetermined value. . A server load measurement unit that measures the load of each business server
The cloud management according to claim 2, further comprising a priority adjustment unit that lowers the incident priority of the business server during a time period when the business server load measured by the server load measurement unit falls below a predetermined value. system. The priority information further stores information on the recovery time corresponding to the incident,
The cloud management system according to claim 2, wherein the output unit outputs information related to the remaining time necessary for handling the incident in association with the incident.   When a virtual machine moves to another cloud system, the information related to the incident of the business server that runs on the moved virtual machine is changed from the source cloud system to the destination cloud system and output as an incident of the destination cloud system. The cloud management system according to claim 4, wherein the system is a cloud management system. A cloud management method for managing incidents of business servers of multiple tenants running on virtual machines running on multiple cloud systems,
The incident receiving unit receives and merges incident information from the business server,
The priority determination unit obtains the priority of the incident in the plurality of cloud systems based on the merged incident information type and occurrence time,
A cloud management method comprising: outputting incident information according to a priority obtained by an output unit. Includes priority information that describes incident priority according to incident type and time of occurrence for each business server,
The cloud management method according to claim 7, wherein the priority determination unit obtains the priority of the incident that has occurred based on information in the priority table. The server load measurement unit measures the load of each business server,
9. The cloud management method according to claim 8, wherein the priority adjustment unit increases the incident priority of the business server during a time period in which the business server load measured by the server load measurement unit exceeds a predetermined value. The server load measurement unit measures the load of each business server,
9. The cloud management method according to claim 8, wherein the priority adjustment unit lowers the incident priority of the business server during a time period when the business server load measured by the server load measurement unit falls below a predetermined value. . The priority information further stores information on the recovery time corresponding to the incident,
The cloud management method according to claim 8-11, wherein the output unit outputs information related to a remaining time necessary for handling an incident in association with the incident.   When a virtual machine moves to another cloud system, the information related to the incident of the business server that runs on the moved virtual machine is changed from the source cloud system to the destination cloud system, and the output unit becomes an incident as an incident of the destination cloud system The cloud management method according to claim 10, wherein:

Images