Hello friends. In the previous Azure post, we learnt about Confidential computing with Azure Kubernetes which allows data security even during run-time. It’s a short and interesting read. Do check out that post in case you haven’t read it. In this post we will learn on how to reduce VM latency Azure Proximity Placement Groups.
This post is divided into 3 sections. First we will see all about Proximity Placement Groups (PPG). Then we will see a step-by-step guide for deploying VMs to proximity placement groups using Azure CLI. And lastly at the end, we will see how to Test VM network latency.
Why do we need Azure Proximity Placement Groups?
Usually when we deploy our applications in Azure, we might divide instances across various availability zones or regions also. But this increases network latency resulting in an impact on the overall performance of our apps. Now we have the option of placing our VMs inside a single availability zone which brings the VMs physically closer. But still as the Azure infrastructure increases, that single availability zone can well span over multiple data centers. This again can create a network latency impacting our apps.
To get VMs as close as possible, achieving the lowest possible latency is a key. Hence we need some kind of grouping which will ensure that Azure compute resources are physically located close to each other. This is what Azure Proximity Groups allow us to do.
What are Azure Proximity Placement Groups?
It is a grouping used so that the Azure compute resources are located close to each other physically. This is a kind of logical grouping. For workloads where we need low latency they are useful.
Points to consider before creating Azure Proximity Placement Groups
A proximity placement group is a resource type which is new in Azure. Hence we need to create it before we use it with other resources. After creating, it could be used with availability sets, virtual machines or virtual machine scale sets. We have to specify a proximity placement group ID when creating compute resources.
In case we have an existing resource, we can still move it into a proximity placement group. But before moving first it should be de-allocated i.e. stopped since it will be redeployed into a different data center in the region so that it fulfills the co-location entity. For virtual machine scale sets and availability sets we have to set the proximity placement group at the resource level and not at the individual VM level.
A proximity placement group is an entity associated with co-location. When a resource which uses a proximity placement group is first deployed, it is pinned to a specific data center. When all resources using this group have been deleted or de-allocated i.e. stopped, it is no longer pinned. Hence we have to first specify the types which are required in a template when using proximity placement groups with multi-VM series. We have to do this so that our chances increase for a successful deployment. If our deployment is not successful, we have to start the deployment again with the first VM size which failed as the first one to be deployed.
Features of Azure Proximity Placement Groups
- After the general availability, proximity placement groups (PPG) are available in all Azure public cloud regions but for some reason it has excluded the Indian Central region.
- PPG has support in the Azure portal. We can use them when creating our IaaS infrastructure.
- Movement of existing resources to and from PPGs.
- One common use cases scenario for PPG is mission-critical applications such as SAP. There is support for SAP on Azure Virtual Machines as well as SAP HANA Large instances.
- In case we need to test the latency in Azure, there is support on how to test VM network latency.
- Using PPG is useful even in case of single tier apps deployed in a single availability set.
- While deploying a PPG with multi-family VMs and SKUs, target to deploy them all with a single template. This increases the chances VMs getting successfully deployed.
- You can reduce the chances of allocation failures by sorting with your VM of biggest size then storage.
- If you are targeting low latency, use PPG along with accelerated networking. This enables single root I/O virtualization to a VM which greatly improves its network performance.
- Make sure you wait for the deletion to complete fully when reusing an existing PPG from which VMs were deleted.
- You can use a PPG alongside availability zone. It cannot span zones. Use this combo in a case of an standby deployment which is active where each of them is in a separate zone.
- While using SDK, Power Shell or the CLI, if you get an allocation error ‘Over constrained Allocation Request’, you should de-allocate/stop all the existing VMs, and change the sequence in the deployment steps to begin with the VM sizes/SKU that are failing.
Step-by-step guide for deploying VMs to proximity placement groups using the Azure CLI
Creating a proximity placement group by using the az ppg create command.
az group create --name testPPGGroup --location westus az ppg create \ -n testPPG \ -g testPPGGroup \ -l westus \ -t standard
Listing all proximity placement groups using the az ppg list command
az ppg list –o table
Creating a VM in the proximity placement group using the new az vm command
az vm create \ -n testVM \ -g testPPGGroup \ --image UbuntuLTS \ --ppg testPPG \ --generate-ssh-keys \ --size Standard_D1_v2 \ -l westus
Viewing the VM in the proximity placement group using the az ppg show command
az ppg show --name testppg --resource-group testppggroup –query "virtualMachines"
Other useful commands
Note that you can use the same –ppg parameter with the az vm availability-set create – Create an availability set and all VMs in the same proximity placement group.
Creating an availability set
az vm availability-set create -n testAvSet -g testResourceGroup --platform-fault-domain-count 2 --platform-update-domain-count 2
Creating a Windows VM scale set with load balancer, public IP address, 2 instances and a data disk of 1GB capacity
az vmss create -n testVmss -g testResourceGroup --instance-count 2 --image Win2016Datacenter --data-disk-sizes-gb 1
Now since we have done all this to improve the network latency, it’s time that we should know how to test the network latency. Below guide will help you.
NOTE: We will be running the latency test only on Windows based system for this tutorial.
Test VM network latency
For a proper and accurate network latency testing of applications we can use latte.exe for Windows and SockPerf for Linux.
We can use two VMs, one as sender and one as receiver to measure network latency to establish a benchmark for network latency between the deployed VMs.
To measure latency, you have two different tool options:
- Windows systems: latte.exe
- Linux systems: SockPerf
Create your VM configuration as per below guidelines
- Use the latest version of Windows or Linux.
- Enable Accelerated Networking for best results.
- Deploy VMs with an Azure proximity placement group.
- Larger VMs generally perform better than smaller VMs.
Analyze test results as per below guidelines
- Try to establish a baseline sooner as deployment and configuration are done.
- Compare results to a baseline.
Windows based testing
- Download latest version of latte.exe.
- Keep the exe in a separate folder for e.g. c:\testtools.
- For the receiver, create an Allow rule in Windows Defender Firewall to allow the latte.exe traffic to arrive.
- Allow latte.exe through Windows Defender Firewall by running the following command:
netsh advfirewall firewall add rule program=<path>\latte.exe name="Latte" protocol=any dir=in action=allow enable=yes profile=ANY
If you copied latte.exe to the c:\testtools folder, the command would be something like below:
netsh advfirewall firewall add rule program=c:\testtools\latte.exe name="Latte" protocol=any dir=in action=allow enable=yes profile=ANY
Run latency tests
On the receiver, start latte.exe from CMD window and not from PS
latte -a <Receiver IP address>:<port> -i <iterations>
Above 60,000 loops can be targeted to return constructive results. Any available port number is fine. If the VM has an IP address of 10.0.0.2, the command would look like below:
latte -a 10.0.0.2:5005 -i 65300
On the sender, start latte.exe from CMD window and not from PS
latte -c -a <Receiver IP address>:<port> -i <iterations>
Except the -c to indicate that this is the client, or sender the command as same as earlier
latte -c -a 10.0.0.2:5005 -i 65300
The test could take some time to finish depending on how further the VMs are. You can try to start with fewer loops before running longer tests.
In this post on Azure Proximity Placement Groups we saw how they are a useful tool for reducing network latency. This feature is now generally available as of Dec 2019 but was announced as a preview earlier on July 2019. If you have any views please then you can add your comments below. Do share this post to your friends as well so that we keep learning together.