I have already thought of this idea. I was hoping for GROUP COLLOCATION. The problem with this idea/design is I have to essential duplicate *EVERYTHING*, such as admin processes, operator training, etc. Also, this means I have to set aside disk storage (which is very limited on my zOS system) to dedicate for each pool, that can't be shared, and hope I don't guess wrong on how much each pool/group needs.
Thanks for the suggestions. Unfortunately, this is probably the way I will have to go. One confusion is why do I have sooooo many partially filled tapes ? I don't have this many nodes ? "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> wrote on 05/04/2004 01:10:17 PM: > Zoltan, why not set up a SMALL_SERVERS policy domain which has MC > definitions the same as your normal server PD with one difference - send > the data to a different hierarchy where the tape storage pool is not > collocated. The client nodes that are candidates for this PD are nodes > that have small quantities of data in TSM's storage. You can do a q > auditoccupancy to zero in on the nodes that are small server candidates > that currently reside in the PD where the data is collocated. Small > quantities are in my opinion nodes with less than 20-40GB reported by q > auditocc. The q auditocc data has to be interpreted as "1/2 onsite, 1/2 > offsite" if you have a normal DR environment where the data has been > backed up to a copy pool. Then copy the appropriate client schedules to > the new PD, update the nodes to the new PD, then associate the nodes with > the new schedules. If your server is pre-5.2.x.x and you are running > schedmode prompted, you will need to restart the client acceptor or > scheduler service/daemon/nlm as the server does not remember the client's > IP address prior to 5.2.x.x servers. Then do a move nodedata for all the > nodes in question. I have a customer with >175 nodes where 50 nodes are > SMALL_SERVERS nodes residing on 2, sometimes 3 tapes. The large nodes > reside on collocated tapes. This approach gives you the best of both > worlds - a fast restore capability for a small node as only 2 sometimes 3 > tapes need to be mounted maximum, and good tape usage as the slot > occupancy in the library is minimized (optimized). I also segregate AGENTS > (TSM for Databases, Mail) into a different PD where the data flows into a > non-collocated tape pool such that reclamation activity is minimized and > tape occupancy is maximized, that is the number of tapes in use is > minimized. Agents typically send large blobs (the database) where > expiration often causes entire tapes to become empty. Workstations, > laptops in my implementations live in the STANDARD PD where the data flows > into a non-collocated tape pool. > > Joerg Pohlmann > 604-535-0452 > > > > > > Zoltan Forray/AC/VCU <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 2004-05-04 07:54 > Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > cc: > Subject: What ever happened to Group Collocation ? > > > > Any one have any idea on what the target is for this much needed feature ? > I thought it was originally targeted for 5.2.2 (unless I missed it > somewhere !). > > I have 125 tapes with less than 10% used, due to collocation and a bunch > of small nodes and I really need to reduce that number !
