Follow @StolarekMarcin

One of the main advantages of servers virtualization is the ease of resources resize. It’s quite common that you start a service with limited resources – in terms of CPU, memory, disk space or performance and at some time the service requires more resources. This may be a result of the growth in the number of concurrent users – typically meaning more memory or CPU required or data volume growth ending up with the need for additional space.

Although, on premise virtualized infrastructure provides you additional flexibility you’re still going to be limited by the total resources in your environment. Even in big organizations you may end up with resources splitted across a few tiny clusters, potentially managed by different supervisors. In this case virtualization gives you nice method of splitting bigger physical machines into small isolated virtual environments, but really doesn’t allow scaling of particular VMs – this is the place where cloud IaaS services come into play with their “nearly infinite” resources. How does this compares to real live? I’ll try to answer this question based on my experience with Azure.

What one should know about vm resize in Azure IaaS?

as always on funinit-from command line perspective.

To explain resizing options let’s start with size definition. When you check Azure calculator [1] or sizes description [2] you’ll discover that there are various options with different layers, profiles and sizes finally constituting your VM size. If you feel overwhelmed with possibilities, let’s check available sizes from command line – it’s always simpler than on colorful webpage:

$ az vm list-sizes az vm list-sizes: error: argument --location/-l is required

As you see you have to specify the location, so we’ve learned 1st limitation – available sizes differ between locations. If you don’t know the name for location of your interest just list them:

$ az account list-locations -o table DisplayName Latitude Longitude Name ------------------- ---------- ----------- ------------------ East Asia 22.267 114.188 eastasia Southeast Asia 1.283 103.833 southeastasia Central US 41.5908 -93.6208 centralus East US 37.3719 -79.8164 eastus [...]

Finally having the name of location, we can list available sizes:

$ az vm list-sizes -l westeurope -o table MaxDataDiskCount MemoryInMb Name NumberOfCores OsDiskSizeInMb ResourceDiskSizeInMb ------------------ ------------ ---------------------- --------------- ---------------- ---------------------- 1 768 Standard_A0 1 1047552 20480 2 1792 Standard_A1 1 1047552 71680 4 3584 Standard_A2 2 1047552 138240 8 7168 Standard_A3 4 1047552 291840 4 14336 Standard_A5 2 1047552 138240 16 14336 Standard_A4 8 1047552 619520 8 28672 Standard_A6 4 1047552 291840 16 57344 Standard_A7 8 1047552 619520 1 768 Basic_A0 1 1047552 20480 2 1792 Basic_A1 1 1047552 40960 4 3584 Basic_A2 2 1047552 61440 8 7168 Basic_A3 4 1047552 122880 16 14336 Basic_A4 8 1047552 245760 4 3584 Standard_D1 1 1047552 51200 [...]

As you see VM size is described by the following parameters: MaxDataDiskCount, MemoryInMb, Name, NumberOfCores, OsDiskSizeInMb, ResourceDiskSizeInMb. While numeric parameters are quite self-explanatory name may sound like the string you’ll use as a reference to numeric parameters. It’s true, but not the whole truth. The beginning of size name is always Basic or Standard – it’s tier. To make long story short “basic” VMs are available only from A series, they can use neither autoscaling nor load balancing features of Azure and are ~20% cheaper than “standard” VMs.

Does the capital letter in size name come with additional features? Yes. You may need to check the details [2] since there are hidden limitations like number of IOPS per VM or memory to CPU bandwidth. The most special series are:

B-series ( Burstable virtual machines ), designed to be running with limited CPU utilization and the need for intensive computing only during the bursts. Those are really cheap [3].

), designed to be running with limited CPU utilization and the need for intensive computing only during the bursts. Those are really cheap [3]. N-series, where as a feature you can use GPU . (Does N come from Nvidia? )

. (Does N come from Nvidia? ) H, A8-11 where you can use RDMAma communication between VMs. ( H come from High Performance Computing, but.. A8-11 🙂 )

OK.. let’s get back to the console. When you know sizes available in your location you may think that all of them are available for your VM, which is not necessarily true, since your VM may be running on the cluster that doesn’t support some sizes available in the location. To list the sizes available on the cluster your VM is currently running, use the following command:

$ az vm list-vm-resize-options -g awx-test -n awx-test -o table MaxDataDiskCount MemoryInMb Name NumberOfCores OsDiskSizeInMb ResourceDiskSizeInMb ------------------ ------------ ---------------------- --------------- ---------------- ---------------------- 2 2048 Standard_B1ms 1 1047552 4096 2 1024 Standard_B1s 1 1047552 2048 4 8192 Standard_B2ms 2 1047552 16384 4 4096 Standard_B2s 2 1047552 8192 8 16384 Standard_B4ms 4 1047552 32768 16 32768 Standard_B8ms 8 1047552 65536 4 3584 Standard_DS1_v2 1 1047552 7168 8 7168 Standard_DS2_v2 2 1047552 14336 16 14336 Standard_DS3_v2 4 1047552 [...] $ az vm list-vm-resize-options -g aws-test -n awx-test -o table | wc -l 43 $ az vm show -g awx-test -n awx-test | grep location "location": "westeurope", $ az vm list-sizes -l westeurope -o table | wc -l 190

As you see from the the commands at the end of the above console listing number of sizes supported on your cluster is normally small compared to the sizes available in the location. Remember that some “sizes” are bound to very specific features, so when you’re running non-gpu machine you probably cannot switch to machine with gpu without the cluster change, but this type of resize is very rare. However, from my experience it’s common that if you are running standard D-series machine you cannot simply resize to B-series VM – for me it’s common operation to use D-series for new service during deployment and then resize to burstable VM for long term production. You can always try, but this will probably end up with error message similar to the one below:

$ az vm resize -g hpc-awx -n hpc-awx --size Basic_A1 Unable to resize the VM 'hpc-awx' because the requested size Basic_A1 is not available in the current hardware cluster. The available sizes are: Standard_A0,Standard_A1,[...]

How can I resize to the size not listed by az vm list-vm-resize-options ?

In this case you have to deallocate machine first, then resize it and start again – ending up with longer downtime than “hot” resize which is just VM reboot. Let’s check how it works

$ az vm deallocate -g test-awx -n test-awx { "endTime": "2018-03-24T09:06:54.809149+00:00", "error": null, "name": "c35798c4-925f-4fee-95fb-26dbcfdbd313", "startTime": "2018-03-24T09:04:22.552129+00:00", "status": "Succeeded" } $ time az vm resize -g test-awx -ntest-awx --size Standard_B2s > /dev/null real 0m37.669s user 0m0.402s sys 0m0.111s $ time az vm start -g test-awx -ntest-awx { "endTime": "2018-03-24T09:26:19.172330+00:00", "error": null, "name": "358ebfb0-1a4b-456e-b7b3-27bea09e73c6", "startTime": "2018-03-24T09:24:41.156280+00:00", "status": "Succeeded" } real 2m9.514s user 0m0.312s sys 0m0.083s

As you see from the listing above the whole operation took around 5 minutes, personally I think it’s quite a lot. Now resize to other burstable hardware profile (within the same cluster) is simpler:

$ time az vm resize -g hpc-awx -n hpc-awx --size Standard_B1s real 2m41.899s user 0m0.501s sys 0m0.118s $ time az vm resize -g hpc-awx -n hpc-awx --size Standard_B1s > /dev/null real 0m58.901s user 0m0.440s sys 0m0.129s

What is super funny for me in the listing above is that resize to previously configured size was also nearly one minute operation. It looks like az doesn’t check if the the size really changed. Thanks to azure-cli being a github project checking the code was no more than a few minutes – the function of interest is resize_vm, you can find it’s definition in custom.py [4] and it was more than simple:



[cinek]$time az vm resize -g test-awx -n test-awx --size Standard_B1s "VM is already Standard_B1s" real 0m1.736s user 0m0.351s sys 0m0.101s

It’s Microsoft, but open source… so let’s help them and fix this in pull request [5], so if it’s merged you’ll see:

[1] https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/

[2] https://docs.microsoft.com/en-us/azure/virtual-machines/linux/sizes

[3] https://azure.microsoft.com/pl-pl/blog/introducing-b-series-our-new-burstable-vm-size/

[4] https://github.com/Azure/azure-cli/blob/dev/src/command_modules/azure-cli-vm/azure/cli/command_modules/vm/custom.py

[5] https://github.com/Azure/azure-cli/pull/6049