Veritas-bu

Re: [Veritas-bu] DSU Question.

2009-03-28 15:27:02
Subject: Re: [Veritas-bu] DSU Question.
From: "Mike Andres" <mandres AT Brocade DOT COM>
To: "Andrew Sydelko" <andrew AT sydelko DOT org>, <veritas-bu AT mailman.eng.auburn DOT edu>
Date: Sat, 28 Mar 2009 13:23:52 -0600
It really does come down to the nature of SATA.  In larger arrays the
controllers can easily outrun the disk.  I've done extensive testing
around backups to SATA (mostly in a VTL config, but basic disk works
just the same).  What I generally see is the following.  Say I have 4
SATA LUNs on 4 different raid groups.  Next I create 4 virtual tapes on
each of those LUNs.  I start one dd /dev/zero copy to the first tape on
the first LUN, I see approx 50MB/s - that's the peak transfer rate per
LUN.  I start a second dd to the first tape on the second LUN, I see an
additional 50MB/s.  Start the other two to the other two LUNs and I get
an aggregate of 200MB/s.  Now I add another copy to the second tape on
each of LUNs and rather than seeing an aggregate increase in speed above
and beyond that 200MB/s I had I actually see a drop in overall speed.  

Bottom line is the nature of SATA is that it tanks under random IO, it
is best suited for sequential.  Many folks think backup is sequential
and they are right, when you consider one backup.  Once you get many
backups running concurrently you approach a very random IO pattern and
SATA hates that.  

I've seen an array peak at 800MB/s using one backup per LUN (which was
set up as one LUN per RAID group).  That's the controller peak
capability.  That same array gives me around 250MB/s on average each
night when there are 70-80 concurrent streams hitting it.

-mike

-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Andrew
Sydelko
Sent: Saturday, March 28, 2009 12:37 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] DSU Question.

On Sat, 28 Mar 2009 09:55:04 -0500
Ed Wilts <ewilts AT ewilts DOT org> wrote:

> On Sat, Mar 28, 2009 at 1:07 AM, Dean Allen <dean.deano AT gmail DOT com>
wrote:
> 
> > Before you get too far into design, you should work out how fast the
> > backups to disk actually are. This can have a big influence on how
you
> > use your DSSU. I have a 3TB DSSU, (RAID 6 SATA) and I can't get any
> > better than about 50 MB/sec out of it (usually about 30 MB/sec). I
can
> > get the tape drives up to 150 MB/sec. The majority of people seem to
> > think backing up to disk is going to be faster, but that's not
> > necessarily the case.
> 
> 
> I concur 100% - this has been our experience as well.
> 
> SATA drives are cheap, but they're slow.   You'll do about half the
> transactional rate of a good fibre channel or SCSI drive.
> 
> Many people think that because "it's just backups" that you can use
cheaper
> SATA drives.  It's actually the opposite - backups are the highest I/O
> generator, by far, in many environments.

This really depends on the controller in use. There are controllers out
there that will do 400MB/s or faster. We have 3ware and Areca
controllers that do just this. This allows us to use multiple FULL
gigabit connections in from clients as well as stage to multiple LTO3
tape drives at the same time using one media server.

--andy.
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
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>