Cloud tenant bearing scale optimization method and device, equipment, medium and product

Abstract

The invention relates to the technical field of cloud computing, in particular to a cloud tenant bearing scale optimization method and device, equipment, a medium and a product, and the method comprises the steps: recognizing a sender and an access purpose of an access request, and determining a data flow direction corresponding to the access request; in response to the condition that the sender is the virtual machine, address conversion and message encapsulation are performed on the access request through the virtual switch, and the encapsulated access request is sent to the cloud gateway; and in response to the fact that the sender is the Underlay network or the public network, the cloud gateway is determined based on the sender, the cloud gateway confirms the virtual private cloud based on the access purpose, the access request is subjected to message packaging, and the access request is sent to the virtual switch. According to the technical scheme of the invention, the original address translation is sunk to the virtual switches corresponding to the virtual private clouds from the cloud gateway for processing according to the data in the cloud-out direction and the cloud-in direction, so that the memory space occupied by the NAT table items can be released, the detailed routing capacity of the virtual machines is improved, and the expansion of the cloud tenant scale borne by the cloud data center is facilitated.

Description

Technical Field

[0001] This disclosure relates to the field of cloud computing technology, and in particular to a method, apparatus, device, medium and product for optimizing cloud tenant capacity. Background Technology

[0002] With the acceleration of digital transformation and the construction of computing networks, the number of cloud tenants that cloud data centers can support is growing rapidly. Cloud tenants are users who subscribe to cloud services such as cloud servers, public IP addresses, and underground services on cloud platforms. To meet the resource isolation requirements of cloud tenants, cloud service providers build Virtual Private Clouds (VPCs) within cloud gateways, assigning a unique identifier to each VPC. Virtual machines (VMs) of cloud tenants within the same VPC can communicate with each other, while VMs in different VPCs are isolated from each other and transparent to each other.

[0003] When handling communication between VMs and the public or underlay networks, related technologies typically perform network address translation on the cloud gateway (north-south or east-west cloud gateway), such as the translation between overlay IPs and public IPs. The routing details of these address translations are recorded in the Network Address Translation (NAT) table. However, due to the rapid growth in the number of cloud tenants, a large number of NAT table entries are required, causing the cloud gateway to be unable to handle the communication needs of a large number of VMs, which seriously affects the scale of cloud tenants that the cloud data center can support. Summary of the Invention

[0004] In view of the above problems, this disclosure is made to provide a method, apparatus, device, medium and product for optimizing cloud tenant capacity.

[0005] According to one aspect of this disclosure, a method for optimizing cloud tenant capacity is provided, comprising: Obtain access requests and identify the sender and purpose of the access requests; the sender includes the Underlay network, the public network, and virtual machines created by cloud tenants; Based on the sender, determine the data flow direction corresponding to the access request; the data flow direction includes the outbound direction and the inbound direction. In response to the fact that the sender is a virtual machine, the direction of data flow is confirmed to be out of the cloud, and the cloud gateway corresponding to the access request is determined based on the access purpose; the access request is forwarded to the virtual switch corresponding to the virtual machine, and the virtual switch performs network address translation and packet encapsulation on the access request, and sends the encapsulated access request to the cloud gateway. In response to the sender being an Underlay network or a public network, the system confirms that the data flow direction is to the cloud. Based on the sender, it determines the cloud gateway corresponding to the access request. The cloud gateway determines the corresponding Virtual Private Cloud based on the access destination. Based on the Virtual Private Cloud, it encapsulates the access request into a message and sends the encapsulated access request to the virtual switch corresponding to the Virtual Private Cloud.

[0006] The beneficial effects of this solution are as follows: For data in the cloud outbound and cloud inbound directions, network address translation is performed through virtual switches. The original address translation is moved down from the cloud gateway to the virtual switches corresponding to each virtual private cloud. This can free up the memory space occupied by NAT entries, improve the detailed routing capacity of virtual machines, and help expand the scale of cloud tenants supported by the cloud data center.

[0007] Furthermore, the cloud tenant capacity optimization method according to one aspect of this disclosure also includes: Assign an Overlay IP to the virtual machine created by the cloud tenant and record the Overlay IP in the virtual switch running the virtual machine; the Overlay IP is effective and unique in the virtual private cloud to which the virtual machine belongs, and the virtual switch and the virtual private cloud are corresponding; When a virtual machine first requests to communicate with the Underlay network, a Dummyf IP is assigned to the virtual machine, and the Dummyf IP is bound to the Overlay IP to form the first mapping relationship; the Underlay network is the basic layer network in the computer network architecture. When the virtual machine communicates with the public network for the first time, the virtual machine's public IP address is bound to the Overlay IP address, forming a second mapping relationship.

[0008] In one or more embodiments, the beneficial effect of this solution is as follows: when a virtual machine first accesses the Underlay network or is first accessed by the Underlay network, a Dummyf IP is assigned to the virtual machine, and the detailed route of the Dummyf IP is configured simultaneously. Overlay IPs and Dummyf IPs are pre-planned Underlay IP address ranges, and each virtual machine's Dummyf IP is unique. Previously, detailed routes were configured for each cloud tenant's virtual machine on the cloud gateway to locate the virtual private cloud where the tenant's VM resided. This solution, however, only configures detailed routes for the virtual machines that actually communicate with the Underlay network, significantly reducing the number of detailed routes and increasing the scale of virtual machines that can be supported.

[0009] Furthermore, according to one aspect of the cloud tenant capacity optimization method disclosed herein, network address translation and packet encapsulation of access requests are performed through a virtual switch, including: In response to the access destination being the Underlay network, the source address in the access request is translated into a Dummyf IP via a virtual switch. The translated access request is then encapsulated into a VXLAN packet. The VXLAN packet is used to identify the virtual switch to which the virtual machine belongs. The Dummyf IP is the IP address of the virtual machine in the Underlay network. The Dummyf IP is mapped to the Overlay IP of the virtual machine. The Overlay IP is the unique identifier of the virtual machine in its virtual private cloud. In response to the public network being the destination of the access, the source address in the access request is translated into the public IP address of the virtual machine through the virtual switch. The translated access request is then encapsulated into a VXLAN packet, in which the VXLAN packet is used to identify the virtual switch to which the sender belongs, and the public IP address is mapped to the overlay IP address of the virtual machine.

[0010] In one or more embodiments, the beneficial effects of this solution are as follows: For data communication in the cloud direction, the virtual private cloud where the virtual machine issuing the access request resides is first determined, and then the corresponding virtual switch is determined, with the virtual switch performing address translation. Compared to performing network address translation on the cloud gateway, this significantly frees up NAT entries in the cloud gateway, improving detailed routing capacity. Through packet encapsulation, the VXLAN packet can characterize the virtual private cloud from which the access request originates or is destined.

[0011] Furthermore, according to one aspect of the cloud tenant capacity optimization method of this disclosure, after sending the encapsulated access request to the cloud gateway, it also includes: The cloud gateway unpacks the access request message and confirms that the data flow direction of the access request is outbound from the cloud. The cloud gateway forwards access requests to the virtual router on the local area network (LAN), which then forwards the requests based on the routing address in the access request.

[0012] In one or more embodiments, the beneficial effects of this solution are as follows: For data in the cloud outbound direction, all data is sent by the local area network-side virtual routing forwarding of the cloud gateway. The local area network-side virtual routing forwarding can serve all virtual private clouds. Compared with the original one virtual routing forwarding bound to one virtual private cloud, the number of virtual routing forwardings is greatly reduced. The scale of virtual routing forwarding is no longer limited by the chip capacity, which is conducive to increasing the scale of virtual private clouds that can be processed.

[0013] Furthermore, according to one aspect of the cloud tenant capacity optimization method disclosed herein, the cloud gateway identifies the corresponding virtual private cloud based on the access purpose, including: The WAN-side virtual router in the cloud gateway identifies the access destination, which is either the virtual machine's DummyfIP or the public IP address. In response to an access destination being a virtual machine's Dummyf IP, the cloud gateway, based on the first mapping table, determines the virtual machine's Overlay IP and the corresponding Virtual Private Cloud based on the Overlay IP. The first mapping table is used to record the mapping relationship between the virtual machine's Overlay IP and Dummyf IP. In response to an access destination being a public IP address of a virtual machine, the cloud gateway confirms the virtual machine's Overlay IP address based on the second mapping table and the public IP address, and then confirms the corresponding virtual private cloud based on the Overlay IP address. The second mapping table is used to record the mapping relationship between the virtual machine's Overlay IP address and the public IP address.

[0014] In one or more embodiments, the beneficial effects of this solution are as follows: For data entering the cloud, all data is processed and sent by the WAN-side virtual routing forwarding within the cloud gateway. The WAN-side virtual routing forwarding can serve all virtual private clouds, significantly reducing the number of virtual routing forwardings compared to the original method of binding one virtual routing forwarding to one virtual private cloud. Through the first and second mapping relationship tables, the cloud gateway can clearly identify the specific virtual machine for the access request.

[0015] Furthermore, according to one aspect of the cloud tenant capacity optimization method of this disclosure, after sending the encapsulated access request to the virtual switch corresponding to the virtual private cloud, the method further includes: The virtual switch decapsulates access request packets to identify the purpose of access; In response to the Dummyf IP address of the virtual machine being accessed, the virtual switch identifies the Overlay IP address of the virtual machine based on the first mapping table and sends an access request to the Overlay IP address. In response to an access request to a virtual machine's public IP address, the virtual switch identifies the virtual machine's Overlay IP address based on the second mapping table and sends an access request to the Overlay IP address.

[0016] In one or more embodiments, the beneficial effect of this solution is that the virtual switch is configured with detailed routes for virtual machines, and by identifying the access destination, access requests can be routed to the correct virtual machine.

[0017] Furthermore, according to the cloud tenant capacity optimization method of one aspect of this disclosure, the cloud gateway includes an east-west cloud gateway and a north-south cloud gateway. The east-west cloud gateway is used to handle data interaction between virtual machines and the Underlay network, and the north-south cloud gateway is used to handle data interaction between virtual machines and the public network. Determine the cloud gateway corresponding to the access request based on the access purpose, including: If the access destination is the Underlay network, the cloud gateway corresponding to the access request is determined to be an east-west cloud gateway; if the access destination is the public network, the cloud gateway corresponding to the access request is determined to be a north-south cloud gateway.

[0018] In one or more embodiments, the beneficial effect of this solution is that when the sender is a virtual machine, the access destination is either the Underlay network or the public network, and the corresponding cloud gateway can be determined by identifying the specific access destination.

[0019] Furthermore, according to one aspect of the cloud tenant capacity optimization method disclosed herein, the cloud gateway corresponding to the access request is determined based on the sender, including: If the sender is an Underlay network, the cloud gateway corresponding to the access request is determined to be an east-west cloud gateway; if the sender is a public network, the cloud gateway corresponding to the access request is determined to be a north-south cloud gateway.

[0020] In one or more embodiments, the beneficial effect of this solution is that when the sender is an Underlay network or a public network, the access destination is a virtual machine, but the specific access address is the virtual machine's dummy IP on the Underlay network or its public IP. By identifying the specific sender, the corresponding cloud gateway can be determined.

[0021] Furthermore, according to one aspect of the cloud tenant capacity optimization method disclosed herein, the data flow direction corresponding to the access request is determined based on the sender, including: In response to the fact that the sender is a virtual machine, the data flow direction corresponding to the access request is determined to be the outbound direction; wherein, the virtual machine is created by the cloud tenant and located in the cloud data center, and the outbound direction means that the data flows from the cloud data center to the outside. In response to whether the sender is an Underlay network or a public network, the direction of data flow corresponding to the access request is determined as the cloud inbound direction; where the Underlay network and the public network are located outside the cloud data center, the cloud inbound direction means that the data flows from the outside to the cloud data center.

[0022] Furthermore, the cloud tenant capacity optimization method according to one aspect of this disclosure also includes: On the east-west cloud gateway, set resource thresholds for each virtual private cloud. The resource thresholds represent the bandwidth resources that virtual machines within each virtual private cloud can share within the threshold.

[0023] In one or more embodiments, the beneficial effects of this solution are as follows: since east-west traffic is free, by setting resource thresholds for each virtual private cloud and limiting the maximum bandwidth resources, it is possible to avoid a single cloud tenant or virtual machine consuming too many resources and affecting other cloud tenants.

[0024] According to another aspect of this disclosure, a cloud tenant capacity optimization apparatus is provided, comprising: The first identification module is used to obtain access requests and identify the sender and purpose of the access requests; the sender includes the Underlay network, the public network, and virtual machines created by cloud tenants; The second identification module is used to determine the data flow direction corresponding to the access request based on the sender; wherein, the data flow direction includes the outbound direction and the inbound direction; The cloud outbound processing module is used to respond to the fact that the sender is a virtual machine, confirm that the data flow direction is outbound, determine the cloud gateway corresponding to the access request based on the access purpose, forward the access request to the virtual switch corresponding to the virtual machine, perform network address translation and packet encapsulation on the access request through the virtual switch, and send the encapsulated access request to the cloud gateway. The cloud inbound processing module is used to respond to whether the sender is an Underlay network or a public network, confirm that the data flow direction is to the cloud, determine the cloud gateway corresponding to the access request based on the sender, the cloud gateway determines the corresponding virtual private cloud based on the access destination, encapsulates the access request message based on the virtual private cloud, and sends the encapsulated access request to the virtual switch corresponding to the virtual private cloud.

[0025] According to another aspect of this disclosure, a computer device is provided, including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement the method of one aspect above.

[0026] According to another aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method of one aspect above.

[0027] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method of the above-described aspect.

[0028] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0029] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0030] Figure 1 This is a system architecture diagram illustrating a cloud tenant capacity optimization method according to an embodiment of this disclosure.

[0031] Figure 2 This is a network logic diagram illustrating an application according to an embodiment of this disclosure.

[0032] Figure 3 This is a flowchart illustrating a cloud tenant capacity optimization method according to an embodiment of the present disclosure.

[0033] Figure 4 This is a schematic diagram of the structure of a cloud tenant capacity optimization device according to an embodiment of the present disclosure.

[0034] Figure 5 This is a schematic diagram illustrating the structure of a computer device according to an embodiment of the present disclosure.

[0035] Figure 6 This is a schematic diagram illustrating a computer program product according to an embodiment of the present disclosure. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this disclosure more apparent, exemplary embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure. It should be understood that this disclosure is not limited to the exemplary embodiments described herein.

[0037] With the acceleration of digital transformation and the construction of computing networks, the number of cloud tenants that cloud data centers can support is growing rapidly. Cloud tenants are users who subscribe to cloud services such as cloud servers, public IP addresses, and underlay services on cloud platforms. In a complete cloud data center network environment, various types of switches provide underlay network services, such as access switches, aggregation switches, and core switches, while devices such as controllers, virtual switches, or cloud gateways provide overlay networks for cloud data center virtualization.

[0038] To meet the resource isolation requirements of cloud tenants, cloud service providers build Virtual Private Clouds (VPCs) within the public cloud using overlay network protocols such as VXLAN. Each VPC is assigned a unique VXLAN Network Identifier (VNI). Virtual machines (VMs) within the same VPC can communicate with each other, while VMs in different VPCs are isolated and transparent to each other. When a VM needs to access the public network or provide services to the public network, it needs to subscribe to a public IP address through the cloud platform and bind to that public IP address, accessing the public network through a north-south cloud gateway. When a VM needs to access resources in other Internet Data Centers (IDCs), it can access underlay network services through an east-west gateway.

[0039] The advantages of VPCs have attracted a large number of cloud tenants, who can connect to VPCs in the public cloud from anywhere. A software-defined networking solution is deployed in the same region to build an overlay network, with each region containing a large number of VPCs and virtual machines (VMs). A unique VNI is assigned to each VPC, and VMs within a VPC share the same VNI to achieve network isolation. Multiple VMs are hosted on physical servers via a hypervisor, and virtual switches running within the hypervisor allow communication between VMs. The cloud gateway plays a crucial role in the cloud computing infrastructure because it is the precise central hub for north-south traffic (VM-Internet) and east-west traffic (VM-Underlay services) across the entire cloud network.

[0040] With the acceleration of digital transformation and the construction of computing networks, the number of VPCs and VMs in a large cloud data center is growing rapidly. For example, a large cloud data center often contains 100,000 VPCs and 1 million VMs. Therefore, current cloud services have the following drawbacks: (1) Tenant isolation is achieved by allocating Virtual Routing Forwarding (VRF) in the cloud gateway. One VPC corresponds to one VRF. However, the mapping table of VRF in the current cloud gateway is limited by the capacity of the underlying switching chip. A single device can only support the processing scale of tens of thousands of VPCs, which is not up to the current number of VPCs and seriously affects the scale of cloud tenants that the cloud data center can support. (2) Detailed routes are configured for each VM in the east-west cloud gateway. One VM corresponds to one detailed route. The east-west cloud gateway uses detailed routes to find the physical server location and VPC corresponding to the VM. One VPC corresponds to one VNI. Therefore, there are a large number of detailed routes on the east-west cloud gateway to correspond to different VMs. Due to the limited capacity of the underlying switching chip, a single device can only reach a VM processing scale of 100,000.

[0041] (3) When handling communication between VMs and the public network, the overlay IP to public IP address is usually translated on the north-south cloud gateway; when handling communication between VMs and the underlay network, the overlay IP to dummy IP address is usually translated on the east-west cloud gateway. The routing details of these address translations are recorded in the network address translation (NAT) table of the cloud gateway. However, as the scale of VMs increases, they will occupy a large number of NAT table entries on the cloud gateway, causing the cloud gateway to be unable to support the communication needs of a large number of VMs, which seriously affects the scale of cloud tenants that the cloud data center can support.

[0042] (4) If the cluster mode is used for horizontal expansion, it can support the resource scale of hundreds of thousands of VPCs and millions of VMs, but it will complicate the networking mode and greatly increase the cost of software and hardware.

[0043] The above description, with reference to the accompanying drawings, describes a method, apparatus, device, medium, and product for optimizing cloud tenant capacity according to embodiments of the present disclosure. By linking cloud gateway services with controllers and virtual machine switches, the network address translation process is offloaded to the virtual machine switches, reducing the load on the cloud gateway and eliminating limitations imposed by chip capacity, thereby increasing the processing scale of VMs.

[0044] By using cloud gateway services in conjunction with controllers and virtual machine switches, for example, when a VM accesses the public network, the virtual switch performs the conversion between the overlay IP and the public network IP and then sends the VXLAN packets to the north-south cloud gateway. At the north-south cloud gateway, different VPCs are associated with the same VRF, and the outbound packets are sent in a unified manner. Compared with the original method of one VPC associated with one VRF, the scale and number of VRFs are greatly reduced, which is conducive to supporting a larger scale of VPC processing.

[0045] For VMs accessing the Underlay network from the cloud or vice versa, address translation between Overlay IP and Dummy IP is performed on the virtual switch side. Taking VM access to the Underlay network as an example, after network address translation is completed on the virtual switch side, the packets are sent to the east-west cloud gateway via VXLAN. On the east-west cloud gateway side, different VPCs are associated with the same VRF, and the outbound packets are then uniformly sent to the Underlay network. Compared to the previous method of one VPC associated with one VRF, this significantly reduces the number of VRFs and is beneficial for supporting a larger VPC processing scale.

[0046] To facilitate understanding of this embodiment, a detailed description of the cloud tenant capacity optimization method disclosed in this disclosure is provided first. The execution entity of the cloud tenant capacity optimization method provided in this disclosure is generally a computer device with certain computing capabilities. This computer device may include, for example, a terminal device, a server, or other processing devices. The terminal device may be a user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. In some possible implementations, this cloud tenant capacity optimization method can be implemented by the processor calling computer-readable instructions stored in memory.

[0047] like Figure 1 The diagram shown is a system architecture diagram of the cloud tenant capacity optimization method provided in this embodiment of the disclosure, including a cloud platform 1, an underlay network 2, an overlay network 3, a virtual switch 4, a north-south cloud gateway 5, and an east-west cloud gateway 6. The following is a detailed description of each device: Cloud platform: This is the entry point for cloud tenants to configure cloud services. Users can subscribe to resources such as cloud servers, public IP addresses, and Underlay network services.

[0048] Underlay network: A bearer network composed of various physical devices that uses routing or switching protocols to ensure IP connectivity between the devices.

[0049] Overlay network: One or more virtual logical networks built on the Underlay network using VXLAN network virtualization technology (different logical networks are distinguished by VNI). Although different Overlay networks share the devices and lines in the Underlay network, the services in the Overlay network are decoupled from the physical networking and interconnection technologies in the Underlay network. Multiple instances of the Overlay network are called Virtual Private Cloud (VPC), which can serve different services of the same cloud tenant or different cloud tenants, and is a core networking technology used in cloud data center SDN solutions.

[0050] Virtual Switch (OVS): Managed by the SDN controller via the OpenFlow protocol. There is a one-to-one correspondence between OVS and VPC.

[0051] North-South Cloud Gateway: A type of cloud gateway that provides public network access services to cloud tenants. A North-South cloud gateway is configured with a WAN-side VRF and a LAN-side VRF. Specifically, the WAN-side VRF handles inbound traffic to the cloud, and the LAN-side VRF handles outbound traffic from the cloud.

[0052] East-West Cloud Gateway: A type of cloud gateway that provides cloud tenants with access to Underlay network services, allowing them to access Underlay network services such as object storage and DNS resolution. The East-West Cloud Gateway is configured with a WAN-side VRF and a LAN-side VRF. Specifically, the WAN-side VRF handles inbound traffic to the cloud, while the LAN-side VRF handles outbound traffic from the cloud.

[0053] In this preferred embodiment, the following are also included: Software-defined networking (SDN) is a network solution for virtualizing networks in cloud data centers. It includes key components such as SDN controllers, cloud gateways, virtual switches, and top-of-rack switches.

[0054] Top-of-Rack (TOR) switches: These switches have VXLAN packet processing capabilities, can be managed by the SDN controller, and can be connected to the Overlay network.

[0055] Underlay switches: This is a collective term for the core components that provide the underlying infrastructure network, including aggregation switches and core switches.

[0056] Public IP: This is a range of public IP addresses pre-planned in this resource pool. Each VM has a unique public IP address, which is used for the VM to access the public network or to be accessed by the public network.

[0057] Specifically, when a cloud tenant creates a VM on the cloud platform and binds it to a VPC created by the cloud tenant, the VM is assigned an Overlay IP address that is then assigned to the physical server running the VM. This Overlay IP address is valid and unique within the cloud tenant's VPC, and can be reused by different cloud tenants or different VPCs. For example, within a certain VPC, the VM's Overlay IP might be

[1234] . This IP address is only valid within that VPC and is used to identify a unique VM. Similarly, within another VPC, there might be a VM with the Overlay IP

[1234] , which is also only valid within that current VPC.

[0058] like Figure 2 The diagram shows the network topology. For traffic accessing the public network from the cloud, the VM sends packets through the Virtual Switch (OVS). Network address translation (NAT) is performed on the OVS, and the packets are then encapsulated into VXLAN packets. The VNI of the VXLAN packet corresponds to the VNI of the VPC where the VM resides. These packets are then sent to the north-south cloud gateway, which processes the VXLAN packets and forwards them to the public network after passing through the external firewall. For traffic entering the cloud from the public network, the north-south cloud gateway locates the physical server corresponding to the VM using the VM's public IP address. It then sends VXLAN packets to the OVS on the physical server for processing. Upon receiving the VXLAN packets, the OVS translates the public IP address into the VM's Overlay IP address and finally forwards the packets to the VM.

[0059] For traffic originating from the cloud and accessing the Underlay network, the VM sends packets through OVS. On OVS, the source address is translated into a Dummyf IP, then encapsulated into a VXLAN packet and sent to the east-west cloud gateway. The east-west cloud gateway processes the VXLAN packet, accesses the Underlay network address information through the VM, and forwards it to the Underlay network after passing through the internal firewall. For traffic originating from the Underlay network and entering the cloud, the east-west cloud gateway locates the physical server corresponding to the VM using the VM's Dummyf IP address, sends a VXLAN packet to the OVS on the physical server for processing, and the OVS translates the VM's Dummyf IP into the VM's Overlay IP before finally forwarding it to the VM.

[0060] Specifically, this embodiment provides the following four scenarios for communication between the VM and the Underlay network and the public network: Scenario 1: VM accessing the Underlay network (cloud outbound direction), including the following steps: Step 1: The virtual switch receives the access request from the VM, identifies the sender as the VM, and determines the destination as the Underlay network. Since the data is destined for outbound traffic, the source address in the access request is translated into a Dummy IP address.

[0061] Specifically, when a VM requests an Underlay network for the first time or when the Underlay network accesses a VM for the first time, the SDN controller assigns a Dummy IP to the VM through a developed interface, forming an Overlay IP. The mapping relationship of Dummyf IPs is recorded in the first mapping relationship table. Dummyf IPs are the Underlay IP address ranges planned in advance in this resource pool, and the Dummyf IPs corresponding to VMs are unique.

[0062] Step 2: Encapsulate the converted access request into a VXLAN packet and send it to the east-west cloud gateway.

[0063] In this context, the VNI in the VXLAN message is the VNI corresponding to the VPC where the VM resides.

[0064] Step 3: The east-west cloud gateway identifies the access request as originating from the cloud, decapsulates the access request message, removes the VXLAN label, and sends the access request to the Underlay network via the LAN-side VRF.

[0065] For traffic accessing the Underlay service: East-West Cloud Gateway: Based on VNI information, it sends the data to the LAN-side VRF (Vrf_private) for processing. It then accesses the Underlay network through the Underlay service routing network segment within the LAN-side VRF, as shown in Table 1. Table 1. Key-value table for east-west cloud gateway outbound direction

[0066] Underlay service routes are obtained in LANVRF either by issuing routes through the controller or by learning routes through BGP, as shown in Table 2: Table 2 Underlay Service Routing Information Table

[0067] Scenario 2: Underlay network access to VM (cloud inbound), including the following steps: Step 1: The East-West Cloud Gateway receives the access request sent by the Underlay Network, identifies the sender as the Underlay Network, and determines that the destination is the VM.

[0068] The specific address used to access the VM is the VM's IP address in the Underlay network, i.e., the Dummyf IP.

[0069] Step 2: The Wan-side VRF queries the first mapping table based on the Overlay IP. The detailed route of the Dummyf IP is encapsulated in a VXLAN packet and the access request is sent to the virtual switch corresponding to the VM. The VNI of the VXLAN packet is the VNI corresponding to the VPC where the VM is located.

[0070] Step 3: The virtual switch deencapsulates the access request packet, removes the VXLAN tag, and determines the IP address based on the Overlay IP. Dummyf provides a detailed route for the IP address and sends the access request to the corresponding VM.

[0071] For traffic accessing VMs via the Underlay network: The WAN-side VRF routes based on the dummy IP address corresponding to the VM, finds the specific next-hop information, and determines how to encapsulate the VXLAN packet (the physical server where the VM resides, the VPC where the virtual machine resides), as shown in Table 3: Table 3. Key-value table for east-west cloud gateway inbound direction

[0072] Scenario 3: VM accessing the public network (cloud outbound direction), including the following steps: Step 1: The virtual switch receives the access request from the VM, identifies the sender as the VM, and determines that the access destination is the public network. Since the data is destined for outbound from the cloud, the source address in the access request is translated into a public IP address.

[0073] Specifically, when a VM accesses the public network for the first time or when the public network accesses a VM for the first time, the SDN controller binds the public IP address applied for by the cloud tenant to the VM through a developed interface, forming an Overlay IP. The mapping relationship of public IP addresses (recorded in the second mapping relationship table).

[0074] Step 2: Encapsulate the converted access request into a VXLAN packet and send it to the north-south cloud gateway.

[0075] In this context, the VNI in the VXLAN message is the VNI corresponding to the VPC where the VM resides.

[0076] Step 3: The north-south cloud gateway identifies the access request as originating from the cloud, decapsulates the access request message, removes the VXLAN label, and sends the access request to the public network via the LAN-side VRF.

[0077] For VM traffic accessing the public network: The north-south cloud gateway sends VNI information to the LAN-side VRF (Vrf_private) for processing, and then routes it to the public network through the default route in the LAN-side VRF, as shown in Table 4: Table 4 Key-value table for north-south cloud gateway outbound direction

[0078] The north-south cloud gateway distributes default routes through the controller or learns public network routes through BGP and places them in the LAN-side VRF, as shown in Table 5: Table 5 Public Network Routing Information Table

[0079] Scenario 4: Accessing a VM from the public network (cloud access direction), including the following steps: Step 1: The north-south cloud gateway receives access requests sent from the public network, identifies the sender as the public network, and determines that the destination is the VM.

[0080] The specific address for accessing the VM is the public IP address bound to the VM.

[0081] Step 2: The Wan-side VRF queries the second mapping table based on the Overlay IP. The detailed route of the public IP address is encapsulated in a VXLAN packet and the access request is sent to the virtual switch corresponding to the VM. The VNI of the VXLAN packet is the VNI corresponding to the VPC where the VM is located.

[0082] Step 3: The virtual switch deencapsulates the access request packet, removes the VXLAN tag, and determines the IP address based on the Overlay IP. The detailed route of the public IP address is used to send the access request to the corresponding VM.

[0083] For traffic accessing the VM from the public network: North-South Cloud Gateway: The WAN-side VRF routes based on the public IP address of the VM, finds the specific next-hop information, and determines how to encapsulate the VXLAN packet (the physical server where the VM resides, the VPC where the virtual machine resides), as shown in Table 6: Table 6. Key-value table for north-south cloud gateway inbound direction

[0084] In one or more embodiments, since public IP addresses are charged based on their bandwidth, north-south gateways bind public IP addresses to chip-based rate-limiting bucket resources to limit their speed. East-west traffic is free. To prevent individual cloud tenants' VPCs from consuming excessive resources, east-west cloud gateways bind cloud tenant VPCs to chip-based rate-limiting bucket resources for unified rate limiting. By setting the bandwidth usage limit for each cloud tenant's VPC, it is possible to prevent a single cloud tenant from consuming too much bandwidth and affecting other cloud tenants.

[0085] This embodiment utilizes a design that works in conjunction with a virtual switch to offload the network address translation (NAT) function to the virtual switch for processing. The memory space occupied by NAT entries can be freed up for use as detailed routes for VMs, thereby increasing the detailed route capacity of the virtual machine.

[0086] This embodiment leverages the programmable data plane feature of programmable devices. By binding different VPCs (one VPC corresponds to one VNI) to the same VRF, the size of VRF entries is significantly reduced. Previously, one VPC corresponded to one VRF; due to limitations in chip VRF capacity, a single device could only handle tens of thousands of VPCs. By binding the VPC processing of different tenant services to the same VRF, the overall VPC scale is unaffected by the VRF size, and a single device can handle over 100,000 VPCs.

[0087] When a VM accesses or is accessed by the Underlay service, the controller assigns a Dummyf IP to the specified VM and configures a detailed route for that Dummyf IP on the east-west cloud gateway system. This method can reduce the number of detailed routes for the Dummyf IP corresponding to the VM on the east-west cloud gateway, increasing the supported VM scale by more than 10 times.

[0088] Based on the above embodiments, this embodiment also provides a method for optimizing the cloud tenant's carrying capacity, such as... Figure 3 The flowchart shown is a method for optimizing cloud tenant capacity, including S301-S304: S301: Obtain the access request and identify the sender and purpose of the access request.

[0089] The senders include virtual machines created by Underlay networks, public networks, and cloud tenants.

[0090] S302: Determine the data flow direction corresponding to the access request based on the sender.

[0091] The data flow direction includes the direction out of the cloud and the direction into the cloud.

[0092] S303: In response to the fact that the sender is a virtual machine, confirm that the data flow direction is outbound from the cloud, determine the cloud gateway corresponding to the access request based on the access purpose; forward the access request to the virtual switch corresponding to the virtual machine, perform network address translation and packet encapsulation on the access request through the virtual switch, and send the encapsulated access request to the cloud gateway.

[0093] S304: In response to the sender being an Underlay network or a public network, confirm that the data flow direction is to the cloud, determine the cloud gateway corresponding to the access request based on the sender, the cloud gateway confirms the corresponding virtual private cloud based on the access destination, encapsulates the access request based on the virtual private cloud, and sends the encapsulated access request to the virtual switch corresponding to the virtual private cloud.

[0094] In one or more embodiments, it further includes: Assign an Overlay IP to the virtual machine created by the cloud tenant and record the Overlay IP in the virtual switch running the virtual machine; the Overlay IP is effective and unique in the virtual private cloud to which the virtual machine belongs, and the virtual switch and the virtual private cloud are corresponding; When a virtual machine first requests to communicate with the Underlay network, a Dummyf IP is assigned to the virtual machine, and the Dummyf IP is bound to the Overlay IP to form the first mapping relationship; the Underlay network is the basic layer network in the computer network architecture. When the virtual machine communicates with the public network for the first time, the virtual machine's public IP address is bound to the Overlay IP address, forming a second mapping relationship.

[0095] When a virtual machine first accesses or is first accessed by the Underlay network, a Dummyf IP is assigned to the virtual machine, and detailed routes for that Dummyf IP are configured. Overlay IPs and Dummyf IPs are pre-planned Underlay IP address ranges, and each virtual machine's Dummyf IP is unique. Previously, detailed routes were configured for each cloud tenant's virtual machine on the cloud gateway to locate the virtual private cloud corresponding to the tenant's VM. This solution, however, only configures detailed routes for the virtual machines that actually communicate with the Underlay network, significantly reducing the number of detailed routes and increasing the scale of virtual machines that can be supported.

[0096] In one or more embodiments, network address translation and packet encapsulation of access requests are performed via a virtual switch, including: In response to the access destination being the Underlay network, the source address in the access request is translated into a Dummyf IP via a virtual switch. The translated access request is then encapsulated into a VXLAN packet. The VXLAN packet is used to identify the virtual switch to which the virtual machine belongs. The Dummyf IP is the IP address of the virtual machine in the Underlay network. The Dummyf IP is mapped to the Overlay IP of the virtual machine. The Overlay IP is the unique identifier of the virtual machine in its virtual private cloud. In response to the public network being the destination of the access, the source address in the access request is translated into the public IP address of the virtual machine through the virtual switch. The translated access request is then encapsulated into a VXLAN packet, in which the VXLAN packet is used to identify the virtual switch to which the sender belongs, and the public IP address is mapped to the overlay IP address of the virtual machine.

[0097] For data communication originating from the cloud, the first step is to determine the Virtual Private Cloud (VPC) where the virtual machine issuing the access request resides. Then, the corresponding virtual switch is identified, and address translation is performed by the virtual switch. Compared to performing network address translation on the cloud gateway, this significantly frees up NAT entries on the cloud gateway, increasing detailed routing capacity. Through packet encapsulation, VXLAN packets can characterize the VPC from which the access request originates or is destined.

[0098] In one or more embodiments, after sending the encapsulated access request to the cloud gateway, the method further includes: The cloud gateway decapsulates the access request message and confirms that the data flow direction of the access request is outbound from the cloud. The cloud gateway forwards the access request to the virtual router on the local area network side, which then forwards the request based on the routing address in the access request.

[0099] In one or more embodiments, the cloud gateway identifies the corresponding virtual private cloud based on the access purpose, including: The WAN-side virtual router in the cloud gateway identifies the access destination, which is either the virtual machine's DummyfIP or the public IP address. In response to an access destination being a virtual machine's Dummyf IP, the cloud gateway, based on the first mapping table, determines the virtual machine's Overlay IP and the corresponding Virtual Private Cloud based on the Overlay IP. The first mapping table is used to record the mapping relationship between the virtual machine's Overlay IP and Dummyf IP. In response to an access destination being a public IP address of a virtual machine, the cloud gateway confirms the virtual machine's Overlay IP address based on the second mapping table and the public IP address, and then confirms the corresponding virtual private cloud based on the Overlay IP address. The second mapping table is used to record the mapping relationship between the virtual machine's Overlay IP address and the public IP address.

[0100] For data entering the cloud, all processing and transmission are handled by the WAN-side virtual router within the cloud gateway. This WAN-side virtual router can serve all virtual private clouds, significantly reducing the number of virtual routers compared to the previous system where each virtual private cloud was bound to a separate virtual router. Through the first and second mapping tables, the cloud gateway can clearly identify the specific virtual machine for each access request.

[0101] In one or more embodiments, after sending the encapsulated access request to the virtual switch corresponding to the virtual private cloud, the method further includes: The virtual switch decapsulates access request packets to identify the purpose of access; In response to the Dummyf IP address of the virtual machine being accessed, the virtual switch identifies the Overlay IP address of the virtual machine based on the first mapping table and sends an access request to the Overlay IP address. In response to an access request to a virtual machine's public IP address, the virtual switch identifies the virtual machine's Overlay IP address based on the second mapping table and sends an access request to the Overlay IP address.

[0102] In one or more embodiments, the cloud gateway includes an east-west cloud gateway and a north-south cloud gateway. The east-west cloud gateway is used to handle data interaction between virtual machines and the Underlay network, and the north-south cloud gateway is used to handle data interaction between virtual machines and the public network. Determine the cloud gateway corresponding to the access request based on the access purpose, including: If the access destination is the Underlay network, the cloud gateway corresponding to the access request is determined to be an east-west cloud gateway; if the access destination is the public network, the cloud gateway corresponding to the access request is determined to be a north-south cloud gateway.

[0103] In one or more embodiments, the beneficial effect of this solution is that when the sender is a virtual machine, the access destination is either the Underlay network or the public network, and the corresponding cloud gateway can be determined by identifying the specific access destination.

[0104] In one or more embodiments, determining the cloud gateway corresponding to the access request based on the sender includes: If the sender is an Underlay network, the cloud gateway corresponding to the access request is determined to be an east-west cloud gateway; if the sender is a public network, the cloud gateway corresponding to the access request is determined to be a north-south cloud gateway.

[0105] In one or more embodiments, determining the data flow direction corresponding to the access request based on the sender includes: In response to the fact that the sender is a virtual machine, the data flow direction corresponding to the access request is determined to be the outbound direction; wherein, the virtual machine is created by the cloud tenant and located in the cloud data center, and the outbound direction means that the data flows from the cloud data center to the outside. In response to whether the sender is an Underlay network or a public network, the direction of data flow corresponding to the access request is determined as the cloud inbound direction; where the Underlay network and the public network are located outside the cloud data center, the cloud inbound direction means that the data flows from the outside to the cloud data center.

[0106] In one or more embodiments, it further includes: On the east-west cloud gateway, set resource thresholds for each virtual private cloud. The resource thresholds represent the bandwidth resources that virtual machines within each virtual private cloud can share within the threshold.

[0107] Since east-west traffic is free, by setting resource thresholds for each virtual private cloud and limiting maximum bandwidth resources, it is possible to prevent a single cloud tenant or virtual machine from consuming too many resources and affecting other cloud tenants.

[0108] According to another aspect of the embodiments of this disclosure, a cloud tenant capacity optimization device is provided, such as... Figure 4 As shown, the device includes: The first identification module 401 is used to obtain access requests and identify the sender and purpose of the access requests; wherein, the sender includes the Underlay network, the public network, and virtual machines created by cloud tenants; The second identification module 402 is used to determine the data flow direction corresponding to the access request based on the sender; wherein, the data flow direction includes the outbound direction and the inbound direction; The cloud processing module 403 is used to respond to the fact that the sender is a virtual machine, confirm that the data flow direction is outbound, determine the cloud gateway corresponding to the access request based on the access purpose, forward the access request to the virtual switch corresponding to the virtual machine, perform network address translation and packet encapsulation on the access request through the virtual switch, and send the encapsulated access request to the cloud gateway. The cloud processing module 404 is used to respond to the fact that the sender is an Underlay network or a public network, confirm that the data flow direction is the cloud direction, determine the cloud gateway corresponding to the access request based on the sender, the cloud gateway confirms the corresponding virtual private cloud based on the access destination, encapsulates the access request based on the virtual private cloud, and sends the encapsulated access request to the virtual switch corresponding to the virtual private cloud.

[0109] The cloud tenant capacity optimization device and the cloud tenant capacity optimization method provided in this disclosure are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0110] This disclosure also provides a computer device for executing the cloud tenant capacity optimization method described above. Please refer to... Figure 5 It illustrates a schematic diagram of a computer device provided by some embodiments of this disclosure. For example... Figure 5 As shown, the computer device 5 includes: a processor 500, a memory 501, a bus 502, and a communication interface 503. The processor 500, the communication interface 503, and the memory 501 are connected via the bus 502. The memory 501 stores a computer program that can run on the processor 500. When the processor 500 runs the computer program, it executes the cloud tenant capacity optimization method provided in any of the foregoing embodiments of this disclosure.

[0111] The memory 501 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this device network element and at least one other network element is achieved through at least one communication interface 503 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0112] Bus 502 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 501 is used to store programs. After receiving an execution instruction, the processor 500 executes the program. The cloud tenant capacity optimization method disclosed in any of the foregoing embodiments of this disclosure can be applied to the processor 500, or implemented by the processor 500.

[0113] The processor 500 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 500 or by instructions in software form. The processor 500 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPTA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 501. The processor 500 reads the information in memory 501 and, in conjunction with its hardware, completes the steps of the above method.

[0114] The computer equipment provided in this disclosure and the cloud tenant capacity optimization method provided in this disclosure are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0115] This disclosure also provides a computer-readable storage medium corresponding to the cloud tenant capacity optimization method provided in the foregoing embodiments. The computer-readable storage medium is an optical disc, on which a computer program (i.e., a computer program product) is stored. When the computer program is run by a processor, it executes the cloud tenant capacity optimization method provided in any of the foregoing embodiments.

[0116] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0117] The computer-readable storage medium provided in the above embodiments of this disclosure and the cloud tenant capacity optimization method provided in the embodiments of this disclosure are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0118] This disclosure also provides a computer program product; please refer to [reference needed]. Figure 6 The computer program product 600 carries program code, namely computer program 601. The instructions included in the computer program 601 can be used to execute the steps of the cloud tenant capacity optimization method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0119] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0120] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0121] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0122] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0123] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0124] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0125] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0126] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A method for optimizing the capacity of cloud tenants, characterized in that, include: Obtain access requests and identify the sender and purpose of the access requests; wherein, the sender includes the Underlay network, the public network, and virtual machines created by cloud tenants; Based on the sender, the data flow direction corresponding to the access request is determined; wherein, the data flow direction includes the outbound direction and the inbound direction; In response to the fact that the sender is the virtual machine, the data flow direction is confirmed to be outbound from the cloud, and the cloud gateway corresponding to the access request is determined based on the access purpose; the access request is forwarded to the virtual switch corresponding to the virtual machine, and the access request is performed on the virtual switch for network address translation and packet encapsulation, and the encapsulated access request is sent to the cloud gateway. In response to the sender being the Underlay network or the public network, the direction of data flow is confirmed to be cloud inbound. Based on the sender, the cloud gateway corresponding to the access request is determined. The cloud gateway determines the corresponding virtual private cloud based on the access destination. Based on the virtual private cloud, the access request is encapsulated and sent to the virtual switch corresponding to the virtual private cloud.

2. The cloud tenant capacity optimization method as described in claim 1, characterized in that, Also includes: An Overlay IP is assigned to the virtual machine created by the cloud tenant, and the Overlay IP is recorded in the virtual switch running the virtual machine; wherein, the Overlay IP is effective and unique in the virtual private cloud to which the virtual machine belongs, and the virtual switch and the virtual private cloud have a corresponding relationship; When the virtual machine first requests to communicate with the Underlay network, a Dummyf IP is assigned to the virtual machine, and the Dummyf IP is bound to the Overlay IP to form a first mapping relationship; wherein, the Underlay network is the basic layer network in the computer network architecture; When the virtual machine communicates with the public network for the first time, the public IP address of the virtual machine is bound to the overlay IP address to form a second mapping relationship.

3. The cloud tenant capacity optimization method as described in claim 1, characterized in that, The virtual switch performs network address translation and packet encapsulation on the access request, including: In response to the access destination being the Underlay network, the source address in the access request is converted to a Dummyf IP via the virtual switch, and the converted access request is encapsulated into a VXLAN packet. The VXLAN packet is used to identify the virtual switch to which the virtual machine belongs, the Dummyf IP is the IP address of the virtual machine in the Underlay network, the Dummyf IP is mapped to the Overlay IP of the virtual machine, and the Overlay IP is the unique identifier of the virtual machine in its virtual private cloud. In response to the public network being the destination of the access, the source address in the access request is converted to the public IP address of the virtual machine through the virtual switch, and the converted access request is encapsulated into a VXLAN packet. The VXLAN packet is used to identify the virtual switch to which the sender belongs, and the public IP address is mapped to the overlay IP address of the virtual machine.

4. The cloud tenant capacity optimization method as described in claim 1, characterized in that, After sending the encapsulated access request to the cloud gateway, the process also includes: The cloud gateway decapsulates the access request message and confirms that the data flow direction of the access request is outbound from the cloud. The cloud gateway forwards the access request to the virtual router on the local area network side, and the virtual router on the local area network side forwards the request based on the routing address in the access request.

5. The cloud tenant capacity optimization method as described in claim 1, characterized in that, The cloud gateway determines the corresponding virtual private cloud based on the access destination, including: The WAN-side virtual router forwarding within the cloud gateway identifies the access destination, which is either the virtual machine's Dummy IP or its public IP. In response to the access destination being the Dummyf IP of the virtual machine, based on the first mapping table, the cloud gateway confirms the Overlay IP of the virtual machine based on the Dummyf IP, and confirms the corresponding virtual private cloud based on the Overlay IP. The first mapping table is used to record the mapping relationship between the Overlay IP and the Dummyf IP of the virtual machine. In response to the access destination being the public IP address of the virtual machine, the cloud gateway confirms the overlay IP address of the virtual machine based on the second mapping table and the public IP address, and confirms the corresponding virtual private cloud based on the overlay IP address; wherein, the second mapping table is used to record the mapping relationship between the overlay IP address and the public IP address of the virtual machine.

6. The cloud tenant capacity optimization method as described in claim 5, characterized in that, After sending the encapsulated access request to the virtual switch corresponding to the virtual private cloud, the process also includes: The virtual switch decapsulates the access request message and identifies the access purpose; In response to the access destination being the virtual machine's Dummy IP, the virtual switch, based on the first mapping table, identifies the virtual machine's Overlay IP and sends the access request to the Overlay IP. In response to the access destination being the public IP address of the virtual machine, the virtual switch, based on the second mapping table, identifies the overlay IP address of the virtual machine and sends the access request to the overlay IP address.

7. A cloud tenant capacity optimization device, characterized in that, include: The first identification module is used to obtain access requests and identify the sender and purpose of the access requests; wherein, the sender includes the Underlay network, the public network, and virtual machines created by cloud tenants; The second identification module is used to determine the data flow direction corresponding to the access request based on the sender; wherein the data flow direction includes the cloud outflow direction and the cloud inflow direction; The cloud outbound processing module is used to respond to the fact that the sender is the virtual machine, confirm that the data flow direction is the cloud outbound direction, determine the cloud gateway corresponding to the access request based on the access destination, forward the access request to the virtual switch corresponding to the virtual machine, perform network address translation and packet encapsulation on the access request through the virtual switch, and send the encapsulated access request to the cloud gateway. The cloud inbound processing module is used to respond to the fact that the sender is the Underlay network or the public network, confirm that the data flow direction is the cloud inbound direction, determine the cloud gateway corresponding to the access request based on the sender, the cloud gateway confirms the corresponding virtual private cloud based on the access destination, encapsulates the access request based on the virtual private cloud, and sends the encapsulated access request to the virtual switch corresponding to the virtual private cloud.

8. A computer embedded device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 6.

Images