Veritas-bu

Re: [Veritas-bu] Netbackup 6; tuning with [mpx/streams] [SEC=UNCLASSIFIED]

2009-11-17 21:55:47
Subject: Re: [Veritas-bu] Netbackup 6; tuning with [mpx/streams] [SEC=UNCLASSIFIED]
From: "Wilkinson, Tim" <Tim.Wilkinson AT dsto.defence.gov DOT au>
To: <bob944 AT attglobal DOT net>, <veritas-bu AT mailman.eng.auburn DOT edu>
Date: Wed, 18 Nov 2009 13:55:36 +1100
UNCLASSIFIED

Thanks bob - a fair bit of food for thought there!

You're possibly correct in that I'm overthinking things a bit; we don't
have a huge backup environment so I tend to focus on control and
specifics quite often when I don't need to. Getting streams out is the
way to go.

I do have to be a little careful as many of the NBU clients are virtual
machines on the same storage array and I need to consider the affect on
the storage array.

-----Original Message-----
From: bob944 [mailto:bob944 AT attglobal DOT net]
Sent: Tuesday, 17 November 2009 7:00 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Cc: Wilkinson, Tim
Subject: RE: [Veritas-bu] Netbackup 6; tuning with [mpx/streams]

> 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.



IMPORTANT: This email remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this email in error, you are
requested to contact the sender and delete the email.
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

<Prev in Thread] Current Thread [Next in Thread>