On Jun 16, 2011, at 8:34 PM, Paul Zarnowski wrote: > At 05:59 PM 6/16/2011, Nick Laflamme wrote: >> We need to do a bake-off -- or study someone else's -- between using >> deduplication in a DataDomain box and using both client-side deduplication >> and server-side deduplication in TSM V6 and then writing to relatively >> inexpensive, relatively simple (but replicating) storage arrays. However, we >> keep pushing the limits of stability with our TSM V6 servers, so we haven't >> dared tried such a back-off yet. > > Nick, > > We are heading down this path. My analysis is that in a TSM environment, the > fairly low dedup ratio does not justify the higher price of duduping VTLs. > Commodity disk arrays have gotten very inexpensive. We're using DS3500s > which are nice building blocks. We put some behind IBM SVCs for servers, > some attached to TSM or Exchange servers (without SVC). Common technology - > different uses. We use them for both TSM DB, LOG and FILE (different RPM > disks, obviously). Using cheap disk vs VTLs has different pros and cons. > using disk allows for source-mode (client-side) dedup, which a VTL will not > do. VTLs, on the other hand, allow for global dedup pools and LAN-free > virtual tape targets. deduping VTLs will be more effective in TSM > environments where you have known duplicate data, such as lots of Oracle or > MSSQL full backups, or other cases where you have multiple full backups. For > normal progressive incremental file backups, however, TSM already does a good > job of reducing data so VTL dedup doesn't get you as much, and in this case > IMHO cheap disk is, well, cheaper and gets you source-mode dedup as well. > > We are in process of implementing this, but I know a few others are a bit > further along.
It's too bad there isn't a USA-based users group for TSM that meets annually or even semi-annually for things like user presentations and panels on topics like this. :-) I'd love to go to a "TSM Workshop" at some university campus to geek out on topics like this. Dedupe ratios are all over the place for us. We've got some in the high teens, and I already mentioned the low end, low single-digits. Part of me wishes we'd broken our library volumes out into smaller replication pools (and corresponding TSM library pools) so we could get a little more granularity on dedupe ratios, but what I really want is volume-by-volume (or file-by-file for NFS mounts? Directory-by-directory?) dedupe ratios. Adding a copy storage pool on the same DDR is cheap from a DDR point of view; it seems to dedupe great when I do that. The TSM DB size becomes the limiting factor in that case. > We will continue to use TSM Backup Stgpool to replicate offsite. We're replicating at the HW level; TSM doesn't know it. That makes me a little nervous. I forgot one thing I don't like: having specific "cleaning" cycles on the DDR is annoying. We run it two or three times a week on a couple of our DDRs to keep them from getting too high (above 80%) in utilization, but I wish it just constantly did its own garbage collection. > ..Paul Nick
