Storage volumes, tivoli volumes, and node read write

[mosiac]

We've recently deployed 7.1 and our storage person provided 13 volumes to tivoli at 2 to 4tb each. IBM has told us that we should split those into many more small volumes so that when clients connect to start backups they can use multiple sessions to write to storage more efficiently.

I was curious if this is how everyone else is doing things for their diskpools. What I'm wondering is if perhaps we should have looked at this another way since we're copying something from one spot on our san storage to just another spot on our san storage and if this could give us some backup speed increases.


Thanks,

 

[marclant]

We've recently deployed 7.1 and our storage person provided 13 volumes to tivoli at 2 to 4tb each. IBM has told us that we should split those into many more small volumes so that when clients connect to start backups they can use multiple sessions to write to storage more efficiently.

Here's how to calculate how many volumes you need based on workload and space available: http://www-01.ibm.com/support/knowl...m.ibm.itsm.perf.doc/r_ptg_strpoolvolsize.html For file pools, it's true that you need as many filling or scratch volumes as the number of concurrent sessions, otherwise you end up in MediaWait.

I was curious if this is how everyone else is doing things for their diskpools. What I'm wondering is if perhaps we should have looked at this another way since we're copying something from one spot on our san storage to just another spot on our san storage and if this could give us some backup speed increases.

If you have two storage pools, both on SAN disk, then it could make more sense to send the data directly to the final destination. Migrating from one file or disk pool to another file or disk pool doesn't seem like the best use of processing time. If the all the SAN disks are the same size, it may make more sense to have one large pool using all these SAN disks, unless you have a business requirements to split them up like that.

You can achieve more speed if you have more physical disks assigned to a single storage pool, because the workload will be split across more spindles. TSM's volume selection does a round robin and any new request for a volume is picked from the next directory. So more LUNs mounted to more directories to a single pool could help.

Review this checklist to make sure your config is optimal:
http://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1.1/com.ibm.itsm.perf.doc/r_srv_hw_disks.html

 

[mosiac]

Thanks for those links they will help a lot. It sounds like I need to look at my settings for maximum possible sessions and my schedules to see how many sessions clients use during backup windows. And go from there to get a better understanding of the bigger picture here.