Let's look at the first line chart. The number of vCPUs left is essentially supply and demand. The supply and demand can be defined as the following:

On the supply side, we can choose physical cores or physical threads. One will be conservative while the other will be aggressive. The ideal number is 1.5 times the physical core, as that's the estimated performance improvement from Hyper-Threading.

My recommendation is to count the cores, not the threads. There are two reasons for this:

That's it for the supply side.

The demand side is simpler. It is simply the sum of all the vCPUs in all the VMs in the cluster.

Count the ESXi agent VMs too. This includes basic VMs such as a Nutanix Controller Virtual Machine (CVM) or Trend Micro Deep Security VM. Regardless of their functionality, they are consuming CPU resources.

If you are using virtual threads in your VM, then count them as if they are full vCPUs. For example, a VM with two vCPUs and two threads per core should be counted as four vCPUs.

In logic, the super metric formula is:

vRealize Operations has a metric that takes HA into account. You do not need to manually build the formula any more.

The following screenshot shows the actual super metric formula:

Super metric – Number of vCPUs left in a tier-1 cluster

Since we need to apply the formula to the vSphere cluster in question, we need to use the THIS option. Click on the little blue icon above the formula bar, as shown in the following diagram, then double-click on the formula you want to use:

Super metric – enabling the THIS formula

The actual formula is as follows:

Avg(${this, attribute=cpu|alloc|object.capacity}) - Avg(${this, attribute=summary|number_running_vcpus})

We've covered CPU. RAM follows a similar logic. The amount of vRAM left is also based on supply and demand, where:

There is no need to include ESXi vmkernel RAM as it is small enough to ignore. In addition, almost no VM uses its configured RAM, and you have Transparent Page Sharing. These two reasons are also why we do not see the need to add a threshold.

If you need to include one, review Chapter 13, Memory Counters.

If you are using VSAN and NSX, you can add some buffer if you think that's necessary. For VSAN 6.1, Cormac Hogan explains this at http://cormachogan.com/2015/11/10/vsan-design-sizing-memory-overhead-considerations/. In most cases, we can ignore both NSX and VSAN overhead.

You do not need to include virtual appliances as they take the form of a VM; hence, they will be included in the demand.

If you find the formula complex, you can actually split them into two super metrics first. Work out supply, then work out demand.

Super metric – Number of vRAM left in a tier-1 cluster

The actual formula is as follows:

(Avg(${this, attribute=mem|alloc|object.capacity}) – Sum (${adapterkind=VMWARE, resourcekind=VirtualMachine, attribute=mem|guest_provisioned, depth=2}) )/1000/1000

The third line chart we need to display shows the total number of VMs left in the cluster. While the first two line charts come from the Performance Policy, this comes from the Availability Policy.

Normally, availability is associated with the ESXi host. For example, you keep the maximum number of VMs in a given ESXi host. The logic here is that if any ESXi goes down, you're capping the number of affected VMs.

We apply the Availability Policy at the cluster level since it makes more sense. Applying it at the ESXi host level is less relevant due to HA. Yes, the chance of a host going down is higher than that of the entire cluster going down. However, HA will reboot the VMs, and VM owners may not notice. On the other hand, if a cluster goes down, it's a major issue.

The supply and demand can be defined as follows:

Can you notice a limitation in the formula?

It assumes that your tier-1 cluster size does not vary. This is a fair assumption as you should keep things consistent in tier 1. If, for some reason, you have multiple cluster sizes (for example, 8, 10, or 12), then you have one super metric per size.

The following screenshot shows the super metric formula for the total number of VMs left in the cluster:

Super metric – the number of VMs left in a tier-1 cluster

We have hardcoded the maximum number that we allow. While you can do away with hardcoding to some extent, it is acceptable as policy changes require agreement from the business.

The actual formula is this:

100 - Avg(${this, attribute=summary|number_running_vms})

In the beginning of this chapter, we recapped that we needed to produce three line charts. Look at the line charts in the previous three subsections as one group. Take the one with the lowest number as the determining factor that you're running out of capacity.

You've got the supply and demand. You know when the number will reach zero.

The question is: when do you buy new hardware?

Because this is tier 1 and you promise identical specifications, this could mean a new cluster. Buying a cluster can be a substantial commitment, so it has to be planned properly.

If you manage a very large environment and are buying clusters quarterly, you can set a threshold. For example, when you are down to the 10 percent capacity, you can trigger a new cluster purchase.

You do not have to build your threshold (which is your buffer, actually) into the super metric formula as it is dynamic. Once it's hard-coded in the super metric, changing it does not change the history.

It is dynamic because it depends on the business situation. If there is a large project going live in a few weeks, then your buffer needs to cater to it. This is why we need to stay close to the business. It's also something you should know, based on your actual experience in your company. You have that gut feeling and estimate.

For an emergency, temporary solution, you can still deploy VMs while waiting for your new cluster to arrive. This is because you have an HA buffer. ESXi hosts are known for their high uptime.