Wednesday, June 3, 2009

How usable space in NetApp array LUN is calculated

The usable space of an array LUN is reduced by the elements shown in the following table.


If you are using block checksums

If you are using zoned checksums

10%–WAFL reserve

10%–WAFL reserve

1%– Core dump

1%– Core dump

20%–Volume-level Snapshot copy (default setting; optional)

20%–Volume-level Snapshot copy (default setting; optional)

5%–Aggregate-level Snapshot copy (default setting; optional)

5%–Aggregate-level Snapshot copy (default setting; optional)

12.5%–Checksum

Please note that the NetApp definition of a gigabyte (GB) is 1000 x 1024 x 1024 bytes.

Now you must be thinking why shouldn’t I go for zoned checksums to save 12.5% space? So what I would say is, if you are not much concerned about performance then you an easily go ahead and use zoned checksum over block checksum (specially in random-read intensive workloads) however please understand the difference between them before you make-up your mind to select one over another. There are a lot of references available on the internet to help you understand the concept even I will also try to cover them if I have some time.

Here’s couple of formulas from NetApp to calculate the space

Usable capacity is the actual space available to store the data and desired capacity is the exact array LUN size required to achieve a usable capacity.

Now if we denote usable capacity with Y and desired capacity with Z so we get the below formula here I have shown an example of 10GB in desired and usable space with Snapshot reserve set at default.


Block

Zoned

Y = Z x {0.875 x 0.9 x 0.99 x Snapshot reserve}

Y = Z x {0.9 x 0.99 x Snapshot reserve}

10 x {0.875 x 0.9 x 0.99 x 0.8} = 6.2 GB

10 x {0.9 x 0.99 x 0.8} = 7.1 GB

Z = Y / {0.875 x 0.9 x 0.99 x Snapshot reserve}

Z = Y / {0.9 x 0.99 x Snapshot reserve}

10 / {0.875 x 0.9 x 0.99 x 0.8} = 16 GB

10 / {0.9 x 0.99 x 0.8} = 14 GB

Please note that I have taken the disk size as identified by system not the marketing size given by manufacturers.

No comments: