We buy slightly used Power equipment for TSM, and are extremely happy
with the cost comparisons and the performance. You can get a lot of work
done with a used, higher-end P6.

When TSM gets down to some of its serious computation tasks such as
expiration, delete filespace, reclamation, and deduplication, you need a
lot more processing and I/O horsepower than you can get from commodity
equipment. The only alternative we would seriously consider is Sun
SPARC.

Some tasks such as web page serving and email can easily be broken up
into chunks and run on commodity equipment working against a central
NAS/SAN infrastructure, and we do this. TSM does not fit this model
without a LOT of additional management effort. TSM needs fewer, larger,
faster computers, which is also cheaper in terms of environmentals such
as power, cooling, and floor space.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
======I have not lost my mind -- it is backed up on tape somewhere.=====


On Wed, 16 Nov 2011, Hans Christian Riksheim wrote:

>I am not of any help here but you say you are moving to Linux because
>it is cheaper.
>
>Our Power servers running TSM accounts for less than 3% of the yearly
>total cost for our backup infrastructure. Then we include licenses and
>man hours in addition to hardware and data center costs(floor space,
>power and cooling).
>
>Cutting off a little of those 3% is not an option for us if it means
>moving away from a rock solid platform. Even if Linux on Dell was
>handed to us free of charge we would stay on Power. But YMMV.
>
>Anyone else done the same calculation and found out what the cost of
>the physical servers amount to compared to total cost for the TSM
>infrastructure? Maybe you should.
>
>Hans Chr.
>
>
>
>On Wed, Nov 16, 2011 at 4:47 PM, Dury, John C. <JDury AT duqlight DOT com> 
>wrote:
>> Our current environment looks like this:
>> We have a production TSM server that all of our clients backup to throughout 
>> the day. This server has 2 SL500 tape libraries attached via fiber. One is 
>> local and the other at a remote site which is connected by dark fiber. The 
>> backup data is sent to the remote SL500 library several times a day in an 
>> effort to keep them in sync.  The strategy is to bring up the TSM DR server 
>> at the remote site and have it do backups and recovers from the SL500 at 
>> that site in case of a DR scenario.
>>
>> I've done a lot of reading in the past and some just recently on the 
>> possible ways to migrate from an AIX TSM server to a Linux TSM server. I 
>> understand that in earlier versions (we are currently at 5.5.5.2) of the TSM 
>> server it allowed you to backup the DB on one platform (AIX for instance) 
>> and restore on another platform (Linux for instance) and if you were keeping 
>> the same library, it would just work but apparently that was removed by IBM 
>> in the TSM server code to presumably prevent customers from moving to less 
>> expensive hardware. (Gee, thanks IBM! <sigh>).
>> I posted several years ago about any possible ways to migrate the TSM Server 
>> from AIX to Linux.
>> The feasible solutions were as follows:
>>
>> 1.       Build new linux server with access to same tape library and then 
>> export nodes from one server to the other and then change each node as it's 
>> exported, to backup to the new TSM Server instead.  Then the old data in the 
>> old server can be purged. A lengthy and time consuming process depending on 
>> the amount of data in your tape library.
>>
>> 2.       Build a new TSM linux server and point all TSM clients to it but 
>> keep the old TSM server around in case of restores for a specified period of 
>> time until it can be removed.
>>
>> There may have been more options but those seemed the most reasonable given 
>> our environment. Our biggest problem with scenario 1 above is exporting the 
>> data that lives on the remote SL500 tape library would take much longer as 
>> the connection to that tape library is slower than the local library.  I can 
>> probably get some of our SLAs adjusted to not have to export all data and 
>> only the active data but that remains to be seen.
>>
>> My question. Has any of this changed with v6 TSM or has anyone come up with 
>> a way to do this in a less painful and time consuming way? Hacking the DB so 
>> the other platform code doesn't block restoring an AIX TSM DB on a Linux 
>> box? Anything?
>>
>> Thanks again and sorry to revisit all of this again. Just hoping something 
>> has changed in the last few years.
>> John
>>
>