CN106775942A - Solid-state disk cache management system and method that a kind of cloud application is oriented to - Google Patents

Abstract

The present invention relates to a cloud application-oriented solid-state disk cache management system and method. Its core idea is to cut in from the perspective of cloud applications, use a multi-layer network model to describe the mapping relationship between virtual machines and solid-state disks, and further determine each The optimal SSD cache size for the virtual machine. When the workload of cloud applications changes, the system will automatically trigger the adjustment process to perform virtual machine dynamic migration and cache capacity changes, thereby improving the performance of cloud applications and improving the utilization of solid-state disks.

Description

A cloud application-oriented solid state disk cache management system and method

technical field

The present invention relates to a cloud application-oriented solid-state disk cache management system and method, in particular to a multi-layer network-based solid-state disk cache allocation and cache-oriented virtual machine dynamic migration method. It belongs to the field of software technology.

Background technique

Virtualization technology has been widely used at present. With the help of virtualization technology, multiple virtual machines can be aggregated (Consolidation) on one physical server, thereby effectively improving the utilization rate of hardware resources. A hard disk drive (HDD) based on magnetic media is usually deployed on a virtualization server (Hypervisor), or a large-capacity shared storage connected to the backend through a protocol such as iSCSI, and used to store virtual machine images. In this architecture, the IO performance of the virtualized server directly affects the performance of the virtual machine itself.

Solid State Disk (SSD), as a fast non-volatile medium, is usually deployed on the Hypervisor and used as a read-write cache for back-end virtual machine image storage. The IO request of the virtual machine will first go through the cache. If the cache hits, the cached data will be returned immediately, and will not further trigger relatively slow read and write operations for the back-end HDD or shared storage, thereby effectively improving IO performance. The SSD cache deployed on a Hypervisor is shared by all virtual machines hosted on the Hypervisor. Therefore, it is very important to use SSD cache resources reasonably.

Cloud applications are the main service model in a virtualized environment. A typical cloud application usually consists of multiple virtual machines. Different components are deployed on these virtual machines, which are related to each other and jointly provide external services. A typical cloud application scenario in a virtualized environment is a web-based transactional cloud application. This type of cloud application usually consists of a front-end load balancer, service middleware, and a back-end database or persistent storage. It usually provides an interface based on the HTTP(S) protocol for users to access through a browser, or opens such as a RESTful style The API is for third-party open platform applications to access. Such applications can also be connected to complex back-end transaction processing logic, such as social network graphs, big data analysis, etc. For this type of application, the average response time is the most critical indicator, which directly affects the experience of end users. Optimizing the response time requires overall consideration from the perspective of the application, and it is impossible to directly determine the optimization goal and means from the application cluster.

In addition, the load of the cloud application itself changes dynamically. Users have a certain mode of using the cloud application, which may be reflected in the virtual machine. It may appear as a completely different IO load performance. When performing SSD cache resource management, it is also necessary to have Self-adaptive capability, which can sense changes in the load pattern of cloud applications and trigger a new round of adjustments to SSD resources to ensure optimal application performance.

However, the current mainstream SSD cache resource management methods are usually considered from the perspective of the virtual machine and the cache itself, and mainly solve the resource allocation problem of the SSD cache. The goal is to allocate the SSD cache to all virtual machines as reasonably as possible, and achieve Best performance. The indicators that this type of work focuses on are the cache miss rate and related export indicators, such as the IO response time and IO bandwidth observed from the virtual machine. As the most critical indicator of the cache, the cache miss rate directly reflects the usage status of the cache, and is also closely related to the average IO response time of the client (that is, the virtual machine) that finally uses the cache. Therefore, reducing the cache miss rate is a key to improving IO performance. Intuitive and effective means. However, it is worth noting that simply starting from the underlying IO indicators ignores the impact of upper-layer workloads on the performance of the underlying storage devices, and there is a certain gap between the actual adjustment effect and the calculation results of the theoretical model.

In addition, this type of cache resource management method regards the virtual machine as an independent unit and adjusts it independently, without taking into account the natural correlation between virtual machines belonging to the same cloud application, and does not evaluate the overall average value of the application from the perspective of the application. Response time. Different virtual machines belonging to the same cloud application may have different priorities and IO loads, and may undertake different transaction processing. Adjusting the cache capacity of different virtual machines will have different effects on the average response time of the application. This may lead to the fact that although the optimal miss rate, IO response time, or IO bandwidth can be achieved from the perspective of each independent virtual machine during SSD cache resource management, the optimal performance cannot be achieved from the application perspective.

When a solid-state disk is used as a cache resource, in addition to the characteristics of a cache, it also has the characteristics of a storage medium, that is, its service capabilities, such as bandwidth and IO operations per second (Input/Output Operations PerSecond, IOPS), are There is an upper limit. When multiple virtual machines use a solid-state disk cache at the same time, and applications with high IO load are running on the virtual machines, the demand for the service capacity of the solid-state disk cache may exceed its supply, resulting in resource contention and eventually causing IO Requests are queued on the SSD side, causing the average latency of the SSD cache to be much higher than ideal, reducing the effectiveness of the cache.

Therefore, when managing cache resources, in addition to the allocation of SSD cache capacity, it is also necessary to consider the placement of virtual machines from the perspective of the cluster to maximize the use of SSD service capabilities and avoid resource contention as much as possible. It is necessary to combine the characteristics of cloud applications to select an appropriate Hypervisor for the virtual machine in the application, and further determine the SSD cache on the virtual machine hosted on the same Hypervisor based on the virtual machine's demand for SSD cache and the degree of impact on application performance. Specific allocation. Existing work does not well combine virtual machine placement with SSD resource allocation.

There is no relevant literature report yet.

Contents of the invention

The purpose of the present invention is to propose a cloud application-oriented solid-state disk cache management method and system for the deficiencies of the prior art. When the workload of the cloud application changes, the present invention will automatically trigger the adjustment process and perform virtual machine dynamic Migration and cache capacity changes, thereby improving the performance of cloud applications and improving the utilization of SSDs.

The technical solution of the present invention: a cloud application-oriented solid-state disk cache management method and system, as shown in Figure 1, mainly consists of a control module, a monitoring module, an analysis module and a decision-making module. The main responsibilities, interaction modes and implementation of each module are as follows:

Control module: used to coordinate the work of the monitoring module, analysis module, decision-making module and execution module, interact with each module and collect results, and realize SSD cache management based on adaptive closed-loop. In a complete closed-loop execution process, the control module first interacts with the monitoring module, and the dependency monitoring module continuously monitors the workload of cloud applications and the dependencies between virtual machines, and collects cloud application status and performance data for subsequent analysis; Interact with the analysis module, pass cloud application status and performance data to the analysis module, and collect relevant information about the generated multi-layer network model; then interact with the decision-making module, pass in the multi-layer network model and rely on the decision-making module to complete the solid-state disk Cache management decisions, such as the calculation of the virtual machine placement plan and the further calculation of the cache allocation plan on the Hypervisor; finally interact with the execution module to pass the specific SSD cache management decision, and the execution module completes the online migration of the specific virtual machine and Dynamic adjustment of cache capacity. The control module is also responsible for triggering a new round of closed-loop execution when a sudden change in the cloud application workload is detected;

Monitoring module: including the monitoring module deployed on the Hypervisor and the monitoring module deployed on the virtual machine; the monitoring module deployed on the Hypervisor is responsible for monitoring the relevant information of the Hypervisor, SSD and cache, and the relevant information includes the idle CPU and memory resources of the Hypervisor ; The maximum bandwidth and IOPS of the SSD, the currently used bandwidth and IOPS; the usage rate of the cache, the number of reads and writes, and the hit rate; the monitoring module deployed on the virtual machine is responsible for monitoring the relevant information and information of the cloud application components deployed on the virtual machine The IO performance of the virtual machine, the relevant information of cloud application components include the proportion of each transaction in the cloud application when dealing with the current workload and the execution time on each component, the network interaction and dependencies between components; the IO performance of the virtual machine includes The used bandwidth and IOPS, as well as the calculated IO load status of the virtual machine, that is, the ratio of the used IO resources to the available resources; the monitoring module will continuously monitor these information, and receive the control module's information during the closed-loop execution process Request, return the corresponding cloud application status and performance data for subsequent analysis and decision-making; during the execution of the adaptive closed-loop, the control module will first interact with the monitoring module to obtain necessary information for the subsequent analysis module, decision-making module and execution module usage;

Analysis module: used to receive the information transmitted by the monitoring module and build a multi-layer network model; the multi-layer network model includes resource demand end and resource supply end, as well as multiple decision-making layers for matching; through analysis deployment in virtual machine monitoring The network interaction of cloud application components and virtual machine IO performance returned by the module builds a dependency graph between virtual machines, and further traverses all strongly connected components of the dependencies of all virtual machines in the cluster to describe cloud applications The boundary of the virtual machine; combined with the dependency graph and the IO load status of the virtual machine, the virtual machine's demand for the SSD cache is constructed, and the construction of the resource demand side is completed; after that, the analysis module will assemble the decision-making module that needs to be called and adapt to the resource supply of the backend end, to complete the construction of a multi-layer network model; during the execution of the self-adaptive closed-loop, the control module will pass the relevant information of the cloud application and the IO performance information of the virtual machine collected from the monitoring module to the analysis module, and receive the analysis module The calculated topological structure of the multi-layer network model and the selected decision-making layer are used for subsequent interaction with the decision-making module;

Decision-making module: used to match the supply side and demand side in the multi-layer network model to achieve the optimal matching of resource supply and demand; the decision-making module is based on a specific algorithm to achieve the goal of resource management, which is represented as the decision-making layer in the multi-layer network; At present, there are two default decision-making layers. The first decision-making layer uses the bipartite graph matching algorithm to calculate the placement plan of the virtual machine; the second decision-making layer uses the minimum cost maximum flow algorithm in the network flow to calculate the allocation of virtual machines on each hypervisor. The optimal cache size; during implementation, more decision-making layers can be expanded according to different requirements; after the implementation control module receives the multi-layer network model returned by the analysis module, it will call the specified decision-making layer to complete the corresponding The calculation of the resource management plan completes the matching of the resource demand end and the resource supply end after invoking all the decision-making layers selected in the model, and generates the final resource management plan, including the placement plan of the virtual machine and the cache allocation plan;

Execution module: deployed on the Hypervisor; the execution module accepts the virtual machine placement plan calculated by the decision-making module and the SSD cache size of the virtual machine on each Hypervisor, and performs specific virtual machine dynamic migration and cache capacity adjustment operations; the control module In the execution process of the adaptive closed-loop, it will interact with the execution module at the end, pass in the resource management plan generated by the decision-making module, and apply it to the virtual machine; in addition, when the control module triggers a new round of adaptive closed-loop execution At the same time, the execution module will also calculate the virtual machine dynamic migration plan with the least steps and the cache capacity adjustment plan that has the least impact on the workload on the virtual machine, and make adjustments; finally complete the cloud application-oriented SSD cache management.

The concrete realization of described control module is as follows:

(1) Build an adaptive closed-loop mechanism: the adaptive closed-loop consists of four steps: monitoring, analysis, decision-making, and execution. The four main steps are completed by the monitoring module, analysis module, decision-making module, and execution module. Adaptive closed-loop is the core control process of the cloud application-oriented SSD cache management method.

(2) On this basis, build a communication protocol to specify the information transmission format and interaction mode between the control module and the monitoring module, analysis module, decision-making module and execution module;

(3) Realize the interaction with the monitoring module, analysis module, decision-making module and execution module based on the communication protocol, and complete the execution of the adaptive closed-loop;

3.1 Call the monitoring module to continuously monitor cloud application information and performance information of virtual machines and Hypervisors;

3.2 Call the analysis module, import cloud application information and performance information, and build a multi-layer network model consisting of resource demand end, resource supply end and multiple decision-making layers;

3.3 According to the decision-making layer selected in the constructed multi-layer network model, call the specific decision-making module to complete resource supply and demand matching, and generate resource management decisions (including cache allocation and virtual machine migration);

3.4 According to the cache allocation and virtual machine migration decision generated by the decision-making module, call the execution module to complete the specific cache allocation operation and virtual machine migration operation;

(4) Build an adaptive closed-loop continuous triggering mechanism to trigger a new round of self-adaptation when a sudden change in cloud application load is detected (changes in the access mode of cloud applications, changes in dependencies, changes in the topology of virtual machines carrying cloud applications) Closed-loop execution;

The specific implementation of the monitoring module is as follows:

(1) Perform program instrumentation in the target cloud application to obtain fine-grained performance information;

1.1 For different types of cloud applications, select the cloud application function modules that need to be program-inserted;

1.2 Perform program instrumentation on these cloud application function modules deployed on the virtual machine, and write monitoring code. The main insertion points are network interactive operations (such as HTTP(S), TCP, UDP connections, etc.) and persistent operations (such as database operations, etc.);

1.3 The monitoring code transmits messages by outputting logs;

(2) On the basis of program instrumentation, collect and monitor code output logs, calculate and obtain the execution time of each module of the cloud application when processing user requests, and the network interaction and dependency relationship between the various modules that make up the cloud application;

(3) deploy agent (Agent) module on virtual machine and Hypervisor;

3.1 The agent module deployed on the virtual machine is used to monitor the IO performance information of the virtual machine, including bandwidth and IOPS;

3.2 The proxy module deployed on the Hypervisor is used to monitor cache related information, including cache usage and read/write hit rate.

(4) The monitoring module interacts with the agent module to collect relevant performance data;

(5) Organize the execution time, network interaction and dependencies of each module of the cloud application output by the monitoring code and the agent module, as well as the performance information of the virtual machine and the Hypervisor, as the output of the monitoring module.

The specific implementation of the analysis module is as follows:

(1) Accept the information passed in by the control module, and generate the resource demand end:

1.1 The topology of the cloud application, the association between application components and the dependency information are transmitted by the control module;

1.2 The IO load information transmitted to the virtual machine by the control module;

1.3 By calculating the network interaction of each component of the cloud application, build a dependency graph between virtual machines, and further find out the strongly connected components in it to describe the boundary of the cloud application;

1.4 By calculating the network and IO load between the components of the cloud application, describe the IO dependency between the components of the cloud application;

1.5 From the IO load of each component of the cloud application and the IO dependence on other components, describe the demand of the cloud application for the SSD cache;

(2) Accept the incoming information from the control module and generate the resource supply end:

2.1 Accept the Hypervisor resource information from the control module, mainly including CPU performance, memory capacity and network bandwidth

2.2 Accept the resource information of the solid state disk from the control module, including the capacity, bandwidth and IOPS of the solid state disk

2.3 Quantify the resources of CPU, memory, network and solid-state disk with a unified score, and build a resource supply end;

(3) Determine the decision-making modules to be used according to the matching requirements of the resource demand side and the resource supply side, and build a multi-layer decision-making layer;

(4) Combining the resource supply end, resource demand end and multi-layer decision-making layer into a multi-layer network model for use by the decision-making module;

The concrete realization of described decision-making module is as follows:

(1) The quantified resource supply end and resource demand end are passed in from the control module;

(2) The information of the decision-making layer that needs to be combined is passed in by the control module;

(3) Call the specific decision-making layer to complete the matching of the resource supply end and the resource demand end, and generate an adjustment plan, mainly including the virtual machine cache capacity allocation plan and the virtual machine placement plan;

(4) Send the adjustment plan back to the control module for use by the execution module;

The specific implementation of the execution module is as follows:

(1) The solid state disk cache allocation scheme and the virtual machine placement scheme are imported by the control module;

(2) Safely remove the existing virtual machine cache;

(3) Starting from the virtual machine placement of the current cluster, calculate the virtual machine migration operation set;

(4) Perform virtual machine migration in accordance with the principle of minimizing service quality violations;

(5) Reconfigure the cache according to the solid state disk cache allocation scheme on the target virtual machine;

A cloud application-oriented solid state disk cache management method, the implementation steps are as follows:

(1) Perform program instrumentation (Instrumentation) in the target application, so as to support the monitoring module to carry out fine-grained monitoring of cloud applications; for specific application types and cloud application modules carried on virtual machines, HTTP(S) access operations As well as the access operations of the database and persistent storage, the instrumentation code will output the execution time and access target of the operation in the form of logs.

(2) The control module starts a complete adaptive closed-loop execution. The control module first interacts with the monitoring module. Based on the logs output by the instrumentation code in step (1), the monitoring module analyzes and obtains the execution time of the cloud application on each module when responding to user requests, as well as the specific network interaction process and The network accesses the target and returns to the control module.

The control module interacts with the monitoring module, and the monitoring module calls the agent (Agent) module deployed on the Hypervisor and the virtual machine to perform performance monitoring. The Agent module deployed on the virtual machine will monitor the execution time of the disk IO operation, the average response time and bandwidth, and the IO load. The Agent module deployed on the Hypervisor will monitor the cache usage status, solid state disk status, and CPU, memory, and network resource usage status corresponding to each virtual machine. Cache usage status includes cache hit rate, usage rate, read and write operations, etc. SSD status includes bandwidth, IOPS, and average response time. The CPU, memory, and network resource usage status includes the currently used and idle CPU time, used and idle memory capacity, and used and idle network bandwidth. These performance data are finally returned to the control module.

(3) After obtaining the cloud application information and performance information returned by the monitoring module in steps (2) and (3), the control module transmits these information to the analysis module. The analysis module performs the construction of a multi-layer network model.

The first is to build the resource demand side. After the analysis module obtains the performance information, it combines the IO dependence of the virtual machine on other virtual machines in the cloud application, the IO load of the corresponding virtual machine, and the random access frequency to calculate the demand for the SSD cache of the virtual machine. After the analysis module obtains the cloud application information, it converts the dependency relationship and network interaction between the virtual machines constituting the cloud application into a dependency graph of the virtual machine. Nodes in the dependency graph represent independent modules that constitute cloud applications, and nodes correspond to virtual machines one-to-one. The weight on the directed edge represents the previously calculated demand of the virtual machine for the SSD cache. The state of a cloud application while executing a specific workload can be mapped as a subgraph of the dependency graph.

The second is to build a resource supply side. After the analysis module obtains the performance information, it quantifies the CPU, memory, network and SSD resources of the Hypervisor to build a unified resource supply model. CPU resources are quantified by CPU time, memory resources are quantified by capacity, network resources are quantified by bandwidth, and SSD resources are quantified by IOPS and capacity.

Finally, the analysis module determines the decision-making modules required for adjustment according to the current workload status of the cloud application, and determines the application sequence of the decision-making modules, which is constructed as a multi-layer decision-making layer.

The analysis module returns the completed multi-layer network model composed of resource supply end, resource demand end and multi-layer decision-making layer to the control module.

(4) The control module calls the corresponding decision-making module according to the order of the decision-making layers in the multi-layer network model, and passes the entire multi-layer network model to the decision-making module. The adjustment plan includes adjusting the cache capacity of the solid state disk of the virtual machine and adjusting the placement of the virtual machine. The decision module sends the adjustment plan back to the control module.

When making a decision on the virtual machine placement plan, the decision-making module converts it into a bipartite graph matching under specific constraints, that is, under the premise of satisfying the maximum service capacity (CPU, memory, network and SSD resources) of the supply side, all virtual machine. The decision-making module uses a bipartite graph matching algorithm to match the supply and demand of resources.

When making the SSD cache allocation decision of the virtual machine, the decision-making module converts it into the minimum cost optimal (maximum) flow problem on the subgraph, that is, the SSD cache is preferentially allocated to Cost-effective virtual machines. The decision-making module analyzes the value of different virtual machines under the current workload mode according to the relevant information of the incoming cloud application, maps it to the flow on the virtual machine dependency graph, and uses the minimum cost maximum flow algorithm to determine the value that each virtual machine should obtain SSD cache ratio, to complete the SSD cache allocation decision.

(5) After the control module obtains the adjustment plan, it transmits it to the execution module, and calls the execution module to complete the execution of the specific adjustment plan. The execution module first safely removes the SSD cache used by the current virtual machine, then calculates the optimized live migration sequence of virtual machines according to the current virtual machine placement scheme and the incoming target placement scheme, and then follows the principle of minimizing service quality violations The principle is to perform virtual machine dynamic migration, and finally perform cache allocation on the target virtual machine according to the incoming cache allocation scheme.

(6) Steps (2)-(5) constitute a complete adaptive closed-loop execution. The control module continuously invokes the monitoring module, and triggers a new round of adaptive closed-loop execution in the order of steps (2) to (5) when a sudden change in the workload of the cloud application is detected. The mutation of cloud application workload mainly manifests as mutation of workload composition mode (proportion of each request) and workload intensity (IO operation intensity on each node).

In addition, the control module sets a threshold to periodically trigger the adaptive closed-loop adjustment, that is, the execution of steps (2)-(6).

The advantage of the present invention compared with prior art is:

(1) The present invention takes into account the relationship between the virtual machines that make up the application. Virtual machines are naturally related to each other because they belong to the same application, but because related technologies consider virtual machines as independent units, these relationships are separated or ignored.

(2) Use a multi-layer network model to describe the relationship between virtual machines. The existing related art does not extract an abstract model with sufficient expressive power.

(3) The concept of software-defined SSD cache is introduced. The system can dynamically control the use of SSD cache from the two aspects of SSD cache allocation and SSD bandwidth management according to workload and user needs, so as to achieve a balance between demand and supply.

Description of drawings

Fig. 1 is a system architecture diagram of the present invention;

Fig. 2 is the implementation flowchart of the present invention;

Fig. 3 is the operation flowchart of monitoring module;

Fig. 4 is the operation flowchart of analysis module;

Fig. 5 is the operation flowchart of decision-making module;

Fig. 6 is a flow chart of the execution module.

detailed description

The present invention will be described in more detail below in conjunction with specific embodiments and accompanying drawings.

The present invention proposes a cloud application-aware solid state disk cache management method and system. This system is mainly composed of control module, monitoring module, analysis module, decision-making module and execution module, and its main deployment mode is shown in Figure 1. The control module is deployed on an independent virtual machine or physical machine, coordinates the monitoring module, analysis module, decision-making module and execution module to complete the execution of the adaptive closed-loop, and triggers a new round of self-adaptation when a sudden change in the cloud application workload is detected Closed-loop execution. The monitoring module is deployed on the Hypervisor and the virtual machine, and is used to collect the performance information of the Hypervisor and the virtual machine, including the resource information of the Hypervisor's CPU, memory, network and solid state disk, and the IO load status of the virtual machine. The analysis module is deployed on an independent virtual machine or physical machine to receive the information generated by the monitoring module and build a multi-layer network model. The decision-making module is deployed on an independent virtual machine or physical machine. By executing specific algorithms (bipartite graph matching and minimum cost maximum flow), the resource supply and demand matching is completed, and a virtual machine placement plan and a cache capacity adjustment plan are generated. The execution module is deployed on the Hypervisor, and is used to calculate the dynamic migration order of the virtual machines from the generated virtual machine placement scheme, and execute specific virtual machine dynamic migration and cache allocation operations.

The specific steps are described below with an example, as shown in FIG. 2 . The target cloud application of the example of the present invention is based on the Java language construction, the Web front-end application server is Apache Tomcat, the application server carrying the service middleware is also Apache Tomcat, and the back-end database server is MySQL. In addition, the virtual machine hosting these components is a Linux operating system. A physical machine cluster consists of physical Hypervisors, each of which is connected to the same shared storage and deployed with independent SSDs. Each Hypervisor hosts multiple virtual machines, and multiple cloud applications are deployed on the virtual machine cluster, and the virtual machines belonging to the cloud applications may be located on different Hypervisors.

The specific steps for this example are as follows:

(1) Perform program instrumentation in the target application. For cloud applications based on Java and Apache Tomcat, the Servlet is mainly instrumented to obtain all request types that the cloud application can accept; further, the part of the Servlet that invokes HTTP requests and JDBC connections is instrumented to obtain The call chain and dependency between different components of the cloud application, as well as the access of the cloud application to the back-end database; finally, the file operation is instrumented to obtain relevant information about reading and writing files during program execution. The instrumentation code will output the log to a text file to give the execution time and access target of the operation.

(2) The control module starts a complete adaptive closed-loop execution. The control module first interacts with the monitoring module, and the execution flow of the monitoring module is shown in Figure 3. Based on the logs output by the plug-in code in step (1), analyze the execution time of the cloud application on each module when responding to user requests, as well as the specific network interaction process and network access target, and return it to the control module.

In this example, the workload of the cloud application can be characterized as a collection of web requests initiated by users to the cloud application within a specific period of time. After sensing all the request types that the cloud application can accept, the monitoring module monitors the time spent on each component when the cloud application is dealing with a specific workload; since the file operations of the application components have been monitored, Therefore, these times can be further divided into IO time and non-IO time, and the IO time can be divided into IO time of sequential read and write operations and random read and write operations, and finally get the cloud application on each module when responding to user requests execution time.

In order to further monitor the network interaction process and network access target, the monitoring module will monitor the process on the virtual machine, and realize it through the ps command and the built-in /proc file system in the Linux environment. For processes of special concern, such as java and mysqld, its command line parameters will be further analyzed to obtain the instance locations of Apache Tomcat and MySQL, and thus obtain configuration files and related configuration parameters, mainly including Apache Tomcat open port information, and MySQL The database file location information and port information. This information is matched with the logs returned by the instrumentation code, and network access information can be obtained.

When monitoring the usage status of virtual machines and Hypervisor-related resources, it is mainly implemented with the help of the sysstat toolkit in the Linux environment. CPU monitoring is implemented through the mpstat command; memory monitoring directly accesses the /proc file system that comes with Linux; disk monitoring is implemented through the iostat command; network connection monitoring is implemented through the netstat command, and network traffic monitoring is implemented through the Linux kernel API.

When monitoring the cache usage status of the virtual machine, it is mainly realized by monitoring the status of the solid-state disk cache bound to the virtual machine on the Hypervisor. Solid state disk cache is implemented based on dm-cache of Linux. By calling the specific method of dm-cache, the solid state disk cache status is obtained, and the cache utilization rate, hit rate and solid state disk utilization rate are mainly monitored.

(3) After obtaining the cloud application information and performance information returned by the monitoring module in steps (2) and (3), the control module transmits these information to the analysis module. The analysis module will execute the construction of a multi-layer network model, and its specific execution process is shown in Figure 4.

The first is to build the resource demand side. After the analysis module obtains the performance information, it combines the IO dependence of the virtual machine on other virtual machines in the cloud application, the IO load of the corresponding virtual machine, and the random access frequency to calculate the demand for the SSD cache of the virtual machine. After the analysis module obtains the cloud application information, it converts the dependency relationship and network interaction between the virtual machines constituting the cloud application into a dependency graph of the virtual machine. Nodes in the dependency graph represent independent modules that constitute cloud applications, and nodes correspond to virtual machines one-to-one. The weight on the directed edge represents the previously calculated demand of the virtual machine for the SSD cache. The state of a cloud application while executing a specific workload can be mapped as a subgraph of the dependency graph.

In this example, according to the monitored cloud application boundary (that is, all virtual machines included in the cloud application) and the network connections established between the virtual machines, a dependency graph of the cloud application is constructed. Afterwards, the dependency diagram of the cloud application is refined to describe the importance of each component. The final cloud application dependency graph includes dependencies between components and their dependencies on IO capabilities of other components, thus forming the demand side of the multi-layer network model.

The second is to build a resource supply side. After the analysis module obtains the performance information, it quantifies the CPU, memory, network and SSD resources of the Hypervisor to build a unified resource supply model. CPU resources are quantified by CPU time, memory resources are quantified by capacity, network resources are quantified by bandwidth, and SSD resources are quantified by IOPS and capacity.

In this example, the resource provider is constructed based on the deployment relationship of the physical cluster, combined with the resource usage and maximum resource supply capacity of the physical machine and SSD cache monitored on the Hypervisor.

Finally, the analysis module determines the decision-making modules required for adjustment according to the current workload status of the cloud application, and determines the application sequence of the decision-making modules, which is constructed as a multi-layer decision-making layer. In this example, the analysis module configures the supply and demand relationship between the resource demand side and the resource supply side, cooperates with the dynamic plug-in mechanism of the policy layer, configures the two-layer strategy layer of optimization of virtual machine placement scheme and optimization of SSD cache capacity allocation, and finally completes the multi-layer Construction of network models.

The analysis module returns the completed multi-layer network model composed of resource supply end, resource demand end and multi-layer decision-making layer to the control module.

(4) The control module calls the corresponding decision-making module according to the order of the decision-making layers in the multi-layer network model. The execution flow of the decision-making module is shown in Figure 5. The control module passes the entire multi-layer network model to the decision-making module, and the decision-making module realizes the matching of resource supply and demand according to different strategies, and finally derives an adjustment plan for solid-state disk resources, including adjusting the virtual machine's solid-state disk cache capacity and adjusting the virtual machine to adjust the placement. The decision module sends the adjustment plan back to the control module.

When making a decision on the virtual machine placement plan, the decision-making module converts it into a bipartite graph matching under specific constraints, that is, under the premise of satisfying the maximum service capacity (CPU, memory, network and SSD resources) of the supply side, all virtual machine. The decision-making module uses a bipartite graph matching algorithm to match the supply and demand of resources.

When making the SSD cache allocation decision of the virtual machine, the decision-making module converts it into the minimum cost optimal (maximum) flow problem on the subgraph, that is, the SSD cache is preferentially allocated to Cost-effective virtual machines. The decision-making module analyzes the value of different virtual machines under the current workload mode according to the relevant information of the incoming cloud application, maps it to the flow on the virtual machine dependency graph, and uses the minimum cost maximum flow algorithm to determine the value that each virtual machine should obtain SSD cache ratio, to complete the SSD cache allocation decision.

(5) After the control module obtains the adjustment plan, it passes it to the execution module, and calls the execution module to complete the execution of the specific adjustment plan. The execution flow of the execution module is shown in Figure 6. The execution module first safely removes the SSD cache used by the current virtual machine, then calculates the optimized live migration sequence of virtual machines according to the current virtual machine placement scheme and the incoming target placement scheme, and then follows the principle of minimizing service quality violations The principle is to perform virtual machine dynamic migration, and finally perform cache allocation on the target virtual machine according to the incoming cache allocation scheme.

(6) Steps (2)-(5) constitute a complete adaptive closed-loop execution. The control module continuously invokes the monitoring module, and triggers a new round of adaptive closed-loop execution in the order of steps (2) to (5) when a sudden change in the workload of the cloud application is detected. The mutation of cloud application workload mainly manifests as mutation of workload composition mode (proportion of each request) and workload intensity (IO operation intensity on each node).

In addition, the control module sets a threshold to periodically trigger the adaptive closed-loop adjustment, that is, the execution of steps (2)-(6).

Although specific embodiments and drawings of the present invention are disclosed for the purpose of illustration, the purpose is to help understand the content of the present invention and implement it accordingly, but those skilled in the art can understand that: without departing from the present invention and the appended claims Various substitutions, changes and modifications are possible within the spirit and scope of . Therefore, the present invention should not be limited to what is disclosed in the preferred embodiments and drawings.

Claims (2)

1. the solid-state disk cache management system that a kind of cloud application is oriented to, it is characterised in that including：Control module, monitoring modular, point Analysis module, decision-making module and performing module；

Control module：For coordinating monitoring modular, analysis module, decision-making module and the work of performing module, carried out with each module Result is interacted and collected, solid-state disk cache management is realized based on self-adapting closed loop, in a complete closed loop implementation procedure, control Molding block is interacted with monitoring modular first, is relied on monitoring modular and is continued to monitor between the workload and virtual machine of cloud application Dependence, and collect cloud application state and performance data is used for subsequent analysis；Interacted with analysis module afterwards, will Cloud application state and performance data pass to analysis module, and collect the relevant information of the Multi-Layered Network Model of generation；Afterwards with Decision-making module is interacted, and incoming Multi-Layered Network Model simultaneously relies on decision-making module completion solid-state disk cache management decision-making, including void The calculating of allocative decision is cached in the calculating of plan machine placement schemes and further Hypervisor；Finally enter with performing module Row interaction, transmits specific solid-state disk cache management decision-making, by performing module complete specific virtual machine online migration and The dynamic adjustment of buffer memory capacity；Control module is also responsible for detecting triggering new round when cloud application workload is undergone mutation Closed loop is performed；

Monitoring modular：Including the monitoring modular that is deployed on Hypervisor and deployment monitoring modular on a virtual machine；Deployment Monitoring modular on Hypervisor is responsible for monitoring the relevant information of Hypervisor, solid-state disk and caching, relevant information Idle CPU and memory source including Hypervisor；The maximum bandwidth and IOPS of solid-state disk, currently used bandwidth and IOPS；The utilization rate of caching, read-write number of times and hit rate；Deployment monitoring modular on a virtual machine is responsible for monitoring virtual machine top The relevant information of the cloud application component of administration and the IO performances of virtual machine, the relevant information of cloud application component include cloud application in reply Each affairs proportion and the execution time on each component during current work load, the network interaction of inter-module and dependence are closed System；The IO performances of virtual machine include the bandwidth that has used and IOPS, and the virtual machine being thus calculated I/O load situation, The I/O resource for having used accounts for the ratio of available resources；Monitoring modular can continue to monitor these information, and in closed loop implementation procedure The middle request for receiving control module, returns to corresponding cloud application state and performance data is used for subsequent analysis, decision-making；Control mould Block can be interacted with monitoring modular first in the implementation procedure of self-adapting closed loop, and subsequent analysis are supplied to obtain necessary information Module, decision-making module and performing module are used；

Analysis module：For receiving the information of monitoring modular transmission, and build Multi-Layered Network Model；Multi-Layered Network Model includes money Source demand end and resource provision end, and the multiple decision-making levels for matching；Monitoring modular in virtual machine is deployed in by analysis The network interaction situation and virtual machine IO performances of the cloud application component passed back, construct the dependence graph between virtual machine, and All strong continune components of the dependence of all virtual machines in cluster are further traveled through out, so as to portray the border of cloud application； I/O load situation in conjunction with dependence graph and virtual machine constructs the demand that virtual machine is cached to solid-state disk, and completing resource needs Seek the structure at end；Afterwards, analysis module can assemble the needs decision-making module for calling and the resource provision end for being adapted to rear end, complete many The structure of layer network model；Control module can be obtained in the implementation procedure of self-adapting closed loop by being collected from monitoring modular The relevant information and virtual machine IO performance informations of cloud application pass to analysis module, and receive the multilayer that analysis module is calculated The topological structure of network model and the decision-making level for wherein choosing, use during for subsequently being interacted with decision-making module；

Decision-making module：For matching the supply side in Multi-Layered Network Model and demand end, the optimal of resource provision and demand is realized Change matching；Decision-making module is based on special algorithm to realize the target of resource management, shows as the decision-making level in multitiered network；At present Comprising two decision-making levels of acquiescence, the first decision-making level calculates the placement schemes of virtual machine using bipartite graph matching algorithm；Second determines Plan layer calculates should being allocated for virtual machine on each Hypervisor using the least cost maximum-flow algorithm in network flow Optimal cache size；Difference more decision-making levels can be expanded during implementation according to demand；Received than carrying out control module After the Multi-Layered Network Model that analysis module is passed back, the decision-making level for wherein specifying can be called, to complete corresponding resource management side The calculating of case, completed after all decision-making levels chosen in having called model resource requirement end and resource provision end Match somebody with somebody, and generate final resource management scheme, including virtual machine placement schemes and caching allocative decision；

Performing module：It is deployed on Hypervisor；The virtual machine placement schemes that performing module acceptance decision module is calculated With the solid-state disk cache size of the virtual machine on each Hypervisor, the dynamic migration and caching appearance of specific virtual machine are performed Amount adjustment operation；Control module can be interacted finally in the implementation procedure of self-adapting closed loop with performing module, incoming by certainly The resource management scheme of plan module generation, applies it on virtual machine；Additionally, when control module triggers new round self adaptation When closed loop is performed, performing module can also calculate the dynamic migration of virtual machine scheme of minimal steps and to workload on virtual machine Minimum buffer memory capacity Adjusted Option is influenceed, and is adjusted；It is finally completed the solid-state disk cache management of cloud application guiding.

2. the solid-state disk buffer memory management method that a kind of cloud application is oriented to, it is characterised in that realize that step is as follows：

(1) program inserting (Instrumentation) is carried out in intended application, so as to support that monitoring modular is carried out to cloud application Fine-grained monitoring；For on specific application type and virtual machine carry cloud application module, to HTTP (S) access operation with And the access operation of database and persistent storage is inserted, inserting code can provide operation by way of output journal Execution time and access target；

(2) control module starts once complete self-adapting closed loop execution, and control module is interacted with monitoring modular, supervised first Survey module obtain (1st) step inserting code output daily record on the basis of, analysis obtain cloud application tackle user's request when Execution time and specific network interaction flow and network access target on modules, and return to control module；

Control module is interacted with monitoring modular, and monitoring modular calls the agency being deployed on Hypervisor and virtual machine (Agent) module, carries out performance monitoring；Deployment Agent modules on a virtual machine can monitor the execution time of disk I/O operation, Average response time and bandwidth, and I/O load.The Agent modules being deployed on Hypervisor can monitor each virtual machine correspondence Caching behaviour in service, solid-state disk situation and CPU, internal memory, Internet usage situation；Caching behaviour in service includes cache hit Rate, utilization rate, read-write operation number of times etc.；Bandwidth, IOPS and average response time that solid-state disk situation includes；CPU, internal memory, net Network resource behaviour in service include it is current use and the idle CPU time, used and the free time memory size, and used and the free time The network bandwidth, these performance datas are finally returned that to control module；

(3) after (2nd), the cloud application information that is returned by monitoring modular of (3) step and performance information is obtained, control module by this To analysis module, analysis module can perform the structure of Multi-Layered Network Model to a little information transmissions；

First it is to build resource requirement end, analysis module is obtained after performance information, empty to other with reference to virtual machine in cloud application The IO dependences of plan machine, the I/O load of corresponding virtual machine and random access frequency are calculated what virtual machine was cached to solid-state disk Demand；Analysis module is obtained after cloud application information, by dependence and network interaction between the virtual machine for constituting cloud application The dependency graph of virtual machine is converted into, the node on behalf in dependency graph constitutes the standalone module of cloud application, node and virtual machine one One correspondence, the demand that the virtual machine that the weight on directed edge is calculated before representing is cached to solid-state disk, cloud application is being performed Situation when particular job is loaded can be mapped as the subgraph of dependence graph；

Next to that building resource provision end, analysis module is obtained after performance information, by the CPU of Hypervisor, internal memory and net Network and solid-state disk resource are quantified, and build unified resource provision model, and cpu resource is quantified by index of the CPU time, Memory source is quantified by index of capacity, and Internet resources are quantified with a width of index of band, solid-state disk resource with IOPS and Capacity is quantified for index；

Finally, analysis module it is determined that adjusting required decision-making module, and determines to determine according to the current work load situation of cloud application The application order of plan module, is configured to multilevel policy decision layer；

Analysis module will build the Multi-Layered Network Model being made up of resource provision end, resource requirement end and multilevel policy decision layer for completing Return to control module；

(4) decision-making level order of the control module in Multi-Layered Network Model calls corresponding decision-making module, by whole Multilayer Network Network Model Transfer is realized the matching of resource supply and demand by decision-making module to decision-making module according to Different Strategies, finally derives solid-state disk The Adjusted Option of resource, including be adjusted to the solid-state disk buffer memory capacity of virtual machine, and the placement of virtual machine is adjusted Whole, Adjusted Option is sent back to control module by decision-making module；

When the decision-making of virtual machine placement schemes is carried out, decision-making module is translated into the bipartite graph under the conditions of particular constraints Match somebody with somebody, i.e., in the maximum service ability at the end that furnishes good supplies to, including CPU, internal memory, network and equiblibrium mass distribution on the premise of solid-state disk resource All virtual machines, decision-making module realizes the supply-demand mode of resource using bipartite graph matching algorithm；

When the solid-state disk for carrying out virtual machine caches Decision of Allocation, the least cost that decision-making module is translated on subgraph is optimal Or maximum flow problem, i.e., it is preferential under conditions of the limitation of solid-state disk buffer memory capacity is met that solid-state disk caching is distributed into high performance-price ratio Virtual machine, decision-making module analyzes different virtual machine under current work load pattern according to the relevant information of incoming cloud application Value, maps that to the flow on virtual machine dependency graph, so as to determine every virtual machine using the least cost maximum-flow algorithm The solid-state disk caching ratio that should be obtained, completes solid-state disk caching Decision of Allocation；

(5) after control module is adjusted scheme, performing module is passed it to, and call performing module to complete specific adjustment side The execution of case, performing module safely removes the solid-state disk caching that current virtual machine is used first, then according to current void The dynamic migration of virtual machine of plan machine placement schemes and incoming target placement schemes calculation optimization sequentially, is then followed and dropped as far as possible The principle of low service quality promise breaking performs dynamic migration of virtual machine, finally according to incoming caching distribution side on target virtual machine Case carries out caching distribution；

(6) step (2)~(5) constitute once complete self-adapting closed loop and perform, and control module persistently calls monitoring modular, Held according to the self-adapting closed loop of a sequence trigger switch new round for step (2)~(5) when monitoring that cloud application workload is undergone mutation OK, cloud application workload mutation is mainly shown as the compositional model of workload, i.e., each request proportion is undergone mutation, with And the intensity of workload, i.e., the I/O operation intensity on each node undergos mutation；

Additionally, control module sets threshold value, periodically to trigger self-adapting closed loop adjustment, the i.e. execution of step (2)~(6).