Those are good comments Wanda.
We have a mix of OS/390, AIX and NT here for ADSM Servers. I'm afraid that
our OS/390 servers are by far the worst performing of all the ADSM Servers.
I'm not going to even pretend to know a lot about OS/390 but I can attest to
Wanda's comments about CPU util and the Network.
The problem with upgrading the CPU on OS/390 is that it in a lot of cases it
also pushes up the costs of all the other software that might be running
within the same LPAR (depending upon your software agreement and setup).
Most software costs in the mainframe world are dependant upon how many MIPS
you're consuming, therefore as soon as you add more MIPS to let ADSM perform
better you end up paying more for all the other software. A real catch22.
Another thing that you can do on OS/390 is allow a started task to use more
memory. You could talk to some of your mainframe guys to see if the ADSM
task has been capped at a certain memory limit and increase it if necessary.
Tuning TCP/IP on OS/390 appears to be somewhat of a black art. TCP/IP is
improving all the time on OS/390 but I doubt it will ever reach the
performance of TCP/IP running on it's native platform - Unix.
I do recall seeing better performance when we had our MVS sysprogs reserve
the TCP/IP ports (e.g. 1500) for use by ADSM. You're lucky to have an OSA
adapter - we live in the world of SIP routers which is even worse.
The implementations of TCP/IP on MVS have improved with time, but as we
upgraded TCP/IP to improve performance we often ended up chasing stability.
It's worth going through the list http://www.adsm.org as I know that a lot
of people in the past have suggested improvements that have helped their
TCP/IP performance on MVS.
The bottom line however is that if you really want to get performance and at
the same time get good performance for money then the long term solution has
either to be rehosting ADSM on either Unix or NT. You only have about 35
clients total, so an ADSM NT Server might be your best long term investment.
It's certainly better than going back to attaching DLT drives to servers.
This is just downright hideous when it comes to administration, bad in terms
of costs and you often end up using one of those other cheaper backup
products which I wince to mention.
Good luck,
Nathan
-----Original Message-----
From: Prather, Wanda [SMTP:Wanda.Prather AT JHUAPL DOT EDU]
Sent: Wednesday, January 12, 2000 10:06 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Using ADSM to back-up large volumes
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
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
|
