The following are a few industry best practices and recommendations for Dynamics AX infrastructure planning.
- Once you have the infrastructure design in place, you need to ensure that you have a plan to deliver the environments as per other milestones.
- There could be a long lead time in getting the budget approvals, the procurement process including lead time from Vendor, OS installation, and so on.
- Add tasks for infrastructure deliverables to the overall plan and have the lead time defined for the infrastructure team to deliver those tasks for your project.
Most of the performance issues arise from bottlenecks on SQL:
- Utilize the latest supported SQL Server version for Dynamics AX databases to utilize the latest SQL Server features.
- The Dynamics AX database has intense storage requirements and it should not be mistaken for any other OLTP database. Utilize the Microsoft recommendations on storage planning and configuration. The following blogs at Microsoft contain useful information on this topic:
Blogs links
Details
This is a Microsoft TechNet article on SQL Server Storage Settings.
Microsoft Dynamics AX performance team: This contains several blogs on storage setting best practices and recommendations
Microsoft Dynamics AX support team: This contains several blog topics on infrastructure estimation and hardware sizing.
- Dynamics AX 2012 extensively uses
TempDBand in-memory processing of data for performance optimization. In SQL Server 2012,TempDBis supported on the local drive which gives you an opportunity to store theTempDBfiles on Solid State Drives (SSDs). This can improve the performance for I/O access toTempDBand avoid any contention. - Plan for high availability by using failover solution on the SQL Server instance for the recovery strategy. SQL Server 2012 supports the Always on availability group feature to synchronize the primary instance to up to four secondary replicas.
- Plan for future expansion. For example, leave room for expansion in case you have to add more RAM or CPUs at a later stage.
- Plan the AOS servers for different purposes and redundancy. Use Windows Load Balancer or the Dynamics AX built-in load balancer functionality and create a cluster for user AOS, integrations, and batch processes.
- Try to minimize the number of AOS servers by having additional resources on the servers.
Tip
Instead of having six AOS servers for users, I would get away with two powerful ones. In the previous versions of Dynamics AX, there was a limitation for scaling the AOS server and customers needed multiple AOS servers. With Dynamics AX 2012, that's not the case anymore. One of my customers was able to downsize from 18 AOS servers to 6 with Dynamics AX 2012. The lower number of AOS would help with the AOS licensing cost, maintenance, and troubleshooting.
- Do not oversize the AOS server resources either. The Microsoft recommendation is to limit the AOS server to maximum eight CPU cores and 16 GB physical memory.
- Virtualization is recommended for AOS servers as it helps to reduce maintenance costs and allows high availability.
- Monitor the AOS server hardware utilization during tests and performance testing to evaluate if the performance meets the required benchmarks.
- You need to have somebody else to review the environments (other than the resources who built it—leverage your partner, Microsoft Premier Support team, or external consultants) once the hardware has been procured and set up. SQL, network, OS, AOS, hardware, storage, security, and others are very important aspects of your environments and need to be reviewed thoroughly.
- You have architected the infrastructure well enough, spent enough to buy all the high-end hardware. Now, the last thing you want to realize is that you haven't configured it well or you are not using all of its features.
Tip
We had a funny incident during one of the projects. We brought in a consultant to review the hardware and the network. They found that the network speed between AOS/SQL and the other application was slower. Getting into details, they found that all these servers were connected through a 100 MB switch while 1 GB switches had been bought, but were sitting on the floor at the data center since more than five years. Isn't that funny? But it happens all the time. The infrastructure teams have the highest number of critical projects running all the time with firefighting situations which demand off-hours work. There is always a possibility of missing out on such things.