BMC Impact Solutions Infrastructure Management Guide

(1)

BMC Impact Solutions

Infrastructure Management

Guide

Supporting

(2)

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 713 918 8000

Outside United States and Canada

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

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

AIX® is a registered trademark of International Business Machines Corporation in the United States, other countries, or both.

ITIL® is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office, and is used here by BMC Software, Inc., under license from and with the permission of OGC. Linux is the registered trademark of Linus Torvalds.

Oracle is a registered trademark of Oracle Corporation.

Sun, Java, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc., in the U.S. and several other countries. UNIX is the registered trademark of The Open Group in the US and other countries.

BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices 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

(3)

Customer support

You can obtain technical support by using the BMC Software Customer Support website or by contacting Customer Support by telephone or e-mail. To expedite your inquiry, see “Before contacting BMC.”

Support website

You can obtain technical support from BMC 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 offers ■ _{find the most current information about BMC products}

■ _{search a database for issues similar to yours and possible solutions} ■ _{order or download product documentation}

■ _{download products and maintenance} ■ _{report an issue or ask a question}

■ subscribe to receive proactive e-mail alerts when new product notices are released

■ _{find worldwide BMC 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 [email protected]. (In the subject line, enter SupID:<yourSupportContractID>, such as SupID:12345). Outside the United States and Canada, contact your local support center for assistance.

Before contacting BMC

Have the following information available so that Customer Support can begin working on your issue 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 issue ■ _{commands and options that you used}

■ _{messages received (and the time and date that you received them)} — product error messages

(4)

(5)

Figures

ConnectionPortRange syntax . . . 30

Distributed event management using event propagation . . . 33

Format of an entry in the mcell.dir file . . . 34

Example of the mcell.dir file and its entries . . . 35

Passive connection format . . . 36

Data object specification . . . 37

mcell.modify file . . . 38

Masking syntax . . . 41

Format of configuration line in mcell.trace file . . . 51

Knowledge Base directory structure . . . 67

Output from mgetinfo kbsources argument . . . 75

Relation among users, groups, roles, and permissions . . . 82

Excerpt from ldap_configuration.xml file . . . 111

Default Infrastructure Management service model . . . 140

Infrastructure Management navigation pane . . . 143

Default service model BMC Impact Solutions (with active services) . . . 144

Edit Relationships dialog with Edit This Relationship subdialog . . . 156

Actions right-click menu . . . 160

High availability (HA) view: two cell servers . . . 161

Actions right-click menu for OVO adapter cells . . . 162

default.econ.config file contents . . . 178

Operator.econ.config file contents . . . 178

Default policy file . . . 181

Listing of the contents of a keystore file . . . 195

Parameters used to print event in BAROC format . . . 204

Example of printed events . . . 204

Command to configure the export file . . . 205

gateway.export file format . . . 206

gateway.explore file output for new events . . . 206

gateway.explore file output for modified events . . . 207

mccomp syntax . . . 214

mccomp example . . . 215

Example output for mccomp . . . 215

mcell syntax . . . 216

Starting a cell . . . 217

Starting a cell as a service on windows . . . 217

(12)

Raw output format for mclassinfo . . . 221

Class tree for mclassinfo . . . 221

Example of mclassinfo command for a list of classes . . . 223

Example output of mclassinfo command for a list of classes . . . 223

Example of mclassinfo command for list of classes . . . 223

Example of mclassinfo command output for list of classes . . . 223

Example of mclassinfo command for adding slot names . . . 224

Example of mclassinfo command output for adding slot names . . . 224

Example of mclassinfo command for adding slot flags . . . 224

Example of mclassinfo command output for adding slot flags . . . 224

mcollinfo syntax . . . 225

Raw output format for mcollinfo . . . 226

mcollinfo example . . . 227

mcollinfo command for verbose mode . . . 227

mcollinfo command for number of events for severity/status . . . 227

mcontrol syntax . . . 228

Retrying Pending propagations with mcontrol command . . . 230

Example of mcontrol command output for retrying pending propagations . . . 230

Terminating a cell using the mcontrol command . . . 230

Example of mcontrol command output for terminating a cell . . . 231

Reconfiguring a cell . . . 231

Example of mcontrol command output for reconfiguring a cell . . . 231

mcrtcell syntax . . . 233

Example of mcrtcell command . . . 234

Example of output of mcrtcell . . . 234

Example of mcrtcell command . . . 234

Example output of mcrtcell . . . 234

Example mcrtcell for recreating an Admin cell . . . 235

mcstat syntax . . . 236

mcstat example . . . 236

Message for cell not running . . . 236

Message for cell running . . . 236

mdelcell syntax . . . 237

Deleting a cell using mdelcell . . . 237

Output for mdelcell if cell is not running . . . 237

Output for mdelcell if cell is running . . . 238

mgetinfo syntax . . . 238

Example of mgetinfo param . . . 242

mgetinfo param command output . . . 242

Example of mgetinfo services . . . 242

mgetinfo services command output . . . 242

Example of mgetinfo services . . . 243

Output of mgetinfo connect . . . 243

(13)

mkb command on Microsoft Windows . . . 248

mkb command output on Microsoft Windows . . . 248

mkill syntax . . . 248 Example of mkill . . . 249 Output of mkill . . . 249 mlogchk syntax . . . . 250 Example of mlogchk . . . 250 Output of mlogchk . . . 250 mlogchk message . . . 251 mposter syntax . . . . 252 msend syntax . . . 252 Example of mposter . . . 254

Definition changes using mposter . . . 255

Enabling persistent buffering using mposter . . . 255

Error message if buffers files are not writable . . . 256

mquery syntax . . . . 257

Example of raw output specification . . . 258

Verbose mode options . . . 258

End of form . . . 259

Special BAROC format . . . 259

Example of mquery—Select events with severity status . . . 261

Example of mquery—Select events from collector . . . 261

Deleting events using mquery . . . 261

mrecover syntax . . . 263

Fixing a broken cell using mrecover . . . 263

mrextract syntax . . . . 264 Example of mrextract . . . 264 mrmerge syntax . . . 265 Example of mrmerge . . . 266 msetmsg syntax . . . 267 msetrec syntax . . . 268 Example of msetrec . . . 269

command to send tracing output to text file . . . 272

(14)

(15)

Tables

BMC Impact Solutions configuration process . . . 24

Cell configuration tasks . . . 27

Substitution parameters for %X in path value parameters . . . 29

Default mcell.propagate options . . . 32

IP Address parameters . . . 42

Files for cell reconfiguration . . . 43

MC_CELL_METRIC slots . . . 48

Default values for client parameters . . . 49

MC_CELL_CLIENT slots . . . 50

MC_CELL_MODIFIED_EVENT slots . . . 50

Trace configuration file parameters . . . 51

MC_CELL_PROCESS_ERROR slots . . . 56

BMC Impact Manager exit codes . . . 57

SIM_NOTIFICATION_REGISTRY dialog box fields . . . 61

Knowledge Base subdirectories . . . 68

Knowledge Base file extensions and directories . . . 69

Configurable IAS files . . . 78

iadmin options . . . 79

BMC Impact Explorer user group mapping to functionality . . . 83

Groups and roles . . . 89

Cell entry format in cell_info.list . . . 96

Server logging properties . . . 98

IAS status monitoring properties . . . 100

IAS thread pool properties . . . 100

IAS synchronization properties . . . 103

mcell.dir entries for a failover pair of Impact Administration cells . . . 105

IAS log files . . . 106

LDAP configuration parameters . . . 111

Event operations . . . . 117

Event Table column default values . . . 125

Status table column default values . . . 126

Report parameters (application.properties file) . . . 128

Report parameters (internal.properties) file . . . 129

application.properties file in smsIwc directory . . . 133

application.properties file in smsConsoleServer directory . . . 134

aggregator.properties file . . . 136

(16)

Edit Relationship dialog: field descriptions . . . 156

Edit This Relationship subdialog . . . 157

Audit log parameters . . . 166

Audit log IAS properties . . . 168

Slots for specifying support files . . . 170

run_state values for components . . . 174

Component state and menu options for a normal or primary cell in a high availability configuration . . . 175

Component state and menu options for a secondary cell in a high availability configuration . . . 175

Components and actions . . . 176

default.console_policy.prop parameters . . . 180

Property descriptions from ix.properties file . . . 183

Event severity levels and colors . . . 184

Event priority levels and colors . . . 185

Event group configuration files . . . 185

xml files that define user interface elements in BMC IX . . . 186

Presentation names for BMC Impact Solution interfaces . . . 188

Presentation name key formats . . . 192

StateBuilder file name conventions . . . 198

statbld.conf Parameters . . . 199

statbld return codes . . . 199

Gateway configuration parameter predefined variables . . . 201

Gateway Configuration Parameter Text Values . . . 201

gateway.export file parameters . . . 202

BMC Impact Manager CLI command descriptions . . . 210

Common options for CLI commands . . . 211

Common return codes for CLI commands . . . 214

mccomp options . . . 215

mcell options . . . 216

mcell return codes . . . 218

mcfgtrace option . . . . 219

mcfgtrace parameters . . . 219

mclassinfo options . . . 220

Type of slot value for mclassinfo . . . 221

Reported facets . . . 222

Class flags . . . 222

Information amount limitation options for mclassinfo . . . 222

mclassinfo return codes . . . 225

mcollinfo options . . . . 225

Information amount limitation options for mcollinfo . . . 227

mcollinfo return codes . . . 228

mcontrol option . . . 228

mcontrol controls . . . . 229

Files for UNIX . . . 233

mcrtcell options . . . 233

mcrtcell return codes . . . 235

mcstat option . . . 236

(17)

mdelcell return codes . . . 238

mgetinfo option . . . . 239

mgetinfo information options . . . 239

Information from connect request . . . 240

mgetinfo return codes . . . 243

mgetrec option . . . 244

mkb options . . . 245

mkb new file options . . . 246

mkill option . . . 249

mlogchk return codes . . . 251

mposter and msend options . . . 252

mposter and msend return codes . . . 257

mquery options . . . 257

mquery query options . . . 260

mquery return codes . . . 262

mrecover option . . . 263

mrecover return codes . . . 263

mrextract options . . . 264

mrextract return codes . . . 265

mrmerge options . . . 266

mrmerge return codes . . . 266

msetmsg options . . . 267

msetmsg return codes . . . 268

msetrec options . . . 268

msetrec return codes . . . 269

BMC Impact Manager CLI configuration parameters . . . 270

Action result event parameters . . . 274

Cell configuration parameters . . . 274

Cell failover configuration parameters . . . 276

Client communication parameters . . . 278

Date and time format parameters for Solaris . . . 279

Encryption parameters . . . 280

Event Repository cleanup parameters . . . 281

Heartbeat parameters . . . 284

Heartbeat slots . . . 286

Internal cell monitors parameters . . . 287

KB parameters . . . . 287

Propagation parameters . . . 288

Deprecated MessageBuffer propagation parameters . . . 290

Reporting client connection parameters . . . 291

Service model parameters . . . 292

State Builder parameters . . . 292

(18)

(19)

C h a p t e r

1

Managing BMC Impact Manager

cells

This chapter describes how to manage and configure BMC Impact Manager cells.

General configuration overview . . . 24

Cell configuration tasks. . . 27

Configuring mcell.conf parameters . . . 28

Configuring event slot propagation . . . 31

Configuring passive connections . . . 36

Configuring slots for time stamping. . . 37

Configuring encryption . . . 38

Reloading cell configuration. . . 43

Managing high availability cell servers . . . 44

Manually failing over to the secondary server . . . 46

Manually switching back to the secondary server . . . 46

Automatic failover process . . . 45

Automatic switchback process . . . 45

Explicitly connecting a CLI to a selected high availability cell server. . . 47

Monitoring event performance . . . 47

Monitoring client to cell interactions . . . 49

Configuring cell tracing . . . 50

Configuring mcell.trace . . . 51

Configuring a destination for cell trace output. . . 52

Sending trace output to another cell. . . 53

Event processing errors . . . 55

Automatic notification of trace configuration changes . . . 56

Interpreting cell execution failure codes. . . 56

Using the BMC IX Administration view to manage cells . . . 58

Connecting or disconnecting a cell . . . 58

Viewing cell information . . . 58

Registering for SIM notification events . . . 59

(20)

General configuration overview

To configure the BMC Impact Solutions environment, you configure the following components after installation:

■ BMC Impact Manager cell ■ BMC Impact Explorer ■ BMC Impact Portal

Table 1 outlines the tasks that configure these components.

After you configure BMC Impact Manager, BMC Impact Portal, and BMC Impact Explorer, you are ready to implement event management and service impact management. For information, consult the following resources:

Table 1 BMC Impact Solutions configuration process

Task Description Component For more information, see

1 (optional) Configure the BMC Impact Portal. BMC Impact Portal Chapter 4, “Managing the BMC Impact Portal” BMC Portal Getting Started

2 Configure BMC Impact Manager cells. BMC Impact Manager Chapter 1, “Managing BMC Impact Manager cells”

3 Define user groups for access to the console functions and objects.

BMC Impact

Administration Server

Chapter 3, “Managing the BMC Impact Administration server”

4 Distribute the BMC Portal URL address so users can install consoles.

BMC Impact Explorer can be deployed as a Java Web Start application from BMC Impact Portal or installed standalone.

■ _{BMC Impact Portal} ■ _{BMC Impact Explorer} ■ _{BMC Impact Service}

Model Editor

BMC Portal Getting Started BMC Impact Solutions Installation Guide

5 (optional) Customize BMC Impact Portal. BMC Impact Portal Chapter 4, “Managing the BMC Impact Portal”

6 (optional) Customize BMC Impact Explorer. BMC Impact Explorer Chapter 6, “Managing the BMC Impact Explorer (BMC IX) console”

7 (optional) Configure the StateBuilder, which

manages the persistent storage of events.

BMC Impact Manager Chapter 8, “Configuring StateBuilder and gateways”

8 (optional) Customize the labels used in the

(21)

Production cells and test cells

■ Event management

— For information about setting up adapters to collect events, see the BMC Impact

Event Adapters User Guide.

— For information about setting up dynamic data, policies, event groups, and image views, see the BMC Impact Solutions Event Management Guide.

— For information about defining event data, writing event management rules, defining collectors, or creating actions, see the BMC Impact Solutions Event

Management Guide. ■ Service impact management

— For information about monitoring service impact management, see BMC Impact

Solutions Service Impact Management Guide.

— For information about defining service models, see the BMC Impact Solutions

Service Modeling and Publishing Guide.

Production cells and test cells

A production cell is an EM or SIM cell that service operators and service managers use to monitor the events and services associated with your IT resources in real time.

A test EM or SIM cell provides senior service managers and service administrators with a test environment in the following ways:

■ SIM cell

Enables publishing of service models from a development sandbox to a test environment before promoting them to a production environment. Each BMC Impact Service Model Editor user has one dedicated test environment, which consists of a pair of test CMDB data sets and an alias to a test cell. Promoted service model components include those in a user’s sandbox and in production. For details about test environments and promotion, see the BMC Impact Solutions Service

Modeling and Publishing Guide. ■ EM cell

(22)

Production cells and test cells

Production and test cell naming and creation

The only way to distinguish a test cell from a production cell is by the cell name. Adopt a naming convention for test and production cells that clearly identifies its purpose.

You name a cell when it is created. One cell is created with each BMC Impact Manager instance that you install. You use the mcrtcell command to create additional production or test cells. The mcrtcell_{command can only be run on the}

local computer where the cell is being created. For more information about syntax and options available with mcrtcell, see “mcrtcell—Creating a new cell” on page 231.

Production and test cell configuration

You register test and production cells in BMC Impact Portal. For instructions, see “Registering production and test cells in the BMC Impact Portal” on page 124.

In BMC Impact Service Model Editor, each user associates a test cell to a test

environment. For further information, see BMC Impact Solutions Service Modeling and

Publishing Guide.

In BMC Impact Explorer, assign the production and test cells to a group. The default groups are MyTest and MyProduction.

Viewing test cell data

You view test data in BMC Impact Explorer.

■ To view test event data, collectors, and actions, select a test cell in the Events view.

■ To view and create test event management policies, select a test cell in the

Administration view.

■ To view test service model components, use the Find tool in the Services view and

(23)

Cell configuration tasks

The more you customize your cell to fit your needs, the more efficiently the cell works. All configuration tasks are optional. Table 2 describes the cell configuration tasks.

Table 2Cell configuration tasks

Task Description For more information, see

1 Create additional cells.

When you install BMC Impact Manager on a system, one cell is installed. You can create additional cells by running the mcrtcell command.

“mcrtcell—Creating a new cell” on page 231

2 If you created multiple cells for an environment, you can create separate configuration files for each cell.

“Creating cell-specific

configuration files” on page 30

3 If you created multiple cells for an environment, configure the cells so that they can communicate with other cells in the network.

BMC Impact Solutions Getting Started Guide

4 If you created multiple cells for an environment, configure a high availability cell or cells.

BMC Impact Solutions Getting Started Guide

“Managing high availability cell servers” on page 44

5 Events can be processed locally or selectively propagated to other cells. To configure the event slots that must be propagated when they are changed configure the propagation configuration file.

“Configuring event slot propagation” on page 31

6 If inbound connections to the cell are disallowed in a protected environment, the connection has to be established within the protected zone to allow a connection between an external client and a cell in the protected zone.

“Configuring passive connections” on page 36

7 To add a time stamp to a slot so that the date and time is recorded when the slot is changed, configure the mcell.modify file.

“Configuring slots for time stamping” on page 37

8 If desired, you can encrypt communication among the various BMC Impact Solutions components.

“Configuring encryption” on page 38

(24)

Configuring mcell.conf parameters

The mcell.conf configuration file installed with the cell allows it to run without any additional configuration. You can change the configuration parameters in the

mcell.conf file to customize the cell for your particular IT infrastructure and environment. You can override some parameters using command line arguments when you start the cell. For more information, see “mcell—Starting a cell” on page 216.

To configure the mcell.conf file using a text editor

1

Open the mcell.conf file in a text editor.

The default location is MCELL_HOME\etc.

2

Create line entries using the format Parameter=Value based on the syntax rules described in “Rules for cell configuration parameter syntax”.

3

Save the changes.

4

Either reload the cell configuration or restart the cell for the changes to go into effect. For more information, see “Reloading cell configuration” on page 43.

Rules for cell configuration parameter syntax

■ One parameter per line, in the form: Parameter=Value

where the Value extends to the end of the line

■ Typically, the value for a parameter is a Boolean value, a string, or a path. The

supported Boolean values are Yes/No and On/Off.

■ The Boolean values are not case sensitive, so, for example, On, ON, on, and even

oN are equally valid.

■ Do not enclose the value in quotation marks unless you want the quotation marks

to be part of the value.

■ Times are stated in seconds unless otherwise specified.

■ By default, all parameter settings are disabled, that is, commented out with a #

sign at the beginning of the line of code. Enable a parameter setting by removing the # sign that precedes it.

(25)

Configuring mcell.conf parameters

Specification of path values

Parameters that have path values contain the string fileName or dirName, for example TraceConfigFileName or SystemLogDirName.

Path values can be stated as:

■ absolute path—starts with slash (/) or backslash (\), or on Windows, with a drive

designator (for example, D:)

■ runtime relative path—starts with ./ or ../. The path is relative from the cell’s

working directory. The working directory is the root directory (/) when it runs as a daemon or a service. When running in foreground, it is the directory where mcell is started.

■ configuration relative path—all other path values are relative from the cell’s

configuration directory, or, for program paths, from the kb\bin directory.

Path values can contain the substitution parameters $VAR or %X. Any $VAR parameter is substituted by the value of the environment variable VAR. Table 3 lists the possible %X substitution parameters.

Modifying SystemLogDirName, SystemTmpDirName, and

KBDirName

With the cell configuration parameters SystemLogDirName and SystemTmpDirName, users can specify alternative path locations for the system defined log and tmp

directories. Their default values are %H/log and %H/tmp. To enable file name

specifications that refer to these alternative locations, use the substitution parameters

%L for the log and %T for the tmp directory. They are substituted by the specified path to the log and tmp directory, respectively.

Table 3 Substitution parameters for %X in path value parameters

Parameter Description

%H cell home directory

%C cell configuration directory

%B Knowledge Base binary directory, kb\bin %L log file directory

%T temporary file directory %P program name

(26)

Creating cell-specific configuration files

If you change the default value for the SystemLogDirName parameter or the

KBDirName parameter in the mcell.conf file, you must also change the value in the

statbld.conf file. If you fail to do this, the cell loses persistency and the mcdb file is not created, because the StateBuilder is configured from statbld.conf file and has no input from the mcell.conf file. As a result, StateBuilder does not know where to find the log files or the KB directory it requires.

ConnectionPortRange syntax

Figure 1 shows the syntax of ConnectionPortRange.

A range is a number of sequences, each of which is a consecutive range of ports. The cell attempts to access all ports in the specified order. The default is to use any of the ephemeral ports.

For example,

■ 1828—1840 specifies a range of ports 1828 through 1840

■ 1828, 1829, 1840 specifies the sequence of ports 1828, 1829, and 1840

Creating cell-specific configuration files

By default, one set of configuration files is installed during installation of the BMC Impact Manager. These files are located in the MCELL_HOME\etc directory and multiple cells on a host can use them. You can also create unique configuration files for individual instances (cells) as needed.

To create cell-specific configuration files

1

Copy the configuration file that you want to be unique to the

MCELL_HOME\etc\cellName directory. cellName represents the name of the cell.

2

Using a text editor, edit the configuration file and customize it for that cell and save it.

You can copy and edit any configuration file located in the MCELL_HOME\etc

directory.

3

Either reload the cell configuration or stop and start the cell so that the changes Figure 1 ConnectionPortRange syntax

(27)

Configuring event slot propagation

When a cell starts, it searches for configuration files in the

MCELL_HOME\etc\cellName directory. If no configuration file is found, the cell uses the configuration file in the MCELL_HOME\etc directory. For example, if you copy the mcell.conf file into the MCELL_HOME\etc\cellName directory and modify it, the cell reads that mcell.conf file and all other files in the MCELL_HOME\etc

directory.

All cells use the following cell-specific directories:

■ _{$MCELL_HOME/etc/CellName} contains cell-specific configurations (including the

Knowledge Base)

■ _{$MCELL_HOME/log/CellName} contains the cell transaction logs and persistent state

of the cell

■ _{$MCELL_HOME/tmp/CellName} contains the cell’s temporary files

High availability cells use the cell-specific directories, but the names of the log and

tmp directories are suffixed with # followed by the server number, 1 for the primary server and 2 for the secondary server. The names become:

■ _{$MCELL_HOME/log/CellName# 1} ■ _{$MCELL_HOME/log/CellName# 2} ■ _{$MCELL_HOME/tmp/CellName# 1} ■ _{$MCELL_HOME/tmp/CellName# 2}

Configuring event slot propagation

Events can be processed locally or selectively propagated to other cells. To configure the event slots that must be propagated when they are changed, and in which direction (forward/backward), you configure the propagation configuration file

mcell.propagate. The mcell.propagate filelists all of the slots whose modifications will be propagated.

In addition, using the BMC Impact Solutions gateways, events can be propagated to a third-party program in a specific format that is described in a gateway configuration file, gateway.GWType.

The default location for these files is MCELL_HOME\etc.

(28)

For the mcell.propagate file to be effective, one or more Propagate rules must be running. For information about Propagate rules, see the BMC Impact Solutions

Knowledge Base Development Reference Guide.

The format is Slotname = Value_{, where:}

Slotname = slot name or CLASS for class-specific slots

Value = _{sequence of {}b_{= backward}f_{= forward }}

You can specify a slot in the base CORE_EVENT class. However, if you want to specify a slot outside those in the base CORE_EVENT class you must use the CLASS specifier, which means that all class-specific slots are propagated in the direction given.

Table 4 on page 32 lists the parameters in the mcell.propagate file and the defaults.

If you have multiple instances of BMC Impact Manager installed, you might want to use event propagation to distribute the event processing load among the cells or to back up events on another cell for failover.

Figure 2 on page 33 illustrates a cell network that is collecting and processing numerous events in a distributed environment.

Table 4 Default mcell.propagate options

Parameter Action Performed

Default Values administrator propagates administrator value changes up (forward) within the cell hierarchy f

CLASS propagates changes to the class-specific slots up (forward) within the cell hierarchy

f

mc_modhist propagates changes to the mc_modhist up (forward) within the cell hierarchy

This is a system defined slot that requires such propagation.

f

mc_notes propagates changes to notes attached to an event up (forward) within the cell hierarchy

f

repeat_count propagates changes to repeat_count up (forward) within the cell hierarchy f

severity propagates severity value changes up (forward) within the cell hierarchy f

status propagates status value changes in both directions, backward and forward, in the cell hierarchy

(29)

Figure 2Distributed event management using event propagation

In this illustration, the lower-level cells process the source events and then propagate (or forward) the events on to higher-level cells according to a Propagate rule or an Event Propagation policy. As events pass through a series of cells, the cells discard unneeded events, identify and leave behind unimportant events, and resolve some of the problems reported by other events.

To enable event propagation, perform the following tasks:

■ enable cell-to-cell communication in mcell.dir ■ configure propagation parameters in mcell.conf

■ specify the slots whose modification has to propagate in mcell.propagate ■ either write a Propagate rule or define an Event Propagation policy

How unpropagated events are buffered

When the cell is started, the buffers are set to a minimum workable size. The default minimum size is 5000 events for each destination buffer and 5000 requests for the propagation buffer. event sources event sources event sources event sources

Some events are propagated for management by other cells in the cell network.

(30)

About mcell.dir, the cell directory file

If the cell cannot propagate events, the cell stores the events to be propagated in the destination buffers and the requests for propagation of those events in the

propagation buffer. When the buffers become full, the cell automatically expands the buffer size by a specified percentage (10 percent, by default), unless the buffer has exceeded a maximum size. By default, the maximum buffer size is unlimited, although the practical limit of the buffer size is the amount of available memory. Once the maximum defined buffer size is reached, additional requests will fail.

When automatic expansion occurs, an MC_CELL_RESOURCE_EXPANSION event is generated.

An expanded buffer will contain free space after propagation has resumed. To free memory resources, the buffer will be reduced when it contains more than the specified amount of free space. Reduction will leave enough free space to avoid the need for an immediate expansion. The buffer will never be reduced below the specified minimum size. When the buffer is reduced, an MC_CELL_RESOURCE_ REDUCTION event is generated.

Parameters controlling the buffer size are located in the mcell.conf file. For information on configuring these parameters, see “Propagation parameters” on page 288.

About mcell.dir, the cell directory file

The mcell.dir file is created during product installation. It acts as the cell directory file, contains the list of cells, the BMC Impact Portal, Impact Administration Servers, and gateways known on a specific computer. Upon startup, the cell reads the mcell.dir file and associates itself with the appropriate name, encryption key (if encryption is enabled), address information, and port number. In addition, it reads this information for the other cells to which it connects and for the BMC Impact Portal.

The mcell.dir file for a cell has an entry for each cell and the BMC Impact Portal to which the cell connect. Figure 3 shows the format of an entry. Figure 3 on page 34 shows an example mcell.dir entry.

Figure 3 Format of an entry in the mcell.dir file

#

## One line per component :

# <Type> <Name> <EncryptionKey> <IpAddress/Port> # <Type> = cell | gateway.type

#

# cell ComponentName EncryptionKey Host/1828

# gateway.portal bip.fullyqualifiedHostName EncryptionKey Host/3783

(31)

About mcell.dir, the cell directory file

Each parameter in the file is defined as follows:

Example of the mcell.dir file

Figure 4 shows an example of the mcell.dir file with typical component entries.

Conventions for mcell.dir file entries

The following conventions apply when creating entries for the mcell.dir file:

■ Cells may be grouped into separate cell files readable only by certain users or

groups (domains).

Attribute Description

Type type of component. It can be

■ _{cell— BMC Impact Manager cell name} ■ _gateway_{.type—Gateway of type type}

■ _{gateway.jServer}_{- predefined jServer gateway type} ■ _{gateway.portal}_{- BMC Impact Portal}

■ _admin_{- named Impact Administration Server (IAS)}

Name Name is an abstract name for the component. Component names are not case-sensitive and

may be any alphanumeric string, including underscores (_).

A Portal name is, by convention, the fully qualified host name of the Portal host, prefixed with bip.

EncryptionKey String to be used as part of the key for the encryption of the communication between a cell and the component. Default value is 0 (zero).

Note: If the string has an odd number of characters, the last character is ignored.

For an IAS component, the string must have the form UserID/Password, or be 0. If the value is non-zero, the indicated UserId and Password are used as IAS login credentials.

IPAddress/Port Host name or IP address and port number on which the component is listening. Default port number for a cell is 1828 and for a Portal is 3783.

Figure 4 Example of the mcell.dir file and its entries

#

## One line per component :

# <Type> <Name> <EncryptionKey> <IpAddress/Port> # <Type> = cell | gateway.type

#

cell bos-71 mc bos-71/1828

cell local mc 127.0.0.1/1828

gateway.portal bip.bos-71.amc.com mc bos-71/3783 admin ias1 Mac/FreeAI1 bos-71/3084

(32)

Configuring passive connections

■ A cell must be configured to communicate with, at a minimum, the cells to which it

propagates events. A cell does not need to be configured to communicate with the cell from which it receives events, even for backward propagation.

■ The _mcell.dir file may define any number of entries, but each entry must be on a

separate line.

■ You can place _mcell.dir files on remote mountable partitions or distribute them

using rdist, tftp, or any other distribution mechanism.

Configuring passive connections

If inbound connections to the cell are disallowed in a protected environment, the connection has to be established within the protected zone to allow a connection between an external client and a cell in the protected zone. To connect to the cell, the client issues a passive connection; that is, it waits until the cell establishes the

connection to the client.

Configuring the client for passive connections

On the client side, the mcell.dir file has to indicate that the destination cell is located in an isolated protected zone.

To configure the client for passive connections

1

Open the mcell.dir file in a text editor.

2

For the destination cell, replace Host:Port with 0 as shown in Figure 5.

3

Save the changes.

4

Either reload the cell configuration or stop and start the cell.

NOTE

A passive connection is only possible with the “server” type clients, such as the cell and gateway clients.

Figure 5 Passive connection format

(33)

Configuring slots for time stamping

When a cell or gateway client needs to connect to an isolated destination cell, it cannot establish a connection because it does not have the IP address and port number of the cell. Instead, the cell or gateway client registers the destination and waits for a connection from it.

Configuring a cell for passive connections

On the cell side, an indication is needed that a client could be waiting on a connection.

To configure a cell for passive connections

To configure a cell for passive connection, you must create a data object and specify how to control it, as shown in Figure 6.

The cell slot, as defined in the MC_CELL_HEARTBEAT superclass, gives the name of the passive client. The enable slot in the superclass specifies whether or not monitoring and reconnection is enabled. The cell attempts to connect to passive client targets as configured with the standard connection parameters. As soon as a connection is established, the connection is reversed. At that moment, the client takes up the connection and behaves as an ordinary client.

Monitoring passive targets

The cell may not be aware that a connection has been terminated when a connection from a passive client to a cell is terminated. The passive client cannot try to

reestablish the connection, nor can it signal the cell to reestablish the connection. To avoid such situations, the cell monitors the passive client, based on the standard heartbeat monitor mechanism. Then, when a disconnect is detected, the cell attempts to connect to the passive client target.

Configuring slots for time stamping

Each event has an mc_modification_date slot that contains the time stamp of the last modification of the event. Only select slot modifications set this time stamp.To add a time stamp to a slot so that the date and time is recorded when the slot is changed, you must configure the mcell.modify file. The mcell.modify file contains the names of the slots that affect the mc_modification_date slot. When one of the slots Figure 6 Data object specification

(34)

Configuring encryption

To configure slots for time stamping

1

Open the mcell.modify file in a text editor.

2

Create a line entry containing the name of the slot whose modification is to be time stamped. Figure 7 shows an example of the mcell.modify file.

When CLASS is used as a slot name, all class-specific slots or slots not defined in the base class CORE_EVENT update the mc_modification_date slot with a time stamp.

3

Save the changes.

4

Either reload the cell configuration or stop and start the cell.

Configuring encryption

You can encrypt communication among the various BMC Impact Solutions components. To enable encryption, make the appropriate settings in the following locations:

■ the cell’s configuration file mcell.conf ■ the CLI configuration file _mclient.conf

■ the BMC Impact Administration server used by BMC Impact Explorer ■ the cell directory file, which is MCELL_HOME\etc\mcell.dir by default

Figure 7 mcell.modify file

# Configuration of slots affecting mc_modification_date when modified # Format :

# SlotName

# Special name : CLASS : specifies all class-specific slots status

(35)

mcell.conf file settings that control encryption

The primary settings controlling encryption are in the cell configuration file

mcell.conf. The following settings control encryption:

■ Encryption ■ ForceEncryption ■ EncryptionKey

If Encryption is set to Yes, encrypted communication to and from the cell is enabled, but not required. For example, if a BMC Impact Explorer does not have encryption enabled, then the communication with that particular BMC Impact Explorer console is not encrypted.

ForceEncryption requires encryption for all communications. If the BMC Impact Explorer attempts an unencrypted connection to the cell, the connection is rejected.

The encryption process uses the EncryptionKey value as part of the encoding key. If there is no encryption, the EncryptionKey_{value has no effect.}

mclient.conf file settings that control encryption

All CLIs can use an mclient.conf file to determine encryption functionality. The parameters are

■ Encryption ■ EncryptionKey

For more information about the CLI configuration parameters, see “BMC Impact Manager CLI configuration” on page 269.

mcell.dir file settings that control encryption

The mcell.dir file contains a field for an EncryptionKey. At installation, the default

EncryptionKey value is set to mc. BMC Software recommends that you modify the value for security.

The string specified as the encryption key is transformed to a binary value as follows:

■ Characters of the encryption key are grouped in pairs. If the string has an odd

number of characters, the last character is ignored.

(36)

■ A character in the hexadecimal range (_0-9, _A-F, _a-f) is converted to the

corresponding hexadecimal value (for example, 8 gives the value 8, B gives the value 11).

■ Any other character is converted to its ASCII code modulo ₁₆.

Encryption behavior between cells and components

This section describes the encryption behavior of cells and components during communication. The following actions occur when a BMC Impact Solutions component initiates communication with a cell:

1. The component scans the cell configuration file, mcell.dir, for that cell’s connection information.

2. BMC Impact Explorer retrieves the cell’s connection information from the BMC Impact Administration server.

3. The component opens a connection to the cell.

If the cell has Encryption=yes, the component can use encrypted or non-encrypted communication. The component must use encrypted communication if the cell has

ForceEncryption=yes and Encryption=yes.

If the communication is encrypted, both the cell and the component must use the same EncryptionKey values to establish communication.

Information retrieval

A component must have the address and port of a cell to establish communications with it. To establish encrypted communications, the component must also have the encryption key of the cell. BMC Impact Explorer and the CLI commands determine the information in different ways:

■ BMC Impact Explorer acquires the information from the BMC Impact

Administration server (cell_info.list).

■ BMC Impact CLI commands obtain the information by determining the server

location using one of the following methods:

— directly from the CLI command

— from CLI configuration parameters in mclient.conf

(37)

Default values

The default value for cellName is the name of the host (hostName). The default value for the port is 1828_.

When the mcell.dir file is present, the default value is EncryptionKey=mc at installation. BMC Software recommends that you modify this value for security.

If the mcell.dir file is absent on the host and you do not specify an encryption key, the CLI command uses 0 (zero) as the default value for EncryptionKey. This value

enables encrypted communications.

Mandatory key specification conditions

You must specify the encryption key if the following conditions apply:

■ you execute the CLI command on a host without an _mcell.dir file ■ the cell has an encryption key other than 0 (zero)

These conditions apply with the default installation. However, if the mcell.dir file is present on the host, and the file specifies the encryption key, you are only required to specify the cellName_.

Limiting cell access

A client is allowed to connect to the cell if its IP address matches the general

AllowConnectionFrom as well as the client type-specific Allow*From.

Figure 8 shows an example of masking syntax.

NOTE

You can disable encryption by setting the configuration parameter to Encryption=No. You might want to use this setting to disable encryption while tracing.

Figure 8 Masking syntax

AddrMaskList = AddrMask {':' AddrMask} AddrMask = Addr ['/' Mask]

Addr = Nr '.' [Nr '.' [Nr '.' [Nr]]] Mask = Addr | Nr

(38)

The following conventions apply:

■ An abbreviated Addr or Mask is expanded with zeros.

■ A numeric Mask (number without trailing dot) gives the number of 1 bit. ■ An omitted Mask defaults to all bits set to 1.

■ A connection is allowed if the source address ANDed with the Mask matches Addr

ANDed with the Mask.

When the Mask is all zeros, any address matches regardless of the value of Addr. For all Mask bits whose value is one (1), the equivalent bits in Addr must match the equivalent bits in the source address.

Table 5 lists the IP address parameters.

The default is 0./0, indicating that the server should accept connections from any source. Usually this is useful only for testing or debugging, or for use with a system that is isolated from the network.

To specify one single address, specify the address without a mask, or use a 32-bit mask. The following examples are equivalent ways of specifying a single address:

■ 127.0.0.1 ■ 127.0.0.1/32

■ 127.0.0.1/255.255.255.255

Table 5 IP Address parameters

Parameter Description

AllowConnectionFrom=0./0 all systems allowed

(same as 0.0.0.0/0) AllowConnectionFrom=0./32 no system allowed

(00.00.00.00 is not a valid IP address) AllowConnectionFrom=198.12./255.255. any system from the 198.12.xx.xx

network can connect

AllowConnectionFrom=127.0.0.1/1 allows any host with an IP address lower than

128.0.0.0, because it indicates there is only 1 bit in the mask

Only the highest-order bit is considered and must be the same as 127, which is a 0 bit.

AllowConnectionFrom=198.12.33./ 255.255.255.:198.12.92./255.255.255.

(39)

Reloading cell configuration

When you specify more than one address per mask pair, a system that matches at least one of the pairs can accept a connection.

Connection attempt using invalid encryption key

An attempt to connect to a cell using an invalid encryption key or from an disallowed address generates an internal event MC_CELL_UNALLOWED_CONNECT. This event contains a slot, reason, that includes the reason for the refused connection.

Reloading cell configuration

The cell does not automatically reconfigure itself, but you can customize and reload the configuration after you have made configuration changes without restarting the cell.

To reload cell configuration

To trigger the reconfiguration, perform one of the following actions:

■ Send a hang-up signal on UNIX.

■ Run the mcontrol command on UNIX or Windows. For information about the

mcontrol command, see “mcontrol—Performing cell control operations” on page 228.

Table 6 lists the specific instances in which the reconfigure feature can be used and the effect that results from its use.

Table 6 Files for cell reconfiguration (part 1 of 2)

Type Name/Directory Result of reconfiguration

cell directory mcell.dira This internal directory is replaced with new contents from the

mcell.dir file. Associated data objects are replaced as well. Connected clients and destinations remain connected, even if the corresponding directory entries are modified.

cell tracing mcell.tracea Tracing is adapted and has the same effect as through the mcfgtrace CLI.

cell

configuration

mcell.conf The cell restarts automatically.

mcell.propagate mcell.modify

(40)

Managing high availability cell servers

If you have installed and configured primary and secondary cell servers as described in the BMC Impact Solutions Installation Guide and the BMC Impact Solutions Getting

Started Guide, you may need some of the following advanced procedures to manage

your high availability environment.

The highest possible availability for a cell occurs when two server machines are close to each other with a highly reliable network connection. When the two server

machines are on remote sites, the high availability cell functions more like a Disaster Recovery system.

Only one of the two servers should be active at any time.

KB program kb\classes The cell restarts automatically.

\kb\rules \kb\lib \kb\bin

KB data kb\data The cell restarts automatically.

\kb\records

a _{For mcell.dir and mcell.trace, a hang-up signal on a UNIX platform performs maximum reconfiguration}

without a cell restart. For information about restarting a cell, see “Interpreting cell execution failure codes” on page 56.”

WARNING

The primary and secondary servers of a high availability pair must run on two different logical OS images of the same type. Primary and secondary servers of a high availability pair running on the same system or running on different operating systems is not supported.

WARNING

It is highly recommended that you disable automatic failover and enable manual failover when the connection between the primary and secondary server is unreliable. Otherwise, there is a risk that both primary and secondary servers would be active at the same time when they cannot communicate with each other, due to network problems.

Although it is technically possible to activate both servers, this is not supported. If both servers are activated, incompatible server states can occur. If the server states are

incompatible, manual intervention is required to re-synchronize the primary and secondary servers. If this situation occurs, see “Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are unsynchronized.” on page 63.

Table 6 Files for cell reconfiguration (part 2of 2)

(41)

Automatic failover process

If a high availability cell is configured with CellDuplicateAutoFailOver=Yes, it will automatically perform a failover when needed.

Failover occurs when the secondary server loses its connection with the primary. If it cannot connect to the primary server within the time period specified in the

CellDuplicateFailOverTimeOut parameter, the secondary server assumes that the primary server is no longer available and becomes active.

The CellDuplicateFailOverStartTimeOut parameter specifies the period after startup after which the secondary server will become active when it has no connection with the primary server. This parameter should be set high enough to allow primary and secondary servers to be started at more or less the same time.

Although you can start the secondary server before the primary server, if the secondary server is started first, it cannot connect to the primary server. Therefore, the value of the CellDuplicateFailOverStartTimeOut parameter should be set so that there is enough time for the primary server to start.

Automatic switchback process

If a high availability cell is configured with CellDuplicateAutoSwitchBack=Yes, it automatically performs a switchback when the primary server starts.

When the primary server is started, it connects to the secondary server and

determines its activity level. If the secondary is active, the switchback procedure is started. The secondary server switches to standby mode and transmits its state to the primary server. Once the primary server has determined that the secondary server is in standby mode, the primary server restarts itself and reloads the state that it received from the secondary server.

BMC Impact Solutions Infrastructure Management Guide