How do vCPUs work in Zettagrid?

What is a vCPU?

A vCPU is a virtual CPU and is an encapsulation of many underlying physical blade host processors presented via VMware to a single VM as its local processor.

Since a vCPU is based on the underlying host CPU the actual GHz amount will be a one to one mapping from its physical counterpart.

What is a vCPU in Zettagrid?

Our standard measure is 2Ghz - 1vCPU

Zettagrid create clusters which are all of the same CPU type so as to not mix CPU types and lose any of the available CPU instruction sets as anything in the same cluster will remove CPU instructions down to a common base level among all hosts in that cluster.

Does higher GHz per vCPU mean it?s better?

No, whilst there is a correlation between the two it isn't really a good indication of value for money or being on a better host if the underlying CPU is 2.3GHz rather than 2GHz.

As we upgrade the environments they will often get different CPU types and GHz amounts. At all times the introduction of a new CPU type means a better performing VM as it is a newer generation with a higher instruction set.

It is quite conceivable that in future the next GHz amount may in fact reduce per vCPU. This will actually mean that for the same price per month the customer is getting more value as the amount they have purchased can be utilised for more concurrent vCPU.

How do you sell CPU resources?

We sell CPU resources as a total of GHz consumed at any one point in time in the environment.

It is not an allocated model it is a concurrent consumed model or a high water mark. This means that customers can utilise very large amounts of overprovisioning if so desired but this might mean that in peak times when many of your VMs are running high CPU workloads you will be limited in terms of available CPU resources. In the event of this the VMs will go into a CPU Wait state for available resources when other VMs in your own environment are not using them.

Scenarios

1. Customer has 100 VMs all with 2 vCPUs assigned. The customer is paying for 200GHz. In this scenario all VMs will be able to utilise all the resources that have been paid for as even if every VM is running both CPUs at 100% the total will only be 200GHz which is what has been assigned to the customers Virtual Data Centre. There is no conceivable event where any VM does not have access to its resources.
2. Customer has 8 VMs all with 1 vCPU assigned, 6 powered on and 2 powered off. The customer is paying for 12GHz. In this scenario the 6 powered on VM are working fine performance wise. The customer has powered on an additional 2 VMs and now their users are complaining of performance issues. With the 8 VMs powered on the requirements could burst up to 16GHz but the customer is only paying for 12GHz so the customer would need to either be aware that performance may be an issue, power off the additional 2 VMs or increase the allocated resources in the environment to 16GHz.
3. Customer has 100 VMs all with 1 vCPUs assigned. The customer is paying for 30GHz. In this scenario the customer is obviously drastically under allocating CPU resources for their VDC as the provisioned amount would be 250GHz. In day to day usage of the VMs they are generally only 10% utilised in terms of CPU. 10% of a single vCPU is .2GHz and for the 100 VMs this is 20GHz in total day to day. In this scenario whilst the customer is not paying for nearly enough CPU it is not constrained in normal activities as they are still under the 30GHz total that has been allocated. A warning in this scenario though, if any VMs start doing work more than the average then there may be periods where the total GHz used is over the 30GHz so it will be resource constrained when this occurs and potential for users to create service desk tickets complaining of performance problems.
4. Customer has 100VMs with a mixture of 1-4 vCPUs assigned. The customer has allocated 200 GHz to the Virtual Data Centre. Generally in the environment the VMs day to day run at 30% which would have a total resource requirement in GHz terms of 260GHz. In this scenario the VMs will constantly be resource constrained by our systems as there is not enough resources provided so it is expected that the VMs will run slower than they should be in normal circumstances as they are continually in a CPU Wait state.

So how much should I buy?

This is a hard question to answer as it is different for every customer. If you want to ensure that your VMs always have the CPU resources that they require then purchase 2 x the total number of vCPUs assigned to VMs per Virtual Data Centre.

If you think your VMs often don't need all their CPU power then you can under allocate by 50-80% and see how the performance goes day to day whilst making sure that you capture all use cases (like the end of month reports that run etc). If you find that users are feeling the VMs underperforming then increase the resources until you find a happy medium of price/performance.

If cost is the driving force entirely then reduce the amount of GHz allocated to the VDC drastically and simply put up with the artificial limits that are placed on each VM and be aware that the VMs will be considerably crippled.

Isn't it easier to just sell vCPUs?

Yes, it most definitely would but we prefer to give customers the final say in how much over-provisioning they wish to have in their own environment so that there is more granularity and control over how their VDC performs.

You may have a few Virtual Data Centres and would like to have the production VDC fully allocated in terms of vCPU so it is never constrained but also have a test VDC in which it really doesn't matter if it suffers from CPU Wait times as performance is of no concern. In this scenario the test VDC may only have 25% of the required CPU resources and is a great way to save money rather than wasting it on CPU where it isn't valued.