The NorduGrid production Grid infrastructure, status and plans

Transcription

1 The NorduGrid production Grid infrastructure, status and plans P.Eerola,B.Kónya, O. Smirnova Department of High Energy Physics Lund University Box 118, Lund, Sweden T. Ekelöf, M. Ellert Department of Radiation Sciences Uppsala University Box 535, Uppsala, Sweden J.R.Hansen,J.L.Nielsen,A.Wäänänen Niels Bohr Institutet for Astronomi, Fysik og Geofysik Blegdamsvej 17, Dk-2100 Copenhagen Ø, Denmark A. Konstantinov Institute of Material Science and Applied Research Vilnius University Saulėtekio al. 9, Vilnius 2040, Lithuania T. Myklebust, F. Ould-Saada Department of Physics University of Oslo P. O. Box 1048, Blindern, 0316 Oslo, Norway J. Herrala, M. Tuisku Helsinki Institute of Physics University of Helsinki P.O. Box 33 FIN Helsinki, Finland B. Vinter Dept. of Mathematics & Computer Science Odense University Campusvej 55 DK-5230 Odense M, Denmark Abstract NorduGrid offers reliable Grid services for academic users over an increasing set of computing & storage resources spanning through the Nordic countries Denmark, Finland, Norway and Sweden. A small group of scientists has already been using the NorduGrid as their daily computing utility. In the near future we expect a rapid growth both in the number of active users and available resources thanks to the recently launched Nordic Grid projects. In this paper we report on the present status and short term plans of the Nordic Grid infrastructure and describe the available and foreseen resources, Grid services and our forming user base. 1. Introduction Grids are emerging as new promising infrastructures for solving large-scale scientific challenges [1]. Recently many Grid projects have been launched for developing, evaluating and deploying Grid Technologies. Despite the vast number of projects very few Grid TestBeds have succeeded in surpassing the demonstration quality stage and providing reliable Grid services on a daily basis for their users. In order to create a Grid infrastructure which can help face the computing and data challenges of the Nordic scientific communities, the Nordic TestBed for Wide Area Computing and Data Handling, also know as NorduGrid [2], was launched in Scandinavia and Finland (see Figure 1). The early TestBed set up in August 2001 comprised of five core development sites in Bergen, Copenhagen, Lund, Oslo and Uppsala. It was based on the at that time very beta quality version 2 of the Globus Toolkit [3]. The evaluation of functionality and reliability of the Grid services provided by the Globus Toolkit and the EU DataGrid Middleware [4] carried out during the Autumn of 2001 showed that these toolkits alone could not be used to build a production Grid. Therefore the NorduGrid developers came up with their own architecture and implementation proposal [5, 6]. In May 2002 the first version of the NorduGrid middleware [7] was rolled out on the TestBed. The toolkit soon got evaluated and deployed in some of the largest Nordic computing centers. Section 2 gives more detailed account of the NorduGrid resources while Section 3 introduces the provided Grid services. It was the ATLAS High Energy Physics Group which first started to use NorduGrid for its production data processing and since July 2002 NorduGrid hosts the production ATLAS runs. As of this writing NorduGrid provides a unique international production Grid infrastructure to its growing user

2 base. The reliable Grid services implemented by the NorduGrid middleware are provided permanently, the TestBed is operational 24 hours a day, 7 days a week. The achieved scientific results and the Nordic share of the ATLAS Data challenges (Section 4) has proven that NorduGrid overcame the demonstration quality stage and that it is now a production Grid infrastructure. In the near future NorduGrid foresees an extensive scaleup both in terms of resources and users due to the recently launched projects such as the Danish center for Grid computing, the Nordic Data Grid Facility or the SweGrid [8]. It is obvious to us that the currently available low-level Grid services will not be satisfactory to professionally manage the scaled-up infrastructure and the extended user base. Therefore common policies and technical solutions (higherlevel Grid services) are needed to be found. Bergen Trondheim NORWAY Oslo DENMARK Tromsø SWEDEN Linköping Göteborg Uppsala Århus Lund Odense Copenhagen Umeå Stockholm FINLAND Helsinki WAN lines: 10 Gbps, GigaSUNET 2.5 Gbps, NORDUNet 2.5 Gbps, UNINETT 622 Mbps, Forskningsnet 100 km Figure 1. Grid enabled sites: The NorduGrid connectivity map. Solid lines illustrate connections to existing resources, dashed lines connect sites which plan to join the facility 2. The resources The NorduGrid fabric consists of a dynamic and an increasing number of computing and storage resources connected via the excellent Nordunet academic network of the Nordic countries [9]. Resources belong to different administrative domains of academic institutes and Nordic Supercomputing Centers. The available resources can any time be seen on the Grid Monitor [10] shown in Figure 2. The majority of the computing resources are Linux clusters although we are experimenting with SMP machines as well. The list of Grid-enabled clusters ranges from small test clusters with a couple of CPUs to TOP500 supercomputing facilities like the Monolith or the HPC2N Superclusters [11]. At the time of writing NorduGrid connects approximately 20 resources with a rather heterogeneous setup. There are both Grid dedicated and non-dedicated resources, PC and Alpha based clusters, SMP machines, clusters running RedHat, Mandrake, Debian or Slackware Linux. NorduGrid uses disk servers as storage facilities. Storage space is continuously added following user demands. As of June 2003, NorduGrid operates Terabyte range storage elements placed in Oslo, Copenhagen, Lund, Linköping and Umeå adding up to a total of 10 Terabytes distributed capacity. NorduGrid is already one of the largest production Grids in the world, both in terms of number of connected sites and resources (app CPU s are available 24 hours a day, 7 days a week). During the Autumn of 2003, the facility is foreseen to grow further. Sweden has initiated the Swe- Grid project which will build and Grid-enable six Beowulfclass clusters and install distributed storage in the order of 100 Terabytes. Finland plans to join the NorduGrid through their official supercomputing centre, Centre for Scientific Computing, by adding a 512 CPU IBM Regatta machine as well as a 128 CPU SGI Origin 3000 machine. In Norway the supercomputing meta-center, NOTUR, will join with its resources: a 96 CPU IBM Regatta and a 862 CPU SGI Origin Finally, Denmark joins through the Danish Centre for Grid Computing and the Danish Centre for Scientific Computing, which will add an 80 CPU IBM Regatta, a 32 CPU SGI Origin 3000 and two Beowulf class clusters of 652 and 480 CPU s respectively. 2.1 Site setup The careful design of the NorduGrid middleware [5] resulted in a lightweight, portable and non-intrusive Grid solution. The main design principles are the following: ffl resource owners retain full control over their resources ffl sites do not have to be Grid dedicated, resources can be shared between Grid and non-grid (local) applications

3 ffl number of Grid daemons is kept minimal and Grid site management as simple as possible ffl NorduGrid is a Grid layer and not a cluster installation, configuration nor management tool ffl there is no unnecessary dictation or constraint on the local cluster setup, no dependency on a particular operating system version ffl the middleware is only installed on the frontend; no extra requirements on the nodes, e.g. nodes can be on a private network. These principles allowed the toolkit to get widely adopted within the computing centers and academic institutions. Moreover, the implementation resulted in an easily installable, configurable and maintainable Grid layer which makes the additional Grid management costs of a NorduGrid site minimal. Some sites are administrated by the NorduGrid developers and some of the site administrators are actively participating in the development process, thus creating a very healthy and close connection between developers and site administrators. 3 Grid services The NorduGrid facility reliably delivers a broad set of Grid services for handling user authentication, authorization, job submission and management, low-level data management as well as services coupled to the information system such as resource aggregation, discovery, monitoring and resource selection (brokering). The above services, referred to as low-level Grid services, are provided by the NorduGrid Toolkit [7] which is a Grid middleware solution based upon the Globus Toolkit libraries and services. Some of the original Globus components are kept (authentication and security framework), some are slightly enhanced (authorization) or extended (resource specification language), some are used in a different manner (LDAP-MDS), while others are completely replaced (GRAM and the Globus jobmanager) by their NorduGrid equivalent. Furthermore NorduGrid have created new services and solutions such as the Grid Manager (a smart Grid frontend on top of the clusters), the NorduGrid Gridftp server (which among other things accepts the Grid job requests), the Information Model with the Monitoring system and the User Interface with the integrated brokering. Even though the NorduGrid Toolkit is under constant development, the Grid services are provided reliably since extra priority is put on maintaining the quality and stability of toolkit and the Grid. The remarkable stability of the NorduGrid was achieved by replacing the most problematic Globus components (gass-cache, GRAM, jobmanager) and simplifying some of the others (the GIIS-GRIS from MDS). Our philosophy to use something simple but functional coupled with the substantial amount of testing and debugging effort added to the overall stability. This set of low-level Grid services appears to be sufficient to operate a production Grid. At the same time it has become obvious that there are important higher-level Grid services missing. In what follows, the implemented services are described together with our conception on the missing higher-level ones. 3.1 Authentication & Security The security infrastructure of the NorduGrid complies with the Grid Security Infrastructure (GSI) [12] of the Globus Toolkit. All users and resources are authenticated by their X.509 Public Key Infrastructure (PKI) certificates. NorduGrid runs its own Certificate Authority (CA) which is responsible for establishing the identity of the NorduGrid users and resources. The NorduGrid CA is recognized by other related projects, such as the EDG [4]. In fact, NorduGrid and EDG certificates are mutually accepted. 3.2 Authorization The current authorization solution follows the rather limited capabilities of the Globus Toolkit. Local (site) authorization is accomplished through a simple mapfile which contains the list of authorized Grid credentials mapped to local Unix user accounts. Local access control is then enforced by fine tuning the Unix and/or the batch system s authorization capabilities. In order to facilitate the synchronization of the grid mapfiles, a collective authorization method has been set up in accordance with the practices of many Grid TestBeds. A central service (a GSI-enabled OpenLDAP database) maintains a list of Grid users organized into user groups. A small utility (nordugridmap) on the resources periodically pulls the list of authorized users and generates the grid mapfile according to the local site policy which decides upon the authorized user groups. Evidently, the above authorization structure is very coarse grained, rather static and absolutely lacks flexibility and scalability. Therefore NorduGrid is making steps towards the usage of one of the recently proposed Grid authorization frameworks such as the EDG s Virtual Organization Management Service (VOMS) [13] or the Globus Project s Community Authorization Service (CAS) [14]. 3.3 Accounting, Logging & Bookkeeping Terms such as accounting, logging & bookkeeping refer to Grid services responsible for collecting some sort of

4 Figure 2. A typical screenshot of the Grid Monitor [10] during production. The number of CPU s of each cluster is given to the right of the cluster name. The monitor shows both the number of running grid and locally submitted (non-grid) jobs for each cluster. resource usage and job history and other information. In centralized systems where all the Grid jobs pass through a central broker the accounting service comes for free. On the other hand, in real distributed environments the accounting information needs to be collected from the local resources. According to our architecture [5] there is no central broker in the NorduGrid. Therefore to maintain an accounting service, NorduGrid have to set up a central accounting database and collect the usage information from the resources. As of writing, the NorduGrid Grid Manager [15] can collect local resource usage information and it is already capable of sending this information through a SOAP message to a central accounting database. The details of the central accounting database and the usage record are currently under development. An alternative solution to the above described accounting service could be the consideration of a Grid Market Economy framework. Within that scenario the Grid Marketplace would serve as a natural logging facility, where all the resource consumers and providers could meet and their contracts would be recorded. 3.4 Uniform access to computing resources NorduGrid offers a uniform interface to its computing resources. Physical access to the computing cycles (batch systems) is provided through a layer which consists of the pair of a GridFTP interface and the Grid Manager (GM) [15] running on the frontend machine of the cluster. Grid job requests, formulated in terms of the extended Resource Specification Language (XRSL) [16] and submitted by the NorduGrid User Interface (UI) or a Grid Portal (see Section 3.9) are received by the job-plugin of the NorduGrid GridFTP server (NGFS). The job-plugin of the NGFS replaces the GRAM/Gatekeeper [17] of the Globus Toolkit. The NGFS is also responsible for handling the stage-in requests of the User Interface, the UI can upload files through the NGFS to the cluster. The (GM) acts as a smart Grid layer running on top of

5 the batch system. It creates, manages and cleans up the temporary job directories (called session directories), collects input data specified in the job s xrsl file, prepares the requested RuntimeEnvironments of the job, translates the Grid job description (xrsl file) into the batch system s language and submits the Grid job to the batch system. On requests received through the job-plugin of the NGFS the GM cancels the Grid job and cleans up the session directory. On job completion, if requested in the xrsl, the GM automagically handles the stage-out process, uploads files to their destination, registers metadata into file catalogues. Additionally, GM manages a cache area for input files on the frontend, in this way letting consecutive jobs share input data and making redundant data transfer unnecessary. GM also provides information on local resource usage for the accounting (Section 3.3) and the monitoring system (Section 3.7). Let us stress here that the NorduGrid layer completely replaces (and largely extends) the functionalities of the Gatekeeper, GRAM and jobmanager services of the Globus Toolkit. The job submission and job management between the UI and the resource is handled by the NGFS job-plugin (i.e. no need for the Gatekeeper), the stage-in process to the session directory is governed by the GM using the NGFS (i.e. no need for the Globus gass cache), the local job submission to the queuing system is also handled by the GM, whereas the job monitoring is implemented exclusively through the information system (no job monitoring through the Jobmanager ports, see Section 3.7). 3.5 Data management NorduGrid supports some low-level data management services for moving data around on the Grid and managing file replication catalogues. The currently available data management infrastructure consists of the following components: Simple Storage Elements (SSE), Replica Catalogs (RC) and a set of user level commands. Moreover the Grid Manager s cache area and its stage-in/stage-out machinery can be considered as part of the data management infrastructure too. The SSE is actually not much more than a NorduGrid GridFtp server plus a rather simple information provider. Its main features involve support for virtual directory trees, access to local file systems, Grid credential (at the moment the Distinguished Name of the certificate) based access control. NorduGrid makes use of the OpenLDAP-based Globus Replica Catalog for maintaining file replication information. A couple of patches fixing apparent problems of transferring relatively big amount of data has made the centralized system functional enough. The user-level commands allow the transfer, removal, replication and registration of data files in the system. These commands are built on the Globus API libraries, the only significant change is the addition of the possibility of secure authenticated connections with RC server. As it was described in Section 3.4, the GM can automatically perform a significant part of the stage-in/stage-out process of a Grid job, thus saving the user from the burden of manual management of input and output files. The GM is capable of downloading the requested input files to the job s session directory, can perform RC queries on behalf of the user and after job completion it can upload output files to an SSE and register the corresponding metadata into an RC. The experience of the ATLAS user group (see Section 4.2) showed that although it was possible, it is rather difficult to handle production tasks with the present low-level data management system. A higher-level data management is very much needed. In particular, a reliable and consistent (distributed) data replication catalog, intelligent storage elements, storage allocation mechanisms are the missing pieces of a higher-level system. Therefore NorduGrid has started to draft its data management architecture. 3.6 Resource aggregation & discovery NorduGrid consists of a dynamic set of resources which vary from time to time since sites may join and leave the Grid. A resource grouping or aggregation mechanism is used to hold the dynamic Grid together, sites are soft registering to index services. Resource discovery is the process of finding the available resources through the index services. Within the NorduGrid these services are provided by the dynamic distributed Information System (IS) [18]. The IS was created by extending the LDAP-based Monitoring and Discovery Services (MDS) [19], of the Globus Toolkit. Resource aggregation is implemented through soft registrations which are used by the local information databases to register their contact information to the indices. The indices themselves can further register to other indices. This makes the Grid dynamic, allowing sites to come and go, the soft-state registrations made the creation of specific topologies of indexed resources possible. NorduGrid utilizes a multilevel crosslinked tree hierarchy which tries to follow the geographical organization. Resources belonging to the same country are grouped together and register to the country s index service and the index services are further registering to a top level NorduGrid index. In order to avoid any single point of failure, NorduGrid operates a multi-rooted tree with several top-level indices. Resource discovery involves query of information indices. In the NorduGrid the clients query the indices only to find out the contact information of the local databases, so the indices are used as simple dynamic link catalogues, the resources are then queried directly. This streamlined setup and usage of the information indices made the system

6 much more efficient and reliable. The present implementation of the soft-state registration of the MDS makes the creation of resource topologies (the aggregation of resources) a rather cumbersome process, NorduGrid is considering a more flexible replacement for this mechanism. 3.7 Monitoring The Grid monitoring service is built upon the distributed Information System sketched in the previous section. The Grid Monitor (the main window is shown in Fig. 2) is actually nothing else but a Grid client which takes a snapshot of the status of the Grid by performing queries on the distributed LDAP system. Just as the Information System, the Monitor itself follows a pull model: the status information is collected (pulled) by direct queries of the resources. For this first the information indices are contacted in order to find out the list of available resources (contact strings). Technically, the Grid Monitor is implemented as a set of PHP codes running on a web server. The PHP-LDAP module made it especially easy to natively interface to the distributed LDAP-based IS. Within the implementation of a pull model the issue of timeouts of pending queries is critical. Unfortunately the original LDAP-MDS has no properly working timeouts, hence frozen and hanging queries were frequent until NorduGrid provided fixes for functioning timeouts. The Monitor allows browsing through all the published information or launching real time queries on resources and attributes. The information content presented by the Monitor is determined by the NorduGrid Information Model [18]. The NorduGrid schema provides information on clusters, batch queues, storage elements, Grid users and Grid jobs. The daily operation of the NorduGrid and the satisfaction of our users proved the validity of our information model and monitoring service. We expect that the service will efficiently scale even on the extented size of the Grid. However it is apparent that a full scale snapshoting system (regardless if it follows a pull or a push model) is not maintainable on still larger systems, therefore different monitoring strategies must be investigated and followed. NorduGrid is performing scalability tests of its infrastructure and looking for scalable solutions. 3.8 Resource management Resource management on the Grid usually refers to the problem of how the Grid jobs are scheduled or allocated among the Grid nodes. Grid scheduling or Superscheduling over the local schedulers (batch systems) is a very complex problem (see the relevant research area of the Global Grid Forum [20]). There are pros & cons on brokering from a central pool, some people even questions the justification and feasibility of such a service. On the other hand Grid market based approaches (which are essentially centralized pools) look as rather promissing candidates for solving the resource management challenge. It was not the task of NorduGrid to settle this question. Instead NorduGrid took a very pragmatic step and followed the simpliest and most straightforward approach, the individual agent based model. NorduGrid implements a fully decentralized resource management system where independent agents are making their own brokering decisions after performing queries against the Information System. The Nordugrid broker comes as an integral part of the User Interface (Sec. 3.9). First it scans the IS for the list of available resources, then matches the job requirements against the possible target and, following brokering algorithm it selects the destination cluster. The brokering algorithm takes into account the number of free and occupied CPUs and the data locality. The broker follows a mixture of a CPU and data driven brokering scheme. 3.9 User Interface A set of command line tools is provided for job submission, status query and job management, etc. There are also commands for retreiving data from finished jobs or accessing files on Storage Elements and manipulating the replica information. Detailed information of the NorduGrid commands can be found in the User Interface Manual [21]. A command line Grid session requires the preparation of an xrsl file [16], which provides the job description by specifying the input data, the executable, the output data or the resource requirements. Then the job is submitted to the Grid with the ngsub command which does the brokering and sends the job to the selected resource (see Section 3.8 on resource allocation and brokering). The User Interface is distributed in an easily installable preconfigured, self-contained portable package available from the NorduGrid download page. Another option to access the NorduGrid is via a Grid portal, which is being developed at the Helsinki Institute of Physics, Finland. The NorduGrid portal is part of the GridBlocks technology framework [22]. The objective of the NorduGrid portal is to provide users with a web-based interface to the available resources and services. The portal is implemented as a light-weight Java application, which embeds the NorduGrid command line interface. A portal user does not need to install the NorduGrid client software, only a web browser is required. The user simply connects his/her web browser to the portal web site and executes NorduGrid commands through the web browser interface.

7 4. Users on the NorduGrid The Grid is used for middleware development, system integration tests, for demonstrations and during tutorials but most importantly for production runs. The existing active user base is what tells NorduGrid apart from the DemoGrids. Users are the key assets on any Grid, they are the real criteria of a production quality operation. One of the main objectives of the recently launched Nordic Grid projects is to attract users to the Grid by providing low level entrance barrier, these projects in particular focus on the traditional High Performance Computing community. 4.1 The early pioneers A small group of scientists who are traditionally dealing with complex, computationally extensive problems has already discovered the NorduGrid. From their point of view the Grid is in the Golden Age of the Wild West where there is a free lunch of vast amount of computing power available for everybody who dares to make the first steps. Our pioneers have been successfully utilizing the Grid for supersymmetric theoretical particle physics model calculations [24] or for performing quantum Monte Carlo simulations of large-scale quantum many body systems [25]. 4.2 The ATLAS HEP group In order to prepare for data-taking at the LHC starting 2007, ATLAS [26] has started a series of computing challenges of increasing size and complexity. The goals include a test of its computing model and the software suite and to integrate grid-middleware as quickly as possible. The first of these Data-Challenges, the DC1, has been running in several stages in the second half of 2002 and in the first half of For the first time, massive physicssimulations ran at a total of more than 50 institutes worldwide. NorduGrid was the Scandinavian contribution to this Data-Challenge. Using solely the NorduGrid facility, we were able to participate in the DC1 and run real production. In total NorduGrid ran more than 4750 grid-jobs processing more than 2TB of input data and producing more than 2.5 TB of output data. See [23] for a thorough account on the NorduGrid involvement in the DC1. In total about 60 TB of data was produced worldwide in DC1. The future Data-Challenges, with Data-Challenge 2 starting in the second quarter of 2004, will be larger and more complex. The intent is along the way to put up a permanent production environment in the interested institutions. This will present our group with future challenges which we are committed to solve relying exclusively on the NorduGrid. 4.3 New user groups The Grid environment appears as an attractive alternative to the traditional structure of supercomputer centers and private research clusters. As more and more resources are being made available through the Grid (see Section 2), it is expected, that the conventional High Performance Computing (HPC) user community will gradually migrate to the NorduGrid. For example, in order to facilitate this process the Swe- Grid project [8], launched in early 2003, will offer its resources linked to the NorduGrid exclusively through the Grid layer. The combined resources of the planned six Grid nodes exceed those of the national supercomputer centers representing a valuable packet for the always CPU-thirsty community. Similar steps have been made in Denmark, Norway and Finland whereas the Nordic DataGrid Facility is responsible for the coordination of developments. This strategy will bring users from many different research areas on the Grid, and presents a serious test for the NorduGrid toolkit. Meeting the requirements of the new user groups, while keeping the reliability, stability, scalability and portability, will be a major challenge for our infrastructure. 5 Summary The production Nordic Grid infrastructure was put into operation during the Summer of 2002 and since then it serves an active user base who already considers the Grid a part of their everyday computing toolkit. The Grid spans over the Nordic countries and connects an increasing number of resources which soon will cover all the HPC facilities in North Europe. The strategic Nordic decision on putting all the High Performance Computing (HPC) resources on the NorduGrid helps the migration of the traditional HPC user community. In Sweden SNAC (national resource allocation committee) already allocates CPU resources on the Grid and similar commitments have been made from the national supercomputing organizations in Norway, Finland and Denmark. Thanks to the NorduGrid middleware the infrastructure can reliably provide a solid set of low-level Grid services on a permanent basis. The foreseen scale-up of the NorduGrid necessitates the development and deployment of higherlevel Grid services.

8 6 Acknowledgements The pioneering Nordic Grid Project, the NorduGrid was funded by the Nordic Council of Ministers through the Nordunet2 programme and by NOS-N. The authors would like to express their gratitude to the system administrators across the Nordic countries for their courage, patience and assistance in enabling the NorduGrid environment. In particular, our thanks go to Ulf Mjörnmark and Björn Lundberg of Lund University, Björn Nilsson of NBI Copenhagen, Niclas Andersson and Leif Nixon of NSC Linköping, Åke Sandgren of HPC2N Umeå and Jacko Koster of Parallab, Bergen. References [1] I. Foster, What is the Grid? A three point checklist. [Online] 02/0722/ html [2] Nordic Testbed for Wide Area Computing And Data Handling, [Online] [3] The Globus Project, [Online] [4] The European Union DataGrid Project, [Online] [5] A. Wäänanen et. al., An Overview of an Architecture Proposal for a High Energy Physics Grid, Proc. of PARA 2002, LNCS 2367, p. 76, Springer-Verlag Berlin Heidelberg [6] A. Konstantinov et. al., The NorduGrid project: Using Globus toolkit for building Grid infrastructure, Proc. of ACAT 2002, Nucl. Instr. and Methods A 502 (2003) pp , Elsevier Science [7] P. Eerola, et. al., The NorduGrid architecture and tools, Proc. of the CHEP 03, (2003), [Online] [8] SweGrid, [Online] [9] NorduNet, The Nordic Internet highway to research and education [Online], [10] The NorduGrid Grid Monitor, [Online] [11] Nordic TOP500 SuperClusters, [Online] /super-cluster.html [12] Grid Security Infrastructure [Online] [13] R. Alfieri et.al., Managing Dynamic User Communities in a Grid of Autonomous Resources, [Online] [14] L. Pearlman, et. al., A Community Authorization Service for Group Collaboration, Proceedings of the IEEE 3rd International Workshop on Policies for Distributed Systems and Networks, [15] A. Konstantinov, The NorduGrid Grid Manager And GridFTP Server: Description And Administrator s Manual, [Online] [16] O. Smirnova, Extended Resource Specifikation Language, [Online] [17] Globus Resource Allocation Manager (GRAM), [Online] [18] B. Kónya, The NorduGrid Information System, [Online] /documents/ng-infosys.pdf [19] Monitoring and Discovery Services, [Online] [20] Global Grid Forum Scheduling and Resource Management Area (SRM), [Online] SRM/srm.htm [21] M. Ellert, The NorduGrid toolkit user interface, User s manual, [Online] /NorduGrid-UI.pdf [22] GridBlocks, [Online] [23] P. Eerola et. al., ATLAS Data Challenge 1 on NorduGrid, Proc. of the CHEP 03, (2003), [Online] [24] T. Sjöstrand and P. Z. Skands, Baryon Number Violation and String Topologies, Nuclear Physics B vol. 659, no. 1-2, (2003) pp [25] O. F. Syljuåsen, Directed Loop Updates for Quantum Lattice Models, [Online] [26] The ATLAS Experiment of the Large Hadron Collider, [Online]