IP percentage scheduling-based CDN customer bandwidth precise traction method

Abstract

The application discloses a CDN customer bandwidth accurate traction method based on IP percentage scheduling and belongs to the technical field of Internet, and specifically comprises the following steps: calculating the scheduling proportion of domain name-region-IP granularity; acquiring the real-time bandwidth of domain name-region-IP granularity; designing a multi-batch bandwidth pre-deduction module for accurately calculating the scheduling bandwidth change of each round; designing an adaptive bandwidth effective module for preoccupying different bandwidth redundancies according to different domain names; and designing a multi-dimensional bandwidth bearing judgment module for finding the planned call-in IP satisfying the resource use rule according to the call-out bandwidth of domain name-region-IP granularity, judging the bearing capacity of each dimension machine of the planned call-in IP and finding the IP satisfying the bearing capacity requirements of each dimension machine for bandwidth traction. The application can more accurately traction bandwidth based on IP percentage scheduling, improves the service quality of users and reduces the CDN bandwidth and hardware cost.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of Internet, and particularly relates to a CDN customer bandwidth accurate traction method based on IP percentage scheduling. BACKGROUND

[0002] CDN (Content Delivery Network) is a network architecture for providing high-quality content distribution services. CDN stores content on servers close to users to improve content access speed and availability.

[0003] In the CDN network, one or more uplink IPs (exposed IP addresses of edge cache servers accessible to users) are generally used to serve customer bandwidth in the domain name (domain name that the customer needs to accelerate)-region (geographical location where the customer serves users, with operator granularity planning) granularity. IP is the finest unit of CDN bandwidth scheduling. One edge cache machine contains one or more uplink IPs. One edge node is composed of one or more edge cache machines. One edge machine room is composed of one or more edge nodes. IP percentage-based scheduling can achieve percentage-based traction of part of the bandwidth of the domain name-region-IP granularity to the eligible IP, and the scheduling is more refined. However, IP percentage scheduling may have different bandwidths in each round of scheduling, which requires real-time correction and higher judgment of the carrying capacity of the IP to be adjusted (including whether the bandwidth redundancy of the edge cache machine, the bandwidth redundancy of the edge node switch, and the bandwidth redundancy of the edge machine room switch are sufficient to carry). If the customer bandwidth traction is not accurate enough, it will affect the quality of service of the customer and cause customer complaints.

[0004] Therefore, it is necessary to provide a CDN customer bandwidth accurate traction method based on IP percentage scheduling, an electronic device, and a storage medium to improve the above situation. SUMMARY

[0005] The technical problem to be solved by the application is to provide a CDN customer bandwidth accurate traction method based on IP percentage scheduling to solve the problems of uneven server load, unstable network performance of user access, and difficulty in coping with burst traffic caused by inaccurate customer bandwidth traction in the background art. The method can accurately traction bandwidth based on IP percentage scheduling, improve user service quality, and reduce CDN bandwidth and hardware costs.

[0006] The application adopts the following technical solutions to solve the above technical problems:

[0007] The application discloses a CDN customer bandwidth precise traction method based on IP percentage scheduling, and specifically comprises the following steps.

[0008] Step S1: calculating a scheduling ratio of a domain name-region-IP granularity;

[0009] Step S2: acquiring real-time bandwidth of the domain name-region-IP granularity;

[0010] Step S3: designing a multi-batch bandwidth pre-deduction module for precisely calculating a scheduling bandwidth change amount of each round;

[0011] The step S3 specifically comprises the following steps.

[0012] Step S3-1: calculating a bandwidth scheduling ratio of the domain name-region-IP granularity every minute;

[0013] Step S3-2: calculating a current round of outgoing bandwidth according to the bandwidth scheduling ratio of the domain name-region-IP granularity and the real-time bandwidth, and the formula is as follows:

[0014] OutBw = OutRate * Bw

[0015] Wherein, OutRate represents the scheduling ratio of the domain name-region-IP granularity of the current round, Bw represents the real-time bandwidth of the domain name-region-IP granularity of the current round, and OutBw represents the outgoing bandwidth of the domain name-region-IP granularity calculated in the current round;

[0016] Step S3-3: statistically summing up outgoing bandwidths of previous rounds of the domain name-region-IP granularity;

[0017] Step S3-4: calculating a difference value between the outgoing bandwidth of the current round and the sum of the outgoing bandwidths of the previous rounds to generate an outgoing bandwidth change amount of the current round;

[0018] Step S3-5: storing the outgoing bandwidth change amount of the current round, namely, a bandwidth pre-deduction record;

[0019] Step S4: designing a self-adaptive bandwidth taking effect module for preoccupying different bandwidth redundancies according to different domain names;

[0020] In step S4, the self-adaptive bandwidth taking effect module specifically comprises the following steps.

[0021] Step S4-1: configuring a deployment taking effect time threshold value as T;

[0022] Step S4-2: calculating a bandwidth taking effect duration E of the domain name, wherein the bandwidth taking effect durations of different domain names are different, and the bandwidth taking effect durations of different domain names are calculated,

[0023] Step S4-3: According to the deployment effective time threshold T and the domain name bandwidth effective duration E, the bandwidth effective proportion of the traction bandwidth at each time is calculated, and the formula is as follows:

[0024]

[0025] Step S4-4: The change amount of the call-out bandwidth of the domain name-area-IP in each round is traversed, the un-effective bandwidth of the call-out bandwidth in each round is calculated according to the current time, and is converged to the IP granularity, for use of the subsequent multi-dimensional bandwidth bearing judgment module;

[0026] The step S4-2 specifically includes the following steps,

[0027] Step S4-2-1: Real-time traction bandwidth of the domain name-area-IP per minute is obtained;

[0028] Step S4-2-2: The difference between the start traction bandwidth time and the end traction bandwidth time is calculated, that is, the effective duration of the bandwidth traction this time;

[0029] Step S4-2-3: The effective duration of the bandwidth traction is taken as the mode and multiplied by the amplification factor R (the default configuration is 1.2), that is, the bandwidth effective duration E of the domain name;

[0030] Step S4-2-4: The default bandwidth effective duration is configured, and until the system can automatically calculate the bandwidth effective duration, the bandwidth effective duration E calculated by the system in real time is used.

[0031] Step S5: A multi-dimensional bandwidth bearing judgment module is designed, which is used for finding the planned call-in IP meeting the resource use rule according to the call-out bandwidth of the domain name-area-IP granularity, and judging the machine bearing capacity of the planned call-in IP in each dimension, including the cache server dimension, the edge node dimension and the edge machine room dimension, and finding the IP meeting the requirements of the machine bearing capacity in each dimension to perform bandwidth traction.

[0032] As a further preferred scheme of the CDN customer bandwidth accurate traction method based on IP percentage scheduling, in step S1, the scheduling proportion of the domain name-area-IP granularity is the bandwidth proportion of the IP needing to be traction in the domain name-area granularity, and the value range is between 0 and 100, 0 indicates that the bandwidth traction is not needed, and 100 indicates that the bandwidth of the IP in the domain name-area granularity needs to be traction to the call-in IP.

[0033] As a further preferred scheme of the CDN customer bandwidth accurate traction method based on IP percentage scheduling, in step S3-4, the change amount of the call-out bandwidth can be positive or negative, the positive number indicates that the bandwidth needing to be called out this round is more than before, and the negative number indicates that the bandwidth needing to be called out this round is less than before.

[0034] As a further preferred scheme of the CDN customer bandwidth precise traction method based on IP percentage scheduling of the present application, in step S3-5, the scheduling line of domain name-region-IP granularity is 100M, at 00 minute, the real-time bandwidth is 70M, which is lower than the scheduling line, thus no scheduling is needed, at this time, the bandwidth to be adjusted out is 0M;

[0035] At 01 minute, the real-time bandwidth is 120M, which is higher than the scheduling line, at this time, the bandwidth to be adjusted out is 20M, because it is the first round of adjustment, thus the total of the bandwidth to be adjusted out of the previous rounds is 0, and the pre-deduction record is +20M;

[0036] At 02 minute, the real-time bandwidth is 140M, at this time, the bandwidth to be adjusted out is 40M, 20M has been adjusted out at 01 minute, the pre-deduction record of this round is +20M;

[0037] At 03 minute, the real-time bandwidth is 150M, at this time, the bandwidth to be adjusted out is 50M, and the pre-deduction record is +10M;

[0038] At 04 minute, the real-time bandwidth is 140M, at this time, the bandwidth to be adjusted out is 40M, the total of the bandwidth to be adjusted out of the previous rounds is 50M, thus the pre-deduction record is -10M;

[0039] At 05 minute, the real-time bandwidth is 130M, at this time, the bandwidth to be adjusted out is 30M, and the pre-deduction record is -10M;

[0040] At 06 minute, the real-time bandwidth is 115M, the bandwidth to be adjusted out is 15M, and the pre-deduction record is -15M;

[0041] At 07 minute, the real-time bandwidth is 100M, no adjustment is needed, the bandwidth to be adjusted out is 0M, because the total of the bandwidth to be adjusted out of the previous rounds is 15M, the pre-deduction record is -15M.

[0042] As a further preferred scheme of the CDN customer bandwidth precise traction method based on IP percentage scheduling of the present application, in step S4-3, the deployment effective time threshold T is configured to be equal to 120 seconds, and the bandwidth effective duration E of the domain name is equal to 480 seconds, to obtain a bandwidth effective proportion trend chart, from which it can be seen that 0 to 120 seconds are within the deployment effective time, during which the bandwidth traction has not started, the bandwidth effective proportion is 0, and all the bandwidth redundancy needs to be preoccupied; 120 to 360 seconds, the bandwidth traction has started, but is relatively slow due to the influence of the cache time of LocalDns and the cache strategy of the domain name belonging to the business client and other factors, during which the bandwidth effective proportion is also low, and more bandwidth redundancy needs to be preoccupied; 360 to 600 seconds, during which the cache time of most LocalDns has expired, and will be re-requested, the bandwidth traction is relatively fast, until the completion of the whole traction.

[0043] As a further preferred scheme of the CDN customer bandwidth precise traction method based on IP percentage scheduling of the present application, in step S4-4, the bandwidth pre-deduction record of the planned incoming IP1 within the current time to the previous 10 minutes is planned, the bandwidth non-effective ratio within each minute from the current time to the previous 10 minutes is calculated according to the formula in step S4-3, and then the non-effective bandwidth at the current time in the previous round is calculated. The non-effective bandwidth is accumulated to obtain a value of 23.5M, which is the total amount of bandwidth that the planned incoming IP1 needs to pre-occupy at the current time.

[0044] As a further preferred scheme of the CDN customer bandwidth precise traction method based on IP percentage scheduling of the present application, the step S5 specifically comprises the following steps.

[0045] Step S5-1: Obtain the real-time bandwidth and rated bandwidth of the edge cache server of the planned incoming IP, obtain the non-effective bandwidth of all upflow IPs of the edge cache server, and calculate the bandwidth redundancy of the edge cache server at the current time, with the formula as follows:

[0046] BwRedu=RateBw-RealBw-sum(IPNotEffetBw)

[0047] Wherein, RateBw represents the rated bandwidth of the edge cache server, i.e. the maximum carrying bandwidth of the edge cache server; RealBw represents the real-time bandwidth of the edge cache server, i.e. the current bandwidth; IPNotEffectBw represents the non-effective bandwidth of a single upflow IP of the edge cache server; and BwRedu is the redundancy bandwidth of the edge cache server at the current time, i.e. the bandwidth that can be accepted.

[0048] Step S5-2: Determine whether the bandwidth redundancy of the edge cache server is greater than or equal to the traction bandwidth. If not, continue to check other planned incoming IPs that meet the resource use rules. If yes, continue to check whether the bandwidth redundancy of the edge node switch is sufficient.

[0049] Step S5-3: Obtain the real-time bandwidth and upper limit export bandwidth of the switch of the edge node to which the planned incoming IP meeting the bandwidth redundancy of the edge cache server belongs, obtain the non-effective bandwidth of all upflow IPs of the edge node, and calculate the bandwidth redundancy of the edge node at the current time, with the formula as follows:

[0050] BwRedu=UpOutBw-RealBw-sum(IPNotEffetBw)

[0051] Wherein, UpOutBw represents the upper limit export bandwidth of the edge node switch, that is, the maximum carrying bandwidth of the edge node; RealBw represents the real-time bandwidth of the edge node, that is, the current bandwidth; IPNotEffectBw represents the non-effective bandwidth of a single upflow IP under the edge node; and BwRedu is the redundancy bandwidth of the edge node at the current time, that is, the bandwidth amount that can be accepted.

[0052] Step S5-4: judging whether the bandwidth redundancy of the edge node is greater than or equal to the traction bandwidth, if not, continuing to check other planned incoming IPs that meet the resource use rules, and if yes, continuing to check whether the bandwidth redundancy of the edge node switch of the edge machine room is sufficient.

[0053] Step S5-5: obtaining the real-time bandwidth and the maximum transmission bandwidth of the switch of the edge machine room to which the planned incoming IP meeting the bandwidth redundancy of the edge node belongs, obtaining the non-effective bandwidth of all upflow IPs under the edge machine room, and calculating the bandwidth redundancy of the edge machine room at the current time, and the formula is as follows:

[0054] BwRedu = MaxTranBw - RealBw - sum (IPNotEffetBw)

[0055] In the above formula, MaxTranBw represents the maximum transmission bandwidth of the edge machine room switch, that is, the maximum carrying bandwidth of the edge machine room; RealBw represents the real-time bandwidth of the edge machine room, that is, the current bandwidth; IPNotEffectBw represents the non-effective bandwidth of a single upflow IP under the edge machine room; and BwRedu is the redundancy bandwidth of the edge machine room at the current time, that is, the bandwidth amount that can be accepted.

[0056] Step S5-6: judging whether the bandwidth redundancy of the edge machine room is greater than or equal to the traction bandwidth, if not, continuing to check other planned incoming IPs that meet the resource use rules, and if yes, selecting the IP as the final incoming IP, tractioning the bandwidth to the IP, and recording the bandwidth pre-deduction record for subsequent adaptive bandwidth effective module.

[0057] Compared with the prior art, the technical scheme has the following technical effects:

[0058] 1. The CDN customer bandwidth precise traction method based on IP percentage scheduling can more accurately traction the bandwidth based on IP percentage scheduling, improves the service quality of users, and reduces the CDN bandwidth and hardware cost.

[0059] 2、The application designs a multi-batch bandwidth pre-deduction module, which can accurately calculate and store the scheduling bandwidth change of domain name-region-IP granularity of each round, avoid too much bandwidth for the IP traction, cause the IP to exceed its own carrying capacity, and affect the service quality of the IP;

[0060] 3、The application designs a self-adaptive bandwidth effective module, which can calculate the bandwidth effective proportion according to different domain names, improve the node bandwidth utilization rate, and reduce the risk of affecting the IP;

[0061] 4、The application designs a multi-dimensional bandwidth carrying judgment module, which can judge the bandwidth redundancy of the cache server dimension, edge node dimension and edge room dimension of the planned IP that meets the resource use rules, and guarantee the bandwidth carrying of each dimension of the IP. BRIEF DESCRIPTION OF DRAWINGS

[0062] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0063] Figure 1 is the overall flowchart of the CDN customer bandwidth accurate traction method based on IP percentage scheduling of the application;

[0064] Figure 2 is the principle diagram of the multi-batch bandwidth pre-deduction module of the application;

[0065] Figure 3 is the domain name-region-IP real-time bandwidth trend chart of the application;

[0066] Figure 4 is the domain name-region-IP bandwidth pre-deduction record details of the application;

[0067] Figure 5 is the principle diagram of the self-adaptive bandwidth effective module of the application;

[0068] Figure 6 is the self-adaptive bandwidth effective proportion trend chart of the application;

[0069] Figure 7 is the un-effective bandwidth calculation information schematic diagram of the application;

[0070] Figure 8 is the principle diagram of the multi-dimensional bandwidth carrying judgment module of the application. DETAILED DESCRIPTION

[0071] The technical solutions of the present application will be further described in detail below with reference to the accompanying drawings:

[0072] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application. The purposes and effects of the present application will become more apparent below with reference to the accompanying drawings and preferred embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, and do not limit the present application.

[0073] Noun explanation:

[0074] Upstream IP: The IP address of the edge cache server exposed to the outside, which can be accessed by users to access content.

[0075] Edge cache server: a server located at the edge of the network, close to the end user, used to store and quickly provide commonly used network content or data. The edge cache server contains one or more upstream IPs.

[0076] Edge node: composed of one or more edge cache servers, is the upper planning of the edge cache server.

[0077] Edge room: composed of one or more edge nodes, is the upper planning of the edge node.

[0078] Region: the geographical location of the customer service user plus the granularity of the operator planning.

[0079] LocalDNS: an abbreviation for local domain name resolution system, which usually refers to a domain name resolution service located inside the user's computer or local area network. The main function of this service is to convert domain names into corresponding IP addresses, so that computers can connect to specific servers or websites through the network.

[0080] If the customer bandwidth traction is not accurate enough, it may cause a variety of problems and shortcomings, which may affect user experience and cost efficiency, mainly including the following aspects:

[0081] Uneven server load: inaccurate customer bandwidth traction may cause some edge nodes to be overloaded, while other nodes are relatively idle, wasting server resources, reducing the efficiency of CDN, and increasing bandwidth and hardware costs;

[0082] Unstable user experience: due to the inaccurate routing of user requests, users can experience unstable network performance. Some requests can be completed quickly, while others can take longer, and this inconsistency can affect the user's experience;

[0083] Difficulty in dealing with sudden traffic: if the CDN's bandwidth traction is not precise enough, it can be difficult to deal with sudden high traffic situations, such as large-scale access, which can lead to performance degradation or even service interruption.

[0084] To address the above problems, the present application provides a CDN customer bandwidth precise traction method based on IP percentage scheduling, electronic equipment and storage medium to improve the above situation.

[0085] In view of the deficiencies of the prior art, the present application aims to provide a CDN customer bandwidth precise traction method based on IP percentage scheduling, which is expected to be able to consider the bandwidth bearing of edge cache servers, edge nodes and edge machine rooms while fine-tuning the scheduling, to precisely traction customer bandwidth, improve user service quality and reduce CDN bandwidth and hardware costs.

[0086] To achieve the above purpose, the embodiment of the present application provides a CDN customer bandwidth precise traction method based on IP percentage scheduling, the system flow is as shown in Figure 1 The main steps include:

[0087] Step S1: calculating the scheduling ratio of domain name-region-IP granularity;

[0088] In implementation, the scheduling ratio of domain name-region-IP granularity is the bandwidth ratio of the IP that needs to be traction in this domain name-region granularity, the value range is between 0 and 100, 0 means no need to perform bandwidth traction, and 100 means that the bandwidth of the IP in this domain name-region granularity needs to be traction to the IP.

[0089] Step S2: obtaining the real-time bandwidth of domain name-region-IP granularity;

[0090] Step S3: a multi-batch bandwidth pre-deduction module is designed. Based on IP percentage scheduling, the scheduling ratio of the domain name-region-IP granularity is calculated every round, so a multi-batch bandwidth pre-deduction module is needed to accurately calculate the scheduling bandwidth change of each round, avoid traction too much bandwidth to the IP, cause the each dimension of the IP exceeds its bearing capacity, affect the service quality of the IP. A multi-batch bandwidth pre-deduction module is as shown in Figure 2 The main steps are as follows;

[0091] Step S3-1: calculating the bandwidth scheduling ratio of domain name-region-IP granularity every minute;

[0092] Step S3-2: Calculate the out bandwidth of this round according to the bandwidth scheduling ratio of domain name-area-IP granularity and real-time bandwidth, the formula is as follows:

[0093] OutBw=OutRate*Bw

[0094] In the above formula, OutRate represents the scheduling ratio of the domain name-area-IP granularity of this round, Bw represents the real-time bandwidth of the domain name-area-IP granularity of this round, and OutBw represents the out bandwidth of the domain name-area-IP granularity calculated in this round;

[0095] Step S3-3: Count the total of the out bandwidth of the previous rounds of the domain name-area-IP granularity;

[0096] Step S3-4: Calculate the difference between the out bandwidth of the current round and the total of the out bandwidth of the previous rounds to generate the out bandwidth change of this round. The out bandwidth change can be positive or negative, positive indicating that the bandwidth to be out in this round is more than before, and negative indicating that the bandwidth to be out in this round is less than before;

[0097] Step S3-5: Store the out bandwidth change of this round, i.e. the bandwidth pre-deduction record;

[0098] In implementation, as Figure 3 and Figure 4As shown, the scheduling line of domain name-area-IP granularity is 100M, at 00 minutes, the real-time bandwidth is 70M, which is lower than the scheduling line, so no scheduling is needed, and the bandwidth at this time is 0M; at 01 minute, the real-time bandwidth is 120M, which is higher than the scheduling line, so the bandwidth at this time is 20M, because it is the first round of bandwidth, the total bandwidth of the previous round is 0, and the pre-deduction record is +20M; at 02 minute, the real-time bandwidth is 140M, and the bandwidth at this time is 40M, because 20M has been scheduled at 01 minute, the pre-deduction record at this round is +20M; at 03 minute, the real-time bandwidth is 150M, and the bandwidth at this time is 50M, and the pre-deduction record is +10M; at 04 minute, the real-time bandwidth is 140M, and the bandwidth at this time is 40M, and the total bandwidth of the previous round is 50M, so the pre-deduction record is -10M; at 05 minute, the real-time bandwidth is 130M, and the bandwidth at this time is 30M, and the pre-deduction record is -10M; at 06 minute, the real-time bandwidth is 115M, and the bandwidth at this time is 15M, and the pre-deduction record is -15M; at 07 minute, the real-time bandwidth is 100M, and no scheduling is needed, and the bandwidth at this time is 0M, because the total bandwidth of the previous round is 15M, so the pre-deduction record is -15M. By calculating the scheduling bandwidth change of different rounds of real-time bandwidth and storing, the bandwidth pre-deduction record of each round can be calculated to have its own bandwidth effective proportion, which can more accurately fit the actual effect of bandwidth traction, which can avoid too much bandwidth from being scheduled to cause the scheduled IP to exceed its bandwidth carrying capacity and affect the service quality, and also does not need to pre-occupy too much bandwidth resource, which affects the bandwidth utilization of the node.

[0099] Step S4: An adaptive bandwidth effective module is designed. Bandwidth traction is not an instantaneous action, which is limited by factors such as cache time of LocalDns and cache strategy of domain name belonging to business client, and the bandwidth effective time of different domain names is also different. If the bandwidth redundancy of the scheduled IP is pre-occupied in a fixed time linear effective way, one is that too much bandwidth redundancy may be pre-occupied, which causes low bandwidth utilization of the scheduled node, and two is that too little bandwidth redundancy may be pre-occupied, which causes too much actual traction bandwidth and makes the scheduled IP overload, affecting the service quality of the scheduled IP.

[0100] Therefore, it is necessary to design an adaptive bandwidth effective module, which can pre-occupy different bandwidth redundancies according to different domain names, improve the bandwidth utilization of the node, and also reduce the risk of affecting the scheduled IP. An adaptive bandwidth effective module is as shown in Figure 5 The main steps are as follows.

[0101] Step S4-1: Configure the deployment effective time threshold value as T;

[0102] In implementation, the general decision system calculates the scheduling ratio of domain name-region-IP and pushes it to the DNS domain name resolution server, which consumes a certain amount of time, and during this time, the scheduling ratio has not yet taken effect, so the dimensional bandwidth redundancy of the scheduled IP needs to be completely reserved to avoid excessive bandwidth from causing the scheduled IP to overload.

[0103] Step S4-2: Calculate the bandwidth effective duration E of the domain name. The bandwidth effective duration of different domain names is not the same. The bandwidth effective duration of general download domain names is relatively short, and the bandwidth effective duration of on-demand domain names is relatively long, so it is necessary to calculate the bandwidth effective duration of each domain name. The main steps are as follows:

[0104] Step S4-2-1: Obtain the real-time traction bandwidth of domain name-region-IP per minute;

[0105] Step S4-2-2: Calculate the difference between the start bandwidth traction time and the end bandwidth traction time, which is the effective duration of this bandwidth traction;

[0106] Step S4-2-3: Take the mode of the effective duration of multiple bandwidth tractions and multiply it by the amplification factor R (default configuration is 1.2), which is the bandwidth effective duration E of the domain name;

[0107] In implementation, if the effective duration is configured too long, it will occupy the bandwidth redundancy of the scheduled IP for a long time, resulting in low bandwidth interest rate. If the effective duration is configured too short, the system considers that the bandwidth traction has been completed, but there is still part of the bandwidth that has not completed traction, which can easily cause the bandwidth of the scheduled IP to exceed the load. Therefore, taking the mode of the effective duration of multiple bandwidth tractions and multiplying it by the amplification factor R can meet most of the bandwidth tractions.

[0108] Step S4-2-4: For new domain names, it is not possible to obtain bandwidth traction data to calculate the bandwidth effective duration, so a default bandwidth effective duration needs to be configured until the system can automatically calculate the bandwidth effective duration, and then the bandwidth effective duration E calculated by the system is updated in real time;

[0109] Step S4-3: According to the deployment effective time threshold T and the domain name bandwidth effective duration E, calculate the bandwidth effective ratio of the traction bandwidth at each time, and the formula is as follows:

[0110]

[0111] In implementation, the deployment effective time threshold T is configured to be equal to 120 seconds, and the bandwidth effective duration E of the domain name is equal to 480 seconds. According to the above formula, the following can be obtained: Figure 6The bandwidth effective proportion trend chart is shown. It can be seen from the chart that 0-120 seconds are in the deployment effective time, during which the bandwidth traction has not started, so the bandwidth effective proportion is 0, and all the bandwidth redundancy needs to be preoccupied; 120-360 seconds, the bandwidth traction has started, but it is relatively slow due to the influence of the cache time of LocalDns and the cache strategy of the domain name belonging to the business client and other factors, during which the bandwidth effective proportion is also low, and more bandwidth redundancy needs to be preoccupied; 360-600 seconds, during which the cache time of most LocalDns has expired, and a new request is made, so the bandwidth traction is relatively fast until the traction is completed.

[0112] Step S4-4: The change amount of the called-out bandwidth of the domain name-region-IP is traversed each round, and the non-effective bandwidth of each round of the called-out bandwidth is calculated according to the current time and converged to the IP granularity for use by the subsequent multi-dimensional bandwidth bearing judgment module.

[0113] In implementation, as Figure 7 The bandwidth pre-deduction record of the planned call-in IP1 in the current time to the previous 10 minutes is shown. The bandwidth non-effective proportion of each minute from the current time to the previous 10 minutes is calculated according to the formula in step S4-3, and then the non-effective bandwidth of each round at the current time is calculated. The non-effective bandwidth is accumulated to obtain a value of 23.5M, which is the total amount of bandwidth that needs to be preoccupied by the planned call-in IP1 at the current time. This preoccupied bandwidth represents the bandwidth that has not yet taken effect but will be gradually pulled into effect in the future, which needs to be preoccupied in advance to avoid affecting the service quality of the call-in IP due to too much bandwidth.

[0114] Step S5: A multi-dimensional bandwidth bearing judgment module is designed, which finds the planned call-in IP that meets the resource use rules according to the called-out bandwidth of the domain name-region-IP granularity, and judges the machine bearing capacity of each dimension of the planned call-in IP (including the cache server dimension, the edge node dimension and the edge machine room dimension), and finds the IP whose machine bearing capacity of each dimension meets the requirements for bandwidth traction. A dimensional bandwidth bearing judgment module is shown as Figure 8 The main steps are as follows.

[0115] Step S5-1: The real-time bandwidth and rated bandwidth of the edge cache machine to which the planned call-in IP belongs are obtained, the non-effective bandwidth of all the uplink IP of the edge cache machine is obtained, and the bandwidth redundancy of the edge cache machine at the current time is calculated, and the formula is as follows:

[0116] BwRedu = RateBw - RealBw - sum(IPNotEffetBw)

[0117] In the above formula, RateBw represents the rated bandwidth of the edge cache machine, i.e., the maximum carrying bandwidth of the edge cache server. If the real-time bandwidth exceeds the rated bandwidth, the normal operation of the edge cache server will be affected. RealBw represents the real-time bandwidth of the edge cache server, i.e., the current bandwidth. IPNotEffectBw represents the non-effective bandwidth of a single upflow IP under the edge cache server (one edge cache server can contain one to multiple upflow IPs). BwRedu is the redundancy bandwidth of the edge cache server at the current time, i.e., the bandwidth amount that can still be accepted.

[0118] Step S5-2: Determine whether the bandwidth redundancy of the edge cache machine is greater than or equal to the traction bandwidth. If not, continue to check other planned incoming IPs that meet the resource use rules. If yes, continue to check whether the bandwidth redundancy of the edge node switch is sufficient.

[0119] Step S5-3: Obtain the real-time bandwidth and the upper limit export bandwidth of the switch of the edge node to which the planned incoming IP meeting the bandwidth redundancy of the edge cache server belongs, obtain the non-effective bandwidth of all upflow IPs under the edge node, and calculate the bandwidth redundancy of the edge node at the current time, according to the following formula:

[0120] BwRedu = UpOutBw - RealBw - sum(IPNotEffetBw)

[0121] In the above formula, UpOutBw represents the upper limit export bandwidth of the edge node switch, i.e., the maximum carrying bandwidth of the edge node. If the real-time bandwidth exceeds the upper limit export bandwidth, the normal operation of the edge node will be affected. RealBw represents the real-time bandwidth of the edge node, i.e., the current bandwidth. IPNotEffectBw represents the non-effective bandwidth of a single upflow IP under the edge node (one edge node can contain one to multiple edge cache servers). BwRedu is the redundancy bandwidth of the edge node at the current time, i.e., the bandwidth amount that can still be accepted.

[0122] Step S5-4: Determine whether the bandwidth redundancy of the edge node is greater than or equal to the traction bandwidth. If not, continue to check other planned incoming IPs that meet the resource use rules. If yes, continue to check whether the bandwidth redundancy of the edge machine room switch is sufficient.

[0123] Step S5-5: Obtain the real-time bandwidth and the maximum transmission bandwidth of the switch of the edge machine room to which the planned incoming IP meeting the bandwidth redundancy of the edge node belongs, obtain the non-effective bandwidth of all upflow IPs under the edge machine room, and calculate the bandwidth redundancy of the edge machine room at the current time, according to the following formula:

[0124] BwRedu = MaxTranBw - RealBw - sum(IPNotEffetBw)

[0125] In the above formula, MaxTranBw represents the maximum transmission bandwidth of the edge room switch, that is, the maximum carrying bandwidth of the edge room, and if the real-time bandwidth exceeds the maximum transmission bandwidth, the normal operation of the edge room will be affected; RealBw represents the real-time bandwidth of the edge room, that is, the current bandwidth; IPNotEffectBw represents the non-effective bandwidth of a single upstream flow IP under the edge room (one edge room can contain one to multiple edge nodes); and BwRedu is the redundancy bandwidth of the edge room at the current time, that is, the bandwidth amount that can be accepted.

[0126] Step S5-6: judging whether the bandwidth redundancy of the edge room is greater than or equal to the traction bandwidth, if not, continuing to verify other planned IP that meets the resource use rule, if yes, selecting the IP as the final IP to be introduced, and tracting the bandwidth to the IP, and recording the bandwidth pre-deduction record for subsequent adaptive bandwidth effective module.

[0127] The application designs an edge machine capacity bandwidth, which is obtained through domain name service bandwidth and domain name bandwidth coefficient convergence calculation, and can reflect the bandwidth carrying capacity of the edge machine more than the directly counted real-time bandwidth of the edge machine.

[0128] The application designs an edge machine dynamic rated bandwidth increasing method, when the edge machine capacity bandwidth approaches the rated bandwidth and the edge machine is healthy, gradually increasing the rated bandwidth of the edge machine, improving the bandwidth load to the maximum extent while ensuring the service quality, and improving the utilization rate of the edge machine.

[0129] The application designs an edge machine dynamic rated bandwidth decreasing method, when the edge machine is in a poor health state, gradually decreasing the rated bandwidth of the edge machine, and then tracting the capacity bandwidth to decrease, so as to restore the health state of the edge machine and improve the service quality.

[0130] Those skilled in the art can understand that the above description is only a preferred example of the application and is not used to limit the application, although the application is described in detail with reference to the foregoing examples, those skilled in the art can still modify the technical solutions recorded in the foregoing examples or make equivalent replacement for part of the technical features. Any modification, equivalent replacement, etc. made within the spirit and principle of the application should be included in the protection scope of the application. All technical features in the embodiments can be freely combined according to actual needs.

[0131] Finally, it should be noted that the above only describes the preferred embodiments of the present application and is not intended to limit the present application. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art will appreciate that the technical solutions described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalent features, and any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. An IP percentage-based scheduling CDN customer bandwidth accurate traction method, characterized in that: Specifically comprising the following steps: Step S1: calculating the scheduling ratio of domain-name-region-IP granularity; Step S2: obtaining the real-time bandwidth of domain-name-region-IP granularity; Step S3: designing a multi-batch bandwidth pre-deduction module for accurately calculating the scheduling bandwidth change of each round; The step S3 specifically comprises the following steps: Step S3-1: calculating the bandwidth scheduling ratio of domain-name-region-IP granularity every minute; Step S3-2: calculating the out-bandwidth of this round according to the bandwidth scheduling ratio and real-time bandwidth of domain-name-region-IP granularity, the formula is as follows: OutBw=OutRate*Bw Wherein, OutRate represents the scheduling ratio of domain-name-region-IP granularity of this round, Bw represents the real-time bandwidth of domain-name-region-IP granularity of this round, and OutBw represents the out-bandwidth of this round calculated for the domain-name-region-IP granularity; Step S3-3: counting the total of the out-bandwidth of the previous rounds of the domain-name-region-IP granularity; Step S3-4: calculating the difference between the out-bandwidth of the current round and the total of the out-bandwidth of the previous rounds to generate the out-bandwidth change of this round; Step S3-5: storing the out-bandwidth change of this round, that is, the bandwidth pre-deduction record; Step S4: designing an adaptive bandwidth effective module for preoccupying different bandwidth redundancies according to different domain names; In step S4, the adaptive bandwidth effective module specifically comprises the following steps: Step S4-1: configuring the deployment effective time threshold as T; Step S4-2: calculating the bandwidth effective duration E of the domain name, the bandwidth effective duration of different domain names is not the same, and the bandwidth effective duration of each domain name is calculated, Step S4-3: calculating the bandwidth effective ratio of the traction bandwidth at each time according to the deployment effective time threshold T and the domain name bandwidth effective duration E, the formula is as follows: Step S4-4: traversing the out-bandwidth change of domain-name-region-IP of each round, calculating the un-effective bandwidth of each round of out-bandwidth according to the current time and converging to the IP granularity for subsequent multi-dimensional bandwidth carrying judgment module; The step S4-2 specifically comprises the following steps, Step S4-2-1: obtaining the real-time traction bandwidth of domain-name-region-IP every minute; Step S4-2-2: counting the difference between the start traction bandwidth time and the end traction bandwidth time, that is, the effective duration of this bandwidth traction; Step S4-2-3: taking the mode of the effective duration of multiple bandwidth tractions and multiplying by the amplification factor R, that is, the bandwidth effective duration E of the domain name; Step S4-2-4: configuring the default bandwidth effective duration until the system can automatically calculate the bandwidth effective duration, and then using the real-time updated bandwidth effective duration E calculated by the system; Step S5: designing a multi-dimensional bandwidth carrying judgment module for finding the planned IP that meets the resource use rules according to the out-bandwidth of domain-name-region-IP granularity, and judging the carrying capacity of each dimension of the planned IP, including the cache server dimension, the edge node dimension and the edge room dimension, and finding the IP whose carrying capacity of each dimension meets the requirements for bandwidth traction.

2. The CDN customer bandwidth precise traction method based on IP percentage scheduling according to claim 1, characterized in that: In step S1, the scheduling ratio of the domain name-area-IP granularity is the proportion of bandwidth that needs to be pulled in this domain name-area granularity, and the value range is between 0 and 100, 0 indicating that no bandwidth pulling is needed, and 100 indicating that all the bandwidth of this domain name-area granularity needs to be pulled into the IP.

3. The CDN customer bandwidth precise traction method based on IP percentage scheduling according to claim 1, characterized in that: In step S3-4, the bandwidth change amount may be positive or negative, and the positive number indicates that the bandwidth to be pulled out is more than before, and the negative number indicates that the bandwidth to be pulled out is less than before.

4. The CDN customer bandwidth precise traction method based on IP percentage scheduling according to claim 1, characterized in that: In step S3-5, the scheduling line of the domain name-area-IP granularity is 100M, at 00 minutes, the real-time bandwidth is 70M, which is lower than the scheduling line, so no scheduling is needed, and the bandwidth to be pulled out is 0M at this time; At 01 minutes, the real-time bandwidth is 120M, which is higher than the scheduling line, so the bandwidth to be pulled out is 20M at this time, and because it is the first round of pulling out, the total of the bandwidth to be pulled out in the previous round is 0, and the pre-deduction record is +20M; At 02 minutes, the real-time bandwidth is 140M, and the bandwidth to be pulled out is 40M at this time, 20M has been pulled out at 01 minutes, and the pre-deduction record of this round is +20M; At 03 minutes, the real-time bandwidth is 150M, and the bandwidth to be pulled out is 50M at this time, and the pre-deduction record is +10M; At 04 minutes, the real-time bandwidth is 140M, and the bandwidth to be pulled out is 40M at this time, and the total of the bandwidth to be pulled out in the previous round is 50M, so the pre-deduction record is -10M; At 05 minutes, the real-time bandwidth is 130M, and the bandwidth to be pulled out is 30M at this time, and the pre-deduction record is -10M; At 06 minutes, the real-time bandwidth is 115M, and the bandwidth to be pulled out is 15M, and the pre-deduction record is -15M; At 07 minutes, the real-time bandwidth is 100M, and no bandwidth needs to be pulled out, and the bandwidth to be pulled out is 0M, and because the total of the bandwidth to be pulled out in the previous round is 15M, the pre-deduction record is -15M.

5. The CDN customer bandwidth precise traction method based on IP percentage scheduling according to claim 1, characterized in that: In step S4-3, the deployment effective time threshold T is configured to be equal to 120 seconds, and the bandwidth effective duration E of the domain name is equal to 480 seconds, and the bandwidth effective proportion trend chart is obtained, and it can be seen from the chart that 0 to 120 seconds are within the deployment effective time, during which the bandwidth pulling has not started, the bandwidth effective proportion is 0, and all the bandwidth redundancy needs to be preoccupied; 120 to 360 seconds, the bandwidth pulling has started, but is relatively slow due to the influence of the cache time of LocalDns and the cache strategy of the business client to which the domain name belongs and other factors, during which the bandwidth effective proportion is also low, and more bandwidth redundancy needs to be preoccupied; 360 to 600 seconds, during which the cache time of most LocalDns has expired, and a request will be re-sent, and the bandwidth pulling is relatively fast until it is completed.

6. The CDN customer bandwidth precise traction method based on IP percentage scheduling according to claim 1, characterized in that: In step S4-4, the bandwidth pre-deduction record of the planned IP1 within the current time to the previous 10 minutes is planned, the bandwidth non-effective proportion of each minute within the current time to the previous 10 minutes is calculated according to the formula in step S4-3, and then the non-effective bandwidth at the current time of each round is calculated, and the non-effective bandwidth is accumulated to obtain a value of 23.5M, which is the total amount of bandwidth that needs to be preoccupied by the planned IP1 at the current time.

7. The CDN customer bandwidth precise traction method based on IP percentage scheduling according to claim 1, characterized in that: The step S5 specifically comprises the following steps; Step S5-1: Obtain the real-time bandwidth and rated bandwidth of the edge cache machine to which the scheduled IP belongs, obtain the non-effective bandwidth of all upflow IP of the edge cache machine, and calculate the bandwidth redundancy of the edge cache machine at the current time, as follows: BwRedu = RateBw - RealBw - sum(IPNotEffectBw) wherein, RateBw represents the rated bandwidth of the edge cache machine, i.e. the maximum carrying bandwidth of the edge cache server; RealBw represents the real-time bandwidth of the edge cache server, i.e. the current bandwidth; IPNotEffectBw represents the non-effective bandwidth of a single upflow IP of the edge cache server; and BwRedu is the redundancy bandwidth of the edge cache server at the current time, i.e. the bandwidth that can be accepted; Step S5-2: Determine whether the bandwidth redundancy of the edge cache machine is greater than or equal to the traction bandwidth. If not, continue to verify other scheduled IP that meets the resource use rule. If yes, continue to verify whether the bandwidth redundancy of the edge node switch is sufficient; Step S5-3: Obtain the real-time bandwidth and upper limit export bandwidth of the switch of the edge node to which the scheduled IP belongs, obtain the non-effective bandwidth of all upflow IP of the edge node, and calculate the bandwidth redundancy of the edge node at the current time, as follows: BwRedu = UpOutBw - RealBw - sum(IPNotEffectBw) wherein, UpOutBw represents the upper limit export bandwidth of the edge node switch, i.e. the maximum carrying bandwidth of the edge node; RealBw represents the real-time bandwidth of the edge node, i.e. the current bandwidth; IPNotEffectBw represents the non-effective bandwidth of a single upflow IP of the edge node; and BwRedu is the redundancy bandwidth of the edge node at the current time, i.e. the bandwidth that can be accepted; Step S5-4: Determine whether the bandwidth redundancy of the edge node is greater than or equal to the traction bandwidth. If not, continue to verify other scheduled IP that meets the resource use rule. If yes, continue to verify whether the bandwidth redundancy of the edge machine room switch is sufficient; Step S5-5: Obtain the real-time bandwidth and maximum transmission bandwidth of the switch of the edge machine room to which the scheduled IP belongs, obtain the non-effective bandwidth of all upflow IP of the edge machine room, and calculate the bandwidth redundancy of the edge machine room at the current time, as follows: BwRedu = MaxTranBw - RealBw - sum(IPNotEffectBw) In the above formula, MaxTranBw represents the maximum transmission bandwidth of the edge machine room switch, i.e. the maximum carrying bandwidth of the edge machine room; RealBw represents the real-time bandwidth of the edge machine room, i.e. the current bandwidth; IPNotEffectBw represents the non-effective bandwidth of a single upflow IP of the edge machine room; and BwRedu is the redundancy bandwidth of the edge machine room at the current time, i.e. the bandwidth that can be accepted; Step S5-6: judging whether the bandwidth redundancy of the edge machine room is greater than or equal to the traction bandwidth, if not, continuing to check other IP meeting the resource use rule, if yes, selecting the IP as the final incoming IP, and recording the bandwidth pre-deduction record for the subsequent adaptive bandwidth validation module.

Images