This article examines two of the biggest considerations when upgrading to the on-premises version of Dynamics 365 for Finance and Operations -- storage and sizing.
Originally published in H1 2018 D365UG/AXUG Magazine
If you’ve ever worked in an organization that has an ERP system implemented, there are generally two things that will keep you up at night. First: I hope the infrastructure I’ve built the system on is stable, and second: How am I going to keep it current?
The first question is easy to answer: Get your credit card out and buy top-line equipment. The second one is not always so easy. And Microsoft has given Microsoft Dynamics AX Users a third thing to worry about: Do I stay with Microsoft Dynamics AX 2012 R2/R3 path or upgrade to Microsoft Dynamics 365 for Finance and Operations. I can’t tell you how many nights of sleep I’ve lost over this question. When Microsoft released Dynamics 365 as “AX 7”, I was lucky enough to get a first glance at the new and improved flagship ERP solution. It was still rough around the edges, but even at that point you could see Microsoft had put a great deal of thought as well as client recommendations into this new version. By making it a cloud offering by the Azure cloud space, Microsoft was looking to the future to bring in existing Customers and entice a bunch of new ones.
I’ve been a Microsoft Certified Trainer for 20 years. I’m also a solutions architect with several years of experience with the Microsoft Dynamics AX products. I was given an opportunity by Microsoft Canada to create a one-day, all-you-can-find-out event about Microsoft Dynamics AX 7. It ran in several Canadian cities, and I believe it was well-received (if the course evaluations are any indication). I met probably 100 people from all sorts of organizations, and at just about every session, the first question I was asked was, “When is Microsoft going to release an on-premises version of D365?” The only response I could provide was, “I promise it’s coming!” Luckily, last September, Microsoft didn’t make a liar out of me. With the September 2017 update of Microsoft Lifecycle Services (LCS), the on-premises installation of D365 became available.
In the remainder of this article, I’ll discuss two areas that you should know before you take the leap into your upgrade/migration to D365 on-premises: Storage and sizing.
A Bit of Background on the Platform
As you probably already know, D365 is based on Microsoft Dynamics AX 2012 R3 CU9. You probably also know that Microsoft has made major changes to the User interface (web-based versus desktop client), and that they have changed some major features to allow for it to function well in the Azure service bus. While those are important items to discuss, it is not really necessary to talk about them here. What I want to explain is the best way to make D365 on-premises work in your organization.
Storage
Have you ever worked in an organization that had a slow and aging storage area network (SAN)? If so, you know how painful it can be to use older technologies. As storage will be your single biggest pain point for your on-premises installation, I highly recommend using solid state storage. The current installation that I manage at Edmonton International Airport had to have a SAN upgrade to keep up with the storage requirements. Its databases were originally installed to a traditional platter drive-based system, which supported a low amount of input/output operations per second (IOPS). After the system was in place, we noticed it started to get slower and slower. After looking at the total number of IOPS that Microsoft Dynamics AX was using via SQL, we noticed that it was well over 10,000 IOPS. We decided to implement a solid state, drive-based SAN that had the ability to take 15,000 IOPS. Believe me when I tell you it was like night and day.
D365 is also a high-usage system, specifically on the SQL Server instances. When implementing your storage, you should keep the following in mind:
- For AOS installations – The on-premises installation will require the use of Server Message Block 3.0 shares to store all unstructured data.
- SQL IOPS – At a minimum, storage for your SQL Server should have at least 2,000 IOPS. In your production environment, IOPS can be hard to calculate. I’ll tackle that subject in the next section.
- VM IOPS – We also need to include the total available IOPS for each VM. For your installation, you should have a minimum of 100 IOPS per VM.
Sizing
The next area that will give you lots to think about is how to size your deployment.
This might scare you a little, but there is no absolute, foolproof way to get your sizing right…at the beginning. If you’re already using Microsoft Dynamics AX 2012, then you will have a good idea of the number and type of transactions that occur daily.
The six things that will impact your sizing are:
- The types of transactions: These generally have peaks and valleys, so understanding when and type of transactions is important.
- Concurrent Users: Knowing the total number of current Users is also vital. This one item can make or break the performance of your implementation. A concurrent User can be best described as someone who is logged on, working in the system, and most importantly, not in an idle session.
- Data composition: The complexity of your data has an impact on your infrastructure. As an example, if you are using a large amount of BOM data with many different levels, those transactions will have a greater system impact than someone who is filling out a purchase requisition.
- Extensions: Or better put “CUSTOMIZATION”. Customization can be the downfall of your deployment. Try as much as possible to keep customizations to a minimum, but if you must have them, the less complex, the better.
- Reporting: Every organization’s biggest stumbling block. Reporting always seems to hit the back burner until someone needs the reports. Reports that generate a large amount of data can be a drag on your implementation. Try to keep reports small, or if it will generate large data sets, run at a minimum.
- Third-party solutions: Too many can slow the system down.
Generally, in terms of sizing, your compute tiers should scale out to be N + 1. If you decide that you want four AOS servers, add in a fifth. And most important, on the SQL Server side, you will need to set up an always-on high availability cluster for constant data access.
That’s it for now. These were just two of the many items that you need to keep in mind during your planning, but hopefully these will give you a good start to your on-premises deployment.