IBM Netcool/Impact 6.1 · 2013-07-11 · IBM Netcool/Impact 6.1.1 Quick Start Guide The Netcool/Impact Quick Start Guide helps you get started with a base configuration of Netcool/Impact

IBM Netcool/Impact 6.1.1

Best Practices

Licensed Materials – Property of IBM

Note: Before using this information and the product it supports, read the information in “Notices” located at the end of this document.

© Copyright IBM Corporation 2012, 2013.

US Government Users Restricted Rights–Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.


IBM Netcool/Impact 6.1.1 Best Practices Contents © Copyright IBM Corporation 2012, 2013.

iii

Contents

About this publication ........................................................................................................................ v

Intended audience .......................................................................................................................................... v What this publication contains...................................................................................................................... v Publications .................................................................................................................................................... vi

Your Netcool/Impact Best Practices library .................................................................................... vi Prerequisite publications ................................................................................................................... vii

Conventions used in this publication ........................................................................................................ viii Typeface conventions ........................................................................................................................ viii Operating system-dependent variables and paths ........................................................................ viii

Chapter 1 Introduction ........................................................................................................................ 1

Chapter 2 Planning .............................................................................................................................. 2

Where to implement custom functionality .................................................................................................. 2 Requirements gathering ................................................................................................................................. 4 Solution design based on requirements ....................................................................................................... 6

A starting point ..................................................................................................................................... 6 List of custom functionality required from Netcool/Impact .......................................................... 7 List of all components Netcool/Impact will interact with .............................................................. 8 List of all event sources ........................................................................................................................ 8 List of all Data Source Adaptors (DSAs) required and rates of access .......................................... 8 List of all Data Types (DTs) required ................................................................................................. 9 List of all Services required ............................................................................................................... 10 List of event processing functions .................................................................................................... 10 List of geographic sites ....................................................................................................................... 11 Estimate of peak event processing rate per site .............................................................................. 11 Estimate of number of concurrent users .......................................................................................... 12 Detailed specification of the Operator Views required ................................................................. 12 Exception handling specification ...................................................................................................... 13

Architectural considerations ....................................................................................................................... 14 Security and network restrictions ..................................................................................................... 15 Resiliency ............................................................................................................................................. 15 Create a diagram ................................................................................................................................. 16 Ports used by Impact .......................................................................................................................... 16

Hardware considerations ............................................................................................................................ 16 Hardware resiliency ........................................................................................................................... 16 CPU, memory and disk space resourcing........................................................................................ 17 Setting the memory for the Java Virtual Machine on the Impact profile .................................... 18 Setting Java Virtual Machine memory for TIPProfile .................................................................... 18 Network resourcing ............................................................................................................................ 18

Other installation prerequisites .................................................................................................................. 18 Solution delivery ........................................................................................................................................... 19

Custom configuration ........................................................................................................................ 19 Documentation .................................................................................................................................... 20

Use of debug mode ....................................................................................................................................... 22 Stress testing prior to deployment into production ................................................................................. 22 Removal of temporary files ......................................................................................................................... 22

Chapter 3 Installation ........................................................................................................................ 24

IBM Prerequisite Scanner............................................................................................................................. 24 Backing up the Deployment Engine (DE) .................................................................................................. 24 Back up before applying fix packs and interim fixes ............................................................................... 24 Setting maximum memory limits within Impact ..................................................................................... 25 Installing in a shared environment ............................................................................................................. 25

Chapter 4 Clustering .......................................................................................................................... 26

Make all components resilient .................................................................................................................... 26 High Availability within Impact ................................................................................................................. 27


IBM Netcool/Impact 6.1.1 Best Practices Contents © Copyright IBM Corporation 2012, 2013.

iv

Cluster operation ................................................................................................................................ 27 How many clusters should I deploy?......................................................................................................... 29

Split brain scenario ............................................................................................................................. 29 Geographically distributed scenario ................................................................................................ 31

Name Server configuration ......................................................................................................................... 32

Chapter 5 Data Sources and Data Types ........................................................................................ 33

Provide backup options for Data Sources ................................................................................................. 33 Use of the internal Derby Apache database .............................................................................................. 33

Chapter 6 Policies ............................................................................................................................... 35

Formatting and use of comments ............................................................................................................... 35 Formatting, use of white space and indentation............................................................................. 36 Use of comments ................................................................................................................................. 37

Defining sensible policy loops .................................................................................................................... 37 Using Impact hibernations .......................................................................................................................... 38 Embedding log statements into policies .................................................................................................... 38 Capturing errors within policy execution ................................................................................................. 40 Event Isolation and Correlation .................................................................................................................. 40

Chapter 7 Services .............................................................................................................................. 41

Event Processor Service ............................................................................................................................... 41 Configuring the number of threads .................................................................................................. 41 Maximising the processing throughput ........................................................................................... 42 Retaining the tuning configuration on restart ................................................................................. 43 Managing the Connection Pool for SQL datasources .................................................................... 43

Event Reader service .................................................................................................................................... 43 Use the default polling interval ........................................................................................................ 44 Configure Event Reader to automatically start ............................................................................... 44 Optimising queries to OMNIbus ...................................................................................................... 44 Stop testing after first match ............................................................................................................. 44 Limit reprocessing of events.............................................................................................................. 44 Order of events read ........................................................................................................................... 45 Caching data ........................................................................................................................................ 45

Policy Activator Service ............................................................................................................................... 45 Care when setting the Activation Interval ....................................................................................... 45

Policy Logger Service ................................................................................................................................... 45 Enabling multiple policy log files ..................................................................................................... 45 Adjusting the log level ....................................................................................................................... 46 Care when inserting log statements ................................................................................................. 46

Chapter 8 Operator Views ................................................................................................................ 48

TIP based Operator View versus JazzSM .................................................................................................. 48

Chapter 9 Final steps and considerations ...................................................................................... 49

Machine start-up ........................................................................................................................................... 49 UNIX ................................................................................................................................................ 49 Windows .............................................................................................................................................. 50

Transferring content between Impact systems ......................................................................................... 50 Using projects to organise custom content ...................................................................................... 50

Self monitoring .............................................................................................................................................. 51 Performance tuning ...................................................................................................................................... 52

Further reading ................................................................................................................................... 53

Appendix A. Initial requirements gathering checklist ............................................................ 54

Notices .................................................................................................................................................. 68

Trademarks .................................................................................................................................................... 70


IBM Netcool/Impact 6.1.1 Best Practices About this publication © Copyright IBM Corporation 2012, 2013.

v

About this publication

The purpose of this document is to be a reference to anyone deploying Netcool/Impact version 6.1.1 either on its own or as part of a greater Netcool solution ― and to assist in the implementation of a solution using best practice techniques. If deployments are done in a standard way, engineers that have to work on an installation done by somebody else will more easily understand what has been configured and how.

This document details recommended best practices for when installing and configuring Netcool/Impact 6.1.1. It is not designed to replace official product documentation ― instead it augments the official product documentation and provides universally practiced standard methods and practices for deployment and configuration.

Installations are always dependent on customer requirements. With that said, the best practices contained in this document should always be adhered to whenever possible.

Note that this document is not intended as a training manual. It is a prerequisite that anyone making use of this document has completed appropriate Netcool/Impact 6.1.1 training.

Intended audience

This publication is intended as essential reading for all technical staff that are responsible for:

Developing Netcool/Impact 6.1.1 solutions;

Installing and administering Netcool/Impact 6.1.1;

Supporting Netcool/Impact 6.1.1.

It is assumed that the reader has a working knowledge of Netcool/Impact and understands the meaning of the Netcool/Impact terms and component names referred to in this document.

Further information about Netcool/Impact 6.1.1 can be obtained from the official product documentation available from the following location:

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.netcoolimpact.doc6.1.1/welcome.html

What this publication contains

This publication contains the following sections:

Chapter 1 Introduction on page 1:

This chapter provides a brief introduction for this guide including an outline of the origins of the information contained herein as well as identifying the target audience for this guide.

Chapter 2 Planning on page 2:

This chapter provides detailed information regarding the planning phase of a Netcool/Impact deployment including where to implement custom functionality, requirements gathering, solution design guidelines, architectural considerations, component and hardware sizing advice, solution delivery, the use of debug mode, debugging techniques, a note on stress testing and a note on the need to remove temporary files and folders from deployed systems.

Chapter 3 Installation on page 24:



vi

This chapter introduces the IBM Prerequisite Scanner, highlights the importance of backing up the IBM Deployment Engine prior to installation as well as the Netcool/Impact installation prior to the application of a fix pack or interim fix, provides guidance as to maximum memory configuration, and considerations around installing in a shared TIP environment.

Chapter 4 Clustering on page 26:

This chapter covers best practices around the configuration of Netcool/Impact clusters including clustering for both the Impact servers as well as the Impact Name Servers. Other topics include: the importance of ensuring all components are installed in a resilient manner; a description of high availability within Netcool/Impact and how it works; and guidance around how many clusters should be deployed.

Chapter 5 Data Sources and Data Types on page 33:

This chapter contains best practices principles in relation to the configuration and use of Netcool/Impact Data Sources. Topics include: the importance of ensuring resiliency for datasources; and the use of the internal Derby Apache database.

Chapter 6 Policies on page 35:

This chapter covers best practices in relation to policy authorship. Topics include: formatting and use of comments; usage of looping constructs within policies; use of Impact hibernations; guidance around the embedding of log statements within policies; capturing errors within policy execution; and an overview of Event Isolation and Correlation (EIC).

Chapter 7 Services on page 41:

This chapter contains best practices principles in relation to the configuration and use of Netcool/Impact Services. Topics include: the Event Processor service; the Event Reader service; the Policy Activator service; and the Policy Logger service.

Chapter 8 Operator Views on page 48:

This chapter contains best practices principles in relation to the configuration and use of Netcool/Impact Operator Views and covers when to use Operator Views versus the new JazzSM dashboards.

Chapter 9 Final steps and considerations on page 49:

This chapter provides guidance on final steps and considerations with respect to a Netcool/Impact deployment. Topics include: the configuration of Netcool/Impact to automatically start when the machine it is installed on boots up; recommendations on best practice methods for transferring content between Netcool/Impact systems; the importance of Netcool/Impact self monitoring.

Publications

This section lists publications in the Netcool/Impact library and related documents.

Your Netcool/Impact Best Practices library

The following best practice document is available in the Netcool/Impact Best Practices library:

Netcool/Impact 6.1.1 Best Practices Guide

This is the primary best practices Netcool/Impact document and includes information on all aspects of Netcool/Impact best practices.



vii

The publication listed above can be accessed online via the following URL:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Netcool%20Impact/page/Best%20Practices

Prerequisite publications

To use the information in this publication effectively, you must have some prerequisite knowledge, which you can obtain from the following publications.

IBM Netcool/Impact 6.1.1 Quick Start Guide

The Netcool/Impact Quick Start Guide helps you get started with a base configuration of Netcool/Impact.

IBM Netcool/Impact 6.1.1 Release Notes

The Netcool/Impact Release Notes contains a description of requirements and getting started issues are addressed in this document.

IBM Netcool/Impact 6.1.1 Administration Guide

The Netcool/Impact Administration Guide contains instructions on installing, configuring, running, and monitoring Netcool/Impact.

IBM Netcool/Impact 6.1.1 DSA Reference Guide

The Netcool/Impact DSA Reference Guide contains information about Netcool/Impact Data Source Adapters (DSAs).

IBM Netcool/Impact 6.1.1 Operator View Guide

The Netcool/Impact Operator View Guide contains instructions about creating Operator Views.

IBM Netcool/Impact 6.1.1 Policy Reference Guide

The Netcool/Impact Policy Reference Guide contains descriptions and complete syntax references for the Impact Policy Language (IPL) and JavaScript.

IBM Netcool/Impact 6.1.1 Solutions Guide

The Netcool/Impact contains end-to-end information about using features in Netcool/Impact.

IBM Netcool/Impact 6.1.1 User Interface Guide

The Netcool/Impact User Interface Guide contains information about the user interface in Netcool/Impact.

IBM Netcool/Impact 6.1.1 Integrations Guide

The Netcool/Impact Integrations Guide contains instructions on integrating Netcool/Impact with other IBM software and other third-party software.

IBM Netcool/Impact 6.1.1 Troubleshooting Guide

The Netcool/Impact Troubleshooting Guide provides information about troubleshooting the installation, customization, starting, and maintaining Netcool/Impact.

All the publications listed above can be accessed online via the following URL:

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.netcoolimpact.doc6.1.1/impact_pdflibrary_ic.html







viii

Conventions used in this publication

This publication uses several conventions for special terms and actions and operating system-dependent commands and paths.

Typeface conventions

This publication uses the following typeface conventions:

Bold

Lowercase commands and mixed case commands that are otherwise difficult to distinguish from surrounding text

Interface controls (check boxes, push buttons, radio buttons, spin buttons, fields, folders, icons, list boxes, items inside list boxes, multicolumn lists, containers, menu choices, menu names, tabs, property sheets), labels (such as Tip: and Operating

system considerations:)

Keywords and parameters in text

Italic

Citations (examples: titles of publications, diskettes, and CDs)

Words defined in text (example: a nonswitched line is called a point-to-point line)

Emphasis of words and letters (words as words example: "Use the word that to introduce a restrictive clause."; letters as letters example: "The LUN address must start with the letter L.")

New terms in text (except in a definition list): a view is a frame in a workspace that contains data

Variables and values you must provide: ... where myname represents....

Monospace

Examples and code examples

File names, programming keywords, and other elements that are difficult to distinguish from surrounding text

Message text and prompts addressed to the user

Text that the user must type

Values for arguments or command options

Operating system-dependent variables and paths

This publication uses the UNIX convention for specifying environment variables and for directory notation.

When using the Windows command line, replace $variable with %variable% for environment variables, and replace each forward slash (/) with a backslash (\) in directory paths. For example, on UNIX systems, the $NCHOME environment variable specifies the directory where the Netcool/Impact core components are installed. On Windows systems, the same environment variable is %NCHOME%. The names of environment variables are not always the same in the Windows and UNIX environments. For example, %TEMP% in Windows environments is equivalent to $TMPDIR in UNIX environments.

If you are using the bash shell on a Windows system, you can use the UNIX conventions.


IBM Netcool/Impact 6.1.1 Best Practices Chapter 1: Introduction © Copyright IBM Corporation 2012, 2013.

Page 1 of 71

Chapter 1 Introduction

This document details the best practices that should be employed when deploying Netcool/Impact 6.1.1. This document is designed to help an engineer quickly and efficiently install a working system and ensure that if another engineer subsequently has to work on a deployment installed by someone else, they will easily understand what has been configured and how.

Many of the best practice concepts covered in this document trace their origins to the Netcool Certified Consultant programme. This document includes the relevant concepts from the product’s roots and introduces new ones based on the new technologies and product features in the latest releases of Netcool/Impact.

This document is intended to be read by anyone preparing to deploy or work with Netcool/Impact version 6.1.1.


IBM Netcool/Impact 6.1.1 Best Practices Chapter 2: Planning © Copyright IBM Corporation 2012, 2013.

Page 2 of 71

Chapter 2 Planning

Netcool/Impact is usually deployed along with other Netcool products as a part of a bigger solution to meet the business requirements. Requirements are often best implemented by using a combination of products within the solution ― for example: a requirement may be partly implemented by a Netcool/OMNIbus Probe rules file, a Netcool/OMNIbus ObjectServer trigger and a Netcool/Impact policy.

The requirements gathering process therefore is a key first step in architecting any Netcool solution. Careful planning must be undertaken to ensure all necessary factors have been considered before provisioning both the software and hardware components as well as designing the architecture layout.

Once the requirements gathering exercise for the overall Netcool solution has been completed, the Netcool Solution Architect will then assess the requirements and identify which Netcool product or combination of products would be the best fit for implementing each requirement. This exercise should be completed before anything else.

One of the outputs of this requirements gathering exercise will be to construct a list of all custom functionality that will be performed by Netcool/Impact. This list of custom functionality is just one of many items that will need to be defined as part of the Netcool/Impact requirements gathering process.

This chapter provides guidance on how to go about the requirements gathering process with respect to Netcool/Impact and also other points to consider when planning a Netcool/Impact deployment.

Where to implement custom functionality

As previously mentioned, one of the tasks of a Netcool Solution Architect is to assess the overall requirements of a Netcool solution and identify how best to implement each one.

For example, would a Netcool/OMNIbus ObjectServer trigger be the best place to implement "requirement X"? Or would it be more appropriate to implement the requirement within Netcool/OMNIbus Probe rules files or a Netcool/Impact policy ― or a combination?

Before the requirements for Netcool/Impact can be established, the overall Netcool solution requirements must first be assessed and a determination made as how best to implement each one. This section provides some guidance of what sorts of tasks are best implemented by the most common Netcool product components.

The following table provides an overview of the strengths of each Netcool component type and the sorts of tasks that would be appropriate for each.



Page 3 of 71

Implementation point Notes

Netcool/OMNIbus Probe rules file

The Probe rules file is where the incoming token stream is parsed and assigned to Netcool/OMNIbus ObjectServer fields prior to being sent to the ObjectServer and potentially being processed by Netcool/Impact or any other components.

It is a best practice to implement as much functionality as possible at the Probe rules file level rather than leaving it up to other components such as Netcool/OMNIbus ObjectServer triggers and Netcool/Impact policies to deal with.

This practice helps to spread the processing load down to the end points and means there is less data processing required at the points where the events converge ― ie: within the ObjectServers. Minimising processing load at the event convergence points ensures that the system is better able to handle peak event flows ―for example: during an event storm.

Lookup files are useful at the Probe level for basic event enrichment so long as the data set is fairly static. If the data in the lookup table is dynamic, it is better to store it in a database table ― for example: within an ObjectServer table or another database ― and then perform event enrichment via an ObjectServer trigger or via Netcool/Impact.

Note that creating large custom tables may cause ObjectServer performance to suffer. Custom tables and triggers, like any other custom functionality, should be thoroughly tested before being put into production.

Netcool/OMNIbus ObjectServer triggers

ObjectServer triggers are a convenient and powerful mechanism to implement custom functionality. Tasks carried out by ObjectServer triggers are typically ones that perform actions around table data stored in the ObjectServer. There are three types of ObjectServer trigger:

Database: used for implementing actions based on changes to the event data set ie: an insert of, update to or deletion of a row in an ObjectServer table;

Temporal: used for implementing actions on a regular, timed basis;

Signal: used for implementing actions based on the signal being raised. The ObjectServer comes with a number of pre-defined signals ― for example: when the ObjectServer starts up ― but custom ones can also be defined for triggering secondary actions.

Thorough testing and monitoring of ObjectServer triggers in a test environment should be done to validate their performance before deployment into a production environment.

External scripts External scripts (launched by external action procedures from within the Netcool/OMNIbus ObjectServer) are used for carrying out actions that require interaction with external systems. The nco_mail script is designed to be launched by an external action procedure to send a notification e-mail, for example. Netcool/Impact also has a policy function called JRExecAction which can be used to do likewise.

Netcool/OMNIbus also has the ability to execute external scripts on remote machines via the Netcool/OMNIbus Process Agent. Similarly, Netcool/Impact has the CommandResponse function which allows you to connect to a remote machine and interactively execute commands on that remote machine.

See the Netcool/Impact 6.1.1 Policy Reference Guide for more information on both of these Netcool/Impact functions.



Page 4 of 71

Netcool/Impact Netcool/Impact is an extremely powerful data processing engine and can be used for a great number of purposes including:

Event enrichment ― typically where the target data resides on an external data source ― for example: a DB2 database;

Any sort of data correlation or processing (event driven or on a timed basis) where the data resides on a Netcool/OMNIbus ObjectServer or any other supported SQL database;

Automation of workflow processes;

Interaction with trouble ticketing systems;

Interaction with Web Services APIs or Java Message Services (JMS);

Either functionality or interaction with a system that requires timed delays (via the Hibernation function);

Provision of complex dashboard views ― called Operator Views ― that display information from potentially multiple disparate data sources. These can be accessed directly or via other dashboards ― for example: launched from Netcool/OMNIbus WebGUI.

See the Netcool/Impact 6.1.1 DSA Reference Guide for more information on the integration capabilities of Netcool/Impact.

An overview of the core features and typical use-cases of Netcool/Impact is available here:

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.netcoolimpact.doc6.1.1/common/dita/imsg_start_netcool_impact_uses_c.html

Requirements gathering

Once the requirements gathering process for the overall Netcool solution has been done and how each requirement will be implemented has been established, the list of custom functions to be performed by Netcool/Impact should be ready.

This list of custom functions will then form one part in a secondary requirements list that contains requirements specific to Netcool/Impact. This secondary requirements list will allow an initial sizing and architecture design to be done with respect to Netcool/Impact.

This section provides a suggested base set of requirements for the Netcool/Impact requirements gathering process and explains how each one may affect the resulting architecture. This will allow a Netcool Solutions Architect to produce an initial design for Netcool/Impact and estimate reasonable initial component numbers.

Any design resulting from these initial requirements will constitute a starting point for the solution and may need to change when additional components that add load are introduced to the overall solution.

Note: Any resulting design should undergo extensive load testing prior to deployment into production. Adjustments may need to be made to the design as a result of these tests.

The initial requirements to be gathered for Netcool/Impact include the following:

A comprehensive list of custom functions that Netcool/Impact will perform. Note that this will be one of the outputs to the initial requirements gathering exercise done for the overall Netcool solution.

A list of all components that Netcool/Impact will connect to or interact with during its execution.





Page 5 of 71

A list of the event sources Netcool/Impact will interact with. Typically the primary event source will be Netcool/OMNIbus however there may be others since Netcool/Impact is capable of reading events from a wide range of data source types.

A list of the custom Data Source Adaptors (DSAs) that will be required to implement the solution.

An estimate of the maximum access rate of each Data Source (DS) in terms of reads and/or writes per second. This information in conjunction with the events-to-process rate will enable you to calculate whether or not each given Data Source will handle the load. The owner of each Data Source to be accessed ― for example: a DB2 Administrator ― should be consulted during this process in case further resource needs to be allocated to the Data Source to accommodate the load Netcool/Impact will place on it.

A list of the custom Data Types (DTs) that will be required to implement the solution including the field that will be the primary key for each one ― plus a list of the fields that will be needed within each Data Type.

A list of the custom Netcool/Impact Services that will be required to implement the solution.

Each of the Netcool/Impact custom functionality items that process event streams need to be identified from the overall list of custom functionality items and grouped into two categories:

One-time event processing functions ― for example: event enrichment;

Functions that are carried out repeatedly on events or functions that perform correlation tasks ― for example: X events in Y seconds.

The purpose of this division is two-fold: first, Event Readers are configured to either process events once only or repeatedly; second, in the case of a tiered Netcool/OMNIbus architecture, one-time processing functions can potentially be pushed down to the Collection ObjectServer layer thereby easing loading on the Aggregation layer. This concept will be discussed in more detail in a later section of this document.

How many geographic sites Impact will need to be present at ― for example: when Netcool/Impact is integrated with a geographically distributed Netcool/OMNIbus system. In such circumstances, one Netcool/Impact cluster would typically be provisioned for each geographic site to provide local resiliency and also so as to minimise WAN traffic.

An estimate of the total number of events the Netcool/Impact cluster will be expected to process from all sources per day (ie. event rate) ― including an estimate of the peak event rate. System design should always be provisioned to manage peak rates plus have a contingency factor built in case of event storms.

Note: Guidance on provisioning the number of cluster members needed and hardware provisioning are both covered in a later section.

The value for the total number of events processed by Netcool/Impact per day should also include each time an event is reprocessed ― since load is incurred on the Netcool/Impact cluster for each processed event ― regardless of whether or not it has been processed before.

This number should be calculated separately for each geographical site or Netcool/Impact cluster, where applicable. This is necessary because it is likely that the sizing requirements for each Netcool/Impact cluster will vary from one site to the next.



Page 6 of 71

An estimate of the maximum number of concurrent users of the system. Typically the Netcool/Impact GUI will only be accessed by Netcool Administrators ― however an estimate should also be made as to the number of concurrent Operator View sessions, if they are to be used within the Netcool solution.

A detailed specification of each of the Operator View dashboards that will be required. Each specification should contain the following at the very least:

A description of how the dashboard is to be accessed ― for example: via a Netcool/OMNIbus WebGUI Active Event List (AEL) right-click tool;

A mock-up sketch or otherwise of how the dashboard should look;

Specific details about what each section of the dashboard should contain including what data is presented and which Data Source the data is to be sourced from;

If there are any active components such as buttons, the specification should define what should happen when the buttons are clicked ― including what further resources are accessed and what actions are carried out, where applicable.

A description of one or more exception handling policies to be created to catch and handle any exceptions that are encountered during Netcool/Impact execution. It is acceptable to simply use the default exception handler as part of the design, of course.

Each of the requirements listed above are expanded upon in the next section.

Note: A sample checklist worksheet of the above requirements is provided in Appendix A at the end of this document and is intended to be used for this exercise.

Solution design based on requirements

This section goes into more detail on each one of the Netcool/Impact requirements documented in the previous section and explains how each one may affect the resulting Netcool/Impact solution design, where applicable. All items listed in this section should be included in the Detailed Design Document (DDD) which is one part of the overall solution documentation.

Note: See the section entitled: Documentation on page 20 for more information regarding the recommended minimum solution delivery documentation.

The listed items in this section will enable an implementation team to rapidly build the required system. Having well documented requirements will also enable the solution maintenance team to more easily maintain the solution later on.

A starting point

It is a general Netcool best practice to include resiliency in any solution. For example, rather than just installing a single standalone Netcool/Impact server, it is better to install two or more Netcool/Impact servers configured as a cluster to provide resiliency in the event of an outage of one or more cluster members.

The starting point for any Netcool/Impact installation therefore is a cluster of at least two members where the Name Servers have been properly configured as a cluster. Each of the initial two Netcool/Impact servers should also be configured to run an instance of the GUI server ― unless the GUI component of Netcool/Impact has been installed on at least two other Tivoli Integrated Portal servers. Then, depending on the load placed on the cluster by custom functionality, additional Impact servers may need to be added to the cluster ― or



Page 7 of 71

additional clusters may be needed. The need to add extra resource will become apparent during load testing.

List of custom functionality required from Netcool/Impact

The starting point for any Netcool solution deployment is a comprehensive requirements gathering exercise followed by the Netcool Solution Architect defining how each requirement would be best implemented. One of the outputs of this exercise will be a list of custom functions that Netcool/Impact will be required to do.

The Netcool Solution Architect must then take this list and define how Netcool/Impact will be used to implement each line item including:

the Data Source Adaptor(s) that will be required;

the Data Type(s) that will be required;

the Service(s) that will be employed;

pseudocode of any Netcool/Impact policies that are required.

EXAMPLE:

Widgetcom are deploying a Netcool solution that includes both Netcool/OMNIbus and Netcool/Impact.

One of the requirements of Netcool/Impact will be to check each new event that is inserted

into the Netcool/OMNIbus Collection ObjectServer and populate the Location field with

the city name where the event originated. The table nodes.locations in the DB2 inventory database contains the information required to populate the events and is indexed

by the primary key field Node.

The Netcool Solution Architect puts together the following implementation specification for this requirement:

Requirement: Populate Location field of all events with originating city name

Integration point: Collection layer Netcool/OMNIbus ObjectServers

DSA required: ObjectServer DSA – ″COL_V_1″

Data Type: ″col_status″

DSA required: DB2 DSA ― ″inventory_db″

Data Type: ″locations″

Service required: Event Reader ― ″COL_V_1_reader″

Policy: ″update_location″

Event Reader: ″COL_V_1_reader″

Event Reader filter: Location = ''

Policy pseudocode:

For each event:

Look up Node field in ″locations″ data type

Set Location field in event to City field in found record

If not found, set Location field to ″NOT FOUND″

Update ObjectServer with newly populated Location field

――

After all the requirements have been specified, it may become apparent that a number of resources can be combined. For example, if there are a number of event enrichment requirements, it is likely that these could be combined into a single policy. Hence the



Page 8 of 71

definition of this custom functionality requirements list may necessarily undergo several iterations before it is condensed and finalised.

List of all components Netcool/Impact will interact with

This item provides a summary list of all the components that Netcool/Impact will interact with. This should be relatively easy to compile once the custom functionality items have been defined.

EXAMPLE:

Continuing the previous example, the Netcool Solution Architect compiles the following list of components that Netcool/Impact will interact with:

Collection layer ObjectServer pair: COL_V_1 (COL_P_1 & COL_B_1)

Aggregation layer ObjectServer pair: AGG_V (AGG_P & AGG_B)

DB2 inventory database: ″inventory_db″

DB2 maintenance database: ″maintenance_db″

List of all event sources

This item provides a summary list of all the event sources Netcool/Impact will read events from. This list will include both ObjectServer event list sources as well as any non-ObjectServer event sources.

EXAMPLE:

Continuing the previous example, the Netcool Solution Architect compiles the following list of event sources that Netcool/Impact will process events from:

Netcool/OMNIbus Collection ObjectServer – ″COL_V_1″

Netcool/OMNIbus Aggregation ObjectServer – ″AGG_V″

List of all Data Source Adaptors (DSAs) required and rates of access

This item provides a summary list of all the Data Source Adaptors (DSAs) that Netcool/Impact will connect to in order to perform its assigned tasks. The rate of access for each Data Source is also provided. The Netcool implementation team will have to liaise with the relevant Information Manager for each of the non-Netcool Data Source Adaptors in order to ensure that the required rate of access is possible. (The rates of access to Netcool datasources will have to be considered by the Netcool solution implementation team.) Where the Data Source can not support such a rate of access, the Data Source resourcing will have to be increased.

EXAMPLE:

Continuing the previous example, the Netcool Solution Architect compiles the following list of Data Source Adaptors (DSAs) that Netcool/Impact will use to carry out its assigned tasks:

Collection ObjectServer DSA – ″COL_V_1″

hosta/4100 (primary) COL_P_1

hostb/4100 (backup) COL_B_1



Page 9 of 71

Peak read access rate: 100 events/second

Peak write access rate: 100 events/second

Aggregation ObjectServer DSA – ″AGG_V″

hostc/4100 (primary) AGG_P

hostd/4100 (backup) AGG_B


Peak write access rate: 100 events/second

Inventory DB2 DSA ― ″inventory_db″

hoste/51000 (primary)

hostf/51000 (backup)


Peak write access rate: 0 events/second (read only)

Maintenance DB2 DSA: ″maintenance_db″

hostg/51000 (primary)

hosth/51000 (backup)


Peak write access rate: 0 events/second (read only)

List of all Data Types (DTs) required

This item provides a summary list of all the Data Types (DTs) that Netcool/Impact will connect to in order to perform its assigned tasks. Note that Data Types are associated to Data Source Adaptors. Each Data Source Adaptor may have one or more Data Types associated with it.

EXAMPLE:

Continuing the previous example, the Netcool Solution Architect compiles the following list of Data Types (DTs) that Netcool/Impact will use to carry out its assigned tasks:

Data Type: ″col_status″

Source DSA: ″COL_V_1″

Table: alerts.status

Primary key: Identifier

Selected fields: Identifier, Node

Data Type: ″agg_status″

Source DSA: ″AGG_V″

Table: alerts.status

Primary key: Identifier

Selected fields: Identifier, Node

Data Type: ″locations″

Source DSA: ″inventory_db″

Table: nodes.location

Primary key: Node

Selected fields: Node, City

Data Type: ″maintenance″

Source DSA: ″maintenance_db″

Table: nodes.maintenance

Primary key: MaintenanceID

Selected fields: MaintenanceID, Node, InMaintenance,



Page 10 of 71

StartTime, EndTime

List of all Services required

This item provides a summary list of all the Services that Netcool/Impact will require in order to perform its assigned tasks.

EXAMPLE:

Continuing the previous example, the Netcool Solution Architect compiles the following list of Services that Netcool/Impact will use to carry out its assigned tasks:

Service required: Event Reader ― ″COL_V_1_reader″

Get Updated Events: No

Comment: This Event Reader is primarily for event enrichment

and is configured to run once only for each event.

Service required: Event Reader ― ″AGG_V_reader″

Get Updated Events: Yes

Comment: This Event Reader is used to suppress events that

are in maintenance. The maintenance database should

checked against each event every time the event

recurs.

List of event processing functions

This item provides a summary of all event processing functions that Netcool/Impact will perform. The purpose of tabulating such a list is so that these functions can be divided up into two main categories: functions that are performed only once per event versus functions that are carried out potentially multiple times per event. The category that each event processing function falls into will define where it is implemented within Netcool/Impact.

Note: An Event Reader can be configured to process events just once ― or multiple times each time the event is updated ― via the Get Updates check box. Dividing the processing functions into these two categories therefore is important from an implementation standpoint as it defines which Event Reader the function will be attached to.

EXAMPLE:

Continuing the previous example, the Netcool Solution Architect compiles and categorises the following list of event processing functions that that Netcool/Impact carry out:

One-time functions:

1) Event enrichment of Location field from locations database.

2) Suppression of event if it is found to be in maintenance.

Repeated/correlation:

1) Creation of synthetic event to warn operators if there are more

than 10 critical events for any one Location.



Page 11 of 71

List of geographic sites

This item provides consideration of how the design of the Netcool/Impact architecture may have to take into account of geographical factors.

EXAMPLE:

Continuing the previous example, Widgetcom has two data centres: one in Yokohama and one in Auckland with a high bandwidth network connection between the two.

In accordance with Netcool/OMNIbus Best Practice, each geography will have its own data centre with a separate Netcool/OMNIbus installation at each.

Note: See the best practice document entitled: “Netcool/OMNIbus 7.x Large scale and geographically distributed architectures - Best Practices” for more information on deploying Netcool/OMNIbus in a geographically distributed manner. This document is available from the IBM Netcool/OMNIbus wiki on the IBM Tivoli Developer Works web site: https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en#/wiki/Tivoli%20Netcool%20OMNIbus/page/Best%20Practices

Each of the two Netcool/OMNIbus installations will form a WebGUI datasource and the WebGUI dashboards will combine events from both. The event processing requirements will need to be carried out at both sites. The Netcool Solution Architect elects to deploy a separate Netcool/Impact cluster within each data centre in order to provide local resiliency and also to reduce WAN traffic.

Geographic data centre location: Yokohama, Japan

One Netcool/Impact cluster (of 2)

One Netcool/Impact Name Server cluster (of 2)

Geographic data centre location: Auckland, New Zealand

One Netcool/Impact cluster (of 2)

One Netcool/Impact Name Server cluster (of 2)

Estimate of peak event processing rate per site

This item provides an estimate of the rate of event processing expected by Netcool/Impact. This includes all event processing activities across all Netcool/Impact Services and should be calculated out separately for each cluster.

The event processing rate should be specified in terms of maximum expected peak rates. In addition to this, it is recommended to provision additional resource as a contingency.

EXAMPLE:

Continuing the previous example, the Netcool Solution Architect notes down the estimated maximum peak event processing rate required from each Netcool/Impact cluster at each of the data centres:

Cluster: YOK (Yokohama, Japan)

Peak one-time event processing: 200 events/sec

Peak repeat/correlation event processing: 600 events/sec

Total peak event processing rate: 800 events/sec

Total plus contingency (25%): 1,000 events/sec

https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en#/wiki/Tivoli%20Netcool%20OMNIbus/page/Best%20Practices

https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en#/wiki/Tivoli%20Netcool%20OMNIbus/page/Best%20Practices



Page 12 of 71

Cluster: AKL (Auckland, New Zealand)

Peak one-time event processing: 100 events/sec

Peak repeat/correlation event processing: 500 events/sec

Total peak event processing rate: 600 events/sec

Total plus contingency (25%): 750 events/sec

Estimate of number of concurrent users

This item provides for a list to be compiled of the Netcool/Impact administrative users and also the maximum number of concurrent Operator View users.

Note that this estimate should be noted down separately for each cluster. These numbers are primarily being captured for completeness of documentation. Typically the maximum concurrent Operator View users will be equivalent to the maximum number of concurrent Netcool/OMNIbus users.

EXAMPLE:

Continuing the previous example, the Netcool Solution Architect makes a list of the Administrative users for the Netcool/Impact clusters as well as the estimated maximum number of concurrent Operator View users for each:

Cluster: YOK (Yokohama, Japan)

Administrative users: 2

Name: Fumio Yoshimura (fyoshimura)

Name: Kaito Yokozeki (kyokozeki)

Maximum concurrent Operator View users: 25

Cluster: AKL (Auckland, New Zealand)

Administrative users: 2

Name: Jonah Lomu (jlomu)

Name: Hemi Hohepa (hhohepa)

Maximum concurrent Operator View users: 10

Detailed specification of the Operator Views required

This item provides for an initial outline of what Operator Views will be required in order to meet the business requirements. The Detailed Design Document discussed later in this chapter will go into a lot more detail regarding each one however this initial outline will provide a useful input into the detailed design process.

Views can be created within the Netcool/Impact Operator View framework or the new Dash framework. If just data visualisation is needed, Dash could be considered as an implementation option. If complex features such as inputs and buttons are required however, then Operator Views should be used. In any case, this section can be used to record how the view should look.

EXAMPLE:

Widgetcom have a requirement for an operator to be able to view the full details of the engineer that will be assigned to any fault from the Netcool/OMNIbus WebGUI Active

Event List (AEL). This information is readily available in the nodes.engineers table in the “maintenance” database.



Page 13 of 71

Since this information will not often be required by an operator, the Netcool Solution Architect decides against simply importing all the details into the event via a Netcool/Impact event enrichment policy and adding the additional ObjectServer fields that would be required to do so. The Netcool Solution Architect instead elects to provide this information to the operator via a Netcool/Impact Operator View.

The Operator View dashboard will be launched via a Netcool/OMNIbus WebGUI Active Event List (AEL) right click tool. The Operator View dashboard should contain full details of the engineer that will be assigned. The engineer details will be based on the value of the

Location field within the event.

The Netcool Solution Architect completes the following Netcool/Impact Operator View worksheet.

Exception handling specification

This item provides for an initial outline of how events will be handled in the event of policy execution exceptions, should they occur. A policy exception may occur when an unexpected outcome happens during Netcool/Impact server operation. This might be during policy execution, for example: a database not being available during the course of a lookup.



Page 14 of 71

There are two main types of exception to be considered: Java exceptions and custom exceptions. Java exceptions occur internally within the Netcool/Impact server when there is any sort of failure during the course of operation. Custom exceptions can be defined and

raised within the body of a policy via the Raise function keyword.

Note: Custom exceptions are analogous to Netcool/OMNIbus ObjectServer signals and signal triggers. For more information on signals and signal triggers, see the section entitled “Signals and signal triggers” in the Netcool/OMNIbus Best Practices Guide. Also see the section entitled “Creating and editing signal triggers” in the Netcool/OMNIbus Administration Guide.

Netcool/Impact is a Java based application and so generates exceptions if unexpected events occur during normal operation. Java exceptions are hierarchical in nature and, when viewed in the main Netcool/Impact log file, will list the full hierarchy of the specific exception right back to the root level. Policy code can therefore be written to “catch” exceptions at the correct level to carry out specific operations should they occur.

Note: Care should be taken when creating exception handlers based on Java exceptions that they are at a specific enough level so as not to fire unintentionally.

Additionally, custom exceptions can be engineered to fire under certain circumstances.

Note: See the section entitled Exceptions in the Netcool/Impact 6.1 Policy Reference Guide for more information and examples of custom exception handling.

EXAMPLE:

The Netcool/Impact solution includes interactions with two DB2 databases. Should either of the databases not be available for whatever reason when Netcool/Impact tries to access them, this will result in a failure.

If this should occur, Widgetcom have a requirement that execution should halt, a synthetic event generated within the ObjectServer to alert the Netcool Administrators and a log file entry written to the policy log file.

The Netcool Solution Architect notes down the following exception handler specification:

Exception handler: DB2 database not available

Exception: SQLDataSourceException

Exception handler actions:

Create synthetic alert in ObjectServer;

Write a message into the policy log file.

Comment: This exception handler applies to all policies

where DB2 databases are accessed. The full Java

exception for this type of failure is:

com.micromuse.common.datasource.SQLDataSourceException

Architectural considerations

When attempting to calculate the number of Netcool components required during the design of Netcool architectures, the previous sections referred to variables such as: number of users; event processing rates;, datasource loading ― and so on.

In addition to these factors, consideration should also be given to the geographical layout of the locations to be managed, security and network restrictions, resiliency, and the loading



Page 15 of 71

incurred by custom functionality. Additional components may need to be added to resolve architectural or business rule constraints.

Security and network restrictions

Very often, security and network restrictions or limitations will affect Netcool architecture design and the number of components to be deployed. Such restrictions often affect the placement of Netcool/OMNIbus ObjectServers, Gateways and Probes ― but can also affect the placement of Netcool/Impact components, also.

EXAMPLE:

Widgetcom have a number of Probes and a Collection ObjectServer pair at remote site "A". The incoming events require enrichment by Netcool/Impact based on data in a DB2 database which is located at site A. The primary Netcool/Impact cluster is located at site "B" ― along with the Aggregation ObjectServers ― however network security restrictions stipulate that Netcool/Impact is not allowed to make connections from site B to site A.

The Netcool Administrator therefore decides to deploy a cluster of two Netcool/Impact servers at site A and configures them to perform one-time event enrichment on the events in the local Collection ObjectServers. The events can then be passed already enriched up to the Aggregation layer at site B.

Resiliency

High availability and resiliency is hallmark of Netcool product suite ― and therefore is an important consideration for any Netcool deployment. Generally speaking, it is a best practice that every Netcool component be deployed in a resilient manner. For this reason, Netcool/Impact servers should be deployed in clusters of at least two servers.

Additional Netcool/Impact servers may need to be added to a cluster in order to provide greater processing power ― however the need to deploy additional servers is dependent on stress testing the system under "production conditions". The term "production conditions" implies that the Netcool/Impact cluster is processing an amount of events that is likely to be encountered in production when it is eventually deployed. In addition to this, the event types should be representative in terms of type and event content so that they will be processed by Netcool/Impact at a rate similar to what would be expected in production. More details on provisioning numbers of servers are included in a later section of this chapter.

To ensure the maximum level of resiliency and disaster recovery ability, cluster member components should be installed on separate machines and ― where possible ― on different sites from each other. Where it is not possible to distribute a Netcool/Impact cluster across two physical sites ― for example: due to security of bandwidth constraints ― a cluster of two or more Netcool/Impact servers should be deployed on each site: one as a primary cluster and the other as a cold standby.

Note: Also see the section entitled: How many clusters should I deploy? later in this document for other considerations around clustering ― particularly relating to deploying Netcool/Impact across multiple sites or geographic locations.

Common sense should be applied to all architectural design decisions.



Page 16 of 71

Note: It is recommended to deploy N + 1 Netcool/Impact servers into a given environment ― where N is the number of Netcool/Impact servers necessary to support the given loading characteristics. The + 1 aspect of the sizing ensures that sufficient processing capabilities will remain in the event of an outage of one of the cluster members ― hence ensuring resiliency of the cluster.

Create a diagram

After geographical and architectural factors have been considered, it is very helpful and a suggested best practice to create a diagram of the proposed Netcool solution in order to help plan and visualise how the various components will connect to each other. With respect to Netcool/Impact, the diagram should be detailed enough to show sub-components including the Netcool/Impact servers, the Name Servers and the GUI servers.

Note: The diagram will necessarily be a work in progress until the testing phase has been completed and the numbers of components have been finalised.

Ports used by Impact

Another consideration during the planning phase is to determine if any ports need opening on firewalls, where present, between both Netcool/Impact components as well as the components Netcool/Impact interacts with. This would include Netcool/OMNIbus, any third party databases or systems Netcool/Impact interacts with in the course of its event processing, and the Tivoli Integrated Portal (TIP) GUI, if installed on a different host to the Netcool/Impact server.

Note: A full listing of the ports used by Netcool/Impact 6.1.1 can be found in the section entitled: Assigning ports on page 5 of the Netcool/Impact 6.1.1 Administration Guide. Subsequent sections explain how to view the port configuration of an installed system.

Although it is possible to change the various ports used by Netcool/Impact during the installation and configuration, it is recommended to use the default ports offered by the installer.

Hardware considerations

Two main areas of planning a Netcool/Impact deployment with respect to hardware are resiliency and resourcing.

Hardware resiliency

Each part of a Netcool/Impact solution should be resilient ― both in terms of software and hardware. Software resiliency is implemented by having secondary components available within each cluster to take over should the primary component fail. Hardware resiliency is implemented by not having multiple Netcool/Impact servers collocated on the same physical server.

When including hardware resiliency into an architectural design, the following points should be considered so as to avoid having any potential single points of failure:

Loss of a physical or virtual server a component is running on;

Loss of an entire site where one or more components may be located.

EXAMPLE:



Page 17 of 71

Widgetcom are planning a Netcool deployment initially with just a single Aggregation pair of Netcool/OMNIbus ObjectServers and a cluster of two Netcool/Impact servers. They have selected two sites located in different parts of the city as part of their Disaster Recovery plan and have a reliable high bandwidth link set up between the two sites.

The Netcool Administrator elects to install the primary Aggregation ObjectServer on the first site and the backup Aggregation ObjectServer on the second site. The Netcool/Impact cluster of two servers will have the primary server installed on the first site and the secondary server on the second site. This provides both functional and physical resiliency.

CPU, memory and disk space resourcing

Once you have identified the number of Netcool/Impact server components you will need and their respective physical placement in order to ensure resiliency, you will need to calculate the number of cores, memory and disk space each server will need. The following table gives recommended cores and memory provisioning requirements for each of the components.

Although it is possible to run multiple Netcool/Impact servers within on the same physical box, it is not recommended in a production system because it increases the severity of the performance hit suffered by a Netcool/Impact cluster in the event of an outage of one physical server.

Each Netcool/Impact cluster member installation should be done on a separate box therefore. Use the table below to calculate what hardware resource to provision for each physical server and then add allowance for any other processes that might also be running on the box ― including the operating system.

Component Recommendation

Netcool/Impact server

GUI server (TIP server)

Cores/CPUs: 8

RAM: 8 GB

Disk: 8 GB

Netcool/Impact server Cores/CPUs: 4

RAM: 4 GB

Disk: 8 GB

NOTES:

Netcool/Impact 6.1.1 is only available in a 64 bit version.

It is recommended that CPUs be 3 GHz or higher and be as fast as budget constraints allow.

No additional hardware resource needs to be provisioned for the Name Server. The Name Server is built in to the Netcool/Impact server as of version 6.1.

Please see the following link to the Netcool/Impact 6.1.1 Administration Guide for more information about hardware requirements:

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.netcoolimpact.doc6.1.1/common/dita/imp_hardware_requirements.html



Page 18 of 71

Note: The Netcool/Impact 6.1.1 Administration Guide provides information about minimum hardware requirements. This guide however provides recommended hardware provisioning for production systems. Development systems can use minimum guidelines however test systems should match production environments as closely as possible so as to provide legitimate validation of the performance capabilities of the engineered solution.

Also see the Netcool/Impact wiki for more information about provisioning, system requirements, the IBM® Software Product Compatibility Reports (SPCR) and system tuning:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Netcool%20Impact/page/Netcool%20Impact%206.1.1%20system%20requirements

EXAMPLE:

Widgetcom need to deploy two Netcool/Impact servers in a clustered configuration. To ensure resiliency, each cluster member will contain a Netcool/Impact server component, a TIP server component and a Name Server component. The initial hardware resourcing would therefore be two identical machines each provisioned with at least 8 cores/CPUs, 8 GB of memory and at least 8 GB of hard disk space.

Setting the memory for the Java Virtual Machine on the Impact profile

To ensure the JVM in which the Netcool/Impact server runs does not run out of memory during normal, production operation, it is recommended to set the maximum memory limit on the JVM to 80% of the available memory on the system. Information on how to configure this can be found in the Netcool/Impact 6.1.1 Administration Guide:

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.netcoolimpact.doc6.1.1/admin/imag_monitor_java_memory_status_c.html

Setting Java Virtual Machine memory for TIPProfile

To ensure that the Netcool/Impact GUI server or TIP does not run out of available memory during normal operation, it is recommended to set the maximum memory limit on the JVM to 80% of the available memory on the system. Information on how to configure this can be found in the Netcool/Impact 6.1.1 Administration Guide:

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.netcoolimpact.doc6.1.1/tip/tipdoc/ttip_admin_jvm_memory.html

Network resourcing

With respect to network requirements, components should be located in a data centre with good network reliability and bandwidth. Network connection speeds of 100 Megabits per second or higher are typically sufficient.

Other installation prerequisites

It is recommended to always run your Netcool systems with the latest fixpack available. Before installing Netcool/Impact, check on the IBM Technical Support site and download the latest fixpack available.

Alternatively, you can monitor the IBM Netcool/Impact Technical Support RSS feed for notifications of all bugs, technical tips and fixpack/interim fix availability information. Each RSS feed includes download locations for any items published. The IBM Technical Support RSS feeds are available here:





Page 19 of 71

http://www.ibm.com/software/support/rss/tivoli/

Netcool/Impact should be configured to start automatically on machine boot. See the section entitled Machine start-up later in this document for detailed information on how to set this up.

No Netcool components should be left running in debug mode in a production environment.

It is recommended to clean up any temporary files on the installation boxes after installation and configuration to maximise the available disk space.

Solution delivery

Consideration as to how a Netcool solution will be delivered by a solution engineering team should be given during the planning phase of any deployment project. The delivered solution should include all custom configuration and all relevant documentation. The concepts introduced in this section will be referred to throughout this document.

All deliverables should be reviewed with the end-customer before final project acceptance and sign-off. The "end-customer" will normally be the primary stakeholder and owner of the resulting Netcool deployment.

Custom configuration

The following list summarises the best practice approach for delivery of each of the custom configuration components in a solution ― and ensures that a solution is as portable and modular as possible.

All the items mentioned below should be collected together into a single directory location

and packaged up together (ie. using a zip or tar utility) for delivery along with the documentation described in the next section.

It is recommended that each of the following Netcool/Impact component configurations be delivered as follows:

One or more custom Netcool/Impact “projects” should be created so that custom components can be assigned to the project(s). Note that a component can be associated with more than one project. Associating custom components with projects makes the export/import process between different systems easier ― for example: between test and production.

Note: It is usual that external Data Sources will be different between development and production environments. As such, Data Sources should normally be assigned to a different project to the other custom components so that they are not exported from one environment to another. In such cases, the Data Sources will have to be set up manually on initial installation and configuration. Note that it only needs to be configured on the primary as the secondary Impact servers in the cluster will synchronise to the primary automatically when each one is started. See Chapter 3. Working with projects in the Netcool/Impact 6.1.1 User Interface Guide for more information about working with projects.

The projects Netcool/Impact server configuration in each environment (ie: development,

test, production) should be exported via the nci_export command and serve as a point of reference for the deployment. This exported configuration can be used to restore a corrupted or broken system. The syntax is:



Page 20 of 71

nci_export NCI --project widgetcom /tmp/NCI_export

Name Server configuration is done at installation time and typically doesn’t require modification after this point. The configuration of the Name Server cluster therefore should be documented in the Detailed Design Document (DDD) and configured for each system at the time of installation.

Note: See the section entitled: Documentation later in this document for more information around what needs to go into the Detailed Design Document.

TIP configuration is done at installation time and typically doesn’t require modification after this point. The configuration of the TIP server therefore should be documented in the Detailed Design Document (DDD) and configured for each system at the time of installation.

Operator Views can occasionally include auxiliary files ― for example: HTML or image files ― that need to be included in the solution delivery. These files should be collected using tar (UNIX) or a zip utility (Windows) so that they can be easily rolled out on a target system.

NOTES:

Solution portability is important when deploying the solution to multiple locations ― for example, when replicating an environment from development, to test and then to production. A portable solution also makes it very easy for the environment to be recreated elsewhere ― for example, by IBM Netcool Technical Support engineers in their labs. Following the guidance above will result in a very portable solution.

Any configuration files that are modified by hand should be backed up before they are

changed. For example, any changes to files in the $IMPACT_HOME/etc/ directory should be copied to a file of the same name with an appropriate file extension:

cp NCI1_server.props NCI1_server.props.orig (UNIX)

copy NCI1_server.props NCI1_server.props.orig (Windows)

Thereafter, if any updates are made to the "live" file, a further backup copy should be taken before making any changes. This will allow a rapid roll-back, if required.

A suggested naming convention for the backup copy filenames is to append them with a

.<date> file extension. For example:

cp NCI1_server.props NCI1_server.props.20120912 (UNIX)

copy NCI1_server.props NCI1_server.props.20120912 (Windows)

Documentation

Clear and thorough documentation is key to the success of any Netcool solution delivery. The solution delivery documentation would normally be produced by the engineering team responsible for delivering the solution. The documentation set is essential for anyone reviewing, deploying or maintaining the solution.



Page 21 of 71

The Business Requirements Document

The first key document is the Business Requirements Document (BRD). The BRD should contain a detailed description about every piece of custom functionality that will be required by the Netcool deployment ― including pseudocode, where possible.

A necessary prerequisite to the production of the BRD would be for the solution delivery team to undertake discussions with the business management and stakeholders in order to compile a detailed list of the business requirements. The signed-off BRD is essential for ensuring that solution scope does not creep during the solution development phase.

An example requirement pseudocode entry follows:

All incoming network events must have their Location field enriched with details from the inventory database. Details must include:

Site city location;

Building name;

Room number.

Any events for Nodes not found in the inventory database should be cleared.

Note: The BRD will include requirements that will likely need more than just Netcool/Impact to provide. For example, Netcool/OMNIbus is usually at the centre of most Netcool solution deployments and requirements will likely be met by a combination of products. The implementation details are not included in the BRD however ― just the requirements themselves.

The Detailed Design Document

The second key document is the Detailed Design Document (DDD). The DDD should contain a detailed, low-level implementation description for each business requirement in the BRD specifying how each requirement will be implemented and the rationale behind each implementation method ― since there are usually many ways to implement each requirement.

The DDD will also usually include the actual code that will be found in the solution delivery SQL files. As previously mentioned, the DDD may well include implementation details of each requirement across multiple products.

The DDD is used as a baseline reference that the custom solution would be engineered against ― both by the solution delivery team and engineers that maintain the system after initial deployment.

The Solution Delivery Package Document

The third key document is the Solution Delivery Package Document (SDPD). The SDPD should contain a detailed, itemised listing of each of the components in the solution delivery zip or tar archive ― and detailed instructions of how to install or apply each one. Note that the solution delivery package may contain more than just Netcool/Impact components ― therefore instructions should be provided in the SDPD for the installation/application of all the parts against the relevant products.

The SDPD is a reference for the un-packaging and deployment of each of the custom functionality components and is intended for use by anyone building out the delivered system either in a development, test or production environment.



Page 22 of 71

Note: If the solution delivery package contains implementation components for more than one product, subdirectories should be created within the package for each product (eg:

omnibus/, impact/, etc.)

The documentation should be produced in the order listed above ― that is: the BRD first, then the DDD and finally the SDPD. If there are any necessary changes to the requirements at any stage of the development phase, the documents will have to be reviewed and modified in the same order as they were initially produced.

Use of debug mode

The insertion of debugging code and the running of components in debug mode are both useful tools in Netcool solution development.

Debugging code may come in the form of additional lines of code in Netcool/Impact server policies that write additional information to log files, for example. It is not recommended to include code such as this in a production environment as it may invariably cause a performance bottleneck ― unless it can be easily activated/deactivated via flags, for instance. File I/O operations (ie. writing to log files), for example, can be relatively costly.

No Netcool/Impact component should be left running in debug mode in a production system. Generally speaking, debug mode significantly degrades performance.

On extremely rare occasions, it is sometimes necessary to run a Netcool process in debug mode in a production system when attempting to triage a critical issue ― however once a diagnosis is made and the problem resolved, those components must be taken out of debug mode and run normally.

Stress testing prior to deployment into production

It is essential to perform stress load testing on a Netcool solution prior to deployment into production to ensure that it will cope in an event storm scenario. Stress load testing involves loading up the system with a maximum predicted peak amount of data.

For example, in a scenario where Netcool/Impact is enriching Netcool/OMNIbus events, the ObjectServer could be loaded up with the maximum number of events ― all of which require enriching by Netcool/Impact ― that would be expected to be received during a typical event storm. With self-monitoring enabled, the Netcool/Impact event queues and memory usage can be monitored to ensure that the system will cope with such an influx of work. The system should be further monitored and validated that it returns to a ″normal″ state after it has caught up after the induced ″storm″.

Note: Monitoring of all Netcool components would be necessary during such testing to ensure that all components have been engineered to handle such occurrences.

When loading up the Netcool system with data, it is important to use a representative set of data similar to what production would likely hold. This will ensure that memory usage and load will be similar to what would be encountered in production. There is limited value in stress testing a system with synthetic events that are not acted upon by custom functionality.

Removal of temporary files

A final note ― after deployment of a delivered solution into an environment, any temporary files should be removed to leave a clean directory structure. Leaving temporary files sitting around in Netcool directories is unprofessional.



Page 23 of 71

Note that the term "temporary files" does not include backup files ― for example, when iterative changes are made to properties file and a backup taken. It refers merely to temporary files that a deployment engineer has created to store temporary data during installation, for example.


IBM Netcool/Impact 6.1.1 Best Practices Chapter 3: Installation © Copyright IBM Corporation 2012, 2013.

Page 24 of 71

Chapter 3 Installation

Full instructions for installing Netcool/Impact 6.1.1 can be found in chapter 2 of the Netcool/Impact 6.1.1 Administration Guide.

IBM Prerequisite Scanner

Prior to installing Netcool/Impact, it is recommended to use the IBM Prerequisite Scanner on the intended host machine to ensure that it is a supported platform and that the patch level is adequate for the installation to be successful.

The Prerequisite Scanner is not supplied with Netcool/Impact. You can locate it on the IBM Fix Central web site using the following URL:

http://www.ibm.com/support/fixcentral/swg/selectFixes?parent=ibm~Tivoli&product=ibm/Tivoli/Prerequisite+Scanner&release=All&platform=All&function=all

As an example, see the following tech note for information about using the IBM Prerequisite Scanner with Netcool/OMNIbus:

http://www.ibm.com/support/docview.wss?rs=3120&uid=swg21472859

Note: This information is referenced in the section entitled IBM Prerequisite Scanner in Chapter 4: Planning for installation or upgrade in the Netcool/OMNIbus 7.4 Installation and Deployment Guide.

Backing up the Deployment Engine (DE)

Before installing any Netcool component on a host where another Tivoli product has already been installed (ie. one for which a DE is already installed), it is recommended to back up the DE prior to installation of new components or patches so that the DE may be restored if problems are encountered during the installation.

Instructions for doing this are published as an IBM Tech Note and can be found at:

http://www.ibm.com/support/docview.wss?uid=swg21395223

Warning: These instructions assume installation is being done as the root user. Netcool/Impact should never be installed as the system root user. Assuming

Netcool/Impact has been installed as a non-root user, the acsi directory can be found under

the user's home directory ― for example: ~netcool/.acsi_netcool/ on UNIX systems. Also see the section entitled Appendix B: Deployment Engine command reference in the Netcool/OMNIbus 7.4 Installation & Deployment Guide.

Back up before applying fix packs and interim fixes

In addition to backing up the IBM Deployment Engine, as outlined in the previous section, it is also recommended to make a backup of your Netcool/Impact installation prior to applying any fix pack or interim fix ― so that you can roll your installation back in the case of any issues.

It is recommended to back up a Netcool/Impact installation in two steps:

1. Use the nci_export utility to export the configuration of the Netcool/Impact server to a backup location.



http://www.ibm.com/support/docview.wss?rs=3120&uid=swg21472859



IBM Netcool/Impact 6.1.1 Best Practices Chapter 3: Installation © Copyright IBM Corporation 2012, 2013.

Page 25 of 71

2. Use the tar utility (UNIX) or the zip utility (Windows) to make a copy of the $NCHOME directory to a backup location.

With the IBM Deployment Engine backed up plus the two items above, it should be easily possible to restore a Netcool/Impact installation to the saved state.

Setting maximum memory limits within Impact

If Netcool/Impact exceeds its memory allocation, it will fail and report an out-of-memory error. It is therefore very important to set the maximum memory limits of each Netcool/Impact server to the maximum amount possible to reduce the chance of an out-of-memory scenario occurring and thus the server failing.

The default amount of memory Netcool/Impact 6.1.1 will start with (Xms) is 256 MB and the

default maximum (Xmx) is 1,200 MB. In addition to the Xmx value, Netcool/Impact allocates a further 150 MB of memory for its own use. Hence the default maximum memory footprint of a Netcool/Impact server is 1,350 MB.

This default setting may be sufficient for development or even some production

environments however it is recommended to set the Xmx setting to the highest value possible depending on the amount of physical memory available on the host machine.

The Xmx setting can be set to a value just short of the amount of physical memory that has been provisioned for Netcool/Impact. For example, if 8 GB of memory has been provisioned

for the Netcool/Impact server’s use, Xmx could be set to 7,800 MB. With the additional 150 MB of memory that Netcool/Impact reserves on top of this, this would make the maximum process size 7,950 MB ― which is just short of the 8 GB provisioned.

It is a best practice to run self monitoring on all elements for Netcool/Impact. Self monitoring information will provide a Netcool Administrator essential information to enable them to effectively monitor the installed Netcool/Impact system.

Note: For more information on configuring memory settings in Netcool/Impact and for

instructions on how to modify the Xms and Xmx properties, see the section entitled: “Setting the memory for the Java Virtual Machine on the Impact profile” in Chapter 9: Self-monitoring in the Netcool/Impact 6.1.1 Administration Guide.

Installing in a shared environment

Often Netcool/Impact will be installed onto a pre-existing Tivoli Integrated Portal that has previously been installed for another product ― for example: a TIP that has Tivoli Business Service Manager (TBSM) or Netcool/OMNIbus WebGUI installed.

Note: If TBSM version 6.1.1 is installed, it is not required to install an Impact UI on the same system. All that is needed is to configure the Name Servers to add the new Impact cluster. The Impact UI inside TBSM 6.1.1 can be used to configure multiple Impact clusters.

Netcool/Impact 6.1.1 requires TIP version 2.2 or better. If your existing TIP environment is using TIP 2.1, you must install the TIP feature pack 2.2.0.1, before you can install Netcool/Impact 6.1.1.

Guidance on how to apply the feature/fix pack is available in the following IBM Support Tech Note and contains links to the feature/fix packs themselves, for each of the supported platforms:




IBM Netcool/Impact 6.1.1 Best Practices Chapter 4: Clustering © Copyright IBM Corporation 2012, 2013.

Page 26 of 71

Chapter 4 Clustering

This chapter contains best practice information in relation to the clustering of Netcool/Impact components. The two main components to consider are the Impact servers and the Name Servers that provide clustering management services to the Impact servers.

Prior to Netcool/Impact 6.1, the Name Server was integrated into the GUI server. From Netcool/Impact 6.1 onwards however, the Name Server is built in to the Impact server. Hence there will be as many Name Servers present as there are Impact servers. Since one Name Server is included with each Impact server, it is recommended to include all Name Servers in the Name Server cluster setup.

The two main purposes of clustering Impact servers are to ensure resiliency and to provide load-balancing capabilities. The main purpose of clustering Name Servers is to provide a resilient cluster management service to the Impact servers.

Name Server cluster members are aware of each other as soon as they start and automatically replicate any Impact server cluster management data between them. Impact servers, on the other hand, have no awareness of each other when they start up ― and rely on Name Server services to coordinate their cooperative activities. The primary purpose of the Name Servers is to provide this clustering management to the Impact servers ― including the nomination and management of who is the primary Impact server within each cluster.

Resiliency is provided within Netcool/Impact by having two or more Impact servers configured to run together as a cluster. This ensures there is no single point of failure. It is also important to properly configure the Name Servers to work together.

Note: You configure Name Server clustering using the nci_configuration_utility utility. See the section entitled: Post installation utility on page 37 of the Netcool/Impact 6.1.1 Administration Guide for more information.

With respect to Impact servers, load-balancing is provided automatically by a properly configured Netcool/Impact cluster. The primary Impact server cluster member is the focal point of the connection and processing activities. It allocates sections of work to secondary Impact server cluster members to carry out on its behalf. The performance and loading capabilities of a cluster can be increased by adding additional Impact server cluster members.

Note: For more detailed information on Netcool/Impact clustering and how to configure it, see: Chapter 5. Server clustering in the Netcool/Impact 6.1.1 Administration Guide.

Make all components resilient

When deploying Netcool/Impact, it is important to deploy at least two Impact servers in the Impact server cluster to ensure resiliency. Likewise, it is important to configure at least two Name Servers as a cluster to provide a resilient cluster management service to the Impact servers.



Page 27 of 71

Host Host

Impact

server

Impact

server

Name

server

Name

server

Impact

server

cluster

Name

server

cluster

Adding further Impact servers increases both the resiliency and the processing capabilities of the Impact server cluster. Adding further Name Servers to a Name Server cluster will not increase processing capabilities, however ― it will increase the resiliency capabilities of the Name Server cluster management service.

Note: For detailed information on how to configure both Impact server and Name Server clustering, see the section entitled: Setting up a cluster in Chapter 5. Server clustering in the Netcool/Impact 6.1.1 Administration Guide.

High Availability within Impact

High Availability or resiliency is implemented within Netcool/Impact using clustering techniques. As outlined in the previous section, the two main components types that are clustered to ensure a highly available and resilient service are the Impact servers and the Name Servers. The way the clustering works for Impact server clusters and Name Server clusters is slightly different however, and is explained in this section.

Cluster operation

This section briefly outlines how the two different Impact cluster types work.

NAME SERVER CLUSTERING

At least two Name Servers should be configured to work together as a cluster within any Netcool/Impact deployment. Each Name Server participating in the cluster should, as part of its configuration, include a listing of each of the cluster Name Server members participating in the cluster ― including itself. The configuration of the Name Server listing should be done uniformly across each cluster member so that each is aware of the other cluster members on start-up.

On initial start-up, each Name Server cluster member will read its configuration and attempt to establish communications with the other Name Server cluster members listed in the configuration. Once a connection is established, a Name Server cluster member will attempt to synchronise any Impact server cluster management data that may be held.



Page 28 of 71

If a Name Server is unable to reach another Name Server listed in its cluster configuration ― either because the remote Name Server has gone down or simply has not yet been started ― it will periodically attempt to reconnect. Once successful connection has been established between two Name Server cluster members, they will synchronise their cluster management data.

If an update is made to any of the Name Server cluster members’ cluster management data ― for example: a secondary Impact server joining the Impact server cluster, it is automatically replicated to the other Name Server cluster members.

IMPACT SERVER CLUSTERING

An Impact server will always try to connect to the first available Name Server cluster

member in the order that they are defined in the nameserver.props file. Once an Impact server registers itself with a Name Server, the Name Server cluster member will then automatically share this information with the other Name Server cluster members.

Note: If an Impact server successfully connects to the first Name Server listed in its

nameserver.props file, it will not attempt to connect to any other Name Servers unless it loses connection to the first one. Even then, it will attempt to re-establish connection to the

first Name Server listed in the nameserver.props file before trying the second one. If an Impact server connects to a secondary Name Server due to an outage of the primary Name Server, the Impact server will automatically fail back to the primary Name Server once it comes back up again.

There are two scenarios that can occur when an Impact server connects to a Name Server.

The first scenario is where the first Impact server in an Impact server cluster is connecting to a Name Server cluster:

Impact server → Name Server: “Hello, I am an Impact server running on: hosta, on port X; and am a member of cluster NCI. Is there already an Impact server cluster member registered with you under cluster name NCI?”

Name Server → Impact server: “No, you are the first. I will register you as the acting primary for Impact server cluster NCI.”

The Impact server will start all its services and begin normal operation.

The second scenario is where an Impact server is attempting to join a cluster for which there is already an acting primary running:

Impact server → Name Server: “Hello, I am an Impact server running on: hostb, on port Y; and am a member of cluster NCI. Is there already an Impact server cluster member registered with you under cluster name NCI?”

Name Server → Impact server: “Yes there is. The acting primary Impact server for cluster NCI is located at hosta on port X. I will register you as a secondary for Impact server cluster NCI.”

The Impact server will open a connection to the primary Impact server cluster member on hosta/port X and request a resynchronisation.

The secondary Impact server will synchronise (overwrite) its configuration with that of the acting primary Impact server of cluster NCI and assume a secondary role.

All Impact servers that register with a Name Server will periodically send a heartbeat and re-verify who the current acting primary Impact server is for the cluster. If a Name Server fails to receive a heartbeat from an Impact server, it will eventually mark that Impact server cluster member as dead.



Page 29 of 71

If the failed Impact server cluster member happens to be the primary, the first secondary Impact server cluster member to check in with the Name Server will assume the role of acting primary when the Name Server tells it that the primary Impact server has gone down. Subsequent secondary Impact servers that check in with the Name Server will be informed of the new acting primary at which time the remaining secondary Impact servers will resynchronise with the new acting primary ― and operation will continue.

If the previous acting primary Impact server subsequently comes back up, it will go through the normal Name Server connection process described above and assume a secondary role.

Note: It is possible to configure failback within an Impact server cluster ― that is, a primary Impact server will reassume the role of primary cluster member when it comes back up after an outage. This can be done by setting the property:

impact.server.preferredprimary to TRUE in the target Impact server’s properties file. See the section entitled: The Impact Server properties file in Chapter 5. Server clustering in the Netcool/Impact 6.1.1 Administration Guide for more information on how to configure this behaviour ― and also how to configure any secondary Impact servers to wait for the primary Impact server to start before they start.

How many clusters should I deploy?

Netcool/Impact gains both resiliency and additional processing capabilities by adding servers to the cluster. Further, Netcool/Impact is a natively multi-threaded application and is capable of running multiple services simultaneously from the same cluster. Hence from a functional standpoint, there is no need to deploy more than one cluster.

That said, there are a number of scenarios where a single cluster may not be the best deployment option. This section contains two scenarios to illustrate this.

Split brain scenario

As mentioned in the section entitled: Resiliency in Chapter 2, resiliency is gained by having one or more cluster members installed on separate physical hardware; ideally across more than one physical site. Central to Netcool/Impact’s clustering and processing capabilities however, is the ability for the cluster members to be able to communicate effectively between each other.

Consider the following diagram:



Page 30 of 71

If the network connectivity between sites A and B is unreliable, or if the connection between the sites is not resilient and there is an outage, consideration should be given to what would happen in such a scenario.

The process of operation of both the Impact server cluster and the Name Server cluster is outlined in a previous section: Cluster operation. In the case of a network outage between the two sites, the following would occur ― not necessarily in this order:

Both Name Servers would notice a loss of connectivity to its counterpart and assume that the other is down. The secondary Name Server would assume the role of primary Name Server for the cluster.

The primary Impact server would notice that the secondary Impact server is down and continue operation since it can still reach its primary Name Server. The primary Name Server would allow the primary Impact server to continue as a primary cluster member since it is available.

The secondary Impact server would notice that the primary Impact server is unavailable and so attempt to contact the primary Name Server ― which would also be unreachable. The secondary Impact server would then attempt to contact the secondary Name Server

as per its nameserver.props file.

The secondary Impact server would go through the normal connection routine with the secondary Name Server: first asking if a primary Impact server already exists for cluster NCI and, if not, request that it becomes the primary.

The secondary Name Server will subsequently assign the secondary Impact server the primary role within the cluster NCI. There would now be two separate Impact clusters running ― neither aware that the other is up and running.

When the network connection is restored, the following would occur:

The Name Servers would re-establish contact with each other. Since the original primary Name Server is listed as Name Server “0” in both Name Server configurations, the primary will re-assume the role of primary Name Server ― hence the secondary Name Server will synchronise to it.



Page 31 of 71

When the secondary Impact server (who is currently running as a primary) next pings the secondary Name Server, the secondary Impact server will be told that there is already a primary Impact server present for the NCI cluster. The secondary Impact server will then contact the primary Impact server, synchronise to it and then revert to the role of secondary within the cluster. The secondary Impact server will also notice the availability of the primary Name Server and reconnect to it since it is the first Name

Server in its nameserver.props file and hence it is the preferred Name Server.

In this scenario, both halves of the Impact cluster will run as two, separate clusters ― each one attempting to carry out the cluster’s assigned tasks as the primary cluster member.

If the running of the two halves of the cluster separately in the event of a network outage between sites is a desirable side effect, then such a deployment option could be considered. If it is not desirable however, that backup site Impact processing continue in the event of a network outage between the sites, then an alternative option is to deploy two clusters: one on each site. The cluster on the secondary site will be a cold stand-by and can be started when it is needed ― for example: in the case of a Disaster Recovery site failover.

Geographically distributed scenario

Very often, a Netcool solution will span multiple geographic locations ― including ones that span across the world.

The best practice Netcool/OMNIbus architecture for this sort of deployment leverages the ability of the visualisation layer Netcool/OMNIbus WebGUI to efficiently pull data over the WAN from multiple geographically datasources and combine the event data into a single view.

Note: A best practice document is freely available that describes the geographically distributed best practice Netcool/OMNIbus architecture. The document is entitled: Netcool/OMNIbus Large scale and geographically distributed architectures and is available from the Netcool/OMNIbus wiki: https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Tivoli%20Netcool%20OMNIbus/page/Best%20Practices

Since the underlying Netcool/OMNIbus systems at each region are independent of each other and not connected, it is recommended to do likewise with Netcool/Impact. In a geographically distributed scenario, each geographic location that requires Netcool/Impact capabilities should have its own, separate cluster. The configuration can easily be ported between the clusters using the export/import functionality plus gives the added benefit that Netcool/Impact configurations can be different, when needed, based on differing regional requirements.

EXAMPLE:

Widgetcom have deployed a separate Netcool/OMNIbus system at each of its data centres in Sao Paolo, Brazil and Perth, Australia. They plan to use WebGUI to enable them to view events from both locations in the same views. Advanced correlation and trouble ticketing functionality is required from Netcool/Impact at both locations.

The Netcool Administrator elects to deploy a separate Netcool/Impact cluster within each geography to provide the required functionality. This will help to avoid a “split brain” scenario across geographical regions as well as to minimise WAN traffic due to data being exchanged amongst geographically distributed Netcool/Impact cluster members.

https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Tivoli%20Netcool%20OMNIbus/page/Best%20Practices




Page 32 of 71

Name Server configuration

As previously mentioned, any Netcool/Impact cluster should have at least two of each component configured to ensure resiliency. Since a Name Server is automatically deployed within each Impact server, it is recommended to configure all available Name Servers to participate in the Name Server cluster.

Note: In version 6.1 of Netcool/Impact, a utility was introduced called

nci_configuration_utility to make the configuration of Name Server clusters easier.


IBM Netcool/Impact 6.1.1 Best Practices Chapter 5: Data Sources and Data Types © Copyright IBM Corporation 2012, 2013.

Page 33 of 71

Chapter 5 Data Sources and Data Types

This chapter contains best practices principles in relation to the configuration and use of Netcool/Impact Data Sources.

Note: Detailed information regarding how to set up and configure each of the Netcool/Impact Data Sources and Data Types can be found in the Netcool/Impact 6.1.1 DSA Reference Guide.

Provide backup options for Data Sources

Resiliency is a key principle within the Netcool suite. As such, it is important that any Data Sources be created in a resilient manner. This means ensuring that the back-end data source is resilient also ― otherwise there will be a single point of failure.

When creating Data Sources therefore, it is a best practice to have both the primary and secondary sources defined. Failover and fail-back should be enabled, where appropriate.

EXAMPLE

Widgetcom have a requirement that events will be enriched with data from a DB2 inventory database and Netcool/Impact will be used to meet this requirement. Resiliency of the DB2 database is provided via HADR and the connection credentials of both the primary and backup DB2 databases are provided by the DB2 DBA to the Netcool Administrator. The maximum number of connections to the DB2 database has been provided by the DBA as 30.

The Netcool Administrator creates a new Data Source via the GUI per the following details:

Data Source name: InventoryDB

DBUSERNAME=db2inst1

DBPASSWORD=netcool

MAXSQLCONNECTION=30

FAILOVERPOLICY=FAILBACK

PRIMARYHOST=inventorypri

PRIMARYPORT=50000

PRIMARYDATABASE=InventoryDB

BACKUPHOST=inventorybak

BACKUPPORT=50000

BACKUPDATABASE=InventoryDB

Use of the internal Derby Apache database

Netcool/Impact includes a specially configured version of an embedded Derby Apache database that has been optimised to store the underlying data used by the GUI reporting tools and reporting information generated by the Impact Server.


IBM Netcool/Impact 6.1.1 Best Practices Chapter 5: Data Sources and Data Types © Copyright IBM Corporation 2012, 2013.

Page 34 of 71

Note: For more information on the embedded Derby Apache database and how to use it, see the section entitled: Managing the database server in the Netcool/Impact 6.1.1 Administration Guide.


IBM Netcool/Impact 6.1.1 Best Practices Chapter 6: Policies © Copyright IBM Corporation 2012, 2013.

Page 35 of 71

Chapter 6 Policies

This chapter contains best practices principles in relation to the writing of Netcool/Impact policies.

Generally speaking, the best practices relating to writing Impact policies are, for the most part, good practices that apply to programming generally. This section covers more general programming good practices plus a number of additional points that are Impact specific.

Note: Information on how to create policies including a detailed reference of each of the policy language functions can be found in the Netcool/Impact 6.1.1 Policy Reference Guide.

Formatting and use of comments

The following example enrichment policy contains a number of features that are highlighted within this section.

EXAMPLE

Widgetcom have a requirement to implement a simple event enrichment policy. The Netcool Administrator creates the following policy for this purpose.

////////////////////////////////////////////////////////////////////////

// EnrichLocation

//

// Created by: J. Smith (jsmith) 12/04/2013

//

// The purpose of this policy is to enrich all incoming events with

// each Node's location. This is done by looking the Node of each

// event up in the Inventory DB2 database. If the Node is not found

// in the Inventory database, the Location field is set to NOT FOUND.

// The Event Reader filter for this policy should be:

//

// Location = ''

//

////////////////////////////////////////////////////////////////////////

// START POLICY LOG MESSAGE

log("EnrichLocation: start policy");

// PERFORM A LOOKUP IN THE DATATYPE LOCATIONS - LOOK UP THE Node FIELD

// IN THE ComponentNode FIELD IN THE DATABASE.

EnrichmentOrgNodes = GetByFilter(

"LOCATIONS",

"(ComponentNode='" + EventContainer.Node + "')",



Page 36 of 71

false);

// STORE THE NUMBER OF MATCHED RECORDS

Num = length(EnrichmentOrgNodes);

// LOG MESSAGE THAT LOOKUP WAS SUCCESSFUL

log("EnrichLocation: GetByFilter successful. Found " +

Num + " dataItem(s).");

// IF AT LEAST ONE INVENTORY ROW IS MATCHED

if (Num > 0) {

// THEN UPDATE EVENT WITH THE FIRST MATCHED INVENTORY ROW

EventContainer.Location = EnrichmentOrgNodes[0].NodeLocation;

// ELSE IF NO INVENTORY ROWS ARE FOUND

} else {

// THEN UPDATE EVENT WITH DEFAULT LOCATION VALUE

EventContainer.Location = "NOT FOUND";

}

// UPDATE THE LOCATION OF THE CURRENT EVENT IN THE OBJECTSERVER

ReturnEvent(EventContainer);

// LOG MESSAGE OF SUCCESSFUL ENRICHMENT

log("EnrichLocation: ReturnEvent successful");

// END POLICY LOG MESSAGE

log("EnrichLocation: end policy.");

Formatting, use of white space and indentation

It is important to make consistent use of white space and indentation in custom policies. It will make policy code more readable and of a more professional appearance.

In the given example, white space, tabs and blank lines are consistently applied. It matters less which formatting conventions are followed ― but more that they are followed consistently.



Page 37 of 71

Use of comments

The use of comments within the context of programming is a fundamental best practice of software engineering. It is also a best practice of solution development within the Netcool suite. Including comments in-line in Impact policy code is a best practice ― and one which is often neglected in Netcool/OMNIbus deployments.

If a Netcool configuration is thoroughly commented, an engineer beginning work on an existing system can deduce very quickly what a piece of functionality is supposed to do ― and how it is supposed to do it.

For Netcool/Impact, extensive commenting should be present in all policies, configuration files and anywhere else it makes sense to include them. This section contains a number of best practice conventions which should be followed wherever possible.

Include a header at the beginning of every policy

The first lines of every custom policy created as part of a Netcool solution should include information about the policy and include at the very least:

The name of the policy;

The creator and last modifier (if applicable) of the policy;

The date of creation and/or the date of last modification;

A thorough description in plain language of what the policy does and how it does it.

Note: Default out-of-the-box policies do not include creator or date information.

Include in-line comments

In-line comments should be included within all policies explaining at each step what the policy is doing. It is better to have too much in-line commenting that not enough.

Make in-line comments stand out

To make your code more readable, you should make your comments stand out from the lines of code. In the given example, this is done by capitalising the comments. Additional break lines can also be added to separate blocks of code. In the example, this is done by inserting blank lines between each code fragment.

Standardise your comment layout and formatting

Whatever conventions are used for the formatting of comments, it should be made consistent throughout all policies ― to make the code more readable and of a more professional appearance. In the given example, each comment header follows the same format and all in-line comments are in capital letters.

Defining sensible policy loops

As in most programming languages, Netcool/Impact provides loop constructs within the Impact Programming Language (IPL) which enables the programmer the ability to perform iterative tasks. The alternative policy language option JavaScript also provides looping constructs that enable a programmer to perform iterative tasks within Impact.

Although a powerful tool, loop constructs can also be the source of major issues if care is not taken in their use. The following are some tips for loop construct usage:

Use loop constructs sparingly

Only use loop constructs where not practicable to implement in a simpler way.



Page 38 of 71

Avoid nested loops where possible

Nested loop constructs can be the source of crippling performance issues, under specific circumstances.

Perform checks on the data to be processed

As with any piece of custom functionality, extensive testing should be carried out on a representative data set to ensure that the functionality is both logically correct and will perform to an acceptable level. Where iterative functionality features such as loops are used, checks should be carried out to ensure that the amount of data being processed by the customisations in the test environment is equivalent to what would be encountered in production.

Note: It is prudent to embed throttling safeguards in custom configuration to prevent the system from being bogged down or overwhelmed during event storms. This might be implemented within Impact policies directly ― or handled within Netcool/OMNIbus, for example.

Using Impact hibernations

Hibernations are policies that have been temporarily put to sleep. While a policy is asleep, it is stored internally at its current state and all processing is paused until it is woken by the hibernating policy activator service or by another policy. Examples of where hibernations can be used include: delaying a corrective action to give a downed link time to correct itself; or in an “X in Y” implementation.

The Hibernation data type is a system data type that stores hibernating policies. You do not typically create or modify Hibernation data items using the Tivoli Integrated Portal GUI. However, you can use the GUI to delete stored hibernations in the case that an error condition occurs and the hibernations are not woken by the hibernation policy activator or another policy.

While hibernations are stored, they take up memory. Care must be taken when implementing hibernations therefore so that their creation and management is carefully controlled. As always, any custom functionality that is implemented as part of a Netcool solution should be thoroughly tested in a realistic environment before deploying into production. With respect to hibernations, this means testing with a set of data that will induce the maximum expected number of hibernations ― plus a contingency ― to check if the designed system can cope with the load.

Note: For more information on implementing hibernations including examples, see Chapter 7. Handling hibernations in the Netcool/Impact 6.1.1 Solutions Guide.

Embedding log statements into policies

The policy logger service allows you to configure, among other things, the “Highest Log Level” that is currently being used within policy logging. The value can be any value between 0 and 3 inclusive. Any log statements within any policies that specify a log level the same or less than the “Highest Log Level” will be written to the policy log.

This feature enables the programmer a way of encoding varying degrees of logging to the policy logs and controlling the log level via the policy logger service.



Page 39 of 71

Note: For more information on the policy logger service and how to configure it, see the section entitled: Policy logger service in the Netcool/Impact 6.1.1 User Interface Guide and the section entitled: Log on page 127 in the Netcool/Impact 6.1.1 Policy Reference Guide for further examples on how to use the log statement.

It is recommended to encode log statements throughout custom policies. Not only will it assist with the development phase, it will also provide a mechanism that can be “switched on” via the policy logger service in a production system, in the event of an indeterminable issue, to provide critically important debugging information.

EXAMPLE:

The Netcool solutions developer encodes the following policy fragment with additional log statements to enable debugging to be done, should the need arise.

// LOG LEVEL 2 – LOG THE NODE BEING LOOKED UP

log(2, "Node being looked up: " + EventContainer.Node);

// PERFORM A LOOKUP IN THE DATATYPE LOCATIONS - LOOK UP THE Node FIELD

// IN THE ComponentNode FIELD IN THE DATABASE.

EnrichmentOrgNodes = GetByFilter(

"LOCATIONS",

"(ComponentNode='" + EventContainer.Node + "')",

false);

// STORE THE NUMBER OF MATCHED RECORDS

Num = length(EnrichmentOrgNodes);

// LOG LEVEL 1 - MESSAGE THAT LOOKUP WAS SUCCESSFUL

log(1, "EnrichLocation: GetByFilter successful. Found " +

Num + " dataItem(s).");

// IF AT LEAST ONE INVENTORY ROW IS MATCHED

if (Num > 0) {

// LOG LEVEL 2 – WRITE OUT THE FOUND NODE LOCATION

log(2, "Node: " + EventContainer.Node + " -- " +

"NodeLocation: " + EnrichmentOrgNodes[0].NodeLocation);

...



Page 40 of 71

Capturing errors within policy execution

When errors are encountered during policy execution, an exception is generated. For example, an exception would be generated if a database lookup failed due to the database being offline. Consideration should be given to what Netcool/Impact should do in the event of an error occurring.

By default, Netcool/Impact comes with a default exception handler which will be executed if no specific exception handler exists for the exception that has been raised. It is acceptable to use the default exception handler however it should be reviewed in the context of the various potential problems that may be encountered and verify that its actions are acceptable.

If using JavaScript to write Impact policies, a suggested method for capturing errors within

policy execution is to use the try catch notation.

Note: For more information on exceptions and exception handling, see the section entitled: Exception handling specification in Chapter 2 of this document.

Event Isolation and Correlation

Event Isolation and Correlation is provided as an additional component of the Netcool/Impact product. Event Isolation and Correlation is developed using the Operator View technology in Netcool/Impact. You can set up Event Isolation and Correlation to isolate an event that has caused a problem. You can also view the events dependent on the isolated event.

Note: For more information about Netcool/Impact Event Isolation and Correlation, see Chapter 18. Configuring Event Isolation and Correlation in the Netcool/Impact 6.1.1 Solutions Guide.


IBM Netcool/Impact 6.1.1 Best Practices Chapter 7: Services © Copyright IBM Corporation 2012, 2013.

Page 41 of 71

Chapter 7 Services

This chapter contains best practices principles in relation to the configuration and use of Netcool/Impact Services.

Event Processor Service

This section contains best practices principles in relation to the configuration and use of the Event Processor service.

The event processor manages the incoming event queue and is responsible for sending queued events to the policy engine for processing. The Event Processor service sends events fetched from readers and listeners to the policies. This service is responsible for managing events coming from the following event sources:

OMNIbus event reader;

OMNIbus event listener;

Database event reader;

Database event listener;

JMS message listener;

WSNNotification listener.

Configuring the number of threads

Netcool/Impact is a natively multi-threaded application and has the ability to process multiple events through defined policies concurrently. The Event Processor service configuration contains both a minimum and maximum number of threads that the Impact server should attempt to run at any one time.

When running, Impact will automatically adjust the number of threads in-use depending on how well it is performing. On initial start-up, Impact runs with the minimum number of threads. Impact then measures the performance, gradually increases the thread count, and compares the performance with the new thread configuration with the default configuration of the minimum number of threads it started with. If there is an improvement in throughput, Impact runs with the new configuration and then periodically measures the performance again, until one of two events occurs:

It reaches the limit set by the maximum number of threads;

It reaches a saturation point where increasing the number of threads further does not improve performance.

Note: For more information on the Event Processor Service, see the section entitled: Event processor service on page 136 of the Netcool/Impact 6.1.1 User Interface Guide.

In setting up the minimum and maximum numbers of threads in the Event Processor of a Netcool/Impact 6.1.1 server, the following guidelines should be followed.

Minimum number of threads: (number of CPUs/cores) + 1

Maximum number of threads: (number of CPUs/cores + 2) × 5

Note: The Event Processor Service should be restarted if any changes are made to its configuration.



Page 42 of 71

In a clustered environment, changes made to the event processor service via the GUI will only be applied to the primary Impact Server and do not automatically propagate to the other Impact servers in the cluster. It is recommended therefore to configure the Event Processor via the Command Line Interface (CLI).

Note: For more information about configuring the Event Processor Service in a clustered environment, see the section entitled: Configuring the event processor service in a cluster in on page 92 of the Netcool/Impact 6.1.1 Administration Guide.

EXAMPLE:

The Netcool Administrator is setting up a secondary Impact server on a dedicated machine that has 4 available cores. Based on the best practice guidance, the minimum number of threads is calculated to be (4) + 1 = 5. Based on the best practice guidance, the maximum number of threads is calculated to be (4 + 2) × 5 = 30.

The Netcool Administrator connects to the secondary Impact server via the CLI, configures the minimum and maximum thread settings for the Event Processor service and then restarts the service:

READY

Update Service set MinNumThreads=5 where Name='EventProcessor';

Command Executed

READY

Update Service set MaxNumThreads=30 where Name='EventProcessor';

Command Executed

READY

Update Service set Running=FALSE where Name='EventProcessor';

Command Executed

READY

Update Service set Running=TRUE where Name='EventProcessor';

Command Executed

READY

Note: For more information and examples on how to configure the Event Processor Service via the CLI, see the section entitled: Event Processor commands on page 144 of the Netcool/Impact 6.1.1 Administration Guide.

Maximising the processing throughput

The Event Processor Service contains a property called Processing Throughput: Maximize. If checked, the Event Processor will attempt to get the maximum performance out of the allocated threads. This can result in high CPU usage however and so consideration should be given to other processes running on the same machine as Impact. When you leave this field cleared, it runs conservatively at around 80% of peak performance.

If the machine is dedicated for the use of Impact, it is recommended to have this option enabled. If other processes are running on the same machine, it is advised to carry out



Page 43 of 71

performance testing to establish whether or not running at maximum throughput will impact too much on the performance of the other processes.

Retaining the tuning configuration on restart

As described in the section above: Configuring the number of threads, Impact will run through an automatic thread tuning process when it first starts up. There is an option available in the Event Processor Service called: Tuning configuration: Maintain on Restart.

If this option is set, each time the Event Processor is started, it will use the same number of threads it had settled on in the previous run. This feature is useful in cases where the environment where Netcool/Impact runs has not changed much from the previous run. If this property is enabled, the Event Processor will instead start with the maximum throughput immediately, rather than engaging in repeated tuning to reach the maximum.

It is recommended therefore to enable this property in production environments.

Note: For more information on the Event Processor Service, see the section entitled: Event processor service on page 136 of the Netcool/Impact 6.1.1 User Interface Guide.

Managing the Connection Pool for SQL datasources

The number of connections opened to external datasources needs to be determined and configured on a per datasource basis. SQL datasources include a property called Maximum SQL Connection which specified the number of simultaneous connections Impact is permitted to make to that datasource.

The maximum number of connections an Impact server can make however, is restricted to the maximum number of threads as defined in the Event Processor. Remember that each Impact server in a cluster may have a different maximum number of threads defined for its Event Processor ― based on the number of cores or CPUs available to that server.

Hence for maximum performance, the Maximum SQL Connection property in each SQL datasource should be set to the same value as the Event Processor Service maximum number of threads value.

Before doing so however, the administrator of each external datasource should be consulted to ensure that this number of concurrent connections will be acceptable.

Note that in a clustered environment, each Impact server in the cluster will attempt to make the Maximum SQL Connection number of connections to the target datasource ― of course limited by the maximum number of threads defined in that Impact server’s Event Processor.

Hence if the Maximum SQL Connection property for a given datasource is set to 10 and there are three Impact servers in the cluster, the Impact cluster may collectively make up to 30 concurrent connections to that datasource. This may or may not be acceptable to the target datasource.

Note: As always, any configuration should be stress-tested in a test environment before deploying into production to make sure that both Impact as well as that the target datasources are not overloaded.

Event Reader service

This section contains best practices principles in relation to the configuration and use of the Netcool/Impact Event Reader service.



Page 44 of 71

Use the default polling interval

It is best practice to use the default polling interval of 3000 milliseconds.

Configure Event Reader to automatically start

It is best practice to configure the Event Reader and all other business critical services to start automatically when the Impact server starts. It is therefore recommended to enable the Event Reader to Startup: Automatically when server starts.

Optimising queries to OMNIbus

Queries to Netcool/OMNIbus via the Event Reader can be optimised in the following ways.

1. Limit the fields that are selected by the Event Reader when it reads in new events from Netcool/OMNIbus. The default behaviour of the Event Reader is to select all fields for the target events. The only fields that actually need to be selected however are the fields that are referenced in the policy or policies. To restrict the number of fields, edit the Event Reader service and click on the Fields button on the General Settings tab. In the pop-up window, fields can be deselected from the Event Reader. If you are unsure of the field that will be needed across all the policies, you can use the Optimize List button to automatically analyse your policies and limit the field selection for you.

2. On the Event Mapping tab, ensure that any created mappings have efficient and appropriately restrictive filters so as only to match on events that the policies are intended for.

Note: For more detailed information on the configuration of these two elements, see the section entitled: OMNIbus event reader service in the Netcool/Impact 6.1.1 User Interface Guide.

Stop testing after first match

In the scenario where multiple policies are listed in your Event Reader mapping, consider if every event actually needs to be executed by all the policies. It may be the case, for instance, that if the event matches one of the mapping conditions, it only needs to be executed by that policy. If this is the case, the Event Reader can be made more efficient by having the property Stop testing after first match enabled.

Limit reprocessing of events

The Event Reader can be configured to either process events once only or reprocess them any time they are updated. This behaviour is controlled by the property: Get updated events. In the interests of efficiency, it is better to configure the Event Reader to process events only once ― that is, not get updated events. There are times, however, when the reprocessing of events is necessary.

It is common for the set of requirements that Impact will carry out to contain both scenarios where events will only be processed once ― for example: event enrichment ― and scenarios where events may need to be reprocessed ― for example: a correlation type activity.

In this case, it is recommended to have two Event Readers configured:

One Event Reader will be configured to not get updated events ― and contain event mappings for the single processing activities;

One Event Reader will be configured to get updated events ― and contain event mappings for ongoing processing activities.



Page 45 of 71

This strategy will involve two Event Readers instead of two but will mean that only events that should be read by Impact will be read by Impact. This can therefore reduce over time the overall number of events Impact is reading into its event queues for processing.

Order of events read

The Order by property in the Event Reader allows the Netcool Administrator to specify a clause to be applied to the events being read in from the ObjectServer. Normally it is preferable to process events in the order that they were received in the ObjectServer. If this property is left unset, the default is to use the Serial field as the default ordering. It is recommended to use this default setting unless there is a specific reason for changing this.

Caching data

If the data being read from the remote data source is fairly static, enabling data caching should be considered. With data caching enabled, the Impact server will cache the results of queries to the data source and refer to the cache when carrying out event processing before going to the remote data source. If the data is found in the cache and has not yet expired, the Impact server will use the cached copy of the data instead. The time-to-live setting will vary depending on how frequently the target data changes.

If the remote data source dataset is relatively dynamic, then data caching is not recommended. In such cases, it can quickly become inefficient to make the Impact server cache and refer to data in its cache that it never or rarely actually uses.

Policy Activator Service

This section contains best practices principles in relation to the configuration and use of the Netcool/Impact Policy Activator service.

Care when setting the Activation Interval

A Policy Activator with a given Activation Interval is analogous to a Netcool/OMNIbus ObjectServer temporal trigger ― it fires at defined intervals and runs a piece of code.

A Policy Activator should be carefully tested in a test environment prior to deploying into production to ensure that the Activation Interval is set to a value that is appropriate given the policy complexity and the load it therefore induces on the systems infrastructure.

As always, testing of Policy Activators along with the rest of the configuration should be done against an event data set that is representative of the maximum number expected in production.

Policy Logger Service

This section contains best practice guidance around the configuration of the Policy Logger Service.

Enabling multiple policy log files

By default, the Policy Logger Service will create a single log file that contains all the log statements from all policies. A configuration feature is available that causes the Policy Logger Service to create a separate log file for each policy. This allows an administrator to more easily analyse any given scenario ― as they can focus their attention on the execution of a particular policy and not see the noise being created from all the other policies.



Page 46 of 71

In order to enable this feature, the property: Append Policy Name to Log must be selected. It is a recommended best practice to enable this property.

Note: For more information on configuring the Policy Logger Service, see the section entitled: Policy logger service in the Netcool/Impact 6.1.1 User Interface Guide.

Adjusting the log level

Another property of the Policy Logger Service is called Highest Log Level. Assuming the implementer has encoded varying degrees of log information into the custom policies, an administrator can adjust this property to vary the level of information being logged to the policy log files. Having this ability to adjust the log level on-the-fly without editing policies or interrupting the service can prove invaluable in the event of diagnosing a production issue.

Note: See the section entitled: Embedding log statements into policies for more information regarding how to encode differing levels of log statements into your policy code.

Care when inserting log statements

If issues are encountered in a production system, it is not desirable to begin modifying policies in order to glean additional debugging information. It is important therefore to encode debugging logic into an Impact solution so that vital information can be obtained, if needed.

The previous sections outline a mechanism for using log levels to control the information that is written to log. Although the log statement is executed by the Impact server, nothing is written to the log file unless the current log level of the Policy Logger service is the same or higher than the log level assigned to the log statement.

A common scenario is where the result set from a query is sent to the log file. Usually, the log statement logging level is set to a suitably high level so that it would not actually write to the log file under normal conditions.

Even if a log statement is defined at a high enough level to prevent it from being written to log under normal conditions, the Impact server will still assemble the string in memory. For small string fragments, the amount of memory required to assemble the string is negligible. In some cases however, the return result from a query can be very large. For example, the result of a web services call could be in excess of 600 MB. Having access to such information may be invaluable should there be a production issue ― but executing these log statements may inadvertently balloon Impact’s memory usage, even when the information is not used.

Care must be taken therefore to ensure log statements are not executed by the Impact server if it is anticipated that the result set will be significantly large ― even when the information isn’t actually written to file, due to the defined log level.

This section outlines a mechanism that can be applied to ensure that log statements that handle sizeable amounts of data are not executed unless they are required. At a high level, the mechanism is as follows:

Create a global debug variable that is used as a debug level flag (SetGlobalVar function).

Use conditional constructs (ie. “if” statements) to control the path of execution within a policy based on the value of the global debug variable. Log statements can then be configured to only evaluate if the global debug variable is set to debug mode.



Page 47 of 71

EXAMPLE:

The Netcool Solution Architect at Widgetcom wants to implement more detailed logging messages within the production environment which can be activated when critical production issues arise. She does not, however, wish to incur unnecessary performance burdens on the Impact cluster while it is not necessary ― nor is it desirable to have a system where policy changes are needed in order to activate the additional logging information.

The Netcool Solution Architect elects to insert key code fragments throughout the Impact policies and use conditional statements combined with global variables to enable the additional logging to be switched on or off.

An example Impact policy code fragment follows:

if (widgetcomdebug == true) {

Log(3,"Message : " + messageContent);

}

The variable widgetcomdebug will be toggled between true and false via an additional

policy. This additional policy will be activated as needed via the nci_trigger utility.


IBM Netcool/Impact 6.1.1 Best Practices Chapter 8: Operator Views © Copyright IBM Corporation 2012, 2013.

Page 48 of 71

Chapter 8 Operator Views

This chapter contains best practices principles in relation to the configuration and use of Netcool/Impact Operator Views.

TIP based Operator View versus JazzSM

With the advent of JazzSM, there are now two ways to build dashboards within Netcool/Impact: traditional Impact Operator Views or JassSM dashboards.

If the purpose of the dashboard is just to visualise data, JazzSM can be used.

If however, the requirement is to implement workflows that potentially access and process data from multiple sources; or contain user inputs; or are relatively complex, then it is recommended to use Netcool/Impact Operator Views.

If you are using a TIP based environment, it is also recommended to use Operator Views rather than JazzSM dashboards. Operator Views are launched from the Netcool/Impact server directly and will avoid the need to deploy both a TIP server and a JazzSM server.


IBM Netcool/Impact 6.1.1 Best Practices Chapter 9: Final steps and considerations © Copyright IBM Corporation 2012, 2013.

Page 49 of 71

Chapter 9 Final steps and considerations

This chapter contains final configuration recommendations in the configuration of Netcool/Impact 6.1.1 and final points to consider after installation.

Machine start-up

It is a best practice to configure Netcool/Impact to start automatically when the machine it is installed on boots up. This section contains instructions on how to set this up for both UNIX and Windows operating systems.

UNIX

On a UNIX machine, the procedure involves creating a script in the init directory along with soft links in the start-up directories to the script.

The script should be named /etc/init.d/nci and contain something like the following:

#!/bin/sh

NCHOME=/opt/IBM/tivoli

TIP_HOME=/opt/IBM/tivoli/tipv2

export NCHOME TIP_HOME

case "$1" in

'start')

su – netcool –c "${TIP_HOME}/profiles/TIPProfile/bin/startServer.sh server1" &

;;

'stop')

su – netcool –c "${TIP_HOME}/profiles/TIPProfile/bin/stopServer.sh server1

–username tipadmin –password netcool" &

;;

*)

echo "Usage: /etc/init.d/nci { start | stop }"

;;

esac

NOTES:

The installation directory may vary in your installation. Modify the environment variables accordingly therefore.

The su command should be modified to match the installation user. This example

assumes Netcool/Impact is installed and run as the user: netcool.

Since the TIP server tipadmin password is stored in this file, the file permissions should be set to protect the contents of the file to just the super user.



Page 50 of 71

The script then needs to be protected from unauthorised view by setting the file permissions appropriately:

chmod 700 /etc/init.d/nci

chown root:sys /etc/init.d/nci

Finally, the soft links need to be created to the start-up directories so that the script will be called at the correct time during machine start-up and shut down:

ln -s /etc/init.d/nci /etc/rc0.d/K100nci

ln -s /etc/init.d/nci /etc/rc1.d/K100nci

ln -s /etc/init.d/nci /etc/rc2.d/S100nci

Windows

On a Windows machine, the auto-start process involves checking that the Windows service that starts Netcool/Impact is set to start automatically when the machine starts.

Since this service is automatically created when the product is installed and, by default, set to automatically start, it is likely that nothing further needs to be configured.

Transferring content between Impact systems

A recommended method for transferring content between Netcool/Impact clusters is to use the export/import utilities provided within the product.

A Netcool/Impact configuration can be exported using the following command:

$IMPACT_HOME/bin/nci_export

A Netcool/Impact configuration can be imported using the following command:

$IMPACT_HOME/bin/nci_import

Using projects to organise custom content

It is recommended to create at least one custom project to assign custom configuration items to. Data sources and data types should be allocated to a custom project ― separate from the rest of the custom content.

The reason for this is that when a project is exported for the purposes of importing into another environment, you would want to exclude the data sources and data types. This is because it is likely that the data sources for a production system will be different than those for a development or test environment. Hence you don’t want to export the data sources and data types when you export the rest of the custom content. Similarly, when you make changes to the configuration as part of a scheduled maintenance program, you don’t want to



Page 51 of 71

inadvertently overwrite the production data sources and data types when you import the updated configuration from the development/test system.

EXAMPLE:

Widgetcom have completed testing the changes to the Impact custom configuration and are ready to copy the updated content into production. In all the environments, the data sources and data types are members of the DATASOURCES project and the rest of the custom content are members of the WIDGETCOM project.

The Netcool Administrator uses the following command to export the configuration from the test system:

$IMPACT_HOME/bin/nci_export NCI_1 --project WIDGETCOM /tmp/NCI_1

The Netcool Administrator then tars up and copies the new custom configuration to the production primary Impact server machine. The secondary Impact server is shut down at this time in preparation for the import process.

The Netcool Administrator then un-tars the custom configuration package and uses the following command to import the new custom configuration into the production primary Impact server:

$IMPACT_HOME/bin/nci_import NCI_1 /tmp/NCI_1

Finally, the Netcool Administrator restarts the secondary Impact server, ensures successful resynchronisation and then monitors the system for a period of time until they are satisfied that the new configuration is functioning correctly and within acceptable performance parameters.

Note: If Netcool/Impact is running in a cluster setup, it is recommended to shut down all

secondary servers and have only primary server running before running nci_import. After

nci_import has completed successfully and there are no locks in the primary, the secondary servers can be started and will replicate the configuration from the primary.

Self monitoring

Self-monitoring is used to monitor such aspects of Netcool/Impact runtime performance, as memory status usage, event queue size, data source status, service status, and cluster status.

Enabling self monitoring causes an Impact cluster to monitor key performance indicators and generate synthetic events within Netcool/OMNIbus. These key events are invaluable for a Netcool Administrator to monitor Impact’s overall health and also for pre-empting potential problems.

With full self monitoring enabled in Netcool/Impact, automated processes within Netcool/OMNIbus can then be engineered to alert Netcool Administrators when critical self monitoring events are generated ― for example: to send an email or an SMS.

Note: Netcool/Impact self monitoring events have a Netcool/OMNIbus Class of 10,500. Administrative view filters should be configured to include these events.



Page 52 of 71

It is a best practice to enable all Netcool/Impact self monitoring options on each Impact cluster member. This includes development and test systems ― as it will provide valuable insight into solution developers or testers as to how well suited the Impact solution is at coping with the given expected loads.

Note: It is essential that any Netcool solution is tested thoroughly with a representative dataset both in terms of quantity of data and the data’s content. This will provide suitable validation of the solution prior to deploying into production.

You configure self-monitoring on each server instance separately, and each server runs the self-monitoring feature independent of other cluster members. For a clustered Netcool/Impact configuration therefore, self monitoring should be configured via the

$IMPACT_HOME/etc/servername_selfmonitoring.props properties file, or via the command line interface. Using the GUI to configure self monitoring will configure the primary Impact server only.

NOTES:

The sampling intervals for each self monitoring option should be set to the defaults;

All self monitoring options should be enabled for each Netcool/Impact server participating in the cluster and set to auto-start when the server starts.

Note: For more information on Netcool/Impact 6.1.1 self monitoring, see Chapter 9. Self-monitoring in the Netcool/Impact 6.1.1 Administration Guide.

Performance tuning

A performance tuning reference guide was produced by the Netcool/Impact development team and made available on the Netcool/Impact wiki.

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Netcool%20Impact/page/Version%206.1%20Performance%20Tuning

Although originally written for Netcool/Impact 6.1, it is also relevant to version 6.1.1.




IBM Netcool/Impact 6.1.1 Best Practices Further reading © Copyright IBM Corporation 2012, 2013.

Page 53 of 71

Further reading

IBM Netcool/Impact 6.1.1 Product documentation:


IBM Netcool/Impact by example:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Tivoli%20Netcool%20Impact/page/About%20Impact%20By%20Example

IBM Netcool/OMNIbus 7.4 Best Practice documentation:









IBM Netcool/Impact 6.1.1 Best Practices Appendix A: Initial requirements gathering checklist © Copyright IBM Corporation 2012, 2013.

Page 54 of 71

Appendix A. Initial requirements gathering checklist

This checklist should be completed during the planning phase of a Netcool/Impact deployment as part of a wider Netcool solution requirements capturing exercise in order to capture the key information required to size and scope the solution.

List of custom functions required from Netcool/Impact (pseudocode) ― page …… of ……:

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 55 of 71

List of custom functions required from Netcool/Impact (pseudocode) ― page …… of ……:

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 56 of 71

List of components that Netcool/Impact will connect or interact with ― page …… of …… :

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 57 of 71

List of all event sources Netcool/Impact will process events from ― page …… of ……:

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 58 of 71

List of all custom Data Source Adaptors (DSAs) required by the solution ― page …… of ……:

NOTE: Include estimated reads/writes per second for each one.

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 59 of 71

List of all custom Data Types (DTs) required by the solution ― page …… of ……:

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 60 of 71

List of all custom Netcool/Impact Services required by the solution ― page …… of ……:

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 61 of 71

List of all custom event processing functionality (one-time) ― page …… of ……:

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 62 of 71

List of all custom event processing functionality (repeated or correlation) ― page …… of ……:

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 63 of 71

Total number of Netcool/Impact clusters:

Name of this Netcool/Impact cluster:

Location of this Netcool/Impact cluster:

Number of Netcool/Impact servers in cluster (minimum of 2):

Number of Name Servers in cluster (minimum of 2):

Peak number of events per day (including reprocessed events): events/day

Peak number of events per second (including reprocessed events): events/second

Number of Administrative users:

Details of Administrative users:

Full name: ……………………………………………… Username: ……………………………………………






………………………………………………………………………………………………………………………

Maximum number of concurrent Operator View sessions:

Other notes:

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 64 of 71

Netcool/Impact Operator View name:

Details of how this Operator View will be accessed:

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

Sketch of how this Operator View should look:



Page 65 of 71

Netcool/Impact Operator View name:

Details of Operator View dashboard components (Data Sources, active component actions, etc):

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 66 of 71

Exception handling policy name:

Details of exception handling policy (pseudocode):

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………



Page 67 of 71

Other notes: ……………………………………………………………………………… page …… of ……:

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………


IBM Netcool/Impact 6.1.1 Best Practices Notices © Copyright IBM Corporation 2012, 2013.

Page 68 of 71

Notices

This information was developed for products and services offered in the U.S.A.

IBM® may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing

IBM Corporation

North Castle Drive

Armonk, NY 10504-1785

U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia Corporation

Licensing

2-31 Roppongi 3-chome, Minato-ku

Tokyo 106-0032, Japan

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:



Page 69 of 71

IBM Corporation

958/NH04

IBM Centre, St Leonards

601 Pacific Hwy

St Leonards, NSW, 2069

Australia

IBM Corporation

896471/H128B

76 Upper Ground

London

SE1 9PZ

United Kingdom

IBM Corporation

JBF1/SOM1 294

Route 100

Somers, NY, 10589-0100

United States of America

Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.

The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.

Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.

All IBM prices shown are IBM's suggested retail prices, are current and are subject to change without notice. Dealer prices may vary.

This information is for planning purposes only. The information herein is subject to change before the products described become available.



Page 70 of 71

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.

If you are viewing this information softcopy, the photographs and color illustrations may not appear.

Trademarks

These terms are trademarks of International Business Machines Corporation in the United States, other countries, or both:

AIX

developerWorks

IBM

Lotus

Netcool

Tivoli

WebSphere

Adobe, Acrobat, Portable Document Format (PDF), PostScript, and all Adobe-based trademarks are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle, Inc. in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Intel is a registered trademark of Intel Corporation, Inc. in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.


Documents

IBM Netcool/Impact 6.1 · 2013-07-11 · IBM Netcool/Impact 6.1.1 Quick Start Guide The Netcool/Impact Quick Start Guide helps you get started with a base configuration of Netcool/Impact