This is where one additional point comes to mind - that of the size of virtual
volumes which is controlled with MAXCAP on the device class definition on the
source server. You can change the value MAXCAP any time. The larger the virtual
volume, the more "white space" you carry at the target server. It's difficult
to get an actual number of the amount of white space, but the logic is as
follows: Assume you have MAXCAP specified on the source server of 100GB. Assume
at the source server you are running reclamation at 50%. Note that all virtual
volumes are marked full at the end of a process, so there may be some amount of
virtual volumes that are smaller than 100GB. For the purposes of a calculation
though, let's assume they are all 100GB. Let's further assume that you have 500
volumes that meet the 50% reclamation threshold. The amount of white space at
the target server therefore is 500 volumes * 100 GB * 50% = 25 TB of white
space, which with LTO4 technology is more than 15 tape cartridges. So, it is
useful to set the DELGRACEPERIOD to zero for your server definitions such that
you gain back space more quickly. I would also suggest that you run reclamation
at 50 % on the virtual volumes on the source server. I would also run
reclamation at the target server very aggressively, namely 50%. To reduce the
overall white space at the target server, you can reduce the source server's
MAXCAP specification. One watch-for is that you can get into a situation where
you now have many small virtual volumes whose corresponding archive objects at
the target server are scattered across many physical tapes. In such a
situation, access to large quantities of data by the source server can result
in an intolerable number of tape mounts at the target server and slow down the
source server's performance to unacceptable levels. If however the target
server is not using physical tapes but instead is using disk via a file device
class, then it is very much worthwhile to have more smaller virtual volumes at
the source server, therefore more smaller archive objects at the target server
and therefore less white space. You can get an estimate of the number of
volumes meeting a given reclamation threshold with a script that I use called
tl. The script is shown below. Here is a sample of the output where a physical
tape and a virtual volume would meet a reclamation threshold at 50 percent.
This was run at the source server.
tsm: IT-TSM>ru tl 50
Session established with server IT-TSM: Windows
Server Version 6, Release 2, Level 0.0
Server date/time: 03/14/2011 18:14:10 Last access: 03/14/2011 17:29:44
Total tapes meeting criterion
------------------------------
1
STGPOOL_NAME: BACKUPTAPE
VOLUME_NAME: A00031
PCT_UTILIZED: 31.6
PCT_RECLAIM: 68.5
Total volumes meeting criterion
--------------------------------
1
STGPOOL_NAME: COPYPOOL
VOLUME_NAME : IT-TSM-DR.BFS.297618097
UTIL: 27.3
RECL: 72.7
EST_CAPACITY_MB: 51200.0
ANR1462I RUN: Command script TL completed successfully.
Hope this helps.
Regards,
Joerg Pohlmann
tsm: IT-TSM>q scr tl f=l
Name Line Command
Number
---------- ------
------------------------------------------------------------
TL 1 select count(*) as "Total tapes meeting criterion"
from
volumes -
5 where devclass_name <> 'DISK' and stgpool_name not
like
'%COPY%' and pct_reclaim >$1 and status in ('FULL',
'FILLING')
10 select stgpool_name, volume_name, pct_utilized,
pct_reclaim
from volumes -
15 where devclass_name <> 'DISK' and stgpool_name not
like
'%COPY%' and pct_reclaim >$1 and status in
('FULL','FILLING') order by stgpool_name asc,
pct_reclaim
desc
20 select count(*) as "Total volumes meeting criterion"
from
volumes -
25 where devclass_name <> 'DISK' and stgpool_name like
'%COPY%'
and pct_reclaim >$1 and status not in ('PENDING',
'EMPTY')
30 select stgpool_name, volume_name as "VOLUME_NAME
",
pct_utilized as UTIL, pct_reclaim as RECL,
est_capacity_mb
from volumes -
35 where devclass_name <> 'DISK' and stgpool_name like
'%COPY%'
and pct_reclaim >$1 and status not in ('PENDING',
'EMPTY')
order by stgpool_name asc, pct_reclaim desc
tsm: IT-TSM>
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Erwann SIMON
Sent: Thursday, March 10, 2011 21:55
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Does Move Data recover space on virtual volumes?
Hi All,
My advice is to read closely this Joerg's message that gives all the answers !
Main points are :
- 1 virtual volume on the source server equals 1 archive object on the target
server
- when a virtual volume returns to scratch on the source server, then begins
the deletion grace period for the associated archive object on the target
Best regards / Cordialement / مع تحياتي
Erwann SIMON
Le 10/03/2011 22:33, Joerg Pohlmann a écrit :
> Keith, make sure you run reclamation on the virtual volume-based storage pool
> on your source server. By default, there is a deletion grace period of 5 days
> before the virtual volume (actually the archive object) is deleted on the
> target server. Oncce it is deleted at the target server you need to make sure
> the archive object is deletd on the storage pool by running inventory
> expiration. Inventory expiration creates reclaimable space in the tape
> storage pool that holds these archive objects and you can now run reclamation
> to get the physical tape space back.
>
> Move data on a virtual volume on the source server will have the same effect
> as reclamation. Move data on a physical tape at the target server has the
> same effect as reclamation. But, why do all this manually as opposed to just
> letting reclamation run on a daily basis.
>
> Regards,
>
> Joerg Pohlmann
>
> ----- Original Message -----
> From: Keith Arbogast<warbogas AT INDIANA DOT EDU>
> Date: Thursday, March 10, 2011 3:48 pm
> Subject: Re: [ADSM-L] Does Move Data recover space on virtual volumes?
> To: ADSM-L AT VM.MARIST DOT EDU
>
>> My specific problem is with a tape pool that is a target for virtual
>> volumes created by a remote TSM server. The number of cartridges in
>> use by the pool goes up and up, at a faster rate than the data growth
>> on the remote server. I suspect there are many virtual volumes in the
>> target pool with not many active files left on them.
>>
>> My understanding is that even one active file in a virtual volume
>> keeps all the space used by it on a tape from being reclaimed. So
>> far, my only resort seems to be to do MOVE DATA on virtual volumes
>> with log pct_utilization, using 'reconstruct=yes'. That won't be
>> efficient or fast.
>>
>> If I am missing something, please let me know.
>>
>> My thanks to all who have offered suggestions so far, Keith
>>
|
