==> In article <s104d9aa.083 AT health-es2.health.qld.gov DOT au>, Steve Harris
<Steve_Harris AT HEALTH.QLD.GOV DOT AU> writes:
> I'd also like to optimize for restore, but without the overheads of
> collocation. So, I'm considering running a move nodedata on every node
> periodically - maybe once a month for production, once every three months
> for non-production.
You run a reasonable chance of saving some resources here, but you're going to
have to 'cook' the process pretty carefully. For example, if you
faux-collocate your library on (say) day 100, but write indiscriminately from
days 100-130, you will probably have to empty all of your written tapes on day
131; many or most of them will have been filled with random-owned data written
above the faux-collocated area.
One thing you can do is define an extra, collocated stgpool, and move data to
it as you deem fit:
So:
DISKPOOL -> TAPEPOOL (non-collocated)
CTAPEPOOL (collocated)
And when you get a full volume in TAPEPOOL, you MOVE DATA it over to
CTAPEPOOL.
... The critical thing to evaluate here is exactly which overheads of
collocation you think you're going to dodge.
You'll still have the reclamation overhead: "nearly all" of your data is in
fact collocated.
You'll still have the tape inefficiency, for the same reason.
You'll avoid some tape-mount overhead: instead of mounting most tapes in your
tape pool every day, you'll only mount a few for migration.
However, what you pay for this is the expectation of mounting every tape in
TAPEPOOL for any given restore. If you keep that low (i.e. only one filling
tape) that could be reasonable.
But if you move data out of TAPEPOOL only once a month or so, you'll probably
accumulate 10 or 20 tapes in there before you clean house. That will make the
MOVE DATA process long and re-mount-iferous, and it will mean most restores
will go from one or two mounts to 10s.
And if you fill tapes every day (and thus in my scheme MOVE DATA every day)
you've in fact lost ground, because you move data one additional time.
In any case I'd -strongly- advocate against moving data around in a -non-
collocated stgpool and thinking you've improved matters much.
- Allen S. Rout
|
