A method, device, system and storage medium for physically servering a tube

Abstract

The application discloses a method, device and storage medium for incorporating a physical server, and is used for incorporating a physical server which has deployed an application into a cloud platform. The method for incorporating the physical server comprises the following steps: inputting physical server information; issuing the physical server information to a software-defined network (SDN) controller, the SDN controller listens to a link layer discovery protocol (LLDP) protocol data packet of the physical server; the physical server sends an LLDP message to a top-of-rack (TOR) switch; the TOR switch reports the LLDP message and corresponding port information to the SDN controller; and the SDN controller establishes a corresponding network according to the LLDP message and the corresponding port information. The application further provides a device for incorporating the physical server and a storage medium.

Description

Technical Field

[0001] This application relates to the field of computing technology, and in particular to a method, apparatus, system and storage medium for managing physical servers. Background Technology

[0002] Software-defined networking (SDN) is a novel network architecture that allows networks to be defined and controlled through software programming. It features a separation of control and forwarding planes and is open and programmable. SDN plays a crucial role in cloud-network convergence, providing a vital technological foundation. In cloud-network convergence scenarios, the SDN controller manages the cloud network, including both virtual and physical networks. However, due to historical reasons, some physical servers with deployed applications need to be managed by the cloud platform and interconnect with specific tenants' virtual networks. How to manage these physical servers with deployed applications on the cloud platform is a pressing issue that needs to be addressed. Summary of the Invention

[0003] To address the aforementioned technical issues, embodiments of this application provide a method, apparatus, and storage medium for managing physical servers, used to manage physical servers that have already been deployed and applied to a cloud platform.

[0004] In a first aspect, an embodiment of this application provides a method for managing physical servers, comprising:

[0005] Enter physical server information;

[0006] The physical server information is sent to the software-defined network virtual SDN controller, which listens for the Link Layer Discovery Protocol (LLDP) data packets of the physical server.

[0007] The physical server sends an LLDP message to the top-of-rack TOR switch;

[0008] The TOR switch reports the LLDP message and the corresponding port information to the SDN controller;

[0009] The SDN controller establishes the corresponding network based on the LLDP message and the corresponding port information.

[0010] The method of this invention records the information of the physical server into the cloud platform, and then establishes a corresponding network through a TOR switch and an SDN controller, thereby managing the physical server under the cloud platform.

[0011] Preferably, the physical server information entered includes:

[0012] Enter the physical server information into the preset cloud platform;

[0013] The physical server information includes one or a combination of the following:

[0014] The MAC address of the physical server's network interface card;

[0015] The system name of the physical server;

[0016] The IP address of the physical server.

[0017] The IP address of the physical server belongs to the same subnet as the IP addresses of the other virtual machines.

[0018] Preferably, the step of entering physical server information further includes:

[0019] Update the status of the physical server;

[0020] The physical server's status includes one of the following:

[0021] The entry status indicates that the physical server information has been entered.

[0022] The "distribution status" indicates that the physical server information has been distributed to the SDN controller.

[0023] The "offline" status indicates that no physical server was found in the network.

[0024] The "online" status indicates that the physical server is already in the network and the network has been created.

[0025] Preferably, the step of sending the physical server information to the software-defined networking (SDN) controller includes:

[0026] The pre-defined cloud platform sends the physical server information to the SDN controller through the northbound interface of the SDN.

[0027] Furthermore, after sending the physical server information to the SDN controller, the process also includes:

[0028] The cloud platform sets the physical server to a distribution state;

[0029] The SDN controller persists the physical server information to local storage and identifies the physical server as offline.

[0030] Preferably, the physical server sending LLDP messages to the top-of-rack TOR switch includes:

[0031] At a preset time and in a preset manner, the physical server is triggered to send an LLDP message to the TOR switch.

[0032] The preset method one includes one or a combination of the following:

[0033] Manually trigger the sending via command line;

[0034] Resend via operating system;

[0035] Send using a dedicated tool.

[0036] Preferably, the TOR switch reports the LLDP message and corresponding port information to the SDN controller, including:

[0037] The TOR switch receives the LLDP message and the corresponding port information;

[0038] The TOR switch reports the LLDP message and the corresponding port information to the SDN controller via a preset method two.

[0039] The preset method two includes one or a combination of the following:

[0040] Netconf (Network Configuration Protocol)

[0041] OpenFlow protocol.

[0042] Preferably, after the TOR switch reports the LLDP message and corresponding port information to the SDN controller, it further includes:

[0043] The TOR switch clears the LLDP protocol packets.

[0044] Preferably, the SDN controller establishes the corresponding network based on the LLDP message and the corresponding port information, including:

[0045] The SDN controller determines whether the physical server is a physical server that needs to be managed based on the LLDP message and the corresponding port information.

[0046] If the physical server is not required to be managed, then discard the LLDP message and the corresponding port information.

[0047] If the physical server needs to be managed, then the following steps should be taken:

[0048] The TOR switch and the port on which the LLDP message was reported were identified.

[0049] Update the topology of the subnet based on the tenant and subnet information of the physical server;

[0050] Based on the subnet topology, recalculate the communication paths for each node within the subnet.

[0051] Furthermore, after recalculating the communication paths of each node within the subnet based on the subnet's topology, the process further includes:

[0052] The recalculated communication path is then distributed to the network components;

[0053] The communication path includes:

[0054] The communication path between the virtual server and the physical server, virtual router, and virtual firewall.

[0055] Secondly, embodiments of this application also provide an apparatus for managing physical servers, comprising:

[0056] The data entry module is configured to enter physical server information on a preset cloud platform;

[0057] The sending module is configured to send the physical server information to the software-defined network virtual SDN controller, triggering the physical server to send LLDP packets to the top-of-rack TOR switch;

[0058] The management module establishes the corresponding network based on the LLDP message and the corresponding port information.

[0059] Thirdly, embodiments of this application also provide a system for managing physical servers, comprising:

[0060] Cloud platform, top-mounted TOR switch, defines the network virtual SDN controller;

[0061] The platform is configured to input physical server information, send the physical server information to the software-defined network virtual SDN controller, and trigger the physical server to send LLDP messages to the top-of-rack TOR switch.

[0062] The TOR switch is configured to receive LLDP packets sent by the physical server and report the LLDP packets and corresponding port information to the SDN controller.

[0063] The SDN controller is configured to listen for Link Layer Discovery Protocol (LLDP) packets from the physical server, receive LLDP messages and corresponding port information sent by the TOR switch, and establish a corresponding network based on the LLDP messages and corresponding port information.

[0064] Fourthly, embodiments of this application also provide an apparatus for managing physical servers, including: a memory, a processor, and a user interface;

[0065] The memory is used to store computer programs;

[0066] The user interface is used to interact with the user;

[0067] The processor is used to read a computer program from the memory, and when the processor executes the computer program, it implements the method for managing physical servers provided by the present invention.

[0068] Fifthly, embodiments of this application also provide a processor-readable storage medium storing a computer program, wherein when the processor executes the computer program, it implements the method for managing physical servers provided by the present invention.

[0069] The method of this invention involves inputting physical server information into a cloud platform. The cloud platform then distributes the physical server information and its associated network information to the SDN controller. The physical server sends LLDP packets to a TOR switch, which in turn reports the LLDP packets and corresponding port information to the SDN controller. The SDN controller parses the LLDP packets and port information to establish the corresponding network, thereby enabling the physical server to be managed by the cloud platform. Compared to manual input, this method offers advantages such as automatic discovery and automatic network configuration, flexible configuration, ease of application, and improved efficiency in physical server management. Attached Figure Description

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

[0071] Figure 1 This is a schematic diagram of the physical server management system structure involved in the embodiments of this application;

[0072] Figure 2 A flowchart illustrating the method for managing physical servers provided in this application embodiment. Figure 1 ;

[0073] Figure 3 A flowchart illustrating the method for managing physical servers provided in this application embodiment. Figure 2 ;

[0074] Figure 4 A schematic diagram of a device for managing physical servers provided in an embodiment of this application;

[0075] Figure 5 This application provides a schematic diagram of a managed physical server system.

[0076] Figure 6 This is a schematic diagram of another device structure for a managed physical server provided in an embodiment of this application. Detailed Implementation

[0077] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0078] The following are explanations of some of the words that appear in the text:

[0079] 1. In the embodiments of this invention, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0080] 2. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0081] Cloud-network convergence (Cloud-Network Convergence) is the integration of network technologies into cloud computing and cloud computing technologies into communication networks. The parallel driving forces of business needs and technological innovation are accelerating network architecture transformation, leading to a high degree of collaboration between the cloud and the network, moving beyond their independent operations. Cloud-network convergence has become a development trend in the cloud computing field. The implementation of cloud computing services requires robust network capabilities, and the optimization of network resources also needs to draw upon cloud computing principles; thus, the concept of cloud-network convergence has emerged. Cloud-network convergence is a conceptual model based on network architecture changes driven by parallel business needs and technological innovation, enabling a high degree of collaboration, mutual support, and mutual learning between the cloud and the network. It also requires the bearer network to open network capabilities on demand according to various cloud service requirements, achieving agile connectivity and on-demand interconnection between the network and the cloud, and exhibiting characteristics such as intelligence, self-service, high speed, and flexibility.

[0082] Software-Defined Networking (SDN) is a novel network architecture that allows networks to be defined and controlled through software programming. It features separation of the control plane and forwarding plane, as well as openness and programmability. Traditional networks are horizontally standardized and open, with each network element interconnecting with surrounding elements. In computers, not only is the horizontal direction standardized and open, but the vertical direction is also standardized and open, from bottom to top: hardware, drivers, operating systems, programming platforms, application software, etc., allowing programmers to easily create various applications. Vertically, networks are relatively closed and "unframeworked," making application creation and service deployment relatively difficult. However, SDN makes the entire network (not just network elements) open, standardized, and programmable in the vertical direction, making it easier and more efficient for people to use network resources. Therefore, SDN technology can effectively reduce device load, assist network operators in better controlling infrastructure, and reduce overall operating costs, making it one of the most promising network technologies.

[0083] In the process of cloud-network convergence, SDN plays a crucial network technology role, providing an important technological foundation for cloud-network convergence. In cloud-network convergence scenarios, the SDN controller manages the cloud network, including virtual networks and physical networks. Due to historical reasons, some physical servers with already deployed applications need to be managed by the cloud platform and need to communicate with specific tenants' virtual networks. How to manage these physical servers with already deployed applications on the cloud platform is a problem that urgently needs to be solved. To address the above technical problems, this invention provides a method that can efficiently manage physical servers on the cloud platform and connect tenant virtual networks and physical servers on demand.

[0084] like Figure 1 The diagram shows the physical server management system structure of the present invention. The physical servers requiring management are connected to the cloud-network converged server via a rack-mounted TOR switch. The TOR controller is connected to the SDN controller, and both the TOR controller and the SDN controller are connected to the cloud platform.

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

[0086] It should be noted that the order in which the embodiments of this application are presented only represents the chronological order of the embodiments and does not represent the superiority or inferiority of the technical solutions provided by the embodiments.

[0087] Example 1

[0088] See Figure 2 The present application provides a schematic diagram of a method for managing physical servers, as shown in the embodiment. Figure 2 As shown, the method includes steps S201 to S205:

[0089] S201. Enter physical server information;

[0090] As a preferred example, the physical server information is entered on a pre-defined cloud platform. The pre-defined cloud platform can be a pre-configured cloud platform, such as OpenStack.

[0091] In this embodiment, the physical server information includes one or a combination of the following:

[0092] The MAC address of the physical server's network interface card;

[0093] The system name of the physical server;

[0094] The IP address of the physical server.

[0095] It should be noted that, in order for the physical servers that need to be managed to communicate with the cloud-network converged server, the IP address of the physical server and the IP address of the other virtual machines must belong to the same subnet.

[0096] It should be noted that when the IP address of the physical server is in the same subnet as the IP addresses of other virtual machines, it means that the subnet segments are the same. For example, the subnet segments 10.0.0.0 to 10.0.0.8, 172.16.0.0 to 172.16.0.16, and 192.168.0.0 to 92.168.0.24 are all in the same subnet.

[0097] As a preferred example, entering physical server information also includes updating the physical server's status, that is, it also includes:

[0098] Update the status of the physical server;

[0099] The physical server's status includes one of the following:

[0100] The entry status indicates that the physical server information has been entered.

[0101] The "distribution status" indicates that the physical server information has been distributed to the SDN controller.

[0102] The "offline" status indicates that no physical server was found in the network.

[0103] The "online" status indicates that the physical server is already in the network and the network has been created.

[0104] In this step, for physical servers with applications already installed, the MAC address, system name, and IP address of the physical server's network card can be obtained through predefined network commands or automated tools. For communication with other virtual machines in the virtual network, the IP addresses must belong to the same subnet. The MAC address and system name of the physical server are entered into the cloud platform, and the subnet of the tenant to which the physical server belongs is specified. Preferably, the managed status of the physical server can be categorized into: entered, distributed, offline, and online, where:

[0105] Entry status: Indicates that the physical server information has been entered;

[0106] Distribution status: Indicates that the physical server has distributed the data to the SDN controller;

[0107] Not online: This means that no physical server was found on the network.

[0108] "Online" status: This indicates that the physical server is already in the network and the network has been created.

[0109] S202. The physical server information is sent to the software-defined network virtual SDN controller, and the SDN controller listens for the Link Layer Discovery Protocol (LLDP) data packets of the physical server.

[0110] As a preferred example, the step of sending the physical server information to the software-defined networking virtual SDN controller includes:

[0111] The pre-defined cloud platform sends the physical server information to the SDN controller through the northbound interface of the SDN.

[0112] Furthermore, after the physical server information is sent to the SDN controller, the process further includes: the cloud platform setting the physical server to a sending state; and the SDN controller persisting the physical server information to local storage and marking the physical server as offline.

[0113] In this step, the cloud platform distributes physical server information to the SDN controller via the SDN's northbound interface. This information includes at least one or a combination of the following: MAC address, system name, tenant, or subnet. The platform then sets this physical server to the "distributed" state. The SDN controller persists the physical server information to local storage, marks the physical server as offline, and begins listening for LLDP protocol packets from this physical server.

[0114] S203. The physical server sends an LLDP message to the top-of-rack TOR switch.

[0115] As a preferred example, the physical server sending LLDP messages to the top-of-rack TOR switch includes:

[0116] At a preset time and in a preset manner, the physical server is triggered to send an LLDP message to the TOR switch.

[0117] The preset method one includes one or a combination of the following:

[0118] Manually trigger the sending via command line;

[0119] Resend via operating system;

[0120] Send using a dedicated tool.

[0121] As a preferred example, the preset time refers to the time for sending LLDP protocol data packets, which can be customized as needed; the present invention does not limit the specific time.

[0122] In this step, the physical server needs to connect to the TOR switch port managed by the SDN controller. The physical server can send LLDP protocol packets in various ways, but the packets must include the network interface card (NIC) MAC address and system name. Sending methods include manual sending via command line, sending via a new operating system installation, or sending via a dedicated tool. The timing of sending LLDP protocol packets can be customized as needed. This approach avoids reinstalling various software on the physical server, including the operating system, middleware, and applications, maximizing the reuse of existing resources while offering flexibility and on-demand deployment advantages.

[0123] S204. The TOR switch reports the LLDP message and the corresponding port information to the SDN controller;

[0124] As a preferred example, the TOR switch reports the LLDP message and corresponding port information to the SDN controller, including:

[0125] The TOR switch receives the LLDP message and the corresponding port information;

[0126] The TOR switch reports the LLDP message and the corresponding port information to the SDN controller via a preset method two.

[0127] The preset method two includes one or a combination of the following:

[0128] Netconf (Network Configuration Protocol)

[0129] OpenFlow protocol.

[0130] Furthermore, after the TOR switch reports the LLDP message and corresponding port information to the SDN controller, it also includes:

[0131] The TOR switch clears the LLDP protocol packets.

[0132] In other words, in this step, the TOR switch can recognize the LLDP protocol and record the port from which LLDP protocol packets are received. The SDN controller receives LLDP protocol packets by configuring the TOR switch to report the LLDP protocol. The TOR switch port is connected to the physical server. When it receives LLDP protocol packets from the physical server, the TOR switch recognizes them and reports the LLDP protocol packets, along with the input switch information and switch port information, to the SDN controller. The SDN controller and the TOR switch can interact through various protocols, including but not limited to netconf and OpenFlow. The TOR switch does not cache LLDP protocol packets; these packets can be cleared after being reported to the SDN controller.

[0133] S205. The SDN controller establishes the corresponding network based on the LLDP message and the corresponding port information.

[0134] As a preferred example, the SDN controller establishes the corresponding network based on the LLDP message and the corresponding port information, including:

[0135] The SDN controller updates the topology of the subnet based on the tenant and subnet information to which the physical server belongs; and recalculates the communication paths of each node within the subnet based on the subnet topology.

[0136] The method described in this embodiment involves inputting physical server information into a cloud platform. The cloud platform then distributes the physical server information and its associated network information to the SDN controller. The physical server sends LLDP packets to a TOR switch, which in turn reports the LLDP packets and corresponding port information to the SDN controller. The SDN controller parses the LLDP packets and port information to establish the corresponding network, thereby enabling the physical server to be managed by the cloud platform. Compared to manual input, this method offers advantages such as automatic discovery and automatic network configuration, flexible configuration, ease of application, and improved efficiency in managing physical servers.

[0137] Example 2

[0138] Based on the same inventive concept, embodiments of the present invention also provide a method for managing physical servers, such as... Figure 3 As shown, the method includes:

[0139] S301. Enter physical server information;

[0140] As a preferred example, the physical server information is entered on a pre-defined cloud platform. The pre-defined cloud platform can be a pre-configured cloud platform, such as OpenStack.

[0141] In this embodiment, the physical server information includes one or a combination of the following:

[0142] The MAC address of the physical server's network interface card;

[0143] The system name of the physical server;

[0144] The IP address of the physical server.

[0145] It should be noted that, in order for the physical servers that need to be managed to communicate with the cloud-network converged server, the IP address of the physical server and the IP address of the other virtual machines must belong to the same subnet.

[0146] As a preferred example, entering physical server information also includes updating the physical server's status, that is, it also includes:

[0147] Update the status of the physical server;

[0148] The physical server's status includes one of the following:

[0149] The entry status indicates that the physical server information has been entered.

[0150] The "distribution status" indicates that the physical server information has been distributed to the SDN controller.

[0151] The "offline" status indicates that no physical server was found in the network.

[0152] The "online" status indicates that the physical server is already in the network and the network has been created.

[0153] The method for this step is the same as S201, and will not be repeated here.

[0154] S302. The physical server information is sent to the software-defined network virtual SDN controller, and the SDN controller listens for the Link Layer Discovery Protocol (LLDP) data packets of the physical server.

[0155] Specifically, the step of sending the physical server information to the software-defined networking (SDN) controller includes:

[0156] The pre-defined cloud platform sends the physical server information to the SDN controller through the northbound interface of the SDN.

[0157] Specifically, after the physical server information is sent to the SDN controller, the process further includes: the cloud platform setting the physical server to a sending state; and the SDN controller persisting the physical server information to local storage and marking the physical server as offline.

[0158] The method for this step is the same as S202, and will not be repeated here.

[0159] S303, The physical server sends an LLDP message to the top-of-rack TOR switch;

[0160] Specifically, the physical server sending LLDP messages to the top-of-rack TOR switch includes:

[0161] At a preset time and in a preset manner, the physical server is triggered to send an LLDP message to the TOR switch.

[0162] The preset method one includes one or a combination of the following:

[0163] Manually trigger the sending via command line;

[0164] Resend via operating system;

[0165] Send using a dedicated tool.

[0166] Specifically, the preset time refers to the time for sending LLDP protocol data packets, which can be customized as needed; however, this invention does not impose any specific limitations.

[0167] This step is the same as S203, and will not be repeated here.

[0168] S304. The TOR switch reports the LLDP message and the corresponding port information to the SDN controller.

[0169] Specifically, the TOR switch reports the LLDP message and corresponding port information to the SDN controller, including:

[0170] The TOR switch receives the LLDP message and the corresponding port information;

[0171] The TOR switch reports the LLDP message and the corresponding port information to the SDN controller via a preset method two.

[0172] The preset method two includes one or a combination of the following:

[0173] Netconf (Network Configuration Protocol)

[0174] OpenFlow protocol.

[0175] Furthermore, after the TOR switch reports the LLDP message and corresponding port information to the SDN controller, it also includes:

[0176] The TOR switch clears the LLDP protocol packets.

[0177] This step is the same as S204, and will not be repeated here.

[0178] S305. The SDN controller establishes the corresponding network based on the LLDP message and the corresponding port information.

[0179] The SDN controller establishes the corresponding network based on the LLDP message and the corresponding port information, including:

[0180] The SDN controller updates the topology of the subnet based on the tenant and subnet information to which the physical server belongs; and recalculates the communication paths of each node within the subnet based on the subnet topology.

[0181] S306: Determine if the server is a physical server that needs to be managed. If yes, proceed to S308; otherwise, proceed to S307.

[0182] As a preferred example, a method for determining whether a physical server needs to be managed could be:

[0183] 1. Based on the MAC address information in the LLDP message, if the MAC address information is within the range of the input server, then the network of that server needs to be created;

[0184] 2. Based on the hostname information in the LLDP message, if the hostname information is within the range of the entered server, then the network for that server needs to be created;

[0185] 3. Based on the IP address information in the LLDP message, if the IP address information is within the range of the input server, then the network of that server needs to be created.

[0186] S307, Discard the LLDP message and the corresponding port information.

[0187] In other words, if the physical server is not required to be managed, the LLDP message and the corresponding port information are discarded.

[0188] S308, analyze the TOR switch and the port on which the LLDP message was reported;

[0189] If the physical server needs to be managed, the TOR switch and the port reported by the LLDP message are analyzed, and S309 is executed.

[0190] S309, Update the topology of the subnet according to the tenant and subnet information to which the physical server belongs.

[0191] S310, based on the subnet topology, recalculate the communication paths of each node within the subnet.

[0192] Furthermore, after recalculating the communication paths of each node within the subnet based on the subnet's topology, the process further includes:

[0193] The recalculated communication path is then distributed to the network components;

[0194] The communication path includes:

[0195] The communication path between the virtual server and the physical server, virtual router, and virtual firewall.

[0196] In this embodiment of the invention, starting from step S305, after the SDN controller receives the LLDP protocol data packet reported by the TOR switch, it needs to parse the content of the LLDP protocol data packet, including the MAC address of the physical server's network card and the system name. The SDN controller analyzes the above two pieces of information to determine whether it is a physical server that needs to be managed. If not, the LLDP packet is discarded. If it is, the TOR switch and the port reported by the LLDP packet need to be analyzed. At the same time, the topology of this subnet is updated according to the tenant and subnet information to which the physical server belongs. Based on the subnet topology, the communication paths of each node in the subnet are recalculated, including virtual servers and physical servers, virtual routers, virtual firewalls, and other nodes. Finally, the updated communication paths are distributed to various network components, thereby realizing the interconnection between the physical server and the tenant subnet.

[0197] Example 3

[0198] Based on the same inventive concept, embodiments of the present invention also provide a device for managing physical servers, such as... Figure 4 As shown, the device includes:

[0199] The data entry module 401 is configured to enter physical server information on a preset cloud platform;

[0200] Sending module 402 is configured to send the physical server information to the software-defined network virtual SDN controller, triggering the physical server to send LLDP packets to the top-of-rack TOR switch;

[0201] The management module 403 establishes a corresponding network based on the LLDP message and the corresponding port information.

[0202] As a preferred example, the data entry module 401 is also configured to enter the physical server information on a preset cloud platform;

[0203] The physical server information includes one or a combination of the following:

[0204] The MAC address of the physical server's network interface card;

[0205] The system name of the physical server;

[0206] The IP address of the physical server.

[0207] Preferably, the IP address of the physical server belongs to the same subnet as the IP addresses of the other virtual machines.

[0208] As a preferred example, the data entry module 401 is also configured to update the status of the physical server;

[0209] The physical server's status includes one of the following:

[0210] The entry status indicates that the physical server information has been entered.

[0211] The "distribution status" indicates that the physical server information has been distributed to the SDN controller.

[0212] The "offline" status indicates that no physical server was found in the network.

[0213] The "online" status indicates that the physical server is already in the network and the network has been created.

[0214] As a preferred example, the sending module 402 is also configured to send the physical server information to the SDN controller via the northbound interface of the SDN through a preset cloud platform.

[0215] As a preferred example, after sending the physical server information to the SDN controller, the method further includes:

[0216] The cloud platform sets the physical server to a distribution state;

[0217] The SDN controller persists the physical server information to local storage and identifies the physical server as offline.

[0218] As a preferred example, the sending module 402 is also configured to trigger the physical server to send an LLDP message to the TOR switch at a preset time and in a preset manner.

[0219] The preset method one includes one or a combination of the following:

[0220] Manually trigger the sending via command line;

[0221] Resend via operating system;

[0222] Send using a dedicated tool.

[0223] As a preferred example, the management module 403 is also configured to establish a corresponding network based on the LLDP message and the corresponding port information:

[0224] The SDN controller determines whether the physical server is a physical server that needs to be managed based on the LLDP message and the corresponding port information.

[0225] If the physical server is not required to be managed, then discard the LLDP message and the corresponding port information.

[0226] If the physical server needs to be managed, then the following steps should be taken:

[0227] The TOR switch and the port on which the LLDP message was reported were identified.

[0228] Update the topology of the subnet based on the tenant and subnet information of the physical server;

[0229] Based on the subnet topology, recalculate the communication paths for each node within the subnet.

[0230] After recalculating the communication paths of each node within the subnet based on the subnet's topology, the process further includes:

[0231] The recalculated communication path is then distributed to the network components;

[0232] The communication path includes:

[0233] The communication path between the virtual server and the physical server, virtual router, and virtual firewall.

[0234] It should be noted that the device provided in Embodiment 3 belongs to the same inventive concept as the methods provided in Embodiments 1 and 2, solves the same technical problem, and achieves the same technical effect. The device provided in Embodiment 3 can implement all the methods in Embodiments 1 and 2, and the similarities will not be repeated.

[0235] Example 4

[0236] Based on the same inventive concept, embodiments of the present invention also provide a system for managing physical servers, such as... Figure 5 As shown, the device includes:

[0237] Cloud platform 501, rack-top TOR switch 502, network virtual SDN controller 503;

[0238] The platform is configured to input physical server information, send the physical server information to the software-defined network virtual SDN controller, and trigger the physical server to send LLDP messages to the top-of-rack TOR switch.

[0239] The TOR switch is configured to receive LLDP packets sent by the physical server and report the LLDP packets and corresponding port information to the SDN controller.

[0240] The SDN controller is configured to listen for Link Layer Discovery Protocol (LLDP) packets from the physical server, receive LLDP messages and corresponding port information sent by the TOR switch, and establish a corresponding network based on the LLDP messages and corresponding port information.

[0241] exist Figure 5 In this context, the physical server is a pre-managed server that has a network connection to the cloud platform 501 and the TOR switch 502. The IP address of the physical server belongs to the same subnet as the IP addresses of the other virtual machines.

[0242] As a preferred example, the physical server information entered by the cloud platform 501 includes one or a combination of the following:

[0243] The MAC address of the physical server's network interface card;

[0244] The system name of the physical server;

[0245] The IP address of the physical server.

[0246] As a preferred example, the cloud platform 501 is also configured to update the status of the physical server;

[0247] The physical server's status includes one of the following:

[0248] The entry status indicates that the physical server information has been entered.

[0249] The "distribution status" indicates that the physical server information has been distributed to the SDN controller.

[0250] The "offline" status indicates that no physical server was found in the network.

[0251] The "online" status indicates that the physical server is already in the network and the network has been created.

[0252] As a preferred example, the cloud platform 501 is also configured to send the physical server information to the SDN controller via the northbound interface of the SDN.

[0253] As a preferred example, the cloud platform 501 is further configured to set the physical server to a distribution state after the physical server information is sent to the SDN controller;

[0254] The SDN controller persists the physical server information to local storage and identifies the physical server as offline.

[0255] As a preferred example, the cloud platform 501 is also configured to trigger the physical server to send an LLDP message to the TOR switch at a preset time and in a preset manner.

[0256] The preset method one includes one or a combination of the following:

[0257] Manually trigger the sending via command line;

[0258] Resend via operating system;

[0259] Send using a dedicated tool.

[0260] As a preferred example, the TOR switch 502 is also configured to receive the LLDP message and the corresponding port information;

[0261] The LLDP message and corresponding port information are reported to the SDN controller using a preset method two.

[0262] The preset method two includes one or a combination of the following:

[0263] Netconf (Network Configuration Protocol)

[0264] OpenFlow protocol.

[0265] After the TOR switch 502 reports the LLDP message and corresponding port information to the SDN controller, it also includes:

[0266] The TOR switch clears the LLDP protocol packets.

[0267] As a preferred example, the SDN controller 503 is also configured to establish a corresponding network based on the LLDP message and the corresponding port information:

[0268] The SDN controller determines whether the physical server is a physical server that needs to be managed based on the LLDP message and the corresponding port information.

[0269] If the physical server is not required to be managed, then discard the LLDP message and the corresponding port information.

[0270] If the physical server needs to be managed, then the following steps should be taken:

[0271] The TOR switch and the port on which the LLDP message was reported were identified.

[0272] Update the topology of the subnet based on the tenant and subnet information of the physical server;

[0273] Based on the subnet topology, recalculate the communication paths for each node within the subnet.

[0274] As a preferred example, the SDN controller 503 is further configured to recalculate the communication paths of each node within the subnet according to the subnet topology, and then distribute the recalculated communication paths to network components; wherein the communication paths include: communication paths between virtual servers and physical servers, virtual routers, and virtual firewalls.

[0275] It should be noted that the system provided in Embodiment 4 belongs to the same inventive concept as the methods provided in Embodiments 1 and 2, solves the same technical problem, and achieves the same technical effect. The system provided in Embodiment 4 can implement all the methods in Embodiments 1 and 2, and the similarities will not be repeated.

[0276] Example 5

[0277] Based on the same inventive concept, embodiments of the present invention also provide a device for managing physical servers, such as... Figure 6 As shown, the device includes:

[0278] It includes a memory 602, a processor 601, and a user interface 603;

[0279] The memory 602 is used to store computer programs;

[0280] The user interface 603 is used to interact with the user.

[0281] The processor 601 is configured to read a computer program from the memory 602, and when the processor 601 executes the computer program, it performs the following:

[0282] Enter physical server information;

[0283] The physical server information is sent to the software-defined network virtual SDN controller, which listens for the Link Layer Discovery Protocol (LLDP) data packets of the physical server.

[0284] The physical server sends an LLDP message to the top-of-rack TOR switch;

[0285] The TOR switch reports the LLDP message and the corresponding port information to the SDN controller;

[0286] The SDN controller establishes the corresponding network based on the LLDP message and the corresponding port information.

[0287] Among them, Figure 6 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 601) and memory (memory 602). The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides the interface. Processor 601 is responsible for managing the bus architecture and general processing, and memory 602 can store data used by processor 601 during operation.

[0288] The processor 601 can be a CPU, ASIC, FPGA or CPLD, and the processor 601 can also adopt a multi-core architecture.

[0289] When processor 601 executes a computer program stored in memory 602, it implements the method of any of the managed physical servers in Embodiment 1.

[0290] It should be noted that the device provided in Embodiment 3 and the method provided in Embodiment 1 belong to the same inventive concept, solve the same technical problem, and achieve the same technical effect. The device provided in Embodiment 3 can implement all the methods in Embodiment 1, and the similarities will not be repeated.

[0291] This application also proposes a processor-readable storage medium. This processor-readable storage medium stores a computer program, which, when executed by a processor, implements the method for any of the managed physical servers described in Embodiment 1.

[0292] It should be noted that the division of units in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0293] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0294] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0295] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0296] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for nanotube physical server, characterized in that ,include: Enter physical server information; The physical server information is sent to the software-defined network virtual SDN controller, which listens for Link Layer Discovery Protocol (LLDP) packets from the physical server. The physical server sends an LLDP message to the top-of-rack TOR switch; The TOR switch reports the LLDP message and the corresponding port information to the SDN controller; The SDN controller establishes the corresponding network based on the LLDP message and the corresponding port information; The SDN controller establishes the corresponding network based on the LLDP message and the corresponding port information, including: The SDN controller determines whether the physical server is a physical server that needs to be managed based on the LLDP message and the corresponding port information; If the physical server is not required to be managed, then discard the LLDP message and the corresponding port information; If the physical server needs to be managed, the following steps should be taken: The TOR switch and the port on which the LLDP message was reported were identified. Update the subnet topology based on the tenant and subnet information of the physical server; Based on the subnet topology, recalculate the communication paths for each node within the subnet; The recalculated communication path is then distributed to the network components. The communication path includes: The communication path between the virtual server and the physical server, virtual router, and virtual firewall; The physical server information to be entered includes: Enter the physical server information into the preset cloud platform; The physical server information includes one or a combination of the following: The MAC address of the physical server's network interface card; The system name of the physical server; The IP address of the physical server; The IP address of the physical server belongs to the same subnet as the IP addresses of the other virtual machines. The entered physical server information also includes: Update the status of the physical server; The status of the physical server includes one of the following: The entry status indicates that the physical server information has been entered. The "distribution status" indicates that the physical server information has been distributed to the SDN controller. The "offline" status indicates that no physical server was found in the network. The "online" status indicates that the physical server is already in the network and the network has been created. The step of sending the physical server information to the software-defined networking (SDN) controller includes: The pre-defined cloud platform sends the physical server information to the SDN controller through the northbound interface of the SDN; After the physical server information is sent to the SDN controller, the process further includes: The cloud platform sets the physical server to a distribution state; The SDN controller persists the physical server information to local storage and identifies the physical server as offline.

2. The method of claim 1, wherein The physical server sends LLDP messages to the top-of-rack TOR switch, including: At a preset time and in a preset manner, the physical server is triggered to send an LLDP message to the TOR switch. The preset method one includes one or a combination of the following: Manually trigger the sending via command line; Resend the operating system.

3. The method of claim 1, wherein The TOR switch reports the LLDP message and corresponding port information to the SDN controller, including: The TOR switch receives the LLDP message and the corresponding port information; The TOR switch reports the LLDP message and corresponding port information to the SDN controller via a preset method two. The preset method two includes one or a combination of the following: Network configuration protocol Netconf; OpenFlow protocol; After the TOR switch reports the LLDP message and corresponding port information to the SDN controller, it also includes: The TOR switch clears the LLDP protocol packets.

4. An apparatus for virtual pipe physical server, characterized by ,include: The data entry module is configured to enter physical server information on a preset cloud platform; The sending module is configured to send the physical server information to the software-defined network virtual SDN controller, triggering the physical server to send LLDP packets to the top-of-rack TOR switch; The management module establishes the corresponding network based on the LLDP message and the corresponding port information; The establishment of the corresponding network by the LLDP message and the corresponding port information includes: The SDN controller determines whether the physical server is a physical server that needs to be managed based on the LLDP message and the corresponding port information; If the physical server is not required to be managed, then discard the LLDP message and the corresponding port information; If the physical server needs to be managed, the following steps should be taken: The TOR switch and the port on which the LLDP message was reported were identified. Update the subnet topology based on the tenant and subnet information of the physical server; Based on the subnet topology, recalculate the communication paths for each node within the subnet; The recalculated communication path is then distributed to the network components. The communication path includes: The communication path between the virtual server and the physical server, virtual router, and virtual firewall.

5. A system for nanotube physical server, characterized by ,include: Cloud platform, top-mounted TOR switch, defines the network virtual SDN controller; The platform is configured to input physical server information, distribute the physical server information to the software-defined network virtual SDN controller, and trigger the physical server to send LLDP packets to the top-of-rack TOR switch; The TOR switch is configured to receive LLDP packets sent by the physical server and report the LLDP packets and corresponding port information to the SDN controller. The SDN controller is configured to listen for Link Layer Discovery Protocol (LLDP) packets from the physical server, receive LLDP messages and corresponding port information sent by the TOR switch, and establish a corresponding network based on the LLDP messages and corresponding port information. The establishment of the corresponding network by the LLDP message and the corresponding port information includes: The SDN controller determines whether the physical server is a physical server that needs to be managed based on the LLDP message and the corresponding port information; Discarding the LLDP packet and corresponding port information if the physical server is not required to be managed; If the physical server is required to be managed, the following processing is performed: Analyzing the TOR switch and the port reported by the LLDP packet; Updating the topology of the subnet according to the tenant and subnet information to which the physical server belongs; Recomputing the communication path of each node in the subnet according to the topology of the subnet; Downloading the recomputed communication path to the network component; The communication path includes: The communication path between the virtual server, the physical server, the virtual router and the virtual firewall.

6. An apparatus for virtual pipe physical server, characterized by , including a memory, a processor and a user interface; The memory is used to store a computer program; The user interface is used to interact with the user; The processor is used to read the computer program in the memory, and the processor executes the computer program to implement the method for managing the physical server according to any one of claims 1 to 3.

7. A processor-readable storage medium, comprising: The processor readable storage medium stores a computer program, and the processor executes the computer program to implement the method for managing the physical server according to any one of claims 1 to 3.

Images