ADSM-L

Re: Need some planning help

1995-02-14 14:47:17
Subject: Re: Need some planning help
From: Paul Zarnowski <VKM AT CORNELLC.CIT.CORNELL DOT EDU>
Date: Tue, 14 Feb 1995 14:47:17 EST
On Tue, 14 Feb 1995 13:34:41 EST Dave Re said:
>     Hi all.
>
>     I need some help from those of you who have experience with ADSM
>on the AIX platform, specifically RS/6000s. What I'm primarily interested
>in are performance and machine size issues. The best information you could
>send to me is the configuration of your RS/6000, the amount of data that you
>back up, what kind of tape device(s) you use, the size of your tape pool,
>and an evaluation on how well you think this configuration handles your
>load.

We run ADSM/6000, and I am also interested in other folks responses.  We
run our server on an RS/6000 41T (PowerPC), one LAGO Datawheel (2 8mm 8500c
tape drives inside), and 9 GB of SCSI disk across 2 SCSI channels.  We have
1 1GB internal SCSI disk for AIX + ADSM Software.  The rest are all 2GB
Baracuda SCSI disks 2 each on 2 different SCSI channels.  One channel also
has the Datawheel on it.  We have one ethernet connection.

We have 119 registered nodes, store just under 50GB, and back up about 1GB
per night on average.  I ran a network analyzer on our network one night to
see how much of a load there was, and it looked promising.  The average load
was in the range of 10-20% for 2-3 hours, so I see much room for growth in
network load.  We also have the option of upgrading our ethernet connection
to FDDI, and even have the option of up to 4 network adapters that ADSM/6000
can support.  We feel that it is important to have a large enough disk
staging area to handle most, if not all, of the night's data transfer.  We
don't quite accomplish this every night, and often see a migration process
triggered during the night when all of the backups are running.  We have
not yet set up a cron script to cause the migrations to happen during the
day or early evening, but we do plan to do this.

One problem that we ran into was that whenever a RECLAIM or MOVE DATA
process was running (tape to tape), user file recoveries were often delayed
for hours.  This is because of the relatively slow speed and high capacity
of 8mm tapes.  To address this problem, I wrote a Rexx exec which wakes up
every 15 minutes and checks for this situation.  When it occurs, the exec
will cancel the MOVE DATA or RECLAIM process to allow the user file recovery
to run.  Later, it will restart the MOVE DATA.  (ADSM will automatically
restart the RECLAIM by itself).  It'd be real nice if the Datawheel had a
third tape drive, but it doesn't.  We are also looking into the possibility
of adding a 3494 to this server, and we are hopeful that this configuration
(upgraded to FDDI) will be able to handle the data throughput needs which
will be associated with this much data storage capacity.

You asked about size of tape pool.  The datawheel holds 54 tapes.  At about
4.4GB each, we have only used a fraction of its total capacity.  We do not
plan to have operator tape mounts, but rather will use all robotics.

What we have now works adequately for the load we have now.  I am concerned
about what problems we might encounter as our load increases.  I am
especially concerned about how much time it might take us to recover from
a database problem, should one occur (I'm knocking on wood).

We duplex all of our databases and logs, and I strongly recommend this to
everyone, whatever platform they are using.  Make sure they are spread
around adequately across disks, and controllers if possible.

Hope this helps some.  I also look forward to seeing others responses.

..Paul

Paul Zarnowski                     Phone:   607/255-4757
Cornell Information Technologies   Fax:     607/255-6523
Cornell University                 US Mail: 315 CCC, Ithaca, NY 14853-2601
<Prev in Thread] Current Thread [Next in Thread>