From: tmorris@sph.unc.edu (Thomas P. Morris)
Newsgroups: comp.sys.novell,bit.listserv.novell,comp.arch.storage,comp.periphs
Subject: Re: Server Fault Tolerant H/W Sources Sought
Date: 6 Jan 93 23:39:50 GMT
Organization: UNC School of Public Health, CAIS
X-Useragent: Nuntius v1.1

In response to my query for sources for fault tolerant hardware for our
NetWare file server.....
In article <1993Jan05.142247.27619@rchland.ibm.com> Del Cecchi,
cecchi@rchland.vnet.ibm.com writes:
>
>1.5 GB is only one drive, worth about 2500 or 3000 bucks.  Do you really need 
>the fault tolerance?  MTBF of modern drives is in the hundreds of thousand
hours
>range.  RAID seems like swatting flies with a sledge hammer for this app.
>

Yes, Del, I -really- need at least -some- form of more-or-less
automatic-failover
fault tolerance, though you are right that RAID seems like "swatting flies." 
RAID is only one of the options I am looking at; what I am trying to do is to
perform a costs-benefits analysis vis a vis different levels of fault
tolerance in hardware and software.  Some of
the current options available (duplexing, mirroring, RAID, the ability to
"swap" out
components without shutting down the system) are really -not- that expensive,
and
provide for nearly 100% availability during scheduled uptime. 

If you read the entirety of my original article,  I wrote:

>[...some material omitted...]
>This server serves ~90 DOS & Windows clients, 60-70 simultaneously attached 
>including 6-7 HP printers with JetDirect print server cards. We have NW4MAC
support 
>loaded and will shortly attach ~30 Mac clients and  3-4 AppleTalked
LaserWriters. >Longer term, we expect to have > 200 total client machines in
the next 6-12 months, 
>and up to 300 or more client machines beyond the next 12 months, and up to 30
more 
>printserver-style queues.  In terms of storage needs,  I would expect to need
to 
>upgrade to ~1.5Gb storage in the next year (not including mirror or duplex
drives),
>with up to 3Gb needed in the longer term.
>[...]

 For my "client" users, this server is the -only- place from which they can
launch
 their word processors, spreadsheets, comunications programs, etc.  It is also
the
 =only= place to which they can print their results.   My main concern,
then, is =not= 
to piss off the >200-300 client users by having =any= form of "major"
unscheduled downtime.

If I have -no- form of faul tolerance, or if if -do not- keep a "hot spare"
disk and/or
server CPU available, then what do I do =when= (not -if-) my CPU or disk
controller
or a disk fails?   The Manufacturers'  rated MTBF ratings notwithstanding, 
what is
=most= important to me (and to my clients) is the MTTR (mean time to repair). 
A
rated Mean Time Between Failure (MTBF) is just that:  within that rated time,
one
half (50%) of components of this type =will= fail.  In some shorter period of
time,
some smaller percentage of these components =will= fail.

If I have to wait a week to replace a CPU or a disk, first I lose my clients,
and then I 
lose my job.  If I setup a server so that single or even multiple components
can fail,
and only barely affect my clients, my clients are happy, and I am happy.  If
these 
components can fail, and if I can swap in replacement hardware without having
to
"down" my server, or if I only have to "down" the server for a very brief time,
I'm even happier, and so are my clients. I'm happy  -because- they are happy,
and 
because I can keep my job.

Now, back to the mention of "swatting flies."  Let's look at some ballpark
numbers.
A 3-1Gb drive, 3-controller, RAID 5 implementation with ~2Gb of available user
disk
space from one vendor runs in the $11,000 range.  A standard NetWare "disk
duplexing"
configuration with 4-1Gb drives and 2 controllers costs in the $9,000 range.,
about
20% less expensive.  If I understand RAID 5 correctly (which I probably don't
:-), 
expanding this configuration to 3Gb of available space by adding 1 additional
1Gb
drive, only costs me ~$3500 more; doing the same upgrade with duplexing costs
me
~$5000 more.
Newsgroups: comp.sys.novell