Vmware Cluster Slot Size Calculation

How does it calculate and our mind will think of the below calculation Available slots = Total slot – Used slots i,e Available slots = 234 – 6 = 228. It should come as 228 as available slots but why Available slots is 150 in the above snapshot. Is that wrong or VMware did something wrong in HA slot calculation? As you can see you are talking between 200-250MB per virtual machine of RAM overhead, if your cluster has 20-30 virtual machines with various sizes you could be talking as much as 7.5GB of RAM! Another thing to take into consideration is the virtual machines that you will add in order to run vSphere. To calculate the slot size for a cluster, HA uses the highest CPU reservation of any virtual in the cluster, and the highest memory reservation for any virtual machine in the cluster. If no reservations are set then CPU will be set as 32 Mhz (see screenshot above) and memory will be set as 0MB + the memory overhead.

Welcome to the latest version of my cluster calculator!

You can type in the field of the online table and the online table will calculate how many hosts you need. You can make the calculation for 2 different setups side by side.

Take note that all values in black are VARIABLES (About 20 variables can be adjusted). Changing any of them will change the recommendations in the top and throughout the whole table. This is a work in progress though, potentially storage recommendations will be made as well. Check regularly to see new updates.

All the values, percentages, consolidation ratios currently in the table are examples. These are not the values I would tell you to use.

TPS

NEW: I have added the possibility to add estimated TPS savings to the table. I know, TPS has been taken out of the equation since the latest updates, but some people still enable it because it won’t affect security in their case, or and the memory savings are more important to them.

Here is how the TPS calculation works. For every year I calculate the total amount of RAM needed based on the % of growth for each year. After I have calculated the growth (in the below example, for 3 years) only then I calculate the TPS savings. Take note that what ever memory is used for NFV, has no TPS savings in my calculations. In this case field H116.

DIFFERENT TYPE OF VMs

In this updated version I have added the possibility to add different types of VM’s. So why did I provide this option?

Well for one, if you have a moderate load of General Purpose servers, and a load of Database Servers, the Database Servers’ impact on the CPUs will be higher. Also the vCPU to pCPU ratio should be lower for the database servers than for the General Purpose servers. You do not want a higher amount of ReadyTime for database servers. In fact you should keep this as low as possible..

I have added the possibility to see how many hosts you need per cluster while maintaining N+x redundancy for all clusters ( equally sized Clusters!!!!). The more clusters, the more hosts you will need to be able to guarantee the N+ x redundancy for all clusters. N is defined in Line 77.

Secondly, you might already have some servers and want to add additional servers and see what the effect on your hosts and clusters will be.

Thirdly, Telco virtualization really has a different CPU and RAM usage. So I have given them their own slot. It is important to understand that TELCO requires you to pin the vCPU to physical CPUs. Read: you should not share the physical CPUs which will be used for Telco servers. In the spreadsheet you will see that some values are in red. I urge you not to change these.

Vmware Cluster Slot Size Calculations

On the assumption that Telco servers for most companies will be ‘one time deployments’ only, they are left out of the equations to calculate growth for all years.

However if you are a service provider and adding Telco appliances to your clusters is something you do have to do on a ‘regular’ basis, all you need to do is to bring the value of the Consolidated Total Peak for CPU within the (()) and multiply it all by the growth % for each Year’s line. You will have to do the same for RAM as well.

When I think about explaining how this table deals with calculating CPU usage per server type, the first word which comes to mind here is ‘relative‘. All my calculations, or rather the calculations done in this xls table are performed in relation to a servers’ need to have quicker access to MHz or slots on the cores. The more servers have to share CPU cycles on the same cores, the longer they potentially have to wait until free CPU cycles are available again.

If you do not need all the different types of servers, set the black values to 0 and bear in mind that where a % is listed, the % symbol should remain in the field. so a 0% should be typed as 0%

As with the first calculator, this calculator is mostly build on speculation and assumptions. Please keep this in mind. We try to mimic the real workload so we can make a more or less calculated guess on how many hosts and clusters we will need to service our future workloads.

Vmware Cluster Slot Size Calculation Calculator

Sincere thanks to Ariel Sanchez, Ahmed Ragab and Richard Diaz for their willingness to review the first version of this spreadsheet.

Recommended reads:

Best practices and advanced features for VMware High Availability

Also have a look at Josh Odgers wonderfull online cluster calculator

Kim

Vmware Cluster Slot Size Calculation Chart

We get an enormous amount of questions about VMware’s HA (High Availability), especially when users see a message stating there are Insufficient resources to satisfy HA failover. We have already discussed the mechanism that HA uses to provide high availability here. Now we need to understand capacity calculations. In current versions of ESX (3.02) and earlier the following calculation applies for failover capacity.

HA Failover Capacity

Failover Capacity is determined using a slot size value that is calculated on the cluster. Slots are calculated by a combination of the total CPU and Memory that are in the physical hosts. The calculation for failover capacity works as follows:

Let’s say you have 4 ESX servers in your VMware HA cluster and Configured Failover capacity on the cluster is set to 1.

Vmware Cluster Slot Size Calculation Tool

Physical memory in the hosts is as follows:

ESX1 = 16 GB
ESX2 = 24 GB
ESX3 = 32 GB
ESX4 = 32 GB

In the cluster, you have 24 VM’s each configured and running. Of the 24 VM’s running, determine the VM which has the highest “configured memory”. For this example let’s say this is 2GB. All other VMs are configured with less or equal to 2GB.

With this information we can now do the calculation:
1. Pick the ESX host which has the least amount of RAM. In this case, it is ESX1 and the minimum amount of RAM is = 16 GB

2. Divide the value found in step 1 with value for the maximum RAM in a VM. In my example, this gives us 8 (16 divided by 2). This means we have 8 slots available per ESX host in the cluster.

3. Since we have 4 hosts and the configured failover capacity for the cluster is 1, we are left with 3 hosts in a failure situation. Hence the total number of VMs that can be powered on these 3 servers is 24 VMs. (i.e. 8 multiplied by 3 = 24)

4. If the total number of VMs in the cluster exceeds 24 then it will give us “Insufficient resources to satisfy HA failover” and the “current failover capacity will be shown as 0”. If the number is less than 24, we should not get this message.

Note: If you are still seeing the message and you have less VM’s running than in the calculation allows for, check both the CPU and Memory reservations on both VM’s and resource pools, as this can skew the calculation. You should avoid unnecessary memory or CPU reservations on VM’s as this can cause these types of errors to occur because we have to ensure that the resource is available.

There are multiple ways to fix or get around this calculation. The most common are as follows:
• Set the “Allow Virtual Machines to be powered on even if they violate availability constraints” in the configuration of the cluster. In this case, it ignores the above calculation and will try to power on as many VM’s as possible in case of HA failover. If this is the option chosen you can also set restart priority in the ‘Virtual Machine Options’ section of the cluster configuration. This way any high priority VM’s are powered on first, and then the lower priority up to the point where we cannot power any further VM’s on
• If you have one VM which is configured with a very high amount of memory, you can either lower its configured memory or take it out of the cluster and run it on any other standalone ESX host. This will increase the number of slots available with the current hardware
• Increase the amount of RAM on servers so that there are more slots available with the current RAM reservations.
• Remove any CPU reservations on any VM(s) that are greater than the max speed of the processors in the hosts. For example, if the CPU Usage on the summary tab of your ESX Server shows as follows:

Then you will see the error message popup if you have a CPU reservation greater than 2793MHz on a VM.
Note: The above calculation method is very limited and is going to be revised in future releases of VirtualCenter to improve calculations for HA failover.