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 rogerd AT uic DOT edu
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 AT VM.MARIST DOT 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 |
>| | <orville.lantto@GLAS|
>| | SHOUSE.COM> |
>| | Sent by: "ADSM: Dist|
>| | Stor Manager" |
>| | <ADSM-L AT VM.MARIST DOT ED|
>| | U> |
>| | |
>| | |
>| | 03/13/2006 01:40 PM |
>| | Please respond to |
>| | "ADSM: Dist Stor |
>| | Manager" |
>| | |
>|---------+------------------------------->
>
> >----------------------------------------------------------------------------------------------------------------|
> |
> |
> |
> |
> |To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT 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
>
|
