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.
|
