phasing out Solaris/Oracle/Netscape with Linux/PostgreSQL/Apa che

[Jesse Eversole]

Mark Hahn <hahn at coffee.psychology.mcmaster.ca> writes:
> [someone writes]
> > [someone writes]
> > > do I absolutely, positively need SCSI? I was thinking about putting a
> > > second 100 EIDE host adapter in, and run disk striping plus mirroring
> > > over 4 EIDE hard drives (the better models from IBM).
> >
> > SCSI is GREAT, and you should set up redundant hot swaps so if you
crash,
> > you insert a new disk, type "boot", and you're back online with a node.
I
>
> uh, that misses the whole point of raid, which is to survive hard disk
> failures.  "survive" as in "not crash, keep functioning".  raid1 or 5
> built on IDE disks do this *just*fine*.

>You should probably explain about hot-swapping off-the-shelf IDE
>disks.  I've heard it's not a problem at all under Linux if the disks
>are not presently being accessed, but I don't have the personal
>experience to corroborate this.

Last fall we elected to migrate from a collection of separate SCSI disks
mounted
in a separate SCSI disk cabinet to a RAID array.  In addition to the
fault-tolerant
and performance properties of RAID systems, we needed to escape the space
limitations
and file system maintenance time associated with adding separate disk drives
to our
environment.  Although it might seem that building our own array with a
cabinet,
RAID adapter and drives would present us with the best price, we were very
concerned
that a "homegrown" solution could end up costing us dearly in system
administration resources should we encounter even the simplest snag in setup
and operation. We,
therefore, excluded these type of solutions.

We determined that 200 gigabytes of effective space would meet our needs for
18
months and began exploring the market for hardware solutions.  We asked a
local
supplier, Stay-Online, to cost a solution, we looked at Dell and we explored
other
solutions on the web.  Robert Brown turned us onto the Zero-D solution and
the new
method of using ide disks inside with a SCSI interface outside.  There is no
question
that SCSI drives are higher quality, however, we have found the Maxtor ide
drives to
be quite reliable over the last two years.

In our research, which I make no claim to be complete, nothing came close to
the
Zero-D.  We went with the least expensive latest model (400AV) that uses ide
drives
and presents a SCSI interface.  There are six slots in the cabinet that
could
handle 80 gig drives at the time.  We populated the array with six 60 gig
Maxtor drives configured RAID 5 with one hot spare.  If you can justify a
hot spare this gets you
out of the hot swap problem since the array shifts to the hot spare
automatically
and you hot swap an off-line drive.  The cost differential between 60 gig
Maxtor
drives and say Baracuda SCSI drives is significant.

We bought the drives from the dealer, let them install and execute burn-in.
The array
was shipped to use populated and ready to go.  It took me about two hours to
install and
configure the array from the front panel (I did not want to mess with any
software) RAID 5 one hot swap drive.  I let the setup process run overnight.
The next day I created a file system on the array as if it were a single 200
gig drive, it simply shows up to linux like it is a single drive.  After
that I was done with setup and installation.

The total cost of the hardware was $4,800 and the sys admin time was maybe 5
hours.
I figure that's about $24/gig (4800/200).  Setup time was little more than a
single
drive. A comparable array from Dell would be about twice that and it can go
up from there. So far the array runs like a champ.  One thing not to
overlook is the backup strategy for a larger storage space.  If you want a
hands-off backup environment then there is definitely a lot of
considerations between cost and performance.  If you have decent backup
hardware with the Solaris system then you might be able to use it with the
new system you are building.  We are still looking for the right backup
solution.

With regard to software. We consider developer time the most expensive
resource and
use the most productive development tools until performance needs require
otherwise.
We prefer Perl for database applications and CGI.  We do not like carrying
around a
compiler if we can avoid it.  We also like memory management done for us.
It allows
us to concentrate on the application.  My personal experience with Perl is
that I can
get a program running and debugged about 3 to 4 times as fast as with C or
C++.  Perl's
weak typing is particularly useful for moving database files from one
environment to
another.

Although I like Oracle as a database platform, I find it an expensive pain
to
setup and manage.  For that reason we use lower overhead database solutions
until we
are required to use Oracle.  If you have plenty of labor resources for dba
work from
the beginning then Oracle may be ok.


Jesse Eversole
Market Driven