posted

0 Comments

vSAN Capacity Views were introduced in 6.2 and provide insight into how capacity is being used.

From the Cluster select —> Monitor —> vSAN —> Capacity to see the capacity views.

From here you will find several panels of information related to the capacity.

 

 

First off is the Capacity Overview. This will show the used capacity, as well as the current amount of raw free space remaining in the cluster. Note depending on deduplication, compression, the RAID type, and Failure To Tolerate (FTT) setting chosen stretched clustering, the amount consumed by provisioning will vary.

Note, Deduplication and compression treat thick, and virtual machines with capacity reservation as being fully hydrated. If you see anomalous results with Deduplication and Compression, try the following tips:

  1. See if the object space reservation policy has been set to above zero, as this reservation will effectively disable the benefits of deduplication for the virtual machine.
  2. Do not forget that swap is by default set to 100% but can be changed.
  3. If a legacy client or provisioning command is used that specifies “thick” or “Eager Zero Thick” this will override the OSR 100%. To fix this, you can reapply the policy. William Lam has a great blog post with some scripts on how to identify and resolve this.
  4. Make sure data is being written to the capacity tier. If you just provisioned 3-4 VM’s they may still be in the write buffer. We do not waste CPU or latency deduplicating or compressing data that may not have a long lifespan. If you only provisioned 10 VM’s that are 8GB each it’s quite possible that they have not destaged yet. If you are doing testing clone a lot of VM’s (I tend to create 200 or more) so you can force the destage to happen.

If you are not using Deduplication and Compression ad additional “VM Overserved” may appear. This is the result of object space reservations being set to larger than zero. If All policies are set to zero, this may still show capacity still reserved. In this, case it is often the result of object swap which defaults to 100%.

If used capacity seems higher than it should be, look below at the used capacity break down. Ther are two groups, Object, and Datatypes.

Object Types are as follows.

  • Virtual Disks – This is capacity associated with Virtual Machine Disks (VMDK). Snapshot overhead will also show up under here.
  • VM Home Objects – The Namespace objects (VMX configuration, NVRAM, VM logs that occupy the virtual machine directory).
  • iSCSI Home and target objects – This includes the iSCSI home namespace, it’s configuration files and LUNs that are provisioned.
  • Swap Objects – Used for swapping to swapping to disk when memory is not available. Do not forget that swap is by default set to 100% but can be changed.
  • Performance Management Objects – This is space used by the vSAN Performance Service. Note this will be a maximum of 255GB, although it rarely consumes more than 70GB. The SPBM policy associated with this object may be changed if needed. It is automatically created when the performance service is enabled.
  • vMEM Objects -Associated with snapshots that include guest memory.
  • File system overhead – Overhead associated with the file system, deduplication, and compression hash tables, and other metadata. When deduplication and compression have been turned on this capacity is inflated by a factor of ten to reflect the larger virtual capacity of capacity devices.
  • Checksum overhead – Approximately 5 bytes per 4KB block, this is a CRC32 checksum. Note Checksum is enabled by default but may be disabled per SPBM policy.
  • Other: ISO’s, non-registered virtual machines, manually created objects fall into this category.

The Data Type breakdown is a simpler view. This view shows the consumed in the guest by a Virtual Disk, vs. all other associated overheads, including the protection of that data (Associated parity, mirror copies, etc.). This is useful in understanding how changes to vSAN protection policies (perhaps changing from RAID 5 to 6) could impact capacity.

Temporary overhead – is an additional data type that will appear during rebuilds or policy changes.