patrol central infrastructure best practices guide

7/25/2019 Patrol Central Infrastructure Best Practices Guide

1/104

PATROLCentral InfrastructureBest Practices Guide

Supporting

PATROL Agent version 3.6PATROL Central Operator Web Edition version 7.1.10.01PATROL Central Operator Microsoft Windows Edition version 7.5.00PATROL Configuration Manager version 1.5.01PATROL Console Server version 7.5.00PATROL Knowledge Module for Event Management/

PATROL Notification Server version 2.6.00PATROL Knowledge Module for Log Management version 2.0.01PATROL RTserver version 6.6.00PATROL Infrastructure Monitor version 7.5.00 (formerly the PATROL

Infrastructure Knowledge Module version 7.1.10)Distribution Server version 7.1.20BMC Impact Integration for PATROL version 7.1.01PATROL Enterprise Manager Console Server Connection version 7.1.00PATROL Integration for HP Network Node Manager version 7.1.00

February 28, 2005


2/104

Contacting BMC Software

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

United States and Canada

Address BMC SOFTWARE INC2101 CITYWEST BLVDHOUSTON TX 77042-2827USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

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 trademarksor 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 OracleCorporation.

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 thisinformation is subject to the terms and conditions of the applicable End User License Agreement for the product and theproprietary and restricted rights notices included in this documentation.

Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THECOPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by theU.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer isBMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent tothis address.
http://www.bmc.com/http://www.bmc.com/http://www.bmc.com/


3/104

3

Customer support

You can obtain technical support by using the Support page on the BMC Software website or by contacting CustomerSupport 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 athttp://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 orsend an e-mail message to [email protected]. Outside the United States and Canada, contact your local support center forassistance.

Before contacting BMC Software

Before you contact BMC Software, have the following information available so that Customer Support can begin workingon 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 f i l e systemf ul l messages from related software
http://www.bmc.com/support_homemailto:[email protected]:[email protected]://www.bmc.com/support_home


4/104

4 PATROL Central Infrastructure Best Practices Guide


5/104

Contents 5

Contents

Chapter 1 Introduction 13

Purpose of this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Planning the Implementation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 2 Analyzing the Management Environment 17

Analysis Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Completing the Enterprise Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 3 PATROL Central Implementation Logical Design 23

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24RT Cloud Logical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

RTserver Design Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Characterizing RTserver Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Deciding Initial RTserver Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26RTserver Backup/Failover Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Visualization Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Which PATROL Central Console is Appropriate? . . . . . . . . . . . . . . . . . . . . . . . . . . 28Which Locations Need PATROL Console Servers? . . . . . . . . . . . . . . . . . . . . . . . . . 28Is One PATROL Console Server Enough? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Logically Sizing the PATROL Console Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30PATROL Console Server Failover Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . 30PATROL Central Operator Web Edition Placement . . . . . . . . . . . . . . . . . . . . . . . 32Visualization Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Event Management Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Notification Server Usage and Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Centralized Customization Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Designing for PATROL Management/Upgrade/ Patching . . . . . . . . . . . . . . . . . . . . . 36

Using the Distribution Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 4 PATROL Central Environment Physical Mapping 39

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Hardware Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Single Server Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40RTserver Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42PATROL Console Server Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45


6/104


PATROL Central Operator Web Edition Hardware . . . . . . . . . . . . . . . . . . . . . . . 46PATROL Central Operator Microsoft Windows Edition Hardware. . . . . . . . . . 47

Co-Hosting PATROL Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47PATROL Console Server Platform Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48RTserver Implementation Tips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

RT Cloud Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49PATROL Console Server Implementation Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Clustering a PATROL Console Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Chapter 5 Developing the Implementation Plan 53

Order of Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Planning Ahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Appendix A Frequently Asked Questions 55

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

How do clients connect to an RTserver?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57How many agents can connect to a single RTserver?. . . . . . . . . . . . . . . . . . . . . . . . 57How many agents can connect to a single RT cloud?. . . . . . . . . . . . . . . . . . . . . . . . 58How many RT clouds can be connected to a single PATROL Console

Server?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58How many RTservers can be connected in a single cloud?. . . . . . . . . . . . . . . . . . . 59What is the best RT cloud configuration?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59When are multiple RT clouds recommended? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61When should hub-and-spoke RT cloud architecture be used? . . . . . . . . . . . . . . . . 62Which multi-cloud configurations should be avoided?. . . . . . . . . . . . . . . . . . . . . . 64Can 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?. . . 68How can RTservers be configured to communicate through a firewall? . . . . . . . 73

PATROL Console Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73How many users can a PATROL Console Server support?. . . . . . . . . . . . . . . . . . . 73How many agents can a PATROL Console Server support? . . . . . . . . . . . . . . . . . 74Which versions of the PATROL Agent should be used with the PATROL

Console Server? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74How many RT clouds can be connected to a PATROL Console Server?. . . . . . . . 75What can be done to prevent the PATROL Console Server from becoming

overloaded? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75How can a PATROL Console Server be backed up? . . . . . . . . . . . . . . . . . . . . . . . . 75

How is a backup PATROL Console Server started?. . . . . . . . . . . . . . . . . . . . . . . . . 76Are the locations of PATROL Central files and directories documented

anywhere?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76What should I do if I see a message in the PATROL Console Server log file

indicating duplicate RTservers? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76PATROL Central Operator Web Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

How many users can PATROL Central Operator Web Edition support? . . . . . 77How large a profile can PATROL Central Operator Web Edition support? . . . 77Why are console-side KM commands inactive on PATROL Central Operator

Web Edition? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77


7/104

Contents 7

PATROL Central Operator Microsoft Windows Edition . . . . . . . . . . . . . . . . . . . . . . 77How large a profile can PATROL Central Operator Microsoft Windows

Edition support? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78What version of PATROL Central Operator Microsoft Windows Edition is

recommended? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

PATROL Infrastructure Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Should I use the former PATROL Infrastructure Knowledge Module or

PATROL 7 Knowledge Module to monitor my PATROL Central 7.5.00infrastructure? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

What versions of the PATROL Central infrastructure are supported by thePATROL Infrastructure Monitor? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

How can more than one RT cloud be monitored with the PATROLInfrastructure Monitor? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Other Components & Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Are there any OS dependencies for PATROL Central infrastructure? . . . . . . . . . 80Is PATROL Central infrastructure supported on iSeries? . . . . . . . . . . . . . . . . . . . . 80

When should the Availability Checker be used in an enterpriseimplementation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Why can't all aspects of KM operation be managed with PCM? . . . . . . . . . . . . . . 81How are PCM rulesets used to best advantage?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Appendix B Infrastructure Planning Forms 83

Stakeholder Roster Worksheet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Location Analysis Worksheet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Appendix C Sample Solution Planning Forms & Diagrams 87

Sample Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Example Stakeholder Roster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Example Location Analysis Worksheet for Houston. . . . . . . . . . . . . . . . . . . . . . . . 90Example Location Analysis Worksheet for Austin. . . . . . . . . . . . . . . . . . . . . . . . . . 91Example Location Analysis Worksheet for New York . . . . . . . . . . . . . . . . . . . . . . 92Example Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Glossary 97
http://-/?-http://-/?-


8/104



9/104


10/104



11/104

Tables 11

Tables

Requirements for Small Single-Server PATROL Central Environment(Up to 500,000 managed objects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Requirements for a Medium Single-Server PATROL Central Environment(Up to 3 million managed objects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Requirements for One RTserver on a Dedicated Computer(Up to 750 RT clients) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Requirements for Two RTservers on a Dedicated Computer(Up to 1000 total RT clients) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Requirements for Two to Four RTservers on a Dedicated Computer(Up to 2000 RT clients) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Requirements for a Medium PATROL Console Server Environment(Up to 3 million managed objects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Requirements for a Large PATROL Console Server Environment(Up to 10 million managed objects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Requirements for PATROL Central Operator Microsoft Windows Edition(based on profile size) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47


12/104



13/104


C h a p t e r 11Introduction

This chapter presents the following topics:

Purpose of this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Planning the Implementation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15


14/104

Purpose of this Guide


Purpose of this Guide

The purpose of the PATROL Central Infrastructure Best Practices Guideis to provideBMC Software PATROL solution architects with a process for gathering technical

requirements, identifying potential trouble spots, and documenting a PATROLinfrastructure implementation that will function reliably and efficiently. While thisdocument discusses some "do's and don'ts" that are covered in other PATROLdocuments, it generally does not duplicate information provided elsewhere. Thisdocument frequently refers to product manuals and white papers for operationaldetails.

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 NotificationServer 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 PATROLInfrastructure 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

While this guide does not answer every possible technical question or provide forevery design contingency, it will almost always lead to a design that uses PATROL inthe best way possible. Choosing not to follow the guidelines presented in thisdocument, or neglecting to take into account the factors discussed herein, can lead toa PATROL implementation that is unstable, that requires an excessive amount of timeto maintain, or that can experience a major failure. If, at the end of the design process,

Best Practice Recommendation BP1

Always obtain the latest revision of this guide before you base a PATROL Central design onthe guidelines it contains. Release-to-release changes in infrastructure components cansignificantly 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 thesuccess or failure of a PATROL implementation.


15/104

Planning the Implementation Process


solution architects have doubts about the proposed implementation, they areencouraged to consult with BMC Software and the PATROL Line Of Business fordesign validation before proceeding. Failure to do so can result in lost time, addedexpense, and disruption of service.

To view the latest BMC Software manuals, technical bulletins, flashes, and whitepapers visit the BMC Software Customer Support page athttp://www.bmc.com/support_home.


While small PATROL implementations can be supported by a single infrastructureserver running a PATROL Console Server/RTserver pair, design of a large PATROLsolution is more challenging and should be approached in a top down manner.

Solution architects should start with the "big picture" and work their way down toprogressively greater levels of detail until all their objectives have been met. Chapters2 and 3 in this document will discuss this process in detail. In general, though, thereare four steps in the process.

1. Solution architects should first identify the implementation stakeholders in orderto 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 andconsoles that the solution requires.

Every infrastructure component should be treated as if it required a dedicatedserver, but with geography and network topology in mind. The diagram shouldindicate the speed of all network connections, note the locations of any firewallsthat may be present, and reference any existing equipment to be used for PATROLinfrastructure.


Always consult with BMC Software and with the PATROL Line of Business before deviatingfrom the Best Practices presented in this guide. Failure to do so can lead to major softwarefailures and system outages.


PATROL Central implementations involving up to 500 managed nodes can be supported bya single infrastructure server running one PATROL Console Server, one RTserver, and oneinstance of PATROL Central Operator Web Edition. For detailed information abouthardware sizing, see Hardware Requirements on page 40.
http://www.bmc.com/support_homehttp://www.bmc.com/support_home


16/104



2. The number of RT clouds and RTservers needed to support the PATROL solutionshould be determined. Provision should not yet be made for recoverability orfailover, 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 failovercapabilities for particular components should be identified. Where failover is notpossible, single points of failure should be eliminated or the solution should bemodified so that most failures cause only a partial loss of functionality orperformance.

4. Hardware requirements should be determined. Factors in configuringinfrastructure servers include the work each PATROL component must performand whether or not components can safely coexist and interoperate on the sameserver. The design should be optimized to require as little hardware as possiblewithout unduly affecting performance.


17/104


C h a p t e r 22Analyzing the ManagementEnvironment

This chapter describes how to complete the planning forms used to recordinformation collected during analysis of the enterprise to be managed with PATROL.The forms can be found in Appendix B, Infrastructure Planning Forms.


Analysis Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Completing the Enterprise Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18


18/104

Analysis Tools


Analysis Tools

The Stakeholder Roster Worksheetprovides a convenient place to note the peopleand 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 andcommunication and help reduce missteps during implementation planning.

The Location Analysis Worksheetprovides a standardized format for recordingrelevant information about each logical and physical location to be managed. Theanalysis performed and the data recorded on this form will be used to develop alogical design for the PATROL implementation. The thoroughness of the analysis andaccuracy of the information recorded will have a significant impact on the quality ofthe design and the overall success of the PATROL implementation. Use of this formwill facilitate communication and review of the proposed design.

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 whowill participate or have an interest in this implementation of PATROL. If a group islisted, identify a person to serve as communications contact for the group. Refer tothe roster during the remainder of the process when questions arise or whencommunicating about the progress of the implementation. Frequent communicationwill help highlight issues early in the process and reduce rework later. At aminimum, identify the people directly involved with:

initial deployment and installation of PATROL


When planning a PATROL Central implementation, the minimum recommended PATROLAgent version is 3.5.32.20 and version 3.6.00.05 or later is preferred. These versionsincorporate many performance and scalability improvements related to PATROL Central. Ifexisting agents must be upgraded they should be upgraded to the latest Generally Availableversion.


19/104



PATROL managed node configuration and change management

ongoing user management, availability, and performance of PATROL Centralinfrastructure

handling events and exception conditions raised by PATROL

Document the role or primary interest of each stakeholder. Typical stakeholders willinclude System Administrators, Database Administrators, managers of businessapplications such as SAP, PeopleSoft, or Oracle Financials, Operations personnel, andPATROL Administrators. Key management sponsors or business partners may alsobe listed. Include anyone who will be directly involved in the implementation orneeds to be kept informed of its progress.

Make a high-level diagram of the entire business enterprise to be managed usingPATROL, similar to the sample shown in Appendix C, Sample Solution Planning

Forms & Diagrams.While it need not be overly detailed, it must indicate any wide-area, lower-speed (less than 10 Mb/sec), or other non-local network links, and anyfirewalls, network switches, or other infrastructure that could impact connectivity. Ifportions of a physical location are isolated by local firewalls, identify each isolatedarea as a separate logical location and treat it as a physically separate location for theremainder of the analysis process.

Make a copy of the Location Analysis Worksheet for each location shown on thediagram 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 willdegrade performance. Accurate connectivity information is key to the design process.

Enter the total number of nodes to be managed by PATROL on the worksheet foreach location. Include all systems where a PATROL Agent will be installed in thiscount. This data is for environment sizing, so individual host names, OS vendors, andother 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 andimpacts PATROL Console Server placement and management profile definition.

Note any KM which may have an unusually high number of Application Classinstances. An example might be an operating system KM running on a large fileserver with an unusually large number of disk and file system instances.

Enter on each worksheet whether or not PATROL Reporting will be used toaggregate 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.


20/104



For each location where PATROL Central consoles are to be used, complete theVisualization Information section of the worksheet.

To determine the number and placement of PATROL Console Servers, an estimate ofthe 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 ofconcurrent console sessions multiplied by the number of managed objects in eachsession profile. The Visualization Information section of the worksheet is used todocument estimates for these factors.

Estimate by location the typical number of KMs needed per node, and enter thatinformation on each worksheet. Using the object count guidelines in the followinglist, determine the total number of managed objects needed on the typical managednode 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 InsightManager or PATROL for Dell OpenManage)

Estimate the total number of PATROL Central Operator Microsoft WindowsEdition consoles to be installed at each location, add the estimated number ofconcurrent PATROL Central Operator Web Edition users, and enter the total on theworksheet.

Estimate the expected number of concurrently activeconsole sessions for each type ofconsole at each location and record the information on the worksheet. Add the twonumbers and record the total number of concurrent console sessions.

Based on the monitoring and management needs of the console users, estimate theaverage number of managed nodes that will be defined in each concurrent consolemanagement profile and record it on the worksheet for each location.

Multiply the number of managed nodes in the typical management profile by thenumber of managed objects on the typical managed node and record the result as thenumber of managed objects in the typical management profile.

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.


21/104


22/104




23/104


C h a p t e r 33PATROL Central ImplementationLogical Design

To be successful, a PATROL Central implementation must be carefully designed andplanned, giving careful attention to the limits and recommendations detailed in thischapter. This chapter presents the following topics:

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24RT Cloud Logical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

RTserver Design Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Characterizing RTserver Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Deciding Initial RTserver Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26RTserver Backup/Failover Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Visualization Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Which PATROL Central Console is Appropriate? . . . . . . . . . . . . . . . . . . . . . . . . . . 28Which Locations Need PATROL Console Servers? . . . . . . . . . . . . . . . . . . . . . . . . . 28Is One PATROL Console Server Enough? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Logically Sizing the PATROL Console Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30PATROL Console Server Failover Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . 30PATROL Central Operator Web Edition Placement . . . . . . . . . . . . . . . . . . . . . . . 32Visualization Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Event Management Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Notification Server Usage and Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Centralized Customization Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Designing for PATROL Management/Upgrade/ Patching . . . . . . . . . . . . . . . . . . . . . 36

Using the Distribution Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37


24/104

Overview


Overview

In a general sense, the logical design step in the process involves adding to theenterprise diagram produced in the previous chapter and indicating where various

PATROL Central infrastructure services will reside. The logical design phase is notconcerned with the physical devices that will provide these services, only with theirlocations and in what numbers the services are needed.

The first refinement to the enterprise diagram centers on designing domains whichconsist of managed nodes and one or more RTservers. In other documentationand/or presentations, these domains have variously been referred to as "messagingdomains," "agent clouds," "RT clouds," and "clouds."

The second refinement addresses the visualization needs of the enterprise. It includesnumbers and placement of PATROL Central Operator Microsoft Windows Edition

installations, PATROL Console Servers, and PATROL Central Operator WebEdition installation(s) (if browser-based visualization is needed). Design decisionsmay result in RTservers dedicated to supporting visualization components. Thesedomains 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 isimportant, the term "agent cloud" will be used. Similarly, "console cloud" will be usedto specify the combination of visualization components and RTservers. If theassociation is not essential to the discussion, the more generic term "RT cloud" may beused 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 oneshown in Appendix C, Sample Solution Planning Forms & Diagrams.Thesediagrams will be used to visualize the placement of infrastructure services for each

location and will be needed when mapping the logical design to physical serverslater.

RTserver Design Considerations

The central component of PATROL Central infrastructure is the RTserver messagebroker. Determining the placement and number of RTservers for each location is aniterative process.


25/104

RTserver Design Considerations


The first step involves high-level RTserver placement based on the number ofmanaged nodes present and the characteristics of the message traffic the RTserverwill handle. Once basic RTserver placement has been completed, a review of theenterprise will be conducted to identify potential points of unacceptable serviceinterruption 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 50or more managed nodes, placing RTservers in the same geographical location as themanaged nodes they support. Starting with the release of PATROL Central version7.3, RTserver design decisions have become much simpler.

Typically, an RT cloud will need no more than two RTservers (a primary and abackup). Scalability is achieved by creating additional RT clouds rather thanconfiguring "hub and spoke" RTservers to create larger domains.

In the case of managed nodes within DMZs, many companies have policies dictatingthe 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 butconnecting from a node in the DMZ into the intranet is not. In these scenarios, an RTcloud can be created for each DMZ and PATROL Console Server can be configured toconnect 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.


No RT cloud should include more than 500-700 managed nodes. If PATROL Reporting willbe used to aggregate data from a location, or if a Notification Server will be used, AND theRTserver will be installed on the same node as either one, that RTserver can support no morethan 500 managed nodes.

NOTE An exception to this general rule is presented in Appendix A, Frequently AskedQuestionsin the question When should hub-and-spoke RT cloud architecture be used? onpage 62.


26/104

Characterizing RTserver Traffic


Characterizing RTserver Traffic

The type and volume of message traffic that RTservers must process impact therequired 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 aretwo optional PATROL components that when installed on the same computer as theRTserver will reduce the number of managed nodes per RTserver: PATROLReporting and the Notification Server.

Deciding Initial RTserver Placement

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 ofRTservers.

RTserver Backup/Failover Considerations

Failure of any component of PATROL Central infrastructure will affect componentsthat rely on the one that fails. The severity of the impact and the time needed torestore functionality can be reduced by providing backup components to take over ifa primary component fails. The process of automatic reconfiguration and resumptionof service using backup components is called failover.

When a failover occurs, the time required to restore full functionality depends on theservice involved and varies considerably from service to service. For failure of asingle service, the relative impacts and recovery times rank from least impact to mostimpact in the following order:


When creating a dedicated RT cloud for consoles, the primary RTserver should be placed onthe same computer as the PATROL Console Server and the backup RTserver should beplaced on a different computer. In cases where the PATROL Central Operator Web Editionis hosted on a separate computer, the backup RTserver for the console cloud can be hostedon the same computer as PATROL Central Operator Web Edition.


27/104

RTserver Backup/Failover Considerations


1. An RTserver that is servicing managed nodes fails. In this case, all managed nodesconnected to the failed RTserver will be shown as disconnected in their respectivemanagement profiles on all active consoles and the managed nodes will begin theirfailover process (if available). Since a managed node RTserver typically servicesonly 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 tofunction. Only browser-based sessions will be affected; any PATROL CentralOperator Microsoft Windows Edition sessions will continue to function.

3. An RTserver supporting a console cloud fails. When this happens, consoles servedby the failed RTserver will be unable to communicate with the PATROL ConsoleServer and will not be usable until the RTserver service is restored or the consolesand PATROL Console Server establish communication through a backup RTserver

(if available).

4. A PATROL Console Server fails. As with a console RTserver failure, all consolesessions served by the failed PATROL Console Server will cease to function. Formore information, see PATROL Console Server Failover Considerations onpage 30.

The way in which a component goes offline also affects recovery time. If a componentis stopped gracefully, all other components recognize the loss almost immediatelyand begin their respective failovers. If a component is lost unexpectedly due to apower or hardware failure, abrupt system shutdown, or physical network

interruption, loss of the component may not be recognized by other components forseveral minutes and recovery time may be lengthened.

ACTION 4

Review the solution diagrams for all locations, looking for areas where an RTserveroutage would create an unacceptable interruption of monitoring. If any such areas areidentified, reconfigure the RT cloud and add backup RTservers to allow theinfrastructure to continue to function if an RTserver service fails.


If a PATROL Central design includes backup RTservers, place a backup RTserver in each RTcloud. If a separate RTserver is provided to handle traffic between the PATROL ConsoleServer and PATROL Central consoles (or PATROL Central Operator Web Edition) andredundancy is needed, place one backup RTserver in the console cloud.


28/104

Visualization Design


Visualization Design

This phase of the design process involves determining the placement and number ofPATROL Console Servers (and optionally PATROL Central Operator Web Edition

instances) to support the anticipated level of PATROL Central console usage. At thisstage, placement decisions should be made without regard for the possibility ofsharing hardware with other services. The only consideration should be logicalplacement of visualization services based on best practice recommendations.

There are multiple PATROL Console Server placement scenarios that will work fornearly any given situation. The best practice recommendations presented hererepresent 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 simplifiesPATROL Console Server placement design decisions.

Which PATROL Central Console is Appropriate?

Generally, PATROL Central Operator Microsoft Windows Edition is therecommended management console for anyone other than a casual user. For userswho do not depend on access to the console to perform their primary job function, orfor those who do not access PATROL daily, PATROL Central Operator Web Editionmay be appropriate. Due to the architectural and component differences, the consolesshould not be viewed as completely interchangeable.

Which Locations Need PATROL Console Servers?

Begin by placing a single PATROL Console Server in the location with the highestconcentration of managed nodes. If network bandwidth and reliability are high, asingle PATROL Console Server may be able to service all console sessions.


Do not attempt to use PATROL Central Operator Web Edition to visualize more than 200managed nodes. Try to limit profiles to fewer than 100 managed nodes.

Use PATROL Central Operator Microsoft Windows Edition to visualize larger numbers ofmanaged nodes.


29/104

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 beused to service it. If no excess capacity exists, either an additional PATROL ConsoleServer must be installed at the remote location or a PATROL Console Server (andpotentially other PATROL Central infrastructure components) must be installed

locally. Bandwidth and reliability of the network connection to the remote locationmust be factored into the decision to use a remote PATROL Console Server, since thenetwork link is a single point of failure.

The primary reason to install a PATROL Console Server where it would nototherwise be justified is for improved performance. If console users in a particularlocation only need to view managed nodes in the same location, the improvedreliability and performance gained by keeping network traffic local may justify theadditional administrative and equipment cost of an additional PATROL ConsoleServer.

Maintenance of multiple PATROL Console Servers requires additionaladministrative work. While PATROL Console Server 7.5 introduced an online backupcapability, there are still no provisions for automatically copying data betweenPATROL Console Servers, nor is there any functionality to synchronize or reconcilechanges when the same type of data (privilege assignments, for instance) has beenchanged on two or more PATROL Console Servers. Operational policies and manualprocedures must be implemented to work around these limitations.

To arrive at an optimal design, each location must be evaluated independently andPATROL 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 singlelocation. Factors in this decision include the number of concurrent console sessionsand the number of managed objects in concurrent management profiles.

The total number of managed objects known to the PATROL Console Server at anygiven 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 thelocation worksheet. Some headroom must be provided to avoid the risk of PATROLConsole Server performance degradation or run-time failure.

Starting with the release of version 7.3 of PATROL Central infrastructure, the numberof concurrent managed objects known to the PATROL Console Server is limited bythe resources of the hardware hosting the PATROL Console Server, most notablyavailable virtual memory.


30/104

Logically Sizing the PATROL Console Server


Version 7.3 of the PATROL Console Server also introduced overload protection. Theoverload protection feature allows the PATROL Console Server to reject additionaloperator connections when they will cause preconfigured limits to be exceeded.

Logically Sizing the PATROL Console Server

ACTION 5

Review the solution diagram and worksheet for each location in light of the PATROLConsole Server sizing factors just discussed. Determine whether or not it will befeasible to host the PATROL Console Server on 64-bit hardware. If such a system isavailable, there is no hard object count limit. In practice, however, it is best to plan forno more than 10 million concurrent managed objects in a single 64-bit PATROLConsole Server.

If the PATROL Console Server will be hosted on 32-bit hardware, there is a hard limitof 3 million concurrent managed objects in a single PATROL Console Server.

Update the solution diagram for each location to show the placement of primaryPATROL Console Servers.

PATROL Console Server Failover ConsiderationsThere are two ways to provide redundancy for the PATROL Console Server:

Install the PATROL Console Server on high-availability cluster hardware, store theconfiguration files on a shared disk, and define a cluster failover package thatincludes the PATROL Console Server.

Install a secondary PATROL Console Server on a separate node and use the onlinebackup feature to periodically snapshot data from the primary PATROL ConsoleServer.


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 bya single PATROL Console Server.


Add an additional PATROL Console Server when the estimated concurrent managed objectcount approaches 3 million (on 32-bit hardware) or 10 million (on 64-bit hardware) to leaveheadroom in the design for additional, unanticipated use.


31/104

PATROL Console Server Failover Considerations


The only way to provide transparent service restoration in the event of a PATROL ConsoleServer failure is by using a high-availability cluster. In this scenario, the PATROL ConsoleServer service will be restarted by the cluster management software. Once restarted,the console cloud will reestablish connectivity and console sessions will resumefunctioning.

In the absence of high-availability hardware, a secondary PATROL Console Serverallows PATROL Central availability to continue during planned outages of theprimary PATROL Console Server or during a hardware or other failure local to theprimary 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 anoutage, its configuration data (for example, profiles and impersonations) will only becurrent to the last time the configuration files for the secondary PATROL ConsoleServer were copied from the primary PATROL Console Server. Depending on the

configuration of the online backup feature in the primary PATROL Console Serverand the network-shared disks between the primary and the secondary, administratorintervention may be required to copy the latest data to the backup PATROL ConsoleServer and then restart it.

After a secondary PATROL Console Server has been started either by high-availability cluster management software or through manual intervention, additionaltime is required for console sessions to be reestablished. This additional time willvary with the number and size of the management profiles involved.

The way in which a component goes offline also affects recovery time. If a componentis stopped gracefully (PATROL Console Server or RTserver), other componentsrecognize the loss almost immediately and begin their respective failovers. If acomponent is lost unexpectedly due to a power or hardware failure, abrupt system

shutdown, or physical network interruption, loss of the component may not berecognized by other components for several minutes and overall recovery time maybe lengthened.

For more information, see the PATROL Console Server and RTserver Getting Startedguide.

NOTE Copying configuration filesfroma running or active PATROL Console Server is supportedonly by using the online backup capability. Copying configuration files intoa running oractive PATROL Console Server is not supported. When using the admin_copy tool, copyingconfigurations between PATROL Console Servers requires that both PATROL Console Serverprocesses be shut down.


32/104


33/104

Event Management Planning


If there are distinct groups of console users, PATROL Console Server performancecan be improved by configuring separate PATROL Console Servers for each group ofusers. This approach is only practical if the enterprise is large and complex, and ifthere 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 thanto divide the console session workload between PATROL Console Servers. Theadditional manual effort needed to keep common management profiles synchronizedusually outweighs the performance improvement provided by a second PATROLConsole Server.

PATROL Central Operator Microsoft Windows Edition is fully supported underMicrosoft Windows Terminal Services. The memory requirement for each consolesession depends on the number of concurrent managed objects, and the CPU

utilization depends on the activity of each console session. A good technique forsizing the Terminal Services host system is to configure a typical session and multiplyits resource consumption by the anticipated number of concurrent console sessions.

Event Management Planning

Nearly all contemporary PATROL implementations are configured to generate andforward events to an operations center for resolution. Tools from BMC Software and

other vendors are used to receive and manage resolution of events originating fromPATROL. PATROL managed nodes can generate events for a wide variety of reasons,but many of these events, while useful when troubleshooting or reconstructing aproblem scenario, are of little help or interest to an operations center. Deciding whichevents to forward and who should receive them is a key factor in satisfaction withPATROL.

BMC Software provides a KM solution for event processing called the PATROLKnowledge Module for Event Management (KM for EM). This KM serves multiplefunctions, and when installed and preloaded on a managed node allows eventprocessing and filtering to be done at the source of the event. It also facilitates

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 listare loaded in the profile automatically. This feature allows profiles to automatically stay insync with changes to the preloaded KM list on each managed node.


Configure preloaded and disabled KMs appropriately on each managed node to minimizethe time required for agent startup and console session initiation.


34/104

Notification Server Usage and Placement


advanced configuration management from a central location using PATROLConfiguration Manager (PCM). PCM is addressed in greater detail elsewhere in thisguide, but it is important to note that some PCM functionality requires the KM forEM to be active on the managed node.

There are two methods for forwarding events from PATROL Agents to eventmanagement products that are not part of the PATROL architecture. Both methodsleverage the KM for EM on each managed node, but use different methods forforwarding events.

"In-band" event propagation leverages the RT cloud and forwards events based on asubscription model. Implementation of in-band event propagation requiresconfiguration of the PATROL Console Server and use of an add-in module, such asBMC Impact Integration for PATROL version 7.1.01, PATROL Enterprise ManagerConsole Server Connection version 7.1.00, or PATROL Integration for HP NetworkNode 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 thedirect connection port of the agent (the default is 3181) . Most out-of-bandimplementations use the KM for EM in a special configuration commonly known as aNotification Server. Managed nodes forward trusted (filtered) events directly to theNotification Server consolidation point. Event Management applications receiveevents from the Notification Server.

Notification Server Usage and Placement

A Notification Server is a special configuration of a PATROL Agent running the KMfor EM. A Notification Server receives event messages from a group of managednodes, optionally pre-processes them, and forwards them to an event managementsystem.


Install and configure the PATROL KM for Event Management to be preloaded on allmanaged nodes.

To minimize network traffic, configure the KM for EM on each managed node to create atrusted event for all events to be forwarded.

PATROL KM for EM configuration is best administered using PCM.


35/104

Centralized Customization Management


Centralized Customization Management

The PATROL Configuration Manager (PCM) is a GUI-based tool used to define anddistribute 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

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 itsgeographical or network location is not critical. Distribution of rulesets through afirewall requires an open port for PCM.

Some managed node attributes cannot be controlled using PCM because of the waythose attributes are implemented. An example is data collection blackout. Some KMsare hard-coded to assure that their data collectors are available continuously, so ifdata collection is stopped with PCM, the local KM code will automatically re-enableit. Always verify compatibility of KM attributes before attempting to control themwith PCM.

PCM implements locking on its configuration files, so only one modification sessionmay be open at a time.

If responsibilities for the enterprise are divided among multiple administrators,consider implementing separate PCM instances for each administrative team.


Use a Notification Server or BMC Impact Integration for PATROL version 7.1.01,PATROL Enterprise Manager Console Server Connection version 7.1.00, orPATROL Integration for HP Network Node Manager version 7.1.00to centralizeevent 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 onthe same computer with the primary RTserver for each RT cloud. Regardless of itsplacement, a single Notification Server can service no more than 500 managed nodes.


Use PCM to centralize administration of managed node settings.


Include no more than 700 managed nodes in any agent group (agent.ini file). Configure PCMto allow no more than 20 concurrent ruleset distributions.


36/104

Designing for PATROL Management/Upgrade/ Patching


Designing for PATROL Management/Upgrade/Patching

PATROL Central infrastructure consists of a number of interdependent serviceswhich must function together. The PATROL Infrastructure Monitor has beendeveloped to provide proactive infrastructure monitoring and to raise alerts if criticalservices are interrupted. All PATROL Central implementations should use thePATROL Infrastructure Monitor.

Using the Distribution Server

Placement of the Distribution Server (DS) in the enterprise is dictated by the needs ofits users. A single DS can deploy software to all nodes across an enterprise, so itsgeographical or network location is not critical. Distribution of software through afirewall requires an open port for the DS.

There are no universal best practice recommendations for defining distributioncollections. Factors to consider, however, include

The more components defined in a collection, the greater the chance for a versionconflict and subsequent distribution failure

Deployment times are higher for large collections than for small ones


Install one instance of the PATROL Infrastructure Monitor to monitor the health of PATROLCentral infrastructure. A single instance can monitor all of the clouds in your environment.For more information, see Appendix A, Frequently Asked Questions.

Best Practice Recommendation BP19Use the Distribution Server to centralize PATROL software deployment to managed nodes.

NOTE All components and patches for PATROL products are currently packaged for usewith the Distribution Server.


Verify the compatibility of components, patches, and hot fixes with Customer Supportbefore planning to deploy them with the DS.


37/104

Security Considerations


Small collections deploy more rapidly than large ones, but may require multiplereboots of the same computer (depending the software being deployed)

Large collections may require more administrative effort than small ones, since thecollection must be updated when any component in it changes


PATROL security level settings are defined by each customer's security policy andare largely beyond the scope of this document except to state that PATROL ConsoleServer 7.5.00 supports the limited interoperability between consoles and agentsrunning at different security levels.

Starting with the 7.5.00 release, the RT cloud connection to a PATROL Console Servercan 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 differentsecurity levels can be connected to the PATROL Console Server transparently to theconsoles and agents in those different clouds. For more information, see the PATROLConsole Server and RTserver Getting Startedguide.


38/104




39/104


C h a p t e r 44PATROL Central EnvironmentPhysical Mapping


Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Hardware Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Single Server Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40RTserver Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42PATROL Console Server Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45PATROL Central Operator Web Edition Hardware . . . . . . . . . . . . . . . . . . . . . . . 46PATROL Central Operator Microsoft Windows Edition Hardware . . . . . . . . . 47

Co-Hosting PATROL Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47PATROL Console Server Platform Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

RTserver Implementation Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49RT Cloud Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49PATROL Console Server Implementation Tips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Clustering a PATROL Console Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51


40/104

Overview


Overview

Once the logical design is complete, PATROL Central infrastructure componentsmust be assigned to specific servers. To accomplish this, all components must be

reviewed by type and assigned to computers in the solution diagram. This processtypically requires several passes through the design as the capacities of existingservers and their abilities to host particular components are assessed.

ACTION 7

Using guidelines presented in this section, determine the hardware needed to host allcomponents identified in the logical design phase. Update solution diagrams toreflect CPU, memory, and disk capacity of all infrastructure servers.

Hardware Requirements

The servers needed to host PATROL infrastructure vary in configuration based on thecomponents 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 guidelinesare presented in the following sections to help with computer selection andconfiguration. Except as noted, these computers are dedicated systems that only runPATROL infrastructure and do not run major applications.

Single Server Environments

A single server hosting an RTserver, PATROL Console Server, and PATROL CentralOperator Web Edition can be used to manage an environment of up to 3 millionmanaged objects in a single RT cloud (with no more than 700 agents) provided thecomputer is sufficiently powerful. The hardware requirements for various single-computer configurations are described in Table 1 on page 41and Table 2 on page 41.


It is not typically necessary to host the PATROL Console Server on a high-end system. ThePATROL Console Server needs a fast CPU and a generous amount of RAM more thanexceptional network and disk I/O performance, and a workgroup class server will usuallysuffice.


41/104

Single Server Environments


Table 1 Requirements for Small Single-Server PATROL Central Environment (Up to500,000 managed objects)

Resource Minimum Requirements Recommendation

Processor Linux and Windows

Single Processor Intel Pentium III at 800 MHz

Solaris

Single Processor SUN Netra X1 at 500 MHz

AIX

Single Processor IBM pSeries POWER 3 II at 450

MHz

Linux and Windows

Dual Processor Intel Pentium III at 800 MHz

Solaris

Dual Processor SUN 420R UltraSPARC II at

450 MHz

AIX

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 (Upto 3 million managed objects)



Dual Processor Intel Pentium 4 at 2000 MHz

Xeon

Solaris

Dual Processor SUN V240 UltraSPARC III at

1000 MHz

AIX

Dual Processor IBM pSeries POWER 4 at 1000

MHz

Linux and Windows

Quad Processor Intel Pentium III at 900 MHz

Solaris

Quad Processor SUN V480/880 at 900 MHz

AIX

Quad Processor IBM pSeries POWER 4 at 1000

MHz

Server Memory 3 GB 4 GB

Disk Space 1 GB 2 GB


42/104

RTserver Hardware


RTserver Hardware

If the requirements of a PATROL infrastructure server exceed the recommendedcapacity of a single computer or if special circumstances warrant, RTservers can be

installed on separate computers (primarily to support one or more clouds of PATROLAgents). In such circumstances it is usually best to choose a computer with arelatively fast CPU and large memory in order to allow the RTserver to maintain highthroughput under peak conditions. This need notwithstanding, a dedicated RTservercomputer will typically have spare capacity for use by other PATROL infrastructurecomponents such as a Notification Server or a PATROL Reporting aggregator. Thereare scenarios where multiple RTservers can be hosted on the same computer toreduce the hardware costs associated with hosting PATROL infrastructure.

Table 3shows the hardware requirements for a single RTserver running on adedicated computer, separate from the PATROL Console Server or PATROL Central

Operator Web Edition.

Starting with the release of RTserver version 6.5.01, PATROL Central supportsconfigurations with more than one RTserver on the same computer. Depending on itsspeed and workload (the total number of RT clients connected to all RTservers on thecomputer), a single computer can host up to four RTservers. Table 4 on page 43andTable 5 on page 44show the recommended hardware for different workloads:

Table 3 Requirements for One RTserver on a Dedicated Computer (Up to 750 RTclients)



Single Processor Intel Pentium III at 733 MHz

Solaris

Single Processor SUN UltraSPARC IIi at 400

MHz

AIX

Single Processor IBM pSeries POWER 3-II at 333

MHz

Linux and Windows

Single Processor Intel Pentium 4 at 1.4 GHz

Solaris

Single Processor SUN UltraSPARC IIe at 500

MHz

AIX

Single Processor IBM pSeries POWER 3-II at 500

MHz

Server Memory 512 MB 1 GBDisk Space 300 MB 300 MB


43/104

RTserver Hardware


Table 4 Requirements for Two RTservers on a Dedicated Computer (Up to 1000 totalRT clients)

Resource Recommendation


Single Processor Intel Pentium 4 at 1400 MHz

Solaris

Single Processor SUN UltraSPARC IIe at 500 MHz

AIX

Single Processor

IBM pSeries POWER 3-II at 375 MHzServer Memory 1 GB

Disk Space 300 MB


44/104

RTserver Hardware


For more information about configuring more than one RTserver to run on the samecomputer, see the PATROL Console Server and RTserver Getting Startedguide.

When running more than one RTserver on the same computer, the number of backupand 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 asthe primary for cloud A and the backup for cloud B while the other computer servesas the primary for cloud B and the backup for cloud A. This distributes the workloadacross both RTservers and minimizes the impact of losing a single computer.

Table 5 Requirements for Two to Four RTservers on a Dedicated Computer (Up to2000 RT clients)


Processor Linux


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 thesame Windows-based computer. For more

information on configuration, seeRTserver Hardware on page 42.

Server Memory 2 GB

Disk Space 300 MB


45/104

PATROL Console Server Hardware


PATROL Console Server Hardware

Table 6describes minimum and recommended hardware for PATROL ConsoleServer version 7.5.00 in medium (up to 3 million managed objects) and Table 7 on

page 46describes large (up to 10 million managed objects) environments.

An RTserver can be run on the PATROL Console Server computer to support a cloudof PATROL Central consoles, but all agent RT clouds should be hosted on other

hardware.


It is not typically necessary to host the PATROL Console Server on a high-end system. ThePATROL Console Server needs a fast CPU and a generous amount of RAM more thanexceptional network and disk I/O performance, and a workgroup class server will usuallysuffice.


Set PATROL Console Server overload protection limits based on the estimated workload ofeach PATROL Console Server in the solution design. For more information about overloadprotection and the type of limits that are available, see the PATROL Console Server andRTserver Getting Startedguide.

Table 6 Requirements for a Medium PATROL Console Server Environment (Up to 3million managed objects)




Solaris

Dual Processor SUN 280R UltraSPARC III at

750 MHz

AIX

Dual Processor IBM pSeries POWER 3-II at 450

MHz

Linux and Windows


Solaris

Dual Processor SUN V240 UltraSPARC IIIi at 1

GHz

AIX

Dual Processor IBM pSeries POWER 4 at 1200

MHz




46/104

PATROL Central Operator Web Edition Hardware


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 recentrelease of PATROL Central Operator Web Edition. Hardware recommendations forhosting this component of PATROL infrastructure will be provided when an

assessment is complete. Contact BMC Software and the PATROL Line Of Business forupdated information.

Table 7 Requirements for a Large PATROL Console Server Environment (Up to 10million managed objects)


Processor Linux

Dual Processor Intel/HP Itanium 2 at 900 MHz

Solaris

Dual Processor SUN V240 at 1280 MHz

AIX

Dual Processor

IBM pSeries POWER 4 at 1450MHz

Windows

Due to the virtual memorylimitations of 32-bit hardware,large PATROL Console Serverconfigurations cannot behosted on a single Windowscomputer.

Linux

Quad Processor Intel/HP Itanium 2 at 900 MHz

Solaris

Quad Processor SUN V480/880 at 900 MHz

AIX

Quad Processor

IBM pSeries POWER 4 at 1200MHz




47/104

PATROL Central Operator Microsoft Windows Edition Hardware


PATROL Central Operator Microsoft Windows EditionHardware

Table 8lists hardware requirements for different profile sizes:

Co-Hosting PATROL Components

The following recommendations provide direction on which PATROL componentscan reside with one another on the same host:

Table 8 Requirements for PATROL Central Operator Microsoft Windows Edition(based on profile size)


Small Profiles (up to 100 managed agents)

Processor Single Processor Intel Pentium III at 500 MHz

Memory 128 MB

Medium Profiles (up to 500 managed agents)


Memory 512 MB

Large Profiles (up to 1200 managed agents)


Memory 1 GB

NOTE

Profiles with 500 or more agents take several minutes to finish loading.


48/104

PATROL Console Server Platform Selection


PATROL Console Server Platform Selection

Although there were circumstances under which prior releases of the PATROLConsole Server performed better on 32-bit Intel servers than on Sun servers, this is nolonger the case. Version 7.5.00 of the PATROL Console Server can be implemented on

either platform with equal efficiency.


All infrastructure components can now coexist with other infrastructure componentsprovided 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 whenpossible place the PATROL Console Server and RTserver on a dedicated host. Try tokeep that system free of other applications.

If the underlying platform is supported by both components, an RTserver should beinstalled on the same host as the PATROL Console Server, and the PATROL ConsoleServer and PATROL Central consoles should be configured to connect to this RTserver.This arrangement will minimize the overhead of communication between the consoleand the PATROL Console Server.

Neverinstall a PATROL Console Server or RTserver on a computer running any of thefollowing 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 aboutincompatibilities and configuration techniques for co-locating components.

PATROL Central Operator Web Edition version 7.1.10 cannot be installed on the samecomputer as PATROL Central Alerts Web Edition version 7.2.01. See the followingProduct Flash for further information:http://documents.bmc.com/supportu/documents/37/38/43738/Output/090f44b180282615.htm


Environments with up to 3 million managed objects or 25 concurrent users can be hosted on32-bit hardware. Environments with up to 10 million managed objects or 100 concurrentusers must be hosted on 64-bit hardware.
http://documents.bmc.com/supportu/documents/37/38/43738/Output/090f44b180282615.htmhttp://documents.bmc.com/supportu/documents/37/38/43738/Output/090f44b180282615.htmhttp://documents.bmc.com/supportu/documents/37/38/43738/Output/090f44b180282615.htmhttp://documents.bmc.com/supportu/documents/37/38/43738/Output/090f44b180282615.htmhttp://documents.bmc.com/supportu/documents/37/38/43738/Output/090f44b180282615.htmhttp://documents.bmc.com/supportu/documents/37/38/43738/Output/090f44b180282615.htmhttp://documents.bmc.com/supportu/documents/37/38/43738/Output/090f44b180282615.htm


49/104

RTserver Implementation Tips


A PATROL Console Server on 32-bit hardware that supports 3 million objectsrequires 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 3GB by using an optional argument (/3GB) in the boot.inifile; versions of Windowsthat 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 PATROLRTservers:

RT Cloud Configuration

RTservers are capable of handling large numbers of client connections and can beconfigured to support messaging failover through appropriate client configuration.Their proper configuration is key to the performance and stability of a PATROLCentral implementation.


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 behosted on the same computers as the PATROL Console Server and PATROL CentralOperator Web Edition.

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.


50/104

RT Cloud Configuration


Two or more RTservers in the same infrastructure create what BMC Software refersto as an RT cloud (or sometimes a messaging domain). An RTserver can join an RTcloud 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 areguidelines which will prevent and/or reduce unexpected performance and stabilityissues:


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'snames.

For the simple case of a cloud containing just a primary and a backup RTserver, set theserver_names variable in the primary RTserver to UNKNOWN and set theserver_names variable in the secondary RTserver to point to the primary RTserver.

Plan and control the direction of initialization through firewalls. The preferredconfiguration consists of separate RT clouds within each DMZ, with the PATROLConsole Server initiating connections to each through the firewall.

If several DMZs or remote sites are linked into a single RT cloud using hub-and-s

patrol central infrastructure best practices guide

Documents