It was inevitable - I've got more tapes and data than I can keep 'hot'
in my current library. Paul's question about "TSM admin processes"
seems like a nice lead-in to this conversation:
Any best practices for using overflow/MountableNotInLib conditions?
I've read the 'Managing a Full Library" page in the Admin guide, but it
seems like there are lots of dependencies that make 'move media'
commands need some thought. I'm not as worried about restores, as those
are manual and observed anyway. I'm more concerned about the basic,
automatic storage pool operations and what overflow means to my overall
maintenance, and its impacts (for example, reclaims not running as well
or using more tapes).
Here's my core dump of thoughts and questions; maybe we can get a good
discussion here. If I missed a redbook or white paper, please point it
out.
The days=X flag on the "q media" and "move media" seems handy. I can
say "only move tapes that haven't been written to in 28 days" or
something. That means I should make sure I've done a 'backup stg' of
those tapes in the last 28 days so that they aren't needed for the
'backup stg' command.
Because I'm tight on library space, I keep my reclaimation values pretty
high on the stgpool I'm migrating. What happens when a
MountableNotInLib volume is eligible for reclaimation? Does anything
tell me, or do I need to be monitoring the logs for failed reclaims or
the volumes for ones that should be reclaimable but aren't. I'm
guessing I need a cleanup process somewhere that finds MountableNotinLib
volumes below the threshhold and reminds me to move them back to the
library.
What about reclaimations of copypool volumes that source
MountableNotInLib volumes? I'm guessing my copypool tapes reclaims will
fail (so I need to watch for that?) or I need to watch for those tapes
sticking below their reclaim threshhold as well? Is this going to be a
common problem, or is the nature of copies of cold data also stay pretty
cold going to keep the copypool reclaims close to the stgpool reclaim
frequencies? (As I hinted, I've been tight on library slots for a
while, so these stgpools are colloc=no, which probably works against me
here.)
'move drm' and 'move media' are independent from each other. Got it.
Too bad -- a VaultRetrieve state for 'move media' would be nice, based
on how its needed. Or is this the type of thing that ServerGraph helps
identify/manage/visualize?
I'm also thinking about active pools, although because it's "yet another
copy" scenario, that might cause even more library slot contention.
Thoughts?
Dave
--
David Mussulman mussulma AT uiuc DOT edu
SysAdmin, NetAdmin for the Technology Services Group 2330 Siebel Center
Department of Computer Science office: 217.333.6231
-- See https://agora.cs.uiuc.edu for CS Intranet and TSG support info --
|
