In Part 1 of this series I wrote about what exactly the Resource Pool Priority Pie Paradox is and how the share mechanisms can really give you some unexpected results. As in Part 1, the fix is really dependent on your type of environment and how your VMs are configured. Basically, one thing to remember is that VMs with 2 vCPU's will get twice the amount of shares of those VMs that have 1 vCPU. VMs with reservations and limits can also affect how shares are applied. I don't think that the following formula is perfect, and I'm sure it will always be a work in progress, but for a basic environment with now limits or reservations this is a good formula to use to divvie up shares between a Production and Test Resource Pools at a 4:1 ratio (meaning VMs in the Production pool will get 4 times the amount of shares of those VMs in the Test Resource Pool.
I will go through this formula twice, once with a number that I know works out to a whole, and then with the numbers from one of my production clusters. So, lets say we have a cluster with 1740 shares to divide up amongst our Production (High Shares) and our Test (Low Shares) Resource Pools. If have a total 8 VMs, 7 in production and 1 in Test (assuming they all have 1 vCPU) our shares would be set as follows
Production (80% of the 1740 = 1392) Divide that by the 7 VMs and you are left with ~ 198 /VM
Test (20% of the 1740 = 348 ) Divide that by the 1 VM and you are left with 348/VM.
Yikes! Hardly the outcome that we want So in my previous post I mentioned that setting shares to custom and entering a value can help you get the results you want. But how do we know what we want for that value. How can we determine what will give us the 4:1 ratio of Production to Test. Essentially, this number would have to be tweaked as well in order to accommodate for the addition of VMs to either of the resource pools. Anyways, I have a formula that will do just that, essentially it goes like so…a ( 4w – 3x ) = nx y = w – x
a = # of VMs in Production Resource Pool
w = Total # of Shares for Production and Test Resource Pools
n = Total # of VMs in Production and Test Resource Pools
x = This will be the custom share value to set on the Production Resource Pool.
y = Custom Share value to set on the Test Resource Pool
Neat eh? I can't take full credit, I basically had to lay out the scenario to some of the math geeks online in order to come up with the formula!
With that said though it works, so lets pump in our values from above..
a = 7, w = 1740, and n = 8 – Now we will use the first line to solve x (custom shares for production pool)a ( 4w – 3 x) = nx 7 ( 4(1740) – 3x ) = 8x 7 ( 6960 – 3x ) = 8x 48720 – 21x = 8x 48720 = 29x x = 48720/29 x = 1680
Now to get yy = w -x y = 1740 – 1680 y = 60
Now if we do the math, we will get the following
Production Pool ( 1680) Divide that by 5 VMs you get 240 / VM
Test Pool ( 60) Divide that by 1 VM and you get 60 / VM
There you have it, Production getting 4 times more than Test. For fun, lets do it one more time with some larger numbers.
Lets say we have 67 VMs total, 60 in the Production Pool, 7 in the Test. Our Total CPU Shares are 248000. Again, let's assume we are dealing with 1 vCPU machines. So, using the same formula we would get the followinga ( 4w – 3 x) = nx 60 ( 4(248000) – 3x ) = 67x 60 ( 992000 – 3x ) = 67x 59520000 – 180x = 67x 59520000 = 247x x = 59520000 / 247 x = ~240 971 y = w – x y = 248000 = 240971 y = 7029
So we are left with Production ( 240 971) divided by the 60 VMs, roughly 4016 / VM and Test (7029) divided by the 7 VMs, roughly 1004 / VM.
Once again, Production has 4 times the shares as Test. Pretty cool huh? Now I know that this isn't very reflective of the real world (being all 1 vCPU machines) but in order to make it work with SMP VMs you would just need to get the total number of CPU's in production, and the total over all Number of CPUS and use those numbers instead of VM numbers and it should work.