Patrol Central Infrastructure Best Practices Guide

PATROL Central Infrastructure
Best Practices Guide
Supporting
PATROL Agent version 3.6
PATROL Central Operator Web Edition version 7.1.10.01
PATROL Central Operator Microsoft Windows Edition version 7.5.00
PATROL Configuration Manager version 1.5.01
PATROL Console Server version 7.5.00
PATROL Knowledge Module for Event Management/
PATROL Notification Server version 2.6.00
PATROL Knowledge Module for Log Management version 2.0.01
PATROL RTserver version 6.6.00
PATROL Infrastructure Monitor version 7.5.00 (formerly the PATROL
Infrastructure Knowledge Module version 7.1.10)
Distribution Server version 7.1.20
BMC Impact Integration for PATROL version 7.1.01
PATROL Enterprise Manager Console Server Connection version 7.1.00
PATROL Integration for HP Network Node Manager version 7.1.00
February 28, 2005
Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information
about the company, its products, corporate offices, special events, and career opportunities.
United States and Canada

Address
BMC SOFTWARE INC

2101 CITYWEST BLVD
HOUSTON TX 77042-2827
USA
Telephone
713 918 8800 or

800 841 2031
Fax
(01) 713 918 8000
Fax
713 918 8000
Outside United States and Canada

Telephone
(01) 713 918 8800
Copyright 2005 BMC Software, Inc., as an unpublished work. All rights reserved.
BMC Software, the BMC Software logos, and all other BMC Software product or service names are registered trademarks
or trademarks of BMC Software, Inc.
IBM is a registered trademark of International Business Machines Corporation.
Oracle is a registered trademark, and the Oracle product names are registered trademarks or trademarks of Oracle
Corporation.
All other trademarks belong to their respective companies.
PATROL technology holds U.S. Patent Number 5655081.
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 included in this documentation.
Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE
COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the
U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS
252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is
BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to
this address.
Customer support
You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer
Support by telephone or e-mail. To expedite your inquiry, please see Before Contacting BMC Software.
Support website
You can obtain technical support from BMC Software 24 hours a day, 7 days a week at
http://www.bmc.com/support_home. From this website, you can
read overviews about support services and programs that BMC Software offers
find the most current information about BMC Software products
search a database for problems similar to yours and possible solutions
order or download product documentation
report a problem or ask a question
subscribe to receive e-mail notices when new product versions are released
find worldwide BMC Software support center locations and contact information, including e-mail addresses, fax
numbers, and telephone numbers
Support by telephone or e-mail

In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or
send an e-mail message to support@bmc.com. Outside the United States and Canada, contact your local support center for
assistance.
Before contacting BMC Software

Before you contact BMC Software, have the following information available so that Customer Support can begin working
on your problem immediately:
product information
product name
product version (release number)
license number and password (trial or permanent)
operating system and environment information
machine type
operating system type, version, and service pack or other maintenance level such as PUT or PTF
system hardware configuration
serial numbers
related software (database, application, and communication) including type, version, and service pack or
maintenance level
sequence of events leading to the problem
commands and options that you used
messages received (and the time and date that you received them)
product error messages

messages from the operating system, such as file system full
messages from related software
PATROL Central Infrastructure Best Practices Guide
Contents
Chapter 1
Introduction
13
Purpose of this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Planning the Implementation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Chapter 2
Analyzing the Management Environment
17
Analysis Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Completing the Enterprise Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 3
PATROL Central Implementation Logical Design
23
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RT Cloud Logical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RTserver Design Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Characterizing RTserver Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deciding Initial RTserver Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RTserver Backup/Failover Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Visualization Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Which PATROL Central Console is Appropriate? . . . . . . . . . . . . . . . . . . . . . . . . . .
Which Locations Need PATROL Console Servers? . . . . . . . . . . . . . . . . . . . . . . . . .
Is One PATROL Console Server Enough? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logically Sizing the PATROL Console Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Console Server Failover Considerations. . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Central Operator Web Edition Placement . . . . . . . . . . . . . . . . . . . . . . .
Visualization Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event Management Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notification Server Usage and Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Centralized Customization Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Designing for PATROL Management/Upgrade/ Patching . . . . . . . . . . . . . . . . . . . . .
Using the Distribution Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
24
24
26
26
26
28
28
28
29
30
30
32
32
33
34
35
36
36
37
Chapter 4
39
PATROL Central Environment Physical Mapping
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Single Server Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RTserver Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Console Server Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
40
40
40
42
45
PATROL Central Operator Web Edition Hardware . . . . . . . . . . . . . . . . . . . . . . . 46

PATROL Central Operator Microsoft Windows Edition Hardware. . . . . . . . . . 47
Co-Hosting PATROL Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
PATROL Console Server Platform Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
RTserver Implementation Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
RT Cloud Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
PATROL Console Server Implementation Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Clustering a PATROL Console Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Chapter 5
Developing the Implementation Plan
53
Order of Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Planning Ahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Appendix A
Frequently Asked Questions
55
RTserver and RT clouds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

How do clients connect to an RTserver?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
How many agents can connect to a single RTserver?. . . . . . . . . . . . . . . . . . . . . . . . 57
How many agents can connect to a single RT cloud?. . . . . . . . . . . . . . . . . . . . . . . . 58
How many RT clouds can be connected to a single PATROL Console
Server?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
How many RTservers can be connected in a single cloud? . . . . . . . . . . . . . . . . . . . 59
What is the best RT cloud configuration?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
When are multiple RT clouds recommended? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
When should hub-and-spoke RT cloud architecture be used? . . . . . . . . . . . . . . . . 62
Which multi-cloud configurations should be avoided? . . . . . . . . . . . . . . . . . . . . . . 64
Can RTserver versions 6.2, 6.5.01, and 6.6 be mixed in the same cloud?. . . . . . . . 68
How should version 6.2-based hub-and-spoke clouds be migrated to 6.6.00?. . . 68
How can RTservers be configured to communicate through a firewall? . . . . . . . 73
PATROL Console Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
How many users can a PATROL Console Server support?. . . . . . . . . . . . . . . . . . . 73
How many agents can a PATROL Console Server support? . . . . . . . . . . . . . . . . . 74
Which versions of the PATROL Agent should be used with the PATROL
Console Server? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
How many RT clouds can be connected to a PATROL Console Server?. . . . . . . . 75
What can be done to prevent the PATROL Console Server from becoming
overloaded? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
How can a PATROL Console Server be backed up? . . . . . . . . . . . . . . . . . . . . . . . . 75
How is a backup PATROL Console Server started? . . . . . . . . . . . . . . . . . . . . . . . . . 76
Are the locations of PATROL Central files and directories documented
anywhere?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
What should I do if I see a message in the PATROL Console Server log file
indicating duplicate RTservers? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
PATROL Central Operator Web Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
How many users can PATROL Central Operator Web Edition support? . . . . . 77
How large a profile can PATROL Central Operator Web Edition support? . . . 77
Why are console-side KM commands inactive on PATROL Central Operator
Web Edition? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
PATROL Central Operator Microsoft Windows Edition . . . . . . . . . . . . . . . . . . . . . .

How large a profile can PATROL Central Operator Microsoft Windows
Edition support? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What version of PATROL Central Operator Microsoft Windows Edition is
recommended? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Infrastructure Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Should I use the former PATROL Infrastructure Knowledge Module or
PATROL 7 Knowledge Module to monitor my PATROL Central 7.5.00
infrastructure? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What versions of the PATROL Central infrastructure are supported by the
PATROL Infrastructure Monitor? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How can more than one RT cloud be monitored with the PATROL
Infrastructure Monitor? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Components & Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Are there any OS dependencies for PATROL Central infrastructure? . . . . . . . . .
Is PATROL Central infrastructure supported on iSeries? . . . . . . . . . . . . . . . . . . . .
When should the Availability Checker be used in an enterprise
implementation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Why can't all aspects of KM operation be managed with PCM? . . . . . . . . . . . . . .
How are PCM rulesets used to best advantage?. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix B
Infrastructure Planning Forms
77
78
78
78
78
79
79
80
80
80
80
81
81
83
Stakeholder Roster Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Location Analysis Worksheet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Appendix C
Sample Solution Planning Forms & Diagrams
87
Sample Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Stakeholder Roster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Location Analysis Worksheet for Houston . . . . . . . . . . . . . . . . . . . . . . . .
Example Location Analysis Worksheet for Austin. . . . . . . . . . . . . . . . . . . . . . . . . .
Example Location Analysis Worksheet for New York . . . . . . . . . . . . . . . . . . . . . .
Example Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
89
90
91
92
93
Glossary
97
Contents
Figures
Example of a Multiple RT Cloud Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of Multiple RT Clouds with Hub and Spoke . . . . . . . . . . . . . . . . . . . . . . . . .
Example of Cross-Linked RT Clouds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of RT Cloud-to-Cloud Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Case 1 "Before" Small Hub-and-Spoke Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Case 1A "After" One Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Case 1B "After" Small Multi-Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Case 2 "Before" Large Hub-and-Spoke Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MainCore, Inc. Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MainCore, Inc. Houston Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MainCore Inc. Austin Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MainCore, Inc. New York Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figures
60
63
65
67
69
70
71
72
93
94
95
96
10
Tables
Requirements for Small Single-Server PATROL Central Environment
(Up to 500,000 managed objects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements for a Medium Single-Server PATROL Central Environment
(Up to 3 million managed objects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements for One RTserver on a Dedicated Computer
(Up to 750 RT clients) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements for Two RTservers on a Dedicated Computer
(Up to 1000 total RT clients) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements for Two to Four RTservers on a Dedicated Computer
(Up to 2000 RT clients) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements for a Medium PATROL Console Server Environment
(Up to 3 million managed objects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements for a Large PATROL Console Server Environment
(Up to 10 million managed objects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements for PATROL Central Operator Microsoft Windows Edition
(based on profile size) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tables
41
41
42
43
44
45
46
47
11
12
Chapter
Introduction
This chapter presents the following topics:
Purpose of this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Planning the Implementation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Chapter 1
Introduction
13
Purpose of this Guide
Purpose of this Guide

The purpose of the PATROL Central Infrastructure Best Practices Guide is to provide
BMC Software PATROL solution architects with a process for gathering technical
requirements, identifying potential trouble spots, and documenting a PATROL
infrastructure implementation that will function reliably and efficiently. While this
document discusses some "do's and don'ts" that are covered in other PATROL
documents, it generally does not duplicate information provided elsewhere. This
document frequently refers to product manuals and white papers for operational
details.
Information presented in this document applies to the following components:
PATROL Agent version 3.6 or later

PATROL Central Operator Web Edition version 7.1.10.01
PATROL Central Operator Microsoft Windows Edition version 7.5.00
PATROL Configuration Manager version 1.5.01
PATROL Console Server version 7.5.00
PATROL Knowledge Module for Event Management / PATROL Notification
Server version 2.6.00
PATROL Knowledge Module for Log Management version 2.0.01
PATROL RTserver version 6.6.00
PATROL Infrastructure Monitor version 7.5.00 (formerly the PATROL
Infrastructure Knowledge Module version 7.1.10)
Distribution Server version 7.1.20
Common Connect clients
BMC Impact Integration for PATROL version 7.1.01
PATROL Enterprise Manager Console Server Connection version 7.1.00
PATROL Integration for HP Network Node Manager version 7.1.00
Best Practice Recommendation BP1

Always obtain the latest revision of this guide before you base a PATROL Central design on
the guidelines it contains. Release-to-release changes in infrastructure components can
significantly affect the success or failure of a PATROL implementation. Verify the supported
platform list for all components before you plan a PATROL Central implementation.
Addition or deprecation of platforms for individual components can significantly affect the
success or failure of a PATROL implementation.
While this guide does not answer every possible technical question or provide for
every design contingency, it will almost always lead to a design that uses PATROL in
the best way possible. Choosing not to follow the guidelines presented in this
document, or neglecting to take into account the factors discussed herein, can lead to
a PATROL implementation that is unstable, that requires an excessive amount of time
to maintain, or that can experience a major failure. If, at the end of the design process,
14
Planning the Implementation Process
solution architects have doubts about the proposed implementation, they are
encouraged to consult with BMC Software and the PATROL Line Of Business for
design validation before proceeding. Failure to do so can result in lost time, added
expense, and disruption of service.
Always consult with BMC Software and with the PATROL Line of Business before deviating
from the Best Practices presented in this guide. Failure to do so can lead to major software
failures and system outages.
To view the latest BMC Software manuals, technical bulletins, flashes, and white
papers visit the BMC Software Customer Support page at
http://www.bmc.com/support_home.

While small PATROL implementations can be supported by a single infrastructure
server running a PATROL Console Server/RTserver pair, design of a large PATROL
solution is more challenging and should be approached in a top down manner.
PATROL Central implementations involving up to 500 managed nodes can be supported by
a single infrastructure server running one PATROL Console Server, one RTserver, and one
instance of PATROL Central Operator Web Edition. For detailed information about
hardware sizing, see Hardware Requirements on page 40.
Solution architects should start with the "big picture" and work their way down to
progressively greater levels of detail until all their objectives have been met. Chapters
2 and 3 in this document will discuss this process in detail. In general, though, there
are four steps in the process.
1. Solution architects should first identify the implementation stakeholders in order
to engage them in the design and review process. A solution diagram should then
be built that provides PATROL support for the number of managed servers and
consoles that the solution requires.
Every infrastructure component should be treated as if it required a dedicated
server, but with geography and network topology in mind. The diagram should
indicate the speed of all network connections, note the locations of any firewalls
that may be present, and reference any existing equipment to be used for PATROL
infrastructure.
Chapter 1
Introduction
15
2. The number of RT clouds and RTservers needed to support the PATROL solution
should be determined. Provision should not yet be made for recoverability or
failover, but key considerations include
the number of agents in the design

common Knowledge Modules (KMs) in the design
the number of active objects in the KMs
the number of concurrent PATROL operators using the infrastructure
the general makeup of Active Sessions
the number of agents per profile
small "application discrete" profiles
group or Individual profiles
security considerations
3. Failure scenarios should be considered and the need to provide failover

capabilities for particular components should be identified. Where failover is not
possible, single points of failure should be eliminated or the solution should be
modified so that most failures cause only a partial loss of functionality or
performance.
4. Hardware requirements should be determined. Factors in configuring
infrastructure servers include the work each PATROL component must perform
and whether or not components can safely coexist and interoperate on the same
server. The design should be optimized to require as little hardware as possible
without unduly affecting performance.
16
Chapter
Analyzing the Management

Environment
2
This chapter describes how to complete the planning forms used to record
information collected during analysis of the enterprise to be managed with PATROL.
The forms can be found in Appendix B, Infrastructure Planning Forms.
Analysis Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Completing the Enterprise Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 2 Analyzing the Management Environment
17
Analysis Tools
Analysis Tools
The Stakeholder Roster Worksheet provides a convenient place to note the people
and groups who will be involved with the implementation and day-to-day operations
using PATROL. Identifying contacts early in the process will aid in analysis and
communication and help reduce missteps during implementation planning.
The Location Analysis Worksheet provides a standardized format for recording
relevant information about each logical and physical location to be managed. The
analysis performed and the data recorded on this form will be used to develop a
logical design for the PATROL implementation. The thoroughness of the analysis and
accuracy of the information recorded will have a significant impact on the quality of
the design and the overall success of the PATROL implementation. Use of this form
will facilitate communication and review of the proposed design.
When planning a PATROL Central implementation, the minimum recommended PATROL
Agent version is 3.5.32.20 and version 3.6.00.05 or later is preferred. These versions
incorporate many performance and scalability improvements related to PATROL Central. If
existing agents must be upgraded they should be upgraded to the latest Generally Available
version.
Completing the Enterprise Analysis

The three key steps in the analysis and data collection stage are:
1. Identify project stakeholders
2. Diagram the enterprise to be managed by PATROL
3. Collect and record high-level sizing data for each management domain
ACTION 1
Begin by completing the Stakeholder Roster. List all the groups or individuals who
will participate or have an interest in this implementation of PATROL. If a group is
listed, identify a person to serve as communications contact for the group. Refer to
the roster during the remainder of the process when questions arise or when
communicating about the progress of the implementation. Frequent communication
will help highlight issues early in the process and reduce rework later. At a
minimum, identify the people directly involved with:
18
initial deployment and installation of PATROL
PATROL managed node configuration and change management
ongoing user management, availability, and performance of PATROL Central

infrastructure
handling events and exception conditions raised by PATROL
Document the role or primary interest of each stakeholder. Typical stakeholders will
include System Administrators, Database Administrators, managers of business
applications such as SAP, PeopleSoft, or Oracle Financials, Operations personnel, and
PATROL Administrators. Key management sponsors or business partners may also
be listed. Include anyone who will be directly involved in the implementation or
needs to be kept informed of its progress.
Make a high-level diagram of the entire business enterprise to be managed using
PATROL, similar to the sample shown in Appendix C, Sample Solution Planning
Forms & Diagrams. While it need not be overly detailed, it must indicate any widearea, lower-speed (less than 10 Mb/sec), or other non-local network links, and any
firewalls, network switches, or other infrastructure that could impact connectivity. If
portions of a physical location are isolated by local firewalls, identify each isolated
area as a separate logical location and treat it as a physically separate location for the
remainder of the analysis process.
Make a copy of the Location Analysis Worksheet for each location shown on the
diagram and write the name of each location in the field provided on each worksheet.
Enter the firewall and network reliability information on each location worksheet.
Some PATROL Central components must reside on the same LAN speed/quality
network segment because WAN or other lower-speed/reliability connections will
degrade performance. Accurate connectivity information is key to the design process.
Enter the total number of nodes to be managed by PATROL on the worksheet for
each location. Include all systems where a PATROL Agent will be installed in this
count. This data is for environment sizing, so individual host names, OS vendors, and
other similar details are unnecessary.
List the name of each PATROL KM to be run on ANY managed node at each location.
This information is vital to estimating the total number of objects to be managed and
impacts PATROL Console Server placement and management profile definition.
Note any KM which may have an unusually high number of Application Class
instances. An example might be an operating system KM running on a large file
server with an unusually large number of disk and file system instances.
Enter on each worksheet whether or not PATROL Reporting will be used to
aggregate data from managed nodes at that location.
If events are to be forwarded from managed nodes to an event management tool,
enter the name of the destination tool on the worksheet for each location.
19
For each location where PATROL Central consoles are to be used, complete the
Visualization Information section of the worksheet.
To determine the number and placement of PATROL Console Servers, an estimate of
the number of managed objects to be concurrently visualized is needed. The number
of managed objects in a PATROL Console Server is the product of the number of
concurrent console sessions multiplied by the number of managed objects in each
session profile. The Visualization Information section of the worksheet is used to
document estimates for these factors.
Estimate by location the typical number of KMs needed per node, and enter that
information on each worksheet. Using the object count guidelines in the following
list, determine the total number of managed objects needed on the typical managed
node for each location and enter the number on each location's worksheet.
1000-2000 objects per large application KM (for example, PATROL for Microsoft
Exchange Servers or PATROL for BEA WebLogic)
450-800 objects per medium-sized KM (for example, PATROL for Unix and Linux,
PATROL for Microsoft Windows Servers, or PATROL for Oracle)
200 objects per small application KM (for example, PATROL for Compaq Insight
Manager or PATROL for Dell OpenManage)
NOTE
If a KM was previously identified as likely to have an unusually large number of Application
Class instances, increase the object count estimate accordingly.
Estimate the total number of PATROL Central Operator Microsoft Windows

Edition consoles to be installed at each location, add the estimated number of
concurrent PATROL Central Operator Web Edition users, and enter the total on the
worksheet.
Estimate the expected number of concurrently active console sessions for each type of
console at each location and record the information on the worksheet. Add the two
numbers and record the total number of concurrent console sessions.
Based on the monitoring and management needs of the console users, estimate the
average number of managed nodes that will be defined in each concurrent console
management profile and record it on the worksheet for each location.
Multiply the number of managed nodes in the typical management profile by the
number of managed objects on the typical managed node and record the result as the
number of managed objects in the typical management profile.
20
The number of concurrent managed objects limits the number of console sessions that
can be handled by a single PATROL Console Server. The object count is estimated by
multiplying the number of managed objects in the typical management profile by the
number of concurrent console sessions. Record the number on the worksheet for each
location as the total number of concurrent managed objects.
21
22
Chapter
PATROL Central Implementation

Logical Design
3
To be successful, a PATROL Central implementation must be carefully designed and

planned, giving careful attention to the limits and recommendations detailed in this
chapter. This chapter presents the following topics:
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RT Cloud Logical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RTserver Design Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Characterizing RTserver Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deciding Initial RTserver Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RTserver Backup/Failover Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Visualization Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Which PATROL Central Console is Appropriate? . . . . . . . . . . . . . . . . . . . . . . . . . .
Which Locations Need PATROL Console Servers? . . . . . . . . . . . . . . . . . . . . . . . . .
Is One PATROL Console Server Enough? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logically Sizing the PATROL Console Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Console Server Failover Considerations. . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Central Operator Web Edition Placement . . . . . . . . . . . . . . . . . . . . . . .
Visualization Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event Management Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notification Server Usage and Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Centralized Customization Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Designing for PATROL Management/Upgrade/ Patching . . . . . . . . . . . . . . . . . . . . .
Using the Distribution Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 3 PATROL Central Implementation Logical Design
24
24
24
26
26
26
28
28
28
29
30
30
32
32
33
34
35
36
36
37
23
Overview
Overview
In a general sense, the logical design step in the process involves adding to the
enterprise diagram produced in the previous chapter and indicating where various
PATROL Central infrastructure services will reside. The logical design phase is not
concerned with the physical devices that will provide these services, only with their
locations and in what numbers the services are needed.
The first refinement to the enterprise diagram centers on designing domains which
consist of managed nodes and one or more RTservers. In other documentation
and/or presentations, these domains have variously been referred to as "messaging
domains," "agent clouds," "RT clouds," and "clouds."
The second refinement addresses the visualization needs of the enterprise. It includes
numbers and placement of PATROL Central Operator Microsoft Windows Edition
installations, PATROL Console Servers, and PATROL Central Operator Web
Edition installation(s) (if browser-based visualization is needed). Design decisions
may result in RTservers dedicated to supporting visualization components. These
domains have also been referred to by several names, such as "console domain,"
"console cloud," "RT cloud," and "cloud."
In this document, where the association of RTservers with managed nodes is
important, the term "agent cloud" will be used. Similarly, "console cloud" will be used
to specify the combination of visualization components and RTservers. If the
association is not essential to the discussion, the more generic term "RT cloud" may be
used to describe either agent or console clouds.
RT Cloud Logical Design

ACTION 2
Make a separate diagram to accompany each location worksheet, similar to the one
shown in Appendix C, Sample Solution Planning Forms & Diagrams. These
diagrams will be used to visualize the placement of infrastructure services for each
location and will be needed when mapping the logical design to physical servers
later.
RTserver Design Considerations

The central component of PATROL Central infrastructure is the RTserver message
broker. Determining the placement and number of RTservers for each location is an
iterative process.
24
RTserver Design Considerations
The first step involves high-level RTserver placement based on the number of
managed nodes present and the characteristics of the message traffic the RTserver
will handle. Once basic RTserver placement has been completed, a review of the
enterprise will be conducted to identify potential points of unacceptable service
interruption in the event of an RTserver outage, and to consider strategies to reduce
the impact of any such outages.
It is generally desirable to design a self-contained RT cloud for each location with 50
or more managed nodes, placing RTservers in the same geographical location as the
managed nodes they support. Starting with the release of PATROL Central version
7.3, RTserver design decisions have become much simpler.
No RT cloud should include more than 500-700 managed nodes. If PATROL Reporting will
be used to aggregate data from a location, or if a Notification Server will be used, AND the
RTserver will be installed on the same node as either one, that RTserver can support no more
than 500 managed nodes.
Typically, an RT cloud will need no more than two RTservers (a primary and a
backup). Scalability is achieved by creating additional RT clouds rather than
configuring "hub and spoke" RTservers to create larger domains.
NOTE
An exception to this general rule is presented in Appendix A, Frequently Asked
Questionsin the question When should hub-and-spoke RT cloud architecture be used? on
page 62.
In the case of managed nodes within DMZs, many companies have policies dictating
the direction in which connections can be initiated to/from the DMZ. Typically,
connecting to a node in the DMZ from the corporate intranet is permissible but
connecting from a node in the DMZ into the intranet is not. In these scenarios, an RT
cloud can be created for each DMZ and PATROL Console Server can be configured to
connect to the RTservers in that RT cloud.
For additional information that may affect the number and placement of RT clouds,
see RTserver and RT clouds on page 57.
25
Characterizing RTserver Traffic
Characterizing RTserver Traffic

The type and volume of message traffic that RTservers must process impact the
required number and placement of RTservers for each location. If only console traffic
is handled, each RTserver can support a larger number of managed nodes. There are
two optional PATROL components that when installed on the same computer as the
RTserver will reduce the number of managed nodes per RTserver: PATROL
Reporting and the Notification Server.
Deciding Initial RTserver Placement

When creating a dedicated RT cloud for consoles, the primary RTserver should be placed on
the same computer as the PATROL Console Server and the backup RTserver should be
placed on a different computer. In cases where the PATROL Central Operator Web Edition
is hosted on a separate computer, the backup RTserver for the console cloud can be hosted
on the same computer as PATROL Central Operator Web Edition.
ACTION 3
Using the traffic characteristics and best practice recommendations for guidance,
update the solution diagrams for each location to reflect the number and placement of
RTservers.
RTserver Backup/Failover Considerations

Failure of any component of PATROL Central infrastructure will affect components
that rely on the one that fails. The severity of the impact and the time needed to
restore functionality can be reduced by providing backup components to take over if
a primary component fails. The process of automatic reconfiguration and resumption
of service using backup components is called failover.
When a failover occurs, the time required to restore full functionality depends on the
service involved and varies considerably from service to service. For failure of a
single service, the relative impacts and recovery times rank from least impact to most
impact in the following order:
26
RTserver Backup/Failover Considerations
1. An RTserver that is servicing managed nodes fails. In this case, all managed nodes
connected to the failed RTserver will be shown as disconnected in their respective
management profiles on all active consoles and the managed nodes will begin their
failover process (if available). Since a managed node RTserver typically services
only a portion of a given management profile, recovery times are shorter than for
services which impact an entire management profile.
2. An instance of PATROL Central Operator Web Edition fails. When this happens,
all browser-based sessions being served by the failed instance will cease to
function. Only browser-based sessions will be affected; any PATROL Central
Operator Microsoft Windows Edition sessions will continue to function.
3. An RTserver supporting a console cloud fails. When this happens, consoles served
by the failed RTserver will be unable to communicate with the PATROL Console
Server and will not be usable until the RTserver service is restored or the consoles
and PATROL Console Server establish communication through a backup RTserver
(if available).
4. A PATROL Console Server fails. As with a console RTserver failure, all console
sessions served by the failed PATROL Console Server will cease to function. For
more information, see PATROL Console Server Failover Considerations on
page 30.
The way in which a component goes offline also affects recovery time. If a component
is stopped gracefully, all other components recognize the loss almost immediately
and begin their respective failovers. If a component is lost unexpectedly due to a
power or hardware failure, abrupt system shutdown, or physical network
interruption, loss of the component may not be recognized by other components for
several minutes and recovery time may be lengthened.
If a PATROL Central design includes backup RTservers, place a backup RTserver in each RT
cloud. If a separate RTserver is provided to handle traffic between the PATROL Console
Server and PATROL Central consoles (or PATROL Central Operator Web Edition) and
redundancy is needed, place one backup RTserver in the console cloud.
ACTION 4
Review the solution diagrams for all locations, looking for areas where an RTserver
outage would create an unacceptable interruption of monitoring. If any such areas are
identified, reconfigure the RT cloud and add backup RTservers to allow the
infrastructure to continue to function if an RTserver service fails.
27
Visualization Design
Visualization Design
This phase of the design process involves determining the placement and number of
PATROL Console Servers (and optionally PATROL Central Operator Web Edition
instances) to support the anticipated level of PATROL Central console usage. At this
stage, placement decisions should be made without regard for the possibility of
sharing hardware with other services. The only consideration should be logical
placement of visualization services based on best practice recommendations.
There are multiple PATROL Console Server placement scenarios that will work for
nearly any given situation. The best practice recommendations presented here
represent a compromise between implementation complexity, run-time performance,
and recovery time in the event of a service outage.
Starting with the release of PATROL Central version 7.3, the PATROL Console Server
has the ability to visualize managed nodes from multiple RT clouds. This simplifies
PATROL Console Server placement design decisions.
Which PATROL Central Console is Appropriate?

Generally, PATROL Central Operator Microsoft Windows Edition is the
recommended management console for anyone other than a casual user. For users
who do not depend on access to the console to perform their primary job function, or
for those who do not access PATROL daily, PATROL Central Operator Web Edition
may be appropriate. Due to the architectural and component differences, the consoles
should not be viewed as completely interchangeable.
Do not attempt to use PATROL Central Operator Web Edition to visualize more than 200
managed nodes. Try to limit profiles to fewer than 100 managed nodes.
Use PATROL Central Operator Microsoft Windows Edition to visualize larger numbers of
managed nodes.
Which Locations Need PATROL Console Servers?

Begin by placing a single PATROL Console Server in the location with the highest
concentration of managed nodes. If network bandwidth and reliability are high, a
single PATROL Console Server may be able to service all console sessions.
28
Is One PATROL Console Server Enough?
If a location with console users does not have a local PATROL Console Server,
examine nearby locations for excess PATROL Console Server capacity that can be
used to service it. If no excess capacity exists, either an additional PATROL Console
Server must be installed at the remote location or a PATROL Console Server (and
potentially other PATROL Central infrastructure components) must be installed
locally. Bandwidth and reliability of the network connection to the remote location
must be factored into the decision to use a remote PATROL Console Server, since the
network link is a single point of failure.
The primary reason to install a PATROL Console Server where it would not
otherwise be justified is for improved performance. If console users in a particular
location only need to view managed nodes in the same location, the improved
reliability and performance gained by keeping network traffic local may justify the
additional administrative and equipment cost of an additional PATROL Console
Server.
Maintenance of multiple PATROL Console Servers requires additional
administrative work. While PATROL Console Server 7.5 introduced an online backup
capability, there are still no provisions for automatically copying data between
PATROL Console Servers, nor is there any functionality to synchronize or reconcile
changes when the same type of data (privilege assignments, for instance) has been
changed on two or more PATROL Console Servers. Operational policies and manual
procedures must be implemented to work around these limitations.
To arrive at an optimal design, each location must be evaluated independently and
PATROL Console Server placement decisions must be made on a case-by-case basis.
Is One PATROL Console Server Enough?

In some cases, more than one PATROL Console Server will be needed in a single
location. Factors in this decision include the number of concurrent console sessions
and the number of managed objects in concurrent management profiles.
The total number of managed objects known to the PATROL Console Server at any
given time imposes an absolute limit on the capacity of the PATROL Console Server.
Since the actual number of concurrent objects is impossible to determine precisely,
designs should not be sized to exactly match the managed object estimates on the
location worksheet. Some headroom must be provided to avoid the risk of PATROL
Console Server performance degradation or run-time failure.
Starting with the release of version 7.3 of PATROL Central infrastructure, the number
of concurrent managed objects known to the PATROL Console Server is limited by
the resources of the hardware hosting the PATROL Console Server, most notably
available virtual memory.
29
Logically Sizing the PATROL Console Server
Version 7.3 of the PATROL Console Server also introduced overload protection. The
overload protection feature allows the PATROL Console Server to reject additional
operator connections when they will cause preconfigured limits to be exceeded.
Regardless of the estimated number of concurrent managed objects, plan for no more than 25
(on 32-bit hardware) or 100 (on 64-bit hardware) concurrent console sessions to be served by
a single PATROL Console Server.
Logically Sizing the PATROL Console Server

ACTION 5
Review the solution diagram and worksheet for each location in light of the PATROL
Console Server sizing factors just discussed. Determine whether or not it will be
feasible to host the PATROL Console Server on 64-bit hardware. If such a system is
available, there is no hard object count limit. In practice, however, it is best to plan for
no more than 10 million concurrent managed objects in a single 64-bit PATROL
Console Server.
If the PATROL Console Server will be hosted on 32-bit hardware, there is a hard limit
of 3 million concurrent managed objects in a single PATROL Console Server.
Add an additional PATROL Console Server when the estimated concurrent managed object
count approaches 3 million (on 32-bit hardware) or 10 million (on 64-bit hardware) to leave
headroom in the design for additional, unanticipated use.
Update the solution diagram for each location to show the placement of primary
PATROL Console Servers.
PATROL Console Server Failover Considerations

There are two ways to provide redundancy for the PATROL Console Server:
30
Install the PATROL Console Server on high-availability cluster hardware, store the
configuration files on a shared disk, and define a cluster failover package that
includes the PATROL Console Server.
Install a secondary PATROL Console Server on a separate node and use the online
backup feature to periodically snapshot data from the primary PATROL Console
Server.
PATROL Console Server Failover Considerations
The only way to provide transparent service restoration in the event of a PATROL Console
Server failure is by using a high-availability cluster. In this scenario, the PATROL Console
Server service will be restarted by the cluster management software. Once restarted,
the console cloud will reestablish connectivity and console sessions will resume
functioning.
In the absence of high-availability hardware, a secondary PATROL Console Server
allows PATROL Central availability to continue during planned outages of the
primary PATROL Console Server or during a hardware or other failure local to the
primary PATROL Console Server node. A secondary PATROL Console Server does not,
however, provide unattended recovery for a failed primary PATROL Console Server.
If a secondary PATROL Console Server is activated in order to recover from an
outage, its configuration data (for example, profiles and impersonations) will only be
current to the last time the configuration files for the secondary PATROL Console
Server were copied from the primary PATROL Console Server. Depending on the
configuration of the online backup feature in the primary PATROL Console Server
and the network-shared disks between the primary and the secondary, administrator
intervention may be required to copy the latest data to the backup PATROL Console
Server and then restart it.
NOTE
Copying configuration files from a running or active PATROL Console Server is supported
only by using the online backup capability. Copying configuration files into a running or
active PATROL Console Server is not supported. When using the admin_copy tool, copying
configurations between PATROL Console Servers requires that both PATROL Console Server
processes be shut down.
After a secondary PATROL Console Server has been started either by highavailability cluster management software or through manual intervention, additional
time is required for console sessions to be reestablished. This additional time will
vary with the number and size of the management profiles involved.
The way in which a component goes offline also affects recovery time. If a component
is stopped gracefully (PATROL Console Server or RTserver), other components
recognize the loss almost immediately and begin their respective failovers. If a
component is lost unexpectedly due to a power or hardware failure, abrupt system
shutdown, or physical network interruption, loss of the component may not be
recognized by other components for several minutes and overall recovery time may
be lengthened.
For more information, see the PATROL Console Server and RTserver Getting Started
guide.
31
PATROL Central Operator Web Edition Placement

If uninterrupted access to the PATROL Console Server is required, plan to run it on highavailability hardware. If high-availability hardware is not available, consider whether or not
a secondary PATROL Console Server adds sufficient value to offset the additional hardware
and administrative cost.
ACTION 6
Using these best practice recommendations and the keeping in mind the failover
considerations discussed in this section, update the solution diagram for each
location to reflect the presence of any secondary PATROL Console Servers.
PATROL Central Operator Web Edition Placement

When browser-based visualization is needed in the enterprise, at least one instance of
PATROL Central Operator Web Edition must be installed. If browser-based
visualization is not needed, PATROL Central Operator Web Edition is not required.
A single instance of PATROL Central Operator Web Edition can serve 15-20
concurrent browser sessions depending on the size of the management profiles being
used. A conservative approach to sizing the initial design is recommended.
Install PATROL Central Operator Web Edition on the same node as the PATROL Console
Server that provides its interface into the PATROL Central infrastructure. If that is not
feasible, install the PATROL Central Operator - Web Edition as near as possible to the
consoles it will serve.
Plan for a single instance of PATROL Central Operator Web Edition to serve no more than
20 concurrent browser sessions.
Only one instance of PATROL Central Operator Web Edition may be installed on any
single node.
Visualization Performance Considerations

PATROL managed nodes should always be configured to preload the KMs used to
manage them. Preloading KMs also reduces the time required to establish and
initialize console sessions. Production managed nodes should be configured to run
ONLY preloaded KMs. This prevents unanticipated loading and unloading of KMs
when the management profile definition causes a connection to be initiated to the
managed node.
32
Event Management Planning
NOTE
Starting with version 7.5.00 of PATROL Central Operator Microsoft Windows Edition,
management profiles can be configured such that all KMs from an agents preloaded KM list
are loaded in the profile automatically. This feature allows profiles to automatically stay in
sync with changes to the preloaded KM list on each managed node.

Configure preloaded and disabled KMs appropriately on each managed node to minimize
the time required for agent startup and console session initiation.
If there are distinct groups of console users, PATROL Console Server performance
can be improved by configuring separate PATROL Console Servers for each group of
users. This approach is only practical if the enterprise is large and complex, and if
there is no need to share management profiles between groups.
If the console user community is large but there is overlap in management profile use,
it is better to host the PATROL Console Server on hardware with more capacity than
to divide the console session workload between PATROL Console Servers. The
additional manual effort needed to keep common management profiles synchronized
usually outweighs the performance improvement provided by a second PATROL
Console Server.
PATROL Central Operator Microsoft Windows Edition is fully supported under
Microsoft Windows Terminal Services. The memory requirement for each console
session depends on the number of concurrent managed objects, and the CPU
utilization depends on the activity of each console session. A good technique for
sizing the Terminal Services host system is to configure a typical session and multiply
its resource consumption by the anticipated number of concurrent console sessions.
Event Management Planning

Nearly all contemporary PATROL implementations are configured to generate and
forward events to an operations center for resolution. Tools from BMC Software and
other vendors are used to receive and manage resolution of events originating from
PATROL. PATROL managed nodes can generate events for a wide variety of reasons,
but many of these events, while useful when troubleshooting or reconstructing a
problem scenario, are of little help or interest to an operations center. Deciding which
events to forward and who should receive them is a key factor in satisfaction with
PATROL.
BMC Software provides a KM solution for event processing called the PATROL
Knowledge Module for Event Management (KM for EM). This KM serves multiple
functions, and when installed and preloaded on a managed node allows event
processing and filtering to be done at the source of the event. It also facilitates
33
Notification Server Usage and Placement
advanced configuration management from a central location using PATROL

Configuration Manager (PCM). PCM is addressed in greater detail elsewhere in this
guide, but it is important to note that some PCM functionality requires the KM for
EM to be active on the managed node.
There are two methods for forwarding events from PATROL Agents to event
management products that are not part of the PATROL architecture. Both methods
leverage the KM for EM on each managed node, but use different methods for
forwarding events.
"In-band" event propagation leverages the RT cloud and forwards events based on a
subscription model. Implementation of in-band event propagation requires
configuration of the PATROL Console Server and use of an add-in module, such as
BMC Impact Integration for PATROL version 7.1.01, PATROL Enterprise Manager
Console Server Connection version 7.1.00, or PATROL Integration for HP Network
Node Manager version 7.1.00. (These three products are known collectively as
Common Connect.)
"Out-of-band" event propagation relies on agent-to-agent communication using the
direct connection port of the agent (the default is 3181) . Most out-of-band
implementations use the KM for EM in a special configuration commonly known as a
Notification Server. Managed nodes forward trusted (filtered) events directly to the
Notification Server consolidation point. Event Management applications receive
events from the Notification Server.
Install and configure the PATROL KM for Event Management to be preloaded on all
managed nodes.
To minimize network traffic, configure the KM for EM on each managed node to create a
trusted event for all events to be forwarded.
PATROL KM for EM configuration is best administered using PCM.
Notification Server Usage and Placement

A Notification Server is a special configuration of a PATROL Agent running the KM
for EM. A Notification Server receives event messages from a group of managed
nodes, optionally pre-processes them, and forwards them to an event management
system.
34
Centralized Customization Management

Use a Notification Server or BMC Impact Integration for PATROL version 7.1.01,
PATROL Enterprise Manager Console Server Connection version 7.1.00, or

PATROL Integration for HP Network Node Manager version 7.1.00 to centralize
event pre-processing, filtering, and forwarding. If use of a Notification Server is permissible
and RT clouds can be limited to 500 or fewer managed nodes, install a Notification Server on
the same computer with the primary RTserver for each RT cloud. Regardless of its
placement, a single Notification Server can service no more than 500 managed nodes.
Centralized Customization Management

The PATROL Configuration Manager (PCM) is a GUI-based tool used to define and
distribute PATROL configuration settings from a central location to some or all
managed nodes. PCM can be used to manage configuration options such as
Preloading KMs
Poll times
Disabling selected application classes

Use PCM to centralize administration of managed node settings.
Placement of PCM in the enterprise is dictated by the needs of its users. A single
instance of PCM can propagate rulesets to all nodes across an enterprise, so its
geographical or network location is not critical. Distribution of rulesets through a
firewall requires an open port for PCM.
Some managed node attributes cannot be controlled using PCM because of the way
those attributes are implemented. An example is data collection blackout. Some KMs
are hard-coded to assure that their data collectors are available continuously, so if
data collection is stopped with PCM, the local KM code will automatically re-enable
it. Always verify compatibility of KM attributes before attempting to control them
with PCM.
PCM implements locking on its configuration files, so only one modification session
may be open at a time.
If responsibilities for the enterprise are divided among multiple administrators,
consider implementing separate PCM instances for each administrative team.
Include no more than 700 managed nodes in any agent group (agent.ini file). Configure PCM
to allow no more than 20 concurrent ruleset distributions.
35
Designing for PATROL Management/Upgrade/ Patching
Designing for PATROL Management/Upgrade/

Patching
PATROL Central infrastructure consists of a number of interdependent services
which must function together. The PATROL Infrastructure Monitor has been
developed to provide proactive infrastructure monitoring and to raise alerts if critical
services are interrupted. All PATROL Central implementations should use the
PATROL Infrastructure Monitor.
Install one instance of the PATROL Infrastructure Monitor to monitor the health of PATROL
Central infrastructure. A single instance can monitor all of the clouds in your environment.
For more information, see Appendix A, Frequently Asked Questions.
Using the Distribution Server

Placement of the Distribution Server (DS) in the enterprise is dictated by the needs of
its users. A single DS can deploy software to all nodes across an enterprise, so its
geographical or network location is not critical. Distribution of software through a
firewall requires an open port for the DS.
Use the Distribution Server to centralize PATROL software deployment to managed nodes.
NOTE
All components and patches for PATROL products are currently packaged for use
with the Distribution Server.

Verify the compatibility of components, patches, and hot fixes with Customer Support
before planning to deploy them with the DS.
There are no universal best practice recommendations for defining distribution

collections. Factors to consider, however, include
36
The more components defined in a collection, the greater the chance for a version
conflict and subsequent distribution failure
Deployment times are higher for large collections than for small ones
Security Considerations
Small collections deploy more rapidly than large ones, but may require multiple
reboots of the same computer (depending the software being deployed)
Large collections may require more administrative effort than small ones, since the
collection must be updated when any component in it changes
PATROL security level settings are defined by each customer's security policy and
are largely beyond the scope of this document except to state that PATROL Console
Server 7.5.00 supports the limited interoperability between consoles and agents
running at different security levels.
Starting with the 7.5.00 release, the RT cloud connection to a PATROL Console Server
can be configured with its own security level. All other components in that cloud
(agents and consoles) have to be at the same security level, but RT clouds at different
security levels can be connected to the PATROL Console Server transparently to the
consoles and agents in those different clouds. For more information, see the PATROL
Console Server and RTserver Getting Started guide.
37
38
Chapter
PATROL Central Environment

Physical Mapping
4

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Single Server Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RTserver Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Console Server Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Central Operator Web Edition Hardware . . . . . . . . . . . . . . . . . . . . . . .
PATROL Central Operator Microsoft Windows Edition Hardware . . . . . . . . .
Co-Hosting PATROL Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Console Server Platform Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RTserver Implementation Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RT Cloud Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Console Server Implementation Tips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clustering a PATROL Console Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 4
40
40
40
42
45
46
47
47
48
49
49
51
51
39
Overview
Overview
Once the logical design is complete, PATROL Central infrastructure components
must be assigned to specific servers. To accomplish this, all components must be
reviewed by type and assigned to computers in the solution diagram. This process
typically requires several passes through the design as the capacities of existing
servers and their abilities to host particular components are assessed.
ACTION 7
Using guidelines presented in this section, determine the hardware needed to host all
components identified in the logical design phase. Update solution diagrams to
reflect CPU, memory, and disk capacity of all infrastructure servers.
Hardware Requirements
The servers needed to host PATROL infrastructure vary in configuration based on the
components they are called upon to run and the workload they are required to bear.
While these factors vary widely from one environment to another, broad guidelines
are presented in the following sections to help with computer selection and
configuration. Except as noted, these computers are dedicated systems that only run
PATROL infrastructure and do not run major applications.
Single Server Environments

A single server hosting an RTserver, PATROL Console Server, and PATROL Central
Operator Web Edition can be used to manage an environment of up to 3 million
managed objects in a single RT cloud (with no more than 700 agents) provided the
computer is sufficiently powerful. The hardware requirements for various singlecomputer configurations are described in Table 1 on page 41 and Table 2 on page 41.
It is not typically necessary to host the PATROL Console Server on a high-end system. The
PATROL Console Server needs a fast CPU and a generous amount of RAM more than
exceptional network and disk I/O performance, and a workgroup class server will usually
suffice.
40
Single Server Environments
Table 1
Requirements for Small Single-Server PATROL Central Environment (Up to

500,000 managed objects)
Resource
Minimum Requirements
Recommendation
Processor
Linux and Windows
Linux and Windows
Single Processor
Intel Pentium III at 800 MHz
Solaris
Dual Processor
Solaris
Single Processor
SUN Netra X1 at 500 MHz
Dual Processor
SUN 420R UltraSPARC II at
450 MHz
AIX
AIX
Single Processor
IBM pSeries POWER 3 II at 450
MHz
Dual Processor
IBM pSeries POWER 3 II at 375
MHz
Server Memory
512 MB
1 GB
Disk Space
300 MB
300 MB
Table 2
Requirements for a Medium Single-Server PATROL Central Environment (Up

to 3 million managed objects)
Resource
Recommendation
Processor
Linux and Windows
Linux and Windows
Dual Processor
Intel Pentium 4 at 2000 MHz
Xeon
Solaris
Quad Processor
Solaris
Dual Processor
SUN V240 UltraSPARC III at
1000 MHz
AIX
Quad Processor
SUN V480/880 at 900 MHz
AIX
Dual Processor
IBM pSeries POWER 4 at 1000
MHz
Quad Processor
MHz
Server Memory
3 GB
4 GB
Disk Space
1 GB
2 GB
Chapter 4
41
RTserver Hardware
RTserver Hardware
If the requirements of a PATROL infrastructure server exceed the recommended
capacity of a single computer or if special circumstances warrant, RTservers can be
installed on separate computers (primarily to support one or more clouds of PATROL
Agents). In such circumstances it is usually best to choose a computer with a
relatively fast CPU and large memory in order to allow the RTserver to maintain high
throughput under peak conditions. This need notwithstanding, a dedicated RTserver
computer will typically have spare capacity for use by other PATROL infrastructure
components such as a Notification Server or a PATROL Reporting aggregator. There
are scenarios where multiple RTservers can be hosted on the same computer to
reduce the hardware costs associated with hosting PATROL infrastructure.
Table 3 shows the hardware requirements for a single RTserver running on a
dedicated computer, separate from the PATROL Console Server or PATROL Central
Operator Web Edition.
Table 3
Requirements for One RTserver on a Dedicated Computer (Up to 750 RT

clients)
Resource
Recommendation
Processor
Linux and Windows
Linux and Windows
Single Processor
Solaris
Single Processor
SUN UltraSPARC IIi at 400
MHz
AIX
Single Processor
IBM pSeries POWER 3-II at 333
MHz
Single Processor
Intel Pentium 4 at 1.4 GHz
Solaris
Single Processor
SUN UltraSPARC IIe at 500
MHz
AIX
Single Processor
MHz
Server Memory
512 MB
1 GB
Disk Space
300 MB
300 MB
Starting with the release of RTserver version 6.5.01, PATROL Central supports
configurations with more than one RTserver on the same computer. Depending on its
speed and workload (the total number of RT clients connected to all RTservers on the
computer), a single computer can host up to four RTservers. Table 4 on page 43 and
Table 5 on page 44 show the recommended hardware for different workloads:
42
RTserver Hardware
Table 4
Requirements for Two RTservers on a Dedicated Computer (Up to 1000 total

RT clients)
Resource
Recommendation
Processor
Linux and Windows
Single Processor
Solaris
Single Processor
SUN UltraSPARC IIe at 500 MHz
AIX
Single Processor
IBM pSeries POWER 3-II at 375 MHz
Server Memory
1 GB
Disk Space
300 MB
Chapter 4
43
RTserver Hardware
Table 5
Requirements for Two to Four RTservers on a Dedicated Computer (Up to

2000 RT clients)
Resource
Recommendation
Processor
Linux
Dual Processor
Solaris
Single Processor
SUN V210 UltraSPARC IIIi at 1 GHz or
Dual Processor
SUN 280R UltraSPARC III at 750 MHz
AIX
Single Processor
IBM pSeries POWER 4 at 1200 MHz or
Dual Processor
IBM pSeries POWER 3 II at 375 MHz
Windows
No more than two RTservers can run on the
same Windows-based computer. For more
information on configuration, see
RTserver Hardware on page 42.
Server Memory
2 GB
Disk Space
300 MB
For more information about configuring more than one RTserver to run on the same
computer, see the PATROL Console Server and RTserver Getting Started guide.
When running more than one RTserver on the same computer, the number of backup
and primary RTservers on the same system should be balanced. If two agent RT
clouds are supported by two computers, for example, one computer should serve as
the primary for cloud A and the backup for cloud B while the other computer serves
as the primary for cloud B and the backup for cloud A. This distributes the workload
across both RTservers and minimizes the impact of losing a single computer.
44
PATROL Console Server Hardware
PATROL Console Server Hardware

Table 6 describes minimum and recommended hardware for PATROL Console
Server version 7.5.00 in medium (up to 3 million managed objects) and Table 7 on
page 46 describes large (up to 10 million managed objects) environments.
It is not typically necessary to host the PATROL Console Server on a high-end system. The
PATROL Console Server needs a fast CPU and a generous amount of RAM more than
exceptional network and disk I/O performance, and a workgroup class server will usually
suffice.
An RTserver can be run on the PATROL Console Server computer to support a cloud
of PATROL Central consoles, but all agent RT clouds should be hosted on other
hardware.
Set PATROL Console Server overload protection limits based on the estimated workload of
each PATROL Console Server in the solution design. For more information about overload
protection and the type of limits that are available, see the PATROL Console Server and
RTserver Getting Started guide.
Table 6
Requirements for a Medium PATROL Console Server Environment (Up to 3

million managed objects)
Resource
Recommendation
Processor
Linux and Windows
Linux and Windows
Dual Processor
Solaris
Dual Processor
Solaris
Dual Processor
SUN 280R UltraSPARC III at
750 MHz
AIX
Dual Processor
SUN V240 UltraSPARC IIIi at 1
GHz
AIX
Dual Processor
MHz
Dual Processor
MHz
Server Memory
3 GB
4 GB
Disk Space
1 GB
2 GB
Chapter 4
45
PATROL Central Operator Web Edition Hardware
Table 7
Requirements for a Large PATROL Console Server Environment (Up to 10

million managed objects)
Resource
Recommendation
Processor
Linux
Linux
Dual Processor
Intel/HP Itanium 2 at 900 MHz
Solaris
Dual Processor
SUN V240 at 1280 MHz
AIX
Dual Processor
MHz
Quad Processor
Intel/HP Itanium 2 at 900 MHz
Solaris
Quad Processor
SUN V480/880 at 900 MHz
AIX
Quad Processor
MHz
Windows
Due to the virtual memory
limitations of 32-bit hardware,
large PATROL Console Server
configurations cannot be
hosted on a single Windows
computer.
Server Memory
4 GB
6 GB
Disk Space
3 GB
4 GB
PATROL Central Operator Web Edition Hardware

At the time this guide was written the Performance, Scalability, Reliability &
Interoperability (PSRI) lab had not completed an assessment of the most recent
release of PATROL Central Operator Web Edition. Hardware recommendations for
hosting this component of PATROL infrastructure will be provided when an
assessment is complete. Contact BMC Software and the PATROL Line Of Business for
updated information.
46
PATROL Central Operator Microsoft Windows Edition Hardware
PATROL Central Operator Microsoft Windows Edition

Hardware
Table 8 lists hardware requirements for different profile sizes:
Table 8
Resource
Requirements for PATROL Central Operator Microsoft Windows Edition

(based on profile size)
Recommendation
Small Profiles (up to 100 managed agents)

Processor
Memory
Single Processor
128 MB
Medium Profiles (up to 500 managed agents)

Processor
Memory
Single Processor
512 MB
Large Profiles (up to 1200 managed agents)

Processor
Memory
Single Processor
1 GB
NOTE
Profiles with 500 or more agents take several minutes to finish loading.
Co-Hosting PATROL Components

The following recommendations provide direction on which PATROL components
can reside with one another on the same host:
Chapter 4
47
PATROL Console Server Platform Selection
All infrastructure components can now coexist with other infrastructure components
provided the host has sufficient memory and CPU bandwidth.
A Common Connect client (for example, the PEM CSE client) can be installed on the
same host as the PATROL Console Server and RTserver.
The system requirements of the PATROL Console Server are relatively high, so when
possible place the PATROL Console Server and RTserver on a dedicated host. Try to
keep that system free of other applications.
If the underlying platform is supported by both components, an RTserver should be

installed on the same host as the PATROL Console Server, and the PATROL Console
Server and PATROL Central consoles should be configured to connect to this RTserver.
This arrangement will minimize the overhead of communication between the console
and the PATROL Console Server.
Never install a PATROL Console Server or RTserver on a computer running any of the
following products:
PATROL End-to-End Response Timer version 1.1.03 and earlier

PATROL Central Alerts Web Edition (specific to version 7.1.00 only)
Always check product release notes to obtain the latest information about
incompatibilities and configuration techniques for co-locating components.
PATROL Central Operator Web Edition version 7.1.10 cannot be installed on the same
computer as PATROL Central Alerts Web Edition version 7.2.01. See the following
Product Flash for further information:
http://documents.bmc.com/supportu/documents/37/38/43738/Output/090f44b1802
82615.htm
PATROL Console Server Platform Selection

Although there were circumstances under which prior releases of the PATROL
Console Server performed better on 32-bit Intel servers than on Sun servers, this is no
longer the case. Version 7.5.00 of the PATROL Console Server can be implemented on
either platform with equal efficiency.
Environments with up to 3 million managed objects or 25 concurrent users can be hosted on
32-bit hardware. Environments with up to 10 million managed objects or 100 concurrent
users must be hosted on 64-bit hardware.
48
RTserver Implementation Tips
A PATROL Console Server on 32-bit hardware that supports 3 million objects

requires more than 3 GB of application virtual memory. On Intel x86 hardware,
RHAS 2.1 supports 3 GB of application virtual memory and RHEL 3.0 supports 4 GB.
By default,
Windows is limited to 2 GB of virtual memory but can be coaxed into supporting 3
GB by using an optional argument (/3GB) in the boot.ini file; versions of Windows
that support this option include
Windows Server 2003
Windows Server 2003, Enterprise Edition
Windows Server 2003, Datacenter Edition
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
RTserver Implementation Tips

The following recommendations provide direction on implementing PATROL
RTservers:
When the environment or the hardware mandates the presence of multiple RT clouds,
provide an RTserver for PATROL Central clients that is separate from the RTserver used
by the PATROL Agents. The RTservers used to implement the console RT cloud can be
hosted on the same computers as the PATROL Console Server and PATROL Central
Do not direct connect more than 700 PATROL Agents to a single RTserver or RT cloud.
RTservers should be geographically close to the client computers they support.
Place RTservers on the same side of a firewall as their connected clients.
RT Cloud Configuration
RTservers are capable of handling large numbers of client connections and can be
configured to support messaging failover through appropriate client configuration.
Their proper configuration is key to the performance and stability of a PATROL
Central implementation.
Chapter 4
49
RT Cloud Configuration
Two or more RTservers in the same infrastructure create what BMC Software refers
to as an RT cloud (or sometimes a messaging domain). An RTserver can join an RT
cloud in either of two ways:
1. By obtaining the names of other RTservers in an RT cloud from its configuration
file (rtserver.cm)
2. By invitation from another RTserver
When deciding which RTservers should establish connections with others, there are
guidelines which will prevent and/or reduce unexpected performance and stability
issues:
Ensure that communication between any two RTservers is unidirectional; never let the
server_names variable in the configuration files of two RTservers contain one another's
names.
For the simple case of a cloud containing just a primary and a backup RTserver, set the
server_names variable in the primary RTserver to UNKNOWN and set the
server_names variable in the secondary RTserver to point to the primary RTserver.
Plan and control the direction of initialization through firewalls. The preferred
configuration consists of separate RT clouds within each DMZ, with the PATROL
Console Server initiating connections to each through the firewall.
If several DMZs or remote sites are linked into a single RT cloud using hub-and-spoke
architecture, the directional connections should be configured as follows. To permit
server RT-1 within the corporate intranet to contact server RT-2 on the other side of the
firewall and invite it to join the RT cloud, put the name of RT-2 in the server_names
variable on RT-1 and set the server_names variable on RT-2 to "UNKNOWN". This will
prevent RT-2 from joining unless RT-1 establishes the relationship.
Do not assign more than two RTservers to a server_names variable; experience has
shown it to be of no benefit.
If an RT cloud consists of just two RTservers, use the following guidelines:
50
Set the max_client_conns to the same value in both RTservers.

Configure all RT clients in the RT cloud to specify primary and backup RTservers in
the same order (i.e., do not split the RT clients between the two computers).
PATROL Console Server Implementation Tips
PATROL Console Server Implementation Tips

If the PATROL Console Server will host 50-100 users, consider the following
recommendations when you plan your implementation:
Increase the configuration parameter threadPoolSize to 8 or 12. This configuration

variable controls the number of threads created to handle concurrent requests. This
recommendation is applicable only on computers with 4 or more processors, for
example, computers that are capable of true multiprocessing. For more
information on configuring the number of process thread pools, see the PATROL
Increase the configuration parameter autoSaveTimer. This parameter controls the

frequency with which profiles open in read-write mode are automatically saved to
disk. The default value is 7.5 minutes. With a large number of read-write profiles
opened concurrently, the auto-save feature can generate a lot of additional disk
I/O. Consider increasing this value to 10 or 15 minutes. For more information on
configuring a management profile, see the PATROL Console Server and RTserver
Getting Started guide.
If you use the online backup capability, consider the maximum number of
concurrent read-write profile users when determining the frequency of the online
backup schedule, especially in cases where relatively large profiles (more than 200
agents) are opened for read-write use on a regular basis. Backup frequencies of
once per hour or longer will minimize performance impact in large environments.
Depending on the disk I/O performance of the PATROL Console Server computer,
the backup frequency can be increased or decreased.
Clustering a PATROL Console Server

In a cluster configuration, applications can move from one cluster node to another
when necessary. While the PATROL Console Server can be configured to support
high availability clustered environments, there are several installation and
configuration requirements:
Chapter 4
51
Clustering a PATROL Console Server
Install separate copies of the PATROL Console Server on local private disks of
each participating host in the cluster.
Use configuration overrides (environment variables) to direct each instance of

the PATROL Console Server to a set of common directories on a shared drive
containing all of the runtime configuration data.
Use the same configuration information for all hosts in the cluster.
Use the same impersonation database for all hosts in the cluster.
Use the same access control database for all hosts in the cluster.
Use the same Management Profiles for all hosts in the cluster.
Use the same PATROL Console Server log files for all hosts in the cluster.
Note that certain types of security-related configuration changes applied on one

node are not automatically replicated to other nodes in the cluster by means of
the environment variable overrides. The environment variable overrides allow
sharing of the configuration data that is typically changed on a day-to-day basis.
The security-related configuration changes are typically made once per node.
These changes must be done manually for each node so that both nodes have
equivalent security policy settings.
For more information on replication, see the PATROL Console Server and RTserver
Getting Started guide.
52
Chapter

Order of Installation and Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Planning Ahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Chapter 5
53
Order of Installation and Configuration
Order of Installation and Configuration

In order to minimize the implementation effort required, PATROL Central
infrastructure components should generally be installed and configured in the
following order:
Install the Distribution Server
Perform the following steps for every RT cloud, one cloud at a time:
A. Install RTservers
B. Install PATROL Agents on all managed nodes
Use PATROL Configuration Manager to configure all PATROL Agents
Install the PATROL Console Server and configure it to service the required RT
clouds
Configure the PATROL Console Server for users
Set RT cloud rights and privileges
Planning Ahead
As a matter of good planning, it is helpful to determine in advance those systems
where special privileges are needed to install, configure, and test PATROL
infrastructure. Whenever possible, early arrangements should be made for creation of
the necessary accounts and privileges and for assistance from appropriate system
administrators. If changes require that any systems be re-booted before they take
effect, those activities should be coordinated in advance so that users are not
interrupted and normal business is not disrupted. The Stakeholder Roster completed
during the Analysis Phase can be used to identify people who may be affected.
54
Appendix

This appendix presents the following topics:
RTserver and RT clouds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
How do clients connect to an RTserver? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
How many agents can connect to a single RTserver? . . . . . . . . . . . . . . . . . . . . . . . 57
How many agents can connect to a single RT cloud? . . . . . . . . . . . . . . . . . . . . . . . 58
How many RT clouds can be connected to a single PATROL Console Server? . 58
How many RTservers can be connected in a single cloud? . . . . . . . . . . . . . . . . . . 59
What is the best RT cloud configuration? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
When are multiple RT clouds recommended? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
When should hub-and-spoke RT cloud architecture be used? . . . . . . . . . . . . . . . . 62
Which multi-cloud configurations should be avoided? . . . . . . . . . . . . . . . . . . . . . 64
Can RTserver versions 6.2, 6.5.01, and 6.6 be mixed in the same cloud? . . . . . . . 68
How should version 6.2-based hub-and-spoke clouds be migrated to 6.6.00? . . 68
How can RTservers be configured to communicate through a firewall? . . . . . . . 73
PATROL Console Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
How many users can a PATROL Console Server support? . . . . . . . . . . . . . . . . . . 73
How many agents can a PATROL Console Server support? . . . . . . . . . . . . . . . . . 74
Which versions of the PATROL Agent should be used with the PATROL Console
Server? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
How many RT clouds can be connected to a PATROL Console Server? . . . . . . . 75
What can be done to prevent the PATROL Console Server from becoming
overloaded? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
How can a PATROL Console Server be backed up? . . . . . . . . . . . . . . . . . . . . . . . . 75
How is a backup PATROL Console Server started? . . . . . . . . . . . . . . . . . . . . . . . . 76
Are the locations of PATROL Central files and directories documented
anywhere? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
What should I do if I see a message in the PATROL Console Server log file
indicating duplicate RTservers? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
PATROL Central Operator Web Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
How many users can PATROL Central Operator Web Edition support? . . . . . 77
How large a profile can PATROL Central Operator Web Edition support? . . . 77
Why are console-side KM commands inactive on PATROL Central Operator
Web Edition? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Appendix A
55
PATROL Central Operator Microsoft Windows Edition. . . . . . . . . . . . . . . . . . . . . . . 77

How large a profile can PATROL Central Operator Microsoft Windows Edition
support? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
What version of PATROL Central Operator Microsoft Windows Edition is
recommended?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
PATROL Infrastructure Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Should I use the former PATROL Infrastructure Knowledge Module or
PATROL 7 Knowledge Module to monitor my PATROL Central 7.5.00
infrastructure? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
What versions of the PATROL Central infrastructure are supported by the
PATROL Infrastructure Monitor?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
How can more than one RT cloud be monitored with the PATROL Infrastructure
Monitor? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Other Components & Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Are there any OS dependencies for PATROL Central infrastructure? . . . . . . . . . 80
Is PATROL Central infrastructure supported on iSeries? . . . . . . . . . . . . . . . . . . . . 80
implementation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Why can't all aspects of KM operation be managed with PCM? . . . . . . . . . . . . . . 81
How are PCM rulesets used to best advantage? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
56
RTserver and RT clouds
RTserver and RT clouds

This section lists common questions and issues related to the RTserver and creating
and implementing RT clouds.
How do clients connect to an RTserver?

Each PATROL component must be configured to talk to one or more specific
RTserver processes. This configuration is performed by assigning one or more logical
RTserver connection names to a configuration variable for each PATROL component
that connects to an RT cloud.
For example, to connect PATROL Central Operator Microsoft Windows Edition to
an RTserver process, use the Windows operating system to assign an RTserver
process address (such as "tcp:houston103.bmc.com:3348") to the environment
variable called RTSERVERS.
NOTE
With the release of PATROL Agent version 3.5.32.08, it is possible to configure RTserver
connection information with a PCM rule. The object name is "/AgentSetup/rtServers" and its
value is the configuration string (for example, value = tcp:bmchost:2059,tcp:bmchost2:2059).
With the release of PATROL Central Operator Microsoft Windows Edition version
7.2.00 it is possible to configure RTserver connection information through the GUI.
For more information, see the PATROL Console Server and RTserver Getting Started
guide.
How many agents can connect to a single RTserver?

The recommended limit for the number of agents that connect to a single RTserver is
700. Each RTserver can handle no more than 750 connections for all types of client
applications. In this context, a client application includes not only the PATROL
Agent, but also any PATROL application that connects to the RT cloud. Examples of
other applications that connect to the cloud include the PATROL Console Server,
each PATROL Central console user, the PATROL Infrastructure Monitor, the
PATROL Reporting aggregator, and many of the command line utilities described in
the PATROL Console Server and RTserver Getting Started guide.
Appendix A
57
How many agents can connect to a single RT cloud?
In cases where only PATROL Central consoles are using the cloud, the recommended
limit of 700 agents provides for an additional 50 RT connections for other types of
PATROL applications. In cases where PATROL Reporting or Common Connect are
using the cloud as well, the recommended limit for the number of agents is 500 (550
total RT clients).
The RTserver configuration option max_client_conns controls the maximum number
of connections to the RTserver. The default value for RT 6.6.00 is 500, but it may be
increased to any value less than or equal to 750.
How many agents can connect to a single RT cloud?

The maximum number of agents in a single RT cloud is the same as the maximum
number of agents on a single RTserver: 700.
Starting with the release of the PATROL Console Server version 7.3.00 and RTserver
version 6.5.01, scalability for enterprises with more than 700 agents is best achieved
by adding RTservers to form new RT clouds rather than by adding RTservers to an
existing cloud. Generally speaking, use of the hub-and-spoke RT cloud architecture is
deprecated in favor of separate RT clouds that each link to the PATROL Console
Server; an example of a multi-cloud configuration is provided in the question What
is the best RT cloud configuration? on page 59. There is still one scenario in which
hub-and-spoke architecture is appropriate, however, and that exception is presented
in the question When should hub-and-spoke RT cloud architecture be used? on
page 62.
In the simplest scenario, a single RT cloud has only two RTservers (a primary and a
backup) and all clients are typically connected to just one of the RTservers (each of
which has max_client_conns set to the same value).
How many RT clouds can be connected to a single PATROL

Console Server?
There is no fixed limit on the number of RT clouds that can be connected to a
PATROL Console Server. The largest configurations tested in the Performance,
Scalability, Reliability and Integration (PSRI) lab, however, consist of 10 RT clouds
and most PSRI test cases are executed with 2-6 RT clouds.
Scenarios that require more than 10 RT clouds should be reviewed by BMC Software
and the PATROL Line Of Business before a design is adopted, and in no case later
than the initial stages of technical evaluation.
58
How many RTservers can be connected in a single cloud?
How many RTservers can be connected in a single cloud?

No more than 12 RTservers should be combined in the same cloud. Starting with the
release of RTserver version 6.5.01, however, the recommended strategy to extend RT
scalability is to create additional clouds of just a few RTservers rather than to add
RTservers to an existing cloud. Typically, two RTservers in a single cloud are
sufficient for most environments. The exception to this recommendation is a special
case in which a hub-and-spoke design may be required; this exception is presented in
question When should hub-and-spoke RT cloud architecture be used? on page 62.
What is the best RT cloud configuration?

The best advice for RT cloud configuration is to keep it simple. In previous releases,
BMC Software recommended an RT cloud architecture based on a hub-and-spoke
model. This RT configuration is no longer generally recommended, however, since a
pair of RTservers can handle the same amount of traffic as 3-4 version 6.2 RTservers
in a hub-and-spoke configuration. An exception to the no-hub-and-spoke rule still
exists when several small, remote offices are interconnected, however, and this
exception is presented in question When should hub-and-spoke RT cloud
architecture be used? on page 62.
In some circumstances only one RT cloud is necessary. These circumstances are
determined by a combination of available hardware capacity and the size of the
monitored environment, and are discussed elsewhere in this guide.
When a single cloud is not sufficient, multiple clouds should be defined and PATROL
Agents and PATROL Central consoles should be connected to separate clouds.
Depending on the number of agents present, more than one cloud of agents may be
necessary. This type of configuration separates agent-to-console-server message
traffic from console-to-console-server message traffic. When using a dedicated cloud
for consoles, the RTservers for that cloud can be hosted on the same computers as the
PATROL Console Server and PATROL Central Operator Web Edition.
Figure 1 on page 60 shows a multi-cloud configuration with three clouds.
Appendix A
59
What is the best RT cloud configuration?
Figure 1
Example of a Multiple RT Cloud Configuration
Some other notes on RT cloud configuration:
60
Configuration of multiple clouds is fundamentally an exercise in configuring the

PATROL Console Server. For more information on multi-cloud configuration in
the PATROL Console Server, see the PATROL Console Server and RTserver Getting
Started guide.
Keep the setting for max_client_conns the same for all RTservers in the same cloud.
This ensures that if a failover occurs, the backup RT will be able to accept as many
connections as the primary.
When are multiple RT clouds recommended?
If an environment has a single cloud or a dedicated cloud for consoles, place the
primary RT server on the same computer as the PATROL Console Server and the
backup RTserver on the same computer as PATROL Central Operator Web
Edition.
An exception to this rule exists for cases where platform support for the RTserver
differs from that of the PATROL Console Server or PATROL Central Operator
Web Edition. In such cases, RTservers must be placed on separate computers from
the PATROL Console Server or PATROL Central Operator Web Edition.
In the case of a two-RTserver cloud, all RT clients connected to the cloud should
have the same RT locator string to ensure that they use the same RTserver for
primary and backup. For instance, in Figure 1 on page 60 the order of RTservers
for the "Consoles" cloud is the same in PATROL Central Operator Microsoft
Windows Edition, in PATROL Central Operator Web Edition, and in the
Acfg_7_1_0_RTCloud_Connection configuration instance for the PATROL
Console Server.
When are multiple RT clouds recommended?

A single RT cloud can handle up to 750 RT clients. Of those 750 RT clients, typically
no more than 700 are PATROL Agents. An additional RT cloud can be created in
cases where a single RT cloud is not sufficient to handle the total number of RT
clients.
Additional clouds are also warranted any time a remote location has more than 50
PATROL Agents. In such remote-office scenarios, it is more efficient for the PATROL
Console Server to connect to an RTserver stationed in the remote office rather than for
agents in the remote office to connection to an RTserver in a central location. If there
are multiple remote locations with more than 50 agents apiece, each remote office
should have its own RT cloud hosted on hardware residing in the remote office (one
primary and one backup RTserver). If the number of dedicated clouds for remote
offices grows too large, several remote offices can be linked into a single cloud based
on the hub-and-spoke architecture. Hub-and-spoke architecture is presented in the
question When should hub-and-spoke RT cloud architecture be used? on page 62.
If remote offices exist with fewer than 50 agents, the agents in those offices can be
connected to an RTserver in another location. Keep in mind that an enterprise's
security policies may require remote offices to connect to an RTserver in the DMZ
rather than to one inside the corporate firewall.
In some corporations, network security policies prohibit network connections that are
initiated from less secure zones into more secure zones. This means that a PATROL
agent in the DMZ is prohibited by company policy from connecting to an RTserver
inside the corporate firewall. In the past, BMC Software recommended that these
scenarios be addressed by placing one or more RTservers in the DMZ and another
Appendix A
61
When should hub-and-spoke RT cloud architecture be used?
behind the corporate firewall, and by configuring the RTserver behind the firewall to
connect to the RTserver(s) in the DMZ. Starting with PATROL Console Server version
7.3.00, an alternative configuration is preferred. Instead of using RTserver-toRTserver connections across the firewall, RTservers in the DMZ can be configured as
a standalone RT cloud and the PATROL Console Server inside the firewall can
connect directly to the RT cloud in the DMZ. For added security, the PATROL
Console Server configuration for each cloud includes an option that prevents the
PATROL Console Server from advertising its presence. For more information on this
option, see the PATROL Console Server and RTserver Getting Started guide.

Starting with the release of PATROL Console Server version 7.3.00, use of hub-andspoke configurations has been generally deprecated. An exception exists, however,
when the number of remote offices requiring a local RTserver (offices with more than
50 agents) exceeds 10. Under these circumstances, several remote offices can be joined
into one cloud using a hub-and-spoke configuration when the following conditions
are met:
The total number of agents in the hub-and-spoke cloud does not exceed 700.
The total number of RTservers in the hub-and-spoke cloud does not exceed 12.
Keep in mind that each remote office should have two RTservers.
The hub RTserver should be positioned on the same side of the WAN connection
as the PATROL Console Server.
Figure 2 on page 63 shows a simple example of hub-and-spoke architecture.
62
Figure 2
Example of Multiple RT Clouds with Hub and Spoke
Building on the example in Figure 2, the cloud named "Agents 2" has been modified
to use a hub-and-spoke configuration. The hubs are RTservers E and F. The RTservers
in each remote office serve as spokes. In this example, all of the RTservers in remote
offices should be configured with their server_names option set to
Appendix A
63
Which multi-cloud configurations should be avoided?
tcp:E:2059,tcp:F:2059. Note that the total number of RTservers in the "Agents 2" cloud
is 10 (below the limit of 12). If each remote office has 50 agents, the total number of
agents in the central office (those connected to RTservers E and F) should not exceed
500 (700 max - (4 x 50)).

In particular, there are three scenarios unique to the new multi-cloud capability that
represent configuration mistakes. These scenarios can create performance problems,
produce unreachable agents, or cause agents to report incorrect connection status.
In the first scenario, more than one agent with the same RT service ID exists in
different clouds. When this happens, all agents with the same RT service ID are able
to connect to their RT cloud but the PATROL Console Server only accepts the first
agent it sees. The other agents are ignored by the PATROL Console Server, which
writes the following warning message to the PATROL Console Server log file:
"Duplicate service name found: /cos/svs/PATROL_AGENT_serviceID"
where serviceID is the RT service ID of the duplicate agent (for more information on
RT service IDs, see the PATROL Console Server and RTserver Getting Started guide).
This cannot occur in a single cloud because the RTserver prevents agents with
duplicate IDs from connecting in the first place. In a multi-cloud configuration, the
PATROL Console Server enforces service ID uniqueness by ignoring duplicates. The
default RT service ID for each agent is based on the host name of the computer where
the agent is running. In some cases, configuring the agent's host to specify the fully
qualified domain name is sufficient to insure uniqueness. Alternatively, the agent can
be configured to use a specified service ID (e.g. PatrolAgent id yourUniqueIdHere).
In the second scenario, the PATROL Console Server has been configured for two or
more separate RT clouds but in fact the RTservers are in the same physical cloud.
There are many conceivable configurations that may result in this scenario; Figure 3
on page 65 illustrates one such configuration. In this example the link from RTserver
D to RTserver E creates one physical cloud, where the PATROL Console Server
configuration indicates that there should be two separate clouds.
64
Figure 3
Example of Cross-Linked RT Clouds
PATROL Console Server 7.5.00 records the following types of log messages when it
encounters this second scenario:
ERROR:1/25/2005 10:09:22 AM:::RT Cloud 'Agents - 1' has duplicate
rtservers with RT cloud 'Agents - 2'
WARNING:1/25/2005
10:09:22AM:COS_BASE_SUBS:::cos_framework.cpp(663):Cloud[Agents - 2]
RTServer[0]: /_C_8401
WARNING:1/25/2005 10:09:22
AM:COS_BASE_SUBS:::cos_framework.cpp(663):Cloud[Agents - 2]
Appendix A
65
RTServer[1]: /_D_8293
WARNING:1/25/2005 10:09:22
RTServer[2]: /_E_8312
WARNING:1/25/2005 10:09:22
RTServer[2]: /_F_8927
ERROR:1/25/2005 9:23:19 AM:::RT Cloud 'Agents - 1' has duplicate
rtservers with RT cloud 'Agents - 2' forcing disconnect.
INFORM:1/25/2005 9:23:19 AM::11.221:Disconnecting from 'Agents - 2'
In general, these types of messages are an indication that there is a problem either
with the RT to RT configurations or the definition of the RT clouds in the PATROL
Console Server configuration. To correct these problems, list the RTservers identified
in each of the PATROL Console Server configuration entries for the cloud names
listed in the message. For each of those RTservers, locate the server_names option in
their respective rtserver.cm files. Based on the server_names values, map out the RT to
RT connections and compare that to the list of RTservers from the PATROL Console
Server configuration entries. Depending on what you find, correct either the PATROL
Console Server configuration file or the RT to RT configuration to eliminate the
redundancy. In this particular example, the problem is in the RT to RT configuration
for Rtserver D.
NOTE
Changes to PATROL Console Server configuration require a restart of the console sever, and
changes to RTserver configuration require a restart of the RTserver.
In the third scenario, a PATROL Agent's RTSERVERS setting specifies RTservers in

different clouds. Failover from one cloud to another is not supported for any
PATROL application, including PATROL Agents. The symptoms in this case will be
similar to those exhibited in the first scenario: the PATROL Console Server will
ignore the agent's failover connection if the agent's reconnect notification from the
second cloud arrives before its disconnect notification from the first cloud. Figure 4
on page 67 illustrates one such configuration. In this example, each PATROL Agent
has been configured to use a backup RTserver in a cloud that is different from its
primary RTserver.
66
Figure 4
Example of RT Cloud-to-Cloud Failover
An agent can be manually moved from one RT cloud to another using a procedure
outlined in the PATROL Console Server 7.3.00 Release Notes (September 30, 2004). Refer
to the section on "Failover of PATROL Agents From One RTserver Cloud to Another".
Appendix A
67
Can RTserver versions 6.2, 6.5.01, and 6.6 be mixed in the same cloud?
Can RTserver versions 6.2, 6.5.01, and 6.6 be mixed in the

same cloud?
Version 6.2 and 6.6.00 RTservers can be used in the same cloud to facilitate
incremental upgrade of an existing 6.2 cloud. Likewise, version 6.5.01 and 6.6.00
RTservers can be used in the same cloud as well. However, a cloud of mixed RT
versions should only be used on an interim basis and not as a long-term solution.
Versions 6.5.01 and 6.6.00 of RTserver are comparable in terms of scalability and
performance, but version 6.2 is significantly less scalable than either version 6.5.01 or
6.6.00. A mixed cloud of 6.6.00 and 6.2 RTservers will only be as scalable as the 6.2
RTserver, and should not be pushed beyond the capacity of RTserver 6.2. Even
though the capacity of version 6.6.00 exceeds that of version 6.2, the cloud as a whole
is limited by its lowest common denominator.
How should version 6.2-based hub-and-spoke clouds be

migrated to 6.6.00?
RTserver version 6.6.00 has greater capacity than version 6.2, and a migration to
version 6.6.00 may provide an opportunity to eliminate one or more existing
RTservers. Review the size of the existing 6.2 environment and the hardware
recommendations presented in this guide to determine if this is possible.
If it is not possible to eliminate any existing RTservers, apply the following principles
when migrating from a hub-and-spoke architecture:
If existing hardware can be re-used, install RTserver version 6.6.00 on top of

existing 6.2 RTservers.
If the migration is being performed in an incremental fashion, upgrade PATROL

Console Servers and RTservers before changing the RT cloud architecture.
Create one cloud for consoles and one or more clouds for agents.
Remove the hub RTservers that only connected to other RTservers in the previous
architecture.
The following three figures show before-and-after scenarios for a small hub-andspoke design with four RTservers (Figure 5 on page 69). In this example there are two
possible configurations for the "after" case depending on the hardware available
(Figure 6 on page 70 and Figure 7 on page 71).
68
How should version 6.2-based hub-and-spoke clouds be migrated to 6.6.00?
Figure 5
Case 1 "Before" Small Hub-and-Spoke Cloud
In the first case, as illustrated in Figure 6 on page 70, the hub-and spoke
implementation in Figure 5 can be reduced to just two computers.
Appendix A
69
Figure 6
Case 1A "After" One Cloud
In the second case, as illustrated in Figure 7 on page 71, the small hub-and-spoke
cloud in Figure 5 on page 69 can be divided into two clouds of two RTservers each:
one cloud for consoles and one cloud for agents.
70
Figure 7
Case 1B "After" Small Multi-Cloud
Figure 8 on page 72 illustrates a larger hub-and-spoke design with six RTservers.
Appendix A
71
Figure 8
Case 2 "Before" Large Hub-and-Spoke Cloud
In this example, the number of RTserver computers can be reduced by two because
hubs E and F can be removed. The resultant multi-cloud configuration is equivalent
to that illustrated in Figure 7 on page 71: one cloud for consoles composed of
RTservers A (primary) and B (backup), and one cloud for agents composed of
RTservers C (primary) and D (primary). As part of this migration, all agents must be
reconfigured to use RTservers C and D.
72
How can RTservers be configured to communicate through a firewall?
How can RTservers be configured to communicate through a

firewall?
The RTserver requires no special configuration in order to run through a firewall. For
security reasons, however, it is better to configure the RTserver and the firewall to use
a non-well-known port.
When running the RTserver through a firewall, it is best to configure the RTserver
and the firewall to use a non-well-known port.
PATROL Console Server

This section lists common questions and issues related to implementing the PATROL
Console Server.
How many users can a PATROL Console Server support?

PATROL Console Server capacity is not determined solely by the number of
concurrent users it supports, since every user may not have the same profile. Profiles
that only reference 10 agents, for example, have much less impact on system
performance than those that reference 500 agents. The workload borne by the
PATROL Console Server is based on the total number of managed objects contained
in all management profiles open at the same time. The total number of managed
objects can be determined by summing the application classes, instances, and
parameters loaded on each agent in each profile.
If an accurate count of the number of objects required for every profile is not
available, a rough rule of thumb can be used to help estimate this number. Although
the correct value varies considerably with the mix of KMs and the number of
application instances, for preliminary sizing an OS KM and an application KM
running on the same agent can be assumed to instantiate approximately 1000
managed objects.
There is no hard-coded limit on the number of concurrent consoles that can connect
to the PATROL Console Server, but there are practical constraints based on the total
number of managed objects. On 32-bit dual CPU hardware the largest configuration
supported is approximately 3 million managed objects. On a 32-bit computer the
limiting factor is the fixed size of the virtual memory address space, which ranges
from 2 GB to 4 GB depending on the OS. On 64-bit quad-CPU hardware the largest
Appendix A
73
How many agents can a PATROL Console Server support?
configuration tested by BMC Software has 10 million managed objects. Testing

includes configurations with 100 concurrent profiles of 100 agents each (100 objects
per agent) and configurations with 50 concurrent profiles of 200 agents each (100
objects per agent).
The hardware requirements for an environment with 10 million managed objects are
significant. Designs that support more than 100 concurrent users or more than 10
million managed objects should be reviewed by BMC Software and the PATROL Line
Of Business before a design is adopted, and in no case later than the initial stages of
technical evaluation.
How many agents can a PATROL Console Server support?

PATROL Console Server capacity is not determined solely by the number of
concurrent agents it supports, since every agent may not have the same configuration
or workload. The largest environments tested by BMC Software include
configurations with 2000 agents distributed across four RT clouds and configurations
with 4000 agents distributed across 10 RT clouds. In both configurations the
aggregate workload on the PATROL Console Server was no more than 10 million
managed objects. With 2000-4000 agents in the environment, the total number of
agents in all concurrently open profiles did not exceed 10,000.
Beyond these limits it may be necessary to partition an environment into separate
domains, where a domain is comprised of one or more PATROL Console Servers, a
PATROL Central cloud, and 8-10 RT clouds for 2000-4000 agents.
The hardware requirements for an environment of 2000-4000 agents are significant.
Environments that require more than 10 RT clouds, more than 4000 physical agents,
or a total of more than 10,000 managed agents across all concurrently open profiles
should be reviewed by BMC Software and the PATROL Line Of Business before a
design is adopted, and in no case later than the initial stages of technical evaluation.
Which versions of the PATROL Agent should be used with the

PATROL Console Server?
The PATROL Console Server will work with any PATROL Agent version 3.5.00 or
later. However, a minimum agent version of 3.5.32.20 is required for environments of
several hundred agents or more. This version corrects several problems related to
RTserver connection and scalability. The 3.6.00.05 agent contains additional
improvements related to scalability, including optimizations that can expedite profile
loading in large environments.
74
How many RT clouds can be connected to a PATROL Console Server?
How many RT clouds can be connected to a PATROL Console

Server?
See the question How many RT clouds can be connected to a single PATROL
Console Server? on page 58.
What can be done to prevent the PATROL Console Server from

becoming overloaded?
Starting with the release of version 7.3.00, the PATROL Console Server includes
several mechanisms to limit its workload. Before each profile-open request, the
PATROL Console Server estimates the impact of that profile on the current workload.
If the addition of the profile will exceed predefined workload thresholds, the openrequest is denied and a warning message is displayed to the user. The PATROL
Console Server will also reject profile-open requests if the workload limit is exceeded
after several profiles have been opened (for example, a large number of agents were
added to a profile or KMs discovered a large number of new instances).
For more information on the configuration options for this feature, see the PATROL
How can a PATROL Console Server be backed up?

With the release of version 7.5.00, the PATROL Console Server provides two method
of backup: online and offline. The online backup allows you to save your PATROL
Console Server configuration data and management profile information without
shutting down the PATROL Console Server process. The offline backup capability
works properly only if the PATROL Console Server process is not running. In either
case, the data that is backed up cannot be copied to an active secondary PATROL
Console Server; the secondary PATROL Console Server must be stopped before the
backed up data can be copied into the secondarys runtime directory. For more
information about the process of backing up the PATROL Console Server, see to the
PATROL Console Server and RTserver Getting Started guide.
Appendix A
75
How is a backup PATROL Console Server started?
How is a backup PATROL Console Server started?

The online backup can be configured to run automatically on a periodic schedule, or
it can be initiated on-demand from a command line utility called admincli. The offline
backup is always initiated from a command line utility called admin_copy. For more
information about starting a backup PATROL Console Server, see the PATROL
Are the locations of PATROL Central files and directories

documented anywhere?
Yes, see the PATROL Console Server and RTserver Getting Started guide.
What should I do if I see a message in the PATROL Console

Server log file indicating duplicate RTservers?
The following error message displayed in the PATROL Console Server log file
indicates that the two RT clouds identified by the variables name X and name Y are
interconnected in some way by their RTserver to RTserver configuration:
RT Cloud name x has duplicate rtservers with RT cloud
name y
In other words, there is actually only one physical RT cloud; however, the PATROL
Console Server configuration indicates that there are two (or more). This is a
configuration mistake that should be corrected. For an example of this problem and
information on how to correct it, see the question Which multi-cloud configurations
should be avoided? on page 64.
PATROL Central Operator Web Edition

This section lists common questions and issues related to implementing PATROL
Central Operator Web Edition.
76
How many users can PATROL Central Operator Web Edition support?
How many users can PATROL Central Operator Web Edition

support?
A single instance of PATROL Central Operator Web Edition can handle a total of
1500-2000 managed agents across all concurrently open profiles, or 15-20 concurrent
users with 100 agents per user.
How large a profile can PATROL Central Operator Web

Edition support?
PATROL Central Operator Web Edition can handle profiles containing up to 200
agents, but an average profile size of no more than 100 agents is recommended.
Above 200 agents per profile, response times deteriorate to unsatisfactory levels. For
environments in which profiles contain more than 200 agents, PATROL Central
Operator Microsoft Windows Edition should be used.
Why are console-side KM commands inactive on PATROL

Central Operator Web Edition?
PATROL Central Operator Web Edition does not support execution of local
commands from the browser.
PATROL Central Operator Microsoft Windows

Edition
This section lists common questions and issues related to implementing PATROL
Central Operator Microsoft Windows Edition.
Appendix A
77
How large a profile can PATROL Central Operator Microsoft Windows Edition support?
How large a profile can PATROL Central Operator Microsoft

Windows Edition support?
There is no hard-coded limit in PATROL Central Operator Microsoft Windows
Edition on the size of a profile. It is best to limit profiles to no more than 500 agents,
but larger profiles are possible. The largest profiles tested by BMC Software contain
up to 1200 agents.
The elapsed time between an initial open-profile request and the point at which
current status and connection information is displayed for every agent varies with
profile size and depends on the hardware used to host the PATROL Console Server.
A quad CPU 900 MHz Solaris computer fully loads profiles at a rate of approximately
100 agents per minute. A dual CPU 2.4 GHz Windows computer fully loads profiles
at a rate of approximately 300 agents per minute. For profiles consisting of several
hundred agents, operators can typically begin to work with some agents within one
or two minutes.
What version of PATROL Central Operator Microsoft

Windows Edition is recommended?
Version 7.5.00 or later of PATROL Central Operator Microsoft Windows Edition is
recommended for use with PATROL Console Server version 7.5.00.
PATROL Infrastructure Monitor

This section lists common questions and issues related to implementing the PATROL
Infrastructure Monitor.
Should I use the former PATROL Infrastructure Knowledge

Module or PATROL 7 Knowledge Module to monitor my
PATROL Central 7.5.00 infrastructure?
No. The PATROL Infrastructure Monitor 7.5.00 or later should be used to monitor
PATROL Central 7.5 infrastructure. This version of the product is both multi-cloud
aware and significantly more efficient than the previous products.
78
What versions of the PATROL Central infrastructure are supported by the PATROL Infrastructure Monitor?
What versions of the PATROL Central infrastructure are

supported by the PATROL Infrastructure Monitor?
The PATROL Infrastructure Monitor supports RTserver 6.2, 6.5.01, and 6.6.00. The
PATROL Infrastructure Monitor can be used on version 3.6.00 or 3.6.50 of the
PATROL Agent.
How can more than one RT cloud be monitored with the

PATROL Infrastructure Monitor?
The PATROL Infrastructure Monitor can monitor multiple clouds from a single
agent. For more details on configuring the PATROL Infrastructure Monitor, see the
PATROL Infrastructure Monitor online Help.
The PATROL Infrastructure Monitor can be placed anywhere in the enterprise where
connectivity to all clouds is available, but the following best-practice
recommendations should be considered:
Place the PATROL Infrastructure Monitor on the same computer as the PATROL
Console Server.
If redundancy is an important consideration, a second instance of the PATROL

Infrastructure Monitor can be installed on another computer, for example, on the
computer where the secondary PATROL Console Server is installed.
Appendix A
79
Other Components & Questions
Other Components & Questions

This section lists common questions and issues related to other components you may
implement in your PATROL environment such as PATROL Configuration Manager.
Are there any OS dependencies for PATROL Central

infrastructure?
OS dependencies vary from product to product and release to release. Review the
release notes and system requirements for all PATROL infrastructure components to
ensure that the implementation plan considers product-specific OS limitations and
accounts for any required OS patches or reconfiguration.
Is PATROL Central infrastructure supported on iSeries?

At this time there is no PATROL Agent for the IBM iSeries platform that supports
PATROL Central infrastructure. PATROL Agent version 3.6.50 is targeted to support
IBM iSeries systems but at security levels 0 and 1 only; higher security levels will not
be supported. Refer to the latest product roadmaps for current status and planned
availability of PATROL Central infrastructure on IBM iSeries.

implementation?
The Availability Checker was not designed for enterprise-wide deployment and does
not scale well to large numbers of managed nodes. It should only be used in single
server implementations to help troubleshoot problems. For more information on
sizing guidelines, see Single Server Environments on page 40.
80
Why can't all aspects of KM operation be managed with PCM?
Why can't all aspects of KM operation be managed with PCM?

Some KMs implement configuration and management features that are not
compatible with PCM. Although all BMC Software KMs are expected to be fully PCM
compatible in the future, features that may not be PCM configurable in every KM
today include
Adjusting thresholds and poll times

Activating and deactivating objects
Managing events
How are PCM rulesets used to best advantage?

Try to apply the following guidelines when planning and using PATROL
Configuration Manager:
Create initial rulesets at the application class level
Rules may apply to all instances of a class

Rules may apply to individual instances
Make localized versions of rules and rulesets for agents that require unique
variations
Rules may apply to all instances of a class

Rules may apply to individual instances
Build hierarchies of rulesets to avoid unnecessary duplication
Don't be afraid to duplicate specific rules into different rulesets when it improves
ease of use
Use an effective naming convention for rulesets. This will add consistency to the
way the tool is used by different users.
Once an Agent has been configured and tested, use "Get Configuration" to save its
configuration in the History ruleset folder. This consolidated ruleset will then be
available to apply to other systems.
Pick out parts of the ruleset to build other custom rulesets
Use the AS_CHANGESPRING.km to create rulesets that use existing KM

threshold values.
Appendix A
81
How are PCM rulesets used to best advantage?
Use AS_CHANGESPRING.km and the PATROL Development console to quickly

and easily turn your config.default into a Standard "Agent Setup" ruleset.
Use Changespring KM Commands primarily to migrate old configuration

information to PCM rulesets
82
Agent backups stored by system name and date/time

Rulesets and backups may be compared (changes and/or errors)
Purge deletes all current configuration information and does a complete "apply
new" to the agent
Appendix

This appendix presents the following worksheets:
Stakeholder Roster Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Location Analysis Worksheet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Appendix B
83
Stakeholder Roster Worksheet
Stakeholder Roster Worksheet

Stakeholder Roster
Name
Contact Phone/Email
Role/Interest
Deployment/Installation
Configuration/Change Management
PATROL Support
Operations/Event Management
At a minimum, the following stakeholders must be identified:

PATROL Deployment/Installation initial setup of PATROL infrastructure
PATROL Configuration/Change Management configure KMs, define event filtering/forwarding, notification rules
PATROL Support maintain PATROL infrastructure, perform maintenance & upgrades
PATROL Operations/Event Management daily users of PATROL
84
Location Analysis Worksheet

PATROL Location Analysis Worksheet
Location Name:
Is this location isolated by a network firewall?
Speed and reliability of LAN/WAN connectivity to this location:
Managed Node Information

Number of managed nodes at this location:
Knowledge Modules to be used at this location:
1.
6.
2.
7.
3.
8.
4.
9.
5.
10.
Additional Infrastructure Services

Will PATROL Reporting aggregate data from managed nodes at this location?
Will PATROL Agents at this location forward events to an event management tool?
If so, indicate which event management tool:
Visualization Information
Typical number of Knowledge Modules used on each managed node:
Typical number of managed objects on each managed node:
Number of PATROL Central Operator Microsoft Windows Edition consoles:
Number of PATROL Central Operator Web Edition users (daily / infrequently):
Number of concurrent PATROL Central Operator console sessions:
Typical number of managed nodes in each management profile:
Will management profiles include nodes at other locations?
If so, indicate which other locations:
Typical number of managed objects in each management profile:
Estimated total number of concurrent managed objects:
Appendix B
85
86
Appendix
Sample Solution Planning Forms &

Diagrams
C
This appendix includes forms and diagrams documenting the analysis and logical
design steps for a hypothetical PATROL Central implementation at MainCore, Inc.
This appendix presents the following topics:
Sample Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Stakeholder Roster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Location Analysis Worksheet for Houston . . . . . . . . . . . . . . . . . . . . . . . .
Example Location Analysis Worksheet for Austin. . . . . . . . . . . . . . . . . . . . . . . . . .
Example Location Analysis Worksheet for New York . . . . . . . . . . . . . . . . . . . . . .
Example Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix C
88
89
90
91
92
93
87
Sample Scenario
Sample Scenario
MainCore has offices in Houston, Austin, and New York City. Their primary
operations center is in Houston, with a secondary center in New York. Their main
interest in PATROL is to monitor the operating system and Oracle databases on their
servers. They will also use PATROL for Microsoft Exchange Servers to monitor two
mail servers in Houston and two others in New York.
The sample Stakeholder Roster includes contacts in the Systems Administration,
Oracle DBA, and Accounting groups. Participation by the system administrators and
DBAs will be needed for the actual implementation, and the Accounting group is
interested because the Oracle databases being monitored support financial
operations.
The analysis of this environment resulted in the following conclusions that were used
to complete the logical design:
88
The network links between offices have sufficient bandwidth and reliability to
permit those offices to share infrastructure components.
The managed node count in both Houston and Austin are sufficiently small to
permit one RTserver in each location to service both (a secondary is provided in
each RT cloud for failover).
An instance of the PATROL Infrastructure KM will be installed in both RT clouds

and each configured to monitor the other.
The New York office does not need any infrastructure components installed
locally.
The managed object counts were estimated using guidelines for OS and Oracle
KMs. PATROL for Microsoft Exchange Servers was not used because there are
only four instances of it in the enterprise (it is not used on a "typical" node).
The estimated total concurrent managed object count is 1,440,000, which is within
the capacity of a single PATROL Console Server.
The estimated number of concurrent console sessions is 10, which is within the
capacity of a single PATROL Console Server.
The estimated number of concurrent PATROL Central Operator Web Edition

sessions is 4, which is within the capacity of a single instance of PATROL Central
The Distribution Server and PATROL Configuration Manager will be located in

Houston.
Example Stakeholder Roster
Example Stakeholder Roster

Stakeholder Roster
Name
Contact Phone/Email
Role/Interest
John Smith
Deployment/Installation
John Smith
Configuration/Change Management
Janet Green
PATROL Support
John Smith
Bill Landry
System Administration Manager
Judy Jones
Mary Ward
Director of IT
Sam Leonard
Accounting Manager
At a minimum, the following stakeholders must be identified:

PATROL Deployment/Installation initial setup of PATROL infrastructure
PATROL Configuration/Change Management configure KMs, define event filtering/forwarding, notification rules
PATROL Support maintain PATROL infrastructure, perform maintenance & upgrades
PATROL Operations/Event Management daily users of PATROL
Appendix C
89
Example Location Analysis Worksheet for Houston
Example Location Analysis Worksheet for Houston

Location Name: MainCore, Inc., Houston
Is this location isolated by a network firewall? Yes
Speed and reliability of LAN/WAN connectivity to this location: T1, reliable

Number of managed nodes at this location: 500
1.KM for Unix
6.
2.KM for Windows
7.
3.KM for Oracle
8.
4.KM for Event Management
9.
5.KM for MS Exchange (2 servers)
10.

Will PATROL Reporting aggregate data from managed nodes at this location? Yes
Will PATROL Agents at this location forward events to an event management tool? Yes
If so, indicate which event management tool: PATROL Enterprise Manager
Typical number of Knowledge Modules used on each managed node: 3 (OS, Oracle, KM for EM)
Typical number of managed objects on each managed node: 1800 (2 * 900)
Number of PATROL Central Operator Microsoft Windows Edition consoles: 3
Number of PATROL Central Operator Web Edition users (daily / infrequently): 0
Number of concurrent PATROL Central Operator console sessions: 3
Typical number of managed nodes in each management profile: 80
Will management profiles include nodes at other locations? Yes
If so, indicate which other locations: Austin, New York
Typical number of managed objects in each management profile: 144,000 (1800 * 80)
Estimated total number of concurrent managed objects: 432,000 (144,000 * 3)
90
Example Location Analysis Worksheet for Austin
Example Location Analysis Worksheet for Austin

Location Name: MainCore, Inc., Austin

1.KM for Unix
6.
2.KM for Windows
7.
3.KM for Oracle
8.
9.
5.
10.

If so, indicate which event management tool: PATROL Enterprise Manager
Number of PATROL Central Operator Web Edition users (daily / infrequently): 0 / 2
If so, indicate which other locations: Houston, New York
Appendix C
91
Example Location Analysis Worksheet for New York
Example Location Analysis Worksheet for New York

Location Name: MainCore, Inc., New York

1.KM for Unix
6.
2.KM for Windows
7.
3.KM for Oracle
8.
9.
5.KM for MS Exchange (2 servers)
10.

If so, indicate which event management tool: PATROL Event Manager
Number of PATROL Central Operator Web Edition users (daily / infrequently): 2/ 0
If so, indicate which other locations: Houston, Austin
92
Example Diagrams
Example Diagrams
Figure 9
MainCore, Inc. Enterprise
Appendix C
93
Example Diagrams
Figure 10
94
MainCore, Inc. Houston Location
Example Diagrams
Figure 11
MainCore Inc. Austin Location
Appendix C
95
Example Diagrams
Figure 12
96
MainCore, Inc. New York Location
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Glossary
A
Agent
Agents are the active management components of PATROL infrastructure. The agent is used to
control monitoring and management of host computers, their resources, and their applications.
PATROL Agents work autonomously from one another and from other components, but
communicate with PATROL client applications, common infrastructure components,
integration products, and Third Party applications developed to run and cooperate with
PATROL.
Agent RT Cloud
An agent RT cloud is a defined combination of PATROL agents and the RTserver that services
them (including a secondary RTserver if one is present). It is an RT cloud intended primarily to
service PATROL agents.
Availability Checker
The Availability Checker is a PATROL Knowledge Module that performs PATROL Agent and
host availability checking. This KM does not scale well to large numbers of managed nodes and
should not be deployed on an enterprise scale; it should only be used to troubleshoot problems.
B
Blackout
Blackout is a generic term for predefining a change in PATROL's behavior based on date and
time. In various contexts it may refer to interrupting data collection, preventing parameter
threshold checking, suppressing event generation, or blocking event propagation. When using
the term, establish the context to indicate what action is being discussed.
C
Common Connect
Common Connect is a generic event API that allows integration between PATROL Central
infrastructure and other event management infrastructure such as PEM.
Console RT Cloud
A console RT cloud is a defined combination of PATROL Central consoles, a PATROL Console
Server, and the RTserver that services them (including a secondary RTserver if one is present). It
is an RT cloud intended primarily to service PATROL Central consoles.
Glossary
97
Console Server
The PATROL Console Server is the component of PATROL Central infrastructure that provides
non-GUI console services, including authentication, user impersonation, management profile
definition, and online help.
D
Distribution Server
The Distribution Server is used to install, re-install, deploy, and un-install BMC Software
distributed system products, upgrades, and patches from a central location.
F
Failover
Failover is the process by which functioning components identify and reconfigure themselves to
use a backup service following the failure of a primary one.
H
Hub RTserver
A hub RTserver is an RTserver which connects to other RTserver(s) as opposed to connecting to
directly to managed nodes. Starting with the release of version 7.3.00 of the PATROL Console
Server, Hub RTservers are generally no longer recommended and should be only be used in
special circumstances.
K
KeepAlive
A KeepAlive is a message sent by an RTserver process to another RTserver process. By
responding to a KeepAlive, an RTserver process signals that it is available to exchange
information.
Knowledge Module
Knowledge modules are loadable libraries of specialized knowledge and functionality that tell
the PATROL Agent how to manage various aspects of server operation. Multiple Knowledge
Modules may be loaded in a single agent, expanding the agent's ability to manage a server's
resources and applications. Knowledge Modules provide the domain-specific intelligence on
every managed server.
Knowledge Module for Event Management
The Knowledge Module for Event Management is the managed node component of PATROL
Configuration Manager that is responsible for interpreting PCM rules and applying them to
KMs and other components on the managed node. Also see Notification Server.
98
Knowledge Module for Log Management
The Knowledge Modules for Log Management is a PATROL Knowledge Module that is
responsible for scraping text log files and generating events or initiating recovery actions in
response to the presence of selected text or text patterns.
L
Location
In the context of this document a "location" is a geographic site or network segment separated
from other similar areas by a network firewall or network link with less than 10Mb bandwidth.
M
Managed Node
A managed node is a logical or physical computer system where a PATROL Agent is executing
for the purpose of monitoring and managing the business workload running on that system.
Managed Node RTserver
A managed node RTserver is an RTserver which connects directly to and services managed
nodes.
Managed Object
A managed object is an item whose attributes and status are maintained by a PATROL Console
Server, such as an Application Class instance or parameter.
Management Profile
A management profile is a defined collection of managed nodes and Knowledge Modules to be
displayed in a PATROL Central console session.
Messaging Domain
See RT cloud.
N
Notification Server
The Notification Server is a configuration of the PATROL Knowledge Module for Event
Management that provides message rewording, event consolidation and forwarding, and
centralized recovery in response to events forwarded from other managed nodes.
P
PATROL 7 (P7) Knowledge Module
See PATROL Infrastructure Monitor.
PATROL Central Administrator
PATROL Central Administrator is a console module optionally installed into the PATROL
Central console application. It provides the functionality required for administrators of
Glossary
99
PATROL infrastructure to manage the access, privileges, and rights of those in the organization
that will view and interact with PATROL Agents installed throughout the enterprise. PATROL
Central Administrator is generally only installed into PATROL Central client applications
responsible for administering PATROL infrastructure and other PATROL users.
PATROL Central Operator
PATROL Central Operator is a console module installed into the PATROL Central Console
infrastructure component. It provides the functionality needed by end users (operators) of the
information gathered by PATROL Agents. PATROL Central Operator is generally installed in
all PATROL Central client applications.
PATROL Central Operator Microsoft Windows Edition
PATROL Central Operator Microsoft Windows Edition provides management console
infrastructure that can be extended by installing console modules. Once console modules are
installed, PATROL Central Operator Microsoft Windows Edition provides a native Windows
interface to all modules regardless of the functionality they provide.
PATROL Central Operator Web Edition
PATROL Central Operator Web Edition provides management console infrastructure that can
be extended by installing console modules. Once console modules are installed, PATROL
Central Operator Web Edition provides a Web browser-based interface to all modules
regardless of the functionality they provide.
PATROL Configuration Manager
PATROL Configuration Manager is used to perform PATROL Agent and Knowledge Module
configuration and customization all from a centralized location. PCM implements a "rule and
ruleset" model, where customizations and configuration specifics are encapsulated in one or
more rules. Logically related rules may be aggregated together in rulesets, and both rules and
rulesets can be deployed to one or more PATROL Agents in a single action.
PATROL Infrastructure Knowledge Module
See PATROL Infrastructure Monitor.
PATROL Infrastructure Monitor
The PATROL Infrastructure Monitor (formerly called the PATROL Infrastructure Knowledge
Module or the PATROL 7 Knowledge Module) is a PATROL Knowledge Module that is
responsible for monitoring the RT cloud and the general health of the RT infrastructure.
R
RT Cloud
An RT cloud is a collection of managed nodes and the RTserver which services them; in the case
where Hub RTservers are used, the RT cloud extends to include the Hub and all other RTservers
and Hubs which are configured to function together. Sometimes referred to as an "RTserver
cloud" or a "messaging domain".
100
RTserver
Real time servers are the components of PATROL Central infrastructure that provide
communication services between PATROL components. RTservers communicate data between
PATROL Agents, common service components such as PATROL Console Servers, and PATROL
Central client applications such as PATROL Central Operator Microsoft Windows Edition and
PATROL Central Operator Web Edition.
S
Stakeholder
A stakeholder is a person with an interest in the success of a project; a stakeholder may or may
not actively participate in the execution of the project.
W
Web Server
In the context of PATROL Central infrastructure, a Web server is a special instance of a Tomcat
or Apache Web server running a proprietary plug-in which allows it to communicate and serve
content from a PATROL Central Console Server.
Glossary
101
102
Notes
*52790*
*52790*
*52790*
*52790*
*52790*

Patrol Central Infrastructure Best Practices Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Patrol Central Infrastructure Best Practices Guide

Hochgeladen von

Copyright:

Verfügbare Formate

PATROL Central Infrastructure

Best Practices Guide

February 28, 2005

Contacting BMC Software

United States and Canada

BMC SOFTWARE INC

713 918 8800 or

(01) 713 918 8000

713 918 8000

Outside United States and Canada

(01) 713 918 8800

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC Software

operating system and environment information

sequence of events leading to the problem

commands and options that you used

product error messages

PATROL Central Infrastructure Best Practices Guide

Purpose of this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Analyzing the Management Environment

PATROL Central Implementation Logical Design

PATROL Central Environment Physical Mapping

PATROL Central Operator Web Edition Hardware . . . . . . . . . . . . . . . . . . . . . . . 46

Developing the Implementation Plan

Order of Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Frequently Asked Questions

RTserver and RT clouds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

PATROL Central Infrastructure Best Practices Guide

PATROL Central Operator Microsoft Windows Edition . . . . . . . . . . . . . . . . . . . . . .

Infrastructure Planning Forms

Stakeholder Roster Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Sample Solution Planning Forms & Diagrams

PATROL Central Infrastructure Best Practices Guide

PATROL Central Infrastructure Best Practices Guide

PATROL Central Infrastructure Best Practices Guide

Purpose of this Guide

Purpose of this Guide

PATROL Agent version 3.6 or later

Best Practice Recommendation BP1

PATROL Central Infrastructure Best Practices Guide

Planning the Implementation Process

Planning the Implementation Process

Planning the Implementation Process

the number of agents in the design

3. Failure scenarios should be considered and the need to provide failover

PATROL Central Infrastructure Best Practices Guide

Analyzing the Management

Chapter 2 Analyzing the Management Environment

Completing the Enterprise Analysis

initial deployment and installation of PATROL

PATROL Central Infrastructure Best Practices Guide

Completing the Enterprise Analysis

PATROL managed node configuration and change management

ongoing user management, availability, and performance of PATROL Central

handling events and exception conditions raised by PATROL

Chapter 2 Analyzing the Management Environment

Completing the Enterprise Analysis

Class instances, increase the object count estimate accordingly.

Estimate the total number of PATROL Central Operator Microsoft Windows

PATROL Central Infrastructure Best Practices Guide

Completing the Enterprise Analysis

Chapter 2 Analyzing the Management Environment

Completing the Enterprise Analysis