The EGEE Middleware Architecture · 2013. 4. 22. · GridKA School, 23September-2004 - 3...

GridKA School 23 September 2004

The EGEE Middleware Architecture

Leanne GuyEGEE Testing Manager

On behalf of JRA1

www.eu-egee.org

EGEE is a project funded by the European Union under contract INFSO-RI-508833

GridKA School, 23September-2004 - 2

Contents

• The gLite componentsArchitectural designApproach and strategyCurrent implementations

• Integration and testing Infrastructure and status

• From Prototype to ReleaseCurrent gLite status


Architecture Guiding Principles• Lightweight (existing) services

Easily and quickly deployableUse existing services where possible asbasis for re-engineering

• InteroperabilityAllow for multiple implementations

• Resilience and Fault Tolerance

• Co-existence with deployed infrastructureRun as an application (e.g. on LCG-2; Grid3)Reduce requirements on site components

• Basically globus and SRMCo-existence (and convergence) with LCG-2 and Grid3 are essential for the EGEE Grid service

• Service oriented approachWSRF still being standardizedNo mature WSRF implementations exist to date, no clear picture about the impact of WSRF hence: start with plain WS

• WSRF compliance is not an immediate goal, but we follow the WSRF evolution• WS-I compliance is important


gLite Services


WMS


CE

• Works in push and pull mode

• Site policy enforcementCEA … Computing Element Acceptance

JC … Job Controller

MON … Monitoring

LRMS … Local Resource Management System


Data Management

• Scheduled data transfers (like jobs)

• Reliable file transfer

•SRM based storage


Storage Element Interfaces

• SRM interfaceManagement and controlSRM (with possible evolution)

• Posix-like File I/OFile AccessOpen, read, writeNot real posix (like rfio)

SRM interface

rfio dcap chirp aio

Castor dCache NeST Disk

POSIXAPIFile I/O

Control

User


Catalogs

Metadata Catalog

LFN

Metadata

• File CatalogFile system-like view on logical file namesKeeps track of sites where data is stored

• Replica CatalogKeeps information at a site

• (Meta Data Catalog)Attributes of files on the logical levelBoundary between generic middleware and application layer

GUIDSite ID

Site IDFile Catalog

Replica Catalog Site A

GUID SURL

SURL

LFN

Replica Catalog Site B

GUID SURL

SURL

LFN


Information and Monitoring

• R-GMA forInformation system and system monitoringApplication Monitoring

• No major changes in architecture

But re-engineer and harden the system

• Co-existence and interoperability with other systems is a goal

E.g. MonaLisa

e.g: D0 application monitoring:

MP

P –

Mem

ory Prim

ary Producer

DbS

P–

Database S

econdary Producer

Job wrapper

MPP

DbSP

Job wrapper

MPP

Job wrapper

MPP


Security

PEP and PDP will in most cases be part of the secured service, rather than separated services


Approach

• Exploit experience and components from existing projects

AliEn, VDT, EDG, LCG, and others• Design team works out architecture

and designArchitecture: https://edms.cern.ch/document/476451Design: https://edms.cern.ch/document/487871/

• Components are initially deployed on a prototype infrastructureSmall scale (CERN & Univ. Wisconsin)Get user feedback on service semantics and interfaces

• After internal integration and testing components are delivered to SA1 and deployed on the pre-production service

EDGVDT . . .

LCG

EGEE

. . .AliEn


gLite and LCG-2

LCG-2focus on production, large-scale data handling

• The service for the 2004 data challenges

• Provides experience onoperating and managing a global grid service

• Development programme driven by data challenge experience

Data handlingStrengthening the infrastructureOperation, VO management

• Evolves to LCG-3 as components progressively replaced with new middleware

-- target is to minimise thediscontinuities of migrationto the new generation

• Aim for migration plan by end of year

gLitefocus on analysis

• Developed by EGEE project in collaboration with VDT (US)

• LHC applications and users closely involved in prototyping & development (ARDA project)

• Short development cycles

• Co-existence with LCG-2• Profit as far as possible from LCG-

2 infrastructure, experienceEase deployment – avoid separate hardware

• As far as possible - completed components integrated in LCG-2improved testing, easier displacement of LCG-2

LCG-2 (=EGEE-0)

prototyping

prototyping

product

20042004

20052005

LCG-3 EGEE-1

product

les robertson - cern-it-13

LCG


From Prototype to Release

• Prototype setup at 2 sites (CERN & Wisconsin)~45 users registered2nd release mid August

• Many bug fixes• New functionalities

More nodes (more powerful) being added at CERNBeing ported to SLC3 (by end of September)

Second VO being set up (core services at Wisconsin)• Will use globus RLS


Integration

• Continuous integration system is in placeCurrently running on RH Linux Enterprise 3.0134 gLite modules built continuously every 60 minutesAutomatic build failure notifications to developersAutomatic packaging of modules in three different formats (source tarballs, binary tarballs, RPMs)Complete nightly builds run every night at 03:30, all packaged deployed to the gLite web site. All builds are tagged for full reproducibilityCoding guidelines, unit test and coverage automatically run for all packages (Java only, C/C++/Perl on the way)

• SCM convergence being reachedSCM plan: https://edms.cern.ch/document/446241

• Common service configuration being worked out• Deployment scenarios being worked out

https://edms.cern.ch/document/446241


Build System


Testing

• Testing sites (RAL, NIKHEF, CERN) up and running24 Machines distributed across the three sites and growingMigrating to RHEL at all sites nowQuattor based automatic installation of testbed beginning at all sites

• Active testing of the prototype Automatic installation testing of rpms/tarballs from nightly buildActive testing of the gLite prototype

• 91 bugs submitted by test team to date• gLite IO, R-GMA and WMS currently primary focus

Testing effort focused on components for pre-production service• Test plan released

Based upon architecture document, release plan, and NA4 requirementshttps://edms.cern.ch/document/477697/

https://edms.cern.ch/document/477697/


Installation testing reports


Deployment considerations

• Interoperability and co-existenceExploit different service implementations

• E.g. Castor and dCache SRM implementationsRequire minimal support from development environment

• Sites required to run globus and SRM (might not be required for tactical storage)

Flexible service deployment• Multiple services running on the same physical machine (if possible)

• Platform supportGoal is to have portable middlewareBuilding & Integration on RHEL 3 and windowsInitial testing (at least 3 sites) using different Linux flavors (including free distributions)

• Service autonomyUser may talk to services directly or through other services (like access service)

• Open source software licenseBased on EDG license


Current Implementations

• WMSAliEn TaskQueueEDG WMS (plus new TaskQueue and Information Supermarket)EDG L&B

• CEGlobus GatekeeperCondorG (CondorC)“Pull component”

• AliEn CE• EGEE MON


Current Implementations Cont’d

• SEExternal SRM implementations

• dCache, Castor, …• LCG disk pool manager (tbi)

AliEn aio (re-factored to gLite-I/O)(

• CatalogsAliEn FileCatalogRLS (globus and EDG)Combined Catalog Interface (tbi)

• Data SchedulingStorkPhedex (concepts)Data mgmt interface and VO data scheduler (tbi)

• Data TransferGridFTP

• Metadata CatalogSimple interface definedAssumption that it will be managed by applications

• Information & MonitoringR-GMAFor application monitoring the aim is to plug in other systems as well.


Currents Implementations Cont’d

• SecurityVOMS as Attribute Authority and VO mgmtmyProxy as proxy storegridmapfile and GSI security as enforcement

• Plan is to move to more fine-grained authorization (e.g. ACLs)

• Plans with globus to provide a set-uid service on CE

• AccountingEDG HLR

• User InterfaceAliEn shellCLIs and APIs

• Move to autogenerated APIs from WSDL

GAS• New development

• Package managerExplore existing solutions


Summary

• Next generation middleware being designed and assembledPrototype first tangible outcome

• BUT this is a PROTOTYPE not a release!Architectural and design work well advanced

• Architecture document sent to EU– Subject to changes

• Design document (draft) exists: https://edms.cern.ch/document/487871/Incremental changes to prototype

• Feedback from applications and operations essential!• Detailed release plan worked out

https://edms.cern.ch/document/468699• First components for pre-production service during autumn• Continuous integration and testing scheme defined and adopted• Technology Risk

Will WS allow for all upcoming requirements? Divergence from standards




Links

• JRA1 homepagehttp://egee-jra1.web.cern.ch/egee-jra1/

• Architecture documenthttps://edms.cern.ch/document/476451/

• Release planhttps://edms.cern.ch/document/468699

• Prototype installationhttp://egee-jra1.web.cern.ch/egee-jra1/Prototype/testbed.htm

• Test planhttps://edms.cern.ch/document/473264/

• Design documenthttps://edms.cern.ch/document/487871/

http://egee-jra1.web.cern.ch/egee-jra1/

http://egee-jra1.web.cern.ch/egee-jra1/



http://egee-jra1.web.cern.ch/egee-jra1/Prototype/testbed.htm




gLite Web site

The EGEE Middleware Architecture · 2013. 4. 22. · GridKA School, 23September-2004 - 3...

Documents

Transcript of The EGEE Middleware Architecture · 2013. 4. 22. · GridKA School, 23September-2004 - 3...