IBMTivoli Netcool Performance Manager 1.3.2 Wireless ... · v Tivoli Netcool Performance Manager 1.3.1 or later, Technology Packs. v IBM System x hardware. v Sun Microsystems and

IBM Tivoli Netcool Performance Manager 1.3.2Wireless ComponentDocument Revision R2E1

Wireless Deployment Guide

��

NoteBefore using this information and the product it supports, read the information in “Notices” on page 39.

© Copyright IBM Corporation 2007, 2012.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

Contents

About this document . . . . . . . . . vAudience . . . . . . . . . . . . . . . vRequired skills and knowledge . . . . . . . . vReferences . . . . . . . . . . . . . . . vUser publications . . . . . . . . . . . . viGlossary . . . . . . . . . . . . . . . vi

Chapter 1. Introduction . . . . . . . . 1Dimensioning procedure . . . . . . . . . . 2Training . . . . . . . . . . . . . . . . 2

Chapter 2. Architecture . . . . . . . . 3Overview . . . . . . . . . . . . . . . 3

Principal components . . . . . . . . . . 3Optional components . . . . . . . . . . 4

Sample system architecture . . . . . . . . . 4Minimum configuration . . . . . . . . . 5

Chapter 3. Requirements . . . . . . . 7Software prerequisites . . . . . . . . . . . 7Kernel parameters . . . . . . . . . . . . 8

Solaris kernel settings . . . . . . . . . . 8Linux kernel settings . . . . . . . . . . 8

SWAP . . . . . . . . . . . . . . . . 9SWAP for Solaris . . . . . . . . . . . . 9SWAP for RHEL . . . . . . . . . . . . 9

Solaris zones . . . . . . . . . . . . . . 9Prerequisite for hardware purchase and deployment 10

Chapter 4. File types and disk layout 11Terminology definitions . . . . . . . . . . 11RAID levels overview . . . . . . . . . . . 11Database RAID and disk types . . . . . . . . 12

Database data files and temp files . . . . . . 12Database online redo log files . . . . . . . 13

Database archive log files. . . . . . . . . . 13Hardware . . . . . . . . . . . . . . 14Configuration . . . . . . . . . . . . 14

Database backup files . . . . . . . . . . . 14Hardware . . . . . . . . . . . . . . 14Configuration . . . . . . . . . . . . 14

Log files . . . . . . . . . . . . . . . 14Hardware . . . . . . . . . . . . . . 14Configuration . . . . . . . . . . . . 15

Report results . . . . . . . . . . . . . 15Configuration . . . . . . . . . . . . 15Hardware . . . . . . . . . . . . . . 15Loader files (LIF files) . . . . . . . . . . 15Gateway files (raw files) . . . . . . . . . 16Disk layout on the database server . . . . . 17

Chapter 5. System configuration. . . . 19Filesystem and SAN configuration. . . . . . . 19Network configuration . . . . . . . . . . 19Database configuration . . . . . . . . . . 19

Database memory configuration . . . . . . 20Application server configuration . . . . . . . 22Loader configuration . . . . . . . . . . . 22Gateway configuration . . . . . . . . . . 23

Configuration of properties files . . . . . . 24Configuration of environment variables . . . . 24Configuration of spool directories . . . . . . 24

High availability. . . . . . . . . . . . . 25Tivoli Integrated Portal and Tivoli CommonReporting . . . . . . . . . . . . . . . 25Modeling . . . . . . . . . . . . . . . 25IBM Tivoli Monitoring. . . . . . . . . . . 25

Chapter 6. Backup strategy . . . . . . 27Database backups . . . . . . . . . . . . 27Database backup storage . . . . . . . . . . 27Database backup procedures. . . . . . . . . 27

Prerequisites . . . . . . . . . . . . . 28Database backup activities . . . . . . . . 28

Filesystem backup . . . . . . . . . . . . 28Cold standby . . . . . . . . . . . . . . 29

Chapter 7. Other topics . . . . . . . 31Memory allocation . . . . . . . . . . . . 31Sizing database OS partitions . . . . . . . . 31Sizing database extents . . . . . . . . . . 33Setting the database block size . . . . . . . . 34Update customer database template . . . . . . 34

Manually setting memory parameters . . . . 36Manually setting tablespace . . . . . . . . 36

Notices . . . . . . . . . . . . . . 39Trademarks . . . . . . . . . . . . . . 41

© Copyright IBM Corp. 2007, 2012 iii

iv IBM Tivoli Netcool Performance Manager: Wireless Deployment Guide

About this document

The IBM Tivoli Netcool Performance Manager: Wireless Deployment Guide, providesguidelines to be used when planning a deployment of an IBM IBM Tivoli NetcoolPerformance Manager - Wireless Component system. This guide should be used inconjunction with a customer specific sizing report and the Installation Guide.

This document does not describe Tivoli Netcool Performance Manager - WirelineComponent deployments, or the optional IBM Tivoli Common Reportingenablement installation.

AudienceThe audience for this guide is professional and deployment services, experiencedsystem administrators and other professionals who are responsible for sizing,deploying and installing Tivoli Netcool Performance Manager.

Required skills and knowledgeThis guide assumes that you are familiar with the following:v Tivoli Netcool Performance Manager 1.3.1 or later, Technology Packs.v IBM System x hardware.v Sun Microsystems and x86-64 hardware.v Sun Microsystems Solaris and Red Hat enterprise Linux operating system.v Oracle databases, tables and tablespaces.v Linux and UNIX basics and system administration.

This guide also assumes that you are familiar with the relevant network and OSSsystems.

ReferencesFollowing are the references:1. IBM Tivoli Netcool Performance Manager v1.2

Tivoli Netcool Performance Manager – Wireless: Dimensioning Procedure v 1.0,September 2009

2. IBM Tivoli Netcool Performance Manager v1.2Linux Benchmarking & Scalability Report for Wireless PerformanceManagement v1.0, September 2009

3. Oracle Database Backup and Recovery Reference, 11g Release 2 (11.2):http://www.oracle.com/technology/documentation/index.html

© Copyright IBM Corp. 2007, 2012 v

http://www.oracle.com/corporate/pricing/sig.html

User publicationsTivoli Netcool Performance Manager software provides the following userpublications:v release notesv user guidesv online help

This documentation is available for viewing and downloading on the informationcenter at:

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.tnpm.doc/welcome_tnpm.html

GlossaryTable 1. Glossary of terms

Acronyms Description

COTS Customer Off The Shelf.

EDDS Estimated Daily Database Size.

ITM IBM Tivoli Monitoring.

LIF Loader Files.

Raw Refers to tables with traffic data.

PGA Program Global Area.

RDBMS Relational Database Management System.

SGA System Global Area.

TNPM Tivoli Netcool Performance Manager.

TP Technology Pack, Technology Package.

TPDK Technology Pack Design Kit.

TPDT Technology Pack Dimensioning Tool.

vi IBM Tivoli Netcool Performance Manager: Wireless Deployment Guide



Chapter 1. Introduction

This document provides guidelines to be used when planning the deployment of aTivoli Netcool Performance Manager system. It provides guidance on how thesystem should be configured and what issues should be considered when settingup a Tivoli Netcool Performance Manager system.

This document would normally be used before the installation of a Tivoli NetcoolPerformance Manager system, and after the hardware for the system has beendimensioned. It gives guidance on how the hardware and software should beconfigured.

Dimensioning a Tivoli Netcool Performance Manager (Wireless) system is acomplicated matter, because of the large number of variables involved in customernetworks. The accuracy of a hardware sizing has inherent risks as it is heavilyreliant on precise entity counts. If Tivoli Netcool Performance Manager (Wireless)hardware proposed is too large then the cost of the system can be needlesslyexpensive and bids may be lost. If the hardware proposed is too small then thesystem may experience problems and not perform optimally, resulting in possiblelarge support costs and extra hardware may also need to be purchased resulting inadditional costs. There may be a considerable time lapse between early sizing (e.g.Budgetary) and the Full (final) sizing. It is important to check the latest customerinformation and a Full sizing is performed by qualified IBM personnel todetermine what customer hardware is required.

Additional challenges often arise, particularly in the pre-sales cycle, due to a tightschedule for producing a sizing with sometimes very limited information availableabout a customer’s network requirements and performed by people who havelimited experience with Tivoli Netcool Performance Manager (Wireless).

Under no circumstances should a budgetary sizing be used to define thedimensioning and acquisition of Tivoli Netcool Performance Manager (Wireless)production hardware.

A Full Sizing must be performed by qualified IBM personnel before anyhardware is purchased.

It is important that the difference between a Budgetary and Full Sizing isunderstood, and that both are used appropriately, limiting each one to its definedrole. A Full (final) Sizing must be performed by qualified IBM personnel beforeany customer hardware is purchased. You can contact such personnel using the"TNPMW-Dimensioning" mail alias, and thereby begin this process. By notadhering to this process you may incur extra cost and significant delays to theimplementation of a fully optimal system.

© Copyright IBM Corp. 2007, 2012 1

Dimensioning procedureFor details on the dimensioning procedure, see the "Dimensioning" section that iscontained at the following link:

https://w3.tap.ibm.com/w3ki/display/ISSTinfo/IBM%20Tivoli%20Netcool%20Performance%20Manager%20for%20Wireless

TrainingFor training material on the dimensioning procedure, login to the:

Tivoli Technical Continuous Learning (TTCL) system at https://ttcl.centra.com/login/index.aspx.

Course NSA38 for the Dimensioning Procedure (Search in Catalog).

Figure 1. Deployment cycle as part of the hardware installation lifecycle

2 IBM Tivoli Netcool Performance Manager: Wireless Deployment Guide



https://ttcl.centra.com/login/index.aspx

https://ttcl.centra.com/login/index.aspx

Chapter 2. Architecture

This chapter contains the architecture of the Tivoli Netcool Performance Managersystem.

OverviewA Tivoli Netcool Performance Manager system consists of one or more TivoliNetcool Performance Manager servers and a client layer. The client layer is aweb-based user interface to the Tivoli Netcool Performance Manager applicationserver.

The principal components can be installed on a single server platform (amonolithic system) or on several different servers (a distributed system).

The server components might be deployed on Intel or AMD based Red HatEnterprise Linux servers, or on Oracle or Sun SPARC servers running Solaris 10.

Principal componentsApplication framework

The core application that provides services to users to create and generatereports. It provides the web server for the user interface through a JBossapplication server. It also runs an agent framework to gather informationabout data sources and information that is required to run reports. Itprovides platform management services to start, shut down, and monitorthe application services.

Database componentAn Oracle RDBMS is used to store performance management data from thenetwork infrastructure, configuration data for the application, andtime-based data for scheduling reports and maintenance tasks. If thedatabase component is separate from the other components, then theOracle client must be installed on the other component machines.

Loader componentThe Loaders process the loader data files (LIF files) generated by theGateways, and store the data in the Oracle database. A number of differentLoader processes might run simultaneously to process data from differentnetwork equipment vendors or to process data, in parallel, from a singlenetwork equipment vendor and technology.

Gateway componentThese services are provided by the Gateway framework, which transfers,parses and manipulates raw performance data from the network elements.Outputs from the Gateways are LIF files which are processed by theLoaders and stored in the Oracle database.

User managementUser management is provided by an IBM Tivoli Directory Server by usingthe Lightweight Directory Access Protocol (LDAP).


Optional components

Tivoli® Common Reporting: Business Intelligent software that is used for reportgeneration. Tivoli Netcool Performance Manager includes a Tivoli CommonReporting license to enable users to report on Tivoli Netcool Performance Managerdata from Tivoli Common Reporting.

IBM Tivoli Monitoring software: IBM Tivoli Monitoring software must beinstalled on a separate machine to the application so that it can provide monitoringinformation if the application machine fails.

Sample system architectureThere are a number of different system architectures that can be used for a TivoliNetcool Performance Manager system. The appropriate system architecture isnormally determined by using the Dimensioning procedure. Each server in thesystem must be sized according to the projected volumes and types of data that ithas to process. The projected growth of such data and any customer prerequisitesmust also be considered.

The following table shows different sample system architectures. These samplearchitectures provide example hardware for each architecture. The most suitablearchitecture must be chosen based on available system at the time of deployment.

Table 2. Sample architectures

System TypeDatabaseComponent

ApplicationComponent

LoaderComponent

GatewayComponent

Monolithic: 1Server

Database component, Application component, Loaders, and Gatewayson 1 server

Example: IBM x3550 with 2 Intel Xeon Quad Core CPUs, 24 GB RAM

Monolithic: 2Servers

Database component, Application component, andLoaders on 1 server

Example: IBM x3550 with 2 Intel Xeon Quad CoreCPUs, 32 GB RAM

Gateways onseparate servers

Example: IBMx3550 with 2Intel Xeon QuadCore CPUs,12GB RAM

Distributed: 2Servers

Databasecomponent on 1server

Example: IBMx3850 with 2Intel Xeon QuadCore CPUs, 64GB RAM

Application component, Loaders, and Gateways on 1server

Example: IBM x3550 with 2 Intel Xeon Quad CoreCPUs, 32 GB RAM




Application component andLoaders on 1 server

Example: IBM x3550 with 2 IntelXeon Quad Core CPUs, 48 GB

RAM

Gateways onseparate servers



Table 2. Sample architectures (continued)

System TypeDatabaseComponent

ApplicationComponent

LoaderComponent

GatewayComponent




Applicationcomponent on 1server


Loaders and Gateways on anotherserver

Example: IBM x3850 with 4 IntelXeon Quad Core CPUs, 32 GB

RAM

Servers for use in Tivoli Netcool Performance Manager systems include:v IBM servers:

– x3400– x3500– x3550– x3650– x3850– x3950

v Sun servers:– M4000– M5000– M8000– M9000

Each server might be suitable for certain tasks and must be sized with appropriateCPUs, memory, and disks to process the required data efficiently.

Minimum configurationThe minimum hardware requirements for a Tivoli Netcool Performance Managerserver are:v CPU with at least 4 Cores (IBM or Sun).v 24 GB core memory.v 14 Disks (internal or on SAN) - 4 x 72 GB (146 GB disks can be considered) and

10 x 146 GB hard disks. Minimum disk size 72 GB and maximum disk size 300GB.

v Optical drive (DVD ROM/R/RW).

Chapter 2. Architecture 5


Chapter 3. Requirements

Software and hardware requirements for deployment.

Software prerequisitesThird-party softwareThe following third-party software products are required before installing a TivoliNetcool Performance Manager system.

Operating system

v Oracle Solaris 10 Update 8 with latest recommended patch clusterv Red Hat Enterprise Linux 5.1 and 5.5 x86_64.v IBM AIX 6.1 and 7.1

RDBMSServer:v Oracle database 11.2.0.2 with partitioning option.

Client:v Oracle database 11.2.0.2 with partitioning option.v Oracle Instant Client 11.2 – Basic.v Oracle Instant Client 11.2 – SQL*Plus Extension package.

The Oracle client is required on each component that does not reside on the samecomputer as the database component.

Other required software

v JBoss application server 4.0.3 Service Pack 1.v Perl 5.6.1.

Software storage requirementsThe minimum disk storage that is required for each software component is shownin the following table.

Table 3. Software storage requirements

Software Location Minimum Size

Oracle 11 $ORACLE_HOME 2.5 GB

Tivoli Directory Server /DB2

/opt 1.5 GB

Application servercomponents

/appl 512 MB

Database components /appl 150 MB

Tivoli Common Reporting is an optional component. The hardware and softwarerequirements for it can be found at the following location:

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.tcr_cog.doc/ctcr_cog_supported.html




IBM Tivoli Monitoring is an optional component. The hardware and softwarerequirements for it can be found at the following location: http://www-01.ibm.com/support/docview.wss?uid=swg27018000

Kernel parametersThe operating system kernel must be configured before installation to set theshared memory parameters that are required to install Oracle and Tivoli DirectoryServer / DB2. These parameters can be set automatically by using thesystem_configure script that is provided in the Platform package which isincluded in the Tivoli Netcool Performance Manager software package.

Solaris kernel settingsOn Solaris 10, the usual method for configuring kernel parameters is to use theresource controls mechanism, through the projadd and projmod tools.

The kernel settings that are required for Solaris are shown here:forceload: sys/shmsysforceload: sys/semsysset noexec_user_stack=1set noexec_user_stack_log=1set maxphys=1048576set semsys:seminfo_semmnu=1024set semsys:seminfo_semmsl=16010set semsys:seminfo_semmni=4096set semsys:seminfo_semmns=65535set semsys:seminfo_semume=512set semsys:seminfo_semopm=100set semsys:seminfo_semvmx=32767set shmsys:shminfo_shmmax=34359738368set shmsys:shminfo_shmmin=1set shmsys:shminfo_shmmni=1024set shmsys:shminfo_shmseg=100

Linux kernel settingsOn RHEL, these parameters are set in the /etc/sysctl.conf file or by using thesysctl command.

The kernel settings that are required for Linux are shown here:kernel.sem = 250 32000 100 128kernel.shmmax = 68719476736kernel.shmmni = 4096kernel.shmall = 4294967296fs.file-max = 753808net.core.rmem_default = 4194304net.core.rmem_max=4194304net.core.wmem_default = 262144net.core.wmem_max = 262144net.ipv4.ip_local_port_range = 1024 65000


http://www-01.ibm.com/support/docview.wss?uid=swg27018000

http://www-01.ibm.com/support/docview.wss?uid=swg27018000

SWAPThe system must be configured with sufficient swap space. If the required amountof swap space is not allocated, installation might fail or the process will fail toinitialize.

Additional swap space is required for the application and loader processes. Theamount of allocated swap space on each server will depend on the sizingrecommendations.

For database servers, you must locate swap partitions on SAN storage.

SWAP for SolarisSwap space must be configured depending on the amount of physical memory onthe server.

An example of the swap setting for Oracle 11 on Solaris (monolithic anddistributed systems) is:v Dedicated distributed database server, swap allocation = the size of RAM.v Monolithic (single node) solutions, swap allocation= 2 times the size of RAM.

SWAP for RHELSwap space must be configured depending on the amount of physical memory onthe server.

Example swap settings for Oracle 11 on RHEL are:v Dedicated distributed database server, swap allocation = 2 times the size of

RAMv Monolithic (single node) solutions, swap allocation = 2.5 times the size of RAM

For example, on a dedicated system with 32 GB of memory, the swap size wouldbe 64 GB.

For example, on a monolithic system with 32 GB of memory, the swap size wouldbe 80 GB.

Solaris zonesThe deployment of a Tivoli Netcool Performance Manager system is supported onSolaris 10 zones.

A single non-global zone can be installed as a Tivoli Netcool Performance Managerserver in the same way as a stand-alone Solaris server. The usual application ofthis capability is to install a distributed system over two or more zones on a singleSPARC platform. This might be chosen to limit the cost of Oracle licenses whichare dependent on the number of CPUs.

In addition, the zones might be defined as containers that use the resource controlfeatures of the Solaris 10 operating system. For example, a single server with 128GB of RAM might be split into two containers, one for the database server and theother for the Application server and Loaders. The Application container wouldoccupy a non-global zone (zone1) with its memory usage capped at 32 GB. The

Chapter 3. Requirements 9

database server would be installed on another zone (zone2) with memory cappedat 72 GB. In this way, the system resources are allocated to the zones according totheir sizing requirements.

If a Solaris server is to be installed using zones and containers, then onlynon-global zones can be used as Tivoli Netcool Performance Manager servers. Theglobal zone must not have any components that are installed on it.

On a zoned Solaris server, the kernel configuration must be completed for theglobal zone and non-global zones. The Platform package must be installed on theglobal zone and the system_configure script that is run to update the kernelparameters. On the non-global zones, system_configure must also be run to createthe resource controls projects for Tivoli Directory Server/DB2 and Oracle.

Prerequisite for hardware purchase and deploymentv RAID 10 required and is the only supported RAID configuration for ALL Oracle

file systems (/oradata*, /oralogs*, and /oradump*)v RAID 5 is not supported and must not be used forTivoli Netcool Performance

Manager database filesystems.v RAID 3 is not supported and must not be used for Tivoli Netcool Performance

Manager database file systems.v RAID 4 is not supported and must not be used for Tivoli Netcool Performance

Manager database file systems.v RAID 6 is not supported and must not be used for Tivoli Netcool Performance

Manager database file systems.v RAID Oracle redo logs (oralogs1 and oralogs2) must be placed on separate

LUNs to that of the Oracle data files.v RAID file systems for Oracle files require a minimum Stripe/Segment Size of

512 KB.v Network attach storage that is not supported,v All external file system must reside on SAN only.v Average Service Time per LUN is recommended to be < 5 ms for optimal

performance.v IO Wait Time per LUN is recommended to be < 35 ms (average sample interval

<= 10 seconds) for optimal performance.v A minimum of 2 GB of cache is required per Fibre Channel controller. (average

sample interval <= 10 seconds)v The Underlying IP Network must support min 1 GB/s transfer rates.v Linux supported ext3 file systems only.v Solaris supported UFS file systems (/oradata*, /oralogs*, and /oradump), ZFS

file systems (/, /appl and /opt)v No remotely shared file systems are recommended and supported.v Oracle RAC is not supportedv Periodic system audits and analysis are recommended to ensure optimal

performance and identify any future growth needs.


Chapter 4. File types and disk layout

Supported file types and disk layout.

Terminology definitionsTable 4. Storage terminology

Term Definition

Spindle A Spindle is a physical hard disk.

Disk Group A Disk Group is a set of physical hard disks(or spindles) that are grouped into a diskarray.

See section “RAID levels overview,” fordetails about disk arrays.

Disk array Same as Disk Group.

RAID A RAID is a logical device that uses a DiskGroup, applying specific rules to form onestorage unit.

LUN A LUN is a logical device that is part of adisk array, or is an entire disk array. A LUNis exported from SAN and presented to anOS as one single logical disk device.Multiple LUNs can be exported to an OSand presented as different devices sharingthe same physical RAID array.

SCSI disk A SCSI disk is a fast physical hard disk thatis used for performance. The main beneficialcharacteristic is RPM (rotations per minute).

SATA disk A SATA disk is normally slower than a SCSIdisk but can have the advantage of havinggreater capacity than a SCSI disk. SATAdisks can be used to store files where IOperformance is not the major factor.

SAS Serial Attached SCSI. A computer bus that isused to move data to and from storagedevices.

RAID levels overviewDifferent RAID levels provide a different level of protection.

The following is a summary of the RAID levels that are used in Tivoli NetcoolPerformance Manager application environments and the advantages of each level:v RAID-0 (block-level striping without mirroring) offers high performance, but

does not provide any data redundancy.v RAID-1 (mirroring without striping) offers high performance and data protection

for read-intensive applications. It is most suited to applications that require highdata availability, good read response times, and where cost is a secondary issue.


v RAID-5 (block-level striping with distributed parity) offers both data protectionand increased throughput. It stripes data and parity across all drives in thearray. Because of the way that data is written to data files in small blocks,RAID-5 must not be used for Tivoli Netcool Performance Manager systems.

v RAID-10 (mirrored and striped sets, also known as RAID 1+0) offers higherperformance than RAID-1 and more reliability than RAID-5. RAID-10 is the bestfault-tolerant solution in terms of protection and performance.

Database RAID and disk typesThere are various disk RAID technologies available. Depending on the type ofdatabase files, different disk types and RAID levels are suitable.

Note: In a Tivoli Netcool Performance Manager application environment onlyRAID-10 and RAID-1 array types must be used on mount points that store theapplication data. Any other array type is not supported.

Note: Estimates for the total size of disk space that is allocated to each mountpoint must be known before you start any deployment activity. This can beachieved by completing a dimensioning of the system.

The following sections provide examples, per data file and per mount point, for atarget server.

Database data files and temp filesThe Oracle database stores all loaded application data in data files. Data files mustbe placed on devices with good I/O performance.

The Tivoli Netcool Performance Manager database stores application data in datafiles and allocates temporary segments in temp files when necessary. The files arestored on disk devices mounted to four mount points:v /oradata01

v /oradata02

v /oradata03

v /oradata04

Hardwarev Small (72 GB per disk; depending on disk availability 146 GB or 300 GB disks

can also be considered). Fast SCSI disks (at least 10 k RPM. 15 k RPM willachieve a greater I/O performance increase).

ConfigurationAll disks that are allocated to store database data files must be grouped into oneRAID 1+0 disk array spreading a workload to all allocated spindles.

4 LUNs are exported from this array and presented to an OS to mount into fourmount points:v /oradata01

v /oradata02

v /oradata03

v /oradata04


Database online redo log filesDatabase online redo log files store transactions history.

They are one of the most demanding points in terms of sequential I/O operationsperformance. Online redo log files must be protected on a hardware level, placedon the dedicated disks or dedicated mirrored storage devices.

Hardwarev 4 small (72 GB per disk, 146 GB or 300 GB disks can also be considered) and fast

SCSI disks (at least 15 k RPM). Setup as 2 RAID-1 devices (two mirrors),exporting 1 LUN for each.

v For small proof of concept deployments, 2 small (72 GB per disk, 146 GB or 300GB disks can also be considered) and fast SCSI disks (at least 15 k RPM). Setupas 2 dedicated disk devices, exporting 1 LUN for each.

Note: This configuration does not offer data redundancy and must be consideredonly as a proof of concept and not with production data.

ConfigurationProduction systems

v 4 Disks (2 disk mirrors, 2 x RAID-1).v 1 LUN is exported to an OS from each disk mirror.v LUNs that were exported in the previous step are mounted to /oralogs1 and

/oralogs2 mount points.

Proof of concept systems (no data redundancy)

v Dedicated disks.v 1 LUN is exported to an OS from each disk mirror.v LUNS are mounted to /oralogs1 and /oralogs2 mount points.

Note: If only bigger disks are available to store online redo log files, they must bepartitioned to use only the first 100 GB of the disk and leave the rest of the diskunallocated. Normally external disk cylinders provide better sequential I/Operformance.

Database archive log filesArchive log files store database transactions history and can be used for databaserecovery operations. They are important files in any database environment. Thesefiles can be placed to slower but larger disks as I/O performance is not a majorfactor for a disk volume where archive log files are stored.

Tivoli Netcool Performance Manager database during normal operation generatestens of GBs of Archive log files per day. As a result, a large disk volume isrequired to store them.

Chapter 4. File types and disk layout 13

Hardwarev Slower but larger SATA disks (7200 RPM) of appropriate total size must be

grouped into one RAID-10 array.

Configurationv 1 LUN is exported from the disk array that is created in the previous step and

mounted to /oradump/archivelogs mount point.

Database backup filesDatabase backups are an important part of any production environment and mustbe taken regularly.

One backup approach for backing up the Tivoli Netcool Performance Managerdatabase environment is a proxy full database backup that is stored on disk, withpossible subsequent backups to tape to increase data safety. The backup databaseimage is updated on disk regularly by applying recent transactions from thearchive log files.

To store a backup copy, a sufficient amount of disks must be allocated to store filesof approximately the same size as the total Tivoli Netcool Performance Managerdatabase plus 10%.

See Chapter 6, “Backup strategy,” on page 27, for details on backing up thedatabase.

Hardwarev Slower but larger SATA disks (7200 RPM) of appropriate total size must be

grouped into one RAID-10 array.

Configurationv 1 LUN is exported from the disk array that is created in the previous step

mounted to /oradump/backups mount point.

Log filesTivoli Netcool Performance Manager maintains all its application log files in/appl/virtuo/logs. A cron job, created during installation, archives all log files to/data/trace_archive1 by default (in gzip format). It is important that the availablefile system space where the /data/trace_archive1 directory resides is managed.

HardwareIn most cases, both directories can reside on the root filesystem. If/data/trace_archive1 needs to be preserved for a long time, slower but largerSATA disks (7200 RPM) of appropriate total size should be grouped into oneRAID-1 or RAID-10 array, either on the SAN or internal to the application servermachine.


ConfigurationIn most cases, both directories can reside on the root filesystem.

Alternatively, 1 LUN is exported from the disk array created in the previous stepmounted to /data/trace_archive1 mount point.

Report resultsTivoli Netcool Performance Manager report results are stored in/appl/virtuo/var/rg.

This directory contains two sub directories:v Logs - report result logs.v Spool - result results (XML files) and exports (CSV, XML, XLS).

These directories are not archived by the system. It is important that the availablefilesystem space where these directories reside is managed.

ConfigurationIn most cases, both directories can reside on the /appl filesystem.

Alternatively, 1 LUN is exported from the disk array created in the previous stepmounted to /appl/virtuo/var/rg mount point.

HardwareIn most cases, both directories can reside on the /appl filesystem. If reports andtheir associated logs need to be preserved for a long time, slower, but larger SATAdisks (7200 RPM) of appropriate total size should be grouped into one RAID-1 orRAID-10 array, either on the SAN or internal to the application server machine.

Loader files (LIF files)Loader files, or LIF files, are generated by the Gateway component and containformatted raw performance data from the network. These files are processed bythe data loader processes and the information is stored in the database.

The loader LIF files are stored in /appl/virtuo/var/loader/spool by default. AsLIF files can take a large amount of disk space (especially in a backlog scenario), itis important to carefully select where they are located. Depending on thedeployment topology (monolithic or distributed) and the available hardware, LIFscan either reside on the Loader servers or on the SAN.

The number of days LIF files are kept is configurable. The number of days to keepLIF files is partly determined by the frequency of backups. If backups are takenweekly you should keep 8 days of LIF files so that the LIF files can be reloadedeasily. Normally 3 days is acceptable but this varies from deployment todeployment.

LIF file size should be carefully assessed. When migrating from legacy productsLIF file sizes should be known.

You can estimate the daily LIF file size from the EDDS (Estimated Daily DatabaseSize). 10GB of EDDS normally corresponds to 70GB of LIF files (this may varydepending on the Technology Packs and the percentage of counters loaded).


For example, given a system with an EDDS of 100GB and a 5 day backlogretention policy, the LIF file size could be estimated to 100*7*5 = 3.5TB logical, and7TB when taking into account RAID-1 overhead. Given that 100GB of EDDSrequires a minimum of 8 disks (30GB EDDS can saturate 2 disks in RAID-1), apossible configuration would include eight 1TB SATA-2 disks, or preferably sixteen500GB disks configured in RAID-10 to take into account additional IO duringbacklog processing.

Backlog scenarios need to be taken into account when computing the total diskspace required for storing LIFs.

Another consideration on the storage of LIF files is the large number of concurrentrandom reads and writes, 30GB daily data size (EDDS) can saturate the IOcapabilities of two 7200RPM SATA-2 disks configured in RAID-1.

ConfigurationDepending on the configuration, the disks holding the LIFs can reside on theLoader server (s).

Alternatively, 1 LUN is exported from the disk array created in the previous stepmounted to /appl/virtuo/var/loader/spool.

Alternatively, 1 LUN is created for each Technology Pack or datasource andmounted to /appl/virtuo/var/loader/spool/<techpack or datasource>.

HardwareSeveral large SATA-2 disks configured in RAID-1 or RAID-10 (depending on sizeand configuration).

Gateway files (raw files)Raw files are generated on the gateways, converted to LIF files and transferred tothe application server. They should be maintained on the gateway until the day'sdata has been successfully loaded into the database. Raw, gateway files should beplaced on RAID-1 devices.

The gateways are installed in $WMCROOT/gways. All gateway framework files residein the directory: $GATEWAY_ROOT.

Each gateway has spool directories configured for input files, intermediate files,and loader files.v IN_DIR=/spool/input_d

v INT_DIR=/spool/inter_d

v OUT_DIR=/spool/output_d

Spool directories should be separated from the main installation directory to avoidmemory issues as spool directories grow. The above example assumes that spooldirectory is created from root directory.


Disk layout on the database serverA list of the minimum disk requirements for the Database component is providedin the following table. The minimum files system sizes that are provided are only aminimum and the file systems are sized according to the customers-specificrequirements.

Details on the RAID type and LUN setup that is required for each filesystem anddata file type are given in the previous sections.

Table 5. Minimum disk requirements

Filesystem Software Typical SizeMinimum DisksRequired RAID Type

/ Operatingsystem

8 GB 2

(typically oninternal disks)

1

swap Operatingsystem

8 GB

/var Operatingsystem

8 GB

/appl Oracle andTivoli NetcoolPerformanceManager

24 GB

/export/home User homeaccounts

2 GB

/data/trace_log1

Trace loglocation

8 GB

/data/trace_archive1

Trace archivelocation

8 GB

/oralogs1 Oracle redo loglocation 1

8 GB 2 1

/oralogs2 Oracle redo loglocation 2

8 GB 2 1

/oradata01 Oracle storagelocation 1(typical size -400 GB)

32 GB (min) 4

(Typically manymore dependingon the estimatedsize of theDatabase.

Total size iscalculated basedon output forsizing report)

1+0

/oradata02 Oracle storagelocation 2(typical size -300 GB)

32 GB (min)


Table 5. Minimum disk requirements (continued)

Filesystem Software Typical SizeMinimum DisksRequired RAID Type

/oradata03 Oracle storagelocation 3

((DBSize –700G)*0.5)

32 GB (min)

/oradata04 Oracle storagelocation 4

((DBSize –700G)*0.5)

32 GB (min)

/oradump/archivelogs

Oracle Archivelog location(SATA disks)

(RequiredArchive logsspace is 50 *EDDS)

100 GB (min) 2 Disks forRAID-1

Or

4 Disks forRAID-10

(Typically manymore dependingon the estimatedsize of theDatabase)

1+0

/oradump/backups

Oracle backuplocation (SATAdisks)

(Requiredbackup spacemust be 1.2 *database Size)

100 GB (min) 2 Disks forRAID-1

Or

4 Disks forRAID-10

(Typically manymore dependingon the estimatedsize of theDatabase)

1+0


Chapter 5. System configuration

Filesystem, network and database configurations.

Filesystem and SAN configurationThe following are suggested filesystem and SAN configurations:v On Linux, all Database server filesystems should be configured with filesystem

type ext3. For performance reasons, access time logging for files and directoriesshould be removed (defaults, noatime, nodiratime).

v ext3 supports three types of journaling modes:v Journal - has higher performance overhead.v Ordered - is the default setting and suggested option.v Writeback - provides the fastest access to the data at the expense of data

consistency.v On Solaris, all database filesystems (/oradata*, /oralogs* and /oradump) should

be configured as UFS, while all other application-related filesystems (/, /appland /opt) should be configured as ZFS.

v A minimum of 2GB of cache is required per fiber channel controller.v Direct-IO should be enabled for Oracle by setting the Oracle

filesystemio_options parameter:filesystemio_options = setall

v Individual SAN LUNs should be created for each /oradata01..04 filesystem, witha minimum Stripe/Segment Size of 512KB and RAID Type 1+0 (mirroring andstriping).

v Oracle redo logs (oralogs1 and oralogs2) should be placed on separate LUNs.

Network configurationThe following are suggested network configurations:v In gigabit networks, large maximum transmission units (MTU) sizes (also known

as JumboFrames) can provide better network performance. To transfer largeamounts of data at gigabit speeds increasing the default MTU size can providesignificant performance gains. A sample MTU Jumbo size is 9000.

v The Underlying IP Network should support 1GB/s transfer rates.

Database configurationDatabase memory, database redo logs and database temporary tablespaceconfigurations.


Database memory configurationThe main memory components for Oracle are:v SGA (Shared Global Area)v PGA (Program Global Area)

Both parameters depend on the amount of data loaded each day into the databaseand are calculated as part of the Dimensioning procedure.

8 GB of the target server must be reserved for the OS and background tasks.

SGAThe SGA is calculated as part of the Dimensioning procedure. The Dimensioningprocedure estimates the amount of daily loaded data (EDDS - Estimated DailyDatabase Size) based on network size. The SGA is then calculated at 1.3 * EDDS.

The SGA is made up of two main components, SHARED_POOL_SIZE andDB_CACHE_SIZE.v DB_CACHE_SIZE - for optimal performance, store a full day of data in to the

database cache. Because of the load patterns, an undersized database cachecould result in a doubling of most IOs, and a READ bottleneck on the /oradata*filesystems during loading, especially later in the day.

For the re-sizing of an existing system, the required database buffer cache can becomputed from the size of the daily partitions of a running system.v SHARED_POOL_SIZE - for Tivoli Netcool Performance Manager, a minimum of 3GB

should be configured for the SHARED_POOL_SIZE.

Automatic shared memory management:

Automatic Shared Memory Management (ASMM) is Oracle automatic managementof SGA memory.

Important: ASMM must not be used with Tivoli Netcool Performance Managerbecause of Tivoli Netcool Performance Manager use of generated SQL and becausememory would not be used optimally on the system workloads.

The SGA value that is an output from the Dimensioning procedure is the total sizeof SGA. ASMM is configured ON by default in Tivoli Netcool Performance Managerand must be turned OFF after installation. To do this, the total size of the SGA mustbe divided into specific SGA parameters that is buffer cache and shared pool size.

The following table provides an example of SGA parameter settings that are usedfor a server, dedicated to the database, with 128 GB RAM, 80 GB SGA and 40 GBPGA (8 GB of the total RAM is reserved for the OS).

Table 6. Breakdown of database SGA parameters

Parameter Setting Details

sga_max_size 81920M Set by Oracle to total SGAsize.

sga_target 0 Disables ASMM when set to0.

shared_pool_size 3G Set to at least 3 GB.


Table 6. Breakdown of database SGA parameters (continued)


db_cache_size 77G Available buffer pool cachememory.

log_buffer 256M Dependent on systemresources and load activity.

Normally 11 - 400 MB.

java_pool_size 100M Set to 100M for Java pool.

large_pool_size 100M Set to 100M for large pool.

To disable ASMM, run the following commands connected to the database withSYSDBA privileges:ALTER SYSTEM SET sga_target=0 SCOPE=spfile sid='*';ALTER SYSTEM RESET sga_max_size SCOPE=spfile sid='*';

ALTER SYSTEM SET db_cache_size=<db_cache_size> SCOPE=spfile sid='*';

ALTER SYSTEM SET shared_pool_size=<shared_pool_size_at_least3G>SCOPE=spfile sid='*';

ALTER SYSTEM SET large_pool_size=100M SCOPE=spfile sid='*';ALTER SYSTEM SET java_pool_size=100M SCOPE=spfile sid='*';

The database must be restarted to enable these changes.

PGA: PGA is used by Oracle for sorting data for individual sessions. Normallythe PGA is set to approximately 20% of the SGA. Because of the amount of largesorts on a typical Tivoli Netcool Performance Manager database, the PGA shouldbe set to approximately 25% of the database cache.

The following table provides an example of PGA parameter settings used for aserver, dedicated to the database, with 128GB RAM, 80GB SGA and 40GB PGA(8GB of the total RAM is reserved for the OS).

Table 7. Breakdown of PGA parameters


pga_aggregate_target 40G Target aggregate PGAmemory available to allserver processes.

Database redo logsOracle redo logs record all changes to the datafiles. The normal redo log setupconsists of 5 groups, with each group having 2 members. These members are splitbetween the two locations, /oralogs1 and /oralogs2.

5 redo log groups are normal for systems that are going to be setup in archive logmode. This is suggested when the system is being backed up.

The size of the redo logs depends on the amount of activity on the system. It isusual for redo log groups switching once every 20 minutes. The size of the systemwill affect the switching frequency.

Chapter 5. System configuration 21

For small to medium systems, the redo logs can be set between 400 MB and 1G foreach member. This results in 400 MB * 2 members * 5 groups => 4 GB. This 4 GB isdivided evenly between /oralogs1 and /oralogs2.

For a larger system, the redo logs can be sized at 3 GB each for each member. Theresults in 3 GB * 2 members * 5 groups => 30 GB. This 30 GB is divided evenlybetween the /oralogs locations.

The configuration and sizing of the database redo logs are updated and deliveredto the customer in a customer database template, vtdb_<customer_name>.dbt.

See section “Update customer database template” on page 34, for information onupdating the database redo logs with the correct sizings and locations.

Database temporary tablespaceOracle temporary tablespaces are used to manage space for database sortoperations and for storing global temporary tables. If a large sort operation cannotfit in memory, then space will be allocated in a temporary tablespace for doing thesort operation.

In Tivoli Netcool Performance Manager , large reports or complex summaries,which join across a number of large tables will require a large temporarytablespace. A suitably sized TEMP tablespace is 80 GB-100 GB.

Application server configurationOn the Application Server component, JBoss must be configured with 3 GB of Javaheap space (“–Xms3G –Xmx3G”). This setting can be configured in the file:

$WMCROOT/conf/as/jvm-default.ini.

To change the setting to 3G, make the following update to the jvm-default.inifile:-Xms3G -Xmx3G -XX:+AggressiveHeap -XX:MaxPermSize=96m

The Tivoli Directory Service, which is required for LDAP authentication andauthorization, uses approximately 2 GB of Random Access Memory (RAM), otherTivoli Netcool Performance Manager Java processes use approximately 2 GB.

An additional 8 GB RAM must be reserved for the OS and background tasks.

Loader configurationThe number of loaders to configure on a system depends on the number oftechnology packs and the amount of data to load on the system.

There is a minimum of one loader per datasource, and in most cases twodatasources per technology pack:v The Performance Counter datasourcev The Hierarchy datasource

Certain technology packs, such as the Ericsson UTRAN Technology Pack, haveadditional datasources, for example, the PDF counter datasource in the EricssonUTRAN Technology Pack.


Most small datasources (such as the hierarchy datasource or the performancecounter datasource for small technology packs with few entities), only require onesingle-threaded loader with 512 MB to 1 GB of memory. For example, JVMarguments: “–Xms1G –Xmx1G”.

Larger datasources require the use of one or more multithreaded loaders. Forexample, it is possible to configure one multithreaded loader with 2 LIF-parserthreads and 4 DB-writer threads for each 10000 cells of an average technologypack. Each such loader will require more memory as they will be processingseveral LIFs in parallel. For example, “–Xms3G –Xmx3G” to configure 3 GB ofmemory.

The following list gives an example of a possible configuration for a system with20000 Nokia UTRAN cells and 10000 Ericsson cells with PDF counters. Theinformation about memory requirements are provided from the Dimensioningprocedure, and depend on the actual network size, the load interval, (for example,15 minutes) and the percentage of counters that are loaded.

Nokia hierarchy One single threaded loader with 512 MB RAMNokia PM Two multithreaded loaders with 3 GB RAM eachEricsson hierarchy One single threaded loader with 512 MB RAMEricsson PM One multithreaded loader with 3 GB RAMEricsson PDF One multithreaded loader with 3 GB RAM

In this example, the system would consist of a total of six loaders and 13 GB ofRAM.

The following must also be set:v The ’insert.max.batch’ size from the lc_loader_config_properties table must

be set to the default value of 5000.v You must leave an additional 8 GB of RAM for the OS and background tasks.v

– For loaders allow 0.2 GB of memory for every 1 GB of data going into thedatabase each day (EDDS). Minimum memory per loader (for example, forsmall hierarchy loaders) is 400 MB.

Gateway configurationThe Gateway framework uses the following configuration files. They reside in thevstart directory:v EngineConfig.pm – configuration file of the first stage of the Gateway.v UserConfig.pm – a user configurable Perl module for configuring the Gateway

Post Parser.v TransferConfig.pm – configures the transfer in of raw files and transfer out of

processed LIF files.v Gateway_start.sh – this script is used to start the Gateway.

Within the Gateway configuration, there are configuration directories for everyvendor subsystem and data revision. They are contained within a directory calledconfig. The contents of these directories are described below:v The docs directory contains documentation on the configuration for each vendor

data revision supported.v The configuration directories are named based on the vendor sub-system, for

example ericsson-bss.


Within each vendor sub-system directory, there are directories for each datarevision supported. For example, r12_ascii, r12_asn1. These directories contain theconfiguration files that are to be referenced by the Gateway framework to parsethe vendor data accordingly. For example, EngineConfig.pm, UserConfig.pm,StatisticsConfig.pm, TransferConfig.pm, NotificationConfig.pm.

The StatisticsConfig.pm, TransferConfig.pm and NotificationConfig.pm files canbe obtained from the Gateway framework example directory. If the StatisticsConfiguration is configured, the file_statistics and block_statistics directorymust be created manually by the user, and the path that is specified in theStatisticsConfig.pm.

Configuration of properties filesThe following are some of the environment variables that are required in theproperties file for each Gateway configuration:v LOG_LEVEL - specifies the log level that was previously defined in

gateway_start.sh.v LOG_FILE - specifies the path and file name of the log file that was previously

defined in gateway_start.sh.v MAX_NUMBER_OF_PROCESSES - specifies the number of Gateway processes allowed

to be spawned for multiple independent blocks configured in the UserConfig.pm.By default, this variable must be set to 1.

Configuration of environment variablesThe following environment variables must be set:v GATEWAY_ROOT: the base path to where all Gateway components are installed.

GATEWAY_ROOT=${WMCROOT}/gways

v TZ: the time zone as defined in RFC 822

Universal: GMT, UTUS zones : EST, EDT, CST, CDT, MST, MDT, PST, PDTMilitary : A to Z (except J)Other : +HHMM or -HHMMISO 8601 : +HH:MM, +HH, -HH:MM, -HH

v PERL5_BASE: the full path to where Perl base is installed, which contains the binand lib directories.PERL5_BASE=/usr

v PERL5: the path of the perl command, which is normally in the bin directory ofPERL5_BASE. If it is not in the bin directory, it must be set.

Configuration of spool directoriesCreate the spool directories for input files, intermediate files, and loader files. Setthe directories in the properties file for the variables below:v IN_DIR=/spool/input_d

v INT_DIR=/spool/inter_d

v OUT_DIR=/spool/output_d

The spool directories must be separated from the main installation directory toavoid memory issues as spool directories grow. The above example assumes thatspool directory is created from root directory.


High availabilityThis solution helps to deploy and configure the IBM Tivoli Netcool PerformanceManager for Wireless component in a high availability configuration using TivoliSystem Automation for Multiplatforms.

You can configure the components of Tivoli Netcool Performance Manager such asDatabase, Application Server, Loader and Gateways for 1+1 topology using theattached policies and deployment guide.

For details see:

https://www-304.ibm.com/software/brandcatalog/ismlibrary/details?catalog.label=1TW10NP59

Tivoli Integrated Portal and Tivoli Common ReportingInstallation and configuration of Tivoli Integrated Portal and Tivoli CommonReporting is fully documented within the IBM Tivoli Netcool Performance Manger:Wireless Installation Guide and upgrade procedures are covered in the IBM TivoliNetcool Performance Manger: Wireless Upgrade Guide.

ModelingThe installation, configuration and usage of the Model Maker tooling is describedin the Model Maker 1.2.0 Installation and User Guide. This guide also coversinstallation and usage of the Common Pack Service tooling.

IBM Tivoli MonitoringIBM Tivoli Monitoring monitors and optimizes hardware and applicationperformance. The IBM Tivoli Monitoring application operates by deploying agentsto monitor the performance of target systems and to relay the data back to the IBMTivoli Monitoring system, where it can be stored and reported on.

Details of installing the IBM Tivoli Monitoring agents and using them with IBMTivoli Netcool Performance Manager are covered in the ITM Agent Install and UserGuide.

Details of how to integrate Tivoli Netcool Performance Manager with IBM TivoliMonitoring are covered in the ITM Integration Guide. This document also providesinstructions on how to deploy the following Tivoli Netcool Performance Manageragents on IBM Tivoli Monitoring:v Application serverv Loadersv Gateways





Chapter 6. Backup strategy

A database and filesystem backup strategy is required for backing up the TivoliNetcool Performance Manager system. Frequent Tivoli Netcool PerformanceManager production database backups must be taken. The frequency of databasebackups is determined by customer data backup policy and hardware availability.

It is important to backup the Oracle database regularly. Backups of the databaseshould be taken more often than backups of the system.

Database backupsDatabase backup is an important process that is initiated and carried out on theTivoli Netcool Performance Manager platform on a regular basis. Data is constantlybeing read from, and written to, the Oracle database. Procedures must be in placeto backup and archive the data correctly.

Database backup storageTwo disk areas should exist on the database server where files related to databasebackups are stored.v /oradump/archivelogs – mount point mounting an appropriate LUN exported

from dedicated RAID-10 disk array of large SATA disks, where Archive log filesare accumulated between database backup image recovery cycles.

The database during normal operation generates tens of gigabytes of Archive logfiles per day. As result a large disk volume is required to store them.v /oradump/backups – mount point mounting an appropriate LUN exported from

dedicated RAID-10 disk array of large SATA disks, where a database backupimage is stored.

To store a backup copy, sufficient amount of disks should be allocated to store filesapproximately of the same size as the total database size + 10%.

Database backup proceduresFrequent database backups must be taken. The frequency of database backups isdetermined by customer data backup policy and hardware availability.

The database backup approach that is outlined below is based on the use of theOracle Recovery Manager (RMAN) that is a part of the Oracle Server software. Fordetailed information about the Oracle Recovery Manager read the Oracledocumentation, ref Oracle Database Backup and Recovery Reference, 11g Release 2 (11.2)at http://www.oracle.com/technology/documentation/index.html.

The following database backup approach consists of a number of activities thatwill allow the recovery of database functionality and data in the event of hardwarefailure.


http://www.oracle.com/technology/documentation/index.html

Prerequisitesv The database is running in ARCHIVELOG mode.v Disk space to store Archive log files is sufficient and available on a database

server; an appropriate LUN is mounted to /oradump/archivelogs mount point.v Disk space sufficient to store one full copy of a database is available on a

database server; an appropriate LUN is mounted to /oradump/backups mountpoint.

Database backup activities1. At the start of a Tivoli Netcool Performance Manager application production

cycle, a full database backup is taken with RMAN. Database file images arestored in a database backup copy directory: /oradump/backups.

2. Between backup image recovery cycles Archive log files are generated by thedatabase and stored in the directory: /oradump/archivelogs.

3. At the start of each backup image recovery cycle, newly generated and unusedArchive log files are applied to a backup copy of the To protect the TivoliNetcool Performance Manager system from loss of data, regular filesystembackups must be made in addition to backing up the Oracle database. database.After successful application of these files, previously applied Archive log filescan be removed from disk to create more space for the new Archive log files.

4. A database backup copy can be copied to tape by using the normal OS filesbackup procedures or Oracle RMAN, further securing customer data.

Filesystem backupTo protect the Tivoli Netcool Performance Manager system from loss of data,regular filesystem backups must be made in addition to backing up the Oracledatabase.

The following filesystems must be included in the backup:v /

v /var

v /opt

v /appl

v /export/home

v /data/trace_log1

v /data/trace_archive1

A backup schedule must include full and incremental backups of these filesystems.Ensure that the backup media are correctly labeled and stored in a secure location,and that the integrity of the backups is checked periodically.


Cold standbyA cold standby is a system which can, with a small amount of configuration, takeover from your existing Tivoli Netcool Performance Manager wireless system if afailure occurs.

A Tivoli Netcool Performance Manager wireless cold standby mirrors theinfrastructure of your existing Tivoli Netcool Performance Manager wirelesssystem. Should your existing Tivoli Netcool Performance Manager wireless systemexperience a serious error, you can quickly configure the cold standby to act asfailover.

The steps that are required to set up a cold standby are described in detail in theIBM Tivoli Netcool Performance Manager: Wireless Administration Guide for v!.3.2.

Chapter 6. Backup strategy 29


Chapter 7. Other topics

Memory allocationThe following are the guidelines for memory allocation.v For loaders allow 0.2 GB of memory for every 1 GB of data going into the

database each day (EDDS). Minimum memory per loader (for example, for smallhierarchy loaders) is 400 MB.

v For the various application server processes allow 7 GB.v For the database server allow 1.3 GB of SGA memory and 0.3 GB of PGA

memory per 1 GB EDDS.v For the gateways the memory requirement is small.12 GB is sufficient for each

server.v For the operating system, allow 8 GB.

Sizing database OS partitionsThe following is an example layout of tablespaces and disk partitions for a largesystem.v /oradata01 - holds the system tablespaces, temporary tablespace, and smaller

application tablespaces. Their sizes are relatively static.v /oradata02 - holds the Undo tablespace. This must be kept separate from the

other tablespaces, especially Traffic tablespaces, to avoid contention,.v /oradata03 and /oradata04 - hold all Traffic tablespaces. Can be sized only by

getting information of the Technology Pack tables, customer data and volume ofdata per day. This must be obtained from the Dimensioning procedure.

v /oradump - holds Archive logs when the database is in archive log mode. This iscustomer data dependent and depends on the backup policy that isimplemented by the customer.

Table 8. Layout of tablespaces and disk partitions

Disk Partition Tablespaces Tablespace Size (GB) Disk size (GB)

/oradata01 SYSTEM 66

SYSAUX 66

WM_CLIENT 20

WM_FLEXPM 20

WM_SA 20

WM_QUEUES 20

ENTERPRISE 20

TEMP 80

Total disk size 400

/oradata02 UNDO 100

Total disk size 300

/oradata03 TRAFFIC_SMALL <data dependent>

TRAFFIC_MEDIUM <data dependent>

TRAFFIC_LARGE <data dependent>


Table 8. Layout of tablespaces and disk partitions (continued)

Disk Partition Tablespaces Tablespace Size (GB) Disk size (GB)

Total disk size xxx

/oradata04 TRAFFIC_JUMBO <data dependent>

TRAFFIC_JUMBOPLUS<data dependent>

Total disk size xxx

/oralogs1 redo log group1,member a

3 (range 1-3GB)

redo log group2,member a

3 (range 1-3GB)


3 (range 1-3GB)


3 (range 1-3GB)


3 (range 1-3GB)

Total disk size 70

/oralogs2 redo log group1,member b

3 (range 1-3GB)

redo log group2,member b

3 (range 1-3GB)


3 (range 1-3GB)


3 (range 1-3GB)


3 (range 1-3GB)

Total disk size 70

/oradump Archive logs andbackups

<data dependent>

Total disk size xxx

The configuration and sizing of the database tablespaces are updated anddelivered to a customer in a customer database template:vtdb_<customer_name>.dbt.

See “Update customer database template” on page 34, for information aboutcreating and updating a customer's database template with the correct sizings andlocations.


Sizing database extentsTivoli Netcool Performance Manager systems are deployed with a database, whichcontains 5 default tablespaces for holding traffic data. These tablespaces are asfollows:v TRAFFIC_SMALLv TRAFFIC_MEDIUMv TRAFFIC_LARGEv TRAFFIC_JUMBOv TRAFFIC_JUMBOPLUS

The default traffic tablespaces are configured with different extent sizes so thatdata can be stored in the correct tablespace for the associated data growth rate. Theaim is to ensure that data is stored in the database for efficient data access anddata storage. Tables must be stored in tablespaces with appropriate extent sizes.

The default extent sizes that are shipped with a Tivoli Netcool PerformanceManager system are listed below. These must be updated to values obtained fromthe customer-specific sizing tool. One approach is to size the extents so that thereis a maximum of 10 extents that are created per day so the extent size would be1/10 of the table growth rate per day:

TRAFFIC_JUMBOPLUS 1024 KBs (1 MB)TRAFFIC_JUMBO 512 KBs (0.5 MB)TRAFFIC_LARGE 256 KBs (0.25 MB)TRAFFIC_MEDIUM 256 KBs (0.25 MB)TRAFFIC_SMALL 128 KBs (0.125 MB)

For example, with the above mentioned default extent sizes, if a table is stored inTRAFFIC_JUMBOPLUS, each table and/or table partition is allocated 1 MB. When anew partition is created, it is created with an initial size of 1 MB. Also, when datais loaded into the table and the table grows, it grows in chunks of 1 MB extents.

It is important to correctly size the extent sizes before deploying a Tivoli NetcoolPerformance Manager system. Oversizing a tablespace extent results in wasted diskspace. Undersizing a tablespace extent results in the system continually having tocreate extents and so can be inefficient. One method for estimating the extent sizeis to use the Technology Pack Dimensioning Tool.

The Technology Pack Dimensioning Tool can be used to calculate the estimateddaily tablespace size per table. This list of tables can then be split into 5 groups oftables and used to determine the boundaries for each tablespace and the optimalextent size.

After the 5 extent sizes are calculated, they can be used to update the uniAllocSizeparameter that is associated with the TablespaceAttributes section, for eachtablespace in a customer's vtdb.dbt database template. The following is anexample of the TablespaceAttributes for the TRAFFIC_SMALL tablespace. Notethe <uniAllocSize unit="KB"> line. This is the value that needs to be updated tothe correct extent size:

<TablespaceAttributes id="TRAFFIC_SMALL"><online>true</online><offlineMode>1</offlineMode><readOnly>false</readOnly><temporary>false</temporary><defaultTemp>false</defaultTemp>

Chapter 7. Other topics 33

<undo>false</undo><local>true</local><blockSize>-1</blockSize><allocation>2</allocation>

<uniAllocSize unit="KB">128</uniAllocSize>

<initSize unit="KB">-1</initSize><increment unit="KB">-1</increment><incrementPercent>-1</incrementPercent><minExtends>-1</minExtends><maxExtends>-2</maxExtends><minExtendsSize unit="KB">-1</minExtendsSize><logging>true</logging><recoverable>false</recoverable><maxFreeSpace>0</maxFreeSpace><autoSegmentMgmt>false</autoSegmentMgmt><bigfile>false</bigfile><datafilesList>

<TablespaceDatafileAttributes id="/oradata02/{DB_UNIQUE_NAME}/traffic_small01.dbf"><id>-1</id>

</TablespaceDatafileAttributes></datafilesList>

</TablespaceAttributes>

Additionally, for each Technology Pack that is to be loaded on a Tivoli NetcoolPerformance Manager system, each table must be assigned to an appropriatetablespace. A table must be assigned to a tablespace, where there will be no morethan ten extents created per day.

A method for determining default extent sizes and for deciding which tablespacemust be used for a table is described in the Dimensioning procedure.

When new extent sizes are determined, they might be changed on the system byediting the customer database template vtdb.dbt file. This must be done atinstallation time, before the database is created. See “Update customer databasetemplate.”

Setting the database block sizeTivoli Netcool Performance Manager uses one block size for the database, 16 KB.This size is set while you create the database and cannot be changed for thelifetime of the database.

Multiple block sizes must not be used. Multiple blocks sizes are used by Oracle forextracting, transforming and/or loading data from a transactional system to a datawarehouse. Multiple block sizes must not be used within the Tivoli NetcoolPerformance Manager application.

Update customer database templateA customer database template vtdb_<customer_name>.dbt is used to create acustomer Oracle database with the appropriate memory settings, tablespace sizes,and data file locations. The Oracle Database Configuration Assistant($ORACLE_HOME/bin/dbca) is used to create and update the customer databasetemplate.


About this task

Each customer requires a customer-specific vtdb database template that contains alldatabase sizing information, which is determined during the sizing exercise.Typical values are memory settings, tablespace sizes, data files sizes, and extentsizes.

The following are the steps that are required for modifying the current databasetemplate.

Procedure1. Copy the current vtdb.dbt file to a system with Oracle 11 installed. Copy the

file to the following location as user Oracle:/appl/oracle/product/11.2.0/db_1/assistants/dbca/templates/vtdb.dbt

2. Export your DISPLAY:$ export DISPLAY=<IP ADDRESS>:0.0

3. Run the following command to start the Oracle Database ConfigurationAssistant (DBCA) as user Oracle:$ dbca

4. Select the MANAGE TEMPLATE checkbox, and then click NEXT.5. Select the FROM AN EXISTING TEMPLATE check box, and then click

NEXT.6. Select the current VTDB template checkbox, and then click NEXT.7. Enter vtdb_<customer_name>_prod as the template name, and then click NEXT.8. Select the USE DATABASE FILE LOCATIONS FROM TEMPLATE checkbox,

and then click NEXT.9. Leave the defaults, and click NEXT.

10. Leave the defaults, and click NEXT.11. Specify the SGA and PGA sizes. The default values are PGA=2 GB and SGA=2

GB. These values vary depending on the size of the system and the outcomeof the sizing exercise. Click NEXT. See section “Manually setting memoryparameters” on page 36 for sizing PGA and SGA.

12. Go through each of the tablespaces and resize them to the size from theoutput of the sizing exercise. Ensure the extent sizes, locations, and totaltablespace sizes are correct. The max data file size must be 20 GB andmultiple data files can be added to a tablespace to increase it in size to thetarget size, in multiples of 20GB. The extent sizes, file locations, andtablespace sizes must be determined during the sizing exercise.

Note: By default Autoextend is set to ON, this must be taken in to accountwhen you do sizing and create tablespaces.

13. If required, change the storage parameters of each datafile that is associatedwith each tablespace and set the autoextend values for each datafile.a. Select STORAGE > DATAFILES .b. Click the data file you want to modify.c. Select the STORAGE tab of the data file in the right side of the screen.d. Set the size of the data file and setting AUTOEXTEND on, and setting the

max size of the data file.14. Click NEXT.15. Click FINISH.

A new database template file is created:


/appl/oracle/product/11.2.0/db_1/assistants/dbca/templates/vtdb_<customer_name>_prod.dbt

This file must be added to the client project to the configuration package in:/appl/virtuo/admin/oracle/conf/vtdb_<customer_name>_prod.dbt

This file name must be added to the install template for the client so that it ispicked up automatically by the installation.

Manually setting memory parametersYou set the PGA and SGA memory in the database template,vtdb_<customer_name>.dbt.

Memory parameters must be set correctly for performance reasons. Theseparameters must be obtained from the sizing exercise.

As a guideline, the PGA can be allocated 30% of the total memory available to thedatabase. The SGA can be allocated 70% of the total memory available to thedatabase. For a system with a separate database, 8 GB of the total memoryavailable must be reserved for the OS before the PGA and SGA settings aredetermined. If the application is also on this system, reserve an additional 7 GB forthe application and the calculated memory required for the Loaders.

To update the PGA setting in the customer database template, update thefollowing line:<initParam name="pga_aggregate_target" value="xxx" unit="MB"/>

To update the SGA settings in the customer's database template, update thefollowing lines:v Automatic Shared Memory Management (ASMM) is currently set to ON in the

vtdb.dbt. This should be set to OFF in all Tivoli Netcool Performance Managerproduction systems. Set ASMM to off by setting SGA_TARGET=0:

<initParam name="sga_target" value="0" unit="MB"/>

v For SGA, as a guideline 3 GB can be allocated for SHARED_POOL_SIZE and theremaining space can be allocated to DB_CACHE_SIZE (minus large_pool_size andjava_pool_size of 100 M each).

Specify the following settings to the size that is determined by the sizing exercise:<initParam name="shared_pool_size" value="????" unit="MB"/><initParam name="large_pool_size" value="100" unit="MB"/><initParam name="java_pool_size" value="100" unit="MB"/><initParam name="db_cache_size" value="????" unit="MB"/>

Manually setting tablespaceTablespace sizes are set in the database template, vtdb_<customer_name>.dbt. Themaximum size of a data file must not exceed 20 GB. This is for easier filemanagement and backing up. If the size of a tablespace is greater than 20 GB, youmust create multiple data files of 20 GB each, and associate these data files withthe tablespace.

About this task

To set the tablespace, you update the vtdb_<customer_name>.dbt in two steps. Thefirst step is to add the additional data files, and the second step is to add the datafiles to the tablespace. You might set the tablespace for most traffic tablespaces.


Procedure1. Add more <DatafileAttributes> sections for the extra datafiles, for example

temp02.dbf, temp03.dbf, temp04.dbf:<DatafileAttributes id="/oradata01/{DB_UNIQUE_NAME}/temp01.dbf"><tablespace>TEMP</tablespace><temporary>false</temporary>;<online>true</online><status>0</status><size unit="MB">2048</size><reuse>true</reuse><autoExtend>true</autoExtend><increment unit="MB>100</increment><maxSize unit="MB">20480</maxSize></DatafileAttributes><DatafileAttributes id="/oradata01/{DB_UNIQUE_NAME}/temp02.dbf"><tablespace>TEMP</tablespace><temporary>false</temporary><online>true</online><status>0</status><size unit="MB">2048</size><reuse>true</reuse><autoExtend>true</autoExtend><increment>unit="MB">100</increment><maxSizeunit="MB">20480</maxSizev</DatafileAttributes><DatafileAttributes id="/oradata01/{DB_UNIQUE_NAME}/temp03.dbf"><tablespace>TEMP</tablespace><temporary>false</temporary><online>true</online><status>0</status><size unit="MB">2048</size><reuse>true</reuse><autoExtend>true</autoExtend><increment unit="MB">100</increment><maxSize unit="MB">20480</maxSize></DatafileAttributes><DatafileAttributes id="/oradata01/{DB_UNIQUE_NAME}/temp04.dbf"><tablespace>TEMP</tablespace><temporary>false</temporary><online>true</online><status>0</status><size unit="MB">2048</size><reuse>true</reuse><autoExtend>true</autoExtend><increment unit="MB">100</increment><maxSize unit="MB">20480</maxSize></DatafileAttributes>

2. Add the new data files to the appropriate tablespace, in<TablespaceAttributes>:<TablespaceAttributes id="TEMP"><online>true</online><offlineMode>1</offlineMode><readOnly>false</readOnly><temporary>true</temporary><defaultTemp>true</defaultTemp><undo>false</undo><local>true</local><blockSize>-1</blockSize><allocation>1</allocation><uniAllocSize unit="KB">-1</uniAllocSize><initSize unit="KB">64</initSize><increment unit="KB">64</increment><incrementPercent>0</incrementPercent><minExtends>1</minExtends><maxExtends>0</maxExtends>


<minExtendsSize unit="KB">64</minExtendsSize><logging>true</logging><recoverable>false</recoverable><maxFreeSpace>0</maxFreeSpace><autoSegmentMgmt>true</autoSegmentMgmt><bigfile>false</bigfile><datafilesList><TablespaceDatafileAttributes id="/oradata01/{DB_UNIQUE_NAME}/temp01.dbf"><id>-1</id></TablespaceDatafileAttributes><TablespaceDatafileAttributes id="/oradata01/{DB_UNIQUE_NAME}/temp02.dbf"><id>-1</id></TablespaceDatafileAttributes><TablespaceDatafileAttributes id="/oradata01/{DB_UNIQUE_NAME}/temp03.dbf"><id>-1</id></TablespaceDatafileAttributes><TablespaceDatafileAttributes id="/oradata01/{DB_UNIQUE_NAME}/temp04.dbf"><id>-1</id></TablespaceDatafileAttributes></datafilesList></TablespaceAttributes>


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 inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user's responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not give youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785 U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan, Ltd.19-21, Nihonbashi-Hakozakicho, Chuo-kuTokyo 103-8510, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE.

Some states do not allow disclaimer of express or implied warranties in certaintransactions, therefore, this statement might not apply to you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Websites. The materials at those Web sites are not part of the materials for this IBMproduct 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 itbelieves appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758 U.S.A.

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 materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurement may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrate programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment toIBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operatingplatform for which the sample programs are written. These examples have notbeen thoroughly tested under all conditions. IBM, therefore, cannot guarantee orimply reliability, serviceability, or function of these programs. You may copy,modify, and distribute these sample programs in any form without payment toIBM for the purposes of developing, using, marketing, or distributing applicationprograms conforming to IBM‘s application programming interfaces.


If you are viewing this information in softcopy form, the photographs and colorillustrations might not be displayed.

TrademarksIBM, the IBM logo, and ibm.com are trademarks or registered trademarks ofInternational Business Machines Corp., registered in many jurisdictions worldwide.Other product and service names might be trademarks of IBM or other companies.A current list of IBM trademarks is available on the Web at “Copyright andtrademark information” at http://www.ibm.com/legal/copytrade.shtml.

Adobe, Acrobat, PostScript and all Adobe-based trademarks are either registeredtrademarks or trademarks of Adobe Systems Incorporated in the United States,other countries, or both.

Cell Broadband Engine and Cell/B.E. are trademarks of Sony ComputerEntertainment, Inc., in the United States, other countries, or both and is used underlicense therefrom.

Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo,Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks orregistered trademarks of Intel Corporation or its subsidiaries in the United Statesand other countries.

IT Infrastructure Library is a registered trademark of the Central Computer andTelecommunications Agency which is now part of the Office of GovernmentCommerce.

ITIL is a registered trademark, and a registered community trademark of the Officeof Government Commerce, and is registered in the U.S. Patent and TrademarkOffice.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States, other countries,or both.

Linux is a trademark of Linus Torvalds in the United States, other countries, orboth.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Notices 41

http://www.ibm.com/legal/copytrade.shtml


��

Printed in USA

Documents

IBMTivoli Netcool Performance Manager 1.3.2 Wireless ... · v Tivoli Netcool Performance Manager 1.3.1 or later, Technology Packs. v IBM System x hardware. v Sun Microsystems and