Table Of Contents

Configuring the SCM

Integrated SCM

Standalone Statistics Manager

Standalone Statistics Collector

Combining SCMs, SSMs, and SSCs

Configuring Collection Functions

SCMProxy

SCMGateway.conf

Setting Up SCM Configurations

Using the SCMGateway.conf File

Configuring the SCM

---

This appendix describes how to configure the CWM Statistics Collection Manager (SCM) software, which comprises these three major modules:

•Integrated Statistics Collection Manager (Integrated SCM)

•Standalone Statistics Manager (SSM)

•Standalone Statistics Collector (SSC)

These modules can be configured in various ways for high performance and redundancy to meet your needs. See these sections:

•Integrated SCM

•Standalone Statistics Manager

•Standalone Statistics Collector

•Combining SCMs, SSMs, and SSCs

•Configuring Collection Functions

•Setting Up SCM Configurations

•Using the SCMGateway.conf File

Integrated SCM

The Integrated SCM resides and operates on the same machine as the CWM server. When the CWM is installed, the Integrated SCM is installed automatically. The Integrated SCM consists of the following components:

•Statistics Controller—Manages statistics collection

•Statistics Collector—Performs the actual statistics collection

•Statistics Parser—Parses the statistical files into the statistics database

As of CWM 15.1.50, Patch 2, the statistics database in the SSM can have only the statsdb format and features. You cannot save statistics in stratacom in the SSM.

Standalone Statistics Manager

The Standalone Statistics Manager (SSM) resides on a separate machine from the CWM machine. It is installed independently of the CWM with the SSM/SSC CD. This separation of the SSM application results in better performance by using a dedicated machine. Figure A-1 shows a system consisting of one CWM and one SSM.

Communication between the CWM and the SSM is through WANDEST. A WANDEST Server resides on the CWM machine, and a WANDEST Client resides in the SSM machine. The WANDEST Client is part of the SSM and is installed automatically when the SSM is installed. Because the WANDEST Server is a separate Cisco product and not part of the CWM, it must be ordered and installed separately.

Figure A-1 shows no statistics functions in the CWM. The Integrated SCM exists in the CWM but is not activated. However, the Integrated SCM could be activated so that both the CWM and the SSM collect statistics.

Figure A-1 CWM with Standalone Statistics Manager

Standalone Statistics Collector

Under the control of the Statistics Controller, the SSC uses the FTP (or TFTP) facility to collect statistics from network nodes and place them in directories for the Statistics parsers to parse.

The SSC resides in a separate machine from the CWM machine and from the SSM machine. It installs independently of the CWM with the SSM/SSC CD. See Figure A-2.

With this configuration with a CWM, an SSM, and an SSC, the collection function is spread across two machines and does not use CWM resources. In this way, a greater number of nodes and connections that can be supported.

Using SSMs and SSCs, several other configuration types can improve performance and provide redundancy, as discussed later in the appendix.

Figure A-2 Standalone Statistics Collector

The figure shows how the Statistics Controller manages both the Statistics Collector and the Statistics Parser. The Statistics Controller communicates with the CWM to obtain details about network nodes. When the CWM and the Statistics Controller are in different machines, they use WANDEST (server and client) to communicate with each other. The Statistics Controller also communicates with the SCM Gateway to the network. This gateway is separate from the CWM Gateway.

The statistics are collected by the Statistics Collector, passed to the Statistics Parser, and then stored in the statistics database.

Combining SCMs, SSMs, and SSCs

SCMs, SSMs, and SSCs can be combined to meet various network needs for performance (maximum nodes and connections supported), database storage, and redundancy.

In general, these guidelines apply:

•Multiple SSMs can be configured to be primary or secondary so that a secondary SSM can take over the functions of a failed primary automatically.

•Multiple SSMs and SSCs can be configured so they duplicate each other's functions. For example, two SSCs can be collecting statistics from the same nodes at the same time. In this way, if one of the SSCs fails, the other SSC continues collecting statistics without interruption.

•Because the statsdb databases reside in the SSMs, multiple SSMs increase database storage capacity and provide the safety of spreading the collected statistics across several independent machines.

If each SSC collects statistics for a particular set of nodes and the statistics are stores in a single statsdb database in the SSM, no redundancy is being provided and the data is vulnerable.

•If an SSC fails, the statistics for its nodes are no longer being collected.

•If the SSM fails, all statistics collection stops.

This configuration can be changed to provide redundancy, as shown in the following examples.

Figure A-3 shows a configuration in which two SSMs are used with their own SSCs. This configuration allows for two redundancy schemes.

•In the first scheme, an SSM is designated as the primary SSM, and the other SSM is designated as the secondary SSM, which is in standby mode. The primary SSM collects statistics and stores them in its statsdb database. If it fails, the secondary takes over collection, storing statistics in its statsdb database. The statistics collected before the failure continue to reside in the primary SSM database. This arrangement requires that an SCM Gateway be configured between SSM1 and SSM2. The configuration is specified through the SCMGateway.conf file that resides in the CWM server in /usr/users/svplus/config.

•The second scheme is to have both SSMs running independently with each storing statistics in its own database through its own SSC. If the SSCs on SSM 1 and the SSCs on SSM 2 are configured to collect statistics from the same set of nodes, the result is two independent, redundant collection systems.

In an extension of this redundant setup, multiple SSCs can exist for each SSM, and each SSC can be assigned its own set of nodes.

Figure A-3 Redundant SSMs and SSCs

Configuring Collection Functions

This section describes how to configure statistics collection functions through ScmProxy and SCM gateways through the SCMgateway.conf file.

For details about configuring through the SCM GUI, please refer to the CWM user guide.

SCMProxy

ScmProxy is a software module that resides in the CWM and provides an alternative user interface to the GUI. To launch Scmproxy, you must first create a node list file that specifies the nodes from which statistics you will be collecting data. This list has the following format.

<CollParams:<templateName><primary,secondary,tertiary collsvrNames ><iprouting>>  
node_name1  
node_name2  
...  
node_nameN 
<CollParams:<templateName><primary,secondary,tertiary collsvrNames ><iprouting>>  
node_name1  
node_name2 
...  
node_nameN 
Example: 
<CollParam:<MGX8850_template><ssc1,ssc2,ssc3><inband>> 
jbpop1-1  
<CollParam:<MGX2_test><ssc3><inband>>  
UpperRed  
popeye13. 

The file consists of a number of records in which each record specifies the stats template to be used, a collection server/parser server pair, and a list of network nodes for which the servers are collecting statistics.

•template_name—This is the name of the applicable template. Statistics templates can be created from the SCM GUI and saved in StrataCom database.

•primary, secondary, tertiary collsverNames—This item specifies the names of the primary, secondary, and tertiary collection servers.

•routinginfo—This field can be in band or out of band, depending on the routing method to the nodes.

•node_name1, node_name2, etc.—These are the names of nodes the the servers are collecting statisitics from.

ScmProxy must be started from the CWM machine by typing the following:

scmproxy<nodelist_filename>

where nodelist_filename is the name that you gave to the node list file.

ScmProxy then displays a menu from which you can enable or disable statistics, start or stop collection, or exit.

SCMGateway.conf

The SCM gateways used for statistics collection are defined independently of the CWM gateways. You specify the network gateways to be used for statistics collection through the SCMGateway.conf file with the following format:

## Default: DomainGatewayList 
## Usage: DomainGateWayList tmonda dilbag sgharat 
DomainGatewayList SCM1 SCM2 SCM3

In this example, SCM1, SCM2, and SCM3 are the names of the SCM gateways.

Setting Up SCM Configurations

Use this procedure to set up SCM configurations with standalone servers.

---

Step 1 Plan the number of machines to be used for statistics collection. Determine the number for statistics management and the number for statistics collection.

Step 2 List the network nodes to be associated with each Statistics Collector.

Step 3 For each machine, install the CWM, SCM, or SCC, as appropriate. The installation is automatic on the CWM machine. For each standalone machine, choose the installation options that fit with the management plan that you developed in Step 1.

Step 4 Start the CWM.

Step 5 Using either the SCM GUI in the CWM or ScmProxy, set up the planned configuration. See the CWM user guide for details.

---

Using the SCMGateway.conf File

This section describes how to set up an SSM using the SCMGateway.conf file.

---

Step 1 Change the CWM machine to which SSM is pointing. When installing the SSM, you are prompted to enter the name of CWM machine to which the SSM points. To change the CWM machine after installation, use the updatescminfo script by entering updatescminfo <CWM hostname>"

Step 2 Get the SSM main menu. Type SCM in the command line.

Step 3 Set up the SCM domain list. In the SCMGateway.conf, add the a list of SCM gateways in "DomainGatewayList" section. (for example, DomainGatewayList <hostname_1> <hostname_2> <hostname_3>...).

Step 4 Set up a SCM forcedswitchover list. In SCMGateway.conf, add the other machine's name in "ForcedSwitchOver" section (for example, ForcedSwitchOver <new primary hostname>). When a forcedswitchover occurs, the primary role is transferred to this remote machine.

Step 5 Set up a redundant SSM on the CWM. In SCMGateway.conf, specify the remote SSM list in "RedundantSCMList" section (for example, if CWM1 and CWM2 are the standalone SSMs and CWM0 is a CWM machine, the SCMGateway.conf on CWM0 should be RedundantSCMList CWM1 CWM2).

This is the only way for the SCM Gateway on the local machine to know the presence of another SCM gateway.

---