I'd hate not to disagree with someone as grumpy and disagreeable
as Ed. Personally, I wouldn't take advice on this matter from someone who
"worked with disk staging units for at least a year" and "gave
up." (Also, I think Ed is a wet blanket.) I had this thing figured out 4
years ago when we first implemented DSSUs in production. I may not be the
biggest NBU shop on the planet, but I back up more than 50TB a week using this
method exclusively, so I can tell you that it does work.
As far “interleaving”, there is most
certainly interleaving at the file system level when you run multiple streams
to a DSSU. How Ed can say there is no interleaving and then tell you to watch
your disk fragmentation is beyond me. Fragmentation = disk interleaving as far
as I am concerned. The point is that the files are non-contiguous.
Here’s my proof.
This is a snippit of a utility called DiskView from
SysInternals / Microsoft. The yellow bits are the actual 1K fragments of data
on disk for that image file above. The little red dots indicate the beginning
and end of file fragments. There are 64 little yellow dots between the red dots
indicating my 64K clusters.
Here’s that same section of disk, different image
file. These two streams ran simultaneously last night (along with 6 others) and
I can guarantee you that the top image wrote faster, and will destage to tape
faster than the image below.
Why? Imagine you are bpdupicate.exe requesting the first
file back to write to tape. Compared to the 2nd image, you are going
to get a lot more reading done and a lot less seeking as your head(s) cross the
disk to pickup fragments. Or, so goes my theory. There is a utility
available from Dell that will show me the amount of time spent reading /
writing versus seeking per disk but I didn’t have the time to acquire it and
test.
Now, I know there are variables here. As I stated before,
one of the big improvements to my speed was using a 64K cluster size. Last time
I checked this wasn’t available in Unix/Linux. Then again, ext2/3 file
systems also like to leave “space” between their writes to account
for file growth, which may help (but I doubt it.) I intended to test this
several years back, but my management put the kibosh on Linux media servers.
The raid controller, simultaneous read/write, spindle count, and disk type also
add a lot of variability.
I haven't tested any of this on a SAN volume, only on
direct attached. I don't think there is much to be gained by taking a 6TB lun
and partitioning it at the OS or breaking it into multiple luns at the
SAN. After partitioning, the entire DSSU is still on the same raid group
/ set, which ultimately controls your performance. If you could take your 6TB
lun and break it into 3 x 2TB raid groups / luns then I think that would help.
I’ve actually considered breaking my 14 disk RAID5s into 14 single disks
for performance testing (single stream each), but that’s an entirely
different management nightmare (14 DSSUs per media server etc…) A single
SATA disk can drive LTO3, assuming the data is all nicely lined up. The
minute that head has to go seeking, you are in a world of hurt.
Again, I would start with a single stream to that 6TB
DSSU and see what you get both writing to the DSSU and destaging to tape.
Whatever performance you get out of that configuration is your best case
scenario. Multiple streams or creating multiple partitions will only drag your
numbers down. The crux of the issue (at least for me) is balancing the number
of streams I need to run to get my backups to DSSU within my windows, versus
the destaging speed I need to get that data off to tape on time.
Good luck,
-Jonathan
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Ed Wilts
Sent: Wednesday, May 05, 2010 4:06 PM
To: Victor Engle
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Architectural question (staging)
On Wed, May 5, 2010 at 2:57 PM, Victor Engle <victor.engle AT gmail DOT com> wrote:
So my question is how best to configure the DSSUs with the
goal of
optimized de-staging. I will have 6TB to configure as desired on the
backup server. If I understand correctly, the more concurrent streams
allowed to the DSSUs, the slower the de-staging because of interleaved
backup streams.
The DSSU consists of a set of files with each file being a backup image and you
define the maximum size of each file within an image. There is no
"interleaving". When you destage, one image at a time goes to
tape.
Watch your fragment sizes and watch your disk file system fragmentation...
.../Ed