NetApp Storage Over Commitment for LUNs
Most modern storage arrays allow for some sort of thin provisioning. If you are currently using thin provisioning on your system you open up the possibility to overcommit your storage. This technology is relatively new to the storage industry, but almost all vendors provide some means to overcommit their arrays. Network guys have known about this for years only they refer to it as oversubscription. Cisco UCS systems for example are 2-1 oversubscribed. A fully loaded chassis (8 blades) is capable of 160GB of throughput, but there is only 80GB of bandwidth available from the FEX (Uplinks). The common thought is not all systems will demand all their bandwidth at the same time, and the same theory holds true for storage. We can drive up utilization of our storage arrays by overcommiting data.
Take for example the following scenario creating a 100GB LUN using the "Create LUN Wizard" in System Manager. If you check the new volume that is created in this process you will see it is now nearly full. This is because the LUN is space reserved by default. If we write 10GB of data to the LUN, the used space won't change since the system has already set aside space for the LUN. A look at the picture below shows how this might look.
If you browse to your newly created LUN and uncheck "Space Reserved" you have just made your LUN "thin". As you can see from the diagram below you now have more space available in the volume. This is a safe option for thin provisioning since your LUN still has the volume space guaranteed and it can grow to the fully provisioned size if necessary. This will give you the ability to store more snapshots, which is a good thing, but it doesn't let us overcommit our storage unless we build more LUNs in the same volume.
In order to get the best use of your NetApp array you can also thin provision your volumes. The way you do that is by setting your volume guarantee to "none". By looking at the diagram below we now see the only space consumed in our aggregate is the actual data written to our LUN.
There are a few caveats with this design. The first is you need to keep a close eye on your storage utilization. I recommend Operations Manager from NetApp as it will let you create alerts for things you need to watch like aggregate free space and aggregate overcommitment. Almost just as importantly Operations Manager will track historical data growth. This will let you plan ahead for extra capacity when needed. If you do not actively monitor your space you could run into a situation where your LUNs go offline and are no longer available to the systems that need them. The other thing to note with this design is how to handle volume auto-growth.
When you create a volume via System Manager the volume will only auto-grow to 20% above its creation size, so a 100GB volume will only auto-grow to 120GB. This results in a good deal of management overhead if you ever start growing thin provisioned LUNs. You run the risk of having the volume run out of space unless you grow the volume, or adjust the autosize parameter (something you can't do from System Manager). I recommend configuring the volume autosize equal to the size of the containing aggregate on non space reserved volumes. You could create the volume equal to the size of the aggregate and get basically the same result, but you won't be able to use the aggregate overcommitment alarm from Operations Manager.
If you have a large number of arrays, volumes, and LUNs changing all of them would be daunting were it not for the recently released Data OnTap Powershell toolkit. I put together this script so you can get a good idea of how much space you could be saving on your storage arrays. By default it will look only at LUNs that are already thin provisioned (space reserved LUNs are ignored), volumes that have a space guarantee set, and volumes that are not in a SnapMirror relationship. The script doesn't modify anything on your system, it just reports on how much space you could save. If you want to take full advantage of the space savings uncomment these lines in the script:
Set-NaSnapshotAutodelete $volume.name state on | Out-Null
Set-NaVolOption $volume.name fractional_reserve 100 | Out-Null
Set-NaVolOption $volume.name guarantee none | Out-Null
Set-NaVolOption $volume.name try_first volume_grow | Out-Null
Set-NaVolAutosize $volume.name -Enabled -MaximumSize $aggrSize.SizeNominal | Out-Null
Once you uncomment those lines and re-run the script it will set all your volumes with thin provisioned LUNs to have a fractional reserve of 100, no volume space guarantee, snapshot auto-delete, volume auto-grow, and a volume autosize equal to the size of the containing volumes aggregate. The autosize parameter will give you a set it and forget it approach to managing thin provisioned LUNs. Pick up the script over at the NetApp forums
Take for example the following scenario creating a 100GB LUN using the "Create LUN Wizard" in System Manager. If you check the new volume that is created in this process you will see it is now nearly full. This is because the LUN is space reserved by default. If we write 10GB of data to the LUN, the used space won't change since the system has already set aside space for the LUN. A look at the picture below shows how this might look.
If you browse to your newly created LUN and uncheck "Space Reserved" you have just made your LUN "thin". As you can see from the diagram below you now have more space available in the volume. This is a safe option for thin provisioning since your LUN still has the volume space guaranteed and it can grow to the fully provisioned size if necessary. This will give you the ability to store more snapshots, which is a good thing, but it doesn't let us overcommit our storage unless we build more LUNs in the same volume.
In order to get the best use of your NetApp array you can also thin provision your volumes. The way you do that is by setting your volume guarantee to "none". By looking at the diagram below we now see the only space consumed in our aggregate is the actual data written to our LUN.
There are a few caveats with this design. The first is you need to keep a close eye on your storage utilization. I recommend Operations Manager from NetApp as it will let you create alerts for things you need to watch like aggregate free space and aggregate overcommitment. Almost just as importantly Operations Manager will track historical data growth. This will let you plan ahead for extra capacity when needed. If you do not actively monitor your space you could run into a situation where your LUNs go offline and are no longer available to the systems that need them. The other thing to note with this design is how to handle volume auto-growth.
When you create a volume via System Manager the volume will only auto-grow to 20% above its creation size, so a 100GB volume will only auto-grow to 120GB. This results in a good deal of management overhead if you ever start growing thin provisioned LUNs. You run the risk of having the volume run out of space unless you grow the volume, or adjust the autosize parameter (something you can't do from System Manager). I recommend configuring the volume autosize equal to the size of the containing aggregate on non space reserved volumes. You could create the volume equal to the size of the aggregate and get basically the same result, but you won't be able to use the aggregate overcommitment alarm from Operations Manager.
If you have a large number of arrays, volumes, and LUNs changing all of them would be daunting were it not for the recently released Data OnTap Powershell toolkit. I put together this script so you can get a good idea of how much space you could be saving on your storage arrays. By default it will look only at LUNs that are already thin provisioned (space reserved LUNs are ignored), volumes that have a space guarantee set, and volumes that are not in a SnapMirror relationship. The script doesn't modify anything on your system, it just reports on how much space you could save. If you want to take full advantage of the space savings uncomment these lines in the script:
Set-NaSnapshotAutodelete $volume.name state on | Out-Null
Set-NaVolOption $volume.name fractional_reserve 100 | Out-Null
Set-NaVolOption $volume.name guarantee none | Out-Null
Set-NaVolOption $volume.name try_first volume_grow | Out-Null
Set-NaVolAutosize $volume.name -Enabled -MaximumSize $aggrSize.SizeNominal | Out-Null
Once you uncomment those lines and re-run the script it will set all your volumes with thin provisioned LUNs to have a fractional reserve of 100, no volume space guarantee, snapshot auto-delete, volume auto-grow, and a volume autosize equal to the size of the containing volumes aggregate. The autosize parameter will give you a set it and forget it approach to managing thin provisioned LUNs. Pick up the script over at the NetApp forums
No comments:
Post a Comment