Hello Rumple,
I actually have that debate with Database people all the time. Overallocation of memory is just as bad as underallocation. The key is to find the spot that makes everyone happy. Overallocated underutilized VMs cause quite a few issues. It is always an interesting subject and usually comes down to finding the proper metrics that the everyone can understand and say 'ah yes, now I get it'. However, overallocation only becomes an issue when you look at the entire cluster and where things will land during an HA event not the normal run-time. VMware never once mentioned you should overallocate your VMs, they however did say you can overcommit memory up to a point. Once you get to the point where you are swapping to disk, it is really time to get more memory or more host. Everything comes down to how much those resources being allocated cost vs the cost of the actual in use resources.
In my experience I have seen what is considered abnormal (such as an HA event) become the normal due to political reasons. Many companies I know also have overbought resources, such that they have what I consider low consolidation ratios. Some have very high but low utilization consolidation ratios.
My customers are worried about this change, I was worried about this change. I am running the numbers here, and will run the numbers with my customers and then make recommendations based on those numbers.
For architecture work, I tend to figure a node is no more than 70% utilized and as necessary with a high end of no more 80% utilized. Because of customer requests I have architected nodes that are no more than 50% utilized. It all depends on the type of redunancy you require. I also think about HA events; where will also those VMs go and how will they be handled. N+1 or even N+2 is usually the standard for many architectures, and that still stands today. I always had to worry about memory before. Now I am forced to consider it for licensing not just application placement and best use of nodes but now in real $s. TPS and the other overcommit technologies come into play for determining the upper limit on memory and number of VMs per node. I also understand that this may not be the case a few months in production.
Also from an architecture view, deduplication and such do not come free either, usually it is an extra cost or license anyways. Now I agree some build it in, but you end up paying for it somewhere. Storage is not cheap, and never has been, add SSD to that and prices skyrocket for some loads. What to use will depend on SLAs, the cost to maintain that storage also changes every year. I have yet to see it actually go down. If I enable thin provisioning, I also have issue when suddenly all blocks get allocated, so I have to build in overheads into my storage in this case as well. Is that overhead something large? I think that depends on the application more than anything. I agree however that just to charge me more for something I already own is an issue. Never claimed it was not. Yet, if we purchase support and the prices are suddenly doubled, would you get different storage or make due with what you have without support? That again depends on your SLAs and what you need to achieve.
Scale out vs Scale up has always been the debate and we have swung to either direction many a time. To me scale-up is not just scaling up memory but also processor. I also look at how much memory costs at the density I have in mind, if he memory to go from a 4GB dimm to an 8GB dimm for my chassis is more than another chassis (and in some cases it is), I will go for the other chassis, UNLESS there is a real need for this for any one application and in that case to provide redundancy, I may buy two like boxes and set up affinity rules for HA. So Scale-Up to me includes processors. Scale-out is is related to memory and the cost of my box.
Your vRAM pool may be bigger than you realize, but I can also see the case where it is smaller than you thought and yes in that case, VMware will request you purchase more licenses and I agree that is an issue for older systems. As I stated before I hope this changes and the upper limits of memory for each license level increase to give more elbow room, or that there is a special high density waiver or reduced cost, much like what they did to get everyone that had Enterprise to go to Ent+.
If after running the numbers with some tool and I find out that one of my customers are in need of more license, which I would assume there will be a few, I would definitely be one of the ones talking to VMware about it.
FYI, I am a customer and a consultant in this space. I see both sides and have to plan appropriately.
Is this the proper pricing model? Not sure, for some it will not make much difference, for others it will have a huge impact. I think it will be tweaked a few times more. What would be a better pricing model for utility style computing?
I never much cared for the last change to licensing either. Eventually VMware moved some of the sought after features into the lower license levels which helped alleviate some issues.
I am still trying to understand this model myself and am looking at my environment as well to see where I fall so that I can assist my customers going forward. Which tool provides the best results, what exactly comprises a vRAM pool in all those environments.
Best regards,
Edward L. Haletky
Communities Moderator, VMware vExpert,
Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition
Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf
--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
