A server temperature anomaly disaster recovery method and device

Abstract

The application provides a server temperature abnormality disaster recovery method and device. The method comprises the following steps: enumerating real temperature sensors and generating a first identifier for each real temperature sensor; determining the number and type of virtual temperature sensors corresponding to each real temperature sensor according to the server hardware layout and disaster recovery requirements; generating a second identifier according to the type of the virtual temperature sensor and establishing a binding relationship between the first identifier and the second identifier; generating an initial configuration parameter according to the requirements corresponding to each virtual temperature sensor; determining a target first identifier according to the temperature adjustment requirements, determining a data source according to the working state of the real temperature sensor, and determining a target virtual temperature sensor according to the binding relationship if the data source is a virtual temperature sensor. The application realizes dynamic switching of the data source by constructing a double-layer identifier system of the real and virtual temperature sensors and a binding mechanism, and improves the server temperature control disaster recovery capability and the regulation flexibility without increasing the hardware.

Description

Technical Field

[0001] This application relates to the field of server heat dissipation control technology, and in particular to a method and apparatus for disaster recovery from abnormal server temperatures. Background Technology

[0002] In the field of server thermal control, temperature sensors are the core data source for fan speed regulation and temperature control management. In existing technologies, temperature sensors are typically used only as independent physical acquisition nodes, lacking mechanisms for standardized data reuse, redundant backup, and disaster recovery. This makes it easy for a single real temperature sensor to malfunction or go offline, potentially causing temperature control failure in the corresponding area, thus increasing the risk of server overheating or downtime. Furthermore, in existing systems, a single real temperature sensor typically corresponds to only a single speed control strategy, unable to be reused and extended based on the differentiated heat dissipation needs of different components such as the CPU, GPU, NIC, and power supply. This makes it difficult for the same sensor data to support temperature control adjustments across multiple scenarios and strategies, limiting the system's flexibility. In addition, existing temperature control systems lack standardized virtual redundancy and data compensation mechanisms, failing to achieve stable data replacement and disaster recovery switching capabilities in the event of sensor malfunction. Moreover, the sensor identifier and BMC control logic are usually strongly bound, which can easily lead to inconsistent identifier mapping during system expansion or strategy adjustments, thus affecting the correct execution of temperature control strategies. Furthermore, existing systems lack the ability to dynamically adapt to load changes, airflow structure, and heat distribution characteristics, and cannot adjust temperature control strategies in real time according to operating conditions. This results in insufficient overall temperature control flexibility, making it difficult to meet the heat dissipation requirements under complex operating environments. In summary, existing technologies lack a collaborative temperature control mechanism between real and virtual temperature sensors based on unified identifier management. This makes it impossible to dynamically map, redundancy-replace, and adapt strategies to data sources for different temperature control needs, thus failing to maintain stable temperature control capabilities under sensor anomalies. Summary of the Invention

[0003] In view of this, this application provides a server temperature anomaly disaster recovery method and apparatus to solve the problems of insufficient redundancy and poor adaptability to multiple scenarios in existing server temperature control systems under sensor anomaly conditions.

[0004] Specifically, this application is implemented through the following technical solution:

[0005] The first aspect of this application provides a disaster recovery method for server temperature anomalies, the method comprising:

[0006] During the server startup phase, all real temperature sensors are enumerated, and a first identifier is generated for each real temperature sensor. The first identifier is shared by the real temperature sensor and its corresponding virtual temperature sensor.

[0007] The number and type of virtual temperature sensors corresponding to each real temperature sensor are determined based on the server hardware layout, heat dissipation strategy and disaster recovery requirements. The number and type of virtual temperature sensors corresponding to each real temperature sensor are not completely the same. One requirement corresponds to only one virtual temperature sensor of the real temperature sensor.

[0008] A second identifier is generated based on the type of virtual temperature sensor and corresponding requirements, and a binding relationship is established between the second identifier and the first identifier of multiple virtual temperature sensors corresponding to the real temperature sensor.

[0009] Generate initial configuration parameters based on the requirements of each virtual temperature sensor;

[0010] After the server starts up, it determines the first target identifier based on the temperature adjustment requirements, and obtains temperature data based on the working status of the real temperature sensor corresponding to the first target identifier to regulate the temperature data. If the data source is a virtual temperature sensor, the target virtual temperature sensor is determined based on the binding relationship.

[0011] A second aspect of this application provides a server temperature anomaly disaster recovery device, the device comprising an acquisition module, a generation module, a binding module, and a control module, wherein:

[0012] The acquisition module is used to enumerate all real temperature sensors during the startup phase of the server and generate a first identifier for each real temperature sensor. The first identifier is shared by the real temperature sensor and its corresponding virtual temperature sensor.

[0013] The generation module is used to determine the number and type of multiple virtual temperature sensors corresponding to each real temperature sensor according to the server hardware layout, heat dissipation strategy and disaster recovery requirements. The number and type of virtual temperature sensors corresponding to each real temperature sensor are not completely the same. One requirement corresponds to only one virtual temperature sensor of the real temperature sensor.

[0014] The binding module is used to generate a second identifier according to the type and corresponding requirements of the virtual temperature sensor, and to establish a binding relationship between the second identifier and the first identifier of multiple virtual temperature sensors corresponding to the real temperature sensor.

[0015] The binding module is used to generate initial configuration parameters according to the requirements of each virtual temperature sensor.

[0016] The control module is used to determine the target first identifier according to the temperature adjustment requirements after the server starts up, determine the data source to obtain temperature data according to the working status of the real temperature sensor corresponding to the target first identifier, and adjust the temperature data. If the data source is a virtual temperature sensor, the target virtual temperature sensor is determined according to the binding relationship.

[0017] The server temperature anomaly disaster recovery method and apparatus provided in this application, compared with the existing technology where temperature sensors are used as single physical acquisition nodes and one sensor data corresponds to only one fixed speed control strategy, constructs scenario-based and different temperature control requirements for each real temperature sensor. Based on the shared identifier between all virtual and real sensors, it reduces data linking time caused by inconsistent naming identifiers, quickly locates the relationship between real and virtual sensors, and achieves adaptive matching for different scenarios and temperature control requirements based on multiple virtual sensors. By constructing a two-layer sensor system combining real and virtual temperature sensors and establishing a binding relationship between the second identifier of the virtual temperature sensor and the first identifier of the real temperature sensor, flexible association and disaster recovery adaptation between real temperature sensor data and different temperature control requirements are achieved. On the one hand, by configuring different numbers and types of virtual temperature sensors for the real temperature sensor according to the server hardware layout, heat dissipation strategy, and disaster recovery requirements, the data from the same real temperature sensor can be adapted to different temperature control scenarios and heat dissipation needs, thereby improving the flexibility and multi-scenario adaptability of the server temperature control strategy. On the other hand, by dynamically switching the data sources of the real temperature sensor and the virtual temperature sensor based on the working status of the real temperature sensor, and determining the target virtual temperature sensor based on the binding relationship between the first identifier and the second identifier, the temperature control process can continue to be executed even when the real temperature sensor is abnormal, thereby improving the server's disaster recovery response capability and temperature control reliability in sensor abnormality scenarios. This application can improve the disaster recovery capability and heat dissipation control flexibility of the server temperature control system without adding additional temperature acquisition hardware, reduce the risk of heat dissipation failure caused by temperature sensor abnormality, and improve the server's operational stability. Attached Figure Description

[0018] Figure 1 A flowchart of Embodiment 1 of the server temperature anomaly disaster recovery method provided in this application;

[0019] Figure 2 This is a schematic diagram of the structure of Embodiment 1 of the server temperature anomaly disaster recovery device provided in this application. Detailed Implementation

[0020] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0021] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0022] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0023] The following specific embodiments are given to illustrate the technical solution of this application in detail.

[0024] Figure 1 This is a flowchart of an embodiment of the server temperature anomaly disaster recovery method provided in this application. Please refer to... Figure 1 The method provided in this embodiment may include:

[0025] S101. During the startup phase of the server, all real temperature sensors are enumerated, and a first identifier is generated for each real temperature sensor. The first identifier is shared by the real temperature sensor and its corresponding virtual temperature sensor.

[0026] Specifically, this application relates to a temperature anomaly disaster recovery control system operating inside a server. This system is deployed in the server's Baseboard Management Controller (BMC) and is used to continuously monitor and regulate the operating temperature of each computing unit and power supply unit within the server. To facilitate the explanation of the technical solution of this embodiment, the relevant operating environment and core terminology will first be described.

[0027] Specifically, the server in this embodiment includes at least one computing node, which internally houses multiple heat-generating units, including but not limited to a central processing unit (CPU), a graphics processing unit (GPU), a network interface unit (NIC), and a power supply unit (PSU). Each heat-generating unit generates varying degrees of heat during operation, which is exchanged through the server's internal cooling system. This cooling system includes at least a fan module, an airflow structure, and a temperature control unit. During server operation, due to different power consumption distributions in different areas, the rate of temperature change and heat accumulation characteristics vary across these areas, resulting in a non-uniform temperature field.

[0028] Specifically, the server has a built-in BMC (Battery Management Center) that performs low-level server management operations, including temperature acquisition, fan speed control, and anomaly monitoring. The BMC periodically polls the temperature sensors to obtain sampling data and assesses the server's current temperature status based on this data. Simultaneously, the BMC maintains the server's internal temperature control strategy table, sensor status table, and fan control parameter table, thereby enabling dynamic adjustments to the server's heat dissipation behavior.

[0029] Specifically, the server is equipped with multiple real temperature sensors to collect actual temperatures in different physical areas within the server. These real temperature sensors include at least an inlet temperature sensor and a hotspot temperature sensor located in the CPU area, a core temperature sensor located in the GPU area, and an intake air temperature sensor located in the power supply area. The sampling data from the real temperature sensors reflects the actual heat distribution within the server and serves as the basis for subsequent temperature control decisions. In addition to the real temperature sensors, this embodiment also includes virtual temperature sensors. Virtual temperature sensors do not correspond to actual hardware sampling nodes but are logical data objects generated based on the sampling data from the real temperature sensors, combined with server space layout information, heat dissipation requirements, and disaster recovery requirements. Virtual temperature sensors serve as an alternative data source to continuously provide temperature data in case of real temperature sensor malfunctions, data failures, or sampling interruptions, ensuring the continuous operation of the temperature control system. Furthermore, different types of virtual temperature sensors can correspond to different temperature control strategy requirements, thereby achieving differentiated temperature regulation for different server areas.

[0030] Specifically, for ease of identification and differentiation, this embodiment introduces a first identifier and a second identifier to establish a mapping relationship between the real temperature sensor and the virtual temperature sensor. The first identifier identifies the real temperature sensor and serves as a unified index entry point for real temperature data, uniquely identifying and managing the operational status of the real temperature sensor, and providing an index basis for subsequent association mapping in temperature data processing. The second identifier identifies the virtual temperature sensor, distinguishing the sources of virtual data under different types and temperature control strategies. After the virtual temperature sensor is generated and the binding relationship is established, the switching and collaborative calling between real temperature data and virtual temperature data are realized through the association index relationship between the first and second identifiers.

[0031] Specifically, to facilitate unified management of real and virtual temperature sensors, BMC constructs a sensor index management structure in its runtime memory. This sensor index management structure uses a first identifier as the primary index to locate the corresponding real temperature sensor node, and establishes a virtual temperature sensor index set under each real temperature sensor node. The virtual temperature sensor index set uses a second identifier as a sub-index to distinguish virtual temperature sensors of different types and with different temperature control requirements. Multiple second identifiers can be associated with the same first identifier, each corresponding to different temperature control scenarios and different types of virtual temperature sensors. Specifically, each first identifier corresponds to a real temperature sensor record item, which includes at least real temperature sensor status information, the most recent valid temperature data, and a list of associated virtual temperature sensors. The list of associated virtual temperature sensors includes multiple second identifiers and their corresponding virtual temperature sensor configuration parameters, forming a tree-like association structure based on the first identifier. During operation, BMC first locates the target real temperature sensor based on the first identifier. When an anomaly is detected in the real temperature sensor, it then indexes the virtual temperature sensor based on the corresponding associated second identifier, thereby achieving data switching and unified management between real and virtual temperature sensors.

[0032] Specifically, after the server starts up, the BMC enters a continuous operation state and periodically monitors each real temperature sensor. When a temperature control request is triggered, the system determines the source of temperature data based on the first identifier corresponding to the target area. If a real temperature sensor is abnormal or unavailable, it switches to the corresponding virtual temperature sensor for data output, thus ensuring the continuity and stability of the server's temperature control process. Specifically, after the server completes its startup self-test and enters the BMC initialization phase, the BMC enumerates the real temperature sensors inside the server and generates a first identifier for each real temperature sensor for unified management. Specifically, after the server powers on and starts up, the BMC enters the hardware resource scanning phase, periodically scanning the sensor nodes inside the server through a preset bus communication interface. The BMC polls sensor devices within a preset address range based on the SMBus or I2C communication protocol and determines the real temperature sensors currently present in the server based on the returned device response signals. During the scanning process, for each successfully responding sensor node, the BMC records its device address information, sensor type information, physical area identifier, initial temperature sampling data, and communication status information. When a sensor node fails to return a valid response within a preset scanning period, the BMC marks the sensor node as unavailable and excludes it from the subsequent first identifier generation process.

[0033] Furthermore, after completing the enumeration, BMC establishes a status record for all identified real temperature sensors and initializes the operating status for each real temperature sensor. This operating status includes at least a normal state, a communication error state, a non-responding state, and a data unreliable state. This status information is used as the basis for selecting the data source during subsequent temperature data retrieval.

[0034] Specifically, the BMC generates a corresponding first identifier for each successfully enumerated real temperature sensor. Specifically, the first identifier is generated based on one or more dimensions of physical installation area information, sensor type information, device address information, and functional role information. In an optional implementation, the first identifier is generated using a structured encoding method, ensuring that each first identifier is unique and resolvable for subsequent rapid indexing within the system. For example, for a real temperature sensor located at the CPU area entrance, its first identifier can be represented as a structured identifier of type CPU_TEMP_INLET_01.

[0035] Furthermore, after generating the first identifier, the BMC establishes a mapping relationship between the first identifier and the corresponding real temperature sensor and stores it in the sensor management table. This sensor management table includes at least the first identifier, device physical address, region information, current operating status, most recent valid temperature data, and update timestamp fields. This mapping relationship allows the corresponding real temperature sensor to be directly located using the first identifier during subsequent temperature control. During system operation, the BMC continuously polls the enumerated real temperature sensors at preset time intervals to update their operating status and sampling data. When a communication interruption or data anomaly is detected in a real temperature sensor, the BMC updates its status to an abnormal state and marks the data source corresponding to that first identifier as unusable. This status information serves as the trigger for the subsequent virtual temperature sensor switching mechanism.

[0036] Through the above process, after the server completes the startup initialization, the system finally forms a set of real temperature sensors, a first identifier corresponding to each real temperature sensor, a mapping table between the first identifier and the real temperature sensor, and the initial operating status and sampling data of each real temperature sensor. The above results constitute the basic data source for the subsequent construction of the virtual temperature sensor system and the disaster recovery switching mechanism.

[0037] S102. Determine the number and type of multiple virtual temperature sensors corresponding to each real temperature sensor based on the server hardware layout, heat dissipation strategy and disaster recovery requirements. The number and type of virtual temperature sensors corresponding to each real temperature sensor are not completely the same. One requirement corresponds to only one virtual temperature sensor of the real temperature sensor.

[0038] Specifically, after enumerating the real temperature sensors and generating the first identifier, BMC constructs a virtual temperature sensor configuration table in its runtime memory based on the established spatial index information, real-time and historical temperature data, and server load information. This table records the type definition, spatial location, data generation rules, and status control information of the virtual temperature sensors. Simultaneously, BMC performs timestamp alignment on the aforementioned multi-source data, ensuring that different sampling sources are updated synchronously based on a unified sampling period, thereby guaranteeing the consistency of subsequent virtual temperature sensor data generation. In one implementation, this virtual temperature sensor configuration process is independent of the subsequent data output process during operation; that is, this step is only used to complete the structural definition and generation rule configuration of the virtual temperature sensor and does not directly participate in the real-time temperature data output.

[0039] Optionally, in one possible implementation, the generation of the virtual temperature sensor includes:

[0040] (1) Obtain the spatial distribution information of each real temperature sensor in the server.

[0041] Specifically, during server startup, the BMC scans sensor devices within a preset address range via SMBus or I2C bus and verifies the scan results using pre-stored hardware topology information in the firmware to confirm the validity of the real temperature sensors. For each identified real temperature sensor, the BMC extracts its device address information, physical installation location, and region information, and writes this information into a spatial distribution record table. The region information includes at least one of the CPU region, GPU region, and power supply region, representing the regional distribution relationship of the real temperature sensors within the server. Based on this information, the BMC establishes the spatial distribution relationship of the real temperature sensors for subsequent temperature distribution model construction and virtual temperature sensor location determination.

[0042] (2) Based on the spatial distribution information and the temperature data of each real temperature sensor, construct the temperature distribution model of the server.

[0043] Specifically, during operation, BMC uses real temperature sensors as spatial sampling nodes to model the internal temperature distribution of the server, thereby constructing a regional temperature distribution model to characterize the evolution of the server's thermal state. This temperature distribution model provides a unified expression of temperature change trends, heat diffusion paths, and inter-regional temperature coupling relationships between different regions within the server. It is stored in BMC's runtime memory in the form of a regional state data structure, and this model is updated in real time with the sampled data.

[0044] Optionally, in one possible implementation, the method for constructing the server's temperature distribution model includes:

[0045] (A) Construct a sliding time window based on periodic sampling of a real temperature sensor, and generate time-dimensional temperature features based on the sliding time window.

[0046] Specifically, the BMC performs periodic data acquisition on each real temperature sensor according to a preset sampling period, and maintains a sliding time window queue structure in its running memory for each real temperature sensor to store continuous temperature sampling sequences within a preset time range. In each sampling period, the BMC writes the latest acquired temperature data into the corresponding sliding time window and simultaneously removes historical data that exceeds the time window range, thus forming a continuously updated time-series data stream. Based on this time-series data stream, the BMC performs time-dimensional analysis on a single real temperature sensor, calculating its temperature change rate, fluctuation amplitude, and local trend characteristics, and generating a corresponding time-dimensional temperature feature vector.

[0047] (B) Construct spatial adjacency relationships based on the spatial distribution of real temperature sensors and temperature data, and generate spatial dimensional temperature features based on spatial adjacency relationships.

[0048] Specifically, BMC constructs a spatial topology based on the physical location information of real temperature sensors and generates a set of adjacency relationships between sensors according to preset spatial adjacency rules. Further, BMC performs correlation calculations on the temperature data between adjacent real temperature sensors based on these adjacency relationships, generating a spatial temperature correlation matrix. This correlation calculation includes at least a weighted difference calculation based on physical distance and a temperature propagation correction calculation based on the airflow direction. Through these calculations, spatial dimensional temperature characteristics characterizing the directionality of heat diffusion and spatial coupling are obtained.

[0049] (C) A server temperature distribution model is constructed by fusing time-dimensional and spatial-dimensional temperature features.

[0050] Specifically, BMC fuses temporal and spatial temperature features to obtain the overall thermal state characteristics of the server. These characteristics include at least temperature change trends, temperature fluctuation amplitudes, temperature gradient differences, and heat diffusion direction features based on the airflow direction. Based on these overall thermal state characteristics, BMC constructs a server temperature distribution model to characterize the internal temperature changes and heat diffusion state of the server. Furthermore, the temperature distribution model uses real temperature sensors as spatial sampling nodes and establishes a thermal state correlation structure based on the spatial adjacency relationships between these sensors, thereby reflecting the temperature coupling relationships and heat propagation trends between different locations within the server. Simultaneously, the temperature distribution model continuously runs in the BMC background scheduling module. When new temperature sampling data is input, BMC incrementally updates the overall thermal state characteristics and corresponding thermal state correlations, ensuring that the temperature distribution model continuously reflects the current thermal state changes of the server, rather than being a static, fixed model.

[0051] (3) Determine the heat dissipation requirement level of different regions based on the temperature distribution model, and determine the corresponding disaster recovery requirement level based on the heat dissipation requirement level.

[0052] Specifically, BMC performs regional-level risk assessment on each area of ​​the server based on the temperature distribution model and determines a heat dissipation demand level for each area to characterize the heat load intensity and heat dissipation pressure of that area under the current operating conditions. BMC extracts regional-level temperature characteristic parameters from the temperature distribution model, which include at least the regional average temperature, temperature change rate, and temperature fluctuation amplitude. In one embodiment, BMC comprehensively evaluates the above temperature characteristic parameters based on a preset heat dissipation demand assessment model to obtain a heat dissipation demand score for each area, and classifies the area into high, medium, and low heat dissipation demand levels based on the heat dissipation demand score. Specifically, when the heat dissipation score is higher than a first preset threshold, it is determined to be a high heat dissipation demand level; when the heat dissipation score is between the first and second preset thresholds, it is determined to be a medium heat dissipation demand level; and when the heat dissipation score is lower than the second preset threshold, it is determined to be a low heat dissipation demand level, wherein the thresholds are dynamically determined based on the server's historical operating temperature distribution statistics.

[0053] Furthermore, the BMC directly maps the heat dissipation requirement level to preset business criticality parameters to determine the corresponding disaster recovery requirement level. Business criticality characterizes the importance of computing resources in the corresponding region, and historical anomaly records are used to correct the disaster recovery requirement level. In one implementation, when a region has high business criticality or a high frequency of historical anomalies, the disaster recovery requirement level of the corresponding region is increased, thereby giving that region a higher redundancy priority in subsequent virtual temperature sensor configuration.

[0054] Furthermore, during operation, the BMC continuously monitors changes in the temperature distribution model. When it detects that the temperature fluctuation range of a region exceeds a preset threshold or the rate of temperature change exceeds a preset threshold, the heat dissipation requirement level of the corresponding region is dynamically increased, and the disaster recovery requirement level update mechanism is triggered simultaneously to improve the temperature sensing redundancy capability of the region.

[0055] (4) Based on the location of the real temperature sensor and the spatial constraints corresponding to the disaster recovery requirement level in the corresponding area, determine the location of the virtual temperature sensor to be added.

[0056] Specifically, after completing the temperature distribution model construction and determining the disaster recovery requirement level, BMC analyzes the thermal state of various areas inside the server based on the temperature distribution model to identify areas with high temperature change rates or significant temperature gradient changes, and designates these areas as candidate areas of interest for virtual temperature sensors. Furthermore, BMC adjusts the deployment density of virtual temperature sensors in different areas based on the disaster recovery requirement level, ensuring higher deployment density for areas with high disaster recovery requirements, thereby improving the temperature sensing redundancy capability of these areas in the event of an anomaly in the real temperature sensor. Further, after determining the candidate areas of interest and deployment density, BMC applies spatial constraints to the candidate areas in conjunction with the server's airflow structure to limit the deployable space of the virtual temperature sensors, ensuring that the deployment location of the virtual temperature sensors matches the internal heat diffusion path and airflow propagation direction of the server, thus avoiding deployment in areas with airflow disturbance or thermal measurement distortion. Based on the above, BMC generates a set of virtual temperature sensor candidate locations based on the spatial location information of real temperature sensors, under the conditions of thermal risk area screening, deployment density constraints and air duct space constraints. The candidate locations are then prioritized according to the disaster recovery requirement level to obtain the set of actual deployment locations of virtual temperature sensors.

[0057] Optionally, in one possible implementation, determining the location of the new virtual temperature sensor includes:

[0058] (A) Calculate the regional thermal gradient field of the server based on the real temperature sensor location information and temperature distribution model.

[0059] Specifically, BMC, based on the spatial location information and temperature distribution model of real temperature sensors, performs spatial coordinate mapping processing on discrete temperature sampling data inside the server, mapping discrete sampling points to a unified three-dimensional spatial coordinate system of the server, thereby forming a regional-level temperature distribution expression consistent with the physical structure. On this basis, by calculating the temperature differences between adjacent spatial locations and combining the temperature relationships between adjacent sensors to determine the direction of heat diffusion, a regional-level thermal gradient field distribution structure is generated. This structure is used to characterize the direction of temperature propagation, the intensity of change, and the trend of heat diffusion between different regions inside the server, and provides basic thermal state input for subsequent spatial constraints and deployment decisions.

[0060] (B) Based on the server airflow structure and disaster recovery requirements, spatial constraints are applied to the regional thermal gradient field, and a constrained thermal propagation space is constructed.

[0061] Specifically, the BMC acquires server airflow structure information, including the intake and exhaust paths and local airflow disturbance areas. It then corrects the propagation direction of the regional thermal gradient field to ensure consistency between the heat diffusion direction and the actual airflow propagation path, thus forming an effective heat propagation space constrained by the airflow structure. Based on this, the BMC adjusts the regional selection range and spatial coverage intensity of the heat propagation space according to the disaster recovery requirement level. This ensures that areas with high disaster recovery requirements have a higher priority for spatial retention during subsequent spatial discretization, thereby forming a constrained heat propagation space that simultaneously considers heat propagation characteristics and disaster recovery risk distribution.

[0062] (C) Based on the regional thermal gradient field and the constrained heat propagation space, generate a set of candidate locations for virtual temperature sensors.

[0063] Specifically, BMC adaptively discretizes the server's internal space within the constrained heat propagation space, dividing the server into multiple spatial grid cells, and assesses the thermal sensitivity of each grid cell based on regional-level thermal gradient values. The preset threshold used to filter grid cells is determined based on historical server operating data, specifically a quantile threshold obtained through statistical analysis of historical temperature gradient distributions or an adaptive threshold calculated based on the mean and standard deviation, used to dynamically limit the spatial grid range entering the candidate generation process. Within spatial grid cells that meet the threshold conditions, virtual temperature sensor candidate location nodes are generated, forming a virtual temperature sensor candidate location set. The generation process of candidate locations is limited by the spatial range of the constrained heat propagation space and inherits its spatial priority coverage characteristics for areas with high disaster recovery requirements. Furthermore, the spatial density of candidate locations is adjusted according to the spatial coverage intensity corresponding to the disaster recovery requirement level, thereby achieving enhanced sensing deployment in high-risk areas.

[0064] (D) Based on thermal response characteristics and disaster recovery requirements, the candidate location set is filtered to obtain the virtual temperature sensor placement location.

[0065] Specifically, within the spatial range of the constrained heat propagation space, the BMC calculates a thermal response characteristic value for each candidate location in the candidate location set. This thermal response characteristic value is determined based on the local temperature gradient change rate, spatial heat diffusion intensity, and neighborhood temperature fluctuation characteristics, and is used to characterize the sensitivity of the location to thermal changes. Based on this, the disaster recovery requirement level is mapped to a location retention weight factor, and the thermal response characteristic value is weighted and corrected to give candidate locations in high disaster recovery requirement areas a higher probability of priority retention. Further, the BMC globally sorts the candidate locations based on the corrected priority score and filters them using a spatial redundancy distance threshold determined based on the server spatial structure. When the spatial distance between candidate locations is less than the redundancy distance threshold, only higher-priority locations are retained, thereby avoiding overly dense deployment in local areas, ultimately obtaining the actual set of virtual temperature sensor placement locations.

[0066] (5) Based on the heat dissipation requirement level and disaster recovery requirement level corresponding to the newly added virtual temperature sensor location, determine the type and quantity of the virtual temperature sensor.

[0067] Specifically, in terms of type determination, BMC first obtains the following thermal characteristic parameters of the area corresponding to the location: the rate of temperature change of the real temperature sensor in the area within a preset time window, the temperature fluctuation amplitude, the number of real temperature sensors in the area, and the load change rate of the corresponding heating unit in the area. BMC compares the above parameters with the corresponding preset thresholds. When the rate of temperature change of the real temperature sensor in the area exceeds the preset rate threshold, or the temperature fluctuation amplitude exceeds the preset amplitude threshold, BMC determines that the area is a high thermal fluctuation area and configures a mirror-type virtual temperature sensor for the location. The mirror-type virtual temperature sensor is used to directly copy the most recent valid data of the corresponding real temperature sensor as the output when the real temperature sensor is abnormal, realizing one-to-one data redundancy backup. When the spatial range corresponding to the location contains two or more real temperature sensors, BMC determines that the area is a multi-sensor coverage area and configures an extreme value type virtual temperature sensor for the location. The extreme value type virtual temperature sensor is used to aggregate and calculate the temperature data of multiple bound real temperature sensors. Specifically, BMC selects the maximum, minimum, or average value as the virtual temperature data output according to the temperature control requirements of the area. When the load change rate of the corresponding heating unit in a given area exceeds a preset load change threshold, or when a preset system error indicator exists in that area, the BMC determines that the area is a complex load change area and configures a computational virtual temperature sensor at that location. The computational virtual temperature sensor is used to perform compensation calculations based on the mapping relationship between real temperature data and equipment operating load parameters to obtain corrected target temperature data.

[0068] Specifically, in one implementation, multiple different types of virtual temperature sensors can be configured at the same virtual temperature sensor location to meet various temperature control requirements that exist simultaneously in the area. For example, for a CPU core area that simultaneously exhibits high thermal fluctuation characteristics and multi-sensor coverage characteristics, the BMC can simultaneously configure a mirror-type virtual temperature sensor for disaster recovery and an extreme value-type virtual temperature sensor for multi-core temperature aggregation monitoring.

[0069] Specifically, regarding the determination of quantity, BMC calculates the thermal complexity coefficient at that location. Disaster recovery requirement level Among them, the thermal complexity coefficient The disaster recovery requirement level is calculated by weighting the ratio of the temperature fluctuation amplitude in the region to the preset baseline fluctuation amplitude, and the ratio of the temperature gradient change rate to the preset baseline gradient change rate. The disaster recovery requirement level is directly mapped; for example, a high disaster recovery requirement level corresponds to a coefficient of 3, a medium-high level to a coefficient of 2, and a medium level to a coefficient of 1. The BMC calculates the weighted sum. ,in and These are preset weighting coefficients. When the weighted sum... When the sum is greater than or equal to a first quantity threshold, the BMC configures multiple virtual temperature sensors for that location; when the weighted sum is greater than or equal to a first quantity threshold, the BMC configures multiple virtual temperature sensors for that location; When the number is less than the first threshold, a single virtual temperature sensor is configured. Based on this, BMC further adjusts the redundancy quantity according to the disaster recovery requirement level: for each level increase in the disaster recovery requirement level, one additional redundant virtual sensor instance is added. For example, when the weighted sum at a certain location... When multiple sensor configuration conditions are met, and the disaster recovery requirement level for this location is medium to high, an additional redundant virtual sensor is added on top of the basic number.

[0070] Specifically, BMC records the type and quantity configuration results in the virtual temperature sensor configuration table. This configuration table includes at least the location identifier, type field, quantity field, and corresponding data generation rule index for each virtual temperature sensor, which is used for the instantiation and configuration parameter initialization of virtual temperature sensors in subsequent steps. Through the above steps, BMC completes the determination of the sensor type and quantity at each virtual temperature sensor location, providing a complete basis for the subsequent specific generation and configuration parameter initialization of virtual temperature sensors.

[0071] (6) Based on the determined type and quantity, configure the corresponding virtual temperature sensor and establish the correspondence between the virtual temperature sensor and the real temperature sensor.

[0072] Specifically, BMC generates a corresponding virtual temperature sensor in its running memory and records the following basic information about the virtual temperature sensor: its first identifier, type identifier, spatial coordinates, address list of the real temperature sensors it depends on, and initial state flag, initialized to an active state. The first identifier field is initially empty, to be used later in establishing the binding relationship. The address list of the real temperature sensors it depends on is filled in according to the data source range.

[0073] Specifically, regarding data generation rule configuration, BMC associates a corresponding preset data generation rule template with the virtual temperature sensor type identifier. This rule template has been predefined in the system for different virtual sensor types. BMC records the index or function pointer of the rule template into the rule field of the instance, enabling the virtual sensor to generate temperature data according to the corresponding rules during subsequent operation.

[0074] Specifically, regarding the establishment of the mapping relationship, BMC records the identification information and address list of the real temperature sensors that each virtual temperature sensor depends on, and stores this mapping relationship in the data source mapping field of the virtual temperature sensor management table. This mapping relationship is used in subsequent operation phases so that when a virtual temperature sensor needs to generate temperature data, it can quickly locate the real temperature sensor it depends on and obtain the raw data.

[0075] It should be noted that this step establishes a data source correspondence, i.e., a dependency relationship, between the virtual temperature sensor and the real temperature sensor. Subsequent steps will establish a binding relationship between the second identifier of the virtual temperature sensor and the first identifier of the real temperature sensor, i.e., an identifier binding relationship. These two relationships are logically independent; the data source correspondence is used for data generation, while the identifier binding relationship is used for data source location during disaster recovery failover.

[0076] Through the above configuration, BMC completes the instantiation of the virtual temperature sensor and the establishment of the data source correspondence, enabling the virtual temperature sensor to participate in the subsequent temperature control process as a logical data source with independent data generation capabilities. This step ultimately outputs a collection of instantiated virtual temperature sensor objects and a data source mapping table between virtual and real sensors, providing a foundation for identifier binding and runtime data switching in subsequent steps.

[0077] Optionally, in one possible implementation, the virtual temperature sensor includes at least one of a mirror-type virtual temperature sensor, an extreme value-type virtual temperature sensor, and a computational virtual temperature sensor. Different types of virtual temperature sensors correspond to different temperature control requirements and employ different data generation methods.

[0078] Specifically, to adapt to the temperature control and disaster recovery requirements of different hot areas inside the server, BMC has built a multi-type virtual temperature sensor structure based on the real temperature sensor system. Different types of virtual temperature sensors are used to realize data redundancy backup, regional thermal state characterization and temperature data compensation and correction, thereby providing multi-granularity temperature sensing capabilities under different control strategies.

[0079] Specifically, mirrored virtual temperature sensors are used to generate data by replicating data from a single real temperature sensor one-to-one. Essentially, they are direct mapping backups of real temperature data, providing an alternative data source when the corresponding real temperature sensor experiences communication failures or data unavailability, thus maintaining the continuity of temperature sensing in the corresponding area. At the same time, when the same real temperature sensor needs to be called by multiple fan control strategies or multiple speed regulation algorithms, multiple mirrored virtual temperature sensors are generated to achieve data distribution, allowing different control units to perform calculations based on independent virtual data sources, thereby avoiding concurrent access conflicts to the same real sensor.

[0080] Specifically, the extreme value type virtual temperature sensor is used to aggregate and calculate the measurement results of multiple real temperature sensors to reflect the overall thermal state of the region. It obtains a virtual temperature output value for regional thermal risk characterization by processing the data of multiple bound real temperature sensors by taking the maximum, minimum, or average value. In the regional overheat protection scenario, the maximum value is preferentially used to drive the heat dissipation strategy. In the regional balanced heat dissipation scenario, the average value is used to characterize the overall temperature level of the region. In the air inlet and outlet monitoring scenario, the minimum or maximum value can be used to reflect the airflow temperature boundary state, thereby achieving overall perception and redundancy fault tolerance of regional thermal distribution.

[0081] Specifically, computational virtual temperature sensors are used to perform compensation calculations based on real temperature sensor data to generate corrected virtual temperature data. This addresses scenarios where real sensors have fixed biases, range mismatches, or require temperature compensation based on load conditions. The computational virtual temperature sensor can perform proportional or offset corrections on real temperature data based on a preset linear mapping relationship, or it can dynamically compensate temperature data based on server load information to make the output temperature more closely match the actual heat load variation trend. Furthermore, in hardware areas without independent temperature sensor coverage, the computational virtual temperature sensor can also perform weighted estimation based on neighboring real temperature sensor data, thereby achieving indirect temperature sensing.

[0082] In one implementation, multiple different types of virtual temperature sensors can be configured in the same area to perform different functions such as disaster recovery, regional thermal monitoring and temperature correction, thereby forming a multi-level virtual temperature sensing system.

[0083] S103. Generate a second identifier based on the type and corresponding requirements of the virtual temperature sensor, and establish a binding relationship between the second identifier and the first identifier of multiple virtual temperature sensors corresponding to the real temperature sensor.

[0084] Specifically, after generating virtual temperature sensors and establishing data source correspondence, BMC generates a corresponding second identifier for each virtual temperature sensor based on the type, region, and corresponding disaster recovery requirements of the virtual temperature sensor. Based on the data source dependency relationship between the real temperature sensor and the virtual temperature sensor, it establishes a binding relationship between the second identifier and the first identifier, thereby forming a data source mapping system for disaster recovery switching in the subsequent operation phase.

[0085] Specifically, the BMC assigns a globally unique second identifier to each virtual temperature sensor. This second identifier uses a structured coding method to characterize the type, region, and disaster recovery attributes of the corresponding virtual temperature sensor. In one implementation, the second identifier includes at least a type field, a region field, and an instance field. The type field distinguishes between mirror-type, extreme value-type, or computational virtual temperature sensors; the region field identifies the corresponding region; and the instance field distinguishes between different virtual temperature sensor instances within the same region. Furthermore, the BMC writes the generated second identifier into the virtual temperature sensor management table and establishes an association with the corresponding virtual temperature sensor, enabling rapid location of the corresponding virtual temperature sensor based on the second identifier during subsequent operation.

[0086] Optionally, in one possible implementation, establishing the binding relationship between the second identifier and the first identifier of multiple virtual temperature sensors corresponding to the real temperature sensor includes:

[0087] (A) Based on the data source correspondence between the virtual temperature sensor and the real temperature sensor, establish the association between the second identifier and the first identifier.

[0088] Specifically, the BMC reads the data source correspondence between virtual temperature sensors and real temperature sensors to determine the real temperature sensor that each virtual temperature sensor depends on. The real temperature sensor corresponds to a first identifier, and the virtual temperature sensor corresponds to a second identifier. Subsequently, the BMC associates and binds the second identifier of the virtual temperature sensor with the first identifier of the real temperature sensor it depends on, thereby establishing a mapping relationship between the second and first identifiers. It should be noted that the same first identifier can correspond to multiple second identifiers; that is, the same real temperature sensor can correspond to multiple virtual temperature sensors used for different temperature control needs. Further, the BMC writes the above association relationship into an identifier mapping table, which includes at least a first identifier field, a second identifier field, a virtual temperature sensor type field, and a binding status field.

[0089] (B) Determine the switching priority corresponding to the correlation based on the disaster recovery requirement level and the virtual temperature sensor type.

[0090] Specifically, the BMC obtains the disaster recovery requirement level and virtual temperature sensor type information for each virtual temperature sensor's location, and determines the switching priority of corresponding associations based on the disaster recovery functions of different types of virtual temperature sensors. For mirror-type virtual temperature sensors, since they are used for one-to-one rapid takeover in case of real temperature sensor anomalies, the BMC sets their corresponding associations as high-priority switching relationships. For extreme value-type virtual temperature sensors, since they are used for regional-level aggregated temperature calculations, they are set as medium-priority switching relationships. For computational virtual temperature sensors, since they are used for compensation and correction calculations, they are set as compensation-level switching relationships. Furthermore, when the same first identifier corresponds to multiple second identifiers, the BMC sorts them according to the switching priority of each association, forming a corresponding priority sequence. In one implementation, regions with higher disaster recovery requirement levels have higher switching priority for their corresponding associations, thereby improving the data takeover capability of critical areas in abnormal situations.

[0091] (C) Generate a virtual temperature sensor mapping management table based on the association between the second identifier and the first identifier and the switching priority.

[0092] Specifically, the BMC summarizes the established associations between the second and first identifiers and their corresponding switching priorities, generating a virtual temperature sensor mapping management table. This table includes at least the first identifier, a list of corresponding second identifiers, the virtual temperature sensor type for each second identifier, the switching priority for each association, and the current status for each association. The current status includes at least one of the following: pending activation, running, abnormal, or failed. Furthermore, the BMC stores this mapping management table in its runtime memory and continuously maintains it during system operation. When the virtual temperature sensor configuration changes, the binding relationship is adjusted, or the virtual temperature sensor status changes, the BMC synchronously updates the corresponding field content.

[0093] (D) Establish a runtime switching index structure based on the mapping management table.

[0094] Specifically, the BMC constructs a runtime fast switching index structure based on the relationships and switching priorities in the mapping management table. This fast switching index structure uses a first identifier as the primary index key and the corresponding list of second identifiers and their priority order as index values, thus forming a fast mapping structure between the first identifier and multiple second identifiers. When a subsequent temperature control request carries the target first identifier, the BMC quickly locates the corresponding list of virtual temperature sensors through this fast switching index structure and selects the currently available data source according to the priority order. Furthermore, in one embodiment, the fast switching index structure also maintains a health status flag corresponding to each relationship. When a virtual temperature sensor is in an abnormal or failed state, the BMC skips the corresponding second identifier and automatically switches to the virtual temperature sensor with the next higher priority.

[0095] (E) Establish a reverse index relationship based on the association between the second identifier and the first identifier.

[0096] Specifically, in one implementation, the BMC further establishes a reverse index relationship between the second identifier and the first identifier, used to quickly locate the corresponding real temperature sensor when the virtual temperature sensor malfunctions. This reverse index relationship includes at least a second identifier field, a corresponding first identifier field, and a corresponding binding status field. Furthermore, the BMC combines this reverse index relationship with the forward association relationship to form a bidirectional index system, thereby improving the data location efficiency of the system during anomaly diagnosis, disaster recovery switching, and state recovery processes.

[0097] Through the above steps, BMC completes the generation of the second identifier, the establishment of the association between the second identifier and the first identifier, the determination of the switching priority, the construction of the mapping management table, and the establishment of the runtime fast switching index structure, thereby providing a unified identifier mapping foundation and data source rapid location capability for temperature control request processing and disaster recovery switching in the subsequent operation phase.

[0098] S104. Generate initial configuration parameters according to the requirements of each virtual temperature sensor.

[0099] Specifically, after establishing the binding relationship between the first and second identifiers of the real and virtual temperature sensors, BMC performs configuration parameter initialization processing on each virtual temperature sensor based on the type information of the virtual temperature sensor, the heat dissipation requirement level of the corresponding area, and the disaster recovery requirement level, generating an initial configuration parameter set for subsequent operation phase calls. These initial configuration parameters define the data generation rules, scheduling rules, and disaster recovery switching rules for the virtual temperature sensors during the operation phase. This step only defines the rules for generating configuration parameters and does not involve parameter execution during the operation phase.

[0100] Optionally, in one possible implementation, generating the initial configuration parameters includes:

[0101] (A) Generate basic operating parameters based on the type of virtual temperature sensor and the corresponding area's heat dissipation and disaster recovery requirements.

[0102] Specifically, the BMC determines the regional demand combination level based on the type identifier of the virtual temperature sensor and combined with the heat dissipation demand score and disaster recovery demand score of the corresponding real temperature sensor's location. The heat dissipation demand score is calculated based on the region's historical average temperature, peak temperature, and temperature rise rate, while the disaster recovery demand score is calculated based on the number of historical anomalies and fault durations, and a unified scoring system is formed through normalization. In one implementation, the BMC divides the regional demand combination level into three categories: high demand, medium demand, and low demand, based on preset segmentation rules. These segmentation rules are determined based on the clustering analysis results of historical operating data. The BMC generates basic operating parameters based on the regional demand combination level, which include at least the data update cycle, data validity time window, and scheduling priority.

[0103] (B) Generate data update strategy parameters based on the virtual temperature sensor type and preset data generation rules.

[0104] Specifically, BMC determines the corresponding data update strategy from preset data generation rules based on the virtual temperature sensor type identifier, and generates data update strategy parameters based on this strategy. The data generation rules are determined based on error statistical analysis of historical real temperature sampling sequences and virtual output target sequences, and are used to determine the data synchronization, aggregation, and compensation relationships for different types of virtual temperature sensors. The data update strategy parameters define how the virtual temperature sensor acquires or calculates temperature data during operation, and include at least the data synchronization method, data caching strategy, and data correction method. Specifically, for mirror-type virtual temperature sensors, BMC selects a real-time synchronization strategy template and configures a recently valid data caching mechanism; for extreme value-type virtual temperature sensors, BMC selects a multi-source aggregation strategy template and configures extreme value calculation rules; for computational virtual temperature sensors, BMC selects a load correction strategy template and configures temperature compensation calculation rules based on load parameters.

[0105] (C) Based on the virtual temperature sensor binding relationship and the corresponding disaster recovery requirement level, generate disaster recovery operation control parameters.

[0106] Specifically, the BMC sorts the virtual temperature sensors corresponding to multiple bound second identifiers based on the switching priority relationship, generating disaster recovery operation control parameters. The BMC generates these parameters based on the candidate takeover sequence, and these parameters include at least the takeover delay time, the switching timeout time, and the switching cooldown time. Specifically, the BMC determines the range of the takeover delay time based on the disaster recovery requirement level, determines the switching timeout time based on the binding priority, and generates the switching cooldown time based on historical switching frequency constraints. If there is no historical data during the initial startup, the default cooldown time is used.

[0107] (D) Based on the temperature fluctuation characteristics and historical anomaly records of the area where the virtual temperature sensor is located, generate data validity parameters and anomaly recovery strategy parameters.

[0108] Specifically, the BMC acquires temperature fluctuation characteristic data and historical anomaly records for the area where the virtual temperature sensor is located, and performs statistical analysis on this data to generate data validity parameters and anomaly recovery strategy parameters. The data validity parameters provide a configuration basis for data quality judgment during operation and include at least an upper limit for temperature values, a temperature change rate threshold, and a threshold for the number of consecutive anomalies. The anomaly recovery strategy parameters define the recovery method for the virtual temperature sensor after an anomaly is resolved and include at least a data synchronization strategy identifier and a status reset strategy identifier. The BMC determines the upper limit for temperature values ​​by multiplying the statistical value of the area's temperature fluctuation amplitude by a preset safety factor, and determines the change rate threshold by multiplying the statistical value of the area's temperature change rate.

[0109] (E) Generate a virtual temperature sensor configuration parameter table based on basic operating parameters, data update strategy parameters, disaster recovery operation control parameters, data validity parameters, and anomaly recovery strategy parameters.

[0110] Specifically, the BMC uses the second identifier as the primary key to structurally summarize basic operating parameters, data update strategy parameters, disaster recovery operation control parameters, and data validity and anomaly recovery strategy parameters, generating a virtual temperature sensor configuration parameter table. This configuration parameter table serves as the sole decision-making basis for the virtual temperature sensor control logic during operation. The configuration parameter table includes at least the second identifier, data update cycle, data validity time window, scheduling priority, data synchronization method, caching strategy, takeover delay time, switchover timeout time, switchover cooling time, temperature range threshold, and rate of change threshold. The BMC writes this configuration parameter table into its runtime memory for unified scheduling and control of the virtual temperature sensor during subsequent operation.

[0111] (F) Based on the virtual temperature sensor configuration parameter table, construct a runtime configuration management structure with the second identifier as the index key.

[0112] Specifically, the BMC generates a runtime configuration management structure based on the configuration parameter table, using the second identifier as the index key to map the corresponding set of configuration parameters to index values. This runtime configuration management structure enables rapid retrieval of configuration parameters when a temperature control request is triggered, meeting the real-time requirements of disaster recovery switching. In this index structure, the encoded prefix of the second identifier distinguishes the type of virtual temperature sensor, the middle encoded segment distinguishes the region, and the last encoded segment distinguishes the virtual temperature sensor serial number. This runtime configuration management structure enables rapid retrieval and retrieval of virtual temperature sensor configuration parameters during system operation and supports an online update mechanism. When the BMC detects a change in configuration parameters, it only updates the corresponding index item, completing the configuration refresh without restarting the system, ensuring the updated parameters take effect in the next sampling period. This is used to achieve rapid location and consistent reading of configuration parameters during disaster recovery switching, thereby avoiding retrieval delays and inconsistent status issues caused by scattered configuration storage.

[0113] S105. After the server is started, a target first identifier is determined according to the temperature adjustment requirements. The data source is determined according to the working status of the real temperature sensor corresponding to the target first identifier to obtain temperature data for temperature control. If the data source is a virtual temperature sensor, the target virtual temperature sensor is determined according to the binding relationship.

[0114] Specifically, during operation, the server receives a temperature control request, which indicates the current system's temperature adjustment requirements. The BMC (Body Control Controller) determines a target first identifier based on the temperature control request and obtains the corresponding temperature data source based on the target first identifier. After determining the temperature data source, the BMC obtains the corresponding temperature data and generates target control parameters based on the temperature data. These target control parameters characterize the adjustment requirements for the heat dissipation device. Finally, the BMC generates a control signal based on the target control parameters and outputs it to the heat dissipation actuator to achieve temperature regulation and control of the server.

[0115] Optionally, in one possible implementation, determining the data source based on the operating state of the actual temperature sensor corresponding to the first target identifier includes:

[0116] (1) Obtain the working status of the real temperature sensor associated with the first identifier of the target.

[0117] Specifically, the BMC performs an index query in a preset sensor status management table based on the target first identifier to obtain the actual temperature sensor operating status data corresponding to the target first identifier. This operating status data is periodically collected and generated by the real-time health monitoring module and includes at least the online status, sampling validity status, and communication response status of the actual temperature sensor. The BMC summarizes and judges the above status data, generates a comprehensive operating status identifier for subsequent decision-making, and writes it into the operating status cache for use in subsequent steps.

[0118] (2) When the working state is normal, the real temperature sensor is selected as the temperature data source.

[0119] Specifically, when the integrated operating status indicator indicates that the real temperature sensor is in normal operating condition, the BMC directly identifies the real temperature sensor corresponding to the first target identifier as the current temperature data source and activates the corresponding data sampling channel to acquire real-time temperature data from that real temperature sensor. The acquired temperature data enters a unified data processing queue for subsequent temperature control adjustment calculations.

[0120] (3) When the working state is abnormal, obtain the working state of the virtual temperature sensor associated with the first identifier of the target, and determine the candidate virtual temperature sensor set based on the obtained state information.

[0121] Specifically, when the comprehensive operating status identifier indicates that the real temperature sensor is in an abnormal operating state, the BMC, based on the target first identifier, queries the binding relationship table for all virtual temperature sensors associated with that first identifier, and obtains the operating status information of each virtual temperature sensor one by one. The operating status information includes at least data update status, availability status, and historical anomaly records. Based on the above status information, the BMC filters virtual temperature sensors that are in a scheduling-ready state, constructs their set into a candidate virtual temperature sensor set, and writes it into the candidate buffer.

[0122] Furthermore, the regulation demand type is determined based on the temperature control strategy of the target area. This temperature control strategy includes at least a disaster recovery control strategy, a regional equilibrium regulation strategy, and an error compensation regulation strategy. Specifically, when a real temperature sensor malfunctions, the BMC determines the corresponding virtual temperature sensor usage mode based on the regulation demand type. Specifically: when the regulation demand type is a disaster recovery control strategy, candidate sensors are selected from a set of mirror-type virtual temperature sensors to maintain the continuity of temperature sensing in the corresponding area; when the regulation demand type is a regional equilibrium regulation strategy, candidate sensors are selected from a set of extreme value-type virtual temperature sensors to characterize the overall thermal state of the area; when the regulation demand type is an error compensation regulation strategy, candidate sensors are selected from a set of computational virtual temperature sensors to correct or compensate for temperature data. This achieves a correspondence constraint between the virtual temperature sensor type and the temperature control target.

[0123] (4) Select available virtual temperature sensors that meet the preset conditions from the candidate set of virtual temperature sensors.

[0124] Specifically, BMC filters the candidate virtual temperature sensor set based on preset availability judgment rules to remove virtual temperature sensors that do not meet the basic availability conditions, and generates a set of processing results by performing availability scoring on virtual temperature sensors that meet the basic availability conditions. The preset availability judgment rules include at least a data freshness threshold and a response delay threshold, which are used to determine whether the virtual temperature sensor meets the basic availability conditions, and a historical stability threshold is used to characterize the operational reliability level of the virtual temperature sensor.

[0125] (5) Determine whether the number of available virtual temperature sensors is less than a preset threshold. If the number is less than the preset threshold, execute a preset fallback strategy to regulate the temperature. If the number is not less than the preset threshold, select one of the available virtual temperature sensors as the source of temperature data based on a preset selection rule.

[0126] Specifically, the BMC counts the number of virtual temperature sensors in the available virtual temperature sensor set and compares it with a preset threshold. When the number is less than the preset threshold, the BMC triggers a preset fallback control strategy. This strategy generates a fixed control output based on preset safety temperature control parameters to put the system into a safe operating state. When the number is not less than the preset threshold, the BMC sorts the virtual temperature sensors in the available virtual temperature sensor set according to a preset selection rule. This preset selection rule includes at least a switching priority weight and a data stability weight, and selects the virtual temperature sensor with the highest priority from the sorting results as the current temperature data source.

[0127] Optionally, in one possible implementation, the data generation and updating of the mirror-type virtual sensor includes:

[0128] (1) Obtain the sampling status of the real temperature sensor.

[0129] Specifically, the BMC periodically queries the operational sampling status of the real temperature sensor bound to the mirrored virtual temperature sensor in a preset status monitoring interface. This sampling status is generated in real-time by the sensor health monitoring module and characterizes whether the real temperature sensor currently possesses effective data acquisition capabilities, including at least one of the following: normal sampling status, abnormal sampling status, and sampling interruption status. The BMC writes the acquired sampling status into the operational status cache for subsequent use in the virtual data generation process.

[0130] (2) When the sampling state is normal, the current temperature data of the real temperature sensor is acquired in real time, and the current temperature data is used as virtual temperature data for synchronous update.

[0131] Specifically, when the BMC determines that the sampling state of the real temperature sensor is normal, it activates a real-time synchronization mechanism. This mechanism continuously acquires the current temperature data output by the real temperature sensor through the data acquisition channel and directly maps this temperature data to the output of the mirror-type virtual temperature sensor, achieving consistent and synchronized updates between the virtual and real temperature data. In one implementation, the synchronization update is performed according to a preset sampling period to ensure consistency between the virtual and real temperature data over time.

[0132] (3) When the sampling state changes from normal state to abnormal state, the data retention strategy is triggered to write the most recent valid temperature data into the cache unit.

[0133] Specifically, when the BMC detects that the sampling state of the real temperature sensor has switched from a normal state to an abnormal state, it immediately triggers the data retention mechanism, writing the last validly acquired real temperature data into the cache unit for permanent storage. The cache unit is used to save the valid temperature data before the anomaly occurred and serves as the basis for the output of temperature data from the mirror-type virtual temperature sensor during subsequent anomalies, so as to avoid the impact of sudden temperature data changes on system control.

[0134] (4) During the period when the sampling state is abnormal, the most recent valid temperature data is read from the cache unit and continuously output as virtual temperature data.

[0135] Specifically, when the BMC detects that the sampling state of the real temperature sensor is continuously abnormal, the BMC stops real-time acquisition of real temperature data and periodically reads the last valid temperature data stored in the cache unit, continuously outputting it as the output value of the mirror-type virtual temperature sensor. This continuous output process remains consistent with the normal sampling cycle to ensure that the temperature control system can still obtain stable temperature input data even when the real sensor is malfunctioning.

[0136] (5) When the sampling state returns to normal, the data retention strategy is released and synchronous updates are resumed.

[0137] Specifically, when the BMC detects that the sampling state of the real temperature sensor has recovered from an abnormal state to a normal state, it releases the aforementioned data retention strategy and re-establishes the real-time data synchronization channel between the mirror-type virtual temperature sensor and the real temperature sensor, enabling the mirror-type virtual temperature sensor to resume real-time mapping updates of the real temperature data. In one embodiment, after synchronization is restored, the BMC first performs a data consistency check to obtain the deviation value between the cached data and the current real-time sampled data, and compares the deviation value with a preset deviation threshold; when the deviation value is within the preset deviation threshold range, it enters the normal synchronization update state; when the deviation value exceeds the preset deviation threshold range, it delays the resumption of synchronization updates and continues to maintain the cached output state.

[0138] Optionally, in one possible implementation, the extreme value type virtual temperature sensor filters data from multiple real temperature sensors and generates at least one of the maximum, minimum, or average values ​​as virtual temperature data based on the filtered data.

[0139] Specifically, after receiving the operation trigger command from the extreme value type virtual temperature sensor, the BMC first acquires real-time temperature data from multiple real temperature sensors in batches, based on the set of real temperature sensors bound to the virtual temperature sensor. These multiple real temperature sensors correspond to the same monitoring area or adjacent heat-affected zones to reflect local temperature distribution characteristics. Subsequently, the BMC performs data validity screening on the acquired real temperature data. This data validity screening includes removing data that exceeds a preset reasonable temperature range and removing data corresponding to communication anomalies or sampling anomalies, thereby obtaining a valid temperature data set.

[0140] Furthermore, the BMC performs statistical calculations on the effective temperature data set based on preset extreme value calculation rules, and generates corresponding virtual temperature data. In one embodiment, the extreme value calculation rules include at least one of maximum value calculation rules, minimum value calculation rules, and average value calculation rules. Specifically, when the virtual temperature sensor is configured in maximum value generation mode, the BMC selects the highest temperature value from the effective data set as the output result; when configured in minimum value generation mode, it selects the lowest temperature value as the output result; and when configured in average value generation mode, it performs a weighted or unweighted average calculation on the temperature data in the effective data set to obtain the corresponding virtual temperature data.

[0141] Furthermore, the BMC outputs the virtual temperature data to the temperature control decision module, which is used to provide an alternative representation of the regional temperature state when the real temperature sensor cannot reliably reflect the regional temperature state at a single point, so as to support the execution of subsequent temperature control strategies.

[0142] Optionally, in one possible implementation, the BMC also performs stability verification on the extreme value calculation results based on the dispersion of the effective temperature data set. When the temperature data fluctuation exceeds the preset fluctuation threshold, the average value calculation rule is used first to avoid single-point extreme values ​​causing control strategy jitter.

[0143] Optionally, in one possible implementation, the computational virtual temperature sensor generates virtual temperature data based on data from at least one real temperature sensor, including:

[0144] (1) When multiple real temperature sensor data are acquired, the data of multiple real temperature sensors are fused to obtain basic temperature data. When only a single real temperature sensor data is acquired, it is directly used as the basic temperature data.

[0145] Specifically, during operation, the BMC acquires real-time temperature data from at least one real temperature sensor corresponding to the computational virtual temperature sensor. When multiple real temperature sensor data are acquired, the BMC fuses the multiple temperature data to eliminate the influence of local measurement point differences on the overall temperature characterization, thereby obtaining basic temperature data that can characterize the overall thermal state of the target area. In one embodiment, the fusion process may include weighted fusion or unweighted fusion, wherein the weighting coefficients are determined based on the spatial location and historical stability of the real temperature sensor in the target area. When only a single real temperature sensor data is acquired, the BMC directly uses this single temperature data as the basic temperature data to ensure the continuity and real-time performance of the data link.

[0146] (2) Based on the mapping relationship between the basic temperature data and the equipment operating status parameters, determine the corresponding temperature compensation amount, and correct the basic temperature data based on the temperature compensation amount to obtain the target temperature data.

[0147] Specifically, BMC determines the corresponding temperature compensation amount based on a preset segmented mapping table between basic temperature data and equipment operating status parameters. This preset segmented mapping table is constructed based on historical operating data statistics and pre-configured with corresponding compensation coefficients according to different combinations of equipment operating status parameters. The equipment operating status parameters include at least one or more of the following: CPU load parameters, GPU load parameters, power consumption parameters, and cooling fan speed parameters, used to characterize the heat source distribution characteristics of the equipment under current operating conditions.

[0148] Specifically, BMC first normalizes each operating state parameter to obtain a standardized operating state vector, and then performs index matching in a preset segmented mapping table based on the standardized operating state vector to determine the corresponding basic compensation coefficient. When the operating state vector is located between adjacent segmented intervals, BMC uses linear interpolation to perform weighted calculation on the adjacent compensation coefficients to obtain the final temperature compensation amount.

[0149] Specifically, after determining the temperature compensation amount, BMC corrects the base temperature data based on a weighted correction model. This weighted correction model includes a linear superposition correction method, which involves either weighting and summing the base temperature data and the temperature compensation amount, or adding the temperature compensation amount as a correction increment to the base temperature data to obtain the target temperature data. Through this processing, the target temperature data reflects the impact of changes in equipment operating load on the local temperature distribution, thereby improving the adaptability and accuracy of temperature control.

[0150] (3) The validity of the target temperature data is judged, and when the judgment result is that the preset validity conditions are met, it is used as the input for temperature control.

[0151] Specifically, the preset validity conditions include at least one or more of the following: temperature range constraints, temperature change rate constraints, and data continuity constraints. When the target temperature data meets the preset validity conditions, the BMC determines it as valid temperature data and uses it as input to the subsequent temperature control module; when the target temperature data does not meet the preset validity conditions, the data is not used as temperature control input, and resampling or replacement with other virtual temperature sensor data may be triggered.

[0152] Optionally, in one possible implementation, the regulation of the temperature data includes:

[0153] (1) Based on the acquired temperature data, the corresponding target control parameter is determined according to the preset correspondence between temperature and control parameter. The correspondence is used to characterize the mapping relationship between temperature data and control parameter.

[0154] Specifically, the BMC acquires target temperature data from a real or virtual temperature sensor and normalizes the target temperature data to match a preset temperature mapping range. Then, based on a pre-built correspondence between temperature and control parameters, the BMC performs index matching in a control parameter mapping table to determine the corresponding target control parameters. This control parameter mapping table is generated based on statistical analysis of temperature change data and heat dissipation performance data during historical server operation, and is used to describe the intensity of heat dissipation control strategies corresponding to different temperature ranges. The target control parameters include at least one or more of the following: target fan speed, PWM duty cycle parameter, and heat dissipation level control parameter. In one embodiment, when the target temperature data is in a low-temperature range, the BMC matches a lower fan speed or a lower PWM duty cycle parameter; when the target temperature data is in a medium-temperature range, the BMC matches a control parameter with medium heat dissipation intensity; and when the target temperature data is in a high-temperature range, the BMC matches a higher fan speed or a higher PWM duty cycle parameter to improve heat dissipation capacity.

[0155] (2) Generate a control signal based on the target control parameters to adjust the operating status of the heat dissipation device.

[0156] Specifically, the BMC generates corresponding control signals based on the determined target control parameters. These control signals directly drive the server's internal cooling system to perform corresponding adjustment actions. In one embodiment, the control signal is a PWM control signal. The BMC generates a corresponding PWM waveform signal based on the target fan speed or PWM duty cycle parameter in the target control parameters and outputs it to the cooling fan control unit through the fan control interface. The PWM duty cycle and fan speed satisfy a preset mapping relationship. The BMC adjusts the duty cycle of the PWM signal to achieve continuous or graded adjustment of the fan speed, thereby changing the cooling airflow to adapt to different temperature load conditions. In another embodiment, the BMC can also convert the target control parameters into multi-level cooling speed control signals. By switching between different fan control modes, graded control of the cooling system is achieved to reduce control jitter and improve system stability. Through these methods, the BMC can dynamically adjust the operating status of the cooling system based on real-time temperature data, realizing closed-loop temperature regulation and control of the server.

[0157] It should be noted that the server temperature anomaly disaster recovery method is executed in the background of BMC in a continuous running mode. BMC continuously monitors the operating status of the real temperature sensor and the virtual temperature sensor through a periodic polling mechanism.

[0158] Specifically, the BMC updates the operating status and sampling data of each real temperature sensor according to a preset sampling period, and simultaneously updates the status information and configuration parameters of the virtual temperature sensor, thereby ensuring that the system can continuously acquire the latest temperature sensing data during operation. At the same time, the BMC also executes a status refresh mechanism during operation to periodically update the configuration parameters, binding relationships, and operating status of the virtual temperature sensor, enabling the configuration parameters to take effect dynamically during operation without requiring a system restart.

[0159] Specifically, in one implementation, when the BMC detects that the real temperature sensor has recovered from an abnormal state to a normal state, it triggers an abnormal recovery mechanism. The abnormal recovery mechanism is used to switch the data source from the virtual temperature sensor back to the real temperature sensor and perform consistency verification on the historical cached data to ensure the continuity and consistency of the temperature data.

[0160] Through the aforementioned background operation mechanism, the entire temperature anomaly disaster recovery system can continue to operate without interrupting service and achieve closed-loop control of dynamic monitoring, dynamic switching and dynamic recovery.

[0161] Optionally, in one possible implementation, the method further includes:

[0162] (1) Receive configuration instructions input by the user through the visual interface.

[0163] Specifically, the BMC receives configuration commands input by the user through a server management interface or an independent operation and maintenance visualization interface. These configuration commands are used to adjust the operating parameters or binding relationships of virtual temperature sensors. The configuration commands include at least one or more of the following: virtual temperature sensor addition commands, deletion commands, parameter modification commands, and mapping relationship adjustment commands. In one implementation, the BMC performs validity checks on the configuration commands, including command format verification, permission verification, and target sensor existence verification. When a configuration command meets preset verification conditions, it is written into the configuration processing queue for subsequent processing.

[0164] (2) Generate or adjust the configuration parameters of the virtual temperature sensor according to the configuration instructions, and update the correspondence between the virtual temperature sensor and the real temperature sensor.

[0165] Specifically, the BMC dynamically generates or modifies the configuration parameters of the virtual temperature sensors according to the configuration instructions. When the configuration instruction is to add a virtual temperature sensor, the BMC generates corresponding initial configuration parameters based on the first identifier of the target real temperature sensor and a preset configuration template, and completes the allocation of the second identifier. When the configuration instruction is to modify parameters, the BMC partially updates the configuration parameters of existing virtual temperature sensors, while keeping unmodified fields unchanged. Simultaneously, the BMC updates the correspondence between virtual and real temperature sensors according to the configuration instructions, including adding binding relationships, debinding relationships, or adjusting binding priorities, ensuring that the updated mapping relationship is consistent with the latest configuration parameters. This updated mapping is then written into the runtime configuration management structure to ensure that subsequent processes can be executed based on the latest configuration.

[0166] (3) The correspondence and operating status of the real temperature sensor and the virtual temperature sensor are displayed in the visualization interface.

[0167] Specifically, the BMC (Body Control Center) provides a structured display of the correspondence between real and virtual temperature sensors in the current system, and outputs a mapping topology diagram or list structure through a visual interface, allowing maintenance personnel to intuitively view the binding relationships between various sensors. Simultaneously, the BMC displays the operational status information of each real and virtual temperature sensor, which includes at least one or more of the following: online status, data update status, and anomaly marker status. In one implementation, when a sensor status changes, the BMC refreshes the visual interface in real time based on a status update mechanism, ensuring that the displayed content remains consistent with the actual operating status of the system, thereby supporting real-time monitoring and analysis of the temperature monitoring system.

[0168] The server temperature anomaly disaster recovery method provided in this application, compared with the existing technology where the temperature sensor is only a single physical acquisition node and the data from a single sensor corresponds only to a fixed temperature control strategy, constructs a two-layer temperature sensing system that coordinates real and virtual temperature sensors. Based on the binding relationship between the first and second identifiers, it achieves dynamic mapping and disaster recovery adaptation between temperature data sources and different temperature control requirements, thereby improving the adaptability and stability of the server temperature control system under complex operating conditions. Furthermore, this application configures corresponding virtual temperature sensors for real temperature sensors of different types and with different regional needs, and generates differentiated virtual temperature sensor configuration parameters based on regional heat dissipation and disaster recovery requirements. This allows the temperature sensing process to adaptively adjust according to different thermal environment characteristics, improving the precision of the temperature control strategy. In addition, this application dynamically switches data sources according to the working status of the real temperature sensor during operation. When the real temperature sensor malfunctions, the virtual temperature sensor system takes over the data. Combined with the data generation mechanisms of different types of virtual temperature sensors, it achieves various temperature data output methods, including mirror type, extreme value type, and computational type, thus maintaining the continuity and reliability of the temperature control system even in the event of sensor malfunction. Meanwhile, this application introduces a runtime management structure based on configuration parameters to achieve unified management and online updates of virtual temperature sensor parameters. This allows the system to complete configuration adjustments without restarting, thereby further improving system operational flexibility and engineering maintainability. In summary, this application can improve the disaster recovery capability, control accuracy, and operational stability of the server temperature control system without adding additional physical temperature acquisition hardware, and reduce the risk of heat dissipation failure due to sensor malfunction.

[0169] Corresponding to the aforementioned embodiment of a server temperature anomaly disaster recovery method, this application also provides an embodiment of a server temperature anomaly disaster recovery device.

[0170] Figure 2 This is a schematic diagram of the structure of Embodiment 1 of the server temperature anomaly disaster recovery device provided in this application. Please refer to... Figure 2 The apparatus provided in this embodiment includes an acquisition module 201, a generation module 202, a binding module 203, and a control module 204, wherein:

[0171] The acquisition module 201 is used to enumerate all real temperature sensors during the startup phase of the server and generate a first identifier for each real temperature sensor. The first identifier is shared by the real temperature sensor and its corresponding virtual temperature sensor.

[0172] The generation module 202 is used to determine the number and type of multiple virtual temperature sensors corresponding to each real temperature sensor according to the server hardware layout, heat dissipation strategy and disaster recovery requirements. The number and type of virtual temperature sensors corresponding to each real temperature sensor are not completely the same. One requirement corresponds to only one virtual temperature sensor of the real temperature sensor.

[0173] The binding module 203 is used to generate a second identifier according to the type and corresponding requirements of the virtual temperature sensor, and to establish a binding relationship between the second identifier and the first identifier of multiple virtual temperature sensors corresponding to the real temperature sensor.

[0174] The binding module 203 is used to generate initial configuration parameters according to the requirements of each virtual temperature sensor.

[0175] The control module 204 is used to determine the target first identifier according to the temperature adjustment requirements after the server is started, determine the data source to obtain temperature data according to the working status of the real temperature sensor corresponding to the target first identifier, and adjust the temperature data. If the data source is a virtual temperature sensor, the target virtual temperature sensor is determined according to the binding relationship.

[0176] The apparatus of this embodiment can be used to perform... Figure 1 The steps of the method embodiment shown are similar in principle and process, and will not be repeated here.

[0177] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0178] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0179] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A disaster recovery method for server temperature anomalies, characterized in that, include: During the server startup phase, all real temperature sensors are enumerated, and a first identifier is generated for each real temperature sensor. The first identifier is shared by the real temperature sensor and its corresponding virtual temperature sensor. The number and type of virtual temperature sensors corresponding to each real temperature sensor are determined based on the server hardware layout, heat dissipation strategy and disaster recovery requirement level. The number and type of virtual temperature sensors corresponding to each real temperature sensor are not completely the same. One temperature control requirement corresponds to only one virtual temperature sensor of the real temperature sensor. A second identifier is generated based on the type of virtual temperature sensor and the corresponding disaster recovery requirements. A binding relationship is established between the second identifier and the first identifier of multiple virtual temperature sensors corresponding to the real temperature sensor. Initial configuration parameters are generated based on the heat dissipation requirement level and disaster recovery requirement level of the area corresponding to each virtual temperature sensor. After the server is started, a target first identifier is determined according to the temperature control adjustment requirements. The data source is determined according to the working status of the real temperature sensor corresponding to the target first identifier to obtain temperature data, so as to regulate the temperature data. If the data source is a virtual temperature sensor, the target virtual temperature sensor is determined according to the binding relationship. The generation of the virtual temperature sensor includes: Obtain spatial distribution information of each real temperature sensor in the server; Based on the spatial distribution information and the temperature data from each real temperature sensor, a temperature distribution model of the server is constructed. The heat dissipation requirement level for different regions is determined based on the temperature distribution model, and the corresponding disaster recovery requirement level is determined based on the heat dissipation requirement level. Based on the location of the real temperature sensor and the spatial constraints corresponding to the disaster recovery requirement level within the corresponding area, determine the location of the virtual temperature sensor that needs to be added. Based on the heat dissipation requirement level and disaster recovery requirement level corresponding to the newly added virtual temperature sensor locations, determine the type and quantity of the virtual temperature sensors. Based on the determined type and quantity, configure the corresponding virtual temperature sensors and establish the correspondence between the virtual temperature sensors and the real temperature sensors.

2. The method according to claim 1, characterized in that, The virtual temperature sensor includes at least one of the following: mirror-type virtual temperature sensor, extreme value-type virtual temperature sensor, and computational virtual temperature sensor. Different types of virtual temperature sensors correspond to different temperature control requirements and adopt different data generation methods.

3. The method according to claim 1, characterized in that, The step of determining the data source based on the operating status of the actual temperature sensor corresponding to the first identifier of the target includes: Obtain the operating status of the actual temperature sensor associated with the first identifier of the target; When the working state is normal, the real temperature sensor is selected as the temperature data source; When the working state is abnormal, the working state of the virtual temperature sensor associated with the first identifier of the target is obtained, and a set of candidate virtual temperature sensors is determined based on the obtained state information. Select available virtual temperature sensors that meet preset conditions from the candidate set of virtual temperature sensors; Determine whether the number of available virtual temperature sensors is less than a preset threshold. If the number is less than the preset threshold, execute a preset fallback strategy for temperature control. If the number is not less than the preset threshold, select one of the available virtual temperature sensors as the temperature data source based on a preset selection rule.

4. The method according to claim 1, characterized in that, The adjustment of temperature data includes: Based on the acquired temperature data, the corresponding target control parameter is determined according to the preset correspondence between temperature and control parameters. The correspondence is used to characterize the mapping relationship between temperature data and control parameters. A control signal is generated based on the target control parameters to adjust the operating state of the heat dissipation device.

5. The method according to claim 1, characterized in that, Also includes: Receive configuration commands input by the user through a visual interface; The configuration parameters of the virtual temperature sensor are generated or adjusted according to the configuration instructions, and the correspondence between the virtual temperature sensor and the real temperature sensor is updated. The visualization interface displays the correspondence and operating status between the real temperature sensor and the virtual temperature sensor.

6. The method according to claim 2, characterized in that, The data generation and updating of the mirror-type virtual temperature sensor includes: Obtain the sampling status of the actual temperature sensor; When the sampling state is normal, the current temperature data of the real temperature sensor is acquired in real time, and the current temperature data is used as virtual temperature data for synchronous updating. When the sampling state switches from a normal state to an abnormal state, the data retention strategy is triggered, and the most recent valid temperature data is written to the cache unit. During the period when the sampling state is abnormal, the most recent valid temperature data is read from the cache unit and continuously output as virtual temperature data; When the sampling state returns to normal, the data retention strategy is lifted and synchronous updates are resumed.

7. The method according to claim 2, characterized in that, The extreme value type virtual temperature sensor filters data from multiple real temperature sensors and generates at least one of the maximum, minimum, or average values ​​as virtual temperature data based on the filtered data.

8. The method according to claim 2, characterized in that, The computational virtual temperature sensor generates virtual temperature data based on data from at least one real temperature sensor, including: When acquiring data from multiple real temperature sensors, the data from multiple real temperature sensors are fused to obtain the base temperature data. When acquiring data from only a single real temperature sensor, it is directly used as the base temperature data. Based on the mapping relationship between the basic temperature data and the equipment operating status parameters, the corresponding temperature compensation amount is determined, and the basic temperature data is corrected based on the temperature compensation amount to obtain the target temperature data. The validity of the target temperature data is determined, and if the determination result meets the preset validity conditions, it is used as the input for temperature control.

9. A server temperature anomaly disaster recovery device, characterized in that, This includes an acquisition module, a generation module, a binding module, and a control module, among which: The acquisition module is used to enumerate all real temperature sensors during the startup phase of the server and generate a first identifier for each real temperature sensor. The first identifier is shared by the real temperature sensor and its corresponding virtual temperature sensor. The generation module is used to determine the number and type of multiple virtual temperature sensors corresponding to each real temperature sensor according to the server hardware layout, heat dissipation strategy and disaster recovery requirement level. The number and type of virtual temperature sensors corresponding to each real temperature sensor are not completely the same. One temperature control requirement corresponds to only one virtual temperature sensor of the real temperature sensor. The binding module is used to generate a second identifier according to the type of virtual temperature sensor and the corresponding disaster recovery requirements, and to establish a binding relationship between the second identifier and the first identifier of multiple virtual temperature sensors corresponding to the real temperature sensor. The binding module is used to generate initial configuration parameters based on the heat dissipation requirement level and disaster recovery requirement level of the area corresponding to each virtual temperature sensor. The control module is used to determine the target first identifier according to the temperature control adjustment requirements after the server is started, determine the data source to obtain temperature data according to the working status of the real temperature sensor corresponding to the target first identifier, and adjust the temperature data. If the data source is a virtual temperature sensor, the target virtual temperature sensor is determined according to the binding relationship. The generation of the virtual temperature sensor includes: Obtain spatial distribution information of each real temperature sensor in the server; Based on the spatial distribution information and the temperature data from each real temperature sensor, a temperature distribution model of the server is constructed. The heat dissipation requirement level for different regions is determined based on the temperature distribution model, and the corresponding disaster recovery requirement level is determined based on the heat dissipation requirement level. Based on the location of the real temperature sensor and the spatial constraints corresponding to the disaster recovery requirement level within the corresponding area, determine the location of the virtual temperature sensor that needs to be added. Based on the heat dissipation requirement level and disaster recovery requirement level corresponding to the newly added virtual temperature sensor locations, determine the type and quantity of the virtual temperature sensors. Based on the determined type and quantity, configure the corresponding virtual temperature sensors and establish the correspondence between the virtual temperature sensors and the real temperature sensors.

Images