PoS(EGICF12-EMITC2)074 http://pos.sissa.it/ ∗ [email protected] [email protected] [email protected] [email protected] [email protected] Speaker. Information system is the backbonewas of one any of kind the first of middlewares a thatarchitecture. came distributed with Grid This a system. reliable solution, and initially NorduGrid comprehensive informationused ARC inspired system as by a an distributed LDAP-based dynamic approachinfrastructures database of for for Globus, many Grid has years. resource been This discoveryderlying paper and technology gives monitoring an and in overview features. of research thecustom Although information system the schema, architecture, the original the standard ARC GLUE2 un- model information isdevelopers being system now. broadly came endorsed ARC by with middleware contributed a toment the it, GLUE2 as development, described and in is this paper.harmonization among Ongoing of the new otherwise first developments different targeting to Grid further information imple- convergence systems and is also discussed. ∗ Copyright owned by the author(s) under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike Licence. c
EGI Community Forum 2012 / EMI26-30 Second March, Technical 2012 Conference Munich, Germany Anders Wäänänen Copenhagen University E-mail: Oxana Smirnova Lund University E-mail: Mattias Ellert Uppsala University E-mail: Balázs Kónya Lund University E-mail: Florido PAGANELLI Lund University E-mail: The ARC Information System: overviewcompliant of production a system GLUE2 PoS(EGICF12-EMITC2)074 , ]. 16 gives ARIS 4 ] identified similar- shows some of the Florido PAGANELLI 1 6 ] and UNICORE [ 3 reg CIP Unicore Unicore Registry ], ARC [ Local/Resource 15 Courtesy of Laurence Field Laurence of Courtesy level, but the transfer methods differ. presents an overview of the existing solutions, reg 2 2 ARIS ARC EGIIS contains experiences on early GLUE2 adoption, and LIB 7 ARC pull Local/Resource gives a deeper technical insight, Section index or registry or cache 5 pull pull top site gLite BDII BDII BDII level to the resource LCG pull Clients Local/Resource ] features a lightweight push model, where the local information system called 3 underlines ARC Information System key concepts and technologies, Section The gLite information system (left) features a pull model, where the information is pulled by gives a summary. highlights the three different information flow models. The information always flows from 3 8 1 ARC [ An analysis conducted mainly by Laurence Field within the EMI project [ The paper is organised as follows: Section local or resource upper levels from the level below.level Unicore registers and to ARC a (center registry. and right) feature a push model where the local ARC Resource Information System, sits locallyby on only a sending Computing a Element small or amount resource of and information registers to an index. Figure 1: a technology overview, Section upcoming integration challenges, Section Figure 2. Existing Solutions and Motivation the Section The ARC Information System: overview of a GLUE2 compliant production system 1. Overview Section ities and differences between the information systems of gLite [ PoS(EGICF12-EMITC2)074 refers to Yes Not really Federated Kind of Not really Florido PAGANELLI Pull Pull Transport Model Pull Pull Transport Model to query the custom NorduGrid ]. To ease the introduction of such Courtesy of Laurence Field Laurence of Courtesy 13 BDII Global Cache BDII (Top) No No arclib LDIF Data Model LDIF LDIF XML 3 GLUE GLUE 2.0 Information Model 1.3GLUE NorduGrid Schema 2.0GLUE ]. 2 EMIR Registry Registry DB GOC (Not EMI) EGIIS Unicore ERIS Service Level BDII (resource) ARIS CIP ], Enhanced Grid Information Indexing Service. ARC distributes a collection of 4 [ shows a comparison of the different features for each middleware and the main EMI 1 EMI Unicore gLite ARC Stack Features of the information systems within the EMI project. Here, EGIIS Grid information systems are currently in a process of transition, converging to a common A key concept in ARC is that clients perform resource discovery, matchmaking and moni- Client and other tools can then use the ARC library Table information system that will make use of the GLUE2 model [ toring. ARC own clientssubmitted, always and relied to get on Computing the Elementsple usage information information information; system with system the to interfaces approach on choose of theand where offering Computing monitor multi- a Element resources (CE), job of clients a can will cluster be be with ARC able CE to in discover several ways, which has the following benefits: the way information consumer orwhole. a client is supposed to get information from the information system as a 2.1 Motivation for a more versatile ARIS a model and preserve backwardsbe compatibility able with to existing interact with models, information ARISimplements system has components federation been from of other resources enhanced middlewares. across to In differentalways this domains been way, and ARC one different of technologies, the which main has drives for Grid computing. Table 1: index federated index prototype (EMIR) [ The ARC Information System: overview of a GLUE2 compliant production system client utilities that are able to perform such queries. PoS(EGICF12-EMITC2)074 . to reach resource Florido PAGANELLI , which is where the . Therefore, most of does not cache resource level informa- minimum information needed local or resource level as up to date as possible 4 speaking all the possible information system “dialects“ different models present different kind of information and fea- ARIS uses well-known standardised interfaces. Information must be ARIS is capable of The index level must contain the As information must be fresh, ARC index if one of the information system interfaces is down, it is possible to try another; more- in the index level. Instead of index level caching, information at the local level is pe- . A basic resource discovery algorithm is as follows: rectly; This is achieved by supporting threeGLUE2), information models two (NorduGrid/ARC, GLUE2 Glue1.2/1.3 renderings and (LDIFWSRF, extended and BES XML) and EMI-ES). and multiple server protocols (LDAP, riodically refreshed, and only thesent minimum to information the on index. how to contact the local level is tion the local levels of interest.resource level ARC information systems. index can be viewed as a collection of URLs pointing at information originates. over, clients not supporting an interface can find one that fulfill their needs; tures. the ARC information must be consumed on the The action of collecting information about services a client wants to use is called ARC Information System is a collection of custom crafted tools and several off-the-shelf prod- The whole information system consists of the following: As a consequence of these principles, clients or consumers willing to retrieve information must ARC information system is based on four key concepts: 1. Client contacts index level and retrieves a2. list ofFor local information each system URL, URLs; the client contacts the local information system accessible by that URL di- After a successful resource discovery, usingservice all to the contact, information depending gathered, on the its needs. client decides which 4. Technologies overview ucts available on the Open Source market. always end up contacting a local information system. discovery Multiple interfaces. No caching. Lightweight index. Freshness of information. The ARC Information System: overview of a GLUE2 compliant production system Reliability: Fine-grained resource discovery: Ease of coding new clients: 3. ARC Information System Key Concepts PoS(EGICF12-EMITC2)074 ). Registra- ]. 4 [ Florido PAGANELLI EGIIS bdii-update ] publishing LDAP informa- 5 [ . 2 OpenLDAP ], capable of collecting information at the local ]. 7 [ 2 5 infoproviders ] to serve local information and perform RESTful registration. is meaningful: amount of information exchanged between ARIS 6 shows how it interacts with existing caching technologies (BDII- 2 )[ 3 that implements both local and index level. It consists of the custom – the ] and a custom LDAP-based index server called based on the custom Web Service container HED (Hosting Environ- 4 [ arched It also consists of the Open Source LDAP server level and produce representations in the form of XML or LDIF documents. NorduGrid schema tion, and of a collection oftion Open to Source an Berkeley DB EGIIS update index scripts is ( achieved via custom scripts. ment Daemon or ]) and the upcoming EMI Registry EMIR [ One of the purposes of ARIS is to easily connect and share information with multiple indexing The orange band shows the ARC ecosystem, consisting only of ARC components. The blue In the case of gLite, a pull model is used to gather information from an ARIS instance. Basi- ARC information system architecture is shown in Figure The two interfaces (LDAP and Web Service based) can live together but it is not mandatory to The lower level represents the local or resource level,ARIS where registers to ARIS a operates. known EGIIS by In sending a small complete amount of information,Then, performing simple a client requesting information from any EGIIS mustThe perform client will a then custom contact the LDAP local query endpoints directly using standard LDAP protocol queries Width of arrows in Figure 8 and caching systems. Figure band shows those software products thatEMIR. don’t belong to ARC, such as gLite BDII-top and EMI’s cally, BDII-top will have a listBy of querying URLs directly to the contact ARIS the local various informationusing LDAP system, standard servers it for will LDAP pull different searches. all services. the Thetransferred data thick needed between arrow for ARIS here caching, and shows that BDII-top.thick a as Note large amount well, that of the because information arrow BDII-topfetched. is between is a a client cache and and a contains BDII-top a is lot of information that can be directly and EGIIS and between clients and EGIIScarries is most quite of small, the while exchange available between information, clients hence and the ARIS thicker arrow. 4.2 ARC information system “speaking” other “dialects” top [ A collection of Perl scripts have both enabled. ARIS is fully functional even if just4.1 one of ARC them information is system running. “speaking” only the ARC “dialect” ARC environment, various instances of EGIIS are organized as an hierarchy of index-level services. standard LDAP operations. that will return a collection of EGIIS or ARIS endpoints/URLs. to gather further information about local resources,servers. or perform other custom queries to other EGIIS The ARC Information System: overview of a GLUE2 compliant production system A customized LDAP setup A Web Services interface PoS(EGICF12-EMITC2)074 . 5.3 , and they usually Florido PAGANELLI is ARC’s own Open arched arched . 4 6 ARC information system "speaking" only the ARC "dialect". Figure 2: In the case of EMIR, the registry is meant to contain minimal static GLUE2 endpoint infor- In this section we will describe in more detail ARISThe components, process supported of schema communicating and to ren- different index levels is explained in Section In what follows, we describe ARIS internals shown in Figure mation. The communication protocolis towards EMIR capable is of a contacting RESTful EMIRservices Web and and Service sending endpoints. interface. a Note small ARIS that,the amount as client in of gets from the information EMIR case regarding is of itsElement the ARC minimal where GLUE2 index information ARIS EGIIS, necessary is to the running. access amount services of on information a Computing 5. Technologies: a detailed look derings, and the algorithm with which information is generated and served. 5.1 Components Source Web Service container. Writtenwith in different C++, purposes. it is Job extensibleallow and submission information allows interfaces system running are requests. Web Services service, served A-REX, through exposes the three ARC interfaces:Service). computing WSRF, element XBES While and (eXtended WSRF job BES)EMI-ES is management and are basically well EMI-ES defined used (EMI interfaces to that Execution information feature obtain is information generated an system from XML retrieval an functionality. XML information All document. this document, XBES and The ARC Information System: overview of a GLUE2 compliant production system PoS(EGICF12-EMITC2)074 ]) in . ] and 2 11 [ 12 arc.conf Florido PAGANELLI ]. Such information is 9 ], Glue 1.2/1.3 [ 4 server. , a Python script, takes care of slapd bdii-update ) configure all the subsystems and the start 7 grid-infosys ARIS "speaking" other "dialects" and ] operations. a-rex Figure 3: 10 are set of Perl scripts, developed by the ARC team, that can generate XML daemon manages and serves information contained in Berkeley databases. LDAP , these are configured in one single central configuration file ( ]. In particular, GLUE2 is rendered in both XML and LDIF, while NorduGrid and slapd 13 infoproviders . The The Another Open Source external component called The two startup scripts ( LDAP information is served via the Open Source LDAP server OpenLDAP and its daemon bdii-update and LDIF documents needed bydocuments the is former shaped two subsystems. according The to information three contained main in schemas: these NorduGrid [ gathering LDIF files representing databaseperform data, add, delete and and merges update them LDAP in operations against an the efficient way in order to GLUE2 [ such a way that configurationindependent and from startup their of canonical these systemrun services an setup. LDAP when server This working or means together atheir BDII that with distribution-based system an ARC configuration. together organisation is with ARC can anitself. will ARC seamlessly CE configure without and changing run a special single instances line of of those for Glue 1.2/1.3 only come ascan, LDIF. at All the same these time, can publish be all the published combinations together. of schemas A and fully protocols enabled listed ARC in Table CE updated by LDAP protocol [ them. It is important toand note that even if ARC uses off-the-shelf components such as OpenLDAP slapd information is described in terms of LDIF trees or LDIF documents [ The ARC Information System: overview of a GLUE2 compliant production system PoS(EGICF12-EMITC2)074 daemon and the Florido PAGANELLI slapd daemon. arched Protocol LDAP LDAP LDAP WSRF XBES EMI-ES . ) 8 2 infoproviders GLUE2 GLUE2 GLUE2-based GLUE2-based Schema NorduGrid Glue 1.3 , ARIS can talk to different index level information systems. 4.2 scripts use the LDIF generator scripts to update information served by startup script configures and starts the OpenLDAP script, then starts the whole LDAP subsystem. generate an XML document and a set of scripts able to generate LDIF trees, takes the XML document and wraps it to serve GLUE2 information over all the startup script configures and starts the . bdii-update shows which interface is responsible for communication to different index technolo- periodically executes the shows the components involved in the process. 5 4 bdii-update arched supported Web Service based protocols (WSRF, XBES and EMI-ES) slapd a-rex grid-infosys infoproviders The ARIS schemas and protocols they can be queried with. GLUE2-based means that the protocol (a) (a) (b) the (b) arched compliant to different schemas (see Table Figure This is achieved by the different subsystems enforcing the technologies the index level sup- As mentioned in Section Figure The high-level algorithm with which the components interact is as follows: 2. 3. the 4. Concurrently, 1. Concurrently, ports. gies, the reader is referred to it while reading the description below. 5.3 Connection to the Index level Table 2: might change the GLUE2 data structure according to the protocol needs. 5.2 High-Level Algorithm The ARC Information System: overview of a GLUE2 compliant production system PoS(EGICF12-EMITC2)074 , arched grid-infosys daemon to get Florido PAGANELLI slapd Starts A-REX Stand-alone Infoproviders requests to an index where Infoproviders LDIF ldapadd . 6 startup script. BDII XML and BDII. BDII represents the Berkeley DB update 9 slapd Startup Script Startup Configuration grid-infosys SLAPD arched LDAP Configuration and Configuration LDAP WS The orange container surrounds the ARC components. The LDAP WSRF EMIES XBES (A-REX BES) (A-REX Details of this mechanism will be described in Section Registration is actually performed by a set of utilities that run from time to time. The time ARC index EGIIS is a custom LDAP server using the Globus-MDS based registration schema. EGIIS was designed to be a lightweight index, so the registration record contains minimal The BDII-top pull model expects an LDAP server serving informationFor according this to kind the of Glue caching to work, the BDII-top must know the ARC LDAP server’s endpoint Figure 4: ARIS components. the chunks of LDAP trees needed. interval can be defined by the system administrator. These scripts are independent from The ARC Information System: overview of a GLUE2 compliant production system startup script provides configuration files for the cluster is authorised. Registration of a cluster to EGIIS is achieved by sending simple amount of information needed to reach the local resource level. 5.3.2 Caching information on a BDII-top 1.3 or GLUE2 schema. ARIS features an LDAP server capable ofURL. providing such The information. BDII-top will then perform simple LDAP queries against ARIS’s scripts. Stand-alone infoproviders canexisted be prior either to components ARC v.1.0.0. external to ARC or legacy infoproviders that 5.3.1 Registering to an EGIIS and are configured and executed by the PoS(EGICF12-EMITC2)074 ]. 1 Florido PAGANELLI ARC Computing Element Starts A-REX Stand-alone Infoproviders Infoproviders LDIF The size of arrows in the figures is important: infor- BDII XML 10 Startup Script Configuration Stand-alone SLAPD LDAP Configuration and Configuration LDAP arched WS Registration Scripts Registration versatile Web Service container, an ARC CE is able to send regis- arched RESTful LDAP ] is a novel Endpoint Registry architecture being developed within the EMI project [ 2 In this section we give a brief overview, in pictures, of how the ARC information trees for In the case of the BDII-top, a huge amount of information is pulled from the local level to the EMIR [ By leveraging the As in EGIIS, very small amount of information is expected to be sent to the registry, namely, different renderings (XML or LDIF) of the GLUE2 schema look like. At the time of writing, there mation towards EGIIS and EMIRARIS is is minimal huge and and uses unidirectional, LDAP while queries. information between BDII-top and 5.4 The information trees Figure 5: ARIS and other index level technologies. index level. 5.3.3 Registering to an EMIR service services and their endpoint URLs. The ARC Information System: overview of a GLUE2 compliant production system Its relevant features considered in this paperof are a GLUE2 RESTful dialect interface for to communication and describea the services use push and model, endpoint in URLs whichinterface. records. a registrant The willing communication to follows be in the index pushestration records information by via reshaping a the RESTful XMLmessage. output of inforproviders and creating the expected RESTful PoS(EGICF12-EMITC2)074 mds- is the root of Florido PAGANELLI shows how the GLUE2 schema is the root of the GLUE2 tree, 7 o=glue mds-vo-local=resource,o=grid shows how the GLUE2 schema is rendered by our 11 8 (NorduGrid) (Glue 1.2/1.3) (Glue Mds-vo-name=local,o=grid Mds-vo-name=resource,o=grid o=glue (GLUE2) o=grid is the root of the NorduGrid schema, shows how does the LDAP root look like, Figure 6 The LDIF/LDAP tree root. It includes all schemas. Figure is rendered by our proposed LDIF,proposed and XML Figure document and its main differences from the LDIF rendering. Figure 6: vo-name=local,o=grid The ARC Information System: overview of a GLUE2 compliant production system are no official treeschange defined, in the therefore future. these figures represent only a proposal that is subject to the Glue 1.2/1.3 schema. They can all be published simultaneously. PoS(EGICF12-EMITC2)074 Com- Florido PAGANELLI GLUE2GroupID=grid Contact or Service or Location AdminDomain Benchmark Can be attached to AdminDomainCan be attached to ComputingShare MappingPolicy(ies) (A-REX) grid ComputingService ComputingService GLUE2 objects from technical-resource branch Benchmark 12 The proposed structure has been divided into two GLUE2GroupID= ComputingManager GLUE2GroupID= ExecutionEnvironments ExecutionEnvironment(s) UserDomain and GLUE2GroupID= o=glue ComputingActivities (GLUE2) ComputingActivity(ies) ) presenting all the needed information to perform job submission and man- ComputingEndpoint(s) resource AdminDomain GLUE2GroupID= ApplicationHandle(s) . Note also that the tree structure is subject to change depending on future OGF GLUE2 ApplicationEnvironments ApplicationEnvironment(s) (ARIS) Service GLUE2GroupID= Endpoint(s) AccessPolicy(ies) GLUE2GroupID=resource Working Group agreements. branches. The choicebranch) is containing to the separate( administrative-bureaucratic information (the agement choices. Please note thatputingActivities in ARC, job information is also published, in the form of GLUE2 Figure 7: The ARC GLUE2 LDAP tree. The ARC Information System: overview of a GLUE2 compliant production system PoS(EGICF12-EMITC2)074 object is