Veritas-bu

[Veritas-bu] LTO3 throughput on Vault/Duplication jobs

2006-09-19 10:09:16
Subject: [Veritas-bu] LTO3 throughput on Vault/Duplication jobs
From: Jonathan.Dyck at cognos.com (Dyck, Jonathan)
Date: Tue, 19 Sep 2006 10:09:16 -0400
Agreed.  Coming from an environment where we are "afraid" of
multiplexing everything due to those image's importability (or lack
thereof), the fact that we cannot demux quick enough has us handcuffed a
little.
 
Just a question, what's the rationale on mpx'ing to your VTL's?
 
Cheers,
Jon

________________________________

From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Paul
Keating
Sent: Tuesday, September 19, 2006 8:50 AM
To: Liddle, Stuart; veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO3 throughput on Vault/Duplication jobs


It's not fishy....your problem is the demultiplexing.....no question.
 
you want to be reading one "virtual tape" and writing to one "physical
tape".....when you're finished reading that virtual tape, you load
another and keep going.
 
In your case, you're loading a virtual tape, reading 256k, skipping
ahead on the disk abit, reading another 256k, skipping ahead somemore,
etc, etc, and then reassembling that and writing it to a tape...in the
mean time, you probably have another job that's jumping in between those
256k blocks and trying to get some different blocks to write to a
different tape...I believe the docs even warn that this will cause poor
duplication performance.
 
instead of shooting from VTL to tape, you' have several jobs pulling
little bits from all over your VTL, then reassembling them and trying to
write them to different tapes......a NIGHTMARE wrt performance.
 
Either use the "preserve multiplexing" option, which will do a straight
dupe, without all the sourcing and assembling....or......create more
virtual drives on the VTL, and don't multiplex you original backups....
 
for example:
if you have 4 virtual drives, and MPX=4, instead create 16 virtual
drives, and turn MPX off.
 
you're actually having to read 100MB/s off the VTL to get enough data to
assemble into a 11MB/s stream for your tapes.
 
Paul
 
 
-- 

        -----Original Message-----
        From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Liddle,
Stuart
        Sent: September 18, 2006 9:08 PM
        To: veritas-bu at mailman.eng.auburn.edu
        Subject: [Veritas-bu] LTO3 throughput on Vault/Duplication jobs
        
        

        ALL,

         

        we have an issue with LTO-3 drive performance.  

         

        Our environment is set up as follows:  

        *       a single master server running Solaris

        *       4 Linux media servers

        *       4 Windows media servers

        *       ADIC i-2000 tape library with 16 LTO-3 drives that are
shared on a SAN to all of the media servers with SSO

        *       five NetApp VTL's that have multiple virtual libraries
on each one.  Each media server is connected to two virtual libraries
(also over the SAN)

         

        We do all of our backups to the VTL's and are using Vault to
make duplicate copies to the physical tapes.  We are multiplexing to the
VTL's and then de-multiplexing to the physical tapes.

         

        We are currently seeing only about 11MB/sec going out to the
physical tapes.  However, our read performance on the dups is averaging
about 80 - 100+ MB/sec from the VTL's.

         

        Is anyone else doing something like this and are you getting
better throughput to your physical tapes using Vault?

         

        Symantec told us today that doing a single-stream to the
physical LTO-3 drives was only going to do about 8 or 9MB/sec and we
should "Preserve Multiplexing" for the output in order to get better
throughput to the physical tapes.

         

        Does this sound right?  It's sounding kind of fishy to me.   We
have our buffers set as follows:

         

        NUMBER_DATA_BUFFERS:   128

         

        SIZE_DATA_BUFFERS:  262144

         

         

         

        thanks......

         

        --stuart
 
     This message may contain privileged and/or confidential information.  If 
you have received this e-mail in error or are not the intended recipient, you 
may not use, copy, disseminate or distribute it; do not open any attachments, 
delete it immediately from your system and notify the sender promptly by e-mail 
that you have done so.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060919/c2be5733/attachment.html