www.ijecs.in
International Journal Of Engineering And Computer Science ISSN:2319-7242
Volume2 Issue 8 August, 2013 Page No. 2611-2619
An Allocation of Exploited Resources for Potent
Parallel Data Processing In Cloud
Prof.Santosh Kumar. B1, AnandKumar A.K2
1
Department of computer science and engineering, Poojya doddappa Appa College of engineering, Gulbarga, Karnataka, India, email:
santosh.bandak@gmail.com
2
Department of computer science and engineering, Poojya doddappa Appa College of engineering, Gulbarga, Karnataka, India,
email:akamatan@yahoo.com
Abstract: In recent years ad-hoc parallel data processing has emerged to be one of the killer applications for Infrastructure-as-aService (IaaS) clouds. Major Cloud computing companies have started to integrate frameworks for parallel data processing in their
product portfolio, making it easy for customers to access these services and to deploy their programs. However, the processing
frameworks which are currently used have been designed for static, homogeneous cluster setups and disregard the particular nature of
a cloud. Consequently, the allocated compute resources may be inadequate for big parts of the submitted job and unnecessarily
increase processing time and cost. In this paper we discuss the opportunities and challenges for efficient parallel data processing in
clouds and present our research project Nephele. Nephele is the first data processing framework to explicitly exploit the dynamic
resource allocation offered by today’s IaaS clouds for both, task scheduling and execution. Particular tasks of a processing job can be
assigned to different types of virtual machines which are automatically instantiated and terminated during the job execution. Based on
this new framework, we perform extended evaluations of MapReduce inspired processing jobs on an IaaS cloud system and compare
the results to the popular data processing framework Hadoop .
Index Terms- Cloud Computing, High-Throughput
Computing, resource allocation, Many Task computing,
nephele.
Introduction: Today a growing number of companies have to
process huge amounts of data in a cost-efficient manner.
Classic representatives for these companies are operators of
Internet search engines, like Google, Yahoo, or Microsoft.
Cloud computing is the use of computing resources (hardware
and software) that are delivered as a service over a network
(typically the Internet) . Cloud computing entrusts remote
services with a user's data, software and computation. cloud
computing allows companies to avoid upfront infrastructure
costs, and focus on projects that differentiate their businesses
instead of infrastructure vast amount of data the companies
have to deal with every day has made traditional database
solutions prohibitively expensive [5]. Instead, these companies
have popularized an architectural paradigm based on a large
number of commodity servers. Problems like processing
crawled documents or regenerating a web index are split into
several independent subtasks, distributed among the available
nodes, and computed in parallel.
In order to simplify the development of distributed
applications on top of such architectures, many of these
companies have also built customized data processing
frameworks. Examples are Google’s MapReduce [9],
Microsoft’s Dryad [14], or Yahoo!’s Map-Reduce-Merge
[6].They can be classified by terms like high throughput
computing (HTC) or many-task computing (MTC), depending
on the amount of data and the number of tasks involved in the
computation [20] The processing framework takes care of
distributing the program among the available nodes and
executes each instance of the program on the appropriate
fragment of data Although these systems differ in design, their
programming models share similar objectives, namely hiding
the hassle of parallel programming, fault tolerance, and
execution optimizations from the developer. For companies
that only have to process large amounts of data on an irregular
basis running their own data center is obviously not an option.
Instead, cloud computing has emerged as a promising
approach to rent a large IT infrastructure on a short-term payper-usage basis. Operators of compute clouds, like Amazon
EC2 [1], let their customers allocate, access and control a set
of virtual machines which run inside their data centers and
only charge them for the period of time the machines are
allocated. The virtual machines are typically offered in diffrent
types, each type with its own characteristics (number of CPUcores, amount of main memory, etc.) and cost Since the
Anand Kumar, IJECS Volume 2 Issue 8 August, 2013 Page No.2611-2619
Page 2611
virtual machine abstraction of compute clouds fits the
architectural paradigm assumed by the data processing
frameworks described above, projects like Hadoop [23], a
popular open source implementation of Google's MapReduce
framework, already began to promote using their frameworks
in the cloud [25]. Only recently, Amazon has integrated
Hadoop as one of its core infrastructure services [2].
However, instead of embracing its dynamic resource
allocation, current data processing frameworks rather expect
the cloud to imitate the static nature of the cluster
environments they were originally designed for. E.g., at the
moment the types and number of virtual machines allocated at
the beginning of a compute job cannot be changed in the
course of processing, although the tasks the job consists of
might have completely diffrent demands on the environment.
Asa result, rented resources may be inadequate for big parts of
the processing job, which may lower the overall processing
performance and increase the cost.performance and increase
the cost.In this paper we want to discuss the particular
challenges and opportunities for efficient parallel data
processing inside clouds and present Nephele is the first data
processing framework to include the possibility of
dynamically allocating/deallocating different compute
resources from a cloud in its scheduling and during
job execution.
CHALLENGES AND OPPORTUNITIES
Current data processing frameworks like Google’s
MapReduce or Microsoft’s Dryad engine have been designed
for cluster environments. This is reflected in a number of
assumptions they make which are not necessarily valid in
cloud environments. In this section we discuss how
abandoning these assumptions raises new opportunities but
also challenges for efficient parallel data processing in clouds.
2.1 Opportunities
Today’s processing frameworks typically assume the
resources they manage consist of a static set of homogeneous
compute nodes. Although designed to deal with individual
nodes failures, they consider the number of available machines
to be constant, especially when scheduling the processing
job’s execution. While IaaS clouds can certainly be used to
create such cluster-like setups, much of their flexibility
remains unused One of an IaaS cloud’s key features is the
provisioning of compute resources on demand. New VMs can
be allocated at any time through a well-defined interface and
become available in a matter of seconds. Machines which are
no longer used can be terminated instantly and the cloud
customer will be charged for them no more.
framework exploiting the possibilities of a cloud could start
with a single virtual machine which analyzes an incoming job
and then advises the cloud to directly start the required virtual
machines according to the job's processing phases. After each
phase, the machines could be released and no longer
contribute to the overall cost for the processing job The
MapReduce pattern is a good example of an unsuitable
paradigm
challenges:
The cloud’s virtualized nature helps to enable promising new
use cases for efficient parallel data processing. However, it
also imposes new challenges compared to classic cluster
setups. The major challenge we see is the cloud’s opaqueness
with prospect to exploiting data locality:
In a cluster the compute nodes are typically interconnected
through a physical high-performance network. The
topology of the network, i.e. the way the compute nodes are
physically wired to each other, is usually well-known
and,what is more important, does not change over time. all
throughput of the cluster can be improved.In a cloud this
topology information is typically not exposed to the customer
[25]. Since the nodes involved in processing a data intensive
job often have to transfer tremendous amounts of data through
the network, this drawback is particularly severe; parts of the
network may become congested while others are essentially
unutilized
I. RESEARCH ELABORATIONS
Nephele/PACTs: A Programming Model and Execution
Framework for Web-Scale Analytical Processing2010,
Dominic Odej Kao ,Battré Stephan Volker Markl, Ewen
Fabian Hueske Daniel Warneke, We present a parallel data
processor centered around a programming model of so called
Parallelization Contracts (PACTs) and the scalable parallel
execution engine Nephele. The PACT programming model is
a generalization of the well-known map/reduce programming
model, extending it with further second-order functions, as
well as with Output Contracts that give guarantees about the
behavior of a function. In this We describe methods to
transform a PACT program into a data flow for Nephele,
which executes its sequential building blocks in parallel and
deals with communication, synchronization and fault
tolerance.
On-Demand Resource Provisioning for BPEL Workflows
Using Amazon’s Elastic Compute Cloud, Tim D¨ornemann,
Ernst Juhnke, Bernd Freisleben, 2009, BPEL is the de facto
standard for business process modeling in today’s enterprises
and is a promising candidate for the integration of business
and Grid applications. Current BPEL implementations do not
provide mechanisms to schedule service calls with respect to
the load of the target hosts. In this paper, a solution that
automatically schedules workflow steps to underutilized hosts
and provides new hosts using Cloud computing infrastructures
in peak-load situations is presented.
SCOPE: SCOPE (Structured Computations Optimized for
Parallel Execution) Easy and Efficient Parallel Processing of
Massive Data Sets, 2008, Ronnie Chaiken, Bob Jenkins, PerÅke Larson, Bill Ramsey,Darren Shakib, Simon Weaver,
Jingren Zhou, Companies providing cloud-scale services have
an increasing need to store and analyze massive data sets such
as search logs and click streams. For cost and performance
reasons, processing is typically done on large clusters of
shared-nothing commodity machines. It is imperative to
develop a programming model that hides the complexity of the
Anand Kumar, IJECS Volume 2 Issue 8 August, 2013 Page No.2611-2619
Page 2612
underlying system but provides flexibility by allowing users to
extend functionality to meet a variety of requirements.
Swift: Fast, Reliable, Loosely Coupled Parallel Computation,
2007, Yong Zhao, Mihael Hategan, Ben Clifford, Ian Foster,
Gregor von Laszewski, Veronika Nefedova, Ioan Raicu,
Tiberiu Stef-Praun, Michael Wilde, We present Swift, a
system that combines a novel scripting language called Swift
Script with a powerful runtime system based on CoG Karajan,
Falkon, and Globus to allow for the concise specification, and
reliable and efficient execution, of large loosely coupled
computations. Swift adopts and adapts ideas first explored in
the GriPhyN virtual data system, improving on that system in
many regards.
Falkon: a Fast and Light-weight tasK executiON framework,
2007, Ioan Raicu, Yong Zhao, Catalin Dumitrescu, Ian Foster,
Mike Wilde To enable the rapid execution of many tasks on
compute clusters, we have developed Falkon, a Fast and
Light-weight task execution framework. Falkon integrates
multi-level scheduling to separate resource acquisition (via,
e.g., requests to batch schedulers) from task dispatch, and a
streamlined dispatcher. Falkon’s integration of multi-level
scheduling and streamlined dispatchers delivers performance
not provided by any other system. We describe Falkon
architecture and implementation, and present performance
results for both micro benchmarks and applications.
Fig 1: Structural overview of Nephele running in an IaaS
cloud
ARCHITECTURE DIAGRAM:
I. SYSTEM DESIGN
The nodes involved are admin and clients which stands as
UI for the system. The deployment is performed as per the
requirements of Hardware and software specified in the
requirements phase.
Nephele computes a job, user must start a VM in the cloud
which runs the so called Job Manager (JM). The Job Manager
receives the client’s jobs, is responsible for scheduling them,
and coordinates their execution. It is capable of
communicating with the interface the cloud operator provides
to control the instantiation of VMs. We call this interface the
Cloud Controller. By means of the Cloud Controller the Job
Manager can allocate or deallocate VMs according to the
current job execution phase. We will comply with common
Cloud computing terminology and refer to these VMs as
instances for the remainder of this paper. The term instance
type will be used to differentiate between VMs with different
hardware characteristics. E.g., the instance type “m1.small”
could denote VMs with one CPU core, one GB of RAM, and a
128 GB disk while the instance type “c1.xlarge” could refer to
machines with 8 CPU cores, 18 GB RAM, and a 512 GB disk.
Fig 2:Architecture Diagram for Parallel data Processing in
the Cloud
Anand Kumar, IJECS Volume 2 Issue 8 August, 2013 Page No.2611-2619
Page 2613
The actual execution of tasks which a Nephele job consists of
is carried out by a set of instances. Eachinstance runs a socalled Task Manager (TM). A Task Manager receives one or
more tasks from the Job Manager at a time, executes them,
and after that informs the Job Manager about their completion
or possible errors. Unless a job is submitted to the Job
Manager, we expect the set of instances (and hence the set of
Task Managers) to be empty. Upon job reception the Job
Manager then decides, depending on the job’s particular tasks,
how many and what type of instances the job should be
executed on, and when the respective instances must be
allocated/deallocated to ensure a continuous but cost-efficient
processing.
Fig 4:An Execution Graph Created From Original
Job Graph
Fig 3: An example of a Job Graph Nephele
Figure 3 illustrates the simplest possible JobGraph. It only
consists of one input, one task, and one output vertex,one
major goal of job graphs has been simplicity: Users should be
able to describe tasks and their relationships on an abstract
level. Therefore, the Job Graph does not explicitly model task
parallelization and the mapping of tasks to instances.
However, users who wish to influence these aspects can
provide annotations to their job description. These annotations
include:
 Number of subtasks: A developer can declare his
task to be suitable for parallelization.
 Number of subtasks per instance: By default each
subtask is assigned to a separate instance.
 Sharing instances between tasks: Subtasks of
different tasks are usually assigned to different (sets
of) instances unless prevented by another scheduling
restriction.
 Channel types: For each edge connecting two
vertices the user can determine a channel type.
 Instance type: A subtask can be executed on
different instance types which may be more or less
suitable for the considered program.
Figure 4 shows one possible Execution Graph constructed
from the previously depicted Job Graph (Figure 2). Task 1 is
e.g. split into two parallel subtasks which are both connected
to the task Output 1 via file channels and are all scheduled to
run on the same instance. Similar to Microsoft’s Dryad [14],
jobs in Nephele are expressed as a directed acyclic graph
(DAG). In contrast to the Job Graph, an Execution Graph is no
longer a pure DAG. Instead, its structure resembles a graph
with two different levels of details, an abstract and a concrete
level. While the abstract graph describes the job execution on
a task level (without parallelization) and the scheduling of
instance allocation/deallocation, the concrete, more finegrained graph defines the mapping of subtasks to instances
and the communication channels between them.
On the abstract level, the Execution Graph equals the user’s
Job Graph. For every vertex of the original Job Graph there
exists a so-called Group Vertex in the Execution Graph. As a
result, Group Vertices also represent distinct tasks of the
overall job, however, they cannot be seen as executable units.
They are used as a management abstraction to control the set
of subtasks the respective task program is split into.The edges
between Group Vertices are only modeled implicitly as they
do not represent any physical communication paths during the
job processing. to ensure cost-efficient execution in an IaaS
cloud, Nephele allows to allocate/deallocate instances in the
course of the processing job, when some subtasks have
already been completed or are already running.
However, this just-in-time allocation can also cause problems,
since there is the risk that the requested instance types are
temporarily not available in the cloud. To cope with this
problem, Nephele separates the Execution Graph into one or
more so-called Execution Stages. Nephele’s scheduler ensures
the following three properties for the entire job execution:
First, when the processing of a stage begins, all instances
required within the stage are allocated.
Second, all subtasks included in this stage are set up (i.e. sent
to the corresponding Task Managers along with their required
libraries) and ready to receive records.
Third, before the processing of a new stage, all intermediate
results of its preceding stages are stored in a persistent
Anand Kumar, IJECS Volume 2 Issue 8 August, 2013 Page No.2611-2619
Page 2614
manner. Hence, Execution Stages can be compared to
checkpoints. Nephele features three different types of
channels, which all put different constrains on the Execution
Graph.
 Network channels: A network channel lets two
subtasks exchange data via a TCP connection.
Network channels allow pipelined processing, so the
records emitted by the producing subtask are
immediately transported to the consuming subtask.
As a result, two subtasks connected via a network
channel may be executed on different instances.
 In-Memory channels: Similar to a network channel,
an in-memory channel also enables pipelined
processing. However, instead of using a TCP
connection, the respective subtasks exchange data
using the instance’s main memory.
 File channels: A file channel allows two subtasks to
exchange records via the local file system. The
records of the producing task are first entirely written
to an intermediate file and afterwards read into the
consuming subtask.
III.PERFORMANCE EVALUATION
In this section we want to present first performance results of
Nephele and compare them to the data processing framework
Hadoop. We have chosen Hadoop as our competitor, because
it is an open source software and currently enjoys high
popularity in the data processing community. We are aware
that Hadoop has been designed to run on a very large number
of nodes (i.e. several thousand nodes).
hardware setup
All three experiments were conducted on our local IaaS cloud
of commodity servers. Each server is equipped with two Intel
Xeon 2:66 GHz CPUs (8 CPU cores) and a total main memory
of 32 GB. All servers are connected through regular 1 GBit/s
Ethernet links. The host operating system was Gentoo Linux
(kernel version 2.6.30) with KVM [15] (version 88-r1) using
virtio [23] to provide virtual I/O access. To manage the cloud
and provision VMs on request of Nephele, we set up
Eucalyptus [16]. Similar to Amazon EC2, Eucalyptus offers a
predefined set of instance types a user can choose from.
During our experiments we used two different instance types:
The first instance type was “m1.small” which corresponds to
an instance with one CPU core, one GB of RAM, and a 128
GB disk.
Experiment 1: MapReduce and Hadoop
In order to execute the described sort/aggregate task with
Hadoop we created three different MapReduceprograms
which were executed consecutively. The first MapReduce job
reads the entire input data set, sorts the contained integer
numbers ascendingly, and writes them back to Hadoop’s
HDFS file system. Since the MapReduce engine is internally
designed to sort the incoming data between the map and the
reduce phase, we did not have to provide custom map and
reduce functions here. Instead, we simply used the TeraSort
code, which has recently been recognized for being wellsuited
for these kinds of tasks [18]. The result of this first
MapReduce job was a set of files containing sorted integer
numbers. Concatenating these files yielded the fully sorted
sequence of 109 numbers. The second and third MapReduce
jobs operated on the sorted data set and performed the data
aggregation. Thereby, the second MapReduce job selected the
first output files from the preceding sort job which, just by
their file size, had to contain the smallest 2108 numbers of the
initial data set. We configured Hadoop to perform best for the
first, computationally most expensive, MapReduce job: In
accordance to [18] we set the number of map tasks per job to
48 (one map task per CPU core) and the number of reducers to
12.
Experiment 2: MapReduce and Nephele
For the second experiment we reused the three MapReduce
programs we had written for the previously described Hadoop
experiment and executed them on top of Nephele. In order to
do so, we had to develop a set of wrapper classes providing
limited interface compatibility with Hadoop and sort merge
functionality. These wrapper classes allowed us to run the
unmodified Hadoop MapReduce programs with Nephele. As a
result, the data flow was controlled by the executed
MapReduce programs while Nephele was able to govern the
instance allocation/deallocation and the assignment of tasks to
instances during the experiment. Figure 4 illustrates the
Execution Graph we instructed Nephele to create so that the
communication paths match the MapReduce processing
pattern. For brevity, we omit a discussion on the original Job
Graph. Following our experiences with the Hadoop
experiment, we pursued the overall idea to also start with a
homogeneous set of six “c1.xlarge” instances, but to reduce
the number of allocated instances in the course of the
experiment according to the previously observed workload.
Anand Kumar, IJECS Volume 2 Issue 8 August, 2013 Page No.2611-2619
Page 2615
Fig 5:The Execution Graph for experiment2(MapReduce and
Nephele)
METHODOLOGIES:
Methodologies are the process of sending the requested
resources and task from client to the cloud and process
efficiently and in less time.
 SQL Service Provider
 Document Service Provider
To access these services user has to be registered . Into the
cloud through User registration Interface..
 Cloud Service Provider
 Upload File
 View File
 Edit File
 Download File
 Change Token
Here user has to take an token to access the above services
which will be generated by service provider.
IV. Module Description
A. Network Module:
Server - Client computing or networking is a distributed
application architecture that partitions tasks or workloads
between service providers (servers) and service requesters,
called clients. Often clients and servers operate over computer
network on separate hardware. A server machine is a highperformance host that is running one or more server programs
which share its resources with clients. A client also shares any
of its resources; Clients therefore initiate communication
sessions with servers which await (listen to) incoming
requests.
B. Allocate Task:
In this Module the service ask the processing data for the
encryption process. Client user has to give the related data for
task scheduling. Here we can see the given datas in text area
and also have to select the encryption model’s orders for
processing. Then have to precede the data to task scheduling
process.
C. Scheduled Task:
Here the tasks send by the multiple clients are scheduled in
processing area. This module arranged the each and every task
in FIFO manner. Here it shows the each and every task in list
area. After scheduled the task it will precede the each and
every data to the Virtual machine process.
Fig 6:Cloud login page
V. Processing In Virtual Machine
Virtual machine receives the each and every process and
arranges it for the processing servers. It is used to search the
free server for processing job. Suppose if every server is in
working process, it makes the remaining task to wait stage. It
is only arrange the job to the server and respond the output to
the client.
A. Processing Task:
This is the area of server to processing the encryption for each
and every request given from the client. Here some more
servers are available for large number of processing task. Each
server will do the prober encryption process. After processing
the job it will forward that to the virtual machine.
REGISTRATION PAGE:
I. RESULTS AND ANALYSIS:
The following figures explains about cloud Services

Service Provider
 Java Service Provider
Anand Kumar, IJECS Volume 2 Issue 8 August, 2013 Page No.2611-2619
Page 2616
Fig 8:Cloud Resource page
Fig 7:Cloud Registration page
purpose: This option is to enable a new user.
Description: During the process of submitting the registration
form, user submits his basic identification information and
also general information.
Purpose: providing the resources to the user.
Description: user can get details about the resources available
in cloud and they can chose resource as their requirement
.Java page:
Fig 9:Cloud Java page
Resources Home Page:
Purpose: To receive the java type request.
Description: user can put or write any java application or
program
in
Anand Kumar, IJECS Volume 2 Issue 8 August, 2013 Page No.2611-2619
Page 2617
Fig 11:Cloud Service provider(CSP) login page
this
;
Fig 12:CSP Home page
Sql Query page:
Fig 10:Cloud SQl page
Purpose: To receive the sql type of request .
Description: user can put any type of sql request and can get
the Results.
Conclusion:
We have discussed the challenges and opportunities for
efficient parallel data processing in cloud environments and
presented Nephele, the first data processing framework to
exploit the dynamic resource provisioning offered by today’s
IaaS clouds. We have described Nephele’s basic architecture,
methodologies and presented a performance comparison to the
well-established data processing framework Hadoop. The
performance evaluation gives a first impression on how the
ability to assign specific virtual machine types to specific tasks
of a processing job, as well as the possibility to automatically
allocate/deallocate virtual machines in the course of a job
execution, can help to improve the overall resource utilization
and, consequently, reduce the processing cost. With a
framework like Nephele at hand, there are a variety of open
research issues, which we plan to address for future work. In
particular, we are interested to find out how Nephele can learn
from job executions to construct more efficient Execution
Graphs (either in terms of cost or execution time) for
upcoming jobs. In its current version, Nephele strongly
depends on the user's annotations to create an efficient
Execution Graph.
Hence this survey paper will hopefully motivate future
researchers to come up reasonable amount of user annotations
to strengthen the cloud computing paradigm.
REFERENCES
[1]
Amazon Web Services LLC. Amazon Elastic Compute
Cloud(Amazon EC2). http://aws.amazon.com/ec2/,
2009.
[2]
Amazon
Web
Services
LLC.
Amazon
Elastic
MapReduce. http:
//aws.amazon.com/elasticmapreduce/, 2009.
[3]
AmazonWeb Services LLC. Amazon Simple Storage Service.
http://aws.amazon.com/s3/, 2009.
[4]
D. Battr´e, S. Ewen, F. Hueske, O. Kao, V. Markl, and D.
Warneke. Nephele/PACTs: A Programming Model
andExecution
Framework for Web-Scale Analytical
Processing. In SoCC ’10:
Anand Kumar, IJECS Volume 2 Issue 8 August, 2013 Page No.2611-2619
Page 2618
Proceedings of the ACM
Symposium on Cloud Computing 2010,
pages 119–130, New York, NY, USA, 2010. ACM.
[5]
R. Chaiken, B. Jenkins, P.-A. Larson, B. Ramsey, D. Shakib, S.
Weaver, and J. Zhou. SCOPE: Easy and
Efficient Parallel Processing of
Massive Data Sets. Proc. VLDB Endow., 1(2):1265– 1276, 2008.
[6]
H. chih Yang, A. Dasdan, R.-L. Hsiao, and D. S.
Parker.
Map- Reduce-Merge: Simplified Relational Data Processing
on
Large Clusters. In SIGMOD ’07: Proceedings of the 2007 ACM SIGMOD
international
conference on Management of data, pages 1029–1040,
New York, NY, USA, 2007. ACM.
[7]
M. Coates, R. Castro, R. Nowak, M. Gadhiok, R. King, and
Y.
Tsang. Maximum Likelihood Network
Topology Identification from
Edge-Based Unicast Measurements. SIGMETRICS Perform. Eval. Rev.,
30(1):11–20, 2002.
[8]
R. Davoli. VDE: Virtual Distributed Ethernet. Testbeds and
Research Infrastructures for the Development of
Networks
&
Communities, International Conference
on, 0:213–220, 2005.
[9]
J. Dean and S. Ghemawat. MapReduce: Simplified
Data
Processing on Large Clusters. In OSDI’04: Proceedings
of
the
6th
conference on Symposium on
Opearting
Systems
Design
&
Implementation, pages
10–10, Berkeley, CA, USA, 2004. USENIX Association.
[10]
E. Deelman, G. Singh, M.-H. Su, J. Blythe, Y. Gil, C.
Kesselman,G. Mehta, K. Vahi, G. B. Berriman, J.
Good, A.
Laity, J. C. Jacob, and D. S. Katz. Pegasus: A
Framework
for
Mapping Complex Scientific
Workflows onto Distributed Systems. Sci.
Program., 13(3):219–237, 2005.
[11]
T. Dornemann, E. Juhnke, and B. Freisleben. OnDemand
Resource Provisioning for BPEL Workflows
Using
Amazon’s
Elastic Compute Cloud. In CCGRID
’09: Proceedings of the 2009 9th
IEEE/ACM
International Symposium on Cluster Computing and the
Grid, pages 140–147, Washington, DC, USA, 2009.
IEEE
Computer Society.
[12]
I. Foster and C. Kesselman. Globus: A Metacomputing
Infrastructure Toolkit. Intl. Journal of Supercomputer
Applications, 11(2):115– 128, 1997.
[13]
J. Frey, T. Tannenbaum, M. Livny, I. Foster, and S.
Tuecke.
Condor- G: A Computation Management
Agent
for
MultiInstitutionalGrids. Cluster Computing,
5(3):237–246, 2002.
[14
] M. Isard, M. Budiu, Y. Yu, A. Birrell, and D. Fetterly.
Dryad: Distributed Data-Parallel Programs from
Sequential
Building Blocks. In EuroSys ’07:
Proceedings of the 2nd ACM
SIGOPS/EuroSys
European Conference on Computer Systems 2007,
pages 59–72, New York, NY, USA, 2007. ACM.
[15]
A. Kivity. kvm: the Linux Virtual Machine Monitor. In
OLS ’07: The 2007 Ottawa Linux Symposium, pages 225–230,
July 2007.
[16]
D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman, L.
Youseff, and D. Zagorodnov. Eucalyptus: A Technical Report on an Elastic
Utility Computing
Architecture Linking Your Programs to Useful
Systems. Technical report, University of California,
Santa
Barbara, 2008.
[17]
C. Olston, B. Reed, U. Srivastava, R. Kumar, and A. Tomkins.
Pig Latin: A Not-So-Foreign Language for Data Processing. In SIGMOD
’08: Proceedings of the
2008
ACM
SIGMOD
international conference on
Management of data, pages 1099–1110,
New York,
NY, USA, 2008. ACM.
[18]
O. O’Malley and A. C. Murthy. Winning a 60 Second Dash with
a Yellow Elephant. Technical report,
Yahoo!, 2009.
[19]
R. Pike, S. Dorward, R. Griesemer, and S. Quinlan.
Interpreting the Data: Parallel Analysis with Sawzall. Sci.
Program., 13(4):277– 298, 2005.
[20]
I.
Raicu,
I.
Foster,
and
Y.
Zhao.
Many-Task
Computing for Grids and Supercomputers. In ManyTask Computing on Grids and Supercomputers, 2008. MTAGS
2008. Workshop on, pages 1–11, Nov. 2008.
[21]
I. Raicu, Y. Zhao, C. Dumitrescu, I. Foster, and M. Wilde. Falkon:a
Fast and Light-weight tasK executiON framework. In SC ’07:
Proceedings of the 2007 ACM/IEEE conference on Supercomputing, pages 1–
12, New York, NY, USA, 2007. ACM.
[22]
L. Ramakrishnan, C. Koelbel, Y.-S. Kee, R. Wolski, D. Nurmi, D.
Gannon, G. Obertelli, A. YarKhan, A. Mandal, T. M. Huang,
K. Thyagaraja, and D. Zagorodnov. VGrADS: Enabling e-Science Workflows
on Grids and Clouds with Fault Tolerance. In SC
’09: Proceedings of the Conference on High Performance Computing
Networking, Storage and Analysis, pages 1–12, New York, NY, USA,
2009. ACM.
[23]
R. Russell. virtio: Towards a De-Facto Standard for Virtual I/O
Devices. SIGOPS Oper. Syst. Rev., 42(5):95–103, 2008.
[24]
M. Stillger, G. M. Lohman, V. Markl, and M. Kandil. LEO DB2’s LEarning Optimizer. In VLDB ’01: Proceedings of the 27th
International Conference on Very Large Data Bases, pages 19–28, San
Francisco, CA, USA, 2001. Morgan Kaufmann Publishers Inc.
[25]
The Apache Software Foundation. Welcome to Hadoop! http:
//hadoop.apache.org/, 2009.
[26]
G. von Laszewski, M. Hategan, and D. Kodeboyina. Workflows
for e-Science Scientific Workflows for Grids. Springer, 2007.
[27]
D. Warneke and O. Kao. Nephele: Efficient Parallel Data
Processing in the Cloud. In MTAGS ’09: Proceedings of the 2nd
Workshopon Many-Task Computing on Grids and Supercomputers, pages 1–
10, New York, NY, USA, 2009. ACM.
[28]
D. Wentzlaff, C. G. III, N. Beckmann, K. Modzelewski, A. Belay,
L. Youseff, J. Miller, and A. Agarwal. An Operating System for Multicore
and Clouds: Mechanisms and Implementation. In SoCC ’10: Proceedings of
the ACM Symposium on Cloud Computing 2010,
pages 3–14, New York, NY, USA, 2010. ACM.
Anand Kumar, IJECS Volume 2 Issue 8 August, 2013 Page No.2611-2619
Page 2619