ADSM-L

Re: SAN Environment

2001-10-25 10:47:24
Subject: Re: SAN Environment
From: James Thompson <jamthomp AT US.TIVOLI DOT COM>
Date: Thu, 25 Oct 2001 07:47:44 -0700
Keep in mind that one of the settings for a node is max number of mount
points (MAXNUMMP).  This is typically set to 1.
This forces a node to only be able to reserve a single mount point.
Resource utilization causes multiple sessions for
a node to be used.  When going to tape or a stgpool of type file, this
requires multiple mount points.

James Thompson
Performance Analyst - Open Systems
Tivoli Certified Consultant - TSM 4.1

----- Message from Robin Sharpe <Robin_Sharpe AT BERLEX DOT COM> on Wed, 24 Oct
2001 11:18:27 -0400 -----
2001 11:18:27 -0400 -----

 Subject: Re: SAN
          Environment


Funny you should mention that...

While setting up our new TSM server on HP-UX, I opted to define all of the
disk pools as sequential files.  I defined a Device Class of type FILE
(called... FILE !) with capacity of 6G.  Then I defined several Storage
Pools using DEVCLASS FILE.  On my older server, the Storage Pools use
DEVCLASS DISK.

My reason for trying this approach was that on the old server, we would get
into situations (usually on weekends) where we would run out of scratch
tapes, and the disk pools would fill up.  Since there were no tapes to
migrate to, backups would cancel.  In order to get them rolling again, I
would delete disk volumes from other disk pools that were not being used,
rm the files from the directory, then define new volumes to the full disk
pools.

By using the DEVCLASS FILE approach,  the use of disk space is dynamic and
self-regulating.  Disk volumes get allocated (in 6G increments) when and
where needed.  No need to remove and define volumes.

I can't really compare performance between the two servers because the
hardware on the new server is much faster (HP 2100 disk array vs. internal
F50 non-SSA disks).  However, I have seen some strange behaviour... one
system backup in particular, got a "server out of storage" message, even
though there was disk AND scratch tapes available...  My thought is that
because it was a collocated pool, and the client had a high
resourceutilization (8 I think), it got into a "waiting for access"
condition.  I had to change that management class to go direct to tape and
reduce the resourceutilization to 1 to get it to complete!  There seems to
be some incompatibility when using collocation and resourceutilization > 1
together.

Other than that one incident, it's been working pretty well.

Robin Sharpe
Berlex Laboratories
<Prev in Thread] Current Thread [Next in Thread>