1 / 9

LCG1 to LCG2 Transition

LCG1 to LCG2 Transition. Markus Schulz LCG Workshop March 2004. Overview. LCG2 what is different LCG1 -> LCG2 Discussion. LCG2. Software Some changes in the data management Improved stability in the services Switch to radical different Ses (SRM) (soon) Operation

sakina
Télécharger la présentation

LCG1 to LCG2 Transition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LCG1 to LCG2 Transition Markus Schulz LCG Workshop March 2004

  2. Overview • LCG2 what is different • LCG1 -> LCG2 • Discussion Markus.Schulz@cern.ch

  3. LCG2 • Software • Some changes in the data management • Improved stability in the services • Switch to radical different Ses (SRM) (soon) • Operation • Focus now on production quality • Focus on total amount of resources • Focus on stability during the experiment’s data challenges • Focus not primary on number of sites. • Installation/Configuration • Now the sites can choose between manual and LCFGng based procedures • makes integrating existing resources easier • WN, UI, CE, SE, RB, lcg-BDII,(missing PROXY) Markus.Schulz@cern.ch

  4. LCG2 • This lead to the concept of CORE Sites • Well supported sites that can initially follow early releases quickly • Experienced staff that quickly can locate configuration problems • Each site committed to provide significant resources (storage, CPU) • Sites integrate their local computing facilities with LCG • Current Core Sites: • CNAF,CERN,FNAL,FZK,NIKHEF,PIC-Barcelona,RAL,Taipei • Total of > 1800CPUs • Improved communications: • Core site mailing list • weekly phone conference (not workable with 30+ sites) Markus.Schulz@cern.ch

  5. LCG1->LCG2 • Only well tested sites should be added to the core • More testing • Testing by the experiments • Tested and non tested sites should not live in the same environment • This avoids faulty sites to atract jobs. • Based on the new LCG-BDII we can separate LCG2 into different views. • A view is represented by a configuration file for the BDII • A view can be shared and centrally managed (http) • A site can be present in different views • An RB submits only to sites that are present in the view • Experiments can provide their own configuration files and add/remove resources Markus.Schulz@cern.ch

  6. LCG1->LCG2 • Currently: Views for CMS, LCG2 Production, and LCG2 TestZone. • Moving a site from LCG1->LCG2 • Site contacts primary site (CERN in case of an independent sites) • Site installs given tag using the preferred procedure • Initially the site installs CEs, WNs, and SEs only using the testZone RB and BDII • Site contacts primary site • Primary sites sends site GIIS name and hostname to the deployment team • deployment team adds the site to the TestZone configuration • primary site runs initial checks and solves problems with the site • do simple jobs run? • can the site access storage (local, remote)? • do the datamanagement tools work? • is the experiment software installation mechanism working? • The deployment team runs a test suite on the new site • The experiments will be invited to run their test jobs on the site • The deployment team repeats their tests. • Site is added to the core sites. Markus.Schulz@cern.ch

  7. New Sites • Contact a suitable primary site first • Primary site walks the new site through the process • There is a problem for new sites to find the correct place to enter the game. We need a link from the top page of LCG Markus.Schulz@cern.ch

  8. LCG1->LCG2 • When? • Should have started last week • Some sites started on their own • Documentation needs to be updated • Validation jobs need to be added to the release • Why delayed? • Limited number of persons • Data challenges required a lot of on demand work Markus.Schulz@cern.ch

  9. Discussion • What specific part of the documentation needs improvement? • Primary/Secondary sites • Initial Testing……….. Markus.Schulz@cern.ch

More Related