Veritas-bu

[Veritas-bu] NetBackup Disk Staging Performance Questions

2007-03-01 09:23:55
Subject: [Veritas-bu] NetBackup Disk Staging Performance Questions
From: pkeating at bank-banque-canada.ca (Paul Keating)
Date: Thu, 1 Mar 2007 09:23:55 -0500
The only thing that screams at me from below is the NetApp 3020.
 
Since the 3020 is, AFAIK, a NAS filer (At least the one I have is), are
you saying that the 3020 is mounting the LUNs from the the Arrays and
then the Windows media server is using CIFs shares from the NetApp as
DSSUs?
 
If that's the case, then you're not running NTFS on the windows host,
but actually WAFL on the filer. WAFL is fragmented by nature, and
doesn't need to be defragged
 
Also, if using the NAS, then Network throughput is going to be a huge
issue.
 
If your 3020 has a NetApp disk array and you're provisioning that to the
Windows host as block level devices, rather than going through the NAS
head, then disregard the above.
 
The IOPS shouldn't be an issue. you should be able to get very good
performance from SATA on a 9585, assuming you have a well thoughout disk
layout.
 
How big are the RAIDgroups? what is the layout? (RAID 5 or 6 or 10) and
how any spindles per RG?
How many LUNS are configured on each RG?
Are you using concatenated LUNs (HDS LUSEs) or a stripe over multiple
LUNs?
Since you can't stripe across RGs (the 9585 definately doesn't allow you
to), are you just providing one LUN  from one RG, and hence one
controller to the host? or multiple LUNs from multiple RGs on separate
controllers, and striping them with a host based volume manager, like
Veritas Storage Foundations?
 
All of these things will have a great effect on throughput to disk, and
therefore how long it takes to defrag as well.
 
Oh.....The time you're seeing for the defrag likely isn't the IOPS
killing the SATA drives, it's probably more that every host is going
direct to the disk, because the cache is constantly flushed. A defrag on
a 1TB FS is going to KILL the cache on your array......every host on
that array is going to feel it.
 
I've had a 36 Gig local disk on a windows host take like 16 hours to
defrag. I would think 1% in 8 hours is fairly good on a 1TB fs on a
shared array.
 
Paul
 
-- 

        -----Original Message-----
        From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Anthony
Segran
        Sent: February 28, 2007 11:35 PM
        To: veritas-bu at mailman.eng.auburn.edu
        Subject: [Veritas-bu] NetBackup Disk Staging Performance
Questions
        
        

        Hello All

         

        I am working with one of my favorite customers and they have
raised a few questions on issues faced in their NetBackup v6.0 MP4
environment. You would certainly see various customer configurations out
there and I am sure we have many large customers with NBU implemented on
Windows. Could you please share your thoughts and experiences on dealing
with the issues faced and highlighted below.

         

        Your input and feedback would be much appreciated.

         

        Couple of things here, which revolve around DSSU's. We have
problems with fragmentation on our DSSU's (Windows Servers attached over
FCP to SATA arrays HDS 9585 and NetApp 3020). The DSSU's are over a TB
in size which is causing a real headache with defrags; we have the
DSSU's in a storage unit group and have tried a method support
recommended for defrag's - namely - drop out an inactive DSSU, defrag
it, then add it back to the group. I've tried this twice without much
success due to the time it's taking - I left it for >8 hours, and the
fragmentation only improved by 1%. I suspect that the IOPS generated by
a defrag is not a good match for SATA..?

        So this leads to a series of questions? 
        Is there any other way to resolve the fragmentation issue? 
        Could the DSSU get removed from the SUG, all images duplicated,
tape images set as primary and the images on disk discarded and the dssu
volume reformatted...

        Support (again) said that large sites with large DSSU's tend to
use Unix/Linux since the filesystems on these platforms don't suffer
from fragmentation to the same extent as NTFS. There must be large
Windows only sites out there (he said hopefully!) - can you find out
what they do?

        Is SATA a common choice out there for DSSU's? 
        We experienced slow performance during duplication, on both HDS
9585 arrays and NetApp 3020 over FCP. We're currently talking to NetApp
about 3020 performance issues, so do you know of other NBU customers
using NetApp 3020's for DSSU's?

        Another DSSU related issue we're seeing is orphan images left on
the DSSU from failed/incomplete jobs. We've turned the appropriate logs
on and will be clearing these out manually and escalate again if/when we
see further occurrences. Support assure us that this is not a
normal/reported issue with NBU. Are there any "working practices" that
may also trigger this outcome - I'm conscious that the guidance we
received at the start of the project was a bit on the thin side to say
the least!

        On the subject of orphan files, we've also seen entries being
retaining in the tmp folders in the catalog itself some of them
stretching back months. Again support have said this is not normal - so
they've been manually removed and we're keeping a watch for further
occurrences. Incidentally I asked one of our guys to do a distribution
breakdown of the files by date and the results indicate that the issue
started around the time MP4 was applied.

====================================================================================

La version fran?aise suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential information, and the Bank 
of
Canada does not waive any related rights. Any distribution, use, or copying of 
this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately 
from
your system and notify the sender promptly by email that you have done so. 

------------------------------------------------------------------------------------

Le pr?sent courriel peut contenir de l'information privil?gi?e ou 
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute 
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires d?sign?s est interdite. Si vous 
recevez
ce courriel par erreur, veuillez le supprimer imm?diatement et envoyer sans 
d?lai ?
l'exp?diteur un message ?lectronique pour l'aviser que vous avez ?limin? de 
votre
ordinateur toute copie du courriel re?u.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20070301/f62febeb/attachment.htm