Technical Blog Post
New in Maximo 7.6 - load balancing cron task instances
Now that Maximo 7.6 has been released, we have access to new functionality that benefits a highly available environment. Cron task instances can now be load balanced across all servers that are allowed to run them.
What does this mean?
Let's say that you have four clusters (one each for MIF, UI, CRON and Reports). In each cluster you have two JVMs.
In previous releases, the purpose of assigning multiple JVMs to the CRON cluster was to provide high availability in the event that one of the servers goes down or becomes unavailable for any reason. When this occurred, the cron task would move from the unavailable server to a running instance where the Maximo system properties allowed them to run. This meant that all cron task instances were typically running in one of two CRON application server instances at any given time, but never both at the same time. The problem with this is only one application server instance was running all cron task instances and possibley overloadin that single JVM. It was possible to separate load based on the cron task instance name (using static mxe.crontask.donotrun and mxe.crontask.dorun Maximo system properties for each application server instance) but it was not possible to run the same cron task instance in multiple servers at the same time so this load was always pinned to one application server instance.
Now with the release of Maximo 7.6, cron task instances run in all server instances that allow the crons to run, which provides load distribution for the cron tasks.
For example, let's say you have an escalation cron task that is set to run on both of the two CRON cluster application servers, such as using a property similar to the following in the maximo.properties file:
In Maximo 7.6, both application server instances will take turns running this cron at the specified interval. So, if the cron task instance is scheduled to run every two minutes in the CRON cluster, the cron task will run in the first application server instance at the scheduled time, and then two minutes later, the second application server instance will run the same crontask. Two minutes later again, the first application server instance will run this cron task again. This means you could have four CRON application server instances and all four instances will take turns running this cron task instance.
The new functionality allows you to better control the load that is going to be placed on your servers and size your clusters accordingly. There are now plenty of reasons to have multiple application servers in the CRON cluster to prevent overloading any one application server instance will running cron tasks. Although you could control which crontasks ran in which servers previously, right down to the application server instance if you wanted to, it was not possible to distribute the cron task load for a single cron task instance.
You can review which cron tasks are running in which application server using either the TASKSCHEDULER table in the database (this is where the servers keep track of where the cron ran last), or you can use the Cron Task History tab to record this information and determine when and where your cron tasks are running.