> clarify a few things. I'm trying to get my throughput up to an
> appropriate speed to avoid shoe shining and also cut down my
> backup
> windows. We have 2 LTO3 drives (with LTO3 tapes, obviously).
> 
> There are 2 specific objectives I'm trying to achieve:
> - send multiple jobs from a single policy to a single drive
> concurrently. I'm thinking 3 concurrent jobs should be fine
> initially.
> Once one of the clients finishes, another is added to the job.
> - send multiple streams (e.g. 3 streams) from a SAN client to a
> single
> drive. Once one stream finishes, another is added to the job.
> 
> I've already got the Global Attribute of 'number of jobs per
> client' at
> 99 (I think it was set like this for MS-SQL backups) so this
> doesn't
> need to be configured. 'Maximum concurrent write drives' is set to
> 2 for
> storage units.
> 
> For the first objective, I think I need to change a few settings;
> 'Maximum streams per drive' on appropriate storage units (set to
> 3),
> 'Media multiplexing' (set to 3) on schedule in policy. Does this
> sound
> about right? Do I need to worry about 'Limit jobs per policy'
> setting?
> 
> The second objective is a bit more confusing. Is it simply a case
> of
> setting the same settings as the first objective (but on
> appropriate
> storage unit and policy), setting the streams in the backup
> selection
> tab on the policy and the 'Allow multiple data streams' setting on
> the
> policy.
> 
> I know to get the most out of this I'll need to tweak a few things
> to
> get ideal numbers for the settings but just trying to understand
> exactly
> which setting I need to configure for the things I'm trying to do.

You may be overthinking this.  Generate a bunch of streams and send
them to storage units with multiplexing set high enough to keep the
drives spinning.

o  don't worry about "multiple jobs from a single policy to a single
drive," or the like, if you really mean to control it like that
(perhaps it is just your phrasing, not your intent).  

o  generate as many streams as you productively can

o  set STU max concurrent drives to as many as the STU has
(generally)

o  set max mpx for a STU to the value you guesstimate/testimate the
drive-type can handle productively

o  set the mpx in schedules as if that many streams, considering the
policy type, its clients and the schedule type (full should be
sending a more robust stream of data than an incremental, for
instance) were going to one of the STU's drives

o  remember that the more pools you use, the less sharing of streams
to drives will happen; same thing with retention periods

o  verify your intent is being realized--look at the active jobs and
see if you're getting N streams all going to the same mediaID, that
all the drives you want to use in a STU are being used... 

o  remember that a given client will be able to send data only so
fast; more simultaneous clients is often more effective than more
streams from fewer clients... more clients may saturate the network
segment... maybe everything goes through one switch or one link to
the media server... all the normal throughput items that have
nothing to do with STUs and multiplexing

o  IMO, there is no better investment than time (or dollars if you
contract it out) spent in a rigorous tuning exercise to optimize
throughput.  Taking wild guesses "hey, I have LTO3s; what should I
set my buffer size to" may be better than no change but is unlikely
to be optimal.  size/number data buffers, representative data, net
buffer size, communications buffer size, understanding your network
config and hardware... 

o  assess throughput with real or at least realistic backup load and
adjust fire.


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu