Bruce Elrick had an explanation of my problem (appended below) which
sounds very convincing. It perfectly describes what I saw. I will
check out the details later on this week.
His explanation brings up another question, tho:
If I have multiple ADSM client sessions (be they buta or ordinary
clients) which are in a management class where the disk storage pool is
in readonly access mode (to force the data to go directly to tape), will
I have a different tape mounted (and tape drive in use) for each session
taking place simultaneously?
Otherwise, with the disk storage pool in readwrite mode, if I understand
Bruce's explanation, it's a question of the relative rate of input to
the disk (from the clients) and the output from the disk to tape by the
migration processes. E.g., if each of 4 client inputs at 1-2 MB/sec
and a migration process can write a tape at 4-5 MB/sec, then 2 migration
processes should be sufficient to keep disk space available to the
clients (with appropriately chosen lo and hi migration thresholds).
Did I get that right?
Thanks in advance. John
-----
John O'Neall
John O'Neall
Centre de Calcul de l'IN2P3
Bruce's explanation:
Probably what happened was the following:
1) 4 buta sessions start (didn't have to be buta), all go to disk
storage pool
2) disk stgpool hit 60% threshold, 1 migration process started, mounts
one tape
3) 4 session fill disk pool faster than one mig process can drain it
(depends on network throughput and tape technology, and number of
sessions/migprocesses), %util climbs from 60% to 100%
4) as %util approaches 100%, each session in turn finds the disk pool
full, allocates a mount pount, and mounts a tape and sends the next file
to the tape stgpool
(as each file is sent to the server, the server evaluates whether there
is enough space in the backup copy group's destination storage pool has
enough space for the next file; when there isn't, the next file is sent
to the destination stgpool's next storage pool)
5) although the sessions may switch back to the diskpool when the mig
process makes space, they quickly (within two minutes?) fill it again
and go back to tape, keeping the tapes mounted.
6) when the sessions complete, the mig process clears out the diskpool
You can confirm this by recreating the situation and issuing a 'q se
f=d' to see what the media status is. It will show whether the session
itself has a a tape mounted.
You can cure the situation by setting the allowable migration processes
higher on the disk stgpool, assuming that multiple migration processes
can keep up with the 4 streams of backup sessions (imagine 4 sessions
coming in across 4 different 100baseT network connections to a striped
SSA disk pool being drained by 4 Exabyte 8200 8mm tape drives :-). ADSM
migrates by node/filespace, does you multi-stream buta backup create
multiple pseudo-filespaces? If a disk stgpool has only one filespace
from one node, only one mig process will run regardless of the setting
of 'mig process' for the stgpool.
Cheers...
Bruce
|
