KR20210008924A - Integrated multi-vendor computing platform - Google Patents

Abstract

The present invention encompasses embodiments of systems and methods for resolving interdependencies resulting from integrating computing resources from multiple hardware and software providers. The integrated multi-vendor cloud-based platform of the present invention uses an abstraction layer to communicate and consolidate resources of multiple backend hardware providers, multiple software providers, and multiple license servers. This layer of abstraction and related functionality not only eliminates the need for users to implement and configure provider-specific protocols, but also requires resolving interdependencies between selected hardware, software, and license servers, either on a task-level basis or at other levels of granularity. Do not.

Description

Integrated multi-vendor computing platform

Cross-reference to related applications

This application is a continuing applicant of the US regular patent application No. 15/235,004 filed on August 11, 2016 under the name "Dynamic Optimization of Simulation Resources", the serial number of the US patent application filed on June 14, 2018. Claims priority to 16/008,465, the disclosure of which is incorporated herein by reference as if fully described herein.

The present invention relates generally to a cloud-based platform, and in particular, interdependency resulting from integrating third-party back-end hardware with third-party software across a number of providers to end users. To solve, it relates to a cloud-based computing platform.

Beginning with the advent of supercomputing in the 1960s, "High Performance Computing" (HPC) tasks belonged to high-performance, expensive computer systems that only large enterprises could afford. HPC tasks are sometimes narrowly defined as requiring large amounts of computing resources over relatively short periods of time (in Wikipedia and elsewhere).

This definition makes it possible to distinguish it from other forms of super computing (HTC or “high throughput computing”, grid computing, MTC or “mass task computing” and others). As used herein, the term HPC refers to whether a job consists of a single task or a number of dependent and independent tasks, or the cost, purpose of computing resources, the time required to complete an individual task or an entire job, or other factors. Regardless of whether it is optimized for, it is used more broadly to include almost any form of super computing that, although temporary, requires significant computing resources.

The PC revolution of the 1970s caused a change in the usual paradigm of client-server computing. Computing, from server-based extremes (users of "dumb terminals" running time-sharing tasks through remote mainframes and other high-performance servers), to client-based extremes (primarily local via progressively more powerful personal computers). (Users performing tasks), and eventually to a hybrid form of client-server computing that allows hosting a combination of hardware, software and networking services over a distributed network such as the Internet.

In this hybrid client-server environment, computing resources and functions are allocated in a number of different ways across the hosting server and end user clients. Yet, HPC tasks are still limited to server-based extremes because they require high-performance computing resources that are typically not available even through personal computers or even more powerful single servers.

With the advent of cloud computing in the mid-2000s, HPC functions became much more widely accessible and affordable to individuals and small businesses as well as large enterprises. Remote “on-demand” access to large amounts of computing resources has significantly reduced costs by distributing the functionality of “high-demand” tasks across a wide range of networked physical and virtual computing resources. (And expanded the connection accordingly). In addition, cloud computing provided hybrid client-server solutions in many other situations, but provided a unique “distributed server-based” solution to the HPC region.

However, cloud computing was not the all-round solution for HPC users. Compared to typical client-server and remote desktop applications, significant problems remain due to the relative complexity of HPC operations. For example, prior to cloud computing, large enterprises purchased or rented expensive, high-performance servers and other computing resources and operated them on their own premises. Companies have the flexibility to choose computing resources that match their specific requirements, but in many cases it has been difficult to justify the indirect cost of such computing resources. The highest performance computing resources were needed only for certain computing-intensive tasks, and sometimes only for certain parts of those tasks. Essentially, the company had to plan for the "worst case scenario".

Large enterprises, relying on their own "on-premise" hardware, often gave up access to the latest computing resources. Hardware purchased or leased is typically replaced at the end of its lifecycle, and by that point it is several years old, lagging the latest technology by more than a generation.

Moreover, end users were required to install and configure each third-party software package licensed from a third-party “independent software vendor” or ISV on their hardware. Unlike installing traditional desktop applications that only need to make sure you have the correct operating system, installing compute-intensive software is a more complex process due to the nature of HPC functionality. Often such software runs in parallel, and multiple instances of the software run across multiple CPU cores and often across multiple physical servers. Each task requires a unique configuration that matches the requirements of the software to the hardware environment, including task-specific attributes regarding the user's computing model.

End users, completely independent of the complexity of sharing the computing resources of their hardware environment with other end users in the enterprise running tasks in parallel, can address these hardware-software dependencies by matching the requirements of each task to the hardware environment. Was responsible for solving it. In addition, the end user was solely responsible for testing or “tuning” the software and hardware environment, and creating “workflows” across and within individual jobs (eg Extract and analyze intermediate and final results; possibly based on various conditions, and many other more complex in-task and inter-task functions, combining multiple tasks in which the output of one task serves as an input to subsequent tasks) . In this regard, the terms work flow, job, and task are used somewhat interchangeably, but a work flow typically refers to one or more jobs, each job being made up of one or more individual HPC tasks.

Introduced, such as Amazon's AWS ("Elastic Compute Cloud" or Amazon Web Services including EC2), Microsoft's "Azure", and Google's "Google Cloud Platform (GCP)" Public cloud services also partially solved this problem. These public cloud platforms are often described as "infrastructure-as-a-service" or laaS. That is, these "backend hardware providers" provide remote access to physical and virtual computing environments, eliminating the need to purchase or lease hardware computing resources for worst-case scenarios. Since these computing resources can be accessed remotely on an on-demand basis, cost can be greatly reduced.

In addition to public cloud providers, other back-end hardware providers are "private cloud", often sacrificing virtualization capabilities (and thus some level of security) for high-performance "bare metal" hardware designed for demanding HPC applications. private cloud)" or "private data center". Provisioning of physical servers, for example, allows the use of faster networking techniques for intra-task communication, as these servers can be tightly coupled given their proximity to each other. As with public cloud services, the bare metal provider's computing resources can be accessed remotely on an on-demand basis, saving money.

However, regardless of whether an enterprise uses a public cloud or a private data center (or a combination of these, including their own physical hardware), HPC tasks, and the various attributes of the hardware and software environment in which they run Due to the interdependencies between the two, most of the other problems mentioned above still remain. HPC users are still responsible for choosing a physical or virtual hardware environment that best addresses their needs.

For example, if certain tasks require the latest bare metal hardware (often at a premium), while others require the flexibility of virtualization, the user has to sacrifice one for the other, or multiple The complexity of contracting with different backend hardware providers has to be added. Also, the user still has to manage the differences between each such hardware environment. Many cloud providers offer virtual "core types" with a specified amount of available computing resources, such as CPU cores, memory, storage, and network bandwidth. On the other hand, bare metal providers offer more limited (but often more powerful) options for computing resources based on the characteristics of their physical servers.

Despite these options, users cannot simply specify their computing resource requirements with a higher level of abstraction, and they cannot have those requirements automatically allocated among the different types of computing resources available from multiple backend hardware providers. . They are often responsible for making such decisions themselves, often through incomplete information. HPC users focus on their own needs, not on frequently changing supplies from various backend hardware providers. Also, for any given company, there is no large amount of usage across multiple suppliers needed to perform the most cost effective pricing.

HPC users can also "mix and match" the computing resource requirements of any particular task (including their own on-premises hardware) with computing resources provided across multiple backend hardware providers. Give up function. For example, they cannot run tasks that take advantage of the high-performance computing power of bare metal providers or cloud providers, along with their own existing storage. In short, there is no integration between many different backend hardware providers. In addition to determining and managing the hardware environment, HPC users must also acquire rights to run specific software in a remote cloud environment. In addition, they not only have to install and configure software for each task, but also match the requirements of a particular task (and associated software) with an appropriate amount of compatible hardware computing resources.

They often have to test or "tune" the software and hardware before executing complex, time-consuming, and costly HPC tasks, as well as develop their own tools to implement custom workflows. Simply put, they share data across clusters and physical servers, manage communication between clusters and servers, provide data security and privacy issues beyond those provided by backend hardware providers, contracts, regulatory and other legal requirements, And it must manage all the dependencies of each task on the provisioned hardware and software environment, including managing the HPC environment to comply with many different aspects of the complex HPC task.

In addition, each ISV provides its own software license restrictions, typically by enforcing authentication and license management through a third-party “license server”. Each ISV may impose different restrictions on the location and access of its license server. Again, the HPC user is responsible for obtaining rights and providing an interface with each associated license server (wherever such a license server can be physically located).

Backend hardware providers "measure" the usage of provisioned clusters (or other units of hardware resources), but HPC users say that they are responsible for the cost of these laaS resources on a per task or other basis (at a higher or lower granularity level). If you want to monitor them, you have to implement their own custom "task-specific" measurements. In addition, if they want to measure the usage of the software (for example, to estimate the relative licensing costs), they must provide their own custom measurement implementation.

In an effort to address some of these issues, several vertical solutions have emerged that provide "software-as-a-service" or SaaS solutions rather than laaS solutions provided by public and private cloud providers. I did. For example, in addition to providing laaS functionality, some large ISVs have integrated their own software with the backend public cloud or their own hardware infrastructure. This "ISV Cloud" provides their software users with a remote hardware platform for executing HPC tasks.

However, users of these ISV clouds are limited to a single software provider, which is a significant limitation that does not take into account users who need a wider variety of software choices. In addition, users still need to resolve many of the aforementioned dependencies with respect to software and hardware coordination and workflow, as well as providing, installing and configuring their own proprietary or third party software, even if permitted by the ISV cloud provider. And management difficulties must be resolved.

Other vertical solutions provide their own laaS environments (whether directly or through a single third-party cloud provider), but through access to specific third-party software packages. This "HW Cloud" also has many of the same limitations as described above. While offering end users a choice of software, their solutions are limited to the computing resources provided by a single back-end hardware environment. These significant limitations prevent users from using, for example, more powerful servers available only from bare metal providers, or more cost-effective solutions offered by other cloud providers.

By providing a remote platform to HPC users, a true "platform-as-a-service", allowing them to choose from multiple backend hardware providers and multiple ISVs, while automatically resolving interdependencies between these hardware and software environments. There is a need for an integrated computing platform that provides an as-a-service)"(PaaS) function and solves the shortcomings of the existing solutions described above. In addition, such an integrated computing platform must resolve the dependency of software and other attributes of HPC operations on the selected hardware environment.

The present invention provides a cloud-based computing platform using an abstraction layer for communicating with and integrating resources of a plurality of backend hardware providers, a plurality of software providers, and a plurality of license servers, thereby solving the above-mentioned drawbacks. And embodiments of the method. This layer of abstraction and related functionality not only eliminates the need for users to implement and configure provider-specific protocols, but also eliminates the need to resolve interdependencies between selected hardware, software and license servers, either on a task-level basis or at other levels of granularity do.

The platform of the present invention automatically distributes computing resources (including on-premises customer resources) between hardware, software, and license servers among multiple providers according to higher-level user selection based on individual work and work flow requirements. Select by For a given task defined by the user, the platform automatically connects with one or more backend hardware providers to provision computing resources.

In one embodiment, the HPC user requests a core type from a specific backend hardware provider, while in another embodiment, the user's higher-level computing resource selection is based on the user's predefined goals (e.g., cost, performance Time, specific computing resources, etc.), translated into low-level requests to one or more backend hardware providers selected by the platform. In another embodiment, the platform automatically generates a suggested computing resource selection based on an analysis of the user's requirements verified from the user's model and other input parameters.

In one embodiment, the backend hardware provider includes a number of public cloud providers and private data centers, as well as computing resources located on the premises of the HPC users themselves (different implementations within the platform's backend hardware abstraction layer). All can be accessed through API). For example, an HPC user's tasks can be executed through a server within a public cloud provider, using a networked repository located on the user's premises. Alternatively, the user's server can be supplemented with the additional computing power of those provided by the cloud provider.

This integration of specific computing resources (including HPC users' on-premises computing resources) across multiple back-end hardware providers provides a level of flexibility that has not been previously seen in any HPC environment. HPC users do not have to worry about communication between providers and, for example, data transfer between computing resources in different hardware environments (since such tasks are handled automatically by the platform).

In addition, the platform automatically installs and configures the selected software into the provisioned hardware environment (in some cases, across multiple different hardware providers) according to the user's specified configuration and input data. The platform further establishes a connection with the relevant license server through the relevant license file (including the license key) that manages the user's access to the related software and its components, and the usage of the related software and its components. do.

The platform allows the construction of a single HPC task (e.g., running a single simulation software package for a user's model), as well as the construction of more complex tasks, including multiple tasks performed sequentially or in parallel. It also provides the user with a workflow tool to enable it. For example, the output of one or more tasks may be provided as input to a subsequent task or task, or individual tasks or tasks may be repeated using different parameters. Workflows include loops, conditions, and other control flow computing constructs.

In addition, hardware and software "tuning" tools are provided to users, with hardware and software "tuning" tools that allow users to test a single task or specific part of a task, and the time to execute complex tasks or workflows. Before incurring costs, based on the results, computing resources and other attributes of the hardware and software environment can be reconfigured. Since many tasks require significant amounts of computing resources to be used over a large amount of time (or sometimes days, weeks or longer), major parts of the task (especially those that are repeated many times) must be tested in advance, and then the initial hardware and software Through the ability to iteratively modify the configuration, both before and during the execution of complex workflows, it saves significant time and money for users.

In one embodiment, the platform, based on the results of hardware and software adjustments, hardware computing resources and/or software configuration in an effort to best match the available computing resources with the requirements of the HPC user's work or workflow. Suggest an option. These requirements are estimated from the analysis of the user's model, input data, and intermediate results that coordinate the "test run".

In one embodiment, while the user's workflow is running, the platform (depending on the user's workflow configuration) monitors intermediate results, repeating or conditionally performing selected tasks, or even (e.g., such intermediate results Initiate specific actions, such as stopping execution of a work flow) to prevent wasted computation in case of a catastrophic error detected based on In another embodiment, the platform (according to the HPC user's workflow, including conditions, loops, and other flow control components) invokes analysis software to perform analysis of intermediate and final results. In other embodiments, the platform discovers patterns among the outputs of similar tasks and workflows (e.g., via supervised machine learning technology) and uses them to make various suggestions, such as different allocations of hardware or software computing resources. Support.

The platform enforces license server restrictions based on license files provided by the user or generated by the platform. For example, the license file may restrict a user's access to specified functions of the software package. The platform connects to the associated license server through a license server abstraction layer that enforces these restrictions.

The platform further includes a hardware and software measurement module that monitors the execution of the user's workflow through the provisioned hardware environment. In one embodiment, such monitoring is performed with the granularity of individual tasks as well as more complex tasks or workflows. In addition, because a workflow (or component job or task) can run across multiple backend hardware providers, such monitoring tracks a specified component of a user's workflow, each of which is separately by a different backend hardware provider. Can be measured. Even these measurements extend, in one embodiment, to the on-premises hardware of HPC users, which typically do not have the measurement function itself.

While individual backend hardware providers may not be able to differentiate one user's workflow or tasks from another, the platform (in one embodiment) is the usage of each resource associated with the user's workflow (or component task or task). For the purpose of monitoring, tracking the use of individual hardware resources (e.g., CPU cores, memory, storage, network bandwidth, etc.). These usages are then correlated with different pricing schemes (e.g. set by different public cloud providers) to calculate rates and enable billing for users, their businesses, partners or other entities. .

It should be noted that the "customer" of the backend hardware provider may be the supplier of the platform of the present invention, or (in other embodiments) a third party partner, ISV, or even an individual HPC user or enterprise. For example, a company may choose its own cloud account for the execution of its users' workflows (or components thereof), or it may choose a public or private cloud account of a platform provider's third-party partner. In any case, the platform tracks hardware usage at a level of granularity sufficient to support virtually any desired pricing and billing mechanism by monitoring the execution of workflow components across multiple backend hardware providers.

In addition, the hardware and software measurement module supports monitoring the usage of HPC users for individual software packages or components thereof (at the work flow or work level, or in fact, at any other level of granularity). This measurement is made possible by the management of connectivity with the remote license server, and the connection with the remote license server is monitored by the platform. These monitoring capabilities extend beyond simple "checkout" and "checkin" events, and are also used as a basis for on-demand measurement and pricing of software usage.

In another embodiment, such monitored usage information is used as a basis for optimizing the goals of HPC users. For example, faster hardware can generally be more expensive, while slower hardware can lead to increased software licensing costs. The platform optimizes the HPC user's specified goals and makes suggestions for future work or workflows (or in the case of hardware and software tuned "run tests" in advance). In another embodiment, results-based pricing is supported, as the platform not only monitors usage of specific software (or component functions), but also user-specific results.

It should be noted that even if the user's workflow includes only the execution of a single software package through the hardware environment of a single back-end hardware provider, the software execution time may only be a subset of the hardware execution time. For example, a backend hardware provider may charge for hardware usage from the moment a cluster of hardware is provisioned (until de-provisioned) (only a fraction of that time is required to actually run the software). Even if included). Additional "hardware usage" time may be required to configure and launch instances of the software and extract results.

For more complex workflows, "software usage" time is allocated across multiple clusters or physical servers, multiple backend hardware providers, and multiple software packages (and their component functions). Again, the platform's hardware and software measurement modules monitor this "software usage" with a desired level of granularity sufficient to support virtually any desired pricing and billing mechanism.

Another embodiment (described in more detail in U.S. Patent Application Serial No. 15/235,004, filed August 11, 2016 under the name "Dynamic Optimization of Simulation Resources", the disclosure of which is incorporated herein by reference) In, the platform also monitors the use of computing resources during execution of a task or workflow, and dynamically optimizes these resources to provide a mechanism for resolving inter-instance dependencies.

The platform further includes a billing layer and related functions, along with hardware and software measurement modules, the platform's support for a variety of different pricing schemes, and a number of different entities (individuals, HPC companies, ISVs, third-party partners, etc.) Enables detailed allocation of usage for invoicing to. In one embodiment, the platform is based on on-demand pricing based on measured usage or consumption, as well as results based, advance deposit, subscription, per-seat, concurrent users, and various provider entities. It supports the calculation of rates, which are also based on other pricing models adopted by.

When running HPC jobs and workflows remotely in a cloud-based environment, taking into account the increased importance of data privacy and security issues, the platform is consistent across multiple different backend hardware environments (at the time of provisioning and deprovisioning). , And at computing time) by encrypting the data, providing an additional layer of data privacy and security. These encryptions further enhance (and are fully compatible with) all levels of security offered by different backend hardware providers. The platform further includes certain "data management" interfaces that handle different data structures and protocols used by different backend hardware providers.

Compared to existing solutions, the advantages of the platform of the present invention are numerous. HPC users and enterprises are provided with increased flexibility to match the requirements of their work and workflow with the computing resources provided by multiple back-end hardware providers and multiple software providers. However, they retain the flexibility to utilize their existing on-premises computing environment (including "bring-your-own" or BYOL licensed and proprietary software, as well as on-premises computing and storage resources).

In addition, the platform includes selected hardware and software (including license servers), to the extent that HPC users "mix and match" different computing resources (including on-premises hardware and software resources) even across multiple hardware and software providers. It does not require integration and configuration. Even within the environment of a single backend hardware provider, HPC users do not have to worry about provisioning and deprovisioning clusters of individual "virtual machines" (VMs), and launching instances of software across these VMs.

Workflow and hardware and software tuning tools are provided to HPC users that provide increased flexibility when defining complex workflows, as well as minimize the resulting time and cost (or other optimization factors) of executing these workflows. . Hardware and software measurements provide a convenient mechanism to support a variety of current and future pricing, licensing, and billing schemes, as well as efficiently managing the HPC workflow and the time and cost of executing tasks. In addition, they further improve the flexibility and robustness of individual HPC workflows and tasks by allowing the execution of conditional outcome-based actions (for execution and pricing purposes), both during and after execution of the HPC workflow or task. .

In short, through the integrated platform of the present invention, HPC users are free from the limitations of limited hardware and software (and license server) options, as well as interdependencies (hardware and software compatibility issues, software compatibility issues resulting from this multi-vendor integration). It also breaks away from the difficulties of solving installation and work and workflow configuration, license management, different licensing and pricing mechanisms, data security and privacy, etc.).

Additional aspects and embodiments of the inventive platform are described in more detail below.

1 is a system diagram showing an embodiment of the main components of the multi-provider server of the cloud-based platform of the present invention.
2 is a flow chart showing an embodiment of an interactive workflow creation and execution process performed by a multi-provider server of the cloud-based platform of the present invention.

Detailed embodiments of the system and method of the present invention are shown in the accompanying drawings and described below. It should be noted that the present invention is not limited to the specific embodiments described below with reference to the drawings. For example, the present invention reflects different engineering tradeoffs without departing from the spirit of the present invention, so that fewer or more (implemented in hardware and/or software and allocated between server and client devices) It can be integrated into a separate server platform with the ability to be reallocated between different conceptual modules. Additional embodiments of the systems and methods of the present invention (including additional standard and proprietary hardware and software) will be apparent to those skilled in the art.

The software components of the present invention shown in the drawings below are implemented in a physical memory and processed by a CPU (single and/or multiple cores) of a physical server (not explicitly shown) to implement the functions of the present invention. do. Such physical servers and such memory may be stored in a public or private cloud, end-user premises, or other computing environment (with or separately from software that implements the user's HPC workflow and operations) without departing from the spirit of the invention. Can be located. In one embodiment, the HPC user connects to the platform of the invention over the Internet through a standard web browser on a client device (server, desktop, laptop, cell phone, and other networked devices).

Referring to FIG. 1, a system diagram 100 shows an embodiment of the cloud-based platform of the present invention implemented by a multi-provider server 101. In that the functionality of the platform is implemented by the multi-provider server 101, the multi-provider server 101 integrates functions and resources from various different entities, all of which are interconnected via the Internet 195. , The cloud-based "platform" is referred to interchangeably with the multi-provider server 101. The HPC end-user customer 155 connects to the multi-provider server 101 over the Internet 195 through one or more different interfaces.

A web-based interface 156 that allows HPC users 155 to remotely access the platform (from their networked desktop and mobile client devices virtually located anywhere in the world) to create and execute HPC workflows is the most. It is common. The web-based interface 156 provides the most user-friendly interface for creating and executing workflows and for viewing results. In addition, advanced HPC users 155 perform most of these functions through a command line interface (CLI) 157, similar to using a "terminal" command line interface (rather than a standard GUI interface) through a desktop computer. can do.

In certain circumstances, HPC users 155 connect to the platform using API clients 158, allowing them to, for example, integrate their own custom software with HPC workflows and invocations of tasks. The multi-provider server 101 implements various APIs contained within the security and API layer 102 to enable such connectivity with the platform.

In one embodiment, the HPC user 155 wants to use its own on-premises hardware and software environment in a platform independent manner. However, for certain relatively demanding tasks, the HPC user 155 wants a "burst" capability that enables on-demand use of additional computing resources available from the backend hardware provider 115 integrated with the platform. In such a scenario, a specific API (described below) in the security and API layer 102 is a custom script that runs through the on-premises environment of the HPC user 155 is a predefined workflow or task of the platform. By making it possible to call, the on-premises work of the HPC user 155 is supplemented and the result is returned to the HPC user 155.

In this embodiment, the API enables the exchange of data (including job configuration, input data, intermediate data if the job is in progress, and results) between the HPC user 155 and the platform. As a result, HPC users 155 simply click a button on the platform's website, and if additional computing resources are required, use the "burst" function to continue through the platform, working (including installation and configuration of related software). You can have it run entirely through this platform, or you can have it run partially through your laptop (for example).

The user interface layer 150 enables bidirectional communication between platforms and various different interfaces provided to the HPC user 155. The user interface manager 152 creates a variety of different user interfaces that are presented to the HPC user 155. In one embodiment, this interface includes a web-based form that allows HPC users 155 to select hardware computing resource options as well as software from available libraries. Another web-based form allows HPC users 155 to enter their models, software configurations, and input data specific to the workflow or task. An additional user interface is a combination of individual HPC tasks, and implementation of loops, conditions, and other control flow components, prior to initiating execution of a workflow tool (and “full” workflow) to control the execution of the workflow. , Hardware and software tuning tools for testing a work flow or part of a task, and reconfiguring hardware and software resources).

The user and customer manager 153 creates and maintains a database of user entities, including individual HPC users 155 and their company affiliations (and user-specific access controls and other restrictions). This "user database" is maintained in the DB 190. Of course, the storage of such user data and other data utilized by the multi-provider server 101 can be distributed across different storage devices in a variety of different locations without departing from the spirit of the invention. In the embodiment shown in FIG. 1, DB 190 is also used to store information specific to a variety of other entities, such as third-party partners, and suppliers of backend hardware, software and license servers.

In this embodiment, the functionality of the multi-provider server 101 (including DB 190) resides on the virtual and physical computing resources of one or more backend hardware providers 115. The platform's owner/operator manages the platform's functionality remotely from the client device on its own premises (not shown).

The security and API layer 102 provides data at the time of provisioning, deprovisioning, and at computing time to ensure a certain level of data privacy and security that complements all security provided by other entities accessing the platform. It includes a security mechanism to encrypt (implemented through the data and security manager 104). The platform uses the API within the security and API layer 102 for a variety of different purposes, depending on the type of entity to which it is connected, as described in more detail below.

The data and security manager 104 also implements certain data structures, which are used internally and then transformed for communication with various entities. For example, even public cloud providers 116 also have APIs and different data structures for storing and retrieving data (similar to different file systems of desktop computers). To move data back and forth between different backend hardware providers 115, the platform must communicate with the different APIs of these backend hardware providers 115 by converting to and from its universal format.

In addition, software often assumes that the storage is "local," so that the platform must abstract the actual physical (or virtual) location of the data when configuring the software for a particular workflow or task. In one embodiment, if performance is significantly affected by the location of the repository, the platform performs conversions before and after the task is executed, so that during execution, the local repository (i.e., where the task is executed) is Ensure that it is maintained.

By handling inter-node (eg, VM-to-VM) communication as well as communication across multiple different backend hardware providers 115 at the task level, the platform eliminates the need for users to resolve these dependencies. In addition, the public cloud provider 116 measures usage at the VM or physical server level, while individual tasks or workflows may include multiple VMs or physical servers. In one embodiment, if one of the VMs experiences a hardware failure, the platform saves the working state and restarts the work by re-provisioning the other VM, preventing further failure. In most cases, the software may not be practically “aware” of the pause/resume of a job.

In another embodiment, the platform performs proactive task diagnostics (e.g., CPU, disk performance, and network latency tests) to minimize the risk of having to halt execution of tasks by evaluating the "robustness" of the hardware environment. do. In other embodiments, additional resources are allocated to provide some level of redundancy for similar reasons.

The multi-provider manager 105 can be used for a variety of different types (including HPC users 155, partners 132, backend hardware providers 115, software providers 125, and providers of license servers 128). It provides additional functions to manage the overall relationship and communication with the supplier entity. The multi-provider manager 105 communicates internally with the various platform modules that manage direct communication with such entities.

In one embodiment, the platform's owner/operator contracts with various third-party partners 132 to manage certain aspects of their relationship with HPC users 155. For example, the partner 132 invites individuals and businesses to become HPC users 155, manages contracts and billing relationships with these invited HPC users 155, and manages the It may be responsible for enabling the integration of on-premises computing resources with the platform. In addition, the partner 132 may substantially act as a backend hardware provider 115, and for the benefit of their recommended HPC users 155, may provide their own hardware infrastructure, or may provide a public 116 ) Or the infrastructure of a private 117 cloud provider.

The partner layer 130 implements communication between the platform and individual partners 132, including the transformation of a variety of different data structures, protocols and APIs. Partner manager 131 implements this transformation and, among other entities, exchanges rates, invoices and related reports with partners 132, HPC users 155, backend hardware providers 115, and software providers 125. It connects to various platform components, such as the responsible billing tier 140. The billing manager 145 implements these rate calculations, generates invoices and related reports, and manages payments (multi-supplier manager 105 and hardware and software measurement manager 180, and other internal platform components. Connected with).

Among the most important entities integrated with the platform is the backend hardware provider 115. As mentioned above, the work flows and tasks of the HPC user 155 are not directly executed by the multi-provider server 101. Instead, the platform is provided by a number of different hardware providers, including public cloud providers 116, private data center providers 117, and on-premises computing resources 118 provided by HPC users 155. Is integrated with computing resources.

As described in more detail below, the platform allows HPC users 155 to select computing resources from one or more available backend hardware providers 115 (even in the case of individual workflows or tasks). In one embodiment, these selections are filtered by the attributes of a particular workflow or task designed by the HPC user 155. For example, if a specific software package is not available in the hardware environment of a specific backend hardware provider 115, the computing resource options provided by the backend hardware provider 115 are displayed in the user interface viewed by the HPC user 155. There won't be. In other embodiments, the absence of such an option is not clearly identified in the user interface (e.g., in a list of high-level computing resource options), but such incompatible options are internally addressed by the multi-provider server 101. Will not be chosen.

The connection of the back-end hardware provider 115 to different computing resource environments is managed by the hardware abstraction layer 110, and the hardware abstraction layer 110 uses a certain internally generated formulation of the computing resource to be a specific core type. , Physical server, or other options provided by the individual backend hardware provider 115. In one embodiment, the platform analyzes (with the aid of multi-vendor manager 105) a high-level requirement of a task or workflow specified by HPC user 155, such as the requirement of 100 CPU cores. These high-level requirements can be met by different core types of two different backend hardware providers 115 (one provider provides 10 nodes (servers) each with 10 CPU cores/nodes, Other providers offer 20 nodes each with 5 CPU cores/nodes).

If the HPC user 155 specifies the total cost as the only optimization factor, the latter option may be cheaper, since the cost of a 10-core node may be more than twice that of a 5-core node. However, if instead the HPC user 155 wants to optimize time (e.g., even more costly, preferring a task to be completed in one day instead of three), the former option may be desirable. Yes (for example, because the inter-node communication overhead between 10 nodes (as opposed to 20 nodes) results in a much faster total task execution time). In one embodiment, the platform automatically makes this determination according to the optimization factor specified by the HPC user 155. In another embodiment, the platform presents detailed suggestions, from which the HPC user 155 makes the final decision. In making this decision, it will be apparent to those skilled in the art that other tradeoffs of various different factors, and other implementations of this comparison between multiple different selections of hardware computing resources, may be considered.

In other embodiments, the computing resources selected in connection with the individual workflows or tasks of HPC users 155 are implemented through the virtual and/or physical hardware environments of multiple backend hardware providers 115. In making this determination, the platform not only includes the model, software and configuration, and input data provided by the HPC user 155, but also the optimization parameters specified by the HPC user 155 (e.g. For example, consider various factors, including total calendar time, running time, cost, etc.).

Using the hardware abstraction layer 110, in addition to provisioning selected computing resources, the platform monitors the execution of work flows (in relation to both hardware and software components), deprovisions computing resources, and provides various costs. For the purpose of performing billing and other functions, the hardware abstraction layer 110 is also used to manage bidirectional communication with the backend hardware provider 115.

For example, certain backend hardware providers 115 have their own "schedulers" for allocating computing resources to tasks, but the platform is essentially, the specific data required by each individual backend hardware provider 115. It provides a higher-level scheduler that translates into structure, protocol, and API (including APIs for integrating on-premises computing resources without these scheduler functions).

In addition to providing access to multiple backend hardware providers 115 (within and across HPC tasks, tasks, and more complex workflows), the platform also supports multiple third party software from multiple software providers 125. The choice of package is provided to the HPC user 155. The SW abstraction layer 120 manages different APIs between the various software providers 125 integrated within the platform (e.g., receiving software updates, and with the aid of billing manager 145 and billing layer 140). To exchange billing and payment information, including invoices, usage reports, and electronic payments).

The ISV and customer SW manager 122 manages the platform's software library, and a subset of the software library is based on their license terms for such third-party software (and its component features), the designated HPC user 155 Connection is possible by The ISV and customer SW manager 122 maintains a separate software “image” for each operating system of each backend hardware provider 115. In one embodiment, before the task is executed, the platform installs the associated image so that it can be replicated as needed within the selected hardware environment. In this way, compatibility of the selected software with the specified hardware environment is ensured in advance to the HPC user 155.

In another embodiment, the platform includes development and integration tools that allow HPC users 155 to develop and integrate proprietary software for their use during subsequent workflows and tasks. These tools ensure compatibility with available hardware environments and provide configuration tools for optimizing the best "HW-SW matching" according to the optimization factors specified by the HPC user 155. In yet another embodiment, the platform creates an OS-independent “container” to enable installation of such software across different operating systems and backend hardware providers 115.

The ISV and customer SW manager 122 further includes a "virtual desktop" tool that enables analysis and other interactive GUI viewing during and after execution of a workflow or task. Similar to "remote desktop" software where applications are controlled locally, but run remotely, the virtual desktop functionality provides HPC users 155 with the ability to invoke and monitor certain aspects of their operations during and after execution. to provide.

As mentioned above, different ISVs have different requirements for their reasons and the location and use of third party license servers 128. The license server abstraction layer 127 provides a great deal of flexibility when integrating with a variety of different license servers 128 (across a number of different ISVs) installed in virtually any physical location. For example, some ISVs may limit the location of the physical license server 128 (e.g., on the ISV premises, or on the premises of HPC users 155), while others are software that implement the license server function. Can be physically located anywhere (eg, in the public cloud 116 (if the ISV maintains sufficient control to ensure the integrity of the license server functionality)).

The license manager 126 may ensure that the license file of the HPC user of the associated license server 128 is located in its physical location (e.g., for authentication and check-in and check-out purposes, and to ensure that the license terms are strictly enforced). Regardless, it provides a tool to ensure that it is accessible by the current job. In certain cases, if the license server 128 is located on the premises of the HPC user 155, pre-custom integration is required.

The license manager 126 works with the HW and SW measurement manager 180 to ensure that the license conditions are strictly enforced. In one embodiment, the HPC user 155 provides a "bring-your-own" (BYOL) license, allowing access to the platform through the associated license server 128 during execution of the job. In another embodiment, the owner/operator of the platform also obtains prior approval from the relevant ISV to create on-demand licenses (prepaid and other) for this same purpose. In such a scenario, if there is no BYOL license provided by the HPC user 155 (e.g., due to an outdated version or other reason), the platform is to execute the task (or in other embodiments, the HPC user 155). In order to provide an on-demand "burst" function) if it exceeds the allocated usage requirements), it can automatically redirect the connection to the platform-hosting license server 128.

Due to this level of integration with the platform, HPC users 155 are freed from many limitations of the existing BYOL (and even some on-demand) licensing schemes. The level of integration of the platform with the third-party license server 128 enables two-way communication during the execution of the task and, using a proxy, a firewall across a variety of different backend hardware providers 115 (at the physical location of the HPC user 155). On-premises firewall) By searching for such a license server 128 in advance, the platform prevents unnecessary hardware provisioning costs of the HPC user 155 (eg, when license authentication fails).

To assist the HPC user 155 in setting up a workflow, the workflow manager 170 provides tools that are typically protected from hardware and software compatibility issues that the HPC user 155 must address. That is, these workflow tools are at a higher level of abstraction, allowing HPC users 155 to focus on the functionality of their specific HPC tasks.

As mentioned above, the workflow manager 170 allows the HPC user 155 to (including software packages from a number of software providers 125 running across the hardware resources of a number of backend hardware providers 115). ) Includes templates and tools that enable the implementation of loops, conditions, and other control flow components, both within and across individual HPC tasks and tasks. The output of one task can be redirected to an input for a subsequent task. Execution can branch to a specified task based on intermediate results according to specified constraints. For example, in the context of designing an airplane wing, a commonly repeated calculation or “sweep” involves varying the angle of the wing. The same calculation can be repeated in multiple test runs where only the parameters used to define the angle of the wing are varied.

In addition, the HW and SW tuner 172 includes a tool that allows the HPC user 155 to design a "test run" to enable selection of desired hardware resources and software configuration parameters. For example, the HPC user 155 can identify a relatively small portion of a frequently repeated task, and test that portion through a number of different hardware configurations. Once the desired configuration is determined, the desired hardware computing resources are provisioned and can execute the entire task. In another embodiment, by specifying conditions for test execution by HPC user 155, the entire task will be automatically reconfigured and executed in the desired hardware environment if satisfied. These "hardware tuning" tools not only provide flexibility for testing purposes, but also provide cost savings by avoiding expensive, long-term tasks that eventually fail (or waste significant resources) due to improper selection of hardware computing resources. do.

In addition, the HW and SW tuner 172 allows HPC users 155 to design test runs to measure their work flow and software-specific aspects of work in an effort to identify appropriate hardware computing resources. Includes a "software adjustment" tool. For example, through the HW and SW tuner 172, the HPC user 155 can test and compare the performance of different configurations (eg, different implementations of a particular software driver) before selecting the desired configuration.

In other cases, more complex workflows can be developed based on intermediate results (e.g., repeating calculations until certain conditions are met, or calling analysis software if other conditions are met). Further, partial or intermediate results may indicate that the hardware configuration should be changed, for example, to include a GPU-only configuration, or to increase or decrease the number of provisioned VMs.

As mentioned above, the HW and SW tuner 172 further includes an optimization tool, which allows the HPC user 155 to specify optimization factors, such as, in particular, job execution time and job cost. These tools provide an automated means of exploring execution times and pricing "sweet spots" (e.g., comparing node cost, communication overhead, licensing limits, and various other factors). .

The analysis manager 174 provides tools for customizing the configuration of analysis software (eg, included in the platform's software library) for use both during and after execution of a task or more complex workflow. In one embodiment, such analysis software provides an interactive GUI-based tool to HPC users 155, allowing them to monitor intermediate results of the workflow, as well as changing certain parameters to affect those results. It also makes it possible to visualize the effect of such changes in real time.

If the HPC user 155 has defined and configured a job or workflow, and has adjusted hardware and software, then using the HPC task manager 175, provisioning the designated computing resources to the selected hardware environment, and installing and configuring the selected software. Thus, execution of the work flow is started. In addition, the HPC Task Manager 175 monitors the execution of the job flow to obtain an intermediate status (for example, when a job or part of it, such as a provisioned VM) fails, and the job flow is completed or prematurely. When it is finished, it notifies the HPC user 155.

As mentioned above, the HW and SW measurement manager 180 monitors the usage of both hardware and software resources during execution of the work flow for a variety of different purposes. Monitored hardware and software usage data can be used for billing purposes (e.g., invoicing, providing reports, HPC users 155 and partners 132, and backend hardware providers 115 and software providers ( 125) and payments). HW and SW measurement manager 180 interacts with billing manager 145 and billing layer 140 in this regard.

In addition, the HW and SW measurement manager 180 also works with the license manager 126 to monitor software usage and ensure compliance with the related licensing system. As mentioned above, the integration of hardware and software providers and platforms, and the ability to monitor hardware and software usage at a discrete level of granularity, enables a new type of pricing scheme. In addition to consumption-based on-demand pricing based on hardware and software usage (ie, time), outcome-based and other forms of pricing (eg, based on hardware resource consumption) may be supported in other embodiments.

For example, in one embodiment, pricing is based on the “success” of the task (measured by a specified goal determined from results extracted from software during or after completion of the task). In other embodiments, pre-purchase of blocks of time is supported (ie, in a non-refundable amount subject to actual monitored hardware and/or usage). These block purchases are offered at a "volume discount" price, and excess usage is prohibited or charged at a premium.

Various consumption-based, outcome-based, and other hardware and software pricing and licensing schemes will be apparent to those skilled in the art, all of which are supported by the integration of multiple hardware and software providers and platforms, as well as individual tasks, tasks, and more. It is supported by its tightly integrated monitoring mechanisms both within and across the complex HPC workflow. This multi-vendor approach not only provides HPC users 155 with improved visibility into the cost of HPC workflows, but also provides excess capacity, and from on-premises hardware to the cloud for other configuration, pricing and licensing options. It provides HPC users 155 with the flexibility to optimize cost, time and other desired factors by “mixing and matching” different hardware and software environments that are “bursted”.

Flow diagram 200 of FIG. 2 provides a dynamic view of the design and execution of HPC workflows (from the perspective of the HPC user 155). Before any HPC user 155 even starts designing a job or workflow, the platform pre-establishes the hardware provider settings with the backend hardware provider 115 (via hardware abstraction layer 110) at step 201. do. In one embodiment, the platform provisions and installs the functionality of the multi-provider server 101 to selected backend hardware providers 115, thereby providing the various layers of abstraction and integration described above with other third-party providers.

Further, in step 202, the platform creates and installs an image of each version of the software in its software library for each supported operating system, along with the necessary software drivers. This allows the platform to install an appropriate image of any selected software package into any provisioned hardware environment, ensuring that compatibility has already been verified. The platform additionally implements the web 156, CLI 157, and API client 158 interfaces through the user interface layer 150, through which the HPC user 155 accesses the platform.

When the HPC user 155 initially wants to prepare and execute a workflow through the platform, the user typically first defines its model and prepares the input data to provide to initialize the desired software (step 204). )in). The HPC user 155 then invokes the platform's workflow tool in step 206 and provides its model and input data to the platform. The platform's workflow tool presents the software library to the HPC user 155 from which the HPC user 155 selects, at step 208, one or more desired software packages. As noted above, a workflow may include multiple software packages, whether as part of a single task, or as a more complex multi-task workflow.

Then, at step 210, the workflow tool presents the HPC user 155 with a list of available hardware resources "core types" and other server configurations available from the backend hardware provider 115. In one embodiment, the platform creates and presents these options with a higher level of abstraction than the specific core types and physical server configurations provided by each backend hardware provider 115. In other embodiments, the option allows to identify a specific backend hardware provider 115 that provides such an option (eg, to enable HPC user 155 to select or circumvent the desired provider).

In other embodiments, this list is filtered based on the user's previous software selections (e.g., if the selected software is not compatible with a particular backend hardware provider platform, or otherwise not available on a particular backend hardware provider platform). . In another embodiment, the platform analyzes the user's model and other input data and, based on the analysis, provides the HPC user 155 with suggested hardware resource options.

When the HPC user 155 selects from the available hardware resource options, the platform's work flow tool presents the work flow and an interface for configuring each component work to the HPC user 155. As mentioned above, this configuration is application-specific, not only based on the selected software package, but also based on the user's model and other input data. Again, since the platform automatically resolves any dependencies between previously selected hardware and software options, the options are presented at a higher level of abstraction. In one embodiment, the workflow tool automatically configures those hardware-specific options that are determined based on previously selected hardware computing resources (additional specifications of hardware-specific parameters such as desired number of cores may still be required).

With the help of the platform's workflow tool, the HPC user 155 can determine the desired control flow configuration (e.g., when multiple HPC tasks and/or multiple jobs are involved), and are provided by the workflow tool. Specify them according to your options. As mentioned above, a workflow can include multiple software packages, and the control flow not only determines the conditions under which subsequent software packages are invoked, but also determines whether the result of one package is provided as input to another package. do.

If any pre-workflow hardware or software adjustments are required, the HPC user 155 invokes the HW adjustment tool in step 214, and/or the SW adjustment tool in step 216. In one embodiment, the platform presents a common template for hardware and software coordination. In another embodiment, by providing an optimization tool, the HPC user 155 can specify the desired optimization factors (e.g., time, cost, etc.), as well as the conditions under which the specified hardware resource configuration is allowed or denied. have. In yet another embodiment, the HPC user 155 provides a custom script that specifies the exact control flow of the hardware and/or software coordination process.

The HPC user 155 initiates a defined workflow in step 220. Note, however, that if the HPC user 155 has specified any hardware or software adjustment "run tests" in step 214 or 216, the platform will run those test runs first, as described below.

In step 222, the multi-provider server 101 provisions the selected hardware computing resources to one or more backend hardware providers 115 selected (or created for) by the HPC user 155 in step 210. do. In addition, the multi-provider server 101 replicates the model and user input data to the provisioned hardware environment.

In step 224, the multi-provider server 101 installs the appropriate version of the selected software image into the provisioned hardware environment, and then configures such software according to the specified configuration defined in step 212. As noted above, multiple instances of the software can be configured (e.g., based on the number of specified cores), depending on the hardware resource configuration (e.g., on multiple VMs or physical servers, and potentially multiple backends). May be further replicated across hardware providers). Additionally, additional instances may be duplicated and/or removed during execution of the workflow.

In step 226, the multi-provider server 101 configures (via the SW abstraction layer 120) a connection between the software installed and configured in the provisioned hardware environment and each associated license server 128. Accordingly, if the HPC user 155 is authenticated, and individual functions are checked out and checked in during execution of the workflow, the software can be properly executed.

In one embodiment, a license key with a relatively short duration (e.g., 1 day instead of 1 year) is repeatedly generated, providing an additional layer of security (e.g., a "counterfeit" license server is To prevent you from continuing to work as you obtain your license key). The license manager 126 manages frequent (eg, daily) communication with the associated license server 128 (via the SW abstraction layer 120), thereby authenticating and authenticating these license keys that are frequently regenerated. Ensures continuous access by the HPC user 155.

At this point, in step 228, the multi-provider server 101 performs any designated hardware and/or software tuning test execution. Although typically much smaller and faster than the actual work or workflow, these test executions allow, in one embodiment, designated computing resources to be automatically reconfigured. In another embodiment, the platform generates a suggestion for the HPC user 155, or simply by providing a result, from which the HPC user 155 makes its own decisions regarding any such reconfiguration.

Thus, in step 235, the HPC user 155 (or in other embodiments described above, the platform) determines whether to "re-adjust" the hardware and/or software selections previously made in steps 208 and 210. do. If re-adjustment is required or desired, control returns to step 208 (at this point, additional hardware and/or software adjustments are required, depending on whether the HPC user 155 recalls the hardware and/or software adjustment tool. May or may not be performed). As described above, in one embodiment (not shown), the platform automatically reconfigures computing resources and resumes execution of the workflow at step 220 (as reprovisioning may be required).

Otherwise, if no remediation is indicated in step 235, the multi-provider server 101 initiates execution of the "full" workflow in step 240. As mentioned above, the platform, in step 242, monitors the execution of the workflow, including hardware and software measurements (for usage and billing purposes), as well as the implementation of the control flow specified in the workflow. do.

At the end of the workflow execution (including early termination of a particular instance), the platform implements a "cleanup" process in step 244. In step 250, the results (via user interface layer 150) are extracted, stored and provided to the HPC user 155. In addition, as described above, the platform de-provisions hardware resources, and for billing and other purposes, the measured hardware and software usage information is extracted and stored in the platform. Also, as described above, an analysis of the results can be performed (including during execution of the workflow in one embodiment), but the execution of such analysis software is considered part of the workflow itself (such software is Because it is part of the software library).

The invention has been described herein with reference to specific embodiments as shown in the accompanying drawings. Many variations of the embodiments of the functional components and dynamic operation of the present invention will be apparent to those skilled in the art without departing from the spirit of the present invention.

Claims (1)

As an integrated cloud-based platform,
(a) a backend hardware provider abstraction layer that allows a user of the platform to organize tasks by selecting from a plurality of hardware core types across a plurality of backend hardware providers;
(b) a software abstraction layer that allows the user to further compose the task by selecting from a plurality of software packages across a plurality of software providers;
(c) a license server abstraction layer that implements a network connection between a license server related to the software selected by the user and the user's work;
(d) an administrator who provisions hardware resources related to a selected hardware core type from an associated backend hardware provider, installs and configures the selected software on the provisioned hardware, and invokes execution of the user's task;
(e) a hardware measurement module that monitors usage of the provisioned hardware during execution of the task;
(f) a software measurement module for monitoring usage of the selected software during execution of the task; And
(g) a user interface layer that allows the user to access the results of the task.
Including, an integrated cloud-based platform.

Images