Load Balanced Server Architecture

AVEVA Work Tasks uses its own clustering technology which allows real-time load balancing based on load on the server. It is managed either using the Multicast mode or the Database mode depending on the configuration done at the Farm level.

• Multicast mode: This uses multicasting UDP protocol to share the server status with other servers over a multicast IP and port at a regular interval.

• Database mode: This uses a database to store the server status of all the Enterprise Servers at a regular interval. All the servers keeps polling the data from the database to get the latest status of each server.

The Enterprise Server installation has a service called "Advance Server service" on each machine running the Load Balanced Server. This service acts as a Load Balancing coordinator between all the servers in the cluster, and continuously keeps communicating with the other Advance Server service running on other machines in the cluster. Services such as Workflow Engine, Task Scheduler, ArchestrA Mobile Notification Service, and Communication Service register themselves internally with this service to get health information about the cluster and provides their own health information to this service. This service performs the following operations:

• Monitoring CPU utilization of the server

• Monitoring health of each service such as Workflow Engine and Task scheduler in the given machine

• Broadcasts the health of each service to the entire cluster over a Multicast based UDP group using the Multicast mode or stores the information in the database using the Database mode. This broadcasting happens at a regular interval which is referred as the “Heart Beat”. So essentially the heart beat is important to determine how fast the cluster can respond to failures or respond to load pattern changes on the server (for example, high CPU utilization on the server).

• Whenever a new workflow execution is requested, one of the servers in the cluster decides which machine will execute it; based on the load on each of the servers. This server is called the “Authority server”. The Authority server role is not bound to any specific machine in the cluster, and any machine can become an Authority server in the cluster. This helps in scenarios where the Authority server itself goes down, since in such cases some other machine can play the role of an Authority server dynamically. The Authority server also makes some more decisions related to coordination of load balancing and failover in the entire cluster.

• If you select the Multicast option, it is recommended that a dedicated Network Interface Card (NIC) be present in the system as AVEVA Work Tasks uses Multicast-based UDP protocol for the cluster coordination. To have a dedicated Network Interface Card, UDP multicasting in the group and all the machines should be part of the same subnet. Network Switch used to connect all the servers for UDP multicasting must be configured to allow multicast packets.

• Use of multicast or database to share the server status with other servers for such frequent messages greatly reduces load on the network and also allows the cluster to scale over multiple machines. The cluster can easily scale to even 4-5 machines and still allow true active-active load balancing.

• Each machine in the cluster communicates with the other machine in two modes. One mode of communication is the regular TCP/IP and the other mode is either by sending Multicast messages or polling data from the database at an appropriate point in time to exchange more specific data as and when required. In case a firewall exists between the servers it should allow broadcasting of both TCP/IP as well as multicast messages.

  Note: We do not recommend to have a firewall between machines in a cluster. The cluster can be setup behind a firewall.

• On AVEVA Work Tasks client machines (such as AVEVA Work Tasks Web Servers which are not having AVEVA Work Tasks Engine services installed, and are going to consume Workflow Engine services in a cluster), the Advance Server service plays the role of an assistant. The Advance Server service assists client APIs to determine which machine to connect in the cluster for the request. This allows fast identification of machine, rather than checking the health of cluster for each call, and also it has the most current state of the cluster. But this means in addition to machines which are participating in the cluster as Workflow Engine Role, even the client machine needs to have additional NIC and supporting network infrastructure to allow them to be part of the same Multicast group for consuming services from the cluster, when using the Multicast mode.

AVEVA Work Tasks Client Notification service which is responsible for monitoring incoming emails and SMS messages and File system events.

Database server can be a point of failure. It is recommended that the Database server is available with optimum performance.

Note: For Enterprise Server deployment, it is mandatory to have the date and time synchronization in all the Enterprise Servers running.

Multicast Mode

Database Mode

Note:

- In a virtualization environment, the following conditions hold good for the Load Balanced Server:

- While performing the disaster recovery scenarios, you must configure the recovery plan for the virtual machines in the following order, the first being with the highest priority:
a. Server1
b. Server2
c. Client