This is the last post for "Lessons Learned from Migrating BEM 7.4 to BPPM 9.0" series. As a summary, here is the architecture diagram of BPPM 9.0 high availability implementation.
This architecture varies slightly from BMC's standard recommendation as we keep BPPM cells and BPPM Agents totally separated on different servers. In a real enterprise IT environment where data flow is steady but event flow is unpredictable, our architecture offers better resource utilization, more flexibility, and more robust high availability.
<This architecture diagram has been deleted>
Hi Willa,
ReplyDeleteThanks for all this valuable information.
We are currently upgrading from BEM 7.3 to BPPM 9.6 and are experiencing similar issues that you mention. More specifically we are standing up a new, separate (clean !) BPPM 9.6 environment and migrating anything we need from the old system to the new. We do not have PATROL or any other metric data coming in so BEM is used purely for event processing. The argument for going to BPPM was more about staying within support than about any new feature it may bring.
Our main issue has been around the inability to successfully HA the embedded BPPM cell. Currently we have an aggregating/filtering cell 'bemp01', a service modelling and auto-ticketing cell 'simp01', and a presentation cell 'simp02' - all HA'd. In our new BPPM environment we still have 'bemp01' HA'd across its own 2 servers and 'simp01' (separate to the embedded BPPM cell) HA'd across the 2 BPPM servers. 'simp01' still handles service modelling and auto-ticketing (as before), and forwards events to 'simp02' (the embedded BPPM cell).
BUT... because it can't be HA'd, 'simp02' is actually 'simp02r' and 'simp02w' on separate BPPM servers. 'simp01' forwards events to BOTH 'simp02r' and 'simp02w'. So, operators can see the events in either BPPM Operator Console. If they close an event in one, this will flow down to the HA'd 'simp01' and back up to the other simp02x cell. If we lose a BPPM server, HA will handle the failover of the 'working' cell - 'simp01' - and the other BPPM server will have an up-to-date copy of the events in its own 'simp02x' cell.
In summary BPPM is effectively active/active but for presentation purposes only. Service modelling and auto-ticketing is still leveraging the old primary/failover cell capability. Why did we do it this way ? Because we didn't want the expense of clustering software to achieve what we always had without it :-)
'Upgrading' from BEM7.3 to BPPM 8.6 then 'upgrading' from BPPM 8.6 to 9.5 has not been an option as we need to cutover from a live BEM 7.3 system to the new BPPM9.6 system within a change window. So, my question to you is :
"Do you know how we can migrate the events (mcdb) from the old system to the new ?"
The events in the old system have created incidents in Remedy 7.5 and these incidents are being copied/migrated over to Remedy 8.1. If we don't take the events over as well, OK events will not be able to close prior non-OK events and auto-resolve incidents they may have created.
Any advice appreciated !
Thanks & regards,
Rohan