Resource cross-layer cooperative management method and baseboard manager

Abstract

The application discloses a resource cross-layer cooperative management method and a baseboard manager, relates to the technical field of server hardware management and virtualization, and comprises the following steps: synchronously acquiring resource information of a physical layer and demand information of a virtual layer by a baseboard manager, realizing information synchronization between physical resources and virtual resources, allocating corresponding physical resources according to the demand information of the virtual layer, constructing a binding relationship between the physical resources and the virtual resources, and uniformly managing the physical layer and the virtual layer according to the binding relationship. The technical problem that physical resource allocation and virtual layer demand are not associated, resulting in low system resource utilization efficiency, is solved, and the technical effect that physical resources are evenly distributed and resource utilization efficiency is improved is achieved.

Description

Technical Field

[0001] This application relates to the fields of server hardware management and virtualization technology, and in particular to a resource cross-layer collaborative management method and a baseboard manager. Background Technology

[0002] Traditional BMCs (Baseboard Managers) are tightly coupled only to physical servers, using the CPU to enable communication between boards in order to monitor the status of physical hardware (such as parameters like temperature, voltage, and fan speed). The related virtual layers (including virtual machines or containers) use independent management mechanisms to allocate resources to virtual machines and containers, for example, through virtualization platforms.

[0003] However, the above management method suffers from a disconnect between physical resource allocation and virtual layer requirements, resulting in a fragmentation between physical resources and the virtual layer, making it difficult to form effective collaborative management and leading to low overall resource utilization efficiency. Summary of the Invention

[0004] This application provides a cross-layer collaborative resource management method and electronic device to at least solve the problem in the prior art where the allocation of physical resources and the demand for virtual layers are not correlated, resulting in low system resource utilization efficiency.

[0005] This application provides a cross-layer collaborative resource management method, comprising: obtaining the connection status between physical resources in the physical layer of a server to obtain a physical topology relationship, wherein the physical resources include a baseboard management controller and a central processing unit; determining the node distribution of non-uniform memory access nodes of the server based on the physical topology information, wherein a non-uniform memory access node includes at least one central processing unit and physical resources directly connected to the central processing unit, or, a non-uniform memory access node includes at least one core of the central processing unit and physical resources directly connected to the core; obtaining resource requirement information of the virtual layer of the server; binding virtualized entities of the virtual layer to target non-uniform memory access nodes based on the resource requirement information and node distribution to obtain a binding result, wherein the target non-uniform memory access node is the non-uniform memory access node corresponding to the physical resource to be called by the virtualized entity; and applying the binding result to perform cross-layer collaborative resource management between the physical layer and the virtual layer.

[0006] This application also provides a baseboard manager, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described cross-layer collaborative resource management methods when executing the computer program.

[0007] This application achieves information synchronization between physical and virtual resources by synchronously acquiring physical layer resource information and virtual layer demand information through the baseboard manager. It also allocates corresponding physical resources according to the virtual layer demand information, establishes a binding relationship between physical and virtual resources, and manages the physical and virtual layers in a unified manner based on the binding relationship. Therefore, it can solve the technical problem of low system resource utilization efficiency caused by the lack of correlation between physical resource allocation and virtual layer demand, and achieve the technical effect of uniformly allocating physical resources and improving resource utilization efficiency. Attached Figure Description

[0008] 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.

[0009] Figure 1 A schematic diagram of a topology for connecting the physical layer and virtual layer based on a substrate manager is provided in this application embodiment;

[0010] Figure 2 A flowchart illustrating a cross-layer collaborative resource management method provided in this application embodiment;

[0011] Figure 3 This is a block diagram of a resource cross-layer collaborative management device provided in an embodiment of this application. Detailed Implementation

[0012] 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.

[0013] 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.

[0014] 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.

[0015] The specific application environment architecture or specific hardware architecture on which the cross-layer collaborative resource management method depends is described here.

[0016] This application provides a system topology architecture based on BMC in its embodiments, such as Figure 1 As shown, this includes a physical server, which is equipped with a BMC chip and physical resources. The BMC accesses the virtual layer through a unified interface gateway, and the virtual layer includes a virtualization management layer and a management platform for user operation.

[0017] Physical resources include a CPU chipset (Central Processing Unit), memory DIMMs (Dual In-line Memory Modules), storage devices, a power supply unit, smart network interface cards (NICs), and a sensor network (including but not limited to temperature sensors, voltage sensors, and fan speed sensors). The CPU chipset connects to the BMC chip via a PCIe bus, and the memory DIMMs are directly connected to the BMC chip via high-speed channels (such as I2C / SMBus). The smart network interface cards support SR-IOV virtualization (single-root I / O virtualization) and RDMA acceleration technology (Remote Direct Memory Access acceleration technology). The power supply unit connects to the BMC chip via the IPMB management bus (Intelligent Platform Management Bus). Communication between the BMC and the physical layer uses the IPMI / Redfish protocol.

[0018] BMC communicates with the virtualization layer through API interfaces such as the Libvirt API and the Kubernetes API. The Libvirt API can be used to obtain the utilization of vCPU (virtual central processing unit), and the Kubernetes API can be used to monitor the resource requirements of Pods (containers).

[0019] Furthermore, the BMC chip is equipped with functional modules such as a hardware management engine, a resource mapping engine, a security linkage controller, a data acquisition agent, and a dynamic scheduler. Among them, the data acquisition agent is used to control the physical layer sensor network, realize adaptive sampling of physical layer data, and obtain the utilization of vCPU (virtual central processing unit) and monitor the needs of Pod (container); the resource mapping engine is used to parse the relationship between CPU cores, MNUA nodes (non-uniform memory access nodes), and virtual resources, and realize dynamic allocation between SR-IOV and VF (network functions); the dynamic scheduler is used to predict future load based on historical data and perform load balancing (such as virtual machine migration) based on the predicted load; the security linkage controller is used to match attack patterns through the rule engine and perform hardware-level isolation of virtual resources that have been attacked.

[0020] The embodiments of this application provide a method for cross-layer collaborative management of resources. The method is described in detail below in conjunction with the execution flow of the cross-layer collaborative management method.

[0021] like Figure 2 As shown, the above-mentioned cross-layer collaborative resource management method includes:

[0022] Step S201: Obtain the connection status between physical resources in the server physical layer to obtain the physical topology relationship. The physical resources include the baseboard management controller and the central processing unit.

[0023] Step S202: Determine the node distribution of non-uniform memory access nodes of the server based on physical topology information. A non-uniform memory access node includes at least one central processing unit and physical resources directly connected to the central processing unit, or a non-uniform memory access node includes the core of the central processing unit and physical resources directly connected to the core.

[0024] Step S203: Obtain the resource requirement information of the server's virtual layer;

[0025] Understandably, the resource requirements information of the virtual layer can be obtained by using the APIs of virtualization platforms such as Kubernetes or Libvirt to collect the current resource usage of virtual machines or containers (such as vCPU utilization, memory usage, etc.) and future demand predictions (such as load changes predicted by machine learning models) to determine the overall demand of the virtual layer and obtain the aforementioned resource requirements information.

[0026] In practice, the real-time CPU and memory usage of a Pod can be queried using the `kubectl top pod` command (used to display Pod resource usage), and the demand information for specific hardware resources (such as GPUs and VF smart interface cards) can be obtained through device plugins (such as device plugins, a type of plugin in the Kubernetes virtualization platform).

[0027] Understandably, physical topology information at the physical layer can be obtained by using the lscpu command (used to list CPU information) to identify the CPU cores and memory distribution of each node under the NUMA architecture, and by reading hardware sensor data and firmware information through protocols such as IPMI / Redfish to understand the health status and resource connection status of the physical server.

[0028] Step S204: Based on resource demand information and node distribution, bind the virtualized entity of the virtual layer to the target non-uniform memory access node to obtain the binding result. The target non-uniform memory access node is the non-uniform memory access node corresponding to the physical resource to be called by the virtualized entity.

[0029] Specifically, based on physical topology information, physical resources are mapped to virtual resources to ensure that virtualized entities can access the required physical resources directly or through minimal intermediate interactions, thus obtaining the binding result described above.

[0030] In practice, by binding vCPUs to physical cores, the scheduling of vCPUs can be made to take into account the impact of NUMA nodes (non-uniform memory access nodes), thereby avoiding performance loss caused by cross-node access and improving resource utilization efficiency.

[0031] Furthermore, this application can dynamically adjust the binding relationship between virtualized entities and physical resources based on real-time resource requirements and physical topology information. If the resource requirements of a virtual machine do not match the currently bound NUMA node, or if it is predicted that the physical node is about to reach resource saturation, the system will recalculate the optimal binding relationship and execute corresponding resource scheduling operations, such as virtual machine migration or dynamic adjustment of resource quotas.

[0032] Step S205: Apply the binding results to perform cross-layer collaborative management of resources between the physical layer and the virtual layer.

[0033] Specifically, based on the above binding results, the system management of virtual and physical resources is realized through the above dynamic resource scheduler. For example, virtual resources are migrated based on the load of physical resources, and physical resource faults are located or security protection is performed based on the faults of virtual resources.

[0034] In practical implementation, the BMC chip achieves unified management of physical and virtual resources through a unified RESTful API interface (presentation layer state transition application programming interface). This interface supports resource scheduling and monitoring in virtualization environments such as Kubernetes and Libvirt.

[0035] Through the above embodiments, by accurately mapping resources and dynamically scheduling, direct access between the BMC and the physical and virtual layers can be achieved, which can significantly reduce unnecessary competition between the virtual and physical layers (such as the BMC communicating and forwarding through the CPU, occupying CPU computing resources) and improve resource utilization efficiency.

[0036] Furthermore, the binding between physical and virtual resources facilitates fault location and self-healing. For example, when anomalies occur in the virtual layer, such as container escape attacks or performance degradation caused by resource contention, the relevant physical resources, such as specific CPU cores or memory regions, can be quickly traced, enabling rapid fault location. With the help of mechanisms such as hardware isolation and firmware hot upgrades, the system can automatically repair or isolate problematic resources without restarting, improving service availability and security.

[0037] Furthermore, binding physical and virtual resources enables unified management, providing operations and maintenance personnel with a unified management interface and standardized RESTful API. This allows management operations at both the physical and virtual layers to be performed on a single platform, reducing the cost of switching and coordinating between multiple tools and improving operational efficiency.

[0038] Understandably, in a Non-Unified Memory Access (NUMA) architecture, server physical memory is divided into multiple distinct nodes, each directly associated with a CPU core. Due to the principle of locality of reference, directly accessing a memory node bound to a CPU core is more efficient than cross-node access. Therefore, to optimize the performance of virtualized entities (such as virtual machines (VMs) or containers), this application sets up a binding mechanism between virtual resources and physical NUMA nodes. Specifically, by analyzing the resource requirements of the virtual layer and the topology information of the physical layer, a greedy algorithm is used to construct the optimal mapping relationship, ensuring that virtualized entities can directly access the most suitable physical resources.

[0039] To achieve the binding between the virtual resources and physical resources described above, in one optional implementation, step S204 includes:

[0040] Step S2041: Based on resource demand information and node distribution, a greedy algorithm is used to construct the mapping relationship between virtualized entities and non-uniform memory access nodes;

[0041] Here, a greedy algorithm is used for fast decision-making, that is, at each step, selecting the strategy that seems best at the moment to find a locally optimal solution. For the resource binding problem, this means that each time an unbound virtualized entity is selected and an attempt is made to bind it to the currently best physical resource.

[0042] Step S2042: Configure the physical resources in the non-uniform memory access node according to the mapping relationship to achieve binding.

[0043] The binding process includes vCPU binding, massive page memory allocation, and passthrough device configuration. Specifically, vCPU binding uses a preset resource configuration strategy to ensure that the virtual machine's vCPU is bound to a specific physical core (belonging to the same NUMA node). Mass page memory allocation, based on the memory requirements of the virtualization entity, adjusts the HugeTLB parameters to allocate massive pages of memory aligned with the NUMA node for the virtual machine or container, thereby reducing cross-node access. For virtualization entities requiring high-performance hardware (such as GPUs (Graphics Processing Units) and smart network interface cards), passthrough binding is achieved by modifying the device's SR-IOV configuration using the echo command.

[0044] In practice, the greedy algorithm described above can be replaced with other algorithms, as follows:

[0045] Firstly, a genetic algorithm can be used. As can be understood, a genetic algorithm is a heuristic search algorithm that finds the optimal solution to a problem by simulating selection, crossover, and mutation operations in biological evolution. In resource allocation scenarios, a genetic algorithm can create a "chromosome" for each virtualized entity, containing information about resource bindings. Through multiple generations of evolution, GA can find a set of resource bindings that maximizes the overall system's performance or resource utilization.

[0046] Secondly, simulated annealing can be used. As can be understood, simulated annealing is a global optimization method that gradually refines the search by allowing for worse solutions with a certain probability, eventually reaching a globally optimal or suboptimal solution. It is suitable for local optima problems in resource allocation. For example, under dynamic resource requirements, simulated annealing can help the system escape the local optimum trap and find a more global resource allocation strategy.

[0047] Thirdly, the ant colony optimization algorithm can be used. This algorithm is inspired by the natural food-finding paths of ants. In resource allocation, each ant (the agent in the algorithm) represents a resource-demanding entity. They move across the resource network, updating resource allocation based on resource availability and historical path information. It is suitable for handling dynamic and complex network resource allocation problems, and can dynamically adjust resource allocation strategies based on historical behavior and resource demands.

[0048] Fourth, a particle swarm optimization (PSO) algorithm can be used. PSO simulates the behavior of a flock of birds searching for food. Specifically, in this application, each particle can be configured to represent a possible resource allocation scheme. By following the current best solution in the swarm and its own historical best solution, the resource allocation strategy is continuously adjusted and optimized. It can converge quickly, is suitable for large-scale resource allocation problems, and helps to achieve efficient resource scheduling in large server clusters.

[0049] Through the above embodiments, the greedy algorithm effectively avoids resource waste and ensures that the resources of each physical node are fully utilized. In a multi-tenant environment, this method helps balance the load and avoid overuse of certain resources, thereby improving overall resource utilization. Based on the greedy algorithm, by precisely binding virtualized entities to physical resources, unnecessary data transmission across nodes is reduced, significantly improving computational efficiency and response speed. The performance improvement is particularly pronounced when handling intensive tasks, such as deep learning training or large-scale data processing.

[0050] To optimize the matching relationship between physical and virtual resources, in one optional implementation, step S2041 includes:

[0051] Step S20411: Determine the physical resources of each non-uniform memory access node based on the node distribution;

[0052] Step S20412: Quantify and score the physical resources of each non-uniform memory access node to obtain the corresponding physical resource quantity;

[0053] The aforementioned physical resource quantities can be quantified using a scoring mechanism. Specifically, the processor core count score is calculated by determining the number of CPU cores on each physical node and assigning a score based on the number of cores (more cores, higher score). The available memory capacity score is determined by evaluating the available memory capacity of each NUMA node (more available memory, higher score). The available storage capacity score is determined by calculating the remaining space on the physical storage devices of each NUMA node (the principle is the same as the memory score). The network device score can be based on the bandwidth and latency characteristics of the network devices, as well as the supported network functions (such as SR-IOV, RDMA).

[0054] Step S20413: Determine the required physical resources for each virtualization entity based on the resource requirement information. The required physical resources include the number of virtual processors, the amount of memory occupied, the amount of storage occupied, and the communication rate baseline.

[0055] Step S20414: Quantify and score the physical resources of each virtualized entity to obtain the corresponding amount of physical resources occupied;

[0056] The above-mentioned physical resource consumption can be quantified using a scoring mechanism. The virtual processor quantity score determines the number of vCPUs required by each virtualized entity (higher demand, higher score). The memory requirement score is based on the memory requirements of the virtualized entity (higher demand, lower score). The storage requirement score is determined by assessing the storage space requirements of the virtualized entity (the principle is the same as the memory requirement score). The communication rate benchmark score considers the network throughput requirements of the virtualized entity; higher demand results in a higher score because high-demand entities consume more network resources.

[0057] Step S20415: Sort the virtualized entities according to the amount of physical resources they occupy, and then allocate the virtualized entities to the non-uniform memory access nodes with the largest corresponding amount of physical resources and update the physical resource amounts to obtain the mapping relationship.

[0058] Specifically, the greedy algorithm has the following steps:

[0059] Based on physical resource quantification and scoring, a physical resource quantity matrix is ​​initialized, where columns represent various physical resource types and rows and columns represent resource quantity scores. Virtual entities are sorted in descending order according to their physical resource demand scores (higher demand, lower score). Starting with the virtual entity with the highest demand, the NUMA node with the maximum physical resource quantity is located and allocated. After allocation, the physical resource quantity of that node is updated immediately. The remaining virtual entities in the list are then allocated sequentially to the NUMA node with the current maximum resource quantity until all virtual entities have been successfully allocated.

[0060] Through the above embodiments, the greedy algorithm effectively avoids resource waste and ensures that the resources of each physical node are fully utilized. In a multi-tenant environment, this method helps balance the load and avoid overuse of certain resources, thereby improving overall resource utilization. Based on the greedy algorithm, by precisely binding virtualized entities to physical resources, unnecessary data transmission across nodes is reduced, significantly improving computational efficiency and response speed. The performance improvement is particularly pronounced when handling intensive tasks, such as deep learning training or large-scale data processing.

[0061] The cross-layer collaborative resource management method combines resource monitoring and prediction at both the physical and virtual layers. It utilizes machine learning to predict the load on physical resources and then performs dynamic load balancing based on the prediction results. Through proactive resource management and scheduling, it can significantly improve resource utilization, prevent resource bottlenecks and overloads, and enhance the overall responsiveness and stability of the system.

[0062] In order to dynamically balance the load on physical resources and improve the operating performance of virtual resources, in an optional implementation, step S205 includes:

[0063] Step S20501: Obtain the historical operating status of physical resources within the first preset time period to obtain historical load data;

[0064] In practice, the BMC and virtualization platform API are used to collect the historical operating status of physical resources (such as CPU and memory) within a first preset time period, including but not limited to CPU utilization, memory usage, network bandwidth usage, disk I / O, etc.

[0065] Step S20502: Use a neural network to predict the operating status of physical resources within a second preset time period based on historical load data, and obtain predicted load data;

[0066] In practical implementation, taking the Long Short-Term Memory network as an example, the LSTM neural network model is used to capture long-term dependencies. With historical load data as input, the operating status of physical resources within a second preset time period is predicted to obtain the above-mentioned predicted load data.

[0067] Step S20503: If the predicted load data is greater than the first threshold and the duration is greater than the second threshold, perform load balancing operation on the physical resources according to the binding result.

[0068] Specifically, the system monitors predicted load data. When the predicted load exceeds a pre-set first threshold, and the duration of the predicted high load exceeds a second threshold, a load balancing operation is triggered. The selection of these thresholds must take into account resource redundancy and load fluctuation tolerance under different scenarios.

[0069] The above load balancing operation involves migrating some virtualized entities from high-load physical nodes to low-load nodes based on existing binding results, or adjusting the resource quotas of virtualized entities.

[0070] Through the above embodiments, by accurately predicting and dynamically load balancing, the system can adjust resource allocation in advance before the peak of resource demand, avoiding resource contention and bottlenecks, and improving the overall utilization and allocation efficiency of resources.

[0071] Furthermore, the predictive mechanism helps the system detect potential load anomalies in advance and take timely measures, reducing system jitter and latency caused by resource overload and improving user experience. Simultaneously, when an overload or failure of a specific physical node is predicted, the system can quickly transfer critical services to other healthy nodes, enhancing the cluster's disaster recovery capabilities and business continuity.

[0072] By integrating technologies such as neural networks (e.g., Long Short-Term Memory networks, LSTM), time series forecasting libraries, and Autoregressive Integrated Moving Average (ARIMA) models, it is possible to make refined predictions about the future operating status of physical resources. Through these predictions, the system can understand resource load trends in advance, thereby making more effective resource scheduling and allocation decisions. The introduction of meta-models aims to combine the advantages of multiple forecasting techniques to improve the accuracy and stability of predictions.

[0073] To achieve accurate prediction of load change trends, in one optional implementation, step S20502 includes:

[0074] Step S205021: Use a long short-term memory network to predict the operating status of physical resources within a second preset time period based on historical load data to obtain the first load data;

[0075] LSTM (Long Short-Term Memory) is a special type of recurrent neural network (RNN) capable of capturing long-term dependencies in sequential data, making it suitable for time-series data prediction. In this scheme, LSTM is used to predict the physical resource operating status within a second preset time period to obtain the aforementioned first load data.

[0076] Step S205022: Use a time series forecasting library to predict the operating status of physical resources within a second preset time period based on historical load data to obtain the second load data;

[0077] Using a mature time series forecasting library (such as Prophet, an open-source time series forecasting library from Facebook, which excels in handling periodic data and trend forecasting), the future operating status of resources is predicted to obtain the second load data mentioned above.

[0078] Step S205023: The autoregressive integrated moving average network is used to predict the operating status of physical resources within a second preset time period based on historical load data, and the third load data is obtained.

[0079] Specifically, ARIMA is a classic statistical model widely used for forecasting time series data. It makes predictions by analyzing the trend and periodic characteristics of the data to obtain the aforementioned third load data.

[0080] Step S205024: The first load data, the second load data, and the third load data are fused using a meta-model to obtain the predicted load data. The meta-model is one or more of linear regression, decision tree, and neural network.

[0081] One or more models are selected from linear regression, decision trees, and neural networks as meta-models to fuse the first load data (LSTM prediction results), the second load data (time series prediction library prediction results), and the third load data (ARIMA model prediction results).

[0082] Specifically, the meta-model learns the relationship between these three predictions and uses a weighted average to predict the final future resource state (predicted load data). The weights can be adjusted using techniques such as cross-validation to find the optimal combination of predictions.

[0083] Through the above embodiments, by integrating multiple prediction technologies, the advantages of each can be combined, reducing the biases and errors that may exist in a single model, and improving the accuracy and stability of the final prediction results. The meta-model can adaptively adjust the weights of the prediction model according to different scenarios and data characteristics, so that it can maintain high prediction accuracy when facing different types of physical resource loads. More accurate predicted load data allows the system to anticipate the degree of resource stress in advance, thereby enabling dynamic resource scheduling, such as the migration of virtual machines or containers, and the adjustment of resource quotas, avoiding resource bottlenecks and improving resource utilization and response efficiency.

[0084] To avoid excessive physical resource load, in an optional implementation, step S2053 includes:

[0085] Step S205031: If the predicted load data of the target non-unified memory access node is greater than the first threshold, migrate some of the virtualized entities deployed on the target non-unified memory access node to other non-unified memory access nodes.

[0086] Specifically, if the system predicts that the load on the entire node exceeds a first threshold and there are not enough idle processor cores available for internal load balancing, it will perform virtual machine migration between processors. This operation will migrate overloaded virtual machines to processors on other nodes with lower loads to distribute the load and avoid resource bottlenecks.

[0087] In practice, the above operations rely on dynamic adjustment of Kubernetes resource quotas (such as using kubectlpatch pod to change the vCPU limit of a Pod) or adjusting the vCPU binding of virtual machines in Libvirt to reduce the occupancy of processor cores.

[0088] Step S205032: If the predicted load data of any processor or processor core in the target non-uniform memory access node is greater than the first threshold, the processor or processor core is identified as the first target object. Other processors or processor cores in the target non-uniform memory access node are traversed to identify processors or processor cores whose predicted load data is less than the second threshold, and the second target object is obtained.

[0089] Step S205033: Allocate the physical resources of the second target object to the first target object until the predicted load data of the first target object is less than or equal to the first threshold.

[0090] If the predicted overload occurs only on an individual processor core (or processor), and the predicted load on other cores (or processors) on the same node is below the threshold, the system will reschedule the virtual processors (vCPUs) associated with the overloaded core and distribute them to other cores with lower loads to balance the load on each core.

[0091] In practice, the above operations rely on the deep integration of BMC with the virtualization layer and dynamic resource scheduling capabilities, such as Kubernetes Pod scheduling or Libvirt vCPU binding adjustment.

[0092] Through the above embodiments, dynamic load balancing enables the system to utilize physical processor resources more efficiently, reducing idle or underutilized situations, making resource allocation more reasonable, and improving the overall performance and utilization of the server.

[0093] Meanwhile, timely vCPU reallocation and virtual machine migration avoid overloading of a single or entire processor, reducing the risk of system crashes and performance degradation, and improving system stability and reliability. These operations also avoid resource contention and bottlenecks, enabling the system to respond faster when handling high concurrency and high performance demands, thus improving the user's service experience.

[0094] In cross-layer collaborative resource management of servers, real-time monitoring and anomaly detection are crucial for maintaining system stability and security. This application utilizes deep learning technology to construct a behavioral model for anomaly detection by monitoring the behavior of processes within containers, network activity, and resource consumption. Once an anomaly is detected, due to the mapping and binding between physical and virtual resources, it can accurately locate the problem and immediately take restart or isolation measures to protect the system from malicious behavior or failures.

[0095] To ensure the security of collaborative management between the virtual layer and the physical layer, in an optional implementation, step S205 further includes:

[0096] Step S20504: Monitor the behavior of processes within the container in the virtual layer to obtain the target behavior; monitor the network activity of the container to obtain the communication mode and connection operations; monitor the consumption of physical resources by the container to obtain the target utilization rate.

[0097] System call tracing tools (such as eBPF, strace) or other process monitoring tools (such as cAdvisor) are used to monitor the operations of processes within the container, including file system access, network connections, system calls, etc., to obtain detailed process behavior logs and thus the target behavior. Network monitoring tools (such as tcpdump, Wireshark) or network firewall logs are used to collect data such as container network traffic, packet size, and communication frequency, constructing container communication patterns and connection operation logs to obtain the aforementioned communication patterns and connection operations. Using BMC and virtualization platform APIs, such as Libvirt and Kubernetes, real-time consumption of physical resources (such as CPU, memory, disk I / O, and network bandwidth) by the container is collected to obtain the target utilization rate.

[0098] Step S20505: Use a pre-trained deep learning-based behavior model to perform anomaly monitoring based on target behavior, communication mode, connection operation and target occupancy rate;

[0099] Using a pre-trained deep learning behavioral model trained on historical container behavior data, this model can identify and classify normal and abnormal behavior patterns. Taking the collected data on in-container process behavior, network activity, and resource consumption as input, the model can automatically analyze this data to determine if the container exhibits abnormal behavior. The model outputs the detection results of abnormal behavior, including the type of anomaly and the possible threat level.

[0100] Step S20506: If the container exhibits abnormal behavior, restart or isolate the container based on the binding result.

[0101] Specifically, for minor anomalies or reachable containers detected, the system can directly restart the containers via the Kubernetes API or the Docker restart command (an open-source application container engine) to attempt to resolve potential issues. For serious anomalies that may cause system-wide impact, or containers that are still detected as anomalies after restarting, the system uses BMC control and PCIe reconfiguration or other isolation technologies to isolate the physical resources bound to the abnormal containers, preventing them from further affecting system security and stability.

[0102] Through the above embodiments, by restarting or isolating abnormal containers, the system can allocate physical resources more rationally, avoiding resource waste and unreasonable allocation, and improving resource utilization efficiency. Furthermore, based on the binding of virtual and physical resources, by monitoring container behavior and resource consumption in real time, anomalies can be quickly detected and accurately located, allowing for countermeasures to be taken, effectively preventing the spread of malware and container escape attacks, and improving the overall security of the system.

[0103] In server operation and maintenance, the resource status of the physical layer and the virtual layer are closely related. Failures of virtualized entities often originate from problems with physical resources, but traditional operation and maintenance tools struggle to directly correlate the status of these two layers. This application, based on the binding relationship between physical and virtual resources, enables the analysis of fault propagation by combining historical data from physical layer sensors with the historical operating status of the virtual layer when a virtual layer entity fails. This analysis utilizes graph neural network technology to quickly locate the faulty physical layer resource, improving operational efficiency and accuracy.

[0104] To improve the efficiency of resource management, in an optional implementation, step S203 further includes:

[0105] Step S20506: In the event of a fault in the virtualized entity of the virtual layer, the sensors of the physical layer are controlled to monitor the historical operating status of the physical resources corresponding to the virtualized entity within a third preset time period according to the binding result, and the first monitoring data is obtained.

[0106] The cross-layer monitoring agent is responsible for collecting physical layer monitoring data and virtual layer operation status data of the sensors, covering the historical operation status of the past third preset time period (such as 1 hour), and obtaining the aforementioned first monitoring data.

[0107] Step S20507: Obtain the historical operating status of the virtualized entity within a third preset time period to obtain the second detection data;

[0108] Step S20508: Embed the first monitoring data and the second detection data into a preset fault propagation map;

[0109] Specifically, the first monitoring data (physical layer data) collected from sensors and the second detection data obtained from the virtual layer are merged to form a comprehensive dataset for fault analysis. Through data standardization and cleaning, this data is embedded into a pre-built fault propagation graph, where each node represents a physical or virtual resource, and edges represent dependencies between resources.

[0110] Step S20509: Use a graph neural network to determine the faulty physical resources of the physical layer based on a preset fault propagation map.

[0111] Using a fault propagation graph embedded with monitoring data as input to a GNN (Graph Neural Network), the model learns and predicts the probability of fault propagation in the graph through message passing mechanisms between nodes, and outputs the fault prediction results of physical resources, thus obtaining the aforementioned faulty physical resources.

[0112] Understandably, a fault propagation graph is first constructed before training the graph neural network. This is achieved by using existing server resource configurations and historical fault records to construct a fault propagation graph that includes physical resources and virtual resources and their interdependencies. This graph not only covers the topology of the resources but also includes possible fault propagation paths and patterns.

[0113] Through the above embodiments, cross-layer data fusion and graph neural network analysis significantly reduce fault location time and improve operation and maintenance efficiency. Furthermore, fault location based on graph neural network analysis reduces unnecessary physical resource checks, saves operation and maintenance costs, and avoids business interruption losses caused by fault troubleshooting.

[0114] To ensure the accuracy of physical layer sampling data, in one optional implementation, after binding the virtualized entity of the virtual layer to the non-uniform memory access node to which the physical resource to be accessed by the virtualized entity belongs, the above method further includes:

[0115] Step S301: Collect the operating status of the physical layer and the virtual layer according to the preset sampling frequency to obtain sampling data;

[0116] The resource mapping engine binds virtual layer entities (such as virtual machines or containers) to their required physical resources, such as CPU cores, memory, and network interfaces. Then, the data acquisition agent begins collecting runtime status data of the physical and virtual layers according to a preset initial sampling frequency (e.g., once every 5 seconds), including but not limited to CPU utilization, memory usage, network throughput, and disk I / O.

[0117] Step S302: Determine the rate of change of the sampled data based on the sampled data to obtain the data change rate; determine the system load based on the sampled data to obtain the system load rate.

[0118] The sampled data is analyzed in real time to calculate the rate of change of data (such as the rate of change of CPU utilization) and the system load rate (the current overall utilization of CPU and memory). This step is achieved through numerical differencing or statistical sliding window averaging to assess the instantaneous changes and long-term trends of resource status.

[0119] Step S303: If the data change rate is greater than the fourth threshold, increase the sampling frequency; if the data change rate is less than the fifth threshold and the system load rate is greater than the sixth threshold, decrease the sampling frequency; if the system load rate is less than the seventh threshold, increase the sampling frequency.

[0120] Based on the calculated data change rate and system load rate, a decision is made regarding whether to adjust the sampling frequency. Specifically, if the data change rate exceeds the fourth threshold (e.g., CPU utilization change rate greater than 5% per second), it indicates unstable resource status, requiring more intensive monitoring; in this case, the sampling frequency is increased to once per second or higher. If the data change rate is below the fifth threshold (e.g., change rate less than 0.1% per second) and the system load rate is above the sixth threshold (e.g., system load rate greater than 75%), the sampling frequency is reduced to once every 15 seconds to avoid overburdening the system due to excessive monitoring. If the system load rate is below the seventh threshold (e.g., system load rate less than 20%), the sampling frequency is increased to ensure timely detection of abnormal changes even under low load conditions.

[0121] Through the above embodiments, by using an adaptive sampling frequency, the operating status of the physical layer and the virtual layer can be collected and analyzed in a unified manner, which facilitates the implementation of the above operations and improves resource utilization.

[0122] 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.

[0123] Embodiments of this application also provide a resource cross-layer collaborative management device, such as... Figure 3 As shown, the aforementioned cross-layer collaborative resource management device includes:

[0124] The first acquisition unit 10 is used to acquire the connection status between physical resources of the server physical layer and obtain the physical topology relationship. The physical resources include the baseboard management controller and the central controller.

[0125] The determining unit 20 is used to determine the node distribution of non-uniform memory access nodes of the server based on physical topology information. The non-uniform memory access node includes at least one central processing unit and physical resources directly connected to the central processing unit, or the non-uniform memory access node includes the core of the central processing unit and physical resources directly connected to the core.

[0126] The second acquisition unit 30 is used to acquire resource requirement information of the server's virtual layer;

[0127] The first processing unit 40 is used to bind the virtualized entity of the virtual layer to the target non-uniform memory access node according to the resource demand information and node distribution, and obtain the binding result. The target non-uniform memory access node is the non-uniform memory access node corresponding to the physical resource to be called by the virtualized entity.

[0128] The first control unit 50 is used to perform cross-layer collaborative management of resources between the physical layer and the virtual layer by applying the binding results.

[0129] To achieve the binding between the virtual resources and physical resources mentioned above, in one optional implementation, the first processing unit includes:

[0130] The first processing module is used to construct the mapping relationship between virtualized entities and non-uniform memory access nodes using a greedy algorithm based on resource demand information and node distribution.

[0131] The second processing module is used to configure the physical resources in the non-uniform memory access nodes according to the mapping relationship in order to achieve binding.

[0132] To optimize the matching relationship between physical and virtual resources, in one optional implementation, the first processing module includes:

[0133] The first determination submodule is used to determine the physical resources of each non-uniform memory access node based on the node distribution. The physical resources include the number of processor cores, available memory capacity, available storage capacity, and network devices.

[0134] The first calculation submodule is used to quantify and score the physical resources of each non-uniform memory access node to obtain the corresponding physical resource quantity.

[0135] The second determination submodule is used to determine the required physical resources for each virtualization entity based on the resource requirement information. The required physical resources include the number of virtual processors, the amount of memory occupied, the amount of storage occupied, and the communication rate baseline.

[0136] The second calculation submodule is used to quantify and score the physical resources of each virtualized entity to obtain the corresponding amount of physical resources occupied.

[0137] The first processing submodule is used to sort virtualized entities according to the amount of physical resources they occupy, and then allocate the virtualized entities to non-uniform memory access nodes with the largest corresponding amount of physical resources and update the physical resource amounts to obtain the mapping relationship.

[0138] To dynamically balance the load on physical resources and improve the performance of virtual resources, in one optional implementation, the first control unit includes:

[0139] The first acquisition module is used to acquire the historical operating status of physical resources within a first preset time period and obtain historical load data.

[0140] The third processing module is used to use a neural network to predict the operating status of physical resources within a second preset time period in the future based on historical load data, and to obtain predicted load data.

[0141] The fourth processing module is used to perform load balancing operations on physical resources based on the binding results when the predicted load data is greater than the first threshold and the duration is greater than the second threshold.

[0142] To achieve accurate prediction of load change trends, in one optional implementation, the third processing module includes:

[0143] The first processing submodule is used to predict the operating status of physical resources within a second preset time period based on historical load data using a long short-term memory network, and to obtain the first load data.

[0144] The second processing submodule is used to use a time series prediction library to predict the operating status of physical resources within a second preset time period based on historical load data, and obtain the second load data.

[0145] The third processing submodule is used to predict the operating status of physical resources within a second preset time period based on historical load data using an autoregressive integrated moving average network, and obtain the third load data.

[0146] The fourth processing submodule is used to fuse the first load data, the second load data, and the third load data using a meta-model to obtain the predicted load data. The meta-model is one or more of linear regression, decision tree, and neural network.

[0147] To avoid excessive physical resource load, in one optional implementation, the fourth processing module includes:

[0148] The fifth processing submodule is used to migrate some of the virtual resources deployed on the target non-uniform memory access node to other non-uniform memory access nodes when the predicted load data of the target non-uniform memory access node is greater than the first threshold.

[0149] The sixth processing submodule is used to determine the processor or processor core as the first target object when the predicted load data of any processor or processor core in the target non-uniform memory access node is greater than the first threshold, and to traverse other processors or processor cores in the target non-uniform memory access node to determine the processor or processor core whose predicted load data is less than the second threshold, and obtain the second target object.

[0150] The seventh processing submodule is used to allocate the physical resources of the second target object to the first target object until the predicted load data of the first target object is less than or equal to the first threshold.

[0151] To ensure the security of collaborative management between the virtual layer and the physical layer, in one optional implementation, the first control unit further includes:

[0152] The second acquisition module is used to monitor the behavior of processes within the container in the virtual layer to obtain the target behavior, monitor the network activity of the container to obtain the communication mode and connection operation, and monitor the consumption of physical resources by the container to obtain the target utilization rate.

[0153] The fifth processing module is used to perform anomaly detection based on target behavior, communication mode, connection operation and target occupancy rate using a pre-trained deep learning-based behavior model;

[0154] The sixth processing module is used to restart or isolate the container based on the binding result if the container exhibits abnormal behavior.

[0155] To improve the efficiency of resource management, in one optional implementation, the first control unit further includes:

[0156] The third acquisition module is used to control the sensors of the physical layer to monitor the historical operating status of the physical resources corresponding to the virtual entity within a third preset time period according to the binding result when the virtualized entity in the virtual layer has a fault, and to obtain the first monitoring data.

[0157] The fourth acquisition module is used to acquire the historical operating status of the virtualized entity within a third preset time period to obtain the second detection data;

[0158] The seventh processing module is used to embed the first monitoring data and the second detection data into a preset fault propagation map;

[0159] The eighth processing module is used to determine the faulty physical resources of the physical layer based on a preset fault propagation map using a graph neural network.

[0160] To ensure the accuracy of physical layer sampling data, in one optional embodiment, the above-mentioned apparatus further includes:

[0161] The second acquisition unit is used to collect the running status of the physical layer and the virtual layer according to a preset sampling frequency after binding the virtualized entity of the virtual layer with the non-uniform memory access node to which the physical resource to be called by the virtualized entity belongs, and obtain sampling data.

[0162] The second processing unit is used to determine the rate of change of the sampled data based on the sampled data, obtain the data change rate, and determine the system load based on the sampled data, obtain the system load rate.

[0163] The second control unit is used to increase the sampling frequency when the data change rate is greater than the fourth threshold, decrease the sampling frequency when the data change rate is less than the fifth threshold and the system load rate is greater than the sixth threshold, and increase the sampling frequency when the system load rate is less than the seventh threshold.

[0164] For a description of the features in the embodiment corresponding to the cross-layer collaborative resource management device, please refer to the relevant description of the embodiment corresponding to the cross-layer collaborative resource management method, which will not be repeated here.

[0165] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the cross-layer collaborative resource management method.

[0166] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the cross-layer collaborative resource management method when it is run.

[0167] 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.

[0168] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described XX method embodiments.

[0169] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above embodiments of the cross-layer resource collaborative management method.

[0170] 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.

[0171] The foregoing has provided a detailed description of a cross-layer collaborative resource management 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 cross-layer collaborative management of resources, characterized in that, include: The connection status between physical resources in the server's physical layer is obtained to acquire physical topology information. The physical resources include a baseboard management controller and a central processing unit. The baseboard manager and the central processing unit are connected via a peripheral component interconnection fast expansion bus. The baseboard manager is directly connected to the memory via a high-speed channel. The baseboard manager is connected to the power supply unit via an intelligent platform management bus. The distribution of non-uniform memory access nodes of the server is determined based on the physical topology information. The non-uniform memory access node includes at least one of the central processing units and the physical resources directly connected to the central processing unit, or the non-uniform memory access node includes at least the core of the central processing unit and the physical resources directly connected to the core. The resource requirement information of the server's virtual layer is obtained. The baseboard management controller accesses the virtual layer through a unified interface gateway. The virtual layer includes a virtualization management layer and a management platform for user operation. Based on the resource requirement information and the node distribution, the virtualized entity of the virtual layer is bound to the target non-uniform memory access node to obtain the binding result. The target non-uniform memory access node is the non-uniform memory access node corresponding to the physical resource that the virtualized entity needs to call. The binding result is used to perform cross-layer collaborative management of resources between the physical layer and the virtual layer; Applying the binding result to perform cross-layer collaborative management of resources between the physical layer and the virtual layer includes: obtaining the historical operating status of the physical resources within a first preset time period to obtain historical load data; and using a neural network to predict the operating status of the physical resources within a future second preset time period based on the historical load data to obtain predicted load data. A neural network is used to predict the operating status of the physical resources within a second preset time period based on historical load data, resulting in predicted load data, including: The first load data is obtained by using a long short-term memory network to predict the operating status of the physical resources within the second preset time period based on the historical load data; The operating status of the physical resources within the second preset time period is predicted using a time series prediction library based on the historical load data, thereby obtaining the second load data; An autoregressive integrated moving average network is used to predict the operating status of the physical resources within the second preset time period based on the historical load data, thereby obtaining the third load data; The first load data, the second load data, and the third load data are fused using a meta-model to obtain the predicted load data. The meta-model is one or more of linear regression, decision tree, and neural network.

2. The resource cross-layer collaborative management method according to claim 1, characterized in that, Based on the resource requirement information and the node distribution, the virtualized entities of the virtual layer are bound to the target non-uniform memory access nodes to obtain the binding results, including: Based on the resource requirement information and the node distribution, a greedy algorithm is used to construct the mapping relationship between the virtualized entity and the non-uniform memory access node; Configure the physical resources included in the non-uniform memory access node according to the mapping relationship to achieve binding.

3. The resource cross-layer collaborative management method according to claim 2, characterized in that, Based on the resource requirement information and the node distribution, a greedy algorithm is used to construct the mapping relationship between the virtualized entities and the non-uniform memory access nodes, including: The physical resources of each of the non-uniform memory access nodes are determined based on the node distribution; The physical resources of each non-uniform memory access node are quantitatively scored to obtain the corresponding physical resource quantity; The required physical resources for each virtualized entity are determined based on the resource requirement information. The required physical resources include the number of virtual processors, the amount of memory occupied, the amount of storage occupied, and the communication rate baseline. The physical resources of each virtualized entity are quantitatively scored to obtain the corresponding amount of physical resources occupied; The virtualized entities are sorted according to the amount of physical resources they occupy, and then the virtualized entities are sequentially assigned to the non-uniform memory access nodes with the largest corresponding amount of physical resources, and the amount of physical resources is updated to obtain the mapping relationship.

4. The resource cross-layer collaborative management method according to claim 1, characterized in that, Applying the binding result to perform cross-layer collaborative management of resources between the physical layer and the virtual layer includes: If the predicted load data is greater than a first threshold and the duration is greater than a second threshold, load balancing is performed on the physical resources based on the binding result.

5. The resource cross-layer collaborative management method according to claim 4, characterized in that, Based on the binding result, a load balancing operation is performed on the physical resource, including: If the predicted load data of the target non-unified memory access node is greater than a first threshold, some of the virtualized entities deployed on the target non-unified memory access node will be migrated to other non-unified memory access nodes. If the predicted load data of any processor or processor core in the target non-uniform memory access node is greater than the first threshold, the processor or processor core is identified as the first target object. Other processors or processor cores in the target non-uniform memory access node are traversed to identify processors or processor cores whose predicted load data is less than the second threshold, and a second target object is obtained. The physical resources of the second target object are allocated to the first target object until the predicted load data of the first target object is less than or equal to the first threshold.

6. The resource cross-layer collaborative management method according to any one of claims 1 to 5, characterized in that, Applying the binding result to perform cross-layer collaborative management of resources between the physical layer and the virtual layer includes: Monitor the behavior of processes within the container of the virtual layer to obtain the target behavior; monitor the network activity of the container to obtain the communication mode and connection operation; monitor the consumption of physical resources by the container to obtain the target utilization rate. A pre-trained deep learning-based behavior model is used to perform anomaly detection based on the target behavior, the communication mode, the connection operation, and the target occupancy rate. If the container exhibits abnormal behavior, the container may be restarted or isolated based on the binding result.

7. The resource cross-layer collaborative management method according to any one of claims 1 to 5, characterized in that, Applying the binding result to perform cross-layer collaborative management of resources between the physical layer and the virtual layer includes: In the event of a fault in the virtualized entity of the virtual layer, the sensors of the physical layer are controlled to monitor the historical operating status of the physical resources corresponding to the virtualized entity within a third preset time period according to the binding result, and the first monitoring data is obtained. Obtain the historical operating status of the virtual entity within the third preset time period to obtain the second detection data; Embed the first monitoring data and the second detection data into a preset fault propagation map; A graph neural network is used to determine the faulty physical resources of the physical layer based on the preset fault propagation map.

8. The resource cross-layer collaborative management method according to any one of claims 1 to 5, characterized in that, After binding the virtualized entity of the virtual layer to the non-uniform memory access node to which the physical resource to be accessed by the virtualized entity belongs, the process includes: The operating status of the physical layer and the virtual layer is collected according to a preset sampling frequency to obtain sampling data; The rate of change of the sampled data is determined based on the sampled data to obtain the data change rate. The server load is determined based on the sampled data to obtain the server load rate. If the data change rate is greater than a fourth threshold, increase the sampling frequency; if the data change rate is less than a fifth threshold and the server load rate is greater than a sixth threshold, decrease the sampling frequency; if the server load rate is less than a seventh threshold, increase the sampling frequency.

9. A substrate manager, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the resource cross-layer collaborative management method as described in any one of claims 1 to 8 when executing the computer program.

Images