Our MVS adsm (while we were running it) took a LOT of MVS tuning...
we had OSA and even ran an isolated TCP/IP for ADSM...
AIX servers (for our use) were just better !
Dwight
> ----------
> From: gail johnson[SMTP:johnson_gaila AT HOTMAIL DOT COM]
> Reply To: ADSM: Dist Stor Manager
> Sent: Wednesday, January 12, 2000 12:35 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Using ADSM to back-up large volumes
>
> Nathan -- I couldn't agree with you more on this subject. Right on the
> money!
>
>
>
>
> >From: Nathan King <nathan.king AT USAA DOT COM>
> >Reply-To: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >To: ADSM-L AT VM.MARIST DOT EDU
> >Subject: Re: Using ADSM to back-up large volumes
> >Date: Wed, 12 Jan 2000 11:38:17 -0600
> >
> >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
> >
> >************************************************************************
> >
> >
> >
> >
> >
> >
> >
> > > -----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
>
>
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>
|
