Load Balancing / High Availability of Maximo 7.6 Cron Tasks using DoNotRun and NOW DoRun Properties

Body

Did you know that Maximo cron tasks have some built in fault tolerance?  Did you know that where cron tasks run can be controlled?  Did you know that by using built in functionality, you can manage load on any particular JVM server?  It’s all there and it’s been there for a long time.  Here we’ll tell you about best practices in using this function and about a brand new property in Maximo 7.6.

As far back as 2005 cron tasks have had some fault tolerant capabilities.  To understand them, you will need to understand the basics of Maximo fault tolerance.  Maximo is a complete application built into an Enterprise Archive (EAR) file.  A single instance of this EAR file deployed and run in an application server Java Virtual Machine (JVM) can connect to a database server, connect to a report server, provide a User Interface (UI) to end users, integrate to external applications using the Maximo Integration Framework (MIF), authenticate users either natively or through a directory server, perform scheduled tasks (cron tasks), escalate certain tasks based on criteria (escalations), and much more.  Yes!  That’s a lot of stuff and just reading that sentence can make you out of breath.  Sure, that one JVM CAN do all that stuff but would you want it to? And then, even if you set it up that way, what would your users do if your server crashed?

That’s what high availability and load balancing is all about.  Setting up your environment so that if something fails, it can continue to run somewhere else and the users never see it or so that not too much stuff runs on any single instance causing a performance problem.  Maximo does this with multiple JVMs.  You build an EAR file, you deploy it to a cluster in the application server with multiple applications and if one of the applications instance fails, Maximo keeps running in other applications.  With intelligent URL redirection, end users rarely even know a failure has occurred.  Once deployed, you can use properties to set aside one JVM for reporting, other JVMs for cron tasks, and still others for cron tasks or integrations to manage the load.

So with that understanding, let’s talk about cron tasks.  If no properties are set on the server instances, it will start at the scheduled time on any one of the running applications in the cluster.  Once it runs the first time, it will have an affinity for that same instance of the application unless, when it runs, it cannot find that application instance.  Then, it will go and find another instance it can run on.  That solves the fault tolerance right?

What if you have 100 concurrent end users so you need two application instances just for users and two application instances to run background/cron tasks?  Here you would set up instance variables for the applications.  So assuming you have named your JVMs UI1, UI2, CronA, CronB, you would set instance variables for UI1 and UI2 using the property DoNotRun set to ALL.  This tells UI1 and UI2 not to run any cron tasks and it means that either CronA or CronB may pick up your cron task at startup and they could then fail over to the other server if either of those became unavailable.  But the bigger you get, the more complicated this becomes.  What if you have 100 cron tasks and you don’t want to let them all run on any one application so you need control over which JVM runs which crons and you need fault tolerance.  Using the two cron servers (A & B) won’t work anymore because if you use DoNotRun=ALL they won’t run any crons and if you specify DoNotRun=cron1,cron2,cron3…. And DoNotRun=cron51,cron52,cron53 on the two different servers it will control where things run but will not provide fault tolerance because the other cron server has been set to not run the cron tasks specified.  In this case you will need to add CronC and CronD application instances each with the same DoNotRun settings as its counterpart.  This will set the servers so that 50 crons will run across CronA and CronC and 50 different crons will run across CronB and CronD. 

So far so good right?  But what if you had a cron that you really needed to run on your UI servers?  Just one cron, that’s all you need on those UI servers.  Well, from Maximo version 6.x through 7.5, you could do that but you would need to specify DoNotRun=cron1,cron2,cron3,…..cron98,cron99 on the UI servers and then DoNotRun=cron100 on the cron servers.  Besides the inevitable human error associated with specifying all of these crons, cron instance names can get pretty long and we have actually had to increase the size of the instance property so some of our larger clients could manage all the crons they needed to specify.

To this we have responded with the DoRun property included in Maximo 7.6.  First we must apologize; we missed it in our documentation.  Yep, that’s right; we added this cool new feature and then forgot to tell you about it.  Well, now you know.  The DoRun property is exactly the opposite of the DoNotRun property.  You can now set properties to DoNotRun=ALL and DoRun=cron100 to accomplish the massive undertaking of just using the DoNotRun property of old.