This article explains the process to change the Azure virtual machine to a different VM size for an Azure virtual Socket (vSocket).
There are different situations where it may be necessary to change the Azure vSocket VM to a different size. The resizing process is managed in your Azure tenant, and resizing the VM doesn't impact the vSocket or site settings. There's no need to make changes in the Cato Management Application or the Socket WebUI.
Depending on the Azure vSocket version and configuration, there will be some down-time for the site.
Before resizing your vSocket VM, it's important to confirm that the allocated quota in the respective region permits an increase in the number of vCPU Cores. Azure sets a quota on the maximum number of VM vCPUs allowable per region. When adjusting the size of a VM and the new VM size has more vCPUs, you need to verify that you won't exceed the vCPU quota for that region. For example, an Azure HA site has 2 Standard_D2s_v4 vSocket VMs and each one uses 2 vCPUs, and you are resizing them to the Standard_D8ls_v5 VM which uses 8 vCPUs. The resizing requires an additional 12 vCPUs (6 for each vSocket), and you need to verify that adding 12 vCPUs to the region doesn't exceed the Azure vCPU quota.
If necessary, submit a request to Microsoft to increase the vCPU quota for the relevant regions. When the vCPU quota is exceeded, the VM doesn't deploy to the new size.
For more information, see the relevant Microsoft documentation: View quotas and Check vCPU quotas.
This section discusses resizing the vSocket VM for an HA (high availability) site and for a site with a single vSocket.
For HA sites running vSocket version v19 or higher, confirm whether the VMs were deployed in an Availability Set from the Virtual Machine's Overview Page. Follow the sections below accordingly:
It's important that you also confirm that the HA failover will work during this procedure. Go to the WebUI's Network Tools section and run the API Test Tool.
- If the test fails, follow the troubleshooting steps mentioned in Troubleshooting Azure HA vSocket
- If the API Test is successful, proceed to follow the steps described in next sections.
Note
Note: During the resize operation, if the Socket WebUI API Test Tool on the Secondary vSocket returns the following message:
Azure API Test state 'Retrieve NIC configuration for current socket' failed! Azure API BLOCK state 'Unblock ALL AZ API'
If the test succeeds on the Primary vSocket, then this message is a mistake and you can safely ignore this specific result and continue with the resizing procedure below.
HA vSockets WITHOUT Availability Set
If the vSockets are NOT deployed in an Availability Set, follow the steps below to resize each VM individually: Change the size of a virtual machine. There should be no downtime during the process.
- Resize the Primary vSocket. The vSocket reboots as part of the resizing process and the site automatically fails over to the Secondary vSocket.
- After the resizing process is complete and the Primary vSocket is running, the site automatically falls back to the Primary vSocket.
- Resize the Secondary vSocket. The vSocket reboots as part of the resizing process.
- Finally, test HA failover by power cycling the Primary VM to confirm that HA is working for the vSockets.
HA vSockets WITH Availability Set
Note
Note: Please contact Microsoft for assistance resizing a Standard_D2s_v4 VM with 3 NICs in an Availability Set. We have seen that the steps below successfully resize HA vSockets with Availability Sets.
If the vSockets are deployed in an Availability Set, follow the steps below to resize each VM individually: Change the size of a virtual machine. There will be some downtime during the process.
-
Attempt to resize the Secondary vSocket. The resize operation will fail with an error reporting that the Primary vSocket exceeded the NIC limit.
-
Resize the Primary vSocket which will succeed. This will cause both vSockets to reboot and the tunnels to reconnect.
-
Both vSockets will come online, but it's possible that the LAN traffic will fail to route due to resizing. The API call to assign the floating IP on the Primary vSocket may initially fail.
-
If you have routing issues, shut down the Secondary vSocket which should restore connectivity through the Primary vSocket.
-
Start the Secondary vSocket. Traffic may stop communication for about 2 minutes while the vSocket boots up.
For HA sites running vSocket versions lower than v19, we recommend that you deploy new VMs for the Primary (active) and Secondary (stand-by) vSocket. See Unregistering and Redeploying Azure vSockets. The vSocket deploys to the new VM size with v19.x.
If it is necessary to keep the same version, please contact Support to manually recreate the site.
For sites with a single Azure vSocket v19.x or higher, the VM reboots as part of the resizing process and there is some down-time for the site.
Refer to the Microsoft documentation for details on how to resize the VM: Change the size of a virtual machine.
For single vSocket sites running vSocket versions lower than v19, we recommend that you use the the Azure Marketplace to deploy new VMs. The vSocket deploys to the new VM size with v19.x. See Deploying Azure vSockets from the Marketplace.
If it is necessary to keep the same version, please contact Support to manually recreate the site.
To verify that the vSocket is functioning correctly after resizing the VM, use the Cato Management Application to log in to the Socket WebUI for the vSocket.
To log in to the Socket WebUI and verify the resized vSocket:
-
From the Monitoring > Topology page, select the site and in the Site Sockets section, click Socket WebUI for the Primary vSocket.
The browser opens a new tab and logs in to the Socket WebUI.
When the vSocket is functioning correctly, the Socket WebUI displays the Monitor tab and the active links have green Link Status icons.
-
For HA configurations, repeat the step above for the Secondary vSocket.
8 comments
Updated content based on new information and procedures
Regarding Step 1 : This suggestion raises the costs per Azure vSocket with 3 years VM reservation at around +420% (MCA pricing). That's huge.
Better to go with a F8s_v2 (+350%, still a lot - but better).
Or are there any reasons not to?
We receive the following error when trying to stop the VMs:
Failed to stop the virtual machine 'VmNameHere'. Error: The number of network interfaces for virtual machine VmNameHere exceeds the maximum allowed for the virtual machine size Standard_D2s_v4. The number of network interfaces is 3 and the maximum allowed is 2.
Linard Moll Currently Cato officially supports the Standard_D8ls_v5 VM size. We are researching and testing other options, and will update this article when we have more information.
Brian Ciarimboli Please open a ticket with Support. Thanks!
Could you provide clearer guidance on which VM size we should select for resizing? The initial message mentions, "As an example, an Azure HA site utilizes 2 Standard_D2s_v4 vSocket VMs, each equipped with 2 vCPUs, and suggests resizing to the Standard_D8ls_v5 VM that offers 8 vCPUs." I realize I might be focusing too much on details.
However, one of the comments recommended trying the F8s_v2, yet Yaakov above says Cato officially supports only the Standard_D8ls_v5. If that's the case, could you explicitly confirm it? This would help avoid any confusion on my part. Thank you.
Benjamin barellano Cato certified and officially supports the Standard_D8ls_v5 VM size. We do not certify other VM sizes.
I have an 2 vsockets running in HA in Azure. I've read the steps for the HA upgrade and I understand that the steps mentioned to do a resize of the VM while it is powered on. The primary will restart and the backup socket should take over.
However, I would like to properly failover to secondary before resizing the primary. So is it possible to power off/shutdown the primary socket first which then forces the secondary socket to take over the virtual IP. Then do the resize of the primary, once resize was successful, power back up the primary which should then force it to failover the VIP services to the primary socket. Then lastly upgrade the backup socket. That seems to be a more controlled upgrade versus just resizing the primary while it was still holding on to the primary role in HA.
Latest update: Standard_D2s_v5 / 2vCores VM officially supported as 2-NIC solution
Link: https://support.catonetworks.com/hc/en-us/articles/20558411383325-Migrating-Azure-vSockets-to-a-2-NIC-Solution
Please sign in to leave a comment.