How to convert from thin to thick provisioned LUNs and Volumes on FAS2650

[superguy41]

Hi All, I'm trying to figure out the best way to convert our existing LUNs and Volumes from thin to thick provisioned.

Is it literally as simple as opening the OnCommand System Manager and:

1. Editing a volume to take the check off of the Thin Provisioned check box

2. Editing a LUN to remove the Disable Space Reservation

I currently have an 18.06TB aggregate and x4 volumes of 5, 6, 4 and 2TB.  I also have x4 LUNs all of exactly the same sizes.  NetApp support said that the Volumes should be 5% larger than the LUNs so I will need to increase these slightly.

Can anyone see any issues with changing this as above or are there additional steps that would have to be taken via the commandline.  All of these LUNs are production facing and in use, would there be any impact/downtime when doing this?

Also after changing to thick provisioned Volumes + 5% for each I'm taken to 17.85 out of 18.06TB used.  This is getting very close to capacity, can anyone see any issues around this? Do I need to leave any space free for system functions etc?

I would really appreciate any help, thanks!

[SpindleNinja]

Yes it's that simple.   

No I wouldn't recommed it.    Give your aggr a little bit more breathing room for WAFL/System functions. 

[superguy41]

---

@SpindleNinja wrote:

Yes it's that simple.   

No I wouldn't recommed it.    Give your aggr a little bit more breathing room for WAFL/System functions. 

---

Thanks for your reply.  Unfortunately there are no more disks to add to the aggregate.  I have inherited this setup from a predecessor.   Why would you not reccomend it?  My main reasons for wanting to switch to thick provisioned is so that I do not have to worry about my LUNs outgrowing the volumes. NetApp support also told us that we should have our volumes 5% larger than our LUNs - is this true for thick and thin provisioned volumes?

I'm working on the VMware environment but we have some machines created as thin provisioned.  Isnt this a recipe for disaster, thin provsioned on volume, LUN and VMware?

Do you think the remaining space after thick provisioning is not enough then?  (about 200GB)

I read that these settings need to be set on volume for thick provisioning, would you say these are not needed?

Volume setting Value

Guarantee          Volume

Fractional reserve           100

Snapshot reserve             Any

Snapshot autodelete      Optional

Autogrow            Optional; if enabled, aggregate free space must be actively monitored.

File or LUN setting           Value

Space reservation            Enabled

[superguy41]

I just wanted to add that I recently added x4 more disks to the aggregate.  A month later I want to now add the space created from the extra disks to one of the volumes.  The problem is with the volume and LUN thick provisioned I have no idea how much actual disk space I can commit from the aggregate to the volumes?  OnCommand tells me I have 18.06TB total space and 9TB available space.  Does this mean that I have 9TB available to committ to volumes?  apologies for any silly questions I have only just looked at my first NetApp device!

[SpindleNinja]

I have inherited this setup from a predecessor. Why would you not reccomend it? I generally always like to thin/thin on ONTAP. However, if you really just want to set it and forget it on ONTAP, then yes, thick all things. but you will for sure not want to commit more than 90-95% of your aggr.

NetApp support also told us that we should have our volumes 5% larger than our LUNs - is this true for thick and thin provisioned volumes? Yes, I would still leave a small "gap" between the vol and lun.

Isnt this a recipe for disaster, thin provsioned on volume, LUN and VMware? Not really, as long as you monitor your aggr space. But it depends how you want to monitor/manage the system.

I read that these settings need to be set on volume for thick provisioning, would you say these are not needed? If you're setting thick yes.

OnCommand tells me I have 18.06TB total space and 9TB available space. Does this mean that I have 9TB available to committ to volumes? Think of it as you can write 9TB worth of capacity to the aggr. All setting thick does is just guaranteeing the space on the aggr to the volume.

Give this a read over and see if it helps any.

http://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-sanag%2FGUID-2F5C9474-FFE9-4E59-84DB-1B9D6D134688.html

[superguy41]

Thanks for your responses, based on what you've said and after doing a but more digging I've decided to keep thin volumes and LUNs on the SAN.  (and probably go thick provisioned in VMware)

With this in mind I would like to make use of the available 9.03TB space in the aggregate.  I've uploaded a Word doc showing the current config and my proposed changes, would you mind taking a look?

Essentially I want to extend vol03 by 2TB and vol04 by 4TB.  Another 1TB will then get used up by adding 5% to each of the volumes to give them a buffer between the LUNs.  I then plan to extend the LUNs to match the volume sizes (minus 5%).

My only concern with this is that once I have made these changes my 18.06TB aggregate will be overcommitted to 22.05TB worth of volumes.  Is this acceptable and normal procedure to overcomitt if there is available space of 9.04TB in the aggregate? 

The way I'm seeing it is that if I have 9.03TB available I'm safe to use 5TB to add to volumes as I'll be left with 4TB (or more as I'm not using this space right away).  I will then be extending VMware datastores to match the size of the LUNs.  I guess this makes no difference though as the space is not actual taken from the SAN until I create the VMs and fill the virtual disks?

Thanks for all your help so far!

[SpindleNinja · Accepted solution]

That's not bad over-commit at all.    I used to run ~150% overcommited. 

Keep in mind though, you'll also get space savings with any volume effencies that you enable (dedupe).  

If you thick the VMDKs  you'll see the space get "used" in vCenter,  but on the netapp you'll just see what's writen to the disk.