Hi All I'm looking at some new TSM servers and I must say that the newest hardware gives great bang for your buck.
In my current production environment (Sun X4540 x86_64 with gobs of main memory and 48x1TB drives, Solaris 10 and TSM 5.5) one issue is disk IO bandwidth, and another is the number of available IO slots for HBAs. I've got my database on raw SAN volumes on a fairly high-performance SAN, but still operations with lots of small files, such as reclaims, can be very slow. Also the ZFS filesystem uses software RAID 6, and ZFS can only use 80% of the available space before it changes its write strategy to the detriment of performance. This means that I can only use effectively half of the available space after hot spares, raid overhead and ZFS overhead are taken into account. I'm considering that the next generation of TSM Servers should be somewhat smaller, like a Sun X4270 M2 or a Dell R510 with 2TB drives for bulk storage plus a couple of 300GB 15Krpm drives each for OS and database . I will probably run RHEL5 on these and use TSM 6.2 and both client and server side deduplication as appropriate. This will allow CPU for deduplication, hardware rather than software raid and EXT3 rather than ZFS to make better use of the available space. Both Sun and Dell offer solid state disk drives, but these are of limited capacity, say 100GB. If I were to use SSD, what is the best way to configure the TSM 6.2 database to get the value from these drives? My 15 year-out-of-date mainframe experience with DB2 leads me to believe that the active log is the best bet for SSD, since a commit to the active log is required to end any transaction, the flush of the DB2 buffers to disk can happen well after that, and I will have a lot of memory to enable DB2 Bufferpools to perform. Am I right? and since there is more space on SSD than active logs will need, what else could I productively put there, and how is it possible to control the placement of DB2 tables and indexes? Regards Steve. Steven Harris TSM Admin.
