ADSM-L

Re: Need some planning help

1995-02-14 16:19:40
Subject: Re: Need some planning help
From: Kostas Piperis <"Kostas.Piperis~piperi00"@MHS.US.SWISSBANK.COM>
Date: Tue, 14 Feb 1995 16:19:40 -0500
Hi all,

We have sort of a similar setup like the Paul Z.(Cornell). I have configured an
RS/6000 with 64MB of RAM and 8GB internal scsi drives. I'm mirror the database
and recovery log on different disks. My primary storage pool(disk), is
approximately 3.4GB and the rest is allocated to AIX and ADSM.

I'm also using a LAGO as the next storage device for migration. We have OS/2
Novell clients. With the OS/2 clients we backup between 1.2 & 1.4GB per hour,
where the Novell clients 1.0GB per hour. When performing incremental, ADSM
flies!!

However, due to our disaster recovery requirements, we need to EXPORT 25GB of
active files off-site on daily basis!! This is very demanding on resources. To
accomplish this, we added another scsi channel and added 4 Exabyte 8505 external
tape drives.

As you probably know, ADSM Export is single threaded, and with all the devices
we added we can do 2 exports at the same time. The Lago will mount 2 tape
volumes and write to 2 of the external 8505s.  This is very time consuming since
we have to account for other processes (i.e. migration, etc.).

So, what we did, we created several schedules and in between them we also start
an export. It seems to work O.K. (ofcourse after having ADSM development make
enhancements to the export function). It takes about 16 hours to complete the
export.

We are considering in altering our setup within a month or so. Due to our needs,
we are thinking of buying a 50GB RAID 5 storage device (disk) and making that
our primary storage pool. Therefore, all of our incremental will go on disk and
any restores will be retrieved from that disk. Moreover, when we have to do our
exports we can utilize 6 tape drives, the 2 internal drives (Lago) and the 4
external 8505s. We believe we can cut our time in half since exporting from disk
to tape is faster then from tape to tape.

For performance on the export, we are getting approximately a 1GB an hour,
sometimes more (it really depends...).

We are also waiting for release 3 with the copy storage pool feature!!!! From
what I understand, we will be able to perform incremental "exports".


I hope this helps. I'm curious to know what others are doing for disaster
recovery.

Paul Z., I would be interested in looking at you Rexx script. We have are
putting something similar to yours together.


regards,

Kostas Piperis
Swiss Bank Corporation
212.574.3142 (voice)
212.574.5449 (fax)
______________________________ Reply Separator _________________________________
Subject: Re: Need some planning help
Author:  ADSM-L (ADSM-L AT VM.MARIST DOT EDU) at smtpgw,0,smtp
Date:    2/14/95 2:47 PM


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>