CN117076142B - Multi-tenant resource pool configuration method and multi-tenant service system - Google Patents

Multi-tenant resource pool configuration method and multi-tenant service system Download PDF

Info

Publication number
CN117076142B
CN117076142B CN202311341953.XA CN202311341953A CN117076142B CN 117076142 B CN117076142 B CN 117076142B CN 202311341953 A CN202311341953 A CN 202311341953A CN 117076142 B CN117076142 B CN 117076142B
Authority
CN
China
Prior art keywords
unit
memory
container units
limited
resource pool
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202311341953.XA
Other languages
Chinese (zh)
Other versions
CN117076142A (en
Inventor
李言
李伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Cloud Computing Ltd
Original Assignee
Alibaba Cloud Computing Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Cloud Computing Ltd filed Critical Alibaba Cloud Computing Ltd
Priority to CN202311341953.XA priority Critical patent/CN117076142B/en
Publication of CN117076142A publication Critical patent/CN117076142A/en
Application granted granted Critical
Publication of CN117076142B publication Critical patent/CN117076142B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0645Rental transactions; Leasing transactions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Debugging And Monitoring (AREA)

Abstract

A multi-tenant resource pool configuration method and a multi-tenant service system are provided. The resource pool is configured with a plurality of container units of different specifications, and the method comprises: obtaining the utilization rate of processing units of container units with different specifications and solving the utilization rate of unit processing units; estimating the number of unit container units limited by the processing units based on the number of the processing units and the unit utilization rate configured in the resource pool; according to the configuration proportion of the container units, the memory size of the unit container units is obtained; estimating the number of unit container units limited by the memory based on the memory size of the unit container units and the memory configuration in the resource pool; and changing the resource pool configuration according to the obtained number of the limited unit container units. The invention evaluates the bottleneck of the utilization efficiency of the resource pool from the two aspects of the processing unit and the memory by normalizing, and gives out a corresponding configuration scheme, thereby improving the utilization efficiency of the resources. According to the scheme, based on the historical information of the computing load, the inventory sales rate measurement for guaranteeing the use experience of each tenant is realized.

Description

Multi-tenant resource pool configuration method and multi-tenant service system
Technical Field
The present disclosure relates to the field of big data, and in particular, to a method for configuring a multi-tenant resource pool and a multi-tenant service system.
Background
A service provider that provides cloud computing services for multiple tenants may use a batch of machines to build a resource pool and run the computing load of multiple tenants within the resource pool, and typically needs to ensure that the tenants do not interact with each other by means of isolation techniques.
In practical applications, container technology is used to run instances, and since computing loads typically include multiple types, it is necessary to provide different specifications of container units for different types of computing loads. Due to the different specifications of the container units, the prior art lacks an effective measure of the inventory condition of the multi-tenant resource pool, and further lacks an effective method for improving the resource utilization by changing the configuration.
For this reason, an efficient multi-tenant resource pool metric scheme is needed.
Disclosure of Invention
One technical problem to be solved by the present disclosure is to provide a multi-tenant resource pool configuration method and a multi-tenant service system. The configuration method evaluates the bottleneck of the utilization efficiency of the resource pool from two aspects of the processing unit and the memory by normalizing the container units with different specifications, and gives a corresponding configuration scheme, thereby improving the utilization efficiency of the resources.
According to a first aspect of the present disclosure, there is provided a multi-tenant resource pool configuration method, in which a plurality of container units of different specifications are configured in a resource pool, and the method includes: acquiring the utilization rate of the processing units of the container units with different specifications and solving the utilization rate of the processing units of the unit container units according to the acquired utilization rate of the processing units of the container units with different specifications; estimating the number of unit container units limited by the processing units based on the number of the processing units configured in the resource pool and the processing unit utilization rate of the unit container units; according to the configuration proportion of the container units with different specifications in the resource pool, the memory size of the unit container unit is calculated; estimating the number of unit container units limited by the memory based on the memory size configured in the resource pool and the memory size of the unit container units; and changing the configuration of the resource pool according to the number of the unit container units limited by the processing unit and the number of the unit container units limited by the memory.
Optionally, when the number of unit container units limited by the processing unit is smaller than the number of unit container units limited by the memory, replacing a machine with a larger memory ratio of the processing unit, thereby increasing the ratio of the number of the processing units in the resource pool to the memory size; and/or when the number of the unit container units limited by the processing unit is larger than the number of the unit container units limited by the memory, replacing the machine with a smaller memory ratio of the processing unit, thereby reducing the ratio of the number of the processing units in the resource pool to the memory size.
Optionally, estimating the number of unit container units limited by the memory based on the memory size configured in the resource pool and the memory size of the unit container units includes: and estimating the number of unit container units limited by the memory based on the available memory size configured in the resource pool and the memory size of the unit container units, wherein the available memory size is related to the number of machines, the single-machine memory size and the single-machine memory fragment size.
Alternatively, when the number of unit container units limited by the processing unit is greater than the number of unit container units limited by the memory, a small-sized container unit is introduced, whereby the number of unit container units limited by the memory can be increased.
Optionally, the container unit is a Pod, and estimating the number of memory-limited unit container units based on the memory size configured in the resource pool and the memory size of the unit container units includes estimating the number of memory-limited unit pods according to the following formula:
optionally, set available memory size = total machine number(single-machine memory size-single-machine memory fragment size), and when the number of unit container units limited by the processing unit is greater than the number of unit container units limited by the memory, selecting to increase the total machine number to obtain and introduce a small-specification container unit according to the relative sizes of the available memory size and the cluster cache memory size, thereby reducing the single-machine memory fragment size, wherein the cluster cache memory size is determined by the maximum resource requirement of a single tenant in the resource pool.
Optionally, determining a configuration item to be adjusted when the number of unit container units limited by the processing unit is greater than the number of unit container units limited by the memory according to the degree of influence of one or more values of the total machine number, the single-machine memory size, the single-machine memory fragment size and the memory size of the unit Pod on the obtained number of unit Pod limited by the memory.
Optionally, changing the configuration of the resource pool according to the number of unit container units limited by the processing unit and the number of unit container units limited by the memory includes: and changing the memory size of the unit container units by adjusting the configuration proportion of the container units with different specifications in the resource pool so as to change the number of the unit container units limited by the memory.
Optionally, the container units are Pod, and estimating the number of unit container units limited by the processing unit based on the number of processing units configured in the resource pool and the processing unit utilization of the unit container units includes estimating the number of unit Pod limited by the processing unit according to the following formula:
optionally, the container unit is a Pod, and the method further comprises: judging the configuration optimization degree of the resource pool according to the cluster selling index, wherein the selling index is estimated according to the following formula:
the unit Pod number is smaller than the unit Pod number limited by the processing unit and the unit Pod number limited by the memory.
According to a second aspect of the present disclosure, there is provided a multi-tenant service system, in which a resource pool of the service system is configured with a plurality of container units of different specifications for providing different services to tenants, the resource pool including a plurality of machines on which the container units of different specifications are deployed, and being configured according to the method of the first aspect.
Optionally, the container units of different specifications are used to provide computing, storage, offline or public component services required by the digital warehouse for the tenant.
Therefore, the configuration method evaluates the bottleneck of the utilization efficiency of the resource pool from two aspects of the processing unit and the memory by normalizing the container units with different specifications, and gives a corresponding configuration scheme, thereby improving the utilization efficiency of the resources. According to the scheme, based on the calculation load history portrait, the inventory sales rate measurement for guaranteeing the use experience of each tenant is realized.
Drawings
The foregoing and other objects, features and advantages of the disclosure will be apparent from the following more particular descriptions of exemplary embodiments of the disclosure as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts throughout exemplary embodiments of the disclosure.
FIG. 1 illustrates one example of a resource configuration in a data warehouse.
Fig. 2 shows a schematic flow diagram of a multi-tenant resource pool configuration method according to one embodiment of the invention.
Figure 3 shows a graphical representation of the processing unit usage of all container units in a cluster of a certain area over a certain period of time.
Detailed Description
Preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While the preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
With the development and popularization of internet and internet of things, more and more data are produced, and data management tools are rapidly developed. Data Warehouse (Data WareHouse) is better suited for Data analysis using online analysis processes than relational databases for online transactions, thereby exploring deeper relationships in the Data.
In today's data warehouse, the mainstream will use a container deployment that is lighter, more portable, and has more loosely isolated characteristics than traditional deployments and virtualized deployments. In actual operation, the containers are typically deployed in Pod (transliterated to pods). Pod is the smallest deployable computing unit created and managed in K8 s. Pod models an application-specific "logical host" that contains one or more application containers that are relatively tightly coupled together and share storage, networks, and declarations of how to run the containers. The content in Pod is always collocated (colocated) and scheduled together, running in a shared context. Pod may be considered herein to be a "container unit," i.e., a computing unit that loads one or more containers to accomplish a particular task. It should be understood that a "container unit" may also include other container minimum deployable computing units other than Pod, such as the minimum deployable computing units employed by other frameworks other than K8s for future release.
In order to implement the application function of the data warehouse, container units with different specifications need to be configured for different services, for example, pod with different specifications are configured, and the Pod with different specifications can be respectively used for executing various services such as calculation, storage, offline, public components and the like required for implementing the data warehouse function. Herein, different specifications of container units refer to different processing unit resources and/or memory resources used by the container units. Herein, the processing unit may refer to a central processing unit, i.e., CPU (Central Processing Unit) (hereinafter, "processing unit" and "CPU" may be used interchangeably). Different processing unit resources used by container units of different specifications may mean different numbers of CPU cores are required. FIG. 1 illustrates one example of a resource configuration in a data warehouse.
As shown, the resource pool mainly includes a fixed resource pool constituted by large-sized machines and an elastic resource pool constituted by elastic instances. The illustrated fixed resource pool includes N machines, which may be the same or different models, such as the illustrated 80C768G and 104C768G models. Here, "C" refers to a Core (e.g., core of a CPU) of a processing unit, and "G" refers to the size of a memory, so 80C768G refers to a single machine model of 80 cores and 768G of memory, and similarly 104C768G refers to a single machine model of 104 cores and 768G of memory. Multiple types of services such as computation, storage, offline, public components, etc., required to implement the data warehouse functions can be run simultaneously on the same machine. The processing units and memory resources required for different types of services are different, and thus the corresponding Pod specifications are different, and as shown in the figure, multiple specifications such as 2C4G, 4C16G, 8C48G, 16C64G, etc. are included.
The elastic resource pool is typically a specified specification Pod purchased from other cloud service providers. The fixed resource pool is a hardware resource pool maintained by the cloud computing service provider itself. Compared with an elastic resource pool which cannot be configured per se, the fixed resource pool is configurable as a hardware resource pool, and the technical problem to be solved by the invention is how to configure the hardware resource pool to improve the resource utilization rate as much as possible while guaranteeing the service quality provided for multiple tenants.
Returning to fig. 1, tenants of the data warehouse cloud service create instances and specify storage, computation sizes by centrally hosting the data warehouse cloud service, and resource application and scheduling is completed by a resource scheduler (resource scheduler).
As can be seen from the above, different models have different processing unit/memory ratios (i.e., the ratio of processing unit to memory, for example, the ratio of CPU core number to memory G number), while Pod of different specifications also has multiple different processing unit/memory ratios of 1:2, 1:4, 1:6, etc., pod of the same processing unit/memory ratio may also have different core numbers and memory sizes (e.g., pod of two specifications of 4C16G and 16C64G has the same processing unit/memory ratio of 1:4, in which case the unit of processing unit is "core" and the unit of memory is "G"). Meanwhile, since the same processing unit core can serve different Pod (because the processing unit utilization of a single Pod is typically low, e.g., about 10%), and the single entity and the resource pool as a whole need to reserve a certain memory capacity, the multi-tenant resource pool cannot be configured simply by making the sum of the processing units and the memory sizes of all Pod equal to the number of processing units and the memory sizes configured in the resource pool.
Therefore, the invention provides a multi-tenant resource pool configuration method, which evaluates the utilization efficiency bottleneck of the resource pool from two aspects of a processing unit and a memory by normalizing container units with different specifications, and accordingly provides a corresponding configuration scheme to improve the utilization efficiency of resources. The efficiency of resource usage may be quantified by the sales rate.
Fig. 2 shows a schematic flow diagram of a multi-tenant resource pool configuration method according to one embodiment of the invention. In the multi-tenant resource pool, a plurality of container units (e.g., pod with specifications of 4C16G and 8C 48G) with different specifications are configured to provide different services for tenants.
In step S210, the processing unit utilization of the container units of different specifications (e.g., pod of different specifications) is acquired, and the processing unit utilization of the unit container unit is found from the acquired processing unit utilization of the container units of different specifications. The processing unit utilization of the container units of different specifications can be obtained according to the historical data. In one embodiment, the processing unit utilization rate of the unit container units can be obtained according to the respective proportion of the container units with different specifications, wherein the processing unit utilization rate of the unit container units can be obtained by various processing unit utilization rates of the container units with different specifications, which are sold in a region. Here, "unit container unit" may be understood as "normalized Pod" or "unit Pod". Since the processing unit/memory ratio is smaller than 1 in the Pod of different specifications (i.e. the value of G is larger than the value of C), the "normalized Pod" has 1CNG, i.e. the number of kernels of Pod is normalized to 1, and the memory size depends on the duty ratio of Pod of different specifications in the cluster, i.e. the value of N needs to be calculated.
Figure 3 shows a graphical representation of the processing unit usage of all container units in a cluster of a certain area over a certain period of time. Here, the container unit is Pod, and the processing unit is CPU. For ease of description, it is assumed that only two specifications of Pod are included within a cluster: storage Pod for storage service with specification of 8C 48G; and a specification 16C64G computing Pod for computing services. The abscissa in the figure represents a specific period of time, and the ordinate represents the total amount of processing unit usage/total amount of processing unit application at any time of all Pod of the same type, i.e., processing unit utilization. The upper and lower five-pointed star in the figure show the peak utilization of the stored Pod and the peak utilization of the calculated Pod, respectively, i.e. the maximum value of the processing unit load at all times during a particular time period.
Through data cleaning and analysis, the peak utilization rate of the calculated Pod is found to be lower than 10%, and the peak utilization rate of the stored Pod is found to be lower than 18%. Here, for convenience of explanation, it is assumed that the storage Pod and the calculated Pod in the cluster each account for 50%. At this time, the processing unit load of the normalized Pod may be calculated according to the following formula:
(1)
here, the normalized Pod load can be regarded as the roughly calculated average calculation load per CPU core, that is, the CPU utilization of the unit container unit (one C). The specification load refers to the utilization rate of the different specification Pod, and the specification ratio refers to the duty ratio of the different specification Pod in the total Pod number. In the example of fig. 3, there are two types of Pod stored and calculated, so n=2, and since the ratio of both is 50%, the CPU utilization per Pod (i.e., the CPU load per Pod) that is normalized is about 14% after normalization.
After the CPU load of the unit Pod (i.e., the processing unit utilization of the unit Pod) is acquired, the number of unit Pod limited by the processing unit, for example, the number of unit Pod limited by the processing unit, may be estimated based on the number of processing units configured in the resource pool and the processing unit utilization of the unit Pod in step S220. Since the CPU has a great performance degradation at 100% utilization, the CPU resources cannot be fully utilized in the utilization shown in fig. 3. Here, the concept of "CPU safe water level" is introduced. The safe water level of the CPU can also be called as 'CPU safe utilization rate', which means that under the condition of resource sharing, the utilization rate of the resource is below the safe water level, the dispute of the computing resource running on the CPU is not obvious, and the service quality is not influenced. Through a large number of mixed part performance evaluations, the analysis result finds that for online service, the utilization rate of the CPU of the whole machine is controlled to be below 30 percent of Qos (quality of service ) and is relatively strong in guarantee, and 30-60 percent of the CPU is partially damaged. Therefore, it is possible to set the CPU security utilization to 30% and estimate the number of units Pod limited by the processing unit based on the following formula:
(2)
here, the product of the total number of machines and the number of single processing units corresponds to the number of processing units arranged in the resource pool. For example, if 50 machines of 104C768G are arranged in the resource pool, the number of processing units arranged in the resource pool is. Of course, if 50 machines are arranged in the resource pool, 20 are 104C768G specification, 30 are 80C768G specification, the number of CPU cores arranged in the resource pool is +.>. Since the safe water level of the processing unit is usually greater than + ->This means that the number of CPU-limited units Pod is greater than the number of CPUs disposed in the resource pool, for example, in the case where the safe water level is 30% and the unit load is 14%, the number of CPUs disposed in the resource pool is +.>In this case, the CPU-limited number of units Pod is 11142.
Meanwhile, the number of units Pod limited by the memory size needs to be obtained. In step S230, the memory size of each container unit is determined based on the arrangement ratios of the container units of different specifications in the resource pool.
Similar to formula (1), the normalized Pod memory size can be obtained by normalization calculation according to cluster duty ratios of memories of Pod of different specifications, namely, the unit Pod memory size:
(3)
here, the specification memory refers to a memory/processing unit ratio of different specifications Pod.
The example of 50% each in the cluster of 8C48G stored Pod and 16C64G calculated Pod can also be described. The storage Pod normalized unit Pod is 1C6G, the calculated Pod normalized unit Pod is 1C4G, and the two units Pod account for 50% of each other in the cluster, so that the unit Pod is 1C5G, and the memory size of the unit Pod is 5G. That is, the memory size of the unit container unit is 5G.
Subsequently, in step S240, the number of unit container units limited by the memory may be estimated based on the memory size configured in the resource pool and the memory size of the unit container units. In a simplest embodiment, the memory size allocated in the resource pool may be directly used to divide the memory size of the unit Pod above to find the number of pods limited by the memory. For example, if 50 machines of 104C768G are configured in the resource pool, the memory size configured in the resource pool is. At this time, if the memory size allocated in the resource pool is directly used to divide the memory size of the above unit Pod to find the memory-limited unit Pod number, 38400G/5 g=7680 can be obtained.
In step S250, the configuration of the resource pool is modified according to the number of unit container units limited by the processing unit and the number of unit container units limited by the memory. Here, the number of unit container units limited by the processing unit and the size of the number of unit container units limited by the memory may be compared, and how to change the configuration of the resource pool may be determined according to the comparison result. Since the smaller value of the number of the units Pod limited by the processing unit and the number of the units Pod limited by the memory determines the actual utilization rate of the resource pool, the resource pool is configured to reduce the number of the unit container units limited by the processing unit and the number of the unit container units limited by the memory, that is, to match the utilization rates of the CPU and the memory.
For example, in the case where 50 machines of 104C768G are arranged in the above resource pool, the storage Pod and the calculation Pod each account for 50% in the cluster, and the security water level is 30% and the unit load is 14%, the CPU-limited number of units Pod is 11142, and the memory-size-limited number of units Pod is 7680, and therefore, in this resource pool, it can be considered that memory is a configuration bottleneck that currently affects efficient resource utilization as compared with CPU-too-small, and therefore, the difference between the memory-limited number of units Pod and the CPU-limited number of units Pod can be reduced by various configuration change operations.
The configuration method evaluates the bottleneck of the utilization efficiency of the resource pool from two aspects of the processing unit and the memory by normalizing the container units with different specifications, and gives a corresponding configuration scheme, thereby improving the utilization efficiency of the resources.
In one embodiment, the configuration change may be made by simply changing the model of the machine. Specifically, when the number of unit container units limited by the processing unit is smaller than the number of unit container units limited by the memory, a machine with a larger processing unit/memory ratio is replaced, so that the ratio of the number of processing units in the resource pool to the size of the memory can be increased. Alternatively or additionally, when the number of unit container units limited by the processing unit is greater than the number of unit container units limited by the memory, a machine with a smaller processing unit/memory ratio is replaced, thereby reducing the ratio of the number of processing units in the resource pool to the size of the memory.
For example, in the above example, as long as 50 machines configured in the resource pool are changed from a 104C768G machine to an 80C768G machine, the ratio of the number of units Pod limited by the processing unit and the memory size is reduced from 11142/7680 to 8571/7680, and obviously the gap between the number of unit container units limited by the memory and the number of unit container units limited by the processing unit becomes smaller, which means that the processing units in the cluster can be more efficiently utilized, thereby improving the overall utilization efficiency of the resource pool.
As described above, in a simple embodiment, the memory size configured in the resource pool may be directly used to divide the memory size of the unit Pod to obtain the number of pods limited by the memory. In actual operation, however, the memory resources configured in the resource pool cannot be fully used for allocation of Pod. This is because actual scheduling typically does not schedule the machine's memory completely full, and there are some memory fragmentation. If two 48G Pod are deployed on a 100G machine, then 4G fragments must be generated. In other words, the impact of single-machine memory fragmentation needs to be considered when finding the number of Pod limited by memory. At this time, estimating the number of unit container units limited by the memory based on the memory size configured in the resource pool and the memory size of the unit container units may include: and estimating the number of unit container units limited by the memory based on the available memory size configured in the resource pool and the memory size of the unit container units, wherein the available memory size is related to the number of machines, the single-machine memory size and the single-machine memory fragment size.
In one embodiment, available memory size = total machine number(Single machine memory size—Single machine memory fragment size). The size of the single memory fragment is then related to the maximum memory size of the single Pod deployed on the machine. In the case of a computing Pod of specification 16C64G, where it is possible to deploy on each machine, the single machine memory fragment size is 64G. At this time, in the example where 50 machine types arranged in the resource pool are 80C768G, the storage Pod and the calculation Pod are each 50% in the cluster, and the safe water level is 30% and the unit load is 14%, the CPU-limited number of units Pod is 8571, and the memory-limited number of units Pod is->. At this time, when the number of CPU-restricted unit container units is greater than the number of memory-restricted unit container units, the number of memory-restricted unit container units may be increased by introducing small-sized container units. Here, the small-sized container unit may refer to a Pod with a smaller memory/CPU ratio, or may refer to a Pod with a smaller CPU core and memory size. Specifically, the memory size of the unit Pod (e.g., from 5G to 4G) can be reduced by introducing an offline Pod (specification of 2C 4G) for offline service, or the size of a single memory fragment can be reduced.
In view of the elastic starting efficiency and stability of the new instance, a part of memory resources are reserved at the cluster level as cluster cache. In actual operation, the size of the cluster cache is set according to the maximum size bin instance size (i.e., the maximum memory size occupied by one tenant) of the region served by the resource pool. In one example, 10000G of cluster cache memory size is set for the cluster as a whole. At this time, estimating the number of memory-limited unit container units based on the memory size configured in the resource pool and the memory size of the unit container units may include estimating the number of memory-limited unit Pod according to the following formula:
(4)
since the cluster cache memory size is determined by the maximum resource requirement of a single tenant in the resource pool (in other words, the memory size of the cluster cache cannot be generally configured), when the number of unit container units limited by the processing unit is greater than the number of unit container units limited by the memory, the size of the available memory (i.e., available memory size = total machine number) can be determined according to the available memory size(single machine memory size-single machine memory fragment size)) and the relative size of the cluster cache memory size, the option to increase the total machine count or to introduce small-size container units to reduce single machine memory fragments. For example, when the available memory size is too small compared to the cluster cache memory size, the memory-constrained number of units Pod can be increased by increasing the resource pool size (i.e., increasing the number of machines).
Further, according to the degree of influence of one or more values of the total machine number, the single-machine memory size, the single-machine memory fragment size and the memory size of the unit Pod on the obtained number of the unit Pod limited by the memory, determining a configuration item to be adjusted when the number of the unit container units limited by the processing unit is larger than the number of the unit container units limited by the memory. This may include modifying the memory size of the unit container units by adjusting the configuration proportions of the container units of different specifications in the resource pool to modify the number of the unit container units subject to memory constraint.
In other words, in the present invention, the configuration of the resource pool is changed not simply to expand or contract, but by changing the configuration on hardware or software, the utilization rate of the resource is improved. For example, when the number of unit container units limited by the processing unit and the number of unit container units limited by the memory differ too much, the gap can be reduced simply by adjusting the processing unit/memory ratio of the hardware model in the resource pool. Further, when the number of unit container units limited by the processing unit is greater than the number of unit container units limited by the memory, how to perform the configuration change may also be determined by analyzing a reason why the number of unit container units limited by the memory is smaller. For example, when the cluster cache memory size is too large compared to the available memory size ratio, the number of machines in the resource pool may be increased.
The number of Pods of unit specification which can be actually operated by the cluster is limited by two factors of processing unit resources and memory resources. Thus, the unit Pod number limited by the processing unit and the unit Pod number limited by the memory, which are calculated as described above, can be used for calculation of the cluster sales index. The cluster selling index not only can represent the resource utilization rate in the fixed resource pool, but also can be used for judging the configuration optimization degree of the resource pool. In one embodiment, the sales index may be estimated according to the following formula:
(5)
the unit Pod number takes the smaller value of the unit Pod number limited by the processing unit and the unit Pod number limited by the memory. Here, the Pod specification is normalized to 1c=1core, called unit specification Pod, based on the statistics of the cluster history instance. The number of Pod corresponds to the number of Pod of unit specification that the cluster can actually operate, and may be a smaller value of the number of Pod units limited by the processing unit and the number of Pod units limited by the memory, which are obtained according to the formula (2) and the formula (4). The total number of machines refers to the number of machines in the fixed resource pool. The machine cost corresponds to the purchase cost of each model. The unit Pod selling price may then correspond to the normalized unit specification Pod selling price. In one embodiment, the normalized unit specification selling price (i.e., unit Pod selling price) may be found according to the following formula:
(6)
wherein the standard unit price is unit price per C (core) of Pod of different standards, and if Pod of 4C16G assumes cost price of 100, the standard unit price is 25=100/4. The specification ratio is the total duty ratio of Pod of different specifications in the cluster, and if only Pod of 4C16G and 8C48G is 100 and 300 respectively, the specification ratio is 0.25 and 0.75 respectively.
And normalizing the Pod into a unit specification by calculating the size and the proportion of the specification based on the number bin instance Pod, and obtaining the CPU utilization rate of the specification Pod by counting bin load. Therefore, the normalized parameter values are substituted into the formula, and the multidimensional measurement of the selling rate is obtained. Here, if the obtained group sales index is too low (for example, lower than 100%), it is indicated that the resources of the resource pool are not well configured, and there is a configuration bottleneck that causes a low resource utilization. At this point, the cluster sales index may be improved according to various optional configuration change options. Specifically, the judgment can be made based on the difference between the number of CPU-limited units Pod and the number of memory-limited units Pod.
Configuration changes by the computation of the above formulas (1) - (6) and the effects achieved by them at each stage of the multi-tenant resource pool configuration will be given below in conjunction with table 1.
In the first stage, the number of machines in the resource pool is small, and 50 machines with the specification of 104C768G are arranged. At this time, a storage Pod with a specification of 8C48G and a calculation Pod with a specification of 16C64G are configured in the resource pool, and the ratio of the two is 1:1. The CPU utilization of both was 18% and 10% respectively as shown in fig. 3, so the unit Pod load (i.e., CPU utilization) was 14%. At this time, the maximum resource requirement of a single tenant in the cluster is 10000G, that is, the memory size of the cluster cache is already determined to be 10000G. At this time, the CPU-limited unit Pod number calculated according to the formula (2) is 11142. The number of Pod limited by the memory calculated according to the formula (4) is 5040, which is far smaller than the number of Pod limited by the CPU (the ratio of the Pod to the Pod is more than 2:1). Bringing 5040 into equation (6) as a unit Pod number, the calculated expected sales rate (i.e., the cluster sales index) is 94% less than 100%. This means that the resources in the fixed resource pool are not as efficiently utilized at this time than the Pod leased in the flexible pool.
Here, the memory/CPU ratio may be raised by first replacing the machine model, i.e., 50 machines with 104C768G, with 50 machines with 80C768G, whereby the difference between the CPU-limited number of units Pod (from 11142 to 8571 due to the reduction of the total CPU resources) and the memory-limited number of units Pod (still 5040) is reduced (the ratio of both is reduced to about 1.7:1). As indicated by "∈" of the machine specification in the second stage, the expected sales rate was improved by lowering the machine specification, from 94% to 111%, starting to achieve the expected sales rate exceeding 100%.
In the second stage, considering that the cluster cache (10000G) is too large (close to 30%) compared to the available memory size (35200G), the difference between the number of memory-limited units Pod compared to the number of CPU-limited units Pod can be reduced by increasing the cluster size (i.e., increasing the number of machines). By increasing the number of machines from 50 to 200, the CPU-limited number of units Pod becomes 34285, the memory-limited number of units Pod becomes 26160, and the ratio of the two further drops to about 1.3:1. As shown by the "+%) of the number of machines in the third stage, the expected sales rate was improved by increasing the number of machines, further increasing from 111% to 144%.
In the third stage, since the cluster size is large enough, the size of the single-machine memory chip can be reduced by introducing a small-size offline Pod (2C 4G), and the ratio of the CPU-limited number of units Pod to the memory-limited number of units Pod is further reduced to about 1.22:1 by reducing the single-machine memory chip from 64G to 16G and increasing the memory-limited number of units Pod to 28080. As shown by "+." for the third stage memory fragmentation, the expected sales rate was improved by reducing the stand-alone memory fragmentation, further increasing from 144% to 155%.
In the fourth stage, the Pod memory allocation can be further optimized, for example, by introducing more small-sized offline pods (with a size of 2C4G and a cpu/memory ratio of 1:2), so that the size of the unit Pod is reduced from 1C5G to 1C4G, and thus the number of unit pods limited by the memory is increased to 35100. This value has exceeded the CPU-limited number of units Pod (value 34285). Since the safe water level and CPU utilization cannot be configured, and the expected sales rate has exceeded 170% at this point. It can be considered that the resources in the resource pool are relatively fully utilized.
Table 1: multi-tenant resource pool configuration phasing configuration example
Therefore, the invention measures the influence of cluster cache reservation on the selling rate through a formula, and can rely on the elastic guarantee capability provided by an elastic resource pool. At a 200 machine scale, the sales rate can be increased by >30% by reducing memory fragmentation and introducing small format Pod.
The invention discloses a normalization technology for calculating the resource specification of a plurality of bins of loads. The technology is based on a multi-bin load historical image, and can still ensure the stock selling rate measurement of service quality when the selling rate exceeds 100%. The scheme selects the machine type based on the historical loads of a plurality of bins, estimates the sales rate of the inventory, supports inventory reporting, and can be expanded to the resource pool inventory sales rate measurement scenes of other databases, distributed computation and distributed AI.
The present invention may also be implemented as a multi-tenant service system. Such as the cloud service system shown in fig. 1. A plurality of different specification container units are configured in a resource pool of a service system for providing different services to tenants, the resource pool comprising a plurality of machines on which the different specification container units are deployed, such as machine 1 … N in fig. 1, and configured according to the method of the present invention as described above.
In one embodiment, container units of different specifications are used to provide the tenant with the computing, storage, offline, or public component services required for the digital warehouse. In other embodiments, container units of different specifications are used to provide different services for tenants as required by other databases, distributed computing, distributed AI, etc. application functions.
The multi-tenant configuration method and the multi-tenant service system according to the present invention have been described in detail above with reference to the accompanying drawings. The configuration method evaluates the bottleneck of the utilization efficiency of the resource pool from two aspects of the processing unit and the memory by normalizing the container units with different specifications, and gives a corresponding configuration scheme, thereby improving the utilization efficiency of the resources. The scheme is based on the calculation load historical portrait, and can realize the stock selling rate measurement of high selling rate safety.
It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region, and provide corresponding operation entries for the user to select authorization or rejection.
Furthermore, the method according to the invention may also be implemented as a computer program or computer program product comprising computer program code instructions for performing the steps defined in the above-mentioned method of the invention.
Alternatively, the invention may also be embodied as a non-transitory machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) having stored thereon executable code (or a computer program, or computer instruction code) which, when executed by a processor of an electronic device (or computing device, server, etc.), causes the processor to perform the steps of the above-described method according to the invention.
Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems and methods according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The foregoing description of embodiments of the invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various embodiments described. The terminology used herein was chosen in order to best explain the principles of the embodiments, the practical application, or the improvement of technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims (12)

1. A multi-tenant resource pool configuration method, the resource pool having a plurality of different specification container units configured therein, and the method comprising:
acquiring the utilization rate of the processing units of the container units with different specifications and solving the utilization rate of the processing units of the unit container units based on the acquired utilization rate of the processing units of the container units with different specifications;
estimating the number of unit container units limited by the processing units based on the number of the processing units configured in the resource pool and the processing unit utilization rate of the unit container units, wherein the product of the number of the processing units configured in the resource pool and the processing unit safety utilization rate is divided by the processing unit utilization rate of the unit container units to estimate the number of the unit container units limited by the processing units;
according to the configuration proportion of the container units with different specifications in the resource pool, the memory size of the unit container unit is calculated;
estimating the number of unit container units limited by the memory based on the memory size configured in the resource pool and the memory size of the unit container units, wherein the number of unit container units limited by the memory is estimated by dividing the memory size configured in the resource pool by the memory size of the unit container units; and
and changing the configuration of the resource pool according to the number of the unit container units limited by the processing unit and the number of the unit container units limited by the memory.
2. The method of claim 1, wherein altering the configuration of the resource pool based on the number of processing unit-limited unit container units and the number of memory-limited unit container units comprises:
when the number of the unit container units limited by the processing unit is smaller than the number of the unit container units limited by the memory, replacing a machine with larger ratio of the processing unit to the memory; and/or
And when the number of the unit container units limited by the processing unit is larger than the number of the unit container units limited by the memory, changing the processing unit and the memory to a smaller machine.
3. The method of claim 1, wherein altering the configuration of the resource pool based on the number of processing unit-limited unit container units and the number of memory-limited unit container units comprises:
and introducing small-specification container units when the number of the unit container units limited by the processing unit is larger than the number of the unit container units limited by the memory.
4. The method of claim 1, wherein estimating the number of memory-limited unit container units based on the memory size configured in the resource pool and the memory size of the unit container units comprises:
and estimating the number of unit container units limited by the memory based on the available memory size configured in the resource pool and the memory size of the unit container units, wherein the available memory size is related to the number of machines, the single-machine memory size and the single-machine memory fragment size.
5. The method of claim 4, wherein the container units are Pod, and estimating the number of memory-limited unit container units based on the memory size configured in the resource pool and the memory size of the unit container units comprises estimating the number of memory-limited unit Pod according to the following formula:
wherein the product of the number of the total machines and the size of the single machine memory corresponds to the size of the memory configured in the resource pool.
6. The method of claim 5, wherein the available memory size = total machine count(single-machine memory size-single-machine memory fragment size), and
when the number of the unit container units limited by the processing unit is larger than the number of the unit container units limited by the memory, according to the relative sizes of the available memory size and the cluster cache memory size, selecting to increase the total machine number or introduce small-size container units to reduce the size of single-machine memory fragments,
the size of the cluster cache memory is determined by the maximum resource requirement of a single tenant in the resource pool.
7. The method of claim 5, wherein the configuration item to be adjusted when the number of processing unit-bound unit container units is greater than the number of memory-bound unit container units is determined based on a degree of impact of adjusting one or more of the total machine number, the stand-alone memory size, the stand-alone memory fragment size, and the memory size of the unit Pod on the determined number of memory-bound unit pods.
8. The method of claim 1, wherein altering the configuration of the resource pool based on the number of processing unit-limited unit container units and the number of memory-limited unit container units comprises:
and changing the memory size of the unit container units by adjusting the configuration proportion of the container units with different specifications in the resource pool so as to change the number of the unit container units limited by the memory.
9. The method of claim 1, wherein the container units are Pod, and estimating the number of unit container units limited by a processing unit based on the number of processing units configured in the resource pool and the processing unit utilization of the unit container units comprises estimating the number of unit Pod limited by a processing unit according to the following formula:
wherein the product of the total machine number and the number of single processing units corresponds to the number of processing units configured in the resource pool.
10. The method of claim 1, the container unit being a Pod, and the method further comprising:
judging the configuration optimization degree of the resource pool according to the cluster selling index, wherein the selling index is estimated according to the following formula:
the unit Pod number is smaller than the unit Pod number limited by the processing unit and the unit Pod number limited by the memory.
11. A multi-tenant service system having a plurality of different sized container units configured in a resource pool of the service system for providing different services to tenants, the resource pool comprising a plurality of machines on which the different sized container units are deployed and configured in accordance with the method of any one of claims 1-10.
12. The system of claim 11, wherein the different specification container units are used to provide computing, storage, offline, or common component services required for a digital warehouse for tenants.
CN202311341953.XA 2023-10-17 2023-10-17 Multi-tenant resource pool configuration method and multi-tenant service system Active CN117076142B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311341953.XA CN117076142B (en) 2023-10-17 2023-10-17 Multi-tenant resource pool configuration method and multi-tenant service system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311341953.XA CN117076142B (en) 2023-10-17 2023-10-17 Multi-tenant resource pool configuration method and multi-tenant service system

Publications (2)

Publication Number Publication Date
CN117076142A CN117076142A (en) 2023-11-17
CN117076142B true CN117076142B (en) 2024-01-30

Family

ID=88704712

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311341953.XA Active CN117076142B (en) 2023-10-17 2023-10-17 Multi-tenant resource pool configuration method and multi-tenant service system

Country Status (1)

Country Link
CN (1) CN117076142B (en)

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107743611A (en) * 2015-04-29 2018-02-27 微软技术许可有限责任公司 The optimum allocation of dynamic cloud computing platform resource
CN107908457A (en) * 2017-11-08 2018-04-13 河海大学 A kind of containerization cloud resource distribution method based on stable matching
CN109144727A (en) * 2018-08-21 2019-01-04 郑州云海信息技术有限公司 The management method and device of resource in cloud data system
CN110198231A (en) * 2018-05-08 2019-09-03 腾讯科技(深圳)有限公司 Capacitor network management method and system and middleware for multi-tenant
CN110489200A (en) * 2018-05-14 2019-11-22 中国科学院声学研究所 A kind of method for scheduling task suitable for embedded container cluster
CN112199194A (en) * 2020-10-14 2021-01-08 广州虎牙科技有限公司 Container cluster-based resource scheduling method, device, equipment and storage medium
CN112559135A (en) * 2020-12-24 2021-03-26 重庆邮电大学 QoS-based container cloud resource scheduling method
CN114666333A (en) * 2022-04-02 2022-06-24 国网江苏省电力有限公司信息通信分公司 Control method for cloud computing resource scheduling problem based on multi-tenant theory
CN114780244A (en) * 2022-04-29 2022-07-22 深圳市赛为智能股份有限公司 Container cloud resource elastic allocation method and device, computer equipment and medium
CN115348264A (en) * 2022-07-28 2022-11-15 招商局金融科技有限公司 Multi-tenant cloud service management method, device, equipment and storage medium
CN115756770A (en) * 2022-10-18 2023-03-07 阿里云计算有限公司 Request operation scheduling execution method and remote procedure call system

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107743611A (en) * 2015-04-29 2018-02-27 微软技术许可有限责任公司 The optimum allocation of dynamic cloud computing platform resource
CN107908457A (en) * 2017-11-08 2018-04-13 河海大学 A kind of containerization cloud resource distribution method based on stable matching
CN110198231A (en) * 2018-05-08 2019-09-03 腾讯科技(深圳)有限公司 Capacitor network management method and system and middleware for multi-tenant
CN110489200A (en) * 2018-05-14 2019-11-22 中国科学院声学研究所 A kind of method for scheduling task suitable for embedded container cluster
CN109144727A (en) * 2018-08-21 2019-01-04 郑州云海信息技术有限公司 The management method and device of resource in cloud data system
CN112199194A (en) * 2020-10-14 2021-01-08 广州虎牙科技有限公司 Container cluster-based resource scheduling method, device, equipment and storage medium
CN112559135A (en) * 2020-12-24 2021-03-26 重庆邮电大学 QoS-based container cloud resource scheduling method
CN114666333A (en) * 2022-04-02 2022-06-24 国网江苏省电力有限公司信息通信分公司 Control method for cloud computing resource scheduling problem based on multi-tenant theory
CN114780244A (en) * 2022-04-29 2022-07-22 深圳市赛为智能股份有限公司 Container cloud resource elastic allocation method and device, computer equipment and medium
CN115348264A (en) * 2022-07-28 2022-11-15 招商局金融科技有限公司 Multi-tenant cloud service management method, device, equipment and storage medium
CN115756770A (en) * 2022-10-18 2023-03-07 阿里云计算有限公司 Request operation scheduling execution method and remote procedure call system

Also Published As

Publication number Publication date
CN117076142A (en) 2023-11-17

Similar Documents

Publication Publication Date Title
US10558498B2 (en) Method for scheduling data flow task and apparatus
CN107045456B (en) Resource allocation method and resource manager
US20190324819A1 (en) Distributed-system task assignment method and apparatus
US10772115B2 (en) Resource scheduling method and server
WO2013101024A1 (en) Imaging task pipeline acceleration
CN109873714B (en) Cloud computing node configuration updating method and terminal equipment
CN111381957A (en) Service instance fine scheduling method and system for distributed platform
CN110096339B (en) System load-based capacity expansion and contraction configuration recommendation system and method
US20230379268A1 (en) Resource scheduling method and system, electronic device, computer readable storage medium
US6865527B2 (en) Method and apparatus for computing data storage assignments
CN117076142B (en) Multi-tenant resource pool configuration method and multi-tenant service system
EP3806548B1 (en) Method for optimising the amount of network resources and the number of services that are likely to use said resources
CN112039689B (en) Network equipment performance evaluation method, device, equipment and storage medium
CN111131375B (en) Interface service acquisition method, device, computer equipment and storage medium
CN116382892B (en) Load balancing method and device based on multi-cloud fusion and cloud service
CN110765082B (en) Hadoop file processing method and device, storage medium and server
CN117369941A (en) Pod scheduling method and system
CN115665157B (en) Balanced scheduling method and system based on application resource types
CN108664322A (en) Data processing method and system
CN113438678B (en) Method and device for distributing cloud resources for network slices
CN113722107B (en) Cloud product management and control service deployment method, device, equipment and storage medium
CN115941758A (en) Cloud service console deployment method, system and storage medium based on dynamic programming
CN114675973A (en) Resource management method, device, storage medium, and program product
US20150294264A1 (en) Threshold revenue management with limited forecasting
CN113656233B (en) Cloud test resource pushing method and system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant