11 About Installation and Removal

This chapter provides information about the installed components for the Oracle Communications Convergent Charging Controller application described in this guide. It also lists the files installed by the application that you can check for, to ensure that the application installed successfully.

Installation and Removal Overview

For information about the following requirements and tasks, see Installation Guide:

  • Convergent Charging Controller system requirements

  • Pre-installation tasks

  • Installing and removing Convergent Charging Controller packages

SMS Packages

An installation of Service Management System includes the following packages, on the:
  • SMS:

    • smsSms

    • smsCluster (clustered)

    • efmSms

    • efmCluster (clustered)

  • SLC:

    • smsScp

  • VWS:

    • smsExtras

Raw Devices on Clustered SMS

SMS can allocate tablespace storage based on raw (without a file system) partitions. This enhances the performance of SMS on the SMS.

If you are using the raw devices option, you must create the raw partitions before installing the database using tools such as the system’s format command.

The raw devices file (which you will be prompted to complete during the installation) must contain the full paths of the device files for the appropriate partitions.

The partitions must be at least as big as the required datafile sizings listed in the sizing file which will be used by the installation.

Example smf_devices.sh File

This is an example smf_devices.sh file.
#!/bin/sh
# The following file is the structure required for knowledge of
# raw device utilization and a few details pertaining to cluster
# creation. If clusters are not used then retaining the default
# values will be sufficient and not impact installation for raw
# device only.
#

# Details about the cluster
# How many instances in the cluster?
CLUSTER_INSTANCES=2
export CLUSTER_INSTANCES

# For each instance in the cluster we need to know the node name
# to install into the service configuration
NODE_1=smp1
NODE_2=smp2
export NODE_1 NODE_2

# These are the generic RAW DEVICE requirements for the cluster
# NOTE:// ENSURE ALL THESE DEVICES ARE READ WRITEABLE BY THE
# ORACLE USER OTHERWISE INSTALLATION WILL FAIL
# System tablespace
SYSTEM_TABLESPACE=/dev/did/rdsk/d10s5
export SYSTEM_TABLESPACE

# USERS tablespace
USERS_TABLESPACE=/dev/did/rdsk/d10s6
export USERS_TABLESPACE

# Temporary tablespace
TEMP_DATAFILE_1=/dev/did/rdsk/d10s2
TEMP_DATAFILE_2=/dev/did/rdsk/d10s3
TEMP_DATAFILE_3=/dev/did/rdsk/d10s4
TEMP_DATAFILE_4=/dev/did/rdsk/d11s0
TEMP_DATAFILE_5=/dev/did/rdsk/d11s1
TEMP_DATAFILE_6=/dev/did/rdsk/d11s2
TEMP_DATAFILE_7=/dev/did/rdsk/d11s3
TEMP_DATAFILE_8=/dev/did/rdsk/d11s4
export TEMP_DATAFILE_1 TEMP_DATAFILE_2 TEMP_DATAFILE_3
export TEMP_DATAFILE_4 TEMP_DATAFILE_5 TEMP_DATAFILE_6
export TEMP_DATAFILE_7 TEMP_DATAFILE_8

# Tools tablespace
TOOLS_TABLESPACE=/dev/did/rdsk/d10s7
export TOOLS_TABLESPACE

# 3 control file devices
CONTROL_FILE_1=/dev/did/rdsk/d12s3
CONTROL_FILE_2=/dev/did/rdsk/d12s4
CONTROL_FILE_3=/dev/did/rdsk/d12s5
export CONTROL_FILE_1 CONTROL_FILE_2 CONTROL_FILE_3

# Service Configuration Device
SRVM=/dev/did/rdsk/d11s5
export SRVM

# Now the UNDO tables. There will be 1 UNDO tablespace per instance in the
# cluster, having 5 datafiles per tablespace
# Standard to use here is UNDOTBS${NODEID}_DATAFILE_X, so UNDOTBS1
# is the UNDO space for NODE_1
# If clusters are not in use and this is raw device then UNDOTBS1
# only needs populating.
UNDOTBS1_DATAFILE_1=/dev/did/rdsk/d9s0
UNDOTBS1_DATAFILE_2=/dev/did/rdsk/d9s1
UNDOTBS1_DATAFILE_3=/dev/did/rdsk/d9s2
UNDOTBS1_DATAFILE_4=/dev/did/rdsk/d9s3
UNDOTBS1_DATAFILE_5=/dev/did/rdsk/d9s4
export UNDOTBS1_DATAFILE_1 UNDOTBS1_DATAFILE_2 UNDOTBS1_DATAFILE_3
export UNDOTBS1_DATAFILE_4 UNDOTBS1_DATAFILE_5

# We require one of the following UNDOTBS sections PER cluster instance
# The ** REQUIRED ** format is UNDOTBSX_DATAFILE_Y= where X is the instance
# ID of the node defined in NODE_X and Y is the log file number
UNDOTBS2_DATAFILE_1=/dev/did/rdsk/d9s5
UNDOTBS2_DATAFILE_2=/dev/did/rdsk/d9s6
UNDOTBS2_DATAFILE_3=/dev/did/rdsk/d9s7
UNDOTBS2_DATAFILE_4=/dev/did/rdsk/d10s0
UNDOTBS2_DATAFILE_5=/dev/did/rdsk/d10s1
export UNDOTBS2_DATAFILE_1 UNDOTBS2_DATAFILE_2 UNDOTBS2_DATAFILE_3
export UNDOTBS2_DATAFILE_4 UNDOTBS2_DATAFILE_5

# And the redo logs. The sizing is for $REDO_LOGS_PER_NODE redo logs per
# node in the cluster, so this section requires $CLUSTER_INSTANCES *
# $REDO_LOGS_PER_NODE to be complete. Naming standard is
# redo$NODEID_X, for example REDO1_1, REDO1_2 ...
REDO_LOGS_PER_NODE=16
export REDO_LOGS_PER_NODE

REDO1_1=/dev/did/rdsk/d5s0
REDO1_2=/dev/did/rdsk/d5s1
REDO1_3=/dev/did/rdsk/d5s2
REDO1_4=/dev/did/rdsk/d5s3
REDO1_5=/dev/did/rdsk/d5s4
REDO1_6=/dev/did/rdsk/d5s5
REDO1_7=/dev/did/rdsk/d5s6
REDO1_8=/dev/did/rdsk/d5s7
REDO1_9=/dev/did/rdsk/d6s0
REDO1_10=/dev/did/rdsk/d6s1
REDO1_11=/dev/did/rdsk/d6s2
REDO1_12=/dev/did/rdsk/d6s3
REDO1_13=/dev/did/rdsk/d6s4
REDO1_14=/dev/did/rdsk/d6s5
REDO1_15=/dev/did/rdsk/d6s6
REDO1_16=/dev/did/rdsk/d6s7
export REDO1_1 REDO1_2 REDO1_3 REDO1_4
export REDO1_5 REDO1_6 REDO1_7 REDO1_8
export REDO1_9 REDO1_10 REDO1_11 REDO1_12
export REDO1_13 REDO1_14 REDO1_15 REDO1_16


# As with the UNDOTBS we require a set of redo logs per nodal instance in 
# the cluster. The format ** REQUIRED ** is REDOX_Y= where X is the instance
# ID of the node defined in NODE_X and Y is the log file number
REDO2_1=/dev/did/rdsk/d7s0
REDO2_2=/dev/did/rdsk/d7s1
REDO2_3=/dev/did/rdsk/d7s2
REDO2_4=/dev/did/rdsk/d7s3
REDO2_5=/dev/did/rdsk/d7s4
REDO2_6=/dev/did/rdsk/d7s5
REDO2_7=/dev/did/rdsk/d7s6
REDO2_8=/dev/did/rdsk/d7s7
REDO2_9=/dev/did/rdsk/d8s0
REDO2_10=/dev/did/rdsk/d8s1
REDO2_11=/dev/did/rdsk/d8s2
REDO2_12=/dev/did/rdsk/d8s3
REDO2_13=/dev/did/rdsk/d8s4
REDO2_14=/dev/did/rdsk/d8s5
REDO2_15=/dev/did/rdsk/d8s6
REDO2_16=/dev/did/rdsk/d8s7
export REDO2_1 REDO2_2 REDO2_3 REDO2_4
export REDO2_5 REDO2_6 REDO2_7 REDO2_8
export REDO2_9 REDO2_10 REDO2_11 REDO2_12
export REDO2_13 REDO2_14 REDO2_15 REDO2_16

# SMS Specific
SMF_DATA_DATAFILE=/dev/did/rdsk/d11s6
SMF_INDEX_DATAFILE=/dev/did/rdsk/d11s7
SMF_LOGS_DATAFILE_1=/dev/did/rdsk/d12s0
SMF_LOGS_DATAFILE_2=/dev/did/rdsk/d12s1
SMF_LOGS_INDEX_DATAFILE=/dev/did/rdsk/d12s2
export SMF_DATA_DATAFILE SMF_INDEX_DATAFILE
export SMF_LOGS_DATAFILE_1 SMF_LOGS_DATAFILE_2
export SMF_LOGS_INDEX_DATAFILE

Setting up ssh Keys

Some of the processes in SMS use ssh and scp to transfer data around the network. Consequently, ssh keys and permissions need to be set up on the relevant machines.

Procedure

Follow these steps to generate an automatic ssh access to a replication node.

  1. Log into the SMS host as smf_oper.

  2. Enter ssh smf@host.

    where host stands for the replicated node host, for example, XXSCP1.

  3. Run the ssh-keygen package.

    Example command: 
    ssh-keygen
    Result: The script will display the following prompts one at a time:
    Enter file in which to save the key(/IN/service_packages/SMS/.ssh/id_rsa):
Generating public/private rsa key pair.

Enter passphrase(empty for no passphrase):

Enter same passphrase again

  4. Press Enter to continue.

    Result: The ssh public key will be generated and saved in .ssh/id_rsa.pub.

  5. Log into the replicated node host, for example, XXSCP1, as smf_oper.

  6. Append the content of the public key to authorized keys.

    Example command: 
    cat .ssh/id_rsa.pub >> .ssh/authorized_keys

  7. Test the ssh access on the replicated node.

    Example command: 
    ssh smf_oper@host

Checking the Installation

Refer to these checking procedures to ensure that SMS has installed correctly.

The end of the smsSms installation process (both unclustered and clustered) specifies a script designed to check the installation just performed. They must be run from the command line.

Check Unclustered SMS Procedure

Follow these steps to ensure SMS has been installed on an unclustered SMS machine correctly.

  1. Log in to SMS machine as root.

  2. Check the following directory structure exists with subdirectories:

    • /IN/service_packages/SMS

    • /IN/html

  3. Check both directories contain subdirectories and that all are owned by:
    smf_oper user (group oracle)

  4. Log into the system as smf_oper.

    Note:

    This step is to check that the smf_oper user is valid.

  5. Check that the permissions for smf_oper's .ssh directory are:
    dwrx------

    Note:

    These permissions are required for the ssh keys to work correctly.

  6. Type 
    sqlplus /

    No password is required.

    Note:

    This step is to check that the smf_oper user has valid access to the database.

  7. Check the entries of the /etc/inittab file.

    Inittab entries reserved for SMS on SMS: 
    1. sms7   /IN/service_packages/SMS/bin/smsMasterStartup.sh

    2. (runs smsMaster)

    3. sms9   /IN/service_packages/SMS/bin/smsMergeDaemonStartup.sh

    4. (runs smsMergeDaemon)

    5. sms5   /IN/service_packages/SMS/bin/smsAlarmDaemonSmsStartup.sh

    6. (runs smsAlarmDaemon)

    7. sms1   /IN/service_packages/SMS/bin/smsAlarmRelayStartup.sh

    8. (runs smsAlarmRelay)

    9. sms6   /IN/service_packages/SMS/bin/smsStatsThresholdStartup.sh

    10. (runs smsStatsThreshold)

    11. sms4   /IN/service_packages/SMS/bin/smsReportSchedulerStartup.sh

    12. (runs smsReportScheduler)

    13. sms3   /IN/service_packages/SMS/bin/smsReportsDaemonStartup.sh

    14. (runs smsReportsDaemon)

    15. sms2   /IN/service_packages/SMS/bin/smsNamingServerStartup.sh

    16. (runs smsNamingServer)

    17. sms8   /IN/service_packages/SMS/bin/smsTaskAgentStartup.sh

    18. (runs smsTaskAgent)

  8. Check that the processes listed in the process lists are running on the relevant machine. For a list of the processes which should be running, see Process list - unclustered SMP.

Check Clustered SMS Procedure

Follow these steps to ensure SMS has been installed on a clustered SMS machine correctly.

  1. Log in to SMS machine as root.

  2. Check the following directory structure exists with subdirectories:

    • /IN/service_packages/SMS

    • /IN/html

  3. Check both directories contain subdirectories and that all are owned by:

    smf_oper user (group oracle)

  4. Log into the system as smf_oper.

    Note:

    This step is to check that the smf_oper user is valid.

  5. Check that the permissions for smf_oper's .ssh directory are:
    dwrx------

    Note:

    These permissions are required for the ssh keys to work correctly.

  6. Type 
    sqlplus /

    No password is required.

    Note:

    This step is to check that the smf_oper user has valid access to the database.

  7. Check the entries of the /etc/inittab file.

    Inittab entries reserved for SMS on SMS:
    sms7   /IN/service_packages/SMS/bin/smsMasterStartup.sh (runs smsMaster)
  8. Ensure the following shell scripts are configured to be run by the clustering software:

    • /IN/service_packages/SMS/bin/smsAlarmDaemonSmsCluster.sh

      (runs smsAlarmDaemon)

    • /IN/service_packages/SMS/bin/smsAlarmRelayCluster.sh

      (runs smsAlarmRelay)

    • /IN/service_packages/SMS/bin/smsStatsThresholdCluster.sh

      (runs smsStatsThreshold)

    • /IN/service_packages/SMS/bin/smsReportSchedulerCluster.sh

      (runs smsReportScheduler)

    • /IN/service_packages/SMS/bin/smsReportsDaemonCluster.sh

      (runs smsReportsDaemon)

    • /IN/service_packages/SMS/bin/smsNamingServerCluster.sh

      (runs smsNamingServer)

    • /IN/service_packages/SMS/bin/smsTaskAgentCluster.sh

      (runs smsTaskAgent)

  9. Check that the processes listed in the process lists are running on the relevant machine.

Check SLC Procedure

Follow these steps to ensure SMS has been installed on the SLC machine correctly.

  1. Log in to SLC machine as root.

  2. Check the following directory structure exists with subdirectories: /IN/service_packages/SLEE

  3. Check both directories contain subdirectories and that all are owned by: smf_oper user (group oracle)

  4. Log into the system as smf_oper.

    Note:

    This step is to check that the smf_oper user is valid.

  5. Check that the permissions for smf_oper's .ssh directory are:
    dwrx------

    Note:

    These permissions are required for the ssh keys to work correctly.

  6. Type 
    sqlplus /

    No password is required.

    Note:

    This step is to check that the smf_oper user has valid access to the database.

  7. Ensure that the required ACS triggers have been added to the database for the ACS_ADMIN oracle user.

  8. Check the entries of the /etc/inittab file.

    Inittab entries reserved for SMS on SLC:

    • scp1 /IN/service_packages/SMS/bin/cmnPushFilesStartup.sh

      (runs cmnPushFiles)

    • scp2 /IN/service_packages/SMS/bin/infMasterStartup.sh

      (runs infMaster)

    • scp3 /IN/service_packages/SMS/bin/smsStatsDaemonStartup.sh

      (runs smsStatsDaemon)

    • scp4 /IN/service_packages/SMS/bin/smsAlarmDaemonScpStartup.sh

      (runs smsAlarmDaemon)

    • scp5 /IN/service_packages/SMS/bin/updateLoaderStartup.sh

      (runs updateLoader)

  9. Check that the processes listed in the process lists are running on the relevant machine.

Check Other Machines Procedure

Follow these steps to ensure SMS has been installed correctly on machines other than SMSs or SLCs.

  1. Log in to the machine as root.

  2. Check the following directory structure exists with subdirectories: /IN/service_packages/SMS

  3. Check both directories contain subdirectories and that all are owned by:
    smf_oper user (group oracle)

  4. Log into the system as smf_oper.

    Note:

    This step is to check that the smf_oper user is valid.

  5. Check that the permissions for smf_oper's .ssh directory are:
    dwrx------

    Note:

    These permissions are required for the ssh keys to work correctly.

  6. If a database has been installed on the machine, and SMS statistics has been configured to use the database, type 
    sqlplus /

    No password is required.

    Note:

    This step is to check that the smf_oper user has valid access to the database.

  7. Ensure that the required SMS tables have been added to the database for the SMF oracle user.

  8. Check the entries of the /etc/inittab file:

    Inittab entries reserved for SMS on SLC:

    1. ext8 /IN/service_packages/SMS/bin/smsStatsDaemonStartup.sh

      (runs smsStatsDaemon)

    2. ext9 /IN/service_packages/SMS/bin/smsAlarmDaemonStartup.sh

      (runs smsAlarmDaemon)

  9. Check that the processes listed in the process lists are running on the relevant machine. For a list of the processes which should be running, see Process list - other machines (on page 262).

Process List

If the application is running correctly, the following processes should be running on each SMS, started from the inittab:

  • smsMaster

  • smsMergeDaemon

  • smsAlarmDaemon

  • smsAlarmManager

  • smsAlarmRelay

  • smsStatsThreshold

  • smsReportScheduler

  • smsReportsDaemon

  • smsNamingServer

  • smsTaskAgent

  • smsTrifDaemon

Process List - Clustered SMS

If the application is running correctly, the following processes should be running on each SMS.

  • smsMaster, started from the inittab.

  • The following are started by the clustering software.

    • smsAlarmDaemon

    • smsAlarmManager

    • smsAlarmRelay

    • smsStatsThreshold

    • smsReportScheduler

    • smsReportsDaemon

    • smsNamingServer

    • smsTaskAgent

    • smsTrigDaemon

Process List - SLC

If the application is running correctly, the following processes should be running on each SLC, started from the inittab:

  • infMaster

  • updateLoader

  • smsAlarmDaemon

  • smsStatsDaemon

  • cmnPushFiles

Process List - Other Machines

If the application is running correctly, the following processes should be running on each platform, started from the inittab:

  • If alarms use replication, smsAlarmDaemon

  • If statistics use replication, smsStatsDaemon

Check the SMS Administration Screens

Check that the SMS administration screens are working correctly. Launch the application using smsGui.bat/smsGui.sh script. For more information about using the SMS Java administration screens, see Service Management System User's Guide.

Check Alarm Replication

Follow these steps to check that alarm replication is functioning correctly.

  1. Open the SMS Java administration screen.

  2. Open the Operator Functions > Node Management screen.

  3. Click Create.

    Result: This will create a replication.config file and distribute a copy to all the machines in the IN.

  4. Check that the file exists on all the machines in the IN.

  5. On each node in the IN, use smsLogTest to generate an error. For more information about smsLogTest, see smsLogTest (on page 220).

  6. Open the Operator Functions > Alarm Management screen.

  7. Check that the alarm has replicated from each node into the SMF_ALARM_MESSAGE table in the SMF.

Enabling Index Defragmentation

Once the installation process is completed, it is advisable to enable the index defragmentation facility, although it is not strictly necessary.

Note:

This facility has a dependency on specific Oracle configuration settings which relate to the nature of deployment. For more information how to install the defragmentation script, see Index defragmentation.