A network configuration method and public cloud system based on hybrid cloud scenarios

Abstract

This application discloses a network configuration method and a public cloud system based on a hybrid cloud scenario, which can improve the tenant experience to a certain extent. The method includes: a tenant sending a network configuration request to a cloud management platform, which requests network configuration for a first server that does not belong to the public cloud system. Based on this request, the cloud management platform configures a first TOR switch and a gateway for the first server. The first TOR switch records forwarding rules, which instruct the first TOR switch to send packets with the destination address being the IP address of the cloud server in the public cloud system to the gateway. When the first TOR switch receives a first packet with the destination address being the IP address of the cloud server sent by the first server, the first TOR switch generates a first overlay packet with the first packet as the inner packet and sends the first overlay packet to the gateway, so that the gateway can send the first packet of the first overlay packet to the cloud server.

Description

Technical Field

[0001] This application relates to the field of cloud technology, and in particular to a network configuration method and a public cloud system based on a hybrid cloud scenario. Background Technology

[0002] With the rapid development of cloud technology, tenants can host their own servers with cloud providers, thus enabling tenants to migrate their servers to the cloud. Based on this, tenants' servers can communicate with cloud servers in the cloud through the network built by the cloud provider, allowing tenants to enjoy various cloud services provided by the cloud servers.

[0003] In related technologies, when a tenant migrates multiple servers to the cloud, each server is connected to its own smart network interface card (NIC). These NICs are equipped with virtualization software, which enables the servers to access cloud servers. This allows the tenant to utilize 100% of the physical resources of these servers, such as processors and memory, thereby improving resource utilization.

[0004] However, for these multiple servers, the forwarding bandwidth of the connected smart network cards is often limited, which means that the server's inbound and outbound traffic is restricted by the forwarding bandwidth of the smart network cards. In some high-traffic scenarios, the smart network cards cannot meet the server's traffic forwarding requirements, thus failing to meet the tenant's business needs and resulting in a poor tenant experience. Summary of the Invention

[0005] This application provides a network configuration method and public cloud system based on a hybrid cloud scenario, which can meet the traffic forwarding requirements of the server, thereby meeting the business needs of the tenant and improving the tenant experience to a certain extent.

[0006] A first aspect of this application provides a network configuration method based on a hybrid cloud scenario. The public cloud system implementing this method includes infrastructure providing cloud services to tenants and a cloud management platform managing this infrastructure. This infrastructure may include cloud servers. The method includes:

[0007] When a tenant needs to bring a primary server that is not part of a public cloud system to the cloud, the tenant can submit a network configuration request to the network configuration interface provided by the cloud management platform. In this way, the cloud management platform can receive the network configuration request sent by the tenant through the network configuration interface, and the network configuration request can be used to request the cloud management platform to configure the network for the primary server.

[0008] Upon receiving a network configuration request, the cloud management platform can configure a first TOR switch and a gateway for the first server. The first end of the first TOR switch is connected to the first server, and the second end of the first TOR switch is connected to the gateway. After configuration, the first TOR switch records forwarding rules, which are used to instruct the first TOR switch to send packets with the destination address being the IP address of the cloud server to the gateway.

[0009] When the first server needs to access the cloud server, it can send a first packet with the cloud server's IP address as the destination address to the first TOR switch. Since the first TOR switch records forwarding rules, it can determine that the first packet needs to be forwarded to the gateway based on the forwarding rules. Therefore, the first TOR switch can encapsulate the first packet to obtain a first overlay packet with the first packet as the inner packet.

[0010] Subsequently, the first TOR switch can send the first superimposed packet to the gateway, so that the gateway can decapsulate the first superimposed packet and send the obtained first packet to the cloud server, thereby completing the communication between the first server and the cloud server.

[0011] As can be seen from the above method, the first server, which does not belong to the public cloud system, offloads its network forwarding capability to the first TOR switch. That is, the first TOR switch can act as the control center for communication between the first server and the cloud server of the public cloud system. Therefore, the traffic transmitted between the two is determined by the forwarding bandwidth of the first TOR switch. The forwarding bandwidth of the first TOR switch is often greater than the forwarding bandwidth of the smart network card on the first server. This is because, in high-traffic scenarios, the first TOR switch can also forward traffic from the first server to the cloud server in a timely and accurate manner to meet the traffic forwarding needs of the first server, thereby meeting the business needs of the tenant and improving the tenant experience to a certain extent.

[0012] In one possible implementation, the network configuration request is further used to instruct network configuration for a second server that does not belong to the public cloud system. The method further includes: configuring a second TOR switch on the cloud management platform, wherein a first end of the second TOR switch is connected to the second server, and a second end of the second TOR switch is connected to a first TOR switch; forwarding rules are further used to instruct the first TOR switch to send a packet with a destination address of the second server's IP address to the second TOR switch; the first TOR switch receives a second packet sent by the first server, wherein the destination address of the second packet is the second server's IP address; the first TOR switch sends a second superimposed packet to the second TOR switch based on the forwarding rules, wherein the inner packet of the second superimposed packet is the second packet; and the second TOR switch sends the second packet in the second superimposed packet to the second server. In the aforementioned implementation, if the network configuration request is also used to request the cloud management platform to configure the network for the second server, the cloud management platform can also configure a second TOR switch for the second server. The first end of the second TOR switch is connected to the second server, and the second end of the second TOR switch is connected to the first TOR switch. Therefore, the forwarding rules recorded by the first TOR switch can also be used to instruct the first TOR switch to send packets with the destination address being the IP address of the second server to the second TOR switch. When the first server needs to access the second server, the first server can send a second packet with the destination address being the IP address of the second server to the first TOR switch. Since the first TOR switch records forwarding rules, it can encapsulate the second packet to obtain a second superimposed packet with the second packet as the inner packet, and send the second superimposed packet to the second TOR switch. The second TOR switch then decapsulates the second superimposed packet and sends the resulting second packet to the second server, thus completing the communication between the first and second servers. Therefore, when the first server can access the second server through the first TOR switch and the second TOR switch, it does not need to go through a gateway. This reduces the dependence of servers that do not belong to the public cloud system on the gateway when communicating, thereby reducing the management cost of the server and the overall cost of the server providing cloud services to the tenant.

[0013] In one possible implementation, the network configuration request is further used to instruct network configuration for a third server that is not part of the public cloud system. The third end of the first TOR switch is connected to the third server. The method further includes: the first TOR switch receiving a third message sent by the first server, wherein the destination address of the third message is the IP address of the third server; and the first TOR switch sending the third message to the third server. In the aforementioned implementation, since the network configuration request can also be used to request the cloud management platform to configure the network for the third server, the cloud management platform can also configure the first TOR switch for the third server, wherein the third end of the first TOR switch is connected to the third server. When the first server needs to access the third server, the first server can send a third message with the destination address of the third server's IP address to the first TOR switch. Since the first TOR switch is directly connected to the third server, the first TOR switch can directly send the third message to the third server, thereby completing the communication between the first server and the third server. Therefore, the first TOR switch can directly enable the first server to access the third server, thereby achieving low-latency communication between servers that are not part of the public cloud system.

[0014] In one possible implementation, the forwarding rules are further used to instruct packets destined for the IP address of the first server to be sent to the first server. The method further includes: the first TOR switch receiving a third overlay packet sent by the gateway, wherein the inner packet of the third overlay packet is a fourth packet, the destination address of the fourth packet is the IP address of the first server, and the source address of the fourth packet is the IP address of the cloud server; the first TOR switch, based on the forwarding rules, sends the fourth packet from the third overlay packet to the first server. In the aforementioned implementation, when the cloud server needs to access the first server, the cloud server can send a fourth packet with the IP address of the first server as its destination to the gateway. Then, the gateway can encapsulate the fourth packet to obtain a third overlay packet with the fourth packet as its inner packet, and send the third overlay packet to the first TOR switch. Subsequently, the first TOR switch can decapsulate the third overlay packet to obtain the fourth packet. Based on the forwarding rules recorded by the first TOR switch, the first TOR switch can send the fourth packet to the first server, thereby completing the communication between the cloud server and the first server. Therefore, the first TOR switch and gateway can enable the first server to access the cloud server and the cloud server to access the first server, which is equivalent to enabling the first server to successfully enter the cloud, thereby meeting the tenant's need to enter the cloud for servers that do not belong to the public cloud system.

[0015] In one possible implementation, the method further includes: a first TOR switch receiving a fourth overlay packet sent by a second TOR switch, wherein the inner packet of the fourth overlay packet is a fifth packet, the destination address of the fifth packet is the IP address of the first server, and the source address of the fifth packet is the IP address of the second server; the first TOR switch, based on forwarding rules, forwards the fifth packet from the fourth overlay packet to the first server. In the aforementioned implementation, when the second server needs to access the first server, the second server can send a fifth packet with the destination address of the first server's IP address to the second TOR switch. Then, the second TOR switch can encapsulate the fifth packet to obtain a fourth overlay packet with the fifth packet as its inner packet, and send the fourth overlay packet to the first TOR switch. Subsequently, the first TOR switch can decapsulate the fourth overlay packet to obtain the fifth packet. Based on the forwarding rules recorded by the first TOR switch, the first TOR switch can send the fifth packet to the first server, thereby completing the communication between the second server and the first server. Therefore, when the second server can access the first server through the second TOR switch and the first TOR switch, it does not need to go through the gateway. This reduces the dependence of servers that do not belong to the public cloud system on the gateway when communicating, thereby reducing the management cost of the server and the overall cost of the server providing cloud services to the tenant.

[0016] In one possible implementation, the method further includes: a first TOR switch receiving a sixth message sent by a third server, wherein the destination address of the sixth message is the IP address of the first server, and the source address of the sixth message is the IP address of the third server; the first TOR switch then sends the sixth message to the first server. In the aforementioned implementation, when the third server needs to access the first server, the third server can send a sixth message with the destination address of the first server's IP address to the second TOR switch. Then, the first TOR switch can directly send the sixth message to the first server, thereby completing the communication between the third server and the first server. Therefore, the first TOR switch can directly enable the third server to access the first server, thus achieving low-latency communication between servers not belonging to the public cloud system.

[0017] In one possible implementation, the first TOR switch also records access control rules, which indicate the accessible range of the first server. The first TOR switch, based on forwarding rules, sends the first overlay packet to the gateway, including: the first TOR switch determining that the cloud server is within the accessible range based on the access control rules, and then sending the first overlay packet to the gateway based on the forwarding rules. In the aforementioned implementation, the first TOR switch may also record access control rules, which can be used to indicate the accessible range of the first server. Therefore, when the first TOR switch receives the first packet, it can determine that the first server is about to access the cloud server. Thus, the first TOR can determine whether the cloud server is within the accessible range of the first server based on the access control rules. If so, the first TOR switch generates the first overlay packet based on the first packet and sends the first overlay packet to the gateway based on the forwarding rules. If not, the first TOR switch intercepts the first packet and does not send it outwards. Therefore, the first TOR switch can also protect the traffic between the first server and the cloud server, thereby ensuring data security when servers not belonging to the public cloud system communicate with the cloud.

[0018] In one possible implementation, the first server is either the tenant's local server or a cloud server of a third-party public cloud system.

[0019] A second aspect of this application provides a public cloud system, which includes a cloud management platform and infrastructure. The cloud management platform manages the infrastructure, which includes cloud servers. Specifically: the cloud management platform receives network configuration requests input by tenants, whereby the network configuration requests request network configuration for a first server that does not belong to the public cloud system; the cloud management platform is also configured, based on the network configuration requests, to configure a first TOR switch and a gateway, wherein a first end of the first TOR switch is connected to the first server, a second end of the first TOR switch is connected to the gateway, and the first TOR switch records forwarding rules that instruct the first TOR switch to send packets with an Internet Protocol (IP) address of the cloud server to the gateway; the first TOR switch receives a first packet sent by the first server, where the destination address of the first packet is the IP address of the cloud server; the first TOR switch is also configured to send a first overlay packet to the gateway based on the forwarding rules, where the inner packet of the first overlay packet is the first packet; and the gateway sends the first packet in the first overlay packet to the cloud server.

[0020] In one possible implementation, the network configuration request is further used to instruct network configuration for a second server that does not belong to the public cloud system; the cloud management platform is further used to configure a second TOR switch, wherein a first end of the second TOR switch is connected to the second server, and a second end of the second TOR switch is connected to a first TOR switch; forwarding rules are further used to instruct the first TOR switch to send packets with a destination address of the second server's IP address to the second TOR switch; the first TOR switch is further used to receive a second packet sent by the first server, wherein the destination address of the second packet is the second server's IP address; the first TOR switch is further used to send a second overlay packet to the second TOR switch based on the forwarding rules, wherein the inner packet of the second overlay packet is the second packet; the second TOR switch is used to send the second packet in the second overlay packet to the second server.

[0021] In one possible implementation, the network configuration request is also used to instruct network configuration for a third server that does not belong to the public cloud system, and the third end of the first TOR switch is connected to the third server; the first TOR switch is also used to receive a third message sent by the first server, wherein the destination address of the third message is the IP address of the third server; the first TOR switch is also used to send the third message to the third server.

[0022] In one possible implementation, the forwarding rule is also used to instruct packets whose destination address is the IP address of the first server to be sent to the first server; the first TOR switch is also used to receive a third overlay packet sent by the gateway, wherein the inner packet of the third overlay packet is a fourth packet, the destination address of the fourth packet is the IP address of the first server, and the source address of the fourth packet is the IP address of the cloud server; the first TOR switch is also used to send the fourth packet in the third overlay packet to the first server based on the forwarding rule.

[0023] In one possible implementation, the first TOR switch is also used to receive a fourth overlay message sent by the second TOR switch, wherein the inner message of the fourth overlay message is a fifth message, the destination address of the fifth message is the IP of the first server, and the source address of the fifth message is the IP of the second server; the first TOR switch is also used to send the fifth message in the fourth overlay message to the first server based on forwarding rules.

[0024] In one possible implementation, the first TOR switch is also used to receive a sixth message sent by the third server, wherein the destination address of the sixth message is the IP address of the first server and the source address of the sixth message is the IP address of the third server; the first TOR switch is also used to send the sixth message to the first server.

[0025] In one possible implementation, the first TOR switch also records access control rules, which are used to indicate the range accessible to the first server. The first TOR switch, based on the access control rules, determines that the cloud server is located within the range, and then sends the first overlay packet to the gateway based on the forwarding rules.

[0026] In one possible implementation, the first server is either the tenant's local server or a cloud server of a third-party public cloud system.

[0027] A third aspect of this application provides a computing device cluster, which includes at least one computing device, each computing device including a processor and a memory: the memory is used to store instructions; the processor is used to cause the computing device cluster to perform the method described in the first aspect or any possible implementation of the first aspect according to the instructions.

[0028] A fourth aspect of this application provides a computer storage medium storing one or more instructions that, when executed by one or more computers, cause the one or more computers to perform the method described in the first aspect or any possible implementation of the first aspect.

[0029] A fifth aspect of this application provides a computer program product storing instructions that, when executed by a computer, cause the computer to perform the method described in the first aspect or any possible implementation of the first aspect.

[0030] In this embodiment, when a tenant needs to bring a first server (not belonging to a public cloud system) into the cloud, the tenant can send a network configuration request to the cloud management platform. This request requests network configuration for the first server. Based on this request, the cloud management platform can configure a first TOR switch and a gateway for the first server. The first TOR switch records forwarding rules that instruct it to send packets destined for the IP address of the cloud server in the public cloud system to the gateway. When the first TOR switch receives a first packet from the first server, it determines that the destination address is the cloud server's IP address. Therefore, the first TOR switch generates a first overlay packet based on the forwarding rules and the first packet. This first packet serves as the inner packet of the first overlay packet. The first TOR switch then sends the first overlay packet to the gateway, enabling the gateway to send the inner packet (the first packet) to the cloud server, thus completing communication between the first server and the cloud server. In the aforementioned process, the first server, which is not part of the public cloud system, offloads its network forwarding capabilities to the first TOR switch. That is, the first TOR switch can act as the control center for communication between the first server and the cloud server of the public cloud system. Therefore, the traffic transmitted between the two is determined by the forwarding bandwidth of the first TOR switch. The forwarding bandwidth of the first TOR switch is often greater than the forwarding bandwidth of the smart network card on the first server. This is because, in high-traffic scenarios, the first TOR switch can also forward traffic from the first server to the cloud server in a timely and accurate manner to meet the traffic forwarding needs of the first server, thereby meeting the business needs of the tenant and improving the tenant experience to a certain extent. Attached Figure Description

[0031] Figure 1 A schematic diagram of the structure of a public cloud system provided in an embodiment of this application;

[0032] Figure 2 Another schematic diagram of the public cloud system provided in the embodiments of this application;

[0033] Figure 3 Another schematic diagram of the cloud network provided in the embodiments of this application;

[0034] Figure 4 This is a flowchart illustrating a network configuration method for a hybrid cloud scenario.

[0035] Figure 5 Another schematic diagram of the public cloud system provided in the embodiments of this application;

[0036] Figure 6 A schematic diagram of a VXLAN message provided in an embodiment of this application;

[0037] Figure 7 A schematic diagram of a TOR switch provided in an embodiment of this application;

[0038] Figure 8 Another schematic diagram of the public cloud system provided in the embodiments of this application;

[0039] Figure 9 A schematic diagram of the structure of the cloud management platform provided in the embodiments of this application;

[0040] Figure 10 A schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0041] Figure 11 A schematic diagram of the structure of a computing device cluster provided in an embodiment of this application;

[0042] Figure 12 This is a schematic diagram illustrating the network connection of computer devices in a computer cluster provided in an embodiment of this application. Detailed Implementation

[0043] This application provides a network configuration method and public cloud system based on a hybrid cloud scenario, which can meet the traffic forwarding requirements of the server, thereby meeting the business needs of the tenant and improving the tenant experience to a certain extent.

[0044] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0045] With the rapid development of cloud technology, tenants can host their own servers with cloud providers, thus enabling tenants to migrate their servers to the cloud. Based on this, tenants' servers can communicate with cloud servers in the cloud through the network built by the cloud provider, allowing tenants to enjoy various cloud services provided by the cloud servers.

[0046] In related technologies, when a tenant's multiple servers are migrated to the cloud, each server is connected to its own smart network interface card (NIC). These NICs are equipped with virtualization software. When a tenant's server needs to access a cloud server, the packets generated by that server are provided to its connected smart NIC. The virtualization software on the smart NIC then forwards the packets to the cloud server, thus enabling communication between the two servers. In this way, the packet forwarding process does not require the server's processor, memory, or other physical resources, allowing these resources to be fully utilized by the tenant, thereby improving resource utilization.

[0047] However, for these multiple servers, the forwarding bandwidth of the connected smart network cards is often limited, which means that the server's inbound and outbound traffic is restricted by the forwarding bandwidth of the smart network cards. In some high-traffic scenarios, the smart network cards cannot meet the server's traffic forwarding requirements, thus failing to meet the tenant's business needs and resulting in a poor tenant experience.

[0048] To address the aforementioned issues, this application provides a network configuration method for hybrid cloud scenarios, which can be implemented through a public cloud system. Figure 1 A schematic diagram of the structure of the public cloud system provided in the embodiments of this application is shown below. Figure 1 As shown, a public cloud system includes the infrastructure that provides cloud services and the cloud management platform that manages this infrastructure. The cloud management platform and the infrastructure are described separately below:

[0049] A cloud management platform can centrally manage the infrastructure within the entire public cloud system (for example, within the infrastructure, according to a tenant's instructions, a network can be created for multiple servers not belonging to the public cloud system, allowing these servers to access multiple cloud servers within the public cloud system through this network, etc.). The cloud management platform can also be open to tenants outside the public cloud system and respond to their requests. For example, the cloud management platform can provide various interfaces such as login and network configuration interfaces for tenant clients (e.g., the terminal devices used by the tenant or the browsers on those devices) to access. Specifically, the cloud management platform can authenticate a tenant's client through the login interface, allowing the client to log in after successful authentication. Furthermore, the cloud management platform can also allow tenant clients to send network configuration requests to the cloud management platform through the network configuration interface, requesting network configuration for multiple servers not belonging to the public cloud system. Based on this network configuration request, the cloud management platform can configure multiple top-of-rack (TOR) switches and multiple gateways (GWs) for these servers. Each TOR switch can connect several servers to a gateway, and each TOR switch records forwarding rules (also known as routing). For any given TOR switch, its forwarding rules instruct it to send packets destined for the cloud server's IP address to the gateway connected to it. Therefore, when a TOR switch receives a packet from one of its connected servers, since the packet's destination address is the cloud server's IP address, the TOR switch treats this packet as an inner packet of an overlay packet and sends this overlay packet to the gateway connected to it. The gateway can then forward this inner packet of the overlay packet, i.e., the packet itself, to the cloud server, thus completing the communication between the server and the cloud server.

[0050] The infrastructure comprises multiple cloud servers owned by the public cloud system. Each of these cloud servers may contain a certain amount of computing resources (e.g., central processing unit (CPU) and graphics processing unit (GPU), etc.), a certain amount of storage resources (e.g., memory and disk), and a certain amount of network resources (e.g., network interface cards, etc.). Therefore, the multiple cloud servers owned by the public cloud system as a whole possess a large number of resources to provide various services to tenants. These cloud servers can be leased to tenants to run their applications and provide dedicated services, or they can be used to run cloud vendor applications and provide various cloud services to tenants without being leased to them.

[0051] Furthermore, multiple servers that do not belong to the public cloud system can be either the tenant's own local servers or cloud servers rented by the tenant from a third-party public cloud system; no specific restrictions are imposed here.

[0052] Furthermore, such as Figure 2 As shown ( Figure 2 (This is another structural diagram of the public cloud system provided in this application embodiment). The cloud management platform can create a network plane covering the infrastructure. For example, this network can be a Virtual Private Cloud (VPC) network. The cloud network of this network is the network accessed by multiple cloud servers. Therefore, multiple cloud servers can access other parts of the VPC network through the cloud network. Based on this, in order to enable multiple servers that do not belong to the public cloud system to access the VPC network, the tenant can send a network configuration request to the cloud management platform. This network configuration request can indicate that the tenant needs the cloud management platform to create an inbound network that can be accessed by multiple servers that do not belong to the public cloud system (i.e., the tenant requests network configuration for multiple servers that do not belong to the public cloud system). Based on this request, the cloud management platform can create an inbound network in the VPC network that covers multiple servers that do not belong to the public cloud system. Therefore, multiple servers that do not belong to the public cloud system can access other parts of the VPC network through the inbound network, such as the aforementioned cloud network, etc.

[0053] Furthermore, such as Figure 2As shown, from a physical perspective, an inbound network covering multiple servers not belonging to a public cloud system can physically consist of a switch layer and a gateway layer. The switch layer includes a TOR switch (also known as an access switch) layer and a route reflector (RR) layer. The TOR switch layer can contain multiple TOR switches, and any one TOR switch can be accessed by at least one server not belonging to a public cloud system. The RR layer can contain multiple aggregation switches, and any one aggregation switch can be accessed by all TOR switches in the TOR layer. The gateway layer contains multiple gateways, and any one gateway can be accessed by at least one aggregation switch. It's important to note that the gateway layer acts as the network boundary between the cloud network and the inbound network, but not as the network boundary between different inbound networks. In other words, the RR layers of different inbound networks can connect (without going through the gateway layer). When a server in the inbound network needs to access a cloud server in the cloud network, the packet transmission path is: server → TOR switch → aggregation switch → gateway → cloud server. When a server in the cloud network needs to communicate with a cloud server in the cloud network, the message transmission path is: server → TOR switch → aggregation switch → gateway → cloud server. When servers in the same cloud network need to communicate, the message transmission path is: server → TOR switch → aggregation switch → TOR switch → server (or server → TOR switch → server). When servers in different cloud networks need to communicate, the message transmission path is: server → TOR switch → aggregation switch → aggregation switch → TOR switch → server.

[0054] Furthermore, such as Figure 2 As shown, logically, the cloud network can be divided into Cloud Data Center Network (CloudDCN) subnets, Ethernet Virtual Private Network (EVPN) route advertising ranges, and EVPN route reflection ranges. The CloudDCN subnet is a logical subnet comprised of multiple servers not belonging to the public cloud system. The EVPN route advertising range is comprised of multiple TOR switches, and the EVPN route reflection range is comprised of multiple aggregation switches. Correspondingly, the logical subnet comprised of multiple cloud servers in the cloud network is the ordinary subnet.

[0055] Furthermore, the network configuration request entered by the tenant can specifically include parameters for the CloudDCN subnets set up by the tenant for multiple servers not belonging to the public cloud (details will not be elaborated here). These parameters indicate that the tenant needs the cloud management platform to build a CloudDCN subnet for these multiple servers. Therefore, the cloud management platform will default to building an inbound network for these multiple servers. This inbound network includes the CloudDCN subnet, the EVPN route advertisement range above the CloudDCN subnet, and the EVPN route reflection range above the EVPN route advertisement range, etc. Based on this, the tenant can create different CloudDCN subnets for different server clusters, for example, such as... Figure 3 As shown ( Figure 3 (This is another schematic diagram of the cloud network provided in the embodiments of this application). The cloud management platform can create CloudDCN subnet 1 for servers 1 to 4, CloudDCN subnet 2 for servers 5 to 8, and CloudDCN subnet 3 for servers 9 to 12 according to the tenant's requirements. In addition, servers in different CloudDCN subnets can share the same TOR switch or use different TOR switches. That is, servers in CloudDCN subnet 1 are connected through TOR switch 1 to TOR switch 2, servers in CloudDCN subnet 2 are connected through TOR switch 3 to TOR switch 4, and servers in CloudDCN subnet 3 are connected through TOR switch 1 to TOR switch 2.

[0056] Furthermore, any inbound network of a tenant can also be referred to as a point of delivery (POD). Generally speaking, an inbound POD can take the form of different inbound PODs in various scenarios. For example, in a typical scenario, an inbound POD can include multiple servers that do not belong to a public cloud system, i.e., servers owned by the tenant or cloud servers rented by the tenant from a third-party public cloud system. In other scenarios, an inbound POD can also include multiple cloud servers rented by the tenant from a public cloud system, and so on.

[0057] Furthermore, for multiple cloud servers in a public cloud system, the cloud management platform can create virtual instances on these physical servers using virtualization technology. For example, these virtual instances can be virtual machines (VMs) created by the cloud management platform on the physical server using virtualization technology; they can also be containers created by the cloud management platform on the physical server using virtualization technology; and they can also be microVMs created by the cloud management platform on the physical server using virtualization technology, and so on. However, for multiple servers that do not belong to a public cloud system, they are usually managed by the cloud management platform as physical machines, that is, they are deployed to the cloud as physical machines (also known as bare metal).

[0058] Furthermore, for multiple cloud servers within a public cloud system, these servers can be deployed on the same site or different sites. A site can take various forms, such as a region within the infrastructure, an availability zone within the infrastructure, a data center (DC) within the infrastructure, a room within the infrastructure, or a rack within the infrastructure, etc. Similarly, for multiple servers not belonging to a public cloud system, these servers can also be deployed on the same site or different sites, which will not be elaborated upon here.

[0059] Based on the aforementioned public cloud system, when a tenant needs to bring servers not belonging to the public cloud system into the cloud, the tenant can send a network configuration request to the cloud management platform. This request requests network configuration for servers not belonging to the public cloud system. Based on this request, the cloud management platform can configure a TOR switch and a gateway for the servers not belonging to the public cloud system. The TOR switch records forwarding rules, which instruct it to send packets destined for the IP address of the cloud server in the public cloud system to the gateway. When the TOR switch receives a packet from a server not belonging to the public cloud system, it determines that the destination address is the cloud server's IP address. Therefore, the TOR switch can generate an overlay packet based on the forwarding rules and the packet, using this overlay packet as its inner packet. The TOR switch then sends this overlay packet to the gateway, enabling the gateway to forward the inner packet (the overlay packet) to the cloud server, thus completing communication between the server not belonging to the public cloud system and the cloud server in the public cloud system. In the aforementioned process, servers not belonging to the public cloud system offload their network forwarding capabilities to TOR switches. This means the TOR switch acts as the control center for communication between servers not belonging to the public cloud system and cloud servers within the public cloud system. Therefore, the traffic transmitted between them is determined by the forwarding bandwidth of the TOR switch. The forwarding bandwidth of the TOR switch is often greater than that of the smart network interface card (NIC) on the server. This is because, in high-traffic scenarios, the TOR switch can also forward traffic from servers not belonging to the public cloud system to cloud servers within the public cloud system in a timely and accurate manner, meeting the server's traffic forwarding needs and thus satisfying the tenant's business requirements, which can improve the tenant's experience to some extent. To further understand the working process of the public cloud system described above, the following section combines... Figure 4 To further explain the working process, Figure 4 This is a flowchart illustrating a network configuration method for a hybrid cloud scenario, as shown below. Figure 4 As shown, this method can be achieved through, as Figure 1 or Figure 2 The illustrated public cloud system implementation may include infrastructure that provides cloud services to tenants and a cloud management platform that manages this infrastructure, which includes cloud servers. The method includes:

[0060] 401. The cloud management platform receives a network configuration request from a tenant. The network configuration request is used to request network configuration for the first server that does not belong to the public cloud system.

[0061] In this embodiment, when a tenant needs to bring a first server (i.e., one or more servers not belonging to the public cloud system) into the cloud, the cloud management platform can provide a network configuration interface to the tenant's client (e.g., the network configuration bar on the tenant's interface). Therefore, the tenant can input the network configuration request set by the tenant into the network configuration interface through its client. In this way, the cloud management platform can receive the network configuration request sent by the tenant's client through the network configuration interface. The network configuration request can be used to indicate that the tenant requests the cloud management platform to perform network configuration on the first server.

[0062] Specifically, a network configuration request (also known as a network creation request) may include parameters of the CloudCDN subnet set up by the tenant for the first server. These parameters describe the CloudCDN subnet where the first server resides. Furthermore, the network configuration request may also include parameters of the CloudCDN subnet set up by the tenant for a second server (or another server or servers not belonging to the public cloud system). These parameters describe the CloudCDN subnet where the second server resides (equivalent to the tenant requesting network configuration for the second server). Further still, the network configuration request may include parameters of the CloudCDN subnet set up by the tenant for a third server (or yet another server or servers not belonging to the public cloud system). These parameters describe the CloudCDN subnet where the third server resides (equivalent to the tenant requesting network configuration for the third server), and so on.

[0063] For the CloudCDN subnet where the first server is located, its parameters must include: the name of the CloudCDN subnet, the network segment of the CloudCDN subnet, the gateway of the CloudCDN subnet, and the ID of the VPC where the CloudCDN subnet is located, etc. Among them, the network segment of the CloudCDN subnet may include the IP of the first server (which can be specified by the tenant or allocated by the cloud management platform; no specific restrictions are made here), etc.

[0064] For the CloudCDN subnet where the second server is located, the parameters must include: the name of the CloudCDN subnet, the network segment of the CloudCDN subnet, the gateway of the CloudCDN subnet, and the ID of the VPC where the CloudCDN subnet is located, etc. Among them, the network segment of the CloudCDN subnet may include the IP of the second server, etc.

[0065] For the CloudCDN subnet where the third server is located, the parameters must include: the name of the CloudCDN subnet, the network segment of the CloudCDN subnet, and the ID of the VPC where the CloudCDN subnet is located, etc. The network segment of the CloudCDN subnet may include the IP address of the third server, etc.

[0066] It should be noted that the CloudCDN subnets where the first server, the second server, and the third server reside can be either the same or different CloudCDN subnets; no specific restrictions are imposed here. Furthermore, these CloudCDN subnets are typically located within the same VPC.

[0067] For example, such as Figure 5 As shown ( Figure 5 (This is another structural diagram of the public cloud system provided in the embodiments of this application). Suppose that a tenant needs to migrate its own servers 1 to 8 to the cloud. The tenant can log in to the cloud management platform. The cloud management platform can provide a tenant interface for the tenant. The tenant interface includes a network configuration bar. Therefore, the tenant can enter a network configuration request for servers 1 to 8 into the network configuration bar. The request includes the parameters of CloudCDN subnet 1 where servers 1 to 4 (including the aforementioned first server and third server) are located, and the parameters of CloudCDN subnet 2 where servers 5 to 8 (including the aforementioned second server) are located.

[0068] In this way, the cloud management platform can receive network configuration requests sent by tenants. These requests instruct tenants to request network configuration for servers 1 to 8, that is, to request the creation of CloudCDN subnet 1 for servers 1 to 4 to access and CloudCDN subnet 2 for servers 5 to 8 to access.

[0069] 402. The cloud management platform configures the first TOR switch and the gateway based on the network configuration request. The first end of the first TOR switch is connected to the first server, and the second end of the first TOR switch is connected to the gateway. The first TOR switch records forwarding rules, which are used to instruct the first TOR switch to send packets with the Internet Protocol IP address of the cloud server as the destination address to the gateway.

[0070] Upon receiving the network configuration request, the cloud management platform determines that the tenant requests network configuration for the first server. Therefore, the cloud management platform can configure a first TOR switch and a gateway for the first server. Specifically, the first end of the first TOR switch is connected to the first server, and the second end of the first TOR switch is connected to the gateway. The first end of the gateway is connected to the first TOR switch, and the second end of the gateway is connected to the cloud server. In other words, the first server connects to the cloud server through the first TOR switch and the gateway. It is worth noting that the configured first TOR switch records forwarding rules, which instruct the first TOR switch to send packets destined for the cloud server's IP address to the gateway.

[0071] Specifically, the cloud management platform can also perform the following operations:

[0072] Since a network configuration request can indicate not only a tenant's request for network configuration on the first server, but also on the second and third servers, the cloud management platform can also configure a second TOR switch for the second server based on this request. The first end of the second TOR switch is connected to the second server, and the second end of the second TOR switch is connected to the first TOR switch. In other words, the first server connects to the second server through the first and second TOR switches. It's worth noting that the forwarding rules recorded by the configured first TOR switch can also be used to instruct it to send packets destined for the second server's IP address to the second TOR switch.

[0073] Furthermore, the cloud management platform can also configure a first TOR switch for the third server. The third end of the first TOR switch is connected to the third server; that is, the first server connects to the third server through the first TOR switch. It is worth noting that since both the first and third servers are connected to the first TOR switch, the first TOR switch can directly send packets destined for the third server's IP address to the third server.

[0074] Therefore, it can be seen that the first server successfully established physical connections with the second server, the third server, and the cloud server through the first TOR switch. This is equivalent to the cloud management platform successfully building the CloudCDN subnet where the first server resides (of course, on the CloudCDN subnet where the first server resides, the cloud management platform also successfully built the corresponding EVPN route advertisement range and EVPN route reflection range, etc., which will not be elaborated here). Similarly, the cloud management platform performed similar operations on the second and third servers, which is equivalent to successfully building the CloudCDN subnets where the second and third servers reside, respectively. For these CloudCDN subnets, servers within the same CloudCDN subnet can communicate with each other, servers in different CloudCDN subnets can communicate with each other, and servers within a CloudCDN subnet can also access cloud servers in ordinary subnets on the cloud.

[0075] More specifically, the cloud management platform can configure routing rules in the first TOR switch in the following ways:

[0076] After the cloud management platform starts the first, second, and third servers, the first and third servers can provide their own IP addresses and other information to the first TOR switch. The second server can automatically trigger the second TOR switch to provide its own IP address and the second TOR switch's IP address and other information to the first TOR switch in the form of EVPN routing. Furthermore, after starting the cloud server, the cloud management platform can provide the cloud server's IP address and the gateway's IP address and other information to the first TOR switch. In this way, after aggregating these IP addresses, the first TOR switch can generate forwarding rules internally. These rules instruct the first TOR switch to send packets destined for the cloud server's IP address to the gateway, packets destined for the second server's IP address to the second TOR switch, and packets destined for the first server's IP address (or the third server's IP address) to the first server (or the third server).

[0077] Therefore, due to the routing rules recorded by the first TOR switch, the first TOR switch can accurately enable the first server to access other cloud servers in the ordinary subnet of the cloud across its own CloudCDN subnet. Assuming that the first server and the second server are located in different CloudCDN subnets (or in the same CloudCDN subnet), the first TOR switch can also enable the first server to access other cloud servers in another CloudCDN subnet (or in the same CloudCDN subnet) across its own CloudCDN subnet. Assuming that the first server and the third server are located in the same CloudCDN subnet (or in different CloudCDN subnets), the first TOR switch can also enable the first server to access other cloud servers in the same CloudCDN subnet (or in another CloudCDN subnet).

[0078] Furthermore, the cloud management platform can also enable the second TOR switch to perform similar operations, generating corresponding forwarding rules internally. Therefore, the second TOR switch can also enable the second server to communicate with the first server, the third server, and the cloud server; this will not be elaborated further here. Moreover, the cloud management platform can provide the gateway with information such as the IP addresses of the cloud server, the first server, the first TOR switch, the second server, the second TOR switch, and the third server, allowing the gateway to also generate corresponding forwarding rules. This enables the gateway to allow the cloud server to communicate with the first, second, and third servers; this will also not be elaborated further here.

[0079] Continuing with the example above, after receiving the network configuration request, the cloud management platform determines that CloudCDN subnet 1, where servers 1 to 4 reside, and CloudCDN subnet 2, where servers 5 to 8 reside, need to be created. The cloud management platform then configures TOR switches 1, 2, 3, and 4, as well as the gateway. Specifically, TOR switch 1 connects to servers 1 and 2; TOR switch 2 connects to servers 3 and 4; TOR switch 3 connects to servers 5 and 6; and TOR switch 4 connects to servers 7 and 8. Furthermore, all TOR switches 1, 2, 3, and 4 are connected to the gateway.

[0080] After servers 1 through 4 start up, server 2 can synchronize its IP address and other routing information to TOR switch 1. Servers 3 and 4 can trigger TOR switch 2 to synchronize the IP address of server 3, the IP address of server 4, and the IP address of TOR switch 2 to TOR switch 1. Servers 5 and 6 can trigger TOR switch 3 to synchronize the IP address of server 5, the IP address of server 6, and the IP address of TOR switch 3 to TOR switch 1. Servers 7 and 8 can trigger TOR switch 4 to synchronize the IP address of server 7, the IP address of server 8, and the IP address of TOR switch 4 to TOR switch 1. After cloud servers 1 through 4 start up, the cloud management platform can provide the IP address and gateway IP address of cloud servers 1 through 4 to TOR switch 1, or the cloud management platform can provide the prefix route of the network segment containing the IP addresses of cloud servers 1 through 4, and the IP address of the gateway to TOR switch 1.

[0081] In this way, TOR switch 1 can generate forwarding rules (routing). These rules instruct TOR switch 1 to directly send packets destined for server 1's IP address to server 1, packets destined for server 2's IP address to server 2, packets destined for server 3 and server 4's IP addresses to TOR switch 2, packets destined for server 5 and server 6's IP addresses to TOR switch 3, packets destined for server 7 and server 6's IP addresses to TOR switch 4, and packets destined for cloud server 1 to cloud server 4's IP addresses to the gateway. Similarly, TOR switches 2, TOR switches 3, and TOR switches 4 can also generate corresponding forwarding rules, which will not be elaborated here.

[0082] In addition, the cloud management platform can provide routing information such as the IP of server 1, the IP of server 2, the IP of TOR switch 1, the IP of server 3, the IP of server 4, the IP of TOR switch 2, the IP of server 5, the IP of server 6, the IP of TOR switch 3, the IP of server 7, the IP of server 8, the IP of TOR switch 4, and the IPs of cloud server 1 to cloud server 4 to the gateway, so that the gateway can also generate forwarding rules, thereby enabling communication between cloud servers (cloud server 1 to cloud server 4) and tenant servers (server 1 to server 8) based on the forwarding rules.

[0083] In this way, the cloud management platform can successfully create CloudCDN subnet 1 where servers 1 to 4 are located, and CloudCDN subnet 2 where servers 5 to 8 are located.

[0084] 403. The first TOR switch receives the first message sent by the first server, wherein the destination address of the first message is the IP address of the cloud server.

[0085] 404. The first TOR switch sends the first superimposed packet to the gateway based on the forwarding rules, wherein the inner packet of the first superimposed packet is the first packet.

[0086] 405. The gateway sends the first message in the first superimposed message to the cloud server.

[0087] When the first server needs to access the cloud server, it sends a first packet with the cloud server's IP address as the destination address to the first TOR switch. This first packet can be a Virtual Local Area Network (VLAN) packet or a raw packet. Upon receiving the first packet, the first TOR switch, having recorded forwarding rules, determines that the first packet needs to be forwarded to the gateway. Therefore, the first TOR switch encapsulates the first packet, resulting in a first overlay packet with the first packet as its inner packet. This first overlay packet can be a Virtual Extensible Local Area Network (VXLAN) packet. The first TOR switch then sends the first overlay packet to the gateway, allowing the gateway to decapsulate it and forward the resulting first packet to the cloud server, thus completing the communication between the first server and the cloud server.

[0088] It should be noted that, due to the forwarding rules recorded by the first TOR switch, the first superimposed packet generated by the first TOR switch includes an inner packet and an outer encapsulation. The destination address of the inner packet is the IP of the cloud server, the source address of the inner packet is the IP of the first server, the destination address of the outer encapsulation is the IP of the gateway, and the source address of the outer encapsulation is the IP of the first TOR switch.

[0089] Continuing with the example above, when server 1 needs to access cloud server 1, server 1 can send VLAN packet 1 to TOR switch 1. The destination address of VLAN packet 1 is the IP address of cloud server 1, and the source address is the IP address of server 1. TOR switch 1, based on its own forwarding rules, determines that VLAN packet 1 needs to be sent to the gateway, and then generates a VXLAN packet 1 with VLAN packet 1 as the inner packet, such as... Figure 6 As shown ( Figure 6 (This is a schematic diagram of a VXLAN message provided in an embodiment of this application). The destination address of the outer encapsulation of VXLAN message 1 is the IP address of the gateway, and the source address is the IP address of TOR switch 1.

[0090] Then, TOR switch 1 can forward VXLAN packet 1 to the gateway, so that the gateway can send VLAN packet 1 in VXLAN packet 1 to cloud server 1, thereby completing the communication between server 1 and cloud server 1.

[0091] Specifically, the first TOR switch can also perform the following operations:

[0092] When the first server needs to access the second server, it can send a second packet to the first TOR switch with the destination address being the IP address of the second server. This second packet can be a VLAN packet or a raw packet. Upon receiving the second packet, the first TOR switch, having recorded forwarding rules, can determine that the second packet needs to be forwarded to the second TOR switch. Therefore, the first TOR switch can encapsulate the second packet, resulting in a second overlay packet with the second packet as its inner packet. This second overlay packet can be a VXLAN packet. Then, the first TOR switch can send the second overlay packet to the second TOR switch, allowing the second TOR switch to decapsulate it and send the resulting second packet to the second server, thus completing the communication between the first and second servers.

[0093] It should be noted that, due to the forwarding rules recorded by the first TOR switch, the second overlay packet generated by the first TOR switch includes an inner packet and an outer encapsulation. The destination address of the inner packet is the IP of the second server, the source address of the inner packet is the IP of the first server, the destination address of the outer encapsulation is the IP of the second TOR switch, and the source address of the outer encapsulation is the IP of the first TOR switch.

[0094] Continuing with the example above, when server 1 needs to access server 3, server 1 can send VLAN packet 2 to TOR switch 1. The destination address of VLAN packet 2 is the IP address of server 3, and the source address is the IP address of server 1. Based on its own forwarding rules, TOR switch 1 determines that VLAN packet 2 needs to be sent to TOR switch 2. It then generates a VXLAN packet 2 with VLAN packet 2 as the inner packet. The outer encapsulation of VXLAN packet 2 has the destination address of TOR switch 2 and the source address of TOR switch 1.

[0095] Then, TOR switch 1 can forward VXLAN packet 2 to TOR switch 2, so that TOR switch 2 can send VLAN packet 2 in VXLAN packet 2 to server 3, thereby completing the communication between server 1 and server 3.

[0096] More specifically, the first TOR switch can also perform the following operations:

[0097] When the first server needs to access the third server, it can send a third packet to the first TOR switch with the destination address being the IP address of the third server. This third packet can be a VLAN packet or a raw packet. Upon receiving the third packet, since the first TOR switch is directly connected to the third server, it can directly forward the third packet to the third server, thus completing the communication between the first and third servers.

[0098] It should be noted that the destination address of the third message is the IP address of the third server, and the source address of the third message is the IP address of the first server.

[0099] Continuing with the example above, when server 1 needs to access server 2, server 1 can send VLAN packet 3 to TOR switch 1. The destination address of VLAN packet 3 is the IP address of server 2, and the source address is the IP address of server 1. Since server 2 is directly connected to TOR switch 1, TOR switch 1 can directly send VLAN packet 3 to server 2, thereby completing the communication between server 1 and server 2.

[0100] It is worth noting that, such as Figure 7 As shown ( Figure 7 (This is a schematic diagram of a TOR switch provided in an embodiment of this application). TOR switch 1 can be configured with a bridge domain (BD) 1 bound to CloudCDN subnet 1 and a virtual bridge domain interface (VBDIF) port 1 bound to BD1. The forwarding rules of TOR switch 1 are set in the VPN instance associated with VBDIF port 1. When server 1 needs to access a cloud server in a normal subnet, server 3 in CloudCDN subnet 1, or server 5 in CloudCDN subnet 2, TOR switch 1 can provide VLAN packets to BD1. BD1 can then provide the original packets from the VLAN packets to VBDIF port 1, allowing VBDIF port 1 to generate VXLAN packets based on the forwarding rules of its associated VPN instance and send the VXLAN packets to the gateway, TOR switch 2, or TOR switch 3. When server 1 needs to access server 2 in CloudCDN subnet 1, TOR switch 1 can provide VLAN packets to BD1, and BD1 can directly send the VLAN packets to server 2.

[0101] In certain special circumstances, such as Figure 3As shown, if TOR switch 1 to TOR switch 2 are also connected to servers 9 to 12, and servers 9 to 12 are located in CloudCDN subnet 3, then TOR switch 1 connects servers 1 and 2 in CloudCDN subnet 1, and servers 9 and 10 in CloudCDN subnet 3. Therefore, TOR switch 1 will create BD1 and VBDIF port 1 bound to CloudCDN subnet 1, and BD2 and VBDIF port 2 bound to CloudCDN subnet 3. When server 1 needs to access server 9, TOR switch 1 can provide VLAN packets to BD1, BD1 can provide VLAN packets to VBDIF port 1, VBDIF port 1 can provide the original packets in the VLAN packets to VBDIF port 2, and VBDIF port 2 can provide VLAN packets to BD2, so that BD2 can provide VLAN packets to server 9.

[0102] It should be noted that BD can be a presentation method for the Layer 2 forwarding domain, and VBDIF port can be a presentation method for the Layer 3 forwarding gateway port. In practical applications, the Layer 2 forwarding domain and the Layer 3 forwarding gateway port can also have other presentation methods, which are not limited here.

[0103] More specifically, the first TOR switch can also perform the following operations:

[0104] When the cloud server needs to access the first server, it sends a fourth packet to the gateway. This fourth packet can be a VLAN packet or a raw packet, with the destination address being the IP address of the first server and the source address being the IP address of the cloud server. The gateway then encapsulates this fourth packet to obtain a third overlay packet, which uses the fourth packet as its inner packet. This third overlay packet can be a VXLAN packet, with the destination address being the IP address of the first TOR switch and the source address being the IP address of the gateway. The gateway then sends this third overlay packet to the first TOR switch. The first TOR switch then decapsulates the third overlay packet to obtain the fourth packet. Based on the forwarding rules recorded by the first TOR switch, it sends the fourth packet to the first server, thus completing the communication between the cloud server and the first server.

[0105] Continuing with the example above, when cloud server 1 needs to access server 1, cloud server 1 can send a VLAN packet 4 to the gateway. The destination address of VLAN packet 4 is the IP address of server 1, and the source address is the IP address of cloud server 1. The gateway generates a VXLAN packet 3 with VLAN packet 4 as the inner packet. The outer encapsulation of VXLAN packet 3 has the destination address of TOR switch 1 and the source address of the gateway's IP address.

[0106] Then, the gateway can forward VXLAN packet 3 to TOR switch 1, so that TOR switch 1 can send VLAN packet 4 in VXLAN packet 3 to server 1, thereby completing the communication between server 1 and cloud server 1.

[0107] More specifically, the first TOR switch can also perform the following operations:

[0108] When the second server needs to access the first server, it can send a fifth packet to the second TOR switch. This fifth packet can be a VLAN packet or a raw packet, with the destination address being the IP address of the first server and the source address being the IP address of the second server. The second TOR switch then encapsulates the fifth packet to obtain a fourth overlay packet, with the fifth packet as its inner packet. This fourth overlay packet can be a VXLAN packet, with the destination address being the IP address of the first TOR switch and the source address being the IP address of the second TOR switch. The second TOR switch then sends the fourth overlay packet to the first TOR switch. Subsequently, the first TOR switch decapsulates the fourth overlay packet to obtain the fifth packet. Based on the forwarding rules recorded by the first TOR switch, it sends the fifth packet to the first server, thus completing the communication between the second and first servers.

[0109] Continuing with the example above, when server 3 needs to access server 1, server 3 can send a VLAN packet 5 to TOR switch 2. The destination address of VLAN packet 5 is the IP address of server 1, and the source address is the IP address of server 3. TOR switch 2 generates a VXLAN packet 4 with VLAN packet 5 as the inner packet. The outer encapsulation of VXLAN packet 4 has the destination address of TOR switch 1 and the source address of TOR switch 2.

[0110] Then, TOR switch 2 can forward VXLAN packet 4 to TOR switch 1, so that TOR switch 1 can send VLAN packet 5 in VXLAN packet 4 to server 1, thereby completing the communication between server 1 and server 3.

[0111] More specifically, the first TOR switch can also perform the following operations:

[0112] When the third server needs to access the first server, it can send a sixth message to the second TOR switch. This sixth message can be a VLAN message or a raw message, with the destination address being the IP address of the first server and the source address being the IP address of the third server. The first TOR switch can then directly send the sixth message to the first server, thus completing the communication between the third and first servers.

[0113] Continuing with the example above, when server 2 needs to access server 1, server 2 can send VLAN packet 6 to TOR switch 1. The destination address of VLAN packet 6 is the IP address of server 1, and the source address is the IP address of server 2. TOR switch 1 then sends VLAN packet 6 to server 5, thus completing the communication between server 1 and server 2.

[0114] More specifically, the first TOR switch can also perform the following operations:

[0115] After configuration, the first TOR switch can also record access control rules (also known as access control lists, ACLs). These rules indicate the scope of accessibility for the first server. Therefore, when the first TOR switch receives the first packet, it can determine that the first server is about to access the cloud server. Based on the access control rules, the first TOR switch can determine whether the cloud server is within its accessible range. If so, the first TOR switch generates a first overlay packet based on the first packet and sends it to the gateway based on the forwarding rules. If not, the first TOR switch intercepts the first packet.

[0116] Furthermore, this access control rule can also be used to indicate the range of accessible servers to the first server. Therefore, when the first TOR switch receives the third overlay message, it can determine, based on the fourth message within the third overlay message, that the second server is about to access the first server. Thus, the first TOR can determine, based on the access control rule, whether the second server is within the range of accessible servers to the first server. If so, the first TOR switch sends the fourth message to the first server; otherwise, the first TOR switch intercepts the fourth message.

[0117] Similarly, when the first server accesses the second and third servers, the first TOR switch can also determine whether the second and third servers are within the range accessible to the first server based on access control rules. The same applies when the second and third servers access the first server; further details are omitted here.

[0118] Similarly, the access control rules of the first TOR switch can also be used to indicate the scope accessible to the third server and the scope of the third server that can be accessed. The access control rules of the second TOR switch can be used to indicate the scope accessible to the second server and the scope of the second server that can be accessed. These will not be elaborated on here.

[0119] Continuing with the example above, TOR switch 1 also records an ACL bound to CloudCDN subnet 1. This ACL indicates the accessible range of server 1 and the range of servers that can access server 1. Therefore, when server 1 needs to access cloud server 1, after receiving VLAN packet 1, TOR switch 1 can check whether cloud server 1 is within server 1's accessible range based on the ACL. If so, TOR switch 1 generates a VXLAN packet 1 with VLAN packet 1 as its inner packet and sends it to the gateway. If not, it intercepts VLAN packet 1 and does not send it outwards.

[0120] Similarly, when server 1 needs to access servers 2 and 3, TOR switch 1 can perform similar operations, which will not be elaborated here. Similarly, TOR switches 2 to TOR switches 4 also have corresponding ACLs configured, and their functions are similar, which will not be elaborated here.

[0121] It should be understood that the aforementioned CloudCDN subnets are typically set up within a VPC network. In certain special scenarios, if the VPC network cannot meet the tenant's business needs, servers not belonging to the public cloud system (including the aforementioned first, second, and third servers) can be equipped with additional processors (e.g., GPUs). These additional processors can be physically connected via TOR switches, thereby constructing a parameter network different from the VPC network. This allows these servers to complete the tenant's business through the parameter network, for example, such as... Figure 8 As shown ( Figure 8 (This is another structural diagram of the public cloud system provided in the embodiment of this application). Servers 1 to 8 can connect to TOR switches 9 to TOR switches 12 through their respective GPUs, thereby forming a parameter network that is different from the VPC network. It is worth noting that servers 1 to 8 can complete communication in the parameter network with only VLAN packets.

[0122] In this embodiment, when a tenant needs to bring a first server (not belonging to a public cloud system) into the cloud, the tenant can send a network configuration request to the cloud management platform. This request requests network configuration for the first server. Based on this request, the cloud management platform can configure a first TOR switch and a gateway for the first server. The first TOR switch records forwarding rules that instruct it to send packets destined for the IP address of the cloud server in the public cloud system to the gateway. When the first TOR switch receives a first packet from the first server, it determines that the destination address is the cloud server's IP address. Therefore, the first TOR switch generates a first overlay packet based on the forwarding rules and the first packet. This first packet serves as the inner packet of the first overlay packet. The first TOR switch then sends the first overlay packet to the gateway, enabling the gateway to send the inner packet (the first packet) to the cloud server, thus completing communication between the first server and the cloud server. In the aforementioned process, the first server, which is not part of the public cloud system, offloads its network forwarding capabilities to the first TOR switch. That is, the first TOR switch can act as the control center for communication between the first server and the cloud server of the public cloud system. Therefore, the traffic transmitted between the two is determined by the forwarding bandwidth of the first TOR switch. The forwarding bandwidth of the first TOR switch is often greater than the forwarding bandwidth of the smart network card on the first server. This is because, in high-traffic scenarios, the first TOR switch can also forward traffic from the first server to the cloud server in a timely and accurate manner to meet the traffic forwarding needs of the first server, thereby meeting the business needs of the tenant and improving the tenant experience to a certain extent.

[0123] Furthermore, in this embodiment of the application, when the first server can access the second server through the first TOR switch and the second TOR switch, it does not need to go through a gateway. This can reduce the dependence of servers that do not belong to the public cloud system on gateways when communicating. This can reduce the number of gateways that need to be deployed, thereby avoiding the cost increase caused by the continuous increase of gateway bandwidth. This can also reduce the management cost of the server and the overall cost of the server providing cloud services to tenants.

[0124] Furthermore, in this embodiment, the network forwarding process is completed at the first TOR switch, and the smart network card of the first server does not need to deploy virtualization software, thereby reducing the virtualization overhead of the first server. Moreover, the first TOR switch can provide the first server with multiple access schemes, achieving line-speed forwarding at most, and has no requirements on the model of the first server. Therefore, when the first server is a tenant's own server, the first TOR switch can provide access for various existing servers of the tenant, thereby saving the tenant's asset depreciation costs.

[0125] Furthermore, in this embodiment, the availability zone where the first server is located can be customized by the tenant. Therefore, the tenant can choose an availability zone that is closer to itself, so that the latency of the tenant accessing the first server is lower. Moreover, the tenant can even use the servers provided by the edge cloud of the public cloud system, which can also achieve lower latency for server access.

[0126] Furthermore, in this embodiment, the first server can be set not only in the VPC network, but also in the parameter network. Therefore, the tenant can use the first server to communicate with other servers (e.g., the second server, the third server, etc.) in different network planes, thereby meeting the different business needs of the tenant in different scenarios and further improving the tenant experience.

[0127] The above is a detailed description of the network configuration method based on a hybrid cloud scenario provided in the embodiments of this application. The cloud management platform provided in the embodiments of this application will be introduced below. Figure 9 A schematic diagram of the structure of the cloud management platform provided in the embodiments of this application is shown below. Figure 9 As shown, the cloud management platform is hosted in a public cloud system, which also includes infrastructure, including cloud servers. The cloud management platform includes:

[0128] The receiving module 901 is used to receive network configuration requests input by tenants, wherein the network configuration requests are used to request network configuration for a first server that does not belong to the public cloud system; for example, the receiving module 901 is used to implement Figure 4 Step 401 of the illustrated embodiment.

[0129] Configuration module 902 is used to configure the first TOR switch and the gateway based on a network configuration request. The first end of the first TOR switch is connected to the first server, and the second end of the first TOR switch is connected to the gateway. The first TOR switch records forwarding rules, which instruct the first TOR switch to send packets destined for the cloud server's Internet Protocol (IP) address to the gateway. For example, configuration module 902 is used to implement... Figure 4 Step 403 of the illustrated embodiment.

[0130] The first TOR switch is used to receive a first message sent by the first server, wherein the destination address of the first message is the IP address of the cloud server; the first TOR switch is also used to send a first superimposed message to the gateway based on forwarding rules, wherein the inner message of the first superimposed message is the first message; for example, the first TOR switch is used to implement Figure 4 Steps 403 and 404 of the illustrated embodiment.

[0131] A gateway is used to send the first message in the first overlay message to the cloud server. For example, a gateway is used to implement... Figure 4 Step 405 of the illustrated embodiment.

[0132] In one possible implementation, the network configuration request is further used to instruct network configuration for a second server that does not belong to the public cloud system; the configuration module 902 is further used to configure a second TOR switch, wherein a first end of the second TOR switch is connected to the second server, and a second end of the second TOR switch is connected to the first TOR switch; the forwarding rules are further used to instruct the first TOR switch to send packets with a destination address of the second server's IP address to the second TOR switch; the first TOR switch is further used to receive a second packet sent by the first server, wherein the destination address of the second packet is the second server's IP address; the first TOR switch is further used to send a second overlay packet to the second TOR switch based on the forwarding rules, wherein the inner packet of the second overlay packet is the second packet; the second TOR switch is used to send the second packet in the second overlay packet to the second server.

[0133] In one possible implementation, the network configuration request is also used to instruct network configuration for a third server that does not belong to the public cloud system, and the third end of the first TOR switch is connected to the third server; the first TOR switch is also used to receive a third message sent by the first server, wherein the destination address of the third message is the IP address of the third server; the first TOR switch is also used to send the third message to the third server.

[0134] In one possible implementation, the forwarding rule is also used to instruct packets whose destination address is the IP address of the first server to be sent to the first server; the first TOR switch is also used to receive a third overlay packet sent by the gateway, wherein the inner packet of the third overlay packet is a fourth packet, the destination address of the fourth packet is the IP address of the first server, and the source address of the fourth packet is the IP address of the cloud server; the first TOR switch is also used to send the fourth packet in the third overlay packet to the first server based on the forwarding rule.

[0135] In one possible implementation, the first TOR switch is also used to receive a fourth overlay message sent by the second TOR switch, wherein the inner message of the fourth overlay message is a fifth message, the destination address of the fifth message is the IP of the first server, and the source address of the fifth message is the IP of the second server; the first TOR switch is also used to send the fifth message in the fourth overlay message to the first server based on forwarding rules.

[0136] In one possible implementation, the first TOR switch is also used to receive a sixth message sent by the third server, wherein the destination address of the sixth message is the IP address of the first server and the source address of the sixth message is the IP address of the third server; the first TOR switch is also used to send the sixth message to the first server.

[0137] In one possible implementation, the first TOR switch also records access control rules, which are used to indicate the range accessible to the first server. The first TOR switch, based on the access control rules, determines that the cloud server is located within the range, and then sends the first overlay packet to the gateway based on the forwarding rules.

[0138] In one possible implementation, the first server is either the tenant's local server or a cloud server of a third-party public cloud system.

[0139] It should be noted that the information interaction and implementation process between the modules / units of the above-mentioned device are based on the same concept as the method embodiments of this application, and the resulting technical effects are the same as those of the method embodiments of this application. For details, please refer to the description in the method embodiments shown above in the embodiments of this application, and will not be repeated here.

[0140] Please see Figure 10 , Figure 10 This is a schematic diagram of a computing device provided in an embodiment of this application. Figure 10 As shown, the computing device 1000 (which can be used to present the aforementioned cloud management platform, first server, first TOR switch, or gateway, etc.; for ease of explanation, the computing device 1000 is used as a cloud management platform in the following schematic description) includes: a processor 1001, a memory 1002, a communication interface 1003, and a bus 1004. The processor 1001, memory 1002, and communication interface 1003 are coupled through the bus (not shown in the figure). The memory 1002 stores instructions. When the execution instructions in the memory 1002 are executed, the computing device 1000 performs the method described in the above method embodiment.

[0141] The computing device 1000 may be one or more integrated circuits configured to implement the methods described above, such as: one or more application-specific integrated circuits (ASICs), or one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), or a combination of at least two of these forms of integrated circuits. Furthermore, when the units in the device can be implemented in the form of a processing element scheduler, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processor capable of calling programs. Alternatively, these units may be integrated together and implemented as a system-on-a-chip (SOC).

[0142] The processor 1001 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0143] The memory 1002 can be volatile memory or non-volatile memory, or it can include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0144] The memory 1002 stores executable program code, and the processor 1001 executes the executable program code to implement the functions of the aforementioned receiving module and configuration module, thereby realizing the network configuration method based on the hybrid cloud scenario. That is, the memory 1002 stores instructions for executing the aforementioned network configuration method based on the hybrid cloud scenario.

[0145] The communication interface 1003 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 1000 and other devices or communication networks.

[0146] In addition to the data bus, the 1004 bus can also include a power bus, a control bus, and a status signal bus. The bus can be a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL) bus, a Cache Coherent Interconnect for Accelerators (CCIX) bus, etc. The bus can be divided into address bus, data bus, and control bus.

[0147] Please see Figure 11 , Figure 11 This is a schematic diagram of a computing device cluster provided in an embodiment of this application. Figure 11 As shown, the computing device cluster 1100 includes at least one computing device 1000.

[0148] like Figure 11 As shown, the computing device cluster 1100 includes at least one computing device 1000. The memory 1002 of one or more computing devices 1000 in the computing device cluster 1100 may store the same instructions for executing the network configuration method based on the hybrid cloud scenario described above.

[0149] In some possible implementations, the memory 1002 of one or more computing devices 1000 in the computing device cluster 1100 may also store partial instructions for executing the network configuration method based on the hybrid cloud scenario described above. In other words, a combination of one or more computing devices 1000 can jointly execute the network configuration method based on the hybrid cloud scenario described above.

[0150] It should be noted that the memory 1002 of different computing devices 1000 in the computing device cluster 1100 can store different instructions, which are used to execute some of the functions of the cloud management platform. That is, the instructions stored in the memory 1002 of different computing devices 1000 can realize the functions of one or more modules such as the receiving module and the configuration module.

[0151] In some possible implementations, one or more computing devices 1000 in the computing device cluster 1100 can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc.

[0152] Please see Figure 12 , Figure 12 This is a schematic diagram illustrating the network connection of computer devices in a computer cluster provided in an embodiment of this application. Figure 12 As shown, the two computing devices 1000A and 1000B are connected via a network. Specifically, they are connected to the network through the communication interfaces in each computing device.

[0153] In one possible implementation, the memory in computing device 1000A stores instructions for performing the functions of modules such as the receiving module. Meanwhile, the memory in computing device 1000B stores instructions for performing the functions of modules such as the configuration module.

[0154] It should be understood that Figure 12 The functions of computing device 1000A shown can also be performed by multiple computing devices. Similarly, the functions of computing device 1000B can also be performed by multiple computing devices.

[0155] This application also relates to a computer storage medium storing a program for signal processing, which, when run on a computer, causes the computer to perform actions such as... Figure 4 The steps performed by the cloud management platform in the illustrated embodiment.

[0156] This application also relates to a computer program product that stores instructions that, when executed by a computer, cause the computer to perform actions such as... Figure 4 The steps performed by the cloud management platform in the illustrated embodiment.

[0157] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0158] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0159] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0160] 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 unit can be implemented in hardware or as a software functional unit.

[0161] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part 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 to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A network configuration method based on a hybrid cloud scenario, characterized in that, The method is applied to a cloud management platform of a public cloud system, the cloud management platform being used to manage the infrastructure of the public cloud system, the infrastructure including cloud servers, and the method comprising: The cloud management platform receives a network configuration request input by a tenant, wherein the network configuration request is used to request network configuration for a first server that does not belong to the public cloud system; Based on the network configuration request, the cloud management platform configures a first top-mounted TOR switch and a gateway. The first end of the first TOR switch is connected to the first server, and the second end of the first TOR switch is connected to the gateway. The first TOR switch records forwarding rules, which are used to instruct the first TOR switch to send packets whose destination address is the Internet Protocol IP of the cloud server to the gateway. The first TOR switch receives a first message sent by the first server, wherein the destination address of the first message is the IP address of the cloud server; The first TOR switch sends the first superimposed packet to the gateway based on the forwarding rules, wherein the inner packet of the first superimposed packet is the first packet; The gateway sends the first message in the first superimposed message to the cloud server.

2. The method according to claim 1, characterized in that, The network configuration request is also used to instruct network configuration for a second server that does not belong to the public cloud system, and the method further includes: The cloud management platform is configured with a second TOR switch, wherein the first end of the second TOR switch is connected to the second server, the second end of the second TOR switch is connected to the first TOR switch, and the forwarding rule is also used to instruct the first TOR switch to send packets whose destination address is the IP of the second server to the second TOR switch. The first TOR switch receives a second message sent by the first server, wherein the destination address of the second message is the IP address of the second server; The first TOR switch sends the second superimposed packet to the second TOR switch based on the forwarding rule, wherein the inner packet of the second superimposed packet is the second packet; The second TOR switch sends the second message in the second overlay message to the second server.

3. The method according to claim 1 or 2, characterized in that, The network configuration request is also used to instruct network configuration for a third server that does not belong to the public cloud system, wherein the third end of the first TOR switch is connected to the third server, and the method further includes: The first TOR switch receives a third message sent by the first server, wherein the destination address of the third message is the IP address of the third server; The first TOR switch sends the third message to the third server.

4. The method according to any one of claims 1 to 3, characterized in that, The forwarding rule is further used to instruct packets destined for the IP address of the first server to be sent to the first server, and the method further includes: The first TOR switch receives a third overlay message sent by the gateway, wherein the inner message of the third overlay message is a fourth message, the destination address of the fourth message is the IP of the first server, and the source address of the fourth message is the IP of the cloud server. Based on the forwarding rules, the first TOR switch sends the fourth packet in the third superimposed packet to the first server.

5. The method according to claim 4, characterized in that, The method further includes: The first TOR switch receives a fourth overlay message sent by the second TOR switch, wherein the inner message of the fourth overlay message is a fifth message, the destination address of the fifth message is the IP of the first server, and the source address of the fifth message is the IP of the second server. Based on the forwarding rules, the first TOR switch sends the fifth packet in the fourth superimposed packet to the first server.

6. The method according to claim 4 or 5, characterized in that, The method further includes: The first TOR switch receives a sixth message sent by the third server, wherein the destination address of the sixth message is the IP address of the first server, and the source address of the sixth message is the IP address of the third server. The first TOR switch sends the sixth message to the first server.

7. The method according to any one of claims 1 to 6, characterized in that, The first TOR switch also records access control rules, which indicate the scope accessible to the first server. Based on these forwarding rules, the first TOR switch sends the first overlay packet to the gateway, including: If the first TOR switch determines that the cloud server is within the range based on the access control rules, it will send the first superimposed packet to the gateway based on the forwarding rules.

8. The method according to any one of claims 1 to 7, characterized in that, The first server is either the tenant's local server or a cloud server of a third-party public cloud system.

9. A public cloud system, characterized in that, The public cloud system includes a cloud management platform and infrastructure. The cloud management platform is used to manage the infrastructure, and the infrastructure includes cloud servers, wherein: The cloud management platform is used to receive network configuration requests input by tenants, wherein the network configuration requests are used to request network configuration for a first server that does not belong to the public cloud system; The cloud management platform is also used to configure a first TOR switch and a gateway based on the network configuration request. The first end of the first TOR switch is connected to the first server, the second end of the first TOR switch is connected to the gateway, and the first TOR switch records forwarding rules. The forwarding rules are used to instruct the first TOR switch to send packets whose destination address is the Internet Protocol IP of the cloud server to the gateway. The first TOR switch is used to receive a first message sent by the first server, wherein the destination address of the first message is the IP address of the cloud server; The first TOR switch is further configured to send the first superimposed packet to the gateway based on the forwarding rules, wherein the inner packet of the first superimposed packet is the first packet; The gateway is used to send the first message in the first superimposed message to the cloud server.

10. The system according to claim 9, characterized in that, The network configuration request is also used to instruct network configuration to be performed on a second server that does not belong to the public cloud system; The cloud management platform is also used to configure a second TOR switch, wherein the first end of the second TOR switch is connected to the second server, the second end of the second TOR switch is connected to the first TOR switch, and the forwarding rule is also used to instruct the first TOR switch to send packets whose destination address is the IP of the second server to the second TOR switch. The first TOR switch is also used to receive a second message sent by the first server, wherein the destination address of the second message is the IP address of the second server; The first TOR switch is further configured to send the second superimposed packet to the second TOR switch based on the forwarding rules, wherein the inner packet of the second superimposed packet is the second packet; The second TOR switch is used to send the second message in the second superimposed message to the second server.

11. The system according to claim 9 or 10, characterized in that, The network configuration request is also used to instruct network configuration for a third server that does not belong to the public cloud system, and the third end of the first TOR switch is connected to the third server. The first TOR switch is also used to receive a third message sent by the first server, wherein the destination address of the third message is the IP address of the third server; The first TOR switch is also used to send the third message to the third server.

12. The system according to any one of claims 9 to 11, characterized in that, The forwarding rule is also used to instruct packets whose destination address is the IP address of the first server to be sent to the first server; The first TOR switch is also used to receive a third overlay message sent by the gateway, wherein the inner message of the third overlay message is a fourth message, the destination address of the fourth message is the IP of the first server, and the source address of the fourth message is the IP of the cloud server. The first TOR switch is also configured to send the fourth packet in the third superimposed packet to the first server based on the forwarding rules.

13. The system according to claim 12, characterized in that, The first TOR switch is also used to receive a fourth overlay message sent by the second TOR switch, wherein the inner message of the fourth overlay message is a fifth message, the destination address of the fifth message is the IP of the first server, and the source address of the fifth message is the IP of the second server. The first TOR switch is also configured to send the fifth packet in the fourth superimposed packet to the first server based on the forwarding rules.

14. The system according to claim 12 or 13, characterized in that, The first TOR switch is also used to receive a sixth message sent by a third server, wherein the destination address of the sixth message is the IP address of the first server and the source address of the sixth message is the IP address of the third server. The first TOR switch is also used to send the sixth message to the first server.

15. The system according to any one of claims 9 to 14, characterized in that, The first TOR switch also records access control rules, which are used to indicate the range that the first server can access. The first TOR switch, based on the access control rules, determines that the cloud server is located in the range, and then sends the first superimposed packet to the gateway based on the forwarding rules.

16. The system according to any one of claims 9 to 15, characterized in that, The first server is either the tenant's local server or a cloud server of a third-party public cloud system.

17. A computing device cluster, characterized in that, The computing device cluster includes at least one computing device, each computing device including a processor and memory: The memory is used to store instructions; The processor is configured to, according to the instructions, cause the computing device cluster to perform the method of any one of claims 1 to 8.

18. A computer storage medium, characterized in that, The computer storage medium stores one or more instructions that, when executed by one or more computers, cause the one or more computers to perform the method of any one of claims 1 to 8.

19. A computer program product, characterized in that, The computer program product stores instructions that, when executed by a computer, cause the computer to perform the method described in any one of claims 1 to 8.

Images