Edge cloud-based computing power elastic scaling server hardware architecture design method

Abstract

This invention relates to the field of edge computing and cloud computing convergence technology, specifically a hardware architecture design method for elastically scalable servers based on edge cloud computing power. The method includes: constructing a multi-level edge cloud hardware resource pool based on the terminal device density and business load characteristics of the deployment area; embedding hardware resource probes in computing nodes to collect real-time data on instruction throughput, memory access latency, chip temperature, and power consumption; converging the data to a regional coordinator, which generates configuration instructions based on a scaling strategy related to business load and hardware performance models; dynamically starting and stopping specific computing nodes and storage units; and reconfiguring the port bandwidth and routing tables of network switching devices to form a physical hardware topology that matches current business needs; and synchronizing the topology and status data to a cloud management center for policy optimization. This method achieves dynamic reorganization of hardware resources at the physical layer and precise scheduling based on microarchitecture performance data, improving resource adaptability and system energy efficiency.

Description

Technical Field

[0001] This invention relates to the field of edge computing and cloud computing convergence technology, and in particular to a hardware architecture design method for elastic scaling servers based on edge cloud computing power. Background Technology

[0002] Currently, virtualization or containerization technologies are commonly used in edge computing environments to achieve logical allocation and elastic scaling of computing power on pre-deployed fixed hardware resources. This approach treats the underlying physical infrastructure as a static resource pool, where the connection topology and bandwidth configuration between servers, storage devices, and network switching devices typically remain unchanged after deployment. When business demands switch between scenarios with varying computing characteristics and resource dependencies, the fixed physical hardware architecture struggles to adapt, easily leading to overload of some hardware resources while others remain idle, resulting in suboptimal overall energy efficiency and performance.

[0003] Existing resource scaling decisions primarily rely on system-level performance metrics provided by the operating system or virtualization layer. These metrics indirectly reflect the hardware resource usage by upper-layer software and cannot directly and accurately measure the true performance state and physical constraints within the hardware. They cannot distinguish whether high loads stem from efficient execution of the computing cores or from memory subsystem latency; nor can they correlate the impact of chip power consumption and thermal status on actual computing power in real time. Scaling mechanisms based on such coarse-grained monitoring data struggle to achieve precise matching between business load and the characteristics of the underlying hardware microarchitecture.

[0004] There is a need for a method that can overcome the limitations of static physical hardware topology and dynamically reconstruct hardware connections based on real-time business needs. At the same time, there is a need for a mechanism that can perform resource scheduling based on accurate performance data and physical status at the hardware level, in order to solve the problems of inaccurate resource adaptation and low energy efficiency in existing technologies. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a hardware architecture design method for elastic scaling servers based on edge cloud computing power.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a hardware architecture design method for an edge cloud-based elastic scaling server, comprising:

[0007] Based on the density distribution of terminal devices and the characteristics of business load in the deployment area, a multi-level edge cloud hardware resource pool is constructed, in which each level of the hardware resource pool contains different types and specifications of computing nodes, storage units and network switching devices.

[0008] Hardware resource probes are implanted on each computing node of the multi-level edge cloud hardware resource pool. The real-time power consumption, chip temperature, instruction throughput and memory access latency data of the computing node are collected in real time through the hardware resource probes.

[0009] The collected real-time power consumption, chip temperature, instruction throughput, and memory access latency data are aggregated to the regional coordinator, which generates hardware resource configuration instructions according to a preset elastic scaling strategy. The elastic scaling strategy is associated with the service load type and the hardware resource performance model.

[0010] According to the hardware resource configuration instructions, specific computing nodes and storage units in the multi-level edge cloud hardware resource pool are started or put into hibernation, and the port bandwidth and routing table of the network switching equipment are dynamically reconfigured to form a physical hardware topology that meets the current business needs.

[0011] The updated physical hardware topology information and real-time status data of the computing nodes are synchronized to the cloud management center, triggering optimization of subsequent elastic scaling strategy parameters.

[0012] As a further aspect of the present invention, the construction of a multi-level edge-cloud hardware resource pool based on the terminal device density distribution and service load characteristics of the deployment area specifically includes:

[0013] Obtain historical location data and service request logs of all access terminal devices within the deployment area, and identify hotspot areas with high terminal device density and time windows with dense service requests through spatiotemporal clustering algorithms;

[0014] Analyze the business request logs to extract business load characteristics under different time windows. The business load characteristics include the proportion of compute-intensive load, the proportion of input / output-intensive load, and the proportion of network latency-sensitive load.

[0015] Based on the physical location of the hotspot area and the characteristics of the service load, the deployment area is divided into multiple service coverage levels, with each level corresponding to a different network latency limit and computing power supply scale.

[0016] Plan physical sites for the service coverage of each level, and deploy heterogeneous computing node clusters, hybrid storage arrays and programmable network switching devices in each physical site to form the hardware resource pool of the level.

[0017] Establish high-speed redundant network links between hardware resource pools at different levels, and configure cross-level resource discovery and communication protocols to complete the construction of multi-level edge cloud hardware resource pools.

[0018] As a further aspect of the present invention, the step of embedding hardware resource probes on each computing node of the multi-level edge cloud hardware resource pool specifically involves:

[0019] Develop corresponding kernel modules for computing nodes of each architecture in a multi-level edge cloud hardware resource pool. The kernel modules can directly access the performance monitoring unit and baseboard management controller of the computing node.

[0020] The kernel module reads the performance counters of the central processing unit of the computing node at a fixed sampling period to obtain instruction throughput, cache hit rate and branch prediction error rate data.

[0021] Meanwhile, the kernel module obtains real-time power consumption readings of the computing node and temperature sensor data of each major chip component from the baseboard management controller interface.

[0022] A custom memory access latency test code segment is injected into the kernel module to periodically measure memory read and write latency and record the distribution of memory access latency.

[0023] The instruction throughput data, cache hit rate data, branch prediction error rate data, real-time power consumption readings, temperature sensor data, and memory access latency distribution data are encapsulated into a unified monitoring data frame and sent to the regional coordinator through the management network port.

[0024] As a further aspect of the present invention, the elastic scaling strategy is associated with the service load type and the hardware resource performance model, specifically as follows:

[0025] Multiple standard service load types are predefined, and a corresponding hardware resource performance model is established for each standard service load type. The hardware resource performance model describes the consumption function of computing, storage, and network resources of the standard service load type.

[0026] Establish a library of elastic scaling strategies. Each elastic scaling strategy includes trigger conditions, load type identification rules, and hardware resource configuration rules. The trigger conditions are set based on data thresholds collected by hardware resource probes.

[0027] After the regional coordinator receives the hardware resource probe data, it matches the current instruction throughput characteristics, memory access patterns and network traffic characteristics with the standard service load types to identify the currently dominant service load type.

[0028] Based on the identified business load type, the corresponding hardware resource performance model is invoked to predict the demand for various hardware resources required to meet the service level agreement in the next time window.

[0029] Based on the overall utilization rate of the current multi-level edge cloud hardware resource pool and the hardware resource demand, a matching hardware resource configuration rule is selected from the elastic scaling policy library to generate specific hardware resource configuration instructions.

[0030] As a further aspect of the present invention, the generation of specific hardware resource configuration instructions specifically includes:

[0031] The hardware resource configuration instructions include node control instructions, storage allocation instructions, and network reconfiguration instructions.

[0032] The node control command specifies the physical location identifier of the standby computing node that needs to be woken up from the hibernation state and the initial power consumption strategy after wake-up, or specifies the physical location identifier and data migration target of the computing node that needs to enter a low-power hibernation state.

[0033] The storage allocation instructions specify the power state switching of storage units associated with compute node start-up and shutdown operations, as well as the migration path of data between storage media with different performance in the hybrid storage array;

[0034] The network reconfiguration command specifies that the newly activated computing nodes are allocated uplink ports and bandwidth of network switching devices, and the routing tables and access control lists of the relevant switching devices are updated to ensure network connectivity.

[0035] The hardware resource configuration instructions also include an execution sequence number and a description of the dependencies between each instruction, ensuring that the execution agents under the regional coordinator can execute complex resource allocation operations in an orderly manner.

[0036] As a further aspect of the present invention, the specific computing nodes and storage units in the multi-level edge cloud hardware resource pool that are activated or put into hibernation are specifically:

[0037] The regional coordinator's execution agent sends remote power-on or power-off signals to the target computing node through the intelligent power distribution unit, based on the node control instructions in the hardware resource configuration instructions.

[0038] For computing nodes that need to be woken up, the execution agent monitors their power-on self-test process and writes the initial power consumption and frequency strategy specified by the hardware resource configuration instructions into their firmware after their baseboard management controller is ready.

[0039] For compute nodes that need to hibernate, the execution agent first initiates the migration of hot data from its memory, persists the data to the specified storage unit, and then triggers the power-down process of the compute node after the data migration is completed.

[0040] Simultaneously, the execution agent controls the power module of the target storage unit or initiates data migration operations between storage media according to the storage allocation instructions, so that the availability status of storage resources is consistent with the start / stop status of the compute nodes, and records the start / stop operation results and timestamps of all compute nodes and storage units, forming a hardware resource change log.

[0041] As a further aspect of the present invention, the step of dynamically reconfiguring the port bandwidth and routing table of the network switching device to form a physical hardware topology that meets the current service requirements specifically includes:

[0042] The execution agent logs into the relevant programmable network switching device via the network management protocol based on the network reconfiguration instructions in the hardware resource configuration instructions;

[0043] Send port configuration commands to programmable network switching devices to enable and allocate specified bandwidth to the physical ports where newly added computing nodes are located, or to release the port bandwidth occupied by computing nodes that are about to go into hibernation.

[0044] Update the routing table of the programmable network switching device, add or delete network routing entries pointing to newly added or removed computing nodes, and synchronously update the access control list related to the routing policy;

[0045] In scenarios involving adjustments to hardware resource pools across multiple levels, the configuration of network switching devices at different levels is coordinated to ensure that the end-to-end network path meets latency and bandwidth requirements after reconfiguration.

[0046] After all network switching devices have been configured and updated, the agent is executed to perform network connectivity tests to verify that all compute nodes and storage units within the new physical hardware topology can communicate normally.

[0047] As a further aspect of the present invention, the step of synchronizing the updated physical hardware topology information and the real-time status data of the computing nodes to the cloud management center specifically includes:

[0048] The regional coordinator aggregates hardware resource change logs, updated network switching device configuration information, and real-time status data of all currently active computing nodes, and packages them into a status synchronization data packet.

[0049] The status synchronization data packets are compressed and encrypted, and are uploaded to the cloud management center through a dedicated management channel in the high-speed redundant network link;

[0050] After receiving the status synchronization data packet, the cloud management center decrypts and parses the information in it, and updates the real-time status of the multi-level edge cloud hardware resource pool in the corresponding area of ​​its global resource graph database.

[0051] The cloud management center's status monitoring interface displays the updated physical hardware topology in real time, including the location, status, resource utilization, and network connectivity of all computing nodes.

[0052] As a further aspect of the present invention, the triggering of subsequent optimization of elastic scaling strategy parameters specifically includes:

[0053] The cloud management center's analytics engine acquires historical operational datasets, including hardware resource change logs in the status synchronization data packets, business load characteristics, and final service quality metrics.

[0054] The analytics engine mines historical operational datasets to evaluate the timing of past elastic scaling strategies, the accuracy of resource allocation, and the achievement of actual service quality goals.

[0055] Based on the evaluation results, reinforcement learning algorithms are used to adjust the trigger condition thresholds of relevant strategies in the elastic scaling strategy library or the resource allocation ratio parameters in the hardware resource configuration rules.

[0056] The optimized elastic scaling strategy parameters are sent to the corresponding regional coordinator to replace the old parameters in its strategy library. In subsequent decision cycles, the regional coordinator will use the optimized parameters to generate hardware resource configuration instructions, thus forming a closed-loop optimization process.

[0057] As a further aspect of the present invention, the step of injecting a custom memory access latency test code segment into the kernel module to periodically measure memory read / write latency specifically involves:

[0058] The kernel module pre-allocates a test buffer in the user space memory of the compute node and ensures that the test buffer is locked in physical memory to prevent it from being swapped out;

[0059] The kernel module periodically initiates a memory latency measurement task, which performs a series of read and write operations with specific access patterns to the test buffer, including sequential access and random access.

[0060] Before and after each read / write operation, the operation time is recorded by reading the high-precision timer of the computing node, thus obtaining the latency data of a single memory access;

[0061] Collect latency data for all memory access operations within a period, calculate their average, maximum, and percentile values ​​to form memory access latency distribution data describing the current performance of the memory subsystem;

[0062] The kernel module encapsulates the memory access latency distribution data along with other performance monitoring data into a monitoring data frame to complete this data collection.

[0063] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0064] By controlling the regional coordinator, the physical computing nodes and storage units in the multi-level hardware resource pool are directly started or put into hibernation, and the port bandwidth and routing tables of network switching devices are dynamically reconfigured simultaneously, enabling real-time on-demand construction of the server hardware physical connection topology. This technology allows discrete, heterogeneous hardware resources to be flexibly combined into different physical cluster forms according to the immediate needs of the business load. The business load is directed to run in a physical hardware environment specifically built for it, rather than competing for virtualization resources on shared fixed hardware. This eliminates the performance bottlenecks and resource mismatches inherent in the combination of static network links and fixed equipment, allowing the physical form of the infrastructure to closely match the actual computing characteristics and data flow patterns of the business, achieving efficient adaptation and integration of hardware resources at the physical layer.

[0065] By embedding hardware resource probes to directly collect low-level data such as instruction throughput, memory access latency, chip temperature, and real-time power consumption, and aggregating this data to the regional coordinator, this data is correlated with a pre-defined workload-hardware performance model to generate resource allocation instructions. This technology shifts the basis for elastic scaling decisions from indirect utilization metrics at the operating system level to the execution efficiency and physical operating status of the hardware microarchitecture. The resource scheduling system can accurately identify the root cause of performance bottlenecks and predict physical constraints. Workloads are thus guided to the physical computing units whose instruction throughput, memory access characteristics, or heat dissipation conditions best match their needs. This achieves precise matching of computing power supply and business demands at the microarchitecture level, while directly incorporating power consumption and heat dissipation constraints into resource scheduling, improving overall energy efficiency. Attached Figure Description

[0066] Figure 1 This is a flowchart of the hardware architecture design method for an edge cloud-based elastic scaling server described in this invention.

[0067] Figure 2 A flowchart for implanting and running a hardware resource probe;

[0068] Figure 3 This is a graph showing the changes in performance metrics during the strategy optimization phase.

[0069] Figure 4 Radar chart comparing the multi-dimensional performance of different elastic scaling strategies;

[0070] Figure 5 This is a daily variation graph of transmission latency across multiple levels of edge cloud. Detailed Implementation

[0071] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0072] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0073] See Figure 1 Based on the density distribution of terminal devices and the characteristics of service load in the deployment area, a multi-level edge cloud hardware resource pool is constructed. Each level of the hardware resource pool contains different types and specifications of compute nodes, storage units, and network switching devices. Hardware resource probes are embedded on each compute node in the multi-level edge cloud hardware resource pool to collect real-time power consumption, chip temperature, instruction throughput, and memory access latency data. The collected real-time power consumption, chip temperature, instruction throughput, and memory access latency data are aggregated to the regional coordinator, which generates hardware resource configuration instructions according to a preset elastic scaling strategy. The elastic scaling strategy is associated with the service load type and the hardware resource performance model. Based on the hardware resource configuration instructions, specific compute nodes and storage units in the multi-level edge cloud hardware resource pool are started or suspended. The port bandwidth and routing tables of the network switching devices are dynamically reconfigured to form a physical hardware topology that meets the current service requirements. The updated physical hardware topology information and the real-time status data of the compute nodes are synchronized to the cloud management center, triggering optimization of subsequent elastic scaling strategy parameters.

[0074] In one embodiment of the present invention, the executing entity acquires historical location data and service request logs of all access terminal devices within a deployment area, which can be the central urban area of ​​a large city. The historical location data records the geographic coordinates of each terminal device every fifteen minutes over the past thirty days. The service request logs record the type, timestamp, request duration, and processing result of service requests initiated by each terminal device within the same period. These logs are processed using a spatiotemporal clustering algorithm, specifically by using geographic coordinates and timestamps as three-dimensional clustering features. In a specific implementation, an optional spatiotemporal clustering algorithm is the DBSCAN algorithm, whose density can reach the radius parameter. Set to reflect the distance of the average coverage radius of the base station, and the minimum number of points in the neighborhood of the core point. The algorithm is configured based on the typical concurrent volume of business requests. It identifies hotspot areas with high density of multiple terminal devices, such as the coverage areas of central business districts, major transportation hubs, and sports venues. Simultaneously, the algorithm identifies time windows with high volume of business requests, such as 9:00 AM to 11:00 AM on weekdays, and several consecutive hours during large-scale cultural and sports events.

[0075] In practice, analyzing business request logs involves extracting business load characteristics across different time windows. Taking the central business district's weekday morning hours (9:00 AM to 11:00 AM) as an example, the executing entity parses the business request logs, classifying and statistically analyzing the service type and related computing resource descriptors for each log entry. In practice, the load characteristic extraction process calculates the proportions of compute-intensive load, input / output-intensive load, and network latency-sensitive load. The compute-intensive load proportion is the ratio of requests belonging to scientific computing, image rendering, or model training categories to the total number of requests per unit time. The input / output-intensive load proportion is the ratio of requests involving large-scale data access or streaming media processing to the total number of requests per unit time. The network latency-sensitive load proportion is the ratio of interactive requests with a clear upper limit on request response latency to the total number of requests per unit time. In practice, an optional load characteristic calculation formula is: Compute-intensive load proportion:

[0076]

[0077] in: This indicates the proportion of computationally intensive loads. This represents the number of computationally intensive service requests identified within a specific time window. This represents the total number of service requests within the same time window. This analysis process is repeated for each identified hotspot region and its associated time window, resulting in a feature map describing the spatiotemporal changes in regional load.

[0078] In implementation, based on the physical location of hotspot areas and calculated business load characteristics, the executing entity divides the entire deployment area into multiple service coverage levels. This tiered division is based on different combinations of network latency limits and computing power supply scale. For example, the first-tier service coverage is defined as the core area of ​​the hotspot region, with a network latency limit of less than or equal to 5 milliseconds and a computing power supply scale sufficient to handle 100,000 compute-intensive requests per second. The second-tier service coverage is defined as the surrounding radiation area of ​​the hotspot region, with a network latency limit of less than or equal to 15 milliseconds and a computing power supply scale sufficient to handle 50,000 input / output intensive requests per second. The third-tier service coverage covers a wide area outside the hotspot region, with a network latency limit of less than or equal to 50 milliseconds and a computing power supply scale sufficient for regular business needs. The latency limit and computing power threshold for each tier are set by matching the identified business load characteristics with a preset service level agreement.

[0079] In implementation, the location and scale of physical sites are planned for each service coverage level. For the first tier of service coverage, physical sites are planned within multiple core data centers in the central business district. Each physical site deploys heterogeneous compute node clusters, including compute nodes equipped with high-performance general-purpose processors and high-performance graphics processors. In practice, hybrid storage arrays include fast storage areas based on non-volatile memory media and persistent storage areas based on large-capacity hard drives. Programmable network switching equipment utilizes high-bandwidth switches supporting software-defined networking protocols. These heterogeneous compute node clusters, hybrid storage arrays, and programmable network switching equipment together constitute the first-tier hardware resource pool. For the second tier of service coverage, physical sites are planned within aggregation data centers in various districts of the city. The compute node clusters deployed within each physical site emphasize compute nodes equipped with large memory and high-speed solid-state drives to match the characteristics of input / output intensive loads, constituting the second-tier hardware resource pool. Physical sites are planned for the service coverage of the third tier. These sites are located in large cloud data centers on the edge of the city, where more general-purpose computing and storage resources are deployed to form a hardware resource pool for the third tier.

[0080] In implementation, high-speed redundant network links are established between hardware resource pools at different levels. Multiple high-bandwidth, low-latency direct fiber optic links are deployed between the first-level and second-level hardware resource pools to form a high-speed redundant network. Similarly, a backbone network connection with redundant paths is deployed between the second-level and third-level hardware resource pools. Cross-level resource discovery and communication protocols are configured, enabling hardware resource pools within a single level to be aware of the status and network addresses of available resources in other levels. After completing the above physical site planning, equipment deployment, network interconnection, and protocol configuration, the construction of a multi-level edge-cloud hardware resource pool is complete.

[0081] See Figure 2 In one embodiment of the present invention, in a multi-level edge cloud hardware resource pool, hardware resource probes are embedded in computing nodes in the form of kernel modules. Specifically, a corresponding kernel module is developed for each architecture of the computing nodes in the multi-level edge cloud hardware resource pool, including x86 and ARM architectures. The kernel module can directly access the performance monitoring unit and the baseboard management controller of the computing node. The performance monitoring unit is a hardware performance counter provided within the central processing unit (CPU), and the baseboard management controller is a dedicated management chip that operates independently of the CPU. In some embodiments, the kernel module establishes communication with the model-specific registers of the performance monitoring unit by loading a custom driver and calls the intelligent platform management interface provided by the baseboard management controller.

[0082] In implementation, the kernel module reads the performance counters of the compute node's CPU at a fixed sampling period of 2 seconds. At the beginning of each sampling period, the kernel module sends an instruction to the CPU's model-specific register to query and record the initial value of the performance counters. At the end of the sampling period, it queries and records the final value of the performance counters again. The acquired performance counter data includes instruction throughput, cache hit rate, and branch prediction error rate. Instruction throughput is the total number of instructions executed by the compute node in each sampling period, obtained by reading the CPU core's INST_RETIRED.ANY performance counter event. Cache hit rate is the proportion of successful accesses to the compute node's last-level cache out of the total number of accesses, calculated by reading the CPU's LLC_REFERENCES and LLC_MISSES performance counter events. Branch prediction error rate is the proportion of incorrectly predicted branch instructions out of the total number of executed branch instructions, calculated by reading the CPU's BR_MISP_RETIRED.ALL_BRANCHES and BR_INST_RETIRED.ALL_BRANCHES performance counter events. It is understandable that for different CPU architectures, the specific performance counter event names used to obtain the same performance metrics may be different, and kernel modules contain configuration mapping tables for different architectures.

[0083] In practical implementation, the kernel module obtains real-time power consumption readings of the compute node and temperature sensor data of each major chip component from the baseboard management controller interface. The kernel module locates the input / output address space of the baseboard management controller through the device tree or system management bus of the compute node's operating system. In some embodiments, the kernel module periodically sends read requests to the power sensor register of the baseboard management controller, and the baseboard management controller returns real-time power consumption readings for the entire compute node or each power rail, in watts. The kernel module also sends read requests to the temperature sensor register of the baseboard management controller, and the baseboard management controller returns temperature sensor data for each major chip component, such as the CPU package temperature, DRAM temperature, and SSD controller temperature, in degrees Celsius. The data obtained from the baseboard management controller and the data obtained from the performance monitoring unit are synchronized in timestamps.

[0084] In implementation, the kernel module pre-allocates a 1-gigabyte test buffer in the user space memory of the compute node and ensures that the test buffer is locked in physical memory to prevent it from being swapped to external storage devices by the operating system's swapping mechanism. The kernel module locks the physical memory pages of the test buffer by calling the `mlock` system call. The kernel module periodically initiates a memory latency measurement task, with an execution cycle of 10 seconds, independent of the performance counter sampling cycle. The memory latency measurement task performs a series of read and write operations with specific access patterns on the test buffer, including sequential and random access. Sequential access involves linearly reading or writing each memory address in the test buffer. Random access uses a pseudo-random number generator to generate non-contiguous memory addresses for reading or writing. In implementation, the optional memory latency test code segment wraps memory load or store instructions with the `rdtsc` instruction, which reads the CPU's timestamp counter. Before each read / write operation, the `rdtsc` instruction is executed once and the timestamp is recorded. After each read / write operation, immediately execute the rdtsc command again and record the timestamp. Latency of a single access From the formula:

[0085]

[0086] in: This represents the latency of a single memory access, measured in central processing unit clock cycles. This indicates the timestamp counter reading before the operation began. This represents the timestamp counter reading after the operation is completed. It can be understood that this delay value includes the overhead of executing the rdtsc instruction itself, which will be compensated for by a pre-calibrated baseline value when calculating the final result.

[0087] In practice, latency data for all memory access operations is collected within a cycle, with 1,000 sequential accesses and 1,000 random accesses performed within that cycle. The average, maximum, and quantile values ​​are calculated, including the 50th, 95th, and 99th quantiles, forming memory access latency distribution data describing the current memory subsystem performance. This memory access latency distribution data is time-aligned with data obtained from the performance monitoring unit and the baseboard management controller within the same acquisition window. The kernel module encapsulates instruction throughput data, cache hit rate data, branch prediction error rate data, real-time power consumption readings, temperature sensor data, and memory access latency distribution data into a unified monitoring data frame. The monitoring data frame format includes a frame header, node identifier, timestamp, various data fields, and a cyclic redundancy check (CRC) code. In practice, the kernel module sends the monitoring data frame as a User Datagram Protocol (UDP) packet to the network address and port specified by the area coordinator via the reserved management network port on the compute node, completing this data acquisition.

[0088] In one embodiment of the present invention, several standard service load types are predefined, including real-time video analytics, batch scientific computing, interactive online services, and offline big data processing. In specific implementations, a corresponding hardware resource performance model is established for each standard service load type. This hardware resource performance model describes the consumption function of computing, storage, and network resources by the standard service load type. Taking real-time video analytics as an example, its hardware resource performance model is defined as the consumption of computing resources... Calculation resource consumption It is the number of concurrent video streams. Video resolution The number of floating-point operations per second required for a unit video stream The function, that is:

[0089]

[0090] in: This represents the total floating-point computing power required to handle real-time video analytics workloads, measured in trillions of floating-point operations per second. This indicates the number of video streams that need to be processed simultaneously. Indicates the video resolution coefficient. This represents the baseline floating-point computing power required to decode and analyze a unit of video stream. The hardware resource performance model also includes storage resource consumption functions and network bandwidth consumption functions. The storage resource consumption function relates to the buffer size and storage duration of each video stream, while the network bandwidth consumption function relates to the bitrate of the video stream.

[0091] In implementation, an elastic scaling policy library is established and stored in the regional coordinator as a database table. Each elastic scaling policy includes trigger conditions, load type identification rules, and hardware resource configuration rules. The trigger conditions are set based on data thresholds collected by hardware resource probes. In some embodiments, for elastic scaling policies targeting real-time video analytics, the trigger conditions are that the average instruction throughput utilization of the compute node cluster exceeds 85% for 5 minutes, or the 99th percentile of the average memory access latency exceeds 200 nanoseconds. The load type identification rules examine the characteristics of processes running on the current compute nodes, including process names containing specific keywords, network ports within a specific range, and memory access patterns exhibiting high spatial locality. The hardware resource configuration rules define that when real-time video analytics is identified as the dominant load, compute nodes equipped with high-performance graphics processors should be woken up from the resource pool, and the solid-state drive storage pool capacity of the online storage array should be increased by 20%.

[0092] In practice, after receiving hardware resource probe data, the regional coordinator performs a load type identification operation. The regional coordinator extracts instruction throughput features, memory access patterns, and network traffic features from the monitoring data frames. Instruction throughput features include the ratio of integer instructions to floating-point instructions and the ratio of single-instruction multiple-data (SIMDD) instructions. Memory access pattern features include the ratio of sequential memory access operations to random memory access operations and the distribution of cache miss rates. Network traffic features include the distribution of packet sizes and the burstiness of network port traffic. The regional coordinator matches these feature vectors with reference feature templates pre-established for each standard service load type. The matching process calculates the cosine similarity between the current feature vector and the reference feature templates for each standard service load type. In practice, the currently dominant service load type is identified as the standard service load type with the highest cosine similarity value, exceeding a preset threshold of 0.8. For example, if the current feature vector has a similarity of 0.92 with the reference feature template for real-time video analytics and 0.45 with the reference feature template for batch scientific computing, then the currently dominant service load type is identified as real-time video analytics.

[0093] In practice, based on the identified workload type, the regional coordinator invokes the corresponding hardware resource performance model. Assuming real-time video analytics is identified as the dominant workload, the regional coordinator obtains the current number of concurrent video streams from the monitoring data. For 100 channels, the average video resolution is 1080p, corresponding to the resolution coefficient. Version 1.0. The regional coordinator obtains the baseline floating-point computing power required per unit video stream from the hardware resource performance model. It performs 0.1 trillion floating-point operations per second. (This is achieved through the formula...) Calculations are performed to determine the floating-point computing power required to meet the service level agreement within the next time window. This translates to 10 trillion floating-point operations per second. The hardware resource performance model also predicts the corresponding storage resource requirements and network bandwidth requirements. The storage resource requirements are related to the total buffer size and storage strategy of the current video stream, while the network bandwidth requirements are related to the total input bitrate and output bitrate of the video stream.

[0094] In practical implementation, based on the overall utilization rate and hardware resource demand of the current multi-level edge cloud hardware resource pool, a matching hardware resource configuration rule is selected from the elastic scaling strategy library. The regional coordinator queries the resource pool status database to obtain the total floating-point computing power, idle storage capacity, and available network bandwidth provided by the currently active computing nodes. The gap between the required computing hardware resources and the currently available resources is calculated. If the currently available floating-point computing power is 8 trillion floating-point operations per second, while the predicted demand is 10 trillion floating-point operations per second, there is a gap of 2 trillion floating-point operations per second. The regional coordinator traverses the elastic scaling strategy library to find strategies whose triggering conditions match the current scenario and whose hardware resource configuration rules can fill this resource gap. In practical implementation, a hardware resource configuration rule is selected that stipulates: when a real-time video analytics load experiences a computing resource gap, and the gap is between 1 trillion and 5 trillion floating-point operations per second, two backup computing nodes are awakened from the first-level hardware resource pool, each providing 1.2 trillion floating-point operations per second.

[0095] In practical implementation, specific hardware resource configuration instructions are generated. These instructions include node control instructions, storage allocation instructions, and network reconfiguration instructions. Node control instructions specify the physical location identifier of the standby compute node to be woken from hibernation and the initial power consumption strategy after wake-up. The physical location identifier is a globally unique identifier for the compute node within the resource pool. The initial power consumption strategy specifies the initial operating frequency and voltage level of the CPU and GPU after the compute node is powered on. Storage allocation instructions specify the power state switching of storage units associated with compute node start-up and shutdown operations, as well as the migration path of data between different performance storage media in the hybrid storage array. For example, the instruction specifies pre-migrating intermediate cache data for video analytics tasks from the hard disk storage area to the non-volatile memory storage area associated with the compute node to be activated. Network reconfiguration instructions specify the allocation of uplink ports and bandwidth for network switching devices to newly activated compute nodes and update the routing tables and access control lists of the relevant switching devices. The instructions include the switch's device identifier, the physical port number to be configured, the bandwidth value to be allocated, and the target network segment information to be added to the routing table. The hardware resource allocation instructions also include an execution sequence number and a dependency description between each instruction. The execution sequence number is a monotonically increasing instruction identifier, and the dependency description indicates that the data pre-migration operation in the storage allocation instruction must be completed before the corresponding node control instruction executes the wake-up operation, and the network reconfiguration instruction must be executed after the node control instruction makes the compute node ready, ensuring that the execution agents under the regional coordinator can execute complex resource allocation operations in an orderly manner.

[0096] See Figure 3 This is a graph showing the performance metrics changes during the strategy optimization phase. Before optimization, resource utilization fluctuated between 80% and 94%, and after optimization, it stabilized in the 73%-80% range, with an average reduction of approximately 10 percentage points, effectively avoiding the risk of resource overload. Latency fluctuated between 188 and 220 ns, showing a high correlation with the utilization trend, verifying the strong correlation between "resource load and memory access performance." Starting from the 10th cycle, the fluctuation range of utilization narrowed significantly, indicating that the reinforcement learning algorithm had effectively converged and the strategy parameters tended to stabilize. When the utilization exceeded 90%, the latency simultaneously spiked to over 215 ns, which can be used as a key threshold for triggering emergency expansion. By comparing the performance data from different cycles, the optimal strategy parameters can be identified, providing data support for subsequent updates to the elastic scaling strategy library.

[0097] In one embodiment of the invention, the execution agent of the regional coordinator sends a remote power-on or power-off signal to the target computing node through an intelligent power distribution unit, based on the node control instructions in the hardware resource configuration instructions. The intelligent power distribution unit is a remotely controllable socket or power distribution unit that manages the power supply of the computing nodes. In some embodiments, the execution agent runs on a separate control server. The execution agent parses the hardware resource configuration instructions and extracts the node control instruction portion. The node control instruction specifies the physical location identifier of the standby computing node that needs to be woken up from hibernation as "Edge-Pool1-Rack2-Node5", or specifies the physical location identifier of the computing node that needs to enter a low-power hibernation state as "Edge-Pool1-Rack1-Node3". For the computing node that needs to be woken up, the execution agent sends a power-on command to the power port identified as "Edge-Pool1-Rack2-Node5" through the application programming interface of the intelligent power distribution unit. The agent monitors the power-on self-test process of the computing node by periodically polling the power status register of the baseboard management controller. Once the baseboard management controller is ready, the agent writes the initial power consumption and frequency strategy, specified by hardware resource configuration instructions, into its firmware. This initial power consumption and frequency strategy includes setting the CPU's operating frequency to 2.5 GHz and the GPU's operating frequency to 1.2 GHz.

[0098] For compute nodes requiring hibernation, the execution agent first initiates a data migration operation from their memory. The execution agent uses the compute node's operating system's hot page migration interface to migrate frequently accessed data pages from the compute node's physical memory to the storage unit specified in the hardware resource configuration instruction. In some embodiments, the specified storage unit is a non-volatile memory storage array within the same hardware resource pool. After the data migration is complete, the execution agent triggers the compute node's power-down process. This process includes sending a soft shutdown command to the compute node via the baseboard management controller interface, confirming the operating system's shutdown, and then disconnecting the power supply to the compute node via the intelligent power distribution unit. The execution agent controls the power module of the target storage unit or initiates a data migration operation between storage media according to the storage allocation instructions in the hardware resource configuration instruction. If the storage allocation instruction requires activating a solid-state drive (SSD) storage pool in a standby hybrid storage array, the execution agent sends a power state switching command to the controller of that storage array. If the storage allocation instruction requires migrating data from the hard disk storage area to the non-volatile memory storage area, the execution agent initiates a data migration operation specifying the source data path, target data path, and data verification method. To ensure that the availability of storage resources is consistent with the start / stop status of compute nodes, the hardware resource change log records the start / stop operation results and timestamps of all compute nodes and storage units. The hardware resource change log records the physical identifier, operation type, start time, end time, and final status of each operation. See Table 1 for a simplified example of a hardware resource change log.

[0099] Table 1: Example Table of Hardware Resource Change Log

[0100]

[0101] In practice, the execution agent logs into the relevant programmable network switch via a network management protocol, based on the network reconfiguration command in the hardware resource configuration instructions. This network management protocol can be a network configuration protocol or a secure shell protocol. The network reconfiguration command specifies the Internet Protocol address, login credentials, and specific configuration commands for the programmable network switch to be configured. The execution agent then issues port configuration commands to the programmable network switch to enable and allocate specified bandwidth to the physical ports where newly added compute nodes reside. For example, if compute node "Edge-Pool1-Rack2-Node5" is connected to port 24 of programmable network switch "Switch-A," the execution agent issues a command to "Switch-A" to enable the port from a closed state and set its bandwidth to 10 gigabits per second. For the port occupied by the soon-to-be-dormant compute node "Edge-Pool1-Rack1-Node3," the execution agent issues a command to clear the bandwidth configuration of that port and disable it. It can be understood that the port bandwidth adjustment is based on the estimated network requirements of the compute node in the hardware resource configuration instructions.

[0102] Update the routing table of the programmable network switch, adding or deleting network route entries pointing to newly added or removed compute nodes, and synchronously updating the access control list related to the routing policy. The execution agent sends a route update command to the programmable network switch "Switch-A," adding a static route to the Internet Protocol address "192.168.5.101 / 24" for the newly added compute node "Edge-Pool1-Rack2-Node5," specifying its next-hop address. Simultaneously, the execution agent deletes the route entry pointing to the Internet Protocol address "192.168.5.100 / 24" for the soon-to-be-dormant compute node "Edge-Pool1-Rack1-Node3." In the programmable network switch's access control list, the execution agent allows the new Internet Protocol address "192.168.5.101" to access the core service network segment and denies access rights to the old Internet Protocol address "192.168.5.100." In scenarios involving adjustments to hardware resource pools across multiple tiers, coordinate the configuration of network switches between different tiers. For example, when a compute node is activated in the Tier 1 hardware resource pool and that node needs to access storage resources in the Tier 3, the execution agent needs to configure the boundary programmable network switches for both the Tier 1 and Tier 3 simultaneously. This involves adding a route to the Tier 3 storage network on the Tier 1 programmable network switch and adding a route to the newly activated compute node on the Tier 3 programmable network switch, while ensuring that the end-to-end network path meets latency requirements after reconfiguration. With bandwidth Requirements, path delay It is the forwarding delay of all network devices along the path. With link propagation delay The sum is:

[0103]

[0104] in: This represents the total delay of the end-to-end network path. This represents the packet processing and queuing delay of a single network switching device or router along the path. Indicates the propagation delay of a signal over a single physical link. Bandwidth It is the minimum available bandwidth among all links on the path.

[0105] After all network switching devices have been configured and updated, the execution agent performs network connectivity tests to verify that all compute nodes and storage units within the new physical hardware topology can communicate normally. The network connectivity test includes sending Internet Control Message Protocol (ICP-IP) echo request packets from newly activated compute nodes to critical service nodes at the same and cross-levels, and checking whether the expected echo responses are received. If the network connectivity test fails, the execution agent, according to a pre-defined rollback procedure, reverts the executed hardware resource configuration instructions, restores the system state to the topology before the operation, and records the failure information in the hardware resource change log.

[0106] See Figure 4 This is a radar chart comparing the performance of different elastic scaling strategies across multiple dimensions. The hybrid strategy achieved excellent performance across all key metrics and can be considered the preferred strategy for elastic scaling of edge cloud computing power, especially suitable for business scenarios such as real-time video analytics that require a balanced performance across multiple dimensions. If the business has extremely high requirements for cost-effectiveness and service quality, prediction-based strategies should be given priority; if response time is sensitive and cost pressure is relatively low, load-based strategies can be used as an alternative. The shortcomings of load-based strategies in terms of cost-effectiveness and service quality may lead to excessively high long-term operating costs or a decline in user experience, and should be used with caution. The chart clearly shows the performance shortcomings of each strategy, providing a clear direction for subsequent strategy iterations. For example, reinforcement learning can be used to optimize the cost-effectiveness model of load-based strategies.

[0107] In one embodiment of the present invention, the regional coordinator aggregates hardware resource change logs, updated network switching device configuration information, and real-time status data of all currently active computing nodes, and packages them into a status synchronization data packet. The hardware resource change log records the start-up and shutdown operations of all computing nodes and storage units within the most recent decision cycle. The updated network switching device configuration information includes the bandwidth allocation, routing table entries, and access control list rules for each switching port after dynamic reconfiguration. The real-time status data of all currently active computing nodes is extracted from the latest monitoring data frame from the hardware resource probe, including real-time power consumption, chip temperature, instruction throughput, and memory access latency data for each computing node. In some embodiments, the status synchronization data packet is structured using JavaScript object notation, including a header identifying the data packet sequence, a field recording the synchronization timestamp, and multiple field bodies storing different types of data.

[0108] State synchronization data packets are compressed and encrypted, and uploaded to the cloud management center via a dedicated management channel on a high-speed redundant network link. In practice, before transmission, the regional coordinator compresses the state synchronization data packets using the LZ4 algorithm and encrypts the compressed data using an Advanced Encryption Standard (AES) algorithm. The encryption key is pre-distributed by the cloud management center. The dedicated management channel is a virtual private network tunnel built on a high-speed redundant network link. This tunnel has independent quality of service (QoS) guarantees, ensuring the transmission priority and low latency of the state synchronization data packets. The regional coordinator sends the encrypted state synchronization data packets to the designated receiving port of the cloud management center through this dedicated management channel.

[0109] After receiving the status synchronization data packet, the cloud management center decrypts and parses the information within, updating the real-time status of the multi-level edge cloud hardware resource pool in the corresponding region of its global resource graph database. The cloud management center's receiving service decrypts and decompresses the data packet to recover the original status synchronization data packet content. The parsing engine extracts hardware resource change logs, network switching device configuration information, and real-time status data of compute nodes from the status synchronization data packet according to a predefined data pattern. Based on this information, the cloud management center updates the records in the corresponding region of the global resource graph database. For example, it updates the status of compute node "Edge-Pool1-Rack2-Node5" from "dormant" to "active," synchronizes and updates its associated storage unit and network port information, and writes the latest performance monitoring data of this compute node to the time-series database. The cloud management center's status monitoring interface displays the updated physical hardware topology in real time. The status monitoring interface graphically displays the location, status, resource utilization, and network connectivity of all compute nodes. The location of a compute node is represented by its physical location icon in the rack, status is distinguished by color, resource utilization is displayed as a progress bar or numbers, and network connectivity is represented by lines connecting nodes.

[0110] The cloud management center's analytics engine acquires historical operational datasets, including hardware resource change logs from state synchronization data packets, business load characteristics, and final service quality metrics. In practice, the analytics engine extracts data from a complete time window, such as the past 24 hours, from a time-series database. The historical operational dataset includes every elastic scaling operation recorded in the hardware resource change logs, business load characteristics extracted from monitoring data frames before and after the operation, and final service quality metrics obtained from the application performance monitoring system. These metrics include request response latency, service success rate, and throughput. The analytics engine mines this historical operational dataset to evaluate the timing of past elastic scaling policy triggers, the accuracy of resource configuration, and the achievement of actual service quality goals. Evaluating the trigger timing involves analyzing the delay between the actual trigger time and the theoretically optimal trigger time of the elastic scaling policy at the point when business load characteristics change. ,Delay The actual triggering time The theoretical triggering time calculated based on the inflection point of load characteristic changes The difference is:

[0111]

[0112] in: This indicates a deviation in the timing of the strategy triggering. This indicates the moment when the elastic scaling strategy is actually triggered and executed by the regional coordinator. This indicates the inflection point at which the business load characteristic curve undergoes a significant change, derived from historical dataset analysis. Resource allocation accuracy analyzes the degree of matching between the amount of resources allocated according to hardware resource allocation rules and the amount of resources consumed by the actual load. The achievement of actual service quality targets is determined by comparing the final measured values ​​of service quality indicators after elastic scaling operations with the target thresholds specified in the service level agreement.

[0113] Based on the evaluation results, reinforcement learning algorithms are used to adjust the trigger condition thresholds of relevant policies in the elastic scaling policy library or the resource allocation ratio parameters in the hardware resource configuration rules. In some embodiments, the analysis engine uses the Q-Learning algorithm. The reinforcement learning algorithm models the adjustment of elastic scaling policies as a Markov decision process, where the state is a combination of business load characteristics and resource pool state, the action is to adjust the trigger condition thresholds or resource allocation ratio parameters, and the reward function is jointly defined by the achievement of service quality goals and resource utilization efficiency. For example, if the evaluation finds an average latency of 500 milliseconds in triggering policies for real-time video analytics... Furthermore, this causes service quality metrics to decline during the triggering period. Reinforcement learning algorithms will calculate a new trigger threshold, such as adjusting the average instruction throughput utilization trigger threshold of the computing node cluster from 85% to 80%, in order to trigger the expansion operation earlier. It is understandable that resource allocation ratio parameters in resource configuration rules, such as the proportion of graphics processor cores reserved for compute-intensive loads, will also be dynamically adjusted based on the historical deviation between predicted demand and actual consumption.

[0114] The optimized elastic scaling strategy parameters are sent to the corresponding regional coordinators, replacing the old parameters in their strategy libraries. The cloud management center generates a strategy parameter update instruction, which includes the strategy's unique identifier, new trigger thresholds, or new resource allocation ratio parameters. This instruction is sent to the corresponding regional coordinator via a dedicated management channel. After receiving and verifying the update instruction, the regional coordinator locates the corresponding strategy record in its local elastic scaling strategy library and replaces the old parameters with the new ones. In subsequent decision cycles, the regional coordinator will use the optimized parameters to generate hardware resource configuration instructions, thus forming a closed-loop optimization process. When the next decision cycle arrives, the regional coordinator will re-evaluate the hardware resource probe data, using the updated trigger thresholds to determine whether to trigger scaling and the updated resource allocation ratios to calculate the amount of resources to be allocated, thereby achieving continuous self-improvement of the strategy.

[0115] See Figure 5This is a daily variation chart of transmission latency across multiple layers of the edge cloud. Latency at all layers peaks at 12:00 PM and then gradually decreases, which closely matches the characteristics of peak business load at midday, verifying the correlation between "business load driving network latency." The latency difference between layers remains stable throughout the day, indicating good consistency in network link performance and providing a reliable benchmark for setting trigger thresholds for elastic scaling strategies. The low latency of the edge layer makes it the preferred deployment layer for latency-sensitive services such as real-time video analytics, while the high latency of the core layer is more suitable for non-real-time tasks such as offline big data processing, providing a quantitative basis for layered scheduling of business load. The latency peak at 12:00 PM can serve as a key trigger point for elastic scaling strategies, such as waking up edge layer computing nodes in advance before the midday peak to cope with surges in business load and ensure service quality.

[0116] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A hardware architecture design method for edge-cloud based elastic scaling server, characterized in that, include: Based on the density distribution of terminal devices and the characteristics of business load in the deployment area, a multi-level edge cloud hardware resource pool is constructed, in which each level of the hardware resource pool contains different types and specifications of computing nodes, storage units and network switching devices. Hardware resource probes are implanted on each computing node of the multi-level edge cloud hardware resource pool. The real-time power consumption, chip temperature, instruction throughput and memory access latency data of the computing node are collected in real time through the hardware resource probes. The collected real-time power consumption, chip temperature, instruction throughput, and memory access latency data are aggregated to the regional coordinator, which generates hardware resource configuration instructions according to a preset elastic scaling strategy. The elastic scaling strategy is associated with the service load type and the hardware resource performance model. According to the hardware resource configuration instructions, specific computing nodes and storage units in the multi-level edge cloud hardware resource pool are started or put into hibernation, and the port bandwidth and routing table of the network switching equipment are dynamically reconfigured to form a physical hardware topology that meets the current business needs. The updated physical hardware topology information and real-time status data of the computing nodes are synchronized to the cloud management center, triggering optimization of subsequent elastic scaling strategy parameters.

2. The hardware architecture design method for an edge-cloud-based elastic scaling server according to claim 1, characterized in that, The multi-level edge-cloud hardware resource pool is constructed based on the terminal device density distribution and service load characteristics of the deployment area, specifically as follows: Obtain historical location data and service request logs of all access terminal devices within the deployment area, and identify hotspot areas with high terminal device density and time windows with dense service requests through spatiotemporal clustering algorithms; Analyze the business request logs to extract business load characteristics under different time windows. The business load characteristics include the proportion of compute-intensive load, the proportion of input / output-intensive load, and the proportion of network latency-sensitive load. Based on the physical location of the hotspot area and the characteristics of the service load, the deployment area is divided into multiple service coverage levels, with each level corresponding to a different network latency limit and computing power supply scale. Plan physical sites for the service coverage of each level, and deploy heterogeneous computing node clusters, hybrid storage arrays and programmable network switching devices in each physical site to form the hardware resource pool of the level. Establish high-speed redundant network links between hardware resource pools at different levels, and configure cross-level resource discovery and communication protocols to complete the construction of multi-level edge cloud hardware resource pools.

3. The hardware architecture design method for an edge-cloud-based elastic scaling server according to claim 2, characterized in that, The process of implanting hardware resource probes on each computing node of the multi-level edge cloud hardware resource pool specifically involves: Develop corresponding kernel modules for computing nodes of each architecture in a multi-level edge cloud hardware resource pool. The kernel modules can directly access the performance monitoring unit and baseboard management controller of the computing node. The kernel module reads the performance counters of the central processing unit of the computing node at a fixed sampling period to obtain instruction throughput, cache hit rate and branch prediction error rate data. Meanwhile, the kernel module obtains real-time power consumption readings of the computing node and temperature sensor data of each major chip component from the baseboard management controller interface. A custom memory access latency test code segment is injected into the kernel module to periodically measure memory read and write latency and record the distribution of memory access latency. The instruction throughput data, cache hit rate data, branch prediction error rate data, real-time power consumption readings, temperature sensor data, and memory access latency distribution data are encapsulated into a unified monitoring data frame and sent to the regional coordinator through the management network port.

4. The hardware architecture design method for an edge-cloud-based elastic scaling server according to claim 3, characterized in that, The elastic scaling strategy is associated with the service load type and the hardware resource performance model, specifically as follows: Multiple standard service load types are predefined, and a corresponding hardware resource performance model is established for each standard service load type. The hardware resource performance model describes the consumption function of computing, storage, and network resources of the standard service load type. Establish a library of elastic scaling strategies. Each elastic scaling strategy includes trigger conditions, load type identification rules, and hardware resource configuration rules. The trigger conditions are set based on data thresholds collected by hardware resource probes. When the regional coordinator receives the hardware resource probe data, it matches the current instruction throughput characteristics, memory access patterns, and network traffic characteristics with the standard service load types to identify the currently dominant service load type. Based on the identified business load type, the corresponding hardware resource performance model is invoked to predict the demand for various hardware resources required to meet the service level agreement in the next time window. Based on the overall utilization rate of the current multi-level edge cloud hardware resource pool and the hardware resource demand, a matching hardware resource configuration rule is selected from the elastic scaling policy library to generate specific hardware resource configuration instructions.

5. The hardware architecture design method for an edge-cloud-based elastic scaling server according to claim 4, characterized in that, The specific hardware resource configuration instructions are generated as follows: The hardware resource configuration instructions include node control instructions, storage allocation instructions, and network reconfiguration instructions. The node control command specifies the physical location identifier of the standby computing node that needs to be woken up from the hibernation state and the initial power consumption strategy after wake-up, or specifies the physical location identifier of the computing node that needs to enter a low-power hibernation state and the data migration target. The storage allocation instructions specify the power state switching of storage units associated with compute node start-up and shutdown operations, as well as the migration path of data between storage media with different performance in the hybrid storage array; The network reconfiguration command specifies that the newly activated computing nodes are allocated uplink ports and bandwidth of network switching devices, and the routing tables and access control lists of the relevant switching devices are updated to ensure network connectivity. The hardware resource configuration instructions also include an execution sequence number and a description of the dependencies between each instruction, ensuring that the execution agents under the regional coordinator can execute complex resource allocation operations in an orderly manner.

6. The hardware architecture design method for an edge-cloud-based elastic scaling server according to claim 5, characterized in that, The specific computing nodes and storage units in the multi-level edge cloud hardware resource pool that are activated or put into hibernation are specifically: The regional coordinator's execution agent sends remote power-on or power-off signals to the target computing node through the intelligent power distribution unit, based on the node control instructions in the hardware resource configuration instructions. For computing nodes that need to be woken up, the execution agent monitors their power-on self-test process and writes the initial power consumption and frequency strategy specified by the hardware resource configuration instructions into their firmware after their baseboard management controller is ready. For compute nodes that need to hibernate, the execution agent first initiates the migration of hot data from its memory, persists the data to the specified storage unit, and then triggers the power-down process of the compute node after the data migration is completed. Simultaneously, the execution agent controls the power module of the target storage unit or initiates data migration operations between storage media according to the storage allocation instructions, so that the availability status of storage resources is consistent with the start / stop status of the compute nodes, and records the start / stop operation results and timestamps of all compute nodes and storage units, forming a hardware resource change log.

7. The hardware architecture design method for an edge-cloud-based elastic scaling server according to claim 6, characterized in that, The process of dynamically reconfiguring the port bandwidth and routing tables of network switching devices to form a physical hardware topology that meets current service requirements is as follows: The execution agent logs into the relevant programmable network switching device via the network management protocol based on the network reconfiguration instructions in the hardware resource configuration instructions; Send port configuration commands to programmable network switching devices to enable and allocate specified bandwidth to the physical ports where newly added computing nodes are located, or to release the port bandwidth occupied by computing nodes that are about to go into hibernation. Update the routing table of the programmable network switching device, add or delete network routing entries pointing to newly added or removed computing nodes, and synchronously update the access control list related to the routing policy; In scenarios involving adjustments to hardware resource pools across multiple levels, the configuration of network switching devices at different levels is coordinated to ensure that the end-to-end network path meets latency and bandwidth requirements after reconfiguration. After all network switching devices have been configured and updated, the agent is executed to perform network connectivity tests to verify that all compute nodes and storage units within the new physical hardware topology can communicate normally.

8. The hardware architecture design method for an edge-cloud-based elastic scaling server according to claim 7, characterized in that, The process of synchronizing the updated physical hardware topology information and the real-time status data of the computing nodes to the cloud management center specifically involves: The regional coordinator aggregates hardware resource change logs, updated network switching device configuration information, and real-time status data of all currently active computing nodes, and packages them into a status synchronization data packet. The status synchronization data packets are compressed and encrypted, and are uploaded to the cloud management center through a dedicated management channel in the high-speed redundant network link; After receiving the status synchronization data packet, the cloud management center decrypts and parses the information in it, and updates the real-time status of the multi-level edge cloud hardware resource pool in the corresponding area of ​​its global resource graph database. The cloud management center's status monitoring interface displays the updated physical hardware topology in real time, including the location, status, resource utilization, and network connectivity of all computing nodes.

9. The hardware architecture design method for an edge-cloud-based elastic scaling server according to claim 8, characterized in that, The triggering of subsequent optimization of elastic scaling strategy parameters specifically includes: The cloud management center's analytics engine acquires historical operational datasets, including hardware resource change logs in the status synchronization data packets, business load characteristics, and final service quality metrics. The analytics engine mines historical operational datasets to evaluate the timing of past elastic scaling strategies, the accuracy of resource allocation, and the achievement of actual service quality goals. Based on the evaluation results, reinforcement learning algorithms are used to adjust the trigger condition thresholds of relevant strategies in the elastic scaling strategy library or the resource allocation ratio parameters in the hardware resource configuration rules. The optimized elastic scaling strategy parameters are sent to the corresponding regional coordinator to replace the old parameters in its strategy library. In subsequent decision cycles, the regional coordinator will use the optimized parameters to generate hardware resource configuration instructions, thus forming a closed-loop optimization process.

10. The hardware architecture design method for an edge-cloud-based elastic scaling server according to claim 9, characterized in that, The process involves injecting a custom memory access latency test code segment into the kernel module to periodically measure memory read / write latency, specifically as follows: The kernel module pre-allocates a test buffer in the user space memory of the compute node and ensures that the test buffer is locked in physical memory to prevent it from being swapped out; The kernel module periodically initiates a memory latency measurement task, which performs a series of read and write operations with specific access patterns to the test buffer, including sequential access and random access. Before and after each read / write operation, the operation time is recorded by reading the high-precision timer of the computing node, thus obtaining the latency data of a single memory access; Collect latency data for all memory access operations within a period, calculate their average, maximum, and percentile values ​​to form memory access latency distribution data describing the current performance of the memory subsystem; The kernel module encapsulates the memory access latency distribution data along with other performance monitoring data into a monitoring data frame to complete this data collection.

Images