Features

Certificate Managment

Generally, security in the Grid is based upon using X.509 certificates. Users do not have accounts for all the resources instead they have public/private key pairs and identity certificates. Using certificates prevents the user from repeatedly typing username/password. It's a critical issue how to manage and store these certificates in the most practical way.

Management of certificates in the portal

In P-GRADE Portal the Credential Manager portlet (Figure 1) allows the portal user to download proxy credentials from a MyProxy server (MPS). A user may have more than one proxy from different MPSs. The user can view the details of a proxy, including its lifetime and any proxy can be selected for usage.

In the multi-GRID environment users have to provide certificate for each Grid, this means that they have to map any valid certificate for any Grid on the resources of which they want to execute their application. The whole certificate management takes place in the Certificate tab of the portal just like before. Right after download, users are offered to map the certificate for any of the Grids.

Grid management

In P-GRADE Portal (from version 2.1) users can execute their applications in several Grids, each of which represents a Virtual Organization, VO. For each of these Grids the user has to have an accepted certificate, which will be used for authenticating the user at the resources of that particular Grid.
To use this multi-GRID support the following steps have to be taken

• The portal administrator have to set up the list of Grids, and may define a set of default resources as well
• Each user can than setup his own resource list for this Grids
• The jobs of the workflow can then be allocated to any of the resources, and the jobs of the very same workflow can be executed on different Grids as well
• Before execution the user has to supply his certificate for each Grid involved

The Grid and resource list can be edited in the Settings portlet (Figure 2).
Only the root user has privilege to setup and modify the list of Grids.

Information System management

The P-Grade portal can also handle the available Grid information systems through the Information System portlet (Figure 3). Two kind of information systems are managed in the P-Grade Portal at present: the MDS-2 and the LCG-2 Information system. The MDS-2 and the LCG-2 information system of the portal have two functions: one is getting the list of resources available in the Grid; the other is retrieving detailed information about individual resources. The user can select a Grid for the available sites using the "Select Grid" combo box which can be found toward the upper part of the portal window.

The users of LCG type Grids must belong to Virtual Organizations (VO). The CE’s and the SE’s are associated to VO-s as well. The CE-s may belong to more than one VO. This means that if a CE or SE associated to a VO only those users who belong to the corresponding VO can access these resources.

The user can filter the sites associated to a specified VO by the combo box which can be found under the Grid combo box in the upper part of the portal window.

Selecting a specified VO means the following:

• The user can see the list of sites which belong to a selected VO only.
• When the user clicks to a site name the detailed information will display only those CE’s and SE’s which belong to the selected VO.

If the user select a VO in the site list page only those CE’s and SE’s will be displayed in the detailed view which are belong to a selected VO.

Resource management

Filling a simple table of the Portal server the user can define the URL and the way of basic services of the remote resources where the jobs may run. The portal administrator defines a default list, which will then be available for any of the users for setting up their own resource list. Resources can be added by 'Add' and can be deleted by the 'Delete' button (Figure 5). Specification of the the resource URL (for example n50.hpcc.sztaki.hu), and a Job manager (for example jobmanager-fork) have to be provided.

File management

Life cycle of local and remote files

When an input file is needed to execute a Job, the file will be copied from the P-GRADE Portal Server if it is as a local file (available on the user's machine) or it will be copied from the remote Location if it has been defined as a remote file. Remote location is a place (eg. Storage Element) which is not in the local file system of the user, but accessible by the used certificate accepted in one or more GRIDs.
To access to a remote location a transfer protocol is needed, which is explicitly or implicitly part of the URL describing the location of the file. The used protocol is gsiftp i.e in this case the user will be identified against the remote host by the actual certificate.
In a similar way after termination of the Job the generated output file will be copied to the P-Grade Portal Server if it has been defined to be local (i.e. downloadable on the User Desktop) and it will be copied to the respecting remote site in the other case.

Workflow management

A workflow is a set of consecutive and parallel jobs which are cooperating in the execution of a parallel program. One job's output may provide input for the next. In the literature workflow is also referenced as application flow. The workflow portlet helps to edit jobs, compose workflow-files, submit them, and visualize the trace-file describing each.

Figure 7 shows a workflow executing a short-term weather forecast application. The important aspect of creating a graph is the possibility of composing the workflow application from existing code components. These components can be sequential, PVM, or MPI programs. This flexibility enables the application developer to create computation-intensive applications where several components are parallel programs to be run on supercomputers or Grid clusters.
The workflow and its jobs can be allocated in the "Workflow Editor". For any job any Grid and resource in that Grid can be set.
Users can attach a visualizer (Workflow Editor application) to the submitted workflow to monitor it's progress which is represented by different colors. (Figure 8)
Double clicking on the job its properties (Figure 9) could be edited. In this menu the user defines the code of job to run (Job Executable) and the call conditions of the job - where to let it run (Grid, Resource) and with what kind of arguments and conditions.

Quota management

From Release 2.1 the administrator can define storage UQ for each user. The amount of quota is common for each user and can be defined by the administrator (Figure 10). The administrator defines the amount of user quotas (maximal storage capacity of user may occupy from the valuable common disk resource of the Portal Server Machine).

Monitoring

On one hand the possibility of the high level, –or workflow monitoring is the generic property of the implied job submission technique "Globus/Dagman". The jobs are represented by colored bars placed as rows of a coordinate system where the horizontal axis denotes the common time, and the –discrete – vertical axis is labeled by the name of a program job.

There is also a job level monitoring. The jobs which are running and /or finished can be visualized by the Prove program which opens independent windows upon hitting the respecting Visualize buttons.
Visual rendering activities include the filtering, attributing, and time scale zooming of the program parts.