Suad, Have you considered a strategy where you give the desktops access to
network drives on a "few" servers that would be backed up incrementally?
Trying to back up hundreds of desktops in a small window is a bunch more
resource intensive from the TSM servers standpoint than backing up a few
servers.

George Lesho
Storage/System Admin
AFC Enterprises





Suad Musovich <suad AT CCU1.AUCKLAND.AC DOT NZ>@VM.MARIST.EDU> on 10/30/2001
07:33:17 PM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: George Lesho/Partners/AFC)
Fax to:
Subject:  Server->Server Virtual Volumes (philosophical)


Sorry, this got a bit long winded..

Our monolith TSM installation is suffering from client overload,
specifically
hundreds of desktops queueing to be backed up every morning (we only give a
4 hour
window to desktops after servers have finished).
Several times this month some glitches with our tape library(plus
performance
issues) have resulted in the disk stg pools filling up and sessions start
queuing
directly to tape. When this happens around the time the of the desktop
backup
window, we end up with dozens of media waits and the dreaded MAXSESSIONS
gets
reached (MAXSCHEDSESSIONS was set to 30%)

Of all the options I considered, farming off the bulk of the desktops to
another
TSM server and using the "Server-to-Server" Virtual Volumes seems to be the
most
attractive.
(Management have declined my BOFH proposals; desktops give us Brownie
points and
have been implemented since the year dot).

I would appreciate any comments as I think this implementation may have
been meant
more for fringe deployments than dealing with rats'n'mice.

The desktops (up to 300 of them) are only backing up the documents/data
directories
with an estimated average occupancy of 1GB and nightly backup about 30% of
that
(think it's more the System Object than data). They are also, mainly, in
logical
proximity to a sector switch, where the 2nd TSM server will be located.

Info/questions:
* The server we are looking at will be a dual CPU Windoze box (Linux
server, where
  are you?), 2 NICs, local tape unit and have around 100GB of backuppool.
* We can give them a full 12+ hour backup window and control the migration
times
  to the virtual volumes (migrating the backuppool at apropriate times).
* I don't think the database will get bigger than 20GB.
* Total Occupancy should be somewhere between 400 and 600GB
* I'm not sure how big the virtual volumes should be (600MB seems a good
size for
  streaming off LTO tapes through 155ATM = allowing ~60seconds per volume).


The main TSM server is RS6K-F80/AIX running TSM4.2.0 connecting to a
3584/LTO and
an ESS via FC, I've set up a LANE ATM connection to the above sector switch
reducing routing overheads for the back-end/private traffic.

Does it sound Kosher??

Thanks, Suad
--
 Suad Musovich (s.musovich AT auckland.ac DOT nz)
 Suad Musovich (s.musovich AT auckland.ac DOT nz)
 Unix Support, ITSS Operations
 University of Auckland