SnapManager Exchange/SQL verifies & reallocation [ Edited ]

[#1]

Hi all,

I am sorry if this is not strictly in the correct place.

Performance issues led me in the direction of the reallocation command, and I am struggling to understand when and if I should be using it (previous thread regarding Exchange defrags & reallocation: http://communities.netapp.com/message/54944#54944). So I have some questions:

I am seeing performance issues on my largest volumes - namely our 800Gb NFS volume used as VM datastore, and our 350Gb Exchange 2003 volume:-

1) Should I be scheduling reallocate tasks on these vols, or even on the aggregate? Do they offer any real performance benefit? (seeing as all vols are deduped anyway?).

2) I see performance problems when Exchange is running an "online defrag" of it databases, and especially when performing a backup "verify". I read somewhere that someone experienced a 40% improvement in read times after performing a weekly reallocation on their Notes database vol. As an SMSQL/Exchange verify is mostly reads I guess, should I also be using it?

3) What about my VMware datastore and SQL volumes? Should I also schedule reallocation on these volumes?

I hope someone has prior experience of using reallocation in Exchange, SQL and VMware environments and can give me some pointers. I can't seem to find any conclusive advice - I even read that I shouldnt run reallocation unless instructred to do so by our NetApp support vendor!

What is clear to me is that any large database verifications, or defrags cause a significant performance hit on my filer.

Help as always appreciated.

M.

[udpate: I ran a "reallocation measure -o" on my Exchange vol, and it says "reallocation check is 9, threshold is 4. Consider running reallocate". I guess this is answering my question for me?]

[#2]

Hi,

I run reallocation on hundreds windows luns and a good handfull of luns with vxfs and zfs on top on the unix side. Reallocate as a command has been part of ONTap for probably 5+ years (longer as wafl scan reallocate, iirc).

You said you use deduplication on "all vols".  Even for the Exchange databases?  I guess without some PAM card, I would have never been so brave.

As I previously suggested in the other thread, see the System Administration Guide... and probably the Block Access Guide as far as interaction between deduplication and reallocate. There are also some other hints there at getting more performance out of Exchange. 

High and low levels of deduplication with probably reallocate well and have advantages.  Those in the middle may very well be a matter of experience.  The two data manipulation mechanisms have sort of tangential purposes: space savings v. performance.  Dedup'ing Exchange probably isn't a good idea if you really need performance, at least not without a PAM card.  Reallocate'ing a dedup'ed volume might not help much at all. 

Where did you read that you shouldn't run reallocate?

There has been a good deal of mumbling about a more definitive Best Practices guide for deduplication and reallocate, but nothing has emerged from NetApp yet, afaik.  For now, try using a newer 7.3.x release and things will work better all around for deduplication and reallocate.

[#3]

Great - the Admin guide section on reallocation is actually quite clear - I don't know how I've missed it (thanks for the link).

I am also a little surprised that not one of my support vendors ever mentioned reallocation- until your last post, I didn't even know such a thing existed! :-/

And just to clarify a few things:

- no, my mistake. We obviously don't run dedupe on all vols! Exchange, SQL & other LUNs are excluded. We used to a long time ago, but it hit performance and saved us nothing (this is again another debate. Some people say use it on SQL LUNs - especially Sharepoint databases. Some say not. I can never keep on top of all the latest best practices :-/

- but we are runing dedupe on our NFS datastore which holds all our VMDK files. Therefore should I not run reallocation on this one?

So based on your experience, I think I will schedule reallocation on my larger volumes where there is a high amount of data change and lots of sequential reads happening and see how it performs.

Thanks,

M.

[#4]

Just regarding your one question:

There will be times when reallocation is a good idea, even on dedup'ed volumes:  when you add new disks to an aggregate and such.  Otherwise, like I said,  highly and minimally deduped volumes will probably benefit in most cases. The rest is still more a matter of experience. There have been some imporovements in ONTap to alleviate some of the inherent problems with using WAFL and deduplication/reallocation with block-based storage allocation.

:-)