JP5035299B2 - Multi-core processor control method, computer system thereof, and management computer program - Google Patents

Description

  The present invention relates to a control method for a computer operating on a multi-core processor.

  As a result of the increase in the number of owned servers in corporate computer systems and data centers, operation management costs have also increased. As a technique for solving this problem, there is a high-performance processor. Conventionally, the performance of a processor has been improved by improving the operating frequency of the processor. There are several different directions for user expectations for improved processor performance. One is high performance for faster processing. By processing more complicated processing in a short time, it becomes possible to obtain advanced processing results in a short time. Another is the ease of operation management. By using a processor with high processing performance as a server, more processing can be performed on a single server, and therefore the number of servers to be managed can be reduced. As a result, the number of servers subject to operation management is reduced, and operation management is facilitated. At present, there is a great expectation for improving the performance of a processor for facilitating operation management. Against this background, multi-core processors are becoming the center of processor architecture. A multi-core processor is an architecture in which a plurality of cores capable of performing operations in parallel are built in a single physical processor. It is not a method for improving the operating frequency of a single core as in the prior art, but a method for improving performance by having a large number of cores. There are several advantages of a multi-core processor, but power consumption and overall performance can be improved compared to conventional processors that require a large number of complex logics. Such a multi-core processor is expected as a technology that improves the performance of a single server than before, and as a result, accelerates the ease of operation management.

JP 2006-260568 A JP2004-30363 JP 2003-330740 A

  Multi-core processors can be expected to improve performance and simplify operation management. However, on the other hand, there is a problem that availability decreases. A high availability condition is that the system can continue processing even if a failure occurs in a specific part. A multi-core processor improves performance by incorporating a large number of cores in a single processor, but from the viewpoint of availability, it means that the range affected by a failure of a single processor becomes large. In other words, the multi-core processor reduces the availability at the cost of constructing the system with a small number of processors. For example, when a total 20 GHz system is constructed using a single core processor having one 2 GHz core, 20 processors are required. When a system is constructed on 20 processors, the range affected by a single processor failure is 1/20. On the other hand, a multi-core processor in which four 2 GHz cores are mounted on a single processor can be constructed with five processors to obtain the same performance. However, in this case, the range affected by the failure of a single processor is 4/20 at the maximum, and the multi-core processor has a problem that the influence at the time of failure is greater.

  Another problem is a decrease in availability in virtualization of a server equipped with a multi-core processor. Another method for facilitating operational management is server virtualization technology. The server virtualization technology is a technology capable of operating a plurality of virtual servers on a single physical server. Physical servers have resources such as processors and memory, and server virtualization technology divides resources and assigns them to different virtual servers to execute multiple virtual servers simultaneously on a single physical server . The need for server virtualization technology is increasing due to performance improvements by multi-core processors and the like, as well as lower costs for resources such as memory. Further, the server virtualization technology has an advantage of further effective use of server resources by workload control in addition to the advantage of integration by operating a plurality of virtual servers on a single physical server. Here, the workload control is a process of increasing / decreasing resources such as the CPU and memory of the physical server to the virtual server according to the situation. For example, when the load on a certain virtual server becomes high, the resources of the physical server can be used effectively by combining resources from the virtual server with the lower load among other virtual servers running on the same physical server. Will be able to.

  A multi-core processor can have a large number of processor resources in a server virtualization environment, thereby having the ability to generate a large number of virtual servers from a single processor. That is, a large number of servers can be integrated into a smaller number of servers. Thus, it can be expected that the operation management will be facilitated by the synergistic effect of the multi-core processor and the virtualization technology. In fact, the reliability of the system can be improved by combining the virtualization technology and a plurality of processors. For example, by constructing a primary and secondary hot standby environment using multiple virtual servers created on a physical server, a highly reliable environment that conventionally required multiple physical servers can be constructed with a single physical server. There is technology. In the prior art, there are a technique for constructing a hot standby among a plurality of virtual servers, a technique for constructing a new virtual server by detecting a failure sign, and preparing for a failure. However, these technologies are not technologies targeting multi-core processors, but are high-reliability technologies using virtual servers in a single-core processor environment. In addition, it does not consider the size of the influence range of the failure, and is not a technology corresponding to a multi-core processor. Therefore, it is a challenge to improve the reliability and availability of virtual servers in a multi-core processor environment.

  A system including a plurality of multi-core processors has a table for managing processors and cores included in the processors, and a single virtual server is configured using cores of different processors when a virtual server is generated.

  Further, the number of processors is made variable in accordance with the number of cores that the processor has. In addition, when a processor failure sign is detected, control is performed so that the execution schedule of the virtualization mechanism is not passed to the processor that has detected the failure sign.

  Further, in a system composed of a plurality of multi-core processors, operation cores possessed by a plurality of different processors are assigned to processing of an operating system process or thread.

  In a system composed of a plurality of multi-core processors, operation cores of a plurality of different processors are allocated to the operating system.

  In a multi-core processor environment, availability can be improved.

1 shows an overall configuration diagram of the present invention. FIG. The block diagram of a processor is shown. The block diagram of a virtualization mechanism is shown. A method of assigning processors to virtual servers is shown. A server configuration table is shown. A virtualization mechanism management table is shown. A processor management table is shown. A failure correspondence table is shown. The user interface is shown. The flowchart of a core allocation program is shown. The flowchart of reliability-oriented core allocation is shown. The flowchart of a performance-oriented core allocation is shown. The flowchart of general-type core allocation is shown. An example of core allocation is shown. The flowchart of a failure sign detection mechanism is shown. The flowchart of a failure management program is shown. The flowchart of a trouble countermeasure program is shown. The flowchart of a failure predictive measure program is shown. The flowchart of a schedule control mechanism is shown. An interrupt control table is shown. The flowchart of a migration control program is shown. 2 shows a flowchart of a processor control mechanism. 10 shows a configuration of a processor having different cores in a second embodiment. 7 shows a failure correspondence table in the second embodiment. 10 is a flowchart of a failure handling program according to the second embodiment. The flowchart of the exclusive core replacement program in Example 2 is shown. The recovery structure of the application program in Example 2 is shown. Server configuration table when the virtualization mechanism is linked. The structure of a management server is shown.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 shows an overall view of an embodiment of the present invention. The center of control in this embodiment is the management server 101. The virtualization mechanism management program 102 is a program for managing the virtualization mechanism 115 operating on the server device 112 to be managed. The virtualization mechanism management program 102 includes a core allocation program 103, a failure management program 104, a schedule control program 105, and a migration control program 106. The core assignment program 103 performs control to assign the processor 119 included in the server device 112 and the core 116 in the processor 119 to the virtual server 114. The failure management program 104 is executed when a failure or a sign of failure is detected in the processor 119 or the core 116, and manages the replacement of the processor 119 or the core 116. The schedule control program 105 issues an instruction to change the execution schedule of the processor 119 and the core 116 to the virtualization mechanism 115. The migration control program 106 is a program that instructs the virtualization mechanism 115 to change the processor 119 or the core 116. These are executed while updating and referring to the core management table 107, the server configuration table 108, the virtualization mechanism management table 109, the processor management table 110, and the failure handling table 111. The server device 112 to be managed includes a memory 113, a processor 119, a core 116 built in the processor 119, a processor controller 117, and an I / O device 118. A virtualization mechanism 115 is stored and executed in the memory 113, thereby generating a virtual server 114. The virtual server 114 can have the same function as the server by distributing resources such as the memory 113, the processor 119, and the I / O device 118 in the server device 112 by the virtualization mechanism 115.

  FIG. 29 describes the relationship between the hardware of the management server 101 and the program. The management server 101 includes a memory 2901 for storing data such as programs and tables, a processor 2902 for executing the program, and a disk access interface. HBA (Host Bus Adapter) and network interface 2904, and the virtualization mechanism management program 102 and each table in the present invention are stored in the memory. The virtualization mechanism management program 102 is realized by being executed by the processor 2902. For the sake of simplicity, the processing of the processor 2902 will be described below with the program as the execution subject. The core allocation program 103, the schedule control program 105, the failure management program 104, and the migration control program 106 are executed by the processor 2902 to realize a virtualization mechanism management process. These are the core allocation unit, the schedule control unit, and the like. , A failure management unit, a migration control unit, and the like, which can be realized as hardware by integrating them as a processing unit for performing each process.

FIG. 2 shows a configuration example of the processor 119. A plurality of cores 116 are built in the processor 119. The core 116 can read an instruction from the memory 113 and execute the instruction or read / write data from / to the memory 113. The primary cache 202 in the core 116 is a high-speed memory for reading and writing instructions and data at high speed. The plurality of cores 116 includes a secondary cache 203 having a larger capacity than the primary cache 201, and the secondary cache 203 is shared by the plurality of cores 116. In addition, it has a memory interface for inputting / outputting data and instructions to / from the external memory 113. The plurality of cores 116 can operate independently. Therefore, the processing performance improves as the number of cores 116 increases. The plurality of cores 116 can take the form of a multiprocessor. That is, although the core 116 operates independently, the program on the memory 113 can be used as a single system. For example, when a plurality of programs run on the memory 113 at the same time, generally, a system program called an operating system automatically assigns execution control to the plurality of cores 116. Can be seen as implemented.

  FIG. 3 shows details of the virtualization mechanism 115. A virtualization mechanism 115 operates in the memory 113 in the server device 112. The virtualization mechanism 115 includes a schedule control mechanism 301, a processor control mechanism 303, a failure sign detection mechanism 302, an interrupt control table 304, and a control interface (I / F) 305. The schedule control mechanism 301 performs execution schedule control of programs related to the virtualization mechanism 115. The processor control mechanism 303 controls the operation mode of the processor 119. The failure sign detection mechanism 302 is a mechanism that operates on a regular basis or when the processor 119 becomes empty and checks the hardware. These operations can be controlled from the outside via the control I / F 305.

  FIG. 4 shows a state in which the processor 119 is assigned to the virtual server 114 by the virtualization mechanism 115. There are several methods for assigning to the virtual server 114. 401 is a method of assigning a single processor 119 to a plurality of virtual servers 114. It is also called a shared allocation method, and is an allocation method that is normally used when a plurality of virtual servers 114 share the same processor 119 resource and construct more virtual servers 114 than processors 119. The method of assigning 402 and 403 is also called an exclusive assignment method, and the virtual server 114 is assigned a dedicated processor 119 and is not shared by other virtual servers 114. There are several patterns of allocation methods, and a plurality of processors 119 are allocated to a single virtual server 114 as in 402. This allocation method is performed when a high-performance virtual server 114 is required. As described above, the virtualization mechanism 115 generates a plurality of virtual servers 114 by distributing resources of the server device 112 such as the processor 119 to the plurality of virtual servers 114, and the plurality of virtual servers 114 operate in parallel. You can also Although the method of assigning the processor 119 has been described here, resources such as the I / O device 118 and the memory 113 can also be divided and assigned in the same manner.

  FIG. 5 shows the server configuration table 108. The server configuration table 108 is a table provided mainly for managing the hardware configuration of the server device 112. A column 501 indicates a system identifier (ID). The system ID 501 is an identifier based on a single server configuration, for example. As an example, a multiprocessor configuration can be considered. A single system ID 501 is composed of a single or a plurality of processors as shown in a column 502. Further, a plurality of cores are mounted on the processor as indicated by a column 503. In a column 503, the number of cores included in the processor is described. A column 504 stores the total memory capacity of the system. A column 505 stores the type and number of I / O devices included in the system. For example, the I / O device is a network adapter for connecting to a network, a disk adapter for connecting to a disk, or the like. A column 506 stores an identifier (ID) of the virtualization mechanism. With these columns, the hardware resources per system can be grasped, and the hardware resources that can be used by the virtualization mechanism can be managed by associating with the virtualization mechanism.

  FIG. 6 shows the configuration of the virtualization mechanism management table 109. A column 601 indicates a virtualization mechanism ID. This is a virtualization mechanism ID corresponding to the column 506 in FIG. A column 602 stores the generated virtual server ID. All virtual server IDs generated by the virtualization mechanism are stored. In addition to the generated virtual server, information on a resource pool, which is a free hardware resource of the virtualization mechanism, is also described. This is because when a new virtual server is generated or when a resource is added to an existing virtual server, the remaining resources need to be managed because they are allocated from the free resources of the system. A column 603 stores processor IDs assigned to the virtual servers. When a plurality of processors are assigned, a plurality of processor IDs are described. A column 604 stores the core ID of the processor described in the column 603. This makes it possible to manage allocation to virtual servers in units of cores. A column 605 stores the memory capacity allocated to the virtual server. A column 606 stores an I / O device assigned to the virtual server. The virtualization mechanism management table 109 is updated when a new virtual server is created or deleted, or when an allocation resource is changed.

  FIG. 7 shows the configuration of the processor management table 110. The processor management table 110 mainly stores information on processor failures. A column 701 stores processor IDs. A column 702 stores the core ID of the processor. A column 703 stores the status of each processor and core. For example, a part is stored when a sign of a failure is detected or when a failure occurs. With the processor management table 110, in a server environment having a plurality of processors and a plurality of cores, a site in the processor can be specified when a failure sign is detected or when a failure is detected.

  FIG. 8 shows the configuration of the failure handling table 111. The failure handling table 111 describes measures to be taken when a failure occurs in the processor or when a failure sign is detected. The countermeasure is described for each processor type 801. Based on the processor type 801, the architecture of the processor can be specified, and countermeasures against failures caused by the difference in architecture can be managed. A column 802 stores processor parts. A column 803 stores a response when a failure sign is detected. For example, contents such as core change and virtualization mechanism schedule prohibition. The core replacement means that a replacement core is assigned by detecting a failure sign. Further, the prohibition of the virtualization mechanism schedule means prohibiting the virtualization mechanism schedule for the core or the processor. Processor replacement means that all cores of the processor are replaced with cores of other processors. The correspondence varies depending on the site. For example, when the core and the primary cache are built in the same core and are independent of the other cores, the replacement in units of cores is sufficient. However, when the secondary cache is shared by a plurality of cores, it is better to replace the processor in units of processors because of the large impact at the time of failure. A column 804 describes a response at the time of failure. The contents are the same as in column 803. Thus, the priority at the time of failure sign detection differs depending on the processor architecture. In order to manage these for each architecture, a failure correspondence table 111 is provided.

  FIG. 9 shows an example of a virtual server console. FIG. 9 describes a user interface when a new virtual server is generated. Reference numeral 901 denotes an overall view of the user interface. Reference numerals 902 to 904 denote menus for selecting an action for the virtual server. The contents of the menu selected here are displayed on the right side of the management server console 901. In FIG. 9, the contents of the virtual server addition are displayed. In 905, an ID of a newly generated virtual server is input. The user can select which system ID the virtual server is generated for. In 906, the characteristics of the virtual server to be generated are input. This is a feature of the present invention. As the characteristics of the virtual server, for example, characteristics such as emphasizing reliability, emphasizing performance, or general are conceivable. The importance of reliability means that even when the same amount of resources is allocated, an allocation method that is strong against a failure is performed. Further, performance-oriented means an allocation method that places importance on higher performance than reliability. General means that free resources are allocated without regard to reliability and performance. In step 907, a processor allocation method is selected. For example, an allocation method such as exclusive allocation / shared allocation, a core unit, a processor unit, and the number of allocation units are described. In 908, an allocated memory amount is input. A field 909 inputs an I / O device to be allocated. When inputting resources, if the contents described in the resource pool of the virtualization mechanism management table 109 are reflected in the user interface, input errors can be reduced and input can be facilitated. When all the items have been input, a new virtual server can be generated with the input parameters by pressing the button 910.

  FIG. 10 shows a flowchart of the core allocation program 103. The operation of the core allocation program 103 changes according to the input result of the user interface 906 in FIG. Each step of the core allocation program 103 will be described. In step 1001, when reliability emphasis is input, the process shifts to step 1003 to perform reliability emphasis core allocation processing. In step 1002, when the emphasis on performance is input, the process shifts to step 1004 to perform performance-oriented core allocation processing. If neither of these is the case, the process moves to step 1005 to perform general type core allocation processing.

  Next, each allocation process will be described with reference to a detailed flowchart. The reliability-oriented core allocation processing 1003 performs a core allocation method with high reliability when generating a virtual server. Here, the assignment of cores with high reliability means that when assigning a plurality of cores to a single virtual server, cores of different processors are selected and assigned. Step 1101 obtains the number of cores per processor from the server configuration table 107. Step 1102 determines the number of distributed processors from the number of cores. For example, the larger the number of cores in the processor, the larger the number of different processor cores that can be selected. This is because the larger the number of cores, the greater the impact when a failure occurs. Therefore, by selecting and assigning as many different processor cores as possible, even if a failure occurs in units of processors, it is possible to prevent all the cores of the virtual server from being stopped due to the failure. In step 1103, a processor is selected from the resource pool of the virtualization mechanism management table 109. Step 1104 determines whether the selected processors are all the same processor. Step 1105 selects the same type of processor from the resource pool. This is because when determining the cores to be assigned to a single virtual server, it is possible to reduce the variation in reliability by selecting processors having the same number of cores as possible. If there is no free processor of the same type, a method such as selecting a processor with as many cores as possible is also conceivable. Step 1106 updates the virtualization mechanism management table 109. Step 1107 instructs the virtualization mechanism 115 to generate a new virtual server based on the selected core. In this way, by selecting different processor cores for a single virtual server, it is possible to prevent all cores of the virtual server from failing simultaneously due to a single processor failure.

  FIG. 12 shows a flowchart of the performance-oriented core allocation processing 1004. Here, the performance-oriented type means that the cores assigned to the virtual server are assigned the same processor core as much as possible. This is because, for example, a secondary cache shared by a plurality of cores is used efficiently. A program executed in a single virtual server is likely to refer / update the same instruction or data. In these cases, the cache hit rate can be improved by sharing the cache as much as possible. Therefore, in order to use the cache efficiently and obtain high performance, it is better to allocate cores of the same processor as much as possible. In step 1201 of the performance-oriented core allocation processing 1004, a core having a large number of cores per processor and a large number of free spaces is selected from the resource pool of the virtualization mechanism management table 109. Step 1203 determines whether the planned number of cores has been reached. If the planned number of cores has not been reached, in step 1204, a core having a large number of cores per processor and a large number of free cores is selected from the resource pool of the virtualization mechanism management table 109, and step 1203 is repeated. Step 1205 updates the virtualization mechanism management table 109. Step 1206 instructs the virtualization mechanism 115 to generate a new virtual server based on the selected core. With these processes, it is possible to provide an allocation method that improves the performance of the virtual server.

  FIG. 13 shows a flowchart of the general-type core assignment process 1005. The general type is a method of assignment when neither reliability nor performance is important. Basically, free resources are searched in order and cores are allocated. Step 1301 in the general type core allocation process 1005 selects a free core from the resource pool of the virtualization mechanism management table 109. Step 1302 determines whether the planned number of cores has been reached. If the planned number of cores has not been reached, a free core is selected from the resource pool of the virtualization mechanism management table in step 1303, and then step 1302 is repeated. Step 1304 updates the virtualization mechanism management table 109. Step 1305 instructs the virtualization mechanism 115 to generate a new virtual server.

  FIG. 14 shows an example of the results of the reliability-oriented core allocation process and the performance-oriented core allocation process. 1401 is the result of the reliability-oriented core allocation process. As described above, a feature is that cores of a plurality of different processors are allocated to a single virtual server. Thereby, even if a failure occurs in the processor, all the virtual servers are not stopped. On the other hand, 1402 is an example of a performance-oriented core allocation result. In this way, the feature is that cores of the same processor as much as possible are allocated to the virtual server. Thus, the performance can be improved by effectively using the shared secondary cache instructions and data. Although not shown in the figure, there is also an allocation method that emphasizes both performance and reliability. For example, there is a mixture of two allocation methods in which the number of different processors is reduced, and instead the cores of the same processor are allocated with priority. By doing so, it is possible to generate a virtual server that satisfies the reliability and performance.

  FIG. 15 shows a flowchart of the failure sign detection mechanism 302. The failure sign detection mechanism 302 is executed in the virtualization mechanism 115 and checks the hardware when the processor is idle (idle) or when a predetermined time has elapsed. Step 1501 in the failure sign detection mechanism 302 determines whether the processor is idle. Step 1502 determines whether a predetermined time has elapsed since the previous check. If either of the conditions in step 1501 or step 1502 matches, hardware check after step 1503 is executed. Step 1503 performs a processor core check. The processor core is checked for signs of failure. Step 1504 checks the primary cache in the processor for signs of failure. Step 1505 checks the secondary cache in the processor for signs of failure. Step 1506 checks the memory bus in the processor for signs of failure. For the failure predictor check in these processors, for example, a method of issuing a dedicated instruction for checking to the processor can be considered. Step 1507 checks the memory for signs of failure. For example, the memory check may use a memory error detection mechanism such as parity or ECC (Error Check and Correct memory). Step 1508 performs an I / O device check. Step 1509 performs a processor controller check. In step 1510, the check results from step 1503 to step 1509 are written in the processor management table 110. In step 1511, the checked current time is recorded. This is used for the next check determination (step 1502). Also, when a failure has occurred instead of a failure sign at the time of the check, it is recorded in the processor management table 110 as with the failure sign. Through these processes, it becomes possible to grasp a hardware failure in advance.

  FIG. 16 shows a flowchart of the failure management program 104. Step 1601 in the failure management program 104 determines whether a failure has occurred. This can be determined by referring to the processor management table 110. Step 1602 determines whether a failure sign has been detected. This can also be determined by referring to the processor management table 110 as in step 1601. If a failure has occurred, the process moves to step 1603, and the failure countermeasure program is executed. If a failure sign is detected, the process proceeds to step 1604 to execute a failure sign countermeasure program.

  FIG. 17 shows a flowchart of the failure countermeasure program 1603. The processor or core in which the failure has occurred basically performs processing to replace another processor or core. A step 1701 in the failure countermeasure program 1603 searches the processor management table 110 for a failed processor. Step 1702 searches the processor management table 110 for a fault occurrence site. In step 1703, the failure correspondence table 111 is referred to and a process corresponding to the failure site is searched. Step 1704 determines whether the failure response is a core change. In the case of core replacement, the process proceeds to step 1605, the virtualization mechanism management table 109 is searched, and a core of a processor different from the failed processor is selected as the replacement core. Step 1706 separates the failed core from the virtual server and assigns the replacement core selected in step 1705. Step 1707 determines whether the failure response is a processor change. In the case of processor replacement, the process proceeds to step 1708, the virtualization mechanism management table 109 is searched, and a different processor is selected as the replacement processor. In step 1709, the faulty processor is disconnected and a replacement processor is assigned. By these processes, the virtual server assigned to the failed core or the processor can be returned to a normal state.

  FIG. 18 shows a flowchart of the failure predictor countermeasure program 1604. The processor or core in which the failure sign is detected basically performs processing to replace another processor or core. In step 1801 of the failure sign countermeasure program 1604, the processor in which the failure sign is detected is searched from the processor management table 110. In step 1802, the processor management table 110 is searched for the occurrence site of the failure sign. In step 1803, the failure correspondence table 111 is referenced to search for a process corresponding to the failure sign portion. Step 1804 issues an instruction to the schedule control mechanism 301 to remove the outline part from the execution schedule target of the virtualization mechanism 115. This is intended to protect the virtualization mechanism 115 from failures that may occur in the future. Since the virtualization mechanism 115 may affect the entire system including the generated virtual server, the virtualization mechanism 115 is a target to be protected with priority in the system. In step 1804, the reliability of the entire system can be improved by excluding the processor or core from which the failure sign has been detected from the schedule target. Step 1805 determines whether the failure predictor response is a core change. In the case of core replacement, the process proceeds to step 1806, the virtualization mechanism management table 109 is searched, and a core of a processor different from the processor that detected the failure sign is selected as the replacement core. In step 1807, a migration control program is called. Here, migration is a process for preventing the system from being affected when the core is changed. Step 1808 determines whether the failure predictor response is a processor change. In the case of processor replacement, the process proceeds to step 1809, the virtualization mechanism management table 109 is searched, and a different processor is selected as the replacement processor. In step 1810, the migration control program is called. With these processes, the virtual server can be returned to a normal state without affecting the system or the core or processor in which the failure sign is detected.

  FIG. 19 shows a flowchart of the schedule control mechanism 301. Step 1901 in the schedule control mechanism 301 detects whether or not a sign of core failure has been detected. When a sign of a core failure is detected, the process proceeds to step 1902 and the interrupt control table 304 is changed so that the corresponding core is excluded from the schedule target. Step 1903 determines whether or not a failure sign affecting the entire processor has been detected. For example, a failure predictor such as a secondary cache or a memory bus shared by a plurality of cores. When a failure sign affecting the entire processor is detected, the interrupt control table 304 is changed so that all cores of the processor are excluded from the schedule target.

  FIG. 20 shows the interrupt control table 304. A column 2001 stores processor IDs. A column 2002 stores a core ID. A column 2003 stores interrupt enable / disable according to the interrupt level. The number and meaning of interrupt levels differ depending on the processor architecture. However, when a failure sign is detected, the interrupt is changed to disable for the purpose of protecting the program. As a result, programs that affect the entire system such as the virtualization mechanism 115 can be protected. Generally, a program executed by a processor is executed by a core in the processor that has accepted an interrupt. When no failure occurs in the core or the processor, the generated interrupt is distributed so that the program is executed evenly in a plurality of cores. However, when a failure sign is detected, there is a possibility that a failure will occur in the near future. Therefore, a program such as the virtualization mechanism 115 that emphasizes reliability needs to be protected. For this reason, the core or the processor that has detected the failure sign is disabled from being executed by disabling interrupts. In FIG. 20, for example, the core 1 of the processor 1 that has detected a core failure sign is set to be non-interruptible. Further, the processor 2 that has detected a failure sign affecting the entire processor is set so that interrupts are disabled for all cores.

  FIG. 21 shows a flowchart of the migration control program 106. Step 2101 in the migration control program 106 determines whether a core failure sign has been detected. If a core failure sign is detected, the process proceeds to step 2102, and the processor control mechanism 303 is instructed to switch the control mode between the failure sign detection core and the replacement core to step execution. This is to accurately grasp how far the instruction has been executed by changing the execution mode of the processor to step execution. In the normal execution mode, since a plurality of instructions are executed simultaneously in the core, it is not possible to determine how many instructions have been executed. Therefore, the processor is temporarily shifted to the step execution mode to manage the instruction level operation of the processor from the outside. The reason for shifting the replacement core to the step execution mode is to control the execution from the outside. Step 2103 obtains the state of the corresponding core from the processor control mechanism 303. Here, the state is information necessary for smoothly transferring control to the replacement core. For example, the contents of a control register that stores an instruction execution address such as a program counter. Step 2104 sets the state of the core for the alternate core. In step 2105, the failure sign detection core is stopped and the execution of the replacement core is instructed for the core replacement. Thereby, it is possible to shift to the replacement core without affecting the system. Step 2106 determines whether a processor failure sign has been detected. When a processor failure sign is detected, the process proceeds to step 2107, and the processor control mechanism 303 is instructed to switch the control modes of all cores of the failure sign detection processor and the replacement processor to step execution. Step 2108 obtains the states of all corresponding cores from the processor control mechanism 303. Step 2109 sets the core state acquired in step 2108 for the core of the replacement processor. Step 2110 stops the failure sign detection processor and instructs execution of the replacement processor. As a result, the entire processor can be migrated without affecting the system.

  FIG. 22 shows a flowchart of the processor control mechanism 303. Step 2201 in the processor control mechanism 303 determines whether or not it is an instruction to change to the normal execution mode. In the case of an instruction to change to the normal execution mode, the process proceeds to step 2202, and the designated core is switched to the normal execution mode. Step 2203 determines whether or not to switch to the step execution mode. In the case of switching to the step execution mode, the designated core is switched to the step execution mode.

  According to the first embodiment, a failure can be avoided in advance by detecting a failure sign of the processor, and even when a failure occurs, reliability can be improved by assigning a core of a plurality of processors to a single virtual server. . In addition, high reliability and performance are emphasized as user interfaces, and the processor can be used efficiently by controlling the assignment of cores to virtual servers.

  In the first embodiment, the virtualization mechanism management program 102 and various tables are stored in the memory 2901 of the management server 101, but may be stored in the memory 113 of the server device 112. For example, as one method of arranging the virtualization mechanism management program 102 and various tables in the server device 112, the virtualization mechanism management program 102 and various tables of the management server 101 may be arranged in one of the virtual servers 114. .

  In the first embodiment, the processor cores 116 are allocated using the virtualization mechanism 115, but the virtualization mechanism 115 is not always necessary. For example, the present invention can be applied to a case where a single operating system performs multi-core assignment. For example, the present invention can be applied to a program execution environment such as an operating system process or thread. In another example, the present invention can be applied to the case where an environment capable of executing a plurality of operating systems with different operating systems is generated.

  FIG. 23 shows the configuration of the processor according to the second embodiment of the present invention. The core in the first embodiment is a general-purpose core in the second embodiment. In the second embodiment, a management method in the processor 119 in which not only the same type of core but also different types of cores are mounted will be described. A significant difference is that a dedicated core 2301 is mounted on the processor 119. The dedicated core 2301 means a core for the purpose of speeding up a specific process. For example, high-speed floating-point arithmetic and high-speed character string processing can be considered.

  FIG. 24 shows the configuration of the failure handling table 111 in the second embodiment. Unlike the first embodiment, a dedicated core item is added to the processor portion of the column 802. In the second embodiment, since the number of dedicated cores is smaller than that of the general-purpose cores, it means that the priority order for failure is set higher than that of the general-purpose cores. In other words, since the failure of a small number of types of cores has a large influence on the system, it is set to give priority to replacement. In the second embodiment, an example in which the number of general-purpose cores is larger than that of dedicated cores is shown. The present invention is characterized by increasing the replacement priority of a small number of cores regardless of whether they are dedicated cores or general-purpose cores. Thus, when different types of cores are mounted, the virtual server core management method also differs.

  FIG. 25 shows a flowchart of the failure countermeasure program 1603 in the second embodiment. The processor or core in which the failure has occurred basically performs processing to replace another processor or core. In step 1701 of the failure countermeasure program 1603 in the second embodiment, a processor in which a failure has occurred is searched from the processor management table 110. Step 1702 searches the processor management table 110 for a fault occurrence site. In step 1703, the failure correspondence table 111 is referred to and a process corresponding to the failure site is searched. Step 1704 determines whether the failure response is a core change. In the case of core replacement, the process proceeds to step 1605, the virtualization mechanism management table 109 is searched, and a core of a processor different from the failed processor is selected as the replacement core. Step 1706 separates the failed core from the virtual server and assigns the replacement core selected in step 1705. Step 1707 determines whether the failure response is a processor change. In the case of processor replacement, the process proceeds to step 1708, the virtualization mechanism management table 109 is searched, and a different processor is selected as the replacement processor. In step 1709, the faulty processor is disconnected and a replacement processor is assigned. In step 2501, it is determined whether or not the dedicated core is replaced. If it is the replacement of the dedicated core, the process proceeds to step 2502, and the dedicated core replacement program is called. By these processes, the virtual server assigned to the failed core or the processor can be returned to a normal state.

  FIG. 26 shows a flowchart of the dedicated core replacement program 2502. Step 2601 in the dedicated core replacement program 2502 determines whether there is a dedicated core for replacement. If there is a replacement core, the process proceeds to step 2602, the virtualization mechanism management table 109 is searched, and a core of a processor different from the failed processor is selected. Here, the core means a dedicated core. In step 2603, the failed core is separated and a replacement core is assigned. On the other hand, if the replacement core does not exist, the process proceeds to step 2604, the virtualization mechanism management table 109 is searched, and a general-purpose core of a processor different from the processor in which the failure has occurred is selected. In step 2605, a program for emulating the function of the dedicated core is executed on the general-purpose core, and the dedicated core is replaced. Step 2606 assigns the general-purpose core as a dedicated core. With these processes, the core can be continued without stopping the system by emulating a small number of cores with a general-purpose core. The same processing can be applied to the operation at the time of failure sign detection.

  FIG. 27 shows an example of recovery of an application program when a processor or a processor core fails. In the virtual server 114, an operating system 2704 runs and an application program 2701 is executed on the operating system 2704. The application program has a snapshot acquisition program 2702 and a recovery program 2703. The snapshot acquisition program 2702 has a function of periodically recording the operation state of the application. This is to enable re-execution when a failure occurs. For example, an execution result of an application program. When a failure occurs in the processor or the core, the recovery program 2703 reads the state acquired by the snapshot acquisition program 2702, and the execution of the application program 2701 is resumed.

  FIG. 28 illustrates the server configuration table 108 according to the third embodiment. A difference from the first embodiment is that a column 2801 is added. A column 2801 means that the virtualization mechanisms cooperate with each other. Although the system IDs are different, the virtualization mechanisms cooperate with each other, so that a plurality of systems can be shown as a single system. In FIG. 28, this means that the virtualization mechanism 1 and the virtualization mechanism 2 are linked. In such a case, when a failure sign or failure is detected, the target for replacement can be expanded. For example, when a failure occurs in the core of the processor ID1 belonging to the virtualization mechanism 1, the core of the processor 3 can be selected as a replacement target. This cooperation can improve the reliability and availability of the system.

  It is used in the field using computers that run on multi-core processors.

DESCRIPTION OF SYMBOLS 101 Management server 102 Virtualization mechanism management program 103 Core allocation program 104 Failure management program 105 Schedule control program 106 Migration control program 107 Core management table 108 Server configuration table 109 Virtualization mechanism management table 110 Processor management table 111 Failure correspondence table 112 Server apparatus 115 Virtualization Mechanism 114 Virtual Server 119 Processor 116 Core

Claims (6)

A server having a plurality of processors having a plurality of arithmetic cores, wherein a virtualization mechanism for generating and controlling a virtual server is operated in the server, and the virtualization mechanism is managed in a virtualization environment managed by a management server.
The virtualization mechanism has a failure sign detection mechanism for detecting a failure sign of the processor,
When the failure sign detection mechanism detects a failure sign of the processor or the arithmetic core,
The management server changes the execution schedule so that the virtualization mechanism is not executed by the processor or the arithmetic core that detects the failure sign,
The management server has a correspondence table that holds whether to replace the processor or the computing core for each part of the processor that has detected a failure sign ,
When a failure sign is detected, the processor or the arithmetic core is replaced based on the correspondence table,
A multi-core processor control method characterized in that, when the processor has the different types of computing cores, the computing cores with fewer types are preferentially replaced when the failure sign is detected. The correspondence table at the time of failure sign detection includes, in addition to the contents of replacement at the time of failure sign detection, whether to replace the processor or the calculation core for each part of the processor that has detected a failure. The multi-core processor control method according to claim 1 , wherein the processor portion includes a general-purpose core or a dedicated core . A computer system including a computer having a plurality of processors having a plurality of arithmetic cores,
In the computer system, a virtualization mechanism that generates and controls a virtual server operates, and the virtualization mechanism is managed by a management server,
The virtualization mechanism has a failure sign detection mechanism for detecting a failure sign of the processor,
The failure sign detection mechanism detects a failure sign of a processor or the arithmetic core,
The management server
Means for changing the execution schedule so that the virtualization mechanism is not executed by the processor or the arithmetic core that detects the failure sign;
A correspondence table that holds whether to replace the processor or the computing core for each part of the processor that has detected a failure sign ;
When the failure sign is detected, the processor or the calculation core is replaced based on the correspondence table, and when the processor has different types of calculation cores, the number of the calculation cores is small when the failure sign is detected. A computer system having a multi-core processor, characterized in that it has means for preferentially changing. The correspondence table at the time of failure sign detection includes, in addition to the contents of replacement at the time of failure sign detection, whether to replace the processor or the calculation core for each part of the processor that has detected a failure. 4. The computer system having a multi-core processor according to claim 3 , wherein the computer part includes a general-purpose core or a dedicated core . A computer having a plurality of processors having a plurality of arithmetic cores operates a virtualization mechanism that generates and controls a virtual server, and the virtualization mechanism is managed by a management computer,
The virtualization mechanism has a failure sign detection mechanism for detecting a failure sign of the processor,
The management computer has a correspondence table that holds whether to replace the processor or the computing core for each part of the processor that has detected a failure sign ,
When the failure sign detection mechanism detects a failure sign of the processor or the arithmetic core,
In the management computer,
A function of changing the execution schedule so that the virtualization mechanism is not executed by the processor or the arithmetic core that detects the failure sign;
When the failure sign is detected, the processor or the calculation core is replaced based on the correspondence table, and when the processor has different types of calculation cores, the number of the calculation cores is small when the failure sign is detected. A management computer program characterized by executing a function of giving priority to replacement. The correspondence table at the time of failure sign detection includes, in addition to the contents of replacement at the time of failure sign detection, whether to replace the processor or the calculation core for each part of the processor that has detected a failure. 6. A management computer program according to claim 5 , wherein said processor portion includes a general-purpose core or a dedicated core .

Images