Drawbacks of using single storage pool for different nodes

[huttivoli]

In my TSM environment we have around 100 nodes of different flavor (SAP,AIX,Windows,DB2,SQL etc..). Other then using different diskstorage pool for a particular policy domain, I am planning to use big diskpool (1TB) for all the policy domian, and enable collocation by node, so the data should not segregate to different tapes, and it will not become a nightmare while full restoration happens.

Advantages

1, There will be no issue of diskpool become full (small diskpool for different flavor) and backup is going to tape which will make the process slow.

2, Easy to administrator as there will be single diskpool.

Disadvantages

1, whenever migration will start, lot of tape drives are required as collocation is enabled (we have 18 drives)

Before implementing this, I want to confirm whether this will be useful or not, And what are the advantages/disadvantages it have.

 

[Trident]

Just remember to have copy pools when using collocation by node. What happens if one tape goes bad.... Suddenly you lost all backup for the server that was on that tape.

 

[huttivoli]

Last time we have a same situation where all the data is going to single storage pool with collocation disabled. In our DR test one DB2 node took almost 4 days to restore as the data is in 200 volumes. Before implementing the same configuration with collocation enabled I want to confirm all the options.

 

[mikeatkc]

I have the same setup here, one storage pool (1TB) for simpler management. Migration is not that bad either, I have 8 drives (LTO-2) and kick of 4 processes, took roughly 4 hours to complete.

 

[mikeatkc]

Last time we have a same situation where all the data is going to single storage pool with collocation disabled. In our DR test one DB2 node took almost 4 days to restore as the data is in 200 volumes. Before implementing the same configuration with collocation enabled I want to confirm all the options.

How large was the DB2 file space? Shouldn't reclamation helps reduce the number of volumes?

 

[Raakin]

I realize this thread is a few months old, but what have you grouped by? OS, Application, Critical/Non Critical?

I am debating on doing this and I would think group collocation can quickly make a lot of groups.

 

[DanGiles]

YES.

No, seriously, you're going to set up the copy groups similarly to the way a lot of people set up their storage pools: by OS, Application, etc. The difference discussed here is that segragation is done during migration instead of during the backups. Personally, I like to differentiate according to tier (criticality) and applications, such as putting databases in their own pool. I don't think o/s really matters as far as backups are concerned (for the most part).

The only thing that I would add to this thread is that I would keep archives in a totally separate storage pool hierarchy: don't mix them with backups at all!

 

[BBB]

Yeh I definitely agree with Dan on that. Don't group by OS. Group by the type of data (importance) or the data's retention (eg. keep long term backups separate from dailies). In fact its probably better to have a separate stgpool for long term data, and perhaps another one for critical data. It all depends on the types of data in your env and the different types of retention period you have.

Collocation by group may give you better performance than by node, if you can ensure there's a few tapes in each group. This means that a) a restore doesn't need to mount too many tapes but b) the restore can mount more than 1 tape for multi-session restore. It also saves having mount 100's of tapes each time you run migration...

 

[Eldoraan]

Yes, collocation by group with them grouped by retention works best for us. That way short term data expires and we free up scratch tapes quickly there, but the longer term data sits on tape a bit longer before reclamation moves it around.

 

[GregE]

I've thought about (haven't done it, just thinking thru some logic here) collocating by group a bit differently. Instead of having similarly critical nodes grouped together, mixing criticality levels:

Let's say you your node criticality is rated....
1 - Most critical
2 - Somewhat critical
3 - Not critical

Then create groups containing a mix of level 1's and 3's, and groups containing 2's and 3's, trying to NOT group any 1's and 2's. The reason being that if there would be mulitple level 1 nodes on a tape, you'll have more possibility of tape contention trying to restore many level 1's at the same time. But if you group level 3's with 1's, less level 1 data will be able to be stored on the same tapes and you'll have things spread a bit better. The same would apply by storing level 3 with level 2, to better alleviate tape contention when restoring level 2 data.

Does something along those lines make sense to look at as an option, with DR being the main purpose for it?

 

[DanGiles]

I've often thought that and suggested it at a few places: it all depends on your DR site's capabilities. If you have a library there what can handle all your tapes, then it makes sense. Most people of a DR infrastructure that is a lot less capable then their normal operational infrastructure, where you would want to minimize the number of tapes that you had to handle at any one time.

If you put all your crit1's together and you want the ability of more parallel processing on the restores at your DR site, and you can access a large chunk of disk, then what you can do is first move all the crit1 data to disk. This would mean that it would take longer to start restoring data, but the overall time will be reduced.

I believe with 6.x, you can have copy pools for your active data pools, in which case the amount of data you'll have to handle above will be greatly reduced.

 

[GregE]

I've often thought that and suggested it at a few places: it all depends on your DR site's capabilities. If you have a library there what can handle all your tapes, then it makes sense. Most people of a DR infrastructure that is a lot less capable then their normal operational infrastructure, where you would want to minimize the number of tapes that you had to handle at any one time.

If you put all your crit1's together and you want the ability of more parallel processing on the restores at your DR site, and you can access a large chunk of disk, then what you can do is first move all the crit1 data to disk. This would mean that it would take longer to start restoring data, but the overall time will be reduced.

I believe with 6.x, you can have copy pools for your active data pools, in which case the amount of data you'll have to handle above will be greatly reduced.

Thank you. In our case, the DR library Sungard has available to us contains more drives than we have onsite,. many more slots, etc, so the scenario could work for us. We did our first DR test last year with a very small number of nodes, and I had collocated the copy pool by group, but data wasn't spread very well at all. The test went "ok" only because the node number was very limited, but in a full DR (7 months away) there's no way it would work well with that kind of tape contention. The DR disk availability for moving data is also interesting and possible.

Something you wrote earlier brought up a question.....

.....you're going to set up the copy groups similarly to the way a lot of people set up their storage pools: by OS, Application, etc. The difference discussed here is that segragation is done during migration instead of during the backups

What did you mean here? The segregation of data in that way sounded interesting, but as I went to look at how that would happen, I realized I didn't quite follow. How would that be done?

 

[DanGiles]

I was refering back to the original thread discussing the use of a single disk storage pool. So instead of having, say, 3 storage pools for crit1/crit2/crit3 servers, they would all back up to the same disk pool then separate out at migration using collocation groups. The other great advantage of doing it this way, especially if you're thinking of mixing nodes, is that management should be much easier. If you want to rebalance the groups, just change the collocation group members; you won't (necessarily) have to mess around with changing domains and management classes.

Let me know if I've answered your question or not.

 

[GregE]

Yes you answered it. What threw me off was your mention of "copy groups." Did you mean "copy pools?"

Nonetheless though, this is great info, thank you. I've never thought of a single primary diskpool and using collocation by group as the method of segregation, as this discussion has been about. I'm thinking of combining all filesystem backups (Windows, UNIX, etc), but continue to segregate DB. We only have MSSQL and Oracle. Is there any technical reason to separate these DB types into two separate diskpools? (Oracle is all TDP; MSSQL are mostly TDP but some just files created by MSSQL native backup). Or would it be a good idea to combine all database TDP backups to their own, one diskpool? Right now, all of our DB backups go to disk but soon I will be moving some of Oracle to LAN-free with logarchives still going to primary disk.

Still knocking around ideas, but with next year's DR being a full blown one, there is a strong need to make some changes to my original configuration. (a canned setup, put in quickly without my involvement at all, then handed to me as a TSM newbie to take over from square one )

 

[DanGiles]

Sorry, I meant collocation groups. That's what happens when you try to multitask .

Me, if I was going the "one pool fits all" route, I'd go all the way. Separate out TDP backups by putting the agent nodes in their own colloc. group.

Since you brought it up, though, if the TDP agents back up large amounts of data (10's or 100's of Gigs), I'd make them go straight to tape. That's what I do regardless of how the disk pools are set up. The smaller, quick TDP backups, like transaction/archive logs, go to disk.

Hey, and if you pull off the full-blown DR test, consider yourself an TSM expert!