Escolar Documentos
Profissional Documentos
Cultura Documentos
BMC Software has released version 8.6 of the BMC ProactiveNet product. This document provides information about optimizing performance and server sizing the BMC ProactiveNet in your environment. This information supplements and supersedes information in the product documents.
NOTE
Details about recent patches or PTFs for this product are available from the BMC Software Customer Support website at http://www.bmc.com/support_home. Before installation, BMC Software recommends that you check the website to determine whether patches are available for this product.
This document contains the following topics: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Deployment Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Sizing a BMC ProactiveNet environment for data collection . . . . . . . . . . . . . . . . . . 4 Additional guidelines for a data collection environment . . . . . . . . . . . . . . . . . . . . . 8 Adapter data collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Hardware requirements for BMC ProactiveNet server . . . . . . . . . . . . . . . . . . . . . . 12 Hardware requirements for Business Objects reporting . . . . . . . . . . . . . . . . . . . . . 13 Hardware requirements for Remote Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Hardware requirements for Oracle Database Server . . . . . . . . . . . . . . . . . . . . . . . . 14 Oracle Database tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Data management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Data management sizing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Data management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Data management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 BMC ProactiveNet Server Bandwidth Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Time consumed by different functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Event management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Event management sizing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Event management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Event management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 *204678* *204678*
*204678*
Time consumed by different functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact Management sizing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact Management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact Management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time consumed by different functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommended AR configuration settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommended AR System Mid-Tier configuration settings . . . . . . . . . . . . . . . . . Recommended AR Application Server configuration settings. . . . . . . . . . . . . . . . Hybrid management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hybrid management sizing recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hybrid management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hybrid management tuning recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cloud management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cloud management sizing recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cloud Management hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements for Servers in Cloud Management . . . . . . . . . . . . . . . . . Cloud Management sizing chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Center details used for monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reports Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component performance and tuning recommendations. . . . . . . . . . . . . . . . . . . . . . . . Disk subsystems and database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPU guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration and deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tested environment for concurrent users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frequently asked questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where to view the latest product information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32 35 35 38 39 40 41 42 47 51 51 54 55 57 58 62 62 63 65 66 66 67 68 70 70 70 71 72 73 76
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
Introduction
Introduction
BMC Software has released version 8.6 of the BMC ProactiveNet product. This document contains guidelines and recommendations to help you size an environment and identify the appropriate architecture and hardware for BMC ProactiveNet deployments.
All information provided is based on controlled, internal testing of BMC ProactiveNet version 8.6 to ensure optimum performance.
In general, the performance of a single BMC ProactiveNet server depends on several variables. Substantial changes in any of these variables could change the expected scaling and performance numbers. Those variables are:
The size of the server. The type of devices monitored. The number of adapters and monitors on each agent. The polling frequency. The number of concurrent users. The number of external events per day. The number of alarms and abnormalities per day.
NOTE
Do not use 32-bit hardware to deploy BMC ProactiveNet server. BMC strongly recommends using 64-bit hardware to deploy BMC ProactiveNet server. If you are an upgrade user and using 32-bit hardware, BMC strongly recommends upgrading to 64-bit hardware. No performance or scalability testing is performed on 32-bit hardware.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
WARNING
BMC ProactiveNet can use the Sybase database or Oracle database in any deployment.
The embedded database (Sybase Adaptive Server Anywhere or Sybase ASA) that must run on the same system as the core server components. The embedded database is optimized for BMC ProactiveNet. The Oracle database must be installed in different systems with the same subnet network.
NOTE
Open the BMC Administration Console or Operations Console on a system different from the system on which the BMC ProactiveNet Server is running. Both these systems must be running on the same network.
Sizing using BMC PATROL Performance Manager Determining the BMC ProactiveNet architecture size required for your environment Determining the number of BMC ProactiveNet Agents and Servers required for your environment
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
Sample Scenario
Determine the system to monitor
Determine what you want to monitor in your environment, and then select the applicable Performance Managers. This scenario monitors the following systems using the following Performance Managers:
PATROL for UNIX and Linux PATROL for Microsoft Windows Servers
PATROL for UNIX and Linux: 7000 PATROL for Microsoft Windows Servers: 5300
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
Table 1
The total number of attributes in sample scenario 1 using BMC PATROL for data collection
Instances 7000 5300 12,300 Attributes per device 75 180 255 Estimated attributes 220,000 580,000 800,000
BMC Performance Managers PATROL for UNIX and Linux PATROL for Microsoft Windows Totals
Determining the BMC ProactiveNet architecture size required for your environment
Deployments of BMC ProactiveNet are categorized, based on their total attributes, as small, medium, or large. For information about the number of computers and hardware requirements for each deployment size, see Hardware requirements on page 12. Some additional variables can affect the size of the architecture. By default, the average polling rate is 5 minutes. For example, an average polling rate of 2 minutes for all monitors could double the attribute estimates. These variables are listed as special considerations in Deployment Configuration Guidelines on page 4. If you have an environment that performs external event management, with or without data collection, the architecture size is affected. For external event management recommendations see Event management sizing recommendations on page 26, and Hybrid management sizing recommendations on page 51.
Determining the number of BMC ProactiveNet Agents and Servers required for your environment
In this last step, you determine the number of BMC ProactiveNet remote agents for your environment. In this scenario BMC PATROL Adapters are used, this step is simplified a little. All monitors and attributes that are collected through an adapter have basically the same level of impact on any given agent and server. With BMC PATROL Adapters, a single 32-bit BMC ProactiveNet Agent can accommodate up to 125,000 attributes. There are many other variables that come into play that can lower or raise this limit (for example, poll frequency and hardware). A single 64-bit BMC ProactiveNet Agent for BMC PATROL Adapter can collect data for more than 125,000 attributes based on the memory (maxheap) allocated to this agent.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
Table 4 on page 8 summarizes the recommendation for 64-bit BMC ProactiveNet Agent. To estimate the number of 32-bit BMC ProactiveNet Agents required (for 5 minutes stats polling), divide the total number of attributes by 125,000 (and round up). To estimate the number of 64-bit BMC ProactiveNet Agents required (for 2 or 5 minutes stats polling), divide the total number of attributes by 800,000 (and round up). The assumption here is each agent has 8 GB RAM for it.
Monitor type Number of attributes (Polling Interval: 5 minutes stats poll and 15 minutes auto-sync)
125,000
125,000
50,000
45,000
Platform: Windows 2008 R2 (32-bit or 64-bit), Intel Core i7, 2 Core, 2 GB RAM, 3.067 GHz Frequency, 2400 MHz Bus-speed
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
Table 4
NOTE
The 800,000 attributes monitored through PATROL Agents were from static KMs and with KPI mode.
Platform: Windows 2008 R2 (64-bit), Intel Core i7, 2 Core, 2 GB RAM, 3.067 GHz Frequency, 2400 MHz Bus-speed The limits shown above can be used for rough estimates but do not necessarily give all the information required for sizing. You must also consider all the factors, for example:
WARNING
If you reduce the polling interval to less than the recommended values, it may put heavy load on the CPUs of the BMC ProactiveNet servers. It may also result in restarting the remote BMC ProactiveNet Agent several times.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
Distributed locations
Independent of the limits of a BMC ProactiveNet Agent, the environment can require that you install a BMC ProactiveNet Agent on a separate machine. For example, it is best to install a BMC ProactiveNet Agent on every remote network where you are collecting data.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
The proxy can send data from multiple PATROL Agents to BMC ProactiveNet. Integration Service for PATROL is deployed on all the BMC ProactiveNet Agents. The adapters must be created on these agents. In a large environment multiple BMC ProactiveNet agents will be collecting data through 1 or more Integration Service for PATROL. It is recommended that Integration Service for PATROL be deployed in at least each different network where PATROL agents are located. It is also recommended to distribute PATROL agents on Integration Service for PATROL so that the load on the agents is not more than the suggested numbers. The BMC ProactiveNet Agent and Server connection can cross network boundaries because the BMC ProactiveNet Agent and Server connection supports more flexible connection options currently (TCP/IP, SSL, HTTP/S) than the proxy. Integration Service for PATROL is highly scalable. A single Integration Service for PATROL can collect data from 1000 PATROL Agents. Data collection was successful in BMC ProactiveNet environment with 1000 PATROL Agents and each agent collecting approximately 850 attributes. In this scenario, the Integration Service for PATROL was deployed with a dedicated 64bit BMC ProactiveNet agent. Minimize the number of Integration Service for PATROL that are used to collect data from PATROL agents. This can be accomplished by using 64-bit BMC ProactiveNet agent that has good hardware configuration (16 GB RAM and 8 CPU). To configure automated workflow, see the BMC ProactiveNet Administrator Guide. Use the following guidelines when using Integration Service for PATROL:
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
10
Do not exceed 800 K attributes per Integration Service for PATROL while using 64-bit BMC ProactiveNet agent. Allocate a separate Integration Service for PATROL to each remote network. For administration purpose the client computer (that runs administrations) should have access to the Integration Service for PATROL.
If the BMC ProactiveNet Agent that is running and controlling the Integration Service for PATROL is dedicated, it is easier to manage and size. However, it does not have to be dedicated in all cases. As an example, if BMC PATROL agents in a different network are collecting only 40,000 attributes, it is possible to use a single BMC ProactiveNet Agent to run both the adapter and the Integration Service for PATROL (as opposed to having two BMC ProactiveNet Agents located on two different hosts in the remote network). Figure 2 BMC PATROL Adapter environment
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
11
Hardware requirements
Hardware requirements
Hardware requirements for BMC ProactiveNet server
This section provides a summary of hardware requirements for BMC ProactiveNet server, to consider when determining the size of your environment for data management, event management, hybrid management (data collection and event management), and impact management.
WARNING
Do not use 32-bit hardware to deploy BMC ProactiveNet server. BMC strongly recommends using 64-bit hardware to deploy BMC ProactiveNet server. If you are an upgrade user and using 32-bit hardware, BMC strongly recommends upgrading to 64-bit hardware. No performance or scalability testing is performed on a 32-bit hardware.
Table 5
Hardware requirements for BMC ProactiveNet server in small, medium and large environments (part 1 of 2)
Data Management Event Management Hybrid Management Impact Management
Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 16 threads or equivalent SPARC Enterprise T-Series OR M-Series Servers, 2x4 Core, 3 GHz, UltraSPARC T2 and 32 threads or more 8 GB 4 GB 10 K SAS disk or SAN storage 8 GB 10 K SAS disk or SAN storage 8 GB 10 K SAS disk or SAN storage
Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 16 threads or equivalent SPARC Enterprise T-Series OR M-Series Servers, 2x4 Core, 3 GHz, UltraSPARC T2 and 32 threads or more 16 GB 8 GB 10 K SAS disk or SAN storage 16 GB 10 K SAS disk or SAN storage 16 GB 10 K SAS disk or SAN storage
LARGE ENVIRONMENT
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
12
Table 5
Hardware requirements for BMC ProactiveNet server in small, medium and large environments (part 2 of 2)
Data Management Event Management Hybrid Management Impact Management
Operating system
Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 16 threads or equivalent SPARC Enterprise T-Series OR M-Series Servers, 2x4 Core, 3 GHz, UltraSPARC T2 and 32 threads or more 32 GB 16 GB 32 GB 32 GB
Report Engine
Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 16 threads or equivalent 4 GB 80 GB Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production 4 GB 40 GB
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
13
Data Management SMALL ENVIRONMENT Operating system RAM Storage configuration MEDIUM ENVIRONMENT Operating system RAM Storage configuration LARGE ENVIRONMENT Operating system RAM Storage configuration
Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 16 threads or equivalent 4 GB 4 GB 10 K SAS disk or SAN storage
Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 16 threads or equivalent 8 GB 8 GB 10 K SAS disk or SAN storage
Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 16 threads or equivalent 8 GB 8 GB 10 K SAS disk or SAN storage
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
14
Table 8
Windows 2008 R2 (64-bit), Intel Core i7, 2x4 Core, 3.067 GHz Frequency, 2400 MHz Bus-speed and 8 threads or equivalent 16 GB 16 GB 16 GB 16 GB 16 GB
200 GB, 10 K SAS disk or SAN storage Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
15
Table 9
lter system set sga_max_size=0 scope=spfile alter system set memory_max_target=8192M scope=spfile alter system set memory_target=8192M scope=spfile
Reset sga_max_size to 0 Set memory to half of the system memory Ex: If system as 16 GB of RAM then set to memory_max_target=8192 M
Follow these steps to resize available REDO log files before BMC ProactiveNet installation start. Setting of REDO01 alter database add logfile group Inactive group number ('Path\Redo Filename Without Group NumberInactive group number.LOG') size 500m reuse; To avoid "cannot allocate new log," error For status of redo log file select group# , status from v$log; Setting of REDO02 alter database add logfile group Inactive group number ('Path\Redo Filename Without Group NumberInactive group number.LOG') size 500m reuse; To avoid "cannot allocate new log," Error For status of redo log file select group# , status from v$log;
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
16
Table 9
Setting of REDO03
select group# , status from v$log; alter system switch logfile; alter system switch logfile;
Status of one redo log file should be CURRENT, and other two should be ACTIVE Alter audit_trail and scope values Add CONNECT_TIMEOUT_LIS TENER = 0 in listener.ora file
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
17
Data management
Data management
BMC Knowledge Management (KM) collects data from different sources. Data management manages the data into features like dynamic base lining, intelligent thresholds, RCA, dynamic thresholds, prediction, and abnormality detection.
Small environment
A small BMC ProactiveNet data collection environment typically collects 50,000 or fewer attributes. In a very small environment, one that collects 25,000 or fewer attributes, you could use one server with a local agent acting as the data collector. When planning a small environment, consider the following guidelines:
If you use the BMC PATROL Adapter, install the Integration Service for PATROL on the agent. If you expect more than five concurrent users or if the average polling intervals are less than five minutes, use a medium architecture setup. If you collect data across networks or firewalls, consider using a remote agent to minimize the number of connections to manage across networks and firewalls. To improve I/O throughput, locate the operating system and database on separate disks, each with its own disk controllers.
Medium environment
A medium environment typically collects 50,000 to 400,000 attributes. Distributing the data collection to remote agents off-loads much of the performance to the collectors, and keeps the server dedicated to the primary server processes (analytical engine, object cache, and agent controller). The number of remote agent computers required depends on several factors, such as the total number of monitor instances extracted from the adapters, the topology of the network or location of firewalls (which can require proxy agents), and the size of the remote agent computers. When planning a medium environment, consider the following guidelines:
An agent does not require a dedicated physical machine. You can install multiple agents on a remote computer as long as 1 CPU and 2 GB of memory are allocated for each agent installed.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
18
A 64-bit agent can handle a higher number of attributes. You can deploy agents within a Virtual Machine (VM) as long as the VM meets the resource requirements. If you expect the total number of attributes for the environment to grow beyond 400,000 attributes, use a large-environment deployment so that the system can accommodate growth smoothly. If you use a BMC PATROL Adapter, install the Integration Service for PATROL on all the remote agents that are identified for creating the adapter. The local data collection agent residing on the BMC ProactiveNet Server collects metrics about only BMC ProactiveNet performance. BMC recommends that you tune the Java Virtual Machines (JVMs) as described in Tested environment for concurrent users on page 72.
Large environment
A large environment typically collects around 800,000 attributes. Distributing the data collection to remote agents off-loads much of the performance to the collectors so that the server can be dedicated to the primary server processes (analytical engine, object cache, and agent controller). The number of remote agent computers required depends on several factors, such as total number of monitor instances extracted from the adapters, the topology of the network or location of firewalls (which can require proxy agents), and the size of the remote agent computers. When planning a large environment, consider the following guidelines:
Configure each BMC ProactiveNet server so that it contains an entire line of business, rather than spreading the monitoring from any line of business or application across servers. An agent does not require a dedicated physical machine. You can install multiple agents on a remote computer as long as 1 CPU and 2 GB of memory are allocated for each agent. A 64-bit agent can handle a higher number of attributes when sufficient memory is allocated. You can deploy agents within a VM as long as the VM meets the resource requirements. If you use a BMC PATROL Adapter, install the Integration Service for PATROL on all the remote agents that are identified for creating the adapter. The data collection agent residing on the server collects metrics about only BMC ProactiveNet performance. BMC recommends that you tune the Java Virtual Machines (JVMs) as described in Tested environment for concurrent users on page 72.
19
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
20
NOTE
A 32-bit remote BMC ProactiveNet Agent can scale up to 125 K attributes for every 2 CPU/2 GB RAM. A 64-bit remote BMC ProactiveNet Agent can scale up to 800 K attributes for every 4 CPU/8 GB RAM.
Small: 2048 MB Medium: 6144 MB Large: 8192 MB Small: 2048 MB Medium: 4096 MB Large: 8192 MB Small: 1024 MB Medium: 1536 MB Large: 2048 MB Small: 512 MB Medium: 512 MB Large: 1024 MB Small: 1 G Medium: 2 G Large: 3 G Small: 1024 MB Medium: 2048 MB Large: 3072 MB
Pnrate.conf
Pnagentcntl.conf
Pnagent.conf
BMC ProactiveNet database server parameter COMDefine -c (Windows) setenv dbsrvicache (Solaris) Cell tuning parameters EventDBSize Mcell.conf The number of events Set it higher for a retained in repository. higher event rate. pndbsrv.conf Initial cache size of database server Initial cache size of database server
startdbsrv7
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
21
Table 11
StateBuildSize
Mcell.conf
Other tuning parameters pronet.apps.agent.age pronet.conf ntmon.agentstatusref reshperiod pronet.apps.agent.wa pronet.conf tchdog.sleeptime
Small: 45000 Medium: 90000 Large: 180000 Small: 30000 Medium: 60000 Large: 120000
pronet.jvm.maxthrea dlimit
pronet.conf
pronet.jserver.cachem pronet.conf odule.threadpool.max .size pronet.jserver.databa pronet.conf semodule.threadpool. max.size pronet.jserver.dbconn pronet.conf ectionpool.maxdbcon nectionsize
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
22
Table 11
Parameter name
pronet.apps.agentcon pronet.conf troller.msghandler.w orkerpoolsize pronet.apps.agentcon pronet.conf troller.dbwriter.max msgcachelimit Remote Agent tuning parameters MaxHeap for Remote pronet.conf Agent pronet.apps.agent.wa pronet.conf tchdog.sleeptime
Small: 10 Medium: 20 Large: 30 Small: 50000 Medium: 50000 Large: 60000 Small: 2048 MB Medium: 6144 MB Large: 8192 MB Small: 50000 Medium: 50000 Large: 100000
pronet.jvm.maxthrea dlimit
pronet.conf
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
23
BMC ProactiveNet Server BMC ProactiveNet version Operating System No. of processors Memory
BMC ProactiveNet Agent (PATROL Proxy enabled) BMC ProactiveNet version Operating System No. of processors Memory
Bandwidth utilization Device Monitor instance Attributes Polling Average Network traffic measured for 2 Hours between BMC ProactiveNet server and BMC ProactiveNet Agent (PATROL Proxy) 10 K (1 K PATROL agents, 9 K systems) 125 K 850 K 5 minutes stats, 15 minutes auto sync 74,416 bytes per sec
The following are the BMC ProactiveNet Sybase Database back-up and restores details:
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
24
Time taken to restore each incremental log file is around 30 minutes. BMC ProactiveNet stores a maximum of 7 database restore log files (6 from Monday through Saturday and 1 that comes with the full backup). Time taken to restore BMC ProactiveNet Sybase Database
Backups 1 2 3 1 Incremental backup file 1 Full backup + 1 incremental backups file 1 Full backup + 6 incremental backups file Time taken to restore 30 minutes 1 hour 3.5 hours
Table 12
No.
The following table shows the Remote BMC ProactiveNet Agent start times with Sybase Database and Oracle Database. Table 13
No. 1 2
Remote BMC ProactiveNet Agent start-up times with Data Management setup
Agent start time with Sybase Database Oracle Database Time taken in minutes 7 8
The following table shows the start-up times for BMC ProactiveNet processes. Table 14
httpd 1 second
12 minutes 1 second
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
25
Event management
Event management
BMC ProactiveNet event management is the method used for monitoring, processing, maintaining, and responding to events that occur in IT resources used by business enterprises, including computer systems, network services and applications.
Small environment
Refer to Table 5 on page 12 to view the characteristics of a small BMC ProactiveNet event management environment used to collect and manage events in a centralized IT infrastructure. When planning a small BMC ProactiveNet event management environment, consider the following guidelines:
In a small environment you can host the server and event adapters on the same host, but PATROL integration must be on a separate system. Event correlation, de-duplication, and normalization are distributed on processing cells. Small BMC ProactiveNet event management environment
Figure 3
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
26
Medium environment
Refer to Table 5 on page 12 to view the characteristics of a medium BMC ProactiveNet event management environment used to collect and manage events for Centralized IT Infrastructure. When planning a medium event management environment, consider the following guidelines:
Monitoring tools are feeding events to processing cell. Processing cells are performing event correlation, de-duplication, normalization and feeding this data to BMC ProactiveNet Server BMC Atrium CMDB is installed on a different system (Please see BMC Atrium CMDB documents for Hardware requirement). BMC Atrium CMDB is feeding devices to the BMC ProactiveNet Server. Medium BMC ProactiveNet event management environment
Figure 4
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
27
Large environment
Refer to Table 5 on page 12 to view the characteristics of a large BMC ProactiveNet event management environment which collects and manages events for a distributed IT infrastructure. When planning a large event management environment, consider the following guidelines:
The BMC Atrium CMDB is feeding devices to BMC ProactiveNet Server with automatic sync up. Install BMC Event Manager in each remote location. These remote event managers collect events directly from the event sources, filter sympathetic events, and apply normalization and de-duplication rules to other events. Important events only are then propagated to the event manager of BMC ProactiveNet Server. Each remote location runs the BMC Event Manager instance as well as adapters and integration components. This requires one dedicated computer with the considerations listed in Tested environment for concurrent users on page 72. Large BMC ProactiveNet event management environment
Figure 5
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
28
Table 15
UI Concurrent operational users* Concurrent admin Groups EVENT Intelligent events per day External events per day Event adapters Remote cells Event DB size Event DB keep closed State build size Event retention Static event collectors Levels for collectors Remote agents Number of event adapters CONFIGURATION Jserver MaxHeap Rate MaxHeap Agent Controller MaxHeap Local Agent MaxHeap Remote Agent MaxHeap 2 GB 2 GB 1 GB 0.5 GB N/A 4 GB 4 GB 1.5 GB 0.5 GB N/A 8 GB 8 GB 2 GB 0.5 GB N/A 0 100 K 2 5 default default default default 10 5 0 2 0 200 K 5 10 300 K default default default 25 5 0 5 0 400 K 10 20 530 K default default default 50 5 0 10 10 1 100 20 1 250 30 1 500
* Concurrent operational user interacts with BMC ProactiveNet Operational Web-based user interface 24 hours a day 7 days a week.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
29
Small: 2048 MB Medium: 4096 MB Large: 8192 MB Small: 512 MB Medium: 512 MB Large: 512 MB
Pnagent.conf
Mcell.conf Mcell.conf
The number of events Set it higher for a retained in repository. higher event rate. The minimum age in Set it lower if event rate is high. seconds of CLOSED events before they are removed from the repository. The maximum size in Kilobytes of a transaction file before it is transformed into a new saved state when the statebuilder runs again. Duration after which the agent status cache is refreshed on the agent controller. Frequency at which the agent writes a KEEPALIVE message to the agent controller. Number of retries the agent controller makes before marking an agent UNREACHABLE. Set it higher for a higher event rate to avoid frequent statebuilder runs.
StateBuildSize
Mcell.conf
Other tuning parameters pronet.apps.agent.age pronet.conf ntmon.agentstatusref reshperiod pronet.apps.agent.wa pronet.conf tchdog.sleeptime
Small: 45000 Medium: 90000 Large: 180000 Small: 30000 Medium: 60000 Large: 120000
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
30
Table 16
Small: 45000 Medium: 90000 Large: 180000 Small: 10 Medium: 20 Large: 40 Small: 10 Medium: 20 Large: 40 Small: 15 Medium: 25 Large: 50
pronet.jserver.cachem pronet.conf odule.threadpool.ma x.size pronet.jserver.databa pronet.conf semodule.threadpool. max.size pronet.jserver.dbconn pronet.conf ectionpool.maxdbcon nectionsize
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
31
The following table shows the multi-cell setup details with number of Master cell and collection cells configured in BMC ProactiveNet. Table 17
For load Operating system Event Rate to Master cell Event Rate to Collection cells (collection cells were configured with rule-based processing) Duration of streaming 20 K Events per day for collection cells Duration of streaming 30 K Events per day for collection cells
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
32
The following table shows the CPU and Memory consumed by BMC ProactiveNet process with multi-cell setup and Event rush to Master cell and collection cells. Table 18 CPU and Memory consumption by BMC ProactiveNet process with Event rush
200 K Events per day for Master cell 200 K Events per day for Master cell and 20 K Events per Day and 30 K Events per Day for collection cells for collection cells CPU PnAgent PwTray acell dbsr httpd jserver mcell pronet_cntl rate services tunnelproxy 5% 0.5% 0.1% 1% 0.2% 4% 10% 0.05% 0.15% 0.2% 0.05% Memory 120MB 4MB 11MB 230MB 55MB 2700MB 900MB 90MB 190MB 33MB 20MB CPU 5% 0.5% 0.05% 1% 0.25% 3% 10% 0.05% 0.025% 0.15% 0.025% Memory 120MB 4MB 12MB 300MB 55MB 3000MB 1000MB 90MB 180MB 30MB 20MB
Process
The following table shows time consumed to start by all BMC ProactiveNet processes with multi-cell setup. Table 19
httpd 25 seconds
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
33
The following table shows the CPU and Memory consumed by Collection cells with Event rush. Table 20 CPU and Memory consumption by collection cells with Event rush
20 K Events per day for for collection cells CPU mcell_cell1 mcell_cell2 mcell_cell3 mcell_cell4 mcell_cell5 mcell_cell6 mcell_cell7 mcell_cell8 mcell_cell9 mcell_cell10 0.50% 0.50% 0.50% 0.50% 0.50% 0.03% 0.50% 0.08% 0.06% 0.03% Process Size 180MB 100MB 160MB 180MB 180MB 45MB 180MB 60MB 180MB 100MB 30 K Events per day for collection cells CPU 0.50% 0.50% 0.50% 0.50% 0.50% 0.02% 0.50% 0.05% 0.50% 0.03% Process size 190MB 180MB 200MB 200MB 190MB 60MB 190MB 80MB 190MB 100MB
Collection cells
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
34
Impact Management
Impact Management
BMC ProactiveNet server can be set up to display the health of key service models. This setup supports creating (or importing) Configuration Items (CIs) and displaying the impact on them due to events. Unlike Data and Event Only setup, the focus is on monitoring critical business services.
Small environment
Refer to Table 5 on page 12 to view the characteristics of a small BMC ProactiveNet impact management environment used to manage events and their impact in a centralized IT infrastructure. When planning a small impact management environment, consider the following guidelines:
In a small environment, you can host the server and event adapters on the same host, but PATROL integration must be on a separate system. Event correlation, de-duplication, and normalization are distributed on processing cells. The BMC Atrium CMDB feeds configuration items and relationships to the BMC ProactiveNet Server with automated and manual publish mode. Small BMC ProactiveNet Impact Management environment
Figure 6
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
35
Medium environment
Refer to Table 5 on page 12 to view the characteristics of a medium BMC ProactiveNet impact management environment used to manage events and their impact for Centralized IT Infrastructure. When planning a medium impact management environment, consider the following guidelines:
Monitoring tools are feeding events to processing cell. Processing cells are performing event correlation, de-duplication, normalization and feeding this data to BMC ProactiveNet Server. The BMC Atrium CMDB feeds configuration items and relationships to the BMC ProactiveNet Server with automated and manual publish mode. Medium BMC ProactiveNet Impact Management environment
Figure 7
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
36
Large environment
Refer to Table 5 on page 12 to view the characteristics of a large BMC ProactiveNet impact management environment is one used to manage events and their impact in a centralized IT infrastructure. A total number of 10000 configuration items can be published at a time. When planning a large impact management environment, consider the following guidelines:
Install BMC Atrium CMDB on different systems (see BMC Atrium CMDB documents for hardware requirement). Processing cells are performing event correlation, de-duplication, normalization and feeding this data to BMC ProactiveNet Server. The BMC Atrium CMDB feeds configuration items and relationships to the BMC ProactiveNet Server with automated and manual publish mode. Large BMC ProactiveNet Impact Management environment
Figure 8
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
37
Table 21
UI Concurrent operational users Concurrent Admin IMPACT CIs in CMDB Services in CMDB CIS in ProactiveNet Server CIS per cell CIS in ProactiveNet Server CIS per Service Model (Max) Services in ProactiveNet Server CONFIGURATION Jserver MaxHeap Rate MaxHeap Agent Controller MaxHeap Local Agent MaxHeap Remote Agent MaxHeap 2 GB default default default N/A 4 GB default default default N/A 8 GB default default default N/A 100 K 15 5K 5K 5K 2K 15 100 K 25 10 K 10 K 10 K 5K 25 100 K 50 20 K 20 K 20 K 10 K 50 10 1 20 1 30 1
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
38
Small: 2048 MB Medium: 4096 MB Large: 8192 MB Small: 512 MB Medium: 512 MB Large: 512 MB
Pnagent.conf
Mcell.conf
The number of events Set it higher for a retained in higher event rate. repository. The minimum age in Set it lower if event seconds of CLOSED rate is high. events before they are removed from the repository. The maximum size in Kilobytes of a transaction file before it is transformed into a new saved state when the statebuilder runs again. Duration after which the agent status cache is refreshed on the agent controller. Frequency at which the agent writes a KEEPALIVE message to the agent controller. Number of retries the agent controller makes before marking an agent UNREACHABLE. Set it higher for a higher event rate to avoid frequent statebuilder runs.
EventDBKeepClosed
Mcell.conf
StateBuildSize
Mcell.conf
Other tuning parameters pronet.apps.agent.ag pronet.conf entmon.agentstatusre freshperiod pronet.apps.agent.wa pronet.conf tchdog.sleeptime
Small: 45000 Medium: 90000 Large: 180000 Small: 50000 Medium: 60000 Large: 120000
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
39
Table 22
pronet.jserver.cachem pronet.conf odule.threadpool.ma x.size pronet.jserver.databa pronet.conf semodule.threadpool. max.size pronet.jserver.dbconn pronet.conf ectionpool.maxdbcon nectionsize DestinationBufferKee smmgr.conf pSent
Small: 15 Medium: 20 Large: 40 Small: 15 Medium: 20 Large: 40 Small: 20 Medium: 25 Large: 50 Small: 900 Medium: 1800 Large: 3600
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
40
The following table shows time consumed by all BMC ProactiveNet processes with Impact setup. Table 23
httpd
2 seconds 2 minutes 1 minute 1 minute 1 minute 4 seconds 1 minute 1 minute 53 seconds 26 seconds 1 second 18 seconds 1 second 22 seconds
NOTE
All settings can be manually inserted into their respective configuration files. Program restart is necessary if configurations are changed in the configuration files directly.
WARNING
These configuration changes are recommended exclusively for optimizing BMC ProactiveNet Impact Management functionality. Refer to the AR System 7.6.04 documentation available on the Customer Support website at http://www.bmc.com/support.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
41
Setting
Value
Manual Steps
Generic 1. Login to http://hostname/arsys/s hared/config/config.jsp with default password arsystem 2. Click Cache Settings link on left navigation. 3. In Definition Change Check Interval field, enter 86400. 4. Click Save Changes
80 (default)
Generic 1. Login to http://hostname/arsys/s default hared/config/config.jsp with default password arsystem 2. Click General Settings on left navigation. 3. In Maximum connections per server, enter 80. 4. Click Save Changes. 5. Restart Mid-tier for this change to take effect.
1. Login to http://hostname/arsys/s hared/config/config.jsp with default password arsystem 2. Click Cache Settings link on left navigation. 3. In Resource Check Interval field, enter 86400. 4. Click Save Changes.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
42
Table 24
Value Enable
Manual Steps
Generic 1. Login to http://hostname/arsys/s hared/config/config.jsp with default password arsystem 2. Click Cache Settings link on left navigation. 3. Check the Enable Cache Persistence box. 4. Click Save Changes.
Prefetch Forms
Enable
Change contents of XML. Refer to Mid-Tier Guide document for detailed steps on what to change.
Company 1. Login to http://hostnamearsys/sh policy determined ared/config/config.jsp with default password arsystem 2. Click Cache Settings link on left navigation. 3. Refer to Mid-Tier Guide document for detailed steps on what to change. 4. Click Save Changes.
Generic / 1. Login to http://hostname/arsys/s production hared/config/config.jsp only with default password arsystem 2. Click Log Settings link on left navigation. 3. In Log Level menu, select Severe. 4. Click Save Changes.
Form expiration
3600 sec
Generic
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
43
Table 24
Setting
Value
In Windows, it In Windows: is present in Name:JvmMs the registry: HKEY_LOCA L_MACHINE \SOFTWARE \Apache Software Foundation\P rocrun 2.0\Tomcat5\ Parameters\Ja va Type:REG_DWOR D Data: (decimal) 1024 Name:JvmMx Type:REG_DWOR D
Hardware configuration 1. Start -> BMC Software -> based AR System -> BMC Remedy Mid Tier -> Configure Tomcat 2. In Tomcat Properties dialog, go to Java tab. 3. In Initial memory pool field, enter 1024. In Maximum memory pool, enter 1024. 4. Click OK. 5. Restart Mid-tier.
Data: (decimal) In Unix, it is 1024 located in tomcat_install_ dir/bin/catali In Unix: na.sh JAVA_OPTS=Xms1024m Xmx1024m
In Unix: None.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
44
Table 24
Value 500
Manual Steps
tomcat_install_ Look for your web dir/conf/serv servers connector er.xml port number. Default is 8080. Each connector has the maxThreads parameter. Connector URIEncoding=" UTF-8" acceptCount=" 100" connectionTim eout="20000" disableUpload Timeout="true " enableLookups ="false" maxHttpHeader Size="8192" maxSpareThrea ds="75" maxThreads="5 00" minSpareThrea ds="25" port="8080" redirectPort= "8443"/
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
45
Table 24
Setting
Value
Manual Steps
tomcat_install_ Look for your web dir/conf/serv servers connector er.xml port number. Default is 8080. Each connector has the acceptCount parameter. Connector URIEncoding=" UTF-8" acceptCount=" 100" connectionTim eout="20000" disableUpload Timeout="true " enableLookups ="false" maxHttpHeader Size="8192" maxSpareThrea ds="75" maxThreads="5 00" minSpareThrea ds="25" port="8080" redirectPort= "8443"/
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
46
Table 25
AR Server threads
Value
Manual Steps
Next-Idblock-size
100
Next-ID-BlockSize: 100
1. Open AR System Administration Server Information. 2. Go to Configuration Tab. 3. In Next Request ID Block Size field, enter 100. 4. Click OK.
Generic
1000 Server-SideTable-ChunkSize
Server-SideTable-ChunkSize: 1000
1. Open AR System Administration Server Information. 2. Go to Configuration Tab. 3. In Server Table Field Chunk Size field, enter 1000. 4. Click OK
Generic
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
47
Table 25
Value Uncheck
Manual Steps 1. Open AR System Administration Server Information. 2. Go to Configuration Tab. 3. Uncheck Allow Unqualified Searches. 4. Click OK.
Cache-Mode: 0
1. Open AR System Administration Server Information. 2. Go to Configuration Tab. 3. Uncheck Development Cache Mode. 4. Click OK.
Production only
1. Open AR System Administration Server Information. 2. Go to Log Files Tab. 3. Make sure none of the options are checked. 4. Click OK.
Submitter Mode
Locked
SubmitterMode: 1
1. Open AR System Administration Server Information. 2. Go to License Tab. 3. Select Locked for Submitter Mode. 4. Click OK. 5. Restart AR Server.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
48
Thread Recommendations
The Fast and List queue values can be configured in ar_install_dir/conf/ar.cfg with the following parameters and values: Private-RPC-Socket: 390601 1 1 Private-RPC-Socket: 390603 1 1 Private-RPC-Socket: 390620 6 6 Private-RPC-Socket: 390626 3 3 Private-RPC-Socket: 390635 6 6 Fast and List thread settings are hardware configuration based limitation. There is no configuration file to configure the Customer Access Interface (CAI) plugin registry value. Entry is saved in the database. Do manual steps 7-9.
Manual Steps
1 Login to the User Tool as an Administrator. 2 Open up the AR System Administration Console. 3 Select to System -> General -> Server Information 4 Enter port and Queues in Server Information Dialog. 5 For each type of thread, modify the min threads and max threads for the RPC
program as listed below in the chart. Please note that we are sharing the queue for Loopback and CAI Thread.
6 Click OK. 7 Open CAI Plugin Registry form in new mode. 8 Create an entry with following values:
9 Click Save. 10 Restart ARServer for the CAI Plugin threads to take affect.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
49
CAI plugin registry setting is a hardware configuration limitation and dependent on fast/list thread settings. Table 26 Fast and List thread settings
No. of Threads (min / max) 1 1 Ensure there are escalations using these threads. Use same queue as CAI to share threads. So only one entry is needed. Create entry in the CAI Plugin Registry form with that private queue number matching number of threads Set min and max to the same number
Comments
6 3
Private-RPC-Socket: 390635
List queue
Below is an example of the AR Server Configuration screen and the CAI Plugin Registry screen. Note that values have to match.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
50
Hybrid management
Hybrid management
Hybrid management is a real-time enterprise environment which combines data management and event management. Hybrid management collects data and monitors events from different computers, network systems and applications, and calculates the impact between the systems.
NOTE
In a hybrid environment, the resources are shared between the data collection and event management functions. Therefore, a hybrid environment handles fewer attributes than a dedicated data collection environment and fewer events than a dedicated event management environment. This statement assumes that the hybrid and each of the dedicated environments use comparable hardware.
The systems require sufficient memory for the analytical engine component to perform all of the tasks quickly. Most data that it uses is cached in memory so that baseline and abnormality generation on virtually every attribute in the system can be done behind the scenes. BMC ProactiveNet currently uses an embedded database (Sybase Adaptive Server Anywhere or Sybase ASA) that always runs on the same system as the core server components. The embedded database is optimized for BMC ProactiveNet.
Small environment
Refer to Table 5 on page 12 to view the characteristics of a small BMC ProactiveNet event management environment used to collect and manage events in a centralized IT infrastructure. When planning a small data collection and event management environment, consider the following guidelines:
In a very small environment that collects 25,000 or fewer attributes, you could use one server with a local agent acting as the data collector. If you use the BMC PATROL Adapter, install the Integration Service for PATROL on the agent. If you expect more than five concurrent users or if the average polling intervals are quicker than five minutes, use a medium architecture setup.
51
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
If you collect data across networks or firewalls, consider using a remote agent to minimize the number of connections to manage across the networks or firewalls. To improve I/O throughput, locate the operating system and database on separate disks, with their own disk controllers. In a small environment you can host server and event adapters on the same host. PATROL integration needs to be on separate system. Event correlation, de-duplication and normalization is distributed on processing cells.
Medium environment
Refer to Table 5 on page 12 to view the characteristics of a medium BMC ProactiveNet hybrid management environment. When planning a medium data collection and event management environment, consider the following guidelines:
The BMC Atrium CMDB is feeding devices to BMC ProactiveNet Server. An agent does not require a dedicated physical machine. You can install multiple agents on a remote computer as long as 1 CPU and 2 GB of memory are allocated for each agent. A 64-bit agent can handle a larger number of attributes. You can deploy agents within a VM as long as the VM meets the resource requirements. If you expect the total number of attributes for the environment to grow beyond 400,000 attributes, use it a large-environment deployment so that the system can accommodate growth smoothly. If you use a BMC PATROL Adapter, install the Integration Service for PATROL on all the remote agents that are identified for creating the adapter. The data collection agent residing on the server collects metrics about only BMC ProactiveNet performance. BMC recommends that you tune the Java Virtual Machines (JVMs) as described in Tested environment for concurrent users on page 72. Monitoring tools are feeding events to processing cell. Processing cells are performing event correlation, de-duplication, normalization and feeding this data to BMC ProactiveNet Server BMC Atrium CMDB is installed on different system (Please see BMC Atrium CMDB documents for Hardware requirement)
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
52
Large environment
Refer to Table 5 on page 12 to view the characteristics of a large BMC ProactiveNet data collection and event management environment. When planning a large data collection and event management environment, consider the following guidelines:
The BMC Atrium CMDB feeds devices to the BMC ProactiveNet Server with automatic sync-up. Configure each BMC ProactiveNet server so that it contains an entire line of business, rather than spreading the monitoring from any line of business or application across servers. An agent does not require a dedicated physical machine. You can install multiple agents on a remote computer as long as 1 CPU and 2 GB of memory are allocated for each agent. A 64-bit agent can scale to much higher attributes. Make sure the memory allocated for this agent is sufficient. You can deploy agents within a VM as long as the VM meets the resource requirements. If you use a BMC PATROL Adapter, install the Integration Service for PATROL on all the remote agents that are identified for creating the adapter. For optimum performance, minimize the number of monitors running on the local agent that resides on the BMC ProactiveNet server. The data collection agent residing on the server should collect metrics about only BMC ProactiveNet performance. BMC recommends that you tune the Java Virtual Machines (JVMs) as described in Tested environment for concurrent users on page 72. Install BMC Event Manager in each remote location. These remote event managers' collects events directly from the event sources, filter sympathetic events and apply normalization and de-duplication rules to other events. Only important events are then propagated to the event manager of BMC ProactiveNet Server. Each remote location runs the BMC Event Manager instance as well as adapters and integration components and requires one dedicated computer with following specification. BMC ProactiveNet Agent scaling recommendations on page 7.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
53
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
54
Table 27
Remote agents Number of event adapters CONFIGURATION Jserver MaxHeap Rate MaxHeap Agent Controller MaxHeap Local Agent MaxHeap Remote Agent MaxHeap
0 0
2 GB 2 GB 1 GB default 2 GB
4 GB 4 GB 1.5 GB default 4 GB
8 GB 8 GB 2 GB default 8 GB
Small: 2048 MB Medium: 4096 MB Large: 8192 MB Small: 2048 MB Medium: 4096 MB Large: 8192 MB Small: 1024 MB Medium: 1536 MB Large: 2048 MB Small: 512 MB Medium: 512 MB Large: 1024 MB Small: 2048 MB Medium: 4096 MB Large: 8192 MB
Pnrate.conf
MaxHeap for Agent Controller MaxHeap for Agent (Local) MaxHeap for Agent (Remote) Cell tuning parameters EventDBSize
Pnagentcntl.conf MaxHeap allocated to Agent Controller Process Pnagent.conf MaxHeap allocated for local agent MaxHeap allocated for remote agent
Pnagent.conf
Mcell.conf
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
55
Table 28
StateBuildSize
Mcell.conf
Set it higher for a higher event rate to avoid frequent statebuilder runs.
Small: 20 Medium: 25 Large: 180000 Small: 20 Medium: 25 Large: 120000 Small: 4 Medium: 4 Large: 4 Small: 25000 Medium: 50000 Large: 100000
pronet.conf
pronet.conf
pronet.conf
pronet.apps.agent.pollp eriod pronet.jserver.cachemo dule.threadpool.max.si ze pronet.jserver.database module.threadpool.ma x.size pronet.jserver.dbconne ctionpool.maxdbconnec tionsize pronet.rate.maxdbconn ections
pronet.conf
Small: 45000 Medium: 90000 Large: 180000 Small: 15 Medium: 20 Large: 40 Small: 15 Medium: 20 Large: 40 Small: 20 Medium: 25 Large: 50 Small: 25 Medium: 45 Large: 90
pronet.conf
pronet.conf
pronet.conf
Number of Max Database connections. Number of DB connections the analytical engine (rate process) can make at one time.
pronet.conf
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
56
Cloud management
Cloud management
BMC ProactiveNet supports the BMC Cloud Lifecycle Management environment. In the BMC Cloud Lifecycle Management environment, you can use BMC ProactiveNet to monitor the performance of virtual machine monitors (VMMs, also called hypervisors). When planning your deployment, it is helpful to consider factors such as your enduser community, your network infrastructure, and security issues. End Users How you build your cloud is determined in part by the number and distribution of the tenants and end users you support. Answering the following questions will help you understand the number, type, and distribution of the infrastructure resources that you need to build your cloud:
How big is your user community? How is your user community distributed geographically? If you represent a service-provider organization, how many tenants will you support, and how many users are associated with each tenant? How will you manage end-user and administrator access to your cloud? How will you manage access to the My Services Portal?
Network Infrastructure At the heart of your cloud planning is your network infrastructure. You must decide how to organize the pods, network containers, and resource pools in your cloud. Much of your network-infrastructure planning will be consumed by BMC Cloud Lifecycle Management as service blueprints to enable automated delivery of resources that support services your end users request.
How many pods do you need to support your tenants and end users? How should your pods be distributed geographically? Consider whether you will have staff to support those pods on-site, or whether you will provide support remotely. How many network containers do you need in each pod? How will you assign resources in network containers? For example, will you assign resources to specific tenants or level of service? How will you build resource pools? For example, will resources be grouped according to performance, geographic location, or some other criteria?
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
57
How many physical and virtual servers do you need? How will you address failover and availability concerns? How should you build your pre-production environment? Prior to making the cloud available to your end users, you will need an environment in which to develop and test your cloud. Do you need only environments for development, testing, and production? If you represent a service provider organization, should you make a pre-production environment available to your tenants?
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
58
Small deployment
Select the small template for deployments of 10,000 virtual devices. Figure 9 High level architecture for small BMC ProactiveNet Server deployment
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
59
Medium deployment
Select the medium template for deployments of 25,000 virtual devices. Figure 10 High level architecture for medium BMC ProactiveNet Server deployment
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
60
Large deployment
Select the large template for deployments of 50,000 virtual devices. Figure 11 High level architecture for large BMC ProactiveNet Server deployment
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
61
Table 29
No. of DCH 1 3 5
Table 30
BMC ProactiveNet Central Server Operating system RAM CPUs Storage configuration
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
62
Size of environment
Table 32 provides the parameter information for BMC ProactiveNet Central Server, BMC ProactiveNet Server and BMC ProactiveNet Data Collection Host in Cloud Management.
Table 32
Server
pnagent.conf pndbsrv.conf
Default Default
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
63
Table 32
Server
File Name
pnjserver.conf pnrate.conf pnagentcntl.conf
Description
Max Heap allocated for Jserver Process Max Heap allocated for Rate Process Max Heap allocated for Agent Controller Process Max Heap allocated for Agent Process Initial cache size for db server Duration after which the agent status cache is refreshed on the agent controller. Frequency at which the agent writes a KEEPALIVE message to the agent controller. Number of retries the agent controller makes before marking an agent UNREACHABLE. Maximum number of threads permitted for the agent JVM (buffer 10% for the instances to be discovered). Frequency at which the agent controller polls each agent for status. This time is in seconds.
pronet.conf
120000
pronet.conf
pronet.jvm.maxthr eadlimit
pronet.conf
100000
pronet.apps.agent. pollperiod pronet.jserver.cach emodule.threadpo ol.max.size pronet.jserver.data basemodule.threa dpool.max.size pronet.jserver.dbc onnectionpool.ma xdbconnectionsize
pronet.conf
180000
pronet.conf
40
pronet.conf
40
pronet.conf
50
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
64
Table 32
Server
File Name
pnagent.conf pronet.conf
Description
Max heap allocated for Agent Process Frequency at which the agent writes a KEEPALIVE message to the agent controller. Maximum number of threads permitted for the agent JVM (buffer 10% for the instances to be discovered). Frequency at which the agent controller polls each agent for status. This time is in milliseconds.
pronet.conf
100000
pronet.apps.agent. pollperiod
pronet.conf
180000
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
65
Reports Management
Reports Management
BMC ProactiveNet Performance Management Reporting is an advanced reporting platform. It uses the SAP BusinessObjects Enterprise product as the host for BMC ProactiveNet Performance Management to administer and publish reports. It also uses Oracle Database as the application database. BMC ProactiveNet Performance Management Reporting contains impact report and event report templates.
Event report templatesdisplay operator response time to an event, event counts, top event sources, and other event details. Impact report templatesdisplay data based on a service's availability, failures, repairs and incidents, and the time related to each.
Data for these templates is obtained from the Oracle database. BMC ProactiveNet Performance Management Reporting also enables you to create ad hoc reports and offers more flexibility when compared to BMC Event and Impact Reporting. The product is intended for customers who are using BMC ProactiveNet Performance Management 8.5 or higher versions.
Architecture
BMC ProactiveNet Performance Management systems propagate events and component status changes from BMC ProactiveNet servers to BMC ProactiveNet Report Engine. BMC ProactiveNet Report Engine then aggregates and summarizes the events and component status changes and stores the processed data in the Oracle database. The impact reports are supplemented with associated service information Figure 12 shows the architecture for BMC ProactiveNet Performance Management Reporting. Figure 12 BMC ProactiveNet Performance Management reporting architecture
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
66
Event Reports
Event Reports
Table 34 shows the hardware consumed by Oracle database for 8 days with 200 K events per day. Table 34
No. 1
Oracle Database Size for 8 days with 200 K events per Day
Database size 2.78 GB Events rate 200 K per day Total Events 1650 K
Database Oracle
Table 35 shows the minimum CPU and memory consumption by events reports.
Table 35
No. 1 2 3 4
BMC ProactiveNet Business Objects reporting engine pulls the following types of pre-defined Event Reporting from the database:
Event Summary by Priority and Event Class Event Summary by Priority and Host Event Summary by Priority and Host Details Event Summary by Priority and Location Event Summary by Priority and Location Details Event Summary by Priority and Object Event Summary by Priority and Object - Details
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
67
Impact Reports
The following are pre-defined Event Reports Types generated by Business Objects reporting engine. Table 36 Pre-defined Event Reports Types generated by Business Objects
No. of records in report 323,832 63,007 2,579 1,266,750 1,072,836 Report type (file size) Excel (37 kb) PDF (142 kb) Excel (242 kb) PDF (821 kb) Excel (39 kb) PDF (124 kb) Excel, PDF Excel (39 kb) PDF (119 kb) Excel (17 kb) PDF (56 kb) Excel (13 kb) PDF (42 kb) Total time to generate reports (sec) 230 342 83 578 507
No. 1 2 3 4 5
File name BPPM01.02 - Event Summary by Priority and Event Class BPPM01.03 - Event Summary by Priority and Host BPPM01.03a - Event Summary by Priority and Host - Details BPPM01.04 - Event Summary by Priority and Location BPPM01.04a - Event Summary by Priority and Location Details BPPM01.05 - Event Summary by Priority and Object BPPM01.05a - Event Summary by Priority and Object - Details
6 7
2 1
15 79
Impact Reports
Table 37 shows the hardware consumed by Oracle database for 6 service models with 20 K CI and 6 levels. Table 37
No. 1
Database
Table 38 shows the minimum CPU and memory consumption by Impact Reports. Table 38
No. 1 2 3 4
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
68
Impact Reports
BMC ProactiveNet Business Objects reporting engine pulls the following types of pre-defined Impact Reporting from the database:
Table 39 shows the pre-defined Impact Reports Types generated by Business Objects reporting engine. Table 39
Pre-defined Impact Reports Types generated by Business Objects No. of records in report 371,647 1,699,979 1,884,025 1,892,027 Report Type (file size) Excel (24 kb), PDF (82 kb) Excel (17 kb), PDF (98 kb) Excel (12 kb), PDF (51 kb) Excel (34 kb), PDF (94 kb) Total time taken to generate reports (sec) 5 3 10 60
No. 1 2 3 4
File name BPPM05.01 - Component Availability BPPM05.01a - Component Availability - Details BPPM05.02a - Losses - Details BPPM05.03 - MTBF
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
69
Use RAID 10 or 01 on larger BMC ProactiveNet installations to better satisfy the higher demands on write IO operations Use SAN on medium and large deployments. Performance testing for the sizing numbers in this document was performed on UNIX and NTFS filesystem. Performance problems were observed using Veritas file systems and not recommended for large deployments. Use a larger number of physical disk drives (spindle count) instead of larger capacity disks. Because disk drive throughput performance has not increased at the same rate of disk capacity, you can achieve better performance with a higher number of smaller disks. Defragmentation of the database file should be done every 6 months for large environments. Avoid extending raw data retention by a large amount - this can impact I/O performance.
CPU guidelines
Parallel CPUs usually have a bigger impact on improving user response time than a single CPU with higher clock speed.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
70
To minimize connections between networks or across firewalls, use BMC ProactiveNet proxy to consolidate BMC ProactiveNet agents. When using BMC PATROL Adapter, deploy the Integration Service for PATROL strategically so that the connection from the Integration Service for PATROL does not need to span across networks or firewalls instead use the BMC ProactiveNet agent connection to do this (or the BMC ProactiveNet Proxy). Deploy monitors and users in a phased approach (validating after gradual increments).
Data collection
Focus collection on KPIs. You do not need to pull all metrics and monitors into BMC ProactiveNet.
Leverage Abnormality generated Detailed Diagnostics to pull in more detailed level (and non-KPI info). Poll only critical monitor instances at quick poll intervals (less than 5 minutes). Distribute monitors and adapters across agents in an intelligent fashion.
Configure views and graphs to update on demand, rather than at regular intervals. Configure reports at less frequent intervals unless absolutely required. Keep Report and View durations to a minimum. Long report periods (reports which span a long durations) can cause substantial impact. Report scoping can have a large impact on report generation. Use group scoping whenever possible. Schedule daily report generation for off-peak time frames (for example, 2:00 a.m.).
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
71
30 different users were created on BMC ProactiveNet Server. 30 concurrent users logged on to the BMC ProactiveNet Server. The users included both the restricted and unrestricted users. For example, if the number of restricted users was 10, then there were 20 unrestricted users.
50% of the users accessed Event View, Tile View, Grid View, and Event Operations page and the rest 50% of the users randomly accessed other pages. BMC ProactiveNet Operations console was accessed using Microsoft Internet Explorer 7.0 and above and Mozilla Firefox 3.5 and above.
NOTE
If all the users are on the same network, the response times for the user interfaces are found to be better.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
72
Does increasing data retention have an impact on performance? What was the data retention used in the scalability testing? How can I monitor more than 10 remote cells from BMC ProactiveNet Administration Console? What is the average number of parameters that a PATROL Agent can collect? How can I tell if the load on the system exceeds its capacity? What is the best way to deploy and configure my adapters across agents? Are there any settings or tuning requirements for the database? Why are the memory requirements so large? How does clustering of the web server, application server, or agent impact the scale estimates? Is there any recommendation if baselining is done for all metrics (non-KPIs)?
How can I monitor more than 10 remote cells from BMC ProactiveNet Administration Console?
You have to disconnect few cells and connect to the cells that you want to monitor. At any given time, you cannot connect to more than 10 remote cells.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
73
What is the average number of parameters that a PATROL Agent can collect?
The average number is 850 parameters per PATROL Agent, and it usually depends on the KMs that are loaded. This was tested on Windows and UNIX machines.
How can I tell if the load on the system exceeds its capacity?
The following are the most common issues that arise when capacity is exceeded:
The analytical engine runs out of memory. If this occurs, OutOfMemory exceptions are logged in the BMC ProactiveNet log file by rate process. This usually means that you need to increase MaxHeap. See Tested environment for concurrent users on page 72. There are gaps in data collection across all monitors sporadically, or there are artificial alarm delays after a threshold condition has been violated. You might also see gaps in the data shown in graphs. When this occurs, you might see pending, cache size limit exceeded, and dropping messages logged in the BMC ProactiveNet log file. Gaps in data could result from memory issues or I/O bottlenecks. If you see no OutOfMemory exceptions logged, it is probably an I/O issue. Check the I/O by looking at % disk busy for the disks that are used (for example, the iostat cmd on Solaris). If the system consistently shows that % disk busy is above 30%, there is most likely an I/O problem.
User response becomes much slower when using the web interface. If it is slow for all interactions, this indicates a problem with memory or CPU. If it is only slow when graphing, this indicates an I/O constraint. Check the out-of-the-box monitors that BMC ProactiveNet creates on the server. If you see sustained (minutes) CPU spikes above 80%, this usually indicates some resource issue (not necessarily a lack of CPU).
What is the best way to deploy and configure my adapters across agents?
In general it depends on what you are trying to accomplish. For best performance, it is always better to have the agent that runs the adapter installed in the same network as the server from which it is pulling data. This ensures that the adapter calls (for example, web service and database queries) do not have latency issues. The BMC ProactiveNet Server and Agent connection bundles up the data more efficiently, which creates better cross network traffic. It is possible to use one large adapter to pull in data from a BMC ProactiveNet application, but there are times when it is better to use multiple adapters across one (or many) BMC ProactiveNet Agents. If you use separate adapters for different application types, you can set different polling intervals for the high priority applications (this allows more scaling in the end). You could also do this for different application instances, as well (not just for application types).
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6 74
How does clustering of the web server, application server, or agent impact the scale estimates?
Clustering addresses continued operation in the event of a failure. It does not address performance. The scale estimates produced by this document represent the minimum number of computers required to support a given workload. A clustered environment requires additional computers. You should use the estimates provided in this document to ensure that, in the case of a failure, the remaining components continue to operate. Monitors that measure response time by simulating a client request can require property tuning in order to avoid response time skew. See Tested environment for concurrent users on page 72.
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
75
TIP
If you do not already have a user name and password that allow you to fully access the Customer Support site, you can register for a user name and password on the site.
From the Customer Support site, you can perform several tasks, including:
Viewing the latest product documentation (manuals, release notes, flashes, technical bulletins, online Help, and parameter information). Subscribing to proactive alerts to receive e-mail messages that inform you of new release notes, flashes, and technical bulletins for your products. Searching for existing product resolutions and frequently asked questions (FAQs).
Copyright 2011 BMC Software, Inc. BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners. Linux is the registered trademark of Linus Torvalds. IBM, DB2 Universal Database, iSeries, Informix, Lotus, Domino, and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. UNIX is the registered trademark of The Open Group in the US and other countries. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. SAP and R/3 are trademarks or registered trademarks of SAP AG in Germany and in several other countries. BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices in the product documentation.
BMC SOFTWARE INC 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA 713 918 8800 Customer Support: 800 537 1813 (United States and Canada) or contact your local support center
Best Practices for BMC ProactiveNet Performance Management Performance and Scalability version 8.6
76