fnature
Enthusiast
Enthusiast

Am I correct my interpretation of slack space ?

Jump to solution

Hi,

So I understand that best practice is "25-30% slack space when designing and running a vSAN cluster"

so image I have a hybrid cluster with FTT=1 and RAID1 for all my VMs ( I understand that RAID1 only is available with VSAN standard ),

I understsand that if I have 20TB of raw disk capacity,  I would have around 10TB usable for this policy

but because of the slack best practice, my usable capacity is really 7TB ?

there seems to be quite an astronomic cost to it

the only alternative is to go VSAN advanced with dedup&compression?..

or all flash with EC ?

thanks

1 Solution

Accepted Solutions
Alex_Romeo
Leadership
Leadership

Hi,

but because of the slack best practice, my usable capacity is really 7TB ? YES!

l'unica alternativa è andare avanti VSAN con dedup & compressione?  This decision is up to you.


How Much Slack Space Should I Leave? | VMware® vSAN™ Design and Sizing Guide | VMware

vSAN “slack space” is simply free space that is set aside for operations such as host maintenance mode data evacuation, component rebuilds, rebalancing operations, and VM snapshots. Activities such as rebuilds and rebalancing can temporarily consume additional raw capacity. Host maintenance mode reduces the total amount of raw capacity a cluster has while a host is in maintenance mode. This is because the local drives on a host that is in maintenance mode do not contribute to vSAN datastore capacity until the host exits maintenance mode.

Recommendation: Maintain 25-30% slack space when designing and running a vSAN cluster.

For example, a vSAN datastore with 20TB of raw capacity should always have 5-6TB of free space available for use as slack space. This recommendation is not exclusive to vSAN. Most other HCI storage solutions follow similar recommendations to allow for fluctuations in capacity utilization.

When one or more storage devices that contribute capacity to a vSAN datastore are more than 80% utilized, vSAN will automatically initiate a reactive rebalance of the data across vSAN storage devices in an attempt to bring utilization below 80%. This rebalancing activity naturally generates additional IO in the vSAN cluster. Maintaining 25-30% slack space minimizes the need for rebalancing operations while accommodating temporary fluctuations in utilization due to the various activities mentioned above.

---

vSAN Operations: Maintain Slack Space for Storage Policy Changes - Virtual Blocks

Calculating Required Capacity

Plan the capacity required for the virtual machines in a cluster with RAID 1 mirroring based on the following criteria:

      1. Calculate the storage space that the virtual machines in the vSAN cluster are expected to consume.
            
    1.  

      expected overall consumption = number of VMs in the cluster * expected percentage of consumption per VMDK

    2. Consider the Primary level of failures to tolerate attribute configured in the storage policies for the virtual machines in the cluster. This attribute directly impacts the number of replicas of a VMDK file on hosts in the cluster.
          
  1.  

    datastore capacity = expected overall consumption * (PFTT + 1)

  2. Estimate the overhead requirement of the vSAN on-disk format.
    • On-disk format version 3.0 and later adds an extra overhead, typically no more than 1-2 percent capacity per device. Deduplication and compression with software checksum enabled require extra overhead of approximately 6.2 percent capacity per device.
    • On-disk format version 2.0 adds an extra overhead, typically no more than 1-2 percent capacity per device.
    • On-disk format version 1.0 adds an extra overhead of approximately 1 GB per capacity device.

Planning Capacity in vSAN

ARomeo

Blog: https://www.aleadmin.it/

View solution in original post

4 Replies
Alex_Romeo
Leadership
Leadership

Hi,

but because of the slack best practice, my usable capacity is really 7TB ? YES!

l'unica alternativa è andare avanti VSAN con dedup & compressione?  This decision is up to you.


How Much Slack Space Should I Leave? | VMware® vSAN™ Design and Sizing Guide | VMware

vSAN “slack space” is simply free space that is set aside for operations such as host maintenance mode data evacuation, component rebuilds, rebalancing operations, and VM snapshots. Activities such as rebuilds and rebalancing can temporarily consume additional raw capacity. Host maintenance mode reduces the total amount of raw capacity a cluster has while a host is in maintenance mode. This is because the local drives on a host that is in maintenance mode do not contribute to vSAN datastore capacity until the host exits maintenance mode.

Recommendation: Maintain 25-30% slack space when designing and running a vSAN cluster.

For example, a vSAN datastore with 20TB of raw capacity should always have 5-6TB of free space available for use as slack space. This recommendation is not exclusive to vSAN. Most other HCI storage solutions follow similar recommendations to allow for fluctuations in capacity utilization.

When one or more storage devices that contribute capacity to a vSAN datastore are more than 80% utilized, vSAN will automatically initiate a reactive rebalance of the data across vSAN storage devices in an attempt to bring utilization below 80%. This rebalancing activity naturally generates additional IO in the vSAN cluster. Maintaining 25-30% slack space minimizes the need for rebalancing operations while accommodating temporary fluctuations in utilization due to the various activities mentioned above.

---

vSAN Operations: Maintain Slack Space for Storage Policy Changes - Virtual Blocks

Calculating Required Capacity

Plan the capacity required for the virtual machines in a cluster with RAID 1 mirroring based on the following criteria:

      1. Calculate the storage space that the virtual machines in the vSAN cluster are expected to consume.
            
    1.  

      expected overall consumption = number of VMs in the cluster * expected percentage of consumption per VMDK

    2. Consider the Primary level of failures to tolerate attribute configured in the storage policies for the virtual machines in the cluster. This attribute directly impacts the number of replicas of a VMDK file on hosts in the cluster.
          
  1.  

    datastore capacity = expected overall consumption * (PFTT + 1)

  2. Estimate the overhead requirement of the vSAN on-disk format.
    • On-disk format version 3.0 and later adds an extra overhead, typically no more than 1-2 percent capacity per device. Deduplication and compression with software checksum enabled require extra overhead of approximately 6.2 percent capacity per device.
    • On-disk format version 2.0 adds an extra overhead, typically no more than 1-2 percent capacity per device.
    • On-disk format version 1.0 adds an extra overhead of approximately 1 GB per capacity device.

Planning Capacity in vSAN

ARomeo

Blog: https://www.aleadmin.it/

View solution in original post

depping
Leadership
Leadership

25-30% is indeed what is recommended. this is to accomodate for things like maintenance mode and maybe even a host failure. You could go higher, we support it, but we simply don't recommend it typically.

How Much Slack Space Should I Leave? | VMware® vSAN™ Design and Sizing Guide | VMware

depping
Leadership
Leadership

And just to be clear, "dedupe and compression" can only be used with All-Flash right now.

fnature
Enthusiast
Enthusiast

thank you guys

0 Kudos