Gateway migration method and device, equipment, storage medium and program product

Abstract

The invention relates to a gateway migration method and device, equipment, a storage medium and a program product. The method comprises the steps that a first virtual gateway and a hardware gateway are deployed in a resource pool of a cloud network, network resource entities in a second virtual gateway in the cloud network are migrated to the first virtual gateway, and the first virtual gateway and the hardware gateway are connected through an extensible virtual local area network tunnel; receiving a migration instruction of an out-of-cloud gateway, wherein the migration instruction is used for indicating to carry out out-of-cloud gateway migration on a target virtual private cloud corresponding to the network resource entity; and in response to the migration instruction, directly routing the cloud outgoing flow corresponding to the target virtual private cloud to a hardware gateway, so that the hardware gateway performs IP forwarding on the cloud outgoing flow related to the target elastic IP address, and the cloud outgoing flow is the flow corresponding to the target elastic IP address in the target virtual private cloud. By adopting the method, smooth migration of the cloud gateway can be realized.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a gateway migration method, apparatus, device, storage medium, and program product. Background Technology

[0002] The cloud network in cloud computing forms the backbone of the entire information technology infrastructure, supporting the stable operation and allocation of computing, storage, and security resources. A crucial service within the cloud network is traffic accessing the internet from the cloud, i.e., outbound traffic or northbound traffic. Outbound traffic typically uses Source Network Address Translation (SNAT) or binding to Elastic IP addresses (EIPs), and these functions are generally handled by the Tenant Gateway (TGW).

[0003] Tenant gateways are typically deployed on hardware servers as Virtualized Network Functions (VNFs), providing data processing and forwarding capabilities by leveraging the hardware server's vCPUs and packet processing frameworks and libraries (DataPlane Development Kit, DPDK). However, as tenant businesses expand, the pressure and stability of the tenant gateways carrying customer services face increasing challenges, necessitating an upgrade to edge intelligent hardware gateways. However, the method for smoothly migrating cloud gateways to hardware gateways remains uncertain. Summary of the Invention

[0004] Therefore, it is necessary to provide a gateway migration method, apparatus, device, storage medium, and program product that can achieve a smooth migration of cloud gateways to address the above-mentioned technical problems.

[0005] Firstly, this application provides a gateway migration method, including:

[0006] A first virtual gateway and a hardware gateway are deployed in the resource pool of the cloud network, and the network resource entities in the second virtual gateway in the cloud network are migrated to the first virtual gateway. The first virtual gateway and the hardware gateway are connected through a scalable virtual local area network tunnel.

[0007] Receive a migration instruction for the cloud gateway, the migration instruction being used to instruct the cloud gateway to be migrated for the target virtual private cloud corresponding to the network resource entity;

[0008] In response to the migration command, the outbound traffic corresponding to the target virtual private cloud is directly routed to the hardware gateway, so that the hardware gateway performs IP forwarding on the outbound traffic related to the target elastic IP address, wherein the outbound traffic is the traffic corresponding to the target elastic IP address in the target virtual private cloud.

[0009] In one embodiment, after receiving the migration instruction from the cloud gateway, the method further includes:

[0010] The type of the migration instruction is determined based on the SDN interface corresponding to the migration instruction;

[0011] The target elastic IP address is determined based on the type of the migration instruction.

[0012] In one embodiment, the migration instruction includes a first migration type and a second migration type; the target elastic IP address corresponding to the first migration type is any elastic IP address in the target virtual private cloud, and the target elastic IP address corresponding to the second migration type is all elastic IP addresses in the target virtual private cloud, and the SDN interfaces corresponding to the first migration type and the second migration type are different.

[0013] In one embodiment, the step of directly routing the outbound traffic corresponding to the target virtual private cloud to the hardware gateway includes:

[0014] The first routing path of the outbound traffic corresponding to the target virtual private cloud is switched to the second routing path so that the outbound traffic corresponding to the target virtual private cloud is directly routed to the hardware gateway.

[0015] The first routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the first virtual gateway and from the first virtual gateway to the hardware gateway; the second routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the hardware gateway.

[0016] In one embodiment, after receiving the migration instruction from the cloud gateway, the method further includes:

[0017] Send a forwarding rule flow table to the virtual switch corresponding to the target virtual private cloud; the forwarding rule flow table is used to encapsulate the outbound traffic with outer packets and match the inbound traffic.

[0018] In one embodiment, when the outer destination IP address of the outbound traffic packet is the IP address of the hardware gateway, the hardware gateway is further configured to remove the outer encapsulation of the outbound traffic to determine the inner packet of the outbound traffic, and perform network address forwarding based on the inner packet.

[0019] Secondly, this application also provides a gateway migration device, comprising:

[0020] The deployment module is used to deploy a first virtual gateway and a hardware gateway in the resource pool of the cloud network, and migrate the network resource entities in the second virtual gateway in the cloud network to the first virtual gateway. The first virtual gateway and the hardware gateway are connected through a scalable virtual local area network tunnel.

[0021] The receiving module is used to receive the migration instruction of the cloud gateway, wherein the migration instruction is used to instruct the cloud gateway to be migrated to the target virtual private cloud corresponding to the network resource entity.

[0022] The migration module is used to respond to the migration command by directly routing the outbound traffic corresponding to the target virtual private cloud to the hardware gateway, so that the hardware gateway performs IP forwarding on the outbound traffic related to the target elastic IP address, wherein the outbound traffic is the traffic corresponding to the target elastic IP address in the target virtual private cloud.

[0023] In one embodiment, the migration module is further configured to determine the type of the migration instruction based on the SDN interface corresponding to the migration instruction; and determine the target elastic IP address based on the type of the migration instruction.

[0024] In one embodiment, the migration instruction includes a first migration type and a second migration type; the target elastic IP address corresponding to the first migration type is any elastic IP address in the target virtual private cloud, and the target elastic IP address corresponding to the second migration type is all elastic IP addresses in the target virtual private cloud, and the SDN interfaces corresponding to the first migration type and the second migration type are different.

[0025] In one embodiment, the migration module is further configured to switch the first routing path of the outbound traffic corresponding to the target virtual private cloud to the second routing path, so as to directly route the outbound traffic corresponding to the target virtual private cloud to the hardware gateway.

[0026] The first routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the first virtual gateway and from the first virtual gateway to the hardware gateway; the second routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the hardware gateway.

[0027] In one embodiment, the migration module is used to send a forwarding rule flow table to the virtual switch corresponding to the target virtual private cloud; the forwarding rule flow table is used to encapsulate the outbound traffic with outer packets and match the inbound traffic.

[0028] In one embodiment, when the outer destination IP address of the outbound traffic packet is the IP address of the hardware gateway, the hardware gateway is further configured to remove the outer encapsulation of the outbound traffic to determine the inner packet of the outbound traffic, and perform network address forwarding based on the inner packet.

[0029] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the gateway migration method described in the first aspect.

[0030] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the gateway migration method of the first aspect described above.

[0031] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the gateway migration method described in the first aspect.

[0032] The aforementioned gateway migration method, apparatus, device, storage medium, and program product deploy a first virtual gateway and a hardware gateway in the resource pool of the cloud network, and migrate network resource entities in the second virtual gateway in the cloud network to the first virtual gateway. The first virtual gateway and the hardware gateway are connected through a scalable virtual local area network tunnel. The method receives a migration instruction from the outbound gateway, which instructs the migration of the outbound gateway to the target virtual private cloud corresponding to the network resource entity. In response to the migration instruction, the method directly routes the outbound traffic corresponding to the target virtual private cloud to the hardware gateway, so that the hardware gateway performs IP forwarding on the outbound traffic related to the target elastic IP address. The outbound traffic is the traffic corresponding to the target elastic IP address in the target virtual private cloud. By first migrating the network resource entities in the second virtual gateway to the first virtual gateway connected to the hardware gateway via a scalable virtual LAN tunnel, and then directly routing the outbound traffic corresponding to the target virtual private cloud to the hardware gateway based on the migration command, the hardware gateway performs IP forwarding on the outbound traffic related to the target elastic IP address. This allows the outbound services in the second virtual gateway to be migrated gradually and in stages, preventing forwarding anomalies caused by excessive pressure on the second virtual gateway, and achieving a smooth migration of the outbound gateway. Attached Figure Description

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

[0034] Figure 1 A schematic diagram illustrating the cloud traffic forwarding path for tenant gateways in related technologies;

[0035] Figure 2 A flowchart illustrating a gateway migration method provided in an embodiment of this application;

[0036] Figure 3 A schematic diagram illustrating the deployment of a first virtual gateway and a hardware gateway, provided as an embodiment of this application;

[0037] Figure 4 One of the schematic diagrams of message encapsulation provided in the embodiments of this application;

[0038] Figure 5 A second schematic diagram of message encapsulation provided for an embodiment of this application;

[0039] Figure 6 A third schematic diagram of a message encapsulation method provided for an embodiment of this application;

[0040] Figure 7 This is a schematic diagram illustrating the direct routing of cloud traffic to the hardware gateway as provided in an embodiment of this application.

[0041] Figure 8 A fourth schematic diagram illustrating a message encapsulation method provided in this application embodiment;

[0042] Figure 9 A flowchart illustrating another gateway migration method provided in this application embodiment;

[0043] Figure 10 A structural block diagram of a gateway migration device provided in an embodiment of this application;

[0044] Figure 11 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0046] The relevant technologies will be explained below.

[0047] The cloud network in cloud computing forms the backbone of the entire information technology infrastructure, supporting the stable operation and allocation of computing, storage, and security resources. A crucial service within the cloud network is traffic accessing the internet from the cloud, i.e., outbound traffic or northbound traffic. Outbound traffic typically uses Source Network Address Translation (SNAT) or binding to Elastic IP addresses (EIPs), and these functions are generally handled by the Tenant Gateway (TGW).

[0048] Figure 1 A diagram illustrating the cloud traffic forwarding path for tenant gateways in related technologies, such as... Figure 1 The diagram shows a virtual machine (VM) bound to an EIP leaving the cloud. After the VM's outbound traffic reaches the tenant gateway, it undergoes Network Address Translation (NAT) and is then forwarded to the leaf node (Bleaf) switches in the resource pool for Internet Protocol (IP) routing. Furthermore, the tenant gateway not only handles NAT but also rate limiting, traffic metering, and access control functions.

[0049] In related technologies, tenant gateways are typically deployed on hardware servers as Virtualized Network Functions (VNFs). They provide data processing and forwarding capabilities by leveraging the server's vCPUs and a Data Plane Development Kit (DPDK) framework. However, as tenant business scales up, the pressure and stability of the tenant gateways carrying customer services face increasing challenges. In other words, relying solely on vCPUs and DPDK technology to squeeze the server's forwarding capacity is limited and cannot compare to the forwarding capabilities provided by hardware devices. As the number of tenant services and configurations in the resource pool increases and become more complex, the VNF-virtualized tenant gateway can easily become a performance bottleneck in the cloud network.

[0050] Meanwhile, the cost of hardware servers remains high. Under the combined pressure of performance and cost constraints, replacing cloud gateways with programmable intelligent hardware devices is an inevitable trend. Hardware devices, such as Programming Protocol-Independent Packet Processors (P4) gateways, possess protocol orchestration advantages and are suitable next-generation evolved edge intelligent hardware gateways for the aforementioned scenarios. However, the smooth migration of cloud gateways to hardware gateways remains uncertain.

[0051] Furthermore, when the tenant gateway is under excessive pressure, migration can only be performed at the tenant level, carrying the corresponding configuration for that tenant and forwarding traffic to that tenant. Currently, it is not possible to migrate or switch to a specific VPC or EIP within a tenant.

[0052] To address the aforementioned issues, this application provides a gateway migration method, apparatus, device, storage medium, and program product. First, network resource entities in the second virtual gateway are migrated to a first virtual gateway connected to the hardware gateway via a scalable virtual local area network tunnel. Then, based on migration instructions, outbound traffic corresponding to the target virtual private cloud is directly routed to the hardware gateway. The hardware gateway performs IP forwarding on the outbound traffic related to the target elastic IP address, thereby enabling the outbound services in the second virtual gateway to migrate gradually and in stages, preventing forwarding anomalies caused by excessive pressure on the second virtual gateway, and achieving a smooth migration of the outbound gateway.

[0053] The gateway migration method in this application embodiment can be applied to a gateway migration device, which can be a control device in a cloud network. This control device can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server; this application embodiment does not impose any limitations on this.

[0054] In one exemplary embodiment, such as Figure 2 As shown, a gateway migration method is provided. Taking the application of this method to a gateway migration device as an example, the method includes the following steps S201 to S203. Wherein:

[0055] S201. Deploy the first virtual gateway and hardware gateway in the resource pool of the cloud network, and migrate the network resource entities in the second virtual gateway in the cloud network to the first virtual gateway.

[0056] In this application, when it is necessary to migrate the cloud gateway, the gateway migration device can first deploy a first virtual gateway and a hardware gateway in the resource pool of the cloud network, and then migrate the network resource entities in the second virtual gateway in the cloud network to the first virtual gateway.

[0057] It should be understood that the embodiments of this application do not limit the first virtual gateway, which can be a newly added tenant gateway or a cluster of tenant gateways; the embodiments of this application also do not limit the hardware gateway, which can be a newly added P4 gateway or a cluster of P4 gateways.

[0058] The first virtual gateway and the hardware gateway are connected via a Virtual eXtensible LAN (VXLAN) tunnel. The aforementioned network resource entities can be, for example, tenants on a tenant gateway.

[0059] For example, a new tenant gateway and P4 gateway cluster can be deployed in the resource pool, and a VXLAN tunnel can be established between the new tenant gateway cluster and the P4 gateway cluster. After outbound traffic can be routed to the new tenant gateway, it can be routed to the new P4 gateway cluster by default through the VXLAN tunnel next hop. That is, the next hop IP of outbound traffic is the IP of the P4 gateway cluster (P4_Cluster_IP). After deployment, the tenants on the original tenant gateway cluster are migrated to the new tenant gateway cluster.

[0060] For example, Figure 3 This application provides a schematic diagram illustrating the deployment of a first virtual gateway and a hardware gateway, as shown in the embodiments. Figure 3 As shown, the original Tenant Gateway (TGW) 1 and TGW2 form a tenant gateway cluster. The migration will be performed to a new tenant gateway cluster consisting of TGW3 and TGW4 via a tenant gateway migration method.

[0061] In some embodiments, after migrating network resource entities in the second virtual gateway in the cloud network to the first virtual gateway, the outbound traffic corresponding to the target virtual private cloud adopts a first routing path. The first routing path includes routing the outbound traffic corresponding to the target virtual private cloud from the virtual switch to the first virtual gateway and from the first virtual gateway to the hardware gateway.

[0062] The target virtual private cloud can be any virtual private cloud.

[0063] For example, continue to refer to Figure 3 After the tenant migration is completed, the outbound traffic of the virtual machine (VM) corresponding to the target virtual private server can first be routed to the new TGW3, and then routed to the P4_1 gateway via the default route of TGW3. Finally, the P4_1 gateway forwards the traffic to the boundary leaf switch for outbound traffic.

[0064] Throughout the exemplary forwarding path, the outbound traffic of VM1 is encapsulated by packets on the virtual switch (Open Vswitch, OVS) of the host machine where VM1 resides. Figure 4 This is one of the schematic diagrams of a message encapsulation provided in an embodiment of this application, such as... Figure 4 As shown, the inner packet source IP of VM1's outbound traffic is VM1's IP address, and the destination IP is the public internet IP address; the source hardware address of VM1's outbound traffic is VM1's hardware address, and the destination hardware address is the hardware address of the subnet gateway on TGW3. After VM1's outbound traffic is encapsulated by VXLAN packets, the outer source IP is the OVS VXLAN tunnel endpoint (Vtep) address, and the destination IP is the TGW3 cluster IP; the source hardware address is the OVS Vetp hardware address, and the destination hardware address is the hardware address of the next hop in the underlying network.

[0065] For example, after the encapsulated packets of VM1's outbound traffic are forwarded to the TGW3 tenant gateway cluster, the TGW3 tenant gateway cluster can remove the outer VXLAN encapsulation, exposing the inner packet. Subsequently, the TGW3 tenant gateway cluster can send the memory packet to the corresponding Subnet Virtual Routing and Forwarding (VR) forwarding service based on the inner destination hardware address, perform NAT translation on the corresponding subnet F to convert the inner source IP address to an Elastic IP (EIP) address, and then look up the default route to forward it to the P4 cluster. At this point, the packet encapsulation result is as follows: Figure 5As shown, the outer destination IP is encapsulated as the aggregated IP of the P4 gateway cluster, i.e., the P4_1 cluster IP. When this packet is forwarded to the P4_1 switch, it is found that the outer destination IP is the P4_1 switch, and the outer encapsulation is removed to expose the inner packet. Subsequently, the routing on the P4_1 switch can be queried for IP forwarding. The source hardware address is encapsulated with its own outgoing interface MAC address, i.e., P4_1-MAC, and the destination address is the hardware address resolved by the next hop of the route. At this time, the packet encapsulation result is as follows. Figure 6 As shown.

[0066] S202, Receive migration instructions from the cloud gateway.

[0067] The migration command is used to instruct the cloud gateway migration of the target virtual private cloud corresponding to the network resource entity.

[0068] In some embodiments, after receiving a migration instruction from the cloud gateway, the gateway's migration device can first determine the type of the migration instruction based on the Software Defined Network (SDN) interface corresponding to the instruction. Then, the gateway's migration device determines the target elastic IP address based on the type of the migration instruction.

[0069] The migration instructions include a first migration type and a second migration type. The target elastic IP address corresponding to the first migration type is any elastic IP address in the target virtual private cloud, and the target elastic IP address corresponding to the second migration type is all elastic IP addresses in the target virtual private cloud. The SDN interfaces corresponding to the first migration type and the second migration type are different.

[0070] It should be understood that after migration via the tenant gateway, the outbound traffic of the virtual machine first goes to the first virtual gateway and then to the hardware gateway, before being transmitted to the Internet through the hardware gateway. At this point, the NAT of the virtual machine's EIP is still performed on the first virtual gateway. To completely switch the gateway for outbound traffic to the hardware gateway, the virtual machine's OVS needs to establish a VXLAN tunnel directly with the hardware gateway, and perform NAT translation on the hardware gateway. Correspondingly, migration commands for the outbound gateway can be used to instruct the target virtual private cloud corresponding to the network resource entity to migrate the outbound gateway.

[0071] For example, two SDN interfaces can be defined, receiving different types of migration commands from the cloud gateway. The command format for the SDN interface corresponding to the first migration type can be defined. By calling this SDN interface to execute the corresponding migration command, a single EIP can be switched to the hardware gateway. The command format for the SDN interface corresponding to the second migration type can also be defined. By calling this SDN interface to execute the corresponding migration command, all EIPs in a specified VPC can be switched to the hardware gateway.

[0072] S203. In response to the migration command, the outbound traffic corresponding to the target virtual private cloud is directly routed to the hardware gateway, so that the hardware gateway performs IP forwarding on the outbound traffic related to the target elastic IP address. Here, the outbound traffic refers to the traffic corresponding to the target elastic IP address within the target virtual private cloud.

[0073] In some embodiments, the gateway migration device can switch the first routing path of the outbound traffic corresponding to the target virtual private cloud to the second routing path, so as to directly route the outbound traffic corresponding to the target virtual private cloud to the hardware gateway.

[0074] The first routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the first virtual gateway and from the first virtual gateway to the hardware gateway; the second routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the hardware gateway.

[0075] For example, the gateway's migration device can determine whether the migration command is a second migration type. If the migration command is a second migration type, it can execute the command to call the SDN interface to switch all EIPs within the entire VPC to the hardware gateway. All EIPs within the entire VPC have completed the switchover to the cloud gateway, and all outbound traffic within the VPC can directly access the hardware gateway for NAT translation and high-performance forwarding.

[0076] For example, if the migration instruction is not of the second migration type, the gateway's migration device can continue to determine whether the migration instruction is of the first migration type. If the migration instruction is of the first migration type, the execution instruction calls the SDN controller interface to switch a single EIP within the VPC to the hardware gateway. A certain EIP within the entire VPC completes the switch to the cloud gateway, and all cloud outbound traffic within the VPC directly goes to the hardware gateway for NAT translation and high-performance forwarding.

[0077] For example, if no migration instructions for the first migration type and the second migration type are received, the EIP cloud gateway is switched. The cloud traffic is still forwarded by NAT on the first virtual gateway and then forwarded to the hardware gateway for public network access.

[0078] In some embodiments, after receiving the migration instruction from the cloud gateway, the gateway's migration device can also send a forwarding rule flow table to the virtual switch corresponding to the target virtual private cloud; the forwarding rule flow table is used to encapsulate the outbound traffic with outer packets and match the inbound traffic.

[0079] In cases where the outer destination IP address of the outbound traffic packet is the IP address of the hardware gateway, the hardware gateway is also used to remove the outer encapsulation of the outbound traffic to determine the inner packet of the outbound traffic, and to forward the network address based on the inner packet.

[0080] The forwarding rule flow table can include outbound flow table and inbound flow table.

[0081] For example, for outbound traffic, the outbound flow table can match the source IP of the virtual machine and the VPC ID where the virtual machine resides. Then, an action can be performed to encapsulate the traffic using VXLAN, with the tunnel destination address being the P4 cluster IP. This encapsulation of outbound traffic is then completed according to the outbound flow table, and the encapsulated traffic is directly sent to the hardware gateway. For example, for inbound traffic, the inbound flow table can match the tunnel source address to the P4 cluster IP, the VPC ID where the virtual machine resides, and the destination address to the virtual machine's IP.

[0082] Figure 7 This is a schematic diagram illustrating the direct routing of cloud traffic to the hardware gateway provided in an embodiment of this application, as shown below. Figure 7 As shown, outbound traffic goes directly to the P4 gateway cluster, and then the IP is forwarded out through the P4 gateway cluster.

[0083] For example, the outbound traffic of VM1 can be encapsulated in the OVS of the host machine where VM1 resides, such as... Figure 8 As shown, the source IP of the inner packet is the IP address of VM1, and the destination IP is the public IP address of the Internet. The source hardware address is the hardware address of VM1, and the destination hardware address is the subnet gateway hardware address represented by the OVS flow table. The outer source IP of the encapsulated VXLAN packet is the OVS Vetp address, and the destination IP is the cluster IP of P4. The source hardware address is the OVS Vetp hardware address, and the destination MAC address is the hardware address of the next hop in the underlying network.

[0084] For example, when the encapsulated VXLAN packet is forwarded to the P4_1 switch, if the outer destination IP is found to be the P4_1 switch, the outer encapsulation is removed to expose the inner packet, and the source IP is NAT-translated to EIP1. The packet encapsulation structure is as follows: Figure 6As shown, you can query the routes on the P4_1 switch and perform IP forwarding. The source hardware address is the hardware of its own outgoing interface, i.e., P4_1-MAC, and the destination hardware address is the hardware address resolved by the next hop of the route.

[0085] The gateway migration method provided in this application embodiment enables a smooth and gradual migration of virtual gateways to hardware gateways. While ensuring the stable operation of user services, it seamlessly completes the replacement of the egress gateway, thereby improving the stability of customer service operations.

[0086] The gateway migration method provided in this application deploys a first virtual gateway and a hardware gateway in a cloud network resource pool, and migrates network resource entities in a second virtual gateway in the cloud network to the first virtual gateway. The first virtual gateway and the hardware gateway are connected through a scalable virtual local area network tunnel. The method receives a migration instruction from the outbound gateway, which instructs the migration of the outbound gateway to the target virtual private cloud corresponding to the network resource entity. In response to the migration instruction, the outbound traffic corresponding to the target virtual private cloud is directly routed to the hardware gateway, enabling the hardware gateway to perform IP forwarding of the outbound traffic related to the target elastic IP address. The outbound traffic is the traffic corresponding to the target elastic IP address in the target virtual private cloud. Because the network resource entities in the second virtual gateway are first migrated to the first virtual gateway connected to the hardware gateway through a scalable virtual local area network tunnel, and then the outbound traffic corresponding to the target virtual private cloud is directly routed to the hardware gateway based on the migration instruction, and the hardware gateway performs IP forwarding of the outbound traffic related to the target elastic IP address, the outbound services in the second virtual gateway can be migrated gradually and in stages, preventing forwarding anomalies caused by excessive pressure on the second virtual gateway, thus achieving a smooth migration of the outbound gateway.

[0087] In one exemplary embodiment, such as Figure 9 As shown, another gateway migration method is provided. Taking the application of this method to a gateway migration device as an example, the method includes the following steps S301 to S306. Wherein:

[0088] S301. Deploy a first virtual gateway and a hardware gateway in the resource pool of the cloud network, and migrate the network resource entities in the second virtual gateway in the cloud network to the first virtual gateway. The first virtual gateway and the hardware gateway are connected through an extensible virtual local area network tunnel.

[0089] S302. Receive the migration instruction from the cloud gateway. The migration instruction is used to instruct the cloud gateway to be migrated to the target virtual private cloud corresponding to the network resource entity.

[0090] The migration instructions include a first migration type and a second migration type. The target elastic IP address corresponding to the first migration type is any elastic IP address in the target virtual private cloud, and the target elastic IP address corresponding to the second migration type is all elastic IP addresses in the target virtual private cloud. The SDN interfaces corresponding to the first migration type and the second migration type are different.

[0091] S303. Determine the type of migration instruction based on the SDN interface corresponding to the migration instruction.

[0092] S304. Determine the target elastic IP address based on the type of migration instruction.

[0093] S305. Send the forwarding rule flow table to the virtual switch corresponding to the target virtual private cloud; the forwarding rule flow table is used to encapsulate outbound traffic with outer packets and match inbound traffic.

[0094] S306. In response to the migration command, the first routing path of the outbound traffic corresponding to the target virtual private cloud is switched to the second routing path so that the outbound traffic corresponding to the target virtual private cloud is directly routed to the hardware gateway.

[0095] In some embodiments, the hardware gateway is used to perform IP forwarding on outbound traffic related to the target elastic IP address, wherein the outbound traffic is the traffic corresponding to the target elastic IP address in the target virtual private cloud.

[0096] The first routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the first virtual gateway and from the first virtual gateway to the hardware gateway; the second routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the hardware gateway.

[0097] The gateway migration method provided in this application deploys a first virtual gateway and a hardware gateway in a cloud network resource pool, and migrates network resource entities in a second virtual gateway in the cloud network to the first virtual gateway. The first virtual gateway and the hardware gateway are connected through a scalable virtual local area network tunnel. The method receives a migration instruction from the outbound gateway, which instructs the migration of the outbound gateway to the target virtual private cloud corresponding to the network resource entity. In response to the migration instruction, the outbound traffic corresponding to the target virtual private cloud is directly routed to the hardware gateway, enabling the hardware gateway to perform IP forwarding of the outbound traffic related to the target elastic IP address. The outbound traffic is the traffic corresponding to the target elastic IP address in the target virtual private cloud. Because the network resource entities in the second virtual gateway are first migrated to the first virtual gateway connected to the hardware gateway through a scalable virtual local area network tunnel, and then the outbound traffic corresponding to the target virtual private cloud is directly routed to the hardware gateway based on the migration instruction, and the hardware gateway performs IP forwarding of the outbound traffic related to the target elastic IP address, the outbound services in the second virtual gateway can be migrated gradually and in stages, preventing forwarding anomalies caused by excessive pressure on the second virtual gateway, thus achieving a smooth migration of the outbound gateway.

[0098] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0099] Based on the same inventive concept, this application also provides a gateway migration apparatus for implementing the gateway migration method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more gateway migration apparatus embodiments provided below can be found in the limitations of the gateway migration method described above, and will not be repeated here.

[0100] In one exemplary embodiment, such as Figure 10 As shown, a gateway migration device 400 is provided, including: a deployment module 401, a receiving module 402, and a migration module 403, wherein:

[0101] Deployment module 401 is used to deploy a first virtual gateway and a hardware gateway in the resource pool of the cloud network, and to migrate network resource entities in the second virtual gateway in the cloud network to the first virtual gateway. The first virtual gateway and the hardware gateway are connected through an extensible virtual local area network tunnel.

[0102] The receiving module 402 is used to receive the migration instruction of the cloud gateway. The migration instruction is used to instruct the cloud gateway to be migrated to the target virtual private cloud corresponding to the network resource entity.

[0103] Migration module 403 is used to respond to migration instructions to directly route the outbound traffic corresponding to the target virtual private cloud to the hardware gateway, so that the hardware gateway can perform IP forwarding on the outbound traffic related to the target elastic IP address. The outbound traffic is the traffic corresponding to the target elastic IP address in the target virtual private cloud.

[0104] In one embodiment, the migration module 403 is further configured to determine the type of migration instruction based on the SDN interface corresponding to the migration instruction; and determine the target elastic IP address based on the type of migration instruction.

[0105] In one embodiment, the migration instruction includes a first migration type and a second migration type; the target elastic IP address corresponding to the first migration type is any elastic IP address in the target virtual private cloud, and the target elastic IP address corresponding to the second migration type is all elastic IP addresses in the target virtual private cloud. The SDN interfaces corresponding to the first migration type and the second migration type are different.

[0106] In one embodiment, the migration module 403 is further configured to switch the first routing path of the outbound traffic corresponding to the target virtual private cloud to the second routing path, so as to directly route the outbound traffic corresponding to the target virtual private cloud to the hardware gateway.

[0107] The first routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the first virtual gateway and from the first virtual gateway to the hardware gateway; the second routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the hardware gateway.

[0108] In one embodiment, the migration module 403 is used to send a forwarding rule flow table to the virtual switch corresponding to the target virtual private cloud; the forwarding rule flow table is used to encapsulate the outbound traffic with outer packets and match the inbound traffic.

[0109] In one embodiment, if the outer destination IP address of the outbound traffic packet is the IP address of the hardware gateway, the hardware gateway is further used to remove the outer encapsulation of the outbound traffic to determine the inner packet of the outbound traffic, and to perform network address forwarding based on the inner packet.

[0110] The various modules in the aforementioned gateway migration device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0111] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 11 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a gateway migration method.

[0112] Those skilled in the art will understand that Figure 11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0113] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the aforementioned gateway migration method.

[0114] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the aforementioned gateway migration method.

[0115] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the aforementioned gateway migration method.

[0116] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0117] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0118] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0119] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A gateway migration method, characterized in that, The method includes: A first virtual gateway and a hardware gateway are deployed in the resource pool of the cloud network, and the network resource entities in the second virtual gateway in the cloud network are migrated to the first virtual gateway. The first virtual gateway and the hardware gateway are connected through a scalable virtual local area network tunnel. Receive a migration instruction for the cloud gateway, the migration instruction being used to instruct the cloud gateway to be migrated for the target virtual private cloud corresponding to the network resource entity; In response to the migration command, the outbound traffic corresponding to the target virtual private cloud is directly routed to the hardware gateway, so that the hardware gateway performs IP forwarding on the outbound traffic related to the target elastic IP address, wherein the outbound traffic is the traffic corresponding to the target elastic IP address in the target virtual private cloud.

2. The method according to claim 1, characterized in that, After receiving the migration instruction from the cloud gateway, the method further includes: The type of the migration instruction is determined based on the SDN interface corresponding to the migration instruction; The target elastic IP address is determined based on the type of the migration instruction.

3. The method according to claim 2, characterized in that, The migration instruction includes a first migration type and a second migration type; the target elastic IP address corresponding to the first migration type is any elastic IP address in the target virtual private cloud, and the target elastic IP address corresponding to the second migration type is all elastic IP addresses in the target virtual private cloud. The SDN interfaces corresponding to the first migration type and the second migration type are different.

4. The method according to claim 1, characterized in that, The step of directly routing the outbound traffic corresponding to the target virtual private cloud to the hardware gateway includes: The first routing path of the outbound traffic corresponding to the target virtual private cloud is switched to the second routing path so that the outbound traffic corresponding to the target virtual private cloud is directly routed to the hardware gateway. The first routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the first virtual gateway and from the first virtual gateway to the hardware gateway; the second routing path includes outbound traffic from the target virtual private cloud being routed from the virtual switch to the hardware gateway.

5. The method according to claim 1, characterized in that, After receiving the migration instruction from the cloud gateway, the method further includes: Send a forwarding rule flow table to the virtual switch corresponding to the target virtual private cloud; the forwarding rule flow table is used to encapsulate the outbound traffic with outer packets and match the inbound traffic.

6. The method according to claim 5, characterized in that, When the outer destination IP address of the outbound traffic packet is the IP address of the hardware gateway, the hardware gateway is further configured to remove the outer encapsulation of the outbound traffic to determine the inner packet of the outbound traffic, and perform network address forwarding based on the inner packet.

7. A gateway migration device, characterized in that, The device includes: The deployment module is used to deploy a first virtual gateway and a hardware gateway in the resource pool of the cloud network, and migrate the network resource entities in the second virtual gateway in the cloud network to the first virtual gateway. The first virtual gateway and the hardware gateway are connected through a scalable virtual local area network tunnel. The receiving module is used to receive the migration instruction of the cloud gateway, wherein the migration instruction is used to instruct the cloud gateway to be migrated to the target virtual private cloud corresponding to the network resource entity. The migration module is used to respond to the migration command and directly route the outbound traffic corresponding to the target virtual private cloud to the hardware gateway, so that the hardware gateway performs IP forwarding on the outbound traffic related to the target elastic IP address, wherein the outbound traffic is the traffic corresponding to the target elastic IP address in the target virtual private cloud.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of 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 steps of the method according to 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 steps of the method according to any one of claims 1 to 6.

Images