Forum Discussion

oschistad's avatar
oschistad
Level 3
14 years ago

Thin reclaim suported on NetApp?

I recently identified a need to shrink the provisioned size of a very large server that mounts its disks from a NetApp filer. While researching my options (sdelete and SnapDrive being the most common methods) I discovered that Storage Foundation recently began supporting thin disk reclamation through the SCSI WRITE_SAME command. Furthermore, NetApp themselves have announced that they are participating in this and have provided Symantec with the necessary APIs to perform this agains a NetApp filer

however, I am not able to use the vxdisk reclaim feature against our NetApp disks, and in the HCL for 5.1 sp2 NetApp is still listed as not supporting thin reclaim.

Does anyone know if there is a later hotfix which introduces this? Or is this a feature that is supported, but only for Unix?

  • Hi Oschistad,

    There is not a patch at this time that will provide support for thin provisioning on NetApp arrays with SFW.  SFW's Support for thin provisiong would allow the relaimation commands to be run from within VEA.  This does not mean that you cannot use thin provisioned luns or that you cannot run reclaimation commands manually outside of VEA.

    In your case I would recommend that you go to 5.1 SP2 the latest CP.  Then perform the following:

     

    1.  Backup your data.

    2.  Clean up the volume so that the spaced used is less than 15 TB.

    3. Backup your data again (I'm overly cautious.)

    4.  In SFW, shrink the volume to 15 TB - freeing up one of your 15 TB luns. 

    ***********  This step (4) is the one that I'm unconfortable with.  Make sure that you stop all access to the volume and perform a check disk on the volume before performing this operation.  This operation if it goes wrong may corrupt the entire volume.  Use at your own risk.

    5.  Remove the unused 15TB lun from the disk group.

    6.  Perform operations on the NetApp array to destroy the unused 15 TB lun, reclaim its space and then recreate the 15 TB lun with the correct settings.

    7. Add the newly recreated 15 TB lun back to the disk group.

    8. Mirror the volume from the old 15 TB lun to the newly recreated 15 TB lun.

    9. When mirror is in sync, remove the mirror plex that is on the old 15 TB lun.

    10. Remove the now unused old 15 TB lun from the disk group.

    11 Perform operations on teh NetApp array to destroy the unused 15 TB lun, reclaim its space and then recreate the 15 TB lun with the correct settings.

    12.  Add the newly recreated 15 TB lun to the disk group.

    13. Expand the volume to use the newly recreated 15 TB lun.

    Thanks,

    Wally

  • Hi oschistad,

    What platform are you interested in? 

    Windows has been releasing patches to add array support for Thin Provisioned luns.  Keep in mind that the support on Windows for Thin Provisioned luns allows you to perform the reclaim operations from within the VEA console.  The reclaim operations even without SFW support for thiin provisioned luns can still be done manuallyl outside of SFW.

     

    If you are actually going to change the size of the lun presented to SFW, I would recommend that you perfrom a vxcbr backup of the disk group prior to performing the shrink on the lun.  You should also shrink the volume(s) prior to shrinking the lun so that you do not destroy the volume(s) when shrinking the lun.  After shrinking the lun you might have to perform a vxcbr restore of the disk group to put the private region back on the disks (this would be if the disks are MBR and not GPT.)

     

    Thanks,

    Wally

  • Platform is windows, yes.

    I just realized I should specify that I am not using VxFS here - this is the volume manager portion of SFW I am using, and the disks in question are two 15TB LUNs concatenated to a 30TB NTFS volume used by a NetBackup media server with the MSDP option.

    The core problem here is that the LUNs have been misconfigured as "windows" instead of "windows_2008" on the NetApp side, and hence are misaligned and incurring drastic performance reduction.

    To get out of this bind we will have to migrate the data into two new, properly aligned LUNs.

    Okay; since we do not have a spare 30TB lying about (the underlying aggregate is about 31TB usable) we are looking at ways in which we can jiggle data around with what we have. The current utilization inside windows is around the 16TB mark, so we will need to expire some data to get to around 12TB.

    However, since these LUNs are thin provisioned we will also need to deallocate a large amount of currently provisioned blocks at the aggregate level on the NetApp, otherwise we will simply not have enough free space in the aggregate.

    And this step requires either SnapDrive (which is licensed and not for free); secure delete (which is free but will generate a massive IO load while issuing 10-20TB worth of zeroes) or thin reclaim.

    The latter option is definitely preferable, as it will use the WRITE_SAME scsi command to perform the zeroing, so instead of writing an empty block N times it gives the storage system a list of blocks to zero, which will then automatically be deallocated since they are empty.

    Buuut; NetApp is not listed as supporting Thin Reclaim on the HCL for 5.1 SP2, which led me to the question of wether or not I need a hotfix in addition to the base SP2 image.

  • Hi Oschistad,

    There is not a patch at this time that will provide support for thin provisioning on NetApp arrays with SFW.  SFW's Support for thin provisiong would allow the relaimation commands to be run from within VEA.  This does not mean that you cannot use thin provisioned luns or that you cannot run reclaimation commands manually outside of VEA.

    In your case I would recommend that you go to 5.1 SP2 the latest CP.  Then perform the following:

     

    1.  Backup your data.

    2.  Clean up the volume so that the spaced used is less than 15 TB.

    3. Backup your data again (I'm overly cautious.)

    4.  In SFW, shrink the volume to 15 TB - freeing up one of your 15 TB luns. 

    ***********  This step (4) is the one that I'm unconfortable with.  Make sure that you stop all access to the volume and perform a check disk on the volume before performing this operation.  This operation if it goes wrong may corrupt the entire volume.  Use at your own risk.

    5.  Remove the unused 15TB lun from the disk group.

    6.  Perform operations on the NetApp array to destroy the unused 15 TB lun, reclaim its space and then recreate the 15 TB lun with the correct settings.

    7. Add the newly recreated 15 TB lun back to the disk group.

    8. Mirror the volume from the old 15 TB lun to the newly recreated 15 TB lun.

    9. When mirror is in sync, remove the mirror plex that is on the old 15 TB lun.

    10. Remove the now unused old 15 TB lun from the disk group.

    11 Perform operations on teh NetApp array to destroy the unused 15 TB lun, reclaim its space and then recreate the 15 TB lun with the correct settings.

    12.  Add the newly recreated 15 TB lun to the disk group.

    13. Expand the volume to use the newly recreated 15 TB lun.

    Thanks,

    Wally

  • Okay, that sounds like the best plan given the circumstances.

    Agree that step 4 is a bit scary, but luckily we use duplication in NetBackup to clone all our backups so I can lose a media server and still perform restores.

    (Fantastic product by the way!)

    Thanks for the help, and have a good weekend! :)

  • Just hit a rather unfortunate snag with the plan: SFW does not support shrink operations for NTFS volumes larger than 2TB.