Slacking Away on vSAN

Have been getting a lot of questions around slack space in recent times and how it affects sizing. Some competitors have taken advantage of the confusion and started classifying it as "overheads" to operate vSAN, and putting us down for it. As a general practice, we often cater between 25-30% additional capacity for slack space.

So what is slack space?
captain-vsan-slack.jpg

Slack space is not an overhead that is required for vSAN to operate per se. Assuming that you have a vSAN requirement for 100TB, factoring in 30% slack, would mean sizing it up for 130TB. So how much can vSAN utilise, if the actual RAW capacity is 130TB? The right answer is, almost all of the 130TB (minus the ~1% file system overhead). So why do we then recommend additional 30%?

Slack space is capacity that we recommend users to have so they can accommodate policy changes, data evacuations and rebuilds in the event of failure. Think of it as if it's staging capacity. So what do you think would happen if you didn't have it? Well, none of those activities mentioned earlier will happen obviously, but vSAN should chug along just fine till the last drop of capacity, given the right policies.

So do we factor in the additional 30% or not?

I would strongly recommend that you have provisions for it. Having said that, let's revisit how we typically size and consume storage in a traditional SAN. Assuming you have a requirement to purchase 100TB of new capacity, would you be looking at consuming all of the 100TB and not have any buffers before you trigger a request to top-up capacity in the future? Or is there a practice in your organisation to always maintain 30% capacity buffer for contingencies? Discussions with many customers in the field, most have best practices to never consume beyond 60-70% of the capacity at hand, which means there is about 30-40% of free capacity. 

So coming back to our example, 100TB, assuming you should never consume beyond 60TB, that leaves us with 40TB of spare capacity to work with which could easily be used as slack space. So if that is indeed the best practice in your organisation, there was no need to size vSAN for 130TB to begin with and 100TB would have been more than sufficient. 

So in conclusion, most customers have had in some ways always provisioned for this so called "overhead". Here is a little more reading on slack space if you are interested to understand more. Hopefully, you now have better clarity of how best to provision for it.

Charles Chow

I am an IT Practitioner (my day job) that have been across multiple roles ranging from end-user, post-sales, pre-sales, sales, and management.

I enjoy everything that is technology and a big advocate in embracing new tech. I love taking things apart and understanding how it works, in the process appreciating the engineering that goes into it.

Sometimes, I take my passion at work and apply it to my hobbies as well aka cycling.

Previous
Previous

60 Minutes - vSAN says "Mai Kan Cheong"

Next
Next

New vSAN 6.7 Demo Clips