LCG2 as the basic CrossGrid Middleware architecture, components and comparison with Globus 2'x, EDG,

1
LCG2 as the basic CrossGrid Middleware
architecture, componentsand comparison with
Globus 2.x, EDG, LCG1

• Gathered and presented by Katarzyna Rycerz

2
Note

• The contents of this presentation come from
• David Foster , Flavia Donno, Massimo Lamanna,
  Andrea Sciabà LCG-1 Architecture Summary
  http//lcg.web.cern.ch/LCG/
• Presentations at LCG Workshop 2004, CERN
  http//agenda.cern.ch/fullAgenda.php?idaa04105
• Antonio Delgado Peris, Flavia Donno, Patricia
  Mendez Lorenzo, Andrea Sciaba, Simone Campana,
  Roberto Santinelli
  LCG-2-Userguide
• http//lcg.web.cern.ch/LCG/
• Presentation and emails from Jorge Gomes
• Emails discussions with Stefano Beco, Lukasz
  Dutka, Tomasz Szepieniec, Marcin Radecki and
  Maciej Malawski
• The presentation does not describe autors work
  on LCG architecture design neither her personal
  opinion about the architecture !

3
Which CG Components are affected?
4
CG Connections - Detailed View
Roaming Access Server
Information Index
Legend
Scheduler
Planned Dependency
Dependency
Data Management
Workload Management
LB
LCG2
CG
GRAM
GridFTP
Optimisation Of Data Access
Globus
5
Components of LCG2 middleware

• EDG (European Data-Grid) 2.1
• predecessor of LCG
• http//www.eu-datagrid.org
• EDT (European DataTag) 1.1
• project that focuses upon interoperability
  between European Community and USA Grid domains
• http//datatag.web.cern.ch/datatag/
• VDT (Virtual Data Toolkit) 1.1.8.
• ensemble of grid middleware that can be easily
  installed and configured
• includes Globus 2, Condor, Condor-G
• http//www.lsc-group.phys.uwm.edu/vdt/

6
Components from EDG 2.1

• WMS Workload Management System
• Data Management System
• EDG-RM (Replica Manager)
• Including the EDG-ROS (Replica Optimisation
  Service)
• EDG-RLS (Replica Location Service)
• Including the EDG-LRC (Local Replica Catalog)
• EDG-RMC (Replica Metadata Catalog)
• Information service
• Information index BDII
• Virtual Organization Management
• EDG infrastructure and procedures
• Fabric Management
• EDG WP4 tools/procedures (LCFG, LCFG-Lite or
  manual procedures)
• LCAS/LCMAPS (Local Centre Auth. System and Local
  Mapping)

7
Components from EDT 1.1 and VDT 1.1.8

• Components from EDT 1.1
• Monitoring system
• Grid-ICE
• Glue Schema LCG-EDT 1.1
• Components from VDT 1.1.8
• Core components
• Globus 2.2.4
• Condor 6.4.7
• Bypass
• Condor-G
• ClassAds
• Information Service
• Globus MDS
• GRIS (Grid Resource Information Service)
• GIIS (Grid Index Information Service)

8
Workload Management System
RB Node
Network service
Replica Location Service
Match Maker/ Broker
User
Workload Manager
Information Index
RB storage
Job Adapter
Globus MDS
Job Control Condor-G
Globus GRAM
Storage Element
Computing Element
9
Workload Management System

• Network Server (NS), accepts the incoming job
  requests from the UI, and provides support for
  the job control functionality.
• Workload Manager, is the core component of the
  system.
• Match-Maker (also called Resource Broker), finds
  the best resource matching the requirements of a
  job (match-making process).
• Job Adapter, which prepares the environment for
  the job and its final description, before passing
  it to the Job Control Service.
• Job Control Service (JCS), performs the actual
  job management operations (job submission,
  removal. .)
• In addition, the Logging and Bookkeeping service
  (LB) is usually also run on a RB machine. Logs
  job management Grid events useful for users or
  system administrators.

10
CG Connections with WMS
Roaming Access Server
Information Index
Legend
Scheduler
Planned Dependency
Dependency
Data Management
Workload Management
LB
LCG2
CG
GRAM
GridFTP
Optimisation Of Data Access
Globus
11
Workload Management what is new ?

• Economic Brokering Infrastructure
• Attribute a price to resource usage,
• Price minimization through the scheduler,
• MPICH-P4 support,
• Feed of job status information to R-GMA,
• Reengineering
• names of many components has changed,
• New version of Condor (6.4.7)
• Support for interactive jobs,
• Condor Bypass the same solution as in CG ,
• Job Shadow on User Interface, Console Agent on
  Worker Node
• In LCG2 -the format of the user interface
  configuration files to select, an RB have
  changed, not backward compatible,
• In LCG2 bugs fixed in LB,
• Migration efford for CG Scheduler/RAS (?), but
  not as serious as during EDG-gtLCG1 migration.

12
Data Managment - Replica Location Service

• co-developed by the Globus team and Work Package
  2 of the DataGrid project
• The replica catalogue (LDAP) is replaced by a new
  replica location service.
• Replication Metadata Catalogue.
• Replica Location Index (RLI)
• Local Replica Catalogue (LRC)

13
CG Connections with DM
Roaming Access Server
Information Index
Legend
Scheduler
Planned Dependency
Dependency
Data Management
Workload Management
LB
LCG2
CG
GRAM
GridFTP
Optimisation Of Data Access
Globus
14
Data Management Changes in LCG2

• New Storage Resource Manager (SRM) versions of
  the SE now exists with support for HSM (castor)
  and disk pools (dcache)
• In the future only SRM-based SE will be
  supported in LCG
• Untill now, also classical SE present in Testbed
• Classical means pure GridFTP server
• The LCG2 replica management software is still not
  available and therefore was not tested in CG
  Tesbed.
• Migration efford for Scheduler/RAS probably NOT
  necessary
• CG Data Access is (going to be) used by LCG2, no
  migration efford from CG site (hopefully)

15
LCG Information System Monitoring

• The LCG information system
• New Information Index - Berkley Database
  Information Index (BDII)
• Generic Information provider
• Glue Schema
• Monitoring
• GridICE
• RGMA

16
Berkley Database Information Index

• Decided to be used by LCG people
• Because MDS is not production quality (tested),
• Standard openLDAP database,
• Database populated by a Perl script.
• Recent improvements
• Parallel population,
• Improved configuration,
• Automatic configuration update via web,
• Can run information providers directly.

17
Information Index in LCG2

• LCG Information Index is no longer an MDS tree,
• a configuration file for the BDII that contains
  the list of GIIS
• The BDII configuration file can be obtained from
  a web server thus enabling the configuration of
  redundant GIIS with the same view from a single
  configuration file at a single location.
• The BDII queries each GIIS from time to time and
  adds its contents to the BD
• Now, to obtain the information the client should
  
• Ask BDII about possible GIIS/GRIS
• Directly query GIIS/GRIS
• Or use BDII cache
• Different schema from what L. Leeming said CGW02
  
• If CG uses LCG WMS it also must use (indirectly)
  BDII
• Currently, no need for direct use BDII in CG (?)

18
BDII Globus MDS - Topologies
Flat Topology (scales up to at least 50 sites)
With regional fault tolerance (increases
scalability)
BDIIs can replace GIISs and GRISs (no more
dependency on globus MDS, but interoperates with
it)
BDII Acting as GRIS
19
CG Connections with Information Index
Roaming Access Server
Information Index
Legend
Scheduler
Planned Dependency
Dependency
Data Management
Workload Management
LB
LCG2
CG
GRAM
GridFTP
Optimisation Of Data Access
Globus
20
Glue Schema

• common conceptual data model
• to be used for grid resources monitoring and
  discovery
• part of DataTAG project http//www.cnaf.infn.it/
  sergio/datatag/glue/index.htm

21
Glue Schema- Example

• Grid Laboratory Universal Environment
• http//www.cnaf.infn.it/sergio/datatag/glue/index
  .htm

22
Glue Schema in LCG2

• Having a common schema is good
• The current schema has many problems
• Weakly defined
• Semantics not always clear
• Affects interoperation between US EU Grids
• Misuse of the schema
• Use cases not defines
• LCG people are working on some solutions ...
• This should be unified with CG monitoring tools !

23
Information vs Monitoring

• Information systems
• Shows what is there
• Mainly static information
• Well defined schema
• Monitoring systems
• Shows what is not there
• Time-stamped data
• Some concept of history
• Mainly dynamic information
• Dynamic schema required
• An overlapped grey area between the two

24
Monitoring in LCG, Grid ICE
Publishing Glue Monitoring Information
BDII
Publishing GlueService URI
Grid ICE
Cron
GRIS 2135
GRIS 2136
Apache Web Server
SQL
Fabric Monitoring
CE
25
LCG Monitoring

• Grid ICE
• Web interface to information in an SQL database.
• Uses MDS based system
• MDS is for information and not monitoring
• Keep information data size small
• Static schema
• New information cant be created by users
• LDAP to SQL?!
• LCG people are considering using of R-GMA
• Relational Grid Monitoring Architecture.
• Dynamic schema
• Well defined API

26
R-GMA
Producer Servlet
Producer API
Schema
Insert
SQL CREATE TABLE
SQL INSERT
Store location
Store table description
Registry
Execute or stream
Lookup location
Consumer Servlet
Consumer API
Query
SQL SELECT
Result Set
27
LCG Information Monitoring - Summary

• LCG is successfully using the BDII
• Is considering also use as the site GIIS and GRIS
• Use Generic information provider
• Can publish any information
• Just requires a template and dynamic plug-in
• Glue Schema need improvements
• Grid ICE
• Currently using MDS, is considered to benefit
  from R-GMA
• R-GMA
• Considered by LCG people be used for the
  monitoring infrastructure
• According to LCG people, can be used by the
  experiments for application level monitoring.

28
CG needs and infrastructure monitoring layers

• According to the requirements not all levels need
  to be present (i.e. for on-demand, on-line
  monitoring there is no need to store the data)
• Does CG need all levels? Probably
  no
• PPC, GridBench need to monitor on-line the
  specific resource
• Scheduler uses LCG RB that uses MDS (currently
  needs only static information)
• But planned to be used with dynamic information
  from postprocessing
• Santa-G information is published in R-GMA

29
CG Infrastructure Monitoring Data FlowFinal
Vision
Scheduler
Post Processing
Legend
RGMA
JIMS
DATA FLOW
Perform Predict
LCG2
Santa-G
GridBench
CG
infrastructure
30
Virtual Organisation Management

• a centralized LDAP database per VO
• stores the certificate subjects of all its
  members.
• used to build the list of the users to be
  authorized to use a certain grid resource
• maps certificates to local users
• mkgridmap procedure is used to generate local
  grid-mapfiles from the VO database.
• In LCG2 the VO servers are still based on the old
  LDAP VO software.
• VOMS is being considered.

31
Security

• when a request arrives for a job to run on a
  given computing resource, the user proxy
  presented is checked
• Local Centre Autorization System (LCAS) is then
  invoked to verify if the request can be accepted
  based on the local policy
• the Local Credential Mapping Service (LCMAPS) is
  then invoked to find out which pool of local
  accounts the subject of the user certificate is
  mapped to in the local grid-mapfile
• the user is mapped to one of the local accounts
  part of the pool.

32
Summary

• Basically, the LCG2 components are improved
  components from EDG/LCG1
• According to testbed people migration
  LCG1-gtLCG2 is easy and gives us more stable
  software
• CG software strongly depends on LCG workload
  management, data management and information
  service
• not sure how tasks (SA, RAS) will deal with
  migration (not much time left, but it seems there
  is not so much work as it was before )
• CG has its independent monitoring tools and does
  not depend on LCG monitoring, but
• compability is good idea-gt Glue schema
• info from SANTA-G is also published in R-GMA

33

• Special thanks to Jorge Gomes !