Hiding Grid Complexity Behind
SSH Session Server framework
Tomasz Kuczyński (1,2)
docentt@man.poznan.pl
Piotr Kopta (2)
kopta@icis.pcz.pl
1) Poznan Supercomputing and Networking Center
2) Czestochowa University of Technology
Outline
SSH Session Server framework
CLI Model Example
Framework Architecture
Application Managers
Interactions between the components
Demo
SSH Session Server framework
What exactly is SSH Session Server framework ?
Why SSH ?
Installed on each resource
No modifications of existing applications needed
Why PTYs ?
utilization of standard SSH client
How does framework work with SSH session ?
CLI interaction model
Application descriptors
SSH Session Server framework (cont.)
Main goal of the framework is to gain high level of
business logic – presentation layer separation
SSH Session Server - continuation of WebCI portal
solutions
Features:
Adding user-defined interfaces at portal run-time
Easy adaptation of existing applications
Seamless installation
XML-based application interface description
VRML, X3D, SVG, Charts (jpeg, png) support
CLI Model Example
Framework Architecture
Application Managers
Simple applications that have CLI
Application manager using the grid resource
management system such as GRMS may submit
many parallel jobs (reduce apps run-time) and control
all the computing on user’s behalf
Overall system performance is increased
User interaction is limited to required minimum
run a job
view results
do not worry about resources
Apps manager will adjust number of jobs running in parallel to
the number of resources available
Interaction between the components
Portal <-> Application Manager <-> Grid Infrastructure
User sets up the input parameters and orders to start an application
Portal passes input data to Application Manager (APPMGR)
Application manager uses the GRMS GAT adaptor to run an application
Resource and job description generated by APPMGR is sent to
GRMS
GRMS finds appropriate resources and runs a job
GRMS, using replica management system or GRMS’s own file
movement mechanisms, stages the files
GRMS starts a job and returns job handler to the APPMGR
Interactions (cont.)
APPMGR collects all the results and presents them to
the portal
User decides about the next steps
Chooses the visualization style
HTML, XML, VRML, X3D, SVG, JFreeChart
Plays with the results and decides about further application runs
Views the history of the application runs
Sets up the notification mechanisms (email, sms, other...)
All user activities are asynchronous and non-blocking
A user can for example start a job and then, while waiting for the
results, logout, go for a coffee and then return to the application
Today’s demo
We will show an interactive Heat Transfer application
run using GridLab and ClusterIX tools (Portal, GAT,
GRMS, GAS, Mobiles Service, other) and SSH
Session Server framework
Application user perspective
Grid hidden behind the portal
No job description interface
Why should user struggle with it? This is too complex...
No data transfer interface
No less complex than job description interface, so why bother user
about it?
No resource discovery interface
Why should user know anything about the resources he might run
the job at?
Questions
For more information visit:
GridSphere http://www.gridsphere.org
GridLab http://www.gridlab.org
Open Grid Portals http://www.opengridportals.com
ClusterIX http://www.clusterix.pl
Thank you