Resource scheduling method for framework perception of hybrid framework target range

Abstract

The invention provides a hybrid architecture target range architecture sensing resource scheduling method, belongs to the field of cloud computing resource scheduling, and can at least partially solve the problems that virtual machine deployment fails and the automation degree is low in heterogeneous environments such as x86 and ARM due to the fact that an existing resource scheduler cannot sense and match an underlying processor architecture. The method comprises the following steps: acquiring own processor architecture information automatically reported by a computing node; when a virtual machine creation request is received, obtaining a processor architecture attribute required by a target virtual machine mirror image; screening out a candidate computing node set matched with the architecture by taking the architecture attribute as a primary filtering condition; and in the candidate set, selecting a target computing node according to a preset weight strategy, and issuing a creation instruction. According to the method, architecture matching is used as a preposed necessary condition, deployment failure caused by incompatibility of instruction sets is fundamentally avoided, and full-automatic and precise scheduling of the hybrid architecture resource pool is achieved.

Description

Technical Field

[0001] This invention relates to the field of cloud computing resource scheduling technology, and more specifically to a hybrid architecture range architecture-aware resource scheduling method. Background Technology

[0002] With cybersecurity elevated to a national strategic level, the development of an independent and controllable software and hardware system based on domestically produced chips, operating systems, and middleware is accelerating. Particularly in key industries vital to the national economy and people's livelihoods, such as the power sector, the adoption of the domestically produced PK system (Phytium processor + Kylin operating system) to build IT infrastructure has become a significant trend. As a crucial platform for cybersecurity capability verification, talent cultivation, and emergency drills, the domestic production capabilities and the ability to simulate hybrid architecture environments are of paramount importance for cybersecurity test ranges.

[0003] To realistically simulate my country's current IT infrastructure environment, modern cybersecurity test ranges are increasingly adopting hybrid resource pool architectures. This means that a single, centrally managed cluster simultaneously includes traditional x86 architecture servers (equipped with Intel / AMD processors) and domestically produced ARM architecture servers (equipped with Huawei Kunpeng and Phytium processors). This heterogeneous environment presents new challenges for resource scheduling.

[0004] In hybrid cloud environments, resource scheduling is a core element. Traditional cloud platform resource schedulers, such as the Nova scheduler widely used in the OpenStack open-source cloud computing platform, make scheduling decisions primarily based on the general resource status of compute nodes, such as the number of CPU cores, memory size, and disk space. These schedulers lack awareness of the underlying hardware, especially the CPU instruction set architecture (ISA).

[0005] Therefore, in a hybrid architecture test range, when a virtual machine needs to be created, a traditional scheduler might incorrectly schedule a virtual machine image compiled for ARM architecture (an image of the Kylin operating system running on the aarch64 architecture) to an x86 architecture (x86_64) compute node, and vice versa. Due to instruction set incompatibility, this incorrect scheduling will directly cause the virtual machine to fail to start, leading to serious problems such as failure to build test range scenarios and interruption of automated processes.

[0006] To address these issues, existing technologies typically employ manual or semi-automatic workarounds. A typical approach involves manually assigning static architecture tags to compute nodes and virtual machine images, requiring users to manually specify the matching architecture tag in their virtual machine resource requests.

[0007] This approach not only increases the complexity of user operations and the probability of errors, and reduces the level of automation in range environment orchestration, but also results in low resource scheduling efficiency and a failure to effectively link with the image management system because the tags are static and cannot dynamically perceive the node status.

[0008] Therefore, a new technical solution is urgently needed to solve the above problems. Summary of the Invention

[0009] This invention aims to at least solve one of the technical problems existing in the prior art, and provides a hybrid architecture range architecture-aware resource scheduling method, including: Obtain the processor architecture information reported by the compute nodes and record it in the resource status database; When a virtual machine creation request is received, the request is parsed to obtain the identifier of the target virtual machine image; Based on the identifier of the target virtual machine image, query and obtain the processor architecture attributes required by the image; Using the processor architecture attribute required by the image as the primary filtering condition, a set of candidate computing nodes matching the processor architecture is selected from the resource status database; In the set of candidate computing nodes, the candidate computing nodes are sorted according to a preset weighting strategy, and a target computing node is selected. A virtual machine creation command is issued to the target computing node.

[0010] Furthermore, obtaining the processor architecture information reported by the computing node further includes: An agent program is deployed on the computing node. When the agent program starts, it automatically detects the processor architecture information of the node and reports the architecture information to the unified resource scheduler.

[0011] Furthermore, the querying and obtaining of the processor architecture attributes required for the image further includes: Determine if the required processor architecture attribute for the image exists; If the attribute is missing, an automatic detection process is initiated to determine the processor architecture and complete the attribute.

[0012] Furthermore, the automatic detection process determines the processor architecture of the target virtual machine image by analyzing its internal file format and kernel information.

[0013] Furthermore, the processor architecture information includes x86 architecture, ARM architecture, and PK architecture.

[0014] Furthermore, the resource status database maintains a grouping list of computing nodes based on processor architecture information.

[0015] Furthermore, the preset weighting strategy includes a weighting strategy calculated based on the real-time CPU load, remaining memory, and network I / O status of the computing node.

[0016] Furthermore, the step of selecting a set of candidate computing nodes that match the processor architecture further includes: If the processor architecture of a compute node does not match the processor architecture attributes required by the image, the compute node is directly excluded from the candidate compute node set.

[0017] Furthermore, the step of selecting a set of candidate computing nodes that match the processor architecture further includes: Filtering is performed based on whether the available resources of the compute node meet the resource requirements specified in the virtual machine creation request.

[0018] Furthermore, if the candidate computing node set is empty, the scheduling is deemed to have failed, and a message indicating that there are no matching resources is returned.

[0019] The beneficial effects of this invention are as follows: By using CPU architecture as the primary filtering condition in the scheduling decision-making process, the compatibility of the virtual machine image with the physical node on which it runs is fundamentally ensured at the instruction set level, avoiding deployment failures caused by architecture mismatch and significantly improving deployment success rate and system reliability.

[0020] This method enables automatic reporting of computing node architecture, automatic identification of mirror architecture, and automatic matching of scheduling processes. It eliminates the need for administrators to tag nodes or users to manually specify the architecture, greatly improving the management efficiency and automation level of hybrid architecture test ranges.

[0021] By ensuring that the architecture is correctly matched, a weighted strategy of CPU load and memory availability is used to select target nodes, thereby achieving refined and optimized utilization of the hybrid architecture resource pool and improving the overall resource utilization of the cluster.

[0022] This method can be integrated into existing open-source or commercial cloud management platforms as an enhancement module or plugin. It is easy to implement and promote on existing test range facilities and has good engineering application value. Attached Figure Description

[0023] Figure 1 A schematic diagram of the basic process of the hybrid architecture range architecture-aware resource scheduling method provided in this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solution of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0025] like Figure 1 As shown, the present invention provides a hybrid architecture range architecture-aware resource scheduling method, the specific steps of which are as follows: Step 1: Resource Registration and Architecture Awareness In order for the scheduler to be aware of the architecture distribution of the entire resource pool, each computing node needs to actively report its own processor architecture information when it joins the resource pool.

[0026] The target range resource pool consists of multiple physical servers, including x86 computing servers and ARM computing servers. Each computing node, regardless of whether it's x86, ARM, or PK architecture, has an agent running on it that automatically executes specific instructions to accurately identify the CPU architecture type of that node after the operating system starts.

[0027] On x86 nodes, the agent can execute the cpuid command or read the / proc / cpuinfo file to obtain architecture information, the result of which is x86_64.

[0028] On ARM nodes based on Phytium or Kunpeng processors, the agent program can obtain its architecture information in a similar way, with the result being aarch64.

[0029] Subsequently, the agent program reports the obtained architecture information, along with general resource information such as the number of CPU cores, total memory size, disk capacity, and NUMA topology of the nodes, to the unified resource scheduler. After receiving this information, the scheduler persists it to the resource status database.

[0030] In this way, the scheduler can accurately grasp the architecture type and static resource information of all nodes in the resource pool in real time. To facilitate rapid subsequent filtering, the scheduler can also maintain grouped resource lists of different architectures in the database based on the architecture information. These lists are also called resource domains, including x86_resource_domain and arm_resource_domain.

[0031] Step 2: Virtual Machine Creation Request Processing and Image Architecture Identification When a user initiates a scheduling request to create a virtual machine through the range management interface, the request typically includes the identifier (UUID) of the virtual machine image to be used and the required virtual machine specifications (number of vCPUs, memory size).

[0032] Upon receiving a request, the scheduler first parses the identifier of the target image. Then, the scheduler uses this identifier to query the metadata database of the image repository. Virtual machine images in the target range, especially domestically developed operating system images (such as Galaxy Kylin V10), should have a metadata field in their metadata that explicitly specifies their required CPU architecture when they are created and uploaded to the image repository. This attribute field can be named `architecture`, and its value could be `x86_64` or `aarch64`. By querying this attribute, the scheduler can determine the architecture of the physical node on which the virtual machine to be created needs to run.

[0033] To improve system fault tolerance and automation, if the scheduler detects a missing architecture attribute field in the image metadata, the system can initiate an automatic detection process. This process intelligently determines the image's CPU architecture by downloading and analyzing specific information within the image file, including its boot sector, kernel file, or core executable format (in Linux systems, the e_machine field of the ELF file explicitly indicates its target architecture). Once determined, the system automatically updates the detected architecture information into the image's metadata for subsequent scheduling use.

[0034] Step 3: Primary Filtering Based on Architecture After obtaining the target architecture attributes required by the image, the scheduler will use these architecture attributes as a primary and mandatory filter.

[0035] The scheduler will query the resource status database and filter out all compute nodes that meet two conditions: The first condition is that the processor architecture is a perfect match for the architecture required by the image; The second condition is that the node's current available resources (remaining CPU and memory) are sufficient to meet the resource requirements specified in the virtual machine creation request. All nodes that do not meet the architecture matching conditions, regardless of their low load or idle resources, will be directly excluded at this stage.

[0036] This step creates a set of candidate compute nodes that are architecturally compatible and have sufficient resources. If the candidate list is empty after this round of filtering, it means that there are no suitable nodes in the resource pool capable of running the virtual machine. The scheduler can directly determine that the scheduling has failed and return an error message of "no matching resources," thus avoiding subsequent invalid computations.

[0037] Step 4: Node selection based on weight strategy If the candidate node set is not empty, the scheduling process enters the optimization and selection phase. At this point, the scheduler only applies a preset weighting strategy to sort the candidate nodes within the set whose architecture has already matched.

[0038] These weighting strategies aim to select a suitable node from all eligible nodes. Common weighting metrics include: CPU real-time load: Select the node with the lowest CPU utilization to achieve load balancing.

[0039] Memory Remaining Amount: Select the node with the most available memory to provide more ample running space for the virtual machine.

[0040] Network I / O status: Select nodes with lower network traffic to avoid network congestion.

[0041] Disk I / O status: Select a node with a lower disk read / write load.

[0042] The scheduler calculates a comprehensive score for each node in the candidate set based on one or more of the above indicators, and finally selects the node with the highest score as the target computing node for this virtual machine creation.

[0043] Step 5: Issue the creation command After selecting a target compute node, the scheduler issues specific instructions to that node to create a virtual machine. These instructions are typically sent by the management node to the virtualization management service (libvirt or nova-compute service) on the target compute node. Upon receiving the instructions, this service invokes the underlying hypervisor (KVM / QEMU) to perform operations, including pulling images from the image repository, creating virtual disks, configuring virtual networks, and finally starting the virtual machine. Because the architecture of the target node and the virtual machine image is already guaranteed to match, the virtual machine can be successfully created and run.

[0044] Example: Application in a domestically developed cybersecurity test range on the power generation side This embodiment describes the specific application of the method of the present invention in a domestically produced cybersecurity test range on the power generation side. This test range aims to simulate the real industrial control environment of a power plant for attack and defense drills and security verification. Its underlying resource pool is managed by a unified cloud management platform. This resource pool has a hybrid architecture, containing 50 x86 computing servers and 30 ARM computing servers based on the domestically produced Phytium FT-2000+ processor.

[0045] First, during the test environment initialization phase, all computing nodes have been deployed with operating systems and virtualization software. On each computing node, whether it's an x86 or ARM server, a lightweight agent automatically executes after its operating system boots up. One of the core functions of this agent is to identify the hardware information of its node. The agent accurately identifies the CPU instruction set architecture of its node by executing low-level instructions or reading system information files.

[0046] For x86 nodes, the recognition result is x86_64; For nodes equipped with Phytium processors, the identification result is aarch64.

[0047] Subsequently, the agent program reports the obtained architecture information, along with general resource information such as the number of CPU cores, total memory size, disk capacity, and NUMA topology of the nodes, to the unified resource scheduler deployed on the management node via the management network. Upon receiving this information, the scheduler persists it to the resource state database and automatically creates and maintains different resource domains, x86_Domain and ARM_Domain, based on the architecture information. At this point, the preliminary process of resource registration and architecture awareness is complete, and the scheduler has a clear understanding of the heterogeneous distribution of the entire resource pool.

[0048] Next, we move on to the construction phase of the target range business scenario. A security engineer needs to build an attack and defense exercise scenario, which requires a database server simulating a domestically produced core business system. Specifically, the target needs to run the "Galaxy Kylin V10" operating system and the "DaMeng Database".

[0049] The target's virtual machine image, Kylin-V10-DM.qcow2, was pre-compiled based on the Phytium ARM processor and uploaded to the target image repository. The image's metadata correctly indicates its architecture attribute as architecture=aarch64.

[0050] The engineer used the target range platform's graphical topology editor to drag and drop the database target from the target library and configure its resource specifications: 2 virtual CPU cores and 4GB of memory. Then, the engineer clicked the "Deploy" button, triggering a virtual machine creation request.

[0051] The unified resource scheduler receives the creation request. The scheduler first parses the request, identifying the required image as Kylin-V10-DM.qcow2 and its identifier UUID. Next, the scheduler queries the image metadata database, retrieving the image's architecture attribute value as aarch64.

[0052] At this point, the core scheduling logic of this invention begins to execute. The scheduler uses aarch64 as the primary and inviolable filtering condition to perform the first round of screening of all 80 compute servers in the resource status database. In this stage, 50 x86 servers are immediately excluded from the candidate list because their reported architecture information x86_64 does not match the image requirements, regardless of how low their load or how idle their resources are.

[0053] After architecture filtering, only 30 ARM servers remain in the candidate compute node set. The scheduler then performs a second round of filtering: resource sufficiency filtering. It iterates through these 30 ARM servers, checking whether the real-time available resources of each server meet the requirements of 2 vCPUs and 4GB of memory specified in the request.

[0054] Suppose that 5 ARM servers are currently running other high-load tasks and have insufficient remaining resources; these will also be excluded from the candidate list. After two rounds of filtering, the final set of candidate compute nodes includes 25 ARM servers that fully meet both the architecture and resource requirements.

[0055] After identifying 25 candidate nodes, the scheduler initiates a weight calculation and sorting process to select the most suitable node. The scheduler queries the agents of these 25 nodes for their latest dynamic load information, including real-time CPU utilization, memory page swapping activity, and network I / O throughput.

[0056] Based on a preset weighting strategy, which includes "prioritizing the node with the lowest CPU load to achieve load balancing," the scheduler calculates a comprehensive score for each candidate node. For example, a server numbered ARM-Node-18 currently has a CPU load of only 15%, the lowest among all candidate nodes, and therefore receives the highest weighting score.

[0057] Ultimately, the scheduler selected ARM-Node-18 as the target compute node for this virtual machine creation. The scheduler generated a creation command containing the image UUID, virtual machine specifications, network configuration, and target node identifier, and sent it to the virtualization management service on the target node. Upon receiving the command, the service invoked the underlying virtualization engine, pulled the Kylin-V10-DM.qcow2 image from the image repository, created a virtual disk on local storage, and successfully started the virtual machine.

[0058] This embodiment automates the entire virtual machine creation process. Security engineers no longer need to concern themselves with the specific architecture of the underlying servers. Through its built-in architecture awareness and matching mechanism, the system ensures that domestically produced virtual machine images are always accurately scheduled onto the correct domestically produced hardware, thereby guaranteeing the rapid and reliable construction of test range scenarios and significantly improving the management efficiency and intelligence level of the hybrid architecture resource pool.

[0059] In summary, the embodiments disclosed herein have at least the following technical effects: Precise matching: By using CPU architecture as the primary filtering condition in the scheduling decision process, the compatibility of the virtual machine image with the physical node it runs on at the instruction set level is fundamentally ensured, avoiding deployment failures caused by architecture incompatibility and significantly improving deployment success rate and system reliability.

[0060] Fully automated: This method enables automatic reporting of computing node architecture, automatic identification of mirror architecture, and automatic matching of scheduling processes. It eliminates the need for administrators to tag nodes or users to manually specify the architecture, greatly improving the management efficiency and automation level of hybrid architecture test ranges.

[0061] Resource optimization: Under the premise of ensuring correct architecture matching, the target node is selected by using a weighted strategy of CPU load and memory reserve, which realizes the refined and optimized utilization of the hybrid architecture resource pool and improves the overall resource utilization of the cluster.

[0062] High compatibility: This method can be integrated into existing open source or commercial cloud management platforms as an enhancement module or plugin, and is easy to implement and promote on existing test range facilities, with good engineering application value.

[0063] It is understood that the above embodiments are merely exemplary implementations used to illustrate the principles of the present invention, and the present invention is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and essence of the present invention, and these modifications and improvements are also considered to be within the scope of protection of the present invention.

Claims

1. A resource scheduling method with hybrid architecture range architecture awareness, characterized in that, include: Obtain the processor architecture information reported by the compute nodes and record it in the resource status database; When a virtual machine creation request is received, the request is parsed to obtain the identifier of the target virtual machine image; Based on the identifier of the target virtual machine image, query and obtain the processor architecture attributes required by the image; Using the processor architecture attribute required by the image as the primary filtering condition, a set of candidate computing nodes matching the processor architecture is selected from the resource status database; In the set of candidate computing nodes, the candidate computing nodes are sorted according to a preset weighting strategy, and a target computing node is selected. A virtual machine creation command is issued to the target computing node.

2. The resource scheduling method according to claim 1, characterized in that, The acquisition of the processor architecture information reported by the computing node includes: An agent program is deployed on the computing node. When the agent program starts, it automatically detects the processor architecture information of the node and reports the architecture information to the unified resource scheduler.

3. The resource scheduling method according to claim 1, characterized in that, The processor architecture attributes required to query and obtain the image include: Determine if the required processor architecture attribute for the image exists; If the attribute is missing, an automatic detection process is initiated to determine the processor architecture and complete the attribute.

4. The resource scheduling method according to claim 3, characterized in that, The automatic detection process determines the processor architecture by analyzing the internal file format and kernel information of the target virtual machine image.

5. The resource scheduling method according to claim 1, characterized in that, The processor architecture information includes x86 architecture, ARM architecture, and PK architecture.

6. The resource scheduling method according to claim 1, characterized in that, The resource status database maintains a grouping list of computing nodes based on processor architecture information.

7. The resource scheduling method according to claim 1, characterized in that, The preset weighting strategy includes a weighting strategy calculated based on the real-time CPU load, remaining memory, and network I / O status of the computing node.

8. The resource scheduling method according to claim 1, characterized in that, The set of candidate computing nodes that match the processor architecture includes: If the processor architecture of a compute node does not match the processor architecture attributes required by the image, the compute node is directly excluded from the candidate compute node set.

9. The resource scheduling method according to any one of claims 1 to 8, characterized in that, The set of candidate computing nodes that match the processor architecture includes: Filtering is performed based on whether the available resources of the compute node meet the resource requirements specified in the virtual machine creation request.

10. The resource scheduling method according to any one of claims 1 to 8, characterized in that, If the candidate computing node set is empty, the scheduling is deemed to have failed, and a message indicating that there are no matching resources is returned.

Images