JP2015530647A - System and method for tuning a cloud computing system - Google Patents

Abstract

The present disclosure relates to methods and systems for configuring a computing system, such as a cloud computing system. The method includes initiating multiple executions of a workload on a multiple node cluster of a computing system based on multiple different sets of configuration parameters of the multiple node cluster. The configuration parameters include at least one of workload container operational parameters, at least one node boot time parameter, and at least one node hardware configuration parameter. The method further includes, based on a comparison of at least one performance characteristic of the multi-node cluster monitored at each execution of the workload, and at least one desired performance characteristic of the multi-node cluster, of the multi-node cluster. Selecting a set of configuration parameters for a plurality of different sets of configuration parameters. The method further includes providing a workload to the multi-node cluster for execution by the multi-node cluster configured with the selected set of configuration parameters. [Selection] Figure 1

Description

  The present disclosure relates generally to the field of computing systems, and more particularly to methods and systems for configuring and / or monitoring performance characteristics of cloud computing systems.

  Cloud computing is involved in delivery of a host service via a network such as the Internet, for example. Cloud computing systems provide the delivery of computing capacity and storage capacity as a service to end users. A cloud computing system includes a plurality of servers or “nodes” operating on a distributed communication network, each node including local processing power and memory. For example, each node of a cloud computing system includes at least one processing device for providing computing capabilities and memory for providing storage capacity. Rather than running the application locally or storing the data locally, the user can run the application remotely or store the data remotely on the cloud, i.e. on a "cluster" of multiple nodes Can do. An end user can access a cloud-based application, for example via a web browser or some other software application on the local computer, while the software application and / or data associated with the software application is at a remote location. Stored and / or executed on a cloud node. Cloud computing resources are typically allocated to end users on demand, which is accompanied by cloud computing system costs that correspond to the actual amount of resources utilized by the end users.

  Computing tasks are distributed across multiple nodes of a cloud computing system in the form of a workload. Nodes operate to share workload processing. A workload (also referred to as a “kernel”) includes computing jobs or tasks that are performed and executed on a multi-node cloud. A workload comprises a collection of software or firmware code and any necessary data, including any application or program or part of an application or program that runs on a cluster of nodes. For example, one exemplary workload is an application that implements one or more algorithms. Exemplary algorithms include, for example, clustering, sorting, classifying, or filtering data sets. Other exemplary workloads include service-oriented applications that are executed to provide computing services to end users. In some forms, the workload includes a single application that is replicated and executed simultaneously on multiple nodes. A load balancer distributes requests to be executed with a workload across a cluster of nodes so that multiple nodes share the processing load associated with the workload. The multi-node cluster collaborates on the results of the workload execution to produce a final result.

  The workload container comprises one or more processors of nodes executing workload container modules (eg, software code or firmware code) and runs on each node. A workload container is an execution framework for workloads that provides a software environment that initiates and directs execution of workloads on a multi-node cluster. Workload containers typically provide an execution framework for a particular class of workloads on a multi-node cluster. A workload container is a related node as a node in the cloud, where the node executes the workload, shares the results of the workload execution with other nodes in the cloud, and cooperates with other nodes in the cloud and Configure related nodes to operate in communication. In one form, the workload container includes application program interfaces (APIs) or XML-based interfaces for interfacing with other nodes as well as other applications and hardware of the associated node.

  One exemplary workload container is a Java-based Apache Hadoop that provides a map reduce framework and a distributed file system (HDFS) for map-reduce workloads. ). A multi-node cluster operating with a hadoop workload container typically includes a master node and a plurality of worker nodes. The Hadoop workload container coordinates the assignment of the master state or worker state to each node and notifies each node that it is operating on the cloud. The master node tracks the start and completion of jobs (ie workloads) and file system metadata. In the “map” phase of the map reduce framework, one task, or workload, is partitioned into multiple parts (ie, multiple groups of one or more processing threads) The multiple parts are distributed to multiple worker nodes that process the processing threads and associated input data. In the “reduce” phase, the outputs from each worker node are collected and combined to produce the final result or answer. The Hadoop Distributed File System (HDFS) is used to store data and communicate data between multiple worker nodes. The HDFS file system supports data replication and increases the likelihood of data reliability by storing multiple copies of data and files.

  Setting up or configuring a multi-node cluster in a conventional cloud computing platform is a complex process that requires a steep learning curve. Cloud software and workloads need to be deployed to each node individually, and any configuration changes need to be deployed to each node individually. Analyzing the performance of a multi-node cluster and optimizing a cloud setup involves multiple independent variables, often time consuming, and is suitable for monitoring and analyzing a specific application. Requires an ad-hoc interface. In particular, the cloud operator or engineer needs to create commands in order to obtain data about how the workload is running and to obtain the actual results of the workload. In addition, such data is in a format specific to the current system configuration, and the data needs to be unified by a cloud operator or engineer into a form suitable for performance analysis. Cloud operators or engineers are required to learn about cloud mechanisms, any networking issues, system management related tasks, and specific details of available performance analysis tool deployments and data formats. Furthermore, monitoring and analyzing workload performance on a multi-node cluster is complex, time consuming, and depends on the specific cloud configuration. A cloud operator or engineer is not familiar with all the details of the configuration and hardware information for a particular cloud system, which makes accurate performance analysis difficult.

  Today, several cloud computing platforms are available, including, for example, Amazon Web Services (AWS) and OpenStack. Amazon's AWS includes an Elastic Compute Cloud (EC2) and lends a cluster of multiple nodes (servers) to end users for use as a cloud computing system. AWS allows a user to allocate a cluster of nodes and run a workload on that cluster of nodes. AWS restricts users to run workloads only on Amazon-provided server hardware with various constraints, such as requiring specific hardware and software configurations. The open stack allows a user to build and manage a multi-node cluster on user-provided hardware. AWS and open stack lack mechanisms to quickly configure workload and workload container software to deploy to each node, modify network parameters, and aggregate performance data from all nodes in the cluster. ing.

  A known method of testing the performance of a particular local processor involves creating synthetic binary code based on user-specified parameters that can be executed by that local processor. However, the creation of the binary composite code requires that the user hard-codes the parameters specified by the user, requires considerable development time, and requires prior knowledge about the architecture of the target processor. Such hard-coded composite code must be written for a specific instruction set architecture (ISA) (eg, x86) or a specific microarchitecture of the target processor. The instruction set architecture is a component of the computer architecture that identifies the type / format of data, instructions, data block size, processing registers, memory addressing mode, memory architecture, interrupt and exception handling, I / O, etc. Microarchitecture identifies data paths, data processing elements (eg, logic gates, arithmetic logic units (ALUs), etc.), data storage elements (eg, registers, caches, etc.), and how the processor sets the instruction set architecture. A component of a computer architecture that identifies whether to implement Thus, the composite code needs to be redesigned with modified or new hard-coded parameters and instructions to implement various instruction set architectures or different microarchitectures of one or more other processors. . For this reason, such hard-coded composite code is not suitable for testing multiple nodes of a cloud computing system.

  Another way to test local processor performance is to run processor-standard workloads or traces such as those provided by the Standard Performance Evaluation Corporation (SPEC) to improve processor performance. It is to be compared with the benchmark. However, a large amount of simulation time is often required to fully run an industry standard workload. Extracting related smaller traces from the workload for execution by the processor may reduce simulation time, but requires extra technical effort to identify and extract related traces. Is done. Furthermore, the selection of industry standard workloads or the extraction of smaller traces from the workloads must be repeated for different architectural configurations of one or more processors.

  Current cloud systems that deliver computing capacity and storage capacity as a service to end users lack a mechanism to change the boot time configuration of each node in a cluster of multiple nodes of the cloud system. For example, boot time configuration changes need to be hard coded onto each node in the cloud by an engineer or programmer to modify the boot time parameters of multiple nodes, which can be time consuming and cumbersome. is there. In addition, engineers need to have detailed knowledge of the hardware and computer architecture of a multi-node cluster in writing configuration code.

  A typical cloud system that delivers computing capacity and storage capacity as a service to an end user has a mechanism that allows the user to identify and modify the network configuration of an allocated cluster of nodes Is missing. In many cloud systems, the user can only request a generic type of node, and directly control the network topology, that is, the physical and logical network connectivity of the node and the network performance characteristics of the requested node. Control is impossible and very little, if possible. For example, Amazon AWS allows users to select nodes that are physically located in the same region of the country or the world (eg, US East or West, Europe, etc.), but the network of those nodes Connectivity and network performance characteristics of those nodes cannot be selected or modified. In addition, some of the selected nodes may be physically remote from other selected nodes even though they are in the same region of the country or even in the same data center. For example, nodes allocated by a cloud system may be on separate racks that are physically far apart in a distributed data center, resulting in poor or inconsistent network performance between nodes. End up.

  Similarly, in a typical cloud system, end user control over the actual hardware resources of the node cluster is limited or impossible. For example, when allocating a node, the user can only request a generic type node. Each available node type may be categorized by the number of CPUs in the node, available memory, available disk space, and the country or world region where the node is located. However, the allocated node may not have the exact hardware characteristics as the selected node type. The node types that can be selected are rough classifications. For example, node types may include small, medium, large and very large depending on the amount of system memory and disk space and the number of processing cores in the node. However, even for nodes selected as the same general purpose type, the computing capacity and storage capacity of the nodes allocated by the system may change. For example, available memory and disk space as well as operating frequency and other characteristics may vary, i.e., fall within a certain range of those values. For example, a “medium” node may include any node having 1500 MB to 5000 MB of system memory and 200 GB to 400 GB of storage capacity. Thus, the user is not necessarily familiar with the actual hardware configuration of the allocated node. Further, even between nodes having the same number of processors and the same memory / disk space, other hardware characteristics of these nodes may change. For example, even for similar nodes, variations occur based on node operating frequency, cache size, 32-bit or 64-bit architecture, node manufacturer, instruction set architecture, etc. There is no control over these properties of the selected node.

  In many cases, the user does not have a clear understanding of the specific hardware resources required for the user's application or workload. As a result of the difficulty of setting up node clusters and running workloads, users have limited opportunities to try different hardware configurations. This, coupled with the lack of user knowledge about the actual hardware resources of the allocated nodes, often results in unnecessary costs for the hardware resources under use. Various monitoring tools are available that can measure the network utilization of the CPU, memory and disk and a single physical processing machine. However, current cloud systems do not provide a mechanism that allows users to deploy these monitoring tools to multiple nodes of a cluster to monitor hardware usage. Therefore, the user cannot know the actual hardware usage when executing the workload. The most common cloud services provide an accounting mechanism that can provide basic information about the cost of hardware resources requested and used by users while running a workload. However, such a mechanism only provides basic information about the cost of the requested hardware resource and thus does not identify the actual hardware resource used in the workload execution.

  In many cloud systems, only a limited number of configuration parameters are available for the user to adjust and improve the configuration of the node cluster. For example, the user may only be able to select several nodes of different generic node types to change the cloud configuration. Furthermore, each configuration change must be implemented manually by the user selecting several nodes for the node cluster and starting the workload on these nodes. Such manual effort to apply configuration changes and test results is expensive and time consuming. In addition, the various performance monitoring tools available for testing node performance are typically suitable for a single physical processing machine, and in current cloud systems, users can cluster these monitoring tools. It lacks a mechanism that allows it to be deployed across multiple nodes to test the performance of a node cluster with different configurations.

  Thus, there is a need for a method and system for automating the creation, deployment, provision, execution and data aggregation of workloads on any size node cluster. There is also a need for a method and system for quickly configuring workloads and workload container software to deploy to each node and aggregating and analyzing workload performance data from all nodes of the cluster. There is also a need for methods and systems that test the performance of multiple nodes of a cloud computing system and provide automated configuration tuning of the cloud computing system based on the monitored performance. There is also a need for a method and system for creating a retargetable synthetic test workload for execution on a cloud computing system for testing node processors having various computer architectures. There is also a need for a method and system that provides for modification of the boot time configuration of multiple nodes in a cloud computing system. There is also a need for a method and system that facilitates modifying the network configuration of a cluster of multiple nodes in a cloud system. There is also a need for a method and system that enables automated selection of suitable nodes for a multi-node cluster based on the desired network topology, desired network performance, and / or desired hardware performance of the cloud system. ing. It also measures node cluster hardware resource usage during workload execution and provides hardware usage feedback to the user and / or automatically automates node cluster configuration based on monitored hardware resource usage. There is a need for a method and system that automatically corrects.

  In an exemplary embodiment of the present disclosure, a method for configuring a computing system implemented by one or more computing devices is provided. The method includes initiating multiple executions of a workload on a multiple node cluster of a computing system based on multiple different sets of configuration parameters for the multiple node cluster. In one embodiment, the configuration parameters include at least one of workload container operational parameters, boot time parameters of at least one node, and hardware configuration parameters of at least one node. The workload container operates so as to link workload sharing processing on a cluster of a plurality of nodes. The method further includes comparing, by one or more computing devices, at least one performance characteristic of the multi-node cluster monitored at each execution of the workload and at least one desired performance characteristic of the multi-node cluster. Based on selecting a set of configuration parameters for a cluster of nodes from a plurality of different sets of configuration parameters. The method further includes providing a workload to the multi-node cluster for shared execution by the multi-node cluster configured with the selected set of configuration parameters.

  Among other benefits, some embodiments may allow selection, configuration and deployment of multi-node clusters, workloads, workload containers and network configurations via a user interface. In addition, some embodiments may allow for control and adjustment of cloud configuration parameters, thereby allowing for under changing characteristics of node hardware, networks, workload containers, and / or workloads. Performance analysis becomes possible, and automated system tuning based on performance analysis becomes possible. Other benefits should be recognized by those skilled in the art.

  In another exemplary embodiment of the present disclosure, a computing configuration system is provided that includes a batch processor, a node configurator, and a workload configurator. The batch processor operates to initiate multiple executions of the workload on the multiple node cluster of the computing system based on the multiple different sets of configuration parameters of the multiple node cluster. In one embodiment, the configuration parameters include at least one of workload container operational parameters, boot time parameters of at least one node, and hardware configuration parameters of at least one node. The workload container operates so as to link workload sharing processing on a cluster of a plurality of nodes. The node configurator is based on a comparison by the node configurator of at least one performance characteristic of the multi-node cluster monitored with each execution of the workload and at least one desired performance characteristic of the multi-node cluster. Operate to select a set of configuration parameters for a plurality of different sets of configuration parameters. The workload configurator operates to provide a workload to a multi-node cluster for shared execution by a multi-node cluster configured with a selected set of configuration parameters.

  In yet another exemplary embodiment of the present disclosure, a non-transitory computer readable medium including executable instructions is provided. Executable instructions, when executed by at least one processor, initiate multiple executions of the workload on the multiple node cluster of the computing system based on different sets of configuration parameters of the multiple node cluster Causing at least one processor to execute. In one embodiment, the configuration parameters include at least one of workload container operational parameters, boot time parameters of at least one node, and hardware configuration parameters of at least one node. The workload container operates so as to link workload sharing processing on a cluster of a plurality of nodes. Execution of executable instructions further causes at least one processor to select a set of configuration parameters for a cluster of nodes from a plurality of different sets of configuration parameters. The selection of a set of configuration parameters may include a comparison by at least one processor of at least one performance characteristic of the multi-node cluster monitored at each execution of the workload and at least one desired performance characteristic of the multi-node cluster. Based. Execution of executable instructions further provides at least one processor to provide a workload to a cluster of nodes for shared execution by a cluster of nodes configured with a selected set of configuration parameters. To run.

  The present invention will be more readily understood in view of the following description in conjunction with the following drawings. In the drawings, like reference numbers indicate like elements.

FIG. 1 is a block diagram of a cloud computing system according to an embodiment including a cluster of multiple nodes operating on a communication network, a control server communicating with the cluster of multiple nodes, and a configurator of the control server.

FIG. 2 is a block diagram of an exemplary node of the multi-node cluster of FIG. 1 that includes at least one processor and memory.

3 is a block diagram of an exemplary control server of the cloud computing system of FIG. 1 including a configurator that operates to configure the cloud computing system of FIG.

FIG. 4 is a flowchart of an exemplary method of operation of the configurator of FIG. 3 for configuring a cloud computing system.

FIG. 5 is a flowchart of another exemplary method of operation of the configurator of FIG. 3 for configuring a cloud computing system.

FIG. 6 is a flowchart of another exemplary method of operation of the configurator of FIG. 3 for configuring a cloud computing system.

FIG. 7 is a diagram illustrating an exemplary user interface provided by the configurator of FIG. 3 that includes an authentication and configuration library module to facilitate user access authentication.

FIG. 8 is a diagram illustrating the instance module of the example user interface of FIG. 7 including an instance tab for facilitating the selection of the multi-node cluster of FIG.

FIG. 9 is a diagram illustrating an instance type tab of the instance module of FIG. 8 for facilitating selection of node types for nodes of the multi-node cluster of FIG.

FIG. 10 is a diagram illustrating another instance configuration tab of the instance module of FIG. 8 for facilitating configuration of boot time parameters for one or more nodes of the multi-node cluster of FIG.

FIG. 11 is a diagram illustrating a network configuration wizard of the network configuration module of the example user interface of FIG. 7 including a delay tab to facilitate implementation of network delays on the communication network of FIG.

12 is a diagram illustrating a packet loss tab of the network configuration module of FIG. 11 for facilitating adjustment of the packet loss rate on the communication network of FIG.

FIG. 13 is a diagram illustrating a packet duplication tab of the network configuration module of FIG. 11 for facilitating adjustment of the packet duplication rate on the communication network of FIG.

14 is a diagram illustrating a packet corruption tab of the network configuration module of FIG. 11 for facilitating adjustment of the packet corruption rate on the communication network of FIG.

FIG. 15 is a diagram illustrating a packet reordering tab of the network configuration module of FIG. 11 for facilitating adjustment of the packet reordering rate on the communication network of FIG.

FIG. 16 is a diagram illustrating a speed control tab of the network configuration module of FIG. 11 for facilitating the adjustment of the communication speed on the communication network of FIG.

17 is a diagram illustrating a custom command tab of the network configuration module of FIG. 11 for facilitating adjustment of network parameters on the communication network of FIG. 1 based on a custom command string.

FIG. 18 is a diagram illustrating the example user interface workload container configuration module of FIG.

FIG. 19 is a diagram illustrating the hadop tab of the workload container configuration module of FIG.

FIG. 20 is a diagram illustrating a hadop tab of the workload container configuration module of FIG. 18 including a custom tab for facilitating configuration of operating parameters of a hadoop workload container based on a custom command string.

FIG. 21 is a diagram illustrating a custom tab of the workload container configuration module of FIG. 18 for facilitating selection of a custom workload container.

22 illustrates the example user interface workload configuration module of FIG. 7 including a workload tab for facilitating selection of a workload for execution on the multi-node cluster of FIG. It is.

FIG. 23 is a diagram illustrating a synthesis kernel tab of the workload configuration module of FIG. 22 for facilitating configuration of a synthetic test workload.

FIG. 24 is a diagram illustrating the MC blaster tab of the workload configuration module of FIG. 22 for facilitating memcached workload configuration.

FIG. 25 is a diagram illustrating the exemplary user interface batch processing module of FIG. 7 for facilitating selection and configuration of a batch sequence for execution on the multiple node cluster of FIG.

FIG. 26 is a diagram illustrating the example user interface monitoring module of FIG. 7 including a hadoop tab for facilitating the configuration of a hadoop data monitoring tool.

FIG. 27 is a diagram illustrating a ganglia tab of the monitoring module of FIG. 26 for facilitating configuration of the ganglia data monitoring tool.

FIG. 28 illustrates a system tap tab of the monitoring module of FIG. 26 for facilitating configuration of the system tap data monitoring tool.

FIG. 29 is a diagram illustrating an I / O time tab of the monitoring module of FIG. 26 for facilitating configuration of virtual memory statistics (VMStat) and input / output statistics (IOStat).

30 controls the example user interface of FIG. 7 to facilitate deployment of the system configuration of the multiple node cluster of FIG. 1 and to facilitate the aggregation of data monitored by the monitoring tools of FIGS. FIG.

FIG. 31 is another block diagram of the cloud computing system of FIG. 1 showing the web-based data aggregator of the configurator of FIG.

FIG. 32 is a diagram illustrating an exemplary table showing a plurality of user-defined workload parameters for generating a synthetic test workload.

FIG. 33 illustrates an exemplary synthesis that includes a synthesizer that operates to generate a synthetic test workload and a synthetic workload engine of nodes that operate to activate and execute at least a portion of the synthetic test workload. 1 is a block diagram of a test workload system.

FIG. 34 is a flowchart of an exemplary method of operation of the configurator of FIG. 3 for configuring a cloud computing system at least one of an actual workload and a synthetic test workload.

FIG. 35 is a flowchart of an exemplary method of operation of the configurator of FIG. 3 for configuring a cloud computing system with a synthetic test workload.

36 is a flowchart of an exemplary method of operation of the configurator of FIG. 3 for selecting a boot time configuration of at least one node of the multi-node cluster of FIG.

FIG. 37 is a flowchart of an exemplary method of operation of a node of the multi-node cluster of FIG. 1 to modify at least one boot time parameter of the node.

38 is a flowchart of an exemplary method of operation of the cloud computing system of FIG. 1 to modify the boot time configuration of one or more nodes of the multiple node cluster of FIG.

39 is a flowchart of an exemplary method of operation of the configurator of FIG. 3 to modify the communication network configuration of at least one node of the multiple node cluster of FIG.

FIG. 40 is a flowchart of an exemplary method of operation of the configurator of FIG. 3 for selecting a multi-node cluster for a cloud computing system based on a network configuration of emulated node clusters.

41 is a flowchart of another exemplary method of operation of the configurator of FIG. 3 to select and configure a multi-node cluster for a cloud computing system based on the network configuration of the emulated node cluster. It is.

FIG. 42 is a diagram illustrating an example data file that identifies multiple communication network characteristics of a node cluster.

43 is a flowchart of an exemplary method of operation of the configurator of FIG. 3 for selecting a multi-node cluster of FIG.

FIG. 44 is a flowchart of another exemplary method of operation of the configurator of FIG. 3 for selecting a cluster of multiple nodes of FIG.

45 is a flowchart of an exemplary method of operation of the configurator of FIG. 3 for selecting a hardware configuration for the cluster of multiple nodes of FIG.

FIG. 46 is a flowchart of another exemplary method of operation of the configurator of FIG. 3 for selecting a hardware configuration for the multi-node cluster of FIG.

47 is a flowchart of an exemplary method of operation of the configurator of FIG. 3 for selecting configuration parameters for the multi-node cluster of FIG. 1 based on the monitored performance characteristics of the multi-node cluster.

48 is a flowchart of another exemplary method of operation of the configurator of FIG. 3 to select configuration parameters for the multi-node cluster of FIG. 1 based on the monitored performance characteristics of the multi-node cluster. is there.

  Although the embodiments disclosed herein are described with respect to a cloud computing system, the disclosed methods and systems may be implemented on any suitable computing system that includes multiple nodes that cooperate to execute a workload. May be.

  As referred to herein, a node of a computing system includes at least one processing device and memory accessible by the at least one processing device. A node may also be referred to as a server, virtual server, virtual machine, instance, or processing node, for example.

  FIG. 1 is a diagram illustrating an exemplary cloud computing system 10 according to various embodiments that is configured to deliver computing power and storage capacity as a service to an end user. The cloud computing system 10 includes a control server 12 operably coupled to a cluster 14 of multiple nodes. A multi-node cluster 14 is connected to a distributed communication network 18 and each node 16 includes local processing capabilities and memory. Specifically, each node 16 includes at least one processor 40 (FIG. 2) and at least one memory 42 (FIG. 2) accessible by the processor 40. The communication network 18 is, for example, an Internet protocol (IP) format including a Transmission Control Protocol / Internet Protocol (TCP / IP) or a User Datagram Protocol (UDP), Ethernet ( Any suitable computer network protocol such as an Ethernet network, a serial network, or other local or wide area network (LAN or WAN).

  As described herein, a node 16 is selected by the control server 12 to designate a cluster 14 of nodes from a cloud of available nodes 16 connected to the communication network 18. The available nodes 16 are provided, for example, on one or more server storage racks in the data center and include various hardware configurations. In one embodiment, an available node 16 from multiple data centers and / or other hardware providers is selected as a control server for selection and configuration as a multi-node cluster 14 for the cloud computing system 10. 12 is accessible. For example, one or more third party data centers (eg, Amazon Web Services, etc.) and / or user-provided hardware may be configured for cloud computing by the control server 12. In one example, thousands of nodes 16 may be available for selection and configuration by the control server 12, but any number of nodes 16 may be available. Although five nodes 16 are shown in FIG. 1, any suitable number of nodes 16 may be selected for the cloud computing system 10. The control server 12 includes one or more computing devices (exemplarily server computers) each including one or more processors. In the illustrated embodiment, the control server 12 is a dedicated control server 12 that is physically separated from the node cluster 14. In one embodiment, the control server 12 may be physically remote from the data center that houses the available nodes 16. Alternatively, the control server 12 may be one or more nodes 16 of a selected cluster 14 consisting of multiple nodes. The control server 12 is a cloud that operates to allocate and configure multiple nodes 16, initiate workloads on the nodes 16, collect and report performance data, etc., as described herein. Functions as a computing configuration system.

  The control server 12 illustratively includes a configurator 22, a load generator 24, and a load balancer 26. The configurator 22, load generator 24, and load balancer 26, as referred to herein, execute the one or more software or firmware codes stored in internal or external memory accessible by one or more processors. The processor is provided. The software / firmware code includes instructions corresponding to the configurator 22, load generator 24, and load balancer 26, which, when executed by the one or more processors, perform the various functions described herein. One or more processors are executed. Configurator 22, load generator 24 and / or load balancer 26 may alternatively be application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), hardware logic elements or the like. Combinations may be included. The configurator 22 selects and configures one or more nodes 16 to be included in the multi-node cluster 14, configures the parameters of the communication network 18, as described herein, on the multi-node cluster 14. Operate for selecting, configuring and deploying workload container modules and workloads for execution on and collecting and analyzing performance data associated with the execution of the workload . The configurator 22 is provided to the node 16 for configuring software on the node 16 and processed at the node 16, and to the load generator 24 for providing workload request parameters to the load generator 24. It operates to generate at least one configuration file 30 that is provided.

  The load generator 24 operates to generate requests that serve as inputs used by the node cluster 14 for workload execution. That is, the node cluster 14 executes the workload based on the request and the input parameters and data provided accompanying the request. In one embodiment, the request from the load generator 24 is initiated by the user. For example, a user or customer may request a search or sort operation for a specified search term or data set, respectively (eg, via user interface 200), and load generator 24 may send a corresponding search or sort request. Generate. In one embodiment, configurator 22 generates a configuration file 30 that describes a user request received via user interface 200. Node 16 executes the workload with the identified terms to be searched or the data set to be sorted. The load generator 24 may generate other suitable requests depending on the type of workload to be executed. The load balancer 26 operates to distribute which requests provided by the load generator 24 among the plurality of nodes 16 and indicate which nodes 16 execute which requests. Further, the load balancer 26 divides the request from the load generator 24 into a plurality of parts and distributes the plurality of parts to the plurality of nodes 16 so that the plurality of nodes 16 operate to execute the request in parallel operation. Also works.

  The configurator 22 is illustratively web-based such that a user can access the configurator 22 via the Internet, but the configurator 22 is accessed via any suitable network or communication link. It's okay. The exemplary user computer 20 shown in FIG. 1 includes a display 21, a processor 32 (eg, a central processing unit (CPU)), and a memory 34 accessible by the processor 32. The computer 20 may include any suitable computing device such as a desktop computer, laptop, mobile device, smart phone or the like. Running on the user computer 20 is a web browser 36 containing software or firmware code, which is used to access the graphical user interface provided by the configurator 22 and displays the graphical user interface. 21 is also used for displaying on the screen. See, for example, the graphical user interface 200 illustrated in FIGS.

  Various other arrangements of components and corresponding connectivity of the cloud computing system 10 that can be substituted for those shown are available, and the arrangement of such components and the corresponding connectivity are disclosed herein. According to the preferred embodiment.

  Referring to FIG. 2, an exemplary node 16 of the node cluster 14 of FIG. 1 that is configured by the configurator 22 is illustrated according to one embodiment. Node 16 includes at least one processor 40 that operates to execute software or firmware stored in memory 42. Memory 42 includes one or more physical memory locations and may be internal to processor 40 or external.

  FIG. 2 shows the software (or firmware) code loaded on each node 16, which includes operating system 44, kernel mode measurement agent 46, network topology driver 48, and user mode measurement agent. 50, web application server 52, workload container module 54, service-oriented architecture runtime agent 56, and composite workload engine 58. In the illustrated embodiment, the kernel mode measurement agent 46 and network topology driver 48 from the operating system 44 to access specific data such as, for example, data from an input / output (I / O) device of the node 16. Requests the privilege of On the other hand, the user mode measurement agent 50, the web application server 52, the workload container module 54, the service-oriented architecture runtime agent 56, and the composite workload engine 58 illustratively have access to data or their respective functions. In order to do so, no privileges from the operating system 44 are required.

  The operating system 44 manages the overall operation of the node 16 including, for example, managing applications, privileges and hardware resources, and allocating processor time and memory usage. The network topology driver 48 operates to control the network characteristics and network parameters of the node 16 on the communication network 18 (FIG. 1). In one embodiment, network topology driver 48 operates to change the network characteristics associated with node 16 based on configuration file 28 (FIG. 1) received from configurator 22 (FIG. 1).

  A network software stack (not shown) is stored and executed at each node 16. The network software stack includes a network socket to facilitate communication over the network 18 of FIG. In the embodiments described herein, network sockets include TCP sockets that are assigned an address for network communication and one or more port numbers. In one embodiment, the network software stack utilizes a network driver of the operating system 44.

  Each of kernel mode measurement agent 46 and user mode measurement agent 50 operates to collect and analyze data for monitoring operation and workload performance at node 16. The kernel mode measurement agent 46 monitors, for example, the number of processor instructions, processor utilization, the number of bytes transmitted and received for each I / O operation, and other suitable data, or combinations thereof. An exemplary kernel mode measurement agent 46 includes SystemTap software. User mode measurement agent 50 collects performance data that does not require system privileges from operating system 44 to access the data. Examples of this performance data include application-specific logs that show the start and completion times of individual subtasks, the speed at which such tasks are executed, the amount of virtual memory utilized by the system, and for certain tasks The amount of input records processed, etc. In one embodiment, agents 46, 50 and / or other monitoring tools are pre-installed on each node 16 and configured by the configurator 22 at each node 16 based on the configuration file 28 (FIG. 1). Alternatively, the configured agent 46, 50 and / or other monitoring tools are loaded by the configurator 22 onto the node 16 during workload deployment.

  The web application server 52 is an application that controls communication between the node 16 and both the control server 12 and the other nodes 16 of the node cluster 14 of FIG. The web application server 52 provides file transfer between the nodes 16 and file transfer between the control server 12 and the nodes. An exemplary web application server 52 is Apache Tomcat.

  The workload container module 54 is also stored in the memory 42 of each node 16. As described herein, the control server 12 provides the workload container module 54 to the node 16 based on the user selection and the configuration of the workload container module 54. Examples of the workload container module 54 include Apache Hadoop, Memcached, Apache Cassandra, or a custom workload container module provided by a non-commercial user. It is done. In one embodiment, workload container module 54 includes a file system 55 that includes a code module that manages data storage in memory 42 and data communication between nodes 16 when executed by a processor. The exemplary file system 55 is an Apache hadoop workload container distributed file system (HDFS). File system 55 supports data replication by storing multiple copies of data and files in node memory 42.

  Other suitable workload container modules may be provided, such as an optional service-oriented architecture (SOA) runtime agent 56 and an optional composite workload engine 58. The SOA runtime agent 56 is another type of workload container module that operates to coordinate workload execution when executed by a processor. The SOA runtime agent 56 performs a service function for caching or serving a frequently used file (for example, an image or the like), for example, in order to speed up a workload operation. An example of the SOA runtime agent 56 is Google Protocol Buffers. Synthetic workload engine 58, as described herein, is a workload container that operates to activate and execute a synthetic test workload received via configurator 22 (FIG. 1) when executed by a processor. Includes modules. In the illustrated embodiment, the synthetic workload engine 58 is tailored to run on a synthetic test workload rather than an actual non-test workload.

  Referring to FIG. 3, the configurator 22 of the control server 12 according to one embodiment is shown. The configurator 22 illustratively includes an authenticator 70, a node configurator 72, a network configurator 74, a workload container configurator 76, a workload configurator 78, a batch processor 80, and a data monitor configurator 82. And a data aggregator 84, each of which is stored in memory (eg, memory 90) accessible by one or more processors 22 of control server 12 to perform the various functions described herein. One or more processors 22 of the control server 12 executing respective software code modules or firmware code modules. Authenticator 70 includes one or more processors 22 that execute an authentication code module and operates to authenticate user access to configurator 22 as described herein with respect to FIG. Node configurator 72 includes one or more processors 22 that execute a node configuration code module and, as described herein with respect to FIGS. 8-10, a multi-node cluster having specified hardware and operational configurations. In order to identify 14, it operates to select and configure node 16. The network configurator 74 includes one or more processors 22 that execute a network configuration code module, such as testing and performance analysis and / or adjusting system power consumption, as described herein with respect to FIGS. Therefore, it operates to adjust the network parameters of the communication network 18 of FIG. Workload container configurator 76 includes one or more processors 22 that execute a workload container configuration code module, and as described herein with respect to FIGS. 18-21, a workload container for operation on node 16. Operates to select and configure a module. Workload configurator 78 includes one or more processors 22 that execute the workload configuration code module to select and configure the workload for execution in the workload container selected by node 16. Operate. Workload configurator 78 illustratively includes a code synthesizer 79 that includes one or more processors 22 that execute a synthetic test workload generation code module, which is now described with respect to FIGS. 23 and 32-35. As stated, it operates to generate a synthetic test workload based on user-defined workload parameters. The batch processor 80 includes one or more processors 22 that execute batch processor code modules and operate to initiate batch processing of multiple workloads as described herein with respect to FIG. Are executed in a sequence on the node cluster 14. The data monitor configurator 82 includes one or more processors 22 that execute a data monitoring configuration code module, as described herein with respect to FIGS. Operate to configure a monitoring tool to collect. Data aggregator 84 includes one or more processors 22 that execute data aggregation code modules and collect and aggregate performance data from each node 16 as described herein with respect to FIGS. 30 and 31. And operate to generate logs, statistics, graphs, and other representations of data.

  The output from the configurator 22 is illustratively stored in the memory 90 of the control server 12. Memory 90 may be internal or external to one or more processors of control server 12, and may include one or more physical memory locations. The memory 90 illustratively stores the configuration files 28 and 30 of FIG. 1 generated by the configurator 22. The memory 90 stores a log file 98 generated by the node 16 and transmitted to the control server 12 following execution of the workload. As shown, an operating system image file 92, a workload container image file 94 selected by the workload container configurator 76, and a workload image file 96 selected or generated by the workload configurator 78. , Stored in the memory 90. In one embodiment, a plurality of operating system image files 92 are stored in the memory 90 and the user can select an operating system to be installed on each node 16 via the configurator 22. In one embodiment, a user can upload an operating system image file 92 to be installed on node 16 from a remote memory (eg, memory 34 of computer 20 of FIG. 1) to control server 12. The workload container image file 94 is generated by the workload container configurator 76 based on the user's selection and configuration of the workload container module from a plurality of available workload container modules. In the embodiment described herein, the workload container configurator 76 configures a corresponding workload container image file 94 based on user input received via the user interface 200 of FIGS. Similarly, the workload configurator 78 generates a workload image file 96 based on a user selection of a workload from one or more available workloads via the user interface 200 of the control server 12 to configure. To do. The workload image file 96 includes a pre-defined actual workload selected by the workload configurator 78 based on user input or a synthetic test workload generated by the workload configurator 78 based on user input.

  In one embodiment, the memory 90 is accessible by each node 16 of the node cluster 14 and the control server 12 provides a pointer or other identifier that identifies the location within the memory 90 of each image file 92, 94, 96. The data is sent to each node 16 of the node cluster 14. The node 16 retrieves each image file 92, 94, 96 from the memory 90 based on the pointer. Alternatively, the control server 12 loads the image file 92, 94, 96 and the appropriate configuration file 28 into each node 16, or by any other suitable mechanism. A configuration file 28 is provided to the node 16.

  As described herein, the configurator 22 operates to automatically perform the following actions based on user selection and user input. That is, a desired resource (for example, node 16) is allocated, node 16 is configured in advance (for example, network topology, memory characteristics), workload container software is installed in each node 16, and user-provided workload software and data are installed. Deploy to nodes 16, start monitoring tools (eg Ganglia, SystemTap) and start collecting performance data from each node 16, provide live status updates to users when running workloads, Collect all data requested by the user, including loading results and information gathered by monitoring tools, process, summarize, display and perform other appropriate functions requested by the user. Further, the user may create and deploy a sequence of workloads that are executed sequentially or in parallel using the configurator 22 as described herein. The user may repeatedly execute any or all workloads during or between executions, with optional adjustment of configuration or input parameters. The configurator 22 also operates to store data on the designated database node 16 of the node cluster 14 based on a user request.

  FIG. 4 is a flow diagram 100 of exemplary operations performed by the configurator 22 of FIGS. 1 and 3 to configure a cloud computing system. 1 and 3 are referred to throughout the description of FIG. In the illustrated embodiment, the configurator 22 is based on a plurality of user selections received via a user interface, such as the user interface 200 shown in FIGS. 7-30, according to the flow diagram 100 of FIG. To configure. In block 102, the node configurator 72 of the configurator 22 selects the multi-node cluster 14 from the plurality of available nodes 16. Each node 16 of the multi-node cluster 14 includes at least one processing device 40 and memory 42 (FIG. 2) to share the workload processing with other nodes 16 of the cluster 14 as described herein. To work. In the illustrated embodiment, multiple nodes 16 are available for selection by configurator 22, and configurator 22 selects a subset of available nodes 16 as node cluster 14. In one embodiment, the configurator 22 selects at least one type of data to be collected from each node 16 of the multi-node cluster 14 based on the user selection received via the user interface and the data aggregator 84 of the configurator 22. Collects and aggregates the at least one type of data from each node 16 of the multi-node cluster 14 as described herein with respect to FIGS.

  At block 104, the workload container configurator 76 of the configurator 22 selects a workload container module for operation on each node 16 of the selected cluster 14 comprising multiple nodes. The workload container module includes a selectable code module that, when executed by the node 16, operates to initiate and coordinate the execution of the workload. In one embodiment, the workload container module is selected from a plurality of available workload container modules, as described herein with respect to FIG. In one embodiment, configurator 22 modifies at least one operational parameter of the workload container module on each node 16 based on user input received via the user interface. The at least one operational parameter is associated with at least one of a read / write operation, a file system operation, a network socket operation, and a sorting operation, as described herein.

  In one embodiment, the selected workload container module is a custom workload container module stored on memory remote from the cloud computing system 10 (eg, memory 34 of FIG. 1), and the configurator 22 is remote The custom workload container module stored in the memory is loaded into each node 16 of the multi-node cluster 14. For example, custom workload container modules include non-commercial workload container modules provided by users. In one embodiment, the custom workload container module includes a configuration file that includes user-defined instructions and parameters for executing the workload. Examples of instructions include instructions for testing workload parameters that are not often found in typical workloads and / or are specific to a particular workload. Other examples of custom workload container module instructions include instructions for redirecting execution output or log files to a different location for further analysis. Alternatively, the workload container module is stored in a computing system 10 such as Apache Hadoop, Memchashed, Apache Cassandra, etc. (eg, memory 90 of FIG. 3). And a commercially available third party workload container module available for selection and deployment by the configurator 22.

  At block 106, the workload configurator 78 of the configurator 22 selects a workload for execution in the workload container module on the multi-node cluster 14. The processing of the selected workload is distributed across a multi-node cluster 14 as described herein. In one embodiment, the workload is selected from at least one of an actual workload and a synthetic test workload. One or more actual pre-compiled workloads are stored in a memory accessible by the processor of the control server 12 (eg, memory 34 of FIG. 1), and the configurator 22 Load to 16. The synthetic test workload is generated by the configurator 22 based on user-defined workload parameters received via the user interface 200 and loaded into each node 16 as described herein with respect to FIGS. 23 and 32-35. The In one embodiment, configurator 22 adjusts at least one communication network parameter based on user input received via user interface 200 as described herein with respect to FIGS. 11-17 to select a selected workload. Modify or limit the performance of the communication network 18 during execution.

  In the illustrated embodiment, the configurator 22 selects selectable node data (eg, table 258 of FIG. 8), selectable workload container data (eg, selectable input 352 of FIG. 18), and selectable workload data (eg, A user interface 200 (FIGS. 7-30) is provided including selectable inputs 418) of FIG. A multi-node cluster 14 is selected based on a user selection of selectable node data, a workload container module is selected based on a user selection of selectable workload container data, and a workload is a user of selectable workload data. Selected based on selection.

  FIG. 5 is a flow diagram 120 of other exemplary operations performed by the configurator 22 of FIGS. 1 and 3 to configure the cloud computing system 10. 1 and 3 are referred to throughout the description of FIG. At block 122, the workload container configurator 76 is for operation on each node 16 of the cluster 14 of multiple nodes of the cloud computing system 10 based on a user selection received via a user interface (eg, the user interface 200). The workload container module is selected from a plurality of available workload container modules. In the illustrated embodiment, the workload container module is selected based on selectable workload container data such as, for example, inputs 352, 360, 362 in FIG. 18 and inputs 353, 401 in FIG. The selected workload container module includes selectable code modules (eg, selectable with inputs 360, 362 in FIG. 18 and input 401 in FIG. 21) that operate to coordinate the execution of the workload. In one embodiment, the plurality of available workload container modules includes custom workload container modules, as described herein. In block 124, the node configurator 72 selects each node 16 of the multi-node cluster 14 with the selected workload container module to execute the workload so that the processing of the workload is distributed to the multi-node cluster. Configure. As described herein, each node 16 includes a processing device 40 and memory 42 and operates to share workload operations with other nodes 16 of the multi-node cluster 14. The configurator 22 installs the selected workload container module on each node 16 of the multi-node cluster 14 and starts executing the workload on the selected workload container module on the multi-node cluster 14.

  FIG. 6 is a flow diagram 140 of other exemplary operations performed by the configurator 22 of FIGS. 1 and 3 to configure the cloud computing system 10. 1 and 3 are referred to throughout the description of FIG. At block 142, the node configurator 72 of the configurator 22 selects from the multiple available nodes 16 for the cloud computing system 10 the multi-node cluster 14 that operates to share the processing of the workload. In the illustrated embodiment, a multi-node cluster 14 is selected based on selectable node data, as described herein.

  At block 144, the workload container configurator 76 uses the same work for each node 16 based on user input received via the user interface (eg, selectable input 367 and fields 374, 378, 380 of the user interface 200 of FIG. 19). Correct the operating parameters of the load container module. This same workload container module includes a selectable code module that operates to coordinate the execution of the workload based on operational parameters when executed by the node 16. The operational parameter is associated with at least one of a read / write operation, a file system operation, a network socket operation, and a sorting operation, as described herein with respect to FIGS. The configurator 22 may include one or more operational parameters prior to deploying the workload container module to each node 16 or after deploying the workload container module to each node 16 when updating the configuration. To correct. The workload container module, when executed by each node 16, operates to coordinate the execution of the workload on the multi-node cluster 14 based on the modified operating parameters. In one embodiment, the operation parameters include the memory buffer size for read / write operations, the size of data blocks transferred during read / write operations, the number of data blocks stored in the memory 42 of each node 16, files It includes the number of processing threads of each node 16 allocated to process requests to the system 55 and / or the number of data streams that merge when sorting the data. Other suitable operating parameters may be modified as described with respect to FIGS.

  An exemplary user interface 200 that provides user access to the control server 12 of FIG. 3 is shown in FIGS. The user interface 200 is illustratively a web-based graphical user interface 200 that includes a plurality of selectable screens configured for display on a display, such as the display 21 of the computer 20 (FIG. 1). Other suitable interfaces such as native user interface applications, command line driven interfaces, programmable APIs, other types, or combinations of multiple interfaces may be provided. The user interface 200 is linked to and inputs to the components 70-84 of the configurator 22, such as selectable inputs, fields, modules, tabs, drop down menus, boxes and other suitable selectable data. Contains selectable data to provide. In one embodiment, the selectable data of the user interface 200 is rendered in such a way that it can be individually selected. For example, the selectable data is selected by the user by a mouse pointer, by touching the touch screen of the user interface 200, by pressing a key on the keyboard, or by any other suitable selection mechanism. As a result of the selection of the data, the data may be highlighted or checked, for example, and a new screen, menu or pop-up window will appear based on the selection of some selectable data (eg, module, drop down menu, etc.). May appear.

  1-3 for the entire description of the user interface 200. As shown in FIG. 7, the user interface 200 allows for user selection by providing access to the configurator 22 when selected, as well as several other user inputs to the configurator 22. Contains selectable modules. Specifically, the authentication and configuration library module 202 includes data representing and linked to the authenticator 70 of the configurator 22. The instance module 204 represents the node configurator 72 of the configurator 22 and comprises data linked thereto. The network configuration module 206 represents the network configurator 74 of the configurator 22 and comprises data linked thereto. The workload container configuration module 208 represents the workload container configurator 76 of the configurator 22 and comprises data linked thereto. The workload configuration module 210 represents the workload configurator 78 of the configurator 22 and comprises data linked thereto. The batch processing module 212 represents the batch processor 80 of the configurator 22 and comprises data linked thereto. The monitoring module 214 represents the data monitor configurator 82 of the configurator 22 and comprises data linked thereto. The control and status module 216 represents the data aggregator 84 of the configurator 22 and comprises data linked thereto. The components 70-84 of the configurator 22 implement their respective functions based on user selections, data and other user inputs provided via modules 202-216 of the user interface 200.

  Referring to FIG. 7, the authentication and configuration library module 202 has been selected. Based on user input to module 202, authenticator 70 authenticates user access to configurator 22 and loads the previously saved system configuration. Authenticator 70 grants user access to configurator 22 by verifying the credential data in the form of an access key, secret key, and / or EC2 key pair in each field 220, 222, 224. . In the illustrated embodiment, the EC2 key pair in field 224 provides root or initial access to the newly selected node 16 when using module 202 to access the Amazon web services cloud platform. Authenticator 70 loads the previously saved system configuration from a system configuration file (eg, stored in user computer 20 or control server 12 of FIG. 1) based on the user selection of input 238. The system configuration file includes the configuration of the workload and workload container, node 16 and network configuration information, data monitoring / collection settings for the cloud computing system 10, and the system previously saved by the configurator 22. Contains all other configuration information associated with the configuration. By loading the previously saved system configuration file, the configurator 22 is updated with the configuration information from the system configuration file. The system configuration file illustratively includes a JSON file format, but other suitable formats may be provided. After loading the system configuration file, the loaded system configuration may be modified via a module of the user interface 200. When input 240 is selected, authenticator 70 saves the current system configuration of configurator 22 to a file. The authentication data may be included in a saved system configuration file based on selection of selection box 242.

  The system configuration file is identified and loaded into the control server 12 via the web-based user interface 200, but other suitable remote method invocation (RMI) may be used to obtain the system configuration file. ) Mechanisms may be used. For example, Apache Hypertext Transfer Protocol (HTTP) server, Apache Tomcat server, Tomcat survlet that passes system configuration file using RMI mechanism, or RMI mechanism Is a custom application (for example, a command line utility) that passes the system configuration file directly to the control server 12.

  The configuration library 226 provides a table or list of previously created system configuration files that are available for selection and execution via the selection input 227. Upon selection of input 228, authenticator 70 updates modules 202-216 with configuration information from the system configuration file selected in library 226. The current system configuration (eg, configured via modules 202-216) is saved to a file based on the selection of input 230 and added to library 226, and the system configuration file is selected on input 234. Is deleted from the library 226. With the input 232, the authenticator 70 uploads the system configuration file from the local computer (eg, computer 20 of FIG. 1) to the library 226, or with the input 236, the authenticator 70 receives the system configuration file. Download the file from the remote computer to the library 226 (eg, via the Internet). Library 226 allows one or more previously used system configurations to be quickly loaded and executed. The system configuration files of the library 226 may be selected and executed separately, in parallel, or sequentially on the cloud computing system 10. For example, a plurality of system configuration files may be provided in the library 226 for execution in a batch sequence, in which case the configurator 22 automatically expands each selected system configuration sequentially and each system Run one or more workloads in the configuration. In the illustrated embodiment, as described herein, the system configuration is deployed to the node 16 via the control and status module 216 of FIG. The deployment of the system configuration indicates that the configurator 22 configures the cloud computing system 10 with settings, software and workload information associated with the system configuration file, as described herein with reference to FIG. Accompany. As described herein, the configurator 22 illustratively generates one or more configuration files 28 that are routed to each node 16 to configure each node 16. The configuration file 28 expanded in the node 16 includes all the configuration information included in the system configuration file loaded via the module 202, and after the system configuration file is loaded, via the modules 202 to 216. Including any additional configuration changes made.

  Referring to FIG. 8, the instance module 204 for configuring the number and characteristics of the nodes 16 has been selected. Based on user input to the module 204, the node configurator 72 identifies and selects a multi-node cluster 14 having a specified hardware and operational configuration. The instance module 204 includes an instance tab 250, an instance type tab 252, and another instance setting tab 254. With the instance tab 250 selected in FIG. 8, the number of desired nodes 16 to be included in the node cluster 14 is entered into the field 256. The node configurator 72 generates in the table 258 a default list of the number of nodes 16 each having a particular hardware configuration under the desired number of nodes 16 selected by the user in field 256. Table 258 provides a list and configuration description of the multi-node cluster 14 of FIG. Table 258 includes a number of descriptive fields for each node 16, including the node number and name, instance (node) type, memory capacity, number of core processors (eg, CPU), storage capacity. , Quota (quota), reception / transmission quota, and reception / transmission upper limit (cap). The instance type generally describes the relative size and computing power of the nodes, illustratively micro, small, medium, large, x-large (x- large), 2x-large (2x-large), 4x-large (4x-large), etc. (FIG. 9). In the exemplary table 258 of FIG. 8, each node 16 is a large type with 7680 megabytes (MB) of memory capacity, 850 gigabytes (GB) of storage capacity, and a 4-core processor. Node configurator 72 selects node 16 based on user selection of selectable node data, illustratively selection box 259 and selectable input 262. The type of each node 16 can be changed based on the selection of the node 16 in the table 258 (eg, selection using the input 262 or selection by checking the corresponding selection box 259) and selecting the instance type edit input 260. Yes, the edit instance type input 260 displays an instance type tab 252 for the selected node 16. Referring to FIG. 9, the table 264 comprises a list of node 16 types (ie, available server hardware) that are available for selection for use in the node cluster 14. One or more nodes 16 of table 264 are selected at selectable input 265 to replace nodes 16 selected in table 258 of FIG. In one embodiment, the fields of table 264 (eg, memory, VCPUs, storage capacity, etc.) can be modified by the user to further identify the desired hardware performance characteristics of the selected node 16. Depending on available server hardware, fewer or additional node 16 types may be available for selection in table 264. In the illustrated embodiment, multiple nodes 16 are available for each node type listed in table 264 for addition to node cluster 14.

  Referring to FIG. 10, the node configurator 72 adjusts the boot time configuration of each node 16 based on the user input provided in the instance settings tab 254 of the user interface 200. The boot time configuration includes one or more boot time parameters that apply to individual nodes 16, groups of nodes 16, or the entire node cluster 14. Boot time parameters such as computing capacity, system memory capacity and / or storage capacity of each node 16 are based on user input to fields 268, 270, 272, 274 such that each node 16 operates at less than maximum capacity. Limited or restricted. The default boot time parameter is selected based on the user selection at input 269 and the customized boot time parameter is selected based on the user selection at input 271. In the illustrated embodiment, the maximum setting for each adjustable parameter is the default, but the user selects the “custom” option at input 271 to enter the configuration settings in their respective fields 268, 270, 272, 274. Then, each parameter can be adjusted.

  In the illustrated embodiment, the number of processing cores for node 16 is adjustable in field 268. For example, if the node 16 selected in the table 258 of the instance tab 250 (FIG. 8) has four processing cores, the number of processing cores that are enabled for workload execution is 0 via field 268. , 1, 2 or 3 so that one or more processing cores of the selected node 16 can be “hiding” from the operating system 44 (FIG. 2) during workload execution. The visible system memory size, that is, the size of system memory accessible by the operating system 44 (FIG. 2), can be adjusted based on inputs to fields 270 and 272. For example, if the node 16 selected in the table 258 of the instance tab 250 (FIG. 8) has a memory capacity of 2048 MB, the “visible” memory (eg, random access memory) that is enabled during workload execution is It may be reduced to less than 2048 MB so that a portion of its memory can be “hidden” from the operating system 44 (FIG. 2) during workload execution. Additional workload arguments or instructions are applied in field 274 to adjust additional boot time parameters. The number of workload arguments may be increased or decreased based on the number entered in field 274. For example, a subset of the instructions of the workload can be selected for execution in field 274, thereby hiding the remaining instructions from the operating system 44 (FIG. 2). In addition, node 16 having a 64-bit architecture can be configured based on input to field 274 so that it operates in 32-bit mode when only 32 bits are visible to operating system 44. Additional boot time parameters may be entered in field 276. In one embodiment, instructions or code may be manually entered into field 276 by the user to provide additional cloud configuration settings. For example, the master node 16 for the map reduce workload may be designated via field 276 such that a particular node 16 acts as the master at boot time. In one embodiment, limiting the operation of one or more nodes 16 with the node configurator 72, as described herein, is used to test the performance of the cloud computing system 10. In the illustrated embodiment, the boot time configuration settings specified in FIG. 10 are from the node configurator 72 to adjust the boot time configuration of each node 16, as described herein with respect to FIGS. Provided in the boot time configuration file 28 (FIG. 3) provided to each node 16.

  The configurator 22 generates the exemplary network configuration wizard window 280 shown in FIGS. 11-17 based on the user selection of the network configuration module 206 of FIG. Referring to FIG. 11, the network configuration wizard 280 provides a plurality of global network settings each including selectable data for adjusting network parameters of one or more nodes 16. Adjustable network parameters are: network delay via tab 282, packet loss via tab 284, packet duplication via tab 286, packet corruption via tab 288, packet via tab 290 Includes reordering, packet rate control via tab 292, and other custom commands via tab 294. Based on user selection and user input via the network configuration wizard 280 of the user interface 200, the network configurator 74 of FIG. 3 adjusts network parameters of the node 16 of the communication network 18 of FIG. 1, as described herein. To work. In one embodiment, network parameter modifications are used for network testing and performance analysis and / or to adjust system power consumption. In the illustrated embodiment, the network configurator 74 artificially forms network traffic and behavior based on user input to the network configuration wizard 280, thereby modeling various types of network topologies. For example, different communication networks have different latencies, bandwidths, performance, etc. depending on the network configuration. Thus, the network configurator 74 allows networks having different configurations to be implemented with workload execution to test and analyze the performance of those different networks with selected workloads. In one embodiment, testing and analysis is performed in conjunction with the batch processor 80 initiating a workload execution with a different network configuration. For example, an optimal network topology may be determined for execution of a particular workload with a selected hardware (node 16) configuration. In one embodiment, network configurator 74 operates to apply network settings to a particular group or subset of nodes 16 of node cluster 14.

  With continued reference to FIG. 11, selectable data associated with implementing communication network delay is shown in tab 282. The network configurator 74 selects and corrects the network delay based on the user selection of the inputs (exemplarily boxes) 298-301 and the fields 302, 304, 306, 308, 310, 312. The communication delay for each packet communication (ie, the packet carries data or information between nodes 16 or between a node 16 and the control server 12) over the communication network 18 (FIG. 1) is selected by the input 298. And the delay value entered via field 302. The specified communication delay variation is implemented based on the selection of input 299 and the variation value entered via field 304 (eg, illustratively plus or minus 10 milliseconds variation). Fields 310 and 312 include drop-down menus for selecting units of time (eg, milliseconds, microseconds, etc.) associated with the respective values of fields 302 and 304. Correlation between specified communication delays is implemented based on the selection of input 300 and the correlation value entered via field 306, illustratively a percentage correlation value. The specified communication delay distribution is implemented based on the selection of the drop-down menu 301. The distribution includes a normal distribution or other suitable distribution type.

  Referring to FIG. 12, selectable data related to implementing network packet loss rates is shown in tab 284. The network configurator 74 selects and corrects the packet loss rate (i.e., the rate at which packets are artificially lost) based on user selections in the inputs (e.g., boxes) 313, 314 and fields 315, 316. The packet loss rate is implemented for packet communication over the network 18 based on the selection of the input 313 and the ratio value entered via the field 315. The packet loss rate is illustratively entered as a percentage, for example 0.1% results in a loss of one packet for every 1000 packets sent by the node 16. Correlation for packet loss rate is implemented based on the selection of input 314 and the correlation value (eg, a percentage value) entered via field 316.

  Referring to FIG. 13, selectable data related to implementing network packet duplication rates is shown in tab 286. The network configurator 74 selects and corrects the packet duplication rate (ie, the rate at which packets are artificially duplicated) based on user selections in the inputs (exemplarily boxes) 317, 318 and fields 319, 320. The packet duplication rate is implemented for packet communication over the network 18 based on the selection of the input 317 and the value of the ratio entered via the field 319. The packet overlap rate is illustratively entered as a percentage, for example 0.1% results in 1 packet overlap for every 1000 packets sent by the node 16. Correlation for the packet overlap rate is implemented based on the selection of input 318 and the correlation value (eg, a percentage value) entered via field 320.

  Referring to FIG. 14, selectable data associated with implementing a network packet corruption rate is shown in tab 288. The network configurator 74 selects and corrects the packet corruption rate (i.e., the rate at which packets are artificially corrupted) based on user selections in the input (e.g., box) 321 and field 322. The packet corruption rate is implemented for packet communication over the network 18 based on the selection of the input 321 and the ratio value entered via the field 322. The packet corruption rate is illustratively entered as a percentage, for example 0.1% results in 1 packet corruption for every 1000 packets sent by the node 16. In one embodiment, a correlation for packet corruption rate may be selected and implemented.

  Referring to FIG. 15, selectable data associated with implementing a network packet reordering rate is shown in tab 290. The network configurator 74 selects and modifies the packet reordering rate (ie, the rate at which packets are reordered during packet communication) based on user selections in the inputs (eg boxes) 323, 324 and fields 325, 326. To do. The packet reordering rate is implemented for packet communication via the network 18 based on the selection of the input 323 and the value of the ratio entered via the field 325. The packet reordering rate is illustratively entered as a percentage, for example 0.1% results in a reordering of 1 packet for every 1000 packets sent by the node 16. Correlation for packet reordering rate is implemented based on the selection of input 324 and the correlation value (exemplarily a percentage value) entered via field 326.

  Referring to FIG. 16, selectable data related to implementing network communication speed is shown in tab 292. The network configurator 74 selects and modifies the packet communication rate (i.e., the rate at which packets are communicated between the nodes 16) based on user selections in the inputs (e.g., boxes) 327-330 and fields 331-338. The packet transmission rate is implemented for the communication network 18 based on the selection of the input 327 and the rate value entered via the field 331, and the ceiling (maximum value) for the packet transmission rate is selected on the input 328. And implemented based on the tolerance limit entered via field 332. Packet bursts are implemented based on the selection of input 329 and the packet burst value entered via field 333, and the tolerance limit (maximum value) for the packet burst is the tolerance entered via selection of input 330 and field 334. Implemented based on limit values. Fields 335 and 336 provide a drop-down menu for selecting a speed unit (eg, kilobytes per second), and fields 337 and 338 are a drop-down for selecting a burst unit (eg, bytes). Provide a menu.

  Referring to FIG. 17, selectable data associated with implementing network parameter adjustment is shown in tab 294. The network configurator 74 modifies network parameters associated with one or more nodes 16 on the communication network 18 based on user selection of the input (eg, box) 340 and custom commands entered via the field 342. Provide custom commands for

  Referring to FIG. 18, the workload container configuration module 208 has been selected. Based on user input to the module 208 (eg, user selection of selectable workload container data such as inputs 352, 360, 362, etc.), the workload container configurator 76 is a workload container for operation on the node cluster 14. Operates to select and configure a module. Module 208 includes a plurality of selectable tabs 350 that correspond to various available workload container modules. Each available workload container module includes a selectable code module that, when executed, operates to initiate and control the execution of the workload on the node cluster 14. There are several workload container modules available via module 208 in the illustrated embodiment, such as Apache Hadoop, Memchashed, Cassandra, and Darwin Streaming. Includes commercially available workload container modules for third parties. Cassandra is an open source distributed data management system that provides a key-value store to provide basic database operations. Darwin Streaming is an open source implementation of a media streaming application that is used to stream a variety of video media, such as QuickTime provided by Apple, Inc. While open source workload container software is illustratively provided via module 208, a closed source workload container may be provided for selection. For example, license information related to closed source workload container software may be entered or purchased via the user interface 200. One or more custom workload container modules may also be loaded and selected via the “custom” tab of module 208. Other workload container modules may be provided. A “Library” tab is also provided that provides access to a library of additional workload container modules that are available for selection, such as a custom workload container module previously used.

  Under the “Haddoop” tab of FIG. 18, the workload container configurator 76 selects an Apache hadoop workload container module based on the user selection of input 352. The Apache Hadoop version and build variant can be selected under the general tab 354 via drop-down menus 360 and 362, respectively. The operating parameters of the selected workload container module can be adjusted by the workload container configurator 76 based on user input provided via the expansion tab 356 and the custom tab 358. The operating parameters available for adjustment are illustratively dependent on the selected workload container module. For example, if Apache Hadoop is selected as the workload container module, the expanded tab 356 shown in FIG. A table 366 of possible operation parameters is displayed. The workload container configurator 76 selects operating parameters for configuration based on the user selection in the corresponding selection box 367. Table 366 provides several fields for workload container configurator 76 to receive configuration data including override field 374, master value field 378 and slave value field 380. Based on the user selection in the override field 374, the node 16 whose workload container is to be adjusted with the corresponding operating parameter is selected. Node 16 is selected in override field 374 based on the user selection in the corresponding drop-down menu or based on the user selection of input 384. Illustratively, the selection of “never” results in a default configuration of the corresponding operating parameters implemented at all nodes 16, and the selection of “master” or “slave” The parameter adjustment implementation at the slave node 16 results in the selection of “always” resulting in the parameter adjustment implementation at all nodes 16 of the node cluster 14. Alternatively, individual nodes 16 of the node cluster 14 may be selected for implementation of adjusted operating parameters.

  In the master value field 378 and the slave value field 380, constraints, data values or other user selections provide adjustment values for the corresponding operational parameters of the workload container at the master node 16 or slave node 16, respectively. Property name field 376 illustratively lists the name of the associated operational parameter referenced in the code module of the selected workload container module. The description field 382 illustratively displays a summary to the user of relevant operating parameters. Input 386 allows the user to select or exclude all operating parameters listed in table 366. Input 388 allows the user to reverse or “undo” previous selections or parameter changes, and input 390 allows the user to enter the value provided in fields 374, 378, 380. Can be reset to default settings.

  Examples of operation parameters that can be adjusted by the workload container configurator 76 based on user selection in the table 366 include node 16 read / write (I / O) operations, sorting operations, node 16 network socket operations (eg, TCP Socket connection) and operational parameters related to the workload container file system 55 (eg, HDFS for Apache Hadoop). The operation parameters related to the read / write operation include, for example, the memory buffer size of the node 16 and the size of the data block transferred during the read / write operation. Illustratively, the memory buffer size shown in row 368 of table 366 is how much data is buffered (temporarily stored in the cache) during node 16 read / write (I / O) operations. ) In the illustrated embodiment, the memory buffer size is a multiple of the node hardware memory page or data block size. A memory page or block of data refers to a fixed length block or virtual memory of node 16, which is the smallest unit of data for memory allocation and memory transfer, as described herein. In the row 368 of FIG. 19, the values of the master node and the slave node are exemplarily set to 4096 bits, but these values are 8192 bits or the data block size of the node processor 40 (FIG. 2). May be adjusted to an appropriate multiple of. Similarly, the size of the data block transferred during a read / write operation is also adjusted based on user input to table 366.

  The operational parameters associated with the sorting operation include, for example, the number of data streams that are merged simultaneously when sorting data. The operational parameters associated with the workload container file system (eg, file system 55 of FIG. 2) are stored in the memory 42 of each node 16 and the number of file system records or files (eg, see line 370) and for the file system 55. Contains the number of processing threads for each node 16 allocated for processing requests. In the exemplary row 370 of the table 366, the number of records stored in the memory 42 for the file system 55 of FIG. 2 is both 100,000 records for the master and slave nodes 16, but the other An appropriate recording limit value may be entered. In one embodiment, limiting the number of file system records helps to limit file replication by the file system 55.

  Operating parameters related to the configuration and operation of network sockets such as the TCP network socket described herein involve the interaction of the workload container and the network socket. For example, network socket communication delay or latency and the number of packets sent over the network 18 (FIG. 1) may be adjusted. For example, to adjust the latency and number of data packets sent over the TCP socket connection of node 16, row 372 of table 366 is an algorithm, illustratively “Nagle's algorithm known in the art. algorithm) ”) field 378, 380, the activation / deactivation is enabled. Other suitable operating parameters related to the operation of the network socket may be adjusted.

  Other exemplary operating parameters that can be adjusted by the workload container configurator 76 include the number of software tasks that are concurrently executed by the processor 40 of the node 16. For example, the user may specify a certain number of tasks (for example, JAVA (registered trademark) tasks) that are simultaneously executed during the execution of the workload through the input to the table 366, and the workload container configurator 76 is associated with this. Adjust the number of tasks. Other suitable operating parameters associated with the workload container may be adjusted.

  Referring to the custom tab 358 of FIG. 20, additional configuration adjustments are made to the selected workload container module, illustratively a haha, to allow further customization of the selected workload container module. May be implemented for a dope workload container module. The workload container configurator 76 further adjusts the configuration of the selected workload container module based on the command string entered in the fields 392, 394, 396 and the user selection in the corresponding selectable box 398. In the illustrated embodiment, these fields 392, 394, 396 place the number of temporary data, the number of tasks in the hadoop master node, the hadoop file system, the task tracker, respectively. Specifies the configuration applied to parameters related to map reduce execution, such as the local directory and other appropriate parameters.

  Operating parameters associated with other available workload container modules (eg, Mem Cash Dee, Cassandra, Darwin Streaming, etc.) are adjusted in the same manner as described for the Hadoop Workload Container Module. Based on the input 352 of module 208 and the configuration information provided via tabs 354, 356, 358, workload container configurator 76 loads workload container image file 94 for loading into node 16 of node cluster 14. (FIG. 3) is generated. In one embodiment, the workload container image file 94 is saved in the memory 90 of the control server 12 or in the memory 42 of the node 16 and the workload container configurator 76 updates the image file 94 with configuration information. In one embodiment, multiple configurations of workload container modules may be saved and then executed sequentially, for example, to investigate the impact of workload container configuration changes on workload and system performance. .

  Referring to FIG. 21, the workload container configurator 76 selects a user-defined custom workload container module for execution on the node 16 based on the user selection of the inputs 353, 401 of the “custom” tab of the module 208. To do. In the illustrated embodiment, custom workload container modules include workload container modules that may be provided by a user and not commercially available, as described herein. The workload container configurator 76 illustratively loads a compressed zip file that includes a workload container code module. Specifically, the zip file includes a configuration file or script including user-defined parameters for coordinating the execution of the workload on the node cluster 14. As shown in FIG. 21, the table 400 is stored in the control server 12 (or computer 20) and loaded custom workload available for user selection via one or more selectable inputs 401. Provides a list of container modules. Additional custom workload container modules are uploaded or downloaded, respectively, based on user selections in inputs 402, 404 and displayed in table 400, and custom workload container modules are deleted from table 400 based on user selections in input 403. The The user can enter the zip folder path and / or the configuration script path via the respective fields 406, 408. In one embodiment, the custom workload container module is stored at a location remote from the cloud computing system 10, such as on the memory 34 of the computer 20 (FIG. 1), and is based on a user selection of the input 402. Uploaded to the memory 90 (FIG. 3).

  Referring to FIG. 22, the workload configuration module 210 has been selected. Based on user input to module 210, workload configurator 78 (FIG. 3) operates to select and configure a workload for execution on a workload container module selected by node cluster 14. The workload configurator 78 also operates to generate a synthetic test workload to be executed on the node 16 with the selected workload container module based on user-defined workload parameters. Module 210 includes a number of selectable tabs that include a workload tab 410, a composite kernel tab 412, an MC-Blaster tab 414, a configuration library tab 416, and a CloudSuite tab. 417. Under the workload tab 410 of FIG. 22, a workload to be executed is selected by the workload configurator 78 based on a user selection of selectable workload data, illustratively including selectable inputs 418, 424, 428. The Illustratively, the available workloads include, for example, a workload suitable for execution on a Hadoop workload container (input 418), a workload suitable for execution on a memcached workload container (input 424). ) Or any other suitable workload configured for the selected workload container, such as a custom workload (input 428).

  Referring to FIG. 22, a hadoop workload has been selected based on one user selection of the corresponding input 418 from the actual workload and the synthetic test workload. The actual workload includes predefined code modules suitable for the map reduce function of the Hadoop workload container and is loaded into the control server 12 based on the identification of the actual workload storage location in field 422. . In one embodiment, the actual workload is stored on memory remote from the cloud computing system 10, such as the memory 34 of FIG. 1, and uploaded to the memory 90 of the control server 12 via field 422. In other embodiments, the actual workload is a sample hadop workload that is provided with the hadoop workload container module, or other workload that has been pre-loaded into the control server 12. Also, the synthetic test workload can be selected based on user selection of the corresponding input 418 for execution on the hadoop workload container. The number of input records, or the number of instructions to be generated with the synthetic test workload, and the number of instructions to be processed in the “map” phase of the synthetic test workload, is described in the field 420 may be entered and may be provided as an input to the synthesizer 79 (FIG. 3) of the workload configurator 78. Other input parameters for generation of the synthetic test workload by synthesizer 79 are configured via synthesis kernel tab 412 as described herein. Although a synthetic test workload has been illustratively applied for execution in a hadoop workload container, synthetic test workloads may be selected and generated for other available workload containers.

  The custom script is loaded as a pre-defined actual workload for execution in the selected workload container module via field 430 and upon user selection of input 428. The custom script comprises user-provided code that includes one or more execution commands to be executed by the node cluster 14 on the selected workload container module. In the illustrated embodiment, the custom script is used as a workload that is executed during system testing on the batch processor 80, and various network, workload container, and / or other system configuration changes are described herein. As is done, the impact on system performance is monitored during sequential workload execution.

  A predefined workload may be loaded for execution in the Mem Cash Dee workload container based on the user selection of input 424. In one embodiment, the memcached workload includes an in-memory acceleration structure that stores the key value pair via a “set” command and retrieves the key value pair via a “get” command. A key-value pair is a set of two linked data items, which are a key that is an identifier for an item of data and the data identified by that key or the location of that data. And a value that is one of the pointers. The Mem Cash Dee workload illustratively operates with a selectable MC blaster tool whose runtime is selected based on the input value to field 426. The MC blaster is a tool for stimulating the system under test by generating requests to read / write records from Mem Cash Dee on a certain number of network (eg TCP) socket connections. Each request specifies a key and a value. The MC blaster tool is configured via the MC blaster tab 414 of FIG. Referring to FIG. 24, the input to field 460 specifies the number of TCP connections to use per processing thread, the input to field 462 specifies the number of keys to operate, and the input to fields 464 and 466 is Specify a “get” command and a “set” command, respectively, that are required to be sent per second. The user-specified (custom) buffer size may be implemented by the workload configurator 78 based on the selection of the corresponding input 469 and the value entered in the field 468, and the TCP request may be “on” the input 470. It may be delayed based on the selection. A certain number of processing threads to be started may be customized by the workload configurator 78 based on the user selection of the corresponding input 473 and the value entered in the field 472. The default number of processing threads is equal to the number of active processing cores in node 16. The number of UDP replay ports is selected based on the input to field 474 and the size (in bytes) of the value stored (or returned) as a result of the workload execution is selected based on the input to field 476.

  Referring to FIG. 23, a synthetic test workload is generated by synthesizer 79 based on user input provided via synthetic kernel tab 412. Specifically, the synthesizer 79 (FIG. 3) of the workload configurator 78 is provided in a code module that is loaded into the memory 90 of the control server 12, illustratively a trace file (eg, a configuration file). Generate a synthetic test workload based on user defined parameters. The trace file contains data describing the desired computational characteristics of the synthetic test workload, as described herein. If there is a user selection of the “composite” input 434 of FIG. 23, the location of the stored trace file may be identified based on the user input to field 436 or field 438. Field 436 illustratively identifies a hard disk location (eg, memory 34 of computer 20 of FIG. 1) that contains the trace file, and field 438 illustratively a web address or URL for retrieving the trace file. Identify. Table 440 displays the trace files and previously generated synthetic test workloads that have been loaded and are available for selection. The trace file is loaded and displayed in table 440 at the user selection of input 442, deleted from table 440 at the user selection of input 444, and downloaded based on the user selection of input 446 (ie, identified in field 438). From the generated URL). The trace file is illustratively a JSON file format, but other suitable file types may be provided. The maximum number of instructions to be generated in the synthetic test workload is identified in field 448 and the maximum number of iterations of the synthetic test workload is identified in field 450. Alternatively, the previously generated synthetic test workload is a user selection of the library input 432, identification of the storage location (local hard drive, website, etc.) of the synthetic test workload in field 436 or 438, and Loaded by the workload configurator 78 based on a user selection of the input 441 corresponding to the desired previously generated synthetic test workload displayed in the table 440. The maximum number of instructions and iterations of the previously generated synthetic test workload can be adjusted in fields 448 and 450.

  The trace file is a modifiable data structure that identifies workload characteristics and user-defined parameters used as input by the synthesizer 79 to generate a synthetic test workload, illustratively a table with modifiable fields; including. This table is displayed on the user interface, such as with the user interface 200 or the user interface of the user computer 20, so that the fields of the table can be modified based on user input to the table and user selections. For example, see the table 150 of FIG. 32 described herein. The trace file further identifies at least a portion of the instruction set architecture (ISA) that is to be used as input by the synthesizer 79. The trace file further identifies other characteristics associated with the instructions of the synthetic test workload, and these other characteristics are inter-instruction dependencies (e.g., the first instruction executes the first instruction before executing the first instruction). Dependent on the completion of instructions), memory register allocation constraints (eg, constraining an instruction to take a value from a specific register), and architectural execution constraints (eg, a limited number of logical units Available to execute types of instructions). Thus, configurator 22 operates to predict how long a workload instruction should be executed based on the execution characteristics specified in the trace file.

  Examples of user-defined workload parameters described in a trace file include the total number of instructions to be generated, the type of instruction to be generated including, for example, floating point instructions, integer instructions and branch instructions, and execution, for example Instruction execution behavior (for example, execution flow) such as the probability of branching of a flow (that is, whether a branch is likely to be performed at the time of instruction execution or whether execution proceeds along the execution flow path and jumps to the branch); The distribution of data dependencies among instructions, the average size of the basic blocks executed and / or transferred, and the latency associated with instruction execution (ie how many cycles are required to execute a particular instruction or instruction type) Etc., the length of time required to execute one instruction or instruction type). In one embodiment, the user-defined workload parameter specifies which particular instruction is used as an integer or floating point instruction. In one embodiment, user-defined workload parameters specify the average number and statistical distribution of each instruction type (eg, integer, floating point, branch). In one embodiment, each instruction includes one or more input and output arguments.

  In the illustrated embodiment, the workload parameters and instruction set architecture described in the trace file are provided in a table-driven, retargetable manner. Based on changes to the contents of the table, configurator 22 operates to target different microarchitectures and systems and different instruction set architectures of node 16. An exemplary table 150 is shown in FIG. 32, which includes data representing a set of user-defined workload parameters to be input to the code synthesizer 79. Referring to FIG. 32, the table 15 includes an instruction part 152 describing a collection of instructions for the generated synthetic test workload, and an addressing mode part 154 describing an addressing mode to be used with the synthetic test workload. . Instructions and addressing modes other than those shown may be provided in table 150. The command portion 152 of the table 150 includes a number of modifiable fields 158, 160, 162, 164. Field 158 contains data identifying the instruction to be generated, field 160 contains data identifying the type of computation associated with the instruction, and field 162 is a mnemonic assigned to assist synthesizer 79 in generating code. ) Is included. Field 164 contains data that identifies the various addressing modes (i.e., ways in which instruction arguments are obtained from memory).

  In the illustrated embodiment, the input command 156 ("gen_ops.initialize ()") indicates that the instruction portion 152 of the table 150 describing the instruction to be generated has started. Line 166 shows an example of user-defined workload parameters for generating one or more instructions. Referring to the line 166, “D (IntShortLatencyArith)” entered in the field 158 specifies an integer arithmetic instruction having a short latency, and “op_add” and “addq” entered in the fields 160 and 162 indicate the instruction. Indicates an addition, that is, an “add” instruction. In one embodiment, the short latency indicates that a processor (eg, node processor 40) takes one or several cycles to execute an instruction. “Addr_regOrw_reg1r” in the field 164 indicates that the first register 0 argument is “rw” (read and write) and the second register 1 argument is “r” (read). Similarly, “addr_reg0rw_imm” in the field 164 describes other variables of the instruction. Here, the first argument (register 0 argument) is “rw” (read and write), and the second argument is “ imm "(" immediate ") value (for example, a number such as 123).

  Referring to the addressing mode portion 154 of the table 150, the exemplary row 170 includes a field 172 “addr_regOw_reg1r” that identifies a class of instructions that operate only on registers. The first register argument (ie register 0) is the destination “w” (write) and the second register argument (ie register 1) is the input “r” (read). The entries in fields 174 and 176 identify the argument and “src” for the read argument, “dst” for the write argument, or “rmw” for the read / modify / write argument. Is shown. In the x86 architecture, for example, the first register argument may be “rmw” (the argument is read, operates there and then written with the result), or other suitable argument. Additional or different user-defined workload parameters may be specified via table 150.

  In one embodiment, the table 150 (eg, trace file) is generated offline and loaded into the configurator 22, such as by the user computer 20. In one embodiment, the table 150 is stored in or loaded into the control server 12 and the user can define user-defined workload parameters via selectable and modifiable data displayed by the user interface 200. Is displayed on the user interface 200 so that it can be corrected.

  Referring to FIG. 33, an exemplary process flow for generating and executing a synthetic test workload is shown. A code synthesizer 79 is shown that generates a synthetic test workload and outputs a configuration file 28 and a synthetic workload image 96 to each node 16, and the synthetic workload engine 58 of each node 16 is described herein. Run the synthetic test workload as follows: Blocks 60, 62, 64 of FIG. 33 provide an abstract representation of the content provided in the trace file that is input to synthesizer 79. Block 60 is a general task graph representing the execution flow of the instruction set. Block 62 represents the task functions to be performed, and these task functions include an input instruction, an output instruction, a start instruction, and an end instruction. Block 64 represents workload behavior parameters, which include data block size, execution duration and latency, message propagation, and other user-defined parameters described herein.

  The synthesizer 79 illustratively includes a code generator 66 and a code emitter 68, each of which can be accessed by one or more processors 22 to perform the various functions described herein (eg, memory 90). One or more processors 22 of the control server 12 that execute the software code or firmware code stored there. The code generator 66 operates on a trace file data structure (eg, a table) that describes user-defined workload parameters and the target instruction set architecture and generates an abstracted composite code having specified execution properties. Generate. The code emitter 68 can be used from an abstract composite code (eg, assembly code to be linked in the execution harness, binary code, or position-independent code to be linked to the simulation infrastructure, etc.) to the execution environment. Create executable composite code (ie, synthetic test workload) in a suitable format. In one embodiment, the desired format of executable code is hard coded in synthesizer 79. In other embodiments, the desired format of the executable code can be selected via the user interface 200 selectable data. In one embodiment, the executable code is of a compact size so that the executable code can be executed through a cycle-accurate simulator that is not configured to run a full size workload. It is. Other suitable configurations of synthesizer 79 may be provided. In one embodiment, synthesizer 79 has access to the computer architecture data of node 16 of node cluster 14. Accordingly, the synthesizer 79 generates a synthetic test workload that targets a specific microarchitecture and instruction set architecture based on the known computer architecture data of the node cluster 14. Thus, a synthetic test workload may be targeted, for example, to exercise a desired set of architectural characteristics.

  The synthetic test workload generated by synthesizer 79 includes a code module that can be executed on node 16 along with the selected workload container module. When a synthetic test workload is generated and selected for execution, the synthetic test workload is stored in the memory 90 of the control server 12 as the workload image file 96 of FIG. The configurator 22 then loads the workload image file 96 into each node 16 for execution, or the node 16 retrieves the workload image file 96. In one embodiment, once a hadoop workload container module is selected, the synthetic test workload is executed as the “map” phase of map reduction.

  In the illustrated embodiment, the synthetic test workload is executed to exercise the computing system 10 hardware for testing and performance analysis, as described herein. The synthesizer 79 receives a desired workload behavior as input via the trace file and generates a synthetic test workload that behaves according to this input. Specifically, as described herein, statistical properties of desired workload behavior, such as the number of instructions to be executed and the statistical distribution of instruction types, are inputs to synthesizer 79. For example, a loaded trace file may contain user-defined parameters that require a program loop containing 1000 instructions, where the trace file contains 30% of the instructions are integer instructions and 10% are specific. A branch instruction having a branch structure, 40% of which are floating point instructions, and the like may be designated. The trace file (or field 450 in FIG. 23) may specify that the loop should be executed 100 times. The synthesizer 79 then generates a program loop containing the requested parameters as a synthetic test workload.

  In one embodiment, the generated synthetic test workload serves to emulate the behavior of an actual workload, such as specific proprietary code or known application or program complex code. For example, some proprietary code includes instructions that are not accessible or available to the user. Similarly, some composite code includes complex and numerous instructions. In some cases, creating a workload based on such proprietary or composite code may be undesirable or difficult. Thus, rather than creating a workload code module that contains all the instructions of a proprietary code or composite code, how the proprietary code or composite code is executed on the server hardware ( A monitoring tool (eg, offline from the configurator 22) is used to monitor whether to exercise the node 16 or other server hardware. The statistical data collected by the monitoring tool upon execution of the proprietary code is used to identify parameters that represent the desired execution characteristics of the proprietary code or composite code. A collection of parameters is provided in the trace file. The trace file is then loaded as input to synthesizer 79, which generates synthetic code that behaves similarly to proprietary code based on statistical inputs and other desired parameters. Thus, a compound code or proprietary instruction for a particular code is not required to model the behavior of that code on the cloud computing system 10.

  In one embodiment, synthesizer 79 cooperates with batch processor 80 to execute a plurality of synthetic test workloads generated by synthesizer 79 from various trace files. In one embodiment, a plurality of synthetic test workloads based on a modified user-defined workload parameter table (eg, table 150 of FIG. 32) that tests different target processors of node 16, ie, both CPUs and GPUs. Is generated.

  FIG. 34 shows a flow diagram 600 of exemplary operations performed by the configurator 22 of the control server 12 of FIGS. 1 and 3 to configure the cloud computing system 10 with a selected workload. Reference is made to FIGS. 1 and 3 for the entire description of FIG. In the illustrated embodiment, the configurator 22 configures the node cluster 14 of FIG. 1 according to the flow diagram 600 of FIG. 34 based on a plurality of user selections received via the user interface 200. At block 602, based on a user selection received via user interface 200 (eg, selection of input 418), workload configurator 78 performs a workload for execution on multiple nodes cluster 14 of cloud computing system 10. Select. The workload is selected at block 602 from a plurality of available workloads including the actual workload and the synthetic test workload. The actual workload comprises code modules stored in memory (eg, memory 90 or memory 34) that can be accessed by the control server 12, as described herein. At block 604, the configurator 22 is configured to execute the selected workload so that the processing of the selected workload is distributed across the multi-node cluster 14, as described herein. Configure a cluster 14 of 10 multiple nodes.

  In one embodiment, configurator 22 provides a user interface 200 comprising selectable actual workload data and selectable synthetic test workload data, where the selection of the workload is selectable actual workload data. And based on at least one of selectable synthetic test workload data. Exemplary selectable actual workload data includes selectable input 418 of FIG. 22 corresponding to “actual workload” and selectable inputs 424, 428 of FIG. The synthetic test workload data includes selectable inputs 418 in FIG. 22 corresponding to “synthetic workload” and selectable inputs 434, 436, and 441 in FIG. In one embodiment, workload configurator 78 selects at least one of a pre-generated synthetic test workload and a user-defined set of workload parameters based on a user selection of selectable synthetic test workload data. The pre-generated synthetic test workload comprises code modules (eg, loaded via library input 432) stored in a memory (eg, memory 90 or memory 34) accessible by the control server 12. The synthesizer 79 operates to generate a synthetic test workload based on the selection of a user-defined set of workload parameters, illustratively provided via the trace files described herein. The user-defined workload parameters in the trace file identify the execution characteristics of the synthetic test workload, as described herein.

  As described herein, exemplary user-defined workload parameters relate to the number of instructions in the synthetic test workload, the type of instruction in the synthetic test workload, and the execution of at least one instruction in the synthetic test workload. It includes at least one of latency and the maximum number of execution iterations of the synthetic test workload, and the instruction type includes at least one of an integer instruction, a floating point instruction, and a branch instruction. In one embodiment, the execution of a synthetic test workload by a multi-node cluster 14 is as described herein for the execution of an actual workload, such as a composite or proprietary workload, by a multi-node cluster 14. Operates to simulate relevant execution characteristics.

  FIG. 35 shows a flow diagram 610 of exemplary operations performed by the configurator 22 of the control server 12 of FIGS. 1 and 3 to configure the cloud computing system 10 with a synthetic test workload. 1 and 3 are referred to throughout the description of FIG. In the illustrated embodiment, the configurator 22 configures the node cluster 14 of FIG. 1 according to the flow diagram 610 of FIG. 35 based on a plurality of user selections received via the user interface 200. At block 612, based on a set of user-defined workload parameters provided via the user interface 200, the code synthesizer 79 of the workload configurator 78 generates a synthetic test workload for execution on the multi-node cluster 14. Is generated. A set of user-defined workload parameters (eg, provided in a trace file) identifies the execution characteristics of the synthetic test workload, as described herein. At block 614, the configurator 22 tests the multi-node cluster 14 to test the synthetic test workload so that the processing of the synthetic test workload is distributed across the multi-node cluster, as described herein. Configure with workload.

  In one embodiment, the generation of the synthetic test workload is further based on computer architecture data that identifies at least one of an instruction set architecture and a microarchitecture associated with the multi-node cluster 14. As described herein, in one embodiment, the configurator 22 stores computer architecture data in memory (so that the configurator 22 can identify the instruction set architecture and microarchitecture of each node 16 of the multi-node cluster 14. For example, it is stored in the memory 90). Accordingly, the configurator 22 is configured so that the synthetic test workload is configured for execution on a particular computer architecture of the node 16 of the node cluster 14 based on the computer architecture data stored in memory. Is generated. In one embodiment, the code synthesizer 79 generates a plurality of synthetic test workloads each based on a different computer architecture associated with the node 16 of the multi-node cluster 14, each computer architecture comprising an instruction set architecture and a micro-architecture. Including at least one. In one embodiment, configurator 22 provides a user interface 200 comprising selectable synthetic test workload data, and workload configurator 78 generates a synthetic test workload based on a user selection of selectable synthetic test workload data. Select a set of user-defined workload parameters for. Exemplary selectable synthetic test workload data includes selectable input 418 of FIG. 22 corresponding to “synthetic workload” and selectable inputs 434, 436, 441 of FIG. In one embodiment, the set of user-defined workload parameters is a data structure (eg, table 150 of FIG. 32) displayed on a user interface (eg, a user interface displayed on user interface 200 or display 21 of computer 20). This data structure includes a plurality of modifiable input fields that each identify at least one user-defined workload parameter, as described herein with respect to table 150 of FIG. In one embodiment, the configurator 22 may modify the modified hardware of at least one node 16 of the node cluster 14 based on a user selection received via the user interface 200 (eg, selection of a boot time parameter at inputs 269-276). Select the hardware configuration. In this embodiment, the configurator 22 configures the multi-node cluster 14 with the synthetic test workload to execute the synthetic test workload on the multi-node cluster 14 having the modified hardware configuration. The modified hardware configuration results in at least one of reduced computing capacity and reduced memory capacity at the at least one node 16, as described herein.

  Referring again to FIG. 23, a previously saved workload may be loaded from local memory (eg, memory 90 of FIG. 3) via configuration library tab 416. Workloads loaded via the configuration library tab 416 include actual workloads, synthetic test workloads, custom scripts, or any other workload suitable for execution in the selected workload container module. You can leave. The loaded workload configuration may be modified based on user input to module 210 of user interface 200. The current workload configuration may also be saved to memory 90 via configuration library tab 416.

  In the illustrated embodiment, a collection of cloud suite workloads may be loaded and configured via tabs 417. A cloud suite is a collection of workloads with typical cloud workloads used to characterize cloud systems.

  Referring to FIG. 25, the batch processing module 212 is selected. Based on user input to module 212, batch processor 80 (FIG. 3) operates to initiate batch processing of multiple workloads. The batch processor 80 may also have various network configurations, various workload container configurations, various synthetic workload configurations, and / or various node configurations (eg, boot time configurations, as described herein). It also operates to initiate execution of one or more workloads having a plurality of different configurations. Based on user input, the batch processor 80 initiates each workload and / or configuration execution in turn on the node cluster 14 so that no manual intervention is required to complete the execution of all workloads. . Further, the batch processor 80 may configure these so that one or more workloads can be executed multiple times based on user settings received via the module 212 of the user interface 200. The batch processor 80 operates to execute the actual workload and / or the synthetic test workload as a batch. In the illustrated embodiment, performance data is monitored and aggregated from batch processing of multiple workloads to allow automatic system tuning, for example as described herein with respect to FIGS.

  The number of executions for a workload and / or configuration batch is specified via the repeat count field 480. Based on user input to field 480, batch processor 80 executes one or more workloads a specified number of iterations. The batch sequence table 482 comprises display data that lists batch jobs to be executed by the node cluster 14. A batch job contains one or more workloads suitable for execution a specified number of times (specified based on input to field 480). In one embodiment, a batch job includes one or more cloud system configurations suitable for a specified number of executions in one or more workloads. Although only one batch job is listed in the table 482, multiple batch jobs may be added to the table 482. Batch processor 80 selects one or more listed batch jobs for execution based on a user selection of one or more inputs 483 corresponding to the listed one or more batch jobs. In one embodiment, the selected batch jobs are executed sequentially in the order in which they are listed in table 482. The batch job is illustratively in the form of a JSON file format, but other suitable formats may be used. Batch jobs listed in table 482 are edited, added and deleted, respectively, based on user selection of inputs 484, 486 and 488. The order of the batch sequence can be adjusted based on user selection of inputs 490, 492 to move the selected batch job to a different position in the sequence displayed in table 482. The batch sequence and other settings related to the execution of the batch job may be loaded from memory (eg, memory 34 or memory 90) via selectable input 494, and the currently configured batch sequence is selectable input. It may be saved to memory (eg, memory 34 or memory 90) via 496. Inputs 484-496 are illustratively selectable buttons.

  Referring to FIG. 26, the monitoring module 214 is selected. Based on user input to module 214, data monitor configurator 82 (FIG. 3) configures one or more data monitoring tools that are used to monitor and collect performance data during the execution of workloads on node cluster 14. Works like a figure. Data monitor configurator 82 operates to configure a monitoring tool that monitors data related to node 16 performance, workload, workload container, and / or network 18. In one embodiment, the monitoring tools configured by the data monitor configurator 82 include both commercially available monitoring tools and custom monitoring tools provided by the user. The monitoring tool collects data from multiple sources and other available nodes 16 in the cloud computing system 10. For example, the monitoring tool includes a kernel mode measurement agent 46 and a user mode measurement agent 50 (FIG. 2) that collect data at each node 16. The control server 12 also includes one or more monitoring tools that operate to monitor network and computing performance on the node cluster 14. In one embodiment, based on user input (eg, input to fields 530 and 532 of FIG. 27), data monitor configurator 82 specifies a sampling rate at which one or more monitoring tools monitor data from node 16. The data monitor configurator 82 operates to configure and initiate the operation of a plurality of data monitoring tools, which are Apache Hadoop monitoring tools (tabs 500), control servers provided on each node 16. 12 ganglia tool provided on 12 (tab 502), system tap tool provided on each node 16 (tab 504), and virtual memory statistics and I / O provided on one or more nodes 16 Includes a monitoring tool (tab 506) for statistics.

  The hadoop monitoring tool monitors the performance of the node 16 at the workload container level when a hadoop workload container module is selected for execution on the node 16. The Hadoop monitoring tool is sent to each node 16 by the configurator 22 along with the Hadoop workload container module to monitor data related to the performance of the Hadoop workload container module based on the monitoring configuration identified in FIG. And loaded. As shown in FIG. 26, various monitoring parameters associated with the Hadoop monitoring tool are configured by the data monitor configurator 82 based on user inputs to several modifiable fields and drop-down menus. The modifiable monitoring parameters are: default log level (selected based on input to drop-down menu 508), maximum file size of collected data (selected based on input to field 510), collected data The total size of all files (selected based on input to field 512), the log level of the JobTracker tool in the Hadoop Workload Container (selected based on input to drop-down menu 514), Hadoop The log level of the TaskTracker tool in the workload container (selected based on input to the drop-down menu 516) and the log level of the FSNamesystem tool in the Hadoop workload container (drop-down menu) 51 Including to) selected on the basis of the input to the. The log level identifies the type of data to be collected via the Hadoop monitoring tool, such as information (“INFO”), warning, error. The job tracker tool, task tracker tool and F name system tool of the Hadoop workload container include various processes and data tracked by the data monitor configurator 82, which, for example, initiates the workload on the master node 16. And end, metadata associated with the file system 55 (FIG. 2), and the start of a map reduce task at the worker node 16. Other suitable data may be collected with a hadoop monitoring tool.

  Referring to FIG. 27, the ganglia monitoring tool also operates to monitor and collect performance data of the cloud computing system 10 based on the monitoring configuration implemented by the data monitor configurator 82. Ganglia is a known system monitoring tool that provides graphs and charts showing remote live viewing of system performance (eg, via control server 12) and historical statistics. In the illustrated embodiment, the ganglia monitoring tool is executed on the control server 12 based on the configuration data provided by the data monitor configurator 82. Examples of data monitored by the ganglia include an average processing load of the node processors 40 (CPUs) at the time of executing the workload, use of the node processor 40 and the network 18 at the time of executing the workload (for example, a stop or inactive time (stall) or inactive time), percentage of time spent processing, percentage of time spent waiting, etc.), and other suitable data. The ganglia monitoring tool is enabled and disabled by the data monitor configurator 82 based on the user selection of the selectable input 520 and the unicast or multicast communication mode is selected by the data monitor configurator 82 based on the user selection of the selectable input 522. Is done. Other configurable monitoring parameters associated with ganglia are the graph data refresh interval generated from the collected data (selected based on input to field 524), the cleanup threshold (to field 526). And an interval for transmitting metadata (selected based on input to field 528). The data input to fields 524, 526, 528 is illustratively in units of seconds. The data monitor configurator 82 collects based on the values (e.g., units are seconds) entered in the respective fields 530, 532 to collect data during the execution of the workload associated with the node processor 40 (CPU) (i.e., units are seconds). Sampling) and transmission intervals, processing load on the node 16 (eg, related to the workload being executed), usage of the node memory 42, network performance of the node 16 on the communication network 18, It operates so as to adjust the hard disk usage of each node 16.

  The system tap tool is a kernel mode measurement agent 46 (FIG. 2) that includes system tap monitoring software that operates to extract, filter, and group data associated with the nodes 16 of the cloud computing system 10. In one embodiment, the system tap tool is executed on each node 16. The system tap is implemented with a Linux (registered trademark) based operating system. The system tap allows customized monitoring scripts to be loaded into each node 16 with a customized monitoring configuration including, for example, sampling rate and histogram generation and display. As shown in FIG. 28, when the “Script” tab is selected, the system tap is enabled or disabled by the data monitor configurator 82 based on the user selection of the input 536. The system tap script file is downloaded to the control server 12 by the data monitor configurator 82 and added for display in the table 538 based on the user selection of each input (button) 540 or in the table 538. Removed / deleted from the display. The table 538 comprises display data that displays script files that are available for selection based on user selection of the corresponding one or more inputs 539. The data monitor configurator 82 loads the selected script file in the table 538 to each node 16 when the configurator 22 develops the cloud configuration. Other appropriate configuration options based on user input and user selection via tab 534 are available for the system tap monitoring tool, such as, for example, Disk I / O. ), Network I / O and Diagnostics configurations.

  Referring to FIG. 29, an I / O time tab 506 provides user access to configure additional monitoring tools that are loaded into one or more nodes 16. Includes virtual memory statistics (VMStat) and input / output statistics (IOStat). VMStat, for example, collects data related to the availability and use of system memory and block I / O controlled by the operating system, processing performance, interrupts, paging, and the like. For example, VMStat collects data related to system memory usage, such as the length or percentage of time the system memory and / or memory controller is busy or waiting to perform read / write operations To do. IOStat, for example, collects data related to storage I / O statistics (eg, usage, availability, etc.) controlled by the operating system. For example, IOStat collects data related to the percentage of time that the processing core of processor 40 of the corresponding node 16 is busy executing instructions or waiting to execute instructions. VMStat and IOStat are enabled / disabled by the data monitor configurator 82 based on the corresponding user selection of the respective inputs 546, 548, and the sampling rate (ie refresh interval) is the value entered into the fields 550, 552 (example) The unit is selected by the data monitor configurator 82 based on the second). Based on the user selection of the corresponding “enabled” inputs 546, 548 and the values entered in the fields 550, 552 of the tab 506, the data monitor configurator 82 configures the VMStat monitoring tool and the IOStat monitoring tool, and configures the configurator. 22 loads the tool into each node 16 when there is a user selection of the corresponding “enabled” input 546, 548.

  These monitoring tools configured with data monitor configurator 82 work together to monitor system performance and provide dynamic instrumentation for cloud computing system 10. Based on data collected via the configured monitoring tool, the configurator 22 diagnoses system bottlenecks and optimizes system configuration (eg, hardware and network configuration), eg, as described herein. Works to determine. In addition, the data monitor configurator 82 receives the user input used to configure each monitoring tool and displays the monitored data from each tool on the monitoring module 214 on the user interface 200. Provides a common user interface.

  Referring to FIG. 30, the control and status module 216 with selectable data has been selected. Based on user input to module 216, configurator 22 may launch (ie, deploy) the system configuration to node cluster 14 by generating a plurality of configuration files 28 that are loaded into each node 16. To work. The configurator 22 initiates deployment of the current system configuration (ie, the system configuration currently identified in modules 202-216) based on the user selection of selectable input 560. The batch processor 80 of the configurator 22 initiates batch processing of one or more workloads and / or configurations, ie, the batch sequence identified in the table 482 of FIG. 25, based on the user selection of the selectable input 562. Workload configurator 78 of configurator 22 initiates execution of a custom workload, such as the custom workload identified in field 430 of FIG. 22, based on the user selection of selectable input 564. If there is a system configuration deployment based on user selection of inputs 560, 562, 564, the configurator 22 selects each of the selected nodes and whatwork settings, workloads, workload container modules, data monitoring tools, etc. The configured node 16 is automatically configured, and the node cluster 14 is instructed to start executing the selected workload and / or batch job based on the system configuration information. The configurator 22 terminates or pauses the workload execution prior to its completion based on user selection of selectable inputs 566, 568, respectively. The configurator 22 resumes the currently executing workload on the node cluster 14 based on the user selection of the selectable input 570. The configurator 22 skips the currently executing workload on the node cluster 14 based on the user selection of the selectable input 572, for example, so that the node 16 proceeds to execute the next workload in the batch. Based on the selection of selectable input 576, data monitor configurator 82 of configurator 22 implements the data monitoring tools, settings and configurations identified via module 214. In one embodiment, implementing data monitoring settings on the nodes 16 includes generating a corresponding configuration file 28 (FIG. 3) that is provided to each node 16. Following the completion of one or more workload executions, i.e., following the receipt of the workload execution results and the collection of all requested data from the node cluster 14, the configurator 22 determines that the node cluster 14 is Terminate or shut down. The inputs 560 to 572 and the inputs 582 to 595 are illustratively buttons.

  System status is provided via displays 578 and 580 during workload execution. The displays 578 and 580 show the progress of the workload execution and status information associated with each active node 16 of the node cluster 14. The display of the system status is enabled or disabled based on the user selection of the button 595.

  In the illustrated embodiment, each of the node configurator 72, network configurator 74, workload container configurator 76, workload configurator 78, batch processor 80, and data monitor configurator 82 (FIG. 3) has their respective configurations. Following the start of deployment via inputs 560, 562, 564 for implementing functionality, at least one corresponding configuration file 28 is automatically generated. The configuration file 28 includes corresponding configuration data and instructions for configuring each node 16 of the node cluster 14 as described herein. In one embodiment, the configurator 22 automatically loads each file 28 into each node 16 of the node cluster 14 following generation of the configuration file 28. Alternatively, a single configuration file 28 containing configuration data and instructions from each component 70-84 of the configurator 22 is generated, and the configurator 22 follows the generation of that configuration file 28 and a single The configuration file 28 is automatically loaded into each node 16 of the node cluster 14. When launching a configuration deployment with inputs 560, 562, 564, each of the operating system, workload container module, and image files 92, 94, 96 respectively corresponding to the workload are also loaded into each node. Alternatively, following generation of one or more configuration files 28 and image files 92, 94, 96 by configurator 22, node 16 retrieves configuration files 28 and / or image files 92, 94, 96. Or you may request.

  The configuration file 28 deployed to the node 16 and the system configuration file saved via the input 240 of FIG. 7 are selected and based on user input to the modules 202-216 and the default settings of the modules 202-216. Contains all loaded configuration data and information. For example, the configuration file 28 generated by the node configurator 72 may include the number of nodes 16 allocated and / or used for the node cluster 14 as well as the hardware requirements and boot of each node 16 as described herein. Including time. The hardware requirements include, for example, RAM size, number of CPU cores, and available disk space. The configuration file 28 generated by the network configurator 74 includes, for example, a global default setting applied to all the nodes 16, which node 16 belongs to a given group of the node cluster 14, and network traffic in the node group. A node configuration including a group configuration including a configuration for the network node, a configuration for network traffic to other node groups of the node cluster 14, a custom configuration for a network traffic between arbitrary nodes 16, Network parameters including latency, bandwidth, ratio of corrupted and dropped packets, correlation and distribution of corrupted and dropped packets, and ratio of reordered packets as described herein with respect to FIGS. Including data and other appropriate network parameters and network topology configuration data. The configuration file 28 generated by the workload container configurator 76 includes, for example, configuration settings for the main workload container software used to execute the workload. The configuration file 28 generated by the workload configurator 78 includes configuration settings for a predefined or composite workload container, for example, selected to be executed on the node 16. Configuration settings include, for example, synthetic test workload configuration data including a synthetic test workload image file, a maximum instruction count, a maximum repetition count, and a speed of I / O operation.

  At the start of deployment via input 560 (or inputs 562, 564), configurator 22 automatically performs several actions. In one embodiment, the configurator 22 allocates and activates the desired node 16 to select the multi-node cluster 14. The configurator 22 then passes the address (eg, IP address) of the control server 12 to each node 16 and assigns or passes an identifier and / or address to each node 16. In one embodiment, each node 16 receives one or more configuration files 28 that automatically contact the control server 12 and describe jobs and other configuration information following receipt of the control server 12 address. Configured to require. Each node 16 communicates with the control server 12 using any suitable mechanism, such as an RMI mechanism (eg, a web-based interface) designated to communicate directly with the control server 12, for example. , HTTP requests for interacting with the control server 12 via Apache HTTP server or Tomcat server, and remote shell mechanism.

  In one embodiment, configurator 22 waits until it receives a request from each node 16 of node cluster 14. In one embodiment, the configurator 22 attempts to restart a node 16 if it does not start, that is, based on no request or acknowledgment from that node 16. If the node 16 does not continue to start, the configurator 22 identifies and requests another available node 16 that was not originally included in the node cluster 14 instead of the node 16 that does not start. The alternative node 16 has the same or similar hardware specifications and processing capability as the node 16 that does not start up. In one embodiment, configurator 22 continues to monitor node 16 throughout the workload execution and restarts node 16 (and workload) that has stopped responding. The configurator 22 may detect the non-responding node 16 when executing the workload based on the failure of data monitoring or other communication failure.

  When configurator 22 receives a request from each node 16 of node cluster 14, configurator 22 determines that each node 16 is ready to proceed. In one embodiment, the configurator 22 then provides the request data to each node 16, which includes one or more configuration files 28, and the addresses and IDs (IDs) of other nodes 16 in the node cluster 14. , Image files 92, 94, 96. When the request data is received from the control server 12, the role of each node 16 in the node cluster 14 is determined. In one embodiment, the role determination is made by the control server 12 (eg, automatically or based on user input) and communicated to the node 16. Alternatively, role determination is made by the node cluster 14 using a distributed arbitration mechanism. In one embodiment, role determination depends on the workload. For example, for a node cluster 14 operating in a hadoop workload container, the first node 16 may be designated as a master node 16 (“name node”) and the remaining nodes 16 are slave / worker nodes. 16 ("datanodes"). In one embodiment, the role determination of a node 16 further depends on the hardware properties of that node 16. For example, a group of nodes 16 with slower node processors 40 may be designated as a database server for data storage, and other groups of nodes 16 with faster node processors 40 may process the workload. It may be designated as a compute node. In one embodiment, role determination is based on user input provided via configuration file 28. For example, the user may have one or more first nodes 16 performing a first task, one or more second nodes 16 performing a second task, and one or more third nodes 16 performing a first task. Allocation may be performed such as performing the third task.

  Each node 16 begins to configure its virtual network settings based on network configuration data received via one or more configuration files 28. This includes, for example, using a network delay and / or packet loss emulator, as described herein. Each node 16 further begins to install and / or configure software applications according to user requests, which applications include workload container code modules received via the workload container image file 94. In one embodiment, multiple workload container modules (eg, multiple versions / manufacturers) are preinstalled at each node 16 and a soft link to the location of the selected workload container module is in the configuration file 28. Created based on. If a synthetic test workload is generated and selected at the control server 12, each node 16 begins to activate the synthetic test workload based on the workload image file 96. Further, each node 16 starts to execute a diagnostic tool and a monitoring tool (for example, ganglia, system tap, Viemstat (VMStat), Iostat (IOStat), etc.) based on the configuration information. Finally, each node 16 starts executing the selected workload.

  In the illustrated embodiment, the steps performed by the configurator 22 and the node 16 following the deployment launch are synchronized between the nodes 16 of the node cluster 14. In one embodiment, the configurator 22 of the control server 12 coordinates multiple nodes 16, but alternatively one or more nodes 16 of the node cluster 14 may manage synchronization. In one embodiment, each node 16 periodically provides state feedback to the control server 12 through a synchronization mechanism used to coordinate node operations. Thus, nodes 16 that do not report within the specified time are considered crashed and are restarted by the configurator 22. Further, the configurator 22 may provide a status to the user via the displays 578 and 580 of FIG. 30 in order to indicate the progress of the job.

  When the job is complete, the data aggregator 84 (FIG. 3) operates to collect data from each node 16. Specifically, data (for example, job output, performance statistics, application log, etc., refer to module 214) collected by the monitoring tool of each node 16 is accessed by the control server 12 (for example, the memory 90 in FIG. 3). In one embodiment, data aggregator 84 retrieves data from each node 16. In other embodiments, each node 16 forwards data to the data aggregator 84. In the illustrated embodiment, data is communicated from each node 16 to the control server 12 in the form of a log file 98, as shown in FIG. 31 (see also FIG. 3). Each log file 98 includes data collected by one or more of the various monitoring tools at each node 16. As described herein, the data aggregator 84 manipulates and analyzes the collected data from the log file 98 and displays the aggregated data to the user in the form of a graph, histogram, chart, etc. (eg, FIG. 1). (Via display 21). Further, the data aggregator 84 aggregates data from monitoring tools provided on the control server 12, such as the ganglia monitoring tool illustrated in FIG.

  Referring back to FIG. 30, the data aggregator 84 collects and aggregates performance data from each node 16 and logs, statistics, graphs and other representations of data based on user selection of the corresponding inputs 582-594 of the module 216. Works to generate Data aggregator 84 collects statistical raw data provided in log file 98 and statistical raw data provided by other monitoring tools based on user selection of input 586. Data aggregator 84 downloads all log files 98 from node 16 to the local file system based on user selection of input 588, which may be further analyzed there or for historical trend analysis. May be remembered. Data aggregator 84 retrieves only log files associated with the system tap monitoring tool based on the user selection of input 590. Data aggregator 84 displays one or more of log files 98 provided by node 16 on user interface 200 based on a user selection of input 582. The data aggregator 84 displays statistical data on the user interface 200 in the form of graphs and charts based on the user selection of the input 584. The statistical data includes, for example, performance data related to the performance of the network 18, the performance of network communication by the node 16, the performance of various hardware components of the node 16, the workload execution, and the overall performance of the node cluster 14. . The data aggregator 84 generates one or more graphs for display on the user interface 200 based on the user selection of the input 592 and showing various data collected from the node 16 and other monitoring tools.

  In one embodiment, the data aggregator 84 selects the data to display based on the data selected for monitoring with the monitoring tool configured in the monitoring module 214. In other embodiments, the data aggregator 84 selects data to be aggregated and displayed based on user input to the control and status module 216. For example, the user selects which of the log file 98, statistical data, and graph to display by selecting the inputs 582, 584, 592, respectively. In one embodiment, the data aggregator 84 selects which data to display in a graph and how to display the data (eg, line graph, bar graph, histogram) based on user input to the user interface 200. Etc.). Examples of graphical data displayed based on the selection of input 592 include processor speed vs. network delay addition, workload execution speed vs. number of processor cores, workload execution speed vs. number of processing threads per core, transmitted by a particular node 16 or Examples include time variation of the number of received data packets, time variation of the number of data packets of a predetermined size communicated, time consumed by data packets in the network stack, and the like.

(Configure the boot time parameter of the node of the cloud computing system)
FIG. 36 shows a flow diagram 620 of exemplary operations performed by the configurator 22 of FIGS. 1 and 3 to configure the boot time configuration of the cloud computing system 10. Reference is made to FIGS. 1 and 3 for the entire description of FIG. In the illustrated embodiment, the configurator 22 configures the node cluster 14 of FIG. 1 according to the flow diagram 620 of FIG. 36 based on a plurality of user selections received via the user interface 200. At block 622, the configurator 22 provides the user interface 200 with selectable boot time configuration data. Exemplary selectable boot time configuration data includes selectable inputs 269, 271 and fields 268, 270, 272, 274, 276 of the display screen of FIG. At block 624, the node configurator 72 of the configurator 22 boots for at least one node 16 of the cluster 14 of multiple nodes of the cloud computing system 10 based on at least one user selection of selectable boot time configuration data. Select a time configuration.

  At block 626, the configurator 22 configures at least one node 16 of the multi-node cluster 14 with the selected boot time configuration and modifies at least one boot time parameter of the at least one node 16. For example, the at least one boot time parameter may be the number of processing cores of the at least one node 16 that are enabled during workload execution (based on input to field 268) and / or the at least one Contains the amount of system memory (based on inputs to fields 270, 272) accessible by the operating system 44 (FIG. 2) of the node 16. Further, the modified boot time parameter may be a subset of the plurality of instructions of the workload to be executed by the at least one node 16 based on the number of instructions entered into field 274 and the selection of the corresponding custom input 271. May be identified. Thus, the workload is executed in a multi-node cluster 14 based on the modification of the at least one boot time parameter of the at least one node 16. In one embodiment, the configurator 22 initiates the workload execution and the multi-node cluster 14 is under reduced computing power and / or reduced memory capacity based on the modification of the at least one boot time parameter. Run the workload on Specifically, the modification of the number of processing cores associated with the selection of field 268 and corresponding input 271 can help reduce computing power, and the amount of system memory associated with selection of fields 270 and 272 and corresponding input 271 can be reduced. The modification helps reduce the memory capacity.

  In one embodiment, the node configurator 72 includes a first boot time configuration for the first node 16 of the multi-node cluster 14 based on at least one user selection of selectable boot time configuration data; A second boot time configuration for the second node 16 of the cluster of nodes 14 is selected. In this embodiment, the first boot time configuration includes a first modification of at least one boot time parameter of the first node 16, and the second boot time configuration is at least of the second node 16. It includes a second modification of one boot time parameter, the first modification being different from the second modification. In one example, the first boot time configuration includes enabling two processing cores of the first node 16 and the second boot time configuration includes three processing cores of the second node 16. Including enabling. Other suitable modifications of each node 16 boot time parameter may be provided as described above.

  FIG. 37 shows a flow diagram 630 of exemplary operations performed by one node 16 of the multi-node cluster 14 of FIG. 1 to configure the boot time configuration of the node 16. Reference is made to FIGS. 1 and 3 for the entire description of FIG. At block 632, one node 16 of the multi-node cluster 14 modifies at least one boot time parameter of that node 16 based on the boot time configuration adjustment request provided by the cloud configuration server 12. In the illustrated embodiment, the boot time configuration adjustment request is provided in the configuration file 28 (FIG. 3) and, as described herein, inputs 270, 271 and fields 268, 270, 272 of FIG. Based on the user selection made via 274,276, the requested modifications to one or more boot time parameters of node 16 are identified. In the illustrated embodiment, the node 16 includes an initial boot time configuration prior to modifying the at least one boot time parameter and a modified boot time configuration subsequent to modifying the at least one boot time parameter. And having. The modified boot time configuration provides at least one of reduced computing capacity and reduced memory capacity of the node 16, as described herein.

  At block 634, when the node 16 determines that the at least one boot time parameter has already been modified according to the boot time configuration adjustment request following the reboot of the node 16, the node 16 Following the reboot of node 16, at least a portion of the workload is executed. In one embodiment, the node 16 obtains the at least part of the workload from the cloud configuration server 12 and executes the workload based on the modification to the at least one boot time parameter. In one embodiment, the determination by the node 16 is based on a flag (eg, 1 bit or 2 bits or more) set after modification to the at least one boot time parameter and prior to the node 16 reboot. Since the set flag indicates to the node 16 following a restart of the node 16 that the at least one boot time parameter has already been modified, the node 16 modifies the at least one boot time parameter. Do not try to reboot again. In one embodiment, the determination is based on a comparison of the boot time configuration of node 16 with the requested boot time configuration identified in the boot time configuration adjustment request. For example, node 16 compares the current boot time parameter of node 16 with the requested boot time parameter identified in the boot time configuration adjustment request, and if these parameters are the same, the at least one boot time parameter. Do not attempt to modify parameters and reboot again. In one embodiment, when node 16 receives a new configuration file that includes a new boot time configuration adjustment request, node 16 may implement the modification of the boot time parameter in accordance with the new boot time configuration adjustment request. , Clear the flag.

  FIG. 38 shows a flow diagram 650 of exemplary detailed operations performed by the cloud computing system 10 to configure the boot time configuration of one or more nodes 16 of the node cluster 14. 1 and 3 are referred to throughout the description of FIG. In the illustrated embodiment, the configurator 22 performs blocks 652-656 of FIG. 38, and each configured node 16 performs blocks 658-664 of FIG. At block 652, the configurator 22 may configure one or more boot times for the corresponding node 16 based on user-defined boot time parameters entered via the user interface 200 (FIG. 10), as described herein. A configuration file 28 is created. In one embodiment, boot time configuration file 28 is a patch of one or more configuration files of node 16 or in the form of a task specific file / data format. At block 654, the configurator 22 activates the multi-node cluster 14 (eg, if there was a user selection of input 560 or inputs 562, 564 of FIG. 30 as described herein). At block 656, the configurator 22 distributes one or more boot time configuration files to the appropriate nodes 16 of the multi-node cluster 14. In one embodiment, each node 16 receives a boot time configuration file, and each file may identify a unique boot time parameter for the respective node 16. In one embodiment, the configuration file 28 is sent via a secure shell (SSH) file transfer, via an fpt client, via a user data string in Amazon AWS, or other suitable file transfer. It is transferred to the node via the mechanism. In other embodiments, the node 16 queries the control server 12 or the master node 16 for boot time configuration information, respectively (eg, via an HTTP request). At block 658, the node 16 applies the desired boot time parameter changes specified in the received boot time configuration file 28. In one example, the node 16 applies a patch to the boot file of the node 16 or the node 16 uses a utility to configure the node 16 based on the boot time parameter specified in the received boot time configuration file 28. Create a new set of boot files for In one embodiment, during or when applying the desired boot time change at block 658, the node 16 sets a status flag indicating that the boot time configuration has already been updated, as described herein. To do. In block 660, the node 16 forces a reboot following application of the boot time configuration change. Upon reboot, node 16 determines at block 662 that the boot time configuration of node 16 has already been updated with the boot time parameter changes specified in the received boot time configuration file 28. In one embodiment, node 16 may be based on the status flag set in block 658, as described herein, or based on a comparison of node 16's current boot time configuration with boot time configuration file 28. At block 662, it is determined that the boot time configuration has been updated. Thus, the node 16 reduces the possibility of applying boot time configuration changes many times. In block 664, the node 16 initiates execution of other tasks, including execution of a portion of the workload or workload received from the control server 12.

(Modify and / or emulate network configuration)
FIG. 39 illustrates a flow diagram 700 of exemplary operations performed by the configurator 22 of FIGS. 1 and 3 to modify the network configuration of a multi-node cluster 14 allocated in the cloud computing system 10. . Reference is made to FIGS. 1 and 3 and FIGS. 11 to 17 for the entire description of FIG. In block 702, the network configurator 74 modifies the network configuration of at least one node 16 of the multi-node cluster 14 of the cloud computing system 10 based on the user selection received via the user interface 200. Modifying the network configuration of the at least one node 16 at block 702 includes modifying the network performance of the at least one node 16 on the communication network 18 (FIG. 1). Network performance is modified by modifying network parameters such as packet rate, dropped or corrupted packets, reordered packets, etc. as described herein. In the illustrated embodiment, the network configurator 74 is based on a user selection or user input provided via the module 280 of the user interface 200, as described herein with respect to FIGS. 3) and modify the network configuration of node 16 by providing network configuration file 28 to node 16 (or by node 16 fetching file 28). Node 16 then implements the changes to the network configuration of node 16 specified in the accessed network configuration file 28. In the illustrated embodiment, the at least one node 16 has an initial network configuration before modification and a modified network configuration after modification. In one embodiment, the modified network configuration reduces the network performance of the at least one node 16 on the communication network 18 during execution of the selected workload. Alternatively, the modified network configuration enhances the network performance of the at least one node 16, such as by reducing the communication delay value specified via field 302 of FIG.

  In one embodiment, the network configurator 74 modifies at least one network parameter of the at least one node 16 to limit the network performance of the at least one node 16 on the communication network 18 during workload execution. To modify the network configuration of the at least one node 16. In one embodiment, the at least one network parameter to be modified comprises at least one of packet communication delay, packet loss rate, packet duplication rate, packet corruption rate, packet reordering rate, and packet communication rate, and Can be selected by the user via tabs 282-294 as described herein. Accordingly, the network configurator 74 generates node 16 access to the configuration file 28 that identifies modifications to network parameters (eg, increased communication delay between nodes 16, increased packet loss or packet corruption rate, etc.). By providing, the network performance of the at least one node 16 is limited.

  In the illustrated embodiment, the configurator 22 provides a user interface 200 comprising selectable network configuration data, and the network configurator 74, as described herein, provides at least one user selection of selectable network configuration data. To modify the network configuration of the at least one node 16. Examples of selectable network configuration data include inputs 298-301 and corresponding fields 302-312 in FIG. 11, inputs 313, 314 and corresponding fields 315, 316 in FIG. 12, inputs 317, 318 in FIG. 14, the input 321 and the corresponding field 322 in FIG. 14, the inputs 323 and 324 and the corresponding fields 325 and 326 in FIG. 15, the inputs 327 to 330, 335 to 338 in FIG. 16 and the corresponding fields 331 to 331. 334, as well as input 340 and corresponding field 342 of FIG. In one embodiment, the network configurator 74 changes the first network parameter of the first node 16 of the multi-node cluster 14 (ie, the network configuration) based on at least one user selection of selectable network configuration data. By limiting the network performance of the first node 16 on the communication network 18 during the execution of the workload (via the application file 28) and the second node 16 second of the multi-node cluster 14 The network performance is modified by changing the network parameters to limit the network performance of the second node 16 on the communication network 18 when executing the workload. In one embodiment, the first network parameter is different from the second network parameter. Accordingly, the network configurator 74 operates to modify different network parameters of different nodes 16 of the multi-node cluster 14 to achieve the desired network characteristics of the multi-node cluster 14 during workload execution.

  In the illustrated embodiment, as described herein with respect to FIGS. 40-42, the configurator 22 further has a network configuration that substantially matches the network configuration of the emulated node cluster. Operate to select a multi-node cluster 14 for 10. As referred to herein, an emulated node cluster is meant to include any group of network nodes having a known network configuration that will be emulated by the node cluster 14 selected by the control server 12. . Each node of the emulated node cluster includes one or more processing devices and memory accessible by the processing devices. In one embodiment, the emulated node cluster does not include available nodes 16 that can be selected by the configurator 22. For example, an emulated node cluster includes nodes that are remote from available nodes 16 housed in one or more data centers and accessible by the configurator 22, such as nodes provided by a user. Alternatively, the emulated node cluster may include a group of available nodes 16. The network topology and network performance characteristics of the emulated node cluster can be obtained using one or more network performance tests, as described below. Referring to FIG. 40, exemplary operations performed by the configurator 22 of FIGS. 1 and 3 to select a multi-node cluster 14 having network characteristics that substantially match the network characteristics of the emulated node cluster. A flow diagram 710 of FIG. Reference is made to FIGS. 1 and 3 for the entire description of FIG. In the illustrated embodiment, the configurator 22 selects and configures the node cluster 14 of FIG. 1 according to the flow diagram 710 of FIG. 40 based on a user selection received via the user interface 200 as described herein. . In block 712, the node configurator 72 compares the emulated node cluster communication network configuration with the actual communication network configuration of the plurality of available nodes 16. At block 714, the node configurator 72 selects a multi-node cluster 14 for the cloud computing system 10 from the plurality of available nodes 16 coupled to the communication network 18 based on the comparison at block 712. The selected multi-node cluster 14 includes a subset of the plurality of available nodes 16. At block 716, the node configurator 72 operates to operate each node 16 of the multi-node cluster 14 to share the workload processing with the other nodes 16 of the multi-node cluster 14 as described herein. In order to perform the load, the selected cluster 14 of multiple nodes is configured. In one embodiment, as described herein, blocks 712-716 begin when there is a cloud configuration deployment based on user input to module 216 of FIG.

  In the illustrated embodiment, the communication network configuration of the emulated node cluster and the actual communication network configuration of the plurality of available nodes 16 each include communication network characteristics associated with the corresponding node. The node configurator 72 selects the multi-node cluster 14 based on the similarity between the communication network characteristics of the emulated node cluster and the communication network characteristics of the plurality of available nodes 16. Exemplary communication network characteristics include network topology and network parameters. Exemplary network parameters include communication speed and latency between nodes, network bandwidth between nodes, and packet error rate. The network topology is the physical and logical connectivity of the nodes, the identification of which nodes and groups of nodes in a node cluster are physically close or separated from each other, the type of connection between the nodes (Fiber optic links, satellite connections, etc.), as well as other suitable characteristics. The packet error rate includes dropped or lost packets, corrupted packets, rearranged packets, duplicate packets, etc. In one embodiment, the node configurator 72 prioritizes the communication network characteristics of the emulated node cluster and selects the multi-node cluster 14 based on the prioritized communication network characteristics, as described herein with respect to FIG. .

  In the illustrated embodiment, the node configurator 72 initiates a network performance test on the available node 16 to identify the actual communication network configuration of the available node 16. Any suitable network performance test may be used. For example, the node configurator 72 may perform computer network management (administration), such as Packet Internet Groper (“Ping”), to test and collect data on network performance between available nodes 16. ) A request may be sent to each available node 16 to execute the utility. Based on the results of the ping test provided by each node 16, the node configurator 72 determines the actual communication network configuration of the available nodes 16. In one embodiment, ping is used in conjunction with other network performance tests to obtain the actual communication network configuration. The configurator 22 aggregates the network performance test results received from the node 16 to identify a network descriptor data file or object (eg, the data file 750 of FIG. 42) that identifies the actual communication network configuration of the available node 16. Create In one embodiment, configurator 22 initiates network performance tests and aggregates results based on user input to user interface 200. For example, a user selection of button 586 in FIG. 30 or other suitable input may cause configurator 22 to initiate a test and aggregate the results.

  In the illustrated embodiment, the node configurator 72 also accesses one or more data files (eg, the data file 750 of FIG. 42) that identify the communication network configuration of the emulated node cluster. In one embodiment, the one or more data files are obtained off-line of the control server 12 by implementing one or more network performance tests (eg, ping tests, etc.) on the emulated multi-node cluster. . In one embodiment, configurator 22 loads a data file associated with the emulated node cluster into accessible memory (eg, memory 90 of FIG. 3). For example, configurator 22 may load a data file based on the user identifying the location of the data file via user interface 200, such as via input to table 226 of FIG. Accordingly, configurator 22 compares the communication network characteristics identified in the data file generated in connection with available node 16 with the data file accessed in connection with the emulated node cluster. A comparison is made at block 712 of FIG.

  An exemplary data file 750 is shown in FIG. Data file 750 identifies the network configuration of any suitable network node, such as available node 16 accessible by control server 12 or a node of an emulated node cluster. As shown, the data file 750 illustratively identifies several groups of nodes including groups A, B,. Each group A, B, M includes a plurality of nodes that are physically close to each other, such as nodes on the same physical rack of the data center. Rows 6-11 identify network parameters related to network communication by Group A nodes, Rows 15-22 identify network parameters related to network communication by Group B nodes, and Rows 27-34 include Group M's. Identify network parameters related to network communication by the node. For example, rows 6 and 7 identify the latency, bandwidth, and error rate associated with communication between nodes in group A. Rows 8 and 9 identify latencies, bandwidths, and error rates associated with communication between group A and group B nodes. Similarly, rows 10 and 11 identify latencies, bandwidths, and error rates associated with communication between group A and group M nodes. Network parameters related to communications by Group B and Group M nodes are also identified in data file 750. Data file 750 may identify additional network configuration data, such as network topology data and other network parameters, as described herein.

  Referring to FIG. 41, one or more including the configurator 22 of FIGS. 1 and 3 to select a multi-node cluster 14 having network characteristics that substantially match the network characteristics of the emulated node cluster. Illustrated is a flow diagram 720 of exemplary detailed operations performed by a computing device. Reference is made to FIGS. 1 and 3 for the entire description of FIG. At block 722, network configuration is requested from each node of the emulated node cluster. For example, as described herein, a network performance test is initiated at each node and the test results are received by the computing device. At block 724, a network configuration data file (eg, data file 750) is created based on the network configuration data received from the emulated node cluster nodes as a result of the performance test. As described herein, blocks 722 and 724 may be performed offline by a computing system remote from cloud computing system 10, such as by computer 20 of FIG.

  At block 726, the configurator 22 requests a network configuration from each available node 16 or from a group of available nodes 16 in the data center. For example, configurator 22 initiates a network performance test on available node 16, as described herein, and configurator 22 aggregates configuration data resulting from the network performance test. In block 728, the configurator 22 creates a network configuration data file (eg, data file 750) based on the network configuration data received from the available node 16. Thus, the configurator 22 has access to two configuration data files including a data file describing the emulated node cluster and a data file describing the available nodes 16. The configurator 22 makes available an appropriate node 16 having network characteristics similar to the emulated node cluster based on a comparison of the network properties identified in the two data files, as shown in block 730. Select from. In one embodiment, the configurator 22 is configured in block 730 as appropriate based on a comparison of the node hardware characteristics (eg, processing power, memory capacity, etc.) of the emulated node cluster and the available node 16 as described herein. Further nodes are selected.

  At block 732, the configurator 22 tunes the selected node 16 based on the desired network configuration parameters identified in the data file associated with the emulated node cluster. For example, the network characteristics of the selected node 16 may not exactly match the network characteristics of the emulated node cluster, and further network tuning may be required or desired. Accordingly, the operating system 44, network topology driver 48 and / or other network components and network parameters of each node 16 are tuned to further achieve the desired network performance of the emulated node cluster. In one embodiment, the configurator 22 automatically tunes the selected node 16 based on the network characteristics identified in the data file. In one embodiment, network parameters are further tuned based on user input provided via module 206 of user interface 200, eg, as described herein with respect to FIGS.

In one exemplary embodiment, the configurator 22 selects the appropriate node 16 using the following “best matching” technique at block 730, although other suitable methods or algorithms may be provided. Good. The configurator 22 considers Z network properties (ie, characteristics) when comparing network configuration data (eg, latency −p ₀ , bandwidth −p ₁ , error rate −p _Z ) of the data file. Nodes X ₁ , X ₂ ,..., X _Q are nodes of the emulated node cluster. Configurator 22, the network property _{p 1,} p 2, ..., node _{X 1,} X 2 with respect to _{p X,} ..., a subset of the available nodes 16 that are most similar to _{X Q} (eg, node _Y 1, _{Y 2,} ... , Y _Q ). Although other algorithms may be used to make this selection, an exemplary algorithm implemented by configurator 22 to prioritize network properties so that a suitable subset of available nodes 16 can be found. including. In the exemplary prioritization, property p ₀ has a higher priority than property p ₁ and property p _k has a higher priority than property p _{k + 1} . Accordingly, in the illustrated example, latency is given higher priority than bandwidth when selecting nodes, and bandwidth is given higher priority than error rate when selecting nodes. In order to return the value of the network property N between the network nodes X and Y, a function P (N, X, Y) with the inputs N (network property), X (node) and Y (node) as parameters is May be a figure. Such a function may be implemented using the network description data file / object (eg, data file 750) created at blocks 724 and 728. The initial list of nodes L = {Y ₁ , Y ₂ , Y ₃ ,...} Includes all available nodes 16. When 1 ≦ g ≦ R (R is the total number of nodes in L, R ≧ Q), the following equation (1) is applied to each node Y _g .
Sx (g) = Σ _{1 ≦ N ≦ Z, 1 ≦ h ≦ R, g ≠ h} P (N, Y _g , Y _h ) (1)

When 1 ≦ i ≦ Q (Q is the number of nodes in the emulated node cluster), the following equation (2) is applied to each node X _i in the emulated node cluster: .
Sy (i) = Σ _{1 ≦ N ≦ Z, 1 ≦ j ≦ R, i ≠ j} P (N, Y _i , Y _j ) (2)

_{Algorithm, Sy (w) -Sx (i} ) = min v, such that f (Sy (v) -Sx ( f)), start looking for available nodes _{Y W} for cloud computing system 10. Therefore, node Y _W is used to simulate original node X _i and node Y _W is removed from list L. The algorithm continues until a full set of available nodes 16 is selected. Other suitable methods and algorithms for selecting the node 16 at block 730 may be provided.

In one exemplary embodiment, the configurator 22 tunes the selected node 16 at block 732 using the following method, although other methods or algorithms may be provided. In this method, the configurator executes a configuration application that automatically creates an appropriate network simulation layer on each node 16. The following algorithm is implemented by the configurator 22 when using a Netem network delay and loss emulator. For each node of the emulated node cluster, G _s is the node group to which that emulated node belongs (ie each node group comprises nodes that are physically close to each other, eg in the same rack) ). Following the configurator 22 for each group G _i is performed, wherein a 1 ≦ i ≦ E, E is the total number of groups defined in the data file associated with the emulated node cluster. The configurator 22 checks the desired network properties p ₀ ,..., P _N for the traffic leaving the node G _s to the node G _i . The configurator 22 creates a new class of service using, for example, the command “tc class add dev”. The configurator 22 creates a new queuing discipline using, for example, the command “tc qdisc add dev”. The configurator 22 sets the desired network properties for that class or its queuing discipline “qdisc”. Bandwidth and burst network properties are specified in the class, and other properties (latency, error rate, etc.) are specified in the queuing discipline. For each node _{Y n,} Gy _n is the group to which the node _{Y n} belongs. Configurator 22, a filter configurable based on the destination (destination) IP address (address of the node _{Y n),} and assign it to the class Gy _n. This can be done, for example, using the command “tc filter add dev”.

  As a result, when the Net Emulator is launched, the selected node cluster will have network performance equivalent to the emulated node cluster, at least with respect to the following network properties: Minimum latency, maximum bandwidth, maximum burst rate, minimum packet corruption rate, minimum packet loss rate, and minimum packet rearrangement rate. Other suitable methods and algorithms for tuning node 16 at block 732 may be provided.

  In one embodiment, blocks 726-732 of FIG. 41 are repeated with different groups of available nodes 16 until all clusters 14 of nodes corresponding to the emulated node cluster are selected. In one embodiment, the emulated node cluster is theoretical in that a physical node 16 may or may not exist, but the desired network configuration is known and it is Provided as input to configurator 22 for making node selections. In one embodiment, once a multi-node cluster 14 is selected based on the emulated node cluster, the configurator 22 may have multiple nodes with the desired network configuration, such as with a batch processor 80 described herein. Operate to test various workloads on a selected cluster 14 consisting of:

(Allocate multi-node clusters based on hardware characteristics)
FIG. 43 shows a flow diagram 760 of exemplary operations performed by the configurator 22 of FIGS. 1 and 3 to allocate a multi-node cluster 14 to the cloud computing system 10. Reference is made to FIGS. 1-3 for the entire description of FIG. At block 762, the configurator 22 (eg, data monitor configurator 82) initiates a hardware performance assessment test for the group of available nodes 16 in one or more data centers to determine the actual hardware of the group of available nodes 16. Get performance characteristics. At block 764, the node configurator 72 compares the actual hardware performance characteristics of the group of available nodes 16 with the desired hardware performance characteristics identified based on the user selection through the user interface 200. At block 766, the node configurator 72 selects a subset of nodes 16 for the cloud computing system 10 from the group of available nodes 16 based on the comparison at block 764. A subset of nodes 16, such as node cluster 14 or a group of nodes 16 of node cluster 14, operates to share the processing of the workload, as described herein. The number of nodes 16 in the subset of nodes 16 is equal to or less than the number of nodes 16 requested by the user for the node cluster 14, as described herein.

  In one embodiment, the node configurator 72 receives via the user interface 200 a user request for a cluster of multiple nodes for the cloud computing system 10 that has the desired hardware performance characteristics. The user request identifies desired hardware performance characteristics based on selection of selectable hardware configuration data such as, for example, selection box 259, input 262 and field 256 of FIG. 8, and selectable input 265 of FIG. In one embodiment, the fields of table 264 of FIG. 9 are selectable / modifiable to further identify the desired hardware performance characteristics. Node configurator 72 may identify desired hardware performance characteristics based on other suitable selectable inputs and fields of user interface 200. The node configurator 72 is based on the user requirements of the multi-node cluster and the desired hardware performance characteristics identified in the request (eg, hardware similarity between the available node 16 and the requested multi-node cluster). A group of available nodes 16 for testing in the hardware performance assessment test. In the illustrated embodiment, the number of nodes 16 in the group of available nodes 16 is greater than the number of nodes 16 in the multi-node cluster requested in the user request.

  Exemplary hardware performance characteristics include whether node 16 has a 64-bit processor architecture or a 32-bit processor architecture to support workloads that require native 32-bit and / or 64-bit operations. Including the computer architecture of the node 16. Other exemplary hardware performance characteristics include the manufacturer of one or more processors 40 of node 16 (AMD, Intel, Nvidia, etc.), one or more processors of node 16 40 operating frequencies and node 16 read / write performance. Still other exemplary hardware performance characteristics are: system memory capacity and disk space (storage capacity), number and size of processors 40 in node 16, cache size of node 16, available instruction set of node 16, node 16 Disk I / O performance and hard drive speed, ability of node 16 to support emulating software, chipset, type of memory of node 16, network communication latency / bandwidth between nodes 16, and other suitable hardware Includes performance characteristics. In the illustrated embodiment, each of these hardware performance characteristics may be specified as desired by the user based on a user request provided via the user interface 200. In addition, one or more hardware performance assessment tests operate to determine these actual hardware performance characteristics of each selected available node 16.

  In one embodiment, the node configurator 72 identifies, at block 762, one or more hardware that operates to identify or determine the hardware performance characteristics of the node 16 and to generate hardware configuration data representing these characteristics. A hardware performance assessment test is started by deploying a hardware performance assessment tool to each node 16. The data aggregator 84 then aggregates the hardware performance data provided by the hardware performance assessment tool so that the node configurator 72 can determine the actual hardware performance characteristics of each node 16 based on the aggregated data. To work. The exemplary assessment tool identifies one or more processor types of node 16 and various characteristics / features of the processor (eg, manufacturer, processor speed and capacity, available memory and disk space, etc.). CPU identification tools ("CPUID") that include executable operational code for such tools are known in the art. Other exemplary monitoring tools, when executed by node 16, may include instruction set extensions or instruction types to determine an instruction set that is compatible with node 16 and / or compatible with the manufacturer of one or more processors. Includes software code modules that operate to test. Another exemplary monitoring tool is a software code module that, when executed by node 16, operates to test whether node 16 has a 64-bit architecture or a 32-bit architecture. including. For example, such a test involves issuing a command or processing request and measuring how long it takes the processor to complete the request. Other suitable assessment tools may be provided.

  In one embodiment, the number of nodes 16 in the subset of nodes 16 selected at block 766 is less than the number of nodes 16 identified in the user request. Accordingly, configurator 22 repeats steps 762-766 until the number of selected nodes 16 is equal to the number of nodes 16 requested in the user request to obtain an additional subset of nodes 16. In one embodiment, after selecting the first subset of nodes 16 at block 766, the node configurator 72 may select a different available node 16 than the first group of available nodes 16 initially tested at block 762. Select the second group. The data monitor configurator 82 initiates a hardware performance assessment test for the second group of available nodes 16 to obtain the actual hardware performance characteristics of the second group of available nodes 16, and the node configurator 72 Based on the comparison by the node configurator 72 of the actual and desired hardware performance characteristics of the second group of available nodes to the cloud computing system 10 from the second group of available nodes 16 Select the second subset of nodes 16. In one embodiment, when the total number of nodes in the selected subsets of node 16 equals the number of nodes 16 requested in the user request, node configurator 72 selects the selected subsets of nodes 16. It is configured as a cluster 14 of multiple nodes of the cloud computing system 10 (ie, the node cluster 14 is configured with user-specified configuration parameters and a workload is executed on the node cluster 14).

  Referring to FIG. 44, one including the configurator 22 of FIGS. 1 and 3 to select a multi-node cluster 14 having hardware characteristics substantially matching the desired hardware performance characteristics specified by the user. An exemplary detailed operational flow diagram 770 performed by the computing device above is shown. Reference is made to FIGS. 1-3 for the entire description of FIG. At block 772, node configurator 72 receives a user request for N nodes 16 having the desired hardware performance characteristics, where N is any suitable number of desired nodes 16. In one embodiment, the user request is based on user selection of selectable hardware configuration data (eg, FIGS. 8 and 9) as described herein with respect to FIG. At block 774, the node configurator 72 requests or reserves N + M nodes 16 from the accessed one or more data center or cloud available nodes 16. M is any suitable number such that the number of reserved available nodes 16 (N + M) exceeds the number N of requested nodes 16. For example, M may be equal to N or may be equal to N times. Alternatively, node configurator 72 may request N available nodes 16 at block 774. In one embodiment, (N + M) nodes 16 are allocated or reserved using an application specific API (eg, Amazon AWS API, open stack API, custom API, etc.). Node configurator 72 requests available node 16 at block 774 (and block 788) based on available node 16 having hardware characteristics similar to the desired cluster of nodes. For example, node configurator 72 may reserve available nodes 16 of the same node type (eg, small, medium, large, x-large as described herein).

  At block 776, the data monitor configurator 82 initiates a hardware performance assessment test for each reserved node 16 by deploying one or more hardware performance assessment tools, as described herein with respect to FIG. The data aggregator 84 aggregates (eg, collects and stores) hardware performance data resulting from hardware performance assessment tests initiated at each node 16. In one embodiment, the hardware performance assessment tool is a software code module that is pre-installed on the node 16, or software code that is installed on the node 16 using SSH, HTTP, or some other suitable protocol / mechanism. It is a module.

  At block 780, the node configurator 72 compares the user requested desired hardware performance characteristic (block 772) with the actual hardware performance characteristic resulting from the hardware performance assessment test. Based on the similarity in actual and desired hardware performance characteristics, the node configurator 72 selects the X nodes 16 that best match the desired hardware characteristics from (N + M) reserved nodes 16 at block 782. Select, where X is any number less than or equal to the number N of requested nodes 16. Any suitable algorithm may be used to compare the hardware characteristics and select the best matching node 16, such as a “best matching” technique based on the hardware characteristics described herein with respect to FIG. In block 784, the node configurator 72 uses the remaining unselected available nodes 16 (eg, (N + M) -X) so that they are available for use in other cloud computing systems. Release to one or more data centers or clouds, for example using application specific APIs. If, at block 786, the number X of selected nodes 16 is less than the number N of requested nodes 16, the node configurator 72, at block 788, adds additional nodes 16 from one or more data centers / clouds. Request or make a reservation. The configurator 22 then repeats steps 776-786 until the total number of selected nodes 16 (ie, the total number of nodes 16 resulting from all iterations of the selection method) is equal to the requested number N of nodes 16. The selected nodes 16 are then configured as a multi-node cluster 14 for performing cloud computing tasks assigned by the user.

  In one embodiment, the method of FIG. 44 operates in conjunction with the method of FIG. 41 to select a multi-node cluster 14 having the desired hardware and network characteristics. In one embodiment, the method of FIG. 44 selects a node 16 further based on proximity in network characteristics. In one embodiment, the hardware characteristics identified in the user request at block 772 are prioritized prior to selecting the node 16 for the node cluster 14. In one embodiment, the method of FIG. 44 (and FIG. 43) uses the configurator to find an appropriate match between the actual selected multi-node cluster 14 and the desired multi-node cluster specified by the user. 22 is automatically executed. Alternatively, the configurator 22 may provide the user with an option to initiate the operations of FIGS. 43 and 44, for example based on selectable inputs of the user interface 200.

(Selecting and / or modifying the hardware configuration of the cloud computing system)
FIG. 45 illustrates a flow diagram 800 of exemplary operations performed by the configurator 22 of FIGS. 1 and 3 to select a hardware configuration for a multi-node cluster 14 of the cloud computing system 10. Reference is made to FIGS. 1 and 3 for the entire description of FIG. At block 802, the node configurator 72 is configured to execute at least one node 16 of the multi-node cluster 14 based on execution of the workload shared by the multi-node cluster 14 of the cloud computing system 10. In execution, it is determined that it has operated below the threshold operation capability. The threshold capability is illustratively based on hardware usage by the at least one node 16, for example, utilization of the processor 40 and / or memory 42 when executing a workload. The threshold operating capability may be any suitable threshold such as, for example, maximum operating capability (100%) or 90% operating capability. At block 804, the node configurator 72 is based on the determination at block 802 such that the multi-node cluster 14 with the modified hardware configuration has at least one of reduced computing capacity and reduced storage capacity. Select a modified hardware configuration for a multi-node cluster 14.

  In one embodiment, the node configurator 72 selects at least one different node 16 from the plurality of available nodes 16 of the data center and selects the at least one node 16 of the multi-node cluster 14 as the at least one different node 16. Select the modified hardware configuration by swapping with. The different node 16 has at least one of a reduced computing capacity and a reduced storage capacity compared to the node 16 that is the replacement target of the cluster 14 of the plurality of nodes. For example, the node configurator 72 has a slower processor 40, has fewer processing cores, has less memory capacity, or any other suitable A different node 16 with reduced hardware characteristics is selected from the available nodes 16. For example, the node 16 being replaced has a higher computing than is needed to process the workload, such that some of the hardware of the node 16 to be replaced is not utilized during workload execution. Has capacity or memory capacity. In the illustrated embodiment, the different node 16 has equivalent performance (eg, equivalent execution speed, etc.) as the one or more nodes 16 to be replaced, but the reduced computing power of the different node 16 and Selected to operate more efficiently to process workload due to storage capacity. Thus, a multi-node cluster 14 modified at that different node 16 is attributed to the reduced computing and / or storage capacity of that different node 16 with little or no overall performance loss. And run the workload more efficiently. For example, the node cluster 14 executes the workload with the different nodes 16 at a speed substantially the same as the case with the nodes 16 to be replaced.

  In one embodiment, the node configurator 72 selects one or more nodes 16 and removes them from the multi-node cluster 14 without exchanging the node 16 to be replaced with a different node 16. Select and implement the modified hardware configuration. For example, the node configurator 72 determines that one or more nodes 16 of the node cluster 14 are not required to execute a workload with similar execution performance for the remaining nodes 16 of the node cluster 14. Accordingly, the node configurator 72 removes the one or more nodes 16 from the node cluster 14 and releases the one or more nodes 16 to the data center. In one embodiment, node configurator 72 selects and implements the modified hardware configuration of block 804 by reducing at least one of computing power and / or memory capacity of one or more nodes 16 of node cluster 14. To do.

  In the illustrated embodiment, the configurator 22 provides access to hardware usage cost data that identifies hardware usage costs associated with using various hardware resources (eg, node 16) for the node cluster 14. Have. For example, cloud computing services (eg, Amazon, open stack, etc.) charge usage costs based on each selected 16 computing capacity and memory capacity of the node cluster 14. Thus, in one embodiment, the node configurator 72 uses usage cost data associated with using the at least one different node 16 in the multi-node cluster 14 and the at least one replacement object in the multi-node cluster 14. Based on the comparison by the node configurator 72 of the usage cost data associated with using the resulting node 16, the at least one different node 16 to be exchanged with one or more nodes 16 of the node cluster 14 is selected. In one embodiment, the node configurator 72 selects the at least one different node 16 on the condition that the usage cost of the at least one different node 16 is lower than the usage cost of the node 16 to be replaced. . For example, the node configurator 72 calculates the cost of hardware resources (eg, node 16) used in the multi-node cluster 14 and determines the cost benefits associated with possible hardware configuration changes in the multi-node cluster 14. To do. For example, the node configurator 72 selects one or more different nodes 16 that will result in a more efficient use of hardware resources allocated to the node cluster 14 with lower usage costs and minimal performance loss. . In one embodiment, configurator 22 configures a network configuration or other configuration based on a similar cost analysis.

  In the illustrated embodiment, the configurator 22 monitors the hardware usage of each node 16 by deploying one or more hardware usage monitoring tools to each node 16 of the multi-node cluster 14. By executing the hardware usage monitoring tool by each node 16, at least one processor 40 of each node 16 uses or uses computer hardware (eg, processor 40, memory 42, memory controller, etc.) in executing the workload. To monitor. The monitoring tool then provides the node 16 with hardware usage data accessible by the configurator 22 that relates to the hardware usage of each node 16 in executing the workload. The data aggregator 84 of the configurator 22 aggregates the hardware usage data provided by each node 16 so that the configurator 22 can determine the hardware usage of each node 16 based on the aggregated hardware usage data. Operate. An exemplary hardware monitoring tool is described herein with respect to the monitoring module 214 of FIGS. For example, the IOStat and VMStat tools may be used to indicate the percentage of time that the processor 40, virtual memory and / or memory controller are busy executing instructions or performing I / O operations during workload execution, It includes a code module that can be executed by the node processor 40 to monitor the percentage of time that these components are waiting / stopped, as well as other suitable usage parameters. Based on the determined hardware utilization of the node 16, the node configurator 72 may determine that it requires less memory or less computing power than that originally requested and allocated, Also, as described herein, the node 16 may be replaced or removed from the cluster 14.

  In one embodiment, node configurator 72 displays selectable hardware configuration data on user interface 200 that represents the modified hardware configuration selected at block 804. Based on a user selection of selectable hardware configuration data, the node configurator 72 modifies the hardware configuration of the multi-node cluster 14, eg, replaces or removes the node 16 of the node cluster 14. Exemplary selectable hardware configuration data is shown with selectable inputs 259 and 262 in table 258 of FIG. For example, the node configurator 72 recommends the recommended modified hardware configuration of the node cluster 14 by listing the recommended nodes 16 of the node cluster 14 that includes one or more different nodes 16 or excluded nodes 16. It may be displayed in table 258. The user selects the input 259 corresponding to the listed node 16 to approve the hardware change, and the node configurator 72 accepts the approved change at the start of the workload deployment, as described herein. Based on this, the modified node cluster 14 is configured. In one embodiment, the hardware usage cost is also displayed in the user interface 200 and one or more recommended hardware configurations of the node cluster 14 allow the user to select a configuration for implementation based on the associated usage cost. Making it possible. Other suitable interfaces may be provided to display the modified hardware configuration of the multi-node cluster 14. In one embodiment, the node configurator 72 automatically configures the cluster 14 of multiple nodes with the modified hardware configuration selected at block 804 without user input or confirmation, and the modified The execution of the workload is started in the node cluster 14.

  Referring to FIG. 46, an example performed by one or more computing devices including the configurator 22 of FIGS. 1 and 3 to select the hardware configuration of a multi-node cluster 14 of the cloud computing system 10. A detailed operational flow diagram 810 is shown. 1-3 are referred with respect to the whole description of FIG. At block 812, the configurator 22 includes selectable node data to allow user selection at block 814 of the desired multi-node cluster 14 with the desired hardware configuration, as described herein. A user interface 200 is provided. At block 816, the configurator 22 selects and configures the multi-node cluster 14 and deploys the workload to the multi-node cluster 14, as described herein. At block 818, the configurator 22 installs and / or configures a hardware usage monitoring tool on each node 16 of the node cluster 14. In one embodiment, the monitoring tool is selected by the user via the monitoring module 214 of FIGS. Alternatively, the configurator 22 may automatically deploy one or more monitoring tools such as the IOStat tool and the VMStat tool based on the start of the method of FIG. At block 820, the workload configurator 78 initiates execution of the workload on the multi-node cluster 14, and at block 822, the data aggregator 84 continues to or after each execution of each node 16. Collect and store hardware usage data provided by monitoring tools.

  When the workload execution by the node cluster 14 is complete, the node configurator 72 determines the hardware usage of each node 16 based on the hardware usage data, as represented by block 824. At block 826, the node configurator 72 determines whether the hardware usage of each node 16 has reached or exceeded the usage threshold (eg, 100% usage, 90% usage, or any other suitable usage threshold). In one embodiment, the node configurator 72 compares a plurality of usage measurements, such as processor usage, memory usage, memory controller usage, etc., to one or more usage thresholds at block 826. If yes at block 826, the node cluster 14 is determined to be suitable for further workload execution, ie no adjustments are made to the hardware configuration of the node cluster 14 by the configurator 22. For each node 16 that is below the utilization threshold at block 826, the node configurator 72 is a different node 16 for replacement that has hardware suitable for running the workload, as described herein with respect to FIG. A different node 16 for exchange having a computing capacity or storage capacity lower than that of the node 16 to be exchanged (i.e. having performance equivalent to that of the one or more nodes 16 to be exchanged). Are identified from the available nodes 16. At block 830, the node configurator 72 displays any recommendation identified in block 828 by displaying on the user interface 200 the recommended hardware configuration of the multi-node cluster 14, as described herein with respect to FIG. Provide feedback to users of hardware configuration changes. At block 832, the node configurator 72 removes the node 16 of the original node cluster 14 and / or replaces the node 16 with a different node 16 identified at block 828 for future execution of the workload. Apply recommended hardware configuration changes.

  In one embodiment, selection by the user at the selectable input of the user interface 200 allows the node configurator 72 to implement the hardware configuration method described in FIGS. 45 and 46 to execute the workload. Find the configuration of the node cluster 14. Alternatively, the configurator 22 automatically implements the methods of FIGS. 45 and 46, such as at the start of a batch processing job, to ensure that the appropriate performance of the multi-node cluster 14 does not significantly limit workload performance. Find alternative configurations.

(Tuning cloud computing system)
FIG. 47 illustrates an exemplary flow of operations performed by the configurator 22 of FIGS. 1 and 3 to select an appropriate configuration for a multi-node cluster 14 of the cloud computing system 10 from a plurality of available configurations. FIG. 850 is shown. Reference is made to FIGS. 1 and 3 for the entire description of FIG. At block 852, the configurator 22 (batch processor 80) initiates multiple executions of the workload on the multi-node cluster 14 based on the different sets of configuration parameters for the multi-node cluster 14. Configuration parameters provided by the configurator 22 as input to the node 16 (eg, via one or more configuration files 28 as described herein) may be used to provide that different set of configuration parameters. Adjustable by the configurator 22, the workload is executed by the multi-node cluster 14 with each different set of configuration parameters. In one embodiment, configurator 22 adjusts configuration parameters for each workload execution based on user input provided via user interface 200, as described herein. In one embodiment, these configuration parameters are at least one of at least one node 16 workload container operational parameter, at least one node 16 boot time parameter, and at least one node 16 hardware configuration parameter. Including one.

  At block 854, the node configurator 72 selects a set of configuration parameters for the multi-node cluster 14 from the plurality of different sets of configuration parameters. At block 856, the workload configurator 78 provides (deploys) the workload to the multi-node cluster 14 for execution by the multi-node cluster 14 configured with the selected set of configuration parameters. . Thus, future executions of the workload are performed by a multi-node cluster 14 having a configuration based on the selected set of configuration parameters.

  The selection of a set of configuration parameters at block 854 includes at least one performance characteristic of the multi-node cluster 14 monitored at each execution of the workload (eg, with a monitoring tool) and at least one of the multi-node cluster 14. Based on a comparison by the node configurator 72 with the desired performance characteristics. For example, in one embodiment, the node configurator 72 selects a set of configuration parameters that provide the best matching performance characteristics of the node cluster 14 to the desired performance characteristics specified by the user during workload execution. In the illustrated embodiment, the desired performance characteristics are identified by the node configurator 72 based on user input provided via the user interface 200. For example, the user interface 200 can fill a selectable input or fill that allows the user to select a desired performance characteristic of the multi-node cluster 14 when executing a selected workload. ) Includes selectable performance data such as fields. See, for example, fillable field 276 of FIG. 10 or any other suitable selectable input or field of user interface 200 configured to receive user input to identify a desired performance characteristic. . In other examples, the node configurator 72 identifies desired performance characteristics, for example, based on user selection of inputs 238, 228, 230, 232 of FIG. 7 and / or buttons 494 of the batch processing module 212 of FIG. A user-provided file containing data to be loaded may be loaded.

  Exemplary performance characteristics specified and monitored by the user during workload execution are: workload execution time, processor utilization by node 16, memory utilization by node 16, power consumption by node 16, hard disk input / output by node 16 (I / O) usage and network usage by the node 16 are included. Other suitable performance characteristics may be monitored and / or specified by the user, such as performance characteristics monitored with the monitoring tools described herein with respect to FIGS.

  In one embodiment, the selection of the set of configuration parameters at block 854 is such that a value associated with one or more performance characteristics monitored during execution of the workload is associated with one or more corresponding desired performance characteristics. Further, it is based on the determination by the node configurator 72 to be included in the allowable value range. For example, tolerance ranges associated with corresponding desired performance characteristics (eg, entered by the user or set by the node configurator 72) are 85% -100% for processor usage and 85% -100 for memory usage. % May be included. Accordingly, the node configurator 72 selects a set of configuration parameters that results in 95% processor utilization and 90% memory utilization, but a set of configuration parameters that results in 80% processor utilization and 75% memory utilization. Reject. If multiple sets of configuration parameters provide performance characteristics that satisfy the acceptable range of values, the node configurator 72 may determine the highest performance value, lowest usage cost, performance characteristic priority, or other suitable factor, etc. Select a set of configuration parameters based on additional factors. If there is no set of configuration parameters that result in acceptable performance characteristics, the node configurator 72 selects the set that yields the best match performance characteristics and automatically sets the configuration parameters until an appropriate set is found. Further adjustments and / or notification to the user that a set of acceptable configuration parameters was not found.

  In one embodiment, the node configurator 72 assigns a score value to each different set of configuration parameters based on the similarity of the monitored performance characteristic to the desired performance characteristic. Accordingly, the selection of the set of configuration parameters at block 854 is further based on the score value assigned to the selected set of configuration parameters. For example, the node configurator 72 selects the set of configuration parameters that yields the highest score value. The score value ranks a set of configuration parameters based on how well the performance characteristics of the node cluster 14 match the desired performance characteristics.

  In one embodiment, the selection of a set of configuration parameters at block 854 may include the use of cost data associated with using different available nodes 16 or using different network configurations in a multi-node cluster 14. Further based on comparison. For example, the node configurator 72 may select a set of configuration parameters that results in more processor usage and memory usage than the threshold usage level, and usage costs lower than the threshold cost level. Any other suitable consideration regarding cost of use may be applied to the selection at block 854.

  In one embodiment, configurator 22 initiates a first execution of a workload on node cluster 14 based on an initial set of configuration parameters provided by a user (eg, via user interface 200). In this embodiment, the node configurator 72 automatically adjusts at least one configuration parameter of the initial set and based on this modified initial set to find a set of configuration parameters that provide the desired performance characteristics. Cover different sets of configuration parameters by initiating additional executions of the workload. Any suitable design space search method or algorithm may be used to search for various sets of such configuration parameters.

  In one embodiment, the data monitor configurator 82 deploys one or more nodes and network performance monitoring tools (eg, as described in FIGS. 26-29) to each node 16 of the multi-node cluster 14. The monitoring tool, when executed by each node 16 (or by the control server 12), operates to monitor the performance characteristics of each node 16 at each execution of the workload, as described herein. The executed monitoring tool generates performance data representing the performance characteristics of the corresponding node 16 that can be accessed by the configurator 22. Data aggregator 84 aggregates the performance data provided by the performance monitoring tool of each node 16 and node configurator 72 selects a set of configuration parameters at block 854 based on the aggregated performance data.

  As described herein, the various sets of configuration parameters of the multi-node cluster 14 include at least one of workload container operational parameters, boot time parameters, and hardware configuration parameters. Exemplary operational parameters of the workload container are described herein with respect to FIGS. 4-6, 19 and 20, for example, at least one of read / write operations, file system operations, network socket operations and sorting operations. Contains relevant operating parameters. The operating parameters are modified by the workload container configurator 76 based on user selection of selectable data (eg, inputs and fields) shown in FIGS. 19 and 20 and described herein. Exemplary operational parameters associated with read / write operations include the memory buffer size for read / write operations and the size of the data block transferred during the read / write operations. Exemplary operational parameters related to file system operation include the number of file system records stored in the memory of each node 16 and the processing thread of each node 16 allocated to handle requests for the file system. At least one of the numbers. Exemplary operating parameters associated with the sorting operation include the number of data streams to merge when performing the sorting operation. Other suitable operating parameters for the workload container may be provided.

  Exemplary boot time parameters are described herein with respect to FIG. 10 and FIGS. 36-38, for example, the number of processing cores of node 16 enabled during workload execution and the operating system 44 of node 16 Contains the amount of system memory of the node 16 accessible by. The boot time parameter is selected and modified by the node configurator 72 based on a user selection of selectable data (eg, inputs and fields) shown in FIG. 10 and described herein. Other suitable boot time parameters may be provided. Exemplary hardware configuration parameters are described herein with respect to FIGS. 8, 9 and 43-46, for example, the number of processors 40 in node 16, the amount of system memory in node 16, and the node 16 Includes at least one of the amount of hard disk space. Hardware configuration parameters are selected and modified by the node configurator 72 based on user selection of selectable data (eg, inputs and fields) shown in FIGS. 8 and 9 and described herein. Other suitable hardware configuration parameters may be provided.

  Referring to FIG. 48, one or more including the configurator 22 of FIGS. 1 and 3 to select an appropriate configuration for the multi-node cluster 14 of the cloud computing system 10 from a plurality of available configurations. An exemplary detailed operational flow diagram 860 performed by a computing device is shown. 1-3 are referred with respect to the whole description of FIG. In the embodiment illustrated in FIG. 48, the configurator 22 stops searching for the appropriate set of configuration parameters when the actual performance of the node cluster 14 is greater than or equal to the desired performance. In other embodiments, the configurator 22 may identify the identified configuration parameters prior to selecting the set of configuration parameters that are the best match based on desired performance characteristics and / or other suitable factors (eg, cost of use). Try each set of.

  At block 862, the configurator 22 receives one or more sets of configuration parameters and desired performance characteristics related to workload execution based on user input received via the user interface 200, as described herein. . At block 864, the configurator 22 allocates the multi-node cluster 14 and configures the multi-node cluster 14 with the set of configuration parameters received at block 862. In one embodiment, configurator 22 deploys one or more network configuration files 28 that identify configuration parameters to node 16 at block 864, as described herein. The configurator 22 installs and / or configures one or more monitoring tools (eg, selected by the user via the module 214) on each node 16 at block 866, and works with the multi-node cluster 14 at block 868. Start the load execution. In the case of or during workload execution, the configurator 22 aggregates performance data generated by one or more monitoring tools at each node 16 at block 870. As described herein, at block 872, based on the aggregated performance data, configurator 22 determines the desired performance characteristics identified at block 862 to the actual performance of cluster 14 identified by the aggregated performance data. Compare with characteristics. At block 874, configurator 22 determines whether the performance characteristic is appropriate compared to the desired performance characteristic (eg, whether it is within an acceptable range, with an appropriate score value, as described herein). Whether or not). If yes at block 874, the configurator saves the current configuration parameters last implemented at block 864 for future execution of the workload. If the performance characteristics are not desired at block 874 and the various available sets of configuration parameters are not exhausted at block 876, the configurator 22 selects a different set of configuration parameters at block 878. Then, the functions of blocks 864 to 876 are repeated. For example, configurator 22 may implement a different set of configuration parameters identified at block 862, as described herein, or implement an incrementally adjusted set of parameters provided by configurator 22. It's okay. The process is repeated until the configurator 22 finds an appropriate set of configuration parameters at block 874 or until configuration parameter options are exhausted at block 876. If the configuration option is exhausted at block 876, the configurator 22 selects a set of configuration parameters at block 880 that provided the best performance characteristics and other identified characteristics (eg, cost of use).

  Among other benefits, the method and system may allow selection, configuration and deployment of multi-node clusters, workloads, workload containers and network configurations via a user interface. In addition, the method and system allows for control and adjustment of cloud configuration parameters, thereby allowing performance under changing characteristics of node hardware, networks, workload containers and / or workloads. Analysis, and automated system tuning based on performance analysis. Other benefits should be recognized by those skilled in the art.

  While this invention has been described as having a preferred design, the present invention can be further modified within the spirit and scope of this disclosure. This application is therefore intended to cover any variations, uses, or adaptations of the invention using its general principles. Further, this application is intended to be a departure from this disclosure, as contained in any practice known or customary in the art to which this disclosure belongs, and which is encompassed by the limitations of the appended claims. It is intended to cover deviations from.

Claims (42)

A method of configuring a computing system implemented by one or more computing devices comprising:
A set of configuration parameters for a multi-node cluster of the computing system from the different sets of configuration parameters, the multi-node cluster monitored upon prior execution of the workload by the multi-node cluster; Selecting based on a comparison by the one or more computing devices of at least one performance characteristic of and a at least one desired performance characteristic of the cluster of nodes.
Providing the workload to the cluster of nodes for shared execution by the cluster of nodes configured with the selected set of configuration parameters.   Prior execution of the workload comprises initiating multiple executions of the workload on the multi-node cluster based on the different sets of the configuration parameters of the multi-node cluster; The workload container comprises at least one of a workload container operational parameter, a boot time parameter of at least one node, and a hardware configuration parameter of at least one node, wherein the workload container is a cluster of the plurality of nodes. The method of claim 1 operative to coordinate the processing of the workload above.   The selecting is that the value associated with the at least one performance characteristic monitored during execution of the workload falls within a tolerance range associated with at least one corresponding desired performance characteristic. The method of claim 2 further based on a determination by one or more computing devices.   The selecting includes assigning a score value to each different set of configuration parameters based on a comparison of the at least one monitored performance characteristic and the at least one desired performance characteristic, and the selected 3. The method of claim 2, further comprising: selecting the set of configuration parameters from a plurality of different sets of configuration parameters based on the score value assigned to the set of configuration parameters.   3. The method of claim 2, wherein the selecting is further based on a comparison of usage cost data associated with using different available nodes in the multi-node cluster. At least one node performance monitoring tool operable to monitor the at least one performance characteristic of each node and provide performance data representative of the at least one performance characteristic upon each execution of the workload by the cluster of nodes Deploying to each node of the multi-node cluster;
3. The method of claim 2, further comprising aggregating the performance data provided by the at least one node performance monitoring tool for each node, wherein the selecting is based on the aggregated performance data.   The method of claim 2, further comprising providing the selected set of configuration parameters to the cluster of nodes.   The method of claim 2, further comprising providing a user interface comprising selectable configuration data, wherein the plurality of different sets of configuration parameters are based on a user selection of the selectable configuration data.   Further comprising providing a user interface comprising selectable configuration data, wherein an initial set of the plurality of different sets of configuration parameters is based on at least one user selection of the selectable configuration data. Other sets of the plurality of different sets are selected by the one or more computing devices based on an adjustment by the one or more computing devices of at least one configuration parameter of the initial set of configuration parameters. The method of claim 2.   The at least one performance characteristic and the at least one desired performance characteristic monitored during each execution of the workload are: workload execution time, processor utilization by at least one node, memory utilization by at least one node, at least one The method of claim 2, comprising at least one of power consumption by one node, hard disk input / output (I / O) utilization by at least one node, and network utilization by at least one node.   The hardware configuration parameter of the at least one node is at least one of the number of processors of the at least one node, the amount of system memory of the at least one node, and the amount of hard disk space of the at least one node. The method of claim 2 comprising one.   The boot time parameter of the at least one node includes the number of processing cores of the at least one node enabled upon execution of the workload and the at least one accessible by the operating system of the at least one node. The method of claim 2, comprising at least one of an amount of system memory of a node.   The method of claim 2, wherein the operational parameter of the workload container is associated with at least one of a read / write operation, a file system operation, a network socket operation, and a sorting operation.   The operation parameter related to the read / write operation includes at least one of a memory buffer size for the read / write operation and a size of a data block transferred in the read / write operation, and the file system operation The operational parameters associated with the at least one of: a number of file system records stored in the memory of each node; and a number of processing threads of each node allocated to process requests for the file system, 14. The method of claim 13, wherein the operational parameter associated with a sorting operation comprises a number of data streams to merge when performing the sorting operation. A computing configuration system comprising a node configurator and a workload configurator comprising:
The node configurator monitors a set of configuration parameters for a multi-node cluster of a computing system from a plurality of different sets of configuration parameters upon prior execution of a workload by the multi-node cluster. Operative to select based on a comparison by the node configurator of at least one performance characteristic of a multi-node cluster and at least one desired performance characteristic of the multi-node cluster;
Computing the workload configurator to provide the workload to the cluster of nodes for shared execution by the cluster of nodes configured with the selected set of configuration parameters; Configuration system.   Initiating prior execution of the workload by initiating multiple executions of the workload on the multiple node cluster based on the plurality of different sets of configuration parameters of the multiple node cluster. An operating batch processor, wherein the configuration parameters comprise at least one of workload container operating parameters, at least one node boot time parameter, and at least one node hardware configuration parameter; The system of claim 15, wherein the workload container operates to coordinate processing of the workload on the cluster of nodes.   The node configurator indicates that a value associated with the at least one performance characteristic monitored during execution of the workload is within a range of tolerances associated with at least one corresponding desired performance characteristic. The system of claim 16, wherein the system is operative to select the set of configuration parameters further based on a determination by.   The node configurator assigns a score value to each different set of configuration parameters based on a comparison of the at least one monitored performance characteristic and the at least one desired performance characteristic, and the selected configuration Operative to select the set of configuration parameters by selecting the set of configuration parameters from a plurality of different sets of configuration parameters based on the score values assigned to the set of configuration parameters. 16 systems.   The node configurator is operative to select the set of configuration parameters further based on a comparison by the node configurator of usage cost data associated with using different available nodes in the multi-node cluster. System. A data monitor configurator and a data aggregator;
The data monitor configurator is operable to deploy at least one node performance monitoring tool to each node of the multiple node cluster, wherein the at least one node performance monitoring tool is executed by a node when the plurality of node performance monitoring tools are executed by the node. Operative to monitor the at least one performance characteristic of the node and provide performance data representative of the at least one performance characteristic upon each execution of the workload by a cluster of nodes;
The data aggregator is operative to aggregate the performance data provided by the at least one node performance monitoring tool of each node, and the node configurator sets the configuration parameter set based on the aggregated performance data. The system of claim 16, which is operative to select.   The system of claim 16, wherein the node configurator is further operative to provide the selected set of configuration parameters to the cluster of nodes.   Further comprising at least one processor and a memory containing executable instructions, the executable instructions providing a graphical user interface comprising selectable configuration data when executed by the at least one processor. 17. The system of claim 16, wherein the system is executed by the at least one processor, and the plurality of different sets of configuration parameters are based on a user selection of the selectable configuration data.   Further comprising at least one processor and a memory containing executable instructions, the executable instructions providing a graphical user interface comprising selectable configuration data when executed by the at least one processor. Causing the at least one processor to execute an initial set of the plurality of different sets of configuration parameters based on at least one user selection of the selectable configuration data; The set is based on an adjustment by the node configurator of at least one configuration parameter of the initial set of configuration parameters. The system of claim 16 which is selected by Igyureta.   The at least one performance characteristic and the at least one desired performance characteristic monitored during each execution of the workload are: workload execution time, processor utilization by at least one node, memory utilization by at least one node, at least one 17. The system of claim 16, comprising at least one of power consumption by one node, hard disk input / output (I / O) utilization by at least one node, and network utilization by at least one node.   The hardware configuration parameter of the at least one node is at least one of the number of processors of the at least one node, the amount of system memory of the at least one node, and the amount of hard disk space of the at least one node. 17. The system of claim 16, comprising one.   The boot time parameter of the at least one node includes the number of processing cores of the at least one node enabled upon execution of the workload and the at least one node accessible by the operating system of the at least one node. 17. The system of claim 16, comprising at least one of an amount of system memory.   The system of claim 16, wherein the operational parameter of the workload container is associated with at least one of a read / write operation, a file system operation, a network socket operation, and a sorting operation.   The operation parameter related to the read / write operation includes at least one of a memory buffer size for the read / write operation and a size of a data block transferred in the read / write operation, and the file system operation The operational parameters associated with the at least one of: a number of file system records stored in the memory of each node; and a number of processing threads of each node allocated to process requests for the file system, 28. The system of claim 27, wherein the operational parameter associated with a sorting operation comprises a number of data streams to merge when performing the sorting operation. When executed by at least one processor,
A set of configuration parameters for a multi-node cluster of a computing system is obtained from a plurality of different sets of configuration parameters of the multi-node cluster monitored during a prior execution of a workload by the multi-node cluster. Selecting based on a comparison by the at least one processor of at least one performance characteristic and at least one desired performance characteristic of the cluster of nodes.
Providing the workload to the cluster of nodes for execution by the at least one processor for shared execution by the cluster of nodes configured with the selected set of configuration parameters. A non-transitory computer readable medium comprising such executable instructions.   The executable instructions cause the at least one processor to initiate prior execution of the workload, the at least one processor on the different sets of configuration parameters of the cluster of nodes. Starting a prior execution of the workload by initiating multiple executions of the workload on the multiple node cluster, wherein the configuration parameter is an operational parameter of the workload container, at least one node And at least one hardware configuration parameter of at least one node, wherein the workload container coordinates processing of the workload on the cluster of nodes Non-transitory computer-readable medium of claim 29, work.   The executable instructions may include at least the value that the value associated with the at least one performance characteristic monitored during execution of the workload falls within a tolerance range associated with at least one corresponding desired performance characteristic. 32. The non-transitory computer readable medium of claim 30, wherein the at least one processor is further configured to select the set of configuration parameters based further on a determination by one processor.   The executable instructions assign the score value to each different set of configuration parameters based on a comparison of the at least one monitored performance characteristic and the at least one desired performance characteristic, and the selected 31. The method of claim 30, wherein the at least one processor is configured to select the set of configuration parameters from a plurality of different sets of configuration parameters based on the score values assigned to the set of configuration parameters. A temporary computer-readable medium.   The executable instructions select the set of configuration parameters further based on a comparison by the at least one processor of usage cost data associated with using different available nodes in the cluster of nodes. 32. The non-transitory computer readable medium of claim 30, having a single processor. The executable instruction further includes:
Operates to monitor the at least one performance characteristic of the node and provide performance data representative of the at least one performance characteristic upon each execution of the workload by the cluster of nodes when executed by the node Deploying at least one node performance monitoring tool on each node of the multi-node cluster;
Aggregating the performance data provided by the at least one node performance monitoring tool of each node to the at least one processor;
32. The non-transitory computer-readable medium of claim 30, wherein the executable instructions cause the at least one processor to select the set of configuration parameters based on the aggregated performance data.   32. The non-transitory computer readable medium of claim 30, wherein the executable instructions further cause the at least one processor to provide the selected set of configuration parameters to the cluster of nodes.   The executable instructions further cause the at least one processor to provide a graphical user interface comprising selectable configuration data, and the plurality of different sets of configuration parameters are defined by a user of the selectable configuration data. 32. The non-transitory computer readable medium of claim 30, based on the selection.   The executable instructions further cause the at least one processor to provide a graphical user interface comprising selectable configuration data, wherein an initial set of the plurality of different sets of configuration parameters is the selectable configuration. Based on at least one user selection of data, other sets of the plurality of different sets of configuration parameters are based on adjustments by the at least one processor of at least one configuration parameter of the initial set of configuration parameters, 32. The non-transitory computer readable medium of claim 30, selected by the at least one processor.   The at least one performance characteristic and the at least one desired performance characteristic monitored during each execution of the workload are: workload execution time, processor utilization by at least one node, memory utilization by at least one node, at least one 32. The non-transitory computer readable medium of claim 30, comprising at least one of power consumption by one node, hard disk input / output (I / O) utilization by at least one node, and network utilization by at least one node.   The hardware configuration parameter of the at least one node is at least one of the number of processors of the at least one node, the amount of system memory of the at least one node, and the amount of hard disk space of the at least one node. 32. The non-transitory computer readable medium of claim 30, comprising:   The boot time parameter of the at least one node includes the number of processing cores of the at least one node enabled upon execution of the workload and the at least one accessible by the operating system of the at least one node. 32. The non-transitory computer readable medium of claim 30, comprising at least one of an amount of system memory of a node.   31. The non-transitory computer readable medium of claim 30, wherein the operational parameter of the workload container is associated with at least one of a read / write operation, a file system operation, a network socket operation, and a sorting operation.   The operation parameter related to the read / write operation includes at least one of a memory buffer size for the read / write operation and a size of a data block transferred in the read / write operation, and the file system operation The operational parameters associated with the at least one of: a number of file system records stored in the memory of each node; and a number of processing threads of each node allocated to process requests for the file system, 42. The non-transitory computer-readable medium of claim 41, wherein the operational parameter associated with a sorting operation comprises a number of data streams to merge when performing the sorting operation.

Images