Deploying and patching Control-M/Agent through Puppet

BMC Control-M/Agent(s) can be deployed like most of an agent software is. If you are a long-time customer of BMC, probably you already have and use BMC BladeLogic Server Automation. But if Control-M is the only tool from BMC and your infrastructure has a lot of Linux (virtual or non-virtual) machines with Puppet (and Puppet agents which are already installed), you may use the Puppet for the deployment of the Control-M/Agent. Unfortunately it's not easy to find any ready-made module for this task, even more - Puppet sometimes is considered as alternative to Control-M. Of course, I don't think it's a real alternative, not yet at least.

Back to the modules, I had not found anything specific in the Puppet Forge, so I made something own. :-)

The modules (two classes in separate modules which I am sharing with you) are very simple but have the useful parameters. For example they can be used like below:

Class['controlmagent'] -> Class['controlmagent_fixpack']

class {'controlmagent':
   userLogin => "ctmuser",
   installDir => "/controlm/ctmagent",
   primaryServer => "ctm8server",
   authorizedServers => "ctm8server",
}

class {'controlmagent_fixpack':
   userLogin => "ctmuser",
}

The installation of Control-M/Agent (with the controlmagent module) itself is made of a few steps:

• Checking if the agent is not installed yet (the installed-versions.txt file checking)
• Making the temporary directory if not exists
• Downloading the Control-M/Agent installation tar from the Puppet server (its general repository of files)
• Preparing the XML file for the silent installation
• Extracting the Control-M/Agent installer from the tar
• Running the installer

The second of the Puppet modules (the controlmagent_fixpack module) does the job not much different from the typical installation of the Control-M/Agent Fix Pack:

• Checking if the agent is installed (the installed-versions.txt file checking)
• Checking if the Fix Pack is not installed yet (the installed-versions.txt file checking)
• Making the temporary directory if not exists
• Downloading the Control-M/Agent Fix Pack installation file from the Puppet server (its general repository of files)
• Shutting down the agent
• Running the installer
• Bringing the agent back

Of course, the modules and classes could be more advanced but they should be good enough for typical scenarios.

While testing, you should get the output like this below:

The view on the same proces but in the Puppet Dashboard:

Ok... I hope you have found this post or/and the modules useful. As usually, any substantive comments, questions, requests (for example - a special, more advanced version of the modules) or errata are very welcome. 

Most important references:

• The Control-M/Agent installation module
• The Control-M/Agent Fix Pack installation module
• Puppet homepage
• BMC BladeLogic Server Automation homepage

 

Monitoring Control-M with Nagios

BMC Control-M can be integrated with monitoring tools by many ways. For example, we can use the PATROL Knowledge Module (which additionally has a nice capability of Control-M/Server failover automatic switching, similar to that which is typical for active/passive clusters) or the Control-M/EM integration with SNMP and external scripts (XAlertsSendSnmp parameter). With other built-in mechanisms (e.g. SendSnmp, Remedy integration, BIM-SIM, etc.) not only monitoring Control-M processes can be done but monitoring the jobs as well.

However, what if our monitoring system is Nagios or one of its derivatives, like op5 Monitor? Do we have to rely on the Control-M/EM and SNMP?

Not necessarily. We can make a use of the wide selection of Nagios plugins. If we haven't found any interesting plugin (which could be used to monitor Control-M), we can make the new one :-) The Nagios plugin interface is not very complex and even a shell script can be the plugin.

I have made the sample plugin for Control-M/Server 8 on Linux/UNIX. The plugin has two input parameters: the Control-M/Server user's home directory and the Control-M/Server home directory. The example call is below:

/usr/lib64/nagios/plugins/check_ctmserver \
/home/ctmuser /home/ctmuser/ctm_server

The plugin calls Control-M/Server's shctm script and the .ctmprofile file (from the Control-M/Server user's home directory), so the requirement is that the Nagios user (e.g. nrpe user) has permissions to read and execute the scripts. I would recommend to assign the user to the Control-M/Server user's group.

When called, the plugin parses the shctm output and returns the information to Nagios.

Of course, it also gives the exit code, which is: 0=OK or 2=CRITICAL (if some of the Control-M/Server processes are not working).

That's all. I hope you have found this post or/and the plugin useful. Any substantive comments, questions, requests (for example - a special, advanced version of the plugin - with performance data, etc.?) or errata are - as usually - very welcome. 

A few references:

• Nagios homepage
• BMC PATROL KM for Control-M (not much information here, much more can be found in the BMC documentation)
• op5 Monitor homepage

 

The load-balancing with HAProxy and Control-M agents

HAProxy is well known as a tool for HTTP(S) protocols, but not every knows it can also work as the load balancer for other TCP traffic. Can we use it with applications like BMC Control-M? Let me try to answer the question.

BMC Control-M has features like Host Groups and Host Restrictions (based on current CPU utilization and/or number of jobs) which are recommended ways for load-balancing jobs. However, since the Fix Packs 1 (for Enterprise Manager, Server and Agent), Control-M 8 supports network load-balancing routers which also can be useful.

So, now it is up to your IT infrastructure and your IT scenarios which load-balancing mechanisms you can use or you prefer to use. I can also imagine that both of the ways, or even three ways if you think of Control-M's quantitative and control resources, may be used at the same time.

But let's go back to HAProxy.

In the simplest scenario we may have one load balancer (e.g. rh65haproxy) and two hosts (let's call them rh65haproxyA and rh65haproxyB) which are behind the LB router.

The configuration may look like below (in the file /etc/haproxy/haproxy.conf):

listen controlm *:7006
mode tcp
option tcplog
balance leastconn

server rh65haproxyA 192.168.10.54:7006 check
server rh65haproxyB 192.168.10.55:7006 check

Of course, this is a very basic sample only. HAProxy can be much more powerful utility and has a lot more features which can be set up. I would consider e.g. more of the server options (for example - the weight option) and also the use-server commands (in a case of more complex infrastructure or fail-over scenarios).

If you are the Red Hat systems user, the good news are that HAProxy is already a part of Red Hat Enterprise Linux.

Back to our scenario, after we set up the load balancer, the network load-balancing support feature must be enabled in the Control-M Configuration Manager. We have to go Control-M/EM System Parameters and look for the EnableLoadBalancerRouter parameter:

After recycling the Control-M Configuration Server we can define components of the new class - Network Load Balancer Router:

In the Control-M GUI (Monitoring) user interface, the network load-balancing looks like Host Groups, but "under the skin" it's a bit different from that:

That's all. Have the nice load-balancing! :-)

And, any substantive comments, questions or errata are - as usually - very welcome. 

A few references:

• HAProxy homepage
• Load Balancer in Red Hat Enterprise Linux 7
• Release Notes for Control-M/Server 8 Fix Pack 1