Storage Pool Re-Configuration Question

ILCattivo

ADSM.ORG Senior Member
Joined
Jul 9, 2013
Messages
192
Reaction score
14
Points
0
Location
Oxford, United Kingdom
PREDATAR Control23

Morning chaps,

I have 1 File device class with 2 deduplication storage pools attached to a TSM 7.1.5 Server.

Directory: S:\STG,P:\STG,X:\STG

Currently these 2 storage pools have a max scratch setting of '0' whereby volumes of 5GB in size have been created manually as and when additional capacity has been required. Personally I don't like storage pools setup in this way as you can be prone to running out of storage pool space, and scratch volumes can also run out which can affect reclamation if any unforeseen large ingestion were to come about.

NB:\\ 1 storage pool has had volumes manually created for it using P:\ & X:\ while the other is only using S:\
i.e 'DEFine Volume DEDUP1 S:\STG\VOL1001 ACCess=READW Formatsize=5120'

Today, a lot more disk capacity is being added to the file class directories (see above) for these two storage pools.

I now want to change the max scratch setting to my preferred setting of '9999' & the max cap (MB) setting to '5120' for these 2 storage pools so that TSM now has the capability of using the entire underlying disk capacity available to it and start creating and deleting scratch volumes on its own as and when it needs them for both backups and reclamation.

Anything I should be aware of before doing this..? Firstly, I am assuming that making this change will result in both storage pools placing their scratch volumes in any one of the 3 available file class directories as appose to previously being restricted to just those directories where they were manually created?

edit.. btw, these storage pools backup to Tape daily via the 'backup stgpool' cmd.

Anything else?

Thanks
 
PREDATAR Control23

Firstly, I am assuming that making this change will result in both storage pools placing their scratch volumes in any one of the 3 available file class directories as appose to previously being restricted to just those directories where they were manually created?
Yes. TSM will place the volumes where ever it pleases. I think there's some sort of reason behind where a volume gets placed based on utilization of the file system but don't quote me on that. Is the new space expanding your drive letters, or are they going to be new mount points?

For sake of letting TSM manage the volumes, you'll likely want to get a list of the manually defined volumes so you can remove them in the future.
Once you have the list, and your new storage is in place, set the manually defined volumes to readonly, then move data $vol to empty them. Once empty go back and delete the volumes.

For space rec's inside your deduplicated pools, depending on how fast your storage is and other factors could be as low as 35%. There's is scheduling consideration around when to run space reclamation. I just have a step in my maintenance scripts to update stgp <stgpool name> recl=100, and then recl=35 depending on where its at in the cycle.

I am curious as to why you are using two independent deduplicated storage pools? You may achieve a higher deduplication ratio if all your data was in one large pool. More extents to compare against.

Hope it helps!
 
PREDATAR Control23

Thanks for the reply RO,

Yep, the new space is an expansion of 2 of those drive letters..

So, what you're saying here is that once the max scratch stg pool settings are changed TSM will not delete the previous manually created volumes as part of it's future reclaim processes. Will it therefore only ever use new ones it auto-creates for backups and never go back to the 'static' ones?

I only ever run reclamation through a Maintenance script and have the stg pool settings set at =100

This is an old TSM server which I have inherited this year to look after, I believe the preference at the time was to separate out client backups from VE backups, hence the two storage pools.

Thanks
 
PREDATAR Control23

So, what you're saying here is that once the max scratch stg pool settings are changed TSM will not delete the previous manually created volumes as part of it's future reclaim processes
From what I've see, that is correct. It will still use them to store data, but won't remove them as part of the reclamation process. They will just sit out there in an empty state.

For example a deduplicated storage pool on my older TSM server that has manually defined volumes:
Code:
Volume Name                  Storage         Device         Estimate-      Pct      Volume
                             Pool Name       Class Name     d Capaci-      Util      Status
                                                                   ty
------------------------     -----------     ----------     ---------     -----     --------
/tsmstg01/file0000           FILEPOOL01      FILECLASS-        50.0 G       0.0      Empty
                                              01
/tsmstg01/file0002           FILEPOOL01      FILECLASS-        50.0 G       0.0      Empty
                                              01
/tsmstg01/file0003           FILEPOOL01      FILECLASS-        50.0 G       0.0      Empty
                                              01
/tsmstg01/file0004           FILEPOOL01      FILECLASS-        50.0 G       0.0      Empty
                                              01
/tsmstg01/file0005           FILEPOOL01      FILECLASS-        50.0 G       0.0      Empty
                                              01
/tsmstg01/file0006           FILEPOOL01      FILECLASS-        50.0 G       0.0      Empty
                                              01
/tsmstg01/file0007           FILEPOOL01      FILECLASS-        50.0 G       0.0      Empty
                                              01
q vol /tsmstg01/file0000 f=d

  Volume Name: /tsmstg01/file0000
  Storage Pool Name: FILEPOOL01
  Device Class Name: FILECLASS01
  Estimated Capacity: 50.0 G
  Scaled Capacity Applied:
  Pct Util: 0.0
  Volume Status: Empty
  Access: Read/Write
  Pct. Reclaimable Space: 0.0
  Scratch Volume?: No
  In Error State?: No
  Number of Writable Sides: 1
  Number of Times Mounted: 221,702
  Write Pass Number: 26
  Approx. Date Last Written: 12/03/2016 20:25:44
  Approx. Date Last Read: 04/27/2017 20:46:42
  Date Became Pending:
  Number of Write Errors: 0
  Number of Read Errors: 0
  Volume Location:
Volume is MVS Lanfree Capable : No
Last Update by (administrator): ADMIN
  Last Update Date/Time: 07/28/2012 09:32:48
  Begin Reclaim Period:
  End Reclaim Period:
  Drive Encryption Key Manager:
  Logical Block Protected: No

As to the client vs VE backups I understand. Just was wondering the reason why. Still you may be able to gain some benefit by combining everything. To be honest, I have things split out between several storage pools as well...Not that I wanted to, but in some aspects it does make managing the backup storagepool and associated reclamation of tapes easier. Just depends on your situation
 
PREDATAR Control23

Ok, that makes sense thanks..

All of the manually created volumes will be very easy to identify for housekeeping purposes later on as they all start with '\STGVOL####' very similar to your example.

I can then periodically clean them up as and when they start to appear as empty under the volume status.
 
PREDATAR Control23

Welcome.

I can then periodically clean them up as and when they start to appear as empty under the volume status
I wrote a script to move data and knock it out in one go :) Other wise things have a nasty habit of lingering too long. And those volumes may never empty on their own.
 
PREDATAR Control23

Believe it or not, even after this space expansion, this particular TSM server will be decommissioned in 2 months time, so not particularly worried about any residual mess.. :)

Migrating the nodes over to Spectrum Protect 8.1.2/3 on new tin and storage at a new DC utilizing dir container storage pools and 'NO MORE TAPE' :cool:
 
PREDATAR Control23

'NO MORE TAPE'
Good luck! Just make sure you are running the latest client levels (higher than 7.1.6 I think, posted about it in a previous post here some where) because they introduced a new compression algorithm.

Still using tape....with legacy dedup/nodedup file pools.
Using tape with container storage pools...
TAPE FOREVER!!!

Wait.....
 
Top