Information processing method, information processing device, and electronic device

Abstract

This application discloses an information processing method, an information processing apparatus, and an electronic device. The method includes: generating configuration information for controlling the updates of a plurality of target devices, the configuration information being used to divide the plurality of target devices into at least one stage group; sending update data to target devices within the current stage group and receiving status proofs returned by the target devices; determining the number of target devices in the current stage group that meet the health status based on the status proofs, and determining that the update admission conditions for the current stage are met when the proportion of the number of target devices meeting the health status to the total number of devices in the stage group reaches or exceeds a preset health proportion threshold; determining whether the acceptance conditions corresponding to the current update stage are met based on the execution results returned by the target devices, and performing the update for the next stage if the execution results meet the acceptance conditions, until all update stages are completed.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and in particular to an information processing method, an information processing device, and an electronic device. Background Technology

[0002] In the operation and maintenance management of data centers and cloud computing clusters, batch firmware or software updates for a large number of server devices are a common and critical operation. Current batch update methods typically use a one-time full update distribution, but this is prone to batch device failures due to some target devices being in abnormal operating states. Data packet signature and verification methods only verify the static attributes of the update packet itself, ignoring whether the target device has the conditions to perform the update. Furthermore, there is a lack of automated admission mechanisms, meaning that even if the overall cluster condition is poor, it may still be pushed to the next batch. Rollback mechanisms lack a provable chain of evidence for triggering the update, and the rollback operation may span multiple unrecorded intermediate states, making it difficult to accurately roll back to the last known, stable version. The batch device update process suffers from low security, low efficiency, and poor traceability. Summary of the Invention

[0003] This application provides an information processing method, an information processing device, and an electronic device.

[0004] On one hand, embodiments of this application provide a data processing method for updating multiple target devices, including: Generate configuration information for controlling the updates of the plurality of target devices. The configuration information is used to divide the plurality of target devices into at least one stage group, each stage group corresponding to an update stage, and includes device identification information of that stage group. Send update data to the target device within the current phase group and receive the status certificate returned by the target device, which is generated by the target device based on its own runtime state; The number of target devices that meet the health status in the current stage group is determined based on the status proof. When the proportion of the number of target devices that meet the health status to the total number of devices in the current stage group reaches or exceeds the preset health proportion threshold, the update admission conditions for the current stage are determined to be met. Based on the execution result returned by the target device, determine whether the acceptance conditions corresponding to the current update stage are met. If the execution result meets the acceptance conditions, proceed to the next update stage until all update stages are completed.

[0005] Optionally, the generated configuration information includes: The multiple target devices are divided into the stage groups according to a preset grouping strategy, wherein the grouping strategy includes at least one of the following: Grouping strategies based on device physical location, device network topology, device hardware configuration, device operating load, device redundancy priority, and device proportion are all applicable.

[0006] Optionally, the generated configuration information may also include: A health ratio threshold is configured for each update phase. The health ratio threshold is used to indicate the minimum proportion of the number of target devices in the current phase group that meet the health status required to perform the update operation relative to the total number of target devices in the current phase group.

[0007] Optionally, sending update data to the target device within the current phase group and receiving the status certificate returned by the target device includes: Send updated data to the target devices within the current phase group; After receiving the updated data, the target device performs integrity verification and signature verification on the updated data. After successful verification, the target device collects its own runtime status, generates and returns the status certificate.

[0008] Optionally, the step of determining the number of target devices meeting the health status within the current stage group based on the status proof, and determining whether the update admission conditions for the current stage are met when the proportion of the number of target devices meeting the health status to the total number of devices in the current stage group reaches or exceeds a preset health proportion threshold, includes: Obtain the status proof returned by each target device in the current stage group, and determine the number of target devices corresponding to the valid status proof; When the number of target devices corresponding to the valid status certificate reaches or exceeds the preset health ratio threshold as a proportion of the total number of target devices in the current stage group, it is determined that the update admission conditions for the current stage are met.

[0009] Alternatively, the method may further include: Send update execution instructions to the target devices within the current phase group; After receiving the update execution instruction, the target device performs integrity verification and signature verification on the update data again, executes the update operation, and generates an execution result. The execution result returned by the target device is received, and the execution result includes the status information corresponding to the update operation.

[0010] Alternatively, the method may further include: If the integrity verification of the updated data passes, the running status of the target device is collected through the baseboard management controller of the target device. The running status includes at least one of the following: firmware version number, startup hash value, hardware temperature, cooling status, and input / output load. The runtime state information is digitally signed using the private key of the target device, and the state proof is generated based on the runtime state information.

[0011] Optionally, determining whether the acceptance criteria for the current update phase are met based on the execution result returned by the target device includes: After the update operation in the current stage is completed, obtain the execution result returned by the target device in the current stage group, and determine the update success rate of the current stage based on the execution result; The update success rate is compared with a preset success rate threshold. When the success rate reaches or exceeds the success rate threshold, it is determined that the acceptance conditions are met, and the process proceeds to the next update stage. When the success rate is lower than the success rate threshold, a preset exception handling operation is performed.

[0012] On the other hand, embodiments of this application also provide an information processing apparatus, including: The acquisition module is used to generate configuration information for controlling the updates of the plurality of target devices. The configuration information is used to divide the plurality of target devices into at least one stage group, each stage group corresponds to an update stage, and includes device identification information of the stage group. The processing module is used to send update data to the target device in the current stage group and receive the status certificate returned by the target device, which is generated by the target device based on its own runtime state. The determination module is used to determine the number of target devices that meet the health status in the current stage group based on the status proof. When the proportion of the number of target devices that meet the health status to the total number of devices in the current stage group reaches or exceeds a preset health proportion threshold, the update admission conditions for the current stage are determined to be met. The update module is used to determine whether the acceptance conditions corresponding to the current update stage are met based on the execution results returned by the target device, and to proceed to the next update stage if the execution results meet the acceptance conditions, until all update stages are completed.

[0013] In another aspect, embodiments of this application also provide an electronic device, including: A memory for storing an executable program; a processor for executing the executable program to perform the following steps: Generate configuration information for controlling the updates of the plurality of target devices. The configuration information is used to divide the plurality of target devices into at least one stage group, each stage group corresponding to an update stage, and includes device identification information of that stage group. Send update data to the target device within the current phase group and receive the status certificate returned by the target device, which is generated by the target device based on its own runtime state; The number of target devices that meet the health status in the current stage group is determined based on the status proof. When the proportion of the number of target devices that meet the health status to the total number of devices in the current stage group reaches or exceeds the preset health proportion threshold, the update admission conditions for the current stage are determined to be met. Based on the execution result returned by the target device, determine whether the acceptance conditions corresponding to the current update stage are met. If the execution result meets the acceptance conditions, proceed to the next update stage until all update stages are completed. Attached Figure Description

[0014] Figure 1 This is a flowchart of an information processing method according to an embodiment of this application; Figure 2 Examples of embodiments of this application Figure 1 A flowchart of one embodiment of step S200; Figure 3 Examples of embodiments of this application Figure 1 A flowchart of one embodiment of step S300; Figure 4 This is another flowchart of the information processing method according to an embodiment of this application; Figure 5 This is another flowchart of the information processing method according to an embodiment of this application; Figure 6 Examples of embodiments of this application Figure 1 A flowchart of one embodiment of step S400; Figure 7 This is a schematic diagram of the structure of the information processing device according to an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0015] Various embodiments and features of this application are described herein with reference to the accompanying drawings.

[0016] It should be understood that various modifications can be made to the embodiments described herein. Therefore, the above description should not be considered as limiting, but merely as an example of embodiments. Other modifications within the scope and spirit of this application will be apparent to those skilled in the art.

[0017] The accompanying drawings, which are included in and form part of this specification, illustrate embodiments of the present application and, together with the general description of the present application given above and the detailed description of the embodiments given below, serve to explain the principles of the present application.

[0018] These and other features of this application will become apparent from the following description of preferred forms of embodiments given as non-limiting examples, with reference to the accompanying drawings.

[0019] It should also be understood that although this application has been described with reference to some specific examples, those skilled in the art can certainly implement many other equivalent forms of this application.

[0020] The above and other aspects, features and advantages of this application will become more apparent when taken in conjunction with the accompanying drawings and in view of the following detailed description.

[0021] Specific embodiments of this application are described thereafter with reference to the accompanying drawings; however, it should be understood that the claimed embodiments are merely examples of this application, which can be implemented in various ways. Well-known and / or repeated functions and structures are not described in detail to avoid unnecessary or redundant details that could obscure the application. Therefore, the specific structural and functional details claimed herein are not intended to be limiting, but merely serve as the basis and representative basis for the claims to teach those skilled in the art to use this application in a variety of substantially any suitable detailed structures.

[0022] This specification may use the phrases “in one embodiment,” “in another embodiment,” “in yet another embodiment,” or “in other embodiments,” all of which may refer to one or more of the same or different embodiments according to this application.

[0023] Figure 1 A flowchart illustrating an information processing method according to an embodiment of this application is shown. This application provides an information processing method for updating multiple target devices, such as... Figure 1 As shown, it includes: S100, generate configuration information for controlling the updates of the plurality of target devices. The configuration information is used to divide the plurality of target devices into at least one stage group, each stage group corresponds to an update stage, and includes device identification information of the stage group. The information processing method in this embodiment is applied to scenarios involving batch firmware or software updates for a large number of server devices, such as BIOS firmware upgrades, batch installation of operating system security patches, or network card driver updates for thousands of servers in a data center or cloud computing cluster. In this embodiment, configuration information for controlling the updates of multiple target devices is first generated. This configuration information can be a structured data object describing how the update is executed in batches. The configuration information divides the multiple target devices into at least one stage group, each stage group corresponding to an update stage, and includes device identification information for the target devices contained in that stage group. The device identification information can be data used to uniquely identify each target device, such as the device's hostname, IP address, or serial number. The target device can be the device that needs to be updated; specifically, the target device can be a server device. The target device can be configured with a Baseboard Management Controller (BMC) and a Trusted Platform Module (TPM) or Hardware Security Module (HSM) to support trusted runtime state acquisition and digital signatures.

[0024] S200, send update data to the target device in the current stage group, and receive the status certificate returned by the target device, the status certificate being generated by the target device based on its own runtime state; In this embodiment, after generating configuration information for controlling updates of multiple target devices, update data is sent to the target devices within the current stage group, and a status certificate returned by the target device is received. The status certificate is generated by the target device based on its own runtime state. The current stage group can be a set of target devices currently performing update operations during a multi-stage update process; the status certificate can be a trusted status certificate signed by the baseboard management controller of the target device, used to prove that the target device is in a healthy runtime state at a certain moment and has the conditions to perform the update.

[0025] Specifically, the central orchestrator sends update data to the target devices within the current phase group. Upon receiving the update data, the target devices first perform integrity verification, for example, calculating the hash value of the received update data and comparing it with the hash value in the configuration information. If they match, the verification passes, indicating that the update data has not been tampered with during transmission. Furthermore, each target device verifies the digital signature of the update data to confirm that the update data originates from a trusted central orchestrator. The central orchestrator can be a central node or core control module responsible for the unified scheduling, management, and control of the entire phased rolling update process. After both integrity and signature verifications pass, each target device collects its own runtime status, which refers to the target device's operational status information at the current moment. The status certificate is generated by the target device's baseboard management controller and digitally signed using a private key stored in the Trusted Platform Module (TPM) or Hardware Security Module (HSM). The certificate's data structure can include the following fields: manifest identifier, phase identifier, node identifier, timestamp, runtime status snapshot, random number, and validity period.

[0026] S300, determine the number of target devices that meet the health status in the current stage group based on the status proof. When the proportion of the number of target devices that meet the health status to the total number of devices in the current stage group reaches or exceeds the preset health proportion threshold, determine that the update admission conditions of the current stage are met. In this embodiment, after sending update data to the target devices within the current stage group and receiving the status certificates returned by the target devices, the number of target devices in the current stage group that meet the health status is determined based on the status certificates. A healthy status can be defined as the runtime state of a target device meeting preset health conditions; a target device meeting these conditions can be considered to be in a healthy state. The central orchestrator receives the status certificates returned by each target device in the current stage group and verifies the validity of each status certificate one by one, verifying whether the digital signature is valid, whether the timestamp is within the validity window, and whether the runtime state meets the preset health conditions. Status certificates that simultaneously meet the above conditions are determined as valid status certificates. The number of target devices corresponding to valid status certificates is counted, and the proportion of this number to the total number of target devices in the current stage group is calculated to obtain the valid proportion.

[0027] The health ratio threshold can be a preset ratio value in the configuration information for each stage. It indicates the minimum proportion of target devices in the current stage group that meet the required health status to perform update operations, relative to the total number of target devices in that stage group. The central orchestrator compares the calculated effective ratio with the health ratio threshold. When the effective ratio reaches or exceeds the health ratio threshold, it determines that the update admission conditions for the current stage are met. The update admission conditions can be the prerequisites that must be met to allow the current stage group to start executing update operations, which can be reflected in the number of target devices with the required health status reaching or exceeding the health ratio threshold. If the effective ratio does not reach the health ratio threshold, it is determined that the admission conditions are not met, the process is stopped, and an exception is triggered. Specifically, this can involve pausing the update for the current stage and waiting for a preset time before reassessing, triggering an alarm and requesting manual intervention, or terminating the current update process.

[0028] S400: Based on the execution result returned by the target device, determine whether the acceptance conditions corresponding to the current update stage are met. If the execution result meets the acceptance conditions, proceed to the next update stage until all update stages are completed.

[0029] In this embodiment, after determining that the update admission conditions for the current stage are met, the update operation for the target devices within the current stage group is executed. Specifically, the central orchestrator can issue update execution instructions to the target devices within the current stage group. After receiving the update execution instructions, the target devices perform integrity verification and signature verification on the update data. After successful verification, each target device executes the update operation. After executing the update operation, each target device generates an execution result and returns it to the central orchestrator. The execution result can be a feedback data object generated after the target device completes the update operation, used to report to the central orchestrator whether the update operation was successfully executed. The execution result can include the following information: manifest identifier and stage identifier (used to associate this update), node identifier (used to indicate which device generated the result), operation type (indicating that an update operation was performed), result code (0 indicates success, non-zero indicates failure and the corresponding error type), detailed result (including the updated firmware version and the new boot hash value), timestamp, and digital signature generated by the BMC private key.

[0030] Based on the execution results returned by the target devices, it is determined whether the acceptance criteria for the current update phase are met. These acceptance criteria can be preset judgment conditions for each phase in the configuration information, used to evaluate whether the update execution results of the current phase meet expectations, thereby deciding whether to allow entry into the next phase. After the update operation in the current phase is completed, the central orchestrator obtains the execution results returned by the target devices within the current phase group and counts the number of successfully updated target devices within the current phase group based on the execution results. The update success rate of the current phase is calculated, which is the ratio of the number of successfully updated target devices to the total number of target devices in the current phase group, and compared with a preset success rate threshold. When the update success rate reaches or exceeds the success rate threshold, the acceptance criteria are determined to be met. If the acceptance criteria are met, the central orchestrator automatically enters the next update phase, determines the phase group corresponding to the next update phase based on the configuration information, uses the next update phase as the current update phase, and repeats the process of sending update data, receiving status proof, admission judgment, executing the update, and acceptance judgment until all update phases are completed.

[0031] In one specific embodiment of this application, the parameters for this update are first configured through the management interface of the central orchestrator. The central orchestrator first generates configuration information (Staged Manifest) for controlling the updates of the six target devices.

[0032] The central orchestrator divides the six devices into three phases based on a "progressive grouping" strategy.

[0033] Phase 1: Select two servers (node-01 and node-02) as the first-phase group for small-scale verification of update package availability. The health ratio threshold is set to 100% (requiring both pilot devices to return valid status certificates), and the success rate threshold is set to 100% (requiring both pilot devices to successfully complete the update). Phase 2: Select two servers (node-03 and node-04) as the second-phase group. The health ratio threshold and success rate threshold are both set to 100%. Phase 3: Select the remaining two servers (node-05 and node-06) as the third-phase group. The health ratio threshold and success rate threshold are both set to 100%.

[0034] The central orchestrator generates configuration information in the following JSON format and digitally signs the entire configuration information using its private key: json { "manifest_id": "fw-update-20250601-rackA", "update_package_hash": "sha256:7d5a8f3c9e2b1a4f6d8c3e7b2a5f9d1c4e8b3a7f6d2c5e9b1a4f8d3c7e2b5a9f1", "stages": [ { "stage_id": "stage-1", "targets": ["node-01", "node-02"], "acceptance_criteria": { "health_ratio_threshold": 1.0, "success_rate_threshold": 1.0 }, "post_stage_validation": ["boot_test"], "rollback_point": "fw-v1.2.3-boothash:5a8f3c9e2b1a4f6d8c3e7b2a5f9d1c4e" }, { "stage_id": "stage-2", "targets": ["node-03", "node-04"], "acceptance_criteria": { "health_ratio_threshold": 1.0, "success_rate_threshold": 1.0 }, "post_stage_validation": ["boot_test"], "rollback_point": "fw-v1.2.3-boothash:5a8f3c9e2b1a4f6d8c3e7b2a5f9d1c4e" }, { "stage_id": "stage-3", "targets": ["node-05", "node-06"], "acceptance_criteria": { "health_ratio_threshold": 1.0, "success_rate_threshold": 1.0 }, "post_stage_validation": ["boot_test"], "rollback_point": "fw-v1.2.3-boothash:5a8f3c9e2b1a4f6d8c3e7b2a5f9d1c4e" } ], "global_policy": { "max_parallel_stages": 1, "stage_timeout_s": 600, "propagation_mode": "strict" }, "signed_by": "orchestrator-key-id", "signature": "base64(ed25519_signature)" } In the above configuration information: manifest_id is the unique identifier of this update manifest; update_package_hash is the SHA-256 hash value of the BIOS firmware upgrade package, used by the target device to perform integrity verification after receiving the update package; each stage includes stage_id, targets (target device list), acceptance_criteria (health ratio threshold and success rate threshold), post_stage_validation (post-stage validation items), and rollback_point; in global_policy, max_parallel_stages: 1 indicates sequential execution of each stage, stage_timeout_s: 600 indicates that the timeout for each stage is 600 seconds; signed_by and signature indicate that this configuration information is signed by the central orchestrator.

[0035] The central orchestrator uses stage 1 (stage-1) in the configuration information as the current stage, and the corresponding target devices are node-01 and node-02.

[0036] The central orchestrator first sends update data, namely the BIOS firmware upgrade package v2.0 and its hash value, to node-01 and node-02. Upon receiving the update data, node-01 and node-02 perform integrity verification. Node-01 calculates the SHA-256 hash value of the received update package, obtaining 7d5a8f3c9e2b1a4f6d8c3e7b2a5f9d1c4e8b3a7f6d2c5e9b1a4f8d3c7e2b5a9f1, which is completely consistent with the update_package_hash in the configuration information. The verification passes, indicating that the update package has not been tampered with during transmission. Next, signature verification is performed. Node-01 uses the pre-stored public key of the central orchestrator to verify the digital signature of the update package. The verification passes, confirming that the update package originates from a trusted central orchestrator. Finally, runtime status acquisition is performed. After both integrity and signature verifications pass, node-01's BMC collects the current runtime status of the device. The BMC reads the CPU temperature as 42.3℃ via a temperature sensor, the current firmware version as v1.2.3 via the System Management BIOS (SMBIOS) interface, the boot hash value as sha256:5a8f3c9e... obtained from the TPM's metric root of trust, confirms normal cooling via a fan speed sensor, verifies a recent error count of 0 via the system event log, and observes a current I / O load of 15% via PCIe interface monitoring. Then, it generates a state proof: the BMC of node-01 assembles the manifest identifier fw-update-20250601-rackA, stage identifier stage-1, node identifier node-01, timestamp 2025-06-01T10:00:01Z, runtime state snapshot, random number n-xyz-001, and expiration date 2025-06-01T10:10:01Z into a state proof message. It then uses the device private key stored in the TPM to digitally sign the entire message, generating the following state proof (Stage-readyAssertion): json { "manifest_id": "fw-update-20250601-rackA", "stage_id": "stage-1", "node_id": "node-01", "timestamp_utc": "2025-06-01T10:00:01Z", "runtime_snapshot": { "boot_hash": "sha256:5a8f3c9e2b1a4f6d8c3e7b2a5f9d1c4e8b3a7f6d2c5e9b1a4f8d3c7e2b5a9f1", "bmc_firmware_version": "v2.1.0", "cpu_temp_c": 42.3, "cooling_ok": true, "recent_error_count": 0, "io_load_pct": 15 }, "nonce": "n-xyz-001", "valid_until_utc": "2025-06-01T10:10:01Z", "signed_by": "bmc-tpm-slot-node01", "signature": "base64(ecdsa_signature)" } Node-02 performs the same operation and returns its own status certificate. After receiving the status certificates returned by Node-01 and Node-02, the central orchestrator determines the number of target devices that meet the health status requirements within the current phase group based on the status certificates, and then determines whether the update admission conditions for the current phase are met.

[0037] After receiving the state certificates returned by node-01 and node-02, the central orchestrator verifies the validity of each state certificate one by one. For the state certificate of node-01, digital signature verification is performed first. The central orchestrator uses node-01's public key to verify the ECDSA signature of the state certificate. If the verification passes, it proves that the state certificate was indeed signed by node-01's BMC. Next, validity period verification is performed. The current time 2025-06-01T10:02:30Z is before the validity period expiration time 2025-06-01T10:10:01Z, so the verification passes. Finally, health condition verification is performed. The CPU temperature of 42.3℃ is lower than the preset temperature threshold of 60℃, the cooling status is normal, the recent error count of 0 is less than the preset threshold of 5 errors, and the I / O load of 15% is lower than the preset load threshold of 80%. All health conditions are met.

[0038] The state proof of node-02 also passed the above three verifications. The state proofs returned by both devices were determined to be valid. The central orchestrator counted 2 target devices corresponding to the valid state proofs, and the total number of target devices in the current phase group was 2, resulting in a valid ratio of 2 / 2 = 100%. The health ratio threshold for Phase 1 in the configuration information is 100% (health_ratio_threshold: 1.0). Since the valid ratio of 100% reached and exceeded this threshold, the central orchestrator determined that the update admission conditions for the current phase (Phase 1) were met, and allowed the update operation to proceed.

[0039] After the central orchestrator confirms that the admission conditions are met, it sends update execution commands to node-01 and node-02, along with the rollback_point (fw-v1.2.3-boothash:5a8f3c9e...) from the configuration information. Upon receiving the update execution commands, node-01 and node-02, to ensure security, perform integrity verification and signature verification (secondary verification) on the update data again to confirm that the update data has not been tampered with. After successful verification, both devices perform a BIOS firmware upgrade operation, upgrading the firmware from v1.2.3 to v2.0. After the upgrade is complete, node-01 generates the following execution receipt and returns it to the central orchestrator: json { "manifest_id": "fw-update-20250601-rackA", "stage_id": "stage-1", "node_id": "node-01", "action": "apply_update", "result_code": 0, "details": "update_success; new_firmware_version: v2.0; boot_hash:sha256:9f4c2a7e5b1d3f8c6e2a4b7d9f1c5e3a8b6d2f4e7c9a1b3d5f7e8c2a4b6d9f1e", "timestamp_utc": "2025-06-01T10:06:30Z", "signed_by": "bmc-tpm-slot-node01", "signature": "base64(ecdsa_signature)" } The result_code: 0 indicates a successful update, and the details record the updated firmware version v2.0 and the new boot hash value. node-02 also returns an execution result with result_code of 0.

[0040] After receiving two execution results, the central orchestrator counts two successfully updated target devices, calculating the update success rate as 2 / 2 = 100%. The success rate threshold for Phase 1 in the configuration information is 100% (success_rate_threshold: 1.0). Since the update success rate reaches and exceeds this threshold, the acceptance criteria are met. Subsequently, the central orchestrator automatically enters Phase 2, grouping the two target devices (node-03 and node-04) corresponding to Phase 2 as the current phase group and repeating the above process. After Phase 2 is completed, the central orchestrator continues to Phase 3, performing updates on node-05 and node-06.

[0041] This application achieves a gradual release of update risks by dividing multiple target devices into at least one phase group, with each phase group corresponding to an update phase, and completing the update of all devices in a phase-by-phase manner. By sending update data to the target devices within the current phase group and receiving their status certificates generated based on runtime states, the real-time operating status of the target devices is verified before update execution. Access is only allowed when the health status ratio requirement is met, avoiding failures caused by performing updates on incompatible or abnormally operating target devices. By setting a health ratio threshold, the access decision, which originally relied on subjective human judgment, is transformed into a quantifiable proportional indicator. Update execution is only allowed when the proportion of target devices meeting the health status requirement reaches or exceeds a preset threshold, preventing temporary anomalies in individual devices from hindering the progress of the entire phase update. The status certificate is generated by the target device based on its own runtime state. Since the status certificate originates from the device itself, it can more realistically and comprehensively reflect the actual operating status of the target device before update execution. By automatically proceeding to the next phase of update when acceptance conditions are met, until all update phases are completed, automated progress from the first phase to the last phase is achieved. This shortens the overall update cycle and avoids efficiency losses caused by delays or misjudgments due to manual operation.

[0042] In one embodiment of this application, generating configuration information includes: The multiple target devices are divided into the stage groups according to a preset grouping strategy, wherein the grouping strategy includes at least one of the following: Grouping strategies based on device physical location, device network topology, device hardware configuration, device operating load, device redundancy priority, and device proportion are all applicable.

[0043] In this embodiment, during the generation of configuration information, the central orchestrator can divide multiple target devices into stage groups according to a preset grouping strategy. The grouping strategy determines which target devices are included in each stage group, and different grouping strategies are suitable for different update scenarios and risk control requirements.

[0044] Based on a device physical location-based grouping strategy, the central orchestrator can group devices according to their physical location. Physical location can be physical dimensions such as the rack, cabinet, or data hall where the device is located. According to the grouping strategy based on physical location, devices within the same physical area share similarities in network latency, power supply conditions, and heat dissipation. Grouping devices with adjacent physical locations into the same phase group allows for timely identification of physical environment issues in specific areas during the update process.

[0045] Based on the device network topology-based grouping strategy, the central orchestrator can group devices according to their location within the network topology. Network topology location can be based on dimensions such as the switch level, network subnet, or network region to which the device is connected. By grouping devices connected to the same switch or subnet into the same phase group according to the device network topology grouping strategy, anomalies within a specific network domain can be monitored during the update process, preventing network congestion or broadcast storms caused by updates from spreading to the entire data center network.

[0046] Based on a device hardware configuration-based grouping strategy, the central orchestrator groups target devices according to their hardware configurations. Hardware configurations can be categorized by device model, CPU model, memory specifications, network interface card (NIC) model, disk controller model, or firmware version, among other dimensions. This grouping strategy groups devices with the same or similar hardware configurations into the same phase group, ensuring that devices in the same phase group have homogeneous hardware characteristics. This allows for timely detection of compatibility issues related to specific hardware platforms during the update process.

[0047] Based on a device load-based grouping strategy, the central orchestrator groups target devices according to their current load status. Load can be measured by metrics such as CPU utilization, memory utilization, network bandwidth utilization, disk I / O load, or the number of running processes. According to the grouping strategy, devices with lower loads are updated first, followed by those with higher loads, thus minimizing the impact of updates on services. Furthermore, using low-load devices as the first batch allows for earlier detection of potential problems.

[0048] Based on a priority grouping strategy for device redundancy, the central orchestrator groups target devices according to their redundancy role or priority within the cluster. Redundancy can be categorized by dimensions such as the device's primary / standby role, the number of replicas in the cluster, the service's redundancy level, or whether it belongs to a core business node. Following this priority grouping strategy, nodes in standby roles or with high redundancy are updated first, with core nodes or primary nodes being updated last, ensuring that even if an update fails, the overall service availability of the cluster is not affected.

[0049] The incremental grouping strategy based on device proportion involves the central orchestrator grouping target devices according to their proportion within the cluster, using a gradual approach that starts with a small pilot group and expands to a larger one. This incremental grouping strategy first verifies the results with a smaller proportion (e.g., 5%), and then gradually expands to a larger proportion (e.g., 20%, 50%) after confirming no issues, eventually extending to all devices. This ensures that risk is controlled within a manageable, incremental curve.

[0050] In one embodiment of this application, the generation of configuration information further includes: A health ratio threshold is configured for each update phase. The health ratio threshold is used to indicate the minimum proportion of the number of target devices in the current phase group that meet the health status required to perform the update operation relative to the total number of target devices in the current phase group.

[0051] In this embodiment, during the generation of configuration information, after dividing the phase groups, the central orchestrator also configures a health ratio threshold for each update phase. The health ratio threshold can be a preset ratio value for each phase in the configuration information, used to indicate the minimum proportion of target devices in the current phase group that meet the required health status to allow update operations to be performed, relative to the total number of target devices in that phase group. Update operations for the update phase are only allowed when the proportion of target devices corresponding to valid status certificates reaches or exceeds the health ratio threshold.

[0052] Specifically, in dividing the 100 target devices into three phases, the central orchestrator configures a health ratio threshold of 100% for Phase 1. A higher health ratio threshold in the early stage ensures that all devices in the small-scale pilot are in a healthy state, thereby verifying the availability of the update package and the correctness of the process within a minimal scope, avoiding distortion of pilot results due to individual device anomalies. A health ratio threshold of 95% is configured for Phase 2. In the mid-stage, the health ratio threshold is appropriately relaxed, allowing a small number of devices to exclude from this round of updates due to temporary issues, while ensuring the health of the vast majority of devices. This avoids the temporary anomalies of a very small number of devices hindering the progress of the entire phase, while the relatively high 95% threshold still ensures the overall health of the cluster. A health ratio threshold of 90% is configured for Phase 3. In the later stages, the health ratio threshold can be further relaxed. After verifying and confirming that the update package and update process are problem-free in the early stages, the entry threshold can be appropriately lowered in the large-scale rollout phase to improve update efficiency. At the same time, the 90% threshold still ensures that the main part of the cluster is in a healthy state, and even the presence of a small number of unhealthy devices will not affect the overall progress of the update.

[0053] In one embodiment of this application, such as Figure 2 As shown, the step of sending update data to the target device within the current stage group and receiving the status proof returned by the target device includes: S210, send update data to the target device within the current phase group; In this embodiment, after generating configuration information, update data is sent to the target devices within the current stage group. Specifically, the central orchestrator determines the stage group corresponding to the current update stage based on the configuration information and sends update data to the target devices within that stage group. The update data may include update packages (e.g., BIOS firmware upgrade files, operating system security patches, or network card driver update packages) and reference hash values ​​for integrity verification. The update data can be transmitted via the data center's management network. Before sending, the central orchestrator digitally signs the update package using its private key to ensure the trustworthiness of the update package's origin.

[0054] S220, after receiving the updated data, the target device performs integrity verification and signature verification on the updated data; In this embodiment, after receiving the update data sent by the central orchestrator, the target device first performs an integrity check on the received update data. Specifically, the target device uses the same hash algorithm as the central orchestrator to calculate the hash value of the received update data, obtaining a first hash value. The target device compares the calculated first hash value with a reference hash value sent along with the update data. If the first hash value matches the reference hash value, the integrity check passes, indicating that the update packet has not been tampered with, damaged, or lost during network transmission; if they do not match, the integrity check fails, and the target device returns an error report to the central orchestrator, requesting a resend of the update data. After the integrity check passes, the target device verifies the digital signature of the update data. Specifically, the target device obtains the public key of the central orchestrator (which can be pre-stored in the target device's trust store) and uses this public key to verify the validity of the digital signature of the update packet. If the signature verification passes, it confirms that the update data indeed originates from a trusted central orchestrator, and is not from a malicious third party impersonating the central orchestrator; if the signature verification fails, it indicates that the source of the update data is untrustworthy, and the target device refuses to perform subsequent operations and reports the verification failure to the central orchestrator. Integrity verification and signature verification together constitute a two-layer security mechanism. The former ensures data integrity, while the latter ensures the trustworthiness of the source. Together, they ensure that the updated data received by the target device is complete and reliable.

[0055] S230, after the verification is successful, the target device collects its own runtime status, generates and returns the status certificate.

[0056] In this embodiment, after both integrity verification and signature verification pass, the target device collects its own runtime status. The runtime status can be the target device's current operating condition information, used to subsequently determine whether the target device is in a healthy state. Specifically, the Baseboard Management Controller (BMC) of the target device collects various operating parameters of the device through sensors and system interfaces. The runtime status may include: the current firmware version number, obtained by reading the BIOS version register or system management BIOS information, used to confirm whether the device's current baseline version is consistent with the upgrade starting point required by the update package; the boot hash value, obtained through the TPM's metric root of trust, used to characterize the integrity and trustworthiness of the device's boot environment; the CPU temperature, read by the BMC's temperature sensor, used to determine if the device is at risk of overheating; the cooling status, read by the BMC's fan speed sensor and temperature alarm status, used to determine if the cooling system is working properly; the recent error count, calculated by the BMC's system event log to count the number of error events that occurred recently, used to determine if the device has recently experienced frequent anomalies; and the current I / O load, obtained through the BMC's PCIe or storage interface monitoring, used to determine if the device is in a busy state that may affect the execution of the update operation. Runtime status acquisition is performed by BMC and is unaffected by the target device's main operating system status. Even if the target device's main operating system is in a crash state, BMC can still work normally and acquire the device's hardware operating parameters, ensuring the reliability and availability of status acquisition.

[0057] After runtime state acquisition is complete, the target device generates a state certificate and returns it to the central orchestrator. Specifically, the target device's BMC assembles the following information into a state certificate message: manifest_id, used to associate with the current update manifest; stage_id, used to indicate which update stage the state certificate belongs to; node_id, used to indicate which device generated the state certificate; timestamp_utc, used to record the generation time of the state certificate; runtime_snapshot, containing the collected runtime parameters; nonce, used to prevent replay attacks; and valid_until_utc, used to limit the valid time window of the state certificate. Subsequently, the BMC calls the device's private key stored in the Trusted Platform Module (TPM) or Hardware Security Module (HSM) to digitally sign the entire state certificate message. This private key is stored in the secure storage area of ​​the TPM / HSM and is designed to be unreadable externally, ensuring the security of the signing operation and the non-repudiation of the signing result. After signing, the target device returns the signed state certificate to the central orchestrator.

[0058] In one embodiment of this application, such as Figure 3 As shown, the step of determining the number of target devices meeting the health status within the current stage group based on the status proof, and determining whether the update admission conditions for the current stage are met when the proportion of the number of target devices meeting the health status to the total number of devices in the current stage group reaches or exceeds a preset health proportion threshold, includes: S310, obtain the status proof returned by each target device in the current stage group, and determine the number of target devices corresponding to the valid status proof; In this embodiment, after the central orchestrator sends update data to the target devices within the current phase group and receives status proofs returned by each target device, it determines the number of target devices within the current phase group that meet the health status criteria based on the status proofs. When the proportion of the number of target devices meeting the health status to the total number of devices in the current phase group reaches or exceeds a preset health ratio threshold, it is determined that the update admission conditions for the current phase are met. Before the actual execution of the update operation, a quantitative assessment of the overall health status of the target device cluster determines whether to allow the execution of the update for this phase.

[0059] The central orchestrator has sent update data to each target device within the current phase group and received status certificates returned by each target device. The central orchestrator first obtains the status certificates returned by each target device within the current phase group and verifies the validity of each status certificate to determine the number of target devices corresponding to valid status certificates.

[0060] The central orchestrator uses the target device's public key to verify the digital signature of the state certificate. During verification, the central orchestrator uses the target device's public key to decrypt and verify the signature value in the state certificate to confirm whether the state certificate was generated by a legitimate target device holding the corresponding private key and has not been tampered with. If the signature verification passes, it indicates that the state certificate was indeed signed by the target device's BMC using its private key stored in the TPM / HSM, and that the content is complete and the source is trustworthy; if the signature verification fails, it indicates that the state certificate may have been forged or tampered with during transmission, and the state certificate is marked as invalid.

[0061] The central orchestrator verifies the timestamp and validity period fields in the status certificate, confirming that the certificate's generation time is within a predetermined validity window. Specifically, each status certificate may contain two time-related fields: timestamp_utc (status certificate generation time) and valid_until_utc (validity expiration time). The central orchestrator obtains the current system time and compares it with the valid_until_utc field. If the current system time has not exceeded the validity expiration time indicated by valid_until_utc, the status certificate is valid and verification passes; if the current system time has exceeded the validity expiration time indicated by valid_until_utc, the status certificate has expired and is marked as invalid.

[0062] The central orchestrator extracts runtime state snapshots from the status certificate and verifies each operating parameter to ensure it meets preset health conditions. These runtime state snapshots are collected by the target device's BMC and contain all operating parameters of the target device at the time the status certificate is generated. The preset health conditions are node-level health judgment criteria that coordinate with health ratio thresholds in the configuration information.

[0063] A status certificate that meets all three verification conditions (digital signature verification passed, within the validity window, and runtime status meets health conditions) is determined to be a valid status certificate; a status certificate that fails any one or more verification conditions is determined to be an invalid status certificate.

[0064] After the central orchestrator verifies the status certificates returned by all target devices within the current phase group, it counts the number of target devices corresponding to valid status certificates, obtaining a first quantity. Simultaneously, based on the device identifier list included in the current phase group in the configuration information, the central orchestrator determines the total number of target devices within the current phase group, obtaining a second quantity. The ratio of the first quantity to the second quantity is the effective ratio subsequently used for comparison with the health ratio threshold.

[0065] S320, when the number of target devices corresponding to the valid status certificate accounts for the proportion of the total number of target devices in the current stage group to reach or exceed the preset health ratio threshold, it is determined that the update admission conditions of the current stage are met.

[0066] In this embodiment, after the central orchestrator determines the number of target devices corresponding to the valid status certificate, it can calculate the proportion of this number to the total number of target devices in the current stage group to obtain the effective proportion, and compare the effective proportion with the preset health proportion threshold in the configuration information, and determine whether the update admission conditions of the current stage are met based on the comparison result.

[0067] Specifically, the effective ratio can be the ratio of the number of target devices corresponding to valid status certificates to the total number of target devices in the current phase group. The central orchestrator obtains the health ratio threshold preset for the current phase from the configuration information. The health ratio threshold is a ratio value preset for each phase in the configuration information, used to indicate the minimum proportion of the number of target devices in the current phase group that meet the health status requirements to allow update operations to be performed, relative to the total number of target devices in that phase group.

[0068] When the effective ratio reaches or exceeds the health ratio threshold, meaning a sufficiently high proportion of target devices within the current phase group are in a healthy state, the central orchestrator determines that the update admission conditions for the current phase are met. Update admission conditions are prerequisites that must be met to allow the current phase group to begin update operations; they can be manifested as the number of target devices meeting the health ratio threshold reaching or exceeding the health ratio threshold. If the effective ratio reaches and exceeds the health ratio threshold, the central orchestrator determines that the update admission conditions are met and can further execute update operations for the target devices within the current phase group.

[0069] The health ratio threshold is used to determine whether to allow the current phase of the update to begin. Before phase execution, this determination is based on the runtime status of the target devices. Specifically, the central orchestrator collects the status certificates returned by each target device within the current phase group. By verifying the signature, validity period, and health conditions of the status certificates, it determines the number of target devices corresponding to valid status certificates and calculates the effective ratio. The central orchestrator compares this effective ratio with the preset health ratio threshold in the configuration information. When the effective ratio reaches or exceeds the health ratio threshold, it determines that the update admission conditions are met, and the update for this phase is allowed to proceed. When the effective ratio does not reach the health ratio threshold, it determines that the update admission conditions are not met, the process is stopped, and exception handling is triggered. The purpose of the health ratio threshold is to ensure that update operations are only initiated when the overall health status of the cluster meets the requirements. By quantitatively evaluating the runtime status of the target devices (including firmware version, CPU temperature, cooling status, error count, I / O load, etc.) before update execution, updates are avoided on incompatible, overheated, high-load, or potentially faulty devices, preventing batch failures and service interruptions caused by forced updates under abnormal conditions.

[0070] The success rate threshold is used to determine whether to allow entry into the next stage. After the stage is completed, the judgment is based on the update execution results of the target devices. Specifically, after the update operation of the current stage is completed, the central orchestrator collects the execution results returned by each target device in the current stage group, counts the number of target devices that have been successfully updated, and calculates the update success rate of the current stage. The central orchestrator compares this update success rate with the preset success rate threshold in the configuration information. When the update success rate reaches or exceeds the success rate threshold, it is determined that the acceptance condition is met, and the next update stage is automatically entered; when the update success rate is lower than the success rate threshold, it is determined that the acceptance condition is not met, and the preset exception handling operation is executed. The role of the success rate threshold is to ensure the reliability of the transition between stages. By quantitatively evaluating the update execution results after each stage is completed, it is ensured that the update scope is only allowed to be expanded to the next stage group when the update success rate of the current stage reaches the expected standard, thereby effectively preventing the spread of errors in the cluster.

[0071] In each stage of the execution process, the health ratio threshold comes into play first. Before starting a stage, the central orchestrator checks the health status of the target devices. Only when the cluster health status meets the requirements is entry into the stage execution phase allowed, ensuring that updates begin from a healthy starting point and avoiding predictable update failures due to device-specific issues. The success rate threshold then comes into play. After a stage is completed, the central orchestrator checks the update execution results. Only when the update success rate meets the requirements is entry into the next stage allowed, ensuring that the success of the previous stage is a necessary prerequisite for the advancement of the next stage and preventing the accumulation and spread of errors within the cluster.

[0072] In one embodiment of this application, such as Figure 4 As shown, the method further includes: S500 sends an update execution command to the target device within the current phase group; In this embodiment, after determining that the update admission conditions for the current stage are met, the central orchestrator issues an update execution command to the target devices within the current stage group. The update execution command is a control command sent by the central orchestrator to the target devices, notifying them to begin the update operation. The update execution command includes at least the following information: a manifest identifier (for associating with this update), a stage identifier (for confirming the stage), an operation type (indicating the need to perform an update operation), and a timestamp (for recording the command issuance time). The update execution command can be digitally signed by the central orchestrator using its private key to ensure the credibility of the command's origin and prevent attackers from impersonating the central orchestrator to send malicious commands to the target devices. The central orchestrator will only issue the execution command after confirming that the target device cluster meets the health ratio threshold requirements.

[0073] S600, after receiving the update execution instruction, the target device performs integrity verification and signature verification on the update data again, executes the update operation, and generates an execution result; In this embodiment, after receiving the update execution command from the central orchestrator, the target device does not immediately execute the update operation. Instead, it first performs a security verification, and then performs integrity verification and signature verification on the update data again. Specifically, the target device has already received and stored the complete update data and performed integrity verification and signature verification on the update data once. However, to prevent the update data from being tampered with within the time window between command issuance, the target device performs integrity verification and signature verification on the update data again before executing the update operation, which is called secondary verification. The target device recalculates the hash value of the stored update data and compares it with the reference hash value in the configuration information to confirm the data integrity. At the same time, the target device uses the public key of the central orchestrator to re-verify the digital signature of the update data to confirm the trustworthiness of the data source. After the secondary verification is passed, the target device executes the update operation. During the execution of the update operation, the target device's BMC continuously monitors the device's operating status to ensure that the update operation is executed under secure conditions. After the update operation is completed, the target device generates an execution result. The execution result is a feedback data object generated by the target device after completing the update operation, used to report to the central orchestrator whether the update operation was successfully executed.

[0074] S700, receive the execution result returned by the target device, the execution result including the status information corresponding to the update operation.

[0075] In this embodiment, the central orchestrator receives the execution results returned by each target device within the current stage group. The execution results include status information corresponding to the update operation, that is, the success or failure status indicated by the result code, and the updated version information, new startup hash value, etc., recorded in the detailed results. The central orchestrator can verify the digital signature of the execution results. The central orchestrator uses the target device's public key to verify the signature of the execution results, confirming the authenticity and integrity of the execution results. If the signature verification passes, the execution results are accepted and stored; if the signature verification fails, the execution results are considered untrusted, and the target device may be required to resend or trigger an alarm. The central orchestrator can parse the status information in the execution results and update the update status records of each target device. The central orchestrator marks the status of each target device as "update successful" or "update failed" and records detailed reasons for failure (such as the error type corresponding to the result code).

[0076] In one embodiment of this application, such as Figure 5 As shown, the method further includes: S800, if the integrity verification of the updated data passes, the running status of the target device is collected through the baseboard management controller of the target device. The running status includes at least one of the following: firmware version number, startup hash value, hardware temperature, cooling status, and input / output load. In this embodiment, the target device performs integrity verification and signature verification on the updated data. Once both verifications pass, the runtime state acquisition process is triggered. This runtime state acquisition is performed by the target device's Baseboard Management Controller (BMC). Specifically, the BMC obtains the target device's current firmware version number by reading the BIOS version register or through the system management BIOS interface. The firmware version number is a string identifier that identifies the currently running BIOS, UEFI, or firmware version, such as "v2.0" or "2.1.0". The BMC obtains the target device's boot hash value through the Root of Trust for Measurement (TPM). The boot hash value is a hash value generated by the TPM during device startup after measuring each component in the boot chain (including BIOS, bootloader, operating system kernel, etc.), and is used to characterize the integrity and trustworthiness of the device's startup environment. The BMC reads the current critical hardware temperatures of the target device, including CPU temperature, motherboard temperature, and memory temperature, through temperature sensors on the motherboard (such as the CPU internal temperature sensor, motherboard thermistor, etc.). Specifically, the BMC accesses temperature sensors through standard interfaces such as IPMI (Intelligent Platform Management Interface) or SMBus (System Management Bus) to obtain current temperature readings. Hardware temperature is a crucial indicator for determining whether a device is at risk of overheating. If the device temperature is too high, performing an update operation may cause hardware damage or an abnormal shutdown during the update process. The BMC comprehensively assesses the cooling status of the target device using fan speed sensors and temperature alarm status. Specifically, the BMC reads the current speed of each fan and compares it with a preset minimum speed threshold; simultaneously, the BMC checks whether temperature alarms have been triggered (such as CPU temperature exceeding warning or critical thresholds). If all fan speeds are normal and there are no temperature alarms, the cooling status is determined to be "normal"; if there are excessively low fan speeds or temperature alarms, the cooling status is determined to be "abnormal". The BMC monitors and obtains the current I / O load of the target device through the PCIe (Peripheral Component Interconnect Express) controller or storage interface. Specifically, the BMC can read the disk I / O queue depth and transfer rate through the status register of the SAS (Serial Attached SCSI) / SATA (Serial ATA) controller, or obtain I / O load data through the bandwidth utilization statistics of the PCIe port.I / O load is expressed as a percentage and is used to determine whether the device is in a busy state. If the device I / O load is too high, performing update operations may affect business performance or cause update operations to time out and fail.

[0077] S900, the runtime state information is digitally signed using the private key of the target device, and the state proof is generated based on the runtime state information.

[0078] In this embodiment, after completing runtime state collection, the target device's BMC combines the collected runtime state information with other necessary metadata into a state proof message. It then digitally signs the state proof message using the target device's private key stored in the Trusted Platform Module (TPM) or Hardware Security Module (HSM), ultimately generating a complete trusted state proof. Specifically, the BMC can assemble the manifest_id, stage_id, node_id, timestamp_utc, runtime_snapshot, nonce, and valid_until_utc into a structured state proof message.

[0079] The manifest_id can be a unique identifier for this update manifest obtained from the configuration information, used to associate the state certificate with the corresponding update manifest. For example, a value of "fw-update-20250601-001". The stage_id can be the current stage identifier obtained from the configuration information, used to indicate which update stage the state certificate belongs to. For example, a value of "stage-1". The node_id can be a unique identifier for the target device itself, used to indicate which device generated the state certificate. For example, a value of "node-001". The timestamp_utc can be the current UTC time recorded by the BMC's internal clock, used to record the generation time of the state certificate. For example, a value of "2025-06-01T10:00:01Z". The runtime state snapshot can be various collected runtime state data, including firmware version number, boot hash value, CPU temperature, cooling status, I / O load, etc. The nonce can be a cryptographically secure random number generated by BMC to prevent replay attacks. A different nonce is used each time a state proof is generated; even if other fields are identical, the signature result will differ due to the different nonces, thus preventing attackers from copying the state proof for replay. The validity period (valid_until_utc) is the expiration time of the state proof, typically set to the current time plus a preset window duration (e.g., 10 minutes), for example, "2025-06-01T10:10:01Z". This field is used to verify whether the state proof has expired.

[0080] The BMC can invoke the target device's private key stored in the Trusted Platform Module (TPM) or Hardware Security Module (HSM) to digitally sign the assembled status certificate message. The BMC inputs the normalized hash value of the status certificate message into the TPM / HSM, which then uses its internally stored private key to calculate the signature value and returns it to the BMC. The digital signature can employ asymmetric encryption algorithms, such as ECDSA (Elliptic Curve Digital Signature Algorithm) or RSA. Taking ECDSA as an example, the BMC first calculates the SHA-256 hash value of the normalized representation of the status certificate message (arranging the fields in a predetermined order and converting them into a byte sequence), then inputs this hash value into the TPM. The TPM uses its private key to perform the ECDSA signature operation, generating a signature value. The BMC fills the signature value into the signature field of the status certificate message and fills the signature subject's identification information (such as certificate fingerprint or key ID) into the signed_by field, forming a complete, digitally signed status certificate.

[0081] In one embodiment of this application, such as Figure 6 As shown, determining whether the acceptance criteria for the current update phase are met based on the execution result returned by the target device includes: S410, after the update operation of the current stage is completed, obtain the execution result returned by the target device in the current stage group, and determine the update success rate of the current stage based on the execution result; In this embodiment, the central orchestrator receives and verifies the execution results returned by each target device within the current stage group. Based on these execution results, the central orchestrator counts the number of successfully updated target devices within the current stage group and calculates the update success rate for the current stage. Specifically, the central orchestrator iterates through the execution results returned by all target devices within the current stage group, parsing the result code (result_code) field in each result. A result code of 0 indicates a successful update for the target device, while a non-zero result code indicates a failed update. Different non-zero values ​​correspond to different failure reasons (e.g., 1 indicates integrity verification failure, 2 indicates burning failure, 3 indicates timeout, 4 indicates hardware error, etc.). The central orchestrator counts the number of target devices corresponding to execution results with a result code of 0, obtaining the number of successfully updated target devices, denoted as the first quantity. Simultaneously, the central orchestrator determines the total number of target devices within the current stage group based on the device identifier list included in the current stage group in the configuration information, denoted as the second quantity.

[0082] For example, the central orchestrator calculates the update success rate for the current stage using the following formula: Update Success Rate = Number of Successfully Updated Target Devices / Total Number of Target Devices in the Current Stage Group. For instance, in Stage 1, the group contains 3 target devices. If the central orchestrator receives 3 execution results, all with a result code of 0, it indicates that all 3 devices were successfully updated. Therefore, the number of successfully updated target devices is 3, and the update success rate = 3 / 3 = 100%. In Stage 2, the group contains 17 target devices. If the central orchestrator receives 17 execution results, with 15 result codes of 0 (update successful) and 2 result codes of non-zero (update failed), then the number of successfully updated target devices is 15, and the update success rate = 15 / 17 ≈ 88.2%.

[0083] S420, compare the update success rate with a preset success rate threshold; In this embodiment, the central orchestrator compares the calculated update success rate with a preset success rate threshold in the configuration information for the current stage. The success rate threshold is a preset ratio value for each stage in the configuration information, indicating the minimum update success rate required to proceed to the next stage after the current stage is completed. Specifically, the central orchestrator compares the update success rate value with the success rate threshold value. If the update success rate ≥ the success rate threshold, the comparison result is "reached or exceeded," indicating that the update execution result of the current stage meets the expected requirements. If the update success rate < the success rate threshold, the comparison result is "below the threshold," indicating that the update execution result of the current stage does not meet the expected requirements, and there may be many device update failures, requiring the process to be stopped and the problem investigated.

[0084] S430, when the success rate reaches or exceeds the success rate threshold, it is determined that the acceptance conditions are met, and the next update stage is entered; In this embodiment, when the comparison between the update success rate and the success rate threshold shows that the update success rate reaches or exceeds the success rate threshold, the central orchestrator determines that the current stage meets the acceptance criteria. The acceptance criteria are preset judgment conditions for each stage in the configuration information, used to evaluate whether the update execution result of the current stage meets expectations, thereby deciding whether to allow entry into the next stage. After determining that the acceptance criteria are met, the central orchestrator automatically enters the next update stage. Specifically, the central orchestrator can determine the stage group corresponding to the next update stage based on the stage list in the configuration information, use the next stage group as the new current stage group, and repeatedly execute the complete update process of "sending update data → receiving status proof → admission judgment → executing update → acceptance judgment" until all update stages in the configuration information have been completed.

[0085] S440, when the success rate is lower than the success rate threshold, execute a preset exception handling operation.

[0086] In this embodiment, when the update success rate is lower than the success rate threshold, the central orchestrator determines that the current stage does not meet the acceptance criteria and executes a preset exception handling operation. The exception handling operation can trigger a rollback operation. Specifically, the central orchestrator restores the target devices in the current stage group that have completed the update to their state before the update, based on the rollback_point recorded in the configuration information. The rollback_point information records the firmware version number and boot hash value before the update, allowing the target devices to accurately restore to their state before the update. The central orchestrator sends a rollback command to the target devices in the current stage group, which includes the rollback_point information from the configuration information. After receiving the rollback command, each target device restores its firmware to the version before the update based on the firmware version information in the rollback_point; simultaneously, the target device's BMC verifies whether the restored boot hash value matches the record in the rollback_point, confirming a successful rollback. The exception handling operation can also generate alarm information, request manual intervention, or terminate the current update process.

[0087] The second aspect of this application also provides an information processing apparatus corresponding to the information processing method. Since the principle of the information processing apparatus in this application for solving the problem is similar to that of the information processing method described above, the implementation of the information processing apparatus can refer to the implementation of the method, and the repeated parts will not be described again.

[0088] Figure 7 The diagram shows a schematic representation of the information processing apparatus provided in an embodiment of this application, which may include: The acquisition module is used to generate configuration information for controlling the updates of the plurality of target devices. The configuration information is used to divide the plurality of target devices into at least one stage group, each stage group corresponds to an update stage, and includes device identification information of the stage group. The processing module is used to send update data to the target device in the current stage group and receive the status certificate returned by the target device, which is generated by the target device based on its own runtime state. The determination module is used to determine the number of target devices that meet the health status in the current stage group based on the status proof. When the proportion of the number of target devices that meet the health status to the total number of devices in the current stage group reaches or exceeds a preset health proportion threshold, the update admission conditions for the current stage are determined to be met. The update module is used to determine whether the acceptance conditions corresponding to the current update stage are met based on the execution results returned by the target device, and to proceed to the next update stage if the execution results meet the acceptance conditions, until all update stages are completed.

[0089] In one embodiment of this application, the acquisition module is further configured as follows: The multiple target devices are divided into the stage groups according to a preset grouping strategy, wherein the grouping strategy includes at least one of the following: Grouping strategies based on device physical location, device network topology, device hardware configuration, device operating load, device redundancy priority, and device proportion are all applicable.

[0090] In one embodiment of this application, the acquisition module is further configured as follows: A health ratio threshold is configured for each update phase. The health ratio threshold is used to indicate the minimum proportion of the number of target devices in the current phase group that meet the health status required to perform the update operation relative to the total number of target devices in the current phase group.

[0091] In one embodiment of this application, the acquisition module is further configured as follows: Send updated data to the target devices within the current phase group; After receiving the updated data, the target device performs integrity verification and signature verification on the updated data. After successful verification, the target device collects its own runtime status, generates and returns the status certificate.

[0092] In one embodiment of this application, the determining module is further configured as follows: Obtain the status proof returned by each target device in the current stage group, and determine the number of target devices corresponding to the valid status proof; When the number of target devices corresponding to the valid status certificate reaches or exceeds the preset health ratio threshold as a proportion of the total number of target devices in the current stage group, it is determined that the update admission conditions for the current stage are met.

[0093] In one embodiment of this application, the update module is further configured as follows: Send update execution instructions to the target devices within the current phase group; After receiving the update execution instruction, the target device performs integrity verification and signature verification on the update data again, executes the update operation, and generates an execution result. The execution result returned by the target device is received, and the execution result includes the status information corresponding to the update operation.

[0094] In one embodiment of this application, the processing module is further configured as follows: If the integrity verification of the updated data passes, the running status of the target device is collected through the baseboard management controller of the target device. The running status includes at least one of the following: firmware version number, startup hash value, hardware temperature, cooling status, and input / output load. The runtime state information is digitally signed using the private key of the target device, and the state proof is generated based on the runtime state information.

[0095] In one embodiment of this application, the update module is further configured as follows: After the update operation in the current stage is completed, obtain the execution result returned by the target device in the current stage group, and determine the update success rate of the current stage based on the execution result; The update success rate is compared with a preset success rate threshold. When the success rate reaches or exceeds the success rate threshold, it is determined that the acceptance conditions are met, and the process proceeds to the next update stage. When the success rate is lower than the success rate threshold, a preset exception handling operation is performed.

[0096] Based on the same inventive concept, such as Figure 8 As shown, this embodiment also includes an electronic device, comprising: Memory, used to store executable programs; A processor is configured to execute the executable program to perform the following steps: Generate configuration information for controlling the updates of the plurality of target devices. The configuration information is used to divide the plurality of target devices into at least one stage group, each stage group corresponding to an update stage, and includes device identification information of that stage group. Send update data to the target device within the current phase group and receive the status certificate returned by the target device, which is generated by the target device based on its own runtime state; The number of target devices that meet the health status in the current stage group is determined based on the status proof. When the proportion of the number of target devices that meet the health status to the total number of devices in the current stage group reaches or exceeds the preset health proportion threshold, the update admission conditions for the current stage are determined to be met. Based on the execution result returned by the target device, determine whether the acceptance conditions corresponding to the current update stage are met. If the execution result meets the acceptance conditions, proceed to the next update stage until all update stages are completed.

[0097] The above embodiments are merely exemplary embodiments of this application and are not intended to limit this application. The scope of protection of this application is defined by the claims. Those skilled in the art can make various modifications or equivalent substitutions to this application within its substance and scope of protection, and such modifications or equivalent substitutions should also be considered to fall within the scope of protection of this application.

Claims

1. An information processing method for updating multiple target devices, comprising: Generate configuration information for controlling the updates of the plurality of target devices. The configuration information is used to divide the plurality of target devices into at least one stage group, each stage group corresponding to an update stage, and includes device identification information of that stage group. Send update data to the target device within the current phase group and receive the status certificate returned by the target device, which is generated by the target device based on its own runtime state; The number of target devices that meet the health status in the current stage group is determined based on the status proof. When the proportion of the number of target devices that meet the health status to the total number of devices in the current stage group reaches or exceeds the preset health proportion threshold, the update admission conditions for the current stage are determined to be met. Based on the execution result returned by the target device, determine whether the acceptance conditions corresponding to the current update stage are met. If the execution result meets the acceptance conditions, proceed to the next update stage until all update stages are completed.

2. The method according to claim 1, wherein generating configuration information includes: The multiple target devices are divided into the stage groups according to a preset grouping strategy, wherein the grouping strategy includes at least one of the following: Grouping strategies based on device physical location, device network topology, device hardware configuration, device operating load, device redundancy priority, and device proportion are all applicable.

3. The method according to claim 1, wherein generating configuration information further includes: A health ratio threshold is configured for each update phase. The health ratio threshold is used to indicate the minimum proportion of the number of target devices in the current phase group that meet the health status required to perform the update operation relative to the total number of target devices in the current phase group.

4. The method according to claim 1, wherein sending update data to the target device within the current stage group and receiving the status certificate returned by the target device includes: Send updated data to the target devices within the current phase group; After receiving the updated data, the target device performs integrity verification and signature verification on the updated data. After successful verification, the target device collects its own runtime status, generates and returns the status certificate.

5. The method according to claim 1, wherein determining the number of target devices meeting the health status within the current stage group based on the status proof, and determining the fulfillment of the update admission conditions for the current stage when the proportion of the number of target devices meeting the health status to the total number of devices within the stage group reaches or exceeds a preset health proportion threshold, includes: Obtain the status proof returned by each target device in the current stage group, and determine the number of target devices corresponding to the valid status proof; When the number of target devices corresponding to the valid status certificate reaches or exceeds the preset health ratio threshold as a proportion of the total number of target devices in the current stage group, it is determined that the update admission conditions for the current stage are met.

6. The method according to claim 5, further comprising: Send update execution instructions to the target devices within the current phase group; After receiving the update execution instruction, the target device performs integrity verification and signature verification on the update data again, executes the update operation, and generates an execution result. The execution result returned by the target device is received, and the execution result includes the status information corresponding to the update operation.

7. The method according to claim 6, further comprising: If the integrity verification of the updated data passes, the running status of the target device is collected through the baseboard management controller of the target device. The running status includes at least one of the following: firmware version number, startup hash value, hardware temperature, cooling status, and input / output load. The runtime state information is digitally signed using the private key of the target device, and the state proof is generated based on the runtime state information.

8. The method according to claim 1, wherein determining whether the acceptance conditions corresponding to the current update stage are met based on the execution result returned by the target device includes: After the update operation in the current stage is completed, obtain the execution result returned by the target device in the current stage group, and determine the update success rate of the current stage based on the execution result; The update success rate is compared with a preset success rate threshold. When the success rate reaches or exceeds the success rate threshold, it is determined that the acceptance conditions are met, and the process proceeds to the next update stage. When the success rate is lower than the success rate threshold, a preset exception handling operation is performed.

9. An information processing apparatus, comprising: The acquisition module is used to generate configuration information for controlling the updates of the plurality of target devices. The configuration information is used to divide the plurality of target devices into at least one stage group, each stage group corresponds to an update stage, and includes device identification information of the stage group. The processing module is used to send update data to the target device in the current stage group and receive the status certificate returned by the target device, which is generated by the target device based on its own runtime state. The determination module is used to determine the number of target devices that meet the health status in the current stage group based on the status proof. When the proportion of the number of target devices that meet the health status to the total number of devices in the current stage group reaches or exceeds a preset health proportion threshold, the update admission conditions for the current stage are determined to be met. The update module is used to determine whether the acceptance conditions corresponding to the current update stage are met based on the execution results returned by the target device, and to proceed to the next update stage if the execution results meet the acceptance conditions, until all update stages are completed.

10. An electronic device, comprising: Memory, used to store executable programs; A processor is configured to execute the executable program to perform the following steps: Generate configuration information for controlling the updates of the plurality of target devices. The configuration information is used to divide the plurality of target devices into at least one stage group, each stage group corresponding to an update stage, and includes device identification information of that stage group. Send update data to the target device within the current phase group and receive the status certificate returned by the target device, which is generated by the target device based on its own runtime state; The number of target devices that meet the health status in the current stage group is determined based on the status proof. When the proportion of the number of target devices that meet the health status to the total number of devices in the current stage group reaches or exceeds the preset health proportion threshold, the update admission conditions for the current stage are determined to be met. Based on the execution result returned by the target device, determine whether the acceptance conditions corresponding to the current update stage are met. If the execution result meets the acceptance conditions, proceed to the next update stage until all update stages are completed.

Images