Computing node upgrading method and device, storage medium and electronic equipment
By screening and migrating target computing nodes that meet the criteria, and upgrading them in conjunction with virtual machine priorities, the problem of insufficient virtual machine migration decisions in heterogeneous computing environments is solved, thereby improving the resource utilization and business stability of the computing cluster system.
Patent Information
- Application Number
- CN202511079461.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-01
- Publication Date
- 2025-11-18
AI Technical Summary
In existing technologies, virtual machine migration decisions in heterogeneous computing environments lack adaptability, resulting in low operational stability, resource waste or over-allocation during computing cluster system upgrades. Furthermore, when migrating across architectures, the processing capacity of virtual machines is difficult to reach the level of the original host nodes, affecting service quality and user experience.
By selecting target compute nodes that meet the running conditions of the target virtual machines, and migrating them in combination with virtual machine priority, and upgrading them after all virtual machines have been migrated, the goal is to ensure that node resource matching and architectural differences are within an acceptable range. Dynamic scoring algorithms and real-time monitoring technology are used to optimize the migration process.
It improved resource utilization and business stability during the computing cluster upgrade process, avoided resource allocation imbalance and business processing performance degradation, and achieved efficient and stable computing cluster upgrade.
Smart Images

Figure CN120979937A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computers, and more specifically, to a method and apparatus for upgrading computing nodes, a storage medium, and an electronic device. Background Technology
[0002] With the widespread application and rapid development of cloud computing, heterogeneous computing environments, with their advantages of flexibly allocating and adapting computing resources according to different workload requirements and improving overall system computing efficiency, have made the coexistence of heterogeneous host nodes (such as ARM, x86, and FPGA architectures) a common occurrence. In heterogeneous computing environments, upgrading the computing cluster system is an inevitable process, involving critical operations such as virtual machine migration and node updates for host nodes.
[0003] In existing technologies, traditional upgrade strategies often rely on preset migration rules and static resource information to process virtual machine migration on host nodes. For example, the migration target of a virtual machine is determined based on the memory usage and CPU usage of the host node. However, this approach has significant shortcomings: on the one hand, because it does not consider real-time changes in resource status and resource differences between nodes, the migration strategy lacks precision and is prone to resource waste or over-allocation; on the other hand, cross-architecture migration does not consider the compatibility of virtual machines with host nodes of different architectures, making it difficult for the migrated virtual machine to reach the level of the original host node in terms of business processing capabilities, which in turn leads to business response delays or even interruptions, seriously affecting service quality and user experience.
[0004] There is still no effective solution to the technical problems such as insufficient adaptability of virtual machine migration decisions in related technologies, which leads to low business operation stability during the upgrade of computing cluster systems. Summary of the Invention
[0005] This application provides a method and apparatus for upgrading computing nodes, a storage medium, and an electronic device to at least solve the technical problems in related technologies, such as insufficient adaptability of virtual machine migration decisions leading to low operational stability of business during the upgrading of computing cluster systems.
[0006] According to one embodiment of the present application, a method for upgrading a computing node is provided, comprising:
[0007] Receive upgrade requests, which are used to request upgrades to the computing cluster, where virtual machines are installed on the computing nodes in the computing cluster;
[0008] In response to the upgrade request, each virtual machine is used as the target virtual machine, and the compute node where each virtual machine is located is used as the source compute node. Based on the running information of the target virtual machine and the source architecture type of the source compute node, target compute nodes that meet the running conditions of the target virtual machine are selected from the compute cluster. The running information is used to indicate the node resources required for the target virtual machine to run. The source architecture type is the architecture type that the target virtual machine is adapted to. The running conditions include: the currently allowed node resources are greater than or equal to the node resources required for the target virtual machine to run, and the architecture difference parameter between the target virtual machine and the source compute node is less than or equal to a preset threshold. The architecture difference parameter is used to indicate the degree of impact on the performance parameters of the target virtual machine when the target virtual machine is installed on compute nodes of different architecture types. The performance parameters are used to indicate the processing performance of the target virtual machine for business requests.
[0009] The virtual machines on each source compute node are migrated to the corresponding target compute node in the migration order indicated by the virtual machine priority of the compute cluster.
[0010] Once it is detected that all virtual machines installed on any reference compute node in the compute cluster have completed migration, the reference compute node is upgraded.
[0011] According to another embodiment of the present application, a computing node upgrade apparatus is also provided, comprising:
[0012] The receiving module is used to receive upgrade requests, which are used to request upgrades to the computing cluster, wherein virtual machines are installed on the computing nodes in the computing cluster.
[0013] The response module is used to respond to upgrade requests. It uses each virtual machine as the target virtual machine and the compute node where each virtual machine is located as the source compute node. Based on the running information of the target virtual machine and the source architecture type of the source compute node, it selects target compute nodes from the compute cluster that meet the running conditions of the target virtual machine. The running information indicates the node resources required for the target virtual machine to run. The source architecture type is the architecture type that the target virtual machine is adapted to. The running conditions include: the currently allowed node resources are greater than or equal to the node resources required for the target virtual machine to run, and the architecture difference parameter between the target virtual machine and the source compute node is less than or equal to a preset threshold. The architecture difference parameter indicates the degree of impact on the performance parameters of the target virtual machine when it is installed on compute nodes of different architecture types. The performance parameters indicate the processing performance of the target virtual machine for business requests.
[0014] The migration module is used to migrate virtual machines on each source compute node to the corresponding target compute node according to the migration order indicated by the virtual machine priority of the compute cluster.
[0015] The upgrade module is used to upgrade the reference compute node after detecting that all virtual machines installed on any reference compute node in the compute cluster have completed migration.
[0016] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described computing node upgrade methods when executing the computer program.
[0017] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described methods for upgrading computing nodes.
[0018] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described methods for upgrading computing nodes.
[0019] According to this application, when a computing cluster receives an upgrade request, it first designates each virtual machine as the target virtual machine and the computing node where it resides as the source computing node. Then, based on the running information of the target virtual machine and the architecture type of the source computing node, it selects target computing nodes from the computing cluster that meet the running conditions. The running conditions include: the currently allowed node resources are not less than the resources required by the target virtual machine, and the architecture difference parameter between the target virtual machine and the source computing node does not exceed a preset threshold. The architecture difference parameter can indicate the degree of impact on the performance parameters of the target virtual machine when it is installed on computing nodes of different architecture types. The performance parameter can indicate the processing performance of the target virtual machine for business requests. Subsequently, according to the migration order indicated by the virtual machine priority of the computing cluster, the virtual machines on each source computing node are migrated to the corresponding target computing node, and the computing nodes where all virtual machines have been migrated are upgraded. This method assesses the available node resources and architectural differences of current compute nodes, selecting target compute nodes from the compute cluster that simultaneously meet the resource requirements of the target virtual machines and the performance requirements of business processing. After determining the target compute node for each virtual machine, it migrates them in an orderly manner based on virtual machine priority, monitoring the migration status of virtual machines on each compute node. Once all virtual machines on any reference compute node have migrated, that compute node is upgraded. This avoids the resource allocation imbalance or business processing performance degradation that occurs after migration due to reliance on static resource information and preset rules in related technologies, thus improving resource utilization and business stability during the compute cluster upgrade process. Therefore, it solves the technical problems of insufficient adaptability in virtual machine migration decisions in related technologies, leading to low business stability during compute cluster system upgrades, and achieves the technical effect of improving the adaptability of virtual machine migration decisions, thereby improving the business stability during compute cluster system upgrades. Attached Figure Description
[0020] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0021] Figure 1 This is a hardware structure block diagram of a computer device for an upgrade method of a computing node according to an embodiment of this application.
[0022] Figure 2 This is a flowchart of a computing node upgrade method according to an embodiment of this application;
[0023] Figure 3 This is a schematic diagram of a computing cluster upgrade process according to an embodiment of this application;
[0024] Figure 4 This is a structural block diagram of a computing node upgrade device according to an embodiment of this application;
[0025] Figure 5 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation
[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.
[0027] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.
[0028] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0029] The methods and embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1This is a hardware structure block diagram of a computer device for an upgrade method of a computing node according to an embodiment of this application. Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.
[0030] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the computing node upgrade method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0031] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.
[0032] This embodiment provides a method for upgrading computing nodes. Figure 2 This is a flowchart of a computing node upgrade method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:
[0033] Step S12: Receive an upgrade request. The upgrade request is used to request an upgrade to the computing cluster, wherein virtual machines are installed on the computing nodes in the computing cluster.
[0034] Optionally, in this embodiment, the upgrade process may be triggered by, but is not limited to, an automated system, an operation and maintenance script, or human operation: the upgrade package is uploaded and a system upgrade command (equivalent to an upgrade request) is issued through the management platform of the homogeneous heterogeneous virtualization system (equivalent to a computing cluster). The computing cluster receives and verifies the upgrade package through a secure API (Application Programming Interface). After ensuring the integrity of the upgrade file by using a digital signature, the specific information containing the computing cluster version upgrade or the addition of new features is obtained from the upgrade file. The upgrade command is broadcast to all computing nodes in the cluster through a distributed message queue, thereby initiating the upgrade process for the computing nodes in the cluster. A globally unique transaction ID (Identifier) is generated for full-process tracking to ensure the secure and reliable transmission of the upgrade command and full-link traceability.
[0035] Optionally, in this embodiment, the computing cluster can be, but is not limited to, a cluster of physical devices with different architecture types such as ARM (Advanced RISC Machines), x86 (a general term for a complex instruction set architecture), and FPGA (Field-Programmable Gate Array). Examples include server clusters in data centers and heterogeneous computing node clusters in cloud computing platforms. This embodiment uses a homogeneous heterogeneous virtualization system as an example, which does not limit the type of computing cluster described above. A computing node can be, but is not limited to, a physical device in the computing cluster used to host virtual machines and provide computing resources, such as a host or server. One or more virtual machines are installed on each computing node to handle business requests, and each virtual machine can process one or more business requests.
[0036] Step S14: In response to the upgrade request, each virtual machine is used as the target virtual machine, and the compute node where each virtual machine is located is used as the source compute node. Target compute nodes that meet the running conditions of the target virtual machine are selected from the compute cluster based on the running information of the target virtual machine and the source architecture type of the source compute node. The running information indicates the node resources required for the target virtual machine to run, the source architecture type is the architecture type adapted to the running of the target virtual machine, and the running conditions include: the currently allowed node resources are greater than or equal to the node resources required for the running of the target virtual machine, and the architecture difference parameter between the target virtual machine and the source compute node is less than or equal to a preset threshold. The architecture difference parameter indicates the degree of impact on the performance parameters of the target virtual machine when the target virtual machine is installed on compute nodes of different architecture types. The performance parameters indicate the processing performance of the target virtual machine for business requests.
[0037] Optionally, in this embodiment, when responding to an upgrade request, the computing cluster traverses multiple computing nodes to identify all running virtual machines and their current source computing node. The target virtual machine can be, but is not limited to, any one of the multiple running virtual machines. For each target virtual machine, its resource requirements (equivalent to runtime information) are checked, including the number of CPU cores (Central Processing Unit), memory size, storage requirements, and network bandwidth. Then, computing nodes with currently available resources greater than or equal to the target virtual machine's requirements are selected from a resource database that records the real-time node resources and architecture type information of each computing node. Real-time node resources can be, but are not limited to, the available CPU cores, remaining memory capacity, storage I / O (Input / Output) bandwidth availability, hardware accelerator resource availability, and other resource availability information. Architecture type information can be, but is not limited to, the architecture type of the computing node, such as one of several hardware architecture types like ARM, x86, or FPGA. For the selected compute nodes, the architectural difference parameters between these compute nodes and the source compute node of the target virtual machine are further evaluated. If the architectural difference parameters are less than or equal to a preset threshold, the compute node is considered a candidate compute node for migration to the target virtual machine. This process, by combining resource matching and architectural compatibility as dual screening methods, ensures that the virtual machine is migrated to the target node that can meet resource requirements while keeping cross-architecture performance loss within an acceptable range, thus achieving intelligent resource scheduling in a homogeneous but heterogeneous environment.
[0038] Optionally, in this embodiment, selecting target computing nodes that meet the operating conditions of the target virtual machine from the computing cluster based on the running information of the target virtual machine and the source architecture type of the source computing node may include, but is not limited to: constructing a candidate list of computing nodes for the target virtual machine based on the selected candidate computing nodes that meet the resource requirements and architecture difference parameters; using a dynamic scoring algorithm to score the candidate computing nodes in the candidate list, considering factors such as resource matching, architecture difference, and the load of the computing nodes; sorting the candidate computing nodes in the candidate list according to the scores; and selecting the candidate computing node with the highest score as the target computing node.
[0039] Step S16: Migrate the virtual machines on each source compute node to the corresponding target compute node according to the migration order indicated by the virtual machine priority of the compute cluster.
[0040] Optionally, in this embodiment, the migration order of the target virtual machine can be determined according to the virtual machine priority corresponding to the target virtual machine. The virtual machine priority can be, but is not limited to, a priority assigned to the virtual machine based on the importance of the business request currently being processed by the virtual machine. For example, the virtual machine priority corresponding to the virtual machine that processes core transaction business has a higher priority than the virtual machine priority corresponding to the virtual machine that processes ordinary logs.
[0041] Step S18: If it is detected that all virtual machines installed on any reference computing node in the computing cluster have completed migration, upgrade the reference computing node.
[0042] Optionally, in this embodiment, taking a heterogeneous computing cluster in a data center as an example, the cluster contains multiple computing nodes based on ARM and x86 architectures. One reference computing node (ARM architecture) runs three virtual machines, which respectively host the core transaction system, log analysis service, and caching service. When the upgrade process is triggered, the system first performs resource assessment and migration planning on these three virtual machines. After confirming through real-time monitoring that they have all been successfully migrated to the adapted target computing node, the system performs upgrade operations on the reference computing node. For example, through a pre-deployed upgrade script, it automatically completes the replacement of the old and new virtualization management programs (the new version supports new hardware instruction sets); it synchronously updates the firmware to a version compatible with the latest architecture extensions; and it refreshes the hardware drivers to optimize the performance of the GPU (Graphics Processing Unit) accelerator and high-speed network interface.
[0043] Optionally, in this embodiment, during the upgrade process of the computing node, the system monitors the power status, temperature sensor data and hardware self-test results of the computing node in real time to ensure that the upgrade operation will not damage the hardware of the computing node. After all upgrade steps are completed and the self-test is passed, the computing node automatically restarts and rejoins the computing cluster, entering an idle state with resources to be allocated.
[0044] Optionally, in this embodiment, by dynamically evaluating the virtual machine's operational requirements and the resource status of computing nodes, combined with architecture compatibility analysis, the optimal target computing node can be intelligently selected, enabling efficient virtual machine migration. For example, for a virtual machine running on an x86 architecture, if there are ARM architecture computing nodes in the computing cluster, the decision to migrate can be made by evaluating architecture difference parameters (such as performance loss). This approach not only improves resource scheduling efficiency but also ensures business continuity and performance stability, solving the migration failure problem caused by resource mismatch and architecture differences during traditional upgrades. By combining technical features such as virtual machine running information, architecture type matching, and resource and performance parameter evaluation, intelligent and automated computing cluster upgrades are achieved, solving problems such as resource scheduling difficulties, low virtual machine migration success rates, and high business interruption risks faced during traditional computing cluster upgrades, thereby improving upgrade efficiency and resource utilization.
[0045] This application evaluates the currently allowed node resources and architectural differences of computing nodes to select target computing nodes from the computing cluster that simultaneously meet the resource requirements of the target virtual machines and the performance requirements of business processing. After determining the target computing node for each virtual machine, it performs orderly migration based on virtual machine priority and monitors the migration status of virtual machines on each computing node. Only after all virtual machines on any reference computing node have been migrated is the computing node upgraded. This avoids the resource allocation imbalance or business processing performance degradation that occurs after migration due to reliance on static resource information and preset rules in related technologies, thus improving resource utilization and business stability during the computing cluster upgrade process. Therefore, it solves the technical problems of insufficient adaptability in virtual machine migration decisions in related technologies, leading to low business operation stability during computing cluster system upgrades, and achieves the technical effect of improving the adaptability of virtual machine migration decisions, thereby improving the business operation stability during computing cluster system upgrades.
[0046] As an optional approach, target computing nodes that meet the running conditions of the target virtual machine are selected from the computing cluster based on the target virtual machine's runtime information and the source architecture type of the source computing nodes, including:
[0047] S21. Based on the running information, detect the resource matching parameters of each computing node in the computing cluster, and based on the source architecture type, detect the performance matching parameters of each computing node in the computing cluster. The resource matching parameters are used to indicate the degree of matching between the node resources currently allowed to be used by the corresponding computing node and the node resources required for the target virtual machine to run. The larger the resource matching parameters, the higher the degree of matching between the node resources currently allowed to be used by the corresponding computing node and the node resources required for the target virtual machine to run. The performance matching parameters are used to indicate the degree of matching between the architecture type of the corresponding computing node and the source architecture type. The larger the performance matching parameters, the smaller the difference between the architecture of the corresponding computing node and the source computing node, and the smaller the impact on the performance parameters of the target virtual machine when the target virtual machine is installed on the corresponding computing node.
[0048] S22, based on the resource matching parameters and performance matching parameters of each computing node, select the target computing nodes from the computing cluster that meet the running conditions of the target virtual machine.
[0049] Optionally, in this embodiment, based on the node resources required by the target virtual machine, the resource matching parameters of each computing node are obtained by detecting the degree of matching between the current idle resources of each computing node in the computing cluster and the resources required by the target virtual machine. The larger the resource matching parameter, the higher the resource matching degree between the computing node and the target virtual machine. At the same time, combined with the source architecture type of the source computing node, the performance matching parameters of each computing node are obtained by detecting the degree of matching between the architecture type of each computing node and the source architecture type. The larger the performance matching parameter, the smaller the architecture difference between the computing node and the source computing node, and the smaller the impact on the virtual machine performance after migration. Then, based on the resource matching parameters and performance matching parameters of each computing node, nodes that simultaneously meet the resource and performance matching requirements are selected from the computing cluster as target computing nodes.
[0050] As an optional approach, resource matching parameters for each computing node in the computing cluster are detected based on runtime information, including:
[0051] S31, detect the component resource information of each computing node and obtain the resource requirement information in the running information. The component resource information records the component resource parameters of each execution component among multiple execution components in the computing node. The component resource parameters are used to indicate the amount of resources that the corresponding execution component is currently allowed to use. The resource requirement information records the resource requirement parameters of each execution component among one or more execution components required for the target virtual machine to run. The resource requirement parameters are used to indicate the amount of resources that the target virtual machine needs to use for the corresponding execution component to run.
[0052] S32 generates resource matching parameters for computing nodes based on resource requirement information and component resource information.
[0053] Optionally, in this embodiment, the execution component may be, but is not limited to, a hardware unit in the computing node that carries resources, such as: CPU cores, memory modules, storage controllers, network interfaces, etc. Component resource information may, but is not limited to, recording the real-time resource status of each execution component in the computing node, such as the available computing power of the CPU core (in GHz), the free capacity of the memory module (in GB), the available I / O operations per second of the storage controller, and the remaining bandwidth of the network interface (in Mbps), etc. Resource requirement information may, but is not limited to, recording the resource quantities of various execution components required for the target virtual machine to run, such as the virtual machine requiring 2 CPU cores, 8GB of memory, and 500Mbps of network bandwidth, etc.
[0054] Optionally, in this embodiment, the step of generating resource matching parameters for computing nodes based on resource requirement information and component resource information can be, but is not limited to, the following: By calculating the ratio of the resource requirement parameters of each execution component in the resource requirement information of the target virtual machine to the component resource parameters of the corresponding execution components of each computing node, the resource ratio of each execution component is obtained, and the minimum value among the resource ratios of multiple execution components is determined as the resource matching parameter of the computing node. For example, if the target virtual machine carrying the transaction system requires 4 CPU cores (CPU resource requirement parameters), 16GB memory (memory module resource requirement parameters), and 500Mbps network bandwidth (network interface resource requirement parameters), and a node in the computing cluster currently has 4 idle CPU cores (CPU component resource parameters), 20GB memory (memory module component resource parameters), and 600Mbps bandwidth (network interface component resource parameters), then based on the resource ratios of each execution component (CPU: 4 / 4 = 1.0, memory module: 20 / 16 = 1.25, network interface: 600 / 500 = 1.2), the minimum value of 1.0 is taken as the resource matching parameter of the node.
[0055] Optionally, in this embodiment, by comparing specific resource quantities, the matching degree between the current idle resources of each computing node in the computing cluster and the resources required by the target virtual machine is quantified, thereby achieving accurate evaluation of resource scheduling. This ensures that the selected target computing nodes can fully meet the resource requirements of the virtual machine, avoids performance bottlenecks or migration failures caused by insufficient resources, and improves the resource allocation efficiency and business stability during the computing cluster upgrade process.
[0056] As an optional approach, performance matching parameters for each compute node in the compute cluster are detected based on the source architecture type, including:
[0057] S41, using each computing node as a reference computing node, detect the architecture type of the reference computing node to obtain the node architecture type;
[0058] S42, Match the reference loss parameter corresponding to the source architecture type and node architecture type from the first architecture type, second architecture type and loss parameter with corresponding relationship, wherein the loss parameter is used to indicate the degree of performance parameter degradation when the virtual machine adapted to the first architecture type is installed on the compute node of the second architecture type;
[0059] The performance matching parameters for each computing node are determined based on the reference loss parameters of each computing node.
[0060] Optionally, in this embodiment, before matching the reference loss parameter corresponding to the source architecture type and node architecture type from the corresponding first architecture type, second architecture type, and loss parameter, the process includes: acquiring historical virtual machine migration data, which records the migration architecture of the historical virtual machine migration as "computing node architecture type before migration (first architecture type) → computing node architecture type after migration (second architecture type)" and the performance change data of the virtual machine after migration, such as the percentage decrease in throughput, the increase in response latency, and the extension of task processing time; classifying all the collected migration data according to the migration architecture type combination, for example, collecting the performance data of different migration paths such as "X86→ARM", "ARM→X86", and "X86→X86" respectively, and associating them with the corresponding business type (such as compute-intensive and read-write-intensive). For different business types within the same architecture type combination, the average performance loss is calculated separately. For example, in the "X86→ARM" path, historical migration data for compute-intensive businesses shows an average throughput loss of 25% and a 20% increase in task processing time, while read-write-intensive businesses show an average throughput loss of 15% and a 10% increase in response latency. The comprehensive loss parameters for each type of business are then recorded separately. Finally, the first architecture type, the second architecture type, the business type, and the corresponding loss parameters are stored in a pre-defined mapping table, forming a structured correspondence database. Simultaneously, a dynamic update mechanism is set up so that when a new migration operation is completed, performance loss data is automatically extracted and updated in the database, ensuring that the loss parameters reflect the latest architecture compatibility status and providing accurate data support for subsequent reference loss parameter matching.
[0061] Optionally, in this embodiment, the step of determining the performance matching parameter of each computing node based on the reference loss parameter of each computing node can be, but is not limited to, taking the difference between 1 and the reference loss parameter to obtain the performance matching parameter. For example, if the architecture type of the source computing node is X86 (source architecture type), and the architecture type of a node in the computing cluster is X86 (node architecture type), and the processing time of the task corresponding to the "X86→ARM" path is found to increase by 15% (reference loss parameter) from the pre-established relationship table, the performance matching parameter obtained by taking the difference between 1 and the reference loss parameter is 0.85.
[0062] Optionally, in this embodiment, by constructing a structured correspondence database, the system can accurately match performance loss data under different architecture migration paths, providing a reliable historical reference for virtual machine migration, avoiding performance evaluation deviations caused by architecture differences, and combining business type classification to calculate loss parameters, making the performance loss parameters more in line with actual business scenarios. For example, it can distinguish the loss differences between compute-intensive and read-write-intensive businesses, making the evaluation results more targeted. In addition, by converting "1-reference loss parameter" to obtain performance matching parameters, the abstract loss data is transformed into intuitive quantitative indicators, which facilitates the rapid selection of target computing nodes whose performance impact is within an acceptable range. At the same time, the dynamic update mechanism ensures data timeliness, further improving the accuracy and reliability of virtual machine migration in heterogeneous computing clusters, and ensuring the overall stability of business after migration.
[0063] As an optional approach, target computing nodes that meet the running conditions of the target virtual machine are selected from the computing cluster based on the resource matching parameters and performance matching parameters of each computing node, including:
[0064] S51, detect the resource weight and performance weight of the target virtual machine. The resource weight is used to indicate the degree of dependence of the target virtual machine on node resources when processing business requests, and the performance weight is used to indicate the degree of dependence of the target virtual machine on the performance parameters of the target virtual machine when processing business requests.
[0065] S52, the product of the resource matching parameters and resource weights of each computing node is determined as the first product of each computing node, and the product of the performance matching parameters and performance weights of each computing node is determined as the second product of each computing node. The larger the first product, the higher the matching degree between the corresponding computing node and the node resources of the target virtual machine. The larger the second product, the smaller the influence of the corresponding computing node on the performance parameters of the target virtual machine.
[0066] S53, perform addition on the first and second products of each computing node to generate the node matching parameters for each computing node;
[0067] S54: Based on the node matching parameters of each computing node, select the computing node with the largest node matching parameters from the computing cluster as the target computing node.
[0068] Optionally, in this embodiment, the step of selecting target computing nodes from the computing cluster that meet the operating conditions of the target virtual machine based on the resource matching parameters and performance matching parameters of each computing node can be, but is not limited to, the following: First, detect the resource weight and performance weight of the target virtual machine. The resource weight reflects the degree of dependence of the target virtual machine on node resources when processing business requests, and the performance weight reflects the degree of dependence of the target virtual machine on its own performance parameters when processing business requests. For example, a virtual machine carrying a transaction system has high requirements for resource stability, so its resource weight is 0.6, and it is sensitive to performance fluctuations, so its performance weight is 0.4. Then, the product of the resource matching parameters and resource weight of each computing node is taken as the first product, and the product of the performance matching parameters and performance weight is taken as the second product. The larger the first product, the higher the degree of matching between the node resources and the virtual machine. The larger the second product, the smaller the impact of the node on the performance of the virtual machine. Then, add the first product and the second product of each computing node to obtain the node matching parameters. Finally, select the computing node with the largest node matching parameters from the computing cluster as the target computing node to ensure that the selected node can optimally adapt to the business needs of the virtual machine.
[0069] Optionally, in this embodiment, selecting target computing nodes that meet the running conditions of the target virtual machine from the computing cluster based on the resource matching parameters and performance matching parameters of each computing node may include, but is not limited to: selecting one or more reference computing nodes from the computing cluster whose resource matching parameters are greater than or equal to the resource matching threshold; and selecting target computing nodes that meet the running conditions of the target virtual machine from one or more reference computing nodes based on the resource matching parameters and performance matching parameters of one or more reference computing nodes.
[0070] Optionally, in this embodiment, the resource matching threshold can be, but is not limited to, set to 1. This ensures that all critical resources required for virtual machine operation are met, preventing performance bottlenecks caused by any unmet resource requirements of any execution component (i.e., the ratio of the resource requirement parameter of an execution component to its resource parameter is less than 1). For example, if the CPU resource ratio is 0.8 (i.e., the actual available resources are lower than the requirement), even if memory and network bandwidth resources are abundant, the virtual machine will still experience lag due to insufficient CPU resources. Setting the resource matching threshold filters one or more reference computing nodes from the computing cluster whose resource matching parameters are greater than or equal to the resource matching threshold, thus ensuring that all execution components of the reference computing node meet their resource requirements.
[0071] Optionally, in this embodiment, the step of selecting a target computing node that meets the running conditions of the target virtual machine from one or more reference computing nodes based on the resource matching parameters and performance matching parameters of one or more reference computing nodes may include, but is not limited to, the following: First, detect the resource weight and performance weight of the target virtual machine. The resource weight reflects the degree of dependence of the target virtual machine on node resources when processing business requests, and the performance weight reflects the degree of dependence of the target virtual machine on its own performance parameters when processing business requests. Then, multiply the resource matching parameters and resource weights of each reference computing node as the third product, and multiply the performance matching parameters and performance weights as the fourth product. The larger the third product, the higher the degree of matching between the node resources and the virtual machine; the larger the fourth product, the smaller the impact of the node on the performance of the virtual machine. Then, add the third and fourth products of each reference computing node to obtain the node matching parameters of each reference computing node. Finally, select the reference computing node with the largest node matching parameters from each candidate computing node as the target computing node, thereby ensuring that the selected node can optimally adapt to the business needs of the virtual machine.
[0072] As an optional approach, virtual machines on each source compute node are migrated to the corresponding target compute node according to the migration order indicated by the virtual machine priority of the compute cluster, including:
[0073] S61, detect the service type of the service request currently being processed by each virtual machine, and obtain the virtual machine priority of each virtual machine. The service type is used to indicate the importance of the service request being processed by the virtual machine. The virtual machine priority corresponding to the virtual machine that processes important service requests is higher than the virtual machine priority corresponding to the virtual machine that processes non-important service requests.
[0074] S62, generate multiple migration instructions to be executed with a target execution order based on the virtual machine priority of multiple virtual machines and the target compute node, wherein the migration instructions are used to migrate the virtual machines on each source compute node to the corresponding target compute node;
[0075] S63 executes multiple migration instructions in the order of the target execution.
[0076] Optionally, in this embodiment, migration instructions with a target execution order are generated based on the priority of each virtual machine and its corresponding target compute node. These migration instructions can be, but are not limited to, operation commands carrying the virtual machine to be migrated, its corresponding source compute node, and the target compute node. Migration instructions for virtual machines with higher priority are given priority. Finally, these migration instructions are executed sequentially according to the target execution order, ensuring that virtual machines with higher priority complete the migration first, minimizing the risk of interruption to critical services due to migration.
[0077] Optionally, in this embodiment, the migration order of the target virtual machine can be determined by combining the virtual machine priority and other virtual machines on the same source compute node: first, the migration batches are divided according to the virtual machine priority (e.g., important business virtual machines are prioritized), and virtual machines with higher priority are assigned to earlier batches; within the same batch, virtual machines originating from the same source compute node are arranged together, that is, virtual machines on the same source compute node are arranged to migrate within the same time period. By determining the migration order in the above way, the overall upgrade time of the compute cluster can be effectively saved. On the one hand, migrating virtual machines in batches according to priority ensures that important business requests are responded to first, avoiding delays in the migration of virtual machines that process important business requests due to non-important business requests occupying resources; on the other hand, centralized migration within the same batch according to the source compute node can reduce the repeated resource scheduling (such as network connection establishment, storage mapping configuration, etc.) on a single source compute node, reducing the loss of frequent node state switching caused by decentralized migration. While ensuring business stability, by reducing redundant operations and resource scheduling conflicts, the virtual machine migration cycle is significantly compressed, thereby shortening the upgrade time of the compute cluster.
[0078] As an optional approach, multiple migration instructions are executed in the order of the target execution, including:
[0079] S71, detect the execution progress of each migration instruction among multiple migration instructions, wherein the execution progress is used to indicate whether the virtual machine corresponding to the migration instruction is running normally on the target compute node;
[0080] S72, when it is detected that the execution progress of the migration instructions corresponding to the virtual machines on the same reference compute node all exceed the target progress, it is determined that the virtual machines installed on the reference compute node have all completed the migration.
[0081] Optionally, in this embodiment, the success of virtual machine migration can be determined by monitoring indicators such as the virtual machine's process startup status, service port connectivity, core function response time, and log status. For any computing node in the computing cluster (reference computing node), when it is detected that the execution progress of migration instructions corresponding to all its virtual machines exceeds the preset target progress (e.g., the virtual machine has completed startup and successfully processed one round of service requests), it can be determined that all virtual machines installed on the reference computing node have completed migration. In this way, the status of a single migration task can be tracked in real time, and the completion status of virtual machine migration on a single computing node can be determined.
[0082] Optionally, in this embodiment, after confirming that all virtual machines installed on the reference compute node have completed migration, the management platform calls the upgrade interface and sends upgrade instructions to the reference compute node through a distributed message queue to execute the upgrade operations of the node firmware and virtualization layer. During the upgrade process of the reference compute node, the management platform tracks the progress through a global transaction ID, monitors the execution status of the upgrade script in real time, and automatically performs compatibility testing (such as verification of the adaptability of the virtualization layer and the new firmware) after the upgrade is completed. Once confirmed to be error-free, the reference compute node is marked as "upgrade complete" and included in the subsequent resource scheduling pool.
[0083] In this embodiment, key technologies such as dynamic dirty page control, context snapshots, and flow table pre-configuration are employed during online migration. This ensures a smooth, seamless migration without the business being aware of the changes, maximizing service continuity while strictly controlling concurrency and bandwidth usage. Simultaneously, a comprehensive monitoring system encompassing business metrics, resource status, and migration progress is established. Based on real-time data, the migration rate and target nodes are dynamically adjusted, forming a closed-loop optimization mechanism of perception, decision-making, and execution, ensuring the upgrade process remains in an optimal state at all times.
[0084] Optionally, in this embodiment, if the execution progress of the migration instruction corresponding to a virtual machine is detected to have failed to reach the target progress within a preset time period, the virtual machine migration is determined to have failed, triggering a rollback mechanism to pause the upgrade process and re-execute the migration, ensuring that the reference computing node enters the upgrade phase only after the virtual machine migration is successful, thus guaranteeing the security and business continuity of the upgrade process.
[0085] Optionally, in this embodiment, in order to better understand the upgrade process of the computing node, the upgrade process of the computing node will be described below in conjunction with optional embodiments, but this is not intended to limit the technical solution of the embodiments of this application.
[0086] This embodiment provides a method for upgrading computing nodes. Figure 3 This is a schematic diagram of a computing cluster upgrade process according to an embodiment of this application, such as... Figure 3 As shown, the main steps include the following:
[0087] Step S301: Upgrade command issued. The upgrade package is uploaded and the system upgrade command is issued through the management platform of the homogeneous virtualization system by the automated system, operation and maintenance script or manual operation, and then step S302 is executed;
[0088] Step S302: The homogeneous virtualization system receives the upgrade command and executes step S303;
[0089] Step S303: Resource Status Monitoring and Collection. Deploy a high-efficiency monitoring agent based on kernel virtual machine technology to collect real-time data on CPU microarchitecture metrics, memory status, accelerator resources, and other comprehensive data for each computing node in the computing cluster, as well as the running information of each virtual machine, with less than 5% CPU overhead. The sampling frequency can be dynamically adjusted to provide accurate real-time resource profiles for subsequent decision-making. Execute step S304.
[0090] Step S304: Obtain the list of candidate hosts for virtual machines to be migrated from the computing cluster, and proceed to step S305;
[0091] Step S305: Cost Calculation. Establish a multi-dimensional evaluation system that includes architecture compatibility (equivalent to architecture difference parameters), resource matching degree (equivalent to resource matching parameters), and network topology. First, use a graded evaluation strategy to screen candidate nodes that meet the hard constraints and remove unusable hosts (equivalent to compute nodes), such as compute nodes that do not meet the node resources required for virtual machine operation. Then, perform fine-grained scoring on the nodes that meet the conditions and proceed to step S306.
[0092] Step S306: Hosts with migration costs less than the threshold. Select hosts with migration costs lower than the set threshold from the cost calculation results as priority migration targets, and proceed to step S307;
[0093] Step S307: Sequential Host Migration Test. Taking into account business priorities, resource dependencies, and load balancing requirements, the optimal upgrade sequence is intelligently generated, and the upgrade plan is visually displayed through a roadmap to ensure that the impact on critical businesses is minimized and resource utilization is optimized. Then, virtual machine migration is carried out, and step S308 is executed.
[0094] Step S308: Test migration fluctuations: During the host migration test, monitor the fluctuations caused by the migration. If the host migration test and related fluctuation monitoring pass, the migration is confirmed to be successful and step S311 is executed; otherwise, step S309 is executed.
[0095] Step S309: Trigger rollback. A multi-level fault detection system is built through heartbeat detection and performance monitoring. Once an anomaly is detected, an emergency plan including phased rollback, automatic resource release, and complete log recording is immediately triggered to ensure the system can quickly recover to a stable state under any abnormal situation. Then proceed to step S310.
[0096] Step S310: Virtual machine shutdown and upgrade. Shut down the virtual machine and perform the compute node upgrade operation, then proceed to step S311;
[0097] Step S311: Host upgrade successful. Compute node upgrade complete.
[0098] Through the above steps, for homogeneous heterogeneous virtualization systems containing heterogeneous computing nodes such as ARM, X86, and FPGA, the available resources of each node, such as CPU, memory, storage, network, and accelerator, are calculated in real time during the upgrade process. Combined with the current resource utilization of virtual machines, the performance loss model of cross-architecture migration, and the idle ratio of cross-architecture resources, the optimal migration target node is dynamically evaluated and selected. By comparing the loss model of heterogeneous architecture resources and migration loss, the upgrade migration is no longer limited to migration between hosts of the same architecture. It realizes intelligent scheduling and rebalancing of virtual machine resources during the upgrade process, ensuring that the resource utilization is optimized while maintaining service continuity during system upgrade.
[0099] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.
[0100] Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.
[0101] This embodiment also provides a computing node upgrade device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0102] Figure 4 This is a structural block diagram of a computing node upgrade device according to an embodiment of this application; as shown... Figure 4 As shown, it includes:
[0103] The receiving module 402 is used to receive an upgrade request, which requests an upgrade to the computing cluster, wherein virtual machines are installed on the computing nodes in the computing cluster.
[0104] The response module 404 is used to respond to upgrade requests. It uses each virtual machine as the target virtual machine and the compute node where each virtual machine is located as the source compute node. Based on the running information of the target virtual machine and the source architecture type of the source compute node, it selects target compute nodes from the compute cluster that meet the running conditions of the target virtual machine. The running information indicates the node resources required for the target virtual machine to run. The source architecture type is the architecture type that the target virtual machine is adapted to. The running conditions include: the currently allowed node resources are greater than or equal to the node resources required for the target virtual machine to run, and the architecture difference parameter between the target virtual machine and the source compute node is less than or equal to a preset threshold. The architecture difference parameter indicates the degree of impact on the performance parameters of the target virtual machine when the target virtual machine is installed on compute nodes of different architecture types. The performance parameters indicate the processing performance of the target virtual machine for business requests.
[0105] Migration module 406 is used to migrate virtual machines on each source compute node to the corresponding target compute node according to the migration order indicated by the virtual machine priority of the compute cluster.
[0106] Upgrade module 408 is used to upgrade the reference compute node when it is detected that all virtual machines installed on any reference compute node in the compute cluster have completed migration.
[0107] In one exemplary embodiment, the response module includes:
[0108] The first detection unit is used to detect the resource matching parameters of each computing node in the computing cluster based on the running information, and to detect the performance matching parameters of each computing node in the computing cluster based on the source architecture type. The resource matching parameters are used to indicate the degree of matching between the node resources currently allowed to be used by the corresponding computing node and the node resources required for the target virtual machine to run. The larger the resource matching parameters, the higher the degree of matching between the node resources currently allowed to be used by the corresponding computing node and the node resources required for the target virtual machine to run. The performance matching parameters are used to indicate the degree of matching between the architecture type of the corresponding computing node and the source architecture type. The larger the performance matching parameters, the smaller the difference between the architecture of the corresponding computing node and the source computing node, and the smaller the impact on the performance parameters of the target virtual machine when the target virtual machine is installed on the corresponding computing node.
[0109] The first screening unit is used to select target computing nodes from the computing cluster that meet the running conditions of the target virtual machine based on the resource matching parameters and performance matching parameters of each computing node.
[0110] In one exemplary embodiment, the first detection unit is further configured to:
[0111] The component resource information of each computing node is detected, and the resource requirement information in the running information is obtained. The component resource information records the component resource parameters of each of the multiple execution components in the computing node. The component resource parameters are used to indicate the amount of resources that the corresponding execution component is currently allowed to use. The resource requirement information records the resource requirement parameters of each of the one or more execution components required for the target virtual machine to run. The resource requirement parameters are used to indicate the amount of resources that the target virtual machine needs to use for the corresponding execution component to run.
[0112] Resource matching parameters for computing nodes are generated based on resource requirement information and component resource information.
[0113] In one exemplary embodiment, the first detection unit is further configured to:
[0114] Using each computing node as a reference computing node, the architecture type of the reference computing node is detected to obtain the node architecture type;
[0115] From the first architecture type, the second architecture type, and the loss parameters that have a corresponding relationship, a reference loss parameter corresponding to the source architecture type and the node architecture type is matched. The loss parameter is used to indicate the degree of performance parameter degradation when a virtual machine adapted to the first architecture type is installed on a compute node of the second architecture type.
[0116] The performance matching parameters for each computing node are determined based on the reference loss parameters of each computing node.
[0117] In one exemplary embodiment, the first filtering unit includes:
[0118] The second detection unit is used to detect the resource weight and performance weight of the target virtual machine. The resource weight is used to indicate the degree of dependence of the target virtual machine on node resources when processing business requests, and the performance weight is used to indicate the degree of dependence of the target virtual machine on the performance parameters of the target virtual machine when processing business requests.
[0119] The determining unit is used to determine the first product of the resource matching parameters and resource weights of each computing node as the first product of each computing node, and to determine the second product of the performance matching parameters and performance weights of each computing node as the second product of each computing node. The larger the first product, the higher the matching degree between the corresponding computing node and the node resources of the target virtual machine. The larger the second product, the smaller the influence of the corresponding computing node on the performance parameters of the target virtual machine.
[0120] The first execution unit is used to perform an addition operation on the first product and the second product of each computing node to generate the node matching parameters of each computing node;
[0121] The second filtering unit is used to filter the computing node with the largest node matching parameter from the computing cluster as the target computing node based on the node matching parameter of each computing node.
[0122] In one exemplary embodiment, the migration module includes:
[0123] The third detection unit is used to detect the service type of the service request currently being processed by each virtual machine and obtain the virtual machine priority of each virtual machine. The service type is used to indicate the importance of the service request being processed by the virtual machine. The virtual machine priority corresponding to the virtual machine that processes important service requests is higher than the virtual machine priority corresponding to the virtual machine that processes non-important service requests.
[0124] The generation unit is used to generate multiple migration instructions to be executed with a target execution order based on the virtual machine priorities of multiple virtual machines and the target compute node. The migration instructions are used to migrate the virtual machines on each source compute node to the corresponding target compute node.
[0125] The second execution unit is used to execute multiple migration instructions in the order of the target execution.
[0126] In one exemplary embodiment, the second execution unit is further configured to:
[0127] The execution progress of each migration instruction among multiple migration instructions is monitored, where the execution progress is used to indicate whether the virtual machine corresponding to the migration instruction is running normally on the target compute node;
[0128] When the execution progress of migration instructions for virtual machines on the same reference compute node exceeds the target progress, it is determined that all virtual machines installed on the reference compute node have completed migration.
[0129] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.
[0130] For a description of the features in the embodiment corresponding to the computing node upgrade device, please refer to the relevant description in the embodiment corresponding to the computing node upgrade method, which will not be repeated here.
[0131] Embodiments of this application also provide an electronic device. Figure 5 This is a schematic diagram of an electronic device according to an embodiment of this application, such as... Figure 5 As shown, the electronic device includes a memory and a processor, the memory storing a computer program, and the processor being configured to run the computer program to perform the steps in any of the above embodiments of the computing node upgrade method.
[0132] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.
[0133] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.
[0134] Embodiments of this application also provide a computer-readable storage medium storing a computer program configured to execute the steps in any of the above embodiments of the computing node upgrade method when running.
[0135] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0136] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0137] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the methods in various embodiments of this application; the computer program product further includes a non-volatile computer-readable storage medium storing the computer program, which, when executed by a processor, implements the steps of the computing node upgrade method in various embodiments of this application.
[0138] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0139] The above provides a detailed description of a computing node upgrade method provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.
Claims
1. A method for upgrading a computing node, characterized in that, include: Receive an upgrade request, the upgrade request being used to request an upgrade to the computing cluster, wherein virtual machines are installed on the computing nodes in the computing cluster; In response to the upgrade request, each virtual machine is designated as the target virtual machine, and the compute node where each virtual machine resides is designated as the source compute node. Based on the running information of the target virtual machine and the source architecture type of the source compute node, target compute nodes that meet the running conditions of the target virtual machine are selected from the compute cluster. The running information indicates the node resources required for the target virtual machine to run, the source architecture type is the architecture type adapted to the target virtual machine's operation, and the running conditions include: the currently allowed node resources are greater than or equal to the node resources required for the target virtual machine to run, and the architecture difference parameter between the target virtual machine and the source compute node is less than or equal to a preset threshold. The architecture difference parameter indicates the degree of impact on the performance parameters of the target virtual machine when it is installed on compute nodes of different architecture types. The performance parameters indicate the processing performance of the target virtual machine for business requests. The virtual machines on each of the source compute nodes are migrated to the target compute node corresponding to the virtual machine in the migration order indicated by the virtual machine priority of the compute cluster. If it is detected that all virtual machines installed on any reference computing node in the computing cluster have completed migration, the reference computing node is upgraded.
2. The method according to claim 1, characterized in that, The step of selecting target computing nodes from the computing cluster that meet the running conditions of the target virtual machine based on the running information of the target virtual machine and the source architecture type of the source computing node includes: The resource matching parameters of each computing node in the computing cluster are detected based on the running information, and the performance matching parameters of each computing node in the computing cluster are detected based on the source architecture type. The resource matching parameters are used to indicate the degree of matching between the node resources currently allowed to be used by the corresponding computing node and the node resources required for the target virtual machine to run. The larger the resource matching parameters, the higher the degree of matching between the node resources currently allowed to be used by the corresponding computing node and the node resources required for the target virtual machine to run. The performance matching parameters are used to indicate the degree of matching between the architecture type of the corresponding computing node and the source architecture type. The larger the performance matching parameters, the smaller the architecture difference between the corresponding computing node and the source computing node, and the smaller the impact on the performance parameters of the target virtual machine when the target virtual machine is installed on the corresponding computing node. Based on the resource matching parameters and performance matching parameters of each computing node, target computing nodes that meet the running conditions of the target virtual machine are selected from the computing cluster.
3. The method according to claim 2, characterized in that, The step of detecting resource matching parameters for each computing node in the computing cluster based on the operational information includes: The component resource information of each computing node is detected, and the resource requirement information in the running information is obtained. The component resource information records the component resource parameters of each of the multiple execution components in the computing node. The component resource parameters are used to indicate the amount of resources that the corresponding execution component is currently allowed to use. The resource requirement information records the resource requirement parameters of each of the one or more execution components required for the target virtual machine to run. The resource requirement parameters are used to indicate the amount of resources that the target virtual machine needs to use for the corresponding execution component to run. The resource matching parameters for the computing node are generated based on the resource requirement information and the component resource information.
4. The method according to claim 2, characterized in that, The step of detecting performance matching parameters for each computing node in the computing cluster based on the source architecture type includes: Using each of the aforementioned computing nodes as a reference computing node, the architecture type of the reference computing node is detected to obtain the node architecture type; A reference loss parameter corresponding to the source architecture type and the node architecture type is matched from the first architecture type, the second architecture type and the loss parameter that have a corresponding relationship, wherein the loss parameter is used to indicate the degree of performance parameter degradation when a virtual machine adapted to the first architecture type is installed on a compute node of the second architecture type; The performance matching parameters of each computing node are determined based on the reference loss parameters of each computing node.
5. The method according to claim 2, characterized in that, The step of selecting target computing nodes from the computing cluster that meet the running conditions of the target virtual machine based on the resource matching parameters and performance matching parameters of each computing node includes: The resource weight and performance weight of the target virtual machine are detected, wherein the resource weight is used to indicate the degree of dependence of the target virtual machine on node resources when processing business requests, and the performance weight is used to indicate the degree of dependence of the target virtual machine on the performance parameters of the target virtual machine when processing business requests. The product of the resource matching parameter and the resource weight of each computing node is determined as the first product of each computing node, and the product of the performance matching parameter and the performance weight of each computing node is determined as the second product of each computing node. The larger the first product, the higher the matching degree between the corresponding computing node and the node resources of the target virtual machine. The larger the second product, the smaller the influence of the corresponding computing node on the performance parameters of the target virtual machine. The first product and the second product of each computing node are added together to generate the node matching parameters of each computing node. Based on the node matching parameters of each computing node, the computing node with the largest node matching parameter is selected from the computing cluster as the target computing node.
6. The method according to claim 1, characterized in that, The migration of virtual machines on each source compute node to the corresponding target compute node according to the migration order indicated by the virtual machine priority of the compute cluster includes: The service type of the service request currently being processed by each of the virtual machines is detected to obtain the virtual machine priority of each virtual machine. The service type is used to indicate the importance of the service request being processed by the virtual machine. The virtual machine priority corresponding to the virtual machine that processes important service requests is higher than the virtual machine priority corresponding to the virtual machine that processes non-important service requests. Based on the virtual machine priorities of the multiple virtual machines and the target compute node, a plurality of migration instructions to be executed with a target execution order are generated, wherein the migration instructions are used to migrate the virtual machines on each of the source compute nodes to the corresponding target compute node; Execute multiple migration instructions in the order described in the target execution sequence.
7. The method according to claim 6, characterized in that, The execution of multiple migration instructions in the order of the target execution includes: The execution progress of each of the multiple migration instructions is detected, wherein the execution progress is used to indicate whether the virtual machine corresponding to the migration instruction is running normally on the target compute node; When it is detected that the execution progress of the migration instructions corresponding to the virtual machines on the same reference compute node all exceed the target progress, it is determined that the virtual machines installed on the reference compute node have all completed the migration.
8. An upgrade device for a computing node, characterized in that, include: A receiving module is used to receive an upgrade request, the upgrade request being used to request an upgrade of the computing cluster, wherein virtual machines are installed on the computing nodes in the computing cluster; A response module is used to respond to the upgrade request, taking each of the virtual machines as target virtual machines and the computing nodes where each of the virtual machines reside as source computing nodes. Based on the running information of the target virtual machines and the source architecture type of the source computing nodes, the module selects target computing nodes from the computing cluster that meet the running conditions of the target virtual machines. The running information indicates the node resources required for the target virtual machines to run, the source architecture type is the architecture type adapted to the running of the target virtual machines, and the running conditions include: the currently allowed node resources are greater than or equal to the node resources required for the running of the target virtual machines, and the architecture difference parameter between the target virtual machines and the source computing nodes is less than or equal to a preset threshold. The architecture difference parameter indicates the degree of impact on the performance parameters of the target virtual machines when installed on computing nodes of different architecture types. The performance parameters indicate the processing performance of the target virtual machines for business requests. The migration module is used to migrate virtual machines on each of the source computing nodes to the corresponding target computing nodes according to the migration order indicated by the virtual machine priority of the computing cluster. The upgrade module is used to upgrade the reference computing node when it is detected that all virtual machines installed on any reference computing node in the computing cluster have completed migration.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the upgrade method for a computing node as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the upgrade method for a computing node as described in any one of claims 1 to 7.
Citation Information
Cited By
Processing method and device of multi-core processor, storage medium and electronic equipment
CN121579416A