I have a doubt concerning the relation between the physical capacity and virtual capacity for processing.
Suppose that I have a cluster which has 3 servers with 2 pCPU, each pCOU with 10 cores and hyperthreading active.
For the point of view of the host capacity each host has:
- Processor sockets: 2
- Cores per socket 10
- Logical processors: 40
How many vCPU's do I have? Is there any tool to calculate it?
When I create a VM I'm requested to "select the number of virtual CPUs for the virtual machine" and there I have:
Number of virtual sockets
Number of cores per virtual socket
What is the relation between this and the physical environment?
you may create any number of VMs having vCPUs upto 40 vCPUs (any combination of core or sockets can be selected) while creating a VM. Actually, there is not direct relationship between physical and vCPUs. The core/socket option available at virtual machine level is to satisfy the needs of some application, but actually the VMs works with total number of vCPUs.
No matter what, whatever sockets you select at VM level, the CPU scheduling at the hardware level is based on total number of vCPUs not with core/sockets.
I suggest reading this document to gain a better understanding of physical vs virtual resource allocation and overcommitment: Best Practices for Oversubscription of CPU, Memory and Storage in vSphere Virtual Environments
Excerpt from white paper, specifically discussing CPU overcommitment:
"Various forums are filled with questions from users requesting insight into acceptable vCPU to pCPU ratios in a real world environment. While some responses continue to advocate for a 1:1 ratio, from a pure density standpoint, 1:1 should be considered a worst-case scenario. In the diagram to the left, note that this particular lab has a current ratio of 2:1.
Some respondents indicate that they have received guidance that suggests no more than a 1.5:1 vCPU to pCPU ratio, but guidance from industry experts suggests that vSphere “real world” numbers are in the 10:1 to 15:1 range. Still others indicate that VMware itself has a real world recommended ratio range of 6:1 to 8:1.
In this Dell white paper, the following vCPU:pCPU guidelines are established:
• 1:1 to 3:1 is no problem
• 3:1 to 5:1 may begin to cause performance degradation
• 6:1 or greater is often going to cause a problem
Additional guidance suggests that keeping the CPU Ready metric at 5% or below is considered a best practice.
The actual achievable ratio in a specific environment will depend on a number of factors:
• vSphere Version - The vSphere CPU scheduler is always being improved. The newer the version of vSphere, the more consolidation that should be possible.
• Processor Age - Newer processors are much more robust than older ones and, with newer processors, organizations should be able to achieve higher processor ratios.
• Workload Type - Different kinds of workloads on the host will result in different possible ratios"
Answer, of course, is it depends.
One of the factor is the number of vCPU in each VM. Since a VM will allocate all the vCPU defined beore processing, the more high vCPU VM you have the closer to a 1:1 ration you need to get to. Back when a VM was happy with a single vCPU, 10:1 and even 15:1 was pretty normal. Now, I'd target 5:1 to 10:1
I gotta chime in here! Remember VMware and Dell are not your friend!
If it was up to the hardware and hypervisor vendor, you would use the lowest possible vCPU/pCPU ratio. Lower ratios = more pCPUs = greater profits because you need more pCPUs which require more vSphere licenses!
I have been doing this (VMware) for more than 10 years now and consulted on hundreds of client environments. Rarely, if ever do you see actual CPU overuse. Oversubscription maybe, but not over use.
As a generalization, I like to target 4 vCPU to 1 pCPU for servers and 6 vCPU to 1 pCPU for desktops. There are exceptions, however observation will allow you to hone-in on the actual ratio that renders optimal utilization without contention.
Hope this helps!
I'd like to extend this question specifically as it relates to HA. In a small environment (2 hosts), if you've oversubscribed at say a 3:1 ratio are you going to kill your server if one goes down? (We have 3 hosts but the third is offsite for replication at another office.) So I have two usable servers on site. Right now I'm running a 1:1 ratio so that if a host goes down, I don't kill the performance on the other server. And I have tested this setup and nobody even realized we were running on one host. Any input would be appreciated.
The answer is, of course, it depends. While optimum design is n-1, budgets often make this impossible. I shoot for as close to that as possible, but in the event of over-committed hosts, I'm ready to first shut down any non-critical guests and I have no issue standing in the boss' office explaining why we are running a bit slower. That will trigger one of 2 things. 1) He'll accept it. oor 2) tell me to get what I need so it does not happen again.
Regarding HA, use the Admission Control feature to protect against Host failure.
When you set "protect against X Host failures" you are essentially creating a cluster-wide default reservation as big as X host resources. In a 2 host cluster, it is difficult to compliment Admission Control and still have usable resources. I never recommend or deploy 2 host clusters for this specific reason.
Without admission control, the remaining host(s) operate on a best effort basis and there may be contention for CPU. This usually means increasing CPU Ready and Co-Stop, with reduced performance, but not systems failing.
The only real problem is if you have applied excessive (any in my book) CPU or Memory reservations directly to the VM. Software developers often recommend these as a way of prioritizing one VM over another, but CPU or Memory reservations adversely affect the availability of the entire environment - and should be disregarded except in justified use cases.
AmericaCube, the article from 2013 is outdated.
Mark Achtemichuk has published a new article 4 years later. It deals with the vNUMA changes since vSphere 6.5:
Essentially, the vNUMA presentation under vSphere 6.5 is no longer controlled by the Cores per Socket value. vSphere will now always present the optimal vNUMA topology unless you use advanced settings.
Say you have 4 hosts in a cluster, each with a 16-core CPU - you have a total of 64 cores in your cluster.
If you build all your VMs with 2 CPUs each, once you‘ve created 32 VMs you have a total of 64 vCPUs.
At that point your ratio of vCPUs to physical CPU cores is 1:1
If you also account for HA (or maintenance) and 1 host in the cluster is offline, your VMs will then be running across 3 hosts with 48 physical cores between them - your ratio is then 1.33:1
Lose another host and your down to 32 physical CPU cores, at a ratio of 2:1
why did you calculate in cluster ? I think we have to calculate this ration in each host
for example I have 10 esxi host in my cluster with follow info :
DL 580 G10
Processor sockets 4
Processor cores per socket 28
and vcpus that assign to vms on this host1 is 118 vcpus
vcpus that assign to vms on this host2 is 144vcpus
vcpus that assign to vms on this host3 is 129vcpus
vcpus that assign to vms on this host4 is 156vcpus
vcpus that assign to vms on this host5 is 130vcpus
vcpus that assign to vms on this host6 is 110vcpus
vcpus that assign to vms on this host7 is 154vcpus
vcpus that assign to vms on this host8 is 122vcpus
vcpus that assign to vms on this host9 is 129vcpus
vcpus that assign to vms on this host10 is 102vcpus
now how do I had to calculate that ?
You have 112 cores per host, and 10 hosts, so a total of 1120 physical cores.
Add up all your vCPUs, that’s a total of 1294.
Your ratio when all 10 hosts are available is 1294:1120, which if you divide both sides by 1120 is 1.155:1
If you had only 7 hosts available, you would have 784 physical cores, your ratio would then be 1294:784 or 1.65:1
Take half of your cluster out of action and you have 560 cores remaining, your ratio is then 1294:560 or 2.31:1
would you say please when and where had to notice to this parameter ?
Is there any best practice for this ?
What can understand from this ? Actually how can help me to optimize my infrastructure /
would you say please when and where had to notice to this parameter ?
I don’t understand your question.
Is there any best practice for this ?
There was a link posted earlier in this thread.
What can understand from this ?
I don’t understand your question, but your ratios are low.
Actually how can help me to optimize my infrastructure /
Are you suffering from poor compute performance? If so, this is just one of many things to consider. If not, don’t worry about it.
By reading through this thread and following the links posted in it.
I see you’ve posted before about vRealize Operations, make use of it.
The physical core on ESXi needs to be calculated.
(Physical socket) x (core) = Indicates the total amount of physical CPU, ie pCPU. If HT is not active in the environment, it is the maximum amount of vCPU you can give to the virtual machine.
If HT is active in the environment;
(pCPU) x (2 x core) = Returns the total number of vCPUs.
Now if we proceed with a simple example;
We have a server with 2 physical sockets, each with 16 cores. HT is also active on this server. In this case, if we proceed according to the calculation above;
(2 sockets) x (16 cores) = There are 32 cores in total. If HT is not active, this is the maximum amount of CPU you can give to a virtual server. However, since HT is active, we continue to calculate.
Since (32 core) x (2) = HT is active, our total vCPU amount, that is, the maximum CPU amount we can give to the virtual server is 64.
Now let's come to the real question. We have a server with a capacity of 64 vCPU. How many virtual machines can I host on this server? First of all, as I mentioned above, you can also use resources that you don't have thanks to CPU overcommitment. In this case, you can create 10 virtual servers with 64 vCPUs. A total of 640 vCPUs may have been assigned, but virtual servers cannot use so many resources. Why? Because the physical resource on ESXi is not that much. So if you give this much CPU, it is very likely that you will experience performance problems. For this, VMware proposes the following rates and asks you to calculate accordingly.
According to the account we made above, we have 64 vCPU capacity. According to this account;
1: 1 = If you keep the total number of vCPUs assigned to virtual servers created under ESXi 64 or less, you will not experience any performance problems. I recommend that you use this rate only and only in environments where you have very critical workloads.
2: 1 = You can give a total of 128 vCPU resources to the virtual servers you create on ESXi if you want to use the 2: 1 ratio here. When you choose this rate, you will not experience any performance problems.
3: 1 = If you want to use the middle of 3: 1 here, you can give a total of 192 vCPU resources on the virtual servers you create on ESXi. When you choose this rate, there may be some small or low changes compared to the previous two configurations.
4: 1 = If you want to use the middle of 4: 1 here, you can give a total of 256 vCPU resources to the virtual machines you create on ESXi. This rate is actually the most optimal rate recommended.
If you use the 5: 1 or 6: 1 ratio here, you may experience serious performance problems. If you are using VDI media, you can use 5: 1 or 6: 1 ratios.
On the VMware side, if you absolutely want to follow a rule and wonder how the rates should be, you can use the rates I mentioned above. The rates stated here are actually purely architectural decisions. You may never want to overcommit the CPU side and use it in a 1: 1 ratio. Yes this is possible. If you think of a different scenario, you can use a ratio like 10: 1. Of course, this ratio will cause you various performance problems. However, there is no obstacle in your use. If you do not overcommitment, you cannot use CPU resources more effectively and efficiently.