The LHC Grid

1
The LHC Grid

• Norbert Podhorszki
• MTA SZTAKI

EGEE is funded by the European Union under
contract IST-2003-508833
2
Acknowledgement

• This tutorial is based on the work of many
  people
• Fabrizio Gagliardi, Flavia Donno and Peter Kunszt
  (CERN)
• the EDG developer team
• the EDG training team
• the NeSC training team
• the SZTAKI training team

3
What is LHC Grid?

• LHC stands for Large Hadron Collider to be built
  by CERN
• http//lhc-new-homepage.web.cern.ch/lhc-new-home
  page/
• The LHC will be put in operation in 2007 with
  many experiments collecting 5-6 PetaB data per
  year
• The LHC Grid was built by CERN in order to
  provide storage and computing capacity for the
  process of this huge data set
• The LHC Grid current version is called LCG-2
• It was built based on the sw developed by the
  European DataGrid project and by the Gryphin US
  project
• Now LCG-2 is the first EGEE infrastructure

4
What is LHC Grid?

• The first EGEE infrastructure - Largest
  functioning Grid
• more than 70 sites, over 5,000 CPUs, 4,000 TB
• 5,000 jobs simultaneously

5
What is EGEE ? (I)

• EGEE (Enabling Grids for Escience in Europe) is a
  seamless Grid infrastructure for the support of
  scientific research, which
• Integrates current national, regional and
  thematic Grid efforts, especially in HEP (High
  Energy Physics)
• Provides researchers in academia and industry
  with round-the-clock access to major computing
  resources, independent of geographic location

Applications
Grid infrastructure
Geant network
6
What is EGEE ? (II)

• 70 leading institutions in 27 countries,
  federated in regional Grids
• 32 M Euros EU funding (2004-5), O(100 M) total
  budget
• Aiming for a combined capacity of over 20000
  CPUs (the largest international Grid
  infrastructure ever assembled)
• 300 dedicated staff

7
EGEE Community
8
EGEE infrastructure

• Access to networking services provided by GEANT
  and the NRENs
• Production Service
• in place (based on HEP LCG-2)
• for production applications
• MUST run reliably, runs only proven stable,
  debugged middleware and services
• Will continue adding new sites in EGEE
  federations
• Pre-production Service
• For middleware re-engineering
• Certification and Training/Demo testbeds

9
What do we expect from the Grid?

• Access to a world-wide virtual computing
  laboratory with almost infinite resources
• Possibility to organize distributed scientific
  communities in VOs
• Transparent access to distributed data and easy
  workload management
• Easy to use application interfaces

10
The LCG-2 Architecture
Local Computing
Local Application
Local Database
Grid
Grid Application Layer
Data Management
Metadata Management
Job Management
Collective Services
Information Monitoring
Replica Manager
Grid Scheduler
Underlying Grid Services
Computing Element Services
Authorization Authentication Accounting
Replica Catalog
Storage Element Services
Logging Book-keeping
Database Services
Grid
Fabric services
Fabric
Node Installation Management
Monitoring and Fault Tolerance
Fabric Storage Management
Configuration Management
Resource Management
11
Main Logical Machine Types (Services) in LCG-2

• User Interface (UI)
• Information Service (IS)
• Computing Element (CE)
• Frontend Node
• Worker Nodes (WN)

• Storage Element (SE)
• Replica Catalog (RC,RLS)
• Resource Broker (RB)

12
User Interface

• The initial point of access to the LCG-2 Grid is
  the User Interface
• This is a machine where
• LCG users have a personal account
• The users certificate is installed
• The UI is the gateway to Grid services
• It provides a Command Line Interface to perform
  the following basic Grid operations
• list all the resources suitable to execute a
  given job
• replicate and copy files
• submit a job for execution on a Computing
  Element
• show the status of one or more submitted jobs.
• retrieve the output of one or more finished jobs
• cancel one or more jobs
• One or more UIs are available at each site part
  of the LCG-2 Grid

13
Main Logical Machine Types (Services) in LCG-2

• User Interface (UI)
• Information Service (IS)
• Computing Element (CE)
• Frontend Node
• Worker Nodes (WN)

• Storage Element (SE)
• Replica Catalog (RC,RLS)
• Resource Broker (RB)

14
Computing Element (CE)

• Defined as a Grid batch Queue and identified by a
  pair
• lthostnamegtltportgt/ltbatch queue namegt
• Several queues defined for the same hostname are
  considered different CEs. For example
• adc0015.cern.ch2119/jobmanager-lcgpbs-long
• adc0015.cern.ch2119/jobmanager-lcgpbs-short
• A Computing Element is built on a homogeneous
  farm of computing nodes (called Worker Nodes)
• One node acts as a Grid Gate (GG) or front-end to
  the Grid and runs
• a Globus gatekeeper
• the Globus GRAM (Globus Resource Allocation
  Manager)
• the master server of a Local Resource Management
  System that can be
• PBS, LSF or Condor
• a local Logging and Bookkeeping server
• Each LCG-2 site runs at least one CE and a farm
  of WNs behind it.

15
Computing Element

• Computing Element entry
• point into a queue of a batch
• system
• information associated with a computing element
  is limited only to information relevant to the
  queue
• Resource details relates to the system

infoService
gatekeeper
Batch server
Grid Gate node

CPUPIII RAM0.5GB OSLinux
CPUPIII RAM0.5GB OSLinux
CPUPIV RAM2GB OSLinux
CPUPIV RAM2GB OSLinux
in the example the red queue is assigned for two
hosts
16
Main Logical Machine Types (Services) in LCG-2

• User Interface (UI)
• Information Service (IS)
• Computing Element (CE)
• Frontend Node
• Worker Nodes (WN)

• Storage Element (SE)
• Replica Catalog (RC,RLS)
• Resource Broker (RB)

17
Storage Element (SE)

• A Storage Element (SE) provides uniform access
  and services to large storage spaces.
• Each site includes at least one SE
• They use two protocols
• GSIFTP for file transfer
• Remote File Input/Output (RFIO) for file access

18
Storage Resource Management (SRM)

• Data are stored on disk pool servers or Mass
  Storage Systems
• storage resource management needs to take into
  account
• Transparent access to files (migration to/from
  disk pool)
• Space reservation
• File status notification
• Life time management
• SRM (Storage Resource Manager) takes care of all
  these details
• SRM is a Grid Service that takes care of local
  storage interaction and provides a Grid interface
  to outside world

19
Storage Resource Management

• Support for local policy
• Each storage resource can be managed
  independently
• Internal priorities are not sacrificed by data
  movement between Grid agents
• Disk and tape resources are presented as a single
  element
• Reservation on demand and advance reservation
• Space can be reserved for registering a new file
• Plan the storage system usage
• File status and estimates for planning
• Provides info on file status
• Provide estimates on space availability/usage

20
A Simple Configuration
Computing Element 1
Storage Element 1
CLOSE
User Interface Resource Broker Replica
Catalog Information Service
CLOSE
Storage Element 2
Computing Element 2
21
SZTAKIs LCG-2 system

• LCG-2 local configuration

GRID GATE
n31.hpcc.sztaki.hu
(512MB, P4 2.53GHz)

• User Interface
• Computing Element
• Storage Element (69GB)
• Resource Broker
• ReplicaManager

n27.hpcc.sztaki.hu
n28.hpcc.sztaki.hu
Workernode 1
(128MB, Dual-PIII, 2x500MHz)
(128MB, Dual-PIII, 2x500MHz)
DefaultWorkernode2
22
Main Logical Machine Types (Services) in LCG-2

• User Interface (UI)
• Information Service (IS)
• Computing Element (CE)
• Frontend Node
• Worker Nodes (WN)

• Storage Element (SE)
• Replica Catalog (RC,RLS)
• Resource Broker (RB)

23
Information System (IS)

• The Information System (IS) provides information
  about the LCG-2 Grid resources and their status
• The current IS is based on LDAP (Lightweight
  Directory Access Protocol) a directory service
  infrastructure which is a specialized database
  optimized for
• reading,
• browsing and
• searching information.
• the LDAP schema used in LCG-2 implements the GLUE
  (Grid Laboratory for a Uniform Environment)
  Schema

24
How to store Information?

• The LDAP information model is based on entries.
• An entry usually describes an object such as a
• person,
• a computer,
• a server, and so on.
• Each entry contains one or more attributes that
  describe the entry.
• Each attribute has a type and one or more values.
  
• Each entry has a name called a Distinguished Name
  (DN) that uniquely identifies it.
• A DN is formed by a sequence of attributes and
  values.
• Example The DN of a particular CE entry would
  be
• an attribute identifying the site (site_IDcern)
  and
• an attribute identifying the CE
  (CE_IDlxn1102.cern.ch),
• so the complete DN would be CE_IDlxn1102.cern.ch
  ,site_IDcern.

25
The Directory Information Tree

• Based on their DNs, the entries can be arranged
  into a hierarchical tree-like structure.
• This tree of directory entries is called the
  Directory Information Tree (DIT).

26
Information System (IS)

• The IS is a hierarchical system with 3 levels
  from bottom up
• GRIS (Grid Resource Information Servers) level
  (CE and SE level)
• Grid Index Information Server (GIIS) level (site
  level)
• Top, centralized level (Grid level)
• the Globus Monitoring and Discovery Service (MDS)
  mechanism has been adopted at the GRIS level
• The other two levels use the Berkeley DB
  Information Index (BDII) mechanism

27
LCG-2 hierarchical Info system
BDII Berkley DB Information Index GIIS Grid
Index Information Server GRIS Grid Resource
Information Server CE Computing
Element SE Storage Element
28
How to collect and store information?

• All services are allowed to enter information
  into the IS
• The BDII at the top
• queries every GIIS in every 2 min and
• acts as a cache storing information about the
  Grid status in its LDAP database
• The BDII at the GIIS
• collects info from every GRIS in every 2 min and
• acts as a cache storing information about the
  site status in its LDAP database
• The GRIS updates information according to the MDS
  protocol

29
How to obtain Information?

• All users can browse the catalogues
• To obtain the information the client should
• Ask BDII about possible GIIS/GRIS
• Directly query GIIS/GRIS
• Or use BDII cache
• The IS scales to 1000 sites (MDS much less
  100)

30
Main Logical Machine Types (Services) in LCG-2

• User Interface (UI)
• Information Service (IS)
• Computing Element (CE)
• Frontend Node
• Worker Nodes (WN)

• Storage Element (SE)
• Replica Catalog (RC,RLS)
• Resource Broker (RB)

31
Data Management

• The Data Management services are provided by
• the Replica Management System (RMS) of EDG
• and the LCG Data Management client tools
• In LCG, the data files are replicated
• on a temporary basis,
• to many different sites depending on
• where the data is needed.
• The users or applications do not need to know
  where the data is located, they use logical files
  names
• the Data Management services are responsible for
  locating and accessing the data.

32
File Management Motivation
Replica Manageratomic replication
operationsingle client interfaceorchestrator
Replica Catalog Map Logical to Site files
Replica Selection Get best file
Security
Pre- Post-processing Prepare files for
transfer Validate files after transfer
Replication Automation Data Source subscription
Site A
Site B
Load balancing Replicate based on usage
Metadata LFN metadata Transaction
information Access patterns
Storage Element A
Storage Element B
File Transfer
File A
File X
File A
File C
File B
File Y
File B
File D
33
Data Management Tools

• Tools for
• Locating data
• Copying data
• Managing and replicating data
• Meta Data management
• In LCG-2 you have
• Replica Manager (RM)
• Replica Location Service (RLS)
• Replica Metadata Catalog (RMC)

RM
RLS
RMC
34
Replication Services Basic Functionality
Each file has a unique Grid ID. Locations
corresponding to the GUID are kept in the Replica
Location Service.
Users may assign aliases to the GUIDs. These are
kept in the Replica Metadata Catalog.
Files have replicas stored at many Grid sites on
Storage Elements.
Replica Metadata Catalog
Replica Location Service
Replica Manager
The Replica Manager provides atomicity for file
operations, assuring consistency of SE and
catalog contents.
Storage Element
Storage Element
35
Interactions with other Grid components
Virtual Organization Membership Service
User Interface or Worker Node
Resource Broker
Applications and users interface to data through
the Replica Manager either directly or through
the Resource Broker. Management calls should
never go directly to the SRM.
Information Service
Replica Metadata Catalog
Replica Location Service
Replica Manager
Storage Element
Storage Element
36
Simplified Interaction Replica Manager
Storage Resource Manager
Replica Catalog
Replica Manager client
SRM
Storage

• The Client asks a catalog to provide the location
  of a file
• The catalog responds with the name of an SRM
• The client asks the SRM for the file
• The SRM asks the storage system to provide the
  file
• The storage system sends the file to the client
  through the SRM or
• directly

37
Replica Manager (RM)

• High level data management on the Grid, takes
  care of
• Location of data
• Replication of data
• Efficient access to data
• Hides the SRM (Storage Resource Manager)
• User cannot access directly the SRM, only through
  the RM
• Coordinates the use of
• Replica Location Service
• Replica Metadata Catalog

38
Interaction of the Replica Manager (RM) with
other Grid services

• The RM presents a single interface to the user or
  other services
• Some of the RM functionalities have been replaced
  by a new, faster interface the LCG Data
  Management client tools.

39
File References and Replica Catalogs

• The files in the Grid are referenced by different
  names
• Grid Unique IDentifier (GUID)
• Logical File Name (LFN)
• Storage URL (SURL)
• Transport URL (TURL).
• the GUID or LFN refer to files and not replicas,
  and say nothing about locations
• the SURLs and TURLs give information about where
  a physical replica is located.

RMC Replica Metadata Catalog
LRC Local Replica Catalog
40
Abstract file names

• GUID
• A file can always be identified by its GUID
• GUID is assigned at data registration time
• GUID is based on the UUID standard to guarantee
  unique IDs
• A GUID is of the form guidltunique stringgt
• All the replicas of a file will share the same
  GUID
• LFN
• In order to locate a Grid accessible file, the
  human user will normally use a LFN
• LFNs are human-readable strings, they are
  allocated by the user as GUID aliases
• LFNs form is lfnltany aliasgt

41
Physical file names

• SURL
• used by the RMS to find where a replica is
  physically stored and by the SE to locate the
  file
• SURLs are of the form sfnltSE hostnamegt/ltlocal
  stringgt
• where ltlocal stringgt is used internally by the SE
  to locate the file.
• TURL
• TURL gives the necessary information to retrieve
  a physical replica, including
• hostname
• path
• protocol
• port (as any conventional URL)

42
Replica Location Service (RLS)

• RLS maintains information about the physical
  location of the replicas (mapping with the
  GUIDs).
• It is composed of several Local Replica Catalogs
  (LRCs) which hold the information of replicas for
  a single VO.

43
Replica Metadata Catalog (RMC)

• The RMC stores the mapping between GUIDs and the
  respective aliases (LFNs)
• Maintains other metada information (sizes, dates,
  ownerships. . . )

44
User Interfaces for Data Management

• Users are mainly referred to use the interface of
  the Replica Manager client
• Management commands
• Catalog commands
• File Transfer commands
• The services RLS and RMC provide additional user
  interfaces
• Mainly for additional catalog operations
• Additional server administration commands
• Should mainly be used by administrators
• Can also be used to check the availability of a
  service

RM
RLS
RMC
45
Main Logical Machine Types (Services) in LCG-2

• User Interface (UI)
• Information Service (IS)
• Computing Element (CE)
• Frontend Node
• Worker Nodes (WN)

• Storage Element (SE)
• Replica Catalog (RC,RLS)
• Resource Broker (RB)

46
Job Management

• The user interacts with Grid via a Workload
  Management System (WMS)
• The Goal of WMS is the distributed scheduling
  and resource management in a Grid environment.
• What does it allow Grid users to do?
• To submit their jobs
• To execute them on the best resources
• The WMS tries to optimize the usage of resources
• To get information about their status
• To retrieve their output

47
WMS Components

• WMS is currently composed of the following parts
• Workload Manager, which is the core component of
  the system
• Match-Maker (also called Resource Broker), whose
  duty is finding 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), which finally performs
  the actual job management operations (job
  submission, removal. . .)
• Logging and Bookkeeping services (LB) store Job
  Info available for users to query

48
Job PreparationLets think the way the Grid
thinks!

• Information to be specified
• Job characteristics
• Requirements and Preferences of the computing
  system
• including software dependencies
• Job Data requirements
• Specified using a Job Description Language (JDL)

49
Job Submission
50
Job Submission
Job Status
51
Job Submission
Job Status
52
Job Submission
Job Status
53
Job Submission
Job Status
54
Job Submission
Job Status
55
Job Submission
Job Status
56
Job Submission
Job Status
57
Job Submission
Job Status
58
Job Submission
Job Status
59
Job Submission
Job Status
60
Job Submission
Job Status
61
Job Submission
Job Status
62
Job Submission
Job Status
63
Job Submission
Job Status
64
Job Submission
Job Status
65
Job monitoring
66
Possible job states
67
Job Flow Status and Errors

• Status queries from the UI machine
• job status queries are addressed to the LB
  database.
• Resource status queries are addressed to the BDII
  
• If the site where the job is being run falls
  down, the job will be automatically resent to
  another CE that is analogue to the previous one,
  w.r.t. requirements the user asked for.
• In the case that this new submission is disabled,
  the job will be marked as aborted.
• Users can get information about what happened by
  simply questioning the LB service.

68
Security
69
Introduction to Security

• What aspects of security should we be concerned
  about?
• Authentication (Identification)
• Confidentiality (Privacy)
• Integrity (non-Tampering)
• Authorisation
• Also
• Accounting
• Delegation
• Non-Repudiation

70
How do I login on the Grid ?

• Distribution of resources secure access is a
  basic requirement
• secure communication
• security across organisational boundaries
• single sign-on" for users of the Grid
• Two basic concepts
• Authentication Who am I?
• Equivalent to a pass port, ID card etc.
• Authorisation What can I do?
• Certain permissions, duties etc.

71
Security in the Grid

• In industry, several security standards exist
• Public Key Infrastructure (PKI)
• PKI keys
• SPKI keys (focus on authorisation rather than
  certificates)
• RSA
• Secure Socket Layer (SSL)
• SSH keys
• Kerberos
• Need for a common security standard for Grid
  services
• Above standards do not meet all Grid requirements
  (e.g. delegation, single sign-on etc.)
• Grid community mainly uses X.509 PKI for the
  Internet
• Well established and widely used (also for www,
  e-mail, etc.)

72
Encrypting for Confidentiality

• Sending a message using asymmetric keys
• Encrypt message using Receivers public key
• Send encrypted message
• Receiver decrypts message using own private key
• Only someone with Receivers private key can
  decrypt message

Receiver space
Public space
Sender space
Private Key
Public Key
Receivers Public Key
Receivers Public Key
3
hR3a rearj
hR3a rearj
openssl
openssl
2
hR3a rearj
1
Hello World
Hello World
73
Signing for Authentication

• Encrypt message with Senders private key
• Send encrypted message
• Message is readable by ANYONE with Senders
  public key
• Receiver decrypts message with Senders public
  key
• Receiver can be confident that only someone with
  Senders private key
• could have sent the message

Public space
Sender space
Receiver space
Senders Public Key
Senders Public Key
Public Key
Private Key
3
openssl
1
openssl
n52krj rer
n52krj rer
openssl
Hello World
4
2
n52krj rer
Hello World
Hello World
74
The Full Monty

• Server authenticates Client
• Client authenticates Server
• (Symmetric) Session key exchanged confidentially
  using public key mechanism
• Secure session can now commence using more
  efficient, agreed session key
• Secure messages will also contain a message
  digest to ensure integrity

75
Digital Certificates

• How can B be sure that As public key is really
  As public key and not someone elses?
• A third party guarantees the correspondence
  between public key and owners identity, by
  signing a document which contains the owners
  identity and his public key (Digital Certificate)
• Both A and B must trust this third party
• Two models
• X.509 hierarchical organization
• PGP web of trust.

76
Certificate contents

• The certificate that you present to others
  contains
• Your distinguished name (DN)
• your identifier
• Your public key
• anyone can send a secret message to you
• The identity of the CA who issued the certificate
• just a name
• Its expiry date
• the certificates expiry date (usually issued for
  one year)
• Digital signature of the CA which issued it
• the certificate encrypted with the CAs private
  key

77
Involved entities
Certificate Authority
User
Public key Private key certificate
Resource (site offering services)
78
Certificate Request
User send public key to CA along with proof of
identity.
User generatespublic/privatekey pair.
CA confirms identity, signs certificate and sends
back to user.
Cert
Signed public key.
Private Key encrypted on local disk
79
X.509 certificates and authentication
B
A
A
As certificate
Verify CA signature
Random phrase
Encrypt with A s private key
Encrypted phrase
Decrypt with A s public key
Compare with original phrase
80
Certificate classification

• User certificate
• issued to a physical person
• DN CCH, OCERN, OUGRID, CN John Smith
• the only kind of certificate good for a client,
  i.e. to send Grid jobs etc.
• Host certificate
• issued to a machine (i.e. a secure web server,
  etc.)
• request signed with a user certificate
• DN CCH, OCERN, OUGRID, CNhost1.cern.ch
• Grid host certificate
• issued to a Grid service (i.e. a Resource Broker,
  a Computing Element, etc.)
• request signed with a user certificate
• DN CCH, OCERN, OUGRID, CNhost/host1.cern.ch
• Service certificate
• issued to a program running on a machine
• request signed with a user certificate
• DN CCH, OCERN, OUGRID, CNldap/host1.cern.ch

81
Grid Security Infrastructure (GSI)

• Globus ToolkitTM proposed and implements the Grid
  Security Infrastructure (GSI)
• Protocols and APIs to address Grid security needs
• GSI protocols extend standard public key
  protocols
• Standards X.509 SSL/TLS
• Extensions X.509 Proxy Certificates (single
  sign-on) Delegation
• Proxy Certificate
• Short term, restricted certificate that is
  derived form a long-term X.509 certificate
• Signed by the normal end entity cert, or by
  another proxy
• Allows a process to act on behalf of a user
• Not encrypted and thus needs to be securely
  managed by file system

82
Delegation

• Proxy creation can be recursive
• each time a new private key and new X.509 proxy
  certificate, signed by the original key
• Allows remote process to act on behalf of the
  user
• Avoids sending passwords or private keys across
  the network
• The proxy may be a Restricted Proxy a proxy
  with a reduced set of privileges (e.g. cannot
  submit jobs).

83
Virtual Organisations
84
Virtual organisations

• An EGEE user must belong to a VO
• A VO
• Sets of users belonging to a collaboration
• Usually comprises geographically distributed
  people
• Controls access to specified CE, SE
• Requires the ability to know who has done what,
  and who will not be allowed to do it again.
  Security.
• Each VO user has the same access privileges to
  Grid resources
• List of supported VOs
• https//lcg-registrar.cern.ch/virtual_organization
  .html
• HEP communities (atlas, cms, etc.), biology,
  astronomy
• HunGrid

85
Virtual Organizations and authorization

• VOs maintain a list of their members
• The list is downloaded by Grid machines to map
  user certificate subjects to local pool
  accounts only mapped users are authorized in LCG
• Sites decide which VOs to accept

... "/CCH/OCERN/OUGRID/CNSimone Campana 7461"
.dteam "/CCH/OCERN/OUGRID/CNAndrea Sciaba
8968" .cms "/CCH/OCERN/OUGRID/CNPatricia
Mendez Lorenzo-ALICE" .alice ...
grid-mapfile
86
VOMS, LCAS, LCMAPS

• Virtual Organization Membership Service
• Extends the proxy info with VO membership, group,
  role and capabilities
• Local Centre Authorization Service (LCAS)
• Checks if the user is authorized (currently using
  the grid-mapfile)
• Checks if the user is banned at the site
• Checks if at that time the site accepts jobs
• Local Credential Mapping Service (LCMAPS)
• Maps grid credentials to local credentials (eg.
  UNIX uid/gid, AFS tokens, etc.)
• Currently uses the grid-mapfile (based only on
  certificate subject)
• In the near future will map also VOMS group and
  roles

"/VOcms/GROUP/cms"
.cms "/VOcms/GROUP/cms/prod"
.cmsprod "/VOcms/GROUP/cms/prod/ROLEmanager"
.cmsprodman
87
Virtual organisations

• EGEE has a formal procedure for adding selected
  new user communities (Virtual Organisations)
• Negotiation with one of the Regional Operations
  Centres
• Seek balance between the resources contributed by
  a VO and those that they consume.
• Resource allocation will be made at the VO level.
  
• Many resources need to be available to multiple
  VOs shared use of resources is fundamental to a
  Grid

88
EGEE Pilot Applications (I)

• High Energy Physics
• Have been running large distributed computing
  systems for many years
• Now focus on computing for LHC ? hence LCG (LHC
  computing grid project)
• several current HEP experiments use grid
  technology (Babar,CDF, etc.)
• LHC experiments are currently executing large
  scale data challenges

89
EGEE Pilot Applications (II)

• Biomedics
• Bioinformatics (gene/proteome databases
  distributions)
• Medical applications (screening, epidemiology,
  image databases distribution, etc.)
• Interactive application (human supervision or
  simulation)
• BioMed applications deployed and expect to run
  first job on LCG-2 by September

90
EGEE Applications (III)

• BLAST comparing DNA or protein sequences
• BLAST is the first step for analysing new
  sequences to compare DNA or protein sequences to
  other ones stored in personal or public
  databases. Ideal as a grid application.

• Requires resources to store databases and run
  algorithms
• Can compare one or several sequence against a
  database in parallel
• Large user community

91
Who else will benefit from EGEE?

• EGEE Generic Applications Advisory Panel
• 4 applications presented
• 3 applications (comp. chemistry, earth science,
  astro-particle) recommended for deployment with
  allocation of NA4 resources
• EU projects GRACE, Mammogrid and Diligent asking
  for support
• Expression of interest Planck/Gaia
  (astroparticle), SimDat (drug discovery)

92
How to access EGEE (I)

• 0) Review information provided on the EGEE
  website
• www.eu-egee.org
• Establish contact with the EGEE applications
  group lead by
• Vincent Breton (breton_at_clermont.in2p3.fr)
• 2) Provide information by completing a
  questionnaire describing your application
• 3) Applications selected based on
• scientific criteria,
• Grid added value,
• effort involved in deployment,
• resources consumed/contributed etc.

93
How to access EGEE (II)

• 4) Follow a training session
• 5) Migrate application to EGEE infrastructure
  with the support of EGEE technical experts
• 6) Initial deployment for testing purposes
• 7) Production usage (contribute computing
  resources for heavy production demands)

94
SZTAKIs role in EGEE

• Education Centre of the Central European Region
• Developing and providing various training courses
• Provide user support for applications
• See the web page www.lpds.sztaki.hu/egee
• Leader of middleware deployment effort in the
  SEEGRID project
• Creating a regional EGEE Grid for South-East
  Europe
• Promote the establishment of the Hungarian EGEE
  Grid together with other members of MGKK
• Creating a national EGEE Grid for Hungary
  (HunGrid VO)
• Extend the EGEE Grid with new layers
• Mercury monitor www.lpds.sztaki.hu/mercury
• P-GRADE portal www.lpds.sztaki.hu/pgportal

95
Conclusions

• EGEE is the first attempt to build a worldwide
  Grid infrastructure for data intensive
  applications from many scientific domains
• A large-scale production grid service, LCG-2 is
  already deployed and being used for HEP and
  BioMed applications
• Resources and user groups will rapidly expand
  during the course of the project
• A process has been established for migrating new
  applications to the EGEE infrastructure
• A training programme has been established with a
  number of events already held
• Prototype next generation grid middleware is
  being tested now
• See the on-line broker demo at
  http//www.hep.ph.ic.ac.uk/mp801/applet/

96
GRID'2005 EGEE Summer School

• Budapest
• July 11-16, 2005
• http//www.egee.hu/grid05
• Registration deadline May 1, 2005
• Venue MTA SZTAKI, Victor Hugo building,

97
GRID'2005 EGEE Summer School

• Lessons and hands-on tutorials every day
• EGEE
• Job execution
• Data management
• Information system
• Security
• Virtual organisations
• Large scale simulations on the EGEE Grid
• Gilda training testbed and Genius portal
• Workflow application development
• Parallel program development with P-GRADE portal
• gLite new middleware, based on web services