A north-south bandwidth dynamic QoS control system, method and device of a multi-tenant intelligent computing center

Abstract

The application discloses a kind of multi-tenant intelligence calculation center's north-south direction bandwidth dynamic QoS control system, it is related to computer network and communication technical field, including policy control layer, data acquisition and monitoring layer, execution and forwarding layer, interface adaptation layer, identification and mapping layer and persistence and operation and maintenance layer;The application solves the problems that existing static QoS is difficult to adapt to service fluctuation, link utilization is uneven and multi-tenant fairness is insufficient.In the premise of not changing application and network equipment form, by controller real-time perception-computation-issuing policy, so that tenant application obtains the flexible north-south direction bandwidth of " can guarantee, can share, can recycle ".

Description

Technical Field

[0001] This invention relates to the field of computer network and communication technology, and in particular to a north-south bandwidth dynamic QoS control system, method and apparatus for a multi-tenant intelligent computing center. Background Technology

[0002] In the construction of existing intelligent computing centers, it is often necessary to allocate outbound bandwidth to tenants, commonly known as north-south bandwidth. This network bandwidth management mostly adopts static QoS policies, that is, pre-allocating fixed bandwidth limits to different tenants' applications or hosts. While static allocation can provide basic bandwidth isolation, it can easily lead to resource waste and performance issues when traffic load changes dynamically. For example, in a fixed bandwidth allocation model, if a portion of bandwidth is reserved for a specific tenant but not fully utilized, its idle portion cannot be used by other traffic, resulting in low link utilization. Theoretically, if unused bandwidth resources could be dynamically utilized, the overall bandwidth utilization would be significantly improved. However, traditional devices and policies often lack mechanisms to adjust allocation based on real-time traffic.

[0003] Multi-tenant intelligent computing centers often deploy tenant applications using containers. In containerized environments, bandwidth scheduling faces more complex challenges due to the presence of NAT container architecture. Multiple containers typically share the host machine's network egress IP, and NAT translates inbound and outbound traffic, making it difficult for external firewalls to directly distinguish the traffic of each container. Current container orchestration systems such as Kubernetes only provide limited QoS configurations, such as limiting the maximum bandwidth of a Pod but not guaranteeing the minimum bandwidth, and configuration changes require restarting the Pod to take effect. This not only prevents critical containers from obtaining bandwidth guarantees but also results in a lack of flexibility in policy adjustments. To implement fine-grained bandwidth control for each container, existing solutions often configure independent queue rules for each container's network interface on the host machine, such as using Linuxtc tools and iptables to create HTB queues for different containers to limit rates. However, this approach is complex to configure, requiring the maintenance of separate virtual devices (IFBs) and rules for each container, and the maintenance workload becomes enormous as the number of containers grows.

[0004] In summary, existing technologies have two major shortcomings: (1) Static QoS policies lack adaptability, and fixed bandwidth allocation results in idle resources being unusable and cannot be optimized according to dynamic changes in traffic. (2) The container NAT network architecture makes fine-grained bandwidth management difficult to achieve. Existing container QoS solutions are limited in function (no minimum guarantee, inflexible updates) and have high implementation costs. There is an industry trend to explore dynamic QoS scheduling, such as combining monitoring with real-time policy adjustments to automatically reduce the bandwidth usage of low-priority traffic during peak traffic periods. This indicates that introducing centralized control and dynamic policy distribution mechanisms is expected to solve the above problems and achieve more efficient and fair bandwidth management. Summary of the Invention

[0005] One objective of this invention is to propose a dynamic QoS control system, method, and apparatus for north-south bandwidth in a multi-tenant intelligent computing center, addressing the problems of existing static QoS systems being unable to adapt to service fluctuations, uneven link utilization, and insufficient fairness among multi-tenants. Without altering the application and network equipment configuration, the controller uses real-time sensing, calculation, and policy distribution to enable tenant applications to obtain "guaranteed, shareable, and reclaimable" elastic north-south bandwidth.

[0006] According to an embodiment of the present invention, a north-south bandwidth dynamic QoS control system for a multi-tenant intelligent computing center includes a policy control layer, a data acquisition and monitoring layer, an execution and forwarding layer, an interface adaptation layer, an identification and mapping layer, and a persistence and operation and maintenance layer. The policy control layer includes a policy controller and a policy engine. The policy controller aggregates network metric data from the entire network, and the policy engine calculates the minimum bandwidth, maximum bandwidth, and sharing ratio of containers based on a multi-dimensional weight model and AIMD smoothing algorithm, and generates a versioned QoS policy set. The multidimensional weight model is based on tenant weight w, business requirement r, and SLA priority p. sla The five-dimensional parameters are weighted: historical bandwidth h, congestion observation indicators, and q. The congestion observation indicators include: q, real-time queue length, p, and real-time packet loss rate. th Queue length threshold; p th Packet loss rate threshold, combined with AIMD additive increase and multiplicative decrease smoothing iterative calculation of minimum bandwidth, maximum bandwidth, and shared allocation ratio for each container; Each scheduling cycle generates a complete set of firewall CAR / MQC rate limiting configurations with version numbers based on real-time metrics, supporting canary batch deployment and version rollback, i.e., a versioned QoS policy set; The data acquisition and monitoring layer includes a monitoring probe, a firewall statistics interface, and an alarm triggering module. The monitoring probe periodically collects container-level traffic indicators and link indicators, the firewall statistics interface obtains device-level indicators, and the alarm triggering module triggers emergency scheduling based on a preset threshold. The execution and forwarding layer includes a firewall scheduling module deployed on the egress data plane. The firewall scheduling module supports parallel scheduling of "dedicated bandwidth pool and shared bandwidth pool". The dedicated bandwidth pool allocates a minimum bandwidth to high-priority containers, and the shared bandwidth pool aggregates unused dedicated bandwidth and idle bandwidth and allocates them fairly according to weight. The interface adaptation layer includes an instruction conversion module and an atomic delivery module. The instruction conversion module maps the QoS policy set to the firewall's native commands, and the atomic delivery module uses a "begin-commit" transaction mechanism to deliver instructions in batches, automatically rolling back upon failure. The identification and mapping layer includes a container-IP mapping table and a NAT front traffic tagging module. The container-IP mapping table dynamically maintains the "tenant ID-container ID-IP" relationship, and the NAT front traffic tagging module adds custom tags to container packets to achieve traffic identification after NAT. The persistence and operation layer includes a policy repository, an audit and rollback module, and a canary release module. The policy repository stores historical data of policies and metrics. The audit and rollback module records operations and supports version rollback. The canary release module pushes policies in batches. The data acquisition and monitoring layer collects metrics in real time and pushes them to the policy control layer; the policy engine calculates and generates versioned QoS policy sets and sends them to the interface adaptation layer to be converted into device instructions; the interface adaptation layer atomically sends them to the firewall scheduling module of the execution and forwarding layer for execution; the identification and mapping layer provides "container-IP" tagging and mapping support for the entire link; the persistence and operation and maintenance layer executes the full-process storage, auditing, and canary release policies, forming a complete closed loop of "collection-computation-transformation-deployment-execution-storage auditing".

[0007] Preferably, the container-level traffic metrics include instantaneous rate, number of active connections, and traffic protocol type; the link metrics include bandwidth utilization, packet loss rate, and average queue length; and the device-level metrics include ACL hit count, QoS queue status, and packet loss statistics. The preset threshold of the alarm triggering module includes a packet loss rate p. th ≥1%, SLA priority p sla_th ≤0.5, average queue length q th ≥20 data packets.

[0008] Preferably, the sharing mode of the firewall scheduling module includes "per-address sharing" and "weighted fairness"; the per-address sharing mode is adopted when there is low tenant concurrency and stable business traffic; the weighted fairness sharing mode is switched to when there are many high-concurrency containers and link congestion scenarios; the firewall native commands include H3CNGFW's CAR rules (qoscarlXsource-ipper-addressshared-bandwidth) and MQC policies (MQC complete binding process trafficclassifier→trafficbehavior→policymap→interface application policy).

[0009] Working mechanism: During the scheduling cycle, the controller calculates bandwidth allocation based on real-time metrics and a weighted model: when bandwidth is ample, idle space is shared according to weight; when congestion occurs, a safety net is guaranteed first, then ordinary containers are rolled back according to AIMD and smoothly updated. Policies are generated, validated, issued, and confirmed in a transactional manner, with automatic rollback in case of failure to avoid business instability.

[0010] This solution, under the premise that the container network segment can be directly identified by the firewall, takes into account multi-tenant isolation and network-wide fairness, significantly improves link utilization and SLA achievement rate, and has the advantages of scalability, maintainability, and low intrusion for engineering implementation.

[0011] This invention also provides a dynamic QoS control method for north-south bandwidth in a multi-tenant intelligent computing center, which is executed cyclically within a fixed scheduling period Δt, and includes the following steps: Step 1: Metrics collection and preprocessing, obtaining the total link bandwidth C link Container instantaneous rate Congestion metrics and "container-IP" mapping relationships are defined, and the active container set A(t) and dedicated container set D(t) are initialized. Congestion metrics include two types of real-time monitoring metrics: link packet loss rate and average queue length. Step 2: Dedicated Bandwidth Pool / Shared Bandwidth Pool Bandwidth Budget, calculate the initial shared bandwidth pool bandwidth. , Among them, C link Total link bandwidth, r min,i Guarantee minimum bandwidth for container i; This represents the sum of the guaranteed bandwidth of all containers in the dedicated set D(t); Reclaim unused bandwidth from dedicated containers Update the effective shared pool bandwidth. ;in, This represents the total amount of recyclable bandwidth. Step 3: Demand estimation and activity determination, using the exponential smoothing algorithm to calculate the smoothed demand for containers. Based on demand and connection thresholds, determine active containers and update A(t) and D(t); This is the smoothing coefficient, with a value between 0 and 1; This is the demand value calculated in the previous period; This refers to the instantaneous rate monitored during this period; Step 4: Dynamic weight update based on normalized demand ratio ,when =0 =0; Update container weights by combining additive gain, multiplicative loss, queue feedback, and guaranteed bias. (t), and restricted to [ , Within the specified range; when there is no network congestion, additive gain is applied to increase the weight of high-demand containers; when packet loss exceeds the threshold, multiplicative loss is applied to globally reduce the weight; when the queue overflows, queue feedback is applied to linearly reduce the weight; when the container's minimum bandwidth is not fully utilized, a minimum bias is applied to increase the weight; among these, This represents the sum of the demands of all containers in the active set; Step 5: Two-stage bandwidth quota allocation, Phase 1: initial share allocated according to weight. The first round of quota R is determined by combining the minimum guarantee, demand, and upper limit. i ; in, This represents the nominal bandwidth share allocated to container i according to its weight. The weight of container i in this period; This represents the sum of the weights of all active containers. Effective shared pool bandwidth Phase 2 allocates the surplus bandwidth L to the gap containers according to their weights, resulting in the final quota R. i (t); Step 6: Rate smoothing and policy distribution. The distribution bandwidth is obtained using an exponential smoothing algorithm. When the conditions for distribution are met, a firewall instruction is generated and atomically distributed, and the effective status is verified.

[0012] The exponential smoothing algorithm is a first-order exponential filter for bandwidth requirements, used to smooth out instantaneous traffic bursts.

[0013] Preferably, the specific formula for weight update in step 4 includes: Additive gain: , where α is the additive coefficient, taking values ​​from 0.1 to 0.3; The percentage of normalized demand for active containers; Multiplicative reduction: If ,but , where β is the multiplicative coefficient, with a value of 0.4-0.6; Queue feedback: If ,but ,in This is the queue coefficient, with a value ranging from 0.01 to 0.03; Minimum offset: Where γ is the bias coefficient, taking a value of 0.1-0.3; let This represents the bandwidth actually used by container i in the previous scheduling cycle (or the previously issued integer rate). This reflects the proportion of the container's guaranteed bandwidth that has not yet been fully utilized. Among them, packet loss rate p and packet loss threshold p th Real-time queue length q, queue threshold q th .

[0014] Preferably, in step 5, the first round quota R i The calculation formula is ,in The upper limit of container bandwidth; the surplus bandwidth Gap container set .

[0015] Preferably, the bandwidth sent in step 6 The formula is ,in This represents the smoothed bandwidth value that will be sent to container i. The smoothing coefficient is 0 to 1. For the scheduling period, This is the value issued by the container in the previous period; the issuance condition is... and Where δ is the variation threshold and Thold is the cooling time. This is the time when the container policy was last issued.

[0016] The beneficial effects of this invention are: 1. Significantly Improved Bandwidth Utilization: The dynamic scheduling algorithm employs a weighted fair sharing and bandwidth borrowing mechanism, fully utilizing unused remaining bandwidth. In traditional fixed allocation, idle reserved bandwidth is often wasted, while this system allows other active containers to temporarily occupy these bandwidth resources, thus maintaining a high link load rate. When high-priority service traffic decreases, low-priority or other containers can immediately utilize the freed-up bandwidth, achieving near 100% link utilization. Practices similar to the Google B4 network show that centralized scheduling using the max-min fair algorithm can bring link utilization close to saturation. In practical applications, the dynamic bandwidth allocation mode of this system smoothly brings the total bandwidth utilization curve close to the capacity limit, avoiding the waste of idle bandwidth resources.

[0017] 2. Improved Fairness Among Containers: By introducing scheduling mechanisms such as Weighted Fair Queuing (WFQ), the system ensures that each container receives bandwidth according to a pre-set weight ratio, preventing any single container from monopolizing the link. Even when total bandwidth is limited, the scheduling algorithm ensures that each container receives at least a fair share corresponding to its weight, achieving weighted max-min fair allocation. When traffic to some containers suddenly increases, the system reduces the allocation to other containers according to their weights to maintain fairness; conversely, when the sudden traffic decreases, previously restricted containers are allowed to resume operation or other containers can utilize idle bandwidth. This dynamic balancing strategy effectively improves fairness during bandwidth contention among containers, avoiding the problem of low-weight containers being completely starved or high-weight containers being unable to fully utilize bandwidth due to static limitations.

[0018] 3. Critical User Bandwidth Guarantee: This system provides minimum bandwidth guarantees and priority forwarding strategies for critical containers or high-priority services. When network congestion occurs, the controller prioritizes ensuring critical containers receive at least their guaranteed bandwidth, and if necessary, reduces the bandwidth usage of secondary traffic to achieve the same goal. Because the controller has a global view and rapid response capabilities, it can detect instantaneous changes in critical traffic within milliseconds and adjust strategies accordingly, such as increasing the priority of critical container queues or temporarily tightening the bandwidth limits of other containers, thereby maintaining the performance of critical services (low latency, low packet loss). Simultaneously, when critical services are idle, the system automatically restores the normal quotas for other containers to avoid wasting bandwidth. Compared to static QoS policies that require manually reserving excessive bandwidth to protect critical services, the dynamic guarantee mechanism of this invention maximizes overall throughput while ensuring the supply of key traffic.

[0019] In summary, the controller-based dynamic policy deployment achieves efficient utilization, fair allocation, and differentiated protection. Tests show that compared to traditional static rate limiting schemes, this system significantly improves bandwidth utilization and multi-tenant fairness, while maintaining the service quality of critical services unaffected by traffic fluctuations. Attached Figure Description

[0020] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a diagram of the layered architecture of the present invention; Figure 2 This is a flowchart of the algorithm of the present invention; Figure 3 This describes the interaction sequence of the various service components in this invention. Detailed Implementation

[0021] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0022] This invention proposes a dynamic QoS control system for north-south bandwidth in a multi-tenant intelligent computing center, such as... Figure 1 , Figure 3 As shown, it includes: 1) Policy Control Layer: Includes a policy controller and a policy engine. The controller aggregates network-wide metrics (bandwidth usage, packet loss / latency, active connections) and applies them based on multi-dimensional weights (tenant / container weight w, demand r, SLA priority p). sla Historical occupancy (h), congestion observation metrics, including: q (real-time queue length), p (real-time packet loss rate); q th Queue length threshold; p th The packet loss rate threshold and the AIMD smoothing algorithm are used to calculate the minimum / maximum / sharing ratio of each container to form a versioned strategy set.

[0023] 2) Data Acquisition and Monitoring Layer: Consists of probes and firewall statistics interfaces, periodically reporting metrics such as interface rate, ACL hits, queue / packet loss, and providing alarm threshold triggering (e.g., q≥q). th p≤p th ).

[0024] 3) Execution and Forwarding Layer (Firewall Scheduling Module): Deployed at the data plane egress, it executes rate limiting and reshaping according to controller instructions. It supports parallel use of shared pools and dedicated bandwidth: the shared pool uses either "per-address sharing" or "weighted fairness"; dedicated entries ensure a minimum SLA guarantee.

[0025] 4) Interface Adaptation Layer: Converts policy sets into native device commands and sends them atomically, typically H3CNGFW's QoS commands. Shared / per-IP based on CAR list: qoscarl…per-address[shared-bandwidth], API application: qoscar{inboundoutbound}carlXcir / pircbsebs…; Alternatively, using MQC: After binding trafficclassifier / behavior / policy, qosapplypolicy takes effect in both inbound and outbound directions.

[0026] 5) Identification and Mapping Layer: Maintains the mapping between "container ⇔ IP / network segment" and tenant; if NAT exists, it marks the packets before the NAT to maintain recognizability.

[0027] 6) Persistence and Operations Layer: Policy repository, auditing and rollback, canary release (batch interface / regional push), and record policy verification and device receipts.

[0028] Working mechanism: During the scheduling cycle, the controller calculates bandwidth allocation based on real-time metrics and a weighted model: when bandwidth is ample, idle space is shared according to weight; when congestion occurs, a safety net is guaranteed first, then ordinary containers are rolled back according to AIMD and smoothly updated. Policies are generated, validated, issued, and confirmed in a transactional manner, with automatic rollback in case of failure to avoid business instability.

[0029] This solution, under the premise that the container network segment can be directly identified by the firewall, takes into account multi-tenant isolation and network-wide fairness, significantly improves link utilization and SLA achievement rate, and has the advantages of scalability, maintainability, and low intrusion for engineering implementation.

[0030] This invention also proposes a dynamic QoS control method for north-south bandwidth in multi-tenant intelligent computing centers, such as... Figure 2 As shown, this method executes once within a fixed scheduling period Δt (e.g., 3–5 seconds). The scheduling controller completes the real-time calculation of the bandwidth allocation strategy in the following order: "metric collection → shared pool calculation → demand estimation → weight update → two-stage allocation → rate smoothing → QoS configuration". The logic of each step is as follows: a) Indicator Collection This step aims to obtain the latest network status and container traffic metrics, providing input for subsequent bandwidth calculations. The controller collects operational metrics for links and containers from monitoring probes and edge devices. Inputs include: total link bandwidth and current utilization ρ, packet loss rate p, average queue length q, number of active connections, etc., with the entire set of containers denoted as I, and instantaneous rate samples for each container. (Such as the currently measured transmission rate or the peak / percentile rate within a specified statistical window), and the mapping relationship between container identifiers and IP addresses, etc. During the calculation, the controller initializes two container sets: an active container candidate set A(t) (shared bandwidth pool candidates) and a dedicated container set D(t) (containers with guaranteed bandwidth). Output: All the above raw metrics are collected, as well as the initial empty sets A(t) and D(t), for the next step of shared pool capacity calculation and demand assessment. This step provides a real-time data foundation, enabling the next step to perform bandwidth budgeting based on the latest link status and container traffic.

[0031] b) Shared / Dedicated Pool Budget The goal of this step is to calculate the bandwidth capacity available for sharing in the current period, based on link capacity and dedicated minimum bandwidth reservation. Inputs include: total link bandwidth capacity (denoted as...). The initial shared pool bandwidth is obtained by first subtracting the sum of the guaranteed bandwidths of all dedicated containers from the total link bandwidth. This is done along with the dedicated container set D(t) identified in the previous step and their respective guaranteed bandwidth values. . This indicates the dedicated minimum bandwidth for container i. The sum of the guaranteed bandwidth of all containers in the dedicated set D(t) is represented by the following formula. If the above calculations yield If a negative value occurs (e.g., the sum of dedicated minimum bandwidth exceeds the link capacity), then its lower limit is set to 0 (i.e., ...). (If the value is set to 0, it indicates that there is no remaining bandwidth available for sharing.) Output: Initial shared pool bandwidth. This result serves as the total shared bandwidth quota for subsequent bandwidth allocation, providing a total capacity constraint for the next step of allocating bandwidth shares to each container.

[0032] c) Demand estimation and activity assessment This step aims to assess the current bandwidth requirement of each container and determine the set A(t) of active containers participating in the shared scheduling. Inputs include: instantaneous rate samples for each container collected in step a. Metrics such as the number of active connections and information on the set of dedicated containers D(t) are used. For each container i, the controller uses a sliding window algorithm to exponentially smooth its bandwidth requirements, obtaining a smoothed requirement value. . This represents the estimated bandwidth requirement (i.e., the smoothed average rate) of container i at time t. The smoothing coefficient is (0-1). The calculation formula is as follows, which combines the current rate sample with the historical average weighted fusion: in This is the demand value calculated in the previous period. This represents the instantaneous rate monitored during this period. Through the above smoothing process, the impact of instantaneous bursts on demand estimation is weakened, resulting in a more robust demand metric. Next, based on the estimated demand and connection threshold, it is determined whether the container is actively participating in sharing: if the container mode is not dedicated (i.e., the mode is shared or hybrid) and its demand... Reaching a certain threshold (e.g., not lower than its minimum bandwidth) The appointment [Note: 1 / 6 is an empirical threshold, adjustable], or if its active connection count exceeds a preset threshold, the container is considered currently active and added to the active set A(t); simultaneously, all containers with dedicated minimum bandwidth (mode: dedicated or hybrid) are added to the dedicated set D(t) (used for dedicated bandwidth usage calculation). Output: Updated active container set A(t) and dedicated container set D(t), and estimated demand values ​​for all containers. These outputs will be used for subsequent weight adjustments and bandwidth allocation to ensure that the algorithm only allocates shared bandwidth to containers that currently have bandwidth requirements, while also considering the minimum requirements of containers with dedicated bandwidth.

[0033] d) Weight update The goal of this step is to dynamically adjust the bandwidth allocation weight for each active container. The algorithm comprehensively considers fairness among containers, current demand, and network congestion. Inputs include: the active set A(t) and the demand value of each container within it. Link congestion metrics (packet loss rate) Queue length ) and its preset threshold ( ), and the weight of container i in the previous iteration. and guaranteed bandwidth information First, calculate the normalized demand percentage of active containers. This is used to measure the relative demand intensity of each container. It represents the proportion of container i in the total demand of all active containers. This represents the sum of the demands of all containers in the active set. Calculation formula: when =0 =0; then iteratively update the weights according to the additive gain / multiplicative loss (AIMD) principle. The weight adjustment for each active container i is accumulated by the following terms: 1) Additive Gain: In the absence of congestion, the container weight is appropriately increased based on the proportion of demand to reward containers with higher bandwidth requirements. The increment is... . This is the additive gain coefficient, controlling the increase in magnitude, and ranging from 0.1 to 0.3. Calculation: .

[0034] 2) Packet loss feedback (multiplicative reduction): If a link packet loss rate is detected... Exceeding the threshold If congestion and packet loss occur, a congestion response is triggered, reducing the weights of all active containers by a multiplicative factor to quickly alleviate congestion. The reduction is proportional to the current weights. This is a factor to reduce the multiplicative effect of packet loss, with a value between 0.4 and 0.6 (e.g., ...). This means halving the weight. Calculation: If ,but .

[0035] 3) Queue feedback (linear decrease): If the average queue length Exceeding the threshold This also indicates that the link is showing signs of congestion. The weight is then linearly reduced based on the degree to which the threshold is exceeded. This is the queue length feedback coefficient, ranging from 0.01 to 0.03. Calculation: If The more the queue exceeds its limit, the greater the weight reduction.

[0036] 4) Guaranteed Bias: To ensure that containers with guaranteed bandwidth receive appropriate weight skew, this step introduces an additional bias adjustment term based on guaranteed bandwidth. When container i's guaranteed bandwidth... If there is remaining bandwidth relative to its current usage, its weight is increased; conversely, if its usage is already higher than the minimum required bandwidth, its weight can be decreased accordingly. The bias increment is calculated as the ratio of the difference between the container's minimum required bandwidth and its current bandwidth usage to the total link bandwidth, multiplied by a coefficient. .make This represents the bandwidth actually used by container i in the previous scheduling cycle (or the previously issued integer rate). This reflects the percentage of the container's guaranteed bandwidth that has not yet been fully utilized. The minimum offset coefficient is set between 0.1 and 0.3. Calculation: .

[0037] After completing the above adjustments, Limit to a preset minimum value and maximum value Within a certain range (avoiding excessively low weights leading to starvation or excessively high weights leading to monopolization). Output: Weights of each active container in the new cycle. Through this weight update mechanism, the algorithm adaptively adjusts resource allocation bias based on the growth / decrease in business demand and network congestion, providing a fair and dynamically adaptable weight benchmark for the next step of bandwidth share allocation.

[0038] e) Two-stage allocation of quotas This step involves allocating specific bandwidth quotas to active containers in two phases. The goal is to fairly share bandwidth according to weights while ensuring a minimum dedicated bandwidth requirement and fully utilizing unused bandwidth. Inputs include: the active set A(t) and its weights. The allocation includes information such as the dedicated pool D(t), guaranteed bandwidth, shared pool bandwidth, and the requirements and limits of each container. The allocation process strictly adheres to the principle of "dedicated pool priority, shared pool weighted allocation, and on-demand redistribution." Phase 0 (Dedicated Priority): First, consider the impact of dedicated minimum bandwidth on the shared pool. In the current period, unused minimum bandwidth from dedicated containers can be reclaimed for shared use. If some dedicated containers do not actually fully utilize their minimum bandwidth, this surplus bandwidth can be lent to other containers for sharing. Let the minimum bandwidth of container i be... The actual bandwidth used (demand) in this period is Then the minimum bandwidth was not used. The total amount of unused bandwidth from all dedicated containers is the total amount of reclaimable bandwidth. . This represents the minimum spare bandwidth of container i. This represents the sum of all unused guaranteed bandwidth in the dedicated pool. The shared pool bandwidth is then adjusted accordingly to obtain the effective shared pool bandwidth. The surplus term in the above formula will be used by the shared pool, ensuring that the effective shared pool has remaining bandwidth available for shared containers. Output: Updated effective shared pool bandwidth. This ensures that even if a dedicated container does not fully utilize its reserved bandwidth, other containers can temporarily use that bandwidth, thereby improving bandwidth utilization.

[0039] Phase 1 (Initial Allocation by Weight): After calculating the total available bandwidth, an initial bandwidth share is allocated to each container according to its weight percentage. Specifically, the sum of weights of the active set A(t) is calculated. Then distribute proportionally in, This represents the nominal bandwidth share allocated to container i according to its weight. The weight of container i in this period; This represents the sum of the weights of all active containers. Effective shared pool bandwidth; Through the above weighted fair sharing, each active container receives a bandwidth quota corresponding to its weight. Next, the initial share for each container will be... Compared to guaranteed bandwidth and configuration caps, determine the actual available first-round quota. Container i should at least obtain its guaranteed value. (like If the price falls below the guaranteed minimum, it will be raised to the guaranteed minimum, and will not exceed its maximum limit. At the same time, it cannot allocate more than its current needs. Therefore, the available bandwidth for container i in the first round is calculated as follows: The preset bandwidth limit for container i. The above calculations ensure that each container meets at least the minimum bandwidth requirement without exceeding its needs and the upper limit. Output: The first round of bandwidth allocation results for each container. Next, we analyze the resource usage after the first round of allocation: if the demand for container i is lower than its share (i.e., ... If it is, then it means that it has not used up the entire initial quota, and the unused portion is... This is recorded as surplus bandwidth; conversely, if... If the demand for this container is not yet fully met, it is added to the gap container set N for future replenishment. The total surplus bandwidth is denoted as: List the set of gap containers This completes the first round of quota allocation and surplus calculation.

[0040] Phase 2 – Secondary Allocation Based on Demand: This phase aims to redistribute the remaining surplus bandwidth L from the first round to containers (i.e., set N) that still have unmet needs, thereby improving bandwidth utilization and satisfaction rate. Specifically, surplus bandwidth is redistributed according to the weight proportion of the gapped containers. For each gapped container… Calculate its weight proportion in the gap set. Based on this, additional bandwidth can be obtained. in, The bandwidth that can be supplemented by the contents of the gap set, j; The weight of container j in the gap set; N: The sum of weights of all containers in the gap set N; L: The surplus bandwidth obtained after the first round of allocation.

[0041] Then limit the amount of replenishment to no more than the remaining bandwidth limit of the container. Actual supplement }.Will Added to the first round of quotas The final bandwidth quota for container j is obtained as follows: Calculate the replenishment allocation for all gap containers sequentially. If there is still unallocated bandwidth after one allocation (e.g., there is still bandwidth remaining even after all gap containers have reached their limits), iterate the above process until the remaining bandwidth is insufficient. (For very small capacities). In most scenarios, two rounds of allocation are sufficient to utilize the remaining bandwidth. After the second phase, surplus bandwidth is fully allocated to containers with real needs, allowing more bandwidth to be utilized. Output: Target bandwidth configuration for all active containers. This refers to the final bandwidth allocation for container i in this cycle. Through a two-stage allocation mechanism, this invention ensures the minimum bandwidth for critical containers while enabling fair competition among other containers based on their weights, and promptly reallocates unused bandwidth to maximize link bandwidth utilization.

[0042] f) Rate Smoothing: The goal of this step is to smooth out changes in control bandwidth allocation, avoiding frequent small fluctuations that lead to frequent policy deployments. Inputs include: the target bandwidth for each container calculated above. And the actual bandwidth control value issued to each container in the previous cycle (denoted as...). The controller uses preset smoothing coefficients and decision thresholds for each container i. For each container i, the controller calculates the new bandwidth value using an exponential smoothing algorithm. . This represents the smoothed bandwidth value that will be sent to container i. The smoothing coefficient is (0 to 1). For the scheduling period, This is the value issued by this container in the previous period. This smoothing calculation is equivalent to applying a first-order filter to the target bandwidth, ensuring that the new configuration does not abruptly change compared to the previous configuration. Next, we set the policy distribution threshold condition: only when the newly calculated... Compared to the previous value The change exceeds a certain threshold δ and the time since the last configuration issuance exceeds the minimum interval. Only then is it deemed necessary to issue a new strategy. δ represents the threshold for bandwidth variation. This is used to set a cooldown period for configuration updates, preventing excessively frequent configuration updates. Judgment: When... and (in When the container policy was last issued (the time elapsed), the flag `needPush=true` indicates that an update is needed; otherwise, the original policy remains unchanged. Output: Smoothed bandwidth value for each container. And the determination of whether an update needs to be issued. Through rate smoothing and threshold determination, it is ensured that configuration issuance is only triggered after a significant change in bandwidth allocation or after a certain period, thereby reducing unnecessary policy fluctuations. g) QoS policy generation This step transforms the bandwidth allocation results calculated by the algorithm into QoS rate limiting policies for actual devices and implements them atomically. Inputs include: the set of containers to be updated and their smoothed bandwidth values. This includes information on the QoS configuration interfaces supported by the device. For each container that needs to be distributed, the controller will... This is mapped to the committed bandwidth for the corresponding interface direction (such as the CIR value in the H3C firewall's CAR policy), and the corresponding token bucket parameters are calculated, such as Committed Burst (CBS) and Excess Burst (EBS). [Parameter Description] Typically, CBS can be calculated according to... Calculation (τ is the average burst duration), EBS can be taken as a multiple of CBS to allow for short-term over-limit. Calculation: For example, set CBS ≈ EBS≈ (k is a constant, such as 1 to 2). Subsequently, the controller generates a new QoS policy set containing all containers that need updating (including new CIR / CBS / EBS values ​​for each container), and atomically distributes it to network devices (such as firewall egress points) via a batch interface, ensuring all configurations take effect simultaneously and avoiding inconsistencies in intermediate states. Output: The updated bandwidth control policy on the device side (such as rate limiting entries for each container), starting to operate according to the new bandwidth cap. Traffic is scheduled and shaped. This completes the algorithm flow for one scheduling cycle, and the new bandwidth allocation strategy takes effect on the device. The result will be fed back for monitoring and weight adjustment in the next cycle, forming a closed-loop control system that continuously and dynamically optimizes bandwidth utilization and service quality.

[0043] The present invention also proposes a north-south bandwidth dynamic QoS control device for a multi-tenant intelligent computing center, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described above.

[0044] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A north-south bandwidth dynamic QoS control system for a multi-tenant intelligent computing center, characterized in that, It includes a policy control layer, a data acquisition and monitoring layer, an execution and forwarding layer, an interface adaptation layer, an identification and mapping layer, and a persistence and operation and maintenance layer; The policy control layer includes a policy controller and a policy engine. The policy controller aggregates network metric data from the entire network, and the policy engine calculates the minimum bandwidth, maximum bandwidth, and sharing ratio of containers based on a multi-dimensional weight model and AIMD smoothing algorithm, and generates a versioned QoS policy set. The multidimensional weight model is based on tenant weight w, business requirement r, and SLA priority p. sla The five-dimensional parameters are weighted: historical bandwidth h, congestion observation indicators, and q. The congestion observation indicators include: q, real-time queue length, p, and real-time packet loss rate. th Queue length threshold; p th Packet loss rate threshold, combined with AIMD additive increase and multiplicative decrease smoothing iterative calculation of minimum bandwidth, maximum bandwidth, and shared allocation ratio for each container; Each scheduling cycle generates a complete set of firewall CAR / MQC rate limiting configurations with version numbers based on real-time metrics, supporting canary batch deployment and version rollback, i.e., a versioned QoS policy set; The data acquisition and monitoring layer includes a monitoring probe, a firewall statistics interface, and an alarm triggering module. The monitoring probe periodically collects container-level traffic and link metrics, the firewall statistics interface obtains device-level metrics, and the alarm triggering module triggers emergency scheduling based on a preset threshold. The execution and forwarding layer includes a firewall scheduling module deployed on the egress data plane. The firewall scheduling module supports parallel scheduling of "dedicated bandwidth pool and shared bandwidth pool". The dedicated bandwidth pool allocates a minimum bandwidth to high-priority containers, and the shared bandwidth pool aggregates unused dedicated bandwidth and idle bandwidth and allocates them fairly according to weight. The interface adaptation layer includes an instruction conversion module and an atomic delivery module. The instruction conversion module maps the QoS policy set to the firewall's native commands, and the atomic delivery module uses a "begin-commit" transaction mechanism to deliver instructions in batches, automatically rolling back upon failure. The identification and mapping layer includes a container-IP mapping table and a NAT front traffic tagging module. The container-IP mapping table dynamically maintains the "tenant ID-container ID-IP" relationship, and the NAT front traffic tagging module adds custom tags to container packets to achieve traffic identification after NAT. The persistence and operation layer includes a policy repository, an audit and rollback module, and a canary release module. The policy repository stores historical data of policies and metrics. The audit and rollback module records operations and supports version backtracking. The canary release module pushes policies in batches. The data acquisition and monitoring layer collects metrics in real time and pushes them to the policy control layer; the policy engine calculates and generates versioned QoS policy sets and sends them to the interface adaptation layer to be converted into device instructions; the interface adaptation layer atomically sends them to the firewall scheduling module of the execution and forwarding layer for execution; the identification and mapping layer provides "container-IP" tagging and mapping support for the entire link; the persistence and operation and maintenance layer executes the full-process storage, auditing, and canary release policies, forming a complete closed loop of "collection-computation-transformation-deployment-execution-storage auditing".

2. The north-south bandwidth dynamic QoS control system for a multi-tenant intelligent computing center according to claim 1, characterized in that, The container-level traffic metrics include instantaneous rate, number of active connections, and traffic protocol type; the link metrics include bandwidth utilization, packet loss rate, and average queue length; the device-level metrics include ACL hit count, QoS queue status, and packet loss statistics; the preset thresholds of the alarm triggering module include packet loss rate p. th ≥1%, SLA priority p sla_th ≤0.5, average queue length q th ≥20 data packets.

3. The north-south bandwidth dynamic QoS control system for a multi-tenant intelligent computing center according to claim 1, characterized in that, The sharing modes of the firewall scheduling module include "per-address sharing" and "weighted fairness"; the per-address sharing mode is used when there is low tenant concurrency and stable business traffic; the weighted fairness sharing mode is switched to when there are many high-concurrency containers and link congestion scenarios; the firewall native commands include H3C NGFW's CAR rules and MQC policies.

4. A dynamic QoS control method for north-south bandwidth in a multi-tenant intelligent computing center, based on the system described in any one of claims 1-3, characterized in that, The process is executed cyclically within a fixed scheduling period Δt, including the following steps: Step 1: Metrics collection and preprocessing, obtaining the total link bandwidth C link Container instantaneous rate Congestion metrics and "container-IP" mapping relationships are defined, and the active container set A(t) and dedicated container set D(t) are initialized. Congestion metrics include two types of real-time monitoring metrics: link packet loss rate and average queue length. Step 2: Dedicated Bandwidth Pool / Shared Bandwidth Pool Bandwidth Budget, calculate the initial shared bandwidth pool bandwidth. ， Among them, C link Total link bandwidth, r min,i Guarantee minimum bandwidth for container i; This represents the sum of the guaranteed bandwidth of all containers in the dedicated set D(t); Reclaim unused bandwidth from dedicated containers Update the effective shared pool bandwidth. ;in, This represents the total amount of recyclable bandwidth. Step 3: Demand estimation and activity determination, using the exponential smoothing algorithm to calculate the smoothed demand for containers. Based on demand and connection thresholds, determine active containers and update A(t) and D(t); This is the smoothing coefficient, with a value between 0 and 1; This is the demand value calculated in the previous period; This refers to the instantaneous rate monitored during this period; Step 4: Dynamic weight update based on normalized demand ratio ,when =0 =0; Update container weights by combining additive gain, multiplicative loss, queue feedback, and guaranteed bias. (t) and restricted to [ , Within the specified range; when there is no network congestion, additive gain is applied to increase the weight of high-demand containers; when packet loss exceeds the threshold, multiplicative loss is applied to globally reduce the weight; when the queue overflows, queue feedback is applied to linearly reduce the weight; when the container's minimum bandwidth is not fully utilized, a minimum bias is applied to increase the weight; among these, This represents the sum of the demands of all containers in the active set; Step 5: Two-stage bandwidth quota allocation, Phase 1: initial share allocated according to weight. The first round of quota R is determined by combining the minimum guarantee, demand, and upper limit. i ; in This represents the nominal bandwidth share allocated to container i according to its weight. The weight of container i in this period; This represents the sum of the weights of all active containers. To effectively share pool bandwidth; Phase 2 allocates the surplus bandwidth L to the gap containers according to their weights, resulting in the final quota R. i (t); Step 6: Rate smoothing and policy distribution. The distribution bandwidth is obtained using an exponential smoothing algorithm. When the conditions for distribution are met, firewall instructions are generated and atomically distributed, and the effective status is verified. The exponential smoothing algorithm is a first-order exponential filter for bandwidth requirements, used to smooth out instantaneous traffic bursts.

5. The method for dynamic QoS control of north-south bandwidth in a multi-tenant intelligent computing center according to claim 4, characterized in that, The specific formula for weight update in step 4 includes: Additive gain: , where α is the additive coefficient, taking values ​​from 0.1 to 0.3; The normalized demand percentage for active containers; Multiplicative reduction: If ,but , where β is the multiplicative coefficient, with a value of 0.4-0.6; Queue feedback: If ,but ,in This is the queue coefficient, with a value ranging from 0.01 to 0.03; Minimum offset: Where γ is the bias coefficient, taking a value of 0.1-0.3; let This represents the bandwidth actually used by container i in the previous scheduling cycle or the integer rate issued in the previous cycle. This reflects the proportion of the container's guaranteed bandwidth that has not yet been fully utilized. Among them, packet loss rate p and packet loss threshold p th Real-time queue length q, queue threshold q th .

6. The method for dynamic QoS control of north-south bandwidth in a multi-tenant intelligent computing center according to claim 4, characterized in that, In step 5, the first round of quota R i The calculation formula is ,in The upper limit of container bandwidth; the surplus bandwidth Gap container set .

7. The method for dynamic QoS control of north-south bandwidth in a multi-tenant intelligent computing center according to claim 4, characterized in that, The bandwidth mentioned in step 6 The formula is ,in This represents the smoothed bandwidth value that will be sent to container i. The smoothing coefficient is 0 to 1. For the scheduling period, This is the value issued by the container in the previous period; the issuance condition is... and Where δ is the variation threshold and Thold is the cooling time. This is the time when the container policy was last issued.

8. A north-south bandwidth dynamic QoS control device for a multi-tenant intelligent computing center, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the method according to any one of claims 4-7.

Images