Since more and more companies are starting to look at using Azure for AX 2012 workloads, it seemed like a good time to review some of the Azure configuration options that can impact the experience after the move to the cloud.
Anyone who is considering making the move to Azure for AX really needs to look at using LCS, even if it is from a sheer simplicity point of view. Microsoft has been working hard on expanding LCS to allow us complete control over the Azure resources chosen for our AX deployments, and with the inclusion of storage options it feels like we are finally there. This is less important for dev/test deployments than for production, however there are still a few configurations that can have a significant impact on performance. Understanding these ahead of time will prevent having to go through a resource upgrade down the road.
When deploying a new environment, the first and most significant choice you have is about the VM size. By default, D series machines are selected. For AX 2012, D3’s are generally good for the AOS servers and D12’s work better for the SQL servers. Non-batch AOS servers are really designed to scale out and not up, so adding additional memory above 16 GB provides diminishing returns. If you are setting up a dedicated batch server that you know will take advantage of multi-threading, then a D4 would likely be the way to go as the batch system can take advantage of the additional cores and memory.
If CPU performance is a concern, then selecting the D v2 series will move you up to a different core architecture that will provide additional performance. The basic A series machines should really be avoided for anything other than AD or print server functions. All of the components of AX (SSRS, SQL, EP) all require enough compute to merit at least a D series. For production environments that have heavy workloads, the G series will provide all the horsepower you need, however for the vast majority of AX installs, D’s will work and the D v2 would be the highest you should have to go.
If you want to delve deeper into the specifics of each series, details can be found at https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-sizes/.
When reviewing the size of the VM, there is one additional decision to be made before providing your final answer, and that is about storage. If you look through the list of VMs you will see an S appended to some of the series names, so a complete list of the D4 machines is D4, DS4, D4 v2 and DS4 v2. The S signifies premium storage.
Premium storage utilizes all SSD drives to provide a high performance disk system which SQL server can really take advantage of. Since each VM type has a maximum number of disks that can be attached, premium storage also allows for greater storage capacity as the drives are larger. For AOS servers there is very little disk utilization and so premium storage will not provide a lot of benefit, it is better to allocate the funds for the SQL server.
There are three levels of premium storage available, P10, P20 and P30. Specifics for performance of each level can be found at https://azure.microsoft.com/en-us/documentation/articles/storage-premium-storage/, however the main statistic we are concerned about for an AX workload is IOPS.
With standard storage, the max IOPS you can achieve is 500/disk. P10 offers the same performance at 500/disk. At P20 that limit jumps to 2300 and P30 offers 5000. When we consider that an average production AX workload requires between 800-1200 IOPS it is clear that standard and even P10 storage will not give us the performance that we need. At the other end of the scale, even the largest AX deployments rarely go above 2000 IPS, so P20’s are the AX sweet spot.
The IOPS requirements for a DEV/TEST environment will be significantly less, except during compile times. Since AX 2012 stores the code in the SQL database, compiles are very IO intensive on the SQL server and a difference of hours can be seen in running a full compile on standard vs. premium storage. Depending on your development strategy, the time savings may not be worth the additional cost of premium storage, but it is something to consider.
Of course the advantage of running AX in Azure is that nothing is set in stone. If you have already provisioned or are not sure what to provision, upgrading to a higher level machine has become very simple. From a compute perspective, you can simply log in to the Azure portal and specify a new architecture. Depending on how drastic the change in architecture is (i.e. moving from an A series to a G series) there may be downtime involved, so it is worthwhile testing before doing it in production.
Additionally, premium storage cannot be added to a non-S series machine. So if you provision a D3 and then later decide you need premium storage, you will need to provision a DS3 and migrate your drives.
Changing storage type is not as simple as clicking a dropdown. Premium storage requires a premium storage account and migrating disks from one storage account to another requires PowerShell. It can still be done; it just requires more effort. An example of what is involved in migrating storage can also be found at the same link as the storage details above. Needless to say this would need to be tested ahead of time as well, you don’t want to lose your productions disks due to a botched move.
The final consideration in your Azure deployment is location. While this does not directly affect performance, not all compute or storage options are available in all locations. Most are, and Microsoft is updating locations all the time, so while it is tempting to simply place your environments in a data center that is geographically close, just be sure to check before you commit. Moving between regions is not supported right now and will require recreation of machines.
LCS and Azure definitely make deploying AX environments a lot easier, but as with all IT projects, there is a little planning you need to do ahead of time to ensure a smooth deployment. And if it doesn’t quite work out the way you hoped, it is a relatively simple task to tweak the environment to get it where you need it to be.