Deployment Plan - Seegrid.csiro.au

flameluxuriantΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 10 μήνες)

100 εμφανίσεις


Deployment Plan

For
AWDIP
Water
Monitoring Data
Service
usi
ng Geoserver Web Feature Server

(Generic for AWDIP participants)






















Name

Version

Date

Description

Rob Atkinson

1

14 dec 2007

Generic

deployment details


with geoserver install
a
nd configuration

Rob Atkinson

1.01

7 January
2008

Minor clarifications to Tomcat section, synced ToC

Rob Atkinson

1.02

21 June
2008

Minor clarification to Tomcat WAR file naming.








Created on
7/01/2008 4:16:00
PM

2

of
11

Contents



1

INTRODUCTION

................................
................................
................................

3

1.1

Context

................................
................................
................................
................................
.......

3

1.2

Scope of this document

................................
................................
................................
..............

3

1.3

Specific Deployment Requirements

................................
................................
...........................

3

1.3.1

Geoserver Version:

................................
................................
................................
...........

4

1.3.2

Improvements over p
revious version

................................
................................
................

4

1.3.3

Availability of updates

................................
................................
................................
......

4

1.3.4

Incremental updates for Geoserver

................................
................................
...................

4

2

CONFIGURATION
................................
................................
..............................

5

2.1

Overview

................................
................................
................................
................................
....

5

2.2

Local configuration

................................
................................
................................
....................

5

2.3

Updates

................................
................................
................................
................................
.......

5

3

DEPLOYMENT ENVIRONME
NTS

................................
................................
.....

5

3.1

Current Status

................................
................................
................................
.............................

5

3.2

Configuration requiremen
ts

................................
................................
................................
........

6

3.2.1

Tomcat

................................
................................
................................
..............................

6

3.3

Other requirements

................................
................................
................................
.....................

6

3.4

Database availability

................................
................................
................................
.............

6

3.5

Risks and mitigation strategies

................................
................................
................................
...

6

3.5.1

Tomcat

................................
................................
................................
..............................

6

3.5.2

Deployment of multiple geoserver versions/ configurations

................................
............

6

3.5.3

XSL/Java

................................
................................
................................
..........................

7

4

DEPLOYMENT AND DEVEL
OPMENT PLAN

................................
....................

8

4.1

Environment Setup

................................
................................
................................
.....................

8

4.1.1

System Architecture
................................
................................
................................
..........

8

4.1.2

Configuration

................................
................................
................................
....................

8

4.1.3

Access arrangements

................................
................................
................................
........

8

4.1.4

Installation responsibili
ty

................................
................................
................................
..

9

4.2

Data Management

................................
................................
................................
....................

10

4.2.1

Responsibilities

................................
................................
................................
...............

10

4.2.2

Documentation requirements

................................
................................
..........................

10








Created on
7/01/2008 4:16:00
PM

3

of
11


1

Introduction


1.1

Context

.

The
AWDIP
project is

explicitly designe
d to exercise and consolidate a
capability for deliver uniform service interfaces to water monitoring data
.


This requires implementing agencies to be able to perform the following:



Acquiring and configuring an
OGC Web Feature Service
reference
implementations



Use of AWDIP data model and schema for water monitoring data



Deployment of service according to chosen access constraints.


Thus, this deployment plan does not address:



Registration of services



Conformance testing



Service lifecycl
e requirements



Enterprise Production environment testing, security, migration or
upgrade procedures or policy.


It does however provide some pragmatic guidance on possible approaches to
production deployment given the technical requirements.

1.2

Scope of this
document

The scope of this document is deployment for a single component of a
distributed system.


The component of interest in this document is a deployment of the Geoserver
technology acting as a Web Feature Server for water resources monitoring
data an
d related details within].


NB. This plan does not provide for implementation, security or testing of core
production systems and appropriate supporting infrastructure and processes
for management, maintenance and upgrade of the application.

1.3

Specific Deplo
yment Requirements

This component requires deployment of Geoserver against
JDBC
database,
which may be
resident on the same physical server
, or visible via a network connection. A suitable JDBC
driver library must be included in the geoserver build


the
build provided for this project
comes bundled with drivers for Postgres, Oracle, MySQL and SQL
-
server


The deployment will include a configuration of Geoserver that maps the
host organisations
database schema to an extended version of the AWDIP data model.

There is no requirement
to standardise database schemas.


The deployment will also include configuring Geoserver’s demo facility with relevant demo
queries to support documentation and testing of the installed service.

This is a matter of
editing availabl
e samples with content applicable for the local installation.








Created on
7/01/2008 4:16:00
PM

4

of
11

1.3.1

Geoserver
Version:


The version of G
eoserver to be deployed is
a customised bundling of modules from the latest
stable branches of Geotools and Geoserver (2.4 and 1.6 respectively)
-

specifical
ly

using the
geoserver 1.6 community/
community
-
schemas/web
-
c module. This module bundles a
modified wfs service handler and cloned administration and demo UI.


This version will be ultimately distributed from the geoserver sourceforge site as a
separate W
AR application, pending either the bundling of the capability within the core
geoserver build, or abiity to download it as a separate plug
-
in extension to the core
geoserver releases.


Currently the latest version and build documentation is available from:

https://www.seegrid.csiro.au/twiki/bin/view/Infosrvices/GeoserverCommunitySchemasDownloads




1.3.2

Improvements over previous version

The target implementation contains substantial improvemen
ts over the previous version
(“
geoserver
-
cf

branch of Geoserver 1,3)

deploy
e
d within the AWDIP testbed for the March 14
demonstration:


Notable improvements are:



Capable of handling unmodified OGC schemas


in particular Observations and
Measurements and ISO19139;



Streamlined configuration fil
e for community schema mapping
s;

o

Schema mapping does not need to manually include all relevant parent
schemas;

o

Separate Id mapping sections replaced by simple flag in attribute mappings;

o

GroupBy tags need only to identify a representative
set of columns;



XML Schema files need less “hac
king” (still under investigation, aiming for zero
hacking)



Aligned with

latest stable branches of Geotools geoserver,

o

common environment and installation instructions to be maintained
;

o

test cases included in build, minimising threat of loss of functionali
ty in future
versions
;

1.3.3

Availability of updates

It is expected that updates to the geoserver implementation will be available as geoserver
core matures, further testing and debugging of the
geoserver
-
c
modules
occurs, etc.


Geotools trunk is currently impl
ementing native capability to handle complex
schemas, so in future a special bundling of plugin components should not be
required.


1.3.4

Incremental updates

for
Geoserver

If small patches are supplied to fix issues arising, these may be published separately, ot
herwise a


Geoserver functionality can be updated by replacing supplied updates (
.jar
files) in
$Tomcat/webapps/geoserver/WEB
-
INF/lib.



To do this,

1.

stop Tomcat

2.

save old versions of files

3.

replace files

4.

start Tomcat







Created on
7/01/2008 4:16:00
PM

5

of
11

5.

test demo requests still work.


2

Configur
ation

2.1

Overview

Geoserver allows designation of a configuration (directory of files) that can be managed separately to
the bundled software.


AWDIP provides a sample configuration, and where available specific configurations for database
schemas managed by
individual agencies.


This configuration may be downloaded using Subversion from

https://www.seegrid.csiro.au/subversion/xmml/AWDIP/trunk/geoserver_conf/


the file geoserver/WEB
-
INF/web.xml

should be edited to set the parameter
GEOSERVER_DATA_DIR to the downloaded geoserver_conf


NB: conformance to AWDIP in
teroperability specification requires use of common controlled
vocabularies. These must be provided wi
thin the target database, except where the value is a constant
and can be introduced in the configuration.

2.2

Local configuration

The main requirement for local configuration is to make catalog.xml reference the right schema
mappings files. The sample catalo
g.xml provide make the locations of these files obvious.


These files should have appropriate database connection parameters and SQL statements. But should
require little or change to schema mappings.



2.3

Updates

Updates may be required from time to time, if

a change to the schemas is required for example to
include a model element previously unrequired.


Configuration is managed using subversion,


so it is possible to propagate incremental updates.
Typically it will be necessary to save the local catalog.xml

file.



3

Deployment environmen
ts


3.1

Current Status


Deployment environment owner to complete


Component

Recommendation/Supported

Actual

(record this for support puposes)

Hardware Platform :

Sun, PC


Operating System Version :

Solaris 8, Linux (specify dist
ribution), Windows XP


Apache Server Version :

Apache 2.x


Tomcat Application Version :

Tomcat 5.5 x


Apache/Tomcat Connector :

Reverse proxy

making geoserver visible on port 80


Java Version :

JDK 1.5 latest release


Java extensions

JAI and JAI imag
eIO 1.1.3


Database :

Oracle, PostGIS
, MS
-
SQL, MySQL








Created on
7/01/2008 4:16:00
PM

6

of
11

Graphics

Windows (native),
Solaris/Linux: XVNC


Components to be installed :

Geoserver build (
as documented)






3.2

Configuration requirements

3.2.1

Tomcat

The application parses significant XML schemas.
Consequently, the JVM must be configured to have
at least 512 Mb of memory available.


(syntax for this
on the command line is
-
Xmx512m. This can also be set in the windows Tomcat
service manager, under the
Java

tab)


Thread stack size of 1024Kb seems to
be satisfactory.


Benchmarking memory requirements unde
r different load conditions is a task to be undertaken, and the
results and recommendations will be made available
.


3.3

Other requirements

3.4


Database availability

Previously the

geoserver application must
be restarted if the database is restarted, or the connections
cached by geoserver are invalidated in some way.

The new build should recover, but further testing is
required to ensure robustness and freedom from memory leaks.

3.5

Risks and mitigation strategie
s


3.5.1

Tomcat


Tomcat 5.5 is recommended, as this is the platform that testing is mainly based on.


Later versions of Tomcat would be expected to work, but have not yet been tested.


Tomc
at 4.1.31 can probably be used, as previous versions were tested against

this platform,
but this has also not been tested extensively.


Tomcat
5.0.x

should
not

be used.


Further requirements or experiences testing with other versions of tomcat or other containers
should be communicated via the AWDIP project management.


3.5.2

Deplo
yment of multiple geoserver versions/ configurations

Geoserver
(
since 1.5
)

allows multiple deployments within a Tomcat context


i.e. /geoserver1
/geoserver2


It is recommended that, at this stage, only one geoserver instance per Tomcat install is used, to

assist
with scheduling version upgrades and isolating problems.


Each geoserver can be use a single configuration dirtectory. It is regarded as difficult to manage and
test multiple overlapping configurations within the same directory, in the absence of a

specific set of






Created on
7/01/2008 4:16:00
PM

7

of
11

benchmarked processes and policies to support this overhead. It is assumed therefore that each project
will identify either an upgrade to a specific configuration, or a new configuration, as appropriate.


This project will create a new con
figuration.


Responsibility for testing co
-
existence of multiple geoserver versions within a single Tomcat lies
outside this project. Advice on reporting and interpreting support requests and responses to the
geoserver development community will be provid
ed if required.


3.5.3

XSL/Java

The
Geoserver

build distributed

i
s compiled under JDK 1.5, and hence requires 1.5 or 1.6 to
run.


NB. Significant performance benefits over JDK 1.4 are reported.


NB Note that some applications (eg ArcIMS) may install legacy XM
L parser and XSL libraries
inside Tomcat. It is recommended to dedicate a Tomcat instance to each software component
to avoid the need of extensive compatibility testing.








Created on
7/01/2008 4:16:00
PM

8

of
11

4

Deployment and Development plan


4.1

Environment Setup

4.1.1

System Architecture

The underlyi
ng platform is a standard J2SE application accessing web services via standard OGC Web
Services/ASDI notional architecture.


All components are assumed to be properly decoupled using interfaces that would allow any
component to be replaced by an alternati
ve technology, version or custodian.


It should be noted that robust, continuous, secure network connectivity is the key requirement.

4.1.2

Configuration


No special modification of the base environment is now necessary to run geoserver under Tomcat 5.5.


Howeve
r, there are some requirements for configuration of the environment:

4.1.2.1

TCP/IP port

The service should be visible to the outside world via TCP port 80, since Commonwealth IT
infrastructure is restricted to accessing this one port.

A reverse
-
proxy using Apac
he is recommended, however there are many possible approaches and
CITEC should resolve this aspect.

4.1.2.2

Resolvable hostname

It may be necessary to ensure that the Tomcat “context” is configured to recognise its
hostname

as the
same name the service is visible
as from the public network.


I.e., if the service is to be called from
http://services.myhost.org

then the tomcat context must be
configured to recognise this at the deployed context name, either from the defaul
t hostname (the
machine knows it is called
services.myhost.org,
or by explicitly configuring Tomcat to enforce this.


i.e. when geoserver advertises its URL in the capabilities document, or in the demo pages as the URL
the semo request gets sent to, this U
RL must not map to an internal hostname. It gets this hostname
from the standard Servlet context.


For more information see
http://tomcat.apache.org/tomcat
-
5.5
-
doc/config/host.html
.


Quick check: deploy geoserver and access the capabilities document, eg


http://myhost.org/geoserver
-
c/ows?service=wfs&version=1.1.0&request=GetCapabilities

4.1.3

Access arrangements

The deployment team will need access and user privileges that allow:

1.

stop/star
t Tomcat

2.

install WAR files

3.

clean up Tomcat work directories (there seems to be an occasional need to do this
when updgrading)

4.

Edit text files to configure applications.








Created on
7/01/2008 4:16:00
PM

9

of
11

4.1.4

Installation responsibility

Agencies are responsible for deployment, however support i
s available as required. Agencies are
responsible for nominating a point of contact and initiating support requests.







Created on
7/01/2008 4:16:00
PM

10

of
11

4.2

Data Management


All data that needs to be migrated, extracted, installed etc for the purposes of getting a pilot
implemented in minimal t
imeframe should be noted here.



The goal is, however, to implement a complete set of interoperable Web services using OGC
standards, however some services may be simulated using static XML files.

4.2.1

Responsibilities

Agencies
will undertake data manag
ement a
ccording to requirements of providing an efficient
query against the content specified by the AWDIP process.



This includes supporting AWDIP controlled vocabularies where appropriate, in particular
common parameter names and parameter groupings.

4.2.2

Documenta
tion requirements

Sample data is to be
p
rovided to support troubleshooting and configuration advice. This
sample data should recreate the exact database table structures being used.



5

Configuration and troubleshooting process

5.1

Overview of configuration

The
hard part of configuration, creating featureTypes that map database queries to GML schemas is
provided within the subversion controlled Geoserver configuration template.

Each agency has to ensure that it has database content that matches the external expec
tations
(parameter names in particular). Materialised views are required for efficient reporting of sampling
availability.


The main config path is:


Catalog.xml
-
> featureTypes/myFeature/myschemaMappings.xml (containing refs to schema + JDBC
connection +

SQL statement )


What follows is some hints and tips about how to set up the details and test and troubleshoot.


The longer term goal is to get Geoserver to report errors better.


5.2

Database connections

It is recommended to use a Java
-
based database brows
er, such as DbVisualiser, to test the
exact

combination of connection credentials and SQL statement:



User



Password



JDBC driver



JDBC connection string



Select statement.


(These connections are currently in the featureType/*/*_schema_mappings.xml files).



5.3

Catalog.xml

This needs to be edited (or chosen from supplied tested configs) to reference your local schema
mappings files.







Created on
7/01/2008 4:16:00
PM

11

of
11

Tip: set enabled=”false” for all but SiteLocation config while debugging database connection.

5.4

Checking config:

Run the GetCapabilit
ies demo query.


NB status bars in the Geoserver test harness should be green for all enabled datastores. Grey means
there are some disabled (by configuration). Red means a configuration failure for an enabled datastore.


5.5

Logs

Logs are generated in the Ge
oserver_conf/logs directory (unless you edit the properties files
in this directory).


Make sure that the Tomcat process has write permission to this directory.


Recommended troubleshooting process:



Stop tomcat



Delete geoserver.log



Start tomcat



Examine geo
server.log for errors