Implementing BPPM version 9.5 starts with architecture drawing board. Whether you are currently running a previous version of BPPM, migrating from BMC Event Manager 7.x, or implementing BPPM for the first time, you must start with a new architecture design because BPPM 9.5 is drastically different from its previous versions in terms of architecture and capacity.
Use bottom-up approach and start your design with your data/event sources. You can divide them into three categories: data-only integration, event-only integration, and PATROL agents (data + events). Then decide how many integration service nodes you will need for each category. In general, it is better to have separate integration service nodes for each category unless you have a small environment.
For data-only integration and event-only integration, BPPM 9.5 didn't make any major capacity changes. BPPM 9.5 still uses data adapters to pull data out of non-PATROL data sources such as BMC TM-ART, BMC Portal, Microsoft SCOM, etc. Non-PATROL events are still pushed to BPPM cells through iiWS, SNMP adapter, msend API, custom email adapter, etc. If you have a previous version of BPPM/BEM running, you can assume the same capacity requirements of integration service nodes for data-only and event-only integration.
For PATROL data, BPPM 9.5 made a major improvement by allowing data and events streamed through the same port. The capacity is limited to 900 PATROL agents per integration service instance. BPPM 9.5 also added an integration service cluster feature so that PATROL agents connected to the first integration service instance in the cluster can send data+events to the second integration service instance in the cluster when the first integration service instance becomes unavailable. If you decide to implement integration service cluster, it means that you can only connect 450 PATROL agents to each integration service instance.
However, if you are not monitoring many instances and parameters on each PATROL agent, you may have plenty of unused resources on each integration service node after streaming data+events from 450 PATROL agents. When this happens, you can install and configure a second integration service instance on another port at the same integration service node.
After architecture design for integration service nodes, you will need to design BPPM server architecture. Each BPPM server has a capacity at 1.7 millions of attributes. If your total number of attributes has exceeded 1.7 millions, you will need to implement multiple BPPM child servers plus one BPPM central server. If your total number of attributes has not exceeded but close to 1.7 millions, you may want to implement one BPPM child server plus one BPPM central server to offload resource intensive GUI operations from BPPM child server to BPPM central server. If your total number of attributes is far below 1.7 millions, you can go with single BPPM server.
Hi Willa,
ReplyDeleteThank you for sharing your experience with us.
I have a question you have mentioned that 900 Patrol Agent per Integration Service is the capacity in 9.5, but however from what i know the scalability depends upon No of attributes or no of monitor instances per Integration service.
Is there something i am missing ? or not able to understand.
Thanks..
Amrit
Amrit,
ReplyDeleteSorry for having overlooked at your question for so long. In Page 42 of BPPM 9.5 Architecture and Scalability Best Practice Webinar (https://communities.bmc.com/docs/DOC-29029), it listed integration service maximum capacities as 1) 1,700,000 attributes; 2) 250,000 instances; 3) 900 PATROL agents. However 1) and 2) are the same maximum capacities for BPPM server. This means limitation 1) and 2) can most likely never be reached since we usually have more integration service nodes than the number of BPPM servers. Therefore 3) 900 PATROL Agents is the only practical limitation. This conclusion has also been verified by BMC Support.
Thanks!
Willa