Multi-level quota management system, method and device

Abstract

The invention relates to the field of quota management, in particular to a multi-level quota management system, method and device. The system comprises multiple stages of quota management nodes, when a cloud service wants to apply for a new resource, the cloud service sends a resource request to a cloud service deployment module, the cloud service deployment module firstly finds a first quota management node corresponding to the cloud service, and sends a resource request to the first quota management node; and the first quota management node also sends a resource request to the upper-layer quota management node, and after the first quota management node receives an agreement request of the upper-layer quota management node, the first quota management node sends a deployment agreement instruction to the cloud service deployment module.

Description

Technical Field

[0001] The present application relates to the field of resource management, and in particular to a multi-level quota management system, method and device. Background Art

[0002] With the development of computer science and technology, various manufacturers will provide users with a variety of services. Among them, some services can open up some physical or virtual resources for users, and the resources may be free or paid.

[0003] Therefore, all kinds of existing manufacturers will develop similar resource quota management systems, allowing services to apply to the quota management system before obtaining resources, and only after the system agrees can they obtain the corresponding requested resources. However, the traditional quota management system uses a unified quota management module, which makes it prone to single point failures and easily causes excessive load. Summary of the invention

[0004] The embodiment of the present application provides a multi-level quota management system, management method and device. Before each quota management node returns resource feedback to the cloud service deployment module, it first applies for resources from the parent node, so that the cloud service or cloud service deployment module only needs to interact with one quota management node to obtain the consent of multiple quota management nodes.

[0005] In a first aspect, a resource management method is provided, characterized in that a quota management system manages cloud computing resources for deploying cloud services, the cloud computing resources are provided by multiple servers, the quota management system includes a multi-level quota management node, the multi-level quota management node includes a plurality of first quota management nodes and a parent node of the first quota management node, the method includes:

[0006] The cloud service deployment module receives a request to deploy a cloud service;

[0007] The cloud service deployment module determines an Internet Protocol IP address of the first quota management node;

[0008] The cloud service deployment module sends a resource application request to the first quota management node according to the IP address of the first quota management node, where the resource application request carries a target resource quota of cloud computing resources required for deploying the cloud service;

[0009] The first quota management node applies for the cloud computing resources of the target resource quota from a parent node of the first quota management node;

[0010] The first quota management node receives feedback from the parent node;

[0011] If the feedback is approval of the application, the first quota management node provides the cloud service deployment module with the cloud computing resources of the target resource quota;

[0012] The cloud service deployment module deploys the cloud service using the cloud computing resources of the target resource quota.

[0013] In this implementation, by arranging quota management nodes in a hierarchical manner, a cloud service or cloud service deployment module only needs to be connected to one leaf node (the first quota management boundary). By transmitting information from the leaf node to the superior node, all superior nodes can be contacted at the same time, thereby reducing the number of service interfaces, lowering development difficulty, and improving development efficiency.

[0014] In a possible implementation manner, if the feedback is that the application is not approved, the first quota management node feeds back the application result to the cloud service deployment module.

[0015] In this implementation, if the feedback result of the upper node is a disagreement or rejection instruction, it means that although the first quota node may have sufficient quota, the quota of the upper node is insufficient, so the relevant resources should not be opened for the cloud service.

[0016] In a possible implementation, the quota amount of at least one quota management node is smaller than the sum of the quota amounts of all its child nodes.

[0017] In this implementation, the quota management system adopts an over-allocation quota management method, which is the core quota method in the quota management system. Using the over-allocation quota management method can improve the resource utilization efficiency of the quota management system and reduce operating costs.

[0018] In a possible implementation manner, the resource application includes a resource use application and / or a resource reservation application.

[0019] In this implementation, in addition to submitting an application for use when resources are actually needed, you can also issue a resource reservation request in advance for resources that may be used by important future businesses to prevent resources from being preempted.

[0020] In a possible implementation, the quota management node and service are configured with a corresponding cache layer.

[0021] In this implementation, each quota management node and service can cache relevant information in the cache layer to reduce the number of requests and queries to the parent node, reduce the operating pressure of the entire quota management system, and improve the availability of the system.

[0022] In a possible implementation, the cache layer of the service includes address information of its corresponding quota management leaf node.

[0023] In this implementation, the service can query the address information of the corresponding quota management leaf node in the cache layer, and after determining the address information of the corresponding quota management leaf node, it can send a corresponding request to the leaf node. Only when the address information of the corresponding leaf node is not found in the cache layer, a query request for the address information of the leaf node is sent to the root node. This implementation reduces the frequency of the leaf node sending the query request for the address information of the leaf node to the root node, reduces the operating pressure of the system, and improves the availability of the system.

[0024] In a possible implementation manner, the cache layer of the quota management node includes the quota amount returned by its quota management parent node.

[0025] In this implementation, if the cache layer node of the quota management node contains the quota amount returned by its parent node,

[0026] In this implementation, the cloud service deployment module can first send a query request to the root node, obtain the next-level node corresponding to the root node and the cloud service, and then send a query request to the next-level node, and repeat this process until the first quota management node directly corresponding to the cloud service is found.

[0027] In the second aspect, a resource management system is provided, which is an implementation of the system in the first aspect and will not be described in detail here.

[0028] In a third aspect, a computing device cluster is provided, the computing device cluster comprising at least one computing device, each computing device comprising a processor and a memory;

[0029] The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 7.

[0030] In a fourth aspect, a computer program product comprising instructions is provided, wherein when the instructions are executed by a computing device cluster, the computing device cluster executes the method as described in any one of claims 1 to 7.

[0031] This implementation method is implemented by the computer program product of the second and third aspects, and will not be described in detail here.

[0032] In a fifth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 7. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 A schematic diagram of the structure of an existing quota management system provided in an embodiment of the present application;

[0034] Figure 2 A schematic diagram of the relationship between quota management nodes provided in an embodiment of the present application;

[0035] Figure 3 A schematic diagram of the structure of a multi-level quota management system provided in an embodiment of the present application;

[0036] Figure 4 A quota management method provided in an embodiment of the present application;

[0037] Figure 5 A leaf node query method provided in an embodiment of the present application;

[0038] Figure 6 A resource reservation method provided in an embodiment of the present application;

[0039] Figure 7 A second resource reservation method provided in an embodiment of the present application;

[0040] Figure 8 A resource utilization method provided in an embodiment of the present application;

[0041] Fig. 9 A resource query method provided in an embodiment of the present application;

[0042] Fig.10 The second resource query method provided in the embodiment of the present application;

[0043] Fig.11 A resource application method provided in an embodiment of the present application;

[0044] Fig.12 A schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0045] Fig.13 A schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0046] Fig.14 A schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application; DETAILED DESCRIPTION

[0047] The technical solutions in the embodiments of the present invention will be described below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments.

[0048] In the description of this specification, "one embodiment" or "some embodiments" etc. means that one or more embodiments of this specification include a specific feature, structure or characteristic described in conjunction with the embodiment. Therefore, the phrases "in one embodiment", "in some embodiments", "in a possible implementation", "in some other embodiments", "in some other embodiments", etc. appearing in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways.

[0049] In the description of this specification, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of this specification, "multiple" means two or more than two.

[0050] In the description of this specification, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "include", "comprises", "has" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0051] Resources: There is no limit to the types of resources. Anything that can be provided to users in the form of services, can be perceived by users, and can bring value to users can be called resources. For example, in cloud services, computing, storage, and network can all be considered resources. Cloud services can provide users with computing, storage, and network services of different levels and quantities of computing power, storage space, bandwidth, etc. according to customer needs. These types of services can be called resources.

[0052] Quota: In some resource-providing services or quota management nodes, the theoretical upper limit of resource usage allocated by the upper-level quota management node is called the quota of this user. The quota of the quota management node may not be the actual amount of resources. For example, Figure 3As shown, if quota management node 102 manages 500 units of quota in the resource pool. It over-allocates quota by 300 units to quota management node 103 and quota management node 106 respectively. At this time, the total quota of quota management node 103 and quota management node 106 is 600 units, which exceeds the quota of its parent node, quota management node 102 (500 units). If quota management node 106 applies to quota management node 102 for the use of 300 units of new resources, at this time, quota management node 102 has 200 units of quota remaining. However, at this time, the quota of quota management node 103 is still 300 units (because it has not applied for use), so at this time, the quota of quota management node 103 exceeds the actual number of resources in the resource pool. Quota can also be referred to as quota.

[0053] Over-allocation: In the process of resource allocation, since users usually do not use the full quota, in order to improve the efficiency of resource use, resource providers often provide users with resource quotas that exceed the actual amount they have. For example, when the resource type is storage resources, if the resource provider actually has 200 units of storage resources, it provides 100 units of quota to user A and 100 units of quota to user B. Under this quota method, although it can ensure that the quota received by each user is the real quota, in actual use, the resource utilization rate of the quota is often only 50%, resulting in only 100 units of the 200 units of storage resources actually provided by the resource provider being used, and 100 units of storage resources are idle, resulting in a waste of resources. At this time, the resource provider can provide user C with another 100 units of quota. Under the normal resource utilization rate of 50%, the actual resource usage is only 150 units. Although the total quota of users A, B, and C is 300 units, which exceeds the actual storage resources owned by the resource provider, the service can still be provided normally because users usually do not use the resources in full. This quota method that exceeds the actual quota of the resource provider is called over-allocation.

[0054] Over-provisioning error: refers to system confusion or errors caused by over-provisioning. For example, when the resource type is storage resources, if the resource provider actually has 200 units of storage resources, it provides 100 units of quota to user A and 100 units of quota to user B. Under this quota method, although it can ensure that the quota received by each user is the real quota, in actual use, the resource utilization rate of the quota is often only 50%, resulting in only 100 units of the 200 units of storage resources actually provided by the resource provider being used, and 100 units of storage resources are idle, resulting in a waste of resources. At this time, the resource provider will provide user C with 100 units of quota. Under the normal 50% resource utilization rate, the actual total resource usage is only 150 units. Although the total quota of users A, B, and C is 300 units, which exceeds the actual quota of 200 units actually owned by the resource provider, the service can still be provided normally. However, when the resource usage rate of user A and user B reaches 70%, that is, user A and user B both apply for and use 70 units of resources, the resource provider only has 60 units of quota remaining. At this time, although user C still has 100 units of quota, when user C applies for 70 units of resources, because the resource provider only has 60 units of resources remaining, user C's request is either rejected, or after obtaining approval, the relevant resources cannot be actually called, or the resources managed by other quota management nodes are forcibly called, causing confusion in the system management logic. This system error that cannot be actually called or forcibly called is called an over-allocation error.

[0055] Resource provider: refers to the entity that provides resources for rent or sale to users in the form of services, such as cloud service providers. Resources can be provided through the Internet or other means, and there is no restriction here. The following example takes cloud providers as the most common resource provider.

[0056] User: refers to the entity that rents or purchases resources from the resource provider. The purchased or rented resources can be provided to the entity in the form of services. In the cloud service scenario, the purchased or rented resources can be provided to the entity remotely through the network.

[0057] Cloud: A collection of hardware and software resources. It uses Internet technology to bring together huge and scalable IT capabilities (i.e. computing, storage, network, and other resources) and provide them to users as cloud services. Generally, a cloud has multiple regions in each country / region, each of which includes at least one data center, and each data center has hardware and software resources. Different cloud service providers have established different clouds, such as Huawei Cloud of Huawei and Azure Cloud of Microsoft. Different clouds provide users with resources (including computing, storage, network, applications, etc.) for rent in the form of cloud services. The scale of the cloud is dynamically scalable, and more resources can be gathered to meet the needs of the growth of applications and user scale. Cloud computing supports users to obtain cloud services in multiple locations and using multiple terminals. The hardware and software resources that support cloud services come from the cloud. Common cloud services include three types: infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). Among them, infrastructure services, including virtual machine computing services and data storage services, mainly provide hardware devices and other resources to users in the form of virtual machines / containers as services. Users can load and run their own applications through virtual machines or storage resources provided by cloud services. Platform services mainly enable developers to build and deploy their own applications on the infrastructure and operating environment provided by the cloud, and allow these applications to use the resources in the cloud infrastructure. Software services are some applications running in the cloud that are provided to users as services on demand, such as cloud voice transcription services and cloud face recognition services.

[0058] Quota management: Due to the limited nature of resources and other reasons, resource providers, such as cloud vendors, usually need to restrictively manage the resources used by users for services purchased or rented. The restrictive management behavior is called quota management. The matters subject to restrictive management are called quota management matters, which usually include whether the actual usage of resources exceeds the quota amount, whether the resource provider's inventory resources are insufficient, whether the user is in arrears, whether the user is in violation of the law, etc. Quota management behaviors can specifically include processing resource use applications (approval or rejection), issuing corresponding instructions to lower-level nodes, allocating new resources to cloud services, adjusting the quota amount of cloud services, directly calling corresponding new resources, etc.

[0059] Region: Region refers to the division of resource pools within the resource provider. The division can be based on different regions (such as South China and North China) or other methods. The purpose of the division can be based on the convenience of internal management or other purposes (for example, to ensure the quality of service, different regions are usually divided based on regions, and resources in different regions are allocated according to users in different regions). The different regions of major cloud service providers are generally far apart in geographical location (for example: a cloud service provider's North China region, South China region, and Western United States region, etc.).

[0060] Quota management node: The main function of the quota management node is to decide how to handle new resource usage applications for services based on the quota of the service. For example, it checks whether the resource usage of the service itself has reached the quota limit. If the quota limit has been reached, it means that the resource usage of the service has exceeded the maximum resource usage allocated to it, so negative measures such as rejection or non-response are taken for its resource call application.

[0061] Due to the limited nature of resources, quotas have become a common means for various resource providers to manage resource allocation. Quotas generally have the following benefits:

[0062] Protect resource providers. Without quota management, every user can use the resources provided by the resource provider without upper limit. Once encountering some malicious users, a small number of users may maliciously occupy a large amount of resources, which will affect the overall service provided by the resource provider and make other normal users unable to use its services normally.

[0063] Protect users. In some paid services, the billing model is often based on the amount of resources used, and users often have a certain financial budget for the upper limit of their resource usage. Without the quota function, users cannot accurately know the usage of their resources, or if they use too much quota due to negligence, they will suffer a lot of economic losses.

[0064] Based on the above reasons, quota management of resources has become a common management method used by various resource providers, especially in the field of cloud services. Major cloud service providers have used various same or different quota management methods.

[0065] Cloud service: The cloud service is the sum of resources and related programs provided by the cloud vendor to a user account in the form of services. The related programs are programs that enable users to actually control and use cloud service resources.

[0066] When a cloud service sends a new resource request to the quota management node, it means that a user applies for new resources for its cloud service to the quota management system.

[0067] The existing mainstream technical solutions are as follows:

[0068] like Figure 1 As shown, multiple services are connected to the same quota management node at the same time, and one quota management node uniformly manages the resource usage of all services.

[0069] The above prior art has the following disadvantages:

[0070] Single point failure is prone to occur because this configuration has only one quota management node. If this quota management node fails, all quota management services will fail. In the prior art, the quota management node needs to handle all quota management requests at the same time, which puts a heavy load on the service and is not conducive to service maintenance.

[0071] To solve the above problems, the present invention provides a multi-level quota management system, in which each quota management node is arranged in layers. To facilitate the description of the hierarchical relationship, the quota management nodes are divided into root nodes, parent nodes, child nodes, and leaf nodes according to their different levels in the system.

[0072] Multi-level quota management system: Each quota management node is no longer configured as an independent, parallel architecture. Instead, each quota management node is allocated to different upper and lower levels within the same system according to its management level. The higher the level, the fewer the number of quota management nodes, and the lower the level, the more the number of quota management nodes.

[0073] Root node: The root node refers to the quota management node at a higher or highest level in a multi-level quota management system.

[0074] Leaf node: A leaf node refers to a quota management node at a lower or lowest level in a multi-level quota management system, which can be directly connected to a service.

[0075] Parent node: The quota management node on the upper layer that manages a quota management node is called the parent node of this quota management node. The leaf node directly connected to the service can also be regarded as the parent node of the service. Figure 2 As shown, quota management node B is directly connected to quota management node C and is located at the upper layer of quota management node C, so quota management node B can be regarded as the parent node of quota management node C. Similarly, quota management node A is directly connected to quota management node B and is located at the upper layer of quota management node B, so quota management node A can be regarded as the parent node of quota management node B. Since quota management node C is at the bottom layer of this quota management system and is directly connected to cloud service D, quota management node C can be called a leaf node, and can also be called the parent node of cloud service D.

[0076] Subnode: The next-level quota management node managed by a quota management node is called the subnode of this quota management node. The service can be regarded as the quota management subnode of the leaf node directly connected to it. The quota management subnode can also be referred to as the subnode. For example, according to Figure 2 , quota management node B is directly connected to quota management node A and is located at the lower layer of quota management node A, so quota management node B can be regarded as a child node of quota management node A. Similarly, quota management node C is directly connected to quota management node B and is located at the lower layer of quota management node B, so quota management node C can be regarded as a child node of quota management node B. Since quota management node C is at the lowest layer of the quota management system and is directly connected to cloud service D, quota management node C can be called a leaf node, and cloud service D can be called a child node of quota management node C.

[0077] The following is a schematic diagram of the architecture of a multi-level quota management system. Figure 3 .

[0078] The quota management system is composed of four layers of quota management nodes, including root node 101, quota management node 102, quota management node 103, quota management node 106, leaf node 104, and leaf node 107. The above nodes are located at different levels of the quota management system and are connected in sequence, wherein the root node 101 is at the top level of the quota management system, and the leaf node 104 is at the bottom level of the quota management system and is directly connected to the cloud service 105.

[0079] Real resource quantity: The real remaining resource quantity in the region corresponding to the resource pool is the real resource quantity. Usually, the highest-level quota management node can know the real resource quantity of the resource pool. The real resource quantity can also be called the real quota amount.

[0080] In the case where over-allocation behavior is generally applicable, in order to improve resource utilization, each parent node may over-allocate resources to each child node, which makes the internal resources of each quota management node may not be the real allocable resources. Figure 3For example, if quota management node 102 has a resource quota of 500 units, it allocates 300 units of resources to each child node, quota management node 103 and quota management node 106 are both allocated 300 units of resources, and quota management node 103 allocates 200 units of resources to each child node, that is, leaf node 104 and leaf node 107 are both allocated 200 units of resources. If cloud service 105 sends a resource use application to leaf node 104, applying for the use of 200 units of resources, if leaf node 107 has already applied to quota management node 103 to use 200 units of resources, the quota remaining in leaf node 104 is actually only 100 units, which cannot meet the 200 units of resource use application. At the same time, if quota management node 106 has already applied to quota management node 102 for the use of 300 units of resources, plus leaf node 107 has applied to quota management node 102 for 200 units of resources through quota management node 103, then quota management node 102 actually has only 0 units of resources left, and cannot satisfy leaf node 104's 200-unit resource use application. Therefore, after cloud service 105 submits a resource use application to leaf node 104, leaf node 104 needs to forward the request to the superior node step by step until it obtains the consent instruction of each parent node, and then it can allocate the requested resources to cloud service 105. The following is a review method for new resource applications for cloud services:

[0081] In this implementation, when the cloud service 105 needs to expand its capacity, it can send a resource use application to the leaf node 104. After the leaf node 104 reviews the quota management matters it is responsible for, if it passes, it will continue to send a use application to its parent node, namely the quota management node 103. After the quota management node 103 reviews the quota management matters it is responsible for, if it passes, it will continue to send a use application to its parent node, namely the quota management node 102. This step is repeated until the root node 101. When the root node 101 receives the use application issued by the quota management node 102, it reviews it according to the quota management matters it is responsible for. If it passes, it will send an approval instruction to its child node, namely the quota management node 102. Otherwise, it will send a rejection instruction or not reply. When the quota management node 102 receives the approval instruction from the root node 101, it will continue to send an approval instruction to its child node, namely the quota management node 103. This step is repeated until the cloud service 105. Each child node will send a consent instruction to its next-level child node only after receiving the consent instruction from the parent node. In this way, the cloud service 105 only needs to connect to the leaf node 104, and can only issue a new resource usage application once to obtain the consent of all associated quota management nodes (root node 101, quota management node 102, quota management node 103, leaf node 104).

[0082] In this embodiment, each quota management node is set to send a consent instruction to its child node only after receiving the consent instruction from the parent node. This method effectively avoids the disadvantages caused by over-allocation in the hierarchical quota management system. Because if the leaf node 104 wants to send a consent instruction to the cloud service 105, it needs to obtain the consent instruction of the quota management node 103 first, but if the quota management node 103 wants to send a consent instruction to the leaf node 104, it first needs to obtain the consent instruction of the quota management node 102. Similarly, if you want to allocate resources to the cloud service 105, you first need to obtain the consent of each of its upper-level quota management nodes. Before each quota management upper-level node sends a consent instruction to its child node, it will review whether the quota amount it manages meets the new resource usage request. Only after each upper-level quota management node of the cloud service has passed the internal review, the cloud service 105 can receive the consent instruction of the leaf node 104. This avoids the situation where the child node has sufficient resources but the parent node does not have sufficient resources, but approves the resource usage application of the cloud service.

[0083] At the same time, in this implementation, since the cloud service 105 only needs to be connected to the leaf node 104, and does not need to be connected to the root node 101, the quota management node 102, and the quota management node 103, the number of development times of the docking API is greatly reduced, and there is no need to perform quota management within the cloud service 105, which simplifies the internal code of the cloud service 105, facilitates its internal maintenance, and increases development efficiency. At the same time, due to the use of a multi-level quota management system, even if a leaf node fails, it does not affect the normal business operation of other leaf nodes or other quota management nodes, which greatly reduces the probability of single point failures and improves the robustness of the system.

[0084] In a possible implementation, the cloud service 105 may also directly send a new resource usage application to the root node 101. After receiving the new resource usage application from the cloud service 105, the root node 101 sends an instruction to its child node, the quota management node 102, based on the result of its internal review. After receiving the instruction from its parent node, the root node 101, the quota management node 102 sends an instruction to its child node, the quota management node 103, based on the result of its internal review, and this step is repeated until the cloud service 105.

[0085] In this implementation, the process of transmitting the new resource use application upward step by step can be omitted, which alleviates the pressure of system operation and improves the overall operation efficiency of the quota management system.

[0086] Quota management information: information related to quota management matters. The quota management node can judge what action (agree or reject) to take for the new resource use application sent by the cloud service or the lower-level node based on this information. The quota management information includes the quota amount of each quota management node. For example, the quota management information of the quota management node includes the remaining quota of the area it is responsible for. The quota management node can judge whether it can meet the number of new resource use applications based on the number of remaining quotas (the judgment method can be, if the quota amount is greater than the new quota amount applied for, then agree, otherwise, reject), and make a corresponding response. If the child node has the quota management information of the parent node, it can make a judgment on behalf of the parent node to decide whether to agree to the new resource use application. After the child node makes a corresponding judgment based on the quota management information of the parent node, it is deemed to have received the corresponding instruction of the parent node. For example, when the child node reviews the new resource use application based on the quota management information of the parent node and the result is approval, it is deemed to have received the approval instruction of the parent node.

[0087] Review: The quota management node makes judgments and responds to new resource usage requests based on quota management information.

[0088] Internal review: refers to the behavior of each quota management node to judge and respond to new resource usage applications based on its own quota management information.

[0089] Instruction: Behavior and information that can execute or enable child nodes to execute corresponding quota management behaviors. For example, if the conclusion of the parent node's review is to agree to the child node's application for the use of new resources, the corresponding consent instruction will be issued to the child node. If the child node is also a quota management node, after receiving this consent instruction, the child node can issue a consent instruction to its next-level child node. If the child node is a cloud service, the cloud service can directly call the new resources it applied for. If the rejection behavior of a quota management node is set as: no response to the new resource application. The behavior of not responding to the new resource application can also be regarded as returning instructions to the child node. For example, if the parent node is a quota management node, and the conclusion of the parent node's review is to reject the child node's application for the use of new resources, the corresponding rejection information can be issued to the child node, or no response can be given to the child node's application for the use of new resources. Before receiving the consent information, the child node will not issue consent instructions to its next-level child node or execute the relevant quota management behaviors agreed to. In this way, sending a rejection message to a child node and not responding to a new resource usage request from a child node can achieve the same effect, so both can be regarded as sending relevant instructions to the child node.

[0090] In a possible implementation, each quota management node and cloud service may also have a corresponding cache layer, and the cache layer may cache the quota management information of its parent node.

[0091] In this implementation, after receiving a new resource usage application from a cloud service or child node, each quota management node reviews the quota management items for which it is responsible. If approved, it can first query the quota management information of its parent node in its cache layer. If it has this information, it will make the corresponding review on behalf of the parent node. If approved, it will issue a consent instruction to the subordinate child node or cloud service. For specific steps, see Figure 4 .

[0092] S101, the cloud service 105 sends a resource usage application to the leaf node 104.

[0093] S102, after receiving the resource use application of the child node and the leaf node 104 passes the internal review, it queries whether there is quota management information of the parent node in the cache layer.

[0094] S103, if the leaf node 104 cache layer has the quota management information of its parent node, namely the quota management node 103, then a corresponding review is made based on the quota management information of its parent node, and an instruction (agree or reject) is issued to its subordinate child node, namely the cloud service 105, based on the review result.

[0095] S104 , if the leaf node 104 does not have the quota management information of its parent node in the cache layer, it continues to transfer the resource usage application to its parent node, namely the quota management node 103 , as normal.

[0096] S105, after receiving the resource use application of the child node and after the quota management node 103 passes the internal review, it queries whether there is quota management information of the parent node in the cache layer.

[0097] S106, if the quota management node 103 has the quota management information of its parent node, namely the quota management node 102, in its cache layer, it makes a corresponding review based on the quota management information of its parent node, and issues an instruction (agree or reject) to its subordinate child node, namely the leaf node 104 according to the review result.

[0098] S107 , if the quota management node 103 does not have the quota management information of its parent node in the cache layer, it continues to transfer the resource usage application to its parent node, namely the quota management node 102 , as normal.

[0099] S108, after receiving the resource use application of the child node and after the quota management node 102 passes the internal review, it queries whether there is quota management information of the parent node in the cache layer.

[0100] S109, if the quota management node 102 has the quota management information of its parent node, i.e. the root node 101, in its cache layer, it makes a corresponding review based on the quota management information of its parent node, and issues an instruction (agree or reject) to its subordinate child node, i.e. the quota management node 103, based on the review result.

[0101] S110 , if the quota management node 102 does not have the quota management information of its parent node in the cache layer, it continues to transmit the resource usage application to its parent node, ie, the root node 101 , normally.

[0102] S111, after receiving the resource use application transmitted by the quota management node 102, the root node 101 conducts an internal review according to the quota management matters for which it is responsible.

[0103] S112, after completing the internal review, the root node 101 returns instructions to its child node, namely the quota management node 102, according to the review result.

[0104] S113 , after receiving the instruction returned by its parent node, namely the root node 101 , the quota management node 102 returns the instruction to its child node, namely the quota management node 103 .

[0105] S114 , after receiving the instruction returned by its parent node, namely the quota management node 102 , the quota management node 103 returns the instruction to its child node, namely the leaf node 104 .

[0106] S115 , after receiving the instruction returned by its parent node, namely the quota management node 103 , the leaf node 104 returns the instruction to its child node, namely the cloud service 105 .

[0107] It is worth noting that after receiving the instruction returned by the parent node or being deemed to have received the instruction returned by the parent node, the child node can directly execute the corresponding quota management behavior. For example, after the quota management node 103 receives the instruction returned by the quota management node 102 in S113 and queries the relevant quota management information of the parent node, i.e., the quota management node 102, from its own cache layer in S106 and makes relevant judgments on behalf of the parent node, it can execute step S114 and return relevant instructions to its child node, i.e., the leaf node 104.

[0108] In this implementation, by setting a corresponding cache layer for the quota management node, the cloud service does not need to obtain approval from all levels of nodes every time it passes new resource usage applications upward, which to a certain extent reduces the operating pressure of the entire quota management system.

[0109] In this implementation, since the child node may only need to obtain the consent of the parent node (reviewed on behalf of the parent node based on the quota management information of the parent node in the cache layer), without obtaining the consent of all upper-level nodes, over-allocation errors may occur. For example, if the quota amount of the leaf node 104 is 300 units, the quota amount of the quota management node 103 cached in the cache layer of the leaf node 104 is 200 units, and the quota amount of the quota management node 102 is 100 units. At this time, if the cloud service 105 issues a resource use application of 200 units to the leaf node 104, the leaf node 104 is reviewed and approved based on the quota amount of 300 units, and the quota amount of 200 units of the parent node, namely the quota management node 103 cached in the cache layer, is reviewed and approved, then the consent instruction is returned to the cloud service 105, but at this time the actual quota amount of the quota management node is only 100 units, so the cloud service 105 still cannot call the resource when it actually calls it, or the management logic of the entire quota management system is disrupted due to forced calling.

[0110] Therefore, the present invention provides a method that can improve the accuracy of child node cache information and avoid over-allocation errors in a multi-level quota management system with a cache layer. If the child node fails to find the quota management information of the parent node in the cache layer, it will pass a new resource application to the parent node, and can carry a resource query request at the same time. After the parent node makes a review based on the quota management matters, it returns an instruction to the child node, and the instruction can carry the quota management quota amount of the parent node. When the child node receives the quota management quota amount returned by the parent node, it stores the amount in the cache layer. If the parent node returns an instruction to the child node, and the parent node also caches the quota amount of its upper-level node, the quota amount carried by the instruction returned by the parent node to the child node can be a quota amount with a lower amount than the quota amount of the parent node and the quota amount of the upper-level node cached in the parent node. Next, Figure 4For example, assume that the quotas of leaf node 104, quota management node 103, quota management node 102, and root node 101 are 40 units, 30 units, 20 units, and 10 units, respectively. If quota management node 102 transmits a new resource usage application to root node 101, this application also carries a resource query request. After the root node 101 reviews the quota management matters, it returns an instruction to quota management node 102, which may carry the quota quantity of root node 101, 10 units. Quota management node 102 stores this quota in the cache layer. When quota management node 103 transmits a new resource use application to quota management node 102, the application also carries a resource query request. After the quota management node makes an examination based on its own quota quota of 20 units and the quota quota of 10 units in the cache layer, it returns an instruction to quota management node 103. The instruction may carry the quota quota of quota management node 102. At this time, there are two quota quotas inside quota management node 102: the quota quota of 20 units of quota management node 102 and the quota quota of 10 units cached in the cache layer and received from root node 101. The quota quota returned by quota management node 102 to quota management node 103 may be the quota quota with a lower amount compared with the above two quota quotas, that is, the quota quota of 10 units received from root node 101. Therefore, after the quota management node 103 receives the quota amount returned by the quota management secondary point 102, its quota amount is: 30 units of the quota management quantity of the quota management node 103, and 10 units of the quota amount queried from the quota management node 102. Similarly, the resource management quantity finally stored by the child node 104 is: 40 units of the quota management quantity of the child node 104, and 10 units of the quota amount cached in the cache layer and received from the quota management node 103. This method can ensure that the quota amount cached in the cache layer of the leaf node 104 is the lowest quota amount among all the upper nodes. It can ensure that the review results made based on this quota amount are credible.

[0111] At the same time, if the amount returned by the parent node to the subordinate node causes the subordinate node or any node below the subordinate node to eventually reach a conclusion of approving the resource activation application, the returned amount can also be regarded as returning an instruction of approval. Similarly, if the amount returned to the subordinate node eventually causes any lower-level node to make a judgment or instruction of rejection, it is regarded as the parent node returning an instruction of rejection.

[0112] In a possible implementation, the information returned by the parent node to the child node is: the parent node's own quota management information, and all quota management information received from the parent node's parent node's parent node. Figure 4For example, assume that the quotas of leaf node 104, quota management node 103, quota management node 102, and root node 101 are 40 units, 30 units, 20 units, and 10 units, respectively. Quota management node 102 internally manages its own quota management information of 20 units and the quota management information of root node 101 obtained from root node 101. If quota management node 103 requests quota management node 102 to return quota management information, quota management node 102 returns two quota management information of 20 units and 10 units to quota management node 103. Therefore, quota management node 103 internally has three quota management information: 30 units, 20 units, and 10 units. By analogy, the quota management information finally cached by leaf node 104 includes 40 units, 30 units, 20 units, and 10 units.

[0113] In a possible implementation, the data in the cache layer can be set to have a certain expiration time, and a resource query request needs to be re-issued to the parent node every time a period of time passes, so as to ensure the real-time nature of the cached data in the cache layer. Fig.10 Description.

[0114] Since users frequently apply for new cloud services and frequently shut down old cloud services, it is necessary to decouple cloud services from the quota management system. Therefore, it is a technical problem that needs to be solved to quickly and efficiently find the corresponding management leaf node for the newly generated cloud service. The following is a method for quickly finding the corresponding leaf node for the cloud service in the multi-level quota management system. Figure 5 .

[0115] S201, the cloud service 105 sends a leaf node query request to the root node 101.

[0116] S202, after receiving the query request from the cloud service 105, the root node 101 determines the corresponding child node, namely the quota management node 102, according to the information carried in the query request sent by the cloud service 105, and returns the address information of the corresponding child node, namely the quota management node 102.

[0117] S203 , the cloud service 105 sends a leaf node query request to the quota management node 102 according to the address information of the corresponding child node, ie, the quota management node 102 , returned by the root node 101 .

[0118] S204, after receiving the query request from the cloud service 105, the quota management node 102 determines the corresponding child node, namely the quota management node 103, according to the information carried in the request sent by the cloud service 105, and returns the address information of the corresponding child node, namely the quota management node 103.

[0119] S205 , the cloud service 105 sends a leaf node query request to the quota management node 103 according to the address information of the corresponding child node, ie, the quota management node 103 , returned by the quota management node 102 .

[0120] S206, after receiving the query request from the cloud service 105, the quota management node 103 determines the corresponding child node, namely the leaf node 104, according to the information carried in the request sent by the cloud service 105, and returns the address information of the corresponding child node, namely the leaf node 104.

[0121] S207 , the cloud service 105 completes the address query of the leaf node 104 .

[0122] In this implementation, the parent node knows the address information of all its child nodes. For example, the root node 101 knows the address information of the quota management node 102, but does not necessarily know the address information of the quota management node 103. However, the quota management node 102 should know the address information of the quota management node 103 because the quota management node 103 is a child node of the quota management node 102.

[0123] The address information may be address information of a quota management node, such as an IP address, or information generated according to other communication protocols and standards, which can be used to locate the location of the node through a network.

[0124] In this implementation, a trusted root node 101 may be set, and its address information should remain relatively stable to facilitate the newly generated cloud service to send a leaf node query request to it.

[0125] The query request should carry the attribution information of the cloud service 105, and the attribution information can enable the quota management node to distinguish its corresponding child node information. For example, when the root node 101 receives a leaf node query request from the cloud service 105, it may have multiple child nodes, including the child node corresponding to the cloud service 105, namely the quota management node 102, and the quota management node 10X (not marked in the figure) that does not correspond to the cloud service 105. The characteristic information should enable the root node 101 to identify the child node corresponding to the cloud service 105, namely the quota management node 102, and return the address information of the quota management node 102 to the cloud service 105.

[0126] According to the said attribution information, it can be some inherent characteristics of the service. For example, regional information can be used as a kind of attribution information. If the address of the cloud service is Longgang District, Longgang-Shenzhen-Guangdong-China can be used as the query basis for the characteristics. Resource type can also be used as a kind of inherent information. If the resource applied for by the cloud service is a container, computing resources-non-bare metal computing resources-container can be used as the query information for attribution. Here, the setting method of the characteristics of the regional information carried in the query request is taken as an example:

[0127] The attribution information is set according to the regional information of the service: the regional information is the region where the newly generated cloud service is located. Correspondingly, the quota management node uses the regional information as a distinction. For example, assuming that the leaf node 104, the quota management node 103, the quota management node 102, and the root node 101 are the quota management nodes of Longgang District, Shenzhen City, Shenzhen City, Guangdong Province, and China, respectively, and are responsible for the quota management matters of the above regions. When the cloud service 105 from Longgang District sends a leaf node query request to the root node 101 in China, the root node 101 can query its corresponding lower-level child node, that is, the quota management node 102 responsible for the quota management matters of Guangdong Province, according to the characteristic information (Longgang District) carried by the query request. The query method can be that each quota management node is internally configured with an attribution information correspondence table, and the characteristic correspondence table records the corresponding rules of various attribution relationship correspondence information and quota management nodes. For example, when the characteristic information is "Longgang District", the attribution correspondence table should record the corresponding relationship of "Longgang-Shenzhen-Guangdong-China" for the quota management node to determine the child node corresponding to the cloud service.

[0128] In addition, the attribution information content may also be manually set attribution information. Here is an example of a manually set cloud service name:

[0129] Set identification feature information according to namespace information: that is, when generating a new cloud service, name the cloud service in a planned manner, and the planned naming should enable the quota management node to directly determine its corresponding child node based on its naming content. For example, the naming content of the new cloud service can be: "root node 101 / quota management node 102 / quota management node 103 / leaf node 104", where the " / " sign is used as the dividing mark between the parent node and the child node. In this way, when the cloud service 105 sends a leaf node query request to the root node 101, the root node 101 can identify its corresponding child node as the quota management node 102 based on the content of its name, and return the address information of the quota management node 102 to the cloud service 105 accordingly. The namespace information can be obtained through calculation. For example, if a user applies to use 100 units of storage resources in Longgang, the cloud service can calculate the naming rule "China / Guangdong / Shenzhen / Longgang / Storage / Storage within 500 units" based on this information. The naming rule can be set according to the specific needs of each quota management node, and the present invention does not make any specific limitation on it.

[0130] In one possible implementation, there is a certain interval between the application for the use of new resources issued by the cloud service and the actual use of the resources, so the present invention provides a resource allocation method of first booking and then using. This method can effectively ensure that the activation of resources and the consumption of quotas are the same thing, ensure the logical consistency within the quota management system, and also provide a basis for the implementation of some other requirements (booking). For the booking behavior, it can be specifically divided into two methods: "real-time booking" and "reserved booking". The real-time booking means that each quota management node will pass the booking request received from the child node to the parent node in real time. According to the CAP principle, the availability of the quota management system using real-time booking will be reduced, and the corresponding response delay will increase, which increases the pressure on the server.

[0131] CAP principle: also known as the CAP theorem, refers to the fact that in a distributed system, consistency, availability, and partition tolerance can only achieve two of these three elements at the same time, and it is impossible to achieve all three at the same time. Figure 6 Describe the specific process of real-time booking in a multi-level quota management system:

[0132] S301, the cloud service 105 sends a resource reservation request to the leaf node 104, where the reservation request includes the type and quantity of the reserved resources.

[0133] S302, after receiving the resource reservation request from the cloud service 105, the leaf node 104 reserves the corresponding resources within the node according to the content of the request.

[0134] S303 , after reserving the corresponding resources inside the node, the leaf node 104 sends a resource reservation request for the cloud service 105 to its parent node, namely the quota management node 103 .

[0135] S304, after receiving the resource reservation request from the cloud service 105, the quota management node 103 reserves corresponding resources within the node.

[0136] S305 , after reserving the corresponding resources inside the node, the quota management node 103 sends a resource reservation request for the cloud service 105 to its parent node, namely the quota management node 102 .

[0137] S306 , after receiving the resource reservation request from the cloud service 105 , the quota management node 102 reserves corresponding resources within the node.

[0138] S307 , after reserving the corresponding resources within the node, the quota management node 102 sends a resource reservation request for the cloud service 105 to its parent node, namely the root node 101 .

[0139] S308 , after receiving the resource reservation request from the cloud service 105 , the root node 101 reserves corresponding resources within the node.

[0140] S309, after the root node 101 reserves the corresponding resources inside the node, it sends a reservation success instruction to its child nodes.

[0141] S310, after receiving the reservation success instruction returned by the parent node, the quota management node 102 sends a reservation success instruction to its child node.

[0142] S311, after receiving the reservation success instruction returned by the parent node, the quota management node 103 sends a reservation success instruction to its child node.

[0143] S312 , after receiving the reservation success instruction returned by the parent node, the leaf node 104 sends a reservation success instruction to its child node, namely the cloud service 105 .

[0144] Before reserving the corresponding resources within the node, each quota management node can first review whether it can reserve the relevant resources for the cloud service 105 according to the quota management information within the node. When the review is passed, the resource reservation request for the cloud service 105 is sent to the parent node. When the review is not passed, a rejection instruction can be directly sent to the child node. When all quota management nodes have passed the internal review and reserved the corresponding resources internally, the root node 101 transmits the reservation success instruction downward step by step until the cloud service 105.

[0145] The implementation logic of the predetermined behavior is that when the quota management node receives the reservation application of the child node, it internally reviews the quota management matters it is responsible for (for example, whether the quota amount is sufficient). If the reservation application of the child node is approved, the corresponding quota amount is deducted internally, and the reservation information is placed in the cache layer, waiting for the child node to issue an actual call application. The reservation information is to agree to the quota amount reserved by the child node. For example, if the quota amounts owned by the leaf node 104, the quota management node 103, the quota management node 102, and the root node 101 are 100 units, 100 units, 90 units, and 80 units respectively. When the cloud service 105 sends a reservation request for 50 units of resources to the leaf node 104, the leaf node first internally reviews whether the quota amount is sufficient. After the review is passed, the quota amount of 50 units is deducted internally, and the resource application is passed to the parent node. This behavior is repeated to the root node 101. After the reservation is completed, the quota amount of each node becomes 50 units, 50 units, 40 units, and 30 units. If cloud service 101 applies to reserve 40 units of resources again at this time, its new resource reservation application will be rejected when it is transmitted to root node 101 because root node 101 no longer has sufficient quota, resulting in reservation failure. At the same time, the 40 units of resources that have been deducted by the lower-level quota management nodes are returned to the quota management nodes, waiting for the next reservation.

[0146] In a possible implementation, all reservations can be set with an expiration time. The expiration time is that after the predetermined time, if the cloud service does not actually call the reserved resources, or does not receive the reservation success instruction returned by the parent node, the reservation automatically expires and the reserved resources return to the resource pool. The resource pool is the quota amount that can be called or reserved by each quota management node.

[0147] In a possible implementation, the expiration time of the resources reserved by the parent node is set to be later than the expiration time of the resources reserved by its child node. In this implementation, the availability of the system can be ensured to prevent the cloud service from requesting the child node to actually call the resource, but the child node agrees to the relevant call, but the parent node has already returned the reserved resource to the resource pool.

[0148] Although the quota management system using real-time reservation has high consistency, its availability is low. In some businesses with low consistency requirements, the reserved reservation method can also be used to improve the availability of the quota management system and reduce the system's operating delay.

[0149] In the quota management system that implements the reservation method, each quota management node can proactively send a resource reservation request to the parent node in advance without receiving a cloud service resource reservation application. If the parent node agrees to the resource reservation application, then within the agreed quantity range, for subsequent related resource reservation applications of the child node, the quota management node is deemed to have received the parent node's consent instruction and can directly return the consent instruction to the child node. For example, if the quota amount of leaf node 104 is 300 units, it can actively send a resource reservation application of 200 units to quota management node 103. If the quota management node 103 agrees, the data of 200 units of quota will be placed in the cache layer. If cloud service 105 sends a resource reservation request of 50 units to leaf node 104 at this time, because 50 units < 200 units and 50 units < 300 units, leaf node 103 can directly agree to the resource reservation application of cloud service 105 without sending another request to quota management leaf node 103, and deduct 50 units from each quota amount internally, that is, the remaining quota amount of itself is 250 units and the quota amount of the parent node is 150 units.

[0150] In this implementation, the pressure on the quota management node 103 can be greatly reduced, because each time the leaf node 104 can reserve a large amount of resources at one time, and after reaching the reservation condition, the leaf node will send a second reservation request, which greatly reduces the frequency of the quota management node 103 receiving reservation requests. Of course, if the pressure on the quota management node 102 is relatively large in actual operation, the quota management node 103 can also adopt the reservation logic of the leaf node 104, and even each quota management node in the entire quota management system can execute this method to relieve the operation pressure of the entire system.

[0151] Combine the following Figure 7 Describe the specific process of reservation in a multi-level quota management system:

[0152] S401, the cloud service 105 sends a resource reservation request to the leaf node 104, wherein the resource reservation request includes the type and quantity of the requested reserved resources.

[0153] S402, after receiving the resource reservation request from the cloud service 105, the leaf node 104 reserves the relevant resources internally.

[0154] S403, after successfully reserving related resources internally, the leaf node 104 returns a reservation success instruction to the cloud service 105.

[0155] S404, after the reservation condition is met, the leaf node 104 actively sends a resource reservation request to its parent node, namely the quota management node 103, and the request may include the type and quantity of the requested reserved resources.

[0156] S405: After receiving the resource reservation request from the child node, the quota management node 103 reserves relevant resources internally.

[0157] S406, after successfully reserving the relevant resources internally, the quota management node 103 returns a reservation success instruction to the leaf node 104.

[0158] S407, after the predetermined conditions are met, the quota management node 103 sends a resource reservation request to its parent node, namely the quota management node 102, where the request may include the type and quantity of the requested reserved resources.

[0159] S408: After receiving the resource reservation request from the child node, the quota management node 102 reserves the relevant resources internally.

[0160] S409, after successfully reserving the relevant resources internally, the quota management node 102 returns a reservation success instruction to the quota management node 103.

[0161] S410, after the predetermined conditions are met, the quota management node 102 sends a resource reservation request to its parent node, namely the root node 101, wherein the request may include the type and quantity of the requested reserved resources.

[0162] S411, after receiving the resource reservation request from the child node, the root node 101 reserves the relevant resources internally.

[0163] S412, after successfully reserving the relevant resources internally, the root node 101 returns a reservation success instruction to the quota management node 102.

[0164] The predetermined condition may be that the resource reserved by the child node reaches a certain threshold (eg, 70% of the remaining quota of the node) at a certain interval (eg, 10 minutes).

[0165] In this implementation, each time the cloud service reserves quota from a leaf node, the leaf node does not need to forward the reservation request to the parent node each time. As long as the leaf node still has resources reserved from the parent node, it can directly return a successful reservation instruction to the cloud service and deduct the corresponding quota from the internal resource pool. This method greatly increases the availability of the system and relieves the operating pressure of the entire system.

[0166] At regular intervals or when the resources reserved by child nodes reach a certain threshold, each quota management node will proactively reserve a certain amount of resources from the parent node for the child nodes to reserve in the next period of time. The more resources each quota management node proactively reserves from the parent node, the less pressure the system will have, but the real-time performance may be reduced. It may happen that some child nodes still have a lot of free resources, but other child nodes under the same parent node can no longer reserve new resources from this parent node.

[0167] In a possible implementation, if the child node does not apply for actually calling the reserved resource within a period of time, the reserved resource expires, and the resource returns to the resource pool to wait for reallocation.

[0168] In addition to reserving resources, resources must also be actually allocated to cloud services to complete the complete resource allocation process. For quota management systems that do not implement the reservation method, the resource allocation is relatively simple. When the cloud service receives the consent instruction from the leaf node, it can directly call the resources it has applied for. For quota management systems that implement the reservation method, the actual resource allocation method is relatively complex. Figure 8 Describes the actual calling method of resources in the quota management system that executes the predetermined method:

[0169] S501 , the cloud service 105 sends a request to the leaf node 104 to use the reserved resources.

[0170] S502, after receiving the use application of the child node, it is checked whether there is corresponding reservation information recorded internally. After finding the corresponding reservation information, the leaf node 104 deducts the corresponding reservation resources internally and deletes the reservation information.

[0171] S503 , after deducting the corresponding reserved resources internally, the leaf node 104 issues a resource usage instruction to the cloud service 105 .

[0172] S504 , after the predetermined conditions are met, the leaf node 104 reports the usage information of the predetermined resources to its parent node, namely the quota management node 103 .

[0173] S505, after receiving the reserved resource usage information reported by the leaf node 104, the quota management node 103 deducts the corresponding reserved resources internally and deletes the corresponding reservation information.

[0174] S506 , after the predetermined conditions are met, the quota management node 103 reports the usage information of the predetermined resources to its parent node, namely the quota management node 102 .

[0175] S507, after receiving the reserved resource usage information reported by the quota management node 103, the quota management node 102 deducts the corresponding reserved resources internally and deletes the corresponding reservation information.

[0176] S508 , after the predetermined conditions are met, the quota management node 102 reports the usage information of the predetermined resources to its parent node, namely the root node 101 .

[0177] S509, after receiving the reserved resource usage information reported by the quota management node 102, the root node 101 deducts the corresponding reserved resources internally and deletes the corresponding reservation information.

[0178] The reservation condition may be that once a reservation application from a child node is received, the usage status is immediately reported to the parent node, so that the parent node deducts the relevant reserved resources to prevent the reserved resources from being returned to the resource pool when they expire.

[0179] The predetermined condition may also be that a predetermined expiration time has been reached. In this implementation, once the predetermined expiration time is reached, the quota management node automatically reports the information of the used and unused scheduled resources, returns the unused scheduled resources to the resource pool, and deducts the corresponding scheduled resources from the used resources. For example, if the cloud service 105 sends a 100-unit use application to the leaf node 104, the leaf node 104 and the quota management node 103 both cache 100 units of resource reservation information internally. When the reservation information of the leaf node 104 reaches the expiration time, the cloud service 105 actually applies for the use of 60 units, and there are 40 units of resources for actual use. The leaf node 104 restores the quota amount of 40 units and reports this information to the quota management node 103. After receiving this information, the quota management node 103 also restores the quota amount of 40 units, and so on until the root node 101.

[0180] In a possible implementation, the expiration time of the parent node is set to be later than the expiration time of the child node, so as to ensure that before the child node reports information to the parent node, the parent node's resources will not expire without receiving the child node information. For example, if the expiration time of the quota management node 103 is set to 1:00, 2:00, 3:00, the expiration time (information reporting time) of the leaf node can be set to 0:59, 1:29, 2:59. Or the expiration time of the parent node is set to five minutes after receiving the child node information. The information is the report information sent to the parent node after the child node's scheduled resources expire.

[0181] In the reserved quota management system, the reservation condition may also be that, every once in a while or when the resources reserved by the child node reach a certain threshold, when actively reserving new resources from the parent node, the used reserved resource information is reported to the parent node at the same time.

[0182] The instruction to use resources may be that the leaf node 104 allocates the corresponding resources to the cloud service 105, or it may be that the cloud service 105 actively calls the corresponding resources, or that the cloud service 105 is given the authority to open the corresponding resources.

[0183] In a possible implementation, when a child node sends a reservation application to a parent node, but the corresponding reserved resources in the parent node have expired, the parent node returns a reservation failure instruction to the child node, and the child node passes the reservation failure instruction down to the cloud service. At this time, if the cloud service wants to use new resources, it needs to re-initiate a new resource reservation application to the leaf node.

[0184] During the actual operation of the quota management system, a cloud service may need to query the maximum quota it can use. The maximum quota that can be used is the maximum quota that can actually be called. For example, if the quota management node of a cloud service shows that the cloud service has a maximum of 100 units of storage resources available, but the parent node of the quota management node, i.e., the quota management node, shows that the area it is responsible for currently has only 80 units of resource quota, then for the cloud service, the maximum quota that can currently be used is 80 units. Here, combined with Fig. 9 A method for querying the maximum quota amount that can be used in a multi-level quota management system is described.

[0185] S601 , the cloud service 105 sends a resource query request to its parent node, namely the leaf node 104 .

[0186] S602 , after receiving the resource query request from the child node, the leaf node 104 sends a resource query request to its parent node, namely the quota management node 103 .

[0187] S603 , after receiving the resource query request from the child node, the quota management node 103 sends a resource query request to its parent node, namely, the quota management node 102 .

[0188] S604 , after receiving the resource query request from the child node, the quota management node 102 sends a resource query request to its parent node, ie, the root node 101 .

[0189] S605, after receiving the resource query request, the root node 101 returns its quota amount to its corresponding child node.

[0190] S606, after receiving the quota amount returned by the parent node, namely the root node 101, the quota management node 102 returns the preferred quota amount to the subordinate child node according to the quota amount of the node and the quota amount of the parent node.

[0191] S607, after receiving the quota amount returned by the parent node, namely the quota management node 102, the quota management node 103 returns the preferred quota amount to the subordinate child node according to the quota amount of the node and the quota amount of the parent node.

[0192] S608, after receiving the quota amount returned by the parent node, namely the quota management node 103, the leaf node 103 returns the preferred quota amount to the subordinate child node according to the quota amount of the node and the quota amount of the parent node.

[0193] The quota amount is a quota amount that is compatible with the resource type managed by the quota management node. For example, the remaining quota of the regional resources that the quota management node is responsible for is the quota amount of this quota management node. When the quota management node is a quota management node, the remaining number of cloud service quotas that the quota management node is responsible for is the quota amount of this quota management node.

[0194] The preferred quota amount may be a lower quota amount compared to the quota amount of the current node and the quota amount returned by the parent node, or the quota amount of the current node and the quota amount returned by the parent node are returned together to the subordinate child node.

[0195] In a possible implementation, the cloud service 105 may also directly send a resource query request to the root node 101. The root node 101 may determine the corresponding child node information based on the information carried in the cloud service 105 query request, and return the quota amount of the root node 101 and the information carried in the cloud service 105 query request to the corresponding child node. After receiving the quota amount information returned by the parent node, i.e., the root node 101, the quota management node 102 first determines the corresponding child node information based on the information carried in the cloud service 105 query request, and returns the preferred quota amount determined based on the quota amount received from the parent node and the quota amount of the node. The carried information should include the characteristic information of the cloud service 105, and the characteristic information enables the quota management node to distinguish the corresponding child node information. For example, when the root node 101 receives a leaf node query request from the cloud service 105, it may have multiple child nodes, including the child node corresponding to the cloud service 105, namely the quota management node 102, and the quota management node 10X (not shown in the figure) that does not correspond to the cloud service 105. The characteristic information should enable the root node 101 to identify the child node corresponding to the cloud service 105, namely the quota management node 102. The specific implementation of the characteristic information is shown in Figure 5 The detailed introduction of the method for querying leaf nodes is not given here.

[0196] In a possible implementation, each quota management node is configured with a corresponding cache layer, in which the quota information of the parent node can be cached. After receiving a resource query request sent by a child node, each quota management node will first query the cache layer to see whether there is a quota of the parent node. If the quota of the parent node is found in the cache layer, the preferred quota will be returned to the child node based on the quota of the parent node and the quota of the node.

[0197] Combine the following Fig.10 Describes the resource query method of the multi-level quota management system with a cache layer:

[0198] S701, the cloud service 105 sends a resource query request to the leaf node 104.

[0199] S702, after receiving the resource query request from the child node, the leaf node 104 queries whether there is a quota amount of the parent node in the cache layer.

[0200] S703, if the leaf node 104 finds the quota amount of its parent node, namely the quota management node 103, in the cache layer, it returns the preferred quota amount to the child node according to the quota amount of the parent node and its own quota amount.

[0201] S704: If the leaf node 104 does not find the quota of its parent node in the cache layer, the resource query request is transmitted to the parent node.

[0202] S705, after receiving the resource query request of the child node, the quota management node 103 queries whether there is a quota amount of the parent node in the cache layer.

[0203] S706: If the quota management node 103 finds the quota amount of its parent node, namely the quota management node 102, in the cache layer, it returns the preferred quota amount to the child node according to the quota amount of the parent node and its own quota amount.

[0204] S707: If the leaf node 104 does not find the quota of its parent node in the cache layer, the resource query request is transmitted to the parent node.

[0205] S708, after receiving the resource query request from the child node, the quota management node 102 queries whether there is a quota amount of the parent node in the cache layer.

[0206] S709: If the quota management node 102 finds the quota of its parent node, namely the root node 101, in the cache layer, it returns the preferred quota to the child node according to the quota of the parent node and its own quota.

[0207] S710: If the quota management node 102 fails to find the quota of its parent node in the cache layer, it transmits a resource query request to the parent node.

[0208] S711, after receiving the resource query request from the child node, the root node 101 returns the quota amount to the child node.

[0209] S712: After receiving the quota information returned by the parent node, the quota management node 102 returns the preferred quota to the child node according to the quota returned by the parent node and its own quota.

[0210] S713, after receiving the quota amount information returned by the parent node, the quota management node 103 returns the preferred quota amount to the child node according to the quota amount returned by the parent node and its own quota amount.

[0211] S714, after receiving the quota information returned by the parent node, the leaf node 104 returns the preferred quota to the child node according to the quota returned by the parent node and its own quota.

[0212] In this implementation, if the quota management node caches the quota amount of the parent node, it can directly return the preferred quota amount to the child node, avoiding the need to query the root node step by step for each quota amount query, greatly reducing the operating pressure of the entire system and improving the operating efficiency of the system.

[0213] In a possible implementation, the quota amount of the parent node cached by the quota management node is the preferred quota amount returned by the parent node rather than the quota amount of the parent node itself. This method can effectively improve the accuracy of resource queries. For example, when the quota management node 102 receives the quota amount of the root node 101, it returns the preferred quota amount to the quota management node 103. It is assumed here that the preferred quota amount is: a quota amount with a lower amount compared to the quota amount of the parent node and the quota amount of the child node. At this time, the quota management node 103 caches the received preferred quota amount into the cache layer, waiting for the next query of the child node, that is, the leaf node 104. When the leaf node 104 sends a resource query request to the quota management node 103, the quota management node 103 returns to the leaf node 104 a quota amount (preferred amount) with a lower amount compared to the preferred quota amount received from the quota management node 102. In this way, the parent node quota amount queried by leaf node 104 is the lowest quota amount compared with the quota amounts of quota management nodes 103, quota management node 102, and root node 101. Similarly, the quota amount returned by leaf node 104 to cloud service 105 is the lowest quota amount compared with the quota amounts of quota management nodes 104, quota management node 103, quota management node 102, and root node 101. This method can ensure that the available quota amount queried by cloud service 105 is the most reliable and available.

[0214] Combine the following Fig.11 Here is a specific implementation method:

[0215] S1, the cloud service sends a resource usage request to the cloud service deployment module;

[0216] The request should include the type and quantity of resources that the cloud service wants to use;

[0217] S2, query the IP address of the first quota management node;

[0218] The query method may be Figure 5The query method provided may also be to directly query the IP address information of the first quota management node from the cache, and the first quota management node may be a leaf node directly corresponding to the cloud service. The upper node of the first quota management node may be any upper node of the first quota management node.

[0219] S3, sending a resource usage application to the first quota management node;

[0220] The cloud service deployment module sends a resource application request to the first quota management node according to the obtained IP address, and the request should include the quantity of the resource type.

[0221] S4, the first quota management node sends a resource usage application to the upper-level quota management node;

[0222] When the first quota management node receives the resource usage application sent by the cloud service deployment module, it can first determine whether its own resource quota meets the request of the first quota management node. When its own resource quota meets the request, it forwards the resource usage request to the upper-level quota management node.

[0223] S5, the upper-layer quota management node of the first quota management node gives a first feedback to the first quota management node;

[0224] The first feedback may be an instruction of approval or rejection after review, and in some cases, it may also be the number of a specific resource quota. The number of resource quotas may be the number of resource quotas of the upper-level quota management node itself, or the number of resource quotas returned to it by a node higher than the upper-level quota management node. The basis for the upper-level quota management node to make the first feedback may be the parent node of the first quota management node based on its own quota information and the quota information or instructions returned by the node higher than the parent node. In one possible implementation, in order to make the first feedback, the parent node may report the resource request layer by layer until it reaches the root node of the system, and then make the first feedback based on the instructions transmitted layer by layer from the root node.

[0225] S6, providing second feedback based on the first feedback;

[0226] When the first quota management node receives an instruction of approval or rejection from the upper quota management node, it returns the instruction to the cloud service deployment module. When the first quota management node receives a specific quota quantity from the upper quota management node, the first quota management node can judge whether to approve or reject the resource application request sent by the cloud service deployment module based on the quantity, and give a second feedback at the same time.

[0227] S7, deploying cloud services according to the second feedback;

[0228] When the second feedback is agreement, the cloud service is deployed according to the content of the feedback.

[0229] The present application also provides a computing device 1000. Fig.12 As shown, computing device 1000 includes: bus 1002, processor 1004, memory 1006 and communication interface 1008. Processor 1004, memory 1006 and communication interface 1008 communicate through bus 1002. Computing device 1000 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in computing device 1000.

[0230] The bus 1002 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.12 The bus 1004 may include a path for transmitting information between various components of the computing device 1000 (eg, the memory 1006, the processor 1004, and the communication interface 1008).

[0231] The processor 1004 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0232] The memory 1006 may include a volatile memory, such as a random access memory (RAM). The processor 1004 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0233] The memory 1006 stores executable program codes, and the processor 1004 executes the executable program codes to respectively implement the functions of the aforementioned traffic analysis device and simulation model arrangement device, thereby achieving Figure 4-10 That is, the memory 1006 stores a method for executing Figure 4-10 Instructions for any of the methods shown.

[0234] The communication interface 1003 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1000 and other devices or a communication network.

[0235] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0236] like Fig.13 As shown, the computing device cluster includes at least one computing device 1000. The memory 1006 in one or more computing devices 1000 in the computing device cluster may store the same Figure 4-10 Instructions for any of the methods shown.

[0237] In some possible implementations, the memory 1006 of one or more computing devices 1000 in the computing device cluster may also store a memory for executing Figure 4-10 In other words, a combination of one or more computing devices 1000 can jointly execute instructions for executing Figure 4-10 Instructions for any of the methods shown.

[0238] It should be noted that the memory 1006 in different computing devices 1000 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the simulation system 600. That is, the instructions stored in the memory 1006 in different computing devices 1000 can implement the functions of one or more modules in the traffic analysis device and the simulation model arrangement device.

[0239] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Fig.14 A possible implementation is shown. Fig.14As shown, two computing devices 1000A and 1000B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 1006 in the computing device 1000A stores instructions for executing the functions of the traffic analysis device. At the same time, the memory 1006 in the computing device 1000B stores instructions for the simulation model arrangement device.

[0240] It should be understood that Fig.14 The functions of the computing device 1000A shown in FIG. 1000A may also be completed by multiple computing devices 1000. Similarly, the functions of the computing device 1000B may also be completed by multiple computing devices 1000.

[0241] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes Figure 4-10 Any of the methods shown.

[0242] The present application also provides a computer-readable storage medium. The computer-readable storage medium may be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute Figure 4-10 Any of the methods shown.

[0243] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A resource management method, characterized in that: A quota management system manages cloud computing resources for deploying cloud services, wherein the cloud computing resources are provided by multiple servers, the quota management system includes a multi-level quota management node, the multi-level quota management node includes a plurality of first quota management nodes and an upper-level quota management node of the first quota management node, and the method includes: The cloud service deployment module receives a request to deploy a cloud service; The cloud service deployment module determines an Internet Protocol IP address of the first quota management node; The cloud service deployment module sends a resource application request to the first quota management node according to the IP address of the first quota management node, where the resource application request carries a target resource quota of cloud computing resources required for deploying the cloud service; The first quota management node applies for the cloud computing resources of the target resource quota from the superior quota management node of the first quota management node; The first quota management node receives feedback from the upper-level quota management node; If the feedback is approval of the application, the first quota management node provides the cloud service deployment module with the cloud computing resources of the target resource quota; The cloud service deployment module deploys the cloud service using the cloud computing resources of the target resource quota.

2. The method according to claim 1, characterized in that The method comprises: If the feedback is that the application is not approved, the first quota management node feeds back the application result to the cloud service deployment module.

3. The method according to any one of claims 1 to 2, characterized in that: The quota amount of at least one quota management node is smaller than the sum of the quota amounts of all its child nodes.

4. The method according to any one of claims 1 to 3, characterized in that: The resource application includes one or more of the following: resource use application, resource reservation application.

5. The method according to any one of claims 1 to 4, characterized in that: The quota management node is configured with a cache, and the cache stores quota management information of the upper-layer quota management node; or, The cloud service deployment module is configured with a cache, and the cache stores one or more of the following: IP address information of the first quota management node, and quota management information of the first quota management node.

6. The method according to claim 5, characterized in that The cache of the cloud service deployment module contains the IP address information of the first quota management node; accordingly, The cloud service deployment module determines the Internet Protocol IP address of the first quota management node including: The cloud service deployment module determines the Internet Protocol IP address of the first quota management node according to the cached IP address information of the first quota management node.

7. The method according to claim 5, characterized in that The cache of the first quota management node includes the quota amount returned by the upper-level quota management node.

8. A quota management system, characterized in that: The quota management system is used to deploy cloud computing resources for cloud services, the cloud computing resources are provided by multiple servers, the quota management system includes multi-level quota management nodes, the multi-level quota management nodes include multiple first quota management nodes and upper-level quota management nodes of the first quota management nodes, and the quota management system includes: a cloud service deployment module, configured to receive a request for deploying a cloud service, and determine the Internet Protocol IP address of the first quota management node according to the request; the cloud service deployment module is further configured to send a resource application request to the first quota management node according to the IP address of the first quota management node, the resource application request carrying a target resource quota of cloud computing resources required for deploying the cloud service; the cloud service deployment module is further configured to deploy the cloud service using the cloud computing resources of the target resource quota after receiving the cloud computing resources of the target resource quota provided by the first quota management node; The first quota management node is used to apply for the cloud computing resources of the target resource quota from the superior quota management node of the first quota management node, and receive feedback from the superior quota management node. If the feedback is to agree to the application, the first quota management node provides the cloud computing resources of the target resource quota to the cloud service deployment module.

9. The system according to claim 8, characterized in that The first quota management node is further used for: If the feedback is that the application is not approved, the first quota management node feeds back the application result to the cloud service deployment module.

10. The system according to any one of claims 8 to 9, characterized in that: The quota amount of at least one quota management node is smaller than the sum of the quota amounts of all its child nodes.

11. The system according to any one of claims 8 to 10, characterized in that: The resource application includes one or more of the following: resource use application, resource reservation application.

12. The system according to any one of claims 8 to 11, characterized in that: The quota management node is configured with a cache, and the cache stores quota management information of the upper-layer quota management node; or, The cloud service deployment module is configured with a cache, and the cache stores one or more of the following: IP address information of the first quota management node, and quota management information of the first quota management node.

13. The system according to claim 12, characterized in that The cache of the cloud service deployment module contains the IP address information of the first quota management node; accordingly, The cloud service deployment module determines the Internet Protocol IP address of the first quota management node including: The cloud service deployment module determines the Internet Protocol IP address of the first quota management node according to the cached IP address information of the first quota management node.

14. The system according to claim 12, characterized in that The cache layer of the quota management node contains the quota amount returned by its quota management upper-level quota management node.

15. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 7.

16. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 7.

17. A computer-readable storage medium, characterized in that: The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 7.

Images