CN111314461B

CN111314461B - IP mounting and data processing method and device

Info

Publication number: CN111314461B
Application number: CN202010093444.XA
Authority: CN
Inventors: 姜琳; 雷思源; 周磊
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2020-02-14
Filing date: 2020-02-14
Publication date: 2022-05-17
Anticipated expiration: 2040-02-14
Also published as: CN111314461A; CN114363346A

Abstract

The embodiment of the application discloses an IP mounting method, a data processing method and a data processing device. One specific implementation of the IP mount method includes: receiving an IP mounting request, wherein the IP mounting request comprises IP information to be mounted; if a port indicated by the IP information to be mounted exists in a VPC where the load balancing equipment is located, acquiring the superposed layer configuration of the port indicated by the IP information to be mounted; if the port indicated by the IP information to be mounted does not exist in the VPC, acquiring the configuration of an overlay layer of virtual routing equipment in the VPC; and downloading the acquired superposition layer configuration to load equipment of the load balancing equipment. According to the implementation mode, the equipment mounted by the load balancing equipment is abstracted into the IP, so that the load balancing equipment supports various equipment such as a mounted elastic network card, a service network card, a cross-regional VPC or a server in a hybrid cloud, scenes supported by the load balancing equipment are greatly enriched, the processing difficulty of data on the cloud is reduced, and the use of cloud products by users is promoted.

Description

IP mounting and data processing method and device

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to an IP mounting method, a data processing method and a data processing device.

Background

Load Balance (LB) may Balance traffic data among multiple devices, respond to massive access requests, and implement service expansion. Furthermore, the method is simple. Load balancing can also avoid single point of failure and improve service availability. At present, a common method is to directly mount a device on a load balancing device, and the load balancing device directly distributes traffic data to the mounted device for processing based on load balancing.

Disclosure of Invention

The embodiment of the application provides an IP mounting method, a data processing method and a data processing device.

In a first aspect, an embodiment of the present application provides an IP mount method, including: receiving an Internet Protocol (IP) mounting request, wherein the IP mounting request comprises IP information to be mounted; if a port indicated by the IP information to be mounted exists in a Virtual Private Cloud (VPC) where the load balancing equipment is located, acquiring an overlay layer configuration of the port indicated by the IP information to be mounted, wherein the port in the VPC is mounted with the equipment; if the port indicated by the IP information to be mounted does not exist in the VPC, acquiring the configuration of an overlay layer of virtual routing equipment in the VPC; and downloading the acquired superposition layer configuration to load equipment of the load balancing equipment.

In some embodiments, downloading the obtained overlay configuration into a load device of a load balancing device includes: downloading the obtained superposed layer configuration to four layers of load equipment of the load balancing equipment; determining whether it is seven-layer load balancing; and if so, synchronizing the acquired superposed layer configuration from the four-layer load equipment to the seven-layer load equipment of the load balancing equipment.

In some embodiments, the method further comprises: receiving a port updating request, wherein the port updating request comprises a port to be updated; updating the equipment mounted on the port to be updated; searching the equipment mounted on the port to be updated through the IP, and updating the information of the equipment mounted on the port to be updated through the IP to the port to be updated.

In some embodiments, the method further comprises: receiving a port release request, wherein the port release request comprises a port to be released; unbinding the equipment mounted on the port to be released; and finding the equipment mounted on the port to be released through the IP, and leading the traffic data of the equipment mounted on the port to be released through the IP back to the virtual routing equipment.

In a second aspect, an embodiment of the present application provides a data processing method, including: receiving a data processing request, wherein the data processing request comprises to-be-processed flow data; processing an internet protocol, IP, based on load balancing allocation; and sending the traffic data to be processed to the equipment mounted by the processing IP for processing.

In some embodiments, sending the traffic data to be processed to the device mounted by the processing IP for processing includes: and if the processing IP exists in the VPC of the virtual private cloud where the load balancing equipment is located, sending the flow data to be processed to equipment mounted through the processing IP in the VPC for processing.

In some embodiments, sending the traffic data to be processed to the device mounted by processing IP, further comprising: if the processing IP exists in the VPC in the same region of the VPC, sending the flow data to be processed to virtual routing equipment in the VPC; and searching the routing information corresponding to the IP to be processed in the virtual routing equipment, and sending the traffic data to be processed to the equipment which is mounted by the IP to be processed in the same region VPC corresponding to the routing information for processing.

In some embodiments, sending the traffic data to be processed to the device mounted by processing IP, further comprising: if a processing IP exists in the cross-regional VPC of the VPC, sending flow data to be processed to virtual routing equipment in the VPC; and sending the traffic to be processed to the cross-regional virtual routing equipment in the cross-regional VPC through the virtual routing equipment in the VPC, so that the cross-regional virtual routing equipment sends the traffic data to be processed to equipment mounted by a processing IP in the cross-regional VPC for processing.

In some embodiments, sending the traffic data to be processed to the device mounted by processing IP, further comprising: if the processing IP exists in the opposite end mixed cloud of the VPC, sending the flow data to be processed to virtual routing equipment in the VPC; and sending the traffic to be processed to the hybrid virtual routing equipment in the opposite-end hybrid cloud through the virtual routing equipment in the VPC, so that the hybrid virtual routing equipment sends the traffic data to be processed to the equipment mounted by the processing IP in the opposite-end hybrid cloud for processing.

In some embodiments, the method further comprises: carrying out health check on the return process of the processing result of the traffic data to be processed; if the return process is a path, determining that the health check is normal; if the return process is not a path, determining that the health check is abnormal.

In some embodiments, the IP mounted device comprises at least one of: the server, the elastic network card of the server, the same IP port of the server, the service network card of the server and the container of the virtual machine.

In a third aspect, an embodiment of the present application provides an IP mount apparatus, including: the device comprises a first receiving unit, a second receiving unit and a third receiving unit, wherein the first receiving unit is configured to receive an Internet Protocol (IP) mounting request, and the IP mounting request comprises IP information to be mounted; the device comprises a first obtaining unit and a second obtaining unit, wherein the first obtaining unit is configured to obtain the superposed layer configuration of a port indicated by the IP information to be mounted if the port indicated by the IP information to be mounted exists in a Virtual Private Cloud (VPC) where the load balancing equipment is located, and the port in the VPC is mounted with the equipment; the second obtaining unit is configured to obtain the overlay layer configuration of the virtual routing equipment in the VPC if the port indicated by the IP information to be mounted does not exist in the VPC; a downloading unit configured to download the acquired overlay configuration into a load device of the load balancing device.

In some embodiments, the download unit comprises: a download subcell configured to download the acquired overlay configuration into a four-tier load device of the load balancing device; a determining subunit configured to determine whether it is seven-layer load balancing; and the synchronization subunit is configured to synchronize the obtained superposed layer configuration from the four-layer load equipment to the seven-layer load equipment of the load balancing equipment if the superposed layer configuration is the same as the obtained superposed layer configuration.

In some embodiments, the apparatus further comprises: a second receiving unit configured to receive a port update request, wherein the port update request includes a port to be updated; an update unit configured to update a device on which a port to be updated is mounted; and the searching and updating unit is configured to search the equipment mounted on the port to be updated through the IP and update the information of the equipment mounted on the port to be updated through the IP onto the port to be updated.

In some embodiments, the apparatus further comprises: a third receiving unit configured to receive a port release request, wherein the port release request includes a port to be released; a unbinding unit configured to unbind the device mounted on the port to be released; and the searching and leading-back unit is configured to search the equipment mounted on the port to be released through the IP and lead back the traffic data of the equipment mounted on the port to be released through the IP to the virtual routing equipment.

In a fourth aspect, an embodiment of the present application provides a data processing apparatus, including: a receiving unit configured to receive a data processing request, wherein the data processing request includes to-be-processed traffic data; an allocation unit configured to process an internet protocol, IP, based on load balancing allocation; and the sending unit is configured to send the traffic data to be processed to the equipment mounted by the processing IP for processing.

In some embodiments, the sending unit is further configured to: and if the processing IP exists in the VPC of the virtual private cloud where the load balancing equipment is located, sending the flow data to be processed to equipment mounted through the processing IP in the VPC for processing.

In some embodiments, the sending unit is further configured to: if the processing IP exists in the VPC in the same region of the VPC, sending the flow data to be processed to virtual routing equipment in the VPC; and searching the routing information corresponding to the IP to be processed in the virtual routing equipment, and sending the traffic data to be processed to the equipment which is mounted by the IP and is in the same region VPC corresponding to the routing information for processing.

In some embodiments, the sending unit is further configured to: if a processing IP exists in the cross-regional VPC of the VPC, sending flow data to be processed to virtual routing equipment in the VPC; and sending the traffic to be processed to the cross-regional virtual routing equipment in the cross-regional VPC through the virtual routing equipment in the VPC, so that the cross-regional virtual routing equipment sends the traffic data to be processed to equipment mounted by a processing IP in the cross-regional VPC for processing.

In some embodiments, the sending unit is further configured to: if the processing IP exists in the opposite end hybrid cloud of the VPC, sending the traffic data to be processed to virtual routing equipment in the VPC; and sending the traffic to be processed to the hybrid virtual routing equipment in the opposite-end hybrid cloud through the virtual routing equipment in the VPC, so that the hybrid virtual routing equipment sends the traffic data to be processed to the equipment mounted by the processing IP in the opposite-end hybrid cloud for processing.

In some embodiments, the apparatus further comprises: the checking unit is configured to perform health check on a return process of a processing result of the to-be-processed flow data; a first determination unit configured to determine that the health check is normal if the return process is a pass; a second determination unit configured to determine that the health check is abnormal if the return process is not a path.

In some embodiments, the device mounted over IP comprises at least one of: the server, the elastic network card of the server, the same IP port of the server, the service network card of the server and the container of the virtual machine.

In a fifth aspect, an embodiment of the present application provides an electronic device, including: one or more processors; a storage device having one or more programs stored thereon; when executed by one or more processors, cause the one or more processors to implement a method as described in any of the implementations of the first aspect or to implement a method as described in any of the implementations of the second aspect.

In a sixth aspect, the present application provides a computer-readable medium, on which a computer program is stored, which when executed by a processor implements the method described in any of the implementation manners in the first aspect or implements the method described in any of the implementation manners in the second aspect.

According to the IP mounting and data processing method and device provided by the embodiment of the application, under the condition of receiving an Internet Interconnection Protocol (IP) mounting request, whether a port indicated by IP information to be mounted exists in a Virtual Private Cloud (VPC) where load balancing equipment is located is determined; then, acquiring the superposed layer configuration of the port indicated by the IP information to be mounted under the condition that the port indicated by the information to be mounted exists, and acquiring the superposed layer configuration of the virtual routing equipment in the VPC under the condition that the port indicated by the information to be mounted does not exist; and finally downloading the acquired superposition layer configuration to load equipment of the load balancing equipment. The equipment mounted by the load balancing equipment is abstracted into an IP (Internet protocol), so that the load balancing equipment supports various equipment such as a mounted elastic network card, a service network card, a cross-regional VPC (virtual private network controller) or a server in a hybrid cloud, scenes supported by the load balancing equipment are greatly enriched, the processing difficulty of data on the cloud is reduced, and the use of cloud products by users is promoted.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:

FIG. 1 is an exemplary system architecture to which the present application may be applied;

FIG. 2 is a flow diagram of one embodiment of an IP mount method according to the present application;

FIG. 3 is a flow diagram of yet another embodiment of an IP mount method according to the present application;

FIG. 4 is a flow diagram of one embodiment of a data processing method according to the present application;

FIG. 5A is a schematic diagram of an elastic network card mounted via IP;

FIG. 5B is a schematic diagram of ports mounted with IP over IP;

FIG. 5C is a schematic diagram of a network card through IP mount service;

FIG. 5D is a schematic diagram of servers in a cross-regional VPC mounted over IP;

FIG. 5E is a schematic diagram of a server in a hybrid cloud mounted over IP;

FIG. 5F is a schematic illustration of a container mounted by IP;

FIG. 6 illustrates a data model relationship for a Meta-Server module;

FIG. 7 is a flow diagram of yet another embodiment of a data processing method according to the present application;

FIG. 8A is a schematic diagram of processing four layers of traffic data with a VPC;

FIG. 8B is a schematic diagram of processing seven layers of traffic data with a VPC;

FIG. 8C is a schematic illustration of co-regional processing of traffic data;

FIG. 8D is a schematic illustration of cross-regional processing of traffic data;

fig. 8E is a schematic diagram of hybrid cloud processing traffic data;

FIG. 9 is a schematic block diagram of one embodiment of an IP mount according to the present application;

FIG. 10 is a schematic block diagram of one embodiment of a data processing apparatus according to the present application;

FIG. 11 is a block diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.

Detailed Description

The present application will be described in further detail with reference to the following drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings.

It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.

Fig. 1 illustrates an exemplary system architecture 100 to which embodiments of the IP mount, data processing method or IP mount, data processing apparatus of the present application may be applied.

As shown in fig. 1, a system architecture 100 may include a terminal device 101 and a VPC 102. A load balancing device 103 is created within VPC 102. The load balancing device 103 is hooked up with devices 104, 105, 106 and IP group 107. Wherein the devices 104, 105, 106 are mounted on the load balancing device 103 through the IPs in the IP group 107.

A user may use the terminal device 101 to interact with the load balancing device 103 to receive or send messages or the like. The load balancing device 103 may provide various services. For example, the load balancing device 103 may receive a data processing request; processing the IPs (IPs in IP group 107) based on load balancing allocation; and sending the traffic data to be processed to a device (such as any one of the devices 104, 105 and 106) mounted by the processing IP for processing.

It should be understood that the number of end devices, VPCs, load balancing devices created within VPCs, devices on which load balancing devices are mounted, IP groups, and IPs in an IP group in fig. 1 are merely illustrative. Any number of terminal devices, VPCs, load balancing devices created within VPCs, devices on which load balancing devices are mounted, IP groups, and IPs in an IP group may be present, as desired for implementation.

With continued reference to fig. 2, a flow 200 of one embodiment of an IP mount method according to the present application is shown. The IP mounting method comprises the following steps:

step 201, an IP mount request is received.

In this embodiment, a load balancing device (e.g., the load balancing device 103 shown in fig. 1) may receive an IP (Internet Protocol) mount request. The IP mount request may include the IP information to be mounted. The to-mount IP information may include the to-mount IP. Optionally, the to-be-mounted IP information further includes ports of the to-be-mounted IP, where one IP may correspond to at least one port.

Step 202, if a port indicated by the IP information to be mounted exists in the VPC where the load balancing device is located, acquiring an overlay layer configuration of the port indicated by the IP information to be mounted.

In this embodiment, if a port indicated by the IP information to be mounted exists in the VPC where the load balancing device is located, the load balancing device may obtain Overlay (Overlay) configuration of the port indicated by the IP information to be mounted. The ports in the VPC may be used to mount devices, including but not limited to servers, flexible network cards of servers, ports of servers with the same IP, service network cards of servers, containers of virtual machines, and the like.

And step 203, if the port indicated by the IP information to be mounted does not exist in the VPC, acquiring the configuration of the superposition layer of the virtual routing equipment in the VPC.

In this embodiment, if there is no port indicated by the IP information to be mounted in the VPC where the load balancing device is located, the load balancing device may obtain Overlay configuration of a Virtual routing device (VR) in the VPC.

And step 204, downloading the acquired overlay configuration to load equipment of the load balancing equipment.

In this embodiment, the load balancing device may download the acquired Overlay configuration to the load device of the load balancing device to complete IP mounting. Specifically, if the port Overlay configuration is obtained, the load device that downloads the Overlay configuration to the load balancing device may complete the binding between the mounted device and the IP to be mounted. Therefore, the flow data can reach the corresponding port through the IP to be mounted, the links on the flow path are ensured to be minimum, and the flow pressure on the virtual routing equipment is reduced. If the Overlay configuration of the virtual routing device is obtained, the load device downloading the Overlay configuration to the load balancing device can complete the mounting of the IP routing back to the virtual routing device. Therefore, the traffic data can be imported into the virtual routing device through the IP to be mounted, and the virtual routing device determines whether the next hop exists and how to forward the next hop according to the routing rule of the virtual routing device, and depends on the routing capability of the virtual routing device.

In general, the load devices of the load balancing device may include BGW and Nginx. The BGW is public cloud intranet four-layer load equipment. Nginx is a seven-layer load device for a public cloud intranet. In some optional implementation manners of this embodiment, the load balancing device may download the acquired Overlay configuration to the BGW of the load balancing device; determining whether it is seven-layer load balancing; if not, only downloading the acquired Overlay configuration into the BGW; if yes, the acquired Overlay configuration needs to be synchronized from the BGW to the Nginx of the load balancing device.

In addition, since the device is mounted in the form of IP, the real resource instance life cycle represented by IP may be changed variously, and the corresponding configuration changes are shown in the following table:

it should be noted that, the above example is a case where there is a port in the VPC where the load balancing device is located, and whether there is an Overlay configuration for the port is mainly determined by whether it mounts the device. For a single port, once the port is fixed, the VPC where the port is located is also fixed, the Overlay configuration is variable, and the mounted equipment is also variable. And (4) all changes of the port are initiated by a user, Neutron perception is realized, ETCD and Meta-catcher perception are updated, and the Meta is informed and processed. The next life cycle for the example represented by IP is actually an arbitrary loop of the scenario in the table.

According to the IP mounting method provided by the embodiment of the application, under the condition that an Internet Protocol (IP) mounting request is received, whether a port indicated by IP information to be mounted exists in a Virtual Private Cloud (VPC) where load balancing equipment is located is determined; then, acquiring the superposed layer configuration of the port indicated by the IP information to be mounted under the condition that the port indicated by the information to be mounted exists, and acquiring the superposed layer configuration of the virtual routing equipment in the VPC under the condition that the port indicated by the information to be mounted does not exist; and finally downloading the acquired superposition layer configuration to load equipment of the load balancing equipment. The equipment mounted by the load balancing equipment is abstracted into an IP (Internet protocol), so that the load balancing equipment supports various equipment such as a mounted elastic network card, a service network card, a cross-regional VPC (virtual private network controller) or a server in a hybrid cloud, scenes supported by the load balancing equipment are greatly enriched, the processing difficulty of data on the cloud is reduced, and the use of cloud products by users is promoted.

With further reference to fig. 3, a flow 300 of yet another embodiment of an IP mount method according to the present application is shown. The IP mounting method comprises the following steps:

step 301, an IP mount request is received.

Step 302, determining whether a port indicated by the IP information to be mounted exists in the VPC where the load balancing device is located.

Step 303, acquiring the overlay layer configuration of the port indicated by the IP information to be mounted.

Step 304, acquiring the overlay layer configuration of the virtual routing device in the VPC.

Step 305, downloading the obtained overlay configuration to a load device of the load balancing device.

In the present embodiment, the specific operations of step 301-.

Step 306, a port update request is received.

In this embodiment, a load balancing device (e.g., load balancing device 103 shown in fig. 1) may receive a port update request. The port update request may include a port to be updated. The port to be updated may be the port in the VPC where the load balancing device is located.

Step 307, updating the device mounted on the port to be updated.

In this embodiment, the load balancing device may update the device to be updated with the port mount. Generally, the load balancing device will update all devices mounted on the port to be updated, including both devices mounted on the port to be updated through IP and devices directly mounted on the port to be updated.

Step 308, finding the device mounted on the port to be updated through the IP, and updating the information of the device mounted on the port to be updated through the IP onto the port to be updated.

In this embodiment, the load balancing device may search for a device mounted on the port to be updated through the IP, and update information of the device mounted on the port to be updated through the IP onto the port to be updated. Specifically, the load balancing device may download information of the device mounted on the port to be updated through the IP to the load device of the load balancing device, so that the device mounted on the port to be updated through the IP is bound to the port to be updated.

In step 309, a port release request is received.

In this embodiment, the load balancing device may receive a port release request. Wherein the port release request may include the port to be released. The port to be released may be a port in the VPC where the load balancing device is located.

And step 310, unbinding the device to be released from the port mounting.

In this embodiment, the load balancing device may unbind the device to be released from port mount. Generally, the load balancing device will unbind all devices mounted on the port to be released, including both devices mounted on the port to be released through IP and devices directly mounted on the port to be released.

Step 311, finding the device mounted on the port to be released through the IP, and directing the traffic data of the device mounted on the port to be released through the IP back to the virtual routing device.

In this embodiment, the load balancing device may search for a device mounted on the port to be released through the IP, and direct traffic data of the device mounted on the port to be released through the IP back to the virtual routing device. Specifically, the load balancing device may download the Overlay configuration of the virtual routing device to the load device of the load balancing device, so as to complete the guiding back of the port to be released to the virtual routing device.

It should be noted that step 306 and step 308 are executed only when the port update request is received. Step 309 and 311 are performed when the port release request is received. Steps 306-308 and 309-311 are two completely independent processes.

As can be seen from fig. 3, compared with the embodiment corresponding to fig. 2, the flow 300 of the IP mount method in this embodiment adds the steps of port update and port release. Thus, the scheme described in the present embodiment improves the flexibility of port update and release.

With continued reference to FIG. 4, a flow 400 of one embodiment of a data processing method according to the present application is shown. The data processing method comprises the following steps:

step 401, a data processing request is received.

In this embodiment, a load balancing device (e.g., load balancing device 103 shown in fig. 1) may receive a data processing request. The data processing request may include to-be-processed traffic data.

Step 402, process IP based on load balancing assignment.

In this embodiment, the load balancing device may process the IP based on load balancing allocation. The processing IP may indicate a port in the VPC where the load balancing device is located, or may indicate a port outside the VPC where the load balancing device is located.

And step 403, sending the traffic data to be processed to the device mounted by the processing IP for processing.

In this embodiment, the load balancing device may send the traffic data to be processed to the device mounted by the processing IP for processing. Wherein the device mounted by IP may include, but is not limited to, at least one of: a server, a flexible network card of the server, a port of the server with the IP, a service network card of the server, a container of the virtual machine, and the like.

In some optional implementations of this embodiment, the device mounted through the IP may be an elastic network card of the server. For ease of understanding, fig. 5A shows a schematic diagram of mounting an elastic network card over IP. As shown in fig. 5A, two load balancers LB1 and LB2 are provided in the VPC. LB1 and LB2 mount network card 1, network card 2, and network card 3 of cloud server CC through IP. By specifying the IP identifier of the elastic network card, the function that the user uses different network cards or different IPs of the cloud server to receive and process the traffic data forwarded by the load balancing device can be realized, the user can manage the traffic data finely, and the traffic data isolation can be realized.

In some optional implementations of this embodiment, the device mounted through the IP may be a port of the server that is in the same IP. For ease of understanding, fig. 5B shows a schematic diagram of ports mounted with IP over IP. As shown in fig. 5B, a load balancing device LB is provided in the VPC. The LB mounts the port 1, the port 2 and the port 3 of the cloud server CC with the IP through the IP. The method supports the user to forward the flow data to different ports of the same IP according to the same forwarding strategy of the same monitor, and supports the scene that the user fully utilizes cloud server resources or manages and forwards the flow data according to the ports.

In some optional implementations of this embodiment, the device mounted through the IP may be a service network card of the server. For ease of understanding, fig. 5C shows a schematic diagram of a network card for a service being mounted over IP. As shown in fig. 5C, a load balancing device LB is provided in the VPC. LB through IP mounting service network card, service network card connecting object storing OS. In addition, the load balancing device also mounts the cloud servers CC1 and CC 2. By specifying the IP identification of the service network card, the user can be supported to use the service outside the VPC through the load balancing equipment. For example, a web architecture is constructed by using a load balancing device, static content can be directly forwarded to an object storage through a service network card for processing, and dynamic content is forwarded to a cloud server for processing.

In some optional implementations of this embodiment, the IP mounted device may be a server in a cross-regional VPC. For ease of understanding, fig. 5D shows a schematic diagram of servers in a cross-regional VPC mounted over IP. As shown in FIG. 5D, VPC1, VPC2, and VPC3 are VPCs of different areas and communicate via peer-to-peer connections. A cloud server CC1 is provided in the VPC 1. Load balancing equipment LB and cloud servers CC2 and CC3 are arranged in the VPC2, and the LB is used for mounting the cloud servers CC2 and CC3 through IP. A cloud server CC4 is provided in the VPC 3. The IP of the IP group can be an intranet reachable IP and supports a cross-VPC and cross-region binding scene. A user firstly makes through a plurality of VPCs by using peer-to-peer connection, and then can specify the IP address of the cross-VPC or cross-regional cloud server to be mounted on the load balancing equipment.

In some optional implementations of this embodiment, the device mounted by IP may be a server in a hybrid cloud. For ease of understanding, fig. 5E shows a schematic diagram of servers in a hybrid cloud mounted over IP. As shown in fig. 5E, the hybrid cloud includes internet data centers IDC1, IDC2, and VPC and IDC1 communicate through dedicated wires, and VPC and IDC2 communicate through VPN. A physical server is located within IDC 1. Load balancing equipment LB, cloud servers CC1 and CC2 are arranged in the VPC, and the LB is used for mounting the cloud servers CC1 and CC2 through an IP. A server is located within IDC 2. After a user gets through to the VPC by using a private line or a VPN, the IP of the hybrid cloud opposite-end server can be specified in the IP group of the load balancing equipment, so that the traffic data is forwarded to the hybrid cloud opposite-end server for processing.

In some optional implementations of this embodiment, the device mounted by IP may be a container of a virtual machine. For ease of understanding, fig. 5F shows a schematic diagram of mounting a container by IP. As shown in fig. 5F, a load balancing device LB is provided in the VPC. LB mounts container 1, container 2, and container 3 of the virtual machine VM through IP. By specifying the IP identifier of the container, the container can be mounted on the back end of the load balancing device, so as to distribute the traffic data to the container for processing. Wherein, the container types can include but are not limited to BCI, CCE, edge container network, user self-built container K8S. The BCI is a group of container groups, a main network card port is arranged, all containers share the port, and specific load balancing is performed to specific containers after flow reaches the port. And binding the CCE with the IP of the virtual machine, carrying out load balancing in the container network through IpTables mapping, and forwarding to a specific container.

In some embodiments, the CCE may access the elastic network card, each container exposes the IP to the outside by binding the elastic network card, and the load balancing device mounts the container by binding the IP of the elastic network card.

In some embodiments, the BCI is exposed to the outside by the instance identity of the container group, a specific container IP is not exposed to the user, the IP is exposed by the identity of the BCI instance (by means of Neutron Port or an elastic network card), and the specific load balancing is performed to the specific container after the traffic reaches the Pod container group of the BCI.

In some embodiments, the self-built container K8S supports a bonded resilient network card, providing data stream access in the form of a load balancing device mounting the resilient network card IP.

In some optional implementation manners of this embodiment, the load balancing device may perform health check on a return process of a processing result of the traffic data to be processed; if the return process is a passage, determining that the health check is normal; if the return process is not a path, determining that the health check is abnormal.

In some optional implementation manners of this embodiment, since the IP is randomly specified, it is necessary to prevent the device-side data stream/health check data stream from looping due to mutual IP pointing, which causes a storm and causes a fault to the device. Specifically, the situation of single-step ring formation formed by mutual fingers of the load balancing instance and the service network card instance of the same VPC is prohibited from being mounted, and the situation of N-step ring formation formed by mutual fingers of the above instances of the cross VPC is allowed to be mounted. The IP looping strategy mainly comprises looping detection, loop breaking and looping recovery. The ring-forming detection mainly relates to an example that an IP in an IP group mounted by the load balancing equipment belongs to the load balancing equipment type with the same VPC, and whether a ring-forming condition exists or not can be correspondingly checked when the load balancing equipment or the second-stage service network card is included. If looping occurs, the corresponding IP instance configuration is not issued to the equipment end, and the user is subjected to abnormal perception through health check of the back-end IP instance, which belongs to damage. And if the looping condition does not exist, the corresponding configuration is issued to the equipment end. The looping recovery mainly includes releasing load balancing device instance/end address instance, or when the second-stage service is unbound, detecting whether there is an IP instance in the corresponding instance, and simultaneously detecting whether there is a scene in which looping is broken on a looping link when the corresponding IP instance is released, the IP link existing in the corresponding scene is recovered, which is the looping recovery. The looping recovery mainly corresponds to three scenes: releasing the load balancing device instance, releasing the endpoint instance, and binding and unbinding the back-end load balancing device of the second-stage service. The binding and unbinding of the back-end load balancing device of the second-stage service corresponds to the checking of a plurality of endpoint instances. Because one second-phase service can receive a plurality of endpoint designations, the whole looping detection, the breakage and the looping recovery are realized by performing recursive detection at the back end, the recursive detection reagent starts from one example, whether the example returns to the example or goes out from a certain outlet is judged, otherwise, the recursion is performed layer by layer until a proper outlet is found (the proper outlet is found), and the breakage and the recovery are based on the results. The recovery mainly comprises the steps of detecting whether any broken chain breaks into a ring because the node exits on an IP chain where the instance is located after the instance is released, and recovering, wherein actually, each node on the IP chain recursively searches whether the broken chain breaks layer by layer.

Here, the control plane introduces a DataModel of the VPC, and locks the corresponding VPC in all the scenarios that may cause the looping operation, so as to ensure that only one VPC at a time may cause the operation of the looping scenario to be performed. After locking, checking the resources in the VPC to confirm whether to form rings or not, and if not, allowing configuration. And for the scene that the load balancing equipment mounts the IP group, when the load balancing equipment or the service network card is in the IP group in a second-stage instance, locking the VPC and checking whether the resources form a ring or not. For a scenario that a service publishing point binds a load balancing device, a VPC where the load balancing device is located needs to be locked, and whether a service network card instance of the service publishing point under the same VPC forms a ring or not is checked. For the scene of binding the service release point again after the service network card is created, the VPC is locked and the check is executed only when the service network card and the service release point binding load balancing device are in the same VPC. The binding can be carried out under the same VPC as long as the ring is not actually formed, the range of the IP in the same VPC is greatly expanded, and the IP resources under the same VPC are not limited except for the mutual-indication scene.

In addition, the data model of the Meta-Server module may include, but is not limited to, app _ ip _ group, app _ ip _ member, app _ ip _ group _ policy, app _ policy, and vpc _ instance, among others.

Wherein, the app _ IP _ group mark belongs to the IP group information under an ELB, which is specifically shown in the following table:

all attributes of app _ ip _ member are consistent with elb _ rs/app _ rs, except that ip/port/weight is an optional option, and may be a port that does not exist actually or a port outside the VPC, as shown in the following table:

specifically, the app _ ip _ group _ policy is shown in the following table:

wherein, app _ policy is specifically shown in the following table:

group_type	ip_group_id	group_policy_id
			ip/instance	ip group id	ip group policy id

wherein vpc _ instance is specified in the following table:

for ease of understanding, FIG. 6 illustrates the data model relationship of the Meta-Server module. As shown in fig. 6, the IP number and the IP group have a one-to-one relationship, and one IP group has a plurality of IP numbers. The listener binds an IP group and then automatically locates the corresponding health check policy and its port by the policy of the IP group (ipPolicy).

In addition, for the BNC module, as can be known from a section of data flow analysis, for the IP resources mounted with non-VPCs, the rear-end RS uniformly goes through a Fullnat mode, the four-layer packet returns to the BGW with DestIP as BIP, the acquisition rule matched with VIP/OVIP on the CN is no longer applicable, and for the VS with the following RS designated to go through the Fullnat mode, the BNC only needs to acquire backward flow data on the BGW. That is, for the vs _ mode of Listener in Meta DB, which is Fullnat mode, BNC does not need to filter the outgoing traffic on BGW, while for the traffic collected on CN, for the above Listener, it needs to filter the CN collected traffic (actually 0, filtering prevents covering).

The data processing method provided by the embodiment of the application comprises the steps of firstly receiving a data processing request; then, IP is distributed and processed based on load balance; and finally, sending the traffic data to be processed to the equipment mounted by the processing IP for processing. The equipment mounted by the load balancing equipment is abstracted into the IP, so that the scenes supported by the load balancing equipment are greatly enriched. In addition, scenes such as an elastic network card, a service network card and a mixed cloud are supported, and the use flexibility is improved.

With further reference to FIG. 7, a flow 700 of yet another embodiment of a data processing method according to the present application is shown. The data processing method comprises the following steps:

step 701, receiving a data processing request.

Step 702, process IP based on load balancing assignment.

In the present embodiment, the steps 701-702 are already described in the steps 401-402 in the embodiment shown in fig. 2, and are not described herein again.

Step 703, determining whether a processing IP exists in the VPC where the load balancing device is located.

In this embodiment, a load balancing device (e.g., the load balancing device 103 shown in fig. 1) may determine whether a processing IP exists in the VPC where the load balancing device is located. If yes, go to step 704; if not, go to step 705.

And step 704, sending the traffic data to be processed to the equipment mounted by the processing IP in the VPC for processing.

In this embodiment, if a processing IP exists in the VPC where the load balancing device is located, the load balancing device may send the traffic data to be processed to a device mounted through the processing IP in the VPC for processing. The advantage of processing flow data by the same VPC is that the flow data processing method is universal and expandable, and can mount any existing resource equipment (ENI/SNIC/BCI and the like) in the same VPC.

For ease of understanding, FIG. 8A shows a schematic diagram of processing four layers of traffic data with a VPC. As shown in fig. 8A, the cloud server CC belongs to VPC-a together with the port of the device mounted by IP. Traffic data flows between the CC, the BGW, and the port of the device mounted by IP in the order of the arrow on fig. 8A and the reference number on the arrow. FIG. 8B shows a schematic diagram of processing seven layers of traffic data with a VPC. As shown in fig. 8B, the cloud server CC belongs to VPC-a together with the port of the device mounted through IP. Traffic data flows between CC, BGW, Nginx, and a port of a device mounted by IP in the order of arrows and reference numerals on the arrows on fig. 8B.

Step 705, determine if there is a process IP in the VPC's co-located VPC.

In this embodiment, if the processing IP does not exist in the VPC where the load balancing device is located, the load balancing device may determine whether the processing IP exists in the VPC in the same area as the VPC. If yes, go to step 706; if not, go to step 708.

Step 706, sending the traffic data to be processed to the virtual routing device in the VPC.

In this embodiment, the load balancing device may send the traffic data to be processed to the virtual routing device in the VPC.

Step 707, searching the routing information corresponding to the to-be-processed IP in the virtual routing device, and sending the to-be-processed traffic data to the device mounted by the processing IP in the same region VPC corresponding to the routing information for processing.

In this embodiment, the load balancing device may search for routing information corresponding to the to-be-processed IP in the virtual routing device, and send the to-be-processed traffic data to a device mounted through the processing IP in the same area VPC corresponding to the routing information for processing.

For ease of understanding, fig. 8C shows a schematic diagram of the same region processing traffic data. As shown in FIG. 8C, VPC-A and VPC-B are different VPCs in the same area, virtual routing device VR belongs to VPC-A, and the port of the device mounted via IP belongs to VPC-B. Traffic data flows between BGW, VR, and ports of devices mounted by IP in the order of arrows and reference numbers on the arrows on fig. 8C. Generally, each BGW cluster will publish its own BIP segment, and each BIP segment will generate a common route in all VPCs in the whole area, so that VPCs to BGW clusters are reachable. Currently, the incoming and outgoing data flows of the BGW all check Vni, and there is Vni dependence, and Vni is relied on to locate the corresponding session.

In some optional implementation manners of this embodiment, the load balancing device may perform health check on a return process of a processing result of the traffic data to be processed. Specifically, the BGW may send the source IP as the BIP to the virtual routing device in the VPC where the load balancing device is located; finding out corresponding routing information on the virtual routing equipment, and forwarding the flow data to ports corresponding to other VPCs; when the Port returns the processing result, the source IP is a BIP network segment, directly hits the public route and directly returns to the BGW; because the returned Vni of the returned processing result is changed and is inconsistent with the output Vni of the packet, the BGW cannot recognize the packet, the data flow is interrupted, and the health check is abnormal. Typically, health checks are abnormal and traffic data is not forwarded. In the DR mode, in the triangle mode, the source IP is visible, and the port directly returns a processing result to the cloud server. In the IMF mode and the triangular mode, the port directly returns a processing result to the cloud server. In the Fullnat mode, the symmetric mode returns the result directly to BGW, and data flow is interrupted due to Vni inconsistency. In summary, both health check and data flow are abnormal in different VPC scenarios.

At step 708, it is determined whether a process IP exists in the VPC across the region of the VPC.

In this embodiment, the load balancing device may determine whether a process IP exists in a cross-regional VPC of the VPC. If yes, go to step 709; if not, go to step 711.

And step 709, sending the traffic data to be processed to the virtual routing equipment in the VPC.

In this embodiment, if there is a processing IP in the cross-domain VPC of the VPC, the load balancing device may send the traffic data to be processed to the virtual routing device in the VPC.

Step 710, sending the traffic to be processed to the cross-regional virtual routing device in the cross-regional VPC through the virtual routing device in the VPC.

In this embodiment, the load balancing device may send the traffic to be processed to the cross-regional virtual routing device in the cross-regional VPC through the virtual routing device in the VPC, so that the cross-regional virtual routing device sends the traffic data to be processed to the device mounted by the processing IP in the cross-regional VPC for processing.

For ease of understanding, fig. 8D shows a schematic diagram of cross-regional processing of traffic data. As shown in FIG. 8D, virtual routing device VR-A belongs to VPC-A, VPC-A belongs to Region-A, virtual routing device VR-B and the port of the device mounted over IP belong to VPC-B, and VPC-B belongs to Region-B. Traffic data flows between the BGWs, VR-A, VR-B and the ports of the IP mounted devices in the order of the arrows and the labels on the arrows in FIG. 8D. Generally, different BIP network segments are issued by BGW clusters in different areas, which are not overlapped with each other, and each area only loads the public routing of the BIP in the area and is not sensed with each other. Therefore, in order to implement cross-regional intercommunication, the route of the BIP network segment of the region needs to be added in the opposite-end VPC, and the next hop points to the VPC.

In some optional implementations of this embodiment, the load balancing device may perform health check on a return process of a processing result of the to-be-processed traffic data. Specifically, the BGW directs traffic data to the virtual routing device; the virtual routing equipment guides the flow data to virtual routing equipment of a cross-regional opposite end VPC; the opposite end virtual router device leads the flow data to the opposite end Port; the Port returns the processing result to the opposite end virtual routing equipment; the opposite virtual routing equipment imports the processing result into the virtual routing equipment of the VPC according to the increased BIP routing of the local area; and the home terminal virtual routing equipment returns the processing result to the BGW. As can be seen, the health check and data flow are both in the above scenario. The scene supports a load balancing device to mount resources in different VPCs of cross regions, and only one corresponding route is required to be added in each VPC. If the resources in the same VPC of the opposite end are mounted under different VPCs in the area, because the VPC of the opposite end can only specify one route for the BIP network segment of the area, if the next hop is specified to VPC-A, the data flow of the load balancing equipment in the VPC-B of the area is caused to flow to the VPC of the opposite end, and the VPC of the opposite end only flows the data back to one VPC, so that the data flow of the VPC-B is not communicated. In sum, the cross-region supports 1: N scenes and does not support N:1 scenes. Furthermore, N: M scenarios are supported across regions without concern for Vni.

Step 711, determine whether there is a processing IP in the opposite end hybrid cloud of the VPC.

In this embodiment, if there is no processing IP in the cross-regional VPC of the VPC, the load balancing device may determine whether there is a processing IP in the opposite-end hybrid cloud of the VPC. If so, go to step 712; if not, the flow is ended.

Step 712, sending the traffic data to be processed to the virtual routing device in the VPC.

In this embodiment, if a processing IP exists in the opposite-end hybrid cloud of the VPC, the load balancing device may send the traffic data to be processed to the virtual routing device in the VPC.

And 713, sending the traffic to be processed to the hybrid virtual routing device in the opposite-end hybrid cloud through the virtual routing device in the VPC.

In this embodiment, the load balancing device may send the traffic to be processed to the hybrid virtual routing device in the opposite-end hybrid cloud through the virtual routing device in the VPC, so that the hybrid virtual routing device sends the traffic data to be processed to the device mounted in the opposite-end hybrid cloud through the processing IP for processing.

For ease of understanding, fig. 8E shows a schematic diagram of hybrid cloud processing traffic data. As shown in FIG. 8E, virtual routing device VR belongs to VPC-A and the port of the device mounted over IP belongs to VPC-B. Traffic data flows between the BGW, VR, BCNAT and the port of the device mounted by IP in the order of the arrow on fig. 8E and the label on the arrow.

In some optional implementations of this embodiment, the load balancing device may perform health check on a return process of a processing result of the to-be-processed traffic data. The data stream of the mixed cloud scene is consistent with the cross-region, the conclusion is consistent, and the 1: N scene is supported. Furthermore, the hybrid cloud supports N: M scenarios without concern for Vni. Specifically, for mounting the EIP in the same area, as known from the health check data flow, taking the EIP backend binding to the cloud server as an example, since the Port of the opposite-end VPC directly replies BGW and Vni is inconsistent, BGW does not recognize the packet, and the health check fails. In the DR mode, it is mainly whether the two VPCs are accessible themselves, otherwise they are not. In Fullnat mode, off, Vni limits. For mounting EIPs in different areas, since no corresponding identity is used as SNAT to go out after the BIP of BGW reaches bcat, data flow interruption may be caused. In the DR mode, the client is dependent on whether the client has a public network identity. In the Fullnat mode, no, BIP has no identity. For the mounted external network IP, the health check and data flow are consistent with the mounted external network EIP. For other unreachable IP, the health check and the data flow are unreachable, and the virtual routing equipment does not have corresponding routing information.

It should be noted that, in the above scenario, the data flow phenomenon in the DR mode or the Fullnat mode is different, and for the cross-regional or hybrid cloud scenario, only the Fullnat can return the packet by adding the BIP route, so for the mount IP group, for the non-VPC resource, the Fullnat mode is uniformly moved.

As can be seen from fig. 7, compared with the embodiment corresponding to fig. 4, the flow 700 of the data processing method in the present embodiment highlights the step of sending traffic data. Therefore, the scheme described in this embodiment supports various scenes such as the same VPC, the same region, cross-region, and mixed cloud, and greatly enriches the scenes supported by the load balancing device.

With further reference to fig. 9, as an implementation of the methods shown in the above-mentioned figures, the present application provides an embodiment of an IP mount apparatus, which corresponds to the method embodiment shown in fig. 2, and which can be applied in various electronic devices.

As shown in fig. 9, the IP mount apparatus 900 of the present embodiment may include: a first receiving unit 901, a first acquiring unit 902, a second acquiring unit 903 and a downloading unit 904. The first receiving unit 901 is configured to receive an internet protocol IP mount request, where the IP mount request includes IP information to be mounted; a first obtaining unit 902, configured to obtain an overlay layer configuration of a port indicated by to-be-mounted IP information if the port indicated by the to-be-mounted IP information exists in a virtual private cloud VPC where the load balancing device is located, where the port in the VPC is mounted with the device; a second obtaining unit 903, configured to obtain an overlay layer configuration of the virtual routing device in the VPC if the VPC does not have a port indicated by the to-be-mounted IP information; a downloading unit 904 configured to download the obtained overlay configuration into a load device of the load balancing device.

In this embodiment, IP mount apparatus 900: the detailed processing and the technical effects of the first receiving unit 901, the first obtaining unit 902, the second obtaining unit 903 and the downloading unit 904 can refer to the related descriptions of step 201 and step 204 in the corresponding embodiment of fig. 2, which are not described herein again.

In some optional implementations of this embodiment, the downloading unit 904 includes: a download subunit (not shown in the figure) configured to download the obtained overlay layer configuration into a four-layer load device of the load balancing device; a determining subunit (not shown in the figure) configured to determine whether it is seven-layer load balancing; a synchronization subunit (not shown in the figure) configured to synchronize the obtained overlay layer configuration from the four-layer load device to the seven-layer load device of the load balancing device if yes.

In some optional implementations of this embodiment, the IP mount apparatus 900 further includes: a second receiving unit (not shown in the figure) configured to receive a port update request, wherein the port update request includes a port to be updated; an updating unit (not shown in the figure) configured to update the device mounted on the port to be updated; and a searching and updating unit (not shown in the figure) configured to search the device mounted on the port to be updated through the IP and update the information of the device mounted on the port to be updated through the IP onto the port to be updated.

In some optional implementations of this embodiment, the IP mount apparatus 900 further includes: a third receiving unit (not shown in the figure) configured to receive a port release request, wherein the port release request includes a port to be released; an unbinding unit (not shown in the figure) configured to unbind the device mounted on the port to be released; and a search and lead-back unit (not shown in the figure) configured to search the device mounted on the port to be released through the IP and lead back the traffic data of the device mounted on the port to be released through the IP to the virtual routing device.

With further reference to fig. 10, as an implementation of the method shown in the above figures, the present application provides an embodiment of a data processing apparatus, which corresponds to the embodiment of the method shown in fig. 4, and which can be applied in various electronic devices.

As shown in fig. 10, the data processing apparatus 1000 of the present embodiment may include: receiving section 1001, allocating section 1002, and transmitting section 1003. The receiving unit 1001 is configured to receive a data processing request, where the data processing request includes to-be-processed traffic data; an allocation unit 1002 configured to process an internet protocol, IP, based on load balancing allocation; and a sending unit 1003 configured to send the traffic data to be processed to the device mounted by the processing IP for processing.

In the present embodiment, in the data processing apparatus 1000: the detailed processing of the receiving unit 1001, the allocating unit 1002 and the sending unit 1003 and the technical effects thereof can refer to the related descriptions of

steps

401 and 403 in the corresponding embodiment of fig. 4, which are not repeated herein.

In some optional implementations of this embodiment, the sending unit 1003 is further configured to: and if the processing IP exists in the VPC of the virtual private cloud where the load balancing equipment is located, sending the traffic data to be processed to the equipment mounted by the processing IP in the VPC for processing.

In some optional implementations of this embodiment, the sending unit 1003 is further configured to: if the processing IP exists in the VPC in the same region of the VPC, sending the flow data to be processed to virtual routing equipment in the VPC; and searching the routing information corresponding to the IP to be processed in the virtual routing equipment, and sending the traffic data to be processed to the equipment which is mounted by the IP to be processed in the same region VPC corresponding to the routing information for processing.

In some optional implementations of this embodiment, the sending unit 1003 is further configured to: if a processing IP exists in the cross-regional VPC of the VPC, sending flow data to be processed to virtual routing equipment in the VPC; and sending the traffic to be processed to the cross-regional virtual routing equipment in the cross-regional VPC through the virtual routing equipment in the VPC, so that the cross-regional virtual routing equipment sends the traffic data to be processed to equipment mounted by a processing IP in the cross-regional VPC for processing.

In some optional implementations of this embodiment, the sending unit 1003 is further configured to: if the processing IP exists in the opposite end mixed cloud of the VPC, sending the flow data to be processed to virtual routing equipment in the VPC; and sending the traffic to be processed to the hybrid virtual routing equipment in the opposite-end hybrid cloud through the virtual routing equipment in the VPC, so that the hybrid virtual routing equipment sends the traffic data to be processed to the equipment mounted by the processing IP in the opposite-end hybrid cloud for processing.

In some optional implementations of this embodiment, the data processing apparatus 1000 further includes: a checking unit (not shown in the figure) configured to perform a health check on a return process of a processing result of the traffic data to be processed; a first determination unit (not shown in the figure) configured to determine that the health check is normal if the return process is a pass; a second determination unit (not shown in the figures) configured to determine that the health check is abnormal if the return process is not a path.

In some optional implementations of this embodiment, the device mounted by IP includes at least one of: the server, the elastic network card of the server, the same IP port of the server, the service network card of the server and the container of the virtual machine.

Referring now to FIG. 11, shown is a block diagram of a computer system 1100 suitable for use in implementing the electronic device of an embodiment of the present application. The electronic device shown in fig. 11 is only an example, and should not bring any limitation to the functions and the use range of the embodiment of the present application.

As shown in fig. 11, the computer system 1100 includes a Central Processing Unit (CPU)1101, which can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)1102 or a program loaded from a storage section 1108 into a Random Access Memory (RAM) 1103. In the RAM 1103, various programs and data necessary for the operation of the system 1100 are also stored. The CPU 1101, ROM 1102, and RAM 1103 are connected to each other by a bus 1104. An input/output (I/O) interface 1105 is also connected to bus 1104.

The following components are connected to the I/O interface 1105: an input portion 1106 including a keyboard, mouse, and the like; an output portion 1107 including a signal output unit such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 1108 including a hard disk and the like; and a communication section 1109 including a network interface card such as a LAN card, a modem, or the like. The communication section 1109 performs communication processing via a network such as the internet. A driver 1110 is also connected to the I/O interface 1105 as necessary. A removable medium 1111 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1110 as necessary, so that a computer program read out therefrom is mounted into the storage section 1108 as necessary.

In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication portion 1109 and/or installed from the removable medium 1111. The above-described functions defined in the method of the present application are performed when the computer program is executed by a Central Processing Unit (CPU) 1101.

It should be noted that the computer readable medium described herein can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or electronic device. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by software or hardware. The described units may also be provided in a processor, and may be described as: a processor includes a first receiving unit, a first obtaining unit, a second obtaining unit, and a downloading unit. Where the names of the units do not constitute a limitation of the unit itself in this case, for example, the first receiving unit may also be described as "the unit receiving an internet protocol, IP, mount request". As another example, it can be described as: a processor includes a receiving unit, an assigning unit, and a transmitting unit. Where the names of these units do not constitute a limitation of the unit itself in this case, for example, a receiving unit may also be described as a "unit receiving a data processing request".

As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: receiving an Internet Protocol (IP) mounting request, wherein the IP mounting request comprises IP information to be mounted; if a port indicated by the IP information to be mounted exists in a Virtual Private Cloud (VPC) where the load balancing equipment is located, acquiring the superposed layer configuration of the port indicated by the IP information to be mounted, wherein the port in the VPC is mounted with the equipment; if the port exists, acquiring the superposed layer configuration of the port indicated by the IP information to be mounted; if the port indicated by the IP information to be mounted does not exist in the VPC, acquiring the configuration of an overlay layer of virtual routing equipment in the VPC; and downloading the acquired superposition layer configuration to load equipment of the load balancing equipment. Or cause the electronic device to: receiving a data processing request, wherein the data processing request comprises to-be-processed flow data; processing the IP based on load balancing distribution; and sending the traffic data to be processed to the equipment mounted by the processing IP for processing.

The above description is only a preferred embodiment of the application and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention herein disclosed is not limited to the particular combination of features described above, but also encompasses other arrangements formed by any combination of the above features or their equivalents without departing from the spirit of the invention. For example, the above features may be replaced with (but not limited to) features having similar functions disclosed in the present application.

Claims

1. An IP mounting method comprises the following steps:

receiving an Internet Protocol (IP) mounting request, wherein the IP mounting request comprises IP information to be mounted, and the IP information to be mounted comprises an IP abstracted by equipment mounted by load balancing equipment;

if a port indicated by the IP information to be mounted exists in a Virtual Private Cloud (VPC) where load balancing equipment is located, acquiring an overlay layer configuration of the port indicated by the IP information to be mounted, wherein the port in the VPC is mounted with the equipment;

if the port indicated by the IP information to be mounted does not exist in the VPC, acquiring the configuration of an overlay layer of virtual routing equipment in the VPC;

and downloading the acquired superposition layer configuration to the load equipment of the load balancing equipment.

2. The method of claim 1, wherein the downloading the obtained overlay configuration into a load device of the load balancing device comprises:

downloading the obtained superposed layer configuration to four layers of load equipment of the load balancing equipment;

determining whether it is seven-layer load balancing;

and if so, synchronizing the acquired superposed layer configuration from the four-layer load equipment to seven-layer load equipment of the load balancing equipment.

3. The method of claim 1, wherein the method further comprises:

receiving a port updating request, wherein the port updating request comprises a port to be updated;

updating the equipment mounted on the port to be updated;

searching the equipment mounted on the port to be updated through the IP, and updating the information of the equipment mounted on the port to be updated through the IP to the port to be updated.

4. The method of claim 1, wherein the method further comprises:

receiving a port release request, wherein the port release request comprises a port to be released;

unbinding the device mounted on the port to be released;

searching the equipment mounted on the port to be released through the IP, and guiding the traffic data of the equipment mounted on the port to be released through the IP back to the virtual routing equipment.

5. An IP mount device comprising:

a first receiving unit, configured to receive an Internet Protocol (IP) mount request, where the IP mount request includes IP information to be mounted, where the IP information to be mounted includes an IP abstracted from a device mounted by a load balancing device;

the first obtaining unit is configured to obtain an overlay layer configuration of a port indicated by the to-be-mounted IP information if the port indicated by the to-be-mounted IP information exists in a Virtual Private Cloud (VPC) where the load balancing equipment is located, wherein the port in the VPC is mounted with the equipment;

a second obtaining unit, configured to obtain an overlay layer configuration of a virtual routing device in the VPC if the port indicated by the to-be-mounted IP information does not exist in the VPC;

a downloading unit configured to download the acquired overlay configuration into a load device of the load balancing device.

6. The apparatus of claim 5, wherein the download unit comprises:

a download subcell configured to download the obtained overlay layer configuration into a four-layer load device of the load balancing device;

a determining subunit configured to determine whether it is seven-layer load balancing;

a synchronization subunit configured to synchronize the obtained overlay configuration from the four-layer load device into a seven-layer load device of the load balancing device if yes.

7. The apparatus of claim 5, wherein the apparatus further comprises:

a second receiving unit configured to receive a port update request, wherein the port update request includes a port to be updated;

an updating unit configured to update the device mounted on the port to be updated;

the searching and updating unit is configured to search the equipment mounted on the port to be updated through the IP and update the information of the equipment mounted on the port to be updated through the IP onto the port to be updated.

8. The apparatus of claim 5, wherein the apparatus further comprises:

a third receiving unit configured to receive a port release request, wherein the port release request includes a port to be released;

an unbinding unit configured to unbind the device mounted on the port to be released;

the finding and leading-back unit is configured to find the equipment mounted on the port to be released through the IP and lead back the traffic data of the equipment mounted on the port to be released through the IP to the virtual routing equipment.

9. An electronic device, comprising:

one or more processors;

a storage device having one or more programs stored thereon,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-4.

10. A computer-readable medium, on which a computer program is stored, wherein the computer program, when being executed by a processor, carries out the method according to any one of claims 1-4.