European cloud computing is taking off as can be seen in the progress of Helix Nebula – the Science Cloud, a collaboration between select service providers and three of Europe’s most prominent research centers, CERN, the European Space Agency (ESA), and the European Molecular Biology Laboratory (EMBL). The Helix Nebula project announced last week that they were on the verge of moving from the initial proof of concept phase to the start of the two-year pilot phase, which involves expanded proofs of concepts and perhaps some additional demand side partners.
The three flagship applications (one from each research institution) have been deployed to cloud resources provided by Atos, CloudSigma and T-Systems.
Michael Higgins, Chief Enterprise Solutions Officer at CloudSigma, makes the point that CERN and the other research institutions are not really customers, not yet at least. Currently, they are all partners exploring the feasibility of migrating workloads from the grid to the cloud. Higgins further explains that Helix Nebula brings together two sets of consortia, the demand side and the supply side, which is comprised of both public and private cloud providers.
In the initial proof-of-concept phase, commercial terms are not imposed by the cloud providers on a pay-per-use basis, but instead involve agreed-upon bulk-payment monetary contribution from each of the demand side participants, based on each vendor’s ability to deliver the proofs of concept.
CERN and the Worldwide LHC Computing Grid
Project participant CERN generates a huge amount of data on its Large Hadron Collider. The LHC generally produces about 15 petabytes (15 million gigabytes) of data annually, but this year, they’re on track to reach 30 petabytes as the search for the Higgs boson particle has picked up steam. To analyze all this data, research partners from around the world rely on the Worldwide LHC Computing Grid (WLCG), a global grid network of more than 150 computing centers.
When asked what role if any Helix Nebula played in the preliminary Higgs boson discovery, the response from WLCG Project Leader Ian Bird was a qualified none:
“We did succeed in running some simulation work in production, and I dare say some of that resulting simulation was used in the analysis of the data that led to the announcement last week, but this was a very tiny fraction compared to the huge amount of data that had to be processed.”
Helix Nebula has gone from its initial stages of technology review to the point now where CloudSigma has completed all three proofs of concept for the flagship workloads. Based on that success, they’re now moving toward the next phase, which is to expand the proofs of concept and to begin to refine the commercial terms.
“They’re not only expanding the original proofs of concept, but opening the door to more demand-side flagship projects. Up to now, the researchers have not been overly pressed to understand TCO – total cost of ownership – so this may be something they’re struggling with,” suggests Higgins. “Like at CERN, IT doesn’t pay for electricity, so they would not know how much to factor in for their in-house server electricity costs.”
Higgins makes the case that cloud bursting is more suitable for science than grid or on-premise systems because very little science occurs 24/7, around the clock. There are times when ATLAS is not generating data and other times when there is an backlog of work. Oversubscription and underutilization are often the norm with designated resources, but bursting allows researchers to use only the resources they need when they need it.
Institutions are facing funding issues, explains Higgins, which means there is less hardware to evergreen or purchase new. Every day there is more compute demand, and the resources are strained. They have to look to the cloud for cost-savings or they have to find new sources of capital investment. Running workloads in the cloud on a pay-per-use basis erases the problem of buying a $10,000 platform and running it two weeks out of four.
While these arguments make sense, applying virtualization and cloud technologies to current grid resources is another avenue for boosting utilization rates and creating elasticity and scalability, and CERN is exploring these options in addition to the public cloud. Still, Bird notes that simply having a private cloud won’t work either, because the research depends on a federated connected cloud.
Grid Versus Cloud
Asked what will happen to the Worldwide LHC grid as cloud ramps up, Bird says that it will remain. He uses the opportunity to discuss current grid developments. They are running virtual machines on some of the sites, and they are in the process of deploying OpenStack. These projects are designed to improve their internal efficiency as well as the way they run services and provide services, and will also give them additional opportunities to interact with cloud sites.
Bird points to an important distinction between grid and cloud which is one of federation. Grid, despite being a networked collection of distributed computing systems, has evolved to become a highly-unified computing resource. Whereas using multiple cloud providers essentially means you have a collection of disparate resources that are difficult to integrate, even when they’re working together as with Helix Nebula. In addition to the API headaches, there are a myriad of standards and integration pain points to contend with, he says, elaborating further on the grid/cloud dichotomy:
The reason why we used the grid in the first place is because the computing resources that we have access to which are provided by the science funding agencies are physically distributed around the world and we have to have a way of putting these together, so that we did with grid technologies. So for us, the grid is a way of sharing resources and collaborating, while the cloud isn’t really that, it’s more to do with economies of scale. It’s distributed in the way it’s remote from you, but it’s really a different concept. One of the interesting things is how much of that [cloud] technology can we use to improve the way we run our own computer centers simply by not having to support grid infrastructure, but switching that to some cloud technology and how much can we do by buying resources from commercial resources?
As for comparisons between the grid I/O problem versus the cloud I/O problem, Bird observes that while these are similar, this is an area that has received a lot of investment on the grid side. Over the years, the partner institutions have developed dedicated optical private networks between the servers and their large compute centers and they also make significant use of specialized academic networks. When asked if he sees similar developments happening in cloud, Bird is doubtful they’ll happen in the near term, and points to another question for Helix Nebula, which is what is the connectivity of these partners and can we reach them over the academic networks? He says these are among the types of issues they want to pin down in the next couple of years.
On the positive side, Bird notes that networking has changed a lot since the deployment of grid. Prices have come down and data management techniques have become more effective. These developments will be applied to the Helix Nebula project.
Regarding the more specific process of transferring workloads from the grid to the cloud, CloudSigma’s Higgins explains that some of them ported over without too much work, while others have required more extensive retooling due to the numerous changes in the software design practices and machine architectures since these applications were first written. As an illustration, many of the apps in use today were written prior to JAVA and NoSQL databases.
Bird has a somewhat different take on the nitty-gritty details of the cloud migration, saying that they did not need to change the code at all. He explains that the LHC codes fall into the “high-throughput computing” model, where the different pieces of the running code do not need to communicate with each other. The grid resource and cloud resource are basically the same, he notes, i.e., a big cluster of Linux machines. The main difference is how you access this resource and how you move data in and out, however “at the level of real-code running on the machine, it’s the same,” he says.
A Cloud is Not a Cloud
From Bird’s point of view, CERN saw the successful completion of its three proofs of concept. The process entailed running the same simulation workload with the three different cloud providers. The conclusion Bird draws from this, is that while successful, “a cloud is not a cloud is not a cloud.” You cannot just write-once, run-anywhere; there are integration headaches.
According to the grid expert, they absolutely will need an adapter layer that knows how to talk to the different providers. This is essential if they want to use these resources in a dynamic way that involves moving between cloud providers. When asked about a possible performance penalty, he responds that since this is mainly a way to get data into the cloud, any overhead would be likely be negligible. He adds these so-called cloud broker solutions already exist in the open source domain; Deltacloud and libcloud are examples. While this layer adds complexity and could even introduce faults, it’s unavoidable at this stage of the game if you value transparency and interoperability.
Up until now, CERN has been running cloud-friendly workloads with little network I/O dependency. When asked about the HPC cloud bandwidth issue, i.e., the limitations of getting data in and out of the cloud, Bird said this absolutely could be a problem. Their normal data processing workloads involve transferring petabytes of data. During the two-year pilot phase, they will address several issues related to data movement: whether they can move data in and out of the cloud at this scale, whether they can afford to do this, and possible policy issues involved with moving academic data into the commercial domain.
Bird returns to the bottom line, which is cost: “Can we afford to move data in and out and can we afford to store data in the cloud?” he asks.
“There are many different use cases. I think we can overcome the technical issues; the most interesting question is what’s the real cost of doing this and how does it compare with the infrastructure that we have currently?”
Bird gives the impression that while cloud migration has potential, it’s not a “sure thing” and by no means a panacea. How do you get a collection of cloud providers to behave as a federated resource? The first steps involve supplementing the existing grid resources with a few cloud providers, says Bird, which allows those involved to begin the process of learning how to integrate the various pieces.
CloudSigma’s Higgins is most excited about the new science that can be enabled by the cloud as more and more science databases are migrated over. Right now, there are three databases that do not combine to support any practical implications, but the possibilities for meta-analysis are intriguing. For example, with ESA’s earth observation data stored in the cloud, a researcher could ask the World Health Organization for the mosquito outbreak data. This would create a platform where both databases would be available, allowing scientists to expand their research horizons.
This kind of integration requires a lot of work because each database has its own schema. Right now CloudSigma is working on an initiative that is attempting to create master schemas. For example, the earth observation data is linked to latitude and longitude, whereas the mosquito outbreak data is based on distance from a known point on a compass bearing. So the question then is how to marry these distinct data points. The new effort is hammering out a global schema which can make sense of these disparate units so that it becomes a useful tool for researchers. At that point, a scientist could answer queries such as “six miles north of Nairobi, how wet is it and how many mosquitos are we expecting to break out?”
Higgins is confident that creating a rich ecosystem of multiple scientific databases will draw new researchers to the cloud.