Magellan Final Report - Office of Science - U.S. Department of Energy

Magellan Final Report
Applications must be designed to dynamically adjust to compute nodes entering and leaving the resource
pool. They must be capable of dealing with failures and rescheduling work. In traditional clusters, batch
systems are routinely used to manage workflows. Batch systems such as Torque, Sun GridEngine, and
Condor can and have been deployed in virtualized cloud environments [71, 49]. However, these deployments
typically require system administration expertise with batch systems and an understanding of how to best
configure them for the cloud environment. Grid tools can also play a role, but they require the user to
understand and manage certificates and deploy tools like Globus. To lower the entry barrier for scientific
users, Magellan personnel have developed and deployed Torque and Globus-based system images.
Each of our applications have used different mechanisms to distribute work. MG-RAST and the IMG
task farmer are examples of locally built tools that handle this problem. Hadoop might be run on top of
virtual machines for this purpose; however, it will suffer from lack of knowledge of data locality. STAR
jobs are embarrassingly parallel applications (i.e., non-MPI codes), where each job fits in one core and uses
custom scripts to handle workflow and data management.
A majority of our Magellan domain science users, despite previous experience with clouds and virtualization,
ranked their experience with workflow management in virtualized cloud environments as medium to
difficult.
11.4.6 Data Management
The last significant challenge is managing the data for the workload. This includes both input and output
data. For the bioinformatic workloads, the input data includes both the new sequence data as well as the
reference data. Some consideration has to be given to where this data will be stored and read from, how
it will be transported, and how this will scale with many worker nodes. In a traditional batch cluster, the
users would typically have access to a cluster-wide file system. However, with EC2-style cloud systems, there
is a different set of building blocks: volatile local storage, persistent block storage associated with a single
instance (EBS), and a scalable put/get storage system (S3). These are different from traditional cluster
and HPC offerings that users are accustomed to, and hence our users made limited use of these storage
systems. The image also can be used to store static data. Each of these options has differing performance
characteristics that are dependent on the application. Thus, the choice of storage components depends on
the volume of data and the access patterns (and cost, in the case of EC2). Similar to workflow management,
a majority of our users noted that data management in these environments took some effort.
11.4.7 Performance, Reliability and Portability
Scientific applications need to consider performance and reliability of these environments. Our benchmarks
(Chapter 9) show that the performance of an application is largely dependent on the type of application.
Cloud resources have also gained popularity since resources are immediately available to handle spikes
in load etc. However, starting a set of virtual machines can take a few minutes and can be highly variable
when trying to get a large number of VMs [66]. In case of synchronous applications, it will be necessary to
wait until all the virtual machines are up; and the user gets charged in public clouds for the time that the
machines are up, even if they are not being used.
High availability is often mentioned as one of the advantages of cloud resources. It is true that a number
of cloud computing vendors such as Amazon provide various fault tolerance mechanisms, such as availability
zones and regions, to enable highly fault-tolerant applications. However, the burden is largely on the end
users to design their applications to be fault-tolerant, usually at a higher cost. Failures can occur at the
hardware or software level, and good design practices to survive failures must be used when building software
and services. The Amazon outage in April 2011 was triggered by an incorrect network configuration change
made during maintenance that affected multiple services. Applications that used multiple regions were less
impacted by the event. However, the common EBS plane impacted EBS activities. Thus cloud computing
has many of the same availability challenges that impact HPC centers.
116