Share this:

Source | February 4, 2015 by Leo Reiter

When it comes to cloud computing, there is no “one size fits all” platform for getting work done.  High Performance Computing (HPC) workloads are not web applications. Thankfully, there are clouds specifically designed for running HPC workloads rather than web applications.

An HPC cloud is very different to a commodity web services cloud. Before we discuss how an HPC Cloud is architected, we need to examine HPC workloads themselves to really understand how they differ from other applications:

  • HPC jobs process data – most often enormous amounts of data (Big Data) and return results. In other types of clouds, “instances” (virtual servers) run when launched and listen for requests. HPC workloads typically run in “batch” mode, where the data and the parameters are queued together with the application for execution. Other types of cloud workloads offer services that often require further interaction to do any processing.
  • HPC jobs “shut down” as soon as they finish, again due to their batch nature. In a pay-per-use model, end-users need not need worry about managing the underlying infrastructure in order to save money, and are billed only for the processing cycles their jobs consume.
  • HPC jobs tend to consume 100% of their allocated resources, 100% of the time. Therefore it is not prudent to use average utilization assumptions to fit more workloads on fewer physical resources (known as oversubscription) as is common with web services applications.
  • Instances tend to be virtual machines with entire operating system stacks. HPC jobs run best on bare metal, where they can take full advantage of the high performance hardware underneath without wasting cycles dealing with an abstraction layer in a hypervisor. HPC jobs also spend far less time “starting” than Instances do, again, due to their non-virtualized nature. In a pay-per-use model, this means less money spent on non-productive computing overhead.

HPC Cloud Job Scheduling
No matter what type of work they do, all clouds have “Cloud Controllers” which put resources to work, and often feature load balancing and metering capabilities. An HPC Cloud uses a Job Scheduler to assign work when requested. Basically, this puts work in queues for future execution on appropriate resources. Jobs are then run as resources become available.

Queuing versus Oversubscription
When resources are not available, the cloud is busy, and an HPC Cloud Controller will queue the work for later execution – otherwise known as “batch queuing.” Since the job has all the parameters and data it needs, there is no need for the user to “watch” to ensure the job starts running. Some jobs may take hours or days to run, even if resources are immediately available. In this case, the end-user submits the request, and is later notified with the results. The HPC Cloud Controller runs the job as soon as resources become available without the user having to “re-submit” or be concerned at all.

In other clouds, Instances suffer a much less desirable fate when resources are not available because cloud resources are oversubscribed. This is how many cloud providers make money with their web services – i.e. putting more jobs to work than what their hardware can handle.

When Instances are virtualized, the end-user has no visibility into how busy their resources actually are – they only see drastically reduced performance. This is because overloaded hypervisors have to “time slice” between Instances, since there is not enough hardware to run in real-time. Depending on the Service Level Agreement (SLA), the cloud may even reject the Instance altogether asking the user to try again at a later time!

An HPC Cloud, on the other hand, ensures deterministic, real-time performance for all work submitted, even if some of the jobs may queue until resources are available. A well designed HPC Cloud will alert operators of resource shortfalls ahead of time so they can anticipate and expand accordingly.

Scalability and Elasticity Elements
A key element of Cloud Computing is elasticity – it allows for the scaling of applications for large-scale processing. An HPC Cloud supports jobs that span across many physical nodes, without requiring that the jobs themselves configure the infrastructure underneath. Cloud programs that support distributed and parallel HPC application models can even leverage high performance interconnects, such as 56Gbps FDR Infiniband technology, which can pass up to 137 million messages per secondbetween nodes. This is compared to only about one million messages per second on commodity web services clouds that limit interconnectivity to Ethernet networks.

Since parallel HPC applications may run millions of data processing iterations during a job, they also must be able to communicate quickly to finish faster. Since the end-user pays for compute cycles, this makes a big difference to the bottom line. Simply put, the faster the job runs, the less it costs. The true cost of a job is not about the price per core hour, but rather the price of all machine resources leveraged over the period of time needed to finish the work.

In addition, commodity web service clouds don’t typically offer a resource manager component that orchestrates queuing and running parallel jobs automatically which means end-users must configure interconnectivity themselves. That means more time spent configuring, less time spent doing productive work – and the end-user still pays the cloud provider regardless.

API and Portal
While most clouds offer end users self-service through both a web portal and an API (Application Program Interface), an HPC Cloud offers a “processing API” where other clouds offer a “machine API.” The processing API allows end-users to submit jobs, parameters, and data. A machine API requires end-users to start and stop instances, which they can later use to set up and execute workloads. Since users shouldn’t be expected to configure their own infrastructure before starting the work, a processing API is important for an HPC Cloud. While the API allows programmatic orchestration of cloud resources for automation, the web portal makes it convenient for end-users to submit work for processing from any device. In HPC Cloud terms, this means kicking off complex jobs with just a few touches on your tablet or smartphone, as opposed to “spinning up” virtual servers, logging in, and typing Linux commands on other clouds.

It’s important to note that traditional HPC clusters do not offer API or portals. Instead they require end-users to write and submit “batch scripts.” This is by no means “self-service” in the spirit of the NIST Cloud Computing Definition. An end-user shouldn’t be required to write a batch script on a mobile device, or even learn how to write batch scripts in order to get work done. A real HPC Cloud provides both an API and a portal to make this process much easier to consume.

There are similarities in HPC Cloud offerings and commodity web services:

  • They all have Cloud Controllers, which assign work to various types of resources. They all bill users for cycles consumed, and allow self-service.
  • They all offer elastic scalability, through API and/or web portal.

However, that’s where the similarities end. An HPC Cloud optimizes all these features for data processing jobs, not “web services.” And since all workloads are not created equal, users should not try to run HPC applications on a “web services” cloud.