NGS Experimental

1

• NGS Experimental
• OGSA-DAI Service

2
What is OGSA-DAI?

• The Open Grid Services Architecture Data Access
  and Integration project is concerned with
  constructing middleware to assist with access and
  integration of data from separate data sources
  via the grid. It is engaged in identifying the
  requirements, designing solutions and delivering
  software that will meet this purpose. The project
  was conceived by the UK Database Task Force and
  is working closely with the Global Grid Forum
  DAIS-WG and the Globus team.

3
OGSA-DAI and the NGS

• The NGS core nodes, from the outset, have been
  partitioned into compute and data clusters. As
  the NGS matures and the requirement for data
  hosting grows within and outside of the user
  community it is in the remit of the data
  clusters to address these needs, moreover to do
  it within a grid-architecture. OGSA-DAI as
  described above will help to satisfy these needs.
• The term experimental is used to indicate that
  the OGSA-DAI deployment on the NGS is being
  actively developed and users should expect that
  procedures may change it does not reflect the
  commitment NGS has to providing a service.
• Initially the Manchester JISC data cluster has
  been charged with deploying the OGSA-DAI service
  (and has dedicated 1/10 of the cluster to do so)
  as demand increases and processes are refined
  deployment to other sites is expected
• This is one of the first attempts to provide a
  consistent, persistent, OGSA-DAI service hosting
  environment for use to a diverse community.

4
Overview of Experimental Service

• Hardware and OS
• Two nodes of the Manchester Cluster are dedicated
  to the OGSA-DAI service, each has
• Dual CPU Intel 3.06 GHz nodes (Supermicro
  motherboard)
• 4GB Memory per node
• 2x120GB IDE disks (1 boot, 1 data with local
  scratch around 100GB)
• Both nodes are running Redhat Enterprise 3.

• Installed Software
• Core middleware
• OGSA-DAI 4.0
• Globus 3.2
• Jakarta Tomcat 4.1.30
• Apache Ant 1.6.2
• Junit3.8.1
• Back-end software
• Sun Java1.4.2-05
• Oracle RAC 9.2.0.5

5
Operational Model

• The working model for the service is three phase
  
• Testing
• This phase is for initial development of the
  OGSA-DAI service. The user is expected to have a
  suitable environment for OGSA-DAI service
  development and access to the data resources
  necessary. It may be the case that the data
  resource is hosted by the NGS.
• Pre-production
• This phase is a pre-cursor to the next. Once a
  user is satisfied that their OGSA-DAI service is
  production ready it can be hosted on the NGS. The
  deployed service will undergo acceptance testing
  for migration into production. Services hosted in
  this phase may still talk to the resources within
  the user environment. Also services should expect
  shorter uptimes and interruptions to operations
  as other projects deploy and stabilise.
• Production
• At this point a services installation is clearly
  defined and stable, modifications to services
  have to be made at pre-defined at risk periods

6
Operational Model
7
Using the Service- Whats required of the User?

• Access to the NGS
• Development platform for OGSA-DAI
• Data resource (secure access to a reference
  database hosted on the NGS is being investigated
  for new developers)
• Completion of OGSA-DAI access form
• Proposed authentication/authorisation method to
  the service for review by the NGS
• Primary contact for a service that is in full
  production.
• Policy regarding authentication/authorisation is
  currently under discussion with the NGS technical
  board.

8
Using the Service-What Users can expect

• Obtaining access
• For deployment a lightweight form needs to be
  completed by a user to capture the requirements
  of the service and provide the NGS admins with
  detail necessary to plan deployment. The form is
  split into five core areas.
• Brief desription of service
• Data resources to be used
• Estimated initial usage
• Authentication/Authorisation methods
• Other requirements
• The form is available from the NGS OGSA-DAI
  website and should be submitted to GOSC.
• Technical Details
• For a detailed information on the OGSA-DAI
  installation on the NGS users can refer to NGS
  OGSADAI Install Configuration.

9
Using the Service-What Users can expect
Service Details

• Pre-deployment Phase
• Best endeavours coordination of service
  deployment by NGS OGSA-DAI administrator.
• Monitoring of deployed service for impact on
  resources and stability. This at present is as
  simple as making sure Tomcat doesnt crash and we
  see no memory/thread leaks as a result of
  deployment.
• Limited access (via gsissh) to the server (only
  to the users own files) in order to troubleshoot
  and make modifications to the service.
• A weeks cool down period after user and admin
  are happy service is ready for full deployment.
• Only developers and admins will have access to
  the pre-deployment service with access controlled
  by the firewall.

• Deployment Phase
• Full change control regarding the OGSA-DAI
  service. All changes and additions are to occur
  at a regularly defined at risk period. (0930
  to 1230 each Wednesday)
• Monitoring and automated notification of outages.
  
• The service will be open to the world subject to
  users chosen authentication method.

10
Using the Service-What Users can expect

• Support
• All enquiries and production support for the
  experimental OGSA-DAI service is via the Grid
  Operations Support Centre (GOSC).
• The initial deployment phase will have direct
  support from NGS OGSA-DAI admins.
• The NGS is developing a working relation with the
  OGSA-DAI team. OGSA-DAI to NGS liaison officers
  have been established to further this
  relationship (Amy Krause from OGSA-DAI and Matt
  Ford from the NGS).

11
Case Studies

• Convert Grid
• Convert Grid website Work in progress
• Reference Service
• OGSA-DAI little black book test database has been
  installed and made available to all. The case
  study shows
• Database creation through to deployment on
  production.
• Example completion of all necessary forms.
• Highlights tests and some of the tools used.
• Note GSI authentication is proving to be tricky

12
Future Development

• Process and Procedure
• The current deployment processes and access
  procedures are not fixed. As the service matures
  and users needs are better understood, all
  processes will be subject to review.
• Technical
• Upgrade to OGSA-DAI 5
• Review deploying OGSA-DAI as an out-of-process
  add-on to apache. i.e., via apachemod_sslmod_jk2
  . Motivation is to check stability/scalability/per
  formance. DQP

13
Supporting Documentation

• Initial RFC for NGS Experimental Service
• OGSA-DAI Installation and Configuration Guide
• Oracle database request form
• OGSA-DAI deployment request form

14
Useful Links

• www.ogsadai.org.uk The home of OGSA-DAI - lots of
  documents and tutorials covering the whole of
  OGSA-DAI
• wiki.astrogrid.org/bin/view/Astrogrid/GlobusSecuri
  tyCode - Very useful information on Globus 3
  security.
• www.gridlab.org/WorkPackages/wp-5/guide/axis.html
  - Apache AXIS and GSI install guide