I’ve done a few Omnibus deployments over the years but have often found the rollout of a multi-tiered environment involved some tedious planning sections to ensure the naming conventions used for the various components were correctly added to the props files of each distributed server. An architecture that can span 6 or more machines needs to have easily understandable names used for the collection, aggregation and display object servers, in addition to the gateways that link them all together. Entering these names correctly into multiple props files is entirely error-prone and can often cause hours of frustration trying to track down which entry you made a mistake on when your northbound events aren’t arriving.

Some props file settings always have to be changed when rolling out a multi-tiered environment but there’s others you might have to consult the documentation about to remember what they did. I wasted days, and I expect a few others did too, when the ITM – Omnibus integration first came out and my EIF probe would happily receive events from ITM for a while, and then just plain stop, and Interval = x did not leap out of the props file as being the source of the problems.

To alleviate a large portion of this headache is the multi-tier deployment initiatives that have been released by the IBM Tivoli Netcool Advanced Architecture Group. I’ve seen them mentioned in the Omnibus documentation in earlier releases but had chance to put them into practice last night. Working out the naming conventions, creating the omni.dats and then having to compile gateway-specific map files have always been a lesson in pain, but the supplied scripts in $NCHOME/omnibus/extensions/multitier
work perfectly well and the documentation covers the process extremely well. I had 4 Omnibus 7.3.1 object servers up in under an hour, complete with aggregation servers in failover, and the gateways between them and the collection servers all configured automatically. Extremely useful!