Workload management for computing cluster

Performance predictions in a computing cluster can be provided by sampling and storing historic workload request data of the computing cluster as time-stamped workload values, forecasting an expected total number of workload requests for a defined time interval in the future based on a time-series analysis of the time-stamped workload values, where the time-series analysis detects cyclic and repeating events in the time-stamped workload values. In response to a result of the time-series analysis, training a workload prediction model by using additional data about acyclic events in expected workload requests, where the training applies a statistical regression technique for predicting a future workload demand for the computing cluster, and in response to exceeding a predefined threshold value of the predicted future workload demand, reassigning resources of the computing cluster.

BACKGROUND

The present disclosure relates generally to performance predictions, and more specifically, to performance predictions in a computing cluster.

The IBM Z system with its z/OS® operating system offers high performance, availability, scalability, security, and real-time reaction to business opportunities and needs based on resource de-/allocation on demand. (z/OS is a registered trademark of IBM Corporation.) Capacity planning, which is required for meeting service needs, cost planning, and business demands, plays an important role in the z/OS field. Capacity planning provides information on the number of resources needed (e.g., processors, storage, etc.), the workload distribution, and consumption as well as deciding when resources need to be de-/provisioned.

SUMMARY

According to one aspect of the present disclosure, a method for performance predictions in a computing cluster can be provided. The method can comprise sampling and storing historic workload request data of the computing cluster as time-stamped workload values and forecasting an expected total number of workload requests for a defined time interval in the future based on a time-series analysis of the time-stamped workload values, where the time-series analysis detects cyclic and repeating events in the time-stamped workload values. Additionally, the method can comprise, in response to a result of the time-series analysis, training a workload prediction model by using additional data about acyclic events in expected workload requests. The training can apply a statistical regression technique for predicting a future workload demand for the computing cluster, and upon exceeding a predefined threshold value of the predicted future workload demand, reassigning resources of the computing cluster.

Furthermore, other embodiments can take the form of a related computer program product storing program instructions configured to cause a processor to perform a method similar to the method described above. Furthermore, other embodiments can take the form of a system comprising a processor and a computer-readable storage medium storing instructions executable by the processor to cause the processor to perform a method similar to the method described above.

The above Summary is not intended to illustrate each embodiment of, or every aspect of, the present disclosure.

DETAILED DESCRIPTION

There is a need to do capacity planning based on recent data, or real-time data, that can help to detect a system's anomalies as well as analyze and predict the transaction rates and trends, workload resource consumption, and growth rates. Capacity planning can be exploited to improve system performance and/or efficiency, such as adding processing resources to the system or performing workload reclassification. Furthermore, it should be highlighted that inaccurate and/or imprecise analyses can lead to workload over- or under-commitment which is undesirable because it is related to both pricing and performance goals.

A motivating example from a real-world banking environment running both batch workload during night time and online transaction workload during day time and facing real-time capacity planning issues highlights the need for an automated analysis approach. An overnight batch workload needs to finish when the online workload begins in the morning. If not, the simultaneous workloads may overburden the system and prevent the banking customers from accessing their accounts. Currently, experts monitor the system environment in real-time, and if they expect their batch workload to run too long, they add additional, costly computing resources. The expert's judgement, however, is based on experience and intuition. This can lead to misinterpretation and inefficiency.

The following limitations can be observed with the traditional approaches: today, tasks for capacity planning on a Z sysplex, i.e. a cluster of Z servers, are performed manually by experts based on their experience. Meanwhile, the business demands and data to analyze are increasing dramatically. Thus, the current approach makes data analysis unfeasible and unreliable. Decisions that directly affect operations need to be made quickly to guarantee that workloads meet their goals. Wrong decisions can lead to large costs due to unsatisfied performance goals and/or wasted capacity. Typical approaches of offloading data from many systems into so-called data lakes can help for after-the-fact analysis, but fail to give suggestions at the time they are needed (e.g., when the decision of adding capacity needs to be made). Hence, the problem addressed by the present disclosure is knowing the future system and workload performance on z/OS clusters in an automated way in real-time without offloading the data off the cluster.

Some tools can assist in different types of system analyses, planning, and behavior forecasting. However, these tools have a common drawback: before the data can be analyzed and processed, it needs to be offloaded to a data lake, or some other type of storage method, that causes increased complexity, data duplication, and/or data movement, all of which can be time consuming and/or can lead to data loss.

In the context of this description, the following conventions, terms and/or expressions can be used.

The term “time-series analysis” can denote the collection of statistical approaches and algorithms and/or the process of the application thereof applied to time-series data points to obtain metrics or other information describing the time-series data points and/or to obtain models configured to forecast the time-series data points into the future, i.e., to predict unobserved future time-series data points based on the observed historic time-series data points with sufficient confidence.

The term “computing cluster” can denote a set of loosely or tightly connected computers or computing systems that work together, so that in many respects, they can be viewed as a single system. The components of a cluster can usually be connected to each other through fast local area networks, with each node (computer used as a server) running its own instance of an operating system. The operating system can, in some cases, differ from node to node. In some embodiments, all nodes use the same or similar hardware. However, embodiments exist in which the hardware differs significantly within the cluster.

The term “historic workload request data” can denote information collected, sampled, measured, and/or stored in the past about then current (i.e., in the past) workload requests. The workload request data can be time-stamped, so that the historic sequence of changing workloads can be available for further analysis.

The term “workload request” can denote addressing a request from one computer system to another computer system. There can also be internal workload requests from one process to another process or from one node in a cluster to another node.

The term “workload demand” can denote a result of one or more workload requests. The workload demand can be a measure for a load that a system or cluster is working on. The workload demand can be quantifiable, e.g., in number of transactions per time and/or a percentage of a utilization of the computer node.

The term “cyclic and repeating events” can denote events such as regular events in workloads for a computing cluster. This can reflect typical daily changes identifying peak workload hours or regular peak workload days in a week.

The term “training of a workload prediction model” can denote applying a machine learning technique based on a statistical regression method. This model can not only reflect regular and cyclic highs and lows in workload demands but also acyclic expected ups and downs in workload demands based on additional, calendar-based data, such as e.g., vacation periods, moving public holidays, or other society events influencing the computer usage. Additionally, system information about the computing cluster can be used as inputs for the training. Such additional system information can reflect planned downtimes due to maintenance of a computing node or related computing resources as well as information about system availability, such as for a portion of their computing cluster (e.g., the availability of a node and/or a CPU due to special license agreements or other contractual considerations).

The term “acyclic events” can denote known calendar-based future events like popular or planned vacation days, moving public holidays and/or other constraints influencing the usage of specific computing resources.

The term “reassigning resources” can denote releasing computing resources of a computing cluster for other purposes (i.e., other workloads or workload classes) or shutting such resources down if the expected workload shows a decreasing forecast. On the other hand, additional computing resources can be activated if the forecasting suggests an increasing demand for workloads for one or more workload classes.

The term “z/Architecture®” denotes an architecture model used by IBM for its mainframe computer system from z900 onwards. (z/Architecture is a registered trademark of IBM Corporation.) Multiple systems running the z/OS operating system can be coupled into a “Sysplex”, or, with Coupling Facility connectivity, “Parallel Sysplex®”. (Parallel Sysplex is a registered trademark of IBM Corporation.) A Parallel Sysplex can extend across one or more servers and can offer a single system view of multiple z/OS instances. Used for disaster recovery, Parallel Sysplex combines data sharing and parallel computing to allow a cluster of currently up to 32 systems to share a workload for high performance and high availability. This can allow authorized components in up to eight logical partitions (“LPARs”) to communicate and cooperate with each other using the so-called XCF protocol.

The term “computing node” can denote, e.g., one of the computing systems being part of a Parallel Sysplex, or any other type of computing cluster.

The term “central processing unit utilization” can denote a percentage of the total capacity of a CPU (central processing unit) of a computer system. Other related measurement techniques can comprise the number of transactions (or basic transactions) per time unit.

The term “R statistical language” can denote the language and environment for statistical computing and graphics. R is based on a GNU project which is similar to the S language and environment which was developed at Bell Laboratories (formerly AT&T, now Lucent Technologies) by John Chambers and colleagues. R can be considered as a different implementation of S. R can provide a wide variety of statistical techniques (e.g., linear and nonlinear modeling, classical statistical tests, time-series analysis, classification, clustering) and visualization techniques. R provides an Open Source route to use the broad set of statistical functions.

The term “Apache Spark” can denote the general engine for large-scale computing. It can offer APIs written for Java®, Scala, Python and R. (Java is a registered trademark of Oracle Corporation.) Available on z/OS are APIs (application programming interface) for Java, Scala and Python. Apache Spark also offers a machine learning library (MLLib), which features a multitude of implemented machine learning algorithms like K-Nearest-Neighbor, Random Forest, Gradient Boosted Tree and many more. The extensive Dataframe API can provide a pipeline for machine learning ranging from feature selection, feature extraction, and feature transformation to model training and model evaluation.

Aspects of the present disclosure use the time series analysis algorithm STL—but can be replaced by other algorithms—proposed by Cleveland, Cleveland, McRae, & Terpenning (1990) that is characterized by the decomposition of a time series into the three components (i) trend component, (ii) seasonal component, and (iii) remainder. The trend component describes whether the data generally rises or falls during the observation period. The seasonal component describes the cyclical aspect of the data. Finally, the remainder describes data that cannot be explained by the previous two components.

The term “Gradient Boosted Tree” can denote a supervised machine learning algorithm using an ensemble of decision trees, which can be used for regression and classification problems. The algorithm iteratively trains decision trees by minimizing a loss function. After each iteration, the prediction can be compared to the true value leading to a re-labelling of the dataset to emphasize training on the poorest predictions. In some embodiments, the decision tree can correct previous mistakes. Aspects of the present disclosure can use the Gradient Boosted Tree algorithm built into the Apache Spark MLLib.

The term “system management facility”—in short SMF—can denote a system tool that can be used on a mainframe system as part of the z/OS operating system for collecting system parameters and workload data in a time stamped manner. The sampled data can be stored in an SMF dataset (known as a “file”) on a persistent data storage system (e.g., a disk drive).

Aspects of the present disclosure can offer multiple advantages and technical effects.

Aspects of the present disclosure enable cluster computing operators, like z/OS system programmers and capacity planners, automated and robust management of their system. The present disclosure can analyze performance and workload management data originating on systems in a, e.g., z/OS sysplex, to make workload demand predictions for selected workloads using a two-operation approach comprising a time series analysis and usage of a, e.g., Gradient Boosted Tree machine learning algorithm operating on the output of the time series analysis. The concept is to prepare, clean, and filter the data on each node, e.g., z/OS system in the sysplex, and then aggregate the data for all systems in the sysplex on one system. This contrasts with current approaches, which usually offload the data to a data lake (or similar storage method/device) for further analysis. The data in question can be sensitive and confidential; thus, moving data out of the secure z/OS sysplex should be avoided. The data extraction from SMF records, as well as the preparation, cleaning, filtering, and aggregation of the extracted data can be done with Apache Spark running on at least one z/OS system in the sysplex (as the data in a sysplex is usually shared). Additional Apache Spark instances can be run for data preparation in case the SMF records are not shared in the sysplex.

Aspects of the present disclosure identify seasonal and/or trend-based patterns in the workload, which can be predicted using time series analysis. Using time series analysis, aspects of the present disclosure can predict the number of completed transactions in an equidistant reporting interval. For online workloads, the number of completed transactions is an important metric closely linked to the external demand that reaches each system in a sysplex. Other factors, such as system performance limits, are specifically excluded and can be considered in a following operation. The predicted number of completed transactions can then be one input feature for the, e.g., Gradient Boosted Tree algorithm, which can further incorporate other features like calendaring aspects, constraints, or system information (e.g. number of processors in the system). Calendaring can be important due to the workload requests for transactional workloads being dependent on features like the day of the week or the fact that a given day is a holiday. A constraint could, e.g., be the available system and/or cluster capacity. The result of the Gradient Boosted Tree can be a per-workload prediction of future workload demand for a given timeframe using a CPU utilization metric. Benefits of the present disclosure can range from enablement of automatic system anomaly detection to automatic capacity planning. Both scenarios can also benefit from additional robustness due to the prediction being traceable given the input data, while in traditional approaches both system, anomaly detection, and capacity planning are in practice often done manually by experts. Notably, all the aforementioned advantages are realized while avoiding offloading data outside of the secure Z environment. The solution presented is highly flexible and the machine learning algorithm as well as the specific algorithm used for the time series analysis could be exchanged.

In the following section, additional embodiments of the present disclosure are described.

According to some embodiments, the computing cluster can be a z/Architecture based computing system. Due to its comparably high complexity related to its high centralized performance and usage in large enterprises, performance predictions can be instrumental in managing cost and performance requirements for such systems. However, the present disclosure is not limited to z/Architecture computing system clusters. It can be applicable to a large variety of different computing systems.

According to some embodiments, the additional data can also comprise additional system information. Such system information can be data about an availability of resources at a given point in time, e.g., due to planned maintenance and/or a disconnect, e.g., of a node due to licensing conditions. Thus, also known information about the future of the cluster computing system and its individual node and its related resources can be taken into account for building the workload prediction model.

According to some embodiments, the computing cluster can comprise a plurality of computing nodes. As an advantageous feature of clustered computer systems, the nodes and other components can be activatable or set in a deactivated mode on demand so that performance changes can be addressed elegantly.

According to some embodiments, one node of the computing cluster can perform the time series analysis and perform the training for all other nodes of the computing cluster. Thus, one of the nodes can act as a master whereas the other nodes of the cluster can be configured to operate in a slave mode for the purpose of workload demand predictions. This can save compute resources and limit the workload requirements for the workload demand computing to a minimum.

According to some embodiments, a workload request can be characterized by classes of workload. These different types of workloads—e.g., interactive dialog or online transactions or batch jobs—can easily be differentiated. Different classes can have different types of CPU utilization and/or transaction requirements. This way the workload's real demand with respect to the computing resources can be better categorized.

According to some embodiments, the workload request can be proportional to a number of transactions. In some embodiments, the workload demand can be proportional to CPU utilization. Thus, different measurement criteria can be used to characterize a workload and/or a future demand. In some embodiments, the input and output of the time series analysis can be done in units of “transactions per time”. This can also be the unit for the input of the regression model. The output of the regression model can be done in utilization per time. However, the units may not necessarily be different. They can either be transactions per time or utilization per time for all input/output purposes. This can also improve usability (e.g., more comprehensible/intuitive) for an operator.

According to some embodiments, the statistical regression technique can be based on the R statistical language. I.e., one node of the computing cluster can execute a method of the statistical regression technique and the other nodes can use the results. If, e.g., an implementation—i.e., an interpreter—of the R statistical language can be available under one specific operating system, this can be used to access the R statistical language functions on one of the nodes of the computing cluster while other nodes can run another operating system not compatible with the R statistical language implementation.

Furthermore, the time series analysis can be based on statistical tools available in R. Having both core parts of the method—i.e., the time series analysis and the building the workload model also reflecting the expected acyclic events—can also have efficiency advantages.

According to some embodiments, the statistical regression technique is used within the computing cluster. I.e., no down-loading or uploading to or from another computer system and/or a data-lake can be required. All historic performance data can be handled within the same computing cluster. This can reduce data transmission—i.e., due to down times of network or external computing resources—and it can also save system resources making the complete method more reliable in a RAS sense (reliability, availability, service-ability).

In the following, a detailed description of the figures can be given. All instructions in the figures are schematic. Firstly, a block diagram of an example method for performance predictions in a computing cluster is given. Afterwards, further embodiments, as well as embodiments of the system for performance predictions in a computing cluster, are described.

FIG. 1shows a block diagram of a method100for generating and applying performance predictions in a computing cluster. The method100comprises sampling and storing,102, historic workload request data of the computing cluster as time-stamped workload values, typically performed by the SMF.

Additionally, the method100comprises forecasting,104, an expected total number—e.g., the sum—of workload requests for a defined time interval (which can theoretically be unlimited) in the future based on a time-series analysis of the time-stamped workload values. The time-series analysis detects cyclic and repeating events in the time-stamped workload values.

Moreover, the method100comprises, in response to a result of the time-series analysis performing,106a training of a workload prediction model by using additional data about acyclic events (e.g., based on known calendar related events in expected workload requests) as well as additional system information. The training applies a statistical regression technique for predicting a future workload demand for the computing cluster. The statistical regression technique applied can be, e.g., the Gradient Boosted Tree algorithm built into the Apache Spark MLLib.

Finally, the method100comprises, upon exceeding a predefined threshold value of the predicted future workload demand, reassigning,108, resources of the computing cluster.

FIG. 2shows a block diagram of a typical architecture200of a computing cluster232in a Z system, while an example method300to handle workload requests is detailed inFIG. 3. An external system206outside the cluster232can send requests202to the cluster232(e.g., in a banking environment by using the ATM (automated teller machine) for money withdrawal) which generates workloads to the server environment204,208, . . . implemented as the cluster232. If a request arrives at the data center, it is routed to one of the server nodes204,208, . . . within the cluster232, typically via network210. The server nodes204,208are usually virtualized using a virtualization layer212,214atop the hardware216,218and can host multiple operating systems220,222. On arrival of the request to one of the nodes204,208it can be classified by its type, it can be prioritized, and then it can be processed by an application of one of the operating systems environments220,222. During and after the processing of the request, the workload and system performance data can be stored in long term storage, e.g., a hard disk224,226, e.g., for post-processing, e.g., for charging and pricing purposes. The data is usually shared between all systems in the sysplex, but there can be separate data stores as well. Furthermore, this data can be evaluated by a system administrator for capacity planning and after-the-fact analysis. The virtualization layers can also be connected via a network228,230.

With reference to the method300ofFIG. 3, the workload request generates a workload,302. The workload arriving in the data center can be routed,304, to the system in the cluster. The workload arriving in the system can be classified, prioritized, and then executed,306. The workload and system performance can be stored on persistent long-term storage,308. This can be handled by the SMF.

FIG. 4shows a block diagram of an example computing node400of a computing cluster (e.g.,FIG. 2).

The proposed architecture, shown inFIG. 4, introduces at least two new components: the data collection and analysis component (DCAC)402and the workload forecasting component (WFC)404, to automate the data processing and performance prediction enabling the proactive management of the system environment.

The DCAC402is introduced for every system in the cluster that is running the workload to be analyzed. Only one DCAC402, however, runs as a master and orchestrates the process. The other DCACs402run as slaves. Furthermore, only one WFC404—potentially implemented in R—is needed per cluster. The WFC404can be included into the master DCAC402. The benefits of having it possibly separated are (i) possibly synchronous as well as asynchronous workload forecasting, (ii) possibly using a dedicated analytics machine, and (iii) possibly integrating existing algorithms as an extension point.

The WFC404can be executed in a Linux operating system environment220a, whereas the other components can run under, e.g., z/OS, namely, the data aggregation unit406for an aggregation of relevant data (receiving,416, in case of the master system; sending,418, in case of a slave system) from systems (e.g., over workload classes), the data collection and aggregation unit408for collecting and aggregating cluster data (if the analysis component is the master), the forecasting unit409, the performance modeling and prediction unit410and the sending unit412for sending the results to act proactively to other servers414and/or for possibly (re-)adjusting and/or (re-)configuring nodes in the cluster.

It can be noted that each DCAC402and the cluster reads the workload data from disk continuously. They then aggregate the data (FIG. 4/406;FIG. 5/504), e.g., over workload classes, and either send the aggregated data to the master DCAC402or collect the data from the other systems in the cluster—were there can possibly zero or more other systems—if it is the master DCAC. The master DCAC402collects the data from the slaves and aggregates them to obtain a holistic view of the environment (FIG. 4/408;FIG. 5/512).

The process500for working with the data is shown inFIG. 5. Each DCAC in the cluster reads,502, the workload data from disk (e.g.,FIGS. 2, 4;224) continuously. They then aggregate,504, the data by the data aggregation unit406, e.g., over workload classes, and either send,508, the aggregated data to the master (e.g.,506) if it is a slave DCAC402or collects/receives,510, (e.g.,416inFIG. 4) the data from the other systems in the cluster—where there can be possible zero or more of other systems—if it is the master DCAC402. The master DCAC402collects,512, the data from the slaves and aggregates them to obtain a holistic view of the environment (by the data collection and aggregation unit408). The workload forecasting is required in intervals, e.g., every day (other forecasting periods are possible), depending on the horizon of the forecast.

If the observation period is expired—case “yes” of the determination514whether the forecast period is expired—a new forecast with fresh data is needed (operation516: WFC: process current data and obtain workload forecast), the information is forwarded to the WFC404to process and forecast (516by the forecasting unit409). The current forecast in combination with important system and calendar data, such as system configuration and regional/public holiday information, is used in the DCAC404and the respective prediction unit410to obtain a performance model (operation518). Solving the performance model (e.g., the gradient boosted trees) allows predicting the system and workload performance in the future. This information is then used,520, to proactively manage the environment (compare also sending unit412), e.g., by adding processing resources if important workloads are expected to underperform or by removing processing resources to save money.

For example, if a utilization that requires 10 CPUs to be processed is expected for the next peak period on a node in the cluster, but only 9 CPUs are currently granted to that node, a scheduled policy can be generated in form of an XML file. That XML file is used by, e.g., a Capacity Provisioning Manager (CPM) or similar automated capacity provisioning products to add the required CPU on demand during the expected peak period. As an alternative, if adding resources is too expensive, the specific workload on the cluster can be given a higher priority in form of an importance factor in the respective Workload Manager (WLM) policy or similar server workload manager products of that node. While this can help important workloads to meet their performance goals, the consequence is that the relative priority of other workloads can be decreased.

FIG. 6shows a block diagram600of different stages and a related dataflow. Aspects of the present disclosure comprise three stages as shown inFIG. 6: data preparation602, time series analysis604, and model training/model prediction606. Data preparation and model training/prediction606can be implemented in Scala using the Apache Spark Scala API. The time series analysis can be implemented in R. The data preparation stage can comprise reading workload data (e.g.,502), data aggregation (e.g.,504), possible data transfer (e.g.,508/510), and data collection and aggregation (e.g.,512), as shown inFIG. 5. The time series analysis is part of the Workload Forecasting component (e.g.,409) and as shown inFIG. 5(e.g.,516). The performance modeling and prediction (e.g.,518) and usage of the results (e.g.,520) belong to the model training/model prediction stage.

Thus, the DCAC402receives a measured transactions per time value608and outputs a cleared/aggregated transaction per time value610. The WFC performing the time series analysis604outputs a first forecast612as a transaction per time value which is received by the DCAC402. As additional inputs, the DCAC402receives system information616(e.g., the number of available processors in a given time period) and calendric information618(e.g., public holidays) in order to generate one or more predicted utilization/time values614.

An exemplary implementation consists of these three stages, which can be asynchronously called. This means after the data aggregation (e.g.,406,504) on an SMF dataset has finished it is determined whether the system is running as a DCAC slave or a DCAC master (e.g.,506). DCAC slaves can send their aggregated data to the DCAC master, which can then collect and further aggregate the data (e.g.,512). The DCAC master can then send the prepared data from the z/OS sysplex220to the WFC404/forecasting unit409which can run the time series analysis. The output of the time series analysis is then asynchronously transferred back to the DCAC master402, which uses it as input for, e.g., the Gradient Boosted Tree algorithm for modeling and prediction (e.g.,410,412;518).

Another possibility for an implementation is a synchronous transfer of results between the different components (WFC404, DCAC402). This can either be achieved (i) with the here presented algorithms Apache Spark on z/OS supporting R as a language, (ii) if a time series analysis algorithm implemented in either Java, Scala or Python is used, which would eliminate the need to transfer data to the WFC404, or (iii) if the data between WFC404and DCAC402is exchanged via “printing to”—in the sense of sending—and reading from system out (console)—in the sense of receiving.

Aspects of the present disclosure satisfy the use case of capacity planning, since the prediction can only be run on demand and no constant update of the predictions needs to be made.

The next section can describe the data preparation by the DCAC402in more detail. The data preparation stage of the DCAC is, e.g., written in Scala and uses the Apache Spark Scala API and the MDSS (mainframe data service for Apache Spark) offered by, e.g., Rocket Software. Using the MDSS, one can directly ingest SMF datasets residing on z/OS, as well as ingest SMF log-stream data currently being written on the z/OS system that the forecasting application is running on. The SMF dataset can be ingested and read into a Spark Dataframe, which can be used for data preparation. This includes dropping irrelevant columns as well as feature extraction. Feature extraction creates new columns that are easier to ingest in a machine learning algorithm and can yield additional insight. I.e., the existing timestamp, provided in the SMF record, is converted to separate “date”, “time”, “weekday” columns that can be of importance for model training, because “time” and “weekday” are highly relevant features for workloads with a seasonal pattern. Other features like “end_of_month”, “end_of_quarter” or “end_of_year” could also be extracted into a column as well if they are of value given the specific use case. The column selection and feature extraction of “date” and “time” is shown in the example code snippet below:

Another operation of the data preparation is to clean the data. The time series analysis in the WFC implicitly operates on equidistant values. That means aspects of the present disclosure ensure that data contains the correct amount of values and that these values were taken at the appropriate time. Missing a value can be corrected by adding a dummy record for it. Having a value too large can be corrected by combining it with another value to gain meaningful insight from the time series analysis.

The next section can describe the data preparation by the WFC404in more detail. The time series analysis and workload forecast is based on the STL (Seasonal and Trend decomposition using Loess//locally weighted regression) algorithm and implemented in R as shown in the code snippet below. First, the relevant data can be combined and transformed into a time series, an equidistant set of data points. Additionally, the length of the frequency, i.e., the length of the periods of the cyclical pattern, is given as input. In the next operation, the data is decomposed using the STL algorithm into its trend, seasonal (i.e. cyclical) and remainder parts. Finally, the decomposition is used to obtain a forecast for the future, for example for the next period. The example code snippet below can illustrate the aforementioned:

The next section describes the data preparation of the DCAC in more detail. The DCAC can use a Gradient Boosted Tree algorithm, which is part of the Apache Spark machine learning library as a model for the performance prediction. Input for our proposed example implementation are the time, the day of the week and the number of completed transactions in the reporting interval (“time”, “weekday”, “Trx.Comp”). With this input, aspects of the present disclosure can predict the CPU utilization of the given workload, which in this case is “TrxCPUPc” (Transaction CPU utilization) but can be different given another workload (not every workload reports its utilization in TrxCPUPc). For model training, aspects of the present disclosure can first transform the weekday into a numeric value “weekdayx” and then combine the numeric columns “time”, “weekdayx” and “Trx.Comp” into a single vector, which can be scaled to have unit standard deviation for better model training. Some embodiments use the “Trx.Comp” predicted by the time series analysis for training and not the original captured values to be able to correct for effects the time series analysis is unable to model, i.e. the occurrence of a holiday. Given that a model has been trained and built, one can now predict values for a given input. The example code snippet below shows feature transformation, scaling, model training, and prediction of test data for model validation:

FIG. 7shows a simplified block diagram of the system700for performance predictions in a computing cluster. The system700comprises a sampling unit702adapted for sampling and storing historic workload request data of the computing cluster as time-stamped workload values, a forecasting module704adapted for an expected total number of workload requests for a defined time interval in the future based on a time-series analysis of the time-stamped workload values, where the time-series analysis detects cyclic and repeating events in the time-stamped workload values, and a training unit706adapted for, in response to a result of the time-series analysis, performing a training of a workload prediction model by using additional data about acyclic events in expected workload requests, where the training applies a statistical regression technique for predicting a future workload demand for the computing cluster. Moreover, the system700comprises a reassignment module708adapted for reassigning resources of the computing cluster if a predefined threshold value of the predicted future workload demand is exceeded.

Embodiments of the present disclosure can be implemented together with virtually any type of computer, regardless of the platform being suitable for storing and/or executing program code.FIG. 8shows, as an example, a computing system800suitable as a basis for the computing cluster and for executing program code related to the proposed method.

As shown in the figure, computer system/server800is shown in the form of a general-purpose computing device. The components of computer system/server800can include, but are not limited to, one or more processors or processing units802, a system memory804, and a bus806that couple various system components including system memory804to the processor802. Bus806represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limiting, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (PCI) bus. Computer system/server800typically includes a variety of computer system readable media. Such media can be any available media that is accessible by computer system/server800, and it includes both volatile and non-volatile media, removable and non-removable media.

The system memory804can include computer system readable media in the form of volatile memory, such as random access memory (RAM)808and/or cache memory810. Computer system/server800can further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, a storage system812can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected to bus806by one or more data media interfaces. As can be further depicted and described below, memory804can include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the present disclosure.

The program/utility, having a set (at least one) of program modules816, can be stored in memory804by way of example, and not limiting, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating systems, one or more application programs, other program modules, and program data or some combination thereof, can include an implementation of a networking environment. Program modules816generally carry out the functions and/or methodologies of embodiments of the present disclosure, as described herein.

The computer system/server800can also communicate with one or more external devices818such as a keyboard, a pointing device, a display820, etc.; one or more devices that enable a user to interact with computer system/server800; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server800to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces814. Still yet, computer system/server800can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter822. As depicted, network adapter822can communicate with the other components of computer system/server800via bus806. It should be understood that, although not shown, other hardware and/or software components could be used in conjunction with computer system/server800. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

Additionally, the system700for performance predictions in a computing cluster be attached to the bus system806.

The flowcharts and/or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present present disclosure. In this regard, each block in the flowchart or block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block can occur out of the order noted in the figures. For example, two blocks shown in succession can, in fact, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It can 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 that perform the specified functions or act or carry out combinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the present disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It can further be understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, operations, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, operations, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or operations plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements, as specifically claimed. The description of the present disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the present disclosure in the form disclosed. Many modifications and variations can be apparent to those of ordinary skills in the art without departing from the scope and spirit of the present disclosure. The embodiments are chosen and described in order to best explain the principles of the present disclosure and the practical application, and to enable others of ordinary skills in the art to understand the present disclosure for various embodiments with various modifications, as are suited to the particular use contemplated.