Page tree

Unsupported content

 

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Skip to end of metadata
Go to start of metadata

This section provides an overview of sizing information for BMC ProactiveNet 9.5. It does not provide comprehensive details on sizing. For information about scalability and sizing details, see Performance and scalability recommendations.

BMC ProactiveNet Server sizing overview

A single large BMC ProactiveNet Server host computer in version 9.5 scales to support the following maximum values. The values include all processes and the event management cell.

Data for 1.7 Million performance parameters

  • 20,000 devices
  • 250,000 monitored instances
  • 3 days of raw data
  • 3 months of rate data
  • 40,000 intelligent events per day
  • 350,000 external events per day

These values are all independent. If you attain any of these values in a single BMC ProactiveNet Server instance, you must consider that you have reached the maximum capacity for that server instance. This sizing is for a 64-bit host with 8 CPUs and 32 GB of RAM. Do not try to exceed 250,000 monitor instances or 1,700,000 attributes on a single BMC ProactiveNet Server host. Additional CPU and memory do not help to scale beyond these values.

In some environments, the BMC ProactiveNet 9.5 database requires more storage space than previous versions. This is because of the increased rate of performance data collection. In earlier BMC ProactiveNet versions, performance data was collected every 5 minutes by default. In BMC ProactiveNet 9.5, the data collected by the BMC PATROL Agent is streamed to the BMC ProactiveNet Server and many parameters are collected every minute. You must allocate 600 GB of storage (100 GB for the BMC ProactiveNet Server + 500 GB for the database) in a large implementation.

Integration Service sizing overview

A single large BMC ProactiveNet Integration Service 9.5 host scales to support the following maximum values. These values include the Integration Service and the event management cell.

  • Data for 1.7 million performance parameters
  • 900 PATROL Agents
  • 250,000 monitored instances
  • 25 events per second

These values are all independent. If you attain one of these values in a single Integration Service instance, consider that you have reached the maximum capacity for that BMC ProactiveNet Server instance. A 64-bit Integration Service host with 2 CPUs and 2 GB RAM can scale up to 500 PATROL Agents. A 64-bit Integration Service host with 4 CPUs and 8 GB RAM can scale up to 900 PATROL Agents Do not try to exceed 250,000 monitor instances and 1,700,000 attributes on a single Integration Service host. Additional CPU and memory do not help to scale beyond these values.

Configuring for scalability

This section lists the best practices to be used when configuring scalability on BMC ProactiveNet components.

Performance data and event processing

  • Do not collect unnecessary data from the PATROL Agents. Configure monitoring in the following order:
    • Do not configure or otherwise enable KMs that are not needed for monitoring. This applies to the KMs and the application classes in the KMs. This has the biggest impact on reducing unnecessary data.
    • Do not propagate performance data that is not needed to the BMC ProactiveNet Server. Leverage the ability to visualize trended data from BMC PATROL in the BMC ProactiveNet Operations Console without having to store it in the BMC ProactiveNet database for parameters that:
      • Are not required in BMC ProactiveNet Performance Management Reporting
      • Do not require baselines and baseline related capabilities
    • Leverage instance filtering in the monitoring policies so that only those instances that need to be monitored send performance data to the BMC ProactiveNet Server.
    • Leverage parameter performance and event data filtering in the monitoring policies so that only those parameters that need to be monitored send performance data or events to the BMC ProactiveNet Server.
    • Reduce the frequency of data collection for collectors in the PATROL KMs when possible. 
  • Do not send performance data events to the BMC ProactiveNet Server for those BMC PATROL parameters to which also you are sending performance data. If the performance data for a parameter is sent to the BMC ProactiveNet Server, events for that parameter must be generated in the BMC ProactiveNet Server. This eliminates unnecessary events.
  • Do not propagate unnecessary events from BMC PATROL or any other source to the remote cells or to the BMC ProactiveNet Server. Filter events at the source when possible.
  • Filter events in the lowest tier event management cells when filtering is not possible at the event source(s).
  • Configure basic event processing such as filtering, enrichment, timers, auto closure, and all other event processing that can be instrumented at the lower tier event management cells as much as possible. This reduces the event processing load on the BMC ProactiveNet Server and improves scalability as well as the startup time of the BMC ProactiveNet Server.
  • Implement the event management cell configured for correlation as a middle tier event processing layer between the remote event management cells and the BMC ProactiveNet Server. This offloads event correlation from the BMC ProactiveNet Server and helps further reduce the volume of events processed by the BMC ProactiveNet Server.

Data retention

  • Reduce raw data retention to 3 days in a large environment when acceptable (the default is 8 days). Reducing the raw data to 3 days reduces 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 a one-time nominal impact to performance on the BMC ProactiveNet Server as the 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 BMC ProactiveNet Performance Management Reporting separately for longer periods of time.
  • Do not reduce raw data retention in the BMC ProactiveNet Server to less than 3 days.
  • Do not extend raw data retention in the BM C ProactiveNetServer to more than 8 days.

Reporting in the BMC ProactiveNet Server

The following are the best practices for reports generated in BMC ProactiveNet. They are not related to BMC ProactiveNet Performance Management Reporting. 

The number of reports generated in the BMC ProactiveNet Server must be kept to a minimum.

The number of reports viewed by multiple concurrent users in the BMC ProactiveNet Server must be kept to a minimum.

Historical reports must be configured in BMC ProactiveNet Performance Management Reporting, instead of the BMC ProactiveNet Server.

Implementation order

The following is the recommended high-level implementation order for the BMC ProactiveNet core components in version 9.5. Note that this has changed from earlier releases. These steps are primarily for a fresh install.

  1. Install the BMC ProactiveNet Central Server(s).
  2. Install the BMC ProactiveNet Child Server(s).
  3. Install the BMC ProactiveNet 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 BMC ProactiveNet Server(s) using BMC ProactiveNet Central Monitoring Administration.
  6. Configure the appropriate Integration Service nodes as staging Integration Services including the one(s) on the BMC ProactiveNet Server(s).
  7. Configure Integration Service clusters in Central Monitoring Administration. Do not do this as part of step 5 when you are connecting the Integration Service nodes to the BMC ProactiveNet Server(s).
  8. Create PATROL Agent/KM silent installation packages for PATROL Agents and KMs in the Central Monitoring Administration repository, but do not deploy them to production at this point in the process.
  9. Create separate staging policies for the BMC ProactiveNet development, test, and production environments assigned to the appropriate Integration Service instances.
  10. Create monitoring policies to be tested in the development environment.
  11. Create/configure event management policies and rules to be tested in the development environment.
  12. Deploy agent/KM silent installation packages to development/test managed servers.
  13. Validate the silent installation packages, monitoring policies, and event management configuration in the development/test environments including all the required data collection and event management processing.
  14. Promote the validated monitoring policies and event management configuration to production.
  15. Deploy the validated agent/KM silent installation packages to the production servers.
  16. Enable monitoring policies in production and verify the proper functionality.

Components and dedicated servers

The table below lists the components of the BMC ProactiveNet Performance Management solution and shows which components must be installed on dedicated servers.

Component

Dedicated or Shared Server

BMC ProactiveNet Server

Dedicated

Oracle database

Installed on a server dedicated to Oracle databases

Sybase database

Installed as part of the BMC ProactiveNet Server

Integration for BMC Remedy Service Desk

Installed as part of the BMC ProactiveNet Server

Integration Service host+

Dedicated server for event and data integration processes

Integration Service

Shared on an Integration Service host computer

Impact Integration Web Services (optional)

Shared on an Integration Service host computer

Remote event management cell

Shared on an Integration Service host computer

BMC Event Adapters

Shared on an Integration Service host computer

BMC PATROL Agents for remote monitoring++

Dedicated

PATROL RT Server (optional)**

Shared on an Integration Service host computer

PATROL Console Server (optional)**

Dedicated

PATROL Central Web Console (optional)**

Dedicated

+ The Integration Service host is not an installable component. It is a server dedicated to middle tier data and event collection processes.

++ PATROL Agents for remote monitoring include solutions for remote operating system monitoring, VMware vSphere, and other domains that involve larger amounts of data collected by a single agent.

** BMC PATROL components that are marked optional must not be used in most production environments.

The BMC ProactiveNet Server contains multiple processes including the following:

  • Apache web server
  • JBOSS application server
  • Embedded event management cell
  • Agent Controller
  • Rate process
  • Additional application server processes

These processes cannot be installed separately from the BMC ProactiveNet Server.

Related topics

Data collection and event management deployment

Event and impact management deployment

Recommendations based on internal testing

Troubleshooting

  • No labels