OGSA-DAI and the NGS

advertisement
NGS Experimental
OGSA-DAI Service
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.
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.
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
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
Operational Model
Using the Service
- What’s 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.
Using the ServiceWhat 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.
Using the ServiceWhat Users can expect
Service Details
Pre-deployment Phase
• Best endeavours coordination of
service deployment by NGS OGSADAI administrator.
• Monitoring of deployed service for
impact on resources and stability. This
at present is as simple as making sure
Tomcat doesn’t 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. (09:30 to 12:30
each Wednesday)
• Monitoring and automated notification
of outages.
• The service will be open to the world
subject to users chosen authentication
method.
Using the ServiceWhat 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).
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
Future Development
Process and Procedure
• The current deployment processes and access
procedures are not fixed. As the service matures
and user’s needs are better understood, all
processes will be subject to review.
Technical
• Upgrade to OGSA-DAI 5
• Review deploying OGSA-DAI as an out-ofprocess add-on to apache. i.e., via
apache+mod_ssl+mod_jk2. Motivation is to
check stability/scalability/performance. DQP
Supporting Documentation
• Initial RFC for NGS Experimental Service
• OGSA-DAI Installation and Configuration
Guide
• Oracle database request form
• OGSA-DAI deployment request form
Useful Links
• www.ogsadai.org.uk The home of OGSADAI - lots of documents and tutorials
covering the whole of OGSA-DAI
• wiki.astrogrid.org/bin/view/Astrogrid/Globu
sSecurityCode - Very useful information on
Globus 3 security.
• www.gridlab.org/WorkPackages/wp5/guide/axis.html - Apache AXIS and GSI
install guide
Download