Microsoft Dynamics NAV 2017 Architecture

An entire book could be written, and likely has, on the Microsoft Dynamics NAV 2017 architecture and how to design the on premise infrastructure to host it. To help you get the most out of this software, and to understand the foundation on which it has been built, this blog provides a summarized version of Dynamics NAV 2017’s complex architecture.

Three-Tier System

Microsoft Dynamics NAV 2017 is a three-tier (or three-layer) architecture system. It consists of:

• presentation tier
• logic or business processing tier
• database management system tier

The presentation tier consists of the NAV Windows Client (formerly RTC), the NAV Web Client, the NAV Tablet/Phone Client (Universal App), and the NAV Development Environment. The business logic-processing tier is where the NAV code is executed and is called the NAV Service Tier or NST for short. The database management system tier is SQL Server.

In the older two-tier (2009 and older) architecture, the Classic Client performed all the business logic processing. It was considered a fat client; it had to be located on the same LAN segment as the database server. The new presentation tier is a thin collection of clients. The one slight exception is the NAV Development Environment that is exclusively used to develop NAV code. The rest of the user interface clients, because of being thin, can be deployed in a variety of dispersed environments, from LAN to WAN to over the Internet. The NAV Windows Client for Dynamics NAV 2017 now comes in a 64-bit version, which enhances performance and supports larger report datasets than the limited 32-bit client from NAV 2013 to 2015.

The business logic-processing tier is a service that runs on a server and links or sits in the middle between the client and the database. There is so much that can be said about the capabilities of the NST service, but the primary take away for this discussion is that the service is 64-bit and multi-threaded, meaning it uses more than one processing core to process. Its job is to execute the NAV code as requested by the client, translating the code into SQL queries, processing the data, and passing the resulting information back to the client.

Many have the misconception that most of the work being done in a NAV environment is on the SQL Server. While SQL server does do a lot of work, the real work to take data and turn it into information is done on the NST. The queries that are generated in the translation of NAV code to TSql are simple. They are reads, writes, edits and deletes. No complicated table joins, table triggers or stored procedures to execute. This means SQL Server uses relatively little CPU cycles compared to the NST. The SQL Server does use a lot of RAM and needs very fast disks particularly for reading.

Best Way to Configure Dynamics NAV 2017

You might be thinking, “Brian, we know about the three-tier architecture since back in NAV 2009 sp1. But how do we size the hardware and what is the best way to configure NAV 2017?” That is a great question and really the point of this blog post. Microsoft has not released performance-testing results since they came out with NAV 2013 R2, but fortunately, the architecture has not changed since then with the slight exception of the 64-bit Windows Client. In the Microsoft white paper, Microsoft Dynamics NAV 2013 R2 Sizing Guidelines for On-Premises Single Tenant Deployments, we see in their conclusions that 500 concurrent users completed 90% of their tasks with acceptable response time.

The amount of RAM used broke down to 5MB per user plus 500MB for overhead. What the paper also suggests is that four CPU cores is the optimum number to handle 500 concurrent users, or approximately 150 users per core. What they found was that beyond 500 users even adding more RAM did not improve performance. Therefore, to handle more users requires scaling out to multiple servers instead of scaling up the hardware. While it is great that the results show a potential for 500 concurrent users performing transactions on a single service, it is important to keep in mind these were done on a small base NAV CRONUS database and simple transactions. In the real world with customization and ISV add-ons, the number is more like 200-250 concurrent users.

SQL Server

SQL Server hosting a Dynamics NAV 2017 database is a light consumer of CPU cycles but a heavy consumer of RAM and dependent on very fast disks. SQL Server is designed to cache as many previously queried datasets into RAM as it can in case those queries are executed again. SQL Server will cache the entire database given time and enough RAM, and this is a good thing. Therefore, a good rule of thumb is you should have more RAM on your SQL Server than the size of your database (plus 2-4GB for the OS). This rule starts to break down with databases larger than 128GB due to restrictions set on the Standard Edition of SQL Server. If your database is larger than 200GB and you have more than 100 users, seriously consider the Enterprise Edition and stick to the rule. Fast disks are solid state or 15k RPM SAS drives in RAID10 arrays on local controllers. There are a glut of best practice SQL disk setup guides, so I am not going to dive deep here. Suffice it to say, NAV is a lot like any other OLTP database with about a 75% read to 25% write ratio, so dedicate a disk array for the data files and another for the transaction log file(s). All other databases and administrative files should be on a third array.

NST Server

The NST server is where the real magic happens; this is where the NAV code is executed. The most important thing I can say about designing this server is use the fastest CPUs possible. I am talking GHz frequency; 2.8GHz is the bottom number. I recommend 3.1GHz and higher for my clients. Newer CPUs that have bursting technology might idle at 2.0 to 2.4GHz, but are capable of spiking up beyond 3.0GHz. For environments of 25-50 people, two CPU cores is all that is needed. Widen the freeway with more cores if you have more users, but make sure the ride is fast with those higher frequency cores. The NST service is 64-bit and can consume higher amounts of RAM. However, the really busy services that I run into rarely use more than 4GB at a time and unlike SQL server will throttle back down when not in use. The NST service is multi-functional or has multiple end-points. It serves four unique functions, client connections, two flavors of web services (SOAP & OData), and the headless client known as NAS. I recommend to my clients that if they are going to deploy more than the client connection function, that they deploy dedicated services for each and disable the functions not used in each service. Theoretically, a fully deployed NST would have four NST services each with a dedicated Active Directory user Service Account. In that case, I would recommend 14GB of RAM for the server. Four for the OS, four for the client connection NST, two each for the SOAP, OData, and NAS services. (Stay tuned for a future posting on best practice NST settings.)

Client Computers

As for the client computers, any Windows 8.1 or 10 computer with at least 2GB of RAM can host the NAV Windows Client. Microsoft does not officially support Dynamics NAV 2017 on Window 7 (don’t tell anybody, but it runs just fine on Windows 7 Professional 64-bit or higher with Service Pack 1). The NAV Web Client can be accessed from just about any HTML browser. The NAV Universal App can be installed on Android, iOS or Windows devices, but on 4” or more for phones and 7” or more for tablets. The NAV Universal App consumes the secured (https) NAV Web Client site inside or outside the on premise network. There are a couple of ways to deploy the NAV Windows client easily with unattended installation or using Microsoft’s ClickOnce .NET application deployment tool the details for each easily accessible on MSDN.

The Dynamics NAV 2017 three-tier architecture is more complicated than in previous versions. Do not fret though; it just takes a little planning and a little help from your friendly neighborhood Dynamics NAV partner to put together the best possible system for your on premise deployment.