Bruce,
Consider the following:
One "project" using good configuration management techniques should have
areas for:
Development - where the programmers dream up the code
Integration - where the developers code is brought together
System test - where the whole issue is tested for compliance to the spec
Released - which is a "development system copy" of what is sent to
production to facilitate testing future bug fixes while the next release is
prepared.
A project based web area where project based documentation and information
can be maintained as both development and released versions
A customer acceptance test area
A training area
Each of these instances may have one of:
A database
A www area
An area for developing the code
An Archive log area for the database
An Administrative area for the database
An Export area for the database
A configuration management tool area
All of these area's have to be set up so the correct ownership and access
rights are maintained to stop for example:
Developers code from inadvertently accessing any other area and vice versa
One projects members from accessing another projects areas
Access via a web listener giving inadvertent access to other parts of a
directory tree/system. I.e. it is treated like a production system in this
aspect.
Efficient use of resources e.g. not having one web listener per project.
All of these areas need to have space management so something running amok
in the developers area will never fill up or inhibit the space allocated to
system test for example.
By simple rules it is not a good idea to have database and archive logs in
the same location nor should you put exports on either of these locations.
The database is Oracle and an OFA compliant structure means the admin side
is somewhere else in the tree. We use this to put the "second" control file
on a different volume - as is good database practice.
When it comes to snapshots database areas typically on a development system
get changed, not often, but when we delete a database I do not wish to have
to wait until the snapshot rules we apply to code development areas expire
before I can recreate or restore that database from a backup.
Each project may have up to five parallel iterations each of which is a
replica of the above.
Each instance of the application when a project runs shall only "talk" to
its appropriate bits and pieces. I.e. hopefully the code that runs in the
integration area will not talk to the copy of the system test database (and
vice versa)
Some other constraints:
Operating system upgrades should not impinge on development work
Other software upgrades should not impinge on development work
The development process when taking on upgrades should be able take on the
upgrade as the appropriate software progresses through the life cycle e.g.
first development, then integration etc. etc.
One project should not be able to interfere with another project space
allocation wise.
Projects should be easy to add, delete and archive (archive = when no longer
required)
New projects should be up and running with full blown facilities as quickly
as possible
Use resources efficiently
Be run with the minimum number of administrative staff.
When you then say 100 projects and we are still growing, with getting on for
250 databases (for good reasons projects do not have all the bells and
whistles above - but we have to be able to cater for tomorrows request! -
you know what developers are like...) on two filers maybe you perhaps begin
to see a little more of the problem. We have a design which is working well
at this time but we perceive we will not be able to grow this "shape" of
implementation of very large disks for the reasons stated.
In the end we may have 1000 or more projects - please pass the aspirin I
have a headache.
Ray
-----Original Message-----
From: Bruce Sterling Woodcock [mailto:sirbruce@ix.netcom.com]
Sent: 19 October 2000 19:43
To: ray.griffith; toasters
Subject: Re: Using large disks on Filers
You're out on a limb. There's no need to do the segmentation you
are describing.
Just combine some projects together in the same volume and let
them share the same snapshot schedule and possibly the same
quota tree. This really should not be a problem.
Bruce