How to Build an HPC Cluster in the Cloud
By Damon Miller
Organizations in industries such as pharmaceutical research and financial services as well as many federal agencies depend on high performance computing (HPC) for research and analytics. From protein sequencing to market simulation, these compute-intensive tasks demand processing power far beyond the capabilities of a single server. Organizations have traditionally built large clusters and grids in their data centers to distribute these massive workloads across multiple machines. Resource requirements are usually short-term (a few hours, days, or weeks), which means that internal equipment is largely underutilized but still needs to be available for critical projects. Rather than continue to build out their infrastructure at enormous cost, many enterprise are now considering the cloud as a more flexible and efficient alternative.
Based on our work with some big players in pharma and banking, building a secure HPC cluster or grid in the cloud can be straightforward and take much less time than you might imagine. Here are the basic steps to get it done:
Step 1: Deploy or migrate a management server in the cloud
A distributed computing management (DCM) server (also called a front end server or queuing server) is required for coordinating execution of jobs across a large number of compute servers. Products such as Oracle Grid Engine or Condor are commonly used to provide this capability. There are also tools such as Rocks Clusters which include the DCM software as part of an OS provisioning system. Regardless of the specific solution used, CloudSwitch enables an administrator to migrate an existing deployment or establish a new deployment in the cloud within a few minutes. Once the chosen software framework is in place, compute capacity to carry out the workload can be provisioned.
Step 2: Create compute servers quickly in the cloud
The CloudSwitch API makes it easy to quickly stamp out dozens or hundreds of virtual servers in the cloud that will form the cluster or grid. You can configure the virtual machine parameters that match your internal environment with a few clicks, or upload a gold image to make provisioning even easier. CloudSwitch automatically creates the appropriate cloud resources with the chosen configuration rather than relying on a cloud provider’s options. (A previous post describes the CloudSwitch point-and-click approach in more detail.) The CloudSwitch isolation layer extends the internal environment into the cloud so that when the servers are started, they appear to be running inside the data center, using the same management tools and processes.
Step 3: Install the operating system
Now that we’ve created the cloud infrastructure, we continue building up the stack, starting by installing the operating system on the virtual machines we created. There are a number of products that do this quickly with minimal human effort. If using Rocks, the compute servers automatically boot from the network using the “PXE” standard, and operating systems are pushed onto them. CloudSwitch also supports other solutions, including ISO-based or image-based provisioning in addition to network boot.
Step 4: Install the DCM software and build the cluster
Since the DCM software provides the overlay framework enabling HPC jobs to run in parallel, it must be installed onto each compute node. In some cases this step can be done automatically by the provisioning solution (as in the case of Rocks), or the software may be installed manually after OS provisioning completes. Regardless of the installation method, once the DCM software is installed onto the newly-provisioned compute nodes, they are available to the management server as workload targets.
The above process will vary slightly depending on which tool(s) you use, but the end result will be the same: a fully-functioning cluster in the cloud, with the same look and feel as if it was running within the data center. These steps could be repeated as often as needed to provision multiple clusters in the cloud, with each cluster running within its own private network to securely support separate users and groups.
And you’re ready to go!
Researchers and analysts can submit HPC jobs through the public network to the front end server, where the DCM software manages the queue, allocates compute resources, monitors progress, and informs users when jobs are finished. The user interface will look as if the cluster were running internally, so scientists or analysts can submit jobs using the commands and processes they are familiar with.
All of this can be done in minimal time. For example, for one pharma customer, I created a Rocks front end server in the cloud using a traditional ISO installation mechanism. Once the front end was in place, I used the CloudSwitch API to clone a server template in parallel and in approximately three minutes I had created over 300 servers in the cloud. I then used Rocks to provision operating systems and Oracle’s Grid Engine onto the servers when they were started. After 45-60 minutes, all servers were running in the cloud with the cluster framework in place and ready to accept HPC jobs.
Another important consideration is data security, for example to protect intellectual property used by our customers while conducting their research. The CloudSwitch isolation layer addresses security concerns by providing a single integrated environment that allows workloads to run in the cloud with the same protection and control available internally. Once data leaves the physical data center it is isolated at all times as an extension of the enterprise’s security perimeter. Enterprises not only know that their data is secure, they are able to prove it to their own customers, regulators, and other stakeholders. (More information about how we do this can be found in the CloudSwitch white paper “Making Cloud Computing Secure for the Enterprise.”)
As the demand for computing power continues to grow, CloudSwitch makes it easy to build a grid of any size in the cloud — quickly, cost-effectively, and securely. Researchers and analysts can run even the most compute-intensive HPC workloads in the cloud, with the same tools and processes used inside the data center. As our customers are discovering, this ability to access almost unlimited computing resources on demand, paying only for what you use, can be a huge competitive advantage.
Reader Comments
-
Randall Svancara
February 10, 2011 12:39 PM | Permalink
This seems like a convenient way to implement an HPC environment. As most of us who are involved in HPC are aware, every researcher has different requirements when using HPC. I am curious to know if users can select the amount of memory on the nodes. Also I am curious to know if researchers have access to high speed interconnects, such as Infiniband, and if so, how easy is it to select an OFED stack and a MPI framework for their applications? Also, in terms of CPU architecture which greatly impacts the time it takes for running a job and which compilers to use, is the researcher able to select specific architectures. Say their code is optimized for the Intel architecture but does not do well in a NUMA environment. Would this researcher have to re-architect their code or could they simply select another architecture that fits their needs.

Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn