WO2012068867A1

WO2012068867A1 - Virtual machine management system and using method thereof

Info

Publication number: WO2012068867A1
Application number: PCT/CN2011/075552
Authority: WO
Inventors: 马苏安; 汪军; 胡学川; 彭永林
Original assignee: 刘建
Priority date: 2010-11-22
Filing date: 2011-06-09
Publication date: 2012-05-31
Also published as: CN102479099B; CN102479099A

Abstract

A virtual machine management system and using method thereof is disclosed. The system comprises: a central management server, master nodes and slave nodes. The central management server is used for managing the master nodes; each master node is used for managing one or more clusters, wherein, each cluster comprises one or more slave nodes; and the slave nodes are physical hosts to run virtual machines. The solution achieves the effect that the virtual machines can be managed effectively when the number of the virtual machines is great.

Description

TECHNICAL FIELD The present invention relates to the field of communications, and in particular to a virtual machine management system and a method for using the same. BACKGROUND Virtualization technology is to divide a physical resource into multiple logical partitions by using virtualization software on a physical server, and each partition is isolated from each other to become an independent virtual machine. In terms of operating systems and applications, virtual machines are no different from physical servers, and they can share the same physical server. To fully utilize the utilization of resources, it is very important to manage the scheduling of virtual machines. The management scheduling functions include the allocation of virtual machine resources, virtual machine migration, and virtual machine lifecycle management. Management scheduling is implemented by the virtual machine management system. At present, the virtual machine management system generally consists of a management server and agent software. The management server includes various functional modules to implement overall management of the virtual machine. The agent software is installed on the physical host running the virtual machine. It is responsible for managing the virtual machine of the physical host and communicating with the management server to join the management scope of the management server. The virtual machine management system manages the physical machines into multiple clusters, each consisting of dozens of servers. Currently, each management system can manage up to hundreds of servers and thousands of virtual machines. 1 is an architectural diagram of a virtual management system according to the related art. 101 is the Management System, which is responsible for performing virtual machine management and scheduling tasks. It connects to each Node and manages commands to each Node. 102 is a client (client), and the administrator issues an operation command to the management system through the client. 103 is a Node, and each Node is a physical host on which multiple virtual machines can run. 104 is a cluster. To facilitate management, the management system groups multiple Nodes into one cluster and manages them in clusters. In this management mode, the management system assumes all management tasks. When the virtual machine scale is small, a few sets of virtual machine management systems can implement effective management. When the number of nodes is too large (when the number of virtual machines is huge) Especially in the desktop virtualization environment, each user corresponds to one virtual machine, and the number of virtual machines may reach hundreds of thousands or even millions.) A management system cannot be used, and hardware processing capacity needs to be increased. Or add another management system. When the number of Nodes reaches tens of thousands or more, this method cannot be managed. Therefore, it is impossible to effectively manage each virtual machine by the management method in the related art. Moreover, these management systems cannot be effectively coordinated, and a large number of management systems are themselves difficult to maintain. SUMMARY OF THE INVENTION A main object of the present invention is to provide a virtual machine management solution to solve at least the problem that the virtual machine cannot be effectively managed when the number of virtual machines is large in the related art. In order to achieve the above object, according to an aspect of the present invention, a virtual machine management system is provided, the system comprising: a central management server, a master node, and a slave node, wherein the central management server is configured to manage the master node; The master node is used to manage one or more clusters, where each cluster includes one or more slave nodes; the slave node is a physical host running a virtual machine. Preferably, the central management server is configured to set the activated physical host as a master node or a slave node when detecting the physical host startup, and if set as a slave node, the central management server is configured to specify a master node for the slave node. management. Preferably, the central management server is configured to set the activated physical host as a master node when the management capability of the system is insufficient, and otherwise set the activated physical host as a slave node. Preferably, the central management server is arranged to send the management software to the master node and to send the agent software to the slave node. Preferably, the central management server is further configured to set a backup primary node for the primary node when setting the primary node. Preferably, the master node is further configured to store management information of the clusters and slave nodes it manages; the central management server is further configured to store an index of management information stored by each master node. Preferably, the system further includes: a client, wherein the client is configured to query an index of the central management server, obtain a primary node corresponding to the index of the query, and send an operation request to the corresponding primary node. Preferably, the central management server employs a multi-layered structure, and one upper central management server manages one or more subordinate central management servers. Preferably, the master node comprises: management software, configured to manage the cluster; the slave node comprises: a node agent, configured to manage the slave node, and execute the command through the virtual machine manager; the virtual machine manager is set to be scheduled from the node The virtual machine, and execute the command sent by the node agent. In order to achieve the above object, according to another aspect of the present invention, a method for performing virtual machine migration using the above system is provided, the method comprising: determining, by a master node, a slave node managed by a master node The resource reaches a predetermined threshold; the master node determines whether the slave node managed by the master node has idle resources, and if so, migrates the virtual machine on the slave node whose resource reaches the predetermined threshold to the slave node that has the idle resource, otherwise, The master node acquires the master node with the idle resource from the central management server, and migrates the virtual machine on the slave node whose used resource reaches the predetermined threshold to the slave node managed by the master node with the idle resource. In order to achieve the above object, in another aspect of the present invention, a method for performing virtual machine allocation using the foregoing system is provided, the method comprising: receiving, by a central management server, a request for requesting a virtual machine sent by a client, and allocating a request for a client a master node having an idle resource, and transmitting the address of the assigned master node to the client; the assigned master node receives the request of the client to allocate the allocated virtual machine, and allocates the slave node with the idle resource to the client; The slave node allocates virtual machines to clients. In order to achieve the above object, according to another aspect of the present invention, a method for performing virtual machine query using the above system is provided, the method comprising: receiving, by a central management server, a host node where a query virtual machine sent by a client is located The request sends the address of the primary node where the virtual machine is located to the client; the primary node where the virtual machine is located receives the virtual machine status request sent by the client, obtains the state of the virtual machine from the slave node where the virtual machine is located, and the virtual machine's state The status is sent to the client. In order to achieve the above object, according to still another aspect of the present invention, a method for using the above system is provided, the method comprising: the central management server detects that the physical host is started; and the central management server sets the activated physical host as a master node or From the node. Preferably, if the physical host that is started is the primary node, the central management server delivers the management software to the activated physical host, and if the activated physical host is the secondary node, Then, the central management server delivers the proxy software to the slave node. Preferably, the physical host initiated by the central management server is the primary node or the secondary node includes: the physical that the central management server will start when the management capability of the system is insufficient The host is set as the master node, otherwise the activated physical host is set as the slave node. The method for managing a virtual machine by using at least three layers of structures (for example, a central management server, a master node, and a slave node) solves the problem that the virtual machine cannot be effectively used when the number of virtual machines is large in the related art. The management problem can achieve the effect of effectively managing the virtual machine when the number of virtual machines is large. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 1 is a schematic diagram of a virtual management system according to the related art; FIG. 2 is a schematic diagram of a virtual machine management system according to an embodiment of the present invention; FIG. 3 is a flowchart of a virtual machine management method according to an embodiment of the present invention. FIG. 4 is a schematic diagram of an internal node and a slave internal architecture according to an embodiment of the present invention; FIG. 5 is a schematic diagram of a physical host assigned to a master node according to an embodiment of the present invention; FIG. FIG. 7 is a schematic diagram of a client requesting a virtual machine according to an embodiment of the present invention; FIG. 8 is a schematic diagram of a client querying a virtual machine state according to an embodiment of the present invention; A schematic diagram of virtual machine migration across a cluster according to an embodiment of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. The embodiment of the present invention provides a virtual machine management system. FIG. 2 is a schematic diagram of a virtual machine management system according to an embodiment of the present invention. As shown in FIG. 2, the system includes: a central management server (Center Management Server, For example, CMS 201, Master Node (MN) 202, Slave Node (SN) 204, wherein CMS 201 is set to manage MN 202; each MN 202 is set to manage one or more Clusters, where each cluster includes one or more SNs 204; SN 204 is a physical host running a virtual machine. In this embodiment, when managing a virtual machine, the system is divided into at least three layers of CMS, MN, and SN. This structure helps manage the virtual machine when the number of virtual machines is large. It should be noted that the three-layer structure is only a preferred management mode, and the embodiment of the present invention is not limited to the three-layer structure. For example, there may be multiple CMSs, and multiple CMSs may form a multi-layer structure, and multiple sub-center management servers may be managed by one upper-level central management server. It can be seen that when the amount of data of the virtual machine is large, the management of the virtual machine can be implemented by using four or more layers, and the data of the next layer is managed by the upper layer. In a preferred example of the embodiment of the present invention, when detecting that a physical host is started, the CMS 201 may set the physical host as an MN or an SN, and the CMS 201 may also assign a physical host to the SN. The MN manages. Wherein, when the management capability of the system is insufficient, CMS 201 can set the physical host start is MN, when the management capability of the system is sufficient, CMS 201 may be provided to the physical host ¹ ^ starts to SN. Preferably, the CMS 201 can send the management software to the MN for the MN to manage according to this, and can also send the agent software to the SN for the SN to manage the agent software. Preferably, the CMS 201 can also set a backup MN for the MN. When the primary MN fails, the backup MN can automatically replace it for management work. In another preferred embodiment of the embodiment of the present invention, the CMS 201 delivers the management software to the MN.

202. The CMS 201 delivers the proxy software to the SN 204. In still another preferred embodiment of the embodiment of the present invention, the management information of the cluster and the SN managed by the MN is stored in the MN; and the index of the management information stored by each MN is stored in the CMS. In this embodiment, the CMS does not need to store a large amount of management information, so that one CMS can manage multiple MNs, which provides a convenient condition for the expansion of system management capabilities. When the management of the four-layer structure is used, the upper-level CMS can also store the information processed by the index of the lower-level CMS. For example, the lower-level CMS saves the ID of the virtual machine it manages, and the upper-level CMS saves the ID of the virtual machine saved by the lower-level CMS. The scope. Preferably, the system may further include: a client 206, when the client 206 is to perform a management operation, may first query an index of the CMS 201, obtain an MN corresponding to the index, and send an operation request to the corresponding MN, thereby completing The corresponding management operation. In still another preferred embodiment of the embodiment of the present invention, the master node includes: management software configured to manage the cluster; the slave node includes: a node agent, configured to manage the slave node, and execute the command through the virtual machine manager; the virtual machine The manager, set to schedule the virtual machines in the slave node, and execute the commands sent by the node agent. The system may further include: a management plane 203 composed of MNs, wherein the MNs form an active/standby relationship, and when one MN fails, other nodes perform management functions instead of them. Cluster 205, if thousands of SNs form a cluster. At jtb, CMS 201 is responsible for downloading management software and configuration to physical hosts and providing an overall system view. The master node MN 202 is a node responsible for managing thousands of clusters and updates the cluster information to the CMS. The SN 204 is a managed physical server on which the agent software is run, accepting the management of the MN, and each SN can run multiple VMs. The client 206 is configured to receive the management command issued by the administrator, query the index information through the CMS, obtain the MN address to be operated, and then directly establish a connection with the MN, and send a management command. Embodiment 2 The embodiment of the present invention further provides a method for using the foregoing virtual machine management system, where the method is used for migrating a virtual machine. FIG. 3 is a flowchart of a method for managing a virtual machine according to an embodiment of the present invention. As shown in FIG. 3, the method includes: Step S302: The MN determines that the resource used by the SN managed by the MN reaches a predetermined threshold; Step S304, the MN determines the MN management. Whether the SN has idle resources, and if so, the virtual machine on the SN that uses the resource to reach the predetermined threshold is migrated to the SN with the idle resource. Otherwise, the MN acquires the MN with the idle resource from the CMS, and the used resource is used. The virtual machine on the SN that reaches the predetermined threshold migrates to the SN managed by the MN with the idle resource. The embodiment of the invention further provides a method for using the above virtual machine management system, which is used for allocating a virtual machine. The method includes: the CMS receives a request for requesting a virtual machine sent by a client, allocates a MN with an idle resource to the client, and sends the address of the allocated MN to the client; and the allocated MN receives the allocated virtual machine sent by the client. Request, the client is assigned an SN with idle resources; the SN with idle resources allocates a virtual machine to the client. The embodiment of the present invention further provides a method for using the foregoing virtual machine management system, where the method is used for querying a virtual machine, and the method includes: receiving, by the CMS, a request by the client to query the MN where the virtual machine is located, and sending the request to the client The address of the MN where the virtual machine is located; the MN where the virtual machine is located receives the virtual machine status request sent by the client, obtains the state of the virtual machine from the SN where the virtual machine is located, and sends the status of the virtual machine to the client. The embodiment of the present invention further provides a method for using the foregoing virtual machine management system, the method includes: if the CMS detects that the physical host is started, the physical host that is set by the CMS is MN or SN; if the activated physical host is MN . Preferably, the CMS delivers the management software to the activated physical host. If the activated physical host is the SN, the CMS delivers the proxy software to the SN. Preferably, the physical host initiated by the CMS setting is the MN or the SN can be set in the following manner: When the management capability of the system is insufficient, the CMS will set the physical host to be set to the MN, otherwise, the activated physical host is set to the SN. Embodiment 3 This embodiment provides a management system with automatic expansion capability, which can implement effective management of massive virtual machines. The implementation process of the embodiment of the present invention is described below by taking the system as a three-layer structure. It should be noted that when the system is a four-layer or multi-layer structure, the management of the upper layer and the lower layer may be performed in the same manner as the three-layer structure. . In the system provided in this embodiment, a CMS is set up, and there is also a management plane composed of MNs. Each VM runs a set of virtual machine management systems that manage thousands of clusters. A cluster consists of thousands of hosts. These hosts are called SNs. One SN is a physical host running a virtual machine (VM). The SN runs the agent software at the same time to manage the host. In this embodiment, the management software and the agent software on the MN and the SN do not need to be pre-installed, but are downloaded from the CMS when the host is started. The download mode can be: When a physical host is started, the default startup script in the host actively reports its hardware resources and configuration information to the CMS. The CMS determines whether the host should be assigned as the MN or SN according to a certain policy. When the host is assigned as the MN, the CMS downloads the corresponding management software, otherwise it downloads the agent software and adds the SN to the management scope of a certain MN. The detailed information and status data of each cluster and VM are stored in the corresponding MN. The MN implements state collection and specific management scheduling for the host and the virtual machine, and the CMS saves the overall view of the system, including each The configuration of the cluster, the physical host information, the current number of virtual machines, the current resource allocation, and the list of reserved virtual machines, etc., the MN is responsible for updating the changed information to the CMS system. When the client wants to implement a management operation, it first queries the CMS for the overall view and further issues an operation request to the MN based on the returned information. Multiple MNs can be set up to be active and standby, and each other can back up management information. When the MN fails, the other MN implements the management function in place of the failed MN. In order to avoid a single point of failure in the CMS, the CMS can be set up as a master standby system. This embodiment can implement effective management of a massive virtual machine as a whole, reducing system maintenance and maintenance personnel input. Embodiment 4 FIG. 4 is a diagram showing the internal architecture of a master node and a slave node according to an embodiment of the present invention. As shown in Figure 4, 401 is the management software CM (Cluster Manager) running in the master node, responsible for the management of thousands of clusters. 402 is the slave node internal NA (Node Agent), responsible for the management of the node, including creating virtual machines, deleting virtual machines, virtual machine migration, etc., which execute specific commands through the hypervisor (virtual machine manager). 403 is a hypervisor, which is a module for implementing hardware virtualization. It is responsible for scheduling the virtual machine central processing unit (CPU) and memory. The management commands sent by NA are executed by the hypervisor. 404 is a virtual machine, which is a unit for allocating resources. The CPU, memory, and storage space of the virtual machine can be allocated as needed, and can be migrated between physical machines as necessary. The following describes a method for performing virtual machine management using the above system through a specific example. Although the following embodiments illustrate the implementation process of the embodiment of the present invention by taking the system as a three-layer structure, those skilled in the art can clearly understand that when the system is a four-layer or multi-layer structure, only three layers are used. The structure of the upper layer to the lower layer can be managed in a similar manner. Embodiment 5 FIG. 5 is a schematic diagram of a physical host assigned as a master node according to an embodiment of the present invention. When the physical host starts, when the CMS determines that the MN management capability is insufficient, the physical host is assigned as a new MN. The specific process is as follows: Step 501: The physical server starts, and the preset startup code sends a startup message to the CMS, where the message includes configuration information of the physical server; Step 502, the CMS determines that the node should be based on the current MN management load. The MN is configured to download the MN management software for the node. Step 503: The CMS specifies a backup MN for the MN to form a backup relationship with the MN. Step 504: The CMS sends a backup information notification to the backup MN. Through the above method, the physical host is defined as the master node. Embodiment 6 FIG. 6 is a schematic diagram of a physical host assigned as a slave node according to an embodiment of the present invention. As shown in FIG. 6, the specific process is as follows: Step 601: The physical server starts, and the preset startup code sends a startup message to the CMS, where the message includes configuration information of the physical server. Step 602: The CMS determines that the physical host can join. Go to a cluster, assign it as SN, and download the SN management software and manage the address of the cluster MN; Step 603, the physical host sends a request to join the cluster to the MN; Step 4 gathers 604, the MN returns a successful response, starts the node Implementation management; Step 605: The MN notifies the CMS of the cluster information change, and the CMS updates the internal information. Through the above method, the physical host is defined as a slave node. Embodiment 7 FIG. 7 is a schematic diagram of a client applying for a virtual machine according to an embodiment of the present invention. As shown in FIG. 7, the specific process is as follows: Step 701: A client sends a virtual machine request to a CMS, where the request includes parameters of the virtual machine. Step 702: The CMS queries the most suitable MN according to the internal idle resource information. Returning the MN address; Step 703, the client initiates the allocation of the virtual machine request to the destination MN; Step 704, the MN selects an SN, the SN has sufficient free resources to allocate the virtual machine, and then sends the request to the SN; Step 705, the SN implements the allocation of the virtual machine, and returns the success information, and the return value includes the virtual machine ID. Step 706, the MN returns the success information to the client, and the client can access the virtual machine by using the virtual machine ID. Step 707, the MN notifies The CMS changes the status of the cluster managed by the MN, and the CMS updates the internal information. Further, the CMS can pre-allocate thousands of idle virtual machines as backups. When the client applies for a virtual machine, the standby virtual machine can be directly allocated to the client to reduce the allocation time. Embodiment 8 FIG. 8 is a schematic diagram of a client querying a virtual machine state according to an embodiment of the present invention. As shown in Figure 8, the specific process is as follows: Step 801: The client queries the CMS for the MN where the virtual machine is located, and the query parameter is the virtual machine ID. Step 802: The CMS returns the MN address where the virtual machine is located. Step 803: The client sends a query to the MN. The virtual machine status request is obtained. Step 804: The MN queries the SN of the virtual machine from the internal information, and sends a query virtual machine status request to the SN. Step 805: The SN acquires the virtual machine related information and returns the information to the MN. Step 806, the MN The virtual machine status information is returned to the client. Example nine

The MN monitors the virtual machine's consumption of resources on each node in real time. When a physical load is too heavy, the MN will migrate the virtual machine to other physical machines. If no suitable idle resources can be found in the cluster, the MN will The CMS applies to migrate virtual machines to other clusters. 9 is a schematic diagram of virtual machine migration across a cluster according to an embodiment of the present invention. As shown in FIG. 9, the specific process is as follows: Step 901: The MN monitors resource usage of each node. Step 902: The SN returns resource usage information. Step 903: When the resource usage reaches a preset threshold, the MN decides to migrate the virtual machine. However, the cluster managed by the MN does not have sufficient idle resources, so the CMS is requested to apply for cross-cluster scheduling. Step 904, the CMS selects the idle MN to return the MN address to the source MN. Step 905: The source MN sends a virtual machine migration request to the destination MN. Step 906, the destination MN grants migration, selects an idle SN, and returns the SN address. Step 907: The source MN sends a virtual machine migration command to the source SN, where the command parameter includes the destination SN address. Step 908: The source SN initiates a virtual machine migration process to the destination SN. Step 909, after the virtual machine migration is completed, the destination SN returns a successful response. Step 910, the source SN returns a virtual machine migration completion response to the source MN; Step 911, the destination SN returns a virtual machine migration completion response to the destination MN; Step 912, the source MN notifies the CMS that the cluster information managed by the MN is changed; Step 913; The destination MN notifies the CMS of the cluster information change managed by the MN. In summary, in the embodiment of the present invention, the virtual machine is managed by using at least three layers (the central management server, the master node, and the slave node), so that when the number of virtual machines is large, the virtual machine can also be performed. The effect of effective management. Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein. The steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps are fabricated as a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the scope of the present invention are intended to be included within the scope of the present invention.

Claims

Claim

A virtual machine management system, comprising: a central management server, a master node, and a slave node, wherein

The central management server is configured to manage the primary node;

Each of the master nodes is configured to manage one or more clusters, wherein each of the clusters includes one or more of the slave nodes;

The slave node is a physical host running a virtual machine.

2. The system of claim 1 wherein

The central management server is configured to set, when the physical host is started, the physical host that is set to be the primary node or the secondary node, and if set to the secondary node, the central management server is set to The slave node specifies a master node for management.

3. The system according to claim 2, wherein

The central management server is configured to set the activated physical host as the primary node when the management capability of the system is insufficient, and otherwise set the activated physical host as the secondary node.

4. The system of claim 1 wherein

The central management server is arranged to send management software to the primary node and to send agent software to the secondary node.

5. The system of claim 1 wherein

The central management server is further configured to set a backup primary node for the primary node when the primary node is set.

6. The system of claim 1 wherein

The master node is further configured to store management information of the clusters and slave nodes it manages; the central management server is further configured to store an index of the management information stored by each of the master nodes.

The system according to claim 6, wherein the system further comprises: a client, wherein The client is configured to query an index of the central management server, obtain a primary node corresponding to the index of the query, and send an operation request to the corresponding primary node.

8. The system of claim 1 wherein

The central management server employs a multi-layered structure, and one upper-level central management server manages one or more lower-level central management servers.

9. The system of claim 1 wherein

The master node includes: management software, configured to manage the cluster; the slave node includes:

a node agent, configured to manage the slave node, and execute a command by the virtual machine manager; the virtual machine manager, configured to schedule a virtual machine in the slave node, and execute a command sent by the node agent.

10. A method of virtual machine migration using the system of any one of claims 1 to 9, comprising:

Determining, by the master node, that a resource used by the slave node managed by the master node reaches a predetermined threshold;

Determining, by the master node, whether the slave node managed by the master node has an idle resource, and if yes, migrating the virtual machine on the slave node that uses the used resource to a predetermined threshold to the slave node that has the idle resource, Otherwise, the master node acquires a master node with idle resources from the central management server, and migrates the virtual machine on the slave node whose used resource reaches a predetermined threshold to the master node managed by the idle resource. From the node.

A method for virtual machine allocation using the system of any one of claims 1 to 9, comprising:

Receiving, by the central management server, a request for requesting a virtual machine sent by the client, allocating a primary node with the idle resource to the client, and sending the address of the allocated primary node to the client;

And the allocated primary node receives a request for allocating a virtual machine sent by the client, and allocates a slave node with an idle resource to the client;

The slave node with the idle resource allocates a virtual machine to the client.

12. A method for virtual machine query using the system of any one of claims 1 to 9, comprising:

Receiving, by the central management server, a request sent by the client to query the primary node where the virtual machine is located, and sending, to the client, an address of the primary node where the virtual machine is located;

The master node where the virtual machine is located receives the virtual machine state request sent by the client, acquires the state of the virtual machine from the slave node where the virtual machine is located, and sends the state of the virtual machine to the client. end.

13. A method of using the system of any one of claims 1 to 9, comprising:

The central management server detects that the physical host is started;

The physical host initiated by the central management server is the primary node or the secondary node.

14. The method according to claim 13, wherein

If the physical host that is started is the primary node, the central management server delivers the management software to the activated physical host, and if the activated physical host is the secondary node, the central management The server delivers the agent software to the slave node.

The method according to claim 13, wherein the central management server sets the activated physical host to be the primary node or the secondary node, including:

The central management server sets the activated physical host as the primary node when the management capability of the system is insufficient, and otherwise sets the activated physical host as the secondary node.