Optimizing an AOS depends on what the AOS is used for. For example, an AOS that is load balanced should only allocate a certain number of resources on the server it is running on. Similarly, an AOS that is only used for the Enterprise Portal may not want to allow access to rich client users. Therefore, before taking any steps to optimize the performance of an AOS, make sure you have properly defined a role that the AOS has.
There are two ways to distribute load in a Dynamics AX environment. They are the following:
• Non-load-balanced cluster
• Load-balanced cluster
A cluster of AOSes are simply a group of AOSes. It doesn't necessarily mean that they are load balanced. However, a load-balanced cluster does indeed mean that a group of AOSes in a cluster are load balanced. The following sections will describe in more detail what a non-load-balanced cluster and a load-balanced cluster are.
A non-load-balanced cluster does not have a main AOS that is dedicated to
delegating client connections to the appropriate AOS. Instead, each AOS in the cluster acts independently. Each AOS has to be provided in the client configuration file for the client to connect. Based on a list of provided AOS servers in the client configuration file, the client will attempt to access each server in the order listed to find an available server. If a server's workload has reached its maximum level, then the client will simply attempt to connect to the next AOS.
Microsoft Dynamics AX provides the option to load balance two or more AOS's together. This is similar to how a web farm works for a SharePoint site. Alternatively, you may opt to use hardware or another software solution to load balance AOS access. It is recommended to have one AOS for no more than 50-60 users. In a load balanced cluster, one AOS is a dedicated load balancer, delegating client connections to the appropriate AOS. It is not directly used either for interactive purposes or for processing application code. Once a client is connected to the load balancer AOS, it will then determine which AOS it should connect to. If an AOS goes down, the load balancer AOS will automatically re-route clients to an active and available AOS without having to make any modifications to client configurations. Also, as a company grows and more users are needed, it is as simple as installing a new AOS and connecting it to the load balancer.
As previously mentioned, to set up load balancing, we must set up one AOS as the load balancer. Afterwards, each additional AOS in the load-balanced cluster will automatically listen for client connection requests from the Load Balancer AOS.
However, in order for an AOS to be a load balancer, it must first satisfy the
• Cannot be a Batch Server
• Must be an AOS that is active
The following steps describe the process of setting up load balancing in Microsoft Dynamics AX 2009:
1. Open the Cluster configuration form by going to Administration | Setup |
2. Once in the Cluster configuration form, click on the Map AOS instances to
3. In the Map AOS instances to clusters tab, select the AOS instance in which
to act as the load balancer and mark the Load Balancer field.
As you can see, setting up a load-balanced cluster in Dynamics AX is quite simple and requires very little configuration or tweaking of settings. When load tends to increase and performance degrades, adding a new AOS into a load-balanced cluster greatly improves performance and is quite simple to do. You can add as many AOS's as desired to a cluster. The process is the same for every additional AOS that is added.
To summarize, a non-load-balanced cluster requires more administrative work to update the client configuration files with the available AOS's. However, with a load-balanced cluster, the AOS that acts as the load balancer, once setup with all the available AOS's will automatically delegate clients to an AOS in a cluster with the most available resources.
Certainly, having a load-balanced cluster may seem like a desired setup to go
with, as it requires less administrative maintenance. It also provides a method for consolidating specific business functions. For example, one cluster of AOS's may be specifically dedicated to batch processing. Similarly, another cluster may be dedicated to an external Enterprise Portal site that can experience a significant load of external user access while a cluster for internal users may not experience as much load. Also consider that in a load-balanced cluster, at least three AOSes are required while in a similar non-load-balanced cluster, only two are required—to provide load distribution.