A bandwidth throttling method, apparatus, device, medium and product

Abstract

This invention relates to the field of network traffic rate limiting technology, and in particular to a bandwidth rate limiting method, apparatus, device, medium, and product. The method includes: after receiving an access request carrying a first floating Internet Protocol (IP) address, determining whether the first floating IP address matches any physical flow table; the output action in the physical flow table corresponds to a kernel rate limiter, and the kernel rate limiter corresponds to multiple floating IP addresses sharing the rate limit; if a match is found, determining whether the traffic of the first floating IP address exceeds the rate-limited traffic corresponding to a target kernel rate limiter, where the target kernel rate limiter is the kernel rate limiter corresponding to the output action of the matched physical flow table; if not, access is performed based on the first floating IP address. In this invention, the kernel rate limiter corresponds to multiple floating IP addresses sharing the rate limit, ensuring that multiple floating IPs share the bandwidth rate limit, improving network resource utilization and reducing costs.

Description

Technical Field

[0001] This invention relates to the field of network traffic rate limiting technology, and in particular to a bandwidth rate limiting method, apparatus, device, medium, and product. Background Technology

[0002] OpenStack is an open-source cloud computing platform widely used in data centers and cloud service providers. However, the current OpenStack architecture has some limitations, especially in network resource management. One major issue is bandwidth limiting for floating Internet Protocol (IP) addresses. Floating IP addresses are IP addresses that can be dynamically allocated to virtual machines or containers to provide external access. However, the current OpenStack architecture only supports bandwidth limiting for individual floating IP addresses, which leads to problems. For example, some floating IP addresses have unused bandwidth, while others have insufficient bandwidth, resulting in resource waste and performance bottlenecks. In this situation, a new method is needed to implement shared bandwidth limiting for floating IP addresses to improve network resource utilization and reduce costs.

[0003] Current solutions primarily rely on manually configuring and managing bandwidth limiting for floating Internet Protocol (IP) addresses, which is both time-consuming and error-prone. Therefore, an automated approach is needed to improve network resource utilization. Summary of the Invention

[0004] The purpose of this invention is to provide a bandwidth limiting method, apparatus, device, medium, and product that can improve the utilization rate of network resources.

[0005] Firstly, a bandwidth limiting method is provided, comprising: after obtaining an access request carrying a first floating Internet Protocol (IP) address, determining whether the first floating IP address hits any physical flow table; wherein, the output action in the physical flow table corresponds to a kernel rate limiter, and the kernel rate limiter corresponds to multiple floating IP addresses sharing the rate limit; if the first floating IP address hits any physical flow table, determining whether the traffic of the first floating IP address exceeds the rate-limited traffic corresponding to a target kernel rate limiter, wherein the target kernel rate limiter is the kernel rate limiter corresponding to the output action of the hit physical flow table; if the traffic does not exceed the rate-limited traffic corresponding to the target kernel rate limiter, then access is performed based on the first floating IP address.

[0006] In a preferred embodiment, the present invention can be further configured as follows: if the access request is a first access request to access a first floating Internet Protocol address from outside the cloud; accordingly, determining whether the first floating Internet Protocol address hits any physical flow table includes: determining whether the first floating Internet Protocol address hits the destination Internet Protocol address of any physical flow table; accordingly, accessing based on the first floating Internet Protocol address includes: converting the first floating Internet Protocol address into a corresponding virtual machine Internet Protocol address, and accessing based on the corresponding virtual machine Internet Protocol address.

[0007] In a preferred embodiment, the present invention can be further configured as follows: if the access request is a second access request from a virtual machine to access an external cloud, the first floating Internet Protocol address is the address obtained by converting the internal Internet Protocol address of the virtual machine; correspondingly, determining whether the first floating Internet Protocol address hits any physical flow table includes: determining whether the first floating Internet Protocol address hits the source Internet Protocol address of any physical flow table.

[0008] In a preferred embodiment, the present invention may be further configured to include: if the access request exceeds the rate-limited traffic corresponding to the target kernel rate limiter, then discard the access request; and / or, if the first floating Internet Protocol address does not hit any physical flow table, then access is performed based on the first floating Internet Protocol address.

[0009] In a preferred embodiment, the present invention can be further configured such that the kernel rate limiter limits the rate by periodically issuing token buckets.

[0010] In a preferred embodiment, the present invention may further be configured to include: obtaining configuration information for configuring a floating Internet Protocol (IP) address group, the configuration information including at least: a floating IP address list and a Quality of Service (QoS) rate limiting policy identifier; translating the floating IP address list to an address set table in the northbound database of the Open Virtual Network (AVN); and creating a QoS rate limiting policy table based on the rate limiting information corresponding to the QoS rate limiting policy identifier, wherein the inbound QoS rate limiting policy matching condition of the QoS rate limiting policy table is set to the destination IP address being equal to the floating IP address list and the outbound QoS rate limiting condition being equal to the outbound QoS rate limiting policy. The policy matching condition is set to the source Internet Protocol address equal to the floating Internet Protocol address list; the Open Virtual Network (AVN) Northbound process is invoked, and if changed data is detected in the address set table and QoS rate limiting policy table of the Northbound database in the AVN Northbound database, the changed data is written to the logical flow table of the Southbound data; based on the logical data of the logical flow table of the Southbound data, a kernel rate limiter is created, which is used to limit the rate according to the QoS rate limiting policy corresponding to the logical data; a physical flow table is created, and each floating Internet Protocol address in the shared rate-limiting floating Internet Protocol address list is associated with the kernel rate limiter.

[0011] In a preferred embodiment, the present invention can be further configured such that the quality of service rate limiting policy includes at least one of the following: inbound bandwidth, outbound bandwidth, inbound burst bandwidth, and outbound burst bandwidth.

[0012] In a preferred embodiment, the present invention can be further configured to: create a kernel rate limiter based on the logical data of the logical flow table of the southbound data, including: calling the Open Virtual Network Control process, and if the logical flow table of the southbound database is found to have changed logical data, creating a kernel rate limiter based on the logical data.

[0013] In a preferred embodiment, the present invention may be further configured to include: populating the floating Internet Protocol address group table and the associated address table of the network service component database according to the floating Internet Protocol address list and the quality of service rate limiting policy identifier; wherein, the floating Internet Protocol address group table is used to record basic information of the floating Internet Protocol address group table, and the associated address table is used to record the association relationship between the floating Internet Protocol address group and the floating Internet Protocol address list.

[0014] In a preferred embodiment, the present invention may be further configured as follows: before filling the floating Internet Protocol address group table and associated address table in the network service component database according to the floating Internet Protocol address list and the quality of service rate limiting policy identifier, the invention further includes: determining whether a floating Internet Protocol address group table exists in the network service component database; if a floating Internet Protocol address group table does not exist in the network service component database, then creating the floating Internet Protocol address group table.

[0015] In a preferred embodiment, the present invention may be further configured as follows: after obtaining the configuration information of the configuration Internet Protocol address set, the invention further includes: verifying the configuration information; if the verification passes, then performing the step of translating the address set table of the northbound database of the Open Virtual Network according to the floating Internet Protocol address list.

[0016] In a preferred embodiment, the present invention can be further configured as follows: the configuration information further includes: a project identifier; the configuration information is verified, including at least one of the following: determining whether the parameter lengths of the floating Internet Protocol address list, the Quality of Service (QoS) rate limiting policy identifier, and the project identifier are each preset parameter lengths; determining whether each floating Internet Protocol address in the floating Internet Protocol address list is a compliant Internet Protocol address; determining whether the rate limiting policy corresponding to the QoS rate limiting policy identifier exists; and determining whether each floating Internet Protocol address in the floating Internet Protocol address list is a floating Internet Protocol address in the project corresponding to the project identifier.

[0017] In a preferred embodiment, the present invention can be further configured to: determine whether each floating Internet Protocol address in the floating Internet Protocol address list is a floating Internet Protocol address in the project corresponding to the project identifier, including: obtaining the correspondence between projects and floating Internet Protocol addresses; and determining, based on the correspondence, whether each floating Internet Protocol address in the floating Internet Protocol address list is a floating Internet Protocol address in the project corresponding to the project identifier.

[0018] In a preferred embodiment, the present invention may further be configured to include: obtaining a first request from a user to add / remove floating Internet Protocol addresses from a floating Internet Protocol address group; and modifying the address set table, quality of service rate limiting policy table, logical flow table, and physical flow table of the northbound database according to the first request.

[0019] In a preferred embodiment, the present invention may be further configured to include: obtaining a second request from a user to delete a floating Internet Protocol address group, the second request including an identifier of the floating Internet Protocol address group; deleting the address set table, QoS rate limiting policy table, logical flow table, and physical flow table of the northbound database corresponding to the identifier of the floating Internet Protocol address group.

[0020] In a preferred embodiment, the present invention may be further configured to include: if there are other access requests corresponding to the same kernel rate limiter, determining the priority of the first floating Internet Protocol address and the floating Internet Protocol addresses corresponding to the other access requests; and determining the access processing order according to the priority.

[0021] Secondly, a bandwidth limiting device is provided, comprising: a hit determination module, configured to determine whether the first floating Internet Protocol address hits any physical flow table after obtaining an access request carrying a first floating Internet Protocol address; wherein the output action in the physical flow table corresponds to a kernel rate limiter, and the kernel rate limiter corresponds to multiple floating Internet Protocol addresses sharing the rate limit; a rate limiting determination module, configured to determine whether the traffic of the first floating Internet Protocol address exceeds the rate limit traffic corresponding to a target kernel rate limiter if the first floating Internet Protocol address hits any physical flow table, wherein the target kernel rate limiter is the kernel rate limiter corresponding to the output action of the hit physical flow table; and an access module, configured to access the device based on the first floating Internet Protocol address if the traffic does not exceed the rate limit traffic corresponding to the target kernel rate limiter.

[0022] Thirdly, an electronic device is provided, comprising a memory for storing a computer program and a processor for executing the computer program to implement the bandwidth limiting method as described in any of the first aspects.

[0023] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the bandwidth limiting method as described in any of the first aspects.

[0024] Fifthly, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the bandwidth limiting method as described in any of the first aspects.

[0025] In summary, the bandwidth limiting method provided by this invention has the following beneficial technical effects: After obtaining an access request carrying a first floating Internet Protocol (IP) address, it is determined whether the first floating IP address hits any physical flow table; wherein, the output action in the physical flow table corresponds to a kernel rate limiter, and the kernel rate limiter corresponds to multiple floating IP addresses sharing the rate limit; if the first floating IP address hits any physical flow table, it is determined whether the traffic of the first floating IP address exceeds the rate limit traffic corresponding to the target kernel rate limiter, wherein the target kernel rate limiter is the kernel rate limiter corresponding to the output action of the hit physical flow table; if it does not exceed the rate limit traffic corresponding to the target kernel rate limiter, access is performed based on the first floating IP address. In this invention, the kernel rate limiter corresponds to multiple floating IP addresses sharing the rate limit. Through the kernel rate limiter mechanism, shared bandwidth limiting among multiple floating IPs is achieved, which not only improves the utilization rate of network resources but also simplifies network management and configuration, and improves the quality of network services in a cloud computing environment.

[0026] In addition, the present invention also provides a bandwidth limiting device, equipment, medium and product, all of which have the above-mentioned beneficial technical effects. Attached Figure Description

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

[0028] Figure 1 This is a schematic diagram illustrating an application scenario of a bandwidth limiting method provided in an embodiment of the present invention.

[0029] Figure 2 This is a schematic diagram illustrating the configuration of a pre-set shared bandwidth floating IP provided by an embodiment of the present invention.

[0030] Figure 3 This is a schematic diagram illustrating another pre-configured floating IP with shared bandwidth provided by an embodiment of the present invention.

[0031] Figure 4 This is a schematic diagram of a data forwarding process provided by an embodiment of the present invention.

[0032] Figure 5 This is a schematic diagram of a bandwidth limiting device provided in an embodiment of the present invention.

[0033] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0035] The terms "comprising" and "having," and any variations thereof, in the specification and accompanying drawings of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.

[0036] To facilitate understanding, some technical terms are explained here.

[0037] Neutron: OpenStack Neutron is the network component of OpenStack, providing software-defined networking (SDN) services. It supports the creation and management of virtual networks, subnets, routers, load balancers, and firewalls, and integrates various network technologies (VLAN / VXLAN / LBaaS, etc.) to achieve flexible network architecture in cloud environments.

[0038] OVN (Open Virtual Network): An enhancement component of OpenStack Neutron, based on OpenvSwitch (OVS), provides distributed virtual network functionality, including logical switches, routers, ACLs and security groups, supports multi-tenant isolation and cross-host communication, and simplifies cloud network management.

[0039] OVS (Open vSwitch) is an open-source virtual switch that supports SDN and network virtualization. It provides cross-physical / virtual machine traffic forwarding, VLAN / VXLAN tunneling, traffic monitoring (sFlow / NetFlow), and OpenFlow protocol integration, and is suitable for cloud platforms and virtualization environments.

[0040] Floating IP: In OpenStack, a public IP address that can be dynamically bound to expose instances (such as virtual machines) to the external network. It supports flexible unbinding / rebinding to achieve high availability and elastic access.

[0041] NAT (Network Address Translation) is a technology that maps private IP addresses to public IP addresses to address the IPv4 address shortage problem. It mainly includes: SNAT (Source NAT): Internal network devices access the external network through a shared public IP address (e.g., a home router). DNAT (Destination NAT): Forwards requests from public IP addresses to specific internal network devices (e.g., port forwarding). NAT hides the internal network structure, improving security, but may affect end-to-end connectivity and requires the use of an ALG (Application Gateway) to support specific protocols (e.g., FTP).

[0042] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0043] OpenStack's Neutron component is responsible for network resource management, including the management of floating IPs (Floating Internet Protocol addresses). Currently, it's commonly used in conjunction with the OVN (Open Virtual Network) network architecture. However, the OVN architecture currently only supports bandwidth limiting for individual floating IPs, which restricts its application in large-scale cloud environments. Therefore, a new method is needed to extend the functionality of the OVN network architecture to achieve shared bandwidth limiting for floating IPs.

[0044] The inventors of this invention have discovered that shared bandwidth limiting for floating IPs can be achieved by adding multiple floating IPs to a single IP address set. Each IP address set can be considered a unified resource, and then rate limiting can be applied to this set. This method ensures that multiple floating IPs share bandwidth limiting, improving network resource utilization and reducing costs.

[0045] However, implementing shared bandwidth rate limiting for floating IPs also presents some technical challenges. For example, a new algorithm needs to be developed to dynamically adjust the bandwidth rate limit for floating IPs, ensuring efficient utilization of network resources. Simultaneously, the compatibility and scalability of this method need to be ensured to adapt to different cloud environments and network topologies.

[0046] In summary, implementing shared bandwidth rate limiting for floating IPs is a challenging task that requires a comprehensive solution to address current technical limitations and challenges.

[0047] The following sections will describe in detail a bandwidth limiting method, apparatus, device, medium, and product provided by embodiments of the present invention. Figure 1 A bandwidth limiting method is provided in this embodiment of the invention. The bandwidth limiting method includes: S101, after obtaining an access request carrying a first floating Internet Protocol address, determining whether the first floating Internet Protocol address hits any physical flow table; wherein, the output action in the physical flow table corresponds to the kernel rate limiter, and the kernel rate limiter corresponds to multiple floating Internet Protocol addresses that share the rate limit.

[0048] The first floating Internet Protocol address is the floating IP address corresponding to the virtual machine. Its nature varies depending on the type of access request. For example, if the access request is for accessing the virtual machine from outside the cloud, then the first floating Internet Protocol address is the destination IP address; if the access request is for the virtual machine to access outside the cloud, then the first floating Internet Protocol address is the source IP address.

[0049] The physical flow table is a pre-created table that stores the corresponding source IP address, destination IP address, and output action. Floating Internet Protocol addresses are pre-defined as IP addresses in this table.

[0050] For example, a typical flow table entry output format is as follows: cookie=0x0,duration=123.456s,table=0,n_packets=100,n_bytes=20000,idle_age=5,priority=100,in_port="eth0",nw_src (source IP address)=fa:16:3e:ab:cd:ef,nw_dst (destination IP address)=fa:16:3e:12:34:56,actions (output actions)=output:"eth1".

[0051] In this embodiment of the invention, a floating Internet Protocol address group (floating Internet Protocol address list) is pre-configured to share a rate limiting policy. Correspondingly, the output action of the physical flow table of each floating Internet Protocol address corresponds to the same kernel rate limiter (meter), thus realizing that the floating IP addresses with shared rate limiting all point to the same meter.

[0052] In one possible implementation of this invention, the kernel rate limiter limits the rate by periodically issuing token buckets.

[0053] In one feasible approach, once the access traffic reaches OVS, the first floating Internet Protocol address is compared one by one with each physical flow table pre-configured in the device. If the first floating Internet Protocol address corresponding to the request exists in the physical flow table, it is considered that the address has matched the physical flow table. The output action in the physical flow table corresponds to the kernel rate limiter, and each kernel rate limiter corresponds to multiple floating Internet Protocol addresses with shared rate limits. Therefore, once matched, the first floating Internet Protocol address needs to be limited by the corresponding kernel rate limiter.

[0054] S102. If the first floating Internet Protocol address hits any physical flow table, determine whether the traffic of the first floating Internet Protocol address exceeds the rate limit traffic corresponding to the target kernel rate limiter, where the target kernel rate limiter is the kernel rate limiter corresponding to the output action of the hit physical flow table.

[0055] The target kernel rate limiter is used to limit the rate according to the corresponding Quality of Service (QoS) rate limiting policy, which is a rate limiting policy resource shared by multiple floating Internet Protocol (IP) addresses corresponding to the target kernel rate limiter.

[0056] Obtain the traffic volume of the first floating Internet Protocol address and compare it with the traffic volume of the target kernel rate limiter. If it exceeds the traffic volume limit, stop access, discard the corresponding data packets, and stop forwarding. If it does not exceed the corresponding traffic volume limit, execute S103.

[0057] S103. If the traffic limit corresponding to the target kernel rate limiter is not exceeded, access is made based on the first floating Internet Protocol address.

[0058] In this step, if the virtual machine is accessed from outside the cloud, the data packet is directly forwarded to the virtual machine based on the first floating Internet Protocol address. If the virtual machine accesses the outside cloud, the data packet is sent out by OVS based on the first floating Internet Protocol address and forwarded to the outside cloud by the physical network card.

[0059] One possible implementation of this invention further includes: if the traffic exceeds the rate limit corresponding to the target kernel rate limiter, then discard the access request; and / or, if the first floating Internet Protocol address does not match any physical flow table, then access is performed based on the first floating Internet Protocol address.

[0060] As can be seen, in this embodiment of the invention, after obtaining an access request carrying a first floating Internet Protocol (IP) address, it is determined whether the first floating IP address hits any physical flow table. The output action in the physical flow table corresponds to a kernel rate limiter, and the kernel rate limiter corresponds to multiple floating IP addresses sharing a rate limit. If the first floating IP address hits any physical flow table, it is determined whether the traffic of the first floating IP address exceeds the rate-limited traffic corresponding to the target kernel rate limiter, where the target kernel rate limiter is the kernel rate limiter corresponding to the output action of the hit physical flow table. If the traffic does not exceed the rate-limited traffic corresponding to the target kernel rate limiter, access is performed based on the first floating IP address. In this invention, the kernel rate limiter corresponds to multiple floating IP addresses sharing a rate limit. Through the kernel rate limiter mechanism, shared bandwidth rate limiting among multiple floating IPs is achieved, which not only improves the utilization rate of network resources but also simplifies network management and configuration, and improves the quality of network services in a cloud computing environment.

[0061] Understandably, in typical network models, the networks of virtual machines within the cloud and the networks outside the cloud are isolated and cannot be accessed directly via IP forwarding. For services that need to communicate with the outside cloud, the common approach is to use NAT (Network Address Translation) to translate IP addresses, exposing only the floating IP address to the outside world. Both external access to the virtual machine and virtual machine access to the external network use the floating IP address. There is a one-to-one correspondence between the virtual machine's IP address and the floating IP address. When multiple floating IP addresses need to share rate limiting, they are grouped together.

[0062] In one possible implementation of this invention, if the access request is a first access request to access a first floating Internet Protocol address from outside the cloud; accordingly, determining whether the first floating Internet Protocol address hits any physical flow table includes: determining whether the first floating Internet Protocol address hits the destination Internet Protocol address of any physical flow table; accordingly, accessing based on the first floating Internet Protocol address includes: converting the first floating Internet Protocol address into a corresponding virtual machine Internet Protocol address, and accessing based on the corresponding virtual machine Internet Protocol address.

[0063] For traffic accessing the first floating IP address from outside the cloud, when the traffic (i.e., the first access request) arrives at OVS, it verifies whether the destination floating IP (first floating IP address) belongs to the configured address group. At this point, it determines whether the first floating IP address matches the destination IP address in any physical flow table. If no match is found, DNAT is directly performed to translate the first floating IP address into an internal virtual machine IP. If a match is found, rate limiting is first applied; this is inbound rate limiting. If a match is found but the limit is exceeded, the current traffic is dropped and no further forwarding is performed. If a match is found and the traffic does not exceed the limit, DNAT is performed to translate the floating IP into an internal virtual machine IP, and subsequent forwarding continues into the virtual machine.

[0064] As can be seen, in this embodiment of the invention, for virtual machines accessed from outside the cloud, after determining that the first floating Internet Protocol address hits the destination Internet Protocol address of any physical flow table, inbound rate limiting can be performed.

[0065] In one possible implementation of this invention, if the access request is a second access request from a virtual machine to access an external cloud, the first floating Internet Protocol address is the address obtained by converting the virtual machine's internal Internet Protocol address; correspondingly, determining whether the first floating Internet Protocol address hits any physical flow table includes: determining whether the first floating Internet Protocol address hits the source Internet Protocol address of any physical flow table.

[0066] Understandably, when the virtual machine sends a response packet back to the cloud, the source IP of the packet is the internal IP. When accessing the cloud, SNAT is needed to convert the source IP of the virtual machine into a floating IP. If the match fails, the packet is directly sent out to the cloud via the OVS (On-Vehicle System) and forwarded by the physical network interface card. If the match succeeds, rate limiting is applied first; this is outbound rate limiting. If the limit is exceeded, the current traffic is discarded and no longer forwarded. If the traffic does not exceed the limit, it is sent out to the cloud via the OVS and forwarded by the physical network interface card.

[0067] As can be seen, in this embodiment of the invention, for virtual machines accessing outside the cloud, after determining that the first floating Internet Protocol address hits the source Internet Protocol address of any physical flow table, outbound rate limiting can be performed.

[0068] It is important to note that this invention proposes a method for shared bandwidth limiting of floating IPs based on an OVN architecture. This method adds multiple floating IPs to a single IP address set, treating them as a unified resource. By binding them to an OVS meter, they share the token bucket of a single meter, thus achieving shared rate limiting. The basic idea is as follows: Create an IP address set to store multiple floating IPs. Map this address set to the OVN network architecture. The OVN controller maps the IP addresses in the address set to the source / destination IPs in the OVS physical flow table, using this as a matching condition. Create OVS meter rate limiting rules to determine that IP addresses requiring shared rate limiting use the same meter's token bucket, thereby achieving shared rate limiting.

[0069] Specifically, one possible implementation of this invention is described in [reference needed]. Figure 2 , Figure 2 This invention provides a process for setting up a floating IP with pre-configured shared bandwidth, including: S201, obtaining configuration information for configuring a floating Internet Protocol address group, wherein the configuration information includes at least: a list of floating Internet Protocol addresses and a quality of service rate limiting policy identifier.

[0070] In this embodiment of the invention, the configuration information is obtained before setting the floating IP for shared bandwidth.

[0071] Understandably, policy resources are created in advance. Users can select them when creating floating IP address groups, or bind or change them after creation via updates. During configuration, project IDs can be pre-configured, allowing other configuration information to be added later. Generally, cloud resource allocation uses project separation for easier management; projects are isolated by default. For example, project A and project B are created before network resources are created. When users create network, virtual machine, floating IP, and other resources for project A, they will pass in project A's ID.

[0072] The floating Internet Protocol address list includes at least two floating Internet Protocol addresses that can share a rate limiting policy. The service quality rate limiting policy identifier and QoS ID are also pre-set, and different QoS IDs correspond to different rate limiting policies.

[0073] Specifically, users can send configuration information via command line, web page, or other means. Here, configuration commands and API interfaces need to be provided to users. At least the created API interface should be added, including the following fields: floating IP address group name, floating IP address group description, service quality rate limiting policy identifier, floating Internet Protocol address list, and project identifier.

[0074] In one possible implementation, after S201, the method further includes: populating the floating Internet Protocol address group table and the associated address table in the network service component database based on the floating Internet Protocol address list and the quality of service rate limiting policy identifier; wherein, the floating Internet Protocol address group table is used to record the basic information of the floating Internet Protocol address group table, and the associated address table is used to record the association relationship between the floating Internet Protocol address group and the floating Internet Protocol address list.

[0075] Specifically, the configuration information is written to the neutron database (network service component database) in two tables: floating_ip_groups (a list of floating Internet Protocol addresses, as shown in Table 1) and addresses_associations (a table of associated addresses, as shown in Table 2). The floating_ip_groups table is stored in the neutron database and is created in its own database when the neutron-server process starts. floating_ip_groups is used to record IP address set information, and addresses_associations is used to record the IP addresses associated with floating_ip_groups.

[0076] Table 1 List of Floating Internet Protocol Addresses

[0077]

[0078] Table 2. Related Address Table

[0079]

[0080] The rate limiting policy identifier uniquely corresponds to a rate limiting policy. It includes four attributes: inbound bandwidth, outbound bandwidth, inbound burst bandwidth, and outbound burst bandwidth. One or more of these attributes can be selected (but cannot be repeated) to form a rate limiting policy. Each floating IP address group can only be bound to one rate limiting policy.

[0081] As can be seen, in this embodiment of the invention, the configuration information is written into the floating Internet Protocol address group table and associated address table of the neutron database as a backup of the data, so as to improve the reliability of the system.

[0082] S202. Translate the address set table of the northbound database of the Open Virtual Network to the floating Internet Protocol address list.

[0083] The data storage format of the address set table in the northbound database may differ from that of the floating Internet Protocol address list. Therefore, a translation is performed to convert the format and write the data into the address set table (address_set table) of the Open Virtual Network (OVN) northbound database.

[0084] S203. Based on the rate limiting information corresponding to the service quality rate limiting policy identifier, create a service quality rate limiting policy table. The service quality rate limiting policy matching condition for the inbound direction of the service quality rate limiting policy table is set to the destination Internet Protocol address equal to the floating Internet Protocol address list, and the service quality rate limiting policy matching condition for the outbound direction is set to the source Internet Protocol address equal to the floating Internet Protocol address list.

[0085] Based on the rate limiting information corresponding to the service quality rate limiting policy identifier, a service quality rate limiting policy table (QoS data) is created. The inbound QoS matching condition is set to the destination IP equal to the set of floating IP addresses, and the outbound QoS matching condition is set to the source IP equal to the set of floating IP addresses. Here, the inbound direction refers to the direction of rate limiting, not the source IP; it applies to rate limiting of floating IPs. Outbound refers to a floating IP (source) accessing another IP. For example, an outbound rate limit of 10Mb / s means that the total bandwidth limit for all floating IPs in the floating IP address group accessing other IPs is 10Mb / s.

[0086] S204. Call the Open Virtual Network Northbound process. If it detects that there are changes in the address set table and service quality rate limiting policy table of the Northbound database in the Open Virtual Network Northbound database, write the changes to the logical flow table of the Southbound data.

[0087] The Open Virtual Network Northbound Process (OVN-north process) is a user-space process that monitors changes in the OVN Northbound database and translates the corresponding information into the Southbound database. It automatically listens to the `address_set` and `qos` tables in the OVN Northbound database and translates the corresponding logical information into a logical flow table, which is then written to the `logical_flow` table in the OVN Southbound database. The changed data (the changed logical information) includes, but is not limited to: floating Internet Protocol addresses, rate-limited directions, rate-limited bandwidth values, and network affiliation. This information is independent in the Northbound database but is linked together in the `logical_flow` table.

[0088] S205. Based on the logical data of the logical flow table of southbound data, create a kernel rate limiter. The kernel rate limiter is used to limit the rate according to the service quality rate limiting policy corresponding to the logical data.

[0089] S206. Create a physical flow table and map each floating Internet Protocol address in the shared rate-limited floating Internet Protocol address list to a kernel rate limiter.

[0090] One possible implementation of this invention is that the quality of service rate limiting strategy includes at least one of the following: inbound bandwidth, outbound bandwidth, inbound burst bandwidth, and outbound burst bandwidth.

[0091] One possible implementation of this invention involves invoking the Open Virtual Network Control (OVN) process. If changes to logical data are detected in the logical flow tables of the southbound database, a kernel rate limiter is created based on this logical data. Specifically, the OVN controller monitors updates to the southbound database. When it detects the creation of a rate-limiting policy in a logical flow table, it creates a meter (kernel rate limiter) in OVN. The kernel rate limiter applies rate limiting by periodically issuing token buckets. Then, a physical flow table is added, and all floating IP addresses sharing the rate limit are pointed to the same meter.

[0092] As can be seen, in this embodiment of the invention, multiple floating IPs are added to a set of IP addresses and treated as a unified resource. By binding them to an OVS kernel rate limiter, they share the token bucket of a single kernel rate limiter, thereby achieving the effect of shared rate limiting.

[0093] One possible implementation of this invention includes, before populating the floating Internet Protocol address group table and associated address table in the network service component database based on the floating Internet Protocol address list and the quality of service rate limiting policy identifier, determining whether a floating Internet Protocol address group table exists in the network service component database; and creating a floating Internet Protocol address group table if it does not exist in the network service component database.

[0094] One possible implementation of this invention, after obtaining the configuration information for the Internet Protocol address set, further includes: verifying the configuration information; if the verification passes, then performing the step of translating the address set table of the northbound database of the Open Virtual Network (AVN) according to the floating Internet Protocol address list. In this embodiment, after receiving the configuration information, the neutron_server (network component controller service) needs to verify the configuration information sent by the user, such as parameter length, IP validity, existence of the bound QoS resource, and whether it is a project.

[0095] In one possible implementation, the configuration information further includes: a project identifier; and the configuration information is validated, including at least one of the following: determining whether the parameter lengths of the floating Internet Protocol address list, the Quality of Service Rate Limiting Policy identifier, and the project identifier are each a preset parameter length; determining whether each floating Internet Protocol address in the floating Internet Protocol address list is a compliant Internet Protocol address; determining whether the rate limiting policy corresponding to the Quality of Service Rate Limiting Policy identifier exists; and determining whether each floating Internet Protocol address in the floating Internet Protocol address list is a floating Internet Protocol address in the project corresponding to the project identifier.

[0096] The floating Internet Protocol address validity check includes: whether the IP format is correct and whether the IP address is a registered floating IP. Only allocated floating IP resources can be added to the floating IP address group.

[0097] Determining whether a rate limiting policy corresponding to a service quality rate limiting policy identifier exists includes: QoS resources are user-configured rate limiting attributes used to record inbound and outbound rate limiting bandwidth and burst bandwidth values. Once created, they are assigned a unique ID. When a floating IP address group is bound to a QoS resource, the QoS ID is checked to see if it has already been created and exists.

[0098] Determine whether each floating Internet Protocol address in the floating Internet Protocol address list is a floating Internet Protocol address in the project corresponding to the project identifier: In normal scenarios, only resources belonging to the same project are visible. When a floating IP address group is created, it will be assigned a project, such as project A. When floating IP, QoS and other information are issued, it is necessary to verify that the floating IP and QoS belong to project A.

[0099] As can be seen, in this embodiment of the invention, by verifying the configuration information, the correctness and integrity of the configuration information are ensured, thereby ensuring the stability of the system.

[0100] One possible implementation of this invention involves determining whether each floating Internet Protocol address in the floating Internet Protocol address list is a floating Internet Protocol address in the project corresponding to the project identifier, including: obtaining the correspondence between projects and floating Internet Protocol addresses; and determining, based on the correspondence, whether each floating Internet Protocol address in the floating Internet Protocol address list is a floating Internet Protocol address in the project corresponding to the project identifier.

[0101] One possible implementation of this invention further includes: obtaining a first request from a user to add / remove floating Internet Protocol (IP) addresses from a floating IP address group; and modifying the address set table, QoS rate limiting policy table, logical flow table, and physical flow table of the northbound database according to the first request. Specifically, if adding, the required floating IP address is added to the address set table, QoS rate limiting policy table, logical flow table, and physical flow table of the northbound database, so that the newly added floating IP address can also share the rate limiting. If deleting, the required floating IP address is deleted from the address set table, QoS rate limiting policy table, logical flow table, and physical flow table of the northbound database.

[0102] One possible implementation of this invention further includes: obtaining a second request from a user to delete a floating Internet Protocol address group, the second request including an identifier of the floating Internet Protocol address group; and deleting the address set table, QoS rate limiting policy table, logical flow table, and physical flow table of the northbound database corresponding to the identifier of the floating Internet Protocol address group. Wherein, if it is necessary to delete a certain floating Internet Protocol address group, the corresponding tables can be deleted sequentially based on the identifier of the floating Internet Protocol address group.

[0103] One possible implementation of this invention further includes: obtaining a third request from the user to update the floating Internet Protocol address group, the third request including: the floating Internet Protocol address group name, description, and rate limiting policy identifier; and the address set table, quality of service rate limiting policy table, logical flow table, and physical flow table of the northbound database corresponding to the identifier of the floating Internet Protocol address group.

[0104] In one possible implementation of this invention, if there are other access requests corresponding to the same kernel rate limiter, a processing scheme is determined based on the actual situation.

[0105] In one possible implementation, the priorities of the first floating Internet Protocol address and the floating Internet Protocol addresses corresponding to other access requests are determined; the access processing order is then determined based on these priorities. For requests that have not yet started accessing, access can be granted based on the priority of each floating Internet Protocol address, ensuring the service quality of important services.

[0106] In another possible implementation, access is achieved based on the chronological order in which the first floating IP address is determined, as well as the floating IP addresses corresponding to other access requests. For example, the order could be floating IP address A, floating IP address B, and floating IP address C, with access processed sequentially using a token bucket approach.

[0107] Furthermore, in one possible implementation of this invention, configuration information for configuring floating Internet Protocol (IP) address groups is obtained. This configuration information includes at least a list of floating IP addresses and a Quality of Service (QoS) rate limiting policy identifier, and further includes: determining the QoS rate limiting policy corresponding to the QoS rate limiting policy identifier; obtaining the historical processing traffic of each floating IP address corresponding to the floating IP address list; using the average historical processing traffic of each floating IP address as the rate limiting value; using the maximum processing traffic among the historical processing traffic of each floating IP address as the mutation value; verifying the QoS rate limiting policy corresponding to the QoS rate limiting policy identifier based on the mutation value and the rate limiting value; if the difference is greater than either the mutation value difference threshold or the rate limiting value difference threshold, a prompt message is sent to allow the user to reconfirm.

[0108] Based on any of the above embodiments, this embodiment of the invention provides a specific bandwidth limiting process, including:

[0109] like Figure 2 As shown, Figure 2 This is a schematic diagram illustrating the configuration of a pre-set shared bandwidth floating IP according to an embodiment of the present invention, including:

[0110] 1. Users can send configuration information via command line, web page or other means. Here we need to provide users with configuration commands, API interfaces, etc., and mainly add the following API interfaces.

[0111] ① Add a floating IP address group to POST: / v2.0 / floating-ip-group

[0112] {

[0113] "name": "floating-ip-group1", Name of the floating IP address group

[0114] "description": "", Description of the floating IP address group

[0115] "qos_id": "" Rate limiting policy ID"

[0116] "ips": ["123.123.123.123","123.123.123.124","face::1234"], a list of IP addresses.

[0117] "project_id": ""Project ID

[0118] }

[0119] ② PUT: / v2.0 / floating-ip-group / {fip_g_id} / add-ip Adds an IP address to the floating IP address group.

[0120] {

[0121] "ips": ["123.123.123.123","123.123.123.124","face::1234"]

[0122] }

[0123] ③ PUT: / v2.0 / floating-ip-group / {fip_g_id} / del-ip Removes an IP address from the floating IP address group.

[0124] {

[0125] "ips": ["123.123.123.123","123.123.123.124","face::1234"]

[0126] }

[0127] ④ DELETE: / v2.0 / floating-ip-group / {fip_g_id} Delete the floating IP address group.

[0128] ⑤ PUT: / v2.0 / floating-ip-group / {fip_g_id} Update the floating IP address group

[0129] {

[0130] "name": "floating-ip-group1",

[0131] "description": "123123123123",

[0132] "qos_id": ""

[0133] }

[0134] 2. After receiving the configuration information, neutron_server needs to verify the configuration information sent by the user, such as parameter length, IP validity, existence of the bound QoS resource, and whether it is a project.

[0135] 3. After successful verification, the configuration information needs to be written to the `floating_ip_groups` and `address_associations` tables in the neutron database. The `floating_ip_groups` table is stored in the neutron database and is created in its own database when the neutron-server process starts. `floating_ip_groups` is used to record IP address set information.

[0136] 4. After successful verification, the data is written to the specified data table in the OVN northbound database via the OVSDB protocol. This mainly involves translating the IP address information of the floating IP address group into the `address_set` table, and creating a new QoS table. The inbound QoS matching condition is set to the destination IP equal to the floating IP address set, and the outbound QoS matching condition is set to the source IP equal to the floating IP address set.

[0137] 5. The OVN-north process is a user-space process used to monitor data changes in the OVN northbound database and translate the corresponding information into the southbound database. It automatically listens to the address_set and qos tables in the OVN northbound database and translates the corresponding logical information into a logical flow table, which is then written into the logical_flow table in the OVN southbound database.

[0138] 6. The OVN controller monitors updates to the southbound database. When it detects the creation of a logical flow table in the southbound database, it creates a meter in OVS and applies rate limiting by periodically issuing token buckets. Then, it adds a physical flow table, pointing all floating IP addresses sharing the rate limit to the same meter.

[0139] 7. Ensure that the flow tables of floating IPs entering and leaving nodes match the newly added physical flow table, and ultimately achieve the purpose of shared rate limiting by sharing tokens from a single token bucket.

[0140] like Figure 3 As shown, Figure 3 This is a schematic diagram of another pre-configured shared bandwidth floating IP provided by an embodiment of the present invention, including: 1. After traffic from outside the cloud accessing the floating IP arrives at OVS, before converting the destination floating IP into an internal IP address, a new flow table is added to verify whether the destination IP belongs to the configured address group.

[0141] 2. If no match is found, DNAT is performed to convert the floating IP to an internal IP of the virtual machine. If a match is found, rate limiting is performed first; this is inbound rate limiting.

[0142] 3. If a match is successful, or if the limit is exceeded, the current traffic will be discarded and will not be forwarded.

[0143] 4. If the match is successful and the traffic limit is not exceeded, DNAT is performed to convert the floating IP to an internal IP of the virtual machine, and subsequent forwarding to the virtual machine continues.

[0144] 5. The source IP of the virtual machine's return packet is the internal IP. When accessing external networks, SNAT needs to be performed to convert the virtual machine IP of the source IP into a floating IP.

[0145] 6. Add a flow table before sending out OVS to verify whether the source IP belongs to the configured address group.

[0146] 7. If the match fails, the OVS will be sent directly to the cloud via the physical network card. If the match succeeds, rate limiting will be applied first. This is outbound rate limiting.

[0147] 8. If the limit is exceeded, the current traffic will be discarded and will not be forwarded.

[0148] 9. If the traffic limit is not exceeded, the OVS will be forwarded from the physical network card to the outside of the cloud.

[0149] The core idea of ​​this invention is to implement shared bandwidth rate limiting among multiple floating IPs by utilizing OVS's meter mechanism and OpenStack's Neutron component. This not only improves network resource utilization but also simplifies network management and configuration, enhancing network service quality in a cloud computing environment. Furthermore, by dynamically adjusting the shared bandwidth rate limiting strategy, optimization can be performed based on actual network conditions and business needs, further improving system flexibility and reliability.

[0150] This invention addresses the limitation of the open-source OVN community, which only allows configuring rate limits for individual floating IPs and cannot dynamically share a rate limit pool among multiple floating IPs. It resolves the bandwidth waste and resource allocation issues that arise when individual floating IPs are configured with their own rate limits. The proposal and implementation of this invention are of significant importance and value for advancing cloud computing and network virtualization technologies.

[0151] The following describes a bandwidth limiting device provided by an embodiment of the present invention. The bandwidth limiting device described below can be referred to in correspondence with the bandwidth limiting method described above. The bandwidth limiting device of this embodiment is installed in an electronic device. Figure 5 , Figure 5This is a structural block diagram of an apparatus according to one embodiment of the present invention, comprising: a hit determination module 210, configured to determine whether the first floating Internet Protocol address hits any physical flow table after obtaining an access request carrying a first floating Internet Protocol address; wherein the output action in the physical flow table corresponds to a kernel rate limiter, and the kernel rate limiter corresponds to multiple floating Internet Protocol addresses sharing a rate limit; a rate limit determination module 220, configured to determine whether the traffic of the first floating Internet Protocol address exceeds the rate limit traffic corresponding to the target kernel rate limiter if the first floating Internet Protocol address hits any physical flow table, wherein the target kernel rate limiter is the kernel rate limiter corresponding to the output action of the hit physical flow table; and an access module 230, configured to access based on the first floating Internet Protocol address if the traffic does not exceed the rate limit traffic corresponding to the target kernel rate limiter.

[0152] In this embodiment of the invention, the hit determination module 210, after obtaining an access request carrying a first floating Internet Protocol address, determines whether the first floating Internet Protocol address hits any physical flow table; wherein, the output action in the physical flow table corresponds to a kernel rate limiter, and the kernel rate limiter corresponds to multiple floating Internet Protocol addresses sharing rate limits; the rate limiting determination module 220, if the first floating Internet Protocol address hits any physical flow table, determines whether the traffic of the first floating Internet Protocol address exceeds the rate-limited traffic corresponding to the target kernel rate limiter, wherein the target kernel rate limiter is the kernel rate limiter corresponding to the output action of the hit physical flow table; the access module 230, if the traffic does not exceed the rate-limited traffic corresponding to the target kernel rate limiter, performs access based on the first floating Internet Protocol address. In this invention, the kernel rate limiter corresponds to multiple floating Internet Protocol addresses sharing rate limits. Through the kernel rate limiter mechanism, shared bandwidth rate limiting among multiple floating IPs is achieved, which not only improves the utilization rate of network resources but also simplifies network management and configuration, and improves the quality of network services in a cloud computing environment.

[0153] In one feasible approach, if the access request is a first access request to access the first floating Internet Protocol address from outside the cloud; the rate limiting determination module 220 is used to: determine whether the first floating Internet Protocol address hits the destination Internet Protocol address of any physical flow table; the rate limiting determination module 220 is used to: convert the first floating Internet Protocol address into the corresponding virtual machine Internet Protocol address, and perform access based on the corresponding virtual machine Internet Protocol address.

[0154] In one possible implementation, if the access request is a second access request from a virtual machine to an external cloud, the first floating Internet Protocol address is the address obtained by converting the virtual machine's internal Internet Protocol address; the rate limiting determination module 220 is used to: determine whether the first floating Internet Protocol address hits the source Internet Protocol address of any physical flow table.

[0155] In one possible implementation, the system further includes: a discard module, configured to discard the access request if the traffic exceeds the rate limit corresponding to the target kernel rate limiter; and an access module 230, configured to access the system based on the first floating Internet Protocol address if the first floating Internet Protocol address does not match any physical flow table.

[0156] In one feasible approach, the kernel rate limiter limits the rate by periodically issuing token buckets.

[0157] In one possible implementation, the module further includes: a floating Internet Protocol address group setting module, used to: obtain configuration information for configuring the floating Internet Protocol address group, the configuration information including at least: a floating Internet Protocol address list and a Quality of Service (QoS) rate limiting policy identifier; translate the floating Internet Protocol address list to the address set table of the northbound database of the Open Virtual Network (AVN); and create a Quality of Service (QoS) rate limiting policy table based on the rate limiting information corresponding to the QoS rate limiting policy identifier, wherein the inbound QoS rate limiting policy matching condition of the QoS rate limiting policy table is set to the destination Internet Protocol address equal to the floating Internet Protocol address list and the outbound QoS rate limiting policy identifier equal to the floating Internet Protocol address list. The rate limiting policy matching condition is set to the source Internet Protocol address equal to the floating Internet Protocol address list; the Open Virtual Network (AVN) Northbound process is invoked, and if changes are detected in the address set table and QoS rate limiting policy table of the Northbound database, the changed data is written to the logical flow table of the Southbound data; based on the logical data of the Southbound data's logical flow table, a kernel rate limiter is created, which is used to limit the rate according to the QoS rate limiting policy corresponding to the logical data; a physical flow table is created, and each floating Internet Protocol address in the shared rate-limiting floating Internet Protocol address list is mapped to the kernel rate limiter.

[0158] In one feasible approach, the quality of service rate limiting policy includes at least one of the following: inbound bandwidth, outbound bandwidth, inbound burst bandwidth, and outbound burst bandwidth.

[0159] In one possible implementation, the floating Internet Protocol address group setting module is used to: call the Open Virtual Network Control process, and if it detects that there is a change in logical data in the logical flow table of the southbound database, create a kernel rate limiter based on the logical data.

[0160] In one possible implementation, the floating Internet Protocol address group setting module is further configured to: populate the floating Internet Protocol address group table and the associated address table in the network service component database based on the floating Internet Protocol address list and the quality of service rate limiting policy identifier; wherein, the floating Internet Protocol address group table is used to record the basic information of the floating Internet Protocol address group table, and the associated address table is used to record the association relationship between the floating Internet Protocol address group and the floating Internet Protocol address list.

[0161] In one possible implementation, the floating Internet Protocol address group setting module is also used to: determine whether a floating Internet Protocol address group table exists in the network service component database; if the floating Internet Protocol address group table does not exist in the network service component database, then create the floating Internet Protocol address group table.

[0162] In one possible implementation, the floating Internet Protocol address group setting module is also used to: verify the configuration information; if the verification passes, perform the step of translating the address set table of the northbound database of the Open Virtual Network according to the floating Internet Protocol address list.

[0163] In one possible implementation, the configuration information also includes: a project identifier; the floating Internet Protocol address group setting module is further used to: determine whether the parameter lengths of the floating Internet Protocol address list, the Quality of Service Rate Limiting Policy identifier, and the project identifier are each preset parameter lengths; determine whether each floating Internet Protocol address in the floating Internet Protocol address list is a compliant Internet Protocol address; determine whether the rate limiting policy corresponding to the Quality of Service Rate Limiting Policy identifier exists; and determine whether each floating Internet Protocol address in the floating Internet Protocol address list is a floating Internet Protocol address in the project corresponding to the project identifier.

[0164] In one possible implementation, the floating Internet Protocol address group setting module is used to: obtain the correspondence between projects and floating Internet Protocol addresses; and, based on the correspondence, determine whether each floating Internet Protocol address in the floating Internet Protocol address list is a floating Internet Protocol address in the project corresponding to the project identifier.

[0165] In one possible implementation, the floating Internet Protocol address group setting module is also used to: obtain a first request from a user to add / remove floating Internet Protocol addresses from the floating Internet Protocol address group; and modify the address set table, QoS rate limiting policy table, logical flow table, and physical flow table of the northbound database according to the first request.

[0166] In one possible implementation, the floating Internet Protocol address group setting module is further configured to: obtain a second request from the user to delete the floating Internet Protocol address group, the second request including the identifier of the floating Internet Protocol address group; and delete the address set table, quality of service rate limiting policy table, logical flow table, and physical flow table of the northbound database corresponding to the identifier of the floating Internet Protocol address group.

[0167] In one possible implementation, the access module 230 is further configured to: if there are other access requests corresponding to the same kernel rate limiter, determine the priority of the first floating Internet Protocol address and the floating Internet Protocol addresses corresponding to the other access requests; and determine the access processing order according to the priority.

[0168] In one possible implementation, a policy verification module is also included, used to: determine the service quality rate limiting policy corresponding to the service quality rate limiting policy identifier; obtain the historical processing traffic of each floating Internet Protocol address corresponding to the floating Internet Protocol address list; use the average historical processing traffic of each floating Internet Protocol address as the rate limiting value; use the maximum processing traffic among the historical processing traffic of each floating Internet Protocol address as the mutation value; verify the service quality rate limiting policy corresponding to the service quality rate limiting policy identifier based on the mutation value and the rate limiting value; if the difference is greater than either the mutation value difference threshold or the rate limiting value difference threshold, send a prompt message to allow the user to confirm again.

[0169] Figure 6 A structural diagram of an electronic device provided in an embodiment of the present invention, such as... Figure 6 As shown, the electronic device includes: a memory 60 for storing a computer program; and a processor 61 for executing the computer program to implement the steps of the bandwidth limiting method as described in the above embodiment.

[0170] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 61 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0171] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the bandwidth limiting method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc.

[0172] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0173] Those skilled in the art will understand that Figure 6 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0174] It is understood that if the bandwidth limiting method in the above embodiments is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drive, mobile hard drive, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, magnetic disk or optical disk, and other media capable of storing program code.

[0175] Based on this, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the bandwidth limiting method described above.

[0176] Based on this, embodiments of the present invention also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the above-described bandwidth limiting method.

[0177] The foregoing has provided a detailed description of a bandwidth limiting method, apparatus, device, medium, and product provided by embodiments of the present invention. The various embodiments are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0178] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0179] The present invention has provided a detailed description of a bandwidth limiting method, apparatus, device, medium, and product. Specific examples have been used to illustrate the principles and implementation methods of the invention. The descriptions of these embodiments are merely illustrative of the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to the invention without departing from its principles, and these improvements and modifications also fall within the scope of protection of the present invention.

Claims

1. A bandwidth limiting method, characterized in that, include: After obtaining an access request carrying a first floating Internet Protocol address, it is determined whether the first floating Internet Protocol address hits any physical flow table; wherein, the output action in the physical flow table corresponds to the kernel rate limiter, and the kernel rate limiter corresponds to multiple floating Internet Protocol addresses with shared rate limits. If the first floating Internet Protocol address hits any physical flow table, then it is determined whether the traffic of the first floating Internet Protocol address exceeds the rate limit traffic corresponding to the target kernel rate limiter, wherein the target kernel rate limiter is the kernel rate limiter corresponding to the output action of the hit physical flow table. If the traffic limit corresponding to the target kernel rate limiter is not exceeded, access is made based on the first floating Internet Protocol address.

2. The bandwidth limiting method according to claim 1, characterized in that, If the access request is a first access request to access the first floating Internet Protocol address from outside the cloud; Accordingly, determining whether the first floating Internet Protocol address hits any physical flow table includes: determining whether the first floating Internet Protocol address hits the destination Internet Protocol address of any physical flow table; Accordingly, accessing based on the first floating Internet Protocol address includes: converting the first floating Internet Protocol address into a corresponding virtual machine Internet Protocol address, and accessing based on the corresponding virtual machine Internet Protocol address.

3. The bandwidth limiting method according to claim 1, characterized in that, If the access request is a second access request from a virtual machine to access outside the cloud, the first floating Internet Protocol address is the address obtained by converting the virtual machine's internal Internet Protocol address. Accordingly, determining whether the first floating Internet Protocol address hits any physical flow table includes: determining whether the first floating Internet Protocol address hits the source Internet Protocol address of any physical flow table.

4. The bandwidth limiting method according to claim 1, characterized in that, Also includes: If the traffic exceeds the rate limit corresponding to the target kernel rate limiter, the access request is discarded. And / or, If the first floating Internet Protocol address does not match any physical flow table, then access is performed based on the first floating Internet Protocol address.

5. The bandwidth limiting method according to claim 1, characterized in that, The kernel rate limiter limits the rate of delivery by periodically issuing token buckets.

6. The bandwidth limiting method according to claim 1, characterized in that, Also includes: Obtain configuration information for configuring floating Internet Protocol address groups, wherein the configuration information includes at least: a list of floating Internet Protocol addresses and a service quality rate limiting policy identifier; Based on the floating Internet Protocol address list, translate the address set table to the northbound database of the Open Virtual Network; Based on the rate limiting information corresponding to the service quality rate limiting policy identifier, a service quality rate limiting policy table is created. The service quality rate limiting policy matching condition for the inbound direction of the service quality rate limiting policy table is set to the destination Internet Protocol address equal to the floating Internet Protocol address list, and the service quality rate limiting policy matching condition for the outbound direction is set to the source Internet Protocol address equal to the floating Internet Protocol address list. If the Open Virtual Network Northbound process detects changes in the address set table and QoS rate limiting policy table of the Northbound database in the Open Virtual Network Northbound database, it writes the changed data into the logical flow table of the Southbound data. Based on the logical data of the logical flow table of southbound data, a kernel rate limiter is created. The kernel rate limiter is used to limit the rate according to the service quality rate limiting policy corresponding to the logical data. Create a physical flow table and map each floating Internet Protocol address in the shared rate-limited floating Internet Protocol address list to a kernel rate limiter.

7. The bandwidth limiting method according to claim 6, characterized in that, The quality of service rate limiting policy includes at least one of the following: inbound bandwidth, outbound bandwidth, inbound burst bandwidth, and outbound burst bandwidth.

8. The bandwidth limiting method according to claim 6, characterized in that, Based on the logical data of the logical flow table of southbound data, create a kernel rate limiter, including: The Open Virtual Network Control process is invoked. If it detects changes in logical data in the logical flow table of the southbound database, it creates a kernel rate limiter based on the logical data.

9. The bandwidth limiting method according to claim 6, characterized in that, Also includes: Based on the floating Internet Protocol address list and the Quality of Service (QoS) rate limiting policy identifier, populate the floating Internet Protocol address group table and associated address table in the network service component database; The floating Internet Protocol address group table records basic information about the floating Internet Protocol address group, and the associated address table records the association between the floating Internet Protocol address group and the floating Internet Protocol address list.

10. The bandwidth limiting method according to claim 9, characterized in that, Before populating the floating Internet Protocol address group table and associated address table in the network service component database based on the floating Internet Protocol address list and the Quality of Service (QoS) rate limiting policy identifier, the following steps are also included: Determine if a floating Internet Protocol address group table exists in the network service component database; If the floating Internet Protocol address group table does not exist in the network service component database, then the floating Internet Protocol address group table is created.

11. The bandwidth limiting method according to claim 6, characterized in that, After obtaining the configuration information for configuring the Internet Protocol address set, it also includes: The configuration information is verified. If the verification passes, the step of translating the address set table of the northbound database of the Open Virtual Network (AVN) according to the floating Internet Protocol (IP) address list is executed.

12. The bandwidth limiting method according to claim 11, characterized in that, The configuration information also includes: project identifier; The configuration information is validated, including at least one of the following: Determine whether the parameter lengths of the floating Internet Protocol address list, the Quality of Service rate limiting policy identifier, and the project identifier are each the preset parameter lengths; Determine whether each floating Internet Protocol address in the floating Internet Protocol address list is a compliant Internet Protocol address; Determine whether the rate limiting policy corresponding to the service quality rate limiting policy identifier exists; Determine whether each floating Internet Protocol address in the list of floating Internet Protocol addresses is a floating Internet Protocol address in the project corresponding to the project identifier.

13. The bandwidth limiting method according to claim 12, characterized in that, Determining whether each floating Internet Protocol address in the list is a floating Internet Protocol address in the project corresponding to the project identifier includes: Obtain the mapping between projects and floating Internet Protocol addresses; Based on the correspondence, determine whether each floating Internet Protocol address in the floating Internet Protocol address list is a floating Internet Protocol address in the project corresponding to the project identifier.

14. The bandwidth limiting method according to claim 6, characterized in that, Also includes: Retrieve the user's first request to add / remove floating Internet Protocol addresses from the floating Internet Protocol address group; Based on the first request, modify the address set table, quality of service rate limiting policy table, logical flow table, and physical flow table of the northbound database.

15. The bandwidth limiting method according to claim 6, characterized in that, Also includes: Obtain a second request from the user to delete the floating Internet Protocol address group, the second request including the identifier of the floating Internet Protocol address group; Delete the address set table, QoS rate limiting policy table, logical flow table, and physical flow table of the northbound database corresponding to the identifier of the floating Internet Protocol address group.

16. The bandwidth limiting method according to claim 1, characterized in that, Also includes: If there are other access requests corresponding to the same kernel rate limiter, then determine the priority of the first floating Internet Protocol address and the floating Internet Protocol addresses corresponding to the other access requests. The access processing order is determined based on the priority.

17. A bandwidth limiting device, characterized in that, include: The hit determination module is used to determine whether the first floating Internet Protocol address hits any physical flow table after obtaining an access request carrying the first floating Internet Protocol address; wherein, the output action in the physical flow table corresponds to the kernel rate limiter, and the kernel rate limiter corresponds to multiple floating Internet Protocol addresses with shared rate limits. The rate limiting determination module is used to determine whether the traffic of the first floating Internet Protocol address exceeds the rate limiting traffic corresponding to the target kernel rate limiter if the first floating Internet Protocol address hits any physical flow table. The target kernel rate limiter is the kernel rate limiter corresponding to the output action of the hit physical flow table. The access module is used to access the target kernel rate limiter based on the first floating Internet Protocol address if the rate limit is not exceeded.

18. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the bandwidth limiting method as described in any one of claims 1 to 16.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the bandwidth limiting method as described in any one of claims 1 to 16.

20. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the bandwidth limiting method according to any one of claims 1 to 16.

Images