WO2014091580A1 - クラウドシステム管理装置、クラウドシステム、再配置方法、及びプログラム - Google Patents
クラウドシステム管理装置、クラウドシステム、再配置方法、及びプログラム Download PDFInfo
- Publication number
- WO2014091580A1 WO2014091580A1 PCT/JP2012/082215 JP2012082215W WO2014091580A1 WO 2014091580 A1 WO2014091580 A1 WO 2014091580A1 JP 2012082215 W JP2012082215 W JP 2012082215W WO 2014091580 A1 WO2014091580 A1 WO 2014091580A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- server device
- service process
- cloud system
- unit
- quality
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 274
- 230000008569 process Effects 0.000 claims abstract description 253
- 238000001514 detection method Methods 0.000 claims abstract description 14
- 230000008707 rearrangement Effects 0.000 claims description 40
- 230000007257 malfunction Effects 0.000 abstract 2
- 238000010586 diagram Methods 0.000 description 19
- 230000001186 cumulative effect Effects 0.000 description 13
- 238000012545 processing Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000011002 quantification Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/203—Failover techniques using migration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2025—Failover techniques using centralised failover control functionality
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5019—Ensuring fulfilment of SLA
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5019—Ensuring fulfilment of SLA
- H04L41/5025—Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1034—Reaction to server failures by a load balancer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
Definitions
- Embodiments described herein relate generally to a cloud system management device, a cloud system, a rearrangement method, and a program.
- cloud services In recent years, an increasing number of companies have adopted services provided by cloud systems (hereinafter referred to as “cloud services”) in their business activities.
- One of the merits of using the cloud service is to reduce the TCO (Total Cost of Ownership) of the system. In particular, it is noted that the operation management cost is reduced.
- TCO Total Cost of Ownership
- Another attractive feature is that system installation and renewal costs are significantly reduced compared to systems built in-house.
- a cloud service provider that provides a large number of services can increase the overall utilization of computer resources by efficiently allocating computer resources to each service.
- the cloud system Since the cloud system is composed of a large number of computers, it is essential to take measures against computer failures. Generally, the greater the number of computers, the greater the probability of failure occurring in the cloud system. For example, even if the availability of a single computer is 99.95%, if there are 10,000 computers, the availability of all computers operating simultaneously is less than 1%.
- cloud services As the application range of cloud services expands, application to services that require stable operation 24 hours a day, 365 days a year, such as so-called social infrastructure services, has also been considered.
- cloud services such as big data analysis, which require a large amount of computing resources but are not necessarily highly reliable and highly available.
- guarantee of MTTR Mean Time To Repair
- MTTR Mobile Time To Repair
- a best effort availability with an availability factor of about 99% may be sufficient.
- availability is not important, there is a service that allows a computer resource to be used at a low price when there is a surplus of computer resources.
- JP 2005-011237 A Japanese Patent Laid-Open No. 2005-100387
- the cloud system management apparatus estimates the penalty information indicating the degree to which the service process cannot achieve the quality based on the quality information indicating the quality guaranteed by the service process operating on the server apparatus in the cloud system.
- a detection unit that detects a failure of the server device, and at least one first service process that operates on the server device in which the failure has been detected, operates on the relocation destination server device
- a determination unit that preferentially determines the server device having a small sum of the penalty information of at least one second service process as the relocation destination server device; and the first service process is determined to be the relocation destination server device.
- a rearrangement unit that rearranges by moving to (1).
- a cloud system is a cloud system including a plurality of server apparatuses on which at least one service process operates and a cloud system management apparatus, and the cloud management apparatus operates on a server apparatus in the cloud system.
- an estimation unit for estimating penalty information indicating a degree to which the service process cannot achieve the quality
- a detection unit for detecting a failure of the server device, and the failure detected
- the server device having a small sum of the penalty information of at least one second service process operating on the relocation destination server device is provided.
- a determination unit that preferentially determines the relocation destination server device; and 1 service process, and a rearrangement unit for rearranging by transferring to the server device of the relocation destination.
- the estimation unit generates penalty information indicating the degree to which the service process cannot achieve the quality based on the quality information indicating the quality guaranteed by the service process operating on the server device in the cloud system.
- the program according to the embodiment is configured to estimate, based on quality information representing quality guaranteed by a service process operating on a server apparatus in a cloud system, a penalty information representing a degree to which the service process cannot achieve the quality.
- a detection unit that detects a failure of the server device, and at least one first service process that operates on the server device in which the failure has been detected, operates on the relocation destination server device
- a determination unit that preferentially determines the server device having a small sum of the penalty information of at least one second service process as the relocation destination server device; and the first service process is determined to be the relocation destination server device.
- FIG. 1 is a diagram illustrating an example of a configuration of a cloud system according to an embodiment.
- FIG. 2 is a diagram illustrating an example of status data of the cloud system management device according to the embodiment.
- FIG. 3 is a diagram illustrating an example of estimate data of the cloud system management device according to the embodiment.
- FIG. 4 is a diagram for explaining an example of the first cluster of the cloud system according to the embodiment.
- FIG. 5 is a diagram for explaining an example of the second cluster of the cloud system according to the embodiment.
- FIG. 6 is a diagram for explaining an example of a service process rearrangement method of the second cluster of the cloud system according to the embodiment.
- FIG. 1 is a diagram illustrating an example of a configuration of a cloud system according to an embodiment.
- FIG. 2 is a diagram illustrating an example of status data of the cloud system management device according to the embodiment.
- FIG. 3 is a diagram illustrating an example of estimate data of the cloud system management device according to the embodiment.
- FIG. 4 is
- FIG. 7 is a flowchart for explaining an example of the rearrangement method of the service process of the first cluster of the cloud system management apparatus of the embodiment.
- FIG. 8 is a diagram for explaining an example of a service process rearrangement method of the first cluster of the cloud system according to the embodiment.
- FIG. 9 is a diagram for explaining an example of a service process rearrangement method of the first cluster in the cloud system according to the embodiment.
- FIG. 10 is a diagram for describing an example of a method for rearranging the service processes of the first cluster in the cloud system according to the embodiment.
- FIG. 11 is a diagram for explaining an example of a service process rearrangement method of the first cluster in the cloud system according to the embodiment.
- FIG. 12 is a flowchart for explaining an example of a method for determining a server apparatus to which the service process of the first cluster of the cloud system management apparatus of the embodiment is to be relocated.
- FIG. 13 is a diagram illustrating an example of a hardware configuration of the cloud system management device and the server device of the cloud system according to the embodiment.
- SLA Service Level Agreement
- the SLA is a service provider that promises customers the quality of service.
- SLA guarantees availability, performance such as average response time, and the like.
- the guarantee quality varies depending on the type of cloud service, as in the case of availability.
- SLA can be roughly divided into two types according to the level of guarantee. Guarantee type and best effort type.
- the guarantee type promises the required quality.
- the best-effort type promises to make the utmost effort to improve quality. In general, it is considered that a service that requires a guarantee of a performance type often requires a guarantee of a guarantee type in terms of availability.
- the best-effort service can increase the overall utilization of computer resources by performing overcommit that allocates computer resources exceeding the total amount of physical computer resources.
- FIG. 1 is a diagram illustrating an example of a configuration of a cloud system 100 according to the embodiment.
- the cloud system 100 of this embodiment includes a cloud system management device 10, server devices 31a to 31n, and server devices 32a to 32n.
- the server devices 31a to 31n are assumed to be used for the first cluster 33 at the start of operation of the cloud system 100. Further, it is assumed that the server devices 32a to 32n are used for the second cluster 34 at the start of operation of the cloud system 100. Details of the first cluster 33 and the second cluster 34 will be described later.
- server devices 31a to 31n are referred to as server devices 31 when they are not distinguished.
- server devices 32a to 32n are not distinguished, they are referred to as server devices 32.
- the server device 31 and the server device 32 may be an arbitrary number.
- the cloud system 100 may be a cloud service provider that provides a cloud service for profit, or may be a private cloud system.
- the cloud system management device 10, the server devices 31a to 31n, and the server devices 32a to 32n are connected to each other via a LAN (Local Area Network) 20.
- the cloud system management apparatus 10, the server apparatuses 31a to 31n, and the server apparatuses 32a to 32n are connected to the client apparatuses 51a to 51n via the LAN 20 and the network 40.
- the client devices 51a to 51n are referred to as client devices 51 when they are not distinguished.
- the client device 51 is a device used by the user to receive the service of the cloud system 100.
- the client device 51 may be an arbitrary device.
- the client device 51 is a PC (Personal Computer), a portable terminal, or the like.
- the network 40 is, for example, the Internet.
- the server devices 31a to 31n, and some of the server devices 32a to 32n are located at other locations, the LAN 20 may be the Internet, a VPN (Virtual Private Network), or the like.
- the cloud system management device 10 includes a detection unit 1, a storage unit 2, an estimation unit 3, a determination unit 4, and a rearrangement unit 5.
- the detection unit 1 detects a failure of the server devices 31a to 31n and the server devices 32a to 32n.
- the storage unit 2 stores status data 6 and estimated data 7.
- FIG. 2 is a diagram illustrating an example of quality achievement status data of the cloud system management apparatus 10 according to the embodiment.
- the status data 6 includes a service process name, quality information, accumulated inoperable time, and penalty information.
- the service process name is the name of a service process that operates on the server device 31 (32).
- Quality information is the quality guaranteed by the service process.
- the quality information is determined by SLA, for example.
- the quality is availability and performance applied to the service process.
- the performance is an average response time of the service process.
- the cumulative inoperable time is the sum of the times when the service process has become inoperable.
- the penalty information is information indicating the degree to which quality information cannot be achieved.
- the penalty information is a penalty.
- the penalty is generated, for example, by a charge obtained by multiplying the time exceeding the inoperable time permitted by the quality information (hereinafter referred to as “fault time”) by the hourly unit price.
- the quality information of service process A indicates that the cumulative inoperable time of service process A is within 52 minutes in one year. That is, the estimation unit 3 generates penalty information when the cumulative inoperable time exceeds 52 minutes. The cumulative inoperable time of the service process A is 0 minute. Therefore, the estimation unit 3 does not generate penalty information yet.
- the quality information of service process B indicates that the cumulative inoperable time of service process B is within 30 minutes in one year. That is, the estimation unit 3 generates penalty information when the cumulative inoperability time exceeds 30 minutes. The cumulative inoperable time of the service process B is 29 minutes. Therefore, the estimation unit 3 does not generate penalty information yet. However, there is only one more minute that service process B can be made inoperable until a penalty is incurred.
- the quality information of service process N indicates that the cumulative inoperable time of service process N is within 40 minutes in one year. That is, the estimation unit 3 generates penalty information when the cumulative inoperability time exceeds 40 minutes. Note that the cumulative inoperable time of the service process N is 42 minutes. Therefore, the estimation unit 3 generates penalty information (penalty) for XXX yen by multiplying the penalty time (2 minutes) by the hourly unit price of the penalty time.
- the cloud system management apparatus 10 quantifies the achievement status of quality information (for example, SLA) as status data 6. Quantification of the achievement status of quality information is performed for each service process. The achievement status for each service process is recorded in the storage unit 2 as needed for each service process.
- quality information for example, SLA
- the method of generating penalty information is not limited to the method described above.
- the quality information of FIG. 2 is defined with respect to the availability of the service process, the quality information is not limited to that regarding the availability of the service process.
- the quality information may be information related to the performance of the service process such as a processing time (average response time) calculated according to a rate at which the resource of the server device can be used.
- FIG. 3 is a diagram illustrating an example of the estimate data 7 of the cloud system management device 10 according to the embodiment.
- the estimate data 7 includes a service process name and expected penalty information.
- the service process name is the name of the service process.
- the expected penalty information is estimated by adding the inoperable time when the service process is rearranged to the cumulative inoperable time of the service process.
- the expected penalty information can be used as one indicator of whether or not the service process may be stopped. Note that the method of calculating the expected penalty information may be arbitrarily determined according to the quality information of the service process.
- the estimation unit 3 estimates the penalty information indicating the degree to which the service process cannot achieve the quality based on the quality information indicating the quality guaranteed by the service process.
- the determination unit 4 selects at least one service process that operates as the rearrangement destination server device on the rearrangement destination server device. The total sum of the penalty information is determined to be minimum.
- the rearrangement unit 5 includes a start unit 8 and a stop unit 9.
- the rearrangement unit 5 rearranges the service process by stopping the service process by the stop unit 9 and starting the service process by the start unit 8.
- the stop unit 9 stops the service process A of the server device 31a.
- the start unit 8 starts the service process A on the server device 32a.
- the rearrangement unit 5 moves (rearranges) the service process A from the server device 31a to the server device 32a. At this time, the time elapsed from the stop to the start is added to the cumulative operation disabled time and recorded in the storage unit 2.
- the stopping unit 9 does not actually stop the service process A, but instead of the time required for the stop, it has been required to detect a failure of the server device 31a. Add time (eg, heartbeat timeout time) to the cumulative inoperable time.
- time eg, heartbeat timeout time
- FIG. 4 is a diagram for explaining an example of the first cluster 33 of the cloud system 100 according to the embodiment.
- a service process hereinafter referred to as “first service process” whose performance, availability, etc. are guaranteed by the quality information operates.
- the first cluster 33 is a unit in which a plurality of server devices 31 constituting the cloud system 100 are logically grouped. At least one service process operating on the server device 31 is fixedly arranged by the cloud system management device 10. That is, at least one service process operating on the server device 31 operates with hardware and software configurations based on a system design determined so as to guarantee quality information such as predetermined performance requirements.
- hot swap is performed first.
- the resources of the server device 32 of the second cluster 34 are released to make the server device 32 unused, and the unused server device 32 is replaced with the failed server device 31 of the first cluster 33. And replace.
- the server device 32 subject to hot swapping is determined by the determination unit 4.
- the determination unit 4 determines the server device 32 to be hot swapped in the second cluster 32 so as to satisfy the following two conditions.
- the first condition is that a computer resource is provided that can exhibit sufficient performance even if the server device 32 is replaced with a failed server device 31.
- the second condition is that the penalty information generated in the service process operating on the server apparatus 32 is the smallest as a result of stopping the server apparatus 32.
- this hot swap it can be considered as if the failed server device 31 is restored, and instead the server device 32 in the second cluster 34 has failed.
- the service process resumes in the first cluster 33 with the same arrangement as the original arrangement.
- the service processes operating on the server device 32 are rearranged in the same manner as when the server device 32 is stopped due to a failure.
- the service process A and the service process B are operating in the server device 31a.
- the communication speed between the service process A and the service process B is improved.
- the cloud system 100 guarantees the performance of the service process A and the service process B.
- the service process C operates alone on the server device 31b. Therefore, the service process C can occupy resources such as a CPU (Central Processing Unit), a memory, and a communication I / F of the server device 31b. Thereby, the cloud system 100 guarantees the performance of the service process C.
- FIG. 5 is a diagram for explaining an example of the second cluster 34 of the cloud system 100 according to the embodiment.
- a service process hereinafter referred to as “second service process” whose performance or availability is not guaranteed by the quality information operates.
- the second service process operates in an environment where performance, availability, etc. can be maximized as much as possible. Therefore, the server device 32 of the second cluster 34 may actively overcommit to increase the utilization rate of computer resources. That is, the server device 32 may allocate more logical resources than physical resources.
- the second cluster 34 is a unit obtained by logically grouping a plurality of server devices 32 constituting the cloud system 100. At least one service process operating on the server device 32 is dynamically arranged by the cloud system management device 10.
- the cloud system management apparatus 10 dynamically arranges service processes according to a specific algorithm.
- the algorithm includes the resource, load, and surplus resource of the server device 32 used by the service process, quality information (for example, SLA) of the service process, the cost (price, etc.) of the service provided by the service process, It is determined based on information such as the arrangement status.
- the cloud system management device 10 relocates the service process that was operating on the server device 32 to another server device 32 in the second cluster 34.
- service process A is the second service process. Then, it is assumed that the server device 32 in which the service process A was operating has failed.
- the service process B is operating.
- a service process C and a service process D are operating.
- a service process E and a service process F are operating.
- the rearrangement unit 5 rearranges the service process A so as to minimize the influence on the performance or availability of other service processes.
- the rearrangement unit 5 rearranges the service process A so that the performance or availability of the service process A itself can be maximized.
- the server device 32a in which only the service process B is activated is selected as the relocation destination of the service process A.
- the determination unit 4 in this example determines the relocation destination of the service process A so that the second service process is equally distributed to the server device 32.
- the service processes are described separately as service processes A to F, but the service processes A to C here are not related to the service processes A to C of FIG. The same applies to FIGS. 6 and 8 to 11 below.
- FIG. 6 is a diagram for explaining an example of a second cluster service process relocation method of the cloud system 100 according to the embodiment.
- the service process A and the service process B are operating in the server device 32a.
- the server device 32b indicates that a failure has occurred. It is assumed that the service process C and the service process D are operating in the server device 32b.
- a service process E and a service process F are operating.
- the relocation unit 5 relocates the service process C that has been operating on the server device 32b to the server device 32c. Further, the rearrangement unit 5 rearranges the service process D that has been operating on the server device 32b, on the server device 32a. That is, in the example of FIG. 6, the rearrangement unit 5 rearranges the service processes that were operating on the server device 32 b evenly on the other server devices 32. As a result, the performance or availability of the service process operating in the second cluster can be maximized as much as possible.
- FIG. 7 is a flowchart for explaining an example of a service process relocation method of the first cluster 33 of the cloud system management apparatus 10 according to the embodiment.
- 8 to 10 are diagrams for explaining an example of a service process relocation method of the first cluster 33 of the cloud system 100 according to the embodiment.
- the detection unit 1 detects a failure of the server device 31 in the first cluster 33 (step S1).
- the first cluster 33 includes a server device 31a and a server device 31b.
- the second cluster 34 includes a server device 32a, a server device 32b, and a server device 32c.
- the service process A and the service process B are operating in the server device 31a.
- the server device 31b indicates that a failure has occurred.
- the detection unit 1 detects a failure of the server device 31b. It is assumed that the service process C and the service process D are operating in the server device 31b.
- a service process G is operating.
- a service process H and a service process E are operating.
- a service process J and a service process K are operating.
- the determination unit 4 determines the server device 31 in which the failure is detected and the server device 32 (relocation destination server device 32) to be hot-swapped (step S2).
- the case of FIG. 9 will be described as an example.
- the example of FIG. 9 is an example in which the determination unit 4 determines the server device 32 that is the relocation destination of the service process of the server device 31b as the server device 32b.
- the details of the determination method (step S2) of the relocation destination server device 32 by the determination unit 4 will be described later.
- the cloud system 100 recognizes the server device 31 of the first cluster 33 subject to hot swapping as the server device 32 of the second cluster 34 after hot swapping.
- the cloud system 100 recognizes the server device 32 of the second cluster 34 that is the target of hot swapping as the server device 31 of the first cluster 33 after hot swapping.
- FIG. 10 shows that the cluster system 100 uses the relocation destination server apparatus 32b as the first cluster.
- the cluster system 100 recognizes the failed server device 31b as the second cluster. The failed server device 31b is used in the second cluster after recovery if it can be recovered due to a minor failure.
- the relocation unit 5 stops the service process (second service process) of the relocation destination server device 32 (step S3).
- the rearrangement unit 5 starts the rearranged service processes (first service process and second service process) (step S4).
- the case of FIG. 11 will be described as an example.
- the rearrangement unit 5 moves the first service process (service process C and service process D) that needs to be rearranged to the server device 32 b determined by the determination unit 4.
- the relocation unit 5 moves the second service process (service process H) that was operating on the relocation destination server device 32b to the server device 32a.
- the rearrangement unit 5 moves the second service process (service process E) that was operating in the server device 32b that is the rearrangement destination to the server device 32c.
- the server device 31 b in which the first service process (service process C and service process D) requiring relocation has been operating is hot on the server device 32 b used by the second cluster. It is swapped. Thereby, the cloud system management apparatus 10 can rearrange the first service process while maintaining the quality (availability or performance) of the first service process of the first cluster.
- the cloud system 100 always guarantees the quality of the first cluster composed of the server devices 31 on which the first service process in which the quality information is guaranteed to guarantee the quality.
- a second cluster composed of server devices 32 on which a second service process that is not defined by quality information operates.
- the cloud system 100 may make one cluster without making such a distinction.
- the cloud system management device 10 makes an individual determination for each server device 31 (32), regardless of the type of cluster, according to the quality information of the service process operating on each server device 31 (32). Relocate the service process.
- the cluster system 100 may distinguish clusters in more detail.
- the second cluster 34 in which the second service process operates may be divided into a second cluster 34 and a third cluster according to quality information indicating quality guaranteed by the service process.
- a function for quantitatively determining the quality required for the service process based on a threshold value or the like is added to the cloud system management apparatus 10.
- the cloud system management apparatus 10 assigns a service process whose threshold value is equal to or greater than a predetermined value to the server apparatus 32 of the second cluster 34.
- the cloud system management apparatus 10 assigns a service process whose threshold value is smaller than a predetermined value to the server apparatus of the third cluster.
- the function may be added to the estimation unit 3, for example.
- the cloud system management apparatus 10 may set the upper limit of the resource overcommit rate (allocated logical resource / physical resource) of the third cluster to be larger than the upper limit of the resource overcommit rate of the second cluster. Further, the cloud system management apparatus 10 may make the usage fee for the second cluster higher than the usage fee for the third cluster.
- the decision unit 4 decides which cluster to select as a target for hot swapping by comparing how much the overcommit rate at the time reaches the upper limit of the overcommit rate. Good.
- the relocation unit 5 does not have to move the service process operating on the relocation destination server device 31 (32) to the other server device 31 (32).
- the quality information may be a processing time of a service process.
- the penalty information is determined according to the processing time. If the relocation destination server device 31 (32) has sufficient resources, even if a service process is added to the relocation destination server device 31 (32), it is not necessary to generate penalty information. In such a case, the relocation unit 5 does not have to move the service process operating on the relocation destination server device 31 (32) to the other server device 31 (32).
- FIG. 12 is a flowchart for explaining an example of a method for determining the server device 32 to which the service process of the first cluster 33 of the cloud system management device 10 of the embodiment is relocated.
- the estimation unit 3 selects one server device h from the server devices 32 in the second cluster 34 (step S11).
- the estimation unit 3 selects one service process S of the server device h (step S12).
- the estimation unit 3 estimates penalty information when the service process S is rearranged (step S13).
- the estimation unit 3 determines whether all the service processes S of the server device h have been selected (step S14). When all the service processes S of the server apparatus h are selected, the estimation unit 3 calculates the total G h of the estimation (Step S15). If all the service processes S of the server apparatus h have not been selected, the process returns to step S12.
- the estimating unit 3 determines whether all the server devices 32 in the second cluster 34 have been selected (step S16).
- step S17 determination unit 4 selects the server device h that has the smallest total G h (step S17). Note that, in step S17, determination unit 4 may not necessarily select the server devices h total G h is minimized. For example, the determination unit 4 may give priority to the server device h having a small total G h in consideration of other indexes. If all the server devices 32 in the second cluster 34 have not been selected, the process returns to step S11.
- the estimation of the penalty information for each service process can be calculated based on, for example, a value obtained by adding the expected processing time for relocation to the inoperable time for the past year and quality information (for example, SLA).
- the estimated processing time required for rearrangement is estimated based on the average of past actual values. Specifically, the average of past performance values of the processing time required for rearrangement can be obtained by dividing the inoperable time recorded in the storage unit 2 for each service process by the number of rearrangements.
- the result evaluated in advance may be used.
- the actual value of another service similar to the service process to be rearranged may be used.
- the optimal target is selected from among them.
- the expected value of the penalty information when the server device 32 further fails after the rearrangement is also estimated. If the server device 32 is selected in this way, not only the penalty information after the rearrangement is minimized, but also the expected value of the penalty information that takes into account the case where the server device 32 further fails after the rearrangement is minimized. In this way, the server device 32 can be selected.
- each server device 32 is assigned a number from 1 to N.
- the expected value of the penalty information when the server device 32 in the second cluster 34 fails is calculated.
- each server device h k (1 ⁇ k ⁇ N) is the same. Further, assuming that the probability that each server device h k (1 ⁇ k ⁇ N) fails is sufficiently small, the expected value of the penalty information when a plurality of server devices h k fail simultaneously is set to 0. It is considered. That is, since the probability of a two-point failure is quite small, the expected value of the penalty information up to the single point failure is regarded as the main part of the expected value of the penalty information.
- the determination unit 4 determines the server device h k having the smallest main part as a relocation destination.
- s be a service process operating on the server device 32 of the second cluster 34.
- g (n, s) be the estimated value of the penalty information when the service process s is relocated n times from the estimated reference time.
- the contract time is estimated by subtracting the value promised in the quality information (for example, 52 minutes) from the value obtained by adding the expected processing time for n relocations to the inoperable time for the past year.
- penalty information for example, penalty
- the penalty information is set to g (n, s). Note that g (0, s) indicates penalty information at the time of estimation of the service process s.
- the penalty information of all the service processes s after the service process s of the server device h k is moved to another server device 32 (after being rearranged once) can be expressed by the following equation (2).
- Equation (2) is a set of service processes running on the server device h k .
- the first term of the equation (2) indicates the sum total of the penalty information of the service process s operating on the server device h k .
- the second term of the equation (2) indicates the sum total of the penalty information of the service processes s operating on the server devices 32 other than the server device h k . Equation (2) can be transformed into Equation (3) as follows.
- the penalty information of the service processes s of all the server devices 32 after the service process s of the server device h k is transferred to another server device 32 includes the penalty information at the time of estimation reference (first term) and the server This is the sum of the increase in the penalty information (second term) by relocating the service process s on the device h k once. It can be seen that the term depending on k in Equation (3) is only the second term.
- the server device h in which the second term of Equation (3) is the minimum (same) Indicates that there are a plurality of k . Therefore, when further calculating the expected value of the penalty information estimate, it may be assumed that the following equation (4) is the same.
- the expectation of the penalty information when the server device 32 in the second cluster 34 fails Calculate the value.
- the expected value of the penalty information is obtained by adding the expected value of the increase in the penalty for the service process s caused by the failure of any one of the server devices h i (1 ⁇ i ⁇ N) to the equation (1). It can be calculated by the following equation (5).
- p is the server device h i and the failure probability (assuming that all the failure probability of the server device h i are the same.).
- / H i (where "/”. Indicating that the upper line) is a set of service process that worked after relocation (after once hot swapping) the server device h i. / G (s) (where “/” indicates an overline) is an increase in the penalty information of service s.
- Equation (5) can be transformed into Equation (7) as follows.
- Equation (4) The third term (equation (4)) of equation (7) is the same among the server apparatuses h k that are the evaluation targets of the expected value of the penalty information. Therefore, the term that depends on k is only the first term of Equation (7). That is, the determination unit 4 may determine the server device h k that has the minimum value calculated by the following equation (8).
- Equation (8) can be actually calculated because the value can be determined regardless of the failure probability p and the server device 32 to which each service process s is relocated. Based on the above calculation, the following equation (9) can be used to evaluate the expected value of the penalty information even when the server apparatus h k fails twice or more (two) after the rearrangement. Recognize.
- n 3 in Expression (9), and the server apparatus h k at the time of estimation reference (1 ⁇ k) The case where the service process s that has been operating under ⁇ N) is to be relocated is evaluated.
- the estimation unit 3 estimates the expected value of the penalty information by increasing the value of n and evaluating Equation (9).
- the determination unit 4 determines the server device h k to be hot swapped based on the expected value of the penalty information.
- the server device 31 (32) in the cloud system 100 fails, the quality guaranteed by the service process by the estimation unit 3, the determination unit 4, and the relocation unit 5 Accordingly, the usable server device 31 (32) can be efficiently allocated to the service process.
- a service process having quality information for example, SLA
- quality information for example, SLA
- the cloud system management device 10 and the cloud system 100 of other embodiments will be described.
- the cloud system 100 of the above-described embodiment all the server devices 31 (32) are used.
- the case where there is a spare server device as a surplus resource will be described as the cloud system 100 according to another embodiment.
- the spare server device is used as a server device of the second cluster 34.
- the quality guaranteed by the service process (hereinafter referred to as “spare service process”) operating on the spare server device is assumed to be lower than that of the server device 32 of the second cluster 34.
- the spare service process is a service process that can be stopped immediately if a failure occurs in the server device 31 (32). Therefore, even if the determination unit 4 determines the spare server device 31 as a hot swap target, the spare service process does not have to be transferred to another server device 31 (32) or another spare server device.
- the determination unit 4 first determines the spare server device as a hot swap target.
- the cloud system management apparatus 10 and the cloud system 100 according to the present embodiment can efficiently allocate the resources of the cloud system 100 according to the quality guaranteed by the service process even when the resources of the cloud system 100 have room. it can.
- FIG. 13 is a diagram illustrating an example of a hardware configuration of the cloud system management device and the server device of the cloud system according to the embodiment.
- the case of the cloud system management apparatus 10 will be described as an example.
- the cloud system management apparatus 10 of this embodiment includes a control unit 61, a main storage unit 62, an auxiliary storage unit 63, a display unit 64, an input unit 65, and a communication I / F unit 66.
- the control unit 61, main storage unit 62, auxiliary storage unit 63, display unit 64, input unit 65, and communication I / F unit 66 are connected to each other via a bus 67.
- the control unit 61 executes the program read from the auxiliary storage unit 63 to the main storage unit 62.
- the main memory 63 is a memory such as a ROM (Read Only Memory) or a RAM (Random Access Memory).
- the auxiliary storage unit 63 is an HDD (Hard Disk Drive), an optical drive, or the like.
- the display unit 64 is a screen that displays the state of the cloud system management apparatus 10 and the like.
- the display unit 6 is a liquid crystal display, for example.
- the input unit 65 is an interface for operating the cloud system management apparatus 10.
- the input unit 65 is, for example, a keyboard or a mouse.
- the communication I / F unit 66 is an interface for connecting to a network.
- the program executed by the cloud system management apparatus 10 of the present embodiment is a file in an installable format or an executable format, such as a CD-ROM, a flexible disk (FD), a CD-R, a DVD (Digital Versatile Disk), and the like. It is recorded on a computer-readable recording medium and provided as a computer program product.
- the program executed by the cloud system management apparatus 10 of the present embodiment may be provided by being stored on a computer connected to a network such as the Internet and downloaded via the network. Moreover, you may comprise so that the program run with the cloud system management apparatus 10 of this embodiment may be provided or distributed via networks, such as the internet.
- the program of the cloud system management apparatus 10 of the present embodiment may be configured to be provided by being incorporated in advance in a ROM or the like.
- the program executed by the cloud system management apparatus 10 has a module configuration including the above-described functional blocks (detection unit 1, estimation unit 3, determination unit 4, and rearrangement unit 5).
- the functional block is loaded onto the main storage unit 62 by the control unit 61 reading out and executing the program from the auxiliary storage unit 63 or the like. That is, each functional block is generated on the main storage unit 62.
- the storage unit 2 is, for example, an auxiliary storage unit 63.
- the data in the storage unit 2 realized by the auxiliary storage unit 63 may be expanded in the main storage unit 62.
- the server device 31 (32) in the cloud system 100 fails, the service process is performed by the estimation unit 3, the determination unit 4, and the relocation unit 5.
- the server device 31 (32) that can be used can be efficiently allocated to the service process in accordance with the quality guaranteed by.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Hardware Redundancy (AREA)
- Computer And Data Communications (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
実施形態のクラウドシステム管理装置は、クラウドシステム内のサーバ装置で動作するサービスプロセスが保証する品質を表す品質情報に基づいて、サービスプロセスが品質を達成できない程度を表す違約情報を見積もる見積部と、サーバ装置の故障を検出する検出部と、故障が検出されたサーバ装置で動作する少なくとも1つの第1サービスプロセスを再配置するときに、再配置先のサーバ装置で動作する少なくとも1つの第2サービスプロセスの違約情報の総和が小さいサーバ装置を優先して再配置先のサーバ装置に決定する決定部と、第1サービスプロセスを、再配置先のサーバ装置に移すことにより再配置する再配置部とを備える。
Description
本発明の実施形態は、クラウドシステム管理装置、クラウドシステム、再配置方法、及びプログラムに関する。
近年、クラウドシステムにより提供されるサービス(以下「クラウドサービス」という。)を事業活動に採用する企業が増えている。クラウドサービスを利用するメリットのひとつは、システムのTCO(Total Cost of Ownership)の削減である。特に、運用管理コストが低減される点が注目される。また、システムの導入費用や更新費用等が、社内で構築するシステムに比べて大幅に削減されることも魅力のひとつである。
クラウドサービスの利用によりTCOが削減される根本的な理由のひとつとして、サーバ装置等のコンピュータ資源の有効利用が挙げられる。多数のサービスを提供しているクラウドサービスの事業者は、コンピュータ資源を効率的に各サービスに割り当てることにより、コンピュータ資源の総合的な利用率をあげることができる。
これにより、クラウドサービスの事業者は、ユーザが、個別にシステムを所有するのに比べて安価なコストでサービスを提供できる。なお、従来の典型的なシステムでは、サービス毎にコンピュータ資源を固定的に割り当てる前提でシステムが設計されているため、多数のサービスプロセスを多数のコンピュータ上へ自在に配置できるようなシステム構成ではなかった。
クラウドサービスの普及について、技術的な側面を見ると、仮想化技術の発展が大きく関与している。仮想化技術によって、物理的なコンピュータ資源を論理的な単位(仮想マシン)に分割して、サービスプロセスに割り当てることができる。これにより、コンピュータ資源のサービスへの割り当てを自在に行うことができるようになった。その結果、サービスの種類に関わらず、物理的コンピュータ資源の共有ができるようになり、最適配置の可能性が大きく広がった。
クラウドシステムは多数のコンピュータで構成されるため、コンピュータの故障を想定した対策が必須である。一般的に、コンピュータの台数が大きくなればなるほど、クラウドシステムの中での故障の発生確率は大きくなる。例えば、コンピュータ単独の可用性が99.95%だとしても、コンピュータが10000台あれば、全てのコンピュータが同時に動作する可用性は、1%に満たない。
クラウドサービスの適用範囲が広がるにつれ、いわゆる社会インフラ・サービスのような、24時間365日の安定的な運用が求められるサービスへの適用も検討されるようになってきた。一方、ビッグデータ分析のような、大量の計算資源を必要とするものの、必ずしも高信頼性や高可用性が絶対ではないクラウドサービスもある。
例えば、24時間365日の連続運転で1分以内のMTTR(Mean Time To Repair)の保証が要求される場合がある。一方、稼働率99%程度のベストエフォートの可用性で十分な場合もある。また、可用性が重視されない例として、コンピュータ資源が余っているときに、当該コンピュータ資源を低価格で利用させるようなサービスもある。
しかしながら、クラウドシステム内のサーバ装置が故障したとき、サービスプロセスが保証する品質に応じて、使用できるサーバ装置を、サービスプロセスに効率的に割り当てることが難しいという課題があった。
実施形態のクラウドシステム管理装置は、クラウドシステム内のサーバ装置で動作するサービスプロセスが保証する品質を表す品質情報に基づいて、前記サービスプロセスが前記品質を達成できない程度を表す違約情報を見積もる見積部と、前記サーバ装置の故障を検出する検出部と、前記故障が検出された前記サーバ装置で動作する少なくとも1つの第1サービスプロセスを再配置するときに、前記再配置先のサーバ装置で動作する少なくとも1つの第2サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、前記第1サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部とを備える。
実施形態のクラウドシステムは、少なくとも1つのサービスプロセスが動作する複数のサーバ装置と、クラウドシステム管理装置とを備えるクラウドシステムであって、前記クラウド管理装置は、クラウドシステム内のサーバ装置で動作するサービスプロセスが保証する品質を表す品質情報に基づいて、前記サービスプロセスが前記品質を達成できない程度を表す違約情報を見積もる見積部と、前記サーバ装置の故障を検出する検出部と、前記故障が検出された前記サーバ装置で動作する少なくとも1つの第1サービスプロセスを再配置するときに、前記再配置先のサーバ装置で動作する少なくとも1つの第2サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、前記第1サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部とを備える。
実施形態の再配置方法は、見積部が、クラウドシステム内のサーバ装置で動作するサービスプロセスが保証する品質を表す品質情報に基づいて、前記サービスプロセスが前記品質を達成できない程度を表す違約情報を見積もるステップと、検出部が、前記サーバ装置の故障を検出するステップと、決定部が、前記故障が検出された前記サーバ装置で動作する少なくとも1つの第1サービスプロセスを再配置するときに、前記再配置先のサーバ装置で動作する少なくとも1つの第2サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定するステップと、再配置部が、前記第1サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置するステップとを含む。
実施形態のプログラムは、コンピュータを、クラウドシステム内のサーバ装置で動作するサービスプロセスが保証する品質を表す品質情報に基づいて、前記サービスプロセスが前記品質を達成できない程度を表す違約情報を見積もる見積部と、前記サーバ装置の故障を検出する検出部と、前記故障が検出された前記サーバ装置で動作する少なくとも1つの第1サービスプロセスを再配置するときに、前記再配置先のサーバ装置で動作する少なくとも1つの第2サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、前記第1サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部として機能させる。
一般に、クラウドサービスに要求される可用性、及び性能は、SLA(Service Level Agreement)で定められている。SLAは、サービスを提供する事業者がサービスの提供品質をお客様に約束するものである。SLAにより、可用性や、平均応答時間等の性能等が保証される。なお、性能の保証についても可用性の場合と同様に、クラウドサービスの種類によって、その保証品質はさまざまである。
SLAは、その保証の程度によって二つに大別することができる。ギャランティ型とベストエフォート型である。ギャランティ型は、要求された品質を約束する。ベストエフォート型は、品質の向上に最大の努力をすることを約束する。一般に、性能にギャランティ型の保証を必要とするサービスは、可用性においてもギャランティ型の保証を必要とする場合が多いと考えられる。
ギャランティ型のサービスを提供するためは、最悪ケースを想定して余裕を持ってコンピュータ資源を割り当てておく必要があるため、コンピュータ資源の総合的な利用率が下がる傾向がある。一方、ベストエフォート型のサービスは、物理的なコンピュータ資源の総量を超えてコンピュータ資源を割り当てるオーバーコミットを行うことにより、コンピュータ資源の総合的な利用率を上げることが可能である。
以下、実施形態のクラウドシステム管理装置、クラウドシステム、及びプログラムについて説明する。図1は、実施形態のクラウドシステム100の構成の一例を示す図である。本実施形態のクラウドシステム100は、クラウドシステム管理装置10、サーバ装置31a~31n、及びサーバ装置32a~32nを備える。サーバ装置31a~31nは、クラウドシステム100の運用開始時点では、第1クラスタ33に使用されているものとする。また、サーバ装置32a~32nは、クラウドシステム100の運用開始時点では、第2クラスタ34に使用されているものとする。第1クラスタ33、及び第2クラスタ34の詳細については後述する。
なお、サーバ装置31a~31nを区別しない場合は、サーバ装置31という。また、サーバ装置32a~32nを区別しない場合は、サーバ装置32という。サーバ装置31、及びサーバ装置32は、任意の台数でよい。また、クラウドシステム100は、クラウドサービス事業者が営利目的でクラウドサービスを提供するものであっても、プライベートクラウドシステムでもよい。
クラウドシステム管理装置10、サーバ装置31a~31n、及びサーバ装置32a~32nは、LAN(Local Area Network)20を介して互いに接続されている。また、クラウドシステム管理装置10、サーバ装置31a~31n、及びサーバ装置32a~32nは、LAN20、及びネットワーク40を介して、クライアント装置51a~51nに接続されている。なお、クライアント装置51a~51nを区別しない場合は、クライアント装置51という。
クライアント装置51は、ユーザがクラウドシステム100のサービスを受けるために使用する装置である。クライアント装置51は任意の装置でよい。例えば、クライアント装置51は、PC(Personal Computer)や、携帯端末等である。
また、ネットワーク40は、例えば、インターネットである。また、クラウドシステム管理装置10、サーバ装置31a~31n、及びサーバ装置32a~32nの一部が、他の拠点にある等の場合は、LAN20は、インターネットやVPN(Virtual Private Network)等でもよい。
クラウドシステム管理装置10は、検出部1、記憶部2、見積部3、決定部4、及び再配置部5を備える。検出部1は、サーバ装置31a~31n、及びサーバ装置32a~32nの故障を検出する。
記憶部2は、状況データ6、及び見積データ7を記憶する。図2は、実施形態のクラウドシステム管理装置10の品質達成状況データの一例を示す図である。状況データ6は、サービスプロセス名、品質情報、累積動作不能時間、及び違約情報を含む。サービスプロセス名は、サーバ装置31(32)で動作するサービスプロセスの名称である。品質情報は、サービスプロセスが保証する品質である。品質情報は、例えば、SLAにより定められる。当該品質は、サービスプロセスに適用される可用性や、性能等である。当該性能は、サービスプロセスの平均応答時間等である。累積動作不能時間は、サービスプロセスが動作不能になった時間の総和である。違約情報は、品質情報が達成できない程度を表す情報である。図2の例では、違約情報は違約金である。違約金は、例えば、品質情報で許される動作不能時間を越えた時間(以下「違約時間」という。)に、時間単価を乗じた分の料金で生成する。
図2の具体例について説明する。サービスプロセスAの品質情報は、サービスプロセスAの累積動作不能時間が、1年間で52分以内であることを示す。すなわち、見積部3は、累積動作不能時間が52分を超えると違約情報を生成する。なお、サービスプロセスAの累積動作不能時間は0分である。そのため、見積部3は、まだ違約情報を生成しない。
サービスプロセスBの品質情報は、サービスプロセスBの累積動作不能時間が、1年間で30分以内であることを示す。すなわち、見積部3は、累積動作不能時間が30分を超えると違約情報を生成する。なお、サービスプロセスBの累積動作不能時間は29分である。そのため、見積部3は、まだ違約情報を生成しない。しかしながら、違約金が発生するまで、サービスプロセスBを動作不能にできる時間は、あと1分である。
サービスプロセスNの品質情報は、サービスプロセスNの累積動作不能時間が、1年間で40分以内であることを示す。すなわち、見積部3は、累積動作不能時間が40分を超えると違約情報を生成する。なお、サービスプロセスNの累積動作不能時間は42分である。そのため、見積部3は、違約時間(2分)に、違約時間の時間単価を乗じてXXX円の違約情報(違約金)を生成している。
このように、クラウドシステム管理装置10は、品質情報(例えばSLA)の達成状況を、状況データ6として定量化する。品質情報の達成状況の定量化は、サービスプロセス毎にする。サービスプロセス毎の達成状況は、サービスプロセス毎に随時、記憶部2に記録される。
なお、違約情報の生成方法は、上述の方法に限られない。また、図2の品質情報は、サービスプロセスの可用性に関して定められているが、当該品質情報は、サービスプロセスの可用性に関するものに限られない。当該品質情報は、サーバ装置のリソースを使用できる割合等に応じて算出される処理時間(平均応答時間)等のサービスプロセスの性能に関する情報であってもよい。
図3は、実施形態のクラウドシステム管理装置10の見積データ7の一例を示す図である。見積データ7は、サービスプロセス名、及び予想違約情報を含む。サービスプロセス名は、サービスプロセスの名称である。予想違約情報は、サービスプロセスの累積動作不能時間に、サービスプロセスを再配置した場合の動作不能時間を加算して見積もられている。予想違約情報は、サービスプロセスを停止させてよいか否かの1つの指標として利用することができる。なお、予想違約情報の算出方法は、サービスプロセスの品質情報にあわせて任意に定めてよい。
図1に戻り、見積部3は、サービスプロセスが保証する品質を表す品質情報に基づいて、サービスプロセスが、当該品質を達成できない程度を表す違約情報を見積もる。決定部4は、サーバ装置31の故障等の理由によりサービスプロセスの再配置が必要になった場合に、再配置先となるサーバ装置を、再配置先のサーバ装置で動作する少なくとも1つのサービスプロセスの違約情報の総和が最小になるようにして決定する。
再配置部5は、開始部8、及び停止部9を備える。再配置部5は、停止部9によりサービスプロセスを停止し、開始部8によりサービスプロセスを開始することにより、サービスプロセスを再配置する。一例として、サービスプロセスAを、サーバ装置31aからサーバ装置32aに再配置する場合について説明する。まず、停止部9は、サーバ装置31aのサービスプロセスAを停止する。次に、開始部8は、サーバ装置32aでサービスプロセスAを開始する。これにより、再配置部5は、サービスプロセスAを、サーバ装置31aからサーバ装置32aに移す(再配置する)。このとき、停止から開始までの間に経過した時間が、累積動作不能時間に加算されて記憶部2に記録される。なお、サーバ装置31aの故障に伴う再配置の場合は、停止部9はサービスプロセスAの停止を実際には行わないが、停止に要した時間のかわりに、サーバ装置31aの故障検出に要した時間(たとえば、ハートビートのタイムアウト時間)を、累積動作不能時間に加算する。
図4は、実施形態のクラウドシステム100の第1クラスタ33の一例を説明するための図である。第1クラスタ33では、性能、又は可用性等が、品質情報で保証されるサービスプロセス(以下「第1サービスプロセス」という。)が動作する。
第1クラスタ33は、クラウドシステム100を構成する複数のサーバ装置31を論理的にひとまとめにした単位である。サーバ装置31で動作する少なくとも1つのサービスプロセスは、クラウドシステム管理装置10により固定的に配置される。すなわち、サーバ装置31で動作する少なくとも1つのサービスプロセスは、所定の性能用件等の品質情報を必ず保証するようにして決定されたシステム設計に基づいたハードウェア、及びソフトウェア構成で動作する。
第1クラスタ33に含まれるサーバ装置31が故障によって停止した場合、最初にホットスワップを行う。本実施形態のホットスワップは、第2クラスタ34のサーバ装置32の資源を開放して当該サーバ装置32を未使用の状態にし、当該未使用のサーバ装置32を第1クラスタ33の故障サーバ装置31と入れ替える。
ホットスワップ対象のサーバ装置32は、決定部4により決定される。決定部4は、第2クラスタ32内でホットスワップの対象となるサーバ装置32を、以下の2つの条件を満たすようにして決定する。第1の条件は、サーバ装置32を故障したサーバ装置31と入れ替えても、十分な性能を発揮できるようなコンピュータ資源を備えていることである。第2の条件は、サーバ装置32を停止させた結果、サーバ装置32で動作していたサービスプロセスで発生する違約情報が、最も小さいことである。
このホットスワップによって、あたかも故障したサーバ装置31が復旧し、代わりに第2クラスタ34内のサーバ装置32が故障したかのようにみなすことができる。つまり、ホットスワップ後、第1クラスタ33では、元の配置と全く同じ配置でサービスプロセスが再開する。また、第2クラスタ34では、サーバ装置32が故障によって停止した場合と同様にして、サーバ装置32で動作していたサービスプロセスの再配置を行う。
図4の例では、サーバ装置31aでは、サービスプロセスA、及びサービスプロセスBが動作している。サービスプロセスA、及びサービスプロセスBを、同じホストで動作させることにより、サービスプロセスA、及びサービスプロセスBとの間の通信速度を向上させている。これにより、クラウドシステム100は、サービスプロセスA、及びサービスプロセスBの性能を保証している。また、サービスプロセスCは、サーバ装置31bで単独で動作している。そのため、サービスプロセスCは、サーバ装置31bのCPU(Central Processing Unit)、メモリ、及び通信I/F等のリソースを占有することができる。これにより、クラウドシステム100は、サービスプロセスCの性能を保証している。
図5は、実施形態のクラウドシステム100の第2クラスタ34の一例を説明するための図である。第2クラスタ34では、性能、又は可用性等が、品質情報で保証されないサービスプロセス(以下「第2サービスプロセス」という。)が動作する。第2サービスプロセスは、性能、又は可用性等が、可能な限り最大に発揮できるような環境で動作する。そのため、第2クラスタ34のサーバ装置32では、積極的にオーバーコミットを行い、コンピュータ資源の利用率を高めてもよい。すなわち、サーバ装置32では、物理リソースよりも多い論理リソースを割り当ててもよい。
第2クラスタ34は、クラウドシステム100を構成する複数のサーバ装置32を、論理的にひとまとめにした単位である。サーバ装置32で動作する少なくとも1つのサービスプロセスは、クラウドシステム管理装置10により動的に配置される。クラウドシステム管理装置10は、特定のアルゴリズムによって、動的にサービスプロセスを配置する。当該アルゴリズムは、サービスプロセスが使用するサーバ装置32のリソース、負荷、及び余剰資源、並びに、サービスプロセスの品質情報(例えばSLA)、当該サービスプロセスが提供するサービスのコスト(価格等)、サービスプロセスの配置状況等の情報に基づいて決定される。クラウドシステム管理装置10は、第2クラスタに含まれるサーバ装置32が故障した場合、そのサーバ装置32で動作していたサービスプロセスを、第2クラスタ34の他のサーバ装置32に再配置する。
例えば、サービスプロセスAが、第2サービスプロセスであるとする。そして、サービスプロセスAが動作していたサーバ装置32が故障したと仮定する。サーバ装置32aでは、サービスプロセスBが動作している。サーバ装置32bでは、サービスプロセスC、及びサービスプロセスDが動作している。サーバ装置32cでは、サービスプロセスE、及びサービスプロセスFが動作している。このとき、再配置部5は、サービスプロセスAを、その他のサービスプロセスの性能、又は可用性等への影響ができる限り少なくなるようにして再配置する。また、再配置部5は、サービスプロセスA自身の性能、又は可用性等が、可能な限り最大に発揮できるように再配置する。図5の例では、サービスプロセスAの再配置先に、サービスプロセスBのみが起動しているサーバ装置32aが選択されている。すなわち、この例の決定部4は、第2サービスプロセスが均等にサーバ装置32に配置されるように、サービスプロセスAの再配置先を決定している。なお、図5では、サービスプロセスをサービスプロセスA~Fとして区別して説明しているが、ここでのサービスプロセスA~Cは、図4のサービスプロセスA~Cとは関係しない。以下、図6、及び8~11においても同様である。
図6は、実施形態のクラウドシステム100の第2クラスタのサービスプロセスの再配置方法の一例を説明するための図である。図6の例では、サーバ装置32aでは、サービスプロセスA、及びサービスプロセスBが動作している。サーバ装置32bは、故障したことを示す。なお、サーバ装置32bでは、サービスプロセスC、及びサービスプロセスDが動作していたものとする。サーバ装置32cは、サービスプロセスE、及びサービスプロセスFが動作している。
図6の例では、再配置部5は、サーバ装置32bで動作していたサービスプロセスCを、サーバ装置32cに再配置する。また、再配置部5は、サーバ装置32bで動作していたサービスプロセスDを、サーバ装置32aに再配置する。すなわち、図6の例では、再配置部5は、サーバ装置32bで動作していたサービスプロセスを、他のサーバ装置32に均等に再配置している。これにより、第2クラスタで動作するサービスプロセスの性能、又は可用性等が、可能な限り最大に発揮できるようにしている。
次に、実施形態のクラウドシステム管理装置10の第1クラスタ33のサービスプロセスの再配置方法について説明する。図7は、実施形態のクラウドシステム管理装置10の第1クラスタ33のサービスプロセスの再配置方法の一例を説明するためのフローチャートである。また、図8~10は、実施形態のクラウドシステム100の第1クラスタ33のサービスプロセスの再配置方法の一例を説明するための図である。
まず、検出部1が、第1クラスタ33内のサーバ装置31の故障を検出する(ステップS1)。図8の場合を例にして説明する。図8の例では、第1クラスタ33は、サーバ装置31a、及びサーバ装置31bを備える。また、第2クラスタ34は、サーバ装置32a、サーバ装置32b、及びサーバ装置32cを備える。
図8の例では、サーバ装置31aでは、サービスプロセスA、及びサービスプロセスBが動作している。サーバ装置31bは、故障したことを示す。検出部1は、サーバ装置31bの故障を検出する。なお、サーバ装置31bでは、サービスプロセスC、及びサービスプロセスDが動作していたものとする。また、サーバ装置32aでは、サービスプロセスGが動作している。サーバ装置32bでは、サービスプロセスH、及びサービスプロセスEが動作している。サーバ装置32cでは、サービスプロセスJ、及びサービスプロセスKが動作している。
図7に戻り、決定部4が、故障が検出されたサーバ装置31と、ホットスワップするサーバ装置32(再配置先のサーバ装置32)を決定する(ステップS2)。図9の場合を例にして説明する。図9の例は、決定部4が、サーバ装置31bのサービスプロセスの再配置先のサーバ装置32を、サーバ装置32bに決定した場合の例である。なお、決定部4による再配置先のサーバ装置32の決定方法(ステップS2)の詳細は後述する。
クラウドシステム100は、ホットスワップの対象となった第1クラスタ33のサーバ装置31を、ホットスワップ後、第2クラスタ34のサーバ装置32として認識する。また、クラウドシステム100は、ホットスワップの対象となった第2クラスタ34のサーバ装置32を、ホットスワップ後、第1クラスタ33のサーバ装置31として認識する。図10は、クラスタシステム100が、再配置先のサーバ装置32bを、第1クラスタとして利用することを示している。また、クラスタシステム100が、故障したサーバ装置31bを、第2クラスタとして認識することを示している。なお、故障したサーバ装置31bは、軽微な故障である等の理由で復旧可能であれば、復旧後に第2クラスタで利用される。
図7に戻り、再配置部5は、再配置先のサーバ装置32のサービスプロセス(第2サービスプロセス)を停止する(ステップS3)。再配置部5は、再配置されたサービスプロセス(第1サービスプロセス、及び第2サービスプロセス)を開始する(ステップS4)。図11の場合を例にして説明する。図11の例では、再配置部5が、再配置が必要になった第1サービスプロセス(サービスプロセスC、及びサービスプロセスD)を、決定部4により決定されたサーバ装置32bに移している。また、再配置部5が、再配置先のサーバ装置32bで動作していた第2サービスプロセス(サービスプロセスH)を、サーバ装置32aに移している。また、再配置部5が、再配置先のサーバ装置32bで動作していた第2サービスプロセス(サービスプロセスE)を、サーバ装置32cに移している。
図11の例では、再配置が必要になった第1サービスプロセス(サービスプロセスC、及びサービスプロセスD)が動作していたサーバ装置31bが、第2クラスタが使用していたサーバ装置32bにホットスワップされている。これにより、クラウドシステム管理装置10は、第1クラスタの第1サービスプロセスの品質(可用性、又は性能等)を保ちながら、第1サービスプロセスを再配置することができる。
なお、本実施形態のクラウドシステム100は、品質を必ず保証することが品質情報で定められている第1サービスプロセスが動作するサーバ装置31で構成される第1クラスタと、品質を必ず保証することが品質情報で定められていない第2サービスプロセスが動作するサーバ装置32で構成される第2クラスタを含んでいる。しかしながら、クラウドシステム100は、このような区別をせずにクラスタを1つにしてもよい。この場合は、クラウドシステム管理装置10は、各サーバ装置31(32)で動作するサービスプロセスの品質情報に応じて、クラスタの種類によらずにサーバ装置31(32)単位で個別に判定してサービスプロセスを再配置する。
また、逆に、クラスタシステム100は、より詳細にクラスタを区別してもよい。例えば、第2サービスプロセスが動作する第2クラスタ34を、サービスプロセスが保証する品質を表す品質情報に応じて、第2クラスタ34と第3クラスタに分けてもよい。すなわち、クラウドシステム管理装置10に、サービスプロセスに要求される品質を、閾値等により定量的に判定する機能を追加する。そして、クラウドシステム管理装置10は、当該閾値が所定の値以上のサービスプロセスは、第2クラスタ34のサーバ装置32に割り当てる。また、クラウドシステム管理装置10は、当該閾値が所定の値より小さいサービスプロセスは、第3クラスタのサーバ装置に割り当てる。当該機能は、例えば、見積部3に追加してもよい。また、クラウドシステム管理装置10は、第3クラスタのリソースのオーバーコミット率(割り当て済み論理リソース/物理リソース)の上限を、第2クラスタのリソースのオーバーコミット率の上限よりも大きくしてもよい。また、クラウドシステム管理装置10は、第2クラスタの利用料金を、第3クラスタの利用料金よりも高くしてもよい。決定部4が、ホットスワップの対象として、どちらのクラスタを選ぶかは、その時点でのオーバーコミット率が、オーバーコミット率の上限にどの程度到達しているかを比較することによって、決定してもよい。
また、再配置部5は、再配置先のサーバ装置31(32)で動作しているサービスプロセスを、他のサーバ装置31(32)に移さなくてもよい。このような場合としては、例えば、品質情報が、サービスプロセスの処理時間等である場合がある。違約情報は、当該処理時間に応じて決定される。再配置先のサーバ装置31(32)にリソースに余裕がある場合は、再配置先のサーバ装置31(32)に、サービスプロセスが追加されても、違約情報を生成する必要がない。このような場合は、再配置部5は、再配置先のサーバ装置31(32)で動作しているサービスプロセスを、他のサーバ装置31(32)に移さなくてもよい。
図12は、実施形態のクラウドシステム管理装置10の第1クラスタ33のサービスプロセスを再配置先するサーバ装置32を決定する方法の一例を説明するためのフローチャートである。
見積部3は、第2クラスタ34内のサーバ装置32から、サーバ装置hを1つ選択する(ステップS11)。見積部3は、サーバ装置hのサービスプロセスSを1つ選択する(ステップS12)。見積部3は、サービスプロセスSを再配置した場合の違約情報を見積もる(ステップS13)。見積部3は、サーバ装置hのサービスプロセスSを全て選択したか否かを判定する(ステップS14)。サーバ装置hのサービスプロセスSを全て選択した場合は、見積部3は、当該見積もりの合計Ghを算出する(ステップS15)。サーバ装置hのサービスプロセスSを全て選択していない場合は、ステップS12に戻る。見積部3は、第2クラスタ34内のサーバ装置32を全て選択したか否かを判定する(ステップS16)。第2クラスタ34内のサーバ装置32を全て選択した場合は、決定部4は、合計Ghが最小となるサーバ装置hを選択する(ステップS17)。なお、ステップS17において、決定部4は、必ずしも合計Ghが最小となるサーバ装置hを選択しなくてもよい。例えば、決定部4は、他の指標も鑑みて、合計Ghが小さいサーバ装置hを優先するに留めてもよい。第2クラスタ34内のサーバ装置32を全て選択していない場合は、ステップS11に戻る。
次に、違約情報の見積方法の一例について説明する。サービスプロセス毎の違約情報の見積もりは、例えば、過去1年間の動作不能時間に、再配置にかかる予想処理時間を加えた値、及び品質情報(例えば、SLA)に基づいて計算することができる。ここで、再配置にかかる予想処理時間は、過去の実績値の平均により見積もる。具体的には、再配置にかかる処理時間の過去の実績値の平均は、サービスプロセス毎に記憶部2に記録されている動作不能時間を、再配置回数で割ることによって得ることができる。なお、過去に一度も再配置が行われていない場合には、再配置の実績値は無いので、事前に評価しておいた結果等を使ってもよい。または、再配置対象のサービスプロセスと同様の他のサービスの実績値を使ってもよい。
なお、再配置後の違約情報の見積もりが最小となるサーバ装置32(ホットスワップ対象のサーバ装置32)が複数あった場合(例えば、違約情報が0で並ぶ等)は、その中から最適な対象サーバ装置32を選択するために、再配置後にサーバ装置32が更に故障した場合の違約情報の期待値も見積もる。このようにしてサーバ装置32を選べば、再配置後の違約情報が最小となるだけでなく、再配置後にサーバ装置32が、更に故障した場合が考慮された違約情報の期待値も最小となるようにして、サーバ装置32を選ぶことができる。
以下では、違約情報の見積もりが最小のサーバ装置32(再配置先のサーバ装置32の候補)が複数あった場合に、更に違約情報の期待値を見積もる方法の一例について説明する。
第2クラスタ34内のサーバ装置32の総数をNとし、各サーバ装置32には1からNの番号が振られているとする。各サーバ装置hk(1≦k≦N)が、再配置先のサーバ装置32に選ばれた後、第2クラスタ34内のサーバ装置32が故障した場合の違約情報の期待値を算出する。
なお、以下の説明では、各サーバ装置hk(1≦k≦N)が、故障する確率は、同一であると仮定する。また、各サーバ装置hk(1≦k≦N)が故障する確率は、十分に小さいと考えることができるとして、同時に複数台のサーバ装置hkが故障する場合の違約情報の期待値を0とみなす。すなわち、二点故障の確率は相当小さいので、一点故障までの違約情報の期待値が、違約情報の期待値の主要部であるとみなす。決定部4は、当該主要部が最小であるサーバ装置hkを再配置先に決定する。
まず、使用する記号について説明する。sを第2クラスタ34のサーバ装置32で動作しているサービスプロセスとする。g(n,s)を、サービスプロセスsを見積もり基準時からn回再配置したときの違約情報の見積もり値とする。具体的には、例えば、過去1年間の動作不能時間に、n回分の再配置の予想処理時間を加えた値から、品質情報で約束された値(例えば52分)を引いて違約時間を見積もる。次に、この違約時間に応じた違約情報(例えば違約金)を算出し、当該違約情報をg(n,s)とする。なお、g(0,s)は、サービスプロセスsの見積もり基準時の違約情報であることを示す。
n回再配置したときの違約情報の増加分G(n,s)を、次式(1)により定義する。
ここでは、計算を簡易的に行うため、サーバ装置hkは全て同一機種であるとする。すなわち、G(n,s)は、サービスプロセスが配置されるサーバ装置hkに関係なく見積もれるものとする。
サーバ装置hkのサービスプロセスsを、他のサーバ装置32に移した後(1回再配置した後)の全てのサービスプロセスsの違約情報は、次式(2)で表すことができる。
ここでHkは、サーバ装置hkで動いていたサービスプロセスの集合である。なお、式(2)の第1項は、サーバ装置hkで動作していたサービスプロセスsの違約情報の総和を示す。また、式(2)の第2項は、サーバ装置hk以外のサーバ装置32で動作しているサービスプロセスsの違約情報の総和を示す。式(2)は、以下のようにして式(3)に変形することができる。
つまり、サーバ装置hkのサービスプロセスsを、他のサーバ装置32に移した後の全てのサーバ装置32のサービスプロセスsの違約情報は、見積もり基準時の違約情報(第1項)と、サーバ装置hk上のサービスプロセスsを1回再配置することによる違約情報の増加分(第2項)の和である。式(3)のkに依存する項は、第2項のみであることがわかる。
再配置後の違約情報の見積もりが最小となるサーバ装置32が複数ある場合(例えば、違約情報が0で並ぶ等)は、式(3)の第2項が最小(同一)となるサーバ装置hkが複数あることを示す。したがって、更に違約情報の見積もりの期待値を算出する場合は、次式(4)が同一であると仮定してよい。
各サーバ装置hk(1≦k≦N)について、サーバ装置hkが再配置先のサーバ装置32に選ばれた後、第2クラスタ34内のサーバ装置32が故障した場合の違約情報の期待値を算出する。当該違約情報の期待値は、サーバ装置hi(1≦i≦N)のいずれか1台の故障により発生するサービスプロセスsの違約金の増加分の期待値を、式(1)に加算した次式(5)により算出できる。
ここで、pはサーバ装置hiの故障確率とする(サーバ装置hiの故障確率を全て同一であると仮定している。)。/Hi(ただし、“/”は上線であることを示す。)は、再配置後(ホットスワップを一回した後)にサーバ装置hiで動いていたサービスプロセスの集合である。/G(s)(ただし、“/”は上線であることを示す。)は、サービスsの違約情報の増加分である。
/G(s)は、次式(6)で表すことができる。
式(5)は、次のようにして式(7)に変形することができる。
式(7)の第3項(式(4))は、違約情報の期待値の評価対象となっているサーバ装置hkの間で同じである。したがって、kに依存する項は、式(7)の第1項のみである。すなわち、決定部4は、次式(8)により算出された値が、最小となるサーバ装置hkを決定すればよい。
式(8)は、故障確率pや、各サービスプロセスsの再配置先のサーバ装置32に関係なく、値が確定できるため、実際に計算可能である。上記の計算を踏まえると、再配置後に2回(2台)以上サーバ装置hkが故障する場合にも、次式(9)を、違約情報の期待値の見積もりの値の評価に利用できることがわかる。
すなわち、式(8)が同一の値となる場合(例えば、0で並ぶ場合)は、式(9)でn=3として、更にもう1回、見積もり基準時のサーバ装置hk(1≦k≦N)で動作していたサービスプロセスsが再配置の対象となった場合を評価する。見積部3は、このようにして、nの値を増やして式(9)を評価することにより、違約情報の期待値を見積もる。決定部4は、当該違約情報の期待値により、ホットスワップの対象となるサーバ装置hkを決定する。
本実施形態のクラウドシステム管理装置10によれば、クラウドシステム100内のサーバ装置31(32)が故障したとき、見積部3、決定部4、及び再配置部5により、サービスプロセスが保証する品質に応じて、使用できるサーバ装置31(32)を、サービスプロセスに効率的に割り当てることができる。
また、本実施形態のクラウドシステム管理装置10によれば、品質の要求レベルの異なる品質情報(例えばSLA)を有するサービスプロセスを、クラウドシステム100により効率的に運用することができる。
(その他の実施形態)
その他の実施形態のクラウドシステム管理装置10、及びクラウドシステム100について説明する。上述の実施形態のクラウドシステム100は、サーバ装置31(32)は、全て使用されていた。その他の実施形態のクラウドシステム100として、余剰リソースとして予備サーバ装置がある場合について説明する。
その他の実施形態のクラウドシステム管理装置10、及びクラウドシステム100について説明する。上述の実施形態のクラウドシステム100は、サーバ装置31(32)は、全て使用されていた。その他の実施形態のクラウドシステム100として、余剰リソースとして予備サーバ装置がある場合について説明する。
予備サーバ装置は、第2クラスタ34のサーバ装置として利用される。ただし、予備サーバ装置で動作するサービスプロセス(以下「予備サービスプロセス」という。)が保証する品質は、第2クラスタ34のサーバ装置32よりも更に低いものとする。例えば、予備サービスプロセスは、サーバ装置31(32)で故障が発生したら、すぐに停止しても差し支えのないサービスプロセスである。したがって、決定部4が、予備サーバ装置31を、ホットスワップの対象に決定しても、予備サービスプロセスは、他のサーバ装置31(32)や、他の予備サーバ装置に移さなくてもよい。決定部4は、第1クラスタのサーバ装置31が故障した際には、まず、予備サーバ装置を、ホットスワップの対象に決定する。
本実施形態のクラウドシステム管理装置10、及びクラウドシステム100は、クラウドシステム100のリソースに余裕がある場合でも、サービスプロセスが保証する品質に応じて、クラウドシステム100のリソースを効率的に割り当てることができる。
次に、実施形態のクラウドシステム100のクラウドシステム管理装置10、及びサーバ装置31(32)のハードウェアの構成の一例について説明する。図13は、実施形態のクラウドシステムのクラウドシステム管理装置、及びサーバ装置のハードウェアの構成の一例を示す図である。以下では、クラウドシステム管理装置10の場合を例にして説明する。
本実施形態のクラウドシステム管理装置10は、制御部61、主記憶部62、補助記憶部63、表示部64、入力部65、及び通信I/F部66を備える。制御部61、主記憶部62、補助記憶部63、表示部64、入力部65、及び通信I/F部66は、バス67を介して互いに接続されている。
制御部61は、補助記憶部63から主記憶部62に読み出されたプログラムを実行する。主記憶部63は、ROM(Read Only Memory)やRAM(Random Access Memory)等のメモリである。補助記憶部63は、HDD(Hard Disk Drive)や光学ドライブ等である。表示部64は、クラウドシステム管理装置10の状態等を表示する画面である。表示部6は、例えば液晶ディスプレイである。入力部65は、クラウドシステム管理装置10を操作するためのインタフェースである。入力部65は、例えばキーボードやマウス等である。通信I/F部66は、ネットワークに接続するためのインタフェースである。
本実施形態のクラウドシステム管理装置10で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでCD-ROM、フレキシブルディスク(FD)、CD-R、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録されてコンピュータ・プログラム・プロダクトとして提供される。
また、本実施形態のクラウドシステム管理装置10で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施形態のクラウドシステム管理装置10で実行されるプログラムをインターネット等のネットワーク経由で提供、又は配布するように構成してもよい。
また、本実施の形態のクラウドシステム管理装置10のプログラムを、ROM等に予め組み込んで提供するように構成してもよい。
本実施形態のクラウドシステム管理装置10で実行されるプログラムは、上述した各機能ブロック(検出部1、見積部3、決定部4、及び再配置部5)を含むモジュール構成となっている。当該各機能ブロックは、実際のハードウェアとしては、制御部61が上記補助記憶部63等からプログラムを読み出して実行することにより、上記各機能ブロックが主記憶部62上にロードされる。すなわち、上記各機能ブロックは、主記憶部62上に生成される。
なお、上述した各部(検出部1、見積部3、決定部4、及び再配置部5)の一部、又は全部を、ソフトウェアにより実現せずに、IC等のハードウェアにより実現してもよい。また、記憶部2は、例えば、補助記憶部63である。なお、補助記憶部63により実現する記憶部2のデータを、主記憶部62に展開してもよい。
以上説明したとおり、実施形態のクラウドシステム管理装置10によれば、クラウドシステム100内のサーバ装置31(32)が故障したとき、見積部3、決定部4、及び再配置部5により、サービスプロセスが保証する品質に応じて、使用できるサーバ装置31(32)を、サービスプロセスに効率的に割り当てることができる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、請求の範囲に記載された発明とその均等の範囲に含まれる。
1 検出部
2 記憶部
3 見積部
4 決定部
5 再配置部
6 状況データ
7 見積データ
8 開始部
9 停止部
10 クラウドシステム管理装置
20 LAN
31a~31n,31 サーバ装置
32a~32n,32 サーバ装置
33 第1クラスタ
34 第2クラスタ
40 ネットワーク
51a~51n,51 クライアント装置
61 制御部
62 主記憶部
63 補助記憶部
64 表示部
65 入力部
66 通信I/F
67 バス
2 記憶部
3 見積部
4 決定部
5 再配置部
6 状況データ
7 見積データ
8 開始部
9 停止部
10 クラウドシステム管理装置
20 LAN
31a~31n,31 サーバ装置
32a~32n,32 サーバ装置
33 第1クラスタ
34 第2クラスタ
40 ネットワーク
51a~51n,51 クライアント装置
61 制御部
62 主記憶部
63 補助記憶部
64 表示部
65 入力部
66 通信I/F
67 バス
Claims (9)
- クラウドシステム内のサーバ装置で動作するサービスプロセスが保証する品質を表す品質情報に基づいて、前記サービスプロセスが前記品質を達成できない程度を表す違約情報を見積もる見積部と、
前記サーバ装置の故障を検出する検出部と、
前記故障が検出された前記サーバ装置で動作する少なくとも1つの第1サービスプロセスを再配置するときに、前記再配置先のサーバ装置で動作する少なくとも1つの第2サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、
前記第1サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部と
を備えるクラウドシステム管理装置。 - 前記再配置部は、
更に、前記第2サービスプロセスを、他の前記サーバ装置に移すことにより再配置する
請求項1に記載のクラウドシステム管理装置。 - 前記クラウドシステムは、
前記品質を必ず保証することが前記品質情報で定められている前記第1サービスプロセスが動作する第1サーバ装置で構成される第1クラスタと、
前記品質を必ず保証することが前記品質情報で定められていない前記第2サービスプロセスが動作する第2サーバ装置で構成される第2クラスタと、
を含み、
前記決定部は、前記第1サーバ装置の故障が検出された場合に、前記第2サーバ装置のうち、再配置する場合の前記サービスプロセスの前記違約情報の総和が小さい前記第2サーバ装置を優先して、前記第1サーバ装置で動作する前記第1サービスプロセスの再配置先となる前記サーバ装置として決定する
請求項2に記載のクラウドシステム管理装置。 - 前記クラウドシステムは、
前記品質を必ず保証することが前記品質情報で定められていない前記第2サービスプロセスが動作する第2サーバ装置で構成される前記第2クラスタを含み、
前記他のサーバ装置は、前記第2サーバ装置である
請求項2に記載のクラウドシステム管理装置。 - 前記見積部は、
前記違約情報を、前記サービスプロセスの累積動作不能時間に、前記サービスプロセスを再配置した場合の動作不能時間を加算することにより見積もる
請求項1乃至4のいずれか1項に記載のクラウドシステム管理装置。 - 前記見積部は、
前記違約情報を、前記第1サービスプロセスを再配置先の前記サーバ装置に移した場合に、前記第1サービスプロセスが前記再配置先のサーバ装置のリソースを使用できる割合に応じて算出される処理時間により見積もる
請求項1乃至5のいずれか1項に記載のクラウドシステム管理装置。 - 少なくとも1つのサービスプロセスが動作する複数のサーバ装置と、
クラウドシステム管理装置と
を備えるクラウドシステムであって、
前記クラウド管理装置は、
クラウドシステム内のサーバ装置で動作するサービスプロセスが保証する品質を表す品質情報に基づいて、前記サービスプロセスが前記品質を達成できない程度を表す違約情報を見積もる見積部と、
前記サーバ装置の故障を検出する検出部と、
前記故障が検出された前記サーバ装置で動作する少なくとも1つの第1サービスプロセスを再配置するときに、前記再配置先のサーバ装置で動作する少なくとも1つの第2サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、
前記第1サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部と
を備えるクラウドシステム。 - 見積部が、クラウドシステム内のサーバ装置で動作するサービスプロセスが保証する品質を表す品質情報に基づいて、前記サービスプロセスが前記品質を達成できない程度を表す違約情報を見積もるステップと、
検出部が、前記サーバ装置の故障を検出するステップと、
決定部が、前記故障が検出された前記サーバ装置で動作する少なくとも1つの第1サービスプロセスを再配置するときに、前記再配置先のサーバ装置で動作する少なくとも1つの第2サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定するステップと、
再配置部が、前記第1サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置するステップと
を含む再配置方法。 - コンピュータを、
クラウドシステム内のサーバ装置で動作するサービスプロセスが保証する品質を表す品質情報に基づいて、前記サービスプロセスが前記品質を達成できない程度を表す違約情報を見積もる見積部と、
前記サーバ装置の故障を検出する検出部と、
前記故障が検出された前記サーバ装置で動作する少なくとも1つの第1サービスプロセスを再配置するときに、前記再配置先のサーバ装置で動作する少なくとも1つの第2サービスプロセスの前記違約情報の総和が小さい前記サーバ装置を優先して前記再配置先のサーバ装置に決定する決定部と、
前記第1サービスプロセスを、前記再配置先のサーバ装置に移すことにより再配置する再配置部と
して機能させるプログラム。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201280077616.8A CN104885059B (zh) | 2012-12-12 | 2012-12-12 | 云系统管理装置、云系统及重新配置方法 |
JP2014551787A JP6072072B2 (ja) | 2012-12-12 | 2012-12-12 | クラウドシステム管理装置、クラウドシステム、再配置方法、及びプログラム |
PCT/JP2012/082215 WO2014091580A1 (ja) | 2012-12-12 | 2012-12-12 | クラウドシステム管理装置、クラウドシステム、再配置方法、及びプログラム |
US14/725,191 US9703653B2 (en) | 2012-12-12 | 2015-05-29 | Cloud system management apparatus, cloud system, reallocation method, and computer program product |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2012/082215 WO2014091580A1 (ja) | 2012-12-12 | 2012-12-12 | クラウドシステム管理装置、クラウドシステム、再配置方法、及びプログラム |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/725,191 Continuation US9703653B2 (en) | 2012-12-12 | 2015-05-29 | Cloud system management apparatus, cloud system, reallocation method, and computer program product |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2014091580A1 true WO2014091580A1 (ja) | 2014-06-19 |
Family
ID=50933903
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2012/082215 WO2014091580A1 (ja) | 2012-12-12 | 2012-12-12 | クラウドシステム管理装置、クラウドシステム、再配置方法、及びプログラム |
Country Status (4)
Country | Link |
---|---|
US (1) | US9703653B2 (ja) |
JP (1) | JP6072072B2 (ja) |
CN (1) | CN104885059B (ja) |
WO (1) | WO2014091580A1 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017016505A (ja) * | 2015-07-03 | 2017-01-19 | 富士通株式会社 | 起動制御プログラム、起動制御方法及び起動制御装置 |
JP2018120354A (ja) * | 2017-01-24 | 2018-08-02 | 富士通株式会社 | 判定プログラム、判定方法および判定装置 |
Families Citing this family (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6319670B1 (en) | 1995-05-09 | 2001-11-20 | Meso Scale Technology Llp | Methods and apparatus for improved luminescence assays using microparticles |
US9864517B2 (en) | 2013-09-17 | 2018-01-09 | Netapp, Inc. | Actively responding to data storage traffic |
CN105988918B (zh) | 2015-02-26 | 2019-03-08 | 阿里巴巴集团控股有限公司 | 预测gpu故障的方法和装置 |
US9720763B2 (en) | 2015-03-09 | 2017-08-01 | Seagate Technology Llc | Proactive cloud orchestration |
CN108780092A (zh) | 2016-03-07 | 2018-11-09 | 豪夫迈·罗氏有限公司 | 抗p53抗体的检测 |
JP6872117B2 (ja) * | 2017-01-26 | 2021-05-19 | 富士フイルムビジネスイノベーション株式会社 | 情報処理装置及びプログラム |
CN110234995A (zh) | 2017-02-02 | 2019-09-13 | 豪夫迈·罗氏有限公司 | 使用至少两种聚乙二醇化的分析物特异性结合试剂的免疫测定 |
CN110069338B (zh) * | 2018-01-24 | 2024-03-19 | 中兴通讯股份有限公司 | 资源控制方法、装置及设备、计算机可读存储介质 |
EP3781600A1 (en) | 2018-04-18 | 2021-02-24 | F. Hoffmann-La Roche AG | Novel anti-thymidine kinase antibodies |
US10733029B2 (en) * | 2018-07-31 | 2020-08-04 | Hewlett Packard Enterprise Development Lp | Movement of services across clusters |
WO2020043868A1 (en) | 2018-08-31 | 2020-03-05 | F. Hoffmann-La Roche Ag | Thymidine kinase (tk-1) in prognostic indices for dlbcl |
WO2021013784A1 (en) | 2019-07-22 | 2021-01-28 | F. Hoffmann-La Roche Ag | S100a8 as blood biomarker for the non-invasive diagnosis of endometriosis |
JP7315780B2 (ja) | 2019-07-22 | 2023-07-26 | エフ. ホフマン-ラ ロシュ アーゲー | 子宮内膜症の非侵襲的診断のための血液バイオマーカーとしてのサブスタンスp |
EP4004555A1 (en) | 2019-07-22 | 2022-06-01 | F. Hoffmann-La Roche AG | S100a6 as blood biomarker for the non-invasive diagnosis of endometriosis |
KR20220016210A (ko) | 2019-07-22 | 2022-02-08 | 에프. 호프만-라 로슈 아게 | 자궁내막증의 비-침습적 진단용 혈액 생물표지자로써 s100a9 |
CN114144671A (zh) | 2019-07-22 | 2022-03-04 | 豪夫迈·罗氏有限公司 | S100a12作为用于子宫内膜异位症的非侵入性诊断的血液生物标志物 |
JP2023502360A (ja) | 2019-11-15 | 2023-01-24 | エフ.ホフマン-ラ ロシュ アーゲー | 患者試料における質量分析測定のためのβ-ラクタム抗生物質の誘導体化 |
WO2022090455A1 (en) | 2020-11-02 | 2022-05-05 | F. Hoffmann-La Roche Ag | Sars-cov-2 nucleocapsid antibodies |
WO2022207628A1 (en) | 2021-03-30 | 2022-10-06 | F. Hoffmann-La Roche Ag | Scf as blood biomarker for the non-invasive diagnosis of endometriosis |
EP4314838A1 (en) | 2021-04-01 | 2024-02-07 | F. Hoffmann-La Roche AG | Psp94 as blood biomarker for the non-invasive diagnosis of endometriosis |
CN117337394A (zh) | 2021-05-17 | 2024-01-02 | 豪夫迈·罗氏有限公司 | sFRP4作为血液生物标志物用于子宫腺肌病的非侵入性诊断 |
WO2023072904A1 (en) | 2021-10-26 | 2023-05-04 | F. Hoffmann-La Roche Ag | Monoclonal antibodies specific for sars-cov-2 rbd |
WO2023131594A1 (en) | 2022-01-05 | 2023-07-13 | F. Hoffmann-La Roche Ag | Derivatization of compounds in patient samples for therapeutic drug monitoring (tdm) |
WO2023247752A1 (en) | 2022-06-23 | 2023-12-28 | F. Hoffmann-La Roche Ag | Method for diagnosing endometriosis and for classifying the stage of endometriosis |
WO2024017985A1 (en) | 2022-07-22 | 2024-01-25 | F. Hoffmann-La Roche Ag | Fibroblast growth factor binding protein 1 (fgfbp1) as (blood) biomarker for the diagnosis of polycystic ovarian syndrome |
WO2024017983A1 (en) | 2022-07-22 | 2024-01-25 | F. Hoffmann-La Roche Ag | Meteorin-like protein (metrnl) as (blood) biomarker for the diagnosis of polycystic ovarian syndrome |
WO2024017982A1 (en) | 2022-07-22 | 2024-01-25 | F. Hoffmann-La Roche Ag | Leukotriene a4 hydrolase (lta4h) as (blood) biomarker for the diagnosis of polycystic ovarian syndrome |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002024192A (ja) * | 2000-07-07 | 2002-01-25 | Hitachi Ltd | 計算機資源分割装置および資源分割方法 |
JP2004259092A (ja) * | 2003-02-27 | 2004-09-16 | Nec Corp | 最適サービスレベル提供者選択システム、サービス仲介ノード及びプログラム |
JP2004538573A (ja) * | 2001-08-03 | 2004-12-24 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ホストされるアプリケーションのためのサーバ・リソース管理 |
JP2007249470A (ja) * | 2006-03-15 | 2007-09-27 | Nec Biglobe Ltd | クラスタサーバシステム、課金装置、課金方法 |
JP2011039740A (ja) * | 2009-08-10 | 2011-02-24 | Ntt Data Corp | サーバ管理システム、サーバ管理方法、及びプログラム |
JP2012108651A (ja) * | 2010-11-16 | 2012-06-07 | Hitachi Ltd | クラスタシステム |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001325117A (ja) * | 2000-05-17 | 2001-11-22 | Nippon Signal Co Ltd:The | 待機2重系情報処理装置およびその系状態確定方法 |
FR2834840B1 (fr) * | 2002-01-14 | 2005-06-24 | Sofedit Sa | Determination de la cause probable d'une diminution de la qualite d'un service en fonction de l'evolution d'un ensemble de services |
JP4363914B2 (ja) | 2003-06-20 | 2009-11-11 | 株式会社東芝 | クラスタシステム |
JP3987517B2 (ja) | 2003-09-02 | 2007-10-10 | 株式会社東芝 | 計算機システム及びクラスタシステム用プログラム |
JP4504329B2 (ja) * | 2006-03-31 | 2010-07-14 | 株式会社東芝 | ストレージシステム、当該ストレージシステムに用いられるストレージ及びアクセス制御方法 |
CN101188509B (zh) * | 2006-11-15 | 2011-10-05 | 富士通株式会社 | 一种为网络服务提供服务质量保证的方法、系统 |
US9021083B2 (en) * | 2008-11-26 | 2015-04-28 | Red Hat, Inc. | Service oriented architecture with dynamic policy enforcement points |
US8190744B2 (en) * | 2009-05-28 | 2012-05-29 | Palo Alto Research Center Incorporated | Data center batch job quality of service control |
US8898307B2 (en) * | 2011-09-22 | 2014-11-25 | Nec Laboratories America, Inc. | Scheduling methods using soft and hard service level considerations |
US9049135B2 (en) * | 2012-10-09 | 2015-06-02 | Ciena Corporation | Network spares audit optimization and maintenance systems and methods |
US9122652B2 (en) * | 2012-12-17 | 2015-09-01 | Lenovo Enterprise Solutions (Singapore) Pte. Ltd. | Cascading failover of blade servers in a data center |
-
2012
- 2012-12-12 WO PCT/JP2012/082215 patent/WO2014091580A1/ja active Application Filing
- 2012-12-12 CN CN201280077616.8A patent/CN104885059B/zh active Active
- 2012-12-12 JP JP2014551787A patent/JP6072072B2/ja active Active
-
2015
- 2015-05-29 US US14/725,191 patent/US9703653B2/en active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002024192A (ja) * | 2000-07-07 | 2002-01-25 | Hitachi Ltd | 計算機資源分割装置および資源分割方法 |
JP2004538573A (ja) * | 2001-08-03 | 2004-12-24 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ホストされるアプリケーションのためのサーバ・リソース管理 |
JP2004259092A (ja) * | 2003-02-27 | 2004-09-16 | Nec Corp | 最適サービスレベル提供者選択システム、サービス仲介ノード及びプログラム |
JP2007249470A (ja) * | 2006-03-15 | 2007-09-27 | Nec Biglobe Ltd | クラスタサーバシステム、課金装置、課金方法 |
JP2011039740A (ja) * | 2009-08-10 | 2011-02-24 | Ntt Data Corp | サーバ管理システム、サーバ管理方法、及びプログラム |
JP2012108651A (ja) * | 2010-11-16 | 2012-06-07 | Hitachi Ltd | クラスタシステム |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017016505A (ja) * | 2015-07-03 | 2017-01-19 | 富士通株式会社 | 起動制御プログラム、起動制御方法及び起動制御装置 |
JP2018120354A (ja) * | 2017-01-24 | 2018-08-02 | 富士通株式会社 | 判定プログラム、判定方法および判定装置 |
Also Published As
Publication number | Publication date |
---|---|
US20150261630A1 (en) | 2015-09-17 |
JP6072072B2 (ja) | 2017-02-01 |
US9703653B2 (en) | 2017-07-11 |
CN104885059B (zh) | 2017-09-08 |
JPWO2014091580A1 (ja) | 2017-01-05 |
CN104885059A (zh) | 2015-09-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6072072B2 (ja) | クラウドシステム管理装置、クラウドシステム、再配置方法、及びプログラム | |
US11050637B2 (en) | Resource lifecycle optimization in disaggregated data centers | |
US20200097358A1 (en) | Resource provisioning and replacement according to a resource failure analysis in disaggregated data centers | |
US9935865B2 (en) | System and method for detecting and preventing service level agreement violation in a virtualized environment | |
RU2605473C2 (ru) | Автоматизированное профилирование использования ресурса | |
US10191771B2 (en) | System and method for resource management | |
US11256595B2 (en) | Predictive storage management system | |
US9277002B2 (en) | Physical resource management | |
US10754720B2 (en) | Health check diagnostics of resources by instantiating workloads in disaggregated data centers | |
CN114218012A (zh) | 用于在集群系统中备份和恢复数据的方法和系统 | |
US10761915B2 (en) | Preemptive deep diagnostics and health checking of resources in disaggregated data centers | |
US9448824B1 (en) | Capacity availability aware auto scaling | |
US11188408B2 (en) | Preemptive resource replacement according to failure pattern analysis in disaggregated data centers | |
US10831580B2 (en) | Diagnostic health checking and replacement of resources in disaggregated data centers | |
JP5998577B2 (ja) | クラスタ監視装置、クラスタ監視方法、及びプログラム | |
US10686721B2 (en) | Storage device access mediation | |
JP6520512B2 (ja) | 情報処理装置、優先度算出プログラムおよびデータセンタシステム | |
US9342372B1 (en) | Dynamic workload capping | |
Gilesh et al. | Opportunistic live migration of virtual machines | |
US20230110786A1 (en) | Regulating cloud budget consumption | |
JP6451497B2 (ja) | 情報処理装置、情報処理プログラム、及びデータセンタシステム | |
JP2010026828A (ja) | 仮想計算機の制御方法 | |
JP2022114776A (ja) | サービス特定方法、及びサービス特定プログラム | |
US10990434B2 (en) | Increasing processing capacity of virtual machines for an abnormal event | |
Paing et al. | High availability solution: Resource usage management in virtualized software aging |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 12890017 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2014551787 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 12890017 Country of ref document: EP Kind code of ref document: A1 |