Professional Documents
Culture Documents
Summary
This Best Practice document provides an overview of the core BPPM 9.5 architecture. Detailed
information and some configuration guidance is included so that the reader can get a solid
understanding of the core solution components regarding how they are connected and communicate
with each other. Best Practice recommendations are provided throughout. References to previous
versions are provided and discussed where appropriate.
Page 1 of 47
Table of Contents
Summary ....................................................................................................................................................... 1
Caveats & Limitations ................................................................................................................................... 1
BPPM 9.5 Overall Architecture ..................................................................................................................... 4
Architecture changes compared to BPPM 9.0 .......................................................................................... 5
BPPM Server Architecture ........................................................................................................................ 6
Sybase Database Architecture .................................................................................................................. 7
Oracle Database Architecture ................................................................................................................... 8
Integration Service Hosts ........................................................................................................................ 12
Event & Data Flow Processing ................................................................................................................ 17
Connection Details .................................................................................................................................. 19
Central Management & Administration (CMA) .......................................................................................... 23
Single CMA Architecture Overview ......................................................................................................... 24
Multiple CMA Architecture ..................................................................................................................... 25
Standalone BPPM Servers & CMA .......................................................................................................... 25
CMA Architecture Details........................................................................................................................ 26
Staging Integration Services........................................................................................................................ 27
Overview & Functionality........................................................................................................................ 27
Staging Process Illustration ..................................................................................................................... 29
Initial Agent Deployment .................................................................................................................... 29
Integration Service Policy Application ................................................................................................ 30
Production Monitoring ....................................................................................................................... 31
Staging & Policy Management for Development, Test and Production ..................................................... 32
Single CMA Instance Deployments ......................................................................................................... 32
Multiple CMA Instance Deployments ..................................................................................................... 35
General Recommendations .................................................................................................................... 36
Interoperability ........................................................................................................................................... 37
High Availability .......................................................................................................................................... 39
BPPM Application Server HA................................................................................................................... 39
Data Collection Integration Services HA ................................................................................................. 40
Staging Integration Service HA ............................................................................................................... 40
Event Management Cells HA................................................................................................................... 41
Page 2 of 47
Page 3 of 47
User Consoles
(Web GUI & Java Admin)
Event Management
Correlation Cell
PATROL Agent
Remote Monitoring
Events &
Performace Data
Data
Events
PATROL Agents collect performance data and generate events for availability metrics. Both
performance data and events from PATROL are streamed though the Integration Service nodes. (This
assumes the BPPM 9.5 Server and BPPM 9.5 Integration Service nodes are in use.)
The Integration Service nodes forward the performance data to the BPPM Server. Not all performance
data has to be forwarded. Performance data can be collected and stored at the PATROL agents and
visualized as trends in the BPPM 9.5 console without having to stream the data to the BPPM Server.
This is configurable for each PATROL parameter. It is a Best Practice to limit streaming performance
data to the BPPM server for only the following purposes.
1) Performance data for all parameters designated as KPIs should be streamed to the BPPM server
to support baselines, abnormality detection and predictive alarming.
Page 4 of 47
Page 5 of 47
Central BPPM
Server with CMA
Policies
Data & Events
Data
Events
Modeling
Direction of arrows indicates
connection requests.
Child BPPM
Server 1
Integration
Host 1
PATROL Agent
monitoring
Child BPPM
Server 2
Integration
Host 2
PATROL Agent
monitoring
Child BPPM
Server N
Child BPPM
Server N+1
Production
Integration
Host N
Production
Integration
Host N+1
PATROL Agent
monitoring
PATROL Agent
monitoring
A multiple BPPM Server implementation supports distributed service models so that specific
Configuration Items in one BPPM Server can be visible in another model in a separate server. This is
supported by Web Services installed standard with the BPPM Server(s). The Central BPPM Server acts as
a single point of entry for users and provides a common point to access service models.
Although not required, for most environments BMC recommends installing the top tier BPPM Server as
a Central server with the CMA module included.
A single BPPM solution implementation cannot support mixed versions of BPPM servers. This includes
the Central Management and Administration module. All BPPM Server versions must be the same in a
single environment.
Page 6 of 47
Page 7 of 47
Development
BPPM Server
Test
BPPM Server
Production
BPPM Server N
Production
BPPM Server N+1
Likewise, multiple BPPM Reporting instances can share the same Oracle instance.
WARNING: An Oracle instance should never contain a schema or schemas for the BPPM Server while
also containing a schema or schemas for BPPM Reporting. The BPPM Application Server instance(s) and
reporting instance(s) must be separated for performance reasons. Additionally the Oracle database
instances for BMC components should be dedicated for BMC products and should not contain any third
party application data or code. The diagram below illustrates these requirements.
BPPM Server 1
Report Engine 1
BPPM
Reporting
Database
BPPM
Application
Database
Schema 1
BPPM Server N
Report Engine N
Reporting
Schema
Schema N
Schema N+1
BPPM Server N+1
Page 8 of 47
Additionally, each unique BPPM Server schema should be installed into separate data files and
corresponding tablespaces in the Oracle Instance. The BPPM Server installer allows you to specify these
criteria as shown below.
Page 9 of 47
Page 11 of 47
BPPM 9.0
All Environments
BPPM Server
Events
Event
Cell
Integration
Service
Data
Events
Event
Cell
Integration
Service
Integration
Service Host
Events
BPPM Server
BPPM Server
Data
BPPM 9.5
Recommended
Data
Integration
Service
Integration
Service Host
Integration
Service Host
Data & Events
Legend Key
Data & Events
Data
Events
Direction of arrows indicates
connection requests.
The BPPM 9.5 Integration Service processes accept streaming of PATROL data and events using a
common connection port. The default port is 3183. This includes all data points and events from
PATROL for parameters that you select. Once events arrive at the Integration Service, events are
separated and follow a unique path to one of the following based on configuration:
1) The Integration Service local cell (default behavior)
2) A Named Event Cell
3) The BPPM Server associated to the Integration Service
NOTE: PATROL sends performance data, streaming it to the BPPM server. This is not summarized data.
The data does get summarized in the BPPM Server (as in previous versions) but raw data is sent from
the PATROL Agents. This includes all data points for parameters that you decide to send.
Page 12 of 47
The architecture also supports buffering of PATROL performance data and events at the PATROL Agents
in case there is a network connectivity issue or the Integration Service otherwise cannot be reached.
When the PATROL Agent reconnects to an Integration Service process the buffered data is sent. This
capability is not intended to support buffering for very large amounts of data. It is intended to support a
few minutes of lost connectivity, not hours or days. Testing has shown that the process can support up
to 30 minutes of data collected by PATROL Agents across one thousand managed servers.
The BPPM 9.5 Integration Service processes are generally stateless meaning the following.
1) The 9.5 Integration Services do not cache PATROL Agent namespace data and data points as in
9.0. The data is now streamed directly through to the BPPM Server. The server now gets every
data point rather than only a snapshot every 5 minutes from the Integration Service cached data
points.
2) There are no adapters associated with PATROL data collection.
a. All filtering of performance data is handled at the PATROL Agents.
b. All filtering of events is handled at the PATROL Agents and if necessary in the event
management cells.
3) The Integration Service acts as a proxy to receive and forward both data and events that are
sent to it from PATROL Agents. It also receives PATROL Agent and Knowledge Module (KM)
configuration data from CMA and passes that data to PATROL Agents.
The following components can be optionally installed and configured on the Integration Service host
depending on whether or not they are needed in the environment. Before installing any of these
additional components scalability and additional required resources must be considered.
1) Event Management Cell Event Management process installed locally on the same server with
the Integration Service. It is a recommendation and Best Practice to install the Event
Management Cell on all Integration Service hosts.
2) RT Server - This assumes the environment includes the PATROL Central Console which is not
required. Refer to PATROL documentation for RT Server requirements. Note that the Console
Server process should be installed on a separate machine.
3) Event Adapters - These work with the event management cell to consume non-PATROL events.
For example SNMP traps, etc. Significant non-PATROL event collection should be dedicated to
other event management cells as recommend in Best Practices for previous BPPM versions. The
default event adapter classes, rules and files are installed with the cell that is installed with the
Integration Service installer.
4) PATROL Agent and Knowledge Module (KM) for monitoring the Integration Service host
processes.
Page 13 of 47
Page 15 of 47
Large environments
Geographically distributed managed infrastructure
Large numbers of events
When different event sources require different event management rules for example
large numbers of SMNP traps compared to events from PATROL
e. Significantly different event management operations are divided by teams
9) Configure display of remote event management cells in the BPPM server when necessary.
10) Install dedicated event processing cells to manage large volumes of events from common
sources like SNMP traps, SCOM, and other significant sources of events.
11) Distribute event management cells as required, based on event loads and event sources.
12) Deploy event management cells close to or on the same node as the event sources for 3rd party
sources.
13) Filter, enrich, normalize, de-duplicate and correlate events at the lowest tier event management
cells as much as possible before propagating to the next level in the event flow path.
14) Do not collect unnecessary events. Limit event messages sent from the data sources to
messages that require action or analysis.
15) Do not try to use the event management cells as a high volume SNMP trap forwarding
mechanism.
16) Use dedicated Integration Service hosts for large domain data collection, for example vSphere,
remote operating system monitoring and other large sources of data.
17) Install Integration Service hosts close to the data sources that they process data for. Deploy by
geography, department, business, or applications especially if multiple Integration Services are
required from a single source.
18) Do not collect excessive or unnecessary performance data. Review the need for lower polling
intervals considering server performance and database size.
19) Do not collect trends for Availability metrics
Page 16 of 47
Page 17 of 47
Page 18 of 47
The diagram below illustrates the default ports on which connections are made regarding
communications from the PATROL agents through the Integration Service process to the BPPM Server
for the BPPM 9.5 solution components. The direction of the arrows indicates the connection requests.
Please review the product documentation for further details.
BPPM Server
Admin Cell
Port 1827
Jserver
CMA
TCP
Event Cell
Agent Controller
Port 12123
TCP
Port 1828
TCP
TCP
TCP
Integration Service
Node
Event Cell
Port 1828
TCP
Integration Service
Port 12124
Port 3183
TCP
Port 3181
Knowledge Modules
TCP
Managed Node
PATROL Agent
Port 3181
Legend Key
Knowledge Modules
3) The Monitor the Monitor (MTM) KM does not discover and monitor the BPPM 9.5 Integration
Service and should not be used with the BPPM 9.5 Integration Service. The built-in self
monitoring is significantly enhanced with BPPM 9.5 and the MTM KM is no longer needed.
However, the PATROL Agent and Operating System KMs should be used for additional self
monitoring and this is recommended.
Administration & PATROL Consoles
The diagram below illustrates the ports and connections related to the BPPM Administration and
PATROL Consoles.
BPPM Server
Admin Cell
Port 1827
Jserver
CMA
TCP
BEM Cell
Agent Controller
Port 12123
Port 1828
TCP
TCP
TCP
BEM Cell
Port 1828
TCP
Integration Service
Port 12124
Port 3183
TCP
TCP
Port 2059
TCP
TCP
PATROL Console
Server
TCP
PATROL Console
Node
PATROL Central
Windows
Managed Node
PATROL Agent
PCM
TCP
PATROL Classic
Console
Port 3181
Legend Key
Knowledge Modules
An instance of the BPPM Administration console should always be installed on a separate machine from
the BPPM Server. An instance of the BPPM Administration console is installed on the BPPM Server by
default. This instance of the BPPM Administration console should only be used in an emergency if
another instance is not available.
Page 20 of 47
Page 21 of 47
The diagram below illustrates the connections between the BPPM Administration Console and other
BPPM solution components. The ports listed are default ports and the arrows indicate the direction of
the connection requests.
BPPM Java
Administration
Console
TCP
Port 1828
Port 1099
BEM Cell
RMI
Registry
TCP
TCP
TCP
TCP
TCP
Port 12128
Port 3084
Port 1828
Port 1827
Jserver
IAS
BEM Cell
Admin Cell
BPPM Server
Page 22 of 47
Page 23 of 47
Central BPPM
Server with CMA
Policies
Data & Events
Data
Events
Direction of arrows indicates
connection requests.
QA
BPPM Server
Staging
Integration
Host
New Deployed
PATROL Agent
QA
Integration
Host
PATROL Agent
monitoring
Test
BPPM Server
Production
BPPM Server N
Production
Integration
Host N
Test
Integration
Host
PATROL Agent
monitoring
PATROL Agent
monitoring
Production
BPPM Server N+1
Production
Integration
Host N+1
PATROL Agent
monitoring
With the Single CMA Architecture a single Staging Integration Service node is used in the agent
deployment process for all agents. All BPPM Servers leverage the single CMA instance for all policy
management
Page 24 of 47
Development
BPPM
Child Server
Staging
Integration
Service
New Deployed
PATROL Agent
(Development)
Production
BPPM
Child Server N+1
Development
BPPM
Child Server
Development
Integration
Service
Development
PATROL Agents
Production Central
BPPM Server
With CMA
Test Central
BPPM Server
With CMA
Staging
Integration
Service
New Deployed
PATROL Agent
(Test)
Development
Integration
Service
Test PATROL
Agents
Production
BPPM
Child Server N
Staging
Integration
Service
New Deployed
PATROL Agent
(Test)
Production
Integration
Service N+1
Production
Integration
Service N
Production
PATROL Agents
Production
PATROL Agents
Legend Key
Policies
Data & Events
Data
Events
Direction of arrows indicates
connection requests.
With this architecture each environment has its own dedicated CMA instance and Staging Integration
Service. All policy application between environments is supported by the policy export/import utility.
Standalone BPPM Servers & CMA
In most multiple BPPM Server environments the CMA module will be installed with a Central BPPM
Server. However, it is possible to install CMA with a stand-alone BPPM Server and then manually
register the additional BPPM Servers with CMA after the install.
The following are reasons for installing CMA on stand-alone BPPM Servers and not leveraging the
Central Server capability.
1) The top tier BPPM Server is only needed to provide an enterprise event console.
Page 25 of 47
Web Services
Port 80 / 443
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
Port 8093
Agent
Controller
Port 8093
Web Services
Port 12123
Agent
Controller
Web Services
Port 80 / 443
Port 80 / 443
Port 12123
TCP
TCP
Integration Service
Port 12124
Integration Service
Port 3183
Port 3183
Port 12124
TCP
Managed Host
TCP
PATROL Agent
Managed Host
PATROL Agent
Port 3181
Port 3181
Knowledge Modules
Knowledge Modules
The detailed architecture above applies to both the Single CMA Architecture and the Multiple CMA
Architecture.
Page 26 of 47
Integration Service policies are the only CMA policies that are applied through a Staging Integration
Service. Monitoring policies are not applied though a Staging Integration Service. Additionally, Staging
Integration Service policies in CMA are only applied through a Staging Integration Service instance.
The architecture of network connections (communication protocol, ports, etc) between the Staging
Integration Service, PATROL Agents, and the BPPM Server are technically the same as with other
Integration Service instances.
The following are best practices for Staging Integration Service nodes.
1) Do not attempt to configure agents so that performance data and/or events are sent to a
Staging Integration Service.
2) Staging Integration Services must not be mixed with Data Collection Integration Services. They
must be configured, used, and managed separately from Data Collection Integration Services.
3) Configure the Integration Service on the BPPM Server as a Staging Integration Service. Do not
use it for data collection.
4) If firewall rules and security prevent using the Integration Service on the BPPM Server as a
Staging Integration Service, deploy a Staging Integration Service into the managed zone or zones.
5) Setup a single Staging Integration Service for each environment, for example one for
Development, one for Test, and one for Production. Or, if you have a single CMA instance for all
environments, setup a single Staging Integration Service for the entire implementation when
possible.
6) Consider high availability for Staging Integration Services. Refer to the High Availability section
for more information.
Page 28 of 47
Staging
Integration
Service
New Deployed
PATROL Agent
General
Integration
Service
PATROL Agent
general monitoring
Domain
Integration
Service
Dedicated PATROL
Agent & IS nodes for
domain monitoring
The diagram above illustrates there different Integration Service nodes and how they are used as follows.
1) The Staging Integration Service is used strictly for introducing new agents to the BPPM Server.
(An Integration Service has to be configured to work as a Staging Integration Service.)
2) The General Integration Service is used for collecting data from various deployments of PATROL
agents that are installed locally on the managed nodes. The term General is a description of
how the Integration Service is used and is not a configuration.
3) The Domain Integration Service is used for collecting data from PATROL Agents that provide
large volumes of data from a single source. Examples are VMware vCenter, PATROL Remote
Operating System Monitoring, NetApp, etc. The term Domain is a description of how the
Integration Service is used and is not a configuration.
The agent introduction process works as follows. A newly deployed PATROL Agent silent install package
is installed as shown above. The install package for the PATROL Agent contains configuration data
telling the PATROL Agent how to connect to the Staging Integration Service. When the new agent starts
for the first time, it registers with CMA through the Staging Integration Service. CMA then applies a
Page 29 of 47
Staging
Integration
Service
New Deployed
PATROL Agent
General
Integration
Service
PATROL Agent
local monitoring
Domain
Integration
Service
Dedicated PATROL
Agent & IS nodes for
domain monitoring
After receiving the Staging policy, the newly deployed agent switches to the data collection Integration
Service node (or Integration Service cluster) defined in the Staging policy. (The switch is represented by
the blue arrow in the diagram above.) The agent then receives any monitoring polices defined in CMA
that match each Monitoring policys agent selection criteria.
Page 30 of 47
Staging
Integration
Service
General
Integration
Service
PATROL Agent
local monitoring
Domain
Integration
Service
Dedicated PATROL
Agent & IS nodes for
domain monitoring
The agent starts monitoring and continues to receive any updates to existing monitoring policies and
new monitoring policies that match the monitoring policys agent selection criteria.
NOTE: Agents do not move from Development to Test, and then to Production. All agents should first
check in with the appropriate Staging Integration Service, then move to their data collection Integration
Service. This supports the concept of creating install packages for Development and Test only, separate
from Production. This topic is discussed further in the BPPM 9.5 Configuration Best Practices.
Page 31 of 47
Central BPPM
Server with CMA
Policies
Data & Events
Data
Events
Direction of arrows indicates
connection requests.
Development
BPPM Server
Staging
Integration
Host
New Deployed
PATROL Agent
Development
Integration
Host
PATROL Agent
monitoring
Test
BPPM Server
Production
BPPM Server N
Production
Integration
Host N
Test
Integration
Host
PATROL Agent
monitoring
PATROL Agent
monitoring
Production
BPPM Server N+1
Production
Integration
Host N+1
PATROL Agent
monitoring
All policies include agent selection criteria that allow you to completely control what policies are applied
to any and all PATROL Agents across the entire environment spanning Development, Test and
Production. This allows you to install a single CMA instance for the entire environment, and it
eliminates the need to recreate policies in production after they have been created in development and
tested, etc. One or more of the following agent assignment configurations in the policies is defined and
edited to accomplish this.
1) BPPM Server that the agent is assigned to (Best Practice)
2) Integration Service that the agent is assigned to
3) A tag defined in the agent configuration
Page 32 of 47
Simply add the Test and Production BPPM Servers to the policy agent selection criteria when you are
ready to apply the policy to those environments. This simplifies the process of moving configuration
from QA to Test, and finally to Production. It also ensures a policy is not applied to any agents in
production until it has been tested and validated.
The following outlines the process as an example referencing the screen shot above.
Phase 1 Only the BPPM Server named BPPMRHEL62-HM-QA is included in the agent
selection criteria when the policy is first created.
Phase 2 The BPPM Server named BPPMRHEL62-HM-TEST is added to the agent selection
criteria with an OR after the policy has been validated in QA.
Page 33 of 47
WARNING: At least one BPPM Server must be included in the agent selection criteria in order to control
which BPPM Server environment(s) the policy is applied to. If you do not include at least one BPPM
Server the policy will be applied to all agents, across all BPPM Servers that match the agent selection
criteria of the policy. Additionally the multiple BPPM Server values must be grouped () and related with
a Boolean OR as shown above. If you use a Boolean AND to relate the agent selection criterion the
policy will not be applied because an agent cannot register with multiple BPPM Servers.
WARNING: leveraging the BPPM Servers in agent selection criteria is powerful and has far reaching,
global implications. If you mistakenly add a production BPPM Server to the agent selection criteria for a
policy the policy could be unintentionally applied to 100s or 1000s of agents in production. Therefore it
is extremely important that this process be managed carefully.
IMPORTANT: Updates and deletion of existing policies will apply to all agents that the policys agent
selection criteria match. Consequently it is not possible to test edits to policies that currently apply to
production without impacting production using the process outlined above. Separate policies should be
created to test edits in the development and test environments leveraging the export/import utility.
The details of this topic are discussed in the configuration best practices.
Leveraging tags in policies can also be used to further control what agents policies are applied to. Tags
should be used to provide a second level of protection to prevent policies still in development or test
from being applied to production accidentally. Leveraging tags this way forces the user to not only add
the appropriate BPPM Server to the policy selection criteria, but they also have to add the appropriate
tag. This helps prevent the user from accidently picking the production BPPM Server and saving the
policy when they did not mean to. Additionally, tags can be used to provide greater granularity for
policy assignment where the other agent selection criteria is not enough.
BMC recommends leveraging precedence in policies so that production policies have the highest
precedence and will not be superseded by development or test policies. If you follow this
recommendation you will also have to adjust the policy precedence when you want to move it from
development to test, and finally from test to production.
The configuration topics above are discussed further in the BPPM 9.5 Configuration Best Practices.
Page 34 of 47
Development
BPPM
Child Server
Staging
Integration
Service
New Deployed
PATROL Agent
(Development)
Development
Integration
Service
Development
PATROL Agents
Production Central
BPPM Server
With CMA
Test Central
BPPM Server
With CMA
Production
BPPM
Child Server N+1
Development
BPPM
Child Server
Staging
Integration
Service
New Deployed
PATROL Agent
(Test)
Development
Integration
Service
Test PATROL
Agents
Production
BPPM
Child Server N
Staging
Integration
Service
New Deployed
PATROL Agent
(Test)
Production
Integration
Service N+1
Production
Integration
Service N
Production
PATROL Agents
Production
PATROL Agents
Legend Key
Policies
Data & Events
Data
Events
Direction of arrows indicates
connection requests.
In a multiple CMA instance deployment there is no need to specify BPPM Servers in the agent selection
criteria for Development and Test environments. This is not needed because the environments are
completely separated and do not share a common CMA instance with Production.
Page 35 of 47
Page 36 of 47
Interoperability
1) In order to leverage all new functionality in BPPM 9.5, PATROL Agent version 9.5.00i or higher
must be used.
2) The BPPM 9.5 Integration Service can only communicate with PATROL Agent versions 9.5.00i or
higher. Older versions of agents are denied access if a connection is attempted. A
corresponding event is generated when this happens.
3) BPPM version 9.0.00 SP1 and 8.6.02 SP3 Integration Services can operate with BPPM 9.5 Servers.
The usage of 9.0.00 SP1 and 8.6.02 SP3 Integration Services in a BPPM 9.5 environment should
be limited to upgrade and migration scenarios where no other method is feasible.
4) The BPPM 9.5 Server and administration console must be manually configured to support 9.0.00
SP1 and 8.6.02 SP3 Integration Services if a fresh install is done.
5) When a BPPM Server 9.0.00 SP1 or 8.6.02 SP3 is upgraded the same version Integration Service
nodes are readily supported. Architecture specific to version 9.0.00 SP1 and 8.6.02 SP3
components is not included in this document. Please review BPPM 9.0.00 SP1 and 8.6.02 SP3
documentation and related version Best Practices for that information.
6) Integration Services older than 9.0.00 SP1 and 8.6.02 SP3 cannot interoperate with BPPM 9.5.
7) A PATROL Agent v9.5 can be connected to a v9.0.00 SP1 or 8.6.02 SP3 Integration Service if the
PATROL Agent is Polled for data via a p3adapter profile in the pproxy configured for the
Integration Service. Streaming under this scenario is not allowed. Do not use this method in a
9.5 BPPM Server environment. Use this capability only in a 9.0 or 8.6 BPPM Server environment
where agents are already polled by the p3adapter. Although the preceding is possible, it should
generally be avoided.
8) A PATROL Agent v9.5 will be denied connection to older Integration Service versions if streaming
with the SA adapter configuration is attempted.
9) BPPM 9.5 can process events that are propagated from previous versions of the event
management cells. In some cases this may require configuration to support customizations
and/or specific event content and processing.
10) Mixed versions of BPPM Servers are discouraged in a single environment. However events from
different versions can be propagated between versions. Integration with CMA and integration
across service models in BPPM 9.5 with older BPPM Servers versions should be avoided.
11) Consider the following regarding Intelligent Ticket integration with BMC Remedy ITSM.
a. There are two major parts of the Intelligent Ticketing 2.0 patch
i. BPPM updates
Page 37 of 47
Page 38 of 47
High Availability
The diagram below illustrates overall High Availability architecture to support fault tolerance for the
core BPPM 9.5 components.
Central BPPM Server
with CMA
Production BPPM Server
OS Cluster - Active/Passive
Test/QA/DEV
BPPM Server
Legend Key
Configuration
Data & Events
Data
Events
Direction of arrows indicates
connection requests.
Page 39 of 47
Page 40 of 47
PATROL Agents HA
PATROL Agents running on the managed node that they are monitoring generally do not require high
availability. However PATROL Agents that monitor large domain sources such as vSphere or remote
operating system monitoring require high availability configurations in most environments. High
availability for the PATROL Agent is supported with operating system clustering, or other 3rd party
solutions like VMware HA.
Page 41 of 47
Page 42 of 47
The above values are all independent. If you reach one of these values in a single BPPM Server instance
you should consider that you have reached maximum capacity for that BPPM Server instance.
This sizing is for a 64-bit host with 8 CPUs and 32 Gig of RAM.
Do not try to exceed 250,000 monitor instances or 1,700,000 attributes on a single BPPM Server host.
Additional CPU and memory does not help to scale beyond these values.
In some environments the BPPM 9.5 database will require more storage space than previous versions.
This is due to the increased performance data collection rate. In previous versions performance data
was collected once every 5 minutes by default. In BPPM 9.5 PATROL agent collected data is streamed to
the BPPM Server and many of the parameters are collected every minute. You should allocate 600 GB
of storage (100 GB for the server + 500 GB for the database) in a large implementation.
Please refer to the documentation for additional details.
Integration Service Node Sizing Overview
A single large BPPM 9.5 Integration Service host will scale to support the following maximum values.
This includes the Integration Service process and the event management cell.
8) Data for 1.7 Million performance parameters
9) 900 PATROL Agents
10) 250,000 monitored instances
Page 43 of 47
Do not collect unnecessary data at the PATROL Agents. Configure monitoring in the order listed.
1) Do not configure or otherwise enable KMs for monitoring that are not needed. This applies to
entire KMs and application classes in KMs that are not needed. This has the biggest impact on
reducing unnecessary data.
2) Do not propagate performance data to the BPPM Server that is not needed in the BPPM Server.
Leverage the ability to visualize trended data from PATROL in the BPPM web console without
having to store it in the BPPM database for parameters that are not required in BPPM Reporting
and that do not require baselines and baseline related capabilities.
3) Leverage instance filtering in the monitoring policies so that only the instances that need to be
monitored will send performance data to the BPPM Server.
4) Leverage parameter performance and event data filtering in the monitoring policies so that only
the parameters that need to be monitored will send performance data or events to the BPPM
Server.
5) Reduce data collection frequency for collectors in the PATROL KMs when possible.
Do not send events to the BPPM Server for performance data for PATROL parameters that you are also
sending performance data. If the performance data for a parameter is sent to the BPPM Server events
for that parameter should be generated in the BPPM Server. This will eliminate unnecessary events.
Do not propagate unnecessary events from PATROL or any other source to the remote cells or to the
BPPM Server. Filter events at the source when possible.
Page 44 of 47
Raw data retention should be reduced to 3 days in large environment when acceptable (the default is 8
days). Reducing the raw data to three days will reduce the size of the database with no impact to
baselines and their calculations.
Do not store more raw data than necessary according to business and IT process requirements. If you
are changing this setting after having already collected and retained 8 or more days of raw data there
will be an initial one time, nominal impact to performance on the BPPM Server as old data is pruned. If
you are concerned about this you can reduce the raw data retention in increments until you get it down
to 3 days.
Store raw data in BPPM Reporting separately for longer periods of time.
Do not reduce raw data retention in the BPPM Server to less than 3 days.
Do not extend raw data retention in the BPPM Server to more than 8 days.
Reporting in the BPPM Server
The following are best practices for reports generated within the BPPM Server and are not related to
BPPM Reporting.
The number of reports generated in the BPPM Server should be kept to a minimum.
The number of reports viewed by multiple concurrent users in the BPPM Server should be kept to a
minimum.
Historical reports should be configured in BPPM Reporting, instead of the BPPM Server.
Page 45 of 47
Implementation Order
The following is the general recommended, high-level implementation order for the BPPM 9.5 core
components. Note that this has changed from previous releases. These steps are primarily for a fresh
install.
1) Install the BPPM Central server(s).
2) Install the BPPM Child server(s).
3) Install the BPPM Administration console on desktop node(s).
4) Install the Integration Service node(s) with event management cell(s).
5) Connect the Integration Service nodes to the BPPM Server(s) in the CMA console(s).
6) Configure the appropriate Integration Service nodes as Staging Integration Services including the
one(s) on the BPPM Server(s).
7) Configure Integration Service Clusters in the CMA console. Do not do this as part of step 5
above while you are connecting the Integration Service nodes to the BPPM Server(s).
8) Create agent/KM silent install packages for PATROL agents and Knowledge Modules in the CMA
Monitoring Repository, but do not deploy them to Production at this point in the process.
9) Create separate Staging policies for the BPPM Development, BPPM Test, and BPPM Production
environments that are assigned to the appropriate Integration Service instances.
10) Create monitoring policies to be tested in Development.
11) Create/configure event management policies and rules to be tested in Development.
12) Deploy the agent/KM silent install packages to Development/Test managed servers.
13) Validate the silent install packages, monitoring policies and event management configuration in
the Development/Test environments including all desired data collection and event
management processing.
14) Promote the validated monitoring policies and event management configuration into
Production.
15) Deploy the validated agent/KM silent install packages to Production servers.
16) Enable the monitoring policies in Production and verify proper functionality.
Page 46 of 47
The above processes cannot be installed separately from the BPPM Server.
Troubleshooting
Please see product documentation at the following URL for troubleshooting information.
https://docs.bmc.com/docs/display/proactivenet95/Troubleshooting
Page 47 of 47