In today’s world where we measure application’s success or failure depending on the time it took to respond and probably fetch the data we requested. In case of multi-tier application your servers would be communicating with each other and making required requests.

This used to be fairly straightforward and simple during datacenter days where we could host our servers in same datacenter and mitigate latency issue as much as possible. But when it comes to cloud, we don’t have a control on the proximity of the servers which are part of the same application.

I’m sure you would have thought we can host the servers in same region and availability zone to ensure low latency. Placing VMs in a single region reduces the physical distance between the instances. Placing them within a single availability zone will also bring them physically closer together. However, as the Azure footprint grows, a single availability zone may span multiple physical data centers, which may result in a network latency impacting your application. To get VMs as close as possible, achieving the lowest possible latency, you should deploy them within a proximity placement group.

Table of contents

So, what’s Proximity placement group exactly?

A proximity placement group is a logical grouping used to make sure that Azure compute resources are physically located close to each other. Proximity placement groups (PPG) are useful for workloads where low latency is a requirement. A PPG is a colocation constraint rather than a pinning mechanism. It is pinned to a specific data center with the deployment of the first resource to use it. Once all resources using the PPG have been stopped (deallocated) or deleted, it is no longer pinned. Therefore, when using a proximity placement group with multiple VM series, it is important to specify all the required types upfront in a template when possible or follow a deployment sequence which will improve your chances for a successful deployment. If your deployment fails, restart the deployment with the VM size which has failed as the first size to be deployed.

A proximity placement group is a resource in Azure that can be used with virtual machines, availability sets, or virtual machine scale sets. You specify a PPG when creating compute resources providing the PPG ID.

You can also move an existing resource into a PPG. When moving a resource into a PPG, you should stop (deallocate) the asset first since it will be redeployed potentially into a different data center in the region to satisfy the colocation constraint.

In the case of availability sets and virtual machine scale sets, you should set the PPG at the resource level rather than the individual virtual machines.

Use case scenarios and best practices:

As mentioned earlier PPG is best suited for the scenarios where low latency is a requirement. These are few use cases where this can be used:

  • Low latency between stand-alone VMs.
  • Low Latency between VMs in a single availability set or a virtual machine scale set.
  • Low latency between stand-alone VMs, VMs in multiple Availability Sets, or multiple scale sets. You can have multiple compute resources in a single placement group to bring together a multi-tiered application.
  • Low latency between multiple application tiers using different hardware types. For example, running the backend using M-series in an availability set and the front end on a D-series instance, in a scale set, in a single proximity placement group.

To ensure you are making best use of PPG you should try and follow below best practices:

  • For the lowest latency, use proximity placement groups together with accelerated networking.
  • Deploy all VM sizes in a single template. In order to avoid landing on hardware that doesn’t support all the VM SKUs and sizes you require, include all of the application tiers in a single template so that they will all be deployed at the same time.
  • If you are scripting your deployment using PowerShell, CLI or the SDK, you may get an allocation error OverconstrainedAllocationRequest. In this case, you should stop/deallocate all the existing VMs, and change the sequence in the deployment script to begin with the VM SKU/sizes that failed.
  • When reusing an existing placement group from which VMs were deleted, wait for the deletion to fully complete before adding VMs to it.
  • If latency is your first priority, put VMs in a proximity placement group and the entire solution in an availability zone. But, if resiliency is your top priority, spread your instances across multiple availability zones (a single proximity placement group cannot span zones).

Planned maintenance and alignment status on PPG

Planned maintenance events, like hardware decommissioning at an Azure datacenter, could potentially affect the alignment of resources in proximity placement groups. Resources may be moved to a different data center, disrupting the collocation and latency expectations associated with the proximity placement group.

Check the alignment status

You can do the following to check the alignment status of your proximity placement groups.

  • Proximity placement group colocation status can be viewed using the portal, CLI, and PowerShell.
    • When using PowerShell, colocation status can be obtained using Get-AzProximityPlacementGroup cmdlet by including the optional parameter ‘-ColocationStatus`.
    • When using CLI, colocation status can be obtained using az ppg show by including the optional parameter ‘–include-colocation-status`.
  • For each proximity placement group, a colocation status property provides the current alignment status summary of the grouped resources.
    • Aligned: Resource is within the same latency envelop of the proximity placement group.
    • Unknown: at least one of the VM resources are deallocated. Once starting them back successfully, the status should go back to Aligned.
    • Not aligned: at least one VM resource is not aligned with the proximity placement group. The specific resources which are not aligned will also be called out separately in the membership section
  • For Availability Sets, you can see information about alignment of individual VMs in the the Availability Set Overview page.
  • For scale sets, information about alignment of individual instances can be seen in the Instances tab of the Overview page for the scale set.

Re-align resources

If a proximity placement group is Not Aligned, you can stop\deallocate and then restart the affected resources. If the VM is in an availability set or a scale set, all VMs in the availability set or scale set must be stopped\deallocated first before restarting them.

If there is an allocation failure due to deployment constraints, you may have to stop\deallocate all resources in the affected proximity placement group (including the aligned resources) first and then restart them to restore alignment.

Advertisement