Data Backup and Recovery
Data Backup and Recovery
Could some one explain how the Thin Provisioning is implemeted on OnTap 7 versions.?
The concept of volume sizing can be broken down into 2 different parts, the database volume and the transaction log volume. Just a note, the total LUN sizes required is used as a basis for volume sizing.
NetApp recommends that when sizing Exchange volumes the Microsoft sizing spreadsheet for Exchange first be used in order to determine appropriate amount of space needed for each LUN. Total LUN Requirements are used as the basis for calculating volume space requirements. Once we have the basicLUN capacity requirements we can easily size each volume using the x+delta method which is much closer to the capacity needs.
Transaction Log Volume Sizing
Providing accurate sizing for transaction log volumes depends on the following factors.
Transaction log volume sizing can be calculated using the following formula.Transaction Log Volume size = Total Transaction Log LUN size+ (snapshot copy space * Online Backup Retention Duration + Fault Tolerance Window)Database Volume SizingProviding that an accurate change rate is known the following formula would be used in calculating total volume size. The formula below is based on 2 different key variables.To calculate the Exchange DB volume size a number of variable are used:
Database volume size can be calculated using the following formula
Database Volume Size = (Sum of the database LUN sizes that will share the database volume) + ((Fault Tolerance Window + Online Backup Retention Duration) * database daily change rate)
Fractional Reserve
Now that we've covered the basic volume sizing let's tackle the question of Fractional Reserve. Historically this has been set at 100% which essentially means you'll wind up with a lot of headroom in the volume. The preferred method is to set fractional reserve to 0% and use the auto delete. So what exactly does auto delete do? When a low volume threshold is triggered, auto delete will delete snapshots to reclaim space until the target free space percentage is hit. I often get the question "why is it recommended to use auto delete? Why can't I just use auto grow to grow my volume when the low space threshold is hit?" To answer the question, you can use auto grow but in order to guarantee space auto delete must be used as well. The reason for this is that there may be cases when auto grow can no longer grow a volume, such as a low space condition in the aggregate. That's why the recommendation is to use auto delete. I will reply more in depth as to the recommended settings when using fractional reserve to 0 in a later post.
Thin Provisioning
Thin provisioning in and Exchange or other application environment is completely fine. The trick to ensuring that you don't run into capacity problems which could cause the application to go offline is monitoring. If you are going to thin provision storage you need to make sure the you monitor volume capacity religiously. In environments where there is no dedicated storage admin or volume space is not monitored I typically recommend not to thin provision.
Please refer to the TR-3563 for further details.
I hope this helps!
we use thin provisioning at aggregate level (volume guarantee=none and LUN space reservation=disabled). so did i get this right in assuming that i need to monitor the aggregate free space? (instead of the volume space you mentioned above)?
Hi,
I am a bit confused - is your question related to Exchange environment, or are you asking about thin provisioning in general?
It is a bit of a dark art , and no matter whether you use or not thin provisioning, you always should know what you are doing. E.g. how much do you over-provision when using thin provisioning? Are you 100% sure you will never ever fill the LUN with data? Are you 100% sure you will never fill the volume (e.g. with snapshots)? If both answers are yes, then you only need to be concerned about free space left in the aggregate, indeed.
Regards,
Radek