A granular adaptive cluster software-defined method and apparatus

Abstract

The application discloses a kind of granularity self-adapting cluster software definition method and device, including pilot engine and cluster management system being connected with each other, applied to cluster service management, the method includes: sending real-time resource data request to each working node in cluster management system, obtains real-time resource data;Read real-time resource data, calculate the best design capacity;The best design capacity is written into configuration file, and cluster management system is triggered to create service;The application utilizes pilot engine to dynamically create service, so that system resources can be more intensively utilized, by obtaining system real-time running data, the data is comprehensively processed, the optimal granularity of container is dynamically calculated, and finally the container is created, the method replaces the traditional way of fixed granularity, to maximize the purpose of resource utilization, balance two resource waste indicators, so that the degree of comprehensive waste resource is reduced to a minimum.

Description

TECHNICAL FIELD

[0001] The present application relates to a kind of granularity adaptive cluster software definition method and device, belong to power system technical field. BACKGROUND

[0002] As an important barrier to protect the safety of power system, power internet of things boundary security protection device plays an important role, with the development of computer science and technology, the processing capacity of such device is stronger and stronger, and the performance is higher and higher. Based on single machine, the deployment of traditional power internet of things boundary security protection device is complex and not easy to expand, therefore, we introduce software defined strategy, unbundling its security function and hardware, and realizing in docker container, so that the resources consumed by business can be dynamically allocated according to real-time demand.

[0003] In actual application, we need to set the granularity of container, i.e. the business processing capacity of single container, simply referred to as "the design capacity of container". The overhead (memory) required by each container is divided into fixed part and variable part, and the variable part increases linearly with the increase of granularity. The traditional method is to artificially estimate and set a value as the granularity, which is written as a fixed value in the configuration file, and will not be changed no matter how the environment changes or the system starts and stops, so the container overhead is fixed. When the remaining resources (memory) of the system cannot meet the overhead of a container, this part of resources will be idle because it cannot be utilized. The disadvantage of this method is that it is easy to cause resource waste, and the granularity is too high or too low, which will have an impact:

[0004] (1) The larger the granularity, the more the remaining resources (memory) of the system cannot support the overhead of a container, resulting in waste.

[0005] (2) The smaller the granularity, the larger the proportion of fixed overhead of the container, which also causes resource waste. SUMMARY

[0006] The purpose of the present application is to overcome the deficiencies in the prior art, provide a kind of granularity adaptive cluster software definition method and device, create a pilot engine in the system, when creating service, pilot engine obtains system real-time running data, comprehensively processes these data, dynamically calculates the optimal granularity of container, and finally creates container, this method replaces the traditional way of fixed granularity, to achieve the purpose of maximizing resource utilization.

[0007] To achieve the above purpose, the technical scheme adopted by the present application is as follows:

[0008] In the first aspect, the present application provides a kind of granularity adaptive cluster software definition method, comprising:

[0009] sending real-time resource data request to each working node in cluster management system, and obtaining real-time resource data;

[0010] read real-time resource data, calculate the optimal design capacity;

[0011] write the optimal design capacity into the configuration file, trigger the cluster management system to create a service, and create a container.

[0012] Further, the real-time resource data includes fixed overhead and single-session overhead, and the formula for calculating the optimal design capacity is as follows:

[0013]

[0014] wherein n is the optimal design capacity, M is the average available memory of each node of the cluster management system, M0 is the fixed overhead, and M1 is the single-session overhead.

[0015] Further, the writing of the configuration file includes writing the limit and request fields in the service configuration file, denoted as LR, and determining LR = M0 + nM1 according to the optimal design capacity n, the fixed overhead M0, and the single-session overhead M1.

[0016] and writing the optimal design capacity n into the configmap for the container to read, each container at most handles n sessions in parallel, and load balancing at most allocates n sessions to each container.

[0017] In a second aspect, the present application provides a cluster management system service creation device with adaptive granularity, comprising:

[0018] a real-time resource data acquisition unit for sending a real-time resource data request to each working node in the cluster management system and acquiring real-time resource data;

[0019] an optimal design capacity calculation unit for reading real-time resource data and calculating the optimal design capacity;

[0020] a configuration file writing unit for writing the optimal design capacity into the configuration file, triggering the cluster management system to create a service, and creating a container.

[0021] Further, in the optimal design capacity calculation unit, the formula for calculating the optimal design capacity is as follows:

[0022]

[0023] wherein n is the optimal design capacity, M is the available memory of each node of the system, M0 is the fixed memory of each container, and M1 is the memory consumed for processing each session.

[0024] Furthermore, in the configuration file writing unit, writing the configuration file includes writing the limit and request fields in the service configuration file, denoted by LR, which is determined according to the optimal design capacity n, fixed overhead M0, and single session overhead M1: LR = M0 + nM1;

[0025] The optimal design capacity n is written to the configmap for containers to read. Each container can process at most n sessions in parallel, and the load balancer can also allocate at most n sessions to each container.

[0026] Thirdly, the present invention provides a granular adaptive cluster management system service creation system, comprising a pilot engine and a cluster management system that are interconnected, wherein the pilot engine includes:

[0027] A resource detector, with a built-in real-time resource data acquisition unit of any of the above-mentioned devices;

[0028] Design a capacity calculator, which incorporates the optimal design capacity calculation unit for any of the devices described above;

[0029] The service creation engine has a built-in configuration file writing unit for any of the devices described above.

[0030] Furthermore, the resource monitor is a component that collects real-time available resources of the cluster worker nodes. The resource monitor sends TCP messages to the worker nodes through a software program to request real-time resource data; the worker nodes obtain the real-time resource data through system calls and respond with TCP messages.

[0031] Furthermore, the design capacity calculator is also used to obtain the fixed overhead and single-session overhead of the service.

[0032] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described above.

[0033] Compared with the prior art, the beneficial effects achieved by the present invention are as follows:

[0034] This invention provides a cluster software definition method and apparatus with adaptive granularity. It abandons the traditional mode of manually pre-specifying container design capacity and uses a pilot engine to dynamically create services, enabling more intensive use of system resources. By acquiring real-time system resource data, processing this data comprehensively, and dynamically calculating the optimal design capacity, the optimal design capacity is written into the configuration file, triggering the cluster management system to create services, and finally creating containers. This method replaces the traditional method of fixed granularity, achieving the goal of maximizing resource utilization, balancing two resource waste indicators, and minimizing the overall degree of resource waste. Attached Figure Description

[0035] Figure 1 is a flow chart of a granularity adaptive cluster software definition method provided by an embodiment of the present application;

[0036] Figure 2 is a system architecture diagram of a granularity adaptive cluster management system service creation system provided by an embodiment of the present application;

[0037] Figure 3 is a system structure diagram of a pilot engine provided by an embodiment of the present application;

[0038] Figure 4 is a flow diagram of creating a service provided by an embodiment of the present application;

[0039] Figure 5 、 Figure 6 is a prior art diagram provided by an embodiment of the present application. DETAILED DESCRIPTION

[0040] The present application will be further described below in conjunction with the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solutions of the present application, and cannot be used to limit the protection scope of the present application.

[0041] Embodiment 1

[0042] As shown in Figure 1 , the present embodiment introduces a granularity adaptive cluster software definition method, which comprises a pilot engine and a cluster management system connected in communication with each other, and is applied to the pilot engine, and the method comprises:

[0043] sending a real-time resource data request to each working node in the cluster management system to obtain real-time resource data;

[0044] reading the real-time resource data and calculating the optimal design capacity;

[0045] writing the optimal design capacity into a configuration file, triggering the cluster management system to create a service, and creating a container.

[0046] Specifically, the real-time resource data comprises a fixed overhead and a single session overhead, and the formula for calculating the optimal design capacity is as follows:

[0047]

[0048] wherein n is the optimal design capacity, M is the average value of the available memory of each node of the cluster management system, M0 is the fixed overhead, and M1 is the single session overhead.

[0049] Specifically, the write configuration file includes limit and request fields in the write service configuration file, denoted as LR, which is determined according to the optimal design capacity n, the fixed overhead M0, and the single-session overhead M1: LR = M0 + nM1.

[0050] And the optimal design capacity n is written into the configmap for the container to read, and each container at most handles n sessions in parallel, and the load balancing at most allocates n sessions to each container.

[0051] The method for calculating the optimal design capacity is improved by combining the prior art;

[0052] The mathematical analysis of the influence of the existing container granularity size on resource consumption is as follows:

[0053] Suppose the fixed overhead (memory) of each container is M0, and the resource M1 is consumed to process each session (TCP or UDP, and the "design capacity" or "granularity" refers to how many sessions each container can ensure to handle in parallel at most), and the available resource (memory) of each node (i.e. a device) is M, and the maximum number of sessions handled by each container is designed as n (i.e. design capacity).

[0054] The overhead x of each container is linearly related to the design capacity, that is:

[0055] x = M0 + nM1

[0056] We set two indicators

[0057] (1) Extra memory consumption EM (extramemorycost) : It refers to the sum of the fixed overhead of all containers in a node (device), which increases with the increase of the number of containers.

[0058] (2) Wasted memory WM (wastedmemory) : It refers to the surplus memory of the system, but this part of memory cannot meet the application requirements of the pod and can only be idle.

[0059] Under this setting, there are two extreme cases:

[0060] (1) Maximum granularity

[0061] When the node resource runs out of containers, the remaining resource is not enough to construct a container, that is:

[0062] 0 ≤ WM < x

[0063] Then the expected value is:

[0064]

[0065] As the granularity n increases, the overhead x of each container also increases, and the expected value of idle memory also increases. When the granularity is infinite, the device can create 0 containers, and all resources are wasted.

[0066] like Figure 5 As shown, the larger the granularity, the greater the resource x consumed by a single container, and the greater the expected value x / 2 of WM. In this case, most of the system's resources are wasted on WM.

[0067] The available resources M of the system are the sum of all the boxes in the diagram, that is, the sum of all M1, M0, and WM.

[0068] (2) Smallest particle size

[0069] In this scenario, each container can only handle one business connection, meaning each pod will consume an additional M0 of memory, which is also M0 on average per pod.

[0070] As we can see, designing pods with the largest or smallest granularity will result in a huge waste of system resources. Therefore, we need to study how to select an intermediate value as the optimal granularity.

[0071] When the container fills the device, the total fixed cost is:

[0072]

[0073] when If the result is not divisible, rounding down is used, and the deviation of EM is at most M0. In a safety protection container, M0 is less than 100M, and the available system memory is usually greater than 14G, so this deviation can be ignored.

[0074] When x takes the minimum value of 1, EM is at its maximum, and the fixed cost is the highest.

[0075] like Figure 6 As shown, in the case of the smallest granularity (i.e., 1), each pod only accommodates one session. The dashed line in the diagram represents EM, which is the sum of the fixed overhead of all containers. Idle memory (WM) represents the resources that are idle because they cannot meet the overhead of a single container. In this case, most of the system's resources are wasted on EM (i.e., the dashed line).

[0076] The available resources M of the system are the sum of all the boxes in the diagram, that is, the sum of all M1, M0, and WM.

[0077] Existing technologies use fixed container design capacities. As can be seen from the above analysis, the disadvantage of this approach is low resource utilization, leading to two types of resource waste:

[0078] (1) The remaining available resources of the node are small, and cannot meet the demand of the design capacity of a container, resulting in that the container cannot be created, and the system cannot provide services, and at this time, the resource utilization rate is 0.

[0079] (2) The remaining available resources of the node are sufficient, and the design capacity of the container is too small, resulting in too many containers and too large fixed overhead proportion.

[0080] As can be seen from the above, when the design capacity of the container does not match the system resources, the container fixed overhead and the single session overhead, resource waste will be caused. Therefore, the present application discards the traditional fixed design capacity method, and proposes a new pilot engine module in the cluster architecture as a service launcher.

[0081] The following analyzes the calculation method of the optimal design capacity:

[0082] As can be seen from the above, the overhead of the container is divided into two categories: fixed overhead and unavailable resources, and the sum is:

[0083] Where x is the independent variable, and y is the dependent variable.

[0084]

[0085] When y takes the minimum value , we have:

[0086] At this time, the solution is

[0087] After substituting x=M0+nM1, the value of n at this time is:

[0088]

[0089] The above is the derivation process of the optimal design capacity n, which is determined by M, M0 and M1. With the change of the available memory M of the system in different running environments, the optimal design capacity n also changes.

[0090] Embodiment 2

[0091] The embodiment provides a granularity adaptive cluster management system service creation device, which comprises a pilot engine and a cluster management system connected with each other in communication, and is applied to the pilot engine and comprises:

[0092] A real-time resource data acquisition unit is configured to send a real-time resource data request to each working node in the cluster management system and acquire real-time resource data.

[0093] An optimal design capacity calculation unit is configured to read the real-time resource data and calculate the optimal design capacity.

[0094] A configuration file writing unit is configured to write the optimal design capacity into a configuration file, trigger a cluster management system to create a service, and create a container.

[0095] Specifically, the optimal design capacity calculation unit calculates the optimal design capacity according to the following formula:

[0096]

[0097] wherein n is the optimal design capacity, M is the available memory of each node of the system, M0 is the fixed memory of each container, and M1 is the memory consumed for processing each session.

[0098] Specifically, the configuration file writing unit writes the configuration file, including writing the limit and request fields in the service configuration file, denoted as LR, and determining LR = M0 + nM1 according to the optimal design capacity n, the fixed overhead M0, and the single-session overhead M1.

[0099] The optimal design capacity n is written into a configmap for the container to read, and each container can at most process n sessions in parallel, and the load balancing can at most allocate n sessions to each container.

[0100] Embodiment 3

[0101] As shown in Figure 2 , Figure 3 The embodiment provides a granular adaptive cluster management system service creation system, which comprises a pilot engine and a cluster management system in communication with each other, and the pilot engine comprises:

[0102] A resource detector, which is internally connected to the real-time resource data acquisition unit of any one of the devices in Embodiment 2;

[0103] A design capacity calculator, which is internally connected to the optimal design capacity calculation unit of any one of the devices in Embodiment 2;

[0104] A service creation engine, which is internally connected to the configuration file writing unit of any one of the devices in Embodiment 2.

[0105] Specifically, the resource monitor is a component for collecting real-time available resources of the cluster worker nodes, and the resource monitor sends a TCP message to the worker nodes through a software program to request real-time resource data; the worker nodes obtain the real-time resource data through a system call method and respond with a TCP message.

[0106] Specifically, the design capacity calculator is further configured to obtain the fixed overhead and the single-session overhead of the service.

[0107] Specifically, the service creation engine writes the optimal design capacity output by the design capacity calculator into a configuration file and triggers the cluster management system to create a boundary security service.

[0108] The written configuration contains two parts:

[0109] One is the limit and request fields (denoted as LR) in the service configuration file (in yaml format), which are determined according to the optimal design capacity n, the fixed overhead M0, and the single-session overhead M1:

[0110] LR = M0 + nM1

[0111] The other is to write the optimal design capacity n into a configmap for the container to read. Each container can handle at most n sessions in parallel, and load balancing also allocates at most n sessions to each container.

[0112] Embodiment 4

[0113] This embodiment provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of any one of embodiments 1.

[0114] The above only describes the preferred embodiments of the present application. It should be noted that, for those skilled in the art, without departing from the technical principles of the present application, several improvements and modifications can be made, and these improvements and modifications should also be considered as the protection scope of the present application.

Claims

1. A granularity-adaptive cluster software definition method, characterized in that, include: Send real-time resource data requests to each worker node in the cluster management system to obtain real-time resource data; Read real-time resource data to calculate the optimal design capacity; Write the optimal design capacity into the configuration file to trigger the cluster management system to create services and containers; The real-time resource data includes fixed overhead and single-session overhead. The formula for calculating the optimal design capacity is as follows: Where n is the optimal design capacity, M is the average available memory per node in the cluster management system, M0 is the fixed overhead, and M1 is the single session overhead. The writing configuration file includes writing the limit and request fields in the service configuration file, denoted by LR, and determined based on the optimal design capacity n, fixed overhead M0, and single session overhead M1: ; The optimal design capacity n is written to the configmap for containers to read. Each container can process at most n sessions in parallel, and the load balancer can also allocate at most n sessions to each container.

2. A granularity-adaptive cluster management system service creation device, characterized in that, include: The real-time resource data acquisition unit is used to send real-time resource data requests to each worker node in the cluster management system to acquire real-time resource data. The real-time resource data includes fixed overhead and single-session overhead. The formula for calculating the optimal design capacity is as follows: Where n is the optimal design capacity, M is the average available memory per node in the cluster management system, M0 is the fixed overhead, and M1 is the single session overhead. The optimal design capacity calculation unit is used to read real-time resource data and calculate the optimal design capacity. The configuration file writing unit is used to write the optimal design capacity into the configuration file, triggering the cluster management system to create services and containers. Writing the configuration file includes writing the `limit` and `request` fields into the service configuration file, denoted by `LR`, and determined based on the optimal design capacity `n`, fixed overhead `M0`, and single-session overhead `M1`. ; The optimal design capacity n is written to the configmap for containers to read. Each container can process at most n sessions in parallel, and the load balancer can also allocate at most n sessions to each container.

3. A granular adaptive cluster management system service creation system, characterized in that, The system includes a pilot engine and a cluster management system that are interconnected, the pilot engine comprising: The resource monitor has a built-in real-time resource data acquisition unit of the device described in claim 2; The design capacity calculator incorporates the optimal design capacity calculation unit of the device described in claim 2. The service creation engine has a built-in configuration file writing unit for the device described in claim 2.

4. The granularity-adaptive cluster management system service creation system according to claim 3, characterized in that: The resource monitor is a component that collects real-time available resources of the cluster's worker nodes. The resource monitor sends TCP messages to the worker nodes through a software program to request real-time resource data; the worker nodes obtain the real-time resource data through system calls and respond with TCP messages.

5. The granularity-adaptive cluster management system service creation system according to claim 3, characterized in that: The design capacity calculator is also used to obtain the fixed overhead and single-session overhead of the service.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by the processor, it implements the steps of the method of claim 1.

Images