Before a bigger VM, check the network path

When an application tier on Azure virtual machines feels slow talking to its database, the reflex is a bigger VM. More cores and more memory are easy to buy, and sometimes they are the answer. Before reaching for them, look at the path the packets take between the two machines, because that path has two possible shapes and only one of them goes through software on the host.

Two paths through the same host

Without Accelerated Networking, all traffic in and out of a VM passes through the host and its virtual switch. The virtual switch is where policy is enforced: network security groups, access control lists, isolation and the other virtualized network services.

With Accelerated Networking, Azure uses single root I/O virtualization (SR-IOV) to give the VM a virtual function on the physical network card. The card applies the same policies in hardware and forwards traffic straight to the VM, bypassing the host and its virtual switch. The policies are not dropped; they move from software to the card.

What it can change, and what it cannot

Microsoft lists three benefits, all of them about processing network traffic:

• Lower latency and more packets per second, because packets no longer wait in the host for policy processing.
• Less jitter, because the variable cost of software switching is taken out of the path.
• Less CPU spent on network traffic, because the host's virtual switch is no longer doing that work.

Those are improvements to the network path, not to the application. A slow query stays slow and a chatty application stays chatty. The benefit applies only to a VM that has the feature enabled; Microsoft recommends enabling it on at least two VMs in the same virtual network, and notes it has minimal effect on traffic across virtual networks or to on-premises. How much it helps depends on the workload, and nobody can promise a number in advance.

The check before you resize

• Size: most general-purpose and compute-optimized sizes with two or more vCPUs support it, or four or more on sizes with hyperthreading. Confirm the exact size against Microsoft's size documentation; the Azure CLI's list of VM SKUs reports the AcceleratedNetworkingEnabled capability.
• Image and drivers: the operating system image must be a supported one, and the guest needs current network drivers. Azure does not update the Mellanox or MANA drivers inside the VM; keeping the kernel or drivers current is the VM owner's job.
• Configuration: on the VM's network interface, the Essentials section shows whether Accelerated networking is Enabled or Disabled.
• Runtime: configuration alone does not prove the path. Use Microsoft's verification steps for the card in use to confirm that traffic is actually flowing over the virtual function, or through MANA, inside the guest.

Before you change an existing VM

Accelerated Networking cannot be switched on while a VM is running. The VM has to be stopped and deallocated first, and in an availability set every VM in the set. That is a maintenance window, so it belongs in a plan rather than an afternoon.

Applications must bind to the VM's synthetic network interface, not to the virtual function directly. The virtual function can be revoked during host maintenance or live migration and restored afterwards; an application bound correctly keeps running over the synthetic path in the meantime. A brief fall back to that path is expected behaviour, not a fault.

In the film the database is SQL Server running on a VM, so it has a network interface of its own to check. A platform-managed database service is a different arrangement, and this check does not apply to it in the same way.