460 likes | 543 Views
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
E N D
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
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