Guru Extended Thesis Outline
From Java CoG Kit
Cover Page
Table of Contents
Table of Figures
Acknowledgments
Synopsis
Introduction
What are Grids? Provide examples
What is the deployment problem?
Resource Management as [The Grid] defines is – “the ability to discover, allocate, and negotiate the use of network-accessible capabilities – be they computational services offered by a piece of software, bandwidth delivered on a network, or storage space provided by a storage system”. This involves discovering the resources, selecting the best among them for a given context, arranging them for use, using them and releasing them after use.
Deployment problem falls into the category of arranging the resources for use. In other words, mapping “What the resources can perform?” to “What the user intends to exercise?”. Efficient use of resources lies in artistically executing this mapping given the complexity of Grid systems with dynamic pool of resources spanning across administrative domains. Hence Deployment Problem is a vital aspect of Resource Management – the crux of Grid Systems It is completely achieved if we can transport the mapping between the resource and users’ requirement to – “I can do anything. Tune me.” to “What the user intends to exercise?”. The rest of this document deals with testifying whether this remains as a whim or a feasible fantasy.
With Grid technology dawning in every aspect of life, the perspective of the user about the bandwidth of tasks she can do on the resources, and the extent to which it can be carried out is drastically changing. This imparts a huge demand on the resources which has to be met by bettering their usage and less by the advancement of hardware technologies – solution – Deployment Problem.
“Exploiting the available resources for a given task with no bounds on the necessary components by seamlessly providing the environment(hardware and software components) for execution, executing it, displaying the results and restoring the system back to its previous state (if required).”
Every task has requirements in terms of the required software components such as operating system, task specific software, environment variables, specific port numbers, and hardware components such as # of processors, RAM size, processor speed, address space, network bandwidth to name a few. Given a task or the type of the task, the selected resources or the available resources it is possible to strategically discover, what is required and what is available and fulfill the gap. Following sections detail the methodology adopted by some of the existing implementations pros and cons and propose a solution we think can cater to the deployment problem in grid systems and hope to surpass the current ones.
Goals:
- Support for any type of task (MPI jobs, MPICH jobs, Standalone Java program, WS clients accessing a service etc.).
- Ability to meet any set-up requirement of a task – before the execution begins or during run-time.
- Capacity to overcome platform dependencies
- Fault-tolerance in terms of deployment failures, availability of resources, clean-up failures, run time faults, node crashes and so forth.
- Ability to specify the life span of a set-up (deploy, environment setup).
- Automatic clean-up after the task completes or the life of a set-up expires.
- Ability to schedule the deployment, clean-up, task execution.
Features:
maybe you like to focus on the phases of deployment.
Related Research
Commodity Tools and Frameworks for the Deployment Problem
Categorization
identify tools and frameworks that deal with deployment, try to categorize them
example: zeroInstall, .exe windows packages, aptget, ..., dont forget dynamic updates through windows update, ... ptan, ..., ap.tget, ..., even lenovo has an update tool for laptops ;-), jnlp, ..., ruby, ...
often it will be sufficient to just name the technology and categorize it.
technology x is a good aeaxmple for demonstration of feature y
Grid Tools and Frameworks for the Deployment problem
Categorization
What are the existing solutions to the Deployment Problem?
Lessons Learned (what is provided, what is lacking)
What is different in regards to Commodity deployment tools and frameworks
You may want to build a table that compares the frameworks and tools that you have and in rows in which phase or what thing they do for the deployment.
Monitoring and Discovery System (MDS4) and Execution Management in Globus Toolkit (GT) 4
Albeit MDS4 and Execution Management in GT4 are not directly related to the deployment problem we are dealing with, they envelope the problem on either side by offering services that can be used for gathering information about resources and providing a mechanism to stage the jobs on the grid resources and monitor the state of their execution.
MDS4 focuses on discovering and monitoring the resources given the dynamic nature and the span of Virtual Organizations (VO) in grid computing. It accomplishes this by means of a set of services and a user interface for the administrators. It uses the interfaces defined in Web Service Resource Framework (WSRF) and Web Services Notification (WS-N) for implementing the same. An Index Service is used to collect the information about the resources and is typically deployed on all the resources intending to be a part of the grid. A Trigger Service is event oriented that triggers an event when certain criteria is met. It verifies the data collected against a set of rules that define when an event has to be triggered.
Execution Management in GT4 offers support for web services and pre-web services jobs covering a wide range of jobs that require guaranteed execution, enhanced performance, thorough monitoring and reliable execution. Predictably, it is a suite of integrated services that offer the user a convincing job execution and management. Job management services monitor and control the job cycle and enable job submission, life-time management, job cancellation and graceful termination. File transfer services handle the input/output files for/of a job and Credential management services to propagate user credentials for safe and correct use of resources.
Lessons Learnt:
- Support for both parallel and distributed tasks.
- Use a monitoring service to get the current state of the resources in the grid.
- Benefit by tight integration with the other resource management modules.
HAND: Highly Available Dynamic Deployment Infrastructure for GT4
HAND [HAND] infrastructure deals with dynamic deployment of Java Web Services in dynamic Grid environments emphasizing the displacement in the focus of Grid computing from legacy applications to service oriented applications. It enhances the Java Web Services Core of GT4 with the ability to dynamically deploy services in dynamic Grid environments. In order to provide this, HAND aims at adaptability to the topology of Virtual Organizations and changes in the number of users, easy reconfiguration, redeploy and undeploy of services with minimal development and management costs. It also aims at handling situations when there unpredictable service demands.
Users who request service deployments such as system administrators are distinguished from the end users who actually use the services available. A deployment request may impact the former in terms of the successful deployment rates and the former by the service unavailable time.
Deployment requests are handled as handled in two different modes:
- HAND-C: Container-level deployment where deployment of a new service will involve reloading the whole container that host services and handle end users requests to access the services. This mode impacts all the users accessing services hosted by the container.
- HAND-S: Service-level deployment where one or more services are deactivated, new services installed and re-activated. This impacts only the end users that are accessing the services at that instant.
This approach primarily focuses on Java Web Services based application and, tight integration with GT4 makes it a wonderful choice for dynamic service-oriented grid environments. This approach relies on that fact that focus in grid computing is changing from legacy systems to service-oriented architecture which may take a significant amount of time before the complete change in focus. This would mean that it caters to only a subset of the Grid environments (involving a variety of applications such as, PVM applications, stand alone JVM applications, Batch Jobs etc) existing today.
Lessons Learnt:
- Architecture should support dynamic deployment requests
- Classifying the different forms deployment requests is necessary.
- Identifying the roles of different users and the implication on the deployment is required.
- Keeping the overhead costs to a minimum must be an inherent part of the framework.
- Deadlocks must be avoided.
GLUnix: a Global Layer UNIX for a Network of Workstations
GLUnix provides a user-level layer to integrate a Network of Workstations into a single system. It aims at transparent remote execution, support for interactive parallel and sequential jobs, batch processing, and load balancing.
It sports a scalable yet centralized system where a per-cluster-master that is responsible for storing and managing the cluster state and making resource allocation decisions. The per-cluster-master should be constantly running for the system to function. Per-node-daemon supplies the master with system level information such as the local load information periodically. This helps the master make resource allocation decisions. Per-application-library provides an API via which applications can use GLUnix services.
It is developed on the assumption that shared files systems and homogenous operating systems which may not suit for a Grid environment where heterogeneity is the fundamental nature of the system, It is not completely transparent to the user, and does not provide dynamic Load Balancing, Single point failure to extent that a per-cluster-master could fail.
Lessons Learnt:
- Remote executions should be transparent to the user.
- The applications should not be altered for using the deployment features.
- System must dynamically choose the best set of resources available.
- Support for batch jobs, interactive parallel jobs is required.
- Support for heterogeneous OS is a must.
Common Deployment Model for Grid Systems – Grid Execution Agent (GEA) and Automatic Deployment of Application in a Grid Environment (ADAGE)
Massimo Coppola [et al.] proposes a generic deployment model identifying that there is not a single model that can cover the wide range of application types, users and execution environments. This is similar to what we are about to propose. A Component based model is proposed as a solution that visualizes grid applications as a collection of components interconnected in certain way that must be deployed on a set of resources available as a part of grid infrastructure. The user submits the application along with a file containing the description of the various modules in the application, resource constraints, other application dependencies, placement policies, resource ranking, and deployment steps is expected of the user. This can be specified in a user understandable specification language for a single application or a group of applications. Based on this the resources are selected, deployment plan is prepared and executed and the actual execution of the application is staged.
GEA uses Grid Abstract Machine to provide security abstractions, discover the resources, and select the resources set-up the execution. Uses Monitoring and Discovery System in Globus toolkit for dynamic Resource Location and provides monitoring of these resources during the whole deployment and execution phases. Applications have to use the API provided by GEA in order the request resources at runtime.
ADAGE requires application description, a reference to resource information service (MDS4) and a control parameter file specifying the placement policies. The control parameter file is however not fully effective; only few parameters are currently taken into account. The application description is internally translated to a generic format as the description can be specific to a programming model.
Lessons Learnt:
- Applications should not require modifications based on the Deployment Model.
- Dynamic adaptability to changes in topology.
- Support for all kinds of parallel and distributed applications.
- Minimal onus on the user requesting the deployment.
Condor Glide-in
Condor provides a tight job management module for the jobs submitted to the resources in the condor pool. Submission of the jobs, specifying the job requirements (in terms of the # of resources required, time of execution etc.), termination of the jobs, maintaining the jobs persistently, and the information about the states of the jobs in submit-execute-result cycle are some of the very desirable features provided in condor. It selects the resources that best suits the users’ requirements and the nature of the job, by ensuring it at various levels; modules probing the search for the resources, modules responsible for searching the resources that suits the need both play roles in making this decision.
Condor-G is tailored to a grid environment by enabling condor to use GT to start the jobs on the remote resources available in the grid (as a VO). Both Condor and Condor-G are queuing systems that submit the tasks to the job queues local to the remote resources. Users can submit the job and query about the state of the submitted jobs at a later time, that is, the user need not stay connected till the job completes reducing the dependency on the network.
Glide-in mechanism combines the strengths of Condor and Condor-G by building the condor pool on a Condor-G system [condor]. This makes it a system that can not only support jobs requiring runtime environments such as PVM, MPI, and JVM but also harness the computing power available remotely.
Lessons Learned:
Legion
Cactus
compile libraries for OS from source
Deployment with virtual machines
How is the deployment problem different from
a single computer
a distributed system - SOA
a parallel computer (this will be answered in section 3
What is the deployment problem
Case Study using Monte Carlo PI
We use the classic Monte Carlo method to compute PI value as an example to demonstrate the different instances, and aggregate the requirements of the deployment problem in Grids. However these may constitute only a subset of the requirements, they provide prototypes of various dimensions of the deployment issue which any single model reviewed before fail to meet. This we believe is the first step in the right direction leading to a generic solution to the deployment problem in Grids.
Breifly ddescribe monte carlo pi program……..
How does it parctically differ, we use the following scenarios to gather a subset of requirements
Sequential Programs
In case of sequential PI program, a single processor makes all the attempts one after another to hit the dartboard, computes the PI value based on the successful attempts and returns the result to the user.
A typical situation of executing sequential PI program would involve user submitting the program to a processor and waiting for the results. There can be a variety of ways in which the user may have implemented the PI program, i.e., a java implementation requiring JVM, a C implementation requiring a particular type of C libraries and compilers (ANSI C, BORLAND C) with each implementation requiring different components (software as well as hardware) for successful execution. It is this diversity of components combined with the dynamic and heterogenous resources in the Grid that increases the complexity of the deployment problem.
Many of the existing implementations perform a great job in matching the resources to the requirement, but what is not obvious is that there is a metaphorical assumption that the pool of the resources at the users’ disposition will suffice the needs of the users. This may mean that the resources will be tuned to meet the needs in the background or users are constrained to have only a set of requirements off the resources.
Some of the requirements from the sequential case may include the following:
- Submit the job to a specific resource or let the system find an optimal resource (In the former we assume that the user chooses a resource that meets the minimum configuration requirement for the job, in the latter, it is responsibility of the system.)
- Tune the resource selected to meet the software requirements. This may involve:
- Install JDK or MPI (Transfer the installers, uncompress, install, set environment variables).
- Transfer the user submitted file that represents the job to be performed.
- Compile the file (javac, gcc etc.), if required.
- Begin execution with necessary parameters (either supplied by the user or system generated).
The system should also possess the following features:
- Persistent state of the job submitted.
- Persistent state of the installation.
- Ability for the user to query the status of installation (Job status is out-of-scope as it is addressed by execution management).
- User should be able to terminate, restart, and resume an installation.
- Manage the lifetime of the installation, depending upon the specification from the user.
Parallel Programs
In case of parallel PI programs, the number of attempts to be made which is supplied by the user is evenly distributed among the number of processors supplied by the user. All the processors attempt to hit the dartboard in parallel and return the successful attempts to the processor that initiated the computation which are consolidated to compute PI.
In a typical case, assuming MPI implementation, a cluster is setup (usually on processors with identical configuration operating on the same type of operating system with MPI libraries and compilers installed on each of the processors in the cluster), user then executes the PI program to get the computed PI value. That is the environment is setup for the user to execute MPI program to compute PI.
But in a Grid environment the user has different set of resources each with different configuration operating on different operating systems every time she wants to compute PI. The requirement here is to provide the same feeling as in the first case despite dynamically changing resources (We assume here that user will have access to the resources for the duration of computation. We do not address the situation, where the computation on a processor has to be stopped due to the expiration of user’s access to a resource. We differentiate this case from a node crash demanding a restart on the same resource or a different resource). This situation holds for MPICH or MPIAB implementations also.
The requirements for parallel implementations are the following:
Resource Management:
- Determine resources (a cluster for MPI, any set of processors for MPICH, MPIAB) based on the type of implementation and the number processors user is requesting.
Deployment Management:
- Install the necessary software components (for example LAM-MPI, OS specific MPICH, MPIAB for respective implementations) if not already present.
- Transfer the source file to one or more processor depending on the file system shared by the resources and the type of implementation.
All the features listed in case of sequential programs will hold in this case.
Web Services Program
In case of Web Services implementation, users look for service available to compute PI, invoke the services with necessary parameters and accept the returned results. In our implementation the users (client programs) propagate the input from the user - the number of attempts to be made to the service that makes the specified number of attempts and returns the successful attempts. Client program invokes several instances of such a service and consolidates the successful attempts from each instantiation to compute PI.
This means that such a service should be available when the user tries to execute her program. In a SOA, users’ role is to exploit the services available and the administrators’ role is to deploy these services. If a user attempts to invoke services that are not deployed, then he would be unsuccessful inevitably and should to wait until the services are deployed. Service not available could be due to a variety of reasons such as, they are taken down by the administrator for maintenance purposes or the service crashed or service is not developed yet. In the former two cases administrator should be notified for a faster fix in the latter case user has to wait until it is made available.
Some of the requirements in SO implementations are as follows:
- Unsuccessful attempt to use a service should be notified to the administrators automatically.
- Automate the deployment process at the administrators end – starting the Web Services server, deploying the service, notifying the registered users, terminating the service, terminating the server hosting the services.
Compare how it is done in [HAND] specific to GT4...
Karajan Programs
Lessons learned in each case
Solution to the deployment problem.
How do we propose to solve it?
Algorithm.- High level design and detailed design (debate the technologies adopted for implementation – viz; JMS, XWS – Security, and NIO)
Advantages over existing methods
Drawbacks
Scope for improvement
Application & Performance
MPIAB as a test case
How do I deploy it sequentially
What needs to be done to deploy it on a Grid
What is the performance benefit – numbers & graphs
Appendix
Sample Monte Carlo PI programs
Installation Instructions
LAM-MPI
NOTE: This has a lot of output....a classic case to show the user the current status of the installtion by piping the output to users' console.
- Download lam−7.1.2.tar.gz and execute
gunzip −c lam−7.1.2.tar.gz | tar xf −
- cd lam−7.1.2
- # Set the desired C, C++, and Fortran compilers, unless using the GNU compilers is sufficient
shell$ ./configure CC=cc CXX=CC FC=f77 −−prefix=/directory/to/install/in ...lots of output...
- shell$ make
...lots of output...
- shell$ make install
...lots of output...
- The following step is optional. Ensure that $prefix/bin is in in your $path so that LAM’s newly−created ‘‘mpicc’’ can be found before running this step.
set PATH=$PATH:$.../lam-7.1.2/bin make examples ...lots of output...
MPICH
MPIAB
You will need to install Grasshopper2.2.4 before installing MPIAB.
- Download Grasshopper2.2.4.tar.gz to $PWD
- Execute the command gunzip Grasshopper2.2.4.tar.gz to unzip
- Execute the command tar -xf Grasshopper2.2.4.tar
- Set CLASSPATH=$CLASSPATH:$PWD\Grasshopper2.2.4\lib\gh.jar
This finishes Grasshopper 2.2.4 installation.
- Download MPIAB1.0.tar.gz to $PWD
- Execute the command gunzip MPIAB1.0.tar.gz to unzip
- Execute the command tar -xf MPIAB1.0.tar
- Set CLASSPATH=$CLASSPATH:$PWD\MPIAB1.0\classes
This finishes MPIAB1.0 installation.
SOAP
