With the announcement of Virtual SAN 1.0 a change in recommended practice when it comes to SSD to Magnetic Disk capacity ratio was also introduced (page 7) has been introduced. (If you had not spotted it yet, the Design and Sizing Guide for VSAN was updated!) The rule was straight forward: Recommended SSD to Magnetic Disk capacity ratio is 1:10. This recommendation has been changed to the following:
The general recommendation for sizing flash capacity for Virtual SAN is to use 10 percent of the anticipated consumed storage capacity before the number of failures to tolerate is considered.
Lets give an example to show the differences:
- 100 virtual machines
- Average size: 50GB
- Projected VM disk utilization: 50%
- Average memory: 5GB
- Failures to tolerate = 1
Now this results in the following from a disk capacity perspective:
100 VMs * 50GB * 2 = 10.000GB 100 VMs * 5GB swap space * 2 = 1000GB (We multiplied by two because FTT was set to 1)
This means we will need 11TB to run all virtual machines. As explained in an earlier post I prefer to add additional capacity for slack space (snapshots etc) and meta data overhead, so I suggest to add 10% at a minimum.This results in ~12TB of total capacity.
From an SSD point of view this results in:
- Old rule of thumb: 10% of 12TB = 1.2TB of cache. Assuming 4 hosts, this is 300GB of SSD per host.
- New rule of thumb: 10% of ((50% of (100 * 50GB)) + 100 * 5GB) = 300GB. Assuming 4 hosts this is 75GB per host.
Now lets dig some deeper, 70% read cache and 30% write buffer. On a per host basis that means:
- Old rule: 210GB Read Cache, 90GB Write Buffer
- New rule: 52,5GB Read Cache, 22,5GB Write Buffer
Sure from a budgetary perspective this is great, only 75GB versus 300GB per host. Personally, I would prefer to spend more money and make sure you have a larger read cache and write buffer… Nevertheless, with this new recommendation you have the option to go lower without violating any of the recommendations.
Note, this is my opinion and doesn’t reflect VMware’s statement. Read the Design and Sizing Guide for more specifics around VSAN sizing.
Cormac Hogan and I decided it was time for a book on Virtual SAN. Both of us have published many articles about VSAN the last 9 months and have been working with the product for over a year now so it only made sense. We have decided, and this wasn’t an easy decision for me, to go with VMware Press. When I say “not an easy decision” I don’t want to sound negative about using publisher, but it is just that I have had a great experience (and results) with self-publishing. It was time for a new experience though, try something different. As we speak we are working hard to get the final set of chapters in for review / editing and we are hoping to have the book available before VMworld. I am guessing that the rough cuts will be available through Safari in the upcoming weeks, if so I will let you know via a blog post.
Infinio just .jpg)
In the last couple of weeks I have had various discussions around creating imbalanced clusters. Imbalanced from either CPU, memory and even a storage point of view. This typically comes up in discussions where either someone wants to bring larger scale to their cluster and they want to add hosts with more resources of any of the before mentioned types. Or also when licensing costs need to be limited and people want to restrict certain VMs to run a specific set of hosts. Something that comes up often when people are starting to look at virtualizing Oracle. (Andrew Mitchell 
DataGravity 
Atlantis 
Tintri 