Reducing network latency for critical apps running on Azure IaaS has become easier since Microsoft’s announcement of General Availability for Proximity Placement Groups (PPG) on Dec 2019.
Today I’ll give you a quick intro to Proximity Placement Groups demonstrating how to deploy a test environment into your Azure Subscription using one of my favourite tools AzureCLI. I’ll also test network latency with a PPG and without to show you the difference.
If you’re undecided about using AzureCLI or ARM templates for your Azure deployments have a look @ Pascal Naber’s post https://pascalnaber.wordpress.com/2018/11/11/stop-using-arm-templates-use-the-azure-cli-instead/
Prior to proximity groups being available the main solution to reduce VM-to-VM network latency was to use Accelerated Networking aka Single Root IO Virtualisation. However, simply using Accelerated Networking does not guarantee that VMs are deployed into the same data centre. This means added latency to traffic if VM 1 was in a separate data centre to VM 2 depending on the distance and network infrastructure traversed.
As per Microsoft’s best practice recommendation to achieve the lowest latency in my Azure subscription I deployed 4x Windows VMs (Standard_D3_v2) with Accelerated Networking into a single VNET with Frontend and Backend subnets.
Without using a proximity placement group for the availability sets my lab VMs could be automatically deployed to separate Azure region data centres depending on Microsoft’s physical resource availability at the time. Here’s a diagram which illustrates this.
MY DEMO LAB WITHOUT A PROXIMITY PLACEMENT GROUP
So in order to guarantee that my lab VMs are co-located in the same data centre, I’m going to associate the availability sets to a single proximity placement group as shown in the following diagram.
- With the VM NICs also set to use Accelerated Networking this ensures that traffic between VMs is optimised for minimal network latency.
MY DEMO LAB WITH A PROXIMITY PLACEMENT GROUP AND ACCELERATED NETWORKING NICS
Deploying Proximity Placement Groups with AzureCLI
The complete AzureCLI script I used is below and ready to go for a demo deployment in your own subscription. You can use VS Code and the AzureCLI extension for easy editing/deployment.
If you’re not a fan of scripting and prefer the GUI method check out the doco here https://docs.microsoft.com/en-us/azure/virtual-machines/windows/proximity-placement-groups-portal
The entire deployment of my lab took less than 6 minutes which was awesome as I needed to rapidly tear down and recreate the lab multiple times in Azure for this blog.
When you’re finished simply delete the Resource Group with this .azcli cmd to clean up and save on costs:
az group delete --name AE-PPGdemo-RG
Using Microsoft’s tool Latte to test TCP traffic between my VMs produced some interesting results. As you can see below when testing my lab VMs that were using PPG and Accelerated Networking I achieved 88.80 usec or 0.09 ms of latency between servers. Compared to 774.51 usec or 0.77 ms of latency when NOT using Microsoft’s recommended solutions.
|VMs using PPG and Accelerated Networking
|VMs NOT using PPG and Accelerated Networking
latte -a 10.0.1.10:80 -i 65000
latte -c -a 10.0.1.10:80 -i 65000
CtxSwitch/sec 22930 (2.04/iteration)
SysCall/sec 23549 (2.09/iteration)
Interrupt/sec 46473 (4.13/iteration)
CtxSwitch/sec 3037 (2.35/iteration)
SysCall/sec 4774 (3.70/iteration)
Interrupt/sec 6597 (5.11/iteration)
Azure Proximity Placement Groups (co-location) are a nice inclusion from Microsoft and provides Azure IT Pros with another solution to further reduce network latency by grouping IaaS VMs in the same Azure data centre. When used along with Accelerated Networking NICs there is a noticeable improvement as shown in my test above.
Consultants and Architects should weigh the pros and cons of using PPGs against Microsoft’s similar co-location solutions such as Azure Dedicated Hosts.