System using SRIOV network card in Kubernetes environment

Abstract

The invention discloses a system for using an SRIOV network card in a Kubernetes environment, and relates to the technical field of cloud computing. The system provided by the invention can automatically deploy, create, manage and monitor all components created by the SRIOV in a one-button manner, and in addition, the invention also provides a method for dynamically adjusting the bandwidth of the virtual function (VF) of the SRIOV network card, so that the virtual function (VF) of the SRIOV network card can adapt to the dynamically changing workload requirement, and the utilization rate of bandwidth resources is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing, and in particular to a system using a SRIOV network card in a Kubernetes environment. Background Art

[0002] The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.

[0003] In containerized and cloud computing environments, the demand for network performance and flexibility continues to increase with the complexity of applications and data processing requirements. Although ordinary network cards can provide satisfactory network performance in most cases, with the popularity of high-performance computing workloads, big data processing, and machine learning applications, the demand for higher network throughput and lower latency is becoming increasingly apparent.

[0004] In order to provide better support for these emerging application scenarios, the introduction of the multi-NIC solution of SRIOV high-speed network can access network resources through multiple physical NICs at the same time, so as to meet the needs of both general network access control and large data transmission. At the same time, SRIOV technology allows containers to directly access virtual functions (Virtual Function, referred to as VF, is a lightweight PCIe function in SRIOV NIC, associated with physical functions, and can share physical resources with physical functions; each VF can be directly used by a virtual machine, thereby achieving efficient resource utilization and performance) on the physical NIC, bypassing some of the complexity of the traditional network protocol stack and greatly reducing the latency of network communication. Therefore, the study of the application and optimization of multi-NIC and high-speed network solutions in Kubernetes can not only meet the current needs for high-performance computing and large-scale data processing, but also provide technical support and guarantee for the deployment of containerized applications in complex network environments in the future. The introduction of these technologies is not only an extension of the traditional network architecture, but also a response and innovation to the development direction of containerization technology.

[0005] The introduction of SRIOV high-speed networks has significantly improved network performance and reduced latency. However, different applications and workloads may have very different requirements for network bandwidth, so traffic bandwidth control for virtual functions is required. Traffic bandwidth control can help achieve accurate allocation and management of network resources in container environments, avoiding performance degradation or instability caused by resource competition. Therefore, studying and optimizing the traffic bandwidth control of network cards can not only improve network performance and user experience, but also support the development and application needs of future network technologies.

[0006] However, currently using SRIOV network cards in Kubernetes requires the deployment of many components and the manual writing of a lot of configuration information. Of course, in order to write the configuration information, you first need to understand the various fields and configuration options in detail. In addition, handwritten configuration may also lead to human errors and lack automated and intelligent management capabilities. In addition, for some applications that require complex operation logic or dependencies, handwritten configuration files are not flexible and intelligent enough to meet the advanced management needs of the application. In addition, handwritten configuration files will become difficult to maintain over time, and version control and tracking changes will also become difficult, especially in team collaboration and multi-environment deployment. Summary of the invention

[0007] The purpose of the present invention is to provide a system for using SRIOV network cards in a Kubernetes environment to solve the above problems in view of the many troubles currently faced by using SRIOV network cards in Kubernetes.

[0008] The technical solution of the present invention is as follows: A system using an SRIOV network card in a Kubernetes environment, wherein the system framework is constructed using a custom controller technology; the system comprises: a container network plug-in, an SRIOV network card management unit, and a device plug-in provided by an SRIOV network card manufacturer; The container network plug-in exists as an executable binary program and is placed in the container network plug-in working directory configured at the container runtime for invocation when the container runtime creates a pod; The SRIOV network card management unit is responsible for managing and configuring the SRIOV network card of this node; The device plug-in is used to manage and schedule hardware resources.

[0009] Furthermore, the system framework is constructed using custom controller technology, including: parameter parsing, deployment of container network plug-ins, deployment of SRIOV network card management units, and deployment of device plug-ins.

[0010] Furthermore, the parameter parsing includes: The system parameters come from three sources: command line parameters, configuration files, and system default configuration parameters. The three parameters have priority from high to low. If a parameter is repeatedly assigned values ​​in different ways, the configuration value with the higher priority is used. Non-repeated configurations are merged and a unified parameter management object is generated to manage the parameters.

[0011] Furthermore, the deploying the container network plug-in includes: Create relevant CRD files, create service accounts and cluster roles, and make corresponding bindings. Finally, deploy relevant container network plug-ins by creating the DaemonSet deployment file of the container network plug-in.

[0012] Furthermore, the container network plug-in includes: multus, flannel, sriov, whereabouts, and host-local.

[0013] Further, the deployment of the SRIOV network card management unit includes: Deploy the SRIOV network card management unit by creating the DaemonSet deployment file of the SRIOV network card management unit.

[0014] Furthermore, the deployment device plug-in includes: The device plug-in startup requires configuration fields, which are obtained from the SRIOV network card management unit, and a DaemonSet deployment file is created for the device plug-in according to the fields to deploy the device plug-in.

[0015] Furthermore, the SRIOV network card management unit includes: a system configuration module, a bandwidth adaptation module and an indicator collection module; The system configuration module performs system configuration for the network card based on SRIOV technology, and monitors the configuration in real time to see if errors occur and corrects them; The bandwidth adaptation module uses a method for dynamically adjusting the bandwidth of a network card virtual function based on SRIOV technology as a basic algorithm to implement configuration and dynamic adjustment of bandwidth values ​​of each virtual function; The indicator collection module is used to collect the indicator data of the network card and then store it according to the indicator type specified by Prometheus; the indicator collection module provides a RESTful interface for Prometheus to crawl.

[0016] Furthermore, the method for dynamically adjusting the bandwidth of a network card virtual function based on SRIOV technology includes: Step S1: Divide the total bandwidth of the network card into intervals and set the default bandwidth of each VF; Step S2: monitor the VF activation event and adjust the bandwidth for the newly activated VF; Step S3: Monitor the bandwidth utilization of each VF and make adjustments step by step in real time.

[0017] Furthermore, the step S1 comprises: First, the bandwidth of each VF is initially set to the average value, and then the total bandwidth of the network card is divided into a reserved area and an activated area. In the initial working state, the system works at the lower limit of the activation area; The step S2 comprises: When a VF is allocated, the bandwidth of each VF needs to be adjusted again. The bandwidth of the unallocated VF is adjusted to the average value of the reserved area. The target value of the newly allocated VF is calculated as follows:

[0018] Among them, Bc represents the bandwidth to be allocated to the target VF, Bs represents the total bandwidth of the network card, C represents the proportion of the active area in the total bandwidth, Ti represents the throughput of the i-th VF currently allocated for use, r is a threshold, and n represents the total number of VFs; If the calculated result of Bc is greater than the current bandwidth value of the newly allocated VF, the bandwidth of the newly allocated VF is set to Bc, and the bandwidth of other allocated VFs is set to Ti*(1+r); the bandwidth of the reserved area is evenly divided among the unallocated VFs; If the calculated result of Bc is less than the current bandwidth value of the newly allocated VF, switch the activation zone to the upper line position for recalculation. If the calculated result Bc is still less than the current bandwidth value of the newly allocated VF, reduce r by one step. To ensure that the allocated VF still has room for expansion, r can be reduced to one step at most. If r is reduced to one step, and the calculated result of Bc is still less than the current bandwidth value of the newly allocated VF, do not adjust the bandwidth of each VF. Instead, just divide the bandwidth occupied by the newly allocated VF into the activation zone and redefine the waterline. The step S3 comprises: The utilization of each allocated VF is monitored in real time. When the utilization of a VF reaches the warning line, it is adjusted. The adjustment method is to extract a step of bandwidth from the VF with the lowest utilization that has not reached the warning line. When all VFs reach the warning line, the bandwidth values ​​of each VF are averaged according to the principle of equal distribution.

[0019] Compared with the prior art, the present invention has the following beneficial effects: The present invention can automatically deploy and create, manage and monitor all components created by SRIOV with one click. In addition, the present invention also provides a method for dynamically adjusting the bandwidth of the virtual function of the SRIOV network card, which can enable the virtual function of the SRIOV network card to adapt to dynamically changing workload requirements and improve the utilization rate of bandwidth resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1This is a system structure diagram for using SRIOV network cards in a Kubernetes environment; Containerd is an industry-standard container runtime; Kubelet is the main "node agent" running on each node in a Kubernetes cluster, responsible for managing the life cycle of Pods and containers and monitoring resource usage; Device Manager is a module in Kubernetes responsible for device plug-in interaction and device life cycle management; the rest of the English is explained in detail in the examples; Figure 2 A flowchart of a method for dynamically adjusting the bandwidth of a network card virtual function based on SRIOV technology; Figure 3 It is a structural diagram of the SRIOV network card management unit. DETAILED DESCRIPTION

[0021] It should be noted that relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0022] The features and performance of the present invention are further described in detail below in conjunction with the embodiments.

[0023] Embodiment 1 See also Figure 1 , a system that uses SRIOV network cards in a Kubernetes environment. The system framework is built using custom controller technology, namely Operator. It should be noted that Operator is a way provided by Kubernetes to extend its own API. Custom resource CRDs can be used to describe and manage the life cycle of applications or specific services, thereby automatically managing and optimizing the operation of applications. The system includes: a container network plug-in, an SRIOV network card management unit (i.e. Figure 1 sriovNetManager in ) and the device plug-in provided by the SRIOV network card manufacturer (i.e. Figure 1Device plugin in ); Among them, the SRIOV network card management unit is a self-developed component, and the container network plug-in and device plug-in are open source components from various companies in the ecological chain; The container network plug-in exists as an executable binary program and is placed in the container network plug-in working directory configured at the container runtime for calling when the container runtime creates a pod; the working directory of the container network plug-in needs to be read from the container runtime configuration file; it should be noted that Pod is the smallest scheduling unit in Kubernetes, which can encapsulate one or more closely related containers, and the containers in the Pod share storage, network, etc.; The SRIOV network card management unit is responsible for managing and configuring the SRIOV network card of this node; The device plug-in is used to manage and schedule hardware resources.

[0024] In this embodiment, specifically, the system framework is constructed using custom controller technology, including: parameter parsing, deploying container network plug-ins, deploying SRIOV network card management units, and deploying device plug-ins.

[0025] In this embodiment, specifically, the parameter parsing includes: The system parameters come from three sources: command line parameters, configuration files, and system default configuration parameters. The three parameters have priority from high to low. If a parameter is repeatedly assigned values ​​in different ways, the configuration value with the higher priority is used. Non-repeated configurations are merged and a unified parameter management object is generated to manage the parameters.

[0026] In this embodiment, specifically, the deploying of the container network plug-in includes: Create relevant CRD files, create service accounts and cluster roles, and perform corresponding bindings. Finally, deploy relevant container network plug-ins by creating the DaemonSet deployment file of the container network plug-in. It should be noted that the container containing the container network plug-in is intended to copy the binary program to the container network plug-in working directory, and generate the container network plug-in configuration file and access certificate file. It should be noted that the full name of CRD is Custom Resource Definitions. CRD is a powerful Kubernetes API extension mechanism that allows users to create and manage custom resources that are not part of the Kubernetes standard API. Through CRD, users can define their own resource structure and then operate these custom resources like Kubernetes built-in resources. It should be noted that DaemonSet is a controller in Kubernetes that is used to ensure that a specific Pod copy is running on each (or certain) node in the cluster.

[0027] In this embodiment, specifically, the container network plug-in includes: multus, flannel, sriov, whereabouts, host-local; It should be noted that mutlus is a container network interface (CNI) plug-in in Kubernetes that allows multiple network interfaces to be used simultaneously in a Pod; Flannel is a simple and effective cross-node network solution in a Kubernetes cluster, allowing containers to obtain unique, routable IP addresses on different physical hosts and communicate with each other; SR-IOV (Single Root I / O Virtualization) is a standard specification defined by the PCI-SIG organization to extend the PCIe specification. This specification is based on hardware virtualization technology and allows a single physical device (such as a network card) to be virtualized into multiple virtual devices, each of which can be used by a separate virtual machine. Whereabouts is an IP address management CNI plugin designed for Kubernetes, which is used to assign IP addresses to Pods across the entire cluster. Host-local is a CNI plugin that assigns IP addresses to Pods on a single node in a Kubernetes cluster.

[0028] Therefore, specifically, for the deployment of multus, multus is a solution proposed for realizing multiple network cards in containers under the Kubernetes environment and is used in conjunction with other container network plug-ins. To deploy multus, it is necessary to create a Network Attachment Definition (NAD) resource for it. NAD contains references to other container network plug-in configuration files. In this way, different types of network services can be freely selected and combined according to needs. To expand a new resource in the Kubernetes system, it is necessary to first use CRD to describe this new resource, so it is necessary to first create a CRD that describes NAD. In addition, multus needs to access the Kubernetes API, so it is necessary to create a service account and MULTUS cluster role and corresponding role binding. Finally, the relevant container network plug-in is deployed by creating a DaemonSet. The container containing the container network plug-in is intended to copy the binary program to the container network plug-in working directory, and generate the container network plug-in configuration file and access certificate file.

[0029] For whereabouts, whereabouts is a container network plug-in that uniformly allocates and manages IP addresses in the Kubernetes system. Similarly, the IP resource pool and the allocated IP are recorded through the CRD resources IPPool (IP address pool) and OverlappingRange IP Reservation (i.e., overlapping IP range reservation, which is a custom resource definition (CRD) in the whereabouts network plug-in, used to record and manage those IP addresses that have been allocated but may overlap with other IP address ranges). Therefore, deploying whereabouts also requires creating CRD and service accounts for it, as well as cluster roles and corresponding bindings, and finally completing the deployment by creating a DaemonSet to deploy whereabouts.

[0030] For other container network plug-ins such as sriov, flannel, and host-local, you only need to ensure that they are placed in the container network plug-in working directory.

[0031] In this embodiment, specifically, the deployment of the SRIOV network card management unit includes: Deploy the SRIOV network card management unit by creating the DaemonSet deployment file of the SRIOV network card management unit.

[0032] In this embodiment, specifically, the deployment device plug-in includes: The device plug-in startup needs to configure specific fields such as vendors and device IDs. The fields are obtained from the SRIOV network card management unit, and a DaemonSet deployment file is created for the device plug-in based on the fields to deploy the device plug-in.

[0033] In this embodiment, please refer to Figure 3 , the SRIOV network card management unit includes: a system configuration module, a bandwidth adaptation module and an indicator collection module; The system configuration module performs system configuration for the network card based on SRIOV technology, and monitors the configuration in real time to see if errors occur and corrects them; first, perform a hardware support condition check, notify the user if the check fails, and then exit. Secondly, the module needs to find a network card with SRIOV capability. Then check the maximum number of VFs (virtual functions) that the network card can support, and finally divide the number of VFs for the network card; that is, first, perform a hardware support condition check, such as Intel's CPU needs to support VT-X and VT-D or AMD's support SVM and IOMMU, and turn them on in the BIOS, notify the user if the check fails, and then exit. Secondly, the module needs to find a network card with SRIOV capability, such as using lspci –vvvv|grep –iEthernet to find out the BUS number of the Ethernet card, and then use lspci –s pci device BUS number –vvv|grepCapabilites to filter out the network card with SRIOV capability. Then check the maximum number of virtual functions (VFs) that the network card can support, such as checking / sys / bus / pci / devices / <device_id> / sriov_totalvfs, and finally divide the number of virtual functions (VFs) of the network card. For example, set the value that the network card can support to the / sys / class / net / network card name / device / sriov_numvfs file; The bandwidth adaptation module uses a method for dynamically adjusting the bandwidth of a network card virtual function based on SRIOV technology as a basic algorithm to implement configuration and dynamic adjustment of bandwidth values ​​of each virtual function; The indicator collection module is used to collect the indicator data of the network card and then store it according to the indicator type specified by Prometheus; the indicator collection module provides a RESTful interface for Prometheus to crawl; by monitoring various indicators, the software can understand the performance status of the system in real time, discover potential problems and solve them in time, so as to ensure the efficient and stable operation of the software; It should be noted that Prometheus is a tool used in Kubernetes clusters to monitor the performance and health of the cluster; RESTful interfaces refer to network interfaces that follow the REST (Representational State Transfer) architectural style. These interfaces are resource-centric and use the HTTP protocol to handle resource states.

[0034] In this embodiment, please refer to Figure 2 The method for dynamically adjusting the bandwidth of a network card virtual function based on SRIOV technology includes: Step S1: Divide the total bandwidth of the network card into intervals and set the default bandwidth of each VF; Step S2: monitor the VF activation event and adjust the bandwidth for the newly activated VF; Step S3: Monitor the bandwidth utilization of each VF and make adjustments step by step in real time.

[0035] In this embodiment, specifically, step S1 includes: First, the bandwidth of each VF is initially set to the average value, and then the total bandwidth of the network card is divided into a reserved area and an activated area. In the initial working state, the system works at the lower limit of the activation area; That is, firstly, assign values ​​to various variables used by the system, and the values ​​can be manually configured by the user. If the user does not configure, the system default value is used. And the total bandwidth of the network card is divided into a reserved area and an activated area. The reason why this application provides a reserved area is to prevent the virtual function (VF) from being allocated and used, but the bandwidth cannot be adjusted in time, resulting in network unavailability; it should be noted that the user can manually configure the range of the interval division. The system defaults to setting the activation area to 80% for the offline position, and the corresponding reserved area is 20%, and the online position is 90%, and the corresponding reserved area is 10%.

[0036] In this embodiment, specifically, step S2 includes: When a VF is allocated, the bandwidth of each VF needs to be adjusted again. The bandwidth of the unallocated VF is adjusted to the average value of the reserved area. The target value of the newly allocated VF is calculated as follows:

[0037] Among them, Bc represents the bandwidth to be allocated to the target VF, Bs represents the total bandwidth of the network card, C represents the proportion of the active area in the total bandwidth, Ti represents the throughput of the i-th VF currently allocated, r is a threshold that can be manually configured by the user, and the system defaults to 20%. The reason for setting this threshold is to give the virtual function (VF) that has been allocated a space to quickly increase the rate, and n represents the total number of VFs; If the calculated result of Bc is greater than the current bandwidth value of the newly allocated VF, the bandwidth of the newly allocated VF is set to Bc, and the bandwidth of other allocated VFs is set to Ti*(1+r); the bandwidth of the reserved area is evenly divided among the unallocated VFs; If the calculated result of Bc is less than the current bandwidth value of the newly allocated VF, switch the activation zone to the upper line position for recalculation. If the calculated result Bc is still less than the current bandwidth value of the newly allocated VF, reduce r by one step. To ensure that the allocated VF still has room for expansion, r can be reduced to one step at most. If r is reduced to one step, and the calculated result of Bc is still less than the current bandwidth value of the newly allocated VF, do not adjust the bandwidth of each VF. Instead, just divide the bandwidth occupied by the newly allocated VF into the activation zone and redefine the waterline. That is, monitor whether there are new virtual functions (VFs) allocated for use. If so, adjust the bandwidth configured for each VF. The adjustment method will vary depending on the system throughput. When the throughput is not high, a larger floating space will be reserved for the virtual functions (VFs) that have been allocated for use, and the rest will be allocated to unknown newly allocated VFs. If the throughput is high, part of the reserved bandwidth will be used first and adjusted to the activation area. If it is still not enough, steal from the VFs that have been allocated for use.

[0038] In this embodiment, specifically, step S3 includes: The utilization of each assigned VF is monitored in real time. When the utilization of a VF reaches the warning line, adjustments are made. It should be noted that the value of the warning line can be manually configured by the user, and the system defaults to 95%. The adjustment method is to extract a step of bandwidth from the VF with the lowest utilization and that has not reached the warning line. It should be noted that the step can be manually configured by the user, and the default is 2%. When all VFs reach the warning line, the bandwidth values ​​of each VF are made to approach the average value according to the equal distribution principle. The specific method is to adjust the bandwidth of the VF with the largest current bandwidth among all VFs to the VF with the smallest current bandwidth according to the adjustment step.

[0039] The above-mentioned embodiments only express the specific implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the protection scope of the present application. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the technical solution concept of the present application, and these all belong to the protection scope of the present application.

[0040] This background section is provided to generally present the context of the invention, and the work of the presently named inventors, the work to the extent described in this background section, and aspects of this section that did not constitute prior art at the time of application are neither explicitly nor implicitly admitted to be prior art to the present invention.

Claims

1. A system using SRIOV network cards in a Kubernetes environment, characterized by: The system framework is constructed using custom controller technology; the system includes: a container network plug-in, an SRIOV network card management unit, and a device plug-in provided by an SRIOV network card manufacturer; The container network plug-in exists as an executable binary program and is placed in the container network plug-in working directory configured at the container runtime for invocation when the container runtime creates a pod; The SRIOV network card management unit is responsible for managing and configuring the SRIOV network card of this node; The device plug-in is used to manage and schedule hardware resources.

2. The system for using SRIOV network card in Kubernetes environment according to claim 1, characterized in that: The system framework is constructed using custom controller technology, including: parameter parsing, deployment of container network plug-ins, deployment of SRIOV network card management units, and deployment of device plug-ins.

3. The system for using SRIOV network card in Kubernetes environment according to claim 2, characterized in that: The parameter parsing includes: The system parameters come from three sources: command line parameters, configuration files, and system default configuration parameters. The three parameters have priority from high to low. If a parameter is repeatedly assigned values ​​in different ways, the configuration value with the higher priority is used. Non-repeated configurations are merged and a unified parameter management object is generated to manage the parameters.

4. The system for using SRIOV network card in Kubernetes environment according to claim 2, characterized in that: The deploying container network plug-in includes: Create relevant CRD files, create service accounts and cluster roles, and make corresponding bindings. Finally, deploy relevant container network plug-ins by creating the DaemonSet deployment file of the container network plug-in.

5. The system for using SRIOV network card in Kubernetes environment according to claim 4, characterized in that: The container network plug-ins include: multus, flannel, sriov, whereabouts, and host-local.

6. The system for using SRIOV network card in Kubernetes environment according to claim 2, characterized in that: The deployment of the SRIOV network card management unit includes: Deploy the SRIOV network card management unit by creating the DaemonSet deployment file of the SRIOV network card management unit.

7. The system for using SRIOV network card in Kubernetes environment according to claim 2, characterized in that: The deployment device plug-in includes: The device plug-in startup requires configuration fields, which are obtained from the SRIOV network card management unit, and a DaemonSet deployment file is created for the device plug-in according to the fields to deploy the device plug-in.

8. The system for using SRIOV network card in Kubernetes environment according to claim 1, characterized in that: The SRIOV network card management unit includes: a system configuration module, a bandwidth adaptation module and an indicator collection module; The system configuration module performs system configuration for the network card based on SRIOV technology, and monitors the configuration in real time to see if errors occur and corrects them; The bandwidth adaptation module uses a method for dynamically adjusting the bandwidth of a network card virtual function based on SRIOV technology as a basic algorithm to implement configuration and dynamic adjustment of bandwidth values ​​of each virtual function; The indicator collection module is used to collect the indicator data of the network card and then store it according to the indicator type specified by Prometheus; the indicator collection module provides a RESTful interface for Prometheus to crawl.

9. The system for using SRIOV network card in Kubernetes environment according to claim 8, characterized in that: The method for dynamically adjusting the bandwidth of a network card virtual function based on SRIOV technology includes: Step S1: Divide the total bandwidth of the network card into intervals and set the default bandwidth of each VF; Step S2: monitor the VF activation event and adjust the bandwidth for the newly activated VF; Step S3: Monitor the bandwidth utilization of each VF and make adjustments step by step in real time.

10. The system for using SRIOV network card in Kubernetes environment according to claim 9, characterized in that: The step S1 comprises: First, the bandwidth of each VF is initially set to the average value, and then the total bandwidth of the network card is divided into a reserved area and an activated area. In the initial working state, the system works at the lower limit of the activation area; The step S2 comprises: When a VF is allocated, the bandwidth of each VF needs to be adjusted again. The bandwidth of the unallocated VF is adjusted to the average value of the reserved area. The target value of the newly allocated VF is calculated as follows: Among them, Bc represents the bandwidth to be allocated to the target VF, Bs represents the total bandwidth of the network card, C represents the proportion of the active area in the total bandwidth, Ti represents the throughput of the i-th VF currently allocated for use, r is a threshold, and n represents the total number of VFs; If the calculated result of Bc is greater than the current bandwidth value of the newly allocated VF, the bandwidth of the newly allocated VF is set to Bc, and the bandwidth of other allocated VFs is set to Ti*(1+r); the bandwidth of the reserved area is evenly divided among the unallocated VFs; If the calculated result of Bc is less than the current bandwidth value of the newly allocated VF, switch the activation zone to the upper line position for recalculation. If the calculated result Bc is still less than the current bandwidth value of the newly allocated VF, reduce r by one step. To ensure that the allocated VF still has room for expansion, r can be reduced to one step at most. If r is reduced to one step, and the calculated result of Bc is still less than the current bandwidth value of the newly allocated VF, do not adjust the bandwidth of each VF. Instead, just divide the bandwidth occupied by the newly allocated VF into the activation zone and redefine the waterline. The step S3 comprises: The utilization of each allocated VF is monitored in real time. When the utilization of a VF reaches the warning line, it is adjusted. The adjustment method is to extract a step of bandwidth from the VF with the lowest utilization that has not reached the warning line. When all VFs reach the warning line, the bandwidth values ​​of each VF are averaged according to the principle of equal distribution.

Images