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.

Lab Setup

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.

 

  • Each pair of VMs are associated to an Availability Set for an SLA.
  • This lab deployment is a simplified version of an N-tier architecture style common with critical applications running on Azure IaaS.
  • In production environments, you will likely see additional components such as NVAs, caching, and load balancing.
  • You can also deploy this with VMSS.

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.

  • Remember to update the CLI variables (e.g. subscriptionID and VM login username/password).
  • Create the VM dependencies first such as RG, PPG, AVset, VNETs, SA, NICs.
  • You need to use a VM SKU that is compatible with Accelerated Networking. You can mix and match VM SKUs in your deployment.
  • If you receive an allocation error OverconstrainedAllocationRequest when running your script try changing the sequence of VMs deployed (e.g. create larger SKUs first).

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

Testing latency

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.

 

Test Syntax VMs using PPG and Accelerated Networking VMs NOT using PPG and Accelerated Networking

RECEIVER

latte -a 10.0.1.10:80 -i 65000

 Protocol TCP
SendMethod Blocking		 Protocol TCP
SendMethod Blocking

SENDER

latte -c -a 10.0.1.10:80 -i 65000

 ReceiveMethod Blocking
SO_SNDBUF Default
SO_RCVBUF Default
MsgSize(byte) 4
Iterations 65000
Latency(usec) 88.80
CPU(%) 8.2
CtxSwitch/sec 22930 (2.04/iteration)
SysCall/sec 23549 (2.09/iteration)
Interrupt/sec 46473 (4.13/iteration)		 ReceiveMethod Blocking
SO_SNDBUF Default
SO_RCVBUF Default
MsgSize(byte) 4
Iterations 65000
Latency(usec) 774.51
CPU(%) 2.1
CtxSwitch/sec 3037 (2.35/iteration)
SysCall/sec 4774 (3.70/iteration)
Interrupt/sec 6597 (5.11/iteration)


Conclusion

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.

Cheers,

Jesse