Snapdrive 6.3 creates misaligned luns?

[petena711]

Hi, I'm running Snapdrive 2003 on a Win2003 64 bit server...prepping it for an Exchange 2007 cluster...running iSCSI

When I run through Snapdrive to create the database/log luns, I'm noticing the luns are being formated for 4k block size and they're misaligned.  Ideally they should be 64k block size and aligned according to MS, but the tools they give me to check this confirm they aren't correct. 

Is there a way around this?

I'm confirming alignment by issuing this command on the windows host: wmic partition get BlockSize, StartingOffset, Name, Index

...it's creating a disk with two partitions, showing:

512        0      Disk #1, Partition #0  33571840
512        1      Disk #1, Partition #1  17408

33571840 / 1048576 gives me a 32.01...so that's off...

I'm confirming allocation unit size by issuing: fsutil fsinfo ntfsinfo

...giving 4096...

The format block size isn't a big deal - I can just reformat after snapdrive is done. However, the partition is done and Snapdrive throws it into my cluster node as an online resource, so if I delete the partition in disk administrator, diskpart won't allow me to realign the partition...or if I'm not watching things and throw it into an active production cluster group and decide to take the drive offline, the whole server will fail over..  I'm left with a lun that Snapdrive can't work with or delete, the cluster sees the resource as being offline, and i have to go through and manually delete everything because nobody's happy that I've monkeyed with this partition...

It's strange to me that a product tailored to storage wouldn't give you an option of how you wanted the volume formatted or aligned by this point, especially since there are sister products (Snapmanager for Exchange and SQL) that are both tailored to products who have extensive info about this being the ideal formatting/partition configuration....and it handles things way beyond the complicity level of a disk format.   Am I confusing something where the NetApp somehow doesn't need these parameters set to MS reccomendations? 

Any info is appreciated!  I managed to get a couple luns 'redone' but it doesn't seem to be working consistantly...i'm sort of hacking away and making too much effort out of this, there has to be an easier/smoother way...

Pete

[shaunjurr · Accepted solution]

Hi,

LUN alignment and block sizes are basically two different things.  Microsoft recommendations on block size don't really apply to NetApp LUNs.  If you read the documentation for MSSQL and Exchange (Best Practices), I believe a lot of this is explained.  Assuming you used the correct LUN type when you setup the LUN (and I believe the current recommendation from MS is to use GPT disks for w2k3 x64), then the rest will be taken care of by the NetApp.

LUN mis-alignment refers to a situation when the NTFS block boundaries (no matter what block size) do not match the underlying 4k block boundaries. As long as the padding from the LUN type is correct for the filesystem laid down afterwards (so the block boundaries match where the mathmatically should), then you don't have a mis-aligned LUN.

I think a bit of additional research into NetApp Best Practices will get you the answers to your questions.

[petena711]

Yeah, I sort of was treating them separately...but I'll take another look at the best practices documents again...could have sworn it was saying 64k allocation unit for the format...

Thanks for the info!

Pete

[petena711]

Curious though - which Best Practices guide are you referencing?  Been looking at some more exchange and snapdrive best practices guides, but other than saying "Snapdrive will do the alignment", where were you seeing information specific to the 4k format over 64k and the disk alignment?  I've run across some other folks having misalignment issues as well more quickly than finding something that says exactly what it's doing...

Pete

[shaunjurr]

Hi,

It took me about 30 seconds to find this KB article:

https://kb.netapp.com/support/index?page=content&id=3012279

There are additional references in the KB article.  It is not so easy to find in the TR's unfortunately.  I would hope that someone in NetApp would correct this since it is a pretty common question.

[petena711]

Thanks, I was looking at best practices guides for close to an hour with no mention of any of this.

[watan]

I will take note of this and try to work this into the next SDW bpg.  Will also get in touch with the SMx experts to get this in the application docs as well.