Cluster credibility verification method and device, equipment, storage medium and program product

Abstract

The invention discloses a cluster credibility verification method and device, equipment, a storage medium and a program product, and belongs to the technical field of cluster security. The method comprises the following steps: acquiring starting information of a first network node, wherein the first network node refers to any one network node which is located at the topmost layer in at least one layer and is connected with a management node; starting information of a first sub-cluster is obtained, the first sub-cluster is a sub-cluster corresponding to the first network node, and the first sub-cluster comprises all downstream nodes connected with the first network node; and generating cluster starting information based on the starting information of the first network node and the starting information of the first sub-cluster, wherein the cluster starting information is used for verifying credible starting conditions of all nodes in the cluster by verification equipment. It can be seen that the top network node serves as the information convergent point, distributed collection of the starting information is achieved, the efficiency of the management node for collecting the starting information of all the nodes in the cluster is improved, and then the efficiency of verifying the trusted starting condition of the cluster is improved.

Description

Technical Field

[0001] This application relates to the field of cluster security technology, and in particular to a cluster trusted verification method, apparatus, device, storage medium and program product. Background Technology

[0002] In modern information environments, device hardware and firmware have become key targets for attackers. Since firmware runs at the hardware level, it typically possesses the highest privileges within the system. This means that once the firmware is maliciously tampered with, attackers can bypass traditional security mechanisms (such as operating system-level security mechanisms) and gain complete control of the device. To prevent this, Trusted Boot technology can be deployed in devices. Trusted Boot technology is a technique to ensure system startup security. It utilizes a trusted platform module (TPM) to detect attacker tampering during device startup through a measurement-before-boot approach. Specifically, the Trusted Boot process starts with the core root of trust for measurement (CRTM). During device startup, the CRTM starts first and measures and verifies the integrity of the basic input / output system (BIOS). After the BIOS integrity verification is successful, the BIOS starts and transfers control to it. The BIOS then continues to execute the same process for subsequent modules—that is, measurement-before-boot—to complete the transfer of the trust chain. After trusted boot is completed, TPM generates an unalterable device metric report for the device and submits it to a remote verification server for remote verification, thereby confirming the trusted status of the device.

[0003] Based on the aforementioned trusted boot process, how to quickly and effectively collect measurement reports from a large number of devices within a computing cluster for remote verification servers to perform trusted verification has become an urgent technical problem to be solved. Summary of the Invention

[0004] This application provides a cluster trust verification method, apparatus, device, storage medium, and program product, which can quickly collect the startup information of all nodes in the cluster, allowing the verification device to perform trust verification on the entire cluster. The technical solution is as follows:

[0005] Firstly, a cluster trust verification method is provided, applied to the management node of the cluster, the cluster including multiple network nodes and multiple processing nodes, the multiple network nodes being used to implement communication connections between the multiple processing nodes, and the multiple network nodes being divided into at least one layer according to a network topology; the method includes:

[0006] The system acquires startup information for a first network node, where the first network node refers to any network node located at the top layer and connected to the management node in the at least one layer. The startup information of the first network node indicates the trusted startup status of the first network node. The system also acquires startup information for a first sub-cluster, where the first sub-cluster is the sub-cluster corresponding to the first network node and includes all downstream nodes connected to the first network node. The downstream nodes include processing nodes, or both network nodes and processing nodes. The startup information of the first sub-cluster indicates the trusted startup status of all nodes within the first sub-cluster. Based on the startup information of the first network node and the startup information of the first sub-cluster, cluster startup information is generated. This cluster startup information is used by the verification device to verify the trusted startup status of all nodes within the cluster.

[0007] Therefore, in this application, the management node is directly connected to the top-level network node, and the top-level network node is connected to the downstream sub-cluster nodes. Based on this communication connection, the management node only needs to communicate with the top-level network node to collect the cluster startup information of the entire cluster, which greatly simplifies the communication link. At the same time, the top-level network node, as the information aggregation point, is responsible for collecting the startup information of all downstream nodes connected to it and transmitting the startup information of all downstream nodes to the management node. This realizes the distributed collection of startup information, avoids single point bottlenecks and failure risks, and also avoids the management node collecting the startup information of each downstream node one by one. This greatly reduces the time overhead of collecting the startup information of the entire cluster, improves the efficiency of the management node in collecting the startup information of all nodes in the cluster, and thus improves the efficiency of the verification device in verifying the trusted startup status of the cluster.

[0008] When there are multiple top-level network nodes, these nodes can collect startup information from their respective connected downstream nodes in parallel. This method of multiple top-level network nodes collecting startup information in parallel significantly improves the speed of startup information collection across the entire cluster, with even more pronounced effects in large clusters. Moreover, regardless of the cluster size or the number of processing nodes, the management node can quickly collect startup information for the entire cluster using only a small number of top-level network nodes.

[0009] In one possible implementation, obtaining the startup information of the first network node includes:

[0010] Send a node identifier acquisition request to the first network node, the node identifier acquisition request being used to request the acquisition of the identity identifier of the first network node; receive a first identity identifier sent by the first network node, the first identity identifier being the identity identifier of the first network node; if it is determined based on the first identity identifier that the startup information of the first network node has not been acquired, then acquire the startup information of the first network node.

[0011] In one possible implementation, determining that the startup information of the first network node has not been obtained based on the first identity identifier includes:

[0012] Obtain a global data structure, which is used to store the identity identifiers of the multiple network nodes, and the startup information of the network node indicated by the identity identifier stored in the global data structure has been obtained by the management node; if the first identity identifier is not stored in the global data structure, it is determined that the startup information of the first network node has not been obtained.

[0013] Therefore, this application determines whether it is necessary to obtain the startup information of the first network node by obtaining the node identity identifier, thereby avoiding the repeated acquisition of the startup information of the corresponding node and improving the efficiency of the management node in aggregating the startup information of nodes in the entire cluster.

[0014] In one possible implementation, obtaining the startup information of the first sub-cluster includes:

[0015] Send a cluster identifier acquisition request to the first network node, the cluster identifier acquisition request being used to request the acquisition of the identifier of the first sub-cluster; receive a first cluster identifier sent by the first network node, the first cluster identifier being the identifier of the first sub-cluster; if it is determined based on the first cluster identifier that the startup information of the first sub-cluster has not been acquired, then acquire the startup information of the first sub-cluster from the first network node.

[0016] In one possible implementation, determining that the startup information of the first sub-cluster has not been obtained based on the first cluster identifier includes:

[0017] Obtain a global data structure, which is used to store the identifiers of the sub-clusters corresponding to each of the top-level network nodes, and the startup information of the sub-clusters indicated by the cluster identifiers stored in the global data structure has been obtained by the management node; if the first cluster identifier is not stored in the global data structure, it is determined that the startup information of the first sub-cluster has not been obtained.

[0018] Therefore, this application determines whether it is necessary to obtain the startup information of the sub-cluster corresponding to the first network node by obtaining the identifier of the sub-cluster, thereby avoiding the repeated acquisition of the startup information of the sub-cluster and improving the efficiency of the management node in aggregating the startup information of the nodes in the entire cluster.

[0019] In one possible implementation, the plurality of network nodes are divided into two layers according to the network topology, the first network node is connected to the second network node, the second network node refers to the network node located at the bottom layer of the two layers, and the second network node is connected to at least one of the plurality of processing nodes.

[0020] The startup information of the first sub-cluster includes the startup information of the second network node and the startup information of the second sub-cluster. The second sub-cluster is the sub-cluster corresponding to the second network node and includes all processing nodes connected to the second network node. The startup information of the second sub-cluster indicates the trusted startup status of all nodes in the second sub-cluster.

[0021] In one possible implementation, the first network node obtains the startup information of the second network node in the same way that the management node obtains the startup information of the first network node.

[0022] In one possible implementation, the startup information of the second sub-cluster is obtained from the second network node;

[0023] The method by which the first network node obtains the startup information of the second sub-cluster from the second network node is the same as the method by which the management node obtains the startup information of the first sub-cluster from the first network node.

[0024] Therefore, the top-level first network node collects startup information from downstream nodes by acquiring startup information layer by layer downwards. This involves obtaining startup information from directly connected downstream nodes, or from both the startup information of the downstream node and the startup information of the sub-cluster. In other words, when implementing the technical solution provided in this application, each network node within the cluster acquires startup information from its directly connected nodes. This allows the startup information of the underlying processing nodes to be aggregated upwards to the management node layer by layer as sub-cluster startup information, achieving distributed collection of startup information and improving the efficiency of the management node in collecting startup information from all nodes within the cluster.

[0025] In one possible implementation, the node's startup information includes the node certificate, the node certificate chain, and a metric report;

[0026] The node certificate is used to identify the identity of the corresponding node, the node certificate chain is used to verify whether the corresponding node is a trusted node, and the metric report is used to evaluate the security of the corresponding node.

[0027] It should be noted that, regardless of whether the startup information of a single node is obtained or the startup information of a sub-cluster is obtained, the essence of the technical solution of this application is that the management node needs to aggregate the startup information of all nodes in the cluster. Therefore, for any node (network node or processing node), its startup information includes node certificate, node certificate chain and metric report.

[0028] Secondly, a cluster trust verification device is provided, which has the function of implementing the cluster trust verification method behavior described in the first aspect above. The cluster trust verification device includes at least one module for implementing the cluster trust verification method provided in the first aspect above.

[0029] Thirdly, a computer device is provided, the computer device including a processor and a memory; the memory is used to store a computer program for executing the cluster trusted verification method provided in the first aspect; the processor is configured to execute the computer program stored in the memory to implement the cluster trusted verification method described in the first aspect.

[0030] In one possible implementation, the computer device may further include a communication bus for establishing a connection between the processor and the memory.

[0031] Fourthly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the steps of the cluster trusted verification method described in the first aspect.

[0032] Fifthly, a computer program product comprising instructions is provided, which, when executed on a computer, causes the computer to perform the steps of the cluster trusted verification method described in the first aspect. Alternatively, a computer program is provided that, when executed on a computer, causes the computer to perform the steps of the cluster trusted verification method described in the first aspect.

[0033] The technical effects achieved by the second, third, fourth, and fifth aspects mentioned above are similar to those achieved by the corresponding technical means in the first aspect, and will not be repeated here. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of a sub-cluster centered on a switch, provided in an embodiment of this application;

[0035] Figure 2 This is a schematic diagram of a trusted startup process provided in an embodiment of this application;

[0036] Figure 3This is a schematic diagram of the trusted boot process for a multi-card supernode on a single machine in related technologies;

[0037] Figure 4 This is a flowchart illustrating a cluster trust verification method provided in an embodiment of this application;

[0038] Figure 5 This is a schematic diagram of the structure of a cluster trusted verification device provided in an embodiment of this application;

[0039] Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0040] Figure 7 This is a schematic diagram of the structure of a network device provided in an embodiment of this application. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0042] To facilitate understanding, before explaining the vector retrieval method provided in this application, the terminology, relevant background, and implementation environment involved in the embodiments of this application will be introduced first.

[0043] First, the relevant terms used in the embodiments of this application will be introduced.

[0044] 1. Equipment Certificate

[0045] A device certificate is a digital certificate used to verify the identity and security of a device. For a given device, a device certificate typically contains information such as the device's public key, the certificate authority's signature, and the validity period, and is used to establish trust relationships when the device communicates with other systems or networks.

[0046] The role of equipment certificates typically includes the following three aspects:

[0047] (1) Authentication: Prove the identity and ownership of the device to prevent counterfeit devices from accessing the network.

[0048] (2) Encrypted communication: Encrypted communication is performed using the public key in the certificate to ensure the security of data transmission.

[0049] (3) Integrity verification: Verify the integrity and trustworthiness of the device through the certificate chain to prevent the device from being tampered with or implanted with malicious software.

[0050] In practical applications, device certificates are widely used in various scenarios requiring high security, such as the Internet of Things (IoT), industrial automation, and cybersecurity. Furthermore, in power systems, device certificates are also used in secondary security protection systems to ensure the signing and encryption of remote communication entities and data during communication.

[0051] 2. Measurement Report

[0052] A metrics report is a report generated after performing metric analysis on a device or system to assess its status, performance, or security. Metric reports typically include a series of metrics, data analysis, and evaluation results.

[0053] The role of measurement reports typically includes the following three aspects:

[0054] (1) Status monitoring: Real-time monitoring of the equipment's operating status and performance indicators to promptly identify potential problems.

[0055] (2) Security assessment: Assess the security of the device, including whether there are vulnerabilities or whether it has been tampered with.

[0056] (3) Decision support: Provide data support and decision-making basis for equipment maintenance, upgrade or replacement.

[0057] In one possible implementation, the generation of a metric report typically involves the following steps:

[0058] (1) Data acquisition: Collect information such as equipment operation data, performance indicators and safety logs.

[0059] (2) Measurement and analysis: Process and analyze the collected data, calculate the measurement indicators and evaluate the status and safety of the equipment.

[0060] (3) Report generation: Organize the analysis results into a report, including charts, data and evaluation conclusions.

[0061] 3. Certificate Chain

[0062] A certificate chain (also known as a certificate path or certificate hierarchy) is a sequence of multiple digital certificates with explicit parent-child relationships between them. A certificate chain typically begins with a device's certificate, passes through a series of intermediate certificates, and ultimately connects to the certificate of the root certificate authority.

[0063] The role of a certificate chain typically includes the following three aspects:

[0064] (1) Trust transfer: Through the trust transfer mechanism in the certificate chain, it is ensured that the device's certificate can be trusted by trusted parties (such as browsers, operating systems, etc.).

[0065] (2) Preventing tampering: Each certificate is issued and signed by its superior certificate. Any tampering will destroy the integrity of the certificate chain and will be detected.

[0066] (3) Authentication: Verify the identity and ownership of the device to ensure that the device is legitimate and trustworthy.

[0067] In one possible implementation, the certificate chain verification process typically involves the following steps:

[0068] (1) Obtain the certificate chain: Obtain the certificate chain from the device, including the device certificate, intermediate certificates and root certificate.

[0069] (2) Step-by-step verification: Starting from the device certificate, verify the signature and validity of each certificate step by step.

[0070] (3) Trusted root verification: Finally verify whether the root certificate was issued by a trusted root certificate authority.

[0071] 4. Sub-cluster

[0072] For a cluster consisting of multiple processing nodes (such as compute nodes, storage nodes, etc.), if multiple network nodes (such as switches) are networked together to enable communication between the multiple processing nodes, then each downstream node directly connected to a switch (referred to as a direct connection) is considered as a minimal sub-cluster.

[0073] See Figure 1 Multiple switches within the cluster are interconnected using a two-layer network topology. Dashed boxes 1 and 2 each represent a sub-cluster. Dashed box 1 is the sub-cluster corresponding to Switch-23, and dashed box 2 is the sub-cluster corresponding to Switch-17.

[0074] It should be noted that in this embodiment, only the example of a sub-cluster including multiple downstream nodes directly connected to the switch is used for illustration. Of course, for a switch, its corresponding sub-cluster can also include itself, for example... Figure 1 The sub-cluster corresponding to Switch-23 can include Switch-23 itself, as well as multiple Switches directly connected to Switch-23; for example Figure 1 The sub-cluster corresponding to Switch-17 may include Switch-17 itself and six compute nodes directly connected to Switch-17. This application embodiment does not limit this. It should be understood that the technical solution of this application embodiment is also applicable to the case where the sub-cluster corresponding to Switch includes itself, and its specific implementation is described in detail in the following method embodiment.

[0075] 5. Downstream Clusters

[0076] See also Figure 1 From the perspective of Switch-23 within dashed box 1, the sub-cluster within dashed box 2 is the downstream cluster of Switch-23.

[0077] Secondly, the relevant background of the embodiments of this application will be introduced.

[0078] In today's information-driven environment, device hardware and firmware have become key targets for hackers and malicious attackers. Firmware, embedded in hardware devices, is responsible for controlling the hardware's basic functions and behavior. Because firmware runs at the hardware level, it typically possesses the highest privileges within the system. This means that once the firmware is maliciously modified, attackers can bypass traditional security controls (such as operating system-level security mechanisms) and gain complete control of the device. This attack method offers extremely high stealth and persistence. Stealth lies in the fact that, because firmware resides at the hardware layer, traditional security software may be unable to effectively detect or prevent firmware-level attacks. Persistence is demonstrated by the fact that even if the system is rebooted or the operating system is reinstalled, the modified firmware remains active, continuing to provide backdoors or execute malicious operations for attackers.

[0079] In response to the aforementioned attack methods, and to safeguard the security of device hardware and firmware, trusted boot technology is employed during device startup to measure and verify the security of various critical components within the device (including firmware, basic input / output system (BIOS) or unified extensible firmware interface (UEFI), operating system loader, etc.). The system will only continue to complete the boot process after confirming that all critical components have not been tampered with.

[0080] Trusted boot, a technology that ensures a system is secure from startup, utilizes a trusted platform module (TPM) to protect against attacks targeting device hardware and firmware. The TPM is a chip installed inside the computer that provides a root of trust. Its core function is to manage and protect encryption keys through a dedicated microcontroller (also known as security hardware) integrated within the device. In other words, the TPM provides physical security and encryption capabilities, storing and verifying keys and measuring the integrity of other critical components.

[0081] For TPMs integrated within the device, see [link / reference]. Figure 2The trusted boot process of a device relies on a core root of trust for measurement (CRTM), a trusted computing security chip (such as a TPM), and a series of measurement and verification mechanisms. The entire trusted boot process includes the following steps:

[0082] (1) CRTM startup.

[0083] CRTM is typically a piece of code embedded in a hardware device, such as the read-only memory (ROM) of the central processing unit (CPU), the extensible firmware interface (EFI), or part of the BIOS. CRTM serves as the starting point for the measurement process, and its integrity is verified by a public key embedded in the chip. This public key is embedded by the device manufacturer during the manufacturing process, ensuring the originality and tamper-proof nature of the CRTM.

[0084] (2) CRTM measures BIOS.

[0085] After CRTM starts, it first reads the BIOS code or image and measures the BIOS by calculating its hash value, which represents the current integrity state of the BIOS. Then, CRTM extends the calculated BIOS hash value into TPM and records the measurement events (including the BIOS hash value) in the TPM's measurement log for subsequent auditing and verification. Once the BIOS hash value is securely stored, CRTM jumps to the BIOS to begin execution.

[0086] (3) The BIOS measures subsequent modules.

[0087] After the BIOS boots up, it performs the same measurement process on subsequent modules (such as the operating system loader and operating system kernel). Before loading each module, a hash value is calculated, expanded into the TPM, and recorded in the measurement log. Only after the hash value verification is successful will the module be loaded and executed.

[0088] Through the above measurement and verification process, the system constructs a complete trust chain from CRTM to BIOS, and then to all subsequent key modules. Each module depends on the verification results of the previous module, thereby ensuring the trustworthiness of the entire system startup process.

[0089] (4) Generate a metric report and perform remote verification.

[0090] After trusted boot is complete, TPM generates an immutable metrics report containing the hash values ​​of all critical modules during the boot process and other relevant information. This metrics report can be remotely verified by a verification device (e.g., an administrator's device) to confirm the device's trusted status.

[0091] With the rapid development of artificial intelligence and big data technologies, the application of large models (such as deep learning models) is becoming increasingly widespread. These large models typically require substantial computing resources for training and inference. Therefore, the industry has begun to actively explore the construction of large-scale computing clusters to run and train even larger-scale models. This trend has spurred a series of cluster architectures based on high-speed buses, designed to efficiently connect numerous computing devices to form supercomputing nodes, such as NVLink clusters, Compute Express Link (CXL) clusters, and UA Link clusters.

[0092] NVLink is a high-speed, low-latency interconnect technology developed by NVIDIA, designed specifically for data exchange between graphics processing units (GPUs). NVLink supports high-speed data transfer and shared memory access, significantly improving the performance of computing clusters. CXL is a new high-speed interconnect standard designed to provide high-speed, low-latency data transfer between CPUs and accelerators (such as GPUs and neural processing units, NPUs). CXL supports memory sharing and cache coherency, enabling CPUs and accelerators to work together more efficiently. UA Link is another high-speed interconnect technology used to connect different types of computing devices, designed to improve the performance and scalability of computing clusters.

[0093] With the continuous advancement of computing technology, the size of supernodes in computing clusters is also constantly increasing. For example, a powerful computing node can be formed by containing 576 B200 GPUs. In addition to the increasing size of supernodes, the number of devices in computing clusters is also constantly increasing. Currently, computing clusters containing thousands of GPUs have emerged, and in the future, supercomputing clusters containing tens of thousands of GPUs may even appear. With the increasing size of computing clusters and the increase in the number of devices, cluster-level trusted boot and remote verification become particularly important.

[0094] For supernodes, relevant technologies present a trusted boot and metric report aggregation scheme for multi-GPU supernodes on a single machine. See [link / reference]. Figure 3For a multi-GPU supernode (e.g., 1 CPU + 8 GPUs), the trusted boot process can be as follows: Upon power-up, all components (CPU and GPUs) first enter the boot process. During boot, each component checks the integrity and authenticity of its firmware (e.g., BIOS / UEFI, GPU firmware) to ensure it hasn't been maliciously tampered with. Each component generates a metric report during boot, which typically contains hash values ​​of key stages (e.g., firmware code hashes) to verify the integrity and authenticity of these stages. The CPU, as the main control unit, sequentially collects the metric reports from each GPU via a communication mechanism (e.g., the high-speed serial computer expansion bus standard (Peripheral Component Interconnect Express, PCIe)) to obtain boot status information for all GPUs, thus gaining a comprehensive understanding of the entire system's boot process.

[0095] After collecting all GPU metric reports, the CPU can choose from two main schemes to process these reports for remote verification.

[0096] Option 1: The CPU sends the measurement reports of each GPU to the remote verification server in sequence. The verification server will verify these reports one by one to confirm their integrity and validity.

[0097] This approach allows the server to independently review the metrics reports for each GPU in detail, facilitating problem tracking and localization. However, sending metrics reports sequentially can require more network transmission and server processing time, especially when there are a large number of GPUs.

[0098] Option 2: The CPU simply combines the measurement reports from all GPUs into a single large report and sends it to the remote verification server. Upon receiving the report, the verification server parses the combined report and verifies the measurements for each GPU.

[0099] This approach reduces the number of network transmissions and server request processing times, potentially improving verification efficiency. However, if a metric report for a particular GPU has a problem, the entire combined report may need to be resent, increasing the complexity of diagnosing the issue.

[0100] In summary, when faced with a large number of devices within a computing cluster, how to quickly and effectively collect measurement reports from these devices for remote verification servers to perform trusted verification has become a pressing technical problem.

[0101] To address the aforementioned technical problems, this application provides a cluster-level trusted verification scheme. The cluster includes multiple network nodes and multiple processing nodes. The multiple network nodes are used to establish communication connections between the multiple processing nodes, and the multiple network nodes are divided into at least one layer according to the network topology. The technical solution of this application is executed by the cluster management node. The management node obtains the startup information of the first network node and the startup information of the first sub-cluster. Based on the startup information of the first network node and the startup information of the first sub-cluster, it generates cluster startup information. This cluster startup information is used by the verification device to verify the trusted startup status of all nodes within the cluster. The first network node refers to any network node located at the top layer and connected to the management node in at least one layer. The startup information of the first network node indicates the trusted startup status of the first network node. The first sub-cluster is the sub-cluster corresponding to the first network node. The first sub-cluster includes all downstream nodes connected to the first network node. The downstream nodes include processing nodes, or the downstream nodes include both network nodes and processing nodes. The startup information of the first sub-cluster indicates the trusted startup status of all nodes within the first sub-cluster.

[0102] Therefore, in the technical solution of this application, the management node is directly connected to the top-level network node, and the top-level network node is connected to the downstream sub-cluster nodes. Based on this communication connection, the management node only needs to communicate with the top-level network node to collect the cluster startup information of the entire cluster, which greatly simplifies the communication link. At the same time, the top-level network node, as the information aggregation point, is responsible for collecting the startup information of all downstream nodes connected to it and transmitting the startup information of all downstream nodes to the management node. This realizes the distributed collection of startup information, avoids single point bottlenecks and failure risks, and also avoids the management node collecting the startup information of each downstream node one by one. This greatly reduces the time overhead of collecting the startup information of the entire cluster, improves the efficiency of the management node in collecting the startup information of all nodes in the cluster, and thus improves the efficiency of the verification device in verifying the trusted startup status of the cluster.

[0103] When there are multiple top-level network nodes, these nodes can collect startup information from their respective connected downstream nodes in parallel. This method of multiple top-level network nodes collecting startup information in parallel significantly improves the speed of startup information collection across the entire cluster, with even more pronounced effects in large clusters. Moreover, regardless of the cluster size or the number of processing nodes, the management node can quickly collect startup information for the entire cluster using only a small number of top-level network nodes.

[0104] As the cluster size increases, implementing the technical solution of this application only requires increasing the number of top-level network nodes or enhancing their processing capabilities to easily collect startup information throughout the entire cluster. Therefore, the information collection architecture provided by this application gives the entire cluster excellent scalability. When the network topology of the cluster changes (e.g., adding or removing network nodes), only the connection relationship between the top-level network nodes and downstream network nodes needs to be adjusted to quickly adapt to the new cluster environment without requiring large-scale modifications to the management nodes, thus offering greater flexibility. Furthermore, the information aggregation and verification through the top-level network nodes also enhances the reliability and security of startup information for nodes within the cluster.

[0105] In summary, the technical solution of this application achieves efficient collection and management of the trusted startup status of all nodes in the cluster by optimizing the architecture design, improving information collection efficiency, enhancing scalability and flexibility, and improving reliability and security. This allows the verification device to verify the trusted startup status of the entire cluster through the cluster startup information provided by the management node. This not only reduces the system's maintenance costs and management complexity but also improves the overall operating efficiency and security of the cluster, providing strong support for the trusted management and maintenance of large-scale distributed systems.

[0106] Finally, the implementation environment of the embodiments of this application will be described.

[0107] The cluster trust verification method provided in this application embodiment is applicable to any cluster and utilizes multiple network nodes within the cluster to collect startup information, thereby aggregating the cluster startup information of the entire cluster.

[0108] The network topology of multiple network nodes in the cluster can be Figure 1 The fat tree network shown can also be a dragonfly network or a torus network. This application embodiment does not limit the networking method of multiple network nodes.

[0109] for Figure 1 The fat tree network shown has a multi-layered network topology. Therefore, when implementing the technical solution of this application, the management node obtains the startup information of the top-level network node and the startup information of the sub-cluster corresponding to the top-level network node from the directly connected top-level network node. The top-level network node then collects the startup information of its directly connected downstream nodes, and so on, so that the startup information of all processing nodes at the bottom layer of the cluster, as well as the startup information of all network nodes, can be aggregated upwards to the management node.

[0110] It should be noted that for other non-hierarchical networks, such as Dragonfly and Torus networks, when implementing the technical solution of this application based on these network architectures, it is necessary to first determine the "logical topology" of these network architectures based on the connection relationships of multiple network nodes. In this logical topology, multiple network nodes are connected in a manner similar to a fat-tree network. In other words, when implementing the technical solution of this application in a non-hierarchical network, it is necessary to first divide the multiple network nodes into at least one layer according to the network topology based on their connection relationships, and then, based on this hierarchical structure, control each network node to collect startup information from directly connected nodes according to the technical solution of this application.

[0111] Taking the Dragonfly network as an example, the topology of the Dragonfly network is divided into three layers: the routing (Switch or Router) layer, the group layer, and the system layer. The switch layer includes a switch and p connected computing nodes; the group layer contains a switch layers, and the a switches in these a switch layers are fully connected (all-to-all), that is, each switch has a-1 links connected to the other a-1 switches; the system layer contains g group layers, and these g group layers are also fully connected.

[0112] When implementing the technical solution of this application based on the Dragonfly network, several groups can be designated as top-level network nodes within the Dragonfly network. During system startup, each of these designated groups performs a trusted startup and collects startup information from multiple switches it contains, as well as startup information from multiple compute nodes connected to those switches (i.e., startup information of the sub-cluster corresponding to that switch). Furthermore, since the groups are fully connected, these designated groups also collect startup information collected by other undesignated groups. Thus, the management node can ultimately obtain the entire cluster startup information from the designated groups.

[0113] Taking the Torus network as an example, a Torus network is represented using an N-dimensional grid. Communication between computing nodes in a Torus network is achieved by establishing direct connections between adjacent computing nodes in each dimension (D). For instance, in a one-dimensional Torus network (1D Torus), each computing node is connected to its two preceding and following adjacent computing nodes; in a two-dimensional Torus network (2D Torus), each computing node is connected to its four adjacent computing nodes above, below, left, and right; and in a three-dimensional Torus network (3D Torus), each computing node is connected to its six adjacent computing nodes above, below, above, left, and right. Because the Torus network is a network topology with node symmetry, its multi-node networking method can be uniquely determined once the dimensions of the Torus network and the number of nodes in each dimension are determined.

[0114] When implementing the technical solution of this application based on a Torus network, assuming it is a 3D Torus network, with the coordinates of each computing node being (x, y, z), it can be divided into 3 levels according to the dimensions. All computing nodes with x=0 collect the startup information of each computing node in sequence along the X direction. All computing nodes with x=0 and y=0 collect the startup information of each computing node in sequence along the Y direction. All computing nodes with x=0, y=0 and z=0 serve as the top-level network node, which aggregates the startup information collected by all computing nodes connected to it and feeds it back to the management node.

[0115] It should be noted that the embodiments of this application only use Dragonfly network and Torus network as examples. In practical applications, other network structures can also be divided into layers in the same way as described above to implement the technical solution provided in this application. The implementation logic is similar, so they will not be described one by one here.

[0116] It should be understood that the network topology and cluster architecture described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network topology and the emergence of new cluster architectures, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0117] After introducing the terminology, relevant background, and implementation environment of the embodiments of this application, the cluster trusted startup method provided by the embodiments of this application will be explained in detail below with reference to the accompanying drawings.

[0118] Figure 4This is a flowchart illustrating a cluster trusted startup method provided in an embodiment of this application. The method is applied to the management node of the cluster. As described above, the cluster includes multiple network nodes and multiple processing nodes. The network nodes are used to implement communication connections between the processing nodes, and the network nodes are divided into at least one layer according to the network topology. Please refer to... Figure 4 The method includes the following steps:

[0119] Step 401: Obtain the startup information of the first network node. The first network node refers to any network node located at the top layer and connected to the management node in at least one layer. The startup information of the first network node indicates the trusted startup status of the first network node.

[0120] In the cluster to which the technical solution of this application is adapted, multiple network nodes are divided into at least one layer according to the network topology. Based on this hierarchical structure, the management node communicates with the first network node located at the top layer. Therefore, the management node can directly obtain startup information from each first network node through the communication link.

[0121] It should be noted that the embodiments of this application do not limit the number of first network nodes. Based on different network topologies and partitioning methods, the first network node that communicates with the management node can be one or more.

[0122] In one possible implementation, the startup information of the first network node refers to the first network node itself following a trusted startup process (see above). Figure 2 Information generated during the startup process. For example, the startup information of the first network node includes the node certificate, node certificate chain, and measurement report of the first network node. Refer to the explanation of device certificate, certificate chain, and measurement report in the previous terminology introduction. In the technical solution of this application, the node certificate is used to identify the identity of the first network node, the node certificate chain is used to verify whether the first network node is a trusted node, and the measurement report is used to evaluate the security of the first network node.

[0123] It should be noted that, regardless of whether the startup information of a single node is obtained or the startup information of a sub-cluster is obtained, the essence of the technical solution of this application lies in the fact that the management node needs to aggregate the startup information of all nodes in the cluster. Therefore, in the embodiments of this application, for any node (network node or processing node), the startup information of the node includes a node certificate, a node certificate chain, and a measurement report. The node certificate is used to identify the identity of the corresponding node, the node certificate chain is used to verify whether the corresponding node is a trusted node, and the measurement report is used to evaluate the security of the corresponding node.

[0124] In some embodiments, considering that trusted startup and verification of the cluster may be performed when the cluster is first started, or may be performed intermittently based on a detection period set by the administrator, that is, trusted startup and verification of the cluster may be triggered at irregular intervals. Therefore, when the management node performs the above step 401, it can first determine whether the startup information of the first network node has been collected. If the startup information of the first network node has been collected, step 401 is skipped.

[0125] In one possible implementation, the above step 401 can be implemented as follows: the management node sends a node identifier acquisition request to the first network node, the node identifier acquisition request being used to request the acquisition of the identity identifier of the first network node; receives the first identity identifier sent by the first network node, the first identity identifier being the identity identifier of the first network node; if it is determined based on the first identity identifier that the startup information of the first network node has not been acquired, then the startup information of the first network node is acquired.

[0126] As an example, the identity identifier of the first network node can be the public key certificate of the first network node (i.e., the public key in the node certificate). Of course, the identity identifier of the first network node can also be other information that can uniquely identify a node, and the specific content is not limited in the embodiments of this application.

[0127] In other words, before obtaining the complete node certificate, node certificate chain, and metric report (i.e., the startup information of the first network node) of the first network node, the management node first obtains the public key certificate of the first network node, so as to determine whether the startup information of the first network node has been collected based on the public key certificate.

[0128] In one possible implementation, the process by which the management node determines whether to obtain the startup information of the first network node based on the first identity identifier can be as follows: obtain a global data structure, which is used to store the identity identifiers of multiple network nodes, and the startup information of the network node indicated by the identity identifier stored in the global data structure has been obtained by the management node; if the first identity identifier is not stored in the global data structure, it is determined that the startup information of the first network node has not been obtained.

[0129] The global data structure can be stored in the management node or in other devices that can communicate with the management node, such as in a separate database. This application embodiment does not impose any restrictions on this.

[0130] Taking the example of storing the global data structure in the management node, after the management node interacts with the first network node and obtains the first identity identifier sent by the first network node, it can query whether the first identity identifier exists in its own stored global data structure to determine whether it needs to obtain the startup information of the first network node. If the first identity identifier is not stored in the global data structure, it means that the management node has not obtained the startup information of the first network node before, so it needs to obtain the startup information of the first network node at this time.

[0131] Furthermore, after obtaining the startup information of the first network node, the management node also needs to update the aforementioned global data structure based on the startup information of the first network node, so as to enter the first identity identifier of the first network node into the global data structure.

[0132] In some embodiments, after the management node has collected the startup information of all nodes in the cluster, the global data structure it constructs stores the identity identifiers of all nodes in the cluster, as well as the startup information corresponding to each node.

[0133] As an example, the global data structure maintained by the management node can be represented by either Table 1 or Table 2 below.

[0134] Table 1

[0135] Node identity identifier Node type Node Certificate Chain Node metric report xxx Network Nodes a1-a2-a3 Report 1 …… …… …… …… yyy Processing Nodes b1-b2-b3 Report 2

[0136] The node type is optional; it can be retained in the global data structure or not, and this application embodiment does not impose any restrictions on this. Considering that the management node in this application embodiment acts as the aggregator of startup information within the cluster, it needs to obtain startup information from all nodes in the cluster. However, the nodes in the cluster include two types: network nodes and processing nodes. Therefore, the "node type" item can be used in the global data structure to distinguish the nodes in the cluster.

[0137] Table 2

[0138] Node identity identifier Node type Certificate Chain Identifier Measurement report identifier xxx Network Nodes Identifier a Identifier c …… …… …… …… yyy Processing Nodes Identifier b Identifier d

[0139] The certificate chain identifier can be the hash value of the corresponding certificate chain, and the measurement report identifier can be the hash value of the corresponding measurement report.

[0140] As can be seen, Table 1 directly stores the startup information of each node in the cluster, while Table 2 does not directly store the startup information of each node in the cluster, but stores the relevant identifiers of the startup information of each node, which are used as indexes for querying specific information. Therefore, Table 2 is more efficient for querying relevant information than Table 1.

[0141] It should be understood that, even if the global data structure only stores the certificate chain identifier and the measurement report identifier, the management node still needs to use other data structures to store the certificate chain and measurement report, so as to obtain the complete node certificate chain and measurement report from other data structures based on the certificate chain identifier and measurement report identifier in the global data structure.

[0142] In one possible implementation, the management node also maintains a first data structure and a second data structure. The first data structure stores the certificate chain identifier and the complete certificate chain, and the second data structure stores the metric report identifier and the complete metric report.

[0143] As an example, the first data structure can be represented by Table 3 below, and the second data structure can be represented by Table 4 below.

[0144] Table 3

[0145] Certificate Chain Identifier Certificate Chain Identifier a a1-a2-a3 …… …… Identifier b b1-b2-b3

[0146] Table 4

[0147] Measurement report identifier Node metric report Identifier c Report 1 …… …… Identifier d Report 2

[0148] Therefore, this embodiment of the application obtains the node identity identifier to determine whether it is necessary to obtain the startup information of the first network node, thereby avoiding the repeated acquisition of the startup information of the corresponding node and improving the efficiency of the management node in aggregating the startup information of nodes in the entire cluster.

[0149] Step 402: Obtain the startup information of the first sub-cluster. The first sub-cluster is the sub-cluster corresponding to the first network node. The first sub-cluster includes all downstream nodes connected to the first network node. The downstream nodes include processing nodes, or the downstream nodes include network nodes and processing nodes. The startup information of the first sub-cluster indicates the trusted startup status of all nodes in the first sub-cluster, and the startup information of the first sub-cluster is collected by the first network node.

[0150] In other words, after the first network node has collected the startup information of all connected downstream nodes, the management node can obtain the startup information of all other nodes in the cluster, excluding the first network node, from the first network node. For the first network node, the startup information of its corresponding sub-cluster includes the startup information of all nodes within that sub-cluster. In other words, the startup information of the sub-cluster corresponding to the first network node includes the startup information of all downstream nodes connected to the first network node.

[0151] Similarly, when the management node obtains the startup information of the first sub-cluster, it can first determine whether the startup information of the first sub-cluster has been collected. If the startup information of the first sub-cluster has been collected, then step 402 is skipped.

[0152] In one possible implementation, step 402 above can be implemented as follows: the management node sends a cluster identifier acquisition request to the first network node, the cluster identifier acquisition request being used to request the acquisition of the identifier of the first sub-cluster; receives the first cluster identifier sent by the first network node, the first cluster identifier being the identifier of the first sub-cluster; if it is determined based on the first cluster identifier that the startup information of the first sub-cluster has not been acquired, then the startup information of the first sub-cluster is acquired from the first network node.

[0153] In other words, before obtaining the startup information of the downstream nodes from the first network node, the management node first obtains the identifier of the first sub-cluster corresponding to the first network node (i.e., the first cluster identifier) ​​to determine whether the startup information of the first sub-cluster has been collected based on the first cluster identifier.

[0154] In one possible implementation, the process by which the management node determines whether it has obtained the startup information of the first sub-cluster based on the first cluster identifier can be as follows: obtain a global data structure, which is used to store the identifiers of the sub-clusters corresponding to each network node at the top level, and the startup information of the sub-clusters indicated by the cluster identifiers stored in the global data structure has been obtained by the management node; if the first cluster identifier is not stored in the global data structure, it is determined that the startup information of the first sub-cluster has not been obtained.

[0155] Similarly, the global database can be stored in the management node or in other devices that can communicate with the management node, such as in a separate database. This application embodiment does not impose any restrictions on this.

[0156] Based on Table 2 above, as an example, the global data structure in this application embodiment can be shown in Table 5 below.

[0157] Table 5

[0158] Node identity identifier Node type Certificate Chain Identifier Measurement report identifier Sub-cluster identifier xxx Network Nodes Identifier a Identifier c Identifier e …… …… …… …… …… yyy Processing Nodes Identifier b Identifier d none

[0159] The identifier of a sub-cluster can be a hash value of the network topology of that sub-cluster.

[0160] It should be noted that the "sub-cluster" in this application embodiment only refers to network nodes. That is, only network nodes have corresponding sub-clusters. For processing nodes, they must belong to a sub-cluster of a certain network node. Therefore, processing nodes do not have corresponding sub-clusters or sub-cluster identifiers.

[0161] Therefore, this embodiment of the application obtains the identifier of the sub-cluster to determine whether it is necessary to obtain the startup information of the sub-cluster corresponding to the first network node, thereby avoiding the repeated acquisition of the startup information of the sub-cluster and improving the efficiency of the management node in aggregating the startup information of the nodes in the entire cluster.

[0162] It should also be noted that the execution order of steps 401 and 402 in this embodiment is not limited. Step 401 can be executed first and then step 402, or step 402 can be executed first and then step 401. Of course, when resources are sufficient, the management node can also obtain the startup information of the first network node itself and the startup information of the first sub-cluster corresponding to the first network node from the first network node, that is, execute steps 401 and 402 simultaneously.

[0163] As described above, the management node can obtain the startup information of the top-level first network node from the directly connected top-level network node. The first network node collects the startup information of all its connected downstream nodes, allowing the management node to also obtain the startup information of the sub-cluster corresponding to the top-level network node from the first network node. However, when multiple network nodes within the cluster are divided into multiple layers according to the network topology, the top-level first network node will obtain the startup information of its downstream nodes. The following section describes the implementation process of the first network node obtaining the startup information of its downstream nodes.

[0164] In some embodiments, multiple network nodes are divided into two layers according to the network topology. A first network node is connected to a second network node, which is the network node located at the bottom layer and is connected to at least one of the multiple processing nodes. Based on this, the startup information of the first sub-cluster includes the startup information of the second network node and the startup information of the second sub-cluster. The second sub-cluster is the sub-cluster corresponding to the second network node and includes all processing nodes connected to the second network node. The startup information of the second sub-cluster indicates the trusted startup status of all nodes within the second sub-cluster.

[0165] That is, when the first network node is connected to the second network node, and the second network node is connected to the processing node, the process by which the first network node collects the startup information of the first sub-cluster is as follows: the first network node obtains the startup information of the second network node and the startup information of the second sub-cluster from the second network node.

[0166] In one possible implementation, the first network node obtains the startup information of the second network node in the same way that the management node obtains the startup information of the first network node. The specific implementation process can be found in the relevant description under step 401, and will not be repeated here.

[0167] In one possible implementation, the startup information of the second sub-cluster is obtained from the second network node. The method by which the first network node obtains the startup information of the second sub-cluster from the second network node is the same as the method by which the management node obtains the startup information of the first sub-cluster from the first network node. The specific implementation process can be found in the relevant description under step 402, and will not be repeated here.

[0168] Therefore, the top-level first network node collects startup information from downstream nodes by acquiring startup information layer by layer downwards. This involves obtaining startup information from directly connected downstream nodes, or from both the startup information of the downstream node and the startup information of the sub-cluster. In other words, when implementing the technical solution provided in this application, each network node within the cluster acquires startup information from its directly connected nodes. This allows the startup information of the underlying processing nodes to be aggregated upwards to the management node layer by layer as sub-cluster startup information, achieving distributed collection of startup information and improving the efficiency of the management node in collecting startup information from all nodes within the cluster.

[0169] Step 403: Based on the startup information of the first network node and the startup information of the first sub-cluster, generate cluster startup information. The cluster startup information is used by the verification device to verify the trusted startup status of all nodes in the cluster.

[0170] After the management node collects the startup information of all nodes in the cluster through the first network node, it can obtain the cluster startup information. The management node can then send the cluster startup information to the verification device, enabling the verification device to verify the trusted startup status of the entire cluster based on the cluster startup information.

[0171] It should be noted that the embodiments of this application do not restrict the method by which the management node generates cluster startup information. The management node can directly use the startup information of the first network node and the startup information of the first sub-cluster as the cluster startup information. In this case, the cluster startup information includes the startup information of all nodes in the cluster. Alternatively, the management node can integrate and splice the startup information of the first network node and the startup information of the first sub-cluster to obtain the cluster startup information. In this case, the cluster startup information is a complete information / report.

[0172] Furthermore, regarding the implementation of the management node sending cluster startup information to the verification device, and the verification device verifying the trusted startup status of the entire cluster based on the cluster startup information, please refer to relevant technologies or the description of single-node trusted startup and verification, which will not be elaborated here.

[0173] In summary, in this embodiment, the management node is directly connected to the top-level network node, which in turn connects to the downstream sub-cluster nodes. Based on this communication connection, the management node only needs to communicate with the top-level network node to collect the cluster startup information of the entire cluster, greatly simplifying the communication link. Simultaneously, the top-level network node, as the information aggregation point, is responsible for collecting the startup information of all downstream nodes it connects to and transmitting this information to the management node. This achieves distributed collection of startup information, avoiding single-point bottlenecks and failure risks. It also avoids the management node collecting startup information from each downstream node individually, significantly reducing the time overhead of collecting startup information for the entire cluster. This improves the efficiency of the management node in collecting startup information from all nodes within the cluster, thereby increasing the efficiency of the verification device in verifying the trusted startup status of the cluster.

[0174] To facilitate understanding of the underlying implementation logic of the above method embodiments, the following will use... Figure 1 Using the cluster shown and the network topology of multiple network nodes (i.e., Switches) as an example, this application embodiment exemplifies the process of collecting startup information layer by layer downward from the Switch as the center, and the aggregation process of cluster startup information, in order to supplement the explanation of the implementation details of the above method embodiment.

[0175] First of all, for Figure 1 The cluster shown in this application is based on the following premise: all nodes in the cluster (including switches and compute nodes) have a root of trust and can autonomously execute a trusted startup process to generate metric values ​​after power-on; moreover, each switch in the cluster has pre-configured hierarchical information of the network topology (e.g., L1 layer switches, L2 layer switches, etc.) and knows the hierarchy of the nodes connected to its own ports (L0 layer compute nodes, L2 layer switches, etc.).

[0176] When collecting startup information layer by layer downwards from the Switch, all Switches in the cluster perform the following steps:

[0177] 1. Initialize the data structure and create 4 empty tables: Global Data List (Chart List), Measurement Report List (Measurement List), Certificate Chain List (Certificate Chain List), and Sub-Chart List (Sub Chart List).

[0178] 2. Collect startup information from downstream directly connected nodes. The implementation process includes:

[0179] 2-1. Verify the identity of the other party.

[0180] The switch sends a nonce (a one-time random number commonly used in encrypted communication) to the directly connected downstream nodes. After receiving the nonce, the downstream node signs the string {device type|nonce} with its own private key and sends the signature along with its own public key certificate to the switch. The switch verifies the signature and updates the chart list based on the downstream node's public key certificate.

[0181] 2-2. Verify the certificate chain.

[0182] Based on the public key certificate, search the Certificate Chain List to determine if there is a cached corresponding certificate chain. If not, request downstream nodes to return their own certificate chains and verify the certificate chains of downstream nodes in order to update the Certificate Chain List and Chart List.

[0183] 2-3. Obtain the measurement report.

[0184] The switch sends a nonce to its directly connected downstream nodes. Upon receiving the nonce, the downstream node calculates a measurement digest of its current state (e.g., BIOS, bootloader, operating system, etc.), signs the string {nonce, measurement digest} with its private key, and sends the signature, measurement digest, and any public key certificate (if not previously exchanged) to the switch. The switch verifies the signature and, based on the measurement digest, searches its local Measurement List to determine if a corresponding measurement report is cached. If no cached measurement report exists, the switch requests the complete measurement report (including more detailed component information or additional verification data) from the downstream node. Upon receiving the complete measurement report, the switch re-verifies the digest match and updates its Measurement List, adding the new measurement report to it.

[0185] 2-4. Update the Sub Chart List.

[0186] Update the Sub Chart List based on the device type of the downstream node.

[0187] 3. Repeat step 2 above until the startup information of all directly connected downstream nodes is collected.

[0188] As an example, with Figure 1 Taking Switch-11 in the L1 layer of the cluster as an example, after executing steps 1-3 above, the corresponding data structure is shown in Tables 6-9 below. Among them, Table 6 is the global data list (i.e., Chart List), Table 7 is the measurement report list (i.e., Measurement List), Table 8 is the certificate chain list (i.e., Certificate Chain List), and Table 9 is the sub-chart list (i.e., Sub Chart List).

[0189] Table 6

[0190] Public Key Certificate Node type Certificate Chain Identifier Measurement report identifier Sub-data list identifier aa1460 L0 layer computing nodes b98d8b 2aeb49 NA a431e9 L0 layer computing nodes b98d8b 2aeb49 NA 9303ce L0 layer computing nodes 75e9a9 f1596d NA

[0191] Specifically, when the downstream node is a compute node, the corresponding sub-data list is identified as NA; when the downstream node is a switch, the corresponding sub-data list is identified as NALL.

[0192] It should be understood that the Chart List here is one implementation of the "global data structure" in the above method embodiments, and the specific meaning of each indicator can also be found in the description in the above method embodiments. In practical applications, the global data structure or Chart List of each node may include more or less information, and this application embodiment does not impose any restrictions on this.

[0193] Table 7

[0194] Measurement report identifier Measurement Report 2aeb49 xxx f1596d xxx …… ……

[0195] Table 8

[0196] Certificate Chain Identifier Certificate Chain b98d8b xxx 75e9a9 xxx …… ……

[0197] Table 9

[0198] Sub-data list identifier Sub-data list

[0199] It should be noted that since the downstream nodes of Switch-11 are compute nodes, the Sub Chart List maintained in Switch-11 is empty after obtaining the startup information of all downstream nodes (as shown in Table 9). Furthermore, to simplify the data structure and improve information retrieval efficiency, the data structure maintained by Switch only stores unique data; that is, for homogeneous downstream nodes, only one copy of their startup information is stored.

[0200] When aggregating and generating the cluster startup information for the entire cluster, all switches within the cluster perform the following steps:

[0201] 1. Locate the entries in the Chart List whose node type is Ln layer network node (i.e., Ln Switch) and whose sub-data list identifier is NULL.

[0202] As an example, to Figure 1 Taking Switch-21 in the L2 layer of the cluster as an example, the downstream nodes directly connected to Switch-21 include Switch-11, and the public key certificate of Switch-11 is c0eb7a. At this time, the chart list of Switch-21 is shown in Table 10 below.

[0203] Table 10 (Chart List)

[0204] Public Key Certificate Node type Certificate Chain Identifier Measurement report identifier Sub-data list identifier c0eb7a L1 Switch f8184e 2039a8 NULL 89e611 L1 Switch f8184e 2039a8 NULL Fc85bb L1 Level Switch Point f8184e 2039a8 NULL

[0205] 2. Send a nonce to the directly connected downstream switch to request the chart digest of that downstream switch.

[0206] 3. After receiving the request, the downstream switch checks if there is a table entry in its own Chart List with node type LnSwitch and sub-data list identifier set to NULL.

[0207] If there is no corresponding entry in the Chart List, it means that the Chart List is complete. The Chart digest and the {nonce|chart digest} string signed with the private key are returned to the upstream Switch. If there is a corresponding entry in the Chart List, it means that the Chart List is not yet complete. The Chart digest is not returned to the upstream Switch, and the upstream Switch is made to wait.

[0208] 4. After receiving the Chart digest returned by the downstream node, the upstream Switch verifies the signature and checks its own ChartList to determine if there is a cached Chart digest.

[0209] If there is no cache, the Chart List, Certificate Chain List, Measurement List, and sub-chart digest need to be updated. The update process includes the following steps:

[0210] 4-1. Request the complete Chart List from the downstream Switch, verify whether the Chart summary matches, and update the ChartList and Sub Chart List.

[0211] 4-2. Check if the metric report identifiers of each node in the new Sub Chart List are cached. If not, request the metric report from the downstream Switch.

[0212] 4-3. Check if the certificate chain identifiers of each node in the new Sub Chart List are cached. If not, request the certificate chain from the downstream Switch.

[0213] 4-4. Check if the sub-data list identifiers of each node in the new Sub Chart List are cached. If not, request the sub-data list from the downstream Switch.

[0214] 4-5. Repeat steps 4-1 to 4-4 above for the sub-data lists of the downstream Switch until no more new Sub Chart Lists can be added.

[0215] 5. Repeat steps 1-4 above until there are no entries in the sub-data list marked as NUL in the upstream Switch.

[0216] Furthermore, once the startup information of all downstream nodes has been aggregated to the top-level switch, i.e., the L2 layer switch, the management node can obtain the startup information of the top-level switch and the startup information of the corresponding sub-cluster from the top-level switch. For details of the implementation process, please refer to the above method embodiment, which will not be repeated here.

[0217] Figure 5 This is a schematic diagram of a cluster trusted verification device provided in an embodiment of this application. The cluster trusted verification device can be implemented as part or all of a management node by software, hardware, or a combination of both. The management node can be as follows: Figure 6 The computer equipment shown. See also Figure 5 The cluster trust verification device includes: a node information acquisition module 501, a sub-cluster information acquisition module 502, and an information integration module 503.

[0218] The node information acquisition module 501 is used to acquire the startup information of the first network node. The first network node refers to any network node located at the top layer and connected to the management node in at least one layer. The startup information of the first network node indicates the trusted startup status of the first network node.

[0219] The sub-cluster information acquisition module 502 is used to acquire the startup information of the first sub-cluster. The first sub-cluster is the sub-cluster corresponding to the first network node. The first sub-cluster includes all downstream nodes connected to the first network node. The downstream nodes include processing nodes, or the downstream nodes include network nodes and processing nodes. The startup information of the first sub-cluster indicates the trusted startup status of all nodes in the first sub-cluster, and the startup information of the first sub-cluster is collected by the first network node.

[0220] The information integration module 503 is used to generate cluster startup information based on the startup information of the first network node and the startup information of the first sub-cluster. The cluster startup information is used by the verification device to verify the trusted startup status of all nodes in the cluster.

[0221] In one possible implementation, the node information acquisition module 501 includes:

[0222] The first request unit is used to send a node identifier acquisition request to the first network node. The node identifier acquisition request is used to request the acquisition of the identity identifier of the first network node.

[0223] The first receiving unit is configured to receive a first identity identifier sent by the first network node, wherein the first identity identifier is the identity identifier of the first network node.

[0224] The acquisition unit is used to acquire the startup information of the first network node if it is determined based on the first identity identifier that the startup information of the first network node has not been acquired.

[0225] In one possible implementation, the acquisition unit is also used for:

[0226] Obtain the global data structure, which is used to store the identity identifiers of multiple network nodes, and the startup information of the network node indicated by the identity identifier stored in the global data structure has been obtained by the management node;

[0227] If the first identity identifier is not stored in the global data structure, it is determined that the startup information of the first network node has not been obtained.

[0228] In one possible implementation, the sub-cluster information acquisition module 502 includes:

[0229] The second request unit is used to send a cluster identifier acquisition request to the first network node. The cluster identifier acquisition request is used to request the identifier of the first sub-cluster.

[0230] The second receiving unit is used to receive the first cluster identifier sent by the first network node, wherein the first cluster identifier is the identifier of the first sub-cluster;

[0231] The second acquisition unit is used to acquire the startup information of the first sub-cluster from the first network node if it is determined based on the first cluster identifier that the startup information of the first sub-cluster has not been acquired.

[0232] In one possible implementation, the second acquisition unit is further used for:

[0233] Obtain the global data structure, which stores the identifiers of the sub-clusters corresponding to each network node at the top level. The startup information of the sub-clusters indicated by the cluster identifiers stored in the global data structure has been obtained by the management node.

[0234] If the first cluster identifier is not stored in the global data structure, it is determined that the startup information of the first sub-cluster has not been obtained.

[0235] In one possible implementation, multiple network nodes are divided into two layers according to the network topology. The first network node is connected to the second network node, which is the network node at the bottom layer of the two layers, and the second network node is connected to at least one of the multiple processing nodes.

[0236] The startup information of the first sub-cluster includes the startup information of the second network node and the startup information of the second sub-cluster. The second sub-cluster is the sub-cluster corresponding to the second network node and includes all processing nodes connected to the second network node. The startup information of the second sub-cluster indicates the trusted startup status of all nodes in the second sub-cluster.

[0237] In one possible implementation, the first network node obtains the startup information of the second network node in the same way that the management node obtains the startup information of the first network node.

[0238] In one possible implementation, the startup information of the second sub-cluster is obtained from the second network node; wherein the first network node obtains the startup information of the second sub-cluster from the second network node in the same way that the management node obtains the startup information of the first sub-cluster from the first network node.

[0239] In one possible implementation, the node startup information includes a node certificate, a node certificate chain, and a metric report; wherein, the node certificate is used to identify the identity of the corresponding node, the node certificate chain is used to verify whether the corresponding node is a trusted node, and the metric report is used to assess the security of the corresponding node.

[0240] In this embodiment, the management node is directly connected to the top-level network node, which in turn is connected to the downstream sub-cluster nodes. Based on this communication connection, the management node only needs to communicate with the top-level network node to collect the cluster startup information of the entire cluster, greatly simplifying the communication link. At the same time, the top-level network node, as an information aggregation point, is responsible for collecting the startup information of all downstream nodes connected to it and transmitting the startup information of all downstream nodes to the management node. This achieves distributed collection of startup information, avoids single-point bottlenecks and failure risks, and also avoids the management node collecting the startup information of each downstream node one by one. This greatly reduces the time overhead of collecting the startup information of the entire cluster, improves the efficiency of the management node in collecting the startup information of all nodes in the cluster, and thus improves the efficiency of the verification device in verifying the trusted startup status of the cluster.

[0241] It should be noted that the cluster trusted verification device provided in the above embodiments, when collecting startup information of all nodes in the entire cluster, is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the cluster trusted verification device and the cluster trusted verification method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0242] Figure 6 A schematic diagram of a computer device is shown. This computer device can be a terminal device or a server, or other devices including hardware such as a processor. In this embodiment, the computer device can act as a management node to perform the above-described... Figure 4 The cluster trust verification method shown is illustrated. Please refer to [reference needed]. Figure 6 The computer device includes at least one processor 601, a communication bus 602, a memory 603, and at least one communication interface 604.

[0243] Processor 601 can be a general-purpose central processing unit (CPU), a network processor (NP), a microprocessor, or one or more integrated circuits for implementing the solutions of this application, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0244] The communication bus 602 is used to transmit information between the aforementioned components. The communication bus 602 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0245] The memory 603 may be a read-only memory (ROM), a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), an optical disc (including a compact disc read-only memory (CD-ROM), a compressed optical disc, a laser disc, a digital versatile optical disc, a Blu-ray disc, etc.), a magnetic disk storage medium, or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but not limited thereto. The memory 603 may exist independently and be connected to the processor 601 via a communication bus 602. The memory 603 may also be integrated with the processor 601.

[0246] Communication interface 604 uses any transceiver-like device for communicating with other devices or communication networks. Communication interface 604 includes a wired communication interface and may also include a wireless communication interface. The wired communication interface may be, for example, an Ethernet interface. The Ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof.

[0247] As an example, processor 601 may include one or more CPUs, such as Figure 6 CPU0 and CPU1 are shown in the diagram.

[0248] As an example, a computer device may include multiple processors, such as Figure 6 The processors 601 and 605 are shown. Each of these processors may be a single-core processor or a multi-core processor. A processor here may refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0249] In some embodiments, the computer device may further include output devices and input devices. The output device communicates with the processor 601 and can display information in various ways. For example, the output device may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device communicates with the processor 601 and can receive user input in various ways. For example, the input device may be a mouse, keyboard, touchscreen device, or sensing device, etc.

[0250] In some embodiments, memory 603 is used to store program code 610 for executing the scheme of this application, and processor 601 can execute the program code 610 stored in memory 603. The program code 610 may include one or more software modules, and the computer device can implement the cluster trusted verification method provided in the embodiments of this application through processor 601 and program code 610 in memory 603.

[0251] See Figure 7 , Figure 7This is a schematic diagram of a network device provided in an embodiment of this application. The network device can be a switch, router, access gateway, or other similar device. In this embodiment, the network device can be any network node within a cluster, such as the first or second network node mentioned in the above embodiments, executing the cluster trust verification method provided in this embodiment to collect startup information from all connected downstream nodes.

[0252] like Figure 7 As shown, the network device includes: a main control board 710, an interface board 730, and an interface board 740. In the case of multiple interface boards, a switching network board may be included. Figure 7 (Not shown in the image), this switching network board is used to complete the data exchange between various interface boards (interface boards are also called line cards or service boards).

[0253] The main control board 710 is used to perform functions such as system management, equipment maintenance, and protocol processing. Interface boards 730 and 740 provide various service interfaces (e.g., POS interface, GE interface, ATM interface, etc.) and implement data stream forwarding. The main control board 710 mainly has three types of functional units: a system management control unit, a system clock unit, and a system maintenance unit. The main control board 710, interface boards 730, and interface boards 740 communicate with each other via a system bus connected to the system backplane. Interface board 730 includes one or more processors 731. The processors 731 control and manage the interface boards, communicate with the central processing unit on the main control board, and handle data stream forwarding. The memory 732 on interface board 730 stores forwarding table entries; the processors 731 forward data streams by looking up the forwarding table entries stored in memory 732.

[0254] The interface board 730 includes one or more network interfaces 733 for receiving data streams sent by computing nodes, other network devices, etc., and forwarding data packets in these data streams according to the instructions of the processor 731. The specific implementation process will not be described in detail here.

[0255] Understandable, such as Figure 7 As shown, this embodiment includes multiple interface boards and employs a distributed forwarding mechanism. Under this mechanism, the operations on interface board 740 are basically similar to those on interface board 730, and for simplicity, they will not be described in detail. Furthermore, it is understood that... Figure 7The processor 731 in interface board 730 and / or the processor 741 in interface board 740 can be dedicated hardware or chips, such as network processors or application-specific integrated circuits (ASICs), to implement the above functions. This implementation method is commonly referred to as using dedicated hardware or chips for the forwarding plane. Of course, processor 731 and / or processor 741 can also use general-purpose processors, such as general-purpose CPUs, to implement the functions described above.

[0256] Furthermore, it should be noted that a network device may have one or more main control boards, including a primary and a backup main control board. Similarly, it may have one or more interface boards; the more data processing capabilities the network device possesses, the more interface boards it provides. When a network device includes multiple interface boards, these boards can communicate through one or more switching network boards, enabling load sharing and redundancy backup. In a centralized forwarding architecture, the network device may not require a switching network board; the interface boards handle the entire system's business data processing. In a distributed forwarding architecture, the network device can include multiple interface boards, which can exchange data through a switching network board, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of a distributed architecture network device are greater than those of a centralized architecture network device. The specific architecture adopted depends on the specific network deployment scenario, and no limitations are imposed here.

[0257] In some embodiments, memory 732 may be read-only memory (ROM), random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), optical discs (including compact disc read-only memory (CD-ROM), compressed optical discs, laser discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium capable of carrying or storing desired program code having an instruction or data structure form and accessible by a computer, but not limited thereto. Memory 732 may exist independently and be connected to processor 731 via a communication bus. Of course, memory 732 may also be integrated with processor 731.

[0258] In some embodiments, network interface 733 can be a transceiver-like device used to communicate with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), etc. Network interface 733 includes a wired network interface and may also include a wireless network interface. The wired network interface can be, for example, an Ethernet interface. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. The wireless network interface can be a WLAN interface, a cellular network communication interface, or a combination thereof, etc. When the network device acts as any network device within a domain, network interface 733 is used to forward data packets to other network devices; when the network device acts as a head node within a domain, network interface 733 can also be used to communicate with computing nodes, such as receiving data packets sent by computing nodes.

[0259] In some embodiments, a network device may include multiple processors, each of which may be a single-core processor or a multi-core processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0260] In some embodiments, the memory 732 is used to store a computer program that executes the scheme of this application, and the processor 731 can execute the computer program stored in the memory 732 to implement the cluster trusted verification method provided in the embodiments of this application.

[0261] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the cluster trusted verification method shown in the above embodiments.

[0262] This application also provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the steps of the signature generation method shown in the above embodiments. Alternatively, it provides a computer program that, when executed on a computer, causes the computer to perform the steps of the cluster trusted verification method shown in the above embodiments.

[0263] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital versatile disc (DVD)), or a semiconductor medium (e.g., solid state disk (SSD)). It is worth noting that the computer-readable storage medium mentioned in the embodiments of this application can be a non-volatile storage medium; in other words, it can be a non-transient storage medium.

[0264] It should be understood that "multiple" as mentioned herein refers to two or more. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In addition, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and the terms "first," "second," etc., do not necessarily imply that they are different.

[0265] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the startup information of each node in the cluster involved in the embodiments of this application is obtained under full authorization.

[0266] The above descriptions are embodiments provided in this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A cluster trust verification method, characterized in that, The method is applied to a management node of the cluster, which includes multiple network nodes and multiple processing nodes. The multiple network nodes are used to implement communication connections between the multiple processing nodes, and the multiple network nodes are divided into at least one layer according to the network topology. Obtain the startup information of the first network node, where the first network node refers to any network node located at the top layer and connected to the management node in the at least one layer, and the startup information of the first network node indicates the trusted startup status of the first network node. Obtain the startup information of the first sub-cluster, which is the sub-cluster corresponding to the first network node. The first sub-cluster includes all downstream nodes connected to the first network node. The downstream nodes include processing nodes, or the downstream nodes include network nodes and processing nodes. The startup information of the first sub-cluster indicates the trusted startup status of all nodes in the first sub-cluster, and the startup information of the first sub-cluster is collected by the first network node. Based on the startup information of the first network node and the startup information of the first sub-cluster, cluster startup information is generated. The cluster startup information is used by the verification device to verify the trusted startup status of all nodes in the cluster.

2. The method as described in claim 1, characterized in that, The step of obtaining the startup information of the first network node includes: Send a node identifier acquisition request to the first network node, the node identifier acquisition request being used to request the identity identifier of the first network node; Receive a first identity identifier sent by the first network node, wherein the first identity identifier is the identity identifier of the first network node; If it is determined based on the first identity identifier that the startup information of the first network node has not been obtained, then the startup information of the first network node is obtained.

3. The method as described in claim 2, characterized in that, The step of determining that the startup information of the first network node has not been obtained based on the first identity identifier includes: Obtain a global data structure, which is used to store the identity identifiers of the multiple network nodes, and the startup information of the network node indicated by the identity identifier stored in the global data structure has been obtained by the management node; If the first identity identifier is not stored in the global data structure, it is determined that the startup information of the first network node has not been obtained.

4. The method according to any one of claims 1-3, characterized in that, The step of obtaining the startup information of the first sub-cluster includes: Send a cluster identifier acquisition request to the first network node, the cluster identifier acquisition request being used to request the identifier of the first sub-cluster; Receive the first cluster identifier sent by the first network node, where the first cluster identifier is the identifier of the first sub-cluster; If it is determined based on the first cluster identifier that the startup information of the first sub-cluster has not been obtained, then the startup information of the first sub-cluster is obtained from the first network node.

5. The method as described in claim 4, characterized in that, The step of determining that the startup information of the first sub-cluster has not been obtained based on the first cluster identifier includes: Obtain a global data structure, which is used to store the identifiers of the sub-clusters corresponding to each of the top-level network nodes, and the startup information of the sub-clusters indicated by the cluster identifiers stored in the global data structure has been obtained by the management node. If the first cluster identifier is not stored in the global data structure, it is determined that the startup information of the first sub-cluster has not been obtained.

6. The method according to any one of claims 1-5, characterized in that, The plurality of network nodes are divided into two layers according to the network topology. The first network node is connected to the second network node. The second network node refers to the network node located at the bottom layer of the two layers, and the second network node is connected to at least one of the plurality of processing nodes. The startup information of the first sub-cluster includes the startup information of the second network node and the startup information of the second sub-cluster. The second sub-cluster is the sub-cluster corresponding to the second network node and includes all processing nodes connected to the second network node. The startup information of the second sub-cluster indicates the trusted startup status of all nodes in the second sub-cluster.

7. The method as described in claim 6, characterized in that, The first network node obtains the startup information of the second network node in the same way that the management node obtains the startup information of the first network node.

8. The method as described in claim 6 or 7, characterized in that, The startup information for the second sub-cluster is obtained from the second network node; The method by which the first network node obtains the startup information of the second sub-cluster from the second network node is the same as the method by which the management node obtains the startup information of the first sub-cluster from the first network node.

9. The method according to any one of claims 1-8, characterized in that, The node's startup information includes the node certificate, the node certificate chain, and a metrics report; The node certificate is used to identify the identity of the corresponding node, the node certificate chain is used to verify whether the corresponding node is a trusted node, and the metric report is used to evaluate the security of the corresponding node.

10. A cluster trust verification device, characterized in that, The device includes a management node within the cluster, the cluster comprising multiple network nodes and multiple processing nodes, the multiple network nodes being used to establish communication connections between the multiple processing nodes, and the multiple network nodes being divided into at least one layer according to a network topology; the device includes: The node information acquisition module is used to acquire the startup information of the first network node. The first network node refers to any network node located at the top layer and connected to the management node in the at least one layer. The startup information of the first network node indicates the trusted startup status of the first network node. The sub-cluster information acquisition module is used to acquire the startup information of the first sub-cluster, the first sub-cluster being the sub-cluster corresponding to the first network node, the first sub-cluster including all downstream nodes connected to the first network node, the downstream nodes including processing nodes, or the downstream nodes including network nodes and processing nodes, the startup information of the first sub-cluster indicating the trusted startup status of all nodes in the first sub-cluster, and the startup information of the first sub-cluster being collected by the first network node. The information integration module is used to generate cluster startup information based on the startup information of the first network node and the startup information of the first sub-cluster. The cluster startup information is used by the verification device to verify the trusted startup status of all nodes in the cluster.

11. The apparatus as claimed in claim 10, characterized in that, The node information acquisition module includes: The first request unit is configured to send a node identifier acquisition request to the first network node, wherein the node identifier acquisition request is used to request the acquisition of the identity identifier of the first network node. The first receiving unit is configured to receive a first identity identifier sent by the first network node, wherein the first identity identifier is the identity identifier of the first network node. The acquisition unit is configured to acquire the startup information of the first network node if it is determined based on the first identity identifier that the startup information of the first network node has not been acquired.

12. The apparatus as claimed in claim 11, characterized in that, The acquisition unit is further configured to: Obtain a global data structure, which is used to store the identity identifiers of the multiple network nodes, and the startup information of the network node indicated by the identity identifier stored in the global data structure has been obtained by the management node; If the first identity identifier is not stored in the global data structure, it is determined that the startup information of the first network node has not been obtained.

13. The apparatus according to any one of claims 10-12, characterized in that, The sub-cluster information acquisition module includes: The second request unit is used to send a cluster identifier acquisition request to the first network node, wherein the cluster identifier acquisition request is used to request the acquisition of the identifier of the first sub-cluster; The second receiving unit is used to receive the first cluster identifier sent by the first network node, wherein the first cluster identifier is the identifier of the first sub-cluster; The second acquisition unit is configured to acquire the startup information of the first sub-cluster from the first network node if it is determined based on the first cluster identifier that the startup information of the first sub-cluster has not been acquired.

14. The apparatus as claimed in claim 13, characterized in that, The second acquisition unit is further configured to: Obtain a global data structure, which is used to store the identifiers of the sub-clusters corresponding to each of the top-level network nodes, and the startup information of the sub-clusters indicated by the cluster identifiers stored in the global data structure has been obtained by the management node. If the first cluster identifier is not stored in the global data structure, it is determined that the startup information of the first sub-cluster has not been obtained.

15. The apparatus according to any one of claims 10-14, characterized in that, The plurality of network nodes are divided into two layers according to the network topology. The first network node is connected to the second network node. The second network node refers to the network node located at the bottom layer of the two layers, and the second network node is connected to at least one of the plurality of processing nodes. The startup information of the first sub-cluster includes the startup information of the second network node and the startup information of the second sub-cluster. The second sub-cluster is the sub-cluster corresponding to the second network node and includes all processing nodes connected to the second network node. The startup information of the second sub-cluster indicates the trusted startup status of all nodes in the second sub-cluster.

16. The apparatus as claimed in claim 15, characterized in that, The first network node obtains the startup information of the second network node in the same way that the management node obtains the startup information of the first network node.

17. The apparatus as claimed in claim 15 or 16, characterized in that, The startup information for the second sub-cluster is obtained from the second network node; The method by which the first network node obtains the startup information of the second sub-cluster from the second network node is the same as the method by which the management node obtains the startup information of the first sub-cluster from the first network node.

18. The apparatus according to any one of claims 10-17, characterized in that, The node's startup information includes the node certificate, the node certificate chain, and a metrics report; The node certificate is used to identify the identity of the corresponding node, the node certificate chain is used to verify whether the corresponding node is a trusted node, and the metric report is used to evaluate the security of the corresponding node.

19. A computer device, characterized in that, The computer device includes a processor and memory; The memory is used to store computer programs; The processor is used to execute the computer program to implement the method according to any one of claims 1-9.

20. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the method described in any one of claims 1-9.

21. A computer program product, characterized in that, The computer program product stores computer instructions, which, when executed by a processor, implement the steps of the method described in any one of claims 1-9.

Images