Network topology management method, device, system and storage medium

Abstract

The present invention relates to the field of network management technology, and provides a network topology management method, device, system and storage medium, wherein the method comprises: upon receiving a topology discovery start instruction, sending a topology discovery request message to a switch, so that the switch broadcasts the topology discovery request message to a second device, the second device being a device other than the first device connected to the switch in a southbound network; receiving a topology discovery response message forwarded by the switch; parsing the topology discovery response message, and establishing a network connection with the second device based on the identification information of the second device obtained by the parsing and local identification information, to obtain the network topology information of the first device. The present invention can collect all the network topology information of the entire southbound network by having the first device send a topology discovery request message in the southbound network, thereby realizing the management and maintenance of the southbound network.

Description

Technical Field

[0001] The present invention relates to the technical field of network management, and in particular to a network topology management method, device, system and storage medium. Background Art

[0002] In the field of AI device clusters, major manufacturers are actively developing their own southbound networks. Given the increasing demand for data processing speed and efficiency, the design of southbound networks has become particularly critical. To achieve high-bandwidth, low-latency data transmission, manufacturers have adopted a variety of technical approaches in developing southbound networks, including standard Ethernet, RDMA (Remote Direct Memory Access) networks, and bus-level protocols. While this diversity has enriched the implementation options of southbound networks, it has also greatly increased their management complexity. As clusters continue to expand, how to efficiently monitor and maintain southbound networks has become a major challenge that needs to be addressed. Summary of the Invention

[0003] The present invention provides a network topology management method, device, system and storage medium to address the defects of complex and difficult-to-maintain southbound network management in the field of artificial intelligence device clusters in related technologies.

[0004] The present invention provides a network topology management method, which is applied to a first device and includes:

[0005] Upon receiving a start topology discovery instruction, sending a topology discovery request message to a switch, so that the switch broadcasts the topology discovery request message to a second device, where the second device is a device other than the first device connected to the switch in a southbound network, the southbound network including a plurality of server nodes and a plurality of switches, each server node being provided with at least one device, and each device being connected to at least one switch;

[0006] receiving a topology discovery response message forwarded by the switch, where the topology discovery response message is replied to the switch by the second device when checking the topology discovery request message and passing it;

[0007] The topology discovery response message is parsed, and based on the identification information of the second device obtained by the parsing and the local identification information, a network connection is established with the second device to obtain the network topology information of the first device.

[0008] A network topology management method provided by the present invention further includes:

[0009] Based on the network topology information, sending a topology keepalive request message to the switch, so that the switch unicasts the topology keepalive request message to a target device, where the target device is a device among the second devices that establishes a network connection with the first device;

[0010] receiving a topology keepalive response message forwarded by the switch, and parsing the topology keepalive response message to obtain a keepalive status, wherein the topology keepalive response message is replied to the switch by the target device based on a result of checking the topology keepalive request message;

[0011] When the keep-alive state is failure, the topology keep-alive request message continues to be sent until the number of failures exceeds a threshold, and then the topology discovery request message is resent.

[0012] According to a network topology management method provided by the present invention, the identification information includes a node identification, a device identification, and a port identification.

[0013] The present invention provides a network topology management method, which is applied to a second device and includes:

[0014] Receiving a topology discovery request message broadcast by a switch, where the topology discovery request message is sent by a first device to the switch upon receiving an instruction to start topology discovery, where the first device is a device other than the second device connected to the switch in a southbound network, where the southbound network includes multiple server nodes and multiple switches, each server node is provided with at least one device, and each device is connected to at least one switch;

[0015] The topology discovery request message is checked, and if the check passes, a topology discovery response message is replied to the switch, so that the switch forwards the topology discovery response message to the first device. The first device is used to parse the topology discovery response message and establish a network connection with the second device based on the identification information of the second device obtained by parsing and the local identification information to obtain the network topology information of the first device.

[0016] According to a network topology management method provided by the present invention, the checking of the topology discovery request message includes:

[0017] Parsing the topology discovery request message to obtain a port identifier and a group identifier of the source device;

[0018] Comparing the port identifier of the source device with the local port identifier to obtain a first comparison result, and comparing the group identifier of the source device with the local group identifier to obtain a second comparison result;

[0019] If the first comparison result and the second comparison result are both consistent, it is determined that the check is passed; otherwise, an alarm log is generated.

[0020] A network topology management method provided by the present invention further includes:

[0021] receiving a topology keepalive request message unicast by the switch, where the topology keepalive request message is sent by the first device to the switch when a network connection is established between the first device and the second device;

[0022] The topology keepalive request message is checked, and based on the check result, a topology keepalive response message is replied to the switch, so that the switch forwards the topology keepalive response message to the first device, and the first device is used to parse the topology keepalive response message to obtain the keepalive status.

[0023] According to a network topology management method provided by the present invention, the checking of the topology keepalive request message includes:

[0024] Parsing the topology keepalive request message to obtain identification information of the source device, identification information of the target device, and a group identification of the source device;

[0025] Comparing the node identifier in the identification information of the target device with the local node identifier to obtain a first result, comparing the port identifier in the identification information of the source device with the local port identifier to obtain a second result, and comparing the group identifier of the source device with the local group identifier to obtain a third result;

[0026] If the first result, the second result, and the third result are all consistent, checking whether the connection information exists locally; if so, determining that the keep-alive state is successful; otherwise, determining that the keep-alive state is failed; the connection information is determined based on the identification information of the source device and the identification information of the target device;

[0027] When any one of the first result, the second result, and the third result is inconsistent, an alarm log is generated.

[0028] The present invention further provides a network topology management device, which is applied to a first device and includes:

[0029] a sending unit, configured to, upon receiving an instruction to start topology discovery, send a topology discovery request message to the switch, so that the switch broadcasts the topology discovery request message to a second device, where the second device is a device other than the first device connected to the switch in a southbound network, the southbound network comprising a plurality of server nodes and a plurality of switches, each server node being provided with at least one device, and each device being connected to at least one switch;

[0030] a receiving unit, configured to receive a topology discovery response message forwarded by the switch, wherein the topology discovery response message is replied to the switch by the second device when checking the topology discovery request message and passing it;

[0031] An establishing unit is used to parse the topology discovery response message, and based on the identification information of the second device obtained by the analysis and the local identification information, establish a network connection with the second device to obtain the network topology information of the first device.

[0032] The present invention further provides a network topology management device, which is applied to a second device and includes:

[0033] a message receiving unit, configured to receive a topology discovery request message broadcast by a switch, wherein the topology discovery request message is sent by a first device to the switch upon receiving an instruction to start topology discovery, wherein the first device is a device other than the second device connected to the switch in a southbound network, the southbound network including a plurality of server nodes and a plurality of switches, each server node being provided with at least one device, and each device being connected to at least one switch;

[0034] A message reply unit is used to check the topology discovery request message and, if the check passes, reply a topology discovery response message to the switch, so that the switch forwards the topology discovery response message to the first device. The first device is used to parse the topology discovery response message and establish a network connection with the second device based on the identification information of the second device obtained by parsing and the local identification information to obtain the network topology information of the first device.

[0035] The present invention also provides a device, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein when the processor executes the computer program, any of the above-mentioned network topology management methods is implemented.

[0036] The present invention also provides a network topology management system, comprising a management node, a plurality of server nodes, and a plurality of switches, wherein each server node is provided with at least one device as described above, each device comprising at least one port, and each port being connected to a switch;

[0037] The server node is used to obtain network topology information of each local device and report the network topology information of each device to the management node;

[0038] The management node is used to obtain information about each switch based on the switch management network, and manage the network topology information of each device and the information of each switch.

[0039] According to a network topology management system provided by the present invention, the management node is further used to assign a node identifier to each server node, and uniformly assign IP addresses to all ports of all devices on all server nodes;

[0040] The server node is further configured to generate a global device identifier for each device based on the node identifier and the local device identifier of each device.

[0041] According to a network topology management system provided by the present invention, a plurality of management nodes are provided.

[0042] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which implements any of the above-mentioned network topology management methods when executed by a processor.

[0043] The present invention also provides a computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements any of the above-mentioned network topology management methods.

[0044] The network topology management method, device, system, and storage medium provided by the present invention can obtain identification information of a second device by sending a topology discovery request message, receiving a topology discovery response message, and parsing the topology discovery response message. Based on this information, a first device can establish a network connection with the second device to obtain network topology information of the first device. Since the southbound network includes multiple server nodes, each server node is provided with at least one device, and each device can serve as both a first device and a second device, the above steps can collect all network topology information of the entire southbound network. Based on this network topology information, the southbound network can be managed and maintained. In addition, the first device automatically sends the topology discovery request message upon receiving a topology discovery start instruction, eliminating the need for manual configuration or network connection checking, thereby helping to improve the efficiency and accuracy of network topology management. The topology discovery request message is broadcast by the switch, covering every device connected to the switch in the network, ensuring the integrity of the network topology information. The topology discovery response message is replied by the second device if the request message is checked and passed, thereby ensuring the compliance and validity of the network connection between the first and second devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the technical solutions in the present invention or related technologies, the following is a brief introduction to the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0046] Figure 1 It is a structural diagram of the southbound network provided by the present invention;

[0047] Figure 2 This is one of the structural diagrams of the network topology management system provided by the present invention;

[0048] Figure 3 This is the second structural diagram of the network topology management system provided by the present invention;

[0049] Figure 4 This is one of the flow charts of the network topology management method provided by the present invention;

[0050] Figure 5 This is the second flow chart of the network topology management method provided by the present invention;

[0051] Figure 6 This is a schematic diagram of topology discovery provided by the present invention;

[0052] Figure 7 This is a schematic diagram of topology keep-alive provided by the present invention;

[0053] Figure 8 This is one of the structural diagrams of the network topology management device provided by the present invention;

[0054] Figure 9 This is the second structural diagram of the network topology management device provided by the present invention;

[0055] Figure 10 It is a structural schematic diagram of the device provided by the present invention. DETAILED DESCRIPTION

[0056] To make the objectives, technical solutions, and advantages of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the embodiments described are only some of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0057] In the context of AI device clusters, the southbound network refers to the network formed by connecting the cluster's service-side ports to other devices. Here, AI devices can be GPUs (Graphics Processing Units), GPGPUs (General-purpose Computing on Graphics Processing Units), TPUs (Tensor Processing Units), and so on, though this disclosure does not specifically limit this. It should be understood that the cluster's service-side ports refer to the ports used by each device in the cluster for service data transmission. Through these ports, the cluster forms a unified entity, jointly processing service requests and data transmission.

[0058] To address southbound network management issues, this paper fully describes the process for southbound network topology discovery and maintenance and develops a management system to implement this solution. To facilitate understanding of the present invention's technical solution, the following primarily uses the southbound network of a GPU cluster as an example to illustrate the present invention's technical solution.

[0059] A GPU cluster usually includes multiple server nodes, each of which is deployed with multiple GPU accelerator cards (hereinafter referred to as "GPU cards"). Each of these GPU cards has multiple ports, and each port is connected to a switch. Figure 1 This is a schematic diagram of the structure of the southbound network provided by the present invention, such as Figure 1As shown, it only takes server node 0 as an example. Server node 0 is deployed with 8 GPU cards, GPU0 to GPU7. Each GPU card has 8 ports, and each port is connected to one of the 8 switches, switch0 to switch7. This architecture allows each GPU card to communicate efficiently with other GPU cards in the cluster through the switch, thus building a complex network topology, namely the southbound network. It should be noted that Figure 1 The ports on each GPU card connected to the external switches (switch0 to switch7) are the service-side ports of the cluster.

[0060] It should be noted that a server node refers to an independent computing device or processing unit that undertakes a specific task in the network. They are interconnected through the network and jointly complete data processing, storage, and transmission tasks. For example, a server node can be a GPU server. Within the server node, GPU cards can also be interconnected through PCIE (Peripheral Component Interconnect Express, a high-speed serial computer expansion bus standard) buses, switches, etc. ( Figure 1 Not shown in the figure), since the present invention mainly realizes the management of the southbound network, the connection network between the GPU cards inside the server node is not described here.

[0061] An embodiment of the present invention provides a network topology management system, comprising a management node, multiple server nodes, and multiple switches. Each server node is provided with at least one device, each device including at least one port, each port being connected to a switch. These ports on each device constitute the service-side ports of the cluster. In the network topology management system, each server node is configured to obtain network topology information for each local device and report this information to the management node. The management node is configured to obtain information about each switch based on a switch management network and manage the network topology information of each device and the information of each switch. It should be understood that topology refers to the physical connection relationships between entities within a network, and network topology management refers to the process of configuring, monitoring, and maintaining these connections.

[0062] It should be noted that the above-mentioned device refers to an artificial intelligence device, which can be a GPU, GPGPU, TPU, etc. The embodiment of the present invention mainly uses a GPU as an example. When the device is a GPU, the device refers to a GPU card.

[0063] Figure 2 This is one of the structural diagrams of the network topology management system provided by the present invention, such as Figure 2As shown in the figure, management server 1 and management server 2 are management nodes, GPU server 0, GPU server 1, ..., GPU server 63 are server nodes, and switch 0, switch 1, ..., switch 7 are switches. The management nodes (i.e., management servers) can access the server management network and allocate and manage resources for each server node (i.e., each GPU server) through the server management network. They can also access the switch management network and collect switch information through the switch management network. It should be understood that the management node can be a regular GPU server or another server. Regardless of the server type, it must have access to both the server management network and the switch management network.

[0064] Specifically, to manage the southbound network, the present invention designs two pieces of management software. One, named fabric-server, serves as a server and is deployed on management nodes. Management nodes support both centralized and distributed deployment. When reliability is high, distributed deployment can be used to prevent abnormalities in the fabric-server software or hardware failures such as power outages on the server where it resides. The other, named fabric-client, serves as a client and is deployed on GPU servers (i.e., server nodes). It should be noted that when distributed deployment is used for management nodes, one management server can serve as the master (i.e., primary management server), while the others serve as slaves (i.e., backup management servers).

[0065] Specifically, once the GPU server and switch cluster are connected via a transmission medium, establishing a southbound network connection, users can configure the management IP (Internet Protocol) addresses of the GPU servers, the management server, and the switches. Furthermore, users can configure IP addresses for each port on all devices (i.e., all GPU cards) within the southbound network based on their network planning requirements. Alternatively, the management server can uniformly assign IP addresses to all ports on all devices within the southbound network.

[0066] After completing the corresponding configuration, the fabric-client on each GPU server can send a topology discovery request message within the southbound network to broadcast the GPU information on that GPU server to other network-reachable fabric-clients. Specific GPU information includes the GPU MAC (Media Access Control) address, GPU port ID, and GPU IP address. Upon receiving this information, the fabric-client on the other GPU server replies with its own GPU information. Upon receiving this information, the requester can establish a network connection. For example, GPU1.port 5 and GPU9.port 5 can establish a network connection and communicate with each other. Here, GPU1.port 5 refers to port 5 of GPU1, and GPU9.port 5 refers to port 5 of GPU9. Both GPU1 and GPU9 are GPU cards.

[0067] Following the same logic, all ports on all GPUs in the cluster will send topology discovery request packets. Each GPU will collect information about all connections within the southbound network that are reachable to its own network. This completes the network topology for each GPU. The fabric-client on each GPU server can report the network topology information of all GPUs on that server to the fabric-server. This allows the fabric-server to have the network topology connections of all fabric-clients, ensuring a global and complete view of the connections on the fabric-server. Furthermore, the fabric-server collects switch information through the switch management network, providing comprehensive information about all GPU servers and switches.

[0068] It's important to note that due to the wide variety of switch manufacturers and their varying management methods, they can't uniformly provide communication via service ports or in-band. Therefore, to maintain solution compatibility, the switch management ports can be used to communicate with GPU servers. Furthermore, to facilitate access by management nodes to both the switch and server management networks, the switch and server management networks can be deployed as a unified management network. However, the switch and server management networks are typically separate networks. This setup prevents conflicting permissions between the server and switch. Therefore, in this scenario, the fabric-server can be deployed on a jump machine that has access to both the switch and server management networks.

[0069] Based on the above embodiment, the management node is also used to assign a node identifier to each server node, and uniformly assign IP addresses to all ports of all devices on all server nodes; the server node is also used to generate a global device identifier for each device based on the node identifier and the local device identifier of each device.

[0070] Specifically, the aforementioned topology discovery request and other protocol messages are all sent within the southbound network and are unrelated to the management node (i.e., the management server). The management node primarily provides auxiliary functions. For example, the management node can assign node identifiers to each server node (i.e., all GPU servers that act as clients), uniformly assign IP addresses to all ports of all devices on all server nodes, and obtain switch information. A node identifier, represented as a node ID, is a unique identifier assigned to each node in the network. It is used to distinguish and identify different server nodes, and is also a unique global ID for each server node.

[0071] After assigning a node ID, the server node generates a global device ID for each device based on the node ID and the local device IDs of each device on that node. Here, the local device ID, represented by the local GPU ID, is a unique identifier for each device (such as each GPU card) on its GPU server. The global device ID, represented by the global GPU ID, is a unique identifier for each device within the entire device cluster. The following details the deployment process of the fabric-server and fabric-client management software, as well as the process for generating global device IDs for each device.

[0072] Figure 3 This is the second structural diagram of the network topology management system provided by the present invention, such as Figure 3 As shown, first, the user decides which servers will assume the server role, that is, as management servers. A single server can be used for centralized management, or multiple servers can be used for distributed management. If a single server fails, it will cause abnormalities in the fabric-server network and affect the normal management of the network topology. Therefore, distributed deployment is recommended.

[0073] After determining which servers will assume the server role, users can install the fabric-server installation package on these management servers and start the fabric-server service. Subsequently, users can configure the fabric-server service configuration file based on their networking requirements. The configuration file should include the following: ① The IPv4 address list of the management server (multiple management servers can assume the server role); ② The TCP port number for the transport layer (the default is 65330); and ③ The IPv4 address list of fabric-client members, which is the IPv4 address list of all GPU servers managed by this management server.

[0074] After completing the configuration file settings, you need to restart the fabric-server service. During the service restart, if there are multiple management servers (i.e., multiple management nodes), in a distributed scenario, one of the management servers' IPv4 addresses is elected as the fabric-server master node, while the others serve as fabric-server slave nodes. In other words, one of the multiple management servers is elected as the master (i.e., primary management server), while the others serve as slaves (i.e., backup management servers). Master election can be based on each management server's PCB (Printed Circuit Board) serial number or UUID (Universally Unique Identifier). After the master node is elected, it subsequently assumes responsibilities such as resource allocation and submits resource allocation results and other information to other slave nodes for backup. If the master node fails, a new master node can be elected from all the slave nodes.

[0075] For example, Figure 3 As shown in the figure, the user has selected two servers as management servers, management server 1 as the master and management server 2 as the slave. Fabric-server software is deployed on both management server 1 and management server 2. Figure 3 The linux user and linux kernel in the Linux system respectively represent the user space and kernel space, where the user space refers to the memory space where ordinary user programs run, and the kernel space refers to the memory space where the operating system kernel runs. Figure 3As shown in the figure, the fabric-server software installation package is deployed in the user space, while the network card driver runs in the kernel space. The fabric-server service can interact with the network card driver.

[0076] After completing fabric-server deployment, users can begin fabric-client deployment. First, users also determine which GPU servers will assume the client role, install the fabric-client installation package on each selected GPU server, and start the fabric-client service. Next, users configure the configuration file for each fabric-client service based on networking requirements. This file includes the following: ① The IPv4 address list of all management servers assuming the server role; ② The TCP port number for the transport layer. If not set, it defaults to 65330; ③ The group identifier (clique ID) for each GPU card on this GPU server. If not configured, it defaults to 0. Only GPU cards with the same clique ID can communicate within the southbound network; ④ The southbound network IPv4 address list is configured for each port on each GPU card. If not configured, it will be allocated uniformly by the fabric-server master on the management node. Each GPU server contains one or more GPU cards, each with one or more ports. Therefore, an IPv4 address must be configured for each port.

[0077] After completing the configuration file settings, you need to restart the fabric-client service. During the service restart process, if the user has not configured the IPV4 address of each port of each GPU card, apply to the fabric-servermaster for the IPV4 address of each port of all GPU cards. At the same time, apply to the fabric-server master for the node id (i.e., node identifier) of this GPU server. For each GPU server, after obtaining the node identifier, a global device identifier (i.e., global gpu id) can be generated for each GPU card based on the node identifier and the local device identifier of each GPU (i.e., local gpu id). For example, assuming there are 64 GPU servers, each GPU server has 8 GPU cards, and a total of 64×8=512 GPU cards. Based on the node id of the server where each GPU card is located and the local gpu id of the GPU card, a global unified number can be generated for each GPU card, that is, a global gpu id. Here, the local gpu id can be a unique number for each GPU card on the GPU server to which it belongs, such as Figure 1The 8 GPU cards on server node 0 have local GPU IDs 0 to 7. The global GPU ID can be used to locate the corresponding GPU card in the entire GPU cluster.

[0078] For example, assuming each GPU server reserves a maximum of 8 GPUs, the global GPU ID is generated as follows: the lower 3 bits represent the local GPU ID, and the remaining high-order bits represent the node ID. For example, if the node ID is 1 and the local GPU ID is 2, the generated global GPU ID is 0xa (hexadecimal), which corresponds to 1010 in binary and 10 in decimal. For example, assuming each GPU server reserves a maximum of 16 GPUs, the global GPU ID is generated as follows: the lower 4 bits represent the local GPU ID, and the remaining high-order bits represent the node ID.

[0079] For each GPU card, after generating the global GPU ID of the GPU card, a corresponding MAC address can be generated for each port on the GPU card. The MAC address generation rule is as follows: 00:00:00:node_id:gpu_id:port_id, where node_id refers to the node ID, gpu_id refers to the global GPU ID of the GPU card, and port_id is the port ID, which refers to the unique number of each port on the GPU card to which it belongs.

[0080] After generating the global GPU ID and MAC address, you can configure this information into the GPU card's registers. Then, request the UUID of this GPU server from the fabric-server master. The fabric-server master will return a UUID of this GPU server to the fabric-client.

[0081] During the fabric-client service restart, the clique id of each GPU card is assigned to the GPU kernel driver manager thread (i.e. Figure 3The fabric-manager-thread module in the GPU driver (as shown in the figure) is configured to carry the clique ID during subsequent topology discovery and keepalive operations. After completing all configurations, the fabric-client service can query the fabric-manager-thread module for its current status. If the fabric-manager-thread module is in the ready state, the service state is transitioned to the active state. If the fabric-manager-thread module is not ready or the service state transition fails, the service log command can be used to view this information. Finally, after the service state successfully transitions to the active state, the fabric-manager-thread module is notified to initiate the topology discovery process.

[0082] In addition, if Figure 3 As shown in the figure, a monitoring tool (i.e., monitor tool) is installed on each GPU server. This tool is user-oriented and allows users to view the network topology information of all GPU cards on the GPU server for operation and maintenance.

[0083] It should be noted that the network topology management provided by the present invention is mainly implemented through a topology discovery process and a topology keep-alive process. The specific processes of topology discovery and topology keep-alive will be described in detail below.

[0084] Based on any of the above embodiments, Figure 4 This is one of the flow charts of the network topology management method provided by the present invention, such as Figure 4 As shown, the method is applied to a first device, and the method includes:

[0085] Step 410: Upon receiving an instruction to start topology discovery, a topology discovery request message is sent to the switch so that the switch broadcasts the topology discovery request message to a second device, where the second device is a device other than the first device connected to the switch in a southbound network. The southbound network includes multiple server nodes and multiple switches, each server node is provided with at least one device, and each device is connected to at least one switch.

[0086] It should be noted that the execution entity of the method provided in the embodiments of the present invention is the first device, which refers to the device that initiates the topology discovery request in the southbound network. The second device refers to other devices in the southbound network that are connected to the same switch as the first device. For example, assume that the southbound network includes 64 GPU cards, namely GPU0 to GPU63, and each GPU card has 8 ports, respectively represented as port0 to port7. For each GPU card, its port port0 is connected to switch switch0, port1 is connected to switch switch1, and so on, and port7 is connected to switch switch7. In this case, when GPU0 is the first device, the other GPU cards (i.e., GPU1 to GPU63) are the second devices; when GPU1 is the first device, the other GPU cards (i.e., GPU0, GPU2 to GPU63) are the second devices, and so on. It should be understood that for each GPU card in the southbound network, it is both the first device and the second device.

[0087] Specifically, when the fabric-manager-thread module driven by the GPU kernel receives the start topology discovery command issued by the fabric-client service, the topology detection process begins. The following is an example using GPU0 as the first device.

[0088] First, a raw socket is created in the kernel-driven fabric-manager-thread module to trigger each port of GPU0 to periodically call the socket programming interface to broadcast and send a topology discovery request message. The initiation of a topology discovery instruction is a signal or command that triggers the first device (such as GPU0) to begin the topology discovery process. Here, broadcast refers to a communication method that sends data packets to all devices in the network. In this embodiment of the present invention, broadcast means that the topology discovery request message will be sent to all switches connected to GPU0, and each switch will forward the message to all connected devices (i.e., other GPU cards in the southbound network).

[0089] It is understood that the topology discovery request message is a data packet in a specific format sent by the first device (such as GPU0) to obtain network topology information. Specifically, the message header fields of the topology discovery request message may include ETH (DMAC, SMAC, PROTO), IPV4 header, UDP header, TOPO header, Payload, etc. The meaning of each field is shown in Table 1 below:

[0090] Table 1 Header of the topology discovery request message

[0091]

[0092] Table 2 TOPO header of topology discovery request message

[0093]

[0094] As shown in Table 2, the TOPO header in a topology discovery request message consists of a total of 32 bytes, with bytes 0-19 currently used. Bytes 0-3 encapsulate the message type opcode, the clique ID, and the status field. The value corresponding to the opcode can be 0x1, indicating that the message type is a discover message (i.e., a topology discovery request message). Bytes 4-7 encapsulate the node IDs of the source and target GPU servers. Bytes 8-11 encapsulate the device IDs of the source and target GPU cards (i.e., the global uniqueness of the GPU cards). Bytes 12-15 encapsulate the port IDs of the source and target GPU cards (i.e., the port IDs, which are unique within each GPU card). Bytes 16-19 are reserved fields. It should be noted that when GPU0 is the primary device, the TOPO header encapsulates the source node ID, source GPU ID, and source port ID associated with GPU0, while the destination information is all zero.

[0095] For GPU0, each port will send a topology discovery request message, which will be broadcast on the switch connected to each port. All other GPUs connected to the same switch will receive the topology discovery request message. For example, port 0 on GPU0 will send a topology discovery request message, which will be broadcast on switch 0. Port 0 on GPUs 1 through 63 connected to switch 0 will receive the request message.

[0096] Step 420: Receive a topology discovery response message forwarded by the switch. The topology discovery response message is replied to the switch by the second device when the second device passes the inspection of the topology discovery request message.

[0097] Specifically, other GPU cards (i.e., second devices) can receive topology discovery request messages through corresponding socket programming interfaces. After receiving the topology discovery request messages, they perform a series of checks to confirm the legitimacy and validity of the messages. For example, they can check whether the source MAC address carried in the message matches a known legitimate device address to prevent potential network attacks or misoperation.

[0098] For example, when deploying a southbound network, it's usually desirable to have regular connections between ports. This makes it easier to troubleshoot any problems. For example, GPU0's port0 (with a port ID of 0) is connected to the port0 of other GPUs, its port1 is connected to the port1 of other GPUs, and so on. Therefore, after receiving a topology discovery request message, other GPUs can check whether the source port ID carried in the message is consistent with the port ID of the local receiving port (that is, check whether the port IDs of the sending and receiving ports in the request message are consistent). If they are inconsistent, an alarm log is generated to remind the user to check the network connection. The main purpose of this is to ensure that all GPUs with the same port ID are connected to the same switching network, facilitating cabling and troubleshooting network problems.

[0099] For example, other GPU cards can check whether the clique ID carried in the message is consistent with the clique ID of the GPU card. If inconsistent, an alarm log is generated to remind the user to check the network connection and the network configuration of the switch, and the topology discovery request message is discarded.

[0100] If the topology discovery request message passes the check, meaning all fields in the message are valid, the switch can reply with a topology discovery response message in accordance with the protocol. A topology discovery response message is a data packet in a specific format sent to the switch by the second device (i.e., another GPU) after receiving and successfully verifying the topology discovery request message. The topology discovery response message has the same header as the topology discovery request message, but the opcode value encapsulated in the TOPO field is 0x2, indicating that the message type is a discover response. The message also encapsulates its source MAC address and clique ID, and writes its node ID, GPU ID, and port ID into the dst node ID, dst GPU ID, and dst port ID fields. The topology discovery response message is then sent using the socket programming interface.

[0101] After receiving the topology discovery response message replied by the second device, the switch may forward the response message to the first device, such as GPU0.

[0102] Step 430: parse the topology discovery response message, and establish a network connection with the second device based on the identification information of the second device obtained through the analysis and the local identification information, to obtain the network topology information of the first device.

[0103] Specifically, after receiving the topology discovery response message, GPU0 can parse the message to obtain the identification information of the second device (i.e., dst node ID, dst GPU ID, dst port ID) and the status field "status" carried in the message. If the status field is "success," GPU0 can obtain a complete connection message, namely, "src [node ID, GPU ID, port ID] - dst [node ID, GPU ID, port ID]. Here, src [node ID, GPU ID, port ID] is the identification information of the first device (i.e., local identification information), and dst [node ID, GPU ID, port ID] is the identification information of the second device. Based on this identification information, the first device can establish a network connection with the second device.

[0104] Specifically, the first device can match the parsed identification information of the second device with the locally stored connection information. If the match is successful, it indicates that connection information with the second device already exists, and the topology discovery response message can be directly discarded. If the match fails, the new connection information can be added to the local storage. Based on the matching or newly added connection information, the first device can attempt to establish a network connection with the second device, that is, use the appropriate network protocol and port number to communicate to ensure the correct transmission and reception of data.

[0105] After the first device stores the connection information locally, it can obtain its network topology information. Here, network topology information refers to information that records the connection relationships between the first device and other devices in the southbound network. For example, for GPU0, its network topology information includes information such as the node ID, device ID, and port ID of each GPU card interconnected to GPU0 via a switch. This information, in the form of connection information such as "src [node ID, gpu ID, port ID] - dst [node ID, gpu ID, port ID]," represents the connection relationship between the source device (i.e., the first device) and the destination device (i.e., the second device). By constructing this network topology information, the connectivity of the entire southbound network can be understood, providing a foundation for subsequent network communication and resource management.

[0106] Following the same logic as GPU0, each GPU in the southbound network receives its own complete network topology, which records the information of every GPU that can be interconnected through the switch. After the topology discovery process is complete, the entire network topology is established. The fabric-client deployed on each GPU server can now obtain the network topology information of all GPUs on that server and report this information to the fabric-server for unified management and maintenance.

[0107] In the method provided by an embodiment of the present invention, a first device can obtain identification information of a second device by sending a topology discovery request message, receiving a topology discovery response message, and parsing the topology discovery response message. Based on this information, the first device can establish a network connection with the second device to obtain network topology information of the first device. Since the southbound network includes multiple server nodes, each server node is equipped with at least one device, and each device can function as both a first device and a second device, the above steps can be used to collect the entire network topology information of the entire southbound network. Based on this network topology information, the southbound network can be managed and maintained. In addition, the first device automatically sends the topology discovery request message upon receiving a topology discovery start instruction, eliminating the need for manual configuration or network connection checking, thereby improving the efficiency and accuracy of network topology management. By broadcasting the topology discovery request message through the switch, it can cover every device connected to the switch in the network, ensuring the integrity of the network topology information. The topology discovery response message is sent by the second device in response to a successful check of the request message, thereby ensuring the compliance and validity of the network connection between the first and second devices.

[0108] Based on any of the above embodiments, the method further includes:

[0109] Step 440: Based on the network topology information, send a topology keepalive request message to the switch, so that the switch unicasts the topology keepalive request message to a target device, where the target device is a device in the second device that establishes a network connection with the first device.

[0110] It's important to note that a topology keepalive request message is used to confirm network connection status and maintain network topology information. After a network device (such as a GPU) establishes a connection, it periodically sends this message to verify the connection's viability and ensure its continuity and validity. If no response is received within a certain period of time, or if a response indicates a disconnected connection, appropriate measures (such as resending a topology discovery request message) can be taken to restore the network connection.

[0111] Specifically, once a complete network connection is established between the first device and the target device, a topology keepalive process can be initiated for this connection. Here, a target device refers to a device that has established a network connection with the first device in the southbound network. For example, using GPU0 as the first device, once port 5 of GPU0 establishes a network connection with port 5 of GPU9, a topology keepalive process can be initiated for the network connection between the two based on the network topology information between the two. Here, GPU9 is the target device.

[0112] Specifically, after GPU0 and GPU9 establish a network connection, a TCP (Transmission Control Protocol) connection can be established between the server node where GPU0 resides and the server node where GPU9 resides. This simply establishes a TCP connection between the two GPU servers, helping to reduce resource consumption. GPU0 can send topology keepalive request messages to GPU9 over this established TCP connection.

[0113] Here, if each port of GPU0 (e.g., port0-port7) has established a network connection with each port of GPU9, a topology keepalive request message is sent based on each connected port of GPU0. Each port of GPU0 can periodically call the corresponding socket programming interface to send a message. The message contains identification information such as the node ID, device ID, and port ID of the source device (i.e., the first device, GPU0) and the target device (i.e., GPU9), so that the switch can accurately unicast the message to the target device.

[0114] It is understood that the message header fields of the topology keepalive request message may include ETH (DMAC, SMAC, PROTO), IPV4 header, UDP header, TOPO header, Payload, etc. The meaning of each field is shown in Table 3 below:

[0115] Table 3 Header of the topology keepalive request message

[0116]

[0117] Table 4 TOPO header of the topology keepalive request message

[0118]

[0119] As shown in Table 4, in the topology keep-alive request message, the TOPO message header consists of a total of 32 bytes, of which bytes 0-19 are currently used. Bytes 0-3 encapsulate the message type opcode, group identifier clique id, and status field. The value corresponding to the opcode can be 0x3, indicating that the message type is a keep-alive message (i.e., a topology keep-alive request message); bytes 4-7 encapsulate the node identifiers of the source GPU server and the target GPU server; bytes 8-11 encapsulate the device identifiers of the source GPU card and the target GPU card (i.e., the global number of the GPU card, which is unique); bytes 12-15 encapsulate the port number on the source GPU card and the target GPU card (i.e., the port identifier, which is unique within each GPU card); and bytes 16-19 are reserved fields. It should be noted that when GPU0 is the first device (i.e., the source device) and GPU9 is the destination device, the TOPO header encapsulates the src node id, src gpu id, src port id related to GPU0, and the dst node id, dst gpu id, and dst port id related to GPU9.

[0120] Step 450: Receive a topology keepalive response message forwarded by the switch, and parse the topology keepalive response message to obtain a keepalive status. The topology keepalive response message is replied to the switch by the target device based on the inspection result of the topology keepalive request message.

[0121] Specifically, for GPU0, each port with an established network connection will send a topology keepalive request message. This message will be unicast on the switch connected to the corresponding port, and the corresponding target device can receive the topology keepalive request message through the corresponding socket programming interface. After receiving the topology keepalive request message, the target device will perform a series of checks to confirm the legitimacy and validity of the message. For example, it can check whether the dst node ID in the message is consistent with the node ID of the server where the device (i.e., the GPU card) is located, check whether the src port ID in the message is consistent with the port ID of the local receiving port, and check whether the clique ID carried in the message is consistent with the clique ID of the device. If inconsistent, an alarm log will be generated to remind the user to check the network connection.

[0122] For another example, check the connection information in the message, that is, whether src [node id, gpu id, port id] - dst [node id, gpu id, port id] exists in the local machine. If not, fill the error information into the status field of the message.

[0123] If all fields in the topology keepalive request message are verified to be valid, the target device can respond with a topology keepalive response message to the switch in accordance with the protocol. A topology keepalive response message is a data packet in a specific format sent to the switch by the target device after receiving and checking the topology keepalive request message, in accordance with the protocol. The header of the topology keepalive response message is the same as that of the topology keepalive request message, but the opcode value encapsulated in the TOPO header is 0x4, indicating that the message type is a keep-alive response. The message also encapsulates its own clique ID and uses the socket programming interface to send the topology keepalive response message.

[0124] After receiving the topology keepalive response message from the target device, the switch forwards the response message to the first device, such as GPU 0. GPU 0 receives these response messages by monitoring and parses the status field in the message to determine whether the keepalive status is successful or failed.

[0125] Step 460: When the keep-alive state is failure, continue to send topology keep-alive request messages until the number of failures exceeds a threshold, and then resend the topology discovery request message.

[0126] Specifically, if the parsed status field is "success," the keepalive status is determined to be successful; otherwise, the keepalive status is determined to be failed. If this fails, the first device (e.g., GPU0) can continue to send topology keepalive request messages to the target device. If no successful response is received after sending the request message multiple times (e.g., three times), the keepalive status is ultimately determined to have failed, and an alarm log is generated. At this point, the first device can resend the topology discovery request message to attempt to reestablish a network connection with the target device.

[0127] Based on any of the above embodiments, the identification information includes a node identification, a device identification, and a port identification.

[0128] Specifically, identification information refers to a set of data that uniquely identifies a device or port on a network. This information can include node identifiers, device identifiers, and port identifiers. The node identifier is the unique number of the server node where the device resides, the device identifier is the globally unique number of the device within the cluster, and the port identifier is the locally unique number of each port on the device. Together, these identifiers form the device's unique identity, enabling each device on the network to be accurately identified and located.

[0129] Based on any of the above embodiments, Figure 5 This is the second flow chart of the network topology management method provided by the present invention, such as Figure 5 As shown, the method is applied to the second device, and the method includes:

[0130] Step 510: Receive a topology discovery request message broadcast by a switch. The topology discovery request message is sent by a first device to the switch upon receiving an instruction to start topology discovery. The first device is a device other than the second device connected to the switch in a southbound network. The southbound network includes multiple server nodes and multiple switches. Each server node is provided with at least one device, and each device is connected to at least one switch.

[0131] Step 520: Check the topology discovery request message, and if the check passes, reply a topology discovery response message to the switch, so that the switch forwards the topology discovery response message to the first device. The first device is used to parse the topology discovery response message and establish a network connection with the second device based on the identification information of the second device obtained by parsing and the local identification information to obtain the network topology information of the first device.

[0132] It should be noted that the execution subject of the method provided in the embodiment of the present invention is the second device, which refers to the device that receives the topology discovery request in the southbound network and replies to the response message. The first device refers to the device that is connected to the same switch as the second device and initiates the topology discovery request. The specific operations performed by the first device and the second device in the topology discovery process in the embodiment of the present invention can refer to the relevant embodiments of the topology discovery process when the first device is the execution subject in the above embodiment, and the embodiment of the present invention will not be repeated here.

[0133] In the method provided by an embodiment of the present invention, a first device can obtain identification information of a second device by sending a topology discovery request message, receiving a topology discovery response message, and parsing the topology discovery response message. Based on this information, the first device can establish a network connection with the second device to obtain network topology information of the first device. Since the southbound network includes multiple server nodes, each server node is equipped with at least one device, and each device can function as both a first device and a second device, the above steps can be used to collect the entire network topology information of the entire southbound network. Based on this network topology information, the southbound network can be managed and maintained. In addition, the first device automatically sends the topology discovery request message upon receiving a topology discovery start instruction, eliminating the need for manual configuration or network connection checking, thereby improving the efficiency and accuracy of network topology management. By broadcasting the topology discovery request message through the switch, it can cover every device connected to the switch in the network, ensuring the integrity of the network topology information. The topology discovery response message is sent by the second device in response to a successful check of the request message, thereby ensuring the compliance and validity of the network connection between the first and second devices.

[0134] Based on any of the above embodiments, in step 520, the checking of the topology discovery request message includes:

[0135] Step 521: parse the topology discovery request message to obtain the port identifier and group identifier of the source device.

[0136] Specifically, after receiving the topology discovery request message through the socket programming interface, the second device can parse the message to obtain various fields in the message, including the src port id, clique id, etc. Here, the src port id is the port identifier of the source device (i.e., the first device), and the clique id is the group identifier of the source device.

[0137] Step 522: Compare the port identifier of the source device with the local port identifier to obtain a first comparison result, and compare the group identifier of the source device with the local group identifier to obtain a second comparison result.

[0138] Step 523: If the first comparison result and the second comparison result are both consistent, it is determined that the check is passed; otherwise, an alarm log is generated.

[0139] Specifically, after parsing the corresponding fields in the message, the source device's port ID can be compared with the local port ID to determine whether the source port ID is consistent with the local receiving port's port ID, generating a first comparison result. If the first comparison result is inconsistent, an alarm log can be generated to remind the user to check the network connection. The main purpose of this is to ensure that all GPU cards with the same port ID are connected to the same switching network, facilitating cabling and troubleshooting network problems.

[0140] At the same time, the source device's group ID can be compared with the local device's group ID to check whether the clique ID in the message matches the local device's clique ID, obtaining a second comparison result. If the second comparison result is inconsistent, an alarm log is generated to remind the user to check the network connection and switch configuration, and the topology discovery request message is discarded. This is because only GPU cards with the same clique ID can communicate within the southbound network.

[0141] If the first comparison result and the second comparison result are consistent, it indicates that the inspection of each field in the topology discovery request message is passed. At this time, the second device can reply with a topology discovery response message according to the protocol requirements.

[0142] Based on any of the above embodiments, the method further includes:

[0143] Step 530: Receive a topology keepalive request message unicast by the switch, where the topology keepalive request message is sent by the first device to the switch when a network connection is established with the second device.

[0144] Step 540: Check the topology keep-alive request message, and based on the inspection result, reply a topology keep-alive response message to the switch, so that the switch forwards the topology keep-alive response message to the first device, and the first device is used to parse the topology keep-alive response message to obtain the keep-alive status.

[0145] It should be noted that, for the specific operations performed by the first device and the second device in the topology keep alive process in the embodiment of the present invention, reference can be made to the relevant embodiments of the topology keep alive process when the first device is the execution subject in the above embodiment, and the embodiments of the present invention will not be repeated here.

[0146] Based on any of the above embodiments, in step 540, the checking of the topology keepalive request message includes:

[0147] Step 541: parse the topology keepalive request message to obtain identification information of the source device, identification information of the target device, and the group identification of the source device.

[0148] Specifically, after receiving the topology keepalive request message through the socket programming interface, the second device can parse the message to obtain the fields in the message, including src node id, src gpu id, src port id, clique id, dst node id, dst gpu id, dst port id, etc. Here, src node id, src gpu id, and src port id are the identification information of the source device (i.e., the first device), dst node id, dst gpu id, and dst port id are the identification information of the target device, and clique id is the group identifier of the source device.

[0149] Step 542: Compare the node identifier in the identification information of the target device with the local node identifier to obtain a first result, compare the port identifier in the identification information of the source device with the local port identifier to obtain a second result, and compare the group identifier of the source device with the local group identifier to obtain a third result.

[0150] Step 543: If the first result, the second result, and the third result are all consistent, check whether the connection information exists locally. If so, determine that the keep-alive status is successful; otherwise, determine that the keep-alive status is failed. The connection information is determined based on the identification information of the source device and the identification information of the target device.

[0151] Step 544: If any one of the first result, the second result, and the third result is inconsistent, generate an alarm log.

[0152] Specifically, after parsing the corresponding fields in the message, the node ID of the target device can be compared with the node ID of the server, that is, checking whether the dst node ID is consistent with the node ID of the server, and obtaining a first result. If the first result is inconsistent, an alarm log is generated.

[0153] Secondly, the source device's port ID is compared with the local port ID, checking whether the source port ID matches the local receiving port's port ID to obtain a second result. If the first result is inconsistent, an alarm log can be generated to remind the user to check the network connection. The main purpose of this is to ensure that all GPU ports with the same port ID are connected to the same switching network, which facilitates cabling and troubleshooting of network problems.

[0154] At the same time, the source device's group ID is compared with the local device's group ID, checking whether the clique ID in the message matches the local device's clique ID, resulting in a third result. If the third result is inconsistent, an alarm log is generated to remind the user to check the network connection and switch configuration, and the topology keepalive request message is discarded. This is because only GPU cards with the same clique ID can communicate within the southbound network.

[0155] Additionally, the system checks whether the connection information in the message exists locally. This information includes the source device's identification information (src node ID, src GPU ID, src port ID) and the destination device's identification information (dst node ID, dst GPU ID, dst port ID). If not, an error message is entered into the status field of the request message. If all fields in the request message are valid, a topology keepalive response message is sent as required by the protocol.

[0156] Based on any of the above embodiments, Figure 6 This is a schematic diagram of topology discovery provided by the present invention, such as Figure 6 As shown in the figure, when the kernel-driven fabric-manager-thread module receives the start topology discovery command issued by the fabric-client service, it starts topology detection. The following takes GPU0 as an example. The specific steps are as follows:

[0157] In step A1, a raw socket is created in the kernel-driven fabric-manager-thread module, and a topology discovery request message is sent to each port of GPU0 while listening (to receive the topology discovery response message).

[0158] Specifically, each port of GPU0 (i.e., port0 to port7) can periodically (e.g., set to 1 second, or adjusted according to the performance requirements of topology convergence) call the socket programming interface sendto to send a broadcast message, i.e., send a discover request message (also called a topology discovery request message). This message will be broadcast on the southbound switch connected to the corresponding port, and other GPU cards connected to the same switch will receive the topology discovery request message. For example, Figure 6 As shown, for port 0 of GPU0, after it sends a discover request message, the message will be broadcast on the southbound switch switch0, that is, the southbound switch switch0 transparently transmits the discover request, so that other GPU cards connected to switch0 (i.e. Figure 6GPU1~GPU63 in the GPU card cluster shown in FIG receives the request message.

[0159] In step A2, after receiving the discover request message through the socket programming interface recvfrom, the other GPU checks whether each field in the message is legal.

[0160] Specifically, it checks whether the source port ID in the message matches the port ID of its receiving port, and whether the clique ID in the message matches the clique ID of its own GPU card. If they are inconsistent, an alarm log is generated to remind the user to check the network connection and switch configuration. If all fields are checked to be legal, it replies with a discover response message (i.e., a topology discovery response message) according to the protocol requirements, encapsulating its own source MAC address and clique ID, writing its own node ID, GPU ID, and port ID into the dst node ID, dst GPU ID, and dst port ID fields, and calls the socket programming interface to send the message.

[0161] In step A3, the switch transparently transmits all discover response messages to GPU0, that is, the switch forwards each topology discovery response message received to GPU0.

[0162] Step A4: GPU0 receives and parses the response message, and establishes a network connection based on the parsing result.

[0163] Specifically, after parsing, the DST information in the message (i.e., DST node ID, DST GPU ID, and DST port ID) is obtained. If the status field in the message is success, a complete connection is obtained: src [node ID, GPU ID, port ID] - dst [node ID, GPU ID, port ID]. Following the same logic, every GPU in the entire southbound network receives complete network topology information, recording the information of every GPU neighbor that can connect to it through the southbound switch. If the connection information in the topology discovery response message already exists locally, the message is discarded.

[0164] Based on any of the above embodiments, Figure 7 This is a schematic diagram of topology preservation provided by the present invention, such as Figure 7As shown in the figure, once the fabric-manager-thread module establishes a complete connection information, it can start the keep-alive process for this connection. The following takes GPU0 as an example to introduce it. The specific steps are as follows:

[0165] In step B1, a TCP socket is created in the kernel-driven fabric-manager-thread module for listening (to receive response messages), and a TCP connection is established with the neighbor (one TCP connection is sufficient between every two server nodes to help reduce resource consumption). A topology keepalive request message is sent based on each connection of GPU0.

[0166] Specifically, each port of GPU0 that has established a network connection can periodically (e.g., set to 3 seconds and adjusted according to the performance requirements of topology convergence) call the socket programming interface send to send a unicast message, that is, send a keep-alive request message (also called a topology keep-alive request message). The message encapsulates the src node id, src gpu id, srcport id of GPU0 and the dst node id, dst gpu id, and dst port id of the destination GPU. Figure 7 As shown in the figure, the topology keep-alive request message will be unicast on the southbound switch connected to the corresponding port, that is, the southbound switch transparently transmits the keep-alive request to the corresponding GPU card.

[0167] In step B2, after receiving the topology keep-alive request message through the socket programming interface read, the other GPUs check whether each field and connection information in the message are legal.

[0168] Specifically, the system checks whether the dst node ID in the message is consistent with the local node ID, the srcport ID in the message is consistent with the port ID of the receiving port, and the clique ID in the message is consistent with the clique ID of the GPU card. If they are inconsistent, an alarm log is generated to remind the user to check the network connection and switch configuration. Furthermore, it is necessary to check whether the connection information in the message exists on the local machine. If not, an error message is entered into the status field of the topology keepalive request message. If all fields are verified to be valid, the system replies with a keep-alive response message (i.e., a topology keepalive response message) according to the protocol requirements, encapsulating its own clique ID and calling the socket programming interface to send the response message.

[0169] In step B3, the switch transparently transmits all keep-alive response messages, that is, the switch forwards each topology keep-alive response message received to GPU0.

[0170] In step B4, GPU0 receives the response message and parses it, obtaining the status information in the message. If the status is success, the keepalive is successful; otherwise, the keepalive fails. If it fails, GPU0 continues to send keepalive requests. If it fails three times in a row, the keepalive is finally considered a failure and an alarm log is generated. GPU0 then attempts to reestablish the connection using a topology discovery request message.

[0171] This invention solves the topology management problem of southbound networks. Within the overall network management mechanism, it first implements unified allocation of global resources, such as node IDs and southbound network IP addresses, through management nodes. This also addresses single points of failure through distributed deployment. Then, by sending topology discovery request messages within the southbound network, all connections within the entire southbound network are collected, and connection information is maintained through topology keepalive request messages. This entire solution combines both functional considerations and maintainability.

[0172] The network topology management device provided by the present invention is described below. The network topology management device described below and the network topology management method described above can be referenced to each other.

[0173] Based on any of the above embodiments, Figure 8 This is one of the structural diagrams of the network topology management device provided by the present invention, such as Figure 8 As shown, the apparatus is applied to a first device, and the apparatus includes:

[0174] a sending unit 810 configured to, upon receiving a topology discovery start instruction, send a topology discovery request message to a switch, so that the switch broadcasts the topology discovery request message to a second device, where the second device is a device other than the first device connected to the switch in a southbound network, the southbound network including a plurality of server nodes and a plurality of switches, each server node being provided with at least one device, and each device being connected to at least one switch;

[0175] The receiving unit 820 is configured to receive a topology discovery response message forwarded by the switch, where the topology discovery response message is replied to the switch by the second device when checking the topology discovery request message.

[0176] The establishing unit 830 is configured to parse the topology discovery response message, and based on the identification information of the second device obtained by the parsing and the local identification information, establish a network connection with the second device to obtain the network topology information of the first device.

[0177] In an apparatus provided by an embodiment of the present invention, a first device can obtain identification information of a second device by sending a topology discovery request message, receiving a topology discovery response message, and parsing the topology discovery response message. Based on this information, the first device can establish a network connection with the second device to obtain network topology information of the first device. Since the southbound network includes multiple server nodes, each server node is provided with at least one device, and each device can function as both a first device and a second device, the above steps can be used to collect the entire network topology information of the entire southbound network. Based on this network topology information, the southbound network can be managed and maintained. In addition, the first device automatically sends the topology discovery request message upon receiving a topology discovery start instruction, eliminating the need for manual configuration or network connection checking, thereby improving the efficiency and accuracy of network topology management. By broadcasting the topology discovery request message through the switch, it can cover every device connected to the switch in the network, ensuring the integrity of the network topology information. The topology discovery response message is sent by the second device in response to a successful check of the request message, thereby ensuring the compliance and validity of the network connection between the first and second devices.

[0178] Based on any of the above embodiments, the device further includes:

[0179] a request sending unit, configured to send a topology keepalive request message to the switch based on the network topology information, so that the switch unicasts the topology keepalive request message to a target device, where the target device is a device among the second devices that establishes a network connection with the first device;

[0180] a response receiving unit, configured to receive a topology keepalive response message forwarded by the switch, and parse the topology keepalive response message to obtain a keepalive status, wherein the topology keepalive response message is replied to the switch by the target device based on a result of checking the topology keepalive request message;

[0181] The state judgment unit is configured to, when the keep-alive state is failure, continue to send the topology keep-alive request message until the number of failures exceeds a threshold, and then resend the topology discovery request message.

[0182] Based on any of the above embodiments, the identification information includes a node identification, a device identification, and a port identification.

[0183] Based on any of the above embodiments, Figure 9 This is the second structural diagram of the network topology management device provided by the present invention, such as Figure 9 As shown, the apparatus is applied to a second device, and the apparatus includes:

[0184] A message receiving unit 910 is configured to receive a topology discovery request message broadcast by a switch, wherein the topology discovery request message is sent by a first device to the switch upon receiving an instruction to start topology discovery, wherein the first device is a device other than the second device connected to the switch in a southbound network, wherein the southbound network includes multiple server nodes and multiple switches, each server node is provided with at least one device, and each device is connected to at least one switch;

[0185] The message reply unit 920 is used to check the topology discovery request message and, if the check passes, reply a topology discovery response message to the switch, so that the switch forwards the topology discovery response message to the first device. The first device is used to parse the topology discovery response message and establish a network connection with the second device based on the identification information of the second device obtained by parsing and the local identification information to obtain the network topology information of the first device.

[0186] In an apparatus provided by an embodiment of the present invention, a first device can obtain identification information of a second device by sending a topology discovery request message, receiving a topology discovery response message, and parsing the topology discovery response message. Based on this information, the first device can establish a network connection with the second device to obtain network topology information of the first device. Since the southbound network includes multiple server nodes, each server node is provided with at least one device, and each device can function as both a first device and a second device, the above steps can be used to collect the entire network topology information of the entire southbound network. Based on this network topology information, the southbound network can be managed and maintained. In addition, the first device automatically sends the topology discovery request message upon receiving a topology discovery start instruction, eliminating the need for manual configuration or network connection checking, thereby improving the efficiency and accuracy of network topology management. By broadcasting the topology discovery request message through the switch, it can cover every device connected to the switch in the network, ensuring the integrity of the network topology information. The topology discovery response message is sent by the second device in response to a successful check of the request message, thereby ensuring the compliance and validity of the network connection between the first and second devices.

[0187] Based on any of the above embodiments, the message reply unit 920 is specifically configured to:

[0188] Parsing the topology discovery request message to obtain a port identifier and a group identifier of the source device;

[0189] Comparing the port identifier of the source device with the local port identifier to obtain a first comparison result, and comparing the group identifier of the source device with the local group identifier to obtain a second comparison result;

[0190] If the first comparison result and the second comparison result are both consistent, it is determined that the check is passed; otherwise, an alarm log is generated.

[0191] Based on any of the above embodiments, the device further includes:

[0192] a request receiving unit, configured to receive a topology keepalive request message unicast by the switch, wherein the topology keepalive request message is sent by the first device to the switch when a network connection is established between the first device and the second device;

[0193] A response reply unit is used to check the topology keep-alive request message and, based on the inspection result, reply a topology keep-alive response message to the switch, so that the switch forwards the topology keep-alive response message to the first device, and the first device is used to parse the topology keep-alive response message to obtain a keep-alive status.

[0194] Based on any of the above embodiments, the response reply unit is specifically configured to:

[0195] Parsing the topology keepalive request message to obtain identification information of the source device, identification information of the target device, and a group identification of the source device;

[0196] Comparing the node identifier in the identification information of the target device with the local node identifier to obtain a first result, comparing the port identifier in the identification information of the source device with the local port identifier to obtain a second result, and comparing the group identifier of the source device with the local group identifier to obtain a third result;

[0197] If the first result, the second result, and the third result are all consistent, checking whether the connection information exists locally; if so, determining that the keep-alive state is successful; otherwise, determining that the keep-alive state is failed; the connection information is determined based on the identification information of the source device and the identification information of the target device;

[0198] When any one of the first result, the second result, and the third result is inconsistent, an alarm log is generated.

[0199] Figure 10 The following is an example of a physical structure diagram of a device, such as Figure 10As shown, the electronic device may include: a processor 1010 , a communication interface 1020 , a memory 1030 and a communication bus 1040 , wherein the processor 1010 , the communication interface 1020 , and the memory 1030 communicate with each other via the communication bus 1040 . The processor 1010 can call the logical instructions in the memory 1030 to execute a network topology management method, which is applied to a first device. The method includes: when receiving a start topology discovery instruction, sending a topology discovery request message to the switch so that the switch broadcasts the topology discovery request message to the second device, the second device being other devices other than the first device connected to the switch in the southbound network, the southbound network including multiple server nodes and multiple switches, each server node is provided with at least one device, and each device is connected to at least one switch; receiving a topology discovery response message forwarded by the switch, the topology discovery response message is replied to the switch by the second device when the topology discovery request message is checked and passed; parsing the topology discovery response message, and based on the identification information of the second device obtained by parsing and the local identification information, establishing a network connection with the second device to obtain the network topology information of the first device.

[0200] The processor 1010 can call the logical instructions in the memory 1030 to execute the network topology management method, which is applied to the second device, and the method includes: receiving a topology discovery request message broadcast by the switch, the topology discovery request message is sent by the first device to the switch when it receives an instruction to start topology discovery, the first device is other devices other than the second device connected to the switch in the southbound network, the southbound network includes multiple server nodes and multiple switches, each server node is provided with at least one device, and each device is connected to at least one switch; checking the topology discovery request message, and if the check passes, replying a topology discovery response message to the switch, so that the switch forwards the topology discovery response message to the first device, the first device is used to parse the topology discovery response message, and based on the identification information of the second device obtained by parsing and the local identification information, establish a network connection with the second device to obtain the network topology information of the first device.

[0201] Furthermore, the logic instructions in the aforementioned memory 1030 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the relevant art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0202] On the other hand, the present invention also provides a computer program product, which includes a computer program, which can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the network topology management method provided by the above methods. The method is applied to a first device, and the method includes: upon receiving an instruction to start topology discovery, sending a topology discovery request message to the switch so that the switch broadcasts the topology discovery request message to a second device, where the second device is a device other than the first device connected to the switch in a southbound network, and the southbound network includes multiple server nodes and multiple switches, each server node is provided with at least one device, and each device is connected to at least one switch; receiving a topology discovery response message forwarded by the switch, where the topology discovery response message is replied to the switch by the second device when the topology discovery request message is checked and passed; parsing the topology discovery response message, and based on the identification information of the second device obtained by parsing and the local identification information, establishing a network connection with the second device to obtain the network topology information of the first device.

[0203] When the computer program is executed by the processor, the computer can execute the network topology management method provided by the above methods, which is applied to the second device, and the method includes: receiving a topology discovery request message broadcast by the switch, the topology discovery request message is sent by the first device to the switch when it receives an instruction to start topology discovery, the first device is other devices connected to the switch in the southbound network except the second device, the southbound network includes multiple server nodes and multiple switches, each server node is provided with at least one device, and each device is connected to at least one switch; checking the topology discovery request message, and if the check passes, replying a topology discovery response message to the switch, so that the switch forwards the topology discovery response message to the first device, the first device is used to parse the topology discovery response message, and based on the identification information of the second device obtained by parsing and the local identification information, establish a network connection with the second device to obtain the network topology information of the first device.

[0204] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to execute the network topology management method provided by the above-mentioned methods, the method being applied to a first device, the method comprising: upon receiving an instruction to start topology discovery, sending a topology discovery request message to a switch so that the switch broadcasts the topology discovery request message to a second device, the second device being a device other than the first device connected to the switch in a southbound network, the southbound network comprising a plurality of server nodes and a plurality of switches, each server node being provided with at least one device, and each device being connected to at least one switch; receiving a topology discovery response message forwarded by the switch, the topology discovery response message being replied to the switch by the second device when the topology discovery request message is checked and passed; parsing the topology discovery response message, and establishing a network connection with the second device based on the identification information of the second device obtained by parsing and the local identification information, to obtain the network topology information of the first device.

[0205] When the computer program is executed by the processor, it is implemented to execute the network topology management method provided by the above-mentioned methods, which is applied to the second device, and the method includes: receiving a topology discovery request message broadcast by the switch, the topology discovery request message is sent by the first device to the switch when it receives an instruction to start topology discovery, the first device is other devices connected to the switch in the southbound network except the second device, the southbound network includes multiple server nodes and multiple switches, each server node is provided with at least one device, and each device is connected to at least one switch; checking the topology discovery request message, and if the check passes, replying a topology discovery response message to the switch, so that the switch forwards the topology discovery response message to the first device, the first device is used to parse the topology discovery response message, and based on the identification information of the second device obtained by parsing and the local identification information, establish a network connection with the second device to obtain the network topology information of the first device.

[0206] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiment. Persons of ordinary skill in the art will be able to understand and implement the present invention without inventive effort.

[0207] Through the description of the above embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using software plus a necessary general-purpose hardware platform, or of course, hardware. Based on this understanding, the essence of the above technical solution, or the portion that contributes to the relevant technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, or an optical disk, and includes a number of instructions for causing a computer device (such as a personal computer, server, or network device) to execute the methods described in each embodiment or certain portions of the embodiments.

[0208] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A network topology management method, characterized in that: The method is applied to a first device, and includes: Upon receiving a start topology discovery instruction, sending a topology discovery request message to the switch, so that the switch broadcasts the topology discovery request message to a second device, where the second device is a device other than the first device connected to the switch in a southbound network, the southbound network including a plurality of server nodes and a plurality of switches, each server node being provided with at least one device, each device being connected to at least one switch, and each device being capable of serving as both a first device and a second device; receiving a topology discovery response message forwarded by the switch, where the topology discovery response message is replied to the switch by the second device when checking the topology discovery request message and passing it; The topology discovery response message is parsed, and based on the identification information of the second device obtained by the analysis and the local identification information, a network connection is established with the second device to obtain the network topology information of the first device, where the network topology information refers to the information on the connection relationship between the first device and other devices in the southbound network.

2. The network topology management method according to claim 1, wherein: Also includes: Based on the network topology information, sending a topology keepalive request message to the switch, so that the switch unicasts the topology keepalive request message to a target device, where the target device is a device among the second devices that establishes a network connection with the first device; receiving a topology keepalive response message forwarded by the switch, and parsing the topology keepalive response message to obtain a keepalive status, wherein the topology keepalive response message is replied to the switch by the target device based on a result of checking the topology keepalive request message; When the keep-alive state is failure, the topology keep-alive request message continues to be sent until the number of failures exceeds a threshold, and then the topology discovery request message is resent.

3. The network topology management method according to claim 1 or 2, characterized in that: The identification information includes a node identification, a device identification, and a port identification.

4. A network topology management method, characterized in that: The method is applied to a second device, and includes: Receiving a topology discovery request message broadcast by a switch, where the topology discovery request message is sent by a first device to the switch upon receiving an instruction to start topology discovery, wherein the first device is a device other than the second device connected to the switch in a southbound network, the southbound network including multiple server nodes and multiple switches, each server node being provided with at least one device, each device being connected to at least one switch, and each device being capable of serving as both a first device and a second device; The topology discovery request message is checked, and if the check passes, a topology discovery response message is replied to the switch, so that the switch forwards the topology discovery response message to the first device. The first device is used to parse the topology discovery response message and establish a network connection with the second device based on the identification information of the second device obtained by parsing and the local identification information to obtain the network topology information of the first device. The network topology information refers to the information of the connection relationship between the first device and other devices in the southbound network.

5. The network topology management method according to claim 4, characterized in that: The checking of the topology discovery request message includes: Parsing the topology discovery request message to obtain a port identifier and a group identifier of the source device; Comparing the port identifier of the source device with the local port identifier to obtain a first comparison result, and comparing the group identifier of the source device with the local group identifier to obtain a second comparison result; If the first comparison result and the second comparison result are both consistent, it is determined that the check is passed; otherwise, an alarm log is generated.

6. The network topology management method according to claim 4, characterized in that: Also includes: receiving a topology keepalive request message unicast by the switch, where the topology keepalive request message is sent by the first device to the switch when a network connection is established between the first device and the second device; The topology keepalive request message is checked, and based on the check result, a topology keepalive response message is replied to the switch, so that the switch forwards the topology keepalive response message to the first device, and the first device is used to parse the topology keepalive response message to obtain the keepalive status.

7. The network topology management method according to claim 6, characterized in that: The checking of the topology keep-alive request message includes: Parsing the topology keepalive request message to obtain identification information of the source device, identification information of the target device, and a group identification of the source device; Comparing the node identifier in the identification information of the target device with the local node identifier to obtain a first result, comparing the port identifier in the identification information of the source device with the local port identifier to obtain a second result, and comparing the group identifier of the source device with the local group identifier to obtain a third result; If the first result, the second result, and the third result are all consistent, checking whether the connection information exists locally; if so, determining that the keep-alive state is successful; otherwise, determining that the keep-alive state is failed; the connection information is determined based on the identification information of the source device and the identification information of the target device; When any one of the first result, the second result, and the third result is inconsistent, an alarm log is generated.

8. An artificial intelligence device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, the network topology management method according to any one of claims 1 to 7 is implemented.

9. A network topology management system, characterized in that: The method comprises a management node, a plurality of server nodes, and a plurality of switches, wherein each server node is provided with at least one artificial intelligence device according to claim 8, each artificial intelligence device comprises at least one port, and each port is connected to a switch; The server node is used to obtain network topology information of each local artificial intelligence device and report the network topology information of each artificial intelligence device to the management node; The management node is used to obtain information about each switch based on the switch management network, and manage the network topology information of each artificial intelligence device and the information of each switch.

10. The network topology management system according to claim 9, characterized in that: The management node is also used to assign node identifiers to each server node and uniformly assign IP addresses to all ports of all artificial intelligence devices on all server nodes; The server node is further configured to generate a global device identifier for each artificial intelligence device based on the node identifier and the local device identifier of each artificial intelligence device.

11. The network topology management system according to claim 9, characterized in that: There are multiple management nodes.

12. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the network topology management method according to any one of claims 1 to 7 is implemented.

Images