While it’s getting easier to find case studies of cloud deployments in the enterprise, cloud deployments in the scientific computing arena are a bit more nebulous to track with some exceptions. Accordingly, those in the scientific computing community who are looking for news about cloud computing are paying close attention to the Magellan testbed, which is set to deliver some results that will be of value as researchers tackle the tough question of buying time versus investing in their own private clusters.
The Magellan cloud computing project is delivering some interesting results as it continues to alter the cloud environment in order to take different cloud models to task. The National Energy Research Scientific Computing Centers (NERSC) in conjunction with Argonne National Laboratory launched a computational cloud testbed called Magellan in October, 2009 with funds from the American Recovery and Reinvestment Act via the U.S. Department of Energy. The goal of the joint effort is to look at the cost and energy benefits and drawbacks to the cloud computing paradigm for scientists, specifically those working on government-funded projects. The range of application areas that are either already being explored or are set to enter the cloud covers several scientific computing arenas, including genomics and climate research and applied mathematics.
To evaluate the current progress and challenges for Magellan users and NERSC, HPC in the Cloud discussed the status of the project with NERSC Director, Kathy Yelick.
HPCc: As a testbed, what variables will be added or subtracted on a hardware and application level to test for differences in performance and benchmarking?
Yelick: The actual testbed is static in the hardware sense; we’ve installed a cluster that’s the hardware basis for the cloud testbed and that’s IBM iDataPlex System with an InfiniBand network and Nehelem processors, which is really the high end of cloud when you compare it to what you’d see in a commercial setting. From a software perspective we’ll be doing a lot of experimentation with different types of virtualization and different uses of operating system virtualization. We’ll also be looking at some of the programming models that are available in cloud computing, including the Hadoop implementation of the map reduce program model idea and we’ll also be looking at different configurations of the system to provide people with either the idea of virtual clusters or more of a shared resource environment where the boundaries between the jobs are more dynamic.
HPCc: For now it seems that there is a distinct focus on genomics research given your collaboration with the Joint Genome Institute (JGI) but from your initial releases about the aims of Magellan it appeared that there would be a broader focus. What other scientific areas will be you examining?
Yelick: We are actually looking at a broader DOE science focus, but just it turned out there was immediate need for some work in the genomics area so we set up a virtual cluster within our cloud testbed for the Joint Genome Institute, which was a short-term project. They’re still using that virtual cloud but it will be trailing off in the next few months as they install some of their own hardware. After that we’ll be looking at some other science projects in high energy physics, applied mathematics, and some climate data analysis. There’s a project in the Earth Systems Grid that’s looking at climate data; it’s not a climate modeling simulation platform, it’s more of a data analysis platform. So in addition to the compute tests we also bought close to a petabyte of disk storage to create a storage cloud that’s integrated into our file system.
HPCc: What are some of the results you’ve seen thus far in terms of your goals of examining overall energy-efficiency and cost effectiveness and what goals or comparison points do you have to determine overall efficiency?
Yelick: We selected an energy-efficient system, IBM iDataPlex Linux Cluster with liquid cooled doors, which is very energy-efficient and did some novel things in the installation of that system to pack it into a tighter space and make more effective use of the cooling system. We’re actually using water that’s returned from other computers in the system that go into the cooling system, which allows us to save energy.
It’s hard to do an energy efficiency comparison to Amazon for example because they don’t open their configurations to the public but we’re always looking for ways to make it more energy efficient. Our real comparison point is not to the commercial clouds, but to private clusters that individual researchers go out and purchase for their scientific applications. So what we’re exploring is the question of whether the DOE or other government agencies should be buying their own clusters (they’ll go out and buy a rack or even a system of 64 nodes, for instance to run their own scientific applications on) or whether those kinds of purchases should be done in a more consolidated way. In other words, we’re looking at the efficiency of running private separate clusters that are run by individual researchers throughout the lab and university system compared to a setup like what we have at NERSC, which is a consolidated testbed.
HPCc: In one of your releases about the use of Amazon EC2 for the metagenomics project, it seemed that there were some pricing surprises that you didn’t anticipate, which might mean that there are some unexpected underlying issues in public clouds for scientific users?
Yelick: It is true that what we found is that there are some costs in the commercial clouds that are not as obvious when you just look at the pricing models. Those costs can also include applications running more slowly on a shared environment with a relatively low-speed network (Ethernet networks rather than our InfiniBand network). Scientific applications that are using more than one processor per job can run much more slowly in an environment like that because of the network performance, which we think is the most significant factor, but also perhaps because of the sharing of the system and the virtualization. If you just look at a price per CPU-hour, you need to be careful because you really want to look at the application performance as well.
The other big factor is the storage, which you pay for separately. For instance, in climate modeling in our experience, there’s a lot of data storage and manipulation that goes along with this application; it’s not just a computationally-intensive problem. You really have to look at both the cost of the storage but also the type of bandwidth you get from say a storage cloud into a compute cloud if you’re doing data analysis. Those are some of the places where I think that some of the commercial options are not really configured for high-parallel I/O bandwidth between the storage and compute clouds. Moving massive scientific datasets around is not really what these are optimized for. Then again, we’re really looking at a different workload than those in the commercial setting—that’s one of the things we were trying to understand—to what extent can the systems be identical and in what ways do they need to be configured differently for a scientific environment.
HPCc: One of the big issues for scientific users is application performance—what have you noticed in this area; in other words, which scientific applications seem best-suited for the cloud? What have developers noticed?
Yelick: BLAST is one example of an application we’ve looked at on a number of systems. I think in terms of the application development there are advantages and disadvantages of the cloud model and what I’m referring to here is really the virtualization model. The advantage is that it is really flexible because you can choose an OS version you’re going to install and run but then again, as an application developer you’re also responsible for doing that in some sense in a hardware as a service model—you get the raw hardware but then you need to configure your environment with your operating system environment, your libraries, and so on. For an application like BLAST, which is an application that has a tremendous amount of throughput required and runs many jobs per day throughout the year, the time to configure a system like that for a cloud environment makes a lot of sense. With that done we’ve been able to run some of the metagenomics pipelines on this cloud environment. There are positives and negatives—some of the users, I was talking to someone looking at detector data in a physics application area—in that case they wanted the control you get from a cloud environment, that is, they wanted the ability to run a particular version of the operating system so they could go back and run versions of the application that had been developed several years ago in order to do validation against current versios of the code. That’s a big attraction.
I should also mention that the Hadoop programming model is something we have used a lot on the Berkeley campus, we are just in the process of being able to provide that to the users on the NERSC testbed. There’s been some work in the case of BLAST on top of Hadoop.
HPCc: Although this it is still early to get an overall picture of the suitability of cloud for scientific computing, what are some of the more surprising findings thus far, especially as they relate to any expectations or benchmarks you might have had in mind before the launch of Magellan?
Yelick: I think the biggest is the difference in performance is visible even when running fairly modest-sized applications across different cloud environments; especially when looking at pricing models—what can seem like a very attractive environment and can actually be very effective at something like the BLAST workload, which is basically independent serial jobs in large numbers, that are running on that kind of environment—each one s running independently, that works very well in a lot of different environments both commercial and on our in-house cluster and would probably also work well on a lower-cost cluster.
But looking at some of the other kinds of scientific applications, even at fairly modest job sizes, there are significant performance differences between running a batch schedule system where jobs run in a synchronous manner across a sub-cluster and on a higher-speed network and in an environment that is not designed for that kind of synchronous parallel work, which is what you get in a commercial cloud.
The other thing has been the sociological question of what it is that the scientists find attractive about cloud computing. This is less quantitative, but having talked to various scientific groups about what makes cloud more attractive than what we already have for scientists, I would say the first issue is really the control of the time—the primary reason why they go out and buy their own hardware in the first palce. It’s really a scheduling issue. It’s about how heavily utilized a system is.
The effect would be a system that’s not as well utilized as our other systems at NERSC (which are around 95% utilized) and if you give a sub-cluster of 64 nodes to a science group, most likely they’re not going to run that full on throughout the year. So there is an interesting question about the utilization of systems, which then goes back to energy efficiency. You need to look at the work that gets done per kilowatt of energy that’s used as opposed to looking at it as how efficient the computer system is.
Another thing is that there is some interest in the virtualization for some of these groups that want to run particular OS versions because, for example they’re running large international project and there are particular software version requirements—the map reduce model is also interesting to some, often who have fairly independent kinds of serial work they want to perform and I think some of the data analysis problems such as genomics will fit in that category as well. Other data analysis problems, including detector data (coming out of CERN for instance or the Earth Systems Grid) those are massively serial jobs, and there are a lot in the data analysis area, those will be the best examples for the cloud environment but that depends on us having an architecture that provides the high-speed I/O between the storage and compute part of the cloud.
HPCc: To expand on that, do you think it’s still too early for large-scale scientific computing in the cloud? Better yet, do you think it’s too early for HPC in the cloud?
Yelick: I would rephrase that ask how useful is cloud to scientific computation–and I think there’s a part of the workload in scientific computing that’s well-suited to the cloud, but it’s not the HPC end, it’s really the bulk aggregate serial workload that often comes up in scientific computing that is not really the traditional arena of high-performance computing. If you look at some of the commercial offerings like SGI’s cloud cluster they’re certainly providing a system and environment that will be competitive for HPC and then it will come down to cost issues—how to most cost effectively run systems and the question of the service level and what the scientists are willing to go pay for versus want to have.
There are lots of questions about anything other than the large serial work for a cloud environment —the biggest sticking point in the cloud is the integration of the network (having a high-speed network that allows you to run parallel work and along with that being able to schedule parallel jobs in a batch way so they can do frequent synchronization across the parallel job.
This can be overcome; we look at cloud as business model. It’s not about HPC and clouds it’s about the individual private clusters that people are still buying versus cloud. It’s really about trying to figure out if you can get rid of the private clusters and replace that with a cloud environment.