Patent ID: 12248821

DETAILED DESCRIPTION

Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure.

With reference toFIG.1, an example computing device100includes a processing unit (CPU or processor)120and a system connection110(e.g., a bus) that couples various system components including the system memory130, such as read-only memory (ROM)140and random-access memory (RAM)150, to the processor120. These and other components can be configured to control the processor120to perform various actions. Other system memory may be available for use as well. It can be appreciated that the disclosure may operate on a computing device100with more than one processor120or on a group or cluster of computing devices networked together to provide greater processing capability. The processor120can include any general purpose processor and a hardware or software service, such as service 1162, service 2164, and service 3166stored in storage device160, configured to control the processor120and/or a special-purpose processor where software instructions are incorporated into the processor design. The processor120may be a self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

The system service110may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input/output (BIOS) stored in ROM140or the like, may provide the basic routine that helps to transfer information between elements within the computing device100, such as during start-up. The computing device100further includes storage devices160, such as a hard disk drive, a magnetic disk drive, an optical disk drive, tape drive, a solid state drive, or the like. The storage device160can include software services162,164,166for controlling the processor120. Other hardware or software services or modules are contemplated. The storage device160is connected to the system service110by a drive interface. The drives and the associated computer readable storage media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the computing device100. In one aspect, a hardware module that performs a particular function includes the software component stored in a tangible and/or intangible computer-readable medium in connection with the necessary hardware components, such as the processor120, service110, display170, and so forth, to carry out the function. The basic components are known to those of skill in the art and appropriate variations are contemplated depending on the type of device, such as whether the device100is a portable, handheld computing device, a desktop computer, or a computer server.

Although the example described herein employs the hard disk160, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, digital versatile disks, cartridges, random access memories (RAMs)150, read only memory (ROM)140, a cable or wireless signal containing a bit stream and the like, may also be used in the exemplary operating environment. Tangible computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

To enable user interaction with the computing device100, an input device190represents any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. The input device190may be used by the presenter to indicate the beginning of a speech search query. An output device170can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems enable a user to provide multiple types of input to communicate with the computing device100. The communications interface180generally governs and manages the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

For clarity of explanation, the illustrative system100is presented as including individual functional blocks including functional blocks labeled as a “processor” or processor120. The functions these blocks represent may be provided through the use of either shared or dedicated hardware, including, but not limited to, hardware capable of executing software and hardware, such as a processor120, that is purpose-built to operate as an equivalent to software executing on a general purpose processor. For example the functions of one or more processors presented inFIG.1may be provided by a single shared processor or multiple processors. Use of the term “processor” should not be construed to refer exclusively to hardware capable of executing software. Illustrative embodiments may include microprocessor and/or digital signal processor (DSP) hardware, read-only memory (ROM)140for storing software performing the operations discussed below, and random access memory (RAM)150for storing results. Very large scale integration (VLSI) hardware embodiments, as well as custom VLSI circuitry in combination with a general purpose DSP circuit, may also be provided.

The logical operations of the various embodiments can be implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a general use computer, (2) a sequence of computer implemented steps, operations, or procedures running on a specific-use programmable circuit; and/or (3) interconnected machine modules or program engines within the programmable circuits. The computing device100can practice all or part of the recited methods, can be a part of the recited systems, and/or can operate according to instructions in the recited tangible computer-readable storage media. Generally speaking, such logical operations can be implemented as modules or services configured to control the processor120to perform particular functions according to the programming of the module. For example,FIG.1illustrates three services162,164and166which can be modules, software, and/or components configured to control the processor120. These services may be stored on the storage device160and loaded into RAM150or memory130at runtime or may be stored as would be known in the art in other computer-readable memory locations.

FIG.2illustrates an example cloud computing environment200. Cloud 1 (202), cloud 2 (204), cloud 3 (206), cloud 4 (208), and cloud N (210) can represent private clouds and/or public clouds associated with respective cloud providers. The clouds202-210can be provide various services and solutions to cloud consumers, such as software services (e.g., software as a service), platform services (e.g., platform as a service), infrastructure services (e.g., infrastructure as a service), etc. For example, the clouds202-210can host, manage, and provide resources which may be accessible by computing networks and/or devices associated with particular cloud consumers. The cloud consumers can include cloud customers (e.g., users and/or organizations) which receive specific cloud services from the clouds202-210.

The clouds202-210can provision resources and/or services to cloud consumers over the network220. The network220can include a public and/or private network, such as the Internet. The clouds202-210can provide fine-grained knowledge and control of the resources in the clouds202-210and the usage of cloud resources/services by cloud consumers, and can track and bill cloud consumers on that basis.

The clouds202-210can include various layers such as, without limitation, a service and/or resource orchestration layer which provides management, monitoring, and scheduling of resources (e.g., compute, storage, and network resources) into consumable services by cloud consumers; a physical resources layer (e.g., physical infrastructure) which can include computing, storage, and network resources; a user layer which can provide user or administrator functions; an access layer which can provide endpoint and/or inter-cloud functions; a management layer which can provide operational management, performance functions, and security functions; and a pooling and virtualization layer which can turn physical resources into virtual resources (e.g., virtual machines, software containers, virtual storage, virtual networks, virtual devices, etc.). Software and platform assets in the clouds202-210can include the runtime environments, applications, and software assets used to orchestrate and provide cloud services.

Virtualization software and technologies may be implemented on any particular cloud to create virtualized resources and/or environments, such as VMs, software containers, software-defined networks (SDNs), virtual network interfaces, virtual applications or services, virtual storage, virtual computing, etc. Virtualization software and technologies can also be used to create distributed, logical resources and/or micro-services. For example, virtualization technology can be used to create a logical pool of resources across one or more clouds or networks. As another example, virtualization technology can be used to create service chains, virtualized network functions (VNF), and/or logical or overlay networks on one or more clouds or networks.

The cloud computing environment200can also include an on-premises site212. The on-premises site212can include a private cloud, branch, network, and/or data center. The on-premises site212can provide an entity, such as an enterprise, enhanced data security, locality, and control. The on-premises site212can be a cloud consumer or customer of clouds202-210. As a customer of clouds202-210, the on-premises site212can submit or route job requests for processing at any of the clouds202-210, can deploy applications or services on the clouds202-210, can use and provision resources from the clouds202-210, etc.

For example, clouds202-210can provide overflow computing services or resources to the on-premises site212. Workload management services can provision infrastructure resources and/or schedule jobs on the clouds202-210for the on-premises site212. The workload management services can be used for management, scheduling, monitoring and provisioning workloads and/or resources in the cloud compute environment200.

FIG.2Billustrates an example pool of resources225on a cloud (e.g.,202,204,206,208,210) in the cloud compute environment200. In this example, the pool of resources225includes servers230, VMs232, software platforms234, applications236, containers238, and infrastructure resources240.

The servers230can host VMs232, software platforms234, applications236, containers238, and other software assets used to orchestrate and/or provide cloud services. Similarly, the VMs232can include specific applications, runtime environments, and software assets used to orchestrate and/or implement cloud services.

The software platforms234can include software and platform assets, such as runtime environments and software tools on which cloud consumers (e.g., on-premises site212) can deploy applications. Cloud consumers can use the software platforms234to deploy specific applications on the cloud using one or more programming languages and execution environments.

Applications236can include software services running on the cloud, which can be accessed by cloud consumers. Example software services can include web services, database services, content management services, collaboration services, security services, personal productivity services, business services, email services, etc.

Containers238can include hardware or software that provides a particular execution environment for software. Containers238can be created and managed on the cloud based on container virtualization technologies which virtualize the underlying operating environment (e.g., the operating system kernel) of an application. The result is an isolated container on which the application can run.

The infrastructure resources240can include physical or virtual resources such as storage, network or compute resources. For example, the infrastructure resources240can include storage nodes, network nodes or interfaces, and processors. The infrastructure resources240can be based on the underlying hardware infrastructure of the cloud.

FIG.2Cillustrates an example configuration245of the on-premises site212. In this example, the on-premises site212can include nodes262representing the physical or logical resources of the on-premises site212. The nodes262can include, for example, networking, storage, or compute resources. For example, the nodes262can include servers, computers, network devices (e.g., switches, routers, etc.), computing devices (e.g., storage devices, processors, etc.), and so forth.

The nodes262can be configured into clusters260A,260B,260N (collectively “260” hereinafter). The clusters260can include a collection of nodes connected to work together to perform a particular task(s). For example, the nodes in a particular cluster (e.g.,260A) can be configured to run specific applications, store specific data (e.g., data blocks, replicas, files, etc.), process specific workloads or jobs, process specific requests, etc.

The on-premises site212can also include storage256for storing specific content or data. The storage256can include one or more databases, shards, storage volumes, storage components, etc. The on-premises site212can also include a workload queue258, which can hold pending and/or processing jobs or requests.

The on-premises site212can management services250for managing, monitoring, scheduling, orchestrating, and/or processing workloads and resources. For example, the management services250can manage, orchestrate and schedule resources and jobs or workloads in the workload queue258.

The management services250can include a workload manager252and a resource manager254. The workload manager252can manage jobs or workloads submitted for the on-premises site212, including jobs or workloads in the workload queue. The workload manager252can monitor the workload queue258and manage each job or workload in the workload queue258until completion. The workload manager252can identify specific requirements for jobs or workloads submitted to the on-premises site212, such as resource and/or job or workload requirements (e.g., job priorities, data requirements, application requirements, performance requirements, etc.), and process the jobs or workloads according to the specific requirements for the jobs or workloads as well as any corresponding service level agreements (SLAs) or quality of service (QoS) arrangements.

The resource manager254can reserve, allocate, and/or provision resources for the jobs or workloads submitted. For example, the resource manager254can reserve, allocate, and/or provision one or more nodes262or clusters260for submitted jobs or workloads. The resource manager254can reserve, allocate, and/or provision resources dynamically, on-demand, or as requested. The resource manager254can coordinate with the workload manager252and together ensure that jobs or workloads submitted or in the workload queue258are scheduled and processed by the necessary resources according to the specific requirements, SLAs or QoS guarantees corresponding to such jobs or workloads.

In some cases, the workload manager252and resource manager254can provision external resources, such as cloud resources, for overflow traffic and process the overflow traffic through the external resources provisioned. For example, as further described below, certain conditions, such as backlogs, policy violations, and/or scarcity of resources, can trigger bursting onto a cloud (e.g., cloud202) in order to process some of the submitted or queued jobs or workloads based on resources provisioned from the cloud. The workload manager252and resource manager254can coordinate with one or more of the clouds202-210and/or a -multi-cloud bursting service (e.g., multi-cloud bursting service340A and/or340B shown inFIG.3) to provision cloud resources for certain jobs or workloads.

FIG.3illustrates an example configuration300of cloud computing environment200including multi-cloud bursting services340A-B for managing the use, performance, and/or delivery of cloud services and providing intermediary services between a cloud consumer (e.g., on-premises site212) and multiple cloud providers (e.g., clouds202-210). Multi-cloud bursting services340A-B (collectively “340”) represent one or more entities that provide cloud bursting and/or brokering services between the on-premises site212and clouds202-210. Multi-cloud bursting services340can be implemented via one or more systems (e.g., computing device100shown inFIG.1), networks, servers, and/or configured to provide the cloud bursting tasks described herein.

Multi-cloud bursting service340A receives requests from clients312,314,316and318. Clients312,314,316and318can be users or entities (e.g., cloud consumers) with processing needs, resource needs, overflow requests, etc. Multi-cloud bursting service340A can poll one or more of the clouds202-210to identify respective capabilities and characteristics, including any type of parameter (e.g., location, performance, cost, availability, latency, data or workload processing patterns, etc.) associated with the respective clouds202-210. Examples of different capabilities or characteristics may include resource types, resource quantities, resource costs (e.g., per unit of compute resource, per request or job, per resource reservation time, per subscription, per amount of data, per requirement, etc.), QoS guarantees, SLAs offered, resource availability, parameters offered, processing patterns, efficiency parameters, etc. For example, cloud202may provide a five cents per unit cost but may only provide a mid-level SLA and a low-level reliability for jobs processed in that environment. Cloud204may have a high-level SLA available but with a cost of eight cents per unit.

Clouds202,204,206,208, and210may have respective management services302A,302B,302C,302D,302E or some other management tool to determine how resources within each environment are consumed. Management services302A,302B,302C,302D,302E can operate as described above with reference to management services250(including workload manager252and/or resource manager254) shown inFIG.2C, to manage resources in the respective environments. For example, management services302A,302B,302C,302D,302E can manage jobs322,324,326,328,330. Cloud consumers or third party requesters can submit jobs322,324,326,328,330directly to each respective cloud. A job can represent any job or workload that consumes resources in the compute environment, such as a web server request, a weather analysis, an accounting task, database query, etc.

The multi-cloud bursting services340can manage and/or facilitate cloud bursting to more than one cloud (202-210). To this end, the multi-cloud bursting services340can periodically poll the clouds202-210to identify their respective resource capabilities, conditions, characteristics, etc. In some cases, each of the clouds202-210can report to the multi-cloud bursting services340its resource capabilities, conditions, characteristics, etc., and/or any changes in its resource capabilities, conditions, characteristics, etc., instead of or in combination with the multi-cloud bursting services340polling the environments.

In order to communicate and function with multi-cloud bursting services340, each of the clouds302-310may register with the multi-cloud bursting services340. In some cases, a cloud may not register with the multi-cloud bursting services340but may otherwise make data available to the multi-cloud bursting services340for determining whether to send workload to that cloud.

Each of the multi-cloud bursting services340can develop a relationship with a number of clouds. As shall be discussed herein, the ability of the multi-cloud bursting services340to identify, aggregate, communicate, and manage compute resources across a number of different clouds can greatly simplify the ability of workloads to be processed on compute resources that match SLA requirements for the cloud consumers. The multi-cloud bursting services340can provide an easy and efficient supply chain management between a job from a customer who desires compute resources for the job and the consumption of selected resources on a cloud by that job.

In some examples, clients312,314,316,318can submit a job to the multi-cloud bursting service340A which then identifies suitable clouds (202-210) and submits the job on behalf of the client. Clients312,314,316,318can query the multi-cloud bursting service340A to determine which clouds are capable of servicing the workload within the workload, SLA or QoS requirements. In some cases, the clients312,314,316,318can submit jobs directly to the appropriate cloud(s) based on information from the multi-cloud bursting service340A. Therefore, rather than transmitting a job or workload, the multi-cloud bursting service340A just passes information about the clouds202-210to the clients.

The multi-cloud bursting services340can utilize software and hardware tools that communicate seamlessly with management services (e.g.,302A-E) in the various clouds. This can greatly facilitate the determination of capabilities and information associated with the various clouds. In some cases, there can be a confidence level associated with the knowledge that is received from polling the separately administered compute environments. The multi-cloud bursting services340can adapt workload distribution as the confidence level changes or as learning algorithms interact with and record metrics associated with the various environments.

The polling of each of the clouds202-210can occur at predetermined intervals and/or dynamically by the multi-cloud bursting services340. For example, the multi-cloud bursting services340may poll one or more clouds every half hour, daily, or on a per job basis. A large batch job can be submitted every evening at midnight for processing. In preparation for most advantageously ensuring that the optimal compute resources are identified and matched for processing the batch job, this system can automatically schedule to receive an updated polling of all of the separately administered compute environments in order to have a current snapshot of the resource capabilities across the different environments. In some cases, the SLA can require polling at a certain minimum interval.

The requests received by the multi-cloud bursting services340for compute resources can specify specific attributes, SLAs, QoS requirements, priorities, etc. The request or requestor can thus identify various parameters associated with the request. Such parameters can include a required cost, a required performance level, a required guarantee of resource availability, an amount of resources, locality requirements, reliability requirements, security requirements, etc. Based on the identified resource capabilities across the clouds202-210and the parameters associated with a request, the multi-cloud bursting services340can select compute resources in one or more of the clouds202-210. The selection may involve identifying the resources and availabilities in one or more environments. In some cases, multi-cloud bursting services340can split jobs or workloads amongst more than one of the clouds202-210. The multi-cloud bursting services340can also instruct or communicate with workload managers in the respective environments to ensure that specific resources are reserved or scheduled for processing the job or workload. In some cases, the multi-cloud bursting services340can serve as enforcers of the requirements (e.g., SLA, QoS, etc.) associated with a job or workload.

The process of managing the selection and reservation and actual consumption of resources may use many of the principles in the following patent applications: U.S. patent application Ser. No. 10/530,583, filed Apr. 7, 2005; U.S. patent application Ser. No. 11/751,899, filed May 22, 2007, both disclosing providing advanced reservations in a compute environment; U.S. patent application Ser. No. 10/530,582, filed Aug. 11, 2006 disclosing co-allocating a reservation spanning different compute resource types; U.S. patent application Ser. No. 10/530,581, filed Aug. 11, 2006 disclosing self-optimizing reservation in time of compute resources; U.S. patent application Ser. No. 10/530,577, filed Mar. 11, 2005 disclosing providing a self-optimizing reservation in space of compute resources; U.S. patent application Ser. No. 11/208,138, filed Aug. 19, 2005 disclosing providing dynamic roll-back reservations in time; U.S. patent application Ser. No. 11/629,940, filed Dec. 18, 2006 disclosing providing reservation masks within a compute environment; U.S. patent application Ser. No. 11/268,857, filed Nov. 8, 2005, now U.S. Pat. No. 7,356,770; U.S. patent application Ser. No. 12/033,386, filed Feb. 19, 2008 both disclosing graphically managing and monitoring a compute environment; U.S. patent application Ser. No. 11/155,090, filed Jun. 17, 2005 disclosing using transaction IDs for managing reservations of compute resources within a compute environment; U.S. patent application Ser. No. 11/155,347, filed Jun. 17, 2005 disclosing providing threshold-based access to compute resources; U.S. patent application Ser. No. 10/530,576, filed Mar. 11, 2005 disclosing providing multi-resource management support in a compute environment; U.S. patent application Ser. No. 11/718,867, filed May 8, 2007 disclosing providing system jobs within a compute environment; U.S. patent application Ser. No. 11/155,091, filed Jun. 17, 2005 disclosing providing dynamic provisioning within a compute environment; U.S. patent application Ser. No. 10/589,339, filed Aug. 11, 2006, now U.S. Pat. No. 7,490,325 disclosing providing intelligent pre-staging of data in a compute environment; U.S. patent application Ser. No. 11/276,852, filed Mar. 16, 2006 disclosing providing a virtual private cluster; U.S. patent application Ser. No. 10/530,578, filed Mar. 11, 2005 disclosing providing object triggers; U.S. patent application Ser. No. 10/530,580, filed Apr. 7, 2005 disclosing providing object messages in a compute environment; U.S. patent application Ser. No. 10/530,575, filed Feb. 4, 2008 disclosing enforcing future policies in a compute environment; U.S. patent application Ser. No. 11/207,438, filed Aug. 19, 2005 disclosing interfacing a workload manager and scheduler with an identity manager; U.S. patent application Ser. No. 11/276,013, filed Feb. 9, 2006 disclosing providing a fixed time offset based on a dedicated co-allocation of a common resource set; U.S. patent application Ser. No. 11/276,853, filed Mar. 16, 2006 disclosing automatic workload transfer to an on-demand center; U.S. patent application Ser. No. 11/276,854, filed Mar. 16, 2006 disclosing simple integration of an on-demand compute environment; U.S. patent application Ser. No. 11/276,855, filed Mar. 16, 2006 disclosing reserving resources in an on-demand compute environment; U.S. patent application Ser. No. 11/276,856, filed Mar. 16, 2006 disclosing an on-demand compute environment; U.S. patent application Ser. No. 11/279,007, filed Apr. 7, 2006 disclosing on-demand access to compute resources; U.S. patent application Ser. No. 11/763,010, filed Jun. 14, 2007 disclosing optimized multi-component co-allocation scheduling with advanced reservations for data transfers and distributed jobs; U.S. patent application Ser. No. 11/616,156, filed Dec. 26, 2006 disclosing co-allocating a reservation spanning different compute resources types; U.S. patent application Ser. No. 12/023,722, filed Jan. 31, 2008 disclosing managing a hybrid compute environment; U.S. patent application Ser. No. 12/179,142, filed Jul. 24, 2008 disclosing managing energy consumption in a compute environment; U.S. patent application Ser. No. 12/245,276, filed Oct. 3, 2008 disclosing dynamically managing data-centric searches. Each of these patent applications is incorporated herein by reference.

The principles incorporated in by reference above describe various examples and implementations of brokering cloud computing services. Such principles include various methods for managing advanced reservations in a compute environment, collocating a reservation, spanning different compute resource types, self-optimizing reservations in time and or space, providing dynamic rollback reservations in time, providing reservation masks within a compute environment, providing transaction IDs for managing reservations in compute resources, providing threshold-based access to compute resources, providing multi-resource management support, providing system jobs, providing dynamic provisioning, providing intelligent pre-staging of data, providing a virtual private cluster, providing object triggers, providing object messages, enforcing future policies, interfacing a workload manager and scheduler with an identity manager, providing fixed-time offset-based dedicated co-allocation of common resource sets, workload transfer to an on-demand center, simple integration of an on-demand compute environment, reserving resources in an on-demand compute environment, on-demand access to compute resources, optimizing multi-component co-allocation scheduling with advanced reservations for data transfers and distributed jobs, co-allocating a reservation spanning different compute resource types, managing a hybrid compute environment such as having multiple operating systems that may be provisioned and repositioned according to workload need and managing energy consumption in the compute environment.

After receiving requests for processing workloads and gathering information from the clouds202-210, the multi-cloud bursting services340can analyze the clouds using the various principles set forth above to select the appropriate resources in one or more clouds for processing the workload. In one example, the on-premises site212may include, in an SLA requirement enforced by multi-cloud bursting service340B, a requirement that if its workload is being processed in cloud208and the performance level drops below a threshold or there is a failure of services from cloud208, the multi-cloud bursting service340B intelligently migrate350the job or workload to another cloud (e.g.,202) to provide continuity and meet the job or workload requirements.

The multi-cloud bursting services340can provide cloud bursting and/or brokering services in several ways. First, the multi-cloud bursting services340may provide information as previously explained. In this case, the requestors312,314,316or318may simply receive information about resources on the clouds202-210. For example, the information can indicate that cloud204is offering a discount for processing a workload if the client can wait 24 hours. The multi-cloud bursting services340can interact with the submitter and manage the relationship between the respective cloud and the submitter to receive an accepted commitment and process the workload to the selected resources in the respective cloud or clouds.

Once a job or workload is communicated to a selected compute environment for the selected resources, which can span one or more of the compute environments, the multi-cloud bursting services340can further analyze parameters associated with how the selected compute environment is processing the communicated job or workload. If a particular threshold is met, the multi-cloud bursting services340can identify and select new compute resources from the compute resource environments and migrate all or part of the communicated job or workload to the new compute resources. This migration is represented by line350.

In some cases, jobs or workloads can be communicated between the multi-cloud bursting services340. For example, as illustrated inFIG.3, multi-cloud bursting service340B communicates with cloud210and on-premises site212. Clients332,334,336,338can submit requests and workload to multi-cloud bursting service340B. In some cases, multi-cloud bursting service340B can communicate with multi-cloud bursting service340A to facilitate processing requests and workloads and/or communicating with clouds202-208. This can be done transparent to the clients.

For example, multi-cloud bursting service340B may not find ideal or satisfactory compute resources within cloud208or on-premises site212. Accordingly, multi-cloud bursting service340B may communicate the request to multi-cloud bursting service340A. Multi-cloud bursting service340A may migrate part or all of the job or workload submitted by clients332,334,336or338to one or more clouds (202-208) in order to satisfy the requirements associated with the job or workload.

In some cases, jobs or workloads can be communicated through the multi-cloud bursting service340A or340B to individual clouds through a respective instance of workload management services (e.g.,302A-E) within the individual clouds. For example, assume that requestor320requests compute resources and multi-cloud bursting service340A selects cloud202to provision resources for the request. Rather than simply communicating workload to the cloud202for consumption, the multi-cloud bursting service340A can manage the creation of an instance of workload management service (302A) in cloud202.

In this scenario, several benefits can be realized. First, the workload management service302A can perform necessary provisioning or modification of the reserved nodes in order to duplicate or create a particular environment which is suitable for the workload from the requestor320. Furthermore, having an instance of the workload management service302A on cloud202can enable efficient communication between the cloud202and the multi-cloud bursting service240A. Therefore, in some cases, the multi-cloud bursting service340A can receive a request from requestor320, identify resources within cloud202for consumption, install an instance of workload management service302A within cloud202, obtain a modification (if necessary) of the selected resources via the installed workload management service302A, provide communication of requirements between the multi-cloud bursting service340A and the workload management service302A, and finally enabling consumption of the resources associated with the request according to transmitted workload to the cloud202. This creates a package of consumed resources that can grow and shrink according to requirements.

The environment that is created in cloud202can be provisioned to match a private cloud or network such as on-premises site212. Thus, if a company has a private cloud (e.g.,212), the company can utilize a multi-cloud bursting service (e.g.,340B) for overflow workload additional resources needed from a public cloud. The multi-cloud bursting service can create an instance of workload management service on a public cloud and duplicate the environment of the private cloud or network (212) for the overflow workload.

As will be described further with reference toFIG.4, the multi-cloud bursting service340A can employ cloud agnostic templates (e.g.,406shown inFIG.4) to provision and burst across clouds (e.g.,202-210) from different cloud providers despite differences in cloud solutions, platforms, configurations, architectures, requirements, programming languages, resources, characteristics, etc., between the different clouds.

FIG.4illustrates an example configuration400for cloud bursting onto multiple clouds202-210associated with distinct cloud providers and/or environments (e.g., architectures, resources, configurations, capabilities, resources, platforms, infrastructure, cloud solutions, etc.) in a cloud agnostic manner. In this example, the on-premises site212is configured with cloud bursting parameters and triggers402for sending a cloud bursting request404to multi-cloud bursting service340A in order to burst to one or more of the clouds202-210.

The cloud bursting parameters and triggers402can include one or more triggers for the cloud bursting request404. The one or more triggers can include one or more rules or conditions for triggering the cloud bursting request404to multi-cloud bursting service340A. The one or more rules or conditions can include, for example, a backlog threshold, a policy violation threshold, an SLA violation threshold, a capacity threshold, a job or workload request threshold, etc. For example, a trigger for generating and sending the cloud bursting request404can be that a backlog of jobs or workloads received or in the workload queue258exceed a threshold. To illustrate, the trigger can specify that the cloud bursting request404should be generated and sent when the workload queue258or backlog reaches or exceeds X number of jobs or workloads, or when X number of jobs or workloads are submitted to the on-premises site212. As another example, a trigger for generating and sending the cloud bursting request404can be that an SLA, QoS guarantee, or requirement has been violated, such as a maximum latency requirement, a minimum performance requirement, a reliability requirement defining a maximum number of errors or failures, a policy defining a timing requirement for processing or completing submitted jobs or workloads, etc.

In some cases, the trigger may be based on the capabilities of the on-premises site212, the availability of resources at the on-premises site212, the likelihood that the on-premises site212will satisfy one or more requirements associated with a job or workload (e.g., based on, for example, the type or number of resources needed for the job or workload versus the type or number of resources at the on-premises site212, the size of the job or workload relative to the resources at the on-premises site212, etc.). For example, the trigger can define a threshold amount or a type of resources that should be available or capable of processing the job or workload at the time the job or workload request is submitted or within a specified grace period. If the threshold amount or type of resources available or capable is reached or exceed when the request is submitted or within the specified grace period, the trigger will cause the cloud bursting request404to be generated and transmitted to the multi-cloud bursting service340A.

The management services250can monitor the cloud bursting parameters and triggers402, the workload queue258, incoming requests, and the resources at the on-premises site212to detect when triggering condition(s) are met for generating and sending the cloud bursting request404. When the triggering condition(s) are met, the cloud bursting request404can be generated and transmitted to multi-cloud bursting service340A to initiate a cloud bursting process as further described below. The cloud bursting request404can be transmitted to the multi-cloud bursting service340A via, for example, an application programming interface (API). Such an API can be configured with calls and a framework for making and receiving the request. Both components on either side of the API would be configured or programmed with the API requirements. In some cases, a single API can be used to communicate with the multi-cloud bursting service340A. The on-premises site212can send one or more API calls via the API to the multi-cloud bursting service340A to communicate the cloud bursting request404.

The on-premises site212can send the cloud bursting request404to multi-cloud bursting service340A, to multiple multi-cloud bursting services (e.g.,340A and340B) or any particular multi-cloud bursting service (e.g., multi-cloud bursting service340A and/or340B) from multiple multi-cloud bursting services (340) for the cloud bursting request404. The determination of which and how many multi-cloud bursting services to send the cloud bursting request404to can be based on one or more factors, such as a relationship between the on-premises site212and the multi-cloud bursting services340A/B; a status of the multi-cloud bursting services340A/B; a responsiveness of the multi-cloud bursting services340A/B; a random selection algorithm; a respective link status (e.g., throughput, latency, distance, performance, congestion, functionality, security, availability, redundancy, etc.) between the on-premises site212and the multi-cloud bursting services340A/B; a load balancing scheme; the type or number of resources that are needed or being requested; the clouds associated with, connected to, or polled by each respective multi-cloud bursting service; the information received from each respective multi-cloud bursting service; etc. In some cases, the on-premises site212can send the cloud bursting request404to multiple multi-cloud bursting services (340A/B) and select a particular multi-cloud bursting service based on the respective responses received from the multi-cloud bursting services (e.g., the timing of the responses, the information in the responses, etc.).

The cloud bursting request404can request provisioning or deprovisioning of one or more nodes and deployment/launching of service instances (e.g., execution environments, software applications or tools, etc.). The bursting parameters and triggers402can dictate whether the cloud bursting request404is for provisioning nodes or deprovisioning nodes. The parameters in the bursting parameters and triggers402can define specific attributes, requirements, and information used in provisioning or deprovisioning nodes in response to the cloud bursting request404. For example, the bursting parameters and triggers402can include parameters for provisioning nodes from one or more clouds (202-210), such as a reservation period (e.g., day, month, quarter, year, etc.), a type and/or number of resources (e.g., nodes) that should be provisioned, cost requirements, SLA requirements, QoS requirements, performance requirements, security requirements, reliability requirements, environment requirements, preferences, priorities, a budget for bursting, policies, etc. As another example, the bursting parameters and triggers402can include parameters for deprovisioning (e.g., destroying, canceling, un-reserving, etc.) nodes, such as a trigger (e.g., job TTL exceeded, idle node time exceeded, a job or workload completion, a threshold backlog or workload queue258reduction, a threshold cost, a threshold availability at the on-premises site212, etc. Some deprovisioning approaches are discussed below in connection withFIG.9B.

For example, the parameters can define a trigger for retiring or destroying provisioned nodes from clouds202-210based on a job TTL being exceeded or an idle node time being exceeded. As another example, the parameters can define a trigger for retiring or destroying provisioned nodes from clouds202-210when the workload queue258has below a threshold number of jobs/requests pending and/or processing. In some cases, the network operator at the on-premises site212can also manually retire or destroy provisioned nodes from clouds202-210based on any criteria, such as a number of pending jobs, a backlog reduction, etc.

In some cases, the bursting parameters and triggers402can be defined in specific job or workload templates. Such job or workload templates can identify specific jobs or workloads, associated requirements, associated dependencies, associated triggers for bursting, associated instructions for bursting, and/or any other information pertinent to the jobs or workloads. The job or workload templates can also identify specific cloud agnostic template stacks for provisioning resources for associated jobs or workloads on any cloud regardless of the cloud configurations, architecture, platform, characteristics, etc. Cloud agnostic template stacks will be further described below.

The cloud bursting request404to multi-cloud bursting service340A can specify any parameters and/or requirements for the associated job or workload, such as a job priority, an SLA, a QoS requirement, a cost threshold, a performance requirement, a security requirement, a processing parameter, a resource requirement (e.g., a number and/or type of resources required or desired), a reliability requirement, a deprovisioning mode, etc. The cloud bursting request404can identify the job or workload that needs processing and any provisioning or deprovisioning instructions. In some cases, the cloud bursting request404can specify one or more particular clouds (202-210) being requested or prioritized for the job or workload.

The multi-cloud bursting service340A receives the cloud bursting request404and processes the request based on the information provided in the request. The multi-cloud bursting service340A can use cloud agnostic template stacks406for image management and provisioning410. The cloud agnostic template stacks406can define one or more stacks which can define the provisioning dependencies and task. A stack can include the base operating system (OS), services, libraries, applications, and/or data for the execution environment for the jobs or workloads. The stacks can be used to create the images for the execution environment to be loaded on the provisioned cloud nodes. The multi-cloud bursting service340A can manage the creation, modification, destruction, processing, verification, storing, and deploying of images or environments corresponding to the stacks.

A stack can also include tasks (e.g., scripts, commands, operations, steps, etc.) for provisioning node(s) on the clouds202-210(e.g., requesting or reserving nodes) and deploying (e.g., loading, configuring, etc.) specific execution environment (e.g., image) on the provisioned node(s). A stack can define the number or type of nodes to be provisioned, the number of instances to be installed and launched, the amount of time the nodes are to be reserved, when the instances should be installed and/or launched, deprovisioning modes relative to head nodes and compute nodes, etc. The tasks can include instructions or executable code to request and provision nodes and install and launch instances as defined in the stacks.

A stack can also define resource requirements for the defined instances, such as a number of processors, an amount of time the resources are to be reserved, etc. A stack can define the resource and/or instance requirements based on various factors, such as job priorities, job requirements, etc. For example, a stack can define tasks for requesting a higher number of nodes and/or processing elements, and launching a higher number of instances for higher priority jobs than lower priority jobs. A stack can define tasks for configuring various aspects of the provisioned nodes, as previously explained, such as the number of processors, the amount of memory, the number of network interfaces or addresses, etc.

A stack can also define the specific cloud and/or job configuration for the associated job or workload. For example, a stack can specify that job X should be processed on cloud202and job Y should be processed on cloud204. A stack can include specific flags and parameters to be configured for the job on the specified clouds.

As previously explained, multi-cloud bursting services (e.g.,340A and340B) can install instances of management services (e.g.,302A-E and250) on the clouds202-210, including workload manager services (e.g.,252) and/or resource manager services (e.g.,254). This process can also be performed using the cloud agnostic template stacks406. For example, the cloud agnostic template stacks406can define the dependencies and environment for provisioning nodes on the clouds202-210and installing and launching instances of management services.

In some examples, the cloud agnostic stacks406can be defined in one or more files or objects. For example, a cloud agnostic stack can be defined in a JSON file which provides significant customization and flexibility.

Based on the stack(s) associated with a job or workload corresponding to the cloud bursting request404, the multi-cloud bursting service(s) (e.g., multi-cloud bursting service340A and/or340B) can provision410specific cloud nodes412-420from one or more of the clouds202-210and configure the execution environments and parameters for the job or workload to be processed by the provisioned nodes. In the example ofFIG.4, the multi-cloud bursting service340A provisions410one or more nodes412from cloud202, one or more nodes414from cloud204, and one or more nodes416from cloud206. These provisioned nodes412,414,416can then be used to process the jobs or workloads associated with the cloud bursting request404.

The nodes provisioned (e.g.,412,414,416) from the clouds (e.g.,202,204,206) can be integrated with the nodes262on the on-premises site212. The on-premises site212, the multi-cloud bursting service340A that provisioned the nodes, and/or the clouds associated with the provisioned nodes (e.g., clouds202,204,206) can coordinate the integration of the provisioned nodes with the on-premises nodes262. In some cases, the management services250(e.g., via the workload manager252and/or the resource manager254) on the on-premises site212can help with part or all of the integration of the provisioned nodes from the clouds.

In some cases, the provisioned nodes (e.g.,412,414,416) from the clouds (e.g., clouds202,204,206) can be included in one or more clusters (e.g., cluster260A) configured on the on-premises site212. In the example ofFIG.4, the nodes412,414,416provisioned from clouds202,204,206are added to cluster260A in the on-premises site212, thus appearing as part of the cluster260A of on-premises nodes262and working with the on-premises nodes262in the cluster260A to process jobs or workloads. As further described below, a graphical user interface that depicts the cluster, nodes, jobs or workloads, job or workload statuses, etc., can depict the on-premises nodes262and provisioned nodes412,414,416, as well as their associated jobs or workloads, as part of the cluster260A as if all of such nodes reside on, or are part of, the on-premises site212.

Once the reservation of the provisioned nodes412,414,416expires or a deprovisioning trigger is satisfied, the provisioned nodes412,414,416can be deprovisioned or unreserved. The deprovisioning trigger can automate the process of deprovisioning or removing the provisioned nodes412,414,416even before their reserved time lapses in order to save costs.FIG.9Balso illustrates various modes of deprovisioning which can be implemented.

The cloud agnostic template stacks406are cloud agnostic in the sense that they can be used for bursting on multiple clouds (e.g.,202-210) from multiple cloud providers despite any differences in the cloud solutions, configurations, platforms, programming languages, resources, architecture, requirements, characteristics, etc., between the multiple clouds. The multi-cloud bursting service340A can process the cloud agnostic template stacks406and translate defined tasks to commands, instructions, executable code, etc., suitable for each specific cloud being used for a bursting request. This process can be automated thus ensuring easy and convenient bursting across multiple cloud providers and solutions.

FIG.5illustrates an example schema500for defining stacks in cloud agnostic stack templates (e.g.,406). The schema500in this example includes fields502-510for defining stacks to be used for cloud bursting as previously explained. Field502is a name field for defining a unique name for the stack. The stack name provided in field502should be unique across all stack definitions. This allows the correct stack to be called or used when cloud bursting for a particular job or workload.

Field504is a version field where the user can define a version of the stack defined in field502. If the stack is an application or package, the version of the application or package can be defined here.

Field506is an OS field used to specify the OS image for the stack defined in field502. Base OS images for each cloud provider (e.g., clouds202-210) can be available through the multi-cloud bursting service340A shown inFIG.4, and new base OS images can be defined for any stack definition.

Field508is a files field for specifying the files that should be uploaded to build the instance (e.g., server) as part of the provisioning process. The files can be identified based on name, location or path, etc.

Field510is a tasks field which contains the provisioning tasks. The tasks can include different types of tasks, such as script tasks for running scripts or code to perform provisioning and deployment operations; file tasks for uploading and/or manipulating files and data used for the provisioning, jobs or workloads, etc.; command tasks for running commands (e.g., configuration commands, troubleshooting commands, launch commands, operations, etc.); and so forth.

FIG.6Aillustrates an example stack template600defined according to the schema500for installing and configuring a resource manager service (e.g., resource manager254), a VPN (virtual private network) application, namely, OpenVPN, a lightweight directory access protocol (LDAP) implementation for directory services, namely, OpenLDAP, and a distributed file system protocol, namely, NFS (network file system).

The name602specified in the name field502for the stack template600is ResourceManager. This is a unique name of the stack template600across all stack definitions. The version field504specified the version which in this example is version 9. The OS field506defines Linux CentOS6as the base OS for the stack. The files field508identifies the various files that will be uploaded to the build server to build the stack or image. In this example, the files field508identifies a package for the resource manager service, including the relative path of the package, and the LDAP package, including its relative path.

The tasks field510defines task 1 (608), task 2 (610), task 3 (612), task 4 (614), task 5 (616), task 6 (618), and task 7 (620), which will be further described below. Each of the tasks 1-7 (608-620) defines the respective type of task (e.g., script task, file task, etc.) and includes the respective instructions, scripts, commands, parameters, etc., for performing the task.

For example, task 1 (608) includes a task type definition630for a script task632, indicating that the task involves one or more scripts to be executed. Included in task 1 (608) is an inline script, which provides one or more commands to execute. The commands can be concatenated by new lines and turned into a single file, so they are executed within the same context. This allows for changing of directories in one command and using something in the directory in the next line and so on. Inline scripts provide a simple way to perform simple tasks within the machine. In this example, the task defines a shell command for creating a subdirectory in the root directory, which in this example is “˜/ResourceManager”.

Task 2 (610) includes a task type definition630which defines the task type as a file task634, which is a task for uploading one or more files. The file to be uploaded in this example is package604for the resource manager service. Task 2 (610) defines the source path or location for the file (package604) and the destination path or location for the file (package604), which in this case is the path “˜/ResourceManager” of the subdirectory created in task 1 (608).

Task 3 (612) includes a task type definition630for a script task632, indicating that the task involves one or more scripts to be executed. The script task in this example is an inline script including an array of shell commands. The commands include a change directory command (cd) to enter the subdirectory with the path “˜/ResourceManager” created in task 1 (608), a tar command to extract the contents of the package604uploaded to that subdirectory in task 2 (610), an ls (list) command to list the contents of the subdirectory after the package contents are extracted, and a command to run a shell script and execute the pwd (print working directory) command.

Task 4 (614), includes a task type definition630for a script task632. The script task is an inline script for installing OpenVPN, easy-rsa which is a utility for building and managing a PKI (public key infrastructure) CA (certificate authority), and an unzip utility via an example package manager (e.g., Yellowdog Updater Modified or yum).

Task 5 (616) includes a file task634, as specified in the task type definition630. The file task here uploads the LDAP package606from the subdirectory with the path “˜/ResourceManager” created in task 1 (608) to a new destination path (e.g., “˜/ac-ldap/ac-ldap.zip”).

Task 6 (618) includes a script task632as specified in the task type definition630. The task is an inline script with commands for installing OpenVPN, configuring an OpenVPN connection, starting an instance of OpenVPN, copying LDAP files, and installing OpenLDAP client.

Task 7 (620) includes a script task632as specified in the task type definition630. The task is an inline script with commands for installing NFS and mounting a directory.

The stack defined in stack template600, including the various tasks, parameters, and fields, are provided as an example for illustration purposes. One of ordinary skill in the art will recognize that many other stacks, tasks, parameters, and fields can be defined for many different purposes and are within the spirit of the disclosure and contemplated herein.

Moreover, the stack template600can be defined in any type of file(s), such as a JSON file. Once the stack template600is defined, it can be used to build the stack. For example, the stack can be built by running a particular script, command(s), or code, such as a build command, referencing the stack template file. This can create the stack in a particular region, which can be defined in the build process, and return a stack identifier (ID) which can be used to reference the stack in the cloud.

FIG.6Billustrates an example job template650defining jobs for bursting and running on one or more clouds. The job template650includes scheduling parameters652for configuring a workload and resource orchestration service (e.g., management services250), which in this example is MOAB WORKLOAD MANAGER by ADAPTIVE COMPUTING, INC. The parameters652include a flag656for enabling dynamic nodes. Dynamic nodes are nodes that can be added or removed at any time (e.g., based on a parameter or condition such as TTL).

The job template650includes a job configuration658for an example cloud bursting instance, such as a cloud web service instance or a cloud database service instance. The job configuration658includes a flag660identifying the cloud202for bursting the example cloud bursting instance. The job configuration658includes a trigger definition662, which in this example defines an elastic trigger (e.g.,402) which when enabled requests or orders the example cloud bursting instance on the cloud (e.g., cloud202). In this example, this is done through a script664that based on the trigger executes a job666identified by a job ID and implements a stack668referenced by a stack ID.

The request geometry parameter670specifies how nodes are requested when the trigger is satisfied. The values provided in this parameter can define the number of nodes to request, the time or duration for reserving the nodes requested, the number of processors for a node, etc. A purge parameter672can specify how nodes are removed. For example, nodes can be purged after a TTL or purge time has passed. The purge value can be defined in the purge parameter672.

A node configuration674can define configuration parameters and/or actions for configuring nodes. In this example, a trigger676is defined for executing a node provisioning action defined by a script678referenced in the node configuration674.

The job template650in this example can be implemented to configure jobs for on-demand elastic computing in the cloud computing environment (e.g.,200). In some cases, on-demand elastic computing can be different from backlog-based elastic computing in that it allows jobs to specify that they are meant to run in the cloud upon execution, without regard to the existence or state of a job backlog. Once a job is submitted, resources in the cloud are allocated so that the job can start running immediately on those cloud resources.

As illustrated herein, the job template650and stack template600, as well as the multi-cloud bursting service340A can be used to provide seamless bursting to multiple cloud providers and compute environments (e.g., clouds202-210). The specific environment for bursting can be defined for the multi-cloud bursting service340A, including the templates (e.g.,600,650) used for provisioning for nodes in the cloud as part of bursting. One or more templates (e.g.,600,650) can be defined once and the multi-cloud bursting service340A can use the one or more templates to provision and burst on any cloud provider and compute environment (e.g., clouds202-210), resulting in end-to-end, seamless provisioning/bursting to any of multiple cloud providers and compute environments.

The provisioned nodes from the cloud provider(s) can become part of the on-premises nodes (e.g.,262). The agnostic aspect (e.g., cloud agnostic stack template600and cloud agnostic job template650) define the steps, code, and items (e.g., OSs, applications, libraries, services, data, tools, configuration files, etc.) needed to provision/burst on any cloud provider (e.g., clouds202-210) of choice. The multi-cloud bursting service340A has the intelligence to process the templates600,650, identify the tasks, and translate the tasks into proper commands or executable instructions to provision/burst in the various cloud providers (e.g., clouds202-210), irrespective of the respective cloud provider solution (e.g., configuration, platform, environment, setup, architecture, requirements, syntax, usage settings, etc.) of the various cloud providers and compute environments. The network operator (e.g., administrator at the on-premises site212and/or multi-cloud bursting services340) can provide cloud provider configuration information in the cloud template (e.g.,600,650), which can include credentials for the respective cloud(s) (e.g.,202-210).

As part of an elastic computing solution, the client (e.g., user or consumer) can configure parameters (e.g., via a job template) to keep track of processor seconds on all dynamic nodes to limit over-bursting. For example, a particular configuration allows 1000 processor seconds of use every day, then if a job needs to burst and the used processor seconds reaches 1000 before the job can burst, the trigger to burst the job will not fire, and an error message is generated.

There are different values that can be set, such as day, month, quarter, or year. The second count resets at the beginning of each period. For ease of use, limits can be set based on processor hours, and the system can automatically convert the hours to seconds.

There are other example policies that can be set in the workload and orchestration platform (e.g., via a job template or configuration file) to limit over-bursting. For example, the following parameters can be specified by processor seconds:MAXDAILYELASTICPROCSECONDSMAXMONTHLYELASTICPROCSECONDSMAXQUARTERLYELASTICPROCSECONDSMAXYEARLYELASTICPROCSECONDS

To specify by processor hours, the following parameters can be used:MAXDAILYELASTICPROCHOURSMAXMONTHLYELASTICPROCHOURSMAXQUARTERLYELASTICPROCHOURSMAXYEARLYELASTICPROCHOURS

Usage policies can be set at the global partition or QoS level, for example.

Global Partition: once the elastic node first appears, the workload and orchestration platform (e.g., management services250) can begin keeping track of its processor seconds or hours. If the processor seconds reaches the limit, it will not fire off the elastic trigger so no new nodes will come in. For example: PARCFG[ALL]MAXDAILYELASTICPROCSECONDS=1000.

QoS: processor seconds or hours can start being counted once a job is submitting using that particular QoS. For example: QOSCFG[HIGH]MAXDAILYELASTICPROCSECONDS=500.

Here, a job is submitted requesting the “HIGH” QOS and the processor seconds begin ticking up for that QOS.

FIG.7illustrates an example output700showing on-premises and cloud nodes as part of the same on-premises cluster, which in this example is cluster260A in on-premises site212. The output700displays a name702of each of the nodes262,412,414,416,418,420in the cluster260A. The output700also displays, for each node, a state704, processors706, memory708, and an OS.

As illustrated in output700, the cluster260A in on-premises site212includes nodes262from the on-premises site212as well as nodes412,414,416,418,420provisioned from the clouds202-210. Thus, on-premises and cloud nodes are clustered together to process jobs or workloads for the on-premises site212, and appear as one single cluster as if all nodes resided on the on-premises site212.

FIGS.8A-Eillustrate example views800,840,850,860,870,880of graphical user interfaces available to the on-premises site212for viewing, monitoring, managing, and configuring jobs or workloads, templates, nodes, clusters, configurations, files, queues, statuses, etc., for the on-premises site212and any cloud provider, including on-premises nodes, nodes provisioned from the clouds202-210, and jobs or workloads processed by such nodes.

Referring toFIG.8A, view800shows an on-premises interface802and a cloud provider interface820. The on-premises interface802corresponds to on-premises site212, and the cloud provider interface820corresponds to any particular cloud provider and associated cloud environment, such as cloud202.

The cloud provider interface820illustrates nodes412and instances826A-J (collectively “826”) in cloud202. The cloud provider interface820also depicts the name822and instance identifier (ID)824for each of the nodes412and instances826.

Moreover, the cloud provider interface820can provide selectable graphical elements828A-B (e.g., buttons, drop-downs, etc.) that allow a user to select items and/or initiate actions. In this example, element828A is a selectable button for launching an instance on the cloud202, and element828B is a selectable button for initiating an action, such as cancelling an instance or node, pausing a job, etc.

The on-premises interface802depicts tabs804,806,808for navigating to specific areas or screens of the interface802. The tabs804,806,808include a workload tab (804), a templates tab (806), and a nodes tab (808). In this example, the on-premises interface802shows a screen presented when nodes tab (808) is selected.

The screen in the nodes tab (808) identifies nodes on the on-premises site212. In this example, the nodes include node262A,262B,262C,262D, and262E from the on-premises site212. The nodes262A-E can represent nodes in a cluster(s), a grid(s), or all or part of the nodes (e.g., active nodes, available nodes, deployed or provisioned nodes, functioning nodes, etc.) in the on-premises site212.

The screen also includes descriptive columns810A-N (collectively “810”), which contain information about nodes262A-E. In this example, column810A is a node ID column which contains the respective node ID of each node (262A-E), column810B is a status column which provides the respective status (e.g., busy, active, inactive, idle, pending, canceled, etc.) of each node (262A-E), and columns810N are columns providing various respective parameters or information812for each of the nodes262A-E. Any mode of communicating can be used to provide input or to interact with the system, such as speech, multi-modal, gesture, touch screen, mobile smart phone interface, biometrics, and so forth.

In this example, columns810N include a column detailing the number of cores available for each node (262A-E), a column detailing the number of jobs corresponding to each node (262A-E), a column detailing the CPU utilization for each node (262A-E), a column detailing the TTL (time to live) for each node (262A-E), a column detailing the operational task(s) for each node (262A-E), etc. Columns810N are examples provided for illustrative purposes. Other columns detailing other information or parameters are also contemplated herein, such as instance identifier columns, location columns, error columns, software environment columns, etc.

Referring toFIG.8B, view830illustrates a screen in the on-premises interface802when the workload tab (804) is selected. The workload screen shows a table of workloads on the on-premises site212. The table includes columns832-848containing information about jobs in the on-premises site212. Column832identifies jobs832A based on their respective job ID. Column834identifies the job name of each of the jobs832A.

Column836identifies a submitter ID for each job, and columns838and840identify respectively a job start date and job submit date for each job.

Column842identifies a queue status for each job. In this example, the queue status of jobs832A include an active status842A or a blocked status842B. Other statuses are also possible and contemplated herein, such as a pending status, a canceled status, an idle status, a paused status, etc.

Columns844and846respectively identify the number of cores and nodes associated with each job. Column848identifies a clock value for each job.

The workload screen can also include selectable graphical elements, such as drop-downs, form fields, input elements, buttons, etc., for initiating or controlling actions or operations. In this example, the workload screen includes a create job button814that allows a user to create one or more jobs right from the interface802.

Referring toFIG.8C, view850in the on-premises interface802illustrates different jobs (832B) in the workload screen having an eligible status842C in the queue status column (842). Jobs832B in this example represent jobs in the queue that are not active but are eligible for processing, bursting, provisioning, etc. Jobs832B in view850are in addition to the jobs832A shown in view830that are active (842A) or blocked (842B).

As illustrated in view850, the number of jobs832B that are eligible (842C) and need to be processed is large. Depending on the triggers associated with the jobs832B and/or on-premises site212, this can trigger provisioning and bursting onto one or more clouds202-210, as previously described, in order to speed up the processing of these jobs and reduce the queue, thus mitigating or avoiding potential violations (e.g., SLA, QoS, etc.). For example, if the number of the jobs832exceeds a threshold backlog or are estimated to violate one or more requirements, such as SLA or QoS guarantees, a configured trigger can automatically initiate a process for provisioning and bursting onto one or more clouds, as previously described, to mitigate or avoid the backlog or violations.

In some cases, a user can also manually initiate a provisioning/bursting process to one or more clouds (202-210) to reduce the queue or increase performance. For example, the user can initiate a provisioning and bursting process manually for processing a certain amount of jobs as desired.

Referring toFIG.8D, view860illustrates the screen on the nodes tab (808) of the on-premises interface802after bursting nodes412from cloud202. Line862illustrates the nodes412from cloud202, shown in the cloud provider interface820, being moved to the on-premises interface802to indicate that the nodes412from cloud202have been provisioned according to the approaches described herein to process jobs or workloads for the on-premises site212. The provisioning and bursting represented by line862can be triggered automatically based on one or more triggers, as previously described, and performed by the multi-cloud bursting service340A using the stack and job templates (e.g.,600,650) defined for the clouds202-210.

As illustrated in view860, the nodes depicted in the on-premises interface802for processing jobs at the on-premises site include a combination of on-premises nodes262and cloud nodes412from cloud202. The on-premises nodes262and cloud nodes412can work together to process jobs for the on-premises site212and appear as though they are all nodes on the on-premises site212.

The on-premises nodes262and cloud nodes412in this example include a busy status866and a down status864, as indicated in the status column810B. The nodes412are shown as having a 99% TTL (868), indicating that the nodes412have only gone through a small portion of the TTL configured for the nodes412before they are purged.

Referring toFIG.8E, view870illustrates a portion of the jobs in the workload screen from the workload tab (804) of the on-premises interface802now transitioned to a completed status834D. The queue in the on-premises site212as starting to reduce as more jobs are being processed after the nodes412from cloud202were provisioned to assist with eligible jobs in the on-premises site212. This represents improvements in the processing, performance, etc., of jobs in the on-premises site212and the benefits of the automatic bursting onto the cloud202.

Referring to view880inFIG.8F, after some time processing jobs, the nodes412provisioned from cloud202have now reached an idle status868, indicating that their corresponding jobs have been processed or completed. The completion of such jobs would have a significant impact on the queue of jobs or workloads at the on-premises site212and the performance of submitted jobs or workloads. The nodes262at the on-premises site212should have a much lower burden and may be capable of handling the remaining jobs in the queue (e.g.,258) at the on-premises site212without necessarily relying on, or utilizing, nodes from cloud202or other clouds.

As shown in view880, the provisioned nodes412from the cloud202have remaining TTL before they will be automatically purged. To reduce cost, a user may manually purge (e.g., deprovision, retire, destroy) one or more of the nodes412from the cloud202to save costs that may be incurred based on reservation time. In some cases, the system may also have a trigger to automatically purge the nodes412once the queue or backlog has been eliminated or reduced to a certain level despite another purge trigger (e.g., TTL) not being yet met. Thus, the purging process can include multiple purge triggers that can work together to optimize the reservation and usage of resources and purging of unneeded resources.FIG.9Billustrates some example purge or deprovisioning modes that can be implemented.

FIG.9Aillustrates a diagram of an example cloud bursting configuration system900for configuring a cloud burst function that dynamically spins up, takes offline, or shuts down nodes (e.g.,262,412,414,416,418,420) in a cloud computing environment (e.g.,200).

A multi-cloud bursting service (e.g.,340A,340B) can host a bursting configuration interface902that can be used to configure a cloud bursting service to dynamically perform specific cloud bursting operations based on one or more cloud bursting preferences, conditions and/or requirements. In some examples, the on-premises site212and/or a cloud provider can access the bursting configuration interface902to configure the cloud bursting service and manage jobs, nodes, clusters, queues, bursting preferences, etc.

In some examples, the bursting configuration interface902can provide a network operator access to cluster and cloud bursting information and statistics. Moreover, the bursting configuration interface902can include an option for enabling a cloud bursting service and configuring bursting operations based on one or more parameters/conditions such as, for example, a jobs in a queue904, any requirements of jobs in the queue904, available nodes in one or more clusters of nodes906,908,910, budgeting and costs considerations, SLA requirements, network conditions, etc.

In some examples, when the cloud bursting service is enabled via the bursting configuration interface902, the cloud bursting service can execute or implement a burst function configured to detect what jobs are in the queue904and automatically spin up, take offline, or shutdown any nodes in the cloud environment200depending on any requirements for the queue904and/or jobs in the queue904. For example, in some cases, if the burst function detects that there are not enough online nodes to run all jobs in the queue904, the bursting function can trigger a bursting operation to spin up or deploy as many nodes as needed to service the jobs in the queue904. The bursting function can determine how many nodes should be spawned or deployed based on one or more factors such as, for example, the number of jobs in the queue904, SLA requirements of the jobs in the queue904, network conditions, time parameters (e.g., time of day, day of week, etc.), current or predicted loads on existing nodes and/or cloud resources, job priorities, types of jobs in the queue904, and/or any other factors.

In some examples, if there are more nodes deployed and/or available than needed to service the jobs in the queue904, any excess nodes can be identified and taken offline to conserve resources and costs. In some cases, if or when queue904is empty, the bursting function can shut down all nodes. For example, if the queue904becomes empty, the bursting function can shut down nodes after a specified period of time.

In some implementations, the bursting configuration interface902can be used to run a single or one-time bursting operation and/or to configure a persistent bursting configuration906, a minimum-maximum bursting configuration908, or an on-demand bursting configuration910. In the persistent bursting configuration906, a persistent bursting operation914can run to spin up all or a portion of the licensed instances in an existing cluster260. The instances deployed or spawned can remain persistent for a period of time and/or until a termination event such as a change in loads, a change in the queue904, job completions, etc. In some cases, the persistent bursting operation914can bring nodes in the cluster260online or shut them down as needed.

In the minimum-maximum bursting configuration908, a minimum bursting operation916can run to spin up a minimum number of nodes in the cluster260needed (or estimated to be needed) to complete the jobs in the queue904. This can allow a network operator to better manage and control budgeting and cloud costs. Moreover, a maximum bursting operation918can run to spin up enough nodes in the cluster260to complete all the jobs in the queue904immediately and/or as fast as possible. This bursting configuration can be implemented to obtain high performance and/or faster job processing results. In another aspect, the system could perform a hybrid operation in which a minimum configuration is initiated until a certain point in the jobs queue occurs such as a large job scheduled to be processed at a certain time, prior to which a maximum configuration is implemented. The system could alternate between maximum and minimum bursts according to the configuration of the job queue. The maximum and minimum designations do not mean absolute maximum or minimum. The system may seek an appropriate or acceptable maximum or minimum value and not require a perfect maximum or minimum amount.

In the on-demand bursting configuration910, an on-demand bursting operation920can run to spin up a number of nodes in an isolated cluster912estimated to be needed to process a particular job on-demand. The isolated cluster912can be a new or existing cluster that is isolated from other jobs and thus not used to process other jobs. In other words, the isolated cluster912can be implemented specifically for the on-demand job being processed.

The particular configuration can be manually chosen or can be modeled via a machine learning model such that the characteristics of the job queue could be modeled to automatically select a bursting service for that queue.

Another aspect is shown in the configuration950ofFIG.9B. The bursting function can detect what jobs are in the queue960and automatically spin up, take off-line, or shut down a node or nodes depending on the total requirements of the queue960. If there are not enough on-line nodes to run all the jobs, the bursting function will bring on-line as many nodes as are needed. If there are more nodes than needed, the excess nodes can be taken off-line. This approach enables users to only pay for what is in use and provides bursting at the lowest possible cost.

When the bursting service is enabled952, a minimum burst configuration956can be selected as part of an existing cluster954. In this scenario, the system spins up the minimum number of compute nodes required to complete all the jobs in the queue. This is an ideal option for budgeting and controlling cloud costs. The user interface902as shown inFIG.9Acan be used to initiate or configure the service. In a maximum burst scenario958, the system spins up enough compute nodes to complete all the jobs in the queue immediately or as soon as possible. This option is designed for getting processing results as fast as possible. In one aspect, another mode could also be utilized which could seek to predict what jobs may be placed in the queue (but are not there yet) and spin up a minimum or maximum amount of nodes based not only on jobs in the queue currently but a prediction of what jobs may be added to the queue or removed from the queue.

When the bursting service is off as is shown in the configuration962, a persistent mode can be provided964which spins up all or a portion of the licensed instances in a cluster966that remains persistent.

FIG.9Bshows an on-demand configuration968in which a new cluster978can be created for one or more jobs in the job queue960. In the on-demand scenario970, there are several options regarding how the system can configure the new cluster978. These options can relate to how to purge or deprovision the cluster978in one or more selected mode. In one option “A”972, the head node will stay active in compute nodes are destroyed. In another option “B”974, the head node stays active and the compute nodes are taken off-line. In a third option “C”976, the full cluster is destroyed including the head node. The additional capability of more specifically define a deprovisioning mode enables users to more particularly control which type of on-demand cluster to generate or to define optional deprovisioning steps to implement when the use of the on-demand cluster978is finished. The user interface902shown inFIG.9Acan be modified to include the ability of a user to select which option regarding how to handle the head node and compute nodes. In another aspect, a machine learning model can be trained as part of a workload manager that can automatically select one of the options972,974,976based on any number of factors such as one or more of historical data, a configuration of the job queue960, a number of jobs in the job queue960, energy requirements, contractual SLA obligations, quality requirements, cost of resources, predicted behavior of the new cluster, available nodes, and so forth. The selection of the option972,974,976can be made at the initiation of a new cluster978, or part way through the processing performed by the new cluster978, or near the end of processing a job or jobs from the job queue960by the new cluster978. The process may be dynamic in that circumstances regarding the compute environment968, the job queue960, or other factors can cause the system to determine which mode to apply972,974,976as a job is being completed by the new cluster978. If the various parameters are less dynamic, then the decision about which mode972,974,976to apply can be made earlier.

As noted above, whether to choose option “A”, “B” or “C” can depend on any number of factors. For example, the particular duration of jobs in the job queue960can cause the system to generate an on-demand cluster configured according to one of the options. For example, if there is a first job in the job queue960that requires a new cluster978to be created, and there are no other jobs in the job queue that are likely to need or could utilize the new cluster978, the system can establish a shutdown procedure is an option “C”976the full cluster to be destroyed including the head node. However, if there is a strong possibility that a later job within the queue might be able to utilize the new cluster978, then the system may, after completing the first job, implement option “B”974in which the head node stays active in the computing nodes go off-line. In this scenario, the system could quickly and efficiently bring compute nodes back online and use the same head node that is active for processing the later job.

In another scenario, the assume that the job configuration of the job queue960includes a first job to be processed by the new cluster978and a relatively small possibility of a later job in the job queue960needing to use the new cluster. In this scenario, option “A”972might be selected in which the head node stays active with the compute nodes are destroyed. This would free up the compute nodes for other clusters or other jobs. In this scenario, if the later job does need to be processed and my use the new cluster978, at least the head node has stayed active and can be utilized to create new compute nodes for processing the later job.

The selection of the various options can be performed manually or automatically. The system can also train machine learning models such that an intelligent decision can be made regarding which option to select when operating an on-demand compute environment968based on any one or more factors such as the configuration of the on-demand compute environment968, the configuration of the job queue960, costs of compute resources, SLA requirements, timing requirements, size of jobs, geographic considerations, and so forth.

Having disclosed example system components and concepts, the disclosure now turns to the example methods1000and1100shown inFIGS.10and11. For the sake of clarity, the methods1000and1100are described in terms of cloud computing environment200, as shown inFIG.2A, and multi-cloud bursting service340A, as shown inFIG.4. The steps outlined herein are examples provided for explanation and can be implemented in any combination thereof, including combinations that exclude, add, or modify certain steps.

With reference toFIG.10, at block1002, multi-cloud bursting service340A can generate and/or store one or more cloud agnostic burst templates (e.g.,406) for bursting one or more workload environments on different clouds (e.g.,202-210). Each cloud agnostic burst template can include a stack template (e.g.,600) and/or a job template (e.g.,650). Moreover, each cloud agnostic burst template can define a stack for a workload environment and tasks (e.g.,610-620) for provisioning one or more cloud resources (e.g., cloud nodes412,414,416,418, and/or420) and deploying, on the one or more cloud resources, the workload environment associated with the stack.

The stack can include or define one or more applications, one or more libraries, one or more services, an OS (e.g., a base operating system for the workload environment), and/or data (e.g., files, packages, data blocks, etc.). The stack can be used to generate the workload environment or an image of the workload environment. In some examples, the workload environment can be an execution environment, which can include an OS, one or more applications, one or more libraries, one or more services, data, etc. For example, the workload can be a server environment, a VM (virtual machine), a software container, a software package, an application or service, etc.

At block1004, multi-cloud bursting service340A can receive from a local compute environment (e.g., on-premises site212), a request (e.g.,404) to burst a workload environment onto a cloud (e.g.,202) from the different clouds (e.g.,202-210). The request to burst the workload environment can be for provisioning resources, such as nodes, and processing a submitted workload or job request at the local compute environment. Moreover, the request can be generated in response to a specified trigger (e.g.,402). For example, a cloud bursting request for reserving or allocating cloud resources for a job can be generated in response to a trigger specifying that such request is to be issued when a backlog reaches a threshold (e.g., x number of backlog jobs), when a workload queue (e.g.,258) reaches a threshold size, when a capacity at the local compute environment or a number of active or available resources reaches a threshold, when a policy violation is detected (e.g., QoS violation, SLA violation, performance requirement, security requirement, reliability requirement, etc.), when a limit is reached (e.g., a maximum latency, a maximum acceptable job processing or completion time, a maximum average performance degradation, etc.), when a spike is encountered, when an error or failure is encountered, when a capacity is deemed insufficient, etc.

The request from the local compute environment can specify a job or workload associated with the request, and may indicate that one or more resources (e.g., cloud nodes) need to be provisioned for the job or workload. In some examples, the request may also specify what cloud is to be used for provisioning the requested resources. The request may also specify other parameters, such as a timeout parameter, a cost parameter, a performance requirement, a job priority, a QoS requirement, a SLA, a reservation time for the requested resources, a bursting budget, a purge time or condition (e.g., a job TTL, a resource idle time that should trigger purging, an indication that a resources should be purged upon completion of a job or an increase of available resource at the local compute environment, etc.), a type and/or number of cloud instances for bursting, a variable or value to be used for the bursting, etc.

Based on the cloud agnostic burst templates, at block1006, multi-cloud bursting service340A provisions (e.g.,410) the cloud resources (e.g., cloud nodes412) from the cloud (e.g.,202), and at block1008multi-cloud bursting service340A deploys the workload environment on the cloud resources. For example, multi-cloud bursting service340A can use the cloud agnostic burst template, which defines a stack for the workload environment and tasks for provisioning the workload environment, to reserve the cloud resources, create an image of the workload environment and deploy it on the cloud resources. Thus, the cloud agnostic burst template can define the necessary provisioning tasks and dependencies.

In some cases, the tasks can provide instructions (e.g., commands) and/or scripts for reserving nodes; obtaining the necessary data (e.g., files, packages, etc.) for the provisioning; installing the necessary OS, applications, libraries, tools, configuration files, services, execution scripts, etc.; configuring the OS, applications, services, and/or overall environment; launching a cloud instance with the workload environment; and configuring the instance to process jobs or workloads for the local compute environment.

The bursting described at blocks1006and1008can be implemented using stack and/or job definitions, such as stack template600and job template650, for automating the process. The stack and job template(s) can be in a single file, such as a single cloud agnostic bursting template file, or multiple files, such as multiple cloud agnostic bursting template files. For example, the stack and job templates can be in different JSON files defined for bursting across multiple cloud providers, which may run different cloud solutions, platforms, configurations, architectures, resources, etc. In some cases, the cloud agnostic bursting template can include a stack and/or job definition in one or more files and include references to other files or objects used in the process, such as scripts, packages, directories, mounts, utilities, executable code, etc.

The tasks defined for the bursting in the stack and job definitions can be translated by multi-cloud bursting service340A into commands for provisioning the cloud resources from the specific cloud and launching the cloud instance(s) (e.g., workload environment) on the provisioned cloud resources. The translated commands can be specific to the cloud provider selected for bursting. As previously mentioned, different cloud providers run different clouds (e.g.,202-210) which may run different cloud solutions and have different configurations, platforms, resources, architecture, programming languages, execution environments, requirements, or other characteristics. Accordingly, the commands, software (e.g., applications, OS, programming languages, utilities, etc.), libraries, hardware configurations, protocols, syntax, dependencies, etc., for provisioning/bursting can vary between cloud provider (e.g., clouds202-210). Multi-cloud bursting service340A can thus use the cloud agnostic bursting templates to define (or abstract) the provisioning/bursting tasks and dependencies, and perform a translation process to generate the commands, configurations, etc., suitable for provisioning/bursting at the specific clouds (202-210) in view of the aforementioned distinctions between cloud providers.

Once the bursting request is completed and the cloud instances are launched, the specific jobs or workloads can be processed via the provisioned cloud resources for the local compute environment. In some cases, the provisioned resources can work along with local resources as if the cloud and local resources are part of the local compute environment. For example, the provisioned cloud resources can be added to a cluster (e.g.,260A) of nodes on the local compute environment, and together operate and appear as a single cluster of local nodes. The local compute environment can view and manage the jobs or workloads as well as the local and cloud nodes from a graphical user interface (e.g.,802). Through the graphical user interface, a user can add or remove cloud nodes, add or modify templates, release resources or instances, start or stop jobs, manage the local workload queue, configure bursting configurations, etc. The multi-cloud bursting service340A can communicate with the local compute environment and the various clouds (e.g.,202-210) to coordinate information, requests, and operations, including orchestration or resources and scheduling of jobs. The multi-cloud bursting service340A can communicate with the various clouds and/or the local compute environment through an API, for example.

With reference toFIG.11, at step1102, a cloud bursting service (e.g.,340A,340B) can receive a cloud bursting configuration associated with a local compute environment (e.g.,212). The cloud bursting configuration can enable the cloud bursting service for dynamically performing cloud bursting actions for the local compute environment. The cloud bursting actions can include, for example, taking offline one or more existing nodes (e.g.,262,412,414,416,418,420), shutting down one or more existing nodes, spinning up one or more new nodes, etc.

In some cases, the cloud bursting configuration can define a persistent cloud bursting setting (e.g.,906), a minimum-maximum cloud bursting size setting (e.g.,908), and/or an on-demand cloud bursting setting.

In some examples, the persistent cloud bursting setting can instruct the cloud bursting service to spin up at least a portion of all licensed nodes associated with the local compute environment for a period of time and/or persistently.

In some cases, the minimum-maximum cloud bursting size setting can specify a minimum cloud bursting size or a maximum cloud bursting size. The minimum cloud bursting size can include a minimum number of nodes needed to process all jobs in the jobs queue without a threshold delay in processing at least one job in the jobs queue, at least one available node being unassigned to at least one job in the jobs queue, and/or waiting for an unavailable node to become available to process at least one job in the jobs queue. In some examples, the maximum cloud bursting size can include an estimated number of nodes needed to complete all jobs in the jobs queue in a fastest amount of time and/or immediately.

In some cases, the on-demand cloud bursting setting can instruct the cloud bursting service to spin up an estimated number of nodes needed to run a particular job without waiting for an unavailable node to become available. The on-demand cloud bursting setting can specify that the estimated number of nodes should be provisioned on an isolated cluster (e.g.,912) that is not shared with other jobs.

Moreover, in some examples, the cloud bursting configuration can be defined by a network operator via a bursting configuration interface (e.g.,902). For example, a network operator can define the persistent cloud bursting setting, the minimum-maximum cloud bursting size setting, and/or the on-demand cloud bursting setting via bursting configuration interface902.

At step1104, the cloud bursting service can determine, in response to the cloud bursting configuration enabling a cloud bursting service for the local compute environment, a state of a jobs queue (e.g.,904) associated with one or more cloud environments from a plurality of cloud environments (e.g., clouds202-210). The one or more cloud environments can include, for example, one or more clusters of resources, one or more cloud networks, one or more workload environments, etc.

The state of the jobs queue can indicate a number of jobs in the jobs queue (if any), a status of any jobs in the jobs queue, one or more parameters (e.g., an SLA requirement, a job priority, a job preference, a quality-of-service requirement, a performance requirement, a type of job, etc.) associated with any of the jobs in the jobs queue, and/or any other information about any jobs in the jobs queue.

At step1106, the cloud bursting service can determine a number of nodes (e.g.,262,412,414,416,418,420) available in the one or more cloud environments to process the number of jobs in the jobs queue.

At step1108, the cloud bursting service can determine, based on the state of the jobs queue and the number of nodes available in the one or more cloud environments, whether to spin up a new node on the one or more cloud environments to process one or more jobs for the local compute environment, take offline an existing node on the one or more cloud environments that is associated with the local compute environment, or shutdown one or more existing nodes on the one or more cloud environments that are associated with the local compute environment, to yield a determination.

At step1110, the cloud bursting service can perform, based on the determination and the cloud bursting configuration, a cloud bursting action associated with the local compute environment. The cloud bursting action can include spinning up the new node on the one or more cloud environments, taking offline the existing node on the one or more cloud environments, and/or shutting down the existing node on the one or more cloud environments.

In some aspects, determining whether to spin up the new node, take offline the existing node, and/or shutdown the existing node and performing the cloud bursting action can include determining whether the number of nodes available in the one or more cloud environments lacks enough available nodes to process all jobs in the jobs queue within a certain period of time or without waiting for an unavailable node to become available; when the number of nodes available lacks enough available nodes to process all jobs in the jobs queue within the certain period of time or without waiting for the unavailable node to become available, spinning up the new node on the one or more cloud environments; and assigning one or more jobs in the jobs queue to the new node on the one or more cloud environments.

In some aspects, determining whether to spin up the new node, take offline the existing node, and/or shutdown the existing node and performing the cloud bursting action can include determining whether the number of nodes available in the one or more cloud environments exceeds a number of nodes needed to process all jobs in the jobs queue without waiting for an unavailable node to become available and/or without a threshold delay (e.g., a predefined period of time, an amount of idle time, an occurrence and/or completion of an event, etc.). When the number of nodes available exceeds the second number of nodes needed to process all jobs in the jobs queue, the method can include taking the existing node offline.

In some aspects, determining whether to spin up the new node, take offline the existing node, and/or shutdown the existing node and performing the cloud bursting action can include, when the state of the jobs queue indicates that the jobs queue is empty, shutting down the one or more existing nodes associated with the local compute environment. In some examples, the one or more existing nodes can include all existing nodes on the one or more cloud environments that are licensed and/or assigned to the local compute environment.

In some cases, determining whether to spin up the new node, take offline the existing node, or shutdown the existing node can be further based on one or more job parameters. The one or more job parameters can include, for example, a quality-of-service parameter associated with one or more jobs in the jobs queue, a node usage limit, a cloud bursting limit, a cloud bursting trigger, a purge condition defining a time-to-live and/or a node idle purge time, etc. In some cases, the cloud bursting trigger can include a threshold backlog, a threshold node availability, a policy violation, a threshold condition, etc.

FIG.12illustrates another example method related to the selection of an optional configuration for an on-demand compute environment968. The example method includes one or more of the following steps or operations in any order. The method can include, at step1202, receiving, via a cloud bursting service associated with a plurality of cloud environments, a cloud bursting configuration associated with a local compute environment, the cloud bursting configuration enabling the cloud bursting service for the local compute environment, wherein the cloud bursting configuration defines an on-demand cloud bursting setting, at step1204, in response to the cloud bursting configuration enabling the cloud bursting service, determining a state of a jobs queue associated with one or more cloud environments from the plurality of cloud environments, the state of the jobs queue indicating a number of jobs in the jobs queue, at step1206, determining a number of nodes available in the one or more cloud environments to process the number of jobs in the jobs queue, and, at step1208, based on the state of the jobs queue and the number of nodes available in the one or more cloud environments and based on the on-demand cloud bursting setting, establishing an on-demand cluster having a chosen mode from a group of modes related to how to manage a head node of the on-demand cluster and compute nodes in the on-demand cluster. The chosen mode can, in one aspect, relate to different ways to spinning down or ending the on-demand cluster. In another aspect, the chosen mode identifies at least one of how and when to deprovision or purge one or more of the head node and a compute node(s) in the on-demand cluster.

In one aspect, the chosen mode relates to a first mode in which the head node of the on-demand cluster stays active and compute nodes are destroyed, a second mode in which the head node stays active and compute nodes go off-line and a third mode in which the full cluster is destroyed including the head node. The choice of which mode to use for the on-demand cluster can be based on one or more factors, such as data about the jobs in the queue, a prediction of future jobs to be entered into the job queue, historical data, cost, energy usage, geographic location of physical nodes in the on-demand cluster, a timing related to the processing of a compute job by the cluster, and so forth.

Embodiments within the scope of the present disclosure may also include tangible computer-readable storage media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable storage media can be any available media that can be accessed by a general purpose or special purpose computer, including the functional design of any special purpose processor as discussed above. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions, data structures, or processor chip design. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or combination thereof) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of the computer-readable media.

Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, components, data structures, objects, and the functions inherent in the design of special-purpose processors, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.

Those of skill in the art will appreciate that other embodiments of the disclosure may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Although the above description may contain specific details, they should not be construed as limiting the claims in any way. Other configurations of the described embodiments are part of the scope of this disclosure. For instance, while the principles disclosed herein are generally discussed in terms of a public cloud, a private cloud412can also receive workloads from a private multi-cloud bursting service. The principles herein are applicable to all cloud compute environments. Those skilled in the art will readily recognize various modifications and changes that may be made to the principles described herein without following the example embodiments and applications illustrated and described herein, and without departing from the spirit and scope of the disclosure.