http://www.grid-support.ac.uk
http://www.ngs.ac.uk
NGS in the future: emerging
middleware
Richard Hopkins
rph@nesc.ac.uk
http://www.nesc.ac.uk/
http://www.pparc.ac.uk/
http://www.eu-egee.org/
Goal of talk
• The NGS is running a production service
• Different middleware may be deployed in the
future.
• The talk seeks to outline some of the
possibilities
2
NGS middleware evolution
EGEE…
Other software
sources
Prototypes &
specifications
‘Gold’ services
NGS
ETF
Software with proven
capability & realistic
deployment
experience
UK,
Operations Campus
and other
grids
Feedback & future requirements
Engineering Task Force
Deployment/testing/advice
3
Outline of current Status
• Middleware currently being prepared for
deployment
– Resource broker
• Under assessment:
– gLite middleware from EGEE
– OMII
– GT4
4
LCG Resource broker
• (This is NOT the SRB!!!)
• Current NGS middleware : Toolkits inviting
development of higher level services
• On the current NGS we have
– GRAM to submit jobs
– Information service to tell us what queues are busy
• The RB will take the work out of deciding where
to run a job
– Submit job to the grid, not a specified “compute
element”
5
Major components
“User
interface”
Input “sandbox”
Output “sandbox”
DataSets info
Replica
Catalogue
Information
Service
Resource
Broker
Publish
Logging &
Book-keeping
Job Query
Job Submit Event
Author.
&Authen.
Storage
Element
Job Status
Computing
Element
Resource broker
• Job Description Language file: describes
resources needed by a job
• Commands analogous to GT2:
– edg-job-submit <jdl filename>
– edg-job-status <dg-job-id>
– edg-job-get-output <dg-job-id>
7
Example
• edg-job-submit myjob.jdl
– Myjob.jdl
• JobType = “Normal”;
• Executable = "$(CMS)/exe/sum.exe";
• InputSandbox = {"/home/user/WP1testC","/home/file*”,
"/home/user/DATA/*"};
• OutputSandbox = {“sim.err”, “test.out”, “sim.log"};
• Requirements = other. GlueHostOperatingSystemName ==
“linux" &&
• other. GlueHostOperatingSystemRelease == "Red Hat 7.3“
&& other.GlueCEPolicyMaxCPUTime > 10000;
• Rank = other.GlueCEStateFreeCPUs;
8
More about the RB
• Developed by the European DataGrid project, EDG then
“hardened” by LCG, and now one of the sources for the
EGEE middleware
• Uses components of Condor
– matchmaker and Condor-G
• Try the GENIUS portal on GILDA
– GILDA is a dissemination grid running the LCG-2 middleware
– Demo site: https://grid-demo.ct.infn.it/
• And look at
http://lcg.web.cern.ch/LCG/
http://www.hep.ph.ic.ac.uk/escience/projects/demo/index.html
9
Resource broker summary
• The resource broker receives a job description
in JDL
• It chooses a batch queue for job submission,
using the information services
• Its an example of the higher services that can be
deployed for the NGS, built upon the current
toolkits
10
Outline of Current Status
• Middleware currently being prepared for
deployment
– Resource broker
– (NGS portal – yesterday!)
• Under assessment:
– gLite middleware from EGEE
– OMII
– GT4
11
EGEE – towards e-infrastructure
Enabling Grids for E-sciencE
A four year programme:
Build, deploy and operate a
consistent, robust a lage scale
production grid service that
– Links with and build on national,
regional and international
initiatives
– attracts new computing
resources
•
Improve and maintain the
middleware in order to deliver a
reliable service to users
•
Attract new users from science
and industry and ensure training
and support for them
INFSO-RI-508833
Pan-European Grid
Operations, Support and
training
•
Collaboration
Network
infrastructure
& Resource
centres
12
In the first 2 years EGEE will
Enabling Grids for E-sciencE
• Establish production quality sustained Grid
services
– 3000 users from at least 5 disciplines
– integrate 50 sites into a common
infrastructure
– offer 5 Petabytes (1015) storage
• Demonstrate a viable general process to
bring other scientific communities on board
• Propose a second phase in mid 2005 to take
over EGEE in early 2006
INFSO-RI-508833
Pilot
New
13
EGEE Organisation
Enabling Grids for E-sciencE
• 70 leading institutions in 27
countries, federated in regional Grids
• ~32 M Euros EU funding for first 2
years starting April 2004
(matching funds from partners)
• Leveraging national and regional grid
activities
• Promoting scientific partnership
outside EU
INFSO-RI-508833
14
gLite: Guiding Principles
Enabling Grids for E-sciencE
•
VDT
EDG
...
AliEn
LCG
...
Service oriented approach
– Allow for multiple interoperable
implementations
•
Lightweight (existing) services
– Easily and quickly deployable
– Use existing services where
possible
 Condor, EDG, Globus, LCG, …
•
Portable
– Being built on Scientific Linux and
Windows
•
•
Security
– Co-existence with LCG-2 and OSG
(US) are essential for the EGEE
Grid services
– Sites and Applications
•
Performance/Scalability &
Resilience/Fault Tolerance
•
Site autonomy
– Reduce dependence on ‘global,
central’ services
– Comparable to deployed
infrastructure
•
INFSO-RI-508833
Co-existence with deployed
infrastructure
Open source license
15
Open Middleware
Infrastructure Institute
OMII goal: to be the source of open source grid
software





Institute of the University of Southampton
Utilise existing software and standards
Production focused software development
Integrate, test & document ‘a product’
Focus on the user experience


Easy to install & use
Utilise existing software and standards

Provide a solid web service base for others to build on
17
Where does our software come
from?

Open Source Community


Software Repository



Tomcat, Axis, etc.,
Accept software contributions
Software deployed, tested & graded to provide
feedback
Managed Programme


Fill gaps to build a solid enabling infrastructure
Projects to bring research software to production
quality
18
Managed Programme









GridSAM (Job Submission & Monitoring service)
BPEL (Workflow service)
Grimoires (Registry service based on UDDI)
FIRMS (Reliable messaging)
FINS (Notification)
GeodiseLab (Matlab toolbox)
WSRF::Lite integration
OGSA-DAI (Database service)
WSeSS (Using SSH to tunnel requests to resources)
19
OMII_1 release:
A basic File-Compute Grid




Enables a generic computational task
Move input data from the client to the service
provider
Process the data using an application on the
service provider
Retrieve the output data from the service
provider
20
OMII Server Infrastructure
PBAC
ExampleService
TestService
Job
Data
Allocation
Account
Resource Acct
Mgmt
Mgmt
Servlet Servlet
Happy
Axis
WS-Security
AXIS
Static Webpage
TOMCAT
21
Try out the OMII_1 client !



Register at www.omii.ac.uk & login
Goto the downloads page
Download the client distribution



SuSE 9.0
 Client may work on other Linuxs but no exhaustive testing
Windows XP (SP 1 & 2)
Distribution requires JDK 1.4.2_04



Does not work with ‘just’ a JRE
Will not work with JDK 1.4.2_05/06 & JDK 1.5.0
No testing with earlier JDKs.
22
GT4: A Service-Oriented
Infrastructure
Users
• Service-oriented applications
– Wrap applications as
services
– Compose applications
into workflows
• Service-oriented
infrastructure
– Provision physical
resources to support
application workloads
Composition
Workflows
Invocation
Appln
Service
Appln
Service
Provisioning
•Carl Kesselman at Globus Week, NeSC, 4th April
– 8th April 2005
23
The future
Neil Geddes
<N.I.Geddes@rl.ac.uk>
Director, GOSC
All Hands Meeting, 2005
24
User Confusion and The Road
Ahead
• GOSC aim to deploy a Web/Grid Services based infrastructure.
– Has proved significantly more challenging than originally hoped.
• several years to develop the stable GT2 based middleware to a production
state
• Re-implementing this knowledge as robust web services has not proved
simple.
• Upheaval around OGSI also delayed coherent application
development
• WS standards are emerging more slowly than originally hoped.
• Uncertainty about the security models adds further uncertainty
– JISC adoption of Shibboleth has not reduced the confusion.
– Recent initiatives in the US and UK have only just begun to address
grid/shibboleth integration.
– Work towards authentication and authorisation based on users
institutional identity
25
Strategy for the Future
•
OGSA remains important to the future development of the NGS
– OGSA addresses the fundamental capabilities/services needed to build grids
– OGSA is only beginning to deliver on first specs (Basic Execution Services)
– There are encouraging signs.
• The Job Submission Description Language standard
• A storage interface –SRM- has been agreed across a large number of grid
projects (though only a limited set of implementations of this standard exist)
• common information schema, the GLUE schema, is in common use around
the world..
•
“middleware hardening” activities such as the UK’s Open Middleware
Infrastructure Initiative will be crucial to out future success.
– take emerging standards/early implementations -> to robust and user friendly
implementations.
– The world does not need yet another job submission interface, it needs a robust
implementation of the agreed and tested open standards!.
26
GOSC Strategy
•
Strategic Framework recognises:
– Need for clear goals and quality control of any new
GOSC services.
– GOSC should have a service focus and not a
technology focus.
– Compatibility with emerging European eInfrastructure (EGEE).
– Importance of Shibboleth for authentication and
authorisation.
– Service based grid infrastructure remains the goal of
the GOSC
27
GOSC Plans
• Currently no plans to deploy a middleware alternative to VDT/GT2
• First Shibboleth integration during Q3 2006
Under Evaluation
• GT4 software looks encouraging
– Sufficient compatibility between GT2 and GT4.
– improvement in stability (cf GT3).
– Looking for early adopters to work with
• GLITE (EGEE)
– evaluation is not complete.
– Problems with deployability and dependences
• OMII-1.0
– Working with some user groups
– Brings no new functionality/benefits to NGS
28