Protocol switching management method and apparatus, electronic device, and storage medium

Abstract

The application discloses a protocol switching management method and device, electronic equipment and a storage medium, and relates to the technical field of computers. Through the application, a standardized application program interface is set, differences in underlying protocols are shielded, unified access of multiple protocols is supported, a dynamic protocol adaptation algorithm is used to dynamically adapt to real-time load changes, and the optimal protocol is dynamically selected, so that the management efficiency is improved. The application realizes protocol dynamic adaptation and collaborative work in a server management scenario, avoids mis-switching protocols caused by temporary congestion of communication protocols, and improves operation and maintenance efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a protocol switching management method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of cloud computing, edge computing, and 5G technologies, modern data centers are increasingly demanding real-time, reliable, and intelligent server management. As a core component of server hardware management, the baseboard management controller faces critical challenges in protocol compatibility and data synchronization efficiency. Traditional management protocols such as IPMI, due to their low bandwidth (≤1Gbps) and poor scalability, struggle to support high-concurrency operations. While the modern protocol Redfish supports high throughput and flexible expansion, it still relies on IPMI for firmware upgrades and secure erasure, leading to protocol fragmentation and operational process inconsistencies. Existing technologies employ fixed-rule protocol switching, selecting between IPMI and Redfish protocols through timed switching or simple threshold judgments (such as network latency thresholds). This results in a high protocol switching misjudgment rate (>38%), an inability to dynamically adapt to real-time load changes, and protocol rigidity. Summary of the Invention

[0003] This application provides a protocol switching management method, apparatus, electronic device, and storage medium to at least solve the problems of high misjudgment rate, inability to dynamically adapt to real-time load changes, and protocol rigidity in related technologies during protocol switching.

[0004] This application provides a protocol switching management method, including:

[0005] Set up a standardized application programming interface, and configure a first communication protocol and a second communication protocol in the standardized application programming interface;

[0006] Obtain communication performance index data of the first communication protocol and the second communication protocol, and construct a communication protocol scoring model based on the communication performance index and its corresponding dynamic weight parameters;

[0007] The dynamic weight parameters corresponding to the communication performance indicators are set and adjusted in real time using a reinforcement learning algorithm.

[0008] The first communication protocol score and the second communication protocol score are obtained through the communication protocol scoring model, and the comparison results are obtained by comparing the first communication protocol score and the second communication protocol score.

[0009] The switching state of the first or second communication protocol is controlled based on the current communication protocol information and the comparison result.

[0010] This application also provides a protocol switching management device, which includes:

[0011] A unified management interface layer module is used to set up standardized application programming interfaces (APIs) and configure a first communication protocol and a second communication protocol in the standardized APIs.

[0012] The status monitoring module is used to acquire communication performance index data of the first communication protocol and the second communication protocol, and to construct a communication protocol scoring model based on the communication performance index and its corresponding dynamic weight parameters.

[0013] The dynamic weight parameter adjustment module is used to set the dynamic weight parameters corresponding to the communication performance indicators and adjust them in real time through a reinforcement learning algorithm.

[0014] The weight calculation module is used to obtain the first communication protocol score and the second communication protocol score through the communication protocol scoring model respectively, and compare the first communication protocol score and the second communication protocol score to obtain a comparison result;

[0015] The dynamic routing decision module is used to control the switching state of the first communication protocol or the second communication protocol based on the current communication protocol information and the comparison result.

[0016] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described protocol switching management methods when executing the computer program.

[0017] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described protocol switching management methods.

[0018] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described protocol switching management methods.

[0019] This application establishes a standardized application programming interface, shields differences in underlying protocols, supports unified access to multiple protocols, and dynamically adapts to real-time load changes through a dynamic protocol adaptation algorithm, dynamically selecting the optimal protocol to improve management efficiency. It realizes dynamic protocol adaptation and collaborative work in server management scenarios, avoids accidental protocol switching due to temporary communication protocol congestion, and improves operation and maintenance efficiency. Attached Figure Description

[0020] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a diagram illustrating the application environment of the protocol switching management method in one embodiment of this application;

[0022] Figure 2 This is a flowchart illustrating a protocol switching management method in one embodiment of this application;

[0023] Figure 3 This is a logic diagram of a protocol switching management method in one embodiment of this application;

[0024] Figure 4 This is a flowchart illustrating a real-time synchronization method used in one embodiment of this application.

[0025] Figure 5 This is a flowchart illustrating a batch synchronization method used in one embodiment of this application;

[0026] Figure 6 This is a flowchart illustrating the dual-protocol hot standby mechanism in one embodiment of this application;

[0027] Figure 7 This is a structural block diagram of a protocol switching management device in one embodiment of this application;

[0028] Figure 8 This is an internal structural diagram of a computer device in one embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0030] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

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

[0032] Traditional BMC management solutions only support a single protocol (such as IPMI or Redfish), making them unsuitable for mixed protocol scenarios. The IPMI protocol has low bandwidth (≤1Gbps) and poor scalability, making it difficult to support high-concurrency operation and maintenance (such as large-scale cluster configuration); while the Redfish protocol still relies on the IPMI protocol in scenarios such as firmware upgrades and secure erasure, resulting in protocol fragmentation and operation and maintenance process fragmentation.

[0033] IPMI protocol: Low-level hardware management based on binary commands, supporting basic functions such as sensor monitoring and power control, but lacking the ability to adapt to modern cloud-native environments.

[0034] Redfish protocol: A RESTful interface based on JSON, supporting fine-grained resource management and automated operation and maintenance, but it has high computing power requirements for embedded BMC and poor compatibility with older devices.

[0035] Existing technologies use fixed rules to control protocol switching, selecting between the IPMI and Redfish protocols through timed switching or simple threshold judgments (such as network latency thresholds). The core process is as follows: Protocol detection: Determines whether the Redfish protocol is reachable through heartbeat detection; Static switching: If the Redfish protocol is unreachable, switch to the IPMI protocol; Data synchronization: Use a polling mechanism (such as pulling data every 5 seconds) to synchronize the status information of the IPMI and Redfish protocols.

[0036] The shortcomings of existing technologies are as follows: high handover misjudgment rate (>38%): fixed thresholds cannot dynamically adapt to real-time load changes. For example, in high-concurrency scenarios, brief congestion of the Redfish protocol may lead to erroneous handover to the IPMI protocol, which reduces efficiency; low synchronization efficiency: the polling mechanism occupies 40%-50% of the bandwidth, which cannot meet the low latency requirements (≤1ms) of 5G URLLC scenarios; data consistency risk: critical state changes (such as hardware failures) may be missed within the polling interval, resulting in a response delay >150ms and a missed detection rate >12%.

[0037] Data synchronization suffers from inefficiency. Existing technologies employ pure event-triggered data synchronization, relying solely on Redfish protocol's EventService to subscribe to resource change events (such as exceeding temperature limits) to trigger data synchronization. The process is as follows: Event listening: Redfish registers an event listener and subscribes to resource update events; Passive synchronization: After an event is triggered, IPMI protocol data is pulled; Conflict handling: Relies on manual intervention to resolve data conflicts between protocols.

[0038] The shortcomings of existing technologies are: high false negative rate: relying solely on event triggers may overlook non-event-related data changes (such as slow sensor drift), with a false negative rate >12%; lack of automatic repair: manual intervention is required when data is lost or conflicting, resulting in high maintenance costs; insufficient real-time performance: the event processing link latency is >150ms, which cannot meet the requirements of real-time control.

[0039] Furthermore, the IPMI and Redfish protocols employ a hybrid data management approach, storing monitoring data (time-series) and configuration data (relational) together in a traditional relational database, resulting in low query efficiency (average latency > 500ms) and high-frequency write bottlenecks.

[0040] This application addresses the three core pain points of traditional BMC technology: protocol rigidity, inefficient synchronization, and chaotic storage. It provides a protocol switching management method that can be applied to applications such as... Figure 1 The application environment shown is illustrated. The system architecture includes a unified management interface layer, a protocol intelligent switching engine, a hybrid data synchronization service, and fault recovery and security modules.

[0041] Unified Management Interface Layer: Provides standardized API interfaces, shielding underlying protocol differences and supporting unified access across multiple protocols. Supports OAuth 2.0 authentication and RBAC access control. Sub-modules: Common Data Model (CDM): Abstracts operations into unified objects, adapting to different protocol commands. Protocol Adapter: Automatically converts commands to Redfish or IPMI protocols based on request type.

[0042] Protocol Intelligent Switching Engine: Dynamically selects the optimal protocol to improve management efficiency. Sub-modules: Weight Calculation Module: Calculates protocol weights based on real-time network latency, BMC load, and heartbeat status. Status Monitoring Module: Collects protocol health metrics (such as Redfish protocol response time and IPMI protocol CPU utilization).

[0043] Hybrid Data Synchronization Service: Enables efficient synchronization and consistency assurance of multi-protocol data. Sub-modules: Real-time Synchronization Module: Triggers instant data retrieval via event subscription (response time ≤ 1ms). Batch Synchronization Module: Compares data versions daily, transmitting only the differing fields (bandwidth usage reduced by 50%).

[0044] Fault Recovery and Security Module: Ensures reliable protocol switching and secure communication. Submodule: Dual Protocol Hot Standby: In case of Redfish protocol failure, the IPMI protocol takes over within 0.8 seconds. Hardware-Level Encryption: TPM 2.0 stores AES-256 keys for encrypted IPMI protocol communication.

[0045] This application proposes an innovative solution combining dynamic protocol adaptation, hybrid data synchronization, and a layered storage architecture. Its technical background is deeply rooted in the industry trends of data center intelligence, real-time edge computing, and hybrid cloud management. By integrating Redfish's efficient data interaction capabilities with the hardware-level monitoring advantages of IPMI (Intelligent Platform Management Interface), it achieves dynamic protocol adaptation and collaborative operation in server management scenarios. The system automatically selects the optimal protocol through an intelligent switching mechanism and designs a hybrid data synchronization method, combining real-time push and event triggering (strategies) to ensure efficient integration and consistent storage of hardware status, alarm logs, and configuration information in a multi-protocol environment. The data storage architecture adopts a layered design, achieving a comprehensive breakthrough in protocol switching accuracy, synchronization bandwidth utilization, and query efficiency.

[0046] Specifically, such as Figure 2 , Figure 3 As shown, an embodiment of this application provides a protocol switching management method, including the following steps:

[0047] Step S1: Set up a standardized application programming interface (API), and configure the first communication protocol and the second communication protocol in the standardized API.

[0048] Step S2: Obtain communication performance index data of the first and second communication protocols, and construct a communication protocol scoring model based on the communication performance indexes and their corresponding dynamic weight parameters.

[0049] Step S3: Set the dynamic weight parameters corresponding to the communication performance indicators and adjust them in real time using a reinforcement learning algorithm;

[0050] Step S4: Obtain the first communication protocol score and the second communication protocol score through the communication protocol scoring model respectively, and compare the first communication protocol score and the second communication protocol score to obtain the comparison result;

[0051] Step S5: Control the switching state of the first or second communication protocol based on the current communication protocol information and the comparison results.

[0052] The preset number of times is preferably 3. If the score of the second communication protocol is lower than the score of the first communication protocol for 3 consecutive times, the protocol switching is triggered and the switching time is ≤0.5 seconds.

[0053] Preferably, the first communication protocol is the IPMI protocol, and the second communication protocol is the Redfish protocol. This application sets up a standardized application programming interface, shields the differences in underlying protocols, supports unified access to multiple protocols, and dynamically adapts to real-time load changes through a dynamic protocol adaptation algorithm, dynamically selects the optimal protocol, improves management efficiency, realizes dynamic protocol adaptation and collaborative work in server management scenarios, avoids erroneous protocol switching due to temporary communication protocol congestion, and improves operation and maintenance efficiency.

[0054] In this embodiment, obtaining communication performance index data of the first and second communication protocols, and constructing a communication protocol scoring model based on the communication performance indexes and their corresponding dynamic weight parameters includes:

[0055] Set communication performance metrics including average network latency, processor idle rate, and heartbeat detection success rate;

[0056] Set corresponding dynamic weight parameters for average network latency, processor idle rate, and heartbeat detection success rate;

[0057] A communication protocol scoring model is constructed by weighted summation based on average network latency, processor idle rate, heartbeat detection success rate, and their dynamic weight parameters.

[0058] Among them, average network latency, processor load idle rate, and heartbeat detection success rate are indicators of protocol health, which can provide comprehensive feedback on the health status of the protocol.

[0059] In this embodiment, setting the dynamic weight parameters corresponding to the communication performance indicators and adjusting them in real time using a reinforcement learning algorithm includes:

[0060] Define the state space as a triplet, which includes the average network latency, processor load idle rate, and heartbeat detection success rate.

[0061] The action space is set to incrementally adjust the values ​​of dynamic weight parameters corresponding to average network latency, processor load idle rate, and heartbeat detection success rate, and the step size of each incremental adjustment time step is limited.

[0062] The Q-value table is updated periodically based on historical switching data. An ε-greedy strategy is used to explore randomly with probability ε and select the action with probability 1-ε that maximizes the current Q-value to determine the values ​​of dynamic weight parameters corresponding to the average network latency, processor load idle rate, and heartbeat detection success rate. The Q-value table includes the status of communication performance indicators and their corresponding actions.

[0063] The step size of each time step is limited to ±0.1 step size. The Q-Table is updated every 24 hours based on historical switching data. The exploration and utilization are balanced through the ε-greedy strategy to ensure that the weight parameters dynamically adapt to the network environment.

[0064] The Q-table is a key component of the Q-Learning algorithm, used to store and update the value estimate for each state-action pair. The Q-table has dimensions equal to the number of states S multiplied by the number of actions A. Each element in the table represents the expected reward of taking an action in the current state. The Q-table is a two-dimensional array where rows represent different states and columns represent all actions that can be taken in that state. The value of each cell represents the expected reward (i.e., the Q-value) of taking the corresponding action in that state. Q-Learning iteratively updates this table, gradually approximating the optimal policy.

[0065] In this embodiment, the Q-value table is updated periodically based on historical switching data. An ε-greedy strategy is used to randomly explore with probability ε, and the action with the highest current Q-value is selected with probability 1-ε to determine the values ​​of the dynamic weight parameters corresponding to the average network latency, processor idle rate, and heartbeat detection success rate.

[0066] Update the Q-value table using historical switching data, initialize the values ​​of dynamic weight parameters and greedy coefficient ε corresponding to the average network latency, processor load idle rate, and heartbeat detection success rate, and set a Q-value corresponding to each state-action. The Q-value stores the cumulative reward value of taking action a in state s.

[0067] Observe the communication performance index data of the first and second communication protocols at the current time t, obtain the difference ΔQ(s,a) before and after the Q value update, and determine whether the Q value table converges based on the difference ΔQ(s,a) before and after the Q value update.

[0068] If ΔQ(s,a) is less than the convergence criterion, then the Q-value table is determined to meet the convergence criterion, and the action with the largest Q-value is selected.

[0069] If ΔQ(s,a) is greater than the convergence criterion, then the Q-value table does not meet the convergence criterion. Therefore, the state s at the current time t is considered. t Choose the action a with the highest Q value according to probability 1-ε. t Calculate the reward r t According to the selected action a t The upper and lower limit switching thresholds are used to adjust the values ​​of dynamic weight parameters corresponding to the initial network average latency, processor load idle rate, and heartbeat detection success rate, and system status feedback is obtained based on the state s at time t+1. t+1 Update the Q-value table.

[0070] The Q-value function is updated as follows:

[0071] Q(s t ,a t )←Q(s t ,a t)+α[r t +γmaxQ(s t+1 ,a t )-Q(s t ,a t )];

[0072] Where α represents the learning rate, γ represents the discount factor, and Q(s) t ,a t () indicates that at the current time t, the state is s. t The value of the action, taking action a t It then reaches state s at time t+1. t+1 And receive a reward r t+1 At this point, find the value in the Q-value table that enables the state s t+1 Take the most valuable action 'a' to obtain Q(s). t+1 ,a), for Q(s) t ,a t )renew.

[0073] like Figure 3 As shown, in this embodiment, obtaining the first communication protocol score and the second communication protocol score through the communication protocol scoring model includes:

[0074] Intermittently send all injection requests in packets, measure round-trip time, and calculate the average network latency corresponding to the first and second communication protocols;

[0075] Monitor processor load, obtain processor utilization in real time, and calculate processor idle rate based on processor utilization.

[0076] Heartbeat detection is performed on the first communication protocol and the second communication protocol respectively, and the heartbeat success rate is statistically analyzed and calculated for the first communication protocol and the second communication protocol.

[0077] The average network latency corresponding to the second communication protocol is denoted as Dr, the processor load idle rate corresponding to the second communication protocol is denoted as Lr, and the heartbeat success rate corresponding to the second communication protocol is denoted as Hr.

[0078] The average network latency corresponding to the first communication protocol is denoted as Di, the processor load idle rate corresponding to the first communication protocol is denoted as Li, and the heartbeat success rate corresponding to the first communication protocol is denoted as Hi.

[0079] The values ​​of the dynamic weight parameters for the network average latency, processor load idle rate, and heartbeat detection success rate corresponding to the second communication protocol are denoted as α1, β1, and γ1, respectively.

[0080] The values ​​of the dynamic weight parameters for the average network latency, processor load idle rate, and heartbeat detection success rate corresponding to the first communication protocol are denoted as α2, β2, and γ2, respectively.

[0081] The score of the second communication protocol is calculated based on the communication protocol scoring model using Wr=α1·(1 / Dr)+β1·Lr+γ1·Hr.

[0082] The score of the first communication protocol is calculated based on the communication protocol scoring model using Wi = α2·(1 / Di) + β2·Li + γ2·Hi.

[0083] Network latency is measured using ICMP Ping, specifically Round-Trip Time (RTT), in milliseconds (ms). The network latency detection method involves sending a full packet injection (ICMP Ping) request to both the first and second communication protocols every 200ms, and then calculating the average network latency. The formula for calculating the average network latency is: RTT k Let n be the round-trip time of the network delay for the kth sampling, where 1 ≤ k ≤ n, and n is the number of sampling network delays, preferably n = 5.

[0084] The idle load rate is calculated as 1 - CPU utilization, where CPU utilization is obtained through the first communication command, the first communication tool sensor get "CPU Utilization". The formula for calculating the processor idle load rate is: L = 1 - U; for example, if U = 70%, then L = 30%.

[0085] The heartbeat success rate is, for example, the success rate of the most recent 10 heartbeat detections, calculated as: Heartbeat Success Rate = Number of Successful Detections / Total Number of Detections × 100%. If, based on the results of the most recent 10 heartbeat detections, the second communication was successful 8 times and the first communication was successful 10 times, then Hr = 8 / 10 = 80%, and Hi = 10 / 10 = 100%.

[0086] In this embodiment, controlling the switching state of the first or second communication protocol based on the current communication protocol information and comparison results includes:

[0087] In response to the current communication protocol being the first communication protocol, if the score of the first communication protocol is lower than the score of the second communication protocol for a preset number of consecutive times, the first communication protocol will be switched to the second communication protocol; otherwise, the first communication protocol will be maintained.

[0088] In response to the current communication protocol being the second communication protocol, if the score of the second communication protocol is lower than the score of the first communication protocol for a preset number of consecutive times, the second communication protocol will be switched to the first communication protocol; otherwise, the second communication protocol will be maintained.

[0089] Protocol switching judgment: if Wi<Wr occurs 3 consecutive times, the first communication protocol is triggered to switch to the second communication protocol; if Wr<Wi occurs 3 consecutive times, the second communication protocol is triggered to switch to the first communication protocol, and the routing table is updated and the management software is notified.

[0090] Adopting the method of calculating the score of the second communication protocol and the score of the first communication protocol can solve the problem of protocol rigidity, and dynamic protocol adaptation significantly improves operation and maintenance efficiency. Through the dynamic protocol adaptation algorithm, the protocol score is calculated based on multi-dimensional real-time indicators including network delay, BMC load idle rate and heartbeat success rate, so as to realize intelligent switching. The false protocol switching rate is reduced from >38% in the prior art to <5%. The switching time is ≤0.5 seconds, which supports seamless switching in high-concurrency scenarios (such as a cluster of thousands of servers).

[0091] In the communication protocol scoring model, the communication protocol scoring calculation formula based on network delay (D), load idle rate (L) and heartbeat success rate (H) is W=α·(1 / D)+β·L+γ·H, where α∈[0.4,0.6], β∈[0.2,0.4], γ∈[0.1,0.3], and the real-time indicator collection data thereof includes ICMP Ping network delay detection, CPU utilization monitoring and heartbeat success rate statistics.

[0092] In addition, the dynamic weight parameters of network delay (D), load idle rate (L) and heartbeat success rate (H) are related to the communication capability of the corresponding server, and are adjusted in real time through the reinforcement learning algorithm based on Q-Learning. Therefore, in this embodiment, calculating the score of the first communication protocol and the score of the second communication protocol respectively by weighted summation according to the values of average network delay, processor load idle rate, heartbeat detection success rate and their dynamic weight parameters comprises:

[0093] Setting the values of the dynamic weight parameters of average network delay, processor load idle rate and heartbeat detection success rate corresponding to the second communication protocol to be the same as the values of the dynamic weight parameters of average network delay, processor load idle rate and heartbeat detection success rate corresponding to the first communication protocol.

[0094] This can reduce the separate adjustment of dynamic weight parameter values corresponding to the two protocols respectively, and reduce the demand for computing power.

[0095] As Figure 3 shown, in this embodiment, switching to the first communication protocol comprises:

[0096] In response to switching to the first communication protocol, triggering an instruction to switch to the first communication protocol;

[0097] In response to receiving the instruction to switch to the first communication protocol, preloading the session key of the first communication protocol into the shared memory;

[0098] The incomplete request is migrated to the first communication protocol by interrupting and redirecting the migration request, and the routing table is updated.

[0099] Among these measures, interrupt redirection technology ensures seamless migration of incomplete requests.

[0100] In this embodiment, a standardized application programming interface (API) is set up, and the configuration of a first communication protocol and a second communication protocol in the standardized API includes:

[0101] When configuring the first communication protocol, set the IP address and default port of the first communication protocol, enable encrypted communication, use a dynamic key for authentication, and use a hash algorithm for key derivation;

[0102] When configuring the second communication protocol, set the resource locator of the second communication service, configure the authentication and permission model, and set the subscription address of the event service.

[0103] Specifically, the first communication protocol interface parameter configuration is as follows:

[0104] IP address and port: Set the IP address and default port for primary communication, and enable SSL / TLS 1.3 encrypted communication.

[0105] Authentication key: Generate a 16-byte dynamic key (e.g., 0x120x340x56...) and use the SHA-256 hash algorithm for key derivation.

[0106] Sensor Polling: Configure the first communication sensor polling interval to 1 second, and set the CPU utilization alarm threshold to 75% (triggering protocol switching conditions).

[0107] Specifically, the second communication protocol interface parameter configuration is as follows:

[0108] RESTful API endpoint: Define the second communication service URL as https: / / <BMC_IP> Enable OAuth2.0 authentication in / redfish / v1 and configure the RBAC permission model (such as administrator and operator roles).

[0109] Event subscription: Set the EventService subscription address to / redfish / v1 / EventService, the heartbeat detection interval to 200ms, and the timeout threshold to 500ms.

[0110] In this embodiment, the protocol switching management method further includes:

[0111] Mixed data synchronization is performed on the first communication data received based on the first communication protocol and the second communication data received based on the second communication protocol. The mixed data synchronization method includes real-time synchronization and batch synchronization.

[0112] In response to the real-time synchronization method of the hybrid data synchronization method, the event service of the second communication protocol is subscribed to through the WebSocket long connection, the event type (such as TemperatureExceeded, PowerStateChange) is registered, the event triggering conditions are set, and when the event triggering conditions are met, the second communication protocol pushes a text-formatted event message;

[0113] In response to an event trigger, the first communication protocol is invoked within a limited time to obtain the binary data of the corresponding event, the binary data is parsed into a text format conversion event message, and the text format conversion event message and the text format event message are checked for data consistency.

[0114] In response to the mixed data synchronization mode being a batch synchronization mode, a full data comparison task is set to start during idle time. The comparison data is divided into data blocks according to a preset storage capacity (4KB). The file backup (Rsync) algorithm is used to identify the difference fields and the blocks where the difference fields are located. At the same time, the event logs of the real-time synchronization mode are compared.

[0115] The block containing the difference fields is obtained as the change block. The data in the change block is compressed to form a difference file. The difference file is transmitted via Hypertext Transfer Security Protocol (HTTPS). Cyclic Redundancy Check (CRC32) is used to verify the data integrity of the sender and receiver. If the data verification result of the sender is equal to the data verification result of the receiver, the verification is considered successful, and the stored content is updated according to the difference file. If the data verification result of the sender is not equal to the data verification result of the receiver, the verification is considered to have failed, and the difference file is transmitted using a breakpoint resume method.

[0116] A hybrid data synchronization mechanism is implemented to optimize bandwidth and response time, combining event-triggered real-time synchronization with batch differential transmission to achieve low-latency and high-integrity data synchronization.

[0117] For example, the event trigger condition is: when the CPU temperature exceeds a threshold (e.g., 85°C), the second communication protocol pushes a text-formatted event message.

[0118] Within 1ms of the event being triggered, the first communication command `ipmitool sensor get "CPU Temp"` is invoked to acquire real-time data. Data retrieval is completed within 1ms of the event being triggered, with a response delay of ≤1ms, and the false negative rate is reduced from greater than 12% to less than 2%.

[0119] Data Conversion: Parse the first communication binary data into a text format (JSON format) and match it with the SensorData object of the Common Data Model (CDM).

[0120] The data consistency verification methods include:

[0121] Use a hash algorithm to obtain the hash value of the second communication data and the hash value of the first communication data, and compare the hash value of the second communication data with the hash value of the first communication data.

[0122] When the hash value of the second communication data is equal to the hash value of the first communication data, it is written to storage;

[0123] When the hash value of the second communication data is not equal to the hash value of the first communication data, an alarm is triggered and synchronization is retried.

[0124] The hash algorithm used is specifically the SHA-256 hash algorithm. The maximum number of synchronization retries is 3.

[0125] This embodiment supports the extremely low latency requirements (≤1ms) of 5G URLLC scenarios while ensuring data consistency (SHA-256 hash verification).

[0126] For example, if the idle time is 2:00 AM every day, the comparison task is started at 2:00 AM every day. The data is divided into 4KB blocks, the Rsync algorithm is used to identify the difference fields, and the event logs of the real-time synchronization module are compared to ensure the data integrity of unprocessed events.

[0127] Difference file generation: Only the changed blocks are transmitted, and the compression algorithm uses LZ4 compression with a compression ratio of more than 50%.

[0128] The daily full comparison uses the Rsync algorithm and LZ4 compression, reducing the amount of transmitted data by at least 50% and bandwidth usage by 20%-30%.

[0129] In this embodiment, the protocol switching management method further includes:

[0130] The stored data is classified into time-series data and configuration data, and the time-series data and configuration data are stored in layers.

[0131] When storing time-series data, the time-series data is divided into multiple fragments according to the timestamp and the segmented storage duration. The fragments are written to the buffer in batches and the Time Series Index (TSI) is enabled.

[0132] When storing configuration data, a binary tree index (B-Tree) is created for the server ID and firmware version fields of the configuration data, and hot data is cached through a database (Redis);

[0133] When querying time-series data, materialized views are enabled to display the queried time-series data.

[0134] The dual-protocol hot standby mechanism detects whether the second communication protocol has failed by using a heartbeat detection timeout method. If the second communication protocol fails, it switches to the first communication protocol.

[0135] Among them, time-series data storage (InfluxDB):

[0136] Sharding strategy: InfluxDB's sharding strategy is set to generate one shard every hour based on timestamps (ShardDuration = 1h), and Time Series Index (TSI) is enabled. For high-frequency queries (such as 'average CPU usage over the past hour'), ​​pre-computed materialized views are used with an aggregation granularity of 1 minute, reducing query latency from 500ms to <50ms.

[0137] Write optimization: Batch write buffer (Buffer Size = 10,000 records), enable Time Series Indexing (TSI).

[0138] Query downsampling: Aggregates 1-second granular data into a 1-minute average, reducing query load by 80%.

[0139] Among them, the configuration data storage (PostgreSQL):

[0140] Index optimization: A binary tree index was created for the ServerID and FirmwareVersion fields, reducing query latency from 500ms to 50ms.

[0141] Cache acceleration: Use Redis to cache hot data (LRU strategy, cache hit rate >95%).

[0142] The unified query API provides a RESTful interface GET / api / data? type=metric&server=1, supporting joint queries of time series and configuration data.

[0143] Pre-calculation optimization: Enable materialized views for high-frequency queries (such as "average CPU usage over the past hour").

[0144] The time-series data (InfluxDB) and configuration data (PostgreSQL) are physically separated to optimize storage and query efficiency.

[0145] Time-series data: Write throughput increased to 120,000 records / second, and query latency decreased from more than 500ms to less than 50ms (through time slicing and downsampling).

[0146] Configuration data: B-Tree indexes and Redis caching reduce query latency to 50ms, with a cache hit rate of >95%.

[0147] This embodiment supports the fine-grained monitoring requirements of new hardware such as GPUs / FPGAs, improving scalability by 200%.

[0148] In addition, protocol switching management methods also include: fault recovery and security assurance.

[0149] like Figure 6 As shown, the dual-protocol hot standby mechanism includes:

[0150] Enhanced heartbeat detection: When Redfish malfunctions, the heartbeat detection interval is shortened from 200ms to 50ms, and the judgment timeout time is 150ms.

[0151] IPMI takeover process: Activate the IPMI session within 0.8 seconds and synchronize the OAuth Token and session key via shared memory.

[0152] State synchronization: Use distributed locks (such as Redis Lock) to ensure atomic operations during protocol switching and avoid data conflicts.

[0153] Hardware-level encryption implementation methods include:

[0154] Key Management: The TPM 2.0 chip stores the AES-256 master key. The session key used for HMAC-SHA256 signing is derived from this master key and dynamically generated through the key negotiation mechanism of the SSL / TLS 1.3 protocol.

[0155] IPMI communication encryption: Employs the SSL / TLS 1.3 protocol, with key negotiation using the ECDHE-RSA algorithm. Session keys are derived using the HMAC-SHA256 algorithm, conforming to the NIST SP 800-108 standard. Input parameters include the master key, context tag (e.g., 'IPMI_Key'), and a counter. During key rotation, the old key is encrypted and archived using TPM 2.0's sealed storage function, ensuring a seamless transition. IPMI communication uses the SSL / TLS 1.3 protocol, with key negotiation using the ECDHE-RSA algorithm. The key length is 4096 bits, and the certificate chain is verified in real-time via OCSP.

[0156] The data integrity protection method is as follows: an HMAC-SHA256 signature is added to the transmitted data to prevent tampering: Signature = HMAC-SHA256(Data,Key).

[0157] Dual-protocol hot standby mechanism (IPMI takes over within 0.8 seconds in case of Redfish failure) and hardware-level encryption (TPM 2.0 stores AES-256 keys) ensure system reliability.

[0158] In the event of a Redfish failure, the heartbeat detection interval is reduced to 50ms, and the fault determination time is ≤150ms. IPMI communication uses SSL / TLS 1.3 encryption, with a key rotation cycle of 24 hours, and data integrity is protected by HMAC-SHA256 signatures. Distributed locks (such as Redis Lock) ensure atomicity of switching and avoid data conflicts.

[0159] The above protocol switching management method sets up a standardized application programming interface, shields the differences in underlying protocols, supports unified access to multiple protocols, and dynamically adapts to real-time load changes through a dynamic protocol adaptation algorithm, dynamically selects the optimal protocol, improves management efficiency, realizes dynamic protocol adaptation and collaborative work in server management scenarios, avoids erroneous protocol switching due to temporary congestion of communication protocols, and improves operation and maintenance efficiency.

[0160] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0161] In one embodiment, see Figure 1 ,like Figure 7 As shown, a protocol switching management device 10 is provided, including: a unified management interface layer module 1, a status monitoring module 2, a dynamic weight parameter adjustment module 3, a weight calculation module 4, and a dynamic routing decision module 5.

[0162] The unified management interface layer module 1 is used to set up standardized application programming interfaces (APIs) and configure the first and second communication protocols within these APIs.

[0163] The status monitoring module 2 is used to acquire communication performance index data of the first communication protocol and the second communication protocol, and to construct a communication protocol scoring model based on the communication performance index and its corresponding dynamic weight parameters.

[0164] The dynamic weight parameter adjustment module 3 is used to set the dynamic weight parameters corresponding to the communication performance indicators and adjust them in real time through reinforcement learning algorithms.

[0165] The weight calculation module 4 is used to obtain the first communication protocol score and the second communication protocol score through the communication protocol scoring model, and to compare the first communication protocol score and the second communication protocol score to obtain the comparison result.

[0166] The dynamic routing decision module 5 is used to control the switching state of the first or second communication protocol based on the current communication protocol information and comparison results.

[0167] In this embodiment, obtaining communication performance index data of the first and second communication protocols, and constructing a communication protocol scoring model based on the communication performance indexes and their corresponding dynamic weight parameters includes:

[0168] Set communication performance metrics including average network latency, processor idle rate, and heartbeat detection success rate;

[0169] Set corresponding dynamic weight parameters for average network latency, processor idle rate, and heartbeat detection success rate;

[0170] A communication protocol scoring model is constructed by weighted summation based on average network latency, processor idle rate, heartbeat detection success rate, and their dynamic weight parameters.

[0171] In this embodiment, setting the dynamic weight parameters corresponding to the communication performance indicators and adjusting them in real time using a reinforcement learning algorithm includes:

[0172] Define the state space as a triplet, which includes the average network latency, processor load idle rate, and heartbeat detection success rate.

[0173] The action space is set to incrementally adjust the values ​​of dynamic weight parameters corresponding to average network latency, processor load idle rate, and heartbeat detection success rate, and the step size of each incremental adjustment time step is limited.

[0174] The Q-value table is updated periodically based on historical switching data. An ε-greedy strategy is used to explore randomly with probability ε and select the action with probability 1-ε that maximizes the current Q-value to determine the values ​​of dynamic weight parameters corresponding to the average network latency, processor load idle rate, and heartbeat detection success rate. The Q-value table includes the status of communication performance indicators and their corresponding actions.

[0175] In this embodiment, obtaining the first communication protocol score and the second communication protocol score through the communication protocol scoring model includes:

[0176] Intermittently send all injection requests in packets, measure round-trip time, and calculate the average network latency corresponding to the first and second communication protocols;

[0177] Monitor processor load, obtain processor utilization in real time, and calculate processor idle rate based on processor utilization.

[0178] Heartbeat detection is performed on the first communication protocol and the second communication protocol respectively, and the heartbeat success rate is statistically analyzed and calculated for the first communication protocol and the second communication protocol.

[0179] The average network latency corresponding to the second communication protocol is denoted as Dr, the processor load idle rate corresponding to the second communication protocol is denoted as Lr, and the heartbeat success rate corresponding to the second communication protocol is denoted as Hr.

[0180] The average network latency corresponding to the first communication protocol is denoted as Di, the processor load idle rate corresponding to the first communication protocol is denoted as Li, and the heartbeat success rate corresponding to the first communication protocol is denoted as Hi.

[0181] The values ​​of the dynamic weight parameters for the network average latency, processor load idle rate, and heartbeat detection success rate corresponding to the second communication protocol are denoted as α1, β1, and γ1, respectively.

[0182] The values ​​of the dynamic weight parameters for the average network latency, processor load idle rate, and heartbeat detection success rate corresponding to the first communication protocol are denoted as α2, β2, and γ2, respectively.

[0183] The score of the second communication protocol is calculated based on the communication protocol scoring model using Wr=α1·(1 / Dr)+β1·Lr+γ1·Hr.

[0184] The score of the first communication protocol is calculated based on the communication protocol scoring model using Wi = α2·(1 / Di) + β2·Li + γ2·Hi.

[0185] In this embodiment, controlling the switching state of the first or second communication protocol based on the current communication protocol information and comparison results includes:

[0186] In response to the current communication protocol being the first communication protocol, if the score of the first communication protocol is lower than the score of the second communication protocol for a preset number of consecutive times, the first communication protocol will be switched to the second communication protocol; otherwise, the first communication protocol will be maintained.

[0187] In response to the current communication protocol being the second communication protocol, if the score of the second communication protocol is lower than the score of the first communication protocol for a preset number of consecutive times, the second communication protocol will be switched to the first communication protocol; otherwise, the second communication protocol will be maintained.

[0188] In this embodiment, switching to the first communication protocol includes:

[0189] In response to switching to the first communication protocol, a switch to the first communication protocol command is triggered;

[0190] In response to receiving a command to switch to the first communication protocol, the first communication protocol session key is preloaded into shared memory;

[0191] The incomplete request is migrated to the first communication protocol by interrupting and redirecting the migration request, and the routing table is updated.

[0192] In this embodiment, a standardized application programming interface (API) is set up, and the configuration of a first communication protocol and a second communication protocol in the standardized API includes:

[0193] When configuring the first communication protocol, set the IP address and default port of the first communication protocol, enable encrypted communication, use a dynamic key for authentication, and use a hash algorithm for key derivation;

[0194] When configuring the second communication protocol, set the resource locator of the second communication service, configure the authentication and permission model, and set the subscription address of the event service.

[0195] In this embodiment, please refer to Figure 1 ,like Figure 7 As shown, the protocol switching management device 10 also includes a hybrid data synchronization service module 6, which is used for:

[0196] Mixed data synchronization is performed on the first communication data received based on the first communication protocol and the second communication data received based on the second communication protocol. The mixed data synchronization method includes real-time synchronization and batch synchronization.

[0197] In response to the real-time synchronization method of the hybrid data synchronization method, the event service of the second communication protocol is subscribed to through the WebSocket long connection, the event type (such as TemperatureExceeded, PowerStateChange) is registered, the event triggering conditions are set, and when the event triggering conditions are met, the second communication protocol pushes a text-formatted event message;

[0198] In response to an event trigger, the first communication protocol is invoked within a limited time to obtain the binary data of the corresponding event, the binary data is parsed into a text format conversion event message, and the text format conversion event message and the text format event message are checked for data consistency.

[0199] In response to the mixed data synchronization mode being a batch synchronization mode, a full data comparison task is set to start during idle time. The comparison data is divided into data blocks according to a preset storage capacity (4KB). The file backup (Rsync) algorithm is used to identify the difference fields and the blocks where the difference fields are located. At the same time, the event logs of the real-time synchronization mode are compared.

[0200] The block containing the difference fields is obtained as the change block. The data in the change block is compressed to form a difference file. The difference file is transmitted via Hypertext Transfer Security Protocol (HTTPS). Cyclic Redundancy Check (CRC32) is used to verify the data integrity of the sender and receiver. If the data verification result of the sender is equal to the data verification result of the receiver, the verification is considered successful, and the stored content is updated according to the difference file. If the data verification result of the sender is not equal to the data verification result of the receiver, the verification is considered to have failed, and the difference file is transmitted using a breakpoint resume method.

[0201] In this embodiment, please refer to Figure 1 ,like Figure 7 As shown, the protocol switching management device 10 also includes a hierarchical storage architecture module 7, which is used for:

[0202] The stored data is classified into time-series data and configuration data, and the time-series data and configuration data are stored in layers.

[0203] When storing time-series data, the time-series data is divided into multiple fragments according to the timestamp and the segmented storage duration. The fragments are written to the buffer in batches and the Time Series Index (TSI) is enabled.

[0204] When storing configuration data, a binary tree index (B-Tree) is created for the server ID and firmware version fields of the configuration data, and hot data is cached through a database (Redis);

[0205] When querying time-series data, materialized views are enabled to display the queried time-series data.

[0206] The dual-protocol hot standby mechanism detects whether the second communication protocol has failed by using a heartbeat detection timeout method. If the second communication protocol fails, it switches to the first communication protocol.

[0207] The aforementioned protocol switching management device features a standardized application programming interface (API) that shields underlying protocol differences and supports unified access to multiple protocols. Through a dynamic protocol adaptation algorithm, it dynamically adapts to real-time load changes and dynamically selects the optimal protocol, thereby improving management efficiency. This enables dynamic protocol adaptation and collaborative work in server management scenarios, avoiding erroneous protocol switching due to temporary communication protocol congestion and improving operational efficiency.

[0208] For a description of the features in the embodiment corresponding to the protocol switching management device, please refer to the relevant description in the embodiment corresponding to the protocol switching management method, which will not be repeated here.

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

[0210] In one embodiment, the electronic device may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, this electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores protocol switching management data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a protocol switching management method.

[0211] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the protocol switching management method when it is run.

[0212] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

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

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

[0215] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0216] The foregoing has provided a detailed description of a protocol switching management method, apparatus, electronic device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A protocol switching management method, characterized in that, include: A standardized application programming interface (API) is set up, and a first communication protocol and a second communication protocol are configured in the standardized API; wherein the first communication protocol is the IPMI protocol and the second communication protocol is the Redfish protocol; The communication performance index data of the first communication protocol and the second communication protocol are obtained, and a communication protocol scoring model is constructed based on the communication performance index and its corresponding dynamic weight parameters; wherein, the communication performance index includes average network latency, processor load idle rate, and heartbeat detection success rate; The dynamic weight parameters corresponding to the communication performance indicators are set and adjusted in real time using a reinforcement learning algorithm. The first communication protocol score and the second communication protocol score are obtained through the communication protocol scoring model, and the comparison results are obtained by comparing the first communication protocol score and the second communication protocol score. The communication protocol scoring model calculates the communication protocol score by W = α·(1 / D)+β·L+γ·H, where D is the average network latency, L is the processor load idle rate, H is the heartbeat success rate, and α, β, and γ are weight parameters. The switching state of the first or second communication protocol is controlled based on the current communication protocol information and the comparison result. The step of controlling the switching state of the first communication protocol or the second communication protocol based on the current communication protocol information and the comparison result includes: In response to the current communication protocol being the first communication protocol, if the score of the first communication protocol is lower than the score of the second communication protocol for a preset number of consecutive times, then the first communication protocol will be switched to the second communication protocol; otherwise, the first communication protocol will be maintained. In response to the current communication protocol being the second communication protocol, if the score of the second communication protocol is lower than the score of the first communication protocol for a preset number of consecutive times, the second communication protocol will be switched to the first communication protocol; otherwise, the second communication protocol will be maintained.

2. The protocol switching management method according to claim 1, characterized in that, The step of obtaining communication performance index data of the first communication protocol and the second communication protocol, and constructing a communication protocol scoring model based on the communication performance index and its corresponding dynamic weight parameters includes: Set corresponding dynamic weight parameters for the average network latency, the processor load idle rate, and the heartbeat detection success rate; A communication protocol scoring model is constructed by weighted summation based on the average network latency, the processor load idle rate, the heartbeat detection success rate, and their dynamic weight parameters.

3. The protocol switching management method according to claim 2, characterized in that, The step of setting the dynamic weight parameters corresponding to the communication performance index and adjusting them in real time through a reinforcement learning algorithm includes: The state space is defined as a triplet, which includes the average network latency, processor load idle rate, and heartbeat detection success rate. The action space is set to incrementally adjust the values ​​of the dynamic weight parameters corresponding to the network average latency, processor load idle rate, and heartbeat detection success rate, and the step size of each incremental adjustment time step is limited. The Q-value table is updated periodically based on historical switching data. An ε-greedy strategy is used to randomly explore with probability ε and select the action with probability 1−ε to determine the values ​​of the dynamic weight parameters corresponding to the average network latency, processor load idle rate, and heartbeat detection success rate. The Q-value table includes the status of communication performance indicators and their corresponding actions.

4. The protocol switching management method according to claim 3, characterized in that, The process of periodically updating the Q-value table based on historical switching data, and determining the values ​​of the dynamic weight parameters corresponding to the average network latency, processor idle rate, and heartbeat detection success rate by using an ε-greedy strategy to randomly explore with probability ε and selecting the action with the largest current Q-value with probability 1−ε includes: Update the Q-value table using historical switching data, initialize the values ​​of dynamic weight parameters and greedy coefficient ε corresponding to the average network latency, processor load idle rate, and heartbeat detection success rate, and set a Q-value corresponding to each state-action. The Q-value stores the cumulative reward value of taking action a in state s. Observe the communication performance index data of the first and second communication protocols at the current time t, obtain the difference ΔQ(s,a) before and after the Q value update, and determine whether the Q value table converges based on the difference ΔQ(s,a) before and after the Q value update. If ΔQ(s,a) is less than the convergence criterion, then the Q-value table is determined to meet the convergence criterion, and the action with the largest Q-value is selected. If ΔQ(s, a) is greater than the convergence criterion, then the Q-value table does not meet the convergence criterion. Therefore, the state s at the current time t is considered. t Choose the action a with the highest Q value according to probability 1-ε. t Calculate the reward r t According to the selected action a t The upper and lower limit switching thresholds are used to adjust the values ​​of dynamic weight parameters corresponding to the initial network average latency, processor load idle rate, and heartbeat detection success rate, and system status feedback is obtained based on the state s at time t+1. t+1 Update the Q-value table.

5. The protocol switching management method according to claim 2, characterized in that, The process of obtaining the first communication protocol score and the second communication protocol score through the communication protocol scoring model includes: Intermittently send all packet injection requests, measure round-trip time, and calculate the average network latency corresponding to the first and second communication protocols; Monitor processor load, obtain processor utilization in real time, and calculate processor load idle rate based on processor utilization. Heartbeat detection is performed on the first communication protocol and the second communication protocol respectively, and the heartbeat success rate is statistically analyzed and calculated for the first communication protocol and the second communication protocol. The average network latency corresponding to the second communication protocol is denoted as Dr, the processor load idle rate corresponding to the second communication protocol is denoted as Lr, and the heartbeat success rate corresponding to the second communication protocol is denoted as Hr. The average network latency corresponding to the first communication protocol is denoted as Di, the processor load idle rate corresponding to the first communication protocol is denoted as Li, and the heartbeat success rate corresponding to the first communication protocol is denoted as Hi. The values ​​of the dynamic weight parameters corresponding to the second communication protocol, namely the average network latency, processor load idle rate, and heartbeat detection success rate, are denoted as α1, β1, and γ1, respectively. The values ​​of the dynamic weight parameters corresponding to the first communication protocol, namely the network average latency, processor load idle rate, and heartbeat detection success rate, are denoted as α2, β2, and γ2, respectively. Based on the communication protocol scoring model, the second communication protocol score corresponding to the second communication protocol is calculated by Wr=α1·(1 / Dr)+β1·Lr+γ1·Hr; Based on the communication protocol scoring model, the first communication protocol score corresponding to the first communication protocol is calculated using Wi=α2·(1 / Di)+β2·Li+γ2·Hi.

6. The protocol switching management method according to claim 1, characterized in that, The protocol switching management method further includes: Mixed data synchronization is performed on first communication data received based on the first communication protocol and second communication data received based on the second communication protocol. The mixed data synchronization method includes real-time synchronization and batch synchronization. In response to the fact that the hybrid data synchronization method is a real-time synchronization method, the event service of the second communication protocol is subscribed through a long connection, the event type is registered, and the event triggering conditions are set. When the event triggering conditions are met, the second communication protocol pushes a text-formatted event message. In response to an event trigger, the first communication protocol is invoked within a limited time to obtain the binary data of the corresponding event, the binary data is parsed into a text format conversion event message, and the text format conversion event message and the text format event message are checked for data consistency. In response to the fact that the hybrid data synchronization method is a batch synchronization method, a full data comparison task is set to start during the idle time, the comparison data is divided into data blocks according to the preset storage capacity, the file backup algorithm is used to identify the difference fields and the blocks where the difference fields are located, and the event logs of the real-time synchronization method are compared at the same time. The block containing the difference field is obtained as the change block. The data in the change block is compressed to form a difference file. The difference file is transmitted via the Hypertext Transfer Security Protocol (HTTP). Cyclic Redundancy Check (CRC) is used to verify the data integrity of the sender and receiver. If the data verification result of the sender is equal to the data verification result of the receiver, the verification is considered successful, and the stored content is updated according to the difference file. If the data verification result of the sender is not equal to the data verification result of the receiver, the verification is considered unsuccessful, and the difference file is transmitted using a breakpoint resume method. The stored data is classified into time-series data and configuration data, and the time-series data and configuration data are stored in a hierarchical manner. In response to storing the time-series data, the time-series data is divided into multiple segments according to the timestamp and the segmented storage duration, the segments are written to the buffer in batches, and the time series index is enabled; In response to storing the configuration data, a binary tree index is created for the server ID and firmware version fields of the configuration data, and hot data is cached in the database. When querying time-series data, materialized views are enabled to display the queried time-series data. A dual-protocol hot standby mechanism is set up to detect whether the second communication protocol has failed by using a heartbeat detection timeout method. In response to the failure of the second communication protocol, the system switches to the first communication protocol.

7. A protocol switching management device, characterized in that, include: A unified management interface layer module is used to set up a standardized application programming interface (API), in which a first communication protocol and a second communication protocol are configured; wherein the first communication protocol is the IPMI protocol and the second communication protocol is the Redfish protocol; The status monitoring module is used to acquire communication performance index data of the first communication protocol and the second communication protocol, and construct a communication protocol scoring model based on the communication performance index and its corresponding dynamic weight parameters; wherein, the communication performance index includes average network latency, processor load idle rate, and heartbeat detection success rate; The dynamic weight parameter adjustment module is used to set the dynamic weight parameters corresponding to the communication performance indicators and adjust them in real time through a reinforcement learning algorithm. The weight calculation module is used to obtain the first communication protocol score and the second communication protocol score through the communication protocol scoring model, and compare the first communication protocol score and the second communication protocol score to obtain a comparison result; the communication protocol scoring model calculates the communication protocol score by W = α·(1 / D)+β·L+γ·H, where D is the average network latency, L is the processor load idle rate, H is the heartbeat success rate, and α, β, and γ are weight parameters. A dynamic routing decision module is used to control the switching state of the first communication protocol or the second communication protocol based on the current communication protocol information and the comparison result, including: in response to the current communication protocol being the first communication protocol, if the score of the first communication protocol is lower than the score of the second communication protocol for a consecutive preset number of times, then switch the first communication protocol to the second communication protocol; otherwise, maintain the first communication protocol; in response to the current communication protocol being the second communication protocol, if the score of the second communication protocol is lower than the score of the first communication protocol for a consecutive preset number of times, then switch the second communication protocol to the first communication protocol; otherwise, maintain the second communication protocol.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the protocol switching management method as described in any one of claims 1 to 6 when executing the computer program.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the protocol switching management method as described in any one of claims 1 to 6.

Images