JP2005099973A - Operation management system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To exhibit an optimum system configuration satisfying requirement performance in a present operation pattern by monitoring the operation pattern fluctuating every moment and performing performance prediction on the basis of the operation pattern. <P>SOLUTION: By monitoring an access log of a system, the operation pattern is extracted. Throughput and a response time in the operation pattern are calculated by a performance prediction simulation part. When prediction performance does not satisfy the requirement performance of the system, a target of a configuration change is specified by a determination policy, and recalculation is repeated by performance prediction simulation. The optimum configuration satisfying the requirement performance is exhibited to an output device as the proposal configuration. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a system operation management method for maintaining a system in consideration of performance and price, and more particularly to a technique for preventing a service level from being lowered and a server going down.

  In recent years, with rapid changes in the business environment, integration and reorganization with many existing IT systems are performed, and a plurality of types of operations are operating on the same system. The business ratio (hereinafter referred to as business pattern) is defined as a performance requirement at the design / development stage, and a system configuration that satisfies the performance requirement is determined (for example, see Patent Document 1).

  However, it is difficult to accurately predict business patterns at the operation stage at the design / development stage. Also, the business pattern changes every moment due to factors such as time fluctuations, seasonal fluctuations, and function changes. Time fluctuation refers to fluctuation in which specific tasks are concentrated by time, such as login processing in the morning and batch processing in the evening. Seasonal fluctuation refers to fluctuations in which a specific job is concentrated only at a specific time, such as at the end of the month or before a large holiday. The function change refers to a change in which a load required for the system is dynamically changed by adding or changing a system function.

  If the ratio of business with a high load on the system increases due to business pattern fluctuations, the maximum number of processes (marginal throughput) of the system decreases and a state that does not satisfy the required performance occurs. When the peak time is reached in this state, there is a problem that the service level decreases (response time becomes slow) or the server goes down (server stops) before the required performance at the design and development stage. Occur.

  On the other hand, if the ratio of tasks with a high load on the system decreases due to variations in task patterns, the marginal throughput increases and a state where the required performance is excessively satisfied occurs. In this state, there is a problem of excessive investment in the system.

  Patent Document 2 describes a performance prediction apparatus that predicts the performance of a computer system when the workload is changed or when the hardware configuration is changed. The outline is to simulate the job operation status based on computer system operation information, hardware configuration information, and job execution information, and to predict changes in job operation status based on user-specified changes in workload and hardware configuration changes. Is.

  A WWW site performance monitoring apparatus that implements preventive measures for maintaining performance is described in Patent Document 3. The outline is determined based on the calculated performance value by accumulating time-series data of the access volume at the WWW site, predicting future access fluctuations using a statistical method, and calculating the performance value for each access. It is determined whether or not the performance can be maintained.

  A system proposing method for proposing a system considering performance and price is described in Patent Document 4. The outline is a system proposal device that proposes a system that considers performance and price, and calculates the response time and total price for each configuration that combines the definition contents of the system configuration, and proposes the one that satisfies the performance requirement and price requirement This is output as the target configuration.

JP-A-8-137725

JP-A-5-324358 JP 2002-268922 A JP 2002-183416 A

  In the above-described conventional technology, consideration is not given to the fluctuation of the business pattern. When the business pattern changes, the resource consumption pattern on each server also changes, so the maximum number of processes in the system (limit throughput) also changes. Therefore, when the limit throughput does not satisfy the required performance, there is a problem that the service level of the system is lowered or the server is down at the peak time. Further, when the required performance is excessively satisfied, there is a problem that excessive investment is made in the system.

  An object of the present invention is to present an optimum system configuration that satisfies the required performance in the current business pattern by monitoring the business pattern that changes every moment and predicting the performance based on the business pattern. is there.

  To achieve the above objectives, business patterns are extracted by monitoring the access logs of the operation management target system, response time and throughput in the business patterns and resource consumption in each configuration are calculated, and performance requirements are satisfied. An optimal configuration is presented as a proposed configuration.

  In the present invention, a business pattern is first extracted by constantly monitoring the access log.

  Next, based on the extracted business pattern and current hardware configuration information, a performance prediction simulation is executed to calculate the response time and throughput of the system and the resource consumption in each configuration.

  It is determined that the response time and throughput obtained by the above calculation satisfy the required performance, and if it is insufficient or excessive, a warning message for hardware configuration expansion or contraction is issued.

  A condition for specifying a hardware configuration to be expanded or contracted from the resource consumption information is stored as a determination policy. The target of system expansion or reduction is specified based on the resource consumption obtained by the calculation and the determination policy.

  The expansion or reduction of the hardware configuration is fed back to the hardware configuration information, and the effect of the expansion or reduction of the system is calculated by performance prediction simulation. The above calculation is repeated until the required performance is satisfied.

  According to the present invention, it is possible to present an optimal configuration that satisfies the required performance in the current business pattern, and therefore it is possible to optimize the system configuration in accordance with the change of the business pattern. As a result, it is possible to detect in advance system performance deficiencies, and this has the effect of preventing in advance a decrease in system service level and server down at peak times.

  In addition, since excessive system resources can be detected, there is an effect of suppressing excessive system investment and reducing costs.

  Embodiments of the present invention will be specifically described below with reference to the drawings.

  FIG. 1 shows the configuration of an embodiment of the present invention. In the figure, an operation management target system 101 is a system to be an operation management target, and an operation management apparatus 102 is an operation management apparatus for presenting an optimum configuration of the operation management target system.

  The operation management target system 101 includes a plurality of server groups, and each server group executes different tasks. In the example of FIG. 1, the business A uses the server group 1, the business B uses the server group 1, the server group 2, and the server group 3, and the business C uses the server group 1 and the server group 2. Each server group is composed of a plurality of servers, and the same server group can execute the same business and distribute the load. The information collection agent 103 collects operational information on each server and stores it in the access log 104. The information collection agent 103 stores server-specific information such as the CPU, memory, and disk of each server in the server performance information 105. The access log 104 and the server performance information 105 are periodically collected by the operation management apparatus 102 using a network. This network may be a LAN or a public network. Therefore, the operation management apparatus 102 may exist in the same site as the operation management target system 101, or may exist in a different site via a public network.

  The business pattern extraction unit 106 extracts a rate of business execution (hereinafter referred to as business pattern 107) from the access log 104 collected from each server. The configuration information extraction unit 108 extracts hardware configuration information 109 from the server performance information 105 collected from each server. The performance database 110 stores the amount of server resources consumed for each business. The performance prediction simulation unit 111 calculates the response time and throughput of the operation management target system. The required performance 112 of the system stores information on the number of processing required for the operation management target system, response time, and peak multiplicity. The determination policy 113 stores a condition for specifying a hardware configuration to be expanded or reduced. The required performance determination unit 114 determines that the predicted performance satisfies the required performance. The output device 115 displays the result of the determination and the change location and effect of the hardware configuration. The output device 115 and the performance prediction device 102 may be mounted on the same device.

  Hereinafter, the operation of the present invention from when a performance optimization request is input until the performance optimization ends will be described with reference to the flowchart of FIG. Optimization requests may be input at regular intervals such as every hour, or may be input manually when a failure occurs or by a system administrator. However, if the interval between the optimization requests is shortened, the load for collecting the access log 104 and the server performance information 105 and the load for changing the hardware configuration are increased.

  Step 201 is a step of collecting the access log 104 stored in each server. Step 202 is a step of extracting the business pattern 107 from the collected access log 104.

  Step 203 is a step of collecting server performance information 105 stored in each server.

  Step 204 is a step of extracting hardware configuration information 109 from the collected server performance information 105.

  Step 205 is a step of executing a performance prediction simulation. In this step, the current performance or the predicted performance after the configuration change is calculated. The performance prediction simulation unit 111 uses the queuing theory and performance simulator based on the business pattern 107 and hardware configuration information 109 extracted as described above and the performance database 110, and the number of people who perform business simultaneously (hereinafter, many Response time, throughput, and resource consumption are calculated. In the queue theory and the performance simulator, the response time and throughput and the resource consumption in each configuration can be calculated by inputting the resource usage time and the occurrence frequency for each business. Information stored in the performance database 110 is input as the resource usage time for each business. The occurrence frequency for each business is input based on the extracted business patterns 107 and the multiplicity changed in order from 1.

  Step 206 is a step of determining that the predicted performance calculated above satisfies the required performance 112 of the system. The required performance determination unit 114 compares the predicted performance calculated by the performance prediction simulation unit 111 with the required performance 112 of the system. If the predicted performance is within an allowable range (for example, 100% to 120%) of the required performance 112 of the system, in step 207, the current hardware configuration is presented to the output device 115 as the optimal configuration, and performance optimization is performed. finish.

  Step 208 is a step of warning the system administrator about expansion or contraction of the hardware configuration. If it is below the allowable range in the determination in step 206, the system performance is not satisfied, so a warning message requesting the system administrator to expand the hardware configuration is issued. On the other hand, if it exceeds the allowable range in the determination in step 206, the system performance is excessively satisfied, so a warning message requesting the system administrator to reduce the hardware configuration is issued.

  Step 209 is a step of displaying the result of the predicted performance to the system administrator. The predicted performance calculated in step 205 and the resource consumption of each server at the time of system limit are displayed. Further, the target of the hardware configuration to be expanded and contracted is specified from the resource consumption of each server at the time of the system limit and the determination policy 113, and presented to the system administrator.

  Step 210 is a step of feeding back hardware configuration expansion and contraction to the hardware configuration information 109. The target of expansion and contraction of the hardware configuration may be instructed interactively by the system administrator.

  When the operation management target system 101 has a function for automatically changing the configuration (a function that does not require a system administrator to manually change the system configuration), it is linked with the step 210 for changing the hardware configuration. Thus, the optimum configuration can be automatically maintained.

  Using the hardware configuration information 109 fed back as described above, the predicted performance after system expansion or reduction is recalculated in the performance prediction simulation of step 205. The recalculation is repeated until the predicted performance satisfies the required performance.

  FIG. 3 shows an example of a table created by the business pattern extraction unit 106. The keyword table 301 in FIG. 3A stores a keyword 304 that specifies that a task has been executed. In the example in the figure, /homepage.html identifies job A (homepage display), /jsp/kensaku.jsp identifies job B (file search), and /cgi/download.cgi identifies job C (file download). It is a keyword. The access log table 302 in FIG. 3B collects and stores the access log 104 collected by each server. When the keyword 304 is recorded in the access log table 302, it indicates that one corresponding job has been executed. Therefore, the number of executions 305 of each business is calculated by searching the access log table 302 for the keywords 304 that specify the business that has been executed and totaling them. The business pattern table 303 in FIG. 3C stores the number of executions 305 of each business and a business pattern 107 representing the rate at which each business is executed. In the example shown in the figure, 20 jobs are executed, and the breakdown is 50% (10) for job A (homepage display), 20% (4) for job B (file search), and job C (file). Download) was 15% (3 cases).

  FIG. 4 shows an example of a table created by the configuration information extraction unit 108. The server performance information 105 in FIG. 4A is stored in each server. The hardware configuration information 109 of FIG. 4B is created by collecting the server performance information 105 of each server, and the number of servers 401, the type of CPU 402, the number of CPUs 403 constituting each server group, A memory amount 404 and a disk performance 405 indicating the disk transfer capability are stored. In the example shown in the figure, the server group 1 is composed of four servers, the CPU type is CPU name 1, the number of CPUs is 2, the amount of memory is 2 GB, and the disk performance is 1 MB / second. .

  FIG. 5 shows an example of the performance database 110 that stores the resource consumption of each server group necessary to execute one task. This resource consumption is measured in advance in the design / development stage and stored in the performance database. In the illustrated example, the server configuration 501, CPU usage time 502 consumed by the server group 1, memory usage 503, disk usage time 504, CPU usage time 505 consumed by server group 2, memory usage 506, disk The usage time 507 is stored. When the CPU name 1 is used for the server configuration in the business A, the server group 1 consumes 0.33 seconds for the CPU, 10 KB for the memory, and 0.25 seconds for the disk.

FIG. 6 shows a calculation model for performance prediction simulation using queuing theory.
A queue is generated for each server group. The number of windows in each queue is the number of servers in the server group. The frequency of occurrence for each business is input based on the multiplicity that is changed sequentially from the business patterns 107 and 1. In the case of multiplicity of 20 people, 50% of 10 people are doing business A, 20% of 4 people are doing business B, and 15% of 3 people are doing business C at the same time. The performance database 110 is used for resource consumption for each business. With this calculation model, the response time, throughput, and resource consumption in each configuration are calculated. The total response time in each configuration indicates the response time of the system.

  FIG. 7 shows an example of calculation results of response time and throughput. The multiplicity 701 is the number of people who simultaneously execute tasks in the operation management target system 101, the response time 702 is the response time (seconds) when the multiplicity 701 is changed, and the throughput 703 is the throughput when the multiplicity 701 is changed (case / Seconds). The inflection value 705 indicates the multiplicity at which the response time changes rapidly due to resource contention. When the multiplicity 701 increases, the response time 702 gradually increases up to the inflection value 705 and rapidly increases when the inflection value 705 is exceeded. On the other hand, the throughput 703 increases in proportion to the multiplicity 701 until the inflection value 705, and approaches a constant value (limit throughput 704) when the inflection value 705 is exceeded. From this relationship graph, it is shown that when a job is executed with respect to the operation management target system 101 with the job pattern 107, the inflection value 705 is a system limit.

  FIG. 8 shows an example of the resource consumption calculated in step 205. In the example of the figure, the CPU usage rate 801, the memory usage rate 802, the disk usage rate 803, the CPU usage rate 804 consumed by the server group 2, the memory usage rate 805, and the disk usage for each multiplicity. A rate 806 is calculated.

  FIG. 9 shows an example of a determination policy 113 that stores conditions for changing the hardware configuration. In this example, a CPU usage rate determination condition 901, a memory usage rate determination condition 902, a disk usage rate determination condition 903, and a determination result 904 are stored. In the example of FIG. 8, since the resource usage rate 807 of the server group 1 is high and matches the condition of the determination policy item number 1 of FIG. 9, it is determined that the number of servers in the server group 1 is increased. Further, since the CPU usage rate 808 of the server group 2 is low and matches the condition of the determination policy item number 6, it is determined that the number of CPUs of the server group 2 is reduced.

  FIG. 10 shows an example of the determination result displayed on the output device 115 and the change location and effect of the hardware configuration. In this example, the current business pattern 1001, the current hardware configuration 1002, the current predicted performance 1003, the resource consumption 1004 of each server at the current system limit, the hardware configuration 1005 after performance optimization, and the performance optimization A predicted performance 1006 later, a resource consumption 1007 of each server at the time of system limit after performance optimization, and a warning message 1008 to the system administrator are displayed. In the example of the figure, a message for increasing the number of servers in the server group 1 and a message for decreasing the number of CPUs in the server group 2 are issued, and the effect on the predicted performance after performance optimization is displayed.

  As described above, by monitoring a business pattern that changes every moment and performing performance prediction based on the business pattern, it is possible to present an optimal system configuration that satisfies the required performance in the current business pattern. . As a result, it is possible to prevent a decrease in service level and server down in advance. Moreover, excessive system investment can be suppressed and cost can be reduced.

1 is an overview of the present invention. It is a flowchart of one Example of this invention. It is an example of extraction of a business pattern. It is an example of extraction of hardware configuration information. It is an example of a performance database. It is an example of a performance prediction simulation model. It is an example of a calculation result of response time and throughput. It is an example of the calculation result of resource consumption. It is an example of a judgment policy. It is an example of a display of a hardware configuration.

Explanation of symbols

101: Operation management target system, 102: Operation management apparatus, 103: Information collection agent,
104: access log, 105: server performance information, 106: business pattern extraction unit,
107: business pattern, 108: configuration information extraction unit, 109: hardware configuration information,
110: Performance database, 111: Performance prediction simulation unit,
112: System required performance 113: Determination policy 114: Required performance determination unit
115: Output device

Claims (2)

  In system operation management that takes into account changes in business patterns, means for collecting system access logs and extracting business patterns, means for extracting hardware configuration information from the system configuration, business patterns and hardware extracted above Means for calculating response time and throughput and resource consumption of each configuration from the hardware configuration information by performance prediction simulation, means for determining that the required performance is satisfied from the calculated response time and throughput, and system management An operation management system comprising means for warning a user of expansion or contraction of a hardware configuration. The apparatus according to claim 1, further comprising means for specifying an object of a hardware configuration to be expanded or reduced and presenting an optimal configuration from the resource consumption of each configuration calculated in the performance prediction simulation. Operation management system.

Images