Hi
At JJ we have decided not to enable WHS functionality, since Warehousing II is not compatible with WHS and we do use some of those functinoality. At the other company we have used WHS from day 1 heavily for load planning, but we have not used the reservations engine, nor the picking routes in the warehouse. The items were using License Plates and got manufactured and allocated against specific sales orders, for which we made our own reservation routine not to rely on the WHS code for speed considerations. The additional tools at our disposal was great that WHS offered, however we have done heavy customizations to make it work according to our needs.
Enabling WHS will add extra load on your database and AX AOS, since for every inventory transaction on goods in and goods out you would be having a pick and put Work operation. The reservation engine uses an alternate table structure for inventory on-hand, generally speaking it will run a whole lot more code to do the work because it stores quantities per each dimension level. You will feel that inventory transactions take a bit more time to process, so a fast SQL with good storage will become more important, along with good index and statistics maintenance strategy to maintain database health.
Your transaction volume does not seem to be too high at the moment, but turning on batch / serial number tracking will change that for sure resulting in much higher inventory transaction numbers.
The hardware which we have procured now that will run JJ's workload starting this summer is a Nutanix XC630-10 hyper-converged solution supplied by Dell, in two 4-node clusters geographically separated with 2x E52698v3 CPU, 512 GB RAM, 2x800 GB SSD for hot data and 8x1 TB HDD for cold storage in each node.
That is going to house 1x Primary SQL 2014 and 1x Secondary synchronous and 2x Secondary asynchronous AlwaysOn replicas, 2x AX AOS (User), 2x AX AOS (Batch), 2x AX AOS (SSRS), 2x AX AOS (AIF/Web/API), 2x SSRS, 3x Terminal Servers, and some smaller VMs for running web services. As a start we will use 8 cores and 128 GB RAM for SQL, 4 cores and 32 GB for AX, 8 cores 32 GB for terminal servers to start with. And depending on the workload we will see it can be expanded, there is room to grow.
SQL 2014 does not give a big edge over SQL 2012, only in some scenarios. AX 2012 does not utilize the in-memory OLTP workload unfortunately, however R3 will be able to make use of the Non-Clustered Columnstore Index with the newly released Entity Store for better data warehousing and reporting. You could help AX a lot by offloading your reporting, BI and KPIs to secondary replicas and/or using the Entity store instead of hammering the primary SQL instance.
In the end it does come down on what do you use AX for, in my case we have about 8million inventtrans entries a year without WHS (~4k sales orders a day) with 11 years of historical data, DB sitting at 1.8 TB size. Since we use reporting heavily, we help to distribute the workload greatly by using a datawarehouse, then will move on to NCCI with Entity store soon, and doing the reporting from the secondary copies, so there is more juice available for doing AX business. On the old hardware we have a mixed use of storage and other databases ie. serving the eCommerce portal, which is far from ideal, so on the Nutanix boxes we will be completely isolating AX workload from everything else to gain the best speed.
