Neil Geddes <N.I.Geddes@rl.ac.uk> Director, GOSC All Hands Meeting, 2005

1. http://www.ngs.ac.uk http://www.grid-support.ac.uk The UK’s Grid Operations Support Centre and National Grid ServiceCore Components of the UK’s e-Infrstructure Neil Geddes <N.I.Geddes@rl.ac.uk> Director, GOSC All Hands Meeting, 2005

2. Outline • GOSC and NGS – who and what are they • Services and facilities • The first year • users and stuff • The future

3. Services and facilities

4. The National Grid Service Launched April 2004 Full production - September 2004 Focus on deployment/operations Do not do development Responsive to users needs

5. NGS Facilities • Leeds and Oxford • 64 dual CPU intel 3.06GHz (1MB cache). Each node: 2GB memory, 2x120GB disk, Redhat ES3.0. Gigabit Myrinet connection. 2TB data server. PGI and Intel compilers, totalview debugger, PBSpro. • Manchester and RAL • 20 dual CPU (as above). 18TB SAN. Software as above + Oracle Application Server. • Bristol • initially 20 2.3GHz Athlon processors in 10 dual CPU nodes. • Cardiff • 1000 hrs/week on a SGI Origin system comprising 4 dual CPU Origin 300 servers with a Myrinet™ interconnect. • Lancaster • 8 Sun Blade 1000 execution nodes, each with dual UltraSPARC IIICu processors connected via a Dell 1750 head node. • HPCx and CSAR • …

6. GOSC

7. GOSC Services • UK Grid Services • National Services • Authentication, authorisation, certificate management, VO registration, security, network monitoring, help desk + support centre. • NGS Servicesand interfaces • Job submission, simple registry, data transfer, data access and integration, resource brokering, monitoring and accounting, grid management services, workflow, notification, operations centre. • NGS core-node Services • CPU, (meta-) data storage, key software • Services coordinated with others (eg OMII, NeSC, EGEE, LCG): • Integration testing, compatibility & Validation Tests, User Management, training • Administration: • Policies and acceptable use • SLA’s, SLD’s • Coordinate deployment and Operations • Operational Security

8. Service Usage • The NGS offers a range or services focused on data access and computation • Batch submission, application software, data sets data management • Most current users make use of a limited range services. • More sophisticated services only recently being investigated • User communities gain confidence in support of NGS interfaces • NGS itself provides access to useful resources. • Immaturity of the available supporting software/middleware • NGS goal is to deploy and support reliable, tested software • Also reflects significant community based developments and education that are required to take full advantage of the opportunities offered. • Sustained support for a stable infrastructure will be key to encouraging community initiatives to tackle these latter points. • This commitment is in EPSRC and JISC planning

9. The first year

10. Growth Several new sites have joined NGS: • New partners join the NGS through a well defined process: • 1. Define level of service commitments through a Service Level Definition • 2. Agree to and adopt NGS acceptable use and security policies. • 3. Run compatible middleware as defined by NGS Minimum Software Stack • 4. Support monitoring and accounting • The compatible middleware • Defines NGS interface for authentication, data transfer and job submission. • Is OGSA compliant • Is implemented by the NGS core nodes using the Globus from VDT • Same as OSG (US) and EGEE (Europe) +… • Further interfaces then provide for interactive access, SRB. … • Two levels of membership are supported: • Affiliation - connection to the NGS, supporting the common interfaces. • Partnership - resources are made available to all NGS users • Services reviewed against SLD ~every 6 months.

11. New partners Over the last year, three new full partners have joined the NGS: • Bristol, Cardiff and Lancaster • Further details of resources can be found on the NGS web site: www.ngs.ac.uk. • Resources committed to the NGS for a period of at least 12 months. • The heterogeneity introduced by these new services has • provided experience in connecting an increasingly wide range of resources to the NGS • presented a challenge to users to make effective use of this range of architectures • basic common interface for authentication+authorisation is the first step towards supporting more sophisticated usage across such a variety of resources. • 1 further site currently deploying, 3 in discussion.

12. NGS Users

13. Users by “Research Council”

14. CPU hours requested, by Research Council

15. Users known funding • #Jobs “project” • 1117 nano-particles • 772 protein folding • 774 ab-initio protein structure prediction • 582 lattice-boltmann simulations • 555 radiation transport (radiotherapy) • 255 Neutron data analysis • 242 geophysical data analyis • 228 medical imaging • 228 Biological membranes • 171 micromagnetics • 123 integrative biology

16. Users by institution IB INRIA IB

17. The future

18. 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

19. 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) • without OGSA we would simply have to invent (yet) another similar activity. • Key requirement for OGSA success will be its contribution to and adoption by the major production grid deployments around the world and the commercial IT world (and must support alternative implementation stacks). • 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!.

20. GOSCStrategy • 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 e-Infrastructure (EGEE). • Importance of Shibboleth for authentication and authorisation. • Service based grid infrastructure remains the goal of the GOSC • Additional operational issues • The NGS Authentication and Authorisation Model is based on Globus GSI and the delegation possible in this model remains important to the NGS. • The GOSC will support only authenticated and auditable (grid/web) services. • Users can run authenticated services “at risk” and may run unauthenticated services for a limited time only.

21. The services supported by the GOSC will continue to form the basis of a sustainable e-infrastructure, providing authentication, authorisation, collaboration and resource sharing tools to meet the requirements of research collaborations and access to large national and international facilities and resources. The NGS cares about: • alignment/compatibility with leading international Grid efforts • special requirements of UK e-Science community • easy migration/upgrade paths • growth: minimising cost of membership for partners based on standards • proven robustness/reliability • usability: but this is too big a problem for us to solve alone Significant changes to NGS Minimum Software Stack will require approval by NGS Management Board on conservative time scales. However, NGS and GOSC will endeavour to work with all users to meet their current and future needs as the principal deliverable for the NGS will always be to help deliver effective and reliable services to support UK research.

22. GOSCPlans • Currently no plans to deploy a middleware alternative to VDT/GT2 • First Shibboleth integration during Q3 2006 • 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 • Will update again at end of year.

23. Conclusions • NGS being used • Increasing user base • Compatibility important • Aim to drive common standard interfaces

25. NGS usage policy • Current policy is driven by need to • encourage new “grid” users • ensure that NGS resources are used effectively • Balance between “initial trial” and “production Service” • We are happy to support production services, but can currently only do so on an ongoing short term basis (!)