|
Re: [Networker] Total speed of backup leaves to be desired
2009-04-27 17:43:31
On 28/04/2009, at 24:35 , Stan Horwitz wrote:
From: "Terveen, Frank" <Frank.Terveen AT AFM DOT NL>
Reply-To: EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>,
"Terveen,
Frank" <Frank.Terveen AT AFM DOT NL>
Date: Mon, 27 Apr 2009 16:26:19 +0200
To: <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
Subject: [Networker] Total speed of backup leaves to be desired
Dear All,
After a "specialized" company did our legato networker upgrade and
install of
our new taperobot we are not getting the desired speeds we would
like to have
I recommend you read the NetWorker Performance Tuning Guide. You can
find it
on PowerLink.
The original post also mentioned the size of the environment, using
LTO-4 and expecting LTO-4 to make at least 80 to 100 MB/s, and like to
comment on that in addition to Stan's recommendation that you read the
performance tuning guide.
The biggest struggle backup has with LTO-4 is that for the most part
its a format that exceeds the capability of most environments to
service its data bandwidth needs. The native speed of LTO-4 is 160 MB/
s - it wants to get 160MB/s throughput. That basically requires a
dedicated 2Gbit HBA per drive, just at the server side, just to drive
the native speed. Then you get into compression.
The common mistake people make when either buying or configuring LTO-4
is assuming there's a linear decrease in drive performance as data
throughput decreases. If your environment can only supply 80MB/s to
the drive, it may be that 80MB/s is not a speed the drive is capable
of working at ... these days drive manufacturers employ "stepping"
speeds to reduce drive speed on lower speed input, but this stepping
speed may result in a lower speed again than 80MB/s, or very poor
performance trying to achieve that amount. In short, you only get a
good speed if you send a good speed.
Not only that, the original post mentioned a company with about 500
users and lots of small files. If this is the case, you need to
consider the impacts of filesystem density - the cost of walking a
dense filesystem (i.e., one with lots of small files) is quite high,
and has a significant impact on the backup, no matter what backup
product you use, when you work _through_ (as opposed to say, under)
the filesystem.
(One good way to check out performance yourself is to isolate a
typical section of the filesystem and create an uncompressed zip file
to another filesystem of it. (It's not going to go as fast as bigasm
either.) Walking the filesystem takes time, measurable time, no matter
what you're using to do it.)
As has also been commented on many times on this list, it's
unrealistic for most companies to expect to write to LTO-4 as a first
stage in the backup process at full speed even uncompressed, let alone
compressed. Unless you have huge server farms, or 10Gbit ethernet with
huge files (etc, etc), you just can't do it.
Instead, most companies need to insert a disk layer into the backup
system - whether that be ADV_FILE or VTL it doesn't really matter; but
you need to first backup to disk, then optimise the data transfer from
disk to tape in cloning and staging operations to have a hope at
driving LTO-4 to anything approaching its full speed.
I don't think you're going to find an easy answer to your questions,
because I don't think your current architecture is suitable for front-
line use with LTO-4, based on the descriptions you've given.
Cheers,
Preston.
--
Preston de Guise
"Enterprise Systems Backup and Recovery: A Corporate Insurance Policy":
http://www.amazon.com/Enterprise-Systems-Backup-Recovery-Corporate/dp/1420076396
http://www.enterprisesystemsbackup.com
NetWorker blog: http://nsrd.wordpress.com
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
|
|
