The Technet reference does state" A dedicated load balancer has lower hardware requirements than an AOS instance that functions as an application server, because the load balancer does not process application requests or business logic." https://technet.microsoft.com/en-us/library/dd309704.aspx
and says it again here https://community.dynamics.com/ax/f/33/t/236401/reply?ReplyToContentTypeID=0
- The AX client configuration determines to which AOS instance that client will connect.
- When the contacted AOS instance is part of a load balanced cluster, then that AOS will act as the load balancer. The load balancing logic is based on a count of current user sessions, and also takes into consideration the max concurrent sessions defined for the instance on the cluster.
- If not, then the contacted AOS is used. When multiple AOS instances are listed, Ax goes down the list until it establishes contact.
- If you have only one AOS instance listed in the client configuration, then you have created a single point of failure. If no connection is established with that AOS, then the client connection will fail, even if that AOS instance belongs to a cluster that has other AOS instances available for connection.
- Every client configuration should point to all AOS instances in the cluster, thus eliminating the single point of failure.
- Those AOS instances listed in the client configuration should belong to the load balanced cluster
- A dedicated load balancer should only be used in high volume scenarios.
The problem with having multiple application folders is maintenance and to keep those in sync.
There is no replication or sync mechanism,. Hosting the files on a clustered file server has a limited benefit since the AOS service does not support automatic failover. You have to restart the AOS and the client sessions will be lost. but It might help you reduce downtime, a little -In AX 2012, the application files are in the database.
Consider whether the client does most of their entry manually within the AX client or is there lot of automation? i.e .do they manually enter Sales orders, purchase orders, planning, etc. or do they utilizing the batch functionality of AX heavily in areas such as AIF imports from outside systems for transactions, master planning, warehouse systems, etc.
Once you have a feel for the separation of Automated vs. Manual, that will help you decide the best Cluster Configuration of your AOS servers within the AX application.
If the client is going to be more manual with few integrations/batch jobs, then set up at least one of the AOS servers as Batch enabled and 'Non-Load Balanced' in the cluster configuration (System admin module). This will stop users from connecting to the batch server with an AX client.
The rest of the AOS servers can be set to 'Load Balanced'.
Separate user servers from servers that batch jobs run on. There are a lot of reasons for doing this but mostly they have to do with segregation of responsibility in your AOS cluster.
If an AOS's system resources get tapped or crashes, then the place troubleshooting could is to know whether a User that created issue in the client, or whether a batch job caused it.
If the client has a lot of integrations with outside systems and the bulk of their transactions will be imported (i.e. sales orders, purchase orders, warehouse trans, financial uploads, etc.), then go for a Non-Load Balanced, batch enabled servers, at least 2 dedicated.
Ultimately a single AOS can support many user sessions, but having batch jobs on user AOS servers can lead to some issues, especially at peak transaction time.
You can change these settings on the fly inside AX without restarting AOS services.
Also set a Load Balanced server that users can connect to as a batch server , and then set the server to ONLY do batch jobs during the evening hours, and leave the daytime for users and nighttime for typically heavy nightly processes (invoicing, planning, etc.). Useful when you have a lot of pos sunc, or alerts workflows etc.
When a client has purchased multiple AOS licenses, segregation of responsibilities is the best option.
Note also that the AX client now talks also directly to SSRS and WCF.
An Ax 2012 AOS LoadBalancer does not include the SSRS reports so you must separately LoadBalance SSRS - but unless you are on SQL 2016 Sp1 then you cannot do that scale out with a standard SQL database and need Enterprise SQL. This is the NLB approach see http://dynamics-ax.blogspot.ae/2013/01/ax-2012-sql-server-2012-nlb-reporting.html
If you are using WMS, then see this psot http://www.axvice.dk/ax2012-wms-device-scale-out-considerations/
When working in a Dynamics AX environment with multiple AOS instances to connect an AX client to a specific AOS for troubleshooting and/or testing purposes and to bypass load balancing create a client configuration file that is set up to connect to a specific AOS instance using a configuration command setting.
- Create a new AX Client Configuration file using the Microsoft Dynamics AX Configuration Utility.
- In the “Configuration command to run at kernel startup” field enter the following command
-internal –loadbalance=0
- Save the file.
- Launch Dynamics AX using this new file.
When using this configuration file to launch Dynamics AX it will connect to the AOS instance that you have configured under the Connection tab and bypass any AX load balancing that is set up.
