Dynamics 365 Business Central/NAV on Azure VMs: tips for best network performances

Many months ago I wrote a series of posts related to best practices to remember when deploying Microsoft Dynamics NAV or Microsoft Dynamics 365 Business Central on-premise as IaaS with Azure. In particular:

• Best practices when installing SQL Server on an Azure VM
• Best practices when deploying NAV (or Dynamics 365 Business Central) on Azure VMs

I’ve received lots of feedbacks and interests related to these posts and many of you were so kind to share with me their experiences.

When talking about installing Dynamics NAV or Dynamics 365 Business Central (D365BC) on Azure, I’ve said in the past that the results from my experiences are the following:

• Option 1: NAV Service Tier and SQL Server on the same Azure VM
• Option 2: NAV Service Tier and SQL Server on separate Azure VMs

Use a single Azure VM when:

• Less than 20 concurrent users
• VM types: D(s) or F(s) series. Premium Storage is a must!
• Set SQL Server with RAM usage limit (50% SQL, 50% applications)
• If you’re using NAV Web Client, consider that it has a low CPU usage

Use multiple Azure VMs when:

• More than 20 concurrent users
• Create VM1 for SQL Server and VM2 for NAV Service Tier
• SQL VM: D(s) or F(s) series, with Premium storage
• DS2v2 is ok for starting with SQL Server Standard Edition, while DS3v2 is the starting point for SQL Server Enterprise Edition
• NAV/D365BC VM (service tier): E series
• Create the Azure VMs in the same region
• This tends to be the best architecture for scalability

The second choice (multiple Azure VMs) is the most interesting architecture and normally this is what I suggest for Microsoft Dynamics NAV/D365BC implementations with important loads. But when choosing this type of architecture, there’s an important aspect that I’ve forgot to mention before and that must be considered to optimize the infrastructure: network latency.

If you have an Azure VM1 for the service tier and another Azure VM2 for the database tier, you have a network latency on the communication between the two machines. Obviously, less latency you have and more performant will be your infrastructure and your network communication between database and service tier.

When deploying D365BC or NAV on Azure by separating database and service tiers on different machines, the worst thing you can do is simply automatically deploy the two machines without doing nothing more than this. Obviously, the “top of the worst” could be placing service tier and database tier on different Azure regions (for example one in Europe and one in USA), but I don’t think someone of you will be crazy to do this if not needed 🙂

The first thing you can do to improve your Azure VMs performances and decrease network latency is to place the VMs on the same Virtual Network (VNET). To do so, simply create a virtual network resource via the Azure Portal (Create a resource, select Networking and then Virtual Network), give it a name and assign this VNET to your VMs:

The second thing you can do to optimize network performances is to place the two VMs in the same Availability Set. Availability sets ensure that the VMs you deploy on Azure are distributed across multiple isolated hardware nodes in a cluster. Using the same Availability Set ensure that the two VMs are on the same hardware. You can create or assign an Availability Set by going to the Settings pane of your Azure VM:

If you want to “be extreme”, you can also create an Availability Set with a single fault domain. This is absolutely not a rule given by Microsoft but only by me (so feel free to avoid it) but virtual machines in the same fault domain share a common physical network switch and if you use this trick, latency is very very low. Obviously, if you want high availability these rules must be duplicated for every redundant configuration.

There’s another very new feature that it’s quite interesting expecially for Azure VMs with the Microsoft Dynamics ERP: Accelerated Networking.

Accelerated Networking is a feature that enables single root I/O virtualization to a VM, greatly improving its networking performance. This high-performance path bypasses the host from the datapath, reducing latency, jitter, and CPU utilization. The following picture (by Microsoft) shows the communication between two VMs with and without accelerated networking:

Unfortunately this feature is disabled by default when you create an Azure VM (and it’s only available with certain VM sizes with more than 2 vCPUs, but for sure it will be available in all VMs you will use with NAV/D365BC), but if you enable it on your Azure VMs (service tier and database tier) connected to the same VNET, you will have a gain in network performances. As said before, Accelerated Networking is disabled as default on your Azure VM:

To enable Accelerated Networking on existing Azure VMs, you have to stop your instances and then run the following Powershell script from Azure CLI:

$nic = Get-AzureRmNetworkInterface -ResourceGroupName "myResourceGroup" -Name "myNic" 

$nic.EnableAcceleratedNetworking = $true

Then restart your Azure VMs and you will see that Accelerated Networking is now enabled:

 

I think that Accelerated Networking is a very interesting and FREE feature that should be always enabled on your Azure VMs.

With these rules and tecniques, network performances of your Dynamics NAV/D365BC IaaS architecture will be improved for sure.

As usual, these are not rules written on the stone, but they only come from practical experiences on the field. I suggest you to try or remember these tips if you will deploy Dynamics 365 Business Central or Dynamics NAV on Azure cloud as IaaS by using Azure VMs, but always remember that on cloud the latency aspect is something that could be very variable.