Ah, SQL, CPUs and licenses... you've got to love it.
Our SQL servers have specific loads, patterns and resource requirements. We've monitored them, we know what they are inside and out. You know that x number of CPUs, and y GB or RAM means that your DBs happily sweat the hardware, but are sized to perfection to make sure it has just enough resource to complete what it needs to do. The negotiations with your Infra team in command of the VM resources were tough, but you're not greedy... you appreciate that other VMs may require resource as well...
Now you have to migrate to Azure, and SQL on Azure VM is your only option. Great, loads of different types/flavours of VMs out there, one of them must be in the the goldilocks perfect porridge zone right? Right?
If you don't care about budgets, a huge (potentially unwarranted) monthly bill, then there's no problem...pick the biggest VM to cover requirements and you're done. Microsoft offer a large range of different families of VMs these days, all with varying CPU / RAM / IO offerings.
Nothing fits anymore after Xmas.
But what happens if you're inbetween sizes?
Lets have a closer look at the Ev5 series.
And say your on prem server has a requirement of 4CPU, 96GB of RAM... damn, no size for that one...Standard_E14s_v5 handles the CPU, but short on RAM. So, lets ramp it to the Standard_E16s_v5 instead as that covers our Memory requirement. Cool... done.
...but my vCPU count just quadrupled also... ouch, that means 4x the license requirement instantly. And if you're on Enterprise Edition, then mucho oucho.
There might be a better Family/series fit for you to make use of, but that might be a compromise somewhere too.
Here in lies the problem.
On Prem, we have full control over what we can size our servers to...if we want to have a VM with 13 CPU, and 37GB of RAM*, we can. Microsoft can't be expected to offer this level of granularity, so offer a selection box of the popular sizes to cover most situations, nothing wrong with that.
The downside is that with the SQL licensing to think about too, if we fall into the cracks between the sizings, and have to uplift...the £££ pain can be err...painful.
*Please don't, using odd numbers on VM sizing irrationally triggers me for some reason.
Constrained Solution
Clearly, this has been thought about previously, as Microsoft also offer us Constrained vCPU sizings, based on (some of) the base VM sizes. It's designed for exactly this situation, where you have specific requirements, and 'vanilla' sizes may mean you're hit with a monsterous license increase through no really fault of your own. MS even use SQL as the example...we haven't moaned at them that much surely?
Ultimately, you can reduce your CPU requirement to either 1/2 or 1/4 of the original size. Note, these CPUs are disabled.
So, what are our options for the VM case above? As mentioned, a quarter, or a half CPU of original. All other limits on the VM are kept identical to before.
Size name | Active vCPUs | Base size |
Standard_E16-8s_v5 | 8 | E16s_v5 |
Standard_E16-4s_v5 | 4 | E16s_v5 |
Alas, no cost reduction in the VMs, but I can live with that if we're avoind SQL license cost murder death kill.
Hidden in plan sight.
These are deployable in any fashion, portal, template, az client etc, distinguished by the hyphen then a number. No excuse not to use them.
And if we have a look at the VM sizing page, the information is right down at the bottom, a little further away from the family pages than maybe you'd expect. Personally, I think a reference in each of the family sizes reminding you of the option to use Constrained CPUs would be nice, but that's just me.
Also, they show up in VM pricing calculator, but can be easily missed under the standard series listings due to the number of size offerings nowadays. You can select Constrained vCPUs capable to show all however.
Summary
You may have been using these already to be honest, just selecting from the available VM sizes. It does appear easy to miss though, which is odd, Microsoft has gone to the trouble of providing this for us, but its not openly baked it into their detail pages 'front and center' so its unmissable.
So, if you've just gone on the basic VM sizes, or from the calculators without looking closely, its possible to miss this altogether if you haven't read every page of the docs. Worth checking? Up to you.
Thanks for reading
Rods-v4 series
Original title image courtesy of Freepik