Whole cabinet server node monitoring method, system, computer equipment and medium

Abstract

The present application relates to a method, system, computer equipment and medium for monitoring nodes of a whole cabinet server. The method includes: pre-allocating a shared information band in the storage space of the whole cabinet, and configuring BMC and RMC for each node. BMC collects node sensor data in real time, appends a timestamp and CRC checksum according to a predetermined format, generates a digital signature, and then writes it into the shared information band. When RMC initiates access, it carries its own public key, and completes two-way identity authentication through BMC random number challenge-private key signature-public key verification. After the authentication is passed, RMC reads the shared information band data, uses the BMC public key to verify the legitimacy of the signature, and verifies the data integrity through CRC; after the verification is successful, RMC aggregates the sensor data according to the strategy and outputs the health monitoring results of each node. This method can realize low-latency, high-reliability, and high-integrity node-level monitoring data interaction between BMC and RMC, thereby improving the operation and maintenance efficiency and fault response speed of the whole cabinet server.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a method, system, computer device, and medium for monitoring server nodes in an entire cabinet. Background Art

[0002] The whole-rack server is a high-density, elastically scalable infrastructure solution for large data centers. It utilizes a 1U / 2U multi-node form factor, integrating computing, storage, power supply, cooling, and management functions into a unified rack framework. Its core features include high-density deployment, hardware elasticity, redundant high availability, and intelligent unified management, making it suitable for scenarios such as cloud computing, artificial intelligence training, and big data analytics. The system consists of standardized compute nodes and shared infrastructure. Each node includes complete hardware (server motherboard, multi-core processor, large memory capacity, and high-speed storage) interconnected via a rack backplane. The shared layer provides centralized power, intelligent cooling, and a network switching backplane, supporting modular resource reuse. The management architecture utilizes a "centralized-distributed" collaborative model: the Rack Management Controller (RMC) serves as the top-level hub, globally controlling power consumption and cooling for the entire rack based on standardized protocols. Each node has a built-in Baseboard Management Controller (BMC), which independently monitors processor temperature, memory health, and storage status, and synchronizes data to the RMC via an out-of-band management channel for refined monitoring. However, existing hardware status sharing mechanisms still have problems: the BMC writes sensor data into a shared cache, which the remote management end needs to read multiple times to aggregate complete information. The protocol stack encapsulation and parsing delay is high, making it difficult to meet real-time monitoring needs. The cache is a fixed partition and lacks dynamic management and priority preemption capabilities. After long-term operation, the space becomes full and access performance degrades. In addition, plaintext transmission poses the risk of MITM (Man-in-The-Middle) attacks, and traditional TLS (such as Transport Layer Security, encryption protocol) adds additional overhead. Summary of the Invention

[0003] To address these shortcomings, the present application provides a rack-mount server node monitoring method, system, computer device, and medium. This method enables low-latency, high-reliability, and high-integrity node-level monitoring data exchange between the BMC and RMC, thereby improving the operational efficiency and fault response speed of the rack-mount server.

[0004] According to a first aspect, the present application provides a method for monitoring nodes in a whole-rack server. The method is applied to a whole-rack server. A shared information band is pre-divided in the storage space of the whole-rack server. Each server node in the whole-rack server is configured with a baseboard management controller, and the whole-rack server is configured with a rack management controller. The method comprises:

[0005] The baseboard management controller obtains the sensor data of each server node, adds a corresponding timestamp and cyclic redundancy check code to each sensor data according to a predefined format, and generates a corresponding digital signature for each sensor data using a preset algorithm; each sensor data, corresponding timestamp, cyclic redundancy check code and digital signature are written into a shared information band; the rack management controller sends an access request to the baseboard management controller, and the access request carries the public key of the rack management controller; receives a random number challenge returned by the baseboard management controller, signs the random number challenge using the private key corresponding to the public key, and then sends it back to the baseboard management controller so that the baseboard management controller can use the public key to verify the signature to complete identity authentication; after the identity authentication is passed, the rack management controller reads each sensor data, corresponding cyclic redundancy check code and digital signature from the shared information band; uses the public key of the baseboard management controller to verify the legitimacy of each digital signature, and verifies the integrity of each sensor data based on each cyclic redundancy check code; after the integrity verification and legitimacy verification are passed, the rack management controller generates monitoring results for each server node based on each sensor data.

[0006] In some embodiments, the shared information band is divided into a first buffer and a second buffer, and the headers of the first buffer and the second buffer are provided with version numbers. The baseboard management controller writes each sensor data, corresponding timestamp, cyclic redundancy check code, and digital signature into the shared information band, including:

[0007] Identify the first buffer or the second buffer in the write-ready state as the current buffer; write each sensor data, corresponding timestamp, cyclic redundancy check code and digital signature into the current buffer; when the current buffer is full or reaches a preset time interval, the baseboard management controller switches to another buffer to perform the write operation, and increments the version number of the current buffer after each write is completed.

[0008] In some embodiments, the method further comprises:

[0009] The baseboard management controller adjusts the size of each data type partition in the first buffer and the second buffer according to the data type of each sensor data and the corresponding current data volume; prioritizes each sensor data according to the importance of the components associated with each data type to obtain sensor data of multiple priorities; when the remaining capacity of the shared information band is lower than the preset threshold, the high-priority data overwrites the low-priority data in order from high to low priority, and before each overwriting, the low-priority data to be overwritten is backed up to the dedicated directory of the corresponding server node.

[0010] In some embodiments, the baseboard management controller generates a corresponding digital signature for each sensor data using a preset algorithm, including:

[0011] Obtain a pre-generated key pair, which includes a public key and a private key; use the private key to perform a digital signature operation on each sensor data or a summary of the sensor data to generate a digital signature corresponding to each sensor data.

[0012] In some embodiments, the baseboard management controller uses the private key to perform a digital signature operation on each sensor data or a summary of the sensor data to generate a digital signature corresponding to each sensor data, including:

[0013] A hash operation is performed on each sensor data or a summary of the sensor data to obtain a hash value corresponding to each sensor data; and each hash value is encrypted using a private key to generate a digital signature corresponding to each sensor data.

[0014] In some embodiments, the rack management controller verifies the legitimacy of each digital signature using the public key of the baseboard management controller and verifies the integrity of each sensor data based on each cyclic redundancy check code, including:

[0015] Read each sensor data and the digital signature corresponding to the sensor data from the shared information band; use the public key of the baseboard management controller to decrypt each digital signature to obtain the original hash value; perform hash calculation on each read sensor data to obtain the current hash value; if the original hash value is consistent with the current hash value and the cyclic redundancy check code is correct, the verification is judged to be successful; if any of the items are inconsistent, the verification is judged to have failed and an alarm log record is triggered.

[0016] In some embodiments, the rack management controller generates monitoring results for each server node based on the sensor data, including:

[0017] Read one or more target sensor data that have passed integrity verification and legitimacy verification from the shared information band; parse each target sensor data to obtain the health status identification of each server node; determine the operating status of each server node based on each health status identification information; generate a health status report, abnormal alarm information and operating status statistics for each server node based on the operating status of each server node.

[0018] According to a second aspect, the present application provides a whole-rack server node monitoring system, which is applied to a whole-rack server. A shared information band is pre-divided in the storage space of the whole-rack server. Each server node in the whole-rack server is configured with a baseboard management controller. The whole-rack server is configured with a rack management controller, including:

[0019] The sensor data writing module is used to enable the baseboard management controller to obtain the sensor data of each server node, attach a corresponding timestamp and cyclic redundancy check code to each sensor data according to a predefined format, and generate a corresponding digital signature for each sensor data using a preset algorithm; and write each sensor data, corresponding timestamp, cyclic redundancy check code and digital signature into the shared information band.

[0020] The access request verification module is used to enable the rack management controller to send an access request to the baseboard management controller, where the access request carries the public key of the rack management controller; receive the random number challenge returned by the baseboard management controller, sign the random number challenge with the private key corresponding to the public key, and then return it to the baseboard management controller for the baseboard management controller to use the public key to verify the signature to complete identity authentication.

[0021] The shared data verification module is used to enable the rack management controller to read each sensor data, corresponding cyclic redundancy check code and each digital signature from the shared information band after the identity authentication is passed; use the public key of the baseboard management controller to verify the legitimacy of each digital signature, and verify the integrity of each sensor data based on each cyclic redundancy check code.

[0022] The monitoring result generation module is used to enable the rack management controller to generate monitoring results for each server node based on the data of each sensor after the integrity verification and the legality verification are passed.

[0023] According to a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of any one of the whole-cabinet server node monitoring methods in the above-mentioned embodiments are implemented.

[0024] According to a fourth aspect, the present application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When executed, the processor implements the steps of any one of the whole-cabinet server node monitoring methods in the above-mentioned embodiments.

[0025] The above-described whole-rack server node monitoring method can be applied to a whole-rack server. A shared information band is pre-allocated within the storage space of the whole-rack server. The whole-rack server is equipped with a rack management controller (RMC). The whole-rack server includes multiple server nodes, each of which is equipped with a baseboard management controller (BMC). The method comprises: the BMC of each server node obtains sensor data from each server node, appends a corresponding timestamp and cyclic redundancy check (CRC) code to each sensor data according to a predefined format, and generates a corresponding digital signature for each sensor data using a preset algorithm. The BMC then writes each sensor data, corresponding timestamp, CRC code, and digital signature into the shared information band. When the RMC needs to obtain sensor data, it first sends an access request to the BMC, carrying the public key of the RMC. The RMC then receives a random number challenge returned by the BMC, signs the random number challenge using the private key corresponding to the public key, and transmits the challenge back to the BMC. The BMC verifies the signature using the public key to complete identity authentication. After authentication is successful, the rack management controller reads the sensor data, corresponding cyclic redundancy check codes, and digital signatures from the shared information band. It then verifies the legitimacy of each digital signature using the BMC's public key and verifies the integrity of each sensor data based on the cyclic redundancy check codes. Finally, after integrity and legitimacy verification, the rack management controller generates monitoring results for each server node based on the sensor data. This method enables low-latency, high-reliability, and high-integrity node-level monitoring data exchange between the BMC and RMC, thereby improving the operational efficiency and fault response speed of the entire cabinet server. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 This is a flowchart of a method for monitoring server nodes in an entire cabinet in one or more embodiments of the present application;

[0027] Figure 2 A flowchart of a method for a BMC to write sensor data, timestamp, cyclic redundancy check code and digital signature into a SIB in one or more embodiments of the present application;

[0028] Figure 3 A flowchart of a method for dynamically matching actual traffic of various data types during operation in one or more embodiments of the present application;

[0029] Figure 4 A flowchart of a method for ensuring that the source of each piece of sensor data is verifiable and the content cannot be tampered with in one or more embodiments of the present application;

[0030] Figure 5 A flow chart of a method for solidifying the integrity fingerprint of each piece of sensor data in a cryptographically verifiable manner in one or more embodiments of the present application;

[0031] Figure 6 A flowchart of a method for ensuring the integrity and source legitimacy of each piece of sensor data in one or more embodiments of the present application;

[0032] Figure 7 A flowchart of a method for aggregating node health status in real time in a structured and scalable manner in one or more embodiments of the present application;

[0033] Figure 8 This is an example flow chart of a method for monitoring server nodes in a whole cabinet in one embodiment of the present application;

[0034] Figure 9 This is a structural diagram of a whole-cabinet server node monitoring system in another embodiment of the present application;

[0035] Figure 10 This is a schematic diagram of the internal structure of a computer device in one or more embodiments of the present application. DETAILED DESCRIPTION

[0036] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0037] The present application provides a whole-cabinet server node monitoring method according to the first aspect, which is applied to the whole-cabinet server. Shared information bands are pre-divided in the storage space of the whole-cabinet server. Each server node in the whole-cabinet server is configured with a baseboard management controller, and the whole-cabinet server is configured with a rack management controller.

[0038] In certain exemplary embodiments of the present application, Figure 1 As shown, the method includes the following steps:

[0039] Step 101: The baseboard management controller obtains the sensor data of each server node, adds a corresponding timestamp and cyclic redundancy check code to each sensor data according to a predefined format, and generates a corresponding digital signature for each sensor data using a preset algorithm; and writes each sensor data, corresponding timestamp, cyclic redundancy check code and digital signature into a shared information band.

[0040] Sensor data can include CPU (Central Processing Unit) temperature, memory voltage, hard drive SMART attributes (Self-Monitoring, Analysis and Reporting Technology attributes), PCIe (Peripheral Component Interconnect Express) link status, motherboard CPLD (Complex Programmable Logic Device) register values, and backplane CPLD register values. The predefined format can be a TLV-TS-CRC-DS four-tuple structure. The TLV-TS-CRC-DS four-tuple structure includes: T (Type, size 1 byte) represents the register type; L (Length, 1 byte) represents the value range length; V (Value, variable length) represents the raw sample value; TS (Timestamp, size 4 bytes) represents the Unix Epoch timestamp; CRC (which can be a 32-bit Cyclic Redundancy Check, size 4 bytes) can be based on a polynomial. 1. Calculation; DS (Digital Signature, 256 bytes) can be a PKCS#1v1.5 signature generated for an RSA-2048 private key. The default algorithm refers to the asymmetric cryptographic algorithm used to generate the digital signature. It can be the RSA-PKCS#1 v1.5 Padding Signature Algorithm, the RSA-PSS Probabilistic Signature Scheme Algorithm, or the Elliptic Curve Digital Signature Algorithm (ECDSA).

[0041] The Baseboard Management Controller (BMC) can poll all sensors in the server node at a 1 Hz cycle, encapsulate each sampled value as TLV-TS-CRC-DS, record it, and write it to the real-time status area of ​​the Shared Information Band (SIB). This writing adopts a double buffering mechanism: when the first buffer is full, it switches to the second buffer and writes a monotonically increasing 4-byte version number (VersionNumber, Ver) to the buffer header to ensure that the rack management controller (RMC) can always read the latest and consistent data when accessing it.

[0042] For example, when the BMC detects that the CPU temperature is 88 degrees Celsius, it generates a record {T=0x01, L=0x02, V=0x0058, TS=0x667B8C00, CRC=0x4E7A3C92, DS=0x8F…} and then writes it to the 256-byte slot starting at SIB address 0x0010_0000.

[0043] Step 102: The rack management controller sends an access request to the baseboard management controller, and the access request carries the public key of the rack management controller; receives a random number challenge returned by the baseboard management controller, signs the random number challenge with the private key corresponding to the public key, and then sends it back to the baseboard management controller, so that the baseboard management controller can use the public key to verify the signature to complete identity authentication.

[0044] The access request may be an authentication request frame (hereinafter referred to as Auth-Req). The format of Auth-Req includes a frame header 0xAA55, a protocol version 0x01, a rack management controller identifier (hereinafter referred to as RMC-ID, which may be 2 bytes in size), and a rack management controller public key (hereinafter referred to as RMC-PubKey, which may be 256 bytes in size).

[0045] After receiving the Auth-Req, the BMC uses the onboard True Random Number Generator (TRNG) to generate a 32-byte Nonce (one-time random number) and returns it via a Challenge frame. The RMC then uses its Rack Management Controller Private Key (RMC-PrivKey) to sign the Nonce using SHA-256-with-RSA (SHA-256 combined with the RSA signature algorithm) to generate the Rack Management Controller Signature (Sig-RMC). The Rack Management Controller Signature (Sig-RMC) is then returned to the BMC via a Response frame. The BMC verifies the signature using the locally stored RMC-PubKey and, upon successful verification, adds the Rack Management Controller ID (RMC-ID) to the whitelist.

[0046] For example, when RMC-PubKey is 0x9C…, BMC generates Nonce = 0xE7…3A, RMC calculates Sig-RMC = 0x4B…D1 and returns it; BMC verifies that the signature is true, sets the whitelist status to 1, and allows subsequent data reading.

[0047] Step 103: After the identity authentication is passed, the rack management controller reads each sensor data, the corresponding cyclic redundancy check code and each digital signature from the shared information band; uses the public key of the baseboard management controller to verify the legitimacy of each digital signature, and verifies the integrity of each sensor data based on each cyclic redundancy check code.

[0048] RMC's read operation can adopt a "zero-copy" approach. That is, RMC maps the SIB real-time status area to the local virtual address space through memory-mapped input and output (MMIO), and directly parses it to obtain records in the TLV-TS-CRC-DS (Type-Length-Value–Timestamp–Cyclic Redundancy Check–Digital Signature) format.

[0049] RMC can perform two-step verification on each record. First, RMC verifies the DS field using the preset Baseboard Management Controller Public Key (BMC-PubKey) to ensure the data source is trustworthy. It also recalculates the 32-bit cyclic redundancy check (CRC32) of the Value|TS (Value concatenated with Timestamp) and compares it with the CRC field in the record to confirm that the data has not been tampered with.

[0050] For example, after reading the CPU temperature record, the RMC calculates the CRC32 of Value|TS and obtains 0x4E7A3C92, which is consistent with the record. DS is then successfully verified using BMC-PubKey, indicating that the record is legal and complete.

[0051] Step 104: After the integrity verification and the legality verification are passed, the rack management controller generates a monitoring result of each server node based on the sensor data.

[0052] The monitoring results can be presented in the form of a Node Health Report (NHR) structured message, which includes a node ID, a health status bitmap (hereinafter referred to as Health-Bitmap, which can be an 8-byte bitmap, with each byte corresponding to CPU, memory, hard disk, PCIe, mainboard CPLD, backplane CPLD, reserved, and reserved), and a threshold-based abnormality level (which can be expressed in the form of Normal / Warning / Critical, i.e. normal / warning / critical).

[0053] The RMC compares the parsed sensor value with the preset threshold. If the CPU temperature is greater than 85 degrees Celsius, the Health Bitmap bit 0 is set to 1 and the abnormality level is marked as Critical. The NHR is then pushed to the cloud management platform via a Redfish event.

[0054] For example, when the CPU temperature of node 3 is 88 degrees Celsius, the memory voltage is 1.18 volts (normal), and there are no SMART alarms on the hard disk, the RMC generates and reports NHR {NodeID=0x03, Health-Bitmap=0x01, Level=Critical}.

[0055] Through steps 101 to 104, the entire cabinet server can achieve low-latency, high-reliability, and high-integrity node-level monitoring data interaction between the BMC and the RMC without the need for an additional network protocol stack, thereby improving the operation and maintenance efficiency and fault response speed of the entire cabinet server.

[0056] In some embodiments, as Figure 2 As shown, the shared information band is divided into a first buffer zone and a second buffer zone, and the headers of the first buffer zone and the second buffer zone are provided with version numbers. Step 101 includes the following steps:

[0057] Step 201: Identify the first buffer or the second buffer in a write-ready state as the current buffer.

[0058] The Write-Ready state means that the least significant bit of the buffer header Ver is 0, indicating that the buffer is not currently locked by the BMC.

[0059] Before each write, the BMC reads the Ver values ​​of the two buffers: if Primary-Buf.Ver.LSB=0 (indicating that the least significant bit of the first buffer version number is 0), the first buffer (hereinafter referred to as Primary-Buf) is selected as the current buffer; if Primary-Buf.Ver.LSB=1 (the least significant bit of the first buffer version number is 1) and Secondary-Buf.Ver.LSB=0 (indicating that the least significant bit of the second buffer version number is 1), the second buffer (hereinafter referred to as Secondary-Buf) is selected; if both are 1, wait 50 milliseconds and try again (anti-collision delay).

[0060] Step 202: Write each sensor data, corresponding timestamps, cyclic redundancy check codes and digital signatures into the current buffer.

[0061] The write unit can be a TLV-TS-CRC-DS record, a single record of 256 bytes, appended sequentially.

[0062] After the BMC encapsulates the sensor data into records, it writes them sequentially to the end of the current buffer through memory mapping (hereinafter referred to as I / O, input / output), and inserts 4-byte alignment padding (Pad=0x00) between records.

[0063] For example, if the current buffer is Primary-Buf and 127 records (127 × 256 = 32512 bytes) have been written to it, the BMC writes the 128th CPU temperature record to offset 0x0000_8000.

[0064] Step 203: When the current buffer is full or the preset time interval is reached, the baseboard management controller switches to another buffer to perform a write operation, and increments the version number of the current buffer after each write is completed.

[0065] Among them, full is defined as "remaining available space < single record length"; the switching action (Buf-Swap) is completed by atomically setting Ver.LSB=1 (indicating that the least significant bit of the version number is 1) and incrementing the high 31 bits of Ver.

[0066] After the switch, the BMC can perform the following three steps:

[0067] 1. Write back the current buffer Ver high 31 bits + 1;

[0068] 2. Set Ver.LSB = 1 to mark it as frozen;

[0069] 3. Clear the Ver.LSB of the next buffer to 0 and initialize the write pointer to 0.

[0070] For example, when Primary-Buf is full at 1.02 seconds, the BMC updates the first buffer area version number Primary-Buf.Ver from 0x0000_0000 to 0x0000_0001, then writes the second buffer area version number Secondary-Buf.Ver from 0x0000_0001 to 0x0000_0002 (high 31 bits) + 0 (LSB), and starts writing the 129th record to Secondary-Buf.

[0071] Through steps 201 to 203, the entire cabinet server can achieve lock-free, low-latency double-buffered writing of the BMC to the shared information band, while ensuring that the RMC can instantly locate the latest valid buffer by reading the Ver value at any time, thereby ensuring the real-time and consistency of the monitoring data.

[0072] In some embodiments, as Figure 3 As shown, when executing step 101, the following steps are also included:

[0073] Step 301: The baseboard management controller adjusts the size of each data type partition in the first buffer and the second buffer according to the data type of each sensor data and the corresponding current data volume.

[0074] A data type partition (Type-Partition) is a variable-length continuous byte segment reserved for the same data type within a Primary-Buf or Secondary-Buf. The current data volume (Data-Volume) is the cumulative number of bytes of this type of data over the past N collection cycles, where N defaults to 10.

[0075] The BMC can perform partition recalculation every 60 seconds using the following formula:

[0076] NewSize(Type)=BaseSize(Type)×(Data-Volume(Type) / AvgVol);

[0077] NewSize(Type) indicates the new partition size of the data type, BaseSize(Type) indicates the baseline partition size of the data type, Data-Volume(Type) indicates the current data volume (in bytes) of the data type, AvgVol indicates the average data volume of all data types in the same statistical period, MinSize(Type) indicates the minimum partition threshold of the data type, and MaxSize(Type) indicates the maximum partition upper limit of the data type. If the calculated result is less than MinSize(Type), MinSize(Type) is used; if it is greater than MaxSize(Type), MaxSize(Type) is used.

[0078] For example, the CPU temperature sensor accumulates 2048 bytes over the past 10 seconds, with an average size of 1024 bytes (meaning the average size of CPU temperature data over the past 10 seconds is 1024 bytes). If BaseSize = 200 MiB (mebibyte), then NewSize(CPU) = 200 MiB × (2048 / 1024) = 400 MiB. The BMC then expands the CPU partition in Primary-Buf from 0x0000_0000–0x0C7F_FFFF to 0x0000_0000–0x18FF_FFFF and simultaneously adjusts the Secondary-Buf mapping.

[0079] Step 302: Prioritize each sensor data according to the importance of the components associated with each data type to obtain sensor data of multiple priorities.

[0080] Component criticality is defined by a static mapping table in the BMC firmware. The value format is {High, Mid, Low}. Priority levels correspond to component criticality levels one-to-one. For example, the value of component criticality is {High = 3, Mid = 2, Low = 1}.

[0081] For example, the CPU temperature and memory ECC (Error-Correcting Code) error columns are set to High; the fan speed column is set to Mid; and the chassis intrusion switch column is set to Low.

[0082] Step 303: When the remaining capacity of the shared information band is lower than the preset threshold, the low-priority data is overwritten with the high-priority data in descending order of priority, and before each overwriting, the low-priority data to be overwritten is backed up to the dedicated directory of the corresponding server node.

[0083] The dedicated directory (Node-Backup-Dir) is the node local file system " / var / log / bmc_sib_backup / <YYYYMMDD_HHMMSS> "" path; the coverage unit is the entire Type-Partition.

[0084] After the storage space threshold (Space-Thr) is triggered, the BMC:

[0085] Enumerate all Type-Partitions with Priority-Level=Low;

[0086] Upload the segment to be overwritten to the node backup directory (Node-Backup-Dir) through the Secure Copy Protocol (SCP). The file name format is " <type>;

[0087] Reclaim the partition space and immediately make it available for writing new data with Priority-Level=High.

[0088] For example, when the remaining SIB capacity drops to 4%, the BMC first copies the entire fan speed partition 0x2000_0000–0x200F_FFFF (Priority-Level=Low) to " / var / log / bmc_sib_backup / 20250721_143052 / fan.bin" and then releases 16 megabytes of the fan speed partition 0x2000_0000–0x200F_FFFF for writing CPU temperature emergency alarm data.

[0089] Through steps 301 to 303, the entire cabinet server can dynamically match the actual traffic of each data type during operation and ensure that critical alarms are never lost. At the same time, historical low-priority data is retained through Node-Backup-Dir, achieving the dual goals of capacity adaptation and data traceability.

[0090] In some embodiments, as Figure 4 As shown, the baseboard management controller in the above step 101 generates a corresponding digital signature for each sensor data using a preset algorithm, including the following steps:

[0091] Step 401: Obtain a pre-generated key pair, which includes a public key and a private key.

[0092] The key pair is generated offline by the BMC firmware during initialization using an RSA-2048 key generator recommended by the Digital Signature Standard (FIPS-186-4). The public key, PubKey-BMC, is stored in the BMC's TrustFlash, while the private key, PrivKey-BMC, is stored in the BMC's Hardware Security Module (HSM). These keys are accessible only through signed commands and cannot be exported in plain text. The key lifecycle (Key-Lifetime) is 180 days. Thirty days before expiration, the BMC automatically invokes the HSM's key rotation service (Key-Rollover) to generate a new key pair and pushes the PubKey-BMC key to the RMC's TrustStore via a secure channel. For example, at 00:00:00 UTC on July 21, 2025, the BMC detects that the current key has been used for 179 days, triggering a Key-Rollover. The newly generated PubKey-BMC digest is 0x9F7A…3E2C and is successfully synchronized to the RMC TrustStore at 00:01:03.

[0093] Step 402: Use the private key to perform a digital signature operation on each sensor data or the digest of the sensor data to generate a digital signature corresponding to each sensor data.

[0094] The digest algorithm can be SHA-256, generating a 256-bit digest value (Digest-Sensor). The signature operation can use the RSASSA-PKCS1-v1_5 padding scheme, outputting a 2048-bit (256-byte) Sig-Sensor.

[0095] The BMC performs a SHA-256 calculation on the complete TLV-TS-CRC record (including Type, Length, Value, Timestamp, and CRC) to obtain the Digest-Sensor. The BMC then calls the HSM's Signature Application Programming Interface (Sign-API): Sig-Sensor = Sign(PrivKey-BMC, Digest-Sensor). For example, when the CPU temperature record is {T = 0x01, L = 0x02, V = 0x0058, TS = 0x667B8C00, CRC = 0x4E7A3C92}, its Digest-Sensor = 0xC5D4…F1A7. After signing, the resulting Sig-Sensor = 0x8F2E…7B9D is then written to the SIB along with the record.

[0096] Through steps 401 to 402, the entire cabinet server can ensure that the source of each sensor data is verifiable and the content cannot be tampered with, providing cryptographic protection for the subsequent legitimacy verification on the RMC side.

[0097] In some embodiments, as Figure 5 As shown, the above step 402 includes the following steps:

[0098] Step 501: Perform a hash operation on each sensor data or a digest of the sensor data to obtain a hash value corresponding to each sensor data.

[0099] The hash operation uses the SHA-256 one-way hash function defined in FIPS-180-4. The digest range can be the entire TLV-TS-CRC record, or only the value field (hereinafter referred to as "Value") can be hashed to match different security policies. Specifically, the BMC calls the HSM's Hash-Engine (a dedicated module in the HSM used to perform hash operations, responsible for converting the input byte stream into a fixed-length hash value): the input is the byte stream M = TLV-TS-CRC, and the output is the hash value (Hash-Sensor) of the sensor data of a fixed size of 32 bytes; after the operation is completed, the intermediate register is immediately cleared to prevent side channel leakage. For example, when the hard disk SMART record is {T=0x03, L=0x10, V=0x0000_0000_0000_0000…, TS=0x667B8D00, CRC=0xE7F2A1B8}, its Hash-Sensor=SHA-256(M)=0x4A6E…C9F1.

[0100] Step 502: Use the private key to perform encryption operation on each hash value to generate a digital signature corresponding to each sensor data.

[0101] The signature operation refers to an RSA private key signature operation using the RSASSA-PKCS1-v1_5 padding scheme, outputting a 256-byte Sig-Sensor. This digital signature uniquely corresponds to the original data and cannot be forged. Specifically, the BMC sends a signature request (a command sent by the BMC to the HSM requesting the hash value be signed, containing parameters such as the hash value and signature scheme identifier, hereinafter referred to as Sign-Request) to the HSM. The parameters are the Hash-Sensor and the signature scheme identifier 0x01. The HSM returns the Sig-Sensor and stores it in the BMC's signature verification cache (a cache area within the BMC used to temporarily store generated digital signatures for subsequent writing to the SIB, hereinafter referred to as Sig-Cache) for writing to the SIB in step 101. For example, for the aforementioned hard drive SMART hash value 0x4A6E…C9F1, the resulting Sig-Sensor is 0x1B94…7E5D after signing, which is then written along with the original record to SIB offset 0x0000_0400.

[0102] Through steps 501 to 502, the entire cabinet server can solidify the integrity fingerprint of each sensor data in a cryptographically verifiable manner, ensuring that any subsequent bit-level tampering can be immediately detected by the RMC.

[0103] In some embodiments, as Figure 6 As shown, the rack management controller uses the public key of the baseboard management controller to verify the legitimacy of each digital signature and verifies the integrity of each sensor data based on each cyclic redundancy check code, including the following steps:

[0104] Step 601: Read each sensor data and its corresponding digital signature from the shared information band; use the public key to perform a decryption operation on the digital signature to obtain the original hash value.

[0105] The verification operation refers to the RSASSA-PKCS1-v1_5 verification operation; the original hash value (hereinafter referred to as Origin-Hash) is the 32-byte digest written during signing.

[0106] The RMC maps the SIB to the local virtual address space through MMIO, sequentially reads the TLV-TS-CRC-DS records, extracts the last 256 bytes of the Sig-Sensor, and then calls the hardware-accelerated RSA engine for verification: Origin-Hash = RSA-PubVerify(PubKey-BMC, Sig-Sensor). For example, when Sig-Sensor = 0x1B94…7E5D, verification yields Origin-Hash = 0x4A6E…C9F1.

[0107] Step 602: Perform hash calculation on each sensor data read to obtain a current hash value.

[0108] SHA-256 hash calculations can be performed over the TLV-TS-CRC quadruple. The current hash value (Current-Hash) is a 32-byte digest calculated in real time. The RMC feeds all bytes in the record, except the digital signature (DS) field, into the secure hash unit. Current-Hash = SHA-256(TLV-TS-CRC). For example, for the same hard drive SMART record, Current-Hash = 0x4A6E…C9F1.

[0109] Step 603: If the original hash value is consistent with the current hash value and the cyclic redundancy check code is correct, the verification is determined to be successful; if any of the items are inconsistent, the verification is determined to be failed and an alarm log record is triggered.

[0110] If the Origin-Hash and Current-Hash match and the CRC32 is correct, verification is considered successful. If any of these items are inconsistent, verification is considered a failure, and an alert log (hereinafter referred to as the Alert-Log) is triggered. The Alert-Log is a structured record in the RMC's local non-volatile storage, containing the node ID, failure type (which can be Hash-Mismatch or CRC-Error), timestamp, and the first 16 bytes of the original record. Specifically, the RMC first compares the Origin-Hash with the Current-Hash, then recalculates the CRC32 of Value|TS. If the CRC32 is ≠ the CRC field in the record, or if the hash comparison fails, the Alert-Log is broadcast to the management network and simultaneously written to the local / var / log / rmc_verify_fail.log. For example, if the CRC32 check of the hard disk SMART record fails, RMC immediately generates Alert-Log{NodeID=0x05,Type=CRC-Error,TS=0x667B8D10,Payload=0x0000_0000…}.

[0111] Through steps 601 to 603, the entire cabinet server can ensure the integrity and source legitimacy of each sensor data, thereby providing a reliable data foundation for subsequent monitoring and fault diagnosis.

[0112] In some embodiments, as Figure 7 As shown, step 104 includes the following steps:

[0113] Step 701: Read one or more target sensor data that have passed integrity verification and legality verification from the shared information band.

[0114] Target-Sensor-Data refers to the set of TLV-TS-CRC-DS records that have passed verification in steps 601 to 603. The RMC locates the most recently valid buffer using buffer Ver, sequentially reads all valid records, and filters out the required nodes and data types. For example, the RMC reads all Target-Sensor-Data records for node 0x03, a total of 128 records in the range 0x0000_0000–0x0000_8000.

[0115] Step 702: Analyze the data of each target sensor to obtain the health status identifier of each server node.

[0116] Parse each target sensor data (Target-Sensor-Data) to obtain the Health-Bitmap for each server node. The Health-Bitmap is an 8-byte bitmap, where bit 0 represents CPU status, bit 1 represents memory status, bit 2 represents hard drive status, bit 3 represents PCIe status, bit 4 represents motherboard CPLD, bit 5 represents backplane CPLD, and bits 6–7 are reserved. The RMC extracts the first 8 bytes of the Value in the record and maps them into the Health-Bitmap in big-endian order. For example, the Health-Bitmap for node 0x03 is 0x0000_0000_0000_0001, where only bit 0 = 1 indicates a CPU alarm.

[0117] Step 703: Determine the operating status of each server node based on the health status identification information.

[0118] The RMC determines the operational status (hereinafter referred to as Node-State) of each server node based on the Health-Bitmap information. Node-State is an enumeration of values: {Normal, Warning, Critical, Offline}. The determination rules are described in the Run-State-Table (a table that defines Node-State determination rules and determines Node-State based on Health-Bitmap values). Run-State-Table definition: If Health-Bitmap = 0x00 → Normal; 1–2 bits = 1 → Warning; ≥3 bits = 1 → Critical; no heartbeat timeout → Offline (If Health-Bitmap = 0x00, the node is in Normal state, meaning all components are normal; if bits 1 through 2 in the Health-Bitmap are 1, the node is in Warning state, meaning a minor issue exists but does not affect normal operation; if bits 3 or more in the Health-Bitmap are 1, the node is in Critical state, meaning a serious issue exists that may affect normal operation; if there is no heartbeat timeout, the node is in Offline state, meaning it is unresponsive or unable to communicate). The RMC matches the Health-Bitmap with the Run-State-Table item by item to determine the Node-State. For example, if only bit 0 in the Health-Bitmap of node 0x03 is 1, it corresponds to Warning.

[0119] Step 704: Generate health status reports, abnormality warning information and operation status statistics based on each server node.

[0120] The Health-Report field can be a JSON object with fields including node_id, state, bitmap, and timestamp. Alert-Info is an SNMP Trap or Redfish Event, containing severity and description. Run-Stat (where node_id represents the node identifier, uniquely identifying the server node; state represents the node state, such as normal, warning, critical, or offline; bitmap represents the health status bitmap, indicating the health status of each node component; timestamp represents the timestamp, recording the time when the data was generated; Alert-Info represents the alarm information, including the severity and description of the alarm; severity represents the severity of the alarm, such as normal, warning, critical, etc.; description represents the alarm description, explaining the specific cause of the alarm; Run-Stat represents running status statistics, recording the number of times each state occurs) is a 24-hour rolling counter that records the number of times each Node-State occurs. Specifically, RMC performs the following operations:

[0121] Encapsulate Health-Report:

[0122] {"node_id":0x03,"state":"Warning","bitmap":"0x01","timestamp":0x667B8D10};

[0123] If Node-State ≥ Warning, generate Alert-Info:

[0124] {severity:Warning,description:"CPU temperature high"};

[0125] Note: The above code describes the status reporting and alarm generation logic in a monitoring system. {"node_id":0x03,"state":"Warning","bitmap":"0x01","timestamp":0x667B8D10} indicates that the server with node ID 0x03 is in the "Warning" state. Its health status bitmap is 0x01, which typically indicates a CPU problem. The timestamp is 0x667B8D10. If the node status reaches or exceeds the "Warning" level, an alarm is generated with a severity of "Warning" and a description of "CPU temperature too high."

[0126] Update Run-Stat: Warning counter +1.

[0127] For example, the abnormal alarm information Alert-Info (which can be an alarm information in Redfish Event format, including alarm severity and description) of node 0x03 is sent to the network management platform through UDP (User Datagram Protocol) port 162, and the cumulative alarm count Warning = 47 times is recorded in / var / log / rmc_stat.json.

[0128] Through steps 701 to 704, the entire cabinet server can summarize the node health status in real time in a structured and scalable manner, automatically generate readable health status reports, subscribeable abnormal alarm information and traceable operation status statistics, and realize accurate visualization and closed-loop operation and maintenance of the operation status of the entire cabinet server.

[0129] In one of the embodiments of the present application, Figure 8 As shown in the figure, after the entire cabinet server is powered on, the BMC starts immediately, and obtains the sensor data of all server nodes through periodic sampling. It adds a timestamp and CRC32 checksum to each data in the predefined format of TLV-TS-CRC-DS, and uses the preset RSA-2048 private key PrivKey-BMC to perform digital signature operation to generate Sig-Sensor, and then writes the encapsulated record into one of the double buffers currently in the write-ready state in the SIB. The buffer header Ver is atomically incremented after each write is completed; RMC then sends an access request carrying its own PubKey-RMC, receives the random number challenge returned by BMC, and sends it back with the corresponding PrivKey-RMC signature. After verification by BMC, Once the challenge-response authentication is completed, RMC then reads all records in the SIB through memory-mapped I / O zero-copy, decrypts Sig-Sensor using PubKey-BMC to obtain Origin-Hash, and recalculates Current-Hash for the record content and verifies CRC32. If Origin-Hash is consistent with Current-Hash and CRC32 is correct, the information integrity check is passed. RMC then parses the 8-byte Health-Bitmap of the verified record, determines the node's operating status as normal, warning, critical, or offline based on the Run-State-Table, and generates JSON (JavaScriptObject) accordingly. The system generates health status reports in the form of Health-Report (Notation, JavaScript Object Notation), exception alarm information in the form of SNMPTrap (Simple Network Management Protocol Trap) or RedfishEvent, and operation status statistics in the form of 24-hour rolling counts. The above results are finally returned to the cloud management platform or local log through the out-of-band management network, completing the closed loop and realizing low-latency, high-reliability, and high-integrity node-level monitoring data interaction between BMC and RMC, thereby improving the operation and maintenance efficiency and fault response speed of the entire cabinet server.

[0130] According to the second aspect, the present application provides a whole cabinet server node monitoring system, such as Figure 9 As shown, the system is applied to a whole cabinet server. A shared information band is pre-divided in the storage space of the whole cabinet server. Each server node in the whole cabinet server is configured with a baseboard management controller. The whole cabinet server is configured with a rack management controller, including:

[0131] The sensor data writing module 110 is used to enable the baseboard management controller to obtain the sensor data of each server node, attach a corresponding timestamp and cyclic redundancy check code to each sensor data according to a predefined format, and generate a corresponding digital signature for each sensor data using a preset algorithm; and write each sensor data, corresponding timestamp, cyclic redundancy check code and digital signature into the shared information band.

[0132] The access request verification module 120 is used to enable the rack management controller to send an access request to the baseboard management controller, where the access request carries the public key of the rack management controller; receive a random number challenge returned by the baseboard management controller, sign the random number challenge using the private key corresponding to the public key, and then return it to the baseboard management controller so that the baseboard management controller can use the public key to verify the signature to complete identity authentication.

[0133] The shared data verification module 130 is used to enable the rack management controller to read each sensor data, corresponding cyclic redundancy check code and each digital signature from the shared information band after the identity authentication is passed; use the public key of the baseboard management controller to verify the legitimacy of each digital signature, and verify the integrity of each sensor data based on each cyclic redundancy check code.

[0134] The monitoring result generating module 140 is used to enable the rack management controller to generate monitoring results of each server node according to each sensor data after the integrity verification and the legality verification are passed.

[0135] In some embodiments, the shared information band is divided into a first buffer and a second buffer, and the headers of the first buffer and the second buffer are provided with version numbers. The sensor data writing module 110 is further configured to cause the baseboard management controller to identify the first buffer or the second buffer in a write-ready state as the current buffer; write each sensor data, corresponding timestamp, cyclic redundancy check code, and digital signature into the current buffer; and when the current buffer is full or a preset time interval is reached, cause the baseboard management controller to switch to another buffer to perform the write operation, and increment the version number of the current buffer after each write is completed.

[0136] In some embodiments, the sensor data writing module 110 is also used to enable the baseboard management controller to adjust the size of each data type partition in the first buffer and the second buffer according to the data type of each sensor data and its corresponding current data volume; prioritize each sensor data according to the importance of the component associated with each data type to obtain sensor data of multiple priorities; when the remaining capacity of the shared information band is lower than the preset threshold, the high priority data is used to overwrite the low priority data in order from high to low priority, and before each overwriting, the low priority data to be overwritten is backed up to the dedicated directory of the corresponding server node.

[0137] In some embodiments, the sensor data writing module 110 is also used to enable the baseboard management controller to obtain a pre-generated key pair, which includes a public key and a private key; use the private key to perform a digital signature operation on each sensor data or the summary of the sensor data to generate a digital signature corresponding to each sensor data.

[0138] In some embodiments, the sensor data writing module 110 is also used to enable the baseboard management controller to perform a hash operation on each sensor data or the summary of the sensor data to obtain a hash value corresponding to each sensor data; use a private key to perform an encryption operation on each hash value to generate a digital signature corresponding to each sensor data.

[0139] In some embodiments, the shared data verification module 130 is also used to read each sensor data and the digital signature corresponding to the sensor data from the shared information band; use the public key of the baseboard management controller to decrypt each digital signature to obtain the original hash value; perform hash calculation on each read sensor data to obtain the current hash value; if the original hash value is consistent with the current hash value and the cyclic redundancy check code is correct, the verification is determined to be passed; if any item is inconsistent, the verification is determined to have failed, and an alarm log record is triggered.

[0140] In some embodiments, the monitoring result generation module 140 is also used to read one or more target sensor data that have passed integrity verification and legitimacy verification from the shared information band; parse each target sensor data to obtain the health status identification of each server node; determine the operating status of each server node based on each health status identification information; and generate a health status report, abnormal alarm information and operating status statistical information for each server node based on the operating status of each server node.

[0141] Regarding the specific limitations applicable to the whole-cabinet server node monitoring system, please refer to the limitations applicable to the whole-cabinet server node monitoring method above, which will not be repeated here. The various modules applicable to the whole-cabinet server node monitoring system can be implemented in whole or in part through software, hardware, and a combination thereof. The above modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to the above modules.

[0142] According to a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of any one of the whole-cabinet server node monitoring methods in the above-mentioned embodiments are implemented.

[0143] According to a fourth aspect, the present application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When executed, the processor implements the steps of any one of the whole-cabinet server node monitoring methods in the above-mentioned embodiments.

[0144] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 10 As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data related to the monitoring of the entire cabinet server node. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, it implements any of the above-mentioned methods for monitoring the entire cabinet server node.

[0145] In particular, any reference to memory, storage, database, or other media used in the various embodiments provided herein may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), memory bus (RamCUs), direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0146] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0147] The above embodiments merely illustrate several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make numerous variations and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application.

[0148] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprise," "include," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not preclude the presence of additional identical elements in the process, method, article, or apparatus comprising the element.< / type>

Claims

1. A method for monitoring server nodes in a whole cabinet, characterized in that: The method is applied to a whole-rack server, wherein a shared information band is pre-divided in the storage space of the whole-rack server, each server node in the whole-rack server is configured with a baseboard management controller, and the whole-rack server is configured with a rack management controller; the method comprises: The baseboard management controller obtains sensor data from each of the server nodes, adds a corresponding timestamp and cyclic redundancy check code to each of the sensor data according to a predefined format, and generates a corresponding digital signature for each of the sensor data using a preset algorithm; and writes each of the sensor data, the corresponding timestamp, the cyclic redundancy check code, and the digital signature into the shared information band; The rack management controller sends an access request to the baseboard management controller, the access request carrying the public key of the rack management controller; receives a random number challenge returned by the baseboard management controller, signs the random number challenge using a private key corresponding to the public key, and then sends the signature back to the baseboard management controller, so that the baseboard management controller uses the public key to verify the signature to complete identity authentication; After the identity authentication is passed, the rack management controller reads each sensor data, each corresponding cyclic redundancy check code, and each digital signature from the shared information band; verifies the legitimacy of each digital signature using the public key of the baseboard management controller, and verifies the integrity of each sensor data based on each cyclic redundancy check code; After the integrity verification and the legality verification are passed, the rack management controller generates a monitoring result of each server node according to each sensor data.

2. The method according to claim 1, characterized in that The shared information band is divided into a first buffer zone and a second buffer zone, and the headers of the first buffer zone and the second buffer zone are provided with version numbers. The baseboard management controller writes each of the sensor data, the corresponding timestamps, the cyclic redundancy check codes, and the digital signatures into the shared information band, including: identifying the first buffer or the second buffer in a write-ready state as a current buffer; Writing each of the sensor data, the corresponding timestamps, the cyclic redundancy check codes, and the digital signatures into the current buffer; When the current buffer is full or a preset time interval is reached, the baseboard management controller switches to another buffer to perform a write operation, and increments the version number of the current buffer after each write is completed.

3. The method according to claim 2, characterized in that Also includes: The baseboard management controller adjusts the size of each data type partition in the first buffer and the second buffer according to the data type of each sensor data and the corresponding current data volume; Prioritizing each of the sensor data according to the importance of components associated with each of the data types to obtain sensor data of multiple priorities; When the remaining capacity of the shared information band is lower than the preset threshold, the high-priority data will overwrite the low-priority data in descending order of priority, and before each overwriting, the low-priority data to be overwritten will be backed up to the dedicated directory of the corresponding server node.

4. The method according to claim 2, characterized in that The baseboard management controller generates a corresponding digital signature for each of the sensor data using a preset algorithm, including: Obtain a pre-generated key pair, the key pair comprising a public key and a private key; The private key is used to perform a digital signature operation on each of the sensor data or the summary of the sensor data to generate a digital signature corresponding to each of the sensor data.

5. The method according to claim 4, characterized in that The baseboard management controller uses the private key to perform a digital signature operation on each of the sensor data or a summary of the sensor data to generate a digital signature corresponding to each of the sensor data, including: Performing a hash operation on each of the sensor data or a digest of the sensor data to obtain a hash value corresponding to each of the sensor data; The private key is used to perform an encryption operation on each hash value to generate a digital signature corresponding to each sensor data.

6. The method according to claim 5, characterized in that The rack management controller verifies the legitimacy of each digital signature using the public key of the baseboard management controller, and verifies the integrity of each sensor data based on each cyclic redundancy check code, including: Reading each of the sensor data and the digital signature corresponding to the sensor data from the shared information band; Decrypting each digital signature using the public key of the baseboard management controller to obtain an original hash value; Performing hash calculation on each of the sensor data read to obtain a current hash value; If the original hash value is consistent with the current hash value and the cyclic redundancy check code is correct, the verification is determined to be successful; If any of the items are inconsistent, the verification is considered to have failed and an alarm log record is triggered.

7. The method according to claim 6, characterized in that The rack management controller generates monitoring results for each server node based on each sensor data, including: Reading one or more target sensor data that have passed integrity verification and legality verification from the shared information band; Parsing the target sensor data to obtain the health status identifier of each server node; Determining the operating status of each server node based on the information of each health status identifier; Generate health status reports, abnormality warning information and operation status statistics of each server node according to the operation status of each server node.

8. A whole cabinet server node monitoring system, characterized in that: The system is applied to a whole-rack server, wherein a shared information band is pre-divided in the storage space of the whole-rack server, each server node in the whole-rack server is configured with a baseboard management controller, and the whole-rack server is configured with a rack management controller, including: a sensor data writing module, configured to enable the baseboard management controller to obtain sensor data from each server node, append a corresponding timestamp and cyclic redundancy check code to each sensor data according to a predefined format, and generate a corresponding digital signature for each sensor data using a preset algorithm; and write each sensor data, the corresponding timestamp, the cyclic redundancy check code, and the digital signature into the shared information band; an access request verification module, configured to cause the rack management controller to send an access request to the baseboard management controller, the access request carrying the public key of the rack management controller; receive a random number challenge returned by the baseboard management controller, sign the random number challenge using a private key corresponding to the public key, and then return the signature to the baseboard management controller, so that the baseboard management controller can use the public key to verify the signature to complete identity authentication; a shared data verification module, configured to, after identity authentication is passed, enable the rack management controller to read each sensor data, each corresponding cyclic redundancy check code, and each digital signature from the shared information band; verify the legitimacy of each digital signature using the public key of the baseboard management controller, and verify the integrity of each sensor data based on each cyclic redundancy check code; The monitoring result generating module is used to enable the rack management controller to generate the monitoring result of each server node according to each sensor data after the integrity verification and the legality verification are passed.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

Images