Best practice DS3400

[nit0tp]

What is best practice for implementing TSM storagepools on a DS3400 disk array with two controllers (1 GB pr controller) and 24 1TB SATA disks using 4Gb fiber.

TSM is installed on x3950 with 8 cpu cores and 32GB of memory. TSM database and Log is set up on a V7000 disk array. The DS3400 is configured as one large array (RAID6) with 4 logical drives (free capacity 4,7TB). We are keeping all backup data on disk using device type FILE and do daily backups to TS3200 tape library. We have two storagepools – one for normal TSM client backup and one for VMware backup. The storagepool for vmware backup is being deduplicated.

I am no good with disk optimization but have a good feeling that the DS3400 configuration is not optimal. The things that I could think of is as follows but if somebody has other important issues I would really appreciate it.
- Number of disk arrays
- Number of Logical drives on the disk arrays
- Segment size.
- Storagepool volume size

 

[terlisimo]

In environments with 12+ disks I usually create 2 arrays, put a storage pool on each one and set each other to be their respective RECLAIMSTGPOOLS, this way your disks will not thrash so much while doing reclamation processing because it's a disk-to-different-disk transfer which is much faster than disk-to-same-disk (whether physical or logical). Ofcourse, 2 RAID6 arrays will waste more space than one large one because of the parity drive, you should strike a balance between performance and available space.

Also, I found that reclaiming offsite volumes of tape-based copystgpools for deduplicated primary storage pools runs very slowly so I gave up on deduplication for data that needs to be kept offsite. Data movement from deduplicated to a non-deduplicated storage pool is usually slow, I've heard many people complain about this.

Few larger volumes will have marginally better performance than many small ones (say, 10GB vs 500MB) because DB has to process fewer volumes during reclamation processing and similar operations but with larger volumes you'll have more wasted space and reclamation processing will usually take longer because it needs to move more data.

Your volume size should be relative to the size of the files you're storing in them. Also it is good practice to separate small and large files in different storage pools. Small files => smaller volumes, large files => large volumes. You can do this by specifying maximum file size that can be stored in a certain storage pool so you have for example stgpool SMALL with sizelimit 1GB and volume size 1GB and use a stgpool LARGE with 10GB volumes as its NEXTSTGPOOL.

If you're backing up 50GB VMware images or SQL databases it makes sense to have volume sizes on the order of ~10GB. With small client files I'd go with 1GB volumes. Ofcourse, another factor to consider here is whether you have much new daily data or maybe just a lot of changed daily data.

For TSM purposes, 1 Logical drive should correspond to 1 disk array, can't see a reason to use more logical drives except maybe to separate beginning of a disk (which has faster transfer rate) and end of the disk (slower transfer) if you need this kind of optimizations. Another reason would be more flexibility when upgrading or reformating disks.

By the way, if you have just one large array with all your disks in it, consider what will happen when a disk fails and needs to be reconstructed... your whole storage performance will be degraded until reconstruction is complete, test whether this is acceptable BEFORE your first disk actually fails.