I agree with the principle of what you say, though it is only practical if
your storage units are configured in a way that allows that. It would be
pretty easy and sensible for example with Oracle servers that have SAN
Media Server, and hence a Storage Unit that is only used to backup the
Oracle server's own data, to set a large fragment size, as the files are
likely to be large. Looking at the output of bpimaglelist is a good way
to do this, see
http://www.encephalon.com/perl/veritas-Netbackup_bkrep.txt.
However general purpose Media Servers cannot really do this, so a
compromise is needed.
I agree with Brian Bahnmiller that the tape accelerate/decelerate time is
a major factor in performance of the backups, and the fragment size needs
to be large enough to reduce the significance of this.
I'm not sure I agree that modern tapes can get round the need to fast
position to the file, and then slow scan the file. As I understand it
NetBackup is tracking the fragment (effectively file on tape) in which a
file is located, so for a restore it can use this to fast position. That
I believe is the reason to keep the fragment small, though as Gideon
Wheeler says it depends on the file size. I guess the ideal would be that
the fragment exactly matched the file size so each file was a fragment,
for this purpose only - clearly unattainable unless you have very neat
data file sizes.
Opinion seems to be that a size > 8GB, maybe 16 or 20 and as much as 32GB
is sensible. I must admit that is much less than I was thinking, given
the default for NBU 6 is 1TB!
My rough calculation suggests that at ~60MB/s a 32GB fragment takes a
little over 9 minutes to write, and a 16GB fragment just over 4 1/2
minutes. So in terms of seeing the fragments tick up one can take a
choice. I think the larger fragment does more to reduce the
accelerate/decelerate time, so I think I will try that and see how it
goes. Hopefully I can find time to test this in our lab. As we are
looking at D2D2T using SLPs, it is also affected by the fragment size on
the disk staging storage unit (actually AdvancedDisk). Those are large,
designed to make the destaging go fast. In fact I wonder if I can aim for
that ideal that each disk fragment exactly fits each tape fragment, i.e.
make them the same size or at least an exact multiple. On disk I care
about how many fragments there are as it will affect the performance of
the file system if there are millions of small fragments.
Thank you all for the responses.
William D L Brown
veritas-bu-bounces AT mailman.eng.auburn DOT edu wrote on 17/09/2009 06:42:46:
> I agree a 2GB fragment size for an LTO3 / 4 drive is a little on the
> small size, but rather than choosing the fragment size to fit the
> tape technology perhaps it would be useful to select fragment size
> based on the type of the data we are backing up. Large single file
> data such as image, audio or exported databases etc. would benefit
> from using the larger fragment sizes. Database Agent orientated
> backups such as RMAN / MSSQL could use a fragment size based on
> their fileset size or multiple thereof. Whilst User home accounts,
> source code project directories would use the smaller settings. Of
> course all this only applies to non NDMP backups.
> There is an advantage of using fragment sizing in that?s it a great
> way of determining tape throughput. It?s easy to calculate the speed
> of a backup if you know that its taking t minutes to backup a 2 or
> 20GB fragment rather than waiting t hours for a terabyte.
> Psychology: Nothing is more re-assuring then seeing the fragment
> markers count up in the job details panel. Its good indicator that
> all is well with that client.
> As to the overhead of fragment markers in the catalogue I have no
idea.
> Just my 2-bits worth.
>
> Gideon Wheeler_______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
-----------------------------------------------------------
This e-mail was sent by GlaxoSmithKline Services Unlimited
(registered in England and Wales No. 1047315), which is a
member of the GlaxoSmithKline group of companies. The
registered address of GlaxoSmithKline Services Unlimited
is 980 Great West Road, Brentford, Middlesex TW8 9GS.
-----------------------------------------------------------
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
