Project

General

Profile

Presentation

About GOCDB

Grid Configuration Database (GOCDB) contains general information about the sites participating to the production Grid. Accessed by all the project actors (end-users, sitemanagers, NGI mangers, support teams, VO managers), by other tools and by third party middleware in order to get Grid topology.

Information stored :
  • Sites and related information
  • Groups (NGIs, ROCs, Countries) and related information
  • Users and related information
  • Downtimes and related information

In the overall architecture described above, regional and central modules are built exactly the same way. They come as a set of components that can be deployed and configured to act as a central or local service.

GOCDB4 comprises of the following core components:

  • A database schema based on Oracle
  • Internal components Allowing for business logic
  • A set of interfaces that provide access to the database to any other component

About CIC portal

The operations portal consists of web pages providing information to various actors (NGI Operations Centres, VO managers, etc.) along with related facilities, such as the VO registration tool, the broadcast and downtime system, the regional dashboard, etc.

Information stored and used :
  • Vo and related information
  • Sites and related information
  • Service endpoints and related information
  • Groups (NGIs, ROCs, Countries) and related information
  • Downtimes and related information

Same kind of architecture than for the GOC DB : In the overall architecture described above, regional and central modules are built exactly the same way. They come as a set of components that can be deployed and configured to act as a central or local service.

Operations Portal comprises of the following core components:

  • A database – to store information related to the users or the VO - based on Mysql
  • A web module – graphical user interface – which is currently integrated into the Symfony framework
  • A Data Aggregation and Unification Service named Lavoisier

Definition of the problem

The interaction between GOC DB and Operations Portal is strong.
Some exchange of information and services is already in place .

This work will be extended with the integration of GOCDB and the Operations Portal under a common
interoperable toolkit for grid operations which will be done following two main directions:

  • Integration of a common central human interface allowing users to access both central services through a single entry point.
  • Integration of interoperable back ends for distribution to NGIs as a single package if possible.

Such development will require effort at data representation level as well as at interface and data
transfer level.Both teams aim at first at providing a common web interface to handle both type of information, being transparent to the user.

Vision and objectives

Modularity: We want “independent tools working together” rather than “one single tool”.
Transparency: users should not have to care about how this is done in the backend. To end users, the solution will be seen as “one single tool”.

Example: something like the Google tools: gmail, googledocs, picasa… are different applications that work well together. You can just use one of them, but if you want to use all there is a great homogeneity.

Needs and constraints

  • Do not propose a bulk tool (keep modularity)
  • Allow one part of the system to be installed and operated without the other
  • Reuse the legacy wherever possible (no time, no money to redo everything)

Possible technical solutions

Considerations on the legacy

  • GOCDB and the Operations Portal different backend: Oracle vs mysql
  • Different DB schema and principles (use of PROM for GOCDB)
  • Also different scope: regional+central, or central only

Solution A:

Merged front-ends and interconnected back-ends

  • Keep separated:
    • GOCDB database backend and low level interfaces
    • Operations Portal backend and low level interfaces
  • Group:
    • High level interfaces
    • Web front ends

Backends will still interact with one another on joint information, this being based on the principle of views (e.g. cross-querying services and VOs)

  • Benefits
    • Reuse the legacy backend
    • Provide a single top level interface
    • Great modularity (can only install one backend or the other)
  • Downsides
    Failover can be complicated

Solution B: Fully merged front-ends and back-ends

Design a database model integrating data currently handled between GOCDB and CICDB
Provide the interfaces to this database, and provide a single front-end

  • Benefits
    • Provide a single top level interface
    • Easier failover
    • Easier to cross-query the information
  • Downsides
    • Bigger tool, more complex, difficult to maintain and operate
    • Not scalable (no modularity)
    • Complete redesign of the legacy