UK Globus Week04 April, 05 10:00 AM - 08 April, 05 04:00 PMe-Science Institute, 15 South College Street, , Edinburgh |
 | ||
| |||
| [eSI Events] | [NeSC Home] | [Pre-requisites] | [NeSC Home] |
|
| ||||||||
| |||||||||
Report on GT4 Performance Tuning Activities and External Security Review
In the development of version 4 of the Globus Toolkit, there have been several areas that have received unprecedented levels of effort. We have striven to make the process more open by holding public phone conferences, community calls for testing, and having an external review of the security architecture. Performance has also received never before seen levels of effort. In this case, we take performance in it's broadest sense. We include robustness, stability, throughput, user experience, etc.
In this talk I provide a brief overview of the results of the external security review that was performed, and the performance efforts that have taken place to date.
Globus and the eMinerals project
The eMinerals project has been operating a production minigrid for some time now. This minigrid is built from the three middleware pillars of Condor, Globus and the SRB. In this talk I will describe how these have been integrated in order to make the middleware as transparent as possible for the end users, with particular emphasis on how Globus was made to fit in. In particular, some modifications that were found to be necessary will also be described.
OGSA-DAI: Responding to a Changing World
OGSA-DAI is a UK eScience funded project to provide access to data resources on Grids. The project was originally based on GT3 and has moved forward to use, amongst others, the early versions of GT4. This talk will look at the process of moving data services written in GT3 to GT4 and the teams experiences with porting and supporting code, as well as discussing the issues with continuing support for an established GT3 userbase.
Experiences with migrating GEMLCA from GT3 to GT4
So far relatively little attention has been paid to how end-users can survive in the rapidly changing world of Grid generations. The primary goal of our research is to construct a high-level Grid application environment where the end-users can:
The research team in the Centre for Parallel Computing at the University of Westminster, has developed GEMLCA (Grid Execution Management for Legacy Code Architecture), a system to enable legacy applications to be quickly and efficiently deployed on the Grid via a user-friendly Web interface. Using GEMLCA, existing programs written in any language (Fortran, C, Java, etc) can be deployed very easily as a Grid service by end users having no programming knowledge. The user-friendly Web-based access to GEMLCA has been provided by integrating the tool with the P-GRADE Grid portal and workflow system developed by SZTAKI Research Institute in Hungary. Utilising the portal, users having little or no knowledge of Grid systems can deploy old legacy codes as new Grid services, simply by selecting Grid resources and attaching the codes. With modest know-how, they can even construct and execute workflows that support complex processes.
The talk will:
Demonstration:
In order to demonstrate the integrated GEMLCA P-Grade portal solution,
a workflow for analysing urban car traffic on road is created. The workflow consists of three
different components: a Manhattan road network generator, traffic simulators, called MadCity,
and an analyser. The Manhattan road network generator creates MadCity compatible network
and turn input-files. The output of this component is used as input to MadCity traffic
simulators that run parallel on UK e-Science OGSA Testbed sites with different number of cars as
input parameters. After completing the simulations, the generated trace files are input
to an analyser that compare the traffic density on roads and illustrate the results on
graphs.
Dependable Grid Services: composing services against quality-of-service requirements
The DIGS project seeks to automate as much as possible the composition of services in pursuit of quality-of-service requirements (such as service level agreements) through choice of appropriate components (diversity) and modification of workflow (structure). This can only be done if the effect of differing service choices and workflow modifications can be understood. In some of our most recent work we offer a tool which predicts the aggregate behaviour of a composition in terms of its workflow structure and the known behaviour of its individual services. By using such predictions, compositions can be optimised to match service level agreements, affording a critical tool in the future development of distributed applications.
During 2003 the project was entirely based within the Globus Toolkit 3 framework (from alpha release onwards), encompassing three different development strands engaged with notification, dynamic invocation, and service proxying respectively. This presentation will give an overview of the project, a taste of our current work, and a review of our experiences with GT3.
GT 2 and 3 Experiences on the INWA and HPC Europa JRA2 projects
Abstract. The INWA project has used GT2 and GT3 based tools to analyse commercial data located at sites in the UK, Australia and more recently China. The HPC Europa JRA2 project is building a single point of access portal for visitors to European HPC centres. As part of JRA2, EPCC are integrating the GT3-based JOb Scheduling Hierarchically (JOSH) tool with this portal. In this presentation I will describe the experiences of the INWA project team using GT2 with the Grid Engine Transfer-queue Over Globus (TOG) Tool. I will then describe the experiences of HPC Europa JRA2 team when developing and deploying JOSH using GT3. Finally, I will provide a brief wish-list for GT4.
The University of Bristol Campus Grid, production using a pre-service based architecture.
Within the University of Bristol it has been historically true that each research group has specified, purchased, managed and used their clustered resources. This has led to their being about 15 clusters and 4 Condor pools within various differing departments. So one of the key tasks for the e-Science centre was creation of a campus grid, to unify access and increase system usage levels. Since creation we now have five different groups of users with up to six different applications already ported. This shows the success of the system and is possible expansion towards other universities within the region.
The tools chosen for each component of the system will be described with experiences of what we have found good and bad about these described. In particular tuning that was necessary for scalability.