Kevin Balmer puts forth:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Forwarded letter follows =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This is targeted at Novell servers but would apply for other platforms =
as well.
I'm looking for feedback concerning logical volume size and =
configuration of the
DASD for file placement.
The problem I'm running into is our Novell guys have kept adding to SYS =
and we
have some 18GB SYS volumes. I've recommended keeping just system data on =
a SYS
volume and having multiple DATA and PROGRAM volumes no larger than 4GB =
each to
facilitate backup and recovery. Since ADSM locks at the filespace =
(logical
volume), multiple restores could be threaded in the event of a full =
server
restore. I'm meeting resistance to that suggestion. For Novell we =
average about
800 MB/hour with ADSM and these 18GB servers take way too long for a =
recovery
the way they're currently configured. How are others handling very large =
single
volumes with ADSM?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Forwarded letter ends =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<insert $0.02 here> In general, I am of the opinion that before =
implementing any kind of system, the ability to back it up and restore =
it within the required time frames should be part of the planning. =
Unfortunately storage management issues, in general, are almost always =
overlooked when planning new systems.
I've run into problems doing multiple recoveries with ADSM; in =
particular when both iterations of the ADSM NLM want to access data on =
the same tape, whichever got their last has to wait for the first =
iteration to free it up. So sometimes multiple recoveries aren't as =
efficient as they might seem (it would be nice if ADSM could detect the =
tape volume is in use, go on to the next tape, then go after the first =
tape later).
The foregoing notwithstanding, 18GB is huge for a single volume, even by =
mainframe standards. So the idea of breaking it down to more =
workably-sized volumes makes some sense.
In the case where you have to be able to restore large volumes very =
quickly, you might want to consider complementing ADSM with LANRES/MVS =
or LANRES/VM (another IBM product). With LANRES, you can create NetWare =
disk images out of mainframe 3390 DASD. Assuming you channel-attach the =
NetWare server to the mainframe, performance of the 3390 NetWare disk =
images is virtually indistinguishable from "real" NetWare disks. But the =
advantage is that you can use mainframe utilities (i.e. DFSMS/dss) to =
back up and restore the NetWare disk images. DFSMS/dss is a high-speed =
datamover that can back up and restore several gigabytes of data in a =
matter of minutes (i.e. under an hour). So whereas it might take ADSM 5 =
hours to restore 2 GB of data (these numbers depend on your =
installation), DFSMS/dss can do it in around 30 - 45 minutes.
Such a solution would not replace ADSM, but enhance it. The LANRES =
solution would give you fast full-volume recovery capability in the case =
of a hardware failure. You'd still want to use ADSM for incremental =
backup and restore, however.
Andy Raibeck
|
