Forum Discussion

oschistad's avatar
oschistad
Level 3
14 years ago
Solved

Changing alignment for existing LUN possible?

Hi all,

As part of a NetBackup installation we have two media servers configured with 2x15TB LUNs each, hosted by a NetApp filer.

Lately we are starting to suspect that we may have a performance problem with these underlying LUNs, and that the culprit may be misalignment on the volumes.

What we've seen is that NetApp's Management Console is reporting that nearly 100% of IO from these hosts are misaligned. We have also discovered that the StorageAgent on these servers is missing the NetApp settings for Track Alignment.

So there is a great probability that these LUNs are receiving misaligned IOs.

 

The question then becomes wether or not it is possible to correct this misalignment while keeping the data intact?

Some KB articles indicate that installing the missing ASL/APM will correct the issue, but unless some fancy rewriting is occurring while processing each block this probably only affects newly created volumes and not those that were formatted using the default ASL?

 

business continuity
Storage Foundation for Windows
  • Wally_Heim's avatar
    Wally_Heim
    14 years ago

    Hi Oschistad,

    You did not mention what platform you are using.  As far as the Windows platform goes, netapp handles the correct physical disk offset based on Windows using its default volume offset of 63.  As such, SFW does not attempt to track align Netapp arrays by default. 

    You can enable the default track alignment settings with a different track alignment setting.  However, you will need to use SFW to mirror the existing volume to a new set of Luns presented to Windows to correct the track alignment to the new settings.  I would not recommend changing the track alignment setting without Netapp recommending to use a different track alignment setting in SFW.

    ASL is an older DMP technology.  It might be workwhile for you to look into using MPIO with DSMs.  But I don't think this will make a large difference in I/O performance.  Again, this is assuming that you are using Windows.

    Thanks,

    Wally

2 Replies

Sort By
  • Wally_Heim's avatar
    Wally_Heim
    Level 6
    14 years ago

    Hi Oschistad,

    You did not mention what platform you are using.  As far as the Windows platform goes, netapp handles the correct physical disk offset based on Windows using its default volume offset of 63.  As such, SFW does not attempt to track align Netapp arrays by default. 

    You can enable the default track alignment settings with a different track alignment setting.  However, you will need to use SFW to mirror the existing volume to a new set of Luns presented to Windows to correct the track alignment to the new settings.  I would not recommend changing the track alignment setting without Netapp recommending to use a different track alignment setting in SFW.

    ASL is an older DMP technology.  It might be workwhile for you to look into using MPIO with DSMs.  But I don't think this will make a large difference in I/O performance.  Again, this is assuming that you are using Windows.

    Thanks,

    Wally

  • oschistad's avatar
    oschistad
    Level 3
    14 years ago

    Hi Wally,

    You are of course correct.

    As it turns out, what actually happened was that when the LUNs were provisioned they were created with a OS type of "windows". In NetApp terms this means "assume incoming IO to be aligned at 63 blocks (31.5k) and adjust accordingly".

    However the actual OS being used is windows 2008 R2, and of course both it and SFW do in fact align correctly.

    We should have chosen windows_2008 as the lun type, which tells the NetApp that incoming IO will be aligned and does not need correction. Our failure to do so has created the rather idiotic situation where the OS aligns properly but gets sabotaged by the filer and ends up incurring 100% misaligned IO anyway.

    The LUN type is set at creation and cannot be changed thereafter.

    Since we do not have 30TB aggregates just lying around, we will either need to expire enough images on these media servers (and secure delete the partition to free up deallocated blocks) so that we can create two new, correctly aligned, LUNs and perform a mirror - break - delete of the old LUNs, or decommision the MSDP pool entirely and build it from scratch.

    It only goes to show that details matter, I guess :)