I see you've gotten a lot of suggestions already - I'll chime in with a few
more from an OS/390 perspective.
1) CPU utilization. (Can you spell STUCK?)
This is obviously something that has to be fixed, if it's really your
bottleneck. I don't know how conversant you are with mainframe tuning
parameters, but OS/390 is normally tuned to limit the amount of the CPU each
application uses. Are you sure the processor is really out of gas, or is
ADSM just not getting a big enough slice of the pie? Beat up on your OS/390
sysprogs to see that you get more cycles for ADSM. If necessary, run a test
have them give you unlimited CPU temporarily while you try a sizeable
restore, see if it makes a difference. If not, and the CPU is pegged at
100%, then actually consider getting a CPU upgrade. I don't mean for that
to sound flip, I know now difficult that can be. BUT, if you happen to have
one of the newer CMOS-based processors, buying more processor could actually
be CHEAPER than replicating a bunch of DLT tape drives and all their
associated maintenance costs, believe it or not.
2) Network bottleneck
Are you sure that your network is the problem, or is it just the gateway to
the mainframe? A simple test - Take a sizeable file, say 300-500 MB at
least, on one of your Windows servers. FTP it to another WIndows server.
Repeat several times to be sure you get consistent transfer times. Now FTP
the same file to the mainframe. If the problem is really the network, you
should get the same average transfer time to the mainframe host, as to
another host on the network. If the mainframe transfer is slower, then the
problem is mainframe-specific.
If your problem is just the gateway to the mainframe, not the entire
network, again that is cheaper to upgrade than replicating multiple tape
drives. If it isn't the gateway, check into your mainframe TCP/IP service
levels. You didn't specify your OS/390 level, but most people saw
substantial improvements in the performance of OS/390 TCP/IP when upgrading
from OS/390 V4 to V5 or above.
Other than that, you may really be stuck. Most really large servers have
multiple drives backed up, and you can greatly improve restore times by
collocating at the filespace level and starting multiple restore streams.
That won't help in your case if CPU and Network are the bottleneck.
Also, the new TSM 3.7 feature of Lan-Free restore is designed to get around
network limitations. You have the ADSM server dump all the data required
for restores onto a tape, and then physically move the tape to the client
and reload the data on the client's tape drive. But that is not likely to
be useful for most OS/390 shops, since most will not likely have media that
is compatible between the OS/390 server and the ADSM clients.
Beyond that, I would at least consider moving the ADSM server to an AIX
host, before decentralizing the backup function again. What gives me
nightmares with decentralized backups is the implications for DR. I REALLY
HATE to have all my DR tapes running lose in dozens of different places
where people can spill coffee on them...
Good luck.
Hope this is useful to somebody.
************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu
"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************
> -----Original Message-----
> From: Chris De Bondt [SMTP:Chris.De.Bondt AT DVVLAP DOT BE]
> Sent: Tuesday, January 11, 2000 10:04 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Using ADSM to back-up large volumes
>
> Hi,
>
> I've a general question concerning back-up strategy and 'how-to-use' ADSM.
> Several years age we started using ADSM to back-up our LAN servers because
> we were seeing an unstoppable proliferation of LAN back-up hardware
> attached
> to those servers, and an unacceptable growth of the manual operations that
> come with that.
> Since then, of course, our LAN environment has grown tremendously, and
> right
> now we find ourselves in the following situation:
> - ADSM 3.1 on OS/390 as server environment
> - +/- 500 GB of LAN data, on some thirty Windows NT application servers
> and
> 5 Novell Netware file servers
> - daily bacup schedules that back-up about 20 GB of changed data (in
> total)
> - mainframe - LAN connection: a 100 Mbit OSA card for the NT clients, 16
> Mbit TR OSA card for the Novell clients
>
> In this situation, backing up the changed data is not really a problem:
> the
> longest back-up schedules run 2 to 3 hours. The problem is: data restore.
> The fastest performance we're seeing for data restore is +/- 2 GB per
> hour,
> this is for collocated clients. (Non-collocated it's dramatic ...) If we
> want to restore clients with 30 GB or more data on it, we'll need at least
> 15 to 20 hours to bring the client back up. As you can imagine, that kind
> of
> downtime is unacceptable. The problem is that I've run out of ideas of how
> to substantially increase the restore performance, the most importance
> bottle necks apparently being the network and the CPU utilisation on
> mainframe. So now we've come to a point where we are seriously considering
> again attaching DLT drives to our larger servers and backing them up that
> way ... back to where we came from, as it were ...
>
> So, a very long explanation just to ask this simple question: are we
> overlooking something ? What are you guys out there doing to back-up all
> those gigabytes of data and how do you manage to restore them without
> sending all your users home for 2 days ?
> All ideas are welcome.
>
>
> Chris De Bondt,
> DVV System Engineer
>
> Tel: 02/286.68.29
> fax: 02/286.71.60
> chris.de.bondt AT dvvlap DOT be
|
