Support Tips: Scale HC3 CPU Over Provisioning
-
Hey all. I wanted to talk about a topic that may be confusing for some users. Over-Provisioning CPUs for VMs.
Scale Computing’s HC3 system like any virtualization platform has physical limitations when it comes to CPU resources. Each node in a cluster has a physical limit to the number of physical cores and threads available to present to guest OSs. If you choose to you can allocate resources to your virtual machines based strictly on on the number of threads available on a physical node.
If you have two 8 core hyperthreaded processors in a node you will have 32 threads or logical CPUs you can assign for a 1 to 1 ratio on each node. In most instances there are CPU cycles that will go unused in a 1 to 1 setup. HC3 can utilize processor scheduling to allow for Over-Provisioning of CPUs meaning that for the same 32 threads that are present you could allocate 64 or 96 virtual CPUs and allow VMs to utilize idle cycles that would have been wasted in a 1 to 1 setup.
One restriction that is built into HC3 is that it will limit any individual VM to the number of threads available on the lowest capacity node in the cluster. If you have 2 nodes with 32 threads and 1 node with 16 threads, any one VM will only be able to allocate 16 virtual CPUs. This prevents any 1 VM from being unable to run if a livemigrate to another node happens and the VM tries to utilize all virtual CPUs. When deciding how to over-provision it is best to start with conservative numbers and build up if there are no issues. If you start seeing high CPU spikes or high wait times it may be important to turn down the amount of over-provisioning being used.
-
@blakerodier said in Support Tips/Tricks and maybe a Treat or two!:
Hey all. I wanted to talk about a topic that may be confusing for some users. Over-Provisioning CPUs for VMs.
Scale Computing’s HC3 system like any virtualization platform has physical limitations when it comes to CPU resources. Each node in a cluster has a physical limit to the number of physical cores and threads available to present to guest OSs. If you choose to you can allocate resources to your virtual machines based strictly on on the number of threads available on a physical node.
If you have two 8 core hyperthreaded processors in a node you will have 32 threads or logical CPUs you can assign for a 1 to 1 ratio on each node. In most instances there are CPU cycles that will go unused in a 1 to 1 setup. HC3 can utilize processor scheduling to allow for Over-Provisioning of CPUs meaning that for the same 32 threads that are present you could allocate 64 or 96 virtual CPUs and allow VMs to utilize idle cycles that would have been wasted in a 1 to 1 setup.
One restriction that is built into HC3 is that it will limit any individual VM to the number of threads available on the lowest capacity node in the cluster. If you have 2 nodes with 32 threads and 1 node with 16 threads, any one VM will only be able to allocate 16 virtual CPUs. This prevents any 1 VM from being unable to run if a livemigrate to another node happens and the VM tries to utilize all virtual CPUs. When deciding how to over-provision it is best to start with conservative numbers and build up if there are no issues. If you start seeing high CPU spikes or high wait times it may be important to turn down the amount of over-provisioning being used.
Available means physically (or logically I guess since they're hyperthreaded) on the nodes? So if you have identically spec'd nodes there shouldn't be an issue with over provisioning?
-ordering my first Scale cluster tomorrow
-
@Kelly The available virtual cores you can assign to a particular VM match the number of logical threads(for hyperthreading) on the nodes. If you have identically spec'd nodes there will be no restrictions put in place beyond that for the number of virtual CPUs you can assign to a particular VM.
The limit of number of virtual cores to the smallest amount of logical threads is specifically to prevent issues with over-provisioning so there are automatic limits put in place to prevent issues that would cause VMs to not be stable.
I'm really glad to hear you are purchasing a cluster and we look forward to working with you.
