Site icon CormacHogan.com

VSAN 6.2 Part 7 – Capacity Views


If you’ve been following my series on VSAN 6.2 blog posts, you’ll be aware of a considerable number of new features, especially around space efficiency, such as deduplication and compression. On top of this, there is a new on-disk format (v3) and a new software checksum mechanism. All of these features introduce some capacity overhead in their own right, so as to allow administrators track where the storage consumption is occurring a brand new capacity view has been introduced with VSAN 6.2.

If we focus on the Capacity Overview first of all, we can see the full size of the VSAN datastore. This is 20.38TB in size. We can also see Deduplication and compression overhead, but if you want further overhead detail, File system overhead and the Checksum overhead are displayed in further detail in the Used Capacity breakdown in the lower half of the screen. We will take a look at that shortly.

The amount of space Used – Total on the VSAN datastore refers to how much space has been physically written (as opposed to logical size). This is a combination of Virtual disks, VM home objects, Swap objects, Performance management objects and Other items that may reside on the datastore. Other items could be ISO images, unregistered VMs, or templates, for example.

Note that the values displayed for VM objects in the Used Capacity breakdown in the lower half of the screen, when grouped by object types, are related to Used space, and are from before deduplication and compression have been taken into account. There is no information available at this point in time to determine how much space the objects are consuming after deduplication and compression have done their processing.

However, that is not to say that we cannot tell how much space is being saved by these space efficiency features. The Deduplication and Compression overview on the top right give administrators and idea around the space savings and dedupe ratio that is being achieved, as well as the amount of space that might be required if an administrator decided that they wanted to disable the space efficiency features on VSAN and re-inflate any deduplicated and compressed objects.  The space savings ratio increases with the more “similar” VMs that are deployed. Here is another sample where we deployed 100s of VMs all running the same Guest OS. Not bad, eh?

This is telling us that without deduplication and compression, it would have required ~11TB of capacity to deploy the current workloads. With dedupe and compression, we’ve achieved it with ~400GB. One thing to also keep in mind that the “Used Before” value also includes replicas (RAID-1) and parity (RAID-5/6), which is only visible when you flip to the Group by data types view, which we will discuss shortly. This can also tell you how much capacity would be required if you disabled dedupe and compression, and re-inflated the VMs to their actual size. Always refer to this view if you ever plan to do such an action, and ensure there is enough capacity available.

Here is a description of some of the objects seen in the capacity view:

Group by Object Types:

When a VM and a template are deployed on the VSAN datastore, more objects appear:

Next, lets look at the data types breakdown, which is another view one can have:

Group by Data Types:

Used – VM Overreserved

If deduplication and compression are not enabled, you will see another field displayed in the Capacity overview part of the UI. This field is called Used – VM Overreserved. This field simply tells you that if you have decided to use a policy with object space reservation,  how much space has been reserved but is not in use. If this is a high value, then you might need to reconsider whether or not it is worthwhile reducing the object space reservation value and reclaim some of this space for other use. Note that with deduplication and compression enabled, object space reservation must be set to either 0 or 100%. It cannot have a value in-between.

For any questions about where capacity is being consumed, or how well dedupe/compression is working, this is the place to get that information. If there are some additional items that should be tracked from a capacity perspective, let me know and I will feed this back to the product managers and engineers.

Exit mobile version