Hmmm. I'm facing a similar issue, even though my database is "only" 210 GB. But mine churns a LOT. Finding time for expiration is driving me nuts. I've been designing an approach that will let me either run multiple images on one server, or to distribute them to separate physical machines. Realistically, I think I'm going to wind up with six images spread across two large AIX boxes in two separate locations a mile apart.
Alan Rout of the University of Florida has done a lot of work towards standardizing and rationalizing this server-splitting process. Comments, Alan? But as we've grown into our present performance crunch, one thing has become clear - being a TSM server is a 24-hour workload. So you can't borrow cycles from your clients, except by forcing them to do the client compression work for you. Problem is, you can say the hard work is the backing up all night, but that's only half of it. We spend all day running migration, expiration, storage pool backup, dead filespace deletion (ouch!), DB backup, and downtime for maintenance. These are tasks you cannot distribute to a client system which has its own job to do in the daytime. If anything, our database is busier by day than at night. Furthermore, the administrator of a client system might really resent having its potential maintenance downtime hours so badly restricted. So I'd actually say, your greatest struggle with this notion will be political, but as has been said, your're also going to have a bear of a time organizing it all, especially on systems you do not directly control. I think you will be overwhelmed. There is no free lunch, sorry to say. P.S. Orville is right about licensing. A license is sold based on the number of processors - client or server. If you add a 4-processor system to your environment, whether it serves as TSM client, TSM server, or both, it counts as +4 towards your grand total. This slightly, but not strongly, favors running your TSM servers on systems with extremely fast individual processors. (IBM sells these.) Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] On Mon, 13 Mar 2006, Orville Lantto wrote: >TSM licenses (and pricing) has been based on the environment for some years. Check with your IBM Business Partner to get the details. > >Orville L. Lantto >Glasshouse Technologies, Inc. >Cell: 952-738-1933 > > >________________________________ > >From: ADSM: Dist Stor Manager on behalf of Robin Sharpe >Sent: Mon 3/13/2006 2:19 PM >To: ADSM-L@VM.MARIST.EDU >Subject: [ADSM-L] TSM Server Hosting - dedicated vs. shared > > > >Orville, >Thanks for your thoughts. We do use Control-M for all of our scheduling in >the Unix environment, and are moving towards Windows deployment too. >I am surprised, though, about your comment on licensing. I thought each >TSM server instance on a separate physical server needed a license (per >processor). Is this not true? Is it a new policy? > >Robin Sharpe >Berlex Labs > > >|---------+-------------------------------> >| | Orville Lantto | >| | <[EMAIL PROTECTED]| >| | SHOUSE.COM> | >| | Sent by: "ADSM: Dist| >| | Stor Manager" | >| | <[EMAIL PROTECTED]| >| | U> | >| | | >| | | >| | 03/13/2006 01:40 PM | >| | Please respond to | >| | "ADSM: Dist Stor | >| | Manager" | >| | | >|---------+-------------------------------> > > >----------------------------------------------------------------------------------------------------------------| > | > | > | > | > |To: ADSM-L@VM.MARIST.EDU > | > |cc: > | > |Subject: > | > | Re: > | > > >----------------------------------------------------------------------------------------------------------------| > > > >The approach is valid and can reap significant backup/restore time benefits >for the clients. >Two points: > > 1) No new licensing cost are involved. TSM is >licensed by the environment, not the number of TSM servers. > > 2) Consider the complexity of resources scheduling >between many servers. Most sites have a limited number of tape drives and >contention can be a bear to schedule out with so many independent servers >and their separate schedulers. An external admin scheduling utility may be >needed. > > >Orville L. Lantto >Glasshouse Technologies, Inc. > > > >________________________________ > >From: ADSM: Dist Stor Manager on behalf of Robin Sharpe >Sent: Mon 3/13/2006 11:03 AM >To: ADSM-L@VM.MARIST.EDU >Subject: [ADSM-L] > > > >Dear colleagues, > >It's time for us to split our TSM into several new instances because our >database is now just too large -- 509GB -- and still growing. My initial >plan is to create five TSMs - four plus a library manager - on the existing >server (an 8-way, 12GB HP rp7410 with 15 PCI slots). This is cost >effective since no additional hardware or license is needed - just lots of >SAN disk for the databases, which we have available. But, I've been >thinking.... what do you think about the following: > >A more "creative" approach is to place the "new" TSM servers on existing >large clients. This has several advantages: >- eliminates need to acquire new servers, saving physical room, power >and cooling requirements, additional maintenance. >- client benefits by sending its backup to local disk using shared >memory protocol. Eliminates potential network bottleneck. >- Client sends data to tapes using library sharing; no need for storage >agent. >- Use of local disk eliminates the need for SANergy >- heavy clients "pay" for their usage by providing backup services for >smaller clients. > >There are also some concerns (not necessarily disadvantages): >- May require CPU, memory, and/or I/O upgrades (still cheaper than >buying a server) >- TSM operation may impact client's primary app. Can be controlled by >PRM on HP-UX. >- Incurs licensing cost. > >Thanks for any insights.... >Robin Sharpe >Berlex Labs >
