Quarterly report ScotGrid Quarter Fraser Speirs

2005 Q1Quarterly report: ScotGrid Current site status data SiteService nodes Worker nodes Local network connectivity Site connectivity SRMDays SFT failed Days in scheduled maintenance Security incidents this quarter which impact on Grid DurhamSL3 LCG2.4.0 SL3 LCG Mb/s1Gb/sNo870 EdinburghSL3 LCG2.5.0 SL3 LCG Gb/s dCache (not fully deployed ) 3460 GlasgowSL3 LCG2.4.0 SL3 LCG Gb/s No )Local network connectivity is that to the site SE 2)It is understood that SFT failures do not always result from site problems, but it is the best measure currently available.

2005 Q1Quarterly report: ScotGrid All GridPP Resources SitePromisedActual Average kSI2K available in this quarter CPU (kSI2K) Storage (TB) Average kSI2K available in this quarter CPUStorage (TB) Durham Edinburgh Glasgow Total )The GridPP-Tier-2 MoUs made reference to integrated CPU over the 3 years of GridPP2. Under the “Promised – integrated kSI2K hours until this quarter” an estimate is provided of what the Tier-2 would have expected to provide to this quarter on the basis of planned installations. “Static kSI2K” shows what would currently be expected if all purchases planned to this quarter had been made and implemented. The actual columns show what has been delivered.

2005 Q1Quarterly report: ScotGrid LCG resources SiteEstimated for LCGCurrently delivering to LCG Total job slots CPU (kSI2K) Storage (TB) Total jobs slots CPU (kSI2K) Storage (TB) Durham Edinburgh Glasgow Total ) The estimated figures are those that were projected for LCG planning purposes: 2) Current total job slots are those reported by EGEE/LCG gstat page.

2005 Q1Quarterly report: ScotGrid VOs supported by site SiteALICEATLASBiome d CMSSixtdTeamZeusLHCbTotal Durham Edinburgh Glasgow Total => not supported 1 => supported

2005 Q1Quarterly report: ScotGrid CPU used per VO over quarter (KSI2K hours) SiteALICEATLASBABARCMSLHCBZEUSabcTotal Durham 33 Edinburgh Glasgow Total 1)Information currently available from APEL - please note these pages are still under development! Nb. This could be automated with an SQL/R-GMA query

2005 Q1Quarterly report: ScotGrid Usage by VO for Tier-2 Jobs Apr 2005May 2005Jun 2005 alice atlas cms2120 dteam lhcb abc CPU (KSI2K hours) Apr 2005May 2005Jun 2005 alice atlas cms3 dteam lhcb abc

2005 Q1Quarterly report: ScotGrid Usage by VO (jobs) Nb: This can be extracted from APEL

2005 Q1Quarterly report: ScotGrid Storage resources in use per VO (TB) Site StorageALICEATLASCMSdTea m LhcbSixtZeusTotal Durham Edinburgh Glasgow Total Difficult to provide this for the period but we can at least show *current* usage. If we can get the information average and maximum per VO over the period would be useful parameters to record.

2005 Q1Quarterly report: ScotGrid CPU Usage by VO (KSI2K hours) Nb: This can be extracted from APEL –

2005 Q1Quarterly report: ScotGrid Progress over last quarter SiteSuccessesProblems/Issues DurhamUpgrade to LCG2.4 Significant reliability improvement Documentation Late release of LCG 2.6 meant problems EdinburghUpgrade to LCG2.5 Participation in SC3 Deployment of dCache SRM Trials of DPM Documentation Lots of difficulty with dCache - mostly solved but v. Time consuming GlasgowDeployment of all CPU resources Pre-production deployment of DPM SRM Documentation Availability of staff to troubleshoot Late release of 2.6 caused problems

2005 Q1Quarterly report: ScotGrid Tier-2 risks General risks Lack of documentation for middleware threatens meeting MoU commitments. Concern over migration strategy from Classic SE to dCache Feel that scheduled LCG release plan has been abandoned Possible resistance to Scientific Linux for future shared cluster at Glasgow Mitigating actions Using GOC Wiki entries as substitute Writing ‘experience’ documentation None known. Tool support and migration strategy is required. Inevitably lowers priority of doing upgrades - can’t just drop everything and upgrade. Virtualisation? Institute specific risks Some concern over reinvestment at Durham Mitigating actions Attempts to secure further funding are ongoing.

2005 Q1Quarterly report: ScotGrid Tier-2 planning for next quarter Maintaining presence on grid Complete DPM SRM deployment at Glasgow, Durham Reliability/metrics a focus Focus on team communication and coordination at Glasgow (see: Better internal monitoring of cluster performance and uptime (Ganglia/Nagios)

2005 Q1Quarterly report: ScotGrid Objectives and deliverables for last quarter Objective/deliverableDue dateStatus All sites to 2.4.0April 1st (or release date) + 3 weeks Done dCache deployed at GlasgowApril 1st + 3 weeksNot done - choosing DPM dCache deployed at EdinburghApril 1st + 3 weeksDone, although dCache issues delayed Increase disk space at GlasgowEnd Q2Not done - awaiting SRM deployment Refurbishment of server room at GlasgowEnd Q2Done dCache deployed at DurhamNone setNot done - waiting on results of Glasgow DPM evaluation Continue planning for network upgrades in respect of service challences None setOngoing. Using experience of SC3 at Edinburgh to guide.

2005 Q1Quarterly report: ScotGrid Objectives and deliverables for next quarter Objective/deliverableDue dateMetric/output All sites to 2.6.0Set by ROC DPM deployed at GlasgowEnd Q2 SRM deployed at DurhamEnd Q2 Full Ganglia implementation across T2End August Continue planning for network upgrades in respect of service challences None setSC4-capable network connectivity

2005 Q1Quarterly report: ScotGrid Meetings, papers & effort Tier-2 coordinator effortComments 3.0 AreaDescription TalksScotgrid status - GridPP13 ConferencesGridPP13 LCG Ops Workshop - Bologna EGEE 3 - Athens Publications For Tier-2 coordinator:

2005 Q1Quarterly report: ScotGrid Summary & outlook Good progress this quarter on resource deployment, especially Glasgow CPU and Edinburgh disk. Progress on SRM deployment promising, although we still need a story about migration from Classic SE. Improvement in team coordination at Glasgow Outlook is good for hardware refresh at Glasgow, Edinburgh Lack of enthusiasm for Scientific Linux across Glasgow’s local userbase leads us to believe that there is a pressing need to research and solve the problem of LCG co-existence inside a shared cluster. (Portability/Xen?) Need to find ways to make SFT results match reality. Currently, they make the situation look worse than it is because of full queues.