Standalone AOS and AOS Clusters

The following is an explanation of some of the possible combination we can have when it comes to AOS’s in our environments.

For what I have learned over the years, we can have several different AOS setups, starting from a single AOS environment (usually used in a development and/or test machine) to a multi AOS (cluster) environment.

So, the following are the differences (based on my opinion)

Standalone AOS Environment

It is obvious that this is the simplest configuration. Usually, I would follow this pattern when I have to create a development and/or test environment. The reason is that for development scenarios (in small –mid companies) we don’t deal with 70 – 80 developers at a time.

In addition, we can add (if we want to) extra AOS servers if the need to handle a larger number of users and/or connections is necessary. This will create a side by side configuration.

Multiple AOS’s (not clustered)

As stated earlier, we know that multiple AOS's in a single Ax environment can exist side by side. Typically the way it works is that a user will connect to the AOS that has been configured in the AX configuration Utility. However, if we were to have more than one AOS listed in the AX configuration utility, the first available will be used to fulfill the connection request by a client.

I guess that if we are listing (and using) more than one AOS in our AX configuration utility is a good thing as this will ensure that a connection is guaranteed to the client because it will use the first available(except if all the AOS servers are down of course).

Side Note:  When using multiple AOS’s we can also define how the user connects to it. For example, in the project I’m working on right now we deal with two different time zones (USA and Asia), so in our cluster we define that the users in Asia will connect to AOS Asia, and the users in the US to the AOS US.

I guess the side note above opened the conversation to yet another type of setup, and this is the Clustered AOS.

There are two types of cluster mode for AOS.

1-      Cluster mode without Load Balancer

2-      Cluster mode with Load balancer

Cluster mode without load balancer

When a client starts, it sends a request to the first server that is listed in the client configuration. When this happens, the server returns the list of active AOS instances in the cluster, sorted by workload.  Then, the client attempts to connect to the first AOS instance in the list, and if that connection fails, the client attempts to connect to the second AOS instance in the list, and so on.

It will be logical to conclude that the only criteria to manage the load is the number of clients that are connected to a specific AOS, this includes threads, BC, etc.

Cluster with load balancer

If we set up a cluster that includes a load balancer, the load balancing AOS instance is dedicated to distributing the user load (NOTE: A load balancer AOS does not require a license nor does process Microsoft Dynamics AX business logic or data)

Side Note: We need to ensure to set up all the client configurations to connect ONLY to the load balancing AOS instance.

So when a client starts, it connects to the load balancing AOS instance. Then, the load balancing AOS returns a list of active AOS servers (instances) that exist in the cluster, usually sorted by the workload. Then, the client attempts to connect to the first AOS instance in the list. If that connection fails, the client attempts to connect to the second AOS instance in the list, and so on.

So, we can conclude that this is very similar to the non-clustered AOS mode, and I guess the only difference using a configuration like this is that we can add and/or remove other AOS instances from the cluster without updating client any of the configurations, which is really cool. Now the question is, even though the Load Balancer AOS is kind of free, do we really need it? Or what happens if the Load balancer AOS fails?