I’m starting a new blog series on Microsoft Azure Virtual Machines, and my goal is to write blog posts exclusively on Azure VM/SQL Server related topics.Here is the 1st post –
“Changing the size of a VM”
When creating an Azure VM to host your SQL Server, you have an option to select the pricing tier. This pricing tier states what will be your VM configuration in terms with CPU cores,memory,No of disks, IOPS etc.
Azure provides plenty of pricing tier options,and you have the power to create a VM with the least amount of configuration or pick a monster like below –
Gone are those days where you had to think twice to move your SQL Server workload to the cloud because of the lack of compute power. 32 cores, 448 GB, 64 disks with 80,000 ! Can’t get better than this !
What if I created a VM with a standard pricing tier like DS1 Standard, and after running it for a while realize that it’s not meeting my needs, and my SQL instance starts freaking out.
Hmm, bad planning isn’t? Yeah, it’s definitely bad planning, however Azure will cover you pretty well.
If I go to the portal and choose the settings option for the VM and the select size, I have multiple selection options for pricing tier-
If I scroll down on the selection options, I can see that the G series are not available. This means that you cannot scale up from a D series to a G series directly. Again, not planning ahead can give you trouble.
What if I select DS3-Standard. Will it change my VM configuration on the fly? Lets check it out –
On the portal I’m selecting the DS3 option which is 4 cores and 14 GB memory.
Note – This will restart your VM behind the scenes.If you are following this article and trying to change the pricing tier of a critical production server, then stop and plan to do this activity during a planned downtime.
Within few seconds, I got an alert which says –
Neat ! Lets check the configuration –
Indeed the new configuration is applied after a quick reboot.
Flexibility to change the VM size pretty easy can come handy sometimes,however carefully analyzing the workload compute demands and choosing the correct sized VM is always the recommended approach.
Thanks for reading and keep watching this space for more Azure VM related posts.