THANKS everyone...
This discussion couldn't have come at a better time. We all have our own
opinions of ADSM, TCPIP, ADSM running on S/390, etc and what is the BEST
way to conduct this venture, but unfortunately there is no single solution
given everyone's different environments. However, having this kind of
public input along with IBM's (or Tivoli's) advice I am pretty confident
that we can make this work.
Having no ADSM experience until about a year ago I embarked on a
"centralization" effort (there's that "C" word) to bring open systems
backup into our MVS world to leverage our existing legacy systems to help
improve the overall scope of backup services for the growing client/server
world we are building. This was also done to help the system admins
concentrate on other issues needing more focus. So far so good although
there were many pains along the way -- some being addressed in the attached
emails.
My environment is similar to those previously discussed (see attached):
200+ servers (all kinds) across an in-house corporate Ethernet (100 mbs)
linked to a CISCO router then to an ESCON channel to an LPAR in one of our
production sysplexes. Not being a network person I don't want to elaborate
any further on this architecture. OS/390 2.5 with TCPIP 3.4 and ADSM
3.1.2.0 (with ADSM the only user of TCPIP), various vendor's disk storage
and Magstar 3494's for both my primary and electronic-vault copy pools.
Currently, I am pushing about 90-120 gigabytes a night across a
prompted-schedule spanning from 18:00 to 04:00 with a scheduled reset of
the disk pool threshold to force migration at 05:00 to my primary tapes.
This is followed by a backup of the primary tape to the copy pool. I also
run a secondary disk-to-tape-to-copy tape process later in the day to
capture any later running backups that may have taken place outside the
normal backup schedule.
Once all of this is done I run a daily full DB backup which goes directly
to the vault. When this is done I run a PREPARE (DRM) to capture all the
business of the day, and I then backup the PREPARE output with Sterling
Software's SAMS:disk creating a primary and vaulted tape backup. This
costs about 10-15 MIPS a day with limited spikes no higher than 25 MIPS.
Because I have many tape drives I can run multiple processes at once and
still leave room for space reclamation to run whenever ADSM decides to do
this.
The ADSM server address used by the clients is a "logical" name managed by
a Domain Name Server. This allows us to hot swap the ADSM server to
another LPAR if necessary without forcing an address change at the client
end (only one call to the Networking help desk (24x7) will take care of
this -- OK, maybe two calls!).
This backup process mimics almost exactly the process used to backup
another S/390 production environment (two sysplexes / 8 LPARS - 700 clients
(each with its own CICS & batch flow) across about 8.5 terabytes of disk)
that also provides backup to disk (in a much larger amount) followed by
migration to primary and copy (electronic vaulted) tape. This helps
establish a "centralized" / "same approach" theme for all of the backup
services regardless of the environment.
Having said all of this, no matter what BIG or small technology solutions
are in place, my conclusion is if the "network" doesn't move the data no
one really cares what is going on behind the scenes. If someone hears that
it took "n" hours to move a relatively small amount of data (no matter that
the backup occurs during the night when "n" hours fits into an established
"x" hour window) the perception is that ADSM is slow. However, if multiple
concurrent backup sessions are running and delivering approximately 10
GB/hr throughput (roughly 100 GB in 10 hours which is what I am getting) I
don't consider that too bad considering the current limitations of the
"pieces" (i.e. Ethernet handshakes to ESCON, TCPIP on MVS and ADSM) that I
am working with.
I have tuned many of the ADSM parameters (some as a result of reading these
emails -- so thanks for the input) and we have a team focusing in on all of
the components (or "pieces") that seem to be leading to the perception of a
slow ADSM. One of the main things we have found is that the ESCON channel
is saturated just as someone else pointed out on this discussion list
before. The thought here is that channel utilization is very high, but the
amount of actual ADSM data is small because there is a problem with packet
sizes traversing the Ethernet and being dropped on the ESCON channel.
Small Ethernet packets don't travel well on ESCON and there is a lot of
channel overhead (extra bytes wrapped around them) added on. TCPIP on MVS
doesn't react well to this which then translates to a slower hand-off the
ADSM then one would like. We are looking at changing the packet size
within TCPIP to a larger amount to alleviate some of this bottleneck.
Remember, I am not a networking person so some of this description might be
a little off, but what before was being pointed out as a flaw with ADSM (it
is just too slow) seems to be moving out to the network as being the cause.
I wish I had more details, but I am only beginning to peel back the layers
now having spent a lot of time prior getting the process in place. If
anyone has any other observations on how they improved throughput in a
similar environment I would like to hear them -- maybe others would as
well. I am trying to solve the throughput problems (or at least get a
better understanding of them) because we will soon be building another ADSM
server to service a growing remote server business offering (customer
servers are centralized here (they have remote access to them) and backup
services are driven at the mainframe end). If anyone has
suggestions/experiences to share regarding multiple ADSM servers that would
be great. Has anyone run multiple TCPIPs on a single system? Multiple
ADSM servers on one system? We are at the early stages of trying to figure
out how best to do this.
Jim Hood (Shared Medical Systems (SMS) Malvern, PA)
---------------------- Forwarded by Jim Hood/SMS on 03/05/99 02:34 PM
---------------------------
---------------------------
Tjeerd Saijoen <tsaijoen AT BFSORG DOT COM> on 03/03/99 10:44:09 AM
Tjeerd Saijoen <tsaijoen AT BFSORG DOT COM> on 03/03/99 10:44:09 AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: Jim Hood/SMS)
Subject: Re: ADSM Server on MVS
Performance
To get the optimum speed out of ADSM you need to tune every component,
hardware, software, interface cards, adapters, routers, network and
clients.
Look first to the slowest component within the route from server to client.
Mostly speed is limited somewhere in the hardware but you can work around
this by adjusting and using buffers. At the moment I am busy to tune
several
ADSM sites. Round the end of March I will be hosting a website for ADSM
performance and tuning. Everybody who has tips, scripts etc can e-mail them
to me and I will place them on the web site available for downloading.
Regards Tj
www.bfsorg.com
tsaijoen AT bfsorg DOT com
|
