Results for Project "130. Optimizing Scientific Workflows on Clouds"

We have two on-going projects that have utilized resources provided by FutureGrid.
The first project aims to address the problem of scheduling large workflows onto multiple execution sites with storage constraints. Three heuristics are proposed to first partition the workflow into sub-workflows and then schedule to the optimal execution sites. In our experiments, we deployed multiple clusters with Eucalyptus and up to 32 virtual machines. Each execution site contains a Condor pool and a head node visible to the network. The performance with three real-world workflows shows that our approach is able to satisfy storage constraints and improve the overall runtime by up to 48% over a default whole-workflow scheduling. A paper [1] has been accepted based on this work.
The second project aims to identify the different overheads in workflow execution and to evaluate how optimization methods help reduce overheads and improve runtime performance. In this project, we present the workflow overhead analysis for our runs in FutureGrid deployed with Eucalyptus. We present the overhead distribution and conclude that the overheads satisfy an exponential or uniform distribution. We compared three metrics to calculate the cumulative sum of overhead considering the overlap between overheads. In addition, we indicated how experimental parameters impact the overhead and thereby the overall performance,. We then showed an integrated view over the overheads help us understand the performance of optimization methods better. A paper [2] based on this work has been accepted. In the future, we plan to evaluate the effectiveness of our approach with additional optimization methods. Additionally, our current work is based on static provisioning and we plan to analyze the performance along with dynamic provisioning.
Furthermore, we have developed a workflow simulator called WorkflowSim [5] based on the traces collected from experiments that were run on FutureGrid.

Reference:
[1] Partitioning and Scheduling Workflows across Multiple Sites with Storage Constraints, Weiwei Chen, Ewa Deelman, 9th International Conference on Parallel Processing and Applied Mathematics (PPAM 2011), Poland, Sep 2011
[2] Workflow Overhead Analysis and Optimizations, Weiwei Chen, Ewa Deelman, The 6th Workshop on Workflows in Support of Large-Scale Science, in conjunction with Supercomputing 2011, Seattle, Nov 2011
[3] FutureGrid - a reconfigurable testbed for Cloud, HPC and Grid Computing Geoffrey C. Fox, Gregor von Laszewski, Javier Diaz, Kate Keahey, Jose Fortes, Renato Figueiredo, Shava Smallen, Warren Smith, and Andrew Grimshaw, Chapter in "Contemporary High Performance Computing: From Petascale toward Exascale", editor Jeff Vetter, April 23, 2013 by Chapman and Hall/CRC
[4] Functional Representations of Scientific Workflows, Noe Lopez-Benitez, JSM Computer Science and Engineering 1(1): 1001
[5] WorkflowSim: A Toolkit for Simulating Scientific Workflows in Distributed Environments, Weiwei Chen, Ewa Deelman, The 8th IEEE International Conference on eScience 2012 (eScience 2012), Chicago, Oct 8-12, 2012

Results for Project "430. ICOM4036 Cuda Project"

None Yet.

Results for Project "429. Proto-Runtime on the Grid"

Supplied as they become available: Stay tuned!

Results for Project "426. Comparison of Architectures to Support Deep Learning Applications"

Results for Project "424. Deep Learning with GPUs"

Results for Project "422. Enabling Time-sensitive Applications on Virtualized Computing Systems"

Results for Project "420. QoS-driven Storage Management for High-end Computing Systems"

Results for Project "419. Distributed Real-time Computation System"

Results for Project "418. Course: Cloud Computing Class - fourth edition"

Results for Project "414. Creating a Highly Configurable, Scalable Cloud Test Bed Using Nimbus and Phantom"

Results for Project "412. Short Course on Algorithmic Differentiation"

Results for Project "227. V3VEE Project"

All V3VEE project papers, presentations, and the Palacios codebase are available from v3vee.org. The most relevant papers for this proposal are:

1. L. Xia, Z. Cui, J. Lange, Y. Tang, P. Dinda, P. Bridges, VNET/P: Bridging the Cloud and High Performance Computing Through Fast Overlay Networking, Proceedings of the 21st ACM Symposium on High-performance Parallel and Distributed Computing (HPDC 2012), accepted, to appear. (also TR version) J. Lange, P. Dinda, K. Hale, L. Xia, An Introduction to the Palacios Virtual Machine Monitor---Version 1.3, Technical Report NWU-EECS-11-10, Department of Electrical Engineering and Computer Science, Northwestern University, November, 2011.
2. J. Lange, K. Pedretti, P. Dinda, P. Bridges, C. Bae, P. Soltero, A. Merritt, Minimal Overhead Virtualization of a Large Scale Supercomputer, Proceedings of the 2011 ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments (VEE 2011), March, 2011.
3. J. Lange, K. Pedretti, T. Hudson, P. Dinda, Z. Cui, L. Xia, P. Bridges, A. Gocke, S. Jaconette, M. Levenhagen, R. Brightwell, Palacios and Kitten: New High Performance Operating Systems for Scalable Virtualized and Native Supercomputing, Proceedings of the 24th IEEE International Parallel and Distributed Processing Symposium (IPDPS 2010), April, 2010.

Results for Project "344. Exploring map/reduce frameworks for users of traditional HPC"

1. Guide to Running Hadoop Clusters on Traditional HPC
2. Guide to Writing Hadoop Jobs in Python with Hadoop Streaming
3. Guide to Parsing Variant Call Format (VCF) Files with Hadoop Streaming

Source code for these guides is also available on GitHub.  Work is ongoing.

Results for Project "172. Cloud-TM"

2012

Sebastiano Peluso, Pedro Ruivo, Paolo Romano, Francesco Quaglia, and Luis Rodrigues

When Scalability Meets Consistency: Genuine Multiversion Update Serializable Partial Data Replication

32nd International Conference on Distributed Computing Systems (ICDCS'12)

Diego Didona, Pierangelo Di Sanzo, Roberto Palmieri, Sebastiano Peluso, Francesco Quaglia and Paolo Romano,

Automated Workload Characterization in Cloud-based Transactional Data Grids

17th IEEE Workshop on Dependable Parallel, Distributed and Network-Centric Systems (DPDNS'12)

 

Paolo Romano,

Elastic, scalable and self-tuning data replication in the Cloud-TM platform,

Proceedings of 1st European Workshop on Dependable Cloud Computing (EWDCC'12)

Paolo Romano and M. Leonetti,

Self-tuning Batching in Total Order Broadcast Protocols via Analytical Modelling and Reinforcement Learning

IEEE International Conference on Computing, Networking and Communications, Network Algorithm & Performance Evaluation Symposium (ICNC'12), Jan. 2012

 

2011     

 

Self-optimizing transactional data grids for elastic cloud environments, P. Romano, CloudViews 2011    

 

Boosting STM Replication via Speculation, P. Romano, R. Palmeri, F. Quaglia, L. Rodrigues, 3rd Workshop on the Theory of Transactional Memory

 

Data Access Pattern Analysis and Prediction for Object-Oriented Applications, S. Garbatov, J. Cachopo, INFOCOMP Journal of Computer Science, December 2011

 

Software Cache Eviction Policy based on Stochastic Approach, S. Garbatov, J. Cachopo, The Sixth International Conference on Software Engineering Advances (ICSEA 2011), October 2011

 

Optimal Functionality and Domain Data Clustering based on Latent Dirichlet Allocation, S. Garbatov, J. Cachopo, The Sixth International Conference on Software Engineering Advances (ICSEA 2011), October 2011

 

Strict serializability is harmless: a new architecture for enterprise applications, S. Fernandes, J. Cachopo, Proceedings of the ACM international conference on Object oriented programming systems languages and applications companion

 

Towards a simple programming model in Cloud Computing platforms, J. Martins, J. Pereira, S.M. Fernandes, J. Cachopo, First International Symposium on Network Cloud Computing and Applications (NCCA2011)

 

On Preserving Domain Consistency for an Evolving Application, J. Neves, J. Cachopo, Terceiro Simpósio de Informática, September 2011

 

Oludap, an AI approach to web gaming in the Cloud, V. Ziparo, Open World Forum 2011, September 2011

 

Towards Autonomic Transactional Replication for Cloud Environments, M.  Couceiro, P. Romano, L. Rodrigues, European Research Activities in Cloud Computing

 

SPECULA: um Protocolo de Replicação Preditiva para Memória Transaccional por Software Distribuída, J. Fernandes, P.  Romano, L. Rodrigues, Simpósio de Informática, Universidade de Coimbra (INFORUM 2011)  

 

Replicação Parcial em Sistemas de Memória Transaccional, P. Ruivo, P. Romano, L., Rodrigues, Simpósio de Informática, Universidade de Coimbra (INFORUM 2011)

 

Integrated Monitoring of Infrastructures and Applications in Cloud Environments, R. Palmieri, P. Di Sanzo, F. Quaglia, P. Romano, S. Peluso, D. Didona, Workshop on Cloud Computing: Projects and Initiatives (CCPI 2011)

 

PolyCert: Polymorphic Self-Optimizing Replication for In-Memory Transactional Grids, M. Couceiro, P. Romano and L. Rodrigues, ACM/IFIP/USENIX 12th International Middleware Conference (Middleware 2011)

 

Exploiting Total Order Multicast in Weakly Consistent Transactional Caches, P. Ruivo, M. Couceiro, P. Romano and L. Rodrigues, Proc. IEEE 17th Pacific Rim International Symposium on Dependable Computing (PRDC’11)

 

Tutorial on Distributed Transactional Memories, M. Couceiro, P. Romano and L. Rodrigues, 2011 International Conference on High Performance Computing & Simulation July 2011

 

Keynote Talk: Autonomic mechanisms for transactional replication in elastic cloud environments, P. Romano, 2nd Workshops on Software Services (WOSS), Timisoara, Romania, June 2011

 

Self-tuning Batching in Total Order Broadcast Protocols via Analytical Modelling and Reinforcement Learning , P. Romano and M. Leonetti, ACM Performance Evaluation Review, to appear (also presented as a Poster at IFIP Performance 2011 Symposium)

 

On the Analytical Modeling of Concurrency Control Algorithms for Software Transactional Memories: the Case of Commit-Time-Locking, P. Di Sanzo, B. Ciciani, F. Quaglia, R. Palmieri and Paolo Romano, Elsevier Performance Evaluation Journal (to appear)

 

OSARE: Opportunistic Speculation in Actively REplicated Transactional Systems, R. Palmieri, F. Quaglia and Paolo Romano, The 30th IEEE Symposium on Reliable Distributed Systems (SRDS 2011), Madrid, Spain, to appear.

 

A Generic Framework for Replicated Software Transactional Memories, N. Carvalho, P. Romano and L. Rodrigues, , Proceedings of the 9th IEEE International Symposium on Network Computing and Applications (NCA), Cambridge, Massachussets, USA, IEEE Computer Society Press, August 2011

Autonomic mechanisms for transactional replication in elastic cloud environments (Keynote Talk), Workshop on Software Services: Cloud Computing and Applications based on Software Services, Paolo Romano, Timisoara, June 2011

 

SCert: Speculative Certification in Replicated Software Transactional Memories. N. Carvalho, P. Romano and L. Rodrigues. 
Proceedings of the 4th Annual International Systems and Storage Conference (SYSTOR 2011), Haifa, Israel, June 2011.
 

2010

 

Asynchronous Lease-based Replication of Software Transactional Memory. N. Carvalho, P. Romano and L. Rodrigues. Proceedings of the ACM/IFIP/USENIX 11th Middleware Conference (Middleware), Bangalore, India, ACM Press, November 2010.

 

Analytical Modeling of Commit-Time-Locking Algorithms for Software Transactional Memories. P. Di Sanzo, B. Ciciani, F. Quaglia, R. Palmieri and P. Romano. Proceedings of the 35th International Computer Measurement Group Conference (CMG), Orlando, Florida, Computer Measurement Group, December 2010 (also presented in the 1st Workshop on "Informatica Quantitative" (InfQ), Pisa, July 2010)

 

Do we really need parallel programming or should we strive for parallelizable programming instead? João Cachopo. SPLASH 2010 Workshop on Concurrency for the Application Programmer. October, 2010.

 

A Machine Learning Approach to Performance Prediction of Total Order Broadcast Protocols. M. Couceiro, P. Romano and L. Rodrigues. Proceedings of the 4th IEEE International Conference on Self-Adaptive and Self-Organizing Systems (SASO), Budapest, Hungary, IEEE Computer Society Press, September 2010

 

An Optimal Speculative Transactional Replication Protocol. P. Romano, R. Palmieri, F. Quaglia, N. Carvalho and L. Rodrigues. Proceedings of the 8th IEEE International Symposium on Parallel and Distributed Processing with Applications (ISPA), Taiwan, Taipei, IEEE Computer Society Press, September 2010.

 

Results for Project "84. Development of an Index File System to Support Geoscience Data with Hadoop"

My results are uploaded at this link : https://slashtmp.iu.edu/files/download?FILE=skarwa%2F98132iCfiVK

The Password to download : futuregrid

Results for Project "214. Mining Interactions between Network Community Structure and Information Diffusion"

1. Lilian Weng, Filippo Menczer, Yong-Yeol Ahn, "Community structure and Spreading of Social Contagions" (Preprint, to be submitted to WWW'13)

Results for Project "313. HyFlowTM"

This is the link of the project http://www.hyflow.org/hyflow and here there are all the papers and technical reports in the context of the project: http://www.hyflow.org/hyflow/wiki/Publications

Results for Project "166. Parallel watershed and hdyrodynamic models"

Tempest cluster in Future grid was used to support the work in the following publications: 

1. Babbar-Sebens, M., Barr, R.C., Tedesco, L.P., Anderson, M., 2013. Spatial identification and optimization of upland wetlands in agricultural watersheds. Ecological Engineering, 52, pp. 130– 142.

Results for Project "18. Privacy preserving gene read mapping using hybrid cloud"

One of the most important analyses on human DNA sequences is read mapping, which aligns a large number of short DNA sequences (called reads) produced by sequencers to a reference human genome. The analysis involves intensive computation (calculating edit distances over millions upon billions of sequences) and therefore needs to be outsourced to low-cost commercial clouds. This asks for scalable privacy-preserving techniques to protect the sensitive information sequencing reads contain.  Such a demand cannot be met by the existing techniques, which are either too heavyweight to sustain data-intensive computations or vulnerable to re-identification attacks.  Our research, however, shows that simple solutions can be found by leveraging the special features of the mapping task, which only cares about small edit distances, and those of the cloud platform, which is designed to perform a large amount of simple, parallelizable computation. We implemented and evaluated such new techniques on a hybrid cloud platforms built on FutureGrid.  In our experiments, we utilized specially-designed techniques based on the classic “seed-and-extend” method to achieve secure and scalable read mapping. The high-level design of our techniques is illustrated in the following figure:  the public cloud on FutureGrid is delegated the computation over encrypted read datasets, while the private cloud directly works on the data. Our idea is to let the private cloud undertake a small amount of the workload to reduce the complexity of the computation that needs to be performed on the encrypted data, while still having the public cloud shoulder the major portion of a mapping task.

We constructed our hybrid environment over FutureGrid in the following two modes:

1.  Virtual mode:

We used 20 nodes on FutureGrid as the public cloud and 1 node as the private cloud.

2. Real mode:

We used nodes on FutureGrid as the public cloud and the computing system within the School of Informatics and Computing as the private cloud. In order to get access to the all the nodes on public cloud, we copied a public SSH key shared by all the private cloud nodes to the authorized_keys files on each public cloud node.

Our experiments demonstrate that our techniques are both secure and scalable.    We successfully mapped 10 million real human microbiome reads to the largest human chromosome over this hybrid cloud.   The public cloud took about 15 minutes to do the seeding and the private cloud spent about 20 minutes on the extension.  Over 96% of computation was securely outsourced to the public cloud.

Results for Project "290. Open Source Cloud Computing"

Results for Project "42. SAGA"

Interoperable and Standards-based Distributed Cyberinfrastructure and Applications

Abstract:
Advances in many areas of science and scientific computing are predicated on rapid progress in fundamental

computer science and cyberinfrastructure, as well as their successful uptake by computational scientists. The

scope, scale and variety of distributed computing infrastructures (DCIs) currently available to Scientists and

CS researchers is both an opportunity, and a challenge. DCI present an opportunity, as they can support the

needs of a vast range and number of science requirements and usage-modes. The design and implementation

of DCI itself present a formidable intellectual challenge, not least because of the challenges in providing

interoperable tools and applications given the heterogeneity and diversity of DCIs.
 

Interoperability - standards based as well as otherwise, is an important necessary (though not sufficient

condition) system and application feature for the effective use of DCI and its scalability. This project report

presents a selection of results from Project No. 42 (SAGA) which makes use of FutureGrid to develop

the software components, runtime frameworks and to test and verify their usage, as well as initial eorts in

incorporating these strands into Graduate curriculum. Specially, we discuss our work on P* - a model for

pilot abstractions, and related implementations which demonstrate (amongst others) interoperability between

different pilot-job frameworks. In addition to the practical benefits interoperable and extensible pilot-

job framework, P* provides a fundamental shift in the state-of-the-art of tool development: for the first time

that we are aware, thanks to P* there now exists a theoretical and conceptual basis upon which to build the

tools and runtime systems. We also discuss standards based approaches to software interoperability, and the

related development challenges { including SAGA as a standards based generic access layer to DCIs. Finally,

we conclude by establishing how these strands have been brought together in a Graduate Classroom.

The full version of the report is available here.

Results for Project "284. Class Assignment: Map Reduce Comparison"

The students will most likely use Hotel and india

So far one student of the class has contacted us. All other students will join this project.

Results for Project "261. Investigation of Data Locality and Fairness in MapReduce"

Our experiment results show that our proposed algorithms improve data locality and outperform the default Hadoop scheduling substantially. For example, the ratio of data-local tasks is increased by 12% - 14% and the cost of data movement is reduced by up to 90%.
The detailed results of this project have been presented in two papers: "Investigation of data locality and fairness in MapReduce" [bib]Guo:2012:IDL:2287016.2287022[/bib], and "Investigation of Data Locality in MapReduce" [bib]fg-261-05-2012-a[/bib].

Results for Project "175. GridProphet, A workflow execution time prediction system for the Grid"

Project brief:

This project was initiated as part of a larger project titled “A provenance and performance prediction system for Grid systems”. The objective of the main project is to develop a grid performance prediction system, which can estimate the execution time of individual workflow tasks, single-entry-single-exit sub-workflows (e.g. loops), and entire workflows for scientific applications such that the prediction technology can be used to rank different workflow transformations or workflow versions with respect to their execution time behavior. The proposed system can be used for optimization of workflow applications, thus enabling scientists to better utilize computing resources and reach their scientific results in shorter time.

The objective of the utilization of Future Grid resources was to collect trace data for training the machine learning systems. The data collected using the Future Grid resources is used along with the data traces collected in the Austrian Grid and the Grid5000.

Experimental setup:

Grid-Appliance provided by Future Grid portal is used in varying configuration to setup the Virtual Grid required to serve the project objective.

Based on the project requirements trace collection was to be performed for the following applications.

• MeteoAG (Meteorology Domain)
• Wien2K (Material Science Domain)
• InvMod (Alpin River Modeling)

The goal was to record trace collection data for atleast 5000 workflow runs in total with varying background load and dynamic distribution of tasks on different sites in the virtual Grid.

For this purpose the Grid-Appliance was customized in different aspects. Additional software packages were added required for the execution of the workflow execution system (ASKALON) and the workflows themselves. A database server was installed to collect the trace data during the experiments.

Trace Data:

A set of key features having noticeable importance during the execution of these workflows on the Grid infrastructure was identified. These selected features covered most of the factors associated to Grid workflow execution such as input to the application workflow, size of the input data, size of application executables, Network associated features like available bandwidth, bandwidth background load, time required to transfer the application data across computer nodes. Moreover both the dynamic and static environment associated parameters are also collected which include the information about the machine architecture, compute power, cache memory and disk space etc. A total number of 65 parameters are selected for use to get accurate predictions and for a rich machine learning based training of the prediction model.

Optimization of the Feature Vectors:

For use with the machine learning system the main feature vector is shortlisted to select a small number of parameters, so that the machine learning process can be carried out swiftly and accurately. Having a large number of input parameters results in very long training times and also introduces lots of noise in the data.

We recorded a large number of run-time parameters so as not to miss any important feature. But for the training of the model we needed to optimize the feature space so that the problems associated with the noise and long training durations can be avoided. Principal component analysis and Principal Feature selection algorithms are used for optimization of the feature space and an optimized feature vector is generated that have maximum influence on the execution of the tasks in distributed environments.

Utilization of Trace Data:

A neural network based machine learning system known as Multilayer Perceptron (MLP) is used. MLP is a Feedforward neural network system for training machine learning models and is used for pattern matching in non linear problem spaces. It maps the sets of inputs presented at the input layers of the network to outputs at the output layer. In contrast to the traditional neural networks MLP may have one or more hidden layers. An activation function determines the threshold value of the network at each node which acts a neuron for the neural network.

For our experiments the trace data collected from the Future Grid infrastructure was used along-with the data collected from other Grid infrastructures like that of Austrian Grid and the Grid5000.

The training results presented herewith are therefore not specific to Future Grid only.

Performance Prediction Results:

Based on our experiments and the machine learning system described above the following activity level predictions accuracy has been achieved.

Workflow: Wien2k

Total successful runs: 700

One activity maximum prediction accuracy: 65.70%

Two activities maximum prediction accuracy: 52.70%

Activity	Cluster	Prediction Accuracy
LAPW1	1	65.70%
LAPW1	2	63.00%
LAPW2	1	64.00%
LAPW2	2	60.00%
LAPW1,LAPW2	1	58.00%
LAPW1,LAPW2	2	56.00%
LAPW1,LAPW2	1	54.00%
LAPW1,LAPW2	2	52.00%

Single workflow prediction accuracy

The results presented above are quite promising for an initial investigation and therefore we are quite eager to continue this research to get even better results. Experimental workflow runs are in progress using the Future Grid resources to have more trace data for improved performance prediction accuracy.

Results for Project "185. Co-Resident Watermarking"

Our use of Futuregrid led to an accepted paper at the 2012 ACM Cloud Computing Security Workshop entitled "Detecting Co-Residency with Active Traffic Analysis Techniques".  This work will be presented on 19 October, 2012.  Futuregrid is featured in the acknowledgements section.  A copy of the paper is available at:

http://ix.cs.uoregon.edu/~amb/documents/Bates_Ccsw12.pdf

Results for Project "118. Testing new paradigms for biomolecular simulation"

The first papers on this project have been submitted; references and details will be provided upon publication.

Results for Project "27. Evaluation of Hadoop for IO-intensive applications"

The results are presented in detail in the file http://archive.futuregrid.org/sites/default/files/HadoopEvaluationResults.pdf.

Results for Project "216. Scaling-out CloudBLAST: Deploying Elastic MapReduce across Geographically Distributed Virtulized Resources for BLAST"

The overall integration of technologies has been described in http://escience2008.iu.edu/sessions/cloudBlast.shtml. It also presents the low overhead imposed by the various technologies (machine virtualization, network virtualization) utilized, the advantages using a MapReduce framework for application parallelization over traditional MPI techniques in terms of performance and fault-tolerance, and the extensions to Hadoop required to integrate an application like the NCBI BLAST.
Challenges to the network virtualization technologies to enable inter-cloud communication, and a solution to overcome them called TinyVine is presented in http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5380884. A comparative analysis of existing solutions addressing sky computing requirements is presented along with experimental results that indicates negligible overhead for embarrassingly parallel applications such as CloudBLAST, and low overhead for network intensive applications such as secure copy of files.
In the largest experiment using FutureGrid (3 sites) and Grid’5000 (3 sites) resources, a virtual cluster of 750 VMs (1500 cores) connected through ViNe/TinyViNe was able to execute CloudBLAST achieving speedup of 870X. To better handle the heterogeneous performance of resources, an approach that skews the distribution of MapReduce tasks was shown to improve overall performance of a large BLAST job using FutureGrid resources managed by Nimbus (3 sites). Both results can be found in http://www.booksonline.iospress.nl/Content/View.aspx?piid=21410.

Table 1. Performance of BLASTX on sky-computing environments. Speedup is computed as the time to execute a BLAST search sequentially divided by the time to execute using the cloud resources. A computation that would require 250 hours if executed sequentially, can be reduced to tens of minutes using sky computing.

Experiment	Number of Clouds	Total VMs	Total Cores	Speedup
1	3	32	64	52
2	5	150	300	258
3	3	330	660	502
4	6	750	1500	870

 


Figure 1: Comparison of executions of a 50000-sequence BLAST job divided into 256 tasks with (a) uniform or (b) skewed sizes on 660 processors across 3 different sites (University of Chicago, University of Florida, and San Diego Supercomputing Center). The progress of time is shown in the horizontal axis and the vertical axis represents each of the 660 individual workers. In this particular setup, the overall time perceived by the end user when running with skewed tasks is 8% shorter than when running with uniform tasks.

Results for Project "120. Workshop: A Cloud View on Computing"

The hands-on workshop was June 6-10, 2011. Participants were immersed in a “MapReduce boot camp”, where ADMI faulty members sought introduction to the MapReduce programming framework. The following were themes for five boot camp sessions:

• Introduction to parallel and distributed processing
• From functional programming to MapReduce and the Google File System (GFS)
• “Hello World” MapReduce Lab
• Graph Algorithms with MapReduce
• Information Retrieval with MapReduce

An overview of parallel and distributed processing provided a transition into the abstractions of functional programming, which introduces the context of MapReduce along with its distributed file system. Lectures focused on specific case studies of MapReduce, such as graph analysis and information retrieval. The workshop concluded with a programming exercise (PageRank or All-Pairs problem) to ensure faculty members have a substantial knowledge of MapReduce concepts and the Twister/Hadoop API.

For more information, please visit http://salsahpc.indiana.edu/admicloudyviewworkshop/

Results for Project "198. XSEDE Campus Bridging Rocks Roll testing"

results will be software installation packages that work -- when we have some, I'll link to them here.

Results for Project "95. Comparision of Network Emulation Methods"

The experiment consisted of host-to-host Iperf TCP performance while increasing parallel streams and inducing RTT latency utilizing FutureGrid's Spirent XGEM Network Impairments device.  The hosts were two IBM x3650's with Broadcom NetExtreme II BCM57710 NIC's.  RedHat release 5.5 Linux distribution was installed on each host, keeping stock kernel tuning in place.  An ethernet (eth0) interface on each host was connected back-to-back while the second ethernet (eth1) passed through the Spirent XGEM and Nexus 7018 using an untagged VLAN, as illustrated in the attached diagram.



The direct host-to-host link saw an average delay of .040 ms while the path through the XGEM (.004 ms) and Nexus (.026 ms) was .080 ms.

Dual five minute unidirectional TCP Iperf tests were conducted, one each across the direct and switched path.  Tests were initiated independently and occurred at approximately the same start time with a deviation of +/- 3 seconds initiation.  Results were gathered for each direct (D) and switched (S) test.  Follow-up tests were executed increasing the number of parallel streams Iperf (command line option -P) could transmit.  The number of streams included single, sixteen, thirty-two, sixty-four and ninety-six.  Delay was added via the Spirent at increments of default (.080 ms), 4.00 ms, 8.00 ms, 16.00 ms, 32.00 ms, 64.00 ms, 96.00 ms and 128.00 ms RTT.  The matrix yielded forty data points.  Additionally the experiments were repeated utilizing two different kernel tuning profiles, increasing the data points to 80 and 120.  The data points and graph (only switched path) show that as delay increased overall TCP performance increased as the number of parallel threads were increased.

Detailed results can be found in the attached text and excel files.

Results for Project "2. Deploy OpenNebula on FutureGrid"

At this time we do have a small OpenNebula cloud installed internally for the FG software Group. This Group uses this cloud as part of the image management.

Presentations:

• fg-1280

Results for Project "80. Genesis II testing"

Genesis II scale testing is being performed in the context of the Cross-Campus Grid (XCG), which brings together resources from around Grounds as well as at FutureGrid.  The XCG provides access to a variety of heterogeneous resources (clusters of various sizes, individual parallel computers, and even a few desktop computers) through a standard interface, thus leveraging UVa’s investment in hardware and making it possible for large-scale high-throughput simulations to be run.  Genesis II, a software system developed at the University by Prof. Andrew Grimshaw of the Computer Science Department and his group, implements the XCG. Genesis II is the first integrated implementation of the standards and profiles coming out of the Open Grid Forum (the standards organization for Grids) Open Grid Service Architecture Working Group.
 
The XCG is used across a variety of disciplines at UVA, including Economics, Biology, Engineering, and Physics.  The services offered by the XCG provide users with faster results and greater ability to share data.  By using the XCG, a researcher can run multiple jobs tens to hundreds of times faster than would be possible with a single desktop. The XCG also shares or “exports” data. Local users and XCG users can manipulate the exported data.  Through the XCG we also participate in projects supported by the National Science Foundation’s XD (extreme digital) program for supercomputing initiatives.

Results for Project "157. Resource provisioning for e-Science environments"

 0. Environment inspection

 Eucalyptus environment tested, identified a working set of
 (image, kernel, ramdisk), inspection of a running VM instance
 to extrapolate underlying configuration (virtual devices, kernel
 and kernel modules) for subsequent custom image setup

 1. VM setup

 Setup and deployed custom VM images

 - VM for publishing a Java web service: JRE and web service are
   dynamically downloaded and executed immediately after boot; a
   start-up script is in charge of downloading the web service
   configuration from a public URL 

 - VM for publishing an Apache ODE workflow engine (deployed inside an
   Apache Tomcat container) and a supervisor web service; a
   start-up script is in charge of downloading the workflows (BPEL
   processes) to be deployed into the engine; the supervisor service
   is in charge of downloading workflow input from a public URL and
   enacting one or more workflow instances

 2. VM test

 Deployed VM images have been manually instantiated to verify the correct
 behavior of start-up scripts

 3. Programmatic VM interaction

 Programmatic VM instance creation and termination has been
 successfully achieved through the EC2 APIs by means of the jclouds
 library

Results for Project "78. Exploring VMs for Open Science Grid Services "

The Open Science Grid Operations Center runs several services
enabling users to locate resources and generally use the OSG.
With this project we have investigated the possibility of
virtualizing the few remaining components that are not already
available as virtual machines. In particular, we have built a
"Compute Element", a basic resource unit for the OSG. Currently,
there are a few small technical details to work out. Eventually,
we intend to demonstrate a usable Compute Element integrated
into the usual list of OSG resources.

Results for Project "50. Performance evaluation of MapReduce applications"

Extended Abstract : Performance evaluation of  MapReduce applications                                        

Yunhi Kang
Pervasive Technology Institute at IU
Bloomington, IN
e-mail: yunh.kang@gmail.com
 
Abstract
 
The purpose of this project  is focused on evaluating performance of two kinds of MapReduce applications: a data intensive application and a computational intensive application.  For this work, we construct a virtualized cluster systems made of   the VM instances for experiments  in the FutureGrid.   What we have observed in the experiments is that the overall performance of a data intensive application is strongly affected by the throughput of the messaging middleware since it is required to transfer data in a map task and a reduce task.   However the performance of computational intensive application is associated with CPU throughput. We have investigated the performance of these MapReduce applications on Future Grid and have done detailed performance variation studies. The results of this experiment can be used for selecting the proper configuration instances in the FutureGrid.  It can be used to identify the bottleneck of the MapReduce application running on the virtualized cluster system with various VM configurations. We conclude that performance evaluation according to the type of specific application is essential to choose properly a set of instances in the FutureGrid.  
 

    I.           Overview of experiment

A.   Experiment Environment

In this experiment, a virtualized cluster system composed of a group of an instance is allocated from india cluster, which is one of FuturGrid environments.   Each instance provides a predictable amount of dedicated compute capacity that is defined in FutureGrid.   The following instance types are used to the experiments:
·       c1-medium
·       m1-large
·       m1-xlarge
 
We make a configuration for a virtualized cluster system as tested and use various configurations that are used to evaluate performance of two types of a MapReduce application.  A configuration has various middleware setups. It is used to represent two different workloads. For example, sim-c1-ml represents an unbalanced load allocation and sim-2-ml represents a balanced load allocation.  
 
The MapReduce application is implemented on a system using:
·       Twister 0.8
·       Naradabroker 4.2.2
·       Linux 2.6.x running on Xen

Before diving into the MapReduce algorithm, we set up virtualized cluster systems of the cloud architecture.  To set up the virtualized   cluster systems, we deploy images and run the instances.  We use a Linux command top that provides a dynamic real-time view of a running system, including information about system resource usage and a constantly updated list of the processes which are consuming the most resources. This can be one of the most useful ways to monitor the system as it shows several key statistics. We set the top command as batch mode, 1 sec. update and 1000 samples to monitor resource usage. By using a tool, top we get the trace of memory and load average while a MapReduce application is running in a specific VM environment.
 

B.    Restrictions of the experiment

This experiment is a micro-level evaluation that is focused on the nodes provided and the application running on them.
·       The applications of which are used in the experiment follow a MapReduce programming model
·       With regard to this experiment, resource allocation considers in a static way that means how to select computing resources to optimize a MapReduce application running on the nodes
·       Performance evaluation is based on the samples, representing a system snapshot of the work system, collected from a command top while a MapReduce application is running
  

    II.          Experiment: Data intensive Application

In this experiment, two different computing environments are evaluated, which are running a data intensive application written in MapReduce programming modeling with various configurations: one is a cluster system composed of real machines and the other is a virtualized cluster computing system. For this work, we construct a MapReduce application is used to transforms a data set collected from a music radio site, Last.fm(http://www.last.fm/) that provide the metadata for an artist includes biography by API,   on the  Internet. The goal program is to histogram the counts referred by  musicians and to construct a bi-directed graph based on similarity value between musicians in the data set.
We compare both environments with application’s performance metrics in terms of elapse time and standard variation.  The graph in Figure 1 deals with the results using the MapReduce application.  In the part of the graph, sim-c1-m1-1 to type sim-2-ml, we see that as the resources of VMs including CPU and memory increase, the elapse time of the application and the value of its standard variation decreases.  What we observe that the number of CPUs has less impact on the elapse time in comparison to the results of sim-c1-m1-2 and sim-2-m1. Though performance degrades as the application runs in the virtualization environment, the performance of sim-2-ml still provides 80.9% of the average performance of sim-gf14-fg15 and sim-india when running  the real computing environment. However the elapse time of type sim-2-ml is 98.6  % of the elapse time of sim-fg14-fg15.
 
Figure 1.    Elapse time of similarity: 6 configurations - Cluster system(3 types) and Virtualized cluster system(2 types) 

Figures  2 and 3 show the load averages as the program  runs on different middleware configurations  even if  those computing resources have the same configuration computing resource that consists of 1 c1-medium and 1 m1-large.  We consider two middleware configurations: one is the message broker is run in the node (194) typed with c1-medim. Other is run in the node (196) type m1-medim.  As shown in Figures  2 and 3,  the overall workload of  sim-c1-ml-2   is less than one of sim-c1-m1-2.   In sim-c1-m1-1, the average number of running processes is 3.24 and its maximum number of running process is   4.97.  The figure 2 shows the node has been overloaded 224% during the application running time.  On the other hand, the average number of running processes is 0.80 and its maximum number of running process is   4.97 in sim-c1-m1-2. During the running time (342sec), the CPU was underloaded 20%.
 
According to this result, performance of a virtualized cluster system is affected by the middleware configuration depends on the location of the message broker that send and receive the message to/from application. The gap of performance is caused by CPU and memory capability of the node running the message broker. What we have observed is that the application is   more I/O oriented job that needs more memory than CPU power. We can expect more high throughput when the node typed with c1-medium may be replaced with other node typed with m1-large.
 
 

Figure 2.    Load average of sim-c1-m1-1(NB running on the node typed with c1-medium)

 
Figure 3.    Load average of sim-c1-m1-2(NB running on the node typed with m1-medium)

III.  Experiment: Computation intensive application

To do performance evaluation of a MapReduce application typed computation intensive, one configuration, xlarge, is added to the testbed.  In this experiment, we use k-means algorithm with 100,000 data points, which is to organize these points into k clusters. We compare both environments, a virtual cluster computing system and a cluster system, with application’s performance metrics in terms of elapse time and standard variation.  Figure 4 shows the elapse time of k-means. Our experiment indicates that the average elapse time can increase by over 375.5% in virtualized cluster computing system, in comparison with cluster system, india.  Besides the elapse time decreases proportional as VM’s CPU capability is added to the virtualized cluster computing system.  Furthermore the standard deviation is less affected by configuration change and the size of input data.    In the real cluster system, the value remains very low at about 1-2% of the variation of elapse time due to the capability of system mainly related with CPU power.  In addition, the standard variation in the three configurations of the virtualized cluster computing system remains low at about 2.0-3.78%.   A similar trend is observed by in the values of standard deviation of all configurations. Hence we can expect that as the number of available VMs increases, there is a proportional improvement of elapse time.  
 


Figure 4.    Elapse time of  k-means: 6 configurations - Cluster system(4 types) and Virtualized cluster system(1 types) 
 
 

   IV.          Summary of the experiments  

 In summary, performance evaluation based on the metrics, load average and memory/swap area usage, according to the type of specific application is essential to choose properly a set of instances in the FutureGrid.  Based on the performance evaluation we may choose the configuration of a virtualized cluster system to provide 80% of performance of a real cluster system.  
 
·       The performance of the application running on the Twister strongly depends on the throughput of a message broker, Naradabroker.
·       The pending of the application is caused by broken pipe between a Twister daemon and a Naradabroker server when Naradabroker has a threshold of the limitation to accept a connection from Twister due to its QoS requirement.
·       The capability of Naradabroker in the middleware configuration affects the performance   of an application as the application runs in the same configuration computing resource.

 
Acknowledgement

The paper entitled "Performance Evaluation of MapReduce applications on Cloud Computing Environment, FutureGrid" is accepted in the conference GDC 2011 that will be held  in Jeju,  KOREA on December 8-10.  This paper is partial fulfillment of  this FutureGrid Project.

Results for Project "4. Word Sense Disambiguation for Web 2.0 Data"

Using this project we realized there was a gap in researchers creating reproducible eScience experiments in the cloud. So, the research shifted to tackle this problem. Towards this goal, we had a paper accepted to the 3rd IEEE International Conference on Cloud Computing Science and Technology titled "Towards Reproducible eScience in the Cloud."
 (http://www.ds.unipi.gr/cloudcom2011/program/accepted-papers.html).

In this work, we demonstrated the following:

• The construction of scalable computing environments into two distinct layers: (1) the infrastructure layer and (2) the software layer.
• A demonstration through this separation of concerns that the installation and configuration operations performed within the software layer can be re-used in separate clouds.
• The creation of two distinct types of computational clusters, utilizing the framework.
• Two fully reproducible eScience experiments built on top of the framework.

Results for Project "17. Comparison of MapReduce Systems"

We started a project that evaluate latest version of DryadLINQ founded by MS in December 2010.
We evaluated the programmability and performance of DryadLINQ CTP for data intensive applications in HPC cluster.

The solid results include:
1) Technical report about DryadLINQ CTP Evaluation in July 2011
2) Technical paper in DataCloud-SC11 in Nov 2011

 Note: we do not use FG resources this time. We would like to evaluate Dryad cluster when they are available on FutureGrid.

Results for Project "116. HPC Scheduling"

Topology scheduling:  To support 3d-torus switch clusters, such as the SDSC Gordon cluster,
topology-aware scheduling code was added to the Catalina Scheduler http://www.sdsc.edu/catalina.
When the relationship of nodes to each other, rather than simply individual node attributes,
affects job performance, it becomes necessary to generate schedules using relationship information.
A method to do this for arbitrary switch topologies was added to Catalina Scheduler. The Futuregrid
Nimbus capability was used to create virtual clusters for scheduler development and testing.
Without this facility, this development effort would not have been possible.
This will allow more efficient resource allocation of resources to jobs, depending on job switch requirements.

Virtual Machine Scheduling:  Use of Virtual Machines in batch systems to increase scheduling
flexibility has been proposed by others.  With the goal of developing a prototype system
capable of doing this, existing OpenNebula facilities were used to start development of
a SLURM-based http://www.schedmd.com VM scheduling system, with suspend/resume
and migrate capabilities.  Because we needed access to low-level OpenNebula functions,
Futuregrid very graciously accomodated us with direct access to compute resources.
Using these resources, we were able to develop the system to the point where SLURM
and a prototype external scheduler are able to convert a job script to a set of OpenNebula
VM machine specifications and start the job with those VMs.

Results for Project "99. Cloud-Based Support for Distributed Multiscale Applications"

The one part of our research was aimed at investigating the usability of business metrics for scaling policies in the cloud using the SAMM monitoring and management system. This system allows for autonomous decision making on the actions to be applied to the
monitored systems based on the retrospective analysis of their behavior over a period of time.   The development work and tests were carried out using the FutureGrid project environment .The India Eucalyptus cluster was
used. The following virtual machine types were provided: small - 1 CPU, 512 MB of RAM, 5 GB of storage space, medium  - 1 CPU, 1024 MB of RAM, 5 GB of storage space, large  - 2 CPUs, 6000 MB of RAM, 10 GB of storage space, xlarge - 2 CPUs, 12000 MB of RAM, 10 GB of storage space, xlarge - 8 CPUs, 20000 MB of RAM, 10 GB of storage space. The test  involved a numerical integration algorithm, while exploiting a master-slave paradigm.

The cluster is built up from 50 nodes and each node is able to run up to 8 small instances. Slave nodes in our application do not use much storage space and memory. To have got a fine-grained level of the management of the computing power, we decided to use small instances for them. The Master node application had higher memory requirements, thus we deployed it on a medium instance.  To evaluate the quality of our approach we compared two strategies of automatic scaling. The first one exploits a generic metric - the CPU usage. The second strategy uses a business metric . The average time spent by computation requests while waiting in Slave Dispatcher's queue for processing. Upper or lower limits for such a metric could be explicitly included in a Service Level Agreement}, e.g. the service provider might be obliged to ensure that a request won't wait for processing for longer than one minute. In case the computing power was not suffiecient to process a task, additional virtual machines were launched.
The infrastructure was used in parallel with other users, thus, e.g., the startup time of virtual machines differed over time.

Our experiments on the FutureGrid infrastructure allowed to infer that using the average wait time metric has a positive impact on the system when considering  its operation from the business point of view. Since the end users are mostly interested in making the time required to wait as short as possible, the amount of  the resources involved should be increased according to this demand. By improving this factor, the potential business value of the presented service grows. The system was automatically scaled by SAMM not only from the technical point of view but also from the business value perspective.

The results of our research are presented in two papers [1,2].

References

[1] Koperek, P., Funika, W. Automatic Scaling in Cloud Computing Environments Based on Business Metrics, in: Proc. of  International
Conference on Parallel Programming and Applied Mathematics (PPAM'2011), 11-14 September 2011, Torun, Poland, LNCS, Springer, 2012 (to be
published)

[2] Funika, W., Koperek, P. Scalable Resource Provisioning in the Cloud Using Business Metrics, in: Proc. of the Fifth International Conference on
Advanced Engineering Computing and Applications in Sciences (ADVCOMP'2011), 20-25 November 2011, Lisbon, Portugal, 2011 (to be
published)

The other part of our research was to invesigate possibility of usage of FG resources for multiscale  MUSCLE-based applications (in particular Instent restenosis application). We have already developed a system based on Amazon AWS API and we are in a process of testing it on FG resources (Eucaliptus).  This is still ongoing work.

Results for Project "36. Advanced Technology for Sensor Clouds"

Alex Ho and Geoffrey Fox Distributed FutureGrid Clouds for Scalable Collaborative Sensor-Centric Grid Applications Ball Aerospace Dayton (Fairborn) July 27 2011

Results for Project "8. Running workflows in the cloud with Pegasus"

Gideon Juve, Ewa Deelman, Automating Application Deployment in Infrastructure Clouds, 3rd IEEE International Conference on Cloud Computing Technology and Science (CloudCom 2011), 2011.

Jens-S. Vöckler, Gideon Juve, Ewa Deelman, Mats Rynge, G. Bruce Berriman, Experiences Using Cloud Computing for A Scientific Workflow Application, Proceedings of 2nd Workshop on Scientific Cloud Computing (ScienceCloud 2011), 2011.

Gideon Juve and Ewa Deelman, Wrangler: Virtual Cluster Provisioning for the Cloud, short paper, Proceedings of the 20th International Symposium on High Performance Distributed Computing (HPDC 2011), 2011.

Results for Project "14. Course: Distributed Scientific Computing Class"

FutureGrid supported a new class focusing on a practical and comprehensive graduate course preparing students for research involving scientific computing. Module E (Distributed Scientific Computing) taught by Shantenu Jha used FutureGrid in hands-on assignments on:

• Introduction to the practice of distributed computing;
• Cloud computing and master-worker pattern;
• and Distributed application case studies.
• Two papers were written about this course: ICCS and TG'11

Results for Project "145. CloVR - Cloud Virtual Resource for Automated Sequence Analysis From Your Desktop"

We have two publications describing the CloVR VM in press. The abstract for the main paper is Background: Next-generation sequencing technologies have decentralized sequence acquisition, increasing the demand for new bioinformatics tools that are easy to use, portable across multiple platforms, and scalable for high-throughput applications. Cloud computing platforms provide on-demand access to computing infrastructure over the Internet and can be used in combination with custom built virtual machines to distribute pre-packaged with pre-configured software. Results: We describe the Cloud Virtual Resource, CloVR, a new desktop application for push-button automated sequence analysis that can utilize cloud computing resources. CloVR is implemented as a single portable virtual machine (VM) that provides several automated analysis pipelines for microbial genomics, including 16S, whole genome and metagenome sequence analysis. The CloVR VM runs on a personal computer, utilizes local computer resources and requires minimal installation, addressing key challenges in deploying bioinformatics workflows. In addition CloVR supports use of remote cloud computing resources to improve performance for large-scale sequence processing. In a case study, we demonstrate the use of CloVR to automatically process next-generation sequencing data on multiple cloud computing platforms. Conclusion: The CloVR VM and associated architecture lowers the barrier of entry for utilizing complex analysis protocols on both local single- and multi-core computers and cloud systems for high throughput data processing.

Results for Project "139. Course: Cloud Computing and Storage Class"

Education and course projects.

Results for Project "75. Cumulus"

Problem: The advent of cloud computing introduced a convenient model for storage outsourcing. At the same time, the scientific community already has large storage facilities and software. How can the scientific community that already has accumulated vast amounts of data and storage take advantage of these data storage cloud innovations? How will the solution compare with existing models in terms of performance and fairness of access?

Project: John Bresnahan at the University of Chicago developed Cumulus, an open source storage cloud and performed a qualitative and quantitative evaluation of the model in the context of existing storage solutions, and needs for performance and scalability. The investigation defined the pluggable interfaces needed, science-specific features (e.g., quota management), and investigated the upload and download performance as well as scalability of the system in the number of clients and storage servers. The improvements made as a result of the investigation were integrated into Nimbus releases.

This work, in particular the performance evaluation part was performed on 16 nodes of the FutureGrid hotel resource. It was important to obtain not only dedicated nodes but also a dedicated network for this experiment because network disturbances could affect the measurement of upload/download efficiency as well as the scalability measurement.   Further, for the scalability experiments to be successful it was crucial to have a well maintained and administered parallel file system.  The GPFS partition on FutureGrid's Hotel resource provided this.  Such requirements are typically hard to find on platforms other than dedicated computing resources within an institution.

Figure: Cumulus scalability over 8 replicated servers using random and round robin algorithms

References:

• Cumulus: Open Source Storage Cloud for Science, John Bresnahan, Kate Keahey, Tim Freeman, David LaBissoniere. SC10 Poster. New Orleans, LA. November 2010.
• http://www.nimbusproject.org/files/cumulus_poster_sc10.pdf

Results for Project "76. Differentiated Leases for Infrastructure-as-a-Service"

Problem: A common problem in on-demand IaaS clouds is utilization: in order to ensure on-demand availability providers have to ensure that there are available resources waiting for a request to come. To do that, they either have to significantly overprovision resources (in which case they experience low utilization) or reject a large proportion of requests (in which case the cloud is not really on-demand). The question arises: how can we combine best of both worlds?

Approach: Paul Marshall from the University of Colorado at Boulder approached this problem by deploying always-on preemptible VMs on all nodes of an IaaS cloud. When an on-demand request comes, the preemptible VMs are terminated in order to release resources for the on-demand request; when the nodes again become available the preemptible VMs are redeployed. Using this method, Paul was able to solve the utilization problem described above and demonstrate cloud utilization of up to 100%. Since sudden preemption is typical in volunteer computing systems such as SETI@home or various Condor installations, this solution was therefore evaluated in the context of a Condor system measure its efficiency for the volnteer computing execution which was shown to be over 90%.

In order to evaluate his system experimentally, Paul first modified the open source Nimbus toolkit to extend its functionality to supports the backfill approach. He then had to deploy the augmented implementation on a sizable testbed that gave him enough privilege (root) to install and configure the augmented Nimbus implementation -- Such requirements are typically hard to find on platforms other than dedicated local resources. In this case however, this testbed was provided by the FutureGrid hotel resource (specifically we used 19 8-core FG nodes on hotel).

 

 

Cloud utilization comparison for the same on-demand request trace.

 

Figure: Cloud utilization comparison for the same on-demand request trace: backfill VMs are disabled and the cloud is very little utilized ("cold"); 

Figure: Backfill VMs are enabled and the cloud achieves close to 100% utilization over the period of observation.

References:

• Improving Utilization of Infrastructure Clouds, Paul Marshall, Kate Keahey, Tim Freeman, submitted to CCGrid 2011.

Results for Project "77. Periodogram Workflow Running on FutureGrid Using Pegasus"

Pegasus Does Sky Computing

Jens-S. Vöckler USC-ISI

Gideon Juve USC-ISI

Bruce Berriman IPAC-CalTech

Ewa Deelman USC-ISI

Mats Rynge USC-ISI

A FutureGrid Success Story

The Periodogram workflow searches for extra-solar planets, either by “wobbles” in the radial velocity of a star, or dips in the star’s intensity. In either case, the workflow searches for repeating variations over time in the input “periodogram” data, a sub-set of the light curves released by the Kepler project. The workflow in this scenario only executed the “plav-chan”[1] algorithm, which is the computationally most intense. A full search needs to execute all three algorithms.

Figure 1: Workflow processing first release with one algorithm.

Figure 1 shows the complete workflow of 1,599 Condor jobs and 33,082 computational tasks, computing every periodogram twice.[2] The top (root) node in the workflow graph is an ancillary job, creating the necessary directory to receive the computational output.

In the first level under the top, the 33k computational tasks were binned into 799 Condor jobs depending on their run-time estimate: extremely fast (sub-second), fast (minutes) and slow (hours). The last bin for extremely fast and fast jobs was not completely filled. Each Condor job stages in all “.tbl” files that the job requires, and stages back all “.out” and “.out.top” result files. The staging happens through Condor-I/O between the submit machine at ISI, and the remote resources in FutureGrid. The “heavy lifting” with regards to staging happens this point.

In the last level, 799 Condor staging jobs, ancillary jobs that Pegasus generated, copy a file on the submit host between directories. This seemingly redundant stage takes almost no time, and is not reflected in the timings except total run-time. We are working on removing this stage from the workflow plan.

 

Figure 2: Requested Resources per Cloud.

Figure 2 describes the resource request setup. We requested 90 resources from Nimbus clouds (blues), and 60 from Eucalyptus clouds (greens). 1/3 of combined resources were provided by sierra (SDSC), 1/3 by hotel (UofC), and the final 1/3 shared between india (IU) and foxtrot (UFl). 150 machines in five clouds at four sites with two cloud middleware systems justify the term Sky Computing for this experiment.

The resources boot a Pegasus VM image that has the Periodogram software installed. Each provisioned image, based on a CentOS 5.5 system, brings up a Condor startd, which reports back to a Condor collector at ISI. As much as possible, we tried to request non-public IP modes, necessitating the use of the Condor connection broker (CCB).

On the provisioned image, each host came up with 2 cores, and each core had 2 Condor slots assigned to it. This computational over-subscription of the remote resources is considered not harmful for the periodogram workflow. Further experimentation will be required to validate this decision.

The provision requests were entered manually, using the Nimbus- and Eucalyptus client tools. After the first resources started reporting back to the Condor collector, the Pegasus-planned workflow was started, resulting in an instance of Condor DAGMan executing the workflow. Once the workflow terminated successfully, the resources were manually released.

Figure 3 shows a combination of available Condor slots and jobs in various states for the duration of the workflow. The blue line shows the provisioned slots as they become available over time, thus starting in negative time with regards to the workflow. The start of the workflow indicates 0 in the x-axis.

Figure 3: Slots and Job State over time.

The blue line tops out at 622 resource slots. However, since this is a total derived from condor_status, the submit host slots (6) and any other non-participating slots (20) need to be subtracted, bringing the total to 596 slots, or 298 participating cores, or 149 remote hosts. It also shows that a single remote resource never reported back properly.

For this workflow, partial success for a resource request is not a problem. However, other workflows do rely on the all-or-nothing principle, and the middleware should never provision a partial success, unless expressly permitted.

The red line in Figure 3 shows the slots that Condor perceived to be busy.  This curve is over-shadowed by the tasks in state executing found in the Condor queue. At one point during the workflow, the number of executing tasks topped out at 466 parallel executing tasks.

The yellow line shows the number of idle tasks in the Condor queue. The workflow manager DAGMan was instructed to only release more jobs into the queue, if there were less than 100 idle jobs. It does not make sense to drop hundreds of jobs into the queue, if only a limited number of them can run. While a maximum of 117 idle jobs does not hit the target perfectly, it is quite sufficient to balance between saturation and scalability.

Figure 4: Display of Table 1.

Site	Avail. Hosts	Active Hosts	Jobs	Tasks	Cumulative Duration (h)
Eucalyptus india	30	8	19	1900	0.4
Eucalyptus sierra	29	28	162	7080	119.2
Nimbus sierra	20	20	140	7134	86.8
Nimbus foxtrot	20	17	126	6678	77.5
Nimbus hotel	50	50	352	10290	250.6
TOTAL	149	123	799	33082	534.5

 

Table 1: Statistics about Sites, Jobs and Tasks.

Table 1 and Figure 4 summarize the hosts that, according to Condor, were actually participating in the workflow. With only 123 actively participating hosts that received work from the Condor scheduler, the maximum number of job slots is 492, over 100 slots less than we requested.

Even though the Eucalyptus resources on sierra were only participating with 8 hosts, they managed to deal with 1,900 tasks. The amount of tasks computed per site reflects the number of resources closely, albeit not the time taken.

Overall, the workflow contained over 22 days of computational work, including staging of data. The workflow executed in a little more than 2 hours total workflow duration.

Even though every periodogram was computed twice, input files were staged from separate locations, with 33,082 compressed files totaling 3.4 GB over Condor-I/O. The output totals 66,164 transfers of compressed files with over 5.8 GB size in transferred volume.

 

Size range		Input .tbl.gz	Output .top.gz	Output .out.gz
1,024	2,047		606
2,048	4,095		32,476
4,096	8,191
8,192	16,383	8,457
16,384	32,767	1,065
32,768	65,535	1,297		21,638
65,536	131,071	5,665
131,072	262,143	52
262,144	524,287	1		11,434
524,288	1,048,575	4		10
1,048,576	2,097,152

 

Table 2: Ranges of compressed input and output sizes.

 

• [1] Binless phase-dispersion minimization algorithm that identifies periods with coherent phased light curves (i.e., least “dispersed”) regardless of signal shape: Plavchan, Jura, Kirkpatrick, Cutri, and Gallagher. ApJS, 175,19 (2008)

• [2] We will fix this in future re-runs.

Results for Project "74. Sky Computing"

Problem: Scientific problems are often large and distributed by nature as they combine processing of data produced at various sources. In the context of cloud computing this leads to a question of what problems would arise if we were to use resources obtain from not just one IaaS cloud, but a federation of multiple geographically distributed infrastructure clouds. Such multi-cloud federations have been called “sky computing” (see [1]) and involve challenges of standardization, security, configuration, and networking.

Project: Pierre Riteau from the University of Rennes 1 proposed one solution in this space by creating a virtual cluster combining resources obtained from six geographically distributed Nimbus clouds: three hosted on Grid’5000 and three hosted on FutureGrid. Experimenting with distribution and scale he succeeded in creating a geographically distributed virtual cluster of over 1000 cores. His solution overcame firewall and incompatible network policy problems by using the ViNe overlay to create a virtual network and secure creation of a virtual cluster by using the Nimbus Context Broker. Further, in order to overcme the image distribution problem which becomes a significant obstacle to fast deployment at this scale Pierre developed a QCOW system which uses copy-on-write techniques to speed up image distribution.

Widely distributed compatible cloud resources needed for this experiment would have been impossible to obtain with the existence of resources such as Grid’5000 and FutureGrid and their close collaboration. In addition to experimenting with research problems at unprecedented scale, this project was also a proof-of-concept and a trail blazer for a close collaboration between Grid’5000 and FutureGrid. Because of its integrative nature, this project was demonstrated at OGF 29 in June 2010.

Figure: The sky computing experiment built a virtual cluster distributed over six Nimbus clouds using the ViNe virtual network overlay and the Nimbus Context Broker.

References:

• Sky Computing on FutureGrid and Grid’5000, Pierre Riteau, Mauricio Tsugawa, Andrea Matsunaga, José Fortes, Tim Freeman, David LaBissoniere, Kate Keahey. TeraGrid 2010, Pittsburgh, PA. August 2010 http://www.nimbusproject.org/files/riteau_tg10.ppt

•  ISGTW article: Reaching for sky computing www.isgtw.org/?pid=1002832

• ERICM article: Large-Scale Cloud Computing Research: Sky Computing on FutureGrid and Grid’5000 http://ercim-news.ercim.eu/en83/special/large-scale-cloud-computing-research-sky-computing-on-futuregrid-and-grid5000

Results for Project "56. Windows and Linux performance comparison"

A collection of performance benchmarks have been run on the FutureGrid IBM System X iDataPlex cluster using two different operating systems. Windows HPC Server 2008 (WinHPC) and Red Hat Enterprise Linux v5.4 (RHEL5) are compared using SPEC MPI2007 v1.1, the High Performance Computing Challenge (HPCC) and National Science Foundation (NSF) acceptance test benchmark suites. Overall, we find the performance of WinHPC and RHEL5 to be equivalent but significant performance differences exist when analyzing specific applications. We focus on the results from the application benchmarks and include the results of the HPCC microbenchmark for completeness.

See also: http://hdl.handle.net/2022/9919

Results for Project "30. Publish/Subscribe Messaging as a Basis for TeraGrid Information Services"

W. Smith. An Information Architecture Based on Publish/Subscribe Messaging. In Proceedings of the 2011 TeraGrid Conference. July, 2011. (Extended Abstract). Slides.

As outlined in the publication above, this project has used FutureGrid to prototype candidate implmementations for a new information service for TeraGrid/XSEDE and to gather performance information about the implementations. XSEDE has not yet begun serious discussions about how to implement a new information service, but I expect that FutureGrid will be used to gather data during that discussion and to perform testing on any new information service components before they go in to production on XSEDE.

Results for Project "73. TeraGrid QA Testing and Debugging"

This success story illustrates collaboration with TeraGrid and the ability to acquire short-term access to FutureGrid resources in order to perform QA testing of software.

The mission of the TeraGrid Quality Assurance (QA) working group is to identify and implement ways in which TeraGrid software components/services and production deployments can be improved to reduce the number of failures requiring operator intervention that are encountered at TeraGrid resource provider sites.  The TeraGrid QA group utilized FutureGrid in the below experiments:

GRAM 5 scalability testing:  The TeraGrid Science Gateway projects tend to submit large amounts of jobs to TeraGrid resources usually through the Globus GRAM interfaces.  Due to scalability problems with GRAM, members of the Science Gateway team at Indiana University extracted code from their GridChem and UltraScan Gateways anddeveloped a scalability test for GRAM.  When GRAM 5 was released, GRAM 5 was deployed to a TACC test node on Ranger and scalability testing was started.  Due to the possibility that the Ranger test node might be re-allocated, the group created an alternate test environment on FutureGrid in July 2010.  A virtual cluster running Torque and GRAM 5 was created on UF’s Foxtrot machine using Nimbus.  Access to the virtual cluster was provided to the Science Gateway team as well.  One problem that was debugged on the virtual cluster was numerous error messages showing up in a log file in the user’s home directory.  This did not effect job execution but took up space in the user’s home directory and was reported to the Globus developers.  The effort is summarized in the following Wiki page at http://www.teragridforum.org/mediawiki/index.php?title=GRAM5_Scalability_Testing

GridFTP 5 testing:  In order to test the newest GridFTP 5 release, the TeraGrid QA group again turned to FutureGrid and instantiated a single VM with GridFTP 5 on UCSD’s Sierra and UF’s Foxtrot machine in October 2010.  They then verified several of the new features, such as data set synchronization and the offline mode for the server.  No major problems were detected in this testing, though a bug related to the new dataset synchronization feature was reported.  The results are summarized on the TeraGrid Wiki at http://www.teragridforum.org/mediawiki/index.php?title=GridFtp5_Testing.

Some results:

Results for Project "220. FutureGrid Project Challenge (Project FG-172)"

Publications:
- Sebastiano Peluso, Pedro Ruivo, Paolo Romano, Francesco Quaglia and Luís Rodrigues, "When Scalability Meets Consistency: Genuine Multiversion Update-Serializable Partial Data Replication". Proc. of 32nd IEEE International Conference on Distributed Computing Systems (ICDCS), June 2012

Results for Project "225. Budget-constrained workflow scheduler"

work progress...

Results for Project "256. QuakeSim Evaluation of FutureGrid for Cloud Computing"

http://quakesim.org

Results for Project "276. Course (1 day): K12 Introduction High Performance and Cloud Computing"

The students were able to use susestudio easily. However, preparation of the environment was still too complex as the instalation requires flash to be on the system. As a Linux distribution was used, flash needed to be installed by the users. In retorspect the image that we gave to the stuudents should have flash already integrated.

Form the 12 students that participated, 1 was female. Two high school teachers participated.

We suggested the teachers to create science videos that demonstrate the use of parallel computers

Results for Project "323. Biomedical Natural Language Processing"

Statistical and linguistical analysis of clinical text

Results for Project "333. Intrusion Detection and Prevention for Infrastructure as a Service Cloud Computing System"

No results as of yet.

Results for Project "379. The genome of a terrestrial metazoan extremophile"

The complete genome of Pontoscolex corethrurus

Results for Project "391. Course: Topics in Parallel Computation"

home work reports related with MPI and CUDA programming.

Results for Project "176. Cloud Interoperability Testbed"

The different groups using access to FutureGrid through this project have a variety of expected output types.  The OGF group with the same name as this project (Cloud Interoperability) will be charged with producing Experience documents and Community Practice documents that capture the output of its tests.  Related groups from other SDOs will be asked to provide output also or to provide the results of their efforts to the OGF CI-WG as input to their efforts for eventual categorization and documentation as above.  Finally, where possible code will be provided to the community to encourage adoption of implementations of standards that prove useful as a result of these efforts.

Results for Project "447. Using SNORT and AFTERGLOW to detect and visualize all malicious attacks within IaaS Cloud COmputing Systems"

Not yet.